Mailman 3 June 2001 - Python-Dev

Re: [Python-Dev] Shouldn't I be able to print Unicode objects?
by Michael Hudson June 5, 2001

June 5, 2001

Skip Montanaro <skip(a)pobox.com> writes: > Just catching up on a little c.l.py and I noticed the effbot's response to > the Unicode degree inquiry. I tried to create and print one and got this: > > % python > Python 2.1.1a1 (#9, Jun 4 2001, 11:32:33) > [GCC 2.96 20000731 (Linux-Mandrake 8.0 2.96-0.48mdk)] on linux2 > Type "copyright", "credits" or "license" for more information. > >>> u"\N{DEGREE SIGN}" > u'\xb0' > >>> print u"\N{DEGREE SIGN}" > > Traceback (most recent call last): > File "<stdin>", line 1, in ? > UnicodeError: ASCII encoding error: ordinal not in range(128) > > Shouldn't I be able to print arbitrary Unicode objects? What am I missing > (this time)? The encoding: >>> print u"\N{DEGREE SIGN}".encode("latin1") ° Cheers, Skippy's little helper. -- In case you're not a computer person, I should probably point out that "Real Soon Now" is a technical term meaning "sometime before the heat-death of the universe, maybe". -- Scott Fahlman <sef(a)cs.cmu.edu>

2 1

SourceForget Python Foundry needs help
by Guido van Rossum June 5, 2001

June 5, 2001

The Python Foundry at SF could use a hand. If you're interested in helping out, please write to Chuck Esterbrook, below! --Guido van Rossum (home page: http://www.python.org/~guido/) ------- Forwarded Message Date: Tue, 05 Jun 2001 14:12:07 -0400 From: Chuck Esterbrook <ChuckEsterbrook(a)yahoo.com> To: guido(a)python.org Subject: SourceForget Python Foundry Hi Guido, I'm one of the admins of the SourceForge Python Foundry. In case you're not familiar with them, foundries are simply SF web portals centered around a particular topic. Admins can customize the HTML text and graphics and SourceForge stats are integrated on the side. I haven't had much time to give the Python Foundry the attention it deserves. I was wondering if you knew of anyone who had the inclination, time and energy to join the Foundry as an admin and expand it. If it becomes strong enough, we could possibly get it featured on the sidebar of the main SF page, which would then bring more attention to Python and its related projects. The foundry is at: http://sourceforge.net/foundry/python-foundry/ - -Chuck ------- End of Forwarded Message

1 0

Shouldn't I be able to print Unicode objects?
by Skip Montanaro June 5, 2001

June 5, 2001

Just catching up on a little c.l.py and I noticed the effbot's response to the Unicode degree inquiry. I tried to create and print one and got this: % python Python 2.1.1a1 (#9, Jun 4 2001, 11:32:33) [GCC 2.96 20000731 (Linux-Mandrake 8.0 2.96-0.48mdk)] on linux2 Type "copyright", "credits" or "license" for more information. >>> u"\N{DEGREE SIGN}" u'\xb0' >>> print u"\N{DEGREE SIGN}" Traceback (most recent call last): File "<stdin>", line 1, in ? UnicodeError: ASCII encoding error: ordinal not in range(128) Shouldn't I be able to print arbitrary Unicode objects? What am I missing (this time)? Skip

1 0

Re: [Python-Dev] Happy event
by Samuele Pedroni June 5, 2001

June 5, 2001

