>> 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 actual
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 r
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 mento
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 indica
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
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 b
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 th
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
sys.path/me
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 ar
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
Py
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
bein
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
migh
> 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 iss
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'
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
co
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 s
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
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
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 so
> 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. AR
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 people reading the wiki won't easily have access
to the
Guido van Rossum 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"
> "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
> mailin
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 manag
"Guido van Rossum wrote:
> > - I still fear that the code of setuptools will turn out to be
> > a maintenance nightmare.
>
> AFAICT Phillip has explicitly promised he will maintain it (or if he
> doesn't, I expect that he would gladly do so if you asked). This has
> always been sufficient as a "
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 d
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
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 l
On 4/20/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> 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
Phillip J. Eby wrote:
>> Why should a 3rd party extension be hot-fixing the standard
>> Python distribution ?
> Because setuptools installs things in zip files, and older versions of
> pydoc don't work for packages zip files.
That doesn't answer my question.
>>> That is the ans
A.M. Kuchling wrote:
> The 2.1 requirement was originally imposed because Greg Ward would
> make standalone Distutil releases. Greg is too busy working at his
> job, going camping on weekends, and being best man [1] to make new
> releases these days.
from python-announce:
From: Greg Ward
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 at least) that are missi
On Thu, Apr 20, 2006, A.M. Kuchling wrote:
>
> I don't mind rewriting much, but hate leaving the original code in
> place; this is confusing to new users, even if it's convenient for
> existing users. How many HTML parsers are in the core now? (My gut
> feeling is that that Python's adoption curv
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 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.
--
Gu
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 $n
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)
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 direct
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 anoth
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 prop
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 opin
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 o
Martin> c) ask for consent in advance to making a potentially-breaking
Martin>change.
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 an
"tomer filiba" <[EMAIL PROTECTED]> wrote:
> the evaluated string will be evaluated based on the current scope (locals
> and globals), just like
> normal expressions. the difference is, the results of the expressions will
> be str()ed into the
> evaluated string directly. these expressions will be
[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
xmlcore/etree/ElementTr
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:
>
> imp
>
>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 stay
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'
We've said "-1"i don't mean to be rude, but only josiah strictly said -1. by you saying "we",
i'd assume you -1'ed it as well, but you couldn't have expected me to know that beforeyou said it. so i feel a little cornered here... is it my fault i don't support quantom superposition?-tomer
On 4/20/
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-
> pressed by a magic tool
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 wor
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 l
[EMAIL PROTECTED] wrote:
> Martin> c) ask for consent in advance to making a potentially-breaking
> Martin>change.
>
> Doesn't that potentially extend the release time for an enhanced distutils
> across multiple Python releases?
Yes, but your alternative doesn't "scale" over time. At
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
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 plat
"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, c
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 migh
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
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. Odd
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 distribu
Guido van Rossum wrote:
> Anyway, perhaps it's a matter of choice. It's clear to me that many
> developers prefer to do it this way. You don't. This is an area that
> has enough external constraints that I'm uncomfortable telling
> developers they can't do it that way.
Hence my -0. I see the pract
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 "resour
Fredrik Lundh wrote:
> - they're currently discussing whether to use stricter version requirements
> for individual components, to increase the chance that people end up using
> a combination that someone else has actually tested.
I don't think setuptools version requirements are enough to ensure
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 "zer
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
Ian Bicking wrote:
> 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-
>>
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
>>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?
>>ElementT
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,
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
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" s
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.
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 n
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 cha
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 access
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
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
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 f
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 2.4.
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 setu
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
> > w
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
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. How
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
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])
> Module names like hashlib are not python-like too (too c/lowlevel-like).
what is python-like?
hashlib was chosen because it is a library of hash functions and
hash() is already taken as a builtin function (otherwise i'd leave off
the lib).
-g
___
Pyt
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 cras
1 - 100 of 108 matches
Mail list logo