Martin v. Löwis wrote:
Please, if you have a *new* idea that doesn't have a failure mode, by
all means post it. But don't resurrect a pointless bikeshed.
While I completely agree that it is pointless to reiterate the same
arguments over and over, I disagree that the bikeshed metapher
Barry Warsaw schrieb:
On Dec 4, 2008, at 6:21 PM, Martin v. Löwis wrote:
I can't find any docs built for Python 3.0 (not 3.1a0).
The Windows installation has new 3.0 doc dated Dec 3, so it was
built,
just not posted correctly.
That doesn't mean very much. I built it on my local
On Fri, Dec 5, 2008 at 12:00 AM, Martin v. Löwis [EMAIL PROTECTED] wrote:
Please, if you have a *new* idea that doesn't have a failure mode, by
all means post it. But don't resurrect a pointless bikeshed.
While I completely agree that it is pointless to reiterate the same
arguments over and
Maciej Fijalkowski wrote:
Hello,
The thing is pypy's taint code is broken. Basically you don't only
need to patch all places that return pyobject, but also all places
that might modify anything. (All side effects) For example innocently
looking call to addition might end up calling
[EMAIL PROTECTED] wrote:
At least this time I think I've encapsulated pretty much my entire
argument here, so if you don't buy it, we can probably just agree to
disagree :).
Glyph, the only point I would add to your message is this one:
Adding a blessed way to encode arbitrary binary data
Le Friday 05 December 2008 00:39:24 Martin v. Löwis, vous avez écrit :
5) represent all environment variables in Unicode strings,
including the ones that currently fail to decode.
(then do the same to file names, then drop the byte-oriented
file operations again)
Please, don't do
On Friday 05 December 2008, Adam Olsen wrote:
Many of the windows APIs use UTF-16 without validating it. They'll
pass through invalid strings until they hit something that does
validate, at which point it'll blow up.
I suspect that it doesn't happen very often in practice, as having
only
Hi,
Le Thursday 04 December 2008 21:02:19 Toshio Kuratomi, vous avez écrit :
I opened up bug http://bugs.python.org/issue4006 a while ago and it was
suggested in the report that it's not a bug but a feature and so I
should come here to see about getting the feature changed :-)
Yeah, I prefer
On Friday 05 December 2008, Guido van Rossum wrote:
At the risk of bringing up something that was already rejected, let me
propose something that follows the path taken in 3.0 for filenames,
rather than doubling back:
For os.environ, os.getenv() and os.putenv(), I think a similar
approach as
Hello,
This concerns a known bug in the frame_setlineno() function for Python
2.5.x and 2.6.x (maybe in earlier version too). It is not possible to use
this function when the address or line offset are greater than 127. The
problem comes from the lnotab variable which is typed char*, therefore
http://code.activestate.com/recipes/576550/
This recipe shows how to use gsl FFT with python 3.
ctypes is really good!
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
On Thu, 4 Dec 2008 22:05:05 -0800, Guido van Rossum [EMAIL PROTECTED] wrote:
On Thu, Dec 4, 2008 at 9:40 PM, [EMAIL PROTECTED] wrote:
The default case, the case of the user without the wherewithal
to understand the nuances of the distinction between 2.x and 3.x, is a user
who should use 2.x.
On Fri, Dec 5, 2008 at 12:35 AM, A.M. Kuchling [EMAIL PROTECTED] wrote:
On Thu, Dec 04, 2008 at 05:29:31PM -0800, Raymond Hettinger wrote:
Here's a bright idea. On the 3.0 release page, include a box listing
which major third-party apps have been converted. Update it
once every couple of
Hi,
Please post this on the issue tracker. http://bugs.python.org
On Fri, Dec 5, 2008 at 4:42 AM, [EMAIL PROTECTED] wrote:
Hello,
This concerns a known bug in the frame_setlineno() function for Python
2.5.x and 2.6.x (maybe in earlier version too). It is not possible to use
this function
On Dec 5, 2008, at 5:27 AM, Ulrich Eckhardt wrote:
Using the byte variant is equally fubar, because e.g. on MS Windows
it is not
supported, except through a very lossy roundtrip through the locale's
codepage, limiting your functionality.
Yeah, IMO whole mess could have been avoided by
Terry Reedy wrote:
Toshio Kuratomi wrote:
I would think life would be ultimately easier if either the file server
or the shell server automatically translated file names from jis and
utf8 and back, so that the PATH on the *nix shell server is entirely
utf8.
This is not possible because no
Hi,
I started to write a short article about Python security on the wiki:
http://wiki.python.org/moin/Security
Nothing useful yet.
--
Victor Stinner aka haypo
http://www.haypocalc.com/blog/
___
Python-Dev mailing list
Python-Dev@python.org
Martin There is. There have been the following trove classifiers
Martin defined for a few weeks now:
Martin Programming Language :: Python :: 2
Martin Programming Language :: Python :: 2.3
Martin Programming Language :: Python :: 2.4
Martin Programming Language :: Python
On Fri, Dec 05, 2008 at 05:40:46AM -, [EMAIL PROTECTED] wrote:
For most users, especially new users who have yet to be impressed with
Python's power, 2.x is much better. It's not like library support is
one small check-box on the language's feature sheet: most of the
attractive
One thing that would help Python in this debate (or, perhaps simply
put it in the running, at least as a next Java candidate) would be
if Python had an easier migration path for Java developers that
currently rely upon various third-party libraries. The wealth of
third-party
ACTIVITY SUMMARY (11/28/08 - 12/05/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.
2233 open (+55) / 14139 closed (+41) / 16372 total (+96)
Open issues with patches: 753
Victor Stinner wrote:
Hi,
Le Thursday 04 December 2008 21:02:19 Toshio Kuratomi, vous avez écrit :
These mixed encodings can occur for a variety of reasons. Here's an
example that isn't too contrived :-)
(...)
Furthermore, they don't want to suffer from the space loss of using
utf-8
On Fri, Dec 5, 2008 at 2:27 AM, Ulrich Eckhardt [EMAIL PROTECTED] wrote:
Seriously, what would you suggest to someone that
wants to handle paths in a portable way? Using the Unicode variants of
functions is fubar, because encoding/decoding is not universally possible.
Using the byte variant is
On Dec 4, 2008, at 7:59 PM, [EMAIL PROTECTED] wrote:
On 02:35 am, [EMAIL PROTECTED] wrote:
On Thu, Dec 04, 2008 at 05:29:31PM -0800, Raymond Hettinger wrote:
Here's a bright idea. On the 3.0 release page, include a box
listing
which major third-party apps have been converted. Update it
On Thu, Dec 4, 2008 at 11:27 PM, [EMAIL PROTECTED] wrote:
With all due respect, for me, library support and serious use are
synonymous.
Glyph, I cannot have a discussion with you if every single post of
yours is longer than my combined daily output. Please spend some time
writing shorter
On Dec 5, 2008, at 10:25 AM, [EMAIL PROTECTED] wrote:
Good. Now we just need to populate them. I take it the classifiers
without
minor numbers imply any known minor version (e.g., 2 == 2.3 and
greater)?
This is an excellent question, Skip.
There was already Programming Language ::
Hi,
as a follow-up to the thread a few days ago, and the bug report, I've
rewritten most of the __import__ docs. I've attached the suggested patch
to the issue http://bugs.python.org/issue4457.
I'd be glad for reviews. Also, I'd like to ask about opinions if this
winning idiom (as a bug comment
Hi all,
to facilitate discussion about porting Python code between different versions
(mainly of course from 2.x to 3.x), we've created a new mailing list
[EMAIL PROTECTED]
It is a public mailing list open to everyone. We expect active participation
of many people porting their
On Thu, Dec 4, 2008 at 3:12 PM, Christian Heimes [EMAIL PROTECTED] wrote:
Flow diagram
trunk --- release26-maint
\- py3k --- release30-maint
I'm running into problems making this work, with a trivial change:
I committed r67590 (which adds a single assert to
On Fri, Dec 5, 2008 at 10:36, Georg Brandl [EMAIL PROTECTED] wrote:
Hi all,
to facilitate discussion about porting Python code between different versions
(mainly of course from 2.x to 3.x), we've created a new mailing list
[EMAIL PROTECTED]
It is a public mailing list open to everyone.
On Fri, Dec 5, 2008 at 11:20, Mark Dickinson [EMAIL PROTECTED] wrote:
On Thu, Dec 4, 2008 at 3:12 PM, Christian Heimes [EMAIL PROTECTED] wrote:
Flow diagram
trunk --- release26-maint
\- py3k --- release30-maint
I'm running into problems making this work, with
On Dec 5, 2008, at 2:20 PM, Mark Dickinson wrote:
Did I mess up somewhere, or does svnmerge not work on
a revision that was itself the result of an svnmerge?
I ran into this yesterday as well with my patch to the cgi module.
The work-around was to revert the change to that property and edit
[EMAIL PROTECTED] schrieb:
To be fair, if someone asked me specifically about educating non-
programmer adults about programming, I would probably at least
*mention* py3, if not recommend it outright. The improved consistency
is worth a lot in an educational setting. (But, if one is
Georg[EMAIL PROTECTED]
Georg It is a public mailing list open to everyone. We expect active
Georg participation of many people porting their libraries/programs,
Georg and hope that the list can be a help to all wanting to go this
Georg (not always smooth :-) way.
I
[EMAIL PROTECTED] schrieb:
Georg[EMAIL PROTECTED]
Georg It is a public mailing list open to everyone. We expect active
Georg participation of many people porting their libraries/programs,
Georg and hope that the list can be a help to all wanting to go this
Georg
On 5-Dec-08, at 8:40 AM, A.M. Kuchling wrote:
On Fri, Dec 05, 2008 at 05:40:46AM -, [EMAIL PROTECTED] wrote:
For most users, especially new users who have yet to be impressed
with
Python's power, 2.x is much better. It's not like library
support is
one small check-box on the
Guido van Rossum wrote:
On Fri, Dec 5, 2008 at 2:27 AM, Ulrich Eckhardt [EMAIL PROTECTED] wrote:
In 99% of all cases, using the default encoding will work and do what people
expect, which is why I would make this conversion automatic. In all other
cases, it will at least not fail silently
On Fri, Dec 5, 2008 at 12:05 PM, Toshio Kuratomi [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
On Fri, Dec 5, 2008 at 2:27 AM, Ulrich Eckhardt [EMAIL PROTECTED] wrote:
In 99% of all cases, using the default encoding will work and do what people
expect, which is why I would make this
Guido van Rossum wrote:
Glob was just an example. Many use cases for directory traversal
couldn't care less if they see *all* files.
Okay. Makes it harder to prove correct or not if I don't know what the
use case is :-) I can't think of a single use case off-hand.
Even your example of a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gregor Lingl wrote:
[EMAIL PROTECTED] schrieb:
To be fair, if someone asked me specifically about educating non-
programmer adults about programming, I would probably at least
*mention* py3, if not recommend it outright. The improved
Guido van Rossum wrote:
At the risk of bringing up something that was already rejected, let me
propose something that follows the path taken in 3.0 for filenames,
rather than doubling back:
For os.environ, os.getenv() and os.putenv(), I think a similar
approach as used for os.listdir() and
Hi,
But they are open questions (already asked in the bug tracker):
I answered these in the bug tracker. Here are the answers for the
mailing list:
Oh, sorry. I didn't follow the end of the discussion on the bug tracker.
os.environb['PATH'] = '\xff'
= os.environ['PATH'] = ???
Toshio Kuratomi wrote:
Guido van Rossum wrote:
Glob was just an example. Many use cases for directory traversal
couldn't care less if they see *all* files.
Okay. Makes it harder to prove correct or not if I don't know what the
use case is :-) I can't think of a single use case off-hand.
Georg Brandl wrote:
Hi,
as a follow-up to the thread a few days ago, and the bug report, I've
rewritten most of the __import__ docs. I've attached the suggested patch
to the issue http://bugs.python.org/issue4457.
I'd be glad for reviews. Also, I'd like to ask about opinions if this
Victor Stinner wrote:
It would be maybe easier if os.environ supports bytes and unicode keys.
But we have to keep these assertions:
os.environ[bytes] - bytes
os.environ[str] - str
I think the same choices have to be made here. If LANG=C, we still have
to decide what to do when
Fred Drake wrote:
On Dec 5, 2008, at 2:20 PM, Mark Dickinson wrote:
Did I mess up somewhere, or does svnmerge not work on
a revision that was itself the result of an svnmerge?
I ran into this yesterday as well with my patch to the cgi module. The
work-around was to revert the change to
Toshio Kuratomi wrote:
Are most programs specific to one organization or are they distributed
to other people?
The former. That's pretty well documented in assorted IT literature
('shrink-wrap' and open source commodity software are still relatively
new players on the scene that started to
Nick Coghlan wrote:
I think we're discovering the real reasons why people generally prefer
to use a DVCS when trying to manage multiple branches :P
For now it looks like we might have to maintain 3.0 manually, with
svnmerge only helping out for trunk-2.6 and trunk-py3k...
The problem seems to
Nick Coghlan wrote:
Toshio Kuratomi wrote:
Are most programs specific to one organization or are they distributed
to other people?
The former. That's pretty well documented in assorted IT literature
('shrink-wrap' and open source commodity software are still relatively
new players on the
Nick Coghlan wrote:
Toshio Kuratomi wrote:
Guido van Rossum wrote:
Glob was just an example. Many use cases for directory traversal
couldn't care less if they see *all* files.
Okay. Makes it harder to prove correct or not if I don't know what the
use case is :-) I can't think of a single
On Dec 5, 2008, at 5:31 PM, Nick Coghlan wrote:
I think we're discovering the real reasons why people generally prefer
to use a DVCS when trying to manage multiple branches :P
Really? I don't. The issue has nothing to do with someone
maintaining private change sets, or wanting to do
Nick Coghlan wrote:
For now it looks like we might have to maintain 3.0 manually, with
svnmerge only helping out for trunk-2.6 and trunk-py3k
Does it make the bookkeeping horrible if you merge from trunk straight
to 3.0, and then blocked svnmerged changes from propagating?
-jJ
Good. Now we just need to populate them. I take it the classifiers without
minor numbers imply any known minor version (e.g., 2 == 2.3 and greater)?
Perhaps. As usual, they mean what people use them for.
I intended them to mean 2.x and 3.x, respectively, with no constraint on
x (i.e.
On Fri, 5 Dec 2008 at 12:11, Guido van Rossum wrote:
On Fri, Dec 5, 2008 at 12:05 PM, Toshio Kuratomi [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
On Fri, Dec 5, 2008 at 2:27 AM, Ulrich Eckhardt [EMAIL PROTECTED] wrote:
In 99% of all cases, using the default encoding will work and do what
Toshio Kuratomi wrote:
Nick Coghlan wrote:
Toshio Kuratomi wrote:
Guido van Rossum wrote:
Glob was just an example. Many use cases for directory traversal
couldn't care less if they see *all* files.
Okay. Makes it harder to prove correct or not if I don't know what the
use case is :-) I
On Fri, Dec 5, 2008 at 19:10, Guido van Rossum [EMAIL PROTECTED] wrote:
On Thu, Dec 4, 2008 at 11:27 PM, [EMAIL PROTECTED] wrote:
With all due respect, for me, library support and serious use are
synonymous.
Glyph, I cannot have a discussion with you if every single post of
yours is
On Fri, Dec 5, 2008 at 18:48, Nick Coghlan [EMAIL PROTECTED] wrote:
Toshio Kuratomi wrote:
Nick Coghlan wrote:
Toshio Kuratomi wrote:
Guido van Rossum wrote:
Glob was just an example. Many use cases for directory traversal
couldn't care less if they see *all* files.
Okay. Makes it harder
On Sat, 6 Dec 2008 09:18:47 am Nick Coghlan wrote:
Toshio Kuratomi wrote:
Guido van Rossum wrote:
Glob was just an example. Many use cases for directory traversal
couldn't care less if they see *all* files.
Okay. Makes it harder to prove correct or not if I don't know what
the use
Toshio Kuratomi wrote:
Nick Coghlan wrote:
Toshio Kuratomi wrote:
Are most programs specific to one organization or are they distributed
to other people?
The former. That's pretty well documented in assorted IT literature
('shrink-wrap' and open source commodity software are still relatively
There was already Programming Language :: Python, provided by many
packages. I think version compatibility relationships meant by each of
these classifiers should be made explicit, wherever it is that
documentation for classifiers is provided.
I don't recall having seen any such
5) represent all environment variables in Unicode strings,
including the ones that currently fail to decode.
(then do the same to file names, then drop the byte-oriented
file operations again)
Please, don't do that! Bytes are not characters!
And environment variables, command
On Dec 5, 2008, at 7:48 PM, Nick Coghlan wrote:
You can't display a non-decodable filename to the user, hence the user
will have no idea what they're working on. Non-filesystem related apps
have no business trying to deal with insane filenames.
Sigh, same arguments, all over again.
Again,
On Fri, Dec 5, 2008 at 19:22, Martin v. Löwis [EMAIL PROTECTED] wrote:
Please, don't do that! Bytes are not characters!
And environment variables, command line arguments, and file names
are not bytes, but characters.
On Windows NT, sure. On Unix they're still bytes no matter how much we
want
On Sat, 6 Dec 2008 12:47:45 pm Guido van Rossum wrote:
But I disagree that most of the cool possibilities they have heard
about are necessarily third party libraries. Python's standard
library has lots of stuff to offer.
+1 on that. I've been using Python for a decade now, and the first third
And environment variables, command line arguments, and file names
are not bytes, but characters.
On Windows NT, sure. On Unix they're still bytes no matter how much we
want them to be characters.
Only in the API of the OS itself. Treating them as bytes in the
application is a mistake. The
On Sat, 6 Dec 2008 11:48:27 am Nick Coghlan wrote:
Toshio Kuratomi wrote:
Nick Coghlan wrote:
...
Why? Most programs won't be able to do anything with it. And if
the program *can* do something with it... that's what the bytes
version of the APIs are for.
Nonsense. A program can do
Thomas Wouters [EMAIL PROTECTED] wrote:
Allow me to paraphrase glyph (with whom I'm in complete agreement, for what
it's worth): many newbies will be disappointed by Python if they start with
Python 3.0 and discover that most of the cool possibilities they had heard
about are 'being worked
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ulrich Eckhardt wrote:
On Friday 05 December 2008, Guido van Rossum wrote:
At the risk of bringing up something that was already rejected, let me
propose something that follows the path taken in 3.0 for filenames,
rather than doubling back:
For
On Sat, 6 Dec 2008 at 13:06, Steven D'Aprano wrote:
Applications can deal with such weird file names. KDE's file manager
(konqueror) and file selection dialog both show the character as a
small square, presumably the font's missing character glyph, and KDE
apps can open and save the file. Still
On 5 Dec, 06:10 pm, [EMAIL PROTECTED] wrote:
On Thu, Dec 4, 2008 at 11:27 PM, [EMAIL PROTECTED] wrote:
With all due respect, for me, library support and serious use are
synonymous.
Glyph, I cannot have a discussion with you if every single post of
yours is longer than my combined daily
Nick Coghlan writes:
True, but it's still a fairly important problem to have a solution to.
Even internally in large organisations there can be some pretty insane
environments as cruft accumulates over the years.
MA and globalization makes it inevitable.
Toshio will remember the Mizuho
Martin v. Löwis writes:
5) represent all environment variables in Unicode strings,
including the ones that currently fail to decode.
(then do the same to file names, then drop the byte-oriented
file operations again)
Please, don't do that! Bytes are not characters!
On 01:47 am, [EMAIL PROTECTED] wrote:
In spite of Python being a programming language, there is a difference
between 'casual user of the language' and 'library developer'; 3.0 is
certainly a must for all actual library developers, and I'm sure most
of
them know about 3.0 by now. We're talking
There has been some discussion here that users should use the str or
byte function variant based on what is relevant to their system, for
example when getting a list of file names or opening a file. That
thought process really doesn't do much for those of us that write code
that needs to run on
74 matches
Mail list logo
