Suggested coding style

[rantingrick]

On Sep 29, 5:37 am, Passiday <passi... at gmail.com> wrote:

> Here's a summary of what I take from this longwinded thread:
> Read the Zen of Pthon for some fun:http://www.python.org/dev/peps/pep-0020
> Read the PEP-8 for some good guidelines:http://www.python.org/dev/peps/pep-0008

That's the point of all this, yes. You see, around here, once the
point is made there is an unwritten rule that the thread must then
descend into chaos. However, it seems you "may" have brought this
train wreck back to reality below... whether the trolls will allow
that happen remains to be seen...?

> My topic was "Suggested coding style" because I hoped
> there is some common understanding which of the ancient
> methods/functions are so not where they should be that the
> use of them should be depreciated.

I agree. Whilst zfill is useful, and probably should be a part of the
stlib somewhere, the string module is no place for it. The only way
zfill WOULD work as a string method is if it were changed to accept a
user defined fill char. Even then i don't like it as a string method;
too specific!

A specific method for padding a string with ONLY zeros is ludicrous
and exposes the narrow mindedness of the creator. The only thing worse
than "zfill" as a string method is making zfill into built-in
function! The ONLY proper place for zfill is as an option in the
str.format() method.

py> "{0:zf10}".format(1234) -> "00000000001234"

When are they going to see that I am the best API designer this
community has ever had the privilege to work with! GvR should be
texting me every night in hopes that some of my API genius will rub
off on him.

> I can fully understand
> that when the language evolves, it might implement some
> ugly methods. Perhaps it was some quick itching need to
> format some numbers that drove some antique Python
> programmer so mad that he decided this belongs to the
> string class, instead of some number/date/string
> formatting class that attempts to build on existing well
> established standards. And so, the str.zfill() was born.

zfills foster home placement is akin to the missing Path object we
still don't have. Both are a result of poor planning. Now zfill is
like some red headed step child that nobody wants, but nobody has the
balls to return the abortion to it's rightful place.

> But I'd expect that there exists some leadership who are
> brave enough to admit some bad decisions and lead the
> people by announcing that using certain methods is "bad
> style".

Ha! I would not hold my breath waiting for "leadership" to admit wrong
doings; these people think they are beyond reproach.

> No need to take them out of the implementation,
> that might unnecessary break some code in obscure places.

What is so bad about breaking code in obscure places? We changed print
to a function which broke just about every piece of code every written
in this language. (BTW, print should ALWAYS have been a function!)
What is so bad then about breaking some very obscure code? We could
always have a lengthy deprecation period.

> However, guiding programmers for better coding practice
> and avoid ugly bloating of nice scripting language should
> be considered a holy (please don't rant on use of this
> word) mission.

I agree. I think you'll agree also with me in the fact that Mr Van
Rossum has created the cleanest, most simplistically elegant, and no
nonsense language this world has ever seen. However. He is not immune
to the wicked influence of a few high ranking people within this
community who have "hidden agendas" and want to mutate Python into a
clone of some other nasty languages.

I believe GvR had a "mid-dev-crisis" and realized the err of his ways.
He attempted to turn back the clock with Python 3000, HOWEVER he did
not go far enough! Much more cleanup is in order to get this language
back on track to what it should be, and COULD be!