One way of doing things.

[nevdelap]

Hi Chuck,

As you know the Zen of Python says "There should be one-- and preferably only one --obvious way to do it.", but is applied pragmatically and certainly not even always. I'm pretty maniacal for both consistency and simplicity and enforced by the compiler is (almost) always good in my book, and Cobra does loads already in this regard.

But a trivial example is that 0xabc, 0xABC, and 0aBc are all allowed in Cobra (& in Python) and I'd like to see only one allowed.*

The example is secondary, the focus of this post is the question: What is the Cobra philosophy on "one way of doing things"?

Nev

* I've known and know programmers who would even mix the casing in a single file and see nothing odd about it if I ranted at them - and equally dumb things.

[Charles]

Yeah, I'm also annoyed by "random casing" where every other local var is capped; where some methods are foobar vs. foo_bar vs. fooBar, etc. Cobra does indeed go a long way to tighten that up compared to other languages.

But you've also hit upon a pet peeve of mine. It's the propagation of the myth that in Python, there is one way to do it. This is wrong, but gets repeated throughout the community. Here are examples showing > 1 to do things:

Code: Select all

# Make a list
# (1)
t = [7, 6, 5, 4, 3, 2, 1]
# (2)
t = range(7, 0, -1)

# Print the elements
# (1)
for x in t: print x
# (2)
for x in t:
    print x

# Double the elements
# (1)
for i in range(len(t)): t[i] *= 2
# (2)
for i in range(len(t)): t[i] << 1
# (3)
t = [x*2 for x in t]
# (4)
t = [x<<1 for x in t]

# Sort the elements
# (1)
t.sort()
# (2)
t = sorted(t)


I used to have more examples, but they are fading from memory as I focus more on Cobra.

Most languages, perhaps all of them, and including Python, have more than one way to do things. And even if you have clear preferences in each of those cases--what you would consider "obvious"--does not mean that your set of preferences is going to match everyone else in the community.

Cobra's first emphasis is to maximize and balance the major concerns of fast coding, fast execution, maintainability and quality control. Certainly I don't want to have many ways to do obvious things, but I'm not going to pretend that we've actually got it down to "one obvious way" either.

Regarding hex numbers, I don't have a strong inclination to make a change here. If I did, it would be to lower case. How do others feel?

[hopscc]

Dont care.
I typically use only a single case (upper) for hex numbers anyway but thats just an old consideration that they delineate better that way.

Re the specific example: Theres a few other old issues in this area - underscores and (non) support for binary and octal literals (ticket:29)

[nevdelap]

Thanks for you answers.

I put in the "and is applied pragmatically" to deliberately mean it doesn't really only have one way of doing things, but it leans strongly in that direction.

Certainly the difference in philosophy between Python and Perl for example is a strong one, and having written a fair bit of Perl before discovering Python seven or eight years ago I never write another line of Perl because it is intrinsically messy - the opposite of both Python and Cobra.

In the hex example there are two ways of doing something that are effectively identical and trivial to enforce. When hopscc supplied the patch for hex literals you said...

"So the prefix is a zero digit followed by the letter 'x', 'o' or 'b'. Always lower case. Give a nice error message if upper case is used."

The rest of the hex literal can benefit from the same consistency.

But the general philosophy was the question. So cheers!