agers, as I'm sure you do to. :)
For Debian/Ubuntu, we already have some additional machinations to make
ensurepip and such work properly in a distro packaging environment. We'd want
to be able to do the same for any bundled packages as well.
Cheers,
-Barry
setuptools and
pkg_resources to be split, which would be great for other reasons. Splitting
them may mean that pkg_resources could eventually be added to the stdlib, but
as an intermediate step, it could also test out this idea. It probably has a
lot less of the baggage that you outline.
ames
until Python 3.7 (presumably) is in widespread -and only- use.
Cheers,
-Barry
pgpbwx9wa1J1Z.pgp
Description: OpenPGP digital signature
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscr
al packages, and
anything that depends on them.
The Fedora/RH ecosystem probably has their own list, which I'd expect to
mostly overlap with ours, but I don't have those links handy.
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
e what
>changes were made without having to go through to another site.)
Yep, this was recently discussed and I think the plan is to bring them back
for python-checkins, but that it's not possible to enable them on PRs due to
GH limitations.
Cheers,
-Barry
__
I don't know if those are configurable in reno or it would require a fork, but
I'd like to preserve that organizational structure. If reno can also help
wrap long lines, enforce/encourage bpo-* mentions, and clean up whitespace,
then I'm for trying it out.
-Barry
_
target output format for this tool?
Maybe it's not the *only* target output format? Now, what's the input?
The other thing is that I'm not sure design-by-committee is going to work so
well here. There are several competing interests here. Release managers,
non-core devs (dri
imple stuff in gdbinit. I think
there's still utility in that if we can keep it working.
-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
tpd, an asyncio-based replacement for smtpd.
It's worked out great on all fronts so far (good community contributions,
rapid development, API flexibility as we move toward 1.0, good visibility
inside the more general aio-libs umbrella).
Cheers,
-Barry
__
doc:
https://docs.google.com/document/d/1zrV3OIRSo99fd2Ty4YdGk_scmTRDmVauBprKL8eij6w/edit
The document should be public for comments and editing.
If you have any thoughts, or other lines of investigation you think are
worthwhile pursuing, please add your comments to the document.
Cheers,
-Barry
be reused in the future. I
*really* don't want for that to ever be possible.
Maybe change the status to "This is an Ex-PEP" or "This PEP is pining for the
fiords".
It's also okay to remove much of the content and just leave a placeholder.
The
The answer is almost always to
explicitly coerce those environments to C.UTF-8 for Linuxes that support that.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/ma
quot;Do some work"""
>
>class Employee(object):
>implements(IEmployee)
IIUC, the Python 3 way to spell this is with a decorator.
from zope.interface import implementer
@implementer(IEmployee)
class Employee:
(also, since this is Python 3, do you really need to inher
stays in main, it
will get official support until 2023.
https://www.ubuntu.com/info/release-end-of-life
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python
On Mar 23, 2017, at 08:02 PM, MRAB wrote:
>If you see 2/8, is that 2 August or February 8?
I think that's 0.25 which doesn't look like a date to me . ISO 8601
dates please: 2020-02-08 is unambiguous.
-Barry
___
Python-Dev mailing li
portingdb.xyz/pkg/samba/
Samba is the last big one keeping 2.7 on the Ubuntu desktop edition as well.
-Barry
pgp0RfH3tstoy.pgp
Description: OpenPGP digital signature
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/li
t I should implement?
Barry
PyCXX
___
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 May 25, 2017, at 08:03 AM, Jake Edge wrote:
>Thanks to Larry and Barry, I was able to sit in on the Python Language
>Summit again this year. The start of the coverage for that is now
>available.
Thanks so much for your always excellent reporting Jake. It's unfortunate
that w
+1
now for requiring braces. :)
-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
releases. New features are much tougher to justify the potential for
regressions.
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/option
at time, 16.04
won't track upstream point releases, but instead will get select cherry
picks. For good reason, there's a lot of overhead to backporting fixes into
stable releases, and something as big as being suggested here would, in my
best guess, have a very l
the process:
https://wiki.ubuntu.com/StableReleaseUpdates
There's also Debian to consider.
Cheers,
-Barry
pgpNTh6UFehHt.pgp
Description: OpenPGP digital signature
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/lis
https://github.com/python/peps/pull/280/files
On Jun 01, 2017, at 09:08 PM, Brett Cannon wrote:
>If you create an issue at github.com/python/peps and assign it to me I will
>get to it someday. :)
pgpqhM6HQldC5.pgp
Description: OpenPGP digital signature
__
breaking pip
>bootstrapping in the process).
That sounds like a good compromise. My own major objection was in exposing a
new public API in Python 2.7, which would clearly be a new feature.
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.or
s://github.com/python/peps/issues/283
https://github.com/python/peps/pull/284
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
down to the
> body
Agreed with the rationale for the open brace being on a separate line, but did
you mean to indent the opening and closing braces to different levels?
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 Jun 05, 2017, at 07:00 AM, Skip Montanaro wrote:
>Wow, this discussion takes me back. Glad I don't have to check out
>comp.lang.c to get my brace placement fix.
Life is better without braces!
-Barry
___
Python-Dev mailing list
ul since those third party packages can be distro-fied into current and
backported channels.
-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
r off trying to identify and address such problems than ignoring or
minimizing them.
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-
could be addressed by a
better builtin, but I fear we’ll end up down the bikeshedding hole for that.
-Barry
> On Jul 17, 2017, at 16:31, Giampaolo Rodola' wrote:
>
> I completely agree. I love namedtuples but I've never been too happy about
> the additional overhead vs.
On Jul 17, 2017, at 18:27, Greg Ewing wrote:
>
> Barry Warsaw wrote:
>> namedtuple is great and clever, but it’s also a bit clunky. It has a weird
>> signature and requires a made up type name.
>
> Maybe a metaclass could be used to make something
> like this po
support it.
That's another problem with the approach of course; it's not universally
possible to implement.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.pyt
On Jul 20, 2017, at 03:16 PM, Eric Snow wrote:
>Relatedly, at PyCon this year Barry and I were talking about the idea of
>bootstrapping the interpreter from a memory snapshot on disk, rather than
>from scatch (thus drastically reducing the number of IO events).
The TPI (Terrible Pytho
us to the gc
module; all those functions could have gone in sys since they query and
effect the Python runtime system, but it makes more sense (and improves
the naming) by putting them in their own module. It also segregates the
functionality so th
On Aug 24, 2017, at 10:23, Yury Selivanov wrote:
>
> On Thu, Aug 24, 2017 at 9:52 AM, Barry Warsaw wrote:
>> Guido van Rossum wrote:
>>> On Tue, Aug 22, 2017 at 7:12 PM, Nathaniel Smith wrote:
>>>
>>> I worry that that's going to lead more people
On Aug 24, 2017, at 16:01, francismb wrote:
> On 08/24/2017 03:52 PM, Barry Warsaw wrote:
>> Guido van Rossum wrote:
>>> On Tue, Aug 22, 2017 at 7:12 PM, Nathaniel Smith wrote:
>>>
>>> I worry that that's going to lead more people astray thinking thi
to
reason about what’s going on, and it’ll be imperative to be able to debug and
examine the state of your execution when things go unexpected. That’s always
harder when mixing dynamic scope with lexical scope, which I think is what PEP
550 is ultimately getting at.
Cheers,
-Barry
signatu
valid value in some cases, but
that currently can’t be distinguished from “missing”.
I’d also like a debugging interface, such that I can ask “context_var.get()”
and get some easy diagnostics about the resolution order.
Cheers,
-Barry
signatu
unique, I would prefer thredarena
> but I see naming is hard ... :-)
Oh mollusks, I thought you said bacon.
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/ma
one, traverse=True)
>
> IMO "lookup" is a slightly better name in this particular context.
Given that signature (which +1), I agree. You could add keywords for debugging
lookup fairly easily too.
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
___
t` is set to `True`, `lookup` will only check the topmost LC.
>
> For deleting a value from the topmost LC we can add a new
> "ContextVar.delete()" method.
+1
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Pyth
PEP:
https://www.python.org/dev/peps/pep-0553/
Unlike David, but like Larry, I have a prototype implementation:
https://github.com/python/cpython/pull/3355
Cheers,
-Barry
P.S. This came to me in a nightmare on Sunday night, and the more I explored
the idea the more it frightened me
(Aside: improving/expanding the stdlib debugger is something else I’d like to
work on, but this is completely independent of PEP 553.)
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@py
om/giampaolo/sysconf/blob/master/home/.pdbrc.py
I don’t think that’s a good idea. pdb is a thing, and that thing is the
standard library debugger. I don’t think ‘pdb’ should be the term we use to
describe a generic Python debugger interface. That to me is one of the
advantages of PEP 553; it separ
On Sep 6, 2017, at 07:46, Guido van Rossum wrote:
>
> IIRC they indeed insinuate debug() into the builtins. My suggestion is also
> breakpoint().
breakpoint() it is then! I’ll rename the sys hooks too, but keep the naming
scheme of the existing sys hooks.
Cheers,
-Barry
sign
;s
> nothing for pdb.pm() to look at. I think Barry is wisely focusing on just the
> ability to quickly and programmatically insert a breakpoint.
Thanks Guido, that’s my thinking exactly. pdb isn’t going away of course, so
those less common use cases are still always available.
Cheers,
ng
> to support other backends?
Possibly, and there’s an open issue about that, but I’m skeptical about that
for your use case. Will a user setting a breakpoint know what to pass there?
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
_
rom the server process and deal
> with the blocked loop.
Would the environment variable idea in the latest version of the PEP help you
here?
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Pyt
formance for the average Python application.
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
Unsubscribe:
https://mail.python.or
nd of feedback from other debuggers that
I’m looking for. It certainly sounds like a handy feature; I’ve found myself
wanting something like that from pdb from time to time.
The PEP has an open issue regarding breakpoint() taking *args and **kws, which
would just be passed through the call stack. I
?
Cheers,
-Barry
> On Oct 7, 2021, at 12:52, Sam Gross wrote:
>
> Hi,
>
> I've been working on changes to CPython to allow it to run without the global
> interpreter lock. I'd like to share a working proof-of-concept that can run
> without the GIL. The proof-of-conce
Thank you Sam, this additional detail really helps me understand your proposal.
-Barry
> On Oct 11, 2021, at 12:06, Sam Gross wrote:
>
> I’m unclear what is actually retried. You use this note throughout the
> document, so I think it would help to clarify exactly what is ret
3.11 at your convenience.
With our appreciation,
-Barry (on behalf of the Python Steering Council)
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists
a PEP Delegate, but more than a PEP shepherd. If
you are that person, please let us know!
Cheers,
-Barry (on behalf of the Python Steering Council)
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le
exemption in
https://github.com/python/steering-council/issues/80
Respectfully,
-Barry (on behalf of the Python Steering Council)
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https
they don’t speed things up as much as you think they will.
Optimizations usually involve adding complexity. I would like some sense of
what we’d gain for the added complexity.
Cheers,
-Barry
> On Nov 29, 2021, at 09:04, Serhiy Storchaka wrote:
>
> 29.11.21 18:36, Victor Stinner пиш
the types declared in annotations to affect
> runtime behaviour, as that's the most under-represented group at the
> moment (and it's not clear whether it's under-represented because
> there aren't many such uses, or because the users aren't being heard
> fro
As much as I’m in the "type annotations are
good” crowd now, I still think they should always be optional. Python’s use is
so broad these days, I for one don’t want to have to add annotations to every
bit of Python I write.
-Barry
signature.asc
Description: Message signed with OpenPGP
On Nov 29, 2021, at 15:57, Larry Hastings wrote:
>
> On 11/29/21 2:56 PM, Barry Warsaw wrote:
>> PEP 563 and 649 have visible effects that even within that domain can have
>> important side effects. For example, PEP 563’s loss of local scope, which
>> even “de-stri
on)
>
> Two lines printed at the end of the -h/--help output would refer users to
> --help-env and -Xhelp.
+1, and —help-env seems better.
What do you think about -hh (and maybe —help-full) printing full help?
-Barry
signature.asc
Description:
On Dec 20, 2021, at 12:22, Guido van Rossum wrote:
> What do you think about -hh (and maybe —help-full) printing full help?
>
> Is there enough of a use case for this to bother?
Maybe not. I’d say if it was easy to implement, why not, but if it’s a pain,
don't bother.
-Barry
s:
>
> ```
> def SomeFn(x: float) -> int:
> ...
>
> def twice(f: SomeFn) -> SomeFn:
> return lambda x: f(f(x))
> ```
That seems pretty intuitive to me. The conventions you mention would be just
that though, right? I.e. `pass` could be used, but whatever the body is it
wo
ame that is easier to understand.
So it might be CostFunction that would be a great name in that problem domain.
Barry
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.o
/4TY3MVJQOLKSTMCJRTGAZEOSIIMAWQ45/
Of course, this decision can be revisited by the 2022 SC.
-Barry
> On Jan 7, 2022, at 15:59, jack.jan...@cwi.nl wrote:
>
> I posted this suggestion earlier in the callable type syntax discussion, at
> which point it was completely ignored. Poss
, ultimately.
-Barry
On Sat, Jan 8, 2022, at 03:06, Stéfane Fermigier wrote:
>
> On 8 Jan 2022 at 00:59:38, jack.jan...@cwi.nl wrote:
>>
>> I posted this suggestion earlier in the callable type syntax discussion, at
>> which point it was completely ignored. Possibly because it’s
PEPs are simple and regular enough that a good
local build environment can suffice for now.
Cheers,
-Barry
> On Jan 10, 2022, at 02:44, pyt...@quite.org.uk wrote:
>
> Hi,
>
> I would like to announce PEP 676 to python-dev. It is a meta-PEP focussed on
> modernising the PEP bu
recompiling the source file you're
> staring at. Which it recomplies without benefit of PGO.
The trick you need is to close the project you use to build python
from source then you can open the python.exe and run that under the
debugger. Because it can find the python.pdb it will source/d
dded escape sequences without a way to turn then off in the API.
On the other hand it would be great to be able, as an API call, to set the
style of the traceback
text.
Barry
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an e
> On 19 Jan 2022, at 21:19, Ethan Furman wrote:
>
> On 1/19/22 1:10 PM, Barry Scott wrote:
> > On 18 Jan 2022, at 19:59, Pablo Galindo Salgado wrote:
>
> >> We considered using colours and other markers such as bold text, but that
> >> opens a considera
> On 19 Jan 2022, at 21:19, Ethan Furman wrote:
>
> An environment variable would solve this, yes? The default would be using
> the underlining carets, but an env var could switch that to using color
> instead.
Oh and if you use colours then you please give me the ability to set the
colour
> On 20 Jan 2022, at 02:22, Skip Montanaro wrote:
>
> (This really belongs on python-ideas, right?)
>
I'm commenting on the implementation that is on going. python-ideas does not
seem right.
Barry
___
Python-Dev mailing l
it will likely get more traction over time. The disadvantage is that HPy
would evolve at the same annual pace as CPython.
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe se
to link python to an external libexpat instead of the
vendored expat inside python?
Have you tried deleting libexpat 2.2.8 from the python source code and
replacing with the libexpat 2.4.6 and then
compiling python?
Are you concerned that you need fixes in the python c
discussions. This will make reading and authoring PEPs a much nicer experience.
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le
arately on PyPI. It’s *possible*
but I don’t know if it’s *practical*.
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://ma
but I’m like Guido. I pretty much use
pytest for everything these days, except for maybe unittest.mock.patch.
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send
.
However, if start up time isn’t a direct benefit of on-demand imports (a.k.a.
declarative imports), I’m not sure how actually useful or used they will be. I
dunno, top-of-module imports never really bothered me that much.
-Barry
[1] I could be wrong about Faster CPython; ISTR there are some tickets
119
I’ve put some questions and comments there, but I’m also really curious about
the technical details for your lazy imports. Have you gotten as far as
thinking about a PR or PEP?
-Barry
[1] Not that there aren’t other reasons folks give for rewriting, such as
multicore performance
#x27;s
> interested in this and happens to be in the sprints too!
>
> I am and I will be.
Apologies for the icky quoting, but yay! It’s great to hear your intentions,
and like Guido, I would like to connect on this at Pycon as well.
-Barry
alue__',
'__forward_is_argument__', '__forward_is_class__',
'__forward_module__’)
So it seems that you’re almost there already!
> So, technically, this means we could spell the "continue class" step like so:
>
> c
> On 27 Apr 2022, at 20:21, Miro Hrončok wrote:
>
> On 27. 04. 22 20:45, Barry wrote:
>>> 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
save from austinp
itself?
Barry
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org
. What similar kinds of protections do we have on
Discourse?
-Barry
> On Jul 15, 2022, at 04:18, Petr Viktorin wrote:
>
> The discuss.python.org experiment has been going on for quite a while, and
> while the platform is not without its issues, we consider it a success. The
> C
To me, that’s the biggest negative of Discourse, and I definitely prefer
threaded discussions. Unfortunately though, much like top posting , I
think that horse is out of the barn, what with other forums like GitHub being
linear.
-Barry
On Jul 15, 2022, at 11:59, Ethan Furman wrote:
>
&g
nts `\0x0b', as it does in the re module.
You seem to be mixing the use \ as the escape for strings and the \ that re
uses.
Is it the behaviour that '\' becomes '\\' that means this is
a breaking change?
Won't this work?
```
re.compile('\v:\\v')
# which is
c. But
> for PEP-level changes, we believe python-dev no longer reaches the proper
> audience.
Please also make sure your PEP’s Discussions-To header points to the right
forum.
https://peps.python.org/pep-0001/#discussing-a-pep
Cheers,
-Barry
signature.asc
Description: Mess
g that previous
discussions get for free or only new replies? I’m not finding much information
about this feature on the Discourse site.
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- python-dev@python.
Oh, I see, thanks. This is for the email interface, not the web interface.
-Barry
> On Sep 27, 2022, at 13:49, Cameron Simpson wrote:
>
> On 27Sep2022 11:14, Barry Warsaw wrote:
>>> Threading on the Python Discourse should now be working correctly. This is
>>&
n just yet, but it sure
is nice to not be overwhelmed and stressed out every single day by the bloat in
my Python inbox.
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe
responded to. I might drop in
to those a couple of times a day when things are slow. Then of course there’s
Discord for various Python groups, and Python’s Slack.
The whole shift away from email leaves me calmer and better engaged.
-Barry
> On Dec 9, 2022, at 06:49, Stephen J. Turnb
> On 11 Dec 2022, at 21:05, Abdur-Rahmaan Janhangeer
> wrote:
>
> If only, fellow list colleagues, I could see only the topics I choose on
> Discourse.
Have you tried changing the Preferences for Notifications/Categories?
That would appear to give you the control you are ask
to python and back into C++ and the exception arrives
as expected.
You can riase in Python fo into C++ and back to Python and again the exception
arrives as expected.
That is as long as its a python exception.
Barry
> ___
> Python-Dev mailing l
I heard it on reasonably believable authority that the FLUFL took the year off.
Lamentable.
-Barry
> On Apr 1, 2023, at 11:19, Skip Montanaro wrote:
>
> Just wanted to throw this out there... I lament the loss of waking up on
> April 1st to see a creative April Fool's D
Yep, fine with me too.
-Barry
> On Nov 13, 2023, at 02:17, Marc-Andre Lemburg wrote:
>
> Hello everyone,
>
> for quite a while now, core discussions have moved to Discourse and people
> are obviously enjoying things there:
>
> https://discuss.python.org/c/core-d
before the last push for PEP 572 implementation gets completed.
Rather than just a vote, if you have a rationale for one over the other, I’d
love to hear it. Feel free to weigh in here or on the issue.
Cheers,
-Barry
signature.asc
Description: Me
an obscurely named exception that
will essentially force users to search for it. But maybe they’ll have to
anyway. OTOH, maybe we can find an even better name, like EggManError or
KooKooKaChooError.
I-am-the-Walrus-lyrics-won’t-help-you-at-all-ly y’rs,
-Barry
signature.asc
Descri
saw that it would definitely be
more descriptive. Is that valuable in the error output? Is it still valuable
when you have useful descriptive text?
> Please let's not use SyntaxError for something that's not an error
> with the syntax.
PEP 572 does propose TargetScopeError as a
Interesting idea!
https://gitlab.com/warsaw/public/issues/3
-Barry
> On Aug 9, 2019, at 09:55, Christian Tismer wrote:
>
> Signed PGP part
> On 16.07.19 00:32, Barry Warsaw wrote:
>> On Jul 13, 2019, at 19:09, Raymond Hettinger
>> wrote:
>>>
>>>
Thanks Nick. I find yours (and Eric’s) argument compelling. I’m totally
aligned with using SyntaxError in 3.8 and thinking through the more general
problem for 3.9.
Cheers,
-Barry
> On Aug 9, 2019, at 06:44, Nick Coghlan wrote:
>
> Short version of my more detailed answer below:
&
Nick and I are now on the same page, so I don’t think we *have* to have a
formal SC vote.
Cheers,
-Barry
> On Aug 9, 2019, at 08:28, Guido van Rossum wrote:
>
> I don't see how this debate can avoid a vote in the Steering Council.
>
> --
> --Guido van Rossum (python
801 - 900 of 2826 matches
Mail list logo
