RE: In code, list.clear doesn't throw error - it's just ignored

[avi.e.gross]

Cameron,

What would be the meaning of an ordering relation determining what is MORE
VALID?

As has been pointed out, not only are some uses that look odd sometimes
valid, but perhaps even can be used in ways you simply may not see, such as
side effects. Some examples ranging from poor to horrible are mentioned
below.

In some languages, trying to access a variable that is not properly existing
or initialized, can generate an error, as an example, which may cause the
current function to terminate if not caught and jump up the call chain till
an error handler is found. Code like:

1/0

May seem meaningless as the result is not saved, but may trigger a divide by
zero error.

Is it an error to write code like:

If x.clear:
  pass

I suspect it is possible to write quite weird code that might pass most
linters but that does nothing useful and also to write code that is useful
but might be disparaged by many interpreters or linters. 

My example above is a fairly common code pattern while code is being written
as a sort of reminder to perhaps come back later and flesh it out properly,
or remove it if it is no longer applicable. If so, it would be reasonable
for it to be challenged and also to ignore such warnings until later when
either it is gone, or the code hint should be gone.

There are many cases where short-circuit evaluation means code is not run
such as "True || x"  that is less obvious but equally bypassed if you set a
variable to True and do not change it and use it instead of True above. But
is it an error? What if again, my later goal is to add code that may change
the Truth value. As it is, the statement is not evaluated. But it may be set
up as a placeholder to enhance later, perhaps long after, or retain some
flexibility. Insisting it be removed might be too harsh while a warning
might be reasonable. Yet again, it is not always an error to not use
something like declaring a variable you might need or importing a module you
never use. 

Code is chock full of such things in mid-stream. And you can deliberately
ignore some things without it being a mistake as in:

( _, mean, _) = minMeanMax(args)

Sure, it may be overkill to call a function that returns three things then
ignore two of them. So what? What if instead of "_" I used real variable
names like min and max? Should I get error messages that two variable are
set up with values but never again used?

Or consider what I sometimes do when I write code that someone else will use
and to test it I must use something like a different filename/path on my
machine than they do on theirs. I might write code like

# Comment out one or more of the below so only one exists:
Place = "whatever"
Place = "Some other place"

Clearly if I am using the second one, I can comment the first out OR I can
leave it alone and at minor expenses let the variable be unconditionally
reset to the second value. Is it a bug or a feature?

I could go on with other examples including some more subtle ones like
declaring a variable name just to mask another variable from being
accessible from a higher level and perhaps prevent the interpreter or
compiler  optimizing it away by using it in the meaningless way this
discussion began with as it has been accessed once.

One person's bug can be another person's feature. And clearly, as has been
mentioned, there MAY be subtle side effects like invoking your custom setter
or dunder method which also does logging or increments a count.

There is a spectrum between being overly permissive and overly strict. This
case almost amuses me because of the way that many a REPL works so something
run directly in a console will take an expression like  "varname" and PRINT
the current value to the screen. If the same code is run from a file, or
from inside some function, it does nothing useful and you need something
like "print(varname)" instead. People often cut and paste such snippets of
code and in one context they did something and in another, it seems
meaningless and possibly an error.

-Original Message-
From: Python-list  On
Behalf Of Cameron Simpson
Sent: Monday, November 14, 2022 9:34 PM
To: python-list@python.org
Subject: Re: In code, list.clear doesn't throw error - it's just ignored

On 14Nov2022 19:15, Dennis Lee Bieber  wrote:
>   There is also the minor facet that "x.clear" can be bound to a 
>different name...
>
 x = [1, 2, 3.145926536, "Pie"]
 clearx = x.clear
 x
>[1, 2, 3.145926536, 'Pie']
 clearx()
 x
>[]


I think the OP would take the stance that this:

 clearx = x.clear

is more valid than:

 x.clear

which discards the return value of the expression.

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

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

Re: Are these good ideas?

[Axy via Python-list]

