Re: pip/setuptools: Entry points not visible from pkexec-root-environment

[c . buhtz]

Dear Chris,
thanks for asking back and my apologize for being to broad in my way of 
asking (in a foreign language).


Am 19.12.2022 07:40 schrieb Chris Angelico:

Hmm, then I'm not sure what you're *losing* here. The problem, as I
understand it, is that the scripts are getting installed into
/usr/local/bin (which is on PATH at the time they're installed), but
pkexec has a restricted PATH. So if you use which before pkexec'ing,
wouldn't you find the scripts, and then be able to run them without
regard to PATH?


Absolut correct. This works.

The question is if this is a "good" or "elegant" way from the viewpoint 
of different communities/projects (e.g. Python, setuptools, pip, other 
build-systems, distros, something I forgot).


I assume that I'm not the first person with such a use case. So there 
could be solutions out there. Maybe they are standardized solutions out 
there; e.g. a magic feature of setuptools or pip I haven't noticed yet.

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

Re: pip/setuptools: Entry points not visible from pkexec-root-environment

[Chris Angelico]

On Mon, 19 Dec 2022 at 19:38,  wrote:
>
> Dear Chris,
> thanks for asking back and my apologize for being to broad in my way of
> asking (in a foreign language).
>
> Am 19.12.2022 07:40 schrieb Chris Angelico:
> > Hmm, then I'm not sure what you're *losing* here. The problem, as I
> > understand it, is that the scripts are getting installed into
> > /usr/local/bin (which is on PATH at the time they're installed), but
> > pkexec has a restricted PATH. So if you use which before pkexec'ing,
> > wouldn't you find the scripts, and then be able to run them without
> > regard to PATH?
>
> Absolut correct. This works.
>
> The question is if this is a "good" or "elegant" way from the viewpoint
> of different communities/projects (e.g. Python, setuptools, pip, other
> build-systems, distros, something I forgot).
>

Ah! Then, my response is: Yes, it is definitely a good/elegant
solution. I've often created scripts that install into somewhere (eg
systemd, cron, ifupdown) by using 'which' to figure something out, and
then posting the full path into the corresponding file. It's a
convenient way to ensure that the exact same program would be used.

Notably, "which python3" will ensure that you run on the
currently-active Python interpreter; this includes virtual
environments. Very convenient.

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

Re: Single line if statement with a continue

[Peter J. Holzer]

On 2022-12-18 16:49:27 +, Stefan Ram wrote:
> Dennis Lee Bieber  writes:
> >>for idx, thing in enumerate(things):
> >>if idx == 103: 
> >>continue
> >>do_something_with(thing)
> >>
> > For this example, I'd probably reverse the condition.
> > if idx != 103:
> > do_something_with(thing)
> 
>   The first four lines of the quotation above cannot be a
>   complete program as "do_something_with" is not defined
>   therein, so they must be part of a larger program.
>   If, in this larger program, something still follows
>   "do_something_with(thing)" in the loop, the new program
>   after the transformation might not show the same behavior.

“do_something_with(thing)” is obviously not intended to be a single
function call but as a shorthand for “one or more lines of code which do
something with `thing`”. So there is nothing after it because it is
included in it.

That said, the "fail and bail" technique is often more readable than
putting the main incode inside of an if - especially if that code is
long and/or it is guarded by multiple conditions.

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: String to Float, without introducing errors

[Peter J. Holzer]

On 2022-12-19 09:25:17 +1100, Chris Angelico wrote:
> On Mon, 19 Dec 2022 at 07:57, Stefan Ram  wrote:
> > G = Decimal( 6.6743015E-11 )
> > r = Decimal( 6.371E6 )
> > M = Decimal( 5.9722E24 )
> 
> What's the point of using Decimal if you start with nothing more than
> float accuracy?

Right. He also interpreted the notation "6.67430(15)E-11" wrong. The
digits in parentheses represent the uncertainty in the same number of
last digits. So "6.67430(15)E-11" means "something between 6.67430E-11 -
0.00015E-11 and 6.67430E-11 + 0.00015E-11". The r value has only a
precision of 1 km and I'm not sure how accurate the mass is. Let's just
assume (for the sake of the argument) that these are actually accurate in
all given digits.

So G is between 6.67415E-11 and 6.67445E-11, r is between 6.3705E6 and
6.3715E6 and M is between 5.97215E24 and 5.97225E24. If we compute the
time for those deviations you will find that the differences are many
orders of magnitude greater than the effect you wanted to show. And that
still ignores the fact that a vacuum won't be perfect (and collisions
with a few stray atoms might have a similarly tiny effect), that gravity
isn't constant while the weight falls (it's getting closer to the center
of the earth and it's moving past other masses on its way) that Newton's
law is only an approximation, etc. So while the effect is (almost
certainly) real, the numbers are garbage.

I think there's a basic numeracy problem here. This is unfortunately all
too common, even among scientists. The OP apparently rounded their
numbers to 8 significant digits (thereby introducing an error of about
1E-8) and then insisted that the additional error of 1E-15 introduced by
the decimal to float conversion was unacceptable, showing IMHO a
fundamental misunderstanding of the numbers they are working with.

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: Installation hell

[Weatherby,Gerard]

Personally, I don’t use Windows and avoid it like the plague.  Python is easy 
to install on Linux and Mac.

I’d start here: 
https://learn.microsoft.com/en-us/visualstudio/python/overview-of-python-tools-for-visual-studio?view=vs-2022

From: Python-list  on 
behalf of Jim Lewis 
Date: Sunday, December 18, 2022 at 12:56 PM
To: Python-list@python.org 
Subject: Fwd: Installation hell
*** Attention: This is an external email. Use caution responding, opening 
attachments or clicking on links. ***

I'm an occasional user of Python and have a degree in computer science.
Almost every freaking time I use Python, I go through PSH (Python Setup
Hell). Sometimes a wrong version is installed. Sometimes it's a path issue.
Or exe naming confusion: python, python3, phthon311, etc. Or library
compatibility issues - took an hour to find out that pygame does not work
with the current version of python. Then the kludgy PIP app and using a DOS
box under Windows with command prompts which is ridiculous. God only knows
how many novice users of the language (or even intermediate users) were
lost in the setup process. Why not clean the infrastructure up and make a
modern environment or IDE or something better than it is now. Or at least
good error messages that explain exactly what to do. Even getting this
email to the list took numerous steps.

-- A frustrated user
--
https://urldefense.com/v3/__https://mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!gdOs-oC1JZcmvMXy1G4irRpzHCUmF565UXVdCjzSWNGZKpmZ04I_llDX4WUeob3asBCjLe6TIthAAhmwFgbph9u1m9A$
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: String to Float, without introducing errors

[Thomas Passin]

On 12/19/2022 9:10 AM, Peter J. Holzer wrote:

On 2022-12-19 09:25:17 +1100, Chris Angelico wrote:

On Mon, 19 Dec 2022 at 07:57, Stefan Ram  wrote:

G = Decimal( 6.6743015E-11 )
r = Decimal( 6.371E6 )
M = Decimal( 5.9722E24 )


What's the point of using Decimal if you start with nothing more than
float accuracy?


Right. He also interpreted the notation "6.67430(15)E-11" wrong. The
digits in parentheses represent the uncertainty in the same number of
last digits. So "6.67430(15)E-11" means "something between 6.67430E-11 -
0.00015E-11 and 6.67430E-11 + 0.00015E-11". The r value has only a
precision of 1 km and I'm not sure how accurate the mass is. Let's just
assume (for the sake of the argument) that these are actually accurate in
all given digits.

So G is between 6.67415E-11 and 6.67445E-11, r is between 6.3705E6 and
6.3715E6 and M is between 5.97215E24 and 5.97225E24. If we compute the
time for those deviations you will find that the differences are many
orders of magnitude greater than the effect you wanted to show. And that
still ignores the fact that a vacuum won't be perfect (and collisions
with a few stray atoms might have a similarly tiny effect), that gravity
isn't constant while the weight falls (it's getting closer to the center
of the earth and it's moving past other masses on its way) that Newton's
law is only an approximation, etc. So while the effect is (almost
certainly) real, the numbers are garbage.

I think there's a basic numeracy problem here. This is unfortunately all
too common, even among scientists. The OP apparently rounded their
numbers to 8 significant digits (thereby introducing an error of about
1E-8) and then insisted that the additional error of 1E-15 introduced by
the decimal to float conversion was unacceptable, showing IMHO a
fundamental misunderstanding of the numbers they are working with.

 hp


In a way, this example shows both things - the potential value of using 
Decimal numbers, and a degree of innumeracy.  It also misses a chance to 
illustrate how to approach a problem in the simplest and most 
informative way.  Here's what I mean -


We can imagine that the input numbers really are exact, with the 
remaining digits filled in with zeros.  Then it might really be the case 
that - if you wanted to do this computation with precision and could 
assume all those other effects could be neglected - using Decimals would 
be a good thing to do. So OK, let's say that's demonstrated.  No need to 
nit-pick it further.


As a physics problem, though, you would generally be interested in two 
kinds of things:


1. Could there be such an effect, and if so would it be large enough to 
be interesting, whether in theory or in practice?
2. Can there be any feasible way to demonstrate the proposed effect by 
measurements?


The first thing one should do is to find a way to estimate the magnitude 
of the effect so it can be compared with some of those other phenomena 
(non-constant gravity, etc) to see if it's worth doing a full 
computation at all, or even spending any more time on the matter.  There 
is likely to be a way to make such an estimate without needing to resort 
to extremely high precision - you would only need to get within perhaps 
an order of magnitude.  Your real task, then, is to find that way.


For example, you would probably be able to estimate the precision needed 
without actually doing the calculation.  That in itself might turn out 
to enough.




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

Re: String to Float, without introducing errors

[MRAB]

On 2022-12-19 14:10, Peter J. Holzer wrote:

On 2022-12-19 09:25:17 +1100, Chris Angelico wrote:

