On 06/18/2012 07:35 PM, Yury Selivanov wrote:
BTW, http://bugs.python.org/issue15008 has the latest implementation
attached (if anybody wants to play with it)
I've also posted the latest minor tweaks to the PEP, on behalf of Yury.
The new version is already live:
http://www.python.org/de
On 2012-06-18, at 10:06 PM, Nick Coghlan wrote:
> On Tue, Jun 19, 2012 at 12:00 PM, Yury Selivanov
> wrote:
>> On 2012-06-18, at 9:36 PM, Nick Coghlan wrote:
>>> So keep the current copying semantics for Signature objects (i.e.
>>> creating new copies of the Parameter objects as well), but call
On Tue, Jun 19, 2012 at 12:00 PM, Yury Selivanov
wrote:
> On 2012-06-18, at 9:36 PM, Nick Coghlan wrote:
>> So keep the current copying semantics for Signature objects (i.e.
>> creating new copies of the Parameter objects as well), but call it a
>> shallow copy rather than a deep copy. Make it cle
On Mon, Jun 18, 2012 at 02:09:17PM -0400, Yury Selivanov wrote:
> That's an excerpt from Signature.__deepcopy__:
>
> cls = type(self)
> sig = cls.__new__(cls)
> sig.parameters = OrderedDict((name, param.__copy__()) \
>for name, param in self.parameters.i
On 2012-06-18, at 9:36 PM, Nick Coghlan wrote:
> On Tue, Jun 19, 2012 at 4:09 AM, Yury Selivanov
> wrote:
>> On 2012-06-18, at 1:35 PM, PJ Eby wrote:
>>> Then just copy the signature itself; as currently written, this is going to
>>> copy the annotation objects, which could produce weird side-e
On 2012-06-18, at 9:50 PM, Steven D'Aprano wrote:
> On Mon, Jun 18, 2012 at 07:10:33PM -0400, Yury Selivanov wrote:
>
>> It seems that we have the following options for 'signature(obj)':
>>
>> 1. If 'obj' has a '__signature__' attribute - return a copy of it,
>> if not - create a new one.
>>
>
On Mon, Jun 18, 2012 at 07:10:33PM -0400, Yury Selivanov wrote:
> It seems that we have the following options for 'signature(obj)':
>
> 1. If 'obj' has a '__signature__' attribute - return a copy of it,
> if not - create a new one.
>
> 2. If 'obj' has a '__signature__' attribute - return it,
> i
On Tue, Jun 19, 2012 at 4:09 AM, Yury Selivanov wrote:
> On 2012-06-18, at 1:35 PM, PJ Eby wrote:
>> Then just copy the signature itself; as currently written, this is going to
>> copy the annotation objects, which could produce weird side-effects from
>> introspection. Using deepcopy seems lik
On 2012-06-18, at 9:29 PM, Nick Coghlan wrote:
> On Tue, Jun 19, 2012 at 7:06 AM, Jim Jewett wrote:
>> Correct; it should be redundant. Signature.kwargsparameter should be
>> the same object that occurs as the nth element of
>> Signature.parameters.values(). It is just more convenient to retrie
On Tue, Jun 19, 2012 at 7:06 AM, Jim Jewett wrote:
> Correct; it should be redundant. Signature.kwargsparameter should be
> the same object that occurs as the nth element of
> Signature.parameters.values(). It is just more convenient to retrieve
> the parameter directly than it is to iterate thr
Yury Selivanov wrote:
On 2012-06-18, at 4:25 PM, Guido van Rossum wrote:
On Mon, Jun 18, 2012 at 11:09 AM, Yury Selivanov
wrote:
The rationale is that sometimes you need to modify signatures.
For instance, in decorators.
A decorator should make a modified copy, not modify it in place (since
On Mon, Jun 18, 2012 at 5:08 PM, Jim Jewett wrote:
> On Sat, Jun 16, 2012 at 11:27 AM, Nick Coghlan wrote:
>> No. This is the full set of binding behaviours. "self" is just an
>> ordinary "POSITIONAL_OR_KEYWORD" argument (or POSITIONAL_ONLY, in some
>> builtin cases).
>
> Or no longer a "paramete
On 2012-06-18, at 4:25 PM, Guido van Rossum wrote:
> On Mon, Jun 18, 2012 at 11:09 AM, Yury Selivanov
> wrote:
>> The rationale is that sometimes you need to modify signatures.
>> For instance, in decorators.
>
> A decorator should make a modified copy, not modify it in place (since
> the signat
Jim,
On 2012-06-18, at 5:06 PM, Jim Jewett wrote:
> On Mon, Jun 18, 2012 at 10:37 AM, Yury Selivanov
> wrote:
>> Jim,
>>
>> On 2012-06-18, at 3:08 AM, Jim Jewett wrote:
>>> On Sat, Jun 16, 2012 at 11:27 AM, Nick Coghlan wrote:
On Sat, Jun 16, 2012 at 1:56 PM, Jim J. Jewett
wrote:
>
On Mon, Jun 18, 2012 at 10:37 AM, Yury Selivanov
wrote:
> Jim,
>
> On 2012-06-18, at 3:08 AM, Jim Jewett wrote:
>> On Sat, Jun 16, 2012 at 11:27 AM, Nick Coghlan wrote:
>>> On Sat, Jun 16, 2012 at 1:56 PM, Jim J. Jewett wrote:
Instead of defining a BoundArguments class, just return
On Mon, Jun 18, 2012 at 11:09 AM, Yury Selivanov
wrote:
> The rationale is that sometimes you need to modify signatures.
> For instance, in decorators.
A decorator should make a modified copy, not modify it in place (since
the signature of the decorated function does not change, and you have
no g
On 2012-06-18, at 1:35 PM, PJ Eby wrote:
> On Fri, Jun 15, 2012 at 5:03 PM, R. David Murray
> wrote:
> On Fri, 15 Jun 2012 22:48:42 +0200, Victor Stinner
> wrote:
> > > 1. Should we keep 'Parameter.implemented' or not. *Please vote*
>
> -1 to implemented.
>
> > I still disagree with the dee
On Fri, Jun 15, 2012 at 5:03 PM, R. David Murray wrote:
> On Fri, 15 Jun 2012 22:48:42 +0200, Victor Stinner <
> victor.stin...@gmail.com> wrote:
> > > 1. Should we keep 'Parameter.implemented' or not. *Please vote*
>
> -1 to implemented.
>
> > I still disagree with the deepcopy. I read somewhere
Jim,
On 2012-06-18, at 3:08 AM, Jim Jewett wrote:
> On Sat, Jun 16, 2012 at 11:27 AM, Nick Coghlan wrote:
>> On Sat, Jun 16, 2012 at 1:56 PM, Jim J. Jewett wrote:
>
>>>Instead of defining a BoundArguments class, just return
>>> a copy of the Signature, with "value" attributes added to
>>
On Mon, Jun 18, 2012 at 5:08 PM, Jim Jewett wrote:
> But perhaps they *should* know their relative position.
No, relative position is a property of the Signature - a parameter has
no position until it is made part of a signature.
> Also,
> positional_only, *args, and **kwargs should be able to r
On Sat, Jun 16, 2012 at 11:27 AM, Nick Coghlan wrote:
> On Sat, Jun 16, 2012 at 1:56 PM, Jim J. Jewett wrote:
>> *Every* Parameter attribute is optional, even name.
>> (Think of builtins, even if they aren't automatically
>>supported yet.) So go ahead and define some others
>>th
On 6/16/2012 6:40 PM, Yury Selivanov wrote:
Actually, Signature and Parameter are currently non-hashable (they are
mutable). I'm not sure if it was a right decision.
If this is added for 3.3, I think it would be a candidate for
'provisional' (ie, api subject to change) status. (That is not t
On 2012-06-16, at 11:27 AM, Nick Coghlan wrote:
> On Sat, Jun 16, 2012 at 1:56 PM, Jim J. Jewett wrote:
>>
>> Summary:
>>
>>*Every* Parameter attribute is optional, even name. (Think of
>>builtins, even if they aren't automatically supported yet.)
>>So go ahead and define some othe
Jim,
On 2012-06-15, at 11:56 PM, Jim J. Jewett wrote:
> because:
>def f(*, a=4, b=5): pass
>
> and:
>def f(*, b=5, a=4): pass
>
> should probably have equal signatures.
That's a very good catch -- I'll fix the implementation.
>> * bind(\*args, \*\*kwargs) -> BoundArguments
>>Create
On Sat, Jun 16, 2012 at 1:56 PM, Jim J. Jewett wrote:
>
> Summary:
>
> *Every* Parameter attribute is optional, even name. (Think of
> builtins, even if they aren't automatically supported yet.)
> So go ahead and define some others that are sometimes useful.
No, that's not the right att
On Sat, Jun 16, 2012 at 5:56 AM, Jim J. Jewett wrote:
> I think it should be explicit that this mapping does not include
> parameters which would be filled by default arguments. In fact, if
> you stick with this interface, I would like a 3rd method that does
> fill out everything.
+1
Daniel
__
Summary:
*Every* Parameter attribute is optional, even name. (Think of
builtins, even if they aren't automatically supported yet.)
So go ahead and define some others that are sometimes useful.
Instead of defining a BoundArguments class, just return a copy
of the Signature, w
> Right now we have no way to automatically generate signatures for built-in
> functions. So, as of current trunk, any such signatures would have to be
> built by hand.
>
> If we could somehow produce signature information in C, what then? Two
> possible approaches suggest themselves:
>
> Pre-gen
Am 15.06.2012 23:38, schrieb Yury Selivanov:
> Although, Larry added __signature__ attribute to PyCFunctionObject
> (None by default_. So those, who want to manually create signatures
> for their 'C' functions would be able to do that.
As I explained in my other posting: You can't add a mutable
Yury Selivanov wrote:
Hello,
The new revision of PEP 362 has been posted:
http://www.python.org/dev/peps/pep-0362/
Open questions:
1. Should we keep 'Parameter.implemented' or not. *Please vote*
-0.5
It is easier to add it later if it is needed, then to take it away if not
needed.
2
Am 15.06.2012 23:03, schrieb R. David Murray:
> The issue isn't "consenting adults", the issue is consistency.
> Without the deepcopy, sometimes what you get back from the
> inspect function is freely modifiable and sometimes it is not.
> That inconsistency is a bad thing.
This must be addressed o
On 06/15/2012 02:13 PM, Antoine Pitrou wrote:
I'm not sure I understand. The PEP already says signatures are computed
lazily. Is there an exception for built-in functions?
Right now we have no way to automatically generate signatures for
built-in functions. So, as of current trunk, any such
On 2012-06-15, at 5:35 PM, Yury Selivanov wrote:
> On 2012-06-15, at 5:30 PM, Antoine Pitrou wrote:
>
>> On Fri, 15 Jun 2012 17:26:25 -0400
>> Yury Selivanov wrote:
>>
>>> On 2012-06-15, at 5:13 PM, Antoine Pitrou wrote:
>>>
On Fri, 15 Jun 2012 17:07:46 -0400
Yury Selivanov wrote:
>
On 2012-06-15, at 5:30 PM, Antoine Pitrou wrote:
> On Fri, 15 Jun 2012 17:26:25 -0400
> Yury Selivanov wrote:
>
>> On 2012-06-15, at 5:13 PM, Antoine Pitrou wrote:
>>
>>> On Fri, 15 Jun 2012 17:07:46 -0400
>>> Yury Selivanov wrote:
On 2012-06-15, at 4:48 PM, Victor Stinner wrote:
[sn
On Fri, 15 Jun 2012 17:26:25 -0400
Yury Selivanov wrote:
> On 2012-06-15, at 5:13 PM, Antoine Pitrou wrote:
>
> > On Fri, 15 Jun 2012 17:07:46 -0400
> > Yury Selivanov wrote:
> >> On 2012-06-15, at 4:48 PM, Victor Stinner wrote:
> >> [snip]
> >>> Would it be possible to only create a signature
On 2012-06-15, at 5:13 PM, Antoine Pitrou wrote:
> On Fri, 15 Jun 2012 17:07:46 -0400
> Yury Selivanov wrote:
>> On 2012-06-15, at 4:48 PM, Victor Stinner wrote:
>> [snip]
>>> Would it be possible to only create a signature for builtin the first
>>> time that you read its __signature__ attribute?
On Fri, 15 Jun 2012 17:07:46 -0400
Yury Selivanov wrote:
> On 2012-06-15, at 4:48 PM, Victor Stinner wrote:
> [snip]
> > Would it be possible to only create a signature for builtin the first
> > time that you read its __signature__ attribute? I don't know how to
> > implement such behaviour on a b
On 2012-06-15, at 4:48 PM, Victor Stinner wrote:
[snip]
> Would it be possible to only create a signature for builtin the first
> time that you read its __signature__ attribute? I don't know how to
> implement such behaviour on a builtin function. I don't know if it's
> important to decide this rig
On Fri, 15 Jun 2012 22:48:42 +0200, Victor Stinner
wrote:
> > 1. Should we keep 'Parameter.implemented' or not. Â *Please vote*
-1 to implemented.
> I still disagree with the deepcopy. I read somewhere that Python
> developers are consenting adult. If someone really want to modify a
> Signature
> 1. Should we keep 'Parameter.implemented' or not. *Please vote*
It looks like only few functions of the os module will use it. Even
for the os module, I'm not convinced that it is the appropriate
solution to indicate if a feature is supported or not. I would prefer
something like os.path.suppor
-1 implemented
It appears to target the problem of platform-dependent parameters.
However as was discussed previously, much more common than a parameter
simply not being supported on a platform is a parameter supporting
different values on different platforms. As such, I think that it
solves too s
On Fri, 15 Jun 2012 15:50:25 -0400
Yury Selivanov wrote:
>
> Open questions:
>
> 1. Should we keep 'Parameter.implemented' or not. *Please vote*
-1 to keeping it.
Regards
Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pyth
On 06/15/2012 12:50 PM, Yury Selivanov wrote:
Open questions:
1. Should we keep 'Parameter.implemented' or not. *Please vote*
+1 to keeping Parameter.implemented.
Let's get this over with,
//arry/
___
Python-Dev mailing list
Python-Dev@python.org
Hello,
The new revision of PEP 362 has been posted:
http://www.python.org/dev/peps/pep-0362/
Summary:
1. Signature's 'is_args', 'is_kwargs', 'is_keyword_only' were all
replaced with a single 'kind' attribute (Nick, I borrowed your
description of 'kind' attribute and its possible values.)
2.
44 matches
Mail list logo
