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

[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] Updated PEP 362 (Function Signature Object)

[Alexandre Zani]

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? some_func.__name__ or f.__name__?

On Wed, Jun 6, 2012 at 10:02 AM, Eric Snow  wrote:
> On Wed, Jun 6, 2012 at 10:20 AM, Yury Selivanov  
> wrote:
>> On 2012-06-06, at 11:38 AM, Steven D'Aprano wrote:
>>> Functions already record their name (twice!), and it is simple enough to 
>>> query func.__name__. What reason is there for recording it a third time, in 
>>> the Signature object?
>>
>> Signature object holds function's information and presents it in a
>> convenient manner.  It makes sense to store the function's name,
>> together with the information about its parameters and return
>> annotation.
>>
>>> Besides, I don't consider the name of the function part of the function's 
>>> signature. Functions can have multiple names, or no name at all, and the 
>>> calling signature remains the same.
>>
>> It always have _one_ name it was defined with, unless it's
>> a lambda function.
>>
>>> Even if we limit the discussion to distinct functions (rather than a single 
>>> function with multiple names), I consider spam(x, y, z) ham(x, y, z) and 
>>> eggs(x, y, z) to have the same signature. Otherwise, it makes it difficult 
>>> to talk about one function having the same signature as another function, 
>>> unless they also have the same name. Which would be unfortunate.
>>
>> I see the point ;)  Let's see what other devs think.
>
> I'm with Steven on this one.  What's the benefit to storing the name
> or qualname on the signature object?  That ties the signature object
> to a specific function.  If you access the signature object by
> f.__signature__ then you already have f and its name.  If you get it
> by calling signature(f), then you also have f and the name.  If you
> are passing signature objects for some reason and there's a use case
> for which the name/qualname matters, wouldn't it be better to pass the
> functions around anyway?  What about when you create a signature
> object on its own and you don't care about the name or qualname...why
> should it need them?  Does Signature.bind() need them?
>
> FWIW, I think this PEP is great and am ecstatic that someone is
> pushing it forward.  :)
>
> -eric
> ___
> 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] Updated PEP 362 (Function Signature Object)

[Alexandre Zani]

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 has to be something like this:

class SomeClass(object):
  @dec
  def func(cursor, self, whatever):
 ...

Perhaps the decorator should be smarter about this and detect the fact
that it's dealing with a method but right now, the Signature object
would drop the first argument (cursor) which doesn't seem right.
Perhaps the decorator should set __signature__. I'm not sure.


On Thu, Jun 7, 2012 at 9:04 PM, Yury Selivanov  wrote:
> Nick,
>
> I'm replying to your email (re 'functools.partial') in python-ideas here,
> in the PEP 362 thread, as my response raises some questions regarding its
> design.
>
>> On 2012-06-07, at 11:40 PM, Nick Coghlan wrote:
>>> On Fri, Jun 8, 2012 at 12:57 PM, Yury Selivanov  
>>> wrote:
 Hello,

 While I was working on adding support for 'functools.partial' in PEP 362,
 I discovered that it doesn't do any sanity check on passed arguments
 upon creation.

 Example:

    def foo(a):
        pass

    p = partial(foo, 1, 2, 3) # this line will execute

    p() # this line will fail

 Is it a bug?  Or is it a feature, because we deliberately don't do any 
 checks
 because of performance issues?  If the latter - I think it should be at 
 least
 documented.
