Re: [Python-Dev] PEP 384 (stable api) question

Am 07.11.2013 19:35, schrieb "Martin v. Löwis": Am 07.11.13 13:44, schrieb Thomas Heller: I thought that the stable API would keep exactly the same across releases - is this expectation wrong or is this a bug? Oscar is right - this change doesn't affect the ABI, just the API. That said, plea

Re: [Python-Dev] PEP 384 (stable api) question

On 8 Nov 2013 04:42, Martin v. Löwis wrote: > > Am 07.11.13 13:44, schrieb Thomas Heller: > > > I thought that the stable API would keep exactly the same across > > releases - is this expectation wrong or is this a bug? > > Oscar is right - this change doesn't affect the ABI, just the API. > > Tha

Re: [Python-Dev] PEP 384 (stable api) question

Am 07.11.13 13:44, schrieb Thomas Heller: > I thought that the stable API would keep exactly the same across > releases - is this expectation wrong or is this a bug? Oscar is right - this change doesn't affect the ABI, just the API. That said, please file an issue reporting what change you see i

Re: [Python-Dev] PEP 384 (stable api) question

On 7 November 2013 12:44, Thomas Heller wrote: > PEP 384 describes the stable Python api, available when > Py_LIMITED_API is defined. > > However, there are some (small) changes in the function prototypes > available, one example is (in Python 3.3): > PyObject* PyObject_CallFunction(PyObject *cal

[Python-Dev] PEP 384 (stable api) question

PEP 384 describes the stable Python api, available when Py_LIMITED_API is defined. However, there are some (small) changes in the function prototypes available, one example is (in Python 3.3): PyObject* PyObject_CallFunction(PyObject *callable, char *format, ...) which changed in Python 3.4 to

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

Re: [Python-Dev] PEP 384 final review

On Tue, Nov 30, 2010 at 12:15 AM, James Y Knight wrote: > > On Nov 29, 2010, at 8:58 AM, Nick Coghlan wrote: > > The http read only URLs > didn't work (no diff returned, just "svn: OPTIONS of > 'http://svn.python.org/python/branches/pep-0384': 200 OK > (http://svn.python.org)"), > > That was the w

Re: [Python-Dev] PEP 384 final review

Am 29.11.2010 09:36, schrieb Georg Brandl: > Am 29.11.2010 09:09, schrieb "Martin v. Löwis": >>> I have now completed >>> >>> http://www.python.org/dev/peps/pep-0384/ >>> >>> >>> was structseq.h considered? >> >> No, it wasn't - unfortunately, it still doesn't get included when >> including

Re: [Python-Dev] PEP 384 final review

Am 29.11.2010 14:14, schrieb Éric Araujo: > Hello, > >> Please comment with any changes you want to see, or speak in >> favor or against this PEP. > > How to get a diff between py3k and this branch? As others have already explained: svn diff http://svn.python.org/projects/python/branches/p...@8

Re: [Python-Dev] PEP 384 final review

> This is probably an issue independent of the PEP but there appear to > be a *lot* of exposed typedefs for various type slots and other > function signatures that don't start with the Py prefix (i.e. getter, > setter, unaryfunc and friends). It's indeed independent: the names don't actually affec

Re: [Python-Dev] PEP 384 final review

> Extensions built with Py_LIMITED_API have the python version encoded in > it's name. Which abi name should be used for these extensions? PEP 3149, IIUC, says it should be "abi3". I don't understand what that means, though (with respect to, say, distutils) > - The m and u modifiers in the abi

Re: [Python-Dev] PEP 384 final review

2010/11/29 "Martin v. Löwis" : >>>  - Should the distutils support for LIMITED_API be part of the pep, or >>>   be implemented later? >> >> In any case, it has to be implemented in Distutils2, not in Distutils. >> Distutils is frozen and just in maintenance mode. > > I think it's too late for that.

Re: [Python-Dev] PEP 384 final review

>> - Should the distutils support for LIMITED_API be part of the pep, or >> be implemented later? > > In any case, it has to be implemented in Distutils2, not in Distutils. > Distutils is frozen and just in maintenance mode. I think it's too late for that. PEP 3149 is accepted, and it does spe

Re: [Python-Dev] PEP 384 final review

On Mon, Nov 29, 2010 at 11:24 AM, Matthias Klose wrote: > On 29.11.2010 00:40, "Martin v. Löwis" wrote: >> >> I have now completed >> >> http://www.python.org/dev/peps/pep-0384/ >> >> Benjamin has volunteered to rule on this PEP. >> >> Please comment with any changes you want to see, or speak in >

Re: [Python-Dev] PEP 384 final review

On Nov 29, 2010, at 8:58 AM, Nick Coghlan wrote: > The http read only URLs > didn't work (no diff returned, just "svn: OPTIONS of > 'http://svn.python.org/python/branches/pep-0384': 200 OK > (http://svn.python.org)"), That was the wrong url: you should've used http://svn.python.org/projects/py

Re: [Python-Dev] PEP 384 final review

On Mon, Nov 29, 2010 at 9:40 AM, "Martin v. Löwis" wrote: > I have now completed > > http://www.python.org/dev/peps/pep-0384/ > > Benjamin has volunteered to rule on this PEP. > > Please comment with any changes you want to see, or speak in > favor or against this PEP. This is probably an issue i

Re: [Python-Dev] PEP 384 final review

On Mon, Nov 29, 2010 at 11:37 PM, Matthias Klose wrote: > On 29.11.2010 14:14, Éric Araujo wrote: >> >> Hello, >> >>> Please comment with any changes you want to see, or speak in >>> favor or against this PEP. >> >> How to get a diff between py3k and this branch? > > I used > svn diff svn://svn.py

Re: [Python-Dev] PEP 384 final review

On 29.11.2010 14:14, Éric Araujo wrote: Hello, Please comment with any changes you want to see, or speak in favor or against this PEP. How to get a diff between py3k and this branch? I used svn diff svn://svn.python.org/python/branches/p...@84330 svn://svn.python.org/python/branches/pep-03

Re: [Python-Dev] PEP 384 final review

Hello, > Please comment with any changes you want to see, or speak in > favor or against this PEP. How to get a diff between py3k and this branch? Regards ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python

Re: [Python-Dev] PEP 384 final review

On 29.11.2010 00:40, "Martin v. Löwis" wrote: I have now completed http://www.python.org/dev/peps/pep-0384/ Benjamin has volunteered to rule on this PEP. Please comment with any changes you want to see, or speak in favor or against this PEP. I looked at a diff with r84330 from the py3k branc

Re: [Python-Dev] PEP 384 final review

Am 29.11.2010 09:09, schrieb "Martin v. Löwis": >> I have now completed >> >> http://www.python.org/dev/peps/pep-0384/ >> >> >> was structseq.h considered? > > No, it wasn't - unfortunately, it still doesn't get included when > including Python.h. I'll add it. Would 3.2 be a good time

Re: [Python-Dev] PEP 384 final review

> I have now completed > > http://www.python.org/dev/peps/pep-0384/ > > > was structseq.h considered? No, it wasn't - unfortunately, it still doesn't get included when including Python.h. I'll add it. > IMO it could be made PEP384-compliant with two additions that would > replace two n

Re: [Python-Dev] PEP 384 final review

2010/11/29 "Martin v. Löwis" > I have now completed > > http://www.python.org/dev/peps/pep-0384/ was structseq.h considered? IMO it could be made PEP384-compliant with two additions that would replace two non-compliant functions: - A new function to create types, since PyStructSequence_InitTyp

Re: [Python-Dev] PEP 384 final review

On 11/28/2010 6:40 PM, "Martin v. Löwis" wrote: I have now completed http://www.python.org/dev/peps/pep-0384/ The current text contains several error messages like: "System Message: WARNING/2 (pep-0384.txt, line 194) Bullet list ends without a blank line; unexpected unindent." Terry Jan Reed

[Python-Dev] PEP 384 final review

I have now completed http://www.python.org/dev/peps/pep-0384/ Benjamin has volunteered to rule on this PEP. Please comment with any changes you want to see, or speak in favor or against this PEP. Regards, Martin ___ Python-Dev mailing list Python-Dev@

Re: [Python-Dev] PEP 384 status

> That said, looking at the PEP, I was wondering whether fields such as > ob_type, ob_refcnt, ob_size have to be directly accessible, rather than > through a macro-turned-into-a-function such as Py_REFCNT(). That they are macros still is primarily for performance reasons. For ob_type, that may be

Re: [Python-Dev] PEP 384 status

On Sun, 12 Sep 2010 19:38:33 +0200 "Martin v. Löwis" wrote: > > On http://bugs.python.org/issue9778 you elaborated on what the PEP would > > entail in its current state: > > > > “No, vice versa. The PEP promises that the ABI won't change until > > Python 4. For any change that might break the ABI

Re: [Python-Dev] PEP 384 status

> On http://bugs.python.org/issue9778 you elaborated on what the PEP would > entail in its current state: > > “No, vice versa. The PEP promises that the ABI won't change until > Python 4. For any change that might break the ABI, either a > backwards-compatible solution needs to be found, or the ch

Re: [Python-Dev] PEP 384 status

Am 07.09.2010 19:48, schrieb M.-A. Lemburg: > "Martin v. Löwis" wrote: >> >>> This sounds like the issues such a mix can cause are mostly >>> theoretical and don't really bother much in practice, so >>> PEP 384 on Windows does have a chance :-) >> >> Actually, the CRT issues (FILE* in particular) h

Re: [Python-Dev] PEP 384 status

On Wed, Sep 8, 2010 at 7:59 PM, Nick Coghlan wrote: > On Wed, Sep 8, 2010 at 6:34 PM, David Cournapeau wrote: >> In other words, the problem mainly arises when you need to integrate >> libraries which you can not recompile with the compiler used by >> python, because the code is not visual-studio

Re: [Python-Dev] PEP 384 status

On Wed, Sep 8, 2010 at 6:34 PM, David Cournapeau wrote: > In other words, the problem mainly arises when you need to integrate > libraries which you can not recompile with the compiler used by > python, because the code is not visual-studio compatible, or because > the library is only available in

Re: [Python-Dev] PEP 384 status

On Wed, Sep 8, 2010 at 5:19 PM, Nick Coghlan wrote: > On Wed, Sep 8, 2010 at 8:34 AM, David Cournapeau wrote: >> I would turn the question around: what are the cases where you manage >> to mix CRT and not getting any issues ? This has never worked in my >> own experience in the context of python

Re: [Python-Dev] PEP 384 status

On Wed, Sep 8, 2010 at 8:34 AM, David Cournapeau wrote: > I would turn the question around: what are the cases where you manage > to mix CRT and not getting any issues ? This has never worked in my > own experience in the context of python extensions, I've done it quite a bit over the years with

Re: [Python-Dev] PEP 384 status

On Wed, Sep 8, 2010 at 2:48 AM, M.-A. Lemburg wrote: > "Martin v. Löwis" wrote: >> >>> This sounds like the issues such a mix can cause are mostly >>> theoretical and don't really bother much in practice, so >>> PEP 384 on Windows does have a chance :-) >> >> Actually, the CRT issues (FILE* in par

Re: [Python-Dev] PEP 384 status

"Martin v. Löwis" wrote: > >> This sounds like the issues such a mix can cause are mostly >> theoretical and don't really bother much in practice, so >> PEP 384 on Windows does have a chance :-) > > Actually, the CRT issues (FILE* in particular) have been > causing real crashes for many years, fo

Re: [Python-Dev] PEP 384 status

Hello Martin, On Sat, 28 Aug 2010 12:04:10 +0200 "Martin v. Löwis" wrote: > I have now started an initial patch for PEP 384, in the pep-0384 branch. [...] On http://bugs.python.org/issue9778 you elaborated on what the PEP would entail in its current state: “No, vice versa. The PEP promises tha

Re: [Python-Dev] PEP 384 status

On Sat, 04 Sep 2010 15:13:55 +0200 "Martin v. Löwis" wrote: > > Please consider this: even without relying on PEP 384, using FILE* > > is /already/ dangerous; because you might compile an extension with a > > different compiler version than Python was compiled with. > > It's only dangerous *if*

Re: [Python-Dev] PEP 384 status

> Please consider this: even without relying on PEP 384, using FILE* > is /already/ dangerous; because you might compile an extension with a > different compiler version than Python was compiled with. It's only dangerous *if* you compile with a different compiler. That's why we take serious precau

Re: [Python-Dev] PEP 384 status

> What I think would be a mistake would be to define the API in terms of > Windows-specific quirks. All this discussion seems bent on satisfying > the needs of Windows developers at the expense of non-Windows > developers. "FILE*" is a perfectly standard C feature (and a > widely-used one at that).

Re: [Python-Dev] PEP 384 status

> This sounds like the issues such a mix can cause are mostly > theoretical and don't really bother much in practice, so > PEP 384 on Windows does have a chance :-) Actually, the CRT issues (FILE* in particular) have been causing real crashes for many years, for many people. Regards, Martin

Re: [Python-Dev] PEP 384 status

> It would be interesting to know how, in practice, these FILE pointers > come to life. In my experience they are generally obtained via fopen. I think that experience can't be generalized. I personally guess that in most cases, the FILE* being passed across CRT boundaries is stdout. > If that i

Re: [Python-Dev] PEP 384 status

On Fri, Sep 3, 2010 at 12:44 PM, Greg Ewing wrote: > On 02/09/10 09:04, Nick Coghlan wrote: > >> I think it would be better if everything dealing with FILE* was a >> macro rather than a function, yes. > > How would that help? Macros (and, as Antoine pointed out, inline functions) will never cross

Re: [Python-Dev] PEP 384 status

On 02/09/10 09:04, Nick Coghlan wrote: I think it would be better if everything dealing with FILE* was a macro rather than a function, yes. How would that help? -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman

Re: [Python-Dev] PEP 384 status

On Wed, Sep 1, 2010 at 10:54 PM, Antoine Pitrou wrote: > Please consider this: even without relying on PEP 384, using FILE* > is /already/ dangerous; because you might compile an extension with a > different compiler version than Python was compiled with. So, if we were > following you, we should

Re: [Python-Dev] PEP 384 status

On Thu, Sep 2, 2010 at 7:19 AM, Antoine Pitrou wrote: > Maybe I've missed your answer, but what would prevent the "inline" > solution from working? Only PEP 7 (since standard support for inline is a C99 feature) On the other hand, if gcc (including cygwin/mingw) and MSVC support it (even with no

Re: [Python-Dev] PEP 384 status

On Thu, 2 Sep 2010 07:04:31 +1000 Nick Coghlan wrote: > On Wed, Sep 1, 2010 at 10:54 PM, Antoine Pitrou wrote: > > Please consider this: even without relying on PEP 384, using FILE* > > is /already/ dangerous; because you might compile an extension with a > > different compiler version than Pyth

Re: [Python-Dev] PEP 384 status

On Wed, Sep 1, 2010 at 10:54 PM, Antoine Pitrou wrote: > Please consider this: even without relying on PEP 384, using FILE* > is /already/ dangerous; because you might compile an extension with a > different compiler version than Python was compiled with. So, if we were > following you, we should

Re: [Python-Dev] PEP 384 status

On 01/09/2010 13:54, Antoine Pitrou wrote: [snip...] Please consider this: even without relying on PEP 384, using FILE* is /already/ dangerous; because you might compile an extension with a different compiler version than Python was compiled with. So, if we were following you, we should rip out

Re: [Python-Dev] PEP 384 status

Le mercredi 01 septembre 2010 à 22:43 +1000, Nick Coghlan a écrit : > On Wed, Sep 1, 2010 at 8:42 AM, Antoine Pitrou wrote: > > After all, we don't usually try to workaround platform-specific > > bugs (not as a low level such as the C API level); at worse, we mention > > their existence in the doc

Re: [Python-Dev] PEP 384 status

On Wed, Sep 1, 2010 at 8:42 AM, Antoine Pitrou wrote: > After all, we don't usually try to workaround platform-specific > bugs (not as a low level such as the C API level); at worse, we mention > their existence in the docs. You persist in viewing the allowance of multiple C runtimes in a single

  1   2   >