Re: [Python-Dev] Fwd: Distributed RCS

[skip]

Anthony> The current bazaar, last time I looked (a few months ago) did
Anthony> not work on Windows. This is a complete deal-breaker for us,

I assume it would be a deal breaker for many people.  According to the
Bazaar-NG website it works on "Linux, Windows and Mac OS X, or any system
with a Python interpreter".  If it's that platform-independent, perhaps it
will work on some systems that don't support CVS.  It does require Python
2.4, though I doubt that would be a great hardship for many people
interested in Python development.

Skip
___
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

Re: [Python-Dev] Fwd: Distributed RCS

[Martin v. Löwis]

Guido van Rossum wrote:
> With permission, I'm forwarding an email from Mark Shuttleworth about
> Bazaar-2 (aka Bazaar-NG), a distributed source control system (not
> entirely unlike bitkeeper, I presume) written in Python and in use by
> the Ubuntu system. What do people think of using this for Python? Is
> it the right model? 

Like Skip, I tried experimenting with it. While that may be the right
model, I don't think it is the right software. In bazaar-ng 0.0.5 (which
is what Debian unstable currently has), bzr commit would not open
a text editor, but require the commit message on the command line;
selective commit of only some of the changed files is also not
supported. bzr diff cannot show the changes between two revisions,
and cannot show revisions across branches.

So I assume that using bazaar-ng right now would cause problems in
day-to-day usage.

Regards,
Martin
___
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

Re: [Python-Dev] cvs to bzr?

[skip]

>> ... I didn't see any mention in the bzr docs of any sort of cvs2bzr
>> tool.

Neil> Haven't tried it but should work:

Neil> http://darcs.net/DarcsWiki/Tailor 

Thanks Neil.  I downloaded it last night and played around a bit.  What
follows is a description that will hopefully keep others from stepping in
the same booby traps I did.

It doesn't appear to work at this point, both based on attempts to use it
and hints on the above page.  After some reading, I was able to pull the
latest version with

wget --exclude-directories=/~lele/projects/tailor/_darcs --mirror \
 --no-parent  --no-host-directories --cut-dirs=3 -e robots=off \
 http://nautilus.homeip.net/~lele/projects/tailor/

(The wget example at the top of the wiki page points to an older version.)

Unfortunately, it (like the older version) is missing

if __name__ == "__main__":
main()

in tailor.py and has no call to its main() function anywhere in the source.
This seemed very odd to me, so I added one, as well as a #! line.  I
eventually noticed that there is a vcpx package and in the directory above,
a number of other files, tailor, a bunch of index.html files and a README.
It was reminiscent of expanding a tar file in the bad old days (or unzipping
a zip file nowadays) before everbody got the idea that it would be a good
idea to create a top-level directory...

Anyway, I'm still struggling with it.  If I get further I'll post my
results.  If others have gotten further, tips would be appreciated.

Skip
___
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

Re: [Python-Dev] Fwd: Distributed RCS

[skip]

Martin> Like Skip, I tried experimenting with it.  While that may be the
Martin> right model, I don't think it is the right software. [problems
Martin> elided]

Martin> So I assume that using bazaar-ng right now would cause problems
Martin> in day-to-day usage.

Granted.  What is the cost of waiting a bit longer to see if it (or
something else) gets more usable and would hit the mark better than svn?  I
presume that once we switch away from cvs to something else, it's unlikely
we would switch again unless some huge roadblock appeared that made the
initial change the wrong one.

I was amazed at the number of different version control systems out there
now.  CVS, while enormously successful from a practical standpoint, clearly
has its detractors.  That there are so many alternatives suggests that it's
not clear yet what the "correct" feature set for a version control system
is.

Skip
___
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

Re: [Python-Dev] Fwd: Distributed RCS

[Martin v. Löwis]

[EMAIL PROTECTED] wrote:
> Granted.  What is the cost of waiting a bit longer to see if it (or
> something else) gets more usable and would hit the mark better than svn?  I
> presume that once we switch away from cvs to something else, it's unlikely
> we would switch again unless some huge roadblock appeared that made the
> initial change the wrong one.

It depends on what "a bit" is. Waiting a month would be fine; waiting
two years might be pointless.

So I think I will personally pursue PEP 347 (switching to SVN); it will
be then an issue of BDFL pronouncement.

Regards,
Martin
___
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

Re: [Python-Dev] Fwd: Distributed RCS

[Neil Schemenauer]

On Sun, Aug 14, 2005 at 06:16:11PM +0200, "Martin v. Löwis" wrote:
> It depends on what "a bit" is. Waiting a month would be fine; waiting
> two years might be pointless.

It looks like the process of converting a CVS repository to
Bazaar-NG does not yet work well (to be kind).  The path
CVS->SVN->bzr would probably work better.  I suspect cvs2svn has
been used on quite a few CVS repositories already.  I don't think
going to SVN first would lose any information.

My vote is to continue with the migration to SVN.  We can
re-evaluate Bazaar-NG at a later time.

  Neil
___
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

[Python-Dev] build problems on macosx (CVS HEAD)

[Ronald Oussoren]

Hi,

I'm trying to build CVS HEAD on OSX 10.4.2 (Xcode 2.1), with a  
checkout that is less than two hours old. I'm building a standard  
unix tree (no framework install):

$ ./configure --prefix=/opt/python/2.5
...
$ make
...
ar cr libpython2.5.a Modules/config.o Modules/getpath.o Modules/ 
main.o Modules/gcmodule.o
ar cr libpython2.5.a Modules/threadmodule.o  Modules/signalmodule.o   
Modules/posixmodule.o  Modules/errnomodule.o  Modules/_sre.o  Modules/ 
_codecsmodule.o  Modules/zipimport.o  Modules/symtablemodule.o   
Modules/xxsubtype.o
ranlib libpython2.5.a
c++  -u _PyMac_Error -o python.exe \
 Modules/python.o \
 libpython2.5.a -ldl
