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
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 def
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
__
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 t
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 c
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 t
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)
>>>
>>> >&
>>> 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' attri
> 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 a
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
___
Pytho
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 meth
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
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:
>>
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
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)
Dani
> 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
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
rds 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
o 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.
T
ot 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
ue8699
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 li
21 matches
Mail list logo
