Re: [Python-Dev] 2.5.2 release coming up
We need to fix the Windows buildbots. 2 tests are currently failing
for 2.5.2: test_mailbox test_winreg
From:
http://www.python.org/dev/buildbot/all/x86%20XP-4%202.5/builds/107/step-test/0
The errors are:
File
"E:\cygwin\home\db3l\buildarea\2.5.bolen-windows\build\lib\test\test_mailbox.py",
line 522, in test_consistent_factory
msg2 = box.get_message(key)
File "E:\cygwin\home\db3l\buildarea\2.5.bolen-windows\build\lib\mailbox.py",
line 315, in get_message
subpath = self._lookup(key)
File "E:\cygwin\home\db3l\buildarea\2.5.bolen-windows\build\lib\mailbox.py",
line 484, in _lookup
raise KeyError('No message with key: %s' % key)
KeyError: 'No message with key: 1201127998.M194999P232Q203.buildbot'
and: test test_winreg failed -- Not the correct number of sub keys
There are several warnings from the tests that we should try to clean up:
lib\test\test_generators.py:1: DeprecationWarning: raising string
exceptions is deprecated
tutorial_tests = """
lib\zipfile.py:714: DeprecationWarning: struct integer overflow
masking is deprecated
0, 0, count, count, pos2 - pos1, -1, 0)
lib\zipfile.py:691: DeprecationWarning: struct integer overflow
masking is deprecated
header_offset)
lib\test\test_unicode_file.py:103: UnicodeWarning: Unicode equal
comparison failed to convert both arguments to Unicode - interpreting
them as being unequal
filename1==filename2
lib\shutil.py:36: UnicodeWarning: Unicode equal comparison failed to
convert both arguments to Unicode - interpreting them as being unequal
os.path.normcase(os.path.abspath(dst)))
n
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] struct module docs vs reality
Gregory P. Smith wrote:
>
> The documentation for the struct module says:
>
> http://docs.python.org/dev/library/struct.html#module-struct
>
> " short is 2 bytes; int and long are 4 bytes; long long ( __int64 on
> Windows) is 8 bytes"
>
> and lists 'l' and 'L' as the pack code for a C long.
>
> As its implemented today, the documentation is incorrect. On an LP64
> host (pretty much any 64-bit linux, bsd or unixish thing) a long is 8
> bytes.
You overlooked the words "Standard size and alignment are as follows"
that start the quoted paragraph. It's a little confusing because
standard size is not the default. The default is platform-specific
sizes. Only if you start the format string with >, <, ! or = do you
get standard sizes.
The reference documentation is correct as it stands, and, I suspect,
so is the LP64 implementation. Doesn't struct.pack('>l',42) produce a
4-byte string on LP64?
The tutorial at
http://docs.python.org/tut/node13.html#SECTION001330%3E
has a bug though: the format string should use '<'.
I believe zipfile.py correctly uses '<' throughout.
regards, Anders
___
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] struct module docs vs reality
Oh good. Reading the Modules/_struct.c code I see that is indeed what happens. There are still several instances of misused struct pack and unpack strings in Lib but the problem is less serious, I'll make a new patch that just addresses those. ___ 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] 2.5.2 release coming up
Neal Norwitz schrieb: > We need to fix the Windows buildbots. 2 tests are currently failing > for 2.5.2: test_mailbox test_winreg The test_winreg failure is a funny one: The py3k test_winreg fails because of a bug in the test itself; I fixed this in rev. 60236. The failing test leaves a key in the registry that make the trunk and release25-maint tests also fail. I have manually removed the offending key in the registry on the x86 XP-3 buildbot; we'll see if it works now. The real solution, however, would be to change all the test_winreg tests to remove the test-key completely before and after their test. But I'll leave this to someone else. Thomas ___ 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] 2.5.2 release coming up
> From:
>
http://www.python.org/dev/buildbot/all/x86%20XP-4%202.5/builds/107/step-test/0
>
> The errors are:
>
> File
"E:\cygwin\home\db3l\buildarea\2.5.bolen-windows\build\lib\test\test_mailbox
.py",
> line 522, in test_consistent_factory
> msg2 = box.get_message(key)
> File
"E:\cygwin\home\db3l\buildarea\2.5.bolen-windows\build\lib\mailbox.py",
> line 315, in get_message
> subpath = self._lookup(key)
> File
"E:\cygwin\home\db3l\buildarea\2.5.bolen-windows\build\lib\mailbox.py",
> line 484, in _lookup
> raise KeyError('No message with key: %s' % key)
> KeyError: 'No message with key: 1201127998.M194999P232Q203.buildbot'
I did quick investigation on this error.
After self._refresh() (line 480 in _loopkup - Lib/mailbox.py) runs,
self._toc contains key like this.
1201171711.M848000P1176Q16.whiterab-c2znlh!2,FR
Please look at exclamation mark. Probably this is not intended on most
platforms like Unix.
It should be ":" colon.
But on windows, ":" is special letter after drive letter. (ex:
"C:/Winnt/foo/bar")
So I imagine open() or something converts ":" to "!" (valid character as
file name).
After I applied following experimental patch, test_mailbox.py run
successfully on windows.
Index: Lib/mailbox.py
===
--- Lib/mailbox.py (revision 60233)
+++ Lib/mailbox.py (working copy)
@@ -223,7 +223,8 @@
class Maildir(Mailbox):
"""A qmail-style Maildir mailbox."""
-colon = ':'
+# colon = ':'
+colon = "!"
def __init__(self, dirname, factory=rfc822.Message, create=True):
"""Initialize a Maildir instance."""
___
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] 2.5.2 release coming up
> But on windows, ":" is special letter after drive letter. (ex:
> "C:/Winnt/foo/bar")
> So I imagine open() or something converts ":" to "!" (valid character as
> file name).
Sorry, I lied. :-(
open() didn't change ":", test_mailbox.py (TestMaildir.setUp) changed
self._box.colon to "!"
Otherwise, newly created mail box in test_consistent_factory 's "colon" is
":".
This mismatch causes error.
Following patch solves error, but I don't know if this is good solution.
Index: Lib/test/test_mailbox.py
===
--- Lib/test/test_mailbox.py (revision 60233)
+++ Lib/test/test_mailbox.py (working copy)
@@ -458,12 +458,11 @@
class TestMaildir(TestMailbox):
-_factory = lambda self, path, factory=None: mailbox.Maildir(path,
factory)
-
-def setUp(self):
-TestMailbox.setUp(self)
+def _factory(self, path, factory=None):
+box = mailbox.Maildir(path, factory)
if os.name in ('nt', 'os2') or sys.platform == 'cygwin':
-self._box.colon = '!'
+box.colon = '!'
+return box
def test_add_MM(self):
# Add a MaildirMessage instance
@@ -518,7 +517,7 @@
# Create new mailbox with
class FakeMessage(mailbox.MaildirMessage):
pass
-box = mailbox.Maildir(self._path, factory=FakeMessage)
+box = self._factory(self._path, factory=FakeMessage)
msg2 = box.get_message(key)
self.assert_(isinstance(msg2, FakeMessage))
___
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] Incorrect documentation of the raw_input built-in function
Recently I was trying to debug an old python program who's maintenance I inherited. I was using the quick-and-dirty method of putting some 'print >>sys.stderr' statements in the code, and then running the command with '2>filename' appended to the end of the command line. Imagine my surprise to see that all of the prompt text from the program's raw_input calls were also disappearing from the screen output, and appearing in the stderr output routed to the file. The latest documentation for raw_input states "If the prompt argument is present, it is written to standard output without a trailing newline." I posted a question regarding the observed behavior to comp.lang.python and Gabriel Genellina (thanks Gabriel!) pointed out that despite the documentation, raw_input was hard-coded to always output its prompt text to stderr. This raises two questions: 1. Shouldn't the current documentation be corrected to state that raw_input writes its prompt to standard error? 2. Is this really the hard-coded behavior we want? I don't think my use-case is that odd; in fact, what I find very odd is that the prompt output is send to stderr. I mean, I'm printing the prompt for a question, not some error message. Can there not at least be an optional parameter to indicate that you want the output sent to stdout rather than stderr? ___ 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] rfc822_escape doing the right thing?
I have created issue #1923 to keep track of this. Stephen Emslie On Jan 23, 2008 6:00 PM, Gregory P. Smith <[EMAIL PROTECTED]> wrote: > could you put this on bugs.python.org and follow up with a reference to the > issue # for better tracking? > > > > On 1/23/08, stephen emslie <[EMAIL PROTECTED]> wrote: > > > > > > > > I've been working on a project that renders PKG-INFO metadata in a > > number of ways. I have noticed that fields with any indentation were > > flattened out, which is being done in distutils.util.rfc822_escape. > > This unfortunately means that you cant use reStructuredText formatting > > in your long description (suggested in PEP345), or are limited to a > > set that doesn't require indentation (no block quotes, etc.). > > > > It looks like this behavior was intentionally added in rev 20099, but > > that was about 7 years ago - before reStructuredText and eggs. I > > wonder if it makes sense to re-think that implementation with this > > sort of metadata in mind, assuming this behavior isn't required to be > > rfc822 compliant. I think it would certainly be a shame to miss out on > > a good thing like proper (renderable) reST in our metadata. > > > > A quick example of what I mean: > > > > >>> rest = """ > > ... a literal python block:: > > ... >>> import this > > ... """ > > >>> print distutils.util.rfc822_escape(rest) > > > > a literal python block:: > > >>> import this > > > > should look something like: > > > > a literal python block:: > > >>> import this > > > > > > Is distutils being over-cautious in flattening out all whitespace? A > > w3c discussion on multiple lines in rfc822 [1] seems to suggest that > > whitespace can be 'unfolded' safely, so it seems a shame to be > > throwing it away when it can have important meaning. > > > > [1] http://www.w3.org/Protocols/rfc822/3_Lexical.html > > > > Thanks for any comments > > > > Stephen Emslie > > ___ > > 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/greg%40krypto.org > > > > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Incorrect documentation of the raw_input built-in function
Mike> 2. Is this really the hard-coded behavior we want? I don't think Mike>my use-case is that odd; in fact, what I find very odd is that Mike>the prompt output is send to stderr. I mean, I'm printing the Mike>prompt for a question, not some error message. Can there not at Mike>least be an optional parameter to indicate that you want the Mike>output sent to stdout rather than stderr? I can think of situations where you don't want the output to go to stdout either (suppose it's the regular output of the file you want to save to a file). Having a choice seems the best route. ___ 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] Incorrect documentation of the raw_input built-in function
On Thu, 24 Jan 2008, [EMAIL PROTECTED] wrote: >Mike> 2. Is this really the hard-coded behavior we want? I don't think >Mike>my use-case is that odd; in fact, what I find very odd is that >Mike>the prompt output is send to stderr. I mean, I'm printing the >Mike>prompt for a question, not some error message. Can there not at >Mike>least be an optional parameter to indicate that you want the >Mike>output sent to stdout rather than stderr? > > I can think of situations where you don't want the output to go to stdout > either (suppose it's the regular output of the file you want to save to a > file). Having a choice seems the best route. What about an option (maybe even a default) to send the prompt to stdin? The Postgres command line interface psql appears to do this: $ psql 2>&1 >/dev/null Password: $ (I typed my password and then I quit by typing ^D; if I type the wrong password, it looks the same on screen but it quits right away without waiting for ^D) I think ssh also does this when it needs to prompt for a password. Really the prompt is part of the input, not part of the output, in a certain sense. Have people actually verified that the prompt is really sent to stderr right now by using 2>/dev/null to attempt to suppress it? Isaac Morland CSCF Web Guru DC 2554C, x36650WWW Software Specialist ___ 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] Incorrect documentation of the raw_input built-in function
On Thu, Jan 24, 2008 at 12:36:51PM -0500, Isaac Morland wrote:
> What about an option (maybe even a default) to send the prompt to stdin?
>
> The Postgres command line interface psql appears to do this:
>
> $ psql 2>&1 >/dev/null
> Password:
> $
>
> (I typed my password and then I quit by typing ^D; if I type the wrong
> password, it looks the same on screen but it quits right away without
> waiting for ^D)
>
> I think ssh also does this when it needs to prompt for a password.
One cannot write to stdin:
>>> sys.stdin.write("1\n")
Traceback (most recent call last):
File "", line 1, in
IOError: [Errno 9] Bad file descriptor
But it is possible to explicitly open the current console for reading
and writing and do I/O regardless of stdin/stdout/stderr redirects:
>>> tty = open("/dev/tty", "r+")
>>> tty.write("1\n")
1
>>> line = tty.readline()
DDD
>>> line
'DDD\n'
Oleg.
--
Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED]
Programmers don't die, they just GOSUB without RETURN.
___
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] Incorrect documentation of the raw_input built-in function
Isaac> Have people actually verified that the prompt is really sent to
Isaac> stderr right now by using 2>/dev/null to attempt to suppress it?
Good point. On my machine at work (Solaris), Python 2.4 seems to send its
raw_input prompt to stdout, not stderr:
% python
Python 2.4.2 (#1, Feb 23 2006, 12:48:31)
[GCC 3.4.1] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> raw_input("?")
?z
'z'
>>>
ink% python 2>/dev/null
>>> raw_input("?")
?sdf
'sdf'
>>> ink% python >/dev/null
Python 2.4.2 (#1, Feb 23 2006, 12:48:31)
[GCC 3.4.1] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> raw_input("?")
wer
>>> ^D
Same for 2.6a0 on my Mac at home. Mike, are you sure about it prompting to
stderr? If so, what's your setup?
Skip
___
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] trunc()
On Jan 24, 2008 10:36 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > Can anyone explain to me why we need both trunc() and int()? trunc() has well-defined semantics -- it takes a Real instance and converts it to an Integer instance using round-towards-zero semantics. int() has undefined semantics -- it takes any object and converts it to an int (a concrete type!) using whatever rules it likes -- the definition of __int__ is up to whatever the source type likes to do. For float this has been defined the same as trunc() above, but for other types, who knows! int() of a string does something completely different. Perhaps worse is that sometimes int() is lossy (e.g. with a float input) and sometimes it is not (e.g. with a string input, or with a non-standard representation of integers). There are still some places where a float is accepted incorrectly (silently truncating) due to the use of the __int__ slot. If trunc() had been part of the language from the beginning we wouldn't have needed to introduce __index__. -- --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] Incorrect documentation of the raw_input built-in function
Beware: this may depend on whether GNU readline is enabled or not --
under many circumstances, raw_input() calls GNU readline instead of
using sys.stdin/stdout.
I do agree that if there are any conditions where it uses stderr
instead of stdout those are mistakes.
On Jan 24, 2008 9:47 AM, <[EMAIL PROTECTED]> wrote:
>
> Isaac> Have people actually verified that the prompt is really sent to
> Isaac> stderr right now by using 2>/dev/null to attempt to suppress it?
>
> Good point. On my machine at work (Solaris), Python 2.4 seems to send its
> raw_input prompt to stdout, not stderr:
>
> % python
> Python 2.4.2 (#1, Feb 23 2006, 12:48:31)
> [GCC 3.4.1] on sunos5
> Type "help", "copyright", "credits" or "license" for more information.
> >>> raw_input("?")
> ?z
> 'z'
> >>>
> ink% python 2>/dev/null
> >>> raw_input("?")
> ?sdf
> 'sdf'
> >>> ink% python >/dev/null
> Python 2.4.2 (#1, Feb 23 2006, 12:48:31)
> [GCC 3.4.1] on sunos5
> Type "help", "copyright", "credits" or "license" for more information.
> >>> raw_input("?")
> wer
> >>> ^D
>
> Same for 2.6a0 on my Mac at home. Mike, are you sure about it prompting to
> stderr? If so, what's your setup?
>
> Skip
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] trunc()
Can anyone explain to me why we need both trunc() and int()? We used to be very resistant to adding new built-ins and magic method protocols. In days not long past, this would have encountered fierce opposition. ISTM that numbers.py has taken on a life of its own and is causing non-essential offspring to sprout-up everywhere. Also, it seems that ABC is starting to evolve from an optional tool into something embedded in the language in a way that you can't escape it. I would prefer that it not be on the list of concepts that a beginner *must* know in order to be functional in the language. There are a handful of needs met by the numeric tower but they only warrant minimal changes to the language. Raymond P.S. The docstring for trunc() makes it sound like an imprecisely specified version of round(). trunc() looks like int() but it isn't--- >>> v = [-4.9, -4.5, -4.1, -4.0, -3.5, -0.0, 0.0, 3.5, 4.0, 4.1, 4.5, 4.9] >>> map(int, v) [-4, -4, -4, -4, -3, 0, 0, 3, 4, 4, 4, 4] >>> map(trunc, v) [-4, -4, -4, -4, -3, 0, 0, 3, 4, 4, 4, 4] >>> trunc is int False >>> print trunc.__doc__ trunc(Real) -> Integral returns the integral closest to x between 0 and x. ___ 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] trunc()
> trunc() has well-defined semantics -- it takes a Real instance and > converts it to an Integer instance using round-towards-zero semantics. No. trunc calls __trunc__, which does whatever it pleases to do. >>> class A: ... def __trunc__(self): ... return 0 ... >>> a=A() >>> trunc(a) 0 > > int() has undefined semantics -- it takes any object and converts it > to an int (a concrete type!) using whatever rules it likes -- the > definition of __int__ is up to whatever the source type likes to do. > For float this has been defined the same as trunc() above, but for > other types, who knows! int() of a string does something completely > different. But why is that a reason to keep trunc()? If you only ever want to convert floats to ints, you can use either one, with no difference. int() does *not* have undefined semantics, for floats, it converts it to an integer using round-towards-zero semantics. Regards, Martin ___ 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] Incorrect documentation of the raw_input built-in function
pobox.com> writes: > > > Isaac> Have people actually verified that the prompt is really sent to > Isaac> stderr right now by using 2>/dev/null to attempt to suppress it? > > Good point. On my machine at work (Solaris), Python 2.4 seems to send its > raw_input prompt to stdout, not stderr: > > > Same for 2.6a0 on my Mac at home. Mike, are you sure about it prompting to > stderr? If so, what's your setup? > > Skip Skip, Guido and others: Interesting point about whether GNU readline is installed. My setup is RedHat Linux, with Python 2.5 that I built and installed myself. GNU readline is not, in fact, installed. If you look at Python2.5/Parser/myreadline.c, function PyOS_StdioReadline, line 125, you will see that prompt output is being sent to stderr. As best as my Python-fu can determine, this is the code used to output a raw_input prompt (thanks again to Gabriel Genellina for pointing me in the right direction.) It's entirely likely that the difference in what I am seeing and what you guys are seeing is caused by my not having GNU readline installed. Nevertheless, the behavior without it seems wrong, and is certainly different from the documentation. ___ 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] trunc()
On Jan 24, 2008 11:36 AM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > trunc() has well-defined semantics -- it takes a Real instance and > > converts it to an Integer instance using round-towards-zero semantics. > > No. trunc calls __trunc__, which does whatever it pleases to do. > > >>> class A: > ... def __trunc__(self): > ... return 0 > ... > >>> a=A() > >>> trunc(a) > 0 However, PEP 3141 specifies what it should do for Numbers. > > int() has undefined semantics -- it takes any object and converts it > > to an int (a concrete type!) using whatever rules it likes -- the > > definition of __int__ is up to whatever the source type likes to do. > > For float this has been defined the same as trunc() above, but for > > other types, who knows! int() of a string does something completely > > different. > > But why is that a reason to keep trunc()? If you only ever want to > convert floats to ints, you can use either one, with no difference. > int() does *not* have undefined semantics, for floats, it converts > it to an integer using round-towards-zero semantics. Yes (although it wasn't always specified this way). But I don't like that, because of the ambiguity of int(x). -- --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] Incorrect documentation of the raw_input built-in function
On Jan 24, 2008 11:41 AM, Mike Kent <[EMAIL PROTECTED]> wrote: > pobox.com> writes: > > > > > > > Isaac> Have people actually verified that the prompt is really sent to > > Isaac> stderr right now by using 2>/dev/null to attempt to suppress it? > > > > Good point. On my machine at work (Solaris), Python 2.4 seems to send its > > raw_input prompt to stdout, not stderr: > > > > > > > Same for 2.6a0 on my Mac at home. Mike, are you sure about it prompting to > > stderr? If so, what's your setup? > > > > Skip > > Skip, Guido and others: > > Interesting point about whether GNU readline is installed. My setup is RedHat > Linux, with Python 2.5 that I built and installed myself. GNU readline is > not, > in fact, installed. If you look at Python2.5/Parser/myreadline.c, function > PyOS_StdioReadline, line 125, you will see that prompt output is being sent to > stderr. As best as my Python-fu can determine, this is the code used to > output > a raw_input prompt (thanks again to Gabriel Genellina for pointing me in the > right direction.) > > It's entirely likely that the difference in what I am seeing and what you guys > are seeing is caused by my not having GNU readline installed. Nevertheless, > the behavior without it seems wrong, and is certainly different from the > documentation. Agreed. -- --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] Incorrect documentation of the raw_input built-in function
Guido van Rossum python.org> writes: > > > It's entirely likely that the difference in what I am seeing and what you > > guys > > are seeing is caused by my not having GNU readline installed. Nevertheless, > > the behavior without it seems wrong, and is certainly different from the > > documentation. > > Agreed. > Being that Guido agrees, should I put a bug report into the system for it, and if so, which should it report as the bug: the actual behavior of the raw_input prompt when GNU readline is not installed, or the documentation? ___ 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] Incorrect documentation of the raw_inputbuilt-in function
IMO the actual behavior is incorrect. On Jan 24, 2008 12:14 PM, Mike Kent <[EMAIL PROTECTED]> wrote: > Guido van Rossum python.org> writes: > > > > > > It's entirely likely that the difference in what I am seeing and what you > > > guys > > > are seeing is caused by my not having GNU readline installed. > > > Nevertheless, > > > the behavior without it seems wrong, and is certainly different from the > > > documentation. > > > > Agreed. > > > > Being that Guido agrees, should I put a bug report into the system for it, and > if so, which should it report as the bug: the actual behavior of the raw_input > prompt when GNU readline is not installed, or the documentation? > > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Incorrect documentation of the raw_input built-in function
> "Guido" == Guido van Rossum <[EMAIL PROTECTED]> writes: >> It's entirely likely that the difference in what I am seeing and what >> you guys are seeing is caused by my not having GNU readline >> installed. Nevertheless, the behavior without it seems wrong, and is >> certainly different from the documentation. Guido> Agreed. http://bugs.python.org/issue1927 Skip ___ 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] trunc()
>> Can anyone explain to me why we need both trunc() and int()? > trunc() has well-defined semantics -- it takes a Real instance > and converts it to an Integer instance using round-towards-zero > semantics. Since something similar is happening to math.ceil and math.floor, I'm curious why trunc() ended-up in builtins instead of the math module. Doesn't it make sense to collect similar functions with similar signatures in the same place? 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] Is anyone porting PyNumber_ToBase to trunk?
Guido van Rossum wrote: > On Jan 23, 2008 7:40 AM, Eric Smith <[EMAIL PROTECTED]> wrote: >> In 3.0, the code to implement long.__format__() calls PyNumber_ToBase to >> do the heavy lifting. If someone is planning on implementing >> PyNumber_ToBase in 2.6, I'll wait for them to do so. If not, I guess >> I'll either do it myself, or hack around it. >> >> Is this on anyone's To Do list? I don't see it on Brett's spreadsheet >> at http://spreadsheets.google.com/pub?key=pCKY4oaXnT81FrGo3ShGHGg > > I'm sure this is because nobody had thought of this detail until now. > Just get started on it. Feel free to add it to the spreadsheet. It's an implementation detail of PEP 3127 (oct() and bin()), which is on the spreadsheet. I guess I'll have to work on oct() and bin() first. The spreadsheet notes a possible __future__ statement requirement for oct(). The PEP doesn't mention this, and I'm not sure I understand the issue. Any clues? ___ 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] trunc()
Raymond Hettinger wrote: > Since something similar is happening to math.ceil and math.floor, > I'm curious why trunc() ended-up in builtins instead of the math > module. Doesn't it make sense to collect similar functions > with similar signatures in the same place? Traditionally the math module is a tiny wrapper around the system's libm. Functions for magic hooks like __trunc__ usually end up in builtins. In this particular case I don't mind where the function is going to live. Christian ___ 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] trunc()
On Jan 24, 2008 12:46 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > trunc() has well-defined semantics -- it takes a Real instance and > converts it to an Integer instance using round-towards-zero semantics. > > int() has undefined semantics -- it takes any object and converts it > to an int (a concrete type!) using whatever rules it likes -- the > definition of __int__ is up to whatever the source type likes to do. What are the use-cases for when trunc() vs int() should be used, and for when a class should define __trunc__ vs __int__? This might help clear up whether both deserve to be a built-in, as well provide a starting point for 3.0 best practices. -- 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
[Python-Dev] trunc()
[Raymond Hettinger] > Since something similar is happening to math.ceil and math.floor, > I'm curious why trunc() ended-up in builtins instead of the math > module. Doesn't it make sense to collect similar functions > with similar signatures in the same place? [Christian Heimes] > Traditionally the math module is a tiny wrapper around the > system's libm. Functions for magic hooks like __trunc__ > usually end up in builtins. In this particular case I don't > mind where the function is going to live. Traditions have gone out the window. ceil() and floor() are going to have their signatures changed (Real --> Integral) and are going to have their own magic methods. They cannot be characterized as a thin wrapper around libm. So the question stands, why is trunc() different? Can anything good come from having trunc() and int() in the same namespace? 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] Is anyone porting PyNumber_ToBase to trunk?
On Jan 24, 2008 12:40 PM, Eric Smith <[EMAIL PROTECTED]> wrote: > The spreadsheet notes a possible __future__ statement requirement for > oct(). The PEP doesn't mention this, and I'm not sure I understand the > issue. Any clues? You can't change the default oct() to return '0o123'; but perhaps you could import a different version that returned that instead of the default '0123'. -- --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] Float --> Integer Ratio
rational.py contains code for turning a float into an exact integer ratio. I've needed something like this in other situations as well. The output is more convenient than the mantissa/exponent pair returned by math.frexp(). I propose C-coding this function and either putting it in the math module or making it a method for floats. That would simplify and speed-up rational.py while making the tool available for other applications. Also, the tool is currently in the wrong place (while the output is clearly useful for rational.py, the internals of the function are entirely about floats and ints and has no internal references to the rational module). Raymond --- def _binary_float_to_ratio(x): """x -> (top, bot), a pair of ints s.t. x = top/bot. The conversion is done exactly, without rounding. bot > 0 guaranteed. Some form of binary fp is assumed. Pass NaNs or infinities at your own risk. >>> _binary_float_to_ratio(10.0) (10, 1) >>> _binary_float_to_ratio(0.0) (0, 1) >>> _binary_float_to_ratio(-.25) (-1, 4) """ ___ 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] trunc()
On Jan 24, 2008 1:09 PM, Daniel Stutzbach <[EMAIL PROTECTED]> wrote: > On Jan 24, 2008 12:46 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > trunc() has well-defined semantics -- it takes a Real instance and > > converts it to an Integer instance using round-towards-zero semantics. > > > > int() has undefined semantics -- it takes any object and converts it > > to an int (a concrete type!) using whatever rules it likes -- the > > definition of __int__ is up to whatever the source type likes to do. > > What are the use-cases for when trunc() vs int() should be used, and > for when a class should define __trunc__ vs __int__? If you intend to convert a real number (usually float, since Decimal has decided not to support it) to an Integral (usually int), use whichever of trunc(), round(), math.floor(), or math.ceil() you intend. In 2.6, that list only includes trunc(). If you absolutely need an int (the concrete, not duck type) from an Integral or you want to parse a string, use int(). Real numbers should define __trunc__. Integrals and, perhaps, some string-like types (maybe an MD5 class?) should define __int__. At least, that's my suggestion. -- Namasté, Jeffrey Yasskin ___ 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] [python] Re: trunc()
Jeffrey Yasskin wrote: > On Jan 24, 2008 1:11 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > >> [Raymond Hettinger] >> >>> Since something similar is happening to math.ceil and math.floor, >>> I'm curious why trunc() ended-up in builtins instead of the math >>> module. Doesn't it make sense to collect similar functions >>> with similar signatures in the same place? >>> >> [Christian Heimes] >> >>> Traditionally the math module is a tiny wrapper around the >>> system's libm. Functions for magic hooks like __trunc__ >>> usually end up in builtins. In this particular case I don't >>> mind where the function is going to live. >>> >> Traditions have gone out the window. ceil() and floor() >> are going to have their signatures changed (Real --> Integral) >> and are going to have their own magic methods. They cannot >> be characterized as a thin wrapper around libm. >> >> So the question stands, why is trunc() different? Can anything >> good come from having trunc() and int() in the same namespace? >> > > One of my goals for trunc() is to replace the from-float use of int(), > even though we can't remove it for backward-compatibility reasons. PEP > 3141 says: > > "Because the int() conversion implemented by float (and by > decimal.Decimal) is equivalent to but less explicit than trunc(), > let's remove it. (Or, if that breaks too much, just add a deprecation > warning.)" > > That needs to be updated and implemented. I think the decision was > that removing float.__int__() would break too much, so it needs a > deprecation warning in 3.0. > > int has to be a builtin because it's a fundamental type. trunc() > followed round() into the builtins. I have no opinion on whether ceil > and floor should move there; it probably depends on how often they're > used. > > So you won't be able to construct an int from a float? That sucks (and is unintuitive). 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] trunc()
On Jan 24, 2008 1:11 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > [Raymond Hettinger] > > Since something similar is happening to math.ceil and math.floor, > > I'm curious why trunc() ended-up in builtins instead of the math > > module. Doesn't it make sense to collect similar functions > > with similar signatures in the same place? > > [Christian Heimes] > > Traditionally the math module is a tiny wrapper around the > > system's libm. Functions for magic hooks like __trunc__ > > usually end up in builtins. In this particular case I don't > > mind where the function is going to live. > > Traditions have gone out the window. ceil() and floor() > are going to have their signatures changed (Real --> Integral) > and are going to have their own magic methods. They cannot > be characterized as a thin wrapper around libm. > > So the question stands, why is trunc() different? Can anything > good come from having trunc() and int() in the same namespace? One of my goals for trunc() is to replace the from-float use of int(), even though we can't remove it for backward-compatibility reasons. PEP 3141 says: "Because the int() conversion implemented by float (and by decimal.Decimal) is equivalent to but less explicit than trunc(), let's remove it. (Or, if that breaks too much, just add a deprecation warning.)" That needs to be updated and implemented. I think the decision was that removing float.__int__() would break too much, so it needs a deprecation warning in 3.0. int has to be a builtin because it's a fundamental type. trunc() followed round() into the builtins. I have no opinion on whether ceil and floor should move there; it probably depends on how often they're used. -- Namasté, Jeffrey Yasskin ___ 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] [python] trunc()
Raymond Hettinger wrote: > [Raymond Hettinger] > >> Since something similar is happening to math.ceil and math.floor, >> I'm curious why trunc() ended-up in builtins instead of the math >> module. Doesn't it make sense to collect similar functions >> with similar signatures in the same place? >> > > [Christian Heimes] > >> Traditionally the math module is a tiny wrapper around the >> system's libm. Functions for magic hooks like __trunc__ >> usually end up in builtins. In this particular case I don't >> mind where the function is going to live. >> > > Traditions have gone out the window. ceil() and floor() > are going to have their signatures changed (Real --> Integral) > and are going to have their own magic methods. They cannot > be characterized as a thin wrapper around libm. > > So the question stands, why is trunc() different? Can anything > good come from having trunc() and int() in the same namespace? > If the ambiguity is that 'int' behaviour is unspecified for floats - is it naive to suggest we specify the behaviour? Michael Foord > > 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/fuzzyman%40voidspace.org.uk > > ___ 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] [python] Re: trunc()
On Jan 24, 2008 3:32 PM, Michael Foord <[EMAIL PROTECTED]> wrote: > > Jeffrey Yasskin wrote: > > On Jan 24, 2008 1:11 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > > > >> [Raymond Hettinger] > >> > >>> Since something similar is happening to math.ceil and math.floor, > >>> I'm curious why trunc() ended-up in builtins instead of the math > >>> module. Doesn't it make sense to collect similar functions > >>> with similar signatures in the same place? > >>> > >> [Christian Heimes] > >> > >>> Traditionally the math module is a tiny wrapper around the > >>> system's libm. Functions for magic hooks like __trunc__ > >>> usually end up in builtins. In this particular case I don't > >>> mind where the function is going to live. > >>> > >> Traditions have gone out the window. ceil() and floor() > >> are going to have their signatures changed (Real --> Integral) > >> and are going to have their own magic methods. They cannot > >> be characterized as a thin wrapper around libm. > >> > >> So the question stands, why is trunc() different? Can anything > >> good come from having trunc() and int() in the same namespace? > >> > > > > One of my goals for trunc() is to replace the from-float use of int(), > > even though we can't remove it for backward-compatibility reasons. PEP > > 3141 says: > > > > "Because the int() conversion implemented by float (and by > > decimal.Decimal) is equivalent to but less explicit than trunc(), > > let's remove it. (Or, if that breaks too much, just add a deprecation > > warning.)" > > > > That needs to be updated and implemented. I think the decision was > > that removing float.__int__() would break too much, so it needs a > > deprecation warning in 3.0. > > > > int has to be a builtin because it's a fundamental type. trunc() > > followed round() into the builtins. I have no opinion on whether ceil > > and floor should move there; it probably depends on how often they're > > used. > > > > > So you won't be able to construct an int from a float? That sucks (and > is unintuitive). Yes, you can, but you have to specify how you want it done by using trunc() or round() or ceil() or floor(). (In 3.0, round(x) will return an int, not a float.) -- --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] [python] trunc()
> If the ambiguity is that 'int' behaviour is unspecified for floats - is > it naive to suggest we specify the behaviour? The concern is that whatever gets specified is arbitrary. There are many ways how an int can be constructed from a float, so why is any such way better than the others, and deserves to be the meaning of int()? Regards, Martin ___ 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] Float --> Integer Ratio
+1. Where do people want it, and what should its name be? I can implement it if you like. Another plausible output would be similar to frexp but with an integer for the mantissa instead of a float. So: A) math.frexp(3.2) == (0.80004, 2) B) integral_frexp(3.2) == (3602879701896397, -50) C) exact_integral_ratio(3.2) == (3602879701896397, 1125899906842624) (B) is easier to implement in C (not that that's a deciding factor); (C) is probably more useful. So I'd vote for (C), your suggestion, but just wanted to make the choice explicit. Also, to make things explicit, the implementation in rational.py doesn't guarantee that the fraction is in lowest terms. Should the library version? On Jan 24, 2008 3:10 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > rational.py contains code for turning a float into an > exact integer ratio. I've needed something like this in > other situations as well. The output is more convenient > than the mantissa/exponent pair returned by math.frexp(). > > I propose C-coding this function and either putting it in > the math module or making it a method for floats. That > would simplify and speed-up rational.py while making > the tool available for other applications. Also, the > tool is currently in the wrong place (while the output > is clearly useful for rational.py, the internals of > the function are entirely about floats and ints and > has no internal references to the rational module). > > Raymond > > > > --- > > def _binary_float_to_ratio(x): > """x -> (top, bot), a pair of ints s.t. x = top/bot. > > The conversion is done exactly, without rounding. > bot > 0 guaranteed. > Some form of binary fp is assumed. > Pass NaNs or infinities at your own risk. > > >>> _binary_float_to_ratio(10.0) > (10, 1) > >>> _binary_float_to_ratio(0.0) > (0, 1) > >>> _binary_float_to_ratio(-.25) > (-1, 4) > """ > ___ > 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/jyasskin%40gmail.com > -- Namasté, Jeffrey Yasskin http://jeffrey.yasskin.info/ "Religion is an improper response to the Divine." — "Skinny Legs and All", by Tom Robbins ___ 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
