[Python-Dev] Documentation for ability to execute zipfiles directories
A few months ago, 2.6 3.0 gained the ability to execute zipfiles and directories containing a __main__.py file (see [1] for details). The idea is that a whole application can be bundled into a zipfile containing a __main__.py module in its root directory, and then passed directly to the interpreter for execution, with the zipfile being inserted as the first entry on sys.path to allow easy access to the rest of the application code. It is inspired by Java's JAR option, but not needing an explicit interpreter option makes it more shebang friendly on *nix systems (it can also be mapped more easily to the existing Python file type handling on Windows). The ability to also execute directories containing a __main__.py was something of a side effect of the implementation technique, but was also considered valuable as it makes it much easier to develop such bundled applications (using a directory most of the time, and then bundling into a single zipfile prior to release). The part I'm struggling with now is where to document the way this feature works. Currently, the only real documentation we have of the command line invocation is in section 2.1 of the tutorial, and the idea of packaging whole applications as zipfiles seems far too esoteric to be covering it there. It doesn't really seem to fit in section 6 (covering modules and packages) either. Do we need a new appendix to the tutorial which goes into detail about the CPython interpreter's command line options, environment variables and details on what can be executed? Cheers, Nick. [1] http://bugs.python.org/issue1739468 -- 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] Documentation for ability to execute zipfiles directories
On 04/03/2008, Nick Coghlan [EMAIL PROTECTED] wrote: Do we need a new appendix to the tutorial which goes into detail about the CPython interpreter's command line options, environment variables and details on what can be executed? There is a Python man page, which covers the command line usage. However, it's separate from the documentation, and it isn't bundled with the Windows installers - both of which are a real pain (for me, at least). I'd suggest taking the man page, adding the information about executing zip files and directories, and putting the whole lot into the formal documentation. The big problem is that there isn't really anywhere in the docs which is formally CPython-specific. My preference would be to put it in the language reference, as a new chapter (between the current chapters 1 and 2) called Invoking the Python Interpreter. You could also make the manpage a new document, called Invoking Python, but it's a bit small to warrant a ful document. An appendix to the Tutorial is OK, I guess, but personally I never think of looking at the tutorial (I've been using Python too long to feel that I need a tutorial any more, although the quality of my code probably says otherwise :-)) 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] Documentation for ability to execute zipfiles directories
On Tue, Mar 04, 2008 at 10:35:42PM +1000, Nick Coghlan wrote: not needing an explicit interpreter option makes it more shebang friendly Sorry, I missed something here. How does one combine a zipfile with a shebang script?! Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ 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] Documentation for ability to execute zipfiles directories
Paul Moore wrote: On 04/03/2008, Nick Coghlan [EMAIL PROTECTED] wrote: Do we need a new appendix to the tutorial which goes into detail about the CPython interpreter's command line options, environment variables and details on what can be executed? There is a Python man page, which covers the command line usage. However, it's separate from the documentation, and it isn't bundled with the Windows installers - both of which are a real pain (for me, at least). I'd suggest taking the man page, adding the information about executing zip files and directories, and putting the whole lot into the formal documentation. The big problem is that there isn't really anywhere in the docs which is formally CPython-specific. My preference would be to put it in the language reference, as a new chapter (between the current chapters 1 and 2) called Invoking the Python Interpreter. You could also make the manpage a new document, called Invoking Python, but it's a bit small to warrant a ful document. An appendix to the Tutorial is OK, I guess, but personally I never think of looking at the tutorial (I've been using Python too long to feel that I need a tutorial any more, although the quality of my code probably says otherwise :-)) While I hesitate to suggest a change of such magnitude, there's something to recommend the old IBM mainframe approach of separating out Principles of Operation (which would be the reference manuals, in Python's case the Language and Library refs) from Users' Guide which contains the practical stuff you need to actually make use of a product. I've always found it rather counter-intuitive that you have to go to the Library Reference manual to find information about Python's built-in types, for example. I though the whole point of libraries was that they *aren't* built in, and represent baggage that should only be carried on necessary trips. And let's not get started on the import statement. I have just spent some time trying to work out how we might get rid of the embarrassing XXX can't be bothered to spell this out right now ... mess, and have come to the conclusion that a thorough review and a complete rewrite is the only thing that will do the topic justice. I can only hope that Brett plans to make a start on this as a part of his rework of the import code (and if you're reading, Brett, I'd like to help). It doesn't help my motivation that the import mechanism is about to change yet again, though I am happy that it will be more regular and easier to understand after the next change. I believe with 3.0 the biggest improvement we could make to the language for newcomers would be to reorganize our documentation so that things live in the places they belong rather than the place they landed and got stuck over time. Please note this isn't a rant, in the sense that I believe there are perfectly comprehensible reasons for how the docs got to be the shape they are. But I fear that we are possibly blinded to their inappropriate nature by our closeness to and familiarity with them, and I think a major effort to revise their structure (and to a lesser degree their content) could pay itself back many times over in increased user friendliness. Georg's recent revision of the technology puts us in a better position to prepare for this, but it would still be a major project. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.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] Documentation for ability to execute zipfiles directories
Oleg Broytmann wrote: On Tue, Mar 04, 2008 at 10:35:42PM +1000, Nick Coghlan wrote: not needing an explicit interpreter option makes it more shebang friendly Sorry, I missed something here. How does one combine a zipfile with a shebang script?! Very carefully ;) As a more helpful answer, the ZIP spec allows additional data to be included in the file before the ZIP header. A more common way of using this is to add a zip file on to the end of an ELF executable while still using normal zipfile utilities to read the data in the zip file section and ignore the executable part. It turns out you can actually use the same trick to prepend a shebang line like /usr/bin/env python and a newline character - the whole zip file is still a binary file, but that doesn't prevent the shell from reading that first line of text and handing the file over to Python for execution. The fact that this actually works was also news to me when the issue I linked in my previous post was first brought to my attention :) 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] Documentation for ability to execute zipfiles directories
On Wed, Mar 05, 2008 at 12:14:04AM +1000, Nick Coghlan wrote: As a more helpful answer, the ZIP spec allows additional data to be included in the file before the ZIP header. A more common way of using this is to add a zip file on to the end of an ELF executable while still using normal zipfile utilities to read the data in the zip file section and ignore the executable part. It turns out you can actually use the same trick to prepend a shebang line like /usr/bin/env python and a newline character That's what I thought, too. - the whole zip file is still a binary file, but that doesn't prevent the shell from reading that first line of text and handing the file over to Python for execution. Unix doesn't distinguish text and binary files. (-: The fact that this actually works was also news to me when the issue I linked in my previous post was first brought to my attention :) So it really works? Amazing! Thank you! Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ 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] Windows buildbot test_bsddb3 problems (was RE: Buildbots for trunk are all red)
Spent some time on my buildbot (x86 2k8 trunk) this morning trying to track down why test_bsddb3 is failing (trunk with db-4.4.20). The first test that fails is this: test01_GetsAndPuts (bsddb.test.test_basics.BasicBTreeWithEnvTestCase) ... ERROR That's slightly misleading though as the test runs fine -- the actual exception is being thrown in test_basics.BasicTestCase.tearDown() when os.remove() is called against the first db file (i.e. '__db.001'): WindowsError: [Error 5] Access is denied: 'c:\users\trent~1.nel\appdata\local\temp\2\db_home2808\__db.001 This isn't surprising, given that the python_d.exe process still seems to have __db.001, __db.002 and __db.003 open at the time os.remove() is called. The aforementioned tearDown() method looks like this: def tearDown(self): self.d.close() if self.env is not None: test_support.rmtree(self.homeDir) self.env.close() ## Make a new DBEnv to remove the env files from the home dir. ## (It can't be done while the env is open, nor after it has been ## closed, so we make a new one to do it.) #e = db.DBEnv() #e.remove(self.homeDir) #os.remove(os.path.join(self.homeDir, self.filename)) else: os.remove(self.filename) If I switch the order of statements such that self.env.close() is called before test_suppot.rmtree(self.homeDir), this particular test and a host of others that were also failing now pass (a runtime abort is no longer raised by the CRT half way into the tests either). (Note that the order was switched to that shown above by Neal in r61052 on Feb 24th, which is when these issues started occurring.) That said, there are still a lot more test failures down the track once this change has been made, either via the access denied WindowsError, or a DBInvalidArgError, e.g.: ERROR: test02_WithSource (bsddb.test.test_recno.SimpleRecnoTestCase) -- Traceback (most recent call last): File S:\src\svn\svn.python.org\projects\python\trunk\lib\bsddb\test\test_recno.py, line 33, in tearDown test_support.rmtree(self.homeDir) File S:\src\svn\svn.python.org\projects\python\trunk\lib\test\test_support.py, line 70, in rmtree shutil.rmtree(path) File S:\src\svn\svn.python.org\projects\python\trunk\lib\shutil.py, line 184, in rmtree onerror(os.remove, fullname, sys.exc_info()) File S:\src\svn\svn.python.org\projects\python\trunk\lib\shutil.py, line 182, in rmtree os.remove(fullname) WindowsError: [Error 5] Access is denied: 'c:\\users\\trent~1.nel\\appdata\\local\\temp\\2\\db_home4656\\tmp04_knk' == ERROR: test01_1WriterMultiReaders (bsddb.test.test_thread.BTreeConcurrentDataStore) -- Traceback (most recent call last): File S:\src\svn\svn.python.org\projects\python\trunk\lib\bsddb\test\test_thread.py, line 62, in setUp self.env.open(homeDir, self.envflags | db.DB_CREATE) DBInvalidArgError: (22, 'Invalid argument -- configured environment flags incompatible with existing environment') The DBInvalidArgError exception is only raised after a previous WindowsError is encountered, so I assume it's a side-effect of the tearDown() method not cleaning the environment correctly. It seems this comment in tearDown() is quite pertinent to our situation: ## Make a new DBEnv to remove the env files from the home dir. ## (It can't be done while the env is open, nor after it has been ## closed, so we make a new one to do it.) #e = db.DBEnv() #e.remove(self.homeDir) #os.remove(os.path.join(self.homeDir, self.filename)) Not sure why this is commented out -- quick search of svn history indicates it's been like that for at least the last year and a half. Will have some more time this evening to spend on this, however, work calls at the moment. Regards, Trent. From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Facundo Batista [EMAIL PROTECTED] Sent: 26 February 2008 06:22 To: Thomas Hervé Cc: python-dev@python.org Subject: Re: [Python-Dev] Buildbots for trunk are all red 2008/2/25, Thomas Hervé [EMAIL PROTECTED]: I've worked on that problem during the bug day. I've open a ticket with a patch at http://bugs.python.org/issue2168. Most of the buildbots are green now!!! Thank you all! This community is as awesome as Python itself, ;) Three remains in red, though: - Alpha Tru64: test_smtplib.py is flaky, and _ssl.c is not compiled correctly. Neil is hunting this, I think. - X86 XP-3: seems to crash after test_bsddb3.py. - X86 XP-4: idem. For this two, how can be tried if the bsddb lib in those windows is correctly installed? Thanks again. -- .Facundo Blog:
Re: [Python-Dev] Documentation for ability to execute zipfiles directories
At 05:40 PM 3/4/2008 +0300, Oleg Broytmann wrote: On Wed, Mar 05, 2008 at 12:14:04AM +1000, Nick Coghlan wrote: As a more helpful answer, the ZIP spec allows additional data to be included in the file before the ZIP header. A more common way of using this is to add a zip file on to the end of an ELF executable while still using normal zipfile utilities to read the data in the zip file section and ignore the executable part. It turns out you can actually use the same trick to prepend a shebang line like /usr/bin/env python and a newline character That's what I thought, too. - the whole zip file is still a binary file, but that doesn't prevent the shell from reading that first line of text and handing the file over to Python for execution. Unix doesn't distinguish text and binary files. (-: The fact that this actually works was also news to me when the issue I linked in my previous post was first brought to my attention :) So it really works? Amazing! Setuptools has been distributed this way for some time: http://pypi.python.org/pypi/setuptools#cygwin-mac-os-x-linux-other It actually contains an entire shell script prefix that launches Python and invokes an entry point inside the egg. With the new interpreter capability, this would've been a *lot* simpler to implement. ___ 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] Windows buildbot test_bsddb3 problems (was RE: Buildbots for trunk are all red)
Trent, thanks for working on the buildbot. I fixed the first case you mentioned in r61233 wrt removing the directory before closing the file. It would be great if you could submit a patch when you are able to fix the remaining problems. Cheers, n On Tue, Mar 4, 2008 at 6:58 AM, Trent Nelson [EMAIL PROTECTED] wrote: Spent some time on my buildbot (x86 2k8 trunk) this morning trying to track down why test_bsddb3 is failing (trunk with db-4.4.20). The first test that fails is this: test01_GetsAndPuts (bsddb.test.test_basics.BasicBTreeWithEnvTestCase) ... ERROR That's slightly misleading though as the test runs fine -- the actual exception is being thrown in test_basics.BasicTestCase.tearDown() when os.remove() is called against the first db file (i.e. '__db.001'): WindowsError: [Error 5] Access is denied: 'c:\users\trent~1.nel\appdata\local\temp\2\db_home2808\__db.001 This isn't surprising, given that the python_d.exe process still seems to have __db.001, __db.002 and __db.003 open at the time os.remove() is called. The aforementioned tearDown() method looks like this: def tearDown(self): self.d.close() if self.env is not None: test_support.rmtree(self.homeDir) self.env.close() ## Make a new DBEnv to remove the env files from the home dir. ## (It can't be done while the env is open, nor after it has been ## closed, so we make a new one to do it.) #e = db.DBEnv() #e.remove(self.homeDir) #os.remove(os.path.join(self.homeDir, self.filename)) else: os.remove(self.filename) If I switch the order of statements such that self.env.close() is called before test_suppot.rmtree(self.homeDir), this particular test and a host of others that were also failing now pass (a runtime abort is no longer raised by the CRT half way into the tests either). (Note that the order was switched to that shown above by Neal in r61052 on Feb 24th, which is when these issues started occurring.) That said, there are still a lot more test failures down the track once this change has been made, either via the access denied WindowsError, or a DBInvalidArgError, e.g.: ERROR: test02_WithSource (bsddb.test.test_recno.SimpleRecnoTestCase) -- Traceback (most recent call last): File S:\src\svn\svn.python.org\projects\python\trunk\lib\bsddb\test\test_recno.py, line 33, in tearDown test_support.rmtree(self.homeDir) File S:\src\svn\svn.python.org\projects\python\trunk\lib\test\test_support.py, line 70, in rmtree shutil.rmtree(path) File S:\src\svn\svn.python.org\projects\python\trunk\lib\shutil.py, line 184, in rmtree onerror(os.remove, fullname, sys.exc_info()) File S:\src\svn\svn.python.org\projects\python\trunk\lib\shutil.py, line 182, in rmtree os.remove(fullname) WindowsError: [Error 5] Access is denied: 'c:\\users\\trent~1.nel\\appdata\\local\\temp\\2\\db_home4656\\tmp04_knk' == ERROR: test01_1WriterMultiReaders (bsddb.test.test_thread.BTreeConcurrentDataStore) -- Traceback (most recent call last): File S:\src\svn\svn.python.org\projects\python\trunk\lib\bsddb\test\test_thread.py, line 62, in setUp self.env.open(homeDir, self.envflags | db.DB_CREATE) DBInvalidArgError: (22, 'Invalid argument -- configured environment flags incompatible with existing environment') The DBInvalidArgError exception is only raised after a previous WindowsError is encountered, so I assume it's a side-effect of the tearDown() method not cleaning the environment correctly. It seems this comment in tearDown() is quite pertinent to our situation: ## Make a new DBEnv to remove the env files from the home dir. ## (It can't be done while the env is open, nor after it has been ## closed, so we make a new one to do it.) #e = db.DBEnv() #e.remove(self.homeDir) #os.remove(os.path.join(self.homeDir, self.filename)) Not sure why this is commented out -- quick search of svn history indicates it's been like that for at least the last year and a half. Will have some more time this evening to spend on this, however, work calls at the moment. Regards, Trent. From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Facundo Batista [EMAIL PROTECTED] Sent: 26 February 2008 06:22 To: Thomas Hervé Cc: python-dev@python.org Subject: Re: [Python-Dev] Buildbots for trunk are all red 2008/2/25, Thomas Hervé [EMAIL PROTECTED]: I've worked on that problem during the bug day. I've open a ticket with a patch at http://bugs.python.org/issue2168.
Re: [Python-Dev] Windows buildbot test_bsddb3 problems (was RE: Buildbots for trunk are all red)
2008/3/4, Trent Nelson [EMAIL PROTECTED]: Spent some time on my buildbot (x86 2k8 trunk) this morning trying to track down why test_bsddb3 is failing (trunk with db-4.4.20). The first test that fails is this: Thank you very much!! Regards, -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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] Documentation for ability to execute zipfiles directories
On Tue, Mar 04, 2008 at 08:58:57AM -0500, Steve Holden wrote: While I hesitate to suggest a change of such magnitude, there's something to recommend the old IBM mainframe approach of separating out Principles of Operation (which would be the reference manuals, in Python's case the Language and Library refs) from Users' Guide which contains the practical stuff you need to actually make use of a product. Good suggestion. Using the debugger and profiler could also be covered in the User's Guide. Would splitting up the docs make them more useful for IronPython/Jython? For example, Jython could eventually take the 2.6 language docs as-is, but modify the library reference to remove unsupported modules and add Jython-specific ones. --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] Documentation for ability to execute zipfiles directories
Steve Holden schrieb: Paul Moore wrote: On 04/03/2008, Nick Coghlan [EMAIL PROTECTED] wrote: Do we need a new appendix to the tutorial which goes into detail about the CPython interpreter's command line options, environment variables and details on what can be executed? There is a Python man page, which covers the command line usage. However, it's separate from the documentation, and it isn't bundled with the Windows installers - both of which are a real pain (for me, at least). I'd suggest taking the man page, adding the information about executing zip files and directories, and putting the whole lot into the formal documentation. Look no further: http://docs.python.org/dev/using/cmdline.html There's even more platform-specific stuff at http://docs.python.org/dev/using/. The big problem is that there isn't really anywhere in the docs which is formally CPython-specific. My preference would be to put it in the language reference, as a new chapter (between the current chapters 1 and 2) called Invoking the Python Interpreter. The Using Python documentation section could be marked as CPython specific very well. You could also make the manpage a new document, called Invoking Python, but it's a bit small to warrant a ful document. An appendix to the Tutorial is OK, I guess, but personally I never think of looking at the tutorial (I've been using Python too long to feel that I need a tutorial any more, although the quality of my code probably says otherwise :-)) While I hesitate to suggest a change of such magnitude, there's something to recommend the old IBM mainframe approach of separating out Principles of Operation (which would be the reference manuals, in Python's case the Language and Library refs) from Users' Guide which contains the practical stuff you need to actually make use of a product. I've always found it rather counter-intuitive that you have to go to the Library Reference manual to find information about Python's built-in types, for example. I though the whole point of libraries was that they *aren't* built in, and represent baggage that should only be carried on necessary trips. You speak my mind. For ages I've wanted to put the builtins together with the language reference into a new document called Python Core Language. I've just never had the time to draft a serious proposal. I believe with 3.0 the biggest improvement we could make to the language for newcomers would be to reorganize our documentation so that things live in the places they belong rather than the place they landed and got stuck over time. I fully agree. Georg ___ 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 XML Validator
On Thu, 28 Feb 2008 23:42:49 + (UTC) Medhat Gayed [EMAIL PROTECTED] wrote: lxml is good but not written in python and difficult to install and didn't work on MacOS X. lxml is built on top of libxml2/libxslt, which are bundled with most Unix-like OS's (including Mac OS X), or available in their package systems. Trying to install it from the repository is a PITA, because it uses both the easyinstall and Pyrex (later Cython) packages - which aren't bundled with anything. On the other hand, if it's in the package system (I no longer have macports installed anywhere, but believe it was there at one time), that solves all those problems. I believe they've excised the easyinstall source dependencies, though. Using lxml on OS X Tiger was problematical, because the versions of python, libxml2 and libxslt provided with Tiger were pretty much all older than lxml supported; I built python from macports, including current versions of libxml2, libxslt and lxml, and everything worked with no problems. (I later stopped working with this on the Mac because I need cx_Oracle as well, which doesn't exist for intel macs). On Leopard, Python is up to date, but libxml/libxslt seems a bit behind for lxml 2.0.x (no schematron support being the obvious problem). I went back to the 1.3.6 source tarball (which is what I'm using everywhere anyway), and python setup.py install worked like a charm. (So it looks the easyinstall dependency is gone). Of course, the real issue here is that, while Python may come with batteries included you only get the common sizes like A, C and D. If you need a B cell, you're on your own. In XML land, validation is one such case. Me, I'd like complete xpath support, and xslt as well. But this happens with other subsystems, like doing client-side SSL support, but not server-side (at least, not as of 2.4; I haven't checked 2.5). If you just want an xml module in the standard library that's more complete, I'd vote for the source distribution of lxml, as that's C + Python and built on top of commonly available libraries. The real issue would be making current lxml work with the outdated versions of those libraries found in current OS distributions. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ 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] Windows buildbot test_bsddb3 problems (was RE: Buildbots for trunk are all red)
Trent, thanks for working on the buildbot. I fixed the first case you mentioned in r61233 wrt removing the directory before closing the file. It would be great if you could submit a patch when you are able to fix the remaining problems. Nod, found a few more things now that test_bsddb3 isn't causing a CRT abortion. tmpfile() needs to be reworked on Windows, see http://bugs.python.org/issue2232. Going to spend some more time on it this evening. I'm determined to see a flippin' green build/test status for my slave if it kills me : Trent. ___ 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] Documentation reorganization [was: ... for ability to execute zipfiles directories]
Georg Brandl writes: You speak my mind. For ages I've wanted to put the builtins together with the language reference into a new document called Python Core Language. I've just never had the time to draft a serious proposal. I think that combination is reasonable, but I would like to see the clear division between the language (ie, the syntax) and the built-in functionality maintained. I'm not sure I like the proposed title for that reason. ___ 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] Compiler used to build Python for Windows
I know this is a topic which has been discussed before (more than once). I'm just adding one more data point. Python.org currently uses VS2003's compiler for building the distributed Windows binaries for Python. Unfortunately, there's a nasty bug in the runtime libraries that support this compiler which causes Python to give the wrong answer when you ask what time it is in most US time zones for four weeks of the year (daylight saving time is observed in that country for four more weeks than those Microsoft's libraries think it is). Even more unfortunate, the patch Microsoft offers is not for the redistributable libraries directly, but for Visual Studio. Worse, Microsoft advises against applying the patch at all, implying that insufficient testing has taken place, urging instead that customers wait for a service pack for Visual Studio which corrects the bug. We've been waiting more than a year, without any indication from MS that this service pack will ever materialize, and it doesn't apply to non-development machines anyway. Every indication seems to point to effective abandonment by Microsoft of those who still use this version of the compiler. http://support.microsoft.com/kb/932299 We don't have conclusive evidence that later versions of Visual Studio are not affected by this bug, but the only KB article we have found for the bug is specific to C runtime library for the 2003 compiler. Any possibility of revisiting this question (upgrading to a more recent compiler for Windows builds of Python)? -- Bob Kline http://www.rksystems.com mailto:[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] Documentation reorganization [was: ... for ability to execute zipfiles directories]
On Tue, Mar 4, 2008 at 3:13 PM, Stephen J. Turnbull [EMAIL PROTECTED] wrote: Georg Brandl writes: You speak my mind. For ages I've wanted to put the builtins together with the language reference into a new document called Python Core Language. I've just never had the time to draft a serious proposal. I think that combination is reasonable, but I would like to see the clear division between the language (ie, the syntax) and the built-in functionality maintained. I'm not sure I like the proposed title for that reason. Such a division would make it unnecessarily hard to find documentation on True, False, None, etc. They've become keywords for pragmatic purposes (to prevent accidental modification), not because we think they ideally should be syntax instead of builtins. -- Adam Olsen, aka Rhamphoryncus ___ 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] Compiler used to build Python for Windows
Bob Kline wrote: Any possibility of revisiting this question (upgrading to a more recent compiler for Windows builds of Python)? The latest alphas of Python 2.6 and 3.0 are build with VS 2088. I've spent some time to get the new build system ready for Python 3.0a2. Is VS 2008 recent enought for you? :] Christian ___ 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] Compiler used to build Python for Windows
Any possibility of revisiting this question (upgrading to a more recent compiler for Windows builds of Python)? Python 2.6 is built with Visual Studio 2008. 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] Compiler used to build Python for Windows
Christian Heimes wrote: Bob Kline wrote: Any possibility of revisiting this question (upgrading to a more recent compiler for Windows builds of Python)? The latest alphas of Python 2.6 and 3.0 are build with VS 2088. I've spent some time to get the new build system ready for Python 3.0a2. Is VS 2008 recent enought for you? :] Yes, thanks! I would hope Microsoft has fixed that bug by now. :-) -- Bob Kline http://www.rksystems.com mailto:[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] Compiler used to build Python for Windows
Bob Kline wrote: Christian Heimes wrote: Is VS 2008 recent enought for you? :] Yes, thanks! I would hope Microsoft has fixed that bug by now. :-) And yes, indeed, the bug is gone in Python 2.6. -- Bob Kline http://www.rksystems.com mailto:[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] Compiler used to build Python for Windows
Christian Heimes wrote: The latest alphas of Python 2.6 and 3.0 are build with VS 2088. Wow, that must be a very, very pre-alpha release... Or has someone at Redmond stolen Guido's time machine? -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiem! | 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] Documentation reorganization [was: ... for ability to execute zipfiles directories]
Adam Olsen wrote: Such a division would make it unnecessarily hard to find documentation on True, False, None, etc. They've become keywords for pragmatic purposes (to prevent accidental modification), not because we think they ideally should be syntax instead of builtins. Maybe the solution is to rename the Library Reference to the Class and Module Reference or something like that. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiem! | 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
[Python-Dev] BSDDB3 (was: Re: Buildbots for trunk are all red)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 A.M. Kuchling wrote: | Doing a code search finds a fair number of users of the module: Zope's | BDBStorage, Mailman 2.x's archiver, 4Suite, PyTone, OuterSpace, | Chandler, BioPython. I'm pybsddb maintainer since late January. Maintainer transfering ownership is going a bit slow, since both Greg and I are busy guys. Also, I have no commit access to python svn, and I'm barely familiar with practices here (just reading PEP are not enough); managing by proxy is a bit... difficult. That said, it is my aim to keep bsddb in stdlib, providing a stable and featureful module. I think keeping bsddb development inside python svn is not appropiate. Currently (I could change idea), my approach will be keeping pybssdb as a separate project and sync with python SVN from time to time. Mainly to take advantage of buildbot architecture and, of course, to be able to release python with current bindings. Since I have no python commit access, this seems a sensible approach. And I could do frequent pybssdb releases (let say, every couple of months) without waiting for a full python release (current approach). I see a lot of complains about bsddb3 in stdlib, spitting buildbot red status, and such. I want to help there. Just remember that I have no direct control over python svn and, although I spend last 28 years breathing computer programming (python since 1998), I'm a newbie in python-dev policies and procedures. PS: I have tried to sign the Python Contributor Agreement, but I am not sure about current pybsddb license terms. Help welcomed. - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ [EMAIL PROTECTED] http://www.argo.es/~jcea/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:[EMAIL PROTECTED] _/_/_/_/ _/_/_/_/_/ ~ _/_/ _/_/_/_/ _/_/ _/_/ Things are not so easy _/_/ _/_/_/_/ _/_/_/_/ _/_/ My name is Dump, Core Dump _/_/_/_/_/_/ _/_/ _/_/ El amor es poner tu felicidad en la felicidad de otro - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBR83fUZlgi5GaxT1NAQIx5AP/VR6HD3HBGbYBl+OeMkL+cHUFgBljIZgl T/N1T2CnertBc6EqEJ2ejEfMuVJF/icCyzwmldXbQWsVjd9XFq7gVGe7h9r7RTc5 DaiBrZk2ZBVEXk5Vp+QcWiyObMU4dYYF5JRyjRl4hCdKPRXo1TLTkQchoc945ubc VEgLgCHROcE= =1I5Z -END PGP SIGNATURE- ___ 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] Buildbots for trunk are all red
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christian Heimes wrote: | Oh yeah ... ZODB4 and BDBStorage ... a dark chapter starting with high | hopes and ending in tragedy ... Several projects like Zope and | Subversion worked hard on a a Berkeley DB backend but in the end all | projects had the same fate. | | A few years ago in Göteborg/SE during lunch Jim explained me the reasons | for the cancellation. As far as I remember the conversation he used some | words I dare not to repeat in public. Some kids may read the Python dev | list. :) I would like to know. Private email is fine to me :-). - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ [EMAIL PROTECTED] http://www.argo.es/~jcea/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:[EMAIL PROTECTED] _/_/_/_/ _/_/_/_/_/ ~ _/_/ _/_/_/_/ _/_/ _/_/ Things are not so easy _/_/ _/_/_/_/ _/_/_/_/ _/_/ My name is Dump, Core Dump _/_/_/_/_/_/ _/_/ _/_/ El amor es poner tu felicidad en la felicidad de otro - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBR83gCZlgi5GaxT1NAQJXKgQAkq6E9zmLRPPINh0rfDy/cOQTY74IS8BP SnBbx2/317nTxe7aNMY4HUAMptA5cae5LKOW+b7+WuHn+F2DMmfbKxvq4PHop2b3 zx9Q3lv4qk6p0ZYL6KLuis5sYivpejuxbRgwFI2m8gkdFsRh5a0MgmVG0b4768TW 6c9ELDY/Xr0= =7pRA -END PGP SIGNATURE- ___ 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 XML Validator
In article [EMAIL PROTECTED], Mike Meyer [EMAIL PROTECTED] wrote: On Thu, 28 Feb 2008 23:42:49 + (UTC) Medhat Gayed [EMAIL PROTECTED] wrote: lxml is good but not written in python and difficult to install and didn't work on MacOS X. lxml is built on top of libxml2/libxslt, which are bundled with most Unix-like OS's (including Mac OS X), or available in their package systems. Trying to install it from the repository is a PITA, because it uses both the easyinstall and Pyrex (later Cython) packages - which aren't bundled with anything. On the other hand, if it's in the package system (I no longer have macports installed anywhere, but believe it was there at one time), that solves all those problems. I believe they've excised the easyinstall source dependencies, though. [...] If you just want an xml module in the standard library that's more complete, I'd vote for the source distribution of lxml, as that's C + Python and built on top of commonly available libraries. The real issue would be making current lxml work with the outdated versions of those libraries found in current OS distributions. I'm not sure what you perceive to be the problems with easy_install on OSX; I find it makes life *much* simpler for managing python packages. Be that as it may, since the release of lxml 2.0, the project has updated the lxml website with useful information about source installations and, in particular, OSX source installations: http://codespeak.net/lxml/build.html IIRC, here's what worked for me on Leopard (10.5.2) using the python.org 2.5.2, though it should work fine with the Apple-supplied 2.5.1: 1. Download and build source tarballs of recent libxml2 (at the moment 2.6.31 is the latest, OSX 10.5.2 has 2.6.16) and libxlst (1.1.22 vs 1.1.12) from xmlsoft.org and then install them to /usr/local/. (Don't bother with the python bindings unless they're needed for some other package.) 2. As noted on the lxml source page, Cython is not needed to install lxml and can complicate matters so, as suggested, if you have Cython (or Pyrex, for that matter) installed in the Python path you're going to install to, temporarily remove it(/them). 3. Using the lxml 2.0.x source tarball: /path/to/python setup.py install \ --with-xslt-config=/usr/local/bin/xslt-config 4. Verify installation: $ which python /usr/local/bin/python $ python Python 2.5.2 (r252:60911, Feb 22 2008, 07:57:53) [GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin Type help, copyright, credits or license for more information. from lxml import etree print etree.LXML_VERSION (2, 0, 2, 0) print etree.LIBXML_VERSION (2, 6, 31) print etree.LIBXML_COMPILED_VERSION (2, 6, 31) print etree.LIBXSLT_VERSION (1, 1, 22) print etree.LIBXSLT_COMPILED_VERSION (1, 1, 22) Clearly there are other ways to do this but HTH. -- Ned Deily, [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] Buildbots for trunk are all red
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Guido van Rossum wrote: | Correction: the subversion BerkeleyDB backend is still very much alive | and kicking. There were some early issues (they did things that | SleepyCat told them not to do :-) but it was corrected and it's still | working fine for several large users. I use BerkeleyDB everyday in a lot of application critical environments, like mailbox storage and such, specially combined with Durus persistence engine. I have medical clients with hundred of terabytes of data under Durus+BerkeleyDB, happy and glad to have met me :). PS: Yes I tried also ZODB+BerkeleyDB. It was ugly and unusable (sigh!), but I don't know why you suppose BerkeleyDB was the one to blame. - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ [EMAIL PROTECTED] http://www.argo.es/~jcea/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:[EMAIL PROTECTED] _/_/_/_/ _/_/_/_/_/ ~ _/_/ _/_/_/_/ _/_/ _/_/ Things are not so easy _/_/ _/_/_/_/ _/_/_/_/ _/_/ My name is Dump, Core Dump _/_/_/_/_/_/ _/_/ _/_/ El amor es poner tu felicidad en la felicidad de otro - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBR83hLJlgi5GaxT1NAQJJ0wQAhjmGh5CWxaiEEkduXuJJFTl1kr4mg8Rr i5Fy+xuquYXScGlv8p0O2G7B+bqji+46cuhk6htuFfXpfIBXBW7QSTBDS4KlsD2+ 8dHxZvKg7irH1rISD6mOfeeAkqFWcVFOBgLOGbwU1EPD+Jfqppaa2dPZ0XemHQon ve3ZAC6wWyg= =xecT -END PGP SIGNATURE- ___ 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 2.6 and 3.0 ...and applink.c?
Bugbee, Larry wrote: Is there a reason why Python.exe cannot be built using gcc instead of Visual Studio? It seems building everything with gcc would get around the problem of having to match VS versions. As I understand it, the problem isn't the compiler so much as the stdio library being used. As long as there is no single standard C library used by everyone for all Windows applications, the problem will exist in one form or another whichever compiler is used. If the standard Python were build with gcc using the GNU libc, everyone would be required to compile extensions against *that* library instead. If it were compiled with gcc but using one of the Microsoft libraries, the same situation would exist as before. The entire mess is all Microsoft's fault for not picking one version of libc and sticking to it. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiem! | 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] Buildbots for trunk are all red
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christian Heimes wrote: | More than 5 years ago Zope Corp was working on a Berkeley DB backend for | ZODB. It was more of a marketing decision to show large companies that | ZODB is using a well known database instead of a self made one. The | project failed due to problems with the Berkeley db. I vaguely remember | something with transactions and speed ... BerkeleyDB transaction performance, like any other ACID database, is limited to disk performance (unless you have a non volatile ram, of course). Using ext2 and such, you are happy if you get 30-50 transactions per second. Using nice Solaris ZFS, I do a transaction per rotation; that is, 120 transactions per second with a consumer level 7200RPM disk. PS: Until Oracle takeover, BerkeleyDB was the heart of MySQL transactional engine. I don't like mysql, but not for its use of BerkeleyDB :-). - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ [EMAIL PROTECTED] http://www.argo.es/~jcea/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:[EMAIL PROTECTED] _/_/_/_/ _/_/_/_/_/ ~ _/_/ _/_/_/_/ _/_/ _/_/ Things are not so easy _/_/ _/_/_/_/ _/_/_/_/ _/_/ My name is Dump, Core Dump _/_/_/_/_/_/ _/_/ _/_/ El amor es poner tu felicidad en la felicidad de otro - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBR83ia5lgi5GaxT1NAQJ5NwP/bIBXEDO3158cnAQhfz2TH70aPK7T3YDg SD3FQMoALNSKb5JP8MsMicRB9JcQUdmznEmi3L2C5TrhvLv/Rb2GBZVyJqqGrFn/ ceBYwIzbV2utniWkk7J7bUWisutZQp72//6CNZFNqM6kPA/MLSngm732V1ZX6JRC vzhsWQhO9i8= =2AQ8 -END PGP SIGNATURE- ___ 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] Documentation reorganization [was: ... for ability to execute zipfiles directories]
Greg Ewing wrote: Adam Olsen wrote: Such a division would make it unnecessarily hard to find documentation on True, False, None, etc. They've become keywords for pragmatic purposes (to prevent accidental modification), not because we think they ideally should be syntax instead of builtins. Maybe the solution is to rename the Library Reference to the Class and Module Reference or something like that. Although DRY is fine as a programming principle, it fails for pedagogic purposes. We should therefore be prepared to repeat the same material in different contexts (hopefully by including some common documentation source rather than laborious and error-prone copy-and-paste). Document things where people expect to find them. (Now *there's* a usability study screaming to be done ... and SoC is coming up). regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.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] [Python-3000] No releases tonight
On Sun, Mar 02 2008 at 05:49:35AM BRT, Jeroen Ruigrok van der Werven [EMAIL PROTECTED] wrote: -On [20080301 19:57], Christian Heimes ([EMAIL PROTECTED]) wrote: I also propose translations of the shorter text to important languages like French, German, Japanese, Portuguese and Spanish. I'm willing to help with the German translation. I can probably get a translation done in Japanese, Chinese and Korean. For Portuguese I guess we could ask the ASync guys in Brazil, they're huge Python users with their work for Canonical/Ubuntu. I could write the Portuguese translation. rbp ___ 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 XML Validator
Mike Meyer wrote: Trying to install it from the repository is a PITA, because it uses both the easyinstall and Pyrex It shouldn't depend on Pyrex as long as it's distributed with the generated C files. If it's not, that's an oversight on the part of the distributor. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiem! | 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] Compiler used to build Python for Windows
Christian Heimes wrote: Bob Kline wrote: Any possibility of revisiting this question (upgrading to a more recent compiler for Windows builds of Python)? The latest alphas of Python 2.6 and 3.0 are build with VS 2088. I've Been out in the time machine, eh? spent some time to get the new build system ready for Python 3.0a2. Is VS 2008 recent enought for you? :] It would be really nice if we could maintain two parallel Windows versions, one with an open source tool chain like Mingw and one with the latest and greatest MS production line. Unfortunately the problem seems to be developer effort. For a long time only Martin and Tim were serious about the Windows platform, and I can appreciate (some of) the extra effort that parallel development platforms would require. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.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] Documentation reorganization [was: ... for ability to execute zipfiles directories]
On Tue, Mar 4, 2008 at 5:04 PM, Steve Holden [EMAIL PROTECTED] wrote: Greg Ewing wrote: Adam Olsen wrote: Such a division would make it unnecessarily hard to find documentation on True, False, None, etc. They've become keywords for pragmatic purposes (to prevent accidental modification), not because we think they ideally should be syntax instead of builtins. Maybe the solution is to rename the Library Reference to the Class and Module Reference or something like that. Although DRY is fine as a programming principle, it fails for pedagogic purposes. We should therefore be prepared to repeat the same material in different contexts (hopefully by including some common documentation source rather than laborious and error-prone copy-and-paste). Document things where people expect to find them. (Now *there's* a usability study screaming to be done ... and SoC is coming up). Python's usage of import makes it clear when something is imported from a library, as opposed to being an integral part of the language. To me, this is an obvious basis on whether to look in the language reference or in the stdlib reference. That said, it would be useful to also have a link for major builtin types in the stdlib section, if only for people who learned to look for them there. -- Adam Olsen, aka Rhamphoryncus ___ 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] Compiler used to build Python for Windows
Greg Ewing wrote: Christian Heimes wrote: The latest alphas of Python 2.6 and 3.0 are build with VS 2088. Wow, that must be a very, very pre-alpha release... Or has someone at Redmond stolen Guido's time machine? DA-LEK ... EX-TER-MI-NATE *scnr* :) Christian ___ 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] Compiler used to build Python for Windows
On Tue, Mar 4, 2008 at 5:10 PM, Steve Holden [EMAIL PROTECTED] wrote: Christian Heimes wrote: Bob Kline wrote: Any possibility of revisiting this question (upgrading to a more recent compiler for Windows builds of Python)? The latest alphas of Python 2.6 and 3.0 are build with VS 2088. I've Been out in the time machine, eh? spent some time to get the new build system ready for Python 3.0a2. Is VS 2008 recent enought for you? :] It would be really nice if we could maintain two parallel Windows versions, one with an open source tool chain like Mingw and one with the latest and greatest MS production line. Is this mainly a request to use more open source tools? Because if the concern is just cost, Python 2.6 and 3.0 compile with the free Microsoft Visual Studio 2008 Express editions. Steve -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy ___ 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] Compiler used to build Python for Windows
Steven Bethard wrote: On Tue, Mar 4, 2008 at 5:10 PM, Steve Holden [EMAIL PROTECTED] wrote: Christian Heimes wrote: Bob Kline wrote: Any possibility of revisiting this question (upgrading to a more recent compiler for Windows builds of Python)? The latest alphas of Python 2.6 and 3.0 are build with VS 2088. I've Been out in the time machine, eh? spent some time to get the new build system ready for Python 3.0a2. Is VS 2008 recent enought for you? :] It would be really nice if we could maintain two parallel Windows versions, one with an open source tool chain like Mingw and one with the latest and greatest MS production line. Is this mainly a request to use more open source tools? Because if the concern is just cost, Python 2.6 and 3.0 compile with the free Microsoft Visual Studio 2008 Express editions. It was maily a request to use more open source tools, but the decision has to be made by the developers supporting the build chain. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.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] Windows buildbot test_bsddb3 problems (was RE: Buildbots for trunk are all red)
Trent, thanks for working on the buildbot. I fixed the first case you mentioned in r61233 wrt removing the directory before closing the file. It would be great if you could submit a patch when you are able to fix the remaining problems. % svn diff Index: test_dbshelve.py === --- test_dbshelve.py(revision 61233) +++ test_dbshelve.py(working copy) @@ -267,8 +267,8 @@ def tearDown(self): +self.do_close() test_support.rmtree(self.homeDir) -self.do_close() class EnvBTreeShelveTestCase(BasicEnvShelveTestCase): Index: test_thread.py === --- test_thread.py (revision 61233) +++ test_thread.py (working copy) @@ -73,9 +73,9 @@ self.d.open(self.filename, self.dbtype, self.dbopenflags|db.DB_CREATE) def tearDown(self): -test_support.rmtree(self.homeDir) self.d.close() self.env.close() +test_support.rmtree(self.homeDir) def setEnvOpts(self): pass I'm getting 100% success rate with test_bsddb3 on Windows now with this patch. Yay! Trent. -- http://www.onresolve.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
[Python-Dev] signal.alarm(3) in trunk test_socketserver.py
r61099 added the following to trunk/Lib/test/test_socketserver.py: if __name__ == __main__: test_main() + signal.alarm(3) # Shutdown shouldn't take more than 3 seconds. which breaks platforms that don't have signal.alarm, like, say, !unix ;-) Trent. -- http://www.onresolve.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] Documentation reorganization
Adam Olsen writes: On Tue, Mar 4, 2008 at 3:13 PM, Stephen J. Turnbull [EMAIL PROTECTED] wrote: I would like to see the clear division between the language (ie, the syntax) and the built-in functionality maintained. I'm not sure I like the proposed title for that reason. Such a division would make it unnecessarily hard to find documentation on True, False, None, etc. They've become keywords for pragmatic purposes (to prevent accidental modification), not because we think they ideally should be syntax instead of builtins. This is Python; of course practicality beats purity. I have no problem with putting some keywords in the built-in functionality section, or even (boggle) duplicate them across the two sections. I too was put off by the separation of syntax from built-in functionality when I first started using the documentation, but later I came to appreciate it. I'm a relatively casual user of Python, and having a spare syntax section has made it much easier to learn new syntax such as comprehensions and generators. I suspect it will make it a lot easier to learn the differences between Python 2 and Python 3, too. I do not want to lose that. I don't pretend to be speaking for anyone else, but I'd be surprised if I were unique.wink ___ 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] Compiler used to build Python for Windows
Greg Ewing writes: Christian Heimes wrote: The latest alphas of Python 2.6 and 3.0 are build with VS 2088. Wow, that must be a very, very pre-alpha release... Nah, it's a version optimized for 8/16-bit segmented architectures. ___ 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] signal.alarm(3) in trunk test_socketserver.py
r61099 added the following to trunk/Lib/test/test_socketserver.py: if __name__ == __main__: test_main() + signal.alarm(3) # Shutdown shouldn't take more than 3 seconds. Actually, signal.alarm() was introduced all over the place in that revision. I understand the intent of this commit was to speed up the runtime of this test (something like 28s - 0.3s was quoted in the commit log). FWIW, runtime of the test with the following patch on Windows is 0.125s: Index: test_socketserver.py === --- test_socketserver.py(revision 61233) +++ test_socketserver.py(working copy) @@ -28,6 +28,9 @@ HAVE_UNIX_SOCKETS = hasattr(socket, AF_UNIX) HAVE_FORKING = hasattr(os, fork) and os.name != os2 +def signal_alarm(n): +if hasattr(signal, 'alarm'): +signal.alarm(n) def receive(sock, n, timeout=20): r, w, x = select.select([sock], [], [], timeout) @@ -99,7 +102,7 @@ Test all socket servers. def setUp(self): -signal.alarm(20) # Kill deadlocks after 20 seconds. +signal_alarm(20) # Kill deadlocks after 20 seconds. self.port_seed = 0 self.test_files = [] @@ -112,7 +115,7 @@ except os.error: pass self.test_files[:] = [] -signal.alarm(0) # Didn't deadlock. +signal_alarm(0) # Didn't deadlock. def pickaddr(self, proto): if proto == socket.AF_INET: @@ -267,4 +270,4 @@ if __name__ == __main__: test_main() -signal.alarm(3) # Shutdown shouldn't take more than 3 seconds. +signal_alarm(3) # Shutdown shouldn't take more than 3 seconds. ___ 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] Patch for trunk test_winsound.py (fixes my buildbot)
winsound.Beep fails for me on the 'x86 2k8 trunk' build slave, which is a virtual Windows Server 2008 instance running under Hyper-V. Not surprisingly, there's not a single audio-related device on this system. The attached patch to test_winsound.py incorporates the _have_soundcard() checks to the BeepTest class, which fixes the problem for me. (I've also tested the patch on a Vista system (that does have a soundcard) and everything works as expected.) Trent. test_winsound.py.patch Description: test_winsound.py.patch ___ 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] signal.alarm(3) in trunk test_socketserver.py
On Tue, Mar 4, 2008 at 7:25 PM, Trent Nelson [EMAIL PROTECTED] wrote: r61099 added the following to trunk/Lib/test/test_socketserver.py: if __name__ == __main__: test_main() + signal.alarm(3) # Shutdown shouldn't take more than 3 seconds. Actually, signal.alarm() was introduced all over the place in that revision. I understand the intent of this commit was to speed up the runtime of this test (something like 28s - 0.3s was quoted in the commit log). FWIW, runtime of the test with the following patch on Windows is 0.125s: Yep, the alarm is only there to prevent what would be deadlocks from running forever. Sorry for breaking !unix. Your patch looks fine to me. Do you want to submit it or shall I? Index: test_socketserver.py === --- test_socketserver.py(revision 61233) +++ test_socketserver.py(working copy) @@ -28,6 +28,9 @@ HAVE_UNIX_SOCKETS = hasattr(socket, AF_UNIX) HAVE_FORKING = hasattr(os, fork) and os.name != os2 +def signal_alarm(n): +if hasattr(signal, 'alarm'): +signal.alarm(n) def receive(sock, n, timeout=20): r, w, x = select.select([sock], [], [], timeout) @@ -99,7 +102,7 @@ Test all socket servers. def setUp(self): -signal.alarm(20) # Kill deadlocks after 20 seconds. +signal_alarm(20) # Kill deadlocks after 20 seconds. self.port_seed = 0 self.test_files = [] @@ -112,7 +115,7 @@ except os.error: pass self.test_files[:] = [] -signal.alarm(0) # Didn't deadlock. +signal_alarm(0) # Didn't deadlock. def pickaddr(self, proto): if proto == socket.AF_INET: @@ -267,4 +270,4 @@ if __name__ == __main__: test_main() -signal.alarm(3) # Shutdown shouldn't take more than 3 seconds. +signal_alarm(3) # Shutdown shouldn't take more than 3 seconds. ___ 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/jyasskin%40gmail.com -- Namasté, Jeffrey Yasskin http://jeffrey.yasskin.info/ ___ 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] signal.alarm(3) in trunk test_socketserver.py
Yep, the alarm is only there to prevent what would be deadlocks from running forever. Sorry for breaking !unix. Your patch looks fine to me. Do you want to submit it or shall I? I'm not a committer, so it's all yours. Thanks for the quick turnaround! Trent. ___ 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] Documentation reorganization
On Tue, Mar 4, 2008 at 8:03 PM, Stephen J. Turnbull [EMAIL PROTECTED] wrote: Adam Olsen writes: On Tue, Mar 4, 2008 at 3:13 PM, Stephen J. Turnbull [EMAIL PROTECTED] wrote: I would like to see the clear division between the language (ie, the syntax) and the built-in functionality maintained. I'm not sure I like the proposed title for that reason. Such a division would make it unnecessarily hard to find documentation on True, False, None, etc. They've become keywords for pragmatic purposes (to prevent accidental modification), not because we think they ideally should be syntax instead of builtins. This is Python; of course practicality beats purity. I have no problem with putting some keywords in the built-in functionality section, or even (boggle) duplicate them across the two sections. -1 on duplicating anything. Provide links to a single location instead. Otherwise you end up with two explanations of the same thing, with different wording and subtle differences or missing details. I too was put off by the separation of syntax from built-in functionality when I first started using the documentation, but later I came to appreciate it. I'm a relatively casual user of Python, and having a spare syntax section has made it much easier to learn new syntax such as comprehensions and generators. I suspect it will make it a lot easier to learn the differences between Python 2 and Python 3, too. I do not want to lose that. I learned them through third-party docs. Even now I have a hard time finding list comprehension/generator expression in the docs. Apparently they're in the Expression section, under Displays for lists, sets and dictionaries, and neither that nor anything with list comprehension or generator expression is in the index. The term Displays is pretty obscure as well, not something I've seen used besides on this list or right there in the documentation. I don't pretend to be speaking for anyone else, but I'd be surprised if I were unique.wink Your experiences *shouldn't* be unique, but I'm afraid they might be. Another example is the use of BNF, which although dominant in its field, it provides a steep learning curve for most programmers. I'm afraid this has turned into a rant, but it should be seen as the experiences of someone who relies on the documentation a great deal. Is there a better way to channel feedback on the documentation? -- Adam Olsen, aka Rhamphoryncus ___ 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] Windows buildbots randomly die with twisted ConnectionLost errors?
I've started to see my build slave dying every so often with a twisted error half way through tests: ... test_htmlparser test_httplib remoteFailed: [Failure instance: Traceback (failure with no frames): twisted.internet.error.ConnectionLost: Connection to the other side was lost in a non-clean fashion. ] Examples: http://www.python.org/dev/buildbot/all/x86%20W2k8%20trunk/builds/46/step-test/0 http://www.python.org/dev/buildbot/all/x86%20W2k8%20trunk/builds/36/step-test/0 I'm not sure if I should read into the fact that it's occurring after networking-oriented tests like test_httplib and test_ftplib. Running rt.bat on the resulting build manually doesn't indicate any errors in these tests. Have other Windows buildbot owners seen this? Trent. ___ 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] BSDDB3 (was: Re: Buildbots for trunk are all red)
On Tue, Mar 4, 2008 at 3:46 PM, Jesus Cea [EMAIL PROTECTED] wrote: That said, it is my aim to keep bsddb in stdlib, providing a stable and featureful module. I think keeping bsddb development inside python svn is not appropiate. Currently (I could change idea), my approach will be keeping pybssdb as a separate project and sync with python SVN from time to time. Mainly to take advantage of buildbot architecture and, of course, to be able to release python with current bindings. Since I have no python commit access, this seems a sensible approach. And I could do frequent pybssdb releases (let say, every couple of months) without waiting for a full python release (current approach). I think that approach is fine. Hopefully you can keep the changes reasonably small (preferably less than 500 lines per change). That will ensure more people will review your changes. 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
Re: [Python-Dev] Documentation reorganization
Adam Olsen schrieb: I don't pretend to be speaking for anyone else, but I'd be surprised if I were unique.wink Your experiences *shouldn't* be unique, but I'm afraid they might be. Another example is the use of BNF, which although dominant in its field, it provides a steep learning curve for most programmers. We could of course accompany each BNF-described item with an example. I'm afraid this has turned into a rant, but it should be seen as the experiences of someone who relies on the documentation a great deal. Is there a better way to channel feedback on the documentation? There's of course the doc-SIG, but it's just another mailing list. In any case, the best way to channel feedback is to provide a patch wink Georg ___ 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
