Steve,
You may be right. It often happens that someone has a (small) idea, perhaps
very focused, and others chime in and try to apply it more widely, perhaps by
making it more general, and it grows. Over the years, the earlier adopters may
be seen almost as co-creators or even become the lead in the story. Tell me who
seems to be associated with Apple and who did much of the technical work? I am
not saying that Jobs did not have vision and marketing talent and an eye for
style and so on. I am not even sure who came up with ideas back then. Another
such person, Bill Gates, did do some programming of BASIC early on and so forth.
So, whatever the history of early Python (and predecessors) was, it may have
begun as some enhancements and improvements of what came before and perhaps new
paradigms. Others who saw it may have seen something that looked easier to
teach. An obvious example, if it was there way back then, was removing lots of
brackets used in other languages (such as {([])} ) and using indentation. Feels
more natural to not-so-mathematical types.
But over the years the brackets have returned and worse. Like many languages,
Python used what symbols it could find on the keyboard and then overloaded them
horribly. Parentheses are used for grouping but also for tuples and to force
invocation of a function and to hold the argument tuple (albeit no trailing
comma is needed for a single argument as in other tuples) and presumably in
other contexts such as within regular expressions. Periods can mean quite a few
things as can asterisk and so on. There are few matched sets of characters on
the keyboard. () is now used for tuples, among other things. [] is used for
lists except when it is used for dictionary access as in cards[key] versus
text[5] and {} is used for dictionaries except when you use [] but also for
sets ...
Heck, they ran out of symbols. {} is an empty dictionary and you say set() for
an empty set. Ditto for tuple.
<> is not currently used as a matched set as it has many other uses like in
comparisons. Some languages even use <> as the same as != or ~= to mean not
equals. "" and '' and even `` are sort of used as if they are a matched set I
some languages (`` is in R, not Python) but are typographically identical as
compared to text processing that creates two versions.
EBCDIC had a few other symbols but many languages now use only ASCII symbols
and have to combine them to make complex and even non-intuitive combinations as
symbols. Try teaching a child in say C++ that:
X++==++Y is valid and even meaningful if read as:
X++ == ++Y
because it asks you to get the current value of X to compare to the NEW value
of Y incremented and return a Boolean result and immediately thereafter,
increment X. Heck, you can write (X++++Y) and so on. I have seen languages with
an = and == and even === alongside := and ::= and -> and --> and <- and <-- and
more all to mean variations on a theme.
If we had started with many more symbols, in some ways it would be harder but
in other ways easier. Mathematicians borrow symbols from lower case, upper case
and script letters from languages like Greek and Latin but also from Hebrew as
in, well not easy to include in a file contain normal text but aleph-null (and
aleph-one and infinitely more levels of infinity.)
A simple teaching language that uses English words children know might either
be verbose in places or long as in making you spell out DELETE instead of del.
But quite a few languages are simple if you leave out most of the
functionality. Yes, you need to explain why some things must end in a semicolon
or be indented a certain way or require parentheses or ...
What you don't want to teach is a complex language like English. I was teaching
my Dad as he prepared for Citizenship and he balked when told there were at
least seven distinct ways you pronounce OUGH in common English words.
So, perhaps python can be used to teach basic programming for several reasons
including no need to declare variables and their "types" in advance and having
relatively intelligent basic types that easily get converted in the background
as in various kinds of numbers. But when you use more and more features, it
expands into areas where, frankly, there is no one right answer and choices are
often made by fiat or by a majority. Mathematically, if you view a topic like
multiple inheritance in classes and the kludges made to get around logical
issues, you see what a mess it really is and very hard to teach. Look at the
double underscore notation(prefix-only) for variables that renames them to be
unique within a certain scope to avoid collisions in the mythical searched name
space.
I am not against such drift but at times wonder if a one-size-has-to-fit-all
mentality is wise.
I had a thought on an earlier topic by Asad. He wanted to write in Python what
is effectively a member of the UNIX grep family. Specifically, fgrep (or maybe
now grep -F) takes a list of things to search for, albeit fixed strings. His
need is literally to Get a line, apply Regular Expession and Print. GREP. In my
earlier days at Bell Labs, it was often easier, especially in prototyping, to
string together multiple tools, often single-minded little ones, sort of like
what someone here wanted to do with calling a pipeline of programs from within
Python and getting the results back into the program. It was not unusual to do
a grep piped to a cut to select parts of the line then pipe it to something
that excludes some of those in a reverse grep on a second pattern then pipe it
to something like the stream editor sed to make changes and so on. Yes, AWK and
PERL and other more full-blown languages evolved but were often initially used
to do small parts of the pipelines like these. We used hammers as thumbtacks
and collections of thumbtacks as hammers.
Python can often let you trivially build such little tools that were harder to
do in C, partially because some of that is built-in or easily attachable as a
module, perhaps with parts from a C library. So it may be easier now to write
the pipeline as straight python code and often more efficient.
I was involved with the history of things at times that now have legends about
them. I remember conversations I participated in back in the Usenet days where
Tim Berners-Lee was discussing what should and should not be part of hypertext
which evolved into HTML. For example, should there be a FLASHING/BLINKING text
as compared to bold/italic/emphasis/color. Many people participated, including
others whose names are now well-known for other achievements but for many it is
now remembered as the accomplishment of one or a few. Many people added to or
influenced Python.
Python can still be a great teaching language if kept to a subset and by
avoiding some tricks, even if intriguing or delightful. One idea SOME have is
to keep things as simple as you can and no simpler. Few would like to see the
two-line programs I can come up with.
Imagine initializing dozens of variables on one line like this:
a,b,c,d,...y,z = 3,1,4,1,5,9,2,6,5,3,5, ...
Or just:
a=3;b=1;c=4;...z=3.14159
One-line is not the same as smart or even comprehensible.
The second line might be an entire program as one big nested list comprehension.
Recall the example of applying a sequence of patterns to a sequence of lines
from a file?
[ print(line) for line in open(filename,'r') for pattern in patterns if pattern
in line]
Or something like that. I expect it will produce duplicates, though.
So, a longer version still on one line might convert the actual list to a set
fed to a sort fed to a print as in:
Print( sorted( set( [ print(line) for line in open(filename,'r') for pattern in
patterns if pattern in line] ) ) )
I know, not the right order! What do you expect from a one-liner 😉
I haven't checked the exact use live (sort of like how I was rushed and did
not check spelling and grammar earlier today before sending) but the point is a
line like that can loop on both lines and patterns nested and apply an if
condition and return the (not meaningful) results of printing the line to be
ignored as you don't actually want to make a list, just do a print as a side
effect. Sometimes a very elegant solution is also hard to understand. The
second version moves the print outside, so no side-effect.
What is easy to teach to children? I remember an experience I had teaching
Geometry to tenth graders. There is a well known method to prove isosceles
triangles (with two equal sides) must have two equal angles opposite those
sides. But it requires you to create a line by dropping a perpendicular to make
two smaller triangles so you can then do side-angle-side comparisons to show
congruence. There is a more elegant proof I knew from taking higher level
courses (Math is one of my degrees) that involves merely relabeling triangle
ABC as CAB and showing how the reflected triangle is congruent to itself and
thus congruent parts are equal. I turned from the blackboard to see a very
puzzled class that had gotten lost on the very first step and never caught on
to the beautiful and elegant and very abstract idea. I did not then try to even
mention that there are many other geometries such as non-Euclidean Riemannian
or Lobachevskian varieties. Wrong level for them. But, our Universe does not
seem to be Euclidean, nonetheless.
Frankly, much of what is added to a simple language is rarely used and some
perhaps never. I was once an expert on all the word processors of the time with
the intent of making programs to interconvert between them so you would send an
attachment to an email which would arrive to each recipient in the form of
their choice with the minimal number of conversion steps. But so many features
turned out to be rarely used or even known about. Look at the modern Microsoft
Word and features like making labels or setting up regions where a different
language is used and spelling should be checked differently or embedding live
objects like spreadsheets and on and on. I doubt many people use a tenth of the
available features and often have no idea they are even there.
Some more academic settings, and that includes AT&T before the breakup and for
quite a while after, try to do as much as they can imagine. For example if
there is a command using the letter A and one for B, we obviously need one for
Q and every other letter even if they are not mnemonic or never used. They
often do not ask if anyone really wants the extra stuff or whether including it
means coming to market years later and with lots of bugs as the requirements
are too ambitious or have conflicts within them. I wrote some of those
requirements, while protesting, and often the projects never made it to light
and are well forgotten now.
I conclude by saying that on this forum, if a beginner or novice asks
questions, we often do not tell them the right way is to make a bunch of
objects with data hidden and preserved and so on, if there is a fairly simple
way. But if asked how we would do it, the answer might often be that we would
just grab some pre-made modules and connect it with a little code. Someone else
has already done all that work and the pythonic way is to make a subclass of
something that already works ...
Avious
-----Original Message-----
From: Tutor <tutor-bounces+avigross=verizon....@python.org> On Behalf Of Steven
D'Aprano
Sent: Tuesday, November 20, 2018 5:36 PM
To: tutor@python.org
Subject: Re: [Tutor] Pythonic way
On Tue, Nov 20, 2018 at 08:22:01PM +0000, Alan Gauld via Tutor wrote:
> I think that's a very deliberate feature of Python going back to its
> original purpose of being a teaching language that can be used beyond
> the classroom.
I don't think that is correct -- everything I've read is that Guido designed
Python as a scripting language for use in the "Amoeba"
operating system.
You might be thinking of Python's major influence, ABC, which was designed as a
teaching language -- but not by Guido himself. Guido was heavily influenced by
ABC, both in what to do, and what not to do.
https://www.artima.com/intv/pythonP.html
http://python-history.blogspot.com/2009/02/early-language-design-and-development.html
--
Steve
_______________________________________________
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
_______________________________________________
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
