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

[Nick Coghlan]

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 
them as instance methods, but I need to decorate them with @classmethod and 
@staticmethod to use them as class and static methods?".

However, now that I've thought about it some more, the explanation would 
simply be that functions behave like instancemethod instances by default, 
while other callables typically behave like staticmethod instances.

So instancemethod(f) would return the passed in object for an actual function, 
and a wrapper with an appropriate __get__ method for anything else (stealing 
__doc__ etc from the original callable).

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Dict suppressing exceptions

[M.-A. Lemburg]

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:
> 
> http://sourceforge.net/tracker/index.php?func=detail&aid=1538956&group_id=5470&atid=305470
> 
> The title of the patch is slightly incorrect - SF doesn't allow
> more descriptive titles... :-(

FYI: I've checked in the patch as revision 51276.

Please give it some serious testing.

All tests pass, but there may still be some corner cases left
which the tests don't catch.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 14 2006)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! 
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fredrik Lundh]

"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 that ET uses a simplified infoset; it's 
not exactly
a secret.

I think you need to work on your FUD skills.

> at least patch the stdlib's version of Elementtree to produce an output
> more in line with the w3 standard.

And that patch would look exactly how ?

 



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fredrik Lundh]

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 deal with this in ET, though; the "iterparse" interface gives 
you
access to namespace prefixes, the semi-official _namespace_map dictionary gives
you better control over how the default serializer maps URI:s to prefixes, and 
the
"QName" wrapper allows you to use qualified names for individual attribute 
values.

dealing with namespace abusers such as SOAP and similar XML dialects are per-
fectly possible, and usually not very hard.

(ET 1.3 will probably improve things further, but that won't be out before 2.5 
final.)

 



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] SimpleXMLWriter missing from elementtree

[Fredrik Lundh]

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 start with three fundamental modules, and
leave out less popular and potentially less stable modules.

leaving out SimpleXMLWriter (and perhaps the HTML stuff) might have
been a mistake, but with 2.5 in final beta, that's how things are going to be
in 2.5.

 



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Noam Raphael]

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 wrong - please forgive me.

The idea is to define an object which is equivalent to Python's code
object, but which is easy to work with. To explain what I mean, I'll
show a quick example. We can define this stupid function:

>>> def f(a, b):
... print (a, b)

We can convert it to an equivalent object, and see how it stores the byte code:

>>> from byteplay import *
>>> c = Code.from_code(f.func_code)
>>> from pprint import pprint; pprint(c.code)
[(SetLineno, 2),
 (LOAD_FAST, 'a'),
 (LOAD_FAST, 'b'),
 (BUILD_TUPLE, 2),
 (PRINT_ITEM, None),
 (PRINT_NEWLINE, None),
 (LOAD_CONST, None),
 (RETURN_VALUE, None)]

We can change the bytecode easily, and see what happens:

>>> c.code[3:3] = [(ROT_TWO, None)]
>>> f.func_code = c.to_code()
>>> f(3, 5)
(5, 3)

The idea is basically the same as that of Michael Hudson's
bytecodehacks, but this one works with Python 2.4 and 2.5. I also
think that it's simpler to use. I borrowed some code from Phillip J.
Eby's peak.util.assembler - the main difference between his package
and mine is that mine lets you play with existing bytecode, not only
create new code objects.

I learned a lot about Python's bytecode from writing this, and I think
that other may learn from it as well - I think it's much easier to
understand how code objects work by understanding equivalent objects
which were meant to be as simple as possible, instead of as fast as
possible.

I think it got pretty good testing - I patched __import__ so that
after a module is imported, all function objects (found by the gc
module) were disassembled and assembled again. I then managed to get
the complete test suite to pass!

You can download the module from
http://byteplay.googlecode.com/svn/trunk/byteplay.py . I wrote a
documentation (which goes into some length in purpose of explaining
how bytecode works). It's on the wiki:
http://wiki.python.org/moin/ByteplayDoc .

I even thought that it might get to the standard library, because it
seemed to me to be a pretty good documentation of bytecode details,
and because it has a pretty straightforward interface. It also makes
meddling with bytecode much less dangerous - for example, you can see
Raymond's original recipe for binding constants at compile time (I
reposted it at http://python.pastebin.com/768312) and how using
byteplay makes it simple (posted at http://python.pastebin.com/768318
so you can view the diff). But, of course - it's up to you. I will be
entirely satisfied if people simply find it useful.

Have a good day,
Noam
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[A.M. Kuchling]

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.  I plan to work on the bug/patch backlog (try
searching for the Python 2.3 bugs on SF and see how many open bugs
there are).

