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
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 need a BDFAP and someone to do a code review:
http://bugs.pyth
68 matches
Mail list logo
