headers
A.M. Kuchling | 8 Oct 02:42

2.5.3: assessing commits

I've begun the task of assessing the 2.6 commits, but the job is
unexpectedly large.

What I did:

* Took the output of 'svn log -r60999:66717'.  (2.5.2 was branched
  from rev. 60999, so I'm ignoring commits to the trunk before 2.5.2 was 
  branch, which may miss some things.)

* Wrote a little script to explode the log into a separate file for each 
  commit.  This resulted in about 2200 files.

* Did a long series of 'grep' and 'rm' commands to remove irrelevant files.
  For example, if the commit touches abc.py, bytesobject.c, bytearrayobject.c,
  etc. it was removed.

* Wrote a little script to find commits that only touch the docs, and moved them
  aside.

At this point I still have 1191 files left.  Many of these commits are
still irrelevant, but this is a lot for me to look through.  A tarball
with the remaining commits is at

      http://www.amk.ca/files/python/2.6-changes.tgz

Can we parallelize the job?  One person could take commits starting
with '01', another with '02', etc.  Or each person could assess the
commits they made.

--amk
(Continue reading)

Permalink | Reply | 0 comments |
headers
"Martin v. =?iso-8859-1?q?L=F6wis=22?= | 7 Oct 09:25

Python 2.5.3: call for patches

Within a few weeks, we will release Python 2.5.3. This will be the last
bug fix release of Python 2.5, afterwards, future releases of 2.5 will
only include security fixes, and no binaries (for Windows or OSX) will
be provided anymore (from python.org).

In principle, the release will include all changes that are already on
the release25-maint branch in subversion [1]. If you think that specific
changes should be considered, please create an issue in the bug tracker
[2], and label it with the 2.5.3 version. Backports of changes that
are already released in Python 2.6 but may apply to 2.5 are of
particular interest.

Regards,
Martin

[1] http://svn.python.org/projects/python/branches/release25-maint/
[2] http://bugs.python.org/
_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply | 4 comments |
headers
Neal Norwitz | 6 Oct 19:55

status of 2.5

Should we plan to put out a final 2.5 release?  If so, should we
continue to backport fixes (like Martin's removal of Alpha in
setup.py)?  My preference is that we do put out a final 2.5 that has
all accumulated bug fixes.  Then close the branch.  That way if we put
out a security release for 2.5, it will be clean and easy.

n
_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply | 9 comments |
headers
Steve Holden | 6 Oct 08:41

[Fwd: In Python 2.6, bytes is str]

This does make it look rather as though bytes == str was a decision
whose consequences weren't fully appreciated before implementation.

Was this horror anticipated?

regards
 Steve

-------- Original Message --------
Subject: In Python 2.6, bytes is str
Date: Sun, 05 Oct 2008 22:30:17 -0700
From: Bryan Olson <fakeaddress <at> nowhere.org>
Organization: at&t http://my.att.net/
To: python-list <at> python.org
Newsgroups: gmane.comp.python.general

Python 3 has the 'bytes' type, which the string type I've long wanted in
various languages. Among other advantages, it is immutable, and
therefore bytes objects can be dict keys. There's a mutable version too,
called "bytearray".

In Python 2.6, the name 'bytes' is defined, and bound to str. The 2.6
assignment presents some pitfalls. Be aware.

Consider constructing a bytes object as:

    b = bytes([68, 255, 0])

In Python 3.x, len(b) will be 3, which feels right.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Barry Scott | 5 Oct 20:14

porting pycxx and pysvn to python 3.0 hit a problem

I have a version of PyCXX ported to python 3.0 rc1 and its passing  
its tests.
I'm porting pysvn to python 3.0 rc1 and hit an odd problem.

Given this dict:

	wc_status_kind_map = {
    	 	pysvn.wc_status_kind.added: 'A',
     		pysvn.wc_status_kind.replaced: 'R',
     		pysvn.wc_status_kind.unversioned: '?',
     	}

This fails:

	wc_status_kind_map[ pysvn.wc_status_kind.unversioned ]

With:

	KeyError: <wc_status_kind.unversioned>

Clearly I have a bug in the implementation of pysvn.wc_status_kind and
could do with some suggestions on what to check please.

I've assumed that if my objects support tp_hash and tp_compare
they can be used as keys to a dictionary. My test scripts shows
hash() and cmp() working.

Why does "key in wc_status_kind_wc" work when I use an object returned
by keys() by not when I use pysvn.wc_status_kind.unversioned?
(Continue reading)

Permalink | Reply | 8 comments |
headers
Nick Coghlan | 5 Oct 12:00

Re: if-syntax for regular for-loops

Matthew Hawkins wrote:
> If there's another way of doing this I'd like to hear it.

The pass statement is still the right way to denote an empty block (the
compiler is already able to detect that and optimise the code
appropriately).

My tangential comment was based on the fact that this keyword could, in
theory, be replaced with the ellipsis notation often used in pseudo-code
to denote "real code goes here".

I don't think pursuing such a switch is actually a good idea - it was
just odd to notice that the Py3k interpreter would quite happily execute
the example code in my postscript when I had really only intended to
write it as pseudo-code with sections missing.

Cheers,
Nick.

--

-- 
Nick Coghlan   |   ncoghlan <at> gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
            http://www.boredomandlaziness.org
_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
(Continue reading)

Permalink | Reply | 2 comments |
headers
Aaron Gallagher | 4 Oct 12:44

