Re: Local variable definition in Python list comprehension
On Thu, Sep 1, 2022 at 9:16 AM Chris Angelico wrote: > On Fri, 2 Sept 2022 at 02:10, James Tsai wrote: > > > > Hello, > > > > I find it very useful if I am allowed to define new local variables in a > list comprehension. For example, I wish to have something like > > [(x, y) for x in range(10) for y := x ** 2 if x + y < 80], or > > [(x, y) for x in range(10) with y := x ** 2 if x + y < 80]. > > > > For now this functionality can be achieved by writing > > [(x, y) for x in range(10) for y in [x ** 2] if x + y < 80]. > > > > Is it worthwhile to add a new feature like this in Python? If so, how > can I propose this to PEP? > > Not everything has to be a one-liner. > So true! I like list comprehensions and generator expressions, but sometimes I end up regretting their use when there's a bug, and I have to convert one to a for loop + list.append in order to debug. -- https://mail.python.org/mailman/listinfo/python-list
Re: Local variable definition in Python list comprehension
在 2022年9月2日星期五 UTC+2 00:17:23， 写道：
> On 02Sep2022 07:01, Chris Angelico wrote:
> >On Fri, 2 Sept 2022 at 06:55, James Tsai wrote:
> >> No but very often when I have written a neat list/dict/set
> >> comprehension, I find it very necessary
> >> to define local variable(s) to make it more clear and concise. Otherwise I
> >> have to break it down
> >> to several incrementally indented lines of for loops, if statements, and
> >> variable assignments,
> >> which I think look less nice.
> >
> >Well, if it's outgrown a list comp, write it on multiple lines. Like I
> >said, not everything has to be a one-liner.
> True, but a comprehension can be more expressive than a less
> "functional" expression (series of statements).
>
> James, can you provide (a) a real world example where you needed to
> write a series of statements or loops and (b) a corresponding example of
> how you would have preferred to have written that code, possibly
> inventing some syntax or misusing ":=" as if it workeed they way you'd
> like it to work?
>
> Cheers,
> Cameron Simpson
Yeah, I think list comprehension is particularly useful to construct a deeply
nested list/dict. For example, I am now using Plotly to visualize a cellular
network including several base stations and users. Here is the function I have
written:
def plot_network(area, base_stations, users):
bs_poses = np.array([bs.pos for bs in base_stations])
ue_poses = np.array([ue.pos for ue in users])
fig = px.scatter(x=bs_poses[:, 0], y=bs_poses[:, 1])
fig.add_scatter(x=ue_poses[:, 0], y=ue_poses[:, 1])
fig.update_layout(
xaxis=dict(range=[0, area[0]], nticks=5),
yaxis=dict(range=[0, area[1]], nticks=5),
shapes=[dict(
type="circle",
fillcolor="PaleTurquoise",
x0=x-r, y0=y-r, x1=x+r, y1=y+r,
hovertext=f"({x:.2f}, {y:.2f})",
opacity=0.3
) for bs in base_stations for x, y in [bs.pos]
for r in [bs.cell_radius]],
)
return fig
Simply put, I want to scatter the BSs and users, and additionally I want to
draw a big circle around each BS to represent its cell coverage. I can choose
to write 'x0=bs.pos[0]-bs.cell_radius, y0=...' instead, but it becomes less
concise, and if x, y, or r is the return value of a function instead of a
property, it becomes more computationally expensive to repeat calling the
function as well. I also can create the list of 'shapes' by appending to a
list, like
shapes = []
for bs in base_stations:
x, y = bs.pos
r = bs.cell_radius
shapes.append(dict(...))
fig.update_layout(
xaxis=dict(range=[0, area[0]], nticks=5),
yaxis=dict(range=[0, area[1]], nticks=5),
shapes=shapes
)
But in my opinion this is much less concise. I think it looks better to create
the list within the nested structure. So I totally agree that list
comprehension adds much expressiveness in Python. I only wonder whether it is a
good idea to introduce a specific syntax for local variable assignment in list
comprehensions, instead of using "for r in [bs.cell_radius]".
I am also surprised to know that the assignment operator ":=" in a list
comprehension will assign a variable outside of the scope of the comprehension.
I think it does not make sense since a list comprehension without a ":=" will
never change name bindings outside itself.
--
https://mail.python.org/mailman/listinfo/python-list
Re: When should I use "parent=None" in __ini__ and "parent" in super()
On 23Sep2021 20:38, Mohsen Owzar wrote: I'm writing since almost one-year codes in Python, using TKinter and PyQt5. I'm somehow able to writes GUIs in both of them. But since I'm using more Pyqt5 and using classes with initialization and super() constructs, and also I saw lots of videos and examples of coding them, I still don’t know exactly how and when should I use the parent in __init()__ and super() construct. Basicly, q Qt widget can always have a parent. You need to accomodate that parameter. Let's look at your first example, which is more correct: class MyClass1(QWidget): def __init__(self, name, parent=None): super(MyClass1, self).__init__(parent) print(self.parent().test) Here's you're defining the initialiser for your MyClass1 subclass. You do not specific handle parent, that is handled by the superclass. So: - accept an optional parent parameter as parameter=None - pass that parameter to the superclass initialiser for it to handle - proceed with the rest of your initialiser Note: when you've got just only superclass, it is simpler to call it's initialiser like this: super().__init__(parent) which avoids having to hardwire knowledge of the superclass in this line of code. Your second example is less correct: class MyClass2(QWidget): def __init__(self, name): super(MyClass2, self).__init__() print(self.parent().test) This subclass _does not_ accept an optional parent parameter. The parent class accepts an optional parent parameter, as before, but you haven't got one to supply and because it is optional in QWidget, things still work. Usually if you're subclassing a single other class, you might try to have even less knowledge of the subperclass. Example: class MyClass1(QWidget): def __init__(self, name, **kw): super().__init__(**kw) ... do something with name ... Here you have a parameter you yourself expect to specially handle (name) and also accept arbitrary other keyword parameters, which you pass straight off to the superclass initialiser. You neither know nor care if a parent was supplied, but by passing all the remaining keywork parameters you support it anyway. If you have some special parameters of your own the pattern looks like this: class MyClass1(QWidget): def __init__(self, name, myparam1=None, **kw): super().__init__(**kw) ... do something with name ... ... do something with myparam1 ... Here your subclass handles name and myparam1, and still leaves the rest for the superclass. Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
[Python-announce] pytest 7.1.3
pytest 7.1.3 has just been released to PyPI. This is a bug-fix release, being a drop-in replacement. To upgrade:: pip install --upgrade pytest The full changelog is available at https://docs.pytest.org/en/stable/changelog.html. Thanks to all of the contributors to this release: * Anthony Sottile * Bruno Oliveira * Gergely Kalmár * Nipunn Koorapati * Pax * Sviatoslav Sydorenko * Tim Hoffmann * Tony Narlock * Wolfremium * Zach OBrien * aizpurua23a Happy testing, The pytest Development Team ___ 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
