On Fri, Oct 15, 2021 at 2:53 PM Chris Angelico <ros...@gmail.com> wrote:
> On Sat, Oct 16, 2021 at 8:22 AM Jeremiah Paige <ucod...@gmail.com> wrote:
> >
> > Here is a pseudo-program showing where I would like to use this token in
> > my own code if it existed. I think besides the cases where one is forced
> to
> > always repeat the variable name as a string (namedtuple, NewType) this
> > is an easy way to express clear intent to link the variable name to
> either
> > its value or original source.
> >
> > >>> REGION = os.getenv(<<<)
> > >>> db_url = config[REGION][<<<]
> > >>>
> > >>> name = arguments.get(<<<)
> > >>>
> > >>> con = connect(db_url)
> > >>> knights = <<<
> > >>> horse = <<<
> > >>> con.execute(f"SELECT * FROM {knights} WHERE {horse}=?", (name,))
>
> Toys like this often don't sell the idea very well, because there's a
> solid criticism of every example:
>
> 1) The environment variable REGION shouldn't be assigned to a variable
> named REGION, because it's not a constant. In real-world code, I'd be
> more likely to write >> region = os.getenv('REGION') << which wouldn't
> work with this magic token.
> 2) I'd be much more likely to put the entire config block into a
> variable >> cfg = config[os.getenv("REGION")] << and then use
> cfg.db_url for all config variables, so they also wouldn't be doubling
> up the names.
> 3) Not sure what you're doing with arguments.get(), but if that's
> command line args, it's way easier to wrap everything up and make them
> into function parameters.
> 4) I've no idea why you'd be setting knights to the string literal
> "knights" outside of a toy. If it's for the purpose of customizing the
> table name in the query, wouldn't it be something like >> table =
> "knights" << ?
>
> I'm sure there are better examples than these, but these ones really
> aren't a great advertisement.
>
I'll admit I don't really have any further examples. After this idea came up
I found myself occasionally typing out code where I tried to reach for it
and wishing it was already implemented. But saying "I literally had to type
T = TypeVar("T") four times!" is not in itself a compelling example. Even
though I know I will have to type it again, and will again feel weird that
there is no better way to write this in python. I don't really write factory
functions this way myself, I just use them with what sounds like more
regularity than some.
I would absolutely use this syntax to gather some env vars, or declare
string flags, like in tix.py. My real world example that got me to circle
back
to this idea was writing a scraper that would collect as much metadata as
possible from a package. This meant walking many different static config
files that have lots of optional branches, or branches that can hold many
different kinds of data. This is the short bit that reads in a package's
long
description from pyproject.
>>> if readme := project.get("readme"):
>>> if isinstance(readme, str):
>>> self.readme = self._read_file(readme, "utf-8")
>>> elif text := readme.get("text"):
>>> if "file" in readme:
>>> raise CorruptPackage()
>>> self.readme = text
>>> else:
>>> charset = readme.get("charset", "utf-8")
>>> self.readme = self._read_file(readme["file"], charset)
A lot of lines in this example block are creating very short lived variables
based on the key name in the file read. I want the names to be kept in sync
with the config file, even though I have no fear of this specific standard
changing.
However you already said that unpacking in expression assignment is not
selling
the new syntax. And I see no one else sticking their head up to say this is
of
interest.
Regards,
~ Jeremiah
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/SFMN3L7AZ2GWJUQBC34DKF6ZOMKQA7DC/
Code of Conduct: http://python.org/psf/codeofconduct/
