Re: Incomplete sys.path with embeddable python (Windows)!?

[Greg Ewing via Python-list]

How are you invoking your script? Presumably you have some code
in your embedding application that takes a script path and runs
it. Instead of putting the code to update sys.path into every
script, the embedding application could do it before running
the script.

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

Junior Research Associate in HPC | Job position at CMCC Foundation, Italy

[info cmcc]

*Junior Research Associate in HPC*

*Deadline: May 15, 2023*
*The job location is CMCC Headquarters of Lecce*

The CMCC Foundation is a scientific research center on climate change and
its interactions with the environment, society, the world of business, and
policymakers.

Our work aims to stimulate sustainable growth, protect the environment and
develop strategies for adapting and mitigating climate change.

Our Division of Advanced Scientific Computing (ASC) is looking for a new
position of Junior Research Associate in HPC, responsible for *supporting
research activities in HPC*.

The position has been opened within the project *PNRR HPC SPOKE, CUP Number
C83C22000560007.*

The job location is CMCC Headquarters in *Lecce, Italy. *

We are looking for a motivated person with the following requirements:

   - *M.Sc. degree in Computer Science or Computer Engineering or
   equivalent fields;*
   - *3+ years’ experience in scientific software development and parallel
   programming;*
   - *Excellent knowledge of C and Fortran programming language;*
   - Parallel programming with MPI of scientific codes for heterogenous HPC
   architectures;
   - OpenACC/OpenMP and GPU programming;
   - Performance analysis of parallel codes;
   - *Expert with HPC systems;*
   - Fluent handling of scripting languages like Bash and Python;
   - Experience in complex software development and software version
   control systems (e.g. Git);
   - Knowledge in numerical methods and numerical schemes;
   - Knowledge in the application of computational fluid dynamics or
   weather and climate modelling is an asset;
   - *Good knowledge of both written and spoken English language.*

The project promotes female and youth employment and the reduction of
territorial gaps according to art.  47 “promotion of generational and
gender equal opportunities for the awarding of public contracts for the
implementation of the National Recovery and Resilience Plan (PNRR)”, of the
Italian Law Decree no. 77/2021 converted into law no. 108 of 29 July 2021.


*More details and info about HOW TO APPLY:
*
https://cmccfoundation.applytojob.com/apply/qCBuoQihlI/12447-Junior-Research-Associate-In-HPC
*-- *
Fondazione CMCC
Centro Euro-Mediterraneo sui Cambiamenti Climatici
Via Augusto Imperatore, 16 - 73100 Lecce
i...@cmcc.it - www.cmcc.it
-- 
https://mail.python.org/mailman/listinfo/python-list

Deadline Reminder: April 30, 2023 - Software Developer | Job position at CMCC Foundation, Italy

[info cmcc]

*Software Developer (Research Associate) code 12428*
(Deadline: April 30, 2023)

The CMCC Foundation is a scientific research center on climate change and
its interactions with the environment, the society, the world of business
and policy makers.

Our work aims to stimulate sustainable growth, protect the environment, and
develop strategies for the adaptation and mitigation of climate change.

Our Division of Ocean Predictions and Applications (OPA) is looking for new
positions of Software Developers, responsible for (i) supporting modelling
developments, implementation, and validation, (ii)
porting/recoding/re-engineering/developing numerical procedures in the
frame of ocean models, and (iii) deployment of applications and services
with virtualization software such as Virtual Machines and Dockers.

The job location is CMCC Headquarters in Lecce, Italy.

We are looking for motivated persons with the following requirements:

   - M.Sc. degree (or equivalent working experience) in Computer Science,
   Engineering, or other scientific disciplines (i.e., physics, mathematics);
   fluency in English;
   - knowledge of UNIX/Linux operating systems and script languages (i.e.,
   *nix shell);
   - good knowledge and skills in programming (i.e., Python and bash
   scripting);
   - knowledge of version control systems (i.e., git).

Furthermore, it is welcome that you have as much as possible of the
following experience:

   - knowledge of workflow management platforms;
   - knowledge of Fortran;
   - HPC architectures and job schedulers (i.e., IBM Spectrum LSF);
   - experience in managing/manipulating NetCDF data.




*More details and info about HOW TO APPLY:
https://cmccfoundation.applytojob.com/apply/WkA5Dhltc9/12428-Software-Developer-Research-Associate
*


-- 

