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:
> 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?
Sigh, I let myself be drawn in again, despite my previous
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
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
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.
31. Simplicity does not precede complexity, but follows it.
-- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html
[Ok this is maybe more a comp.lang.python thing
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.
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
I hope it can be a useful resource for you. Any thoughts you have
on making it better would be very welcome, of course.