Re: [Python-Dev] Possible rough edges in Python 3 metaclasses (was Re: Language reference updated for metaclasses)

On Wed, Jun 6, 2012 at 1:48 PM, PJ Eby wrote: > On Tue, Jun 5, 2012 at 8:14 PM, Nick Coghlan wrote: >> >> On reflection, I'm actually inclined to agree. The next version of the >> PEP will propose the addition of type.__decorate__(). This new method >> will be invoked *after* the class is created

Re: [Python-Dev] Updated PEP 362 (Function Signature Object)

On Wed, Jun 6, 2012 at 12:51 PM, Yury Selivanov wrote: > As for moving Signature object to `functools`, we had this discussion with > Brett, and here is what he suggested: > >    Functools contains code that transforms what a function >    does while inspect is about introspection. These objects

Re: [Python-Dev] TZ-aware local time

MRAB writes: > datetime objects would consist of the UTC time, time zone and DST. “time zone” information always entails DST information doesn't it? It isn't proper time zone information if it doesn't tell you about DST. That is, when you know the full time zone information, that includes when

Re: [Python-Dev] TZ-aware local time

On Tue, Jun 5, 2012 at 8:41 PM, Nick Coghlan wrote: > On Wed, Jun 6, 2012 at 1:14 PM, Guido van Rossum wrote: >> You can try to enforce this, but users will ignore it, and happily >> represent local time as UTC. I've seen people do this with POSIX >> timestamps too -- use the UTC conversions betw

Re: [Python-Dev] Possible rough edges in Python 3 metaclasses (was Re: Language reference updated for metaclasses)

On Tue, Jun 5, 2012 at 8:14 PM, Nick Coghlan wrote: > On reflection, I'm actually inclined to agree. The next version of the > PEP will propose the addition of type.__decorate__(). This new method > will be invoked *after* the class is created and the __class__ cell is > populated, but *before* l

Re: [Python-Dev] TZ-aware local time

On Wed, Jun 6, 2012 at 1:14 PM, Guido van Rossum wrote: > You can try to enforce this, but users will ignore it, and happily > represent local time as UTC. I've seen people do this with POSIX > timestamps too -- use the UTC conversions between timestamps and time > tuples, and yet use time tuples

Re: [Python-Dev] TZ-aware local time

On 06/06/2012 02:57, Alexander Belopolsky wrote: On Tue, Jun 5, 2012 at 7:11 PM, Greg Ewing wrote: What would be so bad about giving datetime objects a DST flag? Apps that don't care could ignore it and get results no worse than the status quo. This would neatly solve the round-trip proble

Re: [Python-Dev] TZ-aware local time

On Tue, Jun 5, 2012 at 6:31 PM, Glyph wrote: > > Le Jun 5, 2012 à 6:16 PM, Nick Coghlan a écrit : > > Personally, I'd like to see the datetime module make an explicit > assumption that "all naive datetime objects are considered to be UTC", > with the interactions between naive and aware objects up

Re: [Python-Dev] TZ-aware local time

On Tue, Jun 5, 2012 at 6:39 PM, Alexander Belopolsky wrote: > On Tue, Jun 5, 2012 at 9:16 PM, Nick Coghlan wrote: >> ...  Local time should only be used for displaying >> dates and times to humans (since we care about little things like >> local sunrise and sunset, local business hours, etc) and

Re: [Python-Dev] TZ-aware local time

On Tue, Jun 5, 2012 at 7:44 PM, Nick Coghlan wrote: > On Wed, Jun 6, 2012 at 11:57 AM, Alexander Belopolsky > wrote: >> On Tue, Jun 5, 2012 at 7:11 PM, Greg Ewing >> wrote: >>> What would be so bad about giving datetime objects >>> a DST flag? Apps that don't care could ignore it and >>> get re

Re: [Python-Dev] Updated PEP 362 (Function Signature Object)

Nick, On 2012-06-05, at 9:45 PM, Nick Coghlan wrote: > Specific proposals: > > - the goals of the PEP be expanded to include error checking of > parameter binding for delayed calls and improve introspection of > function wrappers that accept arbitrary arguments, rather than the > more nebulous "i

Re: [Python-Dev] TZ-aware local time

