Suggested coding style

[Passiday]

Hello,

I have started to code random stuff in Python only recently, still
lots to learn. So please bear with me if my question sounds like rant.

I have been coding in many other languages, most of the time it was
Java and C#. I don't like the function mess of PHP (ie, loads and
loads of functions without any namespaces etc), but I'd like to think
that Python is different.

In my brief coding experience I have stumbled upon Python zfill(width)
method, and I thought, really, do you have to include such a narrow-
purpose method in the basic method set? Perhaps there are more such
methods that are nice when you need them, but then again, you don't
put all the possible methods in the standard set.

Perhaps there is reason such method is in the basic library, and my
complaints are unbased? Or, perhaps the language is on course to bloat
out and get filled with tens and hundreds of special-purpose methods
that render the language structure chaotic?

Passiday

 

[MRAB]

Hello,

I have started to code random stuff in Python only recently, still
lots to learn. So please bear with me if my question sounds like rant.

I have been coding in many other languages, most of the time it was
Java and C#. I don't like the function mess of PHP (ie, loads and
loads of functions without any namespaces etc), but I'd like to think
that Python is different.

In my brief coding experience I have stumbled upon Python zfill(width)
method, and I thought, really, do you have to include such a narrow-
purpose method in the basic method set? Perhaps there are more such
methods that are nice when you need them, but then again, you don't
put all the possible methods in the standard set.

Perhaps there is reason such method is in the basic library, and my
complaints are unbased? Or, perhaps the language is on course to bloat
out and get filled with tens and hundreds of special-purpose methods
that render the language structure chaotic?

Considering that Python has been around for 20 years, there's not much
bloat. Most of the risk of that was early on, when any interest in the
language might have been welcomed. Now that its use has grown, it can
be more choosy.

..zfill does have its uses:
'-001'

 

[Tim Johnson]

I have been coding in many other languages, most of the time it was
Java and C#. I don't like the function mess of PHP (ie, loads and
loads of functions without any namespaces etc), but I'd like to think
that Python is different.

It is ...

In my brief coding experience I have stumbled upon Python zfill(width)
method, and I thought, really, do you have to include such a narrow-
purpose method in the basic method set? Perhaps there are more such
methods that are nice when you need them, but then again, you don't
put all the possible methods in the standard set.

I think that you have raised an interesting question here. I've
been coding in python for 9 years and I have never used it.

Perhaps there is reason such method is in the basic library, and my
complaints are unbased?

It could be some sort of legacy. I imagine we will hear from some
more senior pythonists on this matter.

Or, perhaps the language is on course to bloat
out and get filled with tens and hundreds of special-purpose methods
that render the language structure chaotic?

From my observance, python has developed with care and prudence. I
have a feeling (instinctive of course), that Guido van Rossum
is/was more likely to say 'no' to a request for a new
implementation that Rasmus Lerdorf.

MTCW

 

[MRAB]

It is ...

I think that you have raised an interesting question here. I've
been coding in python for 9 years and I have never used it.


It could be some sort of legacy. I imagine we will hear from some
more senior pythonists on this matter.

The documentation says "New in version 2.2.2".

 

[Arnaud Delobelle]

In my brief coding experience I have stumbled upon Python zfill(width)
method,

[...]
  It could be some sort of legacy. I imagine we will hear from some
  more senior pythonists on this matter.

The documentation says "New in version 2.2.2".

But zfill has been in the string module for a lot longer.

 

[Tim Johnson]

In my brief coding experience I have stumbled upon Python zfill(width)
method, [...]
  It could be some sort of legacy. I imagine we will hear from some
  more senior pythonists on this matter.

The documentation says "New in version 2.2.2".

But zfill has been in the string module for a lot longer.

Like I said. See timestamp.
http://mail.python.org/pipermail/python-bugs-list/1999-July/000035.html
I was coding C/C++ and ASM back then....

 

