Mailman 3 January 2007 - Python-Dev

Problem between deallocation of modules and func_globals
by Brett Cannon Jan. 21, 2007

Jan. 21, 2007

I have discovered an issue relating to func_globals for functions and the deallocation of the module it is contained within. Let's say you store a reference to the function encodings.search_function from the 'encodings' module (this came up in C code, but I don't see why it couldn't happen in Python code). Then you delete the one reference to the module that is stored in sys.modules, leading to its deallocation. That triggers the setting of None to every value in encodings.__dict__. Oops, … [View More]

4 12

Weekly Python Patch/Bug Summary
by Kurt B. Kaiser Jan. 20, 2007

Jan. 20, 2007

Patch / Bug Summary ___________________ Patches : 423 open ( +2) / 3539 closed ( +9) / 3962 total (+11) Bugs : 960 open ( -3) / 6446 closed (+20) / 7406 total (+17) RFE : 258 open ( +3) / 249 closed ( +3) / 507 total ( +6) New / Reopened Patches ______________________ Add aliases for latin7/9/10 charsets (2007-01-13) http://python.org/sf/1634778 opened by Christoph Zwerschke htonl et al accept negative ints (2007-01-14) CLOSED http://python.org/sf/1635058 … [View More]

1 0

Deletion order when leaving a scope?
by Larry Hastings Jan. 20, 2007

Jan. 20, 2007

I just ran a quickie experiment and determined: when leaving a scope, variables are deleted FIFO, aka in the same order they were created. This surprised me; I'd expected them to be deleted LIFO, aka last first. Why is it thus? Is this behavior an important feature or an irrelevant side-effect? Cheers, /larry/

7 6

BangPycon 2007 - First Indian Python Conference : Call for Participation
by Anush Shetty Jan. 19, 2007

Jan. 19, 2007

Hi, The BangPypers (Bangalore Python Users Group) invite you to submit a proposal to present a technical paper or tutorial, or to host a meeting or BOF session at the first Indian Python conference here at St Josephs PG College Auditorium in Bangalore,India on March 3rd,2007. There are no fixed guidelines except for the below. 1) The talk has to be on a Pythonic Topic 2) It will be restricted to 45 mts with buffer for Q& A -10 mts 3) Though not mandatory, preference will be given to … [View More]

1 0

adding _Py prefix to names in 2.5.1?
by Neal Norwitz Jan. 19, 2007

Jan. 19, 2007

http://python.org/sf/1637022 points out a problem caused by the lack of a _Py prefix on Ellipsis. Most (all?) of the new AST names are not prefixed. These are all meant to be internal names. Are there any issues with changing this? If we do so, it means that any module built with 2.5 that is using these names will fail to work in 2.5.1. No code outside the core *should* be using these names. Assuming there is no dissent, does some budding Python developer want to take on a patch? This … [View More]

4 3

Re: [Python-Dev] buglet in long("123\0", 10)
by Calvin Spealman Jan. 19, 2007

Jan. 19, 2007

