Suggested coding style

Tim Johnson tim at
Mon Sep 26 04:55:26 CEST 2011

* Devin Jeanpierre <jeanpierreda at> [110925 16:37]:
> >  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. 

  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 at tee jay forty nine dot com or akwebsoft dot com

More information about the Python-list mailing list