[Python-Dev] next alpha sequence value from var pointing to array

[jdmorgan]

Hello,

I am hoping that this list is a good place to ask this question.I am 
still fairly new to python, but find it to be a great scripting 
language.Here is my issue:


I am attempting to utilize a function to receive any sequence of letter 
characters and return to me the next value in alphabetic order e.g. send 
in "abc" get back "abd".I found a function on StackExchange (Rosenfield, 
A 1995) that seems to work well enough (I think):


def next(s):

strip_zs = s.rstrip('z')

if strip_zs:

return strip_zs[:-1] + chr(ord(strip_zs[-1]) + 1) + 'a' * (len(s) - 
len(strip_zs))


else:

return 'a' * (len(s) + 1)

I have found this function works well if I call it directly with a 
string enclosed in quotes:


returnValue = next("abc")

However, if I call the function with a variable populated from a value I 
obtain from an array[] it fails returning only ^K


Unfortunately, because I don't fully understand this next function I 
can't really interpret the error.Any help would be greatly appreciated.


Thanks ahead of time,

Derek

___
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] next alpha sequence value from var pointing to array

[Nick Coghlan]

On Thu, Jun 7, 2012 at 12:32 PM, jdmorgan  wrote:
> Hello,
>
> I am hoping that this list is a good place to ask this question.

Close, but not quite the right place. This is a list for the design
and development *of* Python itself, rather than a list for using
Python.

For this kind of question, you want python-l...@python.org.

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 (3.2): #14957: clarify splitlines docs.

[Sam Partington]

> On Jun 2, 2012 6:21 AM, "r.david.murray"  wrote:
>> +   For example, ``'ab c\n\nde fg\rkl\r\n'.splitlines()`` returns
>> +   ``['ab c', '', 'de fg', 'kl']``, while the same call with
>> ``splinelines(True)``
>> +   returns ``['ab c\n', '\n, 'de fg\r', 'kl\r\n']``

Wouldn't that be better written as a doctest and so avoid any other typos?

Sam
___
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)

[Steven D'Aprano]

Nick Coghlan wrote:

On Thu, Jun 7, 2012 at 8:38 AM, Steven D'Aprano  wrote:

Brett Cannon wrote:

This is also Python, the language that assumes everyone is an consenting
adult.


Exactly, which is why I'm not asking for __signature__ to be immutable. Who
knows, despite Larry's skepticism (and mine!), perhaps there is a use-case
for __signature__ being modified that we haven't thought of yet.
But that's not really the point. It may be that nobody will be stupid enough
to mangle __signature__, and inspect.getfullargspec becomes redundant.


I've presented use cases for doing this already. Please stop calling me stupid.


I'm sorry Nick, I missed your email and my choice of words was poor. Please 
accept my apologies.




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

[Nick Coghlan]

On Thu, Jun 7, 2012 at 10:04 PM, Steven D'Aprano  wrote:
> Nick Coghlan wrote:
>> I've presented use cases for doing this already. Please stop calling me
>> stupid.
>
> I'm sorry Nick, I missed your email and my choice of words was poor. Please
> accept my apologies.

Thanks and no worries. I can definitely see how it would seem like a
crazy thing to do if you weren't looking at the problem specifically
from a callable wrapping point of view :)

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 (3.2): #14957: clarify splitlines docs.

[R. David Murray]