On Mon, 19 Dec 2022 at 07:57, Stefan Ram  wrote:
> G = Decimal( 6.6743015E-11 )
> r = Decimal( 6.371E6 )
> M = Decimal( 5.9722E24 )

What's the point of using Decimal if you start with nothing more than
float accuracy?


Right. He also interpreted the notation "6.67430(15)E-11" wrong. The
digits in parentheses represent the uncertainty in the same number of
last digits. So "6.67430(15)E-11" means "something between 6.67430E-11 -
0.00015E-11 and 6.67430E-11 + 0.00015E-11". The r value has only a
precision of 1 km and I'm not sure how accurate the mass is. Let's just
assume (for the sake of the argument) that these are actually accurate in
all given digits.

So G is between 6.67415E-11 and 6.67445E-11, r is between 6.3705E6 and
6.3715E6 and M is between 5.97215E24 and 5.97225E24. If we compute the
time for those deviations you will find that the differences are many
orders of magnitude greater than the effect you wanted to show. And that
still ignores the fact that a vacuum won't be perfect (and collisions
with a few stray atoms might have a similarly tiny effect), that gravity
isn't constant while the weight falls (it's getting closer to the center
of the earth and it's moving past other masses on its way) that Newton's
law is only an approximation, etc. So while the effect is (almost
certainly) real, the numbers are garbage.

I think there's a basic numeracy problem here. This is unfortunately all
too common, even among scientists. The OP apparently rounded their
numbers to 8 significant digits (thereby introducing an error of about
1E-8) and then insisted that the additional error of 1E-15 introduced by
the decimal to float conversion was unacceptable, showing IMHO a
fundamental misunderstanding of the numbers they are working with.

To be fair, I don't think I've never seen that notation either! I've 
only ever seen the form 6.67430E-11 ± 0.00015E-11, which is much clearer.

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

Re: Installation hell

[Thomas Passin]

On 12/19/2022 9:59 AM, Weatherby,Gerard wrote:

Personally, I don’t use Windows and avoid it like the plague.  Python is easy 
to install on Linux and Mac.


That's not been my experience.  Windows installers for Python have 
worked well for me over many generations of Python releases.  It's Linux 
where I've found difficulties.  For example, if your distro's Python 
install didn't include tkinter (or even pip), how do you get it?  It's 
different for different Linux distros.  I generally have to use internet 
searches to find out.


For another example, when you use pip to install a package, it sometimes 
suggests that you install a newer version of pip itself. Should you do 
that?  On Linux, probably not, because the distro will have modified pip 
so it puts things in distro-specific places. Yet there is no newer 
version of pip available through the distro's package manager.  Will 
anything bad happen if you don't update pip?  Who knows?


I have a Linux VM that has several versions of Python3 on it.  Python3.8 
came installed with the distro, but for some programs I need Python 
3.9+.  If I forget which versions I have, how can I find out?  People 
say to use which, but that doesn't work - it only reports "python3". 
This does work, but it's not all that easy to remember (the grep "site" 
part is just to filter out uninformative result lines):


~$ find 2>/dev/null ~ -name python -type d |grep "site"
/home/tom/.local/lib/python3.9/site-packages/PyQt5/Qt5/qsci/api/python
/home/tom/.local/lib/python3.8/site-packages/pandas/_libs/src/ujson/python
/home/tom/.local/lib/python3.10/site-packages/PyQt5/Qt5/qsci/api/python

Not that this task is much easier to remember on Windows, but it's not 
harder.  One way: the "py" launcher will tell you:


py --list
-V:3.10 *Python 3.10 (64-bit)
-V:3.9   Python 3.9 (64-bit)
-V:3.7   Python 3.7 (64-bit)
-V:2.7

This is not Linux-bashing, but there's no need for Windows-bashing either.


I’d start here: 
https://learn.microsoft.com/en-us/visualstudio/python/overview-of-python-tools-for-visual-studio?view=vs-2022

From: Python-list  on behalf of 
Jim Lewis 
Date: Sunday, December 18, 2022 at 12:56 PM
To: Python-list@python.org 
Subject: Fwd: Installation hell
*** Attention: This is an external email. Use caution responding, opening 
attachments or clicking on links. ***

I'm an occasional user of Python and have a degree in computer science.
Almost every freaking time I use Python, I go through PSH (Python Setup
Hell). Sometimes a wrong version is installed. Sometimes it's a path issue.
Or exe naming confusion: python, python3, phthon311, etc. Or library
compatibility issues - took an hour to find out that pygame does not work
with the current version of python. Then the kludgy PIP app and using a DOS
box under Windows with command prompts which is ridiculous. God only knows
how many novice users of the language (or even intermediate users) were
lost in the setup process. Why not clean the infrastructure up and make a
modern environment or IDE or something better than it is now. Or at least
good error messages that explain exactly what to do. Even getting this
email to the list took numerous steps.

-- A frustrated user
--
https://urldefense.com/v3/__https://mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!gdOs-oC1JZcmvMXy1G4irRpzHCUmF565UXVdCjzSWNGZKpmZ04I_llDX4WUeob3asBCjLe6TIthAAhmwFgbph9u1m9A$


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

Re: String to Float, without introducing errors

[Peter J. Holzer]

On 2022-12-19 15:14:14 +, MRAB wrote:
> On 2022-12-19 14:10, Peter J. Holzer wrote:
> > He also interpreted the notation "6.67430(15)E-11" wrong. The
> > digits in parentheses represent the uncertainty in the same number of
> > last digits. So "6.67430(15)E-11" means "something between 6.67430E-11 -
> > 0.00015E-11 and 6.67430E-11 + 0.00015E-11".
[...]
> To be fair, I don't think I've never seen that notation either!

I've probably seen it first on Wikipedia, quite a few years ago. Since
then I've also encountered in in physical and astronomical papers (I'm
neither a physicist nor an astronomomer but I occasionally read the
original papers if what I read in the "mainstream media"[1] or hear on
youtube seems suspect).

> I've only ever seen the form 6.67430E-11 ± 0.00015E-11, which is much
> clearer.

Yeah, it's definitely not the pinnacle of inuitiveness. I freely admit
that I looked it up before posting just to make sure that I wasn't
confused about its meaning.

Another problem (but it shares that with the ± notation) is that it's
not clear what that number actually represents. Is it one sigma or two?
Or something else? Is the distribution even symmetric?

hp

[1] I'm not quite happy with that term.

-- 
   _  | 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: Installation hell

[Chris Angelico]

On Tue, 20 Dec 2022 at 03:05, Thomas Passin  wrote:
>
> That's not been my experience.  Windows installers for Python have
> worked well for me over many generations of Python releases.  It's Linux
> where I've found difficulties.  For example, if your distro's Python
> install didn't include tkinter (or even pip), how do you get it?  It's
> different for different Linux distros.  I generally have to use internet
> searches to find out.

If you want to use your distro's Python and add more stuff to it
globally, then yes, it depends on your distro. This is not really a
surprise.

> For another example, when you use pip to install a package, it sometimes
> suggests that you install a newer version of pip itself. Should you do
> that?  On Linux, probably not, because the distro will have modified pip
> so it puts things in distro-specific places. Yet there is no newer
> version of pip available through the distro's package manager.  Will
> anything bad happen if you don't update pip?  Who knows?

Virtual environments work the same way regardless of distro, including
allowing you to install an upgraded pip. As long as your distro
provides the venv package (on Debian, that's in python3-venv), you can
just:

$ python3 -m venv env
$ source env/bin/activate
$ pip install -U pip
$ pip install -r requirements.txt
$ pip install some-package-name
$ etc etc etc etc etc

This is also a recommended way to do things on Windows, so you don't
even need to do things differently.

> I have a Linux VM that has several versions of Python3 on it.  Python3.8
> came installed with the distro, but for some programs I need Python
> 3.9+.  If I forget which versions I have, how can I find out?  People
> say to use which, but that doesn't work - it only reports "python3".
> This does work, but it's not all that easy to remember (the grep "site"
> part is just to filter out uninformative result lines):

Use what your shell already offers you! If you have multiple Pythons
installed, type "python3" and hit tab twice. You should get a list of
options. The exact shell you're using will affect how they're shown,
but I'm pretty sure most shells (at least, the ones designed to be
interactive - /bin/dash might not) will give you some facility like
this.

rosuav@sikorsky:~$ python3
python3   python3.5-dbg-config  python3.8-config
python3.10python3.5dm   python3.8m
python3.10-config python3.5dm-configpython3.8m-config
python3.11python3.5mpython3.9
python3.11-config python3.5m-config python3.9-config
python3.12python3.6 python3.9d
python3.12-config python3.6-config  python3.9-dbg
python3.4 python3.6mpython3.9-dbg-config
python3.4-config  python3.6m-config python3.9d-config
python3.4mpython3.7 python3-config
python3.4m-config python3.7-config  python3d
python3.5 python3.7mpython3-dbg
python3.5-config  python3.7m-config python3-dbg-config
python3.5-dbg python3.8 python3d-config
rosuav@sikorsky:~$ python3

Yes, this is a bit noisy in that it has the -config and -dbg-config
tools listed as well, but you can easily see all the variants that are
installed.

> ~$ find 2>/dev/null ~ -name python -type d |grep "site"
> /home/tom/.local/lib/python3.9/site-packages/PyQt5/Qt5/qsci/api/python
> /home/tom/.local/lib/python3.8/site-packages/pandas/_libs/src/ujson/python
> /home/tom/.local/lib/python3.10/site-packages/PyQt5/Qt5/qsci/api/python

Ugh, that's a horribly inefficient way to do it. All you need to do is
search $PATH. If tab completion isn't suitable, you could probably use
"whereis python3", though it's probably a bit noisy.

> Not that this task is much easier to remember on Windows, but it's not
> harder.  One way: the "py" launcher will tell you:
>
> py --list
> -V:3.10 *Python 3.10 (64-bit)
> -V:3.9   Python 3.9 (64-bit)
> -V:3.7   Python 3.7 (64-bit)
> -V:2.7
>
> This is not Linux-bashing, but there's no need for Windows-bashing either.

