PEP scepticism

Steve Horne sh at ttsoftware.co.uk
Mon Jul 2 07:58:19 EDT 2001


On 28 Jun 2001 17:31:53 GMT, bernhard at intevation.de (Bernhard Reiter)
wrote:

>In article <kklmjtkhk17011nkjkigoh6u5f5otospuu at 4ax.com>,
>	Steve Horne <sh at ttsoftware.co.uk> writes:
>> On 28 Jun 2001 14:47:19 GMT, bernhard at intevation.de (Bernhard Reiter)
>> wrote:
>> 
>>>This a general warning against the second system syndrom in Python.
>> 
>> I think you may have a good point for the future, but I'm actually a
>> big fan of some of those recent additions to Python.
>
>As I wrote in my post, I do not want to discuss the advantages or
>disadvantages of single additions even though I have mentioned them.
>I hope I can explain my cause without being specific.

I interpreted that as not wanting to get bogged down in arguments that
are perfectly well discussed in relation to the PEPs. If we are not
allowed to even mention the cases you mentioned, then surely you are
banning people from using any relevant evidence in counterarguments
;-)

>> Extremely familiar to anyone with a C, C++ or Java background, and
>> something that I was annoyed to have to live without when I first used
>> Python. 
>
>I am not sure if this is good reasoning, 
>just because people know a feature from other languages might not 
>make it a good one (or we all end up with perl :) ).

No - not *just* because it's in other languages, but also because it's
so useful that people don't like to live without it. That really was
the key point I was trying to make - people *want* those features
because they make life easier.

>> Another large group of Python programmers have a background in
>> functional languages, and will immediately understand 
>
>In my experiences a lot of functional programming language features
>are too complex and abstract for most people to really 
>add them to their active programming vocabulary.

Depends on the particular functional language - some seem to have
ignored the simple fact that infix notation is intuitive, for
instance, but others look remarkably similar to imperative languages.

Besides, Python is not turning into a functional language, it is
merely picking up the features that are genuinely useful, and - once
you get used to them - quite difficult to live without. That basically
means having flexible, intuitive list handling - such as list
comprehensions - but not having to deal with all those
migraine-causing recursive definitions.

>> have you ever met an
>> electrician who only owns a single screwdriver? - I think not. Doing a
>> good job means using the right tool for the job, not forcing a single
>> tool to do every job.
>
>Of course this is a matter of balance, I prefer a minimal set of tools
>which gives me maxmimum power. There will always be some overlap of course.
>Still one aim is to keep the number of tools small.

Of course there is no point having so many tools you don't know how to
use them all, but I don't think this is the case yet. The question is,
of course - what is the precise definition of a 'small' number?

Python 2.0 and 2.1 added most of the tools that I had missed in the
past. It will be interesting to see what is added in 2.2.

-- 
Steve Horne
Home : steve at lurking.demon.co.uk
Work : sh at ttsoftware.co.uk



More information about the Python-list mailing list