> Subject: Re: [Python-Dev] Happy event > To: Barrett(a)stsci.edu (Paul Barrett) > Cc: python-dev(a)python.org > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > From: aahz(a)rahul.net (Aahz Maruch) > X-BeenThere: python-dev(a)python.org > X-Mailman-Version: 2.0.5 (101270) > List-Help: <mailto:python-dev-request@python.org?subject=help> > List-Post: <mailto:python-dev@python.org> > List-Subscribe: <http://mail.python.org/mailman/listinfo/python-dev>, <mailto:python-dev-request@python.org?subject=subscribe> > List-Id: Python core developers <python-dev.python.org> > List-Unsubscribe: <http://mail.python.org/mailman/listinfo/python-dev>, <mailto:python-dev-request@python.org?subject=unsubscribe> > List-Archive: <http://mail.python.org/pipermail/python-dev/> > Date: Tue, 5 Jun 2001 07:41:10 -0700 (PDT) > > Paul Barrett wrote: > > Uche Ogbuji wrote: > >> Guido: > >>> > >>> Also, don't expect Jeremy to be too responsive to email for the next > >>> 6-8 weeks. :) > >> > >> *twin* girls? Try 6-8 years. > > > > Actually girls are fine until about 13, after that I expect Jeremy > > won't be too responsive. Something about hormones and such. > > Are you trying to imply that there's a difference between girls and > boys? > > compressing-a-five-screen-rant-down-to-a-single-sentence-ly y'rs > -- The simple fact that we are still moving from the previous bad habit of considering them different to considering them equal just implies/evolves differences. A neutral view-point would be: the N/S ratio between gender-phisiological- differences and the overall interpersonal differences is very big, at least when considering the whole personality and not single aspects. There is no established truth, we are just longing for equiblibrium: in the actual transition phase boys and girls are under different kind of cultural tensions related to self-identification,etc ... this makes differences. regards, Samuele Pedroni.

1 0

Re: [Python-Dev] One more dict trick
by Uche Ogbuji June 5, 2001

June 5, 2001

> "Eric S. Raymond" <esr(a)thyrsus.com>: > > > I think it's significant that MMX > > instructions and so forth entered the Intel line to support *games*, > > not Navier-Stokes calculations. > > But when version 1.0 of FlashFlood! comes out, requiring > high-quality real-time hydrodynamics simulation, > Navier-Stokes calculations will suddenly become very > important... Shoot, I thought that was what Microsoft Hailstorm was all about. Path integrals about the atmospheric isobars, and all that... -- Uche Ogbuji Principal Consultant uche.ogbuji(a)fourthought.com +1 303 583 9900 x 101 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA XML strategy, XML tools (http://4Suite.org), knowledge management

1 0

Happy event
by Guido van Rossum June 5, 2001

June 5, 2001

I just wanted to send a note about a happy event in the Python family. Jeremy Hylton and his wife became the proud parents of twin girls on Sunday June 3rd. Please join Pythonlabs and Digital Creations in congratulating them, and wishing them much joy and luck. Also, don't expect Jeremy to be too responsive to email for the next 6-8 weeks. :) --Guido van Rossum (home page: http://www.python.org/~guido/)

1 0

Re: [Python-Dev] another dict crasher
by Michael Hudson June 5, 2001

June 5, 2001

"Tim Peters" <tim.one(a)home.com> writes: > >> However, then an adversarial user can construct a case that never > >> terminates. > > > I seem to have done this - it was odd, though - it only loops when I > > bump the dict to fairly enormous preportions for reasons I don't > > really (want to) understand. > > Pass it on. I deliberately "started over" via a recursive call instead of a > goto so that an offending program would eventually die with a stack fault > instead of just running forever. So if you're seeing something run forever, > it may be a different problem. I left it running overnight, and it terminated! (with a KeyError). I can't say I really understand what's going on, but I'm in Exam Hell at the moment (for the last time! Yippee!), so don't have any spare cycles to think about it hard. Anyway, this is what I was running: dict = {} # let's force dict to malloc its table for i in range(1,10000): dict[i] = i hashcode = 0 class Machiavelli2: def __eq__(self, other): global hashcode d2 = dict.copy() dict.clear() hashcode += 1 for k,v in d2.items(): dict[k] = v return 1 def __hash__(self): return hashcode dict[Machiavelli2()] = Machiavelli2() print dict[Machiavelli2()] If you thought my last test case was contrived, I look forward to you finding adjectives for this one... Cheers, M. -- (ps: don't feed the lawyers: they just lose their fear of humans) -- Peter Wood, comp.lang.lisp

2 2

Re: [Python-checkins] CVS: python/dist/src/Modules stropmodule.c,2.81,2.82
by Greg Stein June 5, 2001

June 5, 2001

