Consider replacing AttrDict with built-in dict

[hukkin]

I can see the thinking for using an AttrDict for options and env: it provides a syntax that looks like JS object attribute access in "mother" markdown-it, and might make porting of JS extensions etc more straightforward.

I feel, however, that for the purpose the AttrDict is used for, i.e. a container of dynamically named data, a simple builtin dict might be the "Python native" equivalent.

The disadvantages of AttrDict that I can see:

• an added class for contributors to familiarize with
• adds confusion by providing two ways to do one thing, e.g. code like this looks buggy

     if "key" in attr_dict:  # This hints at item access...
         attr_dict.key  # ...but then we do attribute access instead.

• When used as input type in public API, requires users to import the class and convert their dict.
• adds the AttrDict implementation code
• the dict interface can accidentally be broken by certain data, consider e.g.

  >>> a = AttrDict({"values": 2})
  >>> a.values()
  Traceback (most recent call last):
    File "<input>", line 1, in <module>
  TypeError: 'int' object is not callable

• attribute access doesn't allow getting freely named data:

  >>> a=AttrDict({"some-data": 4})
  >>> a.some-data
  Traceback (most recent call last):
    File "<input>", line 1, in <module>
  AttributeError: 'AttrDict' object has no attribute 'some'

• is a dreadful concept for type checkers :)

The advantages might be:

• ease of JS extension portability (although IMO, since a copy-paste won't suffice anyways, I feel like the "JS object -> Python dict" conversion could be seen as a necessary standard procedure for a porter)

[welcome]

Thanks for opening your first issue here! Engagement like this is essential for open source projects! 🤗

If you haven't done so already, check out EBP's Code of Conduct. Also, please try to follow the issue template as it helps other community members to contribute more effectively.

If your issue is a feature request, others may react to it, to raise its prominence (see Feature Voting).

Welcome to the EBP community! 🎉

[hukkin]

@chrisjsewell What do you think about this one? If you like the idea, then it would be a good idea to implement this before v1.0.0 I think.

[choldgraf]

I’ll defer to you two to decide, though I think the points you bring up here do make sense. It is always awkward using attribute for value retrieval when you can use keys that are not valid attribute names.