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 t
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
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
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 hav
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 unicod
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 anythin
On Thu, Jan 20, 2011 at 01:43:03PM -0500, Alexander Belopolsky wrote:
> On Thu, Jan 20, 2011 at 12:44 PM, Toshio Kuratomi wrote:
> > .. My examples that you're replying to involve two "properly
> > configured" OS's. The Linux workstations are configured with a
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 var
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
> > i
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
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
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 wrote:
> > > [Sandro Tosi, 2011-03-02]
> > >> On Wed, Mar 2, 2011 at 10:01, Piotr Ożarowski wrote:
> > >> > I co-maintain with Matthias a package t
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 rec
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
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
> wrote:
> > That (below) is not distutils it is setuptools. distutils just uses
> > `scripts=[...]`, which annoyingly *doesn't* work with setuptools.
>
> Right; distutils scripts are just
On Tue, Mar 08, 2011 at 08:25:50AM +1000, Nick Coghlan wrote:
> On Tue, Mar 8, 2011 at 1:30 AM, Barry Warsaw 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
> >&g
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, d
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
> 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 either the Python
On Mon, Mar 21, 2011 at 09:06:22PM -0400, David Malcolm wrote:
>
> Other ideas that occur:
> - does rpmlint check for encoding yet?
> - what to do e.g. about canonicalization? What happens if one rpm
> provide a feature named "café" (where the "é" is U+00E9) and another rpm
> requires a featu
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
On Wed, Mar 30, 2011 at 08:36:43AM +0200, Lennart Regebro wrote:
> On Wed, Mar 30, 2011 at 07:54, Toshio Kuratomi wrote:
> > Lennart is missing that you just need to use the same encoding
> > + surrogateescape (or stick with bytes) for decoding the byte strings that
> &
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 coul
On Tue, Jun 28, 2011 at 03:46:12PM +0100, Paul Moore wrote:
> On 28 June 2011 14:43, Victor Stinner 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 without an explicit e
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
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/issue4
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 :-)
>
> I
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 fri
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
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, th
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 silen
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()
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 t
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 soft
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
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
>
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
Guido van Rossum wrote:
> On Sat, Dec 6, 2008 at 10:53 AM, <[EMAIL PROTECTED]> wrote:
>> I find it interesting to note that the only users in this discussion who
>> actually have these problems in real life all have this attitude. It is
>> expected that in an imperfect world we will have imperfe
[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 f
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 co
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 spec
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
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 (ot
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 le
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-kn
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 exp
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
> > >> with
I have some similar code in kitchen:
http://packages.python.org/kitchen/api-overview.html
It wasn't as ambitious as your initial goals sound (I was only working on
pulling out what was necessary for what people requested rather than an
all-inclusive set of changes). You're welcome to join me and
On Tue, Oct 11, 2011 at 12:22:12AM -0400, Terry Reedy wrote:
> On 10/10/2011 4:21 PM, Giampaolo Rodolà wrote:
> >Thanks everybody for your feedback.
> >I created a gcode project here:
> >http://code.google.com/p/pycompat/
>
> This project will be easier if the test suite for a particular
> functio
On Tue, Oct 11, 2011 at 01:49:43PM +0100, Michael Foord wrote:
> On 10/10/2011 21:21, Giampaolo Rodolà wrote:
> >
> >Toshio Kuratomi wrote:
> >>I have a need to support a small amount of code as far back as python-2.3
> >>I don't suppose you're inter
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 t
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 SU
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 ta
On Thu, Jan 05, 2012 at 08:35:57PM +, Paul Moore wrote:
> On 5 January 2012 19:33, David Malcolm 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
> > turn the
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', Provi
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
On Tue, Oct 16, 2012 at 11:27:24AM +0200, Antoine Pitrou wrote:
> On Tue, 16 Oct 2012 05:05:23 -0400
> Trent Nelson wrote:
> > On Tue, Oct 16, 2012 at 01:43:37AM -0700, Charles-François Natali wrote:
> > > > My understanding is that we use a specific version of autoconf.
> > > > The reason is that
On Mon, Nov 19, 2012 at 07:49:41PM -0500, Donald Stufft wrote:
> Other languages seem to get along fine without it. Even the OS
> managers which have it don't allow it to be used to masquerade
> as another project, only to make generic virtual packages (e.g. "email").
>
I'm not sure this assertion
On Tue, Nov 20, 2012 at 06:43:32PM -0500, Daniel Holth wrote:
> No. We trust the packages we install, including the way they decide to use
> the metadata. A bad package could delete all our files or cause dependency
> resolution to fail. Mostly they won't.
>
Agreed. And this is closer to the way
On Wed, Dec 05, 2012 at 02:46:11AM -0500, Donald Stufft wrote:
> On Wednesday, December 5, 2012 at 2:13 AM, PJ Eby wrote:
>
> On Mon, Dec 3, 2012 at 2:43 PM, Daniel Holth wrote:
>
> How to use Obsoletes:
>
> The author of B decides A is obsolete.
>
> A releases an e
On Wed, Dec 05, 2012 at 07:34:41PM -0500, PJ Eby wrote:
> On Wed, Dec 5, 2012 at 6:07 PM, Donald Stufft wrote:
>
> Nobody has actually proposed a better one, outside of package renaming
> -- and that example featured an author who could just as easily have
> used an obsoleted-by field.
>
How abo
On Fri, Dec 07, 2012 at 01:18:40AM -0500, PJ Eby wrote:
> On Thu, Dec 6, 2012 at 1:49 AM, Toshio Kuratomi wrote:
> > On Wed, Dec 05, 2012 at 07:34:41PM -0500, PJ Eby wrote:
> >> On Wed, Dec 5, 2012 at 6:07 PM, Donald Stufft
> >> wrote:
> >>
> >&
On Sun, Dec 09, 2012 at 01:51:09PM +1100, Chris Angelico wrote:
> On Sun, Dec 9, 2012 at 1:11 PM, Steven D'Aprano wrote:
> > Why would a software package called "Spam" install a top-level module called
> > "Jam" rather than "Spam"? Isn't the whole point of Python packages to solve
> > this namespa
On Sun, Dec 09, 2012 at 12:48:45AM -0500, PJ Eby wrote:
>
> Do any of the distro folks know of a Python project tagged as
> conflicting with another for their distro, where the conflict does
> *not* involve any files in conflict?
>
In Fedora we do work to avoid most types of Conflicts (backportin
On Fri, Dec 7, 2012 at 10:46 PM, PJ Eby wrote:
>
> In any case, as I said before, I don't have an issue with the fields
> all being declared as being for informational purposes only. My issue
> is only with recommendations for automated tool behavior that permit
> one project's author to exercis
101 - 170 of 170 matches
Mail list logo
