Mailman 3 July 2005 - Python-Dev

Re: [Python-Dev] Possible context managers in stdlib
by Michael Chermside July 11, 2005

July 11, 2005

I wrote: > I agree with Barry. Not only should they be in the stdlib, but they > should have very clear warnings in their docstrings and other documentation > that state that they are ONLY safe to use in single-threaded programs. > > This achieves two things: it makes them available to those who need > them (not everyone uses threads!), and it rather forcefully makes the > point that it's NOT usually a good idea to modify global state info in > a context manager because doing so is not generally threadsafe. Nick Coghlan replies: > Wouldn't they be able to actually emit a warning at run-time if they're used > in a multi-threaded program? That would be even better motivation for > including them, IMO. I don't think that would be desirable. These things CAN be useful in a multi-threaded program if you know what you're doing. One common example would be to use them only from the main thread. -- Michael Chermside

1 0

Possible context managers in stdlib
by Reinhold Birkenfeld July 11, 2005

July 11, 2005

Hi, I compiled a list of some possible new context managers that could be added to the stdlib. Introducing a new feature should IMO also show usage of it in the distribution itself. That wasn't done with decorators (a decorators module is compiled at the moment, if I'm right), but with context managers, there's certainly room to add some. Of course, my list is excessive, it's only some ideas I got by flying over the stdlib docs. * builtins: with open/file * sys: with sys.redirected_std[in|out|err] with sys.trace with sys.excepthook * warnings: with warnings.filter * pprint: with pprint.printer (used for print) * codecs: with codecs.open with codecs.EncodedFile * decimal: with decimal.Context * os: with os.current_directory with os.modified_env with os.umask/uid/gid etc. with os.popen with os.tmpfile * subprocess: with subprocess.Popen * mutex: with mutexobj * curses: with curses.wrapper * tempfile: with tempfile.[Named]TemporaryFile etc. * locale: with locale.differentlocale * logging: with logging.ignored with logging.Logger * signal: with signal.handler * socket: with socket.socket * threading: with threading.Lock with threading.Condition with threading.Event * mmap: with mmap.mmap * bz2/zipfile/tarfile: with ...open * dl: with dl.open * tty: with tty.raw with tty.cbreak * cgitb: with cgitb.enabled * urllib/urllib2: with urllib.urlopen etc. * httplib: with httplib.HTTPConnection * ftplib: with ftplib.FTP * poplib: with poplib.POP3 * imaplib: with imaplib.IMAP4 * nttplib: with nntplib.NNTP * smtplib: with smtplib.SMTP * telnetlib: with telnetlib.Telnet * xmlrpclib: with xmlrpclib.ServerProxy Reinhold -- Mail address is perfectly valid!

7 8

Triple-quoted strings and indentation
by Andrew Durdin July 11, 2005

July 11, 2005

In general, I find triple-quoted strings to be very handy, particularly for standalone scripts. However, the fact that they have to be written in the left-hand column to avoid leading whitespace really grates, particularly when they're nested within a block or two -- it's a wart: try: options, args = getopt.getopt(sys.argv[1:], "cf:s") except getopt.GetoptError: print """Usage: dostuff <options> Options: -c - blah blah -f <filename> - do stuff with file "filename" -s - more blah""" sys.exit(1) This really makes the code hard to read, as the indentation is all mixed up (visually). I have written a patch that changes the way triple-quoted strings are scanned so that leading whitespace is ignored in much the same way that pep 257 handles it for docstrings. Largely this was for a learning experience in hacking the parser, but it would be very nice IMO if something of this sort could be implemented in a future version of Python. To this end, I have sketched out a draft PEP (which was itself a good learning exercise in thinking out the issues of such a change). Should I post it here for discussion? Andrew

10 22

C bindings calling tmpfile() blocks interrupt signal
by Florent Pillet July 11, 2005

July 11, 2005

