[Opps. Forgot to include the list in my reply. And those that read
spambayes-dev will have seen this already. Good grief.]
> I'm having trouble checking out an anonymous copy of the Python CVS
FWIW, neither a fresh checkout nor an update works here
(WinXP), either, although (at least some) other sourceforge
projects do. ViewCVS doesn't work, either (shows an empty
page), so it's certainly not just you.
The SF site status does mention that there's maintenance scheduled (for
tomorrow) - maybe that's relevant? Does developer access still work?
I have written up a rough draft PEP on bytecode verification:
I also have a sketch implementation written in Python that I have uploaded:
This implementation does not really work yet, and there are only a couple of
unit tests, mostly because I am not a bytecode expert, but I think the
framework is pretty close to being usable and I'm getting a better grasp on
the issue. It is based on the algorithm posted by Phillip Eby, and feedback
on it would be great.
--On Dienstag, 1. Juni 2004 11:55 Uhr -0400 Tim Peters
> [A.M. Kuchling]
>> For the impending 2.4alpha1 release, a coordinated effort to reduce the
>> bug backlog would be good. Several other projects (Zope, GNOME, Mozilla)
>> have "bug days" in which people meet on IRC and go through the bug
>> database, closing irrelevant or incorrect reports, writing small test
>> cases for vague reports, etc.
>> Holding a Python bug day seems worth a try. I've written up a Wiki page,
>> http://www.python.org/cgi-bin/moinmoin/PythonBugDay, to begin planning a
>> bug day and to figure out what tools (if any) are required. Please
>> comment, particularly if you've participated in bug days for Zope or
>> other projects.
> A bug day is an excellent idea. In the Zope world, it's the only way any
> bugs get fixed <wink>.
That's really not true :-) There is always a looser standing up to early in
fixing some bugs.
Tim Peters wrote:
> That's more what I had in mind, but if the marker is changed to something
> wordy instead of "a magic character", I don't think the dedent trick is of
> much value anymore:
> A different marker:
> >>> print 'a\n\nb'
> <blank line>
> Then when the expected output is (exactly) "<blank line>", doctest would
> accept "<blank line>", or a line with nothing other than whitespace, as a
> match. I can't get upset by that bit of ambiguity.
I had ruled this out because I assumed that any change I made had to
maintain backward compatibility. But if this (minor) incompatibility is
acceptable, then let me know and I'll write up a patch to implement it.
Instances of classes inheriting from str, tuple, etc cannot be weakly
referenced. Does anyone know the reason for this?
>>> from weakref import proxy
>>> class Object(object):
>>> x = Object()
>>> y = proxy(x) # no problem here
>>> class Str(str):
>>> x = Str()
>>> y = proxy(x) # but why won't this work?
Traceback (most recent call last):
File "<pyshell#9>", line 1, in -toplevel-
y = proxy(x)
TypeError: cannot create weak reference to 'Str' object
Weak referencing would be much more useful to me if it included strings,
tuples, and such. Right now, my awkward workaround is substituting
UserString or some other wrapper class replacing inheritance with
"Martin v. L?wis" <martin(a)v.loewis.de>:
> It is not surprising the patches haven't seen any
> comments: We get way more patches than we can handle
> these days. If you want to help, please review patches
> of other people, and recommend adaption or rejection.
I doubt I'm the only one who assumed that anything but
a change suggestion would be counterproductive; that it
would just be adding a "me too" that slowed down the
person who could actually check the patch in.
If reviews from anyone are welcome, it wouldn't hurt
to mention that a few more places. Ideally, it would
be in the:
(1) boilerplate that you see when looking at a patch
(2) boilerplate at the top of a list of patches
<URL: http://sourceforge.net/tracker/?group_id=5470&atid=305470 >
(3) developer documentation. (I can sort of find it in
<URL: http://www.python.org/dev/dev_intro.html#helping-out >,
but didn't see it until I was already looking specifically
for information on patch reviews.)
(4) pre-announce for a new alpha release.
I'm having trouble checking out an anonymous copy of the Python CVS
repository. I tried the instructions from both the developer FAQ and
the SF CVS page; and tried checking it out from debian, win2k, and OS X.
In all cases, I get an error that looks something like this:
cvs server: cannot read file in mydbm_load_file: Input/output error
cvs checkout: in directory .:
cvs [checkout aborted]: *PANIC* administration files missing
A google search for "mydbm_load_file" didn't turn up anything useful.
Anyone have an idea what's going wrong? Thanks!
(Here's a copy-paste of my shell session from debian, in case I'm doing
> [syse:~/data/programming] export CVSROOT=:pserver:firstname.lastname@example.org:/cvsroot/python
> [syse:~/data/programming] cvs login
> Logging in to :pserver:email@example.com:2401/cvsroot/python
> CVS password:
> [syse:~/data/programming] cvs -z3 co python
> cvs server: cannot read file in mydbm_load_file: Input/output error
> cvs checkout: cannot read file in mydbm_load_file: Input/output error
> cvs checkout: warning: cannot write to history file /cvsroot/python/CVSROOT/history: Read-only file system
> cvs checkout: Updating python
> cvs checkout: failed to create lock directory for `/cvsroot/python/python' (/cvsroot/python/python/#cvs.lock): Read-only file system
> cvs checkout: failed to obtain dir lock in repository `/cvsroot/python/python'
> cvs [checkout aborted]: read lock failed - giving up
Edward Loper wrote:
> I thought that it would be more efficient to get feedback on whether the
> patch is a good idea before writing the docs & tests. But I guess that
> that's now how things are done w/ Python development. I'll go ahead and
> add test cases & docs, and update the patches.
It's more efficient for the patch submitter, but less efficient for the
reviewer, because the reviewer needs to spend more time understanding
the patch in detail. Therefore, patches that are formally complete get
better attention; patches where the author couldn't find the time to
write documentation might never get reviewed.