Re: [Python-Dev] [Python-checkins] cpython: Issue #19512: Add a new _PyDict_DelItemId() function, similar to
On 8 Nov 2013 09:48, "Victor Stinner" wrote: > > 2013/11/8 Nick Coghlan : > >> http://hg.python.org/cpython/rev/69071054b42f > >> changeset: 86968:69071054b42f > >> user:Victor Stinner > >> date:Wed Nov 06 18:58:22 2013 +0100 > >> summary: > >> Issue #19512: Add a new _PyDict_DelItemId() function, similar to > >> PyDict_DelItemString() but using an identifier for the key > >> ... > > > > As a private API, this shouldn't be part of the stable ABI. > > When I don't know if a function should be made public or not, I > compare with other functions. > > In Python 3.3, _PyDict_GetItemIdWithError(), _PyDict_GetItemId() and > _PyDict_SetItemId() are part of the stable ABI if I read correctly > dictobject.h. _PyObject_GetAttrId() is also part of the stable ABI. > Was it a mistake, or did I misunderstand how stable functions are > declared? Likely a mistake - the stable ABI is hard to review properly (since it can depend on non local preprocessor checks, so a mistake may not be obvious in a diff), we don't currently have a systematic approach to handling changes and there's no automated test to catch inadvertent additions or (worse) removals :( This may be a good thing for us to look at more generally when things settle down a bit after the beta 1 feature freeze. Cheers, Nick. > > Victor > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Issue #19512: Add PyRun_InteractiveOneObject() function
On 8 Nov 2013 10:15, "Eric Snow" wrote: > > On Thu, Nov 7, 2013 at 4:55 PM, Victor Stinner wrote: > > About the 72523 functions PyRun_xxx(), I don't understand something. > > The PyRun_FileEx() is documented in the Python "very high" C API to > > use Python. But this function is not part of the stable ABI. So there > > is no "very high" function in the stable ABI to use Python? > > My understanding is that if you are using the PyRun_* API > (embedding?), you aren't concerned with maintaining binary > compatibility across Python versions. If you are writing an extension > module, you probably aren't using PyRun_*. > > > > > Another question: it's not documented if a function is part or not > > part of the stable ABI. So as an user of the API, it is hard to check > > if a function is part of the stable ABI or not. > > The best we have is probably PEP 384. I've been meaning to work on > the C-API docs for a while and add a concise reference page that would > include a summary of the stable API. Alas, other things have taken > precedence. Give it six months or so and I'll likely once again be looking for people to help out with the "make embedding CPython less painful and arcane" project that is PEP 432. There's a *lot* we can do in that space, along with the PEP 451 based extension loading enhancements. Just throwin' it out there ;) Cheers, Nick. > > -eric ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Issue #19512: Add a new _PyDict_DelItemId() function, similar to
2013/11/8 Nick Coghlan : >> In Python 3.3, _PyDict_GetItemIdWithError(), _PyDict_GetItemId() and >> _PyDict_SetItemId() are part of the stable ABI if I read correctly >> dictobject.h. _PyObject_GetAttrId() is also part of the stable ABI. >> Was it a mistake, or did I misunderstand how stable functions are >> declared? > > Likely a mistake - the stable ABI is hard to review properly (since it can > depend on non local preprocessor checks, so a mistake may not be obvious in > a diff), we don't currently have a systematic approach to handling changes > and there's no automated test to catch inadvertent additions or (worse) > removals :( Would it be possible to remove them from the stable ABI in Python 3.4? They are marked as private using the "_Py" prefix... > This may be a good thing for us to look at more generally when things settle > down a bit after the beta 1 feature freeze. I created the following issue to not forget it: http://bugs.python.org/issue19526 Victor ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Issue #19512: Add a new _PyDict_DelItemId() function, similar to
Am 08.11.2013 12:19, schrieb Victor Stinner: 2013/11/8 Nick Coghlan : In Python 3.3, _PyDict_GetItemIdWithError(), _PyDict_GetItemId() and _PyDict_SetItemId() are part of the stable ABI if I read correctly dictobject.h. _PyObject_GetAttrId() is also part of the stable ABI. Was it a mistake, or did I misunderstand how stable functions are declared? Likely a mistake - the stable ABI is hard to review properly (since it can depend on non local preprocessor checks, so a mistake may not be obvious in a diff), we don't currently have a systematic approach to handling changes and there's no automated test to catch inadvertent additions or (worse) removals :( Would it be possible to remove them from the stable ABI in Python 3.4? They are marked as private using the "_Py" prefix... I may be confusing API and ABI (see my other message), but adding to or removing functions from the stable ABI seems to be a very serious mistake, IMO - private or not. Unless my understanding of the word 'stable' is wrong... This may be a good thing for us to look at more generally when things settle down a bit after the beta 1 feature freeze. I created the following issue to not forget it: http://bugs.python.org/issue19526 Thomas ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Issue #19512: Add a new _PyDict_DelItemId() function, similar to
Am 08.11.2013 13:03, schrieb Thomas Heller: I may be confusing API and ABI (see my other message), but adding to or removing functions from the stable ABI seems to be a very serious mistake, IMO - private or not. Unless my understanding of the word 'stable' is wrong... Ok - my mistake. The PEP allows functions to be added (but not to be removed). From PEP 384: """ During evolution of Python, new ABI functions will be added. Applications using them will then have a requirement on a minimum version of Python; this PEP provides no mechanism for such applications to fall back when the Python library is too old. """ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Issue #19512: Add a new _PyDict_DelItemId() function, similar to
On 8 Nov 2013 22:03, "Thomas Heller" wrote: > > Am 08.11.2013 12:19, schrieb Victor Stinner: > >> 2013/11/8 Nick Coghlan : In Python 3.3, _PyDict_GetItemIdWithError(), _PyDict_GetItemId() and _PyDict_SetItemId() are part of the stable ABI if I read correctly dictobject.h. _PyObject_GetAttrId() is also part of the stable ABI. Was it a mistake, or did I misunderstand how stable functions are declared? >>> >>> >>> Likely a mistake - the stable ABI is hard to review properly (since it can >>> depend on non local preprocessor checks, so a mistake may not be obvious in >>> a diff), we don't currently have a systematic approach to handling changes >>> and there's no automated test to catch inadvertent additions or (worse) >>> removals :( >> >> >> Would it be possible to remove them from the stable ABI in Python 3.4? >> They are marked as private using the "_Py" prefix... > > > I may be confusing API and ABI (see my other message), but adding to > or removing functions from the stable ABI seems to be a very serious > mistake, IMO - private or not. Unless my understanding of the word > 'stable' is wrong... Yeah, we can add things to the stable ABI with an appropriate version guard, but we won't remove even private APIs if they were previously published in 3.3. The main thing I get out of this is that we need to figure out a way to test it automatically - the nature of the problem means that code review is an inherently unreliable mechanism for spotting mistakes. Cheers, Nick. > > >>> This may be a good thing for us to look at more generally when things settle >>> down a bit after the beta 1 feature freeze. >> >> >> I created the following issue to not forget it: >> http://bugs.python.org/issue19526 > > > Thomas > > > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Simplify and unify SSL verification
Am 08.11.2013 08:42, schrieb Antoine Pitrou: > 3.2 actually, while many code bases are still 2.x-compatible. > There's no need to make migration more annoying right now. There is also no need to hinder and delay future improvements for the sake of 2.x compatibility. Python 2.7.0 has been released in July 2010. Python 3.5 will be released late 2015. 3rd parties can backport Python 3.x ssl module if they need the new feature in 2.x, too. Seriously, it's time to set Python 3 free. Python 2.7 shall no longer be a millstone around Python 3's neck. > If it's not solved on *all* platforms then you're introducing a nasty > discrepancy between platforms. > > That said, "secure by default" could be a property of the "default > context factory" (see below). I think you forget that incompatible changes won't happen until Python 3.5. Developer and users can still have the insecure, non verified mode but they have to configure it explictly. > Ok, so what about the long term compatibility issues? > > I'd be ok if you changed the name as suggested by Nick *and* if it was > explicit that the security settings for this context can change between > releases, therefore working code can break due to upgraded security > standards. Absolutely! Applications shall create their own context if they require full control. create_default_context() return a sensible context object that is subject to changes between releases. > But, really, it strikes me that adding this method to SSLSocket may make > things more confusing. The docs will have to be clear that certificate > *validation* and certificate *matching* are two different things (that > is, you can't pass CERT_NONE and then expect calling match_cert() is > sufficient). I like Nick's idea with verify_hostname flag and a postverify callback. At first the callback is invoked. Then the hostname is verified if either verify_hostname is true or None with CERT_OPTIONAL / CERT_REQUIRED. Similar to __exit__() the callback can return a true value in order to skip hostname matching. >> The **kwargs make it possible to pass data from the caller of >> check_cert() to the callback function of the SSLContext instance. > > Well, I think such explicit "user data" needn't exist in Python. Sure, people can just use thread local storage or walk up the stack with sys._getframe(). That's going to work well for asyncio! :p Christian ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2013-11-01 - 2013-11-08) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open4227 (+10) closed 27074 (+45) total 31301 (+55) Open issues with patches: 1960 Issues opened (43) == #10197: subprocess.getoutput fails on win32 http://bugs.python.org/issue10197 reopened by gregory.p.smith #19475: Add microsecond flag to datetime isoformat() http://bugs.python.org/issue19475 opened by skip.montanaro #19476: Add a dedicated specification for module "reloading" to the la http://bugs.python.org/issue19476 opened by eric.snow #19477: document tp_print() as being dead in Py3 http://bugs.python.org/issue19477 opened by scoder #19478: Add ability to prefix posix semaphore names created by multipr http://bugs.python.org/issue19478 opened by Marc.Liyanage #19479: textwrap.dedent doesn't work properly with strings containing http://bugs.python.org/issue19479 opened by alexis.d #19481: IDLE hangs while printing instance of Unicode subclass http://bugs.python.org/issue19481 opened by tim.peters #19482: _pickle build warnings on Fedora 19 http://bugs.python.org/issue19482 opened by ncoghlan #19483: Pure-Python ElementTree classes no longer available since 3.3 http://bugs.python.org/issue19483 opened by brechtm #19486: Bump up version of Tcl/Tk in building Python in Windows platfo http://bugs.python.org/issue19486 opened by vajrasky #19489: move quick search box above TOC http://bugs.python.org/issue19489 opened by georg.brandl #19490: Problem installing matplotlib 1.3.1 with Python 2.7.6rc1 and 3 http://bugs.python.org/issue19490 opened by ned.deily #19491: Python Crashing When Saving Documents http://bugs.python.org/issue19491 opened by [email protected] #19492: Report skipped distutils tests as skipped http://bugs.python.org/issue19492 opened by serhiy.storchaka #19493: Report skipped ctypes tests as skipped http://bugs.python.org/issue19493 opened by serhiy.storchaka #19494: urllib2.HTTPBasicAuthHandler (or urllib.request.HTTPBasicAuthH http://bugs.python.org/issue19494 opened by mcepl #19495: Enhancement for timeit: measure time to run blocks of code usi http://bugs.python.org/issue19495 opened by dmoore #19499: "import this" is cached in sys.modules http://bugs.python.org/issue19499 opened by rhettinger #19500: Error when connecting to FTPS servers not supporting SSL sessi http://bugs.python.org/issue19500 opened by Ye.Wang #19501: Buildbot testing of 3.2 broken http://bugs.python.org/issue19501 opened by zach.ware #19502: Wrong time zone offset, when using time.strftime() with a give http://bugs.python.org/issue19502 opened by pwronisz #19504: Change "customise" to "customize". http://bugs.python.org/issue19504 opened by eric.smith #19505: OrderedDict views don't implement __reversed__ http://bugs.python.org/issue19505 opened by ThiefMaster #19506: subprocess.communicate() should use a memoryview http://bugs.python.org/issue19506 opened by haypo #19507: ssl.wrap_socket() with server_hostname should imply match_host http://bugs.python.org/issue19507 opened by christian.heimes #19508: Add warning that Python doesn't verify SSL certs by default http://bugs.python.org/issue19508 opened by christian.heimes #19509: No SSL match_hostname() in ftp, imap, nntp, pop, smtp modules http://bugs.python.org/issue19509 opened by christian.heimes #19510: lib2to3.fixes.fix_import gets confused if implicit relative im http://bugs.python.org/issue19510 opened by durin42 #19511: lib2to3 Grammar file is no longer a Python 3 superset http://bugs.python.org/issue19511 opened by ncoghlan #19512: Avoid temporary Unicode strings, use identifiers to only creat http://bugs.python.org/issue19512 opened by haypo #19513: Use PyUnicodeWriter instead of PyAccu in repr(tuple) and repr( http://bugs.python.org/issue19513 opened by haypo #19515: Share duplicated _Py_IDENTIFIER identifiers in C code http://bugs.python.org/issue19515 opened by haypo #19517: sysconfig variables introduced by PEP-3149 are currently undoc http://bugs.python.org/issue19517 opened by zaytsev #19518: Add new PyRun_xxx() functions to not encode the filename http://bugs.python.org/issue19518 opened by haypo #19519: Parser: don't transcode input string to UTF-8 if it is already http://bugs.python.org/issue19519 opened by haypo #19520: Win32 compiler warning in _sha3 http://bugs.python.org/issue19520 opened by zach.ware #19521: parallel build race condition on AIX since python-3.2 http://bugs.python.org/issue19521 opened by haubi #19523: logging.FileHandler - using of delay argument case handle leak http://bugs.python.org/issue19523 opened by DDGG #19524: ResourceWarning when urlopen() forgets the HTTPConnection obje http://bugs.python.org/issue19524 opened by vadmium #19526: Review additions to the stable ABI of Python 3.4
Re: [Python-Dev] Simplify and unify SSL verification
Le 08/11/2013 17:39, Christian Heimes a écrit : Am 08.11.2013 08:42, schrieb Antoine Pitrou: 3.2 actually, while many code bases are still 2.x-compatible. There's no need to make migration more annoying right now. There is also no need to hinder and delay future improvements for the sake of 2.x compatibility. It's not an improvement, you are proposing to remove existing arguments to stdlib functions/constructors. I agree it would be cleaner without them, but there's no rush really. If it's not solved on *all* platforms then you're introducing a nasty discrepancy between platforms. That said, "secure by default" could be a property of the "default context factory" (see below). I think you forget that incompatible changes won't happen until Python 3.5. Developer and users can still have the insecure, non verified mode but they have to configure it explictly. Whether "secure by default" happens in 3.4 or 3.5 doesn't change my point. I'd be ok if you changed the name as suggested by Nick *and* if it was explicit that the security settings for this context can change between releases, therefore working code can break due to upgraded security standards. Absolutely! Applications shall create their own context if they require full control. create_default_context() return a sensible context object that is subject to changes between releases. Ok, fine with me, then. But, really, it strikes me that adding this method to SSLSocket may make things more confusing. The docs will have to be clear that certificate *validation* and certificate *matching* are two different things (that is, you can't pass CERT_NONE and then expect calling match_cert() is sufficient). I like Nick's idea with verify_hostname flag and a postverify callback. I don't really like it. There are already two steps: cert validation and cert matching, this idea is adding a third step and therefore making things extra confusing. The **kwargs make it possible to pass data from the caller of check_cert() to the callback function of the SSLContext instance. Well, I think such explicit "user data" needn't exist in Python. Sure, people can just use thread local storage or walk up the stack with sys._getframe(). That's going to work well for asyncio! Actually, sensible people will use a closure, but you can prefer thread-local storage or sys._getframe() if that's your taste in programming. Regards Antoine. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 451 (ModuleSpec) is accepted
I'm pleased to announce that Brett Cannon and Nick Coghlan (the co-BDFL-delegates) have accepted PEP 451 for inclusion in Python 3.4. Both of them have contributed substantially to the discussions of the proposal and have helped make it solid. I'm grateful for their diligence, attentiveness, and expertise. I'd also like to thank PJ Eby, who provided important insight on several occasions and helped out with some sticky backward-compatibility situations. http://www.python.org/dev/peps/pep-0451/ -eric ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 451 (ModuleSpec) is accepted
Oh congrats Eric for your PEP. I like it. Victor Le vendredi 8 novembre 2013, Eric Snow a écrit : > I'm pleased to announce that Brett Cannon and Nick Coghlan (the > co-BDFL-delegates) have accepted PEP 451 for inclusion in Python 3.4. > Both of them have contributed substantially to the discussions of the > proposal and have helped make it solid. I'm grateful for their > diligence, attentiveness, and expertise. I'd also like to thank PJ > Eby, who provided important insight on several occasions and helped > out with some sticky backward-compatibility situations. > > http://www.python.org/dev/peps/pep-0451/ > > -eric > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 451 (ModuleSpec) is accepted
I just want to publicly thank Eric for his hard work on this PEP. I think Nick, Eric, and myself all came to the same conclusion independently about needing to update the APIs used by import to make them more flexible and able to grow in the future, but Eric is the one that took the time to champion the changes, write the PEP, and handle the huge amount of feedback both on the import SIG and here along with his current patch. I know I'm quite pleased with the way this PEP turned out and am already looking forward to using the new APIs hopefully in Python 3.5 for introducing a lazy loader mechanism to the stdlib. On Fri, Nov 8, 2013 at 2:49 PM, Eric Snow wrote: > I'm pleased to announce that Brett Cannon and Nick Coghlan (the > co-BDFL-delegates) have accepted PEP 451 for inclusion in Python 3.4. > Both of them have contributed substantially to the discussions of the > proposal and have helped make it solid. I'm grateful for their > diligence, attentiveness, and expertise. I'd also like to thank PJ > Eby, who provided important insight on several occasions and helped > out with some sticky backward-compatibility situations. > > http://www.python.org/dev/peps/pep-0451/ > > -eric > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/brett%40python.org > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 451 (ModuleSpec) is accepted
Congrats are deserved all around. This is a solid PEP. I'm glad you all took such great care with the design and the review. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Simplify and unify SSL verification
On 9 Nov 2013 02:41, "Christian Heimes" wrote: > > Am 08.11.2013 08:42, schrieb Antoine Pitrou: > > 3.2 actually, while many code bases are still 2.x-compatible. > > There's no need to make migration more annoying right now. > > There is also no need to hinder and delay future improvements for the > sake of 2.x compatibility. Python 2.7.0 has been released in July 2010. > Python 3.5 will be released late 2015. 3rd parties can backport Python > 3.x ssl module if they need the new feature in 2.x, too. > > Seriously, it's time to set Python 3 free. Python 2.7 shall no longer be > a millstone around Python 3's neck. As long as there is a backports.ssl module, support in tulip and in requests, it's likely fine in terms of supporting the common 2/3 subset. However, since this change mostly *can* be published via PyPI, I also don't think it makes sense to rush the design of this in the next two weeks. - I'm already trying to help get the binary codec changes, ensurepip and ModuleSpec landed - the hash update PEP still needs to be finalised - there's a couple of other context management features assigned to me to check before the deadline Heck, testing on PyPI first would even allow for fixing the misnomer - currently we're importing the ssl module to access Python's TLS support, which can't be helping the widespread misunderstanding of the fact they're not quite the same thing (even though TLS superseded SSL). The "create_default_context" idea and ensuring affected APIs accept a context object doesn't need to wait, nor does deprecating the implied CERT_NONE verification mode. It's just the parameter deprecations and the matching customisation API I think should be delayed, since those have broader implications that I don't believe we can give adequate consideration in two weeks when there's already plenty of other work we're still trying to finish up. Cheers, Nick. > > > If it's not solved on *all* platforms then you're introducing a nasty > > discrepancy between platforms. > > > > That said, "secure by default" could be a property of the "default > > context factory" (see below). > > I think you forget that incompatible changes won't happen until Python > 3.5. Developer and users can still have the insecure, non verified mode > but they have to configure it explictly. > > > > Ok, so what about the long term compatibility issues? > > > > I'd be ok if you changed the name as suggested by Nick *and* if it was > > explicit that the security settings for this context can change between > > releases, therefore working code can break due to upgraded security > > standards. > > Absolutely! Applications shall create their own context if they require > full control. create_default_context() return a sensible context object > that is subject to changes between releases. > > > > But, really, it strikes me that adding this method to SSLSocket may make > > things more confusing. The docs will have to be clear that certificate > > *validation* and certificate *matching* are two different things (that > > is, you can't pass CERT_NONE and then expect calling match_cert() is > > sufficient). > > I like Nick's idea with verify_hostname flag and a postverify callback. > > At first the callback is invoked. Then the hostname is verified if > either verify_hostname is true or None with CERT_OPTIONAL / > CERT_REQUIRED. Similar to __exit__() the callback can return a true > value in order to skip hostname matching. > > > >> The **kwargs make it possible to pass data from the caller of > >> check_cert() to the callback function of the SSLContext instance. > > > > Well, I think such explicit "user data" needn't exist in Python. > > Sure, people can just use thread local storage or walk up the stack with > sys._getframe(). That's going to work well for asyncio! > > :p > > Christian > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 451 (ModuleSpec) is accepted
On 11/08/2013 11:49 AM, Eric Snow wrote: I'm pleased to announce that Brett Cannon and Nick Coghlan (the co-BDFL-delegates) have accepted PEP 451 for inclusion in Python 3.4. Excellent! Congrats, and thanks to everyone who worked on it. -- ~Ethan~ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 451 (ModuleSpec) is accepted
On Nov 08, 2013, at 12:49 PM, Eric Snow wrote: >I'm pleased to announce that Brett Cannon and Nick Coghlan (the >co-BDFL-delegates) have accepted PEP 451 for inclusion in Python 3.4. >Both of them have contributed substantially to the discussions of the >proposal and have helped make it solid. I'm grateful for their >diligence, attentiveness, and expertise. I'd also like to thank PJ >Eby, who provided important insight on several occasions and helped >out with some sticky backward-compatibility situations. > >http://www.python.org/dev/peps/pep-0451/ Congratulations for all the hard work on a great PEP. -Barry ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 451 (ModuleSpec) is accepted
On 9 Nov 2013 06:39, "Brett Cannon" wrote: > > I just want to publicly thank Eric for his hard work on this PEP. I think Nick, Eric, and myself all came to the same conclusion independently about needing to update the APIs used by import to make them more flexible and able to grow in the future, but Eric is the one that took the time to champion the changes, write the PEP, and handle the huge amount of feedback both on the import SIG and here along with his current patch. > > I know I'm quite pleased with the way this PEP turned out and am already looking forward to using the new APIs hopefully in Python 3.5 for introducing a lazy loader mechanism to the stdlib. We should even be able to finally make circular imports work more consistently, better handle partial failures of packages that implicitly import submodules and address some of the import traps described in PEP 395. This change also enables better integration of runpy with the normal import system, the opportunity for much cleaner reload support (it's currently rife with opportunities for implicit, hard to debug, failures) and the possibility of bringing C extension loading up to a similar level of capability to Python module execution (e.g. allowing extension modules to support execution via runpy) Many of those related changes won't happen until Python 3.5, but PEP 451 is an important step towards making them practical. Awesome work, Eric - this is a far more significant upgrade to the import system than my indirect import idea that originally spawned the discussion on import-sig :) Cheers, Nick. > > > On Fri, Nov 8, 2013 at 2:49 PM, Eric Snow wrote: >> >> I'm pleased to announce that Brett Cannon and Nick Coghlan (the >> co-BDFL-delegates) have accepted PEP 451 for inclusion in Python 3.4. >> Both of them have contributed substantially to the discussions of the >> proposal and have helped make it solid. I'm grateful for their >> diligence, attentiveness, and expertise. I'd also like to thank PJ >> Eby, who provided important insight on several occasions and helped >> out with some sticky backward-compatibility situations. >> >> http://www.python.org/dev/peps/pep-0451/ >> >> -eric >> ___ >> Python-Dev mailing list >> [email protected] >> https://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: https://mail.python.org/mailman/options/python-dev/brett%40python.org > > > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Issue #19512: Add a new _PyDict_DelItemId() function, similar to
Am 08.11.13 10:25, schrieb Nick Coghlan: > Likely a mistake - the stable ABI is hard to review properly (since it > can depend on non local preprocessor checks, so a mistake may not be > obvious in a diff), we don't currently have a systematic approach to > handling changes and there's no automated test to catch inadvertent > additions or (worse) removals :( Actually, there is, for Windows. The .def file is an explicit list of symbols; additions can easily be reviewed. Everything that's not added there is not in the stable ABI (whether or not it is included in the #ifdef). Removals cause linker failures. It would be possible to automatically find out whether any functions declared under the stable API are actually exported also, by parsing the preprocessor output for Python.h Regards, Martin ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
