[issue4761] create Python wrappers for openat() and others

[Ross Lagerwall]

Ross Lagerwall  added the comment:

Fixed small #ifdef error with fstatat.

--
Added file: http://bugs.python.org/file20460/i4761_v6.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2987] RFC2732 support for urlparse (IPv6 addresses)

[Matt Joiner]

Changes by Matt Joiner :


--
nosy: +anacrolix

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10935] wsgiref.handlers.BaseHandler and subclasses of str

[Denis S. Otkidach]

Denis S. Otkidach  added the comment:

Phillip, your argument about interfacing with code written in C doesn't work 
for built-in immutable types like str. Any subclass of str must call 
str.__new__ thus keeping proper internal state.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10954] No warning for csv.writer API change

[Lennart Regebro]

New submission from Lennart Regebro :

In Python 2 the file used for csv.writer() should be opened in binary mode, 
while in Python 3 is should be opened in text mode but with newlines set to ''.

This change is neither warned for by python -3, nor is there a fixer for it 
(and making a fixer would be tricky), thus it provides a surprising API change.

I think that csv.writer() should warn or even fail if the file is opened in 
binary mode under Python 3. Failing is a god option, as a binary file is likely 
to be a port from Python 2, and you are likely to get the less useful message 
"must be bytes or buffer, not str". Even if you understand that message, you 
will then probably just change the file mode from binary to text, but you will 
not add the lineendings='' parameter, and thusly you might cause subtle error 
on windows.

--
components: 2to3 (2.x to 3.0 conversion tool), Library (Lib)
messages: 126596
nosy: lregebro
priority: normal
severity: normal
status: open
title: No warning for csv.writer API change
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10952] Don't normalize module names to NFKC?

[STINNER Victor]

STINNER Victor  added the comment:

> b) what if the file system implementation mangles file names.
> 
> I'd use the same approach as with case-insensitive lookups: verify
> that the file we read is really the one we want.

Only Mac OS X and the HFS+ filesystem normalize filenames (to a variant
of NFD). But such normalization is a good thing! I mean that I don't
think that we have anything to do for that.

---
The user creates café.py file, name written with the keyboard in NFD:
cafe\u0301 (this is very unlikely, all operating systems prefer NFC for
the keyboard, but it's just to give an example). Mac OS X normalizes the
filename to NFD: cafe\u0301.py is created in the filesystem.

Then (s)he tries to import the café module: write "import café" with
his/her NFD keyboard. Python normalizes café to NFKC (caf\xe9) and then
tries to read caf\xe9.py. Mac OS X normalizes the filename to NFD: cafe
\u0301.py, and this file, so it works as expected.
---

I suppose that any filesystem normalization is good, because it avoids
surprising behaviours (eg. having two files cafe\u0301 and caf\xe9 with
names rendered exactly the same on screen). We should maybe patch
Windows, Mac OS, Linux & co to normalize to NFKC :-)

> a) how can users make sure that they name the files correctly?
>
>  For a), wrt. "I'm not able to write U+03BC with my keyboard", I say
> "tough luck - don't use that character in a module name, then".
> Somebody with a Greek keyboard will have no problems doing that. 

Even if I try to agree with "don't use that character in a module name":
it can be surprising for an English who would like to use µTorrent (U
+00B5) module name in his/her project. She/He can creates µTorrent.py
with his non-Greek keyboard (\xb5Torrent.py), but than import µTorrent
(import \xb5Torrent) fails: "ImportError: No module named µTorrent". The
error message is "ImportError: No module named \u03BCTorrent": the
identifier is normalized, but remember that µ (U+00B5) and μ (U+03BC)
are rendered exactly the same by most fonts.

We should at least document this surprising behaviour in the import
documentation. Something like:

<< WARNING: Non-ASCII characters in module names are normalized to NFKC
by the Python parser ([PEP 3131]). For example, import µTorrent (µ: U
+00B5) is normalized to import μTorrent (μ: U+03BC): Python will try to
open "\u03BCTorrent.py" (or "\u03BCTorrent/__init__.py"), and not
"\xB5Torrent.py" (or "\xB5Torrent/__init__.py"). >>

> This is really the same as any other non-ASCII character which you are
> unable to type: it just means that you can't conveniently enter the
> respective Python identifier. Just try importing "саша", for example.
> Get a different keyboard.

I disagree. For identifiers in the source code, it works (transparently)
as expected.

A Greek starts a project using µTorrent (\u03BCTorrent) identifier in
its source code (a variable name, not a module name). An English writes
a patch using µTorrent written with \xB5Torrent: both forms are accepted
by Python, and it works.

"exec"))
it works

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10812] Add some posix functions

[Ross Lagerwall]

Ross Lagerwall  added the comment:

A few small fixes for OS X:
It has no return value for sethostid() and sets different errno if permission 
denied,
waitid() is broken - so its disabled,
the timeval struct used in futimes and lutimes is defined slightly differently.

--
Added file: http://bugs.python.org/file20461/10812_v6.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10954] No warning for csv.writer API change

[Lennart Regebro]

Changes by Lennart Regebro :


--
nosy: +sjmachin

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10923] Deadlock because of the import lock when loading the utf8 codec

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

> can't we raise a RuntimeError on a deadlock?

Deadlock detection is difficult, and probably impossible if the involved locks 
don't use the same underlying mechanism. (A lock can be a pthread object, a 
file opened with os.O_EXCL, and even a loop that tests some atomic variable)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10954] No warning for csv.writer API change

[John Machin]

John Machin  added the comment:

I believe that both csv.reader and csv.writer should fail with a meaningful 
message if mode is binary or newline is not ''

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10923] Deadlock because of the import lock when loading the utf8 codec

[STINNER Victor]

STINNER Victor  added the comment:

> > can't we raise a RuntimeError on a deadlock?

(I mean: deadlock on the import lock)

> Deadlock detection is difficult, and probably impossible if the
> involved locks don't use the same underlying mechanism

If it is impossible to detect deadlocks, can't we raise an exception if two 
threads try to import a module at the same time? (change completly how the 
import "lock" is handled)

Antoine changed recently the io module to raise a RuntimeError on reentrant 
calls in the io module (io.Buffered*.*()): #10478.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10451] memoryview can be used to write into readonly buffer

[STINNER Victor]

Changes by STINNER Victor :


--
nosy: +haypo

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10952] Don't normalize module names to NFKC?

