Re: Anyway to designating the encoding of the "source" for compile?

John Machin wrote: > On 16 May 2005 16:44:30 -0700, [EMAIL PROTECTED] wrote: [snip] > > > Like I said, *ALL* you have to do (like in any other Unicode-aware > app) is decode your user input into Unicode (you *don't* need to parse > bits and pieces of it) and feed it in ... like this: > > >>> user_i

Re: Anyway to designating the encoding of the "source" for compile?

[EMAIL PROTECTED] wrote: > John Machin ìì: > > On 16 May 2005 10:15:22 -0700, [EMAIL PROTECTED] wrote: > > > > >[EMAIL PROTECTED] wrote: > > >> Python's InteractiveInterpreter uses the built-in compile > function. > > >> > > >> According to the ref. manual, it doesn't seem to concern about the > >

Re: Anyway to designating the encoding of the "source" for compile?

John Machin ìì: > On 16 May 2005 10:15:22 -0700, [EMAIL PROTECTED] wrote: > > >[EMAIL PROTECTED] wrote: > >> Python's InteractiveInterpreter uses the built-in compile function. > >> > >> According to the ref. manual, it doesn't seem to concern about the > >> encoding of the source string. > >> > >>

Re: Anyway to designating the encoding of the "source" for compile?

[EMAIL PROTECTED] wrote: > Python's InteractiveInterpreter uses the built-in compile function. > > According to the ref. manual, it doesn't seem to concern about the > encoding of the source string. > > When I hand in an unicode object, it is encoded in utf-8 automatically. > It can be a problem wh

Anyway to designating the encoding of the "source" for compile?

Python's InteractiveInterpreter uses the built-in compile function. According to the ref. manual, it doesn't seem to concern about the encoding of the source string. When I hand in an unicode object, it is encoded in utf-8 automatically. It can be a problem when I'm building an interactive enviro

Strange behaviour of __cmp__

See the following... >>> class X(list): def __cmp__(self,anX): print "comparing from",id(self) return cmp(self.v,anX.v) >>> x1=X() >>> x2=X() >>> x1.v=-1 >>> x2.v=100 >>> x1>x2 False >>> x1x2 or x1http://mail.python.org/mailman/listinfo/python-list

Re: bsddb support for berkeley db 4.3?

Martin v. Löwis wrote: > [EMAIL PROTECTED] wrote: > > It doesn't seem like the python 2.4(and the recent 2.4.1) support > > berkeley db 4.3. > > What makes you say that? It builds fine for me. Oh, it doesn't work with 2.4(I tried this one) but with 2.4.1 seemingly. In the setup.py from 2.4 there

bsddb support for berkeley db 4.3?

It doesn't seem like the python 2.4(and the recent 2.4.1) support berkeley db 4.3. (4.3 fixes some deadlock bugs I occasionally encounter using 4.2.) bsddb3(at pybsddb.sf.net) already supports 4.3 since last December(but doesn't explicitly support win32 -- see the assert statement in setup.py). I

Re: Style guide for subclassing built-in types?

Michael Spencer wrote: > [EMAIL PROTECTED] wrote: > > Kent Johnson wrote: > > > >>[EMAIL PROTECTED] wrote: > >> > >>>p.s. the reason I'm not sticking to reversed or even reverse : > > > > suppose > > > >>>the size of the list is huge. > >> > >>reversed() returns an iterator so list size shouldn't b

Re: Style guide for subclassing built-in types?

Kent Johnson wrote: > [EMAIL PROTECTED] wrote: > > p.s. the reason I'm not sticking to reversed or even reverse : suppose > > the size of the list is huge. > > reversed() returns an iterator so list size shouldn't be an issue. > > What problem are you actually trying to solve? > > Kent > Oh, you

Re: Style guide for subclassing built-in types?

Fuzzyman wrote: > I guess print is using the __repr__ (or __str__ ?) methods of lsit - > which you will need to override as well. > > Regards, > > Fuzzy > http://www.voidspace.org.uk/python/index.shtml Thank you but the problem is that I have to express my intention in duplicate places -- __iter__

Re: Style guide for subclassing built-in types?

Jane Austine wrote: > Please see the following code: > > class rev_wrap(object): > def __init__(self,l): > self.l=l > def __getitem__(self,i): > return self.l[-i-1] > > class rev_subclass(list): > def __getitem__(self,i): > return

Re: time module precision

Peter Hansen wrote: > [EMAIL PROTECTED] wrote: > > So the problem (waiting tens to hundreds of us without busy looping) > > still remains... > > That's actually not a "problem", it's your solution > to a problem. Can you describe the _real_ problem, what > you are trying to do? _Why_ do you want

Re: time module precision

Tim Peters wrote: [snip] > Python's time.sleep() calls the Win32 API Sleep() function on Windows. > All behavior is inherited from the latter. See MS's docs: > > Oh, after a short research, I found that tim