[Python-Dev] [OT] Re: Top-posting on this list
On Sun, 11 Oct 2009 03:26:41 pm Stephen J. Turnbull wrote: > Indeed, and that's why I thanked Michael. Trimming can be a PITA if > you're using a crummy MUA, and for reasons I have no intention of > even trying to remember, let alone understand, a lot of people are > very attached to their crummmy MUAs. Perhaps I've never used a sufficiently crummy MUA, but I don't get this. Particularly for GUI apps on a PC, trimming just means: select text, press delete, repeat until done. How hard can it be? Surely even the crummiest MUA lets you delete text? This might be hard on a PDA or mobile phone, but on a PC with a keyboard and mouse? (I have a vague recollection that Lotus Notes inserts the quoted message *after* you've done editing your reply, so Notes users should be forgiven. Not to mention pitied.) -- Steven D'Aprano ___ 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] Top-posting on this list
"Stephen J. Turnbull" writes: > Trimming can be a PITA if you're using a crummy MUA How so? It merely requires the ability to navigate up and down by lines, and to select and delete text. I've used some very crummy MUAs, but the ability to trim quoted text has never been absent or difficult. Are there MUAs so crummy that this is a PITA, yet still used by any significant portion of email users? -- \“Simplicity is prerequisite for reliability.” —Edsger W. | `\ Dijkstra | _o__) | Ben Finney ___ 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] Top-posting on this list
Fred Drake writes: > Most importantly, insufficient trimming makes many of us start to > ignore threads we'd otherwise want to read more carefully or > participate in, because the tedium of wading through all the quotes to > make sure we catch all the content. Absolutely. This is a significant reason to publicly, and frequently, respond to request inline-replied, suitably-trimmed messages: to help newcomers reading the list understand what constitutes an easy-to-read message, and to maximise their opportunity to write messages that won't simply be skipped as too much effort to read. -- \ “The WWW is exciting because Microsoft doesn't own it, and | `\ therefore, there's a tremendous amount of innovation | _o__) happening.” —Steve Jobs | Ben Finney ___ 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] Top-posting on this list
Greg Ewing canterbury.ac.nz> writes: > > That's no reason to squander it, though. Quoting the entire > message every time makes the size of the thread grow as > O(n**2), and makes things harder to read as well. That's > just senseless. +1. It's always annoying to skim through a three-page quoted message just to read a two-line reply. The problem is not electronic bandwidth, but visual bandwidth. Regards Antoine. ___ 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] Top-posting on this list
On Sun, Oct 11, 2009 at 1:26 PM, Ben Finney wrote: > "Stephen J. Turnbull" writes: > >> Trimming can be a PITA if you're using a crummy MUA > > How so? It merely requires the ability to navigate up and down by lines, > and to select and delete text. I've used some very crummy MUAs, but the > ability to trim quoted text has never been absent or difficult. Are > there MUAs so crummy that this is a PITA, yet still used by any > significant portion of email users? You just can't do it on some mobile device mail clients. For instance Gmail's client on Android. It will just top-post and quote the whole mail for you AFAIK. Tarek ___ 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] Top-posting on this list
Tarek Ziadé writes: > You just can't do it on some mobile device mail clients. For instance > Gmail's client on Android. > It will just top-post and quote the whole mail for you AFAIK. Wow, that *is* crummy. Perhaps a posse of users of that application can loudly request this basic feature from the vendor, to at least make it easy to avoid sending obnoxious messages. -- \“Ice water? Get some onions — that'll make your eyes water!” | `\ —Groucho Marx | _o__) | Ben Finney ___ 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] Top-posting on this list
On 11 Oct 2009, at 13:36 , Tarek Ziadé wrote: On Sun, Oct 11, 2009 at 1:26 PM, Ben Finney > wrote: "Stephen J. Turnbull" writes: Trimming can be a PITA if you're using a crummy MUA How so? It merely requires the ability to navigate up and down by lines, and to select and delete text. I've used some very crummy MUAs, but the ability to trim quoted text has never been absent or difficult. Are there MUAs so crummy that this is a PITA, yet still used by any significant portion of email users? You just can't do it on some mobile device mail clients. For instance Gmail's client on Android. It will just top-post and quote the whole mail for you AFAIK. I'll add the iPhone pre 3.0 Mail (also holds for the Touch): while trimming was possible, it was done using the delete key and character per character (jumping to word per word after a few seconds) because there was no selection. This made trimming long mails a fairly long-winded task already, but things were even worse due to the lack of undo: not stopping soon enough (and deleting part of the text you wanted to quote) meant you had to either re-type it manually or restart the whole operation from the start. This has thankfully been fixed (with the addition of a pretty good selection mechanism and an undo). Another iPhone mail "feature", (which hasn't been fixed and is actually just as broken in the desktop version of Mail) is that Mail is hardcoded to top-post: it's not possible to make the insertion point default to bottom the quote, it's always above it with a bunch of white-spaces for the message. Not much of an issue, but it still makes top-posting lower friction than bottom-posting or trimming. ___ 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] PEP about sys.implementation and implementation specific user site directory
Nick Coghlan wrote: > M.-A. Lemburg wrote: >> Benjamin Peterson wrote: >>> I forgot to ask before: Does this deprecate >>> platform.python_implementation()? >> >> No, platform.py is meant to be portable across multiple Python >> versions and as such not really suitable for such deprecations. >> >> It'll also take a long while before all Python implementations >> expose a new sys module attribute along the proposed lines. > > However, the function could be updated to take advantage of the new > sys.implementation attribute when it was available. If it didn't find > it, it would fallback to figuring out the way it does now. Sure. It already does that for a couple of other APIs. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 11 2009) >>> 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 our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ 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] Weak dict iterators are fragile
Hello,
In py3k, the weak dict methods keys(), values() and items() have been
changed to return iterators (they returned lists in 2.x).
However, it turns out that it makes these methods quite fragile, because
a GC collection can occur whenever during iterating, destroy one of the
weakref'ed objects, and trigger a resizing of the underlying dict, which
in turn raises an exception ("RuntimeError: dictionary changed size
during iteration").
This has just triggered (assuming the diagnosis is correct) a hang in
test_multiprocessing: http://bugs.python.org/issue7060
I would like to propose some possible solutions against this:
1. Add the safe methods listkeys(), listitems(), listvalues() which would
behave as the keys(), etc. methods from 2.x
2. Make it so that keys(), items(), values() atomically build a list of
items internally, which makes them more costly for large weak dicts, but
robust.
What do you think?
Regards
Antoine.
___
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] Top-posting on this list
Masklinn wrote: On 11 Oct 2009, at 13:36 , Tarek Ziadé wrote: On Sun, Oct 11, 2009 at 1:26 PM, Ben Finney wrote: "Stephen J. Turnbull" writes: Trimming can be a PITA if you're using a crummy MUA How so? It merely requires the ability to navigate up and down by lines, and to select and delete text. I've used some very crummy MUAs, but the ability to trim quoted text has never been absent or difficult. Are there MUAs so crummy that this is a PITA, yet still used by any significant portion of email users? You just can't do it on some mobile device mail clients. For instance Gmail's client on Android. It will just top-post and quote the whole mail for you AFAIK. I'll add the iPhone pre 3.0 Mail (also holds for the Touch): while trimming was possible, it was done using the delete key and character per character (jumping to word per word after a few seconds) because there was no selection. This made trimming long mails a fairly long-winded task already, but things were even worse due to the lack of undo: not stopping soon enough (and deleting part of the text you wanted to quote) meant you had to either re-type it manually or restart the whole operation from the start. This has thankfully been fixed (with the addition of a pretty good selection mechanism and an undo). Another iPhone mail "feature", (which hasn't been fixed and is actually just as broken in the desktop version of Mail) is that Mail is hardcoded to top-post: it's not possible to make the insertion point default to bottom the quote, it's always above it with a bunch of white-spaces for the message. Not much of an issue, but it still makes top-posting lower friction than bottom-posting or trimming. Didn't the iPhone also lack cut-and-paste? ___ 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] Top-posting on this list
MRAB mrabarnett.plus.com> writes: > [snipped three pages of quoted messages before a one-liner] > Didn't the iPhone also lack cut-and-paste? Not to sound harsh, but your quoting was a perfect example of wasted visual bandwidth... (are you posting from an iPhone ? ;-)) Antoine. ___ 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] Weak dict iterators are fragile
On Sun, Oct 11, 2009 at 10:50 AM, Antoine Pitrou wrote:
> In py3k, the weak dict methods keys(), values() and items() have been
> changed to return iterators (they returned lists in 2.x).
> However, it turns out that it makes these methods quite fragile, because
> a GC collection can occur whenever during iterating, destroy one of the
> weakref'ed objects, and trigger a resizing of the underlying dict, which
> in turn raises an exception ("RuntimeError: dictionary changed size
> during iteration").
>
Ouch!
The iterator from __iter__ is also affected.
1. Add the safe methods listkeys(), listitems(), listvalues() which would
> behave as the keys(), etc. methods from 2.x
>
> 2. Make it so that keys(), items(), values() atomically build a list of
> items internally, which makes them more costly for large weak dicts, but
> robust.
>
-1 on 1.
+0 on 2.
It'd be nice if we could postpone the resize if there are active iterators,
but I don't think there's a clean way to track the iterators.
--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC
___
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] Weak dict iterators are fragile
Antoine Pitrou pitrou.net> writes: > > 1. Add the safe methods listkeys(), listitems(), listvalues() which would > behave as the keys(), etc. methods from 2.x > > 2. Make it so that keys(), items(), values() atomically build a list of > items internally, which makes them more costly for large weak dicts, but > robust. And a third one (a bit more complicated implementation-wise): 3. Delay weak dict removals until any iteration has finished. Regards Antoine. ___ 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] Top-posting on this list
On 11 Oct 2009, at 18:07 , MRAB wrote: Didn't the iPhone also lack cut-and-paste? It did, but given text selection is a near-mandatory requirement to cutting text (and pasting isn't very useful if you can't put anything into the clipboard) those were implied consequences of the lack of selection. ___ 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] Weak dict iterators are fragile
Daniel Stutzbach stutzbachenterprises.com> writes: > > -1 on 1.+0 on 2.It'd be nice if we could postpone the resize if there are active iterators, but I don't think there's a clean way to track the iterators. I've started experimenting, and it seems reasonably possible using a simple guard class and a set of weakrefs. Regards Antoine. ___ 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] Top-posting on this list
Ben Finney writes: > "Stephen J. Turnbull" writes: > > > Trimming can be a PITA if you're using a crummy MUA > > How so? It merely requires the ability to navigate up and down by lines, > and to select and delete text. I've used some very crummy MUAs, but the > ability to trim quoted text has never been absent or difficult. Not difficult, time-consuming. It can take many seconds to scroll to bottom in a 200-line quote with gmail and the webmail system used by the University of California at Santa Cruz. You bet I get down on my knees and give thanks that my other MUA is an Emacs every time I have to use webmail. Please note that I'm not defending the practice of top-posting; I'm trying to understand why anybody would do it, and address the readability issue in that context. A sentinel that says "the next 500 lines are whatever happened to be in the tail of the 16KiB block on the file system" does help. If others are willing to play bad cop, as Aahz did, I'd be very happy to accept the benefit of a cleaned-up list. But I'm not willing to do it myself. ___ 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] Distutils and Distribute roadmap (and some words on Virtualenv, Pip)
2009/10/9 Michael Foord : > Many Windows users would be quite happy if the standard mechanism for > installing non-source distributions on Windows was via the wininst binaries. +1 I'm one of those people. > I wonder if it is going to be possible to make this compatible with the > upcoming distutils package management 'stuff' (querying for installed > packages, uninstallation etc) since installation/uninstallation goes through > the Windows system package management feature. I guess it would be > eminently possible but require some reasonably high level Windows-fu to do. I am working with Tarek to keep Windows issues (and in particular this one) on the agenda. It's quite hard at times, as getting a representative sample of Windows users' preferences/requirements is difficult at best (Windows users seem as a group to be either very quiet, or very easy to please. I'm an exception :-)) If any Windows users want to speak up and help, that would be immensely useful! (And please, identify yourself as such - it's often hard to determine who knows Windows, and who is a Unix user making assumptions or best guesses). Paul. ___ 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] Top-posting on this list
On Sun, Oct 11, 2009 at 12:38 PM, Stephen J. Turnbull wrote: > If others are willing to play bad cop, as Aahz did, I'd be very happy > to accept the benefit of a cleaned-up list. But I'm not willing to do > it myself. Is it really that big of an issue that we have to discuss it ad-infinitum and potentially have a quoting cop? Sometimes top-posting happens. Sometimes people don't trim messages. Sometimes people argue about the color of a shed. jesse ___ 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] Distutils and Distribute roadmap (and some words on Virtualenv, Pip)
On Sun, Oct 11, 2009 at 9:52 AM, Paul Moore wrote: > 2009/10/9 Michael Foord : >> Many Windows users would be quite happy if the standard mechanism for >> installing non-source distributions on Windows was via the wininst binaries. > > +1 I'm one of those people. +1 on installing packages on Windows through the native package manager (Add/Remove Programs). > I am working with Tarek to keep Windows issues (and in particular this > one) on the agenda. It's quite hard at times, as getting a > representative sample of Windows users' preferences/requirements is > difficult at best (Windows users seem as a group to be either very > quiet, or very easy to please. I'm an exception :-)) > > If any Windows users want to speak up and help, that would be > immensely useful! (And please, identify yourself as such - it's often > hard to determine who knows Windows, and who is a Unix user making > assumptions or best guesses). I'm a Windows user, and I've also spent a fair bit of time improving Python's bdist_msi support exactly so that we have better support for Windows native package management. However, I don't have enough time to keep up with the massive package management threads. If you want to CC me occasionally to get my feedback on a particular comment though, I'd be happy to speak up. Steve -- Where did you get that preposterous hypothesis? Did Steve tell you that? --- The Hiphopopotamus ___ 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] Weak dict iterators are fragile
Antoine Pitrou pitrou.net> writes: > > Daniel Stutzbach stutzbachenterprises.com> writes: > > > > -1 on 1.+0 on 2.It'd be nice if we could postpone the resize if there are > active iterators, but I don't think there's a clean way to track the > iterators. > > I've started experimenting, and it seems reasonably possible using a simple > guard class and a set of weakrefs. Open issue and proposed patch at http://bugs.python.org/issue7105 Antoine. ___ 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] Top-posting on this list
2009/10/11 Jesse Noller : > On Sun, Oct 11, 2009 at 12:38 PM, Stephen J. Turnbull > wrote: > >> If others are willing to play bad cop, as Aahz did, I'd be very happy >> to accept the benefit of a cleaned-up list. But I'm not willing to do >> it myself. > > Is it really that big of an issue that we have to discuss it > ad-infinitum and potentially have a quoting cop? Sometimes top-posting > happens. Sometimes people don't trim messages. Sometimes people argue > about the color of a shed. +1 This is really getting so meta that it's off topic. -- Regards, Benjamin ___ 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] Top-posting on this list
Benjamin Peterson schrieb: > 2009/10/11 Jesse Noller : >> On Sun, Oct 11, 2009 at 12:38 PM, Stephen J. Turnbull >> wrote: >> >>> If others are willing to play bad cop, as Aahz did, I'd be very happy >>> to accept the benefit of a cleaned-up list. But I'm not willing to do >>> it myself. >> >> Is it really that big of an issue that we have to discuss it >> ad-infinitum and potentially have a quoting cop? Sometimes top-posting >> happens. Sometimes people don't trim messages. Sometimes people argue >> about the color of a shed. > > +1 This is really getting so meta that it's off topic. quoting-SIG anyone? Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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] Backport new float repr to Python 2.7?
In a recent #python-dev IRC conversation, it was suggested that we
should consider backporting the new-style float repr from py3k to
trunk. I'd like to get people's opinions on this idea.
To recap quickly, the algorithm for computing the repr of floats changed
between Python 2.x and Python 3.x (well, actually between 3.0 and 3.1,
but 3.0 is dead):
- in Python 2.x, repr(x) computes 17 significant decimal digits, and
then strips trailing zeros. In other words, it's pretty much identical
to doing '%.17g' % x. The computation is done using the platform's
*printf functions.
- in Python 3.x, repr(x) returns the shortest decimal string that's
guaranteed to evaluate back to the float x under correct rounding.
The computation is done using David Gay's dtoa.c code, adapted
for inclusion in Python (in file Python/dtoa.c).
There are (in my view) many benefits to the new approach. Among
them:
- fewer newbie complaints and questions (on c.l.p, IRC, Stack
Overflow, etc.) about Python 'rounding incorrectly'. Whether this is a
good thing or not is the matter of some debate (I'm tempted to
borrow the time machine and simply say 'see the replies
to this message'!)
- string to float *and* float to string conversions are both guaranteed
correctly rounded in 3.x: David Gay's code implements the conversion
in both directions, and having correctly rounded string -> float
conversions is essential to ensure that eval(repr(x)) recovers x exactly.
- the repr of round(x, n) really does have at most n digits after the
point, giving the semi-illusion that x really has been rounded exactly,
and eliminating one of the most common user complaints about the
round function.
- round(x, n) agrees exactly with '{:.{}f}'.format(x, n) (this isn't
true in Python 2.x, and the difference is a cause of bug reports)
- side effects like finding that float(x) rounds correctly for
Decimal instances x.
- the output from the new rule is more consistent: the 'strip trailing
zeros' part of the old rule has some strange consequences: e.g.,
in 2.x right now (on a typical machine):
>>> 0.02
0.02
>>> 0.03
0.02
even though neither 0.02 nor 0.03 can be exactly represented
in binary. 3.x gives '0.02' and '0.03'.
- repr(x) is consistent across platforms (or at least across platforms
with IEEE 754 doubles; in practice this seems to account for
virtually all platforms currently running Python).
- the float <-> string conversions are under our control, so any bugs
found can be fixed in the Python source. There's no shortage of
conversion bugs in the wild, and certainly bugs have been observed in
OS X, Linux and Windows. (The ones I found in OS X 10.5 have
been fixed in OS X 10.6, though.)
Possible problems:
- breaking docstrings in third party code. Though Eric reminded me
that when we implemented this for 3.1, there were essentially no
standard library test breakages resulting from the changed repr
format.
- some might argue that the new repr (and round) just allows users
to remain ignorant of floating-point difficulties for longer, and that
this is a bad thing. I don't really buy either of these points.
- someone has to put in the work. As mentioned below, I'm happy
to do this (and Eric's offered to help, without which this probably
wouldn't be feasible at all), but it'll use cycles that I could also
usefully be spending elsewhere.
I'm mostly neutral on the backport idea: I'm very happy that this is
in 3.x, but don't see any great need to backport it. But if there's
majority (+BDFL) support, I'm willing to put the work in to do the
backport.
Masochists who are still reading by this point and who want more
information about the new repr implementation can see the issue
discussion:
http://bugs.python.org/issue1580
Thoughts?
Mark
___
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] Backport new float repr to Python 2.7?
[Mark Dickinson]
- string to float *and* float to string conversions are both guaranteed
correctly rounded in 3.x: David Gay's code implements the conversion
in both directions, and having correctly rounded string -> float
conversions is essential to ensure that eval(repr(x)) recovers x exactly.
IMO, that is so important that it should be considered a bug fix.
Recently, I lost a lot of time in a discussion about a piece of mathematical
code returning a wrong answer. The problem wasn't the Python code;
instead, it was the str to float conversion (that we inherit from libc) giving
the wrong answer. The code worked correctly under Py3.1 but not
Py2.6.
IDLE 2.6.2
float('-3477086733292797541405082425691835844169343982673243516316511143182440409957570445312.0009000258695827614150149965556917147323765827915398318737061345018446445465087890625')
-2.e+100
Python 3.1.1 (r311:74483, Aug 17 2009, 17:02:12) [MSC v.1500 32 bit (Intel)] on
win32
Type "copyright", "credits" or "license()" for more information.
float('-3477086733292797541405082425691835844169343982673243516316511143182440409957570445312.0009000258695827614150149965556917147323765827915398318737061345018446445465087890625')
-3.0002e+100
- the repr of round(x, n) really does have at most n digits after the
point, giving the semi-illusion that x really has been rounded exactly,
and eliminating one of the most common user complaints about the
round function.
This is also an important improvement and makes round() do what
people expect.
- side effects like finding that float(x) rounds correctly for
Decimal instances x.
This is also important because other decimal calculations can
often be done exactly and it's a bummer to have an accurate
result thrown off by an incorrect rounding to float.
- the float <-> string conversions are under our control, so any bugs
found can be fixed in the Python source. There's no shortage of
conversion bugs in the wild, and certainly bugs have been observed in
OS X, Linux and Windows. (The ones I found in OS X 10.5 have
been fixed in OS X 10.6, though.)
Nice win.
Thoughts?
+1
I've worked with the 3.1 float reprs for a while and have been delighted.
It was a great improvement.
Raymond
___
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] Backport new float repr to Python 2.7?
On Sun, Oct 11, 2009 at 11:28 AM, Mark Dickinson wrote: > In a recent #python-dev IRC conversation, it was suggested that we > should consider backporting the new-style float repr from py3k to > trunk. I'd like to get people's opinions on this idea. [...] > Possible problems: > > - breaking docstrings in third party code. Though Eric reminded me > that when we implemented this for 3.1, there were essentially no > standard library test breakages resulting from the changed repr > format. I think you mean doctests? These are the primary reason I've always been hesitant to change this in 2.x. > - some might argue that the new repr (and round) just allows users > to remain ignorant of floating-point difficulties for longer, and that > this is a bad thing. I don't really buy either of these points. If we bought that we wouldn't have fixed in 3.x. :-) > - someone has to put in the work. As mentioned below, I'm happy > to do this (and Eric's offered to help, without which this probably > wouldn't be feasible at all), but it'll use cycles that I could also > usefully be spending elsewhere. > > I'm mostly neutral on the backport idea: I'm very happy that this is > in 3.x, but don't see any great need to backport it. But if there's > majority (+BDFL) support, I'm willing to put the work in to do the > backport. I'm -0 -- mostly because of the 3rd party doctests and perhaps also because I'd like 3.x to have some carrots. (I've heard from at least one author who is very happy with 3.x for the next edition of his "programming for beginners" book.) -- --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] http://www.pythonlabs.com/logos.html is gone
Which I noticed since it's cited in the BeOpen license we still refer to in LICENSE. Since pythonlabs.com itself is still up, it probably isn't much work to make the logos.html URI work again, but I don't know who maintains that page. cheer, Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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] Backport new float repr to Python 2.7?
On Sun, Oct 11, 2009 at 3:48 PM, Guido van Rossum wrote: > I'm -0 -- mostly because of the 3rd party doctests and perhaps also > because I'd like 3.x to have some carrots. (I've heard from at least > one author who is very happy with 3.x for the next edition of his > "programming for beginners" book.) > This reasoning definitely makes sense to me; with all the dependency-migration issues 3.x could definitely use some carrots. However, I don't think I agree with it, because this doesn't feel like a big new feature, just some behavior which has changed. The carrots I'm interested in as a user are new possibilties, like new standard library features, a better debugger/profiler, or everybody's favorate bugaboo, multicore parallelism. (Although, to be fair, the removal of old-style classes qualifies.) I'd much rather have my doctests and float-repr'ing code break on 2.7 so I can deal with it as part of a minor-version upgrade than have it break on 3.x and have to deal with this at the same time as the unicode->str explosion. It feels like a backport of this behavior would make the 2->3 transition itself a little easier. ___ 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] http://www.pythonlabs.com/logos.html is gone
On Sun, Oct 11, 2009 at 12:55 PM, Georg Brandl wrote: > Which I noticed since it's cited in the BeOpen license we still refer > to in LICENSE. Since pythonlabs.com itself is still up, it probably > isn't much work to make the logos.html URI work again, but I don't know > who maintains that page. I own the domain. I don't know what was on logos.html and http://web.archive.org won't show it to me because of a robots.txt file. I think it's fine to let it be a 404. -- --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] Backport new float repr to Python 2.7?
Guido van Rossum wrote: On Sun, Oct 11, 2009 at 11:28 AM, Mark Dickinson wrote: In a recent #python-dev IRC conversation, it was suggested that we should consider backporting the new-style float repr from py3k to trunk. I'd like to get people's opinions on this idea. [...] Possible problems: - breaking docstrings in third party code. Though Eric reminded me that when we implemented this for 3.1, there were essentially no standard library test breakages resulting from the changed repr format. I think you mean doctests? These are the primary reason I've always been hesitant to change this in 2.x. I think that doctests inherently unsuited to testing floating point algorithms. Leaving aside the platform differences in actual floating point arithmetic that cause minute real differences in the results, Python 2.x relies on string conversion routines which give different doctest results on different platforms. Using a consistent routine would actually improve the ability to use doctests in that one regard. It certainly would make writing examples much more consistent, particularly for those of us that use infs and nans frequently. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco ___ 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] http://www.pythonlabs.com/logos.html is gone
Guido van Rossum schrieb: > On Sun, Oct 11, 2009 at 12:55 PM, Georg Brandl wrote: >> Which I noticed since it's cited in the BeOpen license we still refer >> to in LICENSE. Since pythonlabs.com itself is still up, it probably >> isn't much work to make the logos.html URI work again, but I don't know >> who maintains that page. > > I own the domain. I don't know what was on logos.html and > http://web.archive.org won't show it to me because of a robots.txt > file. I think it's fine to let it be a 404. Okay. Though I am fairly sure that Tim *would* remember ;) Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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] Distutils and Distribute roadmap (and some words on Virtualenv, Pip)
On Thu, Oct 8, 2009 at 2:56 PM, Paul Moore wrote: > In this context, eggs are "merely" the first (and most important) [..] > example of a format extension, and so should drive the development of > a standard. > > To summarise: > > I believe that we need a statement of direction on the (zipped) egg > format. I see a number of options: > > 1. Retain it as-is in Distribute, but deprecated and no further development. > 2. Deprecate egg support in Distribute, and ultimately drop it. > 3. Develop into a reference example of an extensible architecture for > adding to PEP 376 support. > 4. Extend PEP 376 support to eggs by means of egg-specific approaches > hooking into distutils. [..] > I'm willing to help work on option (3). I think PEP 376 needs first to be finished with only one installation format, without thinking about adding an extensible architecture for various formats. That's what I meant when I said I wanted to reduce its scope. Besides, I think the same site-packages should stick with a single installation format for the distributions it contains. Although, I can picture that a site-packages could be stored in a totally different way, possibly in a database, or with only eggs, but I am still fuzzy about what would this mean for PEP 376, and the stdlib itself. (pkgutil+distutils) And as you said earlier, this could be done later in a second phase, once PEP 376 APIs (that are not directly related to the format, but rather to what people do with installed distributions metadata) are stabilized and proven to work. Tarek ___ 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] Distutils and Distribute roadmap (and some words on Virtualenv, Pip)
On Sun, Oct 11, 2009 at 7:27 PM, Steven Bethard wrote: >> I am working with Tarek to keep Windows issues (and in particular this >> one) on the agenda. It's quite hard at times, as getting a >> representative sample of Windows users' preferences/requirements is >> difficult at best (Windows users seem as a group to be either very >> quiet, or very easy to please. I'm an exception :-)) >> >> If any Windows users want to speak up and help, that would be >> immensely useful! (And please, identify yourself as such - it's often >> hard to determine who knows Windows, and who is a Unix user making >> assumptions or best guesses). > > I'm a Windows user, and I've also spent a fair bit of time improving > Python's bdist_msi support exactly so that we have better support for > Windows native package management. However, I don't have enough time > to keep up with the massive package management threads. If you want to > CC me occasionally to get my feedback on a particular comment though, > I'd be happy to speak up. Thanks for the help guys ! Just to mention, these win32 discussions have now moved back to Distutils-SIG. Tarek ___ 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] Backport new float repr to Python 2.7?
On Sun, Oct 11, 2009 at 13:00, Glyph Lefkowitz wrote: > On Sun, Oct 11, 2009 at 3:48 PM, Guido van Rossum wrote: > > >> I'm -0 -- mostly because of the 3rd party doctests and perhaps also >> because I'd like 3.x to have some carrots. (I've heard from at least >> one author who is very happy with 3.x for the next edition of his >> "programming for beginners" book.) >> > > This reasoning definitely makes sense to me; with all the > dependency-migration issues 3.x could definitely use some carrots. However, > I don't think I agree with it, because this doesn't feel like a big new > feature, just some behavior which has changed. The carrots I'm interested > in as a user are new possibilties, like new standard library features, a > better debugger/profiler, or everybody's favorate bugaboo, multicore > parallelism. (Although, to be fair, the removal of old-style classes > qualifies.) > > Sure, but if people like Mark are having to spend their time backporting every bit of behaviour like this then we won't have the time and energy to add the bigger carrots to 3.x to help entice people to switch. > I'd much rather have my doctests and float-repr'ing code break on 2.7 so I > can deal with it as part of a minor-version upgrade than have it break on > 3.x and have to deal with this at the same time as the unicode->str > explosion. It feels like a backport of this behavior would make the 2->3 > transition itself a little easier. > Maybe, but as Mark pointed out, at least in the test suite for Python, there was no breakage. This will only be an issues if someone does:: >>> x 0.02999 instead of:: >>> x == 0.03 True Plus it should be obvious when a doctest breaks with 0.03 != 0.02999 what has happened. I'm with Guido: -0 on the backport, especially with Mark feeling neutral on wanting to put the effort in. -Brett ___ 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] Backport new float repr to Python 2.7?
On Sun, Oct 11, 2009 at 5:16 PM, Brett Cannon wrote: > On Sun, Oct 11, 2009 at 13:00, Glyph Lefkowitz wrote: > >> The carrots I'm interested in as a user are new possibilties, like new >> standard library features, a better debugger/profiler, or everybody's >> favorate bugaboo, multicore parallelism. (Although, to be fair, the removal >> of old-style classes qualifies.) >> > Sure, but if people like Mark are having to spend their time backporting > every bit of behaviour like this then we won't have the time and energy to > add the bigger carrots to 3.x to help entice people to switch. > Okay, call me +0 then. Not one of the migration issues I'm really sweating about :). ___ 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] Backport new float repr to Python 2.7?
On Sunday 11 October 2009 21:00:41 Glyph Lefkowitz wrote: > with all the > dependency-migration issues 3.x could definitely use some carrots. .. > everybody's favorate bugaboo, multicore parallelism. I know it's the upteen-thousandth time it's been discussed, but removal of the GIL in 3.x would probably be pretty big carrots for some. I know the arguments about performance hits on single core systems etc, and the simplifications it brings, but given every entry level machine these days is multicore, is it time to reconsider some of those points ? Not here perhaps - python-ideas or c.l.p, but if bigger carrots are wanted... Just saying. (As time goes on, lack of a GIL in Ironpython makes it more attractive for multicore work) Not suggesting this happens, but just noting it would probably be a big carrot. Michael. -- http://yeoldeclue.com/blog http://twitter.com/kamaelian http://www.kamaelia.org/Home ___ 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] Backport new float repr to Python 2.7?
2009/10/11 Michael Sparks : > On Sunday 11 October 2009 21:00:41 Glyph Lefkowitz wrote: >> with all the >> dependency-migration issues 3.x could definitely use some carrots. > .. >> everybody's favorate bugaboo, multicore parallelism. > > I know it's the upteen-thousandth time it's been discussed, but > removal of the GIL in 3.x would probably be pretty big carrots for > some. I know the arguments about performance hits on single core > systems etc, and the simplifications it brings, but given every entry > level machine these days is multicore, is it time to reconsider some > of those points ? Not here perhaps - python-ideas or c.l.p, but if > bigger carrots are wanted... Just saying. (As time goes on, lack of a > GIL in Ironpython makes it more attractive for multicore work) Oh, I don't think the problem is that Python-dev is opposed to it in principle, but that someone has yet to submit a patch that doesn't affect single thread preformance and remains compatible with the C-API. -- Regards, Benjamin ___ 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] Backport new float repr to Python 2.7?
Michael Sparks gmail.com> writes: > > I know it's the upteen-thousandth time it's been discussed, but > removal of the GIL in 3.x would probably be pretty big carrots for > some. I know the arguments [...] Not before someone produces a patch anyway. It is certainly not as easy as you seem to think it is. Regards Antoine. ___ 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] Backport new float repr to Python 2.7?
On Sun, Oct 11, 2009 at 10:41 PM, Antoine Pitrou wrote: > Michael Sparks gmail.com> writes: >> >> I know it's the upteen-thousandth time it's been discussed, but >> removal of the GIL in 3.x would probably be pretty big carrots for >> some. I know the arguments [...] > > Not before someone produces a patch anyway. It is certainly not as easy as you > seem to think it is. You misunderstand me I think. I don't think it's easy, based on all the discussion I've seen over the years, and the various attempts that have been made, I think it's a Hard problem. I was just mentioning that if someone wanted a serious carrot, that would probably be it. I'll be quiet about it now though, since I *do* understand how contentious an issue it is. Michael. ___ 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] PEP about sys.implementation and implementation specific user site directory
On Fri, Oct 9, 2009 at 8:42 PM, "Martin v. Löwis" wrote: > I think it is important to confirm in advance that all the > implementations listed below agree to implement the PEP "soonish" after > it's adopted. "Required" sounds like a strong term - however, if an > implementation chooses not to implement the PEP, it can do whatever it > wants, including omission of required fields. Speaking for Jython, so far it looks like something we would adopt soonish after it was accepted (it looks pretty useful to me). > So I propose that the python.org version is identified as "python". I'll add my voice to the group that likes "cpython" and "CPython" as the identifier of the python.org implementation. This version has a long history, and "Classic Python" has a nice sound to it. :) -- also I hope (but won't hold my breath) that Python becomes more associated with the abstract language in time. -Frank ___ 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] PEP about sys.implementation and implementation specific user site directory
On Fri, Oct 9, 2009 at 8:34 PM, "Martin v. Löwis" wrote: > Also, why is it the name of the JIT compiler, and not the name of the > source language compiler? >From the Jython side it is easier to get the VM name compared to the source language compiler. Although there is a property on java.lang.System called "java.compiler" it is often empty. -Frank ___ 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] PEP about sys.implementation and implementation specific user site directory
On Sun, Oct 11, 2009 at 4:31 PM, Frank Wierzbicki wrote: > On Fri, Oct 9, 2009 at 8:42 PM, "Martin v. Löwis" wrote: >> So I propose that the python.org version is identified as "python". > I'll add my voice to the group that likes "cpython" and "CPython" as > the identifier of the python.org implementation. This version has a > long history, and "Classic Python" has a nice sound to it. :) Regardless of the history, "CPython" is indeed how most people refer to this implementation *whenever the distinction matters*, so in a variable used to identify the implementation this makes sense to me, even though most people most of the time don't make this distinction. I'm not worried about other implementations written in C aspiring to the name CPython. > -- also > I hope (but won't hold my breath) that Python becomes more associated > with the abstract language in time. Me too (on both accounts :-). -- --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] Backport new float repr to Python 2.7?
[Glyph Lefkowitz ] > This reasoning definitely makes sense to me; with all the > dependency-migration > issues 3.x could definitely use some carrots. However, I don't think I agree > with it, > because this doesn't feel like a big new feature, just some behavior which > has changed. The carrots/incentives idea also sounds specious to me. First of all, I consider it to be more of a bug fix than a feature -- we've had plenty of bug reports and confusion surrounding the current implementation and at least one of my scripts is broken (occasionally giving wrong answers and the same also is true for decimal.__float__ method being similarly afflicted). Our current dependency on a badly implemented libc strtod() function is not a good thing (and not consistent across various Python builds). Second, as Glyph points out, the change is too small of an improvement to be a real carrot. One quick thought on the doctest issue. If the doctests are being used as originally intended (as part of validating examples in docstrings), then consider that the docstrings themselves would actually be improved with the shorter repr. IMO, it significantly detracts from examples if they are afflicted with floating point repr issues: def average(seq): """ Return the arithmetic mean of a sequence. >>> average([0.1, 0.5]) 0.2 """ return sum(seq) / float(len(seq)) Wouldn't this example be much nicer if it returned 0.3 ? Raymond___ 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] Backport new float repr to Python 2.7?
On Sun, Oct 11, 2009 at 12:44 PM, Raymond Hettinger wrote: > [Mark Dickinson] >> >> - string to float *and* float to string conversions are both guaranteed >> correctly rounded in 3.x: David Gay's code implements the conversion >> in both directions, and having correctly rounded string -> float >> conversions is essential to ensure that eval(repr(x)) recovers x exactly. > > IMO, that is so important that it should be considered a bug fix. It looks like the majority of posters so far is +0 to +1 on this, and I don't want my -0 to stand in the way of progress. But make no mistake, it *is* a feature, not a bug fix. It took a multidisciplinary team a year to implement it -- from existing portable code in C! Mark wrote easily a page in favor of introducing it. Those are signs of a Feature. The original behavior was no more a bug than the distinction between int and long, or the existence of classic and new classes, or the GIL. These were all deliberate design decisions made as compromises between different requirements. And make no mistake, I like this feature in 3.1. Just as I like the new int type, the new str type, the new classes, the new rich comparisons. The new f.p. repr() may look like a small feature -- but it's a feature that few other languages have! If I had a doctest that depended on the vagaries of f.p. repr(), I would probably change the doctest to use simpler numbers; getting 1./3.+1./3. to be exactly 2./3. is hard enough, but I might rewrite my test to use 1/2. + 1/2. = 1. instead. So the doctest argument isn't all too strong. Carrot-wise the feature is quite strong (see Mark's page of arguments in favor) -- but that works also in favor of inclusion on 2.7. In the end somebody needs to do the work. If it can reuse much of the work done for 3.1, then hopefully it will be done in much less time than the original was done. It looks like someone wants to do this work. I wish them well. But doing this work will mean not doing other work on 2.7 that may be more productive. PS. str(x) still seems to be using %.12g -- shouldn't it be made equal to repr() in 3.1 or 3.2? *That* I would call a bug, an oversight. -- --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
