Re: [Python-Dev] Python-3.0, unicode, and os.environ

2008-12-12 Thread Adam Olsen 
On Fri, Dec 12, 2008 at 12:33 AM, Toshio Kuratomi  wrote:
> Adam Olsen wrote:
>> As a data point, firefox (when pointed at my home dir) DOES skip over
>> garbage files.
>>
>>
> That's not true.  However, it looks like Firefox is actually broken.
> Take a look at this screenshot:
>  firefox.png
>
> That shows a directory with a folder that's not decodable in my utf-8
> locale.  What's interesting to note is that I actually have two
> nondecodable folders there but only one of them showed up.  So firefox
> is inconsistent with its treatment, rendering some non-decodable files
> and ignoring others.
>
> Also interesting, if you point your browser at:
>  http://toshio.fedorapeople.org/u/
>
> You should see two other test files.  They're both
> (one-half)(enyei).html but one's encoded in utf-8 and the other in
> latin-1.  Firefox has some bugs in it related to this.  For instance, if
> you mouseover the two links you'll see that firefox displays the same
> symbolic names for each of the files (even though they're in two
> different encodings).  Sometimes firefox is able to load both files and
> sometimes it only loads one of them.  Firefox seems to be translating
> the characters from ASCII percent encoding of bytes into their unicode
> symbols and back to utf-8 in some circumstances related to whether it
> has the pages in its cache or not.  In this case, it should be leaving
> things as percent encoded bytes as it's the only way that apache is
> going to know what to retrieve.

UTF-8 in percent encodings is becoming a defacto standard.  Otherwise
the browser has to display the percent escapes in the address bar,
rather than the intended text.

IOW, inconsistent behaviour is a bug, but translating into UTF-8 is not. ;)


-- 
Adam Olsen, aka Rhamphoryncus
___
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-3.0, unicode, and os.environ

2008-12-12 Thread Ulrich Eckhardt 
On Thursday 11 December 2008, Steve Holden wrote:
> Ulrich Eckhardt wrote:
> > If readdir() returned Unicode text, people would start taking that for
> > granted. If it returned bytes, just the same. Returning a completely
> > unrelated type will give them enough hint that for this thing they have
> > to rethink their assumptions. This runs along the lines of "In the face
> > of ambiguity, refuse the temptation to guess.", as it makes guessing
> > rather impossible.
>
> So you are suggesting this "special object" be used only to represent
> files to users? Now I understand.

Not only files, the same problem crops up when handling sys.argv and 
os.environ.

> > I just don't see a case where using a separate path class would break
> > things. Further, the special handling that is required would be made even
> > clearer by using such a class.
>
> But it does have to be implemented ...

Well, it isn't really terribly difficult to do so, after all its just a 
container for either a byte string or Unicode string plus some helper code to 
convert it to/from Unicode.

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] The endless GIL debate: why not remove thread support instead?

2008-12-12 Thread Stefan Behnel 
Hi,

replying to the topic only: because many C libraries support threading and
Python extension modules can integrate them in a way that allows
concurrency in a safe way (although 'safe' is definitely something that is
paid for in developer days).

Stefan

___
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-3.0, unicode, and os.environ

2008-12-12 Thread Ulrich Eckhardt 
On Thursday 11 December 2008, Adam Olsen wrote:
> The simplest solution there is to have windows bytes APIs that return
> raw UTF-16 bytes (note that windows does NOT guaranteed to be valid
> unicode, despite being much more likely than on linux).

Actually, I'm not aware of this case. I only know that the OS refuses to mount 
media it can't decode, but that is on the OS-level. Can you give me a hint?

> The only real issue I see is that UTF-16 isn't an ASCII superset, so it
> won't print nicely.

True, but I personally couldn't care less. Actually, I would even prefer if 
printing a byte string always produced \x escaped byte values, that way it 
would at least be consistent. 

> In other words, bytes can be your special type.

That would actually be a lot of work to do, but I do agree that it would be a 
way. 

The problem though is that I have seen quite a few places in Python where such 
a byte string is passed as 'char*' and treated with the assumption that 
strlen() would yield a meaningful value there, so this calls at least for a 
distinct 'Py_Byte' type. Also, this still doesn't even remotely handle the 
problem that you do have two valid encodings on win32, even though the MBCS 
one could be called deprecated. People will try to interface to other 
libraries that use win32 CHAR strings and that will be much harder or even 
impossible. Further, and that is IMHO the worst part of it, things will fail 
too silently and programmers aren't encouraged to write portable code, but 
maybe I'm just too pessimistic.

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] Python-3.0, unicode, and os.environ

2008-12-12 Thread Stephen J. Turnbull 
Toshio Kuratomi writes:
 > Adam Olsen wrote:
 > > On Thu, Dec 11, 2008 at 6:55 PM, Stephen J. Turnbull  
 > > wrote:
 > >> Unfortunately, even programmers experienced in I18N like Martin, and
 > >> those with intuition-that-has-the-force-of-law like Guido,
 > >> express deliberate disbelief on this point.  They say that filesystem
 > >> names and environment variable values are text, which is true from the
 > >> semantic viewpoint but can't be fully supported by any implementation.
 > > 
 > > With all the focus on backup tools and file managers I think we've
 > > lost perspective.  They're an important use case, but hardly the
 > > dominant one.