On Thu, 07 Jun 2012 11:08:09 +0100, Sam Partington  
wrote:
> > On Jun 2, 2012 6:21 AM, "r.david.murray"  wrote:
> >> +   For example, ``'ab c\n\nde fg\rkl\r\n'.splitlines()`` returns
> >> +   ``['ab c', '', 'de fg', 'kl']``, while the same call with
> >> ``splinelines(True)``
> >> +   returns ``['ab c\n', '\n, 'de fg\r', 'kl\r\n']``
> 
> Wouldn't that be better written as a doctest and so avoid any other typos?

Possibly, except (1) I don't think we currently actually test the doctests
in the python docs and (2) I'm following the style of the surrounding text
(the split examples just above this are in the same inline style.  Oh, and
(3) it would make the text longer, which could be considered a negative.

I have no objection myself to someone reformatting it, but if that is
done the whole chapter should be gone over and given a consistent style.

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

[Michael Foord]

On 6 Jun 2012, at 18:28, Yury Selivanov wrote:

> On 2012-06-06, at 1:13 PM, Alexandre Zani wrote:
>> 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__?
> 
> Never copy attributes by hand, always use 'functools.wraps'.  It copies
> '__name__', '__qualname__', and bunch of other attributes to the decorator 
> object.
> 
> We'll probably extend it to copy __signature__ too; then 'signature(decor(f))'
> will be the same as 'signature(f)'.
> 


I don't think functools.wraps can copy the signature by default - it's not 
uncommon to have decorators that modify signatures. A new parameter to 
functools.wraps defaulting to False?

Michael

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

[Yury Selivanov]

On 2012-06-07, at 9:28 AM, Michael Foord wrote:
> On 6 Jun 2012, at 18:28, Yury Selivanov wrote:
>> On 2012-06-06, at 1:13 PM, Alexandre Zani wrote:
>> Never copy attributes by hand, always use 'functools.wraps'.  It copies
>> '__name__', '__qualname__', and bunch of other attributes to the decorator 
>> object.
>> 
>> We'll probably extend it to copy __signature__ too; then 
>> 'signature(decor(f))'
>> will be the same as 'signature(f)'.
>> 
> 
> I don't think functools.wraps can copy the signature by default - it's not 
> uncommon to have decorators that modify signatures. A new parameter to 
> functools.wraps defaulting to False?



http://mail.python.org/pipermail/python-dev/2012-June/120021.html

We just won't copy it at all. See the link above.

'functools.wraps' already sets '__wrapped__' reference to the wrapped function,
so we can easily traverse the chain to either first function with __signature__ 
defined, or to the most inner-decorated function and get a signature for it.

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

[Yury Selivanov]

Nick,

On 2012-06-07, at 2:56 AM, Nick Coghlan wrote:
> On Thu, Jun 7, 2012 at 11:16 AM, Yury Selivanov  
> wrote:
>> On 2012-06-06, at 9:00 PM, Nick Coghlan wrote:
>> So, the idea for the 'signature(obj)' function is to first check if
>> 'obj' has '__signature__' attribute set, if yes - return it, if no -
>> create a new one (but don't cache).
> 
> I'd say return a copy in the first case to be safe against accidental
> modification. If someone actually wants in-place modification, they
> can access __signature__ directly.

OK.  And I'll implement __copy__ and __deepcopy__ for Signatures.

> Bonus: without implicit signature copying in functools, you can stick
> with the plan of exposing everything via the inspect module.

Exactly!

> We should still look into making whatever tweaks are needed to let
> inspect.signature correctly handle functools.partial objects, though.

Seems doable.  'partial' exposes 'func', 'args' and 'keywords' attributes,
so we have all the information we need.

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

[Nick Coghlan]

On Thu, Jun 7, 2012 at 11:28 PM, Michael Foord
 wrote:
>> We'll probably extend it to copy __signature__ too; then 
>> 'signature(decor(f))'
>> will be the same as 'signature(f)'.
>
> I don't think functools.wraps can copy the signature by default - it's not 
> uncommon to have decorators that modify signatures. A new parameter to 
> functools.wraps defaulting to False?

Most wrapped functions already report the wrong signature under
introspection anyway (typically (*args, **kwds)). Following the
__wrapped__ chains by default will produce an answer that is more
likely to be correct in such cases.

The big win from my point of view is that thanks to __signature__,
decorators that modify the signature will now have the opportunity to
retrieve the signature from the underlying function and accurately
report a *different* signature.

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)

[Larry Hastings]

On 06/06/2012 11:56 PM, Nick Coghlan wrote:

I'd say return a copy in the first case to be safe against accidental
modification. If someone actually wants in-place modification, they
can access __signature__ directly.


I really don't understand this anxiety about mutable Signature objects.  
Can you give a plausible example of "accidental modification" of a 
Signature object?  I for one--as clumsy as I am--cannot recall ever 
"accidentally" modifying an object.


I really don't think signature() should bother copying/deep-copying the 
Signature before returning it.



//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/archive%40mail-archive.com

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

[Larry Hastings]

On 06/06/2012 06:00 PM, Nick Coghlan wrote:

On Thu, Jun 7, 2012 at 10:52 AM, Eric Snow  wrote:

Furthermore, using __signature__ as a cache may even cause problems.
If the Signature object is cached then any changes to the function
will not be reflected in the Signature object.  Certainly that's an
unlikely case, but it is a real case. [...]

+1


I'm missing something here.  Can you give me an example of modifying an 
existing function object such that its Signature would change?  
Decorators implementing a closure with a different signature don't 
count--they return a new function object.




Providing a defined mechanism to declare a public signature is good,
but using that mechanism for implicit caching seems like a
questionable idea. Even when it *is* cached, I'd be happier if
inspect.signature() returned a copy rather than a direct reference to
the original.


I'll say this: if we're going down this road of "don't cache Signature 
objects", then in the case of __signature__ we should definitely return 
a copy just for consistency's sakes.  It'd be a miserable implementation 
if signature() sometimes returned the same object and sometimes returned 
different but equivalent objects when called multiple times on the same 
object.



//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/archive%40mail-archive.com

[Python-Dev] PEP 362 Second Revision

[Yury Selivanov]

Hello,

The new revision of PEP 362 has been posted: 
http://www.python.org/dev/peps/pep-0362/

Thanks to Brett, Larry, Nick, and everybody else on python-dev
for your corrections/suggestions.

Summary of changes:

1. We don't cache signatures in __signature__ attribute implicitly

2. signature() function is now more complex, but supports methods,
partial objects, classes, callables, and decorated functions

3. Signatures are always constructed on demand

4. Dropped the deprecation section

The implementation is not aligned with the latest PEP yet, 
I'll try to update it tonight.

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

[R. David Murray]

On Thu, 07 Jun 2012 07:00:29 -0700, Larry Hastings  wrote:
> On 06/06/2012 11:56 PM, Nick Coghlan wrote:
> > I'd say return a copy in the first case to be safe against accidental
> > modification. If someone actually wants in-place modification, they
> > can access __signature__ directly.
> 
> I really don't understand this anxiety about mutable Signature objects.  
> Can you give a plausible example of "accidental modification" of a 
> Signature object?  I for one--as clumsy as I am--cannot recall ever 
> "accidentally" modifying an object.

Maybe it would make more sense if you read that as "naively" rather than
"accidentally"?

In the 3.3 email extension I made a similar decision, although there I
went even further and made the objects read only.  My logic for doing
this is that a naive user would...naively...try to set the attributes
and expect the object they got it from to change, but that object (a
string subclass) is inherently read-only.

I am thinking that in fact we may ultimately want to return copies of
these objects that are mutable, because that might be useful, but I'm
starting with read-only because it is easy to make them mutable later
but pretty much impossible (backward compatibility wise) to make them
immutable if they start mutable.

I see the signature object as a very parallel case to this, except that
it is already obvious that having them be a mutable copy is useful.

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

[Yury Selivanov]

On 2012-06-07, at 10:45 AM, R. David Murray wrote:
> On Thu, 07 Jun 2012 07:00:29 -0700, Larry Hastings  wrote:
>> On 06/06/2012 11:56 PM, Nick Coghlan wrote:
>>> I'd say return a copy in the first case to be safe against accidental
>>> modification. If someone actually wants in-place modification, they
>>> can access __signature__ directly.
>> 
>> I really don't understand this anxiety about mutable Signature objects.  
>> Can you give a plausible example of "accidental modification" of a 
>> Signature object?  I for one--as clumsy as I am--cannot recall ever 
>> "accidentally" modifying an object.
> 
> Maybe it would make more sense if you read that as "naively" rather than
> "accidentally"?
> 
> In the 3.3 email extension I made a similar decision, although there I
> went even further and made the objects read only.  My logic for doing
> this is that a naive user would...naively...try to set the attributes
> and expect the object they got it from to change, but that object (a
> string subclass) is inherently read-only.
> 
> I am thinking that in fact we may ultimately want to return copies of
> these objects that are mutable, because that might be useful, but I'm
> starting with read-only because it is easy to make them mutable later
> but pretty much impossible (backward compatibility wise) to make them
> immutable if they start mutable.
> 
> I see the signature object as a very parallel case to this, except that
> it is already obvious that having them be a mutable copy is useful.

I think the copy approach is better for Signatures, the immutability.
It should be OK to, for instance, get a signature, modify some parameters 
information, and then try to bind some arguments.

Again, there's a care for decorators, where they get a signature, and
modify it, as the wrapper's signature is different from the original
function's.

-
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] [Python-checkins] peps: Update 422 based on python-dev feedback

[Daniel Urban]

On Thu, Jun 7, 2012 at 2:08 PM, nick.coghlan  wrote:
> -* If the metaclass hint refers to an instance of ``type``, then it is
> +* If the metaclass hint refers to a subclass of ``type``, then it is
>   considered as a candidate metaclass along with the metaclasses of all of
>   the parents of the class being defined. If a more appropriate metaclass is
>   found amongst the candidates, then it will be used instead of the one

I think here "instance" was correct (see
http://hg.python.org/cpython/file/default/Lib/types.py#l76 and
http://hg.python.org/cpython/file/cedc68440a67/Python/bltinmodule.c#l90).


Daniel
___
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)

[Eric Snow]

On Wed, Jun 6, 2012 at 11:10 AM, Yury Selivanov  wrote:
> On 2012-06-06, at 1:02 PM, Eric Snow wrote:
>> 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?
>
> Yes, 'Signature.bind' needs 'qualname' for error messages.  But it can be
> stored as a private attribute.
>
> I like the idea of 'foo(a)' and 'bar(a)' having the identical signatures,
> however, I don't think it's possible.  I.e. we can't make it that the
> 'signature(foo) is signature(bar)'.  We can implement the __eq__ operator
> though.

Adding __eq__ and __ne__ is a good thing.  However, I don't care so
much about the identity/equality relationship as I do about the
relationship between Signature objects and functions.

Regarding name and qualname, several questions:

* Is the use of qualname in errors part of the PEP or an implementation detail?
* Can name and qualname be None?
* If so, do the errors that rely on them still work?
* What do you get when you pass a lambda to inspect.signature()?

Thinking more about this, for me this PEP is more about call
signatures than about function declaration signatures.  For a call you
don't need the callable's name (think lambdas).  Having a name and
qualname attribute communicates that Signature objects are indelibly
tied to functions.  So I still don't think name and qualname are
intrinsic attributes to call signatures.

In the end this is a relatively minor point that does not detract from
my support of this PEP.  I just think we should strip any superfluous
details we can now.  Adding things later is easier than taking them
away.  :)

