[Python-ideas] Re: hybrid implementation for PyLongObject (performance)

在 19-8-14 0:27, Andrew Barnert via Python-ideas 写道: > On Aug 13, 2019, at 06:45, malincns wrote: >> >> Thanks for your guidance. >> To be honest, it's a challenge for me. >> It would be nice if an experienced person is willing to make this attempt. > > It would be a significant amount of work

[Python-ideas] Re: adding support for a "raw output" in JSON serializer

On 8/13/2019 8:53 PM, Steven D'Aprano wrote: On Tue, Aug 13, 2019 at 06:01:27PM -0400, Eric V. Smith wrote: dataclasses does something similar: it wants to know if something is a typing.ClassVar, but it doesn't want to import typing to find out. Why not? Is importing typing especially

[Python-ideas] Re: adding support for a "raw output" in JSON serializer

On Tue, Aug 13, 2019 at 06:01:27PM -0400, Eric V. Smith wrote: > dataclasses does something similar: it wants to know if something is a > typing.ClassVar, but it doesn't want to import typing to find out. Why not? Is importing typing especially expensive or a bottleneck? Wouldn't it be a

[Python-ideas] Re: adding support for a "raw output" in JSON serializer

On Aug 13, 2019, at 15:01, Eric V. Smith wrote: > >> On 8/13/2019 5:49 PM, Andrew Barnert via Python-ideas wrote: >> But I think the lazy-import-decimal-on-first-dump-with-use_decimal solves >> that, and solves it even better than __json__, even besides the fact that >> it’s a better API than

[Python-ideas] Re: adding support for a "raw output" in JSON serializer

Chris Angelico wrote: That's one of the reasons that a simple solution of "make JSONEncoder respect decimal.Decimal" was rejected - it would require that the json module import decimal, which is extremely costly. I don't follow that -- importing Decimal is a one-time cost, so it's not going to

[Python-ideas] Re: adding support for a "raw output" in JSON serializer

On 8/13/2019 5:49 PM, Andrew Barnert via Python-ideas wrote: But I think the lazy-import-decimal-on-first-dump-with-use_decimal solves that, and solves it even better than __json__, even besides the fact that it’s a better API than exposing “dump raw text into any JSON, and it’s up to you to

[Python-ideas] Re: adding support for a "raw output" in JSON serializer

On Aug 13, 2019, at 11:21, Chris Angelico wrote: > > On Wed, Aug 14, 2019 at 3:12 AM Andrew Barnert via Python-ideas > wrote: >> >>> On Aug 13, 2019, at 01:04, Richard Musil wrote: >>> >>> Concerning the custom separators, and why the implementation supports them, >>> I believe it is not

[Python-ideas] Re: adding support for a "raw output" in JSON serializer

On Wed, Aug 14, 2019 at 3:12 AM Andrew Barnert via Python-ideas wrote: > > On Aug 13, 2019, at 01:04, Richard Musil wrote: > > > > Concerning the custom separators, and why the implementation supports them, > > I believe it is not actually about the separators themselves, but the > >

[Python-ideas] Re: adding support for a "raw output" in JSON serializer

On Aug 13, 2019, at 01:04, Richard Musil wrote: > > Concerning the custom separators, and why the implementation supports them, I > believe it is not actually about the separators themselves, but the > whitespaces around them. When you generate JSON with an indentation, you > probably also

[Python-ideas] Re: hybrid implementation for PyLongObject (performance)

On Aug 13, 2019, at 06:45, malincns wrote: > > Thanks for your guidance. > To be honest, it's a challenge for me. > It would be nice if an experienced person is willing to make this attempt. It would be a significant amount of work just to implement it far enough to benchmark. So again, I

[Python-ideas] Re: adding support for a "raw output" in JSON serializer

On Tue, 13 Aug 2019, 14:46 Paul Moore, wrote: > > 1) One has to recognize the type in the input data, > > How do you recognise the type? For Decimal, you just check if it's an > instance of the stdlib type. How does *your* proposal define which > custom types are valid? > I expect it will be