Fondazione CMCCCentro Euro-Mediterraneo sui Cambiamenti Climatici
Via Marco Biagi, 5 - 73100 Lecce
i...@cmcc.it - www.cmcc.it
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Question regarding unexpected behavior in using __enter__ method

[aapost]

On 4/20/23 18:44, Lorenzo Catoni wrote:

Here, the TypeError occurred because "self" was passed as an input


Instantiate X and observe it there

x2 = X()

>>> X.__enter__

>>> X.__exit__
 at 0x...>
>>> x2.__enter__

>>> x2.__exit__
 of <__main__.X object at 0x...>>


To receive self the method must be bound. __enter__ = int doesn't bind 
the int type/class on instantiation, so it never gets self. Your custom 
function binds and receives self.


I am not sure if there is documentation to explain better specifically 
what makes makes type different and not bindable.


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

Re: Is npyscreen still alive?

[Thomas Passin]

On 4/21/2023 5:57 PM, Barry wrote:




On 21 Apr 2023, at 22:00, Grant Edwards  wrote:

I recently googled across the ncurses application framework npyscreen,
and was thinking about giving it a try for a small but real project
(something that would be distributed to customers), but I'm a bit
concerned that npyscreen no longer "alive".

The pypi page says the homepage is http://www.npcole.com/npyscreen/,
which then points to a Google Code page at 
https://code.google.com/archive/p/npyscreen/.

That page says the official repo is at https://bitbucket.org/npcole/npyscreen
which returns a 404.

There seems to be a copy in Github at 
https://github.com/npcole/npyscreen/commits/master,
but the last commit was almost 4 years ago.

Maybe it "just works" and is suitable for production?


Maybe this, recently lwn.net article, https://textual.textualize.io/
I was planning to check it out.


It's still pip-installable from PyPi.

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

Re: Is npyscreen still alive?

[Barry]

> On 21 Apr 2023, at 22:00, Grant Edwards  wrote:
> 
> I recently googled across the ncurses application framework npyscreen,
> and was thinking about giving it a try for a small but real project
> (something that would be distributed to customers), but I'm a bit
> concerned that npyscreen no longer "alive".
> 
> The pypi page says the homepage is http://www.npcole.com/npyscreen/,
> which then points to a Google Code page at 
> https://code.google.com/archive/p/npyscreen/.
> 
> That page says the official repo is at https://bitbucket.org/npcole/npyscreen
> which returns a 404.
> 
> There seems to be a copy in Github at 
> https://github.com/npcole/npyscreen/commits/master,
> but the last commit was almost 4 years ago.
> 
> Maybe it "just works" and is suitable for production?

Maybe this, recently lwn.net article, https://textual.textualize.io/
I was planning to check it out.

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

Is npyscreen still alive?

[Grant Edwards]

I recently googled across the ncurses application framework npyscreen,
and was thinking about giving it a try for a small but real project
(something that would be distributed to customers), but I'm a bit
concerned that npyscreen no longer "alive".

The pypi page says the homepage is http://www.npcole.com/npyscreen/,
which then points to a Google Code page at 
https://code.google.com/archive/p/npyscreen/.

That page says the official repo is at https://bitbucket.org/npcole/npyscreen
which returns a 404.

There seems to be a copy in Github at 
https://github.com/npcole/npyscreen/commits/master,
but the last commit was almost 4 years ago.

Maybe it "just works" and is suitable for production?




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

Re: Incomplete sys.path with embeddable python (Windows)!?

[Thomas Passin]

On 4/20/2023 5:47 PM, Ralf M. wrote:

Hello,

when I run a script with a "normally" installed python, the directory 
the script resides in is automatically added as first element to 
sys.path, so that "import my_local_module" finds my_local_module.py in 
the directory of the script.


