Re: [Python-Dev] Thoughts on stdlib evolvement
On Mon, Jun 06, 2005 at 01:38:36PM -0500, Skip Montanaro wrote:
>
>
> Reinhold> - Flat namespace: Should we tend to a more hierarchic library
> Reinhold> (e.g. inet.url, inet.http, inet.nntp)? This would increase
> Reinhold> clarity when searching for a module.
>
> We've talked about this before. The main technical challenge seems to be
> backward compatibility. You need to support both flat ("import urllib") and
> packaged namespaces ("from www import urllib"), possibly within the same
> application. That is, postulating a www package, if I execute
>
> import urllib
> from www.urllib import urlopen
>
> the module-level code should only be executed once, and
>
> urlopen == urllib.urlopen
>
> should evaluate to True.
Can't this be handled with an __init__ module? Create an inet package
and having the __init__ module pull whatever it wanted into it's own
namespace.
It would be nice to then use warnings to show deprecation messages
when the old import is used (import url instead of import inet.url),
but I don't think that is quite so easy.
--
David Stanek
www.roninds.net
GPG keyID #6272EDAF on http://pgp.mit.edu
Key fingerprint = 8BAA 7E11 8856 E148 6833 655A 92E2 3E00 6272 EDAF
pgptKki5DlMrm.pgp
Description: PGP signature
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] python running in several threads
Hello Python developers, I know this is developers list and I hope I'm right here. I'm using python as scripting engine embedded in application but issue should be more general. When several scripts are executed simultaneously (under several threads) one have to acquire/release locks. This degrades performance IMHO, mainly on server installations (many web servers use python engine). Moreover those scripts are commonly independent chunks of code which do not create other threats. Under those limitations, do you think, an easy rewrite of execution engine is possible to allow simultaneous run of all threads? I checked the sources esp. PyThreadState object and it seems all those variables could be held locally. Another way is using thread local storage, but it could be a little problematic with porting issues. How do you see it? Do you have any plans here? Thanks and regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python running in several threads
On Tue, Jun 07, 2005, Martin Aliger wrote: > > Under those limitations, do you think, an easy rewrite of execution > engine is possible to allow simultaneous run of all threads? Short answer: no Longer answer: see previous threads about removing the GIL; if you still have questions, please post to comp.lang.python. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ f u cn rd ths, u cn gt a gd jb n nx prgrmmng. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Thoughts on stdlib evolvement
Skip Montanaro wrote: > Tim> On 6/6/05, Reinhold Birkenfeld <[EMAIL PROTECTED]> wrote: > > >> - Flat namespace: Should we tend to a more hierarchic library (e.g. > >> inet.url, inet.http, inet.nntp)? This would increase clarity when > >> searching for a module. > > Tim> -1. I feel the opposite way: when trying to figure out where > Tim> something "lives", I prefer Python's flat namespace to (for > Tim> example) Java's com.company.baz.bar.foo hierarchy. > > I think Reinhold's suggestion (e.g., inet.*) was for a flatter namespace > than Java's scheme, but for a slightly more structured namespace than the > current standard library provides. Some amount of structure helps to > collect modules together whose names don't obviously suggest who their > neighbors are in the functionality space. For example, to the naive user it > might not be obvious that these groups of modules and packages are related: > > * getopt and optparse > * bsddb, gdbm and anydbm > * email, mhlib, quopri > * heapq, collections > * user, site, sitecustomize > * profile, hotshot, pstats > * pipes, subprocess, os Yep, exactly. Java's namespaces are ugly, that's right, but a flatter version certainly improves readability. """Namespaces are one honking great idea -- let's do more of those!""" > I wouldn't mind a stdlib that defined a set of top-level packages (some of > which might be wholly unpopulated by modules in the standard distribution) > It might, for example, define a gui package and gui.Tkinter and gui._tkinter > modules, leaving the remainder of gui namespace available for 3rd party > modules. Such a scheme would probably work best if there was some fairly > lightweight registration/approval process in the community to avoid needless > collisions. For example, it might be a bit confusing if two organizations > began installing their packages in a subpackage named gui.widgets. An > unsuspecting person downloading an application that used one version of > gui.widgets into environment with the conflicting gui.widgets would run into > trouble. Is the CPAN namespace wide open? If I wanted to create a Perl > module to fit into the HTML namespace is there some procedure involved or is > it an example of squatters' rights? Personally, I think that CPAN is one of the greatest strengths of Perl. The language is a mess, and the quality of many modules is questionable, but it's incredibly easy to find a module for handling a special problem, and the namespaces are IMHO well thought out. Additionally, the docs > >> - 3rd party modules: There are many superb modules out there, some of > >> which really do have a "standard" character. Examples include PIL, > >> numarray, ElementTree, [wxPython - I know this is a hairy issue], > > Tim> I think the most important question for each of these is "is the > Tim> module's release schedule at least as stable as Python's?". For > Tim> many of these, I suspect the answer is "no". > > If you provide the necessary namespace structure for them to nestle into, I > suspect most of them could be maintained outside the stdlib just fine. Exactly! There needn't be such a big separation between stdlib and 3rd party. Access to the net is standard nowadays, though it wouldn't be of any harm making a big distribution with all modules available, for downloading and burning on CD, for example. PJE's great EasyInstall and Python Eggs will be a perfect starting point for this, I think. Reinhold -- Mail address is perfectly valid! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Thoughts on stdlib evolvement
Fernando Perez wrote: > Skip Montanaro wrote: > >> I wouldn't mind a stdlib that defined a set of top-level packages (some of >> which might be wholly unpopulated by modules in the standard distribution) >> It might, for example, define a gui package and gui.Tkinter and gui._tkinter >> modules, leaving the remainder of gui namespace available for 3rd party >> modules. Such a scheme would probably work best if there was some fairly >> lightweight registration/approval process in the community to avoid needless >> collisions. For example, it might be a bit confusing if two organizations >> began installing their packages in a subpackage named gui.widgets. An >> unsuspecting person downloading an application that used one version of >> gui.widgets into environment with the conflicting gui.widgets would run into >> trouble. > > I've wondered if it wouldn't be better if the std lib were all stuffed into > its > own namespace: > > from std import urllib > > If a more structured approach is desired, it could be > > from std.www import urllib One may want to look at the "py.std" approach of "the py lib", found at http://codespeak.net/py/current/doc/misc.html#the-py-std-hook Reinhold -- Mail address is perfectly valid! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Thoughts on stdlib evolvement
Reinhold Birkenfeld wrote: > Hello, > > I am currently having some thoughts about the standard library, with regard > to Python 2.5 and 3.0. Since I don't want to withhold them from you, here > are they ;) > > - Flat namespace: Should we tend to a more hierarchic library (e.g. > inet.url, inet.http, inet.nntp)? This would increase clarity when > searching for a module. I think putting the standard library in it's own package would be the first step. "std" has been mentioned a couple of times and I think its a good name for it. For backwards compatibility, maybe a "from __compatible__ import ver_2.x", or something similar, could be used as a way to allow future versions a bit more flexibility to change? Trying to move the modules in python/lib to python/packages/stdlib to see what would happen revealed the following files are required to be in python/lib to start the python shell without errors. copy_reg.py ntpath.py os.py site.py stat.py types.py These files are modules site.py imports. Maybe these should be builtins so that the shell could start without importing any modules? > - 3rd party modules: There are many superb modules out there, some of which > really do have a "standard" character. Examples include PIL, numarray, > ElementTree, [wxPython - I know this is a hairy issue], I'm on the side of less in builtins and less in the standard library, and for having a central repository for developers to distribute their packages. A python updater that gets a list of installable packages to install or uninstall would be fantastic. ;-) Having less in the core distribution means smaller complete applications to install when py2exe is used. There also needs to be some assurance that the standard library has as few bugs in it as possible. The more that's added to it, the more work and testing to do that is needed. > - User interface: Tkinter may be "the" standard, but other Toolkits deserve > notice, notably wxPython and PyGtk, the latter of which might be even > easier to package. I think these fall into the category of optional "official" extension packages that could be included in the core installer, but are not part of the standard library package itself. They are packages that would be maintained separately from the core and have their own developers dedicated to maintaining them. The 'official', or other designator if appropriate, would mean that they are important packages that fulfill a need and efforts to make and keep them compatible with the current python release is made. An "official" package designation might be something that developers could strive for and proudly display on their website or resume. Some minimum standards would be needed... ie current with current version of python, fully functional, fulfilling a need, etc. A request and voting process of some sort where python-dev can award "officialdom" to package developers might be usefull for this. Just a few thoughts, Cheers, Ron ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Thoughts on stdlib evolvement
Ron Adam wrote: [snip] > Having less in the core distribution means smaller complete applications > to install when py2exe is used. There also needs to be some assurance > that the standard library has as few bugs in it as possible. The more > that's added to it, the more work and testing to do that is needed. Almost by definition, applications using py2exe are minimal Python installations without external dependencies. - Josiah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] problem installing current cvs
Hi,
I'm having 2 problems with the current cvs :
During compilation this warning occurs:
*** WARNING: renaming "dbm" since importing it failed: build/lib.linux-i686-2.5/
dbm.so: undefined symbol: dbm_firstkey
and the 'dbm' module is unavailable.
I'm running MandrakeLinux 2005 (10.2) gcc 3.4.3
(I'm also having this problem when compiling python 2.3.5 or 2.4.1)
furthermore the 'make install' of current cvs fails halfway trough
with the following errors:
.
.
Compiling /opt/python25/lib/python2.5/bsddb/test/test_associate.py ...
Sorry: TabError: ('inconsistent use of tabs and spaces in indentation',
('/opt/python25/lib/python2.5/bsddb/test/test_associate.py', 97, 23, '\t
os.mkdir(homeDir)\n'))
Compiling /opt/python25/lib/python2.5/bsddb/test/test_basics.py ...
Sorry: TabError: ('inconsistent use of tabs and spaces in indentation',
('/opt/python25/lib/python2.5/bsddb/test/test_basics.py', 400, 26, '\tif
get_raises_error:\n'))
Compiling /opt/python25/lib/python2.5/bsddb/test/test_compare.py ...
Sorry: TabError: ('inconsistent use of tabs and spaces in indentation',
('/opt/python25/lib/python2.5/bsddb/test/test_compare.py', 167, 5, '\t"""\n'))
.
.
Compiling /opt/python25/lib/python2.5/bsddb/test/test_recno.py ...
Sorry: TabError: ('inconsistent use of tabs and spaces in indentation',
('/opt/python25/lib/python2.5/bsddb/test/test_recno.py', 38, 46,
'\tget_returns_none =
d.set_get_returns_none(2)\n'))
.
.
make: *** [libinstall] Error 1
$
And then it quits.
Fixing the tab indentation errors locally makes the problem go away.
Regards,
Irmen de Jong
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Thoughts on stdlib evolvement
On Jun 7, 2005, at 11:47 AM, Josiah Carlson wrote: > Ron Adam wrote: > [snip] > >> Having less in the core distribution means smaller complete >> applications >> to install when py2exe is used. There also needs to be some >> assurance >> that the standard library has as few bugs in it as possible. The >> more >> that's added to it, the more work and testing to do that is needed. >> > > Almost by definition, applications using py2exe are minimal Python > installations without external dependencies. Yeah, py2exe only includes the portion of the standard library that you use, anyway... so the size of it is not an issue. -bob ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Thoughts on stdlib evolvement
Bob Ippolito wrote: > > On Jun 7, 2005, at 11:47 AM, Josiah Carlson wrote: > >> Ron Adam wrote: >> [snip] >> >>> Having less in the core distribution means smaller complete >>> applications >>> to install when py2exe is used. There also needs to be some assurance >>> that the standard library has as few bugs in it as possible. The more >>> that's added to it, the more work and testing to do that is needed. >>> >> >> Almost by definition, applications using py2exe are minimal Python >> installations without external dependencies. > > > Yeah, py2exe only includes the portion of the standard library that you > use, anyway... so the size of it is not an issue. > > -bob This wasn't the main point of my post in any case. Yes, as high bandwidth connections and disk space become more common, the organizational aspects are really more important than the size aspects. Cheers, Ron ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Thoughts on stdlib evolvement
> Fernando Perez wrote: >> Skip Montanaro wrote: >> >> I've wondered if it wouldn't be better if the std lib were all stuffed >> into its >> own namespace: >> >> from std import urllib >> >> If a more structured approach is desired, it could be >> >> from std.www import urllib > > One may want to look at the "py.std" approach of "the py lib", found at > http://codespeak.net/py/current/doc/misc.html#the-py-std-hook > > Reinhold Thats where I hijacked the idea. Doing that would allow both to work. Legacy code could still use: import logging and new code could use: import std.logging At some point the legacy way to do things should be deprecated. David ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] problem installing current cvs - TabError
On Tue, Jun 07, 2005 at 08:49:11PM +0200, Irmen de Jong wrote:
> furthermore the 'make install' of current cvs fails halfway trough
> with the following errors:
>
>.
>.
> Compiling /opt/python25/lib/python2.5/bsddb/test/test_associate.py ...
> Sorry: TabError: ('inconsistent use of tabs and spaces in indentation',
> ('/opt/python25/lib/python2.5/bsddb/test/test_associate.py', 97, 23, '\t
> os.mkdir(homeDir)\n'))
> Compiling /opt/python25/lib/python2.5/bsddb/test/test_basics.py ...
> Sorry: TabError: ('inconsistent use of tabs and spaces in indentation',
> ('/opt/python25/lib/python2.5/bsddb/test/test_basics.py', 400, 26, '\tif
> get_raises_error:\n'))
> Compiling /opt/python25/lib/python2.5/bsddb/test/test_compare.py ...
> Sorry: TabError: ('inconsistent use of tabs and spaces in indentation',
> ('/opt/python25/lib/python2.5/bsddb/test/test_compare.py', 167, 5, '\t"""\n'))
>.
>.
> Compiling /opt/python25/lib/python2.5/bsddb/test/test_recno.py ...
> Sorry: TabError: ('inconsistent use of tabs and spaces in indentation',
> ('/opt/python25/lib/python2.5/bsddb/test/test_recno.py', 38, 46,
> '\tget_returns_none =
> d.set_get_returns_none(2)\n'))
>.
>.
> make: *** [libinstall] Error 1
> $
>
> And then it quits.
> Fixing the tab indentation errors locally makes the problem go away.
ugh. this may be the result of me working on those files recently
without my usual .vimrc in place. i'll take a look. regardless,
where is the TabError coming from? those files are all valid python
even if they do have an annoying mix of spaces and tabs.
major gripe to -dev: a 'make install' of the full cvs tree should not
be required to test that some changes to existing .py files that pass
their tests (in this case they -are- the tests) are ok to check in.
Greg
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python running in several threads
Aahz wrote: >>Under those limitations, do you think, an easy rewrite of execution >>engine is possible to allow simultaneous run of all threads? > > > Short answer: no > > Longer answer: see previous threads about removing the GIL; if you still > have questions, please post to comp.lang.python. Or, as a medium-sized answer: google for "python free threading". Removing the GIL is easy, but then the interpreter crashes in cases of simultaneous accesses to dictionaries, reference counters, etc. I also disagree with Martin Aliger's premises: # This degrades performance IMHO, mainly on server installations # (many web servers use python engine). This is just not true. On a single-processor machine, the GIL does *not* degrade performance. Instead, it increases throughput (and thus performance). On a multi-processor machine, you often use multiple operating system processes to serve request (e.g. in CGI or Apache mpm-prefork, or even the typical mpm-worker configuration). If you then have different processes running Python, they don't interfere with each other at all. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] problem installing current cvs - TabError
Gregory P. Smith wrote: [SNIP] > major gripe to -dev: a 'make install' of the full cvs tree should not > be required to test that some changes to existing .py files that pass > their tests (in this case they -are- the tests) are ok to check in. > You actually don't have to. If you execute the interpreter that is built in your cvs checkout it will use the stdlib files as found in your cvs tree. So if you are in your cvs checkout, ``./python.exe `` will actually execute using the code in the cvs checkout itself. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] problem installing current cvs - TabError
On Wednesday 08 June 2005 07:08, Gregory P. Smith wrote: > ugh. this may be the result of me working on those files recently > without my usual .vimrc in place. i'll take a look. regardless, > where is the TabError coming from? those files are all valid python > even if they do have an annoying mix of spaces and tabs. There's a scripts Tools/scripts/reindent.py - put it somewhere on your PATH and run it before checkin, like "reindent.py -r Lib". It means Tim or I don't have to run it for you Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
