Python-Dev October 2006

python-dev@python.org

103 participants
122 discussions

RELEASED Python 2.3.6, release candidate 1

by Anthony Baxter

On behalf of the Python development team and the Python community, I'm announcing the release of Python 2.3.6 (release candidate 1). Python 2.3.6 is a security bug-fix release. While Python 2.5 is the latest version of Python, we're making this release for people who are still running Python 2.3. Unlike the recently released 2.4.4, this release only contains a small handful of security-related bugfixes. See the website for more. * Python 2.3.6 contains a fix for PSF-2006-001, a buffer overrun * in repr() of unicode strings in wide unicode (UCS-4) builds. * See http://www.python.org/news/security/PSF-2006-001/ for more. This is a **source only** release. The Windows and Mac binaries of 2.3.5 were built with UCS-2 unicode, and are therefore not vulnerable to the problem outlined in PSF-2006-001. The PCRE fix is for a long-deprecated module (you should use the 're' module instead) and the email fix can be obtained by downloading the standalone version of the email package. Most vendors who ship Python should have already released a patched version of 2.3.5 with the above fixes, this release is for people who need or want to build their own release, but don't want to mess around with patch or svn. Assuming no major problems crop up, a final release of Python 2.3.6 will follow in about a week's time. Python 2.3.6 will complete python.org's response to PSF-2006-001. If you're still on Python 2.2 for some reason and need to work with UCS-4 unicode strings, please obtain the patch from the PSF-2006-001 security advisory page. Python 2.4.4 and Python 2.5 have both already been released and contain the fix for this security problem. For more information on Python 2.3.6, including download links for source archives, release notes, and known issues, please see: http://www.python.org/2.3.6 Highlights of this new release include: - A fix for PSF-2006-001, a bug in repr() for unicode strings on UCS-4 (wide unicode) builds. - Two other, less critical, security fixes. Enjoy this release, Anthony Anthony Baxter anthony(a)python.org Python Release Manager (on behalf of the entire python-dev team)

14 years, 5 months

Re: [Python-Dev] Massive test_sqlite failure on Mac OSX ... sometimes

by skip＠pobox.com

Followup #2... Yesterday I whittled my problems with test_sqlite on my OSX g5 to test_ctypes and test_sqlite: ./python.exe Lib/test/regrtest.py -l -f tests test_ctypes test_sqlite test test_sqlite failed -- errors occurred; run in verbose mode for details 1 test OK. 1 test failed: test_sqlite Today I refined things further. I renamed all the test_*.py files in Lib/ctypes/test/ until all I was left with was test_find.py. It fails if that's the only ctypes test script run: $ ls -l *.py -rw------- 1 buildbot buildbot 6870 Oct 20 06:30 __init__.py -rw------- 1 buildbot buildbot 624 Oct 20 06:30 runtests.py -rw------- 1 buildbot buildbot 3463 Oct 21 12:52 test_find.py montanaro:~/pybot/trunk.montanaro-g5/build/Lib/ctypes/test buildbot$ cd - /Library/Buildbot/pybot/trunk.montanaro-g5/build montanaro:~/pybot/trunk.montanaro-g5/build buildbot$ ./python.exe Lib/test/regrtest.py -l -f tests test_ctypes test_sqlite test test_sqlite failed -- errors occurred; run in verbose mode for details 1 test OK. 1 test failed: test_sqlite test_find.py contains checks for three OpenGL libraries on darwin: gl, glu and glut. If I comment out all those tests, test_sqlite succeeds. If any of them are enabled, test_sqlite fails. I've taken this about as far as I can. I submitted a bug report here: http://python.org/sf/1581906 Skip

14 years, 5 months

PSF Infrastructure has chosen Roundup as the issue tracker for Python development

by Brett Cannon

