[issue3008] Let bin/oct/hex show floats

Raymond Hettinger <[EMAIL PROTECTED]> added the comment: Updating patch so that the global symbol starts with _Py. Added file: http://bugs.python.org/file10726/float7.diff ___ Python tracker <[EMAIL PROTECTED]> _

[issue3194] Demo/loop.c passing "char *" instead of "wchar_t *"

New submission from Rafael Zanella <[EMAIL PROTECTED]>: The Demo/loop.c passes a char pointer (argv[0]) while Py_SetProgramName() now expects a wchar_t pointer. I've attached a patch, the solution on the patch was borrowed, ok stolen, from Python/frozenmain.c -- files: loop_c.diff keyw

[issue3187] os.listdir can return byte strings

Changes by Benjamin Peterson <[EMAIL PROTECTED]>: -- title: os.walk - strange bug -> os.listdir can return byte strings ___ Python tracker <[EMAIL PROTECTED]> ___ _

[issue3008] Let bin/oct/hex show floats

Changes by Raymond Hettinger <[EMAIL PROTECTED]>: -- assignee: rhettinger -> gvanrossum nosy: +gvanrossum title: Let bin() show floats -> Let bin/oct/hex show floats ___ Python tracker <[EMAIL PROTECTED]> ___

[issue3008] Let bin() show floats

Raymond Hettinger <[EMAIL PROTECTED]> added the comment: Re-opening for further discussion. -1 on Nick's suggestion to normalize hex output so that nearby floats have nearby reprs. This unnecessarily complicates a simple, straight- forward presentation. In the paper referenced by Terry Reedy,

[issue3193] Python 2.5.2 - Python

Peter Dilley <[EMAIL PROTECTED]> added the comment: Done at pyglet, Thanks for the update, my first Python error like that, could not determine where the issue was stemming from. My worry was the latest security patching from Apple introduced this bug with the Mac version of Python.org's implem

[issue3193] Python 2.5.2 - Python[2420:613] Error loading / flat namespace error

Guilherme Polo <[EMAIL PROTECTED]> added the comment: Neither pyglet nor anything else you installed is part of Python's source, you will have to re-report this at the appropriate place. -- nosy: +gpolo resolution: -> invalid status: open -> closed _

[issue3193] Python 2.5.2 - Python[2420:613] Error loading / flat namespace error

New submission from Peter Dilley <[EMAIL PROTECTED]>: I have noticed a new crash when using pyglet module after installing the latest Apple security patch/framework for Quicktime, Quicktime Framework 7.5.0. This error is repeatable. This error occurs when the opened window is selected/made ac

[issue1394] simple patch, improving unreachable bytecode removing

Guido van Rossum <[EMAIL PROTECTED]> added the comment: Rejecting. Too much risk as well, based on experience in the past with supposedly harmless optimizations. -- resolution: -> rejected status: open -> closed ___ Python tracker <[EMAIL PROTECTED]

[issue1394] simple patch, improving unreachable bytecode removing

Raymond Hettinger <[EMAIL PROTECTED]> added the comment: Recommend rejecting. Too much work for zero performance payoff. -- assignee: rhettinger -> ___ Python tracker <[EMAIL PROTECTED]> ___

[issue3192] exec(open(filename)) doesn't work

Leif Walsh <[EMAIL PROTECTED]> added the comment: execfile is in Lib/idlelib/PyShell.py, and is an instance function, so it's not really standard for regular code, and would also be hard to use correctly. Sorry. ___ Python tracker <[EMAIL PROTECTED]>

[issue3167] math test fails on Solaris 10

Jean Brouwers <[EMAIL PROTECTED]> added the comment: Mark, Take a look at the SUN forum, there is a (long) answer. /Jean On Tue, Jun 24, 2008 at 3:37 PM, Jean Brouwers <[EMAIL PROTECTED]> wrote: > > Jean Brouwers <[EMAIL PROTEC

[issue3167] math test fails on Solaris 10

Jean Brouwers <[EMAIL PROTECTED]> added the comment: Right on! With errno = 0; in between both calls: -Inf 33 Inf 0 /Jean On Tue, Jun 24, 2008 at 1:17 PM, Mark Dickinson <[EMAIL PROTECTED]> wrote: > > Mark Dickinson <[EMAIL PROTECTED]> added the comment: > > On Mon, Jun 23, 2008 at 5:25 PM, J

[issue3192] exec(open(filename)) doesn't work

Mike Speciner <[EMAIL PROTECTED]> added the comment: Well, I think I found exec in bltinmodule.c, but execfile isn't in that file. [In the 3.0 tree.] ___ Python tracker <[EMAIL PROTECTED]>

[issue3192] exec(open(filename)) doesn't work

Leif Walsh <[EMAIL PROTECTED]> added the comment: (isn't gone, that is) ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list mailing l

[issue3192] exec(open(filename)) doesn't work

Leif Walsh <[EMAIL PROTECTED]> added the comment: On Tue, Jun 24, 2008 at 3:05 PM, Mike Speciner <[EMAIL PROTECTED]> wrote: > By the way, I was told that execfile is gone from python 3. It certainly isn't in the branch I just checked out. ___ Python tracker <

[issue3192] exec(open(filename)) doesn't work

Mike Speciner <[EMAIL PROTECTED]> added the comment: I'm actually quite new to Python. My current interpreter of choice is PostScript, followed by Matlab, but I've been discouraged from using either one here at EMC. (PostScript because it's obscure, Matlab because it's expensive!) Meanwhile, I'm

[issue3192] exec(open(filename)) doesn't work

Leif Walsh <[EMAIL PROTECTED]> added the comment: There's 'execfile' in Lib/idlelib/PyShell.py...I'm looking for others. There is also a class of functions 'exec*' (and a related class, 'spawn*') in Lib/os.py that claims to do just what you want, but replacing the current process (or, in spawn

[issue3192] exec(open(filename)) doesn't work

New submission from Mike Speciner <[EMAIL PROTECTED]>: In 2.5, exec(open(filename)), where filename refers to a file with python code, executes the code. In 2.5, open returns an open file, but in 3.0, open returns a stream, and so exec (which wants "a string, file, or code object, not TextIOWrapp

[issue3167] math test fails on Solaris 10

Changes by Mark Dickinson <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file10722/unnamed ___ Python tracker <[EMAIL PROTECTED]> ___ ___

[issue3167] math test fails on Solaris 10

Mark Dickinson <[EMAIL PROTECTED]> added the comment: On Mon, Jun 23, 2008 at 5:25 PM, Jean Brouwers <[EMAIL PROTECTED]> wrote: > result is different for 32- and 64-bit > > > cc -xtarget=native log_inf.c -lm ; a.out > -Inf 33 > Inf 33 > That 33 for the second log call may just be the propagated

[issue449227] rlcompleter add "(" to callables feature

Guilherme Polo <[EMAIL PROTECTED]> added the comment: On Tue, Jun 24, 2008 at 3:42 PM, Manuel Muradás <[EMAIL PROTECTED]> wrote: > > Manuel Muradás <[EMAIL PROTECTED]> added the comment: > > Guilherme, > Thanks a lot for taking some time to review my patch. > Here is a new version. > > Please tak

[issue449227] rlcompleter add "(" to callables feature

Changes by Manuel Muradás <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file10714/rlcompleterAndDoc2.6.diff ___ Python tracker <[EMAIL PROTECTED]> ___ ___

[issue449227] rlcompleter add "(" to callables feature

Manuel Muradás <[EMAIL PROTECTED]> added the comment: Guilherme, Thanks a lot for taking some time to review my patch. Here is a new version. Please take another look and tell me what do you think about it. Thanks again Added file: http://bugs.python.org/file10721/rlcompleter2.6.diff _

[issue449227] rlcompleter add "(" to callables feature

Guilherme Polo <[EMAIL PROTECTED]> added the comment: This is nearly good. But I have some notes: you don't need to import operator here, just use the built-in callable; stick to <80 columns; leave a space after a comma. -- nosy: +gpolo ___ Python tr

[issue449227] rlcompleter add "(" to callables feature

Roman Suzi <[EMAIL PROTECTED]> added the comment: Thanks for the patch! However, I do not understand if it ever gets included into Python or remains always for those who find it? (I do not believe this small change is somehow PEPable, but how it gets included then?)

[issue3182] 2to3 Slight Patch

Nick Edds <[EMAIL PROTECTED]> added the comment: I don't think the improvement falls in margin of error, but maybe I'm wrong. The problem was that even when just run on a single file, isinstance was being called upwards of 100,000 times. I guess it doesn't merit inclusion on its own though, but w

[issue3189] Py3k DeprecationWarning in difflib

Raymond Hettinger <[EMAIL PROTECTED]> added the comment: Applying a minimal version of this patch -- changing has_key() to __contains__(). See r64511. -- nosy: +rhettinger resolution: -> accepted status: open -> closed ___ Python tracker <[EMAIL PR

[issue3182] 2to3 Slight Patch

Collin Winter <[EMAIL PROTECTED]> added the comment: I'm not wild about making this change for such a minimal improvement (which I would guess falls within the margin of error), since it will limit extensibility and testability. I think I'd be fine with it if the benefit were >10%, but 3% doesn't

[issue2813] No float formatting in PyString_FromFormat

Jean Brouwers <[EMAIL PROTECTED]> added the comment: Here is another patch for PyString_FromFormat* adding support for 'l' and 'z' type specifications for the '%x' format and an optional '#' to prepend '0x' to the hex result. In addition, the '%p' format is handled as '%#x'. Updates for the c

[issue3191] round docstring is inaccurate

New submission from Mark Dickinson <[EMAIL PROTECTED]>: In Python 3.0, help(round) gives the following: round(...) round(number[, ndigits]) -> floating point number Round a number to a given precision in decimal digits (default 0 digits). This returns an int when called with on

[issue3187] os.walk - strange bug

Helmut Jarausch <[EMAIL PROTECTED]> added the comment: >> Could you tell us what this 1665th line should be? >> Maybe the 1665th directory has something special (a filename with >> >> spaces or non-ascii chars...) Yes, the next directory contains a filename with an iso-latin1 but non- ascii cha

[issue3143] development docs waste a lot of horizontal space on left nav bar

Changes by Roger Demetrescu <[EMAIL PROTECTED]>: -- nosy: +rdemetrescu ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list m

[issue3187] os.walk - strange bug

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: The original problem seems to come from some Unix platform, but this patch only handles two cases: - on win32, when the argument is a bytestring. - on OS/2. And in both cases, the default (utf-8) conversion seems wrong. Something like cp

[issue2459] speedup for / while / if with better bytecode

Χρήστος Γεωργίου (Christos Georgiou) <[EMAIL PROTECTED]> added the comment: A pointer to previous (minor) research: http://groups.google.com/group/comp.lang.python/browse_frm/thread/72505e3cb6d9cb1a/e486759f06ec4ee5 esp. after Terry Reedy's post -- nosy: +tzot

[issue3187] os.walk - strange bug

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: It seems the conversion to unicode strings (PyUnicode vs PyBytes) was not complete in os.listdir. See the attached patch. -- keywords: +patch Added file: http://bugs.python.org/file10719/oslistdir_string.patch

[issue3187] os.walk - strange bug

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: "he's giving a string"... the user simply called os.walk, which accepts strings AFAIK. We should discover what produced this bytestring. Does listdir() returns a mixed list of strings and bytes? -- resolution: invalid -> statu

[issue3187] os.walk - strange bug

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: It's failing because he's giving a string to bytes.startswith when it requires a byte string or such. -- nosy: +benjamin.peterson resolution: -> invalid status: open -> closed ___ Python tracke

[issue1284316] Win32: Security problem with default installation directory

Jason R. Coombs <[EMAIL PROTECTED]> added the comment: +1 on using "Program Files" by default. In addition to the points mentioned above, there are other considerations. In 64-bit platforms (Windows XP x64 and Vista 64-bit), programs are segmented by their binary compatibility (C:\Program Files

[issue3190] Pydoc should ignore __package__ attributes

New submission from Nick Coghlan <[EMAIL PROTECTED]>: Pydoc doesn't display the standard special attributes for packages and modules (__name__, __file__, __path__). It shouldn't display PEP 361's new __package__ attribute either. -- assignee: ncoghlan components: Library (Lib) messages:

[issue3186] bin(long) doesn't have a trailing 'L'

Mark Dickinson <[EMAIL PROTECTED]> added the comment: Ah. I missed this. Apologies. Sorry for the noise. -- resolution: -> invalid status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> ___

[issue3186] bin(long) doesn't have a trailing 'L'

Eric Smith <[EMAIL PROTECTED]> added the comment: See http://mail.python.org/pipermail/python-dev/2008-February/077062.html, where Guido endorses my approach to implementing bin() without the trailing L for longs. Note that he also agrees with not adding a __bin__ function, which was implemented

[issue3139] bytearrays are not thread safe

Changes by Amaury Forgeot d'Arc <[EMAIL PROTECTED]>: -- title: print is not thread safe -> bytearrays are not thread safe ___ Python tracker <[EMAIL PROTECTED]> ___ ___

[issue3177] implement os.startfile on posix and MacOSX

Changes by Giampaolo Rodola' <[EMAIL PROTECTED]>: -- nosy: +giampaolo.rodola ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-

[issue3187] os.walk - strange bug

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: Could you tell us what this 1665th line should be? Maybe the 1665th directory has something special (a filename with spaces or non-ascii chars...) Can you try with an older version of python? -- nosy: +amaury.forgeotdarc _

[issue3189] Py3k DeprecationWarning in difflib

Virgil Dupras <[EMAIL PROTECTED]> added the comment: It slipped out of my mind that performance was probably important for this module, so I ditched that nested get call and went if an if..else. Added file: http://bugs.python.org/file10718/difflib_py3k_deprecation2.diff ___

[issue3189] Py3k DeprecationWarning in difflib

New submission from Virgil Dupras <[EMAIL PROTECTED]>: When running with the -3 flag, difflib creates DeprecationWarnings. I attach a patch fixing them. There was a note in the code saying "DOES NOT WORK for x in a". However, after my changes, tests still pass, so I removed these notices. If s

[issue3140] str.format("{0:n}") poss. bug with setlocale()

Eric Smith <[EMAIL PROTECTED]> added the comment: Fixed in r64499 (trunk) and r64500 (py3k). I now get: >>> import locale >>> locale.setlocale(locale.LC_ALL, "en_US.UTF-8") 'en_US.UTF-8' >>> for x in (123,1234,12345,123456,1234567,12345678,123456789,1234567890,12345678900): ... print("[{0:>20n}

[issue3188] float('infinity') should be valid

New submission from Mark Dickinson <[EMAIL PROTECTED]>: 2.6 adds float('inf') and float('nan') as cross-platform ways to generate infinities and NaNs. The C99 standard (section 7.20.1.3, paragraph 3) specifies that 'infinity' (in any case, with optional preceding sign) should also be a valid

[issue3187] os.walk - strange bug

New submission from Helmut Jarausch <[EMAIL PROTECTED]>: The script below produces 1664 lines of output before it bails out with Traceback (most recent call last): File "WalkBug.py", line 5, in for Dir, SubDirs, Files in os.walk('/home/jarausch') : File "/usr/local/lib/python3.0/os.py", line

[issue3181] ConfigParsers are classic classes

Ari Makela <[EMAIL PROTECTED]> added the comment: New-style classes make object orientated programming considerably more convenient. For example one can use property() instead of __setitem__ et al. There's super(). This is, of course, not a serious problem and one can always implement a composite

[issue3186] bin(long) doesn't have a trailing 'L'

New submission from Mark Dickinson <[EMAIL PROTECTED]>: In Python 2.6, for a long n, hex(n) and oct(n) have a trailing 'L', while bin(n) does not: >>> hex(1L) '0x1L' >>> oct(1L) '01L' >>> bin(1L) '0b1' I'm guessing that this is intentional, and that the only reason hex(n) and oct(n) still hav

[issue3185] Documentation of time.time() differs from source documentation

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: I think you are misinterpreting what you are seeing. time.mktime returns seconds since the Epoch, in UTC, when passed broken-down local time. So that the result is the same as time.time() doesn't mean that time.time() returns "local unix seco