On Sun, 10 Feb 2013 16:27:49 -0500
PJ Eby p...@telecommunity.com wrote:
On Sun, Feb 10, 2013 at 7:32 AM, Nick Coghlan ncogh...@gmail.com wrote:
class Example:
@classmethod
def __init_class__(cls):
Is the @classmethod required? What happens if it's not present?
On Mon, Feb 11, 2013 at 7:41 AM, PJ Eby p...@telecommunity.com wrote:
On Sun, Feb 10, 2013 at 11:48 AM, Stefan Behnel stefan...@behnel.de wrote:
So, the way to explain it to users would be 1) don't use it, 2) if you
really need to do something to a class, use a decorator, 3) if you need to
On Feb 10, 2013, at 03:28 PM, Antoine Pitrou wrote:
Sure, every little addition is trivial. At the end you have a scary
monster made of many little trivial additions along the years, and
everyone has to take care not to break it.
Why Antoine, that surely isn't the case with the import system!
On Feb 10, 2013, at 02:34 PM, Antoine Pitrou wrote:
zope.interface has been ported to Python 3, so the annoyance can't be
very blocking.
The syntax is different, but I actually prefer the Python 3-compatible syntax
better. It uses a class decorator instead of a magic class attribute, so it's
On Feb 11, 2013, at 08:33 PM, Nick Coghlan wrote:
I like that. Perhaps the PEP should propose some additional guidance
in PEP 8 regarding class based metaprogramming?
I wouldn't put it in PEP 8, since it'll glaze the eyes of all but 6 people on
the planet. Probably better as a HOWTO in the
Le Mon, 11 Feb 2013 10:15:36 -0500,
Barry Warsaw ba...@python.org a écrit :
On Feb 10, 2013, at 03:28 PM, Antoine Pitrou wrote:
Sure, every little addition is trivial. At the end you have a scary
monster made of many little trivial additions along the years, and
everyone has to take care not
Hi Nick,
I think this will make a fine addition to the language. I agree that
it is superior to the alternatives and fulfills a real (if rare) need.
I only have a few nits/questions/suggestions.
- With PJE, I think __init_class__ should automatically be a class
method. The same way that __new__
On Mon, Feb 11, 2013 at 12:44 PM, Guido van Rossum gu...@python.org wrote:
Hi Nick,
I think this will make a fine addition to the language. I agree that
it is superior to the alternatives and fulfills a real (if rare) need.
I only have a few nits/questions/suggestions.
- With PJE, I think
On Mon, Feb 11, 2013 at 12:57 PM, PJ Eby p...@telecommunity.com wrote:
On Mon, Feb 11, 2013 at 12:44 PM, Guido van Rossum gu...@python.org
wrote:
Hi Nick,
I think this will make a fine addition to the language. I agree that
it is superior to the alternatives and fulfills a real (if
On 12 Feb 2013 07:44, Guido van Rossum gu...@python.org wrote:
On Mon, Feb 11, 2013 at 12:57 PM, PJ Eby p...@telecommunity.com wrote:
On Mon, Feb 11, 2013 at 12:44 PM, Guido van Rossum gu...@python.org
wrote:
Hi Nick,
I think this will make a fine addition to the language. I agree that
On Mon, Feb 11, 2013 at 2:29 PM, Nick Coghlan ncogh...@gmail.com wrote:
On 12 Feb 2013 07:44, Guido van Rossum gu...@python.org wrote:
On Mon, Feb 11, 2013 at 12:57 PM, PJ Eby p...@telecommunity.com wrote:
On Mon, Feb 11, 2013 at 12:44 PM, Guido van Rossum gu...@python.org
wrote:
Hi
11.02.2013 23:29, Nick Coghlan wrote:
3. I'm trying to avoid any custom magic specific to this method, but
making it implicitly a static or class method is fairly easy if we so
choose - the standard retrieval code during class creation can just
bypass the descriptor machinery, and wrap it in
On 12/02/13 10:56, Jan Kaliszewski wrote:
Wouldn't __initclass__ be readable enough? IMHO it could spare users
trouble with remembering special case.
+1
I approve of the colour of this bikeshed. __init_class__ has too many
underscores.
--
Steven
On Tue, Feb 12, 2013 at 8:35 AM, Guido van Rossum gu...@python.org wrote:
On Mon, Feb 11, 2013 at 2:29 PM, Nick Coghlan ncogh...@gmail.com wrote:
4.__class__ is already bound as soon as we have a class object to bind it
to, so we can't move it any earlier. However, it's already early enough to
On Sun, 10 Feb 2013 22:32:50 +1000
Nick Coghlan ncogh...@gmail.com wrote:
Replaces many use cases for dynamic setting of ``__metaclass__``
-
For use cases that don't involve completely replacing the defined class,
Python 2
On Sun, Feb 10, 2013 at 10:47 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Sun, 10 Feb 2013 22:32:50 +1000
Nick Coghlan ncogh...@gmail.com wrote:
Replaces many use cases for dynamic setting of ``__metaclass__``
-
For use
On Sun, Feb 10, 2013 at 2:32 PM, Nick Coghlan ncogh...@gmail.com wrote:
For those that don't recall the original discussion, the proposal is
to add a new __init_class__ hook, invoked after the class object is
created, but before the class decorators are applied. This provides a
simple approach
On Sun, 10 Feb 2013 23:17:00 +1000
Nick Coghlan ncogh...@gmail.com wrote:
On Sun, Feb 10, 2013 at 10:47 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Sun, 10 Feb 2013 22:32:50 +1000
Nick Coghlan ncogh...@gmail.com wrote:
Replaces many use cases for dynamic setting of ``__metaclass__``
On Sun, Feb 10, 2013 at 11:33 PM, Simon Cross
hodgestar+python...@gmail.com wrote:
On Sun, Feb 10, 2013 at 2:32 PM, Nick Coghlan ncogh...@gmail.com wrote:
For those that don't recall the original discussion, the proposal is
to add a new __init_class__ hook, invoked after the class object is
On Sun, Feb 10, 2013 at 11:34 PM, Antoine Pitrou solip...@pitrou.net wrote:
Nobody can claim this is simple and easy to wrap your head around. It
is a maintenance burden, and it discourages understanding of the
underlying model by anyone but language experts.
You think anyone but language
On Mon, 11 Feb 2013 00:09:55 +1000
Nick Coghlan ncogh...@gmail.com wrote:
As far as the maintenance burden goes, the patch to enable PEP 422 for
types.new_class() is trivial:
-return meta(name, bases, ns, **kwds)
+cls = meta(name, bases, ns, **kwds)
+try:
+initcl =
Antoine Pitrou, 10.02.2013 15:28:
On Mon, 11 Feb 2013 00:09:55 +1000 Nick Coghlan wrote:
As far as the maintenance burden goes, the patch to enable PEP 422 for
types.new_class() is trivial:
-return meta(name, bases, ns, **kwds)
+cls = meta(name, bases, ns, **kwds)
+try:
+
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 Sun, Feb 10, 2013 at 7:32 AM, Nick Coghlan ncogh...@gmail.com wrote:
class Example:
@classmethod
def __init_class__(cls):
Is the @classmethod required? What happens if it's not present?
Second, will type have a default __init_class__? (IMO, it should,
otherwise it will
On Sun, Feb 10, 2013 at 11:48 AM, Stefan Behnel stefan...@behnel.de wrote:
So, the way to explain it to users would be 1) don't use it, 2) if you
really need to do something to a class, use a decorator, 3) if you need to
decide dynamically what to do, define __init_class__() and 4) don't forget
25 matches
Mail list logo
