D
Dave Brueck
Istvan said:
That's my fear - type declarations could become one of the most abused language
features because they'd get used too often.
-Dave
That's my fear - type declarations could become one of the most abused language
features because they'd get used too often.
-Dave
R
Roman Suzi
What about generic programming coming into fashion anytime soon?
Sincerely yours, Roman Suzi
Sincerely yours, Roman Suzi
D
Doug Holton
Istvan said:
I didn't write that, Guido did. I agree with you, and others who have
made the same point you made. I would have to think Guido is already
aware of this issue (keep python simple). I'm not sure what his
motivations are for wanting to add static typing to python, not that I'm
against it.
It doesn't matter a whole lot either way since Python 3000 is still
years away and you can already do static typing now with Pyrex or boo,
as well as many other things that people have requested for python from
little things like ++i to bigger features like multi-line anonymous
methods/closures.
D
Dave Brueck
Roman said:
Roman, I think I've read every single thread in the past year or three wherein
you've brought up generic programming, and I think you'd do well to choose a new
term for the idea you're trying to convey.
The term "generic programming" is too... er... generic.
As you know, Python already includes a _lot_ of support for generic programming (a function that
iterates over a sequence can easily process a list, or a string, or a tuple as
input; a function that takes a file-like object can often work just as will with
a true file object or a cStringIO object; etc.). So when you bring up "generic
programming", it's too easy to dismiss the comment because (1) it's too vague
and (2) Python already does a lot of it.
So, what is your term for the type of generic programming that Python doesn't
yet support? Interfaces? Protocols? Adapters? Metatype hierarchies?
-Dave
R
Roman Suzi
IIRC, I did it only once: at fall 2004.
The term "generic programming" is too... er... generic.
Nope. It is not generic. It has it's definition made by the co-author
of STL - A.Stepanov. And the Boost C++ library (many of us know it as
Boost Python) standardise on the approach, AFAIK.
Python could have honest support of concepts. Everything else will be
available with them.
That is the whole point that Python supports GP. It is only one step
to do concepts right (and GvR it seems want type-checking into Python 3.0
anyway), so support for concepts/concept checking is very logical,
isn't it?
Right now concepts in Python are things which experienced Python programmers
know from practise. Sometimes, they feel them unconsciously.
Concepts could be veryfied and this, for example, could prevent errors
like DB-API-complient module doesn't have some small, but necessary
to comply, attributes.
Standard concepts could be part of standard concept "metalibrary", along with
verification mechanisms (this could be done even on C++, why not in a candy
like Python?). So every programmer could verify that his/her class, created to
satisfy concept XYZ is (formally) such. Your example - cStringIO - does
it really satisfy concept of STRING? It does. Partially. Those "partially"
here and there could lead to madness.
Unit testing will be simplified too, because structural tests will be
built into concept-checking mechanism.
And BTW, are we really disputing? What do you propose instead? Old-fashioned
Pascal-like type definitions? Java-like interface/implementaion ...? IMHO it
could be a big mistake to play catch-up.
Sincerely yours, Roman Suzi
T
Terry Reedy
Bulba! said:
The array types of Numerical Python (NumPy) and now Numarray are, defacto,
Python's standard 1 to n dimensional array types. Once installed, they are
as builtin as anything else. Several other packages build on top of them.
Numarray has a record array type. If there is not one publicly available,
perhaps you could write a CSV file to record-array slurper and contribute
it to the Recipes site or maybe even the CSV module.
Terry J. Reedy
I
Ian Bicking
Roman said:
Umm... this isn't helpful. "Generic" and "concept" are not terms that
belong to Boost or STL or whatever. They are just words. Coining the
term doesn't mean anyone else knows what it means, nor that anyone
*should* know what they mean -- personally I get very suspicious of
ideas that are based on redefined words, that tends to be a way of
hiding complexity or fuzziness.
But anyway, if you use these terms, you really must provide references,
otherwise no one will know what you mean. "Python could have honest
support of concepts" is simply an incomplete sentence. "Python could
have honest support of Concepts (url)" would be more reasonable.
R
Roman Suzi
Or, yes, and I forgot to mention that generic programming is much clearer idea
than OO programming, as it is not so vague. At least for me:
I still don't fully comprehend OOP (after N years of "studying" it!) and
understanding of GP came after just one book on the topic.
Sincerely yours, Roman Suzi
H
holger krekel
Hi Roman,
As an innocent by-dropper into this thread:
a) do you know Armin Rigo's "semantic model" page dealing
with concepts?
http://arigo.tunes.org/semantic_models.html
b) do you have some concise definition of what you mean
by "concept"?
Myself, i appreciate the combination of testing and python's
flexibility so much that i don't long for type declarations,
at least not to the degree that would warrant syntax additions.
Now for interfaces, for me this references more a documentation issue
than a syntax one: I'd like to have a full-featured runtime browser
that allows to quickly navigate cross-referenced life python objects.
Back and forth in execution time, preferably. This probably requires
the interpreter to help, track and record more information (which is one
of the possibilities with PyPy). It doesn't neccessarily require any new
syntax though.
And I don't really see the point of adding interface
hierarchies to already large frameworks. To me this adds to -
what i call - "naming complexity", i.e. the number of names a
programmer needs to remember to deal with a library or
framework. For me, it's not really the syntax that is the
problem with interfaces in Zope3 or twisted, but the sheer
amount of names (each indicating certain concepts and
behaviours) i am confronted with.
Not sure why i am saying all this here
but have fun,
holger
As an innocent by-dropper into this thread:
a) do you know Armin Rigo's "semantic model" page dealing
with concepts?
http://arigo.tunes.org/semantic_models.html
b) do you have some concise definition of what you mean
by "concept"?
Myself, i appreciate the combination of testing and python's
flexibility so much that i don't long for type declarations,
at least not to the degree that would warrant syntax additions.
Now for interfaces, for me this references more a documentation issue
than a syntax one: I'd like to have a full-featured runtime browser
that allows to quickly navigate cross-referenced life python objects.
Back and forth in execution time, preferably. This probably requires
the interpreter to help, track and record more information (which is one
of the possibilities with PyPy). It doesn't neccessarily require any new
syntax though.
And I don't really see the point of adding interface
hierarchies to already large frameworks. To me this adds to -
what i call - "naming complexity", i.e. the number of names a
programmer needs to remember to deal with a library or
framework. For me, it's not really the syntax that is the
problem with interfaces in Zope3 or twisted, but the sheer
amount of names (each indicating certain concepts and
behaviours) i am confronted with.
Not sure why i am saying all this here
but have fun,
holger
D
Dave Brueck
Roman said:
Ok, "too broad" then; Python already supports at least some aspects of generic
programming (at least, in the sense that I think you mean it), so it'd be good
to spell out what specific features you're referring to.
"Concepts" is a pretty generic term too! ;-) Do you mean concepts as defined
here: http://www.boost.org/more/generic_programming.html
?
No, not at all - I'm just trying to better understand what you mean. Words like
"generic" and "concepts" don't yet have a widely recognized, strict definition
in the context of programming. If somebody has assigned some specific definition
to them, that's great, it's just not universal yet so references and additional
explanations are helpful.
-Dave
R
Roman Suzi
Sorry. I use definitions from there sources:
1. http://www.cs.rpi.edu/~musser/gp/
2. "A Formalization of Concepts for Generic Programming"
(google could find PDF of that). If I am correct, this one:
http://www.osl.iu.edu/publications/pubs/2004/willcock04:_formal_concep_gener_progr.pdf
(it is safe to skip till example on Fig.1 to grasp the idea behind
a concept. Relations between concepts are also very logical and
remind of inheritance, association and aggregation)
3. "The Boost Graph Library" by Jeremy Siek, et al with A.Stepanov's
foreword is a good way to see GP != STL.
Probably Boost docs contain some knowledge on the topic, at least
Boost Graph Library's ones (which I read).
- of course, right now those sources are C++-specific. But I could see that
Python has even greater potential to have concepts ahead of C++ and with
greater usefulness at the same time.
Sincerely yours, Roman Suzi
R
Roman Suzi
I apologize for not providing URLs to the exact definitions in the first
place! I really think there is ONE understanding of GP vs. multitudes of
understandings of OOP.
Sincerely yours, Roman Suzi
R
Robert Kern
Terry said:
And one of the goals of numarray (which is a complete rewrite of
Numeric) *is* entry into the standard library.
--
Robert Kern
(e-mail address removed)
"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter
S
Skip Montanaro
Terry> Numarray has a record array type. If there is not one publicly
Terry> available, perhaps you could write a CSV file to record-array
Terry> slurper and contribute it to the Recipes site or maybe even the
Terry> CSV module.
-1 on putting such a beast into the CSV module, especially if, as it seems,
it would rely on something outside the core.
Skip
Terry> available, perhaps you could write a CSV file to record-array
Terry> slurper and contribute it to the Recipes site or maybe even the
Terry> CSV module.
-1 on putting such a beast into the CSV module, especially if, as it seems,
it would rely on something outside the core.
Skip
C
Carlos Ribeiro
Although I see your point, in the long term it will be required.
Assuming that Numarray will, at some point in the future, be included
in the stdlib... why not give these people some help, easing the
integration? A recipe, or some code that can be provisionally included
in Numarray itself (as a submodule), and then later migrated to the
CSV module... it does make sense in the long run.
--
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: (e-mail address removed)
mail: (e-mail address removed)
A
Alex Martelli
Dave Brueck said:
Googling for "generic programming" (with the quotes) gets 100,000 +
hits. The first couple pages of hits, at least, seem to all be speaking
about exactly the same thing. The terminology appears to be settled
enough that Oxford's St Anne College feels they can organize a "Summer
School on Generic Programming", Nottingham University a "Workshop on
Generic Programming", etc, etc, without fearing ambiguity.
"Generic" by itself is one thing, but when we specifically mention
"Generic programming" I do not really see the ambiguity. Same for
"concepts" -- by itself it's too wide, to the point that it means
nothing, but put it next to "generic programming" and the resulting
26.000 hits seem to be mostly speaking about the very same thing, in as
much as one can tell from the first few pages of hits, "a concept is
defined as a family of abstractions that are all related by a common set
of requirements" to quote Musser.
Exactly what extra support Roman would want from Python for 'concepts',
beyond that offered by, say, C++, I'm not sure. Protocols, interfaces
and design-by-contract are other terms often used to try and capture
pretty similar issues. As far as I know the C++ community is unique in
routinely formalizing some PERFORMANCE requirements (pragmatics ahoy!-)
as part of their approach to generic programming -- but that's just an
important cultural issue, the LANGUAGE itself, C++ as it stands, offers
no way to say "this has O(N) perfrmance"... this kind of thing still
goes in comments, and in clauses in standardization documents.
When I say that a "protocol" includes pragmatics as well as syntax and
semantics, that's part of what I mean, in a handwaving kind of sense.
The *interface* to a Python dictionary/mapping includes a set of methods
with certain signatures; it expresses little beyond "syntax" issues.
The *semantics* of it include axioms that could and perhaps should be
formalized to define the connectedness among the methods, e.g. a long
list of things such as "for any x acceptable as a key and y acceptable
as a value into d, ...:
d[x] = y
assert x in d
del d[x]
assert x not in d
d[x] = y
z = d[x]
assert z is y
and so on, and so forth". The kind of things one would write in a unit
test... except that unit tests don't include universal quantifiers of
the form "for any x such that";-).
Finally, the *pragmatics* of a Python dictionary include "accessing d[x]
is pretty darn fast" although no doubt that could (I dunno if it should)
be formalized further.
As to how a "dictionary CONCEPT" might differ from a "dictionary
PROTOCOL", I'm not sure. They both should include syntax (interface),
semantics (behavior specs), and perhaps a sprinkling of pragmatics --
such as, O(...) performance specs for some operations, but mostly stuff
that's harder to formalize, such as, say:
x = malloc(N);
x = realloc(x, M):
when N is very very large, and M is MUCH smaller than N, SHOULD,
pragmatically, make some memory available for other uses (as opposed to
leaving it all in the block allocated for x) -- the kind of things that
don't get into formalized standards because handwaving is disliked
there, but can make a programmer's life miserable nevertheless (as this
very issue does with today's Python, which relies on these pragmatics in
a spot or two, and MacOSX' standard C library, which ignores them...).
Alex
S
Skip Montanaro
Terry> Numarray has a record array type. If there is not one publicly
Terry> available, perhaps you could write a CSV file to record-array
Terry> slurper and contribute it to the Recipes site or maybe even the
Terry> CSV module.
Carlos> Although I see your point, in the long term it will be required.
Carlos> Assuming that Numarray will, at some point in the future, be
Carlos> included in the stdlib... why not give these people some help,
Carlos> easing the integration?
I'm not sure they really need my help. I've never needed Numarray (or
Numeric) in my own work. If it's deemed useful I'm sure someone from that
community could whip something out in a few minutes. The concepts
represented by the csv module are a lot shallower than those represented by
Numarray.
Skip
Terry> available, perhaps you could write a CSV file to record-array
Terry> slurper and contribute it to the Recipes site or maybe even the
Terry> CSV module.
Carlos> Although I see your point, in the long term it will be required.
Carlos> Assuming that Numarray will, at some point in the future, be
Carlos> included in the stdlib... why not give these people some help,
Carlos> easing the integration?
I'm not sure they really need my help. I've never needed Numarray (or
Numeric) in my own work. If it's deemed useful I'm sure someone from that
community could whip something out in a few minutes. The concepts
represented by the csv module are a lot shallower than those represented by
Numarray.
Skip
R
Roman Suzi
That is why I was pretty sure people undestand me.
I just happen to like the term 'concept' more than Protocols, interfaces,
and design-by-contract ;-)
Alex, I think you are +10 for adding interfaces into Python. "Concept"
is more compact word and I am sure it is not used as a name in existing
projects, unlike other words.
Also, Python concept collection could be used as a teaching example or
templates for high quality code. Concepts need not appear in every
script out there, but as a result of design.
What else Python needs to support GP? A possibility to formally
define a concept (and concept relations) with (optionally)
checks of implementations.
I do not even insist in making it all run-time! Perhaps concepts could
be checked in PyChecker. And (perhaps) the whole type-checking
could be done this way.
However sweety it is, I also hope to have keystrokes saved when
I use ready-maid concept in my program.
Just imagine we have a concept for table and use (as adaptor) it for
db-connectivity, CSV-readers/writers, XML/HTML parsers/writers, arrays,
lists, ...
Right now Python _almost_ has it. However, small differences in small details
do not allow to interchange even different dbm-modules! I remember
getting into trouble when I switched from bsddb to gdbm: some places needed
'r' to be explicitly specified! Same problems with db-api 2.0 "almost"
conformant modules, datetime types and other small details which are
similar but differ in small details at the same time. I think the same
has place with XML-DOM implementations and such.
I think concepts could be guards against such things and also make life easier
for those who implement some standard protocols. That is, concepts could be
internal (Python) standardizing and quality control technique. We can use
constant publicId, systemId a-la XML for concepts, so upgrade path will be
similar to HTMLs. This will make concept-changing visible between versions.
Sincerely yours, Roman Suzi
A
Alex Martelli
Roman Suzi said:
Actually, I want protocols -- semantics (and pragmatics), too, not just
syntax (method names and signatures). Eby's PyProtocols comes closest
to my desiderata (though it possibly exceeds them). But if you start
coding a PyConcepts alternative to PyProtocols I'll be delighted to try
it out, contribute, &c -- I won't be a stickler for the name. Indeed,
"protocol" is no doubt more overloaded, since it's an established name
in networking, and if you google for "protocol adaptation" you get a mix
mostly related to networking with a few examples of the way PEP 246 uses
the phrase thrown in;-).
Alex
B
Bulba!
I've never needed numeric stuff either. I just need to do things like:
..>>> table.sort(column_name) # that obviously would sort rows of table
by the values of column column_name
or
..>>> unique = table.unique(column_name) # that would yield such
a subset of all the rows that would contain unique values from column
column_name
or
..>>> table1.union(table2 [,drop_missing_columns |
,fill_missing_with_None])
or
..>>> common = table1.intersection(table2, column_name [, unique |
, redundant])
# that would yield all the rows that have the same values in
column_name in both table1 and table2; if optional keyword
"unique" were given, those could e.g. be only rows
from table1, when the "redundant" keyword were specified,
that could be a union of common rows from table1 and table2
or
..>>> complement = table.complement(complement_function) # where
complement function could be anything, like (!cellvalue) or
string.upper; that obviously would run the complement_function
on every cell in table
(obviously, this could also be implemented as
map(table, complement_function) )
Now suppose a programmer could write a custom complement function
that detects all the irregularly distributed "anomalous" data points
(be it whatever, missing surnames from personnel records or values
from a physical experiments that are below some threshold) in this
table and returns, say, a list of tuples that are coordinates of those
data points. Getting it from a specific table would be a matter of one
instruction!
Yes, I know, it can be written by hand. But by this line of logic why
bother learning VHLL and not just stay with C?
True, and I may scratch enough time together to learn all the
necessary stuff (I'm not even half done in learning Python)
to write it myself.
That is not the point, however: the biggest boost and one of the
main points of getting into Python, at least for me, but I'm sure
this is also motivation for quite a lot of other people, is precisely
the ease of exploiting capabilities of data structures like
dictionaries and lists, which when coupled with this data structure's
object-style .method are simply very convenient and fast. This is
where IMHO Python excels among the VHLL languages.
I'm about to post reworked version of my program that doesn't
use a _single_ traditional loop to do all the data transformations
I need (I just still need to solve some problems there / polish
it).
This is not just about that damn CSV file that I already have
the way I wanted it and sent it to customer, this is about _terse
and clear_ manipulations of rich data structures in Python. Why not
extend them with flexible tables / matrices / arrays that would work
in as "Pythonic" ways as dictionaries and lists already do?
If Pythoners say a=['A'], it's only logical to say a.append('B').