Re: What is Install-Paths-To in WHEEL file?

[Left Right via Python-list]

> others do not and so your notion of what is "accepted"
> is not universally shared.

Why should I or anyone else care about what "others" think?  The
important question is whether what I do is right. And the answer is
"yes". That's why there are rules in the first place instead of
polling.

> if you want to influence anything

Usually, when I interact with representatives of Python community I
have two goals:

1. Typically, I need to show to someone who's paying my salary why
something produced by this community doesn't work. I.e. say, I need to
convince a project manager on a project I'm helping maintain that
deploying using "pip install" is a bad idea. I write an explanation
which I share with the PM and the PyPA people in the bug tracker.
They predictably block me out of fear or frustration.  This gives me a
proof that the thing doesn't work (well), and I'm allowed to do it the
right way. Just like in your previous remark: majority could be a good
initial heuristic, but proof is still a lot better.

2. At this point, I have no hope of convincing the prominent members
of Python community how awful a lot of their decisions are.  There are
plenty of socially constructed obstacles on this way.  The reason I do
this is posterity.  There are plenty of people who aren't influenced
by the internal developments of Python community (outside of it) and
they can see much of its development for what it is: commenting on
this development honestly will help them make an informed choice.
It's also important that those who will come after us will learn about
this contradiction.  Too many bad projects with bad design outlived
their good counterparts due to popularity caused by chance.  And today
those better design and ideas are as good as lost.  For example, Unix
outlived and "overpowered" plenty of better operating systems of its
time. But most programmers today would have no idea what those systems
were and how they were different.  Similarly, x86 ISA.  And plenty
more.

Python changed from its early days of trying to be funny and generally
welcoming of many contradicting ideas and opinions into a Lord of the
Flies community that no longer tolerates differences of opinion.  It's
lost the spirit of "playful cleverness" (as RMS would put it), and
became a "don't think, do as I say" community. I want to make sure
those who come to learn about Python will not miss this aspect of its
history.
-- 
https://mail.python.org/mailman/listinfo/python-list

ANN: EmPy 4.0.1

[Erik Max Francis via Python-list]

I'm pleased to announce the release of EmPy 4.0.1.

The 4._x_ series is a modernization of the software and a revamp of
the EmPy system to update its feature set and make it more consistent
with the latest Python versions and practices.  EmPy 4._x_ was also
relicensed to BSD.

The 4._x_ series adds new markups, including inline comments,
backquote literals, changed if-then-else extended expression,
functional expressions, support for modern Pythonic controls,
stringized and multiline significators, named escapes, diacritics,
icons, and emojis.

It adds support for configuration objects (replacing options
dictionaries); native support for Unicode, file buffering, reference
counted `sys.stdout` proxies and error dispatchers and handlers; fixes
several serious bugs; has a set of full unit and system tests, an
extensive builtin help system; and the online documention has been
rewritten and expanded.

Attempts have been made to make EmPy 4._x_ as backward compatible as
is practical.  Most common markup has not changed, the only changes
being removal of `repr` (in favor of backquote literals); literal
close parenthesis, bracket and brace markup; in-place markup has
changed syntax (to make way for emojis); and custom markup is now
parsed more sensibly.

Most backward-incompatible changes are in the embedding interface.
The `Interpreter` constructor and global `expand` function now require
keyword arguments to prevent further backward compatibility problems,
though effort has been made to make the behavior as backward
compatible as possible.  The supported environment variables have
changed, as well as the filter, diversion and hook APIs, and options
dictionaries no longer exist (in deference to configurations).

For a comprehensive list of changes from 3._x_ to 4._x_, see:



## Introduction:  Welcome to EmPy!