[STINNER Victor]

STINNER Victor  added the comment:

> There is also issue c) what if the filesystem encoding can only
> represent a compatibility character, say U+00B5, but not its NFKC
> equivalent, U+03BC?

It is the same problem than not being able to write U+03BC with a keyboard: in 
this setup, don't use U+00B5 or U+03BC. More generally: don't use non-ASCII 
characters if your setup is not fully Unicode compliant, or fix your setup :-)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10923] Deadlock because of the import lock when loading the utf8 codec

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> If it is impossible to detect deadlocks, can't we raise an exception
> if two threads try to import a module at the same time? (change
> completly how the import "lock" is handled)
> 
> Antoine changed recently the io module to raise a RuntimeError on
> reentrant calls in the io module (io.Buffered*.*()): #10478.

Reentrant calls and concurrent calls are not the same. If the import
lock is changed to raise an exception, heaps of multi-threaded software
will be broken.

What we could do is set a timeout on the import lock, but then we need
to choose a rather large one (e.g. 5 minutes), and who will wait 5
minutes before killing the process?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10935] wsgiref.handlers.BaseHandler and subclasses of str

[Jean-Paul Calderone]

Jean-Paul Calderone  added the comment:

> Phillip, your argument about interfacing with code written in C doesn't work 
> for built-in immutable types like str.

Sure it does.  Definitely-str is easier to handle in C than maybe-str-subclass. 
 It doesn't matter that str.__new__ gets called.  Other things might get called 
too, with who-knows-what side-effects.

wsgi is right to demand str and only str and exactly str.

--
nosy: +exarkun

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10935] wsgiref.handlers.BaseHandler and subclasses of str

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Jean-Paul Calderone  added the comment:
> 
> > Phillip, your argument about interfacing with code written in C
> doesn't work for built-in immutable types like str.
> 
> Sure it does.  Definitely-str is easier to handle in C than
> maybe-str-subclass.

Well, PyString_AsString() works on subclasses as well as on str itself.
I'm not sure what operations you're thinking about here.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3080] Full unicode import system

[Nick Coghlan]

Nick Coghlan  added the comment:

Victor, could you please create a Reitveld review for this? The auto-review 
creator can't cope with the Git diffs.

--
nosy: +ncoghlan

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10935] wsgiref.handlers.BaseHandler and subclasses of str

[Andrey Popp]

Andrey Popp <8may...@gmail.com> added the comment:

I've also sent message[1] to web-sig about this issue.

[1]: http://mail.python.org/pipermail/web-sig/2011-January/004986.html

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3080] Full unicode import system

[STINNER Victor]

STINNER Victor  added the comment:

> Victor, could you please create a Reitveld review for this?

Yes, but not yet. I have first to cleanup the patch.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10923] Deadlock because of the import lock when loading the utf8 codec

[STINNER Victor]

STINNER Victor  added the comment:

> If the import lock is changed to raise an exception, 
> heaps of multi-threaded software will be broken.

You are right. It has done so for 12 years already (10011), so it's a bit late 
to do anything about it. And backward compatibility is very important, so I 
close this issue.

--
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10923] Deadlock because of the import lock when loading the utf8 codec

[STINNER Victor]

STINNER Victor  added the comment:

> for 12 years already (10011)

Oops, it's r10011 (to get a nice URL on the commit).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10923] Deadlock because of the import lock when loading the utf8 codec

[STINNER Victor]

STINNER Victor  added the comment:

See also issue #9260 for a possible improvment.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3080] Full unicode import system

[Nick Coghlan]

Nick Coghlan  added the comment:

OK - I'll wait until that is ready before digging into this.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9260] A finer grained import lock

[STINNER Victor]

Changes by STINNER Victor :


--
nosy: +haypo

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3080] Full unicode import system

[STINNER Victor]

STINNER Victor  added the comment:

> Use "U" format to parse a module name, and "%R" to format a module name
> (to escape surrogates characters and add quotes, instead of 
> "... '%.200s' ...").

See also #8754: repr() is better than str() for other reasons, eg. to see a 
space at the end of a module name (__import__('space ')) thanks to the quotes.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10955] Possible regression with stdlib in zipfile

[Ronald Oussoren]

New submission from Ronald Oussoren :

I ran into this issue while debugging why py2app doesn't work with python 
3.2rc2. The reason seems to be a regression w.r.t. having the stdlib inside a 
zipfile.

Note that I haven't tested this without going through py2app yet.

py2app basicly recreates a minimal sys.prefix that contains just the 
application python files and a minimal selection of files from the stdlib.

The file structure in the app bundle contains (for python3.2):

.../Resources/
lib/
   python32.zip   # Most compiled python files
   python3.2/ # Files that cannot be in the zip
  lib-dynload # Extensions

This structure works fine with python2.7 (and earlier) and python3.1, with 
python 3.2rc2 I get a bootstrap error because the filesystem encoding codec 
cannot be located.

This can be worked around by moving the encodings package and the codecs module 
from the zipfile to the python3.2 directory. 

That however is not good enough, I also have to change the default search-path 
using Py_SetPath. The default path has python32.zip before the python3.2 
directory, only when I switch those around the application loads fine.

All of this is on MacOSX 10.6.6 (where the filesystem encoding is UTF-8).

This is a regression because it is no longer possible to have a packaged python 
application where all python code is inside a zipfile. Some files must be 
outside of the file to bootstrap the interpreter.

--
messages: 126614
nosy: ronaldoussoren
priority: normal
severity: normal
stage: unit test needed
status: open
title: Possible regression with stdlib in zipfile
type: behavior
versions: Python 3.2

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10955] Possible regression with stdlib in zipfile

[STINNER Victor]

STINNER Victor  added the comment:

It should be a regression introduced by #8611 or #9425.

--
nosy: +haypo

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10955] Possible regression with stdlib in zipfile

[STINNER Victor]

Changes by STINNER Victor :


--
nosy: +georg.brandl
priority: normal -> release blocker

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10956] file.write and file.read don't handle EINTR

[Mark Florisson]

New submission from Mark Florisson :

In both Python versions EINTR is not handled properly in the file.write and 
file.read methods. 

- file.write -
In Python 2, file.write can write a short amount of
bytes, and when it is interrupted there is no way to tell how many bytes it
actually wrote. In Python 2 it raises an IOError with EINTR, whereas in Python 
3 it
simply stops writing and returns the amount of bytes written.

