On Sun, Feb 10, 2013 at 5:48 PM, Stefan Behnel stefan...@behnel.de 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
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 Fri, Jun 15, 2012 at 11:24 PM, Larry Hastings la...@hastings.org 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.
On Thu, Jun 7, 2012 at 2:08 PM, nick.coghlan python-check...@python.org 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
On Thu, Jun 7, 2012 at 9:47 PM, Terry Reedy tjre...@udel.edu wrote:
On 6/7/2012 11:45 AM, Daniel Urban wrote:
On Thu, Jun 7, 2012 at 2:08 PM, nick.coghlanpython-check...@python.org
wrote:
-* If the metaclass hint refers to an instance of ``type``, then it is
+* If the metaclass hint refers
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
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
On Wed, Jun 6, 2012 at 8:35 PM, Yury Selivanov yselivanov...@gmail.com 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 Wed, Jun 6, 2012 at 10:10 PM, Yury Selivanov yselivanov...@gmail.com wrote:
On 2012-06-06, at 3:33 PM, Daniel Urban wrote:
On Wed, Jun 6, 2012 at 8:35 PM, Yury Selivanov yselivanov...@gmail.com
wrote:
On 2012-06-06, at 2:22 PM, Daniel Urban wrote:
I'll try to answer you with the following
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
On Wed, May 9, 2012 at 3:10 AM, Nick Coghlan ncogh...@gmail.com wrote:
On Wed, May 9, 2012 at 8:37 AM, Tres Seaver tsea...@palladion.com 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
On Mon, Apr 16, 2012 at 04:17, Nick Coghlan ncogh...@gmail.com 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
On Tue, Apr 19, 2011 at 16:10, Nick Coghlan ncogh...@gmail.com 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
On Sun, Apr 15, 2012 at 13:48, Nick Coghlan ncogh...@gmail.com 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 urban.dani...@gmail.com wrote:
On Tue, Apr 19, 2011 at 16:10, Nick
On Thu, Apr 14, 2011 at 16:18, Ronald Oussoren ronaldousso...@mac.com 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 :-)
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
On Mon, May 17, 2010 at 09:47, Hrvoje Niksic hrvoje.nik...@avl.com 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
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
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
-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
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
21 matches
Mail list logo