[Steven D'Aprano]

The documentation says "New in version 2.2.2".

Which is about nine years old, so roughly half as old as Python itself.
It's hardly a new feature.

Just because Passiday and Tim don't use zfill doesn't mean it's not useful
to some people. Here are examples of it in use, or people asking how to
format numbers with leading zeroes:

http://www.ruby-forum.com/topic/67378
http://stackoverflow.com/questions/134934/display-number-with-leading-zeros
http://stackoverflow.com/questions/733454/best-way-to-format-integer-as-string-with-leading-zeros
http://msdn.microsoft.com/en-us/library/dd260048.aspx
http://www.ozgrid.com/forum/showthread.php?t=64193&page=1

http://www.google.com/codesearch#al....py&q=lang:^python$ zfill case:yes&ct=rc&cd=7

http://www.google.com/codesearch#Wn...cLwTg/desub.py&q=lang:^python$ zfill case:yes

Padding numbers with leading zeroes is very common. I'm surprised that
more languages don't make it a string method.

 

[Devin Jeanpierre]

Padding numbers with leading zeroes is very common. I'm surprised that

more languages don't make it a string method.

By making it a string method, instead of a function, we force all
implementations of strings to implement that method. That sort of
sucks, and it's a reason not to include it as a method. It can, after
all, be implemented as a function, and in doing so (with the
appropriate operator overloading) that function could work with
multiple implementations of strings. Instead any implementation of a
string must implement that method. That's a waste.

Of course, one could argue that there are very few string
implementations. On the other hand, there were three in the stdlib in
2.x, and there are other concepts of strings (like ropes) that are
more efficient for different use-cases. The third string in the stdlib,
mmap, didn't even bother implementing the full string interface. It's
just so damned big. (Also some methods didn't apply, like zfill, but
hey!)

At the very least, it's sort of ugly from my perspective to tack on
trivial things like this to be string methods.

But sure, yeah, as a bonus you get to do fewer imports. That's pretty
great too, I guess.

Devin

* Passiday<[email protected]>  [110924 09:47]:
<...>
I have been coding in many other languages, most of the time it was
Java and C#. I don't like the function mess of PHP (ie, loads and
loads of functions without any namespaces etc), but I'd like to think
that Python is different.
   It is ...

In my brief coding experience I have stumbled upon Python zfill(width)
method, and I thought, really, do you have to include such a narrow-
purpose method in the basic method set? Perhaps there are more such
methods that are nice when you need them, but then again, you don't
put all the possible methods in the standard set.
   I think that you have raised an interesting question here.I've
   been coding in python for 9 years and I have never used it..

Perhaps there is reason such method is in the basic library, and my
complaints are unbased?

   It could be some sort of legacy. I imagine we will hear from some
   more senior pythonists on this matter.

The documentation says "New in version 2.2.2".

Which is about nine years old, so roughly half as old as Python itself.
It's hardly a new feature.

Just because Passiday and Tim don't use zfill doesn't mean it's not useful
to some people. Here are examples of it in use, or people asking how to
format numbers with leading zeroes:

http://www.ruby-forum.com/topic/67378
http://stackoverflow.com/questions/134934/display-number-with-leading-zeros
http://stackoverflow.com/questions/733454/best-way-to-format-integer-as-string-with-leading-zeros
http://msdn.microsoft.com/en-us/library/dd260048.aspx
http://www.ozgrid.com/forum/showthread.php?t=64193&page=1

http://www.google.com/codesearch#al....py&q=lang:^python$ zfill case:yes&ct=rc&cd=7

http://www.google.com/codesearch#Wn...cLwTg/desub.py&q=lang:^python$ zfill case:yes

Padding numbers with leading zeroes is very common. I'm surprised that
more languages don't make it a string method.

 

[Tim Johnson]

By making it a string method, instead of a function, we force all
implementations of strings to implement that method. That sort of
sucks, and it's a reason not to include it as a method.

Why does it suck? And why do people say 'suck' so much, especially
in technical venues?
Just answer the first question, the second is rhetorical. I
think that your answer, regardless of whether I agree with it may
edify me serendipitously.

It can, after all, be implemented as a function, and in doing so
(with the appropriate operator overloading) that function could
work with multiple implementations of strings. Instead any
implementation of a string must implement that method. That's a
waste.

I'm not sure what you mean. I've written my own `split' function. I
don't believe that there would be any conflict if you wrote your
own `zfill' function. Or if there would be, I'd want to know before
I hurt myself.

regards

 

[Petite Abeille]

Why does it suck? And why do people say 'suck' so much, especially in technical venues?

It's a technical term:

http://www.osnews.com/images/comics/wtfm.jpg

 