True.

 > > Please, as a user, if your app is creating new files, do NOT use
 > > bytes!  You have no excuse for creating garbage, and garbage doesn't
 > > help the user any.  Getting the encoding right, use the unicode APIs,
 > > and don't pass the buck on to everything else.
 > > 
 > Uhmmm That's good advice but doesn't solve any problems :-(.

Exactly.  Furthermore, the problems *already exist*.  My current
locale is UTF-8 and all files dated since about 2002 have UTF-8 names,
*except* in my MIME-bodies garbage can, where only recently have I got
around to coercing my MUA to doing the right thing.  And of course
there are still legacy files names in EUC-JP, which I suppose I could
search for but since I only access a directory containing one once in
a pale blue moon, I'm not gonna bother.

It's just not reasonable to expect users or even sysadminns to go
around cleaning up legacy data.
___
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-3.0, unicode, and os.environ

2008-12-12 Thread André Malo 
* Adam Olsen wrote: 

> UTF-8 in percent encodings is becoming a defacto standard.  Otherwise
> the browser has to display the percent escapes in the address bar,
> rather than the intended text.

Duh! The address bar should contain the URL, which *is* the intended text. 
The escapes are there for a reason. If I pass some octets using percent 
escapes via the query string or request body, it's not text, not even 
intended. It's still a collection of octets. Translating them back (and 
forth when I press enter in the address bar) is a pretty ambigious 
operation and therefore pretty wrong.

The defacto standard does not exist. There's a real one instead: RFC 2396.

nd
___
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-3.0, unicode, and os.environ

2008-12-12 Thread Adam Olsen 
On Fri, Dec 12, 2008 at 1:31 AM, Ulrich Eckhardt
 wrote:
> On Thursday 11 December 2008, Adam Olsen wrote:
>> The simplest solution there is to have windows bytes APIs that return
>> raw UTF-16 bytes (note that windows does NOT guaranteed to be valid
>> unicode, despite being much more likely than on linux).
>
> Actually, I'm not aware of this case. I only know that the OS refuses to mount
> media it can't decode, but that is on the OS-level. Can you give me a hint?

Only pages like this, which indicate the underlying API is an array of WCHAR:

http://blogs.msdn.com/michkap/archive/2005/05/11/416552.aspx


>> The only real issue I see is that UTF-16 isn't an ASCII superset, so it
>> won't print nicely.
>
> True, but I personally couldn't care less. Actually, I would even prefer if
> printing a byte string always produced \x escaped byte values, that way it
> would at least be consistent.
>
>> In other words, bytes can be your special type.
>
> That would actually be a lot of work to do, but I do agree that it would be a
> way.
>
> The problem though is that I have seen quite a few places in Python where such
> a byte string is passed as 'char*' and treated with the assumption that
> strlen() would yield a meaningful value there, so this calls at least for a
> distinct 'Py_Byte' type. Also, this still doesn't even remotely handle the
> problem that you do have two valid encodings on win32, even though the MBCS
> one could be called deprecated. People will try to interface to other
> libraries that use win32 CHAR strings and that will be much harder or even
> impossible. Further, and that is IMHO the worst part of it, things will fail
> too silently and programmers aren't encouraged to write portable code, but
> maybe I'm just too pessimistic.

char * is just fine.  You need only pass a length along with it.  All
internal APIs *must* already do this, as they support nul bytes.  Also
note that the underlying POSIX APIs prohibit nul bytes in filenames,
so it's irrelevant for them.

If your concern is that people will use MBCS byte strings (produced
how?) in a WCHAR API.. I agree it would be confusing, but not nearly
enough to warrant a special type (which would probably get passed a
MBCS byte string anyway.)

Although I haven't found an official claim that MBCS is deprecated, I
see no reason why it wouldn't be effectively obsoleted by the UTF-16
APIs.  (Certain outdated APIs may be the exception.)  We could have a
way to convert (locale-dependent codec?), but that's as much as we
should care.

-- 
Adam Olsen, aka Rhamphoryncus
___
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-3.0, unicode, and os.environ

2008-12-12 Thread Ulrich Eckhardt 
On Friday 12 December 2008, Stephen J. Turnbull wrote:
> I gather that the BFDL's line on this thread of discussion is that
> forcing programmers to think about encodings every time they call out
> to the OS is unacceptable

Exactly that is not necessary.

  for n in os.readdir('.'):
  f = open(n)
  if grep('foo', f):
  print('found "foo"!')