On Wed, Jun 6, 2012 at 11:57 AM, Alexander Belopolsky wrote: > On Tue, Jun 5, 2012 at 7:11 PM, Greg Ewing > wrote: >> What would be so bad about giving datetime objects >> a DST flag? Apps that don't care could ignore it and >> get results no worse than the status quo. > > This would neatly solv

Re: [Python-Dev] TZ-aware local time

On Tue, 05 Jun 2012 18:31:20 -0700, Glyph wrote: > > Le Jun 5, 2012 à 6:16 PM, Nick Coghlan a écrit : > > > Personally, I'd like to see the datetime module make an explicit > > assumption that "all naive datetime objects are considered to be UTC", > > with the interactions between naive and aw

Re: [Python-Dev] TZ-aware local time

On Tue, Jun 5, 2012 at 7:11 PM, Greg Ewing wrote: > What would be so bad about giving datetime objects > a DST flag? Apps that don't care could ignore it and > get results no worse than the status quo. This would neatly solve the round-trip problem, but will open a different can of worms: what ha

Re: [Python-Dev] [Python-checkins] peps: Add PEP 422: Dynamic Class Decorators

On Wed, 06 Jun 2012 09:38:39 +1000, Nick Coghlan wrote: > On Wed, Jun 6, 2012 at 9:06 AM, PJ Eby wrote: > > > > > > On Tue, Jun 5, 2012 at 5:31 PM, Terry Reedy wrote: > >> > >> On 6/5/2012 2:26 PM, PJ Eby wrote: > >>> It's for symmetry and straightforward translation with stacked > >>> decorator

Re: [Python-Dev] Issue 2736: datetimes and Unix timestamps

Terry Reedy wrote: "A rich comparison method may return the singleton NotImplemented if it does not implement the operation for a given pair of arguments. By convention, False and True are returned for a successful comparison. However, these methods can return any value," That's to give the

Re: [Python-Dev] TZ-aware local time

Alexander Belopolsky wrote: The problem is again the DST ambiguity. One day a year, datetime(y, m, d, 1, 30, tzinfo=Local) represents two different times and another day it represents no valid time. The documentation example (fixed in issue 9063) addresses the ambiguity by defaulting to standar

Re: [Python-Dev] Updated PEP 362 (Function Signature Object)

On Wed, Jun 6, 2012 at 10:26 AM, Brett Cannon wrote: > On behalf of Yury, Larry, Jiwon (wherever he ended up), and myself, here is > an updated version of PEP 362 to address Guido's earlier comments. Credit > for most of the update should go to Yury with Larry also helping out. > > At this point I

Re: [Python-Dev] TZ-aware local time

On Tue, Jun 5, 2012 at 9:16 PM, Nick Coghlan wrote: > ... Local time should only be used for displaying > dates and times to humans (since we care about little things like > local sunrise and sunset, local business hours, etc) and for > inter-system coordination where such details are relevant. >

Re: [Python-Dev] TZ-aware local time

Le Jun 5, 2012 à 6:16 PM, Nick Coghlan a écrit : > Personally, I'd like to see the datetime module make an explicit > assumption that "all naive datetime objects are considered to be UTC", > with the interactions between naive and aware objects updated > accordingly I would absolutely love it if

Re: [Python-Dev] TZ-aware local time

On Tue, Jun 5, 2012 at 8:18 PM, Barry Warsaw wrote: >> I think stdlib should allow me to write >>a robust application that knows that some naive datetime objects >>correspond to two points in time and some correspond to none. > > Really?  Why would naive datetimes know that?  I would expect that a

Re: [Python-Dev] TZ-aware local time

On Wed, Jun 6, 2012 at 10:18 AM, Barry Warsaw wrote: > On Jun 05, 2012, at 07:41 PM, Alexander Belopolsky wrote: > >>The second feature has its uses.  If I want wake up at 7 AM every >>weekday, I don't want my alarm clock ask me whether I mean standard or >>daylight saving time, but if I attempt t

Re: [Python-Dev] [Python-checkins] peps: Add PEP 422: Dynamic Class Decorators

On 06/05/2012 07:38 PM, Nick Coghlan wrote: > On Wed, Jun 6, 2012 at 9:06 AM, PJ Eby wrote: >> >> >> On Tue, Jun 5, 2012 at 5:31 PM, Terry Reedy >> wrote: >>> >>> On 6/5/2012 2:26 PM, PJ Eby wrote: It's for symmetry and straightforward translation with stacked decorators, i.e. betwe

