[Python-Dev] pep8 reasoning
Hi All, Apologies if this is considered off topic, but I'm keen to get the "language designers" point of view and short of emailing Barry, Guido and Nick directly, this seemed like the best place. I'm having a tough time persuading some people of the benefits of pep8, particularly when it comes to applying to an existing large code base. The biggest sticking point is naming, particularly as it's the one thing that can't necessarily be changed module by module. What were the compelling reasons to go from mixedCase to underscore_separated? What's considered the best approach for migrating from the former to the latter? A couple of others that have raised some consternation; what are the technical reasons for this pattern being bad: if len(seq) if not len(seq) ...or, for me, the rather ugly: if 0 != len(seq) Likewise, these: if greeting == True: if greeting is True: Please don't misunderstand me: I dislike the above intensely, but it's an emotional response based on 10-15 years of doing things the other way. I'm interested in arguments that don't include things like "it's pythonic" (which some people consider a derogatory term ;-)), or "just because", I trust that the stuff in pep8 was done with specific reasoning in mind, but I'm feeling rather useless at giving that reasoning and I'm hoping you can help :-) cheers, Chris ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pep8 reasoning
On Thu, Apr 24, 2014 at 2:18 AM, Chris Withers wrote: > What were the compelling reasons to go from mixedCase to > underscore_separated? What's considered the best approach for migrating from > the former to the latter? I never recall Python "going from" camelCase to separate_words. The descriptions of best practice you see in the PEP were always that way, as I recall. If you have a code base that does it some other way, I would leave it be. The primary hunk of code I work with is full of Boost.Python-generated bindings for C++ libraries, so leaks C++ naming style out of all its pores. A lot of the other pure Python code in this code base was written by people who were mostly C++ programmers, and didn't know PEP 8 from a hole in the ground. Consequently, the whole thing is riddled with all sorts of non-pep8-ness. I used to want to change everything, but just let that sleeping dog lie. I have better things to do with my life. New stuff I write tends to be much more pep8-ish. Skip ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pep8 reasoning
On Thu, Apr 24, 2014 at 10:18 AM, Chris Withers wrote: > A couple of others that have raised some consternation; what are the > technical reasons for this pattern being bad: > > if len(seq) > if not len(seq) > > ...or, for me, the rather ugly: > > if 0 != len(seq) > > Likewise, these: > > if greeting == True: > if greeting is True: As far as I know that reason for these examples being frowned upon is that they are needlessly redundant. This is not just a matter of minimalism or style; it's a matter of readability. If you're relying on the "len()" call to fail if "seq" isn't a container (for example, if it's None), the code for that should be separate and more explicit. Regarding "if something == True", that's only the same as "if greeting" if greeting is assumed to be a boolean value. If so, it is better (for readability) to use a descriptive variable name: "if should_greet:". Otherwise (e.g. if greeting could also be None) it is reasonable to check if it is equal to a specific value (with a short comment explaining this point!). Also, there's no end to how much comparison to True one can do: if (greeting == True) == True if ((greeting == True) == True) == True Considering that, IMO it makes sense to just avoid such comparisons altogether. - Tal Einat ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pep8 reasoning
On 24/04/2014 12:59, Tal Einat wrote: > As far as I know that reason for these examples being frowned upon is > that they are needlessly redundant. Oh, the irony! (Sorry, couldn't resist) TJG ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pep8 reasoning
On Apr 24, 2014, at 08:18 AM, Chris Withers wrote: >I'm having a tough time persuading some people of the benefits of pep8, >particularly when it comes to applying to an existing large code base. First of all, the purposes of PEP 8 is not to impose mandates of style on your colleagues. :) Two important quotes are useful to keep in mind: Introduction This document gives coding conventions for the Python code comprising the *standard library* in the main Python distribution. (emphasis added) A Foolish Consistency is the Hobgoblin of Little Minds A style guide is about consistency. Consistency with this style guide is important. Consistency within a project is more important. Consistency within one module or function is most important. [...] Some other good reasons to ignore a particular guideline: To be consistent with surrounding code that also breaks it (maybe for historic reasons) -- although this is also an opportunity to clean up someone else's mess (in true XP style). While I personally think PEP 8 is good enough to adopt for my own projects, and I encourage other projects to also adopt the guidelines where appropriate, doing so is *not* always appropriate in existing source code outside the standard library (and sometimes even within the stdlib, e.g. unittest). >The biggest sticking point is naming, particularly as it's the one thing that >can't necessarily be changed module by module. What were the compelling >reasons to go from mixedCase to underscore_separated? What's considered the >best approach for migrating from the former to the latter? If your existing code base is already mixedCase, then there's no compelling reason for a wholesale transition, IMO. I work with plenty of existing mixedCase code and it's much more jarring to see a mix of styles than it is to see consistent mixedCase naming. OTOH, some projects do choose to adopt PEP 8 style names over time, and they have to manage all the expected API guarantees involved in that. I will say this: the original preference for underscore_names in PEP 8 was spurred by user studies some of our early non-native English speaking users conducted many years ago. We learned that it was more difficult for many of them to parse mixedCase names than underscore_names. I'm afraid I probably no longer have references to those studies, but the difference was pronounced, IIRC, and I think it's easy to see why. Underscores can be scanned by the eye as spaces, while I'd hypothesize that the brain has to do more work to read mixedCase names. >A couple of others that have raised some consternation; what are the >technical reasons for this pattern being bad: > >if len(seq) >if not len(seq) > >...or, for me, the rather ugly: > >if 0 != len(seq) Well, I'd write that as `len(seq) != 0` but still, I get your point. The rationale for this is that generic truthiness is a wider check then an explicit value check, and EIBTI. This really comes down to the difference between if not thing: vs if thing != other: In the first case, any falsey value makes it through, while in the second case, you're being more explicit about what you think the value of `thing` can be. So when semantically `thing` can be 0 or None or '', then the first test is preferred. When `thing` can't just be any truthy or falsey value, then a more explicit check is preferred, otherwise some unexpected falsey value might slip through. It might seem less applicable to the len(seq) case, but I'd offer that that's just an application of a more general principle. >Likewise, these: > >if greeting == True: >if greeting is True: This one is based on the preference for identity checks when singletons are involved, rather than equality tests. Being composed of English words, the latter is also more readable. It's the same reason why you would do identity checks against None or enum values. >Please don't misunderstand me: I dislike the above intensely, but it's an >emotional response based on 10-15 years of doing things the other way. I'm >interested in arguments that don't include things like "it's pythonic" (which >some people consider a derogatory term ;-)), or "just because", I trust that >the stuff in pep8 was done with specific reasoning in mind, but I'm feeling >rather useless at giving that reasoning and I'm hoping you can help :-) I hope those explanations give you the basis for why the choices were made. They aren't arbitrary, although folks can and do disagree. It's much more important that your project comes up with its own guidelines and applies them self-consistently. For example, I have my own small set of refinements on top of PEP 8. I'm not providing a link because they're a bit out of date w.r.t. Python 3. ;) Cheers, -Barry ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/op
Re: [Python-Dev] pep8 reasoning
On Thu, Apr 24, 2014 at 8:59 AM, Barry Warsaw wrote: > I will say this: the original preference for underscore_names in PEP 8 was > spurred by user studies some of our early non-native English speaking users > conducted many years ago. We learned that it was more difficult for many of > them to parse mixedCase names than underscore_names. I'm afraid I probably no > longer have references to those studies, but the difference was pronounced, > IIRC, and I think it's easy to see why. Underscores can be scanned by the eye > as spaces, while I'd hypothesize that the brain has to do more work to read > mixedCase names. Given Guido's background, I suspect these studies might have been done at CWI in the context of the ABC language. Skip ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ref leaks
On 04/23/2014 09:06 PM, Benjamin Peterson wrote: On Wed, Apr 23, 2014, at 19:14, Ethan Furman wrote: Command line: ./python -m test.regrtest -v -R3:3 test_tools Results: Ran 44 tests in 7.628s OK (skipped=1) . test_tools leaked [0, 2, 2] references, sum=4 1 test failed: test_tools Any words of wisdom for tracking those leaks? Unless it's consistent, that sort of behavior usually just gets dismissed as intermittent. test_tools leaked [331, 0, 0] references, sum=331 test_tools leaked [108, 1, 0] memory blocks, sum=109 test_tools leaked [2, 0, 0] references, sum=2 test_tools leaked [0, 0, 4] references, sum=4 test_tools leaked [0, 0, 3] memory blocks, sum=3 Consistently the same, or consistently happening? ;) -- ~Ethan~ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pep8 reasoning
On 2014-04-24 14:59, Barry Warsaw wrote: I will say this: the original preference for underscore_names in PEP 8 was spurred by user studies some of our early non-native English speaking users conducted many years ago. We learned that it was more difficult for many of them to parse mixedCase names than underscore_names. I'm afraid I probably no longer have references to those studies, but the difference was pronounced, IIRC, and I think it's easy to see why. Underscores can be scanned by the eye as spaces, while I'd hypothesize that the brain has to do more work to read mixedCase names. A more recent set of studies show some mixedResults (ha ha). On a low-level reading task, the studies agree with yours in that mixedCase takes more time and effort; however, it appears to improve accuracy as well. On a higher-level comprehension task, mixedCase took less or the same time and still improved accuracy. Experienced programmers don't see too much of a difference either way, but inexperienced programmers see a more marked benefit to mixedCase. http://www.cs.loyola.edu/~binkley/papers/tr-loy110720.pdf That said, I can't vouch for the experiments or the analysis, and it isn't really germane to Chris' historical question. I mention it only because I had just run across this paper last night, so it was fresh in my mind when you mentioned studies on the subject. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] pep8 reasoning
Hi All, Apologies if this is considered off topic, but I'm keen to get the "language designers" point of view and short of emailing Barry, Guido and Nick directly, this seemed like the best place. I'm having a tough time persuading some people of the benefits of pep8, particularly when it comes to applying to an existing large code base. The biggest sticking point is naming, particularly as it's the one thing that can't necessarily be changed module by module. What were the compelling reasons to go from mixedCase to underscore_separated? What's considered the best approach for migrating from the former to the latter? A couple of others that have raised some consternation; what are the technical reasons for this pattern being bad: if len(seq) if not len(seq) ...or, for me, the rather ugly: if 0 != len(seq) Likewise, these: if greeting == True: if greeting is True: Please don't misunderstand me: I dislike the above intensely, but it's an emotional response based on 10-15 years of doing things the other way. I'm interested in arguments that don't include things like "it's pythonic" (which some people consider a derogatory term ;-)), or "just because", I trust that the stuff in pep8 was done with specific reasoning in mind, but I'm feeling rather useless at giving that reasoning and I'm hoping you can help :-) cheers, Chris ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ref leaks
Ethan Furman wrote: > >>Any words of wisdom for tracking those leaks? Often the easiest way is to compile --with-valgrind and run the test under Valgrind (obviously). In the Valgrind output, search for "definitely lost" and ignore the rest. If that does not turn up anything, consider a bug in regrtest.py: It happens that certain caches are initialized incrementally in each repetition of the test, so the reported leaks are spurious. That is why some caches like small integers are "warmed up" in regrtest.py. Perhaps there is some recently added cache that needs attention. Stefan Krah ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ref leaks
On Thu, Apr 24, 2014 at 7:31 AM, Ethan Furman wrote: > On 04/23/2014 09:06 PM, Benjamin Peterson wrote: > >> On Wed, Apr 23, 2014, at 19:14, Ethan Furman wrote: >> >>> Command line: >>> >>> ./python -m test.regrtest -v -R3:3 test_tools >>> >>> Results: >>> >>> Ran 44 tests in 7.628s >>> >>> OK (skipped=1) >>> . >>> test_tools leaked [0, 2, 2] references, sum=4 >>> 1 test failed: >>> test_tools >>> >>> Any words of wisdom for tracking those leaks? >>> >> >> Unless it's consistent, that sort of behavior usually just gets >> dismissed as intermittent. >> > > test_tools leaked [331, 0, 0] references, sum=331 > test_tools leaked [108, 1, 0] memory blocks, sum=109 > > test_tools leaked [2, 0, 0] references, sum=2 > > test_tools leaked [0, 0, 4] references, sum=4 > test_tools leaked [0, 0, 3] memory blocks, sum=3 > > Consistently the same, or consistently happening? ;) > Consistently a leak. If it's an occasional reported leak (especially in the first or last of the reported runs) or a mixture of positive and negative numbers, it's more likely it's an effect of delayed cleanup, for whatever reason. regrtest's -R takes two integers, 'stab' and 'run', for the number of times to run the same test without tracking reference counts (to stabilize caching effects) and the number of times to run the test while tracking reference counts. Some tests don't stabilize as easily as others, for example because the actual workload or timings rely on external sources. '2, 0, 0' and '0, 0, 4' are probably not leaks, but if you're worried you can run them with larger 'stab' and 'run' to see if they stabilize, or a smaller 'stab' to see if they just have unreliable refcount effects. The easiest way to debug these things is to reduce the test until it has no net refcount effect, then look at the last thing you removed :) -- Thomas Wouters Hi! I'm an email virus! Think twice before sending your email to help me spread! ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pep8 reasoning
On Thu, Apr 24, 2014 at 4:59 PM, Barry Warsaw wrote: > I will say this: the original preference for underscore_names in PEP 8 was > spurred by user studies some of our early non-native English speaking users > conducted many years ago. We learned that it was more difficult for many of > them to parse mixedCase names than underscore_names. I'm afraid I probably no > longer have references to those studies, but the difference was pronounced, > IIRC, and I think it's easy to see why. Underscores can be scanned by the eye > as spaces, while I'd hypothesize that the brain has to do more work to read > mixedCase names. I speak two languages as mother tongues - English and Hebrew. Hebrew has no capital letters (and is also right-to-left) and is the spoken and written language in the parts of Israel where I've lived most of my life. Perhaps because of this, I do find that capital letters don't quite "jump out" for me and therefore I find mixedCase and CamelCase harder to grok at a quick glance than under_score_names. - Tal ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pep8 reasoning
On Wed, Apr 23, 2014 at 11:48 PM, Chris Withers wrote:
> Apologies if this is considered off topic, but I'm keen to get the
> "language designers" point of view and short of emailing Barry, Guido and
> Nick directly, this seemed like the best place.
>
> I'm having a tough time persuading some people of the benefits of pep8,
> particularly when it comes to applying to an existing large code base.
>
I guess you're not in a position of power or authority there? :-)
> The biggest sticking point is naming, particularly as it's the one thing
> that can't necessarily be changed module by module. What were the
> compelling reasons to go from mixedCase to underscore_separated? What's
> considered the best approach for migrating from the former to the latter?
>
Changing method names is always very painful. E.g. it took us forever to
make threading.py compliant with the PEP. What we did there is to keep all
the old method names (as aliases). E.g. search threading.py for notify_all
and notifyAll. Then compare how this is done in Python 2.7 vs. 3.4.
Eventually the old names will be summarily removed.
Why we did this? Before I wrote PEP 8 people were using different
conventions and I (perhaps foolishly) didn't want to declare half of the
modules out of style, so the original PEP 8 (and my style guide that
predated it) allowed either. But eventually we got agreement on what style
we preferred, so we took out the "you can name modules and methods either
way."
> A couple of others that have raised some consternation; what are the
> technical reasons for this pattern being bad:
>
> if len(seq)
> if not len(seq)
>
> Some user-defined data types have an expensive __len__() (e.g. when you
have to count the items one by one) while __bool__() can be more efficient.
> ...or, for me, the rather ugly:
>
> if 0 != len(seq)
>
I know several engineering teams whose style prefers this, but personally I
hate it with a vengeance -- it always makes me jump when trying to
understand code written like that. In math on a blackboard you would never
write this (unless as the result of a simplification of a more complex
equation). Also, try to read it out loud -- it sounds awful. (The reason
people write this doesn't really apply in Python anyway -- it comes from a
desire to avoid the bug in C where you write
if (x = 42) { ... }
instead of
if (x == 42) { ... }
But the Python equivalent of the former is invalid syntactically in Python
anyway.
> Likewise, these:
>
> if greeting == True:
> if greeting is True:
>
Both these consider as falsey many values that are actually considered
truthy by convention (e.g. non-zero numbers, non-empty
sequences/containers).
> Please don't misunderstand me: I dislike the above intensely, but it's an
> emotional response based on 10-15 years of doing things the other way. I'm
> interested in arguments that don't include things like "it's pythonic"
> (which some people consider a derogatory term ;-)), or "just because", I
> trust that the stuff in pep8 was done with specific reasoning in mind, but
> I'm feeling rather useless at giving that reasoning and I'm hoping you can
> help :-)
>
> cheers,
>
> Chris
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> guido%40python.org
>
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pep8 reasoning
On Thu, Apr 24, 2014 at 7:11 AM, Skip Montanaro wrote: > On Thu, Apr 24, 2014 at 8:59 AM, Barry Warsaw wrote: > > I will say this: the original preference for underscore_names in PEP 8 > was > > spurred by user studies some of our early non-native English speaking > users > > conducted many years ago. We learned that it was more difficult for > many of > > them to parse mixedCase names than underscore_names. I'm afraid I > probably no > > longer have references to those studies, but the difference was > pronounced, > > IIRC, and I think it's easy to see why. Underscores can be scanned by > the eye > > as spaces, while I'd hypothesize that the brain has to do more work to > read > > mixedCase names. > > Given Guido's background, I suspect these studies might have been done > at CWI in the context of the ABC language. I'm sorry, I have no recollection of such studies. (ABC used case differently anyway, so camelcase wasn't possible there -- and neither were underscores). Barry maybe referring to a more informal survey of feedback from Python users at the time. But I have no recollection of that either. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pep8 reasoning
One added note: >> if greeting == True: >> if greeting is True: > > This one is based on the preference for identity checks when singletons are > involved, rather than equality tests. Being composed of English words, the > latter is also more readable. It's the same reason why you would do identity > checks against None or enum values. There is more to it that that -- == can be overridden for a particular class. So doing: X == None Could yield surprising results if __eq__ has been defined for the class X is bound to at the moment. Numpy arrays are a common case for me. As None is often used to mean undefined, X could be any type. Granted, in your code, you likely know what type(s) X is likely to be, but it's a good habit to get in to. -Chris > >> Please don't misunderstand me: I dislike the above intensely, but it's an >> emotional response based on 10-15 years of doing things the other way. I'm >> interested in arguments that don't include things like "it's pythonic" (which >> some people consider a derogatory term ;-)), or "just because", I trust that >> the stuff in pep8 was done with specific reasoning in mind, but I'm feeling >> rather useless at giving that reasoning and I'm hoping you can help :-) > > I hope those explanations give you the basis for why the choices were made. > They aren't arbitrary, although folks can and do disagree. It's much more > important that your project comes up with its own guidelines and applies them > self-consistently. For example, I have my own small set of refinements on top > of PEP 8. I'm not providing a link because they're a bit out of date > w.r.t. Python 3. ;) > > Cheers, > -Barry > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/chris.barker%40noaa.gov ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pep8 reasoning
On Thu, Apr 24, 2014 at 11:59 PM, Barry Warsaw wrote: > I will say this: the original preference for underscore_names in PEP 8 was > spurred by user studies some of our early non-native English speaking users > conducted many years ago. We learned that it was more difficult for many of > them to parse mixedCase names than underscore_names. I'm afraid I probably no > longer have references to those studies, but the difference was pronounced, > IIRC, and I think it's easy to see why. Underscores can be scanned by the eye > as spaces, while I'd hypothesize that the brain has to do more work to read > mixedCase names. Underscores also play much more nicely with initialisms. How would you spell a function named "Add HTTP Header"? add_HTTP_header add_http_header addHTTPHeader addHttpHeader Four options to choose from. The first two clearly separate the initialism from the other words; take your pick whether you want it uppercased or not, because it's separated either way. In mixedCase, the first one merges the H of Header in with HTTP; with something less well known, that can be a nasty readability problem. The second one is probably more readable, but looks weird. Or, here's another one: converting one thing into another, where both are named by their initials: convert_XML_to_JSON convert_xml_to_json convertXMLToJSON convertXmlToJson Same four options. Which is the more readable? ChrisA ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pep8 reasoning
There's been a bit of serious study on this. The results are still open to interpretation, though ;-) Here's a nice summary: http://whathecode.wordpress.com/2011/02/10/camelcase-vs-underscores-scientific-showdown/ of-course-dashes-are-most-natural-ly y'rs - tim On Thu, Apr 24, 2014 at 11:25 AM, Chris Angelico wrote: > On Thu, Apr 24, 2014 at 11:59 PM, Barry Warsaw wrote: >> I will say this: the original preference for underscore_names in PEP 8 was >> spurred by user studies some of our early non-native English speaking users >> conducted many years ago. We learned that it was more difficult for many of >> them to parse mixedCase names than underscore_names. I'm afraid I probably >> no >> longer have references to those studies, but the difference was pronounced, >> IIRC, and I think it's easy to see why. Underscores can be scanned by the >> eye >> as spaces, while I'd hypothesize that the brain has to do more work to read >> mixedCase names. > > Underscores also play much more nicely with initialisms. How would you > spell a function named "Add HTTP Header"? > > add_HTTP_header > add_http_header > > addHTTPHeader > addHttpHeader > > Four options to choose from. The first two clearly separate the > initialism from the other words; take your pick whether you want it > uppercased or not, because it's separated either way. In mixedCase, > the first one merges the H of Header in with HTTP; with something less > well known, that can be a nasty readability problem. The second one is > probably more readable, but looks weird. Or, here's another one: > converting one thing into another, where both are named by their > initials: > > convert_XML_to_JSON > convert_xml_to_json > > convertXMLToJSON > convertXmlToJson > > Same four options. Which is the more readable? > > ChrisA > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/tim.peters%40gmail.com ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] List vs Tuple / Homogeneous vs Heterogeneous / Mutable vs Immutable
Ooops, Forgot "reply all" last time -- here it is again. On Wed, Apr 23, 2014 at 3:17 PM, Chris Barker wrote: > On Mon, Apr 21, 2014 at 11:39 PM, Raymond Hettinger < > [email protected]> wrote: > >> In fact, the distinction is extrinsic to their implementations. It is >> only important >> because the rest of the language tends to treat them differently. For >> example, >> you could store ['raymond', 'red'] as a list or as a tuple ('raymond', >> 'red'), but you >> wouldn't be punished until later when you tried: >> >> 'I think %s likes %s' % container # str.__mod__ treats lists and >> tuples differently >> > > I've been bitten by that a lot -- I always wondered why that didn't work > with any sequence. like "tuple unpacking", which is really sequence > unpacking: > > x, y = [3,4] > > But anyway, when I teach Python, I do struggle with this issue -- I tend > to give the explanation of "structs" vs. "homogenous sequences", but I feel > like I am repeating a party line, rather than anything useful. What I do > is: > > If it needs to be immutable (dict key), then use a tuple > If it needs to be mutable, then use a list > > Otherwise, you can use either, but I tend to use a tuple for small things > I don't need to mutate, regardless of whether they are homogenous or not -- > it makes me feel better to get the perception of a *tiny* bit more > efficiency. > > And sometimes you want to mutate small collections of inhomogeneous values > (C sructs are mutable, after all). > > So I don't think this needs to be codified this in the docs anywhere. > > >> Likewise, there seems to be wide-spread confusion about make makes an >> object immutable. People seem to miss that ints, tuples, None and str are >> immutable only because they lack any mutating methods, >> > > not sure your point here -- that under the hood one could mutate them with > C code? > -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [email protected] ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pep8 reasoning
> -Original Message- > From: Python-Dev [mailto:python-dev- > [email protected]] On Behalf Of Chris Withers > Sent: 24. apríl 2014 07:18 > To: Python-Dev > Subject: [Python-Dev] pep8 reasoning > The biggest sticking point is naming, particularly as it's the one thing that > can't > necessarily be changed module by module. What were the compelling > reasons to go from mixedCase to underscore_separated? What's considered > the best approach for migrating from the former to the latter? I doubt that it was the original motivation, but there have been evidence of late suggesting that snake-case is in fact _better_ than CamelCase. See for instance http://www.cs.kent.edu/~jmaletic/papers/ICPC2010-CamelCaseUnderScoreClouds.pdf Science! K ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Import java classes from python
Hi, I am new to python. I have a requirement to import java class from python. Is there any possibility to import java class from python. -- View this message in context: http://python.6.x6.nabble.com/Import-java-classes-from-python-tp5054707.html Sent from the Python - python-dev mailing list archive at Nabble.com. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Import java classes from python
On Thu Apr 24 2014 at 1:10:39 PM, babu wrote: > Hi, I am new to python. I have a requirement to import java class from > python. Is there any possibility to import java class from python. > This list is for the development *of* Python, not the *use* of Python. But to quickly answer your question you want to look at Jython. -Brett > > > > -- > View this message in context: http://python.6.x6.nabble.com/ > Import-java-classes-from-python-tp5054707.html > Sent from the Python - python-dev mailing list archive at Nabble.com. > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ > brett%40python.org > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pep8 reasoning
On Apr 24, 2014, at 06:51 PM, Tal Einat wrote: >I speak two languages as mother tongues - English and Hebrew. Hebrew >has no capital letters (and is also right-to-left) and is the spoken >and written language in the parts of Israel where I've lived most of >my life. Perhaps because of this, I do find that capital letters don't >quite "jump out" for me and therefore I find mixedCase and CamelCase >harder to grok at a quick glance than under_score_names. I was musing at Pycon with others about how Go would handle identifiers in languages that don't have capital letters, such as Hebrew, given the fact that they use the case of the first letter to control identifier visibility. Their FAQ essentially punts on the issue (start your identifier with a letter that can be capitalized, e.g. X日本語) but says that this feature will likely stay. I guess it's Go's flavor of Python's whitespace rule. :) -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pep8 reasoning
Fortunately, Unicode provides us with the COMBINING LOW LINE character, combining the horizontal space-savings of camelCase with the underscore-indicates-separation properties of _. And it's a valid Python identifier. convertx̲mlt̲oj̲son On Thu, Apr 24, 2014 at 12:25 PM, Chris Angelico wrote: > On Thu, Apr 24, 2014 at 11:59 PM, Barry Warsaw wrote: >> I will say this: the original preference for underscore_names in PEP 8 was >> spurred by user studies some of our early non-native English speaking users >> conducted many years ago. We learned that it was more difficult for many of >> them to parse mixedCase names than underscore_names. I'm afraid I probably >> no >> longer have references to those studies, but the difference was pronounced, >> IIRC, and I think it's easy to see why. Underscores can be scanned by the >> eye >> as spaces, while I'd hypothesize that the brain has to do more work to read >> mixedCase names. > > Underscores also play much more nicely with initialisms. How would you > spell a function named "Add HTTP Header"? > > add_HTTP_header > add_http_header > > addHTTPHeader > addHttpHeader > > Four options to choose from. The first two clearly separate the > initialism from the other words; take your pick whether you want it > uppercased or not, because it's separated either way. In mixedCase, > the first one merges the H of Header in with HTTP; with something less > well known, that can be a nasty readability problem. The second one is > probably more readable, but looks weird. Or, here's another one: > converting one thing into another, where both are named by their > initials: > > convert_XML_to_JSON > convert_xml_to_json > > convertXMLToJSON > convertXmlToJson > > Same four options. Which is the more readable? > > ChrisA > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/dholth%40gmail.com ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] static typing of input arguments in signatures
On Apr 19, 2014, at 11:05 AM, Ethan Furman wrote: > Personal experience: I have my own copy of paramiko because it type checks > for strings, and I routinely use a str-subclass. I have had that kind of problem myself in the past. Most of the time the core issue wasn’t type checking, it was how (badly) it was implemented. `assert obj.__class__ == list` being my favorite one (especially when any iterable would work just fine). -- Best regards, Łukasz Langa WWW: http://lukasz.langa.pl/ Twitter: @llanga IRC: ambv on #python-dev ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ref leaks
On Thu, 24 Apr 2014 17:17:41 +0200, Stefan Krah wrote: > Ethan Furman wrote: > > >>Any words of wisdom for tracking those leaks? > > Often the easiest way is to compile --with-valgrind and run the test > under Valgrind (obviously). > > In the Valgrind output, search for "definitely lost" and ignore the rest. > > If that does not turn up anything, consider a bug in regrtest.py: > > It happens that certain caches are initialized incrementally in each > repetition of the test, so the reported leaks are spurious. That is > why some caches like small integers are "warmed up" in regrtest.py. > > Perhaps there is some recently added cache that needs attention. Note that if you do find a "real" leak, I would start with the assumption that any leak is a leak at the python level (eg: a python cache or an possibly-accidentally-persistent data structure) and only move to the C level once I'd ruled out a python source for the "leak". Unless you are dealing with a wholly or primarily C module, of course :) --David ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pep8 reasoning
On 4/24/2014 12:36 PM, Tim Peters wrote: There's been a bit of serious study on this. The results are still open to interpretation, though ;-) Here's a nice summary: http://whathecode.wordpress.com/2011/02/10/camelcase-vs-underscores-scientific-showdown/ The linked poll is almost evenly split, 52% to 48% for camel case with over 2000 votes each. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pep8 reasoning
[Tim] >> There's been a bit of serious study on this. The results are still >> open to interpretation, though ;-) Here's a nice summary: >> >> >> http://whathecode.wordpress.com/2011/02/10/camelcase-vs-underscores-scientific-showdown/ [Terry Reedy] > The linked poll is almost evenly split, 52% to 48% for camel case with over > 2000 votes each. There are two polls in the post. You're referring to the first, which the author asked viewers to fill out before reading any of the "evidence". There's another poll at the end, which the author asked viewers to fill out after reading the whole post. In that poll, preference changed (56% to 44% in favor of underscore). A followup post summarized later research, confirming the earlier result that CamelCase'd names are harder to read (as measured by eye tracking studies): http://whathecode.wordpress.com/2013/02/16/camelcase-vs-underscores-revisited/ but-all-obvious-a-priori-to-the-most-casual-observer-ly y'rs - tim ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pep8 reasoning
On 4/24/2014 11:01 AM, Daniel Holth wrote: Fortunately, Unicode provides us with the COMBINING LOW LINE character, combining the horizontal space-savings of camelCase with the underscore-indicates-separation properties of _. And it's a valid Python identifier. convertx̲mlt̲oj̲son That should be convertX̲MLt̲oJ̲SON of course :) :) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pep8 reasoning
On Thu, Apr 24, 2014 at 11:36:03AM -0500, Tim Peters wrote: > There's been a bit of serious study on this. The results are still > open to interpretation, though ;-) Here's a nice summary: > > http://whathecode.wordpress.com/2011/02/10/camelcase-vs-underscores-scientific-showdown/ To summarize the key points of the two papers referenced in this thread: Blinky 2009: Participants were trained in camelCase. camelCase was 13.5% slower, 51.5% more accurate on an identifying task. Sharif 2010: Participants were trained in underscores. Same accuracy, camelCase was 20% slower. It seems like, generalizing, camelCase is slower and more accurate, while training affects both speed and accuracy. But, really, there is no compelling scientific argument here. It really boils down to CONSISTENCY: 1) If the existing code uses one or the other, follow the original code to preserve CONSISTENCY. 2) If you're starting a new project, follow PEP8 (or the standards for the language you're using) to preserve CONSISTENCY. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pep8 reasoning
On Fri, Apr 25, 2014 at 11:40 AM, Allen Li wrote: > 2) If you're starting a new project, follow PEP8 (or the standards for >the language you're using) to preserve CONSISTENCY. Don't forget that PEP 8 is not the standard for the Python language, only the Python stdlib. Particularly, there's no strong reason to follow some of its lesser advices (eg spaces rather than tabs, the exact maximum line length) for new projects; if all your developers have good quality screens, there's no point wrapping all your code to 79 just because the Python standard library is wrapped to 79. That particular example is touched on in the PEP itself (suggesting 20 more characters); you could easily set a maximum of 89, 99, or 159 characters if it makes sense for your project. Consistency with the standard library in names is slightly more useful, but the standard library isn't perfectly consistent itself (eg not all class names start with a capital), and if you're spending too much time arguing about style instead of getting code written, your style guide isn't doing its job :) ChrisA ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pep8 reasoning
On Apr 25, 2014, at 12:00 PM, Chris Angelico wrote: >Don't forget that PEP 8 is not the standard for the Python language, >only the Python stdlib. Particularly, there's no strong reason to >follow some of its lesser advices (eg spaces rather than tabs, the >exact maximum line length) for new projects; I'd say it depends. If the code is going to be shared with people outside of your organization (e.g. open source libraries), then there's a strong motivation to be consistent throughout the community, which means PEP 8. -Barry ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pep8 reasoning
Chris Angelico wrote: add_HTTP_header add_http_header addHTTPHeader addHttpHeader Five... there are FIVE options... convertXMLtoJSON i.e. don't capitalise a part that follows capitalised initials. -- Greg ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pep8 reasoning
On Apr 24, 2014 7:01 PM, "Chris Angelico" wrote: > > On Fri, Apr 25, 2014 at 11:40 AM, Allen Li wrote: > > 2) If you're starting a new project, follow PEP8 (or the standards for > >the language you're using) to preserve CONSISTENCY. > > Don't forget that PEP 8 is not the standard for the Python language, > only the Python stdlib. That is not true. It is mandatory for the stdlib, for other projects it is optional, but still recommend. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pep8 reasoning
On Thu, Apr 24, 2014 at 01:57:38PM +0100, Tim Golden wrote: > On 24/04/2014 12:59, Tal Einat wrote: > > As far as I know that reason for these examples being frowned upon is > > that they are needlessly redundant. > > Oh, the irony! (Sorry, couldn't resist) Not really ironic, since not all redundancy is needless. Useful redundancy: an emergency backup chute; if your main parachute fails to release, you have a backup. RAID. Backups in general. There's a lot of redundancy in human language in general, which makes it possible to understand speech even in noisy enviroments. Needless redundancy: a double-headed spoon, in case the first bowl disintegrates in your soup, just turn the spoon around and use the spare. Or the abuse of Hungarian Notation perpetrated by the Windows development team. http://www.joelonsoftware.com/articles/Wrong.html One mild but legitimate criticism of Python's significant indentation feature is that it loses some useful redundancy: you can reconstruct the indentation from the braces, or the braces from the indentation, but if you only have one, and it gets lost in transmission, you're screwed. (The lesson of this, as far as I am concerned, is "Don't transmit source code through noisy channels that delete parts of your code.") -- Steven ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