Now, if you actually wanted to output the filename, you could never do so 
reliably anyway, because even though it is supposed to be text, the encoding 
isn't known. So, an archiving program will probably do something like this:

   try:
   for n in os.readdir():
   b = n.encode('UTF-8')
   f = open(n)
   archive.write_file_header(b)
   archive.write_file(f)
   catch ...
   print "oops, couldn't decode file '%s'" % n.unicode(error='replace')

If you're writing a filemanager, you would store the path alongside an 
approximated Unicode representation.


> when most programs will work acceptably 
> almost all of the time with a rather naive approach.  This means that
> almost all Python programs will be technically broken for the
> forseeable future, sorry, Ulrich.

Actually, they are already broken, only that few people notice it. :|

> And for the same pragmatic reasons, these functions are going to
> return strings (ie, Unicode), not bytes, I expect.  Sorry, Steve.
>
> What needs to be determined here is the best way to provide
> reliability to those who will go to the effort of asking for it if
> it's available.  I don't think "just return bytes" fits the bill for
> the reason above.
>
> What I would like to see is a type that is derived from string (so if
> you present it to an API expecting string, it is silently treated as
> string), but from which the original bytes can always be extracted on
> request.

I like that idea, this type would behave pretty much like the env_string I 
proposed. The main difference is that it does several implicit conversions 
where I personally would rather see explicit conversions. Other than that, 
I'm all for it.

> If the original bytes cannot be sensibly decoded to a 
> string, then the string field in the object would either contain
> something that should normally cause an error in a string API, or some
> made-up string (presumably it would attempt to be a more or less
> faithful representation of the bytes) at the caller's option.
> Probably they'd also contain some metadata useful in guessing
> encodings (the read time locale in particular).

Well, I wouldn't provide an approximation. Considering the archiving software 
above, you would end up with a file name "" in an 
archive. For that kind of software, it would be fatal. But, and that is much 
more important than my preference, at least your approach would allow writing 
reliable software that properly handles such environment strings. Further, 
and that is where it differs from just returning bytes, it even makes it easy 
by the using a distinct type.

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] Python-3.0, unicode, and os.environ

2008-12-12 Thread Adam Olsen 
On Fri, Dec 12, 2008 at 2:11 AM, André Malo  wrote:
> * Adam Olsen wrote:
>
>> UTF-8 in percent encodings is becoming a defacto standard.  Otherwise
>> the browser has to display the percent escapes in the address bar,
>> rather than the intended text.
>
> Duh! The address bar should contain the URL, which *is* the intended text.
> The escapes are there for a reason. If I pass some octets using percent
> escapes via the query string or request body, it's not text, not even
> intended. It's still a collection of octets. Translating them back (and
> forth when I press enter in the address bar) is a pretty ambigious
> operation and therefore pretty wrong.
>
> The defacto standard does not exist. There's a real one instead: RFC 2396.

All the heaps of people using non-english wikipedia sites might
disagree with you.  There's only, what, a few *million* pages that
would be affected?

It'd be very interesting if someone at Google could provide some
statistics on URL encodings.


-- 
Adam Olsen, aka Rhamphoryncus
___
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] The endless GIL debate: why not remove thread support instead?

2008-12-12 Thread Paul Moore 
2008/12/12 Sturla Molden :
> Last month there was a discussion on Python-Dev regarding removal of
> reference counting to remove the GIL. I hope you forgive me for continuing
> the debate.
[...]
> Python could be better off doing what tcl does. Allow each process to
> embed multiple interpreters; run each interpreter in its own thread.
> Implement a fast message-passing system between the interpreters (e.g.
> copy-on-write by making communicated objects immutable), and Python would
> be closer to Erlang than Java.

Too much to comment individually here, but I'd agree that
message-passing approaches are a better model in general. Some
specific points:

1. The Queue module gives the bones of a message-passing model,
building something based on that is possible now (and may already
exist). You have to do isolation by convention rather than having it
enforced by the system, but that's OK for coding. (It doesn't help the
"remove the GIL" debate, though).
2. I'd like to see isolation based on multiple interpreters, but the
problem lies with extensions (and at a lower level with the Python C
API) which wasn't designed with isolation in mind. Changing that may
be nice, but it's probably too late (or if not, it's likely to be a
lot of work to do it in a compatible manner).
3. Exposing multiple interpreters at the Python level would let most
of this be done outside the core. But it may result in pure Python
code being able to crash the application if not done carefully.

And of course, the overriding points:
- This needs to be done in a backward compatible manner (Python 3.0 is out now!)
- A working patch is hugely more likely to make progress, as all the
evidence shows that the current core developers don't find this issue
important enough to spend their limited coding time on.

Paul.
___
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] The endless GIL debate: why not remove thread support instead?

2008-12-12 Thread Lennart Regebro 
On Fri, Dec 12, 2008 at 02:13, Sturla Molden  wrote:
> I genuinely think the use of threads should be discouraged. It leads to
> code that are full of bugs and difficult to maintain - race conditions,
> deadlocks, and livelocks are common pitfalls.

