In various different ways, also:
https://pypi.org/project/bash/
https://pypi.org/project/python-pipe/
https://pypi.org/project/pypette/
https://pypi.org/project/shell/
Just a few I've seen before. Xonsh is pretty cool also.
On Sat, Aug 10, 2019, 9:55 PM Christopher Barker
wrote:
> On Sat,
I guess we can wait for your patch, but I have no idea, having read through
this whole thread, exactly what you are actually proposing. I suggest teh
first step would be to lay that out and see what the core devs think.
In the meantime, I hope it will be helpful for me to summarize what I got
out
On Sat, Aug 10, 2019 at 6:53 AM David Mertz wrote:
> Something very similar to this had been done many times in third party
> libraries.
>
Check out Xonch for example:
https://xon.sh/
-CHB
> None of those have become hugely popular, including none quite compelling
> me personally to do
Ok, thanks for the tip. I guess I will post it on bpo once I will be back at
the keyboard (in one week), so I could reply to the question and comments in
timely manner. I had a quick look at JSONEncoder and it seems that a patch of
the Python code will be sufficient, so I will probably post a
On 8/10/2019 11:30 AM, Eric V. Smith wrote:
On 8/10/2019 10:59 AM, Richard Musil wrote:
Paul Moore wrote:
So IMO, the next step is probably an issue on bpo, combined with a PR
implementing the proposed behaviour. I don't think this is big enough
to need a PEP, and I don't think any more
On 8/10/2019 10:59 AM, Richard Musil wrote:
Paul Moore wrote:
So IMO, the next step is probably an issue on bpo, combined with a PR
implementing the proposed behaviour. I don't think this is big enough
to need a PEP, and I don't think any more debate is really needed
here. Someone motivated
Paul Moore wrote:
> So IMO, the next step is probably an issue on bpo, combined with a PR
> implementing the proposed behaviour. I don't think this is big enough
> to need a PEP, and I don't think any more debate is really needed
> here. Someone motivated and able to do the work is really what's
Andrew Barnert wrote:
> But float _already_ preserves the exact precision and value for the example
> you
> gave. The two strings are different string representations of the exact same
> float value,
> and will therefore give the exact same mathematical results with the exact
> same error
>
Something very similar to this had been done many times in third party
libraries. None of those have become hugely popular, including none quite
compelling me personally to do more than try them out as toys.
It's too bad, in a way, since I love bash and use it all the time when it
seems easier
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 verbose than Bash & friends for doing common
shell scripting tasks such as writing pipelines and redirection .
I propose adding an
Andrew Barnert wrote:
I don’t see why 00.12 vs. 0.12 is a problem ... while 0.12 and 0.012E1 are
not a problem at all.
I don't think either of them are problems. Or to be more precise, I
think that being able to use Decimal objects with JSON would be a
good thing, even though it wouldn't
On Aug 10, 2019, at 01:01, Richard Musil wrote:
>
> Andrew Barnert wrote:
>
>> Except that it doesn’t allow that. Using Decimal doesn’t preserve the
>> difference
>> between 1.E+3 and 1000.0, or between +12 and 12. Not to mention
>
> but it preserves the exact precision and value, i.e.
On Sat, 10 Aug 2019 at 01:17, Greg Ewing wrote:
>
> Paul Moore wrote:
> > So you're proposing a change to the Python
> > language stdlib implementation of that translation. Fine. But you have
> > yet to provide a justification for such a change,
>
> I think it can be justified on the grounds that
Greg Ewing wrote:
> No, that's not the only way. It would be sufficient just to add a
> "use decimal" option to the stdlib json module.
> Since Python's Decimal preserves all the information in the JSON
> representation of a float (including trailing zeroes!), anything
> else you might want can
On Thu, Aug 08, 2019 at 10:28:44AM +0100, Ivan Levkivskyi wrote:
> On Tue, 30 Jul 2019 at 04:00, Steven D'Aprano wrote:
>
> > [...]
> > Should it be aliased in collections if we want people to consider
> > using it instead of namedtuple? I would never go looking in typing for
> >
On Aug 9, 2019, at 19:09, Greg Ewing wrote:
>
> Andrew Barnert wrote:
>> Except that it doesn’t allow that. Using Decimal doesn’t preserve the
>> difference between 1.E+3 and 1000.0, or between +12 and 12.
>
> That's true. But it does preserve everything that's important for
> interpreting
On Aug 9, 2019, at 19:09, Greg Ewing wrote:
>
> Andrew Barnert wrote:
>> No you can’t. Decimal accepts strings that aren’t valid as JSON numbers, like
>> `.3`,
>
> That's not a problem as long as it doesn't serialise them that
> way, which it wouldn't:
Your suggestion was that we could allow
Andrew Barnert wrote:
> Except that it doesn’t allow that. Using Decimal doesn’t preserve the
> difference
> between 1.E+3 and 1000.0, or between +12 and 12. Not to mention
but it preserves the exact precision and value, i.e. not a fraction is lost.
This alone is worthy considering it as
18 matches
Mail list logo
