Fredrik Lundh wrote:
[snip]
> in my experience, any external library that supports more than one
> Python version on more than one platform is likely to be more robust
> than code in the core. add the multilevel volunteer approach de-
> described by Steven (with the right infrastructure, things li
Gustavo Niemeyer wrote:
> > > moving the main trunk and main development over to the Python CVS is
> > > another thing, entirely.
> >
> > (as I've said many times before, both the user community and the developer
> > community would benefit if the core standard library were made smaller, and
> > m
> "Gustavo" == Gustavo Niemeyer <[EMAIL PROTECTED]> writes:
Gustavo> An issue to consider about this is that maintainers (not
Gustavo> talking about you or anyone else specifically) have
Gustavo> different concepts of stability, and while it may seem
Gustavo> perfectly ok to re
> > moving the main trunk and main development over to the Python CVS is
> > another thing, entirely.
>
> (as I've said many times before, both the user community and the developer
> community would benefit if the core standard library were made smaller, and
> more externally maintained packages w
> moving the main trunk and main development over to the Python CVS is
> another thing, entirely.
(as I've said many times before, both the user community and the developer
community would benefit if the core standard library were made smaller, and
more externally maintained packages were included
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 addition to the
> 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 l
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 librar
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 pos
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 d
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.
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, le
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
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
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
30 matches
Mail list logo
