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 se
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
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
>
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
__
On 06/10/2012 10:59 AM, Benjamin Peterson wrote:
2012/6/5 Brett Cannon:
* 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.
How about "vararg" as i
2012/6/5 Brett Cannon :
> * 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.
How about "vararg" as its named in AST.
> * is_kwargs : bool
> T
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(
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()
> retur
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 th
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
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,
>>>
>>> W
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 __signat
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
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
dund
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 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 t
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)
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 fun
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 signatu
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,
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 re
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
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
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 modi
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,
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 decorat
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_
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 d
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 mi
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
On Wed, Jun 6, 2012 at 10:10 PM, Yury Selivanov wrote:
> On 2012-06-06, at 3:33 PM, Daniel Urban wrote:
>> On Wed, Jun 6, 2012 at 8:35 PM, Yury Selivanov
>> wrote:
>>> On 2012-06-06, at 2:22 PM, Daniel Urban wrote:
> I'll try to answer you with the following code:
>
> >>> def foo(*
On 2012-06-06, at 9: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. Cer
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
On Wed, Jun 6, 2012 at 11:28 AM, Yury Selivanov 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))'
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!), perh
Yury Selivanov wrote:
We can implement the __eq__ operator though.
+1
___
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-a
On 6/6/2012 6:38 PM, Steven D'Aprano wrote:
redundant. Even so, getfullargspec is not doing any harm. We're not
*adding* complexity, it's already there, and breaking currently working
code by deprecating and then removing it is not a step we should take
lightly. API churn is itself a cost.
The
Brett Cannon wrote:
On Wed, Jun 6, 2012 at 12:16 PM, Steven D'Aprano wrote:
Larry Hastings wrote:
[...]
"Changes to the Signature object, or to any of its data members,
do not affect the function itself."
which leaves the possibility that __signature__ may no longer match the
actual argumen
Larry Hastings wrote:
inspect.getfullargspec is currently unable to introspect builtin
functions and methods. Should builtins gain a __signature__ so they
can be introspected?
If function signatures are useful, then they're useful, and the
implementation language for the function is irreleva
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.
+1 to __eq__.
I don't think we should care ab
On Jun 7, 2012 12:20 AM, "Yury Selivanov" wrote:
>
> I agree, that we shouldn't make 'functools' be dependent on 'inspect'
module.
> Moreover, this is not even currently possible, as it creates an
import-loop
> that is hard to untie. But how about the following:
>
> 1. Separate 'Signature' objec
On Jun 7, 2012 3:11 AM, "Steven D'Aprano" wrote:
>
> Larry Hastings wrote:
>
>>> [...]
>>> "Changes to the Signature object, or to any of its data members,
>>> do not affect the function itself."
>>>
>>> which leaves the possibility that __signature__ may no longer match the
actual argument spec,
On 2012-06-06, at 3:33 PM, Daniel Urban wrote:
> On Wed, Jun 6, 2012 at 8:35 PM, Yury Selivanov
> wrote:
>> On 2012-06-06, at 2:22 PM, Daniel Urban wrote:
I'll try to answer you with the following code:
>>> def foo(*args):
...print(args)
>>> bound_args =
On Wed, Jun 6, 2012 at 8:35 PM, Yury Selivanov wrote:
> On 2012-06-06, at 2:22 PM, Daniel Urban wrote:
>>> I'll try to answer you with the following code:
>>>
>>> >>> def foo(*args):
>>> ... print(args)
>>>
>>> >>> bound_args = signature(foo).bind(1, 2, 3)
>>> >>> bound_args.arguments
>
On 2012-06-06, at 2:22 PM, Daniel Urban wrote:
>> I'll try to answer you with the following code:
>>
>> >>> def foo(*args):
>> ...print(args)
>>
>> >>> bound_args = signature(foo).bind(1, 2, 3)
>> >>> bound_args.arguments
>> OrderedDict([('args', (1, 2, 3))])
>>
>> You can't invoke
>>> BoundArguments Object
>>> =
>>>
>>> Result of a ``Signature.bind`` call. Holds the mapping of arguments
>>> to the function's parameters.
>>
>> The Signature.bind function has changed since the previous version of
>> the PEP. If I understand correctly, the 'arguments' attri
Daniel,
On 2012-06-06, at 1:39 PM, Daniel Urban wrote:
>> BoundArguments Object
>> =
>>
>> Result of a ``Signature.bind`` call. Holds the mapping of arguments
>> to the function's parameters.
>
> The Signature.bind function has changed since the previous version of
> the PE
Sorry I missed answering these on my first pass.
On 06/06/2012 08:38 AM, Steven D'Aprano wrote:
What to do about parameters which are partly implemented? E.g.
mode='spam' is implemented but mode='ham' is not.
Parameter objects aren't sophisticated enough to represent such a
situation. If y
> BoundArguments Object
> =
>
> Result of a ``Signature.bind`` call. Holds the mapping of arguments
> to the function's parameters.
The Signature.bind function has changed since the previous version of
the PEP. If I understand correctly, the 'arguments' attribute is the
same a
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 full
On 06/06/2012 09:16 AM, Steven D'Aprano wrote:
Nevertheless, the world is full of doorknobs, and people will have to
deal with their code.
I'm having a hard time seeing it. Can you propose a credible situation
where
* some programmer would have a reason (even a bad reason) to modify
th
On Wed, Jun 6, 2012 at 12:16 PM, Steven D'Aprano wrote:
> Larry Hastings wrote:
>
> [...]
>>> "Changes to the Signature object, or to any of its data members,
>>> do not affect the function itself."
>>>
>>> which leaves the possibility that __signature__ may no longer match the
>>> actual argumen
Eric,
On 2012-06-06, at 1:02 PM, 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 recor
A question regarding the name. I have often seen the following pattern
in decorators:
def decor(f):
def some_func(a,b):
do_stuff using f
some_func.__name__ = f.__name__
return some_func
What are the name and fully qualified names in the signature for the
returned function? som
Larry Hastings wrote:
[...]
"Changes to the Signature object, or to any of its data members,
do not affect the function itself."
which leaves the possibility that __signature__ may no longer match
the actual argument spec, for some reason. If you remove
getfullargspec, people will have to rei
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?
>
> Sign
On 06/06/2012 09:05 AM, Larry Hastings wrote:
Is there a use-case for is_implemented?
Yes, see issue 14626.
I should add, there are already some places in the standard library
where is_implemented would be relevant. The "mode" argument to os.mkdir
comes immediately to mind; on Windows it
Steven,
On 2012-06-06, at 11:38 AM, Steven D'Aprano wrote:
> Brett Cannon wrote:
>> Python has always supported powerful introspection capabilities,
>> including introspecting functions and methods. (For the rest of
>> this PEP, "function" refers to both functions and methods). By
>> examining a
On 06/06/2012 08:38 AM, Steven D'Aprano wrote:
What's the fully qualified name of the function, and why is it needed?
Please see PEP 3155.
"args" is just a common name for the parameter, not for the kind of
parameter. *args (or *data, *whatever) is a varargs parameter, and so
the attribut
Steven D'Aprano wrote:
Brett Cannon wrote:
PEP: 362
Title: Function Signature Object
Version: $Revision$
Last-Modified: $Date$
Author: Brett Cannon , Jiwon Seo ,
Yury Selivanov , Larry Hastings <
la...@hastings.org>
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 2
Brett Cannon wrote:
PEP: 362
Title: Function Signature Object
Version: $Revision$
Last-Modified: $Date$
Author: Brett Cannon , Jiwon Seo ,
Yury Selivanov , Larry Hastings <
la...@hastings.org>
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 21-Aug-2006
Python-Versio
On 2012-06-06, at 2:48 AM, Nick Coghlan wrote:
> However, looking at the code, I think the split that makes sense is
> for a lower level functools.signature to *only* support real function
> objects (i.e. not even method objects).
>
> At the inspect layer, inspect.signature could then support retr
On 2012-06-06, at 9:28 AM, Isaac Morland wrote:
> On Wed, 6 Jun 2012, Nick Coghlan wrote:
>
>> 2. Signature.bind introduces the ability to split the "bind arguments
>> to parameters" operation from the "call object" operation
>
> Has anybody considered calling bind __call__? That is, the result
On Wed, 6 Jun 2012, Nick Coghlan wrote:
2. Signature.bind introduces the ability to split the "bind arguments
to parameters" operation from the "call object" operation
Has anybody considered calling bind __call__? That is, the result of
calling the signature of a procedure instead of the pro
On Wed, Jun 6, 2012 at 12:51 PM, Yury Selivanov wrote:
> As for moving Signature object to `functools`, we had this discussion with
> Brett, and here is what he suggested:
>
> Functools contains code that transforms what a function
> does while inspect is about introspection. These objects
Nick,
On 2012-06-05, at 9:45 PM, Nick Coghlan wrote:
> Specific proposals:
>
> - the goals of the PEP be expanded to include error checking of
> parameter binding for delayed calls and improve introspection of
> function wrappers that accept arbitrary arguments, rather than the
> more nebulous "i
On Wed, Jun 6, 2012 at 10:26 AM, Brett Cannon wrote:
> On behalf of Yury, Larry, Jiwon (wherever he ended up), and myself, here is
> an updated version of PEP 362 to address Guido's earlier comments. Credit
> for most of the update should go to Yury with Larry also helping out.
>
> At this point I
67 matches
Mail list logo
