Fwd: Installation hell

[Jim Lewis]

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

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

[c.buhtz]

Hello,

when I install a package on a GNU/Linux system via "sudo python3 -m pip
install -e ." that defines entry points in its pyproject.toml the entry
point starter scripts are located in /usr/locale/bin.

That folder is in PATH for "regular" root users and by "sudo su" roots
users.

But I need to start that entry points via "pkexec".
But in the environment started by "pkexec" the PATH does not contain
/usr/local/bin.

So what can I do?

I don't need a hack or workaround but an "elegant" solution.
-- 
https://mail.python.org/mailman/listinfo/python-list

String to Float, without introducing errors

[Paul St George]

So I am working on a physics paper with a colleague. We have a theory about 
Newtons Cradle. We answer the question why when you lift and drop balls 1 and 
2, balls 4 and 5 rise up. I could say more, but ... (if you are interested 
please write to me).

We want to illustrate the paper with animations. The theory includes distortion 
of the balls and this distortion is very very small. So, I am sent data with 
locations and dimensions to 13 decimal places. Something strange is happening 
with the animations: the balls are not moving smoothly. I do not know (yet) 
where the problem lies so it is difficult to provide a clear narrative.

Because there is a problem, I am investigating in all areas. This brings me to 
the question I asked here. I am not expecting six decimal places or three 
decimal places to be as accurate as thirteen decimal places, but I would like 
to be in control of or fully aware of what goes on under the bonnet.

Here is a picture:
https://paulstgeorge.com/newton/cyclography.html
Thanks,
Paul



 
>> On 17 Dec 2022, at 16:54:05 EST 2022, Thomas Passin wrote:
On 12/17/2022 3:45 PM, Paul St George wrote:
> Thanks to all!
> It was the rounding rounding error that I needed to avoid (as Peter J. Holzer 
> suggested). The use of decimal solved it and just in time. I was about to 
> truncate the number, get each of the characters from the string mantissa, and 
> then do something like this:
> 
> 64550.727
> 
> 64550 + (7 * 0.1) + (2 * 0.01) + (7 * 0.001)
> 
> Now I do not need to!

And that approach would not have helped you, because each of those 
calculations would be done as floating point, and you wouldn't have 
gotten any more precision (and maybe less) than simply doing 
float('64550.727').

Here is a small but interesting discussion thread about float vs Decimal:

https://stackoverflow.com/questions/32053647/comparing-python-decimals-created-from-float-and-string

Would you mind telling us why that degree of precision (that is, decimal 
vs float) matters for your problem?


>> On 17 Dec 2022, at 13:11, Alan Gauld > > wrote:
>>
>> On 17/12/2022 11:51, Paul St George wrote:
>>> I have a large/long array of numbers in an external file. The numbers look 
>>> like this:
>>>
>>> -64550.727
>>> -64511.489
>>> -64393.637
>>> -64196.763
>>> -63920.2
>>
>>> When I bring the numbers into my code, they are Strings. To use the
>>> numbers in my code, I want to change the Strings to Float type
>>> because the code will not work with Strings but I do not want
>>> to change the numbers in any other way.
>>
>> That may be impossible. Float type is not exact and the conversion
>> will be the closest binary representation of your decimal number.
>> It will be very close but it may be slightly different when you
>> print it, for example. (You can usually deal with that by using
>> string formatting features.)
>>
>> Another option is to use the decimal numeric type. That has other
>> compromises associated with it but, if retaining absolute decimal
>> accuracy is your primary goal, it might suit you better.
>>
>>
>> -- 
>> Alan G
>> Author of the Learn to Program web site
>> http://www.alan-g.me.uk/
>> http://www.amazon.com/author/alan_gauld
>> Follow my photo-blog on Flickr at:
>> http://www.flickr.com/photos/alangauldphotos
>>
>>
> 









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

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

[Weatherby,Gerard]

"sudo python3 -m pip
install -e ."

You’ve already started down a problematic road. I recommend installing root 
level Python packages through your system package manager. (apt for debian, or 
whatever RedHat is using now).