Warning: the following may seem to contradict what I said above.  Take
it for what it's worth.  Regardless of name/qualname, it may be useful
to keep a weak reference on the Signature object to the function on
which it is based, *if any*.  That's not essential to the concept of
call signatures, but it could still be meaningful for introspection.

Alternately, let's consider the case where the PEP actually is all
about introspecting function declarations (rather than call
signatures).  Then the attributes of a Signature object could just be
properties exposing the underlying details from the attached
function/code object.

And finally, keep up the good work!

-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/archive%40mail-archive.com

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

[Eric Snow]

On Thu, Jun 7, 2012 at 8:12 AM, Larry Hastings  wrote:
> On 06/06/2012 06:00 PM, Nick Coghlan wrote:
>
>> On Thu, Jun 7, 2012 at 10:52 AM, Eric Snow 
>> wrote:
>>
>> Furthermore, using __signature__ as a cache may even cause problems.
>> If the Signature object is cached then any changes to the function
>> will not be reflected in the Signature object.  Certainly that's an
>> unlikely case, but it is a real case. [...]
>
> +1
>
>
> I'm missing something here.  Can you give me an example of modifying an
> existing function object such that its Signature would change?  Decorators
> implementing a closure with a different signature don't count--they return a
> new function object.

I doubt there are any but corner cases to demonstrate here.  I'd don't
presume to say what use there may be in changing a function's state.
However, the fact is that a change to any of the following would cause
a cached __signature__ to be out of sync:

* f.__annotations__
* f.__closure__
* f.__code__
* f.__defaults__
* f.__globals__
* f.__kwdefaults__
* f.__name__
* f.__qualname__

All of these are at least replaceable, if not mutable.   If
inspect.signature() is intended for function introspection purposes,
I'd expect it's return value (cached on __signature__ or not) to
reflect the function and not a previous state of the function.  I
prefer the idea that f.__signature__ means it was set explicitly.
Then there's no doubt as to what it's meant to reflect.

>> Providing a defined mechanism to declare a public signature is good,
>> but using that mechanism for implicit caching seems like a
>> questionable idea. Even when it *is* cached, I'd be happier if
>> inspect.signature() returned a copy rather than a direct reference to
>> the original.
>
>
> I'll say this: if we're going down this road of "don't cache Signature
> objects", then in the case of __signature__ we should definitely return a
> copy just for consistency's sakes.  It'd be a miserable implementation if
> signature() sometimes returned the same object and sometimes returned
> different but equivalent objects when called multiple times on the same
> object.

+1

-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/archive%40mail-archive.com

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

[Yury Selivanov]

Eric,

On 2012-06-07, at 12:54 PM, Eric Snow wrote:
> On Wed, Jun 6, 2012 at 11:10 AM, Yury Selivanov  
> wrote:
>> I like the idea of 'foo(a)' and 'bar(a)' having the identical signatures,
>> however, I don't think it's possible.  I.e. we can't make it that the
>> 'signature(foo) is signature(bar)'.  We can implement the __eq__ operator
>> though.
> 
> Adding __eq__ and __ne__ is a good thing.  

We still don't have a good use case for this, though.

> However, I don't care so
> much about the identity/equality relationship as I do about the
> relationship between Signature objects and functions.

Yes, that's the core issue we have - the relation between Signature
objects and functions.

> Regarding name and qualname, several questions:
> 
> * Is the use of qualname in errors part of the PEP or an implementation 
> detail?

It's more of an implementation detail.  And those errors may be not 
that important, after all.  Probably, the 'Signature.bind()' will be 
used in contexts where you have either the function itself, or at 
least its name to catch the BindError and add some context to it.

> * Can name and qualname be None?

There is no explicit check for it in the code.

Given the fact, that we now want ''signature()'' to work with any
callable, it may be that the callable object doesn't have '__name__'
and '__qualname__' attributes (unless we copy them from its __call__,
and that's a doubtful move)

> * If so, do the errors that rely on them still work?

The code will break.

> * What do you get when you pass a lambda to inspect.signature()?

It will work fine, since lambdas are instances of FunctionType.

> Thinking more about this, for me this PEP is more about call
> signatures than about function declaration signatures.  For a call you
> don't need the callable's name (think lambdas).  Having a name and
> qualname attribute communicates that Signature objects are indelibly
> tied to functions.  So I still don't think name and qualname are
> intrinsic attributes to call signatures.

Yes, you're right.  Brett and Larry also leaning towards defining
Signature as a piece of information about the call semantics,
disconnected from the function.

I like this too, it makes everything simpler.

I think we'll modify the PEP today, to drop 'name' and 'qualname' from
Signature, and implement __eq__.

> In the end this is a relatively minor point that does not detract from
> my support of this PEP.  I just think we should strip any superfluous
> details we can now.  Adding things later is easier than taking them
> away.  :)

Thanks :)  You're right, we can add 'name' and 'qualname' later.

> Warning: the following may seem to contradict what I said above.  Take
> it for what it's worth.  Regardless of name/qualname, it may be useful
> to keep a weak reference on the Signature object to the function on
> which it is based, *if any*.  That's not essential to the concept of
> call signatures, but it could still be meaningful for introspection.

I think that maintaining an explicit link between functions and 
signatures (by passing them around together, or just by passing the 
function and calculating signature out of it when needed) in the user 
code is better, than do it implicitly in the Signature.

Let's not overcomplicate it all ;)

> Alternately, let's consider the case where the PEP actually is all
> about introspecting function declarations (rather than call
> signatures).  Then the attributes of a Signature object could just be
> properties exposing the underlying details from the attached
> function/code object.

How about that later, if needed, we'll add another object to 'inspect',
that will have this information about the function, and will also 
have its signature?

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

[Larry Hastings]

On 06/07/2012 10:08 AM, Eric Snow wrote:

I'm missing something here.  Can you give me an example of modifying an
existing function object such that its Signature would change?  Decorators
implementing a closure with a different signature don't count--they return a
new function object.

I doubt there are any but corner cases to demonstrate here.  I'd don't
presume to say what use there may be in changing a function's state.
However, the fact is that a change to any of the following would cause
a cached __signature__ to be out of sync:

* f.__annotations__
* f.__closure__
* f.__code__
[... other dunder attributes elided ...]


In other words: this is possible but extremely unlikely, and will only 
be done knowingly and with deliberate intent by a skilled practitioner.


I think it's reasonable to declare that, if you're monkeying around with 
dunder attributes on a function, it's up to you to clear the 
f.__signature__ cache if it's set.  Like Spiderman's uncle Cliff 
Robertson said: with great power comes great responsibility.


