date:20201201

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) with a variable.
> > mod.func1 = 1  
> 
> (Aside: the literal `1` is not a variable, and variables aren't 
> first-class citizens in Python. We can't bind "a variable" to a name, 
> only the variable's value.)

Nobody calls literal "1" a variable. That example explores the meaning
of:

def func1(): pass

func1 = 1

And from a PoV of a human programmer, it's like written in the comment
- first, the symbol (name) "func1" is defined as a function, and then
it's redefined as a variable.

> Is monkey-patching disallowed because `mod.func1` is defined as a 
> constant?

What "disallowed" do you mean? The example above clearly says "Leads to
a warning". At "run-time" (i.e. eventually, after you've done the
monkey-patching), it's disallowed, yes.

> Or are all functions automatically considered to be 
> constants?

That's the case, right.

> 
> If the later, then decorators won't work in strict mode:
> 
> @decorate
> def func():
> ...
> 
> is defined as:
> 
> # define-decorate-replace
> def func():
> ...
> 
> func = decorate(func)

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.

> 
> so if functions are automatically const, decorators won't work.
> 
> Occasionally I find that decorator syntax is not sufficient, and I've 
> used the explicit "define-decorate-replace" form. That won't work 
> either.

You'll get a warning, and if you're smarter than the strict mode in
that case, you can disable it (in the same sense that you can disable
any warning in Python).

> Is it only *monkey-patching* from outside of the module that is 
> disallowed, or any rebindings to functions, including within the
> owning module itself?

In the *run-time* (aka "eventually") any "assign" operation on a const
name is disallowed, and additionally adding any new names is
disallowed, ditto for deletions.

At the *import-time*, everything is allowed.

> 
> If the later, that's also going to break the common idiom:
> 
> def func():
> # Slow Python version.
> 
> # maybe replace with fast C version
> from c_accelerators import *
> 
> under strict mode.

Will lead to a warning. Got bitten by that myself, yeah. (I ove
"from foo import *"). Had to finally implement __all__ in Pycopy due to
those strict mode problems, can you believe?

Anyway, re: example above would either need to mend your your ways
(e.g. run "import *" first then conditionally define missing funcs), or
disable the warning.

[Have to stop here, will look at the rest later, thanks for comments.]

[]

-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/GBXENRGLJIR3UNL7UEZJSLAMW7R5NN6U/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Making the for statement work better with nested functions

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 be much easier to add (to any project). And
> my proposal explores how to get specific advantages from even simple JIT
> techniques.

If all you're doing is exploring, why a PEP? Just create a "Python
with constness" variant, and go to town. What's the advantage of
having CPython and Jython and PyPy and everyone else synchronize on
your proposed syntax?

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/5Z7NWD7ICTFN7MSDZGG4Z4IQ7MSPYGWY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Making the for statement work better with nested functions

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 without an implementation demonstrating an actual speed
> improvement, you're only speculating that the problem is,
> in fact, keeping Python slow.

That summarizes it well, yes. Just as PEP266/PEP267/PEP280, I'm
speculating on how to optimize namespace lookups. I however aspire to
improve on them, providing wider, more coherent picture on how to
achieve that. I also speculate in the same way as PEP509, which was
accepted, and actually implemented in CPython, without any improvements
on CPython speed (on its own). But it lays a framework to "maybe do it
somewhere, somewhen". My proposal is very similar, but explores a
different direction of changes.

https://www.python.org/dev/peps/pep-0266/
https://www.python.org/dev/peps/pep-0267/
https://www.python.org/dev/peps/pep-0280/
https://www.python.org/dev/peps/pep-0509/

> I'm also not convinced that the proposed solution is necessary
> to remove the problem. A sufficiently smart JIT could notice,

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 be much easier to add (to any project). And
my proposal explores how to get specific advantages from even simple JIT
techniques.

> for example, that a particular function doesn't mutate its
> arguments and pass them in an optimised way, without needing
> any declarations.
> 
> -- 
> Greg

[]

-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ZZUVPQJXJM3Z4UM55HVXLNGB635O7AMA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: [RFC] "Strict execution mode" (TL;DR version)

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 is incompatible with most Python
> > > > scripts, why would anyone bother to use it?
> > >
> > > E.g. because someone who would want to experiment with JIT, would
> > > need to apply similar restrictions anyway.
> >
> > 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 well, strict.
> So, it may be interesting to people who want more "strictness" in
> Python. For example, some time ago, "type annotations" were introduced,
> and quite many people (though not everyone of course) aspire to make
> their programs more strict using them. The "strict mode" proposed here
> is similar, but explores different dimension of strictness.
>

Type annotations don't add any strictness. They just give information
so that an external tool can choose to provide information to the
coder. Python can't change its execution plans based on type
annotations, because they have no actual runtime meaning; and the
corollary of that is that type annotations are fairly safe. Annotating
a function won't suddenly break it (assuming the annotation is
syntactically valid).

If constness can be used to actually change behaviour, then it really
does have to restrict the language, and that's quite a different
beast.

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/6GW4K5NHEWZFPXGO2BQ36VHUTC23EQDF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: [RFC] "Strict execution mode" (TL;DR version)

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 to use it?  
> >
> > E.g. because someone who would want to experiment with JIT, would
> > need to apply similar restrictions anyway.  
> 
> 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 well, strict.
So, it may be interesting to people who want more "strictness" in
Python. For example, some time ago, "type annotations" were introduced,
and quite many people (though not everyone of course) aspire to make
their programs more strict using them. The "strict mode" proposed here
is similar, but explores different dimension of strictness.

> Why can't this be done in a separate project, like PyPy or Pycopy?

Both (and many more around!) of those projects are Pythons. So, not
only it can be, it should be done in as many projects as possible. (In
which specific, is up to their maintainers.)

[]

-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/Z6PRWOHCU6JDMEXVIZNKNIOU2RQXNSBX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Making "Any" a builtin