The use of threads for load balancing should be discouraged, yes. That
is not what they are designed for. Threads are designed to allow
blocking processes to go on in the background without blocking the
main process. This, they are very useful for. Removing thread support
would therefore be a very big mistake. It's needed, it has it's uses,
just not the one *you* want.

-- 
Lennart Regebro: Zope and Plone consulting.
http://www.colliberty.com/
+33 661 58 14 64
___
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] The endless GIL debate: why not remove thread support instead?

2008-12-12 Thread Sturla Molden 

On 12/12/2008 11:52 AM, Lennart Regebro wrote:


The use of threads for load balancing should be discouraged, yes. That
is not what they are designed for. Threads are designed to allow
blocking processes to go on in the background without blocking the
main process.


It seems that most programmers with Java or Windows experience don't 
understand this; hence the ever lasting GIL debate.


With multiple interpreters - one interpreter per thread - this could 
still be accomplished. Let one interpreter block while another continues 
to work. Then the result of the blocking operation is messaged back. 
Multi-threaded C libraries could be used the in same way. But there 
would be no need for a GIL, because each interpreter would be a 
single-threaded compartment.


.NET have something similar in what is called 'appdomains'.

I am not suggesting removal of threads but rather the Java threading 
model. I just think it is a mistake to let multiple OS threads touch the 
same interpreter.


Sturla Molden
___
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] The endless GIL debate: why not remove thread support instead?

2008-12-12 Thread Nick Coghlan 
Sturla Molden wrote:
> Last month there was a discussion on Python-Dev regarding removal of
> reference counting to remove the GIL. I hope you forgive me for continuing
> the debate.

Anything to do with removing the GIL/threads/whatever other core
language feature someone doesn't like really belongs on c.l.p. or
python-ideas rather than here. Ideas should be at least remotely
feasible before they're brought to python-dev.

That said, I'll bite anyway...

Treating threads as communicating sequential processes (via the Queue
module) actually makes them pretty easy to use correctly.

They are then extraordinarily handy for performing multiple non-GIL
bound tasks (such as IO operations or number crunching using an
extension module like numpy) in parallel.

For GIL bound tasks, switching from the threading module to the
multiprocessing module now allows the activity to scale to multiple CPUs.

Removing thread support merely because concurrent programming is hard
(no matter how you do it) would be... odd (to say the least).

Changing the underlying concurrency mechanism from threads to
subinterpreters to processes to whole computers doesn't make
understanding and coping with the concepts involved in concurrency any
easier (and in fact will often make them harder to handle by increasing
the communications latency).

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
---
___
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] Build failure on OpenBSD 4.4-current

2008-12-12 Thread Edd Barrett 
Hi,

I just had to move the "extern lstat..." outside the "ifndef
HAVE_LSTAT" to get python 2.6.1 to build on OpenBSD 4.4-current/i386.

I'm not suggesting this is correct, but it fixes the build for my
platform at least.

--- Modules/posixmodule.c.orig Fri Dec 12 11:08:54 2008
+++ Modules/posixmodule.c   Fri Dec 12 11:54:16 2008
@@ -208,10 +208,11 @@
 #ifdef HAVE_SYMLINK
 extern int symlink(const char *, const char *);
 #endif /* HAVE_SYMLINK */
+#endif /* !HAVE_UNISTD_H */
+
 #ifdef HAVE_LSTAT
 extern int lstat(const char *, struct stat *);
 #endif /* HAVE_LSTAT */
-#endif /* !HAVE_UNISTD_H */

 #endif /* !_MSC_VER */


Im using gcc-4.2

Thanks

-- 

Best Regards

Edd

http://students.dec.bournemouth.ac.uk/ebarrett
___
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] The endless GIL debate: why not remove thread support instead?

2008-12-12 Thread Nick Coghlan 
Paul Moore wrote:
> 2. I'd like to see isolation based on multiple interpreters, but the
> problem lies with extensions (and at a lower level with the Python C
> API) which wasn't designed with isolation in mind. Changing that may
> be nice, but it's probably too late (or if not, it's likely to be a
> lot of work to do it in a compatible manner).

Actually, I believe 3.0 already took a big step towards allowing this by
changing the way modules are initialised.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
---
___
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-3.0, unicode, and os.environ

2008-12-12 Thread Antoine Pitrou 
Curt Hagenlocher  hagenlocher.org> writes:

> 
> 
> On Thu, Dec 11, 2008 at 10:19 PM, Adam Olsen  gmail.com> wrote:
> 
> 
> I doubt that UTF-16 is used very much (other than on windows).
> 
> There's this other obscure platform called "Java"... ;)

Does it have a filesystem?


___
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] Build failure on OpenBSD 4.4-current

2008-12-12 Thread Antoine Pitrou 
Hello,

Edd Barrett  gmail.com> writes:
> 
> I just had to move the "extern lstat..." outside the "ifndef
> HAVE_LSTAT" to get python 2.6.1 to build on OpenBSD 4.4-current/i386.

Could you please open an issue in http://bugs.python.org ? That way the problem
is less likely to be overlooked.

