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

[Nick Coghlan]

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 a class"?

Unfortunately, the term "a class" is slightly ambiguous. "cls is a
class" can mean either "isinstance(cls, type)" or it can be shorthand
for "cls is a user-defined class (i.e. not a builtin type)".

I'll likely rephrase that section of the docs based on the current
discussion with PJE, though.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Eli Bendersky]

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 clearer to say
>> "if an explicit metaclass is given and it is not a class"?
>
> Unfortunately, the term "a class" is slightly ambiguous. "cls is a
> class" can mean either "isinstance(cls, type)" or it can be shorthand
> for "cls is a user-defined class (i.e. not a builtin type)".
>

Yes, confusing it is
(http://eli.thegreenplace.net/2012/03/30/python-objects-types-classes-and-instances-a-glossary/)

Still, instance of type()" is a bit too cryptic for mere mortals, IMHO.

Eli
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Nick Coghlan]

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 obtain the enclosing
>> > class at
>> > class creation time.
>>
>> Depends on what you mean by non-invasive:
>
>
> Non-invasive meaning, "not requiring the user of the descriptor or decorator
> to make extra declarations-at-a-distance, especially ones that increase the
> likelihood of clashing machinery if multiple frameworks require the same
> functionality."  ;-)
>
> That means class decorators, mixins, and explicit metaclasses don't work.
> The class decorator adds yak shaving, and the others lead to functional
> clashing.
>
> Currently, my choices for porting these libraries (and their dependents) to
> Python 3 are (in roughly descending order of preference):
>
> 1. Replace __builtins__.__build_class__ and hope PyPy et al follow CPython's
> lead,

Please don't try to coerce everyone else into supporting such an ugly
hack by abusing an implementation detail. There's a reason
types.new_class() uses a different signature. Deliberately attempting
to present python-dev with a fait accompli instead of building
consensus for officially adding a feature to the language is *not
cool*.

> I would prefer to have an option 4 or 5 (where there's a standard Python way
> to get a class creation callback from a class body), but #1 is honestly the
> most attractive at the moment, as I might only need to implement it in *one*
> library, with no changes to clients, including people who've built stuff
> based on that library or any of its clients, recursively.  (#2 would also do
> it, but I was *really* hoping to get rid of that hack in Python 3.)

Please be patient and let us work out a solution that has at least
some level of consensus associated with it, rather than running off
and doing your own thing.

As I understand it, what you currently do is, from a running
decorator, walk the stack with sys._getframes() and insert a
"__metaclass__" value into the class namespace.

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 writing a custom metaclass to automatically
apply the decorators. This has all the problems you have noted with
composability.

It seems then, that a potentially clean solution may be found by
adding a *dynamic* class decoration hook. As a quick sketch of such a
scheme, add the following step to the class creation process (between
the current class creation process, but before the execution of
lexical decorators):

for mro_cls in cls.mro():
decorators = mro_cls.__dict__.get("__decorators__", ())
for deco in reversed(decorators):
cls = deco(cls)

Would such a dynamic class decoration hook meet your use case? Such a
hook has use cases (specifically involving decorator inheritance) that
*don't* require the use of sys._getframes(), so is far more likely to
achieve the necessary level of consensus.

As a specific example, the unittest module could use it to provide
test parameterisation without needing a custom metaclass.


> Given these choices, I hope it's more understandable why I'd want to lobby
> for at least documenting __build_class__ and its replaceability, and perhaps
> encouraging other Python 3 implementations to offer the same feature.

You've jumped to a hackish solution instead of taking a step back and
trying to think of a potentially elegant addition to the language that
is more composable and doesn't require modification of process global
state. You complain that metaclasses are hard to compose, and your
"solution" is to monkeypatch a deliberately undocumented builtin?

Regards,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Steven D'Aprano]

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 confusing about metaclasses, but the 
idea that classes are instances (objects) is not one of them.



-- 
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Mark Shannon]

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.


Personally, I think there is a lot confusing about metaclasses, but the 
idea that classes are instances (objects) is not one of them.




One thing that *is* confusing is that the metaclass parameter in class 
creation is not the metaclass (class of the class), but the class 
factory. For example:


def silly(*args):
print(*args)
return int

class C(metaclass=silly):
def m(self): pass

C () {'m': , '__qualname__': 'C', 
'__module__': '__main__'}


print(C)
int

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 in the docs.


Cheers,
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Michael Foord]

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 any chance at all to understand metaclasses.
>> Personally, I think there is a lot confusing about metaclasses, but the idea 
>> that classes are instances (objects) is not one of them.
> 
> One thing that *is* confusing is that the metaclass parameter in class 
> creation is not the metaclass (class of the class), but the class factory. 
> For example:
> 
> def silly(*args):
>print(*args)
>return int
> 
> class C(metaclass=silly):
>def m(self): pass
> 
> C () {'m': , '__qualname__': 'C', '__module__': 
> '__main__'}
> 
> print(C)
> int
> 
> 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 in the docs.


Well, the same was always true in Python 2 as well - __metaclass__ could be a 
function that was identically "silly". The real "metaclass" (type of the class) 
is whatever you use to construct the class. 

Michael

> 
> Cheers,
> Mark
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk
> 


--
http://www.voidspace.org.uk/


May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing 
http://www.sqlite.org/different.html





___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Walter Dörwald]

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 datetimes to timestamps
rather painful; IMO it should be possible to do everything I need
straight from the datetime module objects, instead of having to
involve the time or calendar modules.

Anyway, I was pointed to issue 2736, which seems to have got a lot of
discouraged core contributors (Victor, Antoine, David and Ka-Ping, to
name just a few) up against Alexander (the datetime maintainer,
AFAIK).


Also see: http://bugs.python.org/issue665194 (datetime-RFC2822 
roundtripping)



It seems like a fairly straightforward case of practicality
over purity: Alexander argues that there are "easy" one-liners to do
things like datetime.totimestamp(),


I don't want one-liners, I want one-callers! ;)


but most other people seem to not
find them so easy. They've since been added to the documentation at
least, but I would like to see if there is consensus on python-dev
that adding a little more timestamp support to datetime objects would
make sense.


Servus,
   Walter
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Michael Foord]

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 writing a custom metaclass to automatically
> apply the decorators. This has all the problems you have noted with
> composability.
> 
> It seems then, that a potentially clean solution may be found by
> adding a *dynamic* class decoration hook. As a quick sketch of such a
> scheme, add the following step to the class creation process (between
> the current class creation process, but before the execution of
> lexical decorators):
> 
>for mro_cls in cls.mro():
>decorators = mro_cls.__dict__.get("__decorators__", ())
>for deco in reversed(decorators):
>cls = deco(cls)
> 
> Would such a dynamic class decoration hook meet your use case? Such a
> hook has use cases (specifically involving decorator inheritance) that
> *don't* require the use of sys._getframes(), so is far more likely to
> achieve the necessary level of consensus.
> 
> As a specific example, the unittest module could use it to provide
> test parameterisation without needing a custom metaclass.


Heh, you're effectively restoring the old Python 2 metaclass machinery with a 
slightly-less-esoteric mechanism. That aside I really like it. 

Michael


--
http://www.voidspace.org.uk/


May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing 
http://www.sqlite.org/different.html





___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Nick Coghlan]

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 in the docs.

"factory" is also wrong (since a more derived metaclass from a base
class may be used instead). "metaclass_hint" or "requested_metaclass"
would be more accurate names - as in Python 2, the value provided in
the class definition is only one input to the algorithm that
determines the metaclass (which is now correctly described in the
language reference), rather than a simple factory function or direct
specification of __class__.

That slightly blurry terminology isn't new in Python 3 though, it's
been around for pretty much as long as Python has supported
metaclasses.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Nick Coghlan]

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 decorate all subclasses as well.
>> Currently, that means writing a custom metaclass to automatically
>> apply the decorators. This has all the problems you have noted with
>> composability.
>>
>> It seems then, that a potentially clean solution may be found by
>> adding a *dynamic* class decoration hook. As a quick sketch of such a
>> scheme, add the following step to the class creation process (between
>> the current class creation process, but before the execution of
>> lexical decorators):
>>
>>    for mro_cls in cls.mro():
>>        decorators = mro_cls.__dict__.get("__decorators__", ())
>>        for deco in reversed(decorators):
>>            cls = deco(cls)
>>
>> Would such a dynamic class decoration hook meet your use case? Such a
>> hook has use cases (specifically involving decorator inheritance) that
>> *don't* require the use of sys._getframes(), so is far more likely to
>> achieve the necessary level of consensus.
>>
>> As a specific example, the unittest module could use it to provide
>> test parameterisation without needing a custom metaclass.
>
>
> Heh, you're effectively restoring the old Python 2 metaclass machinery with a 
> slightly-less-esoteric mechanism. That aside I really like it.

Yup, writing a PEP now - I'm mostly interested in the inheritance
aspects, but providing PJE with a way to get the effect he wants
without monkeypatching undocumented builtins at runtime and
effectively forking CPython's runtime behaviour is a useful bonus.

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 __metaclass__ mechanics
could fill the gap nicely.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[shibturn]

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 call last):
  File "C:\Repos\cpython-dirty\lib\multiprocessing\synchronize.py", 
