71–80 of 80 posts
Earlier quoted context omitted.
It can already be written nicely as libpaths = paths.split(":") if paths else [] Please don't adopt unnecessary sigil junk from other languages.
This is subtly incorrect. Correctly, it should be: libpaths = paths.split(":") if paths is not None else [] or else falsey values of paths (0, [], False) can still cause an error.
Earlier quoted context omitted.
It can already be written nicely as libpaths = paths.split(":") if paths else [] Please don't adopt unnecessary sigil junk from other languages.
I think a better example to show why you might want a ?. operator would involve nested lookups. If you have something like node.child.attribute.value, handling potential Nones at each lookup with ifs would get very verbose very quickly (and that verbosity would be bad, as it would make it much harder to make out the main point of the code). You could surround the nested lookups in try/except and catch the AttributeEr…
if node and node.child and node.child.attribute:
…Earlier quoted context omitted.
It can already be written nicely as libpaths = paths.split(":") if paths else [] Please don't adopt unnecessary sigil junk from other languages.
I think a better example to show why you might want a ?. operator would involve nested lookups. If you have something like node.child.attribute.value, handling potential Nones at each lookup with ifs would get very verbose very quickly (and that verbosity would be bad, as it would make it much harder to make out the main point of the code). You could surround the nested lookups in try/except and catch the AttributeEr…
for child in node.children or []:
for attrib in child.attributes or []:
…I am quite concerned about the kinds of PEPs that come up lately (edit: I now noticed it's three years old). Python is drifting farther and farther away from its nature and strength. The amount of complexity is constantly going up and I don't think it's a good thing. Please let this language be what is is. A small amount of boilerplate in cases like this is fine and motivates you to restructure the code rather than h…
data = data if data is not None else [] data = data if data else [] data = data or []
data = []
data = None
For all intents and purposes, [] is the same as None when you're attempting a true/false if statement (of course it's not 100% but I'm trying to make the point).
Having a Null coalescing operator is a cheap and crappy way to escape proper variable definition and proper statement resolution, and it means you don't understand what your code actually does when reaching the compiler, or behavior in the memory. PEP 505 should be rejected.
On small trick that Pythonistas hate: x = x if None else x Saves a ton of CPU time and is beautiful.
I am quite concerned about the kinds of PEPs that come up lately (edit: I now noticed it's three years old). Python is drifting farther and farther away from its nature and strength. The amount of complexity is constantly going up and I don't think it's a good thing. Please let this language be what is is. A small amount of boilerplate in cases like this is fine and motivates you to restructure the code rather than h…
Earlier quoted context omitted.
I think a better example to show why you might want a ?. operator would involve nested lookups. If you have something like node.child.attribute.value, handling potential Nones at each lookup with ifs would get very verbose very quickly (and that verbosity would be bad, as it would make it much harder to make out the main point of the code). You could surround the nested lookups in try/except and catch the AttributeEr…
for nested loop you can do for child in node.children or []: for attrib in child.attributes or []: …
for child in node.children if node.children else []:
for attrib in child.attributes if child.attributes else []:
...
It will be interesting to see how this PEP is handled by the community with Guido off on a permanent vacation, and the mood among Python core devs seemingly "no major changes to syntax for the next little while" . Personally, some of the examples using the new operators are in fact easier to read, but others border on illegibility, and I don't think the tradeoff is wise. Then again, I felt the same way about Python's…
> It will be interesting to see how this PEP is handled by the community It was created three years ago, and it's still just a draft. Hopefully it won't go anywhere, with or without Guido around. EDIT: Raymond Hettinger is on the ball as always: "This PEP also shares some traits with PEP 572 in that it solves a somewhat minor problem with new syntax and grammar changes that affect the look and feel of the language in…
We have a lot of Django-based code similar to if getattr(obj, 'foreign_obj') is not None and getattr(obj.foreign_obj, 'field_name') is not None: Would this turn into: if obj?.foreign_obj?.field_name ? Does is look shorter? - YES!. Is it more readable? Arguably yes. Would I vote to see this feature in Python? HELL NO! In most of cases, we can have an in-house "maybe()" function, like maybe(obj, 'foreign_obj.field_name…
...why does everyone forget that `getattr()` has an optional `default` argument? It's helpful for stuff like this.
Earlier quoted context omitted.
The whole endeavor seems a bit quixotic to me. This kind of change would no doubt cause such a stir that there’d be a fork before long.
No, it's not that drastic, especially considering prior art in other languages Not supporting the change, but let's not be dramatic