Here is the output of fwrite with Python 2.7 (see attached files). Note also 
how inconsistent the IOError vs OSError difference is:

python2.7 fwrite.py
Writing 10 bytes, interrupt me with SIGQUIT (^\)
^\^\(3, )
Traceback (most recent call last):
  File "fwrite.py", line 16, in 
print(write_file.write(b'a' * 10))
IOError: [Errno 4] Interrupted system call
read 65536 bytes
^\(3, )
Traceback (most recent call last):
  File "fwrite.py", line 21, in 
print('read %d bytes' % len(os.read(r, 10)))
OSError: [Errno 4] Interrupted system call

Because os.read blocks on the second call to read, we know that only 65536 of
the 10 bytes were written.

- file.read -
When interrupting file.read in Python 3, it may have read bytes that are 
inaccessible. 
In Python 2 it returns the bytes, whereas in Python 3 it
raises an IOError with EINTR.

A demonstration:

$ python3.2 fread.py
Writing 7 bytes
Reading 20 bytes... interrupt me with SIGQUIT (^\)
^\(3, )
Traceback (most recent call last):
  File "fread.py", line 18, in 
print('Read %d bytes using file.read' % len(read_file.read(20)))
IOError: [Errno 4] Interrupted system call
Reading any remaining bytes...
^\(3, )
Traceback (most recent call last):
  File "fread.py", line 23, in 
print('reading: %r' % os.read(r, 4096))
OSError: [Errno 4] Interrupted system call

Note how in Python 2 it stops reading when interrupted and it returns our
bytes, but in Python 3 it raises IOError while there is no way to access the
bytes that it read.

So basically, this behaviour is just plain wrong as EINTR is not an error, and
this behaviour makes it impossible for the caller to handle the situation
correctly.

Here is how I think Python should behave. I think that it should be possible to 
interrupt both read and write calls, however, it should also be possible for 
the user to handle these cases. 

file.write, on EINTR, could decide to continue writing if no Python signal 
handler raised an exception.
Analogously, file.read could decide to keep on reading on EINTR if no Python 
signal handler raised an exception.

This way, it is possible for the programmer to write interruptable code while
at the same time having proper file.write and file.read behaviour in case code
should not be interrupted.
KeyboardInterrupt would still interrupt read and write calls, because it
raises an exception. If the programmer decided that writes should finish
before allowing such an exception, the programmer could replace the default
signal handler for SIGINT. 

So, in pseudo-code:

bytes_written = 0

while bytes_written < len(buf):
result = write(buf)

if result < 0:
if errno == EINTR 
if PyErr_CheckSignals() < 0:
/* Propagate exception from signal handler */
return NULL
continue
else:
PyErr_SetFromErrno(PyExc_IOError)
return NULL

buf += result
bytes_written += result

return bytes_written

Similar code could be used for file.read with the obvious adjustments.

However, in case of an error (either from the write call or from a Python 
signal handler), 
it would still be unclear how many bytes were actually written. Maybe (I think
this part would be bonus points) we could put the number of bytes written on 
the exception object in this case, or make it retrievable in some other 
thread-safe way.

For files with file descriptors in nonblocking mode (and maybe other cases) it 
will still return a short amount of bytes.

--
components: IO
files: fwrite.py
messages: 126616
nosy: eggy
priority: normal
severity: normal
status: open
title: file.write and file.read don't handle EINTR
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20462/fwrite.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10956] file.write and file.read don't handle EINTR

[Mark Florisson]

Mark Florisson  added the comment:

Here is fread.py (why can you only attach one file at a time? :P)

--
Added file: http://bugs.python.org/file20463/fread.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10955] Possible regression with stdlib in zipfile

[STINNER Victor]

STINNER Victor  added the comment:

zipimport decodes filenames of the archive from cp437 or UTF-8 (depending on a 
flag in each file entry). Python has a builtin UTF-8 codec, but no cp437 
builtin codec. You should try to add encodings/cp437.py to your python3.2/ 
directory, or to build a ZIP archive with unicode filenames (I don't know how 
to do that).

Call trace:
 - Load the codec of the filesystem encoding
 - Initialize the codec registry
 - Load the codec from python32.zip
 - Load cp437 or UTF-8 codec to decode python32.zip filenames
 - *Bootstrap failure*

Detailed call trace to initialize the codec registry:
 - import encodings (Lib/encodings/__init__.py)
 - import codecs (Load Lib/codecs.py)
 - import encodings.aliases (Load Lib/encodings/aliases.py)

And then the call trace to load UTF-8 codec:
 - import encodings.utf_8 (Lib/encodings/utf_8.py)

Later, initstdio() loads also Latin1 codec (import encodings.latin_1, 
Lib/encodings/latin_1.py).

Python has builtin codecs for MBCS (filesystem encoding on Windows) and UTF-8 
(filesystem encodings on Mac OS X and many other OSes) encodings, but the codec 
lookup loads the encodings module (encodings/xxx.py).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10955] Possible regression with stdlib in zipfile

[STINNER Victor]

STINNER Victor  added the comment:

Restore priority to normal: this is a workaround, and a better fix cannot be 
done before 3.2 final.

--
priority: release blocker -> normal

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10956] file.write and file.read don't handle EINTR

[Antoine Pitrou]

Antoine Pitrou  added the comment:

What behaviour would you expect instead?

--
nosy: +pitrou
versions:  -Python 2.5, Python 2.6, Python 3.1

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10956] file.write and file.read don't handle EINTR

[Mark Florisson]

Mark Florisson  added the comment:

I think this sums it up: 
file.write, on EINTR, could decide to continue writing if no Python signal 
handler raised an exception.
Analogously, file.read could decide to keep on reading on EINTR if no Python 
signal handler raised an exception.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10956] file.write and file.read don't handle EINTR

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Oops, sorry, had missed the relevant part in your original message.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10956] file.write and file.read don't handle EINTR

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> file.write, on EINTR, could decide to continue writing if no Python
> signal handler raised an exception.
> Analogously, file.read could decide to keep on reading on EINTR if no
> Python signal handler raised an exception.

Ok. This would only be done in buffered mode, though, so your fwrite.py example 
would have to be changed slightly (drop the ",0" in fdopen()).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10956] file.write and file.read don't handle EINTR

[Mark Florisson]

Mark Florisson  added the comment:

