Entrypoint __iter__ implemementation breaks _asdict

importlib_metadata/importlib_metadata/__init__.py

Lines 191 to 200 in 2678a5e

    
               def __iter__(self): 
        
                   """ 
        
                   Supply iter so one may construct dicts of EntryPoints by name. 
        
                   """ 
        
                   msg = ( 
        
                       "Construction of dict of EntryPoints is deprecated in " 
        
                       "favor of EntryPoints." 
        
                   ) 
        
                   warnings.warn(msg, DeprecationWarning) 
        
                   return iter((self.name, self))

#debug from usage of the stdlib copy
(Pdb) v
EntryPoint(name='.git', value='setuptools_scm.git:parse', group='setuptools_scm.parse_scm')
(Pdb) v._asdict()
{'name': '.git', 'value': EntryPoint(name='.git', value='setuptools_scm.git:parse', group='setuptools_scm.parse_scm')}
(Pdb) type(v)
<class 'importlib.metadata.EntryPoint'>
(Pdb) v._fields
('name', 'value', 'group')
(Pdb)

i was most surprised when my namedtuple debug printer turned into a endless recursion

Also bpo-44893.

Add test capturing failure. Ref #337.

Override _asdict. Fixes #337.

Update changelog. Ref #337.

In #338, I've drafted a fix, but before I merge the change, I'm pondering - does this project want to support the requested interface. I agree that it's reasonable to expect a namedtuple subclass to implement all the features of a namedtuple. This subclass, however, explicitly overrides the default expectation that __iter__ returns the values... and it was never the explicit intention that EntryPoint._asdict should work.

I originally made EntryPoint a subclass of a namedtuple as a shorthand to describe an object with three properties. I never intended it to be used as a tuple or namedtuple.

I've only learned in the past couple of years how dangerous it is to use a built-in type because it implements a subset of the features needed. In a formal API such as importlib.metadata exposes, it's important to be explicit about the minimum surface supported by the API... and using built-in types implicitly exposes a good deal of extraneous, sometimes unwanted functionality, violating the "preferably only one" obvious way.

Before embarking on supporting the requested behavior, I think it's worthwhile stepping back to ask - what is this functionality needed for?

Other approaches I'd like to consider:

Drop namedtuple as a base class and instead implement a "simple object with 3 properties" (possibly providing compatibility for behaviors that could be relied upon in the current implementation).
Drop support for non-working or unwanted namedtuple behaviors (through NotImplementedError or AttributeErrors).

Why should this project care about supporting _asdict()?

its a easy way to debug/trace details for namedtuples (where vars won't work)

in my own code i migrated to always use fields/getattr to wokr around the bug

i took note of the issue when it created a endless recursion in a debug helper

its not clear to me what most reasonable way to express a entrypoint would be,
its really unfortunate the iter "convenience" exists in the first place

imho it violates multiple python principles just to provide convenience,

its really unfortunate the iter "convenience" exists in the first place

That I can agree, and that behavior is deprecated and slated for removal.

its a easy way to debug/trace details for namedtuples (where vars won't work)

in my own code i migrated to always use fields/getattr to wokr around the bug

i took note of the issue when it created a endless recursion in a debug helper

Thanks for clarifying. That doesn't strike me as a particularly compelling reason to keep this particular interface and more a reason to get rid of the qwirky __iter__ and excess namedtuple behaviors. If the debug helper is a one-off, a one-off workaround seems appropriate. If the debug helper is built into an ecosystem like pytest or Pycharm or similar, that to me is a much stronger case to find a solution.

In #339, I lay out the implementation I have in mind. Basically, eschew namedtuple and instead store keyword-only attributes on the object. The __iter__ hack is still there and still deprecated.

python3-importlib-metadata: upgrade 4.6.4 -> 4.8.1

Navigation Menu

Repository navigation

Entrypoint iter implemementation breaks _asdict #337

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

	def __iter__(self):
	"""
	Supply iter so one may construct dicts of EntryPoints by name.
	"""
	msg = (
	"Construction of dict of EntryPoints is deprecated in "
	"favor of EntryPoints."
	)
	warnings.warn(msg, DeprecationWarning)
	return iter((self.name, self))

Entrypoint __iter__ implemementation breaks _asdict #337

Description

Activity

jaraco commented on Aug 12, 2021

jaraco commented on Aug 13, 2021

RonnyPfannschmidt commented on Aug 13, 2021

jaraco commented on Aug 13, 2021

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions

Entrypoint iter implemementation breaks _asdict #337