[Python-Dev] Updated PEP 362 (Function Signature Object)

On behalf of Yury, Larry, Jiwon (wherever he ended up), and myself, here is an updated version of PEP 362 to address Guido's earlier comments. Credit for most of the update should go to Yury with Larry also helping out. At this point I need a BDFAP and someone to do a code review: http://bugs.pyth

Re: [Python-Dev] TZ-aware local time

On Jun 05, 2012, at 07:41 PM, Alexander Belopolsky wrote: >The second feature has its uses. If I want wake up at 7 AM every >weekday, I don't want my alarm clock ask me whether I mean standard or >daylight saving time, but if I attempt to set it to 1:30 AM on the day >when 1:30 AM happens twice,

Re: [Python-Dev] Possible rough edges in Python 3 metaclasses (was Re: Language reference updated for metaclasses)

On Wed, Jun 6, 2012 at 2:00 AM, Joao S. O. Bueno wrote: > On 5 June 2012 09:24, Nick Coghlan wrote: > >> >> PEP written and posted: http://www.python.org/dev/peps/pep-0422/ >> More toy examples here: >> https://bitbucket.org/ncoghlan/misc/src/default/pep422.py >> >> Yes, it means requiring the us

Re: [Python-Dev] Possible rough edges in Python 3 metaclasses (was Re: Language reference updated for metaclasses)

On Wed, Jun 6, 2012 at 1:28 AM, PJ Eby wrote: > IOW, my motivation for saying, "hey, can't I just use this nice hook here" > was to avoid asking for a *new* feature, if there weren't enough other > people interested in a decoration protocol of this sort. > > That is, I was trying to NOT make anybo

Re: [Python-Dev] TZ-aware local time

On Tue, Jun 5, 2012 at 6:49 PM, Guido van Rossum wrote: >> The problem is again the DST ambiguity.  One day a year, datetime(y, >> m, d, 1, 30, tzinfo=Local) represents two different times and another >> day it represents no valid time.  Many applications can ignore this >> problem but stdlib shou

Re: [Python-Dev] [Python-checkins] peps: Add PEP 422: Dynamic Class Decorators

On Wed, Jun 6, 2012 at 9:06 AM, PJ Eby wrote: > > > On Tue, Jun 5, 2012 at 5:31 PM, Terry Reedy wrote: >> >> On 6/5/2012 2:26 PM, PJ Eby wrote: >>> It's for symmetry and straightforward translation with stacked >>> decorators, i.e. between: >>> >>> @deco1 >>> @deco2 >>> [declaration] >>> >>> and

Re: [Python-Dev] [Python-checkins] peps: Add PEP 422: Dynamic Class Decorators

PJ Eby wrote: At the least, if they're not going to be in decorator order, the member shouldn't be called "__decorators__". ;-) Obviously it should be called __srotaroced__. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.pyth

Re: [Python-Dev] [Python-checkins] peps: Add PEP 422: Dynamic Class Decorators

