Re: [Python-Dev] Type of range object members

Guido van Rossum wrote: > To be honest I have no idea how/why Martin or Tim picked this name. > Perhaps it is in POSIX? it's from sys/types.h, which is a posix thing, afaik: http://www.opengroup.org/onlinepubs/007908799/xsh/systypes.h.html ___ P

Re: [Python-Dev] no remaining issues blocking 2.5 release

On Tuesday 15 August 2006 14:31, Neal Norwitz wrote: > I just updated the PEP to remove all references to issues blocking > release of 2.5. > I don't know of any. I haven't heard of any issues with the fixes > that have been checked in. > > If you have issues, respond ASAP! The release candidate

Re: [Python-Dev] Type of range object members

On Tuesday 15 August 2006 14:14, Guido van Rossum wrote: > > They don't have to come from a python int, they can come from a > > long.I guess range_new would have to be changed to the 'n' > > conversion code instead of 'l' to do the proper conversion. > > Similarly, rangeiter_next will need to

[Python-Dev] no remaining issues blocking 2.5 release

I just updated the PEP to remove all references to issues blocking release of 2.5. I don't know of any. I haven't heard of any issues with the fixes that have been checked in. If you have issues, respond ASAP! The release candidate is planned to be cut this Thursday/Friday. There are only a few

Re: [Python-Dev] Type of range object members

