Consider removing slice and ~ syntax

[lordmauve]

Some of the syntactic sugar in bidict causes a readability problem for me. Syntactic sugar is always going to be subjective, but I'd like to propose the removal of the overloading of slicing and bitwise negation - because .inv is succinct and covers all these cases without needing the sugar:

• ~d is clearer written as d.inv
• d[:key] is clearer written as d.inv[key].

These don't need to be explained/learned in the same way as they follow from the same clear rule.

Naturally this would be a big breaking change but if bidict is not yet at a 1.0 release then this could presumably still be considered.

[jab]

Thanks for opening this. Until now the feedback about the slice syntax has been unanimously positive, so it's valuable to hear another perspective. Eliminating the slice syntax would also allow me to get rid of the caveat about not being able to access a None value via slice syntax (usually a very rare edge case, but one that bugs me nonetheless).

That said, before I remove one of bidict's most appealing features for so many users, I'd need to get more feedback in favor of this, ideally supported by empirical evidence that the sugar is doing harm. In the meantime, there's nothing stopping users who prefer to use .inv from doing so.

[lordmauve]

The syntax isn't doing harm, but I feel (from experience) that it makes it less suitable for adoption in a large project.

Clear, non magical APIs seem to be key to making Python scale to large codebases. Every caveat that a class brings in adds to the cognitive load.

[jab]

After sleeping on it, I'm reopening this. Dropping support for the slice syntax, as well as ~, seems like it could increase bidict's Python Zen on a few levels:

• Explicit is better than implicit.
• Simple is better than complex.
• Readability counts.
• Special cases aren't special enough to break the rules.
• There should be one-- and preferably only one --obvious way to do it.

It would also make the code cleaner and easier to maintain.

And being able to remove the "None value" caveat would be great.

I spent some time on GitHub code search surveying usage of slice and ~ syntax. Here is a sample of people whose code would break if I remove the syntax:

• @sgso (example)
• @cssmillie (example)
• @PersonalAnalytics (example)
• @prologic (example)
• @Nuullll (example)
• @PIA-Group (example)
• @AngryDevelopersLLC (example)
• @not-na (example)
• @ajmarks (example
• @makrai (example)

Everyone please give feedback here, and please spread the word to other bidict users. I'm leaning toward going through with this, but if users' feedback trumps the rationale above, I won't.

While we're at it, I'm also thinking of removing namedbidict. If you have any feedback on that, please chime in on #23.

Thanks everyone.

[ajmarks]

My project can easily be converted if you decide to change. I may just go ahead and do that preemptively.

[prologic]

What would the syntax change to?

cheers
James

James Mills / prologic

E: prologic@shortcircuit.net.au
W: prologic.shortcircuit.net.au

On Wed, Nov 25, 2015 at 10:38 AM, ajmarks notifications@github.com wrote:

My project can easily be converted if you decide to change. I may just go
ahead and do that preemptively.

—
Reply to this email directly or view it on GitHub
#19 (comment).

[jab]

@prologic You would use b.inv as you can do now. So b[:val] would become b.inv[val]. And just use b.inv rather than ~b (again as you can do now).

[prologic]

I see; thanks for that. I'm happy for this change to go ahead personally. I would however prefer something like b.inverse[key] however. Or even better: b.inverse(key)

[jab]

Thanks @prologic, glad you're happy for this to go ahead.

Changing to .inverse would mean another breaking change, and could annoy users who prefer the more concise .inv (myself included). Could add .inverse as an alias for .inv, but that seems against the spirit of this change (one obvious way to do things). Interested to hear more feedback though.

As for the callable rather than getitem syntax, again another breaking change, and harmfully masks the fact that b.inv is itself a bidict, and so should be accessed like one. Would reject anything that broke isomorphism between b and b.inv.

[jab]

FWIW, in my survey of bidict usage, I did encounter instances of people preferring to use b.inv[val] even with b[:val] available (example). So it would be good not to break the code of these users. /cc @alcemirfernandes

[prologic]

Fair points :) Go for it!

James Mills / prologic

E: prologic@shortcircuit.net.au
W: prologic.shortcircuit.net.au

On Wed, Nov 25, 2015 at 11:30 AM, jab notifications@github.com wrote:

FWIW, in my survey of bidict usage, I did encounter instances of people
preferring to use b.inv[val] even with b[:val] available (example
https://github.com/alcemirfernandes/pynguin/blob/631330a/lib/pynguin/mw.py#L2032).
/cc @alcemirfernandes https://github.com/alcemirfernandes

—
Reply to this email directly or view it on GitHub
#19 (comment).

[not-na]

My project could also easily be changed to a new syntax, if required.

[jab]

Implemented this on a branch and opened a PR for it in #25. Please take a look and test if you can.

[belevtsoff]

+1 for removal. That said, the project's been around for a while, so introducing backwards-incompatible changes at this point might do more harm than good.

[Nuullll]

My project could also easily be changed to a new syntax.

Thanks.

From Meizu MX4

-------- Original message --------
Sender: jab notifications@github.com
Time: Thu 11/26 01:53
To: jab/bidict bidict@noreply.github.com
Cc: Yilong Guo vfirst218@gmail.com
Subject: Re: [bidict] Consider removing slice and ~ syntax (#19)

After sleeping on it, I'm reopening this. Dropping support for the slice syntax, as well as ~, seems like it could increase bidict's Python Zen on a few levels:

• Explicit is better than implicit.
• Simple is better than complex.
• Readability counts.
• Special cases aren't special enough to break the rules.
• There should be one-- and preferably only one --obvious way to do it.

It would also make the code cleaner and easier to maintain.

And being able to remove the "None value" caveat would be great.

I spent some time on GitHub code search surveying usage of slice and ~ syntax. Here is a sample of people whose code would break if I remove the syntax:

• @sgso (example)
• @cssmillie (example)
• @PersonalAnalytics (example)
• @prologic (example)
• @Nuullll (example)
• @PIA-Group (example)
• @AngryDevelopersLLC (example)
• @not-na (example)
• @ajmarks (example
• @makrai (example)

Everyone please give feedback here, and please spread the word to other bidict users. I'm leaning toward going through with this, but if users' feedback trumps the rationale above, I won't.

While we're at it, I'm also thinking of removing namedbidict. If you have any feedback on that, please chime in on #23.

Thanks everyone.

---

Reply to this email directly or view it on GitHub:
#19 (comment)

[jab]

Thanks for the feedback, everyone. Just merged the branch that implements this.

[prologic]

Ping this issue when you've pushed a new release to PyPi :)

James Mills / prologic

E: prologic@shortcircuit.net.au
W: prologic.shortcircuit.net.au

On Sat, Nov 28, 2015 at 5:23 AM, jab notifications@github.com wrote:

Thanks for the feedback, everyone. Just merged the branch that implements
this.

—
Reply to this email directly or view it on GitHub
#19 (comment).

[jab]

Will do.

[jab]

@prologic Released!

[prologic]

👍

[pjsg]

Unfortunately our system just used the latest version of bidict -- so our system died when 0.10 was released (we used the slice syntax). This (again) teaches us the importance of version locking...

[jab]

@pjsg Sorry to hear you got bit by the breaking changes. I hope the bugfixes and other improvements in 0.10+ make it worth upgrading. Btw, just invited you to join https://gitter.im/jab/bidict. I always ping everyone in there with news (and Gitter can email you messages you missed while not in the chat), in case you're interested. Please feel free to stop by and say hi / share your use case any time.

[sublee]

I respect this decision. But it should warn DeprecationWarning first. Of course, I should lock the version too.

[jab]

@sublee Once bidict reaches 1.0, yes, but in the meantime, I'm following semver.org which says:

Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.

Hope that seems fair. FWIW, as of closing #23, I don't foresee making any further breaking changes before 1.0. My current thinking is bidict will be ready for 1.0 as soon I make sure that its performance is about equal to keeping 2 inverse dicts in sync manually (see #9). I may also add support for orderedbidict in a 0.11 release (see #29).

I invited you to join https://gitter.im/jab/bidict. As I said above, I always ping everyone in there with news (and Gitter can email you messages you missed while not in the chat), in case you're interested. Please feel free to stop by and say hi / share your use case any time. I love getting to know bidict's users better.

[sublee]

@jab Thanks to good answer. Now I agree your thinking.