Python-Dev December 2006

python-dev@python.org

79 participants
70 discussions

Re: [Python-Dev] Python and the Linux Standard Base (LSB)

by Phillip J. Eby

At 11:09 AM 11/22/2006 -0500, Ian Murdock wrote: >The first question we have to answer is: What does it mean to "add >Python to the LSB"? Is it enough to say that Python is present >at a certain version and above, or do we need to do more than that >(e.g., many distros ship numerous Python add-ons which apps >may or may not rely on--do we need to specific some of these too)? Just a suggestion, but one issue that I think needs addressing is the FHS language that leads some Linux distros to believe that they should change Python's normal installation layout (sometimes in bizarre ways) or that they should remove and separately package different portions of the standard library. Other vendors apparently also patch Python in various ways to support their FHS-based theories of how Python should install files. These changes are detrimental to compatibility. Another issue is specifying dependencies. The existence of the Cheeseshop as a central registry of Python project names has not been taken into account in vendor packaging practices, for example. (Python 2.5 also introduced the ability to install metadata alongside installed Python packages, supporting runtime checking for package presence and versions.) I don't know how closely these issues tie into what the LSB is tying to do, as I've only observed these issues in the breach, where certain distribution policies require e.g. that project names be replaced with internal package names, demand separation of package data files from their packages, or other procrustean chopping that makes mincemeat of any attempt at multi-distribution compatibility for an application or multi-dependency library. Some clarification at the LSB level of what is actually considered standard for Python might perhaps be helpful in motivating updates to some of these policies.

13 years, 6 months

Re: [Python-Dev] Non-blocking (asynchronous) timer without thread?

by tomer filiba

> The main goal is to prevent threads overhead and problems with race > conditions and deadlocks. check out stackless python -- http://www.stackless.com/ -tomer

13 years, 6 months

PEP 8: mention bare 'except:'

by A.M. Kuchling

http://www.python.org/sf/411881 is a bug about removing use of 'except:' in stdlib code. In many cases the intent is to catch one particular exception such as ImportError or AttributeError, but catching all exceptions can disguise other problems. Should PEP 8 mention this issue? Here's some proposed text for discussion: - When catching exceptions, mention specific exceptions whenever possible instead of using a bare 'except:' clause. For example, use:: try: import platform_specific_module except ImportError: platform_specific_module = None A bare 'except:' clause will catch SystemExit and KeyboardInterrupt exceptions, making it harder to interrupt a program with Control-C, and can disguise other problems. If you want to catch all exceptions that signal program errors, use 'except StandardError:'. A good rule of thumb is that you should only use 'except:' if the exception handler will be printing out or logging the traceback; at least the user will be aware that an error has occurred. --amk

13 years, 6 months

Weekly Python Patch/Bug Summary

by Kurt B. Kaiser

