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 o
Alexander Belopolsky wrote:
> Since on most platforms ssize_t is the same as long, the choice
> between the two is just a matter of self-documenting code.
No, it would be an actual change: on Win64,
sizeof(Py_ssize_t)>sizeof(long).
> Speaking
> of which, I find it unfortunate that the name Py
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 wor
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
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
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 Th
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 Thur
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=detail&aid=1540617&group_id=5470&atid=305470
> Perhaps it is in POSIX?
Yes, "ssize_t - Used for a count of bytes or an error indicat
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 a version number a
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 replac
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 purp
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 2.4.
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 i
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?
R
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 i
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 Pyt
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 you
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
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 tr
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
> ver
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 IDLE
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 tw
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 plat
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 u
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 platfo
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
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,
> >>
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
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 talki
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? Actua
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
[email protected]
http://mail.python.
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
Python
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 t
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.
S
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. O
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
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:
>>
>> pytho
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 s
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 la
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 tra
[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
Greg Ewing schrieb:
> 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?
It's what Guido proposes.
It would still leave two types (perhaps three) at the C level,
so
Greg Ewing schrieb:
> 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?
Hardly. The efficiency of the special-case allocator al
Greg Ewing schrieb:
>> There isn't? Actually a lot of APIs currently assumen that.
>
> Also it means you'd pay a penalty every time you
> access it, whereas presumably short ints are the
> case we want to optimise for speed as well.
That penalty is already paid today. Much code dealing with
ints
On 8/15/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
That penalty is already paid today. Much code dealing with
ints has a type test whether it's an int or a long. If
int and long become subtypes of each other or of some abstract
type, performance will decrease even more because a subtype
te
51 matches
Mail list logo
