Mailman 3 January 2002 - Python-Dev

Re: [Python-checkins] CVS: python/dist/src/Objects fileobject.c,2.141,2.142
by Michael Hudson Jan. 4, 2002

Jan. 4, 2002

Neal Norwitz <nnorwitz(a)users.sourceforge.net> writes: > Update of /cvsroot/python/python/dist/src/Objects > In directory usw-pr-cvs1:/tmp/cvs-serv2511/Objects > > Modified Files: > fileobject.c > Log Message: > SF Patch #494863, file.xreadlines() should raise ValueError if file is closed > > This makes xreadlines behave like all other file methods > (other than close() which just returns). Does this qualify as a bugfix? Cheers, M.

3 2

Re: [Python-Dev] Unicode support in getargs.c
by Jack Jansen Jan. 4, 2002

Jan. 4, 2002

Sigh, I let myself be drawn in again, despite my previous assertion.... Recently, "Martin v. Loewis" <martin(a)v.loewis.de> said: > > For this it should be as backward-compatible as possible, i.e. if > > some API expects a unicode filename and I pass "a.out" it should > > interpret it as u"a.out". > > That works fine with the current API. No, it doesn't, that is the whole point of why I started this thread!!!! If the Python wrapper around the API uses PyArg_Parse("u") then it will barf on "a.out", if the wrapper uses "u#" it will not barf but in stead completely misinterpret the StringObject containing "a.out", interpreting it as the binary representation of 3 unicode characters or something far worse! Yes, there is a workaround with the "O" format and three more function calls, but I wouldn't call that "works fine"... > > Using Python StringObjects as binary buffers is also far less common > > than using StringObjects to store plain old strings, so if either of > > these uses bites the other it's the binary buffer that needs to > > suffer. > > This is a conclusion I cannot agree with. Most strings are really > binary, if you look at them closely enough :-) I'm not sure I understand this remark. If you made it just for the smiley: never mind. If you really don't agree: please explain why. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

2 1

Re: [Python-Dev] release for 2.1.2, plus 2.2.1...
by Michael Hudson Jan. 4, 2002

Jan. 4, 2002

Anthony Baxter <anthony(a)interlink.com.au> writes: > As far as 2.2.1 goes, I'm happy to keep on the patch czar role. Fine, so long as you get on with it :) I was going to merge this weeks bugfixes this morning... > Is trying for a release before the conference too aggressive a > timeframe? There seem to be a number of niggles that'd be nice to > have fixed... That's probably a reasonable timeframe, so long as the niggles actually do get fixed by then. Picklability of the struct_seq thingies is one that might be a bit of a pain. Cheers, M. -- 31. Simplicity does not precede complexity, but follows it. -- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html

1 0

object equality vs identity, in and dicts idioms and speed
by Samuele Pedroni Jan. 4, 2002

Jan. 4, 2002

Hi, [Ok this is maybe more a comp.lang.python thing but ...] If I'm correct dictionaries are based on equality and so the "in" operator. AFAIK if I'm interested in a dictionary working on identity I should wrap my objects ... Now what is the fastest idiom equivalent to: obj in list when I'm interested in identity (is) and not equality? That was the comp.lang.python part, now my impression is that in any case when I'm interested in identity and not equality I have to workaround, that means I will never directly have the performace of the equality idioms. Although my experience say that the equality case is the most common, I wonder whether some directy support for the identity case isn't worth, because it is rare but typically then you would like some speed. [Yes, I have some concrete context but this is long so unless strictly requested ...] Am I missing something? Opinions. regards.

3 6

pydoc.org updated
by Ka-Ping Yee Jan. 3, 2002

Jan. 3, 2002

I would like to apologize for allowing pydoc.org to fall behind Python development for the past few months. At last count, it only gave documentation for Python 2.1b1 and 1.5.2. Today, pydoc.org has been updated to provide all the pydoc-generated documentation pages for Python 1.5.2, 1.6, 2.1, and 2.2 final. The search feature lets you search the names of all the modules, packages, functions, classes, and methods, and the text of all their docstrings. I hope it can be a useful resource for you. Any thoughts you have on making it better would be very welcome, of course. -- ?!ng

1 0