Forgot to send this to python-dev. =) ---------- Forwarded message ---------- From: Brett Cannon <brett(a)python.org> Date: Oct 20, 2006 1:35 PM Subject: PSF Infrastructure has chosen Roundup as the issue tracker for Python development To: python-list(a)python.org At the beginning of the month the PSF Infrastructure committee announced that we had reached the decision that JIRA was our recommendation for the next issue tracker for Python development. Realizing, though, that it was a tough call between JIRA and Roundup we said that we would be willing to switch our recommendation to Roundup if enough volunteers stepped forward to help administer the tracker, thus negating Atlassian's offer of free managed hosting. Well, the community stepped up to the challenge and we got plenty of volunteers! In fact, the call for volunteers has led to an offer for professional hosting for Roundup from Upfront Systems. The committee is currently evaluating that offer and will hopefully have a decision made soon. Once a decision has been made we will contact the volunteers as to whom we have selected to help administer the installation (regardless of who hosts the tracker). The administrators and python-dev can then begin working towards deciding what we want from the tracker and its configuration. Once again, thanks to the volunteers for stepping forward to make this happen! -Brett Cannon PSF Infrastructure committee chairman

14 years, 5 months

readlink and unicode strings (SF:1580674) Patch http://www.python.org/sf/1580674 fixes readlink's behaviour w.r.t. Unicode strings: without this patch this function uses the system default encoding instead of the filesystem encoding to convert Unicode objects to plain strings. Like os.listdir, os.readlink will now return a Unicode object when the argument is a Unicode object. What I'd like to know is if this can be backported to the 2.5 branch. The first part of this patch (use filesystem encod

by Ronald Oussoren

Patch http://www.python.org/sf/1580674 fixes readlink's behaviour w.r.t. Unicode strings: without this patch this function uses the system default encoding instead of the filesystem encoding to convert Unicode objects to plain strings. Like os.listdir, os.readlink will now return a Unicode object when the argument is a Unicode object. What I'd like to know is if this can be backported to the 2.5 branch. The first part of this patch (use filesystem encoding instead of the system encoding) is IMHO a bugfix, the second part might break existing applications (that might not expect a unicode result from os.readlink). The reason I did this patch is that os.path.realpath currently breaks when the path is a unicode string with non-ascii characters and at least one element of the path is a symlink. Ronald

14 years, 5 months

Optional type checking/pluggable type systems for Python

by Neil Dunn

Dear All I'm a Master's student at Imperial College London currently selecting a Master's thesis subject. I am exploring the possibility of "optional typing" and "pluggable type systems" (Bracha) for Python. Reading around I see that PEP 246 (object adaption) was dropped for "something better". Is this "something better" currently in production for Python 3000 or just a thinking ground. I'd like to know whether there would be any merit in exploring the project or whether this is something that is going to appear as implementation within the next 6 months (the length of my thesis). If you think it is still something worth exploring I'd plan to pick up the idea as a research project and explore implementations, probabaly in CPython or Jython. Any help with this would be great, could you please reply directly to ndunn(a)ndunn.com as I haven't subscribed to python-dev for a while now. Thanks, Neil Dunn

14 years, 5 months

Re: [Python-Dev] The "lazy strings" patch

by Mark Roberts

Hmm, I have not viewed the patch in question, but I'm curious why we wouldn't want to include such a patch if it were transparent to the user (Python based or otherwise). Especially if it increased performance without sacrificing maintainability or elegance. Further considering the common usage of strings in usual programming, I fail to see why an implementation like this would not be desirable? If there's a widely recognized argument against this, a link will likely sate my curiosity. Thanks, Mark > -------Original Message------- > From: Josiah Carlson <jcarlson(a)uci.edu> > Subject: Re: [Python-Dev] The "lazy strings" patch > Sent: 21 Oct '06 22:02 > > > Larry Hastings <larry(a)hastings.org> wrote: > > > > I've significantly enhanced my string-concatenation patch, to the point > > where that name is no longer accurate. So I've redubbed it the "lazy > > strings" patch. > [snip] > > Honestly, I don't believe that pure strings should be this complicated. > The implementation of the standard string and unicode type should be as > simple as possible. The current string and unicode implementations are, > in my opinion, as simple as possible given Python's needs. > > As such, I don't see a need to go mucking about with the standard string > implementation to make it "lazy" so as to increase performance, reduce > memory consumption, etc.. However, having written a somewhat "lazy" > string slicing/etc operation class I called a "string view", whose > discussion and implementation can be found in the py3k list, I do > believe that having a related type, perhaps with the tree-based > implementation you have written, or a simple pointer + length variant > like I have written, would be useful to have available to Python. > > I also believe that it smells like a Py3k feature, which suggests that > you should toss the whole string reliance and switch to unicode, as str > and unicode become bytes and text in Py3k, with bytes being mutable. > > > - Josiah > > _______________________________________________ > Python-Dev mailing list > Python-Dev(a)python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/mark%40pandapocket.com >

