Python evolution: Unease
Iwan van der Kleyn
Despite a puritan streak I've always tried to refrain from language wars
or syntax bickering; call it enforced pragmatism. That's the main reason
why I've liked Python: it's elegant and simple and still dynamic and
flexible. You could do worse for a clean and pragmatic language.
I do know my Smaltalk from my Common Lisp and my Ruby from my C#, so I
think I'm quite capable of escaping the "Blub paradox"
http://c2.com/cgi/wiki?BlubParadox. I do miss some slick features in
Python. But the nice thing about Python is that in those cases I can use
its dynamism to implement it myself (and usually somebody else has done
it for me, of course).
In the end I'm not a language guru nor a framework wizard, but a mere
mortal who designs and writes programs for end-users. For that task I
need: a better standard ide, an integrated db interface with a proper
set of db drivers (!!), a better debugger, a standard widget/windows
toolkit, something akin to a standard for web programming, better
documentation, a standard lib which is better organized, a formalized
set of protocols and patterns for program construction. And an
interpreter which is fast enough to avoid using C or Pyrex in most
obvious cases.
Many will say that Van Rossum's brainstorms/proposals as depicted in
http://www.artima.com/weblogs/viewpost.jsp?thread=86641
will help in the above mentioned. And I'm certainly not against Optional
ype checking.
But I see little to no efforts from the core python team to address my
needs as listed above. They seem mainly to focus on the core attributes
and syntax of the language. Very little or no efforts are taken to
improve the infrastructure around the language.
And then I read the following sentence by Van Rossum:
"In order to make type inferencing a little more useful, I'd like to
restrict certain forms of extreme dynamic behavior in Python"
In the end, it's mindset which counts. And I think that mindset is going
to be determine the way foreward for Python: more features, increased
complexity, less dynamism. Lots of syntax crud, without addressing the
need to improve the infrastructure around the language.
In short: I symphatize Patrick Logan's feeling:
http://patricklogan.blogspot.com/2005/01/road-to-ruin.html
Regards,
Iwan van der Kleyn
flamesrock
is the singlebest language I've worked with to date. In a matter of
weeks I learned to do things that took me months in other languages and
even found the process enjoyable.
Maybe you are right. If so, couldn't Python be forked into something
like you describe, while still remaining compatible at the core? (if
anyones willing)
Python++ anyone?
Paul Rubin
> Maybe you are right. If so, couldn't Python be forked into something
> like you describe, while still remaining compatible at the core? (if
> anyones willing)
It's not an issue with the Python core (language); I read that post as
mostly bemoaning the poor state of the runtime library. I feel the
same concerns, however, fixing it is a lot of work.
michele....@gmail.com
Michele Simionato
Alex Martelli
> to be determine the way foreward for Python: more features, increased
> complexity, less dynamism. Lots of syntax crud, without addressing the
As a student of human nature, I'm _really_ curious as to how one could
possibly read the key document:
http://www.python.org/peps/pep-3000.html
and think in consequence of "more features, increased complexity".
Also, you keep talking about "the core python team" on the basis, it
would appear, of reading one document by Guido. Have you bothered doing
a MINIMUM of homework, such as, looking at
http://www.amk.ca/diary/archives/cat_python.html
and specifically AMK's entry for September 30? I'm trying to understand
whether you completely missed doing the most elementary amount of
background searching before venting on the group, or if you did find and
read the obvious documents and somehow STILL manage to completely ignore
their contents or read them as saying exactly the opposite of what they
_do_ say...
Alex
Iwan van der Kleyn
> Also, you keep talking about "the core python team" on the basis, it
> would appear, of reading one document by Guido. Have you bothered doing
> a MINIMUM of homework, such as, looking at
> http://www.amk.ca/diary/archives/cat_python.html
Well, you being a member of that core team (meaning nog an
organisational unit, but the group of people doing the really hard job,
getting Python to work. An excellent job at that :-) I can repect you
if not branding me a lamer at least admonishing me for not coming up
with a thorough factual statement. But like I stated: "ramblings", remember.
I'm not completely unknown with the workings of our species myself,
though. Especially when discourse and policy is dictated by a select
group of people (meaning: the one who actually create python, no
criticism there) with final abritary powers for one indidual (again, no
criticism), mindset *is* just as important as stated fact. Mindset will
dictate future discourse and action.
And I do sense (reading planet python/this newsgroup) a mindset or at
least a tendency by the people who really matter in these discussion to
keep on adding features to the syntax; to add "structure" to Python. My
personal preference would be to leave the language alone for a while and
to improve its infrastructure.
Regards,
Iwan
Ville Vainio
Iwan> And then I read the following sentence by Van Rossum:
Iwan> "In order to make type inferencing a little more useful, I'd
Iwan> like to restrict certain forms of extreme dynamic behavior
Iwan> in Python"
Iwan> In the end, it's mindset which counts. And I think that
Iwan> mindset is going to be determine the way foreward for
Iwan> Python: more features, increased complexity, less
Iwan> dynamism. Lots of syntax crud, without addressing the need
Iwan> to improve the infrastructure around the language.
What form of extreme dynamic behaviour have you been using lately? Do
you really think it's more worthwhile than the benefits provided by
type inference, least of which isn't the ability by IDEs to provide
you accurate code completion.
Also, Python is not a monolithic entity. Guido certainly isn't going
to write a better IDE for Python, so the time used on language
features isn't removed from improving the infrastructure around the
language.
--
Ville Vainio http://tinyurl.com/2prnb
Paul Rubin
> Also, Python is not a monolithic entity. Guido certainly isn't going
> to write a better IDE for Python, so the time used on language
> features isn't removed from improving the infrastructure around the
> language.
There aren't THAT many people working on Python. Any time spent on
feature X does tend to divert resources from feature Y.
I think there should be a moratorium on nontrivial language changes
(as opposed to library improvements) until PyPy is fully deployed.
Too much of Python as we know it today is shaped by the weirdness of
CPython. We ought to be able to get away from that.
Ville Vainio
Paul> Ville Vainio <vi...@spammers.com> writes:
>> Also, Python is not a monolithic entity. Guido certainly isn't
>> going to write a better IDE for Python, so the time used on
>> language features isn't removed from improving the
>> infrastructure around the language.
Paul> There aren't THAT many people working on Python. Any time
Paul> spent on feature X does tend to divert resources from
Paul> feature Y.
But the people working on wxPython, pygtk, pyqt, pydev, whatever, are
largely not the same guys that commit stuff to CPython CVS.
Paul> fully deployed. Too much of Python as we know it today is
Paul> shaped by the weirdness of CPython. We ought to be able to
Paul> get away from that.
Type declarations are a feature that might benefit IronPython and
Jython more than they would CPython.
Paul Rubin
> But the people working on wxPython, pygtk, pyqt, pydev, whatever, are
> largely not the same guys that commit stuff to CPython CVS.
Right, but for that reason, they don't count as being working on
Python.
> Type declarations are a feature that might benefit IronPython and
> Jython more than they would CPython.
CPython seems to be what drives quite a few language design decisions.
Roman Suzi
Maybe OP doesn't yet fully comprehend the ways of Python universe?
As for his claims, I am quite surprised that Python lacks
something in the docs.
Concerning better hierarchy in the standard library, it is interesting
that there are some movements in this direction: xml package,
email package, etc. Probably Iwan thinks that letting more
"hierachiesness" into std lib Python will be "cleaner".
Yes, it will probably look "more organized" this way, but
I do not like the idea:
import time.time
import time.calendar
...
import web.url.openers
import net.http
...
import datatypes.string
import textprocessing.re
etc.
> [Iwan van der Kleyn]
>
> #- need: a better standard ide, an integrated db interface with
> #- a proper
> #- set of db drivers (!!), a better debugger, a standard widget/windows
> #- toolkit, something akin to a standard for web programming, better
> #- documentation, a standard lib which is better organized, a
> #- formalized
> #- set of protocols and patterns for program construction. And an
> #- interpreter which is fast enough to avoid using C or Pyrex in most
> #- obvious cases.
>
> Let's take one by one:
>
> - IDE: Better than what? Than IDLE? Than Eclipse? Than SPE? Than Pythonwin?
>
> - Integrated DB interface with a proper set of db drivers (what means the
> "!!"?): What do you mean with an integrated db interface? An standard API to
> access different DB engines? Something like the Database API specification
> (http://www.python.org/topics/database/DatabaseAPI-2.0.html)? There's a SIG
> on DB at http://www.python.org/sigs/db-sig/ you may want to look at.
> Regarding drivers, to what DB do you miss one?
>
> - Debugger: Again, better than what? I use the debugger in IDLE and it's
> pretty ok.
>
> - Standard widget/windows toolkit: More standard than Tk?
>
> - Something akin to a standard for web programming: specifically?
>
> - Better documentation: Did you find *any* issue in the docs? And why you
> didn't post a bug on that?
>
> - Better organization of the std lib: What do you propose (specifically)?
> Please, in your proposal, take in consideration migration plans and how the
> migration affect actual systems. And of course, why the new organization is
> better than the old one. BTW, I also think that it should be better
> organized, but don't know how.
>
> - a formalized set of protocols and patterns for program construction: a
> what?
>
> - an interpreter which is fast enough to avoid using C or Pyrex in most
> obvious cases: CPython is More Than Fast Enough. In which obvious cases it's
> not enough for you?
>
> Don't misinterpret this response. I know it was a rambling. But *maybe* you
> have something to contribute to Python development, even good ideas only and
> no work.
>
> . Facundo
Sincerely yours, Roman A.Suzi
--
- Petrozavodsk - Karelia - Russia - mailto:r...@onego.ru -
Istvan Albert
> And I do sense (reading planet python/this newsgroup) a mindset or at
> least a tendency by the people who really matter in these discussion to
> keep on adding features to the syntax; to add "structure" to Python. My
> personal preference would be to leave the language alone for a while and
> to improve its infrastructure.
In all honesty this:
http://www.artima.com/weblogs/viewpost.jsp?thread=86641
scares me too. Reminds me of Larry Wall's writings on Perl 6
that make me tune out fairly quickly. I don't have the kind of
problems that the these features will solve so I can't relate
to them at all.
But others might do. Especially when using python in an environment
where enforcing a strict contract is important. But if python
were to become overly complicated I'll find something else.
Three years ago I have not not used python at all, now I'm
using it for everything.
Languages should evolve with time, adapt to the needs
of its users. Sometimes that means that in some areas
it might feel worse. But it could also mean that the
problem is with us, so it would be unfair to spend effort
towards holding back this evolution just because
we don't need it.
Istvan.
PS. why can't decorators solve this optional type checking
problem? I clearly remember this as being one of the
selling points for having decorators in the first place...
Aahz
The first three PSF grants were all in some way not directly related to
changing the core language. One was for a library, one for improving
Jython, and one for improving docs. Giving the PSF more money increases
the chances for additional work.
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
"19. A language that doesn't affect the way you think about programming,
is not worth knowing." --Alan Perlis
Paul Rubin
> As for his claims, I am quite surprised that Python lacks
> something in the docs.
Python is lacking plenty in the docs. Care to figure out from the
docs how tkinter works? That's not explained anywhere at all, except
in some off-site resources and in some printed books. Even some
language features like class methods and slots are explained only in
PEP's and release notes, instead of in the language manual where you'd
expect to find them since they're part of the language.
michele....@gmail.com
> The first three PSF grants were all in some way not directly related
to
> changing the core language. One was for a library, one for improving
> Jython, and one for improving docs. Giving the PSF more money
increases
> the chances for additional work.
Here is the link you forgot to post ;-)
http://www.python.org/psf/grants/
The one about the docs seems more about teaching scientists how to use
Python.
Michele Simionato
Skip Montanaro
Paul> Care to figure out from the docs how tkinter works? That's not
Paul> explained anywhere at all, except in some off-site resources and
Paul> in some printed books. Even some language features like class
Paul> methods and slots are explained only in PEP's and release notes,
Paul> instead of in the language manual where you'd expect to find them
Paul> since they're part of the language.
Start writing (or reorganizing). Folks, this is open source. I'm sure by
the traffic on the list most people here know how to write. In the case of
Tkinter, you should probably get the okay of the authors of various external
docs before incorporating them into the Python docs, but note that several
Tkinter-related documents are referenced directly from the Tkinter module
docs:
Python Tkinter Resources
The Python Tkinter Topic Guide provides a great deal of information
on using Tk from Python and links to other sources of information on
Tk.
An Introduction to Tkinter
Fredrik Lundh's on-line reference material.
Tkinter reference: a GUI for Python
On-line reference material.
Tkinter for JPython
The Jython interface to Tkinter.
Python and Tkinter Programming
The book by John Grayson (ISBN 1-884777-81-3).
This being the Internet and all, it's not clear that referencing external
documentation is somehow worse than incorporating it directly into the
distribution.
As for stuff that exists in PEPs and release notes, they should already all
have the necessary copyright (either they were placed in the public domain
or they are already part of the Python distribution) to allow you do just
check out a CVS tree, make the necessary edits and either check the files
back in or submit a patch to SourceForge.
In the documentation arena, I think more thought should probably be given to
producing online docs that can be directly annotated, thus further reducing
the barrier to more complete documentation (and more updates). Take a look
at latex2html, propose or implement changes, or just rewrite the damn thing
in Python. I think latex2html is probably a recurring nightmare for Fred
Drake.
Skip
Michael Hobbs
> What form of extreme dynamic behaviour have you been using lately?
One real-world example: in my new coverage analysis tool (to be
released any month now), I need to trace threads without changing any
code. To do so, I redefine the thread.start_new_thread() function from
outside the thread module, like so:
orig_start_new_thread = thread.start_new_thread
def traced_start_new_thread(func, args, kwargs={}):
return orig_start_new_thread(traced_func_call, (func, args, kwargs))
def traced_func_call(func, args, kwargs):
sys.settrace(my_trace_func)
func(*args, **kwargs)
thread.start_new_thread = traced_start_new_thread
Granted, doing something like this on a regular basis is really bad
coding style, but the ability to do something like this when I really
need it is what I love about Python.
Doug Holton
> But if python
> were to become overly complicated I'll find something else.
> Three years ago I have not not used python at all, now I'm
> using it for everything.
You're in luck, python 2.4 won't be significantly changing anytime soon.
> PS. why can't decorators solve this optional type checking
> problem? I clearly remember this as being one of the
> selling points for having decorators in the first place...
Because they are quite obviously an ugly and overly complicated
solution. Even Guido understood this:
http://mail.python.org/pipermail/python-dev/2004-September/048518.html
"A warning: some people have shown examples of extreme uses of
decorators. I've seen decorators proposed for argument and return type
annotations, and even one that used a decorator to create an object
that did a regular expression substitution. Those uses are cute, but I
recommend being conservative when deciding between using a decorator
or some other approach, especially in code that will see a large
audience (like 3rd party library packages). Using decorators for type
annotations in particular looks tedious, and this particular
application is so important that I expect Python 3000 will have
optional type declarations integrated into the argument list."
Hans Nowak
Optimistic documents about a cleaner and smaller language (and an
improved stdlib) are all well and good, but if you look what has
actually been happening to Python over the last few years, then the OP's
worries don't seem so far-fetched. "More features, increased
complexity, less dynamism" pretty much sums it up.
Guido's posts about optional static typing seem to suggest that this
development will continue in the same vein. (He may just be putting his
thoughts on paper, but it's the BDFL, so what is one supposed to think?)
I for one will NOT welcome our new static typing overlords. ;-)
--
Hans Nowak
http://zephyrfalcon.org/
Alex Martelli
> And I do sense (reading planet python/this newsgroup) a mindset or at
> least a tendency by the people who really matter in these discussion to
> keep on adding features to the syntax; to add "structure" to Python. My
> personal preference would be to leave the language alone for a while and
> to improve its infrastructure.
I happen to agree with this preference as stated here -- the time to
change the language is at 3.0 release time (say a few years from now).
It _is_, of course, perfectly sensible for Guido to start musing out
loud on the only major addition he really wants to make at that distant
time a few years from now, namely optional static typing -- it will be a
biggie when it comes, so it should not be sprung on us all by surprise;
the more (and the earlier) feedback comes to help him decide the exact
details of that addition, the merrier.
Meanwhile, over on python-dev, the discussion is on completing the
AST-branch (so the standard library may finally include a full
python-coded Python compiler when 2.5 is released, likely in 2006),
dealing (in distutils, mostly) with the fact that the Mac may use some
case-sensitive filesystems but its default one is case-preserving but
insensitive, issues with memory allocation strategies triggered by
Darwin's weird realloc behavior (a realloc there never shrinks an
allocation, eek), the best maintenance strategy for old FAQs, what
functionality is to be added to the zipfile module (e.g., removing files
from a zip archive), and the fix of a misspelling in the docs.
I kid you not: these are the threads going on today in the python-dev
list, where most of [the discussion about] Python's development really
takes place. Not sure who you believe "really matter in these
discussion" (sic), but the discussants today included Guido van Rossum,
Tim Peters, Martin v. Loewis, and many others. How one can possibly
infer from such raw data "a mindset or at least a tendency ... to keep
adding features to the syntax" is really hard to explain, at least for
me. Almost invariably, the great majority of proposals to change the
language, most particularly the syntax, come on this list, fortunately,
since that leaves python-dev essentially free to keep focusing on the
huge nitty-gritty daily work of enhancing the implementation (and other
aspects of the infrastruture, such as the spelling of the docs...);
almost invariably, moreover, the great majority of such proposals come
from clueless or semi-clueless newbies or semi-newbies.
You appear to have taken the fact that Guido appears to want lot of
early discussion about his ideas on optional static typing, presumably
to help those ideas develop, and drawn from that tiny speck of 'fact'
the most absurdly extrapolated conclusions, totally and utterly ignoring
the overwhelming countervailing mass of facts and evidence that point
exactly in the opposite direction.
Of course, what YOU think should happen regarding the infrastructure,
and what the people who donate their time to actually make things happen
want, may be totally at odds. For example, you appear to keenly want
one standard IDE to be blessed and receive all attention, one standard
web framework ditto, and so on, and so forth; most core developers, on
the other hand, appear to be very modestly inclined to spend their time
and energy in that direction, so that only a rather minor fraction of
the python-dev effort is channeled that way. Innovative efforts are
best kept OUT of the core Python standard, many of us believe, as long
as their innovative fervor continues: once something does get into the
standard Python library &c, it won't and shouldn't develop very fast,
nor at all freely, due to the tiranny of backwards compatibility, cross
platform support, and the huge increase in maintenance/support efforts
that comes when something suddenly becomes much more widespread and
widely used than it previously used to be. Enhancements in library
organization and functionality, fixing typos in the docs, or deciding
whether and how to work around some platform's quirks, are definitely
less glamorous than inventing new grand unification projects, but
nevertheless this kinds of things IS by far the vastest part of the work
in a large and mature open-source project.
Wonderfully innovative projects, *OUT* of the core language/library, are
very abundant. Come to PyCon in March and you'll probably hear several
eye-opening, possibly mind-boggling talks about such things as the type
inferencing and optimizations of the pypy project, or Enthought's
breathtaking Traits and Envisage technologies -- all "infrastructure",
btw, no language changes involved. It's perfectly fit and proper that
such work takes place exactly where it's taking place now. If and when
it matures and stabilizes, to the point of not needing any more
innovation but rather consolidation and spreading, _then_ some part of
it may be merged into the standard core. Many people contributing to
such innovative projects are also Python core committers, of course.
Alex
Istvan Albert
> application is so important that I expect Python 3000 will have
> optional type declarations integrated into the argument list."
I think that *optional* part of the "optional type declaration"
is a myth.
It may be optional in the sense that the language will
accept missing declarations but as soon as the feature
is available it will become "mandatory" to use it
(peer pressure, workplace practices).
Istvan.
Carlos Ribeiro
<FBat...@unifon.com.ar> wrote:
> #- need: a better standard ide, an integrated db interface with
> #- a proper
> #- set of db drivers (!!), a better debugger, a standard widget/windows
> #- toolkit, something akin to a standard for web programming, better
> #- documentation, a standard lib which is better organized, a
> #- formalized
> #- set of protocols and patterns for program construction. And an
> #- interpreter which is fast enough to avoid using C or Pyrex in most
> #- obvious cases.
>
> Let's take one by one:
I'll take only a few ;-)
> - IDE: Better than what? Than IDLE? Than Eclipse? Than SPE? Than Pythonwin?
I would like to seee Eric3, with some polish & opensourced on Win
(which means solving the Qt licensing problem). Perhaps someone could
convince Trolltech to release a special Qt Win version just for it
(Eric3). Eclipse is also an interesting approach.
> - Integrated DB interface with a proper set of db drivers (what means the
> "!!"?): What do you mean with an integrated db interface? An standard API to
> access different DB engines? Something like the Database API specification
> (http://www.python.org/topics/database/DatabaseAPI-2.0.html)? There's a SIG
> on DB at http://www.python.org/sigs/db-sig/ you may want to look at.
> Regarding drivers, to what DB do you miss one?
At the risk of starting a huge flamewar, let's state my opinion on
this. The DBAPI itself is not a problem, despite several debates about
improvements and talks about a future version 3. On the other hand, I
wish I could simply plug & play DBAPI modules in a totally seamlessly
way. Anyone who tried know how far are we of this dream.
At the risk of sounding pessimistic, I don't see plug & play
interoperability between DBAPI drivers happening anytime soon. The
work is simply way too fragmented. There's no real incentive for
compatibility, besides the good will of individual developers, who are
always busy and also, that have to keep their own code running. The
only way it will work, IMHO, is: if a single entity implements a
common API, be it the DBAPI2.0 or whatever, for a sufficiently large
number of existing database systems. You may call it a "imposed
standard". I don't mind. But it would solve the problem.
> - Standard widget/windows toolkit: More standard than Tk?
I may be wrong, but I think that most business developers expect more
than Tk is able to offer... Canvas is great, but anyone who used more
advanced toolkits (such as the ones available on Delphi, Java, or C#)
surely require a lot more.
--
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: carri...@gmail.com
mail: carri...@yahoo.com
Aahz
<michele....@gmail.com> wrote:
>Aahz:
>>
>> The first three PSF grants were all in some way not directly related to
>> changing the core language. One was for a library, one for improving
>> Jython, and one for improving docs. Giving the PSF more money increases
>> the chances for additional work.
>
>Here is the link you forgot to post ;-)
>
>http://www.python.org/psf/grants/
Didn't forget, was lazy and short of time.
>The one about the docs seems more about teaching scientists how to use
>Python.
True, but that's still an expansion of Python's usability as opposed to
changing the core language.
Bulba!
wrote:
>Also, you keep talking about "the core python team" on the basis, it
>would appear, of reading one document by Guido. Have you bothered doing
>a MINIMUM of homework, such as, looking at
> http://www.amk.ca/diary/archives/cat_python.html
>and specifically AMK's entry for September 30?
This complaint about "syntax cruft" is really weird, as while
browsing through the old and new docs I got the impression that
Python hasn't really changed so much as just added new, and
mostly well-chosen features. What's not to like in sets for
instance?!
However, I do have to concede that Python as environment
still has a way to go - not the language features are missing, but
better _standard_ IDE and debugger. E.g. Pythonwin debugger
sometimes simply dies on me, I have no idea why.
This is not to criticize the great work that you
guys are doing and the results of which we get FOR
FREE (something in principle I don't believe), but merely
to indicate that Python has grown and so did the
expectations. People tend to get spoilt: they expect to
find in a free product the gazillion of VS-like features. :-)
As we say here, "appetite tends to grow as you eat".
E.g. right now I would kill for a standard, built-in matrix
type that would be as flexible as lists and dictionaries are
in Python, so that I could slurp the whole CSV file or some
other table in one instruction into a matrix that could
accomodate data types likes strings and floats (just like
dictionaries do - just, say, declare, "column 1 of matrix
contains strings, and please convert the values in column 2
into floats"), and then easily do some fancy matrix
transformations.
Clean and expressive syntax plus flexibility of lists and
dictionaries are the main reasons I got into Python.
Where else could I do smth as neat as writing a
CSV header with:
DictWriterInstance.writerow(dict(zip(titles,titles)))
Note I didn't have to do any operations myself:
all that was necessary for me as a programmer was to
figure out how to connect the Lego pieces together.
We need more of this sort of expressive power in a
standard library and built-in types. This is the subconscious
power of attraction in Python I think. :-) I'm not a language
designer. I don't know how to get there. I just would love
to see more of that around.
To summarize, it's not the language that is would be
nice to develop further. Those are:
- more of the rich, flexible data types
- more extensive standard debugger
- possibly standard IDE with more features
that are typically found in commercial products
<now the evil me sits back, relaxes and watches
how properly motivated Alex and others get to work>
No, really, guys, great thanks for all that work.
--
Real world is perfectly indifferent to lies that
are the foundation of leftist "thinking".
Dave Brueck
That's my fear - type declarations could become one of the most abused language
features because they'd get used too often.
-Dave
Bulba!
<carri...@gmail.com> wrote:
>> Let's take one by one:
>I'll take only a few ;-)
>> - IDE: Better than what? Than IDLE? Than Eclipse? Than SPE? Than Pythonwin?
>
>I would like to seee Eric3, with some polish & opensourced on Win
>(which means solving the Qt licensing problem).
I second that. I still haven't used Eric3 much, which means I didn't
exploit it in full yet, but I like it a lot. And yes, Qt licensing is
a big problem for me, because for non-technical reasons I have
to work on Windows: when my eval Qt license runs out of time,
no more eric3 for folks like me.
Roman Suzi
>> It may be optional in the sense that the language will
>> accept missing declarations but as soon as the feature
>> is available it will become "mandatory" to use it
>> (peer pressure, workplace practices).
What about generic programming coming into fashion anytime soon?
>That's my fear - type declarations could become one of the most abused language
>features because they'd get used too often.
>
>-Dave
>
Sincerely yours, Roman Suzi
--
r...@onego.ru =\= My AI powered by GNU/Linux RedHat 7.3
Doug Holton
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.
Dave Brueck
> On Tue, 4 Jan 2005, Dave Brueck wrote:
>
>
>>>accept missing declarations but as soon as the feature
>>>is available it will become "mandatory" to use it
>>>(peer pressure, workplace practices).
>
>
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
Roman Suzi
>Roman Suzi wrote:
>>>>It may be optional in the sense that the language will
>>>>accept missing declarations but as soon as the feature
>>>>is available it will become "mandatory" to use it
>>>>(peer pressure, workplace practices).
>>
>>
>> What about generic programming coming into fashion anytime soon?
>
>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.
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.
>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?
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.
Terry Reedy
"Bulba!" <bu...@bulba.com> wrote in message
> E.g. right now I would kill for a standard, built-in matrix
> type
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.
> that would be as flexible as lists and dictionaries are
> in Python, so that I could slurp the whole CSV file or some
> other table in one instruction into a matrix that could
> accomodate data types likes strings and floats (just like
> dictionaries do - just, say, declare, "column 1 of matrix
> contains strings, and please convert the values in column 2
> into floats"), and then easily do some fancy matrix
> transformations.
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
Ian Bicking
>>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.
>
>
>>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?
>
>
> Python could have honest support of concepts. Everything else will be
> available with them.
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.
--
Ian Bicking / ia...@colorstudy.com / http://blog.ianbicking.org
Roman Suzi
>> What about generic programming coming into fashion anytime soon?
>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.
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.
holger krekel
On Wed, Jan 05, 2005 at 00:44 +0300, Roman Suzi wrote:
> 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?
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
Roman Suzi
>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.
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).
>"Python could have honest support of Concepts (url)"
- 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.
Dave Brueck
>>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.
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.
> Python could have honest support of concepts. Everything else will be
> available with them.
"Concepts" is a pretty generic term too! ;-) Do you mean concepts as defined
here: http://www.boost.org/more/generic_programming.html
?
> And BTW, are we really disputing?
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
Roman Suzi
>Roman Suzi wrote:
>>>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.
>
>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.
>
>> Python could have honest support of concepts. Everything else will be
>> available with them.
>
>"Concepts" is a pretty generic term too! ;-) Do you mean concepts as defined
>here: http://www.boost.org/more/generic_programming.html
>?
Yes.
>> And BTW, are we really disputing?
>
>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.
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.
Robert Kern
> "Bulba!" <bu...@bulba.com> wrote in message
>
>>E.g. right now I would kill for a standard, built-in matrix
>>type
>
>
> 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.
And one of the goals of numarray (which is a complete rewrite of
Numeric) *is* entry into the standard library.
--
Robert Kern
rk...@ucsd.edu
"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter
Paul Rubin
> Start writing (or reorganizing). Folks, this is open source. I'm
> sure by the traffic on the list most people here know how to write.
Irrelevant, the issue isn't what docs can be written if someone
wants to do it, it's what docs are actually already there. I mean
every shortcoming anyone could raise about Python or anything else
could have the same answer, "it's open source, go fix it". The
question is what does the existing stuff do.
> In the case of Tkinter, you should probably get the okay of the
> authors of various external docs before incorporating them into the
> Python docs,
If such permission is available then the external docs should just
be dropped into the distro.
> but note that several Tkinter-related documents are referenced
> directly from the Tkinter module docs:
Irrelevant, the Python docs mean the ones that are included, not the
ones that are merely referenced.
> This being the Internet and all, it's not clear that referencing external
> documentation is somehow worse than incorporating it directly into the
> distribution.
The same thing could be said for software. So why not eliminate the
Python library and let everyone download each module separately?
Because it's bogus is why. It really does matter whether something is
included or just referenced. That's what "batteries included" is
supposed to be about--you get ONE package and it's supposed to have
everything you need without having to go forage for additional
components. It matters because most users shouldn't need to care
about the Python distro at all, since they got Python through its
inclusion in some bigger distro. E.g., I'm now running the Python
that was included in Fedora Core 3 GNU/Linux, a complete OS distro on
a DVD-ROM, containing about 3 gigabytes not including sources. And
when a user installs 3 gigabytes of software from a DVD, they can
reasonably expect that they've installed a complete system and
shouldn't need to download anything additional to use all the features
of the programs on the DVD. Now the Fedora maintainers aren't Python
gurus--people ask for Python so they did the obvious thing: downloaded
it, ran its installer, put the output into their distro, and said "ok,
Fedora has Python". That's all they should need to do to incorporate
Python into Fedora. So it's up to the Python maintainers, not the
Fedora maintainers or the user, to make sure that the Python distro
has everything that users need, without further downloading.
And that was just about Tkinter, for which good docs exist but just
don't happen to be in the distro. How about something like
SocketServer, for which no reasonable docs exist at all? There's no
way to figure out how to use it without reading the source. Or the
socket library, whose docs say to go buy a book by W. Richard Stevens.
The book is very good, but having to go buy a proprietary book is the
opposite of what self-contained free software documentation is
supposed to mean.
I'm not trying to bash Python, which is excellent in many ways, or I
wouldn't be using it. I just see various other free software projects
as trying to live up to higher standards and I think Python should
aspire to the same thing.
> As for stuff that exists in PEPs and release notes, they should
> already all have the necessary copyright (either they were placed in
> the public domain or they are already part of the Python
> distribution) to allow you do just check out a CVS tree, make the
> necessary edits and either check the files back in or submit a patch
> to SourceForge.
And about that full featured Python web browser and native-code Python
compiler, all you have to do is go write it. Come on.
Having to piece together info from a dozen obscure and inconsistent
PEP's and stuff in the CVS tree and source comments is not what most
people think of as "documentation". Documentation means I can look in
the manual and the info is right there, properly referenced in the
table of contents and in the proper section for that type of language
feature, unified with the rest of the docs.
> In the documentation arena, I think more thought should probably be
> given to producing online docs that can be directly annotated, thus
> further reducing the barrier to more complete documentation (and
> more updates). Take a look at latex2html, propose or implement
> changes, or just rewrite the damn thing in Python. I think
> latex2html is probably a recurring nightmare for Fred Drake.
I've personally been happy with Texinfo for other kinds of docs and
would consider it easier to deal with than latex2html. It might even
be feasible to edit it in a wiki, so anyone could improve it easily.
Another idea is web-based doc comments like PHP and MySQL have, so the
doc editors can incorporate the info from the comments in subsequent
doc releases.
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
Skip Montanaro
Paul> Skip Montanaro <sk...@pobox.com> writes:
>> Start writing (or reorganizing). Folks, this is open source. I'm
>> sure by the traffic on the list most people here know how to write.
Paul> Irrelevant, the issue isn't what docs can be written if someone
Paul> wants to do it, it's what docs are actually already there.
How do you think we got the docs we already have? Somebody wrote them. If
there aren't enough docs or if they have mistakes, then somebody has to
correct them. I'm just suggesting that more people put their money where
they mouths are so-to-speak.
>> This being the Internet and all, it's not clear that referencing
>> external documentation is somehow worse than incorporating it
>> directly into the distribution.
Paul> The same thing could be said for software. So why not eliminate
Paul> the Python library and let everyone download each module
Paul> separately? Because it's bogus is why.
Paul> It really does matter whether something is included or just
Paul> referenced.
Okay, then start doing the work necessary to incorporate that stuff into the
core. Get Fredrik to say "okay" to including his Tkinter docs, then do what
it takes to incorporate it. The fact that Fredrik can check those docs in
himself but hasn't after several years suggests that he prefers the status
quo for one or more reasons.
I'm not saying references are perfect. I'm saying that given the time
constraints of the existing developer crowd and the relative priority of
various open tasks that folding in external documentation hasn't risen to
the top of the queue yet. The best way to make that happen is for it to be
your highest priority and then for you to make it happen. That's a
longer-winded way to say what I meant with "this is open source".
Paul> And that was just about Tkinter, for which good docs exist but
Paul> just don't happen to be in the distro. How about something like
Paul> SocketServer, for which no reasonable docs exist at all?
I'm at a loss. Is there something about this quote taken directly from the
section of the library reference manual entitled "Undocumented Modules" that
is unclear?
Here's a quick listing of modules that are currently undocumented, but
that should be documented. Feel free to contribute documentation for
them! (Send via email to do...@python.org.)
The list there is itself incomplete.
There is a reference manual section for SocketServer, btw:
http://www.python.org/doc/current/lib/module-SocketServer.html
If that needs examples or corrections or is incomplete, feel free to submit
a patch to either SourceForge or by email to do...@python.org.
Paul> I'm not trying to bash Python, which is excellent in many ways, or
Paul> I wouldn't be using it. I just see various other free software
Paul> projects as trying to live up to higher standards and I think
Paul> Python should aspire to the same thing.
I'm sorry, I don't know quite how to respond to that. Sure, I imagine there
are other communities that do it better. I've seen PHP mentioned here
recently, and have direct experience with CPAN (and actually like it pretty
well).
Look, I don't have much free time, and what free time I do have I mostly
spend moonlighting on other software (much to my wife's chagrin). I imagine
most of the other people who contribute to the Python distribution are
similarly time-afflicted. Here are a couple ideas:
1. Do you have more money than time? Donate a few bucks to the PSF:
Someone will probably do #2.
2. Do you have more time than money? Write a proposal to the PSF to
implement/improve/polish off some aspect of the distribution:
3. Got some free time and don't care about a few extra bucks? Check
out how to contribute to Python:
>> As for stuff that exists in PEPs and release notes, they should
>> already all have the necessary copyright (either they were placed in
>> the public domain or they are already part of the Python
>> distribution) to allow you do just check out a CVS tree, make the
>> necessary edits and either check the files back in or submit a patch
>> to SourceForge.
Paul> And about that full featured Python web browser and native-code
Paul> Python compiler, all you have to do is go write it. Come on.
Where did I say to go write a browser or a native-code Python compiler? If
that's your bag you can try resurrecting something Grail-like (browser) or
contribute time top PyPy or Psyco. When I said "write", I literally meant
write, as in English text.
Paul> Having to piece together info from a dozen obscure and
Paul> inconsistent PEP's and stuff in the CVS tree and source comments
Paul> is not what most people think of as "documentation".
Paul> Documentation means I can look in the manual and the info is right
Paul> there, properly referenced in the table of contents and in the
Paul> proper section for that type of language feature, unified with the
Paul> rest of the docs.
I was suggesting that maybe you might like to take the pieces and make them
something coherent. If it was trivial it would have probably been done by
now.
>> In the documentation arena, I think more thought should probably be
>> given to producing online docs that can be directly annotated, thus
>> further reducing the barrier to more complete documentation (and more
>> updates). Take a look at latex2html, propose or implement changes,
>> or just rewrite the damn thing in Python. I think latex2html is
>> probably a recurring nightmare for Fred Drake.
Paul> I've personally been happy with Texinfo for other kinds of docs
Paul> and would consider it easier to deal with than latex2html. It
Paul> might even be feasible to edit it in a wiki, so anyone could
Paul> improve it easily. Another idea is web-based doc comments like
Paul> PHP and MySQL have, so the doc editors can incorporate the info
Paul> from the comments in subsequent doc releases.
I rather like reST (much of www.python.org is being reimplemented in reST),
but that's just me. The key point I was trying to make is that an
annotation capability would probably help. With such a feature you could
add examples or links to the online Python Cookbook, whatever. Need some
ideas? Look here:
http://www.amk.ca/diary/archives/003336.html
As Andrew indicated, it's a "half-hour hack", but it might give someone
something to think about.
Skip
Jeremy Bowers
> Irrelevant, the issue isn't what docs can be written if someone wants to
> I just see various other free software projects as
> trying to live up to higher standards and I think Python should aspire to
> the same thing.
So, nobody should have to write the docs because they should already be
there, but "somebody" should have to write the docs?
You need to think more clearly about the pronouns you are slinging around.
Who is this "they" that should write the docs? (Yes, I know you didn't use
that exact word but the concept is clearly there.) And what right do you
have to demand this action from "they"? Are you willing to pay me to do it?
Paul Rubin
> So, nobody should have to write the docs because they should already be
> there, but "somebody" should have to write the docs?
>
> You need to think more clearly about the pronouns you are slinging around.
> Who is this "they" that should write the docs?
The Python advocates who claim that Python is well-documented and take
exception to when someone say it isn't. Their idea of "it's
well-documented" seems to be "if there's parts that you think are
poorly documented, feel free to document it". What kind of nonsense
is that? "Python code runs just as fast as C code. If you think it's
slower, feel free to speed it up". "Python's standard library
includes a database module. If it isn't there, feel free to add one".
"Programming in Python cures cancer. If your cancer doesn't clear up
when you code in Python, feel free to submit a patch".
Software advocacy, which Python has an awful lot of, involves
extolling the virtues of a program as it exists in the present. Not
as it could potentially exist if someone hypothetically added a bunch
of work that hasn't yet been done. Python is good software, but its
advocates are making claims that Python itself doesnt live up to.
And no, I don't feel a responsibility to do the missing work, since
I'm not the one making those advocacy claims.
Peter Hansen
> Jeremy Bowers <je...@jerf.org> writes:
>>So, nobody should have to write the docs because they should already be
>>there, but "somebody" should have to write the docs?
>>
>>You need to think more clearly about the pronouns you are slinging around.
>>Who is this "they" that should write the docs?
>
> The Python advocates who claim that Python is well-documented and take
> exception to when someone say it isn't. Their idea of "it's
> well-documented" seems to be "if there's parts that you think are
> poorly documented, feel free to document it". What kind of nonsense
> is that? "Python code runs just as fast as C code. If you think it's
> slower, feel free to speed it up". "Python's standard library
> includes a database module. If it isn't there, feel free to add one".
> "Programming in Python cures cancer. If your cancer doesn't clear up
> when you code in Python, feel free to submit a patch".
I think you're throwing out strawman arguments here.
The key distinction is that "well-documented" is clearly
a judgment call, a personal opinion, while the others
are all measurable absolutes. (The "as fast as C" one borders
on being an opinion, since most people actually say things that
mean something more like "as fast as I need it to, so C has no
advantage".)
Saying, in effect, as they are, "Python's docs are well enough
documented for my purposes and, I believe, for those of many
other people" certainly isn't nonsense, and saying "and if you
don't agree you should consider improving them yourself
instead of asking me or others who feel as I do" is certainly
not nonsense.
> And no, I don't feel a responsibility to do the missing work, since
> I'm not the one making those advocacy claims.
So those who claim Python is well-documented are the ones who
should improve the documentation, but those claiming that
the documentation is poor should feel no responsibility to
make the improvements?
Does this make any sense to you? To me, *this* is the nonsense.
-Peter
alex23
> The Python advocates who claim that Python is well-documented and
take
> exception to when someone say it isn't. Their idea of "it's
> well-documented" seems to be "if there's parts that you think are
> poorly documented, feel free to document it". What kind of nonsense
> is that?
It's called "having an opinion". "Good" documentation does its job, if
noone else thought it was poorly documented then to them it wasn't.
The only person who knows how the current documentation is
unsatisfactory to you is *you*.
The mistake being made here by the OS community is the assumption,
based on their own personal experiences, that others will take the
absence of something as a challenge to fill it themselves, serving the
dual role of obtaining what they need for their own purposes AND
providing it for the purposes of others. It's a mistaken assumption
because for most people it's easier to gripe that someone else, oh
let's say "advocates", should be doing it for you.
> "Python code runs just as fast as C code. If you think it's
> slower, feel free to speed it up".
The objective, qualifiable speed of Python has *what* exactly to do
with the subjective, interprative assessment of the Python
documentation?
> "Python's standard library includes a database module. If it isn't
there,
> feel free to add one".
Which part of the open source movement do you just not get?
> "Programming in Python cures cancer. If your cancer doesn't clear up
> when you code in Python, feel free to submit a patch".
Wow, you quickly ran out of points of blind Pythonic advocation, didn't
you?
> Software advocacy, which Python has an awful lot of, [...]
Unjustifiable claims, which your postings have an awful lot of...see
how easy it is to characterise someones position in the negative? See
how pointless it is for useful dialogue?
You've done nothing but kvetch about how others aren't providing you
with what you need. Let's face it, people like you are never going to
take the initiative and actually contribute something when you're
already quite comfortable sponging off the efforts of others and hiding
behind claims of advocacy whenever anyone questions your own
motivations.
In short: grow up and just write the damn documentation.
- alex23 -
Paul Rubin
> The key distinction is that "well-documented" is clearly
> a judgment call, a personal opinion,
No it's not. If a program has significant modules with complicated
public API's and no documentation, it's poorly documented in an
absolute sense. A well-documented program includes docs for all
the public API's.
> So those who claim Python is well-documented are the ones who
> should improve the documentation, but those claiming that
> the documentation is poor should feel no responsibility to
> make the improvements?
Yes, precisely so. Like if someone says "I've written this fantastic
math package, it's fast and accurate and solves every problem
perfectly, let's start a newsgroup about how to convince our PHB's to
use it and why it's so much better than every other math package
that's ever been written", and I try the package and it says that
2+2=5 and I report that bug, I've made a constructive comment and have
no further responsibility. I've also shown that the program doesn't
live up to its claims and people wanting to do real work with it
should watch out. If the developers want to keep making the grand
claims, they should fix the bug. If they want to say "this package is
technically cool but gets some answers wrong, maybe you don't want to
do anything serious with it but it's fun to play with", that's
different. But there's a constant current in clpy of "Python is great
for everything, our PHB's should all embrace it, it supports protocols
X, Y, and Z and is great for that kind of application" when those
protocols turn out to be only half-implemented, or "it's
well-documented" when the manual turns out to be only half-complete.
And the responses I see sound almost like "2+2=5 is an accurate
answer, and if you think it's not close enough, it's open source, so
fix it".
If you want to see a really well-done (at least in parts, and also
poorly documented but not making claims to the contrary) Python
program, take a look at Twisted Matrix. It reimplements any number of
features that are already in Python. An early version of the docs
explained the reason. It said something like "it may look like we're
re-inventing the wheel, but we have no choice, since the existing
wheel is square and made of glue".
> Does this make any sense to you? To me, *this* is the nonsense.
I don't see any nonsense. People who make claims about a program are
the ones responsible for the truth of the claims. Saying anyone else
is responsible is bizarre.
Paul Rubin
> It's called "having an opinion". "Good" documentation does its job, if
> noone else thought it was poorly documented then to them it wasn't.
Obviously other people thought Tkinter is poorly documented in the
Python distro, since the Python library manual says so itself and
invites people to look at external references instead.
> > Software advocacy, which Python has an awful lot of, [...]
>
> Unjustifiable claims, which your postings have an awful lot of...
I've justified every claim I've made.
> You've done nothing but kvetch about how others aren't providing you
> with what you need. Let's face it, people like you are never going
> to take the initiative and actually contribute something when you're
> already quite comfortable sponging off the efforts of others and
> hiding behind claims of advocacy whenever anyone questions your own
> motivations.
I'm not one of the Python developers, I'm just a user, I have my own
projects that I spend my time on. I like the idea of using Python in
some of those projects. Python advocacy revolves around encouraging
people to use Python in their projects, without having to be Python
developers themselves. Python advocates say "Python does what you
need, so use it". That's supposed make Python sound attractive. If
the real truth is "Python does something sort of related to what you
need, so if besides your own project that you need to finish, you are
willing to stop in the middle and take on some additional projects of
improving Python, it can end up being useful for your task", that's a
lot less attractive.
I'm happy to use Python, as it is, for various kinds of noncritical
and throwaway tasks. For critical projects I'm looking for tools that
work (e.g. Linux, Apache, GCC), not "it's open source, go fix it".
But just one or two days ago, various people on this group were urging
me to do a critical project in Python instead of Java. I like Python
enough to get into these romantic quarrels with it (which is what
you're seeing now) and feel pretty cold toward Java. But while Java's
libraries are poorly designed, their implementations tend to be quite
complete, while Python's are well-designed but often incompletely
implemented. And so with Java, I feel much less likely to look in the
manual and note the existence of some feature and plan to use it, only
to find out after it's too late, that the feature's implementation is
missing some crucial functionality that would be a lot of work to add.
(Then there's issues with the languages themselves, that are separate).
> In short: grow up and just write the damn documentation.
In short, I should grow up and quietly ignore a lot of Python advocacy
as being groundless and just use Python for limited purposes. But
what I want instead is for Python itself to grow up, and do things
properly instead of half-assedly.
Ville Vainio
Paul> inclusion in some bigger distro. E.g., I'm now running the
Paul> Python Python into Fedora. So it's up to the Python
Paul> maintainers, not the Fedora maintainers or the user, to make
Paul> sure that the Python distro has everything that users need,
Paul> without further downloading.
To me, this seems to be the job for the Fedora maintainers, not Python
maintainers. If something essential is not in the distro the distro
maintainers have screwed up.
Paul> And that was just about Tkinter, for which good docs exist
Paul> but just don't happen to be in the distro. How about
I think most people these days do a google search when they are
learning how to use a feature to get the whole story. It's often also
faster than finding the information in the bundled documentation -
even if the first google hit often happens to refer to the page with
the very documentation thu user would have looked up.
Paul> The book is very good, but having to go buy a proprietary
Paul> book is the opposite of what self-contained free software
Paul> documentation is supposed to mean.
I'm not sure the free software documentation is going to evolve to be
more self-contained; the exact opposite is more likely.
--
Ville Vainio http://tinyurl.com/2prnb
michele....@gmail.com
> I'm now running the Python
> that was included in Fedora Core 3 GNU/Linux, a complete OS distro on
> a DVD-ROM, containing about 3 gigabytes not including sources. And
> when a user installs 3 gigabytes of software from a DVD, they can
> reasonably expect that they've installed a complete system and
> shouldn't need to download anything additional to use all the
features
> of the programs on the DVD. Now the Fedora maintainers aren't Python
> gurus--people ask for Python so they did the obvious thing:
downloaded
> it, ran its installer, put the output into their distro, and said
"ok,
> Fedora has Python". That's all they should need to do to incorporate
> Python into Fedora. So it's up to the Python maintainers, not the
> Fedora maintainers or the user, to make sure that the Python distro
> has everything that users need, without further downloading.
Dunno about Fedora, I stopped using Red Hat just because they were
*not* using
the standard Python distribution, and the version they shipped was
cripped in various
ways. There is nothing the Python developers can do if the OS vendors
choose to ship
modified Python distributions, with missing modules or splitted in n
separated packages
to download separately.
Michele Simionato
EP
> Maybe OP doesn't yet fully comprehend the ways of Python universe?
<snip>
> > Don't misinterpret this response. I know it was a rambling. But
> *maybe* you
> > have something to contribute to Python development, even good ideas
> only and
> > no work.
> >
> > . Facundo
Am I selling Snake Oil?
Here's my observation, which must be taken with the grain of salt that I am simply not a smart nor seasoned enough programmer to understand some of the considerations for the new language features. It's over my head - there, I said it.
What I do have is a "forest" instead of an "in the trees" perspective, and from a forest view I see a lot of defensiveness about Python's hypothetical shortcomings. No one needs be defensive, Python is an amazing programming language, and everyone involved with its development, evolution, support and codebase ought to feel quite good about it.
So there should be a lot of clapping each other on the shoulder and the clinking of beer bottles in toasts.
The next morning we get up, we ought to look at our bed mate and think over some coffee whether this is someone who will be our lifelong friend, or if we want it to be much more than that. Because taking it to the next level, to it's ultimate potential, is not a linear exercise and requires non-linear thinking, strategy, and execution (and no doubt greater commitment.)
It would not be ground breaking for me to assert that undertakings reach plateaus as they grow in magnitude and scope. A company, for example, must re-invent itself several times on the way to greatness from the couple folks gathered around the kitchen table, and this is not just at low levels. Companies reach plateaus, for example, around points like $1 billion in annual revenue -- to keep growing and get to, let's say, $5 billion, they have to re-invent themselves with a new and greater vision.
It would be easy to miss this with our heads buried in code, or with our minds occupied with either the defense of Python or a debate about what a "concept" is. [tongue in cheek]
I use Python everyday; I've liked it from the first five minutes, and I like it more all the time. I hope it is always maintained because it would be a shame to ever lose such a powerful and joyful tool.
I also think Python affords a view of what might be great things in the distance, but perhaps the journey required to get there is more like crossing an ocean than simply walking down the road. Not knowing how to cross the ocean doesn't mean there isn't milk and honey on the other side, nor that the journey should be written off; but there is no guarantee that Python is the right vehicle to get us there, and if it is it may need to grow organic gills.
I'm of two minds, that (1) Python is perfect as is and (2) that "it" needs radical (non-linear) improvements in development environment, documentation, and execution speed to reach its potential in terms of application and acceptance. Where and how far the community wants to take Python would be something to figure out before debating what needs to be changed about it, if there is a desire to take it to a potential on a new level.
Python: it tastes so good it makes you hungrier.
Eric Pederson
- - - - - - - - - - - - - -
Perfect indifference and assuming one perceives the "real world" are the essential lies against the natural universe - a "leftist"
- - - - - - - - - - - - - -
Roman Suzi
>Roman wrote:
>
>> Maybe OP doesn't yet fully comprehend the ways of Python universe?
>
><snip>
>
>> > Don't misinterpret this response. I know it was a rambling. But
>> *maybe* you
>> > have something to contribute to Python development, even good ideas
>> only and
>> > no work.
>> >
>> > . Facundo
>
>
>Am I selling Snake Oil?
>
>What I do have is a "forest" instead of an "in the trees" perspective, and
>from a forest view I see a lot of defensiveness about Python's hypothetical
>shortcomings. No one needs be defensive, Python is an amazing programming
>language, and everyone involved with its development, evolution, support and
>codebase ought to feel quite good about it.
-skip-
It's c.l.p and people are free to express their opinions. Even negative.
This helps improve Python.
As for concepts, they are from Generic Programming (by Musser and Stepanov)
and I feel that Python is in position to implement them to the fullest extent.
And IMHO it will be nicer than just Java-like interfaces or Eiffel's contract
approach.
I can try to write a PEP "Generic Programming Concepts".
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: carri...@gmail.com
mail: carri...@yahoo.com
Paul Rubin
> To me, this seems to be the job for the Fedora maintainers, not Python
> maintainers. If something essential is not in the distro the distro
> maintainers have screwed up.
I can't parse that. It says two contradictory things. Sentence 2
says that if something essential is not in the (Python) distro then
the (Python) distro maintainers have screwed up. Sentence 1 says
it's the Fedora maintainer's job to deal with it. Huh?
> Paul> The book is very good, but having to go buy a proprietary
> Paul> book is the opposite of what self-contained free software
> Paul> documentation is supposed to mean.
>
> I'm not sure the free software documentation is going to evolve to be
> more self-contained; the exact opposite is more likely.
With software, I don't think you're right. With documentation, I
don't have a sense of whether you're right or not, but I hope you
aren't right.
Paul Rubin
> Dunno about Fedora, I stopped using Red Hat just because they were
> *not* using the standard Python distribution, and the version they
> shipped was cripped in various ways.
Eh? I used Red Hat for a long while and don't remember their crippling
the Python distribution. I do remember their believing the Python
advocates that Python was a stable language, and therefore building
critical features around it, and being unwilling to upgrade between
major Python releases during minor Red Hat release cycles. The result
was that RH 7.x shipped with Python 1.5.x for quite a long time after
Python 2.x had been released. However I don't remember anything being
crippled about the 1.5.x installations.
Paul Rubin
> Python: it tastes so good it makes you hungrier.
QOTW
Paul Rubin
> As for concepts, they are from Generic Programming (by Musser and
> Stepanov) and I feel that Python is in position to implement them to
> the fullest extent. And IMHO it will be nicer than just Java-like
> interfaces or Eiffel's contract approach.
I keep hearing that term (GP). Can someone explain in a few sentences
what it means, without resorting to marketing buzzwords?
There is nothing in Wikipedia about it.
Paul Rubin
Oops: http://en.wikipedia.org/wiki/Generic_programming
This helps. But I don't see how it's different from what used to
be called polymorphism.
huy
> The Python advocates who claim that Python is well-documented and take
> exception to when someone say it isn't. Their idea of "it's
> well-documented" seems to be "if there's parts that you think are
> poorly documented, feel free to document it". What kind of nonsense
> is that?
I'm not sure which planet you come from but open source is open source
for a reason. IMO gratitude is the only thing which can be given back to
the contributors of open source projects not "what you've given me for
FREE is not good enough, go back and do a better job (and by the way I
don't really know how you can do a better job) so I can make money off
your free time". I don't even expect this much from software I pay for.
Being a python user (not contributer) for the past few years I
personally think the Python docs are GREAT. If it's not in the
reference, it can be found in the source (again thank god for open
source), if it's not in the source you have google, then google groups
then ASPN python cookbook. If you're not smart enough to do this, well
learn. It'll help you become a better programmer.
Anyone who thinks Python docs suck haven't browsed javadocs lately, or MSDN.
> Software advocacy, which Python has an awful lot of, involves
> extolling the virtues of a program as it exists in the present. Not
> as it could potentially exist if someone hypothetically added a bunch
> of work that hasn't yet been done. Python is good software, but its
> advocates are making claims that Python itself doesnt live up to.
You should be more accurate. Quote "Python is good software, but its
advocates are making claims that [you think it] doesnt live up to". I
guess everyone is allowed to have their own opinion.
> And no, I don't feel a responsibility to do the missing work, since
> I'm not the one making those advocacy claims.
Good on ya.
Huy
Alex Martelli
...
> 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.
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
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.
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
Skip Montanaro
Paul> This helps. But I don't see how it's different from what used to
Paul> be called polymorphism.
I think of generic programming as polymorphism for statically typed
languages. Using the example from the Wikipedia reference, you can't have a
generic List class that can hold a list of ints as well as a list of animals
without using templates.
Skip
Roman Suzi
>Dave Brueck <da...@pythonapocrypha.com> wrote:
> ...
>> 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.
>
>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.
That is why I was pretty sure people undestand me.
>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.
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.
Roman Suzi
I already posted these links. They seem to give more fundamental
definitions than wikipedia:
'''
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.
'''
As for polymorphism, yes, polymorphism. But any decent language has some sort
of polymorphism today. The essense of concepts is that they provide
formalities for (call them) contracts, interfaces, etc. Concepts from GP
gather all these together and call it a concept: a family of similar types.
Python already uses concepts implicitly, by convention. And we know them well:
file-like objects, sequences, maps, sets, queues, arrays, etc.
My "marketing" of GP is directed to formalise on concepts instead of
partial cases (design-by-contract, interfaces etc).
Thus, concepts control polymorphism not only from liberation side, but
from constraint side too. Right now concepts in Python are reused
here and there without explicit mentioning. Concepts could help
make code even more reusable.
Ville Vainio
Paul> Ville Vainio <vi...@spammers.com> writes:
>> To me, this seems to be the job for the Fedora maintainers, not
>> Python maintainers. If something essential is not in the distro
>> the distro maintainers have screwed up.
Paul> I can't parse that. It says two contradictory things.
Paul> Sentence 2 says that if something essential is not in the
Paul> (Python) distro then the (Python) distro maintainers have
Paul> screwed up. Sentence 1 says it's the Fedora maintainer's
Paul> job to deal with it. Huh?
By "distro" I meant the Linux distribution, not the Python
distribution. Distro is a customary term for a Linux distribution so I
didn't qualify the word at the time.
Paul Rubin
> Paul> I can't parse that. It says two contradictory things.
> Paul> Sentence 2 says that if something essential is not in the
> Paul> (Python) distro then the (Python) distro maintainers have
> Paul> screwed up. Sentence 1 says it's the Fedora maintainer's
> Paul> job to deal with it. Huh?
>
> By "distro" I meant the Linux distribution, not the Python
> distribution. Distro is a customary term for a Linux distribution so I
> didn't qualify the word at the time.
Oh ok, but it's the Python distribution that's missing components that
are essential to Python. Fedora and other Linux distros are
collections of subsystems like Python. Linux distro maintainers get
asked to include a subsystem, they check that the subsystem has a
reasonable reputation (Python does), they install it in the distro and
run some basic tests, and they ship it. They can't be expected to
immerse themselves in its intricacies and hang out on the user forums
to identify all the missing components that they should also hunt down
and ship. So the Python needs to take care of that stuff.
I realize that in the old days, people used to write big applications
without makefiles, and later when they started using makefiles, they
didn't use configure scripts. So to install a package, you had to do
a bunch of hand configuration for your particular environment before
you could compile it, and maybe you even had to say
cc -O -Dthisflag=thatnumber xyz.c pqr.c frob.c -o frob
on the command line instead of typing "make" to build the program.
That kind of thing really doesn't fly any more. The standards for
what constitutes a properly engineered release of something have
gotten higher. You really need automatic configuration and build and
installation. Likewise, if you're trying to market something as a
complete drop-in system ("batteries included", to use the Python
terminology), it should not be missing any essential pieces that
the user has to hunt down separately.
John Roth
news:7xhdlwh...@ruckus.brouhaha.com...
> "alex23" <wuw...@gmail.com> writes:
>> It's called "having an opinion". "Good" documentation does its job, if
>> noone else thought it was poorly documented then to them it wasn't.
...
>
>> In short: grow up and just write the damn documentation.
I've been reading this thread and quietly congratulating myself
on staying out of it, but this statement takes the cake.
I would like to contribute some documentation to Python.
I've got the time, I write quite a bit, etc. I've got fairly
strong opinions about some things that need to be documented,
(such as all the new style class descriptor stuff from 2.2)
and I have relatively little difficulty matching the existing style.
However, I don't
know TEX, Latex, CVS or Sourceforge. (The latter two are
on my "learn sometime soon so I can put PyFIT where it belongs"
list.)
I have no desire to install Perl to run the documentation toolchain.
I also have no particular desire to write up a bunch of final
format stuff and drop it on someone else to put into the latex
format so it can be included.
That means I'm not going to spend literally months learning
all of this stuff so I can then spend the two or three days
(each) it would take to write decent documentation for the
places I think are lacking, and where I have the
competence to write it up.
I'm also not going to spend those same months writing
a current source to XML translator, and then writing
XSLT or more scripts to do the translations to final
format, a strategy which would arguably be much more
beneficial for the Python community as a whole.
The bottom line is that I'm not going to be writing any
extensive pieces of Python documentation. My time
is better spent elsewhere.
John Roth
Alex Martelli
> 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.
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
Paul Rubin
> Okay, then start doing the work necessary to incorporate that stuff into the
> core. Get Fredrik to say "okay" to including his Tkinter docs, then do what
> it takes to incorporate it. The fact that Fredrik can check those docs in
> himself but hasn't after several years suggests that he prefers the status
> quo for one or more reasons.
I thought that we had been through this already, and permission from
Frederik was not forthcoming. Either he has his own plans for those
docs, or he has some obligation to someone else to not release them.
The Tkinter reference at
http://infohost.nmt.edu/tcc/help/pubs/lang.html
is actually the best doc I've seen on tkinter so far, but it's only
available in ps/pdf format and again, would need permission for
inclusion in Python.
> There is a reference manual section for SocketServer, btw:
>
> http://www.python.org/doc/current/lib/module-SocketServer.html
>
> If that needs examples or corrections or is incomplete, feel free to submit
> a patch to either SourceForge or by email to do...@python.org.
It's been a while since I really had to wrestle with SocketServer, but
that its docs were quite inadequate and I had to study the source code
for quite a while to grok how to use it.
> Look, I don't have much free time, and what free time I do have I mostly
> spend moonlighting on other software (much to my wife's chagrin). I imagine
> most of the other people who contribute to the Python distribution are
> similarly time-afflicted. Here are a couple ideas:
Thanks, but I'm not in the business of promoting Python. I like to
think I contribute in some minor ways by submitting bug reports and
occasional small patches. I made a conscious decision to not spend
time on big patches since Python is non-GPL, and I'd rather spend my
limited volunteer time on GPL projects, working on non-GPL projects
only if I'm getting paid for it. I offered to make an exception once
to contribute some functionality that I felt was important for Python
users, but it was declined.
What I see going on in clpy all the time though, is people asking
whether Python is good for some type of project, and always getting
told "yes" no matter what the project is. If the "yes" means that in
addition to doing your own project, you find out in the middle that
you also have to add features to Python that other languages already
support, that makes your project finish behind schedule and whoever
told you Python was good for your project really did you a disservice.
I'm reacting to that phenomenon in this thread, along with possible
others.
> 1. Do you have more money than time? Donate a few bucks to the PSF:
Nah, I'd rather donate to the FSF if I have the bucks to spare. If I
want to fund the development of proprietary Microsoft products, I'm
better off sending the money directly to Bill G. Of course I'm happy
if PSF gets corporate donations, but that's different than someone
like me operating as a free software activist.
> 2. Do you have more time than money? Write a proposal to the PSF to
> implement/improve/polish off some aspect of the distribution:
Huh? Do you mean like a funding proposal, where PSF would use some of
those donations to hire me to develop something? I guess I'd consider
that in principle, but I'm probably not PSF's favorite person right
now, and unlikely to get hired. And anyway, I have other commitments
right now and couldn't take on anything like that.
> Where did I say to go write a browser or a native-code Python compiler? If
> that's your bag you can try resurrecting something Grail-like (browser) or
> contribute time top PyPy or Psyco. When I said "write", I literally meant
> write, as in English text.
I don't experience much difference between writing text and writing
code. If I say the docs are missing something and you tell me to fix
them, that's not much different than telling me to go write missing code.
Re browsers and compilers: I think a Python browser depends on a good
GUI toolkit and right now Python only has Tkinter. (There are
toolkits like wxpython but Python doesn't "have" them; they exist
separately).
I think the PyPy group is doing real well with compilers, or at least
knows what its doing. I want to wait til PyPy is actually deployed
before I pay too much attention to Python compilation, since I think
supporting good compilation should actually drive the Python 3000
language design, and PyPy will make it much easier to experiment with
new or changing language features.
> Paul> Having to piece together info from a dozen obscure and
> Paul> inconsistent PEP's and stuff in the CVS tree and source comments
> Paul> is not what most people think of as "documentation".
>
> I was suggesting that maybe you might like to take the pieces and
> make them something coherent. If it was trivial it would have
> probably been done by now.
I just avoid using those features. If they're not documented they
probably don't work that well either.
> I rather like reST (much of www.python.org is being reimplemented in reST),
I don't know what that is.
> Look here:
>
> http://www.amk.ca/diary/archives/003336.html
>
> As Andrew indicated, it's a "half-hour hack", but it might give someone
> something to think about.
That's pretty cute and python.org should link to it.
Alex Martelli
...
> > - IDE: Better than what? Than IDLE? Than Eclipse? Than SPE? Than Pythonwin?
>
> I would like to seee Eric3, with some polish & opensourced on Win
> (which means solving the Qt licensing problem). Perhaps someone could
> convince Trolltech to release a special Qt Win version just for it
> (Eric3). Eclipse is also an interesting approach.
I love eric3, but if you're an eclipse fan, look at enthought's
"envisage" IDE -- it seems to me that it has superb promise.
> wish I could simply plug & play DBAPI modules in a totally seamlessly
> way. Anyone who tried know how far are we of this dream.
If you manage to get there, you'll start fighting against the different
dialects of SQL supported by the various back-ends, as is well known by
anybody who tried, say, ODBC or ADO, which do manage good plug&play of
their components but still can't solve the real hard one:-(
Alex
Aahz
John Roth <newsg...@jhrothjr.com> wrote:
>
>I would like to contribute some documentation to Python. I've got
>the time, I write quite a bit, etc. I've got fairly strong opinions
>about some things that need to be documented, (such as all the new
>style class descriptor stuff from 2.2) and I have relatively little
>difficulty matching the existing style.
>
>However, I don't know TEX, Latex, CVS or Sourceforge. (The latter two
>are on my "learn sometime soon so I can put PyFIT where it belongs"
>list.)
>
>I have no desire to install Perl to run the documentation toolchain.
So don't! The editors for the Python docs are extremely happy to take
raw ASCII (or reST if you're up for that) and convert it to Python's
formatting rules. See 2.4's "Documenting Python" -- I finally convinced
the editors to make the policy explicit.
It would be highly desirable for you to learn SourceForge, though; that
way it would be easy for you to participate in the bug/patch process.
But even that isn't essential.
>I also have no particular desire to write up a bunch of final format
>stuff and drop it on someone else to put into the latex format so it
>can be included.
Not clear what you mean here.
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
"19. A language that doesn't affect the way you think about programming,
is not worth knowing." --Alan Perlis
Bulba!
wrote:
>
> 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.
>
> 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.
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?
>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.
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'). :-)
--
It's a man's life in a Python Programming Association.
Carlos Ribeiro
> Carlos Ribeiro <carri...@gmail.com> wrote:
> ...
> > > - IDE: Better than what? Than IDLE? Than Eclipse? Than SPE? Than Pythonwin?
> >
> > I would like to seee Eric3, with some polish & opensourced on Win
> > (which means solving the Qt licensing problem). Perhaps someone could
> > convince Trolltech to release a special Qt Win version just for it
> > (Eric3). Eclipse is also an interesting approach.
>
> I love eric3, but if you're an eclipse fan, look at enthought's
> "envisage" IDE -- it seems to me that it has superb promise.
Hint noted.
> > wish I could simply plug & play DBAPI modules in a totally seamlessly
> > way. Anyone who tried know how far are we of this dream.
>
> If you manage to get there, you'll start fighting against the different
> dialects of SQL supported by the various back-ends, as is well known by
> anybody who tried, say, ODBC or ADO, which do manage good plug&play of
> their components but still can't solve the real hard one:-(
Ian Bicking's SQLObject goes a long way to solve this problem. It's a
ORM, not a complete relational solution, mind you. However, while it's
architecturally oriented towards solving the high-level SQL-to-object
mapping issues, a good deal of time is spent solving things that a
common plug & play API could solve.
IOW: the hard problem really does exist. However, we never come to
face it because we're still stuck in the "easy" one. :-(
Daniel Bowett
> [Daniel Bowett]
>
> #- Contribute to where on Sourceforge??? Which domentation are
> #- we talking
> #- about in general?
>
> Suppose you're reading Python documentation. Don't know, for example,
> os.remove(). There you find that a particular parragraph is difficult
> to understand. You say "Hey, this could be better written", so you
> write i a more pedagogic way.
>
> After that you go to SF, Python project
> (http://sourceforge.net/projects/python), and go to Bugs. There, if
> you are logged in SF, you will see a "Submit new" link. You click on
> it and you'll see a form to fill.
>
> Select some fields (specially bug group in "Documentation") and in
> "Detailed Description:" you put something like "This particular
> sentence was difficult to read. Attaching a new way to write it". Of
> course, then attach the file of your text (if it's short enough you
> can put it directly in that field).
>
> Of course, if you write any NEW documentation about something that is
> not documented at all, or find some more serious issues with the docs
> (for example, bad argument count in a function) you can follow the
> same steps.
>
> . Facundo
>
> Bitácora De Vuelo: http://www.taniquetil.com.ar/plog
> PyAr - Python Argentina: http://pyar.decode.com.ar/
>
>
> * . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> . . . . . . . . . . . . . . . . . . . . . .*
>
> *_ADVERTENCIA._*
>
> *La información contenida en este mensaje y cualquier archivo anexo al
> mismo, son para uso exclusivo del destinatario y pueden contener
> información confidencial o propietaria, cuya divulgación es sancionada
> por la ley.*
>
> *Si Ud. No es uno de los destinatarios consignados o la persona
> responsable de hacer llegar este mensaje a los destinatarios
> consignados, no está autorizado a divulgar, copiar, distribuir o
> retener información (o parte de ella) contenida en este mensaje. Por
> favor notifíquenos respondiendo al remitente, borre el mensaje
> original y borre las copias (impresas o grabadas en cualquier medio
> magnético) que pueda haber realizado del mismo.*
>
> *Todas las opiniones contenidas en este mail son propias del autor del
> mensaje y no necesariamente coinciden con las de Telefónica
> Comunicaciones Personales S.A. o alguna empresa asociada.*
>
> *Los mensajes electrónicos pueden ser alterados, motivo por el cual
> Telefónica Comunicaciones Personales S.A. no aceptará ninguna
> obligación cualquiera sea el resultante de este mensaje.*
>
> *Muchas Gracias.*
>
Thanks, typically how long does it take for any documentation to be
considered and implemented?
Aahz
Daniel Bowett <dan...@bowettsolutions.com> wrote:
>
>Thanks, typically how long does it take for any documentation to be
>considered and implemented?
It varies. (I could write a much longer response, but it would boil
down to the same thing. ;-)
alex23
John Roth wrote:
> I've been reading this thread and quietly congratulating myself
> on staying out of it, but this statement takes the cake.
Honestly, I feel the same way about statements of your's like this:
> The bottom line is that I'm not going to be writing any
> extensive pieces of Python documentation. My time
> is better spent elsewhere.
The question is: *whose* time do you consider better spent on writing
Python documentation *for you*?
That is what I'm so incredulous about, the tone of demand in the
original post (and also very visible in your quoted remark above) that
insists this is *someone else's* responsibility.
Again: if you want the documentation that badly, then you want to do
what said documentation would illustrate. If you *really* want to do
that, then you'll take the time to find out how it's done *anyway*,
document it up as you go, no matter how briefly, and make a *start* on
filling in what *you* perceive as being a void in the current
documentation.
But to point out how laborious a process it is and how your time is too
valuable to undertake it personally...it's difficult to parse that any
other way than "I want other people to do all the hard work for me".
Terry Reedy
"John Roth" <newsg...@jhrothjr.com> wrote in message
news:10to8qu...@news.supernews.com...
> I would like to contribute some documentation to Python.
> I've got the time, I write quite a bit, etc. I've got fairly
> strong opinions about some things that need to be documented,
> (such as all the new style class descriptor stuff from 2.2)
> and I have relatively little difficulty matching the existing style.
I would love to see the written better and in the manuals.
> However, I don't
> know TEX, Latex, CVS or Sourceforge. (The latter two are
> on my "learn sometime soon so I can put PyFIT where it belongs"
> list.)
Neither do I.
> I have no desire to install Perl to run the documentation toolchain.
> I also have no particular desire to write up a bunch of final
> format stuff and drop it on someone else to put into the latex
> format so it can be included.
Why not? If someone is willing to do the part that is easier for him
(format pre-written ascii text), why aren't you willing to do the part that
is easier for you (write the text)?
I am asking as someone who has done just that, at least on a micro scale of
occasional sentences in response to bug reports.
Terry J. Reedy
Terry Reedy
"Daniel Bowett" <dan...@bowettsolutions.com> wrote in message
news:41DC4BA2...@bowettsolutions.com...
>Thanks, typically how long does it take for any documentation to be
>considered and implemented?
Right now, rough guess, based on my haphazard collection of knowledge and
experience, I would anticipate 1 to 60 days for up to a paragraph.
Terry J. Reedy
Robert Kern
> 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
[snip for brevity]
> 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?
I'm not sure what you mean by "written by hand." Someone is going to
have to write the functions in the first place. Sure, they can be
written once, well, and placed in the standard library so they don't
have to be *re*written by anyone else again.
I still think numarray is a good start for this. It handles more than
just numbers. And RecArray (an array that has different types in each
column, as you seem to require) can be subclassed to add these methods
to it.
>>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.
>
>
> 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?
Sure. We're working on it! Come check out numarray; I think you'll like
it. And if, along the way, you write a CSV-to-RecArray converter, we'd
*love* to include it in the distribution. I think that a more complete
integration with the other core Python facilities like the csv module
will help numarray become more suited for inclusion into the standard
library.
--
Robert Kern
rk...@ucsd.edu
"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter
corey
Roman Suzi wrote:
> On Wed, 5 Jan 2005, EP wrote:
>
<snip>
>
> I can try to write a PEP "Generic Programming Concepts".
>
That would be great. It's so hard to get your head around an abstract
concept (a thought, not a programming concept) without a concrete
example in some form of syntax. I think that's what's throwing off
most people from the idea.
And if you really do want to get it incorporated into whatever Guido is
thinking, it would probably be best to hurry. ;)
Bengt Richter
What do you think of automated secure importing/installing from a remote server?
You know, you try to import something and it imports a stub that was included
as a battery-place-holder and that has basic help info and will give you reasonable
options in directing the installation of the full thing (or subset you are interested in).
I don't see why every gee whiz thing has to be on your hard disk from the first.
And for those that want a big grabbag, the stubs ought to be designed to to be
runnable from a configured script, so you can turn it loose and see what's up IRL.
Regards,
Bengt Richter
michele....@gmail.com
> The bottom line is that I'm not going to be writing any
> extensive pieces of Python documentation. My time
> is better spent elsewhere.
Well, a couple of years ago I realized that some documentation on the
MRO
was missing. I wrote a document in reST, posted here, and Guido put it
on
python.org. It was as easy as it sounds. So I don't see your problem.
Dave Kulhman wrote some utility to convert reST in latex using the same
style of the standard library docs; I haven't used it myself, but you
may check
with him: http://www.rexx.com/~dkuhlman/
P.S. since you cite descriptors, what's wrong with Raimond Hetting
documentation?
http://users.rcn.com/python/download/Descriptor.htm
The only problem I see is that it is not integrated with the official
docs, but this is a
minor issue, I think.
Michele Simionato
michele....@gmail.com
Of course, I also got in trouble when upgrading to Python 2.2 from
1.5.2
Finally they switched to Python 2.2, but at that moment Python 2.3 came
out and I got tired. I switched to Mandrake 1.5 and I am happy with it.
Never had any serious trouble with urpmi and lots of Python packages
are
available.
Michele Simionato
Jeremy Bowers
> As for concepts, they are from Generic Programming (by Musser and
> Stepanov) and I feel that Python is in position to implement them to the
> fullest extent. And IMHO it will be nicer than just Java-like interfaces
> or Eiffel's contract approach.
>
> I can try to write a PEP "Generic Programming Concepts".
I'd like to see this.
As corey says, sooner rather than later is good. Release Early, Release
Often :-)
I'm still skeptical on how *most* Generic Programming concepts are an
improvement, but while I don't know much about how "concepts" formally
work I know I like the name... and that's a start. I'd love to see my
skepticism proved wrong.
Mike Thompson
> Carlos Ribeiro <carri...@gmail.com> wrote:
> ...
>
>>>- IDE: Better than what? Than IDLE? Than Eclipse? Than SPE? Than Pythonwin?
>>
>>I would like to seee Eric3, with some polish & opensourced on Win
>>(which means solving the Qt licensing problem). Perhaps someone could
>>convince Trolltech to release a special Qt Win version just for it
>>(Eric3). Eclipse is also an interesting approach.
>
>
> I love eric3, but if you're an eclipse fan, look at enthought's
> "envisage" IDE -- it seems to me that it has superb promise.
>
I've tried both the SciPy and Enthought WWW sites and I can't find much
on "Envisage". At SciPy.org there is one set of powerpoint slides on it
but nothing more.
Is it available for download somewhere?
--
Mike
Robert Kern
Alex is, I think, jumping the gun a bit. Envisage isn't quite ready for
prime time as your day to day IDE. It might be useful to you right now
as a platform to build a dynamic GUI application (Envisage's intended
use) if you are willing to get your hands dirty and help us build
Envisage. Hence, it is not being advertised widely.
But Alex is right; Envisage does hold a lot of promise.
Paul Rubin
> What do you think of automated secure importing/installing from a
> remote server? You know, you try to import something and it imports
> a stub that was included as a battery-place-holder and that has
> basic help info and will give you reasonable options in directing
> the installation of the full thing (or subset you are interested in).
You mean for Python modules, in ordinary operation? I'd hate that.
For things like apt-get, used for installing nonstandard programs or
getting security updates, I guess it's about as good as one can hope
for. The user has to activate it explicitly though. I definitely
don't want my computer opening internet connections unless I
specifically ask it to. Doing otherwise is almost spyware.
This may sound a little extreme but my distribution philosophy is I'd
like to get closer to an environment where users normally never
install any software of any type, ever. Microsoft cornered the OS
market cornered by acheiving something pretty close to this: they
deliver Windows with no installation needed. When people buy new
computers, Windows is already on the hard drive, so the user just
turns the computer on and Windows is there.
Fedora Core (what I'm running now) isn't shipped that way by any
computer makers that I know of, but it makes up for it by having lots
of applications included. So I buy a new computer, put in the
bootable Fedora DVD-ROM, and sit back for half an hour while a
one-time installation runs. That's about as close as I can get to
just turning on the new computer and having Fedora already there.
> I don't see why every gee whiz thing has to be on your hard disk
> from the first. And for those that want a big grabbag, the stubs
> ought to be designed to to be runnable from a configured script, so
> you can turn it loose and see what's up IRL.
If I have a 400 gig hard drive, I don't see why I need 99.99% of it
empty instead of 99.0% after I do my OS install. I don't want to
hassle over downloading stuff for hours or days at a time, or about
what components depend on other components, if the distro can just
include it. I just tried to install a Python program that uses
wxPython, except that meant I had to download both wxPython and
wxWidgets, and the installations failed because of some version
mismatch between the current wxWidgets distro and the version of GTK
included with FC3. I spent an hour or so messing with it and then
said screw it and gave up on the GUI part of that program. I'm more
technical than most users (I'm a programmer) yet this installation
stuff is too much hassle even for me. So I'd really rather that all
that stuff be pre-configured.
If a system has N downloadable components that are supposedly
independent, there are 2**N combinations of them that anyone might
have installed. In reality the indepdence is never that complete, so
something can easily go wrong if you pick a combination that hasn't
been tested and debugged by someone, and there's no way to test more
than a few of the possibilities. So I'd rather that all N components
already be included with the OS so that the combination will have been
tested by the distro maintainers before the end user has to deal with
it. Hard drives and distro media (DVD) are big enough now that it's
quite reasonable for distros to include just about everything that
most users could want.
Carlos Ribeiro
<michele....@gmail.com> wrote:
> John Roth:
> > The bottom line is that I'm not going to be writing any
> > extensive pieces of Python documentation. My time
> > is better spent elsewhere.
>
> Well, a couple of years ago I realized that some documentation on the
> MRO
> was missing. I wrote a document in reST, posted here, and Guido put it
> on
> python.org. It was as easy as it sounds. So I don't see your problem.
>
> Dave Kulhman wrote some utility to convert reST in latex using the same
> style of the standard library docs; I haven't used it myself, but you
> may check
> with him: http://www.rexx.com/~dkuhlman/
Couldn't a better document-writing interface be implemented? This is
the kind of stuff Zope & Plone are used for on a daily basis; not to
mention other countless web frameworks & CMS available in Python. Even
a simple automated service to process & publish reST or SGML files
would be better than requiring aspiring Python doc writers to install
the full toolchain, as pointed out. But, whatever it is (and that's a
difficult choice, politically speaking), it should be hosted on the
main Python site... because that's the place where people look for
info first place.
> P.S. since you cite descriptors, what's wrong with Raimond Hetting
> documentation?
> http://users.rcn.com/python/download/Descriptor.htm
>
> The only problem I see is that it is not integrated with the official
> docs, but this is a
> minor issue, I think.
The docs are great, but it took me some time to find them out after
searching inside Python docs. This is not a minor issue IMHO.
Andrew MacIntyre
> I would like to contribute some documentation to Python.
> I've got the time, I write quite a bit, etc. I've got fairly
> strong opinions about some things that need to be documented,
> (such as all the new style class descriptor stuff from 2.2)
> and I have relatively little difficulty matching the existing style.
>
> However, I don't
> know TEX, Latex, CVS or Sourceforge. (The latter two are
> on my "learn sometime soon so I can put PyFIT where it belongs"
> list.)
>
> I have no desire to install Perl to run the documentation toolchain.
> I also have no particular desire to write up a bunch of final
> format stuff and drop it on someone else to put into the latex
> format so it can be included.
While being able to make doc changes at the Latex level directly into CVS
is the ultimate, Fred Drake and others are quite happy to take straight
text (ReST markup would probably help them a bit) as bugs/patches on
sourceforge.
-------------------------------------------------------------------------
Andrew I MacIntyre "These thoughts are mine alone..."
E-mail: and...@bullseye.apana.org.au (pref) | Snail: PO Box 370
and...@pcug.org.au (alt) | Belconnen ACT 2616
Web: http://www.andymac.org/ | Australia
Nick Coghlan
> Couldn't a better document-writing interface be implemented?
Such as:
http://www.python.org/moin/Documentation
Or AMK's annotatable docs:
http://pydoc.amk.ca/frame.html
Something like that?
> The docs are great, but it took me some time to find them out after
> searching inside Python docs. This is not a minor issue IMHO.
Actually, this is a fair point - I work on isolated machines a lot (i.e. no net
access), which means I can't get to any of these handy things.
It would be nice if at least some of these things could be bundled with the
CPython interpreter and linked to from the main documentation (rather than from
the sidebar menu on the webpage).
Cheers,
Nick.
--
Nick Coghlan | ncog...@email.com | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net
Alex Martelli
...
> >> I love eric3, but if you're an eclipse fan, look at enthought's
> >> "envisage" IDE -- it seems to me that it has superb promise.
> > Is it available for download somewhere?
>
> Alex is, I think, jumping the gun a bit. Envisage isn't quite ready for
> prime time as your day to day IDE. It might be useful to you right now
I apologize if I gave a misleading impression: I did not mean it was
ready to use, or _already_ here; I suggested "looking at" in the sense
of "paying attention to", and specifically mentioned "promise".
Since the subthread was about future IDE developments, I thought it was
appropriate to mention envisage, in the context of comparisons with
eclipse's plugin-centered architecture.
> as a platform to build a dynamic GUI application (Envisage's intended
> use) if you are willing to get your hands dirty and help us build
> Envisage. Hence, it is not being advertised widely.
I saw a Pycon proposed talk about it, so I didn't stop to consider the
"not advertised widely" issue. Thinking about it, I realize Pycon is
almost 3 months from now, so wanting to enthuse about envisage then
doesn't imply already wanting to widely advertise it now; sorry.
> But Alex is right; Envisage does hold a lot of promise.
The very concept of an architecture based on a spare skeleton and
copious plugins is intrinsically excellent, and I think that by now
eclipse has proven it's also practically viable for real-world powerful
IDEs/platforms/frameworks.
Alex
Nick Coghlan
>
> #- Contribute to where on Sourceforge??? Which domentation are
> #- we talking
> #- about in general?
Speaking of docs. . . I think it would help a great deal if the python.org
version-specific documentation pages used the standard documentation front page
that actually includes the "About the Python Documentation" link that explains
how to do this.
Compare:
http://www.python.org/doc/2.4/
To:
http://www.python.org/dev/doc/devel/
gabriele renzi
>>But Alex is right; Envisage does hold a lot of promise.
>
>
> The very concept of an architecture based on a spare skeleton and
> copious plugins is intrinsically excellent, and I think that by now
> eclipse has proven it's also practically viable for real-world powerful
> IDEs/platforms/frameworks.
>
I think this had been demonstrated from emacs long before :)
Carlos Ribeiro
> Carlos Ribeiro wrote:
> > Couldn't a better document-writing interface be implemented?
>
> Such as:
> http://www.python.org/moin/Documentation
>
> Or AMK's annotatable docs:
> http://pydoc.amk.ca/frame.html
Sorry, I wasn't clear. Both are clear steps in the right direction. I
was thinking more along the lines of an automated document processing
service, to avoid the need to install all the tools to generate the
"official" Python docs (latex, sgml, etc.). One could simply "upload"
a revised doc and get the processed result back. Of course, such a
service can't be open to the public, but it would still be useful.
Robert Kern
> Robert Kern <rk...@ucsd.edu> wrote:
> ...
>
>>>>I love eric3, but if you're an eclipse fan, look at enthought's
>>>>"envisage" IDE -- it seems to me that it has superb promise.
>
> ...
>
>>>Is it available for download somewhere?
>>
>>Alex is, I think, jumping the gun a bit. Envisage isn't quite ready for
>>prime time as your day to day IDE. It might be useful to you right now
>
>
> I apologize if I gave a misleading impression: I did not mean it was
> ready to use, or _already_ here; I suggested "looking at" in the sense
> of "paying attention to", and specifically mentioned "promise".
>
> Since the subthread was about future IDE developments, I thought it was
> appropriate to mention envisage, in the context of comparisons with
> eclipse's plugin-centered architecture.
The subthread was? Okay. Never mind me, then. The threading got broken
up in my newsreader and I couldn't tell the context.
>>as a platform to build a dynamic GUI application (Envisage's intended
>>use) if you are willing to get your hands dirty and help us build
>>Envisage. Hence, it is not being advertised widely.
>
>
> I saw a Pycon proposed talk about it, so I didn't stop to consider the
> "not advertised widely" issue. Thinking about it, I realize Pycon is
> almost 3 months from now, so wanting to enthuse about envisage then
> doesn't imply already wanting to widely advertise it now; sorry.
No worries.
The SVN repository address isn't being kept secret, just not advertised
much. If anyone is interested in anonymous read-access, they can ask me
for the address.
Steve Holden
> In article <1104831798.4...@c13g2000cwb.googlegroups.com>,
> <michele....@gmail.com> wrote:
>
>>Maybe a PSF grant would help? I guess this has been considered ...
>
>
> The first three PSF grants were all in some way not directly related to
> changing the core language. One was for a library, one for improving
> Jython, and one for improving docs. Giving the PSF more money increases
> the chances for additional work.
I would, however, like to make the point that the Foundation is much
more likely to fund work that actually gets proposed for a grant, since
the officers don't generally have the time to inspire teams and promote
specific topics. So if a bunch of like-minded people wanted to get
together to propose a specific set of changes, it would then at least be
possible to consider such changes for funding.
There's also a lot of good work that goes on unfunded, of course, and I
wouldn't like to see the grants process subvert such public-spirited
efforts in any way. So there's nothing to stop a bunch of like-minded
individuals proposing changes anyway, through the existing process.
Lastly, the Foundation has only just started to make grants, and so we
need a little time to see how the existing projects go before we can
evaluate the success or failure of the process (at least on the existing
projects, whose outcomes may or may not be related to the grant process).
regards
Steve
--
Steve Holden http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/
Holden Web LLC +1 703 861 4237 +1 800 494 3119
Bengt Richter
>bo...@oz.net (Bengt Richter) writes:
>> What do you think of automated secure importing/installing from a
>> remote server? You know, you try to import something and it imports
>> a stub that was included as a battery-place-holder and that has
>> basic help info and will give you reasonable options in directing
>> the installation of the full thing (or subset you are interested in).
>
>You mean for Python modules, in ordinary operation? I'd hate that.
>For things like apt-get, used for installing nonstandard programs or
>getting security updates, I guess it's about as good as one can hope
>for. The user has to activate it explicitly though. I definitely
>don't want my computer opening internet connections unless I
>specifically ask it to. Doing otherwise is almost spyware.
I agree 1000% !! Importing a stub should get you an imported stub that
prints info as it imports, so you know its not functional. And just
gives you the options to type help(themodule) or if you know you want
to go ahead, themodule.install() -- and nothing would touch the internet
until you gave a final "yes" to an "Are you sure" at the end of a
what-will-happen-if-you-say-yes summary. I didn't mean any activity
that you don't control. Just activity that you can control easily.
>
>This may sound a little extreme but my distribution philosophy is I'd
>like to get closer to an environment where users normally never
>install any software of any type, ever. Microsoft cornered the OS
>market cornered by acheiving something pretty close to this: they
>deliver Windows with no installation needed. When people buy new
>computers, Windows is already on the hard drive, so the user just
>turns the computer on and Windows is there.
It makes a lot of sense for a "core" plus a delivered specific application
base, but IMO if you try to cover the world with a monolith you will
inevitably still have the problem of getting the latest version of
particular packages for bug fixes or enhancements. The more you have
in your giant collection the more that will be true.
>
>Fedora Core (what I'm running now) isn't shipped that way by any
>computer makers that I know of, but it makes up for it by having lots
>of applications included. So I buy a new computer, put in the
>bootable Fedora DVD-ROM, and sit back for half an hour while a
>one-time installation runs. That's about as close as I can get to
>just turning on the new computer and having Fedora already there.
>
>> I don't see why every gee whiz thing has to be on your hard disk
>> from the first. And for those that want a big grabbag, the stubs
>> ought to be designed to to be runnable from a configured script, so
>> you can turn it loose and see what's up IRL.
>
>If I have a 400 gig hard drive, I don't see why I need 99.99% of it
>empty instead of 99.0% after I do my OS install. I don't want to
>hassle over downloading stuff for hours or days at a time, or about
>what components depend on other components, if the distro can just
>include it. I just tried to install a Python program that uses
>wxPython, except that meant I had to download both wxPython and
>wxWidgets, and the installations failed because of some version
>mismatch between the current wxWidgets distro and the version of GTK
>included with FC3. I spent an hour or so messing with it and then
>said screw it and gave up on the GUI part of that program. I'm more
>technical than most users (I'm a programmer) yet this installation
>stuff is too much hassle even for me. So I'd really rather that all
>that stuff be pre-configured.
There are several parts to those frustrations. But you are presuming
that they would have been solved for you and put on a DVD with all
dependency problems resolved. Ok, let's assume that. In that case,
an installation stub module could just as well have the solution built
into it as to what versions etc are needed to make the module work.
With a large collection, you may need several versions of some support libs.
To bring a large collection into version-alignment ISTM you need a version
freeze across too many libraries of different kinds with different
development schedules and resources to make it reliable.
So you're still going to need the ability to add updates and new modules
and more. I'd rather see effort going into making that process simple
and reliable (and fully controlled by the user -- i.e. no unauthorized
hidden internet activity!!) than to solve the same version problems
for some mega DVD make file where you don't have the script and config info
in a concise single-problem stub form, and can't ask here for help finding
an updated stub. It's a matter of being able to limit the problem you
need to solve when something particular doesn't work.
When your wxPython-using program didn't work, wouldn't it have been nice
to have downloaded a standard stub program (with older stub versions still
available if you have an older system) and have it tell you what
was missing that it needed before you decided to let it continue and
get those things? Or choose not to? With broadband most apps
will be ready before you can make fresh coffee, or maybe watch the Simpsons.
Otherwise what? Send for a new DVD? Yes, core stuff + plenty of compatible goodies
in a distro is a good idea, but problems are inevitable, and IMO it's more
important to have a standard reliable way to solve problems than to have
them "solved" on periodic monoliths DVDs that can't ever be problem free.
>
>If a system has N downloadable components that are supposedly
>independent, there are 2**N combinations of them that anyone might
>have installed. In reality the indepdence is never that complete, so
>something can easily go wrong if you pick a combination that hasn't
>been tested and debugged by someone, and there's no way to test more
>than a few of the possibilities. So I'd rather that all N components
>already be included with the OS so that the combination will have been
>tested by the distro maintainers before the end user has to deal with
You are asking a lot from these distro maintainers if you expect recent
versions of everything, and for them to watch for new stuff to evaluate
and include after researching compatibility problems. They aren't in the
best position to do that. The author/s of the new stuff is/are. And if
such authors had a standard stub module they could prepare, then distros
could include those, and you would find version updates for those rather than
trying to solve the integration problems yourself. And if there were
still bugs, a new version would likely be posted here after some discussion.
And then everyone could have an easy download of the new stub, and be able to
go for coffee. I think if python.org had a trusted-software registry that could
be a flat CSV text file of names, versions, urls, sizes, and md5 digests and maybe
some trust level, then the stubs could access that for a standard way of finding
components. Or course for a DVD distro, stubs could access the DVD rather than
the internet for things at the DVD's version level.
I realize this problem has been "solved" with various RPM and app-loading methods,
but I think python could wrap its solution nicely. I don't think distutils and setup.py
is easy enough to create (at least I have been somewhat frustrated in using it effectively),
though it deals with a lot of what has to be done.
>it. Hard drives and distro media (DVD) are big enough now that it's
>quite reasonable for distros to include just about everything that
>most users could want.
Agreed for some "core" set. How shall we define what belongs in the "core?" ;-)
Regards,
Bengt Richter
Bulba!
wrote:
>> 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?
>I'm not sure what you mean by "written by hand."
I mean the same way as you do mylist.sort() in Python
instead of writing the list sorting function yourself in
the application / script.
>Someone is going to
>have to write the functions in the first place. Sure, they can be
>written once, well, and placed in the standard library so they don't
>have to be *re*written by anyone else again.
Well of course - the only point I mean here is getting
high-level stuff is one of the main motives of getting
into VHLL (aside from issues like automatic memory
management, of course).
>I still think numarray is a good start for this. It handles more than
>just numbers. And RecArray (an array that has different types in each
>column, as you seem to require) can be subclassed to add these methods
>to it.
I have downloaded it, playing with it and like it. I esp. like things
like:
>>> print a + a
[2 4 6]
or
>>> b.getshape()
(4,3)
Very Pythonic. :-)
However, not all things are generic enough like I meant. That
is not to criticize, but merely to point out that the library is for
obvious reasons slanted towards numerical work, so e.g. while the
following works:
.>>> from numarray import transpose
.>>> transpose([[1,2],[3,4]])
array([[1, 3],
[2, 4]])
...this doesn't:
>>> transpose([('phone1', 12345), ('phone2', 67890)])
Traceback (most recent call last):
File "<interactive input>", line 1, in ?
[....]
TypeError: Expecting a python numeric type, got something else.
Why would someone want to do such a thing: suppose he
wants 'phone1' and 'phone2' and number records sequenced
horizontally instead vertically, while when he read that from
a file, such was the file structure. It's a boneheaded example,
but you get the idea.
It's obvious why that exception happens: in recarray I have to have
the same type of the data type in every column, so transpose(recarray)
cannot be done.
This is not the situation with other builtin Python data types, where
whatever with can be mixed, i.e. placed in any "cell" of data type
and all the functions will still work as long as the operand type is
proper.
This is obviously the consequence of numarray being based on
the matrices designed for working on numerical data, so it's
probably very fast and I'm sure people who use it find it useful.
But personally I would happily sacrifice much or even most of that
speed for sake of flexibility. Because, sure, I can keep the
matrix header with strings separately in a list, do the transformation
just on numbers, adjust the list as well - it's not like I'm just lazy
to make an additional programming effort, but that eliminates
one of the greatest advantages of Python: terseness without
foregoing clarity.
Yes, now it's probably much harder to do once the simpler things
have been done. All I'm saying is that it would be so frigging nice
to have it with even richer data structures.
>> 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?
>Sure. We're working on it!
Excellent! Great, I'm really grateful to you all for doing that.
Honestly.
>Come check out numarray; I think you'll like
>it. And if, along the way, you write a CSV-to-RecArray converter, we'd
>*love* to include it in the distribution.
First I have to learn Python (and programming in general) well enough
to produce smth that isn't as bug-infested as a software of certain
well-known vendor and that I would not be ashamed of to show to the
world. :-) I'm afraid it will take me some time.
>I think that a more complete
>integration with the other core Python facilities like the csv module
>will help numarray become more suited for inclusion into the standard
>library.
I'm sure people would find it useful. I play with numarray to get the
idea how I could apply it in my work.
--
It's a man's life in a Python Programming Association.
Jarek Zgoda
> But I see little to no efforts from the core python team to address my
> needs as listed above. They seem mainly to focus on the core attributes
> and syntax of the language. Very little or no efforts are taken to
> improve the infrastructure around the language.
>
> And then I read the following sentence by Van Rossum:
>
> "In order to make type inferencing a little more useful, I'd like to
> restrict certain forms of extreme dynamic behavior in Python"
>
> In the end, it's mindset which counts. And I think that mindset is going
> to be determine the way foreward for Python: more features, increased
> complexity, less dynamism. Lots of syntax crud, without addressing the
> need to improve the infrastructure around the language.
I saw this once somewhere:
http://groups.google.com/groups?selm=cf38ph%242f8%241%40namru.matavnet.hu
--
Jarek Zgoda
http://jpa.berlios.de/ | http://www.zgodowie.org/
Terry Reedy
"Paul Rubin" <"http://phr.cx"@NOSPAM.invalid> wrote in message
news:7x652bn...@ruckus.brouhaha.com...
> If I have a 400 gig hard drive, I don't see why I need 99.99% of it
> empty instead of 99.0% after I do my OS install.
Even though I currently only have 80 megs (about the minimum one can
currently buy), I've about decided you are right. Having just installed a
3 CD game last night, I realize that my stinginess with disk space for more
serious stuff is obsolete. (My first hard disk was 5 or 10 megs.) A
gigabyte would cover Python + Wxpython + numarray + scipy + pygame + a lot
of other stuff.
Would it be possible, at least for Windows, to write a Python script
implementing a 'virtual distribution'? IE, download Python, install it,
download next package, install it, etc. -- prefereably table driven?
Terry J. Reedy
Peter Hansen
How would you run the script in the first place?
(Assuming that has one of the straightforward answers I
can think of, then I would say the answer to your question
is "certainly"... I think most installers support a "silent"
option so that they could be run from a script.)
-Peter