By the way, there are other bug entries regarding OpenBSD, at least one of them
has a patch waiting for review: http://bugs.python.org/issue3920

Regards

Antoine.


___
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] Build failure on OpenBSD 4.4-current

2008-12-12 Thread Edd Barrett 
Hi,

On Fri, Dec 12, 2008 at 1:17 PM, Antoine Pitrou  wrote:
> Could you please open an issue in http://bugs.python.org ? That way the 
> problem
> is less likely to be overlooked.

http://bugs.python.org/issue4639

Thanks


-- 

Best Regards

Edd

http://students.dec.bournemouth.ac.uk/ebarrett
___
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-3.0, unicode, and os.environ

2008-12-12 Thread Curt Hagenlocher 
On Fri, Dec 12, 2008 at 5:06 AM, Antoine Pitrou  wrote:
>
> Curt Hagenlocher  hagenlocher.org> writes:
>
> > There's this other obscure platform called "Java"... ;)
>
> Does it have a filesystem?

No, but it also has to interact with filesystems of possibly invalid
or indeterminate encodings.  What does java.io do?

--
Curt Hagenlocher
[email protected]
___
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-3.0, unicode, and os.environ

2008-12-12 Thread Antoine Pitrou 
Curt Hagenlocher  hagenlocher.org> writes:
> 
> No, but it also has to interact with filesystems of possibly invalid
> or indeterminate encodings.  What does java.io do?

My point was that Python doesn't have to interact with the Java IO libraries,
while it has to interact with the Unix and Windows IO APIs.



___
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-3.0, unicode, and os.environ

2008-12-12 Thread Curt Hagenlocher 
On Fri, Dec 12, 2008 at 6:19 AM, Antoine Pitrou  wrote:
> Curt Hagenlocher  hagenlocher.org> writes:
>>
>> No, but it also has to interact with filesystems of possibly invalid
>> or indeterminate encodings.  What does java.io do?
>
> My point was that Python doesn't have to interact with the Java IO libraries,
> while it has to interact with the Unix and Windows IO APIs.

Of course.  But the Java IO libraries have to interact with the Unix
and Windows IO APIs as well. It might be interesting to know how they
handle similar situations.

--
Curt Hagenlocher
[email protected]
___
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] The endless GIL debate: why not remove thread support instead?

2008-12-12 Thread Christian Heimes 
Nick Coghlan schrieb:
> Actually, I believe 3.0 already took a big step towards allowing this by
> changing the way modules are initialised.

You are believing correctly. Martin has designed and implemented a
nicely working API to store extension module data per interpreter state.
 For now interpreter states are used for sub interpreters only.

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

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] Python-3.0, unicode, and os.environ

2008-12-12 Thread Scott Dial 
Curt Hagenlocher wrote:
> On Fri, Dec 12, 2008 at 6:19 AM, Antoine Pitrou  wrote:
>> Curt Hagenlocher  hagenlocher.org> writes:
>>> No, but it also has to interact with filesystems of possibly invalid
>>> or indeterminate encodings.  What does java.io do?
>> My point was that Python doesn't have to interact with the Java IO libraries,
>> while it has to interact with the Unix and Windows IO APIs.
> 
> Of course.  But the Java IO libraries have to interact with the Unix
> and Windows IO APIs as well. It might be interesting to know how they
> handle similar situations.

See the following email for a summary of existing practice (as of 2004):

http://www.mail-archive.com/[email protected]/msg27352.html

-Scott

-- 
Scott Dial
[email protected]
[email protected]
___
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] 2to3 question about fix_imports.

2008-12-12 Thread Lennart Regebro 
The fix_imports fix seems to fix only the first import per line that you have.
So if you do for example
   import urllib2, cStringIO
it will not fix cStringIO.

Is this a bug or a feature? :-) If it's a feature it should warn at
least, right?

-- 
Lennart Regebro: Zope and Plone consulting.
http://www.colliberty.com/
+33 661 58 14 64
___
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] 2to3 question about fix_imports.

2008-12-12 Thread Victor Stinner 
Le Friday 12 December 2008 17:39:33 Lennart Regebro, vous avez écrit :
> The fix_imports fix seems to fix only the first import per line that you
> have. So if you do for example
>import urllib2, cStringIO
> it will not fix cStringIO.
>
> Is this a bug or a feature? :-)

I prefer to see that as a bug and so replace cStringIO by StringIO. So can you 
open an issue?

-- 
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-3.0, unicode, and os.environ

2008-12-12 Thread Toshio Kuratomi 
Adam Olsen wrote:
> UTF-8 in percent encodings is becoming a defacto standard.  Otherwise
> the browser has to display the percent escapes in the address bar,
> rather than the intended text.
> 
> IOW, inconsistent behaviour is a bug, but translating into UTF-8 is not. ;)
> 
> 
I think we should let this tangent drop because it's about bugs in
firefox bug, not in python :-)

-Toshio



signature.asc
Description: OpenPGP digital 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] The endless GIL debate: why not remove thread support instead?

