Oleg Broytmann wrote:
On Fri, Jan 23, 2009 at 02:35:01PM -0500, rdmur...@bitdance.com wrote:
Given that a Unix OS can't know what encoding a filename is in (*),
I can't see that one could practically implement a Unix FTP server
in any other way.
Can you believe there is a well-known
Antoine Pitrou wrote:
Steven D'Aprano steve at pearwood.info writes:
It depends on what you mean by temporary.
Applications like OpenOffice can sometimes recover from an application
crash or even a systems crash and give you the opportunity to restore
the temporary files that were left
Martin v. Löwis wrote:
Something that doesn't require deterministicly named tempfiles was Ted
T'so's explanation linked to earlier.
read data from important file
modify data
create tempfile
write data to tempfile
*sync tempfile to disk*
mv tempfile to filename of important file
The sync
Martin v. Löwis wrote:
The sync is necessary to ensure that the data is written to the disk
before the old file overwrites the new filename.
You still wouldn't use the tempfile module in that case. Instead, you
would create a regular file, with the name base on the name of the
important file.
Martin v. Löwis wrote:
auto-delete is one of the nice features of tempfile. Another feature
which is entirely appropriate to this usage, though, though, is creation
of a non-conflicting filename.
Ok. In that use case, however, it is completely irrelevant whether the
tempfile module calls
Stephen J. Turnbull wrote:
Chris Withers writes:
- debian has an outdated and/or broken version of your package.
True, but just as for the package system you are advocating, it's
quite easy to set up your apt to use third-party repositories of
Debian-style packages. The question is
Steve Holden wrote:
Seems to me that while all this is fine for developers and Python users
it's completely unsatisfactory for people who just want to use Python
applications. For them it's much easier if each application comes with
all dependencies including the interpreter.
This may seem
David Cournapeau wrote:
2009/3/24 Toshio Kuratomi a.bad...@gmail.com:
Steve Holden wrote:
Seems to me that while all this is fine for developers and Python users
it's completely unsatisfactory for people who just want to use Python
applications. For them it's much easier if each application
Tres Seaver wrote:
David Cournapeau wrote:
I am afraid that distutils, and
setuptools, are not really the answer to the problem, since while they
may (as intended) guarantee that Python applications can be installed
uniformly across different platforms they also more or less guarantee
that
David Cournapeau wrote:
On Wed, Mar 25, 2009 at 1:45 AM, Toshio Kuratomi a.bad...@gmail.com
wrote:
David Cournapeau wrote:
2009/3/24 Toshio Kuratomi a.bad...@gmail.com:
Steve Holden wrote:
Seems to me that while all this is fine for developers and Python
users
it's completely unsatisfactory
Barry Warsaw wrote:
Tools like setuptools, zc.buildout, etc. seem great for developers but
not very good for distributions. At last year's Pycon I think there was
agreement from the Linux distributors that distutils, etc. just wasn't
very useful for them.
It's decent for modules but has
David Cournapeau wrote:
I won't argue for setuptools' implementation of multi-version. It
sucks. But multi-version can be done well. Sonames in C libraries are
a simple system that does this better.
I would say simplistic instead of simple :) what works for C won't
necessarily work for
Guido van Rossum wrote:
On Wed, Mar 25, 2009 at 9:40 PM, Tarek Ziadé ziade.ta...@gmail.com wrote:
I think Distutils (and therefore Setuptools) should provide some APIs
to play with special files (like resources) and to mark them as being
special,
no matter where they end up in the target
Guido van Rossum wrote:
2009/3/26 Toshio Kuratomi a.bad...@gmail.com:
Guido van Rossum wrote:
On Wed, Mar 25, 2009 at 9:40 PM, Tarek Ziadé ziade.ta...@gmail.com wrote:
I think Distutils (and therefore Setuptools) should provide some APIs
to play with special files (like resources) and to mark
Robert Collins wrote:
Certainly, import time is part of it:
robe...@lifeless-64:~$ python -m timeit -s 'import sys; import
bzrlib.errors' del sys.modules['bzrlib.errors']; import bzrlib.errors
10 loops, best of 3: 18.7 msec per loop
(errors.py is 3027 lines long with 347 exception
Greg Ewing wrote:
Steven Bethard wrote:
That's an unfortunate decision. When the 2.X line stops being
maintained (after 2.7 maybe?) we're going to be stuck with the 3
suffix forever for the real Python.
I don't see why we have to be stuck with it forever.
When 2.x has faded into the
Glenn Linderman wrote:
On approximately 4/24/2009 11:40 AM, came the following characters from
And so my encoding (1) doesn't alter the data stream for any valid
Windows file name, and where the naivest of users reside (2) doesn't
alter the data stream for any Posix file name that was encoded
Terry Reedy wrote:
Is NUL \0 allowed in POSIX file names? If not, could that be used as an
escape char. If it is not legal, then custom translated strings that
escape in the wild would raise a red flag as soon as something else
tried to use them.
AFAIK NUL should be okay but I haven't
Zooko O'Whielacronx wrote:
On Apr 28, 2009, at 6:46 AM, Hrvoje Niksic wrote:
If you switch to iso8859-15 only in the presence of undecodable UTF-8,
then you have the same round-trip problem as the PEP: both b'\xff' and
b'\xc3\xbf' will be converted to u'\u00ff' without a way to
unambiguously
Martin v. Löwis wrote:
Since the serialization of the Unicode string is likely to use UTF-8,
and the string for such a file will include half surrogates, the
application may raise an exception when encoding the names for a
configuration file. These encoding exceptions will be as rare as the
Thomas Breuel wrote:
Not for me (I am using Python 2.6.2).
f = open(chr(255), 'w')
Traceback (most recent call last):
File stdin, line 1, in module
IOError: [Errno 22] invalid mode ('w') or filename: '\xff'
You can get the same error on Linux:
$ python
On Wed, Nov 23, 2011 at 01:41:46AM +0900, Stephen J. Turnbull wrote:
Barry Warsaw writes:
Hopefully, we're going to be making a dent in that in the next version of
Ubuntu.
This is still a big mess in Gentoo and MacPorts, though. MacPorts
hasn't done anything about ceating a
On Tue, Nov 22, 2011 at 08:27:24PM -0800, Raymond Hettinger wrote:
On Nov 22, 2011, at 7:50 PM, Larry Hastings wrote:
But look! I'm already practicing: NO YOU CAN'T CHECK THAT IN. How's that?
Needs work?
You could try a more positive leadership style: THAT LOOKS GREAT, I'M SURE
On Thu, Dec 22, 2011 at 02:49:06AM +0100, Victor Stinner wrote:
Do people still have to use this in commercial environments or is
everyone on 2.6+ nowadays?
At work, we are still using Python 2.5. Six months ago, we started a
project to upgrade to 2.7, but we have now more urgent tasks, so
On Thu, Jan 05, 2012 at 08:35:57PM +, Paul Moore wrote:
On 5 January 2012 19:33, David Malcolm dmalc...@redhat.com wrote:
We have similar issues in RHEL, with the Python versions going much
further back (e.g. 2.3)
When backporting the fix to ancient python versions, I'm inclined to
On Sat, Feb 11, 2012 at 04:32:56PM +1000, Nick Coghlan wrote:
This would then be seen by pydoc and help(), as well as being amenable
to programmatic inspection.
Would using
warnings.warn('This is a provisional API and may change radically from'
' release to release',
On Wed, Jun 13, 2012 at 01:58:10PM -0400, R. David Murray wrote:
OK, but you didn't answer the question :). If I understand correctly,
everything you said applies to *writing* the bytecode, not reading it.
So, is there any reason to not use the .pyo file (if that's all that is
around)
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 :-)
I have a specific problem with os.environ and a somewhat less important
architectural issue with
Adam Olsen wrote:
On Thu, Dec 4, 2008 at 1:02 PM, Toshio Kuratomi [EMAIL PROTECTED] wrote:
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
Adam Olsen wrote:
On Thu, Dec 4, 2008 at 2:09 PM, André Malo [EMAIL PROTECTED] wrote:
* Adam Olsen wrote:
On Thu, Dec 4, 2008 at 1:02 PM, Toshio Kuratomi [EMAIL PROTECTED]
wrote:
I opened up bug http://bugs.python.org/issue4006 a while ago and it was
suggested in the report that it's
Terry Reedy wrote:
Toshio Kuratomi wrote:
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 :-)
It does you no good and (and will irritate
Adam Olsen wrote:
On Thu, Dec 4, 2008 at 2:19 PM, Nick Coghlan [EMAIL PROTECTED] wrote:
Toshio Kuratomi wrote:
The bug report I opened suggests creating a PEP to address this issue.
I think that's a good idea for whether os.listdir() and friends should
be changed to raise an exception
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
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
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
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
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
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
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
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
Nick Coghlan wrote:
Toshio Kuratomi wrote:
Nonsense. A program can do tons of things with a non-decodable
filename. Where it's limited is non-decodable filedata.
You can't display a non-decodable filename to the user, hence the user
will have no idea what they're working on. Non
Bugbee, Larry wrote:
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
[EMAIL PROTECTED] wrote:
On 06:07 am, [EMAIL PROTECTED] wrote:
Most apps aren't file managers or ftp clients but when they interact
with files (for instance, a file selection dialog) they need to be able
to show the user all the relevant files. So on an app-by-app basis the
need for this
Guido van Rossum wrote:
On Mon, Dec 8, 2008 at 12:07 PM, [EMAIL PROTECTED] wrote:
On Mon, 8 Dec 2008 at 11:25, Guido van Rossum wrote:
But I'm happy with just issuing a warning by default. That would mean
it doesn't fail silently, but neither does it crash. Seems like the
best compromise
James Y Knight wrote:
On Dec 9, 2008, at 6:04 AM, Anders J. Munch wrote:
The typical application will just obliviously use os.listdir(dir) and
get the default elide-and-warn behaviour for un-decodable names. That
rare special application
I guess this is a new definition of rare special
Adam Olsen wrote:
On Thu, Dec 11, 2008 at 6:55 PM, Stephen J. Turnbull step...@xemacs.org
wrote:
Unfortunately, even programmers experienced in I18N like Martin, and
those with intuition-that-has-the-force-of-lawwink like Guido,
express deliberate disbelief on this point. They say that
Adam Olsen wrote:
A half-broken setup is still a broken setup. Eventually you have to
tell people to stop screwing around and pick one encoding.
But it's not a broken setup. It's the way the world is because people
share things with each other.
I doubt that UTF-16 is used very much (other
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
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
On Mon, Jun 21, 2010 at 09:57:30AM -0400, Barry Warsaw wrote:
On Jun 21, 2010, at 09:37 AM, Arc Riley wrote:
Also, under where it mentions that most OS's do not include Python 3, it
should be noted which have good support for it. Gentoo (for example) has
excellent support for Python 3,
On Mon, Jun 21, 2010 at 11:43:07AM -0400, Barry Warsaw wrote:
On Jun 21, 2010, at 10:20 PM, Nick Coghlan wrote:
Something that may make sense to ease the porting process is for some
of these on the boundary I/O related string manipulation functions
(such as os.path.join) to grow encoding
On Tue, Jun 22, 2010 at 01:08:53AM +0900, Stephen J. Turnbull wrote:
Lennart Regebro writes:
2010/6/21 Stephen J. Turnbull step...@xemacs.org:
IMO, the UI is right. Something like the above ought to work.
Right. That said, many times when you want to do urlparse etc they
might
On Mon, Jun 21, 2010 at 01:24:10PM -0400, P.J. Eby wrote:
At 12:34 PM 6/21/2010 -0400, Toshio Kuratomi wrote:
What do you think of making the encoding attribute a mandatory part of
creating an ebyte object? (ex: ``eb = ebytes(b, 'euc-jp')``).
As long as the coercion rules force str+ebytes
On Mon, Jun 21, 2010 at 02:46:57PM -0400, P.J. Eby wrote:
At 02:58 AM 6/22/2010 +0900, Stephen J. Turnbull wrote:
Nick alluded to the The One Obvious Way as a change in architecture.
Specifically: Decode all bytes to typed objects (str, images, audio,
structured objects) at input. Do no
On Mon, Jun 21, 2010 at 04:09:52PM -0400, P.J. Eby wrote:
At 03:29 PM 6/21/2010 -0400, Toshio Kuratomi wrote:
On Mon, Jun 21, 2010 at 01:24:10PM -0400, P.J. Eby wrote:
At 12:34 PM 6/21/2010 -0400, Toshio Kuratomi wrote:
What do you think of making the encoding attribute a mandatory part
On Mon, Jun 21, 2010 at 04:52:08PM -0500, John Arbash Meinel wrote:
...
IOW, if you're producing output that has to go into another system
that doesn't take unicode, it doesn't matter how
theoretically-correct it would be for your app to process the data in
unicode form. In that case,
On Tue, Jun 22, 2010 at 11:58:57AM +0900, Stephen J. Turnbull wrote:
Toshio Kuratomi writes:
One comment here -- you can also have uri's that aren't decodable into
their
true textual meaning using a single encoding.
Apache will happily serve out uris that have utf-8, shift-jis
On Tue, Jun 22, 2010 at 08:31:13PM +0900, Stephen J. Turnbull wrote:
Toshio Kuratomi writes:
unicode handling redesign. I'm stating my reading of the RFC not to defend
the use case Philip has, but because I think that the outlook that non-text
uris (before being percentencoded
On Wed, Jun 23, 2010 at 09:36:45PM +0200, Antoine Pitrou wrote:
On Wed, 23 Jun 2010 14:23:33 -0400
Tres Seaver tsea...@palladion.com wrote:
- - the slow adoption / porting rate of major web frameworks and libraries
to Python 3.
Some of the major web frameworks and libraries have a ton
On Wed, Jun 23, 2010 at 11:35:12PM +0200, Antoine Pitrou wrote:
On Wed, 23 Jun 2010 17:30:22 -0400
Toshio Kuratomi a.bad...@gmail.com wrote:
Note that this assumption seems optimistic to me. I started talking to
Graham
Dumpleton, author of mod_wsgi a couple years back because mod_wsgi
On Tue, Jul 06, 2010 at 10:10:09AM +0300, Nir Aides wrote:
I take ...running off with the good stuff and selling it for profit to mean
creating derivative work and commercializing it as proprietary code which
you
can not do with GPL licensed code. Also, while the GPL does not prevent
On Fri, Aug 13, 2010 at 07:48:22AM +1000, Nick Coghlan wrote:
2010/8/12 Éric Araujo mer...@netwok.org:
Choosing an arbitrary location we think is good on every system is fine
and non risky I think, as long as Python let the various distribution
change those paths though configuration.
On Thu, Sep 16, 2010 at 09:52:48AM -0400, Barry Warsaw wrote:
On Sep 16, 2010, at 11:28 PM, Nick Coghlan wrote:
There are some APIs that should be able to handle bytes *or* strings,
but the current use of string literals in their implementation means
that bytes don't work. This turns out to
On Thu, Sep 16, 2010 at 10:56:56AM -0700, Guido van Rossum wrote:
On Thu, Sep 16, 2010 at 10:46 AM, Martin (gzlist) gzl...@googlemail.com
wrote:
On 16/09/2010, Guido van Rossum gu...@python.org wrote:
In all cases I can imagine where such polymorphic functions make
sense, the necessary
On Wed, Sep 29, 2010 at 01:23:24PM -0700, Guido van Rossum wrote:
On Wed, Sep 29, 2010 at 1:12 PM, Brett Cannon br...@python.org wrote:
On Wed, Sep 29, 2010 at 12:03, Guido van Rossum gu...@python.org wrote:
A problem with that is that we regularly make matching improvements to
upload.py
On Fri, Oct 08, 2010 at 10:26:36AM -0400, Barry Warsaw wrote:
On Oct 08, 2010, at 03:22 PM, Tarek Ziadé wrote:
Yes that what I was thinking about -- I am not too worried about this,
since every Linux deals with the 'more than one python installed'
case.
Kind of. wink but anyway...
On Fri, Oct 08, 2010 at 05:12:44PM +0200, Antoine Pitrou wrote:
On Fri, 8 Oct 2010 11:04:35 -0400
Toshio Kuratomi a.bad...@gmail.com wrote:
In the larger universe of programs, it might make for more intuitive
remembering of the command to use a prefix (either py or python) though
On Thu, Oct 21, 2010 at 12:00:40PM -0400, Barry Warsaw wrote:
On Oct 20, 2010, at 02:11 AM, Victor Stinner wrote:
I plan to fix Python documentation: specify the encoding used to decode all
byte string arguments of the C API. I already wrote a draft patch: issue
#9738. This lack of
On Fri, Oct 29, 2010 at 11:12:28AM -0700, geremy condra wrote:
On Thu, Oct 28, 2010 at 11:55 PM, Glyph Lefkowitz
Let's take PyPI numbers as a proxy. There are ~8000 packages with a
Programming Language::Python classifier. There are ~250 with Programming
Langauge::Python::3. Roughly
On Tue, Nov 09, 2010 at 11:46:59AM +1100, Ben Finney wrote:
Ron Adam r...@ronadam.com writes:
def _publicly_documented_private_api():
Not sure why you would want to do this
instead of using comments.
...
Because the docstring is available at the interpreter
On Tue, Nov 09, 2010 at 01:49:01PM -0500, Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/08/2010 06:26 PM, Bobby Impollonia wrote:
This does hurt because anyone who was relying on import * to get a
name which is now omitted from __all__ is going to upgrade and
On Wed, Dec 01, 2010 at 10:06:24PM -0500, Alexander Belopolsky wrote:
On Wed, Dec 1, 2010 at 9:53 PM, Terry Reedy tjre...@udel.edu wrote:
..
Does Sphinx run on PY3 yet?
It does, but see issue10224 for details.
http://bugs.python.org/issue10224
Also, docutils has an unported module.
On Fri, Dec 03, 2010 at 11:52:41PM +0100, Martin v. Löwis wrote:
Am 03.12.2010 23:48, schrieb Éric Araujo:
But I'm not interested at all in having it in distutils2. I want the
Python build itself to use it, and alas, I can't because of the freeze.
You can’t in 3.2, true. Neither can you in
On Wed, Jan 19, 2011 at 04:40:24PM -0500, Terry Reedy wrote:
On 1/19/2011 4:05 PM, Simon Cross wrote:
I have no problem with non-ASCII module identifiers being valid
syntax. It's a question of whether attempting to translate a non-ASCII
If the names are the same, ie, produced with the same
On Wed, Jan 19, 2011 at 07:11:52PM -0500, James Y Knight wrote:
On Jan 19, 2011, at 6:44 PM, Toshio Kuratomi wrote:
This problem of which encoding to use is a problem that can be
seen on UNIX systems even now. Try this:
echo 'print(hi)' café.py
convmv -f utf-8 -t latin1 café.py
On Thu, Jan 20, 2011 at 01:26:01AM +0100, Victor Stinner wrote:
Le mercredi 19 janvier 2011 à 15:44 -0800, Toshio Kuratomi a écrit :
Additionally, many unix filesystem don't specify a filesystem encoding for
filenames; they deal in legal and illegal bytes which could lead to
troubles
On Thu, Jan 20, 2011 at 03:51:05AM +0100, Victor Stinner wrote:
For a lesson at school, it is nice to write examples in the
mother language, instead of using raw english with ASCII identifiers
and filenames.
Then use this::
import cafe as café
When you do things this way you do not have to
On Wed, Jan 19, 2011 at 09:02:17PM -0800, Glenn Linderman wrote:
On 1/19/2011 8:39 PM, Toshio Kuratomi wrote:
use this::
import cafe as café
When you do things this way you do not have to translate between unknown
encodings into unicode. Everything is within python
On Thu, Jan 20, 2011 at 12:51:29PM +0100, Victor Stinner wrote:
Le mercredi 19 janvier 2011 à 20:39 -0800, Toshio Kuratomi a écrit :
Teaching students to write non-portable code (relying on filesystem encoding
where your solution is, don't upload to pypi anything that has non-ascii
On Thu, Jan 20, 2011 at 01:43:03PM -0500, Alexander Belopolsky wrote:
On Thu, Jan 20, 2011 at 12:44 PM, Toshio Kuratomi a.bad...@gmail.com wrote:
.. My examples that you're replying to involve two properly
configured OS's. The Linux workstations are configured with a UTF-8
locale
On Thu, Jan 20, 2011 at 03:27:08PM -0500, Glyph Lefkowitz wrote:
On Jan 20, 2011, at 11:46 AM, Guido van Rossum wrote:
Same here. *Most* code will never be shared, or will only be shared
between users in the same community. When it goes wrong it's also a
learning opportunity. :-)
On Tue, Jan 25, 2011 at 10:22:41AM +0100, Xavier Morel wrote:
On 2011-01-25, at 04:26 , Toshio Kuratomi wrote:
* If you can pick a set of encodings that are valid (utf-8 for Linux and
MacOS
HFS+ uses UTF-16 in NFD (actually in an Apple-specific variant of NFD). Right
here you've
On Wed, Jan 26, 2011 at 11:24:54AM +0900, Stephen J. Turnbull wrote:
Toshio Kuratomi writes:
On Linux there's no defined encoding that will work; file names are just
bytes to the Linux kernel so based on people's argument that the convention
is and should be that filenames are utf-8
On Wed, Jan 26, 2011 at 11:12:02AM +0100, Martin v. Löwis wrote:
Am 26.01.2011 10:40, schrieb Victor Stinner:
Le lundi 24 janvier 2011 à 19:26 -0800, Toshio Kuratomi a écrit :
Why not locale:
* Relying on locale is simply not portable. (...)
* Mixing of modules from different locales
On Wed, Mar 02, 2011 at 01:14:32AM +0100, Martin v. Löwis wrote:
I think a PEP would help, but in this case I would request that before
the PEP gets written (it can be a really short one!) somebody actually
go out and get consensus from a number of important distros. Besides
Barry, do we
On Thu, Mar 03, 2011 at 09:55:25AM +0100, Piotr Ożarowski wrote:
[Guido van Rossum, 2011-03-02]
On Wed, Mar 2, 2011 at 4:56 AM, Piotr Ożarowski pi...@debian.org wrote:
[Sandro Tosi, 2011-03-02]
On Wed, Mar 2, 2011 at 10:01, Piotr Ożarowski pi...@debian.org wrote:
I co-maintain with
On Thu, Mar 03, 2011 at 09:11:40PM -0500, Barry Warsaw wrote:
On Mar 03, 2011, at 02:17 PM, David Malcolm wrote:
On a related note, we have a number of scripts packaged across the
distributions with a shebang line that reads:
#!/usr/bin/env python
which AIUI follows upstream
On Thu, Mar 03, 2011 at 09:46:23PM -0500, Barry Warsaw wrote:
On Mar 03, 2011, at 09:08 AM, Toshio Kuratomi wrote:
Thinking outside of the box, I can think of something that would satisfy
your requirements but I don't know how appropriate it is for upstream python
to ship with. Stop
On Fri, Mar 04, 2011 at 01:56:39PM -0500, Barry Warsaw wrote:
I don't agree that /usr/bin/python should not be installed. The draft PEP
language hits the right tone IMHO, and I would favor /usr/bin/python pointing
to /usr/bin/python2 on Debian, but primarily used only for the interactive
On Fri, Mar 04, 2011 at 12:56:16PM -0500, Fred Drake wrote:
On Fri, Mar 4, 2011 at 12:35 PM, Michael Foord
fuzzy...@voidspace.org.uk wrote:
That (below) is not distutils it is setuptools. distutils just uses
`scripts=[...]`, which annoyingly *doesn't* work with setuptools.
Right;
On Tue, Mar 08, 2011 at 08:25:50AM +1000, Nick Coghlan wrote:
On Tue, Mar 8, 2011 at 1:30 AM, Barry Warsaw ba...@python.org wrote:
On Mar 04, 2011, at 12:00 PM, Toshio Kuratomi wrote:
Actually, my post was saying that these two can be decoupled. ie: It's
possible to not have /usr/bin
On Tue, Mar 08, 2011 at 06:43:19PM -0800, Glenn Linderman wrote:
On 3/8/2011 12:02 PM, Terry Reedy wrote:
On 3/7/2011 9:31 PM, Reliable Domains wrote:
The launcher need not be called python.exe, and maybe it would be
better called #@launcher.exe (or similar, depending
On Fri, Mar 18, 2011 at 07:40:43PM -0700, Guido van Rossum wrote:
On Fri, Mar 18, 2011 at 7:28 PM, Greg Ewing greg.ew...@canterbury.ac.nz
wrote:
Tres Seaver wrote:
I'm not even sure why you would want __version__ in 99% of modules: in
the ordinary cases, a module's version should be
On Tue, Mar 29, 2011 at 07:23:25PM +0100, Michael Foord wrote:
Hey all,
Not sure how real the security risk is here:
http://blog.omega-prime.co.uk/?p=107
Basically he is saying that if you store a list of blacklisted files
with names encoded in big-5 (or some other non-utf8
On Tue, Mar 29, 2011 at 10:55:47PM +0200, Victor Stinner wrote:
Le mardi 29 mars 2011 à 22:40 +0200, Lennart Regebro a écrit :
The lesson here seems to be if you have to use blacklists, and you
use unicode strings for those blacklists, also make sure the string
you compare with doesn't have
On Wed, Mar 30, 2011 at 08:36:43AM +0200, Lennart Regebro wrote:
On Wed, Mar 30, 2011 at 07:54, Toshio Kuratomi a.bad...@gmail.com wrote:
Lennart is missing that you just need to use the same encoding
+ surrogateescape (or stick with bytes) for decoding the byte strings that
you
On Wed, Apr 06, 2011 at 11:04:08AM +0200, John Arbash Meinel wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
...
#. ``__version_info__`` SHOULD be of the format returned by PEP 386's
``parse_version()`` function.
The only reference to parse_version in PEP 386 I could find was
On Tue, Jun 28, 2011 at 03:46:12PM +0100, Paul Moore wrote:
On 28 June 2011 14:43, Victor Stinner victor.stin...@haypocalc.com wrote:
As discussed before on this list, I propose to set the default encoding
of open() to UTF-8 in Python 3.3, and add a warning in Python 3.2 if
open() is called
On Fri, Aug 12, 2011 at 12:19:23PM -0400, Barry Warsaw wrote:
On Aug 12, 2011, at 01:10 PM, Nick Coghlan wrote:
1. Accept the reality of that situation, and propose a mechanism that
minimises the impact of the resulting ambiguity on end users of Python
by allowing developers to be explicit
On Wed, Oct 05, 2011 at 06:14:08PM +0200, Antoine Pitrou wrote:
Le mercredi 05 octobre 2011 à 18:12 +0200, Martin v. Löwis a écrit :
Not sure what you are using it for. If you need to extend the buffer
in case it is too small, there is absolutely no way this could work
without copies in
1 - 100 of 162 matches
Mail list logo
