Re: [Python-checkins] python/dist/src/Modules threadmodule.c, 2.56, 2.56.8.1
On Wed, 01 Sep 2004 15:31:26 -0700, mhammond@users.sourceforge.net <mhammond@users.sourceforge.net> wrote:
Update of /cvsroot/python/python/dist/src/Modules In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv22421/Modules
Modified Files: Tag: release23-maint threadmodule.c Log Message: Backport [ 1010677 ] thread Module Breaks PyGILState_Ensure() to the 2.3 maint branch.
As long as we're backporting C APIs to 2.3, can I request that the new datetime API be backported to 2.3? Anthony Tuininga (the cx_Oracle author) would be interested in using this and might be willing to help out with the work. (And yes, I'm encouraging this because I could use this myself.) -- --Guido van Rossum (home page: http://www.python.org/~guido/) Ask me about gmail.
Guido van Rossum wrote:
As long as we're backporting C APIs to 2.3, can I request that the new datetime API be backported to 2.3? Anthony Tuininga (the cx_Oracle author) would be interested in using this and might be willing to help out with the work. (And yes, I'm encouraging this because I could use this myself.)
Erm - this particular fix was a bug fix. I'm deeply uncomfortable about adding the C version of datetime to 2.3 at this very late stage of 2.3's life cycle. -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
[Anthony Baxter]
Erm - this particular fix was a bug fix. I'm deeply uncomfortable about adding the C version of datetime to 2.3 at this very late stage of 2.3's life cycle.
It's quite arguably a bugfix, since datetime.h in 2.3.4 exposes things that can't possibly be used outside of datetimemodule.c (the datetime type objects are referenced in the header, but not exported in a usable way). Anthony Tuininga's patch to *finish* (not really add) the datetime C API is a low-risk change regardless: it doesn't change any existing functionality, it just finishes the job of exposing it to C coders, and adds some new macros for convenience. Now if some platform header file has macros with names like PyDateTime_FromTimestamp or PyDelta_FromDSU then adding these macros to datetime.h could cause new problems. But platform header files don't have macros with names like those (if they did, we would have bumped into it while developing 2.4).
It's quite arguably a bugfix, since datetime.h in 2.3.4 exposes things that can't possibly be used outside of datetimemodule.c (the datetime type objects are referenced in the header, but not exported in a usable way). Anthony Tuininga's patch to *finish* (not really add) the datetime C API is a low-risk change regardless: it doesn't change any existing functionality, it just finishes the job of exposing it to C coders, and adds some new macros for convenience.
Now if some platform header file has macros with names like
PyDateTime_FromTimestamp or PyDelta_FromDSU
then adding these macros to datetime.h could cause new problems. But platform header files don't have macros with names like those (if they did, we would have bumped into it while developing 2.4).
Hm, Anthony, what do you think now? (Disregard my previous mail, I was confused by multiple logical threads mixed into the same conversation.) --Guido
Well, I find the argument convincing enough and it is quite safe. I am willing to make the necessary patches and it would be quite convenient to be able to use the C API in Python 2.3 as well. So I'm in favor but I'll bow to the greater wisdom of the Python development community since I really am not significantly involved. :-) Guido van Rossum wrote:
It's quite arguably a bugfix, since datetime.h in 2.3.4 exposes things that can't possibly be used outside of datetimemodule.c (the datetime type objects are referenced in the header, but not exported in a usable way). Anthony Tuininga's patch to *finish* (not really add) the datetime C API is a low-risk change regardless: it doesn't change any existing functionality, it just finishes the job of exposing it to C coders, and adds some new macros for convenience.
Now if some platform header file has macros with names like
PyDateTime_FromTimestamp or PyDelta_FromDSU
then adding these macros to datetime.h could cause new problems. But platform header files don't have macros with names like those (if they did, we would have bumped into it while developing 2.4).
Hm, Anthony, what do you think now? (Disregard my previous mail, I was confused by multiple logical threads mixed into the same conversation.)
--Guido
-- Anthony Tuininga anthony@computronix.com Computronix Distinctive Software. Real People. Suite 200, 10216 - 124 Street NW Edmonton, AB, Canada T5N 4A3 Phone: (780) 454-3700 Fax: (780) 454-3838 http://www.computronix.com
Guido van Rossum wrote:
Now if some platform header file has macros with names like
PyDateTime_FromTimestamp or PyDelta_FromDSU
then adding these macros to datetime.h could cause new problems. But platform header files don't have macros with names like those (if they did, we would have bumped into it while developing 2.4).
Hm, Anthony, what do you think now?
I'm not Anthony (neither, actually), but I do think this is a new feature, not a bug fix - assuming we are talking about the changes between datetime.h in 2.3 and 2.4. This introduces datetime.datetime_CAPI, which is a C object allowing cross-module datetime calls at the C level. This change is very unlikely to break existing code, as existing code just won't use that new API. This is good for a backport. At the same time, this also clearly shows it is a new feature: only new code can use it. Channelling Anthony (Baxter), this cannot be accepted for 2.3. It would allow for code that works on 2.3.5, but fails on 2.3.4. What's worse, the extension module can be built on 2.3.5, and the binary module will fail when run on 2.3.4, as importing the CAPI object would fail. People who rely on that feature should get a compile time error on 2.3.x, instead of compilation succeeding for some x. People who need to support 2.3 as well should use the Python API to the datetime module, not the C API. Regards, Martin
I won't presume to dictate policy on this matter but since this is C API you do have to go through some effort in order to use it. I already have the following in cx_Oracle #if (PY_VERSION_HEX >= 0x02040000) ....do stuff.... #endif I am assuming that I could (if this patch is accepted) simply change it to #if (PY_VERSION_HEX >= 0x02030500) ....do stuff.... #endif Whether or not this makes it acceptable or not I leave that to the release manager to decide.... Martin v. Löwis wrote:
Guido van Rossum wrote:
Now if some platform header file has macros with names like
PyDateTime_FromTimestamp or PyDelta_FromDSU
then adding these macros to datetime.h could cause new problems. But platform header files don't have macros with names like those (if they did, we would have bumped into it while developing 2.4).
Hm, Anthony, what do you think now?
I'm not Anthony (neither, actually), but I do think this is a new feature, not a bug fix - assuming we are talking about the changes between datetime.h in 2.3 and 2.4.
This introduces datetime.datetime_CAPI, which is a C object allowing cross-module datetime calls at the C level.
This change is very unlikely to break existing code, as existing code just won't use that new API. This is good for a backport.
At the same time, this also clearly shows it is a new feature: only new code can use it.
Channelling Anthony (Baxter), this cannot be accepted for 2.3. It would allow for code that works on 2.3.5, but fails on 2.3.4. What's worse, the extension module can be built on 2.3.5, and the binary module will fail when run on 2.3.4, as importing the CAPI object would fail.
People who rely on that feature should get a compile time error on 2.3.x, instead of compilation succeeding for some x. People who need to support 2.3 as well should use the Python API to the datetime module, not the C API.
Regards, Martin
-- Anthony Tuininga anthony@computronix.com Computronix Distinctive Software. Real People. Suite 200, 10216 - 124 Street NW Edmonton, AB, Canada T5N 4A3 Phone: (780) 454-3700 Fax: (780) 454-3838 http://www.computronix.com
Anthony Tuininga wrote: [snip]
Whether or not this makes it acceptable or not I leave that to the release manager to decide....
I can understand why it would be convenient for this to be in 2.3.5, but I really don't want to see this in the release23-maint branch. The advantages (it allows cx_oracle to be faster) are nowhere near strong enough to outweigh the disadvantages (breaking binary compatibility between bugfix releases). From the feedback I've received since I started the current run of bugfix releases, one of the strongest messages I've received is that people _really_ _really_ like the no-new-features rule, because it makes it much easier to justify rolling out a bugfix release. I'm not saying that this rule must never be broken, only that it would need an extremely good reason to do so. This case is even worse, as it is both a new feature _and_ a binary imcompatibility. If you wanted to, you could produce a package with a patched datetime module, and instructions for allowing users to install it into their existing installation. This is entirely up to them, then. Anthony -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
Martin v. Löwis wrote:
Channelling Anthony (Baxter), this cannot be accepted for 2.3. It would allow for code that works on 2.3.5, but fails on 2.3.4. What's worse, the extension module can be built on 2.3.5, and the binary module will fail when run on 2.3.4, as importing the CAPI object would fail.
Ugh. Thanks for the clarification. I really don't think that this is something we want to add to 2.3.5.
People who rely on that feature should get a compile time error on 2.3.x, instead of compilation succeeding for some x. People who need to support 2.3 as well should use the Python API to the datetime module, not the C API.
Given that it's a CObject, code could easily be written (and I'm sure cx_Oracle will do this) that attempts to import the CObject and uses a fallback if that fails. I expect that cx_Oracle will be just about the only customer of this API. -- --Guido van Rossum (home page: http://www.python.org/~guido/) Ask me about gmail.
Guido van Rossum wrote:
Given that it's a CObject, code could easily be written (and I'm sure cx_Oracle will do this) that attempts to import the CObject and uses a fallback if that fails. I expect that cx_Oracle will be just about the only customer of this API.
If there is a fallback already, why do you want the backport? Just use the fallback. Regards, Martin
If there is a fallback already, why do you want the backport? Just use the fallback.
Because the fallback is slower? -- --Guido van Rossum (home page: http://www.python.org/~guido/) Ask me about gmail.
Guido van Rossum wrote:
If there is a fallback already, why do you want the backport? Just use the fallback.
Because the fallback is slower?
This, to me, is a poor reason to break the backwards/forwards compatibility of binary modules. Yes, modules _could_ be written to do the right thing, and cx_Oracle might. But then someone else comes along and uses it, and notices that it works on 2.3.5, so makes a 2.3 binary package. And people on older 2.3's get a broken package. I'm really really unconvinced that this is a good idea. Anthony
"Anthony" == Anthony Baxter <anthony@interlink.com.au> writes:
>> Because the fallback is slower? Anthony> This, to me, is a poor reason to break the backwards/forwards Anthony> compatibility of binary modules. +100 At my new job we maintain "stable" and "unstable" versions (*) of our current project. I frequently hold up Python's policy of "only bug fixes are allowed in stable versions" as a shining example of how things should be done. We've violated that policy on occasion. When that happens it generally comes back to bite us, and we only have three users down the hall, not users scattered all over the planet. Skip (*) I use those terms *very* loosely.
OK, I withdraw my request. Never mind. :-) --Guido
Guido van Rossum wrote:
If there is a fallback already, why do you want the backport? Just use the fallback.
Because the fallback is slower?
I see. However, people with existing installation will have to suffer from the slow-down, anyway; people will need to upgrade in order to see the speed improvement. If they need the speed advantage (which is exactly how much?), they should consider upgrading to 2.4. That an extension module runs slower in 2.3 than it does in 2.3 is not a bug in 2.3 - a lot of things run slower in 2.3, yet we don't backport all performance changes to 2.3, especially if code has to be adopted to make use of it. Regards, Martin
On Thu, 02 Sep 2004 19:36:43 +0200, "Martin v. Löwis" <martin@v.loewis.de> wrote:
I'm not Anthony (neither, actually), but I do think this is a new feature, not a bug fix - assuming we are talking about the changes between datetime.h in 2.3 and 2.4.
This introduces datetime.datetime_CAPI, which is a C object allowing cross-module datetime calls at the C level.
This change is very unlikely to break existing code, as existing code just won't use that new API. This is good for a backport.
At the same time, this also clearly shows it is a new feature: only new code can use it.
Of late, I've found the True / False introduction in later 2.2 releases to be a pain. I'm writing code on a machine that has 2.2.2, but I occasionally run into machines with earlier versions of 2.2 and then my code fails. It would be easier if it didn't work on any 2.2 release, then I wouldn't be lulled into thinking it will work. Jeremy
On Thu, Sep 02, 2004, Jeremy Hylton wrote:
Of late, I've found the True / False introduction in later 2.2 releases to be a pain. I'm writing code on a machine that has 2.2.2, but I occasionally run into machines with earlier versions of 2.2 and then my code fails. It would be easier if it didn't work on any 2.2 release, then I wouldn't be lulled into thinking it will work.
+1 -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "To me vi is Zen. To use vi is to practice zen. Every command is a koan. Profound to the user, unintelligible to the uninitiated. You discover truth everytime you use it." --reddy@lion.austin.ibm.com
On Thu, 2004-09-02 at 14:26, Jeremy Hylton wrote:
Of late, I've found the True / False introduction in later 2.2 releases to be a pain. I'm writing code on a machine that has 2.2.2, but I occasionally run into machines with earlier versions of 2.2 and then my code fails. It would be easier if it didn't work on any 2.2 release, then I wouldn't be lulled into thinking it will work.
Just to add: while this can be worked around in code, it's extremely tedious both to add those workarounds, and to remove them when they're no longer necessary. I think it's generally not a good idea to do it. -Barry
[Martin v. Löwis]
... Channelling Anthony (Baxter), this cannot be accepted for 2.3. It would allow for code that works on 2.3.5, but fails on 2.3.4. What's worse, the extension module can be built on 2.3.5, and the binary module will fail when run on 2.3.4, as importing the CAPI object would fail.
That is a strong argument, and you're right that "the rules" don't allow it. OTOH, unlike Jeremy's True/False example, this is an obscure piece of C with only one known user in the world (Anthony wrote the datetime C API patch, and Anthony wrote the Oracle wrapper which is the datetime C API's only known user). So an opposing "practicality beats purity" argument *could* apply too. I'm not going to make it myself, because I personally have no use for the C datetime API <wink>.
Tim Peters wrote:
[Anthony Baxter]
Erm - this particular fix was a bug fix. I'm deeply uncomfortable about adding the C version of datetime to 2.3 at this very late stage of 2.3's life cycle.
It's quite arguably a bugfix, since datetime.h in 2.3.4 exposes things that can't possibly be used outside of datetimemodule.c
Ah - I misunderstood, and thought that 2.3 had no version of datetime.c at all, and Guido was proposing that we add it. So, to get this straight, what _are_ we talking about, exactly? Is there an SF bug/patch with the trunk change? -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
Anthony (the other one), can you explain it? On Fri, 03 Sep 2004 02:26:12 +1000, Anthony Baxter <anthony@interlink.com.au> wrote:
Tim Peters wrote:
[Anthony Baxter]
Erm - this particular fix was a bug fix. I'm deeply uncomfortable about adding the C version of datetime to 2.3 at this very late stage of 2.3's life cycle.
It's quite arguably a bugfix, since datetime.h in 2.3.4 exposes things that can't possibly be used outside of datetimemodule.c
Ah - I misunderstood, and thought that 2.3 had no version of datetime.c at all, and Guido was proposing that we add it. So, to get this straight, what _are_ we talking about, exactly? Is there an SF bug/patch with the trunk change?
-- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org
-- --Guido van Rossum (home page: http://www.python.org/~guido/) Ask me about gmail.
Yes, there are patches. There happens to be two entries because I missed some documentation changes the first time around. The links are: https://sourceforge.net/tracker/?group_id=5470&atid=305470&func=detail&aid=876130 https://sourceforge.net/tracker/?group_id=5470&atid=305470&func=detail&aid=986010 The files changed are dist/src/Modules/datetimemodule.c dist/src/Include/datetime.h dist/src/Doc/api/concrete.tex To summarize, an attribute named "datetime_CAPI" is added to the datetime module. A macro PyDateTime_IMPORT is used to access this attribute and then additional macros are available for manipulating datetime instances. If you want to look at an actual implementation you can take a look at cx_Oracle 4.1 beta 1 available at http://starship.python.net/crew/atuining If you have further questions, let me know and I'll try to answer them. Guido van Rossum wrote:
Anthony (the other one), can you explain it?
On Fri, 03 Sep 2004 02:26:12 +1000, Anthony Baxter <anthony@interlink.com.au> wrote:
Tim Peters wrote:
[Anthony Baxter]
Erm - this particular fix was a bug fix. I'm deeply uncomfortable about adding the C version of datetime to 2.3 at this very late stage of 2.3's life cycle.
It's quite arguably a bugfix, since datetime.h in 2.3.4 exposes things that can't possibly be used outside of datetimemodule.c
Ah - I misunderstood, and thought that 2.3 had no version of datetime.c at all, and Guido was proposing that we add it. So, to get this straight, what _are_ we talking about, exactly? Is there an SF bug/patch with the trunk change?
-- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org
-- Anthony Tuininga anthony@computronix.com Computronix Distinctive Software. Real People. Suite 200, 10216 - 124 Street NW Edmonton, AB, Canada T5N 4A3 Phone: (780) 454-3700 Fax: (780) 454-3838 http://www.computronix.com
As long as we're backporting C APIs to 2.3, can I request that the new datetime API be backported to 2.3? Anthony Tuininga (the cx_Oracle author) would be interested in using this and might be willing to help out with the work. (And yes, I'm encouraging this because I could use this myself.)
Erm - this particular fix was a bug fix. I'm deeply uncomfortable about adding the C version of datetime to 2.3 at this very late stage of 2.3's life cycle.
Fair enough. Let's drop the idea. -- --Guido van Rossum (home page: http://www.python.org/~guido/) Ask me about gmail.
participants (9)
-
"Martin v. Löwis" -
Aahz -
Anthony Baxter -
Anthony Tuininga -
Barry Warsaw -
Guido van Rossum -
Jeremy Hylton -
Skip Montanaro -
Tim Peters