On Mon, May 14, 2001 at 07:14:46PM -0700, Guido van Rossum wrote: > Update of /cvsroot/python/python/dist/src/Modules > In directory usw-pr-cvs1:/tmp/cvs-serv26415/Modules > > Modified Files: > stropmodule.c > Log Message: > Add warnings to the strop module, for to those functions that really > *are* obsolete; three variables and the maketrans() function are not > (yet) obsolete. > > Add a compensating warnings.filterwarnings() call to test_strop.py. > > Add this to the NEWS. Something that I ran into the other day... >>> ob = some_object_implementing_the_buffer_interface >>> string.find(ob, '.') (fails because ob does not define the .find method) >>> strop.find(ob, '.') (succeeds) The point is that strop uses the t# to get a ptr/len pair to do its work. Thus, it can work on many things that export the buffer interface. Dropping strop means we no longer have many of those functions. Instead, the functionality must be copied to *every* object that implements the buffer interface. We can say ob.find() now, but we can't say find(ob) any longer. And saying that all objects (which implement the buffer API) must now implement a bunch of "standard" methods is awfully burdensome. In my particular case, I was trying to do a find on a BufferObject referring to a subset of another object. Blam. No good. Thankfully, when I did a find() on a mmap object, it worked simply because mmaps happen to define a .find method. [ of course, the find method on an mmap was totally broken, but I checked in a fix for that (last week or so) ] So... my question is: is there any way that we can retain a generic find() (and similar functions from the string/strop module) that operates on any type that implements the buffer API? Maybe there is some way we can do a mixin for Python types? e.g. "this mixin implements some standard methods for 8-bit character data (using the buffer API), which can be mixed into new Python types" That would reduce the burden for new types. Thoughts? Cheers, -g -- Greg Stein, http://www.lyra.org/

9 35

One more dict trick
by Tim Peters June 5, 2001

June 5, 2001

If anyone has an app known or suspected to be sensitive to dict timing, please try the patch here. Best I've been able to tell, it's a win. But it's a radical change in approach, so I don't want to rush it. This gets rid of the polynomial machinery entirely, along with the branches associated with updating the things, and the dictobject struct member holding the table's poly. Instead it relies on that i = (5*i + 1) % n is a full-period RNG whenever n is a power of 2 (that's what guarantees it will visit every slot), but perturbs that by adding in a few bits from the full hash code shifted right each time (that's what guarantees every bit of the hash code eventually influences the probe sequence, avoiding simple quadratic-time degenerate cases).

8 18

Re: [Python-Dev] readline not getting built when .so symlink doesn't exist
by Michael Hudson June 5, 2001

June 5, 2001

Skip Montanaro <skip(a)pobox.com> writes: > [my readline woes snipped] > > Michael> Hmm. Does compiling a proggie > > Michael> $ gcc foo.c -lreadline > > Michael> work? It doesn't here if I move libreadline.so & libreadline.a > Michael> out of the way. > > Yup, it does: > > beluga:tmp% cc -o foo foo.c -lreadline -ltermcap > beluga:tmp% ./foo > >>sdfsdfsdf > sdfsdfsdf > > (This after deleting both /lib/libreadline.so and /lib/libhistory.so.) Odd. What does the output of $ gcc -o foo foo.c -lreadline -ltermcap -Wl,--verbose look like? In particular the bit at the end where you get things like: attempt to open /usr/lib/gcc-lib/i386-redhat-linux/2.95.1/libreadline.so failed attempt to open /usr/lib/gcc-lib/i386-redhat-linux/2.95.1/libreadline.a failed attempt to open /usr/i386-redhat-linux/lib/libreadline.so failed attempt to open /usr/i386-redhat-linux/lib/libreadline.a failed attempt to open /usr/bin/../lib/libreadline.so succeeded -lreadline (/usr/bin/../lib/libreadline.so) (this is more for my personal curiosity than any important reason). > Got that. I just noticed that "rpm -q --whatprovides /lib/libreadline.so" > does list readline-devel as the provider. I just reinstalled it using > --force. Now the .so symlinks are there. Go figure... No :-) > Oh well, probably ought to drop it unless another Mandrake user complains. Sounds reasonable. Cheers, M. -- After a heavy night I travelled on, my face toward home - the comma being by no means guaranteed. -- paraphrased from cam.misc

2 1