Patch / Bug Summary ___________________ Patches : 420 open ( +6) / 3510 closed (+12) / 3930 total (+18) Bugs : 944 open ( -5) / 6391 closed (+15) / 7335 total (+10) RFE : 249 open ( +2) / 245 closed ( +0) / 494 total ( +2) New / Reopened Patches ______________________ cp720 encoding map (2006-12-16) http://python.org/sf/1616979 opened by Alexander Belchenko urllib HTTPS Basic authentication fix (2006-12-17) CLOSED http://python.org/sf/1617413 opened by Dug Song The ability to keep configuration files intact (2006-12-17) CLOSED http://python.org/sf/1617496 opened by Roman Kurakin extended slicing for bytes objects (2006-12-18) CLOSED http://python.org/sf/1617678 opened by Thomas Wouters slice-object support for sre_parse.SubPattern (2006-12-18) CLOSED http://python.org/sf/1617680 opened by Thomas Wouters specialcase simple sliceobj in tuple/str/unicode (2006-12-18) http://python.org/sf/1617682 opened by Thomas Wouters specialcase simple sliceobj in list (and bugfixes) (2006-12-18) http://python.org/sf/1617687 opened by Thomas Wouters Extended slicing for UserString (2006-12-18) http://python.org/sf/1617691 opened by Thomas Wouters Extended slicing for array objects (2006-12-18) http://python.org/sf/1617698 opened by Thomas Wouters slice-object support for ctypes Pointer/Array (2006-12-18) http://python.org/sf/1617699 opened by Thomas Wouters slice-object support for mmap (2006-12-18) http://python.org/sf/1617700 opened by Thomas Wouters extended slicing for structseq (2006-12-18) http://python.org/sf/1617701 opened by Thomas Wouters extended slicing for buffer objects (2006-12-18) http://python.org/sf/1617702 opened by Thomas Wouters add None values in SimpleXMLRPCServer (2006-12-19) http://python.org/sf/1618485 opened by Maximiliano Curia sys.intern() 2to3 fixer (2006-12-19) CLOSED http://python.org/sf/1619049 opened by Georg Brandl fix urllib to raise IOError correctly (2006-12-20) CLOSED http://python.org/sf/1619247 opened by Dug Song Bug fixes for int unification branch (2006-12-20) http://python.org/sf/1619846 opened by Adam Olsen Improve platform.py usability on Windows (2006-12-21) http://python.org/sf/1620174 opened by Luke Dunstan Patches Closed ______________ urllib HTTPS Basic authentication fix (2006-12-17) http://python.org/sf/1617413 closed by akuchling The ability to keep configuration files intact (2006-12-17) http://python.org/sf/1617496 closed by loewis extended slicing for bytes objects (2006-12-18) http://python.org/sf/1617678 closed by twouters slice-object support for sre_parse.SubPattern (2006-12-18) http://python.org/sf/1617680 closed by twouters BZ2File.seek() fails for large files (2006-12-14) http://python.org/sf/1615868 closed by akuchling 1572210 doc patch (2006-11-21) http://python.org/sf/1600491 closed by akuchling cookielib: lock acquire/release try..finally protected (2006-10-30) http://python.org/sf/1587139 closed by akuchling sys.intern() (2006-11-23) http://python.org/sf/1601678 closed by gbrandl sys.intern() 2to3 fixer (2006-12-19) http://python.org/sf/1619049 closed by gbrandl tarfile.py fix for #1471427 and updates (2006-05-09) http://python.org/sf/1484695 closed by gbrandl encoding directive -- more examples (2006-12-11) http://python.org/sf/1613352 closed by gbrandl fix urllib to raise IOError correctly (2006-12-20) http://python.org/sf/1619247 closed by gbrandl New / Reopened Bugs ___________________ Wrong pathname value in logging output (2006-12-15) http://python.org/sf/1616422 reopened by simleo Wrong pathname value in logging output (2006-12-15) http://python.org/sf/1616422 reopened by simleo Wrong pathname value in logging output (2006-12-15) http://python.org/sf/1616422 opened by Tekkaman Vague description of generator close() method (2006-12-15) CLOSED http://python.org/sf/1616726 opened by Lenard Lindstrom Instance methods compare equal when their self's are equal (2006-12-16) http://python.org/sf/1617161 opened by Frank Niessink test_logging hangs on cygwin (2006-04-06) http://python.org/sf/1465643 reopened by tebeka missing word in "sqlite3-Module-Contents"-documentation? (2006-12-18) CLOSED http://python.org/sf/1618083 opened by lgvienna HMAC can get a 6x performance increase easily (2006-12-18) CLOSED http://python.org/sf/1618455 opened by Ben Maurer bisect on presorted list (2006-12-19) http://python.org/sf/1619060 opened by Jeffrey C. Jacobs 64-bit Universal Binary build broken (2006-12-19) http://python.org/sf/1619130 opened by Thomas Treadway format error in 2.5 ref.pdf in section 5.3.4 Calls (2006-12-20) http://python.org/sf/1619641 opened by cwm42 htonl, ntohl don't handle negative longs (2006-12-20) http://python.org/sf/1619659 opened by Adam Olsen Minor error in sum() docs (2006-12-20) CLOSED http://python.org/sf/1619674 opened by Kent Johnson ctypes in_dll documented with wrong argument order (2006-12-20) CLOSED http://python.org/sf/1619680 opened by Lenard Lindstrom Bugs Closed ___________ Wrong pathname value in logging output (2006-12-15) http://python.org/sf/1616422 closed by vsajip Vague description of generator close() method (2006-12-15) http://python.org/sf/1616726 closed by akuchling AttributesImpl does not implement __contains__ on Linux (2006-12-13) http://python.org/sf/1614387 closed by gbrandl IA64/AMD64/x64 confusion (2006-12-15) http://python.org/sf/1616109 closed by loewis Python socket library confused by IPV6 notation in /etc/host (2006-11-27) http://python.org/sf/1603527 closed by loewis missing word in "sqlite3-Module-Contents"-documentation? (2006-12-18) http://python.org/sf/1618083 closed by akuchling HMAC can get a 6x performance increase easily (2006-12-18) http://python.org/sf/1618455 closed by akuchling recv_into not documented (2006-12-11) http://python.org/sf/1613651 closed by akuchling random.randrange don't return correct value for big number (2006-11-05) http://python.org/sf/1590891 closed by rhettinger Minor error in sum() docs (2006-12-20) http://python.org/sf/1619674 closed by akuchling ctypes in_dll documented with wrong argument order (2006-12-20) http://python.org/sf/1619680 closed by akuchling Problem with tapedevices and the tarfile module (2005-11-21) http://python.org/sf/1362587 closed by esshenrik resolver not thread safe (2002-04-04) http://python.org/sf/539175 closed by dustin New / Reopened RFE __________________ Improve list comprehensions to Language Integrated Query? (2006-12-19) http://python.org/sf/1618676 opened by JettLogic

