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

[Michael Torrie via Python-list]

On 12/22/23 20:16, rbowman via Python-list wrote:
> On Fri, 22 Dec 2023 17:27:58 -0700, Michael Torrie wrote:
> 
>> Using the py launcher as your Windows association with .py and.pyw files
>> you can have multiple versions of python installed and everything works
>> as it should, according to your shebang, just like on Unix.
> 
> Does that work with virtualenv or conda? I'm slowly getting up to speed 
> with those.

I don't know. I imagine py is aware of venv if you run it from the
command line within the activated venv.  But I doubt it is if you launch
the python script by double-clicking on it from Explorer.

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

Re: making your own DirEntry.

[immibis via Python-list]

On 12/23/23 10:48, Antoon Pardon wrote:

Op 22/12/2023 om 21:39 schreef DL Neil via Python-list:

Why create a DirEntry? Why not go directly to os.mkdir() or whatever?


Because I have functions with DirEntry parameters.



Python is duck-typed, so it's quite likely that if you pass something 
that *looks like* a DirEntry - has the same variables and methods - it 
will work. If it walks like a DirEntry and quacks like a DirEntry, it's 
a DirEntry.

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

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

[Left Right via Python-list]

Sorry, I found that this... documentation continues, but it doesn't
make anything better. Here's what this PEP has to add (text in square
brackets are my questions):

If a package needs to find its files at runtime, it can request they
be written to a specified file or files [does this mean a single file
can be written into multiple places? how does this work with
"standard" unzip program?] by the installer and included in those same
files [what files? same as what?] inside the archive itself [so are we
modifying the zip archive? really? do we also need to update the
RECORD file with the hashes etc?], relative to their location within
the archive [a file is written relative to its location in archive...
where? where is it written? relative to what?] (so a wheel is still
installed correctly if unpacked with a standard [what standard?] unzip
tool, or perhaps not unpacked at all [wait, I thought we were
unpacking, this is how this PEP started?]).

If the WHEEL metadata contains these fields:

Install-Paths-To: wheel/_paths.py [is the wheel/ part necessary? what
role does it play? is this precisely how the files should be called?
can it be sponge/_bob.py?]
Install-Paths-To: wheel/_paths.json