I discovered an issue on Mac OS X that seems to relate to signal handling. I have a C binding in which I call the standard tmpfile() function. After calling it, I can't break Python anymore with CTRL-C. Investigating the Darwin source code for tmpfile() (and FreeBSD, they are the same) , I found that the function is mucking with the signals: http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/stdio/tmpfile.c?rev=1.9&… Is this considered a Python issue, or an OS issue? I ran a simple test against the interrupt signal, which didn't show any wrong behavior: static void intcatcher(int sig) { printf("Interrupt catched\n"); exit(1); } int main(int argc, char **argv) { signal(SIGINT, intcatcher); printf("Press CTRL-C to interrupt...\n"); tmpfile(); while (1) ; return 0; } But with my threaded Python code, SIGINT doesn't work anymore after my binding has called tmpfile(). Florent -- Florent Pillet http://www.florentpillet.com Freelance software developer/consultant - Palm OS & Mac OS X ICQ: 117292463 Skype: callto://florent.pillet

3 4

Chaining try statements: eltry?
by Thomas Lotze July 11, 2005

July 11, 2005

Hi, this is my first message to this list, so let me say hello first. I want to ask what you think about introducing a keyword 'eltry' which would be the counterpart of 'elif' for try statements. This had been suggested before on python-list a couple of years ago by Jonathan Gardner, but nothing (that I could find) seems to have come of it. Starting from PEP 341, the try statement might be extended to try_stmt: 'try' ':' suite ( (except_clause ':' suite)+ ( 'eltry' ':' suite (except_clause ':' suite)+ )* ['else' ':' suite] ['finally' ':' suite] | 'finally' ':' suite ) where lines 4 through 7 would be an addition to the definition given in the PEP. Admittedly, this looks somewhat complex, but I don't think it actually is. (And while an new keyword always means potentially breaking code, 'eltry' doesn't seem to me a likely identifier chosen by programmers - YMMV.) This extension would be useful whenever a suite of statements is to be terminated as soon as one of them raises an exception, and the programmer is interested in handling those individually. Without 'eltry' the choices are: - Stack conventional try statements, each inside the else clause of the one before. This causes deep nesting, and while typical nesting depths won't be as great as they might become with stacked if statements, it is annoying and ugly IMO. - Run all statements at once and put all exception handlers outside the suite. This yields code that is harder to read than necessary as some handlers will be written far from the statement where the exception they handle is raised. Moreover, if more than one statement may raise a particular exception, some effort is required to find out which one did it if there is only one handler for that exception. - Break up the suite into separate try statements. While this may result in well readable code if each handler breaks out of the block containing the whole run of try statements, it requires some mechanism (such as a wrapper try statement or a separate function that may quit anytime) if exiting the current block is not desired. - Something else, in which case I'm looking forward to learning something new about Python ;o) An example would be a filter chain: def use_eltry(data): # decode as far as possible try: data = foo_decode(data) except ValueError: print "Data seems not to be foo encoded." eltry: data = bar_decode(data) except ValueError: print "Foo decoded data seems not to be bar encoded." eltry: data = baz_decode(data) except ValueError: print "FooBar decoded data seems not to be baz encoded." # whatever data is by now, do something with it do_something(data) def use_stacking(data): # decode as far as possible try: data = foo_decode(data) except ValueError: print "Data seems not to be foo encoded." else: try: data = bar_decode(data) except ValueError: print "Foo decoded data seems not to be bar encoded." else: try: data = baz_decode(data) except ValueError: print "FooBar decoded data seems not to be baz encoded." # whatever data is by now, do something with it do_something(data) def use_single_handler(data): # decode as far as possible try: data = foo_decode(data) data = bar_decode(data) data = baz_decode(data) except ValueError: print "Data could not be decoded, can't tell you why easily." # whatever data is by now, do something with it do_something(data) def use_custom_exception(data): # decode as far as possible try: try: data = foo_decode(data) except ValueError: print "Data seems not to be foo encoded." raise try: data = bar_decode(data) except ValueError: print "Foo decoded data seems not to be bar encoded." raise try: data = baz_decode(data) except ValueError: print "FooBar decoded data seems not to be baz encoded." raise except ValueError: pass # whatever data is by now, do something with it do_something(data) def use_function(data): # decode as far as possible def helper(): try: data = foo_decode(data) except ValueError: print "Data seems not to be foo encoded." return try: data = bar_decode(data) except ValueError: print "Foo decoded data seems not to be bar encoded." return try: data = baz_decode(data) except ValueError: print "FooBar decoded data seems not to be baz encoded." return helper() # whatever data is by now, do something with it do_something(data) Does this seem contrived? (Obviously, I don't think so.) It would be nice to hear your opinions and, if you don't agree with the proposal, learn what is bad about it. -- Viele Grüße, Thomas

23 36

