On Mon, 6 Apr 2020 at 04:14, Stephen J. Turnbull
wrote:
> That's OK for developers on their "own" machines, but I think there
> are still a lot of folks who need approval from corporate (though I
> haven't heard from Paul Moore on that theme in quite a while, maybe
> it's gotten better?)
Howdy :-
As an aside I have a perfect example to back up what Paul is saying below. I
work for a large corporation where developers are permitted to install python
modules on their development machines, (subject to some licence restrictions),
but the proxy settings required to get to PyPi vary from user
Yeah, that's almost exactly the situation I have - although I haven't
been as clever as to write a script, I just manually change the proxy
settings when needed. Plus, we use an NTLM proxy, so you need CNTLM
installed to get to PyPI at all. So not something a casual developer
will have (Python isn'
Hello,
I'm not really sure how suggesting improvements to Python goes and I've found
this mailing list, so I thought I'd email it.
My suggestion is related to the json built in package, and more exactly about
serialising custom classes.
As of now, the process involves using a JSONEncoder class
This thread discusses a __json__ encoder protocol:
"adding support for a "raw output" in JSON serializer"
https://mail.python.org/archives/list/[email protected]/thread/WT6Z6YJDEZXKQ6OQLGAPB3OZ4OHCTPDU/
You actually don't have to subclass JSONEncoder; you can specify a default=
method that
On Mon, Apr 6, 2020 at 8:27 AM Wes Turner wrote:
> This thread discusses a __json__ encoder protocol:
>
> "adding support for a "raw output" in JSON serializer"
>
> https://mail.python.org/archives/list/[email protected]/thread/WT6Z6YJDEZXKQ6OQLGAPB3OZ4OHCTPDU/
>
and a numbe rof other issu
Addressing your last concern, about __json__ being only class -> JSON, not JSON
-> class, classes implementing __str__ only go class -> str, not str -> class.
Just because we can't fully solve a problem, it doesn't mean we shouldn't
attempt to solve (or provide a more convenient to solve) half o
Sorry, this has been sitting in my drafts for a while, and maybe this
conversation is over. But since I wrote it, I figured I might as well post
it.
On Fri, Apr 3, 2020 at 4:24 AM Paul Sokolovsky wrote:
> > the idea of adding += to the File protocol -- for all file-like
> > objects. I like the c
On Mon, Apr 6, 2020 at 9:18 AM Dan Cojocaru wrote:
> Addressing your last concern, about __json__ being only class -> JSON, not
> JSON -> class, classes implementing __str__ only go class -> str, not str
> -> class. Just because we can't fully solve a problem, it doesn't mean we
> shouldn't attem
On Tue, Apr 7, 2020 at 2:42 AM Christopher Barker wrote:
> This all made me think *why* do I type check strings, and virtually nothing
> else? And it's because in most otehr places, if I want a given type, I can
> just try to make it from teh input:
>
> x = float(x)
> i = int(i)
>
> arr = np.asa
Python object > JSON > object requires type information to be serialized.
Jsonpickle is two-way; with support for numpy, pandas, JS, datetimes,
UUIDs, and IDK about e.g. complex fractions
https://github.com/jsonpickle/jsonpickle
JSONLD can specify type information in a space-efficient way with @
On Apr 6, 2020, at 09:22, Dan Cojocaru wrote:
>
>
> Addressing your last concern, about __json__ being only class -> JSON, not
> JSON -> class, classes implementing __str__ only go class -> str, not str ->
> class.
Sure, but str is inherently one-way. There’s no unambiguous mapping from
hum
I totally agree, but the JSONEncoder/JSONDecoder mechanism already exist. I'm
certainly removing stuff. I'm just proposing adding a simpler way to do one of
the things - serialising. An example use case would be creating a simple class
for something like a REST API and that class having a __json
On Tue, Apr 7, 2020 at 4:48 AM Andrew Barnert via Python-ideas
wrote:
> That’s not true for JSON; the entire point of it is data interchange. You
> expect to be able to dump an object, send it over the wire or store it to a
> file, load it (or even parse it in JS or ObjC or Go or whatever) and g
I don't see why the need for standardisation exists.
Here's another example because I can explain myself best by giving examples:
I have an API. I can write some classes that correspond to JSON inputs my API
expects and define __json__ in them to convey how they are expected to be
serialised. F
On Apr 6, 2020, at 11:54, Dan Cojocaru wrote:
>
>
> I totally agree, but the JSONEncoder/JSONDecoder mechanism already exist. I'm
> certainly removing stuff. I'm just proposing adding a simpler way to do one
> of the things - serialising. An example use case would be creating a simple
> clas
On Mon, Apr 6, 2020 at 9:49 AM Chris Angelico wrote:
> > This all made me think *why* do I type check strings, and virtually
> nothing else? And it's because in most otehr places, if I want a given
> type, I can just try to make it from the input:
> >
> > x = float(x)
> > i = int(i)
> >
> > arr =
On Mon, Apr 6, 2020, 3:37 PM Dan Cojocaru wrote:
> I don't see why the need for standardisation exists.
>
> Here's another example because I can explain myself best by giving
> examples:
>
> I have an API. I can write some classes that correspond to JSON inputs my
> API expects and define __json_
On 7/04/20 4:57 am, Wes Turner wrote:
Python object > JSON > object requires type information to be serialized.
Not necessarily -- Java's json library uses reflection on compile
time type information to deserialise json into an object hierarchy.
You tell it the class corresponding to the top l
Type information (the TBox) can be serialized along with instances or in a
separate schema definition.
https://en.wikipedia.org/wiki/Tbox
On Tue, Apr 7, 2020, 12:17 AM Greg Ewing
wrote:
> On 7/04/20 4:57 am, Wes Turner wrote:
> > Python object > JSON > object requires type information to be
>
20 matches
Mail list logo
