[issue1023290] proposed struct module format code addition

Mark Dickinson added the comment: See also issue #923643. -- nosy: +marketdickinson _ Tracker <[EMAIL PROTECTED]> _ ___ Python-bugs-l

[issue923643] long <-> byte-string conversion

Mark Dickinson added the comment: It seems to me that this issue is almost entirely subsumed by issue #1023290. I'm quite tempted to close this and direct further discussion there---personally, I'd support Josiah's proposed struct addition. Paul: if you're still listening after all this ti

[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.

Mark Dickinson added the comment: Raymond: > Were the new methods part of the spec update? If so that's great. Yes. See http://www2.hursley.ibm.com/decimal/damisc.html > If not, we need to take them out. We want zero API creep that isn't > mandated by the spec (no playing fast and loose w

[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.

Raymond Hettinger added the comment: Were the new methods part of the spec update? If so that's great. If not, we need to take them out. We want zero API creep that isn't mandated by the spec (no playing fast and loose with this module). __ Tracker <[EMAIL PROT

[issue1092502] Memory leak in socket.py on Mac OS X

Martey Dodoo added the comment: I am not sure that this is outdated. After running into memory errors trying to download messages with attachments using imaplib, I ran the example client and server. After iteration 357, there was a malloc error, just like etrepum suggested. I am using Mac OS X 1

[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.

Mark Dickinson added the comment: (About the latest patch): this all looks good to me. The comment that "Decimal provides no other public way to detect nan and infinity." is not true (though it once was). Decimal has public methods is_nan and is_infinite, added as part of updating to the m

[issue1869] Builtin round function is sometimes inaccurate for floats

New submission from Mark Dickinson: The documentation for the builtin round(x, n) says: "Values are rounded to the closest multiple of 10 to the power minus n." This isn't always true; for example: Python 2.6a0 (trunk:59634M, Dec 31 2007, 17:27:56) [GCC 4.0.1 (Apple Computer, Inc. build 5370

[issue1694] floating point number round failures under Linux

Mark Dickinson added the comment: I'm closing this as invalid. -- resolution: -> invalid status: open -> closed __ Tracker <[EMAIL PROTECTED]> __ _

[issue1868] threading.local doesn't free attrs when assigning thread exits

Changes by Christian Heimes: -- components: +Extension Modules priority: -> high versions: +Python 2.6, Python 3.0 __ Tracker <[EMAIL PROTECTED]> __ __

[issue1868] threading.local doesn't free attrs when assigning thread exits

New submission from Peter Fein: threading.local doesn't free attributes assigned to a local() instance when the assigning thread exits. See attached patch for _threading_local.py doctests. Per discussion with Crys and arkanes in #python, this may be an issue with PyThreadState_Clear / PyThread

[issue1621] Do not assume signed integer overflow behavior

Martin v. Löwis added the comment: > Btw I think we need an unsigned version of Py_ssize_t to fix this > problem cleanly. I am not sure if you would agree with me though. There is an unsigned version, it's called "size_t". __ Tracker <[EMAIL PROTECTED]>

[issue1621] Do not assume signed integer overflow behavior

Ismail Donmez added the comment: First stub at fixing overflows, regresses following tests : test_doctests.py test_locale.py test_long.py test_long_future.py test_optparse.py test_pickle.py test_str.py (crash) test_string.py (crash) test_unicode.py (crash) test_userstring.py (crash) test_xpickle

[issue1621] Do not assume signed integer overflow behavior

Changes by Ismail Donmez: Added file: http://bugs.python.org/file9210/overflow-error4.patch __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list maili

[issue1621] Do not assume signed integer overflow behavior

Christian Heimes added the comment: The -fwrapv doesn't look right. You aren't testing for -fwrapv at all ;) __ Tracker <[EMAIL PROTECTED]> __ ___ Python

[issue588825] unittest.py, better error message

Antoine Pitrou added the comment: The second proposal shouldn't be accepted as-is. If you compare two very long or undecipherable strings, you don't want them to appear in the failure message. -- nosy: +pitrou Tracker <[EMAIL PROTECTED]>

[issue1568] PATCH: Armin's attribute lookup caching for 3.0

Amaury Forgeot d'Arc added the comment: Yes, now the test suite runs without problem. The patch also contains a file "fastattr_test_py3k.py". It seems to perform some benchmark, but I'm not sure to understand its output. Is it meant to be added somewhere? Does it make sense to keep it as a unit

[issue1621] Do not assume signed integer overflow behavior

Guido van Rossum added the comment: Would you mind also adding patches for the places you think you can fix, and providing us with a list of places you need help with? O'm hoping that Greg or Christian can help reviewing these and committing them. Thanks much for your help BTW! -- keyw

[issue1621] Do not assume signed integer overflow behavior

Changes by Ismail Donmez: Added file: http://bugs.python.org/file9209/overflow-error3.patch __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list maili

[issue1353344] python.desktop

Changes by Antoine Pitrou: Added file: http://bugs.python.org/file9208/pycon.png _ Tracker <[EMAIL PROTECTED]> _ ___ Python-bugs-list mailing

[issue1621] Do not assume signed integer overflow behavior

Ismail Donmez added the comment: Yes it breaks compilation with gcc 4.3. Fixing these bugs are mostly s/int/unsigned int. But some parts of code need Python wisdom :/ New patch attached adressing your comment. Added file: http://bugs.python.org/file9207/overflow-error2.patch _

[issue1353344] python.desktop

Antoine Pitrou added the comment: I'm adding a French translation, and removing the "Application" category (which doesn't exist as per the freedesktop specification). Also, I think the Name is too long right now. "The Python programming language" or "Le langage de programmation Python" looks long

[issue1621] Do not assume signed integer overflow behavior

Guido van Rossum added the comment: Close, I'd like to keep the -fwrapv if -Wstrict-overflow isn't supported. Also, would checking this in mean we can't build with GCC 4.3 until those issues are all fixed? __ Tracker <[EMAIL PROTECTED]>

[issue1866] const arg for PyInt_FromString

Guido van Rossum added the comment: So how about submitting a patch *and* building everything from scratch and running all the unit tests to make sure this doesn't break anything? -- nosy: +gvanrossum priority: -> low __ Tracker <[EMAIL PROTECTED]>

[issue1621] Do not assume signed integer overflow behavior

Ismail Donmez added the comment: Replace -fwrapv with -Wstrict-overflow=3 -Werror=strict-overflow when supported. Guido, does this do what you wanted? Regards, ismail Added file: http://bugs.python.org/file9205/overflow-error.patch __ Tracker <[EMAIL PROTECTED]>

[issue1621] Do not assume signed integer overflow behavior

Guido van Rossum added the comment: An unsigned variant of Py_ssize_t would just be size_t -- that's a much older type than ssize_t. I don't think we need to invent a Py_ name for it. __ Tracker <[EMAIL PROTECTED]> _

[issue1621] Do not assume signed integer overflow behavior

Guido van Rossum added the comment: The proper thing to do here is to add -Werror=strict-overflow to the CFLAGS (*before* -Wall -- we should fix the position of -Wall!); this will turn all those spots into errors, forcing us to fix them, and alerting users who might be using a newer compiler th

[issue1836] 'weekly' rotating logging file rotation incorrect

Kathryn M Kowalski added the comment: I did not put suggested code in - walking through it and counting days on my fingers I don't think it works. If the desired rollover day is Tuesday (self.dayOfWeek = 1) and today is Tuesday (day = 1) then self.rolloverAt is the seconds to midnight as if d

[issue1867] patch for pydoc to work in py3k

Changes by Christian Heimes: -- components: +Library (Lib) -Documentation keywords: +easy, patch priority: -> normal type: -> behavior __ Tracker <[EMAIL PROTECTED]> __ _

[issue1867] patch for pydoc to work in py3k

New submission from Santiago Gala: Basically I'm finding to simple errors: * an iterable where it expects a list, I solved it using a simple list comprehension on the original iterable * it tries to write a string to the socket, I used "UTF-8" both in the Content-Type header and in the convers

[issue1621] Do not assume signed integer overflow behavior

Ismail Donmez added the comment: No I mean we need a new unsigned variant. Else we will have to cast it to unsigned for many overflow cases which is ugly. __ Tracker <[EMAIL PROTECTED]> __

[issue1621] Do not assume signed integer overflow behavior

Christian Heimes added the comment: I don't think we can make Py_ssize_t unsigned. On several occasions Python uses -1 as error flag or default flag. __ Tracker <[EMAIL PROTECTED]> __ _

[issue1621] Do not assume signed integer overflow behavior

Ismail Donmez added the comment: Btw I think we need an unsigned version of Py_ssize_t to fix this problem cleanly. I am not sure if you would agree with me though. __ Tracker <[EMAIL PROTECTED]> _

[issue1866] const arg for PyInt_FromString

New submission from phil: In PyInt_FromString(), please change the type of the first arg from char * to const char *. That is, of course, if the function indeed does not write to the string. (I took a quick look at the code; it doesn't appear to.) If the function does modify the string, it sho

[issue1621] Do not assume signed integer overflow behavior

Ismail Donmez added the comment: -Wstrict-overflow=5 is not valid afaik its 1-3, 3 for most verbose also you need a recent gcc 4.3 snapshot for best results, check your distribution for gcc-snapshot package. About the -Wall thing it seems to be a gcc bug, but for now workaround is easy :-) Rega

[issue1865] Bytes alias for 2.6

Christian Heimes added the comment: Applied in r60052. I'll run a svnmerge now and exclude the revision from the merge. -- resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> _

[issue1621] Do not assume signed integer overflow behavior

Christian Heimes added the comment: I still don't get additional error messages on the trunk. I've altered the configure.in file to include -Wstrict-overflow=5 after -Wall: gcc -pthread -c -fno-strict-aliasing -g -Wall -Wstrict-prototypes -Wstrict-overflow=5 -I. -IInclude -I./Include -DPy_BUI

[issue1865] Bytes alias for 2.6

Guido van Rossum added the comment: Looks like you forgot tokenize.py Make sure none of this gets merged into 3.0! -- nosy: +gvanrossum __ Tracker <[EMAIL PROTECTED]> __ _

[issue1621] Do not assume signed integer overflow behavior

Guido van Rossum added the comment: Thanks! Good catch about -Wall. I think I am now able to reproduce these results with gcc 4.2. These results, while much more disturbing regarding the state of our code base, at least restore my faith in GCC. :-) __ Tracker <[EM

[issue1621] Do not assume signed integer overflow behavior

Ismail Donmez added the comment: Problem was that -Wall at the end was resetting -Wstrict-overflow, so here is the current results for signed overflow warnings (python 2.5 branch SVN), a lot of them : Parser/acceler.c: In function 'fixstate': Parser/acceler.c:90: warning: assuming signed overflo

[issue1863] NameError with genexp in class scope

Georg Brandl added the comment: Amaury Forgeot d'Arc schrieb: > Well, I'm not sure that the genexpr can be considered as a "method", but > it is certainly a nested code block. Technically it is a method, that's why this happens. I added a note to the docs in r60051; closing this as "won't fix".

[issue1863] NameError with genexp in class scope

Facundo Batista added the comment: Yes, something was bad with my test. Now I have the same behaviour. Sorry for the noise. __ Tracker <[EMAIL PROTECTED]> __ __

[issue1865] Bytes alias for 2.6

New submission from Christian Heimes: As discussed on the ml. It adds a bytes builtin and syntax for b"" and br"". -- components: Interpreter Core files: trunk_bytes.patch keywords: patch messages: 60099 nosy: tiran priority: normal severity: normal status: open title: Bytes alias for 2.

[issue1857] subprocess.Popen.poll/__del__ API breakage

René Stadler added the comment: Yes, it works. __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/

[issue932563] logging: need a way to discard Logger objects

Vinay Sajip added the comment: LoggerAdapter class added to trunk. Documentation also updated. -- resolution: -> fixed status: open -> closed Tracker <[EMAIL PROTECTED]> _

[issue1694155] Python 2.5 installer ended prematurely

anatoly techtonik added the comment: It appears to be well known issue with MSI installer which is unable to handle subst'ed drives correctly. _ Tracker <[EMAIL PROTECTED]> _ ___

[issue215555] Parser crashes for deeply nested list displays

Guido van Rossum added the comment: Fine, submit a patch. Might as well open a new bug for the patch (referring to this one for background). Tracker <[EMAIL PROTECTED]>

[issue1222] locale.format bug if thousand separator is space (french separator as example)

Antoine Pitrou added the comment: Eric, your diagnostic looks right, format() gets confused when it tries to remove padding characters to account for the added thousands separators. It does not check that there were padding characters in the first place, and it assumes that the thousands separato

[issue1863] NameError with genexp in class scope

Amaury Forgeot d'Arc added the comment: Facundo, are your sure that your output starts from a fresh environment? I get: C:\Python25>python Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information.

[issue1863] NameError with genexp in class scope

Facundo Batista added the comment: Don't follow you: >>> class C: a = 42 list(a for _ in 'x') >>> Works here! (Python 2.5.1 on win32) -- nosy: +facundobatista __ Tracker <[EMAIL PROTECTED]> __

[issue1864] test_locale doesn't use unittest

Antoine Pitrou added the comment: Ok, here is an almost straight conversion of the original test_locale to unittest. Added file: http://bugs.python.org/file9202/locale_test.patch __ Tracker <[EMAIL PROTECTED]> __

[issue1864] test_locale doesn't use unittest

Antoine Pitrou added the comment: > A patch is welcome. I'll try to work on it in a few days. > Was the test covered by a GHOP task? Hmm, what is a "GHOP task"? __ Tracker <[EMAIL PROTECTED]> __

[issue1864] test_locale doesn't use unittest

Christian Heimes added the comment: A patch is welcome. Was the test covered by a GHOP task? -- nosy: +tiran priority: -> normal __ Tracker <[EMAIL PROTECTED]> __ ___

[issue1472] Small bat files to build docs on Windows

Christian Heimes added the comment: I've implemented Amaury's suggestions and also added a call to hhc.exe if the target is htmlhelp. The files was added in r60048 -- resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]>

[issue215555] Parser crashes for deeply nested list displays

Ralf Schmitt added the comment: Ofcouse the problem was not logging, but I wanted to "replay" those commands. This is where I got the error. Tracker <[EMAIL PROTECTED]>

[issue215555] Parser crashes for deeply nested list displays

Ralf Schmitt added the comment: Well, I've been a victim of this one yesterday in a real world example. I'm logging the repr of arguments to XMLRPC method calls and we happen to use nested lists, which where deep enough to overflow that stack. It's now 8 years later and I can live with the parse

[issue1864] test_locale doesn't use unittest

New submission from Antoine Pitrou: test_locale uses its own result printout and doesn't throw an exception when a test fails. It should be probably converted to unittest. -- components: Library (Lib) messages: 60085 nosy: pitrou severity: normal status: open title: test_locale doesn't u

[issue1222] locale.format bug if thousand separator is space (french separator as example)

Changes by Antoine Pitrou: -- versions: +Python 2.6 -Python 2.4 __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe

[issue1222] locale.format bug if thousand separator is space (french separator as example)

Antoine Pitrou added the comment: Ok, I manage to reproduce it on an Ubuntu box with both 2.5.2a0 and SVN trunk. IMO it's a bug since the expected behaviour would be to enforce the locale settings for number formatting. That's the whole purpose of locale.format() after all. (no to mention the dis

[issue1596321] KeyError at exit after 'import threading' in other thread

Christian Walther added the comment: > Is the bug avoided if you import threading first and use it instead of thread? Yes. The bug happens when the (first) import of threading and the call to Py_Finalize() happen in different threads. To reproduce the problem in pure Python, I therefore have

[issue1763] Winpath module - easy access to Windows directories like My Documents

Christian Heimes added the comment: Mark Hammond wrote: > I'm not sure why the approach of "load-em-all" is being taken. > Interestingly, SHGetFolderPathW is listed as deprecated, so I doubt that > list will grow too much, but the implementation as specified prevents > the user from using other