There's no need for Linux-bashing when Linux isn't the problem. :)

And Windows wasn't the OP's problem. Nor was Python. The OP moaned
about a lack of IDEs, when pretty much every IDE and text editor out
there has Python support.

We're not here to bash anything. Well, except maybe the popular Unix
shell. I'll /bin/bash that every day of the week... ahem. Anyhow.
We're here to share tips and help everyone be more productive.

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

Re: Installation hell

[Peter J. Holzer]

On 2022-12-19 10:55:52 -0500, Thomas Passin wrote:
> On 12/19/2022 9:59 AM, Weatherby,Gerard wrote:
> > Personally, I don’t use Windows and avoid it like the plague.
> > Python is easy to install on Linux and Mac.
> 
> That's not been my experience.  Windows installers for Python have worked
> well for me over many generations of Python releases.

I haven't had any problem either despite being only an occasional
Windows user.

It is however, quite noticable that almost everyone who asks a question
about their Python installation on this list is using Windows. I don't
think this is just because there are more Windows users than Linux or
Mac Users.

> It's Linux where I've found difficulties.  For example, if your
> distro's Python install didn't include tkinter (or even pip), how do
> you get it?  It's different for different Linux distros.

Yes, but most Linux users don't use a dozen different distributions. And
if you've used one for a while you generaLLy know their general naming
conventions. So just guessing (with a little help from your shell's
expansion mechanism) the name will take you a long way.

So as a long-time Debian and Ubuntu user I just know that a Python
package foo will be packaged as python3-foo while a Perl package of the
same name would be packaged as libfoo-perl. Not exactly consistent, but
you get used to it. On RedHat (which I've also used for a long time) the
naming conventions are a bit different but also easy to find out.

> For another example, when you use pip to install a package, it sometimes
> suggests that you install a newer version of pip itself. Should you do that?
> On Linux, probably not, because the distro will have modified pip so it puts
> things in distro-specific places. Yet there is no newer version of pip
> available through the distro's package manager.  Will anything bad happen if
> you don't update pip?  Who knows?

If I use pip on Linux I almost always install into a virtual environment
(rule 1: Don't mess with the package manager). So year, I can install a
new version of pip into that virtual environment without affecting
anything else.


> I have a Linux VM that has several versions of Python3 on it.  Python3.8
> came installed with the distro, but for some programs I need Python 3.9+.
> If I forget which versions I have, how can I find out?

I type python and then ctrl-D. The shell will then show me all commands
starting with "python" in my path (your shell may have a different key
combination for that, maybe tab-tab).

> People say to use which, but that doesn't work - it only reports
> "python3".

More specifically it will report *where* the exact command you named is
installed. So "which python3" might report /usr/bin/python3 or
/usr/local/bin/python3 or maybe /opt/python3.9.2/bin/python3 but it will
never report the presence of any executable not named "python3" and even
if you have several it will only give you one of them.

> ~$ find 2>/dev/null ~ -name python -type d |grep "site"
> /home/tom/.local/lib/python3.9/site-packages/PyQt5/Qt5/qsci/api/python
> /home/tom/.local/lib/python3.8/site-packages/pandas/_libs/src/ujson/python
> /home/tom/.local/lib/python3.10/site-packages/PyQt5/Qt5/qsci/api/python
> 
> Not that this task is much easier to remember on Windows, but it's not
> harder.  One way: the "py" launcher will tell you:
> 
> py --list
> -V:3.10 *Python 3.10 (64-bit)
> -V:3.9   Python 3.9 (64-bit)
> -V:3.7   Python 3.7 (64-bit)
> -V:2.7

But that works only for Python. Shell expansion works for any command.
If you use Linux, learn how to use your shell (and maybe learn different
shells - I personally prefer zsh, but I can also use bash, ksh, tcsh and
if necessary even sh).

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: Installation hell

[Thomas Passin]

On 12/19/2022 11:36 AM, Chris Angelico wrote:

On Tue, 20 Dec 2022 at 03:05, Thomas Passin  wrote:


That's not been my experience.  Windows installers for Python have
worked well for me over many generations of Python releases.  It's Linux
where I've found difficulties.  For example, if your distro's Python
install didn't include tkinter (or even pip), how do you get it?  It's
different for different Linux distros.  I generally have to use internet
searches to find out.


If you want to use your distro's Python and add more stuff to it
globally, then yes, it depends on your distro. This is not really a
surprise.


For another example, when you use pip to install a package, it sometimes
suggests that you install a newer version of pip itself. Should you do
that?  On Linux, probably not, because the distro will have modified pip
so it puts things in distro-specific places. Yet there is no newer
version of pip available through the distro's package manager.  Will
anything bad happen if you don't update pip?  Who knows?


Virtual environments work the same way regardless of distro, including
allowing you to install an upgraded pip.


I have always disliked working with venvs and avoid it whenever 
possible.  But I suppose that's just me.



As long as your distro
provides the venv package (on Debian, that's in python3-venv), you can
just:

$ python3 -m venv env
$ source env/bin/activate
$ pip install -U pip
$ pip install -r requirements.txt
$ pip install some-package-name
$ etc etc etc etc etc

This is also a recommended way to do things on Windows, so you don't
even need to do things differently.


I have a Linux VM that has several versions of Python3 on it.  Python3.8
came installed with the distro, but for some programs I need Python
3.9+.  If I forget which versions I have, how can I find out?  People
say to use which, but that doesn't work - it only reports "python3".
This does work, but it's not all that easy to remember (the grep "site"
part is just to filter out uninformative result lines):


Use what your shell already offers you! If you have multiple Pythons
installed, type "python3" and hit tab twice. You should get a list of
options. The exact shell you're using will affect how they're shown,
but I'm pretty sure most shells (at least, the ones designed to be
interactive - /bin/dash might not) will give you some facility like
this.


Ah, that's nice.  Though it didn't report python3.10 on the VM I 
mentioned earlier.




rosuav@sikorsky:~$ python3
python3   python3.5-dbg-config  python3.8-config
python3.10python3.5dm   python3.8m
python3.10-config python3.5dm-configpython3.8m-config
python3.11python3.5mpython3.9
python3.11-config python3.5m-config python3.9-config
python3.12python3.6 python3.9d
python3.12-config python3.6-config  python3.9-dbg
python3.4 python3.6mpython3.9-dbg-config
python3.4-config  python3.6m-config python3.9d-config
python3.4mpython3.7 python3-config
python3.4m-config python3.7-config  python3d
python3.5 python3.7mpython3-dbg
python3.5-config  python3.7m-config python3-dbg-config
python3.5-dbg python3.8 python3d-config
rosuav@sikorsky:~$ python3

Yes, this is a bit noisy in that it has the -config and -dbg-config
tools listed as well, but you can easily see all the variants that are
installed.


~$ find 2>/dev/null ~ -name python -type d |grep "site"
/home/tom/.local/lib/python3.9/site-packages/PyQt5/Qt5/qsci/api/python
/home/tom/.local/lib/python3.8/site-packages/pandas/_libs/src/ujson/python
/home/tom/.local/lib/python3.10/site-packages/PyQt5/Qt5/qsci/api/python


Ugh, that's a horribly inefficient way to do it. All you need to do is
search $PATH. If tab completion isn't suitable, you could probably use
"whereis python3", though it's probably a bit noisy.


Sure is!


Not that this task is much easier to remember on Windows, but it's not
harder.  One way: the "py" launcher will tell you:

py --list
-V:3.10 *Python 3.10 (64-bit)
-V:3.9   Python 3.9 (64-bit)
-V:3.7   Python 3.7 (64-bit)
-V:2.7

This is not Linux-bashing, but there's no need for Windows-bashing either.


There's no need for Linux-bashing when Linux isn't the problem. :)

And Windows wasn't the OP's problem. Nor was Python. The OP moaned
about a lack of IDEs, when pretty much every IDE and text editor out
there has Python support.


Yes, the OP's rant didn't make much sense to me, especially since it 
didn't line up with my experience at all.



We're not here to bash anything. Well, except maybe the popular Unix
shell. I'll /bin/bash that every day of the week... ahem. Anyhow.
We're here to share tips and help everyone be more productive.

ChrisA


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

Re: Installation hell

[Chris Angelico]

On Tue, 20 Dec 2022 at 03:56, Peter J. Holzer  wrote:
>
> It is however, quite noticable that almost everyone who asks a question
> about their Python installation on this list is using Windows. I don't
> think this is just because there are more Windows users than Linux or
> Mac Users.

