Mailman 3 October 2010 - Python-Dev

question/comment about documentation of relative imports
by Darren Dale 09 Oct '10

09 Oct '10

I have a couple questions/comments about the use of PEP 328-style relative imports. For example, the faq at http://docs.python.org/py3k/faq/programming.html#what-are-the-best-practice… reads: "Never use relative package imports. If you’re writing code that’s in the package.sub.m1 module and want to import package.sub.m2, do not just write from . import m2, even though it’s legal. Write from package.sub import m2 instead. See PEP 328 for details." There is no explanation to support the claim that relative imports should "never" be used. It seems to me that someone read the following in PEP 328:: from .moduleY import spam from .moduleY import spam as ham from . import moduleY from ..subpackage1 import moduleY from ..subpackage2.moduleZ import eggs from ..moduleA import foo from ...package import bar from ...sys import path Note that while that last case is legal, it is certainly discouraged ("insane" was the word Guido used). ... and interpreted it to mean that relative imports are in general discouraged. I interpreted it to mean that relative imports should not be used to import from python's standard library. There are cases where it is necessary to use relative imports, like a package that is included as a subpackage of more than one other project (when it is not acceptable to add an external dependency, for example due to version/compatibility issues). There is some additional context on relative imports in the programming faq for python-2.7 at http://docs.python.org/faq/programming.html#what-are-the-best-practices-for… : "Never use relative package imports. If you’re writing code that’s in the package.sub.m1 module and want to import package.sub.m2, do not just write import m2, even though it’s legal. Write from package.sub import m2 instead. Relative imports can lead to a module being initialized twice, leading to confusing bugs. See PEP 328 for details." Is there some documentation explaining why the module may be initialized twice? I don't see it in PEP 328. Is this also the case for python-3, or does it only apply to the old-style (pre-PEP 328) relative imports in python-2? If relative imports are truly so strongly discouraged, then perhaps warnings should also be included in places like http://docs.python.org/library/functions.html#__import__ , and especially http://docs.python.org/tutorial/modules.html#intra-package-references and http://www.python.org/dev/peps/pep-0328/ (which, if I have misinterpreted, is ambiguously written. Though I doubt this is the case). There is also this warning against relative imports in PEP 8: - Relative imports for intra-package imports are highly discouraged. Always use the absolute package path for all imports. Even now that PEP 328 [7] is fully implemented in Python 2.5, its style of explicit relative imports is actively discouraged; absolute imports are more portable and usually more readable. ... but one could argue, as I just have, that relative imports are more portable, not less. In a sense, the statement "explicit relative imports is actively discouraged" is objectively false. They are passively discouraged. If they were actively discouraged, perhaps performing a relative import would raise a warning, or maybe distutils would raise a warning at install time, or maybe an additional import would be required to enable them. Up until now, I was not aware that use of PEP 328 relative imports might be discouraged. I'm still unclear as to why they might be discouraged. I recently helped convert a popular package to use PEP 328 relative imports. Would the python devs consider this a mistake? Thanks, Darren

14 19

python.org going down?
by geremy condra 08 Oct '10

08 Oct '10

Seems like python.org has gone down and come back up a couple of times in the last few minutes, is this intentional? Geremy Condra

4 9

Patch making the current email package (mostly) support bytes
by R. David Murray 08 Oct '10

08 Oct '10