> Ok. This would only be done in buffered mode, though, so your fwrite.py 
> example would have to be changed slightly (drop the ",0" in fdopen()).

Indeed, good catch. So apparently file.write (in buffered mode) is also 
"incorrect" in Python 3.

--
Added file: http://bugs.python.org/file20464/fwrite.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10948] Trouble with dir_util created dir cache

[Diego Queiroz]

Diego Queiroz  added the comment:

"I would agree if mkpath were a public function."
So It is better to define what a "public function" is. Any function in any 
module of any project, if it is indented to be used by other modules, it is 
public by definition.

If new people get involved in distutils development they will need to read all 
the code, line by line and every comment, because the old developers decided 
not to document the inner workings of its functions.

"Considering that dir_util is gone in distutils2, I see no benefit in editing 
the doc."
Well, I know nothing about this. However, if you tell me that distutils2 will 
replace distutils, I may agree with you and distutils just needs to be 
deprecated. Otherwise, I keep my opinion.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10957] Python FAQ grammar error

[Jerry Seutter]

New submission from Jerry Seutter :

Section 4.1 of the Python FAQ (http://www.python.org/dev/faq/) contains a 
grammar error:

The sentence I am referring to says: "If you are developing on OS X for Python 
2.x and will not be working with the OS X-specific modules from the standard 
library, then consider using the --without-toolbox-glue flag to faster 
compilation time."

How about instead: "If you are developing on OS X for Python 2.x and will not 
be working with the OS X-specific modules from the standard library, then 
consider using the --without-toolbox-glue flag for a faster compile."

(Note: Taken from the FAQ as of Jan 20, 2011)

--
assignee: docs@python
components: Documentation
keywords: easy
messages: 126626
nosy: docs@python, jerry.seutter
priority: normal
severity: normal
status: open
title: Python FAQ grammar error
versions: Python 3.2

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10955] Possible regression with stdlib in zipfile

[STINNER Victor]

STINNER Victor  added the comment:

The regression was introduced in r85690: use the correct encoding to decode the 
filename from the ZIP file. Attached patch fixes the bootstrap issue.

--
keywords: +patch
Added file: http://bugs.python.org/file20465/issue10955.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10958] stat.S_ISLNK() does not wok!

[Марк Коренберг]

New submission from Марк Коренберг :

ipython session:

In [48]: qwe=os.stat('/usr/lib/libstdc++.so.6')
In [49]: qwe.st_mode
Out[49]: 33188
In [50]: stat.S_ISLNK(qwe.st_mode)
Out[50]: False
In [51]: stat.S_IFLNK & qwe.st_mode
Out[51]: 32768

'/usr/lib/libstdc++.so.6' is really symlink !!!

python in ubuntu 10.10 and RHEL 6.0. All the same.

--
components: Library (Lib)
messages: 126628
nosy: mmarkk
priority: normal
severity: normal
status: open
title: stat.S_ISLNK() does not wok!
type: behavior

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10959] mmap crash

[Ross Lagerwall]

New submission from Ross Lagerwall :

The fix for issue10916 commited in r88022 introduces this line:

map_size = st.st_size - offset;

If offset > st.st_size, map_size is negative. This should cause the mmap system 
call to return -1 and set errno.

However, given a certain size of offset, since map_size is unsigned it will 
give a very large map_size and access the resultant mmap object results in a 
bus error crash. It also gives bogus len(mmap) values.

Eg (crashes on a 32bit system):
import os, mmap

with open("/tmp/rnd", "wb") as f:
f.write(b"X" * 115699)

with open("/tmp/rnd", "w+b") as f:
with mmap.mmap(f.fileno(), 0, offset=2147479552) as m:
print(len(m))
for i in m:
print(m[i])

Attached is a patch which should fix this issue by raising a value error if 
offset > st.st_size.

--
files: mmap_issue.patch
keywords: patch
messages: 126629
nosy: amaury.forgeotdarc, pitrou, rosslagerwall
priority: normal
severity: normal
status: open
title: mmap crash
type: crash
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file20466/mmap_issue.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10958] stat.S_ISLNK() does not wok!

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

os.stat() follows symbolic links. You probably want to use os.lstat() instead: 
http://docs.python.org/library/os.html#os.lstat

--
nosy: +amaury.forgeotdarc
resolution:  -> invalid
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10960] os.stat() does not mention that it follow symlinks by default

[Марк Коренберг]

New submission from Марк Коренберг :

Documentation should say about 'following symlink' in this function. 
Documentation should advice to use os.lstat() in case when it needed.

--
assignee: docs@python
components: Documentation
messages: 126631
nosy: docs@python, mmarkk
priority: normal
severity: normal
status: open
title: os.stat() does not mention that it follow symlinks by default
type: behavior

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10952] Don't normalize module names to NFKC?

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

On Thu, Jan 20, 2011 at 8:06 AM, STINNER Victor  wrote:
..
>> There is also issue c) what if the filesystem encoding can only
>> represent a compatibility character, say U+00B5, but not its NFKC
>> equivalent, U+03BC?
>
> It is the same problem than not being able to write U+03BC with a keyboard:

No.  This is a different problem and I agree with Martin that keyboard
limitations are not an issue.  With proper tools one can create
'\u03BCTorrent.py" file even if the keyboard does not have a '\u03BC'
key as long as the filesystem is capable of storing such file.  Python
itself is one such tool:

>>> with open('\u03BCTorrent.py'.encode(fsencoding), 'w') as f: ...

However, if fsencoding = 'latin-1', the code above will fail.

One possible solution to this problem is to define a 'compat' error
handler that would detect unencodable strings with encodable
compatibility equivalents and produce encoding of an NFKC equivalent
string instead of raising an error.  ISTM, that in the Latin-1
encoding, there are only five affected characters:

... dec = decomposition(chr(i))
... if dec and dec.startswith(''):
...print("U+00%02X '%s' (%s): %s" %(i, chr(i), name(chr(i)), dec))
...
U+00A8 '¨' (DIAERESIS):  0020 0308
U+00AF '¯' (MACRON):  0020 0304
U+00B4 '´' (ACUTE ACCENT):  0020 0301
U+00B5 'µ' (MICRO SIGN):  03BC
U+00B8 '¸' (CEDILLA):  0020 0327

I suspect that the number of affected characters in the other
encodings is similarly small.  If we further limit special handling to
characters that are valid in identifiers, U+00B5 will end up being the
only such character in Latin-1.