Yes. I think there are a few reasons for that. One is that there are
many many lazy people in the world, and those people are likely to (a)
use the OS that came with their computers - usually Windows or Mac OS;
and (b) ask a question on a mailing list rather than spend some extra
minutes figuring things out with some web searches. An unrelated cause
might be a large number of student and/or novice programmers, who
simply don't have the groundwork knowledge to figure these things out;
and, again, they'll be using whatever OS their systems come with. Why
don't we see more Mac questions, then? No idea, and I'm not a Mac
person so I can't judge, but I would guess it's just a matter of
numbers - Windows outnumbers Mac OS (not counting iOS, which people
don't tend to be installing Python on) by a fairly significant factor.

> > I have a Linux VM that has several versions of Python3 on it.  Python3.8
> > came installed with the distro, but for some programs I need Python 3.9+.
> > If I forget which versions I have, how can I find out?
>
> I type python and then ctrl-D. The shell will then show me all commands
> starting with "python" in my path (your shell may have a different key
> combination for that, maybe tab-tab).

Ah, interesting. When I mentioned tab-tab I was aware that there are
others, but I'm not familiar with Ctrl-D. Normally that means "send
the command as it is", so I assume your shell is set up to take an
unfinished command and tab-complete it. Which shell is that?

(Also - what happens if you Ctrl-D in the middle of a line? Does that work?)

> But that works only for Python. Shell expansion works for any command.
> If you use Linux, learn how to use your shell (and maybe learn different
> shells - I personally prefer zsh, but I can also use bash, ksh, tcsh and
> if necessary even sh).

I agree, although I wouldn't recommend trying to get too much out of
sh as an interactive shell. It's best aimed at low-overhead script
running, and configured accordingly. Though it's sometimes good to
have some familiarity with a low-powered shell and the most basic of
input methods, just in case you're ever thrust into a situation where
a hard drive has crashed, /bin/bash is corrupted, you don't have
convenient access to external boot media, and you just want to get the
network interface up so you can do some basic fixes or data
recovery...

(Never been in precisely that situation, but I have had other key
programs unavailable for various reasons, and it's handy to know
alternatives!)

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

Re: Installation hell

[Chris Angelico]

On Tue, 20 Dec 2022 at 04:14, Thomas Passin  wrote:
>
> On 12/19/2022 11:36 AM, Chris Angelico wrote:
> > On Tue, 20 Dec 2022 at 03:05, Thomas Passin  wrote:
> >>
> >> That's not been my experience.  Windows installers for Python have
> >> worked well for me over many generations of Python releases.  It's Linux
> >> where I've found difficulties.  For example, if your distro's Python
> >> install didn't include tkinter (or even pip), how do you get it?  It's
> >> different for different Linux distros.  I generally have to use internet
> >> searches to find out.
> >
> > If you want to use your distro's Python and add more stuff to it
> > globally, then yes, it depends on your distro. This is not really a
> > surprise.
> >
> >> For another example, when you use pip to install a package, it sometimes
> >> suggests that you install a newer version of pip itself. Should you do
> >> that?  On Linux, probably not, because the distro will have modified pip
> >> so it puts things in distro-specific places. Yet there is no newer
> >> version of pip available through the distro's package manager.  Will
> >> anything bad happen if you don't update pip?  Who knows?
> >
> > Virtual environments work the same way regardless of distro, including
> > allowing you to install an upgraded pip.
>
> I have always disliked working with venvs and avoid it whenever
> possible.  But I suppose that's just me.
>

That's fine. You don't HAVE to use venvs - and in fact, I only use
them for a relatively small number of projects (eg those that get
deployed to Heroku - make a venv, match Python version to Heroku's
offering, and install packages into it, for maximum consistency).
There are a few ways to manage things:

1) Always use your package manager. Don't use pip at all.
2) Install pip from your package manager, but then do user
installations (~/.local).
3) Install venv from your package manager, use virtual environments everywhere.
4) Build Python from source, parallel to your system Python.
5) Some combination of the above.

As you saw from my tab-tab demo, I have a LOT of Pythons installed,
many of them alphas and betas. Right now, my 'python3' command is
3.12, but /usr/bin/python3 is the system Python (3.9.2) and has
packages managed by apt/dpkg. So when a system-installed script tries
to run, it finds the Python and packages that were curated by the
Debian folks; but if I, at the command line, type "python3
somescript.py", I get a newer Python with packages managed by pip.
Sometimes I'll install those with "sudo python3 -m pip install X", but
mostly without sudo, and they land in ~/.local. (Installing as root is
useful when I need other users to be able to run the script - it's a
pain to try to install something into the correct low-privilege user.)

You have options. There's nothing wrong with picking and choosing
according to what's convenient for you.

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

Re: Fwd: Installation hell

[j via Python-list]

I agree. Wasted too much time on last few installs.

It got to the point I downloaded python-embedded, unzipped it and set 
the path manually for my work (needed it as part of a compiler).


It ain't good enough. And I like python.

jan

On 18/12/2022 11:50, Jim Lewis wrote:

I'm an occasional user of Python and have a degree in computer science.
Almost every freaking time I use Python, I go through PSH (Python Setup
Hell). Sometimes a wrong version is installed. Sometimes it's a path issue.
Or exe naming confusion: python, python3, phthon311, etc. Or library
compatibility issues - took an hour to find out that pygame does not work
with the current version of python. Then the kludgy PIP app and using a DOS
box under Windows with command prompts which is ridiculous. God only knows
how many novice users of the language (or even intermediate users) were
lost in the setup process. Why not clean the infrastructure up and make a
modern environment or IDE or something better than it is now. Or at least
good error messages that explain exactly what to do. Even getting this
email to the list took numerous steps.

-- A frustrated user

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

Re: Fwd: Installation hell

[Thomas Passin]

On 12/19/2022 12:28 PM, j via Python-list wrote:

I agree. Wasted too much time on last few installs.

It got to the point I downloaded python-embedded, unzipped it and set 
the path manually for my work (needed it as part of a compiler).


I don't set those paths.  If you have several different versions 
installed, who knows which one the path will find first?  Probably not 
the one you want.  Without paths to the script files, I need to set them 
temporarily, navigate to to the right directory first, or create a 
dedicated batch file, but at least I get the right ones that way.


I don't find it to be a problem.


It ain't good enough. And I like python.

jan

On 18/12/2022 11:50, Jim Lewis wrote:

I'm an occasional user of Python and have a degree in computer science.
Almost every freaking time I use Python, I go through PSH (Python Setup
Hell). Sometimes a wrong version is installed. Sometimes it's a path 
issue.

Or exe naming confusion: python, python3, phthon311, etc. Or library
compatibility issues - took an hour to find out that pygame does not work
with the current version of python. Then the kludgy PIP app and using 
a DOS
box under Windows with command prompts which is ridiculous. God only 
knows

how many novice users of the language (or even intermediate users) were
lost in the setup process. Why not clean the infrastructure up and make a
modern environment or IDE or something better than it is now. Or at least
good error messages that explain exactly what to do. Even getting this
email to the list took numerous steps.

-- A frustrated user


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

Re: Keeping a list of records with named fields that can be updated

[Peter Otten]

On 17/12/2022 20:45, Albert-Jan Roskam wrote:

On Dec 15, 2022 10:21, Peter Otten <__pete...@web.de> wrote:

  >>> from collections import namedtuple
  >>> Row = namedtuple("Row", "foo bar baz")
  >>> row = Row(1, 2, 3)
  >>> row._replace(bar=42)
  Row(foo=1, bar=42, baz=3)


Ahh, I always thought these are undocumented methods, but: "In addition to
the methods inherited from tuples, named tuples support three additional
methods and two attributes. To prevent conflicts with field names, the
method and attribute names start with an underscore."

https://docs.python.org/3/library/collections.html#collections.somenamedtuple._make


I've read somewhere that Raymond Hettinger regrets the naming and now
would favour a trailing underscore to avoid name conflicts.
--
https://mail.python.org/mailman/listinfo/python-list

Re: Installation hell

[Peter J. Holzer]

On 2022-12-20 04:15:07 +1100, Chris Angelico wrote:
> On Tue, 20 Dec 2022 at 03:56, Peter J. Holzer  wrote:
> > It is however, quite noticable that almost everyone who asks a question
> > about their Python installation on this list is using Windows. I don't
> > think this is just because there are more Windows users than Linux or
> > Mac Users.
> 
> Yes. I think there are a few reasons for that. One is that there are
> many many lazy people in the world, and those people are likely to (a)
> use the OS that came with their computers - usually Windows or Mac OS;

