Re: In code, list.clear doesn't throw error - it's just ignored
On 15Nov2022 00:45, avi.e.gr...@gmail.com wrote: What would be the meaning of an ordering relation determining what is MORE VALID? Are you asking what criterion would rate: clearx = x.clear as "more" valid than: x.clear on its own? I don't want to speak for the OP, but I'd think the OP's issue is that the bare `x.clear` is evaluated but not stored in a variable. As a metric, we might gather various descriptive statements we could make about these statements. They'd perhaps include "is legal Python code", "is pretty simple". The former line could include "saves the expression value in a variable for later use" and the latter could not. That's a comparison test you could use for ordering. My own opinion is that a bare: x.clear is legal and valid for all the example use cases already mentioned, but an entirely valid target for complaint by a linter, whose task is to point out dodgy looking stuff for review by the author. Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
Re: Debugging Python C extensions with GDB
> On 14 Nov 2022, at 23:44, Jen Kris wrote: > > > Thanks for your reply. Victor's article didn't mention ctypes extensions, so > I wanted to post a question before I build from source. Gdb works on any program its not special to python. Victor is only talking about a specific use of gdb for python c extensions. Barry > > > 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: In code, list.clear doesn't throw error - it's just ignored
That is clear, Cameron, but on my python interpreter values evaluated on the command line ARE saved: >>> numb = 5 >>> 5 + numb 10 >>> numb 5 >>> _ + _ + 1 11 >>> _ * 2 22 >>> The point is that a dummy variable of _ is assigned and re-assigned at each step and there can be a valid, if not very useful, reason to evaluating it and storing a result. If the darn thing is a very long name like alpha.beta.gamma.delta.epsilon then code that uses it repeatedly in the very next line can be much simpler by using _ repeatedly and perhaps more efficient. Consider: negsq = _ * -_ versus negsq = alpha.beta.gamma.delta.epsilon * - alpha.beta.gamma.delta.epsilon So does your linter now need to look ahead and see if "_" is used properly in the next line? Note it can also be used on the LHS where it means something else. Still, I grant generally a naked evaluation is generally an error. LOL! -Original Message- From: Python-list On Behalf Of Cameron Simpson Sent: Tuesday, November 15, 2022 4:13 AM To: python-list@python.org Subject: Re: In code, list.clear doesn't throw error - it's just ignored On 15Nov2022 00:45, avi.e.gr...@gmail.com wrote: >What would be the meaning of an ordering relation determining what is >MORE VALID? Are you asking what criterion would rate: clearx = x.clear as "more" valid than: x.clear on its own? I don't want to speak for the OP, but I'd think the OP's issue is that the bare `x.clear` is evaluated but not stored in a variable. As a metric, we might gather various descriptive statements we could make about these statements. They'd perhaps include "is legal Python code", "is pretty simple". The former line could include "saves the expression value in a variable for later use" and the latter could not. That's a comparison test you could use for ordering. My own opinion is that a bare: x.clear is legal and valid for all the example use cases already mentioned, but an entirely valid target for complaint by a linter, whose task is to point out dodgy looking stuff for review by the author. Cheers, Cameron Simpson -- 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
On Wed, 16 Nov 2022 at 10:11, wrote: > > That is clear, Cameron, but on my python interpreter values evaluated on the > command line ARE saved: > > >>> numb = 5 > >>> 5 + numb > 10 > >>> numb > 5 > >>> _ + _ + 1 > 11 That's a REPL feature. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
RE: In code, list.clear doesn't throw error - it's just ignored
Yes, Chris, that is a REPL feature and one that people may use interactively. As you note, it does not work inside something like a function which the REPL is not trying to evaluate and print. So clearly my supposed use would not make much sense in such code. -Original Message- From: Python-list On Behalf Of Chris Angelico Sent: Tuesday, November 15, 2022 6:16 PM To: python-list@python.org Subject: Re: In code, list.clear doesn't throw error - it's just ignored On Wed, 16 Nov 2022 at 10:11, wrote: > > That is clear, Cameron, but on my python interpreter values evaluated > on the command line ARE saved: > > >>> numb = 5 > >>> 5 + numb > 10 > >>> numb > 5 > >>> _ + _ + 1 > 11 That's a REPL feature. ChrisA -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
potential feature "Yield in "
This is about a feature suggestion regarding having the ability to have parallel generators. Currently you can have generators and iterators that can yield a single value. or a collection of values (still a single value). But what if you could yield to multiple objects. In a sense build multiple generators but without having to set these up as return objects. The main concept is having a way to push values to multiple iterable objects from the same loop or code. We have the ability to zip multable iterables for use in parallel. Why not the reverse? As in create multiple generators in parallel. It's just an idea, and I haven't thought it through thoroughly nut I wanted to see if anyone had thoughts, critics or feedback. It would require not only a parser change, but also a new type which I am calling a Collector in my example. A class that has a method used to receive new items. Such a thing could be asynchronous. . Something like: ``` def split_values(values, *collectors): for i in values: for n, c in enumerate(collectors, 1): yield i**n in c class MyCollector(list, Collector): def __receive__(self, value): yield value collector0 = MyCollector() collector1 = MyCollector() split_values(range(1,6), collector0, collector1) for i in collector0: print(i) for i in collector1: print(i) ``` Which would result in output: ``` 1 2 3 4 5 1 4 9 16 25 ``` -- https://mail.python.org/mailman/listinfo/python-list
