Re: time module precision

[janeaustine50]

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 time.sleep uses its customized
way of sleeping using "select".

http://groups.google.com/groups?threadm=ud7i1c9ck.fsf%40ctwd0143.fitlinxx.com

So I think its behaviour is more complicated than single MS Sleep call,
I suppose.

> In particular, MS Sleep() takes an integer argument, giving the
number
> of milliseconds to sleep.  Your 0.0001 case falls under the special
> Sleep(0) case due to truncation in float->int conversion.
>

Oh, I see.

> Also Google on
>
> sleep thread deviation
>
> to find an interesting CodeProject article quantifying behavior on
one
> particular tester's Windows box.  Also see an article it references
> for approaches to the question "how do I handle small intervals?"
> (short course:  you probably can't, unless we're willing to throw
> money at it).

Thanks for the references.

What I want to do is waiting(not busy-delaying) for a few tens to
hundreds of microseconds in some threads. The closet solution I got is
using windows QueryPerformanceCounter (in Python, time.clock) with busy
looping checking if we have past the target time. However, that makes
the cpu usage upto almost 100%.

So the problem (waiting tens to hundreds of us without busy looping)
still remains...

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: time module precision

[janeaustine50]

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 to wait such
> brief amounts of time?
>
> I ask as someone with fairly extensive background in
> realtime software (which is basically what it sounds like
> you are trying to write here), and I suspect that you are
> either trying to achieve something that's not really possible
> on Windows XP, or that you are simply doing something that
> is entirely unnecessary, probably for good reasons but
> with too little experience of the issues involved.  Can
> you expand on your situation?
>
> -Peter

What I am trying to do is sending binary data to a serial port. Since
the device attached to the port cannot handle a continous in-flow of
data, I need to make an artificial tiny delay in-between data chunks(a
few hundreds of KBs). The delay might be a few tens to hundreds of us.

I'd like to make the transmission as fast as possible, uh.. well..
reasonably fast.

[I sort of posted this already but hasn't got it through so am
reposting it now]

Thanks

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Style guide for subclassing built-in types?

[janeaustine50]

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 list.__getitem__(self,-i-1)
>
> if __name__=='__main__':
> l=rev_wrap([1,2,3])
> assert l[0]==3
> assert list(l)==[3,2,1]
>
> l=rev_subclass([1,2,3])
> assert l[0]==3
> assert list(l)==[3,2,1]

Oh... I forgot one. assert l==[3,2,1] at this point doesn't pass
either. "print l" outputs the wrong one([1,2,3]) as well.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Style guide for subclassing built-in types?

[janeaustine50]

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__(along with "next"), __str__, __eq__ and so
on.

p.s. the reason I'm not sticking to reversed or even reverse : suppose
the size of the list is huge.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Style guide for subclassing built-in types?

[janeaustine50]

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 are right.

Actually, it's more complicated than simple reversion. The list order
should be somewhat "twisted" and the list is big.

For example,

[1,2,3,4,5,6,7,8,9,10]

--> [10,9,8,7,6,1,2,3,4,5]

so __getitem__(self,i) => __getitem__(self,-i-1) if ihttp://mail.python.org/mailman/listinfo/python-list

Re: Style guide for subclassing built-in types?

[janeaustine50]

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 be an issue.
> >>
> >>What problem are you actually trying to solve?
> >>
> >>Kent
> >>
> >
> >
> > Oh, you are right.
> >
> > Actually, it's more complicated than simple reversion. The list
order
> > should be somewhat "twisted" and the list is big.
> >
> > For example,
> >
> > [1,2,3,4,5,6,7,8,9,10]
> >
> > --> [10,9,8,7,6,1,2,3,4,5]
> >
> > so __getitem__(self,i) => __getitem__(self,-i-1) if i > otherwise __getitem__(self,i-len(size)/2)
> >
> > I'd like to have TwistedList class that takes in an original list
and
> > pretends as if it is twisted actually. However, I have to have
> > duplicate codes here and there to make it act like a "list", say
assert
> > twisted_list == [10,9,...] and for each in twisted_list and etc.
> >
> If you want a twisted 'view' of an existing list, then a wrapper
makes most sense.
>
> If, however, you only need the twisted version, why not simply
override
> list.__init__ (and extend, append etc... as required):
>
>   >>> class rev_list(list):
>   ... def __init__(self, iterable):
>   ... list.__init__(self, iterable[::-1])
>   ...
>   >>> l = rev_list([1,2,3])
>   >>> l
>   [3, 2, 1]
>
> Michael

