[issue3088] test_multiprocessing hangs on OS X 10.5.3

Ismail Donmez <[EMAIL PROTECTED]> added the comment: Seems to work fine for me now with latest py3k branch. ___ Python tracker <[EMAIL PROTECTED]> ___ __

[issue3100] weakref subclass segfault

Changes by Benjamin Peterson <[EMAIL PROTECTED]>: ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list mailing list Unsubscribe: http

[issue3109] test_multiprocessing seems fragile

Changes by Benjamin Peterson <[EMAIL PROTECTED]>: -- nosy: +jnoller ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list mail

[issue3104] overzealous garbage collector (dict)

GreaseMonkey <[EMAIL PROTECTED]> added the comment: I mean that it actually *drops* values, not *overwrites* them. I have attached the script which demonstrates this quirk in the garbage collector (it also doubles as a library). The original text file was an IRC log. Shoving Charles Dickens' "G

[issue3100] weakref subclass segfault

Adam Olsen <[EMAIL PROTECTED]> added the comment: Another minor nit: "if(current->ob_refcnt > 0)" should have a space after the "if". Otherwise it's looking good. ___ Python tracker <[EMAIL PROTECTED]> __

[issue3109] test_multiprocessing seems fragile

New submission from Antoine Pitrou <[EMAIL PROTECTED]>: I had the following intermittent failure under py3k: [...] test_multiprocessing Process Process-24: Traceback (most recent call last): File "/home/antoine/py3k/context/Lib/multiprocessing/process.py", line 237, in _bootstrap self.run(

[issue3107] memory leak in make test (in "test list"), 2.5.2 not 2.5.1, Linux 64bit

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: How do you know that there is a memory leak? -- nosy: +loewis ___ Python tracker <[EMAIL PROTECTED]> ___

[issue3108] Implicit exception chaining (PEP 3134)

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: Guido, thanks for your comments. Here is a new patch addressing them. Added file: http://bugs.python.org/file10627/context2.patch ___ Python tracker <[EMAIL PROTECTED]> _

[issue2632] performance problem in socket._fileobject.read

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: Well, it's a release blocker for 2.5.3. -- nosy: +benjamin.peterson ___ Python tracker <[EMAIL PROTECTED]> ___

[issue2632] performance problem in socket._fileobject.read

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: If it's fixed in 2.6 and 3.0, it shouldn't be release blocker anymore, now should it? ___ Python tracker <[EMAIL PROTECTED]> ___ __

[issue3108] Implicit exception chaining (PEP 3134)

New submission from Antoine Pitrou <[EMAIL PROTECTED]>: This patch implements implicit except chaining (__context__) as per PEP 3134, or not quite. The difference is that PyErr_Set* functions do set the __context__ attribute, otherwise I think it would make an annoying discrepancy between excepti

[issue3107] memory leak in make test (in "test list"), 2.5.2 not 2.5.1, Linux 64bit

New submission from Tony Wallace <[EMAIL PROTECTED]>: [EMAIL PROTECTED] Python-2.5.1]$ ./configure --prefix=/home/tony/root/usr/local/python-2.5.2 --enable-shared --enable-static [EMAIL PROTECTED] bin]$ file python python: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.

[issue3100] weakref subclass segfault

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: > you're asserting cbcalled, but you're not using the generic callback, > so it's meaningless. The new patch corrects this Added file: http://bugs.python.org/file10625/weakref_cycle.patch ___ Python

[issue3100] weakref subclass segfault

Changes by Amaury Forgeot d'Arc <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file10616/weakref_cycle.patch ___ Python tracker <[EMAIL PROTECTED]> ___ _

[issue839496] SimpleHTTPServer reports wrong content-length for text files

Changes by Terry J. Reedy <[EMAIL PROTECTED]>: -- resolution: accepted -> status: closed -> open ___ Python tracker <[EMAIL PROTECTED]> ___ _

[issue3098] sys.sizeof test fails with wide unicode

Robert Schuppenies <[EMAIL PROTECTED]> added the comment: Found it, thanks. Wrong use of grep :| ___ Python tracker <[EMAIL PROTECTED]> ___ ___ P

[issue3098] sys.sizeof test fails with wide unicode

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: I believe Py_UNICODE_TYPE is set be configure in pyconfig.h. ___ Python tracker <[EMAIL PROTECTED]> ___

[issue3098] sys.sizeof test fails with wide unicode

Robert Schuppenies <[EMAIL PROTECTED]> added the comment: I think you're right that sizeof(Py_UNICODE) is the correct value to use. But could you please explain to me how PY_UNICODE_TYPE is set, I cannot find it. Also, len(u'\0'.encode('unicode-internal')) does not work for Py3.0. Any suggestion

[issue3098] sys.sizeof test fails with wide unicode

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: Le vendredi 13 juin 2008 à 20:18 +, Marc-Andre Lemburg a écrit : > AFAIK, only Crays have this problem, but apart from that: I'd consider > it a bug if sizeof(Py_UCS4) != 4. Perhaps a #error can be added to that effect? Something like (un

[issue3098] sys.sizeof test fails with wide unicode

Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment: On 2008-06-13 21:56, Antoine Pitrou wrote: > Antoine Pitrou <[EMAIL PROTECTED]> added the comment: > > Hmm, so it seems that in some UCS4 builds, sizeof(Py_UNICODE) could end > up being more than 4 if the native int type is itself larger

[issue3098] sys.sizeof test fails with wide unicode

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: Hmm, so it seems that in some UCS4 builds, sizeof(Py_UNICODE) could end up being more than 4 if the native int type is itself larger than 32 bits; although the latter is probably quite rare (64-bit platforms are usually either LP64 or LLP64).

[issue3098] sys.sizeof test fails with wide unicode

Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment: BTW: Here's another trick you can use: print 'sizeof(Py_UNICODE) =', len(u'\0'.encode('unicode-internal')) (for Py2.x) ___ Python tracker <[EMAIL PROTECTED]> ___

[issue3098] sys.sizeof test fails with wide unicode

Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment: It's actually very easy: Py_UNICODE is a 2-byte value for UCS-2 builds and 4 byte value for UCS-4 builds of Python. print ((sys.maxunicode < 66000) and 'UCS2' or 'UCS4') tells you which one you have. Note that you should *not* use the

[issue3098] sys.sizeof test fails with wide unicode

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: Personally, I prefer the one with _testcapi.Py_UNICODE_SIZE because it is safe against future changes, but wait for someone else's opinion. ___ Python tracker <[EMAIL PROTECTED]>

[issue3098] sys.sizeof test fails with wide unicode

Robert Schuppenies <[EMAIL PROTECTED]> added the comment: sys.maxunicode is well defined to be either 0x for UCS-2 or 0x10 for UCS-4 (see PyUnicode_GetMax). Py_UNICODE_SIZE is set in pyconfig.h to be either 2 or 4 during configuration. When >= 4, Py_UNICODE_WIDE is set which again influe

[issue3098] sys.sizeof test fails with wide unicode

Changes by Robert Schuppenies <[EMAIL PROTECTED]>: -- keywords: +patch Added file: http://bugs.python.org/file10623/maxunicode.patch ___ Python tracker <[EMAIL PROTECTED]> ___

[issue3048] getsizeof incorrect for Unicode strings

Robert Schuppenies <[EMAIL PROTECTED]> added the comment: Fixed in r64066. -- resolution: -> fixed status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> ___ __

[issue3100] weakref subclass segfault

Adam Olsen <[EMAIL PROTECTED]> added the comment: Ahh, it seems gcmodule already considers the weakref to be reachable when it calls the callbacks, so it shouldn't be a problem. ___ Python tracker <[EMAIL PROTECTED]>

[issue3106] speedup some comparisons

New submission from Antoine Pitrou <[EMAIL PROTECTED]>: This patch is an experiment in making faster some of the most common comparisons (str vs. str, int vs. int). I don't know if it may bring noticeable speedups in real-world situations, but here are the synthetic benchmark numbers (from pybenc

[issue3100] weakref subclass segfault

Adam Olsen <[EMAIL PROTECTED]> added the comment: Well, my attempt at a patch didn't work, and yours does, so I guess I have to support yours. ;) Can you review my python-incref-from-zero patch? It verifies the invariant that you need, that once an object hits a refcount of 0 it won't get raise

[issue3105] Python 2.5.2 Windows Source Distribution missing Visual Studio 2005 ssl build files

New submission from Mark English <[EMAIL PROTECTED]>: *Problem* The directory structure of PCBuild8 differs from PCBuild in that each project has its own subdirectory. There is no subdirectory for _ssl, and the files that would belong in it are also omitted. *Solution* The attached files, based

[issue3100] weakref subclass segfault

Changes by Adam Olsen <[EMAIL PROTECTED]>: -- nosy: +jnoller ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list mailing lis

[issue3079] sys.exit() called from optparse - bad, bad, bad

Skip Montanaro <[EMAIL PROTECTED]> added the comment: Georg> I agree with Antoine that the standard behavior is what you want in most Georg> simple command-line scripts. Georg> It's easy enough to replace the parser's exit function to just print the Georg> message, or raise an excep

[issue3099] On windows, "import nul" always succeed

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: OK, I think I got is now. The difference is between debug and release builds. Explanation: - in release build, "import nul" calls stat("nul.pyd") which succeeds. It then tries LoadLibrary("nul.pyd"), which fails with a DLL error. - in d

[issue3099] On windows, "import nul" always succeed

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: I was wrong. It seems that an installed python works correctly, but a python running from its build directory has the problem. ___ Python tracker <[EMAIL PROTECTED]>

[issue2912] let platform.uname try harder

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: Ok. I applied the patch in r64233. -- resolution: -> fixed status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> _

[issue2912] let platform.uname try harder

Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment: On 2008-06-13 16:59, Benjamin Peterson wrote: > Benjamin Peterson <[EMAIL PROTECTED]> added the comment: > > Wow, I really admire you for keeping it compatible with Python 1.5. As > you may have noticed, I'm addicted to new feature. :) Y

[issue2912] let platform.uname try harder

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: Wow, I really admire you for keeping it compatible with Python 1.5. As you may have noticed, I'm addicted to new feature. :) Added file: http://bugs.python.org/file10620/platform4.diff ___ Python tracke

[issue2912] let platform.uname try harder

Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment: On 2008-06-13 16:20, Benjamin Peterson wrote: > Benjamin Peterson <[EMAIL PROTECTED]> added the comment: > > Ok. I ran it through reindent.py and removed the True and False. Thanks, but the all() is still there :-) You can change that t

[issue3099] On windows, "import nul" always succeed

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: Sorry, I was not clear. With python 2.5.2, "import nul" correctly raises ImportError, even if the error message is slightly misleading. With a recent release25-maint (and all other branches), "import nul" does succeed, and creates an em

[issue3099] On windows, "import nul" always succeed

Georg Brandl <[EMAIL PROTECTED]> added the comment: The title is misleading -- if what you show is correct then "import nul" doesn't succeed :) -- nosy: +georg.brandl ___ Python tracker <[EMAIL PROTECTED]> __

[issue2912] let platform.uname try harder

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: Ok. I ran it through reindent.py and removed the True and False. Added file: http://bugs.python.org/file10619/platform3.diff ___ Python tracker <[EMAIL PROTECTED]> ___

[issue3081] Py_(X)SETREF macros

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment: A comment on the patch: Since object.h may be included from C++ extensions, you should not use a C++ keyword "new" as a variable name. -- nosy: +belopolsky ___ Python tracker <[EMAIL PROTEC

[issue3098] sys.sizeof test fails with wide unicode

Georg Brandl <[EMAIL PROTECTED]> added the comment: It is true that sys.maxunicode reflects whether the build is using UCS-2 or UCS-4; however, the size of Py_UNICODE is not fixed by that, look at unicodeobject.h. (Though I don't think we have platforms that actually *do* use sizes other than 2

[issue3098] sys.sizeof test fails with wide unicode

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: Do you really need to expose Py_UNICODE_SIZE? There is already sys.maxunicode, unless I'm missing something. -- nosy: +pitrou ___ Python tracker <[EMAIL PROTECTED]>

[issue2065] trunk version does not compile with vs8 and vc6

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: > Probably need to add _multiprocessing module, but not done yet. Yes, and I also forgot to "svn add" the new .vcproj in VS8.0 :-( ___ Python tracker <[EMAIL PROTECTED]>

[issue1407] [performance] Too many closed() checkings

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: I reproduce almost the same output. "function.closed" often come in pair, because TextIOWrapper.closed is a property which delegates to self.buffer.closed I think that the first check in TextIOWrapper.write() is not necessary: self.buff

[issue3079] sys.exit() called from optparse - bad, bad, bad

Georg Brandl <[EMAIL PROTECTED]> added the comment: I agree with Antoine that the standard behavior is what you want in most simple command-line scripts. It's easy enough to replace the parser's exit function to just print the message, or raise an exception. -- nosy: +georg.brandl

[issue2065] trunk version does not compile with vs8 and vc6

Hirokazu Yamamoto <[EMAIL PROTECTED]> added the comment: Thank you for commit. I ziped patch for remaining issue. # Probably need to add _multiprocessing module, but not done yet. Added file: http://bugs.python.org/file10618/ocean-remaining.zip ___ Python tra

[issue3104] overzealous garbage collector (dict)

Georg Brandl <[EMAIL PROTECTED]> added the comment: You'll have to produce a test case for this "dropping" -- otherwise I don't believe that 16 MB cause *any* memory problems at all. -- nosy: +georg.brandl status: open -> pending ___ Python tracker <[

[issue3088] test_multiprocessing hangs on OS X 10.5.3

Jesse Noller <[EMAIL PROTECTED]> added the comment: I also isolated the test(s) like Paul did, and it looks like a semi- consistent lock up in: File "/root/py/python-3000/Lib/multiprocessing/queues.py", line 337, in get racquire() This is running only the test_event test. The racquire tra

[issue1542308] Nested finally in generators don't follow PEP 342

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: Is it useful to keep this bug open? Does it correspond to a real-world use case? -- nosy: +pitrou ___ Python tracker <[EMAIL PROTECTED]> __

[issue1407] [performance] Too many closed() checkings

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: Is this issue still valid? -- nosy: +pitrou ___ Python tracker <[EMAIL PROTECTED]> ___ ___

[issue3088] test_multiprocessing hangs on OS X 10.5.3

Jesse Noller <[EMAIL PROTECTED]> added the comment: FWIW: In order to boost the logging level within the test(s) do the following: Search for LOG_LEVEL, set it to: LOG_LEVEL=util.SUBDEBUG And then in the main() replace: multiprocessing.get_logger().setLevel(LOG_LEVEL) With: multiprocessing

[issue3079] sys.exit() called from optparse - bad, bad, bad

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: The current behaviour is useful in that most of time, it is convenient to let OptionParser display a standard error message and bail out. However, having an attribute on the OptionParser object (e.g. exit_on_errors) to be able to change this b

[issue3104] overzealous garbage collector (dict)

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: Are you sure the keys for those list objects aren't just equal to others you insert in the dict? Witness: >>> d = {} >>> d[1] = 'a' >>> d {1: 'a'} >>> d[1.0] = 'b' >>> d {1: 'b'} I'm not sure what the memory limit is for dict objects, but 1

[issue1778443] robotparser.py fixes

Aristotelis Mikropoulos <[EMAIL PROTECTED]> added the comment: Sure. Added file: http://bugs.python.org/file10617/robotparser.py.patch ___ Python tracker <[EMAIL PROTECTED]> ___ ___

[issue3100] weakref subclass segfault

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: A new version of the patch, which tests the case of multiple weakrefs on the same object, that get deleted together: tp_dealloc of one weakref calls tp_dealloc of the second weakref, which calls tp_dealloc of the referenced object. Since

[issue3104] overzealous garbage collector (dict)

Paul Melis <[EMAIL PROTECTED]> added the comment: What do you mean with ">16MB"? Is that the total size of all data held by the dictionary (and if so, how did you measure this)? How many keys are in the dictionary? And what indication do you have that elements are being dropped? -- nosy:

[issue3100] weakref subclass segfault

Changes by Amaury Forgeot d'Arc <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file10615/weakref_cycle.patch ___ Python tracker <[EMAIL PROTECTED]> ___ _

[issue2234] cygwinccompiler.py fails for latest MinGW releases.

Jason Tishler <[EMAIL PROTECTED]> added the comment: cygwinccompiler.py only uses the first group: $ fgrep group cygwinccompiler.py gcc_version = StrictVersion(result.group(1)) ld_version = StrictVersion(result.group(1)) dllwrap_version = StrictVersion(result.

[issue3100] weakref subclass segfault

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: It seems enough to simply skip deleted weakrefs in PyObject_ClearWeakRefs. Here is a tentative patch. Added file: http://bugs.python.org/file10615/weakref_cycle.patch ___ Python tracker <[EMAIL PROTE

[issue3104] overzealous garbage collector (dict)

New submission from GreaseMonkey <[EMAIL PROTECTED]>: When filled with a massive database (>16MB, i'm not sure how large it's meant to be), the dict object appears to mysteriously drop objects off the face of the earth (in this case list objects). Wouldn't it be more appropriate to splurt out a m

[issue3098] sys.sizeof test fails with wide unicode

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: I'm sure there wasn't any a few months ago. -- nosy: +amaury.forgeotdarc ___ Python tracker <[EMAIL PROTECTED]> ___

[issue839496] SimpleHTTPServer reports wrong content-length for text files

Gabriel Genellina <[EMAIL PROTECTED]> added the comment: As noted by Leo Jay in this message this bug was supposedly fixed but it is still present. Looks like the patch was only applied to release24-maint, not to the trunk. B

[issue2912] let platform.uname try harder

Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment: There are two patches. Which one do you want me to look at ? Note that platform.py should stay Python 1.5.2 compatible, ie. no new builtins, no True/False. The second patch also appears to mix tabs/spaces. __

[issue3098] sys.sizeof test fails with wide unicode

Robert Schuppenies <[EMAIL PROTECTED]> added the comment: Are they any buildbots running with the "--enable-unicode=ucs4" option? Just curious. ___ Python tracker <[EMAIL PROTECTED]> ___ __

[issue3103] sqlite defines a few global symbols.

New submission from Martin v. Löwis <[EMAIL PROTECTED]>: While most global symbols in the _sqlite3 module use a sqlite_ or _sqlite_ prefix, some don't: _enable_callback_tracebacks, converters, microprotocols_adapt, microprotocols_add, psyco_adapters, psyco_microprotocols_adapt. It would be good

[issue3088] test_multiprocessing hangs on OS X 10.5.3

Paul Melis <[EMAIL PROTECTED]> added the comment: I made a copy of test_multiprocessing.py (to test_mp.py) and basically removed all test classes, except _TestCondition. In it, I commented all test methods except test_notify_all. When run with make test TESTOPTS="-v test_mp" there's the lockups e

[issue3102] ctypes defines global symbols

New submission from Martin v. Löwis <[EMAIL PROTECTED]>: ctypes defines a number of global symbols which aren't namespace-prefixed, such as AllocFunctionCallback, FreeClosure, GetType, IsSimpleSubType, MallocClosure, _AddTraceback, _CallProc, alloc_format_string, conversion_mode_encoding, convers

[issue3100] weakref subclass segfault

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: All the versions I tried (2.4, 2.5, 2.6, 3.0) crash with the given script -- components: +Interpreter Core -Extension Modules nosy: +amaury.forgeotdarc versions: +Python 2.5 ___ Python tracke

[issue3101] global function _add_one_to_C

New submission from Martin v. Löwis <[EMAIL PROTECTED]>: abstract.c defines two functions _add_one_to_C and _add_one_to_F. These apparently must be global, as memoryobject.c references them. Therefore, they should get a Py or _Py prefix. A short comment for what these functions actually do would

[issue3095] multiprocessing initializes flags dict unsafely

Adam Olsen <[EMAIL PROTECTED]> added the comment: Aww, that's cheating. (Why didn't I think of that?) ___ Python tracker <[EMAIL PROTECTED]> ___ ___

[issue3093] Namespace polution from multiprocessing

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: Alternatively, I think the _multiprocessing module should be rewritten to use a single C file only, and make all symbols except its init function static. I agree with Adam that the current code needs to be fixed, one way or the other. -

[issue3094] By default, HTTPSConnection should send header "Host: somehost" instead of "Host: somehost:443"

Senthil <[EMAIL PROTECTED]> added the comment: Yes, you are correct. I misunderstood the issue and the patch. Patch seems good to fix that. Sorry for the confusion and thank you. ___ Python tracker <[EMAIL PROTECTED]> __