>>>
>>> Partly the latter, but also a matter of "this is hard to do, so we
>>> don't even try". There are many other "lazy execution" APIs with the
>>> same problem - they accept an arbitrary underlying callable, but you
>>> don't find out until you try to call it that the arguments don't match
>>> the parameters. This leads to errors being raised far away from the
>>> code that actually introduced the error.
>>>
>>> If you dig up some of the older PEP 362 discussions, you'll find that
>>> allowing developers to reduce this problem over time is the main
>>> reason the Signature.bind() method was added to the PEP. While I
>>> wouldn't recommend it for the base partial type, I could easily see
>>> someone using PEP 362 to create a "checked partial" that ensures
>>> arguments are valid as they get passed in rather than leaving the
>>> validation until the call is actually made.
>
> It's not going to be that easy with the current PEP design.
>
> In order to add support for partial, I had to split the implementation
> of 'bind' into two functions:
>
>    def _bind(self, args, kwargs, *, partial=False):
>        ...
>
>    def bind(self, *args, **kwargs):
>        return self._bind(args, kwargs)
>
> The first one, '_bind' does all the hard work.  When 'partial' flag
> is False - it performs all possible checks.  But if it's 'True', then
> it allows you to bind arguments in the same way 'functools.partial'
> works, but still with most of the validation.
>
> So:
>
>    def foo(a, b, c):
>        pass
>
>    sig = signature(foo)
>
>    sig._bind((1, 2, 3, 4), partial=True) # <- this will fail
>
>    sig._bind((1, 2), partial=True) # <- this is OK
>
>    sig._bind((1, 2), partial=False) # <- this will fail too
>
>
> But the problem is - '_bind' is an implementation detail.
>
> I'd like to discuss changing of PEP 362 'bind' signature to match
> the '_bind' method. This will make API less nice, but will allow more.
>
> Or, we can add something like 'bind_ex' (in addition to 'bind').
>
> -
> 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/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] Updated PEP 362 (Function Signature Object)

[Alexandre Zani]

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):
>>    functools.wraps(f)
>>    def decorated(*args, *kwargs):
>>        cursor = databaseCursor()
>>        return f(cursor, *args, **kwargs)
>>
>> As a result, if the decorated function has to be something like this:
>>
>> class SomeClass(object):
>>  @dec
>>  def func(cursor, self, whatever):
>>     ...
>>
>> Perhaps the decorator should be smarter about this and detect the fact
>> that it's dealing with a method but right now, the Signature object
>> would drop the first argument (cursor) which doesn't seem right.
>> Perhaps the decorator should set __signature__. I'm not sure.
>
> The decorator should set __signature__, since the API of the
> underlying function does not match the public API. I posted an example
> earlier in the thread on how to do that correctly.

OK, makes sense.
>
> 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)

[Alexandre Zani]

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
> "keword_only" or
> "vararg" or
> "kwarg"
>
>
> --
> Regards,
> Benjamin
> ___
> 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

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 constants. That's more stuff to remember.
___
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)

[Alexandre Zani]

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 constants. That's more stuff to remember.
>
> I don't see why remembering 4 names is any harder than remember four 
> attributes.

If it's 4 flags, you can tab-complete on the signature object itself,
the meaning of the flags are self-documenting and if you make a
mistake, you get an AttributeError which is easier to debug. Also,

param.is_args

is much simpler/cleaner than

param.type == "args"

or

param.type == inspect.Parameter.VARARGS

>
>
> --
> Regards,
> Benjamin
___
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] #12982: Should -O be required to *read* .pyo files?

[Alexandre Zani]

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 originator of the issue quotes the following from
>> the doc (without giving the location).
>>
>> "It is possible to have a file called spam.pyc (or spam.pyo when -O is
>> used) without a file spam.py for the same module. This can be used to
>> distribute a library of Python code in a form that is moderately hard to
>> reverse engineer."
>>
>> There is no warning that .pyo files are viral, in a sense. The user has to
>> use -O, which is a) a nuisance to remember if he has multiple scripts and
>> some need it and some not, and b) makes his own .py files used with .pyo
>> imports cached as .pyo, without docstrings, like it or not.
>>
>> Currently, the easiest workaround is to rename .pyo to .pyc and all seems
>> to work fine, even with a mixture of true .pyc and renamed .pyo files. (The
>> same is true with the -O flag and no renaming.) This suggests that there is
>> no current reason for the restriction in that the *execution* of bytecode is
>> not affected by the -O flag. (Another workaround might be a custom importer
>> -- but this is not trivial, apparently.)
>>
>> So is the import restriction either an accident or obsolete holdover? If
>> so, can removing it be treated as a bugfix and put into current releases, or
>> should it be treated as an enhancement only for a future release?
>>
>> Or is the restriction an intentional reservation of the possibility of
>> making *execution* depend on the flag? Which would mean that the restriction
>> should be kept and only the doc changed?
>
>
> I have no history so cannot say what was supposed to happen, but my $0.02
> would be that if -O is *not* specified then we should try to read .pyc, then
> .pyo, and finally .py.  In other words, I vote for -O being a write flag,
> not a read flag.