[Chris Angelico]

It's a technical term:

http://www.osnews.com/images/comics/wtfm.jpg

Also, because technical people are opinionated windbags. Goes with the
territory. Actually, it's partly because it's so easy to create
standards. You don't like X? Create your own language in which it
doesn't exist! You absolutely detest Y? Ignore it and use something
else! But since we can't ignore _everything_ we dislike, there ends up
a happy medium in which we all use the things that we dislike least,
all the while ranting about those aspects of them that "absolutely,
totally suck", and vowing that we could have done way better if we'd
been in the position of Some Famous Guy back when he had that perfect
opportunity to create a new and perfect standard, but he *blew it* by
having a small and narrow view, etc, etc, etc...

Of course, some of us manage to still be courteous and objective when
discussing the things that suck, while others just go off on lengthy
rants. And if you're willing to learn, it's not uncommon to start off
complaining and end up appreciating.

Chris Angelico

 

[Devin Jeanpierre]

Why does it suck?

The gist of what I was saying is that it's possible to define
functions that do this "generically" so that one implementation of
zfill can work with multiple implementations of strings. Having to
reimplement every time when one implementation would do is bothersome
and generally isn't done unless it has to be (thus why mmap lacks a
zfill method). Having to do more work than necessary "sucks", as does
having partial str implementations that don't do everything str does.

Ideally, I would claim that if some interface will have multiple
implementations, it should have as few methods as possible to make
implementation as easy as possible, and move as much as possible
_away_ from methods and into functions that work with arbitrary
implementations of the interface. This minimizes the amount of work
that must be done for implementors and thus makes life better.

It's also true that it's "bad practice" to have objects with large
APIs, not for convenience reasons but because it increases object
coupling, something that "good" object oriented design seeks to
eliminate. The idea there is that the less ways you can have your
object interacted with / interact with other objects, the easier it is
to think of the way state flows. I agree with this in principle, but
it doesn't really matter for strings.

The situation I see with something like zfill as-a-method is that it
has nearly negligible benefit (less imports vs function?) and some
detriment. So I would conclude it should not exist. Other people look
at this differently.

 

[MRAB]

The gist of what I was saying is that it's possible to define
functions that do this "generically" so that one implementation of
zfill can work with multiple implementations of strings. Having to
reimplement every time when one implementation would do is bothersome
and generally isn't done unless it has to be (thus why mmap lacks a
zfill method). Having to do more work than necessary "sucks", as does
having partial str implementations that don't do everything str does.

Ideally, I would claim that if some interface will have multiple
implementations, it should have as few methods as possible to make
implementation as easy as possible, and move as much as possible
_away_ from methods and into functions that work with arbitrary
implementations of the interface. This minimizes the amount of work
that must be done for implementors and thus makes life better.

[snip]
I would have thought that a better solution would be to specify a
minimal set of methods in an abstract superclass and write the
additional methods using that minimal set.

The concrete string implementations would be descended from the
superclass and would still be able to override the additional methods
with more efficient code were desired, such as in the 'str' class.

 

[Devin Jeanpierre]

I would have thought that a better solution would be to specify a

minimal set of methods in an abstract superclass and write the
additional methods using that minimal set.

The concrete string implementations would be descended from the
superclass and would still be able to override the additional methods
with more efficient code were desired, such as in the 'str' class.

This does sound better to me too!

Devin

The gist of what I was saying is that it's possible to define
functions that do this "generically" so that one implementation of
zfill can work with multiple implementations of strings. Having to
reimplement every time when one implementation would do is bothersome
and generally isn't done unless it has to be (thus why mmap lacks a
zfill method). Having to do more work than necessary "sucks", as does
having partial str implementations that don't do everything str does.

Ideally, I would claim that if some interface will have multiple
implementations, it should have as few methods as possible to make
implementation as easy as possible, and move as much as possible
_away_ from methods and into functions that work with arbitrary
implementations of the interface. This minimizes the amount of work
that must be done for implementors and thus makes life better.

[snip]
I would have thought that a better solution would be to specify a
minimal set of methods in an abstract superclass and write the
additional methods using that minimal set.

The concrete string implementations would be descended from the
superclass and would still be able to override the additional methods
with more efficient code were desired, such as in the 'str' class.

 