2020-12-01 Thread Christopher Barker

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 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.
> Instead it made it “Unknown”.
>
> That's probably a question for the Pylance devs, but my guess is that
> anything flagged as "Any" type is the same as flagging it as "I don't
> know what that type is".
>
>
> > In fact, I can put anything in 3.10 annotation and it runs just fine.
> > I am not sure if this is the intention of Python3.10
>
> Yes, Python 3.10 makes the `from __future__ import annotations`
> behaviour occur automatically. See PEP 563:
>
> https://www.python.org/dev/peps/pep-0563/
>
> (At least, I'm guessing that's what is happening here, it has to be a
> guess because I can't see the code you run and the error you get.)
>
>
>
> --
> Steve
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/YMJ5NMD3OQOMKWHMMOZAE3WWGHZJD7OY/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/UGRPHAKLN2D7CKHNIZYKW2X6OIIJU6QV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Making "Any" a builtin

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. Instead it 
> made it “Unknown”.

That's probably a question for the Pylance devs, but my guess is that 
anything flagged as "Any" type is the same as flagging it as "I don't 
know what that type is".


> In fact, I can put anything in 3.10 annotation and it runs just fine. 
> I am not sure if this is the intention of Python3.10 

Yes, Python 3.10 makes the `from __future__ import annotations` 
behaviour occur automatically. See PEP 563:

https://www.python.org/dev/peps/pep-0563/

(At least, I'm guessing that's what is happening here, it has to be a 
guess because I can't see the code you run and the error you get.)



-- 
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/YMJ5NMD3OQOMKWHMMOZAE3WWGHZJD7OY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] s/typing._strip_annotations/typing.strip_annotations/

2020-12-01 Thread Paul Bryan

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 mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/4EIQ2E4PRJH3GOPT2EEQ5QRNHMZMGBLJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: [RFC] "Strict execution mode" (TL;DR version)

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 think in terms of "Python" ==
> "CPython", would have hard time imagining how this "strict mode" came
> by, if they will try to apply it the CPython situation.
> 
> I also don't think that it applies to CPython's approach well. If
> anything, it's kind of "contrarian" approach to how CPython tries to
> do things (e.g. https://www.python.org/dev/peps/pep-0509/).

Are you aware that CPython is the reference implementation of Python the 
language? If you are introducing language features and semantic changes 
that CPython doesn't support, or might not support, than it isn't 
Python, it's a superset (or subset) of the language. Like Cython.

Either that, or you are hoping for a revolution where your proposed 
alternative language becomes so successful that a majority of users 
abandon CPython, PyPy, Nuitka, Stackless, Jython, IronPython etc and 
flock to your restricted language, taking the name "Python" with it.

I don't think that's very likely.

So I don't think you should be thinking about scenarios where other 
implementations take this up and CPython doesn't. Rather, I think 
there are three scenarios:

1. Somebody invents a new language with your proposed semantics, similar 
to other Python-inspired languages as Cython, Boo, Nim and Cobra.

(At least one of those, Cython, is a superset of Python; the others are 
just copying syntax rather than semantics.)

2. CPython takes this up, as an optional extension that other 
implementations are free to ignore.

3. Or CPython takes this up, and makes it mandatory for any interpreter 
claiming to be Python to support it.

I don't think there is any chance of your proposal being blessed as 
official Python semantics without CPython supporting it.

> > Should we be thinking specifically of some alternate implementation?
> 
> I guess that the thinking in terms of "tabula rasa" would help.
> Like, if you forget all the existing CPython baggage, and just face a
> problem of optimizing name lookups, what would you do? This proposal is
> one such exploration.

This would be scenario number 1 above. A brand new language, inspired by 
Python, like Cobra. Or since it is backwards-compatible in non-strict 
mode, perhaps Cython is a better analogy.

Or if you prefer, the Perl-inspired Raku.

-- 
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/YQSJRCQLYQ4X3SC3BGOO6HGJB5BFQ23V/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: [RFC] "Strict execution mode" (TL;DR version)

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():
> ...
>
> is defined as:
>
> # define-decorate-replace
> def func():
> ...
>
> func = decorate(func)
>
> so if functions are automatically const, decorators won't work.
>
> Occasionally I find that decorator syntax is not sufficient, and I've
> used the explicit "define-decorate-replace" form. That won't work
> either.
>

Even though decorator syntax is described as being equivalent to
define-decorate-replace, it actually assigns only once. So if the
definition of "constant" is "may only be bound once", a decorated
function would be fine. (But doing it explicitly wouldn't.)

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/PSQVUILAIASACZQSPZZXZMSWPEHR56VW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: [RFC] "Strict execution mode" (TL;DR version)

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 aren't 
first-class citizens in Python. We can't bind "a variable" to a name, 
only the variable's value.)

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():
...

is defined as:

# define-decorate-replace
def func():
...

func = decorate(func)

so if functions are automatically const, decorators won't work.

Occasionally I find that decorator syntax is not sufficient, and I've 
used the explicit "define-decorate-replace" form. That won't work 
either.

Is it only *monkey-patching* from outside of the module that is 
disallowed, or any rebindings to functions, including within the owning 
module itself?

If the later, that's also going to break the common idiom:

def func():
# Slow Python version.

# maybe replace with fast C version
from c_accelerators import *

under strict mode.

> # Way to define a constant.
> my_cnst: const = 1

That clashes with type annotations. Constantness is not a type of the 
value, it's a statement about the name binding.

x: int = some_expression

is a statement about the permitted values bound to `x`. The type checker 
can take it that `x` will always be bound to an int, and reason from 
that.

x: const = some_expression

tells the type-checker nothing about what type `x` is. Unless it can 
infer the type of `some_expression`, it could only guess that `x` might 
be Any type. That's going to hurt type-checking.

It would be better to introduce an independent syntax for constants. 
Let's say `const`:

const x: int = some_expression

can tell the reader and the type-checker that `x` is an int, even if 
they can't infer the type from the expression, and tell the compiler 
that `x` is a constant.

> # Leads to a warning: replacing (monkey-patching) a constant slot.
> my_cnst: const = 2

A warning? What's the use of that?

Are your constants *actually constant* or are they just advisory? If 
they're just advisory, then we might as well stick with the convention 
to use UPPERCASE names and use a linter that warns if you re-bind a 
"constant".

If you can rebind constants by just suppressing or ignoring the warning, 
then people will rebind constants.

Relevant:

Sometimes I run GUI applications from the command line. Invariably they 
generate a flood of runtime warnings. Clearly developers are paying no 
attention to warnings.

> def fun():
> # Imports are not allowed at run-time
> import mod2
> # But you can re-import module previously imported at import-time.
> import mod

That seems like a pointless complication.

If mod is already imported, why would I need to import it again from 
inside the function? Just to turn it into a local variable?

mylocal = mod

Forbidding any imports inside a function would be annoying and 
frustrating, but at least there's no special cases and exceptions. 
Forbidding *some* imports, but allowing *unnecessary and redundant* 
imports inside a function makes no sense to me.

> # RuntimeError
> my_cnst = 3

`my_cnst` is inside a function, so it should create a local variable, 
not attempt to rebind a global constant.

> # RuntimeError
> mod.func2 = lambda x: 1

Yes you already make it clear that rebinding functions is not allowed.

> global glb1, new
> # RuntimeError: Cannot create new global nameslots at runtime.
> new = 1
> # Nor can delete existing
> del glb1

I know "global variables considered harmful", but this looks to me like 
punishing users of globals for being bad by restricting what they can do 
to make their use of globals *worse* rather than better.

- all globals must be pre-declared and initialised before use;

- functions cannot clean-up after themselves by deleting their unneeded 
globals.

These two restrictions will give the coder annoyance and frustration. 
What advantage does this provide to make up for that?

> # Cheats don't work
> globals()["new"] = 1

That seems like it will probably break a lot of code, assuming you can 
even enforce it. Is your proposal for globals() to no longer return the 
global namespace dict?

> # Leads to a warning: replacing (monkey-patching) a constant slot
> (function). 
> def fun():
> pass
> 
> 
> # fun_var is a variable storing a reference to a function (can store ref
> # to another func).
> fun_var = fun

So is `fun`.

Are you aware that Python's execution model treats:

- function *objects* as first-class values, same as ints, strings, 
floats, lists, etc

- and *names* bound to function

[Python-ideas] Re: Making the for statement work better with nested functions

2020-12-01 Thread Greg Ewing


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 only speculating that the problem is,
in fact, keeping Python slow.

I'm also not convinced that the proposed solution is necessary
to remove the problem. A sufficiently smart JIT could notice,
for example, that a particular function doesn't mutate its
arguments and pass them in an optimised way, without needing
any declarations.

--
Greg
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/5MTXTEUBUHAY3YOFPZV2TXRYVJYHX57G/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: [RFC] "Strict execution mode" (TL;DR version)

2020-12-01 Thread Stephen J. Turnbull

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 be called CEPs

They're rare enough that distinguishing them wouldn't be terribly
useful.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/DXWKJIMVEQFQA76Z3WRWAXXNDRQKGFVE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: [RFC] "Strict execution mode" (TL;DR version)

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, would need
> to apply similar restrictions anyway.

So do you think that the strict mode can help people to create a JIT for Python?
Why can't this be done in a separate project, like PyPy or Pycopy?
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ML3FAKTM67DK6GJWJIJZ5WWYQQFM6FV3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: [RFC] "Strict execution mode" (TL;DR version)

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 environment in return for some other
> > > feature (say, "being able to run in a web browser", or "being
> > > able to run on a microcontroller"), then that's fine,  
> >
> > Kinda yes, except not as vulgar as examples above. More like "being
> > able to develop a JIT which doesn't cost million dollars" (extra
> > points if that still can run on a microcontroller!).  
> 
> That's completely the opposite of what I was talking about, then. If
> the goal is to develop a JIT compiler, then it should surely be part
> of the main implementations of the language - the ones that are
> broadly compatible with each other. Cut-down Python implementations
> are NOT fully compliant with the language spec, and that's okay,
> because nobody expects them to be.
> 
> 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, would need
to apply similar restrictions anyway.

> Does it actually offer
> performance advantages better than PyPy, which JIT-compiles and is
> able to run normal Python scripts?

As I mentioned in another response, it's all contrarian approach, right
from the start. It's not whether PyPy offers performance advantages,
it's whether it runs in the target environments I consider interesting
at all. The answer is NO. I then consider what it does to NOT run in the
environments I find interesting. It runs unmodified scripts, and throws
unlimited amounts of memory at that. So, I see how to modify scripts in
such a way to NOT throw unneeded memory at trivial things, while only
improving the code hygiene.

I get that it's hard to get ;-).

Besides that, it also implements runtime support for "const" variables,
which is closer to matters of CPython level. (E.g., if there's support
for constants, CPython's pattern matching doesn't need to go for ugly
workarounds of forcing to use "case Somewhere.SOMETHING", it can be
just "case SOMETHING:").

> 
> ChrisA

-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/XEUGKYDY22DTIVLN6KT7D4YGSZQSEBUM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: [RFC] "Strict execution mode" (TL;DR version)

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", or "being able to run on a
> > microcontroller"), then that's fine,
>
> Kinda yes, except not as vulgar as examples above. More like "being
> able to develop a JIT which doesn't cost million dollars" (extra
> points if that still can run on a microcontroller!).

That's completely the opposite of what I was talking about, then. If
the goal is to develop a JIT compiler, then it should surely be part
of the main implementations of the language - the ones that are
broadly compatible with each other. Cut-down Python implementations
are NOT fully compliant with the language spec, and that's okay,
because nobody expects them to be.

If the restricted execution model is incompatible with most Python
scripts, why would anyone bother to use it? Does it actually offer
performance advantages better than PyPy, which JIT-compiles and is
able to run normal Python scripts?

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/TP7CXAMOALB25EIPZWEU57L2G4VAYHRN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: [RFC] "Strict execution mode" (TL;DR version)

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"), then that's fine,

Kinda yes, except not as vulgar as examples above. More like "being
able to develop a JIT which doesn't cost million dollars" (extra
points if that still can run on a microcontroller!).

> but that's not a language feature
> - that's a partial implementation that sacrifices the parts it can't
> afford to do. 

The sacrifice is coming more from theoretical constraints on what's
(easily) possible and what's not, not from vulgar constraints like "my
microcontroller doesn't have space for that". How to be a dynamic
language (addressing only dynamic name lookup here) and not suffer from
that? How to have a cake and eat it? A simple answer (and we're
interested in such here) is that you can't. First you have the cake -
and heavy emphasis in the proposal is put on that, so you didn't start
with just breadcrumbs. Then you eat the cake.

To give the right idea of how to look at this stuff, you should
compare this "strict mode" with Python compilers like Mypyc or
Shedskin, and what restrictions they place.

> From the sound of your proposal, this should be part of
> the main Python language and be a normal expectation of code.

I don't know where you got that sound from, because the very
first sentence of the very first "Introduction" section reads:

"This proposal seeks to introduce opt-in "strict execution mode" for
Python language implementations interested in such a feature."

So, is for example the CPython implementation interested?

[]

> Still -1000 on that, partly because you can never guarantee that it'll
> be fast (if only because searching for and loading large numbers of
> files can be very expensive without any single one of them being
> blamed for the cost),

This proposal puts a heavy emphasis on a JIT usecase, and JIT
is known to have its startup costs. JIT is also known to not be
a panacea fro all usecases, why this proposal says that strict mode
doesn't replace "normal" mode, some programs are just bound to be run
in it.

> and partly because two-phase initialization is
> something Python tries hard to avoid.

This proposal specifically introduces two-phase startup sequence, which
does affect imports. Price of magic.

Now, all that in detail discussed in the proposal:
https://github.com/pycopy/PycoEPs/blob/master/StrictMode.md#dynamic-module-imports
(yes, I put it in a repo to link to specific sections). Sneak peeks for
you:

"By far, the most "grave" issue with the strict mode is that dynamic
(at run-time) imports are not supported"

"Let us walk thru why"

"To perform any non-trivial optimization on dynamic languages,
whole-program analysis is required."

"Don't get me wrong - I absolutely love dynamic imports! As an example,
the strict mode was implemented in the Pycopy dialect of Python, and of
5 not completely trivial applications written for Pycopy, 5 use dynamic
imports."

"There is actually yet another option to tackle dynamic imports problem
- to ease restrictions"

So, I feel, and share, your pain ;-).