What if I change .py?

>
> ~Ethan~
>
> ___
> 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] PEP 362 Third Revision

[Alexandre Zani]

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 has a '__signature__' attribute it does a deepcopy
>> of it before return.
>
>
> Properly decorated functions are also supported.
>
> -
> 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/alexandre.zani%40gmail.com

This is really exciting! A couple questions/points:

Why do we look at __wrapped__ only if the object is a FunctionType?
Why not support __wrapped__ on all callables?

Why special-case functools.partial? Couldn't functools.partial just
set __signature__ itself? Is that because of inspect's dependency on
functools?

Just a thought: Do we want to include the docstring? A function's
docstring is often intimately tied to its signature. (Or at least, a
lot of us try to write docstrings that effectively describe the
function's 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

Re: [Python-Dev] PEP 362 Third Revision

[Alexandre Zani]

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 render functions for parameter names,
>>>    annotations and default values, along with custom separators.
>>
>> Hum, what are these "custom render functions"? Can you give an example?
>
> That's how the function looks right now (I'm not sure we should load
> the PEP with this):
>
>    def format(self, *, format_name=str,
>                        format_default=repr,
>                        format_annotation=formatannotation,
>                        format_args=(lambda param: '*' + str(param)),
>                        format_kwargs=(lambda param: '**' + str(param)),
>
>                        token_params_separator=', ',
>                        token_kwonly_separator='*',
>                        token_left_paren='(',
>                        token_right_paren=')',
>                        token_colon=':',
>                        token_eq='=',
>                        token_return_annotation=' -> '):
>
>        '''Format signature to a string.
>
>        Arguments (all optional):
>
>        * format_name : A function to format names of parameters.  Parameter
>          won't be rendered if ``None`` is returned.
>        * format_default : A function to format default values of parameters.
>          Default value won't be rendered if ``None`` is returned.
>        * format_annotation : A function to format parameter annotations.
>          Annotation won't be rendered if ``None`` is returned.
>        * format_args : A function to render ``*args`` like parameters.
>          Parameter won't be rendered if ``None`` is returned.
>        * format_kwargs : A function to render ``**kwargs`` like parameters.
>          Parameter won't be rendered if ``None`` is returned.
>        * token_params_separator : A separator for parameters.  Set to
>          ', ' by default.
>        * token_kwonly_separator : A separator for arguments and
>          keyword-only arguments.  Defaults to '*'.
>        * token_left_paren : Left signature parenthesis, defaults to '('.
>        * token_right_paren : Left signature parenthesis, defaults to ')'.
>        * token_colon : Separates parameter from its annotation,
>          defaults to ':'.
>        * token_eq : Separates parameter from its default value, set to
>          '=' by default.
>        * token_return_annotation : Function return annotation, defaults
>          to ' -> '.
>        '''
>
> I've designed it in such a way, that everything is configurable, so you
> can render functions to color-term, HTML, or whatever else.
>
>>> * 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.
>>
>> Hum, why not using a attribute with a string value instead of 3
>> attribute? For example:
>> * argtype: "index", "varargs", "keyword" or "keyword_only"
>>
>> It would avoid a possible inconsitency (ex: is_args=True and
>> is_kwargs=True). And it would help to implement something like a C
>> switch/case using a dict: argtype => function for functions using
>> signatures.
>
> Originally, I thought the the line:
>
>   if parameters.is_args
>
> is better looking that:
>
>   if parameters.kind == 'vararg'
>
> But, I like your arguments regarding inconsistency and dispatch
> through a dict (someone may find it useful).  Also, Larry gave
> another one - who knows if we add another type of arguments in
> the future.
>
> I guess if nobody really wants to keep 'is_args', we can alter the
> PEP.
>
> Let's consider replacement of 'Parameter.is_*' set of attributes with
> a single 'Parameter.kind' attribute, which will have the following
> possible values: 'positional', 'vararg', 'keyword-only', 'varkwarg'.
>
> (I think 'positional' is more intuitive than 'index'?)
>

I disagree largely for readability reasons. As the PEP stands, I can
look at a Parameter object and immediately understand what the
different possible values are by just listing its attributes. The kind
attribute makes that harder.