On Tue, Jun 5, 2012 at 5:31 PM, Terry Reedy wrote: > On 6/5/2012 2:26 PM, PJ Eby wrote: > >> On Tue, Jun 5, 2012 at 12:42 PM, Terry Reedy > > wrote: >> > > I think you should just store the decorators in the correct order of >> use >>+__decorators__ = [dec

Re: [Python-Dev] TZ-aware local time

On Tue, Jun 5, 2012 at 3:33 PM, Alexander Belopolsky wrote: > On Tue, Jun 5, 2012 at 6:07 PM, Guido van Rossum wrote: >>> I've also been arguing against "local time" tzinfo >> >> Why? I don't see your argumentation against such a tzinfo in the bug > > See http://bugs.python.org/issue9063 . > > Th

Re: [Python-Dev] TZ-aware local time

On Tue, Jun 5, 2012 at 6:07 PM, Guido van Rossum wrote: >> I've also been arguing against "local time" tzinfo > > Why? I don't see your argumentation against such a tzinfo in the bug See http://bugs.python.org/issue9063 . The problem is again the DST ambiguity. One day a year, datetime(y, m, d,

Re: [Python-Dev] Issue 2736: datetimes and Unix timestamps

On Tue, Jun 5, 2012 at 5:48 PM, Terry Reedy wrote: > 3.3 enhancement or backported bugfix? Please move this discussion to the tracker: http://bugs.python.org/issue15006 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/lis

Re: [Python-Dev] TZ-aware local time

On Tue, Jun 5, 2012 at 11:29 AM, Alexander Belopolsky wrote: > Changing subject to reflect a change of topic. > > On Tue, Jun 5, 2012 at 2:19 PM, Guido van Rossum wrote: >> .. Although if we ever get that "local time" tzinfo >> object, we may regret it. So I propose to launch without it and see i

Re: [Python-Dev] Issue 2736: datetimes and Unix timestamps

On 6/5/2012 3:17 PM, Guido van Rossum wrote: On Tue, Jun 5, 2012 at 12:15 PM, Alexander Belopolsky wrote: On Tue, Jun 5, 2012 at 3:01 PM, Antoine Pitrou wrote: You could say the same about equally "confusing" results, yet equality never raises TypeError (except between datetime instances):

Re: [Python-Dev] Cross-compiling python and PyQt

On 6/5/2012 4:24 PM, Tarek Sheasha wrote: 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

Re: [Python-Dev] [Python-checkins] peps: Add PEP 422: Dynamic Class Decorators

On 6/5/2012 2:26 PM, PJ Eby wrote: On Tue, Jun 5, 2012 at 12:42 PM, Terry Reedy mailto:tjre...@udel.edu>> wrote: I think you should just store the decorators in the correct order of use +__decorators__ = [deco1, deco2] and avoid the nonsense (time-waste) of making an indire

Re: [Python-Dev] [Python-checkins] peps: Add PEP 422: Dynamic Class Decorators

Terry Reedy dixit (2012-06-05, 12:42): > On 6/5/2012 8:09 AM, nick.coghlan wrote: > > > Add PEP 422: Dynamic Class Decorators [snip] > >+So too will the following be roughly equivalent (aside from inheritance):: > >+ > >+class C: > >+__decorators__ = [deco2, deco1] > > I think you

Re: [Python-Dev] Issue 2736: datetimes and Unix timestamps

Just to correct a misapprehension seen in this thread: there are still plenty of closed systems on the planet where every machine is set to UTC so that "local" time is UTC regardless of where the machine is physically located. You just won't hear about many of those systems if you're not working on

Re: [Python-Dev] Issue 2736: datetimes and Unix timestamps

Good point. On Tue, Jun 5, 2012 at 12:17 PM, Guido van Rossum wrote: > On Tue, Jun 5, 2012 at 12:15 PM, Alexander Belopolsky > wrote: >> On Tue, Jun 5, 2012 at 3:01 PM, Antoine Pitrou wrote: >>> You could say the same about equally "confusing" results, yet equality never >>> raises TypeError (e

[Python-Dev] Cross-compiling python and PyQt

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

Re: [Python-Dev] Issue 2736: datetimes and Unix timestamps

On Tue, Jun 5, 2012 at 12:15 PM, Alexander Belopolsky wrote: > On Tue, Jun 5, 2012 at 3:01 PM, Antoine Pitrou wrote: >> You could say the same about equally "confusing" results, yet equality never >> raises TypeError (except between datetime instances): >> > () == [] >> False > > And even clo

Re: [Python-Dev] Issue 2736: datetimes and Unix timestamps

On Tue, Jun 5, 2012 at 3:01 PM, Antoine Pitrou wrote: > You could say the same about equally "confusing" results, yet equality never > raises TypeError (except between datetime instances): > () == [] > False And even closer to home, >>> date(2012,6,1) == datetime(2012,6,1) False I agree, e

Re: [Python-Dev] Issue 2736: datetimes and Unix timestamps

Le 05/06/2012 20:37, Alexandre Zani a écrit : This is nice when your datetime objects are freshly created. It is not so nice when some of them already exist e.g. in a database (using an ORM layer). Mixing naive and aware datetimes is currently a catastrophe, since even basic operations such as e

Re: [Python-Dev] Issue 2736: datetimes and Unix timestamps

On Tue, Jun 5, 2012 at 11:26 AM, Antoine Pitrou wrote: > Le 05/06/2012 19:21, Alexander Belopolsky a écrit : > >> with timezone.utc added to datetime module >> already the cost of supplying tzinfo to UTC datetime objects is low. > > > This is nice when your datetime objects are freshly created. It

Re: [Python-Dev] Issue 2736: datetimes and Unix timestamps

Le 05/06/2012 19:21, Alexander Belopolsky a écrit : with timezone.utc added to datetime module already the cost of supplying tzinfo to UTC datetime objects is low. This is nice when your datetime objects are freshly created. It is not so nice when some of them already exist e.g. in a database

[Python-Dev] TZ-aware local time

Changing subject to reflect a change of topic. On Tue, Jun 5, 2012 at 2:19 PM, Guido van Rossum wrote: > .. Although if we ever get that "local time" tzinfo > object, we may regret it. So I propose to launch without it and see if > people object. There simply isn't a way to roundtrip for times th

Re: [Python-Dev] [Python-checkins] peps: Add PEP 422: Dynamic Class Decorators

On Tue, Jun 5, 2012 at 12:42 PM, Terry Reedy wrote: > 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 th

Re: [Python-Dev] Issue 2736: datetimes and Unix timestamps

On Tue, Jun 5, 2012 at 11:21 AM, Alexander Belopolsky wrote: > On Tue, Jun 5, 2012 at 1:41 PM, Guido van Rossum wrote: >> Maybe you need to get out more. :-) This is how datetime is >> represented in App Engine's datastore: >> https://developers.google.com/appengine/docs/python/datastore/typesand

Re: [Python-Dev] Issue 2736: datetimes and Unix timestamps

On Tue, Jun 5, 2012 at 1:41 PM, Guido van Rossum wrote: > Maybe you need to get out more. :-) This is how datetime is > represented in App Engine's datastore: > https://developers.google.com/appengine/docs/python/datastore/typesandpropertyclasses#DateTimeProperty > (Note: These docs are unclear ab

