"Immutable", like C. Not rebound has another keyword, in Java for
example (final). If we want to only avoid rebounding, I think const
will be a bit confusing for C/C++ people.
(I wrote "immutable" because in C constness can be removed)
On Tue, 1 Dec 2020 at 01:12, Chris Angelico wrote:
>
> On Tu
Hello,
On Mon, 30 Nov 2020 17:26:00 -0500
David Mertz wrote:
> On Mon, Nov 30, 2020, 5:20 AM Paul Sokolovsky
>
> > So, if anything, we're re-tracing JavaScript steps. We're in dire
> > need of const'ness in the language.
>
>
> Somehow I've used Python for 22 years without experiencing that
Hello,
On Tue, 1 Dec 2020 11:43:07 +
Rob Cliffe wrote:
[]
> >> Somehow "dire" doesn't strike me as the right word Maybe you
> >> were looking for "conceivably useful in niche cases."?
> > Perhaps we can bargain on "really useful in many cases".
> >
> >
> Can I echo Chris Angelico's
Hello,
On Tue, 1 Dec 2020 15:16:11 +0300
Paul Sokolovsky wrote:
[]
> If you want immutable dict you [know whom to thank for the lack of it
> - stroked thru] can use types.MappingProxyType, as was explained (it's
> all about PEP603).
No, apparently I meant PEP416
https://www.python.org/dev/peps
On Tue, 1 Dec 2020 at 13:16, Paul Sokolovsky wrote:
> If you want immutable dict you [know whom to thank for the lack of it -
> stroked thru] can use types.MappingProxyType, as was explained (it's
> all about PEP603).
>
> The last case with immutable dict also shows that proliferation of both
> mu
Hello,
Recently, there was a discussion of language-level (vs just
stdlib-level, like currently done by "typing" module) "const"
annotation. The discussion mentioned that the initial
implementation would have the best-effort semantics, i.e. don't
guarantee "full" constant semantics, effectively, i
Hello,
(This is the full version of the proposal. You can start with
"abstract" of it at
https://mail.python.org/archives/list/[email protected]/thread/ZLQ5KJLG2LD4B7VIU2CEQ256CZ7NCUGV/).
# StrictMode
Created Saturday 21 November 2020
## Introduction
This proposal seeks to introduce opt-
Hello,
I see that code listing was partially garbled (code merged into some
comments). It shouldn't be too bad to disambiguate it, but let me try
to repost the code again:
```
import mod
# Leads to a warning: replacing (monkey-patching) a constant slot (function)
with a variable.
mod.func1 =
On Wed, Dec 2, 2020 at 2:29 AM Paul Sokolovsky wrote:
> def fun():
> # Imports are not allowed at run-time
> import mod2
> # But you can re-import module previously imported at import-time.
> import mod
Wait, what? No. No no no. Please do not do ANYTHING like this. Having
suffered
Hello,
On Wed, 2 Dec 2020 02:39:38 +1100
Chris Angelico wrote:
> On Wed, Dec 2, 2020 at 2:29 AM Paul Sokolovsky
> wrote:
> > def fun():
> > # Imports are not allowed at run-time
> > import mod2
> > # But you can re-import module previously imported at
> > import-time. import mod
>
Hi Paul it's an interesting proposal. I have a couple clarifying questions
about it.
On Tue, Dec 1, 2020 at 10:32 AM Paul Sokolovsky wrote:
> Effectively, with the current Python execution model, all code is
> executed at "import-time". This proposal seeks to introduce
> well-defined distinction
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 vibes. Think about "Python". ;-)
By which you mean "CPython and all other i
On Wed, Dec 2, 2020 at 2:53 AM Paul Sokolovsky wrote:
>
> Hello,
>
> On Wed, 2 Dec 2020 02:39:38 +1100
> Chris Angelico wrote:
>
> > On Wed, Dec 2, 2020 at 2:29 AM Paul Sokolovsky
> > wrote:
> > > def fun():
> > > # Imports are not allowed at run-time
> > > import mod2
> > > # But yo
On Tue, Dec 1, 2020 at 10:38 AM Paul Sokolovsky wrote:
> And the const is the cheapest way to make Python a tad faster (for
> sure open up possibilities for further optimizations), which should be
> accessible even to such an old clumsy behemoth as CPython.
>
This is at least the 50th idea I've
Hello,
On Tue, 1 Dec 2020 16:41:36 +
David Mertz wrote:
> On Tue, Dec 1, 2020 at 10:38 AM Paul Sokolovsky
> wrote:
>
> > And the const is the cheapest way to make Python a tad faster (for
> > sure open up possibilities for further optimizations), which should
> > be accessible even to such
On Tue, Dec 1, 2020 at 5:43 PM Paul Sokolovsky wrote:
> That's in the eye of the beholder, I'm afraid. So, if you don't want to
> be convinced of those clarity improvements, you'll never be.
>
It's hard to be convinced by something that neither you nor anyone else on
the thread has actually pres
There exist TWO highly successful, widely used, JIT compilers for Python.
PyPy and Numba. Neither one of them would have any use whatsoever for this
constantness. Or if you believe otherwise, get a developer of one of those
to comment so. JIT'd Python simply is not slow, even compared to compile
I think that what you want is another language, that already exists
and it's RPython:
https://rpython.readthedocs.io/en/latest/rpython.html
See constants paragraph.
RPython is used to create PyPy, not to limit normal Python programming :-)
___
Python-i
Hello,
On Tue, 1 Dec 2020 10:59:04 -0500
Ricky Teachey wrote:
> Hi Paul it's an interesting proposal. I have a couple clarifying
> questions about it.
>
> On Tue, Dec 1, 2020 at 10:32 AM Paul Sokolovsky
> wrote:
>
> > Effectively, with the current Python execution model, all code is
> > execu
On Tue, Dec 1, 2020 at 3:16 PM Paul Sokolovsky wrote:
> > 2. In order to maintain the distinction between "import time" and "run
> > time", will it be illegal to explicitly run __main__() in the __main__
> > module at import time? If not, would __main__() still be run (a
> > *second time*) at run
Hello,
On Tue, 1 Dec 2020 21:05:23 +0100
Marco Sulla wrote:
> I think that what you want is another language, that already exists
> and it's RPython:
>
> https://rpython.readthedocs.io/en/latest/rpython.html
I embarked to read RPython docs several times, and always found that I
stop right at t
On Tue, Dec 01, 2020 at 06:53:35PM +0300, 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 vibes. Think about "Python". ;-)
I never think *only* of CPytho
Hello,
On Tue, 1 Dec 2020 19:09:28 +
David Mertz wrote:
> There exist TWO highly successful, widely used, JIT compilers for
> Python. PyPy and Numba. Neither one of them would have any use
> whatsoever for this constantness.
Of course not. What PyPy needed were European Commission grants,
n
> I never think *only* of CPython when reading PEPs. Unless the PEP is
> clearly and obviously about an implementation detail of CPython, I
> always read them as proposing a *Python* language change. Doesn't
> everyone?
CPython Extension Proposals should be called CEPs
[image: --]
Felipe V. Rodr
Hello,
On Wed, 2 Dec 2020 07:47:53 +1100
Steven D'Aprano wrote:
> On Tue, Dec 01, 2020 at 06:53:35PM +0300, 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 y
Hello,
On Wed, 2 Dec 2020 03:02:26 +1100
Chris Angelico wrote:
[]
> If there are special-purpose cut-down implementations that provide a
> more restricted environment in return for some other feature (say,
> "being able to run in a web browser", or "being able to run on a
> microcontroller"), t
On Wed, Dec 2, 2020 at 9:10 AM Paul Sokolovsky wrote:
> On Wed, 2 Dec 2020 03:02:26 +1100
> Chris Angelico wrote:
> > If there are special-purpose cut-down implementations that provide a
> > more restricted environment in return for some other feature (say,
> > "being able to run in a web browser
Hello,
On Wed, 2 Dec 2020 09:16:56 +1100
Chris Angelico wrote:
> On Wed, Dec 2, 2020 at 9:10 AM Paul Sokolovsky
> wrote:
> > On Wed, 2 Dec 2020 03:02:26 +1100
> > Chris Angelico wrote:
> > > If there are special-purpose cut-down implementations that
> > > provide a more restricted environmen
On Tue, 1 Dec 2020 at 23:49, Paul Sokolovsky wrote:
> On Wed, 2 Dec 2020 09:16:56 +1100
> Chris Angelico wrote:
> > If the restricted execution model is incompatible with most Python
> > scripts, why would anyone bother to use it?
>
> E.g. because someone who would want to experiment with JIT, wo
Felipe Rodrigues writes:
> > I never think *only* of CPython when reading PEPs. Unless the PEP is
> > clearly and obviously about an implementation detail of CPython, I
> > always read them as proposing a *Python* language change. Doesn't
> > everyone?
>
> CPython Extension Proposals should
On 2/12/20 6:43 am, Paul Sokolovsky wrote:
That's why I don't make such claims, and instead making a very
different one: that idea with absolute certainty will remove *one* of
50 problems which keep Python slow.
But without an implementation demonstrating an actual speed
improvement, you're onl
Paul wrote:
> Below is an example of strict mode program with comments explaining
> various features:
>
> ```
> import mod
>
> # Leads to a warning: replacing (monkey-patching) a constant slot
> (function) with a variable.
> mod.func1 = 1
(Aside: the literal `1` is not a variable, and variables
On Wed, Dec 2, 2020 at 10:45 AM Steven D'Aprano wrote:
> Is monkey-patching disallowed because `mod.func1` is defined as a
> constant? Or are all functions automatically considered to be
> constants?
>
> If the later, then decorators won't work in strict mode:
>
> @decorate
> def func():
>
On Wed, Dec 02, 2020 at 12:24:00AM +0300, Paul Sokolovsky wrote:
> > But I don't understand your comment. Are you suggesting that CPython
> > will be exempt from this proposal? Or that the proposal is aimed at
> > helping alternative implementations?
>
> I just think that some of people who thi
I'm seeing the need to strip annotations from type hints after they've
been fetched using get_type_hints(..., include_extras=True). There's a
convenient function, typing._strip_annotations,which does exactly that.
Why not make it public?
___
Python-ideas
On Mon, Nov 30, 2020 at 05:19:13PM +0400, Abdulla Al Kathiri wrote:
> In python 3.9, I get the following error:
>
>
> In python 3.10, I get no runtime errors:
>
>
>
>
Did you forget to paste the text? Or did gmail eat it?
> However, Pylance (I am not sure about mypy) didn’t recognize Any.
They pasted the code / results as screenshots.
But you got the gist.
In the future, it's really better to use plain text for email lists.
-CHB
On Tue, Dec 1, 2020 at 9:33 PM Steven D'Aprano wrote:
> On Mon, Nov 30, 2020 at 05:19:13PM +0400, Abdulla Al Kathiri wrote:
>
> > In python 3.9, I ge
Hello,
On Wed, 2 Dec 2020 00:10:41 +0100
Marco Sulla wrote:
> On Tue, 1 Dec 2020 at 23:49, Paul Sokolovsky
> wrote:
> > On Wed, 2 Dec 2020 09:16:56 +1100
> > Chris Angelico wrote:
> > > If the restricted execution model is incompatible with most Python
> > > scripts, why would anyone bother
On Wed, Dec 2, 2020 at 6:20 PM Paul Sokolovsky wrote:
>
> Hello,
>
> On Wed, 2 Dec 2020 00:10:41 +0100
> Marco Sulla wrote:
>
> > On Tue, 1 Dec 2020 at 23:49, Paul Sokolovsky
> > wrote:
> > > On Wed, 2 Dec 2020 09:16:56 +1100
> > > Chris Angelico wrote:
> > > > If the restricted execution model
Hello,
On Wed, 02 Dec 2020 12:36:23 +1300
Greg Ewing wrote:
> On 2/12/20 6:43 am, Paul Sokolovsky wrote:
> > That's why I don't make such claims, and instead making a very
> > different one: that idea with absolute certainty will remove *one*
> > of 50 problems which keep Python slow.
>
> But
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 all, not only "sufficiently advanced", but even
> "simple". But simple would
Hello,
On Wed, 2 Dec 2020 10:42:25 +1100
Steven D'Aprano wrote:
> Paul wrote:
>
>
> > Below is an example of strict mode program with comments explaining
> > various features:
> >
> > ```
> > import mod
> >
> > # Leads to a warning: replacing (monkey-patching) a constant slot
> > (function) w
42 matches
Mail list logo