__autoinit__
by Ralf W. Grosse-Kunstleve July 9, 2005

July 9, 2005

For those who didn't like my proposal a week ago, please have another look: http://mail.python.org/pipermail/python-list/2005-July/289446.html Please reply only to python-list. Cheers, Ralf

2 1

Re: [Python-Dev] Adding the 'path' module (was Re: Some RFEfor review)
by Meyer, Tony July 9, 2005

July 9, 2005

>> Well, most people when confronted with this will rename the >> directory to something simple like "ulib" and continue. > > I don't really buy this "trick": what if you happen to have > a home directory with Unicode characters in it ? I think this is one of the most common places, too. Whenever I've come across unicode filenames it has been because the user has a unicode Windows username, so their 'home directory' (and temp directory, desktop folder, etc) does too. Convincing people to either change their username or to go through the fairly complicated process of moving these directories elsewhere generally isn't feasible. =Tony.Meyer

1 0

checklist for filing a bug
by Brett Cannon July 9, 2005

July 9, 2005

In order to lower the barrier for reporting bugs, writing patches, and handling CVS commits, I am writing up checklists for each and I will put them up on python.org. The first checklist is for bug reports. All comments welcome. Keep in mind the list is supposed to be short and straight-forward; too wordy and people won't read it. Reporting a Bug +++++++++++++++ For technical question for any step listed, refer to the `dev FAQ`_. #. Make sure the bug is reproducible The bug cannot be a freak occurence and must be reproducible so developers can test against it. #. Isolate bug Come up with a code snippet that is as succinct as possible that triggers the bug consistently. Coding it as a unit test is the best. #. Gather important information Info such as Python version, operating system version, etc.; anything that might have influenced the code that lead to the bug. #. Report the bug on SourceForge_ Create a new tracker item, filling out the ``Category`` and ``Group`` fields. Do not set the ``Assigned To`` or ``Priority`` fields. Upload your code snippet as a file and make sure to click the ``Upload`` button! .. _dev FAQ: http://www.python.org/dev/devfaq.html .. _SourceForge: http://sourceforge.net/tracker/?group_id=5470&atid=105470

5 4

GCC version compatibility
by David Abrahams July 7, 2005

July 7, 2005

Recently people testing Boost.Python with GCC on Linux have reported that the extensions being tested have to be compiled with exactly the same version of GCC as the Python they're being loaded into, or they get mysterious crashes. That doesn't correspond to my past experience; it has always been true that, as long as the compiler used to build Python and the one used to build the extension have compatible 'C' ABIs, we've been okay. Yes, if you were going to pass types like FILE* across the Python/C API, then you additionally need to be sure that the two compilers are using the same 'C' library. That said, none of the Boost.Python tests do that. I'm wondering if there has been a well-known recent change either in Python or GCC that would account for these new reports. Any relevant information would be appreciated. -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 2

Inconsistent API for sets.Set and build-in set
by Barry Warsaw July 7, 2005

July 7, 2005

I've been looking at the API for sets.Set and built-in set objects in Python 2.4.1 and I think I have found some minor inconsistencies. Background: we have an object that is very similar to "sets" and we originally modeled the API after sets.Set since we started with Python 2.3. Now I'm trying to update the API so that it's consistent with Python 2.4's built-in set object and I've noticed the following discrepancies. set.Set has both an .update() method and a .union_update() method. They appear to be completely identical, accepting either a Set object or an arbitrary sequence. This is the case despite the docstring difference for these two methods and the fact that Set.update() isn't documented on the texinfo page. Built-in set has only .update() though but it acts just like the set.Set methods above. Note that of all these methods, only Set.update() is documented to take an iterable argument. These inconsistencies could prove a bit problematic when porting Py2.3 applications using sets.Set to Py2.4 using built-in set. I'd like to fix this for Python 2.4.2, and I think the changes are pretty minimal. If there are no objections, I propose to do the following (only in Python 2.4 and 2.5): * Add set.union_update() as an alias for set.update(). * Add to docstrings for all methods that 't' can be any iterable. * Update texinfo documentation to add Set.update() and set.union_update() and explain that all can take iterables I consider this a bug in 2.4, not a new feature, because without it, it makes more work in porting applications. Thoughts? I'm willing to Just Fix It, but if someone wants to see a patch first, I'll be happy to generate it and post it to SF. -Barry

9 15