Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #31725 > unrolled thread

Re: A desperate lunge for on-topic-ness

Back to article view | Back to comp.lang.python

Contents

  Re: A desperate lunge for on-topic-ness Jean-Michel Pichavant <jeanmichel@sequans.com> - 2012-10-19 11:21 +0200
    Re: A desperate lunge for on-topic-ness Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-10-19 22:14 +0000
      Re: A desperate lunge for on-topic-ness Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-10-19 20:23 -0400
        Re: A desperate lunge for on-topic-ness Grant Edwards <invalid@invalid.invalid> - 2012-10-20 14:18 +0000
          Re: A desperate lunge for on-topic-ness Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-10-20 15:10 -0400
          Re: A desperate lunge for on-topic-ness Walter Hurry <walterhurry@lavabit.com> - 2012-10-20 20:02 +0000
          Re: A desperate lunge for on-topic-ness David Robinow <drobinow@gmail.com> - 2012-10-20 16:02 -0400
          Re: A desperate lunge for on-topic-ness Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-10-21 08:07 +0000
            Re: A desperate lunge for on-topic-ness Chris Angelico <rosuav@gmail.com> - 2012-10-21 20:20 +1100
              Re: A desperate lunge for on-topic-ness Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-10-21 10:00 +0000
                Re: printing (was: A desperate lunge for on-topic-ness) Tim Chase <python.list@tim.thechases.com> - 2012-10-21 06:03 -0500
                Re: A desperate lunge for on-topic-ness Chris Angelico <rosuav@gmail.com> - 2012-10-21 22:43 +1100
                  Re: A desperate lunge for on-topic-ness Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-10-21 19:11 +0000
                    Re: A desperate lunge for on-topic-ness Grant Edwards <invalid@invalid.invalid> - 2012-10-21 19:23 +0000
                      Re: A desperate lunge for on-topic-ness Roy Smith <roy@panix.com> - 2012-10-21 16:19 -0400
                        Re: A desperate lunge for on-topic-ness Chris Angelico <rosuav@gmail.com> - 2012-10-22 07:38 +1100
                    Re: A desperate lunge for on-topic-ness Chris Angelico <rosuav@gmail.com> - 2012-10-22 07:22 +1100
                      Re: A desperate lunge for on-topic-ness Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-10-22 06:30 +0000
                        Re: A desperate lunge for on-topic-ness Chris Angelico <rosuav@gmail.com> - 2012-10-22 18:03 +1100
                        Re: A desperate lunge for on-topic-ness Roy Smith <roy@panix.com> - 2012-10-22 08:29 -0400
                          RE: A desperate lunge for on-topic-ness "Prasad, Ramit" <ramit.prasad@jpmorgan.com> - 2012-10-22 20:48 +0000
                        Re: A desperate lunge for on-topic-ness Ian Kelly <ian.g.kelly@gmail.com> - 2012-10-22 16:02 -0600
                        Re: A desperate lunge for on-topic-ness Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-10-22 21:39 -0400
                        Re: A desperate lunge for on-topic-ness Joshua Landau <joshua.landau.ws@gmail.com> - 2012-10-23 08:35 +0100
                        Re: A desperate lunge for on-topic-ness Ian Kelly <ian.g.kelly@gmail.com> - 2012-10-23 10:50 -0600
                          Re: A desperate lunge for on-topic-ness Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-10-23 22:34 +0000
                            Re: A desperate lunge for on-topic-ness Ian Kelly <ian.g.kelly@gmail.com> - 2012-10-23 17:24 -0600
                              Re: A desperate lunge for on-topic-ness Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-10-24 00:04 +0000
            Re: A desperate lunge for on-topic-ness Gene Heskett <gheskett@wdtv.com> - 2012-10-21 07:08 -0400
            Re: A desperate lunge for on-topic-ness Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-10-21 12:42 -0400
          Re: A desperate lunge for on-topic-ness DJC <djc@news.invalid> - 2012-10-21 15:06 +0100
      Re: A desperate lunge for on-topic-ness Tim Chase <python.list@tim.thechases.com> - 2012-10-19 22:27 -0500
        Re: A desperate lunge for on-topic-ness rusi <rustompmody@gmail.com> - 2012-10-20 00:35 -0700
      Re: A desperate lunge for on-topic-ness Roy Smith <roy@panix.com> - 2012-10-20 16:37 -0400
        Re: A desperate lunge for on-topic-ness Walter Hurry <walterhurry@lavabit.com> - 2012-10-21 21:58 +0000

Page 2 of 2 — ← Prev page 1 [2]

#31902

Roy Smith wrote:
> Pet peeve of the day...
> 
> Why do you have to write:
> 
> global foo
> foo = 4
> 
> when
> 
> global foo = 4
> 
> would have been so much easier?

