On Thursday 20 April 2006 15:54, Martin v. Löwis wrote:
If you (Anthony) want to act as a second for setuptools, I
would feel much happier - because I can then blame you for
whatever problems that decision causes five years from now.
Done. See my longer reply setuptools in 2.5. I think I just
On 4/19/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
I see a significant procedural difference between what happened
for ctypes, elementtree, and pysqlite, as opposed to setuptools.
For all these packages, there was
1. a desire of users to include it
2. an indication from the package
On Thursday 20 April 2006 15:53, Martin v. Löwis wrote:
I don't know about Phillip's plans, but I do see many indications
that people stop using distutils, and use setuptools instead.
Surely that's an indication that it _should_ become part of Python? If
there's an obvious demand for the
Anthony Baxter wrote:
And now let's look at some of the stuff that setuptools gives us:
- We have a CPAN-type system
I think it is unfair (to Richard Jones) to attribute this to
setuptools. We already have a CPAN-type system: the Cheeseshop.
What setuptools adds is roughly the CPAN shell
Greg Ewing wrote:
I'm not sure whether distutils is really that
badly broken. But an earlier poster seemed to be
saying that he had great difficulty finding anything
that could be changed without breaking something
that someone relied on. It's hard to fix something
if you can't change it at
On Thursday 20 April 2006 16:30, Martin v. Löwis wrote:
I think it is unfair (to Richard Jones) to attribute this to
setuptools. We already have a CPAN-type system: the Cheeseshop.
What setuptools adds is roughly the CPAN shell (ie. CPAN.pm
or however it is implemented). Actually, I think it
Phillip J. Eby wrote:
I assumed that it would be more controversial to merge setuptools into
distutils, than to provide it as an enhanced alternative.
It is this assumption in setuptools that seems to have guided many
design decisions: that it is completely unacceptable to change
Thanks for posting an excellent summary, Anthony.
For the record, I'm taking full responsibility for the decision that
setuptools is going in. Having read much (though not all) of the
endless bitching, and the responses from Phillip and others in
defense, I still believe it's the right decision.
I don't understand it.
Have you read the manuals?
You mean,
http://peak.telecommunity.com/DevCenter/setuptools
Yes, I did. However, this would only enable me to use it (should I
ever find a need). What I really need to understand is how all this
stuff works inside.
Now, I haven't actually
Andrew Clover wrote:
Morning!
I've done some tweaks to the previously-posted-about icon set, taking
note of some of the comments here and on -list.
you do wonderful stuff, and then you post the announcement as a
followup to a really old message, to make sure that people using a
threaded
This spring and summer, Google will again provide stipends
for students (18+, undergraduate thru PhD programs) to write
new open-source code.
The Python Software Foundation (PSF)
http://www.python.org/psf/
will again act as a sponsoring organization in Google's Summer of Code,
matching
Anthony Baxter wrote:
Not without a lot of the other stuff that's in setuptools.
That is says from itself that it is version 0.7a1dev-r45536
doesn't help to reduce that fear.
It's had _two_ _years_ of quite active development, so the version
number of 0.7 is hardly a good indication. As
Fredrik Lundh wrote:
you do wonderful stuff, and then you post the announcement as a
followup to a really old message, to make sure that people using a
threaded reader only stumbles upon this by accident... this should
be on the python.org frontpage!
I also wonder what the actions should be
On Thursday 20 April 2006 17:51, Martin v. Löwis wrote:
He's written code on _top_ _of_ _distutils_. How is this bad?
It makes distutils an implementation detail of setuptools. What
little development distutils has seen will stop; all fixes will
go into setuptools directly. Users will be
Phillip J. Eby wrote:
How much any of that could have also applied to the distutils at one
time, I don't know. My point is merely that setuptools has enough
commercial value to make me believe that sponsorship for features
shouldn't be that hard to come by, and there are certainly worse
Neal Norwitz wrote:
This was run on linux amd64. It would be great to run purify on
windows and other platforms. If you do, please report back here, even
if nothing was found. That would be a good data point.
Summary of tests with problems:
test_codecencodings_jp (1 invalid read)
Anthony Baxter wrote:
I also don't think it will be the death of distutils. I think that
over time the two pieces of code will become closer together -
hopefully for Python 3.0 we can formally merge the two.
I was hoping that for Python 3.0, we could get around to unkludge the
Fredrik Lundh wrote:
Anthony Baxter wrote:
I also don't think it will be the death of distutils. I think that
over time the two pieces of code will become closer together -
hopefully for Python 3.0 we can formally merge the two.
I was hoping that for Python 3.0, we could get around to
Terry Reedy wrote:
I took a look. The only thing that puzzles me is 'warp factor', which
appears exactly once.
It's been put there via time machine in connection
with the dilithium crystal support in that will be
added in Python 7.0. You don't need to worry about
it yet.
--
Greg
Fredrik Lundh wrote:
(distutils and setuptools are over 15000 lines of code, according to sloc-
count.
Ye cats! That's a *seriously* big ball of mud. I just checked,
and the whole of Pyrex is only 17000 lines.
--
Greg
___
Python-Dev mailing list
I didn't have a chance to comment earlier on the Path class PEP,
but I'm dealing with an analogous situation at work and I'd like to
weigh in on it.
The issue is - should paths be specialized objects or regular strings?
PEP 355 does an excellent job, I think, of presenting the case for paths
Phillip J. Eby wrote:
If they have Pyrex installed, setuptools uses
Pyrex to rebuild the .c from the .pyx.
I hope it would only do this if the .pyx was newer than the
.c. It's probably not a good idea to assume that just because
Pyrex is around, the user wants to use it in all cases. He
might
Neal Norwitz [EMAIL PROTECTED] writes:
Please add your project ideas to the existing set at
http://wiki.python.org/moin/SummerOfCode
I'd like to see ctypes supported on GCC ARM platforms. ARM is the only major
Debian architecture that's not supported by ctypes. The underlying issue is
Greg Ewing wrote:
Fredrik Lundh wrote:
(distutils and setuptools are over 15000 lines of code, according to sloc-
count.
Ye cats! That's a *seriously* big ball of mud. I just checked,
and the whole of Pyrex is only 17000 lines.
correction: it's actually only 14000 lines, but it's still
Anthony Baxter wrote:
http://www.joelonsoftware.com/articles/fog69.html
From what I remember, he didn't actually say that you
should never rewrite anything, but that if you do, you
need to be prepared for a very long period of time
when nothing new is working, and that *if you are a
Ganesan Rajagopal wrote:
Neal Norwitz [EMAIL PROTECTED] writes:
Please add your project ideas to the existing set at
http://wiki.python.org/moin/SummerOfCode
I'd like to see ctypes supported on GCC ARM platforms. ARM is the only major
Debian architecture that's not supported by
On 4/20/06, Greg Ewing [EMAIL PROTECTED] wrote:
Anthony Baxter wrote:
http://www.joelonsoftware.com/articles/fog69.html
From what I remember, he didn't actually say that you
should never rewrite anything, but that if you do, you
need to be prepared for a very long period of time
On Thursday 20 April 2006 17:42, Martin v. Löwis wrote:
4. .egg files. -1
As far as I understand it, an egg file is just a zipimport format zip
file with some additional metadata. You can also install the egg
files in an unpacked way, if you prefer that. I don't understand the
objection here
On Thursday 20 April 2006 18:18, Fredrik Lundh wrote:
I was hoping that for Python 3.0, we could get around to unkludge
the sys.path/meta_path/path_hooks/path_importer_cache big ball of
hacks, possibly by replacing sys.path with something a bit more
intelligent than a plain list.
Oh please,
On 4/20/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
3. package resources. I dislike the term resources (it is not about
natural gas, water, main memory, or processor cycles, right?);
instead, this seems to provide access to embedded data files.
Apparently, there is a need for it, so
Guido van Rossum wrote:
I'd rather recommend the approach that Joel suggests for truly large
systems: refactoring smaller components while keeping the overall
structure intact.
That's fine as long as the overall structure isn't the
very thing that's wrong and needs to be fixed.
Incremental
On 4/20/06, Anthony Baxter [EMAIL PROTECTED] wrote:
On Thursday 20 April 2006 18:18, Fredrik Lundh wrote:
I was hoping that for Python 3.0, we could get around to unkludge
the sys.path/meta_path/path_hooks/path_importer_cache big ball of
hacks, possibly by replacing sys.path with something
Thomas Heller [EMAIL PROTECTED] writes:
Ganesan Rajagopal wrote:
Neal Norwitz [EMAIL PROTECTED] writes:
Please add your project ideas to the existing set at
http://wiki.python.org/moin/SummerOfCode
I'd like to see ctypes supported on GCC ARM platforms. ARM is the only major
Debian
Guido == Guido van Rossum [EMAIL PROTECTED] writes:
On 4/20/06, Ganesan Rajagopal [EMAIL PROTECTED] wrote:
I started editing the page, then I thought I'd first post here to get your
feedback :-).
That approach doesn't scale; please use the wiki for feedback, not the
mailing list (because
Phillip J. Eby wrote:
At 11:41 PM 4/19/2006 +1000, Nick Coghlan wrote:
Given that naming though, I think contextlib.contextmanager should be
renamed
to contextlib.context.
The name is actually correct under this terminology arrangement.
@contextmanager *returns* a context manager.
Steven Bethard wrote:
On 4/17/06, Russell E. Owen [EMAIL PROTECTED] wrote:
At some point folks were discussing use cases of make where it was
important to preserve the order in which items were added to the
namespace.
I'd like to suggest adding an implementation of an ordered dictionary to
On Thu, Apr 20, 2006 at 07:53:55AM +0200, Martin v. Löwis quoted:
It is flatly not possible to fix distutils and preserve backwards
compatibility.
Would it be possible to figure what parts are problematic, and
introduce PendingDeprecationWarnings or DeprecationWarnings so
that we can fix
On Thu, Apr 20, 2006 at 11:33:30AM +0100, Guido van Rossum wrote:
Unfortunately, this is mixed in with some stuff that isn't part of
distutils' core competency, like text utilities, process spawning,
and option parsing. These should (eventually, when the 2.1
compatibility requirement is
On Thu, 2006-04-20 at 07:53 +0200, Martin v. Löwis wrote:
Sometimes you _have_ to rewrite. I point to
urllib-urllib2, asyncore-twisted, rfc822/mimelib/c-email.
If I had the time, I would question each of these. Yes, it is
easier for the author of the new package to build in the
green,
The arguments against:
One more:
- Installing a package means dropping files in the system without
any kind of record keeping.
It should learn from the techniques applied in other well-known
package managers (RPM, DPKG, whatever) to keep track of what's
happening in the system.
--
many times, templating a string is a tidious task. using the % operator, either with tuples or dicts,is difficult to maintain, when the number of templated arguments is large. and string.Template,although more easy to read, is less intutive and cumbersome:
import stringt = string.Template(hello
On Thu, 2006-04-20 at 11:33 +0100, Guido van Rossum wrote:
Unfortunately, this is mixed in with some stuff that isn't part of
distutils' core competency, like text utilities, process spawning,
and option parsing. These should (eventually, when the 2.1
compatibility requirement is lifted) be
Talin, everything you wrote is really compelling. If path.py weren't
so ridiculously useful to me, I would be completely convinced. :)
For example, I agree 100% with this:
Another reason why I am a bit dubious about a class-based approach
is that it tends to take anything that is related to
Brett Cannon wrote:
Not sure whether Fredrik Lundh has responded, but I believe he once
said that he would prefer if ElementTree isn't directly modified, but
that instead patches are filed on the SF tracker and assigned to him.
Nope, Fredrik never responded. I am cc:ing him directly to
I'm about to import the 0.9.9.6 tag of ctypes into Python svn.
Should this be done in exact the same way as before, so first
commit it into external/ctypes-0.9.9.6, and then 'svn copy'
the two relevant directories into the trunk, and afterwards set
all the svn props again, or is this done in
Thomas Heller wrote:
I'm about to import the 0.9.9.6 tag of ctypes into Python svn.
Should this be done in exact the same way as before, so first
commit it into external/ctypes-0.9.9.6, and then 'svn copy'
the two relevant directories into the trunk, and afterwards set
all the svn props
Anthony Finally, I'd like to point out that I think some of the
Anthony hostility towards Phillip's work has been excessive. He's done
Anthony an amazing amount of work on this (look at the distutils-sig
Anthony archive for the last two years for more), and produced
Anthony
I've found thread on python-dev related to pdb's weaknesses:
http://www.mail-archive.com/python-dev@python.org/msg05115.html
The opinions are that pdb is 'one of the more unPythonic modules' and
must be 'seriously
fixed'.I have similar experience with pdb's internals but I want to
know others
Anthony I don't think it's fair to say that Phillip just checked this
Anthony in off on his own.
In addition, since he did the development in the Python sandbox, his
checkins all along have been there for everyone to see. It's not like he
did the work in Outer Mongolia then showed up
Martin c) ask for consent in advance to making a potentially-breaking
Martinchange.
Doesn't that potentially extend the release time for an enhanced distutils
across multiple Python releases? With both distutils and setuptools
available simultaneously, setuptools can be designed and
[EMAIL PROTECTED] wrote:
Maybe they know something we don't.
oh, please. it's not like people like myself and MAL don't know anything
about package distribution...
(why is it that people who *don't* distribute stuff are a lot more im-
pressed by a magic tool than people who've spent the last
Fredrik applying emergency patches (stuff that blocks the build, and
Fredrik security fixes) is of course okay, but I would prefer if
Fredrik everything else is handled via the ET master repository.
Could that reference be placed in a comment near the top of
just like r does the escaping for you.but estr types must be implemented so the evaluate with the current scope (locals and globals),not the score they were defined it, so unless you want to do nasty tricks with sys._getframe,
which doesn't work on all implementations of python, you'll need it as
tomer filiba wrote:
many times, templating a string is a tidious task. using the %
operator, either with tuples or dicts,
is difficult to maintain, when the number of templated arguments is
large. and string.Template,
although more easy to read, is less intutive and cumbersome:
import
If you don't like the $name style of template markup and prefer
delimiters instead, then check-out the recipe at:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/3053
The link should have been:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/305306
We already have a slew of templating utilities (see Cheetah for example).first of all -- i know there's a bunch of templating engines, but i think it should be a
built-in feature of the language. like boo does. and estr is stronger than simple $name substitution, like Template does.
Be sure to
Tomer, please stop. We've seen your proposal. We've said -1. Please
take it instead of wasting your time trying to argue for it.
On 4/20/06, tomer filiba [EMAIL PROTECTED] wrote:
We already have a slew of templating utilities (see Cheetah for example).
first of all -- i know there's a bunch
Anthony Baxter wrote:
4. .egg files. -1
As far as I understand it, an egg file is just a zipimport format zip
file with some additional metadata. You can also install the egg
files in an unpacked way, if you prefer that. I don't understand the
objection here - it's no better or worse
Guido van Rossum wrote:
This is another area where API standardization is
important; as soon as modules are loaded out of a zip file, the
traditional approach of looking relative to os.path.dirname(__file__)
no longer works.
Certainly. However, I get two conclusions out of this:
1. don't load
Jérôme Laheurte wrote:
Sorry I'm late, but something like os.popen('taskkill.exe /F /IM
python_d.exe') would have worked; we use this at work.
Thanks, I didn't know about it. Is it available on Windows 2000,
too? (because the system in question is Windows 2000, and I see
it on a What's new in
On 20-apr-2006, at 21:53, Martin v. Löwis wrote:
However, this isn't really my objection to .egg files. I dislike them
because they compete with platform packages: .rpm, .msi, .deb.
As far as I understand the issues they compete up to a point, but should
also make it easier to create
tomer filiba [EMAIL PROTECTED]
i don't mean to be rude,
Then don't be. Your worst was the silly suggestion in an ad hominen barb
that a contributor of many years does not belong on this list. But this
time-wasting quibble post, in response to a request to quit wasting
everyone's time,
Bob Ippolito wrote:
They DO NOT compete any more than source packages do. eggs are packages
plus metadata, nothing more. What eggs do and what rpm/msi/deb does are
orthogonal. It's entirely reasonable that in the future rpm/msi/deb
will simply be a delivery mechanism for eggs.
That might
M.-A. Lemburg wrote:
Anthony Baxter wrote:
In an attempt to help this thread reach some sort of resolution,
here's a collection of arguments against and in favour of setuptools
in 2.5. My conclusions are at the end.
Thanks for the summary. I'd like to add some important aspects
(for me
On 4/20/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
1. don't load packages out of .zip files. It's not that bad if
software on the user's disk occupies multiple files, as long as
there is a convenient way to get rid of them at once.
Many problems go away if you just say no to
Ronald Oussoren wrote:
As far as I understand the issues they compete up to a point, but should
also make it easier to create platform packages that contain proper the
proper dependencies because those are part of machine-readable meta-data
instead of being written down in readme files. Oddly
Ian Bicking wrote:
And now for a little pushback the other way -- as of this January
TurboGears has served up 100,000 egg files (I'm not sure what the window
for all those downloads is, but it hasn't been very long). Has it
occurred to you that they know something you don't about
Greg Ewing wrote:
The resources name is actually quite a common meme;
I believe it goes back to the original Macintosh, which
was the first and only computer in the world to have files
with something called a resource fork. The resource fork
contained pieces of data called resources.
I can
Bob Ippolito wrote:
'There are several binary formats that embody eggs, but the most common
is '.egg' zipfile format, because it's a convenient one for distributing
projects.'
'.egg files are a zero installation format for a Python package;'
single modules are also such a zero installation
Ian Bicking wrote:
I don't think setuptools version requirements are enough to ensure the
integrity of all pieces of a complex system will work together.
Figuring out a self-consistent set of packages to work together is
something that is rather independent of any particular package, and
At 10:59 PM 4/20/2006 +0200, Martin v. Löwis wrote:
Bob Ippolito wrote:
They DO NOT compete any more than source packages do. eggs are packages
plus metadata, nothing more. What eggs do and what rpm/msi/deb does are
orthogonal. It's entirely reasonable that in the future rpm/msi/deb
At 11:26 PM 4/20/2006 +0200, Martin v. Löwis wrote:
Greg Ewing wrote:
The resources name is actually quite a common meme;
I believe it goes back to the original Macintosh, which
was the first and only computer in the world to have files
with something called a resource fork. The resource
And now for a little pushback the other way -- as of this January
TurboGears has served up 100,000 egg files (I'm not sure what the window
for all those downloads is, but it hasn't been very long). Has it
occurred to you that they know something you don't about distribution?
ElementTree would
On 4/20/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
I thought a resource
is something you can exhaust; the fork should have been
named data fork or just second fork.
Hmm... I don't think that the English word resource necessarily
implies that it can be exhausted. In US businesses, people are
Guido van Rossum wrote:
On 4/20/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
1. don't load packages out of .zip files. It's not that bad if
software on the user's disk occupies multiple files, as long as
there is a convenient way to get rid of them at once.
Many problems go away if
Phillip J. Eby wrote:
What I'm opposed to in making setuptools install things the distutils way
by default is that there is no easy path to clean upgrade or installation
in the absence of a system packaging tool like RPM or deb or
what-have-you. I am not opposed to doing the classic style
On 4/20/06, M.-A. Lemburg [EMAIL PROTECTED] wrote:
I wonder why people always seem to imply that installing
packages has never worked before there was setuptools.
There's really nothing wrong with the standard distutils
two step process:
1. download and unzip the source file
2. run python
At 11:49 PM 4/20/2006 +0100, Paul Moore wrote:
It's possible that (1) can be solved by making *all* distutils
installs create egg metadata.
This is already planned to be addressed in Python 2.5, via the
install_egg_info added to the distutils. The implementation is already in
the trunk, but
While merging the trunk changes into the p3yk branch, I discovered what I think is a bug in the stream codecs. It's easily reproduced in the trunk: in Lib/codecs.py, make the 'Codec' class new-style. Then, suddenly, test_codecs will crash with an exception like this:
I read the python 2.5alpha release notes and found that some module and
class names should not make it into the official release. For example,
the name of the ctypes module is ok because the module is only of
special interest, but calls like py_object or create_string_buffer
should definetly be
I often experiment with touring machine algorithms and play around with
alternative arithmetics. I'd like to do that with python but it offers
only the standard bitwise operators. They're fine if one wants to do
manipulations on the full integer. However, I'd like to have direct
(single) bit
Le 17 avr. 06 à 20:59, Martin v. Löwis a écrit :
OTOH, we could just as well check in an executable that
does all that, e.g. like the one in
I did something like this: I checked the source of a
kill_python.exe application which looks at all running processes
and tries to kill python_d.exe.
At 11:53 PM 4/20/2006 +0200, M.-A. Lemburg wrote:
Only after endless discussions, Phillip added some weird
--long-option-name-that-no-one-can-remember to the setuptools
install command that restores the standard distutils behavior
which should be the default anyway.
And later, I also made it the
Paul Moore wrote:
2. Distributors will supply .egg files rather than bdist_wininst
installers (this is already happening).
Really people should at least be uploading source packages in addition
to eggs; it's certainly not hard to do so.
Perhaps a distributor quick intro needs to be written
Dear Python and Mac Community,
I have just successfully built gcc version 4.1.0 for my Mac OS X 10.4.6.
gcc -v
Using built-in specs.
Target: powerpc-apple-darwin8.6.0
Configured with: /usr/local/src/gcc-4.1.0/configure
Thread model: posix
gcc version 4.1.0
When I try to build Python
Hello,
just one more datapoint to help Phillip change his mind on the default install
behavior and the monkeypatching: this is actually hurting adoption of
setuptools.
example: the matplotlib folks wanted to add *optional* setuptool support, but
this is impossible because simply importing
At 12:32 AM 4/21/2006 +0200, M.-A. Lemburg wrote:
Phillip J. Eby wrote:
What I'm opposed to in making setuptools install things the distutils way
by default is that there is no easy path to clean upgrade or installation
in the absence of a system packaging tool like RPM or deb or
On Thu, 2006-04-20 at 23:53 +0200, M.-A. Lemburg wrote:
There's really nothing wrong with the standard distutils
two step process:
1. download and unzip the source file
2. run python setup.py install
The only thing I'll add (other than put me in the just make it work and
tell me what to
Dennis Heuer [EMAIL PROTECTED] wrote:
I often experiment with touring machine algorithms and play around with
alternative arithmetics. I'd like to do that with python but it offers
only the standard bitwise operators. They're fine if one wants to do
manipulations on the full integer. However,
At 07:33 PM 4/20/2006 -0400, Barry Warsaw wrote:
The only thing I'll add (other than put me in the just make it work and
tell me what to do camp ;) is that I really want a simple way to say
do not install into the system Python, put everything over here and I
will fiddle with my environment to
On Wed, Apr 19, 2006, Dean N. Williams wrote:
When I try to build Python 2.4.3, I get the following error below:
Please do not spam multiple lists. Please read this URL before you ask
for further help:
http://www.catb.org/~esr/faqs/smart-questions.html
--
Aahz ([EMAIL PROTECTED])
On 4/21/06, Thomas Wouters [EMAIL PROTECTED] wrote:
While merging the trunk changes into the p3yk branch, I discovered what I
think is a bug in the stream codecs. It's easily reproduced in the trunk: in
Lib/codecs.py, make the 'Codec' class new-style. Then, suddenly, test_codecs
will crash
On Thu, 2006-04-20 at 19:43 -0400, Phillip J. Eby wrote:
I may be way out of date with the state of the art these days, but in
the past, I've had a difficult time making this work for Mailman. For
example, at various times we've had to distribute our own email package
and Asian codecs
At 11:08 PM 4/20/2006 -0400, Barry Warsaw wrote:
Question out of total ignorance: say I get a 3rd party package that has
a standard distutils setup.py but knows nothing of setuptools. Say I
install my own copy of setuptools (or have Python 2.5). Can that 3rd
party package still be installed the
At 01:18 AM 4/21/2006 +0200, Baptiste Carvello wrote:
So instead, they ask the setuptool users to use
python -c import setuptools; execfile('setup.py') install
That's just too bad, and much more confusing than setup.py install_egg !
Actually, the setuptools users just run easy_install matplotlib,
On Friday 21 April 2006 03:31, Fredrik Lundh wrote:
[EMAIL PROTECTED] wrote:
Maybe they know something we don't.
oh, please. it's not like people like myself and MAL don't know
anything about package distribution...
(why is it that people who *don't* distribute stuff are a lot more
im-
Patch / Bug Summary
___
Patches : 371 open (-12) / 3195 closed (+39) / 3566 total (+27)
Bugs: 908 open (+22) / 5767 closed ( +8) / 6675 total (+30)
RFE : 211 open ( +1) / 212 closed ( +0) / 423 total ( +1)
New / Reopened Patches
__
Fix
Thanks for all the great information Phillip.
On Thu, 2006-04-20 at 23:33 -0400, Phillip J. Eby wrote:
Anyway, that's a complete digression from the question you asked. As long
as Mailman doesn't depend on building something like Numeric or Twisted,
you can probably wrap it in
Dennis Heuer wrote:
Module names
like hashlib are not python-like too (too c/lowlevel-like).
I agree with Greg: hashlib is a Pythonic name for a module,
just like httplib, mhlib, xmlrpclib, cookielib, contextlib,
difflib, ...
OTOH, it might be indeed that the ctypes name need to be
aligned
99 matches
Mail list logo