Yeah. But also on Linux you never have to set up Python. It's just
there, ready for use (a few years ago, when Python2 way still the
default, you might have had to "apt install python3"[1] but that's it).
So the lazy Linux users never run into these problems.

> > > I have a Linux VM that has several versions of Python3 on it.  Python3.8
> > > came installed with the distro, but for some programs I need Python 3.9+.
> > > If I forget which versions I have, how can I find out?
> >
> > I type python and then ctrl-D. The shell will then show me all commands
> > starting with "python" in my path (your shell may have a different key
> > combination for that, maybe tab-tab).
> 
> Ah, interesting. When I mentioned tab-tab I was aware that there are
> others, but I'm not familiar with Ctrl-D. Normally that means "send
> the command as it is",

It means that only in cooked mode. Since an interactive shell has to
switch the terminal into cbreak or even raw mode anyway, it can mean
whatever the the shell wants it to mean.

> so I assume your shell is set up to take an unfinished command and
> tab-complete it. Which shell is that?

zsh (with vi keybindings, although I think ctrl-D works the same with
emacs keybindings).

> (Also - what happens if you Ctrl-D in the middle of a line? Does that work?)

Yes. For example if I type "ls foo", dann move the cursor back after
"ls" and type " --co^D", I get:

% ls --co foo
--color-- control use of color
--context  -- print any security context of each file

If I then type tab, it cycles through the options. If I select --color=
and type ^D again, I get

% ls --color= foo
always  autonever

Etc.

Debian/Ubuntu contains a ton of predefined expansions for zsh. Many of
them are very context specific and invoke other commands to figure out
the actual options (I guess that it actually invokes ls --help to find
the options of help, and for psql it definitely checks which users or
databases a local postgres installation has to provide you with sensible
options at the appropriate position in the command line. There's also
remote filename expansion for scp and rsync, etc.)


> > But that works only for Python. Shell expansion works for any command.
> > If you use Linux, learn how to use your shell (and maybe learn different
> > shells - I personally prefer zsh, but I can also use bash, ksh, tcsh and
> > if necessary even sh).
> 
> I agree, although I wouldn't recommend trying to get too much out of
> sh as an interactive shell.

Yeah. If I happen to login to an account which has /bin/sh as the login
shell I'll invoke a different shell if I have to type more than 3 or 4
commands (and there is an alernative installed on the machine, which
these days is usually the case). But when I started to use Unix, the
Bourne shell was all there was. If you were lucky, there might have been
a csh, too, but that didn't use cursor keys either. At least it had a
history and you could use ! escapes to access it (I still use those in
zsh and bash).

hp

[1] Or use yum or zypper or whatever, or your GUI package manager if
that's your thing.

-- 
   _  | 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: String to Float, without introducing errors

[Greg Ewing]

On 19/12/22 9:24 am, Stefan Ram wrote:

 So what's the time until a mass of one gram
 arrives at the ground versus a mass of ten grams? I think
 one needs "Decimal" to calculate this!


Or you can be smarter about how you calculate it.

Differentiating t with respect to m gives

dt/dm = -0.5 * sqrt(2 * s * r**2 / (G * (M + m)**3))

which, since m is much smaller than M, is approximately

   -0.5 * sqrt(2 * s * r**2 / (G * M**3))

So

>>> G = 6.6743015E-11
>>> r = 6.371E6
>>> M = 5.9722E24
>>> dtdm = -0.5 * sqrt(2*s*(r**2) / (G * M**3))
>>> dtdm * (1/1000 - 10/1000)
3.4004053539917275e-28

which agrees with your Decimal calculation to 3 digits,
and should be as precise as the input numbers (about
4 digits in this case).

This is a good example of why it's important to choose
an appropriate numerical algorithm!

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

Re: String to Float, without introducing errors

[Sabrina Almodóvar]

On 17/12/2022 18:55, Stefan Ram wrote:
> Grant Edwards  writes:
>> Yes, fixed point (or decimal) is a better fit for what he's doing. but
>> I suspect that floating point would be a better fit for the problem
>> he's trying to solve.
> 
>   I'd like to predict that within the next ten posts in this
>   thread someone will mention "What Every Computer Scientist
>   Should Know About Floating-Point Arithmetic".

Lol!  Speaking of which, let us guide ourselves by

  https://floating-point-gui.de/basic/

and learn that calculations such as ``0.1 + 0.4 work correctly.''
That's the Internet.  You learn a thing on a Tuesday, and on a Wednesday
you're a teacher.  That's why we need peer review.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: String to Float, without introducing errors

[Michael F. Stemper]

On 19/12/2022 09.14, MRAB wrote:

On 2022-12-19 14:10, Peter J. Holzer wrote:

On 2022-12-19 09:25:17 +1100, Chris Angelico wrote:

On Mon, 19 Dec 2022 at 07:57, Stefan Ram  wrote:
> G = Decimal( 6.6743015E-11 )
> r = Decimal( 6.371E6 )
> M = Decimal( 5.9722E24 )

What's the point of using Decimal if you start with nothing more than
float accuracy?


Right. He also interpreted the notation "6.67430(15)E-11" wrong. The
digits in parentheses represent the uncertainty in the same number of
last digits. So "6.67430(15)E-11" means "something between 6.67430E-11 -
0.00015E-11 and 6.67430E-11 + 0.00015E-11". The r value has only a
precision of 1 km and I'm not sure how accurate the mass is. Let's just
assume (for the sake of the argument) that these are actually accurate in
all given digits.


ntal misunderstanding of the numbers they are working with.



To be fair, I don't think I've never seen that notation either! I've only ever 
seen the form 6.67430E-11 ± 0.00015E-11, which is much clearer.


See, for instance:

In particular, the "concise form".

For more detail, see:


--
Michael F. Stemper
Isaiah 58:6-7
--
https://mail.python.org/mailman/listinfo/python-list

Re: Keeping a list of records with named fields that can be updated

[Peter Otten]

On 18/12/2022 16:44, songbird wrote:

Peter Otten wrote:
...

While I think what you need is a database instead of the collection of
csv files the way to alter namedtuples is to create  a new one:


from collections import namedtuple
Row = namedtuple("Row", "foo bar baz")
row = Row(1, 2, 3)
row._replace(bar=42)

Row(foo=1, bar=42, baz=3)


   namedtuple is easier to use as that will use the csv and
csvreader and create the records without me having to do any
conversion or direct handling myself.  it's all automagically
done.  my initial version works, but i'd like it to be a bit
more elegant and handle descriptions it hasn't seen before
in a more robust manner.



An alternative would be dataclasses where basic usage is just as easy:


from dataclasses import make_dataclass
Row = make_dataclass("Row", "foo bar baz".split())
row = Row(1, 2, 3)
row

Row(foo=1, bar=2, baz=3)

row.bar = 42
row

Row(foo=1, bar=42, baz=3)


   i do like that i can directly reference each field in a
dataclass and not have to specify a _replace for each change.

   is there an easy way to convert from namedtuple to dataclass?
i can see there is a _asdict converter, but don't really like
how that turns out as then i have to do a bunch of:
 rec['fieldname'] = blah

rec.fieldname is much easier to understand.


I recommend that you use a dataclass /instead/ of a namedtuple, not
both. However, for a dataclass with the same fields in the same order as
in your namedtuple the conversion is trivial:

Create compatible namedtuple and dataclass types:

>>> NTRow = namedtuple("NTRow", ["alpha", "beta", "gamma"])
>>> DCRow = make_dataclass("DCRow", NTRow._fields)

Build the namedtuple:

>>> ntrow = NTRow(1, "two", 3.0)
>>> ntrow
NTRow(alpha=1, beta='two', gamma=3.0)

Convert to dataclass:

>>> dcrow = DCRow(*ntrow)
>>> dcrow
DCRow(alpha=1, beta='two', gamma=3.0)

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

Re: Fwd: Installation hell

[DFS]

On 12/18/2022 6:50 AM, Jim Lewis wrote:

I'm an occasional user of Python and have a degree in computer science.
Almost every freaking time I use Python, I go through PSH (Python Setup
Hell). Sometimes a wrong version is installed. Sometimes it's a path issue.
Or exe naming confusion: python, python3, phthon311, etc. Or library
compatibility issues - took an hour to find out that pygame does not work
with the current version of python. Then the kludgy PIP app and using a DOS
box under Windows with command prompts which is ridiculous. God only knows
how many novice users of the language (or even intermediate users) were
lost in the setup process. Why not clean the infrastructure up and make a
modern environment or IDE or something better than it is now. Or at least
good error messages that explain exactly what to do. Even getting this
email to the list took numerous steps.

-- A frustrated user



Issues installing python and sending an email?

Ask for a refund on your compsci degree.
--
https://mail.python.org/mailman/listinfo/python-list

Re: String to Float, without introducing errors

[Ángel GR]

On 2022-12-19 16:14, MRAB wrote:
To be fair, I don't think I've never seen that notation either! I've 
only ever seen the form 6.67430E-11 ± 0.00015E-11, which is much clearer.


We use it regularly in our experimental data: 6.3(4), 15.002(10). Things 
would become complex using exponential forms for errors, specially when 
starting to play with exponents: 6.67430E-11 ± 1.5E-15.

--
Ángel GR

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

Re: Keeping a list of records with named fields that can be updated

[songbird]

Peter Otten wrote:
...
> I recommend that you use a dataclass /instead/ of a namedtuple, not
> both. However, for a dataclass with the same fields in the same order as
> in your namedtuple the conversion is trivial:
>
> Create compatible namedtuple and dataclass types:
>
> >>> NTRow = namedtuple("NTRow", ["alpha", "beta", "gamma"])
> >>> DCRow = make_dataclass("DCRow", NTRow._fields)
>
> Build the namedtuple:
>
> >>> ntrow = NTRow(1, "two", 3.0)
> >>> ntrow
> NTRow(alpha=1, beta='two', gamma=3.0)
>
> Convert to dataclass:
>
> >>> dcrow = DCRow(*ntrow)
> >>> dcrow
> DCRow(alpha=1, beta='two', gamma=3.0)

  thanks, once i get the data in from the file i only have
to reference it, but for the rest of the code i can use
the dataclass instead and that will be easier to read than
dicts.  :)

  your help is appreciated.  :)


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

RE: Fwd: Installation hell

[Jim Schwartz]

This type of response is not called for.  I thought this list was designed
to help people.  That's not what this person was doing.  Everyone has
different experience levels and backgrounds.  Help them learn.  Don't berate
them.

Here's what was said:

Issues installing python and sending an email?

Ask for a refund on your compsci degree.

-Original Message-
From: Python-list  On
Behalf Of DFS
Sent: Monday, December 19, 2022 12:58 PM
To: python-list@python.org
Subject: Re: Fwd: Installation hell

On 12/18/2022 6:50 AM, Jim Lewis wrote:
> I'm an occasional user of Python and have a degree in computer science.
> Almost every freaking time I use Python, I go through PSH (Python 
> Setup Hell). Sometimes a wrong version is installed. Sometimes it's a path
issue.
> Or exe naming confusion: python, python3, phthon311, etc. Or library 
> compatibility issues - took an hour to find out that pygame does not 
> work with the current version of python. Then the kludgy PIP app and 
> using a DOS box under Windows with command prompts which is 
> ridiculous. God only knows how many novice users of the language (or 
> even intermediate users) were lost in the setup process. Why not clean 
> the infrastructure up and make a modern environment or IDE or 
> something better than it is now. Or at least good error messages that 
> explain exactly what to do. Even getting this email to the list took
numerous steps.
> 
> -- A frustrated user


Issues installing python and sending an email?

Ask for a refund on your compsci degree.
--
https://mail.python.org/mailman/listinfo/python-list

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

Re: Fwd: Installation hell

[j via Python-list]

I was unclear. I use the full path to the folder with the unzipped 
python-embedded. I shouldn't have said 'set'.


I have complained on here before about broken installs but got 
indifference. An installer should install stuff correctly (leaving a 
working environment). If it won't then give clear instructions on how to 
install manually then let us do it. A broken installer is like a road 
that just runs out.


Dismissals about 'lazy people' (for example) aren't helpful if you are 
trying to get some actual work done.


jan


On 19/12/2022 17:55, Thomas Passin wrote:

On 12/19/2022 12:28 PM, j via Python-list wrote:

I agree. Wasted too much time on last few installs.

It got to the point I downloaded python-embedded, unzipped it and set 
the path manually for my work (needed it as part of a compiler).


I don't set those paths.  If you have several different versions 
installed, who knows which one the path will find first?  Probably not 
the one you want.  Without paths to the script files, I need to set 
them temporarily, navigate to to the right directory first, or create 
a dedicated batch file, but at least I get the right ones that way.


I don't find it to be a problem.


It ain't good enough. And I like python.

jan

On 18/12/2022 11:50, Jim Lewis wrote:

