On Sat, Jan 08, 2022 at 08:36:57PM -0600, Skip Montanaro wrote:
> >
> > So if you hate type annotations because they are unreadable, then you
> > hate Python because Python is unreadable.
> >
>
> That seems rather harsh. I suspect if those of us who are uncomfortable
> with the typing subsystem ac
On Sun, Jan 9, 2022 at 3:47 PM Steven D'Aprano wrote:
> The point I am making here is not that I was a dimwit who couldn't even
> read Python, but that "easy to read" and "readable" is more a matter of
> familiarity than an inherent property of the language itself. With
> enough familiarity, even
On Sat, Jan 08, 2022 at 06:30:53PM -0800, Ethan Furman wrote:
> On 1/8/22 5:46 PM, Steven D'Aprano wrote:
>
> > [...] if you hate type annotations because they are unreadable, then you
> > hate Python because Python is unreadable.
>
> Not so.
Are you disputing that annotations use the same synta
This really needs a new thread, maybe even a new PEP, but ...
On Sat, Jan 8, 2022 at 5:27 PM Steven D'Aprano wrote:
> > > If I can make a wild suggestion: why not create a little language
> > > for type specifications?
>
> Any time we are tempted to prefix a question with "Why not ...", the
> qu
>
> So if you hate type annotations because they are unreadable, then you
> hate Python because Python is unreadable.
>
That seems rather harsh. I suspect if those of us who are uncomfortable
with the typing subsystem actually hated Python we would have found our way
to the exits long ago. Typing
On 1/8/22 5:46 PM, Steven D'Aprano wrote:
> [...] if you hate type annotations because they are unreadable, then you
> hate Python because Python is unreadable.
Not so. A simple list comprehension is (usually) quite readable, while a triply-nested list comprehension all on one
line is not.
S
On Sun, Jan 09, 2022 at 02:20:45AM +0100, jack.jan...@cwi.nl wrote:
> Barry:
> > The advantage to users of keeping the languages the same is that
> > readers of your code don’t have to learn two disparate syntaxes to
> > make sense of what they’re reading. One of Python’s enduring
> > strengths
On Sun, Jan 09, 2022 at 01:30:33AM +0100, jack.jan...@cwi.nl wrote:
> In the last year I’ve contributed mods to two packages that were
> rejected because I hadn’t provided typing (and black formatting, but
> that’s a different subject). I’ve reluctantly done so. And while I
> *hated* it because
On Sat, Jan 08, 2022 at 12:59:38AM +0100, 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 a really stupid
> idea, but let me post it again on the off chance that it isn’t a stupi
Barry:
> The advantage to users of keeping the languages the same is that readers of
> your code don’t have to learn two disparate syntaxes to make sense of what
> they’re reading. One of Python’s enduring strengths has been its
> readability.
Agreed. But if the little language is (a) clearly
On 8 Jan 2022, at 23:05, Skip Montanaro wrote:
>> ... make sense of what they’re reading.
> Some of us have that problem with type-embellished code now. I'm not sure a
> little language would be such a bad idea. 🤔 Fortunately, my relationship to
> the working world allows me to simply ignore e
On Sat, Jan 08, 2022 at 12:32:35PM +0200, Serhiy Storchaka wrote:
> 08.01.22 01:59, jack.jan...@cwi.nl пише:
> >> If I can make a wild suggestion: why not create a little language for
> >> type specifications?
>
> We need a way to define aliases. For example, write:
>
> Data = Mapping[str, Sequen
I find this a really elegant approach.
While the SC's decision to keep the syntax uniform is certainly laudable, it's
creating the issue of packaging new complexities into a very limited syntactic
& semantic space (e.g. no new magic symbols like "->", which I agree with BTW),
leaving only very
On 1/8/2022 2:05 PM, Skip Montanaro wrote:
> ... make sense of what they’re reading.
Some of us have that problem with type-embellished code now.I'm not
sure a little language would be such a bad idea. 🤔Fortunately, my
relationship to the working world allows me to simply ignore explicit
typi
> ... make sense of what they’re reading.
Some of us have that problem with type-embellished code now. I'm not sure a
little language would be such a bad idea. 🤔 Fortunately, my relationship
to the working world allows me to simply ignore explicit typing. 😉
Way, way BITD I recall leaning on a cru
The advantage to users of keeping the languages the same is that readers of
your code don’t have to learn two disparate syntaxes to make sense of what
they’re reading. One of Python’s enduring strengths has been its readability.
In many ways, type annotations challenge that, but the trade-off
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 a really
> stupid idea, but let me post it again on the off chance that it isn’t a
> stupid idea but was
Indeed, there needs to be a way to get back and forth from the little typing
language to Python and back.
That’s why I suggested the t-string format: in analogy to f-strings you could
use {expression} constructs in there that would be evaluated in the normal
Python environment (and syntax).
Fo
08.01.22 01:59, jack.jan...@cwi.nl пише:
>> If I can make a wild suggestion: why not create a little language for
>> type specifications?
We need a way to define aliases. For example, write:
Data = Mapping[str, Sequence[Tuple[int, T]]]
Factory = Callable[[int, Iterable[str]], Optional[list[Data[T
19 matches
Mail list logo
