The challenge with version conflicts is often less that you need to go
update the constraints (which has little to do with sysadmin'ing, TBH) and
more that you have insufficient *integration tests* and you're relying upon
something else running the per-package tears.
On Thu, Feb 25, 2021, 00:10 Pe
The Steering Council just published the community update for January
(covering November/December as well):
https://github.com/python/steering-council/blob/master/updates/2021-01-steering-council-update.md
(included verbatim below). We'll be trying to keep this up monthly from now
on. I'll note that
On Thu, Feb 25, 2021 at 5:59 AM Guido van Rossum wrote:
>
> Here's a potentially alternative plan, which is also complex, but doesn't
> require asyncio or other use cases to define special classes. Let's define
> two exceptions, BaseExceptionGroup which wraps BaseException instances, and
> Except
On Thu, Feb 25, 2021 at 5:19 AM Guido van Rossum wrote:
> [Subthread: handling individual errors]
>
> > Rather than iterator, I think we should add a visitor that calls a
> function for each leaf exception,
>
> I agree that we shouldn't add an `__iter__` method. But what if we added a
> separate
Finally! One of my top python wishes!
Where can I vote?
How can I get my hands on a back port?
How can I help getting this sooner?
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https:
On Thu, Feb 25, 2021 at 5:35 AM Wes Turner wrote:
> The challenge with version conflicts is often less that you need to go
> update the constraints (which has little to do with sysadmin'ing, TBH) and
> more that you have insufficient *integration tests* and you're relying upon
> something else ru
On Thu, Feb 25, 2021 at 8:46 AM Thor Whalen wrote:
> Finally! One of my top python wishes!
>
> Where can I vote?
>
There is no explicit voting, but thanks for sharing your opinion!
>
> How can I get my hands on a back port?
>
Probably can't since it will be new to 3.10 if the PEP gets accepte
On 2021-02-24 21:08, Peter Wang wrote:
With binary extension modules, version conflicts lead to (at best) runtime
segfault and (at worst) subtle *data* bugs that return incorrect results. There
are also deeper concerns around security and reproducibility.
If your app has requirements, by al
One aspect of conda packaging that's worth adopting is the 'test' block of
the meta.yaml which contains commands necessary to *test* the built package.
You can add a pytest command to setup.py, but it's not as easy as:
https://github.com/conda-forge/python-feedstock/blob/master/recipe/meta.yaml#L2
Good question. The main use case I see for iterating over individual
exceptions is logging frameworks that want to format their own exception
tracebacks for whatever reason. I know that the traceback.py module has
extensive utilities for exactly that, but I betcha there are plenty of
people who sti
So is "fail-fast if you forget to handle an ExceptionGroup" really a
feature? (Do we call this out in the PEP?)
We may believe that "except Exception" is an abuse, but it is too common to
dismiss out of hand. I think if some app has e.g. a main loop where they
repeatedly do something that may fail
We don't call it out but we talked about this at the sprint. I think the
reason we didn't come up with this solution then is that at the time
ExceptionGroups in our plans were not immutable, so this would not have
been possible (you don't know at construction time what it is going to
contain).
O
Then we should get some more opinions on this. I think it's the best idea
so far for kindness towards code using `except Exception:`. I even think
that the names I came up with are reasonable. The pseudo-code needs work:
when instantiating ExceptionGroup, all errors should inherit from
Exception, a
On Thu, Feb 25, 2021 at 9:06 PM Guido van Rossum wrote:
>
> Hm, a different idea: maybe it's simple enough that we can just add an
> example showing how to do this? Then people can tailor that e.g. to use
> various traversal orders. (We could just link to the code in traceback.py,
> but it probab
Great. Let’s wait for others to catch up with the discussion then.
On Thu, Feb 25, 2021 at 18:44 Irit Katriel
wrote:
>
>
> On Fri, Feb 26, 2021 at 2:00 AM Guido van Rossum wrote:
>
>> Then we should get some more opinions on this. I think it's the best idea
>> so far for kindness towards code u
Mike Miller writes:
> "sys-admin" is a bit of an overstatement in my phrasing. The core
> is that you need to understand how a PATH works and be able to run
> pip and cd into folders and perhaps run rm/del, etc. Basic
> command-line skills?
That's what I would mean by basic sys-admin skills
On Fri, Feb 26, 2021 at 2:00 AM Guido van Rossum wrote:
> Then we should get some more opinions on this. I think it's the best idea
> so far for kindness towards code using `except Exception:`.
>
I agree that it's the best idea so far.
If someone says 'except Exception' they better mean it becau
On Thu, Feb 25, 2021 at 2:13 PM Guido van Rossum wrote:
>
> So is "fail-fast if you forget to handle an ExceptionGroup" really a feature?
> (Do we call this out in the PEP?)
>
> We may believe that "except Exception" is an abuse, but it is too common to
> dismiss out of hand. I think if some app
On 2/25/2021 9:40 PM, Nathaniel Smith wrote:
On Thu, Feb 25, 2021 at 2:13 PM Guido van Rossum wrote:
So is "fail-fast if you forget to handle an ExceptionGroup" really a feature?
(Do we call this out in the PEP?)
We may believe that "except Exception" is an abuse, but it is too common to dism
On Thu, Feb 25, 2021 at 10:23 PM Glenn Linderman wrote:
> So then why do you need except* at all? Only to catch unwrapped
> ExceptionGroup before it gets wrapped?
>
> So why not write except ExceptionGroup, and let it catch unwrapped
> ExceptionGroup?
>
> That "CUTE BIT" could be done only when
20 matches
Mail list logo