2008-12-12 Thread Thomas Heller 
Christian Heimes schrieb:
> Nick Coghlan schrieb:
>> Actually, I believe 3.0 already took a big step towards allowing this by
>> changing the way modules are initialised.
> 
> You are believing correctly. Martin has designed and implemented a
> nicely working API to store extension module data per interpreter state.
>  For now interpreter states are used for sub interpreters only.
> 
> http://www.python.org/dev/peps/pep-3121/

But the extension modules still have to changed to use this mechanism, right?
-- 
Thanks,
Thomas

___
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] The endless GIL debate: why not remove thread support instead?

2008-12-12 Thread Lennart Regebro 
On Fri, Dec 12, 2008 at 12:23, Sturla Molden  wrote:
> It seems that most programmers with Java or Windows experience don't
> understand this; hence the ever lasting GIL debate.

Yes. Maybe writing this with big letters in the thread module docs would help?

> I am not suggesting removal of threads but rather the Java threading model.
> I just think it is a mistake to let multiple OS threads touch the same
> interpreter.

Does Python have a java threading model? I don't know java well enough
to know what that is. :)

-- 
Lennart Regebro: Zope and Plone consulting.
http://www.colliberty.com/
+33 661 58 14 64
___
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-3.0, unicode, and os.environ

2008-12-12 Thread Lennart Regebro 
On Fri, Dec 12, 2008 at 16:21, Scott Dial
 wrote:
> See the following email for a summary of existing practice (as of 2004):
>
> http://www.mail-archive.com/[email protected]/msg27352.html

Interesting. Quite a lot of them do just drop the undecodable
filenames. The Java solution with replacing it seems to be a better
idea at first glance, but what if you then end up with two filenames
that are the same? Possibly replacing with the  character is a good
idea to notify that the file is there, but fail then fail to open it.

-- 
Lennart Regebro: Zope and Plone consulting.
http://www.colliberty.com/
+33 661 58 14 64
___
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] Summary of Python tracker Issues

2008-12-12 Thread Python tracker 

ACTIVITY SUMMARY (12/05/08 - 12/12/08)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue 
number.  Do NOT respond to this message.


 2261 open (+58) / 14206 closed (+37) / 16467 total (+95)

Open issues with patches:   763

Average duration of open issues: 699 days.
Median duration of open issues: 2499 days.

Open Issues Breakdown
   open  2242 (+57)
pending19 ( +1)

Issues Created Or Reopened (97)
___

Remove mimetools usage from the stdlib   12/06/08
   http://bugs.python.org/issue2848reopened brett.cannon  
   patch   

improve linecache: reuse tokenize.detect_encoding() and io.open( 12/12/08
   http://bugs.python.org/issue4016reopened benjamin.peterson 
   patch   

Deprecated python 2.x syntax in "HOWTO Use Python in the web"12/05/08
CLOSED http://bugs.python.org/issue4550created  jcsalterego   
   patch   

The python 2.6.1 source distribution is missing Doc/tools/sphinx 12/05/08
CLOSED http://bugs.python.org/issue4551created  andreask  
   

Doc/tools/sphinxext not included in the 2.6.1 tarball12/05/08
CLOSED http://bugs.python.org/issue4552created  doko  
   

Results from os.path.islink and os.stat S_ISLNK do not match 12/05/08
CLOSED http://bugs.python.org/issue4553created  npatters  
   

Missing  make altframeworkinstall for Mac OS X   12/06/08
   http://bugs.python.org/issue4554created  christian.heimes  
   

Smelly exports   12/06/08
   http://bugs.python.org/issue4555created  christian.heimes  
   

cmp() function erroneously noted as gone in "What's New" 12/06/08
CLOSED http://bugs.python.org/issue4556created  mwatkins  
   

array('c') in python 3.0 produces error, doc says it is ok   12/06/08
CLOSED http://bugs.python.org/issue4557created  lopgok
   

with_stdc89  12/06/08
   http://bugs.python.org/issue4558created  christian.heimes  
   patch, patch

Whats new recommendation error   12/06/08
CLOSED http://bugs.python.org/issue4559created  lregebro  
   

"Flouted", not "flaunted"12/06/08
CLOSED http://bugs.python.org/issue4560created  jdf   
   

Optimize new io library  12/06/08
   http://bugs.python.org/issue4561created  christian.heimes  
   patch   

zip() documentation was not updated  12/06/08
CLOSED http://bugs.python.org/issue4562created  mchouza   
   

Wrong formatting of contributor list in About page   12/06/08
   http://bugs.python.org/issue4563created  salty-horse   
   

bytearray.fromhex doesn't respect bytearray subclass 12/06/08
CLOSED http://bugs.python.org/issue4564created  pitrou
   

io write() performance very slow 12/06/08
   http://bugs.python.org/issue4565created  ialbert   
   

2.6.1 breaks many applications that embed Python on Windows  12/06/08
   http://bugs.python.org/issue4566created  craigh
   

Registry key not set if unattended installatio

Re: [Python-Dev] Python-3.0, unicode, and os.environ

2008-12-12 Thread glyph 

On 02:23 pm, [email protected] wrote:
On Fri, Dec 12, 2008 at 6:19 AM, Antoine Pitrou  
wrote:

Curt Hagenlocher  hagenlocher.org> writes:


No, but it also has to interact with filesystems of possibly invalid
or indeterminate encodings.  What does java.io do?


My point was that Python doesn't have to interact with the Java IO 
libraries,

while it has to interact with the Unix and Windows IO APIs.


Of course.  But the Java IO libraries have to interact with the Unix
and Windows IO APIs as well. It might be interesting to know how they
handle similar situations.


Apparently Java has the facilities to do the right thing, but actually 
it's just broken.


My locale says UTF-8.  However, if I create a non-decodable file with 
Python (2), there are three ways I can tell Java to open it: I can ask 
for it with a string (that won't work, because no valid UTF-8 string 
maps to an undecodable string, pretty much by definition).  I can list 
the directory that it's in (presuming that *that's* a directory) and get 
a java.io.File, which could be retaining all the interesting 
information, or I can use a URI, which is a string that resolves to 
octets before it resolves to characters again.