I'm an occasional user of Python and have a degree in computer science.
Almost every freaking time I use Python, I go through PSH (Python Setup
Hell). Sometimes a wrong version is installed. Sometimes it's a path 
issue.

Or exe naming confusion: python, python3, phthon311, etc. Or library
compatibility issues - took an hour to find out that pygame does not 
work
with the current version of python. Then the kludgy PIP app and 
using a DOS
box under Windows with command prompts which is ridiculous. God only 
knows

how many novice users of the language (or even intermediate users) were
lost in the setup process. Why not clean the infrastructure up and 
make a
modern environment or IDE or something better than it is now. Or at 
least

good error messages that explain exactly what to do. Even getting this
email to the list took numerous steps.

-- A frustrated user



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

Re: Fwd: Installation hell

[Mats Wichmann]

On 12/19/22 13:34, j via Python-list wrote:
I was unclear. I use the full path to the folder with the unzipped 
python-embedded. I shouldn't have said 'set'.


I have complained on here before about broken installs but got 
indifference. An installer should install stuff correctly (leaving a 
working environment). If it won't then give clear instructions on how to 
install manually then let us do it. A broken installer is like a road 
that just runs out.


Dismissals about 'lazy people' (for example) aren't helpful if you are 
trying to get some actual work done.


jan


I don't think there was an intent to be dismissive, just to point out 
that this list, and the tutor list, and other places *do* get questions 
from people who haven't tried very much, and don't tell their readers 
what they've tried, jrather ust go "it's broken, please fix it for me". 
You can call that lazy or not (I personally would not throw out that 
term); it does happen.


The Python installer has a few specific people working on it, most of us 
here aren't in a position to make changes to it - complaining here can 
get sympathy, or not, but probably not action.  It does seem to work out 
for a lot of people, so it's always a bit of a surprise when it doesn't. 
 I'd say you ought to file an issue on it if it's broken for you - not 
to say you haven't tried that already.


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

Re: Installation hell

[Weatherby,Gerard]

I was suggesting a possible resource while making it clear I am not Windows 
savvy. My avoidance of Windows has nothing to do with Python, so there is no 
need to discuss it here.

If I don’t care which Python I’m using, I’ll type python3. If I want3.9,  
python3.9. python3 -V tells me the default on that system. (It varies across 
our servers).

If a Python package isn’t available in the mainline Ubuntu repository 
(python3-whatever), I’m creating a virtual environment. It just saves trouble 
in the long run. I have this in ~/bin to create an environment. I’m slowly 
moving projects to the pyproject.toml because pip is complaining about the 
setup.py installs.


