Re: [Python-Dev] Patch for an initial support of bytes filename in Python3

2008-10-01 Thread Simon Cross 
On Wed, Oct 1, 2008 at 12:05 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Actually on Windows the syscalls use the encoding that Microsoft uses
> -- when using bytes we use the Windows bytes API and when using str we
> use the Windows wide API. That's the most platform-compatible
> approach.

Woot. As long as the Python file API is consistent across the two
platforms, I'm happy. :)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-3000] New proposition for Python3 bytes filename issue

2008-10-01 Thread Ulrich Eckhardt 
On Tuesday 30 September 2008, M.-A. Lemburg wrote:
> On 2008-09-30 08:00, Martin v. Löwis wrote:
> >> 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.
>
> Not a bad idea... have os.listdir() return Unicode subclasses that work
> like file handles, ie. they have an extra buffer that holds the original
> bytes value received from the underlying C API.

Why does it have to be a Unicode subclass? In my eyes, a Unicode object 
promises a few things, in particular that it contains a Unicode string. If it 
now suddenly contains bytes without any further meaning, that would be bad.


What I wonder is what the requirements on path handling are. I'll try to list 
the ones I can see:

1. A path received from the system should be preserved, so it can be given to 
the system later on. IOW, the internal representation should not loose any 
information compared to the one used by the OS.

2. Typical operations like joining two path segments or moving to the parent 
dir should be defined.

3. There must be a way to display the path to the user. IOW, there should be a 
way to turn the path into a string that the user can recognise, according to 
some encoding. Note that this is not always possible, so this can fail.

4. There must be a way to receive a path from the user. That means that there 
must be a way from a user-entered string to a path. Note that this, too, 
isn't always possible and can fail.

5. The conversion between a string and a path should be configurable, defaults 
retrieved from the system. This is so that most operations will just work and 
do the thing that the user expects.

6. There should be a way to modify the path data itself. This of course 
requires knowledge about the internals but gives full power to the 
programmer.


For requirement 3, I would say a lossy conversion to a string would be enough, 
i.e. try to convert the path to a Unicode string and use a question mark or 
some escaping to mark parts that can't be decoded. It will allow users to 
recognise the decodeable parts of the path with hopefully just a few 
characters left without decoding.

For requirement 4, a failure to encode a string to a path must result in a 
loud failure, i.e. an exception. This is because the user entered a path that 
we can't use, any guessing what the user might have wanted is futile.


Are there any points to add?

Uli

-- 
Sator Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932

**
   Visit our website at 
**
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten 
bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen 
Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein 
sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, 
weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte 
Änderungen enthalten. Sator Laser GmbH ist für diese Folgen nicht 
verantwortlich.

**

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Patch for an initial support of bytes filename in Python3

2008-10-01 Thread Simon Cross 
On Wed, Oct 1, 2008 at 12:04 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Plus, even on Linux Unicode is *usually* what you should be doing,
> unless you're writing a backup tool.

I still find this line of reasoning a bit worrying. Imagine an end
user application like a music player. The user discovers that he can't
see some .mp3 or .ogg file from the music player that is visibile is
the file manager. I would expect him to file a bug on the music
player. If the bug was closed with "fix the filename" I imagine the
user would respond with "but other programs can access it just fine".

I'm not unhappy with the solution Victor is proposing, but I imagine
that when I start coding projects in 3.0 I'll default to the bytes
versions of the filename methods and use
b"path".decode(sys.getfilesystemencoding(), "replace") if I need to
get Unicode.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-3000] New proposition for Pyth on3 bytes filename issue

2008-10-01 Thread Victor Stinner 
Le Wednesday 01 October 2008 04:06:25 [EMAIL PROTECTED], vous avez écrit :
> b = gtk.Button(u"\u/hello/world")
>
> which emits this message:
> TypeError: OGtkButton.__init__() argument 1 must be string without
> null bytes or None, not unicode
>
> SQLite has a similar problem with NULLs, and I'm definitely sticking
> paths in there, too.