Re: [Python-Dev] Issue 2736: datetimes and Unix timestamps

On Tue, Jun 5, 2012 at 11:14 AM, Alexander Belopolsky wrote: > On Tue, Jun 5, 2012 at 1:41 PM, Guido van Rossum wrote: >> What do they want to set the dst flag for? > > To shift the responsibility to deal with the DST ambiguity to the > user.   This is what POSIX mktime with varying degree of suc

Re: [Python-Dev] Issue 2736: datetimes and Unix timestamps

On Tue, Jun 5, 2012 at 1:41 PM, Guido van Rossum wrote: > What do they want to set the dst flag for? To shift the responsibility to deal with the DST ambiguity to the user. This is what POSIX mktime with varying degree of success. > I think I am advocating for the former but without the dst fl

Re: [Python-Dev] [Python-checkins] peps: Add PEP 422: Dynamic Class Decorators

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

Re: [Python-Dev] Issue 2736: datetimes and Unix timestamps

On Tue, Jun 5, 2012 at 10:21 AM, Alexander Belopolsky wrote: > On Tue, Jun 5, 2012 at 9:45 AM, Guido van Rossum wrote: >> TZ-less datetimes aren't going away and have >> plenty of use in contexts where the tz is either universally known or >> irrelevant. > > I agree, but in these contexts naive d

Re: [Python-Dev] Issue 2736: datetimes and Unix timestamps

On Tue, Jun 5, 2012 at 9:45 AM, Guido van Rossum wrote: > TZ-less datetimes aren't going away and have > plenty of use in contexts where the tz is either universally known or > irrelevant. I agree, but in these contexts naive datetime objects almost always represent local time in some "universall

Re: [Python-Dev] what is happening with the regex module going into Python 3.3?

On 05/06/2012 03:40, Terry Reedy wrote: On 6/4/2012 9:22 PM, MRAB wrote: I'm not planning any further changes to regex. I think it already has enough features... Do you have any idea where regex + Python stands in regard to Unicode TR18 support levels? http://unicode.org/reports/tr18/ While

Re: [Python-Dev] Possible rough edges in Python 3 metaclasses (was Re: Language reference updated for metaclasses)

On 5 June 2012 09:24, Nick Coghlan wrote: > > PEP written and posted: http://www.python.org/dev/peps/pep-0422/ > More toy examples here: > https://bitbucket.org/ncoghlan/misc/src/default/pep422.py > > Yes, it means requiring the use of a specific metaclass in 3.2 (either > directly or via inherit

Re: [Python-Dev] Possible rough edges in Python 3 metaclasses (was Re: Language reference updated for metaclasses)