An import mechanism using encode(fsencoding, 'compat') will, when
given either "import \u00B5Torrent" or  "import \u03BCTorrent" in
source file, open  "\u03BCTorrent.py" when fsencoding='utf-8'  and
"\u00B5Torrent.py" if fsencoding='latin-1'.   A packaging mechanism
that prepares code developed on a Latin-1 filesystem for distribution,
would have to NFKC-normalize filenames before encoding them using
UTF-8.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10961] Pydoc touchups in new browser for 3.2

[Ron Adam]

New submission from Ron Adam :

A collection of small fix's that only effect the new browser mode.

* Change title of html pages from "Python ..." to "PyDoc ...".

* Fixed unterminated div float for items returned without a header.
 example: str, None, True, False

* Added "topic?key=..." url command to explicitly get topics.  This is to avoid 
the shadowing when an object has the same name as a topic.

* Nicer parsing and error handling in the url handler.

--
components: Library (Lib)
files: pydoc_misc_fix.diff
keywords: patch
messages: 126633
nosy: georg.brandl, ron_adam
priority: normal
severity: normal
status: open
title: Pydoc touchups in new browser for 3.2
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file20467/pydoc_misc_fix.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10961] Pydoc touchups in new browser for 3.2

[Ron Adam]

Ron Adam  added the comment:

new patch...

Adjusted a comment in the _gettopic method.

Everything else the same.

--
Added file: http://bugs.python.org/file20468/pydoc_misc_fix.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10961] Pydoc touchups in new browser for 3.2

[Ron Adam]

Changes by Ron Adam :


Removed file: http://bugs.python.org/file20467/pydoc_misc_fix.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10955] Possible regression with stdlib in zipfile

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

About the patch: """Break out of this dependency by assuming that the path to 
the encodings module is ASCII-only."""

The 'path' here is the entry inside the zip file (and does not include the 
location of the zip file itself), so the comment is right as long as the Python 
stdlib only contains ascii names.

But if the zip file contains the stdlib *and* some other custom modules with 
cp437 names, the whole operation will fail; it can be the case with py2exe 
applications.

--
nosy: +amaury.forgeotdarc

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10935] wsgiref.handlers.BaseHandler and subclasses of str

[Phillip J. Eby]

Phillip J. Eby  added the comment:

PyString_AsString() only "works on subclasses" if their internal representation 
is the same as type str.  So we can't say "subclass of str" without *also* 
specifying that the subclass store its contents in exactly the same way as an 
object of type str...  which means all we've really done is to make the 
specification longer and more complicated.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10935] wsgiref.handlers.BaseHandler and subclasses of str

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> PyString_AsString() only "works on subclasses" if their internal
> representation is the same as type str.  So we can't say "subclass of
> str" without *also* specifying that the subclass store its contents in
> exactly the same way as an object of type str...

There's no point in subclassing str if you're using a different
representation. You're not only wasting space, but some things will
behave badly (precisely because of lot of C functions will call
PyString_Check() and then PyString_AsString()).
So, what you call a limitation isn't really one.

> which means all we've really done is to make the specification longer
> and more complicated

That doesn't follow from the above.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10812] Add some posix functions

[Ned Deily]

Changes by Ned Deily :


--
nosy: +ned.deily

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10953] safely eval serialized dict/list data from arbitrary string over web with no side effects

[Skip Montanaro]

Skip Montanaro  added the comment:

If you intend this to be "safe" in the security sense of the word, I
suggest you release it in PyPI and post a note on comp.lang.python
(a.k.a. python-l...@python.org) asking people to try and break it.

--
nosy: +skip.montanaro

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10962] gdb support broken

[Antoine Pitrou]

New submission from Antoine Pitrou :

This happens when I try to debug a Python process (py3k HEAD in pydebug mode):

Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/python-gdb.py", line 52, in 
_type_size_t = gdb.lookup_type('size_t')
RuntimeError: No type named size_t.

--
assignee: dmalcolm
components: Demos and Tools
messages: 126639
nosy: dmalcolm, georg.brandl, pitrou
priority: critical
severity: normal
status: open
title: gdb support broken
type: behavior
versions: Python 3.2

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10962] gdb support broken

[Antoine Pitrou]

Antoine Pitrou  added the comment:

$ gdb --version
GNU gdb (GDB) 7.1-1mdv2010.1 (Mandriva Linux release 2010.1)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10962] gdb support broken

[Antoine Pitrou]

Antoine Pitrou  added the comment:

And bizarrely, test_gdb runs fine.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10962] gdb support broken

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Er, for some reason it seems to have just stopped happening.

--
resolution:  -> works for me
status: open -> pending

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10962] gdb support broken

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
status: pending -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10963] "subprocess" can raise OSError (EPIPE) when communicating with short-lived processes

[Dave Malcolm]

New submission from Dave Malcolm :

If we start a short-lived process which finishes before we begin communicating 
with it (e.g. by crashing), we can receive a SIGPIPE due to the receiving 
process no longer existing.  This becomes an EPIPE, which becomes an:
  OSError: [Errno 32] Broken pipe

Arguably this is a bug; if the subprocess could crash, the user currently has 
to check for it by both monitoring the returncode _and_ catching OSError (then 
examining for this specific errno), which seems ugly to me.

I'm attaching a patch for subprocess which handles this case, masking the 
OSError within the Popen implementation, so that you have to test for it within 
the returncode, in one place, rather than wrap every call with a try/except.

It could be argued that this is incorrect, as it masks under-reads of stdin by 
the subprocess.  However I believe a sanely-written subprocess ought to 
indicate success/failure back with its return code.

This was originally filed downstream within the Red Hat bugzilla instance as:
  https://bugzilla.redhat.com/show_bug.cgi?id=667431

The handler part of the patch is based on a patch attached there by Federico 
Simoncelli; I don't know if he has signed a PSF contributor agreement, however 
the size of the patch is sufficiently small that I suspect it's not 
copyrightable, and I've somewhat rewritten it since; I wrote the unit test.

