This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author eric.snow
Recipients amaury.forgeotdarc, eric.araujo, eric.snow, rhettinger, vstinner
Date 2012-06-12.03:28:27
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1339471709.73.0.238320200937.issue15003@psf.upfronthosting.co.za>
In-reply-to
Content
> Is this documented in whatsnew?

I'm not sure what has been (none of my patches have done so).

> Also, I remember a discussion about making it public or not, but
> don’t recall a decision.

Amaury brought it up in msg162127.  His point was that the type is public in Python, so why not the C API?  That's about the extent of the discussion.  :)  Do you see any harm in making PyNamespace_New() public?

> I personally find it bad that we have structseqs for most things, dicts
> in PEP 418 get_clock_info return values, and now simplenamespace for
> sys.implementation.

The use cases are different for the different types.  StructSequence/namedtuple provides fixed data structures for structured records.  A dict is essentially the opposite: an un-fixed data structure for dynamic namespaces, making no firm promises as to what the future holds.

SimpleNamespace fills a similar role to dicts, but offers a higher appearance of stability by virtue of using attributes vs. keys.  The problem is that moving from item-access to attribute-access is not a backward-compatible change.  That's the big reason why PEP 421 specified the use of an attr-based object.
History
Date User Action Args
2012-06-12 03:28:29eric.snowsetrecipients: + eric.snow, rhettinger, amaury.forgeotdarc, vstinner, eric.araujo
2012-06-12 03:28:29eric.snowsetmessageid: <1339471709.73.0.238320200937.issue15003@psf.upfronthosting.co.za>
2012-06-12 03:28:29eric.snowlinkissue15003 messages
2012-06-12 03:28:27eric.snowcreate