On Tue, Jun 5, 2012 at 3:53 AM, Nick Coghlan wrote: > Please don't try to coerce everyone else into supporting such an ugly > hack by abusing an implementation detail. Whoa, whoa there. Again with the FUD. Sorry if I gave the impression that I'm about to unleash the monkeypatching hordes tomo

Re: [Python-Dev] Issue 2736: datetimes and Unix timestamps

On Tue, Jun 5, 2012 at 5:07 PM, Guido van Rossum wrote: > In fact, we might go further and define fromtimestamp() to do the same > thing. Then the only difference between the two would be what timezone > they use if there is *no* tzinfo. That's fine with me. Yeah, that sounds good. Cheers, Dirk

Re: [Python-Dev] Issue 2736: datetimes and Unix timestamps

On Tue, Jun 5, 2012 at 7:19 AM, Dirkjan Ochtman wrote: > On Tue, Jun 5, 2012 at 3:45 PM, Guido van Rossum wrote: >> For datetimes with tzinfo, dt.totimestamp() should return (dt - >> epoch).total_seconds() where epoch is >> datetime.datetime.fromtimestamp(0, datetime.timezone.utc); for >> timezon

Re: [Python-Dev] Issue 2736: datetimes and Unix timestamps

On Tue, Jun 5, 2012 at 3:45 PM, Guido van Rossum wrote: > For datetimes with tzinfo, dt.totimestamp() should return (dt - > epoch).total_seconds() where epoch is > datetime.datetime.fromtimestamp(0, datetime.timezone.utc); for > timezones without tzinfo, a similar calculation should be performed >

Re: [Python-Dev] Issue 2736: datetimes and Unix timestamps

On Mon, Jun 4, 2012 at 5:51 PM, Alexander Belopolsky wrote: > On Mon, Jun 4, 2012 at 5:25 PM, Guido van Rossum wrote: > .. >> But I don't know what ticks() is supposed to do. > > """ > .ticks(offset=0.0,dst=-1) > > Returns a float representing the instances value in ticks (see above). > > The con

Re: [Python-Dev] Possible rough edges in Python 3 metaclasses (was Re: Language reference updated for metaclasses)

On Tue, Jun 5, 2012 at 10:37 PM, Xavier Morel wrote: > On 5 juin 2012, at 14:24, Nick Coghlan wrote: >>> Metaclasses *do* have a problem with composition and lexical >>> decorators don't play nicely with inheritance, but a dynamic decorator >>> system modelled to some degree on the old __metaclas

Re: [Python-Dev] Possible rough edges in Python 3 metaclasses (was Re: Language reference updated for metaclasses)

On 5 juin 2012, at 14:24, Nick Coghlan wrote: > On Tue, Jun 5, 2012 at 8:25 PM, Nick Coghlan wrote: >> On Tue, Jun 5, 2012 at 7:11 PM, Michael Foord >> wrote: >>> >>> On 5 Jun 2012, at 08:53, Nick Coghlan wrote: >>> [snip...] Now, one minor annoyance with current class decora

Re: [Python-Dev] Possible rough edges in Python 3 metaclasses (was Re: Language reference updated for metaclasses)

On Tue, Jun 5, 2012 at 8:25 PM, Nick Coghlan wrote: > On Tue, Jun 5, 2012 at 7:11 PM, Michael Foord > wrote: >> >> On 5 Jun 2012, at 08:53, Nick Coghlan wrote: >> >>> [snip...] >>> >>> Now, one minor annoyance with current class decorators is that they're >>> *not* inherited. This is sometimes w

Re: [Python-Dev] Possible rough edges in Python 3 metaclasses (was Re: Language reference updated for metaclasses)

On 4 June 2012 21:10, PJ Eby wrote: >> > 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. >> > PJ, it maybe just me, but what does this code do that can't be done at the metaclass' __new__

Re: [Python-Dev] Issue #11022: locale.getpreferredencoding() must not set temporary LC_CTYPE

> Fine with me. Ok, done with changeset 2587328c7c9c. > So in theory, your change should have no effect, unless somebody has > modified some environment variables. Changing TextIOWrapper to call locale.getpreferredlocale(False) instead of getpreferredlocale() has these two effects: 1) without t

Re: [Python-Dev] [Python-checkins] cpython: Fix potential NameError in multiprocessing.Condition.wait()