case $MAKEFLAGS in \
*-s*)  CC='gcc' LDSHARED='gcc  -bundle -undefined dynamic_lookup'  
OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python.exe -E ./ 
setup.py -q build;; \
*)  CC='gcc' LDSHARED='gcc  -bundle -undefined dynamic_lookup' OPT='- 
DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python.exe -E ./setup.py  
build;; \
esac
make: *** [sharedmods] Error 139

This is a segmentation fault when trying to build extensions:

$ ./python.exe
Python 2.5a0 (#5, Aug 14 2005, 18:20:08)
[GCC 4.0.0 (Apple Computer, Inc. build 5026)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> import setup
Segmentation fault

The minimal import that causes a crash is 'import  
distutils.sysconfig'. I've rebuild using --enable-debug and --with- 
pydebug to check if gdb could tell me more.

The start of the stacktrace:
(gdb) r -c 'import distutils.sysconfig'
Starting program: /Volumes/Data/Users/ronald/Python/python-HEAD/dist/ 
src/python.exe -c 'import distutils.sysconfig'
Reading symbols for shared libraries . done

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0xcbcbcbd3
0x001500b0 in structseq_dealloc (obj=0x3c3878) at Objects/structseq.c:47
47  Py_XDECREF(obj->ob_item[i]);
(gdb) where
#0  0x001500b0 in structseq_dealloc (obj=0x3c3878) at Objects/ 
structseq.c:47
#1  0x0002fdb0 in _Py_Dealloc (op=0x3c3878) at Objects/object.c:1883
#2  0x000eedb4 in frame_dealloc (f=0x1816c18) at Objects/ 
frameobject.c:394
#3  0x0002fdb0 in _Py_Dealloc (op=0x1816c18) at Objects/object.c:1883
#4  0x000dd1d0 in fast_function (func=0x390038, pp_stack=0xbfffd788,  
n=1, na=1, nk=0) at Python/ceval.c:3654
#5  0x000dcdc8 in call_function (pp_stack=0xbfffd788, oparg=1) at  
Python/ceval.c:3590
#6  0x000d6aa4 in PyEval_EvalFrameEx (f=0x610358, throw=0) at Python/ 
ceval.c:2181
#7  0x000d98d0 in PyEval_EvalCodeEx (co=0x5180d8, globals=0x5146c8,  
locals=0x5146c8, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0,  
defcount=0, closure=0x0) at Python/ceval.c:2748
#8  0x000ce270 in PyEval_EvalCode (co=0x5180d8, globals=0x5146c8,  
locals=0x5146c8) at Python/ceval.c:490
#9  0x0001643c in PyImport_ExecCodeModuleEx (name=0xbfffe808  
"distutils.sysconfig", co=0x5180d8, pathname=0xbfffde4c "/Volumes/ 
Data/Users/ronald/Python/python-HEAD/dist/src/Lib/distutils/ 
sysconfig.pyc") at Python/import.c:620

At the DECREF, i == 17, size == 18 and obj->ob_item[i] == 0xcbcbcbcb,  
and obj is an posix.stat_result.

___
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

Re: [Python-Dev] cvs to bzr?

[Neil Schemenauer]

On Sat, Aug 13, 2005 at 06:03:46PM -0600, Neil Schemenauer wrote:
> Haven't tried it but should work:
> 
> http://darcs.net/DarcsWiki/Tailor 

After applying the attached patch, this command seemed to work for
converting the initial revision:

~/src/cvsync/tailor.py --source-kind cvs --target-kind bzr \
--bootstrap --repository ~/Python/python-cvsroot -m python \
--revision r16b1 py_bzr

After, I think this command is supposed to bring the bzr repostiory
up-to-date:

cd py_bzr; ~/src/cvsync/tailor.py -v 

It does not seem to work for me (it only updates one file and then
quits).  cvs2svn seems to be much more mature.

  Neil
diff -rN -u old-cvsync/vcpx/bzr.py new-cvsync/vcpx/bzr.py
--- old-cvsync/vcpx/bzr.py  2005-08-14 09:43:15.0 -0600
+++ new-cvsync/vcpx/bzr.py  2005-08-14 10:38:02.0 -0600
@@ -29,14 +29,23 @@
 
 ## SyncronizableTargetWorkingDir
 
-def _addEntries(self, root, entries):
-"""
-Add a sequence of entries.
-"""
+def _addPathnames(self, root, entries):
+c = SystemCommand(working_dir=root, command="bzr add --no-recurse"
+" %(entries)s")
+c(entries=' '.join([shrepr(e) for e in entries]))
 
+def _addSubtree(self, root, *entries):
 c = SystemCommand(working_dir=root, command="bzr add %(entries)s")
-c(entries=' '.join([shrepr(e.name) for e in entries]))
+c(entries=' '.join([shrepr(e) for e in entries]))
 
