[Python-ideas] Re: json library: non-standards-compliant by default, and what to do about it.

On Wed, Jun 17, 2020 at 3:47 PM Steven D'Aprano wrote: > > On Wed, Jun 17, 2020 at 10:58:38AM +1000, Chris Angelico wrote: > > On Wed, Jun 17, 2020 at 10:43 AM Steven D'Aprano > > wrote: > > > > > > Please forgive the stupid question, but given that the JSON standard is > > > so obviously broken

[Python-ideas] Re: EVENTFD(2) support

This is my first attempt at a C implementation: https://gist.github.com/doodspav/5d96c09696fa3ef1c89b4d6426ddc338 It stores the `fd` as an atomic int, since I think threads not being able to run in parallel is an implementation detail, and I shouldn't be designing code around it? I'm not sure i

[Python-ideas] "return if "

So yeah, we can "if : return", but why not? Examples: def some_function(a, b): return if a == b # That will return None return a * b print(some_function(2,2)) # None print(some_function(5,2)) # 10 def some_function_2(a, b): return if a > b or a == b return if a == 1 and b == 1 ret

[Python-ideas] Re: EVENTFD(2) support

On 16/06/2020 07.56, [email protected] wrote: > Can we implement eventfd(2) as documented here > ? > > It would only be available on the Linux platform, and one of the benefits > would be the ability to create synchronisation primitives on s

[Python-ideas] Re: "return if "

On Wed, 17 Jun 2020 at 10:44, artem6191 wrote: > > So yeah, we can "if : return", but why not? That's the wrong question. The correct question is "why is this needed, and is the need sufficiently pressing to justify the change to the language?" You're talking about allowing "return EXPR if CONDI

[Python-ideas] Re: the 'z' string escape

Soni L. writes: > Explicit is better than implicit. > > and \z is more explicit than #cont It's not more explicit. Line continuation in a string literal is perfectly explicit and easy to explain *exactly*: "omit the '\' and the following newline from the string being constructed". You could

[Python-ideas] Re: approximate equality operator ("PEP 485 follow-up")

Paul Sokolovsky writes: > But that's exactly my point: the core of the language is already > quite comprehensive, well-defined, and even crowded. Stuffing even > more stuff into it just doesn't scale. Python *arithmetic* is comprehensive, well-defined, even crowded, and adding operators doesn'

[Python-ideas] Re: Doc preview in Github PR

> > It was suspended because of limitation of netlify. I had the same problem with docs previews for pydantic, I solved it by creating a google cloud run script that unpacked a zip file and uploaded it to google cloud storage where the docs could be viewed, the files expire after 6 months to avoi

[Python-ideas] Re: EVENTFD(2) support

> I opened a BPO and created https://github.com/python/cpython/pull/20930 > to implement a low-level interface to glibc's eventfd() function. Perfect. What's the procedure now for getting that PR accepted? ___ Python-ideas mailing list -- python-ideas@py

[Python-ideas] Re: Support infinite temporal types

Yeah, looks like it had support in principle but just went quiet. I'd be ok with just having it as a third-party library, but the real value comes when your data layer supports it directly - psycopg2, ORMs, etc. That's far more likely to happen if it's built-in. Thanks for responding! Cheers, Al

[Python-ideas] Re: json library: non-standards-compliant by default, and what to do about it.

On 17/06/20 5:42 pm, David Mertz wrote: I think the argument 'allow_nan' is poorly spelled. Spelling it 'strict' would have been much better. Maybe 'conformant'. It should be called 'json_me_harder'. -- Greg ___ Python-ideas mailing list -- python-id

[Python-ideas] Re: "return if "

On 17/06/2020 10:42, artem6191 wrote: So yeah, we can "if : return", but why not? Because without a decent reason otherwise, status quo ante wins. When I was writing a lot of Perl, I used the " if ;" form quite a lot to start with. Partly that was the novelty of it, part was that it reads n

[Python-ideas] Re: Support infinite temporal types

1. Dates beyond year aren't a prerequisite for infinite types - I see that as a separate issue. The fact that we can't represent dates between and infinity doesn't make infinity less useful :) 2 & 3. Yeah, string representation is something that needs to be decided on - that's a big pote

[Python-ideas] Re: "return if "

On 6/17/20 5:42 AM, artem6191 wrote: > So yeah, we can "if : return", but why not? > >From Pep 20 (The Zen) There should be one-- and preferably only one --obvious way to do it. We don't add a second way to do something just because we can, there needs to be some clear need that the existing way

[Python-ideas] Re: json library: non-standards-compliant by default, and what to do about it.

