> It sounds like a good thing, but what is the impact? How much code will be
> broken by this proposal?
Nearly all extension modules will be broken, as PyObject_HEAD goes away.
However, it is likely that Py3k breaks all extension modules for a lot
of other reasons, as well.
Fixing this specific
On 4/27/07, Adam Olsen <[EMAIL PROTECTED]> wrote:
> On 4/27/07, Thomas Lotze <[EMAIL PROTECTED]> wrote:
> > Guido van Rossum wrote:
> >
> > > Another constraint is that hashable objects, once created, should
> > > never change their value (as compared by ``==``) or their hash value.
> > >
On 4/27/07, Thomas Lotze <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> > Another constraint is that hashable objects, once created, should
> > never change their value (as compared by ``==``) or their hash value.
> > If a class cannot guarantee this, it should not derive from
On 4/27/07, Jeffrey Yasskin <[EMAIL PROTECTED]> wrote:
> On 4/18/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > Agreed. But there aren't 40K (alphabetic) letters in any particular
> > locale. Most individual languages will have less than 100.
> Here's a relevant bunch of data from the CLDR:
> ht
"Martin v. Löwis" wrote:
> I propose the PEP below for Py3k.
>
> Regards,
> Martin
>
> PEP: 3122
> Title: Dropping PyObject_HEAD
> Version: $Revision: 54998 $
> Last-Modified: $Date: 2007-04-27 10:31:58 +0200 (Fr, 27 Apr 2007) $
> Author: Martin v. Löwis <[EMAIL PROTECTED]>
> Status: Draft
> Typ
On 4/18/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 4/18/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > On 4/18/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
>
> > > Today, string.letters works most easily with ASCII supersets, and is
> > > effectively limited to 8-bit encodings. Once everythi
This PEP says that no ABC defines __init__ or a couple other methods.
Is that a prohibition on ABCs in general, or just a comment about the
ones defined here?
Can properties be abstract? How would one specify it? (Is that
@abstractattribute?)
On the orderings: If I have a function foo(a, b) and I
Second PEP today. Martin is on a roll! =)
On 4/27/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> I propose the PEP below for Py3k.
>
> Regards,
> Martin
>
> PEP: 3122
> Title: Dropping PyObject_HEAD
> Version: $Revision: 54998 $
> Last-Modified: $Date: 2007-04-27 10:31:58 +0200 (Fr, 27 Apr 2
I propose the PEP below for Py3k.
Regards,
Martin
PEP: 3122
Title: Dropping PyObject_HEAD
Version: $Revision: 54998 $
Last-Modified: $Date: 2007-04-27 10:31:58 +0200 (Fr, 27 Apr 2007) $
Author: Martin v. Löwis <[EMAIL PROTECTED]>
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Create
On 4/26/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> - Where should PartiallyOrdered and TotallyOrdered live?
Could someone please post some sample code using either of
these? I don't see what they're good for.
Here's my failed attempt:
def my_max(a : TotallyOrdered, b : TotallyOrdered):
Jim Jewett wrote:
> Yes, but it is a TypeError today. Is it worth the backwards
> compatibility?
I'd say yes for the sake of doing things right, in particular as we are
talking about Py3k, but then I don't think I have a good picture of all
the things that would be broken by this change.
> That
On 4/27/07, Thomas Lotze <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > ``__hash__`` for those instances should raise a ``TypeError``
> > exception.
> Shouldn't this rather be a ValueError since it occurs not because of the
> type of the object in question, but its value (while
Guido van Rossum wrote:
> Another constraint is that hashable objects, once created, should
> never change their value (as compared by ``==``) or their hash value.
> If a class cannot guarantee this, it should not derive from
> ``Hashable``; if it cannot guarantee this for certain
The PEP looks good. A few nits and a couple of related questions:
MutableSet.pop() "...removes an arbitrary..." # should be "...removes and
returns an arbitrary..."
BasicMapping .__contains__() # should be .__contains__(key)
In Mapping.__eq__, "if and only iff" is redundant. And yes, I think th
On Apr 27, 2007, at 10:40 AM, Bill Janssen wrote:
> 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.
>>
>> Why can't the
On 4/27/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Continuing a discussion from last April, I added
> PEP 3121, included below for convenience. Please
> comment.
>
> Regards,
> Martin
>
> PEP: 3121
> Title: Module Initialization and finalization
> Version: $Revision: 54998 $
> Last-Modified
Phillip J. Eby wrote:
> As someone with more recent background in Java than C++, I find the idea of
> abstract methods having an executable implementation to be quite confusing,
> and suspect that other people with that Java or C# background will do the
> same thing. That is, skim the explanati
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.
>
> Why can't they have data attributes as well?
I agree with Jim. It seems t
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.
Why can't they have data attributes as well?
> - - With interfaces, you can make assertions about indivi
On 4/26/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> - Where should PartiallyOrdered and TotallyOrdered live?
The abc module seems reasonable, even though the rest are containers.
> - Should we support comparison of different concrete set types?
> - Ditto for mapping types?
> - Ditto for se
At 07:25 PM 4/27/2007 +1200, Greg Ewing wrote:
>Talin wrote:
>
> > I kind of wonder about the idea of implementing generic functions using
> > generic functions.
>
>I'd be worried about efficiency. Generic functions on
>top of generic functions sounds like you would have two
>layers of dynamic look
On 4/27/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 4/27/07, Jan Grant <[EMAIL PROTECTED]> wrote:
> > On Thu, 26 Apr 2007, Dan Christensen wrote:
> >
> > > Note also that double-precision reals are a subset of the rationals,
> > > since each double precision real is exactly representable a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Apr 27, 2007, at 4:21 AM, Greg Ewing wrote:
> Guido van Rossum wrote:
>
>> Then how do you explain the popularity of zope.interfaces in both the
>> Zope and the Twisted world?
>
> I don't know -- from my point of view, the fact that
> Zope and Twis
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Apr 26, 2007, at 2:50 PM, Guido van Rossum wrote:
> After a fair amount of pre-discussion, I'm ready for the first
> official review of this PEP. The PEP is online at
> http://www.python.org/dev/peps/pep-3119/
Thanks for posting the PEP Guido. I
On 4/27/07, Jan Grant <[EMAIL PROTECTED]> wrote:
> On Thu, 26 Apr 2007, Dan Christensen wrote:
>
> > Note also that double-precision reals are a subset of the rationals,
> > since each double precision real is exactly representable as a
> > rational number, but many rational numbers are not exactly
On Thu, 26 Apr 2007, Dan Christensen wrote:
> Note also that double-precision reals are a subset of the rationals,
> since each double precision real is exactly representable as a
> rational number, but many rational numbers are not exactly
> representable as double precision reals. Not sure if t
Continuing a discussion from last April, I added
PEP 3121, included below for convenience. Please
comment.
Regards,
Martin
PEP: 3121
Title: Module Initialization and finalization
Version: $Revision: 54998 $
Last-Modified: $Date: 2007-04-27 10:31:58 +0200 (Fr, 27 Apr 2007) $
Author: Martin v. Löwi
I added PEP 3120 (Using UTF-8 as the default source encoding,
http://www.python.org/dev/peps/pep-3120/) to the repository.
Should I set it to the accepted state?
Martin
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/l
Guido van Rossum wrote:
> Then how do you explain the popularity of zope.interfaces in both the
> Zope and the Twisted world?
I don't know -- from my point of view, the fact that
Zope and Twisted rely on them so much seems like a
strangely unpythonic aberration. They don't seem to
have caught on
After a fair amount of pre-discussion, I'm ready for the first
official review of this PEP. The PEP is online at
http://www.python.org/dev/peps/pep-3119/ . Here's a summary of open
issues on which I could use more help (more details in the full text
of the PEP below):
- Where should PartiallyOrder
Talin wrote:
> I kind of wonder about the idea of implementing generic functions using
> generic functions.
I'd be worried about efficiency. Generic functions on
top of generic functions sounds like you would have two
layers of dynamic lookup to go through instead of one.
--
Greg
__
31 matches
Mail list logo
