Python-Dev January 2005

python-dev@python.org

101 participants
123 discussions

Allowing slicing of iterators
by Nick Coghlan 26 Jan '05

26 Jan '05

I just wrote a new C API function (PyItem_GetItem) that supports slicing for arbitrary iterators. A patch for current CVS is at http://www.python.org/sf/1108272 For simple indices it does the iteration manually, and for extended slices it returns an itertools.islice object. As a trivial example, here's how to skip the head of a zero-numbered list: for i, item in enumerate("ABCDEF")[1:]: print i, item Is this idea a non-starter, or should I spend my holiday on Wednesday finishing it off and writing the documentation and tests for it? Regards, Nick. -- Nick Coghlan | ncoghlan(a)email.com | Brisbane, Australia --------------------------------------------------------------- http://boredomandlaziness.skystorm.net

6 11

RELEASED Python 2.3.5, release candidate 1
by Anthony Baxter 26 Jan '05

26 Jan '05

On behalf of the Python development team and the Python community, I'm happy to announce the release of Python 2.3.5 (release candidate 1). Python 2.3.5 is a bug-fix release. See the release notes at the website (also available as Misc/NEWS in the source distribution) for details of the bugs squished in this release. Assuming no major problems crop up, a final release of Python 2.3.5 will follow in about a week's time. Python 2.3.5 is the last release in the Python 2.3 series, and is being released for those people who still need to use Python 2.3. Python 2.4 is a newer release, and should be preferred if possible. From here, bugfix releases are switching to the Python 2.4 branch - a 2.4.1 will follow 2.3.5 final. For more information on Python 2.3.5, including download links for various platforms, release notes, and known issues, please see: http://www.python.org/2.3.5 Highlights of this new release include: - Bug fixes. According to the release notes, more than 50 bugs have been fixed, including a couple of bugs that could cause Python to crash. Highlights of the previous major Python release (2.3) are available from the Python 2.3 page, at http://www.python.org/2.3/highlights.html Enjoy the new release, Anthony Anthony Baxter anthony(a)python.org Python Release Manager (on behalf of the entire python-dev team)

1 0

Deprecating modules (python-dev summary for early Dec, 2004)
by Jim Jewett 25 Jan '05

25 Jan '05