On 8/14/06, Alexander Belopolsky <[EMAIL PROTECTED]> wrote: > > On Aug 14, 2006, at 10:56 PM, Guido van Rossum wrote: > > > Because the only way to create one (in 2.5 or before) is by passing it > > a Python int. > > Is that true? > > Python 2.4.2 (#2, Jan 13 2006, 12:00:38) > >>> xrange(long(2))

Re: [Python-Dev] Type of range object members

On Aug 14, 2006, at 10:56 PM, Guido van Rossum wrote: > > Because the only way to create one (in 2.5 or before) is by passing it > a Python int. > Is that true? Python 2.4.2 (#2, Jan 13 2006, 12:00:38) >>> xrange(long(2)) xrange(2) > > But since the start and end come from a Python int, what

Re: [Python-Dev] Type of range object members

On 8/14/06, Alexander Belopolsky <[EMAIL PROTECTED]> wrote: > > On Aug 14, 2006, at 7:32 PM, Guido van Rossum wrote: > > > Methinks that as long as PyIntObject uses long (see intobject.h) > > there's no point in changing this to long. > > I guess you meant "changing this to Py_ssize_t ". Yup, sorr

Re: [Python-Dev] Type of range object members

On Aug 14, 2006, at 7:32 PM, Guido van Rossum wrote: > Methinks that as long as PyIntObject uses long (see intobject.h) > there's no point in changing this to long. I guess you meant "changing this to Py_ssize_t ". I don't understand why the type used by PyIntObject is relevant here. Range o

Re: [Python-Dev] Type of range object members

Guido van Rossum wrote: > Methinks that as long as PyIntObject uses long (see intobject.h) > there's no point in changing this to long. Those fields are going to have to change to Py_Object* eventually if xrange() is going to become the range() replacement in Py3k. . . Cheers, Nick. -- Nick Co

Re: [Python-Dev] Arlington VA sprint on Sept. 23

Fred L. Drake, Jr. wrote: > On Monday 14 August 2006 18:21, Georg Brandl wrote: > > * flag RFE patches as RFE ("patch" shouldn't be a category on its own) > > This is something Martin and I have disagreed over in the past. Martin has > indicated that he'd rather see the patches as separate arti

Re: [Python-Dev] Arlington VA sprint on Sept. 23

A.M. Kuchling wrote: > On Tue, Aug 15, 2006 at 12:21:34AM +0200, Georg Brandl wrote: >> * close RFEs and patches which have no chance of going in (there are many >> patches on SF having one or two "-1" comments, is anyone ever going to >> check them in without a python-dev discussion?) > > In

Re: [Python-Dev] Arlington VA sprint on Sept. 23

On Tue, Aug 15, 2006 at 12:21:34AM +0200, Georg Brandl wrote: > * close RFEs and patches which have no chance of going in (there are many > patches on SF having one or two "-1" comments, is anyone ever going to > check them in without a python-dev discussion?) In the past, someone (I think Ray

Re: [Python-Dev] Type of range object members

Methinks that as long as PyIntObject uses long (see intobject.h) there's no point in changing this to long. --Guido On 8/14/06, Alexander Belopolsky <[EMAIL PROTECTED]> wrote: > The range object is currently defined in Objects/rangeobject.c as > > typedef struct { > PyObject_HEAD >

[Python-Dev] Type of range object members

The range object is currently defined in Objects/rangeobject.c as typedef struct { PyObject_HEAD longstart; longstep; longlen; } rangeobject; Is this consistent with PEP 353, or should Py_ssize_t be used instead of long? It looks like some of the code

Re: [Python-Dev] Arlington VA sprint on Sept. 23

On Monday 14 August 2006 18:21, Georg Brandl wrote: > * flag RFE patches as RFE ("patch" shouldn't be a category on its own) This is something Martin and I have disagreed over in the past. Martin has indicated that he'd rather see the patches as separate artifacts rather than as attachments to

Re: [Python-Dev] Fwd: [Python-checkins] r51236 - in python/trunk: Doc/api/abstract.tex Include/abstract.h Include/object.h Lib/test/test_index.py Misc/NEWS Modules/arraymodule.c Modules/mmapmodule.c M

Travis E. Oliphant wrote: > > The idea is that the __index__() method should return an exact int or > exact long or this call will raise an error. The restriction is present > to remove the possibility of infinite recursion (though I'm not sure > where that would occur exactly). > I just rea

Re: [Python-Dev] Arlington VA sprint on Sept. 23

A.M. Kuchling wrote: > The CanDo group continues to have sprints in Arlington, so we may as > well continue to piggyback on their space. The next one will be > Saturday Sept. 23; sign up at > . > > If the PEP 356 plan holds, Python 2.5 will have been r

[Python-Dev] Arlington VA sprint on Sept. 23

The CanDo group continues to have sprints in Arlington, so we may as well continue to piggyback on their space. The next one will be Saturday Sept. 23; sign up at . If the PEP 356 plan holds, Python 2.5 will have been released a week and a half before.

[Python-Dev] ANN: byteplay - a bytecode assembler/disassembler

Hello, I wanted to tell you that I wrote a Python bytecode assembler/disassembler, and would be happy if people tried it and said what they think. I send this message to this list because this module deals with pretty low-level Python, so I thought it might interest the audience here. If I was wr

Re: [Python-Dev] SimpleXMLWriter missing from elementtree

Ralf Schmitt wrote: > any chance to get SimpleXMLWriter (and other modules maybe??) getting > included into xml.etree? Otherwise people might have to stick to the > original elementtree, which doesn't really make sense, since most of > elementtree already is included. the original decision was to

Re: [Python-Dev] Elementtree and Namespaces in 2.5

Martin v. Löwis wrote: > That is not enough reason. Yes, it makes certain applications > impossible, e.g. when namespace prefixes are inside attribute > values. It just means you can't use it for that application, > then. XML has many other applications, and so does ElementTree. there are ways to

Re: [Python-Dev] Elementtree and Namespaces in 2.5

"Chris S" wrote: > and while most users and the w3 spec > (http://www.w3.org/TR/2001/REC-xml-c14n-20010315#NoNSPrefixRewriting) > agree this feature is actually a bug ET's not a canonicalization library, and doesn't claim to be one, so that reference isn't very relevant. And "most users" know t

Re: [Python-Dev] Dict suppressing exceptions

M.-A. Lemburg wrote: > M.-A. Lemburg wrote: >> Guido van Rossum wrote: >>> Marc-Andre, how's the patch coming along? >> I'm working on it. >> >> Since we only want equal compares to generate the warning, >> I have to add a rich compare function to Unicode objects. > > Here's an initial version: >

Re: [Python-Dev] 2.6 idea: a 'function' builtin to parallel classmethod and staticmethod

Guido van Rossum wrote: > It ought to be called @instancemethod for a better analogy. That's actually what I was originally going to suggest. And then I changed my mind after wondering how I would answer the question "Why don't I need to decorate functions with @instancemethod in order to use t