On 20-apr-2006, at 23:08, Martin v. Löwis wrote:
> 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-reada
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 wi
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 easy_insta
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 test_
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
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 matplo
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 "
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
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
> 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 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])
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
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
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
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
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
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
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
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
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
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.
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
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:
===
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
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.
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
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
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,
>>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
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
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
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-
>>
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
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
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
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
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
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
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
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
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
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
"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
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
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
[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
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
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
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
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/
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 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
>
>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
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
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
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
[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
"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
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
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
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> 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
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
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
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
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
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)
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
> 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
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
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
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
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
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
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
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 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
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
"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 "
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" == 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
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"
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
> 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, 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
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, "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
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 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 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
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
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
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'
> 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
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
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
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
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:
> 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
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
1 - 100 of 108 matches
Mail list logo
