On Mon, Aug 5, 2019 at 6:47 PM <raymond.hettin...@gmail.com> wrote: > > I wish people with more product management experience would chime in; > otherwise, 3.8 is going to ship with an intentional hard-to-ignore annoyance > on the premise that we don't like the way people have been programming and > that they need to change their code even if it was working just fine. >
I was resisting weighing in since I don't know the discussion around deprecating this language feature in the first place (other than what's given in this thread). However, in the product I work on we made a very similar change in our last release so I'll throw it out there for people to take what they will from it. We have a long standing feature which allows people to define groups of hosts and give them a name. In the past that name could include dashes, dots, and other characters which are not legal as Python identifiers. When users use those group names in our "DSL" (not truly a DSL but close enough), they can do it using either dictionary-lookup syntax (groupvars['groupname']) or using dotted attribute notation groupvars.groupname. We also have a longstanding problem where users will try to do something like groupvars.group-name.... using the dotted attribute notation with group names that aren't proper python identifiers. This causes problems as the name then gets split on the characters that aren't legal in identifiers and results in something unexpected (undefined variable, an actual subtraction operation, etc). In our last release we decided to deprecate and eventually make it illegal to use non-python-identifiers for the group names. At first, product management *did* let us get away with this. But after some time and usage of the pre-releases, they came to realize that this was a major problem. User's had gotten used to being able to use these characters in their group names. They had defined their group names and gotten used to typing their group names and built up a whole body of playbooks that used these group names.... Product management still let us get away with this.. sort of. The scope of the change was definitely modified. Users were now allowed to select whether invalid group names were disallowed (so they could port their installations), allowed with a warning (presumably so they could do work but also see that they were affected) or allow without a warning (presumably because they knew not to use these group names with dotted attribute notation) . This feature was also no longer allowed to be deprecated... We could have a warning that said "Don't do this" but not remove the feature in the future. Now... I said this was a config option.... So what we do have in the release is that the config option allows but warns by default and *the config option* has a deprecation warning. You see... we're planning on changing from warn by default now to disallowing by default in the future so the deprecation is flagging the change in config value. And you know what? User's absolutely hate this. They don't like the warning. They don't like the implication that they're doing something wrong by using a long-standing feature. They don't like that we're going to change the default so that they're current group names will break. They dislike that it's being warned about because of attribute-lookup-notation which they can just learn not to use with their group names. They dislike this so much that some of us have talked about abandoning this idea... instead, having a public group name that users use when they write in the "DSL" and an internal group name that we use when evaluating the group names. Perhaps that works, perhaps it doesn't, but I think that's where my story starts being specific to our feature and no longer applicable to Python and escape sequences.... Now like I said, I don't know the discussions that lead to invalid escape sequences being deprecated so I don't know whether there's more compelling reasons for doing it but it seems to me that there's even less to gain by doing this than what we did in Ansible. The thing Ansible is complaining about can do the wrong thing when used in conjunction with certain other features of our "DSL". The thing that the python escape sequences is complaining about are never invalid (As was pointed out, it's complaining when a sequence of two characters will do what the user intended rather than complaining when a sequence of two characters will do something that the user did not intend). Like the Ansible feature, though, the problem is that over time we've discovered that it is hard to educate users about the exact characteristic of the feature (\k == k but \n == newline; groupvars['group-name'] works but groupvars.group-name does not) so we've both given up on continuing to educate the users in favor of attempting to nanny the user into not using the feature. That most emphatically has not worked for us and has spent a bunch of goodwill with our users but the python userbase is not necessarily the same as ours so the audience may not be as tough to please. -Toshio P.S. One entry point to "discussions" about the Ansible feature: https://github.com/ansible/ansible/issues/56930 That bug starts off just asking for better documentation but becomes embroiled with other asks and just general dislike of the idea as a whole... getting linked to other issues, PRs, and referenced by mailing list threads..... The dislike of this feature really is a many headed hydra). _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/IERYIDCDTC2XWK5ITT7WVXFXPE4CLAA6/