On 05/06/2012 6:59am, Eli Bendersky wrote: Can you add a testcase for this? ... OK. BTW, I should have written UnboundLocalError not NameError: >>> import multiprocessing as mp [81047 refs] >>> c = mp.Condition() [88148 refs] >>> with mp.Condition() as c: c.wait() ... Traceback (most recent

Re: [Python-Dev] Possible rough edges in Python 3 metaclasses (was Re: Language reference updated for metaclasses)

On Tue, Jun 5, 2012 at 7:11 PM, Michael Foord wrote: > > On 5 Jun 2012, at 08:53, Nick Coghlan wrote: > >> [snip...] >> >> Now, one minor annoyance with current class decorators is that they're >> *not* inherited. This is sometimes what you want, but sometimes you >> would prefer to automatically

Re: [Python-Dev] Language reference updated for metaclasses

On Tue, Jun 5, 2012 at 6:34 PM, Mark Shannon wrote: > In this example the metaclass (ie the class of C) is type (C is int), > even though the declared metaclass is 'silly'. > > I assume it is too late to change the name of the 'metaclass' keyword to > 'factory', but we could use that terminology i

Re: [Python-Dev] Possible rough edges in Python 3 metaclasses (was Re: Language reference updated for metaclasses)

On 5 Jun 2012, at 08:53, Nick Coghlan wrote: > [snip...] > > Now, one minor annoyance with current class decorators is that they're > *not* inherited. This is sometimes what you want, but sometimes you > would prefer to automatically decorate all subclasses as well. > Currently, that means writi

Re: [Python-Dev] Issue 2736: datetimes and Unix timestamps

On 04.06.12 13:19, Dirkjan Ochtman wrote: I recently opened issue14908. At work, I have to do a bunch of things with dates, times and timezones, and sometimes Unix timestamps are also involved (largely for easy compatibility with legacy APIs). I find the relative obscurity when converting dateti

Re: [Python-Dev] Language reference updated for metaclasses

On 5 Jun 2012, at 09:34, Mark Shannon wrote: > Steven D'Aprano wrote: >> On Tue, Jun 05, 2012 at 10:20:58AM +0300, Eli Bendersky wrote: >>> Still, instance of type()" is a bit too cryptic for mere mortals, IMHO. >> I think that if somebody finds "instance of type" too cryptic, they won't >> have

Re: [Python-Dev] Language reference updated for metaclasses

Steven D'Aprano wrote: On Tue, Jun 05, 2012 at 10:20:58AM +0300, Eli Bendersky wrote: Still, instance of type()" is a bit too cryptic for mere mortals, IMHO. I think that if somebody finds "instance of type" too cryptic, they won't have any chance at all to understand metaclasses. Personal

Re: [Python-Dev] Language reference updated for metaclasses

On Tue, Jun 05, 2012 at 10:20:58AM +0300, Eli Bendersky wrote: > Still, instance of type()" is a bit too cryptic for mere mortals, IMHO. I think that if somebody finds "instance of type" too cryptic, they won't have any chance at all to understand metaclasses. Personally, I think there is a lot

Re: [Python-Dev] Possible rough edges in Python 3 metaclasses (was Re: Language reference updated for metaclasses)

On Tue, Jun 5, 2012 at 2:03 PM, PJ Eby wrote: > On Mon, Jun 4, 2012 at 10:43 PM, Eric Snow > wrote: >> >> On Mon, Jun 4, 2012 at 6:10 PM, PJ Eby wrote: >> > I mean that class-level __metaclass__ is no longer supported as of PEP >> > 3115, >> > so I can't use that as a way to non-invasively obtai

Re: [Python-Dev] Language reference updated for metaclasses

On Tue, Jun 5, 2012 at 10:18 AM, Nick Coghlan wrote: > On Tue, Jun 5, 2012 at 1:24 PM, Eli Bendersky wrote: >> >> "if an explicit metaclass is given and it is not an instance of >> type(), then it is used directly as the metaclass" >> >> Could you elaborate on this point? Would it perhaps be clea

Re: [Python-Dev] Language reference updated for metaclasses

On Tue, Jun 5, 2012 at 1:24 PM, Eli Bendersky wrote: > > "if an explicit metaclass is given and it is not an instance of > type(), then it is used directly as the metaclass" > > Could you elaborate on this point? Would it perhaps be clearer to say > "if an explicit metaclass is given and it is not