Pickle, 3.0, and recursion

Hi,

I posted a bug ticket on bugs.python.org, specifically #3119. Link: http://bugs.python.org/issue3119
The original issue is that the default Pickler can exceed the maximum  
recursion depth for structures that are fairly nested. There's a patch  
attached to the ticket that fixes this behavior by using a generator- 
based callstack. Unfortunately, this completely changes the API of  
Pickler.

As far as I know, such major API changes would not be accepted in to  
3.0 at this point. I tried to come up with an alternate version of the  
patch that just added a subclass, but I haven't been able to think of  
a way to do that that doesn't involve a lot of code duplication. It's  
easy to just copy-paste most of Pickler and give it a new name and  
change the API, but that's hardly an optimal solution.

Does anybody else have any thoughts about how this could be better  
implemented? I think this is a decent implementation, but at this  
point, it's too severe of a change. Maybe somebody else has a better  
idea of how this could fit cleanly into the existing Pickler API or  
write a subclass without a lot of messy duplication.
_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply | 0 comments |
headers
Amaury Forgeot d'Arc | 4 Oct 00:56

Suspect intermittent failure in buildbots

I've noticed an error that comes up from time to time in python 3.0 buildbots.
The error is always similar to this one:

Traceback (most recent call last):
  File "E:\cygwin\home\db3l\buildarea\3.0.bolen-windows\build\lib\test\test_io.py",
line 900, in testBasicIO
    self.assertEquals(f.write("abc"), 3)
  File "E:\cygwin\home\db3l\buildarea\3.0.bolen-windows\build\lib\io.py",
line 1486, in write
    b = encoder.encode(s)
  File "E:\cygwin\home\db3l\buildarea\3.0.bolen-windows\build\lib\encodings\ascii.py",
line 22, in encode
    return codecs.ascii_encode(input, self.errors)[0]
AttributeError: 'NoneType' object has no attribute 'ascii_encode'

The most recent is here:
http://www.python.org/dev/buildbot/3.0/AMD64%20W2k8%203.0/builds/843/step-test/0

but this already happened on various buildbots:
http://www.google.fr/search?q=%27NoneType%27+object+has+no+attribute+encode+site:mail.python.org/pipermail/python-checkins&filter=0

"x86 XP-4 3.0", "amd64 gentoo 3.0", "AMD64 W2k8 3.0", "x86 W2k8 3.0",
"g4 osx.4 3.0", "OS X x86 3.0"
"x86 XP-3 trunk"

yes, even on trunk!
Every time, a "codecs" global module variable has been reset to None,
either in a codec module (encoding/ascii.py, encoding/mac_roman.py) or
in test_io.py.
Every time, io.py is not far (which may be normal, it must have the
(Continue reading)

Permalink | Reply | 1 comment |
headers
Leif Walsh | 4 Oct 00:24

Re: if-syntax for regular for-loops

On Fri, Oct 3, 2008 at 12:33 PM, Andreas Nilsson <adde <at> trialcode.com> wrote:
> Thanks for the pointer!
> I don't buy the argument that newlines automagically improves readability
> though. You also get increased nesting suggesting something interesting is
> happening where it isn't and that hurts readability.
> And as Vitor said, all other constructions of the form 'for i in items' can
> have if-conditions attached to them, it's really not that far-fetched to
> assume that the loop behaves the same way. Consistency good, surprises bad.

Yeah, I know what you mean, and I kind of liked the idea of adding the
if statement to the for loop (for consistency, if nothing else), but
it's been discussed before, and plenty of people have made the same
argument.  Probably not worth it.

--

-- 
Cheers,
Leif
_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply | 0 comments |
headers
Benjamin Peterson | 3 Oct 23:22

for __future__ import planning

So now that we've released 2.6 and are working hard on shepherding 3.0
out the door, it's time to worry about the next set of releases. :)

I propose that we dramatically shorten our release cycle for 2.7/3.1
to roughly a year and put a strong focus stabilizing all the new
goodies we included in the last release(s). In the 3.x branch, we
should continue to solidify the new code and features that were
introduced. One 2.7's main objectives should be binding 3.x and 2.x
ever closer.

--

-- 
Cheers,
Benjamin Peterson
"There's nothing quite as beautiful as an oboe... except a chicken
stuck in a vacuum cleaner."
_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply | 30 comments |
headers
Python tracker | 3 Oct 18:06

Summary of Python tracker Issues


ACTIVITY SUMMARY (09/26/08 - 10/03/08)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue 
number.  Do NOT respond to this message.

 2074 open (+39) / 13779 closed (+16) / 15853 total (+55)

Open issues with patches:   678

Average duration of open issues: 712 days.
Median duration of open issues: 1835 days.

Open Issues Breakdown
   open  2058 (+38)
pending    16 ( +1)

Issues Created Or Reopened (56)
_______________________________

pprint._safe_repr is not general enough in one instance          09/26/08
       http://bugs.python.org/issue3976    created  erickt                    

Check PyInt_AsSsize_t/PyLong_AsSsize_t error                     09/26/08
CLOSED http://bugs.python.org/issue3977    created  haypo                     
       patch                                                                   

ZipFileExt.read() can be incredibly slow                         09/26/08
       http://bugs.python.org/issue3978    created  lightstruk
(Continue reading)

Permalink | Reply | 0 comments |

Gmane