[EmPy](http://www.alcyone.com/software/empy/) is a powerful, robust and 
mature

templating system for inserting Python code in template text.  EmPy
takes a source document, processes it, and produces output.  This is
accomplished via expansions, which are signals to the EmPy system
where to act and are indicated with markup.  Markup is set off by a
customizable prefix (by default the at sign, `@`).  EmPy can expand
arbitrary Python expressions, statements and control structures in
this way, as well as a variety of additional special forms.  The
remaining textual data is sent to the output, allowing Python to be
used in effect as a markup language.

EmPy also supports hooks, which can intercept and modify the behavior
of a running interpreter; diversions, which allow recording and
playback; filters, which are dynamic and can be chained together; and
a dedicated user-customizable callback markup.  The system is highly
configurable via command line options, configuration files, and
environment variables.  An extensive API is also available for
embedding EmPy functionality in your own Python programs.

EmPy also has a supplemental library for additional non-essential
features (`emlib`), a documentation building library used to create
this documentation (`emdoc`), and an extensive help system (`emhelp`)
which can be queried from the command line with the main executable
`em.py` (`-h`/`--help`, `-H`/`--topics=TOPICS`).  The base EmPy
interpreter can function with only the `em.py`/`em` file/module
available.

EmPy can be used in a variety of roles, including as a templating
system, a text processing system (preprocessing and/or
postprocessing), a simple macro processor, a frontend for a content
management system, annotating documents, for literate programming, as
a souped-up text encoding converter, a text beautifier (with macros
and filters), and many other purposes.


### Markup overview

Expressions are embedded in text with the `@(...)` notation;
variations include conditional expressions with `@(...?...!...)`  and
the ability to handle thrown exceptions with `@(...$...)`.  As a
shortcut, simple variables and expressions can be abbreviated as
`@variable`, `@object.attribute`, `@sequence[index]`,
`@function(arguments...)`, `@function{markup}{...}` and
combinations.  Full-fledged statements are embedded with `@{...}`.
Control flow in terms of conditional or repeated expansion is
available with `@[...]`.  A `@` followed by any whitespace character
(including a newline) expands to nothing, allowing string
concatenations and line continuations.  Line comments are indicated
with `@#...` including the trailing newline.  `@*...*` allows inline
comments.  Escapes are indicated with `@\...`; diacritics with
`@^...`; icons with `@|...`; and emoji with `@:...:`.  `@%...` and
`@%%...%%`  indicate "significators," which are distinctive forms of
variable assignment intended to specify per-document identification
information in a format easy to parse externally, _e.g._, to indicate
metadata.  In-place expressions are specified with `@$...$...$`.
Context name and 

Re: Python 3.12.1, Windows 11: shebang line #!/usr/bin/env python3 doesn't work any more

[Thomas Passin via Python-list]

On 1/1/2024 12:26 PM, Mats Wichmann via Python-list wrote:

On 1/1/24 07:11, Thomas Passin via Python-list wrote:

Here's how to find out what program Windows thinks it should use to 
run a ".py" file.  In a console:


C:\Users\tom>assoc .py
.py=Python.File

C:\Users\tom>ftype Python.file
Python.file="C:\Windows\py.exe" "%L" %*


That's not enough. There is now (has been for a while) a layered system, 
and this gives you just one layer, there may be other associations that 
win out.


Per somebody who actually knows:

 > The only way to determine the association without reimplmenting the 
shell's search is to simply ask the shell via AssocQueryString. Possibly 
PowerShell can provide this information. – Eryk Sun


"Possibly", eh?  In fact, on my system those layers must be in effect, 
since ftype claims that the "py" launcher will be used but in actual 
fact the old Python 3.9.9 is used instead, as I wrote earlier.  This is 
verified by this tiny Python script:


# Optional shebang line here
import sys
print(sys.executable)

Then run it with "py", a proposed shebang line, its plain name on the 
command line, whatever.  That will tell you for sure which Python 
executable gets launched by which technique.


On Windows 10, a shebang line gets ignored in favor of Python 3.9.9 (if 
invoked by the script name alone) or Python 3.12.1 (if invoked by the 
"py" launcher).


--
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3.12.1, Windows 11: shebang line #!/usr/bin/env python3 doesn't work any more

[Mats Wichmann via Python-list]

On 1/1/24 07:11, Thomas Passin via Python-list wrote:

Here's how to find out what program Windows thinks it should use to run 
a ".py" file.  In a console:


C:\Users\tom>assoc .py
.py=Python.File

C:\Users\tom>ftype Python.file
Python.file="C:\Windows\py.exe" "%L" %*


That's not enough. There is now (has been for a while) a layered system, 
and this gives you just one layer, there may be other associations that 
win out.


Per somebody who actually knows:

> The only way to determine the association without reimplmenting the 
shell's search is to simply ask the shell via AssocQueryString. Possibly 
PowerShell can provide this information. – Eryk Sun



--
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3.12.1, Windows 11: shebang line #!/usr/bin/env python3 doesn't work any more

[Mats Wichmann via Python-list]

On 1/1/24 04:02, Sibylle Koczian via Python-list wrote:

Am 30.12.2023 um 04:04 schrieb Mike Dewhirst via Python-list:


I had assumed the OP had installed Python from the Microsoft shop and 
that's where py.exe must have come from.




In fact I didn't say in my post that I always get Python from 
python.org. When I started to use the language there was no Python from 
any Microsoft shop (I'm not sure there was a Microsoft shop, it was in 
the last millenium, Python 1.5 or 1.6). So I tend to forget that 
possible download source.


But in all this thread I didn't see a single explanation for my current 
situation: one and the same shebang line works on Windows 10 / Python 
3.11 and doesn't work on Windows 11 / Python 3.12. I suspect Windows, 
because a change in the way Python 3.12 uses shebang lines should be 
visible in the documentation.


The shebang support in the Python Launcher is documented here:

https://docs.python.org/3/using/windows.html#shebang-lines

That says the line you list originally:

> My shebang line is usually "#!/usr/bin/env python3"

means look for python3 in PATH.  Do you have one? If you don't have one, 
you'll get one you don't want: the stupid Microsoft shim that, which if 
run interactively, encourages you to install from the Microsoft store. 
You should be able to disable this.


File suffix associations are a different thing - they give me no end of 
headaches on Windows. They start out bound to the shim, and should 
rebind to the launcher when you install, but then things can steal it. 
If you install Visual Studio Code with Python extensions, then it takes 
over the running of .py files - if you click in the explorer, you'll get 
it open in the editor, not run.  I've argued about this, to no avail 
(plays havoc with my testsuite, which in some places tries to execute 
Python scripts as a cli command).


And then I've got this:

C:\Users\mats\SOMEWHERE>py -0
 -V:3.13  Python 3.13 (64-bit)
 -V:3.12 *Python 3.12 (64-bit)
 -V:3.11  Python 3.11 (64-bit)
 -V:3.10  Python 3.10 (64-bit)
 -V:3.9   Python 3.9 (64-bit)
 -V:3.8   Python 3.8 (64-bit)
 -V:3.7   Python 3.7 (64-bit)
 -V:3.6   Python 3.6 (64-bit)

# Okay, it knows about lots of Python versions, and shows a default of 3.12

C:\Users\mats\SOMEWHERE>py
Python 3.12.1 (tags/v3.12.1:2305ca5, Dec  7 2023, 22:03:25) [MSC v.1937 
64 bit (AMD64)] on win32

Type "help", "copyright", "credits" or "license" for more information.
>>> ^Z

# Great, that works just as expected

C:\Users\mats\SOMEWHERE>py test.py
Python was not found; run without arguments to install from the 
Microsoft Store, or disable this shortcut from Settings > Manage App 
Execution Aliases.


# wait, what? if "py" worked, why doesn't "py test.py"?


--
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3.12.1, Windows 11: shebang line #!/usr/bin/env python3 doesn't work any more

[Thomas Passin via Python-list]

On 1/1/2024 8:19 AM, Thomas Passin via Python-list wrote:

On 1/1/2024 6:02 AM, Sibylle Koczian via Python-list wrote:

Am 30.12.2023 um 04:04 schrieb Mike Dewhirst via Python-list:


I had assumed the OP had installed Python from the Microsoft shop and 
that's where py.exe must have come from.




In fact I didn't say in my post that I always get Python from 
python.org. When I started to use the language there was no Python 
from any Microsoft shop (I'm not sure there was a Microsoft shop, it 
was in the last millenium, Python 1.5 or 1.6). So I tend to forget 
that possible download source.


But in all this thread I didn't see a single explanation for my 
current situation: one and the same shebang line works on Windows 10 / 
Python 3.11 and doesn't work on Windows 11 / Python 3.12. I suspect 
Windows, because a change in the way Python 3.12 uses shebang lines 
should be visible in the documentation.


Happy new year to all!
Sibylle


Happy New Year!

I speculated that the shebang line didn't work on Windows 10 either, but 
you didn't realize it because the file associations were right to launch 
".py" programs with the right version of Python.  When the newer version 
of Python got installed, the default Python program to use, was not 
updated correctly, and the shebang line still has nothing to do with the 
launch failure.  This could happen if other the older install went into 
Program Files, while the newer one went into 
%USERPROFILE%\AppData\Local\Programs\Python.


This was backed up with all of 5 minutes of experimenting on my own 
computer, on which Windows launches ".py" programs with an old install 
of Python 3.9.9, but the py launcher launches Python 3.12 by default.


Since I am avoiding Windows 11, I can't try anything on it, so my 
thoughts above may not be relevant.


The Python docs for 3.12.1 cover shebang lines at

https://docs.python.org/3/using/windows.html

"If the first line of a script file starts with #!, it is known as a 
“shebang” line. Linux and other Unix like operating systems have native 
support for such lines and they are commonly used on such systems to 
indicate how a script should be executed. This launcher allows the same 
facilities to be used with Python scripts on Windows and the examples 
above demonstrate their use.


To allow shebang lines in Python scripts to be portable between Unix and 
Windows, this launcher supports a number of ‘virtual’ commands to 
specify which interpreter to use. The supported virtual commands are:


/usr/bin/env
/usr/bin/python
/usr/local/bin/python
python

For example, if the first line of your script starts with

#! /usr/bin/python
The default Python will be located and used. As many Python scripts 
written to work on Unix will already have this line, you should find 
these scripts can be used by the launcher without modification. If you 
are writing a new script on Windows which you hope will be useful on 
Unix, you should use one of the shebang lines starting with /usr."


But

"The /usr/bin/env form of shebang line has one further special property. 
Before looking for installed Python interpreters, this form will search 
the executable PATH for a Python executable matching the name provided 
as the first argument. This corresponds to the behaviour of the Unix env 
program, which performs a PATH search. If an executable matching the 
first argument after the env command cannot be found, but the argument 
starts with python, it will be handled as described for the other 
virtual commands. The environment variable PYLAUNCHER_NO_SEARCH_PATH may 
be set (to any value) to skip this search of PATH.


Shebang lines that do not match any of these patterns are looked up in 
the [commands] section of the launcher’s .INI file. This may be used to 
handle certain commands in a way that makes sense for your system. The 
name of the command must be a single argument (no spaces in the shebang 
executable), and the value substituted is the full path to the 
executable (additional arguments specified in the .INI will be quoted as 
part of the filename)."




Here's how to find out what program Windows thinks it should use to run 
a ".py" file.  In a console:


C:\Users\tom>assoc .py
.py=Python.File

C:\Users\tom>ftype Python.file
Python.file="C:\Windows\py.exe" "%L" %*

If your ".py" files are associated to the py.exe launcher, as mine are, 
then the launcher may try to use your shebang line and you need to make 
sure there aren't any spaces where there shouldn't be.


If your ".py" files are not associated with py.exe, the shebang line 
probably won't be used for anything.



--
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3.12.1, Windows 11: shebang line #!/usr/bin/env python3 doesn't work any more

[Thomas Passin via Python-list]

On 1/1/2024 6:02 AM, Sibylle Koczian via Python-list wrote:

Am 30.12.2023 um 04:04 schrieb Mike Dewhirst via Python-list:


I had assumed the OP had installed Python from the Microsoft shop and 
that's where py.exe must have come from.




In fact I didn't say in my post that I always get Python from 
python.org. When I started to use the language there was no Python from 
any Microsoft shop (I'm not sure there was a Microsoft shop, it was in 
the last millenium, Python 1.5 or 1.6). So I tend to forget that 
possible download source.


But in all this thread I didn't see a single explanation for my current 
situation: one and the same shebang line works on Windows 10 / Python 
3.11 and doesn't work on Windows 11 / Python 3.12. I suspect Windows, 
because a change in the way Python 3.12 uses shebang lines should be 
visible in the documentation.


Happy new year to all!
Sibylle


Happy New Year!

I speculated that the shebang line didn't work on Windows 10 either, but 
you didn't realize it because the file associations were right to launch 
".py" programs with the right version of Python.  When the newer version 
of Python got installed, the default Python program to use, was not 
updated correctly, and the shebang line still has nothing to do with the 
launch failure.  This could happen if other the older install went into 
Program Files, while the newer one went into 
%USERPROFILE%\AppData\Local\Programs\Python.


This was backed up with all of 5 minutes of experimenting on my own 
computer, on which Windows launches ".py" programs with an old install 
of Python 3.9.9, but the py launcher launches Python 3.12 by default.


Since I am avoiding Windows 11, I can't try anything on it, so my 
thoughts above may not be relevant.


The Python docs for 3.12.1 cover shebang lines at

https://docs.python.org/3/using/windows.html

"If the first line of a script file starts with #!, it is known as a 
“shebang” line. Linux and other Unix like operating systems have native 
support for such lines and they are commonly used on such systems to 
indicate how a script should be executed. This launcher allows the same 
facilities to be used with Python scripts on Windows and the examples 
above demonstrate their use.


To allow shebang lines in Python scripts to be portable between Unix and 
Windows, this launcher supports a number of ‘virtual’ commands to 
specify which interpreter to use. The supported virtual commands are:


/usr/bin/env
/usr/bin/python
/usr/local/bin/python
python

For example, if the first line of your script starts with

#! /usr/bin/python
The default Python will be located and used. As many Python scripts 
written to work on Unix will already have this line, you should find 
these scripts can be used by the launcher without modification. If you 
are writing a new script on Windows which you hope will be useful on 
Unix, you should use one of the shebang lines starting with /usr."


But

"The /usr/bin/env form of shebang line has one further special property. 
Before looking for installed Python interpreters, this form will search 
the executable PATH for a Python executable matching the name provided 
as the first argument. This corresponds to the behaviour of the Unix env 
program, which performs a PATH search. If an executable matching the 
first argument after the env command cannot be found, but the argument 
starts with python, it will be handled as described for the other 
virtual commands. The environment variable PYLAUNCHER_NO_SEARCH_PATH may 
be set (to any value) to skip this search of PATH.


Shebang lines that do not match any of these patterns are looked up in 
the [commands] section of the launcher’s .INI file. This may be used to 
handle certain commands in a way that makes sense for your system. The 
name of the command must be a single argument (no spaces in the shebang 
executable), and the value substituted is the full path to the 
executable (additional arguments specified in the .INI will be quoted as 
part of the filename)."



--
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3.12.1, Windows 11: shebang line #!/usr/bin/env python3 doesn't work any more

[Barry via Python-list]

> On 1 Jan 2024, at 11:14, Sibylle Koczian via Python-list 
>  wrote:
> 
> But in all this thread I didn't see a single explanation for my current 
> situation: one and the same shebang line works on Windows 10 / Python 3.11 
> and doesn't work on Windows 11 / Python 3.12. I suspect Windows, because a 
> change in the way Python 3.12 uses shebang lines should be visible in the 
> documentation.

See my earlier reply with info on ftype etc output.
What do you see on your windows 10 vs windows 11?

Barry


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3.12.1, Windows 11: shebang line #!/usr/bin/env python3 doesn't work any more

[Sibylle Koczian via Python-list]

Am 30.12.2023 um 04:04 schrieb Mike Dewhirst via Python-list:


I had assumed the OP had installed Python from the Microsoft shop and 
that's where py.exe must have come from.




In fact I didn't say in my post that I always get Python from 
python.org. When I started to use the language there was no Python from 
any Microsoft shop (I'm not sure there was a Microsoft shop, it was in 
the last millenium, Python 1.5 or 1.6). So I tend to forget that 
possible download source.


But in all this thread I didn't see a single explanation for my current 
situation: one and the same shebang line works on Windows 10 / Python 
3.11 and doesn't work on Windows 11 / Python 3.12. I suspect Windows, 
because a change in the way Python 3.12 uses shebang lines should be 
visible in the documentation.


Happy new year to all!
Sibylle


--
https://mail.python.org/mailman/listinfo/python-list