On 12/17/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> Say I have a metaclass X. Say that I've been using metaclass X since
> Python 2.2 days. One day I hear that shortly after Py3k, __metaclass__
> is going away and I need to start using some other syntax (say the
> metaclass= syntax for arguments sake). So what do I do?
>
> class Foo(A, B, metaclass=X):
> ...
>
> And I think that I have fixed my implementation for Py3k+, nevermind
> that it doesn't work in Python 2.x anymore, I'm a forward thinker and I
> like the new syntax. X implemented a class registry, so when X is called
> twice (once for setup, and once for finalization), now the class gets
> registered twice, or perhaps I get a crash because my metaclass doesn't
> have a default dict argument that discriminates between the two cases
> (using Steven's semantics). Ok, so now I need to adjust my metaclass to
> check to see whether it is doing the setup or finalization step. That's
> fine, but now I've had to modify my metaclass, something that I was told
> I wouldn't need to do, and with __metaclass__ going away (presumably,
> otherwise would we create a new syntax?), I'm going to need to rewrite
> *all* of my metaclasses when I switch syntaxes.
>
> But I thought you said I wouldn't need to rewrite all of my metaclasses?
FWLIW, avoiding having to rewrite code was not a goal I was striving
for. You're already going to have to rewrite for 3.0 any of your code
that uses, for example, dict.itervalues(), dict.iteritems(), etc., and
I thought people had accepted that because there *is* a way to write
that code that should work in both 2.X and 3.0 (e.g. using only
iter(dict) or dict.values(), etc.)
So, for me, the goal was to make sure that there was a way to write
code that worked in both 2.X and 3.0. That is, I didn't mind if you
had to rewrite some 2.X code to make it future compatible, as long as
it was *possible* to write such code.
STeVe
--
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
--- Bucky Katt, Get Fuzzy
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