[]

> Yes, I'm thinking about Python, but unless you specifically tell me
> that this is a narrow special-purpose sublanguage, I'm going to assume
> you want CPython to at least respect this, even if it doesn't take
> advantage of it.

I'd like to have a pure-python implementation running on CPython, yes.
I'm not sure what you mean by "respect this". Any valid strict-mode
program is also a valid normal-mode program. You can treat strict mode
as a kind of type linter - it will pinpoint issues violating
particular discipline (not totally insane), you fix them, and then can
run without it too.

> 
> ChrisA

-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/2OFFDRYC6XKLKJJAJUHU2HOIGFCSYZ6B/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: [RFC] "Strict execution mode" (TL;DR version)

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 you the wrong vibes. Think about "Python". ;-)  
> 
> 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?
> 
> 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 think in terms of "Python" ==
"CPython", would have hard time imagining how this "strict mode" came
by, if they will try to apply it the CPython situation.

I also don't think that it applies to CPython's approach well. If
anything, it's kind of "contrarian" approach to how CPython tries to
do things (e.g. https://www.python.org/dev/peps/pep-0509/).

> Should we be thinking specifically of some alternate implementation?

I guess that the thinking in terms of "tabula rasa" would help.
Like, if you forget all the existing CPython baggage, and just face a
problem of optimizing name lookups, what would you do? This proposal is
one such exploration.

Also Steven, it's literally the response I promised in our initial
thread on the "const" annotation,
https://mail.python.org/archives/list/python-ideas@python.org/message/SQTOWJ6U5SGNXOOXZB53KBTK7O5MKMMZ/

As you can see, it's much more far-fetched than just how to implement
the runtime honoring of the "const" annotation. Because it tries to
"extract" as much as possible already existing constness in Python
programs, and then drafts how to use that to optimize lookups (en
masse, as there're a lot of constness indeed).

If we only need to handle explicit "const" annotations, it's a pretty
small subset of this proposal.

> If not, then the purpose of this "very important point" isn't clear
> to me.

[]

-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/TUVD5PEEUVL3MVH565W7MLI6OLOU5VUK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: [RFC] "Strict execution mode" (TL;DR version)

2020-12-01 Thread Felipe Rodrigues

> 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. Rodrigues
[image: https://]felipevr.com



On Tue, Dec 1, 2020 at 5:47 PM 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 you the wrong vibes. Think about "Python". ;-)
>
> 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?
>
> 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?
>
> Should we be thinking specifically of some alternate implementation? If
> not, then the purpose of this "very important point" isn't clear to me.
>
>
> --
> Steve
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/SM2CSWUKTEAT667USVUSLFMRVRSYPA4K/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/BQX3N2AKY2S3ZWVVT62EVQ5HDRLNGQZI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: [RFC] "Strict execution mode" (TL;DR version)

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,
nothing else. Numba needed a lot of corporate backing for sure too, but
they also needed LLVM bindings. So they picked some guy's module. Then
they threw it away, because it was hard to maintain, and made their
own. While LLVM has always shipped Python bindings. That's absolutely
normal, but shows there's a lot of "random betting" happens even in
"highly successful" projects.

But most importantly, I'm not interested in survivorship bias. I'm not
much interested to know how to write million-dollar JIT projects,
because heck, that's known for decades. I'm interested to know how to
NOT write "million-dollar" JIT projects, and why Unladen Swallow,
Pyston failed. I'm also interested to know how to write JIT projects
which do NOT cost millions of dollars.

All that is quite an unusual hobby, you bet.

> 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 compiled languages. 

Yeah! It's just don't work for stuff you need in a way you need, and too
bloated, so when you want to fix it, you can't.

> Searching for
> maybe-possibly-someday optimizations while ignoring the actual speed
> paths, is silly.

Exactly interested in low-hanging optimizations. Much less interested in
approaches like "we'll feed in some random crap, and LLVM will take
care of it".

So, hopefully, the motivation is clear - I'm doing this stuff, because
it's so obvious thing to do, and the guys who got the same idea
in 2001 or so, didn't seem to have left tangible artifacts beyond
deadlocked PEPs.

> 
> But I'll be moderate and only vote -100, 10x less negative than Paul
> Moore and Chris Angelico :-).

[]

-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/HKHCVSGL3BF2HDWACAXT3WMIT4MKQHKH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: [RFC] "Strict execution mode" (TL;DR version)

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 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?

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?

Should we be thinking specifically of some alternate implementation? If 
not, then the purpose of this "very important point" isn't clear to me.

-- 
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/SM2CSWUKTEAT667USVUSLFMRVRSYPA4K/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: [RFC] "Strict execution mode" (TL;DR version)

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 the top of that page, at the phrase "The exact definition
is “RPython is everything that our translation toolchain can
accept” :)".