To make it more annoying for people who use globals, duh. :)

Ramit Prasad

This email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of
securities, accuracy and completeness of information, viruses,
confidentiality, legal privilege, and legal entity disclaimers,
available at http://www.jpmorgan.com/pages/disclosures/email.  

[toc] | [prev] | [next] | [standalone]

#31906

On Mon, Oct 22, 2012 at 1:03 AM, Chris Angelico <rosuav@gmail.com> wrote:
> Python's system "just works" most of
> the time, but can introduce yet another trap for the unsuspecting
> newbie who doesn't understand the difference between rebinding and
> mutating; I've not looked into multiple levels of closures but I
> suspect there'll be odd limitations there, as there's only one
> "nonlocal" keyword.

On my wishlist for Python is a big, fat SyntaxError for any variable
that could be interpreted as either local or nonlocal and is not
explicitly declared as either.  It would eliminate this sort of
confusion entirely and make code that shadows nonlocal variables much
more readable.

Ideally, the same thing would also be done for locals that shadow
globals, but I don't see how that could possibly be enforced at
compile time.

[toc] | [prev] | [next] | [standalone]

#31913

On Mon, 22 Oct 2012 16:02:34 -0600, Ian Kelly <ian.g.kelly@gmail.com>
declaimed the following in gmane.comp.python.general:

> On my wishlist for Python is a big, fat SyntaxError for any variable
> that could be interpreted as either local or nonlocal and is not
> explicitly declared as either.  It would eliminate this sort of
> confusion entirely and make code that shadows nonlocal variables much
> more readable.
>
	Which now makes code dependent upon changes to some imported modules
if someone is foolish enough to use the 

	from xyz import *

notation...

	I'd be very displeased if working code with local names suddenly
fails because some third-party package was updated.

	Yes, I prefer not to use the "from...*" notation, but how many
tutorials (especially of GUI toolkits, with their dozens of constants)
illustrate using the wildcard?
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#31918

On 23/10/2012, Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote:
> On Mon, 22 Oct 2012 16:02:34 -0600, Ian Kelly <ian.g.kelly@gmail.com>
> declaimed the following in gmane.comp.python.general:
>
>> On my wishlist for Python is a big, fat SyntaxError for any variable
>> that could be interpreted as either local or nonlocal and is not
>> explicitly declared as either.  It would eliminate this sort of
>> confusion entirely and make code that shadows nonlocal variables much
>> more readable.
>>
> 	Which now makes code dependent upon changes to some imported modules
> if someone is foolish enough to use the
>
> 	from xyz import *
>
> notation...
>
> 	I'd be very displeased if working code with local names suddenly
> fails because some third-party package was updated.
>
> 	Yes, I prefer not to use the "from...*" notation, but how many
> tutorials (especially of GUI toolkits, with their dozens of constants)
> illustrate using the wildcard?

I'm not particularly fond (or disliking) of the proposal, but we
already make changes to the structure of locals/globals and so forth
when someone does "from <something> import *". Disabling checks when
it is used is totally reasonable.

Additionally, "SyntaxError: import * only allowed at module level".
This means, as far as I grasp, one should never *manage* to create an
ambiguity here. Ian already stated this idea should (due to
neccessity) be disabled for possible globals.

[toc] | [prev] | [next] | [standalone]

#31942

On Mon, Oct 22, 2012 at 7:39 PM, Dennis Lee Bieber
<wlfraed@ix.netcom.com> wrote:
> On Mon, 22 Oct 2012 16:02:34 -0600, Ian Kelly <ian.g.kelly@gmail.com>
> declaimed the following in gmane.comp.python.general:
>
>> On my wishlist for Python is a big, fat SyntaxError for any variable
>> that could be interpreted as either local or nonlocal and is not
>> explicitly declared as either.  It would eliminate this sort of
>> confusion entirely and make code that shadows nonlocal variables much
>> more readable.
>>
>         Which now makes code dependent upon changes to some imported modules
> if someone is foolish enough to use the
>
>         from xyz import *
>
> notation...

It's already a SyntaxError to use a wildcard import anywhere other
than the module level, so its use can only affect global variables.

[toc] | [prev] | [next] | [standalone]

#31963

On Tue, 23 Oct 2012 10:50:11 -0600, Ian Kelly wrote:

>> if someone is foolish enough to use the
>>
>>         from xyz import *
>>
>> notation...
> 
> It's already a SyntaxError to use a wildcard import anywhere other than
> the module level, so its use can only affect global variables.

In Python 3.x. 