13 years, 6 months

Request for developer privileges.

by Lars Gustäbel

Hello, my name is Lars Gustäbel (SF gustaebel). I contributed tarfile.py to the Python standard library in January 2003 and have been the maintainer since then. I have provided about 25 patches over the years, most of them fixes, some of them new features and improvements. As a result, I am pretty familiar with the Python development process. If possible I would like to get developer privileges to be able to work more actively on tarfile.py for a certain time. I am currently implementing read-write POSIX.1-2001 pax format support. Development is still in progress, but it is already clear at this point, that it will be a complex change, which will definitely require some maintenance once it is finished and in day-to-day use. I would like to clean up the tarfile test suite during this process as well. The introduction of the pax format is important because it is the first tar specification that puts an end to those annoying limitations of the "original" tar format. It will become the default format for GNU tar some day. Thank you, Lars. -- Lars Gustäbel lars(a)gustaebel.de

13 years, 6 months

Listing of PEP 328 status and possible minor oversight

by Brett Cannon

I just noticed that PEP 328 (relative imports) is listed as an accepted PEP, but not completed. Is this because there is still things to do for 2.6 and 2.7? Or did someone just forget to move it to the completed PEPs section of the PEP index? If it is the former then PEP 362 will need to be moved. I also noticed that there is no mention of removing import redirection to a top-level module by having None in sys.modules. Was this for backwards-compatibility issues, or was it just not thought of? -Brett

13 years, 6 months

New Python-Ideas mailing list

by Brett Cannon

At Guido's suggestion, a new mailing list has been created named Python-Ideas (http://mail.python.org/mailman/listinfo/python-ideas). This list is meant as a place for speculative, pie-in-the-sky language design ideas to be discussed and honed to the point of practically being a PEP before being presented to python-dev or python-3000. This allows both python-dev and python-3000 to focus more on implementation work or final approval/denial of ideas instead of being flooded with long threads where people discuss ideas that are too nebulous to be considered for inclusion into Python. Like python-dev and python-3000, Python-Ideas requires you subscribe before you can post, but there is no moderator approval required. If you are interested in helping me out by being an administrator or moderator for the list, please let me know. -Brett

13 years, 6 months

Re: [Python-Dev] About dictionary lookup caching

by "Martin v. Löwis"

Raymond Hettinger schrieb: > If you can find some other design that doesn't depend on the ordering of > co_names, that would be nice; otherwise, we're adding a permanent > complication to the compiler and establishing a new invariant that would > have to be maintained by everyone hoping to generate or hack bytecodes. It wouldn't be a strict invariant, but instead, breaking it would mean that the memory consumption goes up somewhat. Regards, Martin

13 years, 6 months

About dictionary lookup caching

by Andrea Griffini

I'm experimenting with a patch for dictionary lookup caching, the main idea being avoiding the lookup of a constant (co_names) in a dictionary if the dictionary didn't change since last lookup. Currently the cache is held in a structure that is parallel to co_names (the LOAD_GLOBAL opcode uses oparg to access the cache slot) and this is wasteful if there are co_names entries that are not used for global lookups. Probably I could act at the code object creation time to sort names so that ones used by LOAD_GLOBAL are at the beginning of co_names but this would require inspecting and hacking the already generated opcode. Another case that would IMO be worth optimizing is the LOAD_ATTR lookup when it's done after a LOAD_GLOBAL (I suspect that in many cases the element being searched will be a module so caching would be simple to implement; for general objects things are way more complex and I see no simple solution for caching dictionary lookups). My opinion is that it would be by far better to do this ordering of co_names at compile time but I've no idea where to look for trying to make such a change. Can someone please point me in the right direction ? Andrea

13 years, 6 months

Open CPython VM for type information

by Kay Schluehr

Dear Python developers, while the JVM is opened to support dynamically typed languages [1] I wonder if the CPyVM could not show more openness to statically typed languages? Hereby I don't think that much about arbitrary languages for the CPyVM but sublanguages like RPython which are "static enough" to be compilable into extension modules [2]. However creating C extension modules from Python code is not really the standard way I do think Python source should be handled. Instead I think about a more direct VM support like the JVM does, that provides opcodes like iload, fstore etc. Besides this I don't expect one canonical approach for these type information to be feeded into the CPyVM. There are type inferencer like rtyper for PyPy, Psycos continous bytecode monitoring and also other approaches are possible that use type feedback. Finally optional type declarations are also an issue; however I would like to see language design discussions being separated ( -> Python 3000 ) and focus on general APIs for compiler extensions / plugs that deal with type information ( the architecture ) and VM implementation issues. Thanks, Kay [1] http://jcp.org/en/jsr/detail?id=292 [2] http://codespeak.net/pypy/dist/pypy/doc/extcompiler.html

13 years, 6 months

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

Python-Dev December 2006