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
/F
___
Alexander Belopolsky 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?
Fred L. Drake, Jr. wrote:
I can guess at Martin's thinking, but I'd rather let him speak for himself,
since I'm not a trained channeller. ;-)
Essentially, I want to give patches more attention, since they are
larger contributions. I don't care if bug reports get unnoticed for
years; I do
Martin v. Löwis wrote:
Fred L. Drake, Jr. wrote:
I can guess at Martin's thinking, but I'd rather let him speak for himself,
since I'm not a trained channeller. ;-)
Essentially, I want to give patches more attention, since they are
larger contributions. I don't care if bug reports get
Georg Brandl wrote:
I can guess at Martin's thinking, but I'd rather let him speak for himself,
since I'm not a trained channeller. ;-)
Essentially, I want to give patches more attention, since they are
larger contributions. I don't care if bug reports get unnoticed for
years; I do worry if
Neal Norwitz schrieb:
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
On Aug 15, 2006, at 12:14 AM, Guido van Rossum wrote:
Feel free to submit a patch for Python 2.6.
Please see http://sourceforge.net/tracker/index.php?
func=detailaid=1540617group_id=5470atid=305470
Perhaps it is in POSIX?
Yes, ssize_t - Used for a count of bytes or an error indication.,
FWIW, I propose that in py3k, the int type uses Py_ssize_t instead of long.
Already decided is that in py3k, the (x)range object will support
arbitrary integer sizes, so that e.g. range(10**10, 10**10+10) is
valid (it currently is, but for different reasons, it isn't with
xrange, which will
Guido van Rossum wrote:
On 8/15/06, M.-A. Lemburg [EMAIL PROTECTED] wrote:
The distutils version number should be changed back to a static
string literal.
It's currently setup to get its version number
from the Python version running it which pretty much defeats
the whole purpose of having
Guido van Rossum schrieb:
I am sympathetic to this case. Is there any advantage to the *users*
of distutils of the dynamic version number?
This series of commits was triggered by a user who wondered why
Python 2.4.3 ships with distutils 2.4.1, yet Python 2.5bsomething
ships with the older
Alexander Belopolsky schrieb:
Another reason is that POSIX interprets negative values of ssize_t as
an error indication, not as an offset from the end. A better POSIX
analogy would be off_t (as used in lseek).
That's subtle. By this reasoning, ptrdiff_t would be wrong, as well,
since it
Guido van Rossum schrieb:
FWIW, I propose that in py3k, the int type uses Py_ssize_t instead of long.
This is really a py3k issue, but: shouldn't the int and long types
really get unified into a single type in Py3k?
I suppose the i parameter to PyArg_ParseTuple would continue to parse
int?
M.-A. Lemburg schrieb:
I find it important to maintain distutils compatibility with
a few Python versions back. Even if I can't volunteer to
maintain distutils, like Martin suggested, due to lack of time,
I don't really see the requirement to use the latest and greatest
Python features in
Martin v. Löwis wrote:
Guido van Rossum schrieb:
I think it must be rolled back, at least as long as
distutils is officially listed as a package that needs to support
older versions of Python, which pretty much implies that it's okay to
extract it from the 2.5 release and distribute it
On 8/15/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
Guido van Rossum schrieb:
FWIW, I propose that in py3k, the int type uses Py_ssize_t instead of long.
This is really a py3k issue, but: shouldn't the int and long types
really get unified into a single type in Py3k?
From the Python
Marc-Andre,
I think the release managers might let you change this back if you
volunteered, not to maintain all of distutils (I wouldn't wish that on
my worst enemies :-) but at least to keep the version number up to
date and to do the occasional work to keep it backwards compatible in
the way
Martin v. Löwis wrote:
M.-A. Lemburg schrieb:
I find it important to maintain distutils compatibility with
a few Python versions back. Even if I can't volunteer to
maintain distutils, like Martin suggested, due to lack of time,
I don't really see the requirement to use the latest and greatest
Guido van Rossum wrote:
Marc-Andre,
I think the release managers might let you change this back if you
volunteered, not to maintain all of distutils (I wouldn't wish that on
my worst enemies :-) but at least to keep the version number up to
date and to do the occasional work to keep it
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.
I'd like to see problem #1531862 fixed. The bug is clear and the
fix should be
Fredrik Lundh wrote:
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.
I just uploaded a series of IDLE patches, but I'm not quite sure how
to classify them on the feature/bugfix scale now that the last beta is
out.
From most to least buggish:
python.org/sf/1540892 -- honor the new quit() behavior. On the other
hand, it was documented that this didn't work in
Guido van Rossum schrieb:
From the Python *user*'s perspective, yes, as much as possible. But
I'm still playing with the thought of having two implementation types,
since otherwise we'd have to devote 4 bytes (8 on a 64-bit platform)
to the single *bit* telling the difference between the two
On 8/15/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
Guido van Rossum schrieb:
From the Python *user*'s perspective, yes, as much as possible. But
I'm still playing with the thought of having two implementation types,
since otherwise we'd have to devote 4 bytes (8 on a 64-bit platform)
to
M.-A. Lemburg schrieb:
It's either an official feature, with somebody maintaining it,
or people should expect to break it anytime.
I'll let you know when things break - is that good enough ?
That can't be an official policy; you seem to define breaks
as breaks in my (your) personal usage of
On Aug 15, 2006, at 6:20 PM, Martin v. Löwis wrote:
Guido van Rossum schrieb:
From the Python *user*'s perspective, yes, as much as possible. But
I'm still playing with the thought of having two implementation
types,
since otherwise we'd have to devote 4 bytes (8 on a 64-bit platform)
to
Martin v. Löwis wrote:
M.-A. Lemburg schrieb:
It's either an official feature, with somebody maintaining it,
or people should expect to break it anytime.
I'll let you know when things break - is that good enough ?
That can't be an official policy; you seem to define breaks
as breaks in my
On 8/15/06, James Y Knight [EMAIL PROTECTED] wrote:
On Aug 15, 2006, at 6:20 PM, Martin v. Löwis wrote:
Guido van Rossum schrieb:
From the Python *user*'s perspective, yes, as much as possible. But
I'm still playing with the thought of having two implementation
types,
since otherwise
James Y Knight schrieb:
But it's the short int that you probably really want to make size
efficient.
Only if you have many of them. And if you do, you have the problem
of the special-cased allocator: when the many ints go away, Python
will hold onto their memory forever.
Regards,
Martin
On 8/15/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
James Y Knight schrieb:
But it's the short int that you probably really want to make size
efficient.
Only if you have many of them. And if you do, you have the problem
of the special-cased allocator: when the many ints go away, Python
On Aug 15, 2006, at 7:06 PM, Guido van Rossum wrote:
There's no particular reason that a short int must be able to store
the entire range of C long, so, as many bits can be stolen from it
as desired.
There isn't? Actually a lot of APIs currently assumen that.
I thought we were talking about
Neal Norwitz [EMAIL PROTECTED] wrote:
I don't know of any. I haven't heard of any issues with the fixes
that have been checked in.
It would be nice if someone could bytecompile Lib using
Tools/compiler/compile.py and then run the test suite. I'd do it
myself but can't spare the time at the
On 8/15/06, James Y Knight [EMAIL PROTECTED] wrote:
On Aug 15, 2006, at 7:06 PM, Guido van Rossum wrote:
There's no particular reason that a short int must be able to store
the entire range of C long, so, as many bits can be stolen from it
as desired.
There isn't? Actually a lot of APIs
Martin v. Löwis wrote:
We had this discussion before; if you use ob_size==0 to indicate
that it's an int, this space isn't needed in a long int.
What about int subclasses?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
Guido van Rossum wrote:
I worry that dropping the special allocator will be too slow.
Surely there's some compromise that would allow
recently-used ints to be kept around, but reclaimed
if memory becomes low?
--
Greg
___
Python-Dev mailing list
I really don't care any more about this. My initial concern (and why I
requested the change) was that there are no more official separate distutils
releases. I don't see how keeping a bunch of version numbers in the stdlib
that just track the main version number is a sane use of developer time
Guido van Rossum wrote:
On 8/15/06, James Y Knight [EMAIL PROTECTED] wrote:
There's no particular reason that a short int must be able to store
the entire range of C long, so, as many bits can be stolen from it
as desired.
There isn't? Actually a lot of APIs currently assumen that.
Also it
On Tuesday 15 August 2006 22:57, Thomas Heller wrote:
What is the policy for documentation changes? Am I allowed to check in
changes/additions to the ctypes docs without release manager permission
after the release candidate is out? I'l always make sure that the html
docs can be built.
So
On Wednesday 16 August 2006 06:19, Jim Jewett wrote:
I just uploaded a series of IDLE patches, but I'm not quite sure how
to classify them on the feature/bugfix scale now that the last beta is
out.
From most to least buggish:
python.org/sf/1540892 -- honor the new quit() behavior. On the
Ok, here we go... I'm declaring the TRUNK FROZEN as of 00:00 UTC on Thursday
the 17th of August. This is in about 22 hours time. At this time, I'll be
cutting the release25-maint branch and 2.5c1 (and all future 2.5 releases)
will be from that branch. I'll send another email once the release is
Anthony Baxter [EMAIL PROTECTED] writes:
I'd also like to see idle's separate version number go away and have
it start using the Python version number - maybe as of 2.6?
+1
When we merged IDLEfork the consensus was to keep the versioning
separate. But it seems confusing and is extra work for
Anthony Baxter [EMAIL PROTECTED] writes:
On Wednesday 16 August 2006 06:19, Jim Jewett wrote:
I just uploaded a series of IDLE patches, but I'm not quite sure how
to classify them on the feature/bugfix scale now that the last beta is
out.
From most to least buggish:
python.org/sf/1540892
Martin v. Löwis wrote:
M.-A. Lemburg schrieb:
Python just doesn't know the encoding of the 8-bit string, so can't
make any assumptions on it. As result, it raises an exception to inform
the programmer.
Oh, Python does make an assumption what the encoding is: it assumes
it is the system
On 04/08/06, Ka-Ping Yee [EMAIL PROTECTED] wrote:
On Thu, 3 Aug 2006, Oren Tirosh wrote:
The UUID module uses network byte order, regardless of the platform
byte order. On little-endian platforms like Windows the .bytes
property of UUID objects is not compatible with the memory layout
RFC
Back in June, the Python Software Foundation's Infrastructure Committee asked for help in the search for a new issue tracker to replace SourceForge (see http://wiki.python.org/moin/CallForTrackers
for details). We asked people who wished to help with the search to install their favourite issue
[Greg Ewing]
Surely there's some compromise that would allow
recently-used ints to be kept around, but reclaimed
if memory becomes low?
Not without losing /something/ we currently enjoy. The current int
scheme has theoretically optimal memory use too, consuming 12 bytes
per int object on a
45 matches
Mail list logo
