Op donderdag 23-04-2009 om 05:53 uur [tijdzone -0700], schreef Aahz:

How do non-keyword builtins bite?

You can accidentally "re-define" or mask them (if you don't use a tool that warns for that). -- Jan Claeys

Le Sat, 2 May 2009 15:57:35 -0700, Aahz s'exprima ainsi:

...

...

How do non-keyword builtins bite?

You can accidentally "re-define" or mask them (if you don't use a tool that warns for that).

Given how long it has been since the original post, I think it's unfair of you to cut this much context.

Sorry for this.

What Denis Spir originally wrote was, "On the contrary: non-keyword builtins bite painfully!" and my rejoinder was written because of the extreme language.

Still, Jan's reply is the right issue I had in mind.

Your issue is a valid one, but I have seen no cases where I would call it "painful" contrasted with the pain of being unable to use a keyword anywhere as a name or attribute.

Depends on your pov. I consider the _possibility_ of using 'list', 'range' or 'type' as a name for totally custom thing, without even a warning, an issue, not a wishable feature. It _invents_ very hard to diagnose bugs. Painful they are. I cannot even figure out a debugging process that would point to the real source of the problem -- except for a sudden "eureka". Actually, the issue is that precisely the non-protected build-in words are those so obvious variable names for data or funcs. I have (painfully) learnt a reflex to use 'ranj' for range, 'Seq' for list, 'typ' for type, etc... But maybe its me and I'm the only one ;-) [There is an (unsatisfying) solution with some editors: just add all those word to the keyword set so that they will jump at your eyes when you pretend use them... But they also look like keywords when safely used as attributes. I would prefere a python warning mode switch.] Strangely enough, I cannot imagine a use case for 'for' or 'in' or 'while' as names. while these ones are protected (indeed, I don't mean they shouldn't). Denis ------ la vita e estrany

On Sun, 3 May 2009 12:28:47 pm Adam Atlas wrote:

Isn't the convention to suffix a name with an underscore when it would clash with a builtin? (range_, list_, type_, etc.)

That's one convention. Another is to name things alist, atype, astr,. etc. If you need two of them, the obvious extension is blist, btype... When writing *small* generic methods or functions, I'm also fond of using L for list, x and y for floats, n or i for ints, and similar. This needs to be handled with care, for obvious reasons.

I'm not sure how much I like that stylistically, but I've seen it used a lot. (I think in some cases there are better alternatives -- e.g. instead of naming a variable "seq" or "list_", I'd have the name specify what it's a list *of*.)

Well, this is Python, and we use duck-typing, so everything would need to be list_of_string_like_instances or similar :) But seriously, I tend to use plurals for that. If I have an argument that takes a collection of widgets, say, I call it "widgets", and write code like this: for widget in widgets: whatever() I don't think there's much to be gained by calling it "list_of_widgets" unless it really needs to be a list, and not any other collection type. -- Steven D'Aprano

spir writes:

Depends on your pov. I consider the _possibility_ of using 'list', 'range' or 'type' as a name for totally custom thing, without even a warning, an issue, not a wishable feature. It _invents_ very hard to diagnose bugs.

If you want warnings, use pylint. It catches all of those. On the other hand, Python's even-handed treatment of builtins, standard library identifiers, and user-defined identifiers makes for a great simplification in the rules for the language, and allows for introspective usage: # Here's something you can do for fun on a lazy Sunday afternoon. the_artist_formerly_known_as_list = list def list(thing): print "Somebody called list!" return the_artist_formerly_known_as_list(thing) For most of us, the gain in simplicity and power is well worth the pain.

Strangely enough, I cannot imagine a use case for 'for' or 'in' or 'while' as names. while these ones are protected (indeed, I don't mean they shouldn't).

Dunno about the other two, but in C I used to use the equivalent of in = open("mind", "r") text = in.readlines() all the time.

On Mon, May 04, 2009, John Graham wrote:

Has anyone ever suggested a standard pylint, something that might be distributed with the interpreter/libraries? As important as the 'look-and-feel' is to Python, it seems like an automated style-checker / 'you probably didn't meant to do that' engine would be a good idea to introduce even newbies to the language instead of them having to search it out.

It's been mentioned; I don't remember why it never got any traction, whether because the authors didn't want to deal with it or nobody bothered submitting a PEP (this definitely needs a PEP). -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "It is easier to optimize correct code than to correct optimized code." --Bill Harlan

On Mon, May 04, 2009, CTO wrote:

...

It's been mentioned; I don't remember why it never got any traction, whether because the authors didn't want to deal with it or nobody bothered submitting a PEP (this definitely needs a PEP).

I'll volunteer to put one together if somebody's willing to walk me through the PEP process.

Um, I think you trimmed too much of the quote -- what are you talking about? -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "It is easier to optimize correct code than to correct optimized code." --Bill Harlan

On Mon, May 04, 2009, CTO wrote:

Aahz:

...

On Mon, May 04, 2009, John Graham wrote:

...

Has anyone ever suggested a standard pylint, something that might be distributed with the interpreter/libraries? As important as the 'look-and-feel' is to Python, it seems like an automated style-checker / 'you probably didn't meant to do that' engine would be a good idea to introduce even newbies to the language instead of them having to search it out.

It's been mentioned; I don't remember why it never got any traction, whether because the authors didn't want to deal with it or nobody bothered submitting a PEP (this definitely needs a PEP).

I'll volunteer to put one together if somebody's willing to walk me through the PEP process.

Sure! I suggest that you start by checking with the maintainers of pychecker and pylint to find out how they feel about it. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "It is easier to optimize correct code than to correct optimized code." --Bill Harlan

On Mon, May 4, 2009 at 7:25 PM, Chris Rebert wrote:

On Mon, May 4, 2009 at 4:15 PM, Aahz wrote:

...

On Mon, May 04, 2009, CTO wrote:

...

Aahz:

...

On Mon, May 04, 2009, John Graham wrote:

...

Has anyone ever suggested a standard pylint, something that might be distributed with the interpreter/libraries?  As important as the

Wouldn't it be be better placed in the Tools/ directory rather than as part of the stdlib?

Cheers, Chris -- http://blog.rebertia.com _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

Touche', salesman. -Jg

Aahz wrote:

On Mon, May 04, 2009, Chris Rebert wrote:

...

...

...

...

...

Has anyone ever suggested a standard pylint, something that might be distributed with the interpreter/libraries? ?As important as the Wouldn't it be be better placed in the Tools/ directory rather than as

On Mon, May 04, 2009, John Graham wrote: part of the stdlib?

Perhaps, but I don't think so -- you need a source tree to get Tools/ AFAIK, and if some form of lint gets blessed by incorporation into Python, then it needs to be available for all standard installs.

Regardless, the stdlib is for modules to import, tools for programs that run.

Nick Coghlan wrote:

Terry Reedy wrote:

...

Aahz wrote:

...

On Mon, May 04, 2009, Chris Rebert wrote:

...

...

...

> On Mon, May 04, 2009, John Graham wrote: >> Has anyone ever suggested a standard pylint, something that might be >> distributed with the interpreter/libraries? ?As important as the Wouldn't it be be better placed in the Tools/ directory rather than as part of the stdlib? Perhaps, but I don't think so -- you need a source tree to get Tools/

My standard Windows 3.0.1 installation has Tools without the source tree. It has 5 directories, including Scripts/, which has about 50 .py files, including 2to3. If *that* can go there, I see no reason why a syntax checker could not also.

...

...

AFAIK, and if some form of lint gets blessed by incorporation into Python, then it needs to be available for all standard installs. Regardless, the stdlib is for modules to import, tools for programs that run.

We blur that line all the time though (cf. timeit, pdb, pydoc, webbrowser, runpy, probably others).

So I'd agree with Aahz that if python-dev is going to bless something along these lines, it should be something worthy of inclusion in the standard lib itself rather than just being dropped into the Tools directory.

timit, pdb, webbrowser, amd runpy are importable modules that *also* have a command-line interface via "if __name__ == '__main__': ...". Pydoc might be also, but I could not be sure from the doc. If the checker were written similarly, so that it could be imported and used from within a program to check another file, then I would agree that stdlib would be a place for it. tjr

CTO writes:

Skipping over some of the wrangling about where it goes for a minute, is there any firm consensus on which tool to put in? I've only heard back from pylint, and there seems to be a general feeling that that's the strictest (and therefore best), but that its external dependencies constitute a liability. Does anybody have a firm objection on that score?

Not a firm objection: pylint is also the most complex (AFAICT). Perhaps a simpler one that still does a good job would be best for stdlib consideration. -- \ “To save the world requires faith and courage: faith in reason, | `\ and courage to proclaim what reason shows to be true.” | _o__) —Bertrand Russell | Ben Finney

On Wed, May 6, 2009 at 8:50 AM, Jesse Noller wrote:

On Wed, May 6, 2009 at 3:14 AM, Ben Finney wrote:

...

CTO writes:

...

Skipping over some of the wrangling about where it goes for a minute, is there any firm consensus on which tool to put in? I've only heard back from pylint, and there seems to be a general feeling that that's the strictest (and therefore best), but that its external dependencies constitute a liability. Does anybody have a firm objection on that score?

Not a firm objection: pylint is also the most complex (AFAICT). Perhaps a simpler one that still does a good job would be best for stdlib consideration.

+1, something which does simple linting, and pep 8 checking would be a big enough benefit over what we have now. Ideally, it would support extensibility for additional rules.

I don't see much value in building a new lint tool. I might like it if pylint were less complex than it is, but I don't understand the design fully enough to have justification for that. If we can get a good PEP 8 checker out of pylint, it would be silly to write something from scratch. We went through a similar exercise at work two summers ago and concluded that we'd it would be faster to build on pylint than to write something from scratch. I don't think there are any special considerations for python stdlib development that would lead me to reach a different conclusion. Certainly, it would be convenient if the lint tool was part of the source tree, but our editors, compilers, debuggers, and source control tools aren't part of the source tree either. I don't think the desire to put it in tools or stdlib outweighs the cost of building and maintaining a new tool when a perfectly good one already exists. Jeremy

Should we give another look to something like pep8.py, then? Less complex, certainly, no dependencies and it runs cleanly under python3 after running it through 2to3. On the minus side, it is *much* less rigorous.

Geremy Condra

I've also just heard back from the maintainer of pyflakes, and he seems pretty happy with the idea. Here's the email: Geremy, I maintain Pyflakes and am an employee of the company responsible for its development. I think it's a good idea; Pyflakes is definitely an important part of my development process. There are pretty diverse opinions about how thorough and punctilious Python code checkers should try to be, so there are a bunch of relatively popular programs with vaguely similar functionality. I'm a fan of Pyflakes in particular because it's quick, passive and not overly ambitious or presumptious. Let me know how things work out. Take care, Moe So, are there any particular objections to pyflakes? Does anybody have a strong preference for pylint, pep8.py, or pychecker over pyflakes? Geremy Condra

Jeremy Hylton writes:

On Wed, May 6, 2009 at 8:50 AM, Jesse Noller wrote:

...

On Wed, May 6, 2009 at 3:14 AM, Ben Finney wrote:

...

Not a firm objection: pylint is also the most complex (AFAICT). Perhaps a simpler one that still does a good job would be best for stdlib consideration.

+1, something which does simple linting, and pep 8 checking would be a big enough benefit over what we have now. Ideally, it would support extensibility for additional rules.

I don't see much value in building a new lint tool. I might like it if pylint were less complex than it is, but I don't understand the design fully enough to have justification for that. If we can get a good PEP 8 checker out of pylint, it would be silly to write something from scratch.

AFAIK, nobody is suggesting writing one from scratch; earlier in this thread we explored the fact that there are several already written and working. -- \ “Always code as if the guy who ends up maintaining your code | `\ will be a violent psychopath who knows where you live.” —John | _o__) F. Woods | Ben Finney

