Has anyone recommended ftputil? Either add that to the library or
make the existing ftp module more high level would be my suggestion.
http://www.sschwarzer.net/python/python_software.html
-Greg
On 7 Jul 2005 05:38:28 -0700, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
1. LDAP module should
1. LDAP module should be included in the base distro.
2. DNS library really should be included in the base library, I emailed
Anthony Baxter and he replied, saying it was almost done.
3. Ipython would be nice
--
http://mail.python.org/mailman/listinfo/python-list
Terry Reedy wrote:
Colin J. Williams [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Isn't this where the discussion should start? There should be some
general policy guiding the types of modules which should be in the
standard library.
A couple of times, Guido has given his
Steven Bethard wrote:
Fredrik Johansson wrote:
On 6/27/05, Reinhold Birkenfeld
[EMAIL PROTECTED] wrote:
Do you have any other good and valued Python modules that you would
think are
bug-free, mature (that includes a long release distance) and useful
enough to
be granted a place in
On Fri, 1 Jul 2005, Scott David Daniels wrote:
Daniel Dittmar wrote:
Rocco Moretti wrote:
Except that (please correct me if I'm wrong) there is somewhat of a
policy for not including interface code for third party programs
which are not part of the operating system. (I.e. the modules in
Gregory Piñero wrote:
While that policy does make sense, I think a database program falls
somewhere in between an OS and an everyday third party program. For
web developers, the database might as well be the OS. I use the
database to store everything in my web app. That way I can just worry
Rocco Moretti wrote:
Paul Rubin wrote:
Rocco Moretti [EMAIL PROTECTED] writes:
Except that (please correct me if I'm wrong) there is somewhat of a
policy for not including interface code for third party programs which
are not part of the operating system. (I.e. the modules in the
standard
Colin J. Williams [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Isn't this where the discussion should start? There should be some
general policy guiding the types of modules which should be in the
standard library.
A couple of times, Guido has given his general policy as generally
Reinhold Birkenfeld wrote:
Hello,
Do you have any other good and valued Python modules that you would think are
bug-free, mature (that includes a long release distance) and useful enough to
be granted a place in the stdlib?
For my part, ctypes seems like a suggestion to start with.
ctypes
Hi All--
Max M wrote:
Another good bet is BeautifulSoup, which is absolutely great for
scraping content from webpages.
http://crummy.com/software/BeautifulSoup/index.html
Not if you want to handle HTML in anything but ASCII. BeautifulSoup
insists you change your site.py to change the
Paul Rubin wrote:
Rocco Moretti [EMAIL PROTECTED] writes:
Except that (please correct me if I'm wrong) there is somewhat of a
policy for not including interface code for third party programs which
are not part of the operating system. (I.e. the modules in the
standard libary should all be
Rocco Moretti wrote:
Except that (please correct me if I'm wrong) there is somewhat of a
policy for not including interface code for third party programs which
are not part of the operating system. (I.e. the modules in the
standard libary should all be usable for anyone with a default OS +
Daniel Dittmar wrote:
Rocco Moretti wrote:
Except that (please correct me if I'm wrong) there is somewhat of a
policy for not including interface code for third party programs which
are not part of the operating system. (I.e. the modules in the
standard libary should all be usable for anyone
On 6/29/05, Thomas Heller [EMAIL PROTECTED] wrote:
To me, this sounds that *at least* a PEP would be needed to convince
Guido. Or, to record the reasoning why it cannot be included.
I have a feeling that Guido won't allow ctypes into the standard
library since it can crash Python. I don't
Simon Brunning schrieb:
On 6/29/05, Christopher Arndt [EMAIL PROTECTED] wrote:
Adding sqllite to the standard library has been discussed before:
http://groups-beta.google.com/group/comp.lang.python/browse_thread/thread/fd150297c201f814
Yeah, but they didn't seem to have come to a
On Wed, 29 Jun 2005, it was written:
Rocco Moretti [EMAIL PROTECTED] writes:
Except that (please correct me if I'm wrong) there is somewhat of a
policy for not including interface code for third party programs which
are not part of the operating system.
I've never heard of Python having
Harry George [EMAIL PROTECTED] writes:
b) Installing distutils-aware python packages is trivial. I'd rather
the energy which might go into a bigger std library go instead into
helping projects which don't have distutils-style builds.
How about integrating distutils and PyPI, so that
Mike Meyer wrote:
Harry George [EMAIL PROTECTED] writes:
b) Installing distutils-aware python packages is trivial. I'd rather
the energy which might go into a bigger std library go instead into
helping projects which don't have distutils-style builds.
How about integrating distutils and
On 6/28/05, John Roth [EMAIL PROTECTED] wrote:
I'd definitely like to see ctypes. I can agree with the segfault
issue, but I think that some design work would eliminate that.
I'm not sure that it would. Ctypes allows you, as one colleague
memorably put it, to poke the operating system with a
Simon Brunning [EMAIL PROTECTED] writes:
On 6/28/05, John Roth [EMAIL PROTECTED] wrote:
I'd definitely like to see ctypes. I can agree with the segfault
issue, but I think that some design work would eliminate that.
I'm not sure that it would. Ctypes allows you, as one colleague
memorably
I'd like to see some database API's to the most common databases
included. It would make Python much more useful for web development.
I've come across situations where a web host supports python and
supports MySQL yet it's taken me days to get the MySQLAPI installed
with running setup in my home
George Sakkis wrote:
bruno modulix [EMAIL PROTECTED] wrote:
George Sakkis wrote:
I'd love to see IPython replace the standard interpreter.
I dont.
Care to say why ?
Sorry...
it was about the replace, not about IPython itself nor about IPython
becoming part of the stdlib.
IPython is a
One of my votes would be for something like:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/303481or
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/303770.
We use something like these in the stdlib already (time_struct), but don't supply a ready solution for people to implement
Gregory Piñero [EMAIL PROTECTED] writes:
I'd like to see some database API's to the most common databases
included.
Yes, certainly, this is a serious deficiency with Python.
--
http://mail.python.org/mailman/listinfo/python-list
While that policy does make sense, I think a database program falls
somewhere in between an OS and an everyday third party program. For
web developers, the database might as well be the OS. I use the
database to store everything in my web app. That way I can just worry
about 1 place to access
And 1 more argument for adding DB support, a large part of PHP's
success as a web langauge is being easily interoperable with MySQL
(out of the box I think? I haven't used it.) But I think it's tight
integration with MySQL really helped it find its niche.
I think batteries included means
Noah wrote:
def unzip(list):
if len(list) == 0: return ()
l = []
for t in range(len(list[0])):
l.append(map( lambda x,t=t: x[t], list ))
return tuple(l)
The simplest solution to this problem that I know of:
def unzip(iterable):
return zip(*iterable)
Rocco Moretti [EMAIL PROTECTED] writes:
Except that (please correct me if I'm wrong) there is somewhat of a
policy for not including interface code for third party programs which
are not part of the operating system. (I.e. the modules in the
standard libary should all be usable for anyone
On Wednesday 29 June 2005 04:55 am, Simon Brunning wrote:
On 6/28/05, John Roth [EMAIL PROTECTED] wrote:
I'd definitely like to see ctypes. I can agree with the segfault
issue, but I think that some design work would eliminate that.
I'm not sure that it would. Ctypes allows you, as one
I'll 2nd the vote for Pychecker.
--
http://mail.python.org/mailman/listinfo/python-list
George Sakkis wrote:
I'd love to see IPython replace the standard interpreter.
I dont.
--
bruno desthuilliers
python -c print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in '[EMAIL PROTECTED]'.split('@')])
--
http://mail.python.org/mailman/listinfo/python-list
bruno modulix [EMAIL PROTECTED] wrote:
George Sakkis wrote:
I'd love to see IPython replace the standard interpreter.
I dont.
Care to say why ?
George
--
http://mail.python.org/mailman/listinfo/python-list
Reinhold Birkenfeld [EMAIL PROTECTED] wrote in
message news:[EMAIL PROTECTED]
Hello,
at the moment python-dev is discussing including Jason Orendorff's path
module
into the standard library.
Do you have any other good and valued Python modules that you would think
are
bug-free, mature
George Sakkis wrote:
bruno modulix [EMAIL PROTECTED] wrote:
George Sakkis wrote:
I'd love to see IPython replace the standard interpreter.
I dont.
Care to say why ?
For an easy, quick interactive interpreter, it's way to overloaded
with functions and too slow in startup.
However,
Reinhold Birkenfeld [EMAIL PROTECTED] wrote:
George Sakkis wrote:
bruno modulix [EMAIL PROTECTED] wrote:
George Sakkis wrote:
I'd love to see IPython replace the standard interpreter.
I dont.
Care to say why ?
For an easy, quick interactive interpreter, it's way to overloaded
George Sakkis wrote:
Reinhold Birkenfeld [EMAIL PROTECTED] wrote:
For an easy, quick interactive interpreter, it's way to overloaded
with functions and too slow in startup.
Too slow ? It doesn't take more than a second or two to startup in a
two years old 1.8Ghz Athlon and an older 900Mhz
Do you have any other good and valued Python modules that you would
think are bug-free, mature (that includes a long release
distance) and useful enough to be granted a place in the stdlib?
First of all, numeric/numarray, obviously!
There has been recent discussion about this. Check
Hello,
at the moment python-dev is discussing including Jason Orendorff's path module
into the standard library.
Do you have any other good and valued Python modules that you would think are
bug-free, mature (that includes a long release distance) and useful enough to
be granted a place in the
Reinhold Birkenfeld [EMAIL PROTECTED] writes:
Hello,
at the moment python-dev is discussing including Jason Orendorff's path module
into the standard library.
I have never used the path module before, although I've heard good
things about it. But, it seems to have problems with unicode
On 6/27/05, Reinhold Birkenfeld [EMAIL PROTECTED] wrote:
Do you have any other good and valued Python modules that you would think are
bug-free, mature (that includes a long release distance) and useful enough to
be granted a place in the stdlib?
First of all, numeric/numarray, obviously!
I'd
Reinhold Birkenfeld wrote:
For my part, ctypes seems like a suggestion to start with.
I believe this has been discussed somewhere before and the conclusion
was that ctypes should not be a candidate for inclusion in the Python
stdlib because people don't want things in the stdlib that can make
Fredrik Johansson wrote:
On 6/27/05, Reinhold Birkenfeld [EMAIL PROTECTED] wrote:
Do you have any other good and valued Python modules that you would think are
bug-free, mature (that includes a long release distance) and useful enough to
be granted a place in the stdlib?
First of all,
I'd love to see IPython replace the standard interpreter. Pychecker
seems to be a strong candidate too.
George
--
http://mail.python.org/mailman/listinfo/python-list
Reinhold Birkenfeld wrote:
Hello,
at the moment python-dev is discussing including Jason Orendorff's path module
into the standard library.
Do you have any other good and valued Python modules that you would think are
bug-free, mature (that includes a long release distance) and useful
Robert Kern wrote:
I would like to see the setuptools/PythonEggs/EasyInstall trifecta get
more attention and eyeballs. Once it is mature, I think that it will
obviate the desire for stdlibification of most of the packages being
requested here.
Looks pretty cool!
--
Michael Hoffman
--
pyparsing is the far and away the easiest general purpose parser out
there that I've encountered; BNF-style grammar parsing is a *pleasure*
with pyparsing. And it all comes in a single pure python module to
boot.
--
http://mail.python.org/mailman/listinfo/python-list
46 matches
Mail list logo