On 15/11/2022 04:36, Dan Stromberg wrote:


On Mon, Nov 14, 2022 at 11:33 AM Axy via Python-list 
 wrote:


On 14/11/2022 17:14, Stephen Tucker wrote:
> Hi,
>
> I have two related issues I'd like comments on.
>
> Issue 1 - Global Values

Your "global variables" module acts exactly as a singleton class.


Which is apparently a design pattern that some now believe is regrettable.


Exactly. I dislike it too and always avoid. However, it could be a good 
starting point. Stepping directly into class-based approach would raise 
the same question: where to place global instance of that class. Gradual 
refactoring might have greater side effect of better overall design 
where many issues simply vanished by themselves. Maybe, (c) will change 
in favor of well-designed classes, who knows? Dropping singleton code is 
not a difficult task.


Axy.

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

Re: Are these good ideas?

[Dan Stromberg]

On Mon, Nov 14, 2022 at 11:33 AM Axy via Python-list 
wrote:

> On 14/11/2022 17:14, Stephen Tucker wrote:
> > Hi,
> >
> > I have two related issues I'd like comments on.
> >
> > Issue 1 - Global Values
>
> Your "global variables" module acts exactly as a singleton class.
>

Which is apparently a design pattern that some now believe is regrettable.

It's something I've done before too, but it's pretty much shared, mutable
state, which isn't great for functional programming or for parallelism.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: In code, list.clear doesn't throw error - it's just ignored

[Cameron Simpson]

On 14Nov2022 19:15, Dennis Lee Bieber  wrote:

There is also the minor facet that "x.clear" can be bound to a
different name...


x = [1, 2, 3.145926536, "Pie"]
clearx = x.clear
x

[1, 2, 3.145926536, 'Pie']

clearx()
x

[]




I think the OP would take the stance that this:

clearx = x.clear

is more valid than:

x.clear

which discards the return value of the expression.

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

Re: In code, list.clear doesn't throw error - it's just ignored

[Dennis Lee Bieber]

On Tue, 15 Nov 2022 09:11:10 +1100, Cameron Simpson 
declaimed the following:

>On 13Nov2022 22:23, DFS  wrote:
>>This is an easy check for the interpreter to make.
>
>It really isn't, given that (a) this isn't known by the interpreter to 
>be a `list` until runtime and (b) that would need embedding special 
>knowledge that looking up an attribute on a `list` has no side effects 
>(versus some other things, where it is not the case).
>

There is also the minor facet that "x.clear" can be bound to a
different name...

>>> x = [1, 2, 3.145926536, "Pie"]
>>> clearx = x.clear
>>> x
[1, 2, 3.145926536, 'Pie']
>>> clearx()
>>> x
[]
>>> 



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

Re: Debugging Python C extensions with GDB

[Jen Kris via Python-list]

Thanks for your reply.  Victor's article didn't mention ctypes extensions, so I 
wanted to post a question before I build from source.  


Nov 14, 2022, 14:32 by ba...@barrys-emacs.org:

>
>
>> On 14 Nov 2022, at 19:10, Jen Kris via Python-list  
>> wrote:
>>
>> In September 2021, Victor Stinner wrote “Debugging Python C extensions with 
>> GDB” 
>> (https://developers.redhat.com/articles/2021/09/08/debugging-python-c-extensions-gdb#getting_started_with_python_3_9).
>>  
>>
>> My question is:  with Python 3.9+, can I debug into a C extension written in 
>> pure C and called from ctypes  -- that is not written using the C_API?
>>
>
> Yes.
>
> Just put a breakpoint on the function in the c library that you want to debug.
> You can set the breakpoint before a .so is loaded.
>
> Barry
>
>>
>> Thanks. 
>>
>> Jen
>>
>>
>>
>> -- 
>> https://mail.python.org/mailman/listinfo/python-list
>>

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

Re: Are these good ideas?

[Thomas Passin]

On 11/14/2022 5:36 PM, Barry wrote:




On 14 Nov 2022, at 22:06, Thomas Passin  wrote:

For parameter passing like your #2, I have packaged them into a dictionary and 
passed that around.  It was easy enough, and worked well.


I used to use a dict but having been burnt with issues now create a class.

With a class you can add accessor methods that allow you to run debug code as 
values are changed. Also you can check that values being set are spelt 
correctly, have reasonable values etc.

Barry


Of course, it all depends on how you are going to use the parameters, 
whether you plan to mutate some of them in place, etc.  Mutating some of 
the input parameters can be useful, but also can lead to bugs that are 
harder to track down.  For simple cases, dicts will probably be fine. 
Otherwise, classes or data classes may be better, as you suggest.




The only potential problem is in documenting the key/value pairs the dictionary 
is supposed to contain.  You had better make sure it's made clear somewhere, 
preferable where it is consumed.

For "global" values, sure, put them in a module and import them as needed.  
Just make sure that none of your code is going to mutate those values, or you will end up 
with mass confusion.  I suppose you could make them be properties that have no setters, 
if you want to go to that trouble.


On 11/14/2022 12:14 PM, Stephen Tucker wrote:
Hi,
I have two related issues I'd like comments on.
Issue 1 - Global Values
Some years ago, I had a situation where
(a) I could supply low-level functions that carry out tasks,
(b) I needed those functions to communicate with each other, but
(c) I had no access to the module that invoked my functions.
In order to achieve this, I hit on the idea that I also supply a module
that I describe as a "global values" module. This module …
(i) … defines the values that the functions use to communicate with each
other;
(ii) … is the subject of an import statement in each of my functions;
(iii) … initialises its values at the start of each run (since the import
only carries out an actual import once per session);
(iv) … acts as a repository for the values thereafter.
This solution works well.
Given that I am not particularly concerned about efficiency,
(1) Is this a reasonable way to achieve this goal?
(2) Do you know of any better ways?
Issue 2 - Passed Parameters
I am now facing another situation where I am wanting to pass 6 or 7
parameters down through several layers of logic (function A calling
function B calling ... ) and for results to be passed back.
Having had the idea described above, I am considering using it again to
save all the parameter-and-results passing.
I see nothing wrong with doing that, but I may well be missing something!
Comments, please!
Stephen Tucker.


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




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

Re: Are these good ideas?

[Barry]

> On 14 Nov 2022, at 22:49, Chris Angelico  wrote:
> 
> On Tue, 15 Nov 2022 at 09:38, Barry  wrote:
>> 
>> 
>> 
 On 14 Nov 2022, at 22:06, Thomas Passin  wrote:
>>> 
>>> For parameter passing like your #2, I have packaged them into a dictionary 
>>> and passed that around.  It was easy enough, and worked well.
>>> 
>> I used to use a dict but having been burnt with issues now create a class.
>> 
>> With a class you can add accessor methods that allow you to run debug code 
>> as values are changed. Also you can check that values being set are spelt 
>> correctly, have reasonable values etc.
>> 
> 
> TBH you could add accessor methods to a dict just as easily

Its the dict interface that we found allowed for API abuse and lead to hard to 
fix bugs.

Barry

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

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

Re: Are these good ideas?

[Chris Angelico]

On Tue, 15 Nov 2022 at 09:38, Barry  wrote:
>
>
>
> > On 14 Nov 2022, at 22:06, Thomas Passin  wrote:
> >
> > For parameter passing like your #2, I have packaged them into a dictionary 
> > and passed that around.  It was easy enough, and worked well.
> >
> I used to use a dict but having been burnt with issues now create a class.
>
> With a class you can add accessor methods that allow you to run debug code as 
> values are changed. Also you can check that values being set are spelt 
> correctly, have reasonable values etc.
>

TBH you could add accessor methods to a dict just as easily

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

Re: Debugging Python C extensions with GDB

[Barry]

> On 14 Nov 2022, at 19:10, Jen Kris via Python-list  
> wrote:
> 
> In September 2021, Victor Stinner wrote “Debugging Python C extensions with 
> GDB” 
> (https://developers.redhat.com/articles/2021/09/08/debugging-python-c-extensions-gdb#getting_started_with_python_3_9).
>   
> 
> My question is:  with Python 3.9+, can I debug into a C extension written in 
> pure C and called from ctypes  -- that is not written using the C_API? 

Yes.

Just put a breakpoint on the function in the c library that you want to debug.
You can set the breakpoint before a .so is loaded.

Barry

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

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

Re: Are these good ideas?

[Barry]

> On 14 Nov 2022, at 22:06, Thomas Passin  wrote:
> 
> For parameter passing like your #2, I have packaged them into a dictionary 
> and passed that around.  It was easy enough, and worked well.
> 
I used to use a dict but having been burnt with issues now create a class.

With a class you can add accessor methods that allow you to run debug code as 
values are changed. Also you can check that values being set are spelt 
correctly, have reasonable values etc.

Barry

> The only potential problem is in documenting the key/value pairs the 
> dictionary is supposed to contain.  You had better make sure it's made clear 
> somewhere, preferable where it is consumed.
> 
> For "global" values, sure, put them in a module and import them as needed.  
> Just make sure that none of your code is going to mutate those values, or you 
> will end up with mass confusion.  I suppose you could make them be properties 
> that have no setters, if you want to go to that trouble.
> 
>> On 11/14/2022 12:14 PM, Stephen Tucker wrote:
>> Hi,
>> I have two related issues I'd like comments on.
>> Issue 1 - Global Values
>> Some years ago, I had a situation where
>> (a) I could supply low-level functions that carry out tasks,
>> (b) I needed those functions to communicate with each other, but
>> (c) I had no access to the module that invoked my functions.
>> In order to achieve this, I hit on the idea that I also supply a module
>> that I describe as a "global values" module. This module …
>> (i) … defines the values that the functions use to communicate with each
>> other;
>> (ii) … is the subject of an import statement in each of my functions;
>> (iii) … initialises its values at the start of each run (since the import
>> only carries out an actual import once per session);
>> (iv) … acts as a repository for the values thereafter.
>> This solution works well.
>> Given that I am not particularly concerned about efficiency,
>> (1) Is this a reasonable way to achieve this goal?
>> (2) Do you know of any better ways?
>> Issue 2 - Passed Parameters
>> I am now facing another situation where I am wanting to pass 6 or 7
>> parameters down through several layers of logic (function A calling
>> function B calling ... ) and for results to be passed back.
>> Having had the idea described above, I am considering using it again to
>> save all the parameter-and-results passing.
>> I see nothing wrong with doing that, but I may well be missing something!
>> Comments, please!
>> Stephen Tucker.
> 
> -- 
> https://mail.python.org/mailman/listinfo/python-list

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

Re: In code, list.clear doesn't throw error - it's just ignored

[Cameron Simpson]

On 13Nov2022 22:23, DFS  wrote:

On 11/13/2022 9:11 PM, Chris Angelico wrote:

[ ... `x.clear` ... ]
No part of it is invalid, so nothing causes a problem. For instance,
you can write this:


If it wastes time like that it's invalid.


It's a valid expression.

It looks to your eye like a no-op, but at actually Python _looks up the 
name `clear`_ on an object (which happens to be a `list`). That is a 
real thing to do, and can have side effects.


While most of the examples here have been in the REPL where running an 
expression with no side effects is itself useful, because the REPL can 
print the result, I've personally got some real world code with a bare 
`some_object.attribute` line. I'm not sure where, or I'd show it, but I 
_think_ it was probably prepriming a cached object property. There might 
have been a more expressive way to do that, but it was a bare attribute 
lookup with side effects, _used for those side effects_.



This is an easy check for the interpreter to make.


It really isn't, given that (a) this isn't known by the interpreter to 
be a `list` until runtime and (b) that would need embedding special 
knowledge that looking up an attribute on a `list` has no side effects 
(versus some other things, where it is not the case).


Linters are the best place for this: they warn about probably-mistakes 
idioms like this, and can have slightly deep knowledge of the code's 
semantics sometimes.


If I submit a suggestion to python-list@python.org will it just show 
up here?  Or do the actual Python devs intercept it?


Nah, it'll go through.

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

Re: Are these good ideas?

[Thomas Passin]

For parameter passing like your #2, I have packaged them into a 
dictionary and passed that around.  It was easy enough, and worked well.


The only potential problem is in documenting the key/value pairs the 
dictionary is supposed to contain.  You had better make sure it's made 
clear somewhere, preferable where it is consumed.


For "global" values, sure, put them in a module and import them as 
needed.  Just make sure that none of your code is going to mutate those 
values, or you will end up with mass confusion.  I suppose you could 
make them be properties that have no setters, if you want to go to that 
trouble.


On 11/14/2022 12:14 PM, Stephen Tucker wrote:

Hi,

I have two related issues I'd like comments on.

Issue 1 - Global Values

Some years ago, I had a situation where
(a) I could supply low-level functions that carry out tasks,
(b) I needed those functions to communicate with each other, but
(c) I had no access to the module that invoked my functions.

In order to achieve this, I hit on the idea that I also supply a module
that I describe as a "global values" module. This module …
(i) … defines the values that the functions use to communicate with each
other;
(ii) … is the subject of an import statement in each of my functions;
(iii) … initialises its values at the start of each run (since the import
only carries out an actual import once per session);
(iv) … acts as a repository for the values thereafter.

This solution works well.

Given that I am not particularly concerned about efficiency,
(1) Is this a reasonable way to achieve this goal?
(2) Do you know of any better ways?

Issue 2 - Passed Parameters

I am now facing another situation where I am wanting to pass 6 or 7
parameters down through several layers of logic (function A calling
function B calling ... ) and for results to be passed back.

Having had the idea described above, I am considering using it again to
save all the parameter-and-results passing.

I see nothing wrong with doing that, but I may well be missing something!

Comments, please!

Stephen Tucker.


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

Re: Are these good ideas?

[Axy via Python-list]

On 14/11/2022 17:14, Stephen Tucker wrote:

Hi,

I have two related issues I'd like comments on.

Issue 1 - Global Values


Your "global variables" module acts exactly as a singleton class. Funny, 
you could (and maybe you do) write in your functions


import global_vars_module as self

as the first step of refactoring.

From personal experience, when I worked at work we used modules for 
globals as well, but over time such an approach looked more and more 
ugly and finally was rejected.

Issue 2 - Passed Parameters

I am now facing another situation where I am wanting to pass 6 or 7
parameters down through several layers of logic (function A calling
function B calling ... ) and for results to be passed back.


Nothing fancy here, we used dicts for args and results.

Axy.

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

Re: In code, list.clear doesn't throw error - it's just ignored

[Chris Angelico]

On Tue, 15 Nov 2022 at 05:57, Stefan Ram  wrote:
>
> Michael Speer  writes:
> >Python doesn't care what an expression returns.
>
>   In my English, functions return values,
>   expression are being evaluated to a value.
>   The evaluation of a function yields or
>   produces a value. Expressions do not return,
>   because they are not functions.
>

Well, you can dispute the terminology all you like, but there's no
real difference between function calls and other types of expression.
They're all just expressions and they can be combined arbitrarily.

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

Debugging Python C extensions with GDB

[Jen Kris via Python-list]

In September 2021, Victor Stinner wrote “Debugging Python C extensions with 
GDB” 
(https://developers.redhat.com/articles/2021/09/08/debugging-python-c-extensions-gdb#getting_started_with_python_3_9).
  

My question is:  with Python 3.9+, can I debug into a C extension written in 
pure C and called from ctypes  -- that is not written using the C_API? 

Thanks. 

Jen



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

Re: In code, list.clear doesn't throw error - it's just ignored

[Jon Ribbens via Python-list]

On 2022-11-14, Stefan Ram  wrote:
> Jon Ribbens  writes:
>>"""Create an array and print its length"""
>>array = [1, 2, 3]
>>array.clear
>
>   BTW: Above, there are /two/ expression statements
>   with no effect; the other one is
>
> """Create an array and print its length"""
>
>   . Apparently, linters know this and will not create
>   a warning for such string literals.

Not only do they know this, pylint will complain if you *don't* include
that line, which is why I included it ;-)
-- 
https://mail.python.org/mailman/listinfo/python-list

[Python-announce] python-oracledb 1.2.0

[Anthony Tuininga]

What is python-oracledb?

python-oracledb is a Python extension module that enables access to Oracle
Database for Python and conforms to the Python database API 2.0
specifications with a number of enhancements. This module is intended to
eventually replace cx_Oracle.

Where do I get it?

https://pypi.org/project/oracledb/1.2.0/

The easiest method to install/upgrade python-oracledb is via pip as in

python -m pip install oracledb --upgrade

What's new?

This release adds support for binding and fetching data of type
oracledb.DB_TYPE_OBJECT (including SYS.XMLTYPE) in thin mode. It also adds
official support for Python 3.11 and addresses a number of smaller
enhancements and bug fixes.

See the full release notes for all of the details:
https://python-oracledb.readthedocs.io/en/latest/release_notes.html#oracledb-1-2-0-november-2022

Please provide any feedback via GitHub issues: https://github.com/oracle/
python-oracledb/issues or discussions: https://github.com/oracle/python-
oracledb/discussions
___
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

Re: Are these good ideas?

[Weatherby,Gerard]

Issue 1.

Depends very much on your operating system and application environment.

Issue 2.
I usually make myself a data class to pass around. Then when I figure out I 
forgot something, I just update the dataclass and the creator and consumer of 
it.

@dataclass
class CallParameter:
first : int
second: str

etc. I use context specific names, not “first” et. al.

From: Python-list  on 
behalf of Stephen Tucker 
Date: Monday, November 14, 2022 at 12:16 PM
To: Python 
Subject: Are these good ideas?
*** Attention: This is an external email. Use caution responding, opening 
attachments or clicking on links. ***

Hi,

I have two related issues I'd like comments on.

Issue 1 - Global Values

Some years ago, I had a situation where
(a) I could supply low-level functions that carry out tasks,
(b) I needed those functions to communicate with each other, but
(c) I had no access to the module that invoked my functions.

In order to achieve this, I hit on the idea that I also supply a module
that I describe as a "global values" module. This module …
(i) … defines the values that the functions use to communicate with each
other;
(ii) … is the subject of an import statement in each of my functions;
(iii) … initialises its values at the start of each run (since the import
only carries out an actual import once per session);
(iv) … acts as a repository for the values thereafter.

This solution works well.

Given that I am not particularly concerned about efficiency,
(1) Is this a reasonable way to achieve this goal?
(2) Do you know of any better ways?

Issue 2 - Passed Parameters

I am now facing another situation where I am wanting to pass 6 or 7
parameters down through several layers of logic (function A calling
function B calling ... ) and for results to be passed back.

Having had the idea described above, I am considering using it again to
save all the parameter-and-results passing.

I see nothing wrong with doing that, but I may well be missing something!

Comments, please!

Stephen Tucker.
--
https://urldefense.com/v3/__https://mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!hb_4MXkjG1NsyGoNsLJNDTOruPzfPWJKD-6vj0_2N1yqqtvz8oDZH3cT0EVkFbPTzSC19cAOgXlQdkDp7FZjwbyOjw$
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Are these good ideas?

[Karsten Hilbert]

Am Mon, Nov 14, 2022 at 05:14:05PM + schrieb Stephen Tucker:

> Issue 2 - Passed Parameters
>
> I am now facing another situation where I am wanting to pass 6 or 7
> parameters down through several layers of logic (function A calling
> function B calling ... ) and for results to be passed back.
>
> Having had the idea described above, I am considering using it again to
> save all the parameter-and-results passing.
>
> I see nothing wrong with doing that, but I may well be missing something!

Maybe pass and return a class ?  Maybe even a data class ?

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Are these good ideas?

[Paul Bryan]

Seems like this is a use case for context managers and/or context
variables:

https://docs.python.org/3/library/contextlib.html
https://docs.python.org/3/library/contextvars.html


On Mon, 2022-11-14 at 17:14 +, Stephen Tucker wrote:
> Hi,
> 
> I have two related issues I'd like comments on.
> 
> Issue 1 - Global Values
> 
> Some years ago, I had a situation where
> (a) I could supply low-level functions that carry out tasks,
> (b) I needed those functions to communicate with each other, but
> (c) I had no access to the module that invoked my functions.
> 
> In order to achieve this, I hit on the idea that I also supply a
> module
> that I describe as a "global values" module. This module …
> (i) … defines the values that the functions use to communicate with
> each
> other;
> (ii) … is the subject of an import statement in each of my functions;
> (iii) … initialises its values at the start of each run (since the
> import
> only carries out an actual import once per session);
> (iv) … acts as a repository for the values thereafter.
> 
> This solution works well.
> 
> Given that I am not particularly concerned about efficiency,
> (1) Is this a reasonable way to achieve this goal?
> (2) Do you know of any better ways?
> 
> Issue 2 - Passed Parameters
> 
> I am now facing another situation where I am wanting to pass 6 or 7
> parameters down through several layers of logic (function A calling
> function B calling ... ) and for results to be passed back.
> 
> Having had the idea described above, I am considering using it again
> to
> save all the parameter-and-results passing.
> 
> I see nothing wrong with doing that, but I may well be missing
> something!
> 
> Comments, please!
> 
> Stephen Tucker.

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

Are these good ideas?

[Stephen Tucker]

Hi,

I have two related issues I'd like comments on.

Issue 1 - Global Values

Some years ago, I had a situation where
(a) I could supply low-level functions that carry out tasks,
(b) I needed those functions to communicate with each other, but
(c) I had no access to the module that invoked my functions.

In order to achieve this, I hit on the idea that I also supply a module
that I describe as a "global values" module. This module …
(i) … defines the values that the functions use to communicate with each
other;
(ii) … is the subject of an import statement in each of my functions;
(iii) … initialises its values at the start of each run (since the import
only carries out an actual import once per session);
(iv) … acts as a repository for the values thereafter.

This solution works well.

Given that I am not particularly concerned about efficiency,
(1) Is this a reasonable way to achieve this goal?
(2) Do you know of any better ways?

Issue 2 - Passed Parameters

I am now facing another situation where I am wanting to pass 6 or 7
parameters down through several layers of logic (function A calling
function B calling ... ) and for results to be passed back.

Having had the idea described above, I am considering using it again to
save all the parameter-and-results passing.

I see nothing wrong with doing that, but I may well be missing something!

Comments, please!

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

Re: Problems with IDLE in Windows 8.1 and installer x86 Version 3.10.8

[darkstone]

Dear list,


>>So please check that you are running the right version of Python when 
>>you type "python".



If i type “python”, it is


C:\>python -V
Python 3.11.0
















Von: Thomas Passin
Gesendet: ‎Sonntag‎, ‎13‎. ‎November‎ ‎2022 ‎16‎:‎18
An: darkst...@o2online.de





On 11/13/2022 9:32 AM, Thomas Passin wrote:
> When you ran "python -V", the current directory was the top-level Python 
> directory.  So the Python version would automatically have been the same 
> as that directory's Python, that is, 3.11.
 >
 > When you ran the idlelib self test, you may have been in a different
 > directory, and so a different version of Python might possible have
 > been running.

To illustrate this point, on my system:

C:\Users\tom>python -V
Python 3.9.9

but

C:\Users\tom>py -V
Python 3.10.4

With the "py" script, I can run 3.9x this way:

py -3.9 -V
Python 3.9.9

and also:

C:\Users\tom>py -3.7 -V
Python 3.7.9

So please check that you are running the right version of Python when 
you type "python".
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: In code, list.clear doesn't throw error - it's just ignored

[Weatherby,Gerard]

The terminal told you what x.clear was.

The Python documentation tells you how to call it: 
https://docs.python.org/3/tutorial/datastructures.html

list.clear()
Remove all items from the list. Equivalent to del a[:].

An IDE (e.g. PyCharm) will try to autocomplete the parentheses and warn you if 
you don’t:

“Statement seems to have no effect and can be replaced with a function call to 
have effect”

From: Python-list  on 
behalf of DFS 
Date: Sunday, November 13, 2022 at 7:46 PM
To: python-list@python.org 
Subject: In code, list.clear doesn't throw error - it's just ignored
*** Attention: This is an external email. Use caution responding, opening 
attachments or clicking on links. ***

In code, list.clear is just ignored.
At the terminal, list.clear shows



in code:
x = [1,2,3]
x.clear
print(len(x))
3

at terminal:
x = [1,2,3]
x.clear

print(len(x))
3


Caused me an hour of frustration before I noticed list.clear() was what
I needed.

x = [1,2,3]
x.clear()
print(len(x))
0

--
https://urldefense.com/v3/__https://mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!jRrjG0fRo46VyY0jLfD1Z5C6tXDiphZy8zi2AqN_N5BB1_OwBe_wxmsBWmIVOFQDdZnvbRq1JNeGnPg$
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: In code, list.clear doesn't throw error - it's just ignored

[Karsten Hilbert]

Am Mon, Nov 14, 2022 at 02:13:34AM + schrieb MRAB:

> But if it's an expression where it's expecting a statement and it's not a 
> call, then
> it's probably a bug.

That "probably" makes it suitable for a linter, as was pointed out.

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: In code, list.clear doesn't throw error - it's just ignored

[Roel Schroeven]

Op 14/11/2022 om 4:23 schreef DFS:

On 11/13/2022 9:11 PM, Chris Angelico wrote:

On Mon, 14 Nov 2022 at 11:53, DFS  wrote:


On 11/13/2022 5:20 PM, Jon Ribbens wrote:

On 2022-11-13, DFS  wrote:

In code, list.clear is just ignored.
At the terminal, list.clear shows



in code:
x = [1,2,3]
x.clear
print(len(x))
3


But why is it allowed in the first place?

I stared at list.clear and surrounding code a dozen times and said
"Looks right!  Why isn't it clearing the list?!?!"

2 parens later and I'm golden!



No part of it is invalid, so nothing causes a problem. For instance,
you can write this:



If it wastes time like that it's invalid.


It's not invalid. In the REPL for example, it does something useful:

>>> x = [1, 2, 3]
>>> x.clear


Others have shown instances where writing a method or function without 
calling it are useful in a script too.


There are languages that handle this differently. Ruby, for example, 
calls the function/method even when you don't write the parens, if I'm 
not mistaken. Personally I don't like that; I much prefer Python's 
explicitness in making the difference between the value of a function 
and calling that function. Still, there's something to be said for 
warnings. I agree with others that such warnings are more the job for a 
linter than for the language.


FWIW I've been bitten by this in C++ once. I wanted to write something like

if (some_condition())
    foo();

But I forgot the parens after some_condition, so C++ evaluated the 
function pointer (which was non-NULL so evaluated is true in a boolean 
context) instead of the return value, and therefore foo() got called 
unconditionally.


--

"Don't Panic."
-- Douglas Adams, The Hitchhiker's Guide to the Galaxy

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