You know, I can very relate to that phrase. As a little guy, that's how
I write my stuff - no proper docs, no nothing, and when somebody comes
by asking what's supported or similar, the response is "RTFC!" (where
"C" is "code").

But sorry, I just can't take that from a project which for a long time
received non-trivial funding and which is supposed to serve as a base
for other projects. You can compare that with my "strict mode" proposal
where I try to spell out how the flaming thing works, even though the
idea is banally simple.

That said, that's my experiences with RPython. What are yours? What
have you written with it? I'm especially interested in memory
requirements. "Strict mode" is implemented in Pycopy, which can do more
or less useful things in 16KB of heap, and the strict mode doesn't
regress that much. How does RPython feel in 16KB?

[]

-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/52F6QXCVOKWISSZUH3UYWHHDOPE4JNZZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: [RFC] "Strict execution mode" (full version)

2020-12-01 Thread Ricky Teachey

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 time?
>
> Even the "TL;DR" version gives the idiom to make an application (its
> main module) be compatible with both standard and strict mode. And full
> version gives the details of why it is so. That's pretty much the
> simple(st) method, why do you ask for something else?
>
> >
> > ```
> > __
> >
> > # import time section
> >
> > def __main__():
> > # run time
> > print("foo")
> >
> > __main__()
> > ```
> >
> > Is the output:
> >
> > foo
> > foo
>
> Yes, if run in the strict mode, the __main__() will be executed twice.
>