I think that you can say "all C libraries".

Would it possible to convert the encoded string to bytes just before call Gtk? 
(job done by some Python internals, not as an explicit conversion)

I don't know if it would help the discussion, but Java uses its own modified 
UTF-8 encoding:
 * NUL byte is encoded as 0xc0 0x80 instead of 0x00
 * Java doesn't support unicode > 0x (boh!)
http://java.sun.com/javase/6/docs/api/java/io/DataInput.html#modified-utf-8

-- 
Victor Stinner aka haypo
http://www.haypocalc.com/blog/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-3000] New proposition for Python3 bytes filename issue

2008-10-01 Thread M.-A. Lemburg 
On 2008-10-01 09:54, Ulrich Eckhardt wrote:
> On Tuesday 30 September 2008, M.-A. Lemburg wrote:
>> On 2008-09-30 08:00, Martin v. Löwis wrote:
 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.
>> Not a bad idea... have os.listdir() return Unicode subclasses that work
>> like file handles, ie. they have an extra buffer that holds the original
>> bytes value received from the underlying C API.
> 
> Why does it have to be a Unicode subclass? In my eyes, a Unicode object 
> promises a few things, in particular that it contains a Unicode string. If it 
> now suddenly contains bytes without any further meaning, that would be bad.

Please read my entire email. I was proposing to store the underlying
non-decodeable byte string value in such a subclass. The Unicode value
of the object would then be that underlying value decoded as e.g.
Latin-1 in order to be able to work on it as text.

Path operations would have to be made aware of such subclasses and
operate on the underlying bytes value.

However, like Guido mentioned, this only works if all components are
indeed aware of such subclasses... and that's likely to fail for
code outside the stdlib.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Oct 01 2008)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


 Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Patch for an initial support of bytes filename in Python3

2008-10-01 Thread Stephen J. Turnbull 
Simon Cross writes:

 > I still find this line of reasoning a bit worrying. Imagine an end
 > user application like a music player. The user discovers that he can't
 > see some .mp3 or .ogg file from the music player that is visibile is
 > the file manager. I would expect him to file a bug on the music
 > player. If the bug was closed with "fix the filename" I imagine the
 > user would respond with "but other programs can access it just fine".

And the user would very likely be *wrong*.  The file manager is
displaying it, but in the nature of things file managers *don't access
files*, they access *directories*.  The files they pass to other apps
to access.

That's precisely the kind of situation that Georg Brandl was
describing with OpenOffice.

 > I'm not unhappy with the solution Victor is proposing, but I imagine
 > that when I start coding projects in 3.0 I'll default to the bytes
 > versions of the filename methods and use
 > b"path".decode(sys.getfilesystemencoding(), "replace") if I need to
 > get Unicode.

But now the user will file a bug because in the file opening dialog
they can't *read* their Chinese file names on their USB key because
they are appearing in (system encoding) Cyrillic.  Do you begin to see
the nature of the Catch-22 here?

I don't expect the user to be very sympathetic when you tell her to
fix the filenames, but it's not as easy as you would think to get this
right.

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Patch for an initial support of bytes filename in Python3

2008-10-01 Thread Simon Cross 
On Wed, Oct 1, 2008 at 12:25 PM, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote:
> Simon Cross writes:
>
>  > I still find this line of reasoning a bit worrying. Imagine an end
>  > user application like a music player. The user discovers that he can't
>  > see some .mp3 or .ogg file from the music player that is visibile is
>  > the file manager. I would expect him to file a bug on the music
>  > player. If the bug was closed with "fix the filename" I imagine the
>  > user would respond with "but other programs can access it just fine".
>
> And the user would very likely be *wrong*.  The file manager is
> displaying it, but in the nature of things file managers *don't access
> files*, they access *directories*.  The files they pass to other apps
> to access.

Exactly the same reasoning applies to files in a directory with an odd name.