Thank you but your advice doesn't fit in my case since I want to keep
the memory usage and the initial time minimum. iterable[::-1] would
build another list and it would take big memory and time during
reversing if iterable were huge. (and the "iterable" wouldn't be
garbage-collected because I want to keep a reference to it)

-- 
http://mail.python.org/mailman/listinfo/python-list

bsddb support for berkeley db 4.3?

[janeaustine50]

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 thought the bsddb3 project were merged into the python
project. Hasn't it?

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: bsddb support for berkeley db 4.3?

[janeaustine50]

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 is a line with:
'db4': {'libs': ('db-4.2', 'db42', 'db-4.1', 'db41',
'db-4.0', 'db4',),

But in 2.4.1 the setup.py from pybsddb project has been merged:
for x in (0,1,2,3):
db_inc_paths.append('/usr/include/db4%d' % x)


>
> > 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 thought the bsddb3 project were merged into the python
> > project. Hasn't it?
>
> It certainly has. However, the authors of bsddb3 are free to release
> new versions of their software whenever they wish to, independent of
> any Python releases. They are encouraged to merge their changes into
the
> Python CVS, but they are requested to avoid adding new features to
> Python 2.4.
> 
> Regards,
> Martin


Thank you.

--
http://mail.python.org/mailman/listinfo/python-list

Strange behaviour of __cmp__

[janeaustine50]

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

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

[janeaustine50]

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 environment using
"compile", with a different encoding from utf-8. IDLE itself has the
same problem. ( '' is treated okay
but u'' is treated wrong.)

Any suggestions or any plans in future python versions?

-- 
http://mail.python.org/mailman/listinfo/python-list

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

[janeaustine50]

[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 when I'm building an interactive environment
using
> "compile", with a different encoding from utf-8. IDLE itself has the
> same problem. ( '' is treated okay
> but u'' is treated wrong.)
>
> Any suggestions or any plans in future python versions?

I've read a posting from Martin Von Loewis mentioning trying to build
in that feature(optionally marking encoding when calling "compile").
Anyone knows how it is going on?

-- 
http://mail.python.org/mailman/listinfo/python-list

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

[janeaustine50]

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.
> >>
> >> 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 environment
> >using
> >> "compile", with a different encoding from utf-8.
>
> I don't understand this. Suppose your "different encoding" is cp125x
> (where x is a digit). Would you not do something like this?
>
> compile_input = user_input.decode('cp125x')
> code_object = compile(compile_input, ..
>
>
> >> IDLE itself has the
> >> same problem. ( '' is treated
okay
> >> but u'' is treated wrong.)
> >>
> >> Any suggestions or any plans in future python versions?
> >
> >I've read a posting from Martin Von Loewis mentioning trying to
build
> >in that feature(optionally marking encoding when calling "compile").
> >Anyone knows how it is going on?
>
> Firstly, it would help those who might be trying to help you if you
> could post a simple example: input, output, what error message, what
> you mean by 'is treated wrong' ... and when it comes to Unicode
> objects (indeed any text), show us repr(text) -- "what you see is
> often not what others see and often not what you've actually got".
>
> Secondly, are any of the contents of PEP 263 of any use to you?
> http://www.python.org/peps/pep-0263.html


Okay, I'll use one of the CJK codecs as the example. EUC-KR is the
default encoding.

>>> import sys;sys.getdefaultencoding()
'euc-kr'
>>> 'íê'
'\xc7\xd1\xb1\xdb'
>>> u'íê'
u'\ud55c\uae00'
>>> s=compile("inside=u'íê'",'','single')
>>> exec s
>>> inside #wrong
u'\xc7\xd1\xb1\xdb'
>>> s=compile(u"inside=u'íê'",'','single')
>>> exec s
>>> inside #correct
u'\ud55c\uae00'

So I reckon that the "compile" should get a unicode object. However...

C:\Python24\Lib>python code.py
> (1)?()
(Pdb) c
Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> 'íê'
'\xc7\xd1\xb1\xdb'
>>> u'íê' #wrong.. should be u'\ud55c\uae00' instead
u'\xc7\xd1\xb1\xdb'
>>> import sys;sys.getdefaultencoding()
'euc-kr'
>>> ^Z

Am I right that I assume the problem lies in the code.py(and therefore
in codeop.py)? To correct the problem, I seem to parse each string and
change the literal unicode object... Hmm... Sounds a bad approach.

-- 
http://mail.python.org/mailman/listinfo/python-list

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

[janeaustine50]

[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
> > >> 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 environment
> > >using
> > >> "compile", with a different encoding from utf-8.
> >
> > I don't understand this. Suppose your "different encoding" is
cp125x
> > (where x is a digit). Would you not do something like this?
> >
> > compile_input = user_input.decode('cp125x')
> > code_object = compile(compile_input, ..
> >
> >
> > >> IDLE itself has the
> > >> same problem. ( '' is treated
> okay
> > >> but u'' is treated wrong.)
> > >>
> > >> Any suggestions or any plans in future python versions?
> > >
> > >I've read a posting from Martin Von Loewis mentioning trying to
> build
> > >in that feature(optionally marking encoding when calling
"compile").
> > >Anyone knows how it is going on?
> >
> > Firstly, it would help those who might be trying to help you if you
> > could post a simple example: input, output, what error message,
what
> > you mean by 'is treated wrong' ... and when it comes to Unicode
> > objects (indeed any text), show us repr(text) -- "what you see is
> > often not what others see and often not what you've actually got".
> >
> > Secondly, are any of the contents of PEP 263 of any use to you?
> > http://www.python.org/peps/pep-0263.html
>
>
> Okay, I'll use one of the CJK codecs as the example. EUC-KR is the
> default encoding.
>
> >>> import sys;sys.getdefaultencoding()
> 'euc-kr'
> >>> 'íê'
> '\xc7\xd1\xb1\xdb'
> >>> u'íê'
> u'\ud55c\uae00'
> >>> s=compile("inside=u'íê'",'','single')
> >>> exec s
> >>> inside #wrong
> u'\xc7\xd1\xb1\xdb'
> >>> s=compile(u"inside=u'íê'",'','single')
> >>> exec s
> >>> inside #correct
> u'\ud55c\uae00'
>
> So I reckon that the "compile" should get a unicode object.
However...
>
> C:\Python24\Lib>python code.py
> > (1)?()
> (Pdb) c
> Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)]
on
> win32
> Type "help", "copyright", "credits" or "license" for more
information.
> (InteractiveConsole)
> >>> 'íê'
> '\xc7\xd1\xb1\xdb'
> >>> u'íê' #wrong.. should be u'\ud55c\uae00' instead
> u'\xc7\xd1\xb1\xdb'
> >>> import sys;sys.getdefaultencoding()
> 'euc-kr'
> >>> ^Z
>
> Am I right that I assume the problem lies in the code.py(and
therefore
> in codeop.py)? To correct the problem, I seem to parse each string
and
> change the literal unicode object... Hmm... Sounds a bad approach.

Oh, I forgot one more thing.

C:\Python24\Lib>python
Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> s=compile(u"'íê'",'','single')
>>> exec s #wrong. the result is encoded in utf-8 instead of euc-kr
'\xed\x95\x9c\xea\xb8\x80'
>>> s=compile(u"u'íê'",'','single')
>>> exec s #correct
u'\ud55c\uae00'
>>>

-- 
http://mail.python.org/mailman/listinfo/python-list

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

[janeaustine50]

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_input_kr = "inside=u'\xc7\xd1\xb1\xdb'"
> >>> user_input_uc = user_input_kr.decode('euc-kr')
> >>> user_input_uc
> u"inside=u'\ud55c\uae00'"
> >>> s = compile(user_input_uc, '', 'single')
> >>> exec s
> >>> inside
> u'\ud55c\uae00'
> >>> # right
>
> HTH,
> John

Thank you but there is still a problem.

|>>> s='euckr="\xc7\xd1";uni=u"\xc7\xd1"'
|>>> su=s.decode('euc-kr')
|>>> su
|u'euckr="\ud55c";uni=u"\ud55c"'
|>>> c=compile(su,'','single')
|>>> exec c
|>>> euckr,uni
|('\xed\x95\x9c', u'\ud55c')
|>>>

As you see the single's result is turned into UTF-8 encoding.

-- 
http://mail.python.org/mailman/listinfo/python-list