from:"Silva"


Às 16:40 de 20/06/22, Dennis Lee Bieber escreveu:

On Mon, 20 Jun 2022 15:54:29 +0100, Paulo da Silva
 declaimed the following:


Às 15:07 de 19/06/22, jan Anja escreveu:

Dude, it's called CPython for a reason.


IMHO CPython means Core Python, not C Python.


It is, as I recall, a term for the reference implementation of Python,
which was written in C... In contrast to things like Jython -- Python
implemented using Java.


Yes, it is a reference. That's why it is called "Core Python". The "C" 
has nothing to do with the C programming language. It may well be 
written in any language. So far it is "C" language.

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

Re: What's up with modern Python programmers rewriting everything in Rust?


Às 15:07 de 19/06/22, jan Anja escreveu:

Dude, it's called CPython for a reason.


IMHO CPython means Core Python, not C Python.

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

Re: "CPython"


Às 18:19 de 20/06/22, Stefan Ram escreveu:

   The same personality traits that make people react
   to troll postings might make them spread unconfirmed
   ideas about the meaning of "C" in "CPython".

   The /core/ of CPython is written in C.

   CPython is the /canonical/ implementation of Python.

   The "C" in "CPython" stands for C.




Not so "unconfirmed"!
Look at this article, I recently read:
https://www.analyticsinsight.net/cpython-to-step-over-javascript-in-developing-web-applications/

There is a sentence in ther that begins with "CPython, short for Core 
Python, a reference implementation that other Python distributions are 
derived from, ...".


Anyway, I wrote "IMHO".

Do you have any credible reference to your assertion "The "C" in 
"CPython" stands for C."?


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

Re: "CPython"

Às 20:01 de 20/06/22, Paulo da Silva escreveu:

Às 18:19 de 20/06/22, Stefan Ram escreveu:

The same personality traits that make people react
to troll postings might make them spread unconfirmed
ideas about the meaning of "C" in "CPython".

The /core/ of CPython is written in C.

CPython is the /canonical/ implementation of Python.

The "C" in "CPython" stands for C.

Not so "unconfirmed"!
Look at this article, I recently read:
https://www.analyticsinsight.net/cpython-to-step-over-javascript-in-developing-web-applications/

There is a sentence in ther that begins with "CPython, short for Core
Python, a reference implementation that other Python distributions are
derived from, ...".

Anyway, I wrote "IMHO".

Do you have any credible reference to your assertion "The "C" in
"CPython" stands for C."?

Thank you.

Stefan Ram responded with a, at least, not very polite post.
That's why I needed to somehow "defend" why I posted that response, and,
BTW, trying to learn why he said that the C in CPython means "written in C".

I still find very strange, to not say weird, that a compiler or
interpreter has a name based in the language it was written. But, again,
is just my opinion and nothing more.

I rest my case.
Thank you all.
--
https://mail.python.org/mailman/listinfo/python-list

Re: "CPython"

Às 03:20 de 21/06/22, MRAB escreveu:

On 2022-06-21 02:33, Chris Angelico wrote:

On Tue, 21 Jun 2022 at 11:13, Paulo da Silva
 wrote:

Às 20:01 de 20/06/22, Paulo da Silva escreveu:
> Às 18:19 de 20/06/22, Stefan Ram escreveu:
>>    The same personality traits that make people react
>>    to troll postings might make them spread unconfirmed
>>    ideas about the meaning of "C" in "CPython".
>>
>>    The /core/ of CPython is written in C.
>>
>>    CPython is the /canonical/ implementation of Python.
>>
>>    The "C" in "CPython" stands for C.
>>
>>
>
> Not so "unconfirmed"!
> Look at this article, I recently read:
> 
https://www.analyticsinsight.net/cpython-to-step-over-javascript-in-developing-web-applications/ 

>
>
> There is a sentence in ther that begins with "CPython, short for Core
> Python, a reference implementation that other Python distributions are
> derived from, ...".
>
> Anyway, I wrote "IMHO".
>
> Do you have any credible reference to your assertion "The "C" in
> "CPython" stands for C."?
>
> Thank you.

Well ... I read the responses and they are not touching the point!
I just answered, with my opinion based on articles I have read in the
past. Certainly I could not be sure. That's why I responded as an
opinion (IMHO) and not as an assertion.
Stefan Ram responded with a, at least, not very polite post.
That's why I needed to somehow "defend" why I posted that response, and,
BTW, trying to learn why he said that the C in CPython means "written 
in C".

I still find very strange, to not say weird, that a compiler or
interpreter has a name based in the language it was written. But, again,
is just my opinion and nothing more.

Not sure why it's strange. The point is to distinguish "CPython" from
"Jython" or "Brython" or "PyPy" or any of the other implementations.
Yes, CPython has a special place because it's the reference
implementation and the most popular, but the one thing that makes it
distinct from all the others is that it's implemented in C.

And just to make it clear, the interpreter/compiler _itself_ is still 
called "python". "CPython" is a name/term that was applied retroactively 
to that particular implementation when another implementation appeared.
Yes, but that does not necessarily means that the C has to refer to the 
language of implementation. It may well be a "core" reference to 
distinguish that implementation from others with different behaviors.

Let's say they reimplement "reference python" CPython in Rust. What is 
better? Change the "reference python" CPython name to RPython, for 
example, or let it as CPython?

It's my opinion that it should stay as CPython.
After all who cares in which language it is implemented?

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

Re: "CPython"