>  > I'm not unhappy with the solution Victor is proposing, but I imagine
>  > that when I start coding projects in 3.0 I'll default to the bytes
>  > versions of the filename methods and use
>  > b"path".decode(sys.getfilesystemencoding(), "replace") if I need to
>  > get Unicode.
>
> But now the user will file a bug because in the file opening dialog
> they can't *read* their Chinese file names on their USB key because
> they are appearing in (system encoding) Cyrillic.  Do you begin to see
> the nature of the Catch-22 here?
>
> I don't expect the user to be very sympathetic when you tell her to
> fix the filenames, but it's not as easy as you would think to get this
> right.

a) There is some chance that at least ASCII characters will be
displayed correctly if getfilesystemencoding() is similar to the
encoding used and corrupted filenames will display correctly except
for corrupted characters.

b) The user will at least be able to access the file.

It's a more graceful degredation of functionality than not being able
to work with the file at all.

Schiavo
Simon
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Python 2.6 final today

2008-10-01 Thread Barry Warsaw 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I've been out of town since Friday, but I don't yet see anything in  
the 700 billion email messages I'm now catching up on that leads me to  
think we need to delay the release.  Yay!


I will be on irc later today and will be trolling through the tracker  
and buildbots soon.  Don't trust email to get an important issue in  
front of me today, please use irc or submit a showstopper bug against  
2.6 if something /must/ be addressed before today's release.


I'm going to make a test release at around 1600UTC today, just to see  
how building the docs and such go.  I'm still planning on doing the  
final final release at about 2200UTC.  If you need to coordinate with  
me (e.g. press releases, Windows builds, etc.) please meeting me on  
#python-dev on irc.freenode.net.


- -Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSONrt3EjvBPtnXfVAQJn7wP9HSieFM7daE5vbvsuJGZtHyC2NFmT5Rsm
Fd/ce6CvLzGEkUQ5GQs09TtiZZbIYiObUNkbVQBV8Zbu7A9S3fx7PBpHmPOnIIbr
Dfw39pphdKE76yoJmC7OkFTlDbOw6rbuD+JLAzCgcjxx1MqL1Cx08vl2/WEJf3Fl
izAVTI2Bwwc=
=BCvf
-END PGP SIGNATURE-
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-3000] New proposition for Python3 bytes filename issue

2008-10-01 Thread Nick Coghlan 
[EMAIL PROTECTED] wrote:
> The reasoning is that a lot of software doesn't care if it's wrong for
> edge cases, it's really hard to come up with something that's correct
> with respect to all of those edge cases (absurdly difficult, if you need
> to stay in the straightjacket of string / bytes types, as well as
> provide a useful library interface - which is why we're having this
> discussion).  But, it should be _possible_ to write software that's
> correct in the face of those edge cases.

I just wanted to highlight this as something to keep in mind during this
discussion: we want to keep the easy things easy and make the difficult
things possible.

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://www.boredomandlaziness.org
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Determine minimum required version for a script

2008-10-01 Thread techtonik 
Can somebody remind how to check script compatibility with old Python versions?

I can remember PHP_CompatInfo class for PHP that parses a script or directory to
find out the minimum version and extensions required for them to run,
and I wonder
if there was anything like this for Python?

-- 
--anatoly t.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Patch for an initial support of bytes filename in Python3

2008-10-01 Thread Stephen J. Turnbull 
Simon Cross writes:

 > a) There is some chance that at least ASCII characters will be
 > displayed correctly if getfilesystemencoding() is similar to the
 > encoding used and corrupted filenames will display correctly except
 > for corrupted characters.

All you're saying is that the cases *you* can imagine running into
work better.  All I'm saying is the opposite.  We're both right; the
point is that that means that Python can't be, not all of the time.

We know from experience (Emacs/Mule, Java) that trying to impose a
theoretical system on encoding just doesn't work by itself[1], and in
fact creates other problems by its very rigidity.  I'd like to see
Python not fall into that trap, too.


Footnotes: 
[1]  It needs system-level support as in Windows and Mac OS X.

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Patch for an initial support of bytes filename in Python3

