STINNER Victor added the comment:
I tried... "the issue is *now* complelty fixed"
--
___
Python tracker
<http://bugs.python.org/issue9992>
___
___
STINNER Victor added the comment:
> We shouldn't need to reopen the file in the first place.
> If we already have a file handle, we can rewind it.
> Then the encoding of the file name becomes irrelevant.
Oh yes, great idea. r85476 implements this solution (use lseek(0) on
New submission from STINNER Victor :
Example:
$ ./python
Python 3.2a3+ (py3k, Oct 15 2010, 14:31:59)
>>> compile('', 'abc\uDC80', 'exec')
...
UnicodeEncodeError: 'utf-8' codec can't encode character '\udc80' in position
3: surr
STINNER Victor added the comment:
#6543 changed code->co_filename encoding from filesystem
encoding+surrogateescape to utf-8+strict.
With my patch, compile('', '\udcc3\udca9', 'exec').co_filename gives 'é', it
doesn't depend on the file
STINNER Victor added the comment:
See also #9713.
--
___
Python tracker
<http://bugs.python.org/issue10114>
___
___
Python-bugs-list mailing list
Unsubscribe:
STINNER Victor added the comment:
See also issue #10114.
--
___
Python tracker
<http://bugs.python.org/issue9713>
___
___
Python-bugs-list mailing list
Unsub
STINNER Victor added the comment:
> All filenames should use the filesystem encoding in Python.
Here is a new patch [code_encoding.patch] implementing this idea:
- Use filesystem encoding (and surrogateescape) to encode/decode paths in
compile() and the parser, instead of utf-8 in str
STINNER Victor added the comment:
> I do not see what filesystem encodings, or any other encoding
> to bytes should really have to do with the [code.co_filename].
co_filename attribute is used to display the traceback: Python opens the
related file, read the source code line and disp
STINNER Victor added the comment:
Remove [compile_surrogates.patch] because it creates filenames unencode to the
filesystem encoding. Eg. compile('', '\udcc3\udca9', 'exec').co_filename gives
'é' e
Changes by STINNER Victor :
Removed file: http://bugs.python.org/file19243/compile_surrogates.patch
___
Python tracker
<http://bugs.python.org/issue10114>
___
___
Pytho
STINNER Victor added the comment:
> Here is a new patch [code_encoding.patch] implementing this idea:
> - Use filesystem encoding (and surrogateescape) to encode/decode
> paths in compile() and the parser, instead of utf-8 in strict mode
> (...)
> The patch restores the situati
STINNER Victor added the comment:
Oh, I just realized that Python 3.1.2 (last Python 3.1 release) was released
the 21st March, whereas r82063 (commit for #6543) was made the 17st June. So
the encoding change was not released yet.
--
___
Python
STINNER Victor added the comment:
Commited to 3.2 (r85569+r85570). I wait for the buildbot before porting the
patch to 3.1 and close the issue. There is already a regression on Gentoo
buildbot with ascii locale encoding, test_doctest test_zipimport_support:
http://www.python.org/dev/buildbot
New submission from STINNER Victor :
In #10114, I changed parser filename encoding from utf-8/strict to the
filesystem encoding/surrogateescape. With C locale, the filesystem encoding is
ASCII and test_doctest fails because it uses an unencoable filename
(foo-b...@baz.py).
A solution is to
STINNER Victor added the comment:
I created #10123 for the test_doctest regression.
--
___
Python tracker
<http://bugs.python.org/issue10114>
___
___
Python-bug
STINNER Victor added the comment:
Failures occurred on:
http://www.python.org/dev/buildbot/builders/AMD64%20Gentoo%20Wide%203.x
http://www.python.org/dev/buildbot/builders/sparc%20solaris10%20gcc%203.x
test_zipimport_support does also fail, but it is linked to test_doctest
failures
STINNER Victor added the comment:
Fixed by r85578.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue10123>
___
__
STINNER Victor added the comment:
Status of this issue, 5 months later: most tests pass except test_gc test_gdb
test_runpy test_sys test_wsgiref test_zipimport. Said differently, 95% of the
task (or more?) is done. It's possible to run Python installed in a non-ascii
directory wit
STINNER Victor added the comment:
Updated list of failing test with py3k and a non-ascii path:
* Linux, LANG=C: test_gc test_gdb test_runpy test_zipimport
* Windows: test_email test_httpservers test_zipimport
Possible reasons:
* test_httpservers (CGIHTTPServerTestCase.setUp): test should be
STINNER Victor added the comment:
r85655 fixed test_gdb failure.
test_runpy failure looks to be linked to test_zipimport problems.
--
___
Python tracker
<http://bugs.python.org/issue8
STINNER Victor added the comment:
r85659 + r85662 + r85663 fixed test_httpservers.
--
___
Python tracker
<http://bugs.python.org/issue8611>
___
___
Python-bug
STINNER Victor added the comment:
Good news: this issue is now fixed in py3k (Python 3.2). I cannot give a commit
number, because there are too much commits related to this problem (see #8611
and #9425), but it works ;-)
--
resolution: -> fixed
status: open ->
New submission from STINNER Victor :
See attached file for the full output. One example:
== CPython 3.2a3+ (py3k:85660, Oct 17 2010, 21:57:48) [MSC v.1500 32 bit
(Intel)]
== Windows-XP-5.1.2600-SP3 little-endian
==
FAIL
STINNER Victor added the comment:
> Victor, can you paste or attach the error for email?
It doesn't look to be related to the path name (same failure with "py3ké" or
"py3k" directory name), so I opened #10134.
--
_
Changes by STINNER Victor :
--
nosy: +haypo
___
Python tracker
<http://bugs.python.org/issue5111>
___
___
Python-bugs-list mailing list
Unsubscribe:
STINNER Victor added the comment:
Starting at r85691, the full test suite of Python 3.2 pass with ASCII,
ISO-8859-1 and UTF-8 locale encodings in a non-ascii directory. The work on
this issue is done.
--
resolution: -> fixed
status: open ->
STINNER Victor added the comment:
Starting at r85691, the full test suite of Python 3.2 pass with ASCII,
ISO-8859-1 and UTF-8 locale encodings in a non-ascii directory. The work on
this issue is done.
--
resolution: -> fixed
status: open ->
STINNER Victor added the comment:
Buildbots are green again (#10123 is closed). I ported the fix to Python 3.1
(r85716). Close this issue.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
STINNER Victor added the comment:
I'm not sure that the patch is still needed on Python 3.2.
--
___
Python tracker
<http://bugs.python.org/issue6011>
___
___
STINNER Victor added the comment:
See issue #10114: fixed in Python 3.1 (r85716) and in Python 3.2
(r85569+r85570).
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/
STINNER Victor added the comment:
I tested the example with Python 3.2 (r85691) and the issue looks to be fixed.
Can someone else confirm that?
I decompressed the ZIP archive, moved into the directory containing a.py and
b.py, and called \path\to\python.exe a.py: it works
STINNER Victor added the comment:
See also #3080 for the full unicode support in the import machinery.
--
___
Python tracker
<http://bugs.python.org/issue8
STINNER Victor added the comment:
With #8611 and #9425, I patched a lot of functions and modules, including the
NullImporter and zipimport, but not the core of the import machinery.
In my import_unicode SVN branch, I patched the import machinery to manipulate
unicode strings, instead of
STINNER Victor added the comment:
FYI, I finished my work on non-ascii filenames in Python 3.2 (#8611, #9425):
Python 3.2 now suports any filename with any locale (filesystem) encoding.
--
___
Python tracker
<http://bugs.python.org/issue1552
STINNER Victor added the comment:
Patch version 7:
- don't use snprintf() because it is not signal safe
- catch also SIGBUS and SIGILL if available
- Py_FatalError() uses fileno(stderr) instead of directly 2
- Factorize code in segfault.c and test_segfault.py
--
Added file:
STINNER Victor added the comment:
Patch version 8:
- fix compiler warning on Windows
- skip test_sigfpe() on Windows: it looks like the signal handler is not
executed, the program exits directly
- fix tests for Windows end of line (\r\n vs \n)
--
Added file: http://bugs.python.org
STINNER Victor added the comment:
> One other concern: many OSes (e.g. Linux distributions) implement
> some kind of system-wide crash-catching utility; ...
Even if it would be possible to call the original signal handler, I think that
it would be better to just disable this featur
STINNER Victor added the comment:
initfsencoding() now raises a fatal error on get_codeset() error. Use a
encoding different than the locale encoding on get_codeset() only leads to
mojibake and encoding issues, it's not a good idea. Close this issue as invalid.
--
resol
STINNER Victor added the comment:
> One solution would be to duplicate the UTF-8 decoder for OSX,
> incorporating surrogate escape. This should be much shorter
> than the full UTF-8 codec, and perhaps at least utf8_code_length
> could be shared.
Good idea, implemented in the at
STINNER Victor added the comment:
_Py_DecodeUTF8_surrogateescape() is a simplified version of
PyUnicode_DecodeUTF8Stateful():
- no "consumed" argument
- only support surrogateescape error handler
- no optimization
- don't resize the buffer at exit
Hum, resize the buffer
STINNER Victor added the comment:
I commited my patch to Python 3.2 (r85765), with a specific test in
test_cmd_line. Reopen the issue if the bug is not fixed.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
New submission from STINNER Victor :
On a failure, unittest does its best to display values. But sometimes, the
output doesn't help me. Example:
FAIL: test_listdir (test.test_pep277.UnicodeFileTests)
--
Traceback (most r
Changes by STINNER Victor :
--
components: +Unicode
___
Python tracker
<http://bugs.python.org/issue7828>
___
___
Python-bugs-list mailing list
Unsubscribe:
STINNER Victor added the comment:
I just closed #4388 with r85765 (Python 3.2): always use UTF-8 to decode the
command line arguments on Mac OS X, not the locale encoding.
I suppose that it does fix this issue. Can someone check that
STINNER Victor added the comment:
Since r85765 (issue #4388), always use UTF-8 to decode the command line
arguments on Mac OS X, not the locale encoding. Which means that the
pseudo-code becomes:
if os.name != 'nt':
if sys.platform == 'darwin':
encoding
STINNER Victor added the comment:
> $ LC_ALL=C ./python
> Fatal Python error: Py_Initialize: Unable to get the locale encoding
> SystemError: NULL result without error in PyObject_Call
> Abandon
What is your Python version? I fixed Python 3.2, but I don't plan to fix Pyt
STINNER Victor added the comment:
FYI, you should use ascii() instead of a.encode(\"utf8\") to dump arguments.
It's easier to check '\u2603' than b'\xe2\x98\x83' for me :-)
So the bug is fixed in Python 3.2, great! I was thinking that we need a test
for
STINNER Victor added the comment:
> I’m trying to build py3k on posix in a subdir called
> sep-build-dir-éric, with locale set to C.
Ah yes, this particular use case doesn't work: r85800 should fix it. Please
retry.
--
___
Python tra
STINNER Victor added the comment:
Commited to Python 3.1 (r85802).
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
STINNER Victor added the comment:
> Same errors.
Please describe exactly how you reproduced the error (write each command).
r85805 fixes another bug related to this problem. Is it a better fix than
distutils_makefile_encoding.patch: use surrogateescape error handler to decode
the Makef
STINNER Victor added the comment:
Prototype (in Python) of argvb.py. Try it with: ./python -i argvb.py.
It's not possible to create sys.argvb in Python in a module loaded by
Py_Initialize(), because sys.argv is created after Py_Initialize().
--
Added file: http://bugs.pytho
STINNER Victor added the comment:
Fixed by r85827.
--
resolution: accepted -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/
STINNER Victor added the comment:
Closed with r85829: patch test_pep277 instead of unittest.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
STINNER Victor added the comment:
Don't you know http://www.nongnu.org/failmalloc/?
--
___
Python tracker
<http://bugs.python.org/issue10195>
___
___
Pytho
STINNER Victor added the comment:
> ... every call to PyRun_InteractiveOneFlags immediately returns
>(the PyUnicode_FromString("stdin") in within PySys_GetObject() fails
> to allocate memory); this leads to a tight loop sending the total
> refcount to stderr:
I thin
New submission from STINNER Victor :
PyUnicode_EncodeFSDefault() and os.fsencode() should decompose the filename
(NFD) before encoding it to utf-8.
PyUnicode_DecodeFSDefault(AndSize)() and os.fsdecode() should precompose the
filename (NFC) after decoding it from utf-8.
Qt library does this
STINNER Victor added the comment:
I opened the issue #10209: "Mac OS X: Decompose filenames on encode, and
precompose filenames on decode".
--
___
Python tracker
<http://bugs.python.
STINNER Victor added the comment:
Patch for os.fsencode/fsdecode importing unicodedata in the function (instead
of a global import). unicodedata module is not builtin and is dynamically
loaded. We should maybe ignore ImportError if the module is not available? With
a warning?
For
New submission from STINNER Victor :
Using -b command line option, os.get_exec_path() always produce a warning.
Example:
$ ./python -b
>>> import os: os.get_exec_path({'PATH': ''})
.../Lib/os.py:395: BytesWarning: Comparison between bytes and string
path_listb
STINNER Victor added the comment:
Prototype to test nonblocking file objet:
- add getblocking() and setblocking() methods to _io._FileIO and all _pyio
classes
- fileio_setblocking() is implemented using fcntl(fd, F_SETFL, flags |
O_NONBLOCK) (POSIX only?)
- BufferedReader.read() uses read1
Changes by STINNER Victor :
Added file: http://bugs.python.org/file19385/test_process.py
___
Python tracker
<http://bugs.python.org/issue949667>
___
___
Python-bugs-list m
STINNER Victor added the comment:
> I'd like to see this patch reverted.
I created a specific branch to test the patch (I also patched
PyUnicode_EncodeFSDefault() and PyUnicode_DecodeFSDefaultAndSize()):
issue10209. test_pep277 now pass in this branch!
> encoding with NFD sh
STINNER Victor added the comment:
Some pointers.
"MacFUSE"
http://code.google.com/p/macfuse/issues/detail?id=139#c2
"FILENAME_ENCODING_PROPOSAL" (MacFUSE)
http://code.google.com/p/macfuse/wiki/FILENAME_ENCODING_PROPOSAL
"Converting to Precomposed Unicode"
http
STINNER Victor added the comment:
> My question is rather why it failed in the first place,
> when issue8207 had supposedly fixed it.
r79426 (of #8207) only disabled some tests.
The problem with test_normalize() and test_listdir() of test_pep277 is maybe
that these tests are irrevel
STINNER Victor added the comment:
> The problem with test_normalize() and test_listdir() of test_pep277
> is maybe that these tests are irrevelant on Mac OS X?
I tried a different approach (different than my patch and the svn branch):
- r85897 disables the filenames that are norm
STINNER Victor added the comment:
> - r85897 disables the filenames that are normalized differently by Python and
> by darwin
> - r85899 disables test_normalize and test_listdir tests
It looks like r85897 is enough to fix test_pep277 on "x86 Tiger 3.x" buildbot.
But r85
STINNER Victor added the comment:
I now agree with Martin: "Mac OS X: Decompose filenames on encode, and
precompose filenames on decode" was a bad idea, fix the test is the right
solution.
test_pep277 now pass on "x86 Tiger 3.x" buildbot, and so I can close this is
STINNER Victor added the comment:
> I opened the issue #10209: "Mac OS X: Decompose filenames on encode,
> and precompose filenames on decode".
It was a bad idea. I fixed test_pep277 instead with:
- r85897 disables the filenames that are normalized differently by Pytho
Changes by STINNER Victor :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue10209>
___
___
Python-bugs-list
STINNER Victor added the comment:
Fixed by r85902.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue10210>
___
__
New submission from STINNER Victor :
test_tarfile in only failing on one 3.x buildbot: AMD64 debian parallel 3.x.
The problem is related to the mtime field and os.utime():
http://www.python.org/dev/buildbot/builders/AMD64 debian parallel
3.x/builds/508/steps/test/logs/stdio
Changes by STINNER Victor :
--
nosy: +haypo
___
Python tracker
<http://bugs.python.org/issue10184>
___
___
Python-bugs-list mailing list
Unsubscribe:
STINNER Victor added the comment:
I reproduced the problem with the following commands:
cd py3k
export LANG=C
export LC_ALL=C
make distclean
./configure --with-pydebug --prefix=/home/haypo/tmp/py3ké
make
It looks like the problem is that srcdir environment variable of Makefile.pre
is ".
STINNER Victor added the comment:
I would also be nice to have a "monotonic" clock in Python. See monotonic.py
for an example. But I don't know if it solves the same problem than
time.wallclock() or not. I need a monotonic clock for a server on which NTP is
sometimes called t
Changes by STINNER Victor :
--
nosy: +haypo
___
Python tracker
<http://bugs.python.org/issue6625>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by STINNER Victor :
--
nosy: +haypo
___
Python tracker
<http://bugs.python.org/issue10310>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by STINNER Victor :
--
nosy: +haypo
___
Python tracker
<http://bugs.python.org/issue10308>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by STINNER Victor :
--
nosy: +haypo
___
Python tracker
<http://bugs.python.org/issue10309>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by STINNER Victor :
--
nosy: +haypo
___
Python tracker
<http://bugs.python.org/issue10133>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by STINNER Victor :
--
nosy: +haypo
___
Python tracker
<http://bugs.python.org/issue10086>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by STINNER Victor :
--
nosy: +haypo
___
Python tracker
<http://bugs.python.org/issue2921>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by STINNER Victor :
--
nosy: +haypo
___
Python tracker
<http://bugs.python.org/issue10070>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by STINNER Victor :
--
nosy: +haypo
___
Python tracker
<http://bugs.python.org/issue10231>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by STINNER Victor :
--
nosy: +haypo
___
Python tracker
<http://bugs.python.org/issue960325>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by STINNER Victor :
--
nosy: +haypo
___
Python tracker
<http://bugs.python.org/issue9611>
___
___
Python-bugs-list mailing list
Unsubscribe:
STINNER Victor added the comment:
I wrote a small function to call WriteConsoleOutputA() and
WriteConsoleOutputW() in Python to do some tests. It works correclty, except if
I change the code page using chcp command. It looks like the problem is that
the chcp command changes the console code
STINNER Victor added the comment:
sys_write_stdtout.patch: Create sys.write_stdout() test function to call
WriteConsoleOutputA() or WriteConsoleOutputW() depending on the input types
(bytes or str).
--
keywords: +patch
Added file: http://bugs.python.org/file19493
New submission from STINNER Victor :
In Python3, the following pattern becomes common:
with open(fullname, 'rb') as fp:
coding, line = tokenize.detect_encoding(fp.readline)
with open(fullname, 'r', encoding=coding) as fp:
...
It open
STINNER Victor added the comment:
> 1. It opens the source file one more time. This is probably acceptable
> because existing code already opens it at least four times when -m (show
> missing) option is selected. (Twice in find_executable_linenos() and
> twice in linecache.getline
New submission from STINNER Victor :
On "NetBSD 5 i386 3.x" buildbot, testTanh() of test_math fails because the sign
of wrong.
configure scripts has a test to check if tanh(-0.0) keeps the sign or no, and
on this buildbot the result is "no". pyconfig.h contains a
TANH
Changes by STINNER Victor :
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue10337>
___
___
Python-bugs-list mailing list
Unsubscribe:
STINNER Victor added the comment:
test_cmath does also fail:
http://www.python.org/dev/buildbot/builders/NetBSD%205%20i386%203.x/builds/237/steps/test/logs/stdio
==
FAIL: test_specific_values (test.test_cmath.CMathTests
Changes by STINNER Victor :
--
nosy: +gregory.p.smith
___
Python tracker
<http://bugs.python.org/issue10337>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from STINNER Victor :
http://www.python.org/dev/buildbot/builders/x86%20debian%20parallel%203.x/builds/806/steps/test/logs/stdio
test test_lib2to3 failed -- multiple errors occurred
==
ERROR: test_bom (lib2to3
Changes by STINNER Victor :
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue10338>
___
___
Python-bugs-list mailing list
Unsubscribe:
STINNER Victor added the comment:
> In the test, do you have to remove the TESTFN file manually? Isn’t that
> handled by unittest or regrtest?
The test uses TESTFN+'.py', not TESTFN ;-)
> I think the name of the function could be better but I don’t have a
> proposal.
STINNER Victor added the comment:
> what about open(.., encoding="fromcookie")?
Please don't do that. It remembers me the magical str.encode() method of
Python2. I prefer simple API with limited features: if you want to open a
Python script, use tokenize.open(), if you w
STINNER Victor added the comment:
On Saturday 06 November 2010 17:00:15 you wrote:
> Note that it is useful for opening any text file with an encoding cookie,
> not only python source code, so "tokenize.open()" sounds attractive.
Ok, the new patch (tokenize_open-2.patch) us
STINNER Victor added the comment:
Here is a patch skipping math and cmath tests if TANH_PRESERVES_ZERO_SIGN is 0.
--
keywords: +patch
Added file: http://bugs.python.org/file19532/skip_tanh_sign.patch
___
Python tracker
<http://bugs.python.
Changes by STINNER Victor :
Added file: http://bugs.python.org/file19533/skip_tanh_sign-2.patch
___
Python tracker
<http://bugs.python.org/issue10337>
___
___
Python-bug
2401 - 2500 of 35168 matches
Mail list logo
