Re: [Python-Dev] Possible patch for functools partial - Interested?
On Fri, May 7, 2010 at 17:02, Antoine Pitrou wrote: > It would be more useful to provide equality, hashing and repr to partial > itself, > rather than a subclass. Feel free to propose a patch :) Hi! I've done that. I've opened a feature request: http://bugs.python.org/issue8699 The patch is also at Rietveld: http://codereview.appspot.com/1179044 I'm a beginner, so my patch is probably far from perfect, but I'd appreciate any help, and will try to correct my mistakes. Thanks, Daniel Urban ___ 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-archive.com
Re: [Python-Dev] Possible patch for functools partial - Interested?
> While a partial object should reasonably never change, you could change it:
>>>> from functools import partial
>>>> p = partial(lambda *a, **kw: kw, 1, 2, spam='eggs')
>>>> p()
> {'spam': 'eggs'}
>>>> p.keywords['spam'] = 'bacon'
>>>> p()
> {'spam': 'bacon'}
>>>>
> I realize touching p.keywords voids your warranty, but if we can stop people
> from doing it, maybe we should (or at least put a warning in the
> documentation, no?). So I'm thinking either we make an immutable/hashable
> dict while we're at it, or store the keyword arguments as a tuple (which
> guarantees immutability), and only convert them back to a dict when you want
> to call the partial object (simpler, slower).
You're right. I think it is possible to stop people from modifying
p.keywords. If p.keywords wouldn't be a dict, but a read-only proxy
for that dict, that may solve this problem. I think that is possible,
with PyDictProxy_New [1]. But I'm not certain if that is a good idea,
it may have side effects I'm not aware of. Any thoughts about this?
> Your thoughts? Should we continue this discussion at issue8699?
I don't know, I'm new here...
[1] http://docs.python.org/py3k/c-api/dict.html#PyDictProxy_New
Thanks,
Daniel Urban
___
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-archive.com
Re: [Python-Dev] Possible patch for functools partial - Interested?
I wrote an e-mail yesterday, but it seems, it didn't reach python-dev.
Here it is again:
On Thu, May 13, 2010 at 13:30, Steven D'Aprano wrote:
> I'd support an immutable dict. partial objects already impose a
> significant (~ 30%) performance penalty:
>
>>>> from timeit import Timer
>>>> min(Timer('f(5)', 'f = lambda x: x').repeat())
> 0.93580079078674316
>>>> min(Timer('p(5)', 'from functools import partial; p = partial(lambda
> x: x)').repeat())
> 1.2715129852294922
>
> No need to make that worse if that can be avoided.
I've made a new patch, in which the keywords attribute is a read-only
proxy of the dictionary. I've used your benchmark, and I haven't found
any significant difference in execution times.
The patch is in the tracker (http://bugs.python.org/issue8699) and
Rietveld (http://codereview.appspot.com/1179044).
Daniel Urban
___
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-archive.com
Re: [Python-Dev] Possible patch for functools partial - Interested?
On Thu, May 13, 2010 at 13:30, Steven D'Aprano wrote:
> I'd support an immutable dict. partial objects already impose a
> significant (~ 30%) performance penalty:
>
>>>> from timeit import Timer
>>>> min(Timer('f(5)', 'f = lambda x: x').repeat())
> 0.93580079078674316
>>>> min(Timer('p(5)', 'from functools import partial; p = partial(lambda
> x: x)').repeat())
> 1.2715129852294922
>
> No need to make that worse if that can be avoided.
I've made a new patch, in which the keywords attribute is a read-only
proxy of the dictionary. I've used your benchmark, and I haven't found
any significant difference in execution times.
The patch is in the tracker (http://bugs.python.org/issue8699) and
Rietveld (http://codereview.appspot.com/1179044).
Daniel Urban
___
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-archive.com
Re: [Python-Dev] Possible patch for functools partial - Interested?
On Mon, May 17, 2010 at 09:47, Hrvoje Niksic wrote: > On 05/14/2010 06:39 AM, Daniel Urban wrote: >> >> I've made a new patch, in which the keywords attribute is a read-only >> proxy of the dictionary. > > What about backward compatibility? This looks like an incompatible change. You're probably right. I'd be happy to make patch which doesn't replace the dict with the proxy. But that would mean, that the hash value isn't really immutable. Daniel Urban ___ 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-archive.com
Re: [Python-Dev] abstractmethod doesn't work in classes
> I've found that abstractmethod and similar decorators "don't work" in > classes, inherited from built-in types other than object. http://bugs.python.org/issue5996 ___ 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-archive.com
Re: [Python-Dev] python and super
On Thu, Apr 14, 2011 at 16:18, Ronald Oussoren wrote: > It would be odd to not call super in __init__, but for other methods not > calling the superclass implementation is fairly common. Yes it is odd, that for example list.__init__ doesn't call super :-) (http://bugs.python.org/issue8733) Daniel ___ 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-archive.com
Re: [Python-Dev] Providing a mechanism for PEP 3115 compliant dynamic class creation
On Tue, Apr 19, 2011 at 16:10, Nick Coghlan wrote:
> In reviewing a fix for the metaclass calculation in __build_class__
> [1], I realised that PEP 3115 poses a potential problem for the common
> practice of using "type(name, bases, ns)" for dynamic class creation.
>
> Specifically, if one of the base classes has a metaclass with a
> significant __prepare__() method, then the current idiom will do the
> wrong thing (and most likely fail as a result), since "ns" will
> probably be an ordinary dictionary instead of whatever __prepare__()
> would have returned.
>
> Initially I was going to suggest making __build_class__ part of the
> language definition rather than a CPython implementation detail, but
> then I realised that various CPython specific elements in its
> signature made that a bad idea.
Are you referring to the first 'func' argument? (Which is basically
the body of the "class" statement, if I'm not mistaken).
> Instead, I'm thinking along the lines of an
> "operator.prepare(metaclass, bases)" function that does the metaclass
> calculation dance, invoking __prepare__() and returning the result if
> it exists, otherwise returning an ordinary dict. Under the hood we
> would refactor this so that operator.prepare and __build_class__ were
> using a shared implementation of the functionality at the C level - it
> may even be advisable to expose that implementation via the C API as
> PyType_PrepareNamespace().
__prepare__ also needs the name and optional keyword arguments. So it
probably should be something like "operator.prepare(name, bases,
metaclass, **kw)". But this way it would need almost the same
arguments as __build_class__(func, name, *bases, metaclass=None,
**kwds).
> The correct idiom for dynamic type creation in a PEP 3115 world would then be:
>
> from operator import prepare
> cls = type(name, bases, prepare(type, bases))
>
> Thoughts?
When creating a dynamic type, we may want to do it with a non-empty
namespace. Maybe like this (with the extra arguments mentioned above):
from operator import prepare
ns = prepare(name, bases, type, **kwargs)
ns.update(my_ns) # add the attributes we want
cls = type(name, bases, ns)
What about an "operator.build_class(name, bases, ns, **kw)" function?
It would work like this:
def build_class(name, bases, ns, **kw):
metaclass = kw.pop('metaclass', type)
pns = prepare(name, bases, metaclass, **kw)
pns.update(ns)
return metaclass(name, bases, pns)
(Where 'prepare' is the same as above).
This way we wouldn't even need to make 'prepare' public, and the new
way to create a dynamic type would be:
from operator import build_class
cls = build_class(name, bases, ns, **my_kwargs)
Daniel
___
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-archive.com
Re: [Python-Dev] Providing a mechanism for PEP 3115 compliant dynamic class creation
On Sun, Apr 15, 2012 at 13:48, Nick Coghlan wrote:
> /me pages thoughts from 12 months ago back into brain...
Sorry about that, I planned to do this earlier...
> On Sun, Apr 15, 2012 at 7:36 PM, Daniel Urban wrote:
>> On Tue, Apr 19, 2011 at 16:10, Nick Coghlan wrote:
>>> Initially I was going to suggest making __build_class__ part of the
>>> language definition rather than a CPython implementation detail, but
>>> then I realised that various CPython specific elements in its
>>> signature made that a bad idea.
>>
>> Are you referring to the first 'func' argument? (Which is basically
>> the body of the "class" statement, if I'm not mistaken).
>
> Yup, I believe that was my main objection to exposing __build_class__
> directly. There's no obligation for implementations to build a
> throwaway function to evaluate a class body.
>
>> __prepare__ also needs the name and optional keyword arguments. So it
>> probably should be something like "operator.prepare(name, bases,
>> metaclass, **kw)". But this way it would need almost the same
>> arguments as __build_class__(func, name, *bases, metaclass=None,
>> **kwds).
>
> True.
>
>>> The correct idiom for dynamic type creation in a PEP 3115 world would then
>>> be:
>>>
>>> from operator import prepare
>>> cls = type(name, bases, prepare(type, bases))
>>>
>>> Thoughts?
>>
>> When creating a dynamic type, we may want to do it with a non-empty
>> namespace. Maybe like this (with the extra arguments mentioned above):
>>
>> from operator import prepare
>> ns = prepare(name, bases, type, **kwargs)
>> ns.update(my_ns) # add the attributes we want
>> cls = type(name, bases, ns)
>>
>> What about an "operator.build_class(name, bases, ns, **kw)" function?
>> It would work like this:
>>
>> def build_class(name, bases, ns, **kw):
>> metaclass = kw.pop('metaclass', type)
>> pns = prepare(name, bases, metaclass, **kw)
>> pns.update(ns)
>> return metaclass(name, bases, pns)
>>
>> (Where 'prepare' is the same as above).
>> This way we wouldn't even need to make 'prepare' public, and the new
>> way to create a dynamic type would be:
>>
>> from operator import build_class
>> cls = build_class(name, bases, ns, **my_kwargs)
>
> No, I think we would want to expose the created namespace directly -
> that way people can use update(), direct assigment, exec(), eval(), or
> whatever other mechanism they choose to handle the task of populating
> the namespace. However, a potentially cleaner way to do that might be
> offer use an optional callback API rather than exposing a separate
> public prepare() function. Something like:
>
> def build_class(name, bases=(), kwds=None, eval_body=None):
> metaclass, ns = _prepare(name, bases, kwds)
> if eval_body is not None:
> eval_body(ns)
> return metaclass(name, bases, ns)
That seems more flexible indeed. I will try to make a patch next week,
if that's OK.
Daniel
___
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-archive.com
Re: [Python-Dev] Providing a mechanism for PEP 3115 compliant dynamic class creation
On Mon, Apr 16, 2012 at 04:17, Nick Coghlan wrote: > Sure, just create a new tracker issue and assign it to me. You already > know better than most what the _prepare() step needs to do :) I've created http://bugs.python.org/issue14588, and attached the first version of a patch. I can't assign it to you, but you're on the nosy list. Thanks, Daniel ___ 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-archive.com
Re: [Python-Dev] Adding types.build_class for 3.3
On Wed, May 9, 2012 at 3:10 AM, Nick Coghlan wrote: > On Wed, May 9, 2012 at 8:37 AM, Tres Seaver wrote: >>> No, the "mcl" in the call is just the designated metaclass - the >>> *actual* metaclass of the resulting class definition may be something >>> different. That's why this is a separate method from mcl.__new__. >> >> Why not make it a static method, if there is no notion of a useful 'cls' >> argument? > > We need the explicitly declared metaclass as well as the bases in > order to determine the correct metaclass. Note, that the current patch (at http://bugs.python.org/issue14588) obtains the explicitly declared metaclass from the keywords dict (exactly like the class statement). > As a static method, the invocation would look like: > > type.build_class(mcl, bases, keywords, exec_body) So I think, that in theory, this static method could work exactly like the operator.build_class function in the patch: type.build_class(name, bases, kwds, exec_body) (it doesn't need the mcls in a separate argument, it is in kwds). > Since mcl will always be an instance of type in 3.x (due to all > classes being subtypes of object), it makes more sense to just make it > a class method and invoke the method on the declared metaclass: > > mcl.build_class(bases, keywords, exec_body) We could do that, but "mcl will always be an instance of type in 3.x" is not strictly true: an arbitrary callable is still allowed as a metaclass in a class statement, so I think the build_class function should support it too. > The following assertion *does not* hold reliably: > > cls = mcl.build_class(bases, keywords, exec_body) > assert type(cls) == mcl # Not guaranteed Right. > Instead, the invariant that holds is the weaker assertion: > > cls = mcl.build_class(bases, keywords, exec_body) > assert isinstance(cls, mcl) But if mcl is an arbitrary callable, this is also not always true (of course, then the invocation above wouldn't work, but with a class statement we could still create such "classes": >>> def f(mcls, name, bases): ... return 0 ... >>> class C(metaclass=f): ... pass ... >>> C 0 Daniel ___ 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-archive.com
Re: [Python-Dev] Language reference updated for metaclasses
I think there is a small mistake in section "3.3.3.4. Creating the class object": "After the class object is created, any class decorators included in the *function* definition are invoked ..." That probaly should be "class definition". Daniel ___ 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-archive.com
Re: [Python-Dev] Updated PEP 362 (Function Signature Object)
> 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 as the return value of bind in the previous version (more or less
the same as the return value of inspect.getcallargs). My question is:
why we need the other 2 attributes ('args' and 'kwargs')? The
"Annotation Checker" example uses it to call the function. But if we
are able to call bind, we already have the arguments, so we can simply
call the function with them, we don't really need these attributes. I
think it would be better (easier to use and understand), if bind would
simply return the mapping, as in the previous version of the PEP.
> Has the following public attributes:
>
> * arguments : OrderedDict
> An ordered mutable mapping of parameters' names to arguments' values.
> Does not contain arguments' default values.
Does this mean, that if the arguments passed to bind doesn't contain a
value for an argument that has a default value, then the returned
mapping won't contain that argument? If so, why not?
inspect.getcallargs works fine with default values.
Daniel
___
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-archive.com
Re: [Python-Dev] Updated PEP 362 (Function Signature Object)
>>> 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 as the return value of bind in the previous version (more or less
>> the same as the return value of inspect.getcallargs). My question is:
>> why we need the other 2 attributes ('args' and 'kwargs')? The
>> "Annotation Checker" example uses it to call the function. But if we
>> are able to call bind, we already have the arguments, so we can simply
>> call the function with them, we don't really need these attributes. I
>> think it would be better (easier to use and understand), if bind would
>> simply return the mapping, as in the previous version of the PEP.
>
> 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 'foo' by:
>
> >>> foo(**bound_args.arguments)
> TypeError: foo() got an unexpected keyword argument 'args'
Of course, but you can invoke it with "1, 2, 3", the arguments you
used to create the BoundArguments instance in the first place: foo(1,
2, 3) will work fine.
> That's why we have two dynamic properties 'args', and 'kwargs':
Ok, but what I'm saying is, that we don't really need them.
> >>> bound_args.args, bound_args.kwargs
> ((1, 2, 3), {})
>
> 'BoundArguments.arguments', as told in the PEP, is a mapping to work
> with 'Signature.parameters' (you should've seen it in the
> "Annotation Checker" example).
>
> 'args' & 'kwargs' are for invocation. You can even modify 'arguments'.
>
>>> Has the following public attributes:
>>>
>>> * arguments : OrderedDict
>>> An ordered mutable mapping of parameters' names to arguments' values.
>>> Does not contain arguments' default values.
>>
>> Does this mean, that if the arguments passed to bind doesn't contain a
>> value for an argument that has a default value, then the returned
>> mapping won't contain that argument? If so, why not?
>> inspect.getcallargs works fine with default values.
>
> Yes, it won't. It contains only arguments you've passed to the 'bind'.
> The reason is because we'd like to save as much of actual context as
> possible.
I don't really see, where this "context" can be useful. Maybe an
example would help.
> If you pass some set of arguments to the bind() method, it tries to map
> precisely that set. This way you can deduce from the BoundArguments what
> it was bound with. And default values will applied by python itself.
Anyway, I think it would be nice to be able to obtain the full
arguments mapping that the function would see, not just a subset. Of
course, we can use inspect.getcallargs for that, but I think we should
be able to do that with the new Signature API.
Daniel
___
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-archive.com
Re: [Python-Dev] Updated PEP 362 (Function Signature Object)
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
>>> OrderedDict([('args', (1, 2, 3))])
>>>
>>> You can't invoke 'foo' by:
>>>
>>> >>> foo(**bound_args.arguments)
>>> TypeError: foo() got an unexpected keyword argument 'args'
>>
>> Of course, but you can invoke it with "1, 2, 3", the arguments you
>> used to create the BoundArguments instance in the first place: foo(1,
>> 2, 3) will work fine.
>
> The whole point is to use BoundArguments mapping for invocation.
> See Nick's idea to validate callbacks, and my response to him, below in
> the thread.
>
>>> That's why we have two dynamic properties 'args', and 'kwargs':
>>
>> Ok, but what I'm saying is, that we don't really need them.
>
> We need them. Again, in some contexts you don't have the arguments
> you've passed to bind().
But how could we *need* bind to return 'args' and 'kwargs' to us, when
we wouldn't be able to call bind in the first place, if we wouldn't
had the arguments?
>>> >>> bound_args.args, bound_args.kwargs
>>> ((1, 2, 3), {})
>>>
>>> 'BoundArguments.arguments', as told in the PEP, is a mapping to work
>>> with 'Signature.parameters' (you should've seen it in the
>>> "Annotation Checker" example).
>>>
>>> 'args' & 'kwargs' are for invocation. You can even modify 'arguments'.
>>>
>>>>> Has the following public attributes:
>>>>>
>>>>> * arguments : OrderedDict
>>>>> An ordered mutable mapping of parameters' names to arguments' values.
>>>>> Does not contain arguments' default values.
>>>>
>>>> Does this mean, that if the arguments passed to bind doesn't contain a
>>>> value for an argument that has a default value, then the returned
>>>> mapping won't contain that argument? If so, why not?
>>>> inspect.getcallargs works fine with default values.
>>>
>>> Yes, it won't. It contains only arguments you've passed to the 'bind'.
>>> The reason is because we'd like to save as much of actual context as
>>> possible.
>>
>> I don't really see, where this "context" can be useful. Maybe an
>> example would help.
>
> For instance, for some sort of RPC mechanism, where you don't need to
> store/pass arguments that have default values.
I see. So, basically, it's an optimization.
>>> If you pass some set of arguments to the bind() method, it tries to map
>>> precisely that set. This way you can deduce from the BoundArguments what
>>> it was bound with. And default values will applied by python itself.
>>
>> Anyway, I think it would be nice to be able to obtain the full
>> arguments mapping that the function would see, not just a subset. Of
>> course, we can use inspect.getcallargs for that, but I think we should
>> be able to do that with the new Signature API.
>
>
> Well, it will take just a few lines of code to enrich BoundArguments with
> default values (we can add a method to do it, if it's really that required
> feature). But you won't be able to ever reconstruct what arguments the
> bind() method was called with, if we write default values to arguments
> from start.
As I've mentioned above, I don't think, we have to be able to
reconstruct the arguments passed to bind from the return value of
bind. If we will need the original arguments later/in another place,
we will just save them, bind doesn't have to complicate its API with
them.
> Also, it's better for performance. "Annotation Checker" example does
> defaults validation first, and never checks them again. If bind() would
> write default values to 'BoundArguments.arguments', you would check
> defaults on each call. And think about more complicated cases, where
> processing of argument's value is more complicated and time consuming.
Ok, so again, it is an optimization.
Daniel
___
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-archive.com
Re: [Python-Dev] Updated PEP 362 (Function Signature Object)
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(*args):
>>>>> ... print(args)
>>>>>
>>>>> >>> bound_args = signature(foo).bind(1, 2, 3)
>>>>> >>> bound_args.arguments
>>>>> OrderedDict([('args', (1, 2, 3))])
>>>>>
>>>>> You can't invoke 'foo' by:
>>>>>
>>>>> >>> foo(**bound_args.arguments)
>>>>> TypeError: foo() got an unexpected keyword argument 'args'
>>>>
>>>> Of course, but you can invoke it with "1, 2, 3", the arguments you
>>>> used to create the BoundArguments instance in the first place: foo(1,
>>>> 2, 3) will work fine.
>>>
>>> The whole point is to use BoundArguments mapping for invocation.
>>> See Nick's idea to validate callbacks, and my response to him, below in
>>> the thread.
>>>
>>>>> That's why we have two dynamic properties 'args', and 'kwargs':
>>>>
>>>> Ok, but what I'm saying is, that we don't really need them.
>>>
>>> We need them. Again, in some contexts you don't have the arguments
>>> you've passed to bind().
>>
>> But how could we *need* bind to return 'args' and 'kwargs' to us, when
>> we wouldn't be able to call bind in the first place, if we wouldn't
>> had the arguments?
>
> You're missing the point. BoundArguments contains properly mapped
> *args and **kwargs passed to Signature.bind. You can validate them after,
> do type casts, modify them, overwrite etc. by manipulating
> 'BoundArguments.arguments'.
>
> At the end you can't, however, invoke the function by doing:
>
> func(**bound_arguments.arguments) # <- this won't work
>
> as varargs will be screwed.
>
> That's why you need 'args' & 'kwargs' properties on BoundArguments.
>
> Imagine, that "Annotation Checker" example is modified to coerce all string
> arguments to int (those that had 'int' in annotation) and then to multiply
> them by 42.
>
> We'd write the following code:
>
> for arg_name, arg_value in bound_arguments.arguments.items():
> # I'm skipping is_args & is_kwargs checks, and assuming
> # we have annotations everywhere
> if sig.parameters[arg_name].annotation is int \
> and isinstance(arg_value, str):
> bound_arguments.arguments[arg_name] = int(arg_value) * 42
>
> return func(*bound_arguments.args, **bound_arguments.kwargs)
I see. Thanks, this modifying example is the first convincing use case
I hear. Maybe it would be good to mention something like this in the
PEP.
Daniel
___
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-archive.com
Re: [Python-Dev] [Python-checkins] peps: Update 422 based on python-dev feedback
On Thu, Jun 7, 2012 at 2:08 PM, nick.coghlan wrote: > -* If the metaclass hint refers to an instance of ``type``, then it is > +* If the metaclass hint refers to a subclass of ``type``, then it is > considered as a candidate metaclass along with the metaclasses of all of > the parents of the class being defined. If a more appropriate metaclass is > found amongst the candidates, then it will be used instead of the one I think here "instance" was correct (see http://hg.python.org/cpython/file/default/Lib/types.py#l76 and http://hg.python.org/cpython/file/cedc68440a67/Python/bltinmodule.c#l90). Daniel ___ 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-archive.com
Re: [Python-Dev] [Python-checkins] peps: Update 422 based on python-dev feedback
On Thu, Jun 7, 2012 at 9:47 PM, Terry Reedy wrote: > On 6/7/2012 11:45 AM, Daniel Urban wrote: >> >> On Thu, Jun 7, 2012 at 2:08 PM, nick.coghlan >> wrote: >>> >>> -* If the metaclass hint refers to an instance of ``type``, then it is >>> +* If the metaclass hint refers to a subclass of ``type``, then it is >>> considered as a candidate metaclass along with the metaclasses of all >>> of >>> the parents of the class being defined. If a more appropriate metaclass >>> is >>> found amongst the candidates, then it will be used instead of the one >> >> >> I think here "instance" was correct (see >> http://hg.python.org/cpython/file/default/Lib/types.py#l76 and >> http://hg.python.org/cpython/file/cedc68440a67/Python/bltinmodule.c#l90). > > > If so, then the behavior of the standard case of a type subclass is not > obviously (to me) covered. A subclass of type is also necessarily an instance of type, so that is also covered by this case. Daniel ___ 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-archive.com
Re: [Python-Dev] PEP 362: 4th edition
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 ___ 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-archive.com
Re: [Python-Dev] PEP 362 implementation issue: C callables
On Fri, Jun 15, 2012 at 11:24 PM, Larry Hastings wrote: > There are four more candidates I found with the grep but couldn't figure out > how to instantiate and test. They have to do with the descriptor protocol, > aka properties, but the types aren't directly exposed by Python. They're > all defined in Object/descrobject.c. The internal class names are: > > method_descriptor > classmethod_descriptor > wrapper_descriptor > method-wrapper (you get one of these out of a "wrapper_descriptor") 'method_descriptor' is apparently used for the methods of built-in (implemented in C) objects: >>> set.__dict__['union'].__class__ 'classmethod_descriptor' is similarly for the classmethods of built-in classes: >>> import itertools >>> itertools.chain.__dict__['from_iterable'].__class__ 'wrapper_descriptor' is used for example the operators of built-in types: >>> int.__dict__['__add__'].__class__ And 'method-wrapper': >>> (5).__add__.__class__ Daniel ___ 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-archive.com
Re: [Python-Dev] Submitting PEP 422 (Simple class initialization hook) for pronouncement
On Sun, Feb 10, 2013 at 5:48 PM, Stefan Behnel wrote: > However, it's hard to say if this "new way of doing it" doesn't come with > its own can of worms. For example, would cooperative calls to > "__init_class__" work if a superclass already defines it? Do implementors > have to remember that? And is it clear how this should be done, e.g. what > should normally go first, my own code or the superclass call? Supporting > cooperative __init_class__() calls properly might actually be a good thing. > Currently, there's only one metaclass, plus a sequence of decorators, which > makes the setup rather static and sometimes tedious for subclasses that > need to do certain things by themselves, but in addition to what happens > already. Cooperative multiple inheritance of __init_class__ would work exactly the same way as it works e.g., for __init__ of any other method (actually it is easier, since as Nick mentioned, the signature is always the same): __init_class__ can simply use the zero argument form of super. There is a simple example in the tests at http://bugs.python.org/issue17044. Daniel ___ 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-archive.com
