imaplib thread method anomaly

Hi, I was looking at the thread functionality of IMAP4rev1 servers with the threading extension. Here is my output with debug=8 : 02:23.02 > GDJB3 UID THREAD references UTF-8 (SEEN) 02:23.02 < * THREAD (3)(2)(4)(1) 02:23.02 matched r'\* (?P[A-Z-]+)( (?P.*))?' => ('THREAD', ' (3)(2)

Re: Anomaly in time.clock()

On Mar 22, 10:03 pm, Tim Roberts <[EMAIL PROTECTED]> wrote: > Godzilla <[EMAIL PROTECTED]> wrote: > > >Just found out that win32api.GetTickCount() returns a tick count in > >milli-second since XP started. Not sure whether that is reliable. > >Anyone uses that for calculating elapsed time? > > What

Re: Anomaly in time.clock()

Godzilla <[EMAIL PROTECTED]> wrote: > >Just found out that win32api.GetTickCount() returns a tick count in >milli-second since XP started. Not sure whether that is reliable. >Anyone uses that for calculating elapsed time? What do you mean by "reliable"? The tick count is updated as part of schedu

Re: Anomaly in time.clock()

On 21 mar, 03:13, Godzilla <[EMAIL PROTECTED]> wrote: > Just found out that win32api.GetTickCount() returns a tick count in > milli-second since XP started. Not sure whether that is reliable. > Anyone uses that for calculating elapsed time? I use GetTickCount on other languages because it's easy

Re: Anomaly in time.clock()

On 20 mar, 08:47, Godzilla <[EMAIL PROTECTED]> wrote: > Thanks Ross and John for your help. I apologise for the code I posted > earlier not being the full picture of what I was trying to achieve. I > had instantiated multiple instances of elapseTime class and each of > them gets called approximate

Re: Anomaly in time.clock()

Just found out that win32api.GetTickCount() returns a tick count in milli-second since XP started. Not sure whether that is reliable. Anyone uses that for calculating elapsed time? -- http://mail.python.org/mailman/listinfo/python-list

Re: Anomaly in time.clock()

Thanks Ross and John for your help. I apologise for the code I posted earlier not being the full picture of what I was trying to achieve. I had instantiated multiple instances of elapseTime class and each of them gets called approximately the same time. Below is the updated code: import time impo

Re: Anomaly in time.clock()

On Mar 19, 11:17 pm, Godzilla <[EMAIL PROTECTED]> wrote: > Hi John, > > I am using time.clock to calculate the elapsed time. Below is an > example of what I was trying to do: > > import time > import thread Silly me, not being able to infer that from your initial post! [snip] > > But the time.clo

Re: Anomaly in time.clock()

Godzilla <[EMAIL PROTECTED]> wrote: >But the time.clock() sometimes return a value of between -3.5 to -4.5 >seconds backward. There are race conditions in your code. In between the time you execute "curTime = time.clock()" and calculate "curTime - self.timeStamp" in one thread, the other thread

Re: Anomaly in time.clock()

Hi John, I am using time.clock to calculate the elapsed time. Below is an example of what I was trying to do: import time import thread class elapseTime: def __init__(self, name=''): self.name = name self.timeStamp = None self.checkTimeFlag = False thread.start_new_t

Re: Anomaly in time.clock()

On Mar 18, 9:43 pm, Godzilla <[EMAIL PROTECTED]> wrote: > Thanks Roel. If there is a way to pass in the PRESERVE_PRECISION > constant in the python time.clock library, that would be great Re-read Roel's message. Something like PRESERVE_PRECISION is to be passed to whatever is setting up DirectX.

Re: Anomaly in time.clock()

Thanks Roel. If there is a way to pass in the PRESERVE_PRECISION constant in the python time.clock library, that would be great. But I'm afraid it's not possible. I think I will change away from using time.clock() from now on... seems too edgy to me. Thank you for sharing your experience with me n

Re: Anomaly in time.clock()

Godzilla schreef: > Hello, > > I have been reading a thread about time.clock() going backward, which > is exactly what I am seeing... the thread generally leaning toward the > problem is caused by multi-processor machines. But I am seeing it at a > single CPU computer, and running XP. > > The err

Anomaly in time.clock()

Hello, I have been reading a thread about time.clock() going backward, which is exactly what I am seeing... the thread generally leaning toward the problem is caused by multi-processor machines. But I am seeing it at a single CPU computer, and running XP. The error I am seeing between two very cl

Re: file reading anomaly

Final update: problem solved. In the big script, the snippet was reading depstats.txt which hadn't been closed. Sorry for all the bother. Gerry -- http://mail.python.org/mailman/listinfo/python-list

Re: file reading anomaly

Update: The PC seems to not be a factor (same problem exist on two PCs). The entire script does some computation and writes depstats.txt. The code snippet below attempts to read depstats.txt and write another file. When the code below is run stand-alone, it succeeds. When run in-line as p

file reading anomaly

Python 2.5, Windows XP. I have a 48-line text file written by a Windows python script, I try to read it as follows: f = open ("depstats.txt", "r", 0) for index, line in enumerate(f): print index, len(line), len(line.split()) f.close() On one PC, this runs without any problem. On an

Re: logging anomaly

On Jun 26, 3:48 pm, Jesse James <[EMAIL PROTECTED]> wrote: > > 2007-06-26 07:59:38,192 vor.uploader INFO - start uploading file: > 7_Canyons_Clip_1.flv > 2007-06-26 07:59:38,206 vor.uploader INFO - done uploading file: > 7_Canyons_Clip_1.flv > > I know this is wrong because this is a large

logging anomaly

I have some fairly simply code in a turbogears controller that uploads files. In this code, I inserted a 'start uploading' and a 'done uploading' log record like this: logger.info('- start uploading file: '+Filename) # copy file to specified location. while 1:

Re: Regex anomaly

Bryan> We could define the __or__ method for RegExFlags, but really, Bryan> or-ing together integer flags is old habit from low-level Bryan> languages. Really we should pass a set of flags. Good idea. Added to the Python3.0Suggestions wiki page: http://wiki.python.org/moin/Pytho

Re: Regex anomaly

Roy Smith wrote: > LOL, and you'll be LOL too when you see the problem :-) > > You can't give the re.I flag to reCompiled.match(). You have to give > it to re.compile(). The second argument to reCompiled.match() is the > position where to start searching. I'm guessing re.I is defined as 2, > wh

Re: Regex anomaly

In article <[EMAIL PROTECTED]>, Roy Smith <[EMAIL PROTECTED]> wrote: > In article <[EMAIL PROTECTED]>, > "Sam Pointon" <[EMAIL PROTECTED]> wrote: > > > Would this particular inconsistency be candidate for change in Py3k? > > Seems to me the pos and endpos arguments are redundant with slicing, >

Re: Regex anomaly

In article <[EMAIL PROTECTED]>, "Sam Pointon" <[EMAIL PROTECTED]> wrote: > Would this particular inconsistency be candidate for change in Py3k? > Seems to me the pos and endpos arguments are redundant with slicing, > and the re.match function would benefit from having the same arguments > as patt

Re: Regex anomaly

On 3 Jan 2006 02:20:52 -0800, Sam Pointon <[EMAIL PROTECTED]> wrote: > Would this particular inconsistency be candidate for change in Py3k? > Seems to me the pos and endpos arguments are redundant with slicing, Being able to specify the start and end indices for a search is important when working

Re: Regex anomaly

Would this particular inconsistency be candidate for change in Py3k? Seems to me the pos and endpos arguments are redundant with slicing, and the re.match function would benefit from having the same arguments as pattern.match. Of course, this is a backwards-incompatible change; that's why I suggest

Re: Regex anomaly

> mike klaas <[EMAIL PROTECTED]> writes: > Thanks guys, that is probably the most ridiculous mistake I've made in > years I was taken too :-). This is quite embarassing, considering that I remember reading a big thread in python devel list about this a while back! Ganesan -- Ganesan Rajag

Re: Regex anomaly

In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote: > Thanks guys, that is probably the most ridiculous mistake I've made in > years > > -Mike If that's the more ridiculous you can come up with, you're not trying hard enough. I've done much worse. -- http://mail.python.org/mailman/list

Re: Regex anomaly

Thanks guys, that is probably the most ridiculous mistake I've made in years -Mike -- http://mail.python.org/mailman/listinfo/python-list

Re: Regex anomaly

> mike klaas <[EMAIL PROTECTED]> writes: > In [48]: import re > In [49]: reStr = r"([a-z]+)://" > In [51]: against = "http://www.hello.com"; > In [53]: re.match(reStr, against).groups() > Out[53]: ('http',) > In [54]: re.match(reStr, against, re.I).groups() > Out[54]: ('http',) > In [55]: reCo

Re: Regex anomaly

<[EMAIL PROTECTED]> wrote: > >Hello, > >Has anyone has issue with compiled re's vis-a-vis the re.I (ignore >case) flag? I can't make sense of this compiled re producing a >different match when given the flag, odd both in it's difference from >the uncompiled regex (as I thought the uncompiled api w

Re: Regex anomaly

On 2 Jan 2006 21:00:53 -0800, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Has anyone has issue with compiled re's vis-a-vis the re.I (ignore > case) flag? I can't make sense of this compiled re producing a > different match when given the flag, odd both in it's difference from > the uncompile

Regex anomaly

Hello, Has anyone has issue with compiled re's vis-a-vis the re.I (ignore case) flag? I can't make sense of this compiled re producing a different match when given the flag, odd both in it's difference from the uncompiled regex (as I thought the uncompiled api was a wrapper around a compile-and-

Re: Anomaly in creating class methods

venk <[EMAIL PROTECTED]> wrote: > Cool, > i got it now... accessing thru attribute reference always > returns a bound or unbound method... so, D.f is an unbound method Right. Specifically, accessing through a (newstyle) class or instance always calls the __get__ method of a descriptor [

Re: Anomaly in creating class methods

Cool, i got it now... accessing thru attribute reference always returns a bound or unbound method... so, D.f is an unbound method whereas i want the "function" of the unbound method... ok, this example and the nice explanations definitively thought me about function, bound method (for

Re: Anomaly in creating class methods

venk <[EMAIL PROTECTED]> wrote: > Hi, > given below is my interaction with the interpreter In one case, i > have created the class method using the "famous idiom"... and in the > other, i have tried to create it outside the class definition... why > isn't the latter working ? (of course, the

Re: Anomaly in creating class methods

On 3 Nov 2005 03:19:22 -0800, "venk" <[EMAIL PROTECTED]> wrote: >Hi, > given below is my interaction with the interpreter In one case, i >have created the class method using the "famous idiom"... and in the >other, i have tried to create it outside the class definition... why >isn't the latter

Anomaly in creating class methods

Hi, given below is my interaction with the interpreter In one case, i have created the class method using the "famous idiom"... and in the other, i have tried to create it outside the class definition... why isn't the latter working ? (of course, the presence of decorators is a different issue

Re: printing anomaly

Paul Rubin wrote: What's the deal with this? >>> print 3.2 3.2 >>> print [3.2] [3.2002] >>> Yes, I know that 3.2 isn't an exact binary fraction. I'm wondering why it's converted differently depending on whether it's in a list. It's not. The difference is that prin

Re: printing anomaly

Paul Rubin wrote: What's the deal with this? >>> print 3.2 3.2 >>> print [3.2] [3.2002] >>> Yes, I know that 3.2 isn't an exact binary fraction. I'm wondering why it's converted differently depending on whether it's in a list. repr vs. str. The str of the sequenc

Re: printing anomaly

In article <[EMAIL PROTECTED]>, Paul Rubin wrote: > What's the deal with this? > > >>> print 3.2 > 3.2 > >>> print [3.2] > [3.2002] > >>> > > Yes, I know that 3.2 isn't an exact binary fraction. I'm wondering > why it's converted diff

RE: printing anomaly

Paul Rubin wrote: > What's the deal with this? > > >>> print 3.2 > 3.2 > >>> print [3.2] > [3.2002] > >>> > > Yes, I know that 3.2 isn't an exact binary fraction. I'm wondering > why it's converted differently depending on whether it's in a list. `print 3.2` ==

printing anomaly

What's the deal with this? >>> print 3.2 3.2 >>> print [3.2] [3.2002] >>> Yes, I know that 3.2 isn't an exact binary fraction. I'm wondering why it's converted differently depending on whether it's in a list. -- http://mail.python.org/mailman/listinfo/python-lis

Re: specifying constants for a function (WAS: generator expressions: performance anomaly?)

Bengt Richter wrote: On Mon, 24 Jan 2005 20:35:09 GMT, [EMAIL PROTECTED] (Bengt Richter) wrote: from presets import presets, curry @presets(verbose=True, a=1, b=2, deftime=__import__('time').ctime()) ... def foo(): ...print (a, b) ...print deftime ... presets: -- "name(?)" means name may be

Re: specifying constants for a function (WAS: generator expressions: performance anomaly?)

On Mon, 24 Jan 2005 20:35:09 GMT, [EMAIL PROTECTED] (Bengt Richter) wrote: >On Mon, 24 Jan 2005 00:31:17 -0700, Steven Bethard <[EMAIL PROTECTED]> wrote: > >>Bengt Richter wrote: >>> So, e.g., for >>> >>> >>> presets = dict(a=1, b=2, deftime=__import__('time').ctime()) >>> >>> in the decorator

Re: specifying constants for a function (WAS: generator expressions: performance anomaly?)

On Mon, 24 Jan 2005 00:31:17 -0700, Steven Bethard <[EMAIL PROTECTED]> wrote: >Bengt Richter wrote: >> So, e.g., for >> >> >>> presets = dict(a=1, b=2, deftime=__import__('time').ctime()) >> >> in the decorator args, the next version will act as if the decorated >> function had the source code

Re: specifying constants for a function (WAS: generator expressions: performance anomaly?)

Bengt Richter wrote: So, e.g., for >>> presets = dict(a=1, b=2, deftime=__import__('time').ctime()) in the decorator args, the next version will act as if the decorated function had the source code >>> print '%s = __frompresets__' % ', '.join(sorted(presets)) a, b, deftime = __frompresets__ for

Re: specifying constants for a function (WAS: generator expressions: performance anomaly?)

On Sun, 23 Jan 2005 13:14:10 -0700, Steven Bethard <[EMAIL PROTECTED]> wrote: >Bengt Richter wrote: >> On Sat, 22 Jan 2005 16:22:33 +1000, Nick Coghlan <[EMAIL PROTECTED]> wrote: >> >> [Steven Bethard] > If you really want locals that don't contribute to arguments, I'd be > much happie

Re: specifying constants for a function (WAS: generator expressions: performance anomaly?)

Bengt Richter wrote: On Sat, 22 Jan 2005 16:22:33 +1000, Nick Coghlan <[EMAIL PROTECTED]> wrote: Steven Bethard wrote: I wrote: > If you really want locals that don't contribute to arguments, I'd be > much happier with something like a decorator, e.g.[1]: > > @with_consts(i=1, deftime=time.ctime()

Re: specifying constants for a function (WAS: generator expressions: performance anomaly?)

Nick Coghlan wrote: Steven Bethard wrote: I wrote: > If you really want locals that don't contribute to arguments, I'd be > much happier with something like a decorator, e.g.[1]: > > @with_consts(i=1, deftime=time.ctime()) > def foo(x, y=123, *args, **kw): >return x*y, kw.get('which_time'

Re: specifying constants for a function (WAS: generator expressions: performance anomaly?)

On Sat, 22 Jan 2005 16:22:33 +1000, Nick Coghlan <[EMAIL PROTECTED]> wrote: >Steven Bethard wrote: >> I wrote: >> > If you really want locals that don't contribute to arguments, I'd be >> > much happier with something like a decorator, e.g.[1]: >> > >> > @with_consts(i=1, deftime=time.ctime())

Re: specifying constants for a function (WAS: generator expressions: performance anomaly?)

Steven Bethard wrote: I wrote: > If you really want locals that don't contribute to arguments, I'd be > much happier with something like a decorator, e.g.[1]: > > @with_consts(i=1, deftime=time.ctime()) > def foo(x, y=123, *args, **kw): >return x*y, kw.get('which_time')=='now' and time.ct

specifying constants for a function (WAS: generator expressions: performance anomaly?)

I wrote: > If you really want locals that don't contribute to arguments, I'd be > much happier with something like a decorator, e.g.[1]: > > @with_consts(i=1, deftime=time.ctime()) > def foo(x, y=123, *args, **kw): >return x*y, kw.get('which_time')=='now' and time.ctime() or deftime > > Then yo

Re: generator expressions: performance anomaly?

[Steve Holden] > Since it doesn't yet optimize 2+5 to a constant-folded 7 you should > realize that you are suggesting a large increase in the compiler's > analytical powers. FWIW, limited constant folding is already in CVS for Py2.5. Raymond Hettinger -- http://mail.python.org/mailman/listi

Re: generator expressions: performance anomaly?

Op 2005-01-19, Steve Holden schreef <[EMAIL PROTECTED]>: > Antoon Pardon wrote: > >> Op 2005-01-18, Steve Holden schreef <[EMAIL PROTECTED]>: > [...] >> >> But you do have a point that I have a tendency to put salt on >> any snail. I'll try to restrain myself a bit more in the future. >> > Finall

Re: generator expressions: performance anomaly?

Antoon Pardon wrote: Op 2005-01-18, Steve Holden schreef <[EMAIL PROTECTED]>: [...] But you do have a point that I have a tendency to put salt on any snail. I'll try to restrain myself a bit more in the future. Finally! :-) I find I like you much better after this reflective response. Thanks for t

Re: generator expressions: performance anomaly?

Paul Rubin wrote: Steve Holden <[EMAIL PROTECTED]> writes: You probably already know that sensible compiled language systems have used constant folding since time immemorial, but Python has always eschewed it. That's what comes of being a pragmatist's language: if such optimizations really are requ

Re: generator expressions: performance anomaly?

Op 2005-01-18, Steve Holden schreef <[EMAIL PROTECTED]>: > Antoon Pardon wrote: > >> Op 2005-01-18, Steve Holden schreef <[EMAIL PROTECTED]>: >> >> >>>Python is *designed* as a dynamic language. I wish you would embrace >>>this aspect rather than continually trying to shoehorn it into a static

Re: generator expressions: performance anomaly?

Op 2005-01-18, Jeremy Bowers schreef <[EMAIL PROTECTED]>: > On Tue, 18 Jan 2005 14:05:15 +, Antoon Pardon wrote: >> I don't see how generating byte code for a = 9; when seeing the >> expression a = 3 + 6, would be a problem for non-functional >> languages. > > To answer nearly every post you've

Re: generator expressions: performance anomaly?

Stephen Thorne wrote: On Tue, 18 Jan 2005 23:09:57 -0700, Steven Bethard <[EMAIL PROTECTED]> wrote: @with_consts(i=1, deftime=time.ctime()) def foo(x, y=123, *args, **kw): return x*y, kw.get('which_time')=='now' and time.ctime() or deftime Then you don't have to mix parameter declarations with

Re: generator expressions: performance anomaly?

On Tue, 18 Jan 2005 23:09:57 -0700, Steven Bethard <[EMAIL PROTECTED]> wrote: > @with_consts(i=1, deftime=time.ctime()) > def foo(x, y=123, *args, **kw): > return x*y, kw.get('which_time')=='now' and time.ctime() or deftime > > Then you don't have to mix parameter declarations with locals def

Re: generator expressions: performance anomaly?

Bengt Richter wrote: On Tue, 18 Jan 2005 17:38:20 -0700, Steven Bethard <[EMAIL PROTECTED]> wrote: Bengt Richter wrote: Which make me wonder what plans there are for providing a better mechanism than default arguments as a way of initializing local function variables. Nested def's to create a clos

Re: generator expressions: performance anomaly?

Steve Holden <[EMAIL PROTECTED]> writes: > You probably already know that sensible compiled language systems have > used constant folding since time immemorial, but Python has always > eschewed it. That's what comes of being a pragmatist's language: if > such optimizations really are required the p

Re: generator expressions: performance anomaly?

On Tue, 18 Jan 2005 17:38:20 -0700, Steven Bethard <[EMAIL PROTECTED]> wrote: >Bengt Richter wrote: >> Which make me wonder what plans there are for providing a better >> mechanism than default arguments as a way of initializing local function >> variables. Nested def's to create a closure with in

Re: generator expressions: performance anomaly?

On Tue, 18 Jan 2005 15:29:06 +0100, "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote: >> I don't see how generating byte code for a = 9; when seeing the >> expression a = 3 + 6, would be a problem for non-functional >> languages. > >Most probably. But I don't see much code of that type that it would

Re: generator expressions: performance anomaly?

Bengt Richter wrote: Which make me wonder what plans there are for providing a better mechanism than default arguments as a way of initializing local function variables. Nested def's to create a closure with initialized values is pretty crufty for that, IMO. What about using a class? Associating f

Re: generator expressions: performance anomaly?

On Tue, 18 Jan 2005 09:24:15 -0500, Steve Holden <[EMAIL PROTECTED]> wrote: [...] >You probably already know that sensible compiled language systems have >used constant folding since time immemorial, but Python has always >eschewed it. That's what comes of being a pragmatist's language: if such

macros (was: RE: generator expressions: performance anomaly?)

On Tue, 18 Jan 2005 12:59:07 -0800, Robert Brewer wrote: > Especially since you can already do it explicitly with Raymond > Hettinger's cookbook recipe: > http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/277940 You know, Guido might as well give in now on the Macro issue. If he doesn't come

RE: generator expressions: performance anomaly?

Jeremy Bowers wrote: > On Tue, 18 Jan 2005 14:05:15 +, Antoon Pardon wrote: > > I don't see how generating byte code for a = 9; when seeing the > > expression a = 3 + 6, would be a problem for non-functional > > languages. > > Ultimately, the use is fairly limited; I can't imagine the > execu

Re: generator expressions: performance anomaly?

On Tue, 18 Jan 2005 14:05:15 +, Antoon Pardon wrote: > I don't see how generating byte code for a = 9; when seeing the > expression a = 3 + 6, would be a problem for non-functional > languages. To answer nearly every post you've made to this thread, "because Python doesn't have the resources t

Re: generator expressions: performance anomaly?

Antoon Pardon wrote: Op 2005-01-18, Steve Holden schreef <[EMAIL PROTECTED]>: Python is *designed* as a dynamic language. I wish you would embrace this aspect rather than continually trying to shoehorn it into a static straitjacket. Efficiency is good. Flexibility is better. Flexibility is bett

Re: generator expressions: performance anomaly?

Op 2005-01-18, Steve Holden schreef <[EMAIL PROTECTED]>: > Python is *designed* as a dynamic language. I wish you would embrace > this aspect rather than continually trying to shoehorn it into a static > straitjacket. Efficiency is good. Flexibility is better. Flexibility is better? IMO flexibi

Re: generator expressions: performance anomaly?

Antoon Pardon wrote: Op 2005-01-18, Diez B. Roggisch schreef <[EMAIL PROTECTED]>: Something else I was thinking about. I think it would be nice if the python compilor could figure out whether a genexp in a list or tuple expression always generates the same list or tuple and then instead of generati

Re: generator expressions: performance anomaly?

> I don't see how generating byte code for a = 9; when seeing the > expression a = 3 + 6, would be a problem for non-functional > languages. Most probably. But I don't see much code of that type that it would be worth optimizing for, either. The cost for re-evaluation such an expression doesn't re

Re: generator expressions: performance anomaly?

Stephen Thorne wrote: On Tue, 18 Jan 2005 07:12:18 -0500, Steve Holden <[EMAIL PROTECTED]> wrote: Since it doesn't yet optimize 2+5 to a constant-folded 7 you should realize that you are suggesting a large increase in the compiler's analytical powers. As in interesting aside to this, you might be

Re: generator expressions: performance anomaly?

What makes the leftmost expression different from the iterable returning expression inside the for? The same arguments apply there. It's not different, but it's a requirement that the iterable returns the same data every time. I know that anyone can type range = fancyRange and make this return a

Re: generator expressions: performance anomaly?

Op 2005-01-18, Diez B. Roggisch schreef <[EMAIL PROTECTED]>: >> Something else I was thinking about. I think it would be nice if the >> python compilor could figure out whether a genexp in a list or tuple >> expression always generates the same list or tuple and then instead >> of generating code w

Re: generator expressions: performance anomaly?

> My thoughts where to let the 'leftmost' section of the expression to be > intact so that any of the dynamic things done to this part, i.e. > replacing time.time with random.random are taken into consideration. > What can be done is to extract the expression into a loopless structure > > lst = l

Re: generator expressions: performance anomaly?

Diez B. Roggisch wrote: Would it be a bad solution to make that a list or tuple of ten time.time() calls, you could also restrict what theese prebuilding sequenses could contain, or perhaps try to prebuild them, and then fail if it's impossible. I don't fully understand what you mean. Restricting

Re: generator expressions: performance anomaly?

On Tue, 18 Jan 2005 07:12:18 -0500, Steve Holden <[EMAIL PROTECTED]> wrote: > Since it doesn't yet optimize 2+5 to a constant-folded 7 you should > realize that you are suggesting a large increase in the compiler's > analytical powers. As in interesting aside to this, you might be interested to kn

Re: generator expressions: performance anomaly?

> Would it be a bad solution to make that a list or tuple of ten > time.time() calls, you could also restrict what theese prebuilding > sequenses could contain, or perhaps try to prebuild them, and then fail > if it's impossible. I don't fully understand what you mean. Restricting them would mean

Re: generator expressions: performance anomaly?

Diez B. Roggisch wrote: lst = list(genexp) tpl = tuple(genexp) Since in such cases the object is build in memory any way, I don't think it would be a problem of having them prebuilt in memory, or am I missing something? Yes. Consider this: lst = list(time.time() for i in xrange(10)) tpl = tupl

Re: generator expressions: performance anomaly?

>lst = list(genexp) >tpl = tuple(genexp) > > > Since in such cases the object is build in memory any way, I don't > think it would be a problem of having them prebuilt in memory, or am > I missing something? Yes. Consider this: lst = list(time.time() for i in xrange(10)) tpl = tuple(ti

Re: generator expressions: performance anomaly?

Antoon Pardon wrote: Op 2005-01-18, Steve Holden schreef <[EMAIL PROTECTED]>: Antoon Pardon wrote: Op 2005-01-18, Nick Coghlan schreef <[EMAIL PROTECTED]>: Raymond Hettinger wrote: [Delaney, Timothy C] Nick's other suggestion - that genexps propagate __len__ - might still be interesting. Of cou

Re: generator expressions: performance anomaly?

Op 2005-01-18, Steve Holden schreef <[EMAIL PROTECTED]>: > Antoon Pardon wrote: > >> Op 2005-01-18, Nick Coghlan schreef <[EMAIL PROTECTED]>: >> >>>Raymond Hettinger wrote: >>> [Delaney, Timothy C] >Nick's other suggestion - that genexps propagate __len__ - might >still be in

Re: generator expressions: performance anomaly?

> Something else I was thinking about. I think it would be nice if the > python compilor could figure out whether a genexp in a list or tuple > expression always generates the same list or tuple and then instead > of generating code would generate the list or tuple in place. This won't ever happen

Re: generator expressions: performance anomaly?

Antoon Pardon wrote: Op 2005-01-18, Nick Coghlan schreef <[EMAIL PROTECTED]>: Raymond Hettinger wrote: [Delaney, Timothy C] Nick's other suggestion - that genexps propagate __len__ - might still be interesting. Of course, it would only be applicable for unconditional genexps(i.e. no if clause). Le

Re: generator expressions: performance anomaly?

Op 2005-01-18, Nick Coghlan schreef <[EMAIL PROTECTED]>: > Raymond Hettinger wrote: >> [Delaney, Timothy C] >> >>>Nick's other suggestion - that genexps propagate __len__ - might >>>still be interesting. Of course, it would only be applicable for >>>unconditional genexps(i.e. no if clause). >> >>

Re: generator expressions: performance anomaly?

Raymond Hettinger wrote: [Delaney, Timothy C] Nick's other suggestion - that genexps propagate __len__ - might still be interesting. Of course, it would only be applicable for unconditional genexps(i.e. no if clause). Length transparency for iterators is not as general as one would expect. I once

Re: generator expressions: performance anomaly?

[Delaney, Timothy C] > Nick's other suggestion - that genexps propagate __len__ - might > still be interesting. Of course, it would only be applicable for > unconditional genexps(i.e. no if clause). Length transparency for iterators is not as general as one would expect. I once spent a good deal

RE: generator expressions: performance anomaly?

Raymond Hettinger wrote: > Check out the current source. The time machine beat you to it. Nick's other suggestion - that genexps propagate __len__ - might still be interesting. Of course, it would only be applicable for unconditional genexps(i.e. no if clause). Tim Delaney -- http://mail.python

Re: generator expressions: performance anomaly?

[Raymond Hettinger] > >List slice assignment is an example of a tool with a special case optimization > >for inputs that know their own length -- that enables the tool to pre-allocate > >its result rather than growing and resizing in spurts. Other such tools include > >tuple(), map() and zip(). [

Re: generator expressions: performance anomaly?

Nick Coghlan: >There's a similar performance glitch associated with constructing a tuple from a generator expression (with vanilla 2.4, detouring via list is actually faster) You look right: .from time import clock .print "[x for x in l], list(x for x in l), aux = list(x for x in l); tuple(aux),

Re: generator expressions: performance anomaly?

On Sun, 16 Jan 2005 12:18:23 GMT, "Raymond Hettinger" <[EMAIL PROTECTED]> wrote: >"John Machin" <[EMAIL PROTECTED]> wrote in message >news:[EMAIL PROTECTED] >> Please consider the timings below, where a generator expression starts >> out slower than the equivalent list comprehension, and gets wors

Re: generator expressions: performance anomaly?

"John Machin" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Please consider the timings below, where a generator expression starts > out slower than the equivalent list comprehension, and gets worse: > > >python -m timeit -s "orig=range(10)" "lst=orig[:];lst[:]=(x for x > in ori

Re: generator expressions: performance anomaly?

John Machin wrote: Background: There was/is a very recent thread about ways of removing all instances of x from a list. /F proposed a list comprehension to build the result list. Given a requirement to mutate the original list, this necessitates the assignment to lst[:]. I tried a generator express

Re: generator expressions: performance anomaly?

John Machin wrote: > Given a requirement to mutate the original list, this necessitates the > assignment > to lst[:]. do you always pull requirements out of thin air? -- http://mail.python.org/mailman/listinfo/python-list

generator expressions: performance anomaly?

Please consider the timings below, where a generator expression starts out slower than the equivalent list comprehension, and gets worse: >python -m timeit -s "orig=range(10)" "lst=orig[:];lst[:]=(x for x in orig)" 10 loops, best of 3: 6.84e+004 usec per loop >python -m timeit -s "orig=range(

<    1   2