Hi,
I was wondering if the following idea would be a useful addition to the
Python language and if it could use a new PEP.
I personally find myself often looking into the documentation &
implementation of libraries I use to try and figure out what exceptions
a function may raise.
In the same vein
I like the idea.
In python 3.9 you could actually experiment with implementing something
like this yourself using the new Annotated type introduced in PEP 593:
https://docs.python.org/3.9/library/typing.html#typing.Annotated
https://www.python.org/dev/peps/pep-0593/
Maybe create a raises helper
Hey all, I recently ran into some trouble and that I think deserves some
attention. Consider the following case:
class A(ABC):
@abstractmethod
def __lt__(self, other):
pass
@dataclass(order=True)
class B(A):
x: int = 0
class C(B):
pass
Interesting problem. Since the solution is just updating
`__abstractmethods__`, this could be done in the `@dataclass` decorator, no
new ABC needed.
On Thu, Sep 24, 2020 at 8:32 AM Ben Avrahami wrote:
> Hey all, I recently ran into some trouble and that I think deserves some
> attention. Conside
Does anyone know if attrs handles this? I don't have a recent version
installed, but I'll take a look later today.
Eric
On 9/24/2020 11:59 AM, Guido van Rossum wrote:
Interesting problem. Since the solution is just updating
`__abstractmethods__`, this could be done in the `@dataclass`
decorat
On Thu, Sep 24, 2020 at 6:59 PM Guido van Rossum wrote:
> Interesting problem. Since the solution is just updating
> `__abstractmethods__`, this could be done in the `@dataclass` decorator, no
> new ABC needed.
>
>
This issue also pertains to total_ordering (and perhaps other std library
class-de
On Thu, Sep 24, 2020 at 7:02 PM Eric V. Smith wrote:
> Does anyone know if attrs handles this? I don't have a recent version
> installed, but I'll take a look later today.
>
attrs handles this only if you set slots=True (which makes sense since
attrs would have to rebuild the class)
Where is the discussion on this PEP going to be? In this thread, or a new
thread? Sorry for not having followed these closely enough to know. I'd like to
point out that boost-histogram and xarray (at least) would love this as well,
as we both (independently) came up with dict-in-index workaround
not sure where further discussion will be, but absolutely look at the
length discussion already on this list, where your question has been much
discussed.
-CHB
On Thu, Sep 24, 2020 at 1:01 PM wrote:
> Where is the discussion on this PEP going to be? In this thread, or a new
> thread? Sorry for
https://www.python.org/dev/peps/pep-0637/
Thank you Stefano and Jonathan for a very carefully written and thought-out
PEP. I trust that the background etc. are representing past discussion, so
I am going to focus on the spec itself. Fortunately I only have a few nits,
really. (If you submit new PR
On Thu, Sep 24, 2020 at 07:32:37PM -, [email protected] wrote:
> Where is the discussion on this PEP going to be? In this thread, or a
> new thread?
I see no reason why we cannot continue discussion in this thread.
> Sorry for not having followed these closely enough to know. I'd like
Sergio Fenoll writes:
> In the same vein as adding type annotations to code, I think it'd
> be very useful to have exception "raises" annotations, i.e. a way
> to annotate what exceptions a function raises.
I think you need to explain the use cases in more detail. You mention
IDEs, but they c
I feel like this paragraph in the PEP goes a little bit too far, but I
understand its good intention.
The first difference is in meaning to the reader. A function call says
> "arbitrary function call potentially with side-effects". An indexing
> operation says "lookup", typically to point at a sub
Is this a breaking change? It feels borderline.
Keyword-only subscripts are permitted. The positional index will be the
> empty tuple:
> obj[spam=1, eggs=2]
> # calls type(obj).__getitem__(obj, (), spam=1, eggs=2)
I.e. consider:
>>> d = dict()
>>> d[()] = "foo"
>>> d
{(): 'foo'}
I don't reall
If you are upgrading a maintenance version (following the
major.minor.maintenance naming) of python, e.g. 3.8.5 -> 3.8.6 it is also a
good idea to update any 3.8 venvs that you may be using. The venv –upgrade flag
is reasonably new and I think that relatively few people will have heard about
it
On Thu, Sep 24, 2020 at 10:47:21AM +0200, Sergio Fenoll wrote:
> Hi,
>
> I was wondering if the following idea would be a useful addition to the
> Python language and if it could use a new PEP.
> I personally find myself often looking into the documentation &
> implementation of libraries I use to
On Fri, Sep 25, 2020 at 3:38 PM Steven D'Aprano wrote:
> The last thing I want to see is people being encouraged to write code
> like this:
>
> def demo(arg)->Something:
> # Raises ValueError
> try:
> processing...
> except ValueError:
> raise
>
O 25/09/20 ás 07:37, Steven D'Aprano escribiu:
I think that it's a truism that any function written in Python could
raise any exception :-)
In practice, though, I think it is reasonable to say that functions will
*typically* but not necessarily exclusively raise a certain set of
exceptions.
Wh
On Fri, Sep 25, 2020 at 4:25 PM Sergio Fenoll wrote:
> What I had in mind was that an IDE could use this information to show
> autocomplete options when writing except blocks. The other day I was
> writing some code like this:
>
> import requests
>
> try:
>
> requests.get('https://python.org'
19 matches
Mail list logo