line 219, in wait

ret = self._wait_semaphore.acquire(True, timeout)
KeyboardInterrupt

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "", line 1, in 
  File "C:\Repos\cpython-dirty\lib\multiprocessing\synchronize.py", 
line 227, in wait

return ret
UnboundLocalError: local variable 'ret' referenced before assignment
[88218 refs]

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Victor Stinner]

> 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 the patch, setting LC_ALL, LC_CTYPE or LANG environment
variable changes the encoding used by TextIOWrapper.

2) with the patch, setting LC_CTYPE (with locale.setlocale) changes
the the encoding used by TextIOWrapper.

IMO (2) is less surprising than (1) For example, it is the expected
behaviour of the reporter of the issue #11022.

In practice, it should not change anything for most people.

Victor
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Joao S. O. Bueno]

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__ method?

You might have to rewrite some method-decorators, so that they just
mark a method at class body execution time, and then, whatever the
decorator used to do at this time, would be done at meta's __new__ - I
have this working in some code (and in Python 2 already).

   js
  -><-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Nick Coghlan]

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 what you want, but sometimes you
>>> would prefer to automatically decorate all subclasses as well.
>>> Currently, that means writing a custom metaclass to automatically
>>> apply the decorators. This has all the problems you have noted with
>>> composability.
>>>
>>> It seems then, that a potentially clean solution may be found by
>>> adding a *dynamic* class decoration hook. As a quick sketch of such a
>>> scheme, add the following step to the class creation process (between
>>> the current class creation process, but before the execution of
>>> lexical decorators):
>>>
>>>    for mro_cls in cls.mro():
>>>        decorators = mro_cls.__dict__.get("__decorators__", ())
>>>        for deco in reversed(decorators):
>>>            cls = deco(cls)
>>>
>>> Would such a dynamic class decoration hook meet your use case? Such a
>>> hook has use cases (specifically involving decorator inheritance) that
>>> *don't* require the use of sys._getframes(), so is far more likely to
>>> achieve the necessary level of consensus.
>>>
>>> As a specific example, the unittest module could use it to provide
>>> test parameterisation without needing a custom metaclass.
>>
>>
>> Heh, you're effectively restoring the old Python 2 metaclass machinery with 
>> a slightly-less-esoteric mechanism. That aside I really like it.
>
> Yup, writing a PEP now - I'm mostly interested in the inheritance
> aspects, but providing PJE with a way to get the effect he wants
> without monkeypatching undocumented builtins at runtime and
> effectively forking CPython's runtime behaviour is a useful bonus.
>
> 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 __metaclass__ mechanics
> could fill the gap nicely.

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 inheritance), but monkeypatching an undocumented
builtin is going to pathological lengths just to avoid requiring that
people explicitly interoperate with your particular metaclass
mechanisms.

Regards,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Xavier Morel]

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 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 writing a custom metaclass to automatically
 apply the decorators. This has all the problems you have noted with
 composability.
 
 It seems then, that a potentially clean solution may be found by
 adding a *dynamic* class decoration hook. As a quick sketch of such a
 scheme, add the following step to the class creation process (between
 the current class creation process, but before the execution of
 lexical decorators):
 
for mro_cls in cls.mro():
decorators = mro_cls.__dict__.get("__decorators__", ())
for deco in reversed(decorators):
cls = deco(cls)
 
 Would such a dynamic class decoration hook meet your use case? Such a
 hook has use cases (specifically involving decorator inheritance) that
 *don't* require the use of sys._getframes(), so is far more likely to
 achieve the necessary level of consensus.
 
 As a specific example, the unittest module could use it to provide
 test parameterisation without needing a custom metaclass.
>>> 
>>> 
>>> Heh, you're effectively restoring the old Python 2 metaclass machinery with 
>>> a slightly-less-esoteric mechanism. That aside I really like it.
>> 
>> Yup, writing a PEP now - I'm mostly interested in the inheritance
>> aspects, but providing PJE with a way to get the effect he wants
>> without monkeypatching undocumented builtins at runtime and
>> effectively forking CPython's runtime behaviour is a useful bonus.
>> 
>> 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 __metaclass__ mechanics
>> could fill the gap nicely.
> 
> 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
> 

Does it really make sense to meld decorators and inheritance so? With this, 
class "decorators" become way more than mere decorators and start straying 
quite far away from their function-based counterparts (which are not 
"inherited" when overriding methods but are statically applied instead)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Nick Coghlan]

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 __metaclass__ mechanics
>>> could fill the gap nicely.
>>
>> 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
>>
>
> Does it really make sense to meld decorators and inheritance so? With this, 
> class "decorators" become way more than mere decorators and start straying 
> quite far away from their function-based counterparts (which are not 
> "inherited" when overriding methods but are statically applied instead)

Lexical class decorators won't go away, and will still only apply to
the associated class definition.

There are a couple of key points about class decorators that make them
a *lot* easier to reason about than metaclasses:

1. They have a very simple expected API: "class in, class out"
2. As a result of 1, they can typically be pipelined easily: in the
absence of decorator abuse, you can take the output of one class
decorator and feed it to the input of the next one

Metaclasses live at a different level of complexity all together - in
order to make use of them, you need to have some understanding of how
a name, a sequence of bases and a namespace can be combined to create
a class object. Further, because it's a transformative API (name,
bases, ns -> class object), combining them requires a lot more care
(generally involving inheriting from type and making appropriate use
of super() calls).

However, even when all you really want is to decorate the class after
it has been created, defining a metaclass is currently still necessary
if you also want to be notified when new subclasses are defined. This
PEP proposes that those two characteristics be split: if all you want
is inheritance of decorators, then dynamic decorators are a much
simpler, more multiple inheritance friendly solution than using a
custom metaclass, leave full metaclass definitions for cases where you
really *do* want almost complete control over the class creation
process.