[Chris Angelico]

Pardon?

No offense intended; just look at this list and you'll see how
opinionated people can be, and how willing to express those opinions
in many words! Frank and courteous exchange of views, one of the best
ways to learn about the subject matter... and about the other
programmers too.

ChrisA

 

[Tim Johnson]

The gist of what I was saying is that it's possible to define
functions that do this "generically" so that one implementation of
zfill can work with multiple implementations of strings.

That is kind of 'spot on' for me. Before I started using python, I
worked in rebol - where (at that time), there was a limited number
of function names available because of limited namespacing (and
the binary was a fraction the size of python). So I learned to
take that approach.

Having to
reimplement every time when one implementation would do is bothersome
and generally isn't done unless it has to be (thus why mmap lacks a
zfill method). Having to do more work than necessary "sucks", as does
having partial str implementations that don't do everything str does.

Ideally, I would claim that if some interface will have multiple
implementations, it should have as few methods as possible to make
implementation as easy as possible, and move as much as possible
_away_ from methods and into functions that work with arbitrary
implementations of the interface. This minimizes the amount of work
that must be done for implementors and thus makes life better.

It's also true that it's "bad practice" to have objects with large
APIs, not for convenience reasons but because it increases object
coupling, something that "good" object oriented design seeks to
eliminate. The idea there is that the less ways you can have your
object interacted with / interact with other objects, the easier it is
to think of the way state flows. I agree with this in principle, but
it doesn't really matter for strings.

The situation I see with something like zfill as-a-method is that it
has nearly negligible benefit (less imports vs function?) and some
detriment. So I would conclude it should not exist. Other people look
at this differently.

Good response.
Thank you.

 

[Tim Johnson]

Also, because technical people are opinionated windbags. Goes with the
territory.

I always felt that to be courteous, to the point and reserved cost
me less typing time. And since I'm self-employed and only charge
for productive time for clients, that's being cost-conscious for me.

Of course I've been known to get a little crazy about PHP. So don't
let me get started...

BTW: If you like ranting as a spectator sport, I have found the
Common Lisp newsgroup to be among the most spectacular. But that's
just me.

 

[Chris Angelico]

BTW: If you like ranting as a spectator sport, I have found the
 Common Lisp newsgroup to be among the most spectacular. But that's
 just me.

I do, actually, but I don't need to add another newsgroup. Rick
provides plenty of material here, and I can easily sate myself in just
a few other places that I frequent. It's quite amusing to watch those
holy wars erupt...

And every once in a while, they actually prove quite educative. I'm
not sure how it happens, nor how to trigger it - hmm, perhaps this
should be the subject of a scientific paper. "On ranting newsgroups
and how to make them productive".

ChrisA

 

[DevPlayer]

I do, actually, but I don't need to add another newsgroup. Rick
provides plenty of material here, and I can easily sate myself in just
a few other places that I frequent. It's quite amusing to watch those
holy wars erupt...

And every once in a while, they actually prove quite educative. I'm
not sure how it happens, nor how to trigger it - hmm, perhaps this
should be the subject of a scientific paper. "On ranting newsgroups
and how to make them productive".

ChrisA

I think intellectual growth from rants works like this:

Ranter: Bla bla, bad logic, poor facts, some point.
Others: Bla bla you rant Mr Ranter, some logic, few facts, same point.
Ranter: bad mouthing
Others: bad mouthing back
Ranter: Bla Bla, I don't rant, better logic counter facts, lots of
opinion (to not get called a ranter)
Others: Bla bla, You do rant Ranter, good counter logic and facts,
same point (some reason needs to put Ranter "in his place")
Ranter: Super Bla, long winded logic with some strong points, random
but accurate facts out the wazzu (tries to save face)
Others: Acknowleges Ranters point are accurate but claims they don't
apply
Ranter: makes case his points do.
Others: agrees to disagree, silently picks mute Ranter,
Ranter: picks a new topic and starts over.

 

[DevPlayer]

By the way OP Passiday the title of the topic is "Suggested coding
style".

Are you suggesting a coding style or asking for a Python coding style
or are you asking what IS the Python coding style.

If you are asking what is the Python coding style. Google The Zen of
Python. It's pretty much the dictum of coding style and referred to
alot by many Pythoneers.