Mailman 3 June 2012 - Python-Dev

Re: [Python-Dev] [Python-checkins] peps: Update 422 based on python-dev feedback
by Daniel Urban June 7, 2012

June 7, 2012

On Thu, Jun 7, 2012 at 2:08 PM, nick.coghlan <python-checkins(a)python.org> wrote: > -* If the metaclass hint refers to an instance of ``type``, then it is > +* If the metaclass hint refers to a subclass of ``type``, then it is > considered as a candidate metaclass along with the metaclasses of all of > the parents of the class being defined. If a more appropriate metaclass is > found amongst the candidates, then it will be used instead of the one I … [View More]

2 1

Re: [Python-Dev] [Python-checkins] peps: Update 422 based on python-dev feedback
by Daniel Urban June 7, 2012

June 7, 2012

On Thu, Jun 7, 2012 at 9:47 PM, Terry Reedy <tjreedy(a)udel.edu> wrote: > On 6/7/2012 11:45 AM, Daniel Urban wrote: >> >> On Thu, Jun 7, 2012 at 2:08 PM, nick.coghlan<python-checkins(a)python.org> >> wrote: >>> >>> -* If the metaclass hint refers to an instance of ``type``, then it is >>> +* If the metaclass hint refers to a subclass of ``type``, then it is >>> considered as a candidate metaclass along with the … [View More]

1 0

next alpha sequence value from var pointing to array
by jdmorgan June 7, 2012

June 7, 2012

Hello, I am hoping that this list is a good place to ask this question.I am still fairly new to python, but find it to be a great scripting language.Here is my issue: I am attempting to utilize a function to receive any sequence of letter characters and return to me the next value in alphabetic order e.g. send in "abc" get back "abd".I found a function on StackExchange (Rosenfield, A 1995) that seems to work well enough (I think): def next(s): strip_zs = s.rstrip('z') if strip_zs: … [View More]

2 1

Cross-compiling python and PyQt
by Tarek Sheasha June 6, 2012

June 6, 2012

Hello, I have been working for a long time on cross-compiling python for android I have used projects like: http://code.google.com/p/android-python27/ I am stuck in a certain area, when I am cross-compiling python I would like to install SIP and PyQt4 on the cross-compiled python, I have tried all the possible ways I could think of but have had no success. So if you can help me by giving me some guidelines on how to install third-party software for cross-compiled python for android I would be … [View More]

3 2

Re: [Python-Dev] [Python-checkins] peps: PEP 422 rewrite to present an idea that a) isn't crazy and b) it turns out
by Eric Snow June 6, 2012

June 6, 2012

On Wed, Jun 6, 2012 at 5:40 AM, nick.coghlan <python-checkins(a)python.org> wrote: > + > +Alternatives > +============ > + Would it be worth also (briefly) rehashing why the class instance couldn't be created before the class body is executed*? It might seem like a viable alternative if you haven't looked at how classes get created. -eric * i.e. meta.__new__() would have to be called before the class body is executed for the class to exist during that execution. Perhaps … [View More]

2 1

Static type analysis
by Edward K. Ream June 6, 2012

June 6, 2012

Hello all, I'm wondering whether this is the appropriate place to discuss (global) static type analysis, a topic Guido mentioned around the 28 min mark in his PyCon 2012 keynote, http://pyvideo.org/video/956/keynote-guido-van-rossum This is a topic that has interested me for a long time, and it has important implications for Leo. Just now I have some free time to devote to it. Edward ------------------------------------------------------------------------------ Edward K. Ream email: … [View More]

2 1

Re: [Python-Dev] [Python-checkins] peps: PEP 422 rewrite to present an idea that a) isn't crazy and b) it turns out
by Terry Reedy June 6, 2012

June 6, 2012

On 6/6/2012 7:40 AM, nick.coghlan wrote: > PEP 422 rewrite to present an idea that a) isn't crazy and > b) it turns out Thomas Heller proposed back in 2001 > +There is currently no corresponding mechanism in Python 3 that allows the > +code executed in the class body to directly influence how the class object > +is created. Instead, the class creation process is fully defined by the > +class header, before the class body even begins executing. This makes the problem for … [View More]

2 1

