[Python-Dev] A bunch of patch reviews
Below are a set of five patch reviews. I don't have any patch to push for at
this point, so these patch reviews are just for you to read and enjoy. Thanks
everybody for developing and maintaining Python. I wouldn't know what to do
without it.
--Michiel.
Patch [ 853890 ] Optional keyword unicode args not handled correctly
The skipitem function in Python/getargs.c misses code for several argument
formats. This patch solves one of them ('u' and 'u#'), patch 985713 solves
another one ('w'). There are several more that need to be solved. I've asked the
patch contributor to write a complete patch, including all missing formats. This
patch is rather straightforward and solves a serious problem, so I'd recommend
accepting it once it is complete.
Patch [ 1167316 ] a fix for doctest crash when it is ran on itself
doctest.py in Lib fails when it is run on itself. The error is due to missing
"import doctest" statements and similar small problems in the doctest
docstrings. Patch seems to work correctly.
Patch [ 1166780 ] Fix _tryorder in webbrowser.py
In webbrowser.py, a user can override the default list of web browsers to be
opened by setting the BROWSER variable. Currently, if BROWSER is set, the
default list is not used at all. The patch contributor notes that if BROWSER is
set incorrectly, this may result in no browser being opened at all. While this
is true, seeing a different browser open instead of the one specified in BROWSER
may lead to confusion, and may lead to future bug reports saying "webbrowser.py
ignores the BROWSER variable" if a user sets BROWSER incorrectly. So my
suggestion is to at least print a warning message if the browser specified in
BROWSER cannot be used, and then proceed by opening one of the default browsers.
Patch [ 764221 ] add set/getattr interface to tkFont.Font objects
This patch has already made it into Python2.4, so I think this patch can be
closed.
Patch [ 1163314 ] the quotes page on the Web site links to something broken
The patch writer is correct that the link is broken, but it's not a Python bug.
I've suggested him to write to the web master.
--
Michiel de Hoon, Assistant Professor
University of Tokyo, Institute of Medical Science
Human Genome Center
4-6-1 Shirokane-dai, Minato-ku
Tokyo 108-8639
Japan
http://bonsai.ims.u-tokyo.ac.jp/~mdehoon
___
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] New PyPI broken package editing
Walter Dörwald wrote: I'm not sure if this is the right approach. I think the approach is right, but the implementation is wrong. The encoding I specify in setup.py should be independent of the encoding used between distutils and PyPI to communicate on the wire. I.e. the author (and maintainer) argument should always be unicode. "should" is a correct description. It should allow Unicode strings, which it then should encode to UTF-8 during transmission. The matter of fact is that the register command as released in 2.4 (and 2.4.1) doesn't. When str is passed, this is treated as any other str in a unicode context, it is decoded using the default encoding. This would fix another problem: It would make it nearly impossible to send a request to PyPI with the wrong encoding, because any encoding problems are sorted out completely on the client side. distutils should *not* assume that byte strings are in the default encoding. It is fair to assume they are in ASCII; if the administrator has changed the default encoding, then this cannot possibly affect all the setup.py files out there. Also, it is a fact that the deployed versions of the register command just send byte strings in setup.py as-is, without trying to do any kind of recoding. In any case, PyPI now requires that the form submission uses UTF-8, and refuses anything else. So it *is* impossible to send, say, Latin-1; whether the client makes that happen by properly encoding Unicode strings or whether they are in setup.py in the first place does not matter. Is there a way to display the HTTP response by PyPI? Yes, please invoke upload with --show-response. Editing the package is still broken. The link "edit" on the page http://www.python.org/pypi/ll-ansistyle/0.6.1 gives: --- Error... There's been a problem with your request exceptions.UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 92: ordinal not in range(128) I see. I'll investigate. 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] Deprecating 2.2 old bugs
Facundo Batista wrote: > Going on with the old bugs checking, here are the results for 2.2. > When I'll finish this will be put in an informational PEP. > I just want to publicly thank Facundo for doing this. I remember when I went through one weekend and did a ton of old bug reports; it ain't exactly fun. And he even spent his PyCon sprint time on this some more. So thanks from me for putting the time in on this. -Brett ___ 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