--amk

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Georg Brandl]

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 released a week
> and a half before.  I plan to work on the bug/patch backlog (try
> searching for the Python 2.3 bugs on SF and see how many open bugs
> there are).

Once we do have a new tracker system, it would be a Good Thing[tm]
to go through all the bugs, patches and RFE, and try to get them
properly categorized: we'd have to

* merge duplicates (also bug + patch duplicates caused by the current
   split trackers)
* assign a realistic priority
* assign a realistic milestone
* flag RFE patches as RFE ("patch" shouldn't be a category on its own)
* try to reproduce if bug is quite old
* close old bugs which can't be reproduced or refer to obscure platforms
* 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?)


Quite a lot of work, but with a fair amount of volunteers it should be
doable and cut the number of open issues to under 1000.

Georg

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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]

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 realized that returning a sub-class of Int and/or Long would not 
be a problem here.  The recursion problem that I was guarding against 
only arose when the possibility of returning any object with an 
.__index__() method was suggested.

Therefore, I think these exact int or exact long checks can and should 
be replaced with PyInt_Check() and PyLong_Check().

-Travis



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred L. Drake, Jr.]

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 a bug report, while I'd rather see them attached to the 
relevant bug report or feature request.

My thought is that it's easier to deal with fewer items in the tracker.  
Keeping the candidate patches with the bug report or feature request makes 
them readily accessible to a reviewer.  It's not the only way.

I can guess at Martin's thinking, but I'd rather let him speak for himself, 
since I'm not a trained channeller.  ;-)


  -Fred

-- 
Fred L. Drake, Jr.   
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Type of range object members

[Alexander Belopolsky]

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 in rangeobject.c is already Py_ssize_t
aware (see range_item and range_length), but it assumes that it is
safe to cast long to ssize_t and back.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Guido van Rossum]

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
> 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 in rangeobject.c is already Py_ssize_t
> aware (see range_item and range_length), but it assumes that it is
> safe to cast long to ssize_t and back.
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>


-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[A.M. Kuchling]

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 Raymond) has argued that we shouldn't
close old bug reports because even if no one is interested in
processing them *now*, someone might come along someday who wants to
update that module and fix those bugs or apply those enhancements.

Perhaps we need a 'not dead, not actively pursued' state for patches
and RFEs.  

--amk

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Nick Coghlan]

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 the past, someone (I think Raymond) has argued that we shouldn't
> close old bug reports because even if no one is interested in
> processing them *now*, someone might come along someday who wants to
> update that module and fix those bugs or apply those enhancements.
> 
> Perhaps we need a 'not dead, not actively pursued' state for patches
> and RFEs.  

Open with priority 0?

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Nick Coghlan]

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 artifacts rather than 
> as attachments to a bug report, while I'd rather see them attached to the 
> relevant bug report or feature request.
> 
> My thought is that it's easier to deal with fewer items in the tracker.  
> Keeping the candidate patches with the bug report or feature request makes 
> them readily accessible to a reviewer.  It's not the only way.

I'd rather see this as a "has patch" flag, similar to "is RFE", rather than 
completely separate trackers. A patch will be aimed at addressing either an 
RFE or a bug fix - so long as people can filter out the tracker items with 
patches attached to find things to review, it makes sense to me to keep the 
patch with the tracker item it addresses.

Another useful categorization would be "what skills are needed to address this 
item" - Python coding, C coding or documentation writing (although this is 
covered to some degree by the existing categories, it may not always be 
obvious).

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Nick Coghlan]

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 Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Alexander Belopolsky]

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 object's  
"start" is logically  an index, but int object's "ob_ival" is not.
Since PyIntObject's is definition is exposed by Python.h, changing  
the type of ob_ival will probably break a lot of code.  This  
reasoning does not apply to the range object.

Since on most platforms ssize_t is the same as long, the choice  
between the two is just a matter of self-documenting code.  Speaking  
of which, I find it unfortunate that the name Py_ssize_t was selected  
for the typedef.  I would prefer Py_index_t.  The first time I saw  
Py_ssize_t, I did not notice the double 's' and thought it was an  
unsigned type.  On the second look, I've realized that it is signed  
and started wondering why not ptrdiff_t.  I understand that ssize_t  
is defined by POSIX as the return type of functions such as "read"  
that can return either size or -1 for error.  I don't think POSIX  
mandates sizeof(size_t) == sizeof(ssize_t), but I may be wrong.   I  
would agree that ptrdiff_t, although standard C, is not a very  
intuitive name, but ssize_t is even less clear. 
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Guido van Rossum]

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, sorry.

