Jim Jewett wrote:
> On 4/29/07, Tim Delaney <[EMAIL PROTECTED]> wrote:
>> I've been intending to write up a PEP for fixing super, but I
>> haven't had time to get to it.
>
> Calvin Spealman has the most recent draft. I hope he will incorporate
> this into his draft.
Sorry about this - wasn't rec
Guido van Rossum wrote:
>> 1. When a method is defined, the class is bound to it via an
attribute
>> (which in my version is called func_class).
> In Py3k all the func_XXX attrs are renamed __XXX__, so this would be
> __class__; but that's a name reserved for something else, so it would
> need to
From: "Delaney, Timothy (Tim)" <[EMAIL PROTECTED]>
> Sorry - this is related to my proposal that the following two bits of
> code behave the same:
>
>class A(object):
>def f(self, *p, **kw):
>super.f(*p, **kw)
>
>class A(object):
>def f(self, *p, **kw):
>
On 4/30/07, Delaney, Timothy (Tim) <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> >> 1. When a method is defined, the class is bound to it via an
> attribute
> >> (which in my version is called func_class).
>
> > In Py3k all the func_XXX attrs are renamed __XXX__, so this would be
> > __c
Delaney, Timothy (Tim) wrote:
> What I'm proposing is that the `super = super_factory()` line be
> implicit in this case, resulting in the following code behaving
> identically:
>
> class A(object):
> def f(self):
> def inner():
> return 'A' + super.f()
>
(-CC python-dev)
On 30/04/2007 5.29, Jim Jewett wrote:
> Rationale for Removing Explicit Line Continuation
>
> A terminal "\" indicates that the logical line is continued on the
> following physical line (after whitespace).
>
> Note that a non-terminal "\" does not have this meaning
On 30/04/2007 3.40, Collin Winter wrote:
> The mechanism I'm most familiar with for solving this problem (which,
> unless I've missed something, is, "how do I make sure this object does
> what I expect?") is Perl 6's roles system; if you know about Squeak
> Smalltalk's "traits" system, you're on t
Jim Jewett wrote:
> Rationale for Removing Implicit String Concatenation
>
> Implicit String concatentation can lead to confusing, or even
> silent, errors. [1]
>
> def f(arg1, arg2=None): pass
>
> f("abc" "def") # forgot the comma, no warning ...
>
On 4/30/07, Tim Delaney <[EMAIL PROTECTED]> wrote:
> I've been working on improved super syntax for quite a while now - my
> original approach was 'self.super' which used _getframe() and mro crawling
> too. I hit on using bytecode hacking to instantiate a super object at the
> start of the method t
From: "Calvin Spealman" <[EMAIL PROTECTED]>
> I believe the direction my PEP took with all this is a good bit
> primitive compared to this approach, although I still find value in it
> because at least a prototype came out of it that can be used to test
> the waters, regardless of if a more direct
On 4/30/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I think these should be two separate proposals, with more specific
> names (e.g. "remove implicit string concatenation" and "remove
> backslash continuation"). There's no need to mention the octal thing
> if it's already a separate PEP.
Pat
At 01:48 PM 4/30/2007 +1200, Greg Ewing wrote:
>Currently, isinstance(x, C) implies that the
>C struct layout of x is compatible with that
>defined by C.
No, it doesn't, and hasn't since Python 2.3.
> I'm worried that changing this
>could cause difficulties for extension modules
>that use PyObj
On 4/30/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> I'm concerned that the current ABC proposal will quickly evolve from optional
> to required and create somewhat somewhat java-esque landscape where
> inheritance and full-specification are the order of the day.
+1 for preferring simple sol
At 06:27 PM 4/30/2007 +1200, Greg Ewing wrote:
>So can we please have another couple of functions that just
>do a simple, reliable concrete type test?
I believe the operation you're looking for (i.e., C-level layout
compatibility) is:
C in type.__mro__.__get__(type(x))
or in Pyrex:
C in (((PyT
GvR wrote:
> So how about we reduce the scope of our (!) PEP (or perhaps of a new
> one) to two items: (a) add @abstractmethod, and (b) overload
> isinstance() and issubclass()? Library authors can do everything they
> want with those, and we can always add a specific set of ABCs for
> containers a
> [Collin Winter]
> +100 I'm very interested in seeing a lighter weight alternative to abc.py
> that:
>
> 1) is dynamic
There's no reason ABC's can't be dynamic.
> 2) doesn't require inheritance to work
> 3) doesn't require mucking with isinstance or other existing mechansims
Using existing me
> On 4/30/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > I'm concerned that the current ABC proposal will quickly evolve from
> > optional
> > to required and create somewhat somewhat java-esque landscape where
> > inheritance and full-specification are the order of the day.
>
> +1 for pref
Collin Winter wrote:
> The key part of traits/roles is that, because the system is separate
> from classes, you can do runtime role composition without a) mucking
> with __bases__, or b) making isinstance() and issubclass() squishy and
> ill-defined. By "runtime role composition", I mean it would b
On 4/30/07, Bill Janssen <[EMAIL PROTECTED]> wrote:
> > [Collin Winter]
> > +100 I'm very interested in seeing a lighter weight alternative to abc.py
> > that:
> >
> > 1) is dynamic
>
> There's no reason ABC's can't be dynamic.
>
> > 2) doesn't require inheritance to work
> > 3) doesn't require mu
For PEP: 3101 - Advanced String Formatting - I would like to suggest
the following additions.
First, that an additional pair of forms be added to format strings so
that callable objects could be used as parameters to the format string
method:
{0()} for positional arguments and
{keyword()} for key
On 30/04/07, Bill Janssen <[EMAIL PROTECTED]> wrote:
> > 6) that doesn't freeze all of the key APIs in concrete
>
> After 15 years of experience with the key APIs, we could perhaps freeze some
> of
> them?
After 15 years not being able to clearly state what "file-like" or
"mapping-like" means to
On 4/30/07, Talin <[EMAIL PROTECTED]> wrote:
> Collin Winter wrote:
> > The key part of traits/roles is that, because the system is separate
> > from classes, you can do runtime role composition without a) mucking
> > with __bases__, or b) making isinstance() and issubclass() squishy and
> > ill-de
On 4/30/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 4/30/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > I think these should be two separate proposals, with more specific
> > names (e.g. "remove implicit string concatenation" and "remove
> > backslash continuation"). There's no need to ment
On 4/30/07, Giovanni Bajo <[EMAIL PROTECTED]> wrote:
> I was in favor of one of the alternatives that were proposed here:
Was? Are you no longer in favor of it? (Then I should shut up. :-)
> line continuation through indentation:
>
> a = 123 *
> (12 + 4) / 8
>
> assert True,
>
On 4/30/07, Bill Janssen <[EMAIL PROTECTED]> wrote:
> GvR wrote:
> > So how about we reduce the scope of our (!) PEP (or perhaps of a new
> > one) to two items: (a) add @abstractmethod, and (b) overload
> > isinstance() and issubclass()? Library authors can do everything they
> > want with those, a
On 4/29/07, Delaney, Timothy (Tim) <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> >> 2. Every non-static method has an implicit cell variable called
> >> 'super'.
> >
> > I think you're using 'cell' in a different sense than it is normally
> > used in Python's implementation. What you are l
On 4/30/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> No existing mechanism would allow PEP 3141 to be distributed as a
> third-party module and still impact the built-in types; that's what
> this whole business of __isinstance__ and __issubclass__ is about. In
> order to achieve dynamic compositi
On 4/30/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 4/30/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > Guido had set an Apr 30 deadline for Py3000 PEPs that can't be
> > implemented in pure python.
>
> I don't recall limiting the deadline in that way. Is this a general
> understanding?
FW
On 4/30/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> On 4/30/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > On 4/30/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > > Guido had set an Apr 30 deadline for Py3000 PEPs that can't be
> > > implemented in pure python.
> >
> > I don't recall limitin
On 4/30/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> On 4/30/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> > No existing mechanism would allow PEP 3141 to be distributed as a
> > third-party module and still impact the built-in types; that's what
> > this whole business of __isinstance__ and __
On 4/30/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> On 4/30/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> > On 4/30/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> > > No existing mechanism would allow PEP 3141 to be distributed as a
> > > third-party module and still impact the built-in types;
While working on the generic function PEP, I came across an unexpected (to
me, anyway) consequence of PEP 3115: it breaks current methods (circa
Python 2.2+) of implementing class decorators. However, there does not
appear to be a class decorator PEP outstanding.
In current Python versions, th
Hm... Where *is* the class decorators PEP? I was expecting it.
Assuming class decorators are added, can't you do all of this using a
custom metaclass?
I'm not sure that your proposal for implementing an improved super has
anything over the currently most-favored proposal by Timothy Delaney.
--Gu
On 4/30/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> On 4/30/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > On 4/30/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > > Guido had set an Apr 30 deadline for Py3000 PEPs that can't be
> > > implemented in pure python.
> >
> > I don't recall limitin
At 12:17 PM 4/30/2007 -0700, Guido van Rossum wrote:
>Hm... Where *is* the class decorators PEP? I was expecting it.
>
>Assuming class decorators are added, can't you do all of this using a
>custom metaclass?
The only thing I need for the GF PEP is a way for a method decorator to get
a callback a
On 4/30/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Hm... Where *is* the class decorators PEP? I was expecting it.
>
Jack Diedrich was working on it.
Jack, you going to get this in to meet the April 30th deadline for
Py3K PEPs (which is obviously today)?
-Brett
I sent an email with an initial PEP to the PEP editors a few weeks
ago. Never got a reply. I noticed some traffic about this recently
but was too busy to follow it really carefully.
Pat
On 4/30/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 4/30/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
On 4/30/07, James Thiele <[EMAIL PROTECTED]> wrote:
> For PEP: 3101 - Advanced String Formatting - I would like to suggest
> the following additions.
>
> First, that an additional pair of forms be added to format strings so
> that callable objects could be used as parameters to the format string
>
From: "Guido van Rossum" <[EMAIL PROTECTED]>
> I'm not sure that your proposal for implementing an improved super has
> anything over the currently most-favored proposal by Timothy Delaney.
Call me Tim ;) Unfortunately, I can't change the format that work sends my
name out as - Delaney, Timoth
On 4/30/07, Tim Delaney <[EMAIL PROTECTED]> wrote:
> Would you prefer me to work with Calvin to get his existing PEP to match my
> proposal, or would you prefer a competing PEP?
Please work together with Calvin. One PEP is enough.
Thanks,
Collin Winter
> > If we simply had a small standard extensible set of APIs, and a way to
> > indicate that a value does or doesn't support one or more of them,
> > we'd be done. We could either add a new mechanism to do this, or simply
> > actually use the one we already have, which should work perfectly well f
> On 30/04/07, Bill Janssen <[EMAIL PROTECTED]> wrote:
> > > 6) that doesn't freeze all of the key APIs in concrete
> >
> > After 15 years of experience with the key APIs, we could perhaps freeze
> > some of
> > them?
>
> After 15 years not being able to clearly state what "file-like" or
> "mappi
> No existing mechanism would allow PEP 3141 to be distributed as a
> third-party module and still impact the built-in types; that's what
> this whole business of __isinstance__ and __issubclass__ is about.
Perhaps 3143 should not be distributed as a third-party module.
Perhaps it should be built
From: "Collin Winter" <[EMAIL PROTECTED]>
> On 4/30/07, Tim Delaney <[EMAIL PROTECTED]> wrote:
>> Would you prefer me to work with Calvin to get his existing PEP to match
>> my
>> proposal, or would you prefer a competing PEP?
>
> Please work together with Calvin. One PEP is enough.
Fine with me
At 02:15 PM 4/30/2007 -0700, Bill Janssen wrote:
>Actually, it hasn't been around in workable form for years.
Correction: Zope's Interface package has been around since 2002; PEAK's
originated in 2003. I'd say those count as both "workable form" and "for
years". :)
>I'm not sure of the actua
On 4/30/07, Bill Janssen <[EMAIL PROTECTED]> wrote:
> > On 4/30/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > > I'm concerned that the current ABC proposal will quickly evolve from
> > > optional
> > > to required and create somewhat somewhat java-esque landscape where
> > > inheritance and
On 4/30/07, BJörn Lindqvist <[EMAIL PROTECTED]> wrote:
[SNIP]
> One really wise person wrote a long while ago (I'm paraphrasing) that
> each new feature should have to prove itself against the standard
> library. That is, a diff should be produced proving that real world
> Python code reads better
2007/4/30, Tim Delaney <[EMAIL PROTECTED]>:
> Fine with me. Calvin - want to send me your latest draft, and I'll do some
> modifications? I think we've got to the point now where we can take this
> off-list.
One more thing: what do people think of modifying super so that when
it doesn't find a met
On 4/30/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
I think these should be two separate proposals, with more specific
names (e.g. "remove implicit string concatenation" and "remove
backslash continuation"). There's no need to mention the octal thing
if it's already a separate PEP.
Revised
The PEP editors have admitted to being behind on the job. AFAIK PEPs
sent to the PEP editors before the deadline are in, regardless of when
the PEP goes online.
To save the PEP editors the effort, if you send it to me I will assign
it a PEP number and submit it. (Ditto for other PEPs in the same
s
This is just the first draft (also checked into SVN), and doesn't include
the details of how the extension API works (so that third-party interfaces
and generic functions can interoperate using the same decorators,
annotations, etc.).
Comments and questions appreciated, as it'll help drive bett
On 4/30/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 12:17 PM 4/30/2007 -0700, Guido van Rossum wrote:
> >Assuming class decorators are added, can't you do all of this using a
> >custom metaclass?
>
> The only thing I need for the GF PEP is a way for a method decorator to get
> a callback aft
On 4/30/07, Lino Mastrodomenico <[EMAIL PROTECTED]> wrote:
> One more thing: what do people think of modifying super so that when
> it doesn't find a method instead of raising AttributeError it returns
> something like "lambda *args, **kwargs: None"?
To me, the most important change is correctnes
On 4/30/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> On 4/30/07, Tim Delaney <[EMAIL PROTECTED]> wrote:
> > Would you prefer me to work with Calvin to get his existing PEP to match my
> > proposal, or would you prefer a competing PEP?
>
> Please work together with Calvin. One PEP is enough.
And
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Apr 30, 2007, at 6:47 PM, Guido van Rossum wrote:
> The PEP editors have admitted to being behind on the job. AFAIK PEPs
> sent to the PEP editors before the deadline are in, regardless of when
> the PEP goes online.
>
> To save the PEP editors the
On 4/30/07, Lino Mastrodomenico <[EMAIL PROTECTED]> wrote:
2007/4/30, Tim Delaney <[EMAIL PROTECTED]>:
> Fine with me. Calvin - want to send me your latest draft, and I'll do
some
> modifications? I think we've got to the point now where we can take this
> off-list.
One more thing: what do peo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Apr 27, 2007, at 1:10 PM, Jim Jewett wrote:
> On 4/27/07, Barry Warsaw <[EMAIL PROTECTED]> wrote:
>
>> - - Attributes. Interfaces allow you to make assertions about
>> attributes, not just methods, while ABCs necessarily cover only
>> methods.
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Apr 27, 2007, at 2:17 PM, Tony Lownds wrote:
> +0 on abstract attributes. Methods seem to dominate most APIs that
> make
> use of interfaces, but there are always a few exceptions.
One of the reasons to be able to specify attributes in an ABC or
On 4/30/07, Lino Mastrodomenico <[EMAIL PROTECTED]> wrote:
> 2007/4/30, Tim Delaney <[EMAIL PROTECTED]>:
> > Fine with me. Calvin - want to send me your latest draft, and I'll do some
> > modifications? I think we've got to the point now where we can take this
> > off-list.
>
> One more thing: what
On 4/30/07, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> On Apr 27, 2007, at 2:17 PM, Tony Lownds wrote:
> > +0 on abstract attributes. Methods seem to dominate most APIs that
> > make use of interfaces, but there are always a few exceptions.
>
> One of the reasons to be able to specify attributes in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Apr 30, 2007, at 6:01 PM, BJörn Lindqvist wrote:
> On 4/30/07, Bill Janssen <[EMAIL PROTECTED]> wrote:
>>> On 4/30/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
I'm concerned that the current ABC proposal will quickly evolve
from opt
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Apr 30, 2007, at 6:31 PM, Brett Cannon wrote:
> I think it would be a little difficult in this situation as since a
> similar mechanism does not currently exist in the stdlib and so most
> code is not written so that ABCs or roles are needed.
This
On 4/30/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
This is just the first draft (also checked into SVN), and doesn't include
the details of how the extension API works (so that third-party interfaces
and generic functions can interoperate using the same decorators,
annotations, etc.).
Commen
On 4/30/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> It is currently an open issue to determine the best way to implement
> this rule in Python 3.0. Under Python 2.x, a class' metaclass was
> not chosen until the end of the class body, which means that
> decorators could insert a custom metacl
On 4/30/07, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> On Apr 27, 2007, at 1:10 PM, Jim Jewett wrote:
> > On 4/27/07, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> >> Finally, I'm concerned with the "weight" of adding ABCs to all the
> >> built-in types.
> > What if the builtin types did not initially
> > > On 4/27/07, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> > >> Finally, I'm concerned with the "weight" of adding ABCs to all the
> > >> built-in types.
> > On Apr 27, 2007, at 1:10 PM, Jim Jewett wrote:
> > > What if the builtin types did not initially derive from any ABC, but
> > > were added
Calvin Spealman wrote:
> I also checked and PyPy does implement a sys._getframe() and a
> IronPython currently doesn't, but seems to plan on it (there is a
> placeholder, at present). I am not sure if notes on this belongs in
> the PEP or not.
If this is to have a chance, you really need to
come
At 03:54 PM 4/30/2007 -0700, Guido van Rossum wrote:
>On 4/30/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>>At 12:17 PM 4/30/2007 -0700, Guido van Rossum wrote:
>> >Assuming class decorators are added, can't you do all of this using a
>> >custom metaclass?
>>
>>The only thing I need for the GF PE
At 04:10 PM 4/30/2007 -0700, Guido van Rossum wrote:
>And don't get me started abut __init__. Constructors don't do
>cooperative MI, period.
Actually, metaclass __init__'s do. In fact, they *have to*.
Right now, we get away with it because the type(name, bases, dict)
signature is fixed. Once w
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Apr 30, 2007, at 7:43 PM, Guido van Rossum wrote:
> Right. int (long doesn't exist in py3k!) doesn't change -- the only
> thing that "changes" is that the question subclass(int, Integer) is
> answered positively, but since you can't ask that questi
At 04:19 PM 4/30/2007 -0700, Brett Cannon wrote:
>Doubt there is a ton of use for it, but any way to use this for pattern
>matching ala Standard ML or Haskell?
Yes. You have to provide a different dispatching engine though, as will be
described in the currently non-existent "extension API" sect
At 07:29 PM 4/30/2007 -0400, Jim Jewett wrote:
>On 4/30/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>
>>It is currently an open issue to determine the best way to implement
>>this rule in Python 3.0. Under Python 2.x, a class' metaclass was
>>not chosen until the end of the class body, which mea
After a couple of whiteboard discussions with Collin Winter and
Jeffrey Jasskin I have a much better grip on where to go next with the
ABC PEPs.
(a) Roles
Collin will continue to develop his Roles PEP. This may or may not end
up providing a viable alternative to ABCs; in either case it will be
re
On 4/25/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > There are only a few use-cases (that I can think of) where Python's
> > list() regularly outperforms the BList. These are:
> >
> > 1. A large LIFO stack, where there are many .append() and .pop(-1)
> > operations. These are O(1) for a P
On 4/30/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 03:54 PM 4/30/2007 -0700, Guido van Rossum wrote:
> >On 4/30/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> >>At 12:17 PM 4/30/2007 -0700, Guido van Rossum wrote:
> >> >Assuming class decorators are added, can't you do all of this using a
Patrick Maupin wrote:
> Method calls are deliberately disallowed by the PEP, so that the
> implementation has some hope of being securable.
If attribute access is allowed, arbitrary code can already
be triggered, so I don't see how this makes a difference
to security.
--
Greg
___
Bill Janssen wrote:
>>On 30/04/07, Bill Janssen <[EMAIL PROTECTED]> wrote:
>>After 15 years not being able to clearly state what "file-like" or
>>"mapping-like" means to different people, perhaps we should accept
>>that there is no clear-cut answer...?
>
> And that's a problem -- people are confu
At 05:19 PM 4/30/2007 -0700, Guido van Rossum wrote:
>Collin will continue to develop his Roles PEP. This may or may not end
>up providing a viable alternative to ABCs; in either case it will be
>refreshing to compare and contrast the two proposals.
These should also be interesting to compare with
At 05:38 PM 4/30/2007 -0700, Guido van Rossum wrote:
>Of course, once the core language adds built-in support for such a
>feature, it becomes slightly less advanced, and it is reasonable to
>expect that the special functionality be provided by object or type or
>some other aspect of the standard cl
Raymond Hettinger wrote:
> [Collin Winter]
>> Put another way, a role is an assertion about a set of capabilities.
> . . .
>> If there's interest in this, I could probably whip up a PEP before the
>> deadline.
>
> +100 I'm very interested in seeing a lighter weight alternative to abc.py
> that:
On 4/30/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 05:38 PM 4/30/2007 -0700, Guido van Rossum wrote:
> >Of course, once the core language adds built-in support for such a
> >feature, it becomes slightly less advanced, and it is reasonable to
> >expect that the special functionality be provi
Greg Ewing wrote:
> Patrick Maupin wrote:
>
>> Method calls are deliberately disallowed by the PEP, so that the
>> implementation has some hope of being securable.
>
> If attribute access is allowed, arbitrary code can already
> be triggered, so I don't see how this makes a difference
> to securi
On 4/30/07, BJörn Lindqvist <[EMAIL PROTECTED]> wrote:
> On 4/30/07, Bill Janssen <[EMAIL PROTECTED]> wrote:
> > > +1 for preferring simple solutions to complex ones
> >
> > Me, too. But which is the simple solution? I tend to think ABCs are.
>
> Neither or. They are both an order of a magnitude
On 4/30/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> The correct
> approach is for TotallyOrdered to be a metaclass (is this the
> typeclass thing in Haskell?).
Mmmm. Typeclasses don't *feel* like metaclasses. Haskell types
aren't objects.
A typeclass is like an interface, but more express
Proto-PEP: Information Attributes (First Draft)
Proposal:
Testing hasattr() is a broadly applicable and flexible technique that works well
whenever the presence of a method has an unambiguous interpretation
(i.e. __hash__ for hashability, __iter__ for iterability, __len__ for sized
containers);
PEP: Remove Implicit String Concatenation
Motivation
One goal for Python 3000 should be to simplify the language by removing
unnecessary features. Implicit string concatenation should be dropped in
favor of existing techniques. This will simplify the grammar and simplify a
user's mental picture
86 matches
Mail list logo
