On Mon, Mar 12, 2012 at 20:51, Guido van Rossum <gu...@python.org> wrote:
> I'm very sympathetic to this PEP. I would accept it outright except I
> have a few quibbles on details, and some questions and remarks.
>
> - There are several examples of poor English grammar, perhaps from
> your co-author. Can you fix these? (Do you need me to produce a list?)
>
Nope. I will do a re-read since it's an old PEP.
>
> - You're using an informal notation to indicate compound types, e.g.
> dict(str, object). I'm not sure it's worth using this particular
> notation without defining it (although maybe the time is ripe for
> creating a PEP that proposes a standard use for parameter
> annotations...). You're also not using it very consistently
>
> - sig.name is currently the unqualified function name. Now we have
> __qualname__ maybe this should be the qualified name instead?
>
Probably.
>
> - Did you think about whether var_args and var_kw_args should be '' or
> None or undefined if these aren't present in the actual definition?
>
It's an open issue in the PEP. Perhaps they can be set to their default
values of () and {}, respectively?
>
> - If there is no return annotation, is return_annotation None or
> undefined? (TBH I think undefined is awkward because you'd have to use
> hasattr() to test for its presence. I'd be okay with equating None
> with no return annotation. For parameter annotations I'm less sure,
> it's not so bad to test for presence in the dict, and you can easily
> use .get().)
>
I think it should be None since that is what the return value is
>
> - I don't quite understand how bind() is supposed to work. Maybe an
> example would help? (It could also use some motivation. I think this
> is meant to expose a canonical version of the algorithm that maps
> arguments to parameters. What's a use case?)
>
Nick addressed this.
>
> - Why is bind() listed under attributes, while there's also a list of
> methods? Is it something funky about self?
>
Probably just an oversight.
>
> - The PEP still seems to support tuple unpacking, which is no longer
> supported in Python 3. Please take it out.
>
Sure thing.
>
> - I see it was my idea to give kw-only parameter a valid but
> meaningless position. I think I want to revert my opinion; it would be
> odd if there's a (kw-only) *parameter* 5 that cannot correspond to
> *argument* 5. So let's set it to None if it's kw-only. Maybe
> sig.parameters should not have these guys? Or it should have a
> separate sig.kw_only_parameters which is a dict??????
>
Yeah, trying to handle these odd cases is one of the reasons I have not
pushed hard for this PEP before. =)
>
> - There is mention of has_annotation but no definition. Is this due to
> a half revision of the PEP? I sort of see the point but maybe it's
> more pragmatic to set it to None for an absent annotation? (Later:
> maybe I see, there's a similar pattern for defaults, and it does make
> sense to distinguish between "x" and "x = y".)
>
I will clarify in the PEP.
>
> - And why are there two ways of getting the annotations, one via
> sig.var_annotations[v] and once via sig[v].annotation ?
>
Probably just made sense for some reason all those years ago.
>
> - Actually I now see there are also, kind of, two ways to access the
> Parameter objects: sig[v] and sig.parameters[i]. But maybe that's more
> defensible since we want to be able to access them by position or by
> name.
>
> - You have some examples like "var_args(*[1,2,3])" -- I think that
> should just be "var_args(1, 2, 3)" right? Similar "var_kw_args(**{'a':
> 1})" should be "var_kw_args(a=1)"...
>
>
Quite possibly.
> - You have some example code using try: <some dict>[<some key>] //
> except KeyError: pass // else: <code>. Wouldn't that be expressed
> cleaner using if <key> in <dict>: <block> ?
>
Yes. =)
>
> - Similar, this smells a bit; can you explain or improve?
> try:
> duck = sig.var_annotations[sig.var_kw_args]
> except (KeyError, AttributeError):
>
>
Sure.
-Brett
> That's all I have for now; on to reject^Wreview some more PEPs...
>
> --
> --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/brett%40python.org
>
_______________________________________________
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
