You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First, I think the call should be client.typedef_name(...), not client.typedef_guid(...)`.
Secondly (and please correct me if I'm misunderstanding), the above doesn't seem to do anything. Calling the internal variable _data seems to just return a 1-element dict, with the key as name (if using the correct method) and the value being the name passed - no interaction with the server has taken place:
Rather, the way to ensure actually get the typedef seems to be to call .inflate(), or any valid data attribute other than the one indicated by the method call; i.e., if client.typedef_name(...) was called, a subsequent attempt to access the guid attribute on the result will lead to a server roundtrip - or vice versa. And it is only if this call returns null that you know you've specified a typedef name which doesn't exist:
Finally, it just looks a bit strange to direct users to access the internal attribute _data in the first place - in principle, surely there should be a way to achieve the same ends using some public API (even if not the approach suggested above).
If I'm not missing something here, would you accept a docs patch to clarify this section? Would be happy to extend it to the corresponding "Get [relationshipDefs|structDefs] by [GUID|name]" sections, for consistency, if you like?
The text was updated successfully, but these errors were encountered:
The section of the docs for getting typedefs by name currently reads as follows:
First, I think the call should be
client.typedef_name(...)
, not client.typedef_guid(...)`.Secondly (and please correct me if I'm misunderstanding), the above doesn't seem to do anything. Calling the internal variable
_data
seems to just return a 1-element dict, with the key asname
(if using the correct method) and the value being the name passed - no interaction with the server has taken place:Rather, the way to ensure actually get the typedef seems to be to call
.inflate()
, or any valid data attribute other than the one indicated by the method call; i.e., ifclient.typedef_name(...)
was called, a subsequent attempt to access theguid
attribute on the result will lead to a server roundtrip - or vice versa. And it is only if this call returns null that you know you've specified a typedef name which doesn't exist:Finally, it just looks a bit strange to direct users to access the internal attribute
_data
in the first place - in principle, surely there should be a way to achieve the same ends using some public API (even if not the approach suggested above).If I'm not missing something here, would you accept a docs patch to clarify this section? Would be happy to extend it to the corresponding "Get [relationshipDefs|structDefs] by [GUID|name]" sections, for consistency, if you like?
The text was updated successfully, but these errors were encountered: