[issue3100] weakref subclass segfault
Adam Olsen [EMAIL PROTECTED] added the comment: Patch to add extra sanity checks to Py_INCREF (only if Py_DEBUG is set). If the refcount is 0 or negative if calls Py_FatalError. This should catch revival bugs such as this one a little more clearly. The patch also adds a little more checking to _Py_ForgetReference, so it's more likely to print an error rather than segfaulting. -- keywords: +patch Added file: http://bugs.python.org/file10614/python-incref-from-zero.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3100 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3095] multiprocessing initializes flags dict unsafely
Georg Brandl [EMAIL PROTECTED] added the comment: I think the easiest way is to just call AddObject after inserting the values. I fixed this, and the leaking BuildValue references, in r64223. -- nosy: +georg.brandl resolution: - fixed status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3095 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue3094 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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. -- nosy: +loewis ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3093 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue3095 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 also be appreciated. -- assignee: teoliphant messages: 68133 nosy: loewis, teoliphant severity: normal status: open title: global function _add_one_to_C versions: Python 2.6, Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3101 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 tracker [EMAIL PROTECTED] http://bugs.python.org/issue3100 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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, conversion_mode_errors, get_error_object, getentry, module_methods (there are more, but the other ones can be understood as being unambiguously prefixed, such as with CData, CField, StgDict). It would be good if these symbols either are changed to static, or get a proper Py/_Py prefix. -- assignee: theller messages: 68135 nosy: loewis, theller severity: normal status: open title: ctypes defines global symbols ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3102 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 every few runs, but I also got
(only three times in 40 or so runs so far):
9:57|[EMAIL PROTECTED]:~/c/py3k-svn make test TESTOPTS=-v test_mp
Failed to find the necessary bits to build these modules:
_gestalt
To find the necessary bits, look in setup.py in detect_modules() for the
module's name.
find ./Lib -name '*.py[co]' -print | xargs rm -f
./python -E -bb ./Lib/test/regrtest.py -v test_mp
test_mp
test_notify_all (test.test_mp.WithProcessesTestCondition) ... ok
test_notify_all (test.test_mp.WithThreadsTestCondition) ... ok
test_notify_all (test.test_mp.WithManagerTestCondition) ... ok
--
Ran 3 tests in 1.087s
OK
1 test OK.
CAUTION: stdout isn't compared in verbose mode:
a test that passes in verbose mode may fail without it.
./python -E -bb ./Lib/test/regrtest.py -v test_mp
test_mp
test_notify_all (test.test_mp.WithProcessesTestCondition) ... ok
test_notify_all (test.test_mp.WithThreadsTestCondition) ... ok
test_notify_all (test.test_mp.WithManagerTestCondition) ... Exception in
thread Thread-28:
Traceback (most recent call last):
File /home/paul/c/py3k-svn/Lib/threading.py, line 492, in
_bootstrap_inner
self.run()
File /home/paul/c/py3k-svn/Lib/threading.py, line 447, in run
self._target(*self._args, **self._kwargs)
File /home/paul/c/py3k-svn/Lib/test/test_mp.py, line 208, in f
cond.wait(timeout)
File /home/paul/c/py3k-svn/Lib/multiprocessing/managers.py, line
973, in wait
return self._callmethod('wait', (timeout,))
File /home/paul/c/py3k-svn/Lib/multiprocessing/managers.py, line
748, in _callmethod
raise convert_to_error(kind, result)
RuntimeError: cannot wait on un-aquired lock
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3088
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 if these could be made static, or get their own prefix. -- assignee: ghaering messages: 68137 nosy: ghaering, loewis severity: normal status: open title: sqlite defines a few global symbols. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3103 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue3098 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2912 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue839496] SimpleHTTPServer reports wrong content-length for text files
Gabriel Genellina [EMAIL PROTECTED] added the comment: As noted by Leo Jay in this message http://mail.python.org/pipermail/python-list/2008-June/495718.html this bug was supposedly fixed but it is still present. Looks like the patch was only applied to release24-maint, not to the trunk. Both the 2.5 and the 2.6 sources don't have the patch applied. 3.0 doesn't have this problem but probably it was fixed independently. -- nosy: +gagenellina versions: +Python 2.5, Python 2.6 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue839496 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue3098 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 memory error rather than fail silently only to screw up in another way? -- components: Interpreter Core messages: 68142 nosy: GreaseMonkey severity: normal status: open title: overzealous garbage collector (dict) type: behavior versions: Python 2.5 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3104 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 PROTECTED] http://bugs.python.org/issue3100 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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.group(1)) So, I would like to move forward with the regular expression from http://cygwin.com/ml/cygwin/2008-05/msg00622.html: (\d+\.\d+(\.(\d+))?([ab](\d+))?) Can we get a consensus? ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2234 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue3100 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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: +paulmelis ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3104 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 the weakrefs are being deleted, no callback should fire. Added file: http://bugs.python.org/file10616/weakref_cycle.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3100 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue1778443 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 16MB sounds
quite low.
--
nosy: +pitrou
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3104
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 behaviour is a reasonable proposition. -- nosy: +pitrou ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3079 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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.log_to_stderr(level=LOG_LEVEL) ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3088 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1407] [performance] Too many closed() checkings
Antoine Pitrou [EMAIL PROTECTED] added the comment: Is this issue still valid? -- nosy: +pitrou ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1407 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue1542308 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 traces back to synchronize.SemLock which calls into _multiprocessing.SemLock ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3088 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 [EMAIL PROTECTED] http://bugs.python.org/issue3104 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 tracker [EMAIL PROTECTED] http://bugs.python.org/issue2065 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3079 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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.buffer.write(b) will also check for self.buffer.closed, and there is not much code in-between. The only side-effect is the decoder state. -- nosy: +amaury.forgeotdarc ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1407 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue2065 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue3098 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 PROTECTED] http://bugs.python.org/issue3081 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue2912 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue3099 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 empty module. import con seems to block, it actually waits for the user to enter text and type ^Z. Then it prints to the console some bizarre text that looks like the content of a .pyc file: Python 2.5.3a0 (release25-maint, Jun 11 2008, 13:17:36) [MSC v.1200 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. import con ^Z a=1 b=2 c=3 ^Z │≥ c☺ @ s► d Z d☺ Z☺ d☻ S(♥ i☻ i♥ N(☻ t☺ bt☺ c(((s♠ con.py module☺ s☻ ♠☺[27520 refs] dir(con) ['__builtins__', '__doc__', '__file__', '__name__', 'b', 'c'] [27533 refs] ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3099 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 to: ... or not filter(None, [system, node, release, version, machine]): should work on all Python versions. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2912 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 tracker [EMAIL PROTECTED] http://bugs.python.org/issue2912 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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. :) Yeah, well... it's a hobby :-) We can probably bump that to Python 2.1 or even 2.3 after 2.6 is out. The main reason for keeping 1.5.2 compatibility was mxCGIPython which started platform.py in the first place. Since it turned out to be useful for all kinds of things, it's good to be able to backport any changes to installations still using older Python versions. The patches look OK now. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 13 2008) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2008-07-07: EuroPython 2008, Vilnius, Lithuania23 days to go Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2912 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue2912 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue3099 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 debug builds, import nul first tries stat(nul_d.pyd) which fails. It then tries stat(nul.py), which succeeds to return an empty file! Wh. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3099 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 exception. Check the code. Most of the time error is called without an exception having been raised. In one case it actually is called and swallows an exception that the code did raise. It would be preferable in my mind to always raise an exception. If you want, the default can be to catch them and ignore them as error() does now, but as it stands you can't raise anything more specific than OptParseError, and that's just a punt even though specific problems were detected by the code. Skip ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3079 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3100] weakref subclass segfault
Changes by Adam Olsen [EMAIL PROTECTED]: -- nosy: +jnoller ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3100 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 on those included with the Python 2.5.2 PCBuild release for windows in the svn Python25 maintenance trunk (http://svn.python.org/projects/python/branches/release25-maint/PCbuild/), should be placed in a new directory PCBuild8\_ssl. Once added to the parent solution file pcbuild.sln, the _ssl project will simply build if the normal instructions have been followed. *Changes* Since this is a change in location, both _ssl.mak and build_ssl.py have been altered to reflect the extra level of nesting. As a result, the #pragma comment(lib, Python25) in pyconfig.h did not work. In order to add the appropriate directory to the LIB path in _ssl.mak, build_py.py now takes an additional (second) command line parameter derived from visual studio's $(PlatformName). This is used to define an variable PLATFORM_NAME passed to _ssl.mak which is used to deduce the directory containing python25.lib. The accompanying _ssl.vcproj has been migrated from the Visual Studio 2003 vcproj file in PCBuild, and passes the additional $(PlatformName) parameter. _ssl.mak has also been adjusted to output a .pdb file and keep the root _ssl directory clean, copying existing behaviour for all the other projects. This has resulted in some ugly usage of special path splitting NMAKE syntax (grep for %|fF.obj) which doesn't work with the @ syntax. As a result the link stage has been split across several lines. Someone with a better knowledge of makefiles in general and NMAKE in particular can probably improve on this, but it does work, and is otherwise legible. Note that this sub-directory file structure is new in this release, and that the Python3k trunk seems to be reverting to the flat file structure. These additions are still helpful since they should just work out of the box, and allow people using the current recommended build of Python (2.5.2) to compile the ssl and hashlib modules. *Additional Details* Built on Windows XP SP2 with MSVS2005 SP1. Details appended to this message. Built against openssl-0.9.8h, which is later than the standard Python25 distribution. Note that the assembly file based build of openssl-0.9.8h, which is triggered by build_ssl.py, currently has a small bug. See http://www.mail-archive.com/[EMAIL PROTECTED]/msg24059.html This is easily fixed by the following one line change to openssl-0.9.8h\crypto\perlasm\x86ms.pl In this file, the line 273 containing $extra should be removed to be able to compile the generated assembly files. If an openssl build has been attempted prior to this step, delete all out32 and tmp32 directories under openssl-0.9.8h *Code and Patch* Attached is a zip file containing the altered files, and a patch generated using cygwin's diff run with the command line -uarN. The patch can be applied by: cd PCBuild8 mkdir _ssl cd _ssl patch -u -p1 [wherever_the_patch_file_is_downloaded_to]\_ssl.patch *Tested* Compiles and imports fine with Release and Debug builds. Other builds (AMD, Itanium) untested. *Build Details* Compiled against openssl-0.9.8h Microsoft Visual Studio 2005 Version 8.0.50727.762 (SP.050727-7600) Microsoft .NET Framework Version 2.0.50727 SP1 Installed Edition: Professional Microsoft Visual C++ 2005 77626-009-007-41042 Microsoft Visual C++ 2005 Microsoft Visual Studio 2005 Professional Edition - ENU Service Pack 1 (KB926601) -- components: Build, Windows files: Python252-PCBuild8-_ssl.zip messages: 68172 nosy: MarkE severity: normal status: open title: Python 2.5.2 Windows Source Distribution missing Visual Studio 2005 ssl build files type: compile error versions: Python 2.5 Added file: http://bugs.python.org/file10621/Python252-PCBuild8-_ssl.zip ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3105 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 raised again. (The possibility of __del__ makes me worry, but it *looks* okay.) gcmodule.c has an inline copy of handle_callbacks. Is it possible a collection could have the same problem we're fixing here? Minor nit: you're asserting cbcalled, but you're not using the generic callback, so it's meaningless. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3100 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 pybench, this is the patched version and other is vanilla py3k): Test minimum run-timeaverage run-time thisother diffthisother diff --- CompareFloats: 182ms 173ms +5.4% 182ms 176ms +3.4% CompareFloatsIntegers: 238ms 232ms +2.3% 242ms 236ms +2.5% CompareIntegers: 237ms 277ms -14.4% 237ms 280ms -15.2% CompareInternedStrings: 163ms 257ms -36.7% 163ms 258ms -36.7% CompareLongs: 137ms 160ms -14.5% 137ms 162ms -15.6% CompareStrings: 149ms 170ms -12.1% 154ms 170ms -9.5% --- Totals: 1105ms 1268ms -12.9% 1115ms 1281ms -13.0% -- components: Interpreter Core files: cpms.patch keywords: patch messages: 68174 nosy: pitrou severity: normal status: open title: speedup some comparisons type: performance versions: Python 3.0 Added file: http://bugs.python.org/file10622/cpms.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3106 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue3100 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue3048 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue3098 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 influences sys.maxunicode. Thus, it currently is possible to derive Py_UNICODE_SIZE from sys.maxunicode. But it takes some indirections. So here are 2 possible patches, one which exposes Py_UNICODE_SIZE via _testcapi and one which assumes that sys.maxunicode reflects UCS-X settings. Since I am a fairly new Python developer and the new 4-eyes-per-commit policy for the beta phase, please decide which patch should be applied. Added file: http://bugs.python.org/file10624/Py_UNICODE.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3098 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue3098 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 exact value of 0x10 for UCS-4 - it's possible that the Unicode consortium decides to add more planes to the Universal Character Set... (though not likely). The above comparison is good enough to detect the number of bytes in a single code point, though. -- nosy: +lemburg ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3098 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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]
http://bugs.python.org/issue3098
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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). However, Py_UNICODE.patch is wrong in that it uses Py_UNICODE_SIZE rather than sizeof(Py_UNICODE). Py_UNICODE_SIZE itself is always either 2 or 4. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3098 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 than 32 bits; although the latter is probably quite rare (64-bit platforms are usually either LP64 or LLP64). AFAIK, only Crays have this problem, but apart from that: I'd consider it a bug if sizeof(Py_UCS4) != 4. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3098 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 (untested): #if SIZEOF_INT == 4 typedef unsigned int Py_UCS4; #elif SIZEOF_LONG == 4 typedef unsigned long Py_UCS4; #else #error Could not find a 4-byte integer type for Py_UCS4, aborting #endif (of course we could also try harder to find an appropriate type, but I'm no specialist in C integer variations) ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3098 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 how could this information can be retrieved in py3k?
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3098
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue3098 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue3098 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue839496 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue3100 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 tracker [EMAIL PROTECTED] http://bugs.python.org/issue3100 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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.4.0, dynamically linked (uses shared libs), not stripped [EMAIL PROTECTED] bin]$ uname -a Linux gossamer.ambric.local 2.4.21-40.ELsmp #1 SMP Wed Mar 15 13:46:01 EST 2006 x86_64 x86_64 x86_64 GNU/Linux [EMAIL PROTECTED] bin]$ cat /etc/redhat-release CentOS release 3.6 (Final) -- components: Demos and Tools messages: 68188 nosy: hushp1pt severity: normal status: open title: memory leak in make test (in test list), 2.5.2 not 2.5.1, Linux 64bit type: resource usage versions: Python 2.5 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3107 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 exceptions generated by Python modules and exceptions generated by C modules (especially when some parts are written in C and others in Python, e.g. the io library). Unimplemented are the modifications in exception reporting. -- components: Interpreter Core files: context.patch keywords: patch messages: 68189 nosy: pitrou severity: normal status: open title: Implicit exception chaining (PEP 3134) type: behavior versions: Python 3.0 Added file: http://bugs.python.org/file10626/context.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3108 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue2632 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue2632 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue3108 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue3107 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue3100 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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' Great Expectations 17 times in a text file and then parsing it doesn't show this problem for some weird reason. I have python 2.5.1. Added file: http://bugs.python.org/file10628/markov.py ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3104 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3100] weakref subclass segfault
Changes by Benjamin Peterson [EMAIL PROTECTED]: ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3100 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
