Re: [Python-Dev] PEP 383: Non-decodable Bytes in System Character Interfaces

2009-04-25 Thread Zooko O'Whielacronx
Thanks for writing this PEP 383, MvL. I recently ran into this problem in Python 2.x in the Tahoe project [1]. The Tahoe project should be considered a good use case showing what some people need. For example, the assumption that a file will later be written back into the same local file

Re: [Python-Dev] PEP 383: Non-decodable Bytes in System Character Interfaces

2009-04-28 Thread Zooko O'Whielacronx
On Apr 28, 2009, at 6:46 AM, Hrvoje Niksic wrote: Are you proposing to unconditionally encode file names as iso8859-15, or to do so only when undecodeable bytes are encountered? For what it is worth, what we have previously planned to do for the Tahoe project is the second of these -- decod

Re: [Python-Dev] a suggestion ... Re: PEP 383 (again)

2009-04-28 Thread Zooko O'Whielacronx
On Apr 28, 2009, at 13:01 PM, Thomas Breuel wrote: (2) Should the default UTF-8 encoder for file system operations be allowed to generate illegal byte sequences? I think that's a definite no; if I set the encoding for a device to UTF-8, I never want Python to try to write illegal UTF-8 stri

Re: [Python-Dev] PEP 383 and GUI libraries

2009-04-30 Thread Zooko O'Whielacronx
Folks: My use case (Tahoe-LAFS [1]) requires that I am *able* to read arbitrary binary names from the filesystem and store them so that I can regenerate the same byte string later, but it also requires that I *know* whether what I got was a valid string in the expected encoding (which might be utf

Re: [Python-Dev] PEP 383 and GUI libraries

2009-05-01 Thread Zooko O'Whielacronx
Following-up to my own post to correct a major error: On Thu, Apr 30, 2009 at 11:44 PM, Zooko O'Whielacronx wrote: > Folks: > > My use case (Tahoe-LAFS [1]) requires that I am *able* to read arbitrary > binary names from the filesystem and store them so that I can regenerat

Re: [Python-Dev] PEP 383 and GUI libraries

2009-05-01 Thread Zooko O'Whielacronx
Folks: Being new to the use of gmail, I accidentally sent the following only to MvL and not to the list. He promptly replied with a helpful counterexample showing that my design can suffer collisions. :-) Regards, Zooko On Fri, May 1, 2009 at 10:38 AM, "Martin v. Löwis" wrote: >> >> Require

Re: [Python-Dev] PEP 383 and GUI libraries

2009-05-02 Thread Zooko O'Whielacronx
[cross-posting to python-dev and tahoe-dev] On Fri, May 1, 2009 at 8:12 PM, James Y Knight wrote: > > If I were designing a new system such as this, I'd probably just go for > utf8b *always*. Ah, this would be a very tempting possibility -- abandon all unix users who are slow to embrace our utf-

Re: [Python-Dev] PEP 383 and Tahoe [was: GUI libraries]

2009-05-04 Thread Zooko O'Whielacronx
Thank you for sharing your extensive knowledge of these issues, SJT. On Sun, May 3, 2009 at 3:32 AM, Stephen J. Turnbull wrote: > Zooko O'Whielacronx writes: > > > However, it is moot because Tahoe is not a new system. It is > > currently at v1.4.1, has a str

Re: [Python-Dev] PEP 383 update: utf8b is now the error handler

2009-05-05 Thread Zooko O'Whielacronx
On Tue, May 5, 2009 at 8:57 AM, Stephen J. Turnbull wrote: > > 2.  The specification should state, and the discussion emphasize, that >    strings which were produced by surrogate replacement *must not* be >    used in data interchange with systems that do not specifically >    accept such strings

Re: [Python-Dev] .pth files are evil

2009-05-09 Thread Zooko O'Whielacronx
.pth files are why I can't easily use GNU stow with easy_install. If installing a Python package involved writing new files into the filesystem, but did not require reading, updating, and re-writing any extant files such as .pth files, then GNU stow would Just Work with easy_install the way it Just

Re: [Python-Dev] how GNU stow is complementary rather than alternative to distutils

2009-05-10 Thread Zooko O'Whielacronx
following-up to my own post to mention one very important reason why anyone cares: On Sun, May 10, 2009 at 12:04 PM, Zooko Wilcox-O'Hearn wrote: > It is a beautiful, elegant hack because it is sooo dumb.  It is also very > nice to use the same tool to manage packages written in any programming >

[Python-Dev] please consider changing --enable-unicode default to ucs4

2009-09-20 Thread Zooko O'Whielacronx
Dear Pythonistas: This issue causes serious problems. Users occasionally get binaries built for a compatible Linux and Python version but with a different UCS2-vs-UCS4 setting, and those users get mysterious memory corruption errors which are hard to diagnose. It is possible that these situation

Re: [Python-Dev] please consider changing --enable-unicode default to ucs4

2009-09-20 Thread Zooko O'Whielacronx
I'm sorry, I should have mentioned that I did read those archives before I posted my letter. That discussion was all about whether UCS2 or UCS4 is better. I consider that question to be mostly irrelevant to this issue, which is about compatibility for people who don't choose to configure that set

Re: [Python-Dev] please consider changing --enable-unicode default to ucs4