Às 02:33 de 21/06/22, Chris Angelico escreveu:

On Tue, 21 Jun 2022 at 11:13, Paulo da Silva
wrote:

Às 20:01 de 20/06/22, Paulo da Silva escreveu:

Às 18:19 de 20/06/22, Stefan Ram escreveu:

The same personality traits that make people react
to troll postings might make them spread unconfirmed
ideas about the meaning of "C" in "CPython".

The /core/ of CPython is written in C.

CPython is the /canonical/ implementation of Python.

The "C" in "CPython" stands for C.

Not so "unconfirmed"!
Look at this article, I recently read:
https://www.analyticsinsight.net/cpython-to-step-over-javascript-in-developing-web-applications/

There is a sentence in ther that begins with "CPython, short for Core
Python, a reference implementation that other Python distributions are
derived from, ...".

Anyway, I wrote "IMHO".

Do you have any credible reference to your assertion "The "C" in
"CPython" stands for C."?

Thank you.

Well ... I read the responses and they are not touching the point!
I just answered, with my opinion based on articles I have read in the
past. Certainly I could not be sure. That's why I responded as an
opinion (IMHO) and not as an assertion.
Stefan Ram responded with a, at least, not very polite post.
That's why I needed to somehow "defend" why I posted that response, and,
BTW, trying to learn why he said that the C in CPython means "written in C".

I still find very strange, to not say weird, that a compiler or
interpreter has a name based in the language it was written. But, again,
is just my opinion and nothing more.

Not sure why it's strange. The point is to distinguish "CPython" from
"Jython" or "Brython" or "PyPy" or any of the other implementations.

Notice that they are, for example, Jython and not JPython.
There is also Cython that is a different thing.

And YES. You have the right to not feel that as strange.

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

Subtract n months from datetime


Hi!

I implemented a part of a script to subtract n months from datetime.
Basically I subtracted n%12 from year and n//12 from the month adding 12 
months when it goes<=0. Then used try when converting to datetime again. 
So, if the day is for example 31 for a 30 days month it raises a 
ValuError exception. Then I subtract 1 to day and repeat.


The code seems too naive and very very complicated!
What is the best way to achieve this? Any existent module?

At the very end, what I want is to subtract nx where x can be y, m, w, d 
for respectively years, months, weeks or days.


I feel I am missing something here ...

Thanks.
Paulo

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

Re: Subtract n months from datetime

2022-06-21 Thread Paulo da Silva


Às 05:44 de 21/06/22, Paul Bryan escreveu:

Here's how my code does it:


import calendar

def add_months(value: date, n: int):
   """Return a date value with n months added (or subtracted if
negative)."""
   year = value.year + (value.month - 1 + n) // 12
   month = (value.month - 1 + n) % 12 + 1
   day = min(value.day, calendar.monthrange(year, month)[1])
   return date(year, month, day)

Paul

I have a datetime, not a date.
Anyway, the use of calendar.monthrange simplifies the task a lot.

Assuming dtnow has the current datetime and dtn the number of months to 
be subtracted, here is my solution (the code was not cleaned yet - just 
a test):

dtnow_t=list(dtnow.timetuple()[:6]+(dtnow.microsecond,))
y=dtnow_t[0] # y,m,d,*_=dtnow_t seems slower
m=dtnow_t[1]
d=dtnow_t[2]
dy,dm=divmod(dtn,12)
y-=dy
m-=dm
if m<1:
m+=12
y-=1
daysinmonth=calendar.monthrange(y,m)[1]
d=min(d,daysinmonth)
dtnow_t[0]=y
dtnow_t[1]=m
dtnow_t[2]=d
bt=datetime.datetime(*dtnow_t)

Any comments are welcome.

Thank you.
Paulo




On Tue, 2022-06-21 at 05:29 +0100, Paulo da Silva wrote:

Hi!

I implemented a part of a script to subtract n months from datetime.
Basically I subtracted n%12 from year and n//12 from the month adding
12
months when it goes<=0. Then used try when converting to datetime
again.
So, if the day is for example 31 for a 30 days month it raises a
ValuError exception. Then I subtract 1 to day and repeat.

The code seems too naive and very very complicated!
What is the best way to achieve this? Any existent module?

At the very end, what I want is to subtract nx where x can be y, m,
w, d
for respectively years, months, weeks or days.

I feel I am missing something here ...

Thanks.
Paulo





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

Re: Subtract n months from datetime [Why?]

2022-06-22 Thread Paulo da Silva


Às 05:29 de 21/06/22, Paulo da Silva escreveu:

As a general response to some comments ...

Suppose we need to delete records from a database older than ...
Today, it's usual to specify days. For example you have to keep some gov 
papers for 90 days. This seems to come from computers era. In our minds, 
however, we immediately think 90 days=3 months.
For example, one may want to delete some files older than 9 months. It's 
far more intuitive than 270 days.
When we talk about years it is still going. For example I need to keep 
my receipts for 5 years because IRS audits.
Accepting this, it's intuitive, for example, that 3 months before July, 
31 is April, 30.

The same happens for the years. 5 years before February, 29 is February, 28.

Again, this is my opinion and that's the way I like it :-)
Regards
Paulo
--
https://mail.python.org/mailman/listinfo/python-list

Re: Subtract n months from datetime [Why?]

2022-06-22 Thread Paulo da Silva


Às 20:25 de 22/06/22, Barry Scott escreveu:




On 22 Jun 2022, at 17:59, Paulo da Silva  
wrote:

Às 05:29 de 21/06/22, Paulo da Silva escreveu:

As a general response to some comments ...

Suppose we need to delete records from a database older than ...
Today, it's usual to specify days. For example you have to keep some gov papers 
for 90 days. This seems to come from computers era. In our minds, however, we 
immediately think 90 days=3 months.
For example, one may want to delete some files older than 9 months. It's far 
more intuitive than 270 days.
When we talk about years it is still going. For example I need to keep my 
receipts for 5 years because IRS audits.
Accepting this, it's intuitive, for example, that 3 months before July, 31 is 
April, 30.
The same happens for the years. 5 years before February, 29 is February, 28.


The advantage of 30 days, 90 days etc is that a contract or law does not need 
to tell you
how to deal with the problems of calendar months.

As you say in peoples thoughts that 1 month or 3 months etc. But an accounts 
department
will know how to to the number of days till they have to pay up.

Yes. But my point is to justify why I want months. And it depends on the 
application.
Let's suppose a program for Joe User to clean something - files, for 
example. There are no rules except for the comfort of the user. He would 
prefer to be able to say 9 months back instead of 270 days. And by 9 
months, he expects to count down 9 months. Not 270 days.

That's what happens with the script I am writing.

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

Re: Subtract n months from datetime

2022-06-22 Thread Paulo da Silva


Às 19:47 de 22/06/22, Marco Sulla escreveu:

The package arrow has a simple shift method for months, weeks etc

https://arrow.readthedocs.io/en/latest/#replace-shift


At first look it seems pretty good! I didn't know it.
Thank you Marco.

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

Find the path of a shell command


Hi!

The simple question: How do I find the full path of a shell command 
(linux), i.e. how do I obtain the corresponding of, for example,

"type rm" in command line?

The reason:
I have python program that launches a detached rm. It works pretty well 
until it is invoked by cron! I suspect that for cron we need to specify 
the full path.
Of course I can hardcode /usr/bin/rm. But, is rm always in /usr/bin? 
What about other commands?


Thanks for any comments/responses.
Paulo

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

Re: Find the path of a shell command


Às 05:00 de 12/10/22, Paulo da Silva escreveu:

Hi!

The simple question: How do I find the full path of a shell command 
(linux), i.e. how do I obtain the corresponding of, for example,

"type rm" in command line?

The reason:
I have python program that launches a detached rm. It works pretty well 
until it is invoked by cron! I suspect that for cron we need to specify 
the full path.
Of course I can hardcode /usr/bin/rm. But, is rm always in /usr/bin? 
What about other commands?



Thank you all who have responded so far.
I think that the the suggestion of searching the PATH env seems the best.
Another thing that I thought of is that of the 'which', but, to avoid 
the mentioned recurrent problem of not knowing where 'which' is I would 
use 'type' instead. 'type' is a bash (sh?) command.


Thanks
Paulo


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

Re: Find the path of a shell command


Às 17:22 de 12/10/22, Tilmann Hentze escreveu:

Paulo da Silva  schrieb:

I have python program that launches a detached rm. It works pretty well
until it is invoked by cron! I suspect that for cron we need to specify
the full path.


Probably you could use os.unlink[1] with no problem.
No, because I need to launch several rm's that keep running after the 
script ends.



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

Re: Find the path of a shell command


Às 20:16 de 12/10/22, 2qdxy4rzwzuui...@potatochowder.com escreveu:

On 2022-10-12 at 17:43:18 +0100,
Paulo da Silva  wrote:


Às 17:22 de 12/10/22, Tilmann Hentze escreveu:

Paulo da Silva  schrieb:

I have python program that launches a detached rm. It works pretty well
until it is invoked by cron! I suspect that for cron we need to specify
the full path.


Probably you could use os.unlink[1] with no problem.

No, because I need to launch several rm's that keep running after the script
ends.


rm doesn't take that long.  Why are you detaching them?


Because the use of "rm -rf" here is to remove full dirs, mostly in 
external drives, each reaching more than hundreds thousand files.




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

Re: Find the path of a shell command


Às 19:14 de 12/10/22, Jon Ribbens escreveu:

On 2022-10-12, Paulo da Silva  wrote:

Às 05:00 de 12/10/22, Paulo da Silva escreveu:

Hi!

The simple question: How do I find the full path of a shell command
(linux), i.e. how do I obtain the corresponding of, for example,
"type rm" in command line?

The reason:
I have python program that launches a detached rm. It works pretty well
until it is invoked by cron! I suspect that for cron we need to specify
the full path.
Of course I can hardcode /usr/bin/rm. But, is rm always in /usr/bin?
What about other commands?


Thank you all who have responded so far.
I think that the the suggestion of searching the PATH env seems the best.
Another thing that I thought of is that of the 'which', but, to avoid
the mentioned recurrent problem of not knowing where 'which' is I would
use 'type' instead. 'type' is a bash (sh?) command.


If you're using subprocess.run / subprocess.Popen then the computer is
*already* searching PATH for you.

Yes, and it works out of cron.

Your problem must be that your cron
job is being run without PATH being set, perhaps you just need to edit
your crontab to set PATH to something sensible.

I could do that, but I am using /etc/cron.* for convenience.


