Python-ideas February 2013

python-ideas@python.org

85 participants
39 discussions

Functions and Unbound methods
by robert2682 22 Feb '13

22 Feb '13

Hi, I'm new; greetings all! I'm not sure if this is a bug or feature, but it confused me so I thought I'd raise the issue. class a: def b (self): pass foo = ('Hello', b) class c(a): def d(self): t = type (self. __class__. foo [1]) print t t = type (self. __class__. b) print t e = c () e. d() prints <type 'function'> for the first print, and it seems to me it should be an instancemethod I'm trying to something like this class EditPage: additonal_buttons = () def __init__ (self): buts = [] for x in addional_butons: if isinstance (x [1], types. UnboundMethodType): # fails because type (x [1]) is function, not UnboundMethod buts. append ((x [0], types. MethodType (x [1], self))) else: buts. append (x) class TreePage(EditPage): def EditAsText (self): pass additional_buttons = (('EditAsText', EditAsText),) Thanks Robert Kaplan robert2682(a)verizon.net

3 2

Re: [Python-ideas] Functions and Unbound methods
by robert2682 22 Feb '13

22 Feb '13

Hi, > Hi, > > I'm new; greetings all! > > I'm not sure if this is a bug or feature, but it confused me so I thought > I'd raise the issue. > > > class a: > def b (self): > pass > > foo = ('Hello', b) > > class c(a): > def d(self): > t = type (self. __class__. foo [1]) > print t > t = type (self. __class__. b) > print t > > e = c () > e. d() > > prints <type 'function'> for the first print, > and it seems to me it should be an instancemethod > > [snip] > I think what's happening is that it's defining 'b' as a function in the > class's namespace, storing a reference to that function in the tuple, > and then, when the class definition ends, it's wrapping the function as > a method. > > You'll find: > > >>> a.foo[1] > <function b at 0x00B42C30> > >>> a.b > <unbound method a.b> > >>> a.b.im_func is a.foo[1] > True > I'm afraid this won't do what I want. As illustrated below, I want to store the reference from withing the same class, so as to be able to access in from a superclass. (sorry if subclass and superclass is not the correct terminology for Python) > I'm trying to something like this > > class EditPage: > > additonal_buttons = () > def __init__ (self): > buts = [] > for x in addional_butons: > if isinstance (x [1], types. UnboundMethodType): # fails > because type (x [1]) is function, not UnboundMethod > buts. append ((x [0], types. MethodType (x [1], self))) > else: > buts. append (x) > > class TreePage(EditPage): > def EditAsText (self): > pass > > additional_buttons = (('EditAsText', EditAsText),) > > It might be that Python simple doesn't do exactly what I want. This is really unusual; mostly I think it's great and highly intuitive. No biggie; I'm sure I can find a workaround! Bob

1 0

Introducing PEP 434 -- IDLE Enhancement Exception for All Branches
by Todd Rovito 22 Feb '13

22 Feb '13

Please see http://www.python.org/dev/peps/pep-0434/ for the complete PEP. The idea for the PEP was generated because a right click menu was added to IDLE in Python 2.7 this started a debate about bug fix VS enhancement see the PEP references for more information. IDLE has many patches that already exist but are difficult to get committed. This PEP is designed to make it easier to bring IDLE up to speed with modern GUI standards. The PEP is not perfect some issues that need to be solved: -How do we test IDLE patches to make sure they are high quality? Apparently the build bots don't test user interface issues. My philosophy is keep it simple so I was thinking that a simple procedure for testing on each of the major platforms should be performed before a commit. Creating a build bot that tests user interfaces seems difficult to me and could put IDLE improvements even more behind. -Does it make sense to separate IDLE from the stdlib for Python 3.4? I understand the batteries included argument, but if IDLE development is going to continue to proceed at a more accelerated pace than Python, it might make sense to separate it out into its own project or a sub-project. Please provide comments or other concerns. Thanks.

10 16