In Python 2.x, which includes the most recent version of three of the 
four "big implementations" (PyPy, Jython, IronPython) it is still legal, 
at least in theory.

I haven't tested PyPy, but IronPython 2.6 allows wildcard imports inside 
functions without even a warning. Bizarrely, Jython 2.5 *appears* to 
allow them with only a warning, but they don't take:

steve@runes:~$ jython
Jython 2.5.1+ (Release_2_5_1, Aug 4 2010, 07:18:19)
[OpenJDK Client VM (Sun Microsystems Inc.)] on java1.6.0_18
Type "help", "copyright", "credits" or "license" for more information.
>>> def test():
...     from math import *
...     return cos
...
<stdin>:2: SyntaxWarning: import * only allowed at module level
>>> test()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 3, in test
NameError: global name 'cos' is not defined


So, legal or not, they're definitely something you want to avoid.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#31971

On Tue, Oct 23, 2012 at 4:34 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Tue, 23 Oct 2012 10:50:11 -0600, Ian Kelly wrote:
>
>>> if someone is foolish enough to use the
>>>
>>>         from xyz import *
>>>
>>> notation...
>>
>> It's already a SyntaxError to use a wildcard import anywhere other than
>> the module level, so its use can only affect global variables.
>
> In Python 3.x.
>
> In Python 2.x, which includes the most recent version of three of the
> four "big implementations" (PyPy, Jython, IronPython) it is still legal,
> at least in theory.

If we're talking about making changes to the language, then we're
clearly talking about Python 3.x and beyond.  There are no more major
releases planned for 2.x.

[toc] | [prev] | [next] | [standalone]

#31979

On Tue, 23 Oct 2012 17:24:34 -0600, Ian Kelly wrote:

> On Tue, Oct 23, 2012 at 4:34 PM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
>> On Tue, 23 Oct 2012 10:50:11 -0600, Ian Kelly wrote:
>>
>>>> if someone is foolish enough to use the
>>>>
>>>>         from xyz import *
>>>>
>>>> notation...
>>>
>>> It's already a SyntaxError to use a wildcard import anywhere other
>>> than the module level, so its use can only affect global variables.
>>
>> In Python 3.x.
>>
>> In Python 2.x, which includes the most recent version of three of the
>> four "big implementations" (PyPy, Jython, IronPython) it is still
>> legal, at least in theory.
> 
> If we're talking about making changes to the language, then we're
> clearly talking about Python 3.x and beyond.  There are no more major
> releases planned for 2.x.

In what way does "it is ALREADY a SyntaxError" [emphasis added] refer to 
making future changes to the language? :)

My point is that for probably 80% or more of Python users, it is not the 
case that wildcard imports in functions are already a syntax error. 
Anyone using CPython 2.x, PyPy, Jython or IronPython have such a syntax 
error to look forward to in the future, but not now. Until then, they 
have to deal with syntax warnings, implementation-dependent behaviour, 
and as far as I can see, an outright language bug in Jython, but no 
syntax errors.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#31845

On Sunday 21 October 2012 07:02:26 Steven D'Aprano did opine:

> On Sat, 20 Oct 2012 14:18:47 +0000, Grant Edwards wrote:
> > On 2012-10-20, Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote:
> >> 	Strangely, we've gone from 80-character fixed width displays to
> >> 
> >> who-knows-what (if I drop my font size I can probably get nearly 200
> >> characters across in full-screen mode)...
> >> 
> >> 	But at the same time we've gone from 132-character line-printers
> >> 
> >> using fan-fold 11x17 pages, to office inkjet/laser printers using
> >> 8.5x11 paper, defaulting to portrait orientation -- with a 10
> >> character/inch font, and 1/4" left/right margins, we're back to 80
> >> character limitation
> >>
> >><G>
> >>
> > True, but nobody prints source code out on paper do they?
> 
> I do.
> 
> There's nothing better than spreading out a dozen sheets of source code
> over a table to get a good, high-level overview of what does what in
> preparation to refactoring it.
> 
> > Seriously -- I can't remember the last time I printed souce code...
> 
> I've never printed souce code either *wink*

So do I, but I often am looking at assembler listings with the assembler 
set for 132 chars a line to preserve the src codes comments, so lp gets a 
use 17 cpi option on the cli that makes the listing.  I probably recycle 2 
reams of paper a year doing exactly that.  Those who won't take advantage 
of that are doomed to publish buggy code.

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page: <http://coyoteden.dyndns-free.com:85/gene> is up!
Not all men who drink are poets.  Some of us drink because we aren't poets.

[toc] | [prev] | [next] | [standalone]

#31853