Added a check in test_long.LongTest.test_misc() that long("123\0", 10) fails properly and adapted the patch to int_new to long_new. I get this weird feeling that if its impossible for the function (PyLong_FromString) to know if its being given bad data, having know way to know if the string is supposed to continue past the zero-byte, then doesn't it make sense to say that the function by design is broken? Anyway, here is the patch. Index: Objects/longobject.c ===================================… [View More]================================ --- Objects/longobject.c (revision 53406) +++ Objects/longobject.c (working copy) @@ -3287,10 +3287,27 @@ return PyLong_FromLong(0L); if (base == -909) return PyNumber_Long(x); - else if (PyString_Check(x)) + if (PyString_Check(x)) { + /* Since PyLong_FromString doesn't have a length parameter, + * check here for possible NULs in the string. */ + char *string = PyString_AS_STRING(x); + if (strlen(string) != PyString_Size(x)) { + /* create a repr() of the input string, + * just like PyLong_FromString does. */ + PyObject *srepr; + srepr = PyObject_Repr(x); + if (srepr == NULL) + return NULL; + PyErr_Format(PyExc_ValueError, + "Invalid literal for long() with base %d: %s", + base, PyString_AS_STRING(srepr)); + Py_DECREF(srepr); + return NULL; + } return PyLong_FromString(PyString_AS_STRING(x), NULL, base); + } #ifdef Py_USING_UNICODE - else if (PyUnicode_Check(x)) + if (PyUnicode_Check(x)) return PyLong_FromUnicode(PyUnicode_AS_UNICODE(x), PyUnicode_GET_SIZE(x), base); @@ -3439,3 +3456,4 @@ long_new, /* tp_new */ PyObject_Del, /* tp_free */ }; + Index: Lib/test/test_long.py =================================================================== --- Lib/test/test_long.py (revision 53406) +++ Lib/test/test_long.py (working copy) @@ -299,6 +299,8 @@ slicemin, slicemax = X()[-2L**100:2L**100] self.assertEqual(X()[slicemin:slicemax], (slicemin, slicemax)) + self.assertRaises(ValueError, long, "123\0", 10) + # ----------------------------------- tests of auto int->long conversion def test_auto_overflow(self): ### END PATCH On 1/15/07, Neal Norwitz <nnorwitz(a)gmail.com> wrote: > Calvin, > > Was Guido's answer enough or did you want some more? If you take a > look at the svn rev I sent, I think it should be pretty easy to come > up with a patch for long too. > > Getting the size won't help (exactly), since the problem is the diff > between strlen() and the size. You can see this in the int() fix. > > Let me know if you have any questions. It would be great if you could > produce a patch. > > Cheers, > n > -- > On 1/14/07, Calvin Spealman <ironfroggy(a)gmail.com> wrote: > > Is it a more general problem that null-terminated strings are used > > with data from strings we specifically allow to contain null bytes? > > Perhaps a migration of *FromString() to *FromStringAndSize() > > functions, or taking Python string object pointers, would be a more > > general solution to set as a goal, so this sort of thing can't crop up > > down the road, again. > > > > I know I'm still very uninitiated in the internals of CPython, so > > anyone please correct me if my thoughts here are against any on-going > > policy or reasoning. > > > > On 1/14/07, Neal Norwitz <nnorwitz(a)gmail.com> wrote: > > > SVN rev 52305 resolved Bug #1545497: when given an explicit base, > > > int() did ignore NULs embedded in the string to convert. > > > > > > However, the same fix wasn't applied for long(). > > > > > > n > > > > > > On 1/13/07, Guido van Rossum <guido(a)python.org> wrote: > > > > What's wrong with this session? :-) > > > > > > > > Python 2.6a0 (trunk:53416, Jan 13 2007, 15:24:17) > > > > [GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin > > > > Type "help", "copyright", "credits" or "license" for more information. > > > > >>> int('123\0') > > > > Traceback (most recent call last): > > > > File "<stdin>", line 1, in <module> > > > > ValueError: null byte in argument for int() > > > > >>> int('123\0', 10) > > > > Traceback (most recent call last): > > > > File "<stdin>", line 1, in <module> > > > > ValueError: invalid literal for int() with base 10: '123\x00' > > > > >>> long('123\0') > > > > Traceback (most recent call last): > > > > File "<stdin>", line 1, in <module> > > > > ValueError: null byte in argument for long() > > > > >>> long('123\0', 10) > > > > 123L > > > > >>> > > > > > > > > -- > > > > --Guido van Rossum (home page: http://www.python.org/~guido/) > > > > _______________________________________________ > > > > 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/nnorwitz%40gmail.com > > > > > > > _______________________________________________ > > > 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/ironfroggy%40gmail.com > > > > > > > > > -- > > Read my blog! I depend on your acceptance of my opinion! I am interesting! > > http://ironfroggy-code.blogspot.com/ > > _______________________________________________ > > 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/nnorwitz%40gmail.com > > > -- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://ironfroggy-code.blogspot.com/ [View Less]

2 2

Testers wanted: mailbox.py bugfix
by A.M. Kuchling Jan. 18, 2007

Jan. 18, 2007

http://www.python.org/sf/1599254 is a bug in the mailbox.py module that affects single-file mailbox formats (mbox, Babyl, MMDF) and can cause data loss. A proposed fix, mailbox-unified-patch, is attached to the bug. If you use mailbox.py for modifying mailboxes in the above formats, can you please test the patch and report if there are any problems? The bug is pretty complicated, and such bugs in the mailbox.py (and the necessary fixes) make me nervous. Some more testing would be very reassuring. --amk