2009-09-20 Thread Zooko O'Whielacronx
On Sun, Sep 20, 2009 at 8:27 AM, Antoine Pitrou wrote: > > What "binaries" are you talking about? I mean extension modules with native code, which means .so shared library files on unix. > AFAIK, C extensions should fail loading when they have the wrong UCS2/4 > setting. That would be an impro

Re: [Python-Dev] please consider changing --enable-unicode default to ucs4

2009-09-20 Thread Zooko O'Whielacronx
On Sun, Sep 20, 2009 at 8:27 AM, Antoine Pitrou wrote: > For information, all Mandriva versions I've used until now have had their > Python's built with UCS2 (maxunicode == 65535). By the way, I was investigating this, and discovered an issue on the Mandriva tracker which suggests that they inten

Re: [Python-Dev] please consider changing --enable-unicode default to ucs4

2009-09-29 Thread Zooko O'Whielacronx
Dear MAL and python-dev: I failed to explain the problem that users are having. I will try again, and this time I will omit my ideas about how to improve things and just focus on describing the problem. Some users are having trouble using Python packages containing binary extensions on Linux. I

Re: [Python-Dev] [New-bugs-announce] [issue7064] Python 2.6.3 / setuptools 0.6c9: extension module builds fail with KeyError

2009-10-06 Thread Zooko O'Whielacronx
Here are three buildbot farms for three different projects that exercise various features of setuptools: build, install, sdist_dsc, bdist_egg, sdist, and various specific requirements that our projects have, such as the "Desert Island Build" in which setuptools is not allowed to download anything f

Re: [Python-Dev] a new setuptools release?

2009-10-07 Thread Zooko O'Whielacronx
+1 For a large number of people [1, 2, 3], setuptools is already a critical part of Python. Make it official. Let everyone know that future releases of Python will not break setuptools/Distribute, and that they can rely on backwards-compatibility with the myriad existing packages. Make the next

[Python-Dev] please consider changing --enable-unicode default to ucs4

2009-10-07 Thread Zooko O'Whielacronx
problem that is preventing people from distributing and using Python packages with binary extension modules on Linux. Regards, Zooko -- Forwarded message ------ From: Zooko O'Whielacronx Date: Sun, Sep 27, 2009 at 11:43 AM Subject: Re: [Python-Dev] please consider changing --enabl

Re: [Python-Dev] a new setuptools release?

2009-10-07 Thread Zooko O'Whielacronx
Thanks for the reply, MAL. How would we judge whether Distribute is ready for inclusion in the Python standard lib? Maybe if it has a few more releases, leaving a trail of "closed: fixed" issue tickets behind it? Regards, Zooko ___ Python-Dev mailing

Re: [Python-Dev] Python byte-compiled and optimized code

2009-10-07 Thread Zooko O'Whielacronx
You might be interested in the new PYTHONDONTWRITEBYTECODE environment variable supported as of Python 2.6. I personally think it is a great improvement. :-) Regards, Zooko ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailm

Re: [Python-Dev] Python 2.6.4rc2

2009-10-21 Thread Zooko O'Whielacronx
Barry: Do you know anything about this alleged regression in 2.6.3 with regard to the __doc__ property? https://bugs.edge.launchpad.net/ubuntu/+source/boost1.38/+bug/457688 Regards, Zooko ___ Python-Dev mailing list Python-Dev@python.org http://mail.p

Re: [Python-Dev] Possible language summit topic: buildbots

2009-10-27 Thread Zooko O'Whielacronx
Right, how do developers benefit from a buildbot? >From my experience (five large buildbots with many developers plus two with only a couple of developers), a buildbot does little good unless the tests are reliable and not too noisy. "Reliable" is best achieved by having tests be deterministic an

Re: [Python-Dev] 2.7 Release? 2.7 == last of the 2.x line?

2009-11-03 Thread Zooko O'Whielacronx
Folks: I really don't want to make anyone feel bad or to criticize, but I should mention that I have no plans to use Python 3 or to support Python 3. My best guess at this time is that the current projects that I'm involved in will still require Python 2 for the forseeable future (let's say 5 yea

Re: [Python-Dev] 2.7 Release? 2.7 == last of the 2.x line?

2009-11-04 Thread Zooko O'Whielacronx
Folks: It occurred to me to wonder why I haven't investigated how hard it would be to make my Python packages Python-3-compatible. That's right -- I haven't even looked closely. I couldn't even tell you off the top of my head what is in Python 3 that I would have to think about except for the ne

Re: [Python-Dev] mingw support?

2010-08-13 Thread Zooko O'Whielacronx
On Sat, Aug 7, 2010 at 2:14 PM, Steve Holden wrote: > There have certainly been demonstrations that Python can be compiled > with mingw, but as far as I am aware what's  missing is a developer > sufficiently motivated to integrate that build system into the > distributions and maintain it. It loo

Re: [Python-Dev] Goodbye

2010-09-23 Thread Zooko O'Whielacronx
Speaking as a frequent contributor of bug reports and an occasional contributor of patches, I must say that I feel like status quo of the tracker before Mark's work was discouraging. If there is a vast collection of abandoned tickets, it gives me the strong impression that my attempted contribution