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
>>
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 bring
> "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 p
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, lea
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 nam
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
At 03:17 PM 6/6/2005 -0700, Bob Ippolito wrote:
>Personally I'd like to see the standard library get smaller rather
>than larger. There's a whole lot of bit rot in there, and since
>sys.path prefers the standard library over anything else it's a
>really huge pain to integrate patches on a faster r
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.
-1. I feel the opposite way: when trying to figure out where something
"
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
>> Element
> > 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 addition to the standard library.
Rewritten:
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 b
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
>
> i
> "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
>>
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
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 compatib
> - 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 additio
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 clari
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 decorato
18 matches
Mail list logo
