On Wed, Apr 15, 2020 at 2:12 AM Serhiy Storchaka wrote:
> Then it obviously should be different class than SimpleNamespace. There
> are too much differences between them, and they are used in different
> circumstances.
+1
Keep in mind that I added SimpleNamespace when implementing PEP 421,
to us
On Wed, Apr 15, 2020 at 2:59 PM Ivan Pozdeev via Python-Dev
wrote:
> "Glom syntax" still excludes the delimiter, whatever it is, from use in keys.
> So it's still a further limitation compared to the JSON spec.
Glom does let you be specific about the exact lookup keys if you want,
to handle keys
On 4/15/2020 2:57 PM, Ivan Pozdeev via Python-Dev wrote:
On 16.04.2020 0:34, Glenn Linderman wrote:
On 4/15/2020 12:47 PM, Ivan Pozdeev via Python-Dev wrote:
When writing a proof-of-concept implementation, however, I bumped
into the need to distinguish which of the child objects are
container
On 16.04.2020 0:34, Glenn Linderman wrote:
On 4/15/2020 12:47 PM, Ivan Pozdeev via Python-Dev wrote:
When writing a proof-of-concept implementation, however, I bumped into the need to distinguish which of the child objects are containers
(thus need to be wrapped as well) and which are the leave
On 4/15/2020 12:47 PM, Ivan Pozdeev via Python-Dev wrote:
When writing a proof-of-concept implementation, however, I bumped into
the need to distinguish which of the child objects are containers
(thus need to be wrapped as well) and which are the leaves (thus need
to be returned as is). I guess
On Wed, Apr 15, 2020 at 7:37 AM Victor Stinner wrote:
> Le mer. 15 avr. 2020 à 05:02, Raymond Hettinger
> a écrit :
> > I would like to make that functionality available to the JSON module (or
> just about anything else that accepts a custom dict) by adding the magic
> methods for mappings so th
On Wed, Apr 15, 2020 at 12:49 PM Ivan Pozdeev via Python-Dev <
python-dev@python.org> wrote:
> First of all, be aware of the limitations of this approach (which will
> need to be clearly documented if we go this way):
>
>- It only allows valid Python identifiers -- while JSON accepts any
>
First of all, be aware of the limitations of this approach (which will need to
be clearly documented if we go this way):
* It only allows valid Python identifiers -- while JSON accepts any sequence
of Unicode characters for keys
(http://www.ecma-international.org/publications/files/ECMA-ST/
A very long time ago, I wrote an XML library (Gnosis Utilities
xml_objectify) that had this same issue, and adopted the "duality" approach
(where possible, with both dictionary and other styles also available).
JSON is sort of the new XML, and it feels like the same concern. FWIW,
LXML explicitly
I will also say that when I do want such a shift from JSON or dict data
structures to a more concrete one I write my own classmethod to provide some
error checking, so I haven't personally needed a package to do this for me.
___
Python-Dev mailing list
On Wed, 15 Apr 2020 at 15:41, Brett Cannon wrote:
>
> The "hey I'm a dict, but look over hear and now you can treat my like like
> any other object" duality doesn't sit well with me. I do understand the idea
> of wanting to convert something to convert JSON data into a more object-like
> access
The "hey I'm a dict, but look over hear and now you can treat my like like any
other object" duality doesn't sit well with me. I do understand the idea of
wanting to convert something to convert JSON data into a more object-like
access pattern, though.
So if something were to be brought in, for
Le mer. 15 avr. 2020 à 05:02, Raymond Hettinger
a écrit :
> I would like to make that functionality available to the JSON module (or just
> about anything else that accepts a custom dict) by adding the magic methods
> for mappings so that this works:
>
> catalog = json.load(f, object_hook=S
It seems a little odd to be dictating website updates about other VMs in this
PEP. I'm not arguing that we shouldn't update the site, I just think requiring
it as part of this PEP seems tangential to what the PEP is focusing on.
___
Python-Dev mailing l
Barry Scott wrote:
> > On 12 Apr 2020, at 21:49, Eric V. Smith e...@trueblade.com wrote:
> > On 4/12/2020 4:08 PM, Barry Scott wrote:
> > On 11 Apr
> > 2020, at 16:28, Barry Scott > mailto:ba...@barrys-emacs.org> wrote:
> > modulefinder.py does not open source files in "rb" which
> > prevents comp
On 14Apr2020 23:08, Glenn Linderman wrote:
On 4/14/2020 10:09 PM, Cameron Simpson wrote:
Like many others, I recently implemented one of these
__getattr__+__getitem__ SimpleNamespaces. I'm hacking on some
mappings which map dotted-names to values. So the natural
implementation is dicts or d
> On 15 Apr 2020, at 03:39, Victor Stinner wrote:
>
> Hi Ronald,
>
> Le mar. 14 avr. 2020 à 18:25, Ronald Oussoren a
> écrit :
>> Making “PyObject” opaque will also affect the stable ABI because even types
>> defined using the PyTypeSpec API embed a “PyObject” value in the structure
>> def
15.04.20 10:06, Raymond Hettinger пише:
[Serhiy]
As a workaround you can use
object_hook=lambda x: SimpleNamespace(**x)
That doesn't suffice because some valid JSON keys are not valid identifiers.
You still need a way to get past those when they arise:
catalog.books.fiction['Paradise Lost
[Serhiy]
> As a workaround you can use
>
> object_hook=lambda x: SimpleNamespace(**x)
That doesn't suffice because some valid JSON keys are not valid identifiers.
You still need a way to get past those when they arise:
catalog.books.fiction['Paradise Lost'].isbn Also, it still leaves you wit
15.04.20 05:59, Raymond Hettinger пише:
SimpleNamespace() is really good at giving attribute style-access. I would like
to make that functionality available to the JSON module (or just about anything
else that accepts a custom dict) by adding the magic methods for mappings so
that this works:
20 matches
Mail list logo