A while back on some issue or another I remember telling someone that if there was any sort of clever hack that would allow the current email package (email5) to work with bytes we would have implemented it. Well, I've come up with a clever hack. The idea came out of a conversation with Antoine. I was saying that it was ironic that Unicode could only be used as a 7bit-clean data transmission channel for email, and he remarked that by using surrogate escape you *could* use unicode as a transmission channel for 8bit data. At first I dismissed this observation as irrelevant to email, since email has to transform the 8bit data at some point. But I started thinking. And then I started experimenting. And it turns out that it works. The clever hack (thanks ultimately to Martin) is to accept 8bit data by encoding it using the ASCII codec and the surrogateescape error handler. Then, inside the email module at any point where bytes might be meaningful or might be about to escape, it can check to see if there are any surrogates and act accordingly. The API additions are few, and in fact for most programs (he says bravely, not really knowing) there are really only two changes you need to make when converting a program that handles bytes data to py3k. The first is the encoding of binary input data as mentioned. The second is that when you want to get the bytes back out, you use the new BytesGenerator instead of Generator. BytesGenerator is just like Generator except that it writes bytes to its file argument instead of strings, and it recovers any bytes that were in the original input. So given this sequence: msg = email.msg_from_file(open('myfile', encoding='ascii', errors='surrogateescape')) email.generator.BytesGenerator(open('myfile2', 'wb')).flatten(msg) myfile and myflie2 will theoretically be identical (modulo universal newline and _mangle_from issues). I've additionally added a 'message_from_bytes' convenience function. One nice feature of this patch is that once you've got the model built from surrogateescaped input, if you do a get_payload() on a message body whose ContentTransferEncoding is '8bit' you will get the body decoded to unicode using the charset declared in the Content-Type header (assuming Python supports that charset). You can always get at the bytes version of the body of a message part by using get_payload(decode=True) [*]. You can't really get at the bytes version of message headers, though...for safety if you access a header whose value contains non-ASCII chars (that aren't RFC2047 encoded to be ASCII) the 8bit characters get replaced with '?'s. (But BytesGenerator will emit the original 8bit characters if the headers haven't been modified.) I do not propose that this is a *good* API, since it has the classic problem that if there are coding bugs in the email module strings may "escape" that have surrogates in them and we end up with programs that work most of the time....except when they fail with mysterious errors because of unusual bytes input data. On the other hand you always *know* when you have bytes data in an unknown encoding (because they are surrogate escaped), so it is ever so much better than the Python2 situation. The advantage of this patch is that it means Python3.2 can have an email module that is capable of handling a significant proportion of the applications where the ability to process binary email data is required. I've uploaded the patch to issue 4661 (http://bugs.python.org/issue4661). I uploaded it to rietveld as well just before Martin's announcement. After the announcement I uploaded the svn patch to the tracker, so hopefully there will be an automated review button as well. Here is your chance to exercise the new review tools :) This patch does break two of Barry's patch-for-review rules: it is more than 800 lines of diff (but not a lot more, and less than 800 if you count only code diff and not docs), and it did not have a very extensive design discussion beforehand. I did talk with people on IRC, particularly Barry, before finishing the patch, and I did post a summary to the email-sig mailing list (but got no response). Now it is time to see what the wider community thinks. There is some question of whether this is a bending of the string/bytes separation that doesn't belong as part of the standard library, but after working my way through it I think it is a fairly clean hack[**], and most likely a case where practicality beats purity. Regardless of whether or not this patch or a descendant thereof is accepted I still intend to continue working on email6. There are many other bugs in the current email package that require a rewrite of parts of its infrastructure, and the email-sig is agreed that the email API needs revision quite apart from the bytes/string issues. However, there is something pleasing about the simplicity of this way of handling bytes that I intend to consider carefully while we work further on email6. --David [*] It is counterintuitive that 'decode=True' gives you bytes and 'decode=False' gives you strings, but in this case 'decode' refers to the ContentTransferEncoding...and this confusion is one of the reasons I think the email API needs a big overhaul. [**] There are a couple places where generator pokes into the internals of Message in a way it hasn't before, but this could be fixed by defining a 'bytes access' API on Message, which would probably be a good idea anyway. There is also the possibility of wrapping up the 'ascii+surrogateesape' stuff inside APIs that accept input data, to hide that 'implementation detail' from the email package user.

6 24

Re: [Python-Dev] Patch making the current email package (mostly) support bytes
by lutz＠rmi.net 08 Oct '10

08 Oct '10

