469,356 Members | 1,884 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,356 developers. It's quick & easy.

General question about Python design goals

Sometimes I find myself stumbling over Python issues which have to do
with what I perceive as a lack of orthogonality.

For instance, I just wanted to use the index() method on a tuple which
does not work. It only works on lists and strings, for no obvious
reason. Why not on all sequence types?

Or, another example, the index() method has start and end parameters for
lists and strings. The count() method also has start and end parameters
for strings. But it has no such parameters for lists. Why?

However when I ask such things I noticed I get answers like: "Is there a
use case?" "You can do it some other way so it is not worth bothering."

Let me ask back: Do I really need to bother and justify it with a use
case in a case where the language can be easily made more consistent or
orthogonal without breaking anything?

What about design goals such as:

- orthogonality
- coherence, consistency
- principle of least astonishment ("Python fits my brain")
- simplicity ("kiss" principle)
- aesthetics, symmetry

Actually, which priority have the above design goals for Python? Are
other design goals considered more important?

If I compare them with the "Zen of Python", I find some of the above:

consistency -> Special cases aren't special enough to break the rules
simplicity -> Simple is better than complex
aesthetics -> Beautiful is better than ugly

Actually, concerning the last two, you already need to understand the
Zen of Python to decide if something is "simple" or even "beautiful", so
they are not really suitable to *define* the Zen of Python. For me, a
programming language is beautiful if it is orthogonal and coherent. But
for others, this may be different. Somehow, I'm missing a direct
allusion to the following in the Zen of Python:

- orthogonality
- principle of least astonishment

Maybe I am I lacking the satori of a real Python Zen master?

-- Christoph
Nov 28 '05
105 4703
Donn Cave <do**@u.washington.edu> writes:
There's a historical issue too: when tuples started first being
used this way in Python, classes had not yet been introduced.


When was that, old-timer?


It was before my time, but I have the impression that classes arrived
with 1.3 or somewhere around then. Maybe some of the oldbies here
remember. I started using Python around when 2.1 was released, I think.
Dec 2 '05 #101
"Fredrik Lundh" <fr*****@pythonware.com> writes:
fwiw, the tuple and class implementation were both checked into
CVS in october 1990.

maybe he's talking about ABC?


No I think I'm just plain mistaken. For some reason I thought classes
came much later. It was way before my time so I defer to your wisdom.
Dec 2 '05 #102
Alex Martelli wrote:
Yep -- "time tuples" have also become pseudo-tuples (each element can be
accessed by name as well as by index) a while ago, and I believe there's
one more example besides stats and times (but I can't recall which one).


Apart from time and os.stat all the uses seem to be restricted to Unix
only: pwd, grp and resource modules all use StructSequence, also os.statvfs
and spwd (new in 2.5). Thats from an svn checkout though so there may be
fewer uses in released code.
Dec 2 '05 #103
Donn Cave <do**@u.washington.edu> writes:
In article <86************@bhuda.mired.org>, Mike Meyer <mw*@mired.org>
wrote:
Seriously. Why doesn't this have to be phrased as "for x in list((1,
2, 3))", just like you have to write list((1, 2, 3)).count(1), etc.? How could list(t) work, if for x in t didn't?


Good question.
For me, conceptually, if an object can't be accessed
sequentially, then it can't be mapped to a sequence.
So you're saying that for should implicitly invoke list (or maybe
iter) on any object that it's passed that's not a list or iterator?
Anyway, it seems to me that in the end this is about
that balance between practicality and purity. Maybe
it's more like tuples have a primary intended purpose,
and some support for other applications. Not white,
but not pure black either.


If you do that, you've just weakened the case for not having count
etc. as methods of tuples.

It really is the dichotomy of "tuples aren't meant to be sequences so
they don't have ..." versus being able to access them sequentially
that gets me. That just doesn't seem right.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Dec 3 '05 #104
In article <86************@bhuda.mired.org>, Mike Meyer <mw*@mired.org> wrote:
Donn Cave <do**@u.washington.edu> writes:

For me, conceptually, if an object can't be accessed
sequentially, then it can't be mapped to a sequence.


So you're saying that for should implicitly invoke list (or maybe
iter) on any object that it's passed that's not a list or iterator?


for does in fact implicitly invoke iter() on its loop expression.
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

"Don't listen to schmucks on USENET when making legal decisions. Hire
yourself a competent schmuck." --USENET schmuck (aka Robert Kern)
Dec 3 '05 #105
Quoth Mike Meyer <mw*@mired.org>:
| Donn Cave <do**@u.washington.edu> writes:
....
|> For me, conceptually, if an object can't be accessed
|> sequentially, then it can't be mapped to a sequence.
|
| So you're saying that for should implicitly invoke list (or maybe
| iter) on any object that it's passed that's not a list or iterator?

Not really saying anything so concrete about it -- doesn't make
any difference to me how it works, just saying that all these
things come together. Convert to list, iterate, for. They're
conceptually not just related, but bound together.

|> Anyway, it seems to me that in the end this is about
|> that balance between practicality and purity. Maybe
|> it's more like tuples have a primary intended purpose,
|> and some support for other applications. Not white,
|> but not pure black either.
|
| If you do that, you've just weakened the case for not having count
| etc. as methods of tuples.
|
| It really is the dichotomy of "tuples aren't meant to be sequences so
| they don't have ..." versus being able to access them sequentially
| that gets me. That just doesn't seem right.

The case is weakened only if we have been pretending it was really
strong. I guess this may be why this issue drives certain people
crazy. There's a case for "don't have", but it isn't air-tight, so
what do we do? Well, that's the one thing I really like about the
winter holiday season -- some particularly flavorful ales come out
of the local micro-breweries around this time of year, just in time
to ease my worries about tuples.

Donn Cave, do**@drizzle.com
Dec 3 '05 #106

This discussion thread is closed

Replies have been disabled for this discussion.

By using this site, you agree to our Privacy Policy and Terms of Use.