Re: Pythonic way to iterate through multidimensional space?
On 06/08/2014 06:34, Gayathri J wrote: Dear Peter Below is the code I tried to check if itertools.product() was faster than normal nested loops... they arent! arent they supposed to be...or am i making a mistake? any idea? * * * * *# -*- coding: utf-8 -*- * *import numpy as np* *import time* *from itertools import product,repeat* *def main():* *# N - size of grid* *# nvel - number of velocities* *# times - number of times to run the functions* *N=256* *times=3* *f=np.random.rand(N,N,N)* ** *# using loops* *print "normal nested loop"* *python_dot_loop1(f,times,N)* * * *print "nested loop using itertools.product()"* *python_dot_loop2(f,times,N)* * * *def python_dot_loop1(f,times,N):* *for t in range(times):* * t1=time.time()* * for i in range(N):* * for j in range(N):* * for k in range(N):* * f[i,j,k] = 0.0* * print "python dot loop " + str(time.time()-t1)* ** *def python_dot_loop2(f,times,N):* *rangeN=range(N)* *for t in range(times):* * t1=time.time()* * for i,j,k in product(rangeN,repeat=3):* * f[i,j,k]=0.0* * print "python dot loop " + str(time.time()-t1)* * * * * *if __name__=='__main__':* *main()* ** Who cares, well not I for one? Give me slower but accurate code over faster but inaccurate code any day of the week? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Pythonic way to iterate through multidimensional space?
Gayathri J wrote: > Dear Peter > > Below is the code I tried to check if itertools.product() was faster than > normal nested loops... > > they arent! arent they supposed to be... I wouldn't have expected product() to be significantly faster, but neither did I expect it to be slower. > or am i making a mistake? any > idea? For your testcase you can shave off a small amount by avoiding the tuple- unpacking for t in product(...): f[t] = 0.0 but that may be cheating, and the effect isn't big. When you are working with numpy there may be specialised approaches, but f[:,:,:] = 0.0 is definitely cheating I suppose... -- https://mail.python.org/mailman/listinfo/python-list
Re: Pythonic way to iterate through multidimensional space?
You might check numpy it is really powerful tool for working with multi dimensional arrays: ex. >>> a = arange(81).reshape(3,3,3,3) >>> a array( 0, 1, 2], [ 3, 4, 5], [ 6, 7, 8]], [[ 9, 10, 11], [12, 13, 14], [15, 16, 17]], [[18, 19, 20], [21, 22, 23], [24, 25, 26]]], [[[27, 28, 29], [30, 31, 32], [33, 34, 35]], [[36, 37, 38], [39, 40, 41], [42, 43, 44]], [[45, 46, 47], [48, 49, 50], [51, 52, 53]]], [[[54, 55, 56], [57, 58, 59], [60, 61, 62]], [[63, 64, 65], [66, 67, 68], [69, 70, 71]], [[72, 73, 74], [75, 76, 77], [78, 79, 80) >>> f = a.flat >>> for i in f: ...print(i) 0 1 2 .. 98 99 cheers Wojciech On 05/08/14 21:06, Frank Miles wrote: I need to evaluate a complicated function over a multidimensional space as part of an optimization problem. This is a somewhat general problem in which the number of dimensions and the function being evaluated can vary from problem to problem. I've got a working version (with loads of conditionals, and it only works to #dimensions <= 10), but I'd like something simpler and clearer and less hard-coded. I've web-searched for some plausible method, but haven't found anything "nice". Any recommendations where I should look, or what technique should be used? TIA! -- https://mail.python.org/mailman/listinfo/python-list
How to delete letters automatically with imaplib?
I have a gmail account 'x...@gmail.com' which subscripted python
maillist. To take part in python discussion is the only target for my
x...@gmail.com. There are so many emails in my x...@gmail.com,it is a good
idea for me to auto delete all emails whose body contain no . I write
some codes to do the job.
|import imaplib
user="xxx"
password="yy"
con=imaplib.IMAP4_SSL('imap.gmail.com')
con.login(user,password)
con.select('INBOX')
status, data= con.search(None, "ALL")
print(len(data[0].split()))
48
typ, data= con.search(None, 'Body', '"x...@gmail.com"')
data
[b'1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
32 33 34 35 36 37 44']
len(data[0].split())
36|
How can i delete 48-36=12 letters?
--
https://mail.python.org/mailman/listinfo/python-list
Re: How to delete letters automatically with imaplib?
elearn writes: > status, data= con.search(None, "ALL") > print(len(data[0].split())) > 48 > typ, data= con.search(None, 'Body', '"x...@gmail.com"') > >>> data > [b'1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 > 29 > 32 33 34 35 36 37 44'] > > len(data[0].split()) > 36 > > How can i delete 48-36=12 letters? Set operations are designed for this:: # Construct a set of all message numbers. status, data = con.search(None, "ALL") ids_of_all_messages = set(data[0].split()) # Construct a set of messages mentioning the address. status, data = con.search(None, 'Body', '"x...@gmail.com"') ids_of_messages_containing_address = set(data[0].split()) # Get the messages to delete. ids_of_messages_to_delete = ( ids_of_all_messages - ids_of_messages_containing_address) -- \ “Too many pieces of music finish too long after the end.” —Igor | `\ Stravinskey | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Making every no-arg method a property?
On Wed, 06 Aug 2014 12:07:58 +1000, Chris Angelico wrote: > On Wed, Aug 6, 2014 at 10:49 AM, Steven D'Aprano > wrote: >> A >> plethora of argument-less methods is a code smell -- that doesn't mean >> it's *necessarily* a bad idea, but the class design really needs a >> careful review. > > There are plenty of no-argument mutator methods, where the name of the > method (and the target object, obviously) is all the info you need. You > can clear() or copy() something with any more info, reverse() a list, > pop() from a list, etc. They don't have to be mutator methods. The same applies to string methods like upper(), lower(), isalpha() and many others. I'm not sure if you're agreeing or disagreeing with me. All these examples shouldn't be treated as properties either. This should be grounds for being slapped with a large herring: mydict.clear # returns None, operates by side-effect Some things are conceptually either methods or attributes: mydict.keys # could be okay I suppose but I digress. As I said, zero-argument (one-argument, if you count self) methods are a code smell, not an error. As is so often the case in programming, the fundamental sin here is *coupling* -- zero-argument methods are bad if they require coupling to temporary attributes which exist only to communicate an argument to the method. In other words, one of the sins of zero-argument methods is the same as that of zero-argument functions. We wouldn't write this: def double(): return number_to_operate_on*2 number_to_operate_on = 23 print double() number_to_operate_on = 42 print double() Turning it into a method on an instance, and turning the global into a "per instance global" (instead of per module, or application-wide) doesn't make it any better. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Making every no-arg method a property?
On Wed, 06 Aug 2014 10:34:04 +1200, Gregory Ewing wrote: > Grant Edwards wrote: >> Did I miss a news story? Have the parentesis mines all exploded >> causing the price of parenthesis to skyrocket? > > The Unicode Consortium has been secretly buying them up for some time > now. Pretty soon you won't be able to get cheap ASCII parentheses any > more, only the fancy high-priced ones like U+2045/U+2046, U+2772/U+2773 > and U+27E6/U+27E7. Perhaps that will make JMF rich enough to retire ;-) -- Live long and prosper. -- Spock, "Amok Time", stardate 3372.7 -- https://mail.python.org/mailman/listinfo/python-list
Re: Making every no-arg method a property?
On Tue, 05 Aug 2014 12:39:18 -0700, Christian Calderon wrote: > I have been using python for 4 years now, and I just started learning > ruby. > I like that in ruby I don't have to type parenthesis at the end of each > function call if I don't need to provide extra arguments. I just > realized right now that I can do something similar in python, if I make > all methods with only the implicitly passed 'self' into properties. > Which means I can either do some fancy coding and make a metaclass that > does this auto-magically, or I have to have property decorators all over > the place :-P . I was wondering what other thought of this, is it an > overly fanciful way of coding python, or is it an acceptable thing to do > in a real project? > Also, would anyone be interested in helping me make this metaclass? > I have been using python for 4 years now, and I just > started learning ruby. I like that in ruby I don't have to type > parenthesis at the end of each function call if I don't need to > provide extra arguments. I just realized right now that I can do > something similar in python, if I make all methods with only the > implicitly passed 'self' into properties. Which means I can > either do some fancy coding and make a metaclass that does this > auto-magically, or I have to have property decorators all over the place > :-P . I was wondering what other thought of this, is it an overly > fanciful way of coding python, or is it an acceptable thing to do in a > real project? Also, would anyone be interested in helping me make this > metaclass? import this Special Cases are not special enough This is a horrible idea for python code -- Once is happenstance, Twice is coincidence, Three times is enemy action. -- Auric Goldfinger -- https://mail.python.org/mailman/listinfo/python-list
Re: How to delete letters automatically with imaplib?
and how to write the delete command with imaplib? On 8/6/2014 5:14 PM, Ben Finney wrote: elearn writes: status, data= con.search(None, "ALL") print(len(data[0].split())) 48 typ, data= con.search(None, 'Body', '"x...@gmail.com"') data [b'1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 32 33 34 35 36 37 44'] len(data[0].split()) 36 How can i delete 48-36=12 letters? Set operations are designed for this:: # Construct a set of all message numbers. status, data = con.search(None, "ALL") ids_of_all_messages = set(data[0].split()) # Construct a set of messages mentioning the address. status, data = con.search(None, 'Body', '"x...@gmail.com"') ids_of_messages_containing_address = set(data[0].split()) # Get the messages to delete. ids_of_messages_to_delete = ( ids_of_all_messages - ids_of_messages_containing_address) -- https://mail.python.org/mailman/listinfo/python-list
Re: Making every no-arg method a property?
On Wed, Aug 6, 2014 at 7:15 PM, Steven D'Aprano wrote: > On Wed, 06 Aug 2014 12:07:58 +1000, Chris Angelico wrote: > >> On Wed, Aug 6, 2014 at 10:49 AM, Steven D'Aprano >> wrote: >>> A >>> plethora of argument-less methods is a code smell -- that doesn't mean >>> it's *necessarily* a bad idea, but the class design really needs a >>> careful review. >> >> There are plenty of no-argument mutator methods, where the name of the >> method (and the target object, obviously) is all the info you need. You >> can clear() or copy() something with any more info, reverse() a list, >> pop() from a list, etc. > > They don't have to be mutator methods. The same applies to string methods > like upper(), lower(), isalpha() and many others. > > I'm not sure if you're agreeing or disagreeing with me. Agreeing with your primary point, disagreeing with this subpoint. > All these > examples shouldn't be treated as properties either. This should be > grounds for being slapped with a large herring: > > mydict.clear # returns None, operates by side-effect Wholeheartedly agree. These should NOT be properties. A property should not mutate state, normally (I can imagine exceptions, but they are *definitely* code smell, unless they're doing basic logging or something). What I disagree with is that argument-less methods, even a plethora thereof, are *themselves* code smell. Mutator methods, and the string methods that construct a "this string only different" result (which in many ways are the immutable object's equivalent of mutators), will often take no args, and are most definitely not properties, but IMO aren't code smell. Something like isalpha() is borderline, but making upper() a property implies that, conceptually, the upper-case version of a string is an attribute the string already has, rather than something that you construct from that string. It's debatable, but IMO it makes perfect sense to keep that as a method - and it's fine for it to take no args other than the object it's working on. > As I said, zero-argument (one-argument, if you count self) > methods are a code smell, not an error. As is so often the case in > programming, the fundamental sin here is *coupling* -- zero-argument > methods are bad if they require coupling to temporary attributes which > exist only to communicate an argument to the method. > > In other words, one of the sins of zero-argument methods is the same as > that of zero-argument functions. We wouldn't write this: > > def double(): > return number_to_operate_on*2 > > number_to_operate_on = 23 > print double() > number_to_operate_on = 42 > print double() > > > Turning it into a method on an instance, and turning the global into a > "per instance global" (instead of per module, or application-wide) > doesn't make it any better. But if it were written as: class float(float): pass # allow more attributes on float def double(self): return self*2 float.double = double number = float(23) print(number.double()) Then it's not hidden global state any more, but it's still a zero-argument method. Is that really just as bad? Surely it's the same as "print(double(number))"? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: How to delete letters automatically with imaplib?
elearn writes: > and how to write the delete command with imaplib? (Please don't top-post. Instead, compose your responses interleaved https://en.wikipedia.org/wiki/Posting_style#Interleaved_style> so the conversation is easier to follow in the message.) I'm not familiar with the API of the ‘imaplib’ module. Start with https://docs.python.org/3/library/imaplib.html> and remember that it is a library designed to work intimately with the IMAP command-response protocol. If, instead, you wish to manipulate mailboxes without needing to know much about the detailed features of the storage format, use the https://docs.python.org/3/library/mailbox.html> ‘mailbox’ module for that purpose. -- \“No matter how cynical you become, it's never enough to keep | `\up.” —Jane Wagner, via Lily Tomlin | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Pythonic way to iterate through multidimensional space?
Dear Peter Yes the f[t] or f[:,:,:] might give a marginal increase, but then i need to do further operations using the indices, in which case this wouldnt help Dear Wojciech np.flat() works if u dont care about the indices and only the matrix/array values matter. but if the matters, flatten wouldnt work On Wed, Aug 6, 2014 at 1:34 PM, Wojciech Giel wrote: > You might check numpy it is really powerful tool for working with multi > dimensional arrays: > > ex. > >>> a = arange(81).reshape(3,3,3,3) > >>> a > > array( 0, 1, 2], > [ 3, 4, 5], > [ 6, 7, 8]], > > [[ 9, 10, 11], > [12, 13, 14], > [15, 16, 17]], > > [[18, 19, 20], > [21, 22, 23], > [24, 25, 26]]], > > >[[[27, 28, 29], > [30, 31, 32], > [33, 34, 35]], > > [[36, 37, 38], > [39, 40, 41], > [42, 43, 44]], > > [[45, 46, 47], > [48, 49, 50], > [51, 52, 53]]], > > >[[[54, 55, 56], > [57, 58, 59], > [60, 61, 62]], > > [[63, 64, 65], > [66, 67, 68], > [69, 70, 71]], > > [[72, 73, 74], > [75, 76, 77], > [78, 79, 80) > > >>> f = a.flat > >>> for i in f: > ...print(i) > 0 > 1 > 2 > .. > 98 > 99 > > cheers > Wojciech > > > > > On 05/08/14 21:06, Frank Miles wrote: > >> I need to evaluate a complicated function over a multidimensional space >> as part of an optimization problem. This is a somewhat general problem >> in which the number of dimensions and the function being evaluated can >> vary from problem to problem. >> >> I've got a working version (with loads of conditionals, and it only works >> to #dimensions <= 10), but I'd like something simpler and clearer and >> less hard-coded. >> >> I've web-searched for some plausible method, but haven't found anything >> "nice". Any recommendations where I should look, or what technique should >> be used? >> >> TIA! >> > > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Pythonic way to iterate through multidimensional space?
Gayathri J wrote: > Dear Peter > > Yes the f[t] or f[:,:,:] might give a marginal increase, The speedup compared itertools.product() is significant: $ python -m timeit -s 'from itertools import product; from numpy.random import rand; N = 100; a = rand(N, N, N); r = range(N)' 'for x in product(r, repeat=3): a[x] = 0.0' 10 loops, best of 3: 290 msec per loop $ python -m timeit -s 'from itertools import product; from numpy.random import rand; N = 100; a = rand(N, N, N); r = range(N)' 'a[:,:,:] = 0.0' 100 loops, best of 3: 3.58 msec per loop But normally you'd just make a new array with numpy.zeros(). > but then i need > to do further operations using the indices, in which case this wouldnt > help Which is expected and also the crux of such micro-benchmarks. They distract from big picture. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
> > Thankfully, all actually user-friendly operating systems (MacOS, > > TOS, RiscOS, probably AmigaOS, MacOS X) spare(d) their users the > > bottomless cesspit of "package management" and/or "installers". > > > > Because on such operating systems, each and every application is an > > entirely self-contained package that doesn't need any "packages" or > > "installers" to use it. > > You mean everyone has to reinvent the proverbial wheel AND worry about > dependency collisions? Yeah, that's a heavenly thought. You should get a clue in stead of just fantasizing up assumptions based on ignorance. Sincerely, Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
> > Because on such operating systems, each and every application is an > > entirely self-contained package that doesn't need any "packages" or > > "installers" to use it. > For people who have never used such a system it's probably difficult > to see the advantages. That's the whole point. The problem is that the ones who "decide" (well, they pretend to, but actually can't, because they don't know the alternatives) are always people who are "not even clueless". I.e. they are totally clueless, *and* psychotically self-convinced of their omnicompetence. Sincerely, Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
> I've worked with both. Quite honestly, I really wish that other > operating systems had gone down this route. MS didn't possibly to make > it harder to steal software, >From the perspective of the computer-literate, proficient screenworker, MS always got and gets everything completely wrong. > and Unix...well, *nix has the concept of the "distribution" that will > manage all of this for you. We all know the problems that this > causes. Linux was made by geeks who didn't have a clue of ergonomics for screenworkers and didn't care to get one. Sincerely, Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
On Wed, Aug 6, 2014 at 10:38 PM, Wolfgang Keller wrote: >> > Thankfully, all actually user-friendly operating systems (MacOS, >> > TOS, RiscOS, probably AmigaOS, MacOS X) spare(d) their users the >> > bottomless cesspit of "package management" and/or "installers". >> > >> > Because on such operating systems, each and every application is an >> > entirely self-contained package that doesn't need any "packages" or >> > "installers" to use it. >> >> You mean everyone has to reinvent the proverbial wheel AND worry about >> dependency collisions? Yeah, that's a heavenly thought. > > You should get a clue in stead of just fantasizing up assumptions based > on ignorance. I've worked with a number of operating systems, a number of dependency management systems, and a number of absences of such systems. I stand by my earlier statements in this thread, and I think I have a fairly good clue about what does and doesn't work in terms of installers. There is one way to avoid most of the duplication and still make every application perfectly self-contained. You simply decree that there are no dependencies permitted except for the base OS itself and what it provides. As long as that's a rich enough set of tools, everything can work (that's what seems to be happening on mobile platforms, for instance). But it does mean that any unusual dependencies have to be considered part of the app, and that means duplication. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Pythonic way to iterate through multidimensional space?
On 2014-08-06 11:04, Gayathri J wrote: > Below is the code I tried to check if itertools.product() was > faster than normal nested loops... > > they arent! arent they supposed to be...or am i making a mistake? I believe something like this was discussed a while ago and there was a faster-but-uglier solution so you might want to consult this thread: https://mail.python.org/pipermail/python-list/2008-January/516109.html I believe this may have taken place before itertools.product() came into existence. -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: Pythonic way to iterate through multidimensional space?
Dear Peter thanks . But thats what I was trying to say just taking them to zero by f[:,:,:] = 0.0 or using np.zeros is surely going to give me a time gain... but my example of using the itertools.product() and doing f[x] =0.0 is just to compare the looping timing with the traditional nested loops and not to distract us to the operation done inside the loop. right? On Wed, Aug 6, 2014 at 6:09 PM, Peter Otten <__pete...@web.de> wrote: > Gayathri J wrote: > > > Dear Peter > > > > Yes the f[t] or f[:,:,:] might give a marginal increase, > > The speedup compared itertools.product() is significant: > > $ python -m timeit -s 'from itertools import product; from numpy.random > import rand; N = 100; a = rand(N, N, N); r = range(N)' 'for x in product(r, > repeat=3): a[x] = 0.0' > 10 loops, best of 3: 290 msec per loop > > $ python -m timeit -s 'from itertools import product; from numpy.random > import rand; N = 100; a = rand(N, N, N); r = range(N)' 'a[:,:,:] = 0.0' > 100 loops, best of 3: 3.58 msec per loop > > But normally you'd just make a new array with numpy.zeros(). > > > but then i need > > to do further operations using the indices, in which case this wouldnt > > help > > Which is expected and also the crux of such micro-benchmarks. They distract > from big picture. > > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On Wednesday, May 28, 2014 6:38:22 PM UTC-4, Ben Finney wrote: > Larry Martell writes: > > > > > No company that I work for is using python 3 - they just have too much > > > of an investment in a python 2 code base to switch. > > > > There are many large companies still using FORTRAN and COBOL because of > > a large investment in those languages, which are far more outdated than > > Python 2. What's your point? Fortran compiler vendors such as Intel, IBM, Oracle/SUN and open source projects such as gfortran are updating their compilers to the Fortran 2003 and 2008 standards while also keeping the ability to compile all the old Fortran code. FORTRAN 77 programmers and programs will not be forced to move to modern Fortran, but I'm not sure that Python 2.x users can be as confident that Python 2.x will be supported on future operating systems. -- https://mail.python.org/mailman/listinfo/python-list
why i can not delete my email with imaplib?
I have a gmail account 'x...@gmail.com' which subscripted python
maillist. I want to delete any emails which is sent to
python-list@python.org .
|import imaplib
user="xxx"
password="yy"
con=imaplib.IMAP4_SSL('imap.gmail.com')
con.login(user,password)
con.select('[Gmail]/&YkBnCZCuTvY-')
type, data= con.search(None, "All")
type1, data1= con.search(None, '(TO "python-list@python.org")')
ids_all= set(data[0].split())
ids1=set(data1[0].split())
ids_deleted=set(ids_all-ids1)
for numin ids_deleted:
con.store(num, '+FLAGS', '\\Deleted')
con.expunge()|
When i open my gmail with thunderbird ,the emails which are sent to
python-list@python.org are still in my gmail,Why i can't delete them?
--
https://mail.python.org/mailman/listinfo/python-list
Re: why i can not delete my email with imaplib?
My apologies. I must be dense. Why do you want to do this from Python? Can't you accomplish the same thing more easily with a Gmail filter which deletes all messages sent to python-list@python.org? Also, I assume that if you use "x...@gmail.com" only so you can send mail to the list, why not just disable message delivery altogether through the Mailman interface. That would avoid the necessity of deleting the mail at all. > When i open my gmail with thunderbird ,the emails which are sent to > python-list@python.org are still in my gmail... Do you perhaps need to force Thunderbird to refresh its view of your mailbox? Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: Making every no-arg method a property?
On Wed, 6 Aug 2014 05:13:07 + (UTC) Grant Edwards wrote: > On 2014-08-05, Gregory Ewing wrote: > > Grant Edwards wrote: > >> Did I miss a news story? Have the parentesis mines all exploded > >> causing the price of parenthesis to skyrocket? > > > > The Unicode Consortium has been secretly buying them > > up for some time now. Pretty soon you won't be able > > to get cheap ASCII parentheses any more, only the > > fancy high-priced ones like U+2045/U+2046, > > U+2772/U+2773 and U+27E6/U+27E7. > > Damn. Time to buy some options... > > -- > Grant > No, no. Options use up commas, not parentheses. Maybe equals signs if you're feeling particularly verbose. Clearly there's a market for some sort of well-diversified punctuation fund. The only problem becomes listing it. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix. -- https://mail.python.org/mailman/listinfo/python-list
Re: asyncio with map&reduce flavor and without flooding the event loop
2014-08-03 16:01 GMT+02:00 Valery Khamenya : > Hi all > > [snip] > > Consider a task like crawling the web starting from some web-sites. Each > site leads to generation of new downloading tasks in exponential(!) > progression. However we don't want neither to flood the event loop nor to > overload our network. We'd like to control the task flow. This is what I > achieve well with modification of nice Maxime's solution proposed here: > https://mail.python.org/pipermail/python-list/2014-July/675048.html > > Well, but I'd need as well a very natural thing, kind of map() & reduce() or > functools.reduce() if we are on python3 already. That is, I'd need to call a > "summarizing" function for all the downloading tasks completed on links from > a page. This is where i fail :( Hi Valery, With the modified as_completed, you can write map and reduce primitives quite naturally. It could look like that: def async_map(corofunc, *iterables): """ Equivalent to map(corofunc, *iterables) except that corofunc must be a coroutine function and is executed asynchronously. This is not a coroutine, just a normal generator yielding Task instances. """ for args in zip(*iterables): yield asyncio.async(corofunc(*args)) @asyncio.coroutine def async_reduce(corofunc, futures, initial=0): """ Equivalent to functools.reduce(corofunc, [f.result() for f in futures]) except that corofunc must be a coroutine function and future results can be evaluated out-of order. This function is a coroutine. """ result = initial for f in as_completed(futures, max_workers=50): new_value = (yield from f) result = (yield from corofunc(result, new_value)) return result === Best, Maxime -- https://mail.python.org/mailman/listinfo/python-list
Re: converting ISO8601 date and time string representations to datetime
On Fri, Aug 1, 2014 at 10:53 PM, Akira Li <4kir4...@gmail.com> wrote: > Wolfgang Maier writes: > >> On 08/01/2014 01:30 AM, Roy Smith wrote: >>> In article , >>> Albert-Jan Roskam wrote: >>> > In article , > Wolfgang Maier wrote: > >> Hi, >> I'm trying to convert ISO8601-compliant strings representing dates or >> dates and times into datetime.datetime objects. > > https://pypi.python.org/pypi/iso8601 Yikes, what a regex. It must have been painstaking to get that right. https://bitbucket.org/micktwomey/pyiso8601/src/2bd28b5d6cd2481674a8b0c54a8bba6 4ab775f81/iso8601/iso8601.py?at=default >>> >>> It is a thing of beauty. >>> >> >> No wonder I found it hard to write something that seemed bulletproof ! > > It seems it supports only some custom subset of ISO 8601. There is rfc > 3339 [1] that describes a profile of the ISO 8601 standard. > > rfc 3339 combines human readability with the simplicity of machine parsing. > > [1] http://tools.ietf.org/html/rfc3339 > > > -- > Akira > > -- > https://mail.python.org/mailman/listinfo/python-list I just came across this package: http://crsmithdev.com/arrow/ Among other features it lists this: Gaps in functionality: ISO-8601 parsing, timespans, humanization -- Joel Goldstick http://joelgoldstick.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On 8/6/2014 9:47 AM, beliav...@aol.com.dmarc.invalid wrote: Fortran compiler vendors such as Intel, IBM, Oracle/SUN and open *Vendors* sell compilers for money, which they can then use to *pay* people to do unfun stuff that volunteers don't want and should not have to do. Actually, I am beginning to think that 2.7 should be split off for 3.x development and charged for. source projects such as gfortran are updating their compilers to the Fortran 2003 and 2008 standards while also keeping the ability to compile all the old Fortran code. FORTRAN 77 programmers and programs According to https://gcc.gnu.org/fortran/ , gfortran is a standard Fortran 95 compiler with legacy (F77) support where practical and 'significant' F2003 and F2008 support. Since it is free, one takes what one gets. In multiple ways, Gfortran, as a whole, is significantly simpler to develop than Python. It is an alternate front end to the gcc compiler (a very smart decision). The GNU projects distributes source code, which I presume consists of C code aimed at the GCC compiler. will not be forced to move to modern Fortran, but I'm not sure that Python 2.x users can be as confident that Python 2.x will be supported on future operating systems. It will be for as long as 2.x users are willing to pay for support. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Making every no-arg method a property?
On 8/6/2014 6:09 AM, alister wrote: On Wed, 06 Aug 2014 10:34:04 +1200, Gregory Ewing wrote: Grant Edwards wrote: Did I miss a news story? Have the parentesis mines all exploded causing the price of parenthesis to skyrocket? The Unicode Consortium has been secretly buying them up for some time now. Pretty soon you won't be able to get cheap ASCII parentheses any more, only the fancy high-priced ones like U+2045/U+2046, U+2772/U+2773 and U+27E6/U+27E7. Perhaps that will make JMF rich enough to retire ;-) Gratuitous personal digs are disrespectful and out of place on this list, especially when the target has not even participated in the thread. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: converting ISO8601 date and time string representations to datetime
On Wed, Aug 6, 2014 at 1:31 PM, Joel Goldstick wrote: > Among other features it lists this: Gaps in functionality: ISO-8601 > parsing, timespans, humanization What is "humanization"? Skip -- https://mail.python.org/mailman/listinfo/python-list
Test for an empty directory that could be very large if it is not empty?
Suppose I have a directory C:/Test that is either empty or contains more
than 200 files, all with the same extension (e.g. *.txt). How can I
determine if the directory is empty WITHOUT the generation of a list of
the file names in it (e.g. using os.listdir('C:/Test')) when it is not
empty?
--
https://mail.python.org/mailman/listinfo/python-list
Re: Test for an empty directory that could be very large if it is not empty?
Virgil Stokes writes:
> Suppose I have a directory C:/Test that is either empty or contains
> more than 200 files, all with the same extension (e.g. *.txt). How
> can I determine if the directory is empty WITHOUT the generation of a
> list of the file names in it (e.g. using os.listdir('C:/Test')) when
> it is not empty?
What is your goal for that? Have you measured the performance difference
and decided *based on objective observation* that it's too expensive?
Certainly ‘os.listdir(foo)’ is the simplest way to determine the entries
in a directory, and thereby to test whether it is empty. That simplicity
is very valuable, and you should have a compelling, *measured* reason to
do something more complicated. What is it?
--
\ “The most dangerous man to any government is the man who is |
`\ able to think things out for himself, without regard to the |
_o__) prevailing superstitions and taboos.” —Henry L. Mencken |
Ben Finney
--
https://mail.python.org/mailman/listinfo/python-list
Re: Test for an empty directory that could be very large if it is not empty?
On 2014-08-07 08:26, Ben Finney wrote:
> Virgil Stokes writes:
> > Suppose I have a directory C:/Test that is either empty or
> > contains more than 200 files, all with the same extension
> > (e.g. *.txt). How can I determine if the directory is empty
> > WITHOUT the generation of a list of the file names in it (e.g.
> > using os.listdir('C:/Test')) when it is not empty?
>
> Certainly ‘os.listdir(foo)’ is the simplest way to determine the
> entries in a directory, and thereby to test whether it is empty.
> That simplicity is very valuable, and you should have a compelling,
> *measured* reason to do something more complicated. What is it?
With all the changes in 2->3 where many listy things were made into
iteratory things (e.g. range()), I was surprised that os.listdir()
didn't do likewise since I believe that just about every OS uses some
iterator-like call behind the scenes anyways.
The difference in timings when serving a web-request are noticeable
(in my use-case, I had to change my algorithm and storage structure
to simplify/avoid heavily-populated directories)
-tkc
--
https://mail.python.org/mailman/listinfo/python-list
Re: Davis putnam algorithm for satisfiability...
On 05Aug2014 07:03, varun...@gmail.com wrote: Thank you Cameron. Your post was very helpful. If you don't mind I'd like to ask you the purpose of the final list in the very beginning of the code. It is being updated and then checked for the presence of a literal. If a literal is found it returns not equivalent. Could you brief me the use of a final list? Not entirely, no. The python code is not very good, so the subtleties of the algorithm are harder to see on inspection. We can talk about those issues later if you like. It looks to me as though this is a truncated version of the full algorithm. It is currently written to abort the whole program if it decides that the cnf is not satisfiable. Maybe. In the (I am guessing hacked) code in your email, any single element sub-cnf has its components appended to the final_list and then the list is scanned for nonempty items; if one is found the whole program aborts. Otherwise the list itself is returned (and universally ignored, which is why I think this code is modified from a more complete original). I think in the original the final_list is supposed to be a list of things to examine later, possibly a list of subexpressions not yet determined to be satisfiable. In this code it is never examined and you could possibly get away with a direct examination of cnf[0][0] at that point, ignoring final_list. The only reason I have any uncertainty is that the cnf trees get modified by the del_sat() function, and so I'm not sure that the stuff put on final_list is unchanged later. So the short answer is: final_list is almost unused in this version of the code and could possibly be removed, but the code is sufficiently uncommented and clearly not the original algorithm, and the cnf structured modified in place, that I am not entirely sure. It is further complicated by the fact that this is not just the davis-putnam algorithm on its own, it is that algorithm being used (I think) to compare two boolean logic circuits for equivalence, possibly by assembling a cnf representing circuit1 xor circuit2: if they are equivalent then I would expect that to be not satisfiable but I have not thought it through completely. You'd better hope those two circuits have no loops; I would not expect the algorithm to be sufficient in the face of a loop. Cheers, Cameron Simpson If I had thought about it, I wouldn't have done the experiment. The literature was full of examples that said you can't do this. --Spencer Silver on the work that led to the unique adhesives for 3-M "Post-It" Notepads. -- https://mail.python.org/mailman/listinfo/python-list
Re: Test for an empty directory that could be very large if it is not empty?
On 8/6/2014 6:44 PM, Tim Chase wrote:
On 2014-08-07 08:26, Ben Finney wrote:
Virgil Stokes writes:
Suppose I have a directory C:/Test that is either empty or
contains more than 200 files, all with the same extension
(e.g. *.txt). How can I determine if the directory is empty
WITHOUT the generation of a list of the file names in it (e.g.
using os.listdir('C:/Test')) when it is not empty?
Certainly ‘os.listdir(foo)’ is the simplest way to determine the
entries in a directory, and thereby to test whether it is empty.
That simplicity is very valuable, and you should have a compelling,
*measured* reason to do something more complicated. What is it?
With all the changes in 2->3 where many listy things were made into
iteratory things (e.g. range()), I was surprised that os.listdir()
didn't do likewise since I believe that just about every OS uses some
iterator-like call behind the scenes anyways.
I expect 3.5 will have a scandir generator function.
The difference in timings when serving a web-request are noticeable
(in my use-case, I had to change my algorithm and storage structure
to simplify/avoid heavily-populated directories)
-tkc
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
Re: Test for an empty directory that could be very large if it is not empty?
Tim Chase writes: > The difference in timings when serving a web-request are noticeable > (in my use-case, I had to change my algorithm and storage structure to > simplify/avoid heavily-populated directories) So, if the requirement is “test whether the directory is empty faster than N microseconds”, that's quite different from “without the generation of a list of the file names”. The former may entail the latter, but that's not to be assumed, and chasing an optimisation prematurely is a common cause of terrible code. Therefore, I'm asking the OP what is their (so far unstated) reason for caring about the implementation of a standard library call. Without that, it would be folly to try to suggest a solution. With that, it may turn out the stated requirement isn't relevant for satisfying the actual requirement. I don't know (and it's possible the OP doesn't know) the relevance of the “create a list of entries” part, so I asked. -- \ “Science is a way of trying not to fool yourself. The first | `\ principle is that you must not fool yourself, and you are the | _o__) easiest person to fool.” —Richard P. Feynman, 1964 | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
Terry Reedy wrote: > On 8/6/2014 9:47 AM, beliav...@aol.com.dmarc.invalid wrote: > >> Fortran compiler vendors such as Intel, IBM, Oracle/SUN and open > > *Vendors* sell compilers for money, which they can then use to *pay* > people to do unfun stuff that volunteers don't want and should not have > to do. Red Hat does this, and will offer support for 2.7 until 2023. But even Red Hat doesn't offer to support software forever -- Python 2.3 has just reached end of life with paid Red Hat support earlier this year. Anyone still using 2.3 now has two choices, keep using it without support, or upgrade. The same will apply to 2.7 users. It's not like their computer will suddenly stop running 2.7. Come 2020 when Python 2.7 stops receiving free support from the core developers, there's a business opportunity for the 2.7-naysayers. Red Hat support is Red Hat Enterprise Linux only. There may be paid support from companies like ActiveState, but that's likely to be Windows only (I could be wrong about that). So there's the opportunity: in 2020, those naysayers who are convinced that Python 3 is a mistake can offer paid support on whatever platforms they like. > Actually, I am beginning to think that 2.7 should be split off for 3.x > development and charged for. Python is open source. Anyone can fork it, and release 2.8, 2.9, 2.10, as many versions they like. The only thing they can't do is call it "Python 2.8" without agreement from the PSF, which they won't get. But they won't fork it, for two reasons: Complaining is cheap, actually maintaining a programming language is hard work. And deep down they know that a fork will be just a waste of time. This is not like the fork of the X-11 windowing system a few years back, for all the complaints and whinging about Python 3 even the nay-sayers know that the world will remain full behind Guido, the core developers and the PSF, who are all committed to Python 3. Let me be frank here: the core developers are committed to making the process of migrating from 2 to 3 as easy as possible without compromising Python 3 in any serious manner. E.g. minor cosmetic warts, like the re-introduction of u"" syntax just for backwards compatibility reasons, may be allowed, reversing design decisions like strings being Unicode rather than bytes will not be. But ultimately, people will need to make a choice: - spend the time and effort and money to migrate from Python 2 to 3; - spend an order of magnitude more time and effort and money to re-write their applications in another language; - pay somebody to support Python 2.7 for as long as needed; - or do without bug fixes and security updates. If you want bug fixes, security updates AND feature enhancements, for free, you have have to migrate to Python 3 (or another language). If you're unhappy with that, write to Oprah, I'm sure she'll listen. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Wikibooks example doesn't work
number = 7
guess = -1
count = 0
print("Guess the number!")
while guess != number:
guess = int(input("Is it... "))
count = count + 1
if guess == number:
print("Hooray! You guessed it right!")
elif guess < number:
print("It's bigger...")
elif guess > number:
print("It's not so big.")
if count > 3:
print("That must have been complicated.")
else:
print("Good job!")
http://en.wikibooks.org/wiki/Non-Programmer%27s_Tutorial_for_Python_3/Decisions
Why not?
I think I know why it isn't working, but I don't know enough yet on
how it should work.
The If statement isn't getting read.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Wikibooks example doesn't work
On Thu, Aug 7, 2014 at 12:58 PM, Seymore4Head wrote: > Why not? > I think I know why it isn't working, but I don't know enough yet on > how it should work. > The If statement isn't getting read. One thing you need to learn about Python... or, for that matter, pretty much any language. "It isn't working" is not very helpful; what you need to do is show what you expect and what it does. If the script throws an exception, post the full traceback. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Wikibooks example doesn't work
In Seymore4Head
writes:
> number = 7
> guess = -1
> count = 0
>
> print("Guess the number!")
> while guess != number:
> guess = int(input("Is it... "))
> count = count + 1
> if guess == number:
> print("Hooray! You guessed it right!")
> elif guess < number:
> print("It's bigger...")
> elif guess > number:
> print("It's not so big.")
>
> if count > 3:
> print("That must have been complicated.")
> else:
> print("Good job!")
> http://en.wikibooks.org/wiki/Non-Programmer%27s_Tutorial_for_Python_3/Decisions
> Why not?
> I think I know why it isn't working, but I don't know enough yet on
> how it should work.
> The If statement isn't getting read.
It would help tremendously if you gave us more detail than "it doesn't
work".
Do you get an error message?
Does the program not execute at all?
Does it execute, but give unexpected results?
--
John Gordon Imagine what it must be like for a real medical doctor to
gor...@panix.comwatch 'House', or a real serial killer to watch 'Dexter'.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Test for an empty directory that could be very large if it is not empty?
Ben Finney wrote:
> Virgil Stokes writes:
>
>> Suppose I have a directory C:/Test that is either empty or contains
>> more than 200 files, all with the same extension (e.g. *.txt). How
>> can I determine if the directory is empty WITHOUT the generation of a
>> list of the file names in it (e.g. using os.listdir('C:/Test')) when
>> it is not empty?
>
> What is your goal for that? Have you measured the performance difference
> and decided *based on objective observation* that it's too expensive?
Normally I would agree with you, but this is one case where there is no need
to measure, we can tell in advance that at least sometimes there will be a
severe performance hit simply by considering the nature of file systems. In
particular, consider the case where the directory is a remote file system
on the other side of the world over a link with many dropped packets or
other noise. Waiting for 200 thousand file names to be transmitted, only to
throw them away, is surely going to be slower than (say) the results of a
call to os.stat. (Assuming that gives the answer.)
The difficult question then becomes: is it reasonable to (potentially) slow
down the common case of local file systems by a tiny amount, in order to
protect against the (rare) case where it will give a big speed things up?
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
Re: Wikibooks example doesn't work
On Wed, 06 Aug 2014 22:58:51 -0400, Seymore4Head
wrote:
>number = 7
>guess = -1
>count = 0
>
>print("Guess the number!")
>while guess != number:
>guess = int(input("Is it... "))
>count = count + 1
>if guess == number:
>print("Hooray! You guessed it right!")
>elif guess < number:
>print("It's bigger...")
>elif guess > number:
>print("It's not so big.")
The part to here is supposed to be an example to allow the user to
guess at a number (7) with an infinite amount of tries.
This part was added as an exercise.
A counter is added to give 3 tries to guess the number.
It is supposed to stop after count gets to 3. It doesn't. It just
keeps looping back and asking for another guess.
>if count > 3:
>print("That must have been complicated.")
>else:
>print("Good job!")
>
>http://en.wikibooks.org/wiki/Non-Programmer%27s_Tutorial_for_Python_3/Decisions
>
>Why not?
>I think I know why it isn't working, but I don't know enough yet on
>how it should work.
>The If statement isn't getting read.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
Wolfgang Keller wrote: > Linux was made by geeks who didn't have a clue of ergonomics for > screenworkers and didn't care to get one. I can only repeat what you said earlier: "You should get a clue in stead [sic] of just fantasizing up assumptions based on ignorance." I daresay that Linus Torvalds spends more time in front of a computer screen than most 9 to 5 "screenworkers". By the way, you keep replying to people, and quoting them, but deleting their name. Please leave the attribution in place, so we know who you are replying to. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Wikibooks example doesn't work
Seymore4Head wrote: [snip code that looks fine to me] > Why not? I don't know. What does "doesn't work" mean? "It didn't do what I expected." (What did you expect? What did it do?) "It printed an error message." (Care to tell it what it was?) "It crashed the computer." (Some more details might help.) "My computer caught fire when I ran it." (I'm sorry to hear that.) Don't expect us to read your mind and know what you know. And don't expect us to run the code and see for ourselves -- we might, but we normally shouldn't need to, if you give as the details you already have. And of course just because it "doesn't work" on your system, doesn't mean it won't work on ours. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
beliav...@aol.com wrote: > Fortran compiler vendors such as Intel, IBM, Oracle/SUN and open source > projects such as gfortran are updating their compilers to the Fortran 2003 > and 2008 standards while also keeping the ability to compile all the old > Fortran code. FORTRAN 77 programmers and programs will not be forced to > move to modern Fortran, How about FORTRAN IV and FORTRAN 66 users? Where's their support? Why aren't they moaning and gnashing their teeth that they're so cruelly and unreasonably forced to upgrade? > but I'm not sure that Python 2.x users can be as > confident that Python 2.x will be supported on future operating systems. Oh well, life wasn't meant to be easy. Fortunately they can run it under Windows 98 or Centos 3.5 in a virtual machine. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Wikibooks example doesn't work
Seymore4Head wrote:
> On Wed, 06 Aug 2014 22:58:51 -0400, Seymore4Head
> wrote:
>
>>number = 7
>>guess = -1
>>count = 0
>>
>>print("Guess the number!")
>>while guess != number:
>>guess = int(input("Is it... "))
>>count = count + 1
>>if guess == number:
>>print("Hooray! You guessed it right!")
>>elif guess < number:
>>print("It's bigger...")
>>elif guess > number:
>>print("It's not so big.")
>
> The part to here is supposed to be an example to allow the user to
> guess at a number (7) with an infinite amount of tries.
>
>
> This part was added as an exercise.
Ah, now things make sense! Your subject line is misleading! It's not that
the wikibooks example doesn't work, the example works fine. It's that the
code you added to it doesn't do what you expected. You should have said.
> A counter is added to give 3 tries to guess the number.
> It is supposed to stop after count gets to 3. It doesn't. It just
> keeps looping back and asking for another guess.
You don't check the counter until after the loop has finished. It needs to
be inside the loop, not outside:
while looping:
# See the indent?
# this is inside the loop
# No indent.
# This is outside the loop.
Also, having reached the count of three, you will want to break out of the
loop. The "break" command does that.
Is this enough of a hint to continue? Please feel free to ask any further
questions you need.
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
Re: Wikibooks example doesn't work
On Thu, 07 Aug 2014 13:43:40 +1000, Steven D'Aprano
wrote:
>Seymore4Head wrote:
>
>> On Wed, 06 Aug 2014 22:58:51 -0400, Seymore4Head
>> wrote:
>>
>>>number = 7
>>>guess = -1
>>>count = 0
>>>
>>>print("Guess the number!")
>>>while guess != number:
>>>guess = int(input("Is it... "))
>>>count = count + 1
>>>if guess == number:
>>>print("Hooray! You guessed it right!")
>>>elif guess < number:
>>>print("It's bigger...")
>>>elif guess > number:
>>>print("It's not so big.")
>>
>> The part to here is supposed to be an example to allow the user to
>> guess at a number (7) with an infinite amount of tries.
>>
>>
>> This part was added as an exercise.
>
>
>Ah, now things make sense! Your subject line is misleading! It's not that
>the wikibooks example doesn't work, the example works fine. It's that the
>code you added to it doesn't do what you expected. You should have said.
>
I copied it verbatim from the web page's solution. After indenting as
you suggested, it does work now though.
Thanks
>
>> A counter is added to give 3 tries to guess the number.
>> It is supposed to stop after count gets to 3. It doesn't. It just
>> keeps looping back and asking for another guess.
>
>You don't check the counter until after the loop has finished. It needs to
>be inside the loop, not outside:
>
>while looping:
># See the indent?
># this is inside the loop
>
># No indent.
># This is outside the loop.
>
>
>Also, having reached the count of three, you will want to break out of the
>loop. The "break" command does that.
>
>Is this enough of a hint to continue? Please feel free to ask any further
>questions you need.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Wikibooks example doesn't work
On 7/08/2014 1:25 PM, Seymore4Head wrote: This part was added as an exercise. A counter is added to give 3 tries to guess the number. It is supposed to stop after count gets to 3. It doesn't. It just keeps looping back and asking for another guess. You've misread the exercise: Modify the higher or lower program from this section to keep track of how many times the user has entered the wrong number. If it is more than 3 times, print "That must have been complicated." at the end, otherwise print "Good job!" There's nothing there about breaking out of the loop after 3 attempts, just producing a different end message on successful completion based on how many attempts were made. The Wikibooks example works as specified. -- https://mail.python.org/mailman/listinfo/python-list
Re: Wikibooks example doesn't work
On 08/06/2014 08:48 PM, Seymore4Head wrote: On Thu, 07 Aug 2014 13:43:40 +1000, Steven D'Aprano wrote: Seymore4Head wrote: On Wed, 06 Aug 2014 22:58:51 -0400, Seymore4Head wrote: [snip] Ah, now things make sense! Your subject line is misleading! It's not that the wikibooks example doesn't work, the example works fine. It's that the code you added to it doesn't do what you expected. You should have said. I copied it verbatim from the web page's solution. After indenting as you suggested, it does work now though. Thanks A counter is added to give 3 tries to guess the number. It is supposed to stop after count gets to 3. It doesn't. It just keeps looping back and asking for another guess. I just took a look at that web page, and I see what your problem actually is... You are misunderstanding the problem. The problem does NOT say to end the loop at three tries, just to keep track of the number of tries. It's not actually specific, but the implication is that AFTER the loop display a message depending on the number of actual tires. The wikibooks solution IS correct, you understanding of the stated problem is not. My response here may sound harsh but I don't mean it to be, so please don't take it that way. Python is a great language to learn -- keep it up, you'll get it!:-) -=- Larry -=- -- https://mail.python.org/mailman/listinfo/python-list
RE: Wikibooks example doesn't work8
The if statement in question isn't inside the while loop.
White space and indentation is meaningful in python, so putting the if count >
3 block at same indentation as the while statement effectively places it
outside the loop.
Regards,
Drew
Original message
From: Seymore4Head
Date:08/06/2014 20:32 (GMT-08:00)
To: python-list@python.org
Subject: Re: Wikibooks example doesn't work
On Wed, 06 Aug 2014 22:58:51 -0400, Seymore4Head
wrote:
>number = 7
>guess = -1
>count = 0
>
>print("Guess the number!")
>while guess != number:
>guess = int(input("Is it... "))
>count = count + 1
>if guess == number:
>print("Hooray! You guessed it right!")
>elif guess < number:
>print("It's bigger...")
>elif guess > number:
>print("It's not so big.")
The part to here is supposed to be an example to allow the user to
guess at a number (7) with an infinite amount of tries.
This part was added as an exercise.
A counter is added to give 3 tries to guess the number.
It is supposed to stop after count gets to 3. It doesn't. It just
keeps looping back and asking for another guess.
>if count > 3:
>print("That must have been complicated.")
>else:
>print("Good job!")
>
>http://en.wikibooks.org/wiki/Non-Programmer%27s_Tutorial_for_Python_3/Decisions
>
>Why not?
>I think I know why it isn't working, but I don't know enough yet on
>how it should work.
>The If statement isn't getting read.
--
https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
Re: Wikibooks example doesn't work
Larry Hudson writes: > I just took a look at that web page, and I see what your problem > actually is... > You are misunderstanding the problem. The problem does NOT say to end > the loop at three tries, just to keep track of the number of tries. > It's not actually specific, but the implication is that AFTER the loop > display a message depending on the number of actual tires. Could it be re-phrased to state the exercise requirements more clearly? Maybe you could edit the wiki page to prevent future confusion on this exercise. -- \ “Are you pondering what I'm pondering?” “I think so, Brain, but | `\ wouldn't his movies be more suitable for children if he was | _o__) named Jean-Claude van Darn?” —_Pinky and The Brain_ | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Test for an empty directory that could be very large if it is not empty?
Virgil Stokes wrote: How can I determine if the directory is empty WITHOUT the generation of a list of the file names Which platform? On Windows, I have no idea. On Unix you can't really do this properly without access to opendir() and readdir(), which Python doesn't currently wrap. Will the empty directories be newly created, or could they be ones that *used* to contain 20 files that have since been deleted? If they're new or nearly new, you could probably tell from looking at the size reported by stat() on the directory. The difference between a fresh empty directory and one with 20 files in it should be fairly obvious. A viable strategy might be: If the directory is very large, assume it's not empty. If it's smallish, list its contents to find out for sure. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
AttributeError: 'module' object has no attribute 'fork'
Hi,
Code:
import os, time
def child(pipeout):
zzz = 0
while True:
time.sleep(zzz)
msg = ('Spam %03d' % zzz).encode()
os.write(pipeout, msg)
zzz = (zzz+1) % 5
def parent():
pipein, pipeout = os.pipe()
if os.fork() == 0:
child(pipeout)
else:
while True:
line = os.read(pipein, 32)
print('Parent %d got [%s] at %s' % (os.getpid(), line, time.time()))
parent()
Output:
Traceback (most recent call last):
File "C:/Python34/pipe1.py", line 17, in
parent()
File "C:/Python34/pipe1.py", line 11, in parent
if os.fork() == 0:
AttributeError: 'module' object has no attribute 'fork'
Why does this error appear? Module os provides fork(). How to solve this
problem? Kindly help.
--
https://mail.python.org/mailman/listinfo/python-list
