Hello,
On Wed, 2 Dec 2020 18:33:49 +1100
Chris Angelico wrote:
[]
> > > So do you think that the strict mode can help people to create a
> > > JIT for Python?
> >
> > That's my aspiration for the strict mode, yes. (I provide "full
> > disclosure" on that fact.) Beyond that, strict mode, is we
Hello,
On Wed, 2 Dec 2020 18:39:42 +1100
Chris Angelico wrote:
> On Wed, Dec 2, 2020 at 6:37 PM Paul Sokolovsky
> wrote:
> > A sufficiently smart JIT is sufficiently hard to develop. As an
> > example, a most well-known and most-used Python implementation,
> > CPython, doesn't have any JIT at a
On Wed, Dec 2, 2020 at 7:11 PM Paul Sokolovsky wrote:
> > Python can't change its execution plans based on type
>
> CPython can't, other Pythons can. Mypyc is a well-known Python which
> changes its execution plans based on type annotations.
"Mypyc is (mostly) not yet useful for general Python de
On Wed, Dec 2, 2020 at 7:24 PM Chris Angelico wrote:
>
> On Wed, Dec 2, 2020 at 7:11 PM Paul Sokolovsky wrote:
> > > Python can't change its execution plans based on type
> >
> > CPython can't, other Pythons can. Mypyc is a well-known Python which
> > changes its execution plans based on type ann
On Wed, Dec 2, 2020 at 7:18 PM Paul Sokolovsky wrote:
>
> Hello,
>
> On Wed, 2 Dec 2020 18:39:42 +1100
> Chris Angelico wrote:
>
> > On Wed, Dec 2, 2020 at 6:37 PM Paul Sokolovsky
> > wrote:
> > > A sufficiently smart JIT is sufficiently hard to develop. As an
> > > example, a most well-known an
On Wed, Dec 02, 2020 at 10:52:30AM +0300, Paul Sokolovsky wrote:
[Paul]
> > > # Leads to a warning: replacing (monkey-patching) a constant slot
> > > (function) with a variable.
> > > mod.func1 = 1
[...]
> That example explores the meaning of:
>
> def func1(): pass
>
> func1 = 1
Those two c
On Wed, Dec 2, 2020 at 9:18 PM Steven D'Aprano wrote:
> > That's "conceptual model". How it's actually implemented is, "bu abuse
> > of notation" is:
> >
> > def decorate(func):
> > ...
> >
> > Works without hitch with the strict mode.
>
> Okay, Chris made the same point.
>
> Is that a language gu
I still like the approach of doing `import typing as t` - (or other short
name of ones preference).
Bcause in the end, any argument used to bring "Any" as a built-in could be
used in favor
of any other element in typing anway.
Typing "t.Any, t.Union, t.Optional" is not a hassle and immediately
Hello,
On Tue, 1 Dec 2020 16:02:21 +
Paul Moore wrote:
> On Tue, 1 Dec 2020 at 15:55, Paul Sokolovsky
> wrote:
>
> > I also forgot to mention very important point in the intro: when you
> > read this proposal, please don't think about "CPython". That for
> > sure will send you the wrong vi
On Wed, 2 Dec 2020 at 09:27, Chris Angelico wrote:
> But you can make your own private research project without asking
> anyone else for information. Why try to synchronize with anyone else?
> Why not just make your own thing and find out what constness can do
> for Python?
I agree. I think it wi
Hi there,
I'm proposing a new builtin method `b` which is a shorthand for the
already-builtin method `breakpoint`. Let me just show you a scratch
implementation: (Yes, I am serious)
```
b = breakpoint
```
PEP 553 proposed the builtin method `breakpoint()` (12 characters) as a
shorthand for `i
This sounds like a bad idea, since 'b' is a common variable name (like all
short names are) and people would fall in the trap of forgetting that
there's a variable named 'b' in scope when they call 'b()'.
If you're having trouble typing 'breakpoint' maybe you can switch to an
editor that has some
On Wed, Dec 2, 2020 at 6:11 AM Paul Sokolovsky wrote:
> Just imagine that if someone wrote previously such a detailed spec,
> which I liked - I might implement it now. And if they actually even
> provided a sample implementation, I might now code changes for it in the
> compiler, and maybe even r
Single-letter variables are common. If your use-case is inserting breakpoints
into arbitrary library code there's no way to guarantee that the builtin won't
be shadowed by some arguments or other local variables, making your alias
extremely unreliable.
def add(a, b):
"""Arbitrary li
Yeah the results were screenshots. Next time, i will just paste them as texts.
Still ‘unknown’ for any unidentified type (including ‘Any’ if not imported)
means it’s not identified as if you didn’t annotate the variable even though
you meant to say ‘Any’ type is ok there. That was my intention.
Thanks for the reply!
> since 'b' is a common variable name (like all
short names are) and people would fall in the trap of forgetting that
there's a variable named 'b' in scope when they call 'b()'.
That's a good point. I should have seen this issue myself.
I have an alternative proposal to add
See https://docs.python.org/3/library/gettext.html.
'_' is the standard name for i18n conversion.
I am against any more standard renaming of breakpoint(). If someone wants
to bind that to another name, they are free to. The point isn't the
length, but the memorability of the name.
On Wed, Dec
17 matches
Mail list logo