2008-10-01 Thread Guido van Rossum 
On Wed, Oct 1, 2008 at 1:05 AM, Simon Cross
<[EMAIL PROTECTED]> wrote:
> On Wed, Oct 1, 2008 at 12:04 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> Plus, even on Linux Unicode is *usually* what you should be doing,
>> unless you're writing a backup tool.
>
> I still find this line of reasoning a bit worrying. Imagine an end
> user application like a music player. The user discovers that he can't
> see some .mp3 or .ogg file from the music player that is visibile is
> the file manager. I would expect him to file a bug on the music
> player. If the bug was closed with "fix the filename" I imagine the
> user would respond with "but other programs can access it just fine".

I see nothing wrong with this scenario. If undecodable filenames are a
common thing then the authors of the music player should be using the
bytes variant of the API, and if they get enough bugs like this they
will fix their code to do so. OTOH if this is not common the response
"rename the file" is totally reasonable -- you have to prioritize your
bugs or else you'll never get any software released, and the
occasional work-around is a given.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Determine minimum required version for a script

2008-10-01 Thread Gerhard Häring 

techtonik wrote:

Can somebody remind how to check script compatibility with old Python versions?

I can remember PHP_CompatInfo class for PHP that parses a script or directory to
find out the minimum version and extensions required for them to run,
and I wonder
if there was anything like this for Python?


You posted on the *python-dev* mailing list.

On this list the key *Python developers* discuss the future of the 
language and its implementation. Topics include Python design issues, 
release mechanics, and maintenance of existing releases.


Please, do not post general Python questions to this list! For help with 
Python please use the mailing list [EMAIL PROTECTED] or the 
newsgroup comp.lang.python. Messages are routed between the two. so 
they're basically the same thing.


-- Gerhard
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-3000] New proposition for Python3 bytes filename issue

2008-10-01 Thread Bill Janssen 
M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> On 2008-10-01 09:54, Ulrich Eckhardt wrote:
> > On Tuesday 30 September 2008, M.-A. Lemburg wrote:
> >> On 2008-09-30 08:00, Martin v. Löwis wrote:
>  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.
> >> Not a bad idea... have os.listdir() return Unicode subclasses that work
> >> like file handles, ie. they have an extra buffer that holds the original
> >> bytes value received from the underlying C API.
> > 
> > Why does it have to be a Unicode subclass? In my eyes, a Unicode object 
> > promises a few things, in particular that it contains a Unicode string. If 
> > it 
> > now suddenly contains bytes without any further meaning, that would be bad.
> 
> Please read my entire email. I was proposing to store the underlying
> non-decodeable byte string value in such a subclass. The Unicode value
> of the object would then be that underlying value decoded as e.g.
> Latin-1 in order to be able to work on it as text.

I'm actually sort of liking this idea.  A Pathname class, for convenience
a subtype of String, but containing the underlying binary representation 
used by the OS.  Even non-unicode pathnames could be represented.

Bill
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python security team

2008-10-01 Thread Barry Warsaw 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sep 30, 2008, at 7:27 AM, Jan Mate(jek <[EMAIL PROTECTED]> Mate> wrote:



Thanks for your answer. I guess the process is the real problem then.
- From what i could observe, the connection between vendor-sec and  
PSRT is

not really working as it should.
(And then of course you need some kind of upstream flow too, because  
not

everyone reports to PSRT.)


Please remember that the proper way to contact the PSRT is via [EMAIL PROTECTED] 
.


FWIW, I am in favor of adding a few trusted people to the team, but  
only if they're willing to actually get stuff done :).  Clearly the  
current team is too swamped to act effectively, myself included.


- -Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSOOe3XEjvBPtnXfVAQJ5JgP/dDg+SPLeQ4yBQ/CYxJEh3/Xm2B+2KV5U
9RUjp7W7z2iC/Bz7qwJlui0Z30KaaZ/whMqTuh+5ZYDlrmUDUh9Tl88OyngHOBxy
R/SYmluOlYUPdmjUHQYWXf5Bl9JVX9vtZ3LaFKPUo8KJf+dQDFSK3guxnIr5+Jjt
oJjX+52vilM=
=nJse
-END PGP SIGNATURE-
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-3000] New proposition for Python3 bytes filename issue

