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.

Hi, we are using version bidict==0.18.0 and CPython 2.7.13 and got the following error here:

bidict/_abc.py in subclasshook at line 90

    def __subclasshook__(cls, C):  # noqa: N803 (argument name should be lowercase)
        """Check if *C* is a :class:`~collections.abc.Mapping`
        that also provides an ``inverse`` attribute,
        thus conforming to the :class:`BidirectionalMapping` interface,
        in which case it will be considered a (virtual) C
        even if it doesn't explicitly extend it.
        """
        that also provides an ``inverse`` attribute,
        thus conforming to the :class:`BidirectionalMapping` interface,
        in which case it will be considered a (virtual) C
        even if it doesn't explicitly extend it.
        """
        if cls is not BidirectionalMapping:  # lgtm [py/comparison-using-is]  # global name 'BidirectionalMapping' is not defined here
            return NotImplemented
        if not Mapping.__subclasshook__(C):
            return NotImplemented
        mro = getattr(C, '__mro__', None)
        if mro is None:  # Python 2 old-style class
        ...

C is a <type 'unicode'> here. So we simply pass unicode string to logger and such error raised. Looks like this happened because of the following line in python2.7/logging/init.py:

if (args and len(args) == 1 and isinstance(args[0], collections.Mapping)

Could anybody help with this issue? What we are doing wrong? Thanks in advance.

Maybe after removing support for older versions of Python.

Ref:

• https://docs.python.org/3/library/typing.html
• https://mypy.readthedocs.io/en/stable/generics.html#defining-sub-classes-of-generic-classes
• MagicStack/immutables#13

issubclass(bidict, dict) returns False. We thus cannot pass it to function that test it. If dict were at least at last place of mro it would be settled.

• raise ValueExistsException on insert new key associated with existing value
• stifled by forceput just like CollapseException was
• ValueExistsException replaces CollapseException since it's more general
• rename collapsingbidict loosebidict now that ValueExistsException has replaced CollapseException
• add forceupdate method for bulk forceput
• update docs and tests

The license title is not strictly required, but it's useful metadata, and part of the recommended license template text:

• http://choosealicense.com/licenses/isc/
• https://opensource.org/licenses/isc-license
• http://spdx.org/licenses/ISC.html#licenseText

The short identifier has been codified by both SPDX and OSI as "ISC" -- see https://opensource.org/licenses/ISC and http://spdx.org/licenses/ISC.html.

Hi,

We are working with @hgoldstein95, @bcpierce00, @lemonidas and @seyoungjkim on a mutation testing tool developped as a pytest plugin, called pytest-mutagen. It allows the user to introduce some mutated versions of its functions to check that its test suite catches them.

It's particularly suited for property-based testing, and that's why we decided to use it on bidict. We found some trivial mutants (like replacing the "clear" or "put" function by just "pass") that were not caught by your test suite, so we added some properties to the existing ones to make sure that they are now caught.

To witness this you can simply run these commands in the bidict repo (branch new_properties) : python3 -m pip install pytest-mutagen ./run_tests.py --mutate --quick-mut -q

Therefore we think that these properties could be a relevant addition to yours.

The fact that every bidict creates an holds a reference to its inverse bidict, and each inverse holds a reference to the forward bidict, means that bidicts will create reference cycles.

This has two implications:

1. Memory won't be reclaimed immediately if the references are deleted. They will be reclaimed by the garbage collector - but at some later point. Large bidicts could therefore hold memory much longer than a standard dict.
2. Prior to Python 3.4, any subclasses of bidict that happen to implement __del__() methods won't be garbage collectable at all.

I'm not sure how important this is, but it's more important the less you know about ways in which bidict is used.

A workaround might be not to hold a full reference to inv, but to instead hold a weak memoized reference. This would guarantee

d.inv.inv is d

but would allow immediate reclamation of either side of the bidict pair if no reference to them are held.

Hi, Pull request 107 has removed __all__ from bidict/__init__.py.

This leads to implicit reexports of all the imported classes etc., which generates a error when typechecking with mypy in strict mode (which sets --no-implicit-reexport).

So for example with test.py...

from bidict import bidict, BidirectionalMapping
element_by_symbol: BidirectionalMapping[str, str] = bidict({'H': 'hydrogen'})

... due to disallowing implicit reexports, the imports will not be found by mypy, while the code obviously works:

$ mypy --strict .\test.py
test.py:1: error: Module 'bidict' has no attribute 'bidict'
test.py:1: error: Module 'bidict' has no attribute 'BidirectionalMapping'; maybe "MutableBidirectionalMapping"?
Found 2 errors in 1 file (checked 1 source file)

Was there some reasoning behind removing __all__ or could it be re-added? Thanks in advance. :)

I see considerable value preventing people accidentally creating mappings that are not invertible. In our codebase, there are several hundred instances of code like

PRODUCT_REMAP = {... hundreds of lines ...}
REVERSE_PRODUCT_REMAP = dict((v, k) for k, v in PRODUCT_REMAP.iteritems())

A concern with these is that literals that were accidentally written to include duplicate values would create an incorrect inverse mapping.

Using bidict does little to improve matters. In code like that below, one of those keys will "win":

d = bidict({
     'foo': 1,
     ... hundreds of lines ...
     'bar': 1
})

This has the advantage that the inverse mapping will genuinely reflect the forward mapping, but it carries the disadvantage the mapping for one of the keys is lost. In many cases this is worse - for example, when the forward mapping is fundamental and the inverse mapping is just informational. The only reasonable solution in cases like these is to throw an exception for the programmer to deal with.

I suggest creating a "strictbidict" in which _put() throws a CollapseException if any value is duplicated, rather than dropping the previous key that maps to that value.

Example with mixed type strategy.

If you want to keep your pypy warning, instead of my "assume not nan", you could decorate with an xfail:

@pytest.mark.xfail(BUGGY_PYPY, reason="pypy mistakes 'nan's as equal when in collections")

Currently, I manually run a script periodically to keep development dependencies up-to-date.

It looks like https://github.com/marketplace/actions/dependencies-autoupdate could be used to automate this.

The old logo is black on a transparent background, and was only designed for use on pages with light backgrounds. The logo is not visible on pages with dark backgrounds, which has become a much more common way for it to be displayed now that GitHub supports dark mode.

• SVG supports embedded CSS in <style> elements. Can @media (prefers-color-scheme: dark) be used in an SVG to make the same image file look good on both light and dark backgrounds? If so, if we switch the logo from PNGs to SVGs that use this trick, will it work everywhere the logo is displayed?
• Instead (or in addition), the logo could use other foreground colors that work well on both light and dark backgrounds. Python blue and yellow? (At that point, does it actually need a snake or two? Perhaps encircling a dictionary in a heart shape, or forming { braces around it } (as @lordmauve once mocked up)? A full redesign is not out of scope here :)