--
components: Library (Lib)
files: py3k-handle-EPIPE-for-short-lived-subprocesses-2011-01-20-001.patch
keywords: patch
messages: 126643
nosy: dmalcolm
priority: normal
severity: normal
stage: patch review
status: open
title: "subprocess" can raise OSError (EPIPE) when communicating with 
short-lived processes
versions: Python 3.3
Added file: 
http://bugs.python.org/file20469/py3k-handle-EPIPE-for-short-lived-subprocesses-2011-01-20-001.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10963] "subprocess" can raise OSError (EPIPE) when communicating with short-lived processes

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> It could be argued that this is incorrect, as it masks under-reads of
> stdin by the subprocess.  However I believe a sanely-written subprocess 
> ought to indicate success/failure back with its return code.

It seems quite orthogonal. The subprocess could have terminated successfully 
while not all of the stdin bytes were consumed; EPIPE informs you of the latter.

--
nosy: +pitrou

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10959] mmap crash

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +georg.brandl
stage:  -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10959] mmap crash

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Here is an updated patch which also caters to the Windows side of things.

--
Added file: http://bugs.python.org/file20470/mmap_10959.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10845] test_multiprocessing failure under Windows

[Brett Cannon]

Changes by Brett Cannon :


--
priority: normal -> critical

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10959] mmap crash

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Fixed in r88131 (3.2), r88132 (3.1) and r88133 (2.7). Thank you!

--
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4761] create Python wrappers for openat() and others

[Giampaolo Rodola']

Changes by Giampaolo Rodola' :


--
nosy: +giampaolo.rodola

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4819] Misc/cheatsheet needs updating

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

Misc/cheatsheet has been removed in r88127.  Should this be closed?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4819] Misc/cheatsheet needs updating

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Well, perhaps Marc-André wants to revive it. Otherwise, suggest closing indeed.

--
assignee: docs@python -> 
nosy: +lemburg
stage:  -> needs patch
status: open -> pending

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4819] Misc/cheatsheet needs updating

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Updating the cheat sheet would be a great summer of code like project. We are 
considering using the cheat sheet as basis for a flyer in the PSF marketing 
material project.

Please add it back and add a note to it, that it currently is missing a few 
language features (e.g. add Alexanders list to it).

Thanks.

--
status: pending -> open

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10238] ctypes not building under OS X 10.6 with LLVM/Clang 2.8

[Brett Cannon]

Brett Cannon  added the comment:

Filed a bug with LLVM/Clang: http://llvm.org/bugs/show_bug.cgi?id=9014

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4819] Misc/cheatsheet needs updating

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Updating the cheat sheet would be a great summer of code like project.
> We are considering using the cheat sheet as basis for a flyer in the
> PSF marketing material project.

IMO it's not only about updating. It's about converting it to some
proper markup format, and being able to generate nicely laid out
versions of it. See examples of nice non-Python cheat sheets:
http://javascript-reference.info/
http://www.gscottolson.com/weblog/2008/01/11/jquery-cheat-sheet/

By the way the Python 3 transition means that it not only misses some
features, but probably has lots of bogus constructs and examples, so
putting it back as-is would do users a disservice.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10887] Add link to development ML

[anatoly techtonik]

anatoly techtonik  added the comment:

Link on group description page to FOTP project site. I thought that 
https://bitbucket.org/tarek/distutils2/wiki/Home is that site.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10906] wsgiref should mention that CGI scripts usually expect HTTPS variable to be set to 'on'

[anatoly techtonik]

anatoly techtonik  added the comment:

The problem that most scripts check for 'on', and not for '1'.

http://www.cgi101.com/book/ch3/text.html

More than that - I don't know any servers that set this to '1', except 
mod_wsgi, and perhaps other implementations that follow this wsgiref. mod_wsgi 
even changes value of Apache2 environment to '1'

For existing CGI scripts (that rely on HTTPS parameter being 'on') and that are 
ported to WSGI, this creates additional issues with HTTPS, and wastes people 
time.

--
status: closed -> open

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10955] Possible regression with stdlib in zipfile

[STINNER Victor]

STINNER Victor  added the comment:

Le jeudi 20 janvier 2011 à 18:15 +, Amaury Forgeot d'Arc a écrit :
> But if the zip file contains the stdlib *and* some other custom
> modules with cp437 names, the whole operation will fail; it can be the
> case with py2exe applications.

The ASCII fallback is only used before the codec registry is loaded. I
suppose that you can use non-ASCII module names in the same ZIP file: if
you load them after that the codec registry is ready, it should work.

I copied the fix from Objects/unicodeobject.c which has also a similar
bootstrap "hack" to encode/decode filenames.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10906] wsgiref should mention that CGI scripts usually expect HTTPS variable to be set to 'on'

[Graham Dumpleton]

Graham Dumpleton  added the comment:

As has been pointed out to you already in other forums, the correct way of 
detecting in a compliant WSGI application that a SSL connection was used is to 
check the value of the wsgi.url_scheme variable. If your code does not do this 
then it is not a compliant WSGI application and you have no guarantee that it 
will work portably across different WSGI hosting mechanisms. This is because a 
WSGI server/adapter is not obligated to set the HTTPS variable in the WSGI 
environment dictionary.

So, the correct thing to do, which for some reasons you don't want to, is to 
fix your code when it is being ported to adhere to the WSGI specification and 
what it dictates as the way of detecting a SSL connection.

FWIW, the HTTPS variable will no longer be set from mod_wsgi version 4.0 to 
enforce the point that it is not the correct way of detecting that an SSL 
connection and that wsgi.url_scheme should be used. The HTTPS variable was only 
being set at all and with that value because older versions of Django weren't 
doing what you also refuse to do, which is check for wsgi.url_scheme instead of 
the HTTPS variable. Django did the right thing and fixed their code to be 
compliant. Why you can't and want to keep arguing this point in three different 
forums is beyond me. You have spent way much more time arguing the point than 
it would take to fix your code to be compliant.

--
nosy: +grahamd

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10952] Don't normalize module names to NFKC?

[STINNER Victor]

STINNER Victor  added the comment:

> A packaging mechanism that prepares code developed on a Latin-1
> filesystem for distribution, would have to NFKC-normalize 
> filenames before encoding them using UTF-8.

It causes portability issues: if you copy a non-ASCII module on a new
host, the program will work or not depending on the filesystem encoding.
Having to transform the filename when you copy a file, just to fix a
corner case, is a pain.

> One possible solution to this problem is to define a 'compat' error
> handler that would detect unencodable strings with encodable
> compatibility equivalents and produce encoding of an NFKC equivalent
> string instead of raising an error.