I am now firmly in the "using __signature__ as a cache is fine, don't 
make copies for no reason" camp.



//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/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython (3.2): Nudge readers towards a more accurate mental model for loop else clauses

[Terry Reedy]

On 6/7/2012 8:42 AM, nick.coghlan wrote:

http://hg.python.org/cpython/rev/6e4ec47fba6a
changeset:   77369:6e4ec47fba6a
branch:  3.2
parent:  77363:aa9cfeea07ad
user:Nick Coghlan
date:Thu Jun 07 22:41:34 2012 +1000
summary:
   Nudge readers towards a more accurate mental model for loop else clauses

files:
   Doc/tutorial/controlflow.rst |  7 +++
   1 files changed, 7 insertions(+), 0 deletions(-)


diff --git a/Doc/tutorial/controlflow.rst b/Doc/tutorial/controlflow.rst
--- a/Doc/tutorial/controlflow.rst
+++ b/Doc/tutorial/controlflow.rst
@@ -187,6 +187,13 @@
  (Yes, this is the correct code.  Look closely: the ``else`` clause belongs to
  the :keyword:`for` loop, **not** the :keyword:`if` statement.)

+When used with a loop, the ``else`` clause has more in common with the
+``else`` clause of a :keyword:`try` statement than it does that of
+:keyword:`if` statements: a :keyword:`try` statement's ``else`` clause runs
+when no exception occurs,


(And there no return. But that is true of of every statement.)

I think the above is wrong.

I claim that try-statement else: is essentially identical to 
if-statement else:. The try-statement else: clause is subordinate to the 
except: clauses, not the try: part itself. It must follow at least one 
except condition just as an if-statement must follow at least one if 
condition. So it is really an except else, not a try else.


Furthermore, 'except SomeError' is an abbreviation for 'if/elif 
SomeError was raised since the corresponding try' and more particularly 
'if/elif isinstance(__exception__, SomeError). I use __exception__ here 
as the equivalent of C's errno, except that it is hidden. (If it were 
not hidden, we would not need 'as e', and indeed, we would not really 
need 'except' either.) The else clause runs when all the implied 
conditionals of the excepts are false. Just as an if-statement else 
clause runs when all the explicit conditionals of the if/elifs are false.


The real contrast is between if/except else and loop else. The latter is 
subordinate to exactly one condition instead of possibly many, but that 
one condition may be evaluated multiple times instead of just once. It 
is the latter fact that seems to confuse people.



and a loop's ``else`` clause runs when no ``break`` occurs.


As I explained on Python-ideas, the else clause runs when the loop 
condition is false. Period. This sentence is an incomplete equivalent to 
'the loop condition is false'. The else clause runs when no 'break', no 
'return', no 'raise' (explicit or implicit), AND no infinite loop occurs.


I think your addition should be reverted. Here is a possible alternative 
if you think something more is needed.


"An else clause used with a loop has two differences from an else clause 
used with an if statement. It is subordinate to just one condition 
instead of possibly many. (In for statements, the condition is implicit 
but still there.) That one condition is tested repeatedly instead of 
just once. A loop else is the same in that it triggers when that one 
condition is false."


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

[Terry Reedy]

On 6/7/2012 10:41 AM, Yury Selivanov wrote:

Hello,

The new revision of PEP 362 has been posted:
http://www.python.org/dev/peps/pep-0362/

Thanks to Brett, Larry, Nick, and everybody else on python-dev
for your corrections/suggestions.

Summary of changes:

1. We don't cache signatures in __signature__ attribute implicitly

2. signature() function is now more complex, but supports methods,
partial objects, classes, callables, and decorated functions

3. Signatures are always constructed on demand

4. Dropped the deprecation section


I like this now. Being more able to get the actual signature of partials 
and wraps will be a win. If the signature object has a decent 
__str__/__repr__ method, I would (try to remember) to revise idle 
tooltips (for whichever version) to check for .__signature__ before 
inspect'ing.


--
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] [Python-checkins] peps: Update 422 based on python-dev feedback

[Daniel Urban]