On May 4, 8:57 pm, Ben Finney wrote:

Aahz writes:

...

...

...

On Mon, May 04, 2009, John Graham wrote:

...

Has anyone ever suggested a standard pylint, something that might be distributed with the interpreter/libraries? As important as the 'look-and-feel' is to Python, it seems like an automated style-checker / 'you probably didn't meant to do that' engine would be a good idea to introduce even newbies to the language instead of them having to search it out.

...

Sure!  I suggest that you start by checking with the maintainers of pychecker and pylint to find out how they feel about it.

The popularity of ‘pyflakes’ suggests it would be good to coordinate with that project too. URL:http://divmod.org/trac/wiki/DivmodPyflakes URL:http://github.com/kevinw/pyflakes/

I've sent emails to pylint, pychecker, pyflakes, and pep8.py. We'll see what comes out of that, but if anybody is aware of any alternative emails for any of the above, I should probably send something to those too- the one for pylint in particular doesn't look like it's been checked in a while. Geremy Condra

On Tue, May 5, 2009 at 5:29 AM, Michael Foord wrote:

2009/5/5 Aahz

...

On Mon, May 04, 2009, CTO wrote:

...

Aahz:

...

On Mon, May 04, 2009, John Graham wrote:

...

Has anyone ever suggested a standard pylint, something that might be distributed with the interpreter/libraries?  As important as the 'look-and-feel' is to Python, it seems like an automated style-checker / 'you probably didn't meant to do that' engine would be a good idea to introduce even newbies to the language instead of them having to search it out.