capturing the origin of objects
by Eric Snow 20 Feb '13

20 Feb '13

With the removal of unbound methods in Python 3, introspecting the class on which a method was defined is not so simple. Python 3.3 gives us __qualname__ for classes and functions (see PEP 3155), which helps somewhat by giving us a string composed at compile-time. However, I was considering something a little more powerful. I propose that what would have formerly been an unbound method get a new attribute, __origin__. It will be bound to class where the method is defined. Motivation ========== One motivator for this proposal is http://bugs.python.org/issue15582, allowing inspect.getdoc() to "inherit" docstrings. Without a concrete connection between a method and the "origin" class, dynamically determining the docstring is basically a non-starter. The __origin__ attribute would help. Extended Idea ============= The name, __origin__, is a bit generic to accommodate the possible extension of the proposal to other objects: * f.__origin__ (the module or function (nested) where the function was defined) * cls.__origin__ (the module, class (nested), or function where the class was defined) * code.__origin__ (the function for which the code object was originally created) * module.__origin__ (a.k.a. module.__file__) For functions and classes defined in a function, __origin__ would be bound to the function rather than the locals or the code object. For modules, __origin__ is more accurate in the cases that the module was generated from something other than a file. It would still be a string, though. Also, we currently have a convention of setting __module__ to the name of the module rather than the module itself. Whether to break with that convention for __origin__ is an open question which relates to how __origin__ would be used. Conceivably, each use case for __origin__ could be covered by a name more specific to the object, e.g. module.__file__. However, having the one name would help make the purpose clear and consistent. Objections ========== The downside of binding the objects to __origin__ is in memory usage and, particularly, in ref-counts/reference-cycles. I expect that this is where the biggest objections will lie. However, my understanding is that this is less of an issue now than it used to be. If need be, weakref proxies could address some of the concerns. The status quo has a gap in the case of "unbound" methods and of code objects, though __qualname__ does offer an improvement for methods. The actual use case I have relates strictly to those methods. Having something like __origin__ for those methods, at least, would be helpful. -eric

1 0

A subclassing API for named tuples?
by Nick Coghlan 19 Feb '13

19 Feb '13

An exchange with Antoine in one of the enum threads sparked a thought. A recurring suggestion for collections.namedtuple is that it would be nice to be able to define them like this (as it not only avoids having to repeat the class name, but also allows them to play nicely with pickle and other name-based reference mechanisms): class MyTuple(collections.NamedTuple): __fields__ = "a b c d e".split() However, one of Raymond's long standing objections to such a design for namedtuple is the ugliness of people having to remember to include the right __slots__ definition to ensure it doesn't add any storage overhead above and beyond that for the underlying tuple. For the intended use case as a replacement for short tuples, an unused dict per instance is a *big* wasted overhead, so that concern can't be dismissed as premature optimisation: >>> import sys >>> class Slots(tuple): __slots__ = () ... >>> class InstanceDict(tuple): pass ... >>> sys.getsizeof(tuple([1, 2, 3])) 72 >>> x = Slots([1, 2, 3]) >>> sys.getsizeof(x) 72 >>> y = InstanceDict([1, 2, 3]) >>> sys.getsizeof(y) # All good, right? 72 >>> sys.getsizeof(y.__dict__) # Yeah, not so much... 96 However, the thought that occurred to me is that the right metaclass definition allows the default behaviour of __slots__ to be flipped, so that you get "__slots__ = ()" defined in your class namespace automatically, and you have to write "del __slots__" to get normal class behaviour back: >>> class SlotsMeta(type): ... def __prepare__(cls, *args, **kwds): ... return dict(__slots__=()) ... >>> class SlotsByDefault(metaclass = SlotsMeta): pass ... >>> class Slots(tuple, SlotsByDefault): pass ... >>> class InstanceDict(tuple, SlotsByDefault): del __slots__ ... >>> sys.getsizeof(Slots([1, 2, 3])) 72 >>> Slots().__dict__ Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: 'Slots' object has no attribute '__dict__' >>> sys.getsizeof(InstanceDict([1, 2, 3])) 72 >>> sys.getsizeof(InstanceDict([1, 2, 3]).__dict__) 96 So, what do people think? Too much magic? Or just the right amount to allow a cleaner syntax for named tuple definitions, without inadvertently encouraging people to do bad things to their memory usage? (Note: for backwards compatibility reasons, we couldn't use a custom metaclass for the classes returned by the existing collections namedtuple API. However, we could certainly provide a distinct collections.NamedTuple type which used a custom metaclass to behave this way). Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