Only few people use non-ASCII module names and most operating systems
are able to store all Unicode characters, so I don't think that we need
to support U+00B5 in a module name with Latin1 filesystem at all. If you
use an old system using Latin1 filesystem, you have to limit your
expectation on Python unicode support :-)

os.fsencode() and os.fsdecode() already use a custom error handler:
surrogateescape. compat will conflict with surrogateescape. Loading a
module concatenates two parts: a path from sys.path (decoded from the
filesystem encoding and surrogateescape error handler) and a module
name. If custom is used to encode the filename, the module name will be
encoded correctly, but not the path.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8797] urllib2 basicauth broken in 2.6.5: RuntimeError: maximum recursion depth exceeded in cmp

[Sam Bull]

Sam Bull  added the comment:

I think there's a much simpler solution to this ticket than the retry logic 
that's currently in place.

The code originally avoided the infinite recursion by checking to see if the 
previous request had already submitted the auth credentials that would be used 
in the retry. If it had, it would return None. If it hadn't, it would add the 
auth credentials to the request header and the request again:

if req.headers.get(self.auth_header, None) == auth:
return None
req.add_header(self.auth_header, auth)

Then, to fix #3819, it was changed. Instead of calling add_header, it called 
add_unredirected_header:

if req.headers.get(self.auth_header, None) == auth:
return None
req.add_unredirected_header(self.auth_header, auth)

This caused the loop because the auth creds were going into unredirected_hdrs 
instead of the headers dict.

But I think the original logic is sound. The code just wasn't checking in all 
the headers. Luckily there's a get_header method that checks both for you. This 
one-line change should fix the issue:


if req.get_header(self.auth_header, None) == auth:
return None
req.add_unredirected_header(self.auth_header, auth)

I think this fix is cleaner and makes more sense, but I'm worried I might be 
missing something. I don't fully understand the distinction between headers and 
unredirected headers. Maybe there's a reason why the code isn't checking in 
unredirected headers for the auth header.

I'm attaching a patch. I'm new to contributing to python so I apologize if the 
format is wrong.

--
nosy: +sambull
versions: +Python 2.7
Added file: http://bugs.python.org/file20471/simpler_fix.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10238] ctypes not building under OS X 10.6 with LLVM/Clang 2.8

[Brett Cannon]

Brett Cannon  added the comment:

Chris Lattner from LLVM says that this has been fixed in their mainline and 
that to work around it in LLVM 2.8 one should build with the -no-integrated-as 
flag.

--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4819] Misc/cheatsheet needs updating

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Perhaps the cheatsheet can be transferred to a wiki page and we can put out a 
comp.lang.python call for updates.

Also, +1 on the summer of code idea.

--
nosy: +rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3341] "Suggest a change" link

[anatoly techtonik]

anatoly techtonik  added the comment:

Still actual, esp. with this - 
http://google-opensource.blogspot.com/2011/01/make-quick-fixes-quicker-on-google.html
 and this http://codemirror.net/

--
status: closed -> open

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10964] Mac installer need not add things to /usr/local

[Russell Owen]

New submission from Russell Owen :

The Mac installer alters the user's $PATH to put 
/Library/Frameworks/Python.Framework/Versions/Current/bin on the $PATH before 
/usr/local/bin and /usr/bin. This is a good idea in my opinion.

But the installer *also* installs numerous symlinks in /usr/local/bin. These 
symlinks are redundant with altering the $PATH. Thus they are redundant. They 
are also make it difficult to switch versions of python because it's tricky to 
know which symlinks should be deleted (and the list may depend on the current 
version of python).

This is problem for me because I often have to switch versions of Python while 
building binary installers for packages such as matplotlib.

My request is for the Mac python installer to leave /usr/local/bin alone.

For if there is a need to add symlinks to /usr/local/bin that I'm not seeing 
then my request is for an easy way to switch versions of python or at least get 
rid of the symlinks, e.g. a python version switcher script or symlink deletion 
script.

--
assignee: ronaldoussoren
components: Macintosh
messages: 126661
nosy: reowen, ronaldoussoren
priority: normal
severity: normal
status: open
title: Mac installer need not add things to /usr/local
type: feature request
versions: Python 2.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10965] dev task of documenting undocumented APIs

[Brett Cannon]

New submission from Brett Cannon :

Once the docs are built using Python 3, then the coverage results can be used 
by people wanting to contribute as something to do. Should also mention in the 
task that some APIs should probably be private: 
http://mail.python.org/pipermail/python-dev/2010-November/105476.html .

--
assignee: brett.cannon
components: Documentation
messages: 126662
nosy: brett.cannon
priority: low
severity: normal
stage: needs patch
status: open
title: dev task of documenting undocumented APIs
type: feature request
versions: Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10965] dev task of documenting undocumented APIs

[Brett Cannon]

Changes by Brett Cannon :


--
dependencies: +Build 3.x documentation using python3.x

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10966] eliminate use of ImportError implicitly representing TestSkipped

[Brett Cannon]

New submission from Brett Cannon :

test.regrtest considers an ImportError to be a test to skip. It then uses this 
info to decide what skipped tests were expected (or not) based on a list kepted 
in regrtest.py.

For detecting compiler failures, an ImportError should be a test error or 
failure. Tests for optional modules should instead raise TestSkipped directly 
if an import fails. Something like test.support.optional_import() should be 
created which raises TestSkipped if the requested module could not be imported. 
It could also be made optional based on the OS (not sure if it should be 
inclusive, exclusive, or either). That way the list of expected skips in 
regrtest.py can be moved into the individual test modules where it belongs.

--
components: Tests
messages: 126663
nosy: brett.cannon
priority: normal
severity: normal
stage: needs patch
status: open
title: eliminate use of ImportError implicitly representing TestSkipped
versions: Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10966] eliminate use of ImportError implicitly representing TestSkipped

[Brett Cannon]

Brett Cannon  added the comment:

Once the proper function in test.support comes about then a dev task to help 
move everything over can be created. And then once all needed test modules have 
been switched over the ImportError try/except statement in regrtest can be 
removed.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10967] move regrtest over to using more unittest infrastructure

[Brett Cannon]

New submission from Brett Cannon :

test.regrtest is rather old and has not been updated to take advantage of all 
the latest features in unittest (e.g., test discovery). It might be a rather 
large undertaking with various bits requiring some changes (e.g., getting away 
from raising exceptions for skipped tests and instead using unittest.skipIf), 
but for maintainability it might be good to try to use as much unittest code in 
regrtest as possible.