Or just hard-code your
program to run '/bin/rm' explicitly, which should always work (unless
you're on Windows, of course!)

It can also be in /bin, at least.
A short idea is to just check /bin/rm and /usr/bin/rm, but I prefer 
searching thru PATH env. It only needs to do that once.



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

Re: Find the path of a shell command


Às 20:09 de 12/10/22, Antoon Pardon escreveu:



Op 12/10/2022 om 18:49 schreef Paulo da Silva:

Às 05:00 de 12/10/22, Paulo da Silva escreveu:

Hi!

The simple question: How do I find the full path of a shell command 
(linux), i.e. how do I obtain the corresponding of, for example,

"type rm" in command line?

The reason:
I have python program that launches a detached rm. It works pretty 
well until it is invoked by cron! I suspect that for cron we need to 
specify the full path.
Of course I can hardcode /usr/bin/rm. But, is rm always in /usr/bin? 
What about other commands?



Thank you all who have responded so far.
I think that the the suggestion of searching the PATH env seems the best.


I fear that won't work.

If it doesn't work in cron, that probably means, PATH is not set 
properly in your cron environment. And if PATH is not set properly, 
searching it explicitely won't work either.



It seems you are right :-( I didn't think of that!
Does 'type' bash command work? I don't know how bash 'type' works.
I need to do some tests.
Thanks
Paulo



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

Re: Find the path of a shell command

Às 22:38 de 12/10/22, Jon Ribbens escreveu:

On 2022-10-12, Jon Ribbens  wrote:

On 2022-10-12, Paulo da Silva  wrote:

Às 19:14 de 12/10/22, Jon Ribbens escreveu:

On 2022-10-12, Paulo da Silva  wrote:

Às 05:00 de 12/10/22, Paulo da Silva escreveu:

Hi!

The simple question: How do I find the full path of a shell command
(linux), i.e. how do I obtain the corresponding of, for example,
"type rm" in command line?

The reason:
I have python program that launches a detached rm. It works pretty well
until it is invoked by cron! I suspect that for cron we need to specify
the full path.
Of course I can hardcode /usr/bin/rm. But, is rm always in /usr/bin?
What about other commands?

Thank you all who have responded so far.
I think that the the suggestion of searching the PATH env seems the best.
Another thing that I thought of is that of the 'which', but, to avoid
the mentioned recurrent problem of not knowing where 'which' is I would
use 'type' instead. 'type' is a bash (sh?) command.

If you're using subprocess.run / subprocess.Popen then the computer is
*already* searching PATH for you.

Yes, and it works out of cron.

Your problem must be that your cron
job is being run without PATH being set, perhaps you just need to edit
your crontab to set PATH to something sensible.

I could do that, but I am using /etc/cron.* for convenience.

Or just hard-code your
program to run '/bin/rm' explicitly, which should always work (unless
you're on Windows, of course!)

It can also be in /bin, at least.

I assume you mean /usr/bin. But it doesn't matter. As already
discussed, even if 'rm' is in /usr/bin, it will be in /bin as well
(or /usr/bin and /bin will be symlinks to the same place).

A short idea is to just check /bin/rm and /usr/bin/rm, but I prefer
searching thru PATH env. It only needs to do that once.

I cannot think of any situation in which that will help you. But if for
some reason you really want to do that, you can use the shutil.which()
function from the standard library:

 >>> import shutil
 >>> shutil.which('rm')
 '/usr/bin/rm'

Actually if I'm mentioning shutil I should probably mention
shutil.rmtree() as well, which does the same as 'rm -r', without
needing to find or run any other executables.

Except that you can't have parallel tasks, at least in an easy way.
Using Popen I just launch rm's and end the script.

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

Re: Find the path of a shell command [POSTPONED]


Às 05:00 de 12/10/22, Paulo da Silva escreveu:

Hi!

The simple question: How do I find the full path of a shell command 
(linux), i.e. how do I obtain the corresponding of, for example,

"type rm" in command line?

The reason:
I have python program that launches a detached rm. It works pretty well 
until it is invoked by cron! I suspect that for cron we need to specify 
the full path.
Of course I can hardcode /usr/bin/rm. But, is rm always in /usr/bin? 
What about other commands?



For now I will postpone this problem.
I just wrote a small script to delete a dir using rm and it works even 
under cron!
There is another problem involved. The script, works fine except when 
launched by cron! Why?

I'll have to look into this later when I have more time.
For now I solved the problem using a complementary shell script.

Thank you very much to those who responded.
Paulo


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

A trivial question that I don't know - document a function/method

2022-10-22 Thread Paulo da Silva


Hi all!

What is the correct way, if any, of documenting a function/method?

1.
def foo(a,b):
""" A description.
a: Whatever 1
b: Whatever 2
"""
...

2.
def foo(a,b):
""" A description.
a -- Whatever 1
b -- Whatever 2
"""
...

3.
def foo(a,b):
""" A description.
@param a: Whatever 1
@param b: Whatever 2
"""
...

4.
def foo(a,b):
""" A description.
:param a: Whatever 1
:param b: Whatever 2
"""
...

5.
Any other ...

Any comments/suggestions are welcome.
Thanks.
Paulo

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

Typing: Is there a "cast operator"?


Hello!

I am in the process of "typing" of some of my scripts.
Using it should help a lot to avoid some errors.
But this is new for me and I'm facing some problems.

Let's I have the following code (please don't look at the program content):

f=None  # mypy naturally assumes Optional(int) because later, at open, 
it is assigned an int.

..
if f is None:
f=os.open(...
..
if f is not None:
os.write(f, ...)
..
if f is not None:
os.close(f)

When I use mypy, it claims
Argument 1 to "write" has incompatible type "Optional[int]"; expected "int"
Argument 1 to "close" has incompatible type "Optional[int]"; expected "int"

How to solve this?
Is there a way to specify that when calling os.open f is an int only?

I use None a lot for specify uninitialized vars.

Thank you.

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

Re: A trivial question that I don't know - document a function/method


Às 21:58 de 22/10/22, Paulo da Silva escreveu:

Hi all!

What is the correct way, if any, of documenting a function/method?



Thank you all for the, valuable as usual, suggestions.
I am now able to make my choices.

Paulo


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

Re: Typing: Is there a "cast operator"? [RESOLVED]


Às 21:36 de 23/10/22, Paulo da Silva escreveu:

Hello!

I am in the process of "typing" of some of my scripts.
Using it should help a lot to avoid some errors.
But this is new for me and I'm facing some problems.

Let's I have the following code (please don't look at the program content):

f=None  # mypy naturally assumes Optional(int) because later, at open, 
it is assigned an int.

..
if f is None:
 f=os.open(...
..
if f is not None:
 os.write(f, ...)
..
if f is not None:
 os.close(f)

When I use mypy, it claims
Argument 1 to "write" has incompatible type "Optional[int]"; expected "int"
Argument 1 to "close" has incompatible type "Optional[int]"; expected "int"

How to solve this?
Is there a way to specify that when calling os.open f is an int only?
And yes there is! Exactly the "cast" operator. A mistype led me to wrong 
search results. I'm sorry.


So, in the above code, we have to do:
os.write(cast(int,f), ...)
and
os.close(cast(int,f), ...)

Regards.
Paulo



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

Re: Typing: Is there a "cast operator"?

Às 23:56 de 23/10/22, Cameron Simpson escreveu:
On 23Oct2022 21:36, Paulo da Silva 
 wrote:

I am in the process of "typing" of some of my scripts.
Using it should help a lot to avoid some errors.
But this is new for me and I'm facing some problems.

Let's I have the following code (please don't look at the program 
content):

f=None  # mypy naturally assumes Optional(int) because later, at open, 
it is assigned an int.

..
if f is None:
f=os.open(...
..
if f is not None:
os.write(f, ...)
..
if f is not None:
os.close(f)

When I use mypy, it claims
Argument 1 to "write" has incompatible type "Optional[int]"; expected 
"int"
Argument 1 to "close" has incompatible type "Optional[int]"; expected 
"int"

How to solve this?
Is there a way to specify that when calling os.open f is an int only?

I use None a lot for specify uninitialized vars.

Maybe you shouldn't. The other way is to just not initialise the var at 
all. You could then just specify a type. Example:

    Python 3.8.13 (default, Aug 11 2022, 15:46:53)
    [Clang 12.0.0 (clang-1200.0.32.29)] on darwin
    Type "help", "copyright", "credits" or "license" for more
information.

    >>> f:int
    >>> f
    Traceback (most recent call last):
  File "", line 1, in 
    NameError: name 'f' is not defined
    >>>

So now `f` has `int` type definitely (for `mypy`'s purposes), and if 
used before assignment raises a distinctive error (versus having the 
value `None`, which you might then pass around, and perhaps successfully 
use in some contexts).

It is probably better on the whole to specify types up front rather than 
relying on `mypy` or similar to infer them. That way (a) you're stating 
your intent and (b) not relying on an inferred type, which if you've got 
bugs may be inferred _wrong_. If `mypy` infers a type incorrectly all 
the subsequent checks will also be flawed, perhaps subtly.

Yes.
I also use to make f unavailable (f=None) when something goes wrong and 
I don't want to stop the script but of course I could use "del f". I 
also need to care about using "try", which might be better than "if" tests.

A thing to think of ...

Thanks.
Paulo

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

A typing question

2022-10-29 Thread Paulo da Silva


Hi!

Consider this simple script ...

___
from typing import List, Optional

class GLOBALS:
foos=None

class Foo:

def __init__(self):
pass

class Foos:
Foos: List[Foo]=[]
# SOME GLOBALS ARE USED HERE in a real script

def __init__(self):
pass

GLOBALS.foos: Optional[Foos]=Foos()
___

Running mypy on it:
pt9.py:18: error: Type cannot be declared in assignment to non-self 
attribute
pt9.py:18: error: Incompatible types in assignment (expression has type 
"Foos", variable has type "None")

Line  18 is last line and pt9.py is the scrip.

Replacing last line by
GLOBALS.foos=Foos()
and running mypy still gives the second error.
pt9.py:18: error: Incompatible types in assignment (expression has type 
"Foos", variable has type "None")


What is the common practice in these cases?

Thank you.

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

Re: Fwd: A typing question

2022-10-29 Thread Paulo da Silva


Às 22:34 de 29/10/22, dn escreveu:
Out of interest, tested snippet in PyCharm, cf native-mypy. It flags the 
original:


     GLOBALS.foos: Optional[Foos]=Foos()

but not the fall-back:

     GLOBALS.foos=Foos()


Must admit, the first query coming to mind was: why is the typing taking 
place at initialisation-time, rather than within the (class) definition? 
At definition time "foos" has already been typed as None by implication!



Solution (below) will not work if the mention of Foos in GLOBALS is a 
forward-reference. Either move GLOBALS to suit, or surround "Foos" with 
quotes.
This is the problem for me. So far, without typing, I used to have some 
config and globals classes, mostly to just group definitions an make the 
program more readable. A matter of taste and style.
Now, "typing" is breaking this, mostly because of this forward reference 
issue.
The funny thing is that if I replace foos by Foos it works because it 
gets known by the initial initialization :-) !



from typing import List, Optional

class GLOBALS:
Foos: Optional[Foos]=None

class Foo:

def __init__(self):
pass

class Foos:
Foos: List[Foo]=[]
# SOME GLOBALS ARE USED HERE

def __init__(self):
pass

GLOBALS.Foos=Foos()







Also, these days (Python version allowing) importing "List" is 
unnecessary. Instead could use "list".




On 30/10/2022 10.23, Sam Ezeh wrote:

Do you want the following?

```
from typing import List, Optional


class GLOBALS:
 foos: Optional[Foos] = None


class Foo:
 def __init__(self):
 pass


class Foos:
 Foos: List[Foo] = []

 def __init__(self):
 pass


GLOBALS.foos = Foos()
```

Kind regards,
Sam Ezeh

On Sat, 29 Oct 2022 at 22:13, Paulo da Silva <
p_d_a_s_i_l_v_a...@nonetnoaddress.pt> wrote:


Hi!

Consider this simple script ...

___
from typing import List, Optional

class GLOBALS:
  foos=None

class Foo:

  def __init__(self):
  pass

class Foos:
  Foos: List[Foo]=[]
  # SOME GLOBALS ARE USED HERE in a real script

  def __init__(self):
  pass

GLOBALS.foos: Optional[Foos]=Foos()
___

Running mypy on it:
pt9.py:18: error: Type cannot be declared in assignment to non-self
attribute
pt9.py:18: error: Incompatible types in assignment (expression has type
"Foos", variable has type "None")
Line  18 is last line and pt9.py is the scrip.

Replacing last line by
GLOBALS.foos=Foos()
and running mypy still gives the second error.
pt9.py:18: error: Incompatible types in assignment (expression has type
"Foos", variable has type "None")

What is the common practice in these cases?

Thank you.

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






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

Re: Fwd: A typing question


Às 02:32 de 30/10/22, dn escreveu:

On 30/10/2022 11.59, Paulo da Silva wrote:
Solution (below) will not work if the mention of Foos in GLOBALS is a 
forward-reference. Either move GLOBALS to suit, or surround "Foos" 
with quotes.
This is the problem for me. So far, without typing, I used to have 
some config and globals classes, mostly to just group definitions an 
make the program more readable. A matter of taste and style.


Agreed, a good practice.

Thank you.



Now, "typing" is breaking this, mostly because of this forward 
reference issue.


As a first step, use the quotation-marks to indicate that such will be 
defined later in the code:-



class GLOBALS:
    Foos: Optional[Foos]=None 


class GLOBALS:
     Foos: Optional["Foos"]=None


Later, as gather (typing) expertise, can become more sophisticated, 
as-and-when...



The funny thing is that if I replace foos by Foos it works because it 
gets known by the initial initialization :-) !


Is the objective to write (good) code, or merely to satisfy the 
type-checker?


Something that is misleading is not going to be appreciated by others 
(including the +6-months you), eg


a = a + 1   # decrement total

Typing is not compulsory, and has been designed so that we can implement 
it a bit at a time, eg only one function amongst many contained by a 
module - if that's the only code that requires maintenance/update.


Best not to create "technical debt" though!

The main idea is to eventually catch some, otherwise "hidden", errors 
and produce better and cleaner code. Documentation is also a must.


Regards


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

Re: A typing question


Às 01:14 de 30/10/22, Thomas Passin escreveu:

On 10/29/2022 1:45 PM, Paulo da Silva wrote:

Hi!

Consider this simple script ...

___
from typing import List, Optional

class GLOBALS:
 foos=None

class Foo:

 def __init__(self):
 pass

class Foos:
 Foos: List[Foo]=[]
 # SOME GLOBALS ARE USED HERE in a real script

 def __init__(self):
 pass

GLOBALS.foos: Optional[Foos]=Foos()
___

Running mypy on it:
pt9.py:18: error: Type cannot be declared in assignment to non-self 
attribute
pt9.py:18: error: Incompatible types in assignment (expression has 
type "Foos", variable has type "None")

Line  18 is last line and pt9.py is the scrip.

Replacing last line by
GLOBALS.foos=Foos()
and running mypy still gives the second error.
pt9.py:18: error: Incompatible types in assignment (expression has 
type "Foos", variable has type "None")


What is the common practice in these cases?

Thank you.



I don't understand

class Foos:
  Foos: List[Foo]=[]

If "Foos" is supposed to be a class attribute, then it cannot have the 
same name as the class.

Yes it can.
You can refer it anywhere by Foos.Foos as a list of Foo elements.


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

Re: Fwd: A typing question


Às 10:26 de 30/10/22, Peter J. Holzer escreveu:

On 2022-10-29 23:59:44 +0100, Paulo da Silva wrote:

Às 22:34 de 29/10/22, dn escreveu:

Solution (below) will not work if the mention of Foos in GLOBALS is a
forward-reference.
Either move GLOBALS to suit, or surround "Foos" with quotes.

  ^^

This is the problem for me.


Quotes are a bit ugly, but why are they a problem?

[...]


The funny thing is that if I replace foos by Foos it works because it gets
known by the initial initialization :-) !


from typing import List, Optional

class GLOBALS:
 Foos: Optional[Foos]=None

[...]

class Foos:


That seems like a bug to me. What is the «Foos» in «Optional[Foos]»
referring to?

If it's the class attribute «Foos» then that's not a type and even if
its type is inferred that's not the same as «Optional[it's type]», or is
it?

