This comes up pretty often. Every example can be replaced by a loop over a
single item list. It's a bit idiomatic, but not difficult. Many, as you
note, can use the new walrus operator instead.
[price for price in [item.get('price')] for item in basket if price is not
On Mon, Jul 15, 2019 at 10:21 AM Fabrizio Messina <zauddelig(a)gmail.com>
> It is likely not the first time such a proposal is being made but let's
> I would like to explicitly set variable names in list comprehensions using
> a where keyword, eventually set after the if keyword:
> [price for item in basket if price is not None where price := item.get(
> For this example one could use the walrus operator which is indeed
> [price for item in basket if price := item.get('price') is not None]
> But I fell that this approach is a bit opportunistic as one is doing two
> things at a time, if you allow me more lines for a somewhat more complex
> price * (1 + vat)
> item in basket
> price is not None
> price := item.get('price')
> vat := get_vat(item, user)
> Now this example may look pretty stupid and probably one may simply use
> for loop, but I feel that this kind of Haskell-like where inside of list
> comprehension will let the programmer have a space where they can
> explicitly state the variables.
> Best regards,
> Python-ideas mailing list -- python-ideas(a)python.org
> To unsubscribe send an email to python-ideas-leave(a)python.org
> Message archived at
> Code of Conduct: http://python.org/psf/codeofconduct/
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons. Intellectual property is
to the 21st century what the slave trade was to the 16th.
What would you think if we could write our code using unicode ?
It would be especially useful for scientific programming (we could use the
greek letters), it could also be nice to use emojis for some variables. I
don't see any bad consequences (apart from people that would use misleading
characters but that's already possible). I don't know how hard it is to do
that switch but it feels like it could be nice;
(Re-sending, because this was originally a reply to an off-list message by Nima Hamidi)
On Jul 13, 2019, at 14:12, Nima Hamidi <hamidi(a)stanford.edu> wrote:
> Sometimes it's necessary not to evaluate the expression. Two such applications of NSE in R are as follows:
> 1. Data-tables have cleaner syntax. For example, letting dt be a data-table with a column called price, one can retrieve items cheaper than $1 using the following: dt [price < 1]. Pandas syntax requires something like dt[dt.price < 1]. This is currently inevitable as the expression is evaluated *before* __getitem__ is invoked. Using NSE, dt.__getitem__ can, first, add its columns to locals() dictionary and then evaluate the expression in the new context.
This one looks good. I can also imagine it being useful for SQLAlchemy, appscript, etc. just as it is for Pandas.
But in your proposal, wouldn’t this have to be written as dt[`price < 1`]? I think the cost of putting the expression in ticks is at least as bad as the cost of naming the dt.
Also: dt.price < 1 is a perfectly valid expression, with a useful value. You can store it in a temporary variable to avoid repeating it, or stash it for later, or print it out to see what’s happening. But price < 1 on its own is a NameError, and I’m not sure what `price < 1` is worth on its own. Would this invite code that’s hard to refactor and even harder to debug?
> 2. Pipe-lining in R is also much cleaner. Dplyr provided an operator %>% which passes the return value of its LHS as the first argument of its RHS. In other words, f() %>% g() is equivalent to g(f()). This is pretty useful for long pipelines. The way that it works is that the operator %>% changes AST and then evaluates the modified expression. In this example, evaluating g() is undesirable.
This doesn’t seem necessary in a language with first-class functions. Why can’t you just write the pipeline as something f %>% g, much as you would in, say, Haskell, which would just define a function (presumably equivalent to either lambda: g(f()) or lambda *a, **kw: g(f(*a, **kw))) that represents the pipeline that you then just call normally? I don’t see the benefit in being able to write g() instead of g here, and in fact it seems actively misleading, because it implies calling g on no arguments instead of one.
Also, given that Python doesn’t have such an operator, or a way to define custom operators, and that proposals for even simpler operators on functions like @ for compose have been rejected every time they’ve been suggested, I wouldn’t expect much traction from this example. Is there something similar that could plausibly be done in Python, and feel Pythonic?
A couple more things I thought of since the initial reply…
I’m pretty sure Python’s AST objects don’t contain the original source text. So, what is your plot function going to actually do with its arguments to get the axes? What if it’s called with plot(`x[..., 3:]`)? Will plot—and every other function that wants to do something similar—need to come up with a way to generate the nicest source text that could produce the given AST? Or do we need to add a decompile to the stdlib for them? I suppose you could solve this by just adding more fields to BoundExpression, but I’m not sure that wouldn’t make it a lot harder to implement the backtick feature.
Backticks are supposed to be banned for the life of Python since 3.0 eliminated them as shorthand for repr. That could be revisited, but it might be a tough sell. Maybe the original “grit on Tim’s screen” reason is no longer as compelling because of higher-res screens and more uniform console fonts, but the rise to ubiquity of markdown seems like an even better reason not to use them. Today, you can paste Python code between backticks to mark it as code in markdown; if Python code can contain backticks, that’s no longer true. People who use languages that rely on backticks have been complaining about that for years; so we want to join them?
Finally, I think you need a fully worked-through example, not just a description of one. Show what the implementation of plot would look like if it could be handed BoundExpression objects. (Although pd.DataFrame.__getitem__ seems like the killer use case here, so maybe show that one instead, even though it’s probably more complicated.)
Could we add __enter__ and __exit__ to the tuple type?
Look at the following code:
a = open('a.tmp', 'w')
b = open('b.tmp', 'w')
with (a, b) as (af, bf):
Even better example:
with tuple(open(str(_n) + '.tmp', 'w') for _n in range(1000)) as f:
for n, fn in enumerate(f):
Tuple as context manager would invoke __enter__ for each of its elements
and return a tuple of the results.
On exit, the __exit__ method would be invoked for every element.
We could even generalize it to every kind of iterable.
This is somewhat consistent with treatment of exception types in
except Exception1 as error:
except (Exception2, Exception3) as error:
Tuple of exception types is accepted in 'except' clause, as well as a
single exception type. We could apply that rule to the 'with' clause.
in response to some of the recent spam, Brett and I have decided to put in place moderation for subscriptions, as well as moderating some of the newly subscribed accounts.
We feel that moderation of all messages is too much, given the (occasional) high volume of python-ideas, and its utility as a free-form discussion forum.
Currently the py[w] command will launch the latest python by default however I feel that this discourages the testing of pre-releases & release candidates as once they are installed they will become the default. What I would like is for the default to be the highest version number of a full release but the user to be able to specify a specific version even if it is a pre-release.
The currently py or py -3 would give python 3.7 (if installed) but py -3.8 would give the pre-release/release candidate if installed.
Any thoughts on whether this would be a good idea - I am quite willing to undertake the changes.
>>> a: 3
>>> type(a: 3)
File "<stdin>", line 1
SyntaxError: invalid syntax
>>> a: 3
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
NameError: name 'a' is not defined
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
NameError: name 'a' is not defined
At the sensual mixing state, nitric oxide starts getting free from the man's body that makes and spare cGMP in his hot organ. Finally, penile muscles get broaden and speed of blood is augmented due to unwinding and extension of male penile channels. Therefore, a man finally gets a hard and suffering erection. Sildenafil citrate is the generic of Sildenafil 100mg, which works by hampering the movement of PDE-5 proteins that further deters the breakdown of cGMP existing in the male private district. A presentation tablet of Sildenafil should be taken orally with one glass of water.
Hey all, after this talk
on how useful standard libraries are this has been in talks in multiple
I just wanted to present my idea on the same.
Why not keep the essentials (ensurepip) and strip off everything else. When
someone imports a package like datetime, we can catch the error
(ImportError) and install it.
Or something similar.
Please do let me know your feedback on why this might or might not be a
good option so that we can come up with better solutions for issues.
Thanks for the feedback Xavier
Indeed, this “last resort” strategy only works if your project source is a git repository. I rely on the excellent setuptools_scm to handle that special case. By the way if someone knows an equivalent for other popular scm systems, please let me know (or better suggest it here: https://github.com/smarie/python-getversion/issues )
I forgot to add something in my previous email: the original reason for developing this library was to provide a version-aware persistency layer based on json. Basically when you deserialize an object, your code would receive the associated version, which allows for legacy-aware deserialization (typically storing a machine learning model for 6 months and needing to upgrade your code while still being able to deserialize it).
I guess that this use case could also apply to pickle – from what I remember, pickle does not like it too much when the object to deserialize does not correspond to the same versions of the classes used.
De : Xavier Combelle <xavier.combelle(a)gmail.com>
Envoyé : samedi 6 juillet 2019 11:34
À : Sylvain MARIE <sylvain.marie(a)se.com>
Objet : Re: [Python-ideas] Getting the version number for a package or module, reliably
[External email: Use caution with links and attachments]
I'm certainly wrong, but version of a development version of a typical library is probably not reliable, as typically the version number is bumped when a new version is shipped so the code can be very different of the version given.
Le sam. 6 juil. 2019 11:13, Sylvain MARIE via Python-ideas <python-ideas(a)python.org<mailto:firstname.lastname@example.org>> a écrit :
Dear python enthusiasts,
For some industrial project a few years ago we needed a reliable way to get the version number for a package or module.
I found out that there was actually no method working in all edge cases, including:
* Built-in modules
* Unzipped wheels and eggs added to the python patch
* Non-installed project under development with version control information available
* Packages both installed and added to the python path (typically a developer working on a new version)
So I created one, and finally found the time to publish it.
No rocket science here, but you may find this new package useful: https://smarie.github.io/python-getversion/<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsmarie.gi…>
It works with any imported module for now, including submodules.
Along with the version you get details about why a given version number is returned (is it because of the __version__ attribute that was found, or because of the Version metadata in the installed package, etc.)
Also, if one edge case is missing, it is fairly easy to add it.
If I missed something in the stdlib (I acme across the importlib.metadata initiative but as of now it does not seem to cover all of the above cases), please let me know so that I can cite it in the documentation and even redirect to it if it happens to already cover all the cases.
Happy summer to all !
Python-ideas mailing list -- python-ideas(a)python.org<mailto:email@example.com>
To unsubscribe send an email to python-ideas-leave(a)python.org<mailto:firstname.lastname@example.org>
Message archived at https://email@example.com/message/OEXCP…<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.pyth…>
Code of Conduct: http://python.org/psf/codeofconduct/<https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpython.org…>
This email has been scanned by the Symantec Email Security.cloud service.