Paul Moore wrote:
Unfortunately, I don't have a better naming suggestion (other than
simply template, which is probably too general to work), so I just
raise this as something you should expect to need to clarify a few
times...
PEP 346 used statement_template for the generator decorator. That
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
- 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],
If Fred were up for it, I think ElementTree would be a wonderful,
must-have addition.
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
On Mon, 2005-06-06 at 14:38, Skip Montanaro wrote:
import urllib
from www.urllib import urlopen
the module-level code should only be executed once, and
urlopen == urllib.urlopen
should evaluate to True.
Not to mention urlopen is urllib.urlopen
-Barry
signature.asc
Barry == Barry Warsaw [EMAIL PROTECTED] writes:
Barry On Mon, 2005-06-06 at 14:38, Skip Montanaro wrote:
import urllib
from www.urllib import urlopen
the module-level code should only be executed once, and
urlopen == urllib.urlopen
should evaluate
Skip Montanaro wrote:
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
Raymond Hettinger wrote:
ElementTree, [wxPython - I know this is a hairy issue],
If Fred were up for it, I think ElementTree would be a wonderful,
must-have addition.
I might be missing fine details of the English language here
(what does to be up for something mean?), however, I believe
On Jun 6, 2005, at 3:10 PM, Raymond Hettinger wrote:
If Fred were up for it, I think ElementTree would be a wonderful,
must-have addition.
I might be missing fine details of the English language here
(what does to be up for something mean?), however, I believe
ElementTree is an unlikely
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
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
Skip == Skip Montanaro [EMAIL PROTECTED] writes:
Skip If you provide the necessary namespace structure for them to
Skip nestle into, I suspect most of them could be maintained
Skip outside the stdlib just fine.
FWIW, this has worked well for XEmacs; it's one of our most popular
Josiah Carlson wrote:
Fernando Perez 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
This generally brings up the
Fernando Perez wrote:
Josiah Carlson wrote:
Fernando Perez 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
This generally brings up the
14 matches
Mail list logo
