Re: [Python-Dev] Python 2.7 patch levels turning two digit
On Jun 23, 2014, at 04:20 PM, Donald Stufft wrote:>At the risk of getting Guido to post his slide again, I still think the>solution to the old compiler is to just roll a 2.8 with minimal changes. No. It's not going to happen, for all the reasons discussed previously. Python 2.8 is not a soluti
Re: [Python-Dev] Python 2.7 patch levels turning two digit
On Jun 23, 2014, at 05:15 PM, Donald Stufft wrote:>Normally when I see someone suggest that switching compilers>in 2.7.x is likely to be less work than releasing a 2.8 It normally>appears to me they haven’t looked at the impact on the packaging>tooling. Just to be clear, releasing a Python 2.
Re: [Python-Dev] Python 2.7 patch levels turning two digit
On Jun 23, 2014, at 05:28 PM, Donald Stufft wrote:>Can you clarify? What support guarantees will we make about Python 2.8? Will it be supported as long as Python 2.7? Longer? Will we now have two long-term support versions or change *years* of expectations that users should transition off of
Re: [Python-Dev] sum(...) limitation
On Aug 10, 2014, at 05:24 PM, Stephen J. Turnbull wrote:>Actually ... if I were a fan of the "".join() idiom, I'd seriously>propose 0.sum(numeric_iterable) as the RightThang{tm]. Then we could>deprecate "".join(string_iterable) in favor of "".sum(string_iterable)>(with the same efficient sema
Re: [Python-Dev] class Foo(object) vs class Foo: should be clearly explained in python 2 and 3 doc
On Aug 10, 2014, at 11:51 AM, Alexander Belopolsky wrote:>This is not true. An alternative is to put>>__metaclass__ = type>>at the top of your module to make all classes in your module new-style in>python2. I like this much better, and it's what I do in my own bilingual code. It makes it
Re: [Python-Dev] PEP 4000 to explicitly declare we won't be doing a Py3k style compatibility break again?
On Aug 16, 2014, at 07:43 PM, Guido van Rossum wrote:>(Don't understand this to mean that we should never deprecate things.>Deprecations will happen, they are necessary for the evolution of any>programming language. But they won't ever hurt in the way that Python 3>hurt.) It would be useful t
Re: [Python-Dev] Fwd: PEP 467: Minor API improvements for bytes & bytearray
I think the biggest API "problem" is that default iteration returns integers instead of bytes. That's a real pain. I'm not sure .iterbytes() is the best name for spelling iteration over bytes instead of integers though. Given that we can't change __iter__(), I personally would perhaps prefer a s
Re: [Python-Dev] Fwd: PEP 467: Minor API improvements for bytes & bytearray
On Aug 18, 2014, at 08:48 AM, Nick Coghlan wrote:>Calling it bytes is too confusing:>>for x in bytes(data):> ...>>for x in bytes(data).bytes()>>When referring to bytes, which bytes do you mean, the builtin or the method?>>iterbytes() isn't especially attractive as a method
Re: [Python-Dev] Fwd: PEP 467: Minor API improvements for bytes & bytearray
On Aug 18, 2014, at 09:12 AM, Nick Coghlan wrote:>I'm talking more generally - do you *really* want to be explaining that>"bytes" behaves like a tuple of integers, while "bytes.bytes" behaves like>a tuple of bytes? I would explain it differently though, using concrete examples. data = byt
Re: [Python-Dev] Fwd: PEP 467: Minor API improvements for bytes & bytearray
On Aug 18, 2014, at 10:08 AM, Nick Coghlan wrote:>There's actually another aspect to your idea, independent of the naming:>exposing a view rather than just an iterator. I'm going to have to look at>the implications for memoryview, but it may be a good way to go (and would>align with the iterat
Re: [Python-Dev] PEP 467: Minor API improvements for bytes & bytearray
On Aug 17, 2014, at 09:39 PM, Antoine Pitrou wrote:>> need for a special case for a single byte. We already have a perfectly>> good spelling:>> NUL = bytes([0])>>That is actually a very cumbersome spelling. Why should I first create a>one-element list in order to create a one-byte bytes
Re: [Python-Dev] PEP 4000 to explicitly declare we won't be doing a Py3k style compatibility break again?
On Aug 17, 2014, at 06:02 PM, Guido van Rossum wrote:>I'm unsure about what's the single biggest pain moving to Python 3. In the>past I would have said that it's for sure the bytes/str split (which both>the biggest pain and the biggest payoff).>>But if I look carefully into the soul of teams
Re: [Python-Dev] Fwd: PEP 467: Minor API improvements for bytes & bytearray
On Aug 17, 2014, at 09:48 PM, Donald Stufft wrote:>from __future__ import bytesdoneright? :D Synonymous to: bytes = bytesdoneright or maybe from bytesdoneright import bytes :) -Barry ___ Python-Dev mailing list [email protected] https://mail.p
Re: [Python-Dev] PEP 476: Enabling certificate validation by default!
On Aug 30, 2014, at 12:19 PM, M.-A. Lemburg wrote:>The reasoning here is the same as for hash randomization. There>are cases where you want to test your application using self-signed>certificates which don't validate against the system CA root list.>>In those cases, you do know what you're do
Re: [Python-Dev] Proposed schedule for 3.4.2
On Sep 08, 2014, at 10:44 AM, Alex Gaynor wrote:>*Shifts uncomfortably* it looks like presently there's not a good way to>change anything about the SSL configuration for urllib.request.urlopen. It>does not take a `context` argument, as the http.client API does:>https://docs.python.org/3/librar
Re: [Python-Dev] Proposed schedule for 3.4.2
On Sep 09, 2014, at 08:20 AM, Nick Coghlan wrote:>We could actually make it an "official" hack:>>import urllib.request>urllib.request.urlopen = urllib.request._unverified_urlopen>>Or else the user can just change the code to call the unverified one>directly.>>All we'd have to do i
Re: [Python-Dev] Adding numbering to PEP 20, the Zen of Python
On Sep 18, 2014, at 08:46 PM, Tim Peters wrote:>See Revelation 22:18. Adding numbers is how heresy begins ;-) Thus Spake Timbot -Barry ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe:
Re: [Python-Dev] PEP 394 - Clarification of what "python" command should invoke
On Sep 19, 2014, at 03:31 AM, Bohuslav Kabrda wrote:>as Fedora is getting closer to having python3 as a default, I'm being more>and more asked by Fedora users/contributors what'll "/usr/bin/python" invoke>when we achieve this (Fedora 22 hopefully). So I was rereading PEP 394 and I>think I need
[Python-Dev] 3.5 release schedule PEP
Hi Larry, I think we need a Python 3.5 Release Schedule PEP. Cheers, -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.pytho
Re: [Python-Dev] PEP 394 - Clarification of what "python" command should invoke
On Sep 19, 2014, at 10:23 AM, Donald Stufft wrote:>My biggest problem with ``python3``, is what happens after 3.9. FWIW, 3.9 by my rough calculation is 7 years away.>I know Guido doesn’t particularly like two digit version numbers and it’s>been suggested on this list that instead of 3.10 we’r
Re: [Python-Dev] PEP 394 - Clarification of what "python" command should invoke
On Sep 19, 2014, at 08:40 AM, Guido van Rossum wrote:>Until I say so. Which will happen in the distant future. I'm gonna hid your time machine keys so you didn't find them. -Barry ___ Python-Dev mailing list [email protected] https://mail.python.o
Re: [Python-Dev] shebang policy, and pip
On Oct 08, 2014, at 08:20 AM, Donald Stufft wrote:>Some editors can use shebang lines to control syntax highlighting or linting>(mine for example will lint different for python2 vs python3 shebangs). Some editors can also use `# -*- foo -*-` comments to set up editing modes and there are other
Re: [Python-Dev] isinstance() on old-style classes in Py 2.7
On Oct 21, 2014, at 10:13 AM, Guido van Rossum wrote:>For new code, and whenever you have an opportunity to refactor old code,>you should use new-style classes, by inheriting your class from object (or>from another class that inherits from object). One nice way to do this module-globally is to
Re: [Python-Dev] isinstance() on old-style classes in Py 2.7
On Oct 21, 2014, at 11:22 AM, Guido van Rossum wrote:>Hm. I've never been a fan of that. EIBTI and such... Yeah, I just hate seeing `class Foo(object)` in Python 3 and am too lazy to clean up every class definition. ;) YMMV! Cheers, -Barry signature.asc Description: PGP signature ___
Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?
On Nov 21, 2014, at 10:36 PM, Nick Coghlan wrote:>I'd been taking "must be hosted in PSF infrastructure" as a hard>requirement, but MAL pointed out earlier this evening that in the age>of DVCS's, that requirement may not make sense: if you avoid tightly>coupling your automation to a particular
Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?
On Nov 23, 2014, at 04:49 PM, Nick Coghlan wrote:>Moving from self-hosted Mercurial repos to externally hosted Mercurial>repos is a low risk change. It reduces maintenance overhead and lowers>barriers to external contribution, both without alienating existing>contributors by forcing them to ch
Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?
On Nov 23, 2014, at 08:55 AM, Guido van Rossum wrote:>- Moving from Hg to Git is a fair amount of one-time work For anyone seriously interested in this, even experimentally, I would highly suggest looking at Eric Raymond's reposurgeon code. You can google it or find it covered in the vast discu
Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?
On Nov 23, 2014, at 03:59 PM, Nick Coghlan wrote:>The learning curve on git is still awful What I find so ironic is that git's model is beautifully simple, but its cli is abysmal, and its manpages are less than helpful. git-push(1) is over 650 lines and it's nearly impossible to dig out the mos
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Nov 30, 2014, at 09:54 AM, Ian Cordasco wrote:>- Migrating "data" from GitHub is easy. There are free-as-in-freedom>tools to do it and the only cost is the time it would take to monitor>the process *Extracting* data may be easy, but migrating it is a different story. As the Mailman project
Re: [Python-Dev] Joining the PEP Editors team
On Dec 01, 2014, at 03:54 PM, Chris Angelico wrote:>In response to Guido's call for volunteers, I'm offering myself as a>PEP editor. Who is in charge of this kind of thing? Who manages public>key lists etc? I can add you to the pep editors mailing list. Please send me a off-list message with
Re: [Python-Dev] [Python-checkins] cpython (3.4): - Issue #22966: Fix __pycache__ pyc file name clobber when pyc_compile is
On Dec 02, 2014, at 06:44 AM, Jeremy Kloth wrote:>This test is failing on the Windows buildbots due to the hard-coded>path separator. Using `os.pathsep` should work assuming that>importlib returns normalized paths. Good catch, thanks, however os.path would be the one to use. Here's the patch
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Dec 02, 2014, at 06:21 PM, Brett Cannon wrote:>Well, if I'm going to be the Great Decider on this then I can say upfront>I'm taking a pragmatic view of preferring open but not mandating it,>preferring hg over git but not ruling out a switch, preferring Python-based>tools but not viewing it
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Dec 02, 2014, at 07:20 PM, Brett Cannon wrote:>No because only two people have said they like the experiment idea so>that's not exactly enough to say it's worth the effort. =) Plus GitHub>could be chosen in the end. Experimenting could be useful, although if the traffic is disproportionate
Re: [Python-Dev] Making it possible to accept contributions without CLA (was: My thinking about the development process)
On Dec 09, 2014, at 09:31 AM, Ben Finney wrote:>Rather, I'm asking what, specifically, necessitates this situation.>>What would need to change, for the PSF to accept contributions to the>Python copyrighted works, without requiring the contributor to do>anything but license the work under Apac
Re: [Python-Dev] Making it possible to accept contributions without CLA (was: My thinking about the development process)
On Dec 09, 2014, at 07:42 PM, Nick Coghlan wrote:>A more restricted CLA that limited the PSF's outgoing licence choices to>OSI approved open source licenses might address some of the concerns>without causing problems elsewhere, but the combination of being both>interested in core development a
Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition
On Dec 12, 2014, at 08:07 PM, Petr Viktorin wrote:>If anyone is wondering why their favorite Linux distribution is stuck with>Python 2 – well, I can only speak for Fedora, but nowadays most of what's>left are CPython bindings. No pylint --py3k or 2to3 will help there... It's true that some of
Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition
On Dec 13, 2014, at 12:29 AM, Donald Stufft wrote:>For what it’s worth, I almost exclusively write 2/3 compatible code (and>that’s with the "easy" subset of 2.6+ and either 3.2+ or 3.3+) and doing so>does make the language far less fun for me than when I was writing 2.x only>code. For myself,
Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition
On Dec 14, 2014, at 10:14 AM, Nick Coghlan wrote:>Barry, Petr, any of the other folks working on distro level C extension>ports, perhaps one of you would be willing to consider an update to the C>extension porting guide to be more in line with Brett's latest version of>the Python level porting
Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition
On Dec 16, 2014, at 02:15 PM, Skip Montanaro wrote:>While he doesn't explicitly say so, I got the distinct impression reading>his recent blog post that he supports one source, not forked sources. I've ported a fair bit of code, both pure-Python and C extensions, both libraries and applications.
Re: [Python-Dev] Proposal: Update PEP 1 to allow an explicit "Provisional" status for PEPs
On Dec 18, 2014, at 06:57 AM, Nick Coghlan wrote:>However, I'd be happier if we could communicate that status more>explicitly through the PEP process, especially as I think such a>capability would be useful more generally as we move towards>implementing metadata 2.0 and potentially other enhan
Re: [Python-Dev] Any grammar experts?
On Jan 25, 2015, at 09:31 PM, R. David Murray wrote:>>>> {*x for x in it}>>>>>>>> which is a set comprehension, while the other is a dict comprehension :)>>>>>>> >>> That distinction doesn't bother me -- you might as well claim it's>>> confusing that f(*x) passes positional args
Re: [Python-Dev] Any grammar experts?
On Jan 26, 2015, at 10:55 AM, Ethan Furman wrote:>In the your example>> from_env = {'a': 12}> from_config = {'a': 13}>> f(**from_env, **from_config)>>I would think 'a' should be 13, as from_config is processed /after/ from_env.>>So which is it? In the face of ambiguity, refuse the te
Re: [Python-Dev] (no subject)
On Feb 09, 2015, at 07:46 PM, Neil Girdhar wrote:>Also, regarding calling argument order, not any order is allowed. Regular>arguments must precede other kinds of arguments. Keyword arguments must>precede **-args. *-args must precede **-args. However, I agree with>Antoine that PEP 8 should
Re: [Python-Dev] PEP 441 - Improving Python ZIP Application Support
I'm just now catching up on this thread, so hopefully these thoughts are still relevant. IIRC, the PEP has been scaled back to mostly a convenience around packing an existing directory into a .pyz file, and (on Windows) adding an association for those as executable Python zip file. To the extent
Re: [Python-Dev] PEP 441 - Improving Python ZIP Application Support
On Feb 15, 2015, at 05:15 PM, Petr Viktorin wrote:>So I'd suggest `/usr/bin/env python3` for the default. I really don't want `/usr/bin/env anything`. In general, using /usr/bin/env is a fine tool for developers, but a terrible tool for deployment. It's just too easy for end users to break an
Re: [Python-Dev] PEP 441 - Improving Python ZIP Application Support
On Feb 16, 2015, at 04:16 PM, Paul Moore wrote:>So, the options I see:>>1. Stick with /usr/bin/env python>2. No shebang unless -p is specified>3. Unix users come up with a solution which is the same as the above>for Windows users, but which suits them better. #2 seems to me to be the most r
Re: [Python-Dev] PEP 441 - Improving Python ZIP Application Support
On Feb 15, 2015, at 05:21 PM, Thomas Wouters wrote:>FWIW, we have a similar tool to 'pyzaa' at Google, although a lot older (it>has a pure-python implementation of zipimport, because it had to work with>Python 2.2 back in the day) that *does* support extension modules and other>shared librarie
Re: [Python-Dev] PEP 441 - Improving Python ZIP Application Support
On Feb 16, 2015, at 11:21 PM, Paul Moore wrote:>Default Interpreter>--->>The initial draft of this PEP proposed using ``/usr/bin/env python``>as the default interpreter. The other reasonable alternative for a default shebang is sys.executable. Cheers, -Barry
Re: [Python-Dev] PEP 441 - Improving Python ZIP Application Support
On Feb 17, 2015, at 08:58 PM, Paul Moore wrote:>But I would say that anything that is added to zipimport should be>cross-platform. Having support for C extensions in zipimport on Unix>only will just add another way in which Python applications can>inadvertantly be non-portable... (It should be
Re: [Python-Dev] PEP 441 - Improving Python ZIP Application Support
On Feb 17, 2015, at 08:53 PM, Paul Moore wrote: >On 17 February 2015 at 18:56, Barry Warsaw wrote: >>>The initial draft of this PEP proposed using ``/usr/bin/env python`` >>>as the default interpreter. >> >> The other reasonable alternative for a default she
Re: [Python-Dev] PEP 441 - Improving Python ZIP Application Support
On Feb 17, 2015, at 08:52 PM, Paul Moore wrote:>I'm pretty sure that's the way the general feeling is going. Though the more I think about it, the more I like sys.executable. :)>> However, -p must be able to accept any number of strings, including>> "/usr/bin/env python3" if the user wants th
Re: [Python-Dev] PEP 441 - Improving Python ZIP Application Support
On Feb 17, 2015, at 08:44 PM, Paul Moore wrote:>I'd like to see a good single-file bundled application format for>Python (on Windows, there's py2exe, which is fantastic, but often I>simply don't *want* to bundle Python and the stdlib with my code). I agree, for deployment to environments where
Re: [Python-Dev] PEP 441 - Improving Python ZIP Application Support
On Feb 17, 2015, at 01:25 PM, Ethan Furman wrote: >On 02/17/2015 01:13 PM, Barry Warsaw wrote: > >> There are lots of interesting use cases we could still support. I could >> build a single-file application and deploy it into my OS's system archives. >> I co
Re: [Python-Dev] PEP 441 - Improving Python ZIP Application Support
On Feb 17, 2015, at 09:52 PM, Paul Moore wrote:>I see no problem with either having zipapp develop into a much>fuller-featured solution, or having an externally developed tool>brought into the stdlib and replacing zipapp. I just don't think>there's anything mature enough for that role out ther
Re: [Python-Dev] PEP 441 - Improving Python ZIP Application Support
On Feb 17, 2015, at 09:45 PM, Paul Moore wrote:>If Python zip applications got the ability to include binary extensions, they>would *definitely* not be portable (we don't want to go down the route of>wheel-like compatibility tags for an application file format). Agreed!>Currently, I'm trying
Re: [Python-Dev] PEP 441 - Improving Python ZIP Application Support
On Feb 18, 2015, at 09:16 PM, Paul Moore wrote:>That covers mime types, but not file extensions, so it's not really>what *I* thought Barry was talking about. I was actually thinking about both. :) The Wikipedia page has several external links to collections of file extensions, but I don't know
Re: [Python-Dev] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support
On Feb 24, 2015, at 08:20 PM, Paul Moore wrote:>(side note: --python/-p or --interpreter/-i?) and set the entry point, Both virtualenv and (I think) pex use --python/-p so that seems to be the overwhelming trend .>To modify an archive could be done using>>python -m zipapp old.pyz new.pyz
Re: [Python-Dev] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support
On Feb 25, 2015, at 07:33 PM, Paul Moore wrote:>The module defines two convenience functions:>>>.. function:: create_archive(directory, target=None, interpreter=None,>main=None)>> Create an application archive from *source*. The source can be any> of the following: I think you meant
Re: [Python-Dev] PEP 488: elimination of PYO files
On Mar 07, 2015, at 12:30 PM, Scott Dial wrote:>As a packager, this PEP is a bit silent on it's expectations about what>will happen with (for instance) Debian and Fedora packages for Python.>My familiarity is with Fedora, and on that platform, we ship .pyc and>.pyo files (using -O for the .pyo
Re: [Python-Dev] Use ptyhon -s as default shbang for system python executables/daemons
On Mar 18, 2015, at 03:46 PM, Orion Poplawski wrote:>We're starting a discussion in Fedora about setting the default shbang for>system python executables and/or daemons to python -s or python -Es (or ?). We've talked about this in Debian/Ubuntu land and the general consensus is that for Python
Re: [Python-Dev] Use ptyhon -s as default shbang for system python executables/daemons
On Mar 18, 2015, at 05:31 PM, Victor Stinner wrote:>Does it work to pass command line options to Python in the shebang? Yes, but only one "word", thus -Es or -I. We've often mused about whether it makes sense to have two Pythons on the system. One for system scripts and another for users. Sys
Re: [Python-Dev] Use ptyhon -s as default shbang for system python executables/daemons
On Mar 18, 2015, at 02:44 PM, Toshio Kuratomi wrote:>Interesting, I've cautiously in favor of -s in Fedora but the more I've>thought about it the less I've liked -E. It just seems like PYTHONPATH is>analagous to LD_LIBRARY_PATH for C programs and PATH for shell scripting.>We leave both of tho
Re: [Python-Dev] Use ptyhon -s as default shbang for system python executables/daemons
On Mar 18, 2015, at 05:51 PM, Donald Stufft wrote:>I’ve long wished that the OS had it’s own virtual environment. A lot of>problems seems to come from trying to cram the things the OS wants with the>things that the user wants into the same namespace. Yep, and those breakages can be difficult t
Re: [Python-Dev] Use ptyhon -s as default shbang for system python executables/daemons
On Mar 19, 2015, at 11:15 AM, Toshio Kuratomi wrote:>I could see that as a difference. However, the environment variables>give users the ability to change things globally whereas overriding>the shebang line is case-by-case so it's not a complete replacement>of the functionality. You make so
Re: [Python-Dev] some minor questions about pep8
On Mar 20, 2015, at 08:53 PM, Guido van Rossum wrote:>FWIW, I think __version__, __author__ etc. were bad ideas. Almost nobody>manages these correctly. Note that the PEP 8 section starts with less than>an endorsement: "If you *have* to have Subversion, CVS, or RCS crud in your>source file, do
Re: [Python-Dev] some minor questions about pep8
On Mar 20, 2015, at 09:59 PM, Ian Lee wrote:>shebang>docstring>imports>dunder assignments>other code... I generally put imports after dunders, except for __future__. I want the first screenful of code to contain them, and imports can be a few dozen lines in some modules. -Barry ___
Re: [Python-Dev] some minor questions about pep8
On Mar 21, 2015, at 05:00 PM, Donald Stufft wrote:>I sort of think (though I haven’t completely convinced myself) that adding>something like __version__ to a package is a work around to the fact that>we don’t have an API that lets someone ask "what is the distribution and>version that this mod
Re: [Python-Dev] [python-committers] Do we need to sign Windows files with GnuPG?
On Apr 03, 2015, at 02:56 AM, Larry Hastings wrote:>My Windows development days are firmly behind me. So I don't really have an>opinion here. So I put it to you, Windows Python developers: do you care>about GnuPG signatures on Windows-specific files? Or do you not care? They're not mutually
Re: [Python-Dev] [python-committers] Do we need to sign Windows files with GnuPG?
On Apr 04, 2015, at 02:41 PM, Steve Dower wrote:>"Relying only on Authenticode for Windows installers would result in a break>in technology w/r to the downloads we make available for Python, since all>other files are (usually) GPG signed" It's the "only" part I have a question about. Does the
Re: [Python-Dev] PEP 8 update
On Apr 06, 2015, at 06:08 PM, Guido van Rossum wrote:>I've taken the liberty of adding the following old but good rule to PEP 8>(I was surprised to find it wasn't already there since I've lived by this>for ages):>> Be consistent in return statements. Either all return statements in a> fu
Re: [Python-Dev] Surely "nullable" is a reasonable name?
On Apr 19, 2015, at 01:19 AM, Larry Hastings wrote:>We should rename "types" to "accept". "accept" should takes a set of types;>these types specify the types of Python objects the Clinic parameter should>accept. For the funny pseudo-types needed in some Clinic declarations>("buffer", "robuff
Re: [Python-Dev] Type hints -- a mediocre programmer's reaction
On Apr 20, 2015, at 07:30 PM, Harry Percival wrote:>tldr; type hints in python source are scary. Would reserving them for stub>files be better? I think so. I think PEP 8 should require stub files for stdlib modules and strongly encourage them for 3rd party code. Cheers, -Barry ___
Re: [Python-Dev] Type hints -- a mediocre programmer's reaction
On Apr 21, 2015, at 01:34 PM, Steven D'Aprano wrote:>Putting the type information in a stub file is an exponentially more distant>fourth best, or to put it another way, *the worst* solution for where to put>type hints. Not only do you Repeat Yourself with the name of the parameter,>but also th
Re: [Python-Dev] async/await in Python; v2
On Apr 21, 2015, at 01:26 PM, Yury Selivanov wrote:>The updated version of the PEP should be available shortly at>https://www.python.org/dev/peps/pep-0492 and is also pasted in this email. There's a lot to like about PEP 492. I only want to mildly bikeshed a bit on the proposed new syntax. Wh
Re: [Python-Dev] async/await in Python; v2
On Apr 23, 2015, at 02:02 PM, Yury Selivanov wrote:>To my eye 'async def name()', 'async with', 'async for' look>better than 'def async name()', 'with async' and 'for async'.>But that's highly subjective. Would you be willing to add this as an alternative to the PEP, under the "Why async def"
Re: [Python-Dev] async/await in Python; v2
On Apr 24, 2015, at 11:17 PM, Steven D'Aprano wrote:>It seems to me that tools that search for r"^\s*def\s+spam\s*\(" are They would likely search for something like r"^\s*def\s+[a-zA-Z0-9_]+" which will hit "def async spam" but not "async def". Cheers, -Barry __
Re: [Python-Dev] async/await in Python; v2
On Apr 24, 2015, at 08:03 PM, Greg Ewing wrote:>Putting it at the end would seem least likely to>cause breakage:>>def useful() async: That's not bad IMHO. I wonder how crazy it is in the face of, ahem, function annotations. Cheers, -Barry ___
Re: [Python-Dev] A macro for easier rich comparisons
On Apr 28, 2015, at 11:13 AM, Victor Stinner wrote:>It would be nice to have a six module for C extensions. I'm quite sure>that many projects are already full of #ifdef PYTHON3 ... #else ...>#endif macros. Maybe encapsulating some of the recommendations here: https://wiki.python.org/moin/Port
Re: [Python-Dev] [python-committers] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)
On May 12, 2015, at 10:38 AM, Larry Hastings wrote:>It doesn't. Workflows 0 and 2 mean no public development of 3.6 until after>3.5.0 final ships, as per tradition. I still think it's a good idea to focus primarily on 3.5 while it's in the beta/rc period, but if you want to allow for landings
Re: [Python-Dev] PEP 553: Built-in debug()
On Sep 6, 2017, at 23:10, Terry Reedy wrote:> > Environmental variables are set to strings, not objects. It is not clear how > you intend to handle the conversion. The environment variable names a module import path. Without quibbling about the details of the syntax (because honestly, I’m n
Re: [Python-Dev] PEP 553: Built-in debug()
On Sep 7, 2017, at 07:46, Guido van Rossum wrote:> Without following all this (or the PEP, yet) super exactly, does this mean > you are satisfied with what the PEP currently proposes or would you like > changes? It's a little unclear from what you wrote. I’m also unsure whether Terry is good
Re: [Python-Dev] PEP 553: Built-in debug()
On Sep 7, 2017, at 10:00, Christian Heimes wrote:> Setuptools' entry points [1] use colon between import and function, e.g.> "pdb:set_trace" would import pdb and then execute set_trace. The> approach can be augmented to allow calling a class method, too.> > So> > "package.module:myclass.c
[Python-Dev] PEP 553 V2 - builtin breakpoint() (was Re: PEP 553: Built-in debug())
. Cheers, -Barry PEP: 553 Title: Built-in breakpoint() Author: Barry Warsaw Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 2017年09月05日 Python-Version: 3.7 Post-History: 2017年09月05日, 2017年09月07日 Abstract This PEP proposes adding a new built-in function called ``breakpoint
Re: [Python-Dev] PEP 553: Built-in debug()
On Sep 7, 2017, at 14:04, Fred Drake wrote:> > On Thu, Sep 7, 2017 at 4:52 PM, Terry Reedy wrote:>> Environmental variables tend to be a pain on Windows and nigh unusable by>> beginners. Leaving that aside, I see these problems with trying to use one>> for IDLE's *current* debugger.>> >>
Re: [Python-Dev] PEP 553: Built-in debug()
On Sep 7, 2017, at 13:52, Terry Reedy wrote:> pdb.set_trace is a public and stable interface. IDLE's is private and likely > to be initially unstable. I can imagine that the function that I would want > to bind to sys.__breakpoint__ would be a bound method To be pedantic, you’re not suppos
Re: [Python-Dev] PEP 553: Built-in debug()
On Sep 7, 2017, at 12:09, Fernando Perez wrote:>> The PEP has an open issue regarding breakpoint() taking *args and **kws, >> which would just be passed through the call stack. It sounds like you’d be >> in favor of that enhancement.> > If you go witht the `(*a, **k)` pass-through API, would
Re: [Python-Dev] PEP 553: Built-in debug()
On Sep 7, 2017, at 14:25, Barry Warsaw wrote: > > I’ll see what it takes to add `header` to pdb.set_trace(), but I’ll do that > as a separate PR (i.e. not as part of this PEP). Turns out to be pretty easy. https://bugs.python.org/issue31389 https://github.com/python/cpython/pull/343
Re: [Python-Dev] PEP 552: deterministic pycs
On Sep 7, 2017, at 16:58, Gregory P. Smith wrote:> Input from OS package distributors would be interesting. Would they use this? I suspect it won’t be that interesting to the Debian ecosystem, since we generate pyc files on package install. We do that because we can support multiple version
Re: [Python-Dev] PEP 553 V2 - builtin breakpoint() (was Re: PEP 553: Built-in debug())
On Sep 7, 2017, at 18:12, Nick Coghlan wrote:> > Related to this is the suggestion that we make the default> sys.breakpointhook() a no-op, so that accidentally checking in calls> to breakpoint() won' t hang CI systems.> > Then folks that wanted to use the functionality would set> "PYTHONBRE
Re: [Python-Dev] PEP 553: Built-in debug()
On Sep 7, 2017, at 16:19, Terry Reedy wrote:> I think breakpoint() should have a db= parameter so one can select a debugger > in one removable line. The sys interface is more useful for IDEs to change > the default, possible with other args (like breakpoints and colors) bound to > the callab
Re: [Python-Dev] PEP 553: Built-in debug()
On Sep 7, 2017, at 18:03, Fernando Perez wrote:> Ah, perfect! I've subscribed to the PR on github and can pitch in there > further if my input is of any use. Awesome, thanks! -Barry signature.asc Description: Message signed with OpenPGP ___ Python
Re: [Python-Dev] PEP 553 V2 - builtin breakpoint() (was Re: PEP 553: Built-in debug())
On Sep 7, 2017, at 19:34, Nick Coghlan wrote:> Now that you put it that way, it occurs to me that CI environments> could set "PYTHONBREAKPOINTHOOK=sys:exit" to make breakpoint() an> immediate failure rather than halting the CI run waiting for input> that will never arrive. You better watch o
[Python-Dev] PEP 559 - built-in noop()
I couldn’t resist one more PEP from the Core sprint. I won’t reveal where or how this one came to me. -Barry PEP: 559 Title: Built-in noop() Author: Barry Warsaw Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 2017年09月08日 Python-Version: 3.7 Post-History: 2017年09月09日
Re: [Python-Dev] PEP 559 - built-in noop()
On Sep 9, 2017, at 15:12, Guido van Rossum wrote:> > I can't tell whether this was meant seriously, but I don't think it's worth > it. People can easily write their own dummy function and give it any damn > semantics they want. Let's reject the PEP. Alrighty then! (Yes, it was serious, but I
[Python-Dev] breakpoint() and $PYTHONBREAKPOINT
For PEP 553, I think it’s a good idea to support the environment variable $PYTHONBREAKPOINT[*] but I’m stuck on a design question, so I’d like to get some feedback. Should $PYTHONBREAKPOINT be consulted in breakpoint() or in sys.breakpointhook()? If we support it in breakpoint() then it means
Re: [Python-Dev] PEP 559 - built-in noop()
On Sep 10, 2017, at 14:39, Chris Angelico wrote:> > As a language change, definitely not. But I like this idea for> PYTHONBREAKPOINT. You set it to the name of a function, or to "pass"> if you want nothing to be done. It's a special case that can't> possibly conflict with normal usage. I hav
Re: [Python-Dev] PEP 557: Data Classes
On Sep 10, 2017, at 20:08, Nathaniel Smith wrote:> > I've sometimes wished that attrs let me control whether it generated equality > methods (eq/ne/hash) separately from ordering methods (lt/gt/...). Maybe the > cmp= argument should take an enum with options none/equality-only/full? I have ha
Re: [Python-Dev] PEP 557: Data Classes
On Sep 11, 2017, at 15:16, Ethan Furman wrote:>> >> enum Compare(enum.Enum):>> none = 1>> unordered = 2>> ordered = 3> > I like the enum idea (suprise! ;) but I would suggest "equal" or "equivalent" > instead of "unordered"; better to say what they are rather than what they are
Re: [Python-Dev] PEP 557: Data Classes
On Sep 11, 2017, at 16:51, Mike Miller wrote:> > On 2017年09月11日 05:26, Eric V. Smith wrote:>> On 9/10/17 10:27 PM, Raymond Hettinger wrote:> > I've typically used these type of objects as records. When in an irreverent > mood I've called them bags. I’ve used ‘bag’ too, but I’m not sure that
Re: [Python-Dev] breakpoint() and $PYTHONBREAKPOINT
On Sep 10, 2017, at 12:16, Guido van Rossum wrote:> > I think programmatic overrides should be able to decide for themselves if > they want to honor PYTHONBREAKPOINT or not, since I can imagine use cases > that go both ways. So it should be checked in sys.breakpointhook(). Thanks Guido, I’ll