9 22

Re: [Python-ideas] PEP for enum library type?
by Guido van Rossum 14 Feb '13

14 Feb '13

After all the defenses I still don't like Tim's proposed syntax. Color me Barry. On Tue, Feb 12, 2013 at 11:54 AM, Tim Delaney <tim.delaney(a)aptare.com> wrote: > On 13 February 2013 06:13, Guido van Rossum <guido(a)python.org> wrote: >> >> So with Tim's implementation, what happens here: >> >> class Color(Enum): >> RED, GREEN, BLUE >> if sys.platform == 'win32': >> MAGENTA >> >> and you happen to have no "import sys" in your module? The sys lookup >> will succeed, create a new enum, and then you will get an error >> something like this: >> >> AttributeError: 'Enum' object has no attribute 'platform' > > > Well, that particular case would work (you'd get a NameError: sys) due to > having done an attribute lookup on sys, but the following: > > class Color(Enum): > RED, GREEN, BLUE > if platfor == 'win32': > MAGENTA > > would create an enum value 'platfor'. > > Personally, I don't think it's possible to have an enum with a simple > interface and powerful semantics with just python code without it being > fragile. I think I've got it fairly close, but there is horrible magic in > there (multiple kinds) and there are definitely still edge cases. Any > complete enum implementation is going to need some special handling by the > parser I think. > > I'm actually thinking that to simplify things, I need a sentinel object to > mark the end of the enum list (which allows other names after it). But that > still wouldn't handle the case above (the if statement). > > BTW, for anyone who hasn't seen the magic code (largely uncommented, no > explanations yet of how it's doing it - I probably won't get to that until > the weekend) it's here: https://bitbucket.org/magao/enum > > Tim Delaney -- --Guido van Rossum (python.org/~guido)

13 31

another enum implementation
by Ethan Furman 13 Feb '13

13 Feb '13

I realize this isn't going very far, but I would still appreciate feedback. :) The code is here: https://bitbucket.org/stoneleaf/enum It is based on ideas from Michael Foord, Antoine Pitrou, and (eventually) Ted Delaney. Enum only accepts upper-case names as enum candidates; all enum values must be the same: either 'sequence' (0, 1, 2, etc) or 'flag' (1, 2, 4, etc.) or 'unique' (north, south, east, west, etc.); and extending via subclassing is possible. Sample code: class Color(Enum): type = 'sequence' BLACK RED GREEN = 4 BLUE print Color # Color(BLACK:0, RED:1, GREEN:4, BLUE:5) class MoreColor(Color): MAGENTA YELLOW CYAN print MoreColor # MoreColor(BLACK:0, RED:1, GREEN:4, BLUE:5, MAGENTA:6, YELLOW:7, # CYAN:8) class DbfType(Enum): type = 'unique' CLP DB3 VFP --> print(enum.DbfType) # DbfType(DB3:'db3', CLP:'clp', VFP:'vfp') class SomeFlags(Enum): type = 'flag' ON_DISK HAS_MEMO LARGE_CHAR UNICODE --> print(enum.SomeFlags) # SomeFlags(ON_DISK:1, HAS_MEMO:2, LARGE_CHAR:4, UNICODE:8) class Error(Enum): type = 'sequence' THIS THAT The_Other # raises NameError THOSE = 1 # raises InvalidEnum -->enum.Color.RED Color('RED') -->enum.Color.RED == 1 True -->int(enum.Color.RED) 1 -->enum.SomeFlags.ON_DISK SomeFlags('ON_DISK') -->enum.SomeFlags.ON_DISK == 1 True -->int(enum.SomeFlags.ON_DISK) 1 -->enum.SomeFlags.ON_DISK == enum.Color.RED False -->enum.MoreColor.RED == 1 True -->enum.MoreColor.RED == enum.Color.RED True -->enum.Color(1) Color('RED') -->enum.Color('RED') Color('RED') --> for color in enum.Color: ... print(color) ... BLACK RED GREEN BLUE --> for color in enum.Color: ... print(repr(color)) ... Color('BLACK') Color('RED') Color('GREEN') Color('BLUE') I would appreciate any comments on both the API, and the code behind it. Thanks. -- ~Ethan~