No not asking for something else, just wanted to make sure I understood.
Thanks!

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/4WU4TF4XXDO6FXZDIKRGPQDEB7BHOINW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: [RFC] "Strict execution mode" (full version)

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
> > executed at "import-time". This proposal seeks to introduce
> > well-defined distinction between import-time vs run-time. For this,
> > it introduces the `__main__()` function, localted in the `__main__`
> > module of the application (from which application execution
> > starts). All top-level code in the `__main__` module is executed to
> > completion, including code in recursively imported modules. This
> > completes the "import-time" phase of the application. After that,
> > the `__main__()` function is executed, which begins the "run-time'
> > phase. 
> 
> Two questions about this.
> 
> 1. What about single module packages? If there is no __main__ module,
> how does the interpreter find my __main__() function?

The application main module loading happens as usual (whether it's
file.py or -m module switch is used). It's just normally, after main
module top-level code finishes execution, the interpreter exits
(because the application exited). In strict mode instead, interpreter
looks up __main__() function in this main module, and executes it.

> 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 time?

Even the "TL;DR" version gives the idiom to make an application (its
main module) be compatible with both standard and strict mode. And full
version gives the details of why it is so. That's pretty much the
simple(st) method, why do you ask for something else?

> 
> ```
> __
> 
> # import time section
> 
> def __main__():
> # run time
> print("foo")
> 
> __main__()
> ```
> 
> Is the output:
> 
> foo
> foo

Yes, if run in the strict mode, the __main__() will be executed twice.

> 
> ...or it is just:
> 
> foo
> 
> ...?
> 
> 
> > ## Discussion and implications
> >
> > The baseline implications should be fairly obvious from the text
> > above:
> >
> > ```
> > def fun():
> > pass
> >
> > # This (defining the function of the same name) will lead to warning
> > # at import-time.
> > def fun():
> > pass
> >
> > import mod
> >
> > # This (assigning to a var in another module) is possible
> > # both at import-time and run-time.
> > mod.var = 1
> >
> > # This will lead to warning at import-time and RuntimeError at
> > runtime. mod.func = lambda *a, **kw: print("Stabbed out!")
> > ```
> >  
> 
> In the above code snippet, are you assuming that mod.func already
> exists, and the last line in the module is redefining the existing
> mod.func, and this is what causes the runtime error?

Yes, that's it.

> 
> ---
> Ricky.


-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/HCHRSD7V6IU2YPABZCOH6JEDRP3HW5NM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: [RFC] "Strict execution mode" (TL;DR version)

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-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/H3HOXPVCGA6BSGUG3BNNWM2JT7ATZ4OF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: [RFC] "Strict execution mode" (TL;DR version)

2020-12-01 Thread David Mertz

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 compiled
languages.  Searching for maybe-possibly-someday optimizations while
ignoring the actual speed paths, is silly.

But I'll be moderate and only vote -100, 10x less negative than Paul Moore
and Chris Angelico :-).

On Tue, Dec 1, 2020 at 4:03 PM 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 vibes. Think about "Python". ;-)
>
> By which you mean "CPython and all other implementations" I assume?
>
> I'm also -1000 on this proposal, even if you just limit it to CPython.
>
> It's not at all clear what prompted this idea, but if you're
> suggesting "modify Python so we can make it faster" then I'd rather
> see a prototype implementation that demonstrated both the limitations
> *and* the improved performance. We shouldn't limit the core language
> based simply on speculative benefits that some implementation might be
> able to achieve.
>
> Paul
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/R5PVEZV36TXRMBXFLOVA26UPFAFD3DRS/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
The dead increasingly dominate and strangle both the living and the
not-yet born.  Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/Z3BRUON6ETG5RX72KVXPUNQSPJJL56VM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Making the for statement work better with nested functions

2020-12-01 Thread David Mertz

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 presented.

Other than posturing about "dire need" and vague hand-waving about
potential speed-ups, there's absolutely nothing that makes this desirable.
Not even a small toy example, let alone a more real world need. Yes, some
other languages have block level scopes. And some other languages have
constants. But you have not even *suggested* why this would be good for
Python itself (I guess other than "gotta keep up with the Javascript
programmers").

It's not especially common, but I've sometimes written:

for i in big_collection:
if condition():
break
# other stuff
... intervening code ...
if i+1 < len(big_collection):
something_about_early_stop()

On the other hand, I can count on one hand, without using any fingers, the
number of times when I would have used:

for const i in big_collection:
# whatever

It's just not a need that arises.

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 compiled
languages. Searching for maybe-possibly-someday optimizations while
ignoring the actual speed paths, is silly.

--
The dead increasingly dominate and strangle both the living and the
not-yet born. Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/MLSOAET3LWF7ARIPCSQB5YGLF2ZCCN7E/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Making the for statement work better with nested functions

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 an old clumsy behemoth as CPython.
> >  
> 
> This is at least the 50th idea I've seen that will "with absolute
> certainty make Python faster" 

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.

Hard-boiled pragmatists among us won't get it, but it's a true
intellectual pleasure to be left with 49 problems instead of 50.

Besides, if every advanced Python programmer peeled one of such
problems, before waving bye-bye and flying over to Haskell, we'd
already have a fast Python. In that regard, I continue a
well-established Python tradition. (And indeed, we have many fast
Pythons, working under various conditions. We still need to pull
further as a community to go over the summit where "a Python" is by
default "fast", not "slow").

> ... where the first 49 failed to do so,
> often despite significant institutional investment in money and
> skilled developers.
> 
> Obviously, there *have* been actual speed improvements.  But they
> rarely seem to follow the "obvious intuitions" of speculation on
> python-ideas.

Challenge accepted - let's on python-ideas speculate on actual speed
improvements, not wait with popcorn for "significant institutional
investment" (can do both).

> > > 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".
> >  
> 
> I've still yet to see an example that is very compelling.  Not speed,
> I'll treat that with skepticism. Just in terms of notably improved
> code clarity.

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.

-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/M5WFSMPX2NUWTV7XQDWNRUWTTAOAPQBJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Making the for statement work better with nested functions

2020-12-01 Thread David Mertz

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 seen that will "with absolute certainty
make Python faster" ... where the first 49 failed to do so, often despite
significant institutional investment in money and skilled developers.

Obviously, there *have* been actual speed improvements.  But they rarely
seem to follow the "obvious intuitions" of speculation on python-ideas.

> > 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".
>

I've still yet to see an example that is very compelling.  Not speed, I'll
treat that with skepticism. Just in terms of notably improved code clarity.

-- 
The dead increasingly dominate and strangle both the living and the
not-yet born.  Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/BN3UHLFKSAKI6WNAESZ2S2TWCOKYC7O4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: [RFC] "Strict execution mode" (TL;DR version)

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 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 under JavaScript's highly restrictive import system (and
> > actually been glad for it, since the alternative is far worse), I do
> > not want ANY version of Python to give up the full power of its import
>
> Then it's luck that ALL versions and dialects of Python aren't under
> your control ;-).

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"), then that's fine, but that's not a language feature
- that's a partial implementation that sacrifices the parts it can't
afford to do. From the sound of your proposal, this should be part of
the main Python language and be a normal expectation of code.