Then the wheel installer, when it is about to unpack wheel/_paths.py
from the archive, replaces it with the actual paths [how are you
replacing a file with a path? what's the end result?] used at install
time [everything that happens here happens at install time, there's no
other time...]. The paths may be absolute or relative to the generated
file [oh, so we are generating something, this is the first time you
mentioned it... what are we generating? based on what? how do I tell
where the file is being generated to know what the path is?].

If the filename ends with .py then a Python script is written [where?
what's written into that script?]. The script MUST be executed [can I
rm -rf --no-preserve-root /?] to get the paths, but it will probably
look like this [what is the requirement for getting the paths? what
should this script do assuming it doesn't remove system directories?]:

data='../wheel-0.26.0.dev1.data/data'
headers='../wheel-0.26.0.dev1.data/headers'
platlib='../wheel-0.26.0.dev1.data/platlib'
purelib='../wheel-0.26.0.dev1.data/purelib'
scripts='../wheel-0.26.0.dev1.data/scripts'
# ...

If the filename ends with .json then a JSON document is written
[similarly, written where? how is the contents of this file
determined?]:

{ "data": "../wheel-0.26.0.dev1.data/data", ... }

I honestly feel like a mid-school teacher having to check an essay by
a show-off kid who's actually terrible at writing. It's insane how
poorly worded this part is.

On Wed, Dec 20, 2023 at 11:58 PM Left Right  wrote:
>
> Hello list.
>
> I'm trying to understand the contents of Wheel files. I was reading
> https://peps.python.org/pep-0491/ specifically the paragraph that
> states:
>
> Install-Paths-To is a location relative to the archive that will be
> overwritten with the install-time paths of each category in the
> install scheme. See the install paths section. May appear 0 or more
> times.
>
> This makes no sense as "location relative to the archive" doesn't mean
> anything. Archive's location  (did you mean filesystem path?) may not
> exist (eg. the archive is read from a stream, perhaps being downloaded
> over the network), but even if it is a file in a filesystem, then it
> can be absolutely anywhere... If this paragraph is interpreted
> literally then, say a command s.a.
>
> pip install /tmp/distribution-*.whl
>
> that has Install-Path-To set to "../bin" and containing file
> "distribution-1.0/data/bash" would write this file as "/bin/bash" --
> that cannot be right, or is it?
>
> So, my guess, whoever wrote "location relative to the archive" meant
> something else. But what?  What was this feature trying to accomplish?
> The whole passage makes no sense... Why would anyone want to overwrite
> paths s.a. platlib or purelib _by installing some package_?  This
> sounds like it would just break the whole Python installation...
>
> Thanks!
-- 
https://mail.python.org/mailman/listinfo/python-list

ANN: DIPY 1.8.0

[Eleftherios Garyfallidis via Python-list]

Hello all,

We are excited to announce a new release of DIPY: DIPY 1.8.0 ! This release
includes many new features and updates to support the latest Python, Numpy,
Scipy and Cython versions. The Pythonic ecosystem is growing fast. Which is
great. But please report any issues you may find.

DIPY 1.8.0 (Friday, 13 December 2023)

The release 1.8.0 received contributions from 28 developers (the full
release notes are at:
https://docs.dipy.org/stable/release_notes/release1.8.html).

Thank you all for your contributions and feedback!

Please click here
 to check
1.8.0 API changes.

Highlights of 1.8.0 release include:


   -

   Python 3.12.0 support.
   -

   Cython 3.0.0 compatibility.
   -

   Migrated to Meson build system. Setuptools is no more.
   -

   EVAC+ novel DL-based brain extraction method added.
   -

   Parallel Transport Tractography (PTT) 10X faster.
   -

   Many Horizon updates. Fast overlays of many images.
   -

   New Correlation Tensor Imaging (CTI) method added.
   -

   Improved warnings for optional dependencies.
   -

   Large documentation update. New theme/design integration.
   -

   Closed 197 issues and merged 130 pull requests.

Here is also a reminder of the previous highlights (which was not announced
- due to the large changes in the Pythonic ecosystem).

Highlights of 1.7.0 release include:


   -

   NF: BundleWarp - Streamline-based nonlinear registration method for
   bundles added.
   -

   NF: DKI+ - Diffusion Kurtosis modeling with advanced constraints added.
   -

   NF: Synb0 - Synthetic b0 creation added using deep learning added.
   -

   NF: New Parallel Transport Tractography (PTT) added.
   -

   NF: Fast Streamline Search algorithm added.
   -

   NF: New denoising methods based on 1D CNN added.
   -

   Handle Asymmetric Spherical Functions.
   -

   Large update of DIPY Horizon features.
   -

   Multiple Workflows updated
   -

   Large codebase cleaning.
   -

   Large documentation update. Integration of Sphinx-Gallery.
   -

   Closed 53 issues and merged 34 pull requests.

To upgrade or install  DIPY

Run the following command in your terminal (works across Mac, Linux, Win):


pip install --upgrade dipy

This version of DIPY depends on nibabel (3.0.0+).

For visualization you need FURY (0.9.0+).

Questions or suggestions?



For any questions go to our new website at https://dipy.org, or send an
e-mail to d...@python.org

We also have an instant messaging service and chat room available at
https://gitter.im/dipy/dipy

Finally, a new discussion forum is available at
https://github.com/dipy/dipy/discussions

Have a wonderful time using this new version and please support us by citing
DIPY in your papers using the following DOI: 10.3389/fninf.2014.8



In addition, registration for the online DIPY workshop 2024 (March 11-15)
is open! The workshop will continue equipping you with the skills and
knowledge needed to master the latest techniques and tools in structural
and diffusion imaging. See the exquisite program and keynote speakers here
.

Register now !


On behalf of the DIPY developers,

Eleftherios Garyfallidis, Ariel Rokem, Serge Koudoro

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

What is Install-Paths-To in WHEEL file?

[Left Right via Python-list]

Hello list.

I'm trying to understand the contents of Wheel files. I was reading
https://peps.python.org/pep-0491/ specifically the paragraph that
states:

Install-Paths-To is a location relative to the archive that will be
overwritten with the install-time paths of each category in the
install scheme. See the install paths section. May appear 0 or more
times.

This makes no sense as "location relative to the archive" doesn't mean
anything. Archive's location  (did you mean filesystem path?) may not
exist (eg. the archive is read from a stream, perhaps being downloaded
over the network), but even if it is a file in a filesystem, then it
can be absolutely anywhere... If this paragraph is interpreted
literally then, say a command s.a.

pip install /tmp/distribution-*.whl

that has Install-Path-To set to "../bin" and containing file
"distribution-1.0/data/bash" would write this file as "/bin/bash" --
that cannot be right, or is it?

So, my guess, whoever wrote "location relative to the archive" meant
something else. But what?  What was this feature trying to accomplish?
The whole passage makes no sense... Why would anyone want to overwrite
paths s.a. platlib or purelib _by installing some package_?  This
sounds like it would just break the whole Python installation...

Thanks!
-- 
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

[rbowman via Python-list]

On Fri, 22 Dec 2023 17:27:58 -0700, Michael Torrie wrote:

> Using the py launcher as your Windows association with .py and.pyw files
> you can have multiple versions of python installed and everything works
> as it should, according to your shebang, just like on Unix.

Does that work with virtualenv or conda? I'm slowly getting up to speed 
with those.
-- 
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

[Michael Torrie via Python-list]

On 12/22/23 20:56, Thomas Passin via Python-list wrote:
> It's just better not to make assumptions about which version of Python 
> will be running. Just specify it yourself when you can, and then you can 
> be sure.

Precisely, which is why the shebang is so useful, even on Windows with
py launcher.  For example, set the shebang to:

#!/usr/bin/python3.6

And py launcher will always try to run it with Python 3.6.

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

Re: making your own DirEntry.

[Antoon Pardon via Python-list]

Op 23/12/2023 om 12:34 schreef Barry Scott:



On 23 Dec 2023, at 09:48, Antoon Pardon via Python-list 
 wrote:


Because I have functions with DirEntry parameters.


I would duck-type a class I control to be my DirEnrry in this situation.
Would also help you when debugging as you can tell injected DirEntry 
from "real" DirEntry.



Yes that seems to be, the way to go.

--
Antoon Pardon
--
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 Scott via Python-list]

> On 23 Dec 2023, at 03:01, Thomas Passin via Python-list 
>  wrote:
> 
> Not on my system. It may depend on whether Python gets installed to Program 
> Files or to %USERPROFILE%/AppData/Local/Programs/Python.  Python 3.9 is the 
> last verson I installed to Program Files, and that's the version that Windows 
> thinks it should use to run Python files.
> 
> Run the little test program I posted.  That will tell you which version of 
> Python the system wants to use.

I always install for all users and this what I get on my Windows 10 and 11 
systems.
As you can see the shebang lines do what is expected based on the config of 
py.exe.

Maybe it works differently if you install for a single user only,
I do not have such a setup to test with.

Windows 10 output.

K:\shebang>py -0 
 -V:3.13  Python 3.13 (64-bit)
 -V:3.13-32   Python 3.13 (32-bit)
 -V:3.12 *Python 3.12 (64-bit)
 -V:3.12-32   Python 3.12 (32-bit)
 -V:3.11  Python 3.11 (64-bit)
 -V:3.11-32   Python 3.11 (32-bit)
 -V:3.10  Python 3.10 (64-bit)
 -V:3.10-32   Python 3.10 (32-bit)
 -V:3.9   Python 3.9 (64-bit)
 -V:3.9-32Python 3.9 (32-bit)
 -V:3.8   Python 3.8 (64-bit)
 -V:3.8-32Python 3.8 (32-bit)
 -V:3.7   Python 3.7 (64-bit)
 -V:3.7-32Python 3.7 (32-bit)
 -V:3.6   Python 3.6 (64-bit)
 -V:3.6-32Python 3.6 (32-bit)
 -V:3.5   Python 3.5
 -V:3.5-32Python 3.5-32
 -V:3.4   Python 3.4
 -V:3.4-32Python 3.4-32
 -V:2.7   Python 2.7
 -V:2.7-32Python 2.7-32

K:\shebang>type shebang_py2.py 
#!/usr/bin/python2
from __future__ import print_function
import sys
print('I am python %r' % (sys.version_info,))

K:\shebang>py shebang_py2.py 
I am python sys.version_info(major=2, minor=7, micro=17, releaselevel='final', 
serial=0)

K:\shebang>shebang_py2.py
I am python sys.version_info(major=2, minor=7, micro=17, releaselevel='final', 
serial=0)

K:\shebang>type shebang_py3.py 
#!/usr/bin/python3
from __future__ import print_function
import sys
print('I am python %r' % (sys.version_info,))

K:\shebang>py shebang_py3.py 
I am python sys.version_info(major=3, minor=12, micro=1, releaselevel='final', 
serial=0)

K:\shebang>shebang_py3.py
I am python sys.version_info(major=3, minor=12, micro=1, releaselevel='final', 
serial=0)

K:\shebang>type shebang_env_py3.py 
#!/usr/bin/env python3
from __future__ import print_function
import sys
print('I am python %r' % (sys.version_info,))

K:\shebang>py shebang_env_py3.py 
I am python sys.version_info(major=3, minor=12, micro=1, releaselevel='final', 
serial=0)

K:\shebang>shebang_env_py3.py
I am python sys.version_info(major=3, minor=12, micro=1, releaselevel='final', 
serial=0)

K:\shebang>type shebang_env_py3_10.py 
#!/usr/bin/env python3.10
from __future__ import print_function
import sys
print('I am python %r' % (sys.version_info,))

K:\shebang>py shebang_env_py3_10.py 
I am python sys.version_info(major=3, minor=10, micro=11, releaselevel='final', 
serial=0)

K:\shebang>shebang_env_py3_10.py
I am python sys.version_info(major=3, minor=10, micro=11, releaselevel='final', 
serial=0)

K:\shebang>assoc .py 
.py=Python.File

K:\shebang>ftype Python.File 
Python.File="C:\WINDOWS\py.exe" "%L" %*


Windows 11 output


: 11:52:10.36 K:\shebang
: \\BARNSTONE\barry> py -0 
 -V:3.12 *Python 3.12 (64-bit)
 -V:3.12-32   Python 3.12 (32-bit)
 -V:3.11  Python 3.11 (64-bit)
 -V:3.11-32   Python 3.11 (32-bit)
 -V:3.10  Python 3.10 (64-bit)
 -V:3.9   Python 3.9 (64-bit)
 -V:3.9-32Python 3.9 (32-bit)
 -V:3.8   Python 3.8 (64-bit)
 -V:3.8-32Python 3.8 (32-bit)

: 11:52:10.40 K:\shebang
: \\BARNSTONE\barry> type shebang_py2.py 
#!/usr/bin/python2
from __future__ import print_function
import sys
print('I am python %r' % (sys.version_info,))

: 11:52:10.41 K:\shebang
: \\BARNSTONE\barry> py shebang_py2.py 
No suitable Python runtime found
Pass --list (-0) to see all detected environments on your machine
or set environment variable PYLAUNCHER_ALLOW_INSTALL to use winget
or open the Microsoft Store to the requested version.

: 11:52:10.47 K:\shebang
: \\BARNSTONE\barry> type shebang_py3.py 
#!/usr/bin/python3
from __future__ import print_function
import sys
print('I am python %r' % (sys.version_info,))

: 11:52:10.49 K:\shebang
: \\BARNSTONE\barry> py shebang_py3.py 
I am python sys.version_info(major=3, minor=12, micro=0, releaselevel='final', 
serial=0)

: 11:52:10.52 K:\shebang
: \\BARNSTONE\barry> shebang_py3.py
I am python sys.version_info(major=3, minor=12, micro=0, releaselevel='final', 
serial=0)

: 11:52:10.58 K:\shebang
: \\BARNSTONE\barry> type shebang_env_py3.py 
#!/usr/bin/env python3
from __future__ import print_function
import sys
print('I am python %r' % (sys.version_info,))

: 11:52:10.60 K:\shebang
: \\BARNSTONE\barry> py shebang_env_py3.py 
I am python sys.version_info(major=3, minor=12, micro=0, 

Re: making your own DirEntry.

[Barry Scott via Python-list]

> On 23 Dec 2023, at 09:48, Antoon Pardon via Python-list 
>  wrote:
> 
> Because I have functions with DirEntry parameters.

I would duck-type a class I control to be my DirEnrry in this situation.
Would also help you when debugging as you can tell injected DirEntry from 
"real" DirEntry.

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

[Peter J. Holzer via Python-list]

On 2023-12-22 22:56:45 -0500, Thomas Passin via Python-list wrote:
> In my experience one should always make sure to know what version of Python
> is being used, at least if there is more than one version installed on the
> computer.  Even on Linux using a shebang line can be tricky, because you are
> likely to get the system's version of Python,

You are not "likely" to get the system's version of Python, you get the
version of Python you specify. If you specify "/usr/bin/python3", that's
the system's version of Python. If you specify something else, you get
something else. If you specify "/usr/bin/env python3", you get whatever
the user has in their PATH first.


> and that often is not what you want.  OTOH you don't want to go
> symlinking python3 to some other version of python because then the OS
> system may not work right.  So either you have to specify the Python
> version in the shebang,

This. In my considered opinion installed scripts should work regardless
pf the user's PATH, so they must have the correct interpreter in the
shebang. That specifying the correct shebang pulls in the complete
virtual environment is IMHO a great feature of Python.

I've written a small script "install-python" which basically just copies
a file and adjusts the shebang line.

for the use in Makefiles etc.

> or just specify the right version
> on the command line.  In that case you might as well not have included the
> shebang line at all.

Right. However, that's not how scripts are usually invoked on Unix.
Using /usr/bin/env in the command line is supposed to fix that but of
course it assumes that your interpreter is actually called python3.

hp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: making your own DirEntry.

[Antoon Pardon via Python-list]

Op 22/12/2023 om 21:39 schreef DL Neil via Python-list:

Antoon,


On 12/23/23 01:00, Antoon Pardon via Python-list wrote:
I am writing a program that goes through file hierarchies and I am 
mostly

using scandir for that which produces DirEntry instances.

At times it would be usefull if I could make my own DirEntry for a 
specific

path, however when I try, I get the following diagnostic:


os.DirEntry('snap')

Traceback (most recent call last):
   File "", line 1, in 
TypeError: cannot create 'posix.DirEntry' instances


Does anyone have an idea for why this limitation and how to go around 
it.


At this moment I don't consider pathlib very usefull, it lacks the
follow_symlinks parameter in the is_dir, is_file, ... methods.



Can't recall ever trying this.


The manual (https://docs.python.org/3/library/os.html#os.DirEntry) 
suggests that a DirEntry is one of those Python data-constructs which 
it creates, but we may only use: "cannot create".


Secondly, that a DirEntry object consists of a lot more than the 
directory-name, eg its path.


Thirdly, that os.scandir() deals (only) with concrete directories - 
unlike pathlib's ability to work with both the real thing and abstract 
files/dirs.



Why create a DirEntry? Why not go directly to os.mkdir() or whatever?


Because I have functions with DirEntry parameters.

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