2 2

Re: [Python-Dev] [Python-3000] dict.items as attributes [Was: The bytes type]
by Jim Jewett Jan. 18, 2007

Jan. 18, 2007

Other than dict.items (and .keys and .values) returning a non-list, are there any other cases where the Py3K idiom can't already be used in (or at least backported to) Py 2.x? Is there a chance that this special case could be handled by an import hook in py 2.6? For example 2.6 could have an additional LOAD_ATTR_PY3 opcode that just handles the special cases before delegating to the normal LOAD_ATTR. It would be generated instead of LOAD_ATTR whenever >>> from __future__ import … [View More]

4 4

Pythn 2.5 buildbots do not build anymore?
by Thomas Heller Jan. 18, 2007

Jan. 18, 2007

Why don't the Python 2.5 buildbots build anymore? http://www.python.org/dev/buildbot/2.5/ Thanks, Thomas

2 1

Re: [Python-Dev] The bytes type
by Phillip J. Eby Jan. 18, 2007

Jan. 18, 2007

At 07:47 AM 1/16/2007 -0800, Guido van Rossum wrote: >On 1/16/07, James Y Knight <foom(a)fuhm.net> wrote: > > On Jan 15, 2007, at 8:02 AM, Thomas Wouters wrote: > > > There seems to be rather a lot of confusion. No one is suggesting > > > Python 3.0 be anything less for the sake of backward compatibility. > > > Instead, it has been suggested Python 2.6 (and possibly 2.7) be > > > something *more* in order to provide for an easier upgrade path. … [View More]No > > > compromises in Python 3.0. > > > > True: nobody is suggesting python 3.0 be anything less. But, I am > > indeed suggesting that Python 3.0 be something *more*: I am > > suggesting that people keep in mind the ease of writing of a program > > which can run on both 2.5 and 3.0. And wherever possible, act so as > > to preserve that ease. That may indeed involve a "compromise" in 3.0. > >I'm not keen on compromises in 3.0, but without specific proposals I >don't see why we're arguing. So, please, what specific thing(s) are >you proposing we do in 3.0? Please make a list of specifics rather >than attempting at specifying a general rule to match things that >could go into the list; you've tried the latter and I still don't know >what you want. I think what he's saying boils down to two things: * Don't remove any feature for which an alternative doesn't already exist in 2.5 * Don't change APIs (e.g. items()) Now, I'm not sure these goals are achievable with respect to 2.5. I think we'd be better off adding compatibility features in 2.6. To be honest, the items() and keys() thing personally baffles me. If they're supposed to be *views* on the underlying dictionary, wouldn't it make more sense for them to be *attributes* instead of methods? I.e. dict.items and dict.keys. Then, we could provide that feature in 2.6, and drop the availability of the callable forms in 3.0. Then you could write code like: for k,v in somedict.items: ... And have it work in 2.6 and 3.0. Meanwhile, .items() would still return a list in 2.6 (but be warnable about with a -3 switch), but go away entirely in 3.0. It's not a panacea, but at least would make it *possible* to write code that runs on both 3.0 and some 2.x version. Without having at least *some* 2.x version that can run 3.x code, I think there is little chance of 3.0 becoming viable. You've been comparing this to Zope 2/Zope 3, but in that world there is something called "Five" that lets you do Zope 3 things inside of Zope 2, so you have some chance of porting your code in an incremental fashion, without having to leap everything over in one go. You've cited JoS on your decision not to do 3.0 as a ground-up rewrite, so perhaps you'll find this other JoS article relevant here: """It turns out that what was stopping people from switching to Excel was that everybody else they worked with was still using Lotus 123. They didn't want a product that would create spreadsheets that nobody else could read: a classic Chicken and Egg problem. When you're the lone Excel fan in a company where everyone else is using 123, even if you love Excel, you can't switch until you can participate in the 123 ecology.""" http://www.joelonsoftware.com/articles/fog0000000052.html The analogy isn't perfect, because we are not so much trying to provide backward compatibility in "Excel" as to add *forward* compatibility to "123", but you get the idea. [View Less]

5 5