2008-10-01 Thread glyph 


On 03:54 pm, [EMAIL PROTECTED] wrote:
I'm actually sort of liking this idea.  A Pathname class, for 
convenience
a subtype of String, but containing the underlying binary 
representation

used by the OS.  Even non-unicode pathnames could be represented.


On the one hand, I agree with you - except for the part where it's a 
subtype of String, that doesn't work.  In case I haven't mentioned it 
enough times already:


http://twistedmatrix.com/documents/8.1.0/api/twisted.python.filepath.FilePath.html

On the other hand, we've all been on this merry-go-round before:

   http://www.python.org/dev/peps/pep-0355/

Note especially the rejection notice: "Subclassing from str is a 
particularly bad idea".


Again, one day I'd really like to add one of these to Python.  Now is 
not the time.

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-3000] New proposition for Python3 bytes filename issue

2008-10-01 Thread Bill Janssen 
[EMAIL PROTECTED] wrote:

> > I'm actually sort of liking this idea.  A Pathname class, for
> > convenience
> > a subtype of String, but containing the underlying binary
> > representation
> >used by the OS.  Even non-unicode pathnames could be represented.
> 
> On the one hand, I agree with you - except for the part where it's a
> subtype of String, that doesn't work.  In case I haven't mentioned it
> enough times already:
> 
> http://twistedmatrix.com/documents/8.1.0/api/twisted.python.filepath.FilePath.html
> 
> On the other hand, we've all been on this merry-go-round before:
> 
>http://www.python.org/dev/peps/pep-0355/
> 
> Note especially the rejection notice: "Subclassing from str is a
> particularly bad idea".

Yes, the only real justification for it is to not break existing code
(otherwise, calling str() is not that much of an ordeal).

> On the other hand, we've all been on this merry-go-round before:
> 
>http://www.python.org/dev/peps/pep-0355/

The very existence of os.path seems a good argument that something like
this is useful.  Perhaps PEP 355 just went too far.

Bill
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-3000] New proposition for Python3 bytes filename issue

2008-10-01 Thread Martin v. Löwis 
>> SQLite has a similar problem with NULLs, and I'm definitely sticking
>> paths in there, too.
> 
> I think that you can say "all C libraries".

Just for the sake of nit-picking: the socket library, and the regular
POSIX stream IO library (as well as C standard "unformatted" IO) deal
just fine with embedded NULL characters.

>  * Java doesn't support unicode > 0x (boh!)

I don't think that is true anymore.

Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-3000] New proposition for Python3 bytes filename issue

2008-10-01 Thread Nick Coghlan 
Bill Janssen wrote:
> Perhaps PEP 355 just went too far.

That was certainly one of the major objections to it. A filesystem path
object which didn't try to combine a half-dozen different modules into
methods on a single object, but instead focused on solving a few
specific problems with using raw strings as file paths would have a far
greater chance of acceptance.

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://www.boredomandlaziness.org
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] self signing a py2exe winxp executable with signtool

2008-10-01 Thread William Heath 
Hi All,
I am trying to figure out how to self sign a py2exe winxp executable with
signtool.  Anyone know?  I saw this which looked kind of promising:

http://markmail.org/message/zj5nzechzgmjuu7c#query:signtool%20python+page:1+mid:s4jrb2hter4zxvg3+state:results

-Tim

P.S.

Python rocks!
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] RELEASED Python 2.6 final

2008-10-01 Thread Barry Warsaw 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On behalf of the Python development team and the Python community, I  
am happy to announce the release of Python 2.6 final.  This is the  
production-ready version of the latest in the Python 2 series.


There are many new features and modules, improvements, bug fixes, and  
other changes in Python 2.6.  Please see the "What's new" page for  
details


http://docs.python.org/dev/whatsnew/2.6.html