--
components: Tests
messages: 126665
nosy: brett.cannon
priority: low
severity: normal
stage: unit test needed
status: open
title: move regrtest over to using more unittest infrastructure
type: feature request
versions: Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10952] Don't normalize module names to NFKC?

[Martin v . Löwis]

Martin v. Löwis  added the comment:

> There is also issue c) what if the filesystem encoding can only
> represent a compatibility character, say U+00B5, but not its NFKC
> equivalent, U+03BC?

That should be considered as similar to file systems that just cannot
represent certain characters at all - e.g. many of the non-ASCII
characters, or no upper-case letters. If you have such a file system,
you just cannot use these characters in a module name. Rename your
modules, then, or put the modules in a zipfile (or use some other
import hook).

> However, this code will always fail because '\xB5Torrent' will be
> normalized into '\u03BCTorrent' and a file named '\u03BCTorrent.py'
> cannot be created on a filesystem with Latin-1 encoding.

Tough luck. The filesystem just doesn't support GREEK SMALL LETTER MU,
just as it doesn't support all the other greek characters.

It may be fun coming up with these border cases. But I really don't
see a need to support them. If you really need to have that letter
in a module name, reformat your disk with a better file system.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10238] ctypes not building under OS X 10.6 with LLVM/Clang 2.8

[Brett Cannon]

Brett Cannon  added the comment:

I have verified that if you add -no-integrated-as as a flag (e.g., through 
CFLAGS) then ctypes will build.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10956] file.write and file.read don't handle EINTR

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Here is a patch for Python 3.2+.

--
keywords: +patch
nosy: +amaury.forgeotdarc
stage:  -> patch review
Added file: http://bugs.python.org/file20472/eintr_io.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10952] Don't normalize module names to NFKC?

[Martin v . Löwis]

Martin v. Löwis  added the comment:

> Only Mac OS X and the HFS+ filesystem normalize filenames (to a variant
> of NFD). But such normalization is a good thing! I mean that I don't
> think that we have anything to do for that.

That may well be - I don't have a case where this would cause problems,
either.

> We should at least document this surprising behaviour in the import
> documentation.

There are also are better ways to support the user than mere
documentation. For example,, the exception message could be more
helpful, and IDLE could warn the user when saving the file in the
first place.

> << WARNING: Non-ASCII characters in module names are normalized to NFKC
> by the Python parser ([PEP 3131]). For example, import µTorrent (µ: U
> +00B5) is normalized to import μTorrent (μ: U+03BC): Python will try to
> open "\u03BCTorrent.py" (or "\u03BCTorrent/__init__.py"), and not
> "\xB5Torrent.py" (or "\xB5Torrent/__init__.py"). >>

I can't believe this is a real problem. I'd defer warning about made-up
problems until real users report them as a real problem.

> I disagree.

If you disagree strongly, please write a PEP.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10961] Pydoc touchups in new browser for 3.2

[Ron Adam]

Ron Adam  added the comment:

A few last minute changes.. I think this will be all.

Run topic contents through html.markup.  That makes ref:, pep:, and html: links 
if they exist.  (I meant to this earlier.)

Fix case where topic reference links are to objects rather than another topic.  
(applies to keywords also.)

Skips making an empty reference section if there are no references with a topic.

These are all small changes, and nothing should be controversial in this as 
everything changed only effects the new html browser mode.

--
Added file: http://bugs.python.org/file20473/pydoc_misc_fix_c.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10961] Pydoc touchups in new browser for 3.2

[Ron Adam]

Changes by Ron Adam :


Removed file: http://bugs.python.org/file20468/pydoc_misc_fix.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10961] Pydoc touchups in new browser for 3.2

[Ron Adam]

Changes by Ron Adam :


--
nosy: +eric.araujo, rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4819] Misc/cheatsheet needs updating

[Ezio Melotti]

Ezio Melotti  added the comment:

I agree that it would be nice to have a cheatsheet somewhere, possibly in the 
official doc and not as a plain txt file in Misc/.
FWIW another cheatsheet updated to 2.6 can be found here: 
http://rgruet.free.fr/PQR26/PQR2.6.html

--
keywords: +gsoc
nosy: +ezio.melotti
type:  -> feature request

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3080] Full unicode import system

[STINNER Victor]

STINNER Victor  added the comment:

Version 4 of the patch.

--
Added file: http://bugs.python.org/file20474/issue3080-4.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3080] Full unicode import system

[STINNER Victor]

Changes by STINNER Victor :


Removed file: http://bugs.python.org/file20448/issue3080-3.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3080] Full unicode import system

[STINNER Victor]

STINNER Victor  added the comment:

Same patch (version 4) generated by svn.

--
Added file: http://bugs.python.org/file20475/issue3080-4-svn.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9723] pipes.quote() needs to be documented

[Matt Joiner]

Matt Joiner  added the comment:

I agree, I discovered this function (pipes.quote) only through recommendation 
here:

http://stackoverflow.com/questions/4748344/whats-the-reverse-of-shlex-split

I suggest that it be added to shlex, perhaps as shlex.quote. While the quoting 
style it performs, and the module it's found in are specific to Unix tools, the 
shlex module is available on non-Unix platforms. To this end, adding the 
function to shlex would make it available elsewhere, as well as be 
appropriately shell-related.

--
nosy: +anacrolix

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4819] Misc/cheatsheet needs updating

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

FWIW, I updated the first couple of pages.  If anyone finds my changes useful, 
here they are in issue4819.diff.

--
keywords: +patch
Added file: http://bugs.python.org/file20476/issue4819.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3080] Full unicode import system

[STINNER Victor]

STINNER Victor  added the comment:

You can review the patch with Rietveld:
http://codereview.appspot.com/3972045

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10968] Timer class inheritance issue

[Benjamin VENELLE]

Changes by Benjamin VENELLE :


--
assignee: collinwinter
components: Benchmarks
nosy: Kain94, collinwinter
priority: normal
severity: normal
status: open
title: Timer class inheritance issue
type: behavior

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10968] Timer class inheritance issue

[Benjamin VENELLE]

New submission from Benjamin VENELLE :

Hi,

Due to Timer's object creation behavior, it is impossible to subclass it. This 
kind of declaration will result to an exception raising:

class A(Timer): pass

--
components: +Library (Lib) -Benchmarks
versions: +Python 3.1

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com