Python-list Digest, Vol 91, Issue 89

[Aman Nijhawan]

Sent from my iPhone

On Apr 12, 2011, at 8:05 PM, python-list-request at python.org wrote:

> Send Python-list mailing list submissions to
>    python-list at 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-request at python.org
>
> You can reach the person managing the list at
>    python-list-owner at 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.python at 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 <goldtech at 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 <rantingrick at 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 <ethan at 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