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
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.
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
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
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
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
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
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
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
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
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
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
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
Python-Dev@python.org
https://mail.p
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
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
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
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
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
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
Hi Larry,
I think we need a Python 3.5 Release Schedule PEP.
Cheers,
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.pytho
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
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
Python-Dev@python.org
https://mail.python.o
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
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
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
___
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
___
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
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
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
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
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
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
___
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
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
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"
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
__
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
___
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
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
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
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
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
.
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
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.
>>
>>
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
1 - 100 of 2704 matches
Mail list logo
