Re: [Python-Dev] Buildbot for AIX
Hi Sridhar, Le 15/10/2010 18:50, Sridhar Ratnakumar a écrit : We definitely like to share our core Python patches for AIX 5.1/5.2 and other platforms. Great to hear that ActiveState shares their improvements for Python on AIX! Thanks for the patch in git, I will check it and try to open some issues in the Python bug tracker in order to get those modifications integrated. Please do send us any patches you may have for building Python 3 on AIX. Here is a list of issues concerning AIX on which I have been working: http://bugs.python.org/issue678250 = OK (test_mmap error) http://bugs.python.org/issue678264 = WAIT (test_resource error) http://bugs.python.org/issue730467 = WAIT (AIX_GENUINE_CPLUSPLUS error) http://bugs.python.org/issue713169 (test_pty error) http://bugs.python.org/issue941346 = OK (shared library) http://bugs.python.org/issue1542544 = OK (shared library - duplicate) http://bugs.python.org/issue1563807 (compilation ctypes) http://bugs.python.org/issue1633863 = OK (bad default compiler) http://bugs.python.org/issue1745108 (curses error) http://bugs.python.org/issue3526 (custom memory allocation system - dlmalloc) http://bugs.python.org/issue4026 = OK (fcntl extension) http://bugs.python.org/issue4499 = OK (tilde macro) http://bugs.python.org/issue5718 (ctypes compilation) http://bugs.python.org/issue6006 (ctypes compilation) http://bugs.python.org/issue6164 (flag -blibpath) http://bugs.python.org/issue7657 (test_ctypes error) http://bugs.python.org/issue8695 = OK (crash on Python 2.6.4 at compilation) http://bugs.python.org/issue8882 (pb getsockaddrarg) http://bugs.python.org/issue9700 = OK (semwait) http://bugs.python.org/issue9799 = (xlc requires --without-computed-gotos) = OK add some doc http://bugs.python.org/issue9862 = OK (broken PIPE_BUF on AIX) The 2 most interesting patches I think are: * in issue 941346, a patch to be able to compile Python as a shared library (already applied in svn) * in issue 3526, a patch to use a custom memory allocation system (dlmalloc) in Python in order to greatly reduce memory consumption on AIX = not applied yet; I need to formally discuss it on Python-dev, but I am waiting for the AIX buildbot to be setup before that. best regards -- Sébastien Sablé ___ 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] Fixing zipfile.BadZipfile to zipfile.BadZipFile
Hello [Sorry if this comes twice, connection errors here] (A bit of context: The original message comes from bug #2775, “Implement PEP 3108”, a meta-bug tracking stdlib reorganization for py3k.) I am very glad you're reorganizing the Standard Library. Thumbs up! I hope everything will comply to PEP 8 after you're done. You may have missed the timeline: Most of the PEP 3108 changes have been done before the first 3.x release went out. Now that we have 3.1 out as a stable and supported, we cannot reorganize and break compatibility anymore. (A note about PEP 8 compliance: Module names have been mostly fixed, but not all function/method names, for example in logging and unittest. If I recall correctly, readability did not seem to make all the rewrites worth it.) Since you're reorganizing, I have my own contribution. I have attached a patch. The issue7351 http://bugs.python.org/issue7351 was not accepted at the time, so I hope you'll accept this fix now. I’ve just re-read the answers there and they are still valid. Ezio and me: “Your patch need to include an alias (BadZipfile = BadZipFile) to preserve compatibility with old pickles, as explains msg95477.” Antoine: “I don't think changing it for the sake of aesthetics is a good deal given that many existing programs will have to be converted to the new spelling.” Regards ___ 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] Fixing zipfile.BadZipfile to zipfile.BadZipFile
On Mon, Oct 18, 2010 at 10:45 PM, Éric Araujo mer...@netwok.org wrote: (A note about PEP 8 compliance: Module names have been mostly fixed, but not all function/method names, for example in logging and unittest. If I recall correctly, readability did not seem to make all the rewrites worth it.) Correct. We went through this for one module that I recall (threading) and that was annoying enough that we mostly left things alone after that unless they were truly obnoxious. For threading we were able to clean a lot of things up in the process (such as adding properties where appropriate), but even so, we still made sure all the old names continued to work. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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
[Python-Dev] About resolution “accepted ” on the tracker
Hi everyone [Sorry if this comes twice, connection errors here] Raymond Hettinger noticed on the tracker that there are different interpretations of the “accepted” resolution: Traditionally it denotes an approved patch, not a agreement that the bug is valid. Daniel Stutzbach and I are (were) two users of the second meaning. It’s more useful to follow Raymond’s meaning, so that a simple query can find all accepted patches that are awaiting commit. I don’t remember if I took up this use from R. David Murray or someone else, so I thought I’d redirect the message to python-dev so that all triagers can see it. Forward to python-list as you see fit, I’m not subscribed there. Regards ___ 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
[Python-Dev] How to get commit access
I am waiting for the bug Issue5111 (httplib: wrong Host header when connecting to IPv6 litteral URL) to be fixed for a very long. Even I attached patches, test patches. How to get commit access so that I can fix such issues ( HTTP lib ) - Chandrasekar ___ 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] Fixing zipfile.BadZipfile to zipfile.BadZipFile
Hello (A bit of context: The original message comes from bug #2775, “Implement PEP 3108”, a meta-bug tracking stdlib reorganization for py3k.) I am very glad you're reorganizing the Standard Library. Thumbs up! I hope everything will comply to PEP 8 after you're done. You may have missed the timeline: Most of the PEP 3108 changes have been done before the first 3.x release went out. Now that we have 3.1 out as a stable and supported, we cannot reorganize and break compatibility anymore. (A note about PEP 8 compliance: Module names have been mostly fixed, but not all function/method names, for example in logging and unittest. If I recall correctly, readability did not seem to make all the rewrites worth it.) Since you're reorganizing, I have my own contribution. I have attached a patch. The issue7351 http://bugs.python.org/issue7351 was not accepted at the time, so I hope you'll accept this fix now. I’ve just re-read the answers there and they are still valid. Ezio and me: “Your patch need to include an alias (BadZipfile = BadZipFile) to preserve compatibility with old pickles, as explains msg95477.” Antoine: “I don't think changing it for the sake of aesthetics is a good deal given that many existing programs will have to be converted to the new spelling.” Regards ___ 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] How to get commit access
Hello Chandrasekar, On Mon, Oct 18, 2010 at 10:05:56PM +0530, chandru wrote: I am waiting for the bug Issue5111 (httplib: wrong Host header when connecting to IPv6 litteral URL) to be fixed for a very long. I just had a look at the bug. Looks like a minor change and tests are there too. I shall check that it does not break of any of existing changes and commit it. Even I attached patches, test patches. How to get commit access so that I can fix such issues ( HTTP lib ) The details on How to contribute to Python are here: http://www.python.org/dev/contributing/ -- Senthil Blutarsky's Axiom: Nothing is impossible for the man who will not listen to reason. ___ 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
[Python-Dev] About resolution “accepted ” on the tracker
Hi everyone Raymond Hettinger noticed on the tracker that there are different interpretations of the “accepted” resolution: Traditionally it denotes an approved patch, not a agreement that the bug is valid. Daniel Stutzbach and I are (were) two users of the second meaning. It’s more useful to follow Raymond’s meaning, so that a simple query can find all accepted patches that are awaiting commit. I don’t remember if I took up this use from R. David Murray or someone else, so I thought I’d redirect the message to python-dev so that all triagers can see it. Forward to python-list as you see fit, I’m not subscribed there. Regards ___ 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] About resolution “accepted ” on the tracker
On Oct 18, 2010, at 04:04 PM, Éric Araujo wrote: Raymond Hettinger noticed on the tracker that there are different interpretations of the “accepted” resolution: Traditionally it denotes an approved patch, not a agreement that the bug is valid. I'm with Raymond; I've always used 'accepted' to mean an approved patch. -Barry signature.asc Description: PGP signature ___ 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] About resolution “accepted” on the tracker
Am 18.10.2010 20:11, schrieb Barry Warsaw: On Oct 18, 2010, at 04:04 PM, Éric Araujo wrote: Raymond Hettinger noticed on the tracker that there are different interpretations of the “accepted” resolution: Traditionally it denotes an approved patch, not a agreement that the bug is valid. I'm with Raymond; I've always used 'accepted' to mean an approved patch. Same here. I think of the resolution as only relevant when the issue status is closed (or pending, of course). Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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] About resolution “accepted” on the tracker
On 18/10/2010 19:18, Georg Brandl wrote: Am 18.10.2010 20:11, schrieb Barry Warsaw: On Oct 18, 2010, at 04:04 PM, Éric Araujo wrote: Raymond Hettinger noticed on the tracker that there are different interpretations of the “accepted” resolution: Traditionally it denotes an approved patch, not a agreement that the bug is valid. I'm with Raymond; I've always used 'accepted' to mean an approved patch. Same here. I think of the resolution as only relevant when the issue status is closed (or pending, of course). Whilst I agree we lack a status (resolution is probably not right) that says either this bug has been verified as genuine and needs fixing or for a feature request that it has been agreed that the feature can be added but not yet got as far as a completed patch. All the best, Michael Georg -- http://www.voidspace.org.uk/ 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. ___ 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] About resolution “accepted” on the tracker
Am 18.10.2010 21:04, schrieb Michael Foord: On 18/10/2010 19:18, Georg Brandl wrote: Am 18.10.2010 20:11, schrieb Barry Warsaw: On Oct 18, 2010, at 04:04 PM, Éric Araujo wrote: Raymond Hettinger noticed on the tracker that there are different interpretations of the “accepted” resolution: Traditionally it denotes an approved patch, not a agreement that the bug is valid. I'm with Raymond; I've always used 'accepted' to mean an approved patch. Same here. I think of the resolution as only relevant when the issue status is closed (or pending, of course). Whilst I agree we lack a status (resolution is probably not right) that says either this bug has been verified as genuine and needs fixing or for a feature request that it has been agreed that the feature can be added but not yet got as far as a completed patch. Don't we have stage for that (at the moment at least)? Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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] About resolution “accepted” on the tracker
On 18/10/2010 20:24, Georg Brandl wrote: Am 18.10.2010 21:04, schrieb Michael Foord: On 18/10/2010 19:18, Georg Brandl wrote: Am 18.10.2010 20:11, schrieb Barry Warsaw: On Oct 18, 2010, at 04:04 PM, Éric Araujo wrote: Raymond Hettinger noticed on the tracker that there are different interpretations of the “accepted” resolution: Traditionally it denotes an approved patch, not a agreement that the bug is valid. I'm with Raymond; I've always used 'accepted' to mean an approved patch. Same here. I think of the resolution as only relevant when the issue status is closed (or pending, of course). Whilst I agree we lack a status (resolution is probably not right) that says either this bug has been verified as genuine and needs fixing or for a feature request that it has been agreed that the feature can be added but not yet got as far as a completed patch. Don't we have stage for that (at the moment at least)? Which stage do you have in mind, patch needed? This is currently used for any issue that lacks a patch and doesn't mean that an issue has been accepted as valid in any way. All the best, Michael Foord Georg -- http://www.voidspace.org.uk/ 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. ___ 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] About resolution “accepted” on the tracker
Am 18.10.2010 21:28, schrieb Michael Foord: On 18/10/2010 20:24, Georg Brandl wrote: Am 18.10.2010 21:04, schrieb Michael Foord: On 18/10/2010 19:18, Georg Brandl wrote: Am 18.10.2010 20:11, schrieb Barry Warsaw: On Oct 18, 2010, at 04:04 PM, Éric Araujo wrote: Raymond Hettinger noticed on the tracker that there are different interpretations of the “accepted” resolution: Traditionally it denotes an approved patch, not a agreement that the bug is valid. I'm with Raymond; I've always used 'accepted' to mean an approved patch. Same here. I think of the resolution as only relevant when the issue status is closed (or pending, of course). Whilst I agree we lack a status (resolution is probably not right) that says either this bug has been verified as genuine and needs fixing or for a feature request that it has been agreed that the feature can be added but not yet got as far as a completed patch. Don't we have stage for that (at the moment at least)? Which stage do you have in mind, patch needed? This is currently used for any issue that lacks a patch and doesn't mean that an issue has been accepted as valid in any way. This is probably sophistry, but if an issue is invalid, it doesn't need a patch :) The first stage seems to be unit test needed anyway, which sounds to me a bit like needs to be checked for reproducibility/validity. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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
[Python-Dev] Digital video basics tutorial
http://xiph.org/video/vid1.shtml ___ 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] Digital video basics tutorial
On 10/18/2010 3:33 PM, Janzert wrote: http://xiph.org/video/vid1.shtml Sorry, sent to the wrong place. Janzert ___ 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] About resolution “accepted” on the tracker
On Mon, 18 Oct 2010 21:31:24 +0200 Georg Brandl g.bra...@gmx.net wrote: This is probably sophistry, but if an issue is invalid, it doesn't need a patch :) Not only, but it generally gets closed too. The first stage seems to be unit test needed anyway, which sounds to me a bit like needs to be checked for reproducibility/validity. I don't like this first stage, it makes it look like we mandate a proper unit test to proceed with actually writing patches, which is really not true. Regards Antoine. ___ 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] About resolution “accepted ” on the tracker
On Mon, 18 Oct 2010 17:20:13 +0200, mer...@netwok.org wrote: Raymond Hettinger noticed on the tracker that there are different interpretations of the âacceptedâ resolution: Traditionally it denotes an approved patch, not a agreement that the bug is valid. Daniel Stutzbach and I are (were) two users of the second meaning. Itâs more useful to follow Raymondâs meaning, so that a simple query can find all accepted patches that are awaiting commit. I donât remember if I took up this use from R. David Murray or someone else, so I thought Iâd redirect the message to python-dev so that all triagers can see it. Forward to python-list as you see fit, Iâm not subscribed there. 'twasn't me, I figured the resolution field was only for resolved bugs. I did notice a number of people using for accepted feature requests or 'valid bugs', or sometimes patches accepted in principle that were nonetheless not quite complete. Clearly (some) people would *like* a toggle that indicates such a status :) -- R. David Murray www.bitdance.com ___ 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] About resolution “accepted” on the tracker
On Mon, 18 Oct 2010 21:42:08 +0200, Antoine Pitrou solip...@pitrou.net wrote: On Mon, 18 Oct 2010 21:31:24 +0200 Georg Brandl g.bra...@gmx.net wrote: This is probably sophistry, but if an issue is invalid, it doesn't need a patch :) Not only, but it generally gets closed too. The first stage seems to be unit test needed anyway, which sounds to me a bit like needs to be checked for reproducibility/validity. I don't like this first stage, it makes it look like we mandate a proper unit test to proceed with actually writing patches, which is really not true. Why isn't it? :) Seriously, though, what it indicates is indicates is that we need a unit test for the patch to be complete. We have a number of issues with patches but no tests, I believe. Which order 'unit test' and 'fix' occur in is arbitrary in practice. I certainly prefer to have the unit tests first myself, though. The problem is that the stage field really isn't all that useful. I'd prefer a set of check boxes, as I've suggested in the wiki. I was the one who advocated labeling it 'unit test needed', but if people would rather change it back to just 'test needed', I will raise no objection, since in practice trying to squeeze the meaning I wanted into the stage field doesn't really work. -- R. David Murray www.bitdance.com ___ 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
[Python-Dev] My work on Python3 and non-ascii paths is done
Hi, Seven months after my first commit related to this issue, the full test suite of Python 3.2 pass with ASCII, ISO-8859-1 and UTF-8 locale encodings in a non- ascii source directory. It means that Python 3.2 now process correctly filenames in all modules, build scripts and other utilities, with any locale encoding. General changes: * Encode/decode filenames with the locale encoding, instead of utf-8, until the filesystem is set * mbcs encoding (Windows filesystem encoding) is now strict by default, whereas it ignores unencodable characters and replace undecodable bytes in Python 3.1. Old behaviour can still be used using the right error handler: 'ignore' to encode, 'replace' to decode. * tarfile uses utf-8 encoding on Windows (instead of mbcs), and the surrogateescape error handler on all OSes * sys.getfilesystemencoding() cannot be None anymore * Don't accept bytearray as filenames anymore Changes of the Python API: * Add os.environb: bytes version of os.environ, os.getenvb() function and os.supports_bytes_environ constant * Add os.fsencode() and os.fsdecode() functions * Remove sys.setfilesystemencoding() function Changes of the C API: * Add PyUnicode_EncodeFSDefault() function * Add PyUnicode_FSDecoder() ParseTuple converter * Add PySys_FormatStdout(), PySys_FormatStderr() and PyErr_WarnFormat() functions * Add PyUnicode_AsWideCharString() function: don't need a buffer size. * Add Py_UNICODE_strrchr(), Py_UNICODE_strcat(), PyUnicode_AsUnicodeCopy() and Py_UNICODE_strncmp() functions * PyUnicode_DecodeFSDefault() and PyUnicode_DecodeFSDefaultAndSize() use the surrogateescape error handler * File utilities: add _Py_wchar2char() (reverse of Py_char2wchar()), _Py_stat() and _Py_fopen() functions; move all file utilities to Python/fileutils.c * The format string of PyUnicode_FromFormat() and PyErr_Format() is now pure ASCII: raise an error on non-ascii character * PyUnicode_FSConverter() doesn't accept bytearray anymore Bugfixes: * Fix modules: tarfile, pickle, pickletools, ctypes, subprocess, bz2, ssl, profile, xmlrpclib, platform, libpython (gdb plugin), sqlite, distutils.log, locale, _warnings, zipimport, imp * Fix functions: os.exec*(), os.system(), ctypes.dlopen(), os.getenv(), os.get_exec_path() * Fix tests: test_gdb, test_httpservers, test_cmd_line, test_size, test_generic_path, test_subprocess, test_doctest, test_cmd_line_script * Fix utf-8 encoder to support error handlers producing unicode string (eg. 'backslashreplace') * Fix conversion from unicode to a wide character string if Py_UNICODE and wchar_t have different sizes: UTF-16 = UTF-32 or UTF-32 = UTF-16 * Fix Python command line parser if the the command line contains surrogates * Avoid _PyUnicode_AsString() because it returns NULL if the string contains surrogates, or catch the error * Fix regrtest.py to support surrogate characters in the current working directory and in the tracebacks I wrote also some tests and documentation. The most difficult part was to debug Python initialization (Py_InitializeEx and calculate_path) and the import machinery (import.c, zipimport.c), because gdb does sometimes crash (for various reasons) and because the import machinery is fragile and difficult to understand. A special thanks to Marc-Andre Lemburg, Martin v. Löwis, Antoine Pitrou and Amaury Forgeot d'Arc for their help, useful advices and code reviews! -- Bonus: short story of PYTHONFSENCODING --- In the middle of August, I created the PYTHONFSENCODING environment variable, as suggested by Marc-Andre Lemburg. Because of this variable and because Python used utf-8 until the filesystem encoding is known, I had to write ugly and fragile redecode functions to redecode all filenames of all objects (sys.path, sys.meta_path, sys.executable, sys.modules, all code objects, etc.). Then I found 4 issues related to PYTHONFSENCODING, inconsistencies between the filesystem encoding and the locale encoding. It was not easy to decide how to fix these issues, but at the end, we choosed to drop PYTHONFSENCODING variable, use the locale encoding as the filesystem encoding, and always use utf-8 as the filesystem encoding on Mac OS X. -- Victor Stinner http://www.haypocalc.com/ ___ 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] About resolution “accepted” on the tracker
On 10/18/2010 07:07 PM, R. David Murray wrote:
Seriously, though, what it indicates is indicates is that we need a unit
test for the patch to be complete. We have a number of issues with
patches but no tests, I believe. Which order 'unit test' and 'fix'
occur in is arbitrary in practice. I certainly prefer to have the unit
tests first myself, though.
The problem is that the stage field really isn't all that useful. I'd
prefer a set of check boxes, as I've suggested in the wiki.
I was the one who advocated labeling it 'unit test needed', but if
people would rather change it back to just 'test needed', I will raise
no objection, since in practice trying to squeeze the meaning I wanted
into the stage field doesn't really work.
This is about communicating both content and quality, with several
decisions at certain points. It's not a straight line step by step
process, which is why it gets confusing if you try to treat it as such.
Check boxes work well for things like this.
Could something like (or parts of) the following work? It would have
assignment and module keywords items as well.
[] boxes can be set or unset by both the bug/feature author and those with
tracker/commit privileges.
{} boxes settable only by those with tracker and commit privileges?
Title []
Description [___...]
TYPE:
[] Bug
Versions:
[] 2.5 [] 2.6[] 2.7
[] 3.0 [] 3.1[] 3.2
...
{} Verified
[] Feature Request
For Version [_]*Drop down list.
{} Initial approval*May be rejected later.
Requires PEP:
{} yes PEP Number [__]
{} no
STATUS:
Components:
[] Code Patch {} approved
[] Test patch {} approved
[] Document Patch {} approved
[] News Entry Patch {} approved
[] Final Commit Approval {} approved
{} Committed
Revision #(s) {}
Notes:{}
{} Rejected
Reason:{___} *Drop down list here.
{} Closed
ATTENTION REQUESTS:
[] Request bug verification *Auto set when new bug.
[] Request feature initial approval *Auto set when new.
[] Request author reassignment
*Current author unable to work on this.
Request test patch [] review [] approval
Request code patch [] review [] approval
Request document patch [] review [] approval
Request news patch [] review [] approval
Request final commit[] review [] approval
*More than one attention request can be set at a time.
*Reviewer clears request if revision is needed or item is ok.
Most changes to any of these should also be documented in the discussion
area as well.
Ron
___
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] My work on Python3 and non-ascii paths is done
On 10/18/2010 08:53 PM, Victor Stinner wrote:
Hi,
Seven months after my first commit related to this issue, the full test suite
of Python 3.2 pass with ASCII, ISO-8859-1 and UTF-8 locale encodings in a non-
ascii source directory. It means that Python 3.2 now process correctly
filenames in all modules, build scripts and other utilities, with any locale
encoding.
[...]
Congratulations Victor, From what I saw it looked like it was a lot of work.
I don't suppose you could take a look at this issue also?
http://bugs.python.org/issue9319
(If not, maybe someone else can.)
When pydoc uses imp to search for modules it runs across a test file with a
bad BOM. Which then causes a segfault.
r...@gutsy:~/svn/py3k$ ./python
Python 3.2a3+ (py3k:85719, Oct 18 2010, 22:32:47)
[GCC 4.4.3] on linux2
Type help, copyright, credits or license for more information.
help('modules ')
Here is a list of matching modules. Enter any module name to get more help.
Segmentation fault
Or more directly...
import imp
imp.find_module('test/badsyntax_pep3120')
Segmentation fault
I believe it should issue a SyntaxError instead.
Thanks,
Ron Adam
___
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] My work on Python3 and non-ascii paths is done
Congratulations Victor! This is not a small feat. The PSU should send you cookies to thank you, but they won’t since they don’t exist and ___ 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
