Re: error of opening Python

2023-09-26 Thread MRAB via Python-list

On 2023-09-27 03:30, Chris Roy-Smith via Python-list wrote:

On 26/9/23 22:27, Abdelkhelk ashref salay eabakh via Python-list wrote:

Dear Python team,

This is my not first time using Python, I tried to launch Python and it showed


I'm no expert but

"Python 3.11.3 (tags/v3.11.3:f3909b8, Apr  4 2023, 23:49:59) [MSC v.1934 64 bit 
(AMD64)] on win

surely running a 64 bit version of python in a 23mbit version of windows
will cause significant problems!


It says "win32" even on 64-bit Windows.

If you try to run 64-bit Python on 32-bit Windows, it won't get as far 
as printing that header!



try the correct python or windows

regards,




Type "help", "copyright", "credits" or "license" for more information." I
don't know what this meant and how to fix this. Could you please help me?
Thank you very much.

Kind regards






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


Re: The GIL and PyEval_RestoreThread

2023-09-26 Thread MRAB via Python-list

On 2023-09-26 14:20, Peter Ebden via Python-list wrote:

Hi all,

I've been working on embedding Python and have an interesting case around
locking with PyEval_RestoreThread which wasn't quite doing what I expect,
hoping someone can explain what I should expect here.

I have a little example (I'm running this in parallel from two different
threads; I have some more C code for that but I don't think it's super
interesting):

void run_python(PyThreadState* thread) {
   LOG("Restoring thread %p...", thread);
   PyEval_RestoreThread(thread);
   LOG("Restored thread %p", thread);
   PyRun_SimpleString("import time; print('sleeping'); time.sleep(3.0)");
   LOG("Saving thread...");
   PyThreadState* saved_thread = PyEval_SaveThread();
   LOG("Saved thread %p", saved_thread);
}

This produces output like
11:46:48.110058893: Restoring thread 0xabc480...
11:46:48.110121656: Restored thread 0xabc480
11:46:48.110166060: Restoring thread 0xabc480...
sleeping
11:46:48.110464194: Restored thread 0xabc480
sleeping
11:46:51.111307541: Saving thread...
11:46:51.111361075: Saved thread 0xabc480
11:46:51.113116633: Saving thread...
11:46:51.113177605: Saved thread 0xabc480

The thing that surprises me is that both threads seem to be able to pass
PyEval_RestoreThread before either reaches the corresponding
PyEval_SaveThread call, which I wasn't expecting to happen; I assumed that
since RestoreThread acquires the GIL, that thread state would remain locked
until it's released.

I understand that the system occasionally switches threads, which I guess
might well happen with that time.sleep() call, but I wasn't expecting the
same thread to become usable somewhere else. Maybe I am just confusing
things by approaching the same Python thread from multiple OS threads
concurrently and should be managing my own locking around that?

Storing the result of PyEval_SaveThread in a local variable looks wrong 
to me.


In the source for the regex module, I release the GIL with 
PyEval_SaveThread and save its result. Then, when I want to claim the 
GIL, I pass that saved value to PyEval_RestoreThread.


You seem to be releasing the GIL and discarding the result, so which 
thread are you resuming when you call PyEval_RestoreThread?


It looks like you're resuming the same thread twice. As it's already 
resumed the second time, no wonder it's not blocking!


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


Re: error of opening Python

2023-09-26 Thread Chris Roy-Smith via Python-list

On 26/9/23 22:27, Abdelkhelk ashref salay eabakh via Python-list wrote:

Dear Python team,

This is my not first time using Python, I tried to launch Python and it showed


I'm no expert but

"Python 3.11.3 (tags/v3.11.3:f3909b8, Apr  4 2023, 23:49:59) [MSC v.1934 64 bit 
(AMD64)] on win
surely running a 64 bit version of python in a 23mbit version of windows 
will cause significant problems!


try the correct python or windows