On Thu, Jun 7, 2012 at 9:47 PM, Terry Reedy  wrote:
> On 6/7/2012 11:45 AM, Daniel Urban wrote:
>>
>> On Thu, Jun 7, 2012 at 2:08 PM, nick.coghlan
>>  wrote:
>>>
>>> -* If the metaclass hint refers to an instance of ``type``, then it is
>>> +* If the metaclass hint refers to a subclass of ``type``, then it is
>>>   considered as a candidate metaclass along with the metaclasses of all
>>> of
>>>   the parents of the class being defined. If a more appropriate metaclass
>>> is
>>>   found amongst the candidates, then it will be used instead of the one
>>
>>
>> I think here "instance" was correct (see
>> http://hg.python.org/cpython/file/default/Lib/types.py#l76 and
>> http://hg.python.org/cpython/file/cedc68440a67/Python/bltinmodule.c#l90).
>
>
> If so, then the behavior of the standard case of a type subclass is not
> obviously (to me) covered.

A subclass of type is also necessarily an instance of type, so that is
also covered by this case.


Daniel
___
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 Second Revision

[Yury Selivanov]

On 2012-06-07, at 3:54 PM, Terry Reedy wrote:
> On 6/7/2012 10:41 AM, Yury Selivanov wrote:
>> Hello,
>> 
>> The new revision of PEP 362 has been posted:
>> http://www.python.org/dev/peps/pep-0362/
>> 
>> Thanks to Brett, Larry, Nick, and everybody else on python-dev
>> for your corrections/suggestions.
>> 
>> Summary of changes:
>> 
>> 1. We don't cache signatures in __signature__ attribute implicitly
>> 
>> 2. signature() function is now more complex, but supports methods,
>> partial objects, classes, callables, and decorated functions
>> 
>> 3. Signatures are always constructed on demand
>> 
>> 4. Dropped the deprecation section
> 
> I like this now. Being more able to get the actual signature of partials and 
> wraps will be a win. If the signature object has a decent __str__/__repr__ 
> method, I would (try to remember) to revise idle tooltips (for whichever 
> version) to check for .__signature__ before inspect'ing.

I think we'll add a 'format' method to the Signature, that will work
like 'inspect.formatargspec'.  'Signature.__str__' will use it with
default parameters/formatters.

I'm not sure how __repr__ should look like.  Maybe default repr
(object.__repr__) is good enough.

-
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 Second Revision

[Yury Selivanov]

On 2012-06-07, at 5:39 PM, Terry Reedy wrote:

> On 6/7/2012 4:54 PM, Yury Selivanov wrote:
> 
>> I think we'll add a 'format' method to the Signature, that will work
>> like 'inspect.formatargspec'.  'Signature.__str__' will use it with
>> default parameters/formatters.
> 
> Great. If I don't like the default, I could customize.

Can you tell me how do you use those customizations (i.e.
formatvarargs, formatarg and other arguments of formatargspec)?

>> I'm not sure how __repr__ should look like.  Maybe default repr
>> (object.__repr__) is good enough.
> 
> __repr__ = __str__ is common.
> 
> Idle tooltips use an re to strip 'self[, ]' from the inspect.formatargspec 
> result*. I have revised the code to only do that when appropriate (for bound 
> instance methods and callable instances), which is to say, when the user has 
> already entered the object that will become the self parameter). If signature 
> does the same, I might delete the code and use the signature object instead.
> 
> *The same could be done for class methods, but I am not sure that 'cls' is 
> standard enough to bother. Of course, any function using anything other than 
> 'self' will also not see the deletion. Come to think of it, now that I am 
> doing the search-and-replace conditionally rather than always, I can and 
> should re-write the re to remove the first name rather than 'self' 
> specifically. It will be good to have all such signature manipulations done 
> correctly in one place.

Well, signature won't strip parameters based on their names, but rather
based on the callable type.  If it's a method, than no matter how
its first parameter is named - it will be omitted.  Same applies for 
classmethods.

-
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] [Python-checkins] cpython (3.2): Nudge readers towards a more accurate mental model for loop else clauses

[Nick Coghlan]

The inaccuracies in the analogy are why this is in the tutorial, not the
language reference. All 3 else clauses are really their own thing. For if
statements, the full construct is "if/elif/else", for loops it is
"for/break/else" and "while/break/else" and for try statements it is
"try/except/else". Early returns and uncaught exceptions will skip any of
the three.

However, emphasising the link to if statements has been demonstrably
confusing for years, due to the interpretation of empty iterables as False
in a boolean context. The new text is intended to emphasise that, no, the
for loop else clause does *not* map directly to an if statement that checks
that iterable.

--
Sent from my phone, thus the relative brevity :)
On Jun 8, 2012 5:12 AM, "Terry Reedy"  wrote:

>
>
> On 6/7/2012 8:42 AM, nick.coghlan wrote:
>
>> http://hg.python.org/cpython/**rev/6e4ec47fba6a
>> changeset:   77369:6e4ec47fba6a
>> branch:  3.2
>> parent:  77363:aa9cfeea07ad
>> user:Nick Coghlan
>> date:Thu Jun 07 22:41:34 2012 +1000
>> summary:
>>   Nudge readers towards a more accurate mental model for loop else clauses
>>
>> files:
>>   Doc/tutorial/controlflow.rst |  7 +++
>>   1 files changed, 7 insertions(+), 0 deletions(-)
>>
>>
>> diff --git a/Doc/tutorial/controlflow.rst b/Doc/tutorial/controlflow.rst
>> --- a/Doc/tutorial/controlflow.rst
>> +++ b/Doc/tutorial/controlflow.rst
>> @@ -187,6 +187,13 @@
>>  (Yes, this is the correct code.  Look closely: the ``else`` clause
>> belongs to
>>  the :keyword:`for` loop, **not** the :keyword:`if` statement.)
>>
>> +When used with a loop, the ``else`` clause has more in common with the
>> +``else`` clause of a :keyword:`try` statement than it does that of
>> +:keyword:`if` statements: a :keyword:`try` statement's ``else`` clause
>> runs
>> +when no exception occurs,
>>
>
> (And there no return. But that is true of of every statement.)
>
> I think the above is wrong.
>
> I claim that try-statement else: is essentially identical to if-statement
> else:. The try-statement else: clause is subordinate to the except:
> clauses, not the try: part itself. It must follow at least one except
> condition just as an if-statement must follow at least one if condition. So
> it is really an except else, not a try else.
>
> Furthermore, 'except SomeError' is an abbreviation for 'if/elif SomeError
> was raised since the corresponding try' and more particularly 'if/elif
> isinstance(__exception__, SomeError). I use __exception__ here as the
> equivalent of C's errno, except that it is hidden. (If it were not hidden,
> we would not need 'as e', and indeed, we would not really need 'except'
> either.) The else clause runs when all the implied conditionals of the
> excepts are false. Just as an if-statement else clause runs when all the
> explicit conditionals of the if/elifs are false.
>
> The real contrast is between if/except else and loop else. The latter is
> subordinate to exactly one condition instead of possibly many, but that one
> condition may be evaluated multiple times instead of just once. It is the
> latter fact that seems to confuse people.
>
>  and a loop's ``else`` clause runs when no ``break`` occurs.
>>
>
> As I explained on Python-ideas, the else clause runs when the loop
> condition is false. Period. This sentence is an incomplete equivalent to
> 'the loop condition is false'. The else clause runs when no 'break', no
> 'return', no 'raise' (explicit or implicit), AND no infinite loop occurs.
>
> I think your addition should be reverted. Here is a possible alternative
> if you think something more is needed.
>
> "An else clause used with a loop has two differences from an else clause
> used with an if statement. It is subordinate to just one condition instead
> of possibly many. (In for statements, the condition is implicit but still
> there.) That one condition is tested repeatedly instead of just once. A
> loop else is the same in that it triggers when that one condition is false."
>
> ---
> 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/**
> ncoghlan%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 Second Revision

[Terry Reedy]

On 6/7/2012 4:54 PM, Yury Selivanov wrote:


I think we'll add a 'format' method to the Signature, that will work
like 'inspect.formatargspec'.  'Signature.__str__' will use it with
default parameters/formatters.


Great. If I don't like the default, I could customize.


I'm not sure how __repr__ should look like.  Maybe default repr
(object.__repr__) is good enough.


__repr__ = __str__ is common.

Idle tooltips use an re to strip 'self[, ]' from the 
inspect.formatargspec result*. I have revised the code to only do that 
when appropriate (for bound instance methods and callable instances), 
which is to say, when the user has already entered the object that will 
become the self parameter). If signature does the same, I might delete 
the code and use the signature object instead.


*The same could be done for class methods, but I am not sure that 'cls' 
is standard enough to bother. Of course, any function using anything 
other than 'self' will also not see the deletion. Come to think of it, 
now that I am doing the search-and-replace conditionally rather than 
always, I can and should re-write the re to remove the first name rather 
than 'self' specifically. It will be good to have all such signature 
manipulations done correctly in one place.


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

[R. David Murray]

On Thu, 07 Jun 2012 17:39:54 -0400, Terry Reedy  wrote:
> On 6/7/2012 4:54 PM, Yury Selivanov wrote:
> 
> > I think we'll add a 'format' method to the Signature, that will work
> > like 'inspect.formatargspec'.  'Signature.__str__' will use it with
> > default parameters/formatters.
> 
> Great. If I don't like the default, I could customize.
> 
> > I'm not sure how __repr__ should look like.  Maybe default repr
> > (object.__repr__) is good enough.
> 
> __repr__ = __str__ is common.

I think you meant __str__ = __repr__.  __repr__ is the more fundamental
of the two, and if there is no __str__, it defaults to __repr__.

IMO the __repr__ should make it clear that it is a signature object
somehow.

--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] [Python-checkins] peps: Update 422 based on python-dev feedback

[Nick Coghlan]

On Fri, Jun 8, 2012 at 1:45 AM, Daniel Urban  wrote:
> On Thu, Jun 7, 2012 at 2:08 PM, nick.coghlan  
> wrote:
>> -* If the metaclass hint refers to an instance of ``type``, then it is
>> +* If the metaclass hint refers to a subclass of ``type``, then it is
>>   considered as a candidate metaclass along with the metaclasses of all of
>>   the parents of the class being defined. If a more appropriate metaclass is
>>   found amongst the candidates, then it will be used instead of the one
>
> I think here "instance" was correct (see
> http://hg.python.org/cpython/file/default/Lib/types.py#l76 and
> http://hg.python.org/cpython/file/cedc68440a67/Python/bltinmodule.c#l90).

Hmm, thinking back on it, the REPL experiments that persuaded me Terry
was right were flawed (I tried with object directly, but the signature
of __new__/__init__ would have been wrong regardless in that case).

Still, I'm kinda proving my point that I find it difficult to keep
*all* the details of metaclass invocation straight in my head, even
though I've been hacking on the type system for years. I've never had
anything even close to that kind of problem with class methods :)

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)

[Nick Coghlan]

On Fri, Jun 8, 2012 at 4:34 AM, Larry Hastings  wrote:
> In other words: this is possible but extremely unlikely, and will only be
> done knowingly and with deliberate intent by a skilled practitioner.
>
> I think it's reasonable to declare that, if you're monkeying around with
> dunder attributes on a function, it's up to you to clear the f.__signature__
> cache if it's set.  Like Spiderman's uncle Cliff Robertson said: with great
> power comes great responsibility.
>
> I am now firmly in the "using __signature__ as a cache is fine, don't make
> copies for no reason" camp.

I have a simpler rule: functions in the inspect module should not have
side effects on the objects they're used to inspect.

When I call "inspect.signature(f)", I expect to get something I can
modify without affecting the state of "f". That means, even if
f.__signature__ is set, the signature function will need to return a
copy rather than a direct reference to the original. If
f.__signature__ is going to be copied *anyway*, then there's no reason
to cache it, *unless* we want to say something other than what the
inspect module would automatically derive from other attributes like
__func__, __wrapped__, __call__, __code__, __closure__, etc.

There are lots of ways that implicit caching can go wrong and fail to
reflect the true state of the system, and unlike a centralised cache
such as linecache or those in importlib, a distributed cache is hard
to clear when the state of the system changes. If "signature creation"
ever proves to be a real bottleneck in an application, then it is free
to implement it's own identity-based cache for signature lookup.

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)

[Steven D'Aprano]

Nick Coghlan wrote:

On Fri, Jun 8, 2012 at 4:34 AM, Larry Hastings  wrote:

In other words: this is possible but extremely unlikely, and will only be
done knowingly and with deliberate intent by a skilled practitioner.

I think it's reasonable to declare that, if you're monkeying around with
dunder attributes on a function, it's up to you to clear the f.__signature__
cache if it's set.  Like Spiderman's uncle Cliff Robertson said: with great
power comes great responsibility.

I am now firmly in the "using __signature__ as a cache is fine, don't make
copies for no reason" camp.


I have a simpler rule: functions in the inspect module should not have
side effects on the objects they're used to inspect.

When I call "inspect.signature(f)", I expect to get something I can
modify without affecting the state of "f". That means, even if
f.__signature__ is set, the signature function will need to return a
copy rather than a direct reference to the original. If
f.__signature__ is going to be copied *anyway*, then there's no reason
to cache it, *unless* we want to say something other than what the
inspect module would automatically derive from other attributes like
__func__, __wrapped__, __call__, __code__, __closure__, etc.



There is still a potential reason to cache func.__signature__: it's a 
relatively large chunk of fields, which duplicates a lot of already existing 
data. Why make all function objects bigger when only a small minority will be 
inspected for their __signature__?


I think that lazy evaluation of __signature__ is desirable, and caching it is 
certainly desirable now that you have convinced me that there are use-cases 
for setting __signature__.


Perhaps func.__signature__ should be a computed the first time it is accessed? 
Something conceptually like this:


class FunctionWithSignature(types.FunctionType):
@property
def __signature__(self):
if hasattr(self._sig):
return self._sig
sig = self._get_signature()  # Left as an exercise for the reader.
self._sig = sig
return sig
@__signature__.setter
def __signature__(self, sig):
self._sig = sig
@__signature__.deleter
def __signature__(self):
del self._sig



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

[Larry Hastings]

On 06/07/2012 07:08 PM, Steven D'Aprano wrote:
Perhaps func.__signature__ should be a computed the first time it is 
accessed?


The PEP already declares that signatures are lazily generated.  
signature() checks to see if __signature__ is set, and if it is returns 
it.  (Or, rather, a deepcopy of it, assuming we go down that route.)  If 
__signature__ isn't set, signature() computes it and returns that.  
(Possibly caching in __signature__, possibly not, possibly caching the 
result then returning a deepcopy.)



//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/archive%40mail-archive.com

Re: [Python-Dev] PEP 362 Second Revision

[Yury Selivanov]

On 2012-06-07, at 8:40 PM, R. David Murray wrote:
> IMO the __repr__ should make it clear that it is a signature object
> somehow.

+1.

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

[Nick Coghlan]

On Fri, Jun 8, 2012 at 12:18 PM, Larry Hastings  wrote:
> On 06/07/2012 07:08 PM, Steven D'Aprano wrote:
>
> Perhaps func.__signature__ should be a computed the first time it is
> accessed?
>
>
> The PEP already declares that signatures are lazily generated.  signature()
> checks to see if __signature__ is set, and if it is returns it.  (Or,
> rather, a deepcopy of it, assuming we go down that route.)  If __signature__
> isn't set, signature() computes it and returns that.  (Possibly caching in
> __signature__, possibly not, possibly caching the result then returning a
> deepcopy.)

The need for a consistent return value ownership guarantee (i.e. "it's
OK to mutate the return value of inspect.signature()") and the
implicit inspect module guarantee of "introspection is non-intrusive
and doesn't affect the internal state of inspected objects" are the
main reasons I think implicit caching is a bad idea.

However, there are also a couple of pragmatic reasons I don't like the idea:

1. It's unlikely there will be a huge performance difference between
deep copying an existing Signature object and deriving a new one
2. If someone actually *wants* cached signature lookup for speed
reasons and is willing to sacrifice some memory in order to do so
(e.g. when using signatures for early parameter checking), they can
just do: "cached_signature = functools.lru_cache(inspect.signature)"

This approach will provide *genuine* caching, with no deep copying
involved when the same callable is encountered a second time. You will
also get all the benefits that the LRU caching mechanism provides,
rather than having a hidden unbounded caching mechanism that
potentially encompasses every function in the application.

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,

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

[Nick Coghlan]

On Fri, Jun 8, 2012 at 2:04 PM, Yury Selivanov  wrote:
>>> 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.

I would keep _bind() as an implementation detail (because the
signature is ugly), and expose the two behaviours as bind() and
bind_partial() (with the cleaner existing signature).

I thought about suggesting that bind_partial() return a (Signature,
BoundArguments) tuple, but realised that doesn't make sense, since
there are at least two different ways to use bind_partial():
1. to provide or change the default arguments for one or more parameters
2. to remove one or more parameters from the signature (forcing them
to particular values)

Rather than trying to guess specific details on how it could be used a
priori, it makes more sense to just leave it up to the caller to
decide how they want to update the Signature object. If additional
convenience methods seem like a good idea in the future, they can
either be provided in a third party enhanced signature manipulation
library, and/or added in 3.4.

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)

[Nick Coghlan]

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.

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