Thanks for both your reply and work, David. I'm going to have to test my email clients under the 3.2 patch when it gels. It's good to hear that email5 API support remains a goal. I don't mean to single out this change unfairly, of course. My real concern is not as much with the specific technical aspects of this proposal, as with the generally low priority that backward compatibility sometimes receives on this list. The bytecode file model change in 3.2 comes to mind as another example; sound as it may be, I'm not sure this list has any idea how many users, systems, or docs may be impacted by this. Though not always true, the work here does sometimes appear to be conducted in a vacuum. Ultimately, development in the open source world is driven by the very few with time to show up, rather than by the very many who depend on it. This can unfortunately lead to the perception of thrashing by end users. Some even come to see the net effect as not that much different from closed models. I have no solution to offer, except to underscore again that changes made here affect very many people who are too busy using Python to participate here. Especially given the still tentative state of 3.X, stability matters. --Mark Lutz (http://learning-python.com, http://rmi.net/~lutz) > -----Original Message----- > From: "R. David Murray" <rdmurray(a)bitdance.com> > To: lutz(a)rmi.net > Subject: Re: [Python-Dev] Patch making the current email package (mostly) support bytes > Date: Thu, 07 Oct 2010 13:46:02 -0400 > > On Thu, 07 Oct 2010 16:03:18 -0000, lutz(a)rmi.net wrote: > > I'm forwarding a link to the code of these clients to David by > > private email in case they might be useful as a test case (O'Reilly > > has already posted them ahead of the book, but they may be a bit too > > heavy for use in formal testing). > > Thanks very much. I will take a look, and expect they will > be helpful. > > > The email package is obviously less than ideal today, and there are > > many other clients for it besides my own, of course. But making it > > backward incompatible at this point is likely to be seen as a big > > negative to newcomers evaluating 3.X viability. And as I tried to > > make clear in June, this list should carefully weigh the PR cost of > > pulling the rug out from under those brave souls who have already > > taken the time to accommodate the 3.X world you've mandated. > > Well, as I have said before the plan is to provide backward compatibility > in email6, so that you only need to change your code if you want to > take advantage of improved or new functionality. If this turns out not > to be possible for some reason, then we aren't going to suddenly stop > supporting email5. That's not the Python Way :) (Example: we added > ArgParse post-3.0, and lots of people wanted to deprecate OptParse, > but we aren't planning on removing OptParse.) > > Do you see any issues with the patch I'm proposing? My goal is to make > things work that didn't work before, but nothing that worked before > should stop working, if I do my job right. > > The one *potentially* backward-incompatible change that I'm consciously > considering (that is, any other backward incompatibilities will be bugs) > is having DecodedGenerator fully decode headers and emit full unicode, > rather than the ASCII-only unicode that Generator emits. Can you think > of any problem that that would cause? A quick grep indicates your own > code does not use that generator (possibly because currently it does not > do that decoding). I could, of course, only enable header decoding if > a flag is passed requesting it, and as I write this I realize that that > is indeed what I should do. Even though I haven't been able to think of a > case where DecodedGenerator producing non-ASCII unicode would be an issue, > that doesn't mean there isn't one :) > > > To put that more strongly, the Python user base is much larger than > > this list's readership. If I'm using 3.1 email, so are many others. > > People will accept the 3.X world you make up to a point, but it's > > impossible to code to a moving target, much less base a product on > > it. At some point, they'll simply stop trying to keep up; in fact, > > some already have. > > > > Fixes are a Good Thing, of course, and this particular change's scope > > remains to be seen; but to channel most of the users I meet out there > > in the real world today: Enough with the 3.X changes already, eh? > > Now that Python3 is out, the backward compatibility policy for it is > the same as it always was for Python2. Only the transition from 2 > to 3 broke backward compatibility in a significant way. From here > on, we are as conservative as we always have been at making backward > incompatible changes (that is, we don't do it intentionally without > a good reason and a deprecation cycle, and if we do it unintentionally > it is a regression and treated as such). > > -- > R. David Murray www.bitdance.com >

3 2

Re: [Python-Dev] Patch making the current email package (mostly) support bytes
by R. David Murray 08 Oct '10

08 Oct '10

On Thu, 07 Oct 2010 15:00:04 +0900, "Stephen J. Turnbull" <stephen(a)xemacs.org> wrote: > R. David Murray writes: > > > > But that's not interesting; you did that with Python 3. We want to > > Of course I did it with Python3. It's the Python3 email codebase > > I'm working with (and have to work *around*). > > Sure. My point is that it has nothing to do with the expections of > people trying to upgrade their apps to Python 3, and meeting those > expectations is an important requirement of the specification of > email5, right? Well, not necessarily, no. Python3 broke backward compatibility. *Some* changes are going to have to be made in user code to make it work with email5. Where we can minimize those changes we should, but it isn't a requirement, no. With my patch, the minimization will be message_from_string --> message_from_bytes, message_from_file --> message_from_binary_file, and in some cases Generator --> BytesGenerator, for those programs that need to deal with wire format data that is not 7bit clean. Programs that only *generate* emails should need few if any changes, but that is already true (that's the half of email that is working :). > Actually, in context we were not talking about a random character that > came in from outside, we were talking about U+FFFD that *we* > generated, and *know* that it's the only non-ASCII character in the > string because we replaced all the others with it. Ah, so that *was* what you were suggesting. > Of course the best we can do with 'From: =?UNKNOWN?Q?p=C3=B6stal' or > 'From: p\xc3\xb6stal' on input is to save the encoded or raw bytes > representation and spit it back out on output. Yes. And I haven't actually dealt with what to do with non-ascii characters or RFC2047 unknown-8bit characters when decoding headers in email6. In issue 6302 we are talking about adding a decode_header_to_string method for email5 where the same issue arises, and so we'll need to make a decision soon. Presumably we'll use U+FFFD to replace them (along with registering defects in email6). > The MIME-charset = UNKNOWN dodge might be a better way of handling > this. The str is all ASCII, so won't raise exceptions unless the app > itself objects to MIME encoded-words for some reason. OTOH, the > presence of encoded words will be a red flag to any human viewer, and > after processing with .flatten(), the receiver is likely to DTRT (from > the receiving human's point of view, per that human's configuration). That is a very interesting idea. It is the *right* thing to do, since it would mean that a message parsed as bytes could be generated via Generator and passed to, say, smtplib without losing any information. However, It's not exactly trivial to implement, since issues of runs of characters and line re-wrapping need need to be dealt with. Perhaps Header can be made to handle bytes in order to do this; I'll have to look in to it. > > So you are suggesting that I should use U+FFFD encoded as UTF-8 > > rather than '?' as the substitution character? But earlier you said > > that people would probably rather not be forced to deal with Unicode > > just because there are invalid bytes in the message. So that's > > probably not what you meant. > > "Suggest" !=3D "recommend". Talking to a wider base of users and > developers, you might or might not find that to be a good idea. I > don't think the 800 million or so Chinese coming online in the next > decade will much care whether you use U+FFFD or '?'. The Japanese > would prefer U+2639 WHITE FROWNING FACE or U+270C VICTORY HAND, no > doubt ("crassly cute" is much beloved here). Americans will likely > prefer '?', as they probably have correspondents with legacy systems > that won't like UTF-8 or perhaps don't have a font to display U+FFFD. For the moment I think I'll stick with '?', with the idea of "fixing that bug" by using the unknown charset trick at a later stage. > > Presumably you are suggesting that email5 be smart enough to turn my > > example into properly UTF-8/CTE encoded text. > > No, in general that's undecidable without asking the originator, > although humans can often make a good guess. But not always: Japanese > are fond of "four-character compound words", and I once found an > 8-byte sequence (four 2-byte characters) that is idiomatic in both > Shift JIS and EUC-JP. Even a dictionary lookup can't determine the > intended encoding for that sequence. I was talking about unicode input, though, where you do know (modulo the language differences that unicode hasn't yet sorted out). > I'm only saying that any Unicode email-N generates itself can be > properly encoded. Agreed. > > But *that* problem is what email6 is trying to address. It just > > doesn't look practical to address it directly in the email5 code > > base, because the email4 codebase that email5 inherits does not > > provide the correct distinction between bytes and text. email5 is > > parsing the input stream *as if* it were ASCII-only CTE text. > > I don't see how this is different from email6. Just because email6 is > trying to DTRT doesn't mean the spammers will, and even Emacs MUA > developers occasionally screw this up in new products. So email-N has > to handle input streams that are *supposed* to be entirely ASCII except > for message bodies that are properly marked as 8bit or binary CTE, but > occasionally will not conform. Right, but I was talking about my python3 example, where I was using the email5 parser to (unsuccessfully) parse unicode. *That's* the thing email5 can't really handle, but email6 will be able to. > > Extending it to actually handle unicode input is a whole different > > kettle of sushi[*]. > > But this is not your problem in email5 AFAICS. Right, but I thought you were suggesting it was. My mistake. > > [*] And I've had an argument with someone who thinks email should > > *not* be extended to handle unicode messages with non-ASCII > > content, on the grounds that they aren't really email. > > That's total nonsense. Don't argue with people like that, educate > them, and if that fails, ignore them. There's good reason for not > extending email5, ie, email4 didn't do it. But that has nothing to do > with what email "really is". [ snip good supporting text ] > In practice, email undoubtably has clients that want to manipulate > bytes directly. I can't blame them, but the RFCs have nothing to say > about that, really. RFC 822 and its family (including MIME) are about > representing human media as octet streams compatible with protocols > like RFC 821, and in Python the human medium for representing text is > str. The result of bytes manipulations should be "as if" the original > stream was decoded, manipulated, and reencoded. So direct bytes > manipulation is an optimization. The RFCs don't provide for it at > all, AFAICS. > > The same thing is true of URIs, except that RFC 3896 makes it fully > explicit that URIs are conceptually text, not octets. Again, there > are many important use cases for bytes manipulation of URIs, but this > is an optimization. Thank you very much for this piece of perspective. I hadn't thought about it that clearly before, but what you say makes perfect sense to me, and is in fact the implicit perspective I've been working from when working on the email6 stuff. -- R. David Murray www.bitdance.com

3 5

Re: [Python-Dev] Patch making the current email package (mostly) support bytes
by lutz＠rmi.net 08 Oct '10

08 Oct '10

stephen(a)xemacs.org wrote in the full message below: > If having 1 *and* 2 is so important to particular users, but they come > into conflict because of proposed changes in Python, then they're > going to have to give up 3, come here, and articulate their needs. But I _did_ come here and articulate my needs, and received this antagonistic response for my efforts. If you really value user input, you may want to explore the nature of your reaction to it. Trust me: criticism goes with the territory any time your actions impact a large group of people. This seems inherent here. Frankly, your view of the roles of developers and users seems so upside down to me that I doubt anything I could say here would matter. You're more than welcome to ignore an interjection of reality and adopt a closed group mindset, of course, but you do so at the peril of the system you're working on. For my part, one week from now I'll be standing up again in front of a group of 20 Python beginners, and basically apologizing for both the present and ongoing 3.X changes they must conform to in the near future. Python may not be Perl 6 yet, but its image is already tarnished in the real world where people make technology choices, due to its rapid pace of change. It's a genuine problem. In the end, I suppose I'm just one of those lazy end users you mentioned who are too busy to spend 24/7 hanging out on this list in order to head off changes that will break their code. (Yes, sarcasm intended.) --Mark Lutz (http://learning-python.com, http://rmi.net/~lutz) > -----Original Message----- > From: "Stephen J. Turnbull" <stephen(a)xemacs.org> > To: lutz(a)rmi.net > Subject: Re: [Python-Dev] Patch making the current email package > (mostly) support bytes > Date: Fri, 08 Oct 2010 14:33:22 +0900 > > lutz(a)rmi.net writes: > > > To put that more strongly, the Python user base is much larger than > > this list's readership. > > Agreed. Nevertheless, this is the channel (not "channel") that the > developers listen on, and substantial effort is made to let Python > users know that. I think they do know it, too. > > > If I'm using 3.1 email, so are many others. > > That's not obvious. 3.1 email is unusable for several applications. > In fact, for human factors reasons (humans are very likely to > communicate with other humans who use the same encodings, and to > accept occasional glitches they must deal with manually), MUAs are > likely to port relatively easily as "good enough" software. But I > doubt very much that folks writing MTAs or spam filters that must run > unattended, often in long-lived, very active processes, are producing > production versions using Python 3 email yet. > > > People will accept the 3.X world you make up to a point, but it's > > impossible to code to a moving target, much less base a product on > > it. > > "Impossible is nothing." It's a decision that each individual > developer makes for herself. I haven't heard Mailman devs complain > about the impossibility of dealing with the proposed changes, for > example. Quite the reverse, in fact. > > > At some point, they'll simply stop trying to keep up; in fact, > > some already have. > > Predictable and predicted. Where's the balance? I don't know, but > "channeling" the users is not a lot of help. There are three worthy > goals here: > > 1. Taking advantage of improvements in to-be-released Pythons. > 2. Not changing one's own working code. > 3. Not participating in python-dev/email-sig. > > Take any two; one can't have all three. > > More specifically, it's interesting that most of the users you talk to > care enough to actually say they don't want more incompatible changes. > But what are we supposed to take from that? Some fixes have to be > incompatible; do the users want the fix or the compatibility? You > waffle (as a good representative often must): > > > Fixes are a Good Thing, of course, and this particular change's scope > > remains to be seen; but to channel most of the users I meet out there > > in the real world today: Enough with the 3.X changes already, eh? > > But that's also a decision each developer *can* make for himself. > Python does not withdraw products, or even withdraw support, just > because the core developers release something they consider better. > > If having 1 *and* 2 is so important to particular users, but they come > into conflict because of proposed changes in Python, then they're > going to have to give up 3, come here, and articulate their needs. As > you are doing -- but to have real influence, you're going to have to > do the review of David's patch that he requests. > > I really don't see how the process can work any other way. >

2 1

Summary of Python tracker Issues
by Python tracker 08 Oct '10

08 Oct '10

ACTIVITY SUMMARY (2010-10-01 - 2010-10-08) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues stats: open 2557 (+37) closed 19276 (+30) total 21833 (+44) Open issues with patches: 1071 Issues opened (37) ================== #10008: Two links point to same place http://bugs.python.org/issue10008 opened by ocean-city #10009: Automated MSI installation does not work http://bugs.python.org/issue10009 opened by amaury.forgeotdarc #10011: `except` doesn't use `isinstance` http://bugs.python.org/issue10011 opened by cool-RR #10013: fix `./libpython2.6.so: undefined reference to `_PyParser_Gram http://bugs.python.org/issue10013 opened by PaulePanter #10014: sys.path[0] is incorrect if PYTHONFSENCODING is used http://bugs.python.org/issue10014 opened by haypo #10015: Creating a multiproccess.pool.ThreadPool from a child thread b http://bugs.python.org/issue10015 opened by Michael.Olson #10016: shutil.copyfile -- allow sparse copying http://bugs.python.org/issue10016 opened by karaken12 #10017: pprint.pprint raises TypeError on dictionaries with user-defin http://bugs.python.org/issue10017 opened by arno #10018: IDLE not loading in xp pro due to tcl issue http://bugs.python.org/issue10018 opened by Grant.Andrew #10019: json.dumps with indent = 0 not adding newlines http://bugs.python.org/issue10019 opened by dpjanes #10020: docs for sqlite3 describe functions not available without reco http://bugs.python.org/issue10020 opened by doughellmann #10021: Format parser is too permissive http://bugs.python.org/issue10021 opened by belopolsky #10022: Emit more information in decoded SSL certificates http://bugs.python.org/issue10022 opened by pitrou #10023: test_lib2to3 leaks under 3.1 http://bugs.python.org/issue10023 opened by pitrou #10024: Outdated advice in C-API tutorial? http://bugs.python.org/issue10024 opened by pitrou #10025: random.seed not initialized as advertised http://bugs.python.org/issue10025 opened by goddard #10027: os.lstat/os.stat don't set st_nlink on Windows http://bugs.python.org/issue10027 opened by brian.curtin #10028: test_concurrent_futures fails on Windows Server 2003 http://bugs.python.org/issue10028 opened by brian.curtin #10029: "Equivalent to" code for zip is wrong in Python 3 http://bugs.python.org/issue10029 opened by max #10030: Patch for zip decryption speedup http://bugs.python.org/issue10030 opened by shashank #10031: Withdraw anti-recommendation of relative imports from document http://bugs.python.org/issue10031 opened by dsdale24 #10036: compiler warnings for various modules on Ubuntu x86 http://bugs.python.org/issue10036 opened by jfinkels #10037: multiprocessing.pool processes started by worker handler stops http://bugs.python.org/issue10037 opened by asksol #10038: Returntype of json.loads() on strings http://bugs.python.org/issue10038 opened by llnik #10039: python é.py fails with UnicodeEncodeError if PYTHONFSENCODING http://bugs.python.org/issue10039 opened by haypo #10040: GZipFile failure on large files http://bugs.python.org/issue10040 opened by Robert.Rohde #10041: socket.makefile(mode = 'r').readline() silently removes carria http://bugs.python.org/issue10041 opened by kaizhu #10042: total_ordering stack overflow http://bugs.python.org/issue10042 opened by francescor #10043: UnboundLocalError with local variable set by setattr, caused b http://bugs.python.org/issue10043 opened by ssc #10044: small int optimization http://bugs.python.org/issue10044 opened by pitrou #10045: poor cStringIO.StringO seek performance http://bugs.python.org/issue10045 opened by boogenhagn #10046: Correction to atexit documentation http://bugs.python.org/issue10046 opened by Jason.Baker #10047: python-2.6.6 coredump running newspipe http://bugs.python.org/issue10047 opened by wiz #10048: urllib.request documentation confusing http://bugs.python.org/issue10048 opened by pitrou #10049: Add a "no-op" (null) context manager to contextlib http://bugs.python.org/issue10049 opened by hniksic #10050: urllib.request still has old 2.x urllib primitives http://bugs.python.org/issue10050 opened by pitrou #10051: distutils fail to install unicode-encoded files with POSIX loc http://bugs.python.org/issue10051 opened by mgorny Most recent 15 issues with no replies (15) ========================================== #10051: distutils fail to install unicode-encoded files with POSIX loc http://bugs.python.org/issue10051 #10050: urllib.request still has old 2.x urllib primitives http://bugs.python.org/issue10050 #10048: urllib.request documentation confusing http://bugs.python.org/issue10048 #10039: python é.py fails with UnicodeEncodeError if PYTHONFSENCODING http://bugs.python.org/issue10039 #10037: multiprocessing.pool processes started by worker handler stops http://bugs.python.org/issue10037 #10036: compiler warnings for various modules on Ubuntu x86 http://bugs.python.org/issue10036 #10025: random.seed not initialized as advertised http://bugs.python.org/issue10025 #10023: test_lib2to3 leaks under 3.1 http://bugs.python.org/issue10023 #10022: Emit more information in decoded SSL certificates http://bugs.python.org/issue10022 #10018: IDLE not loading in xp pro due to tcl issue http://bugs.python.org/issue10018 #10017: pprint.pprint raises TypeError on dictionaries with user-defin http://bugs.python.org/issue10017 #10009: Automated MSI installation does not work http://bugs.python.org/issue10009 #10008: Two links point to same place http://bugs.python.org/issue10008 #9998: find_library should search LD_LIBRARY_PATH on linux http://bugs.python.org/issue9998 #9995: "setup.py register sdist upload" requires pass to be saved http://bugs.python.org/issue9995 Most recent 15 issues waiting for review (15) ============================================= #10049: Add a "no-op" (null) context manager to contextlib http://bugs.python.org/issue10049 #10045: poor cStringIO.StringO seek performance http://bugs.python.org/issue10045 #10044: small int optimization http://bugs.python.org/issue10044 #10041: socket.makefile(mode = 'r').readline() silently removes carria http://bugs.python.org/issue10041 #10039: python é.py fails with UnicodeEncodeError if PYTHONFSENCODING http://bugs.python.org/issue10039 #10037: multiprocessing.pool processes started by worker handler stops http://bugs.python.org/issue10037 #10030: Patch for zip decryption speedup http://bugs.python.org/issue10030 #10028: test_concurrent_futures fails on Windows Server 2003 http://bugs.python.org/issue10028 #10027: os.lstat/os.stat don't set st_nlink on Windows http://bugs.python.org/issue10027 #10019: json.dumps with indent = 0 not adding newlines http://bugs.python.org/issue10019 #10016: shutil.copyfile -- allow sparse copying http://bugs.python.org/issue10016 #10014: sys.path[0] is incorrect if PYTHONFSENCODING is used http://bugs.python.org/issue10014 #9998: find_library should search LD_LIBRARY_PATH on linux http://bugs.python.org/issue9998 #9993: shutil.move fails on symlink source http://bugs.python.org/issue9993 #9992: Command line arguments are not correctly decodedif locale and http://bugs.python.org/issue9992 Top 10 most discussed issues (10) ================================= #10044: small int optimization http://bugs.python.org/issue10044 22 msgs #4661: email.parser: impossible to read messages encoded in a differe http://bugs.python.org/issue4661 14 msgs #10049: Add a "no-op" (null) context manager to contextlib http://bugs.python.org/issue10049 12 msgs #9800: Fast path for small int-indexing of lists and tuples http://bugs.python.org/issue9800 9 msgs #10021: Format parser is too permissive http://bugs.python.org/issue10021 9 msgs #6302: email.header.decode_header data types are inconsistent and inc http://bugs.python.org/issue6302 8 msgs #9873: urllib.parse: Allow bytes in some APIs that use string literal http://bugs.python.org/issue9873 7 msgs #10029: "Equivalent to" code for zip is wrong in Python 3 http://bugs.python.org/issue10029 7 msgs #5088: optparse: inconsistent default value for append actions http://bugs.python.org/issue5088 6 msgs #9017: doctest option flag to enable/disable some chunk of doctests? http://bugs.python.org/issue9017 6 msgs Issues closed (30) ================== #2982: more tests for pyexpat http://bugs.python.org/issue2982 closed by amaury.forgeotdarc #4487: Add utf8 alias for email charsets http://bugs.python.org/issue4487 closed by r.david.murray #7789: Issue using datetime with format() http://bugs.python.org/issue7789 closed by belopolsky #8017: c_char_p.value does not return a bytes object in Windows. http://bugs.python.org/issue8017 closed by ocean-city #8190: Add a PyPI XML-RPC client module http://bugs.python.org/issue8190 closed by eric.araujo #8584: test_multiprocessing skips some tests http://bugs.python.org/issue8584 closed by brian.curtin #8670: c_types.c_wchar should not assume that sizeof(wchar_t) == size http://bugs.python.org/issue8670 closed by haypo #8980: distutils.tests.test_register.RegisterTestCase.test_strict fai http://bugs.python.org/issue8980 closed by tarek #9060: Python/dup2.c doesn't compile on (at least) newlib http://bugs.python.org/issue9060 closed by amaury.forgeotdarc #9065: tarfile: default root:root ownership is incorrect. http://bugs.python.org/issue9065 closed by lars.gustaebel #9272: CGIHTTPServer poisons os.environ http://bugs.python.org/issue9272 closed by orsenthil #9533: metaclass can't derive from ABC http://bugs.python.org/issue9533 closed by benjamin.peterson #9759: GzipFile object should raise ValueError on .read() after .clos http://bugs.python.org/issue9759 closed by pitrou #9903: test_concurrent_futures writes on stderr http://bugs.python.org/issue9903 closed by bquinlan #9936: trace misreports "missing" lines http://bugs.python.org/issue9936 closed by belopolsky #9978: Better wait for slow machine in test_os (_kill_with_event) http://bugs.python.org/issue9978 closed by ocean-city #9989: ctypes bitfield problem http://bugs.python.org/issue9989 closed by ocean-city #9996: binascii should convert unicode strings http://bugs.python.org/issue9996 closed by r.david.murray #10003: signal.SIGBREAK regression on windows http://bugs.python.org/issue10003 closed by brian.curtin #10006: non-Pythonic fate of __abstractmethods__ http://bugs.python.org/issue10006 closed by benjamin.peterson #10010: ".. index::" position http://bugs.python.org/issue10010 closed by orsenthil #10012: httplib shadows builtin, assumes strings http://bugs.python.org/issue10012 closed by orsenthil #10026: xml.dom.pulldom strange behavior http://bugs.python.org/issue10026 closed by georg.brandl #10032: os.setuid and os.setgid have unexpected influence on serial mo http://bugs.python.org/issue10032 closed by ned.deily #10033: can't run unittest because of issubclass http://bugs.python.org/issue10033 closed by ned.deily #10034: Readline doc issue http://bugs.python.org/issue10034 closed by georg.brandl #10035: sgmllib fail to parse html containing <!- .... -> http://bugs.python.org/issue10035 closed by georg.brandl #1050268: rfc822.parseaddr is broken, breaks sendmail call in smtplib http://bugs.python.org/issue1050268 closed by r.david.murray #845560: imaplib: traceback from _checkquote with empty string http://bugs.python.org/issue845560 closed by r.david.murray #1210680: Split email headers near a space http://bugs.python.org/issue1210680 closed by r.david.murray

1 0

os.path.normcase rationale?
by Chris Withers 08 Oct '10

08 Oct '10

Hi All, I'm curious as to why, with a file called "Foo.txt" on a case descriminating but case insensitive filesystem, os.path.normcase('FoO.txt') will return "foo.txt" rather than "Foo.txt"? Yes, I know the behaviour is documented, but I'm wondering if anyone can remember the rationale for that behaviour? cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk

18 35

Adding Wing 4 project to
by Michael Foord 08 Oct '10

08 Oct '10

Hello all, There is a Wing IDE [1] project file in Misc/ which I use for working on Python. The project file is 'python-wing.wpr'. Wing 4 is now in beta and I have switched to using it. Wing 4 uses an updated, backwards incompatible, project file format. I would like to add a Wing 4 project file to Misc, called 'python-wing4.wpr' to all the branches I work on (likely py3k, python27-maint and python31-maint). Any objections to this? Once Wing 4 is out of beta there are several options. Major version updates to Wing are infrequent, so the options are listed in my order of preference: 1. rename the old file 'python-wing3.wpr' and rename 'python-wing4.wpr' to 'python-wing.wpr' 2. delete the wing 3 project file altogether and rename 'python-wing4.wpr' to 'python-wing.wpr' 3. stay with versioned project file names and rename 'python-wing.wpr' to 'python-wing3.wpr' (Option 3 could be done immediately of course.) All the best, Michael Foord [1] http://wingware.com/ -- http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.

4 6

Re: [Python-Dev] Patch making the current email package (mostly) support bytes
by lutz＠rmi.net 07 Oct '10

07 Oct '10

Stephen J. Turnbull wrote (giving me an opening to jump in here): > R. David Murray writes: > > In other words, my proposed patch only makes email5 1/8 to 1/4 > > broken, instead of half broken as it is now. But not un-broken > > enough for Mailman, it sounds like. > > IMO, not in the long run. But realistically, in the applications I > know of, most desired traffic is conformant, and since there aren't > any Python 3 email apps yet, this isn't even a regression. :-/ Well, yes there are, and yes it is. As I pointed out in a thread on this list back in June, there are multiple large Python 3 email "apps" in the new Programming Python, a book which is about to be released, and which will be read by at least tens of thousands of people, many of whom will be evaluating the stability of Python 3. These apps include both a simple webmail site, as well as a more sophisticated 5k-line tkinter email client -- one which I've been using for all my personal and business email over the last 6 months, and which works well with the email package as it is in 3.1 (albeit with a bit of workaround code). This includes support for Unicode, MIME, headers, attachments, and the lot. I'm forwarding a link to the code of these clients to David by private email in case they might be useful as a test case (O'Reilly has already posted them ahead of the book, but they may be a bit too heavy for use in formal testing). The email package is obviously less than ideal today, and there are many other clients for it besides my own, of course. But making it backward incompatible at this point is likely to be seen as a big negative to newcomers evaluating 3.X viability. And as I tried to make clear in June, this list should carefully weigh the PR cost of pulling the rug out from under those brave souls who have already taken the time to accommodate the 3.X world you've mandated. To put that more strongly, the Python user base is much larger than this list's readership. If I'm using 3.1 email, so are many others. People will accept the 3.X world you make up to a point, but it's impossible to code to a moving target, much less base a product on it. At some point, they'll simply stop trying to keep up; in fact, some already have. Fixes are a Good Thing, of course, and this particular change's scope remains to be seen; but to channel most of the users I meet out there in the real world today: Enough with the 3.X changes already, eh? --Mark Lutz (http://learning-python.com, http://rmi.net/~lutz)

3 2