Re: [Python-Dev] Reminder: Python 3.5 beta 1 will be tagged tomorrow
Is it too late to get the isclose() code (PEP 485) into 3.5? I posted the code here, and got a tiny bit of review, but have not yet merged it into the source tree -- and don't know the process for getting it committed to the official source. So -- too late, or should I try to get that merge done soon -- if so, how? -Chris On Fri, May 22, 2015 at 12:53 PM, Larry Hastings la...@hastings.org wrote: Howdy howdy. It's-a me, Larry, your friendly neighborhood Python 3.5 Release Manager. Somewhere around 2 or 3pm tomorrow I expect to tag Python 3.5 beta 1. We'll actually release beta 1 on Sunday, once the binary installers are all built. Beta 1 is also feature-freeze, meaning no new features may be added to 3.5 without my permission. Since it seems useful to have a specific cutoff time, please stop adding features at ** 8pm Saturday UTC **. (That's 1pm Pacific Daylight Time. It's also almost exactly 24 hours from... now.) I remind you that this time we're trying something new: we're going to create the 3.5 branch when we release beta 1, allowing feature development (for 3.6) to continue in trunk. At the point that I check in and push beta 1, I'll also merge all checkins from trunk back into the 3.5 branch. After that it'll be responsibility of the person checking in to check their bug fixes in to the appropriate place. So please keep in mind: once the 3.5 branch becomes generally available on Sunday, the usual rules for a release branch will apply: bug fixes for 3.5 should be checked in to the 3.5 branch and get merged forward into trunk. If you have new features you want to ship with Python 3.5, please check them in as soon as possible! Thank you for helping to make Python better, */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/chris.barker%40noaa.gov -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ 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] PEP 484 (Type Hints) announcement
Hello all, I am pleased to announce that I am accepting PEP 484 (Type Hints). Given the proximity of the beta release I thought I would get this announcement out now, even though there are some (very) minor details to iron out. (If you want to know the details, it's all at https://github.com/ambv/typehinting) I hope that PEP 484 will be a benefit to all users of Python. I think the proposed annotation semantics and accompanying module are technically sound and I hope that they are socially acceptable to the Python community. I have long been aware that as well as a powerful, sophisticated and production quality language, Python is also used by many casual programmers, and as a language to introduce children to programming. I also realise that this PEP does not look like it will be any help to the part-time programmer or beginner. However, I am convinced that it will enable significant improvements to IDEs (hopefully including IDLE), static checkers and other tools. These tools will then help us all, beginners included. This PEP has been a huge amount of work, involving a lot of people. So thank you to everyone involved. If I were to list names I would inevitably miss someone out. You know who you are. Finally, if you are worried that this will make Python ugly and turn it into some sort of inferior Java, then I share you concerns, but I would like to remind you of another potential ugliness; operator overloading. C++, Perl and Haskell have operator overloading and it gets abused something rotten to produce concise (a.k.a. line noise) code. Python also has operator overloading and it is used sensibly, as it should be. Why? It's a cultural issue; readability matters. Python is your language, please use type-hints responsibly :) Cheers, Mark. ___ 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] PEP 484 (Type Hints) announcement
Thanks Mark! On May 22, 2015 1:52 PM, Mark Shannon m...@hotpy.org wrote: Hello all, I am pleased to announce that I am accepting PEP 484 (Type Hints). Given the proximity of the beta release I thought I would get this announcement out now, even though there are some (very) minor details to iron out. (If you want to know the details, it's all at https://github.com/ambv/typehinting) I hope that PEP 484 will be a benefit to all users of Python. I think the proposed annotation semantics and accompanying module are technically sound and I hope that they are socially acceptable to the Python community. I have long been aware that as well as a powerful, sophisticated and production quality language, Python is also used by many casual programmers, and as a language to introduce children to programming. I also realise that this PEP does not look like it will be any help to the part-time programmer or beginner. However, I am convinced that it will enable significant improvements to IDEs (hopefully including IDLE), static checkers and other tools. These tools will then help us all, beginners included. This PEP has been a huge amount of work, involving a lot of people. So thank you to everyone involved. If I were to list names I would inevitably miss someone out. You know who you are. Finally, if you are worried that this will make Python ugly and turn it into some sort of inferior Java, then I share you concerns, but I would like to remind you of another potential ugliness; operator overloading. C++, Perl and Haskell have operator overloading and it gets abused something rotten to produce concise (a.k.a. line noise) code. Python also has operator overloading and it is used sensibly, as it should be. Why? It's a cultural issue; readability matters. Python is your language, please use type-hints responsibly :) Cheers, Mark. ___ 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/guido%40python.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] Reminder: Python 3.5 beta 1 will be tagged tomorrow
On 05/22/2015 02:29 PM, Chris Barker wrote: Is it too late to get the isclose() code (PEP 485) into 3.5? I posted the code here, and got a tiny bit of review, but have not yet merged it into the source tree -- and don't know the process for getting it committed to the official source. So -- too late, or should I try to get that merge done soon -- if so, how? Posting your plea here is a good start. Hopefully you can find a core dev familiar enough with the issues involved that they can (quickly!) guide it through the process of getting it checked in. Given that this is a new feature I can live with it being checked in at the last minute, as it shouldn't destabilize the build. Still, I would prefer that it was checked in far enough in advance that you can watch the buildbots ( http://buildbot.python.org/all/waterfall?category=3.x.stable ) and maybe even iterate if the checkin causes problems. //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] [python-committers] Can we clean up the buildbots please?
*From:*Larry Hastings [mailto:la...@midwinter.com] *On Behalf Of *Larry Hastings *Sent:* Friday, May 22, 2015 1530 *To:* Steve Dower; Python Dev; python-committers *Cc:* Yury Selivanov; Benjamin Peterson *Subject:* Re: [python-committers] Can we clean up the buildbots please? Is MSVS 2015 the only supported compiler for Python 3.5 on Windows? What's the other buildbot using MSVS 2015? I'll answer my own question here. According to PCbuild/readme.txt: This script will use the env.bat script to detect one of Visual Studio 2015, 2013, 2012, or 2010, any of which may be used to build Python, though only Visual Studio 2015 is officially supported. I'll admit I'm puzzled by the wisdom of using unsupported compilers on buildbots. I guess it's a historical thing. But I gently suggest that we should either upgrade those buildbots to a supported compiler or remove them entirely. Definitely we should remove unsupported the two unsupported platforms from the buildbots--that's just crazy. //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] Accepting PEP 489 (Multi-phase extension module initialization)
Congrats! Many thanks to all who contributed. On May 22, 2015 2:45 PM, Eric Snow ericsnowcurren...@gmail.com wrote: Hi all, After extended discussion over the last several months on import-sig, the resulting proposal for multi-phase (PEP 451) extension module initialization has finalized. The resulting PEP provides a clean, straight-forward, and backward-compatible way to import extension modules using ModuleSpecs. With that in mind and given the improvement it provides, PEP 489 is now accepted. I want to thank Petr, Nick, and Stefan for the time, thought, and effort they put into the proposal (and implementation). It was a disappointment to me when, at the time, we couldn't find a good way to apply PEP 451 to builtins and extension modules. So thanks for easing my anxiety! -eric ___ 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/guido%40python.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] Reminder: Python 3.5 beta 1 will be tagged tomorrow
On Fri, May 22, 2015 at 2:33 PM, Larry Hastings la...@hastings.org wrote: On 05/22/2015 02:29 PM, Chris Barker wrote: Is it too late to get the isclose() code (PEP 485) into 3.5? ... Hopefully you can find a core dev familiar enough with the issues involved that they can (quickly!) guide it through the process of getting it checked in. Ping! Anyone willing to sponsor this? Sorry I waited 'till this late in the game. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ 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-committers] Can we clean up the buildbots please?
The Windows 7 buildbots are failing on test_asdl_parser, but I have no idea why – the test works for me just fine. Yury and Benjamin made the most recent changes to Python.asdl, but I have no idea what effect they would have here, or why it’s Windows only. The WS2K3 machine needs a reboot – I pinged Trent about that months ago – and the XP one isn’t supported for 3.5. Pending the test_asdl_parser fix, I’d also like to see AMD64 Windows 8 (http://buildbot.python.org/all/builders/AMD64%20Windows8%203.x) be promoted to stable, as it’s one of only two currently using the right compiler. Cheers, Steve Coming to PyData Seattle 2015http://conf.pydata.org/seattle2015/? Hosted by Microsoft on our Redmond campus, July 24-26 From: python-committers [mailto:python-committers-bounces+steve.dower=microsoft@python.org] On Behalf Of Larry Hastings Sent: Friday, May 22, 2015 1444 To: Python Dev; python-committers Subject: [python-committers] Can we clean up the buildbots please? Right now we have eight online buildbots for Python trunk. Of those, currently *six* are reporting errors in either the compile or test phases. http://buildbot.python.org/all/waterfall?category=3.x.stable There's one platform (AMD64 Snow Leop) where the failures are sporadic stack overflow errors encountered during the test suite. But the other five platforms have consistent failures, build after build. Those platforms: AMD64 OpenIndiana AMD64 Windows7 SP1 x86 Windows Server 2003 [SB] x86 Windows7 x86 XP-4 That includes *all* of the Windows buildbots. Gosh, it sure would be nice if Beta 1 didn't fail on Windows, wouldn't it? Could some Windows core devs take a look at the failures and see about cleaning them up? Naturally the OpenIndiana and OS X devs are invited to fix the errors on those platforms too, /arry p.s. My apologies for not bringing attention to this sooner. But, well, we still have a day left, right? ___ 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] Reminder: Python 3.5 beta 1 will be tagged tomorrow
On Sat, May 23, 2015 at 12:53 AM, Chris Barker chris.bar...@noaa.gov wrote: On Fri, May 22, 2015 at 2:33 PM, Larry Hastings la...@hastings.org wrote: On 05/22/2015 02:29 PM, Chris Barker wrote: Is it too late to get the isclose() code (PEP 485) into 3.5? ... Hopefully you can find a core dev familiar enough with the issues involved that they can (quickly!) guide it through the process of getting it checked in. Ping! Anyone willing to sponsor this? Hi Chris, Thanks for the PEP and the implementation! You'll get more attention If you open an issue with a patch at bugs.python.org. Having a GitHub repository is good, but the isclose() code(with tests and documentation) needs to be integrated into the CPython code base: * The C implementation should be in Modules/mathmodule.c * Tests should be in Lib/test/test_math.py * Documentation should be in Doc/library/math.rst * Add an entry to Doc/whatsnew/3.5.rst * If I remember correctly, we don't need the Python implementation and its tests --Berker ___ 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] Accepting PEP 489 (Multi-phase extension module initialization)
Hi all, After extended discussion over the last several months on import-sig, the resulting proposal for multi-phase (PEP 451) extension module initialization has finalized. The resulting PEP provides a clean, straight-forward, and backward-compatible way to import extension modules using ModuleSpecs. With that in mind and given the improvement it provides, PEP 489 is now accepted. I want to thank Petr, Nick, and Stefan for the time, thought, and effort they put into the proposal (and implementation). It was a disappointment to me when, at the time, we couldn't find a good way to apply PEP 451 to builtins and extension modules. So thanks for easing my anxiety! -eric ___ 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-committers] Can we clean up the buildbots please?
On 05/22/2015 03:06 PM, Steve Dower wrote: The Windows 7 buildbots are failing on test_asdl_parser, but I have no idea why – the test works for me just fine. Yury and Benjamin made the most recent changes to Python.asdl, but I have no idea what effect they would have here, or why it’s Windows only. The WS2K3 machine needs a reboot – I pinged Trent about that months ago – and the XP one isn’t supported for 3.5. Pending the test_asdl_parser fix, I’d also like to see AMD64 Windows 8 (http://buildbot.python.org/all/builders/AMD64%20Windows8%203.x) be promoted to stable, as it’s one of only two currently using the right compiler. So what you seem to be saying is, the Windows buildbots provide no useful signal and should be ignored? Is MSVS 2015 the only supported compiler for Python 3.5 on Windows? What's the other buildbot using MSVS 2015? //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] [python-committers] Can we clean up the buildbots please?
Two of them are useless (x86 Windows Server 2003 [SB] and x86 XP-4, to be precise), but the fact that everything other than test_asdl_parser passes is a very valuable signal. AMD64 Windows 7 SP1 is also using the correct compiler. Since some of our core developers are yet to upgrade, I’m not against keeping the one VS 2010 buildbot around for now. When MSFT comes up with a better way of getting the compiler than installing 8GB+ of interactive environment, then I’ll be more forceful about it (and yes, I’m helping encourage the relevant teams). Cheers, Steve Coming to PyData Seattle 2015http://conf.pydata.org/seattle2015/? Hosted by Microsoft on our Redmond campus, July 24-26 From: Larry Hastings [mailto:la...@midwinter.com] On Behalf Of Larry Hastings Sent: Friday, May 22, 2015 1530 To: Steve Dower; Python Dev; python-committers Cc: Yury Selivanov; Benjamin Peterson Subject: Re: [python-committers] Can we clean up the buildbots please? On 05/22/2015 03:06 PM, Steve Dower wrote: The Windows 7 buildbots are failing on test_asdl_parser, but I have no idea why – the test works for me just fine. Yury and Benjamin made the most recent changes to Python.asdl, but I have no idea what effect they would have here, or why it’s Windows only. The WS2K3 machine needs a reboot – I pinged Trent about that months ago – and the XP one isn’t supported for 3.5. Pending the test_asdl_parser fix, I’d also like to see AMD64 Windows 8 (http://buildbot.python.org/all/builders/AMD64%20Windows8%203.x) be promoted to stable, as it’s one of only two currently using the right compiler. So what you seem to be saying is, the Windows buildbots provide no useful signal and should be ignored? Is MSVS 2015 the only supported compiler for Python 3.5 on Windows? What's the other buildbot using MSVS 2015? /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
[Python-Dev] Can we clean up the buildbots please?
Right now we have eight online buildbots for Python trunk. Of those, currently *six* are reporting errors in either the compile or test phases. http://buildbot.python.org/all/waterfall?category=3.x.stable There's one platform (AMD64 Snow Leop) where the failures are sporadic stack overflow errors encountered during the test suite. But the other five platforms have consistent failures, build after build. Those platforms: AMD64 OpenIndiana AMD64 Windows7 SP1 x86 Windows Server 2003 [SB] x86 Windows7 x86 XP-4 That includes *all* of the Windows buildbots. Gosh, it sure would be nice if Beta 1 didn't fail on Windows, wouldn't it? Could some Windows core devs take a look at the failures and see about cleaning them up? Naturally the OpenIndiana and OS X devs are invited to fix the errors on those platforms too, //arry/ p.s. My apologies for not bringing attention to this sooner. But, well, we still have a day left, right? ___ 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-committers] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 13.05.15 um 09:59 schrieb Larry Hastings: When you say branch testing, you mean running the buildbots against it? Right now the UI for doing that is pretty clunky. Kicking off a build against a server-side clone (iirc) requires clicking through a couple web pages, filling out a form, and clicking on a teeny-tiny button. It would help *tremendously* here if I could get this automated, so I could run a script locally that made everything happen. Is there a remote API for starting builds? Or existing automation of any kind? Who should I talk to about this stuff? Antoine, or me. For branch builds, it would be better to configure them into the buildbot configuration, instead of trying to force them from the outside. To make this happen, you need to add a repository URL and branch name into the buildbot configuration, and a post-push hook on the repository to trigger the build. It's actually possible to configure a bitbucket POST hook to trigger a buildbot build, but we haven't yet integrated that into the buildbot master. Regards, Martin -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlVfivYACgkQavBT8H2dyNIzCACdG3yHShN/ZEc1sIiOVYj0lcg0 K9IAnjqLCFN+EewBPLfh651wQUq64nun =0j5m -END PGP 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] Accepting PEP 489 (Multi-phase extension module initialization)
On Fri, May 22, 2015 at 11:44 PM, Eric Snow ericsnowcurren...@gmail.com wrote: Hi all, After extended discussion over the last several months on import-sig, the resulting proposal for multi-phase (PEP 451) extension module initialization has finalized. The resulting PEP provides a clean, straight-forward, and backward-compatible way to import extension modules using ModuleSpecs. With that in mind and given the improvement it provides, PEP 489 is now accepted. I want to thank Petr, Nick, and Stefan for the time, thought, and effort they put into the proposal (and implementation). It was a disappointment to me when, at the time, we couldn't find a good way to apply PEP 451 to builtins and extension modules. So thanks for easing my anxiety! Thank you for the thorough review, Eric! Also thanks to everyone involved for insightful discussion, and especially Nick for guiding me through writing my first PEP. Let me know if there's anything more I can (or should -- still my first time) do. I'm off now but I'll be online tomorrow all day (UTC-ish hours). ___ 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] Accepting PEP 489 (Multi-phase extension module initialization)
On May 22, 2015, at 2:52 PM, Guido van Rossum gu...@python.org wrote: Congrats! Many thanks to all who contributed. On May 22, 2015 2:45 PM, Eric Snow ericsnowcurren...@gmail.com wrote: Hi all, After extended discussion over the last several months on import-sig, the resulting proposal for multi-phase (PEP 451) extension module initialization has finalized. The resulting PEP provides a clean, straight-forward, and backward-compatible way to import extension modules using ModuleSpecs. With that in mind and given the improvement it provides, PEP 489 is now accepted. I echo that sentiment. Thank you for your work. Raymond ___ 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-committers] Can we clean up the buildbots please?
On Fri, May 22, 2015 at 10:06:48PM +, Steve Dower wrote: The Windows 7 buildbots are failing on test_asdl_parser, but I have no idea why – the test works for me just fine. Yury and Benjamin made the most recent changes to Python.asdl, but I have no idea what effect they would have here, or why it’s Windows only. The WS2K3 machine needs a reboot – I pinged Trent about that months ago – and the XP one isn’t supported for 3.5. Gave it a little bit of love just then (haven't been able to access it for months as the main switch needed a reboot). There were like, 155 cl.exe processes wedged and a bunch of error reporting dialogs. Do we still support WS2K3? (Can I even install VS 2015 on that? I would have thought not.) Trent. ___ 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-committers] Can we clean up the buildbots please?
On 05/22/2015 05:11 PM, Trent Nelson wrote: Do we still support WS2K3? (Can I even install VS 2015 on that? I would have thought not.) According to PCbuild/readme.txt, no. It says: This directory is used to build CPython for Microsoft Windows NT version 6.0 or higher (Windows Vista, Windows Server 2008, or later) on 32 and 64 bit platforms. //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] [python-committers] Can we clean up the buildbots please?
On Fri, May 22, 2015 at 05:24:53PM -0700, Larry Hastings wrote: On 05/22/2015 05:11 PM, Trent Nelson wrote: Do we still support WS2K3? (Can I even install VS 2015 on that? I would have thought not.) According to PCbuild/readme.txt, no. It says: This directory is used to build CPython for Microsoft Windows NT version 6.0 or higher (Windows Vista, Windows Server 2008, or later) on 32 and 64 bit platforms. Ah, yeah, thought so. Pity, that box is probably the only one that hasn't had any form of hardware failure during its tenure ;-) Tried to get the W2K8 one back up on Monday when I had some remote hands but alas, no luck. Think it has balked HDDs or something. The Solaris 11 AMD64 one Solaris 10 SPARC ones are back up now though and I just cleared out their 700+ build backlogs, FWIW. Trent. ___ 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] Accepting PEP 489 (Multi-phase extension module initialization)
On 23 May 2015 07:45, Eric Snow ericsnowcurren...@gmail.com wrote: Hi all, After extended discussion over the last several months on import-sig, the resulting proposal for multi-phase (PEP 451) extension module initialization has finalized. The resulting PEP provides a clean, straight-forward, and backward-compatible way to import extension modules using ModuleSpecs. With that in mind and given the improvement it provides, PEP 489 is now accepted. I want to thank Petr, Nick, and Stefan for the time, thought, and effort they put into the proposal (and implementation). It was a disappointment to me when, at the time, we couldn't find a good way to apply PEP 451 to builtins and extension modules. So thanks for easing my anxiety! Ah, what a nice way to start my weekend :) Thanks especially to Petr both for writing the PEP itself, and for taking the general ideas Stefan and I originally had and turning them into a real implementation. Cheers, Nick. -eric ___ 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/ncoghlan%40gmail.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] Hello, I am André Freitas :)
On 23 May 2015 01:15, André Freitas p.andrefrei...@gmail.com wrote: Hi there, My name is André Freitas, I'm 22 years old and I live in Portugal (Porto). I'm currently finishing my Masters in Informatics and Computer Science with a thesis in Mining Software Repositories, where I am able to predict defects in Software components: https://github.com/andrefreitas/schwa Oh, nice. I've been intrigued by the MSR conference series since Greg Wilson pointed it out to me at SciPy last year, but haven't had the time to go look at the research myself. I'm a Python developer with 4 years of experience and as a Speaker, did a lot of Python workshops in Engineering Universities. I'm always learning new things and I really love Python (it's my religion)! I have skills in Security, Tests and Quality, Devops, Software Architecture and Engineering, UI/UX and Compilers. I am reading your guidelines and just checking around to see how this mailing list works. Hope to send some patches soon and share some ideas. Excellent! You may want to sign up for the core-mentorship mailing list ( http://pythonmentors.com/), as that's our preferred venue for helping folks get used to core development processes. Cheers, 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
[Python-Dev] PEP 484 (Type Hints) announcement
Mark Shannon writes: Hello all, I am pleased to announce that I am accepting PEP 484 (Type Hints). Congratulations to all concerned! Python is your language, please use type-hints responsibly :) +1 QOTW (not to mention ROTFLMAO) ___ 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] Reminder: Python 3.5 beta 1 will be tagged tomorrow
Howdy howdy. It's-a me, Larry, your friendly neighborhood Python 3.5 Release Manager. Somewhere around 2 or 3pm tomorrow I expect to tag Python 3.5 beta 1. We'll actually release beta 1 on Sunday, once the binary installers are all built. Beta 1 is also feature-freeze, meaning no new features may be added to 3.5 without my permission. Since it seems useful to have a specific cutoff time, please stop adding features at ** 8pm Saturday UTC **. (That's 1pm Pacific Daylight Time. It's also almost exactly 24 hours from... now.) I remind you that this time we're trying something new: we're going to create the 3.5 branch when we release beta 1, allowing feature development (for 3.6) to continue in trunk. At the point that I check in and push beta 1, I'll also merge all checkins from trunk back into the 3.5 branch. After that it'll be responsibility of the person checking in to check their bug fixes in to the appropriate place. So please keep in mind: once the 3.5 branch becomes generally available on Sunday, the usual rules for a release branch will apply: bug fixes for 3.5 should be checked in to the 3.5 branch and get merged forward into trunk. If you have new features you want to ship with Python 3.5, please check them in as soon as possible! Thank you for helping to make Python better, //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] Tracker reviews look like spam
There's an issue about this at http://psf.upfronthosting.co.za/roundup/meta/issue562 I believe the problem is not that of the SPF, but the fact that mail gets sent using IPv6 from an address that has neither a name mapping to it nor a reverse pointer from IP address to name in DNS. See the second-first comment where R. David Murray states that Mail is consistently sent from rep...@bugs.python.org, always from the same IP address, 46.4.197.70. 46.4.197.70 resolves to bugs.python.org., which clearly is false. On 13 May 2015 at 08:20, Chris Angelico ros...@gmail.com wrote: On Wed, May 13, 2015 at 8:15 AM, David Wilson dw+python-...@hmmz.org wrote: SPF only covers the envelope sender, so it should be possible to set that to something that validates with SPF, keep the RFC822 From: header as it is, and maybe(?) include a separate Sender: header matching the envelope address. As Cameron says, Sender: isn't necessary - just have the envelope address be bounces@ or something and it should be fine. This is how SPF and (eg) mailing lists interact. 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/antti%40haapala.name -- Antti Haapala antti.haap...@iki.fi http://antti.haapala.name/ +358503693535 ___ 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] PEP 484 (Type Hints) -- penultimate(?) draft
Another draft. This is mostly a bunch of clarifications and minor edits, but it also removes the four version/platform constants (PY2, PY3, WINDOWS, POSIX) in favor of asking type checkers to recognize common version checks e.g. using sys.version_info or sys.platform. This time I think the new version *will* appear on python.org. For more frequent updates, watch https://github.com/ambv/typehinting . Also note: I'm probably going to commit the typing.py module to the CPython repo optimistically, while Mark is still pondering his decision. Off-list he's told me he's happy with the PEP. I have to make some changes to typing.py to satisfy him; I won't have time to work on those this afternoon, and I don't want to miss (or hold up) Larry's tagging of the tree for beta 1. So a few things may end up as bugs in the issue tracker ( https://github.com/ambv/typehinting/issues) and I'll rectify those before beta 2. --Guido PEP: 484 Title: Type Hints Version: $Revision$ Last-Modified: $Date$ Author: Guido van Rossum gu...@python.org, Jukka Lehtosalo jukka.lehtos...@iki.fi, Łukasz Langa luk...@langa.pl BDFL-Delegate: Mark Shannon Discussions-To: Python-Dev python-dev@python.org Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 29-Sep-2014 Post-History: 16-Jan-2015,20-Mar-2015,17-Apr-2015,20-May-2015,22-May-2015 Resolution: Abstract PEP 3107 introduced syntax for function annotations, but the semantics were deliberately left undefined. There has now been enough 3rd party usage for static type analysis that the community would benefit from a standard vocabulary and baseline tools within the standard library. This PEP introduces a provisional module to provide these standard definitions and tools, along with some conventions for situations where annotations are not available. Note that this PEP still explicitly does NOT prevent other uses of annotations, nor does it require (or forbid) any particular processing of annotations, even when they conform to this specification. It simply enables better coordination, as PEP 333 did for web frameworks. For example, here is a simple function whose argument and return type are declared in the annotations:: def greeting(name: str) - str: return 'Hello ' + name While these annotations are available at runtime through the usual ``__annotations__`` attribute, *no type checking happens at runtime*. Instead, the proposal assumes the existence of a separate off-line type checker which users can run over their source code voluntarily. Essentially, such a type checker acts as a very powerful linter. (While it would of course be possible for individual users to employ a similar checker at run time for Design By Contract enforcement or JIT optimization, those tools are not yet as mature.) The proposal is strongly inspired by mypy [mypy]_. For example, the type sequence of integers can be written as ``Sequence[int]``. The square brackets mean that no new syntax needs to be added to the language. The example here uses a custom type ``Sequence``, imported from a pure-Python module ``typing``. The ``Sequence[int]`` notation works at runtime by implementing ``__getitem__()`` in the metaclass (but its significance is primarily to an offline type checker). The type system supports unions, generic types, and a special type named ``Any`` which is consistent with (i.e. assignable to and from) all types. This latter feature is taken from the idea of gradual typing. Gradual typing and the full type system are explained in PEP 483. Other approaches from which we have borrowed or to which ours can be compared and contrasted are described in PEP 482. Rationale and Goals === PEP 3107 added support for arbitrary annotations on parts of a function definition. Although no meaning was assigned to annotations then, there has always been an implicit goal to use them for type hinting [gvr-artima]_, which is listed as the first possible use case in said PEP. This PEP aims to provide a standard syntax for type annotations, opening up Python code to easier static analysis and refactoring, potential runtime type checking, and (perhaps, in some contexts) code generation utilizing type information. Of these goals, static analysis is the most important. This includes support for off-line type checkers such as mypy, as well as providing a standard notation that can be used by IDEs for code completion and refactoring. Non-goals - While the proposed typing module will contain some building blocks for runtime type checking -- in particular a useful ``isinstance()`` implementation -- third party packages would have to be developed to implement specific runtime type checking functionality, for example using decorators or metaclasses. Using type hints for performance optimizations is left as an exercise for the reader. It should also be emphasized that **Python will remain a dynamically typed language, and the authors have no desire to
[Python-Dev] Hello, I am André Freitas :)
Hi there, My name is André Freitas, I'm 22 years old and I live in Portugal (Porto). I'm currently finishing my Masters in Informatics and Computer Science with a thesis in Mining Software Repositories, where I am able to predict defects in Software components: https://github.com/andrefreitas/schwa I'm a Python developer with 4 years of experience and as a Speaker, did a lot of Python workshops in Engineering Universities. I'm always learning new things and I really love Python (it's my religion)! I have skills in Security, Tests and Quality, Devops, Software Architecture and Engineering, UI/UX and Compilers. I am reading your guidelines and just checking around to see how this mailing list works. Hope to send some patches soon and share some ideas. Feel free to follow me on Github https://github.com/andrefreitas Best regards, André Freitas. ___ 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] Status of PEP 484 and the typing module
On Fri, May 22, 2015 at 9:45 AM, Jim J. Jewett jimjjew...@gmail.com wrote: Mark Shannon wrote: PY2, etc. really need to go. Assuming that this code type checks OK: if typing.PY2: type_safe_under_py2_only() else: type_safe_under_py3_only() Is the checker supposed to pass this: if sys.hexversion 0x0300: type_safe_under_py2_only() else: type_safe_under_py3_only() If it should pass, then why have PY2, etc. at all. My immediate response was that there really is a difference, when doing the equivalent of cross-compilation. It would help to make this explicit in the PEP. That seems obvious. There's no reason why a type checker should care about what sys.*version* is in the process that runs the type checker (that process may not even be a Python interpreter). But ... If it should fail, well that is just stupid and annoying. so I'm not sure regular authors (as opposed to typing tools) would ever have reason to use it, and making stub files more different from regular python creates an attractive nuisance bigger than the clarification. So in the end, I believe PY2 should merely be part of the calling convention for type tools, and that may not be worth standardizing yet. It *is* worth explaining why they were taken out, though. Because there is no advantage (either to the user or to the type checker) of using e.g. typing.WINDOWS instead of using sys.platform == win32. And it is worth saying explicitly that typing tools should override the sys module when checking for non-native environments. OK, I am saying it here. People writing type checkers can decide for themselves what they want to support. (It is already the case that mypy can check code for conformance with various Python versions, but mypy itself must always run in Python 3.4 or later.) -- --Guido van Rossum (python.org/~guido) ___ 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] Status of PEP 484 and the typing module
Mark Shannon wrote: PY2, etc. really need to go. Assuming that this code type checks OK: if typing.PY2: type_safe_under_py2_only() else: type_safe_under_py3_only() Is the checker supposed to pass this: if sys.hexversion 0x0300: type_safe_under_py2_only() else: type_safe_under_py3_only() If it should pass, then why have PY2, etc. at all. My immediate response was that there really is a difference, when doing the equivalent of cross-compilation. It would help to make this explicit in the PEP. But ... If it should fail, well that is just stupid and annoying. so I'm not sure regular authors (as opposed to typing tools) would ever have reason to use it, and making stub files more different from regular python creates an attractive nuisance bigger than the clarification. So in the end, I believe PY2 should merely be part of the calling convention for type tools, and that may not be worth standardizing yet. It *is* worth explaining why they were taken out, though. And it is worth saying explicitly that typing tools should override the sys module when checking for non-native environments. -jJ -- If there are still threading problems with my replies, please email me with details, so that I can try to resolve them. -jJ ___ 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] Summary of Python tracker Issues
ACTIVITY SUMMARY (2015-05-15 - 2015-05-22)
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:
open4833 ( -7)
closed 31194 (+71)
total 36027 (+64)
Open issues with patches: 2219
Issues opened (40)
==
#24147: Dialect class defaults are not documented.
http://bugs.python.org/issue24147 reopened by r.david.murray
#24203: Depreciate threading.Thread.isDaemon etc
http://bugs.python.org/issue24203 opened by anon
#24204: string.strip() documentation is misleading
http://bugs.python.org/issue24204 opened by PhoenixofMT
#24206: Issues with equality of inspect objects
http://bugs.python.org/issue24206 opened by serhiy.storchaka
#24207: Argument Clinic doesn't mangle conflicting names
http://bugs.python.org/issue24207 opened by serhiy.storchaka
#24209: Allow IPv6 bind in http.server
http://bugs.python.org/issue24209 opened by Link Mauve
#24212: Idle, 2.7, backport idlelib.__main__, enable py -m idlelib
http://bugs.python.org/issue24212 opened by terry.reedy
#24214: Exception with utf-8, surrogatepass and incremental decoding
http://bugs.python.org/issue24214 opened by RalfM
#24215: test_trace uses test_pprint
http://bugs.python.org/issue24215 opened by serhiy.storchaka
#24217: O_RDWR undefined in mmapmodule.c
http://bugs.python.org/issue24217 opened by Jeffrey.Armstrong
#24219: Repeated integer in Lexical analysis/Integer literals section
http://bugs.python.org/issue24219 opened by vlth
#24224: test_msilib is inadequate
http://bugs.python.org/issue24224 opened by zach.ware
#24225: Idlelib: changing file names
http://bugs.python.org/issue24225 opened by Al.Sweigart
#24228: Interpreter triggers segmentation fault at the starting
http://bugs.python.org/issue24228 opened by mdootb
#24229: pathlib.Path should have a copy() method
http://bugs.python.org/issue24229 opened by jshholland
#24230: tempfile.mkdtemp() doesn't work with bytes paths
http://bugs.python.org/issue24230 opened by durin42
#24231: os.makedirs('/', exist_ok=True) fails on Darwin
http://bugs.python.org/issue24231 opened by mew
#24234: Should we define complex.__complex__ and bytes.__bytes__?
http://bugs.python.org/issue24234 opened by gvanrossum
#24235: ABCs don't fail metaclass instantiation
http://bugs.python.org/issue24235 opened by Devin Jeanpierre
#24238: Avoid entity expansion attacks in Element Tree
http://bugs.python.org/issue24238 opened by vadmium
#24239: Allow to configure which gpg to use in distutils upload
http://bugs.python.org/issue24239 opened by ced
#24241: webbrowser default browser detection and/or public API for _tr
http://bugs.python.org/issue24241 opened by daves
#24243: behavior for finding an empty string is inconsistent with docu
http://bugs.python.org/issue24243 opened by swanson
#24244: Python exception on strftime with %f on Python 3 and Python 2
http://bugs.python.org/issue24244 opened by MajeedArni
#24247: unittest discover does modify sys.path
http://bugs.python.org/issue24247 opened by redixin
#24249: unittest API for detecting test failure in cleanup/teardown
http://bugs.python.org/issue24249 opened by r.david.murray
#24251: Different behavior for argparse between 2.7.8 and 2.7.9 when a
http://bugs.python.org/issue24251 opened by hhuang
#24252: IDLE removes elements from tracebacks.
http://bugs.python.org/issue24252 opened by ppperry
#24253: pydoc for namespace packages indicates FILE as built-in
http://bugs.python.org/issue24253 opened by Antony.Lee
#24254: Make class definition namespace ordered by default
http://bugs.python.org/issue24254 opened by eric.snow
#24255: Replace debuglevel-related logic with logging
http://bugs.python.org/issue24255 opened by demian.brecht
#24256: threading.Timer is not a class
http://bugs.python.org/issue24256 opened by jrunyon
#24258: BZ2File objects do not have name attribute
http://bugs.python.org/issue24258 opened by jojko.sivek
#24259: tar.extractall() does not recognize unexpected EOF
http://bugs.python.org/issue24259 opened by Thomas Güttler
#24260: TabError behavior doesn't match documentation
http://bugs.python.org/issue24260 opened by abacabadabacaba
#24261: Add a command line flag to suppress default signal handlers
http://bugs.python.org/issue24261 opened by abacabadabacaba
#24263: Why VALID_MODULE_NAME in unittest/loader.py is r'[_a-z]\w*\.py
http://bugs.python.org/issue24263 opened by sih4sing5hong5
#24264: imageop Unsafe Arithmetic
http://bugs.python.org/issue24264 opened by JohnLeitch
#24265: IDLE produces error message when run with both -s and -c.
http://bugs.python.org/issue24265 opened by ppperry
#24266: raw_input function (with readline): Ctrl+C (during search mode
http://bugs.python.org/issue24266 opened by sping
Most recent 15 issues with no replies (15)
==
#24266: raw_input function
Re: [Python-Dev] Status of PEP 484 and the typing module
At Thu May 21 22:27:50 CEST 2015, Guido wrote: I want to encourage users to think about annotations as types, and for most users the distinction between type and class is too subtle, So what is the distinction that you are trying to make? That a type refers to a variable (name), and a class refers to a piece of data (object) that might be bound to that name? Whatever the intended distinction is, please be explicit in the PEP, even if you decide to paper it over in normal code. For example, the above distinction would help to explain why the typing types can't be directly instantiated, since they aren't meant to refer to specific data. (They can still be used as superclasses because practicality beats purity, and using them as a marker base class is practical.) -jJ -- If there are still threading problems with my replies, please email me with details, so that I can try to resolve them. -jJ ___ 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] Status of PEP 484 and the typing module
On Fri, May 22, 2015 at 10:23 AM, Jim J. Jewett jimjjew...@gmail.com wrote: At Thu May 21 22:27:50 CEST 2015, Guido wrote: I want to encourage users to think about annotations as types, and for most users the distinction between type and class is too subtle, So what is the distinction that you are trying to make? That a type refers to a variable (name), and a class refers to a piece of data (object) that might be bound to that name? Sort of. But really a type is something in the mind of the type checker (or the programmer) while the class is a concept that can be inspected at runtime. Whatever the intended distinction is, please be explicit in the PEP, even if you decide to paper it over in normal code. For example, the above distinction would help to explain why the typing types can't be directly instantiated, since they aren't meant to refer to specific data. (They can still be used as superclasses because practicality beats purity, and using them as a marker base class is practical.) There will have to be documentation and tutorials beyond the PEP. The PEP mostly defines a standard to be used by people implementing type checkers. -- --Guido van Rossum (python.org/~guido) ___ 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
