| msg162322 - (view) |
Author: Eric Snow (eric.snow) *  |
Date: 2012-06-05 02:53 |
| The type is available as types.SimpleNamespace, and there's no reason to hold PyNamespace_New() back. |
|
|
| msg162325 - (view) |
Author: Raymond Hettinger (rhettinger) * |
Date: 2012-06-05 03:35 |
| SimpleNamespaces also need to be picklable. |
|
|
| msg162330 - (view) |
Author: Eric Snow (eric.snow) * |
Date: 2012-06-05 05:40 |
| Patch to make PyNamespace_New() public. |
|
|
| msg162331 - (view) |
Author: Eric Snow (eric.snow) * |
Date: 2012-06-05 06:14 |
| I'll get a patch up tomorrow to make the type pickleable. |
|
|
| msg162394 - (view) |
Author: Eric Snow (eric.snow) * |
Date: 2012-06-06 06:35 |
| I'll get to a pickle patch as soon as I can. I also need to add a doc addition for PyNamespace_New() to the existing patch. |
|
|
| msg162430 - (view) |
Author: STINNER Victor (vstinner) * |
Date: 2012-06-06 23:27 |
| It would be nice to have a minimum documentation :-) What is the kwds parameter? What are attributes of the object? |
|
|
| msg162451 - (view) |
Author: Eric Snow (eric.snow) * |
Date: 2012-06-07 03:20 |
| Where should the docs go for PyNamespace_New()? I looked at what's in Doc/c-api/concrete.rst (concrete.html#other-objects), and each of them points to its own page. Adding a new page for a single function seems a bit too much. :) Would it be bad to put the doc right at the end of concrete.rst? The attached patch does so. (Also just noticed that PyStructSequence_* is not documented...) |
|
|
| msg162454 - (view) |
Author: Eric Snow (eric.snow) * |
Date: 2012-06-07 03:39 |
| I've opened issue 15022 for making SimpleNamespace picklable. |
|
|
| msg162576 - (view) |
Author: Éric Araujo (eric.araujo) * |
Date: 2012-06-10 01:46 |
| > The type is available as types.SimpleNamespace (sorry for being OT) Is this documented in whatsnew? Also, I remember a discussion about making it public or not, but don’t recall a decision. 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. |
|
|
| msg162661 - (view) |
Author: Eric Snow (eric.snow) * |
Date: 2012-06-12 03:28 |
| > 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 . 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. |
|
|
| msg162675 - (view) |
Author: Éric Araujo (eric.araujo) * |
Date: 2012-06-12 13:31 |
| >> Is this documented in whatsnew? > I'm not sure what has been (none of my patches have done so). Okay; if a committer does not add a note we can open a doc bug to not forget that. >> Also, I remember a discussion about making it public or not, but >> don’t recall a decision. > Amaury brought it up in . His point was that the type is public in Python, so why not the C API? Actually I was talking about making it public at all, i.e. in Python too. > 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. Right; I just don’t see why the clock info needs to be a dict instead of a structseq or simplenamespace, but maybe it’s explained in the PEP and I missed it. Also it seems to me that the only advantage of simplenamespace over structseqs is that it has no order and can’t be unpacked; I don’t find that a very strong argument (I do see its value, e.g. “major, minor, *etc = sys.version_info” makes sense but we really don’t want to assign order to sys.implementation elements), but I guess this ship has sailed when the implementation was approved. |
|
|
| msg163689 - (view) |
Author: Eric Snow (eric.snow) * |
Date: 2012-06-23 22:47 |
| Here's an updated patch to address the use of _PyNamespace_New() in changeset 77414:0011536f2a06. |
|
|
| msg163741 - (view) |
Author: Alyssa Coghlan (ncoghlan) * |
Date: 2012-06-24 07:23 |
| -1. The entire Python API is already accessible from C, so expansions to the public C API need more justification than "it's exposed in Python". If new instances of this type end up being used in performance critical third party C extensions, then we can have a conversation about whether or not it needs to be exposed directly in C. |
|
|
| msg163819 - (view) |
Author: Mark Shannon (Mark.Shannon) * |
Date: 2012-06-24 19:00 |
| -1 for the reasons Nick stated. |
|
|
| msg164547 - (view) |
Author: Éric Araujo (eric.araujo) * |
Date: 2012-07-02 20:51 |
| Suggest closing or marking “remind” and see if people use / request / reimplement SimpleNamespace. |
|
|
| msg182240 - (view) |
Author: Eric Snow (eric.snow) * |
Date: 2013-02-16 21:21 |
| At present, I don't see a need to make the C API public. |
|
|