regards,




Type "help", "copyright", "credits" or "license" for more information." I
don't know what this meant and how to fix this. Could you please help me?
Thank you very much.

Kind regards




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


Re: error of opening Python

2023-09-26 Thread Michael F. Stemper via Python-list

On 26/09/2023 07.27, Abdelkhelk ashref salay eabakh wrote:

Dear Python team,

This is my not first time using Python, I tried to launch Python and it showed
"Python 3.11.3 (tags/v3.11.3:f3909b8, Apr  4 2023, 23:49:59) [MSC v.1934 64 bit 
(AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information." I
don't know what this meant and how to fix this. Could you please help me?


What error did you encounter? Aside from the lack of line breaks, it looks
quite similar to what I get when I start up python:

 Python 3.6.9 (default, Mar 10 2023, 16:46:00)
 [GCC 8.4.0] on linux
 Type "help", "copyright", "credits" or "license" for more information.
 >>>

Didn't you get the ">>> " prompt? Once you get it, it shows that the
Read, Evaluate, Print Loop (REPL) is ready for you to type some python
statements. For instance:

 >>> x = 2**3
 >>> print(x)
 8
 >>>

--
Michael F. Stemper
Outside of a dog, a book is man's best friend.
Inside of a dog, it's too dark to read.

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


error of opening Python

2023-09-26 Thread Abdelkhelk ashref salay eabakh via Python-list
Dear Python team,

This is my not first time using Python, I tried to launch Python and it showed
"Python 3.11.3 (tags/v3.11.3:f3909b8, Apr  4 2023, 23:49:59) [MSC v.1934 64 bit 
(AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information." I
don't know what this meant and how to fix this. Could you please help me?
Thank you very much.

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


The GIL and PyEval_RestoreThread

2023-09-26 Thread Peter Ebden via Python-list
Hi all,

I've been working on embedding Python and have an interesting case around
locking with PyEval_RestoreThread which wasn't quite doing what I expect,
hoping someone can explain what I should expect here.

I have a little example (I'm running this in parallel from two different
threads; I have some more C code for that but I don't think it's super
interesting):

void run_python(PyThreadState* thread) {
  LOG("Restoring thread %p...", thread);
  PyEval_RestoreThread(thread);
  LOG("Restored thread %p", thread);
  PyRun_SimpleString("import time; print('sleeping'); time.sleep(3.0)");
  LOG("Saving thread...");
  PyThreadState* saved_thread = PyEval_SaveThread();
  LOG("Saved thread %p", saved_thread);
}

This produces output like
11:46:48.110058893: Restoring thread 0xabc480...
11:46:48.110121656: Restored thread 0xabc480
11:46:48.110166060: Restoring thread 0xabc480...
sleeping
11:46:48.110464194: Restored thread 0xabc480
sleeping
11:46:51.111307541: Saving thread...
11:46:51.111361075: Saved thread 0xabc480
11:46:51.113116633: Saving thread...
11:46:51.113177605: Saved thread 0xabc480

The thing that surprises me is that both threads seem to be able to pass
PyEval_RestoreThread before either reaches the corresponding
PyEval_SaveThread call, which I wasn't expecting to happen; I assumed that
since RestoreThread acquires the GIL, that thread state would remain locked
until it's released.

I understand that the system occasionally switches threads, which I guess
might well happen with that time.sleep() call, but I wasn't expecting the
same thread to become usable somewhere else. Maybe I am just confusing
things by approaching the same Python thread from multiple OS threads
concurrently and should be managing my own locking around that?

Thanks in advance,

Peter

-- 
Thought Machine Group Limited, a company registered in England & Wales.
Registered number: 4277. 
Registered Office: 5 New Street Square, 
London EC4A 3TW 
.


The content of this email is confidential and intended for the recipient 
specified in message only. It is strictly forbidden to share any part of 
this message with any third party, without a written consent of the sender. 
If you received this message by mistake, please reply to this message and 
follow with its deletion, so that we can ensure such a mistake does not 
occur in the future.
-- 
https://mail.python.org/mailman/listinfo/python-list


Unable to uninstall 3.10.9

2023-09-26 Thread Pau Vilchez via Python-list
Hello Python Team,



I am somehow unable to completely remove Python 3.10.9 (64 Bit) from my
computer. I have tried deleting the Appdata folder then repairing and then
uninstalling but it still persists in the remove/add program function in
windows 10. I am just trying to reinstall it because I didn’t add it to the
path correctly, any help is greatly appreciated.



Very Respectfully,



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


Re: []=[]

2023-09-26 Thread Rob Cliffe via Python-list

It's not a bug, it's an empty unpacking.
Just as you can write
    [A,B] = [1,2] # Sets A to 1, B to 2
Best wishes
Rob Cliffe

On 23/09/2023 04:41, Greg Ewing via Python-list wrote:

On 23/09/23 4:51 am, Stefan Ram wrote:

[]=[]

   (Executes with no error.)


#
[]=[]
( 1 )
#\_/#

(Executes with no error.)



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


[Python-announce] ANN: NumExpr 2.8.7

2023-09-26 Thread Francesc Alted
Hi everyone,

NumExpr 2.8.7 is a release to deal with issues related to downstream
`pandas`
and other projects where the sanitization blacklist was triggering issues
in their
evaluate. Hopefully, the new sanitization code would be much more robust
now.

For those who do not wish to have sanitization on by default, it can be
changed
by setting an environment variable, `NUMEXPR_SANITIZE=0`.

If you use `pandas` in your packages it is advisable you pin

`numexpr >= 2.8.7`

in your requirements.

Project documentation is available at:

http://numexpr.readthedocs.io/

Changes from 2.8.6 to 2.8.7
---

* More permissive rules in sanitizing regular expression: allow to access
digits
  after the . with scientific notation.  Thanks to Thomas Vincent.

* Don't reject double underscores that are not at the start or end of a
variable
  name (pandas uses those), or scientific-notation numbers with digits
after the
  decimal point.  Thanks to Rebecca Palmer.

* Do not use `numpy.alltrue` in the test suite, as it has been deprecated
  (replaced by `numpy.all`).  Thanks to Rebecca Chen.

* Wheels for Python 3.12.  Wheels for 3.7 and 3.8 are not generated anymore.

What's Numexpr?
---

Numexpr is a fast numerical expression evaluator for NumPy.  With it,
expressions that operate on arrays (like "3*a+4*b") are accelerated
and use less memory than doing the same calculation in Python.

It has multi-threaded capabilities, as well as support for Intel's
MKL (Math Kernel Library), which allows an extremely fast evaluation
of transcendental functions (sin, cos, tan, exp, log...) while
squeezing the last drop of performance out of your multi-core
processors.  Look here for a some benchmarks of numexpr using MKL:

https://github.com/pydata/numexpr/wiki/NumexprMKL

Its only dependency is NumPy (MKL is optional), so it works well as an
easy-to-deploy, easy-to-use, computational engine for projects that
don't want to adopt other solutions requiring more heavy dependencies.

Where I can find Numexpr?
-

The project is hosted at GitHub in:

https://github.com/pydata/numexpr

You can get the packages from PyPI as well (but not for RC releases):

http://pypi.python.org/pypi/numexpr

Documentation is hosted at:

http://numexpr.readthedocs.io/en/latest/

Share your experience
-

Let us know of any bugs, suggestions, gripes, kudos, etc. you may
have.

Enjoy data!

-- 
Francesc Alted
___
Python-announce-list mailing list -- python-announce-list@python.org
To unsubscribe send an email to python-announce-list-le...@python.org
https://mail.python.org/mailman3/lists/python-announce-list.python.org/
Member address: arch...@mail-archive.com