Possible rough edges in Python 3 metaclasses (was Re: Language reference updated for metaclasses)
by Nick Coghlan June 6, 2012

June 6, 2012

On Tue, Jun 5, 2012 at 8:58 AM, PJ Eby <pje(a)telecommunity.com> wrote: > On Mon, Jun 4, 2012 at 6:15 PM, Nick Coghlan <ncoghlan(a)gmail.com> wrote: >> >> It's actually the pre-decoration class, since the cell is initialised >> before the class is passed to the first decorator. I agree it's a little >> weird, but I did try to describe it accurately in the new docs. > > I see that now; it might be helpful to explicitly call that out. > > This is … [View More]adding to my list of Python 3 metaclass gripes, though. In Python > 2, I have in-the-body-of-a-class decorators implemented using metaclasses, > that will no longer work because of PEP 3115... I'm not quite following this one - do you mean they won't support __prepare__, won't play nicely with other metaclasses that implement __prepare__, or something else? > and if I switch to using > class decorators instead, then they won't work because of PEP 3135. :-( Yeah, 3135 has had some "interesting" consequences :P (e.g. class body level __class__ definitions are still broken at the moment if you also reference super: http://bugs.python.org/issue12370) > Meanwhile, mixing metaclasses is more difficult than ever, due to > __prepare__, and none of these flaws can be worked around officially, > because __build_class__ is an "implementation detail". I *really* want to > like Python 3, but am still hoping against hope for the restoration of hooks > that __metaclass__ allowed, or some alternative mechanism that would serve > the same use cases. > > Specifically, my main use case is method-level decorators and attribute > descriptors that need to interact with a user-defined class, *without* > requiring that user-defined class to either 1) redundantly decorate the > class or 2) inherit from some specific base or inject a specific metaclass. > I only use __metaclass__ in 2.x for this because it's the only way for code > executed in a class body to gain access to the class at creation time. > > The reason for wanting this to be transparent is that 1) if you forget the > redundant class-decorator, mixin, or metaclass, stuff will silently not > work, Why would it silently not work? What's preventing you from having decorators that create wrapped functions that fail noisily when called, then providing a class decorator that unwraps those functions, fixes them up with the class references they need and stores the unwrapped and updated versions back on the class. You call it redundant, I call it explicit. > and 2) mixing bases or metaclasses has much higher coupling to the > library providing the decorators or descriptors, and greatly increases the > likelihood of mixing metaclasses. So don't do that, then. Be explicit. > And at the moment, the only workaround I can come up with that *doesn't* > involve replacing __build_class__ is abusing the system trace hook; ISTM > that replacing __build_class__ is the better of those two options. Stop trying to be implicit. Implicit magic sucks, don't add more (PEP 3135 is bad enough). > At this point, with the additions of types.new_class(), ISTM that every > Python implementation will have to *have* a __build_class__ function or its > equivalent; all that remains is the question of whether they allow > *replacing* it. types.new_class() is actually a pure Python reimplementation of the PEP 3115 algorithm. Why would it imply the need for a __build_class__ function? Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia [View Less]

7 22

Open PEPs and large-scale changes for 3.3
by Georg Brandl June 6, 2012

June 6, 2012

With 3.3a3 tagged and the beta stage currently 2 months away, I would like to draw your attention to the following list of possible features for 3.3 as specified by PEP 398: Candidate PEPs: * PEP 362: Function Signature Object * PEP 395: Qualified Names for Modules * PEP 397: Python launcher for Windows * PEP 402: Simplified Package Layout (likely a new PEP derived from it) -- I assume PEP 420 is a candidate for that? * PEP 405: Python Virtual Environments * PEP 421: Adding sys.… [View More]

15 30

Re: [Python-Dev] [Python-checkins] peps: Add PEP 422: Dynamic Class Decorators
by Terry Reedy June 5, 2012

June 5, 2012

On 6/5/2012 8:09 AM, nick.coghlan wrote: > Add PEP 422: Dynamic Class Decorators > +Iterating over decorator entries in reverse order > +------------------------------------------------- > + > +This order was chosen to match the layout of lexical decorators when > +converted to ordinary function calls. Just as the following are equivalent:: > + > + @deco2 > + @deco1 > + class C: > + pass > + > + class C: > + pass > + … [View More]

7 8