However, it looks like Java screws up in every case.

Here's a transcript from the ever-helpful jython:

gl...@nhuvasarim:~/tmp$ python
Python 2.5.2 (r252:60911, Jul 31 2008, 17:28:52) [GCC 4.2.3 (Ubuntu 
4.2.3-2ubuntu7)] on linux2

Type "help", "copyright", "credits" or "license" for more information.

file("\xff\xff", "wb").write("lolz\n")

gl...@nhuvasarim:~/tmp$ jython
Jython 2.2.1 on java1.6.0_07
Type "copyright", "credits" or "license" for more information.

from java.io import File
fileList = File(".").listFiles()
fileList

array(java.io.File,[./

fileList[0].__class__



from java.io import FileReader
FileReader(fileList[0])

Traceback (innermost last):
 File "", line 1, in ?
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.(FileInputStream.java:106)
at java.io.FileReader.(FileReader.java:55)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native 
Method)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at 
java.lang.reflect.Constructor.newInstance(Constructor.java:513)


java.io.FileNotFoundException: java.io.FileNotFoundException: ./ÿFDÿFD (No 
such file or directory)

from java.net import URI
u = URI("file:///home/glyph/tmp/%ff%ff")
FileReader(File(u))

Traceback (innermost last):
 File "", line 1, in ?
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.(FileInputStream.java:106)
at java.io.FileReader.(FileReader.java:55)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native 
Method)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at 
java.lang.reflect.Constructor.newInstance(Constructor.java:513)


java.io.FileNotFoundException: java.io.FileNotFoundException: 
/home/glyph/tmp/ÿFDÿFD (No such file or directory)


___
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] The endless GIL debate: why not remove thread support instead?

2008-12-12 Thread Nick Coghlan 
Thomas Heller wrote:
> Christian Heimes schrieb:
>> Nick Coghlan schrieb:
>>> Actually, I believe 3.0 already took a big step towards allowing this by
>>> changing the way modules are initialised.
>> You are believing correctly. Martin has designed and implemented a
>> nicely working API to store extension module data per interpreter state.
>>  For now interpreter states are used for sub interpreters only.
>>
>> http://www.python.org/dev/peps/pep-3121/
> 
> But the extension modules still have to changed to use this mechanism, right?

Yep, but at least it's *possible* now. With 2.x, it isn't possible for
an extension module to support subinterpreters properly, even if they
want to.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
---
___
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-3.0, unicode, and os.environ

2008-12-12 Thread André Malo 
* Adam Olsen wrote:

> On Fri, Dec 12, 2008 at 2:11 AM, André Malo  wrote:
> > * Adam Olsen wrote:
> >> UTF-8 in percent encodings is becoming a defacto standard.  Otherwise
> >> the browser has to display the percent escapes in the address bar,
> >> rather than the intended text.
> >
> > Duh! The address bar should contain the URL, which *is* the intended
> > text. The escapes are there for a reason. If I pass some octets using
> > percent escapes via the query string or request body, it's not text,
> > not even intended. It's still a collection of octets. Translating them
> > back (and forth when I press enter in the address bar) is a pretty
> > ambigious operation and therefore pretty wrong.
> >
> > The defacto standard does not exist. There's a real one instead: RFC
> > 2396.
>
> All the heaps of people using non-english wikipedia sites might
> disagree with you.  There's only, what, a few *million* pages that
> would be affected?

I'm not sure what you're trying to pull here. Is that supposed to be an 
argument? There's no page affected at all. It's a browser UI issue, not a 
page issue.

And even if it were interesting at all, how the URL escapes are displayed in 
the address bar, those millions of people would favourite KOI8-R or Big 5 
over UTF-8 if you would ask them.

