Hi i am sure most of you have read the article of Andrew Kuchling about focusing more in the standart library than language newFeatures/tweaking and probably i as many others would like to know what the python hackers/developers think about this proposal.Maybe this post is out of place but oh well.. i am personaly very interested in improving the stdlib which is very messy in my opinion right now. the article(several comments): http://www.amk.ca/diary/archives/cat_python.html#003382
Hi i am sure most of you have read the article of Andrew Kuchling about focusing more in the standart library than language newFeatures/tweaking and probably i as many others would like to know what the python hackers/developers think about this proposal.
There is a great deal of merit to efforts for cataloging resources and thinking about ways to improve the standard library. Whether successful or not likely depends on who wants to volunteer their time for what. Where there are multiple, competing third party solutions, Guido has historically resisted ending exploration by locking in a single solution. Instead, he said he prefers "category killers" such as the unittest and logging modules. Martin has also been clear that community acceptance and a commitment to on-going maintenance are also important considerations. For the core, python-dev discussions indicate that several things are still in the works and will probably happen depending on who has the time, interest, and ability: * Someday, decimal may become a built-in type. * The AST version of the compiler may get finished. * A mutable bytes type may emerge on the road to all strings being Unicode. * Someday, C99 may rule the roost and cmath will be updated. * One of three proposals may be accepted for optimized attribute lookup. * A bytecode verifier seems to have a chance. * reST support may be added when it becomes mature enough. * The project to transition to unittests and increase coverage is continuing. * If the class/instance semantics get worked out, exceptions may become new style classes along the road to Py3.0. FWIW, there is a trend toward providing pure python equivalents to CPython implementations (such as that for compiler, sets, bisect, heapq, deques, itertools, decimal, etc). The thought is that these may outlive their C counterparts.
i am personaly very interested in improving the stdlib which is very messy in my opinion right now.
It's not clear whether you're volunteering or just making a vague blanket request/criticism. If it is the former, then the backlog of bug reports and patch reviews is a good place to start. Raymond
On Thu, 7 Oct 2004 19:55:03 -0400, Raymond Hettinger <python@rcn.com> wrote:
Where there are multiple, competing third party solutions, Guido has historically resisted ending exploration by locking in a single solution. Instead, he said he prefers "category killers" such as the unittest and logging modules. Martin has also been clear that community acceptance and a commitment to on-going maintenance are also important considerations.
I see the reasoning behind this position. But I fear it can lead to lack of standardization in some areas. There is at least one area where a firm position would greatly clarify things: standard interfaces for modules where multiple providers are always the norm, such as the DB API and WSGI. WSGI is working is way out, but it's still too early to tell if they will be successful. But the DB API could really take advantage of a BDFL-style intervention to settle things. (it does not *need* to be Guido, but it has to be someone with power enough to take a firm stand and enforce it; but I don't know anyone who could assume this role as the undisputed leader of the DB-API effort).
For the core, python-dev discussions indicate that several things are still in the works and will probably happen depending on who has the time, interest, and ability:
* Someday, decimal may become a built-in type. * The AST version of the compiler may get finished. * A mutable bytes type may emerge on the road to all strings being Unicode. * Someday, C99 may rule the roost and cmath will be updated. * One of three proposals may be accepted for optimized attribute lookup. * A bytecode verifier seems to have a chance. * reST support may be added when it becomes mature enough. * The project to transition to unittests and increase coverage is continuing. * If the class/instance semantics get worked out, exceptions may become new style classes along the road to Py3.0.
Nice summary.
FWIW, there is a trend toward providing pure python equivalents to CPython implementations (such as that for compiler, sets, bisect, heapq, deques, itertools, decimal, etc). The thought is that these may outlive their C counterparts.
That's great -- I mean, taken to its maximum expression, Python would be able to bootstrap itself this way (a Python VM written in Python?). It's a sign of maturity, don't you think?
i am personaly very interested in improving the stdlib which is very messy in my opinion right now.
It's not clear whether you're volunteering or just making a vague blanket request/criticism. If it is the former, then the backlog of bug reports and patch reviews is a good place to start.
I still need to find my way there (docs/sourceforge stuff). Depending on the way my current projects go, I may still be able to dedicate some time to it. I'm really looking forward to it... -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: carribeiro@gmail.com mail: carribeiro@yahoo.com
Carlos Ribeiro wrote:
On Thu, 7 Oct 2004 19:55:03 -0400, Raymond Hettinger <python@rcn.com> wrote:
Where there are multiple, competing third party solutions, Guido has historically resisted ending exploration by locking in a single solution. Instead, he said he prefers "category killers" such as the unittest and logging modules. Martin has also been clear that community acceptance and a commitment to on-going maintenance are also important considerations.
I see the reasoning behind this position. But I fear it can lead to lack of standardization in some areas. There is at least one area where a firm position would greatly clarify things: standard interfaces for modules where multiple providers are always the norm, such as the DB API and WSGI. WSGI is working is way out, but it's still too early to tell if they will be successful. But the DB API could really take advantage of a BDFL-style intervention to settle things. (it does not *need* to be Guido, but it has to be someone with power enough to take a firm stand and enforce it; but I don't know anyone who could assume this role as the undisputed leader of the DB-API effort).
I don't know anything about the way the WSGI specification is developed. The DB-API specification was developed outside the Python development process and has so far been very successful at that. The DB-SIG which manages the specification is in charge of the process and will continue to work together with module authors and users to accommodate for new features that may become generally available in databases or their interfaces. Note that there is no need to "settle things": the DB-API spec has been around for many years, is very stable, widely used and still flexible enough to meet requirements of various different database backends. If you feel that a certain feature is missing, I'd suggest you direct your constructive criticism to the db-sig@python.org. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 08 2004)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
Hello all, There must be something about the way I write my comments that may be making them sound worst than I want. I have _no_ intention to start a flame war... and I really would like to make it sound constructive. I apologize if it sounded otherwise. (I have a few comments that still belong here, if only to clarify things) On Fri, 08 Oct 2004 10:54:34 +0200, M.-A. Lemburg <mal@egenix.com> wrote:
Note that there is no need to "settle things": the DB-API spec has been around for many years, is very stable, widely used and still flexible enough to meet requirements of various different database backends.
There are several packages around that don't implement the DB API correctly, or implement a completely different API. This is clearly not a fault of the DB API itself, or of its developers, but it's an issue for its users. It's a difficult situation, because nobody is really in a position to enforce compliance. In this sense, bringing the issue to the standard library _could_ be helpful. One suggestion is to have a reference implementation -- for example, a simple DB API module, or a library that makes use of DB-API compliant modules. Of course, it's open to discussion whether this is feasible or not; for now it's only a personal opinion.
If you feel that a certain feature is missing, I'd suggest you direct your constructive criticism to the db-sig@python.org.
I think the DB API itself is fine. What is lacking is some way to make sure that everyone _comply_ to it. If that's can be done within the DB-SIG group alone, fine. -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: carribeiro@gmail.com mail: carribeiro@yahoo.com
i know there are a lot of volunters,fans,developers who are very actively developing/improving the library but the main point of the argument(i think),is to realy focus on the stdlib improvements,not implying that the interpreter improvements are less important,just that the stdlib is currently lacking a bit in certain aspects already mentioned,to try to balance the ecosystem. A more formal,focused,organized aproach to improve the stdlib is the point of the proposal,some sort of plan,roadmap is what is needed(in my opinion). Some things that comes to mind and others based on feedback about the AFK non formal proposal are: to refactor(someway) stdlib parts that are a bit inconsistent,as duplicated functionality of some modules,modules with just one function,obscure ways of working of some of them,to stablish realy strong naming,style coding conventions ie: modules names with get_type,getType,gettype. To realy start a stdlib documentation effort,aspiring it to be the best,clearest documented stdlib out there. To develop the greatest,more advanced library packaging system out there,taking the strengh and weaknesses of others(as CPAM) as a guide. To start a planed and formal draft for py 3.0,some similar system as the iniciative from zope,the zope X3 project and maybe to #adelantar a litle python 3.0 realease(to jump from python 2.7 to python 3000 ^_^). And many other great ideas to start making python the best language ever.
daniel narf wrote:
i know there are a lot of volunters,fans,developers who are very actively developing/improving the library but the main point of the argument(i think),is to realy focus on the stdlib improvements,not implying that the interpreter improvements are less important,just that the stdlib is currently lacking a bit in certain aspects already mentioned,to try to balance the ecosystem.
As I said in a comment to Andrew's piece - the _best_ way is to pick up a piece of the stdlib that annoys you, and fix it. Attempting to setup a roadmap, or a plan, or whatever, will only mean that nothing ever gets done. For instance, look at the long and sorry history before PyPI. Many, many attempts to do some big picture thing, and no result. What we have now isn't perfect, but it's a start. And it was accomplished by one person (Richard) getting annoyed enough to just roll up the sleeves and do it. Anthony -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
participants (6)
-
Anthony Baxter -
Carlos Ribeiro -
daniel narf -
M.-A. Lemburg -
Raymond Hettinger -
Walter Dörwald