> > system, including the ability for a module to be imported only when
> > it's actually needed. Imports inside functions allow a program to have
> > optional dependencies, or dependencies that might be slow to load (eg
> > numpy), and without that, even running your script with "--help" has
> > to process every single import in the entire file.
>
> But didn't you you already spotted a line which says that the strict
> mode also aspires to improve on the Python module practices? Under
> strict mode's firm but benevolent rule, there won't be slowly-loading
> modules any more. All imports will be fast. And modules which want to be
> slow will do that in their module.init() function.

Still -1000 on that, partly because you can never guarantee that it'll
be fast (if only because searching for and loading large numbers of
files can be very expensive without any single one of them being
blamed for the cost), and partly because two-phase initialization is
something Python tries hard to avoid. You don't get code like this:

f = file("/path/to/file")
f.open()

db = psycopg2.database("postgresql://user@localhost/dbname")
db.connect()

Two-phase initialization means that everything in that module (or
class, as the case may be) has to first check if it's been
initialized. Why not just initialize it when you create the object?
Why not just initialize when you import the module?

How much do you really gain by forcing this? You get stub modules
everywhere that aren't initialized yet, but have to be imported just
to satisfy this restriction. Current code simply... doesn't import it.

> 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". ;-)
>

Yes, I'm thinking about Python, but unless you specifically tell me
that this is a narrow special-purpose sublanguage, I'm going to assume
you want CPython to at least respect this, even if it doesn't take
advantage of it.

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/NDC4BBHOUJ66PCBIGUBVLQND7HZPGIEC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: [RFC] "Strict execution mode" (TL;DR version)

2020-12-01 Thread Paul Moore

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 implementations" I assume?

I'm also -1000 on this proposal, even if you just limit it to CPython.

It's not at all clear what prompted this idea, but if you're
suggesting "modify Python so we can make it faster" then I'd rather
see a prototype implementation that demonstrated both the limitations
*and* the improved performance. We shouldn't limit the core language
based simply on speculative benefits that some implementation might be
able to achieve.

Paul
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/R5PVEZV36TXRMBXFLOVA26UPFAFD3DRS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: [RFC] "Strict execution mode" (full version)

2020-12-01 Thread Ricky Teachey

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 between import-time vs run-time. For this, it
> introduces the `__main__()` function, localted in the `__main__` module
> of the application (from which application execution starts). All
> top-level code in the `__main__` module is executed to completion,
> including code in recursively imported modules. This completes the
> "import-time" phase of the application. After that, the `__main__()`
> function is executed, which begins the "run-time' phase.
>

Two questions about this.

1. What about single module packages? If there is no __main__ module, how
does the interpreter find my __main__() function?

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 time?

```
__

# import time section

def __main__():
# run time
print("foo")

__main__()
```

Is the output:

foo
foo

...or it is just:

foo

...?


> ## Discussion and implications
>
> The baseline implications should be fairly obvious from the text above:
>
> ```
> def fun():
> pass
>
> # This (defining the function of the same name) will lead to warning
> # at import-time.
> def fun():
> pass
>
> import mod
>
> # This (assigning to a var in another module) is possible
> # both at import-time and run-time.
> mod.var = 1
>
> # This will lead to warning at import-time and RuntimeError at runtime.
> mod.func = lambda *a, **kw: print("Stabbed out!")
> ```
>

In the above code snippet, are you assuming that mod.func already exists,
and the last line in the module is redefining the existing mod.func, and
this is what causes the runtime error?

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/C46OBXSH72W6ICLMIM3UPXR3Y6327TBU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: [RFC] "Strict execution mode" (TL;DR version)

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  
> 
> Wait, what? No. No no no. Please do not do ANYTHING like this. Having
> suffered under JavaScript's highly restrictive import system (and
> actually been glad for it, since the alternative is far worse), I do
> not want ANY version of Python to give up the full power of its import

Then it's luck that ALL versions and dialects of Python aren't under
your control ;-). 

> system, including the ability for a module to be imported only when
> it's actually needed. Imports inside functions allow a program to have
> optional dependencies, or dependencies that might be slow to load (eg
> numpy), and without that, even running your script with "--help" has
> to process every single import in the entire file.

But didn't you you already spotted a line which says that the strict
mode also aspires to improve on the Python module practices? Under
strict mode's firm but benevolent rule, there won't be slowly-loading
modules any more. All imports will be fast. And modules which want to be
slow will do that in their module.init() function.

> 
> -1000.

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". ;-)

> 
> ChrisA

-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/GKRUGXJVZYFBTHD27IPY5NXF6CNDDI3S/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: [RFC] "Strict execution mode" (TL;DR version)

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 under JavaScript's highly restrictive import system (and
actually been glad for it, since the alternative is far worse), I do
not want ANY version of Python to give up the full power of its import
system, including the ability for a module to be imported only when
it's actually needed. Imports inside functions allow a program to have
optional dependencies, or dependencies that might be slow to load (eg
numpy), and without that, even running your script with "--help" has
to process every single import in the entire file.

