Re: [Python-Dev] PEP 384 accepted

On Sat, Dec 4, 2010 at 8:43 PM, "Martin v. Löwis" wrote: ... > Now, distutils2 is different: it's *not* new functionality. So perhaps > yes: I disagree with the principle that bold rewrites should be > developed independently. Such work would be much better carried out in a > branch - it will neve

Re: [Python-Dev] PEP 384 accepted

On 04/12/2010 11:27, Antoine Pitrou wrote: On Fri, 3 Dec 2010 18:11:57 -0500 James Y Knight 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,

Re: [Python-Dev] PEP 384 accepted

> 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 befo

Re: [Python-Dev] PEP 384 accepted

Le 04/12/2010 17:55, Tarek Ziadé a écrit : > On Sat, Dec 4, 2010 at 12:27 PM, Antoine Pitrou 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 responsibil

Re: [Python-Dev] PEP 384 accepted

On Sat, Dec 4, 2010 at 12:27 PM, Antoine Pitrou wrote: > On Fri, 3 Dec 2010 18:11:57 -0500 > James Y Knight 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

Re: [Python-Dev] PEP 384 accepted

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

Re: [Python-Dev] PEP 384 accepted

On Fri, 3 Dec 2010 18:11:57 -0500 James Y Knight 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 o

Re: [Python-Dev] PEP 384 accepted

> 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

Re: [Python-Dev] PEP 384 accepted

"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 propos

Re: [Python-Dev] PEP 384 accepted

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 >> repo

Re: [Python-Dev] PEP 384 accepted

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 c

Re: [Python-Dev] PEP 384 accepted

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’

Re: [Python-Dev] PEP 384 accepted

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

Re: [Python-Dev] PEP 384 accepted

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

Re: [Python-Dev] PEP 384 accepted

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 distutil

Re: [Python-Dev] PEP 384 accepted

> 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

Re: [Python-Dev] PEP 384 accepted

>> 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

Re: [Python-Dev] PEP 384 accepted

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 oth

Re: [Python-Dev] PEP 384 accepted

> 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 o

Re: [Python-Dev] PEP 384 accepted

> Python’s setup.py has an example in Martin’s branch: > > ext = Extension('xxlimited', ['xxlimited.c'], > define_macros=[('Py_LIMITED_API', 1)]) > > > > This is possible with today’s distutils. I don’t know if it’s enough t

Re: [Python-Dev] PEP 384 accepted

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

Re: [Python-Dev] PEP 384 accepted

> 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 t

Re: [Python-Dev] PEP 384 accepted

On 03.12.2010 00:25, Tarek Ziadé wrote: 2010/12/2 "Martin v. Löwis": 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 setuptoo

Re: [Python-Dev] PEP 384 accepted

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 th

Re: [Python-Dev] PEP 384 accepted

On 02/12/2010 23:51, Amaury Forgeot d'Arc wrote: Hi, 2010/12/3 Michael Foord > 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

Re: [Python-Dev] PEP 384 accepted

Hi, 2010/12/3 Michael Foord > 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

Re: [Python-Dev] PEP 384 accepted

On Fri, Dec 3, 2010 at 12:01 AM, "Martin v. Löwis" 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 Python has

Re: [Python-Dev] PEP 384 accepted

> 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 http://mail.python.org/mailman/

Re: [Python-Dev] PEP 384 accepted

> 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 jus

Re: [Python-Dev] PEP 384 accepted

2010/12/2 "Martin v. Löwis" : >>> 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

Re: [Python-Dev] PEP 384 accepted

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

Re: [Python-Dev] PEP 384 accepted

> 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 tha

Re: [Python-Dev] PEP 384 accepted

>> 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

Re: [Python-Dev] PEP 384 accepted

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

Re: [Python-Dev] PEP 384 accepted

2010/12/2 "Martin v. Löwis" : >>> 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 woul

Re: [Python-Dev] PEP 384 accepted

On Thu, 02 Dec 2010 23:21:25 +0100 "Martin v. Löwis" 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 we d

Re: [Python-Dev] PEP 384 accepted

2010/12/2 "Martin v. Löwis" : >>> 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 gr

Re: [Python-Dev] PEP 384 accepted

>> 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 visi

Re: [Python-Dev] PEP 384 accepted

2010/12/2 "Martin v. Löwis" : > 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 an

Re: [Python-Dev] PEP 384 accepted

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

Re: [Python-Dev] PEP 384 accepted

>> 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

Re: [Python-Dev] PEP 384 accepted

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 contr

Re: [Python-Dev] PEP 384 accepted

2010/12/2 "Martin v. Löwis" : >> 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 contradicto

Re: [Python-Dev] PEP 384 accepted

> 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 de

Re: [Python-Dev] PEP 384 accepted

2010/12/2 "Martin v. Löwis" : > >> 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 options, s

Re: [Python-Dev] PEP 384 accepted

> 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, an

Re: [Python-Dev] PEP 384 accepted

2010/12/2 "Martin v. Löwis" : > Am 02.12.2010 21:48, schrieb Tarek Ziadé: >> On Thu, Dec 2, 2010 at 9:24 PM, "Martin v. Löwis" 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 mergi

Re: [Python-Dev] PEP 384 accepted

Am 02.12.2010 21:48, schrieb Tarek Ziadé: > On Thu, Dec 2, 2010 at 9:24 PM, "Martin v. Löwis" 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 o

Re: [Python-Dev] PEP 384 accepted

On Thu, Dec 2, 2010 at 9:24 PM, "Martin v. Löwis" 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 also take

Re: [Python-Dev] PEP 384 accepted

> 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

[Python-Dev] PEP 384 accepted

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 Pyt