#!/bin/bash
VERS=3.8 #default version
VENV=venv #default environment name
if [ $# -gt 0 ]; then
VERS=$1
fi
if [ $# -gt 1 ]; then
VENV=$2
fi
PYTHON=python$VERS
echo $PYTHON
$PYTHON -m venv $VENV
./$VENV/bin/pip install -U pip ipython
if [ -e requirements.txt ]; then
./$VENV/bin/pip install -r requirements.txt
fi
if [ -e setup.py ]; then
./$VENV/bin/python setup.py install
fi
if [ -e pyproject.toml ]; then
./$VENV/bin/pip install -e .
fi

From: Python-list  on 
behalf of Thomas Passin 
Date: Monday, December 19, 2022 at 11:05 AM
To: python-list@python.org 
Subject: Re: Installation hell
*** Attention: This is an external email. Use caution responding, opening 
attachments or clicking on links. ***

On 12/19/2022 9:59 AM, Weatherby,Gerard wrote:
> Personally, I don’t use Windows and avoid it like the plague.  Python is easy 
> to install on Linux and Mac.

That's not been my experience.  Windows installers for Python have
worked well for me over many generations of Python releases.  It's Linux
where I've found difficulties.  For example, if your distro's Python
install didn't include tkinter (or even pip), how do you get it?  It's
different for different Linux distros.  I generally have to use internet
searches to find out.

For another example, when you use pip to install a package, it sometimes
suggests that you install a newer version of pip itself. Should you do
that?  On Linux, probably not, because the distro will have modified pip
so it puts things in distro-specific places. Yet there is no newer
version of pip available through the distro's package manager.  Will
anything bad happen if you don't update pip?  Who knows?

I have a Linux VM that has several versions of Python3 on it.  Python3.8
came installed with the distro, but for some programs I need Python
3.9+.  If I forget which versions I have, how can I find out?  People
say to use which, but that doesn't work - it only reports "python3".
This does work, but it's not all that easy to remember (the grep "site"
part is just to filter out uninformative result lines):

~$ find 2>/dev/null ~ -name python -type d |grep "site"
/home/tom/.local/lib/python3.9/site-packages/PyQt5/Qt5/qsci/api/python
/home/tom/.local/lib/python3.8/site-packages/pandas/_libs/src/ujson/python
/home/tom/.local/lib/python3.10/site-packages/PyQt5/Qt5/qsci/api/python

Not that this task is much easier to remember on Windows, but it's not
harder.  One way: the "py" launcher will tell you:

py --list
-V:3.10 *Python 3.10 (64-bit)
-V:3.9   Python 3.9 (64-bit)
-V:3.7   Python 3.7 (64-bit)
-V:2.7

This is not Linux-bashing, but there's no need for Windows-bashing either.

> I’d start here: 
> https://learn.microsoft.com/en-us/visualstudio/python/overview-of-python-tools-for-visual-studio?view=vs-2022
>
> From: Python-list  on 
> behalf of Jim Lewis 
> Date: Sunday, December 18, 2022 at 12:56 PM
> To: Python-list@python.org 
> Subject: Fwd: Installation hell
> *** Attention: This is an external email. Use caution responding, opening 
> attachments or clicking on links. ***
>
> I'm an occasional user of Python and have a degree in computer science.
> Almost every freaking time I use Python, I go through PSH (Python Setup
> Hell). Sometimes a wrong version is installed. Sometimes it's a path issue.
> Or exe naming confusion: python, python3, phthon311, etc. Or library
> compatibility issues - took an hour to find out that pygame does not work
> with the current version of python. Then the kludgy PIP app and using a DOS
> box under Windows with command prompts which is ridiculous. God only knows
> how many novice users of the language (or even intermediate users) were
> lost in the setup process. Why not clean the infrastructure up and make a
> modern environment or IDE or something better than it is now. Or at least
> good error messages that explain exactly what to do. Even getting this
> email to the list took numerous steps.
>
> -- A frustrated user
> --
> https://urldefense.com/v3/__https://mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!gdOs-oC1JZcmvMXy1G4irRpzHCUmF565UXVdCjzSWNGZKpmZ04I_llDX4WUeob3asBCjLe6TIthAAhmwFgbph9u1m9A$

Re: How to enter escape character in a positional string argument from the command line?

[Mark Bourne]

Jach Feng wrote:

I have a script using the argparse module. I want to enter the string 
"step\x0A" as one of its positional arguments. I expect this string has a 
length of 5, but it gives 8. Obviously the escape character didn't function correctly. 
How to do it?


That depends on the command-line shell you're calling your script from.

In bash, you can include a newline in a quoted string:
./your_script 'step
'
(the closing quote is on the next line)

Or if you want to do it on a single line (or use other escape 
sequences), you can use e.g.:

./your_script $'step\x0a'
(dollar sign before a single-quoted string which contains escape sequences)

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

Re: Installation hell

[Eryk Sun]

On 12/18/22, Jim Lewis  wrote:
>
> Sometimes it's a path issue.

For whatever reason, Python installations on Windows lack versioned
executable names (except for the Microsoft Store distribution). Thus
adding multiple installations to PATH doesn't help unless "python.exe"
is manually linked or copied to versioned names, e.g. "python3.11.exe"
-> "python.exe" and "python3.exe" -> "python.exe". In this case, the
first installation in PATH is the default for running "python" and
"python3".

Using the "py.exe" launcher is the more general and preferred
solution. It allows running any registered Python installation. It's
also the installed handler for the ".py" file type, and it supports
Unix-style shebangs.

> Or exe naming confusion: python, python3, phthon311, etc.

I don't understand what's supposedly confusing here. Here are some
commands to help discover what "py" or "python" commands and
installations are available.

* CMD: where py*.exe
* PowerShell: get-command py*.exe
* Python launcher: py --list-paths

> Or library compatibility issues - took an hour to find out that
> pygame does not work with the current version of python.

It should be a trivial task to discover that wheel packages for pygame
aren't currently available for Python 3.11. It is not unreasonable to
expect Python developers to familiarize themselves with pip and PyPI.

If you search a bit deeper, you'll find a site with unofficial Windows
builds of many packages, including pygame for Python 3.11:

https://www.lfd.uci.edu/~gohlke/pythonlibs/#pygame

Otherwise, while building some packages from source can be quite
involved and difficult, I'd expect anyone with a degree in computer
science to be able to build pygame if necessary. They even provide a
simple guide:

https://www.pygame.org/wiki/CompileWindows

> Then the kludgy PIP app and using a DOS box under Windows with
> command prompts which is ridiculous.

How is pip "kludgy" (i.e. sloppy, hasty, shoddy, or inelegant)? How is
using a command-line interface "ridiculous"? Many programmers and
system administrators actually prefer using command-line interfaces
and text user interfaces (TUI) for many if not most development and
administration tasks. It's a matter of opinion.

---

Nerdy operating system discussion...

> using a DOS box under Windows

The term "DOS box" refers to a virtual machine running 16-bit MS-DOS
in virtual 8086 (v86) mode under Windows 3.1 or Windows 9x, with the
MS-DOS keyboard and display drivers hooked to redirect I/O to a
desktop window. There is no "DOS box" in Windows NT systems. Windows
client systems switched to NT starting with Windows XP. Thus the term
"DOS box" is about two decades out of date.

Also, "DOS" is not synonymous with a command-line interface shell
(e.g. the 16-bit MS-DOS shell, "COMMAND.COM"). A "Disk Operating
System" is one that supports disk drives and filesystems, which
includes most operating systems from the late 1960s onward (e.g.
DOS/360 from 1966). There were several DOS systems for personal
computers in the 1980s, such as Apple ProDOS, Atari DOS, Tandy TRSDOS,
Commodore DOS, and Microsoft MS-DOS. A DOS system can use a graphical
shell, such as running Windows 1.0 (1985) on MS-DOS.

The "python.exe" executable is a Windows application that's flagged to
require a console session. If it doesn't inherit a console session,
then the system allocates one automatically. However, any Windows
application can allocate, attach to, and detach from a console session
via AllocConsole(), AttachConsole(), and FreeConsole().

Prior to Windows 7, each console session in the current NT session is
hosted on threads in the subsystem process for Windows, "csrss.exe".
Starting with Windows 7, console sessions are hosted by instances of
"conhost.exe". The console host also implements a builtin terminal
window for command-line interface (CLI) and text user interface (TUI)
applications. (A console session can be allocated without a terminal
window if a console application is spawned with the creation flag
CREATE_NO_WINDOW.)

Prior to Windows 10, the connection between a console session and its
terminal is hardwired in the console host. This makes it difficult to
implement an alternate terminal, though some alternate terminals have
managed to do so in creative ways (e.g. ConEmu). Starting with Windows
10, alternate terminals can use an open source implementation of the
console host, named "openconsole.exe". The most important example is
Microsoft's "Windows Terminal". Starting with Windows 11, an alternate
terminal can also register as the default terminal for console
applications. For example, if Windows Terminal is set as the default
terminal, then running "python.exe" from Explorer opens a new tab in
Terminal.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Fwd: Installation hell

[Thomas Passin]

On 12/19/2022 3:34 PM, j wrote:
I was unclear. I use the full path to the folder with the unzipped 
python-embedded. I shouldn't have said 'set'.


I have complained on here before about broken installs but got 
indifference. An installer should install stuff correctly (leaving a 
working environment). If it won't then give clear instructions on how to 
install manually then let us do it. A broken installer is like a road 
that just runs out.


Yes, I've had a few of those, just not with Python so far.  One problem 
with a list like this is that if other people don't have the problem or 
can't make it happen, then they don't have any suggestions based on 
personal experience.  So they can't be helpful.  In this issue, I'm in 
that category.


In that situation, we (the list-people, I mean) need good information to 
have a chance of being helpful.  But I've observed that many requestors 
for help like this - especially installation issues - don't provide any 
useful particulars.  That makes it seem like they don't understand what 
they are doing, and folks would like them to do their homework and think 
about what it would take for other people to have a chance of helping.


Would you try to cook a meal, and then say "I followed the recipe and it 
didn't work, please help"?  It's impossible.  But I've seen this kind of 
question over and over on this list.


I did once have a Python installation problem.  The installed Python 
executable worked, but later I ran into some permissions problem.  I had 
installed for "everyone", so it installed into Program Files, and 
apparently somewhere along the way I had done something odd to the 
permissions for that directory.  I was never sure what.  I uninstalled, 
and since then I have always installed new versions for just one user 
(me). Never a problem since.


I'm sorry to say that I have never tried an embedded install, and I 
don't know what's different about one.  Maybe I'll try one now, just to 
know.


Dismissals about 'lazy people' (for example) aren't helpful if you are 
trying to get some actual work done.


Yes, that's true. Lack of clear information isn't helpful, either.

Well this is getting too long, and not directly helping with any of your 
problems.  I hope it may be informative for others who want to ask for 
help. To be able to help someone, I have to understand just what they 
were trying to do, what they did, what happened that caused them to 
think their efforts failed, and what error messages the system emitted. 
That may not be enough either, but it's a required starting point. 
Without this kind of information, people who want to help feel frustrated.



jan


On 19/12/2022 17:55, Thomas Passin wrote:

On 12/19/2022 12:28 PM, j via Python-list wrote:

I agree. Wasted too much time on last few installs.

It got to the point I downloaded python-embedded, unzipped it and set 
the path manually for my work (needed it as part of a compiler).


I don't set those paths.  If you have several different versions 
installed, who knows which one the path will find first?  Probably not 
the one you want.  Without paths to the script files, I need to set 
them temporarily, navigate to to the right directory first, or create 
a dedicated batch file, but at least I get the right ones that way.


I don't find it to be a problem.


It ain't good enough. And I like python.

jan

On 18/12/2022 11:50, Jim Lewis wrote:

I'm an occasional user of Python and have a degree in computer science.
Almost every freaking time I use Python, I go through PSH (Python Setup
Hell). Sometimes a wrong version is installed. Sometimes it's a path 
issue.

Or exe naming confusion: python, python3, phthon311, etc. Or library
compatibility issues - took an hour to find out that pygame does not 
work
with the current version of python. Then the kludgy PIP app and 
using a DOS
box under Windows with command prompts which is ridiculous. God only 
knows

how many novice users of the language (or even intermediate users) were
lost in the setup process. Why not clean the infrastructure up and 
make a
modern environment or IDE or something better than it is now. Or at 
least

good error messages that explain exactly what to do. Even getting this
email to the list took numerous steps.

-- A frustrated user




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

Re: Fwd: Installation hell

[Thomas Passin]

On 12/19/2022 4:54 PM, Thomas Passin wrote:

On 12/19/2022 3:34 PM, j wrote:
I was unclear. I use the full path to the folder with the unzipped 
python-embedded. I shouldn't have said 'set'.


I have complained on here before about broken installs but got 
indifference. An installer should install stuff correctly (leaving a 
working environment). If it won't then give clear instructions on how 
to install manually then let us do it. A broken installer is like a 
road that just runs out.


Yes, I've had a few of those, just not with Python so far.  One problem 
with a list like this is that if other people don't have the problem or 
can't make it happen, then they don't have any suggestions based on 
personal experience.  So they can't be helpful.  In this issue, I'm in 
that category.


In that situation, we (the list-people, I mean) need good information to 
have a chance of being helpful.  But I've observed that many requestors 
for help like this - especially installation issues - don't provide any 
useful particulars.  That makes it seem like they don't understand what 
they are doing, and folks would like them to do their homework and think 
about what it would take for other people to have a chance of helping.


Would you try to cook a meal, and then say "I followed the recipe and it 
didn't work, please help"?  It's impossible.  But I've seen this kind of 
question over and over on this list.


I did once have a Python installation problem.  The installed Python 
executable worked, but later I ran into some permissions problem.  I had 
installed for "everyone", so it installed into Program Files, and 
apparently somewhere along the way I had done something odd to the 
permissions for that directory.  I was never sure what.  I uninstalled, 
and since then I have always installed new versions for just one user 
(me). Never a problem since.


I'm sorry to say that I have never tried an embedded install, and I 
don't know what's different about one.  Maybe I'll try one now, just to 
know.


FWIW, I once set up a Python installation so that it could run from a 
USB stick (Windows only).  My launcher was a batch file that contained 
the following:


@echo off
setlocal
: Find effective drive for this file.
set ed=%~d0
path %ed%\python37\Scripts;%ed%\python37;%PATH%
set PYTHONUSERBASE=%ed%\user\python
set HOME=%ed%\user\python
call python %*
endlocal

I suppose anyone trying to use an embedded version of Python would have 
to set up some environmental variables in a similar way.  Note that I 
used the "user" directory on the USB stick as a home directory for the 
installation.



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

Re: Fwd: Installation hell

[Chris Angelico]

On Tue, 20 Dec 2022 at 09:12, Thomas Passin  wrote:
> FWIW, I once set up a Python installation so that it could run from a
> USB stick (Windows only).  My launcher was a batch file that contained
> the following:
>
> @echo off
> setlocal
> : Find effective drive for this file.
> set ed=%~d0
> path %ed%\python37\Scripts;%ed%\python37;%PATH%
> set PYTHONUSERBASE=%ed%\user\python
> set HOME=%ed%\user\python
> call python %*
> endlocal
>

So much easier to do on a Unix-like system, where you don't need to
concern yourself with "effective drive" and can simply use relative
paths. I know we're not here to bash Windows, but... drive letters
really need to just die already.

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

Re: Installation hell

[Mats Wichmann]

On 12/19/22 14:47, Eryk Sun wrote:


If you search a bit deeper, you'll find a site with unofficial Windows
builds of many packages, including pygame for Python 3.11:

https://www.lfd.uci.edu/~gohlke/pythonlibs/#pygame
Semi-OT: that's been a superb resource, but apparently it's no longer 
maintained - internet scuttlebutt suggests the project which let it 
exist has lost funding.  The link above is a mirror, marked "Archived", 
and I can't see there's been any addition since July 1. (sadly... I 
happen to need an lxml build for experimenting with 3.12 alphas, and 
that's an absolute bear to build for WIndows - I've never cracked it)

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

Re: Fwd: Installation hell

[Thomas Passin]

On 12/19/2022 5:16 PM, Chris Angelico wrote:

On Tue, 20 Dec 2022 at 09:12, Thomas Passin  wrote:

FWIW, I once set up a Python installation so that it could run from a
USB stick (Windows only).  My launcher was a batch file that contained
the following:

@echo off
setlocal
: Find effective drive for this file.
set ed=%~d0
path %ed%\python37\Scripts;%ed%\python37;%PATH%
set PYTHONUSERBASE=%ed%\user\python
set HOME=%ed%\user\python
call python %*
endlocal



So much easier to do on a Unix-like system, where you don't need to
concern yourself with "effective drive" and can simply use relative
paths. I know we're not here to bash Windows, but... drive letters
really need to just die already.


Considering that this was for a removable drive, the launcher needed to 
know its own location, which might change from one instance to another. 
If you look at the code above, you won't find an obvious drive letter. 
You would need to do the equivalent on Linux. The Windows drive letter 
is just not relevant here.


(and I thought we weren't going keep on bashing non-preferred operating 
systems).


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

Re: Fwd: Installation hell

[Grant Edwards]

On 2022-12-19, Chris Angelico  wrote:

> So much easier to do on a Unix-like system, where you don't need to
> concern yourself with "effective drive" and can simply use relative
> paths. I know we're not here to bash Windows, but... drive letters
> really need to just die already.

They needed to "die already" 40 years ago. I was a Unix user before
MS-DOS came out, and I was rather stunned by the whole drive letter
thing. It seemed like such a giant step backwards. I figured that once
hard drives became common, drive letters would die. Nope, they're
still failing strong!

--
Grant


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

Re: Fwd: Installation hell

[Chris Angelico]

On Tue, 20 Dec 2022 at 10:01, Thomas Passin  wrote:
>
> On 12/19/2022 5:16 PM, Chris Angelico wrote:
> > On Tue, 20 Dec 2022 at 09:12, Thomas Passin  wrote:
> >> FWIW, I once set up a Python installation so that it could run from a
> >> USB stick (Windows only).  My launcher was a batch file that contained
> >> the following:
> >>
> >> @echo off
> >> setlocal
> >> : Find effective drive for this file.
> >> set ed=%~d0
> >> path %ed%\python37\Scripts;%ed%\python37;%PATH%
> >> set PYTHONUSERBASE=%ed%\user\python
> >> set HOME=%ed%\user\python
> >> call python %*
> >> endlocal
> >>
> >
> > So much easier to do on a Unix-like system, where you don't need to
> > concern yourself with "effective drive" and can simply use relative
> > paths. I know we're not here to bash Windows, but... drive letters
> > really need to just die already.
>
> Considering that this was for a removable drive, the launcher needed to
> know its own location, which might change from one instance to another.
> If you look at the code above, you won't find an obvious drive letter.
> You would need to do the equivalent on Linux. The Windows drive letter
> is just not relevant here.

The only thing that's relevant is the *path*. Everything can be made
relative to a single directory. On Unix-like systems, any relative
path can be made absolute with reference to a single directory - most
commonly the current working directory, of which there is precisely
one. On Windows, there is the current working directory, plus
twenty-six ADDITIONAL reference directories, plus a current drive (I'm
not certain whether "current working directory" is the same as
"current drive + current directory on that drive", so maybe there's
one fewer than this).

If you create a Python virtual environment without symlinks (eg
"python3 -m venv env --copies"), you can run Python scripts using that
environment simply by invoking the corresponding Python interpreter,
regardless of the actual path. Trivially easy, because it's simply
relative paths.

On Tue, 20 Dec 2022 at 10:03, Grant Edwards  wrote:
>
> On 2022-12-19, Chris Angelico  wrote:
>
> > So much easier to do on a Unix-like system, where you don't need to
> > concern yourself with "effective drive" and can simply use relative
> > paths. I know we're not here to bash Windows, but... drive letters
> > really need to just die already.
>
> They needed to "die already" 40 years ago. I was a Unix user before
> MS-DOS came out, and I was rather stunned by the whole drive letter
> thing. It seemed like such a giant step backwards. I figured that once
> hard drives became common, drive letters would die. Nope, they're
> still failing strong!

They feel like part of an old style of concrete identifiers, like
working with direct memory addresses (as opposed to virtual memory
pages), until you realise that even MS-DOS had a special hack that let
a single physical drive behave as both A: and B: with system-provided
prompts "please insert disk for drive A/B" when needed. And with the
SUBST and JOIN commands, you could - again, even in MS-DOS - mount
directories as drives or drives as directories. (I don't remember what
happened if you tried to use both at once to have a directory appear
in a different location - the equivalent of a bind mount. Might have
worked.) People could have destroyed drive letters by just always
turning them into directories, and then comfortably moving to a
Unix-like mount system, but since that didn't happen, generations of
Windows users have grown up with the expectation that drive letters
are a thing.

And that leads to myriad problems. Until Steve Dower got involved with
the Python installers, there were periodic issues resulting from
certain combinations of (a) installing Python somewhere other than the
C: drive, (b) using pip from somewhere other than the C: drive to
install packages, and (c) attempting to use those packages from
somewhere other than C:. I don't remember exactly what the solutions
were (I want to say that "use explicit paths" was part of it, but this
was a while ago and my memory of other people's problems isn't the
greatest), but it was often a mess.

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

OT: ~gohlke [Was: Installation hell]

[Mike Dewhirst]

On 20/12/2022 9:28 am, Mats Wichmann wrote:

On 12/19/22 14:47, Eryk Sun wrote:


If you search a bit deeper, you'll find a site with unofficial Windows
builds of many packages, including pygame for Python 3.11:

https://www.lfd.uci.edu/~gohlke/pythonlibs/#pygame
Semi-OT: that's been a superb resource, but apparently it's no longer 
maintained - internet scuttlebutt suggests the project which let it 
exist has lost funding.  The link above is a mirror, marked 
"Archived", and I can't see there's been any addition since July 1. 
(sadly... I happen to need an lxml build for experimenting with 3.12 
alphas, and that's an absolute bear to build for WIndows - I've never 
cracked it)


That is dreadful news! Windows as a dev platform is dead without it. 
That is serious.


Back on topic - Installation hell

I use Windows for historic reasons related to needing to support 99% of 
my customers/dependents who also use it. I'm the only one who also uses 
Linux - but only non-GUI Linux.


Windows works for me as a dev platform because there are so many 
talented Python people out there who make it work. It would be 
impossible otherwise. I would be forced to to learn two GUIs if I had to 
develop on Linux.


I'm here to tell you that dev and production on different OSs works 
without a hitch! For me.


Whoever wrote the installation docs for Windows did a great job. All the 
bases and options are covered. Absolutely no-one could complain that any 
pertinent detail has been omitted.


Some marketing research is indicated. The OP who started this thread 
could define themself in exquisite detail so that installation 
infrastructure including documentation can be developed to suit that 
market exemplar.


I think there are several separate markets. Eg., for someone like me ... 
locked into Windows (but not Microsoft otherwise) and needing to target 
Linux web servers. That would allow a branching of the installation docs 
to home in, say, on virtual envs and multiple Python installations in 
the root of drive C: (well away from "Program files") and so on.


If the OP says they are an educated computer scientist they could become 
a hero and write up a tightly focused set of docs (extracted from the 
comprehensive canonical docs) which assume their particular "market", 
for want of a better term.


The PSF might recognise the effort and be able to promote such a high 
interest from Windows Python devs into funding for Chris Gohlke.


Cheers

Mike


--
Signed email is an absolute defence against phishing. This email has
been signed with my private key. If you import my public key you can
automatically decrypt my signature and be sure it came from me. Just
ask and I'll send it to you. Your email software can handle signing.



OpenPGP_signature
Description: OpenPGP digital signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to enter escape character in a positional string argument from the command line?

[Jach Feng]

Mark Bourne 在 2022年12月20日 星期二凌晨4:49:13 [UTC+8] 的信中寫道：
> Jach Feng wrote: 
> > I have a script using the argparse module. I want to enter the string 
> > "step\x0A" as one of its positional arguments. I expect this string has a 
> > length of 5, but it gives 8. Obviously the escape character didn't function 
> > correctly. How to do it?
> That depends on the command-line shell you're calling your script from. 
> 
> In bash, you can include a newline in a quoted string: 
> ./your_script 'step 
> ' 
> (the closing quote is on the next line) 
> 
> Or if you want to do it on a single line (or use other escape 
> sequences), you can use e.g.: 
> ./your_script $'step\x0a' 
> (dollar sign before a single-quoted string which contains escape sequences) 
> 
> -- 
> Mark.
That's really good for Linux user! How about Windows?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to enter escape character in a positional string argument from the command line?

[Thomas Passin]

On 12/19/2022 9:24 PM, Jach Feng wrote:

Mark Bourne 在 2022年12月20日 星期二凌晨4:49:13 [UTC+8] 的信中寫道：

Jach Feng wrote:

I have a script using the argparse module. I want to enter the string 
"step\x0A" as one of its positional arguments. I expect this string has a 
length of 5, but it gives 8. Obviously the escape character didn't function correctly. 
How to do it?

That depends on the command-line shell you're calling your script from.

In bash, you can include a newline in a quoted string:
./your_script 'step
'
(the closing quote is on the next line)

Or if you want to do it on a single line (or use other escape
sequences), you can use e.g.:
./your_script $'step\x0a'
(dollar sign before a single-quoted string which contains escape sequences)

--
Mark.

That's really good for Linux user! How about Windows?


One way is to process the argument after it gets into Python rather than 
before. How hard that will be depends on how general you need the 
argument to be.  For your actual example, the argument comes into Python 
as if it were


arg1 = r"step\x0A"  # or "step\\x0a"

You can see if there is an "\\x":

pos = arg1.find('\\x')  # 4

Replace or use a regex to replace it:

arg1_fixed = arg1.replace('\\x0A', '\n')

Naturally, if "\\x0A" is only a special case and other combinations are 
possible, you will need to figure out what you need and do some more 
complicated processing.


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

Re: How to enter escape character in a positional string argument from the command line?

[Eryk Sun]

On 12/19/22, Jach Feng  wrote:
>
> That's really good for Linux user! How about Windows?

In CMD, typing the "^" escape character at the end of a line ignores
the newline and prompts for "more" input. If you press enter again,
you'll get another "more" prompt in which you can write the rest of
the command line. Command-line arguments are separated by spaces, so
you have to start the next line with a space if you want it to be a
new argument. Also, "^" is a literal character when it's in a
double-quoted string, which requires careful use of quotes. For
example:

C:\>py -c "import sys; print(sys.orig_argv[3:])" spam^
More?
More?  eggs^
More?
More? " and spam"
['spam\n', 'eggs\n and spam']

The above is easier in PowerShell, which supports entering multiline
strings without having to escape the newline. The second-level prompt
is ">> ". For example:

> py -c "import sys; print(sys.orig_argv[3:])" spam"
>> " eggs"
>>  and spam"
['spam\n', 'eggs\n and spam']
-- 
https://mail.python.org/mailman/listinfo/python-list