python-dev Summary for 2004-10-16 through 2004-10-31 [draft]
Winter Break is upon me which means I have time to catch up on the Summaries. I will definitely be caught up by the end of the month. As for this summary, I will send this out around Wednesday. As always corrections are appreciated. If you feel one of the skipped threads deserves coverage please feel free to write up a summary and I will edit it and include it. -------------------------------------- ===================== Summary Announcements ===================== `Python 2.4`_ final is now out! As I mentioned in the last summary my school schedule this past quarter has been insane. But now I am on Winter Break and will hopefully be able to catch up on my Summary backlog. .. _Python 2.4: http://www.python.org/2.4/ ========= Summaries ========= -------------------------------------------------------- Specifying main functions and calling packages with '-m' -------------------------------------------------------- In my opinion, the new '-m' command line option in Python 2.4 is really handy. But wouldn't it be even handier if you could execute modules in a package? That exact question came up. The reason this kind of thing didn't just go directly into 2.4 was that the semantics are not as obvious nor is it as simple. A PEP is on the way, though. Until then, you can use Nick Coghlan's recipe at http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/307772. This also brought up the discussion of being able to specify a 'main' function to take the place of the good old ``if __name__ == "__main__"`` idiom. Some liked the idea of allowing one to define a function named 'main', others '__main__'. But the discussion never went any farther. This will require a PEP to ever even be seriously considered. Contributing threads: - `python-dev Summary for 2004-09-16 through 2004-09-30 [draft] <>`__ - `Magic main functions <>`__ - `Supporting packages on the command line <>`__ ---------------------------- ConfigParser shootout begins ---------------------------- As mentioned in the `last summary`_, a desire for a replacement for ConfigParser has come into being. It seems the ideas are being hashed out in the wiki at http://www.python.org/moin/ConfigParserShootout . Contributing threads: - `ConfigParser shootout, preliminary entry <>`__ - `What are the goals for ConfigParser 3000? <>`__ ---------------------------------------------------- Making pymalloc friendlier to long running processes ---------------------------------------------------- Pymalloc, when a small chunk of memory is requested that is less than 256 bytes, fetches the memory from a pool of previously used memory that is now available. While this speeds up memory allocation since it does not directly involve calling the OS to free up the memory, it does cause issues for long running processes that have at some point requested a large portion of memory. The example in the OP for this whole topic was an app that needs 1GB for about five minutes, but the amount of allocated memory stays at 1 GB since pymalloc does not free it to the OS. This was brought up back in June and is summarized at http://www.python.org/dev/summary/2004-06-01_2004-06-15.html#id17 . No code has been checked in at the moment to change the behavior partially thanks to the difficulty of the problem. Contributing threads: - `Changing pymalloc behaviour for long running processes <>`__ - `Re: Python-Dev Digest, Vol 15, Issue 46 <>`__ ---------------------------- How to get a patch looked at ---------------------------- Often times people have a specific patch that they want reviewed/applied to solve a specific problem they are having. Unfortunately the Python developers have limited time; we just can't get to every patch there in a timely fashion. This can be a problem who *really* need to get a patch in. Enter Martin v. Löwis and his deal to review a specific patch: 1. Review 10 other patches on SF 2. Send an email to python-dev listing the 10 patches that you reviewed and the one patch you want to be reviewed 3. Your specific patch gets reviewed by Martin You can see the exact details of Martin's requirements at http://mail.python.org/pipermail/python-dev/2004-October/049495.html and can also read http://www.python.org/dev/dev_intro.html for ideas on what to do for reviewing. Contributing threads: - `Patches <>`__ ---------------------------------------------- Discussion of including pysqlite in the stdlib ---------------------------------------------- The idea of including pysqlite_ in the stdlib came up once again (not this is the wrapper for SQLite_ and not SQLite itself). The arguments for including the module were the SQLite is most likely used more than Sleepycat and thus deserved a place in the stdlib if bsddb did. It also goes along with Python's idea of "batteries included". Arguments against started with the idea of sanctioning pysqlite over other SQLite wrappers did not seem proper. People also thought that including bsddb might not be correct anymore and thus should not be used as a basis for including pysqlite. This all then led into a discussion about package management and how to simplify extending what can be installed at compile-time. The idea of pushing PyPI_ came up as well as revising `PEP 206`_. .. _pysqlite: http://pysqlite.org/ .. _SQLite: http://www.sqlite.org/ .. _PyPI: http://www.python.org/pypi .. _PEP 206: http://www.python.org/peps/pep-0206.html Contributing threads: - `SQLite module for Python 2.5 <>`__ =============== Skipped Threads =============== - Python 2.4b1 on win32 installer bug? - test_subprocess 2.4b1 fails on FreeBSD 5.2 - adding Py{String|Unicode}_{Lower|Upper} and fixing CreateProcess in _subprocess.pyd and PyWin32 - IPv6 bug in 2.3.4?? - logging needs better documentation - bsddb todo for someone - auto-upgrade db format - Tests broken on Windows - import w/options - Adding a developer People are only added as a developer if they ask for it and have shown they are going to stick around - audiotest.au and possible copyright issues? - Re: [Python-checkins] python/dist/src/Pythoncompile.c, 2.330, 2.331 - Bug [ 959379 ] Implicit close() should check for errors - weakref callback vs gc vs threads
Brett C. wrote:
This also brought up the discussion of being able to specify a 'main' function to take the place of the good old ``if __name__ == "__main__"`` idiom. Some liked the idea of allowing one to define a function named 'main', others '__main__'. But the discussion never went any farther. This will require a PEP to ever even be seriously considered.
There's a PEP already - PEP 299. The PEP actually describes a reasonable approach, since code using the current idiom is unlikely to define a __main__() function. However, it seems more like a Py3K idea, since if it's only in 2.5 and later, we'd see code like this to support earlier 2.x versions: ========================== def __main__(*args): ... if __name__ == "__main__": import sys as _sys if _sys.version_info < (2, 5): __main__(_sys.argv) ========================== Or, instead (using only the current idiom): ========================== def _main(*args): ... if __name__ == "__main__": import sys as _sys _main(_sys.argv) ========================== So, to my mind, the backwards compatibility issue completely defeats the PEP's goal of finding a cleaner idiom than the current one. Cheers, Nick. -- Nick Coghlan | ncoghlan@email.com | Brisbane, Australia --------------------------------------------------------------- http://boredomandlaziness.skystorm.net
participants (2)
-
Brett C.
-
Nick Coghlan