as well as PEP 361

http://www.python.org/dev/peps/pep-0361/

While Python 2.6 is backward compatible with earlier versions of  
Python, 2.6 has many tools and features that will help you migrate to  
Python 3.  Wherever possible, Python 3.0 features have been added  
without affecting existing code.  In other cases, the new features can  
be enabled through the use of __future__ imports and command line  
switches.


Python 3.0 is currently in release candidate and will be available  
later this year.  Both Python 2 and Python 3 will be supported for the  
foreseeable future.


Source tarballs, Windows installers, and Mac disk images can be  
downloaded from the Python 2.6 page:


http://www.python.org/download/releases/2.6/

(Please note that due to quirks in the earth's time zones, the Windows  
installers will be available shortly.)


Bugs can be reported in the Python bug tracker:

http://bugs.python.org

Enjoy,
- -Barry

Barry Warsaw
[EMAIL PROTECTED]
Python 2.6/3.0 Release Manager
(on behalf of the entire python-dev team)

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSOREJ3EjvBPtnXfVAQLAigP/aEnrdvAqk7wbNQLFbmBonIr2YQbd1vEu
TyTr5imYXFWGNfv1/JMeMBjMfwpHi1bgPEDTLEZdhDRNj/G1h4NqqnpfJS0lfIaU
4JBKwnsO80se/RGyupcs5f09UdKxOljhbFKEw46CHDkd9lE+cqy2yhetEwyx3c3+
AVC11sjcO54=
=Oxo3
-END PGP SIGNATURE-
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] RELEASED Python 2.6 final

2008-10-01 Thread Aahz 
Huzzah!
-- 
Aahz ([EMAIL PROTECTED])   <*> http://www.pythoncraft.com/

"...if I were on life-support, I'd rather have it run by a Gameboy than a
Windows box."  --Cliff Wells, comp.lang.python, 3/13/2002
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] RELEASED Python 2.6 final

2008-10-01 Thread Guido van Rossum 
Congratulations, Barry!!!

On Wed, Oct 1, 2008 at 8:46 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On behalf of the Python development team and the Python community, I am
> happy to announce the release of Python 2.6 final.  This is the
> production-ready version of the latest in the Python 2 series.
>
> There are many new features and modules, improvements, bug fixes, and other
> changes in Python 2.6.  Please see the "What's new" page for details
>
>http://docs.python.org/dev/whatsnew/2.6.html
>
> as well as PEP 361
>
>http://www.python.org/dev/peps/pep-0361/
>
> While Python 2.6 is backward compatible with earlier versions of Python, 2.6
> has many tools and features that will help you migrate to Python 3.
>  Wherever possible, Python 3.0 features have been added without affecting
> existing code.  In other cases, the new features can be enabled through the
> use of __future__ imports and command line switches.
>
> Python 3.0 is currently in release candidate and will be available later
> this year.  Both Python 2 and Python 3 will be supported for the foreseeable
> future.
>
> Source tarballs, Windows installers, and Mac disk images can be downloaded
> from the Python 2.6 page:
>
>http://www.python.org/download/releases/2.6/
>
> (Please note that due to quirks in the earth's time zones, the Windows
> installers will be available shortly.)

Can someone who's still up fix add this note to the website? It looks
a little dodgy just linking to a 404 error... :-(

> Bugs can be reported in the Python bug tracker:
>
>http://bugs.python.org
>
> Enjoy,
> - -Barry
>
> Barry Warsaw
> [EMAIL PROTECTED]
> Python 2.6/3.0 Release Manager
> (on behalf of the entire python-dev team)
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (Darwin)
>
> iQCVAwUBSOREJ3EjvBPtnXfVAQLAigP/aEnrdvAqk7wbNQLFbmBonIr2YQbd1vEu
> TyTr5imYXFWGNfv1/JMeMBjMfwpHi1bgPEDTLEZdhDRNj/G1h4NqqnpfJS0lfIaU
> 4JBKwnsO80se/RGyupcs5f09UdKxOljhbFKEw46CHDkd9lE+cqy2yhetEwyx3c3+
> AVC11sjcO54=
> =Oxo3
> -END PGP SIGNATURE-
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] RELEASED Python 2.6 final

