Re: [Python-Dev] I'm not getting email from SF when assigned a bug/patch
Fredrik Lundh wrote: If you would rather contribute by collecting a list of possible trackers along with who will maintain it, then please do. I am not going to dive into that quite yet, but if you want to parallelize the work needed then I would appreciate the help. that is what I expected the PSF infrastructure committee to do (I hope you're not the only one in that committee?); it's a bit disappointing to hear that we're still stuck on the SF export issue. (wasn't there someone with backchannel access to the SF data ?) Yes. We found a way to export all data (except for file attachments), through a different exporter. This gives all data, unfortunately, it is ill-formed XML ( is not properly entity-referenced sometimes). Anybody who wants to work with these data, please let me know; I made a snapshot a few days ago. The backchannel access to SF data was actually someone different: he experimented with the existing export, confirmed the problem, promised to talk to Paul Moore about that, and referred us to the other XML exporter as a work-around (that one allows to export 500 items at a time). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Renaming sqlite3
I just tried creating a pysqlite VS project, and ran into a naming conflict: the Windows DLL is called sqlite3.dll. So if it is on sys.path import sqlite3 might find the DLL, instead of finding the package. Python then finds that there is no entry point in sqlite3, and raises an ImportError. I see three options: 1. rename sqlite3 again 2. link sqlite3 statically into _sqlite3.pyd 3. stop treating .DLL files as extension modules I'm actually leaning towards option 3: what is the rationale for allowing Python extension modules to be named .DLL? Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] SF #1462700 - Errors in PCbuild
Discovered a couple of minor errors in pcbuild.sln and pythoncore.vsproj while working out how to compile 2.5 on Windows using the VS C++ Toolkit for the bug day (no Visual Studio at home). FWIW, I eventually ended up using Nant (using the solution task). Nant couldn't build 2.5 without the fixes - basically, _ctypes_test didn't have any dependencies, and so was being built first. And the GUIDs for pythoncore were different between pcbuild.sln and pythoncore.vsproj. I've attached the fix to the bug report. Tim Delaney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] outstanding items for 2.5
I updated the PEP to include owners. If this message is sent directly to you, you are an owner. http://www.python.org/dev/peps/pep-0356/ There are still some items without owners as I don't know who will be leading the charge to get some of the modules in the stdlib. If we don't have anyone pushing them, they won't go in. If they are going in, they should be committed soon after alpha1 is out the door. Please don't rush to get them in before the alpha, unless you're absolutely sure it won't screw things up. Review the PEP and let me know what needs to be changed. If your pet project isn't already in the PEP, assume it has been deferred until 2.6. Also, now would be a good time to see if you have any bugs/patches assigned to you: http://sourceforge.net/my/tracker.php Cheers, n ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] SF:1463370 add .format() method to str and unicode
From discussion on python-3000, it occured to me that this shouldn't break anything. This patch adds a .format() method to the string and unicode types. SF:1463370 -- Crutcher Dunnavant [EMAIL PROTECTED] littlelanguages.com monket.samedi-studios.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] String formating in python 3000
On Sun, Apr 02, 2006, Crutcher Dunnavant wrote: But I have some questions about this for python 3000. Please use the python-3000 list for questions like this. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ Look, it's your affair if you want to play with five people, but don't go calling it doubles. --John Cleese anticipates Usenet ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I'm not getting email from SF when assigneda bug/patch
On 4/2/06, Fredrik Lundh [EMAIL PROTECTED] wrote: Martin v. Löwis wrote: Yes. We found a way to export all data (except for file attachments), through a different exporter. This gives all data, unfortunately, it is ill-formed XML ( is not properly entity-referenced sometimes). so why didn't Brett know about this ? I knew the export existed, but my understanding was that it was ill-formed as in truncated since it didn't have a close tag on the outermost XML tag. So I thought that the data was incomplete and thus the dump was mostly useless. Martin got another dump, and I asked if it contained all the data but just with a bad format, and he said he wasn't sure. That's why I was still planning on possibly writing a scraper if we didn't validate that the dump had all the tracker items. Anybody who wants to work with these data, please let me know; I made a snapshot a few days ago. the scraper I wrote in response to Brett's post has successfully down- loaded 80% of the data at this very moment (including attachments), so I'll probably keep playing with that one instead... I'll reply to this in the other email you sent. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r43545 - in python/trunk: Doc/lib/libcalendar.tex Lib/calendar.py
Tim Peters wrote: [Tim, gripes about ...] Author: walter.doerwald Date: Sat Apr 1 22:40:23 2006 New Revision: 43545 Modified: python/trunk/Doc/lib/libcalendar.tex python/trunk/Lib/calendar.py Log: Make firstweekday a simple attribute instead of hiding it behind a setter and a getter. [Walter][ This is because in 2.4 there where no Calendar objects and firstweekday was only setable and getable via module level functions. I didn't realize that, of course blush. Skipping the rest ;-), then, it would be best to make firstweekday a property on the new base class. ... The only thing lost is the range check in the setter. Which isn't a good thing to lose. It's not good that the current Calendar constructor skips that sanity check either (errors should never pass silently). I've changed calendar so that firstweekday is only used modulo 7 everywhere (There was only one spot missing, all other cases used firstweekday modulo 7 anyway. ... Simple attribute access looks much more Pythonic to me than setters and gettes (especially as the attributes of subclasses are simple attributes). Or are you talking about the Calendar class itself? Yes, it would be best if Calendar had a property, so that sanity checks were performed when setting `firstweekday`, and also if the Calendar constructor performed that sanity check (which could happen by magic if `firstweekday` were a property). Range checks should no longer be neccessary, as any value works now. Bye, Walter Dörwald ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] reference leaks, __del__, and annotations
Thomas Wouters [EMAIL PROTECTED] writes: While we're at it, I would like for the new __del__ (which would probably have to be a new method) to disallow reviving self, just because it makes it unnecessarily complicated and it's rarely needed. I'm not sure the problem is so much that anyone _wants_ to support resurrection in __del__, it's just that it can't be prevented. l = [] class A(object): def __del__(self): l.append(self) a = A() a = 1 What would you have this do? And if we want to have a version of __del__ that can't reference 'self', we have it already: weakrefs with callbacks. What happened to the 'get rid of __del__ in py3k' idea? Cheers, mwh -- freeside On a scale of One to AWESOME, twisted.web is PRETTY ABSTRACT -- from Twisted.Quotes ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Whole bunch of test failures on OSX
I'm not sure this is going to be all that helpful. If there's more I can do
to help track down these problems, let me know.
Last night I ran
make test EXTRATESTOPTS='-R :: -uall -r'
on my Mac laptop after a fresh svn up. I wasn't ready for how long that
would run!
I got plenty of test failures:
285 tests OK.
12 tests failed:
test_codecencodings_cn test_codecencodings_kr
test_codecencodings_tw test_codecmaps_cn test_codecmaps_hk
test_codecmaps_jp test_codecmaps_tw test_decimal test_difflib
test_logging test_optparse test_warnings
15 tests skipped:
test_al test_cd test_cl test_dl test_gdbm test_gl test_imgfile
test_linuxaudiodev test_locale test_nis test_ossaudiodev
test_pep277 test_sunaudiodev test_winreg test_winsound
Those skips are all expected on darwin.
The test_codecencodings_tw failure looks like this:
File
/Users/skip/src/python-svn/trunk/Lib/test/test_multibytecodec_support.py,
line 88, in test_customreplace_encode
test.xmlcharnamereplace)[0], sout)
File
/Users/skip/src/python-svn/trunk/Lib/test/test_multibytecodec_support.py,
line 74, in xmlcharnamereplace
if ord(c) in codepoint2name:
File
/Users/skip/src/python-svn/trunk/Lib/test/test_multibytecodec_support.py,
line 260, in ord
return _ord(c)
File
/Users/skip/src/python-svn/trunk/Lib/test/test_multibytecodec_support.py,
line 260, in ord
return _ord(c)
File
/Users/skip/src/python-svn/trunk/Lib/test/test_multibytecodec_support.py,
line 260, in ord
return _ord(c)
... many more at the same line ...
with maximum recursion depth exceeded at the bottom. Similar problem in
test_codecmaps_hk except the recursion was in _unichr():
File
/Users/skip/src/python-svn/trunk/Lib/test/test_multibytecodec_support.py,
line 299, in test_mapping_file
unich = unichrs(data[1])
File
/Users/skip/src/python-svn/trunk/Lib/test/test_multibytecodec_support.py,
line 275, in lambda
unichrs = lambda s: u''.join(map(unichr, map(eval, s.split('+'
File
/Users/skip/src/python-svn/trunk/Lib/test/test_multibytecodec_support.py,
line 253, in unichr
return _unichr(v)
File
/Users/skip/src/python-svn/trunk/Lib/test/test_multibytecodec_support.py,
line 253, in unichr
return _unichr(v)
File
/Users/skip/src/python-svn/trunk/Lib/test/test_multibytecodec_support.py,
line 253, in unichr
return _unichr(v)
...
The other codec-related failures looked the same to my casual eye.
The test_difflib error was an assertion failure involving a big-ass chunk of
HTML:
test test_difflib failed -- Traceback (most recent call last):
File /Users/skip/src/python-svn/trunk/Lib/test/test_difflib.py, line
145, in test_html_diff
self.assertEqual(actual,expect)
AssertionError: '\n!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0
Transitional//EN\n
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;\n\nhtml\n\nhead\n
meta http-equiv=Content-Type\n content=text/html;
charset=ISO-8859-1 /\ntitle/title\nstyle type=text/css\n
table.diff {font-family:Courier; border:medium;}\n.diff_header
{background-color:#e0e0e0}\ntd.diff_header {text-align:right}\n ...
The test_optparse failure:
test test_optparse failed -- Traceback (most recent call last):
File /Users/skip/src/python-svn/trunk/Lib/test/test_optparse.py, line
571, in test_float_default
self.assertHelp(self.parser, expected_help)
File /Users/skip/src/python-svn/trunk/Lib/test/test_optparse.py, line
176, in assertHelp
actual_help + '\n')
AssertionError: help text failure; expected:
usage: test [options]
options:
-h, --helpshow this help message and exit
-p PROB, --prob=PROB blow up with probability PROB [default: 0.43]
; got:
usage: test [options]
options:
-h, --helpshow this help message and exit
-p PROB, --prob=PROB blow up with probability PROB
[default: 0.43]
Test_logging crashed:
test test_logging crashed -- class 'exceptions.KeyError':
logging.StreamHandler instance at 0x2088478
And though it didn't list test_bsddb3 as a failure, it got a bunch of
DBLockDeadlockError exceptions. Here are a couple examples:
test_bsddb3
Exception in thread reader 0:
Traceback (most recent call last):
File /Users/skip/src/python-svn/trunk/Lib/threading.py, line 467, in
__bootstrap
self.run()
File /Users/skip/src/python-svn/trunk/Lib/threading.py, line 447, in run
self.__target(*self.__args, **self.__kwargs)
File /Users/skip/src/python-svn/trunk/Lib/bsddb/test/test_thread.py,
line 275, in readerThread
rec = dbutils.DeadlockWrap(c.next, max_retries=10)
File /Users/skip/src/python-svn/trunk/Lib/bsddb/dbutils.py, line 62, in
DeadlockWrap
return function(*_args, **_kwargs)
DBLockDeadlockError: (-30995,
Re: [Python-Dev] Whole bunch of test failures on OSX
[Neal Norwitz, on -R testing] ... For the latest results, see: http://docs.python.org/dev/results/make-test-refleak.out Several tests fail consistently with -R. These are the most recent from the link above: test_decimal test_difflib test_logging test_optparse test_warnings. It would be great if someone would figure out why these tests fail when running under -R and fix them. Like anyone wants to spend their life guessing what reload() actually does 0.6 wink. C:\Code\python\PCbuildpython Python 2.5a0 (trunk:43548M, Apr 1 2006, 21:44:15) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. from test import test_warnings test_warnings.test_main() # first time it's fine test_filtering (test.test_warnings.TestModule) ... ok test_warn_default_category (test.test_warnings.TestModule) ... ok test_warn_specific_category (test.test_warnings.TestModule) ... ok -- Ran 3 tests in 0.031s OK reload(test_warnings) # then the dreaded reload(), and it fails module 'test.test_warnings' from 'C:\Code\python\lib\test\test_warnings.pyc' test_warnings.test_main() test_filtering (test.test_warnings.TestModule) ... ERROR test_warn_default_category (test.test_warnings.TestModule) ... ERROR test_warn_specific_category (test.test_warnings.TestModule) ... ERROR == ERROR: test_filtering (test.test_warnings.TestModule) -- Traceback (most recent call last): File C:\Code\python\lib\test\test_warnings.py, line 68, in test_filtering self.assertEqual(msg.message, text) AttributeError: WarningMessage instance has no attribute 'message' == ERROR: test_warn_default_category (test.test_warnings.TestModule) -- Traceback (most recent call last): File C:\Code\python\lib\test\test_warnings.py, line 42, in test_warn_default_category self.assertEqual(msg.message, text) AttributeError: WarningMessage instance has no attribute 'message' == ERROR: test_warn_specific_category (test.test_warnings.TestModule) -- Traceback (most recent call last): File C:\Code\python\lib\test\test_warnings.py, line 57, in test_warn_specific_category self.assertEqual(msg.message, text) AttributeError: WarningMessage instance has no attribute 'message' -- Ran 3 tests in 0.000s FAILED (errors=3) Traceback (most recent call last): File stdin, line 1, in module File C:\Code\python\lib\test\test_warnings.py, line 85, in test_main test_support.run_unittest(TestModule) File C:\Code\python\lib\test\test_support.py, line 300, in run_unittest run_suite(suite, testclass) File C:\Code\python\lib\test\test_support.py, line 284, in run_suite raise TestFailed(msg) test.test_support.TestFailed: errors occurred in test.test_warnings.TestModule Figuring out why that happens is pretty much a nightmare. Fixing it requires changes to both regrtest and test_warnings: Index: Lib/test/regrtest.py === --- Lib/test/regrtest.py(revision 43548) +++ Lib/test/regrtest.py(working copy) @@ -536,12 +536,10 @@ sys.path_importer_cache.update(pic) dircache.reset() linecache.clearcache() -if indirect_test: -def run_the_test(): -indirect_test() -else: -def run_the_test(): -reload(the_module) +def run_the_test(): +reload(the_module) +if indirect_test: +getattr(the_module, test_main)() deltas = [] repcount = huntrleaks[0] + huntrleaks[1] print sys.stderr, beginning, repcount, repetitions Index: Lib/test/test_warnings.py === --- Lib/test/test_warnings.py (revision 43548) +++ Lib/test/test_warnings.py (working copy) @@ -84,5 +84,9 @@ def test_main(verbose=None): test_support.run_unittest(TestModule) +# Obscure hack so that this test passes after reloads (regrtest -R). +if '__warningregistry__' in globals(): +del globals()['__warningregistry__'] + if __name__ == __main__: test_main(verbose=True) The change to regrtest may fix other -R cases (for example, it appears to repair test_decimal), but may introduce new failures too. If you try it and find it's a net win ;-), feel free to check it in.
Re: [Python-Dev] outstanding items for 2.5
On Sun, Apr 02, 2006 at 11:34:18PM -0800, Neal Norwitz wrote: Review the PEP and let me know what needs to be changed. If your pet project isn't already in the PEP, assume it has been deferred until 2.6. I'd like to see Gregory K. Johnson's updated mailbox module (in sandbox/mailbox/) included. I mentored its development and think the code is ready for inclusion, but would like someone else to run an eye over it. Any volunteers? I can file a patch request for this item if desired. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Renaming sqlite3
Martin v. Löwis wrote: I see three options: 1. rename sqlite3 again 2. link sqlite3 statically into _sqlite3.pyd 3. stop treating .DLL files as extension modules I'm actually leaning towards option 3: what is the rationale for allowing Python extension modules to be named .DLL? A datapoint specific to OS/2 which probably has little relevance to Windows or to the specific case at hand: In order to get the curses_panel module to work, I have to forward the necessary curses entry points from the _curses module DLL. On OS/2, this only works for DLLs with the extension .DLL, so I ship _curses.pyd as _curses.dll. As a consequence, I can't implement option 3 for the OS/2 port but I can live with the nasty side-effects given the modest userbase and by documenting the issue in the port README. If you can make option 3 work for Windows, then I would do it now during the alpha to see whether it flushes any problems out. I must admit to being uncomfortable with including version numbers in module names, especially when they reflect a version outside the scope of Python. Ending up with a module name that can match a 3rd party dynamically linkable file would seem problematic no matter which way you look at it. FWIW, Andrew. - Andrew I MacIntyre These thoughts are mine alone... E-mail: [EMAIL PROTECTED] (pref) | Snail: PO Box 370 [EMAIL PROTECTED] (alt) |Belconnen ACT 2616 Web:http://www.andymac.org/ |Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Renaming sqlite3
Martin v. Löwis wrote: I just tried creating a pysqlite VS project, and ran into a naming conflict: the Windows DLL is called sqlite3.dll. So if it is on sys.path import sqlite3 might find the DLL, instead of finding the package. Python then finds that there is no entry point in sqlite3, and raises an ImportError. I see three options: 1. rename sqlite3 again 2. link sqlite3 statically into _sqlite3.pyd 3. stop treating .DLL files as extension modules I'm actually leaning towards option 3: what is the rationale for allowing Python extension modules to be named .DLL? Don't know. But if you make the change to implement option 3, IMO it would be a good idea to add the Python version number to the .pyd basename as well. pywin32 already has to do this, since pythoncomXY.pyd and pywintypesXY.pyd have to live (if possible) in the windows directory. There have been other conflicts reported before: I remember Windows\system32\wmi.dll conflicting with Tim Golden's wmi.py module. In addition, wmi.dll is very special, since it doesn't have an import table, IIRC. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] SF:1463370 add .format() method to str and unicode
Crutcher Dunnavant wrote: From discussion on python-3000, it occured to me that this shouldn't break anything. This patch adds a .format() method to the string and unicode types. SF:1463370 -1. For reasons I go into more on the Py3k list, I'd like to see this term associated with an enhanced version of PEP 292 style string formatting rather than the existing mod-style formatting. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r43545 - in python/trunk: Doc/lib/libcalendar.tex Lib/calendar.py
Walter Dörwald wrote: Tim Peters wrote: Which isn't a good thing to lose. It's not good that the current Calendar constructor skips that sanity check either (errors should never pass silently). I've changed calendar so that firstweekday is only used modulo 7 everywhere (There was only one spot missing, all other cases used firstweekday modulo 7 anyway. ... Simple attribute access looks much more Pythonic to me than setters and gettes (especially as the attributes of subclasses are simple attributes). Or are you talking about the Calendar class itself? Yes, it would be best if Calendar had a property, so that sanity checks were performed when setting `firstweekday`, and also if the Calendar constructor performed that sanity check (which could happen by magic if `firstweekday` were a property). Range checks should no longer be neccessary, as any value works now. But now all *clients* of the Calendar class are forced to deal with the fact that firstweekday may not be greater than seven. If you want to accept any input value, why not use a property to force it to be modulo 7, rather than doing an actual range check? Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Use dlopen() on Darwin/OS X to load extensions?
Hi folks, I submitted a patch a little while ago to led Python on Darwin/OS X use the same code path to load extensions it uses on most other Unix- like platforms. (The reasons for this are several, and mentioned in the patch: http://sourceforge.net/tracker/index.php? func=detailaid=1454844group_id=5470atid=305470 ). Anyhow, IMO if this patch is to be included at all (I rather think it should, and will happily discuss that on this list or on the patch comments to clarify why this is so), it probably ought to make it into python 2.5 earlier rather than later. While I'm almost certain that these changes will cause no issues (as Apple officially encourages use of dlopen() as a drop-in replacement for the officially 'discouraged' NeXT-derived functions that Python now uses to load extensions), it would seem more prudent to give a low-level change like this plenty of time to settle out in case I am wrong. I've run this by the python-mac folks, and there seemed to be some assent, or at least no complaint. Bob Ippolito appeared to think that this approach was the best to making Python on the Mac load extensions properly in some corner cases (see the patch description for more details), but he hasn't weighted in for a while. Sorry if it's bad form to ask about patches one has submitted -- let me know if that sort of discussion should be kept strictly on the patch tracker. Zach Pincus Program in Biomedical Informatics and Department of Biochemistry Stanford University School of Medicine ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] SF:1463370 add .format() method to str and unicode
On Mon, Apr 03, 2006, Crutcher Dunnavant wrote: From discussion on python-3000, it occured to me that this shouldn't break anything. This patch adds a .format() method to the string and unicode types. SF:1463370 If you're serious, please write up a PEP. I recommend that you start posting to comp.lang.python first. (Changes to built-in types like this generally require a PEP.) -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ Look, it's your affair if you want to play with five people, but don't go calling it doubles. --John Cleese anticipates Usenet ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r43545 - in python/trunk: Doc/lib/libcalendar.tex Lib/calendar.py
Nick Coghlan wrote: Walter Dörwald wrote: [...] Range checks should no longer be neccessary, as any value works now. But now all *clients* of the Calendar class are forced to deal with the fact that firstweekday may not be greater than seven. If you want to accept any input value, why not use a property to force it to be modulo 7, rather than doing an actual range check? OK, the property setter does a % 7 now. (But the global setfirstweekday() still does a range check). Bye. Walter Dörwald ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] SF #1462485 - StopIteration raised in body of 'with' statement suppressed
On 4/2/06, Delaney, Timothy (Tim) [EMAIL PROTECTED] wrote:
Given:
@contextmanager
def gen():
print '__enter__'
yield
print '__exit__'
with gen():
raise StopIteration('body')
I would expect to get the StopIteration exception raised. Instead it's
suppressed by the @contextmanager decorator.
Right. I'm not sure how to fix this (but I think Phillip probably can).
I think we should only suppress the exception if it's *not* the
exception passed into gen.throw() i.e. it's raised by the generator.
Does this sound like the correct behaviour? I've attached tests and a
fix implementing this to the bug report.
Cool.
I can't confirm right now (at work, need to install 2.5) but I'm also
wondering what will happen if KeyboardInterrupt or SystemExit is raised
from inside the generator when it's being closed via __exit__. I suspect
a RuntimeError will be raised, whereas I think these should pass
through.
I see no reason for this with the current code. Perhaps a previous
version of contextlib.py had this problem?
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I'm not getting email from SF when assignedabug/patch
the source code is available via the above link; I'll post the ZIP file some- where tomorrow (drop me a line if you want the URL). I found some free space on the effbot.org server, so anyone inter- ested can get the current ZIP file here: http://effbot.org/tracker-20060403.zip the zip file is ~85 megabytes, and expands to about 300 megabyte data. there are three tracker directories (for the bugs, patches, and feature re- quest trackers). for each item, there are at least two files: item-NNN.xml (index information, created by getindex.py) item-NNN-page.xml (xhtml pages, created by getpages.py) where NNN is the tracker item identifier. for items that have attached files, there's also one or more item-NNN-data-MMM.dat (data files, created by getfiles.py) where MMM is a file identifier (referred to by the page files). ::: the extract module available here: http://effbot.python-hosting.com/browser/stuff/sandbox/sourceforge/ can be used to extract information from the page.xml files (see the sanity check code at the end of that file for a usage example). to use this, you need ElementTree (a Python 2.5 pre-alpha should work) and/or cElementTree. ::: I'll post an export demo script later. cheers /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP to list externally maintained modules and where to report bugs?
[Brett Cannon wrote] Anyone else think we need a PEP to point to places where externally maintained code should have bugs or patches reported? I don't want to hunt down a URL for where to do this every time and so it would be nice to have a list of what code needs bugs/patches reported where. Otherwise I am prone to just check my changes into the tree and not get them reported upstream since I want the warnings to go away. =) +1 Perhaps that could be merged with generic how to report a bug instructions. This might be helpful for a start: http://producingoss.com/html-chunk/bug-reporting.html Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Firefox searchbar engine for Python bugs
[Anthony Baxter wrote] I've created a searchbar plugin for the firefox search bar that allows you to search bugs. I think someone created one for the sidebar http://starship.python.net/~skippy/mozilla/ http://projects.edgewall.com/python-sidebar/ Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Need Py3k group in trackers
Could one of the tracker admins add a Python-3000 group to the SF trackers (while we're still using them :-)? This is so we can easily move proposals between Python 3000 and Python 2.x status. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] reference leaks, __del__, and annotations
On 4/3/06, Michael Hudson [EMAIL PROTECTED] wrote: I'm not sure the problem is so much that anyone _wants_ to support resurrection in __del__, it's just that it can't be prevented. Well, Java has an answer to that (at least I believe Tim Peters told me so years ago): it allows resurrection, but will only call the finalizer once. IOW if the resurrected object is GC'ed a second time, its finalizer won't be called. This would require a bit __del__ already called on an object, but don't we have a whole word of GC-related flags? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] outstanding items for 2.5
I checked what I owned. - pgen: yes, if I have time - GeneratorExit inheriting from BaseException: no, I've pronounced on this - StopIteration propagation from context managers: I'm giving this to Phillip --Guido On 4/3/06, Neal Norwitz [EMAIL PROTECTED] wrote: I updated the PEP to include owners. If this message is sent directly to you, you are an owner. http://www.python.org/dev/peps/pep-0356/ There are still some items without owners as I don't know who will be leading the charge to get some of the modules in the stdlib. If we don't have anyone pushing them, they won't go in. If they are going in, they should be committed soon after alpha1 is out the door. Please don't rush to get them in before the alpha, unless you're absolutely sure it won't screw things up. Review the PEP and let me know what needs to be changed. If your pet project isn't already in the PEP, assume it has been deferred until 2.6. Also, now would be a good time to see if you have any bugs/patches assigned to you: http://sourceforge.net/my/tracker.php Cheers, n -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Need Py3k group in trackers
On Monday 03 April 2006 14:45, Guido van Rossum wrote: Could one of the tracker admins add a Python-3000 group to the SF trackers (while we're still using them :-)? This is so we can easily move proposals between Python 3000 and Python 2.x status. Done. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] reference leaks, __del__, and annotations
Guido van Rossum [EMAIL PROTECTED] wrote: This would require a bit __del__ already called on an object, but don't we have a whole word of GC-related flags? No. Neil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] SF:1463370 add .format() method to str and unicode
On 4/3/06, Crutcher Dunnavant [EMAIL PROTECTED] wrote: From discussion on python-3000, it occured to me that this shouldn't break anything. This patch adds a .format() method to the string and unicode types. SF:1463370 Hmm... Let's not jump to conclusions. While I like your patch, we need to have community consensus that s.format(x) is better than s%x, and we need to discuss alternatives such as a different format syntax. I guess I have to amend my process proposals (and yes, I know it's high time for me to get back on the wagon and start spending quality time with Python 3000). While I still believe that new features which can be introduced without backwards incompatibility are fair game for introduction in Python 2.x rather than waiting for 3.0 (and in fact, introduction in 2.x is perhaps preferable over waiting), the realities of community opinion and proposal history need to be taken into account. We also, in particular, need to be really careful that we don't introduce things into 2.x that we *think* we'll want in Py3k but which might turn out later to require more tweaks. For example, in the case of the formatting method, it would be tragic if Python 3000 switched to a different format syntax but we had already introduced s.format(x) in Python 2.x as an alias to s%x -- then the meaning of s.format(x) would change in Python 3000, while we might have had the opportunity of a 10)% *compatible* change if we had waited until the Python 3000 version of the feature had settled before rushing it into Python 2.x. Concluding, perhaps the right time to include certain features in Python 2.x is only *after* the feature has been discussed, specified, agreed upon, and implemented in Python 3000. Of course, this doesn't mean we shouldn't plan to add anything new to Python 2.x (even though that would greatly reduce merge problems with the Py3k branch ;-). I guess changes to 2.x should follow the established, 100% backwards compatible, evolutionary path: if python-dev agrees it's a good idea, it should probably go in. OTOH if it's a potentially disruptive change, or if it could benefit from synchronicity with other Py3k features, or perhaps even if it just adds a new way of saying something that might eventually mean the old way should be deprecated, it's better to refine the idea in a Python 3000 context first. It's going to be inevitable that we'll get the occasional idea first brought up on python-dev that makes more sense to move to Python 3000, or vice versa; let's all be mindful of such cases. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] posixmodule.c patch- revision 43586
According to MSDN, ShellExecute has only six parameters: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/reference/functions/shellexecute.asp But in the posixmodule patch at: http://mail.python.org/pipermail/python-checkins/2006-April/050698.html it is passed seven: rc = ShellExecuteW((HWND)0, operation, PyUnicode_AS_UNICODE(unipath), PyUnicode_AS_UNICODE(woperation), NULL, NULL, SW_SHOWNORMAL); Shouldn't that part read as follows? Or am I missing something? rc = ShellExecuteW((HWND)0, PyUnicode_AS_UNICODE(woperation), PyUnicode_AS_UNICODE(unipath), NULL, NULL, SW_SHOWNORMAL); Regards, Khalid _ Don't just search. Find. Check out the new MSN Search! http://search.msn.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] outstanding items for 2.5
On Sun, Apr 02, 2006, Neal Norwitz wrote: I updated the PEP to include owners. If this message is sent directly to you, you are an owner. http://www.python.org/dev/peps/pep-0356/ Review the PEP and let me know what needs to be changed. If your pet project isn't already in the PEP, assume it has been deferred until 2.6. Per file() vs open(), round 7 at http://mail.python.org/pipermail/python-dev/2005-December/thread.html#59073 please add to list of planned features and list me as the owner. I'd calle this feature make open() a factory function instead of an alias for file() (with suitable doc changes) -- that parenthetical being the blocking factor here ;-) -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ Look, it's your affair if you want to play with five people, but don't go calling it doubles. --John Cleese anticipates Usenet ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] reference leaks, __del__, and annotations
[Michael Hudson] I'm not sure the problem is so much that anyone _wants_ to support resurrection in __del__, it's just that it can't be prevented. [Guido] Well, Java has an answer to that (at least I believe Tim Peters told me so years ago): it allows resurrection, but will only call the finalizer once. IOW if the resurrected object is GC'ed a second time, its finalizer won't be called. Right, that's a technical trick Java uses. Note that it doesn't stop resurrection: all the resurrection-related pitfalls remain. One good result is that cycles containing objects with finalizers don't stop gc progress forever; some progress can always be made, although it may be as little as reclaiming one object per full gc cycle (ignoring that full gc cycle is a fuzzy concept in a runs-in-parallel threaded gc). A bad result is an endless stream of nearly-impenetrable articles encouraging deep fear of Java finalizers ;-); e.g., http://www.devx.com/Java/Article/30192/0/page/1 This would require a bit __del__ already called on an object, but don't we have a whole word of GC-related flags? Nope! You're probably thinking of gc_refs. That's a Py_ssize_t today, and is overloaded to hold, at various times, a status enum (which only needs a few bits) or a copy of the object's refcount (which uses all the bits). ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] outstanding items for 2.5
Done. What exactly do you plan to do apart from editing the docs to steer people away from file()? --Guido On 4/3/06, Aahz [EMAIL PROTECTED] wrote: On Sun, Apr 02, 2006, Neal Norwitz wrote: I updated the PEP to include owners. If this message is sent directly to you, you are an owner. http://www.python.org/dev/peps/pep-0356/ Review the PEP and let me know what needs to be changed. If your pet project isn't already in the PEP, assume it has been deferred until 2.6. Per file() vs open(), round 7 at http://mail.python.org/pipermail/python-dev/2005-December/thread.html#59073 please add to list of planned features and list me as the owner. I'd calle this feature make open() a factory function instead of an alias for file() (with suitable doc changes) -- that parenthetical being the blocking factor here ;-) -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ Look, it's your affair if you want to play with five people, but don't go calling it doubles. --John Cleese anticipates Usenet ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Saving the hash value of tuples
On 4/2/06, Noam Raphael [EMAIL PROTECTED] wrote: On 4/2/06, Guido van Rossum [EMAIL PROTECTED] wrote: I tried the change, and it turned out that I had to change cPickle a tiny bit: it uses a 2-tuple which is allocated when the module initializes to lookup tuples in a dict. I changed it to properly use PyTuple_New and Py_DECREF, and now the complete test suite passes. I run test_cpickle before the change and after it, and it took the same time (0.89 seconds on my computer). Not just cPickle. I believe enumerate() also reuses a tuple. Maybe it does, but I believe that it doesn't calculate the hash value of it - otherwise, the test suite would probably have failed. But someone else could. What do you think? I see three possibilities: 1. Nothing should be done, everything is as it should be. 2. The cPickle module should be changed to not abuse the tuple, but there's no reason to add an extra word to the tuple structure and break binary backwards compatibility. 3. Both should be changed. I'm -1 on the change. Tuples are pretty fundamental in Python and hashing them is relatively rare. I think the extra required space for all tuples isn't worth the potential savings for some cases. That's fine with me. But what about option 2? Perhaps cPickle (and maybe enumerate) should properly discard their tuples, so that if someone in the future decides that saving the hash value is a good idea, he won't encounter strange bugs? At least in cPickle I didn't notice any loss of speed because of the change, and it's quite sensible, since there's a tuple-reuse mechanism anyway. No, these are carefully considered speed-ups. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] posixmodule.c patch- revision 43586
[A.B., Khalid] According to MSDN, ShellExecute has only six parameters: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/reference/functions/shellexecute.asp But in the posixmodule patch at: http://mail.python.org/pipermail/python-checkins/2006-April/050698.html it is passed seven: rc = ShellExecuteW((HWND)0, operation, PyUnicode_AS_UNICODE(unipath), PyUnicode_AS_UNICODE(woperation), NULL, NULL, SW_SHOWNORMAL); Shouldn't that part read as follows? Or am I missing something? rc = ShellExecuteW((HWND)0, PyUnicode_AS_UNICODE(woperation), PyUnicode_AS_UNICODE(unipath), NULL, NULL, SW_SHOWNORMAL); Well, _something's_ screwy with it. All the Windows buildbots are unhappy with that statement, giving 3 warnings: \Code\python\Modules\posixmodule.c(7487) : warning C4133: 'function' : incompatible types - from 'char *' to 'LPCWSTR' \Code\python\Modules\posixmodule.c(7490) : warning C4047: 'function' : 'INT' differs in levels of indirection from 'void *' \Code\python\Modules\posixmodule.c(7490) : warning C4020: 'ShellExecuteW' : too many actual parameters It would be worse, except all the Windows buildbot compiles are dying for a different reason: md5c.c c1 : fatal error C1083: Cannot open source file: '\Code\python\Modules\md5c.c': No such file or directory While we're at it, looks like all the 2.4 buildbots are failing test_email today. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] reference leaks, __del__, and annotations
On Apr 3, 2006, at 3:12 PM, Neil Schemenauer wrote:
Guido van Rossum [EMAIL PROTECTED] wrote:
This would require a bit __del__ already called on an object,
but don't we have a whole word of GC-related flags?
No.
Actually there is. Kinda. Currently python's refcounting scheme uses
4 words per object (gc_next, gc_prev, gc_refs, ob_refcnt), and has
one spare word in the padding of PyGC_Head that's just sitting there
wasting memory. So really it's using up 5 words per object, and that
5th word could actually be used for flags...
/* GC information is stored BEFORE the object structure. */
typedef union _gc_head {
struct {
union _gc_head *gc_next;
union _gc_head *gc_prev;
int gc_refs;
} gc;
long double dummy; /* force worst-case alignment */
} PyGC_Head;
#define PyObject_HEAD \
_PyObject_HEAD_EXTRA\
int ob_refcnt; \
struct _typeobject *ob_type;
typedef struct _object {
PyObject_HEAD
} PyObject;
James
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] posixmodule.c patch- revision 43586
Tim Peters wrote: While we're at it, looks like all the 2.4 buildbots are failing test_email today. ___ Anthony backported the patch that should fix this, so it should be showing up in 2.4 buildbots soon. -Barry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I'm not getting email from SF when assignedabug/patch
On 4/3/06, Fredrik Lundh [EMAIL PROTECTED] wrote: the source code is available via the above link; I'll post the ZIP file some- where tomorrow (drop me a line if you want the URL). I found some free space on the effbot.org server, so anyone inter- ested can get the current ZIP file here: http://effbot.org/tracker-20060403.zip the zip file is ~85 megabytes, and expands to about 300 megabyte data. Can someone (Martin, Barry?) post this on python.org (I don't think this necessarily needs to be put into svn and I don't have any access but svn) so Fredrik can free up the space on his server? there are three tracker directories (for the bugs, patches, and feature re- quest trackers). for each item, there are at least two files: item-NNN.xml (index information, created by getindex.py) item-NNN-page.xml (xhtml pages, created by getpages.py) where NNN is the tracker item identifier. for items that have attached files, there's also one or more item-NNN-data-MMM.dat (data files, created by getfiles.py) where MMM is a file identifier (referred to by the page files). ::: the extract module available here: http://effbot.python-hosting.com/browser/stuff/sandbox/sourceforge/ can be used to extract information from the page.xml files (see the sanity check code at the end of that file for a usage example). to use this, you need ElementTree (a Python 2.5 pre-alpha should work) and/or cElementTree. ::: I'll post an export demo script later. OK, great. I will send out an email to start hashing out what we want in the tracker call soon so we can start working on that while you type up the demo script. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] reference leaks, __del__, and annotations
[Guido] but don't we have a whole word of GC-related flags? [Neil S] No. [James Y Knight] Actually there is. Kinda. Currently python's refcounting scheme uses 4 words per object (gc_next, gc_prev, gc_refs, ob_refcnt), and has one spare word in the padding of PyGC_Head that's just sitting there wasting memory. Using which compiler? This varies across boxes. Most obviously, on a 64-bit box all these members are 8 bytes (note that ob_refcnt is Py_ssize_t in 2.5, not int anymore), but even on some 32-bit boxes the long double trick only forces 4-byte alignment. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] posixmodule.c patch- revision 43586
[Tim] While we're at it, looks like all the 2.4 buildbots are failing test_email today. [Barry] Anthony backported the patch that should fix this, so it should be showing up in 2.4 buildbots soon. ? Anthony's Changed by: anthony.baxter Changed at: Mon 03 Apr 2006 16:40:28 Branch: branches/release24-maint Revision: 43597 Changed files: * branches/release24-maint/Lib/email/_parseaddr.py Comments: backport of r43578 The email module's parsedate_tz function now sets the daylight savings flag to -1 (unknown) since it can't tell from the date whether it should be set. patch from Aldo Cortesi is in the blamelist for the runs where test_email _started_ failing in 2.4 today. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] reference leaks, __del__, and annotations
At 08:14 AM 3/31/2006, Tim Peters wrote: [Phillip J. Eby] ... As Tim suggested, it'd be better to have the code be generator-specific, at least for now. That had actually been my original plan, to make it generator-specific, but I was afraid of breaking encapsulation in the garbage collector by having it know about generators. It sucks in a way, but so would adding yet another new slot just for (at present, and possibly forever) making gc and generators play nicer together. Practicality beats purity here. I'm trying to figure out how to implement this now, and running into a bit of a snag. It's easy enough for gcmodule.c to check if an object is a generator, but I'm not sure how safe the dynamic check actually is, since it depends on the generator's state. In principle, running other finalizers could cause the generator's state to change from a finalizer being required to not being required, or vice versa. Could this mess up the GC process? It seems to me that it's safe for a generator to say, yes, I need finalization, because if it later turns out not to, it's just a waste. But if the generator says, no, I don't need finalization, and then later turns out to need it, doesn't that leave an opportunity to screw things up if the GC does anything other than immediately clear the generator? As best I can tell, the only things that could cause arbitrary Python code to run, that could possibly result in generator state changes, are structure traversal and weakref callback handling. It's probably not sane for anybody to have structure traversal run arbitrary Python code, so I'm going to ignore that for the sake of my own sanity. :) Weakref callbacks are tougher, though; it seems possible that you could have one of those cause a generator to be advanced to a point where it now needs finalization. OTOH, if such a generator could be advanced by the callback, then wouldn't that mean the generator is reachable, and ergo, not garbage? That is, since only reachable weakref callbacks are run, they must by definition be unable to access any generator that declared itself finalizer-free. It does seem possible you could end up with a situation where an object with a finalizer is called after a generator it references is torn down, but that circumstance can occur in earlier versions of Python anyway, and in fact this behavior would be consistent. Okay, I *think* I've convinced myself that a dynamic state check is OK, but I'm hoping somebody with more GC experience can check my reasoning here for holes. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Renaming sqlite3
Thomas Heller wrote: But if you make the change to implement option 3, IMO it would be a good idea to add the Python version number to the .pyd basename as well. Can you please elaborate? In the name of what .pyd file do you want the Python version number? And why? And why is that related to not supporting extensions with .DLL names anymore? pywin32 already has to do this, since pythoncomXY.pyd and pywintypesXY.pyd have to live (if possible) in the windows directory. I think this is a very special case: it could have been implemented with separate DLLs which just provide the COM entry points, and find the location of pythoncom.pyd from the registry. I would discourage people from providing additional entry points to an extension module. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] SF #1462485 - StopIteration raised in body of 'with' statement suppressed
Guido van Rossum wrote: I can't confirm right now (at work, need to install 2.5) but I'm also wondering what will happen if KeyboardInterrupt or SystemExit is raised from inside the generator when it's being closed via __exit__. I suspect a RuntimeError will be raised, whereas I think these should pass through. I see no reason for this with the current code. Perhaps a previous version of contextlib.py had this problem? Nah - that was me mis-remembering the contextlib code. They're handled properly. Tim Delaney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] posixmodule.c patch- revision 43586
On Tuesday 04 April 2006 06:06, Tim Peters wrote: backport of r43578 The email module's parsedate_tz function now sets the daylight savings flag to -1 (unknown) since it can't tell from the date whether it should be set. patch from Aldo Cortesi is in the blamelist for the runs where test_email _started_ failing in 2.4 today. Damnit. I see you fixed this. Sorry about that. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] reference leaks, __del__, and annotations
Michael Hudson wrote: And if we want to have a version of __del__ that can't reference 'self', we have it already: weakrefs with callbacks. Does that actually work at the moment? Last I heard, there was some issue with gc and weakref callbacks as well. Has that been resolved? -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiam! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r43545 - in python/trunk: Doc/lib/libcalendar.tex Lib/calendar.py
Walter Dörwald wrote: OK, the property setter does a % 7 now. (But the global setfirstweekday() still does a range check). Wouldn't it be better for the setter to raise an exception if it's out of range? It probably indicates a bug in the caller's code. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiam! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] reference leaks, __del__, and annotations
[Phillip J. Eby]
I'm trying to figure out how to implement this now, and running into
a bit of a snag. It's easy enough for gcmodule.c to check if an
object is a generator, but I'm not sure how safe the dynamic check
actually is, since it depends on the generator's state. In
principle, running other finalizers could cause the generator's state
to change from a finalizer being required to not being required, or
vice versa. Could this mess up the GC process?
Yup, although the tricky question is whether it's possible for other
finalizers to do such a thing.
It seems to me that it's safe for a generator to say, yes, I need
finalization,
because if it later turns out not to, it's just a waste.
Definitely safe. In effect, that's what happens right now (all
generators say I need finalization now).
But if the generator says, no, I don't need finalization, and then later
turns out to need it, doesn't that leave an opportunity to screw things up
if the GC does anything other than immediately clear the generator?
As best I can tell, the only things that could cause arbitrary Python
code to run, that could possibly result in generator state changes,
are structure traversal and weakref callback handling.
And __del__ methods. It's a common misconception that Python's cyclic
gc won't ever clean up an object with a __del__ method. It can and
routinely does. What it won't do is automagically break a _cycle_
containing an object with a __del__ method. It's quite possible to
have any number of objects with __del__ methods reachable only _from_
a trash cycle containing no objects with __del__ methods, where those
__del__-slinging objects are not themselves in a cycle. gc will break
that cycle, and the __del__ methods on trash objects hanging off
that cycle will get invoked as a normal side effect of their objects'
refcounts falling to 0.
From a different POV, Python's gc never reclaims anything directly --
all it does is break cycles via calling tp_clear on trash objects, and
whatever (if any) reclamation gets done happens as a side effect of
Py_DECREF. Specifically, this one in delete_garbage():
if ((clear = op-ob_type-tp_clear) != NULL) {
Py_INCREF(op);
clear(op);
Py_DECREF(op);
}
If it wouldn't spoil the fun, I'd be tempted to add a comment pointing
out that the entire purpose of gcmodule.c is to execute that Py_DECREF
safely :-)
It's probably not sane for anybody to have structure traversal run arbitrary
Python
code,
I'm not sure what you mean by structure traversal. The only kind of
traversing that should be going on during gc is running tp_traverse
slots, and although I doubt it's written down anywhere, a tp_traverse
slot shouldn't even do an incref, let alone call back into Python. A
tp_traverse slot dare not release the GIL either. That last one is a
subtlety that takes fixing a few critical bugs to fully appreciate:
as soon as anything can call Python code, all bets are off, because
any number of other threads can run then too, and do _almost_ anything
whatsoever to the object graph.
In particular, that Py_DECREF() above can trigger a chain of code that
releases the GIL, so by the time we get to that loop it has to be
impossible for any conceivable Python code to create any new problems
for gc.
so I'm going to ignore that for the sake of my own sanity. :) Weakref
callbacks
are tougher, though; it seems possible that you could have one of those cause
a
generator to be advanced to a point where it now needs finalization.
Not a _trash_ generator, though. While much of gc's behavior wrt
weakref callbacks is more-than-less arbitrary, and so may change some
day, for now a wr callback to a trash object is suppressed by gc if
any trash objects are reachable from that callback.
OTOH, if such a generator could be advanced by the callback, then
wouldn't that mean the generator is reachable,
Yes, but you have to qualify reachable to reachable from the callback.
and ergo, not garbage?
If the callback is itself trash, no, then G being reachable from the
callback is not enough evidence to conclude that G is not garbage.
The horrid bugs we've had come from things just like that: messy
interconnections among objects that _all_ look like trash. When
they're in cycles, they can reach each other, and so their finalizers
can see each other too, trash or not.
We already endure lots of pain to ensure that a weakref callback that
gets executed (not all do) can't see anything that looks like trash.
That is, since only reachable weakref callbacks are run,
s/reachable/non-trash/ and that's true today.
they must by definition be unable to access any generator that
declared itself finalizer-free.
Any trash object, period.
It does seem possible you could end up with a situation where an
object with a finalizer is called after
Re: [Python-Dev] reference leaks, __del__, and annotations
[Michael Hudson] ... What happened to the 'get rid of __del__ in py3k' idea? Apart from its initial mention, every now again someone asks what happened to it :-). ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] reference leaks, __del__, and annotations
Tim Peters wrote: We already endure lots of pain to ensure that a weakref callback that gets executed (not all do) can't see anything that looks like trash. Okay, so would it be possible for a generator that needs finalisation to set up a weakref callback, suitably rooted somewhere so that the callback is reachable, that references enough stuff to clean up after the generator, without referencing the generator itself? -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiam! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Use dlopen() on Darwin/OS X to load extensions?
On 4/3/06, Zachary Pincus [EMAIL PROTECTED] wrote: Sorry if it's bad form to ask about patches one has submitted -- let me know if that sort of discussion should be kept strictly on the patch tracker. No, it's fine. Thanks for reminding us about this issue. Unfortunately, without an explicit ok from one of the Mac maintainers, I don't want to add this myself. If you can get Bob, Ronald, or Jack to say ok, I will apply the patch ASAP. I have a Mac OS X.4 box and can test it, but don't know the suitability of the patch. n ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Twisted and Python 2.5a0r43587
I tried out Twisted's test suite with a version of Python built from SVN trunk
today and ran into a few problems. First, the test suite hung indefinitely
using all available CPU time. This apparently was due to a change in the
behavior of __import__: in Python 2.4, __import__('') raises a ValueError; in
Python 2.5, it returns None.
Once I hacked around this, the test suite ran to completion, though with over
fifty failures. Some of these appear to be related to the conversion of the
exception hierarchy to new-style classes, but I have not yet had a chance to
examine them closely.
Once I do have time to track down specifics, I'll file tickets as appropriate.
For now I just wanted to point out the one detail I have tracked down, and give
a heads up that there are likely some more to come.
Of course anyone who is interested can run the Twisted test suite very easily
and take a look at the failures themselves (if you have Twisted installed,
trial twisted will do it).
Jean-Paul
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Use dlopen() on Darwin/OS X to load extensions?
Thanks for reminding us about this issue. Unfortunately, without an explicit ok from one of the Mac maintainers, I don't want to add this myself. If you can get Bob, Ronald, or Jack to say ok, I will apply the patch ASAP. I have a Mac OS X.4 box and can test it, but don't know the suitability of the patch. Fair enough -- this seems reasonable. Now, there is one issue with this all that some general feedback from Python-Dev would be helpful with: how best to test such a patch? Specifically, this patch would change a core python code path. Now, I can see no reason why it would break anything -- but we know how flimsy such arguments are. More strong evidence is that python builds and tests flawlessly with this patch. Given that many of the tests involve loading C extension libs, that's a good sign. Moreover, I've been using patched versions of 2.4 and 2.5 for some time, and loading fairly extensive libs (numpy/scipy, as well as the more exotic extensions that drove me to uncover this problem before), all without issue. But it would be good to have a specific benchmark to know nothing will break. I personally sort of feel that if dlopen() works once or twice, it will probably always work, but there are those who probably understand better the failure modes of opening shared libs as python extensions, and could suggest some good things to test. Any thoughts? Zach ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
