On Tue, Sep 30, 2008 at 12:22 AM, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Victor Stinner schrieb:
>> Le Monday 29 September 2008 18:45:28 Georg Brandl, vous avez écrit :
>>> If I had to choose, I'd still argue for the modified UTF-8 as filesystem
>>> encoding (if it were UTF-8 otherwise), despite
> Change the default file system encoding to store bytes in Unicode is like
> introducing a new Python type: .
Exactly. Seems like the best solution to me, despite your polemics.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http:/
Le Monday 29 September 2008 19:06:01 Guido van Rossum, vous avez écrit :
I know I keep flipflopping on this one, but the more I think about it
the more I believe it is better to drop those names than to raise an
exception. Otherwise a "naive" program that happens to use
os.listdir() can be re
On Mon, Sep 29, 2008 at 5:47 PM, Victor Stinner
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> See attached patch: python3_bytes_filename.patch
>
Patches should go on the tracker, not the mailing list. Otherwise it
will just get lost.
-Brett
___
Python-Dev mailin
Guido van Rossum writes:
> On Mon, Sep 29, 2008 at 4:29 PM, Victor Stinner
> <[EMAIL PROTECTED]> wrote:
> > It would be hard for a newbie programmer to understand why he's
> > unable to find his very important file ("important r?port.doc")
> > using os.listdir().
> *Every* failure in this s
FWIW: I didn't have much luck translating segfaults into exceptions. It
(seemed) to work on
some platforms, but not others; this was in the context of C++.
In my experience, it is more useful to generate Python and C stack traces and
bail out.
I also do this for floating-point exceptions. The han
Greg Ewing writes:
> Ulrich Eckhardt wrote:
>
> > AFAIK, OS X guarantees UTF-8 for filesystem encodings. So the OS
> > also provides Unicode filenames and how it deals with broken or
> > legacy media is left up to the OS.
>
> Does this mean that the OS always returns valid utf-8 strings
>
Hi,
See attached patch: python3_bytes_filename.patch
Using the patch, you will get:
- open() support bytes
- listdir(unicode) -> only unicode, *skip* invalid filenames
(as asked by Guido)
- remove os.getcwdu()
- create os.getcwdb() -> bytes
- glob.glob() support bytes
- fnmatch.filter()
Le Tuesday 30 September 2008 01:31:45 Adam Olsen, vous avez écrit :
> The alternative is not be valid unicode, but since we can't use such
> objects with external libs, can't even print them, we might as well
> call them something else. We already have a name for that: bytes.
:-)
__
On Mon, Sep 29, 2008 at 5:29 PM, Victor Stinner
<[EMAIL PROTECTED]> wrote:
> Le Monday 29 September 2008 19:06:01 Guido van Rossum, vous avez écrit :
>> >> - listdir(unicode) -> unicode and raise an error on invalid filename
>>
>> I know I keep flipflopping on this one, but the more I think about
> import os
> import os.path
> import sys
> if os.path.supports_unicode_filenames:
> cwd = getcwd()
> else:
> cwd = getcwdb()
> encoding = sys.getfilesystemencoding()
> for filename in os.listdir(cwd):
> if os.path.supports_unicode_filenames:
> text = str(fil
Le Monday 29 September 2008 18:45:28 Georg Brandl, vous avez écrit :
> If I had to choose, I'd still argue for the modified UTF-8 as filesystem
> encoding (if it were UTF-8 otherwise), despite possible surprises when a
> such-encoded filename escapes from Python.
If I understand correctly this sol
On Mon, Sep 29, 2008 at 4:29 PM, Victor Stinner
<[EMAIL PROTECTED]> wrote:
> Le Monday 29 September 2008 19:06:01 Guido van Rossum, vous avez écrit :
>> >> - listdir(unicode) -> unicode and raise an error on invalid filename
>>
>> I know I keep flipflopping on this one, but the more I think about
Ulrich Eckhardt wrote:
AFAIK, OS X guarantees UTF-8 for filesystem encodings. So the OS also provides
Unicode filenames and how it deals with broken or legacy media is left up to
the OS.
Does this mean that the OS always returns valid utf-8 strings
from filesystem calls, even if the media is
On Mon, Sep 29, 2008 at 4:49 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>> Originally I thought that this was a valid idea, but then it became
>> clear that this could be a problem. Consider a filename which includes
>> a UTF-8 encoding of a PUA code point.
>
> I still think it's a valid ide
Le Monday 29 September 2008 19:06:01 Guido van Rossum, vous avez écrit :
> >> - listdir(unicode) -> unicode and raise an error on invalid filename
>
> I know I keep flipflopping on this one, but the more I think about it
> the more I believe it is better to drop those names than to raise an
> exce
On Sat, Sep 27, 2008 at 8:32 AM, Victor Stinner
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> Would it possible to get more permissions on Python bugtracker, especially to
> add keywords, close a duplicate bug, etc.?
>
Let's start off with giving you Developer permissions on the tracker
to start and then y
Hi,
I would like to be able to catch SIGSEGV in my Python code! So I started to
hack Python trunk to support this feature. The idea is to use a signal
handler which call longjmp(), and add setjmp() at Py_EvalFrameEx() enter.
See attached ("small") patch: segfault.patch
Example read.py with the
> The default behaviour should be to use unicode and raise an error if
> conversion to unicode fails. It should also be possible to use bytes using
> bytes arguments and optional arguments (for getcwd).
I'm still opposed to allowing bytes as file names at all in 3k. Python
should really strive
Jack Jansen wrote:
> I'm a bit late to join in this discussion, but if unicode filenames are
> going to be the normal mode, how about this whole normalized/canonical
> business?
I don't think there is a change in the current implementation. Users
interested in this issue should contribute code tha
> Originally I thought that this was a valid idea, but then it became
> clear that this could be a problem. Consider a filename which includes
> a UTF-8 encoding of a PUA code point.
I still think it's a valid idea. For non-UTF-8 file system encodings,
use PUA characters, and generate them throug
Ulrich Eckhardt wrote:
>>> Well, currently it does make a difference. Simple example: CreateFile().
>> It's not so simple: Python doesn't actually call CreateFile
>
> Martin, CreateFile() was just used as an example. You can substitute it with
> LoadString() or CreateProcess() if you like, the pr
On Sep 29, 2008, at 6:17 PM, Adam Olsen wrote:
I suspect linux will eventually take this route as well. If ext3 had
an option for UTF-8 validation I know I'd want it on. That'd move the
error to the program creating bogus file names, rather than those
trying to read, display, and manage them.
On Mon, Sep 29, 2008 at 11:06 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 29, 2008 at 9:45 AM, Georg Brandl <[EMAIL PROTECTED]> wrote:
>
>> This approach (changing all path-handling functions to accept either bytes
>> or string, but not both) is doomed in my eyes. First, there are
On Mon, Sep 29, 2008 at 10:00 AM, Victor Stinner
<[EMAIL PROTECTED]> wrote:
> Le Monday 29 September 2008 17:16:47 Steven Bethard, vous avez écrit :
>> > - getcwd() -> unicode
>> > - getcwd(bytes=True) -> bytes
>>
>> Please let's not introduce boolean flags like this. How about
>> ``getcwdb`` in
Yeah, right. Let's continue there.
--- Giampaolo
http://code.google.com/p/pyftpdlib
On 29 Set, 22:44, "Josiah Carlson" <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 29, 2008 at 12:02 PM, Giampaolo Rodola' <[EMAIL PROTECTED]> wrote:
> > On 27 Set, 20:04, "Josiah Carlson" <[EMAIL PROTECTED]> wrote:
>
On Mon, Sep 29, 2008 at 12:02 PM, Giampaolo Rodola' <[EMAIL PROTECTED]> wrote:
> On 27 Set, 20:04, "Josiah Carlson" <[EMAIL PROTECTED]> wrote:
>> On Sat, Sep 27, 2008 at 8:54 AM, Victor Stinner
>>
>> <[EMAIL PROTECTED]> wrote:
>> > Second, I would like to help to fix all Python security issues. It
On 27 Set, 20:04, "Josiah Carlson" <[EMAIL PROTECTED]> wrote:
> On Sat, Sep 27, 2008 at 8:54 AM, Victor Stinner
>
> <[EMAIL PROTECTED]> wrote:
> > Second, I would like to help to fix all Python security issues. It looks
> > like
> > Python community isn't very reactive (proactive?) about securit
On Mon, Sep 29, 2008 at 7:12 AM, Michele Simionato
<[EMAIL PROTECTED]> wrote:
> I like Martin's proposals (use a function, remove -O) very much.
That's too bad, since I don't like it at all :-). You can write your
own function trivially that does this; however IMO the *language*
should support som
On Mon, Sep 29, 2008 at 5:11 AM, Jan Matejek <[EMAIL PROTECTED]> wrote:
> Brett Cannon napsal(a):
>> On Sat, Sep 27, 2008 at 8:54 AM, Victor Stinner
>> <[EMAIL PROTECTED]> wrote:
>>> First, I would like to access to these informations. Not only this issue,
>>> but
>>> all security related issues.
> Victor Stinner schrieb:
(Thanks Victor for moving this to the list. Having a discussion in the
tracker is really painful, I find.)
>> POSIX OS
>>
>>
>> The default behaviour should be to use unicode and raise an error if
>> conversion to unicode fails. It should also be possible to use
Ulrich Eckhardt schrieb:
> Hi!
>
> In trunk/PCbuild/readme.txt it says NASM is available from kernel.org. The
> project has moved to Sourceforge though, please replace the link with
>
> http://nasm.sf.net
Fixed in r66681. Thanks! (In the future, it might be better to open an issue
at bugs.pyt
On Sat, Sep 27, 2008 at 8:45 PM, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On Sat, Sep 27, 2008 at 8:54 AM, Victor Stinner
> <[EMAIL PROTECTED]> wrote:
>>
>> I would like to know if a Python security team does exist. I sent an email
>> about an imageop issue, and I didn't get any answer. Later I le
Le Monday 29 September 2008 17:16:47 Steven Bethard, vous avez écrit :
> > - getcwd() -> unicode
> > - getcwd(bytes=True) -> bytes
>
> Please let's not introduce boolean flags like this. How about
> ``getcwdb`` in parallel with the old ``getcwdu``?
Yeah, you're right. So i wrote a new patch: os_
On Mon, Sep 29, 2008 at 6:07 AM, Victor Stinner
<[EMAIL PROTECTED]> wrote:
> The default behaviour should be to use unicode and raise an error if
> conversion to unicode fails. It should also be possible to use bytes using
> bytes arguments and optional arguments (for getcwd).
>
> - listdir(unicod
Hi!
In trunk/PCbuild/readme.txt it says NASM is available from kernel.org. The
project has moved to Sourceforge though, please replace the link with
http://nasm.sf.net
Thanks!
Uli
--
Sator Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
***
I like Martin's proposals (use a function, remove -O) very much.
Actually I wanted
to propose the same months ago. Here is my take at the assert function, which
I would like to be able to raise even exceptions different from AssertionError:
def assert_(cond, exc, *args):
"""Raise an exception
On 11:59 am, [EMAIL PROTECTED] wrote:
Sorry, I wasn't clear enough. I'll try to explain further...
Let's assume we have a filename like this:
0xc2 0xa9 0x2f 0x7f
The first two bytes are the copyright sign encoded in UTF-8, followed
by a
slash (0x2f, path separator) and a character encoded i
Patches are already avaible in the issue #3187 (os.listdir):
Le Monday 29 September 2008 14:07:55 Victor Stinner, vous avez écrit :
> - listdir(unicode) -> unicode and raise an error on invalid filename
Need raise_decoding_errors.patch (don't clear Unicode error
> - listdir(bytes) -> bytes
Al
On Mon, 29 Sep 2008 14:34:07 +0200, Ulrich Eckhardt <[EMAIL PROTECTED]> wrote:
On Monday 29 September 2008, [EMAIL PROTECTED] wrote:
Also, what about MacOS X?
AFAIK, OS X guarantees UTF-8 for filesystem encodings. So the OS also provides
Unicode filenames and how it deals with broken or legacy
On Monday 29 September 2008, [EMAIL PROTECTED] wrote:
> Also, what about MacOS X?
AFAIK, OS X guarantees UTF-8 for filesystem encodings. So the OS also provides
Unicode filenames and how it deals with broken or legacy media is left up to
the OS.
Uli
--
Sator Laser GmbH
Geschäftsführer: Thors
I'm a bit late to join in this discussion, but if unicode filenames
are going to be the normal mode, how about this whole normalized/
canonical business?
This is a headache that has shown up on the Mac a couple of times,
because MacOS prefers filenames to be NFC, whereas Python prefers its
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brett Cannon napsal(a):
> On Sat, Sep 27, 2008 at 8:54 AM, Victor Stinner
> <[EMAIL PROTECTED]> wrote:
>> First, I would like to access to these informations. Not only this issue, but
>> all security related issues. I have some knowledges about securit
Le Monday 29 September 2008 06:43:55, vous avez écrit :
> It will make users happy, and it's simple enough to implement for
> python 3.0.
I dislike your argument. A "quick and dirty hack" is always faster to
implement than a real solution, but we may hits later new issues if we don't
choose the
Hi,
After reading the previous discussion, here is new proposition.
Python 2.x and Windows are not affected by this issue. Only Python3 on POSIX
(eg. Linux or *BSD) is affected.
Some system are broken, but Python have to be able to open/copy/move/remove
files with an "invalid filename".
The i
On Monday 29 September 2008, M.-A. Lemburg wrote:
> On 2008-09-29 12:50, Ulrich Eckhardt wrote:
> > 1. For POSIX platforms (using a byte string for the path):
> > Here, the first approach is to convert the path to Unicode, according to
> > the locale's CTYPE category. Hopefully, it will be UTF-8, b
Le Monday 29 September 2008 12:50:03 Ulrich Eckhardt, vous avez écrit :
> (...) uses an ASCII mapping where possible and codepoints from the
> "Private Use Area" (PUA) of Unicode for the non-decodable bytes.
That sounds to me like a very *ugly* hack.
It remembers me my proposition to create an o
On 10:50 am, [EMAIL PROTECTED] wrote:
On Sunday 28 September 2008, Gregory P. Smith wrote:
"broken" systems will always exist. Code to deal with them must be
possible to write in python 3.0.
since any given path (not just fs) can have its own encoding it makes
the most sense to me to let the
On 2008-09-29 12:50, Ulrich Eckhardt wrote:
> On Sunday 28 September 2008, Gregory P. Smith wrote:
>> "broken" systems will always exist. Code to deal with them must be
>> possible to write in python 3.0.
>>
>> since any given path (not just fs) can have its own encoding it makes
>> the most sense
On Sunday 28 September 2008, Gregory P. Smith wrote:
> "broken" systems will always exist. Code to deal with them must be
> possible to write in python 3.0.
>
> since any given path (not just fs) can have its own encoding it makes
> the most sense to me to let the OS deal with the errors and not t
* Gregory P. Smith <[EMAIL PROTECTED]> [2008-09-28 13:34:50 -0700]:
> since any given path (not just fs) can have its own encoding it makes
> the most sense to me to let the OS deal with the errors and not try to
> enforce bytes vs string encoding type at the python lib. level.
But the underlying
On Friday 26 September 2008, Martin v. Löwis wrote:
> >> Please don't. Whether or not _UNICODE is defined should have no effect.
> >
> > Well, currently it does make a difference. Simple example: CreateFile().
>
> It's not so simple: Python doesn't actually call CreateFile, AFAICT
> (well, it does,
52 matches
Mail list logo