You raise valid points - notably about how JSON isn't a great target in general. On 6/17/20 8:42 AM, Serhiy Storchaka wrote: > 1. Initial standard allowed only JSON objects and JSON arrays at the top > level, but Python implementations allowed all. Now the standard has been > changed. This seems

[Python-ideas] Re: the 'z' string escape

On 2020-06-17 7:44 a.m., Stephen J. Turnbull wrote: Soni L. writes: > Explicit is better than implicit. > > and \z is more explicit than #cont It's not more explicit. Line continuation in a string literal is perfectly explicit and easy to explain *exactly*: "omit the '\' and the follow

[Python-ideas] Re: Modularize Python library

Edwin Zimmerman writes: > This is still true.  There are some of us that will scream very > very loud if the std lib disappears from Python installers.  > However, I think there could easily be a way to satisfy both > parties here.  How difficult would it be to release both full and > minimal

[Python-ideas] Re: json library: non-standards-compliant by default, and what to do about it.

Apart from not making it clear that allow_nan=False is about RFC compliance whether than for some other purpose, it also doesn't mean what it says. The argument really means "allow_nan_and_infs." On Wed, Jun 17, 2020, 8:18 AM Greg Ewing wrote: > On 17/06/20 5:42 pm, David Mertz wrote: > > I thin

[Python-ideas] Re: Support infinite temporal types

I've just updated my implementation to support multiplication and division of TIMEDELTA_INF, mimicking the behaviour of timedelta and float("inf"). Cheers, Alex On Wed, Jun 17, 2020 at 8:26 PM Alexander Hill wrote: > 1. Dates beyond year aren't a prerequisite for infinite types - I see > t

[Python-ideas] Re: Support infinite temporal types

On Tue, Jun 16, 2020 at 11:55 PM Serhiy Storchaka wrote: > First we need to solve some problems. > > 1. Parsing dates with more than 4-digit year. Note that many external > implementations do not support such data, so we need a way to restrict > the data range when convert them to string represen

[Python-ideas] Re: the 'z' string escape

On Wed, Jun 17, 2020 at 6:09 AM Soni L. wrote: > This also gives us two ways of doing indented strings (in Lua): > > local ugly = "foo\n\z > bar\n\z > baz" > local nicer = "foo\n\z >\x20 bar\n\z >\x20 baz" > I'm havi

[Python-ideas] Re: the 'z' string escape

On 2020-06-17 12:46 p.m., Christopher Barker wrote: On Wed, Jun 17, 2020 at 6:09 AM Soni L. > wrote: This also gives us two ways of doing indented strings (in Lua): local ugly = "foo\n    \z   bar\n    \z   baz"

[Python-ideas] Re: the 'z' string escape

On Wed, Jun 17, 2020 at 8:58 AM Soni L. wrote: > I'm having a really hard time seeing why that is either more readable, or > easier to type than: > > > nicest = ("foo" > " bar" > " baz" > ) > (my prefered way these days) > > > I think you missed some \n's here. >

[Python-ideas] Re: the 'z' string escape

On 2020-06-17 1:23 p.m., Christopher Barker wrote: less than ideal, yes -- but please post the \z version -- is it any better? I did, look again. ___ Python-ideas mailing list -- [email protected] To unsubscribe send an email to python-idea

[Python-ideas] Re: the 'z' string escape

Soni L. writes: > however, I bring up again the original use-case which has nothing to do > with textwrap.dedent, or nested indentation. > Currently you'd have to write it as: > foo = ( >     "This is the help page for foo, a command " >     "with the following subcommands:\n" >     "

[Python-ideas] Re: Support infinite temporal types

On 18/06/20 3:00 am, Christopher Barker wrote: 3. String representations and parsing for infinity data (positive and negative). yup -- let the bike shedding begin! My bikeshed suggestions: DISTANT_FUTURE and DISTANT_PAST for datetimes MUCH_LATER and MUCH_EARLIER for timedeltas -- Greg

[Python-ideas] Re: the 'z' string escape

On Wed, Jun 17, 2020 at 09:23:04AM -0700, Christopher Barker wrote: > Though now that you mention is, I really dont like the \z idea -- I just > don't see the point. But a simiple way to call (and pre-process detent > would be nice: > > nicest = d"""foo > bar > baz

[Python-ideas] Re: EVENTFD(2) support

> Perfect. What's the procedure now for getting that PR accepted? Next, it will go through a PR review process prior to being included for Python 3.10. Since it's being implemented as a wrapper for an existing OS API, a PR and bpo issue should be adequate (as opposed to major change proposals that