[Baypiggies] Assuming NoPython is good criticism. (Rant)

[Charles Merriam]

> http://bitcheese.net/wiki/nopython

Well formed criticism is a great thing!  Let's avoid the dog pile of
dismissing it.  Python is a great language.  Criticism drives it to be
better.

So:
1.   the calculator problem:
>>> 2.3 - 3.4
-1.1000000000000001

It's not just a display problem.  It's a continuing precision problem.
 I can work around it using the decimal class, yet I fondly remember
working on bare x86 processors and having the guard bits handle
problems.  The usual issue is that I don't care about the last couple
bits of precision, and I expect them to be rounding errors, hence
guard bits.

I was last bit by this problem on Wednesday when a cdf (cummulative
distribution function) blew some asserts:  the probability capped at
1.0 + small_num instead of 1.0.    While the printing hacks in 3.1 fix
this, the documentation made me expect these are __repr__ hacks, not
fixes.

2.  The Indentation Issue

Just get over it.   Everyone does within a week and it is a trade-off
for lower token counts.

3.  self

'self' as a quasi-keyword is a problem, in that it creates verbose
code such as:  "self.a = self.fn(self.b) + self.c".   Dropping the
number of tokens by half would work by just making self a known
keyword and using the bare period instead, e.g.,  ".a = .fn(.b) + .c".
 Purely a syntactic hack dropping a reasonable percentage of tokens.
To me, the code reads much better.

4. 'dunders' naming for meta programming

'dunders' are a legitimate grip as well.   Currently, dunders (double
underscore name double underscore) merely signal that 'this function
is likely to be involved in meta programming'.   It, correctly, allows
new programmers to safely ignore most dunder functions.  Still, there
isn't an easy method to figure out which dunders are in use,
over-ridden, etc.   At a base, there is repr, str, iter, init, new,
cls, etc., etc.   It lets the C++ unstructured knowledge world into
Python.  On top of that, there isn't a standard naming convention for
other meta programming identifiers.  A 'iterByFirstName()' call in
some frameworks will dynamically create a sorted iterator based on
FirstName being a legitimate database field.

I was last bit by this earlier this week, guessing between __repr__
and __str__ for use in my debugger.

4.  Naming Conventions and Lack Thereof:

PEP-8 rambles for a bit before specifying that everything should be
using_lowercase_underscores except for package names and class names.
 Except that most of the standard library breaks these rules.   I
would love to have a rule that throws a warning when you have a second
identifier with the same translate(None, "_-'").lower().   Using
"Mail()" and "mail" is just asking for errors.

And why, why have a different naming convention for package names?

5.  GIL

The GIL does get in the way, for some people at some times.
Exceedingly clear write-ups on the GIL, where it is a problem, and how
to code around the problem, are necessary.  It usually comes down to
manually segmenting code.  Typing "GIL" into the docs search box
should yield a clear write-up.

6.  Unicode

I admit it:  I've never understood the codecs module.   The
documentation just skips why and how to use it and instead goes into
the required handlers.   I have no idea how it deals with broken
unicode.   Python does not hide the borked-ness of The Unicode
Standard from its programmers.

So,

In conclusion, there are issues.   Python should make the life of a
programmer easier and less buggy.  Naming conventions, dunders, self,
and even the default float implementation do get in the way.

Does anyone wish to bet that these will still be criticisms in Python 6.0?

Charles Merriam