Re: [Python-Dev] [RELEASED] Python 3.5.0b2 is now available
Thanks Larry, and my apologies to the release team for the extra work! Regards, Nick. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.7 is here until 2020, please don't call it a waste.
On 01.06.2015 12:44, Armin Rigo wrote: Hi Larry, On 31 May 2015 at 01:20, Larry Hastings la...@hastings.org wrote: p.s. Supporting this patch also helps cut into PyPy's reported performance lead--that is, if they ever upgrade speed.pypy.org from comparing against Python *2.7.2*. Right, we should do this upgrade when 2.7.11 is out. There is some irony in your comment which seems to imply PyPy is cheating by comparing with an old Python 2.7.2: it is inside a thread which started because we didn't backport performance improvements to 2.7.x so far. Just to convince myself, I just ran a performance comparison. I ran the same benchmark suite as speed.pypy.org, with 2.7.2 against 2.7.10, both freshly compiled with no configure options at all. The differences are usually in the noise, but range from +5% to... -60%. If anything, this seems to show that CPython should take more care about performance regressions. If someone is interested: * raytrace-simple is 1.19 times slower * bm_mako is 1.29 times slower * spitfire_cstringio is 1.60 times slower * a number of other benchmarks are around 1.08. The 7.0x faster number on speed.pypy.org would be significantly *higher* if we upgraded the baseline to 2.7.10 now. If someone were to volunteer to set up and run speed.python.org, I think we could add some additional focus on performance regressions. Right now, we don't have any way of reliably and reproducibly testing Python performance. Hint: The PSF would most likely fund such adventures :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 01 2015) Python Projects, Coaching and Consulting ... http://www.egenix.com/ mxODBC Plone/Zope Database Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ : Try our mxODBC.Connect Python Database Interface 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 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.7 is here until 2020, please don't call it a waste.
Hello, On Mon, 01 Jun 2015 13:14:27 +0200 M.-A. Lemburg m...@egenix.com wrote: [] The 7.0x faster number on speed.pypy.org would be significantly *higher* if we upgraded the baseline to 2.7.10 now. If someone were to volunteer to set up and run speed.python.org, I think we could add some additional focus on performance regressions. Right now, we don't have any way of reliably and reproducibly testing Python performance. Just for the note, we had similar concerns with performance and other regressions in MicroPython, and in the end, http://micropython.org/resources/code-dashboard/ was set up. Performance tracking is simplistic so far and consists only of running pystones; mostly the executable size for different configuration is tracked, as that's the most distinctive trait of MicroPython. -- Best regards, Paul mailto:pmis...@gmail.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.7 is here until 2020, please don't call it a waste.
Hi Larry, On 31 May 2015 at 01:20, Larry Hastings la...@hastings.org wrote: p.s. Supporting this patch also helps cut into PyPy's reported performance lead--that is, if they ever upgrade speed.pypy.org from comparing against Python *2.7.2*. Right, we should do this upgrade when 2.7.11 is out. There is some irony in your comment which seems to imply PyPy is cheating by comparing with an old Python 2.7.2: it is inside a thread which started because we didn't backport performance improvements to 2.7.x so far. Just to convince myself, I just ran a performance comparison. I ran the same benchmark suite as speed.pypy.org, with 2.7.2 against 2.7.10, both freshly compiled with no configure options at all. The differences are usually in the noise, but range from +5% to... -60%. If anything, this seems to show that CPython should take more care about performance regressions. If someone is interested: * raytrace-simple is 1.19 times slower * bm_mako is 1.29 times slower * spitfire_cstringio is 1.60 times slower * a number of other benchmarks are around 1.08. The 7.0x faster number on speed.pypy.org would be significantly *higher* if we upgraded the baseline to 2.7.10 now. A bientôt, Armin. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Avoiding reference leaks in heap types with custom tp_dealloc
On Mon, 1 Jun 2015 17:52:13 +0200 Petr Viktorin encu...@gmail.com wrote: On Mon, Jun 1, 2015 at 5:33 PM, Antoine Pitrou solip...@pitrou.net wrote: On Mon, 1 Jun 2015 16:38:35 +0200 Petr Viktorin encu...@gmail.com wrote: [...] The nice way out would be taking advantage of PEP 442: xxlimited.Xxo can ditch tp_dealloc in favor of tp_traverse and tp_finalize (the former of which it needs anyway to behave correctly). Unfortunately, tp_finalize is not available in the stable ABI (issue24345). I think it should be added; is it too late for 3.5? Well, but the stable ABI is supposed to be a subset of the API that's safe to program against, regardless of the Python version (at least from the point where the stable ABI was introduced). That part's not true. From the PEP: 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. I think we have been laxist with additions to the stable ABI: apparently, they should be conditioned on the API version requested by the user. For example, in pystate.h: #if !defined(Py_LIMITED_API) || Py_LIMITED_API+0 = 0x0303 /* New in 3.3 */ PyAPI_FUNC(int) PyState_AddModule(PyObject*, struct PyModuleDef*); PyAPI_FUNC(int) PyState_RemoveModule(struct PyModuleDef*); #endif (those were added by Martin, so I assume he knew what he was doing :-)) This way, failing to restrict yourself to a given API version fails at compile time, not at runtime. However, it's also more work to do so when adding stuff, which is why we tend to skimp on it. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Avoiding reference leaks in heap types with custom tp_dealloc
On Mon, Jun 1, 2015, at 11:33, Antoine Pitrou wrote: On Mon, 1 Jun 2015 16:38:35 +0200 Petr Viktorin encu...@gmail.com wrote: Hello, The new test_importlib.extension.test_loader is currently leaking references, (issue24268). There is a simple hack to stop this, but I'm inclined to not apply quick hacks and rather dig into the root cause. (It's a test module, the refleaks are relatively harmless.) The tests are based directly on the xxlimited example, xxlimited.Xxo, which exhibits the same bug -- it's just not tested. It's is caused by a combination of a few factors, but I'm not sure what's a bug and what's just undocumented behavior, so I'm asking for input to put me on the right track. Yes, the issue is really nasty. There are several situations to take into account: - derived heap type inherits from base heap type, both have custom deallocs - derived heap type inherits from base heap type, only one has a custom dealloc - derived heap type inherits from Python-defined class (the latter having subtype_dealloc) - derived heap type inherits from static type - ... It is unreasonable to expect developers of C extensions come up with the correct incantation (and ideally, they shouldn't have to think about it at all). The nice way out would be taking advantage of PEP 442: xxlimited.Xxo can ditch tp_dealloc in favor of tp_traverse and tp_finalize (the former of which it needs anyway to behave correctly). Unfortunately, tp_finalize is not available in the stable ABI (issue24345). I think it should be added; is it too late for 3.5? Well, but the stable ABI is supposed to be a subset of the API that's safe to program against, regardless of the Python version (at least from the point where the stable ABI was introduced). What happens if you define a Py_tp_finalize and run your C extension type on a pre-3.5 version? Do you get an error at definition time? A resource leak? A crash? I don't get why Benjamin committed the change so quick. I thought all the slots were supposed to be available through the stable ABI, since you need them to properly define c types. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Avoiding reference leaks in heap types with custom tp_dealloc
On Mon, Jun 1, 2015 at 5:33 PM, Antoine Pitrou solip...@pitrou.net wrote: On Mon, 1 Jun 2015 16:38:35 +0200 Petr Viktorin encu...@gmail.com wrote: [...] The nice way out would be taking advantage of PEP 442: xxlimited.Xxo can ditch tp_dealloc in favor of tp_traverse and tp_finalize (the former of which it needs anyway to behave correctly). Unfortunately, tp_finalize is not available in the stable ABI (issue24345). I think it should be added; is it too late for 3.5? Well, but the stable ABI is supposed to be a subset of the API that's safe to program against, regardless of the Python version (at least from the point where the stable ABI was introduced). That part's not true. From the PEP: 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. What happens if you define a Py_tp_finalize and run your C extension type on a pre-3.5 version? Do you get an error at definition time? A resource leak? A crash? Looking at PyType_FromSpecWithBases code, you should get RuntimeError(invalid slot offset) in this case. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Avoiding reference leaks in heap types with custom tp_dealloc
On Mon, 1 Jun 2015 16:38:35 +0200 Petr Viktorin encu...@gmail.com wrote: Hello, The new test_importlib.extension.test_loader is currently leaking references, (issue24268). There is a simple hack to stop this, but I'm inclined to not apply quick hacks and rather dig into the root cause. (It's a test module, the refleaks are relatively harmless.) The tests are based directly on the xxlimited example, xxlimited.Xxo, which exhibits the same bug -- it's just not tested. It's is caused by a combination of a few factors, but I'm not sure what's a bug and what's just undocumented behavior, so I'm asking for input to put me on the right track. Yes, the issue is really nasty. There are several situations to take into account: - derived heap type inherits from base heap type, both have custom deallocs - derived heap type inherits from base heap type, only one has a custom dealloc - derived heap type inherits from Python-defined class (the latter having subtype_dealloc) - derived heap type inherits from static type - ... It is unreasonable to expect developers of C extensions come up with the correct incantation (and ideally, they shouldn't have to think about it at all). The nice way out would be taking advantage of PEP 442: xxlimited.Xxo can ditch tp_dealloc in favor of tp_traverse and tp_finalize (the former of which it needs anyway to behave correctly). Unfortunately, tp_finalize is not available in the stable ABI (issue24345). I think it should be added; is it too late for 3.5? Well, but the stable ABI is supposed to be a subset of the API that's safe to program against, regardless of the Python version (at least from the point where the stable ABI was introduced). What happens if you define a Py_tp_finalize and run your C extension type on a pre-3.5 version? Do you get an error at definition time? A resource leak? A crash? I don't get why Benjamin committed the change so quick. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Avoiding reference leaks in heap types with custom tp_dealloc
On Mon, 01 Jun 2015 12:09:37 -0400 Benjamin Peterson benja...@python.org wrote: I thought all the slots were supposed to be available through the stable ABI, since you need them to properly define c types. You're right, I was thinking specifically about the ABI versioning issues (which I exposed in my reply to Petr). Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Avoiding reference leaks in heap types with custom tp_dealloc
Hello, The new test_importlib.extension.test_loader is currently leaking references, (issue24268). There is a simple hack to stop this, but I'm inclined to not apply quick hacks and rather dig into the root cause. (It's a test module, the refleaks are relatively harmless.) The tests are based directly on the xxlimited example, xxlimited.Xxo, which exhibits the same bug -- it's just not tested. It's is caused by a combination of a few factors, but I'm not sure what's a bug and what's just undocumented behavior, so I'm asking for input to put me on the right track. As reported in issue16690, heap types with a naïve custom tp_dealloc leak references to the type when instantiated. According to [0], it seems that tp_dealloc should check if it has been overridden, and if so, decref the type. This needs to be documented (regardless of the solution to the other problems), and I intend to document it. We can change xxlimited to do the check and decref, but isn't it too ugly for a module that showcases the extension module API? (xxlimited.Xxo can technically skip the check, since it doesn't allow subclasses, but that would be setting a nasty trap for anyone learning from that example.) The nice way out would be taking advantage of PEP 442: xxlimited.Xxo can ditch tp_dealloc in favor of tp_traverse and tp_finalize (the former of which it needs anyway to behave correctly). Unfortunately, tp_finalize is not available in the stable ABI (issue24345). I think it should be added; is it too late for 3.5? Another problem is that xxlimited is untested. It's only built for non-debug builds, because Py_LIMITED_API and Py_DEBUG are incompatible. Would it make sense to build and test it without Py_LIMITED_API in debug mode, instead of not building it at all? [0] http://bugs.python.org/issue15653#msg168449 ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Windows new 3.5 installer: Command line uninstall
I'm trying to script a command line uninstall of Python 3.5. The new installer has a nice well-documented command line interface, but there's nothing much about how to uninstall. Looking at the installed products, I see get-wmiobject Win32_Product -filter 'name like Python 3.5.0b2%' | select Name Name Python 3.5.0b2 pip Bootstrap (64-bit) Python 3.5.0b2 Development Libraries (64-bit) Python 3.5.0b2 C Runtime (64-bit) Python 3.5.0b2 Tcl/Tk Support (64-bit) Python 3.5.0b2 Standard Library (64-bit) Python 3.5.0b2 Executables (64-bit) Python 3.5.0b2 Core Interpreter (64-bit) Python 3.5.0b2 Launcher (32-bit) Python 3.5.0b2 Documentation (64-bit) Python 3.5.0b2 Utility Scripts (64-bit) Python 3.5.0b2 Test Suite (64-bit) Normally I'd be able to call the Uninstall method on the installed product, but here, I'm not sure which of the above I'd call Uninstall on (there's only one Programs and Features entry for 3.5, and I can't tell which of these is equivalent to it - or if I need to uninstall each in turn, I don't know what order they need to be done in). Specifically (get-wmiobject -query 'select * from Win32_Product where name = Python 2.7.8 (64-bit)').Uninstall() is an automated, command line silent uninstall of Python 2.7.8. What (if anything) would be the equivalent for 3.5.0b2? Paul ___ Python-Dev mailing list Python-Dev@python.org 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] peps: We have a 3.6 release PEP.
It looks like we now have two 3.6 release PEPs: 494 495 Yury On 2015-06-01 1:59 PM, barry.warsaw wrote: https://hg.python.org/peps/rev/a50d51e8c748 changeset: 5888:a50d51e8c748 user:Barry Warsaw ba...@python.org date:Mon Jun 01 13:59:32 2015 -0400 summary: We have a 3.6 release PEP. files: pep-0495.txt | 66 1 files changed, 66 insertions(+), 0 deletions(-) diff --git a/pep-0495.txt b/pep-0495.txt new file mode 100644 --- /dev/null +++ b/pep-0495.txt @@ -0,0 +1,66 @@ +PEP: 495 +Title: Python 3.6 Release Schedule +Version: $Revision$ +Last-Modified: $Date$ +Author: Ned Deily n...@acm.org +Status: Active +Type: Informational +Content-Type: text/x-rst +Created: 30-May-2015 +Python-Version: 3.6 + + +Abstract + + +This document describes the development and release schedule for Python 3.6. +The schedule primarily concerns itself with PEP-sized items. + +.. Small features may be added up to the first beta release. Bugs may be + fixed until the final release, which is tentatively planned for late 2016. + + +Release Manager and Crew + + +- 3.6 Release Manager: Ned Deily +- Windows installers: Steve Dower +- Mac installers: Ned Deily +- Documentation: Georg Brandl + + +Release Schedule + + +The releases: + +- 3.6.0 alpha 1: TBD +- 3.6.0 beta 1: TBD +- 3.6.0 candidate 1: TBD +- 3.6.0 final: TBD (late 2016?) + +(Beta 1 is also feature freeze--no new features beyond this point.) + + +Features for 3.6 + + +Proposed changes for 3.6: + +* TBD + + +Copyright += + +This document has been placed in the public domain. + + +.. + Local Variables: + mode: indented-text + indent-tabs-mode: nil + sentence-end-double-space: t + fill-column: 70 + coding: utf-8 + End: ___ Python-checkins mailing list python-check...@python.org https://mail.python.org/mailman/listinfo/python-checkins ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RM for 3.6?
Barry Warsaw schrieb am 01.06.2015 um 20:07: On May 30, 2015, at 10:09 AM, Serhiy Storchaka wrote: Isn't it a time to assign release manager for 3.6-3.7? Indeed! Please welcome Ned Deily as RM for 3.6: https://www.python.org/dev/peps/pep-0494/ Does he know already? Stefan ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RM for 3.6?
On Jun 1, 2015, at 11:33, Benjamin Peterson benja...@python.org wrote: On Mon, Jun 1, 2015, at 14:24, Stefan Behnel wrote: Barry Warsaw schrieb am 01.06.2015 um 20:07: On May 30, 2015, at 10:09 AM, Serhiy Storchaka wrote: Isn't it a time to assign release manager for 3.6-3.7? Indeed! Please welcome Ned Deily as RM for 3.6: https://www.python.org/dev/peps/pep-0494/ Does he know already? The suck^H^H^H^H man even volunteered! I thought I was volunteering to get a pony. I was misinformed. -- Ned Deily n...@acm.org -- [] ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RM for 3.6?
On May 30, 2015, at 10:09 AM, Serhiy Storchaka wrote: Isn't it a time to assign release manager for 3.6-3.7? Indeed! Please welcome Ned Deily as RM for 3.6: https://www.python.org/dev/peps/pep-0494/ Cheers, -Barry pgpArSFCqg7XM.pgp Description: OpenPGP digital signature ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RM for 3.6?
On Mon, Jun 1, 2015, at 14:24, Stefan Behnel wrote: Barry Warsaw schrieb am 01.06.2015 um 20:07: On May 30, 2015, at 10:09 AM, Serhiy Storchaka wrote: Isn't it a time to assign release manager for 3.6-3.7? Indeed! Please welcome Ned Deily as RM for 3.6: https://www.python.org/dev/peps/pep-0494/ Does he know already? The suck^H^H^H^H man even volunteered! ___ Python-Dev mailing list Python-Dev@python.org 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] peps: We have a 3.6 release PEP.
On Jun 1, 2015, at 11:04, Yury Selivanov yselivanov...@gmail.com wrote: It looks like we now have two 3.6 release PEPs: 494 495 Sorry about the confusion. The second checkin (for 495) has been reverted; PEP 494 will be the ongoing PEP. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Windows new 3.5 installer: Command line uninstall
On 1 June 2015 at 20:21, Steve Dower steve.do...@microsoft.com wrote: You need the original exe and can pass /uninstall to that. OK, that's cool. Looks like I missed that in the docs. (Checks) Yes, I did :-( Paul ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RM for 3.6?
On Mon, Jun 1, 2015 at 1:35 PM, Ned Deily n...@acm.org wrote: I thought I was volunteering to get a pony. I was misinformed. Ned, Not to worry. I'm sure that by the time 3.6a0 is due, the PSF will be able to scrape together the funds for a pony, perhaps even one with super powers: Skip ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RM for 3.6?
On Tue, Jun 2, 2015 at 5:05 AM, Skip Montanaro skip.montan...@gmail.com wrote: On Mon, Jun 1, 2015 at 1:35 PM, Ned Deily n...@acm.org wrote: I thought I was volunteering to get a pony. I was misinformed. Ned, Not to worry. I'm sure that by the time 3.6a0 is due, the PSF will be able to scrape together the funds for a pony, perhaps even one with super powers: Nice :) I think if someone could create a pic using the Python logo as a cutie mark (sp?), my MLP-obsessed sister would finally have a reason to learn Python. ChrisA ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Windows new 3.5 installer: Command line uninstall
You need the original exe and can pass /uninstall to that. There is an uninstall entry in the registry that uses the cached version of the exe (via Programs and Features), but I don't know why WMI doesn't see it. I'll check that out a bit later. You can uninstall with the web installer exe, and it won't download anything, but the version does have to match exactly. Cheers, Steve Top-posted from my Windows Phone From: Paul Mooremailto:p.f.mo...@gmail.com Sent: 6/1/2015 6:54 To: Python Devmailto:python-dev@python.org Subject: [Python-Dev] Windows new 3.5 installer: Command line uninstall I'm trying to script a command line uninstall of Python 3.5. The new installer has a nice well-documented command line interface, but there's nothing much about how to uninstall. Looking at the installed products, I see get-wmiobject Win32_Product -filter 'name like Python 3.5.0b2%' | select Name Name Python 3.5.0b2 pip Bootstrap (64-bit) Python 3.5.0b2 Development Libraries (64-bit) Python 3.5.0b2 C Runtime (64-bit) Python 3.5.0b2 Tcl/Tk Support (64-bit) Python 3.5.0b2 Standard Library (64-bit) Python 3.5.0b2 Executables (64-bit) Python 3.5.0b2 Core Interpreter (64-bit) Python 3.5.0b2 Launcher (32-bit) Python 3.5.0b2 Documentation (64-bit) Python 3.5.0b2 Utility Scripts (64-bit) Python 3.5.0b2 Test Suite (64-bit) Normally I'd be able to call the Uninstall method on the installed product, but here, I'm not sure which of the above I'd call Uninstall on (there's only one Programs and Features entry for 3.5, and I can't tell which of these is equivalent to it - or if I need to uninstall each in turn, I don't know what order they need to be done in). Specifically (get-wmiobject -query 'select * from Win32_Product where name = Python 2.7.8 (64-bit)').Uninstall() is an automated, command line silent uninstall of Python 2.7.8. What (if anything) would be the equivalent for 3.5.0b2? Paul ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/steve.dower%40microsoft.com ___ Python-Dev mailing list Python-Dev@python.org 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 3 migration status update across some key subcommunities (was Re: 2.7 is here until 2020, please don't call it a waste.)
2015-05-31 16:15 GMT+02:00 Nick Coghlan ncogh...@gmail.com: On 31 May 2015 at 19:07, Ludovic Gasc gml...@gmail.com wrote: About Python 3 migration, I think that one of our best control stick is newcomers, and by extension, Python trainers/teachers. If newcomers learn first Python 3, when they will start to work professionally, they should help to rationalize the Python 3 migration inside existing dev teams, especially because they don't have an interest conflict based on the fact that they haven't written plenty of code with Python 2. 2020 is around the corner, 5 years shouldn't be enough to change the community mind, I don't know. The education community started switching a while back - if you watch Carrie-Anne Philbin's PyCon UK 2014 keynote, one of her requests for the broader Python community was for everyone else to just catch up already in order to reduce student's confusion (she phrased it more politely than that, though). Educators need to tweak examples and exercises to account for a version switch, but that's substantially easier than migrating hundreds of thousands or even millions of lines of production code. About the French article about Python 3 from a teacher on the production field, it's available again: https://translate.google.com/translate?hl=frsl=frtl=enu=http%3A%2F%2Fsametmax.com%2Fpython-3-est-fait-pour-les-nouveaux-venus%2F And yes, if you learn Python 3 first, subsequently encountering Python 2's quirks and cruft is likely to encourage folks that know both versions of the language to start advocating for a version upgrade :) Exactly ;-) After accounting for the Wow, the existing Python 2 install base is even larger than we realised factour, the migration is actually in a pretty good place overall these days. The enterprise crowd really are likely to be the only ones that might need the full remaining 5 years of migration time (and they may potentially have even more time, if they're relying on a commercial redistributor). More than a full-monty toolbox to migrate to Python 3 now available, I've a good hope when I see numbers like this: http://blog.frite-camembert.net/python-survey-2014.html Even if we have a statistical bia because it's only Pythonists who keep an eye on the Python actuality who have answer to this survey, by definition, people who are more aware about Python 3 migration than the average Python user, however, I don't remember exactly the theorem, but I know to diffuse a piece of information inside a community and to be accepted, the most work will be with the first 10%. After 10%, you have enough people to start to invert the network/group effects to keep the previous status. BTW, during PyCON, Guido did a keynote where he noticed that a lot of libraries don't support Python 3 yet, however a lot of famous Python packages are already ported. If about the absolute values, I was agree with him (more or less 5000 Python 3 packages on 55000 of PyPI if I remember), we should maybe do some datamining with PyPI data to have a more precise vision of the situation, for example: 1. Requests with 4195790 of downloads supports Python 3. hikvision, 9 downloads, doesn't support Python 3. It isn't fair to count with the same weight both products. In term of probability, you have more chances in your project to use Requests that use hikvision. If we ponderate each package by the number of download and calculate the percentage, we should have more of less the probability that a lambda project has all dependencies available for Python 3. 2. The acceleration of Python 3 adoption on PyPI: More complicated to calculate that because we need to know when the Python 3 trove classifier has appear on each library metadata. However, I'm pretty sure that we should see an acceleration. And we should be capable to do a prediction for a date range when a majority of Python packages will be available for Python 3. 3. Maybe some other hidden data, maybe Python scientific community should have better ideas. Web frameworks have allowed Python 3 development for a while now, and with Django switching their tutorial to Python 3 by default, Django downloads via pip show one of the highest proportions of Python 3 adoption on PyPI. www.python.org itself is now a production Python 3 Django web service, and the next generation of pypi.python.org will be a Pyramid application that's also running on Python 3. Pretty cool :-) The dedicated async/await syntax in 3.5 represents a decent carrot to encourage migration for anyone currently using yield (or yield from) based coroutines, since the distinct syntax not only allows for easier local reasoning about whether something is an iterator or a coroutine, it also provides a much improved user experience for asynchronous iterators and context managers (including finally handling the asynchronous database transaction as a context manager case, which previous versions of Python couldn't really
Re: [Python-Dev] [python-committers] Ned Deily is release manager for Python 3.6
On 06/01/2015 11:09 AM, Barry Warsaw wrote: Please welcome Ned Deily as RM for Python 3.6. https://www.python.org/dev/peps/pep-0494/ We're in good hands. For two versions now Benjamin and Ned have been quietly cleaning up my mistakes after (nearly) every release. My guess is, Ned won't bother making the mistakes in the first place! //arry/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RM for 3.6?
On 01/06/2015 19:33, Benjamin Peterson wrote: On Mon, Jun 1, 2015, at 14:24, Stefan Behnel wrote: Barry Warsaw schrieb am 01.06.2015 um 20:07: On May 30, 2015, at 10:09 AM, Serhiy Storchaka wrote: Isn't it a time to assign release manager for 3.6-3.7? Indeed! Please welcome Ned Deily as RM for 3.6: https://www.python.org/dev/peps/pep-0494/ Does he know already? The suck^H^H^H^H man even volunteered! Was that volunteered as in RM or the Comfy Chair? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Obtaining stack-frames from co-routine objects
Hi Ben, On 2015-05-31 8:35 AM, Ben Leslie wrote: Hi Yury, I'm just starting my exploration into using async/await; all my 'real-world' scenarios are currently hypothetical. One such hypothetical scenario however is that if I have a server process running, with some set of concurrent connections, each managed by a co-routine. Each co-routine is of some arbitrary complexity e.g: some combination of reading files, reading from database, reading from peripherals. If I notice one of those co-routines appears stuck and not making progress, I'd very much like to debug that, and preferably in a way that doesn't necessarily stop the rest of the server (or even the co-routine that appears stuck). The problem with the if debug: log(...) approach is that you need foreknowledge of the fault state occurring; on a busy server you don't want to just be logging every 'switch()'. I guess you could do something like switch_state[outer_coro] = get_current_stack_frames() on each switch. To me double book-keeping something that the interpreter already knows seems somewhat wasteful but maybe it isn't really too bad. I guess it all depends on how switching is organized in your framework of choice. In asyncio, for instance, all the code that knows about coroutines is in tasks.py. `Task` class is responsible for running coroutines, and it's the single place where you would need to put the if debug: ... line for debugging slow Futures-- the only thing that coroutines can stuck with (the other thing is accidentally calling blocking code, but your proposal wouldn't help with that). Yury ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (2.7): Issue #24357: Change host in socket.getaddrinfo example to one that
On 02.06.15 04:58, ned.deily wrote: https://hg.python.org/cpython/rev/30da21d2fa4f changeset: 96458:30da21d2fa4f branch: 2.7 parent: 96454:5e8fa1b13516 user:Ned Deily n...@acm.org date:Mon Jun 01 18:45:49 2015 -0700 summary: Issue #24357: Change host in socket.getaddrinfo example to one that does support IPv6 and IPv4; www.python.org currently does not. files: Doc/library/socket.rst | 8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/Doc/library/socket.rst b/Doc/library/socket.rst --- a/Doc/library/socket.rst +++ b/Doc/library/socket.rst @@ -262,12 +262,12 @@ method. The following example fetches address information for a hypothetical TCP - connection to ``www.python.org`` on port 80 (results may differ on your + connection to ``google.com`` on port 80 (results may differ on your system if IPv6 isn't enabled):: example.org does support IPv6 and IPv4 too, and is not commercial name. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (2.7): Issue #24357: Change host in socket.getaddrinfo example to one that
On Jun 1, 2015, at 20:46, Serhiy Storchaka storch...@gmail.com wrote: On 02.06.15 04:58, ned.deily wrote: https://hg.python.org/cpython/rev/30da21d2fa4f changeset: 96458:30da21d2fa4f branch: 2.7 parent: 96454:5e8fa1b13516 user:Ned Deily n...@acm.org date:Mon Jun 01 18:45:49 2015 -0700 summary: Issue #24357: Change host in socket.getaddrinfo example to one that does support IPv6 and IPv4; www.python.org currently does not. example.org does support IPv6 and IPv4 too, and is not commercial name. Good suggestion, thanks! -- Ned Deily n...@acm.org -- [] ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RM for 3.6?
On 01.06.15 21:07, Barry Warsaw wrote: On May 30, 2015, at 10:09 AM, Serhiy Storchaka wrote: Isn't it a time to assign release manager for 3.6-3.7? Indeed! Please welcome Ned Deily as RM for 3.6: https://www.python.org/dev/peps/pep-0494/ Good news for all us! Ned many times saved me from mistakes. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