It's been mentioned; I don't remember why it never got any traction, whether because the authors didn't want to deal with it or nobody bothered submitting a PEP (this definitely needs a PEP).

I'll volunteer to put one together if somebody's willing to walk me through the PEP process.

Sure!  I suggest that you start by checking with the maintainers of pychecker and pylint to find out how they feel about it.

PyLint is huge and depends on a whole ream of support libraries. I think the logilab guys would probably rather maintain it themselves and I'm not sure it is really suitable for the standard library anyway.

We use pylint at work for our own lint tool. It's been useful to us. I'm not sure that I see much value in adding it or something like it to the standard distribution. If there is a good lint tool that supports PEP 8 and is available for download, I expect most python developers would install it. Jeremy

PyFlakes and PyChecker are both very good; although neither does as much as PyLint. I'm not sure if either of the two does enough to enforce full PEP-8 compliance.

Michael Foord

...

-- Aahz (aahz@pythoncraft.com)           <*> http://www.pythoncraft.com/

"It is easier to optimize correct code than to correct optimized code." --Bill Harlan _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

-- http://www.ironpythoninaction.com/

_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

On Sun, 3 May 2009 07:35:29 am Jan Claeys wrote:

Op donderdag 23-04-2009 om 05:53 uur [tijdzone -0700], schreef Aahz:

...

How do non-keyword builtins bite?

You can accidentally "re-define" or mask them (if you don't use a tool that warns for that).

Cross out "accidentally", and the ability to shadow built-ins is a feature, not a bug. Anything that you do accidentally is a problem. You can accidentally shadow a module, or one of your own functions or names. And while Python has a rich set of built-ins, it isn't so many that learning them is a burden. I would expect that the average newbie would accidentally shadow a built-in once or twice, then never do it again. (Especially if they hang around comp.lang.python and get yelled at every time they do it.) -- Steven D'Aprano

Greg Ewing writes:

Since we place a high value on not breaking existing code, we are naturally reluctant to add new keywords.

This also works in the opposite direction. Despite all the natural barriers to adding a new keyword, it is still far easier to add a new keyword than to *remove* one from the language if it later turns out to be problematic: some portion of working code will be thereby broken, which is much more likely than the breakage caused by adding it in the first place. Hance, since it's far more difficult to go back (from complex to simple), there must be great burden of proof for the benefit in moving from simple to complex. -- \ “Two hands working can do more than a thousand clasped in | `\ prayer.” —Anonymous | _o__) | Ben Finney