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
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
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
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
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
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
[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-
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
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
.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
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
>
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
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
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
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
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
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
+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
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
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
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
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
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
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
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
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
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
27 matches
Mail list logo