+def _removePathnames(self, root, names):
+pass # bzr handles this itself
+
+def _renamePathname(self, root, oldname, newname):
+c = SystemCommand(working_dir=root,
+  command="bzr mv %(old)s %(new)s")
+c(old=shrepr(oldname), new=shrepr(newname))
+
 def _commit(self,root, date, author, remark, changelog=None, entries=None):
 """
 Commit the changeset.
@@ -112,7 +121,7 @@
 
 # Create the .bzrignore file, that contains a glob per line,
 # with all known VCs metadirs to be skipped.
-ignore = open(join(root, '.hgignore'), 'w')
+ignore = open(join(root, '.bzrignore'), 'w')
 ignore.write('\n'.join(['(^|/)%s($|/)' % md
 for md in IGNORED_METADIRS]))
 ignore.write('\ntailor.log\ntailor.info\n')

___
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

Re: [Python-Dev] Fwd: Distributed RCS

[Guido van Rossum]

On 8/14/05, Neil Schemenauer <[EMAIL PROTECTED]> wrote:
> It looks like the process of converting a CVS repository to
> Bazaar-NG does not yet work well (to be kind).  The path
> CVS->SVN->bzr would probably work better.  I suspect cvs2svn has
> been used on quite a few CVS repositories already.  I don't think
> going to SVN first would lose any information.
> 
> My vote is to continue with the migration to SVN.  We can
> re-evaluate Bazaar-NG at a later time.

That's looks like a fair assessment -- although it means twice the
conversion pain for developers.

It sounds as if bazaar-NG can use a bit of its own medicine -- I hope
everybody who found a bug in their tools submitted a patch! :-)

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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

[Python-Dev] Fwd: PEP: Migrating the Python CVS to Subversion

[Guido van Rossum]

Here's another POV. (Why does evereybody keep emailing me personally?)

--Guido van Rossum (home page: http://www.python.org/~guido/)

-- Forwarded message --
From: Daniel Berlin <[EMAIL PROTECTED]>
Date: Aug 13, 2005 7:33 PM
Subject: Re: [Python-Dev] PEP: Migrating the Python CVS to Subversion
To: [EMAIL PROTECTED]


(Sorry for the lack of proper References: headers, this is a reply to
the email archive).

It's been a couple years since i've been in the world of python-dev, but
apparently i'm rejoining the mailing list at just the right time.

Take all of this for what it is worth:

I'm currently responsible for GCC's bugzilla, wiki, in addition to
maintaining several optimization areas of the compiler :P.
In addition, i'm responsible for pushing GCC (my main love and world :P)
towards Subversion.  I should note my bias at this point.  I now have
full commit access to Subversion.  However, I've also submitted patches
to monotone, etc.

We had a long thread about the various alternatives (arch, bzr, etc),
and besides "freeness" constraints on what we can run on gcc.gnu.org as
an FSF project, it wouldn't have mattered anyway.  This has been in the
planning for about a year now (mainly waiting for new hardware).

Originally, we were hoping to move GCC to monotone, but it didn't mature
fast enough (it's way too slow), and we couldn't make it centralized
enough for our tastes (more later).

The rest of the free tools other than subversion (arch, monotone, git,
darcs, etc) simply couldn't handle our repository with reasonable
speed/hardware.  GCC has project history dating back to 1987.  It's a 4
gig CVS repo containing > 1000 tags, and > 300 branches.  The changelog
alone has 30k trunk revisions.   Those distributed systems that carry
full history often can't deal with this fast enough or in any space
efficient way.  arch was an example of this.  It had a retarded
mechanism that forced users to care about caching certain revisions to
speed it up , instead of doing it on it's own.  I've never tried
converting this repo to bazaar-ng, it wasn't far enough along when i
started.  It also had no cvs2bzr type program, and we aren't about to
lose all our history.  Except for monotone (builtin cvs_import) and
subversion (cvs2svn), none of the cvs2* programs i've run across either
run in reasonable time (those that don't actually understand how to
extract rcs revisions would take weeks to convert our repo, literally),
or could handle all the complexities a repository with our history
present (branches of branches, etc).  Most simply crash in weird ways or
run out of memory :).

Anyway:
Monotone took 45 minutes just to diff two old revisions that are one
revision away from each other.
CVS takes about 2 minutes for the same operation.
SVN on fsfs takes 4 seconds.

The converted SVN repo has > 10 revisions, and is only ~15% bigger
than the cvs repo (mostly due to stupid copies it has to do to handle
some tag fuckery people were doing in some cases.  If it had been
subversion from the start, it would have been smaller).

We have cvs2svn speedup patches that were done with the KDE folks that
make cvs2svn io bound again instead of cpu bound (it was O(N^2) in
extracting cvs revision texts before).  It takes 17 hours to convert the
gcc repository now, only 45 minutes of cpu time :).  It used to take 52
hours.

I've also talked with Linus about version control before.  He believes
extreme distributed development is the way to go.  I believe heavily
that in most cases where you have a mix of corporations and free
developers, it ends up causing people to "hide the ball" more than they
should.  This is particularly prevalent in GCC.  We don't want design
and development done and then sent as mega-patches presented as fait
accompli, then watch these people whine as their designs get torn apart.
We'd rather have the discussion on the mailing list and the work done in
a visible place (IE CVS branch stored in some central place) rather than
getting patch bombs.  As a result (and there are many other reasons, i'm
just presenting one of them), we actually don't *want* to move from a
centralized model, in order to help control the social and political
problems we'd have to face if we went fully distributed.

Python may not face any of these problem to the degree that GCC does (i
doubt many projects do actually. GCC is a very weird and tense political
situation :P), because of size, etc, in which case, a distributed model
may make more sense.  However, you need to be careful to make sure that
people understand that it hasn't actually changed your real development
process (PEP's, etc), only the workflow used to implement it.
___
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

Re: [Python-Dev] build problems on macosx (CVS HEAD)

[Brett Cannon]

On 8/14/05, Ronald Oussoren <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> I'm trying to build CVS HEAD on OSX 10.4.2 (Xcode 2.1), with a
> checkout that is less than two hours old. I'm building a standard
> unix tree (no framework install):
> 
> $ ./configure --prefix=/opt/python/2.5
> ...
> $ make
> ...
> ar cr libpython2.5.a Modules/config.o Modules/getpath.o Modules/
> main.o Modules/gcmodule.o
> ar cr libpython2.5.a Modules/threadmodule.o  Modules/signalmodule.o
> Modules/posixmodule.o  Modules/errnomodule.o  Modules/_sre.o  Modules/
> _codecsmodule.o  Modules/zipimport.o  Modules/symtablemodule.o
> Modules/xxsubtype.o
> ranlib libpython2.5.a
> c++  -u _PyMac_Error -o python.exe \
>  Modules/python.o \
>  libpython2.5.a -ldl
> case $MAKEFLAGS in \
> *-s*)  CC='gcc' LDSHARED='gcc  -bundle -undefined dynamic_lookup'
> OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python.exe -E ./
> setup.py -q build;; \
> *)  CC='gcc' LDSHARED='gcc  -bundle -undefined dynamic_lookup' OPT='-
> DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python.exe -E ./setup.py
> build;; \
> esac
> make: *** [sharedmods] Error 139
> 
> This is a segmentation fault when trying to build extensions:
> 

I can verify the breakage.  I did a ``make distclean``, updated,
built, and got the same 139 error.

I am short on time today, so I don't think I will be able to dive into
this right away.

-Brett
___
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

Re: [Python-Dev] build problems on macosx (CVS HEAD)

[Michael Hudson]

Ronald Oussoren <[EMAIL PROTECTED]> writes:

> Hi,
>
> I'm trying to build CVS HEAD on OSX 10.4.2 (Xcode 2.1), with a  
> checkout that is less than two hours old. I'm building a standard  
> unix tree (no framework install):

It seems very likely that it was this change:

http://fisheye.cenqua.com/changelog/~br=MAIN/python?cs=MAIN:loewis:20050809145951

Refcounting, posixmodule.c, aiee!  You are in a maze of twisty
#ifdefs, all alike.  I'll probably find the problem fairly soon, we'll
see... :)

Cheers,
mwh

-- 
  All obscurity will buy you is time enough to contract venereal
  diseases.  -- Tim Peters, python-dev
___
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

Re: [Python-Dev] Fwd: Distributed RCS

[Neal Becker]

I encourage everyone to look at mercurial.  It is also written in Python.  I
am using it daily.

___
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

Re: [Python-Dev] Exception Reorg PEP checked in

[Michael Hudson]

Wilfredo Sánchez Vega <[EMAIL PROTECTED]> writes:

>I'm curious about why Python lacks FileNotFoundError,  
> PermissionError and the like as subclasses of IOError.

Good question.  Lack of effort/inertia?

>Catching IOError and looking at errno to figure out what went  
> wrong seems pretty unpythonic, and I've often wished for built-in  
> subclasses of IOError.

The py library does this (http://codespeak.net/py).

>I sometimes subclass them myself, but a lot of the time, I'm  
> catching such exceptions as thrown by the standard library.

Well, indeed.  OTOH, functions like os.open aren't really *meant* to
be pythonic.

I don't think this is something I can get interested enough in to work
on myself.

Cheers,
mwh

-- 
   As far as I'm concerned, the meat pie is the ultimate unit
 of currency.   -- from Twisted.Quotes
___
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

Re: [Python-Dev] Exception Reorg PEP checked in

[Guido van Rossum]

On 8/14/05, Michael Hudson <[EMAIL PROTECTED]> wrote:
> Wilfredo Sánchez Vega <[EMAIL PROTECTED]> writes:
> 
> >I'm curious about why Python lacks FileNotFoundError,
> > PermissionError and the like as subclasses of IOError.
> 
> Good question.  Lack of effort/inertia?

Well, I wonder how often it's needed. My typical use is this:

try:
f = open(filename)
except IOError, err:
print "Can't open %s: %s" % (filename, err)
   return

and the error printed contains all the necessary details (in fact it
even repeats the filename, so I could probably just say "print err").

Why do you need to know the exact reason for the failure? If you
simply want to know whether the file exists, I'd use os.path.exists()
or isfile(). (Never mind that this is the sometimes-frowned-upon
look-before-you-leap; I think it's often fine.)

Also note that providing the right detail can be very OS specific.
Python doesn't just run on Unix and Windows.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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

Re: [Python-Dev] Distributed RCS

[Michael Hudson]

"Terry Reedy" <[EMAIL PROTECTED]> writes:

> It seems to me that auto testing of the tentatively updated trunk before 
> final commitment would avoid the 'who checked in test-breaking code' 
> messages that appear here occasionally.  

I don't think there's any fundamental impossibility in setting up such
a system for CVS, and am pretty certain there's not for SVN.

> But it requires that the update + test-suite time be less than the
> average inter-update interval.

Indeed.

> The current bottleneck in Python development appears to be patch reviews. 

And acting on those reviews...

> So merely making submission and commitment easier will not help much. 

I'm not sure, I think it could help quite a bit.

> An alternative to more reviewers is more automation to make more
> effective use of existing reviewers.  (And this might also encourage
> more reviewers.)  The Launchpad group seems to be ahead in this
> regard, but I don't know how much this is due to using bazaar.  In
> any case, ease of improving the review process might be a criterion
> for choosing a source code system.  But I leave this to ML.
>
> *Other things being equal*, using a state-of-the-art development system 
> written in Python to develop Python would be a marketing plus.

I think the words "stable" and "reliable" should be in there somewhere
:)

I don't get the impression bazaar-ng is there yet.

Cheers,
mwh

-- 
  Unfortunately, nigh the whole world is now duped into thinking that 
  silly fill-in forms on web pages is the way to do user interfaces.  
-- Erik Naggum, comp.lang.lisp
___
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

Re: [Python-Dev] Fwd: Distributed RCS

[Gustavo Niemeyer]

> Like Skip, I tried experimenting with it. While that may be the right
> model, I don't think it is the right software. In bazaar-ng 0.0.5 (which
> is what Debian unstable currently has), bzr commit would not open
> a text editor, but require the commit message on the command line;
> selective commit of only some of the changed files is also not
> supported. bzr diff cannot show the changes between two revisions,

The development version has all of those features implemented already.

> and cannot show revisions across branches.

I'm not sure about this one, though.

-- 
Gustavo Niemeyer
http://niemeyer.net
___
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

Re: [Python-Dev] build problems on macosx (CVS HEAD)

[Martin v. Löwis]

Ronald Oussoren wrote:
> I'm trying to build CVS HEAD on OSX 10.4.2 (Xcode 2.1), with a  
> checkout that is less than two hours old. I'm building a standard  
> unix tree (no framework install):

I just committed what I think is a bugfix for the recent st_gen support.
Unfortunately, I can't try the code, since I don't have access to
BSD/OSX at the moment.

So please report whether there is any change in behaviour.

Regards,
Martin
___
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

Re: [Python-Dev] Fwd: Distributed RCS

[Martin v. Löwis]

Guido van Rossum wrote:
> It sounds as if bazaar-NG can use a bit of its own medicine -- I hope
> everybody who found a bug in their tools submitted a patch! :-)

I had problems finding the place where the bazaar-NG source code
repository is stored - is there a public access to the HEAD version?
There also doesn't appear to be a bug tracker - but I found a mentioning
that bug reports should go to the mailing list.

Regards,
Martin
___
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

Re: [Python-Dev] Fwd: PEP: Migrating the Python CVS to Subversion

[Martin v. Löwis]

Guido van Rossum wrote:
> Here's another POV.

I think I agree with Daniel's view, in particular wrt. to performance.
Whatever the replacement tool, it should perform as well or better
than CVS currently does; it also shouldn't perform much worse than
subversion.

I've been using git (or, rather, cogito) to keep up-to-date with the
Linux kernel. While performance of git is really good, storage
requirements are *quite* high, and initial "checkout" takes a long
time - even though the Linux kernel repository stores virtual no
history (there was a strict cut when converting the bitkeeper HEAD).
So these distributed tools would cause quite some disk consumption
on client machines. bazaar-ng apparently supports only-remote
repositories as well, so that might be no concern.

Regards,
Martin
___
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

Re: [Python-Dev] Fwd: Distributed RCS

[Daniel Berlin]

On Sun, 2005-08-14 at 11:12 -0600, Neil Schemenauer wrote:
> On Sun, Aug 14, 2005 at 06:16:11PM +0200, "Martin v. Löwis" wrote:
> > It depends on what "a bit" is. Waiting a month would be fine; waiting
> > two years might be pointless.
> 
> It looks like the process of converting a CVS repository to
> Bazaar-NG does not yet work well (to be kind).  The path
> CVS->SVN->bzr would probably work better.  I suspect cvs2svn has
> been used on quite a few CVS repositories already.  I don't think
> going to SVN first would lose any information.

It doesn't.

As a data point, CVS2SVN can handle gcc's massive cvs repository, which
has merged rcs file information in it dating back to 1987, >1000 tags,
and > 300 branches.

Besides monotone's cvs_import, it's actually the only properly designed
cvs converter I've seen in a while (Properly designed in that it
actually uses the necessary and correct algorithms to get all the
weirdities of cvs branches and tags right).

I'm not sure how big python's repo is, but you probably want to use the
attached patch to speed up cvs2svn.  It changes it to reconstruct the
revisions on it's own instead of calling cvs or rcs.  For GCC, and KDE,
this makes a significant difference (17 hours for our 4 gig cvs repo
convresion instead of 52 hours), because it was spawning cvs/rcs 50
billion times, and the milliseconds add up :)


> My vote is to continue with the migration to SVN.  We can
> re-evaluate Bazaar-NG at a later time.
GCC is moving to SVN (very soon now, within 2 months), and this has been
my viewpoint as well.

It's much easier to go from something that has changesets and global
revisions, to a distributed system, if you want to, than it is to try to
reconstruct that info from CVS on your own :).

Subversion also has excellent language bindings, including the python
bindings.  That's how i've hooked it up to gcc's bugzilla.  You could
easily write something to transform *from* subversion to another system
using the bindings.

Things like viewcvs use the python bindings to deal with the svn
repository entirely.  

--Dan

Index: cvs2svn
===
--- cvs2svn (revision 1423)
+++ cvs2svn (working copy)
@@ -166,6 +166,10 @@
 # grouping.  See design-notes.txt for details.
 DATAFILE = 'cvs2svn-data'
 
+REVISIONS_DB = 'cvs2svn-cvsrepo.db'
+
+CHECKOUT_DB = 'cvs2svn-cvsco.db'
+
 # This file contains a marshalled copy of all the statistics that we
 # gather throughout the various runs of cvs2svn.  The data stored as a
 # marshalled dictionary.
@@ -355,40 +359,7 @@
" cvsroot\n" % (error_prefix, cvsroot, fname))
   sys.exit(1)
 
-def get_co_pipe(c_rev, extra_arguments=None):
-  """Return a command string, and the pipe created using that string.
-  C_REV is a CVSRevision, and EXTRA_ARGUMENTS is used to add extra
-  arguments.  The pipe returns the text of that CVS Revision."""
-  ctx = Ctx()
-  if extra_arguments is None:
-extra_arguments = []
-  if ctx.use_cvs:
-pipe_cmd = [ 'cvs' ] + ctx.cvs_global_arguments + \
-   [ 'co', '-r' + c_rev.rev, '-p' ] + extra_arguments + \
-   [ ctx.cvs_module + c_rev.cvs_path ];
-  else:
-pipe_cmd = [ 'co', '-q', '-x,v', '-p' + c_rev.rev ] + extra_arguments + \
-   [ c_rev.rcs_path() ]
-  pipe = SimplePopen(pipe_cmd, True)
-  pipe.stdin.close()
-  return pipe_cmd, pipe
-
-def generate_ignores(c_rev):
-  # Read in props
-  pipe_cmd, pipe = get_co_pipe(c_rev)
-  buf = pipe.stdout.read(PIPE_READ_SIZE)
-  raw_ignore_val = ""
-  while buf:
-raw_ignore_val = raw_ignore_val + buf
-buf = pipe.stdout.read(PIPE_READ_SIZE)
-  pipe.stdout.close()
-  error_output = pipe.stderr.read()
-  exit_status = pipe.wait()
-  if exit_status:
-sys.exit("%s: The command '%s' failed with exit status: %s\n"
- "and the following output:\n"
- "%s" % (error_prefix, pipe_cmd, exit_status, error_output))
-
+def generate_ignores(raw_ignore_val):
   # Tweak props: First, convert any spaces to newlines...
   raw_ignore_val = '\n'.join(raw_ignore_val.split())
   raw_ignores = raw_ignore_val.split('\n')
@@ -614,9 +585,7 @@
 DB_OPEN_READ = 'r'
 DB_OPEN_NEW = 'n'
 
-# A wrapper for anydbm that uses the marshal module to store items as
-# strings.
-class Database:
+class SDatabase:
   def __init__(self, filename, mode):
 # pybsddb3 has a bug which prevents it from working with
 # Berkeley DB 4.2 if you open the db with 'n' ("new").  This
@@ -635,22 +604,24 @@
 
 self.db = anydbm.open(filename, mode)
 
-  def has_key(self, key):
-return self.db.has_key(key)
+  def __getattr__(self, name):
+return getattr(self.db, name)
 
+# A wrapper for anydbm that uses the marshal module to store items as
+# strings.
+class Database(SDatabase):
+
   def __getitem__(self, key):
 return marshal.loads(self.db[key])
 
   def __setitem__(self, key, value):
 self.db[key] = marshal.dumps(value)
 
-  def __delitem__(self, key):

Re: [Python-Dev] Fwd: PEP: Migrating the Python CVS to Subversion

[Daniel Berlin]

On Sun, 2005-08-14 at 11:13 -0700, Guido van Rossum wrote:
> Here's another POV. (Why does evereybody keep emailing me personally?)
> 

Because we love you, and I forgot to cc python-dev.



___
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

Re: [Python-Dev] Fwd: Distributed RCS

[Gustavo Niemeyer]

> I had problems finding the place where the bazaar-NG source code
> repository is stored - is there a public access to the HEAD version?

You may use rsync:

  rsync -av --delete bazaar-ng.org::bazaar-ng/bzr/bzr.dev .

Or bzr itself:

  bzr branch http://bazaar-ng.org/bzr/bzr.dev

Regards,

-- 
Gustavo Niemeyer
http://niemeyer.net
___
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

Re: [Python-Dev] Fwd: Distributed RCS

[Martin v. Löwis]

Daniel Berlin wrote:
> I'm not sure how big python's repo is, but you probably want to use the
> attached patch to speed up cvs2svn.  It changes it to reconstruct the
> revisions on it's own instead of calling cvs or rcs. 

Thanks for the patch, but cvs2svn works fairly well for us as is (in
the version that was released with Debian sarge); see

http://www.python.org/peps/pep-0347.html

for the conversion procedure. On the machine where I originally did
the conversion, the script required 7h; on my current machine, it is
done in 1:40 or so, which is acceptable.

Out of curiosity: do you use the --cvs-revnums parameter? Should we?

Regards,
Martin
___
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

Re: [Python-Dev] Fwd: PEP: Migrating the Python CVS to Subversion

[Daniel Berlin]

On Sun, 2005-08-14 at 23:58 +0200, "Martin v. Löwis" wrote:
> Guido van Rossum wrote:
> > Here's another POV.
> 
> I think I agree with Daniel's view, in particular wrt. to performance.
> Whatever the replacement tool, it should perform as well or better
> than CVS currently does; it also shouldn't perform much worse than
> subversion.

Then, in fairness, I should note that annotate is slower on subversion
(and monotone, and anything using binary deltas) than CVS.

This is because you can't generate line-diffs that annotate wants from
binary copy + add diffs.  You have to reconstruct the actual revisions
and then line diff them.Thus, CVS is O(N) here, and SVN and other
binary delta users are  O(N^2).

You wouldn't really notice the speed difference when you are annotating
a file with 100 revisions.  You would if you annotate the 800k changelog
which has 30k trunk revisions.  CVS takes 4 seconds, svn takes ~5
minutes, the whole time being spent in doing diffs of those revisions.
I rewrote the blame algorithm recently so that it will only take about 2
minutes on changelog, but it cheats because it knows it can stop early
because it's blamed all the revisions (since our changelog rotates).

For those curious, you also can't directly generate "always-correct"
byte-level differences from the diffs, since their goal is to find the
most space efficient way to transform rev old into rev new, *not* record
actual byte-level changes that occurred between old and new.  It may
turn out that doing an add of 2 bytes is cheaper than specifying the
opcode for copy(start,len).  Actual diffs are produced by reproducing
the texts and line diffing them.  Such is the cost of efficient
storage :).

> 
> I've been using git (or, rather, cogito) to keep up-to-date with the
> Linux kernel. While performance of git is really good, storage
> requirements are *quite* high, and initial "checkout" takes a long
> time - even though the Linux kernel repository stores virtual no
> history (there was a strict cut when converting the bitkeeper HEAD).
> So these distributed tools would cause quite some disk consumption
> on client machines. bazaar-ng apparently supports only-remote
> repositories as well, so that might be no concern.

The argument "network and disk is cheap" doesn't work for us when you
are talking 5-10 gigabytes of initial transfer :).  However, I doubt
it's more than a hundred meg or so for python, if that.

You may run into these problems in 10 years :)






___
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

Re: [Python-Dev] build problems on macosx (CVS HEAD)

[Michael Hudson]

"Martin v. Löwis" <[EMAIL PROTECTED]> writes:

> Ronald Oussoren wrote:
>> I'm trying to build CVS HEAD on OSX 10.4.2 (Xcode 2.1), with a  
>> checkout that is less than two hours old. I'm building a standard  
>> unix tree (no framework install):
>
> I just committed what I think is a bugfix for the recent st_gen support.
> Unfortunately, I can't try the code, since I don't have access to
> BSD/OSX at the moment.
>
> So please report whether there is any change in behaviour.

Seems to have done the trick, thanks.

Cheers,
mwh

-- 
   I just had a very odd phone call
   from a researcher with the french TV station "TF1"
   asking about inflatable football referees
-- from Twisted.Quotes
___
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

Re: [Python-Dev] Fwd: Distributed RCS

[Daniel Berlin]

On Mon, 2005-08-15 at 00:15 +0200, "Martin v. Löwis" wrote:
> Daniel Berlin wrote:
> > I'm not sure how big python's repo is, but you probably want to use the
> > attached patch to speed up cvs2svn.  It changes it to reconstruct the
> > revisions on it's own instead of calling cvs or rcs. 
> 
> Thanks for the patch, but cvs2svn works fairly well for us as is (in
> the version that was released with Debian sarge); see
> 
> http://www.python.org/peps/pep-0347.html
> 
> for the conversion procedure. On the machine where I originally did
> the conversion, the script required 7h; on my current machine, it is
> done in 1:40 or so, which is acceptable.
> 
> Out of curiosity: do you use the --cvs-revnums parameter? Should we?

No.  In our case, it doesn't buy us anything.

In the name of continuity, we have to make the old cvsweb urls work with
new viewcvs urls anyway (they appear in bug reports, etc). We also don't
want to destroy the ability for people to diff existing cvs working
copies.  I may have been able to hack something around with cvs-revnums,
but not easily.

Thus, we are just going to keep a readonly version of the repo around,
and a readonly cvsweb,  with a warning at the top of the page  that the
current source is stored in subversion.


> 
> Regards,
> Martin

___
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

Re: [Python-Dev] Fwd: Distributed RCS

[Martin v. Löwis]

Gustavo Niemeyer wrote:
> You may use rsync:
> 
>   rsync -av --delete bazaar-ng.org::bazaar-ng/bzr/bzr.dev .
> 
> Or bzr itself:
> 
>   bzr branch http://bazaar-ng.org/bzr/bzr.dev

Ah, thanks. Fetching it with rsync is so much faster than fetching
it with bzr, though...

Regards,
Martin
___
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

Re: [Python-Dev] Fwd: PEP: Migrating the Python CVS to Subversion

[Martin v. Löwis]

Daniel Berlin wrote:
> The argument "network and disk is cheap" doesn't work for us when you
> are talking 5-10 gigabytes of initial transfer :).  However, I doubt
> it's more than a hundred meg or so for python, if that.
> 
> You may run into these problems in 10 years :)

I don't know how bazaar-ng would perform - but the converted fsfs svn
repository is 718MiB.

Of course, in 10 years, 5-10GiB of network transfer will be cheap :-)

Regards,
Martin
___
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

Re: [Python-Dev] cvs to bzr?

[Lalo Martins]

And so says [EMAIL PROTECTED] on 14/08/05 07:00...
> Based on the message Guido forwarded, I installed bazaar-ng.  From Mark's
> note it seems they convert cvs repositories to bzr repositories, but I
> didn't see any mention in the bzr docs of any sort of cvs2bzr tool.
> Likewise, Google didn't turn up anything obvious.  Anyone know of something?

Just for the sake of fairness - Mark's email states that they convert
cvs repositories to baz (Bazaar 1.x), not to bzr (Bazaar-NG, soon-to-be
Bazaar 2.x).  The tools to convert to bzr are not yet mature, as bzr
itself just recently started to solidify.  (The pace of development is
one of my favorite "features" about bzr; it's a testament to python and
to bzr itself.)

You can, however, convert from CVS to baz (arch), and from there to bzr.

best,
   Lalo Martins
--
  So many of our dreams at first seem impossible,
   then they seem improbable, and then, when we
   summon the will, they soon become inevitable.
--
http://www.exoweb.net/  mailto:[EMAIL PROTECTED]
GNU: never give up freedom http://www.gnu.org/

___
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

Re: [Python-Dev] cvs to bzr?

[skip]

Lalo> You can, however, convert from CVS to baz (arch), and from there
Lalo> to bzr.

Would this be with cscvs?  According to the cscvs wiki page at

http://wiki.gnuarch.org/cscvs

cscvs is current unmaintained and can't handle repositories with branches.
In addition, it appears that to do a one-time convertsion from cvs to bzr I
will need to also install arch and baz as well as any other packages they
depend on.

Skip
___
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

[Python-Dev] request for code review - hashlib - patch #1121611

[Gregory P. Smith]

https://sourceforge.net/tracker/index.php?func=detail&aid=1121611&group_id=5470&atid=305470

This is the hashlib module that speeds up python's md5 and sha1
support by using openssl (when available) as well as adding sha224/256
+ sha384/512 support (plus anything openssl provides).

I believe it is complete and ready to commit (hashlib-009.patch), any
objections?

compiled docs in html are here for easy perusal:

  http://electricrain.com/greg/hashlib-py25-doc/

thanks,
greg
___
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

[Python-Dev] python-dev Summary for 2005-07-16 through 2005-07-31 [draft]

[Tony Meyer]

Here's July Part Two.  As usual, if anyone can spare the time to proofread
this (it's fairly short this fortnight!), that would be great!  Please send
any corrections or suggestions to Tim (tlesher at gmail.com), Steve
(steven.bethard at gmail.com) and/or me, rather than cluttering the list.
Ta!

=
Announcements
=

-
PyPy Sprint in Heidelberg 22nd - 29th August 2005
-

Heidelberg University in Germany will host a PyPy_ sprint from 22nd August
to 29th August. The sprint  will push towards the 0.7 release of PyPy_ which
hopes to reach Python 2.4.1 compliancy and to have  full, direct translation
into a low level language, instead of reinterpretation through CPython.  If
you'd like to help out, this is a great place to start!

For more information, see PyPy's `Heidelberg sprint`_ page.

.. _PyPy: http://codespeak.net/pypy
.. _Heidelberg sprint:
http://codespeak.net/pypy/index.cgi?extradoc/sprintinfo/Heidelberg-sprint.ht
ml

Contributing thread:

- `Next PyPy sprint: Heidelberg (Germany), 22nd-29th of August
`__



zlib 1.2.3 in Python 2.4 and 2.5


Trent Mick supplied a patch for updating Python from zlib 1.2.1 to zlib
1.2.3, which eliminates some  potential security vulnerabilities. Python
will move to this new version of zlib in both the  maintenance 2.4 branch
and the main (2.5) branch.

Contributing thread:

- `zlib 1.2.3 is just out
`__

=
Summaries
=

---
Moving Python CVS to Subversion
---

Martin v. Löwis submitted `PEP 347`_, covering changing from CVS to SVN for
source code revision  control of the Python repository, and moving from
hosting the repository on sourceforge.net to  python.org.

Moving to SVN from CVS met with general favour from most people, although
most were undecided about  moving from sourceforge.net to python.org.  The
additional administration requirements of the move  were the primary
concern, and moving to an alternative host was suggested.  Martin is open to
including suggestions for alternative hosts in the PEP, but is not
interested in carrying out such  research himself; as such, if alternative
hosts are to be included, someone needs to volunteer to  collect all the
required information and submit it to Martin.

Discussion about the conversion and the move is continuing in August.

.. _PEP 347: http://www.python.org/peps/pep-0347.html

Contributing thread:

- `PEP: Migrating the Python CVS to Subversion
`__

-
Exception Hierarchy in Python 3.0
-

Brett Cannon posted the first draft of `PEP 348`_, covering reorganisation
of exceptions in Python  3.0.  The initial draft included major changes to
the hierarchy, requiring any object raised to  inherit from a certain
superclass, and changing bare 'except' clauses to catch a specific
superclass.   The latter two proposals didn't generate much comment
(although Guido vacillated between removing bare  'except' clauses and not),
but the proposed hierarchy organisation and renaming was hotly discussed.

Nick Coghlan countered each revision of Brett's maximum-changes PEP with a
minimum-changes PEP, each  evolving through python-dev discussion, and
gradually moving to an acceptable middle ground.  At  present, it seems that
the changes will be much more minor than the original proposal.

The thread branched off into comments about `Python 3.0`_ changes in
general.  The consensus was  generally that although backwards compatibility
isn't required in Python 3.0, it should only be broken  when there is a
clear reason for it, and that, as much as possible, Python 3.0 should be
Python 2.9  without a lot of backwards compatibility code.  A number of
people indicated that they were reasonably  content with the existing
exception hierarchy, and didn't feel that major changes were required.

Guido suggested that a good principle for determining the ideal exception
hierarchy is whether there's  a use case for catching the common base class.
Marc-Andre Lemburg pointed out that when migrating  code changes in
Exception names are reasonably easy to automate, but changes in the
inheritance tree  are much more difficult.

Many exceptions were discussed at length (e.g. WindowsError, RuntimeError),
with debate about whether  they should continue to exist in Python 3.0, be
renamed, or be removed.  The PEP contains the current  status for each of
these exceptions.

The PEP evolution and discussion are still continuing in August, and since
this is for Python 3.0, are  likely to be considered open for some time yet.

.. _Python 3.0: http://www.p

[Python-Dev] PEP 348 (exception reorg) revised again

[Brett Cannon]

I am sure people mainly care about the big changes inroduced by
revision 1.8 of the PEP (http://www.python.org/peps/pep-0348.html). 
So, first is that WindowsError is staying.  Enough people want it to
stay and have a legitimate use that I removed the proposal to ditch
it.

Second, I changed the bare 'except' proposal again to recommend its
removal.  I had been feeling they should just go for about a week, but
I solidified my thinking when I was talking with Alex and Anna
Martelli and managed to convince them bare 'except's should go after
Alex initially thought they should be changed to be ``except
Exception``.  This obviously goes against what Guido last said he
wanted, but I hope I can convince him to get rid of bare 'except's.

Minor stuff is fleshing out the arguments for TerminatingException (I
am sure Raymond loves that I am leaving this part in  =) and adding a
Roadmap for the transition.

-Brett
___
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

[Python-Dev] SWIG and rlcompleter

[Michael Krasnyk]

Hello all,

Recently I've found that rlcompleter does not work correctly with SWIG
generated classes.
In some cases dir(object) containes not only strings, but also type of
the object, smth like . 
And condition "word[:n] == attr" throws an exception.
Is it possible to solve this problem with following path?

--- cut ---
--- rlcompleter.py.org  2005-08-14 13:02:02.0 +0200
+++ rlcompleter.py  2005-08-14 13:18:59.0 +0200
@@ -136,8 +136,11 @@
 matches = []
 n = len(attr)
 for word in words:
-if word[:n] == attr and word != "__builtins__":
-matches.append("%s.%s" % (expr, word))
+try:
+if word[:n] == attr and word != "__builtins__":
+matches.append("%s.%s" % (expr, word))
+except:
+pass
 return matches

  def get_class_members(klass):
--- cut ---

Thanks in advance,
Michael Krasnyk

___
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

[Python-Dev] string_join overrides TypeError exception thrown in generator

[Stephen Thorne]

Hi,

An interesting problem was pointed out to me, which I have distilled
to this testcase:
def gen():
 raise TypeError, "I am a TypeError"
 yield 1

def one(): return ''.join( x for x in gen() )
def two(): return ''.join([x for x in gen()])

for x in one, two:
try:
 x()
except TypeError, e:
 print e

Expected output is:
"""
I am a TypeError
I am a TypeError
"""

Actual output is:
"""
sequence expected, generator found
I am a TypeError
"""

Upon looking at the implementation of 'string_join' in
stringobject.c[1], It's quite obvious what's gone wrong, an exception
has been triggered in PySequence_Fast, and string_join overrides that
exception, assuming that the only TypeErrors thrown by PySequence_Fast
are caused by 'orig' being a value that was an invalid sequence type,
ignoring the possibility that a TypeError could be thrown by
exhausting a generator.

seq = PySequence_Fast(orig, "");
if (seq == NULL) {
if (PyErr_ExceptionMatches(PyExc_TypeError))
PyErr_Format(PyExc_TypeError,
 "sequence expected, %.80s found",
 orig->ob_type->tp_name);
return NULL;
}

I can't see an obvious solution, but perhaps generators should get
special treatment regardless. Reading over this code it looks like the
generator is exhausted all at once, instead of incrementally..
-- 
Stephen Thorne
Development Engineer

[1] 
http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Objects/stringobject.c?rev=2.231&view=markup
___
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