Which leads to the exact point: The browser cannot know, nor should it even. 
It's opaque. The only entity which needs to understand the encoding of URL 
percent escapes in query or request body is the *server* selecting the 
resource.

But I'm sure I'm not telling you any news here.

nd
-- 
"Das Verhalten von Gates hatte mir bewiesen, dass ich auf ihn und seine
beiden Gefährten nicht zu zählen brauchte" -- Karl May, "Winnetou III"

Im Westen was neues: 
___
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-3.0, unicode, and os.environ

2008-12-12 Thread Adam Olsen 
On Fri, Dec 12, 2008 at 9:47 PM, André Malo  wrote:
> * Adam Olsen wrote:
>> On Fri, Dec 12, 2008 at 2:11 AM, André Malo  wrote:
>> > * Adam Olsen wrote:
>> >> UTF-8 in percent encodings is becoming a defacto standard.  Otherwise
>> >> the browser has to display the percent escapes in the address bar,
>> >> rather than the intended text.
>> >
>> > Duh! The address bar should contain the URL, which *is* the intended
>> > text. The escapes are there for a reason. If I pass some octets using
>> > percent escapes via the query string or request body, it's not text,
>> > not even intended. It's still a collection of octets. Translating them
>> > back (and forth when I press enter in the address bar) is a pretty
>> > ambigious operation and therefore pretty wrong.
>> >
>> > The defacto standard does not exist. There's a real one instead: RFC
>> > 2396.
>>
>> All the heaps of people using non-english wikipedia sites might
>> disagree with you.  There's only, what, a few *million* pages that
>> would be affected?
>
> I'm not sure what you're trying to pull here. Is that supposed to be an
> argument? There's no page affected at all. It's a browser UI issue, not a
> page issue.
>
> And even if it were interesting at all, how the URL escapes are displayed in
> the address bar, those millions of people would favourite KOI8-R or Big 5
> over UTF-8 if you would ask them.
>
> Which leads to the exact point: The browser cannot know, nor should it even.
> It's opaque. The only entity which needs to understand the encoding of URL
> percent escapes in query or request body is the *server* selecting the
> resource.
>
> But I'm sure I'm not telling you any news here.

You're arguing that text should be an opaque entity..

We've wasted enough of everybody's time on this already, I'm not going
to continue on this thread.  Send me a private email if you think it's
really important.


-- 
Adam Olsen, aka Rhamphoryncus
___
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-3.0, unicode, and os.environ

2008-12-12 Thread André Malo 
* Adam Olsen wrote:

> On Fri, Dec 12, 2008 at 9:47 PM, André Malo  wrote:
> > * Adam Olsen wrote:
> >> On Fri, Dec 12, 2008 at 2:11 AM, André Malo  wrote:
> >> > * Adam Olsen wrote:
> >> >> UTF-8 in percent encodings is becoming a defacto standard. 
> >> >> Otherwise the browser has to display the percent escapes in the
> >> >> address bar, rather than the intended text.
> >> >
> >> > Duh! The address bar should contain the URL, which *is* the intended
> >> > text. The escapes are there for a reason. If I pass some octets
> >> > using percent escapes via the query string or request body, it's not
> >> > text, not even intended. It's still a collection of octets.
> >> > Translating them back (and forth when I press enter in the address
> >> > bar) is a pretty ambigious operation and therefore pretty wrong.
> >> >
> >> > The defacto standard does not exist. There's a real one instead: RFC
> >> > 2396.
> >>
> >> All the heaps of people using non-english wikipedia sites might
> >> disagree with you.  There's only, what, a few *million* pages that
> >> would be affected?
> >
> > I'm not sure what you're trying to pull here. Is that supposed to be an
> > argument? There's no page affected at all. It's a browser UI issue, not
> > a page issue.
> >
> > And even if it were interesting at all, how the URL escapes are
> > displayed in the address bar, those millions of people would favourite
> > KOI8-R or Big 5 over UTF-8 if you would ask them.
> >
> > Which leads to the exact point: The browser cannot know, nor should it
> > even. It's opaque. The only entity which needs to understand the
> > encoding of URL percent escapes in query or request body is the
> > *server* selecting the resource.
> >
> > But I'm sure I'm not telling you any news here.
>
> You're arguing that text should be an opaque entity..

No, actually I'm not. I'm arguing that escapes are opaque.

> We've wasted enough of everybody's time on this already, I'm not going
> to continue on this thread. 

Agreed.

nd
-- 
Da fällt mir ein, wieso gibt es eigentlich in Unicode kein
"i" mit einem Herzchen als Tüpfelchen? Das wär sooo süüss!

 -- Björn Höhrmann in darw
___
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] Psyco for -OO or -O

2008-12-12 Thread Lie Ryan 
I'm sure probably most of you knows about psyco[1], the optimizer. Python 
has an -O and -OO flag that is intended to be optimization flag, but we 
know that currently it doesn't do much. Why not add psyco as standard 
library and let -O or -OO invoke psyco?

[1] http://psyco.sourceforge.net/index.html

___
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