Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!feeder.news-service.com!news2.euro.net!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:from:in-reply-to:mime-version:date:message-id:subject:to :content-type:content-transfer-encoding; b=QRTgaomdSmHLHw8CMFYlNlwtsBYfTzunLhnSQry3b5sf9Sn7DJ0jp2/d44TszozPIE +/LYCL2Tgu8pVNv0V6Ch+c3VTt+vLfT/1GQbmkpxXEsxTv+WhxX/FjISbNVk4htwqBFR UpOzIRXOzkZqZlBa5wbCkqLt0pyJ++KuPAok4=
References: <mailman.1520.1302663655.9058.python-list@python.org>
From: Aman Nijhawan <amannijhawan@gmail.com>
In-Reply-To: <mailman.1520.1302663655.9058.python-list@python.org>
Mime-Version: 1.0 (iPhone Mail 8B117)
Date: Tue, 12 Apr 2011 20:06:48 -0700
Subject: Re: Python-list Digest, Vol 91, Issue 89
To: "python-list@python.org" <python-list@python.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.301.1302664044.9059.python-list@python.org>
Lines: 345
NNTP-Posting-Host: 82.94.164.166
Xref: x330-a1.tempe.blueboxinc.net comp.lang.python:3112

Sent from my iPhone

On Apr 12, 2011, at 8:05 PM, python-list-request@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-request@python.org
>
> You can reach the person managing the list at
>    python-list-owner@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=EF=BF=BDnez wrote:
>> On Tue, 2011-04-12 at 16:06 -0700, Ethan Furman wrote:
>>> --> def func():
>>> -->     var1 =3D something()
>>> -->     var2 =3D something_else('this')
>>> -->     return? var1.hobgle(var2)
>>> -->     var3 =3D 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 m=
ajor 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=EDnez wrote:
>>> On Tue, 2011-04-12 at 16:06 -0700, Ethan Furman wrote:
>>>> --> def func():
>>>> -->     var1 =3D something()
>>>> -->     var2 =3D something_else('this') -->     return?
>>>> var1.hobgle(var2)
>>>> -->     var3 =3D 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@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 busines=
s
>> process relating to law.
>
> IBM tried patenting the business of patent trolling, which I found hilari=
ous.
>
> 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@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 !=3D editor
> True
>
> On Wed, Apr 13, 2011 at 11:50 AM, rantingrick <rantingrick@gmail.com> wro=
te:
>> 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=EDnez wrote:
>>>> On Tue, 2011-04-12 at 16:06 -0700, Ethan Furman wrote:
>>>>> --> def func():
>>>>> -->     var1 =3D something()
>>>>> -->     var2 =3D something_else('this') -->     return?
>>>>> var1.hobgle(var2)
>>>>> -->     var3 =3D last_resort(var1)
>>>>> -->     return var3.wiglat(var2)
>>>> The question mark makes the programmer look like he wasn't sure of wha=
t
>>>> 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 ma=
jor 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 catego=
rize them when they finish it is easy to see where control goes to next bec=
ause of indentation.  With this idea flow can leave the function with no in=
dentation 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@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 categor=
ize
>> them when they finish it is easy to see where control goes to next becau=
se
>> 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=3Dmalloc(50000) # Shtarker, zis is Python! We don't malloc he=
re!
>    if not resource: return 0
>    resource[param]=3D5
>    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]=3D5
>        del resource
>        return 1
>
> or, flipping that the other way around:
>
>    if resource:
>        resource[param]=3D5
>        del resource
>        return 1
>    return 0
>
> but both of these are grossly inferior to:
>
> def foo(param):
>    resource=3Dgenerate_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