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
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
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
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
___
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
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
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:
catalog = json.load(f,
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
> defining the instance layout. It is easy enough to change this in a
Steve Dower wrote:
> On 14Apr2020 1557, André Malo wrote:
>
> > Stefan Behnel wrote:
> >
> >> André Malo schrieb am 14.04.20 um 13:39:
> >>
> >>> A good way to test that promise (or other implications like
> >>> performance)
> >>> might
> >>>
> > also be to rewrite the standard library
On 14Apr2020 1557, André Malo wrote:
Stefan Behnel wrote:
André Malo schrieb am 14.04.20 um 13:39:
A good way to test that promise (or other implications like performance)
might
also be to rewrite the standard library extensions in Cython and
see where it leads.
Not sure I understand
On 2020-04-14, 12:35 GMT, Stefan Behnel wrote:
>> A good way to test that promise (or other implications like performance)
>> might
>> also be to rewrite the standard library extensions in Cython and see where
>> it
>> leads.
>
> Not sure I understand what you're saying here. stdlib extension
On 2020-04-13, 17:39 GMT, Eric Fahlgren wrote:
> Ok, so put that in a Pros/Cons list that provides guidance as to what
> interface and tools to choose when writing a new extension module.
> Personally, I'd put Cython (and other "big" packages, numpy, requests and
> such) on par with CPython itself
> On 10 Apr 2020, at 19:20, Victor Stinner wrote:
>
[…]
>
>
> PEP xxx: Modify the C API to hide implementation details
>
>
> Abstract
>
>
> * Hide implementation
Stefan Behnel wrote:
> André Malo schrieb am 14.04.20 um 13:39:
>
> > I think, it does not serve well as a policy for CPython. Since we're
> > talking
hypotheticals right now, if Cython vanishes tomorrow, we're
> > kind of left empty handed. Such kind of a runtime, if considered part of
> > the
Paul Moore schrieb am 13.04.20 um 14:25:
> On a related but different note, what is the recommended policy
> (assuming it's not to use the C API) for embedding Python, and for
> exposing the embedding app to Python as a C extension? My standard
> example of this is the Vim interface to Python -
André Malo schrieb am 14.04.20 um 13:39:
> I think, it does not serve well as a policy for CPython. Since we're talking
> hypotheticals right now, if Cython vanishes tomorrow, we're kind of left
> empty
> handed. Such kind of a runtime, if considered part of the compatibility
> "promise",
Steve Dower schrieb am 14.04.20 um 00:27:
> On 13Apr2020 2308, André Malo wrote:
>> For one thing, if you open up APIs for Cython, they're open for everybody
>> (Cython being "just" another C extension).
>> More to the point: The ABIs have the same problem as they have now,
>> regardless
>> how
Steve Dower wrote:
> On a policy level, we don't make changes that would break users of the C
> API. Because we can't track everyone who's using it, we have to assume
> that everything is used and any change will cause breakage.
>
> To make sure it's possible to keep developing CPython, we
23 matches
Mail list logo
