understand how to fix
and that now I don't exactly remember:
http://mail.python.org/pipermail/distutils-sig/2009-January/010880.html
Regards,
Zooko
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
on to use the word "monotonic clock" to refer to the
second concept is that POSIX does so, but since Mac OS X, Solaris,
Windows, and C++ have all avoided following POSIX's mistake, I think
Python should too.
Regards,
Zooko
¹ http://mathworld.wolfram.com/MonotonicSequence.html
___
er* be right next to the flag, although he will be moving just as
fast as the flag is moving.
Runner E: no helicopter, no headset. He just proceeds at his own pace,
blissfully unaware of the exhortations of others.
Now: which ones of these five runners do you call "monoto
ou may
choose to go ahead, while making sure that the NTP servers are
authenticated, or you may choose to disable NTP on the control
platform, etc., but that choice might need to be made explicitly by
the operator, rather than automatically by the library.
Regards,
Zooko
___
a misunderstanding (doubtless due to the confusing
name "monotonic") to think that such a thing is offered by the
underlying platforms. We can choose to *call* it "monotonic",
following POSIX instead of calling it "steady", following C++.
Regards,
Zooko
7;t though about it very carefully, but that is actually
dangerous.
If someone has a use case which fits the "steady or else fall back to
wall clock" pattern, I would like to learn about it.
Regards,
Zooko
___
Python-Dev mailing list
Python
wall clock" clock (calendaring, displaying to a
user, timestamping). I'm not aware of any use case for "steady if
implemented, else wall-clock", and it sounds like a mistake to me.
Regards,
Zooko
___
Python-Dev mailing lis
continue to close tickets after he was
asked not to do so? I didn't see any quotes or timestamps showing what
happened or when.
Regards,
Zooko
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsu
maintain it.
It looks like quite a lot of activity on
http://bugs.python.org/issue3871 . I find it surprising that nobody
mentioned it before on this thread. Perhaps nobody who has been
posting to this thread was aware of this activity.
Regards,
Zooko
_
n 2.4 compatibility for the
next releases of most of my code.)
Regards,
Zooko
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
hat
issue in [3] were fixed then Python 3 would join Python 2 as a
language that can (with the CapPython extension) have
object-capability nature.
Regards,
Zooko
[1] http://bracha.org/Site/Newspeak.html
[2] http://jacaranda.org
[3]
http://lackingrhoticity.blogspot.com/2008/09/cappython-unbound-met
to think of what would happen if that policy were
automated -- any patch which caused any "supported" builder to go from
green to red would be automatically be reverted.)
Also, of course, this is mostly meaningless unless the code that is
being changed by the pa
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
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
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-D
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
next release of the distutils standard lib module
be Distribute.
(Perhaps some people will complain, but they can channel their energy
into improving the new distutils.)
Regards,
Zooko
[1] The majority of professional developers using Python rely on
setuptools to distribute and to use packages
o make a commit to our central darcs repository for Tahoe-LAFS,
pycryptopp, or zfec, and I don't want to do that to experiment with
new versions of setuptools/Distribute. Does anyone know how to use a
buildbot farm like this one to run tests without committing patches to
the central reposito
, improving the tools to handle incompatible packages
nicely would not make more packages compatible. Let's do both!
Improve tools to handle incompatible packages nicely, and encourage
everyone who compiles python on Linux to use the same UCS2/4
setting.
Thank you for your attention.
Regards,
Zook
ggests that they intend to switch to UCS4 in
the next release in order to avoid compatibility problems like these.
(Not because they think that UCS4 is better than UCS2.)
https://qa.mandriva.com/show_bug.cgi?id=48570
Regards,
Zooko
___
Python-Dev mailing
#x27;t interfere with
Mandriva's decision, right?
Regards,
Zooko
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
erience of Python on Linux.
I should mention that the reason I'm spending time on this right now
is that it is currently blocking me from being able to distribute
binaries of Python packages which will work for all of my Linux users.
Regards,
Zooko
___
t to the
compatible option.
Hm, I guess that means that it should default to UCS2 on Windows and Mac and
to UCS4 on Linux and Solaris.
Regards,
Zooko
Ubuntu 6.10 "edgy" i386: python: 2.4.4c1 (#2, Mar 7 2008, 03:03:38) [GCC 4.1.2
20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)], maxunico
ed in http://allmydata.org/trac/tahoe/ticket/628
("mtime" and "ctime": I don't think that word means what you think it
means.) where the Allmydata-Tahoe project is carefully unpicking the
mess we made for ourselves by confusing ctime with file-creation time.
This is ticket
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
ckages/easy_install.pth'. I'm
too dumb to deal with this conflict, so I give up.". If I understand
correctly, your (MvL's) suggestion that easy_install create a .pth
file named "easy_install-$PACKAGE-$VERSION.pth" instead of
"easy_install.pth" would i
writing of conflicting files in the target -- does
pip handle these?)
GNU stow does handle these issues.
Regards,
Zooko
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.
ay it Just Works with most things.
Regards,
Zooko
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On May 6, 2009, at 10:54 AM, Antoine Pitrou wrote:
Zooko Wilcox-O'Hearn zooko.com> writes:
I'm not thinking of API compatibility as much as data
compatibility -- someone used Python 3.1 to write down some
filenames, and now a few years later they are trying to use the
ility mode? I'm not thinking of API compatibility as much as
data compatibility -- someone used Python 3.1 to write down some
filenames, and now a few years later they are trying to use the
latest and greatest Python release to read those filenames...
Regar
uot; in f:
f += " (invalid encoding)"
(On top of that I would have to check for collisions, but that's out of scope.)
Regards,
Zooko
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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
he same local
filesystem in the same Python process". I'm not sure that it can help
if you are going to store the results of your os.listdir()
persistently or if you are going to transmit them over a network.
Indeed, using the results t
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&qu
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
I guess this means that PEP 383, which I have approved of and liked so
far in this discussion, would actually not help Tahoe at all and would
in fact harm Tahoe -- I would have to remember to detect and work-around
the automatic 'utf-8b' filesystem encoding when porting Tahoe to Pyt
it is possible to build a better system on top of POSIX.) Hopefully
David Wheeler's proposals to tighten the requirements in Linux
filesystems will catch on: [2].
Regards,
Zooko
[1] http://allmydata.org
[2] http://www.dwheeler.com/essays/fixing-unix-linux-filenames.html
__
7;)
u'\xff'
>>> '\xc3\xbf'.decode('iso-8859-15')
u'\xc3\xbf'
>>>
>>>
>>>
>>> '\xff'.decode('cp1252')
u'\xff'
>>> '\xc3\xbf'.decode('cp1252')
u'\xc3\xbf'
Regards
nd include that with the filename. This
expands the size of our filenames significantly, but it is the only
way to allow some future programmer to undo the damage of a falsely-
successful decoding. Here's our whole plan: [5].
Regards,
Zooko
[1] http://allmydata.org
[2] http://allmydat
u're
thinking of.
Regards,
Zooko
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
ay do with them.
"""
Regards,
Zooko
---
http://allmydata.org -- Tahoe, the Least-Authority Filesystem
http://allmydata.com -- back up all your files for $5/month
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.o
ashedformat/base32/
base32/base32.py
base32.c:
http://allmydata.org/source/z-base-32/trunk-hashedformat/base32/base32.c
Regards,
Zooko
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
h
On Jun 15, 2008, at 12:20 PM, zooko wrote:
So, it would be easy to change those two behaviors in order to use
this implementation. There are actually three implementations in
that file: one that is asymptotically O(1) for all operations
(using a double-linked list woven into the values of
uses a Python list to hold the order, so it is faster for small
enough dicts. The third implementation is an implementation that
someone else wrote that I included just for comparison purposes --
the comparison showed that each of mine was better.
d I like your counterproposals better, at least for now.
Directories, folders, or zip entries with __init__.py in them are
"package modules", and Python packages are "package distributions".
Regards,
Zooko
___
Python-Dev mai
tood by the programmers:
1. A "module" shall henceforth be the name for either a foo.py file
(a single-file module), or a directory with an __init__.py in it (a
directory module).
2. A "package" shall henceforth be the name of the thing that is
currently called a
mpatible with certain
easy_install traditions such as fetching new packages from the
internet at buildtime or installing into your system directory.
Regards,
Zooko
P.S. Two days ago I was able to remove twisted from the list of
"Manual Dependencies" that people have to be awar
fault, rather than .pyc files)
You are of course welcome to log in to that trac and update those
tickets yourself, but if you prefer not to then I will paste your
reasons into those tickets.
Regards,
Zooko
___
Python-Dev mailing list
Python-Dev@python.o
s by default
instead of .pyc files.
I've opened a ticket on my setuptools trac about this proposal:
http://allmydata.org/trac/setuptools/ticket/5 # binary eggs should
come with .py files by default, rather than .pyc files
Regards,
Zooko
___
Py
ntained. The latter appears to be usable, but
somewhat incomplete -- substantial manual labor is required to use it
successfully, as documented by my programming partner Brian Warner in
this ticket: [3].
Regards,
Zooko
[1] http://easy-deb.sourceforge.net/
[2] http://stdeb.python-hosting.c
e had to specifically choose
zip_safe=True in order to install eggs in zipped form.
I've opened a ticket on my setuptools trac:
http://allmydata.org/trac/setuptools/ticket/4
Regards,
Zooko
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.p
setuptools/easy_install to be more widely
accepted. This is best and most easily achieved by fixing the two
most frequent objections to setuptools/easy_install: 1. That you
can't conveniently install into an arbitrary directory, and 2. that
it subverts the meaning of your PYTHONPATH.
Rega
ng our source code to other programmers.
But no software is ever installed on our production servers unless
that software is in .deb form in an apt-gettable repository, and this
requirement is unlikely to change for the forseeable future.
Regards,
Zooko
_
On Mar 26, 2008, at 7:34 PM, Chris McDonough wrote:
> zooko wrote:
http://mail.python.org/pipermail/python-dev/2008-March/078243.html
>> Here is a simple proposal: make the standard Python "import"
>> mechanism notice eggs on the PYTHONPATH and insert them (into
rs.)
This also preserves most of the value of eggs for many use cases.
This is backward-compatible with most current use cases that rely on
eggs.
This is very likely forward-compatible with new schemes that are
currently being cooked up and will be deployed in the future.
s tool called "unzip"? I have done this -- accessed the
source code -- many times, and unzip suffices.
I don't know what else would be required in order to make an egg into
"a standard distutils-style installation". Until PJE's com
pact on their systems.
Perhaps relevant are my blog entries on how to use setuptools with
GNU stow:
https://zooko.com/log-2007.html#d2007-04-27-
distutils_or_setuptools_with_GNU_stow
https://zooko.com/log-2007.html#d2007-06-02-
distutils_or_setuptool
ble, and that our use of setuptools
plugins will eventually replace our GNUmakefile and thus remove our
dependency on GNUmake. That will leave only g++, Python, OpenSSL,
and Crypto++ as dependencies that a user has to manually deal with in
order to build allmydata.org from source
#x27;ve done so
in private many times with only partial success as to the "specific"
part. One promising approach is to request objections in the form of
automated tests that setuptools fails, e.g. [3].
Regards,
Zooko O'Whielacronx
[1] http://stdeb.python-hosting.com/
[2] http://www
ther platforms where its
homegrown setup script and homegrown "find my file" function fail.
So using pkg_resources (and setuptools to install it) makes
"test_nevow" pass on all of the allmydata.org buildslaves:
http://allmydata.org/buildbot/waterfall?show_events=false
Re
s
it the obvious choice for interfacing to native code in the future.
Regards,
Zooko O'Whielacronx
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/opt
61 matches
Mail list logo