-1000.

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/EP24L35CMMDBBYAFVPAP2T4FJNHFRG4T/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: [RFC] "Strict execution mode" (TL;DR version)

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 = 1

# Leads to a warning: replacing (monkey-patching) a constant slot (function).
mod.func2 = lambda: None

# Way to define a constant.
my_cnst: const = 1

# Leads to a warning: replacing (monkey-patching) a constant slot.
my_cnst: const = 2

glb1 = 100

def fun():
# Imports are not allowed at run-time
import mod2
# But you can re-import module previously imported at import-time.
import mod

# RuntimeError
my_cnst = 3

# RuntimeError
mod.func2 = lambda x: 1

global glb1, new
# RuntimeError: Cannot create new global nameslots at runtime.
new = 1
# Nor can delete existing
del glb1

# Cheats don't work
globals()["new"] = 1

# Leads to a warning: replacing (monkey-patching) a constant slot (function).
def fun():
pass

# fun_var is a variable storing a reference to a function (can store ref
# to another func).
fun_var = fun

# fun2 is an alias of fun
fun2: const = fun

# Run-time execution starts with this function. This clearly delineates
# import-time from run-time: a module top-level code is executed at
# import-time (including import statements, which execute top-level code
# of other modules recursively). When that is complete, strict mode
# interpreter switches to run-time mode (restrictions enabled) and
# executes __main__().
def __main__():
fun()

# This statement is not executed when program runs in strict mode.
# It is executed when it is run in normal mode, and allow to have
# the same startup sequence (execution of __main__()) for both cases.
if __name__ == "__main__":
__main__()
```

On Tue, 1 Dec 2020 18:26:48 +0300
Paul Sokolovsky  wrote:

> 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

[]

-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/LRABLTXTAIA6MF3SKBCAP2NM2P5B72W4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] [RFC] "Strict execution mode" (full version)

Hello,

(This is the full version of the proposal. You can start with
"abstract" of it at
https://mail.python.org/archives/list/python-ideas@python.org/thread/ZLQ5KJLG2LD4B7VIU2CEQ256CZ7NCUGV/).


# StrictMode
Created Saturday 21 November 2020

## Introduction

This proposal seeks to introduce opt-in "strict execution mode" for
Python language implementations interested in such a feature. Under
this mode, some "overdynamic" language features are restricted in a
reasonable way. The primary motivation for these restrictions are
opportunities for simple(r) to implement runtime optimizations.
However, it is also believed that the "strict mode" may also help on
its own with clarity and maintenance of large(r) Python codebases.

The "strict mode" is an opt-in alternative execution mode to the
standard one. The standard mode is not intended to be replaced by the
strict mode. It's up to an application to decide whether it supports
strict mode or not (based on requirements of its dependent libraries if
course). Any program which can (correctly, without errors) run in the
strict mode can also run in the standard mode without any changes in
behavior.

## Summary and scope

Proposed are restrictions on modifications, at run-time, to "namespace
dictionaries" of classes and modules. The baseline restriction is
prohibition of addition of new attributes (and by extension, removals
of them). Further extension is introduction of "const" attributes, and
prohibition of their redefinition (reassignment) at the run-time. It is
believed that the restrictions applied are relatively modest and can be
surmounted by the interested Python programmers. Moreover, they should
coincide (or being fairly close) with restrictions that some codebases
may already place, and overall, would lead to improved structure and
maintenance of large (and small) codebases.

This proposal explicitly does not consider attribute dictionaries of
objects. It is considered to be the matter of fact that addition of new
object atributes at run-time is a widely used feature in Python
programs. Besides, the Python language already offers means to control
that - object's class `__slots__` attribute. Namely, if it doesn't
contain `__dict__` meta-attribute, then creation of new object
attributes (beyond declared in `__slots__`) is prohibited.

## Definitions

Namespace dictionary - a (special) dictionary used to implement
attributes of modules and classes. Note that each script in Python is a
module ("default" module for scripts is called "__main__"). In this
regard, global variables are attributes of a module (and thus stored in
module's namespace dict). One way namespace dictionaries differ from
normal Python dictionaries is that namespace dicts' keys are always
strings. And for many implementation, they are actually interned
strings (because we want to lookup attributes efficiently by a single
comparison operation of a dictionary key, instead of comparing string
content). 

Namespace slot - an entry in a namespace dictionary, consisting of
attribute name and its value. This proposal adds extra property of a
namespace slot - "constness". This property would make namespace
dictionaries even more distinct from normal Python dictionaries, which
don't have such property. Implementation wise, a "const" bit would be
almost certainly stored in a "key" part of the dictionary entry,
because a "value" part can hold an arbitrary Python value, wheras per
above, the a "key" part stores only a string, so it would be "easier"
to find an extra space for the "const" bit.

Import-time - timespan of program execution where imports of other
modules and initialization of current module happens.

Run-time - timespan of program execution when all imports and
initialization complete, and a program "runs" per se.

To avoid mixing up the (very specific) meaning of these terms with
similarly sounding generic terms (like "runtime"), we write them using
hyphens, like we did above.

## Motivation

The underlying motivation for the introduction of the strict mode is to
avoid expensive dynamic lookup-by-name during program runtime. Such
lookups inherently require operation of *searching*, and searching is
inherently slow. A common topic of argument is how much searching is
slower, especially how much it affects the overall program performance
(of which searching for dynamic resolution of names is just one
overhead). This proposal doesn't try to go in such arguments.

And if that sentence didn't emphasize it enough, let us elaborate: this
proposal avoids that argument completely. The proposal is based on the
idea that to not be slow, you should avoid slow operations. Languages
which are built with "don't perform slow searching operations for
variable lookups", so-called "static languages", for example C/C++, are
known to be generally fast. Of course, dynamic vs static
variable/attribute lookup is not the only thing which differentiates
Python from C/C++. That is why this proposal avoids

[Python-ideas] [RFC] "Strict execution mode" (TL;DR version)

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, in its baseline,
being the same annotation as any other. There was immediately raised a
question how a full, eventual implementation would look like, and the
posted proposal showcases *one* of the options.

This initial post provides "TL;DR" version, also know as "abstract".
The following post has the full proposal narrative.

-

## Abstract

This proposal seeks to define "constant namespace
slot" (variables/functions/methods) for Python, including both implicit
and explicit (user-annotated) slots. Further, the proposal seeks to
define necessary changes to language semantics to actually uphold the
constant property (i.e. inability to redefine). To preserve as much as
possible the benefits of Python's dynamic nature and metaprogramming it
enables, the proposal introduces 2 distinct execution modes:
"Import-time", which preserves full existing Python execution semantics
(albeit with some warnings to point at "problem spots"), and
"Run-time", where constant property of the designated name slots
(including implicitly constant nameslots, like functions/methods) is
enforced (attempts to assign to such slots lead to runtime exception).
Overall, the new execution variant is named "strict mode". 

It is believed that these measures would allow to develop more
structured and more robust Python code, especially in big codebases. At
the same time, the underlying motivation for the strict mode is to ease
the development of runtime optimizers for Python, in particular JIT
compilers.

Support infrastructure for the strict mode is defined: means to enable
it, compatibility measures with standard execution mode.

The strict mode is intended to be an opt-in feature, not replacing the
default Python execution mode. 

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

# Leads to a warning: replacing (monkey-patching) a constant slot
(function). mod.func2 = lambda: None

# Way to define a constant.
my_cnst: const = 1

# Leads to a warning: replacing (monkey-patching) a constant slot.
my_cnst: const = 2

glb1 = 100


def fun():
# Imports are not allowed at run-time
import mod2
# But you can re-import module previously imported at import-time.
import mod

# RuntimeError
my_cnst = 3

# RuntimeError
mod.func2 = lambda x: 1

global glb1, new
# RuntimeError: Cannot create new global nameslots at runtime.
new = 1
# Nor can delete existing
del glb1

# Cheats don't work
globals()["new"] = 1


# Leads to a warning: replacing (monkey-patching) a constant slot
(function). def fun():
pass


# fun_var is a variable storing a reference to a function (can store ref
# to another func).
fun_var = fun

# fun2 is an alias of fun
fun2: const = fun


# Run-time execution starts with this function. This clearly delineates
# import-time from run-time: a module top-level code is executed at
# import-time (including import statements, which execute top-level code
# of other modules recursively). When that is complete, strict mode
# interpreter switches to run-time mode (restrictions enabled) and
# executes __main__().
def __main__():
fun()


# This statement is not executed when program runs in strict mode.
# It is executed when it is run in normal mode, and allow to have
# the same startup sequence (execution of __main__()) for both cases.
if __name__ == "__main__":
__main__()
```