[Python-ideas] Re: hybrid implementation for PyLongObject (performance)

在 19-8-13 1:27, Andrew Barnert via Python-ideas 写道: > On Aug 11, 2019, at 19:01, malin...@163.com wrote: >> >> The idea is mixing `PyLongObject` with `Python 2's PyIntObject` >> implementation. >> >> For example, on a 64-bit platform, if (an integer >=-9223372036854775808 and >>

[Python-ideas] Re: adding support for a "raw output" in JSON serializer

On Tue, 13 Aug 2019 at 11:40, Richard Musil wrote: > > But my proposal is not more complex. Implementing support for Decimal > requires exactly the same steps as implementing the support for custom type. > > 1) One has to recognize the type in the input data, How do you recognise the type? For

[Python-ideas] Re: adding support for a "raw output" in JSON serializer

But my proposal is not more complex. Implementing support for Decimal requires exactly the same steps as implementing the support for custom type. 1) One has to recognize the type in the input data, 2) Get the JSON representation, possibly by using obj.__str__(). 3) Check the output that it

[Python-ideas] Re: Idiomatic API for shell scripting

(Changed subject, as I don't think a PEP is the right focus for thinking about this problem space) Thiago Padilha wrote: > Python is often used a shell scripting language due to it being more > robust than traditional Unix shells for managing complex programs, but > it is significantly more

[Python-ideas] Re: adding support for a "raw output" in JSON serializer

On Tue, 13 Aug 2019 at 10:29, Richard Musil wrote: > > My goal is, as already mentioned: > > To extend JSON encoder to support custom type to serialize into "JSON real > number" (changed "fractional" to "real" to be aligned to Python source > internal comment). > > This includes support for

[Python-ideas] Re: adding support for a "raw output" in JSON serializer

Christopher Barker wrote: > > Since we agreed that the only type which needs such a > > treatment is JSON > > fractional number, it should not be that hard to check if the custom type > > output is valid. > well, no -- we did not agree to that. Then I misread your statement: "I can't think of,

[Python-ideas] Re: Stdlib module - Draft

Done! Yours, Abdur-Rahmaan Janhangeer pythonmembers.club | github Mauritius On Tue, Aug 13, 2019 at 9:57 AM Christopher Barker wrote: > > > On Thu, Aug 8, 2019 at 1:18 AM Abdur-Rahmaan Janhangeer < > arj.pyt...@gmail.com>

[Python-ideas] Re: adding support for a "raw output" in JSON serializer

Just a short comment, I agree that "parse_float" is an unfortunate name, which also confuses me in retrospect. "parse_real" will be more fitting, especially since the source use this term internally. I am not sure it is enough to justify the change though. Concerning the custom separators, and

[Python-ideas] Re: Disallow all ending statements (continue/break/return) inside of finally

continue inside of finally, a new feature of python. But it crashed the interpreter, Then i submited a bug report and saw there are other cases where it crashes to. I think we shouldnt allow continue/break/return inside of finally as a language standard. https://bugs.python.org/issue37830

[Python-ideas] Disallow all ending statements (continue/break/return) inside of finally

About 2 days ago i was writing a blog post and i thought why dont i use a ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org

[Python-ideas] Re: Stdlib module - Draft

On Thu, Aug 8, 2019 at 1:18 AM Abdur-Rahmaan Janhangeer < arj.pyt...@gmail.com> wrote: > Greetings, > > Here is a draft after the stdlib module discussion > > . > why don't you make a PR add

[Python-ideas] Re: adding support for a "raw output" in JSON serializer

On Mon, Aug 12, 2019 at 8:40 PM Andrew Barnert wrote: > Although normalization can be a problem, there’s a much simpler—and more > common—issue: what to escape, and how to escape it. > Yup -- I realized this after writing that post -- thanks for fleshing it out. This tell me that trying to use