On Tue, Jun 19, 2012 at 12:38:38PM -0400, Yury Selivanov wrote:
> > class Signature:
> > . . .
> > def equivalent(self, other):
> > "compares two Signatures for equality (ignores parameter names)"
> > . . .
>
> I don't think that comparing signatures will be a common operation,
> so
On Wed, Jun 20, 2012 at 1:51 PM, Yury Selivanov wrote:
> What if instead of 'optional', we have 'base_signature'
> (or 'from_signature')?
>
> sig = signature(func)
> params = OrderedDict(tuple(sig.parameters.items())[1:])
> new_sig = Signature(params, base_signature=sig)
>
> And for Param
On Wed, Jun 20, 2012 at 1:28 PM, Yury Selivanov wrote:
> On 2012-06-19, at 11:24 PM, Nick Coghlan wrote:
>> The constructor accepts an iterable of Parameter objects rather than a
>> mapping.
>
> That's the code I've ended up with:
>
> sig = signature(obj.__func__)
> return Signature
On 2012-06-19, at 10:16 PM, Nick Coghlan wrote:
> On Wed, Jun 20, 2012 at 11:22 AM, Yury Selivanov
> wrote:
>> On 2012-06-19, at 8:39 PM, Nick Coghlan wrote:
>>> If we even keep that at all for the initial version of the API, the
>>> direct "default" and "annotation" attributes would just be read-
On 2012-06-19, at 11:24 PM, Nick Coghlan wrote:
> On Wed, Jun 20, 2012 at 12:36 PM, Yury Selivanov
> wrote:
>> On 2012-06-19, at 9:22 PM, Yury Selivanov wrote:
>>> On 2012-06-19, at 8:39 PM, Nick Coghlan wrote:
7. The idea of immutable Signature objects does highlight an annoyance
with
On Wed, Jun 20, 2012 at 12:36 PM, Yury Selivanov
wrote:
> On 2012-06-19, at 9:22 PM, Yury Selivanov wrote:
>> On 2012-06-19, at 8:39 PM, Nick Coghlan wrote:
>>> 7. The idea of immutable Signature objects does highlight an annoyance
>>> with the "attribute may be missing" style APIs. To actually du
Nick,
I started a new branch to experiment with immutable Signatures.
So far, almost everything works (except a couple unit-tests, that are
modifying now immutable Parameters & Signatures)
https://bitbucket.org/1st1/cpython/changesets/tip/branch(%22pep362-2%22)
I hope tomorrow we get some feedb
On 2012-06-19, at 10:16 PM, Nick Coghlan wrote:
> On Wed, Jun 20, 2012 at 11:22 AM, Yury Selivanov
> wrote:
>>> 10. Similar to the discussion of convenience properties on Signature
>>> objects themselves, I now think we should drop the "args" and "kwargs"
>>
>> Big -1 on this one. Look at the c
On 2012-06-19, at 9:22 PM, Yury Selivanov wrote:
> On 2012-06-19, at 8:39 PM, Nick Coghlan wrote:
>> 7. The idea of immutable Signature objects does highlight an annoyance
>> with the "attribute may be missing" style APIs. To actually duplicate
>> a signature correctly, including its return annotat
On Wed, Jun 20, 2012 at 12:15 PM, Yury Selivanov wrote:
> On 2012-06-19, at 10:06 PM, Nick Coghlan wrote:
>> True, the check for name clashes in Signature (and the implied numeric
>> "names") will cover the BoundArguments.parameters case
>
> Nick, I also would like to keep Parameter.name being req
On Wed, Jun 20, 2012 at 11:22 AM, Yury Selivanov
wrote:
> On 2012-06-19, at 8:39 PM, Nick Coghlan wrote:
>> 6. I think "return_annotation" can safely be abbreviated to just
>> "annotation". The fact it is on the Signature object rather than an
>> individual parameter is enough to identify it as th
On 2012-06-19, at 10:06 PM, Nick Coghlan wrote:
> On Wed, Jun 20, 2012 at 11:29 AM, Yury Selivanov wrote:
>> On 2012-06-19, at 9:22 PM, Yury Selivanov wrote:
>>
>>> On 2012-06-19, at 8:39 PM, Nick Coghlan wrote:
>>>
2. The constructor for Parameter objects should require that names for
>>>
On Wed, Jun 20, 2012 at 11:29 AM, Yury Selivanov wrote:
> On 2012-06-19, at 9:22 PM, Yury Selivanov wrote:
>
>> On 2012-06-19, at 8:39 PM, Nick Coghlan wrote:
>>
>>> 2. The constructor for Parameter objects should require that names for
>>> positional-only parameters start with "<" and end with ">
On 2012-06-19, at 9:22 PM, Yury Selivanov wrote:
> On 2012-06-19, at 8:39 PM, Nick Coghlan wrote:
>
>> 2. The constructor for Parameter objects should require that names for
>> positional-only parameters start with "<" and end with ">" to ensure
>> they can always be distinguished from standard p
On 2012-06-19, at 8:39 PM, Nick Coghlan wrote:
> On Wed, Jun 20, 2012 at 3:53 AM, Yury Selivanov
> wrote:
>> On 2012-06-19, at 1:03 PM, Ethan Furman wrote:
>>> At some point it was suggested that Signature be put in provisionally so we
>>> could modify the API if needed -- are we doing that?
>>
On Wed, Jun 20, 2012 at 3:53 AM, Yury Selivanov wrote:
> On 2012-06-19, at 1:03 PM, Ethan Furman wrote:
>> At some point it was suggested that Signature be put in provisionally so we
>> could modify the API if needed -- are we doing that?
>
> Well, it doesn't have much of an API right now (just f
On 2012-06-19, at 1:03 PM, Ethan Furman wrote:
> Yury Selivanov wrote:
>> On 2012-06-19, at 11:55 AM, Ethan Furman wrote:
>>> Yury Selivanov wrote:
Hello,
The new revision of PEP 362 has been posted:
http://www.python.org/dev/peps/pep-0362/
Summary:
1. What was 'Signature.
Yury Selivanov wrote:
On 2012-06-19, at 11:55 AM, Ethan Furman wrote:
Yury Selivanov wrote:
Hello,
The new revision of PEP 362 has been posted:
http://www.python.org/dev/peps/pep-0362/
Summary:
1. What was 'Signature.__deepcopy__' is now 'Signature.__copy__'.
__copy__ creates a shallow copy of
On 2012-06-19, at 11:55 AM, Ethan Furman wrote:
> Yury Selivanov wrote:
>> Hello,
>> The new revision of PEP 362 has been posted:
>> http://www.python.org/dev/peps/pep-0362/
>> Summary:
>> 1. What was 'Signature.__deepcopy__' is now 'Signature.__copy__'.
>> __copy__ creates a shallow copy of Signa
Yury Selivanov wrote:
Hello,
The new revision of PEP 362 has been posted:
http://www.python.org/dev/peps/pep-0362/
Summary:
1. What was 'Signature.__deepcopy__' is now 'Signature.__copy__'.
__copy__ creates a shallow copy of Signature, shallow copying its
Parameters as well.
2. 'Signature.fo
20 matches
Mail list logo