Comparing with strings is error prone. If I do param.is_varargs
(adding an s at the end of the attribute name) I will see an attribute
error and know what is going on. If I do the same mistake with the
kind attribute param.kind == "varargs", the expression will just
always be False without any explanation.

>>> * 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 u

Re: [Python-Dev] PEP 362 Third Revision

[Alexandre Zani]

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 this.
>
> Thanks,
> -
> 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] PEP 362 Third Revision

[Alexandre Zani]

+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' attribute, which will have the following
>> possible values: 'positional', 'vararg', 'keyword-only', 'varkwarg'.
>>
>> (I think 'positional' is more intuitive than 'index'?)
>>
>>
>> +1 if this change is made.
>
> How about adding 'kind' and keeping 'is_*' attributes,
> but making them read-only dynamic properties, i.e.:
>
>   class Parameter:
>       ...
>
>       @property
>       def is_vararg(self):
>           return self.kind == 'vararg'
>
>       ...
>
> ?
>
> Thanks,
> -
> 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/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] PEP 362 Third Revision

[Alexandre Zani]

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 9:50 AM, Yury Selivanov
>> >>>  wrote:
>> >>>
>> >>> [SNIP]
>> >>>
>> >>> Let's consider replacement of 'Parameter.is_*' set of attributes with
>> >>> a single 'Parameter.kind' attribute, which will have the following
>> >>> possible values: 'positional', 'vararg', 'keyword-only', 'varkwarg'.
>> >>>
>> >>> (I think 'positional' is more intuitive than 'index'?)
>> >>>
>> >>>
>> >>> +1 if this change is made.
>> >>
>> >> How about adding 'kind' and keeping 'is_*' attributes,
>> >> but making them read-only dynamic properties, i.e.:
>> >>
>> >>   class Parameter:
>> >>       ...
>> >>
>> >>       @property
>> >>       def is_vararg(self):
>> >>           return self.kind == 'vararg'
>> >>
>> >>       ...
>> >>
>> >> ?
>> >
>> > Seems a bit bloatly to me. (One way to do it.)
>>
>> Yes, but on the other hand it solves "strings are error prone"
>> argument, keeps all 'is_*' attributes in sync, and makes them
>> read-only.
>>
>> 'kind' property may do validation on set, to diminish mistakes
>> probability even further.
>
>
> I agree with Benjamin, it goes against TOOWTDI without enough of a
> justification to break the rule. Just make the strings constants on the
> Parameter class and you solve the lack of enum issue.
>
> ___
> 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
>

I don't think it really breaks TOOWTDI because you're talking about
two use-cases. In one case, you're checking if something is a
particular kind of parameter. In the other case, you're doing some
sort of dict-based dispatch. I also think is_args etc is cleaner to
use when doing a comparison:

if param.is_arg:

vs

if param.kind == param.ARG:

That said, it's not a huge deal and so I won't push this any more than
I already have.
___
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] PEP 362 Third Revision

[Alexandre Zani]

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()
>> True
>>
>> We know that a string cannot be both all-upper and all-lower at the same
>> time;
>
> We know that because it's common wisdom for everyone (although who knows
> what oddities the unicode consortium may come up with in the future).
> Whether a given function argument may be of several kinds at the same
> time is much less obvious to most people.

Is it obvious to most people? No. Is it obvious to most users of this
functionality? I would expect so. This isn't some implementation
detail, this is a characteristic of python parameters. If you don't
understand it, you are probably not the audience for signature.

>
> 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] PEP 362 Third Revision

