Now that I'm starting to examine and do some edits on the docs, I'd like to
ask some guidance. What editor(s) do you guys use? I'm not one to cling to
an editor, so all suggestions are fair game.
On Fri, Mar 28, 2008 at 11:15 AM, Bill Janssen <janssen(a)parc.com> wrote:
> > On Fri, Mar 28, 2008 at 3:31 AM, <skip(a)pobox.com> wrote:
> > >
> > > Neal> Anything that connects to a remote host is definitely flaky.
> > >
> > > Would it maybe help to set up a dedicated host (or virtual host) to serve as
> > > the sole target of all network tests?
> > It would help, but not fix the problem. There will still be transient
> > network issues that come up.
> We really need to be able to wrap a timeout around any individual
> test, perhaps throwing a TimeoutException if the timeout is reached,
> and have the ability to regard a TimeoutException as not being a
def RaiseTimeout(signal, frame):
# Why don't we have a context manager for the next line?
old_alarm = signal.signal(signal.SIGALRM, RaiseTimeout)
with appropriate fallbacks for Windows. I may not be poking at
test_support for a bit, so anyone else is welcome to check that in, or
a fixed version of it, whenever they're fixing a timing-out test.
Someone else will have to implement the support in regrtest, although
I wouldn't mind having it treat a timeout as a failure, as long as
it's easier to diagnose than the SIGKILL it currently uses for
Hello. In Python 2.5.1 the code
for d in '123', u'123':
x = decimal.Decimal(d)
In 2.5.2 it prints
Why the change? Is it a bug or a feature? Shouldn't .to_eng_string()
always return a str?
Oleg Broytmann http://phd.pp.ru/ phd(a)phd.pp.ru
Programmers don't die, they just GOSUB without RETURN.
I've been running 2to3's fix_callable over 2.6's stdlib to remove -3
warnings due to callable() usage; 2to3 replaces callable(x) with
has_attr(x, "__call__"). Unfortunately, this breaks code that wants to
run callable() on old-style classes (like test_builtin), because
old-style classes don't have a __call__ attribute (new-style classes
How should this be handled? I'm tempted to just add __call__ to
old-style classes for 2.6, but Neal Norwitz thought that might break
some user code. Any other thoughts?
On Thu, Mar 27, 2008 at 11:31 AM, Bill Janssen <janssen(a)parc.com> wrote:
> > There
> > have been other tests that have also been flaky like test_asynchat,
> > test_smtplib, test_ssl, test_urllib2net, test_urllibnet,
> > test_xmlrpc_net and some of the tests that use networking.
> Some of the *other* tests that use networking, I think you mean.
Yes, primarily networking tests. Also things like signals and threading.
> Sounds like networking tests in general are flaky.
Anything that connects to a remote host is definitely flaky. Most of
the tests that connect to localhost are flaky for one reason or
another. One reason used to be port allocation. That is mostly fixed
The big reason that most tests fail now is EAGAIN or some other error,
typically on non-blocking sockets. Switching to blocking sockets
isn't really a great option since the tests are much more likely to
> > - http://www.python.org/dev/buildbot/all/S-390%20Debian%20trunk/builds/255/st…
> Unfortunately, this log has no information about why the test is
> failing, and I do not have a Debian-unstable machine to try it on
> (much less a six-processor IBM S/390 mainframe running Debian-unstable
> -- cool!). I'm unsure about how to make progress here. It's
> interesting to see that most of the stable buildbots running Debian
> are doing so on big-endian (PPC, Sparc) hardware.
> I also can't tell which branch of Python is being tested, from this
> logfile. That would be nice to add. Is this 2.6 (known problems with
> SSL) or 3.0 (no known problems with SSL)? Is this information in the
> logfile somewhere and I'm not seeing it?
The information happens to be encoded in the URL. The URL above is for trunk.
You can see more info here: http://www.python.org/dev/buildbot/all/
That is the landing page for all the info you could want. Well,
mostly. The logs often don't really have enough info to debug the
problem. In that case, it would be better to add more debugging to
So, after having some time to absorb the Python-Dev threads about
setuptools, bootstrap, and all the rest, I think I see an opportunity
to let people route around the "damage" of eggs, while still making
it possible for the people who want to use easy_install or to put
dependencies in their setup.py to get what they want, too. (And
without them needing to install eggs, either.) At the same time, we
can address the issues that remain around uninstalling packages,
system vs. user packages, PYTHONPATH and site.py woes, and really
pretty much every other complaint I've heard in the last few days
about setuptools stomping on other people's stuff. (Even Paul's
Windows issues, hopefully.)
Now, you might be asking, "Okay, so why are you telling me about
this? Why not just go fix setuptools?" Well, I *can't*. Not
without some help from Python-Dev and the Distutils-SIG, to create an
updated standard for installed package metadata, by updating PEP 262
("A Database of Installed Python Packages") to include input from the
system packaging folks, support for namespace packages, and support
for setuptools-compatible dependency information.
What's that got to do with anything? Well, without it, setuptools
can't support uninstall or conflict management without using eggs to
compartmentalize the installed files. And because it has to use eggs
to do *that*, it has to munge .pth files and install its own site.py
when installing to PYTHONPATH. All of this ugliness follows directly
from the absence of a PEP 262-style installation database.
Sure, setuptools could create its own version of this, and I almost
did that four years ago. (If you look at the "open issues" part of
PEP 262, you'll see my comments from back then.) I decided not to
for two reasons: first, the distutils didn't support it yet, so it
didn't help for conflict detection and avoidance in the real world at
Second, there were no uninstall tools for it, so I'd have had to
write one myself. (Zed's "easy_f'ing_uninstall" to the contrary, it
ain't easy, and I have an aversion to deleting stuff on people's
systems without knowing what will break. There's a big difference
between them typing 'rm -rf' themselves, and me doing it.)
However, if tools exist and are distributed for such a "database",
and *everybody* agrees to use it as an officially-blessed standard,
then it should be possible for setuptools to co-exist with that
framework, and we're all happy campers.
In particular, the "installing eggs sucks" camp should be happy,
because it'll be possible for me (or anyone else) to write a version
of easy_install that doesn't install eggs any more, and
setuptools-based packages can go back to having "setup.py install"
install things the old way by default.
So, to accomplish this, we (for some value of "we") need to:
1. Hash out consensus around what changes or enhancements are needed
to PEP 262, to resolve the previously-listed open issues, those that
have come up since (namespace packages, dependency specifications,
canonical name/version forms), and anything else that comes up.
2. Update or replace the implementation as appropriate, and modify
the distutils to support it in Python 2.6 and beyond. And "support
it" means, "ensure that 'install' and *all* bdist commands update the
database". The bdist_rpm, bdist_wininst, and bdist_msi commands,
even bdist_dumb. (This should probably also include the add/remove
programs stuff in the Windows case.)
3. Create a document for system packagers referencing the PEP and
introducing them to what/why/how of the standard, in case they
weren't one of the original participants in creating this.
It will probably take some non-trivial work to do all this for Python
2.6, but it's probably possible, if we start now. I don't think it's
critical to have an uninstall tool distributed with 2.6, as long as
there's a reasonable way to bootstrap its installation later.
Questions, comments... volunteers? :)
Hi Python devs,
I have been contributing to since December. (See me first issue on the
tracker, #1828; it was a major learning experience.) :P In that time, I have
contributed many patches and actively participated on this list.
This will enable me to help triage bugs on the tracker, something I've been
wanting to help with.
I'm willing to field questions.
Thanks for your consideration,