Hi Carl,
> I think the first question to answer is, are the current mypy docs
> (https://mypy.readthedocs.io/en/stable/) insufficient for this purpose, and
> why?
There’s certainly lots of great documentation in the mypy docs; it’s often my
first go-to.
> They do include both tutorial-style "
Hi Barry & Luciano,
Barry Warsaw wrote:
> Actually, I think it’s time for a comprehensive guide to type annotations.
> Just anecdotally, I was trying to annotate a library of mine and was having
> an impossible time of it, until a chat with Guido lead me to
> @typing.overload. That solved my
Am 16.04.21 um 03:21 schrieb Barry Warsaw:
Actually, I think it’s time for a comprehensive guide to type
annotations. Just anecdotally, I was trying to annotate a library of
mine and was having an impossible time of it, until a chat with Guido
lead me to @typing.overload. That solved my problem
On Apr 15, 2021, at 17:49, Luciano Ramalho wrote:
> Anyone who uses a language with support for static typing expects the
> language distribution to include a type checker. Since that may be
> beyond our means, then the least we could do is have some official
> guidance on the matter, maybe in th
Today I stumbled upon another false positive on Mypy:
https://github.com/python/mypy/issues/4660 .
The issue is more than 3 years old, but it refers to a language
feature (__init_subclass__) which was added in Python 3.6, released in
late 2016.
I understand that maintaining a type checker is a lot
On Thu, Apr 15, 2021 at 2:36 PM Hugh Fisher wrote:
>
> > Date: Wed, 14 Apr 2021 09:57:49 +1000
> > From: Chris Angelico
> > Subject: [Python-Dev] Re: Typing syntax and ecosystem, take 2
>
> >
> > You're advocating an approach that absolutely mandates runn
> Date: Wed, 14 Apr 2021 09:57:49 +1000
> From: Chris Angelico
> Subject: [Python-Dev] Re: Typing syntax and ecosystem, take 2
>
> You're advocating an approach that absolutely mandates running the
> type checker, but then caches the results in an executable file (the
>
Hugh Fisher writes:
> There are a lot of programmers like me. Those languages I listed
> are widely used, and therefore we assume that if a Python language
> construct looks like something we've used before, it will work in
> the same way.
That's not very persuasive. When in London, England,
> Date: Wed, 14 Apr 2021 11:24:12 +0200
> From: Antoine Pitrou
> Subject: [Python-Dev] Re: Typing syntax and ecosystem
>
> Can you explain why you think C++ typing is based on structural
> equivalence?
I'd rather not have a detailed discussion of C++ typing on python-d
On Tue, Apr 13, 2021 at 5:12 PM Hugh Fisher wrote:
> On Wed, 14 Apr 2021 at 08:21, Barry Warsaw wrote:
> > I wouldn’t necessarily be opposed to bundling a type checker with the
> interpreter/stdlib, but I think there are some issues with it. Just off
> the top of my head (there are undoubtedly
>
> Date: Tue, 13 Apr 2021 19:55:38 -0400
> From: Ned Batchelder
>
> In another message, you alluded to PEP 649 being a solution to run-time
> type checking. Maybe I'm misunderstanding something: type annotations
> never do type checking at runtime. As I understand it, PEP 649 is about
> avoidin
I agree that showing support for type hints is important, as long as this
doesn't convey the counterproductive message that type hints have become
almost mandatory. They are useful in some circumstances, and less so
(specially when dealing with beginners or non-professional programmers) in
others.
On Wed, 14 Apr 2021 10:12:19 +1000
Hugh Fisher wrote:
>
> For example, type equivalence by name only is used in Ada (or was,
> it's been many years) and probably other languages. In equivalence
> by name, the following code would not pass the type checker.
> x : list[int]
> y : list[int]
On Apr 13, 2021, at 16:35, Rob Cliffe via Python-Dev
wrote:
> (Gasps in horror.) I can only hope I've misunderstood this sentence. Has it
> ever been even tentatively suggested that type hinting become mandatory?
> (What would that even mean: that the type of every function parameter or
> f
The old rule is best: be strict in what you produce and liberal i what you
accept.
Kind regards,
Steve
On Tue, Apr 13, 2021 at 12:52 AM Edwin Zimmerman
wrote:
> On 4/12/2021 6:34 PM, Brett Cannon wrote:
>
> Had the sentences ended at "confusing" or said something like "I don't
> think it's as
On Wed, 14 Apr 2021 at 08:21, Barry Warsaw wrote:
> I wouldn’t necessarily be opposed to bundling a type checker with the
> interpreter/stdlib, but I think there are some issues with it. Just off the
> top of my head (there are undoubtedly many more issues to resolve):
>
> * Which type checker
On Wed, Apr 14, 2021 at 9:47 AM Hugh Fisher wrote:
>
> > From: Ned Batchelder
> [ munch ]
> > This is very similar to statically typed languages. They also have two
> > steps:
> >
> > * There is the first step that checks the types but does not run the
> > program. In C/C++, this is the com
On 4/13/21 7:40 PM, Hugh Fisher wrote:
From: Ned Batchelder
[ munch ]
This is very similar to statically typed languages. They also have two
steps:
* There is the first step that checks the types but does not run the
program. In C/C++, this is the compiler, in Python it is "mypy".
On Wed, Apr 14, 2021 at 9:45 AM Hugh Fisher wrote:
> I don't want Python to be explicitly typed either. I'm happy with dynamic
> typing, and do not want to have to write even
> x : object
You don't. That's not the proposal. The proposals have ALL been about
gradual typing and inferred typing,
> From: Ned Batchelder
[ munch ]
> This is very similar to statically typed languages. They also have two
> steps:
>
> * There is the first step that checks the types but does not run the
> program. In C/C++, this is the compiler, in Python it is "mypy".
> * There is the second step that r
On Tue, 13 Apr 2021 at 20:30, Stephen J. Turnbull
wrote:
[ munch ]
> > As someone who has programmed in FORTRAN, Pascal, C/C++,
> > Java, and Go this is not at all what I consider reasonable.
>
> From the point of view of typing, you've programmed in one other
> language. ;-) (Maybe Go makes tw
On 13/04/2021 23:21, Barry Warsaw wrote:
I would still be opposed to requiring type hinting in Python.
-Barry
(Gasps in horror.) I can only hope I've misunderstood this sentence.
Has it ever been even tentatively suggested that type hinting become
mandatory? (What would that even mean: t
I see multiple problems with including a type checker as part of the standard
library:
First of all this would require defining precise type checking semantics and
not making breaking changes to them. Currently some parts of type checking are
not precisely defined and are done differently by di
On Tue, 13 Apr 2021 at 18:43, Stéfane Fermigier wrote:
>
[ munch ]
>
> Python is, historically, a dynamically typed language, and gradual typing
> (see https://en.wikipedia.org/wiki/Gradual_typing) has been progressively
> added to it in the last decade or so. This is a legitimate approach, both
On Tue, 13 Apr 2021 at 12:09, Filipe Laíns wrote:
>
[ munch ]
>
> Python is not a typed language, it is a language with optional typing.
Well, it's a dynamically typed language. And yes I agree, I want typing
to remain optional. I am happy that I can write
x = 1
x = [ "hello", "world" ]
On Apr 13, 2021, at 14:55, Luciano Ramalho wrote:
>
> Hugh was unfortunate in presenting the problem, but I agree that we
> should commit all the way to supporting type hints, and that means
> bundling a type checker as part of the standard library and
> distribution.
I wouldn’t necessarily be o
Hugh was unfortunate in presenting the problem, but I agree that we
should commit all the way to supporting type hints, and that means
bundling a type checker as part of the standard library and
distribution.
There is always a delay after a Python release before Mypy catches up
to—and that's the t
On Tue, 2021-04-13 at 09:20 +0200, Antoine Pitrou wrote:
> On Tue, 13 Apr 2021 03:09:28 +0100
> Filipe Laíns wrote:
> >
> > This is simply not a good point in itself, and on top of that it seems to
> > completely ignore that Python could be untyped,
>
> Python is definitely not untyped. It's st
On Tue, Apr 13, 2021 at 1:46 AM Hugh Fisher wrote:
> In any Python 3.6 or later, type
>
> >>> x : float = 1
> >>> isinstance(x, float)
>
> or replace the second line with
>
> >>> type(x)
>
> As someone who has programmed in FORTRAN, Pascal, C/C++,
> Java, and Go this is not at all wha
On 4/12/21 7:43 PM, Hugh Fisher wrote:
Having a type checker run before the Python interpreter in our
current day continuous build/integration environment adds a
second step
This is very similar to statically typed languages. They also have two
steps:
* There is the first step that checks t
On Tue, 13 Apr 2021 03:09:28 +0100
Filipe Laíns wrote:
>
> This is simply not a good point in itself, and on top of that it seems to
> completely ignore that Python could be untyped,
Python is definitely not untyped. It's strongly typed. Its typing is
just dynamic and isn't explicitly spelled
On Tue, 2021-04-13 at 09:43 +1000, Hugh Fisher wrote:
> In any Python 3.6 or later, type
>
> >>> x : float = 1
> >>> isinstance(x, float)
>
> or replace the second line with
>
> >>> type(x)
>
> As someone who has programmed in FORTRAN, Pascal, C/C++,
> Java, and Go this is not at al
On 4/12/2021 6:34 PM, Brett Cannon wrote:
> Had the sentences ended at "confusing" or said something like "I don't think
> it's as optimal as it could be" or "I think it could be better" are all fine.
> But saying that the current approach is "arousing or deserving ridicule :
> extremely silly o
> Message: 4
> Date: Mon, 12 Apr 2021 13:59:50 -0700
> From: Brett Cannon
>
> Please don't denigrate the hard work people have put in to even bring
> forward the idea of typing in Python by saying it's "slightly ridiculous".
In the interest of moving the discussion forward about separate syntax
>> Aren't people allowed to have their own opinions?
Absolutely
> If criticism of any current implementation of any construct becomes
> off-limits is automatically classed as "denigrating"
Without judging the particular instance or the discussion itself, here is the
definition of the w
On Mon, Apr 12, 2021 at 2:19 PM wrote:
> April 12, 2021 4:59 PM, "Brett Cannon" wrote:
>
> > On Mon, Apr 12, 2021 at 3:01 AM Hugh Fisher
> wrote:
> >
> >>> Message: 1
> >>> Date: Sun, 11 Apr 2021 13:31:12 -0700
> >>> From: Barry Warsaw
> >>> Subject: [Python-Dev] Re: PEP 647 Accepted
> >>
> >>
April 12, 2021 4:59 PM, "Brett Cannon" wrote:
> On Mon, Apr 12, 2021 at 3:01 AM Hugh Fisher wrote:
>
>>> Message: 1
>>> Date: Sun, 11 Apr 2021 13:31:12 -0700
>>> From: Barry Warsaw
>>> Subject: [Python-Dev] Re: PEP 647 Accepted
>>
>>>
>>> This is something the SC has been musing about, but a
On Mon, Apr 12, 2021 at 3:01 AM Hugh Fisher wrote:
> > Message: 1
> > Date: Sun, 11 Apr 2021 13:31:12 -0700
> > From: Barry Warsaw
> > Subject: [Python-Dev] Re: PEP 647 Accepted
>
> >
> > This is something the SC has been musing about, but as it’s not a fully
> formed idea, I’m a little hesitant
> Message: 1
> Date: Sun, 11 Apr 2021 13:31:12 -0700
> From: Barry Warsaw
> Subject: [Python-Dev] Re: PEP 647 Accepted
>
> This is something the SC has been musing about, but as it’s not a fully
> formed idea, I’m a little hesitant to bring it up. That said, it’s somewhat
> relevant: We wonder
39 matches
Mail list logo