2008-10-01 Thread Steven D'Aprano 
On Thu, 2 Oct 2008 01:46:45 pm Barry Warsaw wrote:
> On behalf of the Python development team and the Python community, I
> am happy to announce the release of Python 2.6 final.  This is the
> production-ready version of the latest in the Python 2 series.

I'd like to thank you all very much for your hard work and for making 
such a great language. Cheers!



-- 
Steven
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] RELEASED Python 2.6 final

2008-10-01 Thread Haoyu Bai 
On Thu, Oct 2, 2008 at 11:59 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Congratulations, Barry!!!
>
> On Wed, Oct 1, 2008 at 8:46 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On behalf of the Python development team and the Python community, I am
>> happy to announce the release of Python 2.6 final.  This is the
>> production-ready version of the latest in the Python 2 series.
>>
>> There are many new features and modules, improvements, bug fixes, and other
>> changes in Python 2.6.  Please see the "What's new" page for details
>>
>>http://docs.python.org/dev/whatsnew/2.6.html
>>
>> as well as PEP 361
>>
>>http://www.python.org/dev/peps/pep-0361/
>>
>> While Python 2.6 is backward compatible with earlier versions of Python, 2.6
>> has many tools and features that will help you migrate to Python 3.
>>  Wherever possible, Python 3.0 features have been added without affecting
>> existing code.  In other cases, the new features can be enabled through the
>> use of __future__ imports and command line switches.
>>
>> Python 3.0 is currently in release candidate and will be available later
>> this year.  Both Python 2 and Python 3 will be supported for the foreseeable
>> future.
>>
>> Source tarballs, Windows installers, and Mac disk images can be downloaded
>> from the Python 2.6 page:
>>
>>http://www.python.org/download/releases/2.6/
>>
>> (Please note that due to quirks in the earth's time zones, the Windows
>> installers will be available shortly.)
>
> Can someone who's still up fix add this note to the website? It looks
> a little dodgy just linking to a 404 error... :-(
>
>> Bugs can be reported in the Python bug tracker:
>>
>>http://bugs.python.org
>>
>> Enjoy,
>> - -Barry
>>
>> Barry Warsaw
>> [EMAIL PROTECTED]
>> Python 2.6/3.0 Release Manager
>> (on behalf of the entire python-dev team)
>>
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v1.4.9 (Darwin)
>>
>> iQCVAwUBSOREJ3EjvBPtnXfVAQLAigP/aEnrdvAqk7wbNQLFbmBonIr2YQbd1vEu
>> TyTr5imYXFWGNfv1/JMeMBjMfwpHi1bgPEDTLEZdhDRNj/G1h4NqqnpfJS0lfIaU
>> 4JBKwnsO80se/RGyupcs5f09UdKxOljhbFKEw46CHDkd9lE+cqy2yhetEwyx3c3+
>> AVC11sjcO54=
>> =Oxo3
>> -END PGP SIGNATURE-
>> ___
>> Python-Dev mailing list
>> [email protected]
>> http://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>>
>
>
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/)

Now almost all the pages on docs.python.org can't be accessed. For
example http://docs.python.org/lib/lib.html returns 403 forbidden.

Is the online docs under updating to 2.6, or there's something wrong?

-- 
Haoyu Bai
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] RELEASED Python 2.6 final

2008-10-01 Thread Christian Heimes 
Nice!

Python 2.7 is waiting, let's get started! :)

Christian

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] self signing a py2exe winxp executable with signtool

2008-10-01 Thread Martin v. Löwis 
> I am trying to figure out how to self sign a py2exe winxp executable
> with signtool.  Anyone know?  
Dear William,

This list (python-dev) is for the development of Python, not the
development with Python. I recommend to use either python-list, or
the py2exe-users list for this question.

Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com