That said, actively discouraging PJE from his current scheme that
involves monkeypatching __build_class__ and publishing "Python 3 (with
monkeypatched undocumented builtins) compatible" packages on PyPI is
definitely a key motivation in putting this proposal together.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Guido van Rossum]

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 conversion routine assumes that the stored date/time value is
> given in local time.
>
> The given value for dst is used by the conversion (0 = DST off, 1 =
> DST on, -1 = unkown) and offset is subtracted from the resulting
> value.
>
> The method raises a RangeErrorexception if the objects value does not
> fit into the system's ticks range.
>
> Note:On some platforms the C lib's mktime() function that this method
> uses does not allow setting DST to an arbitrary value. The module
> checks for this and raises a SystemError in case setting DST to 0 or 1
> does not result in valid results.
> """ mxDateTime Documentation,
> 

I agree that would be a step backward.

>> I am assuming we
>> would create totimestamp() and utctotimestamp() that mirror
>> fromtimestamp() and utcfromtimestamp().
>
> First, with the introduction of timezone.utc, the use of utc...
> methods should be discouraged.

Speak for yourself. TZ-less datetimes aren't going away and have
plenty of use in contexts where the tz is either universally known or
irrelevant.

> fromtimestamp(s,timezeone.utc) is better than utcfromtimestamp();
> now(timezeone.utc)  is better than utcnow(); and
> dt.astimezone(timezone.utc).timetuple() is better than dt.utctimetuple()

No, they are not better. They are simply different.

> The advantage of the first two is that they produce aware datetime
> instances.

Whether that really is an advantage is up to the user and the API they
are working with.

> The last example may appear more verbose, but in most
> applications, dt.astimezone(timezone.utc) is really what is needed.

So you think.

>> Since we trust the user with
>> the latter we should trust them with the former.

> This does not follow.  When you deal with non-monotonic functions,
> defining the inverse functions requires considerably more care than
> defining the original.  For example, defining sqrt(), requires
> choosing the positive root.  For arcsin(), you need to choose between
> infinitely many branches.   I don't think many users would appreciate
> a math library where sqrt() and arcsin() take an optional branch=
> argument, but mxDT's ticks() features this very design with its dst=
> flag.  Most users will ignore optional dst= and live with the
> resulting bugs.  We had several such bugs in stdlib and they went
> unnoticed for years.

That's why I don't recommend adding ticks(). But those math functions
*do* exist and we need their equivalent in the stdlib. Users will
have a *need* to convert their datetime objects (with or without
tzinfo) to POSIX timestamps, and the one-liners from the docs are too
hard to find and remember. While I agree that not every handy three
lines of code need to become a function in the standard library, the
reverse also doesn't follow: it just being three lines does not make
it a sin to add it to the stdlib if those three lines are particularly
hard to come up with.

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
assuming local time. The utctotimestamp() method should insist that dt
has no tzinfo and then do a similar calculation again assuming the
implied UTC timezone.

I think these definitions are both sufficiently unsurprising and
useful to add to the datetime module.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Dirkjan Ochtman]

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
> assuming local time. The utctotimestamp() method should insist that dt
> has no tzinfo and then do a similar calculation again assuming the
> implied UTC timezone.

It would be nice if utctotimestamp() also worked with datetimes that
have tzinfo set to UTC.

And while I don't think we really need it, if there are concerns that
some other epochs may be useful, we could add an optional epoch
argument.

Cheers,

Dirkjan
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Guido van Rossum]

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
>> timezones without tzinfo, a similar calculation should be performed
>> assuming local time. The utctotimestamp() method should insist that dt
>> has no tzinfo and then do a similar calculation again assuming the
>> implied UTC timezone.
>
> It would be nice if utctotimestamp() also worked with datetimes that
> have tzinfo set to UTC.

Hm, but utcfromtimestamp() never returns a datetime that has a tzinfo
(it doesn't take a tzinfo argument like fromtimestamp() does).

But if we want to do this, we should just say that utcfromtimestamp()
with a datetime that has a tzinfo honors the tzinfo, always.

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.

> And while I don't think we really need it, if there are concerns that
> some other epochs may be useful, we could add an optional epoch
> argument.

No, that's hypergeneralization. People working with other epochs can
write the three lines of code -- or they can add or substract a
constant that is the difference between *their* epoch and 1/1/1970.

Alternate epochs just aren't that common (and where they are, the
datetime module probably isn't what you want -- you're probably doing
calendrical calculations using some other calendar).

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Dirkjan Ochtman]

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,

Dirkjan
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[PJ Eby]

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 tomorrow or something.  I'm unlikely to begin serious Python 3
porting of the relevant libraries before 3.3 is released; the reason I'm
talking about this now is because there's currently Python-Dev discussion
regarding metaclasses, so it seemed like a good time to bring the subject
up, to see if there were any *good* solutions.

Just because my three existing options are, well, the only options if I
started porting today, doesn't mean I think they're the *only* options.  As
I said, an option 4 or 5 would be fantastic, and your new PEP 422 is
wonderful in that regard.  Thank you VERY much for putting that together, I
appreciate that very much.

(I just wish you hadn't felt forced or coerced to do it -- that was not my
intention *at all*!)

Frankly, a big part of my leaning towards the __build_class__ option was
that it's the *least work by Python implementors* (at least in terms of
coding) to get my use case met.  The reason I didn't write a PEP myself is
because I didn't want to load up Python with yet another protocol, when my
use case could be met by stuff that's already implemented in CPython.

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 anybody do a bunch of work on my behalf.
(Clearly, I wasn't successful in the attempt, but I should at least get
credit for trying.  ;-)



> 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 writing a custom metaclass to automatically
> apply the decorators. This has all the problems you have noted with
> composability.
>
> It seems then, that a potentially clean solution may be found by
> adding a *dynamic* class decoration hook. As a quick sketch of such a
> scheme, add the following step to the class creation process (between
> the current class creation process, but before the execution of
> lexical decorators):
>
>for mro_cls in cls.mro():
>decorators = mro_cls.__dict__.get("__decorators__", ())
>for deco in reversed(decorators):
>cls = deco(cls)
>
> Would such a dynamic class decoration hook meet your use case? Such a
> hook has use cases (specifically involving decorator inheritance) that
> *don't* require the use of sys._getframes(), so is far more likely to
> achieve the necessary level of consensus.
>

Absolutely.  The main challenge with it is that I would need stateful
decorators, so that they do nothing when called more than once; the
motivating use cases for me do not require actual decorator inheritance.
But I do have *other* stuff I'm currently using metaclasses for in 2.x,
that could probably be eliminated with PEP 422.  (For example, the #1
metaclass I use in 2.x is one that basically lets classes have
__class_new__ and __class_init__ methods: a rough equivalent to in-line
metaclasses or inheritable decorators!)

In general, implementing what's effectively inherited decoration is what
*most* metaclasses actually get used for, so PEP 422 is a big step forward
in that.

Sketching something to get a feel for the PEP...

def inheritable(*decos):
"""Wrap a class with inheritable decorators"""
def decorate(cls):
cls.__decorators__ =
list(decos)+list(cls.__dict__.get('__decorators__',()))
for deco in reversed(decos):
cls = deco(cls)
return cls

Hm.  There are a few interesting consequences of the PEP as written.
In-body decorators affect the __class__ closure (and thus super()), but
out-of-body decorators don't.  By me this is a good thing, but it is a bit
of complexity that needs mentioning.  Likewise, the need for inheritable
decorators to be idempotent, in case two base classes list the same
decorator.  (For my own use attribute/method use cases, I can just have
them remove themselves from the class's __decorators__ upon execution.)



 You complain that metaclasses are hard to compose, and your
> "solution" is to monkeypatch a deliberately undocumented builtin?
>

To be clear, what I specifically proposed (as I mentioned in an earlier
thread) was simply to patch __build_class__ in order to restore the missing
__metaclass__ hook.  (Which, incidentally, would make ALL code using
__metaclass__ cross-version compatible between 2.x and 3.x: a potentially
valuable thing in and of itself!)

As for metaclasses being hard to compose, PEP 422 is definitely a step in
the right direction.  (Automatic metaclass combining is about the o

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

[Joao S. O. Bueno]

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 inheritance), but monkeypatching an undocumented
> builtin is going to pathological lengths just to avoid requiring that
> people explicitly interoperate with your particular metaclass
> mechanisms.

When reading the PEP, I got the impression that having a
"__decorate__" method on "type", which would perform its thing, would
be not add magic exceptions, would be more explicit and more flexible
than having an extra step to be called between the metaclass execution
and decorator applying.

So, I think that settling for having the decorators applied - as
described in the PEP - in a __decorate__ method of the metaclass would
be nicer and cleaner.

   js
 -><-
>
> Regards,
> Nick.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/jsbueno%40python.org.br
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[MRAB]

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 most of the Tailored Support Level 3 strikes me as out of scope
for the stdlib, I can imagine getting requests for any other stuff not
already included.


It supports Basic Unicode Support (Level 1), plus default word
boundaries and \X (grapheme cluster).
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Alexander Belopolsky]

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 "universally known or irrelevant"
timezone.   I rarely see people use naive datetime objects to
represent UTC time and with timezone.utc added to datetime module
already the cost of supplying tzinfo to UTC datetime objects is low.

Based on tracker comments, I believe users ask for the following function:

def timestamp(self, dst=-1):
"Return POSIX timestamp as float"
if self.tzinfo is None:
return _time.mktime((self.year, self.month, self.day,
 self.hour, self.minute, self.second,
 -1, -1, dst)) + self.microsecond / 1e6
else:
return (self - _EPOCH).total_seconds()

You seem to advocate for

def utctimestamp(self):
return (self - _EPOCH).total_seconds()

in addition or instead of timestamp().  In mxDT, utctimestamp() is
called gmticks().

Is this an accurate summary?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Guido van Rossum]

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 datetime objects almost always
> represent local time in some "universally known or irrelevant"
> timezone.   I rarely see people use naive datetime objects to
> represent UTC time and with timezone.utc added to datetime module
> already the cost of supplying tzinfo to UTC datetime objects is low.

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 about whether a tzinfo attribute is
present. The code is clear that it isn't.)

> Based on tracker comments, I believe users ask for the following function:
>
>    def timestamp(self, dst=-1):
>        "Return POSIX timestamp as float"
>        if self.tzinfo is None:
>            return _time.mktime((self.year, self.month, self.day,
>                                 self.hour, self.minute, self.second,
>                                 -1, -1, dst)) + self.microsecond / 1e6
>        else:
>            return (self - _EPOCH).total_seconds()

What do they want to set the dst flag for?

> You seem to advocate for
>
>    def utctimestamp(self):
>            return (self - _EPOCH).total_seconds()

Not literally, because this would crash when self.tzinfo is None.

I think I am advocating for the former but without the dst flag.

> in addition or instead of timestamp().  In mxDT, utctimestamp() is
> called gmticks().
>
> Is this an accurate summary?



-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Terry Reedy]

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
+C = deco2(deco1(C))
+
+So too will the following be roughly equivalent (aside from inheritance)::
+
+class C:
+__decorators__ = [deco2, deco1]


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 indirect copy via 
list_iterator and reversing it each time the attribute is used.


If the list is constructed in reversed order, immediately reverse it.


+
+class C:
+pass
+C = deco2(deco1(C))


Terry Jan Reedy
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Alexander Belopolsky]

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 flag.

The cost of dst flag is low and most users will ignore it anyways, but
by providing it we will at least acknowledge the issue.  I don't care
much one way or another.

The remaining issue is the return type.  Most of the use cases that
have been brought up cast the timestamp to int as soon as it is
computed.   I recall a recent discussion about high-presision
timestamps, but don't recall the conclusion.  I guess we should offer
timestamp() returning float and let those who care about range or
precision write their own solution.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Guido van Rossum]

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 success.
>
>> I think I am advocating for the former but without the dst flag.
>
> The cost of dst flag is low and most users will ignore it anyways, but
> by providing it we will at least acknowledge the issue.  I don't care
> much one way or another.

Me neither, TBH. 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 that
fall in the DST->std transition, and I doubt that many users will want
to think about it (they'd have to store an extra bit with all their
datetime objects -- it would be better to get them to use tzinfo
objects instead...).

> The remaining issue is the return type.  Most of the use cases that
> have been brought up cast the timestamp to int as soon as it is
> computed.   I recall a recent discussion about high-presision
> timestamps, but don't recall the conclusion.  I guess we should offer
> timestamp() returning float and let those who care about range or
> precision write their own solution.

Python uses floats pretty much everywhere for posix timestamps. So let
it return a float.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Alexander Belopolsky]

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 about whether a tzinfo attribute is
> present. The code is clear that it isn't.)

>From the docs: "Some libraries use the TZ environment variable to
control the time zone applied to date-time values. App Engine sets
this environment variable to 'UTC'."  This means that  App Engine's
local timezone is UTC and strictly speaking this is not a counter
example to what I said.  Proposed mktime() based code will still work
in this case.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Guido van Rossum]

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/typesandpropertyclasses#DateTimeProperty
>> (Note: These docs are unclear about whether a tzinfo attribute is
>> present. The code is clear that it isn't.)
>
> From the docs: "Some libraries use the TZ environment variable to
> control the time zone applied to date-time values. App Engine sets
> this environment variable to 'UTC'."  This means that  App Engine's
> local timezone is UTC and strictly speaking this is not a counter
> example to what I said.  Proposed mktime() based code will still work
> in this case.

Fair enough. Perhaps unrelated do you think a tzinfo representing
"local time" can be built?

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[PJ Eby]

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 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
>> +C = deco2(deco1(C))
>> +
>> +So too will the following be roughly equivalent (aside from
>> inheritance)::
>> +
>> +class C:
>> +__decorators__ = [deco2, deco1]
>>
>
> 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 indirect copy via
> list_iterator and reversing it each time the attribute is used.
>

It's for symmetry and straightforward translation with stacked decorators,
i.e. between:

@deco1
@deco2
[declaration]

and __decorators__ = [deco1, deco2]

Doing it the other way now means a different order for people to remember;
there should be One Obvious Order for decorators, and the one we have now
is it.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] TZ-aware local time

[Alexander Belopolsky]

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 that
> fall in the DST->std transition, and I doubt that many users will want
> to think about it (they'd have to store an extra bit with all their
> datetime objects -- it would be better to get them to use tzinfo
> objects instead...).

I've also been arguing against "local time" tzinfo and my proposal was
to create a function that would produce TZ-aware local time with
tzinfo bound to a fixed-offset timezone.  In New York that would mean
EDT in the summer and EST in the winter.   This is what Unix date
utility does.

See http://bugs.python.org/issue9527 .
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Antoine Pitrou]

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 (using an ORM 
layer). Mixing naive and aware datetimes is currently a catastrophe, 
since even basic operations such as equality comparison fail with a 
TypeError (it must be pretty much the only type in the stdlib with such 
poisonous behaviour).


Regards

Antoine.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Alexandre Zani]

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 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 equality comparison fail with a TypeError (it
> must be pretty much the only type in the stdlib with such poisonous
> behaviour).

Comparing aware and naive datetime objects doesn't make much sense but
it's an easy mistake to make. I would say the TypeError is a sensible
way to warn you while simply returning False could lead to much
confusion.
>
> Regards
>
> Antoine.
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/alexandre.zani%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Antoine Pitrou]

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 equality comparison fail with a TypeError (it
must be pretty much the only type in the stdlib with such poisonous
behaviour).


Comparing aware and naive datetime objects doesn't make much sense but
it's an easy mistake to make. I would say the TypeError is a sensible
way to warn you while simply returning False could lead to much
confusion.


You could say the same about equally "confusing" results, yet equality 
never raises TypeError (except between datetime instances):


>>> () == []
False

Raising an exception has very serious implications, such as making it 
impossible to put these objects in the same dictionary.


Regards

Antoine.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Alexander Belopolsky]

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, equality comparison should not raise an exception.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Guido van Rossum]

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 closer to home,
>
 date(2012,6,1) == datetime(2012,6,1)
> False
>
> I agree, equality comparison should not raise an exception.

Let's make it so.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Cross-compiling python and PyQt

[Tarek Sheasha]

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 very helpful.
Thanks a lot
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Alexandre Zani]

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 (except between datetime instances):
>>>
>> () == []
>>> False
>>
>> And even closer to home,
>>
> date(2012,6,1) == datetime(2012,6,1)
>> False
>>
>> I agree, equality comparison should not raise an exception.
>
> Let's make it so.
>
> --
> --Guido van Rossum (python.org/~guido)
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/alexandre.zani%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Nick Coghlan]

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 or using them directly.

Cheers,
Nick.

--
Sent from my phone, thus the relative brevity :)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Jan Kaliszewski]

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 should just store the decorators in the correct order of use
> +__decorators__ = [deco1, deco2]
> and avoid the nonsense (time-waste) of making an indirect copy via
> list_iterator and reversing it each time the attribute is used.

+1.  For @-syntax the inverted order seems to be somehow natural.  But I
feel the list order should not mimic that...

***

Another idea: what about...

@@dynamic_deco2
@@dynamic_deco1
class C:
pass

...being an equivalent of:

class C:
__decorators__ = [dynamic_deco1, dynamic_deco2]

...as well as of:

@@dynamic_deco2
class C:
__decorators__ = [dynamic_deco1]

?

Cheers.
*j

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Terry Reedy]

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 indirect copy via
list_iterator and reversing it each time the attribute is used.


It's for symmetry and straightforward translation with stacked
decorators, i.e. between:

@deco1
@deco2
[declaration]

and __decorators__ = [deco1, deco2]

Doing it the other way now means a different order for people to
remember; there should be One Obvious Order for decorators, and the one
we have now is it.


You and I have different ideas of 'obvious' in this context. But since 
you will use this and and me probably not, let your idea rule.


--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Terry Reedy]

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 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
very helpful.


This is off-topic for pydev list (which is for development *of* Python 
rather than development *with*). I suggest python-list (post in text 
only, please) or other lists for better help.


--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Terry Reedy]

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):


() == []

False


And even closer to home,


date(2012,6,1) == datetime(2012,6,1)

False

I agree, equality comparison should not raise an exception.


Let's make it so.


3.3 enhancement or backported bugfix? The doc strongly suggests that 
rich comparisons should return *something* and by implication, not 
raise. In particular, return NotImplemented instead of raising a 
TypeError for mis-matched arguments.


"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,"


--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Guido van Rossum]

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 if
>> people object. There simply isn't a way to roundtrip for times that
>> fall in the DST->std transition, and I doubt that many users will want
>> to think about it (they'd have to store an extra bit with all their
>> datetime objects -- it would be better to get them to use tzinfo
>> objects instead...).
>
> I've also been arguing against "local time" tzinfo

Why? I don't see your argumentation against such a tzinfo in the bug
(but I may have missed it, it's a lot of comments).

> and my proposal was
> to create a function that would produce TZ-aware local time with
> tzinfo bound to a fixed-offset timezone.  In New York that would mean
> EDT in the summer and EST in the winter.   This is what Unix date
> utility does.
>
> See http://bugs.python.org/issue9527 .

I don't like that function. It returns two different timezone objects
depending on whether DST is in effect. Also it adds a new method to
the datetime class, which I think is unnecessary here. I understand
returning two different timezone objects appear simpler, but it is
also more limiting: there are things you can do with timezone objects
that you can't do with these fixed-offset timezone objects, such as
adding a timedelta that produces a result in a different DST state.
E.g. adding 6 months to June 1st, 2012, PDT, would return Dec 1st,
2012, PDT, which is not local time here.

Reading the requirements for a timezone implementation and the
time.localtime() function, it would seem that a timezone object
representing "local time" can certainly be constructed, as long as the
time module uses or emulates the Unix/C behavior. On platforms where
it doesn't, it is okay to guess based on the limited information it
does have. But it looks like it should work on Unix/Linux, Windows,
and Mac. The crux is that the localtime() function "knows" the rules
for local DST in the past and future. It is true that it may not
always be right (e.g. if politics change the rules for the future, or
if the algorithm used is simplified, making it incorrect for times far
in the past), but it would still be consistent with the time module's
notion of local time, and we can consider this a bug in the OS (or
libc) rather than in Python.

If in the past I was ever opposed to that (as Raymond assumes in a
comment in that issue) I have changed my mind, but I think it's more
likely that we put off the creation of concrete timezone
implementations until later and then got distracted -- after all we
didn't even supply a UTC timezone, which surely is a lot simpler than
the local timezone.

--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Alexander Belopolsky]

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/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Alexander Belopolsky]

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, 1, 30, tzinfo=Local) represents two different times and another
day it represents no valid time.  Many applications can ignore this
problem but stdlib should not.

The documentation example (fixed in issue 9063) addresses the
ambiguity by defaulting to standard time, but it does this at a cost
of having no way to spell "the other hour."
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Guido van Rossum]

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 .
>
> 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 should not.

This seems the blocking issue. We disagree on whether the stdlib
should not offer this functionality because it cannot do so perfectly.

> The documentation example (fixed in issue 9063) addresses the
> ambiguity by defaulting to standard time, but it does this at a cost
> of having no way to spell "the other hour."

Again, this is a problem of DST and timezones, and not something you
can ever "fix" (even if DST would be abandoned worldwide tomorrow, it
would still remain a problem for historic times). We should just
acknowledge the problem, implement the best we can do, document the
limitation, and move on. Apps that care should just use some other way
to represent local time.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[PJ Eby]

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__ = [deco1, deco2]
>>and avoid the nonsense (time-waste) of making an indirect copy via
>>list_iterator and reversing it each time the attribute is used.
>>
>>
>> It's for symmetry and straightforward translation with stacked
>> decorators, i.e. between:
>>
>> @deco1
>> @deco2
>> [declaration]
>>
>> and __decorators__ = [deco1, deco2]
>>
>> Doing it the other way now means a different order for people to
>> remember; there should be One Obvious Order for decorators, and the one
>> we have now is it.
>>
>
> You and I have different ideas of 'obvious' in this context.


To be clearer: I've written other APIs which take multiple decorators, or
things like decorators that just happen to be a pipeline of functions to be
applied, and every time the question of what order to put the API in, I
always put them in this order because then in order to remember what the
order was, I just have to think of decorators.  This is easier than trying
to remember which APIs use decorator order, and which ones use reverse
decorator order.

So, even though in itself there is no good reason for one order over the
other, consistency wins because less thinking.  At the least, if they're
not going to be in decorator order, the member shouldn't be called
"__decorators__".  ;-)



> But since you will use this and and me probably not, let your idea rule.


For my motivating use case, I actually don't care about the order within a
class very much.  Nick's proposal will actually be the reverse of the
application order used by my in-class decorators, but I can easily work
around that.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Greg Ewing]

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.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Nick Coghlan]

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 __decorators__ = [deco1, deco2]
>>>
>>> Doing it the other way now means a different order for people to
>>> remember; there should be One Obvious Order for decorators, and the one
>>> we have now is it.
>>
>>
>> You and I have different ideas of 'obvious' in this context.
>
>
> To be clearer: I've written other APIs which take multiple decorators, or
> things like decorators that just happen to be a pipeline of functions to be
> applied, and every time the question of what order to put the API in, I
> always put them in this order because then in order to remember what the
> order was, I just have to think of decorators.  This is easier than trying
> to remember which APIs use decorator order, and which ones use reverse
> decorator order.
>
> So, even though in itself there is no good reason for one order over the
> other, consistency wins because less thinking.  At the least, if they're not
> going to be in decorator order, the member shouldn't be called
> "__decorators__".  ;-)

Yeah, I can actually make decent arguments in favour of either order,
but it was specifically "same order as lexical decorators" that tipped
the balance in favour of the approach I wrote up in the PEP.

It's also more consistent given how the base classes are walked. While
I'm not proposing to calculate it this way, you can look at the scheme
the PEP as:

# Walk the MRO to build a complete decorator list
decorators = []
for entry in cls.mro():
decorators.extend(cls.__dict__.get("__decorators__", ())
# Apply the decorators in "Last In, First Out" order, just like
unwinding a chain of super() calls
for deco in reversed(decorators):
cls = deco(cls)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Alexander Belopolsky]

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 should not.
>
> This seems the blocking issue. We disagree on whether the stdlib
> should not offer this functionality because it cannot do so perfectly.
>

I would put it differently.  There are two features missing from datetime:

1.  We cannot create TZ-aware local time datetime objects from a
timestamp.  In other words, if I want to implement UNIX date utility:

$ date
Tue Jun  5 18:56:50 EDT 2012

I have to use the lower level time module.

2. We cannot imbue a naive datetime object presumed to represent local
time with a tzinfo instance.

Note that the first feature does not suffer from the DST ambiguity.
Many modern systems extend POSIX struct tm to supply accurate UTC
offset and zone name taking into account all historical changes.

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, I don't want it to go off twice or divine
which 1:30 AM I had in mind.  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.  This
does not preclude implementing LocalTimezone, but we have to decide
what to do if user specifies ambiguous or invalid naive time.  My
preference would be to default to standard time for the ambiguous hour
and raise a ValueError for the invalid hour.

>> The documentation example (fixed in issue 9063) addresses the
>> ambiguity by defaulting to standard time, but it does this at a cost
>> of having no way to spell "the other hour."
>
> Again, this is a problem of DST and timezones, and not something you
> can ever "fix" ...

POSIX has the "fix."  It is not perfect if the DST rules change
historically, but it does let you round-trip between timestamp and
broken down local time.   The fix is the DST flag.  For most values
stored in struct tm, the tm_isdst  flag can be divined from time
fields, but for the ambiguous hour this flag is necessary to read the
actual time.  To use mathematical analogy, tm_isdst specifies the
branch of a multi-valued function.

I don't advocate adding isdst flag to datetime.  This solution has its
own limitations and as I mentioned above, modern systems extend struct
tm further adding non-standard tm_zone and tm_offset fields.  What I
suggest is that we skip the isdst kludge and provide a way to get
system-supplied tm_zone and tm_offset to the aware datetime object.
This will not solve the alarm clock problem, but will solve the what
time is now and what time it was when I created this file problems.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Nick Coghlan]

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 anybody do a bunch of work on my behalf.
> (Clearly, I wasn't successful in the attempt, but I should at least get
> credit for trying.  ;-)

OK, I can accept that. I mainly just wanted to head off the idea of
overloading __build_class__ *anyway*, even if you weren't successful
in getting agreement in bringing back __metaclass__ support, or a
sufficiently powerful replacement mechanism.

The idea of making __build_class__ itself public *has* been discussed,
and the outcome of that discussion was the creation of
types.new_class() as a way to programmatically define classes that
respects the new __prepare__() hook.

> In general, implementing what's effectively inherited decoration is what
> *most* metaclasses actually get used for, so PEP 422 is a big step forward
> in that.

Yeah, that's what I realised (and will try to explain better in the
next version of the PEP, based on my reply to Xavier).

> Sketching something to get a feel for the PEP...
>
> def inheritable(*decos):
>     """Wrap a class with inheritable decorators"""
>     def decorate(cls):
>     cls.__decorators__ =
> list(decos)+list(cls.__dict__.get('__decorators__',()))
>     for deco in reversed(decos):
>     cls = deco(cls)
>     return cls

Yep, that should work.

> Hm.  There are a few interesting consequences of the PEP as written.
> In-body decorators affect the __class__ closure (and thus super()), but
> out-of-body decorators don't.  By me this is a good thing, but it is a bit
> of complexity that needs mentioning.

It's also worth highlighting this as a limitation of the currently
supported metaclass based approach. When a metaclass runs, __class__
hasn't been filled in yet, so any attempts to call methods that use it
(including via zero-argument super()) will fail.

That's why my _register example at [1] ended up relying on the default
argument hack: using __class__ (which is what I tried first without
thinking it through) actually fails, complaining that the cell hasn't
been populated. Under PEP 422, the default argument hack wouldn't be
necessary, you could just write it as:

def _register(cls):
__class__._registry.append(cls)
return cls

[1] https://bitbucket.org/ncoghlan/misc/src/default/pep422.py

>  Likewise, the need for inheritable
> decorators to be idempotent, in case two base classes list the same
> decorator.

Yeah, I'll add a section on "well-behaved" dynamic decorators, which
need to be aware that they may run multiple times on a single class.
If they're not naturally idempotent, they may need additional code to
be made so.

>  (For my own use attribute/method use cases, I can just have them
> remove themselves from the class's __decorators__ upon execution.)

Indeed, although that's probably unique to the approach of
programmatically modifying __decorators__. Normally, if you don't want
a decorator to be inherited and automatically applied to subclasses
you would just use an ordinary lexical decorator.

>>  You complain that metaclasses are hard to compose, and your
>> "solution" is to monkeypatch a deliberately undocumented builtin?
>
> To be clear, what I specifically proposed (as I mentioned in an earlier
> thread) was simply to patch __build_class__ in order to restore the missing
> __metaclass__ hook.  (Which, incidentally, would make ALL code using
> __metaclass__ cross-version compatible between 2.x and 3.x: a potentially
> valuable thing in and of itself!)

I did briefly consider proposing that, but then I had the dynamic
decorators idea which I like a *lot* more (since it also simplifies
other use cases that currently require a metaclass when that isn't
really what you want).

> (Automatic metaclass combining is about the only thing
> that would improve it any further.)

Automatic metaclass derivation only works in practice if the
metaclasses are all written to support cooperative multiple
inheritance though, which is a fairly large "if" (albeit, far more
likely than in the general inheritance case, since the signatures of
the methods involved in type construction are significantly more
constrained than those involved in instantiating arbitrary objects).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Nick Coghlan]

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 use of a specific metaclass in 3.2 (either
>> directly or via inheritance), but monkeypatching an undocumented
>> builtin is going to pathological lengths just to avoid requiring that
>> people explicitly interoperate with your particular metaclass
>> mechanisms.
>
> When reading the PEP, I got the impression that having a
> "__decorate__" method on "type", which would perform its thing, would
> be not add magic exceptions, would be more explicit and more flexible
> than having an extra step to be called between the metaclass execution
> and decorator applying.
>
> So, I think that settling for having the decorators applied - as
> described in the PEP - in a __decorate__ method of the metaclass would
> be nicer and cleaner.

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* lexical decorators are applied.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Barry Warsaw]

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, I don't want it to go off twice or divine
>which 1:30 AM I had in mind.  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 an aware
datetime would have that information but not naive ones.

-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Brett Cannon]

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.python.org/issue15008 .

---
PEP: 362
Title: Function Signature Object
Version: $Revision$
Last-Modified: $Date$
Author: Brett Cannon , Jiwon Seo ,
Yury Selivanov , Larry Hastings <
la...@hastings.org>
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 21-Aug-2006
Python-Version: 3.3
Post-History: 04-Jun-2012


Abstract


Python has always supported powerful introspection capabilities,
including introspecting functions and methods.  (For the rest of
this PEP, "function" refers to both functions and methods).  By
examining a function object you can fully reconstruct the function's
signature.  Unfortunately this information is stored in an inconvenient
manner, and is spread across a half-dozen deeply nested attributes.

This PEP proposes a new representation for function signatures.
The new representation contains all necessary information about a function
and its parameters, and makes introspection easy and straightforward.

However, this object does not replace the existing function
metadata, which is used by Python itself to execute those
functions.  The new metadata object is intended solely to make
function introspection easier for Python programmers.


Signature Object


A Signature object represents the overall signature of a function.
It stores a `Parameter object`_ for each parameter accepted by the
function, as well as information specific to the function itself.

A Signature object has the following public attributes and methods:

* name : str
Name of the function.
* qualname : str
Fully qualified name of the function.
* return_annotation : object
The annotation for the return type of the function if specified.
If the function has no annotation for its return type, this
attribute is not set.
* parameters : OrderedDict
An ordered mapping of parameters' names to the corresponding
Parameter objects (keyword-only arguments are in the same order
as listed in ``code.co_varnames``).
* bind(\*args, \*\*kwargs) -> BoundArguments
Creates a mapping from positional and keyword arguments to
parameters.

Once a Signature object is created for a particular function,
it's cached in the ``__signature__`` attribute of that function.

Changes to the Signature object, or to any of its data members,
do not affect the function itself.


Parameter Object


Python's expressive syntax means functions can accept many different
kinds of parameters with many subtle semantic differences.  We
propose a rich Parameter object designed to represent any possible
function parameter.

The structure of the Parameter object is:

* name : str
The name of the parameter as a string.
* default : object
The default value for the parameter if specified.  If the
parameter has no default value, this attribute is not set.
* annotation : object
The annotation for the parameter if specified.  If the
parameter has no annotation, this attribute is not set.
* is_keyword_only : bool
True if the parameter is keyword-only, else False.
* is_args : bool
True if the parameter accepts variable number of arguments
(``\*args``-like), else False.
* is_kwargs : bool
True if the parameter accepts variable number of keyword
arguments (``\*\*kwargs``-like), else False.
* is_implemented : bool
True if the parameter is implemented for use.  Some platforms
implement functions but can't support specific parameters
(e.g. "mode" for os.mkdir).  Passing in an unimplemented
parameter may result in the parameter being ignored,
or in NotImplementedError being raised.  It is intended that
all conditions where ``is_implemented`` may be False be
thoroughly documented.


BoundArguments Object
=

Result of a ``Signature.bind`` call.  Holds the mapping of arguments
to the function's parameters.

Has the following public attributes:

* arguments : OrderedDict
An ordered mutable mapping of parameters' names to arguments' values.
Does not contain arguments' default values.
* args : tuple
Tuple of positional arguments values.  Dynamically computed from
the 'arguments' attribute.
* kwargs : dict
Dict of keyword arguments values. Dynamically computed from
the 'arguments' attribute.

The ``arguments`` attribute should be used in conjunction with
``Signature.parameters`` for any arguments processing purposes.

``args`` and ``kwargs`` properties should be used to invoke functions:
::

def test(a, *, b):
...

sig = signature(test)
ba = sig.bind(10, b=20)
test(*ba.args, **ba.kwargs)


Implementation
==

An

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

[Tres Seaver]

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. between:
 
 @deco1 @deco2 [declaration]
 
 and __decorators__ = [deco1, deco2]
 
 Doing it the other way now means a different order for people
 to remember; there should be One Obvious Order for decorators,
 and the one we have now is it.
>>> 
>>> 
>>> You and I have different ideas of 'obvious' in this context.
>> 
>> 
>> To be clearer: I've written other APIs which take multiple
>> decorators, or things like decorators that just happen to be a
>> pipeline of functions to be applied, and every time the question of
>> what order to put the API in, I always put them in this order
>> because then in order to remember what the order was, I just have to
>> think of decorators.  This is easier than trying to remember which
>> APIs use decorator order, and which ones use reverse decorator
>> order.
>> 
>> So, even though in itself there is no good reason for one order over
>> the other, consistency wins because less thinking.  At the least, if
>> they're not going to be in decorator order, the member shouldn't be
>> called "__decorators__".  ;-)
> 
> Yeah, I can actually make decent arguments in favour of either order, 
> but it was specifically "same order as lexical decorators" that
> tipped the balance in favour of the approach I wrote up in the PEP.
> 
> It's also more consistent given how the base classes are walked.
> While I'm not proposing to calculate it this way, you can look at the
> scheme the PEP as:
> 
> # Walk the MRO to build a complete decorator list decorators = [] for
> entry in cls.mro(): 
> decorators.extend(cls.__dict__.get("__decorators__", ()) # Apply the
> decorators in "Last In, First Out" order, just like unwinding a chain
> of super() calls for deco in reversed(decorators): cls = deco(cls)


Or, to make it obvious we are treating 'decorators' as a stack::

  while decorators:
  cls = decorators.pop()(cls)


-- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Nick Coghlan]

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 to set it to 1:30 AM on the day
>>when 1:30 AM happens twice, I don't want it to go off twice or divine
>>which 1:30 AM I had in mind.  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 an aware
> datetime would have that information but not naive ones.

Indeed. As I mentioned in my earlier email, we need to remember that
there's a *system* level solution to many of these problems Alexander
raises: configure machines to use UTC and completely ignore local time
definitions.

Many military systems do this. They schedule everything in Zulu time
anyway, and have the kind of control over their mission critical
systems that means they can enforce the rule of configuring absolutely
everything to run as UTC. Such systems often span multiple time zones,
and sharing a consistent time base with other system components is
considered far more important than the vagaries of local time
definitions (coping with DST is the least of your worries in that
context, since you would also need to consider situations like entire
countries deciding to change time zones:
http://www.bbc.co.uk/news/world-13334229).

You *cannot* do robust date processing with local times, because the
meaning of "local time" changes. Clients, servers, peers, will all
have different ideas about the local time, but they will all agree on
UTC. For some platforms (especially supersonic aircraft, satellites
and extraplanetary exploration vehicles) the very notion of "local
time" is completely meaningless (the International Space Station takes
90 minutes to complete an orbit, so it takes less than 4 minutes to
cross any given terrestrial "time zone"). And if everything is known
to be in UTC, then it doesn't matter if you're using "naive" timezone
objects, or "aware" ones that happen to have their timezone
specifically set to UTC. 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.

It's analagous to the situation with Unicode text and encodings: the
"true" time representation is UTC, just as the "true" text
representation is Unicode. "tzinfo" objects are the date/time
equivalent of Unicode encodings. Passing tzinfo objects around is the
equivalent of using "tagged bytestrings" (i.e. binary data with an
associated encoding) as your internal representation instead of a
Unicode based text object.

You really want to deal with timezone variations solely at your system
boundaries and get rid of them ASAP when it comes to internal
processing.

The datetime module should be designed to make this *as easy as
possible*. Adding a "local time" tzinfo object (with the ambigous hour
favouring the non-DST time, and the missing hour triggering an error
at construction time) would be a good step in the right direction: it
allows local times to be clearly flagged, even though they're
explicitly *not* appropriate for many kinds of processing and need to
be converted to a more suitable format (such as a naive datetime
object, or one with the timezone set to UTC) first. This is directly
analogous to text in a specific encoding: it's useful for some
purposes, but you'll need to decode it to Unicode for many other
manipulations.

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. (The difference between this and the implicit conversion
hell that is the Python 2 Unicode model is that there shouldn't be a
range mismatch between the canonical time representation and the
timezone aware representations the way there is between the range of
the full Unicode representation and what can be represented in an
arbitrary text encoding).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Alexander Belopolsky]

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 an aware
> datetime would have that information but not naive ones.

I did not say that it is the datetime objects who would have that
information.  It is the application or the library that should embody
such knowledge.  So if I try to specify time as 2012-03-11 at 2:30 AM
"New York time," the application should know that no such time exists
and reject it as it would 2012-03-11 at 2:66 AM.

At the end of the day, users want an easy way to solve the equation

datetime.fromtimestamp(x) = dt,

but this equation can have 0, 1 or 2 solutions depending on the value
of dt.  An ultimate solution would be to provide a function that
returns a list length 0, 1, or 2.  Short of that, we can assume
standard time when there are two solutions and raise an exception when
there are none.  This is the math.sqrt() approach.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Glyph]

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 this were true.  In fact, I would go a step 
further and say that the whole concept of a "naive" datetime is simply a bug.  
We don't have a "naive" unicode, for example, where it's text in some encoding 
but you decline to decide which one when you decode it, leaving that to the 
caller.

When we addresed this problem for ourselves at Divmod some time ago, naive=UTC 
is exactly what we did:

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Alexander Belopolsky]

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.
>

Displaying local time would be addressed by what I called the first
feature: given the timestamp find the local time and the TZ
name/offset:

$ date
Tue Jun  5 21:28:21 EDT 2012

Most humans will ignore the TZ information, but the format above can
represent any moment in time unambiguously.

A related but different problem is taking time input from humans.  Air
traffic control systems may handle all times in UTC, but when I search
for my flight, I enter local time.  There may be two flights one at
1:30 AM EDT and the other at 1:30 AM EST.  In this case I need some
way to figure out which one is mine and I will look at the TZ part.
(Hopefully the user interface will present a helpful explanation of
what is going on.)


> The datetime module should be designed to make this *as easy as
> possible*. Adding a "local time" tzinfo object (with the ambigous hour
> favouring the non-DST time, and the missing hour triggering an error
> at construction time) would be a good step in the right direction: it
> allows local times to be clearly flagged, even though they're
> explicitly *not* appropriate for many kinds of processing and need to
> be converted to a more suitable format (such as a naive datetime
> object, or one with the timezone set to UTC) first.

This is exactly my proposal, but it does not help when you need to get
on the right 1:30 AM flight.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Nick Coghlan]

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 need a BDFAP and someone to do a code
> review: http://bugs.python.org/issue15008 .

I suspect I have too many ideas for what I want the PEP to accomplish
to make a good BDFL delegate for this one.

One thing I would like to see this PEP achieve is to improve function
introspection for @functools.wraps decorated functions where the
wrapper uses a (*args, **kwds) signature. To that end, I would prefer
to see it added to the functools module rather than to the inspect
module.

I would also like to see native support for "early binding" validation
of call parameters. The idea will be for interfaces that support "lazy
calls" (such as contextlib.ExitStack, unittest.TestCase.addCleanup) to
detect parameter binding errors when the function is *added*, rather
than when it is called. Such lazy call errors are notoriously hard to
debug, since the error site (where the callback is invoked) often
provides no indication as to where the actual error occurred (that is,
when it was registered with the callback interface).

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 "improve introspection support for functions".

- the main new API be added as "functools.signature" (any necessary
infrastructure from inspect would also migrate to functools as private
implementations. affected inspect APIs would either be updated to use
the signature API, or else to just republish the functools
implementation)

- "functools.update_wrapper" be enhanced to set "wrapper.__signature__
= signature(wrapped)"

- At least contextlib and unittest be updated to use
"functools.signature(f).bind(*args, **kwds)" for the relevant callback
APIs

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Greg Ewing]

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 standard time, but it does this at a cost
of having no way to spell "the other hour."


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.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Greg Ewing]

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 other operand a chance to handle
the operation. If they both return NotImplemented,
then a TypeError is raised by the interpreter.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[R. David Murray]

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
> >>> decorators, i.e. between:
> >>>
> >>> @deco1
> >>> @deco2
> >>> [declaration]
> >>>
> >>> and __decorators__ = [deco1, deco2]
> >>>
> >>> Doing it the other way now means a different order for people to
> >>> remember; there should be One Obvious Order for decorators, and the one
> >>> we have now is it.
> >>
> >>
> >> You and I have different ideas of 'obvious' in this context.
> >
> >
> > To be clearer: I've written other APIs which take multiple decorators, or
> > things like decorators that just happen to be a pipeline of functions to be
> > applied, and every time the question of what order to put the API in, I
> > always put them in this order because then in order to remember what the
> > order was, I just have to think of decorators.  This is easier than trying
> > to remember which APIs use decorator order, and which ones use reverse
> > decorator order.
> >
> > So, even though in itself there is no good reason for one order over the
> > other, consistency wins because less thinking.  At the least, if they're 
> > not
> > going to be in decorator order, the member shouldn't be called
> > "__decorators__".  ;-)
> 
> Yeah, I can actually make decent arguments in favour of either order,
> but it was specifically "same order as lexical decorators" that tipped
> the balance in favour of the approach I wrote up in the PEP.

I don't think about data structures lexically, though, I think of them
programmatically.  So I'm with Terry here, I would expect them to be in
the list in the order they are going to get applied.  I can see the
other argument, though, and presumably other people's brains work
differently and they'd be more confused by non-lexical ordering.

> It's also more consistent given how the base classes are walked. While
> I'm not proposing to calculate it this way, you can look at the scheme
> the PEP as:
> 
> # Walk the MRO to build a complete decorator list
> decorators = []
> for entry in cls.mro():
> decorators.extend(cls.__dict__.get("__decorators__", ())
> # Apply the decorators in "Last In, First Out" order, just like
> unwinding a chain of super() calls
> for deco in reversed(decorators):
> cls = deco(cls)

Assuming I got this right (no guarantees :), the following is actually
easier for me to understand (I had to think to understand what "just
like unwinding a chain of super() calls" meant):

  # Walk the MRO from the root, applying the decorators.
  for entry in reversed(cls.mro()):
  for deco in cls.__dict__.get("__decorators__", ()):
 cls = deco(cls)

--David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Alexander Belopolsky]

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 happens to the dst flag when you add a
timedelta?  If dst flag is optional, should you be able to compare
dst-aware and dst-naive instances?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[R. David Murray]

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 aware objects updated
> > accordingly
> 
> I would absolutely love it if this were true.  In fact, I would go a step 
> further and say that the whole concept of a "naive" datetime is simply a bug. 
>  We don't have a "naive" unicode, for example, where it's text in some 
> encoding but you decline to decide which one when you decode it, leaving that 
> to the caller.
> 
> When we addresed this problem for ourselves at Divmod some time ago, 
> naive=UTC is exactly what we did:
> 
> 

Note that (after several conversations with Alexander, and based on the
analogous decision in the email RFCs), the email package makes the same
call.  A naive datetime is treated as a UTC time with no information
about what timezone it originated from (coded as - per RFC 5322),
while an aware datetime will generate an accurate offset (+ for
"really UTC", and as appropriate for others).

So in some sense I've already nudged the stdlib in this
direction...unless I get overruled now that I've pointed it out :)

--David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Nick Coghlan]

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 solve the round-trip problem, but will open a
> different can of worms: what happens to the dst flag when you add a
> timedelta?  If dst flag is optional, should you be able to compare
> dst-aware and dst-naive instances?

Yeah, I think it's cleaner to lean on tzinfo as much as possible. If
we decide we need to support both "local, treating the overlapping
hour as standard time" and "local, treating the overlapping hour as
DST", then that could be represented as two different timezone objects
and follow the normal rules for reconciling timezones rather than
adding a new flag anywhere.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Yury Selivanov]

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 "improve introspection support for functions".

It's already supported, if I understand your request correctly.
'Signature.bind' already does all necessary arguments validation (see the unit 
tests).

Hence, `unittest.TestCase.addCleanup` may be rewritten as:

def addCleanup(self, function, *args, **kwargs):
# Bind *args & **kwargs. May raise a BindError in case
# of incorrect callback arguments.
bound_args = signature(function).bind(*args, **kwargs)
self._cleanups.append((function, bound_args))

And later, in `doCleanups`:

while self._cleanups:
function, bound_args = self._cleanups.pop()
part = lambda: function(*bound_args.args, **bound_args.kwargs)
self._executeTestPart(part, outcome)
...

And same for `contextlib.ExitStack`:

def callback(self, callback, *args, **kwds):
cb_bound_args = signature(callback).bind(*args, **kwds)
def _exit_wrapper(exc_type, exc, tb):
callback(*cb_bound_args.args, **cb_bound_args.kwargs)
...

> - the main new API be added as "functools.signature" (any necessary
> infrastructure from inspect would also migrate to functools as private
> implementations. affected inspect APIs would either be updated to use
> the signature API, or else to just republish the functools
> implementation)

Only 'ismethod' and 'isfunction' from the 'inspect' module are used.  Those 
could be easily replaced with direct 'isinstance' calls, so we have no 
dependancy on inspect's guts.

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 are 
all about introspection and not about transforming what a 
function does.

> - "functools.update_wrapper" be enhanced to set "wrapper.__signature__
> = signature(wrapped)"

Big +1 on this one.  If you give me a green light on this, I'll add this change 
along with the unit tests to the patch.

> - At least contextlib and unittest be updated to use
> "functools.signature(f).bind(*args, **kwds)" for the relevant callback
> APIs


+1.

Thank you,
-
Yury

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Guido van Rossum]

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 results no worse than the status quo.
>>
>> This would neatly solve the round-trip problem, but will open a
>> different can of worms: what happens to the dst flag when you add a
>> timedelta?  If dst flag is optional, should you be able to compare
>> dst-aware and dst-naive instances?
>
> Yeah, I think it's cleaner to lean on tzinfo as much as possible. If
> we decide we need to support both "local, treating the overlapping
> hour as standard time" and "local, treating the overlapping hour as
> DST", then that could be represented as two different timezone objects
> and follow the normal rules for reconciling timezones rather than
> adding a new flag anywhere.

Let's not add a DST flag to datetime objects.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Guido van Rossum]

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 for
>> inter-system coordination where such details are relevant.
>>
>
> Displaying local time would be addressed by what I called the first
> feature: given the timestamp find the local time and the TZ
> name/offset:
>
> $ date
> Tue Jun  5 21:28:21 EDT 2012
>
> Most humans will ignore the TZ information, but the format above can
> represent any moment in time unambiguously.
>
> A related but different problem is taking time input from humans.  Air
> traffic control systems may handle all times in UTC, but when I search
> for my flight, I enter local time.  There may be two flights one at
> 1:30 AM EDT and the other at 1:30 AM EST.  In this case I need some
> way to figure out which one is mine and I will look at the TZ part.
> (Hopefully the user interface will present a helpful explanation of
> what is going on.)
>
>
>> The datetime module should be designed to make this *as easy as
>> possible*. Adding a "local time" tzinfo object (with the ambigous hour
>> favouring the non-DST time, and the missing hour triggering an error
>> at construction time) would be a good step in the right direction: it
>> allows local times to be clearly flagged, even though they're
>> explicitly *not* appropriate for many kinds of processing and need to
>> be converted to a more suitable format (such as a naive datetime
>> object, or one with the timezone set to UTC) first.
>
> This is exactly my proposal, but it does not help when you need to get
> on the right 1:30 AM flight.

Trust me. Even if there was only one 1:30AM flight everybody including
the crew would have trouble getting there on time. There's a reason
why the DST change happens around 1AM.

(Unrelated fun DST fact: there's a difference between the way Europe
and the US coordinate DST changes across multiple timezones. In the US
each timezone switches at 1AM local time, making the difference
between adjacent timezones vary for an hour. In Europe the linked
timezones all switch simultaneously, keeping the zone differences in
sync but making the local time of the switch vary.)

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Guido van Rossum]

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 updated
> accordingly
>
> I would absolutely love it if this were true.  In fact, I would go a step
> further and say that the whole concept of a "naive" datetime is simply a
> bug.  We don't have a "naive" unicode, for example, where it's text in some
> encoding but you decline to decide which one when you decode it, leaving
> that to the caller.
>
> When we addresed this problem for ourselves at Divmod some time ago,
> naive=UTC is exactly what we did:
>
> 

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 to represent local time (the
timestamps are stored because integers are easier to store). And yes
they get in horrible trouble around DST and they don't understand why.
But they still do it.

I think it's better to give users the rope they want than to try and
prevent them from hanging themselves, since otherwise they'll just use
the power cords as ropes and electrocute themselves.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[MRAB]

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 problem, but will open a
different can of worms: what happens to the dst flag when you add a
timedelta?  If dst flag is optional, should you be able to compare
dst-aware and dst-naive instances?


Here's my take on it:

datetime objects would consist of the UTC time, time zone and DST.

When comparing 2 datetime objects, it would compare the UTC times. The
difference between 2 datetimes would be the difference between their
UTC times.

When converting to a string, you would specify whether you wanted local
time (UTC + TZ + DST) or not.

When converting from a string, it would assume UTC time unless the
string gave the time zone and DST or you specified that it was local
time. It would convert local time to UTC time and set the time zone and
DST appropriately.

After adding a timedelta to a datetime, it would normalise the DST
according to the local rules.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Nick Coghlan]

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 to represent local time (the
> timestamps are stored because integers are easier to store). And yes
> they get in horrible trouble around DST and they don't understand why.
> But they still do it.
>
> I think it's better to give users the rope they want than to try and
> prevent them from hanging themselves, since otherwise they'll just use
> the power cords as ropes and electrocute themselves.

Agreed, I'm just asking that the particular brand of rope be the
assumption that naive timezones are implicitly UTC and allowing
transparent interoperation according to that assumption. If someone is
just using them to represent local time, and only have to deal with
local time in one location, then they'll still mostly be fine (setting
aside DST problems).

If naive times and tz-aware times can natively interoperate, then it
provides a path towards making more of the stdlib tz-aware by default
(such as returning objects with the timezone set to UTC).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[PJ Eby]

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* lexical decorators are applied.
>

Why not have type.__call__() do the invocation?  That is, why does it need
to become part of the external class-building protocol?

(One advantage to putting it all in type.__call__() is that you can emulate
the protocol in older Pythons more easily than if it's part of the external
class creation dance.)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Guido van Rossum]

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 between timestamps and time
>> tuples, and yet use time tuples to represent local time (the
>> timestamps are stored because integers are easier to store). And yes
>> they get in horrible trouble around DST and they don't understand why.
>> But they still do it.
>>
>> I think it's better to give users the rope they want than to try and
>> prevent them from hanging themselves, since otherwise they'll just use
>> the power cords as ropes and electrocute themselves.
>
> Agreed, I'm just asking that the particular brand of rope be the
> assumption that naive timezones are implicitly UTC and allowing
> transparent interoperation according to that assumption. If someone is
> just using them to represent local time, and only have to deal with
> local time in one location, then they'll still mostly be fine (setting
> aside DST problems).
>
> If naive times and tz-aware times can natively interoperate, then it
> provides a path towards making more of the stdlib tz-aware by default
> (such as returning objects with the timezone set to UTC).

I don't see how that follows. Forbidding the interaction between naive
and tz-aware datetime objects is a fundamental part of the design and
I won't be comfortable with dropping it without a whole lot more
discussion of the topic.

OTOH adding the "Local" timezone object to the stdlib (despite its
flaws) is a no-brainer for me, since it doesn't hurt those who don't
use it.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Ben Finney]

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 (if ever) DST kicks on or off.

Or have I been spoiled by the Olsen database?

-- 
 \   “Truth is stranger than fiction, but it is because fiction is |
  `\ obliged to stick to possibilities, truth isn't.” —Mark Twain, |
_o__)  _Following the Equator_ |
Ben Finney

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Nick Coghlan]

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 are
>    all about introspection and not about transforming what a
>    function does.

I actually disagree with that characterisation of the new feature, as:

1. __signature__ introduces the possibility for a function (or any
object, really) to say "this is my *real* signature, even if the lower
level details appear to be more permissive than that"
2. Signature.bind introduces the ability to split the "bind arguments
to parameters" operation from the "call object" operation

Those two use cases are about function manipulation rather than pure
introspection, making functools an appropriate home.
>> - "functools.update_wrapper" be enhanced to set "wrapper.__signature__
>> = signature(wrapped)"
>
> Big +1 on this one.  If you give me a green light on this, I'll add this 
> change along with the unit tests to the patch.

And this is actually the real reason I'm proposing functools as the
home for the new feature. I think this change would a great
enhancement to functools.wraps, but I also think making functools
depend on the inspect module would be a crazy thing to do :)

However, looking at the code, I think the split that makes sense is
for a lower level functools.signature to *only* support real function
objects (i.e. not even method objects).

At the inspect layer, inspect.signature could then support retrieving
a signature for an arbitrary callable roughly as follows:

def signature(f):
try:
# Real functions are handled directly by functools
return functools.signature(f)
except TypeError:
pass
# Not a function object, handle other kinds of callable
if isclass(f):
# Figure out a Signature based on f.__new__ and f.__init__
# Complain if the signatures are contradictory
# Account for the permissive behaviour of object.__new__
and object.__init__
return class_signature
if ismethod(f):
f = f.__func__
elif not isfunction(f):
try:
f = f.__call__
except AttributeError:
pass
return signature(f) # Use recursion for the initial
implementation sketch

That code is almost certainly wrong, but it should be enough to give
the general idea. The short version is:

1. Provide a functools.signature that expects ordinary function
objects (or objects with a __signature__ attribute)
2. Provide an inspect.signature that also handles other kinds of callable

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Nick Coghlan]

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 and the __class__ cell is
>> populated, but *before* lexical decorators are applied.
>
>
> Why not have type.__call__() do the invocation?  That is, why does it need
> to become part of the external class-building protocol?
>
> (One advantage to putting it all in type.__call__() is that you can emulate
> the protocol in older Pythons more easily than if it's part of the external
> class creation dance.)

That's something else I need to write up in the PEP (I *had* thought
about it, I just forgot to include the explanation for why it doesn't
work). The problems are two-fold:

1. It doesn't play nicely with __class__ (since the cell doesn't get
populated until after type.__call__ returns)
2. It doesn't play nicely with metaclass inheritance (when you call up
to type.__call__ from a subclass __call__ implementation, the dynamic
decorators will see a partially initialised class object)

That's really two aspects of the same underlying concern though: the
idea is that decorators should only be handed a fully initialised
class instance, which means they have to be invoked *after* the
metaclass invocation has already returned.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com