helpful in that situation,
Most tools that support colour output allow you to customise the colours
and have a always-colour, never-colour, auto-colour option.
Isatty() is useful for the auto.
Barry
>
> -Mike
>
> ___
> Python-Dev mai
Should is often read as meaning optional when writing specs.
Can you say “must be compatible with C++”.
Barry
>
> Victor
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@pytho
lace the libexpat code inside the python tree
then compile python and see if that works without error.
Take that python version and run the python test suite against it.
If that passes then I would run my application’s test suite to ensure no
regressions.
Barry
>
> Thanks,
> Raghu
&g
> On 27 Apr 2022, at 17:22, Victor Stinner wrote:
>
> Ok, you changed my mind and I added PYTHONDONTADDPATH0=1 env var. Example:
Maybe the env var say what it is not adding rather then where it adds it.
PYTHONDONTADDPWD=1
Barry
___
P
unchanged here. I also am struggling to think of a place
> where someone would care about the kernel-level changes between _MOD
> and _ADD/_DEL but that might be my own lack of imagination or
> knowledge of epoll techniques.
>
> Maybe a compromise is to ship EpollExclusveSelector for a rel
k last week and decided to take a shot at it and have
> built something that I feel is a bit ugly but does seem to work. I'd like to
> some feedback on this approach.
We use the pyOpenSSL to access APIs of openssl.
No need to use ctypes.
Barry
>
> My patches can be fo
y deduced. Am I missing something?
Try asking for help at https://discuss.python.org/
This list is not for help or ideas, also its basically dead.
Barry
>
> --
> Christian Tismer-Sperling:^) tis...@stackless.com
> Software Consulting : http://www.stackless.com/
>
a subject matter expert
> on STREAMS, or what other affect this might have.
>
> And if added to 3.10, should it be backported? I'd tend to say "no", because
> of unknown impacts on existing code.
>
What kernel ca
;> library does not help with any of these.
>
> Of course it helps. You can develop extensions without any third party
> packages or install them.
But you do not need distutils to write python extensions right?
Barry
>
> Same situation if you are on mobile Internet or in
owstoppers and several green buildbots, so I'm going to make the
releases tonight. Please, NO CHECKINS until I say so, or ping me on
#python-dev.
As for bsddb, we'll make a determination after beta3. If it's terminally
busted for Python 3.0, so be it.
Thanks everyone for working so h
ire, but that's gotta be *much* lighter weight
than releasing a Python 2.8.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https
ing a Python 2.8 has enormous impact outside of just
the amount of work to do it. It's an exceedingly bad idea.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/li
Python 2 are
baked into the ecosystems outside of core Python?
I could probably go on, but I'm exhausted.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/pyth
m(string_iterable)
>(with the same efficient semantics).
Ever since ''.join was added, there has been vague talk about adding a join()
built-in. If the semantics and argument syntax can be worked out, I'd still
be in favor of that. Probably deserves
gual code. It
makes it much easier to remove the unnecessary cruft when you drop the Python
2 support.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mai
e any similar looming
pervasive change? [*]
-Barry
[*] I was going to add a joke about mandatory static type checking, but
sometimes jokes are blown up into apocalyptic prophesy around here. ;)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.
nt to spell the .byte()
alternative constructor .from_int() but I also don't think the status quo (or
.byte()) is that much of a usability problem.
The API churn problem comes about when you start wanting to deprecate the
single-int-ctor form. *If* that part gets adopted, it should have a really
t especially attractive as a method name, but it's far more
>explicit about its purpose.
I don't know. How often do you really instantiate the bytes object there in
the for loop?
-Barry
signature.asc
Description: PGP signature
___
Pyt
using concrete examples.
data = bytes(...)
for i in data: # iterate over data as integers
for i in data.bytes: # iterate over data as bytes
But whatever. I just wish there was something better than iterbytes.
-Barry
signature.asc
Description: PGP signature
uld
>align with the iterator -> view changes in dict).
Yep! Maybe that will inspire a better spelling. :)
Cheers,
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listin
order to create a one-byte bytes object?
I feel the same way every time I have to write `set(['foo'])`.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.o
both cases, I
ended up in a situation where some core types could be neither str nor bytes
without some part of the test suite failing miserably. Those are the types of
projects that largely get left unported since it's much harder to justify the
costs vs. benefits.
Cheers,
-Barry
[*] https:
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
ht
t to be the most secure, but other use
cases must be preserved.
Cheers,
-Barry
___
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
xt.verify_mode = CERT_OPTIONACERT_NONE
>context.verify_hostname = False
>urllib.request.urlopen("https://something-i-apparently-dont-care-much-about";,
>context=context)
There's probably an ugly hack possibility that uses unittest.mock.patch. ;)
-Barry
ar this function may not always be
>available (e.g. Jython, older versions of Python)
+1. This would also make it easy to mock in a context manager if you just
wanted to ignore certs for a small section of code.
-Barry
signature.asc
Description: PGP signature
___
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
Unsubscr
bin/python2 installed for that script's shebang. At
that point, they'll *also* get /usr/bin/python which of course points to
/usr/bin/python2.
If the user wants to invoke Python 3, it's not hard to type 'python3' and I
think that's the message we should be spreading. Th
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
s has been suggested.
I seem to recall Guido saying that *if* there's a 4.0, it won't be a major
break like Python 3, whatever that says about the numbering scheme after 3.9.
Is 7 years enough to eradicate Python 2 the way we did for Python 1? Then
maybe Python 4 can reclaim /usr/bin/python.
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@pyt
other ways to specify which version linters to use.
I generally avoid shebangs where they aren't needed, and between entry points
and -m they rarely are these days. I find most uses are in smaller one-off
scripts and such.
Cheers,
-Barry
signature.asc
Description: PG
obally is to set:
__metaclass__ = type
at the top of your file. Then when you're ready to drop Python 2, it's an
easy clean up.
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/pyt
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 s
no problem allowing developers to use non-PSF controlled
resources *unofficially* if it makes their work easier and doesn't conflict
with their own principles. However, in such cases, I still believe that the
official, master, blessed repositories remain on PSF controlled
infrastructure. Sure
en aside from the "we should support open source"
question (which I feel strongly about but acknowledge others have less
allegiance to), it must be absolutely clear that there are repositories which
we as the Python development community, bless.
Cheers,
-Barry
___
positories, having gone through many previous iterations of vcs's - in
Python's case, at least cvs, svn, and hg.
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https:
o dig out the most important bits.
Cheers,
-Barry
___
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
ete, or stay at
parity with new features.
Cheers,
-Barry
[*] And our huge gratitude goes to Paul Boddie for his amazing amount of work
on the project.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsu
f-list
message with your preferred email address. I'd prefer it if you GPG signed
that message.
See here for getting your SSH key registered such that you can make commits to
the PEP repo.
https://docs.python.org/devguide/faq.html#ssh
Cheers,
-Barry
__
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
is decision. E.g. are you saying all these above points will be completely
ignored, or all else being equal, they will help tip the balance?
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listin
is disproportionate
(e.g. peps are updated way more often than devinabox) or folks don't interact
with each of the repos, it might not be very representative. Still, I think
it's better to get a visceral sense of how things actually work than to
speculate about how they *might* work.
C
uarantees it extends to
the contributor.
Cheers,
-Barry
___
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
ource", at least in the view of the entire (unanimous) PSF board. "OSI
approved" would probably be the least controversial definition of "open
source" that the PSF could adopt.
Cheers,
-Barry
pgp7O9fxtjjZZ.pgp
Description: OpenPGP digital signature
__
code that would still benefit
a significant population if it got ported to Python 3. By far Python 3 is a
better language, with a better stdlib, so the work is worth it.
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/m
ar less fun than doing so in Python 3.
Cheers,
-Barry
___
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
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
>
eed
`six` but it does provide some nice conveniences that can be helpful. With
something like tox running your test suite, it doesn't even have to be painful
to maintain.
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.p
e requires a little more formality in its own right.
Hi Nick. What specific changes do you propose to PEP 1 and/or the PEP
process? FWIW, if they are fairly simple, then I think a tracker issue with
at least the PEP 1 authors nosied would be fine.
Cheers,
-Barry
_
tant understanding of any such code. This is head-scratcher code that
I'm sure I'd get asked about from folks who aren't steeped in all the dark
corners of Python. I don't know if that's an argument not to adopt the PEP,
but it I think it would be a good reason to recommen
t;
>So which is it?
In the face of ambiguity, refuse the temptation to guess.
Cheers,
-Barry
pgpQ9ie65GEHm.pgp
Description: OpenPGP digital signature
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/pyth
ement?
I had some more snarky/funny comments to make, but I'll just say -1. The
Rationale in the PEP doesn't sell me on it being an improvement to Python.
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.pytho
s is outside the scope of PEP 441, but if anybody at Pycon wants to explore
this further, I'm in.
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.
users to break an application
by mucking with their $PATH. In Debian/Ubuntu, we don't allow these shebangs
in system scripts, and in fact the package build tools will rewrite shebangs
to avoid them.
Cheers,
-Barry
___
Python-Dev mailing list
Pyth
on *nix at least) is, if the path is absolute,
use the given string verbatim. If the path is relative, search for the given
executable on $PATH and use the first one found. If nothing is found, use
what's given explicitly.
I think that will give all the reas
released. It requires some fairly big changes to
>zipimport (I ended up rewriting the whole thing) but we can easily
>opensource the code, if there's any interest at all.
+1
>I'd be happy to discuss this in more detail at PyCon, at which time we should
>be deploying code internal
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.
m (or via
supported cross-building) would be fine with me.
Cheers,
-Barry
pgpD_dIRHk2Px.pgp
Description: OpenPGP digital signature
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https
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
f use cases will be
>ascii, but someone could have a Python interpreter in
>/home/léon/.local/bin/python...
Well, actually probably utf-8 in most cases, at least for Python 3 on *nix.
I'm not sure sys.getfilesystemencoding() is the right encoding, rather than
sys.getdefaultencoding(), if y
can
come later; let's get some basic support into Python first, and a good start
IMHO is executable zips (including support for extension modules) with the
pkg_resources/importlib API additions.
Cheers,
-Barry
pgp0pH78owXV6.pgp
Description: OpenPGP digital signature
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
>includes zipimport support for C extensions I'll be ecstatic! (But I
>suspect that one's more a 3.6 timeframe)
Agreed! The only difference between executable zips and the full-featured
self-contained app is the goop you put at the front of the file, right? :)
Cheer
ly reasonable. Admittedly, I was hijacking your PEP
discussion for some pie-in-the-sky musing. :)
Cheers,
-Barry
pgpLu9N2fmjsg.pgp
Description: OpenPGP digital signature
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/li
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,
don't know how useful this is, given that (on *nix at least) you can
effectively do the same with head(1).
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://m
wing:
I think you meant s/directory/source/ in the signature.
Other than that, +1.
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/op
collision between -O and -OO, so this PEP
may open the door to us generating both optimization levels automatically.
It's not something that's very high on my todo list, but if there's enough
interest it probably wouldn't be difficult to add.
Cheers,
-Barry
__
that for Python 2, use -Es and for Python 3 use -I (which implies -Es). I'm
not sure we're consistent yet in making sure our build tools install these
switches in our shebangs, but I'm hoping after Jessie we can make some
progress on that.
Cheers,
-Barry
___
nments so maybe there's something useful to be mined there.
Cheers,
-Barry
___
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
vars?
I'd have to go digging around the archives. It wasn't a recent discussion
IIRC.
Cheers,
-Barry
pgpYnskkCwUKH.pgp
Description: OpenPGP digital signature
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/l
difficult to debug.
Comment #47 for Bug 123456: "Oh wait, you installed *what?!*"
Cheers,
-Barry
pgpkruqPndrJS.pgp
Description: OpenPGP digital signature
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/
nality.
You make some good points. I guess it's a trade-off between flexibility and a
known secure execution environment. I'm not sure there's a right answer;
different admins might have valid different opinions.
Cheers,
-Barry
pgpniq0DKukw3.pgp
Descri
wer is required, common sense would suggest
>that __version__ should go before the imports. (I would put it before the
>docstring too, except then the docstring wouldn't be a docstring any more.
>Go figure.)
And after __future__ imports too, right?
Cheers,
-Barry
_
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 m
nside is for doing in-tree development without 'installing'
the package (e.g. absence of venv, tox, or similar).
Cheers,
-Barry
pgpMGj2h7VWfU.pgp
Description: OpenPGP digital signature
___
Python-Dev mailing list
Python-Dev@python.org
https://m
?
They're not mutually exclusive, so why not do both?
I think the advantage of being able to verify the files on any platform is
useful.
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
art I have a question about.
Does the use of Authenticode preclude detached GPG signatures of the exe file?
I can't see how it would, but maybe there's something (well, a lot of
somethings ;) I don't know about Windows.
If not, then what's the proble
be present at the end of the function (if
> reachable).
+1
Odd synchronicity: Today I discovered an old interface that was documented as
returning a "thing or None" but the latter was relying on implicit None return
in some cases. Fixed of course in e
a lot more intuitive sense to me.
I had the same initial thought as Glenn regarding type annotations. It's fine
that they're separate concepts, but it's also helpful that Larry's suggestion
above seems to align them better.
Cheers,
-Barry
___
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,
ing that I will care, but I want to be convinced first.
So I think stub files in the stdlib are the right compromise today.
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
parate, but here the PEP does describe the __async_*__
alternatives.)
Cheers,
-Barry
pgpxCIhVKHrXy.pgp
Description: OpenPGP digital signature
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscri
willing to add this as an alternative to the PEP, under the "Why
async def" section probably?
As with all such bikesheds, Guido will pick the color and we'll ooh and
ahh. :)
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
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"
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
MPARE(val1, op, val2)`.
Cheers,
-Barry
___
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
to allow for landings on what will be 3.6,
then going with workflow 1 will be an interesting social experiment.
I'm fine with any of them as long as the workflow is *well documented*,
preferably in the devguide.
Cheers,
-Barry
pgpr_x4ASMLvd.pgp
Description:
reakpoint() calls
-Barry
signature.asc
Description: Message signed with OpenPGP
___
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/archi
sometimes I
> have a need for a *conditional* breakpoint where it's just much simpler to
> decide whether to break or not in Python code than it would be to use the
> IDE's conditional breakpoint facilities.
That certainly aligns with my own experience and expectations. I gues
ass method, too.
>
> So
>
> "package.module:myclass.classfunc"
>
> would do :
>
> from package.module import myclass
> myclass.classfunc
Yep, that’s how it's described in the PEP 553 open issue. I just didn’t
include that complication in my response.
.
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
e breakpoint() is called, but allows the breakpointhook
> that gets used to work with whatever has been arranged.
Right again! I think setting up the communication channel is outside the scope
of this PEP.
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
__
ic, you’re not supposed to touch sys.__breakpointhook__ although
like sys.__excepthook__ and sys.__displayhook__ they are not enforced to be
read-only.
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing l
anding of
what debugger they are using and what arguments their breakpoint hook allows.
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).
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
__
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
is probably good enough.
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-
be
we want a shortcut for that, e.g. PYTHONBREAKPOINTHOOK=0 or some such.
(Note, I’m still not sure it’s worth supporting the environment variable, but I
am interesting in collecting the feedback on it.)
-Barry
signature.asc
Description: Message signed with OpenPGP
__
much better user
experience than what built-in breakpoint() could do anyway.
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
U
1 - 100 of 2826 matches
Mail list logo