If a package you need isn’t available from the system level virtual 
environments are your friend.

I’ve never used pkexec. Generally, just use sudo. There’s an -E flag to 
preserve the environment. We generally write bash wrappers that set whatever 
environment we need.


From: Python-list  on 
behalf of c.bu...@posteo.jp 
Date: Sunday, December 18, 2022 at 12:56 PM
To: Python-list@python.org 
Subject: pip/setuptools: Entry points not visible from pkexec-root-environment
*** Attention: This is an external email. Use caution responding, opening 
attachments or clicking on links. ***

Hello,

when I install a package on a GNU/Linux system via "sudo python3 -m pip
install -e ."
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Fwd: Installation hell

[Mats Wichmann]

On 12/18/22 04: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. 


It's usually best to wait a bit after a new Python releases, until the 
myriad packages developed externally which depend on the binary ABI 
catch up. *Some* carefully follow the beta release cycle and are ready 
on or close to day 1, some feel like they have enough other work to do 
and are not. Can understand both viewpoints.  You can check - search for 
something that's important to you on pypi.org and see if binary wheels 
are available.


e.g. https://pypi.org/project/pygame/#files

New Python releases are only once a year, so this shouldn't be too huge 
a burden, Python 3.10 works just fine in the meantime.



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


Why? Python is a command-line tool to process a language, Similar to 
many other languages - Go, for example.  Or a C/C++ compiler.  *Or* you 
can choose to use someone's wrapping of that process inside an 
Integrated Development Environment. There are tons that support Python 
and let you run your code from within the editor environment without 
having to go open a cmd.exe or powershell box. Most of those are 
external, but the comes-with-Python IDLE works well, too.



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

Fun with python string formatting

[Axy via Python-list]

Hi all,

what do you see looking at format string syntax 
https://docs.python.org/3/library/string.html#formatstrings ?


In particular, at something like this:

{h[1].red.jumbo-header:Hello, World!}

Yes, this is syntactically correct statement and if we tweak Formatter 
methods, we can generate such an output:


Hello, World!

Someone might need a booze to catch sight of arguments and css classes 
in the source statement, okay: let it be Aligote markup.


Although I haven't implemented HTML rendering yet (my actual needs were 
reST and Markdown), this does generate plain text and Markdown now.


However, I'm discouraged at the moment. Without nested markup the 
implementation is very small and nice. With more or less complex 
formatting, such as nested lists, there's a need to analyse upper level 
statements and to enforce some rules. Also, there's a pain with 
indentation, but that's mainly because I was too lazy and based my 
implementation on previous work instead of writing a better one from 
scratch.


There are some undefined points such as how to render paragraphs. Use 
strict {p:text} directive or just split literal text by doubly newlines.


Can't decide whether to cut down all the complexity and revert recursion 
level to 2 or proceed with rich markup.


Anyway, below is the rendered specification in plain text. Here's the 
source code 
https://github.com/declassed-art/clabate/blob/main/clabate/extras/aligote.py 
and the specification 
https://github.com/declassed-art/clabate/blob/main/clabate/examples/aligote_spec.py


If this looks funny and you have any crazy ideas what can be added to or 
changed in the specification, let me know.


Axy.


Aligote markup specification


Headings


{h1:heading}


{h2:heading}


{h3:heading}


{h4:heading}


{h5:heading}


{h6:heading}


Styles
--

{b:bold text}

{i:italic text}

{b:bold and {i:italic} text}

{i:italic and {b:bold} text}

{u:underline text}

{s:strike-through text}

{sub:subscript text}

{sup:superscript text}

Links
-

{link[optional text]:URL}

Examples:

{link:http://declassed.art}

{link[Declassed Art]:http://declassed.art}

Rendered as:

http://declassed.art

Declassed Art (http://declassed.art)


Lists
-

Unordered lists
---

{ul:
    {li:item one, can be markup}
    {li:item two
    can be multi-line}
    {li:etc}
}

Rendered as:

* item one, can be {b:markup}
* item two
  can be multi-line
* etc

Ordered lists
-

{ol:
    {li:item one}
    {li:item two}
    {li:etc}
}

Rendered as:

1. item one
2. item two
3. etc

Nested lists


{ul:
    {li:item one}
    {li:item two}
    {ol:
    {li:item one,
    multi-line}
    {li:item two}
    }
    {li:etc}
}

Rendered as:

* item one
* item two
    1. item one,
   multi-line
    2. item two
* etc

Optional arguments
--

XXX Markdown does not support arbitrary numbering, does it?

{ol:
    {li[3]:item 3}
    {li[5]:item 5
    {ol:
    {li:ordinal is rendered as 5.1}
    {li[3]:ordinal is rendered as 5.3}
    {li[5][5]:ordinal is rendered as 5.5}
    {li: ordinal is rendered as 5.6}
    }
    }
}

Rendered as:

3. item 3
5. item 5
   5.1. ordinal is rendered as 5.1
   5.3. ordinal is rendered as 5.3
   5.5. ordinal is rendered as 5.5
   5.6. ordinal is rendered as 5.6

Optional argument for unordered list is the bullet character.
Default is `*`:
{ul:
    {li:item 1}
    {li[+]:item 2}
    {li[-]:item 3}
}

Rendered as:

* item 1
+ item 2
- item 3

Quirks
--

{ol:
    {li:item one}

    Basically, lists may contain any literal text.
    In terms of python formatting this is not an error,
    but that's not good for rendering.

    {li:item two}
}

Rendered as:

1. item one

Basically, lists may contain any literal text.
In terms of python formatting this is not an error,
but that's not good for rendering.

2. item two

Syntax highlighting
---

{python:
    print('Hello, world!')
}

Rendered as:


    print('Hello, world!')
--
https://mail.python.org/mailman/listinfo/python-list

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

[c . buhtz]

Dear Gerard,
thank you for your reply.

Am 18.12.2022 19:45 schrieb Weatherby,Gerard:

"sudo python3 -m pip
install -e ."

You’ve already started down a problematic road. I recommend installing
root level Python packages through your system package manager. (apt
for debian, or whatever RedHat is using now).


I'm totally with you at this point.

It is clear for me that distro maintainers sometimes using different 
mechanics.
But I'm the upstream maintainer and before handing offer a release to 
the distro that thing need to run without a distro. And that is pip. I 
also know a quit old project using "make" for that.


This question is independent from distros.


I’ve never used pkexec. Generally, just use sudo.


They are two very different things. There is a strict reason why I need 
to use pkexec here.


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

Re: Fwd: Installation hell

[Chris Angelico]

On Mon, 19 Dec 2022 at 06:10, Mats Wichmann  wrote:
> Why? Python is a command-line tool to process a language, Similar to
> many other languages - Go, for example.  Or a C/C++ compiler.  *Or* you
> can choose to use someone's wrapping of that process inside an
> Integrated Development Environment. There are tons that support Python
> and let you run your code from within the editor environment without
> having to go open a cmd.exe or powershell box. Most of those are
> external, but the comes-with-Python IDLE works well, too.

I wouldn't bother responding to these sorts of people. They have
already decided that it's impossible to find any sort of decent IDE
for Python (despite pretty much every editor out there having Python
support), are deathly afraid of command lines, and yet feel the need
to join a mailing list to tell us all that. You won't convince them of
anything.

ChrisA
-- 
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 04:56,  wrote:
>
> Hello,
>
> when I install a package on a GNU/Linux system via "sudo python3 -m pip
> install -e ." that defines entry points in its pyproject.toml the entry
> point starter scripts are located in /usr/locale/bin.
>
> That folder is in PATH for "regular" root users and by "sudo su" roots
> users.
>
> But I need to start that entry points via "pkexec".
> But in the environment started by "pkexec" the PATH does not contain
> /usr/local/bin.
>
> So what can I do?
>
> I don't need a hack or workaround but an "elegant" solution.

Does it have to be in path? Can't you say
/usr/local/bin/entrypointname? Not sure what constitutes an elegant
solution here.

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

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

[Thomas Passin]

Pip is fine for most packages, as it looks like you know.  Some distros 
put some packages in unusual places, and those are the ones that either 
are not or should not be installed via pip.  Which ones varies from 
distro to distro. (I just include this  information here for others who 
haven't discovered it yet).


You asked for something that's not a hack, but here's a hack anyway :). 
Worth reading for the caveats -


https://stackoverflow.com/questions/50783033/execute-pkexec-command-on-a-different-path

I think the most natural way is to launch it with a script that adds 
your desired path to the pkexec environment.  What I don't know is if 
that script needs elevated permissions itself, but you probably already 
know about that.


On 12/18/2022 2:23 PM, c.bu...@posteo.jp wrote:

Dear Gerard,
thank you for your reply.

Am 18.12.2022 19:45 schrieb Weatherby,Gerard:

"sudo python3 -m pip
install -e ."

You’ve already started down a problematic road. I recommend installing
root level Python packages through your system package manager. (apt
for debian, or whatever RedHat is using now).


I'm totally with you at this point.

It is clear for me that distro maintainers sometimes using different 
mechanics.
But I'm the upstream maintainer and before handing offer a release to 
the distro that thing need to run without a distro. And that is pip. I 
also know a quit old project using "make" for that.


This question is independent from distros.


I’ve never used pkexec. Generally, just use sudo.


They are two very different things. There is a strict reason why I need 
to use pkexec here.




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

Re: String to Float, without introducing errors

[Thomas Passin]

Thanks for filling us in!  I wouldn't think the animations themselves 
would need such precision, though perhaps the calculations of the forces 
and motions do.  One way to check might be to perturb the initial 
conditions a bit and see if the changes in the motions seem to be 
correspondingly small.  That might help you work out if the problem is 
with the physics solution or the animation.  It would be easy to get 
some numerical instability in the calculations, for example if you are 
inverting matrices.


On 12/18/2022 2:00 PM, Paul St George wrote:

So I am working on a physics paper with a colleague. We have a theory about 
Newtons Cradle. We answer the question why when you lift and drop balls 1 and 
2, balls 4 and 5 rise up. I could say more, but ... (if you are interested 
please write to me).

We want to illustrate the paper with animations. The theory includes distortion 
of the balls and this distortion is very very small. So, I am sent data with 
locations and dimensions to 13 decimal places. Something strange is happening 
with the animations: the balls are not moving smoothly. I do not know (yet) 
where the problem lies so it is difficult to provide a clear narrative.

Because there is a problem, I am investigating in all areas. This brings me to 
the question I asked here. I am not expecting six decimal places or three 
decimal places to be as accurate as thirteen decimal places, but I would like 
to be in control of or fully aware of what goes on under the bonnet.

Here is a picture:
https://paulstgeorge.com/newton/cyclography.html
Thanks,
Paul



  

On 17 Dec 2022, at 16:54:05 EST 2022, Thomas Passin wrote:

On 12/17/2022 3:45 PM, Paul St George wrote:

Thanks to all!
It was the rounding rounding error that I needed to avoid (as Peter J. Holzer 
suggested). The use of decimal solved it and just in time. I was about to 
truncate the number, get each of the characters from the string mantissa, and 
then do something like this:

64550.727

64550 + (7 * 0.1) + (2 * 0.01) + (7 * 0.001)

Now I do not need to!


And that approach would not have helped you, because each of those
calculations would be done as floating point, and you wouldn't have
gotten any more precision (and maybe less) than simply doing
float('64550.727').

Here is a small but interesting discussion thread about float vs Decimal:

https://stackoverflow.com/questions/32053647/comparing-python-decimals-created-from-float-and-string

Would you mind telling us why that degree of precision (that is, decimal
vs float) matters for your problem?



On 17 Dec 2022, at 13:11, Alan Gauld https://mail.python.org/mailman/listinfo/python-list>> wrote:

On 17/12/2022 11:51, Paul St George wrote:

I have a large/long array of numbers in an external file. The numbers look like 
this:

-64550.727
-64511.489
-64393.637
-64196.763
-63920.2



When I bring the numbers into my code, they are Strings. To use the
numbers in my code, I want to change the Strings to Float type
because the code will not work with Strings but I do not want
to change the numbers in any other way.


That may be impossible. Float type is not exact and the conversion
will be the closest binary representation of your decimal number.
It will be very close but it may be slightly different when you
print it, for example. (You can usually deal with that by using
string formatting features.)

Another option is to use the decimal numeric type. That has other
compromises associated with it but, if retaining absolute decimal
accuracy is your primary goal, it might suit you better.


--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos
















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

Re: Single line if statement with a continue

[Dennis Lee Bieber]

On Wed, 14 Dec 2022 10:53:10 -0800 (PST), Aaron P
 declaimed the following:

Late response here, and the concept may have been covered in
skimmed-over posts..

>I occasionally run across something like:
>
>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)

and hence completely drop the "continue" -- after all, if idx is 103, the
if statement falls through, and the end of the loop acts as an implicit
"continue"

OTOH: if the "if/continue" is buried in four or five layers of
conditionals, it could be cleaner than trying to configure the conditionals
to have a chained exit.


-- 
Wulfraed Dennis Lee Bieber AF6VN
wlfr...@ix.netcom.comhttp://wlfraed.microdiversity.freeddns.org/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: String to Float, without introducing errors

[rbowman]

On Sun, 18 Dec 2022 11:14:28 -0500, Dennis Lee Bieber wrote:

> .. And maybe lament the days when a 3-digit result was acceptable in
> math class -- being the typical capability in reading a standard (10"
> scale) slide rule.

Arguably more thought was given to what those three digits meant in the 
real world. For example, is calculating a latitude to 6 decimal places 
meaningful when the data was gathered by a GPS receiver with 5m accuracy? 
-- 
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:
...
> 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.


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

String to Float, without introducing errors

[Paul St George]

So I am working on a physics paper with a colleague. We have a theory about 
Newtons Cradle. We answer the question why when you lift and drop balls 1 and 
2, balls 4 and 5 rise up. I could say more, but ... (if you are interested 
please write to me).

We want to illustrate the paper with animations. The theory includes distortion 
of the balls and this distortion is very very small. So, I am sent data with 
locations and dimensions to 13 decimal places. Something strange is happening 
with the animations: the balls are not moving smoothly. I do not know (yet) 
where the problem lies so it is difficult to provide a clear narrative.

Because there is a problem, I am investigating in all areas. This brings me to 
the question I asked here. I am not expecting six decimal places or three 
decimal places to be as accurate as thirteen decimal places, but I would like 
to be in control of or fully aware of what goes on under the bonnet.







 
>> On 17 Dec 2022, at 16:54:05 EST 2022, Thomas Passin wrote:
On 12/17/2022 3:45 PM, Paul St George wrote:
> Thanks to all!
> It was the rounding rounding error that I needed to avoid (as Peter J. Holzer 
> suggested). The use of decimal solved it and just in time. I was about to 
> truncate the number, get each of the characters from the string mantissa, and 
> then do something like this:
> 
> 64550.727
> 
> 64550 + (7 * 0.1) + (2 * 0.01) + (7 * 0.001)
> 
> Now I do not need to!

And that approach would not have helped you, because each of those 
calculations would be done as floating point, and you wouldn't have 
gotten any more precision (and maybe less) than simply doing 
float('64550.727').

Here is a small but interesting discussion thread about float vs Decimal:

https://stackoverflow.com/questions/32053647/comparing-python-decimals-created-from-float-and-string

Would you mind telling us why that degree of precision (that is, decimal 
vs float) matters for your problem?


>> On 17 Dec 2022, at 13:11, Alan Gauld > > wrote:
>>
>> On 17/12/2022 11:51, Paul St George wrote:
>>> I have a large/long array of numbers in an external file. The numbers look 
>>> like this:
>>>
>>> -64550.727
>>> -64511.489
>>> -64393.637
>>> -64196.763
>>> -63920.2
>>
>>> When I bring the numbers into my code, they are Strings. To use the
>>> numbers in my code, I want to change the Strings to Float type
>>> because the code will not work with Strings but I do not want
>>> to change the numbers in any other way.
>>
>> That may be impossible. Float type is not exact and the conversion
>> will be the closest binary representation of your decimal number.
>> It will be very close but it may be slightly different when you
>> print it, for example. (You can usually deal with that by using
>> string formatting features.)
>>
>> Another option is to use the decimal numeric type. That has other
>> compromises associated with it but, if retaining absolute decimal
>> accuracy is your primary goal, it might suit you better.
>>
>>
>> -- 
>> Alan G
>> Author of the Learn to Program web site
>> http://www.alan-g.me.uk/
>> http://www.amazon.com/author/alan_gauld
>> Follow my photo-blog on Flickr at:
>> http://www.flickr.com/photos/alangauldphotos
>>
>>
> 









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

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

[c . buhtz]

Dear Chris,

thank you for your reply.

Am 18.12.2022 20:27 schrieb Chris Angelico:

Does it have to be in path? Can't you say
/usr/local/bin/entrypointname? Not sure what constitutes an elegant
solution here.


I asked that myself. My current solution do determine the full path of 
the entrypoint via "which entrypoint".

I also think this is to my current knowledge the best solution.
--
https://mail.python.org/mailman/listinfo/python-list

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

[Barry]

> On 18 Dec 2022, at 17:57, c.bu...@posteo.jp wrote:
> 
> Hello,
> 
> when I install a package on a GNU/Linux system via "sudo python3 -m pip
> install -e ." that defines entry points in its pyproject.toml the entry
> point starter scripts are located in /usr/locale/bin.
> 
> That folder is in PATH for "regular" root users and by "sudo su" roots
> users.
> 
> But I need to start that entry points via "pkexec".
> But in the environment started by "pkexec" the PATH does not contain
> /usr/local/bin.
> 
> So what can I do?


Why are asking on this list and discuss.python.org?
Lots of people on this list are also on discuss.python.org.

Barry
> 
> I don't need a hack or workaround but an "elegant" solution.
> -- 
> https://mail.python.org/mailman/listinfo/python-list
> 

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

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

[Mats Wichmann]

On 12/18/22 14:07, c.bu...@posteo.jp wrote:

Dear Chris,

thank you for your reply.

Am 18.12.2022 20:27 schrieb Chris Angelico:

Does it have to be in path? Can't you say
/usr/local/bin/entrypointname? Not sure what constitutes an elegant
solution here.


I asked that myself. My current solution do determine the full path of 
the entrypoint via "which entrypoint".

I also think this is to my current knowledge the best solution.


the which command uses your PATH, so I'm not sure you're buying anything 
new there


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

Re: String to Float, without introducing errors

[dn]

On 18/12/2022 10.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".



Thank you for doing-so.

More specific: https://docs.python.org/3/tutorial/floatingpoint.html


Perhaps in the rush to 'answer', the joke is on 'us' - that we might 
first need to more carefully-understand the OP's use-case, requirements, 
and constraints?



The joke sours when remembering that this 'mystery' generates frequent 
questions 'here' (and on other Python fora) - not as many as 'why don't 
I see a pretty-GUI when I fire-up Python on MS-Windows?' but it is a 
more sophisticated realisation and deserves a detailed response (such as 
the thought-provoking illustration-code appearing today).



Is it a consequence of Python lowering 'the barrier to entry'? Good 
thing? Bad thing?


(we first started noticing this sort of issue in our (non-Python) MOOCs, 
several pre-COVID years ago: when we first started, the trainee was 
typically recent post-grad; whereas today we enrol folk with a much 
wider range of ages and backgrounds. It is likely that more dev.work has 
gone into 'the bottom end', than into new/higher sophistications - even 
given IT's rate-of-change!)


--
--
Regards,
=dn
--
https://mail.python.org/mailman/listinfo/python-list

Re: String to Float, without introducing errors

[Cameron Simpson]

On 18Dec2022 18:35, Paul St George  wrote:

So I am working on a physics paper with a colleague. We have a theory about 
Newtons Cradle. We answer the question why when you lift and drop balls 1 and 
2, balls 4 and 5 rise up. I could say more, but ... (if you are interested 
please write to me).

We want to illustrate the paper with animations. The theory includes distortion 
of the balls and this distortion is very very small. So, I am sent data with 
locations and dimensions to 13 decimal places. Something strange is happening 
with the animations: the balls are not moving smoothly. I do not know (yet) 
where the problem lies so it is difficult to provide a clear narrative.

Because there is a problem, I am investigating in all areas. This brings me to 
the question I asked here. I am not expecting six decimal places or three 
decimal places to be as accurate as thirteen decimal places, but I would like 
to be in control of or fully aware of what goes on under the bonnet.


First the short take: your machine pobably is quite precise, and float 
is far more performant that the other numeric types available. Your 
source data seem to have more round off than the rounding in a float.


Under the bonnet:

A Python float is effectively a base-2 value in scientific notation.  
Internally it has a base-2 mantissa and base-2 exponent. This page:

https://docs.python.org/3/library/stdtypes.html#typesnumeric
says that CPython's float uses C's "double" floating point type
(you are almost certainly using the CPython implementation) and thus 
you're using the machine's floating point implemenetation.


I believe that almost all modern CPUs implement IEEE 754 floating point:
https://en.wikipedia.org/wiki/IEEE_754

Because they're base 2, various values in other bases will not be 
precisely representable as a float. For example, 1/3 (which you will 
know is _also_ not representable precisely as a base-10 value such as 
0.333).


You can get specifics of your Python's floating point from 
`sys.float_Info`, i.e:


from sys import float_info

The look at float_info.epsilon etc. Details:
https://docs.python.org/3/library/sys.html#sys.float_info

Here's my machine:

Python 3.10.6 (main, Aug 11 2022, 13:47:18) [Clang 12.0.0 
(clang-1200.0.32.29)] on darwin
Type "help", "copyright", "credits" or "license" for more 
information.

>>> from sys import float_info
>>> float_info
sys.float_info(max=1.7976931348623157e+308, max_exp=1024, 
max_10_exp=308, min=2.2250738585072014e-308, min_exp=-1021, 
min_10_exp=-307, dig=15, mant_dig=53, epsilon=2.220446049250313e-16, 
radix=2, rounds=1)


Values of note: mant_dig=53 (53 base-2 bits), dig=15 (15 decimal digits 
of precision).


You might want to look at sys.float_repr_style here:
https://docs.python.org/3/library/sys.html#sys.float_repr_style
which affects how Python writes floats out. In particular this text:

 If the string has value 'short' then for a finite float x, repr(x) 
 aims to produce a short string with the property that 
 float(repr(x)) == x. This is the usual behaviour in Python 3.1 and 
 later.


Again, on my machine:

>>> 64550.727
64550.727
>>> 64550.728
64550.728
>>> 64550.72701
64550.72701
>>> 64550.7270101
64550.7270101
>>> 64550.727010101
64550.727010101
>>> 64550.72701010101
64550.72701010101
>>> 64550.7270101010101
64550.72701010101
>>> 64550.727010101010101
64550.72701010101
>>> 64550.72701010101010101
64550.72701010101


On 17 Dec 2022, at 16:54:05 EST 2022, Thomas Passin wrote:

On 12/17/2022 3:45 PM, Paul St George wrote:

Thanks to all!
It was the rounding rounding error that I needed to avoid (as Peter J. Holzer 
suggested). The use of decimal solved it and just in time. I was about to 
truncate the number, get each of the characters from the string mantissa, and 
then do something like this:

64550.727

64550 + (7 * 0.1) + (2 * 0.01) + (7 * 0.001)

Now I do not need to!


Good, because if you do that using floats it will be less precise than 
float(64550.727). (Which I see Alan has already stated.)


Your source file contains strings like "64550.727". They look to already 
be less than 13 digits of precision as written i.e. some round off 
already took place when that file was written. Do you know the precision 
of the source data?


I suspect that rather than chasing a "perfect" representation of your 
source data, which is already rounded off, you:

- see if the source values can be obtained more precisely
- figure out which operations in your simulation contribute to the 
  motion roughness you see


I'm no expert on floating point coding for precision, but I believe that 
trying to work with values "close together" in magnitude is important 
because values of different scales inherently convert one of them to the 
other scale (i.e. similar sized exponent part) with corresponding loss 
of precision in the mantissa part. T

Re: String to Float, without introducing errors

[Chris Angelico]

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?

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

Re: String to Float, without introducing errors

[Greg Ewing]

On 19/12/22 6:35 am, Paul St George wrote:

So I am working on a physics paper with a colleague. We have a theory about 
Newtons Cradle.

We want to illustrate the paper with animations.

Because there is a problem, I am investigating in all areas. ... I would like 
to be in control of or fully aware of what goes on under the bonnet.


When you convert a string to a float, you're already getting the closest
possible value in binary floating point.

For things like physics simulations, you need to design your algorithms
so that they're tolerant of small inaccuracies in the representation of
your numbers. If those are causing you problems, it sounds like there
is some kind of numerical instability in your algorithm that needs to
be addressed.

It's also possible that there is just a bug somewhere in your code, and
the problem really has nothing to do with floating point inaccuracies.

If you can post some code we might be able to help you further.

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

Re: Single line if statement with a continue

[Tony Oliver]

On Saturday, 17 December 2022 at 23:58:11 UTC, avi.e...@gmail.com wrote:
> Is something sort of taboo when using something like a computer language to 
> write a program?

With what else would you write a program?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: String to Float, without introducing errors

[Cameron Simpson]

On 19Dec2022 08:53, Cameron Simpson  wrote:
I'm no expert on floating point coding for precision, but I believe 
that trying to work with values "close together" in magnitude is 
important because values of different scales inherently convert one of 
them to the other scale (i.e. similar sized exponent part) with 
corresponding loss of precision in the mantissa part. That may require 
you to form your calcutations carefully.


This depends on the operation. With addition/subtraction you'd see this 
directly. With multiplication etc it isn't really the case. But there 
are both more and less effective ways to arrange your floating point 
math in terms of preserving what precision you have.


Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

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

[c . buhtz]

Am 18.12.2022 22:37 schrieb Mats Wichmann:

the which command uses your PATH, so I'm not sure you're buying
anything new there


I'm using which before entering pkexec. ;)

I'll show a demonstrator project later.
--
https://mail.python.org/mailman/listinfo/python-list

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

[c . buhtz]

Dear Barry,
thanks for reply and asking back.

Am 18.12.2022 22:33 schrieb Barry:

Why are asking on this list and discuss.python.org?


To be exact I'm asking in the "Packaging" section of 
"discuss.python.org". To my knowledge that section is the official 
channel of "pypa/pip" project pointed to from there own README.md [1].
To be complete. I also asked in in context of "pypa/setuptools" [2] and 
on the debian-python mailing list.


Not all questions are exactly the same but touching the same meta topic.
"pypa/setuptools" themselfs pointed me to the fact that they are not 
responsible for generating the entry-point-scripts but "pypa/pip" is. No 
matter both have "pypa/" in their names they seem technically different. 
This has reasons but is very confusing for "developers from the outside" 
like me. There are also alternative build-tools other then "setuptools". 
That is why I asked on that python-list here, too. The later was in the 
hope to maybe be pointed to alternative solutions away from setuptools 
and/or pip.


My apologize. When I decide for a solution I will point you to a 
demonstrator repository illustrating that solution.


[1] -- 
[2] -- 
--
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 17:30,  wrote:
>
> Am 18.12.2022 22:37 schrieb Mats Wichmann:
> > the which command uses your PATH, so I'm not sure you're buying
> > anything new there
>
> I'm using which before entering pkexec. ;)
>
> I'll show a demonstrator project later.

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?

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