On Sun, 21 Oct 2012 20:20:41 +1100, Chris Angelico <rosuav@gmail.com>
declaimed the following in gmane.comp.python.general:


> So what you actually mean is that there's nothing _like_ spreading out
> &c &c. I should think that throwing cold water over the code would be
> better.
>
	Only if it's mongrelizing with PERL
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#31851

On 20/10/12 15:18, Grant Edwards wrote:
> On 2012-10-20, Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote:
>
>> 	Strangely, we've gone from 80-character fixed width displays to
>> who-knows-what (if I drop my font size I can probably get nearly 200
>> characters across in full-screen mode)...
>>
>> 	But at the same time we've gone from 132-character line-printers
>> using fan-fold 11x17 pages, to office inkjet/laser printers using 8.5x11
>> paper, defaulting to portrait orientation -- with a 10 character/inch
>> font, and 1/4" left/right margins, we're back to 80 character limitation
>> <G>
>
> True, but nobody prints source code out on paper do they?

I print source code. Usually when the development has got to a stage 
that the program works but needs a lot of tidying up. It's a lot more 
comfortable than scrolling up and down screen to look through pages from 
the comfort of an armchair. Also I can take the listing to a Café and 
write notes all over it. Sometimes removing the temptation to 
immediately hit the keyboard is a good thing.

[toc] | [prev] | [next] | [standalone]

#31791

On 10/19/12 17:14, Steven D'Aprano wrote:
> Code never *needs* to be long, because it can always be shortened.

I advocate one bit per line:

1
0
1
0
0
1
0
1
1
0
0
1
0
1
1
1
0
0
0
0
1
1
1
0
1
1
0
0
1
1
0
1
1
0
0
1
1
1
1
0
0
1
1
1
1
1
1
1

«grins, ducks, and flees»

Shortenedly-yers,

-tkc

[toc] | [prev] | [next] | [standalone]

#31798

On Oct 20, 8:27 am, Tim Chase <python.l...@tim.thechases.com> wrote:
> On 10/19/12 17:14, Steven D'Aprano wrote:
>
> > Code never *needs* to be long, because it can always be shortened.
>
> I advocate one bit per line:
>
> 1
> 0
> 1
> 0
> 0
> 1
> 0
> 1
> 1
> 0
> 0
> 1
> 0
> 1
> 1
> 1
> 0
> 0
> 0
> 0
> 1
> 1
> 1
> 0
> 1
> 1
> 0
> 0
> 1
> 1
> 0
> 1
> 1
> 0
> 0
> 1
> 1
> 1
> 1
> 0
> 0
> 1
> 1
> 1
> 1
> 1
> 1
> 1
>
> «grins, ducks, and flees»
>
> Shortenedly-yers,
>
> -tkc

T
H
A
N
K
S

T
I
M
(for the sanity)

[toc] | [prev] | [next] | [standalone]

#31821

In article <5081d0c3$0$30003$c3e8da3$5496439d@news.astraweb.com>,
 Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:

> Some code might be more conveniently written as a single long line. But I 
> would argue that nearly never is code more easily *read* as a single long 
> line, and since code is read much more than it is written, it is more 
> important to optimise for reading, not writing.

Like many people here, I don't worry much about the 80 column limit.  I 
make my lines of code as long as they have to be, and no longer.  If 
there's some obvious and easy way to fold the statement onto multiple 
lines, I'll do it.  If not, I won't.

This tends to result in lines that are less than 80 characters, but if 
not, I don't worry about it (assuming I'm even aware of it).

I just did a little experiment.  I took about 20 KLOC of python that was 
largely written by me and make a histogram of the line lengths 
(http://www.panix.com/~roy/length.pdf).  Just by eye, I'd say "most are 
less than 80, almost all are less than 100".  I'd guess the average of 
all non-empty lines is about 45 or so.  The longest line is 273 
characters:

             sys.stderr.write("Error: Can't find the file 'settings.py' 
in the directory containing %r.\nYou'll have to run django-profile.py, 
passing it your settings module.\n(If the file settings.py does indeed 
exist, it's causing an ImportError somehow.)\n" % __file__)

Would that have been better rewritten broken up into several shorter 
lines?  Absolutely.  Such is life.

PS: I didn't write that line :-)

[toc] | [prev] | [next] | [standalone]

#31865

On Sat, 20 Oct 2012 16:37:23 -0400, Roy Smith wrote:

>              sys.stderr.write("Error: Can't find the file 'settings.py'
> in the directory containing %r.\nYou'll have to run django-profile.py,
> passing it your settings module.\n(If the file settings.py does indeed
> exist, it's causing an ImportError somehow.)\n" % __file__)

textwrap.dedent?

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.python

csiph-web