If it's referring to the global symbol «Foos» (i.e. the class defined
later) that hasn't been defined yet, so it shouldn't work (or
alternatively, if forward references are allowed it should always work).


The problem is exactly this.
Is there anything to do without loosing my script structure and usual 
practice? The forward reference only is needed to the "typing thing".
Even if I declare class "Foos: pass" before, then another error arises - 
something like "already declared" below.



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

Re: Fwd: A typing question


Às 22:34 de 29/10/22, dn escreveu:
Out of interest, tested snippet in PyCharm, cf native-mypy. It flags the 
original:


     GLOBALS.foos: Optional[Foos]=Foos()

but not the fall-back:

     GLOBALS.foos=Foos()


Must admit, the first query coming to mind was: why is the typing taking 
place at initialisation-time, rather than within the (class) definition? 
At definition time "foos" has already been typed as None by implication!



Solution (below) will not work if the mention of Foos in GLOBALS is a 
forward-reference. Either move GLOBALS to suit, or surround "Foos" with 
quotes.

Somehow I missed this sentence the 1st. time I read this post :-(
This is good enough to me! Thank you.
I didn't know about this "quoting" thing.

Regards
Paulo


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

Re: Fwd: A typing question


Às 17:06 de 30/10/22, Stefan Ram escreveu:

Paulo da Silva  writes:

Is there anything to do without loosing my script structure and usual
practice?


   to lose (losing): to stop having something
   to loose (loosing): to let or make loose (see next line)
   loose (adj.): not firmly attached/tied/fastened/controlled
   to loosen: similar to "to loose"


It was a keyboard bounce ;-)
How about answering the question?
Thank you.



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

