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:
On Sat, Jun 16, 2012 at 11:27 AM, Nick Coghlan ncogh...@gmail.com wrote:
On Sat, Jun 16, 2012 at 1:56 PM, Jim J. Jewett jimjjew...@gmail.com wrote:
*Every* Parameter attribute is optional, even name.
(Think of builtins, even if they aren't automatically
supported yet.) So go ahead
On Mon, Jun 18, 2012 at 5:08 PM, Jim Jewett jimjjew...@gmail.com 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
Jim,
On 2012-06-18, at 3:08 AM, Jim Jewett wrote:
On Sat, Jun 16, 2012 at 11:27 AM, Nick Coghlan ncogh...@gmail.com wrote:
On Sat, Jun 16, 2012 at 1:56 PM, Jim J. Jewett jimjjew...@gmail.com wrote:
Instead of defining a BoundArguments class, just return
a copy of the Signature, with
On Fri, Jun 15, 2012 at 5:03 PM, R. David Murray rdmur...@bitdance.comwrote:
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
On 2012-06-18, at 1:35 PM, PJ Eby wrote:
On Fri, Jun 15, 2012 at 5:03 PM, R. David Murray rdmur...@bitdance.com
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.
On Mon, Jun 18, 2012 at 11:09 AM, Yury Selivanov
yselivanov...@gmail.com 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
On Mon, Jun 18, 2012 at 10:37 AM, Yury Selivanov
yselivanov...@gmail.com wrote:
Jim,
On 2012-06-18, at 3:08 AM, Jim Jewett wrote:
On Sat, Jun 16, 2012 at 11:27 AM, Nick Coghlan ncogh...@gmail.com wrote:
On Sat, Jun 16, 2012 at 1:56 PM, Jim J. Jewett jimjjew...@gmail.com wrote:
Instead of
Jim,
On 2012-06-18, at 5:06 PM, Jim Jewett wrote:
On Mon, Jun 18, 2012 at 10:37 AM, Yury Selivanov
yselivanov...@gmail.com wrote:
Jim,
On 2012-06-18, at 3:08 AM, Jim Jewett wrote:
On Sat, Jun 16, 2012 at 11:27 AM, Nick Coghlan ncogh...@gmail.com wrote:
On Sat, Jun 16, 2012 at 1:56 PM, Jim
On 2012-06-18, at 4:25 PM, Guido van Rossum wrote:
On Mon, Jun 18, 2012 at 11:09 AM, Yury Selivanov
yselivanov...@gmail.com 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
On Mon, Jun 18, 2012 at 5:08 PM, Jim Jewett jimjjew...@gmail.com wrote:
On Sat, Jun 16, 2012 at 11:27 AM, Nick Coghlan ncogh...@gmail.com 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).
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
yselivanov...@gmail.com wrote:
The rationale is that sometimes you need to modify signatures.
For instance, in decorators.
A decorator should make a modified copy, not
On Tue, Jun 19, 2012 at 7:06 AM, Jim Jewett jimjjew...@gmail.com 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
On 2012-06-18, at 9:29 PM, Nick Coghlan wrote:
On Tue, Jun 19, 2012 at 7:06 AM, Jim Jewett jimjjew...@gmail.com 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
On Tue, Jun 19, 2012 at 4:09 AM, Yury Selivanov yselivanov...@gmail.com 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
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,
if not
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.
2. If 'obj'
On 2012-06-18, at 9:36 PM, Nick Coghlan wrote:
On Tue, Jun 19, 2012 at 4:09 AM, Yury Selivanov yselivanov...@gmail.com
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
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
On Tue, Jun 19, 2012 at 12:00 PM, Yury Selivanov
yselivanov...@gmail.com 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
On 2012-06-18, at 10:06 PM, Nick Coghlan wrote:
On Tue, Jun 19, 2012 at 12:00 PM, Yury Selivanov
yselivanov...@gmail.com 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
On Sat, Jun 16, 2012 at 5:56 AM, Jim J. Jewett jimjjew...@gmail.com 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
On Sat, Jun 16, 2012 at 1:56 PM, Jim J. Jewett jimjjew...@gmail.com 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
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
Creates a mapping
On 2012-06-16, at 11:27 AM, Nick Coghlan wrote:
On Sat, Jun 16, 2012 at 1:56 PM, Jim J. Jewett jimjjew...@gmail.com 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
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
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
On Fri, 15 Jun 2012 15:50:25 -0400
Yury Selivanov yselivanov...@gmail.com wrote:
Open questions:
1. Should we keep 'Parameter.implemented' or not. *Please vote*
-1 to keeping it.
Regards
Antoine.
___
Python-Dev mailing list
-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
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
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 right
On Fri, 15 Jun 2012 17:07:46 -0400
Yury Selivanov yselivanov...@gmail.com 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
On 2012-06-15, at 5:13 PM, Antoine Pitrou wrote:
On Fri, 15 Jun 2012 17:07:46 -0400
Yury Selivanov yselivanov...@gmail.com 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
On Fri, 15 Jun 2012 17:26:25 -0400
Yury Selivanov yselivanov...@gmail.com wrote:
On 2012-06-15, at 5:13 PM, Antoine Pitrou wrote:
On Fri, 15 Jun 2012 17:07:46 -0400
Yury Selivanov yselivanov...@gmail.com wrote:
On 2012-06-15, at 4:48 PM, Victor Stinner wrote:
[snip]
Would it be
On 2012-06-15, at 5:30 PM, Antoine Pitrou wrote:
On Fri, 15 Jun 2012 17:26:25 -0400
Yury Selivanov yselivanov...@gmail.com wrote:
On 2012-06-15, at 5:13 PM, Antoine Pitrou wrote:
On Fri, 15 Jun 2012 17:07:46 -0400
Yury Selivanov yselivanov...@gmail.com wrote:
On 2012-06-15, at 4:48 PM,
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 yselivanov...@gmail.com wrote:
On 2012-06-15, at 5:13 PM, Antoine Pitrou wrote:
On Fri, 15 Jun 2012 17:07:46 -0400
Yury Selivanov
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
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 one
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.
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
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-generate
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,
42 matches
Mail list logo
