Sent from my iPhone On Apr 12, 2011, at 8:05 PM, python-list-requ...@python.org wrote:
> Send Python-list mailing list submissions to > python-list@python.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.python.org/mailman/listinfo/python-list > or, via email, send a message with subject or body 'help' to > python-list-requ...@python.org > > You can reach the person managing the list at > python-list-ow...@python.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Python-list digest..." > Today's Topics: > > 1. Re: Feature suggestion -- return if true (Ethan Furman) > 2. Re: [OT] Free software versus software idea patents > (Steven D'Aprano) > 3. Re: [OT] Free software versus software idea patents > (Steven D'Aprano) > 4. Re: Feature suggestion -- return if true (Steven D'Aprano) > 5. Re: [OT] Free software versus software idea patents > (geremy condra) > 6. Re: Can not uninstall activepython. Missing msi ? > (Sridhar Ratnakumar) > 7. [Bug / Feature Request] IDLE Shell (rantingrick) > 8. Re: [Bug / Feature Request] IDLE Shell (James Mills) > 9. Re: Feature suggestion -- return if true (Ethan Furman) > 10. Re: Feature suggestion -- return if true (Chris Angelico) > Westley Mart�nez wrote: >> On Tue, 2011-04-12 at 16:06 -0700, Ethan Furman wrote: >>> --> def func(): >>> --> var1 = something() >>> --> var2 = something_else('this') >>> --> return? var1.hobgle(var2) >>> --> var3 = last_resort(var1) >>> --> return var3.wiglat(var2) >> The question mark makes the programmer look like he wasn't sure of what >> he was doing at the time. "Hmm, should I return this object or not?" > > Yeah, I'm definitely -1 on the ?, as well as -1 on the idea. All other major > flow control uses indentation, and this does not. > > ~Ethan~ > > On Tue, 12 Apr 2011 13:37:08 -0600, Ian Kelly wrote: > >> There is at least one method of measuring it without resorting to sales >> figures: logging user-agent data from web browsers. Is it perfectly >> accurate? Of course not. But there are a number of different >> organizations that do this, sampling hundreds of thousands of different >> websites, and they consistently report that the various versions of >> Windows have a total usage share ranging from 80% to 90%. That at least >> gives us an upper and lower bound with a great deal of confidence. In >> the same data, Apple systems range from about 7% to 15%, and Linux >> musters a meager 1% to 3%. > > Yes, but it's the most important 1%. > > *wink* > > > Seriously, I would expect that Linux is seriously under-reported in > surveys based on user-agent, for various reasons, starting with the > number of people who have their user-agent set to claim to be IE on > Windows even when they're running (say) Konqueror on Linux. Nevertheless, > I'd be gratified if Linux marketshare of the desktop was as high as 5%. > That would be awesome. > > Another interesting source of data might be on-line games that offer > clients for multiple platforms. E.g. EVE Online (to pick an old, well > established one that just so happens to use Python as its scripting > engine). > > > > > -- > Steven > > On Tue, 12 Apr 2011 13:43:00 -0400, Terry Reedy wrote: > >> Anyone here who does not understand how absurd software patents can get >> should contemplate the following (based on a real patent from about 20 >> years ago, when CDroms were new. >> >> A Methods for Ensuring that the Correct CDROM is in the CDROM drive. >> >> While the correct cdrom is not in the drive: >> Display a message asking the user to insert the correct CD. >> >> Buried in a page of verbiage, that was it, completely obvious and >> unoriginal. > > There's no doubt that, for some reason, the US Patent Office has an > institutional blind-spot in certain areas. As the joke goes, you can take > any existing patent, scrawl "on the Internet" over it in red crayon, and > they will grant you a patent on it. > > But I'm also sure that if you look hard enough, there will be hardware > patents that are as inane. For the longest time, you could patent > perpetual motion machines. Now you can patent perpetual motion machines > so long as you don't use the words "perpetual motion" or "free energy". > > The real question should not be "how bad are the worst patents?", or "how > good are the best patents?", but "overall, does the patent system make > things better or worse in general, and how can we reduce the harm done in > favour of more good?". > > (I'll also point out that there's remarkably little evidence that > *hardware* patents promote and support innovation and invention, even > though it is conventional wisdom that it does. People on *both* sides of > the debate are amazingly resistant to the idea of evidence-based policy.) > > > >>> That is what made the last Supreme Court decision (from this argument >>> in part) so important... because for the first time the U.S. Supreme >>> Court is beginning to buy it ... in part. >> >> What might help lawyers understand the obsurdity of software patents >> would be to have them contemplate the possibility of patents on laws and >> legal arguments, so that a legislature could not write a law, nor a >> lawyer submit a legal brief, without possibly having to pay royalties or >> violate a patent. > > That would be a patent on a business process, which is allowed. In fact, > as I recall, at least one lawyer has made an attempt to patent a business > process relating to law. > > > > Too-lazy-to-google-for-it-ly y'rs, > > -- > Steven > > On Tue, 12 Apr 2011 16:48:31 -0700, Ethan Furman wrote: > >> Westley Martínez wrote: >>> On Tue, 2011-04-12 at 16:06 -0700, Ethan Furman wrote: >>>> --> def func(): >>>> --> var1 = something() >>>> --> var2 = something_else('this') --> return? >>>> var1.hobgle(var2) >>>> --> var3 = last_resort(var1) >>>> --> return var3.wiglat(var2) >>> >>> The question mark makes the programmer look like he wasn't sure of what >>> he was doing at the time. "Hmm, should I return this object or not?" >>> >>> >> Yeah, I'm definitely -1 on the ?, as well as -1 on the idea. All other >> major flow control uses indentation, and this does not. > > Neither return nor raise use indentation, and you don't get much more > major than those. Nor do list comps or generator expressions. > > Indentation is not appropriate here because it doesn't involve a block of > code. The whole point is that it just involves a single expression. > > But in any case, I'm -1 on any syntax involving ? in Python, and +0 on > the concept on a conditional return. I suspect it's too specialised to be > worth special syntax or a keyword, but I can definitely see some uses for > it. > > > > -- > Steven > > On Tue, Apr 12, 2011 at 4:56 PM, Steven D'Aprano > <steve+comp.lang.pyt...@pearwood.info> wrote: > > <snip> > >> That would be a patent on a business process, which is allowed. In fact, >> as I recall, at least one lawyer has made an attempt to patent a business >> process relating to law. > > IBM tried patenting the business of patent trolling, which I found hilarious. > > Geremy Condra > > Looks like this is resolved for you, > http://community.activestate.com/node/6558 > > On Tue, Apr 12, 2011 at 10:13 AM, goldtech <goldt...@worldpost.com> wrote: >> Hi, >> >> I want to uninstall Active Python 2.6.2.2 and upgrade. Certain things >> are not working and it's probably time to upgrade anyway. When I try >> to uninstall it says "missing msi". >> >> Before I delete all the folders and clean the registry out is there >> something I can try to have a normal or more graceful uninstall? Using >> WinXP. >> >> Thanks, >> >> Lee G. >> -- >> http://mail.python.org/mailman/listinfo/python-list >> > > > Hello folks, > > In the IDLE shell when pressing the key combos "Control+Up" and > "Control+Down" the insertion cursor should jump to the nearest prompt > (>>>) above or below it's current position respectively. > > Note: In the Editor Window of IDLE the current behavior is for the > insertion cursor to jump to the next block (which is just fine for the > Editing Source code!) HOWEVER in the shell we need a much more > intelligent behavior. > > py> shell != editor > True > > On Wed, Apr 13, 2011 at 11:50 AM, rantingrick <rantingr...@gmail.com> wrote: >> In the IDLE shell when pressing the key combos "Control+Up" and >> "Control+Down" the insertion cursor should jump to the nearest prompt >> (>>>) above or below it's current position respectively. >> >> Note: In the Editor Window of IDLE the current behavior is for the >> insertion cursor to jump to the next block (which is just fine for the >> Editing Source code!) HOWEVER in the shell we need a much more >> intelligent behavior. > > Not to be rude or anything - but why can't you get the latest IDLE > source code, patch it, test it, see how you like it and if you feel > it useful, share the patch and/or file a bug with the patch. > > cheers > James > > -- > -- James Mills > -- > -- "Problems are solved by method" > > Steven D'Aprano wrote: >> On Tue, 12 Apr 2011 16:48:31 -0700, Ethan Furman wrote: >>> Westley Martínez wrote: >>>> On Tue, 2011-04-12 at 16:06 -0700, Ethan Furman wrote: >>>>> --> def func(): >>>>> --> var1 = something() >>>>> --> var2 = something_else('this') --> return? >>>>> var1.hobgle(var2) >>>>> --> var3 = last_resort(var1) >>>>> --> return var3.wiglat(var2) >>>> The question mark makes the programmer look like he wasn't sure of what >>>> he was doing at the time. "Hmm, should I return this object or not?" >>>> >>>> >>> Yeah, I'm definitely -1 on the ?, as well as -1 on the idea. All other >>> major flow control uses indentation, and this does not. >> Neither return nor raise use indentation, and you don't get much more major >> than those. Nor do list comps or generator expressions. > > The indentation for return and raise is the next coded line. List comps and > gen exps are basically uber-functions, and regardless of how you categorize > them when they finish it is easy to see where control goes to next because of > indentation. With this idea flow can leave the function with no indentation > clue, making it easy to miss (assuming, of course, it's not some bright > syntax highlighted color). > > ~Ethan~ > > On Wed, Apr 13, 2011 at 12:42 PM, Ethan Furman <et...@stoneleaf.us> wrote: >> The indentation for return and raise is the next coded line. List comps and >> gen exps are basically uber-functions, and regardless of how you categorize >> them when they finish it is easy to see where control goes to next because >> of indentation. With this idea flow can leave the function with no >> indentation clue, making it easy to miss (assuming, of course, it's not some >> bright syntax highlighted color). > > So if I have a function that can early-abort, I should indent after that? > > def foo(param): > resource=malloc(50000) # Shtarker, zis is Python! We don't malloc here! > if not resource: return 0 > resource[param]=5 > del resource > return 1 > > Now, this pattern of "attempt to acquire resource, return if unable > to" is probably better recoded as "acquire resource and have it throw > an error if it can't"; but if you're eyeballing for control-flow > changes, a called function throwing an error is even less obvious than > an if: return. > > Where should the indentation go? > > As I understand it, Python uses indents the way C uses braces - to > delimit blocks of code. The only reason to indent in foo() above would > be if the if has an else: > > if not resource: return 0 > else: > resource[param]=5 > del resource > return 1 > > or, flipping that the other way around: > > if resource: > resource[param]=5 > del resource > return 1 > return 0 > > but both of these are grossly inferior to: > > def foo(param): > resource=generate_resource() > resource.dosomething(param,5) > return 1 > > However, what's to tell you that generate_resource() will throw a > KaosError if Siegfried is around? > > (Oh, and apologies to all for picking a different comedy source for my > references. Sometimes even a python has to get smart...) > > Chris Angelico > > -- > http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