Re: Fwd: A typing question

2022-11-01 Thread Paulo da Silva


Às 21:08 de 31/10/22, Peter J. Holzer escreveu:

On 2022-10-30 11:26:56 +0100, Peter J. Holzer wrote:

On 2022-10-29 23:59:44 +0100, Paulo da Silva wrote:

The funny thing is that if I replace foos by Foos it works because it gets
known by the initial initialization :-) !


from typing import List, Optional

class GLOBALS:
 Foos: Optional[Foos]=None

[...]

class Foos:


That seems like a bug to me.


But is it even true?

I just tried to reproduce it (should have done that before answering)
with mypy 0.942 (included in Ubuntu 22.04 LTS):

[p1]---
from typing import List, Optional

class GLOBALS:
 foos: Optional[Foos]=None

class Foo:

 def __init__(self):
 pass

class Foos:
 Foos: List[Foo]=[]
 # SOME GLOBALS ARE USED HERE

 def __init__(self):
 pass

GLOBALS.foos=Foos()
---

[p2]---
from typing import List, Optional

class GLOBALS:
 Foos: Optional[Foos]=None

class Foo:

 def __init__(self):
 pass

class Foos:
 Foos: List[Foo]=[]
 # SOME GLOBALS ARE USED HERE

 def __init__(self):
 pass