> I don't understand
> why the type used by PyIntObject is relevant here.

Because the only way to create one (in 2.5 or before) is by passing it
a Python int.

> Range object's
> "start" is logically  an index, but int object's "ob_ival" is not.
> Since PyIntObject's is definition is exposed by Python.h, changing
> the type of ob_ival will probably break a lot of code.  This
> reasoning does not apply to the range object.

But since the start and end come from a Python int, what advantage
would it have to use Py_ssize_t instead? We know sizeof(long) <=
sizeof(Py_ssize_t).

> Since on most platforms ssize_t is the same as long, the choice
> between the two is just a matter of self-documenting code.  Speaking
> of which, I find it unfortunate that the name Py_ssize_t was selected
> for the typedef.  I would prefer Py_index_t.  The first time I saw
> Py_ssize_t, I did not notice the double 's' and thought it was an
> unsigned type.

Blame the C standards committee -- they introduced ssize_t in C99.

> On the second look, I've realized that it is signed
> and started wondering why not ptrdiff_t.

Because it is not used for the difference of pointers?

Frankly, you're about 6 months too late with naming concerns. It's not
going to change now. The PEP has been discussed and the code reviewed
ad infinitum. We're only looking for bugs now, and so far the issue
you've brought up decidedly falls in the category "non-bug".

> I understand that ssize_t
> is defined by POSIX as the return type of functions such as "read"
> that can return either size or -1 for error.  I don't think POSIX
> mandates sizeof(size_t) == sizeof(ssize_t), but I may be wrong.   I
> would agree that ptrdiff_t, although standard C, is not a very
> intuitive name, but ssize_t is even less clear.

Water under the bridge.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Alexander Belopolsky]

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 advantage
> would it have to use Py_ssize_t instead? We know sizeof(long) <=
> sizeof(Py_ssize_t).

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 use PyInt_FromSsize_t .


>
> Blame the C standards committee -- they introduced ssize_t in C99.

I've checked in the Wiley's 2003 edition of "The C Standard" and it  
does not have ssize_t .  I could not find anything suggesting that it  
is in the C standard on google either.  Are you sure it is in C99?


>
>> On the second look, I've realized that it is signed
>> and started wondering why not ptrdiff_t.
>
> Because it is not used for the difference of pointers?

After being exposed to C++, ptrdiff_t (or more generally  
difference_type) is what I expect as an argument of a [] operator  
that allows negative indices (such as operator[] of C++ iterators).

>
> Frankly, you're about 6 months too late with naming concerns.

I know :-(  I'll shut up now.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Guido van Rossum]

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))
> xrange(2)

But a long with a value larger than sys.maxint is never accepted right?

> > But since the start and end come from a Python int, what advantage
> > would it have to use Py_ssize_t instead? We know sizeof(long) <=
> > sizeof(Py_ssize_t).
>
> 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 use PyInt_FromSsize_t .

Feel free to submit a patch for Python 2.6. I expect the 2.5 release
managers to reject this on the basis of being a new feature.

> > Blame the C standards committee -- they introduced ssize_t in C99.
>
> I've checked in the Wiley's 2003 edition of "The C Standard" and it
> does not have ssize_t .  I could not find anything suggesting that it
> is in the C standard on google either.  Are you sure it is in C99?

To be honest I have no idea how/why Martin or Tim picked this name.
Perhaps it is in POSIX? I doubt they made it up; ssize_t is used all
over the standard headers in the 4-year-old Linux distro (Red Hat 7.3)
running on my ancient home desktop.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] no remaining issues blocking 2.5 release

[Neal Norwitz]

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 more days before
code freeze.  A branch will be made when the release candidate is cut.

n
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Anthony Baxter]

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 use PyInt_FromSsize_t .
>
> Feel free to submit a patch for Python 2.6. I expect the 2.5 release
> managers to reject this on the basis of being a new feature.

Absolutely correct. At this point in the release process, there's going to be 
a massive resistance to changes.


Anthony

-- 
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Anthony Baxter]

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 is planned to
> be cut this Thursday/Friday.  There are only a few more days before
> code freeze.  A branch will be made when the release candidate is cut.

More information here: I plan to branch release25-maint on Thursday morning, 
as the first step in the release process for 2.5c1. This will be done after 
the repository is updated to identify itself as '2.5c1'. Once this is done, I 
plan on doing all further 2.5 releases from the release25-maint branch. I 
will no longer care about the trunk's stability :-) 

Anthony
-- 
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fredrik Lundh]

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



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com