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
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
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:
> 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]
> 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
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
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
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
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
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
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
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
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
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
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:
> 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
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
http://mail.python.
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
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 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
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
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, 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,
> >>
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 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
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 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
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
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
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
> 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
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
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
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
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
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
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
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
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:
> 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.
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
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
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
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
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
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
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
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
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
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
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
51 matches
Mail list logo
