Greg Ewing <[EMAIL PROTECTED]> wrote:
>
> Jack Diederich wrote:
>
> > I am a very big fan of ordered dicts in classes. One possibility is that
> > suites in classes always store their order in a special dict that keeps a
> > side list of key order. A final invisible class decorator around
> >
On Mar 9, 2007, at 2:35 PM, Guido van Rossum wrote:
> On 3/9/07, Tony Lownds <[EMAIL PROTECTED]> wrote:
>> With tuple parameters removed, there would still be divergence in
>> 2.X.
>
> But not much; we could drop the annotation feature for tuple
> parameters (since it won't survive in 3.0) and w
Josiah Carlson wrote:
> Also, depending on the use, one may want to know the order in a 'move to
> end' fashion (if a is assigned to multiple times, it ends up in the
> ordering as if only the last assignment was done).
This is why I feel it is insufficient to keep just a record of what key
names
Greg Ewing wrote:
> Talin wrote:
>
>>class Foo(base1, base2, metaclass=mymeta):
>> ...
>
> -1 on this syntax, I think it's ugly.
All I can say is, beauty is in the eye, etc...in any case, I'm not the
one to decide what's pretty and what's not.
> Alternative proposals:
>
>
Tony Lownds schrieb:
>>> or fixing the assertion failure currently in CVS.
>>
>> Perhaps you should switch to SVN? :-)
>
> Heh, clearly I am behind the times. I should switch to Mercurial
> to get ahead of the curve.
You should rather switch to Bazaar and Mercurial at the same time,
as I expect
Jack Diederich schrieb:
> I am a very big fan of ordered dicts in classes. One possibility is that
> suites in classes always store their order in a special dict that keeps a
> side list of key order. A final invisible class decorator around
> every class would then toss out the order and leave
On Sat, Mar 10, 2007 at 10:26:09AM +0100, Georg Brandl wrote:
> Tony Lownds schrieb:
>
> >>> or fixing the assertion failure currently in CVS.
> >>
> >> Perhaps you should switch to SVN? :-)
> >
> > Heh, clearly I am behind the times. I should switch to Mercurial
> > to get ahead of the curve.
>
Greg Ewing <[EMAIL PROTECTED]> wrote:
>
> Talin wrote:
>
> >class Foo(base1, base2, metaclass=mymeta):
> > ...
>
> -1 on this syntax, I think it's ugly.
>
> Alternative proposals:
>
>class Foo(base1, base2) as MyMeta:
> ...
While I don't particularly like the foo(b
Josiah Carlson wrote:
> There are two semantics that I would be happy with. Either force
> metaclasses to have a .metadict() or equivalent method (or a callable
> attribute in the case of arbitrary callables), or even allow
> __metaclass__ to be a tuple:
>
> class foo(...):
> __metacl
As an experiment with the new IO library (http://docs.google.com/Doc?
id=dfksfvqd_1cn5g5m), I added support for walking through the lines
of a file backwards using the reversed() iterator:
for line in reversed(open(path)):
...
It works by scanning backwards through the file a bl
At 08:45 PM 3/10/2007 +1300, Greg Ewing wrote:
>Jack Diederich wrote:
>
> > I am a very big fan of ordered dicts in classes. One possibility is that
> > suites in classes always store their order in a special dict that keeps a
> > side list of key order. A final invisible class decorator around
>
Talin <[EMAIL PROTECTED]> wrote:
> I strongly feel that this makes *using* metaclasses way too complex. A
> person wanting to create a C struct or a database record should simply
> have to say "metaclass=cstruct" - they shouldn't have to declare a bunch
> of individual pieces, all of which have
At 12:40 PM 3/10/2007 -0800, Josiah Carlson wrote:
>Talin <[EMAIL PROTECTED]> wrote:
> > I strongly feel that this makes *using* metaclasses way too complex. A
> > person wanting to create a C struct or a database record should simply
> > have to say "metaclass=cstruct" - they shouldn't have to de
"Phillip J. Eby" <[EMAIL PROTECTED]> wrote:
> At 12:40 PM 3/10/2007 -0800, Josiah Carlson wrote:
>
> >Talin <[EMAIL PROTECTED]> wrote:
> > > I strongly feel that this makes *using* metaclasses way too complex. A
> > > person wanting to create a C struct or a database record should simply
> > > ha
On Mar 9, 2007, at 2:35 PM, Guido van Rossum wrote:
> On 3/9/07, Tony Lownds <[EMAIL PROTECTED]> wrote:
>> By the way, I would like to work on either removing tuple parameters
>> in 3.0
>
> That would be great!
>
I've posted a patch removing tuple parameters as #1678060.
There was one case in i
Tony Lownds schrieb:
> On Mar 9, 2007, at 2:35 PM, Guido van Rossum wrote:
>
>> On 3/9/07, Tony Lownds <[EMAIL PROTECTED]> wrote:
>>> By the way, I would like to work on either removing tuple parameters
>>> in 3.0
>>
>> That would be great!
>>
>
> I've posted a patch removing tuple parameters as
There are a few files which seemingly don't belong in their subdirectories:
* Python/bltinmodule.c -> Modules
* Python/sysmodule.c -> Modules
* parts of Python/import.c -> Modules/impmodule.c
* Python/traceback.c -> Objects
* Modules/getpath.c -> Python
* Modules/getbuildinfo.c -> Python
* Modul
Talin wrote:
> The relation
> between a class and a metaclass isn't well-expressed with 'as', 'is', or
> 'equals'.
Okay, then make it
class Foo(base1, base2) isa MyMeta:
...
--
Greg
___
Python-3000 mailing list
Python-3000@python.org
http://
Some more metaclass syntax ideas:
class Foo[Meta](bases):
...
Meta class Foo(bases):
...
although I don't like the way the latter moves the
'class' keyword away from the beginning.
Another thought: It's not strictly necessary to
allow for arguments to the metaclass, since the sa
On 3/10/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> There are a few files which seemingly don't belong in their subdirectories:
>
> * Python/bltinmodule.c -> Modules
> * Python/sysmodule.c -> Modules
> * parts of Python/import.c -> Modules/impmodule.c
>
> * Python/traceback.c -> Objects
>
The ab
On 3/9/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Guido van Rossum schrieb:
> > I don't recall ripping them out, but it's worth trying to do that --
> > they really shouldn't be needed for modern extensionmodules (2.2+).
> >
> > On 3/7/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> >> While revie
Greg Ewing wrote:
> Another thought: It's not strictly necessary to
> allow for arguments to the metaclass, since the same
> effect can be achieved with a factory function, like
> we do for decorators.
True. The main reason for doing it the way that I did, is to allow for
the future possibility o
On 3/10/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 3/9/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
[SNIP]
> > Okay, I looked into it.
> > The old attribute semantics of offering a custom tp_getattr
> > which dispatches to methods and members is mainly used in very old
> > and platform-spe
Talin wrote:
> I'll give you an example: Suppose the author of Pyrex realizes that
Of course, only an idiot would be unaware that "the author of Pyrex" is
in fact the person who he is replying to. Which means I must have meant
to do that. Uh-huh. Right. :)
-- Talin
Josiah Carlson wrote:
> As such, the compiler, etc., needs to be taught to pull out the
> __metaclass__ definition before executing the class body, but that's
> better than mucking with the syntax of class foo(...).
I'd be happy with that.
Also, for the name of the method for creating the
dict,
Josiah Carlson wrote:
> I did have a post that was going to show that they were related, but
> then I remembered that because of __metaclass__ assignment semantics, it
> needs to necessarily have access to the class body dictionary at the
> point of assignment, so the compiler, etc., cannot be tau
On 3/10/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
[snip]
> And does anyone else find test.test_support an odd name; it isn't
> testing anything! I really want to rename that module test.support or
> make it the __init__ module for 'test'.
+1 for test.support, if it's to be renamed.
Collin Wint
Greg Ewing <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
> > I did have a post that was going to show that they were related, but
> > then I remembered that because of __metaclass__ assignment semantics, it
> > needs to necessarily have access to the class body dictionary at the
> > point of
Josiah Carlson wrote:
> class foo(...):
> a = ...
> __metaclass__ = callable(a, ...)
Personally I wouldn't mind if it were made a requirement
that __metaclass__, if it is present, must be the first
name bound in the class body (and can't be inside an
if statement, etc.)
Does
Talin wrote:
> The main reason for doing it the way that I did, is to allow for
> the future possibility of the *default* metaclass interpreting some of
> those keywords.
Hmmm. I can see how you would need some way of passing
keywords in order to do that. But in the absence of any
real use cases
30 matches
Mail list logo
