Re: Is PEP-8 a Code or More of a Guideline?
Carl Banks [EMAIL PROTECTED] writes: Identifiers should just allow spaces. first element.get item(selected value) This is not a joke. It would be a hideous pain to read though. My decades of schooling have carved channels in my brain that recognise the space as a *separator* for lexical elements, and any non-space separator as being lower down the hierarchy. The parentheses just look awkward, but the period is *definitely* joining tokens together whereas the spaces separate them. Thus, the example you give parses as the tokens first, element.get, item, selected, value. I don't see any language with the characteristics you describe being at all useful until the major natural language of programmers ceases to use spaces this way. -- \ First they came for the verbs, and I said nothing, for verbing | `\weirds language. Then, they arrival for the nouns and I speech | _o__)nothing, for I no verbs. -- Peter Ellis | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Is PEP-8 a Code or More of a Guideline?
Joe Riopel [EMAIL PROTECTED] writes: Using camel case instead of the under_score means less typing. I am lazy. Using camelCase instead of lower_case means harder reading. I am lazy. Remember: a program is read by humans much more often than it is written. -- \ If you saw two guys named Hambone and Flippy, which one would | `\ you think liked dolphins the most? I'd say Flippy, wouldn't | _o__) you? You'd be wrong, though. It's Hambone. -- Jack Handey | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Is PEP-8 a Code or More of a Guideline?
Tim Roberts [EMAIL PROTECTED] wrote: Carl Banks [EMAIL PROTECTED] wrote: Identifiers should just allow spaces. first element.get item(selected value) This is not a joke. I don't mean Python should necessarily do this (though it could be done without any ambiguity or backward incompatibility: there is currently nowhere in Python where two identifiers can be separated by only a space), but new languages should be designed to allow it. That's an interesting idea. It would, perhaps, allow you to write programs that read more like prose. However, it would certainly make the parser more complicated, because it could no longer be context-insensitive. For example, if I had identifiers called mine and not mine, how would it parse this: if not mine: The rules would have to change - currently you cannot use a reserved word (or keyword) as an identifier. It would have to be legislated that you cannot use a keyword as part of a space linked identifier - this should not be a train smash to implement, and if it makes it easier for people with disabilities, its probably not too much to ask. Hey, it could lead to self documenting code such as: That which will be returned = [] for The current element from the iterator in My iterable thingy: My temporary variable called x = The current element from the iterator if My temporary variable called x == None: break else: Temporary variable = Complicated function(My temporary variable called x) That which will be returned.append(Temporary variable) and so forth - kind of verbose, but clear... Note that I have also just invented a rule - I shall call it The German Noun Copycat Readability Style and Parser Simplification Capitalisation Rule for short. It reads: Space linked identifiers must start with a capital letter. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Is PEP-8 a Code or More of a Guideline?
projecktzero [EMAIL PROTECTED] wrote: On May 30, 12:36 am, Hendrik van Rooyen [EMAIL PROTECTED] wrote: Maric Michaud [EMAIL PROTECTED] wrote: Typist is fine, although MCP that I am, I tend to think of typist as female... - Hendrik What does being a Microsoft Certified Professional(MCP) have to do with thinking of a typist as female? =) Yikes! - Male Chauvinist Pig... ;-) - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Is PEP-8 a Code or More of a Guideline?
Joe Riopel [EMAIL PROTECTED] writes: Using camel case instead of the under_score means less typing. I am lazy. fooBar foo_bar Each requires exactly the same number of key strokes when I do the math. (Too lazy to explain further...) -- http://mail.python.org/mailman/listinfo/python-list
Re: Is PEP-8 a Code or More of a Guideline?
Each requires exactly the same number of key strokes when I do the math. (Too lazy to explain further...) foo_bar f, o, o, shift + underscore, b, a, r = 8 fooBar f, o, o, shift + b, a, r = 7 -- http://mail.python.org/mailman/listinfo/python-list
Re: Is PEP-8 a Code or More of a Guideline?
In [EMAIL PROTECTED], kc wrote: Joe Riopel [EMAIL PROTECTED] writes: Using camel case instead of the under_score means less typing. I am lazy. fooBar foo_bar Each requires exactly the same number of key strokes when I do the math. (Too lazy to explain further...) Let's leave 'foo' and 'ar': 1. B = Shift + B = 2 key strokes. 2. _b = Shift + - and b = 3 key strokes. At least on my keyboard + layout. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: Is PEP-8 a Code or More of a Guideline?
Joe Riopel a écrit : Each requires exactly the same number of key strokes when I do the math. (Too lazy to explain further...) foo_bar f, o, o, shift + underscore, b, a, r = 8 fooBar f, o, o, shift + b, a, r = 7 f, o, o, _, b, a, r = 7 f, o, o, shift + b, a, r = 8 Also the shift+b is much more work than 2 keypresses IMHO. On the other hand, the underscore is done by pressing the 8 key without any other modifier which is very easy and accessible. Yeap, french layout rules for that naming convention :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Is PEP-8 a Code or More of a Guideline?
[EMAIL PROTECTED] wrote: FWIW, even though I think proper-case-with-seperators is greatly preferrable to camelCase, I certainly don't think that speaking the names is a really major point. unless you or someone with working hands helps fix up voicecoder, it is a major point for people like me. http://voicecode.iit.nrc.ca/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Is PEP-8 a Code or More of a Guideline?
On Wed, 30 May 2007 20:41:32 -0600, Frank Swarbrick [EMAIL PROTECTED] wrote: Tim Roberts wrote: Frank Swarbrick [EMAIL PROTECTED] wrote: Then you'd really love COBOL! :-) Frank COBOL programmer for 10+ years Hey, did you hear about the object-oriented version of COBOL? They call it ADD ONE TO COBOL. I know you were joking, but the COBOL 2002 standard implements OO. It's OK, but quite obviously bolted on. Exactly the same situation as the OO in C++... -- http://mail.python.org/mailman/listinfo/python-list
RE: Is PEP-8 a Code or More of a Guideline?
Perhaps a foot pedal? Hmmm My two cellphones don't like underbars very much. And the shift key -- while much easier -- still is cumbersome. If outlook didn't autocaps on me, this message would be in all lowercase. In fact, when communicating with friends from outlook, to their sms, I take the trouble to correct my outlook's autocorrect. underbars are more of a reach and harder to read when you use a really nice font. camelBack -- damn, I just had to correct outlook's autocorrect on camelback -- so, what was I saying, oh yes -- camelBackNames are just freaking weird. So i.prefer.dots-- no, seriously sure it's slow, but forces you the think about names in a new way. or, perhaps going deep is sacrilege? -Original Message- From: [EMAIL PROTECTED] [mailto:python-list- [EMAIL PROTECTED] On Behalf Of Christophe Sent: Thursday, May 31, 2007 6:18 AM To: python-list@python.org Subject: Re: Is PEP-8 a Code or More of a Guideline? Joe Riopel a écrit : Each requires exactly the same number of key strokes when I do the math. (Too lazy to explain further...) foo_bar f, o, o, shift + underscore, b, a, r = 8 fooBar f, o, o, shift + b, a, r = 7 f, o, o, _, b, a, r = 7f, o, o, shift + b, a, r = 8 Also the shift+b is much more work than 2 keypresses IMHO. On the other hand, the underscore is done by pressing the 8 key without any other modifier which is very easy and accessible. Yeap, french layout rules for that naming convention :)-- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Is PEP-8 a Code or More of a Guideline?
Warren Stringer wrote: i.prefer.dots-- no, seriously sure it's slow, but forces you the think about names in a new way. Are you now suggesting that addinfourl() should actually be called url(), placed in a module named info, which is part of a package called add, so as to enable you to call add.info.url()? May I assume it wouldn't bother you having millions of packages containing only one module each (plus their __init__.py's) where the modules only provide around one function. OK, go ahead. Modify the whole Python-library to conform to that style and then send us the bill from your psychiatrist. This may be a nice idea for the Next Overwhelming Programming Escapade (Codename: NOPE), but you can just forget about it in Python. Excuse my mocking, but while typing dots is far easier for US and German keyboards, this may be a whole different story for any other layout (I forget how it goes with the french layout; shift for the dot or the comma?). Back to the drawing boards! ;) /W PS You may want to elaborate on the new way to think about names. Maybe you have a point which I just don't see. -- http://mail.python.org/mailman/listinfo/python-list
RE: Is PEP-8 a Code or More of a Guideline?
Wildemar Wildenburger wrote:
This may be a nice
idea for the Next Overwhelming Programming Escapade (Codename: NOPE)
...
You may want to elaborate on the new way to think about names. Maybe
you have a point which I just don't see.
Is it considered pythonic to LOL?
Nietzsche would love NOPE ... and so would his psychiatrist.
Nope, I'm proposing: Yo! Extend that Python (Codename: YEP)
I'm treating classes as nested dictionaries. Not *all* classes; only the
ones that I want to use and code from a cell phone.
I've been porting a scripting language, that was written in C++ to Python.
It allows declare a structure like this:
mouse
position x,y
button
left x,y
right x,y
and pipe the whole tree to a recorder, like this:
record mouse//
which is like doing this:
record [mouse.position.x,
mouse.position.y,
mouse.button.left.x,
mouse.button.left.y,
mouse.button.right.y,
mouse.button.right.y]
So, how is this related to the addinfourl example? It isn't. At least, not
for rewriting old API. But for fresh APIs, add.info.url() forces you to
think about names, and functionality in a fine grained way. This translates
roughly to:
class add(object)...
class info(object)...
class url(object)...
or as a dict:
{'add' : { 'info': 'url' { ...
Then it becomes easier to think about decorators, generators, and closures
in a way that is quite amorphous. (Though slow?)
Tschüs,
\~/
--
http://mail.python.org/mailman/listinfo/python-list
Re: Is PEP-8 a Code or More of a Guideline?
Carl Banks [EMAIL PROTECTED] wrote: Identifiers should just allow spaces. first element.get item(selected value) This is not a joke. I don't mean Python should necessarily do this (though it could be done without any ambiguity or backward incompatibility: there is currently nowhere in Python where two identifiers can be separated by only a space), but new languages should be designed to allow it. That's an interesting idea. It would, perhaps, allow you to write programs that read more like prose. However, it would certainly make the parser more complicated, because it could no longer be context-insensitive. For example, if I had identifiers called mine and not mine, how would it parse this: if not mine: -- Tim Roberts, [EMAIL PROTECTED] Providenza Boekelheide, Inc. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is PEP-8 a Code or More of a Guideline?
Frank Swarbrick [EMAIL PROTECTED] wrote: Then you'd really love COBOL! :-) Frank COBOL programmer for 10+ years Hey, did you hear about the object-oriented version of COBOL? They call it ADD ONE TO COBOL. -- Tim Roberts, [EMAIL PROTECTED] Providenza Boekelheide, Inc. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is PEP-8 a Code or More of a Guideline?
Maric Michaud [EMAIL PROTECTED] wrote: Is typist ok ? It's the google's translation for dactylo. Typist is fine, although MCP that I am, I tend to think of typist as female... I would call a male one a typer, but I dont think it is correct English. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Is PEP-8 a Code or More of a Guideline?
+1 QOTW On Wed, 30 May 2007 06:18:36 GMT, Tim Roberts [EMAIL PROTECTED] wrote: Frank Swarbrick [EMAIL PROTECTED] wrote: Then you'd really love COBOL! :-) Frank COBOL programmer for 10+ years Hey, did you hear about the object-oriented version of COBOL? They call it ADD ONE TO COBOL. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is PEP-8 a Code or More of a Guideline?
John DeRosa wrote: +1 QOTW Hey, did you hear about the object-oriented version of COBOL? They call it ADD ONE TO COBOL. actually it is ADD 1 TO COBOL GIVING COBOL http://en.wikipedia.org/wiki/COBOL#Aphorisms_and_humor_about_COBOL -- http://mail.python.org/mailman/listinfo/python-list
Re: Is PEP-8 a Code or More of a Guideline?
Using camel case instead of the under_score means less typing. I am lazy. fooBar foo_bar -- http://mail.python.org/mailman/listinfo/python-list
Re: Is PEP-8 a Code or More of a Guideline?
On May 30, 12:36 am, Hendrik van Rooyen [EMAIL PROTECTED] wrote: Maric Michaud [EMAIL PROTECTED] wrote: Typist is fine, although MCP that I am, I tend to think of typist as female... - Hendrik What does being a Microsoft Certified Professional(MCP) have to do with thinking of a typist as female? =) -- http://mail.python.org/mailman/listinfo/python-list
Re: Is PEP-8 a Code or More of a Guideline?
Joe Riopel wrote: Using camel case instead of the under_score means less typing. I am lazy. fooBar foo_bar camel case makes source code extremely ugly in weird disturbing way YMMV -- http://mail.python.org/mailman/listinfo/python-list
Re: Is PEP-8 a Code or More of a Guideline?
Steven Bethard [EMAIL PROTECTED] writes: John J. Lee wrote: [...] Even as a native English speaker, some of these are tricky -- e.g. urllib has a private class named addinfourl. What's this 'fourl' we're adding in? (In fact, the method adds attributes named info and url. Even though I've read that name hundreds of times, my brain always insists on reading it add in fourl.) This is the worst of both worlds: inconsistent and hard to understand. Sounds like a good candidate for a rename in Python 3000. The point was the general issue, not the particular case. The problems associated with this naming style do not go away when bad cases like addinfourl go away: 1. Other runtogether names are less tricky than addinfourl, but the issue is still there. These names (e.g. getitem) are considered good Python standard library style. This particular point involves a trade-off and is debatable, I accept. More important, and less debatable: 2. The runtogether style makes *many* names hard to remember because of the runtogether / kept_apart choice. 3. The style introduces tiresome inconsistency in naming decisions. John -- http://mail.python.org/mailman/listinfo/python-list
Re: Is PEP-8 a Code or More of a Guideline?
Apologies for jumping into the thread late.
On May 27, 3:25 pm, Roy Smith [EMAIL PROTECTED] wrote:
Ben Finney [EMAIL PROTECTED] wrote:
Is C no longer a major language? The long-standing convention there
is for lower_case_with_underscores.
Which dates back to the days of ASR-33's which only had one case (upper
The date is about right (actually, a little early: ASR-33, 1965; C,
about 1970), but you can't program C on an ASR-33. Keywords are all
lower case, and always have been. IF is a syntax error...
case, as a matter of fact). Does nobody else remember C compilers which
accepted \( and \) for { and }?
I don't, but modern conforming compilers are supposed to accept ?? or
% for { and ?? or % for }. Makes it awful hard to read, though,
IMHO.
Regards,
-=Dave
P.S. CamelCase sucks. ;-)
--
http://mail.python.org/mailman/listinfo/python-list
Re: Is PEP-8 a Code or More of a Guideline?
On May 26, 11:36 pm, Paul McGuire [EMAIL PROTECTED] wrote: Steve, sorry for taking your thread down a rathole. I hope we can move any further PEP-8-related discussion (if the point merits any) to this thread. Identifiers should just allow spaces. first element.get item(selected value) This is not a joke. I don't mean Python should necessarily do this (though it could be done without any ambiguity or backward incompatibility: there is currently nowhere in Python where two identifiers can be separated by only a space), but new languages should be designed to allow it. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: Is PEP-8 a Code or More of a Guideline?
Tim Roberts wrote: Frank Swarbrick [EMAIL PROTECTED] wrote: Then you'd really love COBOL! :-) Frank COBOL programmer for 10+ years Hey, did you hear about the object-oriented version of COBOL? They call it ADD ONE TO COBOL. I know you were joking, but the COBOL 2002 standard implements OO. It's OK, but quite obviously bolted on. Frank Python programmer for 3+ days -- http://mail.python.org/mailman/listinfo/python-list
Re: Is PEP-8 a Code or More of a Guideline?
Dave Hansen [EMAIL PROTECTED] wrote: On May 27, 3:25 pm, Roy Smith [EMAIL PROTECTED] wrote: Ben Finney [EMAIL PROTECTED] wrote: Is C no longer a major language? The long-standing convention there is for lower_case_with_underscores. Which dates back to the days of ASR-33's which only had one case (upper The date is about right (actually, a little early: ASR-33, 1965; C, about 1970), but you can't program C on an ASR-33. Damn, I wish I had known that at the time :-) Keywords are all lower case, and always have been. IF is a syntax error... I doubt it still works on anything made today, but back in those days, if you typed your login name in all upper case, the terminal was put into lcase mode. Upper case on input was automatically converted to lower case. You typed IF, the C compiler saw if, and it all worked. Including \( and \) for curly braces. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is PEP-8 a Code or More of a Guideline?
Dave Hansen wrote: The date is about right (actually, a little early: ASR-33, 1965; C, about 1970), but you can't program C on an ASR-33. Keywords are all lower case, and always have been. IF is a syntax error... But the Unix terminal drivers of the day for upper case only terminals translated to lower case and you had to enter \A to get an upper case A, and so on. Still hangs around in the stty options iuclc, -iuclc, olcuc and -olcuc - You can make an x-term window look like an old upper case only terminal. I don't know if any still do it, but old unices used to detect on logon if you typed your user name and password in all caps and then turned on the iuclc and olcuc options, assuming that the reason for the all caps was a upper case only terminal - great fun if you hit caps lock by accident. Charles -- http://mail.python.org/mailman/listinfo/python-list
Re: Is PEP-8 a Code or More of a Guideline?
On 5/29/07, Eric S. Johansson [EMAIL PROTECTED] wrote: A huge reason why this is important because the vast majority of software developers who are injured fall off the economic ladder. They leave the profession and had very few options for work that doesn't involve significant handy is. The last time I looked at the numbers, in the US somewhere north of 60,000 developers per year are injured. Some recover (kind of). Others, like I I'm curious, where did you get that statistic? Assuming the US hosts no more than 6M developers, then 60,000 is =1% which is an alarming amount. -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: Is PEP-8 a Code or More of a Guideline?
--- Carsten Haese [EMAIL PROTECTED] wrote: On Sun, 2007-05-27 at 07:30 +, OKB (not okblacke) wrote: Underscores are harder to type than any alphanumeric character. This is a discussion about underscores versus capital letters denoting the word boundaries in identifiers. How is an underscore harder to type than a capital letter? longer reach with the pinkie on American keyboards Slowly type the following two keywords, you'll see what I mean: hop_count hopCount Also note the number of characters. Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos more. http://mobile.yahoo.com/go?refer=1GNXIC -- http://mail.python.org/mailman/listinfo/python-list
Re: Is PEP-8 a Code or More of a Guideline?
Steve Howell a écrit : --- Carsten Haese [EMAIL PROTECTED] wrote: On Sun, 2007-05-27 at 07:30 +, OKB (not okblacke) wrote: Underscores are harder to type than any alphanumeric character. This is a discussion about underscores versus capital letters denoting the word boundaries in identifiers. How is an underscore harder to type than a capital letter? longer reach with the pinkie on American keyboards Slowly type the following two keywords, you'll see what I mean: hop_count hopCount Also note the number of characters. While this point was certainly discussed by those who wrote the PEP 8, I see hardly how it can be a valid argument. I used two keyboard maps in my life for development, fr_FR and fr_CH, in fr_CH both '.' and the pair '[', ']' are really more easy to type, and I think they appear at least as often as '_'. All in all, I never felt more productive with any keyboard, but, of course, I'm not a typist. Is typist ok ? It's the google's translation for dactylo. -- http://mail.python.org/mailman/listinfo/python-list
RE: Is PEP-8 a Code or More of a Guideline?
Hi Eric, You make a compelling argument for underscores. I sometimes help a visually impaired friend with setting up his computers. I'm wondering about the aural output to you second example: link.set_parse_action(emit_link_HTML) Does it sound like this: link dot set under parse under action space between parens emit under link under HTML jump out Also, does how HTML read? Is it H T M L or cap H cap T cap M cap L ? How many python programmers can reconfigure their speech-to-text and text-to-speech converter? Isn't there a Python based accessibility project? Perhaps a few lines of script to add CamelBack support, using an amplitude increase for initial caps and maybe lingering on the initial phoneme for an extra 100 milliseconds. So then, the above example would read: camel link dot set Parse Action between parens emit Link H T M L jump out Warren Eric S. Johansson wrote or said: link.setParseAction(emitLinkHTML) is spoken no caps link dot set no space cap parser no space cap action between parens emit no space cap link HTML jump out on the other hand, link.set_parse_action (emit_link_HTML) snip -- http://mail.python.org/mailman/listinfo/python-list
Re: Is PEP-8 a Code or More of a Guideline?
Warren Stringer wrote: Hi Eric, You make a compelling argument for underscores. I sometimes help a visually impaired friend with setting up his computers. I'm wondering about the aural output to you second example: link.set_parse_action(emit_link_HTML) Does it sound like this: unfortunately, I do not have text to speech set up on this machine as I'm saving the storage for more MP3s. :-) link dot set under parse under action space between parens emit under link under HTML jump out it would probably say underscore instead of under and left ( and right ) (too much work is make it spell out the symbol). Also, does how HTML read? Is it H T M L or cap H cap T cap M cap L ? probably HTML. Remember case is not apparent in an aural interface. How many python programmers can reconfigure their speech-to-text and text-to-speech converter? It's really difficult. I'm getting by right now with some minimal macros to start classes and methods as well as things like putting a: on the end of the line. But it is really primitive. When I had voice coder working, it was pretty good and the only problem was command surface area. Isn't there a Python based accessibility project? You might be thinking of voice coder and VR-mode for Emacs. Both projects need help, via-mode probably the most useful to the beginning user but combining the two would make a very nice voice driven Python IDE. Of course if somebody wanted to adapt it to another IDE that was nice and not too expensive, I think people would not say no to that either. Perhaps a few lines of script to add CamelBack support, using an amplitude increase for initial caps and maybe lingering on the initial phoneme for an extra 100 milliseconds. So then, the above example would read: I can tell you've never used speech recognition. :-) if you do that for a few weeks, you'll find yourself being reluctant to talk and considering using Morse code sent by big toe as your primary computer interface. QLF OM? Seriously, amplitude and timing information is gone by the time we get recognition events. This is a good thing because it eliminates problems caused by individual habits and physiological traits. As I've said before, I think the ultimate programming by voice environment is one in which the environment is aware of what symbols can be spoken and uses that information to improve accuracy. This will also allow for significant shortcuts in what you say in order to get the right code. The problem with this being that it needs to work when the code is broken. And I don't mean a little broken, I mean the kind of broken it gets when you are ripping out the implementation of one concept and putting in a new one. Yes, it's a hard problem. ---eric -- http://mail.python.org/mailman/listinfo/python-list
Re: Is PEP-8 a Code or More of a Guideline?
On May 29, 3:22 pm, Eric S. Johansson [EMAIL PROTECTED] wrote: Warren Stringer wrote: Hi Eric, You make a compelling argument for underscores. I sometimes help a visually impaired friend with setting up his computers. I'm wondering about the aural output to you second example: link.set_parse_action(emit_link_HTML) Does it sound like this: unfortunately, I do not have text to speech set up on this machine as I'm saving the storage for more MP3s. :-) link dot set under parse under action space between parens emit under link under HTML jump out it would probably say underscore instead of under and left ( and right ) (too much work is make it spell out the symbol). Also, does how HTML read? Is it H T M L or cap H cap T cap M cap L ? probably HTML. Remember case is not apparent in an aural interface. I don't do text-to-speech at all, but I do often have someone ask what's the method for blah? and case is important there. In such cases, I'd say lowercase emit underscore link underscore all caps H T M L. For emitLinkHTML it'd be lowercase emit capital-L link all-caps H T M L. For emitLinkHtml it'd be lowercase emit capital-L link capital-H H T M L. FWIW, even though I think proper-case-with-seperators is greatly preferrable to camelCase, I certainly don't think that speaking the names is a really major point. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is PEP-8 a Code or More of a Guideline?
Ben Finney a écrit : Paul McGuire [EMAIL PROTECTED] writes: It is a bit reassuring that I am not the only one who turns a blind eye to this part of the PEP, that l_c_w_u bothers others as well. I see similar support for lower_case, and opposition to camelCase. It's nice that we're both reassured by what we see. What now? So it's actually a matter of taste, and that's why PEP 8 exists, to answer the subject's question, make decision about conventions when only taste is in balance, am I wrong ? Asking the question is like asking : I don't like the convention, can I use another one for myself ? I think the answer is, of course, yes, but it is highly discouraged... (and that's why PEP 8 exists after all). -- http://mail.python.org/mailman/listinfo/python-list
Re: Is PEP-8 a Code or More of a Guideline?
Paul McGuire [EMAIL PROTECTED] writes: [...] http://mail.python.org/pipermail/python-dev/2005-December/058750.html At first, Guido seemed ambivalent, and commented on the contentiousness of the issue, but it seems that the non-English speakers can more easily find word breaks marked with underscores justification tipped the scale in favor of lower_case_with_underscores. [...] That rationale seems undermined by the frequent use of runtogether names in the standard library. These can be confusing even to native speakers. And every time you come up with a new name, or try to remember an old one, you have to decide or remember whether it's likethis or like_this. Even as a native English speaker, some of these are tricky -- e.g. urllib has a private class named addinfourl. What's this 'fourl' we're adding in? (In fact, the method adds attributes named info and url. Even though I've read that name hundreds of times, my brain always insists on reading it add in fourl.) This is the worst of both worlds: inconsistent and hard to understand. John -- http://mail.python.org/mailman/listinfo/python-list
Re: Is PEP-8 a Code or More of a Guideline?
John J. Lee wrote: Paul McGuire [EMAIL PROTECTED] writes: [...] http://mail.python.org/pipermail/python-dev/2005-December/058750.html At first, Guido seemed ambivalent, and commented on the contentiousness of the issue, but it seems that the non-English speakers can more easily find word breaks marked with underscores justification tipped the scale in favor of lower_case_with_underscores. [...] That rationale seems undermined by the frequent use of runtogether names in the standard library. These can be confusing even to native speakers. And every time you come up with a new name, or try to remember an old one, you have to decide or remember whether it's likethis or like_this. Even as a native English speaker, some of these are tricky -- e.g. urllib has a private class named addinfourl. What's this 'fourl' we're adding in? (In fact, the method adds attributes named info and url. Even though I've read that name hundreds of times, my brain always insists on reading it add in fourl.) This is the worst of both worlds: inconsistent and hard to understand. Sounds like a good candidate for a rename in Python 3000. STeVe -- http://mail.python.org/mailman/listinfo/python-list
Re: Is PEP-8 a Code or More of a Guideline?
In article [EMAIL PROTECTED], Steven Bethard [EMAIL PROTECTED] wrote: Stefan Sonnenberg-Carstens wrote: Paul McGuire schrieb: I'm starting a new thread for this topic, so as not to hijack the one started by Steve Howell's excellent post titled ten small Python programs. In that thread, there was a suggestion that these examples should conform to PEP-8's style recommendations, including use of lower_case_with_underscores style for function names. I raised some questions about this suggestion, since I liked the names the way they were, but as a result, part of the discussion has drifted into a separate track about PEP-8, and naming styles. I prefer mixedCaseStyle, and I think that should be standard, as this style is commonly used in all major languages , for example Java,C++,C#. It shortens the identifiers but leaves the meaning intact. The argument for under_score_names is usually that non-native speakers can more easily find the word boundaries. Not being a non-native speaker ;-) I can't verify that one, but it's pretty plausible given the current amount of money spent on research on automatic word-segmentation for languages like Chinese. =) STeVe I've gone through a few different flavors of composite name schemes over the years (starting with FORTRAN's 6 upper case character limit). When first exposed to camelCase, I thought it was horrible. Eventually, I came to like it. On the other hand, I'm convinced that words_with_underscores, is easier to read. This is especially true when abbreviations creep into variable names. It's certainly easier to parse ip_address as compared to IPAddress. Same with snmp_manager vs SNMPManager. I really like lisp's convention of using dashes instead of underscores, i.e. ip-address and snmp-manager. I think the only reason most languages don't use that is the parsing ambiguity, but if you required white space around all operators, then ip-address would unambiguously be a variable name and ip - address would be a subtraction expression. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is PEP-8 a Code or More of a Guideline?
--- Roy Smith [EMAIL PROTECTED] wrote: It's certainly easier to parse ip_address as compared to IPAddress. Same with snmp_manager vs SNMPManager. Somebody earlier was actually advocating something called proper_case, in which you can capitalize certain letters for clarity, like test_for_Heisenberg_uncertainty. Regarding acronyms, I'm curious about how people interpret PEP 8 for the following. Acronyms: get_HTTP_response get_http_response Abbreviations: get_file_id get_file_ID Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out. http://answers.yahoo.com/dir/?link=listsid=396545469 -- http://mail.python.org/mailman/listinfo/python-list
Re: Is PEP-8 a Code or More of a Guideline?
Roy Smith [EMAIL PROTECTED] writes: [...] On the other hand, I'm convinced that words_with_underscores, is easier to read. This is especially true when abbreviations creep into variable names. It's certainly easier to parse ip_address as compared to IPAddress. Same with snmp_manager vs SNMPManager. Well, you don't capitalize abbreviations like that in a classic CamelCase, I believe. Those names ought to be SnmpManager and IpAddress. Though there is still problem with digits, e.g., Crc24Accum. -- Sergei. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is PEP-8 a Code or More of a Guideline?
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Historically, it's only Java and the Windows world (including non- standard Windows-style C++) that use forcedCase significantly (C# draws from both). I remember meeting that style first in the X Window System (now commonly known as X11, but it was around for a few years before the 11 arrived), which is a little bit older than Windows and WAY older than Java. I don't know if X was the first project to use that style consistently. Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: Is PEP-8 a Code or More of a Guideline?
On Mon, 28 May 2007 14:12:33 -0700, Alex Martelli wrote: [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Historically, it's only Java and the Windows world (including non- standard Windows-style C++) that use forcedCase significantly (C# draws from both). I remember meeting that style first in the X Window System (now commonly known as X11, but it was around for a few years before the 11 arrived), which is a little bit older than Windows and WAY older than Java. I don't know if X was the first project to use that style consistently. There was also Hypercard from Apple in (by memory) 1988. Although case was not significant, handlers were usually written mouseDown, mouseUp, openStack, openCard, etc. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is PEP-8 a Code or More of a Guideline?
Steven D'Aprano [EMAIL PROTECTED] writes: There was also Hypercard from Apple in (by memory) 1988. Although case was not significant, handlers were usually written mouseDown, mouseUp, openStack, openCard, etc. Apple (*cough*) Xerox PARC (*cough*). I think that style got into the Macintosh by way of Smalltalk, and got into X11 the same way indirectly, via the CMU Andrew system and its relatives that also were influenced by Smalltalk. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is PEP-8 a Code or More of a Guideline?
Paul McGuire wrote: At first, Guido seemed ambivalent, and commented on the contentiousness of the issue, but it seems that the non-English speakers can more easily find word breaks marked with underscores justification tipped the scale in favor of lower_case_with_underscores. The PEP itself on www.python.org seems to have been updated as recently as May 17 of this year, but I don't seen any way to identify what the change history is. So, those who are the stewards of the core source code have nailed down thier coding standard to be l_c_w_u, so if sometime in the future I find myself working on any code in the Python std libs, l_c_w_u is the style to be followed. It just looks so old-fashioned... link.setParseAction(emitLinkHTML) is spoken no caps link dot set no space cap parser no space cap action between parens emit no space cap link HTML jump out on the other hand, link.set_parse_action (emit_link_HTML) is much more friendly to aural interfaces. I've been using speech recognition since about 1995 when I was injured thanks to programming in high stress, ergonomically poor environments. as a result, I have become extremely sensitive to what makes a good interface for hands and for voice. Bumpy case words are extremely difficult to pronounce for both text-to-speech dependent blind users and speech recognition (speech to text) dependent users like myself. One important factor in a speech user interfaces is the difference between what you say/here and the target text. I can't say for the blind user but I know in the speech recognition context, the more time you spend thinking about what it is you say in order to get your desired text, the less brainpower you have for thinking about the problem. There are solutions to this problem but unfortunately handicapped users are in a Catch-22 situation. We know what we need to make our world better. But we don't have the hands to make our world better. Therefore we have to rely on those who don't know what we need to make our lives better which doesn't happen. There are two projects (voice coder and vr-mode) which have started making things better. Unfortunately, they are are fragile and difficult to install which defeats the purpose of a good accessibility tool. I suggest that the first option is encouraging enhanced use of full words joined by underscores for all public interfaces so that unenhanced speech recognition or text-to-speech systems can be used in a way we have become accustomed to living with. This is not to say it's good. Only that we have acquired enough scar tissue to cope. the second option would be for some of you to dig in and help some of your technical kinfolk by improving some tools so that we can start writing Python code with greater ease. A huge reason why this is important because the vast majority of software developers who are injured fall off the economic ladder. They leave the profession and had very few options for work that doesn't involve significant handy is. The last time I looked at the numbers, in the US somewhere north of 60,000 developers per year are injured. Some recover (kind of). Others, like I said, dropout. Tools to make programming by voice easier and not as damaging to the throat as unenhanced speech recognition with bumpy caps symbols, would significantly improve the lives of people you probably know and possibly your own life in the future. Feel free to contact me off list if you want. ---eric (founding member of Open Source Speech Recognition Initiative nonprofit) warning: NaturallySpeaking in use. It makes mistakes. I correct some. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is PEP-8 a Code or More of a Guideline?
Roy Smith wrote: I really like lisp's convention of using dashes instead of underscores, i.e. ip-address and snmp-manager. I think the only reason most languages don't use that is the parsing ambiguity, but if you required white space around all operators, then ip-address would unambiguously be a variable name and ip - address would be a subtraction expression. Then you'd really love COBOL! :-) Frank COBOL programmer for 10+ years -- http://mail.python.org/mailman/listinfo/python-list
Re: Is PEP-8 a Code or More of a Guideline?
Paul McGuire schrieb: I'm starting a new thread for this topic, so as not to hijack the one started by Steve Howell's excellent post titled ten small Python programs. In that thread, there was a suggestion that these examples should conform to PEP-8's style recommendations, including use of lower_case_with_underscores style for function names. I raised some questions about this suggestion, since I liked the names the way they were, but as a result, part of the discussion has drifted into a separate track about PEP-8, and naming styles. I was under the impression that lower_case_with_underscores was a dated recommendation, and that recent practice is more inclusive of mixedCase style identifiers. On the contrary, Steven Bethard straightened me out, saying that PEP-8 used to accept either style, but has been amended to accept only lower_case_with_underscores. My latest thought on the topic relates back to the Martin v. Löwis thread-that-would-not-die requesting feedback about PEP 3131, on adding support for non-ASCII identifiers in Py3K. I posted an out-of- curiosity comment asking about how underscore separators mix with Unicode identifiers, including the mechanics of actually typing an underscore on a non-US keyboard. At this point, I realized that I was taking things too far off-topic, so I decided to start a new thread. Steve, sorry for taking your thread down a rathole. I hope we can move any further PEP-8-related discussion (if the point merits any) to this thread. -- Paul I prefer mixedCaseStyle, and I think that should be standard, as this style is commonly used in all major languages , for example Java,C++,C#. It shortens the identifiers but leaves the meaning intact. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is PEP-8 a Code or More of a Guideline?
Stefan Sonnenberg-Carstens wrote: Paul McGuire schrieb: I'm starting a new thread for this topic, so as not to hijack the one started by Steve Howell's excellent post titled ten small Python programs. In that thread, there was a suggestion that these examples should conform to PEP-8's style recommendations, including use of lower_case_with_underscores style for function names. I raised some questions about this suggestion, since I liked the names the way they were, but as a result, part of the discussion has drifted into a separate track about PEP-8, and naming styles. I prefer mixedCaseStyle, and I think that should be standard, as this style is commonly used in all major languages , for example Java,C++,C#. It shortens the identifiers but leaves the meaning intact. The argument for under_score_names is usually that non-native speakers can more easily find the word boundaries. Not being a non-native speaker ;-) I can't verify that one, but it's pretty plausible given the current amount of money spent on research on automatic word-segmentation for languages like Chinese. =) STeVe -- http://mail.python.org/mailman/listinfo/python-list
Re: Is PEP-8 a Code or More of a Guideline?
Paul McGuire wrote: I was under the impression that lower_case_with_underscores was a dated recommendation, and that recent practice is more inclusive of mixedCase style identifiers. On the contrary, Steven Bethard straightened me out, saying that PEP-8 used to accept either style, but has been amended to accept only lower_case_with_underscores. Underscores are harder to type than any alphanumeric character. Thus I support their use in situations where difficulty of typing is desirable (e.g., magic method names) and I detest them in all other situations. -- --OKB (not okblacke) Brendan Barnwell Do not follow where the path may lead. Go, instead, where there is no path, and leave a trail. --author unknown -- http://mail.python.org/mailman/listinfo/python-list
Re: Is PEP-8 a Code or More of a Guideline?
On May 27, 1:25 am, Steven Bethard [EMAIL PROTECTED] wrote: Stefan Sonnenberg-Carstens wrote: Paul McGuire schrieb: I'm starting a new thread for this topic, so as not to hijack the one started by Steve Howell's excellent post titled ten small Python programs. In that thread, there was a suggestion that these examples should conform to PEP-8's style recommendations, including use of lower_case_with_underscores style for function names. I raised some questions about this suggestion, since I liked the names the way they were, but as a result, part of the discussion has drifted into a separate track about PEP-8, and naming styles. I prefer mixedCaseStyle, and I think that should be standard, as this style is commonly used in all major languages , for example Java,C++,C#. It shortens the identifiers but leaves the meaning intact. The argument for under_score_names is usually that non-native speakers can more easily find the word boundaries. Not being a non-native speaker ;-) I can't verify that one, but it's pretty plausible given the current amount of money spent on research on automatic word-segmentation for languages like Chinese. =) STeVe- Hide quoted text - - Show quoted text - Here is the thread from python-dev where this change (from mixedCase is no better or worse than lower_case_with_underscores to should use l_c_w_u) was discussed, a year ago last December: http://mail.python.org/pipermail/python-dev/2005-December/058750.html At first, Guido seemed ambivalent, and commented on the contentiousness of the issue, but it seems that the non-English speakers can more easily find word breaks marked with underscores justification tipped the scale in favor of lower_case_with_underscores. The PEP itself on www.python.org seems to have been updated as recently as May 17 of this year, but I don't seen any way to identify what the change history is. So, those who are the stewards of the core source code have nailed down thier coding standard to be l_c_w_u, so if sometime in the future I find myself working on any code in the Python std libs, l_c_w_u is the style to be followed. It just looks so old-fashioned... Whatev. -- Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: Is PEP-8 a Code or More of a Guideline?
Paul McGuire [EMAIL PROTECTED] writes: At this point, I realized that I was taking things too far off-topic, so I decided to start a new thread. So, uh, what's the purpose of this thread? Did you have a specific point to start off with, or a question to ask? -- \ It seems intuitively obvious to me, which means that it might | `\be wrong. -- Chris Torek | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Is PEP-8 a Code or More of a Guideline?
On Sun, 2007-05-27 at 07:30 +, OKB (not okblacke) wrote: Underscores are harder to type than any alphanumeric character. This is a discussion about underscores versus capital letters denoting the word boundaries in identifiers. How is an underscore harder to type than a capital letter? -- Carsten Haese http://informixdb.sourceforge.net -- http://mail.python.org/mailman/listinfo/python-list
Re: Is PEP-8 a Code or More of a Guideline?
--- Ben Finney [EMAIL PROTECTED] wrote: Paul McGuire [EMAIL PROTECTED] writes: At this point, I realized that I was taking things too far off-topic, so I decided to start a new thread. So, uh, what's the purpose of this thread? Did you have a specific point to start off with, or a question to ask? I'll take the liberty of answering on by behalf of Paul. Purpose of the thread--he realized he was taking another thread off topic, decided to start his own, so that people who don't want debate PEP 8 can more easily ignore it Specific point--he was mostly focused on the pain of using underscores, and while he was still off-topic on the previous thread, he had put his problems in the context of working with German colleagues who have slightly different keyboards than the American keyboard he has, the upcoming complications of Unicode in Python 3, etc. Question to ask--note the subject line, although I'm not sure that's his main question Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/features_spam.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Is PEP-8 a Code or More of a Guideline?
En Sun, 27 May 2007 10:20:49 -0300, Carsten Haese [EMAIL PROTECTED] escribió: On Sun, 2007-05-27 at 07:30 +, OKB (not okblacke) wrote: Underscores are harder to type than any alphanumeric character. This is a discussion about underscores versus capital letters denoting the word boundaries in identifiers. How is an underscore harder to type than a capital letter? Underscores are not always easily available on non us-layout keyboards, like \ and @ and many other special characters. A language that requires more symbols than the 26 english letters has to make room somewhere - keyboards usually have only 102 keys (or 105 nowadays). Back to the style, I think that mixedCaseIsEnough to determine_word_endings and looksBetter. alllowercase is hard to read. -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list
Re: Is PEP-8 a Code or More of a Guideline?
--- Gabriel Genellina [EMAIL PROTECTED] wrote:
Underscores are not always easily available on non
us-layout keyboards,
like \ and @ and many other special characters. A
language that requires
more symbols than the 26 english letters has to make
room somewhere -
keyboards usually have only 102 keys (or 105
nowadays).
Back to the style, I think that mixedCaseIsEnough to
Regarding the US keyboard, if you like chess:
1) The right pinkie normally sits on the semicolon,
and if you shift it, you get a colon.
2) Typing the P character is like moving a pawn up
one square (while shifting with the left).
3) Typing the [ and { is like capturing with the
pawn (one up, one over).
4) Typing the _ is like moving the knight (two up,
one over), as are typing the ] an } (one up, two
over).
No need to miss a message. Get email on-the-go
with Yahoo! Mail for Mobile. Get started.
http://mobile.yahoo.com/mail
--
http://mail.python.org/mailman/listinfo/python-list
Re: Is PEP-8 a Code or More of a Guideline?
On May 27, 3:35 am, Ben Finney [EMAIL PROTECTED] wrote: Paul McGuire [EMAIL PROTECTED] writes: At this point, I realized that I was taking things too far off-topic, so I decided to start a new thread. So, uh, what's the purpose of this thread? Did you have a specific point to start off with, or a question to ask? -- \ It seems intuitively obvious to me, which means that it might | `\be wrong. -- Chris Torek | _o__) | Ben Finney (Nice sig quote, by the way.) Mostly, I started this thread so any discussion of lower_case_with_underscores (l_c_w_u) vs. mixedCase naming styles would not (further) clutter up Steve Howell's thread. To recap: - I was surprised at the comments to convert Steve's example to l_c_w_u, as the last time I read PEP-8, it had the more liberal use whichever you prefer, just be consistent wording. - I posted one comment that I thought l_c_w_u looks old-fashioned, and was an odd choice in the face of mixedCase, which has been adopted as de facto practice in recent languages. - I also mused on the implications for l_c_w_u in the face of Py3K's recent acceptance of non-ASCII identifiers, and added as a related point my own personal experience with typing '_' on a non-US keyboard layout. - At this point, I tracked down the python-dev archive of the discussion thread that led to the stricter version of PEP-8, and I can see that this is a windmill (like the choice of '@' sign for decorators) that is not worth tilting at. It is a bit reassuring that I am not the only one who turns a blind eye to this part of the PEP, that l_c_w_u bothers others as well. But as to the further purpose for this thread, I think there is little to none. We will continue to see std lib code written using l_c_w_u. Ordinarily, this would little concern me, since I go to read std lib code about once/year. But it does mean that additions to the external API to the std lib will contain method calls such as get_files, send_message, delete_record, etc. I think this just promotes a perception of Python as so last century. It would also seem we will continue to see 3rd party developers use whatever their personal taste and/or project coding standards dictate. So for these users, this part of the PEP is not really a code, its more of a guideline.* -- Paul *same joke was in Ghostbusters and Pirates of the Caribbean, Pt.1 -- http://mail.python.org/mailman/listinfo/python-list
Re: Is PEP-8 a Code or More of a Guideline?
Stefan Sonnenberg-Carstens wrote: Paul McGuire schrieb: I'm starting a new thread for this topic, so as not to hijack the one started by Steve Howell's excellent post titled ten small Python programs. In that thread, there was a suggestion that these examples should conform to PEP-8's style recommendations, including use of lower_case_with_underscores style for function names. I raised some questions about this suggestion, since I liked the names the way they were, but as a result, part of the discussion has drifted into a separate track about PEP-8, and naming styles. I was under the impression that lower_case_with_underscores was a dated recommendation, and that recent practice is more inclusive of mixedCase style identifiers. On the contrary, Steven Bethard straightened me out, saying that PEP-8 used to accept either style, but has been amended to accept only lower_case_with_underscores. My latest thought on the topic relates back to the Martin v. Lo:wis thread-that-would-not-die requesting feedback about PEP 3131, on adding support for non-ASCII identifiers in Py3K. I posted an out-of- curiosity comment asking about how underscore separators mix with Unicode identifiers, including the mechanics of actually typing an underscore on a non-US keyboard. At this point, I realized that I was taking things too far off-topic, so I decided to start a new thread. Steve, sorry for taking your thread down a rathole. I hope we can move any further PEP-8-related discussion (if the point merits any) to this thread. -- Paul I prefer mixedCaseStyle, and I think that should be standard, as this style is commonly used in all major languages , for example Java,C++,C#. It shortens the identifiers but leaves the meaning intact. Actually, proper_case is standard in C++ (see, e.g., the naming section of http://www.research.att.com/~bs/bs_faq2.html ) . And C is still more common than Java, and Perl and Lisp are about as common as C#--all use proper case (though Lisp uses - instead of _). Historically, it's only Java and the Windows world (including non- standard Windows-style C++) that use forcedCase significantly (C# draws from both). The underscore version is not lower case; it is proper case--case is used as in normal English. Compare plot_line_slope() vs. plot_line_Besenheim(); with the underscore method, you preserve all the natural meaning of case. Especially when you have, say, acronyms in variable names, forcedCase can be somewhat confusing even for native English speakers; the style forces you to use a specific case for naming convention reasons, losing the natural meaning of the case. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is PEP-8 a Code or More of a Guideline?
Carsten Haese wrote: On Sun, 2007-05-27 at 07:30 +, OKB (not okblacke) wrote: Underscores are harder to type than any alphanumeric character. This is a discussion about underscores versus capital letters denoting the word boundaries in identifiers. How is an underscore harder to type than a capital letter? It is harder in that the key that has the underscore on it is quite out of the way compared to any letter key. -- --OKB (not okblacke) Brendan Barnwell Do not follow where the path may lead. Go, instead, where there is no path, and leave a trail. --author unknown -- http://mail.python.org/mailman/listinfo/python-list
Re: Is PEP-8 a Code or More of a Guideline?
OKB (not okblacke) [EMAIL PROTECTED] writes: Underscores are harder to type than any alphanumeric character. I know of no keyboard layout in common use where it's more complicated than Shift+some key, exactly the same as a single uppercase letter. Care to enlighten me? -- \Conscience is the inner voice that warns us somebody is | `\looking. -- Henry L. Mencken | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Is PEP-8 a Code or More of a Guideline?
Stefan Sonnenberg-Carstens [EMAIL PROTECTED] writes: I prefer mixedCaseStyle, and I think that should be standard, I dislike it. It's inconsistent, and confusingly similar to TitleCaseStyle used for class names in Python. as this style is commonly used in all major languages , for example Java,C++,C#. Is C no longer a major language? The long-standing convention there is for lower_case_with_underscores. It shortens the identifiers but leaves the meaning intact. The shortening is both minor, and irrelevant: clarity is worth more than shorter names merely for the sake of shorter names. -- \ If you're a young Mafia gangster out on your first date, I bet | `\it's real embarrassing if someone tries to kill you. -- Jack | _o__) Handey | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Is PEP-8 a Code or More of a Guideline?
Paul McGuire [EMAIL PROTECTED] writes: code about once/year. But it does mean that additions to the external API to the std lib will contain method calls such as get_files, send_message, delete_record, etc. I think this just promotes a perception of Python as so last century. I think you've got it backwards; the godawful MixedCase style goes back to Smalltalk, which couldn't use underscores in identifiers because it had assigned some other purpose to that character. That it was picked up by Java is not evidence of anything other than Java's Vogon-like tastelessness, and of course C# uses it since C# is basically a Java dialect. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is PEP-8 a Code or More of a Guideline?
Ben Finney [EMAIL PROTECTED] wrote:
Is C no longer a major language? The long-standing convention there
is for lower_case_with_underscores.
Which dates back to the days of ASR-33's which only had one case (upper
case, as a matter of fact). Does nobody else remember C compilers which
accepted \( and \) for { and }?
--
http://mail.python.org/mailman/listinfo/python-list
Re: Is PEP-8 a Code or More of a Guideline?
Paul McGuire [EMAIL PROTECTED] writes: It is a bit reassuring that I am not the only one who turns a blind eye to this part of the PEP, that l_c_w_u bothers others as well. I see similar support for lower_case, and opposition to camelCase. It's nice that we're both reassured by what we see. What now? We will continue to see std lib code written using l_c_w_u. Ordinarily, this would little concern me, since I go to read std lib code about once/year. But it does mean that additions to the external API to the std lib will contain method calls such as get_files, send_message, delete_record, etc. I think this just promotes a perception of Python as so last century. If clearly-readable code is so last century, I don't see how that's a negative. It would also seem we will continue to see 3rd party developers use whatever their personal taste and/or project coding standards dictate. So for these users, this part of the PEP is not really a code, its more of a guideline.* Many of these libraries have users, and even primary developers, who hope to find the modules added to the standard library one day. I think using lower_case for names is good style in all Python code, for consistency. -- \ You could augment an earwig to the point where it understood | `\ nuclear physics, but it would still be a very stupid thing to | _o__) do! -- The Doctor, _The Two Doctors_ | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Is PEP-8 a Code or More of a Guideline?
I'm starting a new thread for this topic, so as not to hijack the one started by Steve Howell's excellent post titled ten small Python programs. In that thread, there was a suggestion that these examples should conform to PEP-8's style recommendations, including use of lower_case_with_underscores style for function names. I raised some questions about this suggestion, since I liked the names the way they were, but as a result, part of the discussion has drifted into a separate track about PEP-8, and naming styles. I was under the impression that lower_case_with_underscores was a dated recommendation, and that recent practice is more inclusive of mixedCase style identifiers. On the contrary, Steven Bethard straightened me out, saying that PEP-8 used to accept either style, but has been amended to accept only lower_case_with_underscores. My latest thought on the topic relates back to the Martin v. Löwis thread-that-would-not-die requesting feedback about PEP 3131, on adding support for non-ASCII identifiers in Py3K. I posted an out-of- curiosity comment asking about how underscore separators mix with Unicode identifiers, including the mechanics of actually typing an underscore on a non-US keyboard. At this point, I realized that I was taking things too far off-topic, so I decided to start a new thread. Steve, sorry for taking your thread down a rathole. I hope we can move any further PEP-8-related discussion (if the point merits any) to this thread. -- Paul -- http://mail.python.org/mailman/listinfo/python-list
