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

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

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

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

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

A question regarding the name. I have often seen the following pattern in decorators: def decor(f): def some_func(a,b): do_stuff using f some_func.__name__ = f.__name__ return some_func What are the name and fully qualified names in the signature for the returned function? som

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

A comment on the way methods are handled. I have seen decorators that do something like this: import functools def dec(f): functools.wraps(f) def decorated(*args, *kwargs): cursor = databaseCursor() return f(cursor, *args, **kwargs) As a result, if the decorated function

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

On Thu, Jun 7, 2012 at 9:41 PM, Nick Coghlan wrote: > On Fri, Jun 8, 2012 at 2:20 PM, Alexandre Zani > wrote: >> A comment on the way methods are handled. I have seen decorators that >> do something like this: >> >> import functools >> >> def dec(f): &g

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

On Sun, Jun 10, 2012 at 1:27 PM, Benjamin Peterson wrote: > 2012/6/10 Larry Hastings : >> Can you make a more concrete suggestion?  "type" strikes me as a poor choice >> of name, as it makes one think immediately of type(), which is another, uh, >> variety of "type". > > kind -> > "position" or >

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

On Sun, Jun 10, 2012 at 11:13 PM, Benjamin Peterson wrote: > 2012/6/10 Alexandre Zani : >> >> I prefer the flags. Flags means I can just look at the Parameter >> object. A "type" or "kind" or whatever means I need to compare to a >> bunch of consta

Re: [Python-Dev] #12982: Should -O be required to *read* .pyo files?

On Tue, Jun 12, 2012 at 11:41 AM, Ethan Furman wrote: > Terry Reedy wrote: >> >> http://bugs.python.org/issue12982 >> >> Currently, cpython requires the -O flag to *read* .pyo files as well as >> the write them. This is a nuisance to people who receive them from others, >> without the source. The

Re: [Python-Dev] PEP 362 Third Revision

On Wed, Jun 13, 2012 at 8:06 PM, Yury Selivanov wrote: > On 2012-06-13, at 10:52 PM, Yury Selivanov wrote: >> 2. signature() function support all kinds of callables: >> classes, metaclasses, methods, class- & staticmethods, >> 'functools.partials', and callable objects.  If a callable >> object ha

Re: [Python-Dev] PEP 362 Third Revision

On Thu, Jun 14, 2012 at 6:50 AM, Yury Selivanov wrote: > On 2012-06-14, at 8:06 AM, Victor Stinner wrote: >> Sorry if I'm asking dummy questions, I didn't follow the discussion. >> >>> * format(...) -> str >>>    Formats the Signature object to a string.  Optional arguments allow >>>    for custom

Re: [Python-Dev] PEP 362 Third Revision

Thanks. :) On Thu, Jun 14, 2012 at 4:50 AM, Yury Selivanov wrote: > On 2012-06-14, at 12:29 AM, Alexandre Zani wrote: >> Why do we look at __wrapped__ only if the object is a FunctionType? >> Why not support __wrapped__ on all callables? > > Good idea ;)  I'll add th

Re: [Python-Dev] PEP 362 Third Revision

+1 On Thu, Jun 14, 2012 at 9:16 AM, Yury Selivanov wrote: > On 2012-06-14, at 11:24 AM, Brett Cannon wrote: >> On Thu, Jun 14, 2012 at 9:50 AM, Yury Selivanov >> wrote: >> >> [SNIP] >> >> Let's consider replacement of 'Parameter.is_*' set of attributes with >> a single 'Parameter.kind' attribut

Re: [Python-Dev] PEP 362 Third Revision

On Thu, Jun 14, 2012 at 10:10 AM, Brett Cannon wrote: > > > On Thu, Jun 14, 2012 at 12:39 PM, Yury Selivanov > wrote: >> >> On 2012-06-14, at 12:32 PM, Benjamin Peterson wrote: >> >> > 2012/6/14 Yury Selivanov : >> >> On 2012-06-14, at 11:24 AM, Brett Cannon wrote: >> >>> On Thu, Jun 14, 2012 at

Re: [Python-Dev] PEP 362 Third Revision

On Thu, Jun 14, 2012 at 12:57 PM, Antoine Pitrou wrote: > On Thu, 14 Jun 2012 12:46:38 -0700 > Ethan Furman wrote: >> >> This is no different from what we have with strings now: >> >> --> 'aA'.islower() >> False >> --> 'aA'.isupper() >> False >> --> 'a'.islower() >> True >> --> 'A'.isupper() >> T

Re: [Python-Dev] PEP 362 Third Revision

On Thu, Jun 14, 2012 at 1:45 PM, Yury Selivanov wrote: > On 2012-06-14, at 4:24 PM, Benjamin Peterson wrote: > >> 2012/6/14 Alexandre Zani : >>> On Thu, Jun 14, 2012 at 12:57 PM, Antoine Pitrou >>> wrote: >>>> On Thu, 14 Jun 2012 12:46:38 -0700 >&g

Re: [Python-Dev] PEP 362 Third Revision

On Thu, Jun 14, 2012 at 2:00 PM, Benjamin Peterson wrote: > 2012/6/14 Alexandre Zani : >> How about keyword instead of kwonly? I find kwonly clear when >> side-by-side with varkw, but ambiguous standalone. >> >> I like the idea of using args and kwargs just becau

Re: [Python-Dev] PEP 362 Third Revision

On Fri, Jun 15, 2012 at 9:52 AM, Benjamin Peterson wrote: > 2012/6/15 Larry Hastings : >> If I understand you correctly, you seem to be trying to apply >> "is_implemented" to the problem of predicting which specific inputs to a >> parameter would be valid.  I don't think that problem is tractable-

Re: [Python-Dev] PEP 362: 4th edition

-1 implemented It appears to target the problem of platform-dependent parameters. However as was discussed previously, much more common than a parameter simply not being supported on a platform is a parameter supporting different values on different platforms. As such, I think that it solves too s

Re: [Python-Dev] Signed packages

On Fri, Jun 22, 2012 at 9:35 AM, Donald Stufft wrote: > Ideally authors will be signing their packages (using gpg keys). Of course > how to distribute keys is an exercise left to the reader. Key distribution is the real issue though. If there isn't a key distribution infrastructure in place, we m

Re: [Python-Dev] Signed packages

On Fri, Jun 22, 2012 at 9:56 AM, Donald Stufft wrote: > On Friday, June 22, 2012 at 12:54 PM, Alexandre Zani wrote: > > > Key distribution is the real issue though. If there isn't a key > distribution infrastructure in place, we might as well not bother with > signatures

Re: [Python-Dev] PEP 0424: A method for exposing a length hint

On Sat, Jul 14, 2012 at 4:21 PM, Alex Gaynor wrote: > > > On Sat, Jul 14, 2012 at 4:18 PM, Benjamin Peterson > wrote: >> >> 2012/7/14 Alex Gaynor : >> > >> > Proposal >> > >> > >> > This PEP proposes formally documenting ``__length_hint__`` for other >> > interpreter and non-standard lib

Re: [Python-Dev] PEP 0424: A method for exposing a length hint

On Sun, Jul 15, 2012 at 8:08 AM, Mark Shannon wrote: > Brett Cannon wrote: > >> >> >> On Sun, Jul 15, 2012 at 10:39 AM, Mark Shannon > > wrote: >> >> Nick Coghlan wrote: >> >> Right, I agree on the value in being able to return something to >> say "this c