Guido van Rossum wrote:
> 2008/8/21 Nick Coghlan <[EMAIL PROTECTED]>:
>> Levi wrote:
>>> Now, I understand that set doesn't return NotImplemented to avoid having
>>> it's __cmp__ method called, but what I don't get is why it has a __cmp__
>>> method at all. I thought the entire point of set and co.
2008/8/21 Nick Coghlan <[EMAIL PROTECTED]>:
> Levi wrote:
>> Now, I understand that set doesn't return NotImplemented to avoid having
>> it's __cmp__ method called, but what I don't get is why it has a __cmp__
>> method at all. I thought the entire point of set and co. using the rich
>> comparison
Levi wrote:
> Now, I understand that set doesn't return NotImplemented to avoid having
> it's __cmp__ method called, but what I don't get is why it has a __cmp__
> method at all. I thought the entire point of set and co. using the rich
> comparison operators is that Sets only define a partial order
Greg Ewing wrote:
Levi wrote:
Recently I've taken some interest in PEP 3106 (revamping dick.keys,
^
Is this a feature related to some kind of chastity belt for men? :-)
I didn't notice that until I recived the message from the list. Truely
an embarrasssing typo to say the least.
Greg Ewing wrote:
Levi wrote:
Recently I've taken some interest in PEP 3106 (revamping dick.keys,
^
Is this a feature related to some kind of chastity belt for men? :-)
Maybe it's a brand new, special feature when a dict cont
Levi wrote:
Recently I've taken some interest in PEP 3106 (revamping dick.keys,
^
Is this a feature related to some kind of chastity belt for men? :-)
--
Greg
___
Python-3000 mailing
Recently I've taken some interest in PEP 3106 (revamping dick.keys,
etc.) and wrote a rough draft of an experimental implementation in
Python. Along the way I noticed a few things that I think need some
discussion. A lot of them have to do with the interaction with PEP 3119
(Abstract Base Class
Hi,
Georg Brandl gmx.net> writes:
> * 3134 -- exception chaining
There are few things to correct/clean up:
(1) The "C API" paragraph contains incorrect information:
- the sentence "The PyErr_Set* calls for setting exceptions will not set the
'__context__' attribute on exceptions" is wrong. T
There are some "accepted" PEPs that are, AFAIK, fully implemented.
There shouldn't be much work left to bring them to "final" state:
* 358 -- bytes object
* 370 -- per-user site-packages directory
* 371 -- multiprocessing
* 3101 -- adv. string formatting
* 3106 -- dict.keys() etc.
* 3116 -- ne
Daniel Stutzbach wrote:
> I actually don't think it will be that bad, since list operations go
> through one thin API. I just need to redirect the API in listobject.h
> and I'm mostly done.
Some of that API consists of macros that index directly
into the list. Currently those are O(1) and inline
> I haven't used the python.org wiki before. If you point me to the
> right place put a link to a BList page, I'd be happy to create one.
> Somewhere under UsefulModules?
That would be a good place:
http://wiki.python.org/moin/UsefulModules
Raymond
__
On 5/11/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> Newly developed code always faces an uphill battle when compared to
> mature open-source.
As it should. :-)
> End-users (everyday Python programmers) need to be understand the
> performance intuitively and have a clear understanding of wh
> Thanks for taking time to review my code.
You welcome. And thanks for the continuing development effort.
> Did you look through the PEP as well?
Yes.
> In fact, I am half way done with implementing the change so
> that small BLists are memory efficient.
As the code continues to evolve, I'l
On 5/10/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > 3128 (BList) -- I'll leave this for Raymond Hettinger to review.
>
> After looking at the source, I think this has almost zero chance for replacing
> list(). There is too much value in a simple C API, low space overhead for
> small list
On 5/10/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> I did not see octal literals on your list. FWIW, I'm -1 on the proposal.
> The current situation is only a minor nuisance. While I prefer to see octal
> literal support dropped entirely, I would rather live with the 0123 form than
> a
On 5/10/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> The PEP for eliminating __del__ seemed straight-forward
> at the outset, but the use case you presented doesn't
> seem to have a clean substitute (as it requires the object
> to be alive to finalize it). Other use cases do have a clean
> s
> and rejected some others:
> SR 3126 Remove Implicit String Concatenation Jewett
I had high hopes for this one. Cie le vie.
I did not see octal literals on your list. FWIW, I'm -1 on the proposal. The
current situation is only a minor nuisance. While I prefer to see octal
literal
I've accepted some PEPs:
SA 3120 Using UTF-8 as the default source encoding von Löwis
SA 3121 Extension Module Initialization & Finalization von Löwis
SA 3123 Making PyObject_HEAD conform to standard C von Löwis
SA 3127 Integer Literal Support and Syntax Maupin
SA 3129 Cla
Guido van Rossum schrieb:
> And it's in the p3yk branch, too.
>
> The main reason these are all still drafts is that I expect that
> implementing them may cause a certain amount of redesign, and in some
> cases the spec isn't entirely clear. The "real" acceptance status (in
> my head) is all over
And it's in the p3yk branch, too.
The main reason these are all still drafts is that I expect that
implementing them may cause a certain amount of redesign, and in some
cases the spec isn't entirely clear. The "real" acceptance status (in
my head) is all over the map -- 3102 is obviously accepted,
On 2/17/07, Talin <[EMAIL PROTECTED]> wrote:
> I don't know about the others, however I want to speak to the issue of
> 3101 and 3102, since I wrote them - the main reason that those PEPs
> haven't been accepted is that there's no sample implementation to
> evaluate. (At least, I'm not aware of any
Eduardo "EdCrypt" O. Padoan wrote:
> All the 3xxx PEPs except 3100 and the "meta" ones are marked a draft.
> While I understand that many has some open issues, even the
> implemented ones (3102, 3105, 3106, 3107, 3110) still run the risk of
> being withdrawn?
I don't know about the others, howeve
All the 3xxx PEPs except 3100 and the "meta" ones are marked a draft.
While I understand that many has some open issues, even the
implemented ones (3102, 3105, 3106, 3107, 3110) still run the risk of
being withdrawn?
--
EduardoOPadoan (eopadoan->altavix::com)
Bookmarks: http://del.icio.us/edcryp
23 matches
Mail list logo
