Fredrik Lundh wrote:
> I can help build an infrastructure that makes it easier to create a more
> complete standard distribution, sure. (and since this isn't exactly a new
> idea, I'm 100% confident that I don't have to do all the work myself.)
>
> if this is needed is something for the PSF to de
Fredrik Lundh wrote:
Robert Kern wrote:
Agreed, which is why I think that proper package management and a CPyAN-type system is the way to
go, not trying to stuff everything into a single distribution.
I think we're looking at this in two different ways: you're looking at it from the
"sumo
pytho
Skip Montanaro wrote:
>> I guess the other thing to compare to is something like SciPy, which
>> is a kind of specialized distribution of Python for scientific
>> applications.
Robert> No, Scipy is just a (large) package. Enthon, on the other hand,
Robert> is just such a distrib
>> I guess the other thing to compare to is something like SciPy, which
>> is a kind of specialized distribution of Python for scientific
>> applications.
Robert> No, Scipy is just a (large) package. Enthon, on the other hand,
Robert> is just such a distribution.
I'm sorry, y
Martin v. Löwis wrote:
I personally find the notion of "path objects" confusing. Is this a
real path name on the local system, or merely a potential one? If
potential, why does it have a .size attribute
(what is the size of a non-existing file)?
Logically (and, I feel, quite intuitively), it's a
Robert Kern wrote:
> Agreed, which is why I think that proper package management and a CPyAN-type
> system is the way to
> go, not trying to stuff everything into a single distribution.
I think we're looking at this in two different ways: you're looking at it from
the "sumo
python distribution
Fredrik Lundh wrote:
Robert Kern wrote:
(the Linux distributors know how to do this: look for good stuff that's
either actively maintained or simple and solid enough to live for a while,
make sure the licenses are good enough, bundle the latest and greatest
version, ship tested versions at regular
Martin v. Löwis wrote:
>> if I were in charge
>
> Would you like to be?
I can help build an infrastructure that makes it easier to create a more
complete standard distribution, sure. (and since this isn't exactly a new
idea, I'm 100% confident that I don't have to do all the work myself.)
if th
Robert Kern wrote:
>> (the Linux distributors know how to do this: look for good stuff that's
>> either actively maintained or simple and solid enough to live for a while,
>> make sure the licenses are good enough, bundle the latest and greatest
>> version, ship tested versions at regular interval
Fredrik Lundh wrote:
I'm not talking about things that absolutely have to be in the Python
interpreter core; I'm talking about things that *could* be bundled
with the standard distribution, *without* having to be relicensed,
or be forever maintained by the CPython developers.
(the Linux distributor
Terry Hancock wrote:
On Sunday 10 April 2005 05:14 pm, Fredrik Lundh wrote:
I'm not talking about things that absolutely have to be in the Python
interpreter core; I'm talking about things that *could* be bundled
with the standard distribution, *without* having to be relicensed,
or be forever maint
On Sunday 10 April 2005 05:14 pm, Fredrik Lundh wrote:
> I'm not talking about things that absolutely have to be in the Python
> interpreter core; I'm talking about things that *could* be bundled
> with the standard distribution, *without* having to be relicensed,
> or be forever maintained by the
Martin v. Löwis wrote:
> I can see why you are not willing to do some of these things. But
> I can't see why that is for other things. For example, why are you
> not willing to license your contribution to the PSF (nobody asks
> you to "sign it over")?
Because the software already has a license?
Fredrik Lundh wrote:
> because we're not willing to go through endless PEP processes,
> generate patches that end up sitting on sourceforge for years, deal
> with shitstorms initiated by developers of "competing" libraries, sign
> over our copyrights to the PSF, loose control over the code base,
>
Martin v. Löwis wrote:
> For a number of libraries added recently, I heard lots of complaints
> how terrible they are to use, including, in particular, the XML
> and logging libraries, and the Unicode type, and that "something
> else" is so much easier to use. Why is it that the authors of
> "some
On Sun, 10 Apr 2005 13:18:01 +0200, "Fredrik Lundh"
<[EMAIL PROTECTED]> wrote:
>Kay Schluehr wrote:
>
>> I fear that Python 3.0 becomes some kind of vaporware in the Python
>> community that paralyzes all redesign efforts on the std-lib.
Even if Python 3.0 never materializes, The documented PEP m
Fredrik Lundh wrote:
> if I were in charge
Would you like to be?
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
Fredrik Lundh wrote:
> here are three alternatives:
>
> ltree (http://codespeak.net/lxml/)
> libxml2 (http://xmlsoft.org/downloads.html)
> celementtree (http://effbot.org/zone/celementtree.htm)
Thanks, Fredrik, I will take a look.
Ciao,
Kay
--
http://mail.python.org/mailman/listin
Kay Schluehr wrote:
> > it's also GPL:ed, and the namespace support is totally broken. there
> > are faster solutions out there with Python-compatible licenses.
>
> Interesting. Which implementation "out there" ( so not in the std-lib )
> that maps the whole XML into an internal structure and mak
Fredrik Lundh wrote:
> Kay Schluehr wrote:
>
> > You have already given the arguments in Your discussion above. I
> > personally never use the standard-lib XML parser, but pyRXP/pyRXPU
> > which is fast, stores objects in pythonic list/tuple/dict
structures
> > and provides access by lazy tagging
Kay Schluehr wrote:
> I fear that Python 3.0 becomes some kind of vaporware in the Python
> community that paralyzes all redesign efforts on the std-lib.
that, combined with the old observation that CPython developers,
when given a choice, prefer to write C code over Python code, is
making the st
Kay Schluehr wrote:
> You have already given the arguments in Your discussion above. I
> personally never use the standard-lib XML parser, but pyRXP/pyRXPU
> which is fast, stores objects in pythonic list/tuple/dict structures
> and provides access by lazy tagging
it's also GPL:ed, and the namesp
Martin v. Löwis wrote:
> That said, if the people who want a path object would get together
> and contribute one, the library could be extended. I don't know
> whether this would be an improvement, though - os.path could not
> go away for backwards compatibility, so users would now have *two*
> wa
Kay Schluehr wrote:
> I slightly disagree. It's a symptom. The example of the path-module is
> instructive because it actually represents path objects not just a
> bunch of functions in isolation that manipulate strings that can be
> interpreted as paths. I started to read in the lib.py documentati
Steve Holden wrote:
> You are correct in suggesting that the library could be better
organized
> than it is, but I felt we would be better off deferring such change
> until the emergence of Python 3.0, which is allowed to break
backwards
> compatibility. So, start working on your scheme now - PEP
Martin v. Löwis wrote:
> Is it good that people write these wrappers?
No.
> I don't think so. Is it
> the library's fault? I don't think so, either. People write these
> wrappers because they cannot remember how to use the library.
I slightly disagree. It's a symptom. The example of the path-m
vegetax wrote:
> Why does people have to put wrappers around about half of the standart
> library modules? i have wrappers for urllib,urllib2, [... many more ...]
>
> I mean is this normal?
Not sure what "this" is :-) Is it normal that people write wrappers
around libraries? Yes, most certainly s
On Sat, 09 Apr 2005 02:22:45 -0400, Steve Holden <[EMAIL PROTECTED]>
wrote:
>Ron_Adam wrote:
>> On Fri, 08 Apr 2005 05:15:23 -0400, vegetax <[EMAIL PROTECTED]>
>> wrote:
>>
>>
>>>Are those issues being considered right now? i cant find any PEP addressing
>>>the issue especifically, at least cook
Ron_Adam wrote:
On Fri, 08 Apr 2005 05:15:23 -0400, vegetax <[EMAIL PROTECTED]>
wrote:
Are those issues being considered right now? i cant find any PEP addressing
the issue especifically, at least cooking it for python 3000.
specific topics could be:
grouping related modules.
removing useless lega
On Fri, 08 Apr 2005 05:15:23 -0400, vegetax <[EMAIL PROTECTED]>
wrote:
>Are those issues being considered right now? i cant find any PEP addressing
>the issue especifically, at least cooking it for python 3000.
>
>specific topics could be:
>
>grouping related modules.
>removing useless legacy modu
"vegetax" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> And those thoughts comes to mind again, if python is such a great
> language
> why does the stdlib is so bloated with duplication,bad bad library
> design,clumsy to use modules,etc.
Some general responses:
1. The Python lib
vegetax <[EMAIL PROTECTED]> wrote:
> And those thoughts comes to mind again, if python is such a great language
> why does the stdlib is so bloated with duplication,bad bad library
> design,clumsy to use modules,etc.
> I mean is this normal? i dont think so.I havent seen such a messy stdlib in
>
I was messing around in google looking for the available python form
validation modules when i found this:
http://www.jorendorff.com/articles/python/path/, and i realized that is very
similar to my python fileutils module,which encapsulate,path
operations,file operations,etc.
And those thoughts co
33 matches
Mail list logo