-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ZLQ5KJLG2LD4B7VIU2CEQ256CZ7NCUGV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Making the for statement work better with nested functions

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
> mutable and immutable type counterparts doesn't scale. What we need is
> some generic types.roproxy (yes, all lower-case, to emphasize its
> fundementalness) which can be applied to any object, and will filter
> out __setitem__ and __setattr__ (and del counterparts, and custom list
> of mutator methods, you get an idea).

Is it not more simple for the moment to have it only as a sort of
warning for the developer? I mean, if the object is mutated, a warning
is raised at runtime. If the object is rebound, a SyntaxError is
emitted.

I suppose that this is possible for dicts, since they have an internal
attribute ma_version_tag, that is increased every time the dict
mutates. Classes have __dict__. Don't know for the other builtin
types.

Speed optimizations could be done later, if they are possible.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/4GIKATDJM6BOJO3S5WZXP27RYMXGU4I3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Making the for statement work better with nested functions

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/pep-0416/ . Heh, even a language lawyer
would get lost in the PEPs ;-).

[]

-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/X7XIWMDHPZSZFNYOTBZBBWTB6OLKYLUB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Making the for statement work better with nested functions

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 question to Marco Sulla?  Are you
> advocating syntax (possibly including a keyword "const") that means
>      (a) "will not be rebound"
>      (b) "is immutable"
>      (c) both
>      (d) something else

I'm personally advocating for ability to mark variable bindings as not
reboundable, i.e. the choice (a).

This is clearly orthogonal feature to object immutability, the choice
(b).

These also should be separate, easily (well, without further
restrictions) composable. A solution which welds both too firmly is
apparently not flexible enough.

And I don't mention variable value/object mutability, aka choice (b),
in my posts at all because Python already has fairly advanced control
of that. Almost each fundamental data structure in Python comes both in
mutable and immutable counterparts, e.g.:

mutable list - immutable tuple
mutable set - immutable frozenset
mutable object - (may come as surprise, but becomes obvious if you
think about it) - immutable namedtuple

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
mutable and immutable type counterparts doesn't scale. What we need is
some generic types.roproxy (yes, all lower-case, to emphasize its
fundementalness) which can be applied to any object, and will filter
out __setitem__ and __setattr__ (and del counterparts, and custom list
of mutator methods, you get an idea). 

> (and if you can spare the time, give a toy example or two explaining
> how they would behave).

I'm about to post my pseudo-PEP on the so-called "strict mode", which
uses const'ness as one of its biggest constituents, it will have various
examples.

In the meantime, let's theorize what it might mean for sys.argv to get
a "const" annotation? (It doesn't have to, just a figure of thought.)

You would still be able to run .append() and .clear() on it. But you
would be 100% sure that the type of value stored in sys.argv is a list,
and only a list. (So for example, you could write an optimized JIT which
would bypass any type checks and support for other possible types when
accessing sys.argv, but inline operations which work directly on lists
without extra checks).

> Because I've read every post in this thread (though I haven't kept
> them) and I'm still not clear.
> If we're clear about what we're discussing, we can avoid talking past 
> each other.
> Thanks
> Rob Cliffe

-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/7TRMSBU4APBH5EPYD6HITYI2YLTASSR4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Making the for statement work better with nested functions

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
> direness.
> 
> I've taught thousands of students already experienced in other
> languages (most with constants) without anyone noting the need). I've
> been *read* by MILLIONS of readers using Python without mentioning
> the need to me.

I suspect someone will eventually write a drama along the lines of
"Best-kept Secret from the Python Community", second only to Oedipus
Rex.

Perhaps, you were talking to the wrong people? Perhaps you should teach
students like https://www.youtube.com/watch?v=x2IQP8iug3c ? That guy
reached only 0.3M, not millions like you, but spread the word that
Python is slow.

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.
(Alternative, recently quoted, is to spend $1+M on that.
https://mail.python.org/archives/list/python-...@python.org/message/RDXLCH22T2EZDRCBM6ZYYIUTBWQVVVWH/)

And I'm mentioning just that usecase with a bow to my fixation on
Python JITting, other people already mentioned more.   

> 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".

-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/TPHOZPMEHNORKB5STTGB46GNLU5M6I47/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Making the for statement work better with nested functions