[Alexandre Zani]

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
>>>> 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()
>>>>> True
>>>>>
>>>>> We know that a string cannot be both all-upper and all-lower at the same
>>>>> time;
>>>>
>>>> We know that because it's common wisdom for everyone (although who knows
>>>> what oddities the unicode consortium may come up with in the future).
>>>> Whether a given function argument may be of several kinds at the same
>>>> time is much less obvious to most people.
>>>
>>> Is it obvious to most people? No. Is it obvious to most users of this
>>> functionality? I would expect so. This isn't some implementation
>>> detail, this is a characteristic of python parameters. If you don't
>>> understand it, you are probably not the audience for signature.
>>
>> Consequently, the "kind" model should match up very well with their
>> understanding that a parameter can only be one "kind" at a time.
>
> I myself now like the 'kind' attribute more than 'is_*' family.
> Brett and Larry also voted for it, as well the majority here.
>
> I'll amend the PEP this evening to replace 'is_args', 'is_kwargs',
> and 'is_keyword_only' with a 'kind' attribute, with possible
> values: 'positional', 'vararg', 'varkw', 'kwonly'.
>
> Parameter class will have four constants, respectively:
>
>     class Parameter:
>         KIND_POSITIONAL = 'positional'
>         KIND_VARARG = 'vararg'
>         KIND_VARKW = 'varkw'
>         KIND_KWONLY = 'kwonly'
>
> 'Parameter.is_implemented' will be renamed to 'Parameter.implemented'
>
> Is everybody OK with this?  Thoughts?
>
> I, for instance, like 'varkwarg' more than 'varkw' (+ it is more
> consistent with **kwargs)
>
> -
> Yury

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 because those are the
defacto standard way we refer to that type of argument.
___
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] PEP 362 Third Revision

[Alexandre Zani]

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 because those are the
>> defacto standard way we refer to that type of argument.
>
> That conflates the name of the parameter with what it does.

Agreed, but also easily understood.
>
>
> --
> Regards,
> Benjamin
___
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] PEP 362 Third Revision

[Alexandre Zani]

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--it's way
>> too context-specific.
>
> Exactly! It's too context sensitive to belong on a generic signature
> object. Without is_implemented, all the properties of the signature
> object should only change if you alter the parameter list. How a
> parameter is dealt with in the function should not affect the
> signature of a function.
>

I agree. It seems to me is_implemented solves too small a class of the
problem it attacks to be worth including in the signature.

>
> --
> Regards,
> Benjamin
> ___
> 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] PEP 362: 4th edition

[Alexandre Zani]

-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 small a sub-set of the problem that it attacks to be
useful. Raising exceptions solves the problem.

Furthermore, whether a parameter is implemented or not is not properly
a part of the callable's signature. It's a part of the function's
internals.

On Fri, Jun 15, 2012 at 12:56 PM, Larry Hastings  wrote:
> On 06/15/2012 12:50 PM, Yury Selivanov wrote:
>
> Open questions:
>
> 1. Should we keep 'Parameter.implemented' or not.  *Please vote*
>
>
> +1 to keeping Parameter.implemented.
>
> Let's get this over with,
>
>
> /arry
>
> ___
> 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] Signed packages

[Alexandre Zani]

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 might as well not bother with
signatures. PyPI could issue x509 certs to packagers. You wouldn't be
able to verify that the name given is accurate, but you would be able
to verify that all packages with the same listed author are actually
by that author.

>
> On Friday, June 22, 2012 at 11:48 AM, Vinay Sajip wrote:
>
>  v.loewis.de> writes:
>
>
> See above. Also notice that such signing is already implemented, as part
> of PEP 381.
>
>
> BTW, I notice that the certificate for https://pypi.python.org/ expired a
> week
> ago ...
>
> Regards,
>
> Vinay Sajip
>
>
> ___
> 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/donald.stufft%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/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] Signed packages

[Alexandre Zani]

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. PyPI could issue x509 certs to packagers. You wouldn't be
> able to verify that the name given is accurate, but you would be able
> to verify that all packages with the same listed author are actually
> by that author.
>
> I've been sketching out ideas for key distribution, but it's very much
> a chicken and egg problem, very few people sign their packages (because
> nothing uses it currently), and nobody is motivated to work on
> infrastructure
> or tooling because no one signs their packages.

Are those ideas available publicly? I would love to chip in.
___
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] PEP 0424: A method for exposing a length hint