3 5

constant/enum type in stdlib
by Joao S. O. Bueno 13 Feb '13

13 Feb '13

This idea is not new - but it is stalled - Last I remember it came around in Python-devel in 2010, in this thread: http://mail.python.org/pipermail/python-dev/2010-November/thread.html#105967 There is an even older PEP (PEP 354) that was rejected just for not being enough interest at the time - And it was not dismissed at all - to the contrary the last e-mail in the thread is a message from the BDLF for it to **be** ! The discussion happened in a bad moment as Python was mostly freature froozen for 3.2 - and it did not show up again for Python 3.3; The reasoning for wanting enums/ constants has been debated already - but one of the main reasons that emerge from that thread are the ability to have named constants (just like we have "True" and "False". why do I think this is needed in the stdlib, and having itin a 3rd party module is not enough? because they are an interesting thing to have, not only on the stdlib, but on several widely used Python projects that don't have other dependencies. Having a feature like this into the stdlib allow these projects to make use of it, without needing other dependencies, and moreover, users which will benefit the most out of such constants will have a wll known "constant" type which won't come as a surprise in each package he is using interactively or debugging. Most of the discussion on the 2010 thread was summed up in a message by Michael Foord in this link http://mail.python.org/pipermail/python-dev/2010-November/106063.html with some follow up here: http://mail.python.org/pipermail/python-dev/2010-November/106065.html js -><- ---------- --

23 80

PEP 3156 / Tulip: stopping the loop while in run_until_complete
by Saúl Ibarra Corretgé 11 Feb '13

11 Feb '13

Hi, While analyzing some code I came across the following situation: - User calls run_until_complete for some Task - The task itself calls loop.stop() at some point - run_until_complete raises TimeoutError Here is a very simple example: https://gist.github.com/saghul/4754117 Something seems a bit off here. While one could argue that stopping the loop while run_until_complete is ongoing, getting a TimeoutError doesn't feel right. I think we should detect that the loop was stopped but the future is not done and raise something like NotCompleted or FutureNotCompleted. Thoughts? -- Saúl Ibarra Corretgé http://saghul.net/blog | http://about.me/saghul

2 11

PEP 3156 / Tulip: Synchronization primitives
by Nikolay Kim 09 Feb '13

09 Feb '13

I think Tulip should have synchronization primitives by default. Here is my motivation: 1. it is more convenient to use locking primitive with existing semantics rather than tulip magic. crawl.py example could use semaphore instead of tasks.wait with timeout 0. 2. while it seems easy to implement semaphore with tulip, it still requires deep understanding of tulips control flow. i had 2 not very obvious bugs in my semaphore implementation: a) release() could be called from different co-routines during same scheduling step. b) bug with acquire and release during same scheduling step. example: 1. task tries to acquire locked semaphore 2. other task releases semaphore in result - semaphore gets acquired 2 times at the end of scheduling step, because actual semaphore acquisition happens in "call_soon" and at this stage release() call is already released semaphore but first waiter does not acquire it yet. Thoughts? my implementation: https://codereview.appspot.com/download/issue7230045_15001.diff

4 3

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

Python-ideas February 2013