> It was also agreed that deleting deprecated modules was not needed; it breaks > code and disk space is cheap. > It seems that no longer listing documentation and adding a deprecation warning > is what is needed to properly deprecate a module. By no longer listing > documentation new programmers will not use the code since they won't know > about it.[*] And adding the warning will let old users know that they should be > using something else. [* Unless they try to maintain old code. Hopefully, they know to find the documentation at python.org.] Would it make sense to add an attic (or even "deprecated") directory to the end of sys.path, and move old modules there? This would make the search for non-deprecated modules a bit faster, and would make it easier to verify that new code isn't depending (perhaps indirectly) on any deprecated features. New programmers may just browse the list of files for names that look right. They're more likely to take the first (possibly false) hit if the list is long. I'm not the only one who ended up using markupbase for that reason. Also note that some shouldn't-be-used modules don't (yet?) raise a deprecation warning. For instance, I'm pretty sure regex_syntax and and reconvert are both fairly useless without deprecated regex, but they aren't deprecated on their own -- so they show up as tempting choices in a list of library files. (Though reconvert does something other than I expected, based on the name.) I understand not bothering to repeat the deprecation for someone who is using them correctly, but it would be nice to move them to an attic. Bastion and rexec should probably also raise Deprecation errors, if that becomes the right way to mark them deprecated. (They import fine; they just don't work -- which could be interpreted as merely an "XXX not done yet" comment.) -jJ

2 2

state of 2.4 final release
by Anthony Baxter 25 Jan '05

25 Jan '05

I didn't see any replies to the last post, so I'll ask again with a better subject line - as I said last time, as far as I'm aware, I'm not aware of anyone having done a fix for the issue Tim identified ( http://www.python.org/sf/1069160 ) So, my question is: Is this important enough to delay a 2.4 final for? My plan is currently to release it _this_ _Tuesday_, so I really need an answer soon... I've attached Tim's original message at the end here. At the moment, I'm inclined to say "if it's not fixed, it won't kill us". But that's admittedly my own biases - threading bugs annoy me <wink> I'm happy to defer to more knowlegable types, though - is this so bad that it merits delaying the release? I can't make time to look at it before then - I'm still writing slides for a couple of talks at OSDC. Anthony From: Tim Peters <tim.peters(a)gmail.com> To: Python Dev <python-dev(a)python.org> Date: 2004-11-19 13:08 This one is a puzzler. See http://www.python.org/sf/1069160 for details. The short course is that the PyThreadState_SetAsyncExc() implementation fell into a common trap, and can cause segfaults under rare conditions (like every other Python thread segfault bug we've ever had). This is easily repaired (although I've got no interest in doing the coding, or even in contriving a test case -- this was an obvious "by eyeball" bug). The puzzle is how to treat this wrt 2.4. Since it's a critical bug, I suppose it "should" force another release candidate. OTOH, this is a C-only API (there's no exposure from Python) that's never used in the core. We could add code to make it segfault every time <wink>, and nothing in the distribution would notice. OTOH, if we broke its intended behavior while fixing the bug, we'd never know that either. "Never used in the core" means never -- the function isn't tested. On the third hand, it's a simple function with an obvious segfault mode that has an obvious fix. I'll leave it to the release manager <wink>.

4 5

PyCon: The Spam Continues ;-)
by Steve Holden 25 Jan '05

25 Jan '05

Dear python-dev: The current (as of even date) summary of my recent contributions to Python -dev appears to be spam about PyCon. Not being one to break habits, even not those of a lifetime sometimes, I spam you yet again to show you what a beautiful summary ActiveState have provided (I don't know whether this URL is cacheable or not): <http://aspn.activestate.com/ASPN/Mail/Browse/ByAuthor/python-dev?author=cHl…> If I remember Trent Lott (?) described at an IPC the SQL Server database that drives this system, and it was a great example of open source technology driving a proprietary (but I expect (?) relatively portable) repository. Since I have your attention (and if I haven't then it really doesn't matter what I write hereafter, goodbye ...) I will also point out that the current top hit on Google for "Microsoft to Provide PyCon Opening Keynote" is [Python-Dev] Microsoft to Provide PyCon Opening Keynote by Steve Holden (you can repeat the search to see whether this assertion is true as you read this mail, and read the opening keynote announcement [I hope...]). Space at PyCon is again enlarged, but it certainly isn't infinite. I'd love to see it filled in my third and last year as chair. The program committee have worked incredibly hard to make sure we all have to choose between far more technical content than a single individual can possibly take in on their own. They [disclaimer: I was program chair, but this should be kudos for the committee membership - without whom this conference would have failed in many dimensions] they have succeeded so well we all, I hope, have to agonize between two sumptuous but equidistant technical bales of hay. Only by providing such rich choice can we ensure that an even broader community forms around Python, with free interchange between the technical communities of the proprietary and open source worlds, and equitable participation in the benefit. Sorry I haven't made many CVS contributions lately. We really should be showcasing more Python technologies via www.python.org. targeted-marketing-to-talented-professionals-ly y'rs - steve -- Steve Holden http://www.holdenweb.com/ Python Web Programming http://pydish.holdenweb.com/ Holden Web LLC +1 703 861 4237 +1 800 494 3119

4 6

RE: [Python-Dev] Allowing slicing of iterators
by Batista, Facundo 25 Jan '05

25 Jan '05

[Guido van Rossum] #- > As a trivial example, here's how to skip the head of a #- zero-numbered list: #- > #- > for i, item in enumerate("ABCDEF")[1:]: #- > print i, item #- > #- > Is this idea a non-starter, or should I spend my holiday #- on Wednesday finishing #- > it off and writing the documentation and tests for it? #- #- Since we already have the islice iterator, what's the point? It seems #- to me that introducing this notation would mostly lead to confuse #- users, since in most other places a slice produces an independent #- *copy* of the data. I think that breaking the common idiom... for e in something[:]: something.remove(e) is a no-no... . Facundo Bitácora De Vuelo: http://www.taniquetil.com.ar/plog PyAr - Python Argentina: http://pyar.decode.com.ar/ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ADVERTENCIA. La información contenida en este mensaje y cualquier archivo anexo al mismo, son para uso exclusivo del destinatario y pueden contener información confidencial o propietaria, cuya divulgación es sancionada por la ley. Si Ud. No es uno de los destinatarios consignados o la persona responsable de hacer llegar este mensaje a los destinatarios consignados, no está autorizado a divulgar, copiar, distribuir o retener información (o parte de ella) contenida en este mensaje. Por favor notifíquenos respondiendo al remitente, borre el mensaje original y borre las copias (impresas o grabadas en cualquier medio magnético) que pueda haber realizado del mismo. Todas las opiniones contenidas en este mail son propias del autor del mensaje y no necesariamente coinciden con las de Telefónica Comunicaciones Personales S.A. o alguna empresa asociada. Los mensajes electrónicos pueden ser alterados, motivo por el cual Telefónica Comunicaciones Personales S.A. no aceptará ninguna obligación cualquiera sea el resultante de este mensaje. Muchas Gracias.

2 1

2.3 BRANCH FREEZE imminent!
by Anthony Baxter 25 Jan '05

25 Jan '05

As those of you playing along at home with python-checkins would know, we're going to be cutting a 2.3.5c1 shortly (in about 12 hours time). Can people not in the set of the normal release team (you know the drill) please hold off on checkins to the branch from about 0000 UTC, 26th January (in about 12 hours time). After than, we'll have a one-week delay from release candidate until the final 2.3.5 - until then, please be ultra-conservative with checkins to the 2.3 branch (unless you're also volunteering to cut an emergency 2.3.6 <wink>). Assuming nothing horrible goes wrong, this will be the final release of Python 2.3. The next bugfix release will be 2.4.1, in a couple of months. (As usual - any questions, comments or whatever, let me know via email, or #python-dev on irc.freenode.net) Anthony -- Anthony Baxter <anthony(a)interlink.com.au> It's never too late to have a happy childhood.

1 0

Speed up function calls
by Neal Norwitz 24 Jan '05

24 Jan '05

I added a patch to SF: http://python.org/sf/1107887 I would like feedback on whether the approach is desirable. The patch adds a new method type (flags) METH_ARGS that is used in PyMethodDef. METH_ARGS means the min and max # of arguments are specified in the PyMethodDef by adding 2 new fields. This information can be used in ceval to call the method. No tuple packing/unpacking is required since the C stack is used. The benefits are: * faster function calls * simplify function call machinery by removing METH_NOARGS, METH_O, and possibly METH_VARARGS * more introspection info for C functions (ie, min/max arg count) (not implemented) The drawbacks are: * the defn of the MethodDef (# args) is separate from the function defn * potentially more error prone to write C methods??? I've measured between 13-22% speed improvement (debug build on Operton) when doing simple tests like: ./python ./Lib/timeit.py -v 'pow(3, 5)' I think the difference tends to be fairly constant at about .3 usec per loop. Here's a portion of the patch to show the difference between conventions: -builtin_filter(PyObject *self, PyObject *args) +builtin_filter(PyObject *self, PyObject *func, PyObject *seq) { - PyObject *func, *seq, *result, *it, *arg; + PyObject *result, *it, *arg; int len; /* guess for result list size */ register int j; - if (!PyArg_UnpackTuple(args, "filter", 2, 2, &func, &seq)) - return NULL; - # the are no other changes between METH_O and METH_ARGS - {"abs", builtin_abs, METH_O, abs_doc}, + {"abs", builtin_abs, METH_ARGS, abs_doc, 1, 1}, - {"filter", builtin_filter, METH_VARARGS, filter_doc}, + {"filter", builtin_filter, METH_ARGS, filter_doc, 2, 2}, Neal

4 8

Microsoft to Provide PyCon Opening Keynote
by Steve Holden 23 Jan '05

23 Jan '05

Dear Python Colleague: The PyCon Program Committee is happy to announce that the opening keynote speech, at 9:30 am on Wednesday March 23 will be: Python on the .NET Platform, by Jim Hugunin, Microsoft Corporation Jim Hugunin is well-known in the Python world for his pioneering work on JPython (now Jython), and more recently for the IronPython .NET implementation of Python. Jim joined Microsoft's Common Language Runtime team in August last year to continue his work on Iron Python and further improve the CLR's support for dynamic languages like Python. I look forward to hearing what Jim has to say, and hope that you will join me and the rest of the Python community at PyCon DC 2005, at George Washington University from March 23-25, with a four-day sprint starting on Saturday March 19. Early bird registration rates are still available for a few more days. Go to http://www.python.org/moin/PyConDC2005/Schedule for the current schedule, and register at http://www.python.org/pycon/2005/ regards Steve Holden Chairman, PyCON DC 2005 -- PyCon DC 2005: The third Python Community Conference http://www.pycon.org/ http://www.python.org/pycon/ The scoop on Python implementations and applications

1 0

Weekly Python Patch/Bug Summary
by Kurt B. Kaiser 23 Jan '05

23 Jan '05

Patch / Bug Summary ___________________ Patches : 273 open ( +1) / 2746 closed ( +9) / 3019 total (+10) Bugs : 797 open ( +4) / 4789 closed (+12) / 5586 total (+16) RFE : 166 open ( +1) / 141 closed ( +0) / 307 total ( +1) New / Reopened Patches ______________________ fix distutils.install.dump_dirs() with negated options (2005-01-17) CLOSED http://python.org/sf/1103844 opened by Wummel Add O_SHLOCK/O_EXLOCK to posix (2005-01-17) http://python.org/sf/1103951 opened by Skip Montanaro setup.py --help and --help-commands altered. (2005-01-17) http://python.org/sf/1104111 opened by Titus Brown new-style exceptions (2005-01-18) http://python.org/sf/1104669 opened by Michael Hudson misc doc typos (2005-01-18) CLOSED http://python.org/sf/1104868 opened by DSM chr, ord, unichr documentation updates (2004-10-31) http://python.org/sf/1057588 reopened by mike_j_brown Faster commonprefix in macpath, ntpath, etc. (2005-01-19) http://python.org/sf/1105730 opened by Jimmy Retzlaff get rid of unbound methods (mostly) (2005-01-17) CLOSED http://python.org/sf/1103689 opened by Guido van Rossum Updated "Working on Cygwin" section (2005-01-22) http://python.org/sf/1107221 opened by Alan Green Add Thread.isActive() (2005-01-23) http://python.org/sf/1107656 opened by Alan Green Speed up function calls/can add more introspection info (2005-01-23) http://python.org/sf/1107887 opened by Neal Norwitz Patches Closed ______________ fix distutils.install.dump_dirs() with negated options (2005-01-17) http://python.org/sf/1103844 closed by theller ast-branch: fix for coredump from new import grammar (2005-01-11) http://python.org/sf/1100563 closed by kbk Shadow Password Support Module (2002-07-10) http://python.org/sf/579435 closed by loewis misc doc typos (2005-01-18) http://python.org/sf/1104868 closed by fdrake extending readline functionality (2003-02-11) http://python.org/sf/684500 closed by fdrake self.button.pack() in tkinter.tex example (2005-01-03) http://python.org/sf/1094815 closed by fdrake Clean up discussion of new C thread idiom (2004-09-20) http://python.org/sf/1031233 closed by fdrake Description of args to IMAP4.store() in imaplib (2004-12-12) http://python.org/sf/1084092 closed by fdrake get rid of unbound methods (mostly) (2005-01-17) http://python.org/sf/1103689 closed by gvanrossum New / Reopened Bugs ___________________ email.base64MIME.header_encode vs RFC 1522 (2005-01-17) http://python.org/sf/1103926 opened by Ucho wishlist: os.feed_urandom(input) (2005-01-17) http://python.org/sf/1104021 opened by Zooko O'Whielacronx configure doesn't set up CFLAGS properly (2005-01-17) http://python.org/sf/1104249 opened by Bryan O'Sullivan Bugs in _csv module - lineterminator (2004-11-24) http://python.org/sf/1072404 reopened by fresh Wrong expression with \w+? (2005-01-18) CLOSED http://python.org/sf/1104608 opened by rengel Bug in String rstrip method (2005-01-18) CLOSED http://python.org/sf/1104923 opened by Rick Coupland Undocumented implicit strip() in split(None) string method (2005-01-19) http://python.org/sf/1105286 opened by YoHell Warnings in Python.h with gcc 4.0.0 (2005-01-19) http://python.org/sf/1105699 opened by Bob Ippolito incorrect constant names in curses window objects page (2005-01-19) http://python.org/sf/1105706 opened by dcrosta null source chars handled oddly (2005-01-19) http://python.org/sf/1105770 opened by Reginald B. Charney bug with idle's stdout when executing load_source (2005-01-20) http://python.org/sf/1105950 opened by imperialfists os.stat int/float oddity (2005-01-20) CLOSED http://python.org/sf/1105998 opened by George Yoshida README of 2.4 source download says 2.4a3 (2005-01-20) http://python.org/sf/1106057 opened by Roger Erens semaphore errors from Python 2.3.x on AIX 5.2 (2005-01-20) http://python.org/sf/1106262 opened by The Written Word slightly easier way to debug from the exception handler (2005-01-20) http://python.org/sf/1106316 opened by Leonardo Rochael Almeida os.makedirs() ignores mode parameter (2005-01-21) http://python.org/sf/1106572 opened by Andreas Jung split() takes no keyword arguments (2005-01-21) http://python.org/sf/1106694 opened by Vinz os.pathsep is wrong on Mac OS X (2005-01-22) CLOSED http://python.org/sf/1107258 opened by Mac-arena the Bored Zo Bugs Closed ___________ --without-cxx flag of configure isn't documented. (2003-03-12) http://python.org/sf/702147 closed by bcannon presentation typo in lib: 6.21.4.2 How callbacks are called (2004-12-22) http://python.org/sf/1090139 closed by gward rfc822 Deprecated since release 2.3? (2005-01-15) http://python.org/sf/1102469 closed by anthonybaxter codecs.open and iterators (2003-03-20) http://python.org/sf/706595 closed by doerwalter Wrong expression with \w+? (2005-01-18) http://python.org/sf/1104608 closed by niemeyer Wrong expression with \w+? (2005-01-18) http://python.org/sf/1104608 closed by effbot Bug in String rstrip method (2005-01-18) http://python.org/sf/1104923 closed by tim_one No documentation for zipimport module (2003-12-03) http://python.org/sf/853800 closed by fdrake distutils/tests not installed (2004-12-30) http://python.org/sf/1093173 closed by fdrake urllib2 doesn't handle urls without a scheme (2005-01-07) http://python.org/sf/1097834 closed by fdrake vertical bar typeset horizontal in docs (2004-08-13) http://python.org/sf/1008998 closed by fdrake write failure ignored in Py_Finalize() (2004-11-27) http://python.org/sf/1074011 closed by loewis os.stat int/float oddity (2005-01-20) http://python.org/sf/1105998 closed by loewis os.pathsep is wrong on Mac OS X (2005-01-22) http://python.org/sf/1107258 closed by bcannon

1 0

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

2022

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 January 2005