On Thu, Aug 7, 2008 at 11:57 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: > On 2008-08-07 19:09, Guido van Rossum wrote: >> >> Sounds like a plan. Make sure it is prominently mentioned in Misc/NEWS. > > Committed as r65582.
Thanks! > All tests pass except test_socket, but that appears to be related > to some quirk on my machine: > > File "Lib/test/test_socket.py", line 365, in testGetServBy > eq(socket.getservbyport(port2), service) > socket.error: port/proto not found I saw this fail earlier today, but now I can't repro it. What OS+hardware? > Note that the macro PyObject_REPR() still potentially exposes the > _PyUnicode_AsString() API to 3rd party code. We should probably > change that macro to a function in Python 3.1. > >> On Thu, Aug 7, 2008 at 10:03 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: >>> >>> On 2008-08-07 18:40, Guido van Rossum wrote: >>>> >>>> On Thu, Aug 7, 2008 at 5:18 AM, Barry Warsaw <[EMAIL PROTECTED]> wrote: >>>>> >>>>> On Aug 7, 2008, at 5:09 AM, M.-A. Lemburg wrote: >>>>> >>>>>>>> Is it too late for that ? >>>>>>> >>>>>>> That kind of depends on how far other 3rd party projects are in >>>>>>> porting their extensions to Py3k, and how much they've bought into >>>>>>> these APIs. I recall that mechanically translating these APIs to >>>>>>> something else can easily introduce memory leaks. >>>>>> >>>>>> True, but isn't it better to go through that pain for a few extensions >>>>>> now and then have a proper C API to use in 3.1 ? Otherwise, we end >>>>>> up having to support those APIs for the whole lifetime >>>>>> of the 3.x branch. >>>>>> >>>>>> Note that those two APIs are not documented, so their use is not >>>>>> yet officially allowed. >>>>> >>>>> I'd prefer not introducing such instability this late in the beta >>>>> processes, >>>>> but I agree that fixing it now will be better in the long term. >>>> >>>> I see this as a sufficient endorsement. Marc-Andre, can you do this? >>> >>> Yes. I'll just apply a renaming of two APIs (and all their uses >>> in the interpreter code) to a _Py internal name. >>> >>> We can then hash out a better interface to the internal UTF-8 >>> representation for 3.1. >>> >>> Extension that use the current unofficial APIs could then also >>> apply that renaming if the developers don't have time to update >>> the code and then use the new APIs when 3.1 ships. >>> >>> -- >>> Marc-Andre Lemburg >>> eGenix.com >>> >>> Professional Python Services directly from the Source (#1, Aug 07 2008) >>>>>> >>>>>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>>>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>>>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ >>> >>> ________________________________________________________________________ >>> >>> :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: >>> >>> >>> eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 >>> D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg >>> Registered at Amtsgericht Duesseldorf: HRB 46611 >>> >> >> >> > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Aug 07 2008) >>>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ > ________________________________________________________________________ > > :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: > > > eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 > D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg > Registered at Amtsgericht Duesseldorf: HRB 46611 > -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