[Alexandre Zani]

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 library Python to implement.
>> >
>> > ``__length_hint__`` must return an integer, and is not required to be
>> > accurate.
>> > It may return a value that is either larger or smaller than the actual
>> > size of
>> > the container. It may raise a ``TypeError`` if a specific instance
>> > cannot have
>> > its length estimated. It may not return a negative value.
>>
>> And what happens if you return a negative value?
>>
>
> ValueError, the same as with len.
>
>>
>> >
>> > Rationale
>> > =
>> >
>> > Being able to pre-allocate lists based on the expected size, as
>> > estimated by
>> > ``__length_hint__``, can be a significant optimization. CPython has been
>> > observed to run some code faster than PyPy, purely because of this
>> > optimization
>> > being present.
>> >
>> > Open questions
>> > ==
>> >
>> > There are two open questions for this PEP:
>> >
>> > * Should ``list`` expose a kwarg in it's constructor for supplying a
>> > length
>> >   hint.
>> > * Should a function be added either to ``builtins`` or some other module
>> > which
>> >   calls ``__length_hint__``, like ``builtins.len`` calls ``__len__``.
>>
>> Let's try to keep this as limited as possible for a public API.
>>
>
> Sounds reasonable to me!  Should we just go ahead and strip those out now?

I'm +1 on not having a public API for this. Ultimately the contract
for a length hint will depend heavily upon what you need it for. Some
applications would require a length hint to be an "at least" others an
"at most" and others something else entirely. Given that the contract
here appears to be >=0, I don't think the length hint is particularly
useful to the public at large.

>
>>
>>
>> --
>> Regards,
>> Benjamin
>
>
> Alex
>
> --
> "I disapprove of what you say, but I will defend to the death your right to
> say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
>
>
> ___
> 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] PEP 0424: A method for exposing a length hint

[Alexandre Zani]

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 cannot be converted to a concrete container".
>>
>> I still haven't seen a use case where the appropriate response
>> to "I don't know" differs from the appropriate response to a
>> hint of zero - that is, you don't preallocate, you just start
>> iterating.
>>
>>
>> There seem to be 5 possible classes values of __length_hint__ that an
>> iterator object can provide:
>>
>> 1. Don't implement it at all.
>>
>> 2. Implement __length_hint__() but don't want to return any value.
>>Either raise an exception (TypeError) -- As suggested in the PEP.
>>or return NotImplemented -- my preferred option.
>>
>> 3. Return a "don't know" value:
>>Returning 0 would be fine for this, but the VM might want to
>> respond
>>differently to "don't know" and 0.
>> __length_hint__() == 0 container should be
>> minimum size.
>> __length_hint__() == "unknown" container starts at
>> default size.
>>
>>
>> 4. Infinite iterator:
>>Could return float('inf'), but given this is a "hint" then
>>returning sys.maxsize or sys.maxsize + 1 might be OK.
>>Alternatively raise an OverflowError
>>
>>
>> I am really having a hard time differentiating infinity with "I don't
>> know" since they are both accurate from the point of view of __length_hint__
>> and its typical purpose of allocation. You have no clue how many values will
>> be grabbed from an infinite iterator, so it's the same as just not knowing
>> upfront how long the iterator will be, infinite or not, and thus not worth
>> distinguishing.
>>
>>
>> 5. A meaningful length. No problem :)
>>
>> Also, what are the allowable return types?
>>
>> 1. int only
>> 2. Any number (ie any type with a __int__() method)?
>> 3. Or any integer-like object (ie a type with a __index__() method)?
>>
>> My suggestion:
>>
>> a) Don't want to return any value or "don't know": return
>> NotImplemented
>> b) For infinite iterators: raise an OverflowError
>> c) All other cases: return an int or a type with a __index__() method.
>>
>>
>> I'm fine with (a), drop (b), and for (c) use what we allow for __len__()
>> since, as Nick's operator.length_hint pseudo-code suggests, people will call
>> this as a fallback if __len__ isn't defined.
>
>
> So how does an iterator express infinite length?
>
> What should happen if I am silly enough to do this:
 list(itertools.count())
>
> This will fail; it should fail quickly.
>
>
> 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/alexandre.zani%40gmail.com

The PEP so far says: "It may raise a ``TypeError`` if a specific
instance cannot have
its length estimated." In many ways, "I don't know" is the same as
this "specific instance cannot have its length estimated". Why not
just raise a TypeError?

Also, regarding the code Nick posted above, I'm a little concerned
about calling len as the first thing to try. That means that if I
implement both __len__ and __len_hint__ (perhaps because __len__ is
very expensive) __len_hint__ will never be used. It's relatively easy
to say:

try:
  hint = len_hint(l)
except TypeError:
  hint = len(l)
___
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