Talin wrote:
> It does not need to implement the full dictionary interface;
> only the ability to insert items and retrieve them are
> required. (Note: double check that this is true).
Deletion ability might be required as well, in case
del is used in the class body.
--
Greg
__
PEP: xxx
Title: Metaclasses in Python 3000
Version: $Revision$
Last-Modified: $Date$
Author: Talin
Status: Draft
Type: Standards
Content-Type: text/plain
Created: 07-Mar-2007
Python-Version: 3.0
Post-History: 11-March-2007
Abstract
This PEP proposes changing the syntax for declaring metacl
Ack, I meant to hit cancel and not Send. Please ignore that.
Talin wrote:
> Guido van Rossum wrote:
>>> I'm a bit worried that class headers are going to become
>>> rather cluttered if we start putting all sorts of stuff
>>> in there.
>>>
>>> E.g. are you intending to put __slots__ there? It makes
On 14/03/2007 6.38, Greg Ewing wrote:
>> Do we deprecate it followed by a later removal (so as to "resist the
>> temptation to guess")? If so, sounds good to me (I've never had a use
>> for octal literals).
>
> I think that *some* syntax should be provided for octal
> literals.
If we get to t
Guido van Rossum wrote:
>> I'm a bit worried that class headers are going to become
>> rather cluttered if we start putting all sorts of stuff
>> in there.
>>
>> E.g. are you intending to put __slots__ there? It makes
>> sense, but it could lead to some rather long and
>> unwieldy class headers.
>
On 14/03/2007 7.22, Raymond Hettinger wrote:
> [Josiah]
>> Do we deprecate it followed by a later removal
>
> Nope. Just drop them from Python 3000. No one (except Greg) will miss them.
> The 2-to-3 tool can convert 0123 constants to decimal or hex.
I don't think anyone use octal unless there
> Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>> Now that the 20th century is safely behind us, do we still want
>> literals with leading zeroes to be interpreted as octal?
[Josiah]
> Do we deprecate it followed by a later removal
Nope. Just drop them from Python 3000. No one (except Greg) wil
On 3/14/07, Talin <[EMAIL PROTECTED]> wrote:
> Then I would call that 'somestring'.expand(), or perhaps 'substitute' or
> 'interpolate' - implying that you are doing an expansion of the named
> fields within the current scope.
'expand' isn't bad. On the one hand, I really would like the ability
t
I agree that octal should still have a syntax. However, as you say, 0o
doesn't jump out as much typographically. And I'm wary of adding
arbitrary base literals to the language. It sounds like unnecessary
complexity, though a standard library function to convert arbitrary base
representations of
Patrick Maupin wrote:
> Ian Bicking actually suggested 'somestring'.eval() for this
> functionality. I like that a lot, in the sense that it gives the same
> sense of danger as eval('somestring'), but at the same time, I dislike
> it intensely because eval('somestring') and 'somestring'.eval() ap
On 3/14/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> 1101(2) # binary
> 1234(8) # octal
> 1c3a(16)# hexadecimal
> 12g7(35)# why stop at 16?
>
> Since calling a built-in integer never makes sense,
> this would be unambiguous.
That's a great idea all the way around. A
On 3/14/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
>
> I think the difference is that when you see eval()
> you know something dangerous is going on, but most
> uses of format() would be harmless -- *except* when
> given no arguments. It would be an easy thing to
> overlook when reading code.
>
> If
Josiah Carlson wrote:
> Do we deprecate it followed by a later removal (so as to "resist the
> temptation to guess")? If so, sounds good to me (I've never had a use
> for octal literals).
I think that *some* syntax should be provided for octal
literals. They're useful when you're translating co
Josiah Carlson wrote:
> By requiring people to be explicit about when they wanted the
> traceback (rather than giving it to them all the time via
> e.__traceback__), we can prevent many of those issues.
If any way is provided of getting a traceback given an
exception object, whether it's get_tb(e)
Josiah Carlson wrote:
> eval() should require explicit locals() and globals() if the user wants
> to use them. Not providing a locals() at least should be an error.
Or should default to an empty dict. You might want
to use eval() on something known to be a constant
expresssion that doesn't refer
Patrick Maupin wrote:
> Out of curiosity, do you feel that eval()'s use of this is somehow
> different? I haven't been able to figure out a real difference yet.
I think the difference is that when you see eval()
you know something dangerous is going on, but most
uses of format() would be harmles
Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> Now that the 20th century is safely behind us, do we still want
> literals with leading zeroes to be interpreted as octal?
Do we deprecate it followed by a later removal (so as to "resist the
temptation to guess")? If so, sounds good to me (I've nev
Now that the 20th century is safely behind us, do we still want literals with
leading zeroes to be interpreted as octal?
Raymond
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http:
-- Forwarded message from python-3000-checkins --
Neal Norwitz schrieb:
> I assume this is not the desired behaviour?
>
class F:
> ... def __dir__(self):
> ... return [5]
> ...
dir(F())
> [5]
f = F()
dir(f)
> [5]
def __dir__(): return [10]
> ...
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> [adding back the list]
(oops)
> On 3/13/07, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > What if the thing to the right of 'as' were assigned different values
> > depending on what it was? If it were one name, it would be the
> > exception (witho
"Patrick Maupin" <[EMAIL PROTECTED]> wrote:
>
> On 3/13/07, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> >
> > Sounds far too implicit to me. I would much prefer a completely
> > different syntax. Having just had a patch that implements Windows shell
> > variable expansion as $var, ${var} and %v
On 3/13/07, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> Sounds far too implicit to me. I would much prefer a completely
> different syntax. Having just had a patch that implements Windows shell
> variable expansion as $var, ${var} and %var% (the last being new), I
> can't help but think that %v
[adding back the list]
On 3/13/07, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> What if the thing to the right of 'as' were assigned different values
> depending on what it was? If it were one name, it would be the
> exception (without traceback) "except ... as foo". If it was a 3-tuple
> of name
Guido van Rossum wrote:
> For uniformity and generality I propose to keep it. So the absolute
> minimal signature for __prepare__ is actually:
>
> def __prepare__(name, bases, *, metaclass=None): ...
>
> this way the prepare function can
> distinguish between an explicit and an implied metaclass
"Thomas Wouters" <[EMAIL PROTECTED]> wrote:
> On 3/13/07, BJorn Lindqvist <[EMAIL PROTECTED]> wrote:
> >
> > On 3/13/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > > > I find this rather cool looking:
> > > > >
> > > > > class C(implements=(I1, I2)): ...
> > >
> > > Me too. :-)
>
>
> Wh
"Patrick Maupin" <[EMAIL PROTECTED]> wrote:
[snip]
> Feature: Alternate syntaxes for escape to markup.
[snip]
> The second method is the well-understood ${} syntax. The $ is easy to
> find in a sea of { characters, and the only special handling required
> is that every $ must be doubled.
I thin
At 08:37 AM 3/14/2007 +1000, Nick Coghlan wrote:
>Greg Ewing wrote:
> > Nick Coghlan wrote:
> >
> >> Generics can live quite happily inside modules and as methods on objects.
> >
> > If instead of pydoc it's some third party module,
> > the situation is even worse, since the module may
> > not even
On 3/13/07, BJörn Lindqvist <[EMAIL PROTECTED]> wrote:
On 3/13/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > I find this rather cool looking:
> > >
> > > class C(implements=(I1, I2)): ...
>
> Me too. :-)
Who is the receiver of the implements keyword argument in your
example? Should
Greg Ewing wrote:
> Nick Coghlan wrote:
>
>> Generics can live quite happily inside modules and as methods on objects.
>
> If instead of pydoc it's some third party module,
> the situation is even worse, since the module may
> not even be installed on the user's system.
>
> So this scheme would
I think we've definitely entered the bikeshed color discussion now.
I'm holding out for Talin's revised version of the PEP.
On 3/13/07, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
> > But in slightly longer examples, I think that the looks are
> > significantly improved...
> >
Josiah Carlson wrote:
> But in slightly longer examples, I think that the looks are
> significantly improved...
>
> class Foo(base1, base2, *otherbases, metaclass=mymeta,
> private=True, **kwargs):
> ...
>
> vs.
>
> @@(metaclass=mymeta, private=True, **kwargs)
> class
Nick Coghlan wrote:
> Generics can live quite happily inside modules and as methods on objects.
I can see a problem with this when applied to
the pydoc problem discussed earlier.
Suppose pydoc were to define some generic functions
for documenting an object. To avoid polluting the
global namespac
At 02:26 PM 3/13/2007 -0700, Josiah Carlson wrote:
>But in slightly longer examples, I think that the looks are
>significantly improved...
>
> class Foo(base1, base2, *otherbases, metaclass=mymeta,
> private=True, **kwargs):
> ...
>
>vs.
>
> @@(metaclass=mymeta, private=True
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> On 3/13/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> > I'm a bit worried that class headers are going to become
> > rather cluttered if we start putting all sorts of stuff
> > in there.
> >
> > E.g. are you intending to put __slots__ there? It makes
>
BJörn Lindqvist schrieb:
> On 3/13/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> > > I find this rather cool looking:
>> > >
>> > > class C(implements=(I1, I2)): ...
>>
>> Me too. :-)
>
> But... What does it do? PEP says:
>
> In the new model, the syntax for specifying a metaclass is via a
At 01:29 PM 3/13/2007 -0400, Barry Warsaw wrote:
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA1
>
>On Mar 13, 2007, at 12:05 PM, Phillip J. Eby wrote:
>
> > However, more people are under the impression that interface
> > testing is
> > safe and pure and smell-free, so there's more of a barrier to
On 3/13/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > I find this rather cool looking:
> > >
> > > class C(implements=(I1, I2)): ...
>
> Me too. :-)
But... What does it do? PEP says:
In the new model, the syntax for specifying a metaclass is via a
keyword argument in the list of base cl
He was talking about
raise ExceptionClass
which I don't want to forbid; it's the
raise ExceptionClass, args
that will be killed in 3.0. You're correct though that in 2.x, "raise
E" instantiates E immediately. We could change this though, as it
works from C...
--Guido
On 3/13/07, Thomas Wo
On 3/13/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
[Quoting Greg E. quoting Guido]
> > I find this rather cool looking:
> >
> > class C(implements=(I1, I2)): ...
Me too. :-)
Boy, you really like it, don't you. Me, too, though. Will that be the syntax
for ABCs then, rather than that si
On 3/13/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> Would this apply to Python code as well? I.e. if you use
> a raise statement with a class, it doesn't get instantiated
> immediately? And if you catch it with an except clause which
> doesn't capture the exception, it's never instantiat
Another bulk reply...
On 3/12/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> Maybe I'm misunderstanding but isn't this a reason that you'd *want*
> the ``**kwargs`` signature? With the plain ``kwargs`` signature from
> the PEP you'd have to do something like::
>
> def __prepare__(name, args,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 13, 2007, at 12:05 PM, Phillip J. Eby wrote:
> However, more people are under the impression that interface
> testing is
> safe and pure and smell-free, so there's more of a barrier to
> overcome for
> them to learn why it's wrong, without
On 3/13/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> > The internal mechanism for bubbling an exception up the stack until an
> > except clause catches it could continue to use the (class, instance,
> > traceback) triple,
>
> Hmmm, so most of that complexity will still be
-- Forwarded message --
From: Thomas Wouters <[EMAIL PROTECTED]>
Date: Mar 9, 2007 5:00 PM
Subject: Re: [Python-3000] Cross-compatibility with 2.6 and 3.0
To: Talin <[EMAIL PROTECTED]>
Cc: Python-3000@python.org
On 3/9/07, Talin <[EMAIL PROTECTED]> wrote:
"It is unlikely that
At 11:51 AM 3/13/2007 -0400, Barry Warsaw wrote:
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA1
>
>On Mar 13, 2007, at 11:06 AM, Phillip J. Eby wrote:
>
> > I prefer to think of adaptation as being a way to provide a
> > namespace for generic functions. :)
> >
> > See http://mail.python.org/piper
At 09:30 AM 3/13/2007 -0400, Barry Warsaw wrote:
>For example, what do you do if you want to talk about 8 attributes
>and a dozen methods as a cohesive unit. Let's say I want to allow
>people to implement an IUser which has an email address, a realname,
>a company, a reference to an IProfile, and
At 10:33 PM 3/13/2007 +1000, Nick Coghlan wrote:
>Greg Ewing wrote:
> > If they're passed to both, then the signatures become
> >
> >metaclass.__prepare__(name, bases, **kwargs)
> >metaclass(name, bases, body, **kwargs)
> >
> > BTW, I don't think I like the name "__prepare__" much
> > more
At 07:16 AM 3/13/2007 -0400, Benji York wrote:
>Phillip J. Eby wrote:
> > In short, the very idea of 'is_file()' is wrong, wrong, wrong. At least,
> > if your goal is to make libraries more robust and reusable.
>
>First a note: I personally hope a generic function system (with multiple
>dispatch)
On 3/12/07, Mark Russell <[EMAIL PROTECTED]> wrote:
> Hopefully I'll have something in the next week or so. Daniel and
> Mike - please let me know if I'm overlapping with anything you're
> working on - I don't want to tread on anyone's toes.
I'm not doing any work on this at the moment, but feel
On 3/12/07, Mark Russell <[EMAIL PROTECTED]> wrote:
> Yes, I suspect that BufferedReader needs some kind of readuntil()
> method, so that (at least for sane encodings like utf-8) each line is
> read via a single readuntil() followed by a decode() call for the
> entire line.
+1
.readuntil() would
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 13, 2007, at 11:06 AM, Phillip J. Eby wrote:
> I prefer to think of adaptation as being a way to provide a
> namespace for generic functions. :)
>
> See http://mail.python.org/pipermail/python-3000/2006-November/
> 004717.html for an implem
On 3/12/07, Patrick Maupin <[EMAIL PROTECTED]> wrote:
> Feature: Ability to pass in a dictionary or tuple of dictionaries of
> namespaces to search.
>
> This feature allows, in some cases, for much more dynamic code than
> *kwargs. (You could manually smush multiple dictionaries together to
> buil
At 09:45 PM 3/12/2007 -0600, Steven Bethard wrote:
>On 3/12/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > At 09:32 PM 3/12/2007 -0600, Steven Bethard wrote:
> > >On 3/12/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> > > > the signature of the method called will be::
> > > > __prepare__(na
At 10:16 AM 3/13/2007 -0400, Barry Warsaw wrote:
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA1
>
>On Mar 13, 2007, at 10:12 AM, Nick Coghlan wrote:
>
> > Generics can live quite happily inside modules and as methods on
> > objects.
> >
> > The important aspect is the ability to tell the generic f
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 13, 2007, at 10:12 AM, Nick Coghlan wrote:
> Generics can live quite happily inside modules and as methods on
> objects.
>
> The important aspect is the ability to tell the generic function
> "here's how to frobnicate a doodad", even though
Barry Warsaw wrote:
> Two other things I wanted to mention. One, I do think adaptation is
> an important (necessary?) aspect to any interface solution for
> exactly the reasons you state. Second, I think the other thing that
> bugs me about a pure-generics solution is that all the generic
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 12, 2007, at 11:06 PM, Phillip J. Eby wrote:
> In short, the very idea of 'is_file()' is wrong, wrong, wrong. At
> least,
> if your goal is to make libraries more robust and reusable. It leads
> inevitably to the brokenness seen in Pydoc --
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 12, 2007, at 7:40 PM, Phillip J. Eby wrote:
> Remember, len(), iter(), and suchlike are all generic functions --
> that just happen to be implemented using reserved method names
> instead of a method registry. Do we need an ILengthMeasurab
Greg Ewing wrote:
> Nick Coghlan wrote:
>> Along similar lines, I'd be marginally happier with:
>>
>>class Bob(meta=Planet): pass
>
> Is there some way we could remove the word "meta"
> from the syntax altogether? I don't mind using
> it in conversation, but it seems a tad too geeky
> to have
Greg Ewing wrote:
> If they're passed to both, then the signatures become
>
>metaclass.__prepare__(name, bases, **kwargs)
>metaclass(name, bases, body, **kwargs)
>
> BTW, I don't think I like the name "__prepare__" much
> more than "__metacreate__". It seems just as wooly.
> What's being
Phillip J. Eby wrote:
> In short, the very idea of 'is_file()' is wrong, wrong, wrong. At least,
> if your goal is to make libraries more robust and reusable.
First a note: I personally hope a generic function system (with multiple
dispatch) makes it into 3.0 and I don't particularly like the A
Nick Coghlan wrote:
> Along similar lines, I'd be marginally happier with:
>
>class Bob(meta=Planet): pass
Is there some way we could remove the word "meta"
from the syntax altogether? I don't mind using
it in conversation, but it seems a tad too geeky
to have as an actual part of the languag
Nick Coghlan wrote:
> - is it intended to typically be a static method or a class method of
> the metaclass? (as it will be called before __new__, an instance method
> of the metaclass wouldn't make sense)
Looks like it will have to be either a staticmethod or
classmethod, or else you'll have
Guido van Rossum wrote:
> The internal mechanism for bubbling an exception up the stack until an
> except clause catches it could continue to use the (class, instance,
> traceback) triple,
Hmmm, so most of that complexity will still be there at
the C level. I was hoping there might be some simpli
Guido van Rossum wrote:
>
> On 3/10/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
>
> > class Foo:
> > class __metaclass__:
>
> Personally, I find code that does this completely unreadable
The reason I'd be a little disappointed to lose this is that
it provides a concise way of defining genuin
Steven Bethard wrote:
> Initially, I was concerned that this would break the symmetry with the
> __metaclass__ signature::
>
> def __metaclass__(name, bases, bodydict):
> def __prepare__(name, bases, kwargs):
Can someone clarify something here: Are the keywords going
to be passed to the p
Guido van Rossum wrote:
> On 3/9/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
>>
>> I'd rather __metacreate__ be called something like __createdict__,
>> __creationdict__, __metadict__, __getmetadict__, etc. where it's
>> clearer that the purpose is to create a dict object.
>>
>
> Agreed; there
67 matches
Mail list logo
