On 2020-04-16 04:33, Rob Cliffe via Python-Dev wrote:
Here's another revolutionary thought: add a new operator and associated dunder
method (to object?)
whose meaning is *undefined*. Its default implementation would do *nothing*
useful (raise an error? return None?).
E.g. suppose the operato
Here's another revolutionary thought: add a new operator and associated
dunder method (to object?)
whose meaning is *undefined*. Its default implementation would do
*nothing* useful (raise an error? return None?).
E.g. suppose the operator were `..`
Then in a specific class you could implement
Le mer. 15 avr. 2020 à 23:38, Glenn Linderman a écrit :
> Do the child objects truly need to be wrapped, or just accessed?
>
> Thanks for your comments though, they inspired a thought.
>
> The problem with the glom syntax versus the dotted syntax is that the
> minimal syntax is bulky.
>
> obj.abc.
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
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
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:
On 4/14/2020 10:09 PM, Cameron Simpson wrote:
On 14Apr2020 21:25, Guido van Rossum wrote:
On Tue, Apr 14, 2020 at 9:08 PM Raymond Hettinger <
raymond.hettin...@gmail.com> wrote:
[GvR]
> We should not try to import JavaScript's object model into Python.
Yes, I get that. Just want to point-out
On Tue, Apr 14, 2020 at 9:26 PM David Mertz wrote:
>
> I've written AttributeDict a fair number of times. Each time I write it from
> scratch, which is only a few lines. And I only make a silly wore about 50% of
> the time when I do so.
I've also written it a number of times, and never found a
On 14Apr2020 21:25, Guido van Rossum wrote:
On Tue, Apr 14, 2020 at 9:08 PM Raymond Hettinger <
raymond.hettin...@gmail.com> wrote:
[GvR]
> We should not try to import JavaScript's object model into Python.
Yes, I get that. Just want to point-out that working with heavily nested
dictionaries
On 4/14/2020 9:25 PM, Guido van Rossum wrote:
On Tue, Apr 14, 2020 at 9:08 PM Raymond Hettinger
mailto:raymond.hettin...@gmail.com>> wrote:
[GvR]
> We should not try to import JavaScript's object model into Python.
Yes, I get that. Just want to point-out that working with heavily
Raymond Hettinger wrote:
> Yes, I get that. Just want to point-out that working with heavily
nested dictionaries (typical for JSON) is no fun with square brackets and
quotation marks.
I can certainly agree with that sentiment, especially when working with
something like GraphQL that tends to ret
On Tue, Apr 14, 2020 at 9:08 PM Raymond Hettinger <
raymond.hettin...@gmail.com> wrote:
> [GvR]
> > We should not try to import JavaScript's object model into Python.
>
> Yes, I get that. Just want to point-out that working with heavily nested
> dictionaries (typical for JSON) is no fun with squa
I've written AttributeDict a fair number of times. Each time I write it
from scratch, which is only a few lines. And I only make a silly wore about
50% of the time when I do so.
I wonder if a separate type in collections might be a more natural way to
get the desired effect. I do recognize that su
On Wed, Apr 15, 2020 at 2:09 PM Raymond Hettinger
wrote:
>
> [GvR]
> > We should not try to import JavaScript's object model into Python.
>
> Yes, I get that. Just want to point-out that working with heavily nested
> dictionaries (typical for JSON) is no fun with square brackets and quotation
>
Well, as a user of JSON in Python I *would* be surprised by it, since the
actual JSON notation uses dicts, and most Python code I've seen that access
raw JSON data directly uses dict notation. Where you see dot notation is if
the raw JSON dict is verified and converted to a regular object (usually
[GvR]
> We should not try to import JavaScript's object model into Python.
Yes, I get that. Just want to point-out that working with heavily nested
dictionaries (typical for JSON) is no fun with square brackets and quotation
marks.
Raymond
___
Pytho
Guido van Rossum wrote:
> I've seen this pattern a lot at a past employer, and despite the obvious
convenience I've come to see it as an anti-pattern: for people expecting
Python semantics it's quite surprising to read code that writes foo.bar and
then reads back foo['bar'].
Would it be significan
I've seen this pattern a lot at a past employer, and despite the obvious
convenience I've come to see it as an anti-pattern: for people expecting
Python semantics it's quite surprising to read code that writes foo.bar and
then reads back foo['bar']. We should not try to import JavaScript's object
m
32 matches
Mail list logo