GLOBALS.Foos=Foos()
---

--- p1  2022-10-31 21:59:49.639869922 +0100
+++ p2  2022-10-31 21:58:19.815830677 +0100
@@ -1,7 +1,7 @@
  from typing import List, Optional

  class GLOBALS:
-foos: Optional[Foos]=None
+Foos: Optional[Foos]=None

  class Foo:

@@ -15,4 +15,4 @@
  def __init__(self):
  pass

-GLOBALS.foos=Foos()
+GLOBALS.Foos=Foos()

So the only difference is the capitalization of foos. And mypy accepts
both (as it probably should):

% mypy p1
Success: no issues found in 1 source file
% mypy p2
Success: no issues found in 1 source file


If you did something different, please explain what you did.


Yes for mypy.
Try to run them (python3 ).

Paulo


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

typing: property/setter and lists?

2022-11-02 Thread Paulo da Silva


Hi!

And a typing problem again!!!
___
class C:
def __init__(self):
self.__foos=5*[0]

@property
def foos(self) -> list[int]:
return self.__foos

@foos.setter
def foos(self,v: int):
self.__foos=[v for __i in self.__foos]

c=C()
c.foos=5
print(c.foos)
___

mypy gives the following error:
error: Incompatible types in assignment (expression has type "int", 
variable has type "List[int]")


How do I turn around this?

Thanks.
Paulo

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

Re: typing: property/setter and lists? [RESOLVED]


Às 03:24 de 03/11/22, Paulo da Silva escreveu:

Hi!

And a typing problem again!!!
___
class C:
 def __init__(self):
     self.__foos=5*[0]

 @property
 def foos(self) -> list[int]:
     return self.__foos

 @foos.setter
 def foos(self,v: int):
     self.__foos=[v for __i in self.__foos]

c=C()
c.foos=5
print(c.foos)
___

mypy gives the following error:
error: Incompatible types in assignment (expression has type "int", 
variable has type "List[int]")


How do I turn around this?


Changing def foos(self) -> list[int]:  to
 def foos(self) -> Union[list[int]]:
fixes the problem.
Not so elegant, however!

Regards.
Paulo


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

Re: typing: property/setter and lists? [RESOLVED ERRATA]


Às 05:32 de 03/11/22, Paulo da Silva escreveu:

Às 03:24 de 03/11/22, Paulo da Silva escreveu:

Hi!

And a typing problem again!!!
___
class C:
 def __init__(self):
 self.__foos=5*[0]

 @property
 def foos(self) -> list[int]:
 return self.__foos

 @foos.setter
 def foos(self,v: int):
 self.__foos=[v for __i in self.__foos]

c=C()
c.foos=5
print(c.foos)
___

mypy gives the following error:
error: Incompatible types in assignment (expression has type "int", 
variable has type "List[int]")


How do I turn around this?


Changing def foos(self) -> list[int]:  to
  def foos(self) -> Union[list[int]]:

I meant, of course,
def foos(self) -> Union[list[int],int]:

Sorry.
Paulo


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

Re: typing: property/setter and lists? [RESOLVED]


Às 18:16 de 03/11/22, Chris Angelico escreveu:

On Fri, 4 Nov 2022 at 05:03, Paulo da Silva
 wrote:

Changing def foos(self) -> list[int]:  to
   def foos(self) -> Union[list[int]]:
fixes the problem.
Not so elegant, however!


Wait, what?!

Union[X, Y] means "X or Y"
Union[X] means "X, but don't complain if it's a @property".

Is that how it goes?

I'm sorry. A bad transposition of the text. I meant
def foos(self) -> Union[list[int],int]:

Regards.
Paulo


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

Re: typing: property/setter and lists?


Às 07:55 de 03/11/22, dn escreveu:

On 03/11/2022 16.24, Paulo da Silva wrote:

class C:
 def __init__(self):
 self.__foos=5*[0]

 @property
 def foos(self) -> list[int]:
 return self.__foos

 @foos.setter
 def foos(self,v: int):
 self.__foos=[v for __i in self.__foos]

c=C()
c.foos=5
print(c.foos)
___

mypy gives the following error:
error: Incompatible types in assignment (expression has type "int", 
variable has type "List[int]")



To help us to help you please copy-paste the *exact* message - 
especially which line is in-question.



The above code passes without complaint in PyCharm, and executes.


However, the general rule?convention would be to establish type at the 
first mention of the identifier, eg


def __init__(self):
     self.__foos:list[int] = 5 * [ 0 ]
# or [ 0, 0, 0, 0, 0, ]


Why the "__i", and not "i", or "_"?

Just because of my personal taste.
I know that __ means (for me) a "not used anymore" var and i is an 
indexer/counter/...


Regards.
Paulo


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

Re: typing: property/setter and lists? [RESOLVED ERRATA]

2022-11-04 Thread Paulo da Silva


Às 07:52 de 04/11/22, dn escreveu:

On 04/11/2022 07.50, Chris Angelico wrote:

On Fri, 4 Nov 2022 at 05:48, Paulo da Silva
 wrote:


Às 05:32 de 03/11/22, Paulo da Silva escreveu:

Às 03:24 de 03/11/22, Paulo da Silva escreveu:

Hi!

And a typing problem again!!!
___
class C:
  def __init__(self):
  self.__foos=5*[0]

  @property
  def foos(self) -> list[int]:
  return self.__foos

  @foos.setter
  def foos(self,v: int):
  self.__foos=[v for __i in self.__foos]

c=C()
c.foos=5
print(c.foos)
___

mypy gives the following error:
error: Incompatible types in assignment (expression has type "int",
variable has type "List[int]")

How do I turn around this?


Changing def foos(self) -> list[int]:  to
   def foos(self) -> Union[list[int]]:

I meant, of course,
def foos(self) -> Union[list[int],int]:



Ohhh! I thought this was triggering a strange quirk of the checker in
some way...



Yes, these personal styles (?quirks) are off-putting to others.

Plus "_" means (more or less) "not used anymore"
and for most of us, a weak-identifier name such as "i" is indeed "an 
indexer/counter/... "

Thank you for the suggestions.
BTW, I am not a python pro programmer. I use it as a tool as many other 
tools and some other (few) languages.


..

...and whilst I'm griping,
"To help us to help you please copy-paste the *exact* message"
has been followed by:
"I'm sorry. A bad transposition of the text."

copy-paste for the win!
(and to keep others happy to spend their voluntary time helping you - 
more working-with-the-team thinking to consider - please)
The full original message was there. Seemed to me that that was obvious 
considering the simplicity of the subject and the illustrative toy example.

Anyway, I'm sorry.

Thank you.
Paulo


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

spyder does not work under root! [linux]

Hi!

I need to debug a python3 script under root. I tried spyder but it does
not work.

Running as root without --no-sandbox is not supported. See
https://crbug.com/638180.

Thanks for any comments including alternative solutions to debug as root.

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

Re: spyder does not work under root! [linux]

Às 22:56 de 08/10/21, Paulo da Silva escreveu:
> Hi!
> 
> I need to debug a python3 script under root. I tried spyder but it does
> not work.
> 
> Running as root without --no-sandbox is not supported. See
> https://crbug.com/638180.
> 
> Thanks for any comments including alternative solutions to debug as root.
> 
I also tried with eric and curiously it gave the same message!!

This seems crazy.
-- 
https://mail.python.org/mailman/listinfo/python-list

Assign a value to a var content in an object

Hello!

Is there a better way of doing this?
Why didn't setattr (as commented) work?

Thanks for an help/comments.

class C:
def f(self,v):
#setattr(self,n,v)
self.__dict__['n']=v

c=C()
c.f(3)
print(c.n)

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

Re: Assign a value to a var content in an object