Re: dict.get(key, default) evaluates default even if key exists
Serhiy Storchaka writes:
> 15.12.20 19:07, Mark Polesky via Python-list пише:
>> # Running this script
>>
>> D = {'a':1}
>> def get_default():
>> print('Nobody expects this')
>> return 0
>> print(D.get('a', get_default()))
>>
>> # ...generates this output:
>>
>> Nobody expects this
>> 1
>>
>> ###
>>
>> Since I'm brand new to this community, I thought I'd ask here first... Is
>> this
>> worthy of a bug report? This behavior is definitely unexpected to me, and I
>> accidentally coded an endless loop in a mutual recursion situation because of
>> it. Calling dict.get.__doc__ only gives this short sentence: Return the
>> value
>> for key if key is in the dictionary, else default. Nothing in that docstring
>> suggests that the default value is evaluated even if the key exists, and I
>> can't think of any good reason to do so.
>>
>> Am I missing something?
>
> You are missed that expressions for function arguments are always
> evaluated before passing their values to a function. This is expected
> behavior, and I can't remember any programming language in which it's
> different.
>
> So dict.get() returns the value of argument default, which is computed
> by calling function get_default() before calling dict.get().
Isn't the second argument to D.get() the value to be return if the first
argument is not a valid key? In that case, why does it make any
difference here what the second argument of D.get() is since the key 'a'
does exist?
Thus, I would indeed expect the code above to print '1'. I am obviously
missing something here.
Cheers,
Loris
--
This signature is currently under construction.
--
https://mail.python.org/mailman/listinfo/python-list
Re: dict.get(key, default) evaluates default even if key exists
On Wed, 2020-12-16 at 08:59 +0100, Loris Bennett wrote:
> Isn't the second argument to D.get() the value to be return if the
> first
> argument is not a valid key? In that case, why does it make any
> difference here what the second argument of D.get() is since the key
> 'a'
> does exist?
>
> Thus, I would indeed expect the code above to print '1'. I am
> obviously
> missing something here.
Yes, the second argument is what to return if there is no valid key.
The second argument is evaluated before the call to the get function.
It's return value is being supplied as an argument to the get function.
Let's write a couple of quick functions to demonstrate...
>>> def get(key, default):
... print(f"{key=} {default=}")
...
>>> def generate_a_default_value():
... return 1
...
>>> get("a", generate_a_default_value())
key='a' default=1
>>>
The generate_a_default_value function was called before the call to
get. It was called so it could produce a value that is actually passed
in as an argument to the get function.
Paul
--
https://mail.python.org/mailman/listinfo/python-list
Re: dict.get(key, default) evaluates default even if key exists
Paul Bryan writes:
> On Wed, 2020-12-16 at 08:59 +0100, Loris Bennett wrote:
>
>> Isn't the second argument to D.get() the value to be return if the
>> first
>> argument is not a valid key? In that case, why does it make any
>> difference here what the second argument of D.get() is since the key
>> 'a'
>> does exist?
>>
>> Thus, I would indeed expect the code above to print '1'. I am
>> obviously
>> missing something here.
>
> Yes, the second argument is what to return if there is no valid key.
> The second argument is evaluated before the call to the get function.
> It's return value is being supplied as an argument to the get function.
>
> Let's write a couple of quick functions to demonstrate...
>
def get(key, default):
> ... print(f"{key=} {default=}")
> ...
def generate_a_default_value():
> ... return 1
> ...
get("a", generate_a_default_value())
> key='a' default=1
>
> The generate_a_default_value function was called before the call to
> get. It was called so it could produce a value that is actually passed
> in as an argument to the get function.
OK, I get the point about when the default value is generated and that
potentially being surprising, but in the example originally given, the
key 'a' exists and has a value of '1', so the default value is not
needed.
Thus, I am still unsurprised when dict.get returns the value of an
existing key.
What am I missing?
Cheers,
Loris
--
This signature is currently under construction.
--
https://mail.python.org/mailman/listinfo/python-list
Re: dict.get(key, default) evaluates default even if key exists
On Wed, 2020-12-16 at 10:01 +0100, Loris Bennett wrote: > OK, I get the point about when the default value is generated and > that > potentially being surprising, but in the example originally given, > the > key 'a' exists and has a value of '1', so the default value is not > needed. But the function is still called. The get method just doesn't use (or return) the value it generates because the key exists. Nevertheless, you're passing the return value of the get_default function as an argument. > Thus, I am still unsurprised when dict.get returns the value of an > existing key. As am I. > What am I missing? You'll need to tell me at this point. Paul -- https://mail.python.org/mailman/listinfo/python-list
Re: dict.get(key, default) evaluates default even if key exists
Maybe this will help:
>>> def get(key, default):
... print("entering get")
... print(f"{key=} {default=}")
... print("exiting get")
...
>>> def generate_default():
... print("entering generate_default")
... print("exiting generate_default")
... return 1
...
>>> get("a", generate_default())
entering generate_default
exiting generate_default
entering get
key='a' default=1
exiting get
>>>
--
https://mail.python.org/mailman/listinfo/python-list
Re: dict.get(key, default) evaluates default even if key exists
Paul Bryan writes: > On Wed, 2020-12-16 at 10:01 +0100, Loris Bennett wrote: > >> OK, I get the point about when the default value is generated and >> that >> potentially being surprising, but in the example originally given, >> the >> key 'a' exists and has a value of '1', so the default value is not >> needed. > > But the function is still called. The get method just doesn't use (or > return) the value it generates because the key exists. Nevertheless, > you're passing the return value of the get_default function as an > argument. > >> Thus, I am still unsurprised when dict.get returns the value of an >> existing key. > > As am I. > >> What am I missing? > > You'll need to tell me at this point. I was just slow and confused, but you helped me get there in the end. I now realise that issue is not about the result of the dict.get(), but rather about the fact that the method which generates the default value is called, whether or not it is needed. I shall remember that next time I think it might be a good idea to define a computationally massively expensive value as a rarely needed default :-) Cheers, Loris -- This signature is currently under construction. -- https://mail.python.org/mailman/listinfo/python-list
Re: dict.get(key, default) evaluates default even if key exists
On Wed, Dec 16, 2020 at 8:43 PM Loris Bennett wrote: > > Paul Bryan writes: > > > On Wed, 2020-12-16 at 10:01 +0100, Loris Bennett wrote: > > > >> OK, I get the point about when the default value is generated and > >> that > >> potentially being surprising, but in the example originally given, > >> the > >> key 'a' exists and has a value of '1', so the default value is not > >> needed. > > > > But the function is still called. The get method just doesn't use (or > > return) the value it generates because the key exists. Nevertheless, > > you're passing the return value of the get_default function as an > > argument. > > > >> Thus, I am still unsurprised when dict.get returns the value of an > >> existing key. > > > > As am I. > > > >> What am I missing? > > > > You'll need to tell me at this point. > > I was just slow and confused, but you helped me get there in the end. I > now realise that issue is not about the result of the dict.get(), but > rather about the fact that the method which generates the default value > is called, whether or not it is needed. > > I shall remember that next time I think it might be a good idea to > define a computationally massively expensive value as a rarely needed > default :-) > Yep! That's what defaultdict can do - or if you need more flexibility, subclass dict and add a __missing__ method. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: dict.get(key, default) evaluates default even if key exists
Paul Bryan writes:
> Maybe this will help:
>
def get(key, default):
> ... print("entering get")
> ... print(f"{key=} {default=}")
> ... print("exiting get")
> ...
def generate_default():
> ... print("entering generate_default")
> ... print("exiting generate_default")
> ... return 1
> ...
get("a", generate_default())
> entering generate_default
> exiting generate_default
> entering get
> key='a' default=1
> exiting get
OK, so it even has nothing to do with dict.get(). It is just about the
way function arguments are evaluated. Your example above illustrates
nicely that Python does what I would expect, although from the examples
others have given, I might have to adjust my expectations when using
other languages.
Cheers,
Loris
--
This signature is currently under construction.
--
https://mail.python.org/mailman/listinfo/python-list
Re: dict.get(key, default) evaluates default even if key exists
On 2020-12-15 13:07:25 -0800, Ethan Furman wrote:
> On 12/15/20 9:07 AM, Mark Polesky via Python-list wrote:
>
> > D = {'a':1}
> >
> > def get_default():
> > print('Nobody expects this')
> > return 0
> >
> > print(D.get('a', get_default()))
>
> Python has short-circuiting logical operations, so one way to get the
> behavior you're looking for is:
>
> D.get('a') or get_default()
That will call get_default for any falsey value (0, "", an empty list ...),
not just for missing values.
Which may or may not be what the OP wants.
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: dict.get(key, default) evaluates default even if key exists
On Wed, Dec 16, 2020 at 10:17 PM Peter J. Holzer wrote:
>
> On 2020-12-15 13:07:25 -0800, Ethan Furman wrote:
> > On 12/15/20 9:07 AM, Mark Polesky via Python-list wrote:
> >
> > > D = {'a':1}
> > >
> > > def get_default():
> > > print('Nobody expects this')
> > > return 0
> > >
> > > print(D.get('a', get_default()))
> >
> > Python has short-circuiting logical operations, so one way to get the
> > behavior you're looking for is:
> >
> > D.get('a') or get_default()
>
> That will call get_default for any falsey value (0, "", an empty list ...),
> not just for missing values.
>
> Which may or may not be what the OP wants.
>
D['a'] if 'a' in D else get_default()
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python3 change logs
On Tue, 15 Dec 2020, Terry Reedy wrote: In particular, for latest release (now 3.9) you would want tkinter in https://docs.python.org/3/whatsnew/3.9.html#improved-modules but nothing there. However, https://docs.python.org/3.8/whatsnew/3.8.html#tkinter Thanks, Terry. Stay well, Rich -- https://mail.python.org/mailman/listinfo/python-list
Python concurrent.futures.ProcessPoolExecutor
Warning: I am new to this group
Warning: I am not an expert at Python, I've written a few small programs, and
spend 20 hours of online classes, and maybe a book or two.
Warning: I am new to trying to use concurrent.futures.ProcessPoolExecutor
- Prior to writing this question I updated to Python 3.9 and PyCharm 2020.3.
And confirmed the problem still exists.
- Running on Windows 10 Professional
- I've been trying to run a simple piece of code to exactly match what I have
seen done in various training videos. By I am getting a different and
unexpected set of results. I.e. the instructor got different results than I
did on my computer. My code is very simple:
import concurrent.futures
import time
start = time.perf_counter()
def task(myarg):
print(f'Sleeping one second...{myarg}')
time.sleep(1)
return 'Done sleeping...'
if __name__ == '__main__':
with concurrent.futures.ProcessPoolExecutor() as executor:
future1 = executor.submit(task, 1)
future2 = executor.submit(task, 2)
finish = time.perf_counter()
print(f'Finished in {round(finish-start,2)} seconds')
And the output is:
Finished in 0.0 seconds
Finished in 0.0 seconds
Sleeping one second...1
Sleeping one second...2
Finished in 1.14 seconds
Process finished with exit code 0
---
QUESTIONS and CONCERNS that I have...
It seems that both calls to task not only runs that function, but then keeps
executing the rest of the main line code. I only expected it to run the
function and then immediately quit/disappear. That is, I expect the output to
look like (i.e. not having the three lines of "Finished in x.x seconds",
rather, just one line like that):
Sleeping one second...1
Sleeping one second...2
Finished in 1.14 seconds
Goal: I need the executor tasks to only run that one function, and then
completely go away and stop. Not keep executing more code that doesn't belong
to the task function.
I've tried many iterations of this issue, and placed PRINT statements all over
to try to track what is going on. And I used if/else statements in the main
code, which caused even more problems. I.e. both the IF and the ELSE was
executed each time through the code. Which completely blows my mind.
Any thoughts on this? Thanks for your time and help!
R
--
https://mail.python.org/mailman/listinfo/python-list
Re: dict.get(key, default) evaluates default even if key exists
On 12/16/20 1:44 AM, Chris Angelico wrote:
On Wed, Dec 16, 2020 at 8:43 PM Loris Bennett
wrote:
Paul Bryan writes:
On Wed, 2020-12-16 at 10:01 +0100, Loris Bennett wrote:
OK, I get the point about when the default value is generated and
that
potentially being surprising, but in the example originally given,
the
key 'a' exists and has a value of '1', so the default value is not
needed.
But the function is still called. The get method just doesn't use (or
return) the value it generates because the key exists. Nevertheless,
you're passing the return value of the get_default function as an
argument.
Thus, I am still unsurprised when dict.get returns the value of an
existing key.
As am I.
What am I missing?
You'll need to tell me at this point.
I was just slow and confused, but you helped me get there in the end. I
now realise that issue is not about the result of the dict.get(), but
rather about the fact that the method which generates the default value
is called, whether or not it is needed.
I shall remember that next time I think it might be a good idea to
define a computationally massively expensive value as a rarely needed
default :-)
Yep! That's what defaultdict can do - or if you need more flexibility,
subclass dict and add a __missing__ method.
Or, if the computationally massively expensive call uses potentially
different arguments for each invocation:
some_var = d.get('a') or cme(arg1, arg2, ...)
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
Re: dict.get(key, default) evaluates default even if key exists
On 12/16/20 3:08 AM, Peter J. Holzer wrote:
On 2020-12-15 13:07:25 -0800, Ethan Furman wrote:
On 12/15/20 9:07 AM, Mark Polesky via Python-list wrote:
D = {'a':1}
def get_default():
print('Nobody expects this')
return 0
print(D.get('a', get_default()))
Python has short-circuiting logical operations, so one way to get the behavior
you're looking for is:
D.get('a') or get_default()
That will call get_default for any falsey value (0, "", an empty list ...),
not just for missing values.
Which may or may not be what the OP wants.
Good point, thanks for clarifying.
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python concurrent.futures.ProcessPoolExecutor
> On Dec 16, 2020, at 7:04 AM, Rob Rosengard wrote:
>
> Warning: I am new to this group
> Warning: I am not an expert at Python, I've written a few small programs,
> and spend 20 hours of online classes, and maybe a book or two.
> Warning: I am new to trying to use concurrent.futures.ProcessPoolExecutor
> - Prior to writing this question I updated to Python 3.9 and PyCharm 2020.3.
> And confirmed the problem still exists.
> - Running on Windows 10 Professional
> - I've been trying to run a simple piece of code to exactly match what I have
> seen done in various training videos. By I am getting a different and
> unexpected set of results. I.e. the instructor got different results than I
> did on my computer. My code is very simple:
>
> import concurrent.futures
> import time
>
>
> start = time.perf_counter()
>
>
> def task(myarg):
>print(f'Sleeping one second...{myarg}')
>time.sleep(1)
>return 'Done sleeping...'
>
>
> if __name__ == '__main__':
>with concurrent.futures.ProcessPoolExecutor() as executor:
>future1 = executor.submit(task, 1)
>future2 = executor.submit(task, 2)
> finish = time.perf_counter()
> print(f'Finished in {round(finish-start,2)} seconds')
>
> And the output is:
> Finished in 0.0 seconds
> Finished in 0.0 seconds
> Sleeping one second...1
> Sleeping one second...2
> Finished in 1.14 seconds
>
> Process finished with exit code 0
>
> ---
> QUESTIONS and CONCERNS that I have...
> It seems that both calls to task not only runs that function, but then keeps
> executing the rest of the main line code. I only expected it to run the
> function and then immediately quit/disappear. That is, I expect the output
> to look like (i.e. not having the three lines of "Finished in x.x seconds",
> rather, just one line like that):
> Sleeping one second...1
> Sleeping one second...2
> Finished in 1.14 seconds
>
> Goal: I need the executor tasks to only run that one function, and then
> completely go away and stop. Not keep executing more code that doesn't
> belong to the task function.
>
> I've tried many iterations of this issue, and placed PRINT statements all
> over to try to track what is going on. And I used if/else statements in the
> main code, which caused even more problems. I.e. both the IF and the ELSE
> was executed each time through the code. Which completely blows my mind.
>
> Any thoughts on this? Thanks for your time and help!
Assuming the code above is indented exactly as you run it, you have an
indentation error. That is, the finish and print() are not indented to be part
of the if __name__… call. As such, they run on import. When you launch a new
process, it imports the module, which then runs those lines, since they are not
guarded by the if statement.
Indent those last two lines to be under the if (they don’t need to be indented
to be under the with, just the if), and it should work as intended.
---
Israel Brewster
Software Engineer
Alaska Volcano Observatory
Geophysical Institute - UAF
2156 Koyukuk Drive
Fairbanks AK 99775-7320
Work: 907-474-5172
cell: 907-328-9145
>
> R
> --
> https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python concurrent.futures.ProcessPoolExecutor
On Wed, Dec 16, 2020 at 9:23 AM Israel Brewster
wrote:
> > On Dec 16, 2020, at 7:04 AM, Rob Rosengard
> wrote:
> >
> > Warning: I am new to this group
> > Warning: I am not an expert at Python, I've written a few small
> programs, and spend 20 hours of online classes, and maybe a book or two.
> > Warning: I am new to trying to use
> concurrent.futures.ProcessPoolExecutor
> > - Prior to writing this question I updated to Python 3.9 and PyCharm
> 2020.3. And confirmed the problem still exists.
> > - Running on Windows 10 Professional
> > - I've been trying to run a simple piece of code to exactly match what I
> have seen done in various training videos. By I am getting a different and
> > unexpected set of results. I.e. the instructor got different results
> than I did on my computer. My code is very simple:
> >
> > import concurrent.futures
> > import time
> >
> >
> > start = time.perf_counter()
> >
> >
> > def task(myarg):
> >print(f'Sleeping one second...{myarg}')
> >time.sleep(1)
> >return 'Done sleeping...'
> >
> >
> > if __name__ == '__main__':
> >with concurrent.futures.ProcessPoolExecutor() as executor:
> >future1 = executor.submit(task, 1)
> >future2 = executor.submit(task, 2)
> > finish = time.perf_counter()
> > print(f'Finished in {round(finish-start,2)} seconds')
> >
> > And the output is:
> > Finished in 0.0 seconds
> > Finished in 0.0 seconds
> > Sleeping one second...1
> > Sleeping one second...2
> > Finished in 1.14 seconds
> >
> > Process finished with exit code 0
>
> Assuming the code above is indented exactly as you run it, you have an
> indentation error. That is, the finish and print() are not indented to be
> part of the if __name__… call. As such, they run on import. When you launch
> a new process, it imports the module, which then runs those lines, since
> they are not guarded by the if statement.
>
> Indent those last two lines to be under the if (they don’t need to be
> indented to be under the with, just the if), and it should work as intended.
>
Windows has a problem forking, so the indentation is more persnickety
there. On Linux and I believe on Mac, you don't have to be so careful with
multiprocessing and concurrent.futures.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python concurrent.futures.ProcessPoolExecutor
On 2020-12-16 16:04, Rob Rosengard wrote:
Warning: I am new to this group
Warning: I am not an expert at Python, I've written a few small programs, and
spend 20 hours of online classes, and maybe a book or two.
Warning: I am new to trying to use concurrent.futures.ProcessPoolExecutor
- Prior to writing this question I updated to Python 3.9 and PyCharm 2020.3.
And confirmed the problem still exists.
- Running on Windows 10 Professional
- I've been trying to run a simple piece of code to exactly match what I have
seen done in various training videos. By I am getting a different and
unexpected set of results. I.e. the instructor got different results than I
did on my computer. My code is very simple:
import concurrent.futures
import time
start = time.perf_counter()
def task(myarg):
print(f'Sleeping one second...{myarg}')
time.sleep(1)
return 'Done sleeping...'
if __name__ == '__main__':
with concurrent.futures.ProcessPoolExecutor() as executor:
future1 = executor.submit(task, 1)
future2 = executor.submit(task, 2)
finish = time.perf_counter()
print(f'Finished in {round(finish-start,2)} seconds')
And the output is:
Finished in 0.0 seconds
Finished in 0.0 seconds
Sleeping one second...1
Sleeping one second...2
Finished in 1.14 seconds
Process finished with exit code 0
---
QUESTIONS and CONCERNS that I have...
It seems that both calls to task not only runs that function, but then keeps executing
the rest of the main line code. I only expected it to run the function and then
immediately quit/disappear. That is, I expect the output to look like (i.e. not having
the three lines of "Finished in x.x seconds", rather, just one line like that):
Sleeping one second...1
Sleeping one second...2
Finished in 1.14 seconds
Goal: I need the executor tasks to only run that one function, and then
completely go away and stop. Not keep executing more code that doesn't belong
to the task function.
I've tried many iterations of this issue, and placed PRINT statements all over
to try to track what is going on. And I used if/else statements in the main
code, which caused even more problems. I.e. both the IF and the ELSE was
executed each time through the code. Which completely blows my mind.
Any thoughts on this? Thanks for your time and help!
It imports the module to run the function, so any top-level code _will_
be run.
Here's a modified version:
--8<8<--
import concurrent.futures
import time
print('Main code, __name__ is {!a}'.format(__name__))
start = time.perf_counter()
def task(myarg):
print('In task, __name__ is {!a}'.format(__name__))
print(f'Sleeping one second...{myarg}')
time.sleep(1)
return 'Done sleeping...'
if __name__ == '__main__':
with concurrent.futures.ProcessPoolExecutor() as executor:
future1 = executor.submit(task, 1)
future2 = executor.submit(task, 2)
finish = time.perf_counter()
print(f'Finished in {round(finish-start,2)} seconds')
--8<8<--
It prints:
--8<8<--
Main code, __name__ is '__main__'
Main code, __name__ is '__mp_main__'
Finished in 0.0 seconds
Main code, __name__ is '__mp_main__'
Finished in 0.0 seconds
In task, __name__ is '__mp_main__'
Sleeping one second...1
In task, __name__ is '__mp_main__'
Sleeping one second...2
Finished in 1.8 seconds
--8<8<--
Any top-level code that you don't want it to run when it re-imports the
module should be protected by the __name__ test.
--
https://mail.python.org/mailman/listinfo/python-list
Fwd: bug in download
Begin forwarded message: > From: Erick Willum > Date: 16 December 2020 at 15:53:40 GMT > To: python-list@python.org > Subject: bug in download > > Hallo and good afternoon, > > Having installed python (big thank you) and sublime text, i get the next > message when trying to download numpy or matplotlib in sublime text: > > fails to pass a sanity check due to a bug in the windows runtime. See this > issue for more information: > https://tinyurl.com/y3dm3h86I > > I got the next message from tiny.url, the long url is: > > https://developercommunity.visualstudio.com/content/problem/ > 1207405/fmod-after-an-update-to-windows-2004-is-causing-a.html > > These next lines appear in the sublime window as well: > > File > "C:\Users\Bill\AppData\Local\Programs\Python\Python39\lib\site-packages\numpy\__init__.py", > line 305, in > _win_os_check() > File > "C:\Users\Bill\AppData\Local\Programs\Python\Python39\lib\site-packages\numpy\__init__.py", > line 302, in _win_os_check > raise RuntimeError(msg.format(__file__)) from None > > I would appreciate your help. > Thanks again. > Bill. > > -- https://mail.python.org/mailman/listinfo/python-list
Python 2 to Python 3 .so library incompatibility - need help
Some time ago (in July) I asked some questions here about problems migrating some code from Python 2 to Python 3. The specific problem that finally prevented me from managing to get it to work was a (Linux) .so file that had been built for Python 2 and, as I don't have the source, I can't build for Python 3. I need to have another go at fixing this as otherwise the code that I need to manage my printer will stop working as I update my Ubuntu systems. The specific error I'm getting is as follows:- File "/usr/libexec/okimfputl.new/guicom.py", line 66, in import pyscand ImportError: /usr/libexec/okimfpdrv/pyscand.so: undefined symbol: _Py_ZeroStruct I know this is because the extension module is compiled for Python 2 and _Py_ZeroStruct is only available in Python 2. I don't have the C code for the module. Is there *any* other way around this, like a 'compatibility module' to use Python 2 .so files in Python 3 or anything like it? I have all the Python code and have (up to hitting this problem) converted it to Python 3. -- Chris Green · -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 2 to Python 3 .so library incompatibility - need help
On Thu, Dec 17, 2020 at 6:06 AM Chris Green wrote: > > Some time ago (in July) I asked some questions here > about problems migrating some code from Python 2 to Python 3. > > The specific problem that finally prevented me from managing to get it > to work was a (Linux) .so file that had been built for Python 2 and, > as I don't have the source, I can't build for Python 3. > > I need to have another go at fixing this as otherwise the code that I > need to manage my printer will stop working as I update my Ubuntu > systems. > > The specific error I'm getting is as follows:- > > File "/usr/libexec/okimfputl.new/guicom.py", line 66, in import > pyscand > ImportError: /usr/libexec/okimfpdrv/pyscand.so: undefined symbol: > _Py_ZeroStruct > > I know this is because the extension module is compiled for Python 2 > and _Py_ZeroStruct is only available in Python 2. I don't have the C > code for the module. > > Is there *any* other way around this, like a 'compatibility module' to > use Python 2 .so files in Python 3 or anything like it? I have all > the Python code and have (up to hitting this problem) converted it to > Python 3. > Basically no. The error you're seeing is a nice noisy one, but even if you got past that, there'll be a LOT of incompatibilities. Unfortunately, a quick google search for 'pyscand' showed up places where you've asked this question, suggesting that nobody else uses this library. It looks like you're going to have to take a big step back and figure out what the library is doing for you, and reimplement that somehow. :( Good luck. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: dict.get(key, default) evaluates default even if key exists
On 2020-12-16, Dennis Lee Bieber wrote: > On Tue, 15 Dec 2020 20:08:53 + (UTC), Mark Polesky via Python-list > declaimed the following: > >>behavior, and I can't remember any programming language in which it's >>different. > > https://en.wikipedia.org/wiki/Evaluation_strategy#Call_by_name Most of us only run across call-by-name when using macro processors (cpp, m4, TeX, various assemblers). I vaguely recall some other old language I ran across in a survey course when in college that used it. IIRC it was Algol. Somebody else already mentioned Haskel. -- Grant -- https://mail.python.org/mailman/listinfo/python-list
Re: Fwd: bug in download
On 12/16/2020 12:15 PM, Erick Willum wrote: Begin forwarded message: From: Erick Willum Date: 16 December 2020 at 15:53:40 GMT To: python-list@python.org Subject: bug in download Hallo and good afternoon, Having installed python (big thank you) and sublime text, i get the next message when trying to download numpy or matplotlib in sublime text: fails to pass a sanity check due to a bug in the windows runtime. See this issue for more information: https://tinyurl.com/y3dm3h86I The answer on stackoverflow.com, easily accessed by their local search or Google web search: use 1.9.3 on Windows 2004, 1.9.4 on *nix. 1.9.3 did not work on *nix, and the 1.9.4 hotfix does not work on on some Windows. I have not seen anything either way about the 2009 Windows update -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 2 to Python 3 .so library incompatibility - need help
On 2020-12-16 19:16, Chris Angelico wrote: On Thu, Dec 17, 2020 at 6:06 AM Chris Green wrote: Some time ago (in July) I asked some questions here about problems migrating some code from Python 2 to Python 3. The specific problem that finally prevented me from managing to get it to work was a (Linux) .so file that had been built for Python 2 and, as I don't have the source, I can't build for Python 3. I need to have another go at fixing this as otherwise the code that I need to manage my printer will stop working as I update my Ubuntu systems. The specific error I'm getting is as follows:- File "/usr/libexec/okimfputl.new/guicom.py", line 66, in import pyscand ImportError: /usr/libexec/okimfpdrv/pyscand.so: undefined symbol: _Py_ZeroStruct I know this is because the extension module is compiled for Python 2 and _Py_ZeroStruct is only available in Python 2. I don't have the C code for the module. Is there *any* other way around this, like a 'compatibility module' to use Python 2 .so files in Python 3 or anything like it? I have all the Python code and have (up to hitting this problem) converted it to Python 3. Basically no. The error you're seeing is a nice noisy one, but even if you got past that, there'll be a LOT of incompatibilities. Unfortunately, a quick google search for 'pyscand' showed up places where you've asked this question, suggesting that nobody else uses this library. It looks like you're going to have to take a big step back and figure out what the library is doing for you, and reimplement that somehow. :( Good luck. Alternatively, run something in Python 2.7 that can import it and talk to the main Python 3 code, at least until you have a long-term solution. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 2 to Python 3 .so library incompatibility - need help
On Thu, Dec 17, 2020 at 7:27 AM MRAB wrote: > > On 2020-12-16 19:16, Chris Angelico wrote: > > On Thu, Dec 17, 2020 at 6:06 AM Chris Green wrote: > >> > >> Some time ago (in July) I asked some questions here > >> about problems migrating some code from Python 2 to Python 3. > >> > >> The specific problem that finally prevented me from managing to get it > >> to work was a (Linux) .so file that had been built for Python 2 and, > >> as I don't have the source, I can't build for Python 3. > >> > >> I need to have another go at fixing this as otherwise the code that I > >> need to manage my printer will stop working as I update my Ubuntu > >> systems. > >> > >> The specific error I'm getting is as follows:- > >> > >> File "/usr/libexec/okimfputl.new/guicom.py", line 66, in > >> import pyscand > >> ImportError: /usr/libexec/okimfpdrv/pyscand.so: undefined symbol: > >> _Py_ZeroStruct > >> > >> I know this is because the extension module is compiled for Python 2 > >> and _Py_ZeroStruct is only available in Python 2. I don't have the C > >> code for the module. > >> > >> Is there *any* other way around this, like a 'compatibility module' to > >> use Python 2 .so files in Python 3 or anything like it? I have all > >> the Python code and have (up to hitting this problem) converted it to > >> Python 3. > >> > > > > Basically no. The error you're seeing is a nice noisy one, but even if > > you got past that, there'll be a LOT of incompatibilities. > > Unfortunately, a quick google search for 'pyscand' showed up > > places where you've asked this question, suggesting that nobody else > > uses this library. It looks like you're going to have to take a big > > step back and figure out what the library is doing for you, and > > reimplement that somehow. :( > > > > Good luck. > > > Alternatively, run something in Python 2.7 that can import it and talk > to the main Python 3 code, at least until you have a long-term solution. Yes, that's a possibility. A hack, but a definite hack. But this is one of the places where the universality of stdin/stdout is extremely handy. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 2 to Python 3 .so library incompatibility - need help
On 16Dec2020 18:51, Chris Green wrote: >The specific problem that finally prevented me from managing to get it >to work was a (Linux) .so file that had been built for Python 2 and, >as I don't have the source, I can't build for Python 3. ChrisA I think suggested keeping a Python 2.7 install around for this. >I need to have another go at fixing this as otherwise the code that I >need to manage my printer will stop working as I update my Ubuntu >systems. Have you considered keeping a legacy VM around as well? I have a few VMs sitting here I use for some legacy software. Have you checked an upgraded Ubuntu to failure to run your software using Python 2? Python 2 won't be installed by default, but I'm pretty sure you can add it in. It is just the "system Python" which is moving to Python 3. Also, make note of the specific Python 2 version where your software works - the CPython API does change somewhat sometimes. >The specific error I'm getting is as follows:- >File "/usr/libexec/okimfputl.new/guicom.py", line 66, in import > pyscand >ImportError: /usr/libexec/okimfpdrv/pyscand.so: undefined symbol: > _Py_ZeroStruct Guessing from the library name, have you looked on the OKI.com site for current software? Maybe here? What's your printer model? https://www.oki.com/au/printing/support/drivers-and-utilities/index.html Not that I've found anything helpful... What Ubuntu package supplies that .so file? >Is there *any* other way around this, like a 'compatibility module' to >use Python 2 .so files in Python 3 or anything like it? I have all >the Python code and have (up to hitting this problem) converted it to >Python 3. Almost certainly not. I think ChrisA's Python 2 suggestion is the go here. You may need to manually copy the requisite .so files if the package is about to vanish. Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 2 to Python 3 .so library incompatibility - need help
On Thu, Dec 17, 2020 at 8:26 AM Cameron Simpson wrote: > > On 16Dec2020 18:51, Chris Green wrote: > >The specific problem that finally prevented me from managing to get it > >to work was a (Linux) .so file that had been built for Python 2 and, > >as I don't have the source, I can't build for Python 3. > > ChrisA I think suggested keeping a Python 2.7 install around for this. (MRAB did, but I agree with it.) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 2 to Python 3 .so library incompatibility - need help
Cameron Simpson wrote: > On 16Dec2020 18:51, Chris Green wrote: > >The specific problem that finally prevented me from managing to get it > >to work was a (Linux) .so file that had been built for Python 2 and, > >as I don't have the source, I can't build for Python 3. > > ChrisA I think suggested keeping a Python 2.7 install around for this. > Not possible really as there are other python conflicts that start appearing if one tries to retain the libraries needed. > >I need to have another go at fixing this as otherwise the code that I > >need to manage my printer will stop working as I update my Ubuntu > >systems. > > Have you considered keeping a legacy VM around as well? I have a few VMs > sitting here I use for some legacy software. > That's not a lot of use. The programs that I want to run (by converting to Python 3) are utility programs for my printer, they install with a handy 'app' in my toolbar. Having them in a VM wouldn't really do much good! :-) > Have you checked an upgraded Ubuntu to failure to run your software > using Python 2? Python 2 won't be installed by default, but I'm pretty > sure you can add it in. It is just the "system Python" which is moving > to Python 3. > > Also, make note of the specific Python 2 version where your software > works - the CPython API does change somewhat sometimes. > I still have python 2. The issue is that the programs need modules which come from a PPA to support Python GTK, these conflict with ongoing updates to Python. The PPA works OK in Ubuntu 20.04 but prevents some updates in 20.10. I expect it will get worse as time goes on. > >The specific error I'm getting is as follows:- > >File "/usr/libexec/okimfputl.new/guicom.py", line 66, in import > > pyscand > >ImportError: /usr/libexec/okimfpdrv/pyscand.so: undefined symbol: > > _Py_ZeroStruct > > > Guessing from the library name, have you looked on the OKI.com site for > current software? Maybe here? What's your printer model? > > https://www.oki.com/au/printing/support/drivers-and-utilities/index.html > > Not that I've found anything helpful... > > What Ubuntu package supplies that .so file? > It comes from OKI with the Linux utilities for the printer, it's an MC342N. I have tried asking them for a Python 3 version, maybe I should try again. -- Chris Green · -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 2 to Python 3 .so library incompatibility - need help
On Thu, Dec 17, 2020 at 9:06 AM Chris Green wrote: > > Also, make note of the specific Python 2 version where your software > > works - the CPython API does change somewhat sometimes. > > > I still have python 2. The issue is that the programs need modules > which come from a PPA to support Python GTK, these conflict with > ongoing updates to Python. The PPA works OK in Ubuntu 20.04 but > prevents some updates in 20.10. I expect it will get worse as time > goes on. > Try getting JUST the printer info in Python 2, and then outputting that to stdout in JSON format. Then your Python 3 script can run your Python 2 script, read what it sends on stdout, and do whatever it needs to. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 2 to Python 3 .so library incompatibility - need help
On 16Dec2020 21:59, Chris Green wrote: >Cameron Simpson wrote: >> On 16Dec2020 18:51, Chris Green wrote: >> >The specific problem that finally prevented me from managing to get it >> >to work was a (Linux) .so file that had been built for Python 2 and, >> >as I don't have the source, I can't build for Python 3. >> >> ChrisA I think suggested keeping a Python 2.7 install around for this. >> >Not possible really as there are other python conflicts that start >appearing if one tries to retain the libraries needed. Runtime python issues like you missing symbol error, or package conflict issues? i.e. can you keep the OKI stuff sitting around along with Python 2 install without having trouble with the PPA? >> >I need to have another go at fixing this as otherwise the code that >> >I need to manage my printer will stop working as I update my Ubuntu >> >systems. I'm leaning towards ChrisA's JSON suggestion at this point (absent newer driver software). Keep a small Python 2 programme around which uses the printer driver in whatever _basic_ ways you need, and _invoke that_ from your modern Python 3 code as an external command, passing/receiving the necessary information in JSON form as input.output, or on its command line if that is more convenient. >> Have you considered keeping a legacy VM around as well? I have a few VMs >> sitting here I use for some legacy software. >> >That's not a lot of use. The programs that I want to run (by >converting to Python 3) are utility programs for my printer, they >install with a handy 'app' in my toolbar. Having them in a VM >wouldn't really do much good! :-) Fair enough. It seemed cumbersome to me too, but it is a viable way to keep something legacy around, particularly if that legacy thing requires a legacy OS. >I still have python 2. The issue is that the programs need modules >which come from a PPA to support Python GTK, these conflict with >ongoing updates to Python. The PPA works OK in Ubuntu 20.04 but >prevents some updates in 20.10. I expect it will get worse as time >goes on. [...] >> Guessing from the library name, have you looked on the OKI.com site >> for current software? Maybe here? What's your printer model? >> https://www.oki.com/au/printing/support/drivers-and-utilities/index.html >> >> >It comes from OKI with the Linux utilities for the printer, it's an >MC342N. >From here? https://www.oki.com/uk/printing/support/drivers-and-utilities/colour-multifunction/01331401/?os=ab33&lang=ac2 This driver? https://www.oki.com/uk/printing/support/drivers-and-utilities/?id=46252701FZ01&tab=drivers-and-utilities&productCategory=colour-multifunction&sku=01331401&os=ab33&lang=ac2 I've just installed the .deb above on my Ubuntu 20.04.1 LTS system. Aside from whinging about systemd it installed ok. How do I reproduce your problems? (I've got no printer of course, but...) >I have tried asking them for a Python 3 version, maybe I should try >again. Can't hurt, but may not be necessary if you are prepared to split your Python 3 code form the Python 2 stuff that ships with the .deb. Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
Review, suggestion etc?
I've done my biggest project that allowed me to learn a lot. It's basically simply Database with basic options >> https://bpa.st/FU4A . What sucks here is basically the find_people() I'll have to work on it yet to make it more useful. . If anyone was bored and wished to point me some wrong way or suggest a better one I'd appreciate. -- Thanks -- https://mail.python.org/mailman/listinfo/python-list
Re: Function returns old value
On 2020-12-12, Terry Reedy wrote: > > Don't post links to unknown sites. Reduce it to the minimum needed to > exhibit the questionable behavior and include inline with the question. > >> How this functions should look properly? > > I've solved the problem. BTW bpa.st/+python is well known for code sharing among Python communities it's alternative to pastebin.com. -- https://mail.python.org/mailman/listinfo/python-list
Re: Function returns old value
On 17/12/2020 15:40, Bischoop wrote: On 2020-12-12, Terry Reedy wrote: Don't post links to unknown sites. Reduce it to the minimum needed to exhibit the questionable behavior and include inline with the question. BTW bpa.st/+python is well known for code sharing among Python communities it's alternative to pastebin.com. Remember that posts to the list are archived, and thus may be searched. People experiencing similar problems in-future will be able to 'mine' the archives for help and advice. Using a/any pastebin is great for immediate sharing. Remember that in this case their links expire/the bin 'disappears'. After expiry, any posts 'here' with links to 'there', will be useless. -- Regards =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: Function returns old value
On 2020-12-17, dn wrote: > Remember that posts to the list are archived, and thus may be searched. > People experiencing similar problems in-future will be able to 'mine' > the archives for help and advice. > > Using a/any pastebin is great for immediate sharing. Remember that in > this case their links expire/the bin 'disappears'. > > After expiry, any posts 'here' with links to 'there', will be useless. I do mind that however I thoght it better if paste a whole code to see and pasting from my IDE to vim/slrn was messing syntax, I'll do better next time. -- https://mail.python.org/mailman/listinfo/python-list
Re: Review, suggestion etc?
On 2020-12-17, Bischoop wrote: Accidently removed the paste, https://bpa.st/E3FQ -- https://mail.python.org/mailman/listinfo/python-list
Re: Function returns old value
On 17/12/2020 16:06, Bischoop wrote: On 2020-12-17, dn wrote: Remember that posts to the list are archived, and thus may be searched. People experiencing similar problems in-future will be able to 'mine' the archives for help and advice. Using a/any pastebin is great for immediate sharing. Remember that in this case their links expire/the bin 'disappears'. After expiry, any posts 'here' with links to 'there', will be useless. I do mind that however I thoght it better if paste a whole code to see and pasting from my IDE to vim/slrn was messing syntax, I'll do better next time. Yes, it can be difficult to know how much code to include and how much can be left-out. Don't worry about that - replies can always trim any excess. Also, don't be concerned about such comments. Rather than complaints, please regard them as advice from folk who have been 'here' and/or using Python for some time. -- Regards =dn -- https://mail.python.org/mailman/listinfo/python-list