14 years, 5 months

ctypes and win64

by Thomas Heller

The _ctypes extension module does currently not even build on Win64. I'm (slowly) working on this (for AMD64, not for itanium), but it may take a good while before it is stable - It is not even fully implemented currently. The win64 msi installer installs the ctypes package anyway, but it cannot be imported. I suggest that it should be removed from the 2.5 win64 msi installers, so that at least, when it is ready, can be installed as separate package. Thanks, Thomas

14 years, 5 months

OT: fdopen on Windows question

by skip＠pobox.com

Sorry for the off-topic post. I figured someone here would know the answer and I don't have access to Windows to check experimentally. The ocrad program opens its input like so: if ( std::strcmp( infile_name, "-" ) == 0 ) infile = stdin; else infile = std::fopen( infile_name, "r" ); (SpamBayes is starting to use ocrad and PIL to extract text from image spam). Ocrad fails on Windows because the input file is opened in text mode. That "r" should be "rb". What's not clear to me is whether we can do anything about stdin. Will this work: if ( std::strcmp( infile_name, "-" ) == 0 ) infile = std::fdopen( std::fileno(stdin), "rb" ); else infile = std::fopen( infile_name, "rb" ); That is, can I change stdin from text to binary this way or is it destined to always be in text mode? Thx, Skip

14 years, 5 months

Re: [Python-Dev] 2.4.4: backport classobject.c HAVE_WEAKREFS?

by Raymond Hettinger

> The change was for clarity -- most things that have the weakref slots > filled-in will also make the flag explicit -- that makes it easier on > the brain when verifying code that checks the weakref flag. > I don't understand why you added this flag here; Perhaps my other post wasn't clear. The change wasn't necessary, so if it bugs you, feel free to take it out. Essentially, it was a "note to self" so that I didn't have to keep looking up what was implied by Py_TPFLAGS_DEFAULT. > the slightly obscure bit that requires some getting used to is > that all these flags don't really mean "I have such and such > feature" but just "I could have such and such > feature, if the corresponding tp_xxx field were set". I would like to see that cleaned-up for Py3k. Ideally, the NULL or non_NULL status of a slot should serve as its flag. Raymond

14 years, 5 months

Re: [Python-Dev] Massive test_sqlite failure on Mac OSX ... sometimes

by skip＠pobox.com

Following up on my earlier post... I svn up'd both my g5 and my g4 powerbook (both running OSX 10.4.8, gcc 4.0.0 apple build 5026), built and tested both. The test suite completed fine on my powerbook, failed on the g5. I tried running regrtest.py twice more on the g5 with the -r flag. It failed the first time, succeeded the second. I then made a series of run with the -f flag (thank you once again for that Señor Peters). I whittled it down to the following reliably failing pair: $ ./python.exe Lib/test/regrtest.py -l -f tests test_ctypes test_sqlite test test_sqlite failed -- errors occurred; run in verbose mode for details 1 test OK. 1 test failed: test_sqlite For confirmation, this pair works fine on my g4 powerbook. I've gone no further so far. It's bedtime. Maybe someone else can at least try to reproduce what I've come up with so far on other platforms or on another Mac g5. Skip

14 years, 5 months

← Newer
1
2
3
4
5
6
7
...
13
Older →

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

Python-Dev October 2006