However, when I run the same script with embeddable python ("Windows 
embeddable package (64-bit)", download link
https://www.python.org/ftp/python/3.11.3/python-3.11.3-embed-amd64.zip) 
the script directory is *not* prepended to the path, thus "import 
my_local_module" gives an ImportError.


I couldn't find an option to get the "normal" behaviour. Any ideas how 
to do that?


What I tried so far:

* The start-up value for sys.path seems to be defined in python311._pth. 
It looks that I can add further static paths to it, but I don't know how 
to make it add the script path (which can be different for different 
scripts).


* Uncommenting "import site" in python311._pth doesn't help.

* It seems that I could import something else in python311._pth, but I 
don't know how something imported from there could find out the path of 
the script that is about to be started.


* I read the (rather short) documentation of the embeddable package and 
of the site module several times but couldn't recognize a hint as to how 
to solve the issue.


* I can add the following lines to every script:
     import sys
     script_path = __file__.rsplit("\\", 1)[0]
     if script_path not in sys.path:
     sys.path[0:0] = [script_path]
     import my_local_modul
That works, but it's ugly, executing code between imports is frowned 
upon, and it needs to be added to every script.


Does anybody have a better idea?
Any help is appreciated.


I haven't worked with embeddable python, but here are some possibilities 
that came to mind, depending on how your system works -


1. If your script is started from the command line, sys.argv[0] gives 
the path to the script; You could use os.path.dirname() to get its 
directory.  This will end up the same place as your code fragment, but 
looks nicer and handles different path separators (e.g., Linux vs Windows);


2. You could write a little module that figures out the script's path 
and import that first in all your scripts.


3. If you know all the directories that your scripts will be in, you 
could add them all to a xx.pth file (do a search to make sure where to 
put .pth files for an embeddable case).


Not executing code between imports is a guideline, but guidelines are 
not laws and you can certainly deviate from them if there is a good reason.


My preference would be for 1) if at all possible.  Something like this 
(untested) -


import sys
import os.path

script_dir = os.path.dirname(sys.argv[0])
sys.path.insert(0, script_dir)  # Use built-in method to insert

Inserting the path entry again in case it's already there is not harmful 
so there's no need to check.  If for some reason sys.argv is not 
available, just substitute __file__.  That still won't be too clunky.

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

Re: Incomplete sys.path with embeddable python (Windows)!?

[Mats Wichmann]

On 4/20/23 15:47, Ralf M. wrote:

Hello,

when I run a script with a "normally" installed python, the directory 
the script resides in is automatically added as first element to 
sys.path, so that "import my_local_module" finds my_local_module.py in 
the directory of the script.


However, when I run the same script with embeddable python ("Windows 
embeddable package (64-bit)", download link
https://www.python.org/ftp/python/3.11.3/python-3.11.3-embed-amd64.zip) 
the script directory is *not* prepended to the path, thus "import 
my_local_module" gives an ImportError.


This is intended behavior - the question comes up from time to time. The 
embeddable distribution is intended to be part of an application, not a 
general-purpose Python you can call for just anything.


There are a bunch of details here, for example:

https://github.com/python/cpython/issues/79022


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

Incomplete sys.path with embeddable python (Windows)!?

[Ralf M.]

Hello,

when I run a script with a "normally" installed python, the directory 
the script resides in is automatically added as first element to 
sys.path, so that "import my_local_module" finds my_local_module.py in 
the directory of the script.


However, when I run the same script with embeddable python ("Windows 
embeddable package (64-bit)", download link
https://www.python.org/ftp/python/3.11.3/python-3.11.3-embed-amd64.zip) 
the script directory is *not* prepended to the path, thus "import 
my_local_module" gives an ImportError.


I couldn't find an option to get the "normal" behaviour. Any ideas how 
to do that?


What I tried so far:

* The start-up value for sys.path seems to be defined in python311._pth. 
It looks that I can add further static paths to it, but I don't know how 
to make it add the script path (which can be different for different 
scripts).


* Uncommenting "import site" in python311._pth doesn't help.

* It seems that I could import something else in python311._pth, but I 
don't know how something imported from there could find out the path of 
the script that is about to be started.


* I read the (rather short) documentation of the embeddable package and 
of the site module several times but couldn't recognize a hint as to how 
to solve the issue.


* I can add the following lines to every script:
import sys
script_path = __file__.rsplit("\\", 1)[0]
if script_path not in sys.path:
sys.path[0:0] = [script_path]
import my_local_modul
That works, but it's ugly, executing code between imports is frowned 
upon, and it needs to be added to every script.


Does anybody have a better idea?
Any help is appreciated.

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

ipaddress (was: Re: for a 'good python')

[Simon Ward]

On Thu, Apr 13, 2023 at 04:00:59PM +0100, Barry wrote:
Ipaddress was developed outside of the std lib and later added i 
recall.


I used it prior to it being in the standard library:
https://pypi.org/project/ipaddr/

Simon

--
A complex system that works is invariably found to have evolved from a
simple system that works.—John Gall
--
https://mail.python.org/mailman/listinfo/python-list

Re: Question regarding unexpected behavior in using __enter__ method

[Lorenzo Catoni]

Thankyou for your answer,
i think i found the reason for this behavior, is has to do with the
function being user defined or not, rather than being a plain function or
type, as stated here
https://docs.python.org/3/reference/datamodel.html#:~:text=Also%20notice%20that%20this%20transformation%20only%20happens%20for%20user%2Ddefined%20functions%3B%20other%20callable%20objects%20(and%20all%20non%2Dcallable%20objects)%20are%20retrieved%20without%20transformation

Regards,
Lorenzo Catoni

On Fri, 21 Apr 2023 at 07:21, Cameron Simpson  wrote:

> On 21Apr2023 00:44, Lorenzo Catoni  wrote:
> >I am writing to seek your assistance in understanding an unexpected
> >behavior that I encountered while using the __enter__ method. I have
> >provided a code snippet below to illustrate the problem:
> >
> >```
>  class X:
> >... __enter__ = int
> >... __exit__ = lambda *_: None
> >...
>  with X() as x:
> >... pass
> >...
>  x
> >0
> >```
> >As you can see, the __enter__ method does not throw any exceptions and
> >returns the output of "int()" correctly. However, one would normally
> expect
> >the input parameter "self" to be passed to the function.
>
> My descriptor fu is weak, but I believe this is because `int` is not a
> plain function but a type.
>
> Consider this class definition:
>
>  class X:
> x = 1
> def y(self):
> return "y"
>
> When you define a class, the body of the class is run in a namespace,
> and on completion, the namespace is _used_ to construct the class.
> During that process, the various names are considered. Here we've got 2
> names: "x" and "y".
>
> "x" refers to an int and is just stored as a class attribute, unchanged.
>
> "y" refers to a function, and is promoted to a descriptor of an unbound
> method.
>
> So later: X.x return 1 but X.y returns a unbound method. If we make an
> instance:
>
>  objx = X()
>
> then obj.x returns 1 (by not fining an "x" on "obj", but finding one on
> "type(obj)" i.e. the class attribute.
>
> By contrast, obj.y returns a bound method, a function already curried
> with a leading parameter "obj" (which will be "self"). There's no "y"
> attribute directly on "obj" but there's an unbound method on
> "type(obj).y", which gets bound by saying "obj.y".
>
> The means that what happens to a name when you define the class depends
> on the typeof the value bound to the name.
>
> A plain function gets turned into an unbound instance method, but other
> things are left alone.
>
> When you went:
>
>  __enter__ = int
>
> That's not a plain function and so "obj.__enter__" doesn't turn into a
> bound method - it it just `int`.
>
> Cheers,
> Cameron Simpson 
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Question regarding unexpected behavior in using __enter__ method

[Peter Otten]

On 21/04/2023 00:44, Lorenzo Catoni wrote:

Dear Python Mailing List members,

I am writing to seek your assistance in understanding an unexpected
behavior that I encountered while using the __enter__ method. I have
provided a code snippet below to illustrate the problem:

```

class X:

... __enter__ = int
... __exit__ = lambda *_: None
...

with X() as x:

... pass
...

x

0
```
As you can see, the __enter__ method does not throw any exceptions and
returns the output of "int()" correctly. However, one would normally expect
the input parameter "self" to be passed to the function.

On the other hand, when I implemented a custom function in place of the
__enter__ method, I encountered the following TypeError:

```

def myint(*a, **kw):

... return int(*a, **kw)
...

class X:

... __enter__ = myint
... __exit__ = lambda *_: None
...

with X() as x:

... pass
...
Traceback (most recent call last):
   File "", line 1, in 
   File "", line 2, in myint
TypeError: int() argument must be a string, a bytes-like object or a real
number, not 'X'
```
Here, the TypeError occurred because "self" was passed as an input
parameter to "myint". Can someone explain why this unexpected behavior
occurs only in the latter case?


Cameron is right, it's the descriptor protocol. Technically

inst.attr

invokes attr.__get__(...) if it exists:

>>> class A:
def __get__(self, *args): return args


>>> class B: pass

>>> class X:
a = A()
b = B()


>>> x = X()
>>> x.b
<__main__.B object at 0x02C2E388>
>>> x.a
(<__main__.X object at 0x02C2E280>, )

Python functions support the descriptor protocol

>>> hasattr(lambda: None, "__get__")
True

while builtin functions don't:

>>> hasattr(ord, "__get__")
False


I'm unsure whether to regard int as a class or or function, but as there
is no __get__

>>> hasattr(int, "__get__")
False

it behaves like builtin functions in this case.

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