Martin v. Löwis, 02.12.2010 21:24:
Since discussion has trailed off without any blocking objections, I'm
accepting PEP 384. Martin, you may mark the PEP accepted and proceed
with merging the implementation for the beta on Saturday.
Thanks! will do (I'll also take into consideration the
I'm not really complaining (the API fixes are long overdue), just
leaving a comment that what a compiler considers a warning or error
pretty much depends on compiler, platform and configuration.
No no no. It does *not* depend on compiler, platform, or configuration.
It *only* depends on the
On Fri, 3 Dec 2010 18:11:57 -0500
James Y Knight f...@fuhm.net wrote:
On Dec 3, 2010, at 5:52 PM, Martin v. Löwis wrote:
Am 03.12.2010 23:48, schrieb Éric Araujo:
But I'm not interested at all in having it in distutils2. I want the
Python build itself to use it, and alas, I can't because
On Fri, Dec 03, 2010 at 11:52:41PM +0100, Martin v. Löwis wrote:
Am 03.12.2010 23:48, schrieb Éric Araujo:
But I'm not interested at all in having it in distutils2. I want the
Python build itself to use it, and alas, I can't because of the freeze.
You can’t in 3.2, true. Neither can you in
On Sat, Dec 4, 2010 at 12:27 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Fri, 3 Dec 2010 18:11:57 -0500
James Y Knight f...@fuhm.net wrote:
On Dec 3, 2010, at 5:52 PM, Martin v. Löwis wrote:
Am 03.12.2010 23:48, schrieb Éric Araujo:
But I'm not interested at all in having it in
Le 04/12/2010 17:55, Tarek Ziadé a écrit :
On Sat, Dec 4, 2010 at 12:27 PM, Antoine Pitrou solip...@pitrou.net wrote:
It seems like it'd be a good idea to start integrating distutils2 into
python trunk immediately after the 3.2 branch is cut, then.
+1 from me.
+1 too.
+1, and I take
At the language summit it was proposed and seemed generally accepted (maybe
I took silence as consent... it's been almost a year now) that bold new
modules (and bold rewrites of existing modules since it fell out of the
distutils/2 discussion) should get implemented in a module on pypi before
On 04/12/2010 11:27, Antoine Pitrou wrote:
On Fri, 3 Dec 2010 18:11:57 -0500
James Y Knightf...@fuhm.net wrote:
On Dec 3, 2010, at 5:52 PM, Martin v. Löwis wrote:
Am 03.12.2010 23:48, schrieb Éric Araujo:
But I'm not interested at all in having it in distutils2. I want the
Python build
Le 03/12/2010 08:31, Martin v. Löwis a écrit :
I wonder what your definition of “unmaintained” is.
In this specific case: doesn't get feature requests acted upon.
Thanks for clarifying. I think that’s a stretch, but I see your meaning
now.
Sure, distutils is not as well-maintained as other
For example, I keep running into the issue that distutils doesn't
currently support parallel builds. I have been pondering supporting
-j for building extensions, using both unbounded -j and the GNU make
style -jN build server. However, I know that the patch will be rejected,
so I don't even
But I'm not interested at all in having it in distutils2. I want the
Python build itself to use it, and alas, I can't because of the freeze.
You can’t in 3.2, true. Neither can you in 3.1, or any previous
version. If you implement it in distutils2, you have very good chances
to get it for 3.3.
Am 03.12.2010 23:48, schrieb Éric Araujo:
But I'm not interested at all in having it in distutils2. I want the
Python build itself to use it, and alas, I can't because of the freeze.
You can’t in 3.2, true. Neither can you in 3.1, or any previous
version. If you implement it in distutils2,
On Dec 3, 2010, at 5:52 PM, Martin v. Löwis wrote:
Am 03.12.2010 23:48, schrieb Éric Araujo:
But I'm not interested at all in having it in distutils2. I want the
Python build itself to use it, and alas, I can't because of the freeze.
You can’t in 3.2, true. Neither can you in 3.1, or any
On 12/3/2010 5:52 PM, Martin v. Löwis wrote:
Am 03.12.2010 23:48, schrieb Éric Araujo:
But I'm not interested at all in having it in distutils2. I want the
Python build itself to use it, and alas, I can't because of the freeze.
You can’t in 3.2, true. Neither can you in 3.1, or any previous
Am 04.12.2010 00:35, schrieb Terry Reedy:
On 12/3/2010 5:52 PM, Martin v. Löwis wrote:
Am 03.12.2010 23:48, schrieb Éric Araujo:
But I'm not interested at all in having it in distutils2. I want the
Python build itself to use it, and alas, I can't because of the freeze.
You can’t in 3.2, true.
On 12/3/2010 6:46 PM, Martin v. Löwis wrote:
and stable as D1. I do not know what Martin means by 'integrate' (other
than that he be able to use it to build Python)
That the master copy of the source code is in the Python source repository.
Is a separate branch acceptible, as long as you
Am 04.12.2010 01:00, schrieb Terry Reedy:
On 12/3/2010 6:46 PM, Martin v. Löwis wrote:
and stable as D1. I do not know what Martin means by 'integrate' (other
than that he be able to use it to build Python)
That the master copy of the source code is in the Python source
repository.
Is a
Hi,
Since discussion has trailed off without any blocking objections, I'm
accepting PEP 384. Martin, you may mark the PEP accepted and proceed
with merging the implementation for the beta on Saturday.
--
Regards,
Benjamin
___
Python-Dev mailing list
Since discussion has trailed off without any blocking objections, I'm
accepting PEP 384. Martin, you may mark the PEP accepted and proceed
with merging the implementation for the beta on Saturday.
Thanks! will do (I'll also take into consideration the proposed changes).
Regards,
Martin
On Thu, Dec 2, 2010 at 9:24 PM, Martin v. Löwis mar...@v.loewis.de wrote:
Since discussion has trailed off without any blocking objections, I'm
accepting PEP 384. Martin, you may mark the PEP accepted and proceed
with merging the implementation for the beta on Saturday.
Thanks! will do (I'll
Am 02.12.2010 21:48, schrieb Tarek Ziadé:
On Thu, Dec 2, 2010 at 9:24 PM, Martin v. Löwis mar...@v.loewis.de wrote:
Since discussion has trailed off without any blocking objections, I'm
accepting PEP 384. Martin, you may mark the PEP accepted and proceed
with merging the implementation for the
2010/12/2 Martin v. Löwis mar...@v.loewis.de:
Am 02.12.2010 21:48, schrieb Tarek Ziadé:
On Thu, Dec 2, 2010 at 9:24 PM, Martin v. Löwis mar...@v.loewis.de wrote:
Since discussion has trailed off without any blocking objections, I'm
accepting PEP 384. Martin, you may mark the PEP accepted and
So the question still stands: Why not implementing this in Distutils2 ?
Because it then wouldn't be available in Python 3.2, which is the target
release of the PEP.
If that really causes too much pain, I'll refrain from making any
changes to distutils; PEP 384 doesn't specify any changes,
2010/12/2 Martin v. Löwis mar...@v.loewis.de:
So the question still stands: Why not implementing this in Distutils2 ?
Because it then wouldn't be available in Python 3.2, which is the target
release of the PEP.
The exact feature I am mentioning is the ability to compile extensions
with new
I was told not to touch to Distutils code to avoid any regression
since it's patched to the bones in third party products. So we decided
to freeze distutils and add all new features in Distutils2, which is
at alpha stage now. So this move seems contradictory to me.
I think it was a bad
2010/12/2 Martin v. Löwis mar...@v.loewis.de:
I was told not to touch to Distutils code to avoid any regression
since it's patched to the bones in third party products. So we decided
to freeze distutils and add all new features in Distutils2, which is
at alpha stage now. So this move seems
On 02/12/2010 21:39, Martin v. Löwis wrote:
I was told not to touch to Distutils code to avoid any regression
since it's patched to the bones in third party products. So we decided
to freeze distutils and add all new features in Distutils2, which is
at alpha stage now. So this move seems
This freeze made the situation worse.
Can you extend on this and explains why it makes it worse ?
Before the freeze, distutils was unmaintained (i.e. before you started
maintaining it), but people who want to improve it gradually atleast
could. Now gradual improvements are also banned, so
Am 02.12.2010 22:54, schrieb Michael Foord:
On 02/12/2010 21:39, Martin v. Löwis wrote:
I was told not to touch to Distutils code to avoid any regression
since it's patched to the bones in third party products. So we decided
to freeze distutils and add all new features in Distutils2, which is
2010/12/2 Martin v. Löwis mar...@v.loewis.de:
Am 02.12.2010 22:54, schrieb Michael Foord:
On 02/12/2010 21:39, Martin v. Löwis wrote:
I was told not to touch to Distutils code to avoid any regression
since it's patched to the bones in third party products. So we decided
to freeze distutils
The distutils is unmaintained situation. It's not only unmaintained
now, but proposed improvements are rejected without consideration, on
the grounds that they are changes.
I welcome those changes in Distutils2. That's the whole point.
That would be useful if there was a clear vision of
2010/12/2 Martin v. Löwis mar...@v.loewis.de:
This freeze made the situation worse.
Can you extend on this and explains why it makes it worse ?
Before the freeze, distutils was unmaintained (i.e. before you started
maintaining it), but people who want to improve it gradually atleast
could.
On Thu, 02 Dec 2010 23:21:25 +0100
Martin v. Löwis mar...@v.loewis.de wrote:
Am 02.12.2010 22:54, schrieb Michael Foord:
On 02/12/2010 21:39, Martin v. Löwis wrote:
I was told not to touch to Distutils code to avoid any regression
since it's patched to the bones in third party products. So
2010/12/2 Martin v. Löwis mar...@v.loewis.de:
The distutils is unmaintained situation. It's not only unmaintained
now, but proposed improvements are rejected without consideration, on
the grounds that they are changes.
I welcome those changes in Distutils2. That's the whole point.
That
On Dec 02, 2010, at 11:21 PM, Martin v. Löwis wrote:
Well, the PEP 384 text in PEP 3149 specifies a change. It's not clear
whether this change was accepted when PEP 3149 was accepted, or whether
it was accepted when PEP 384 was accepted, or whether it was not
accepted at all, or whether it was
No, only the ones that didn't cause backwards incompatibilities,
and broke existing packages.
This is impossible. I can point you to some third party project that
can break if you touch some distutils internals, like setuptools.
Setuptools also uses some privates global variables in some
I think distutils is simply a bugfix branch for distutils2. Similarly
as how we don't commit improvements in e.g. 2.7 or 3.1, neither do we
commit improvements to distutils.
It's different, though, in the sense that Python has a release schedule
and multiple committers working on it, and that
On 02/12/2010 23:01, Martin v. Löwis wrote:
[snip...]
I'm just getting tired having to talk to
five projects just to make a single change to the build infrastructure
available to the Python community.
The very best hope of resolving that particular problem is distutils2. :-)
distutils2 is
2010/12/2 Martin v. Löwis mar...@v.loewis.de:
No, only the ones that didn't cause backwards incompatibilities,
and broke existing packages.
This is impossible. I can point you to some third party project that
can break if you touch some distutils internals, like setuptools.
Setuptools also
From my point of view, the PEP 3149 text is just a proposal. It leaves the
final decision to PEP 384, but tries to address some of the issues raised
during the PEP 3149 discussion. I think it is within PEP 384's scope to make
the final decisions about it.
Ok, then it looks like there just
An alpha is already released. A beta will be released for Pycon (I
need it for my talk :) ) Then hopefully the final before 3.2
Ok, that's promising.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
On Fri, Dec 3, 2010 at 12:01 AM, Martin v. Löwis mar...@v.loewis.de wrote:
I think distutils is simply a bugfix branch for distutils2. Similarly
as how we don't commit improvements in e.g. 2.7 or 3.1, neither do we
commit improvements to distutils.
It's different, though, in the sense that
Hi,
2010/12/3 Michael Foord fuzzy...@voidspace.org.uk
On 02/12/2010 23:01, Martin v. Löwis wrote:
[snip...]
I'm just getting tired having to talk to
five projects just to make a single change to the build infrastructure
available to the Python community.
The very best hope of resolving
On 02/12/2010 23:51, Amaury Forgeot d'Arc wrote:
Hi,
2010/12/3 Michael Foord fuzzy...@voidspace.org.uk
mailto:fuzzy...@voidspace.org.uk
On 02/12/2010 23:01, Martin v. Löwis wrote:
[snip...]
I'm just getting tired having to talk to
five projects just to make
On Dec 03, 2010, at 12:51 AM, Amaury Forgeot d'Arc wrote:
Sure. But today (before 3.2b1) we want to merge PEP3149 and PEP384;
they change the paths and filenames used by python.
Either we modify distutils to comply with the new names,
or defer these PEPs until distutils2 is ready.
I do not think
On 03.12.2010 00:25, Tarek Ziadé wrote:
2010/12/2 Martin v. Löwismar...@v.loewis.de:
No, only the ones that didn't cause backwards incompatibilities,
and broke existing packages.
This is impossible. I can point you to some third party project that
can break if you touch some distutils
even without having any changes in distutils it would make sense to know if
an
extension can be built with the restricted ABI, so maybe it is better to
defer
any changes to the extension soname, and provide a check for an extension if
it
conforms to the restricted ABI, even if the
Le 02/12/2010 23:17, Martin v. Löwis a écrit :
Before the freeze, distutils was unmaintained (i.e. before you started
maintaining it), but people who want to improve it gradually atleast
could. Now gradual improvements are also banned, so it's not only
unmaintained, but I can't even provide
Python’s setup.py has an example in Martin’s branch:
ext = Extension('xxlimited', ['xxlimited.c'],
define_macros=[('Py_LIMITED_API', 1)])
http://codereview.appspot.com/3262043/patch/1/68
This is possible with today’s distutils. I don’t know if it’s enough to
build
I wonder what your definition of “unmaintained” is.
In this specific case: doesn't get feature requests acted upon.
I'm well aware that you are fixing bugs, and that is appreciated.
Sure, distutils is not as well-maintained as other modules, but a dozen
bugs have been fixed by five or six of
50 matches
Mail list logo
