On Wed, Nov 6, 2019 at 5:32 AM martin_05--- via Python-ideas <
python-ideas@python.org> wrote:
> In other words, these two things would have been equivalent in Python:
>
> a ← 23
>
> a = 23
>
I do not consider these two things conceptually equivalent. In Python the
identifier ('a' in this
On Thu, Oct 24, 2019 at 12:34 AM Richard Musil wrote:
> Can we agree on the reply from Serhiy and close this discussion?
>
> The proposed change does not bring any advantage apart from few saved
> keystrokes and even that is questionable, because it makes the code more
> pron
On Wed, Oct 23, 2019 at 4:33 PM Serhiy Storchaka
wrote:
> 23.10.19 14:00, Steven D'Aprano пише:
> > So please do educate me Serhiy, which one is the One Obvious Way that we
> > should all agree is the right thing to do?
>
> If you need a constant number, the most obvious way is to write it as a
>
On Wed, Oct 23, 2019 at 7:18 AM Steven D'Aprano wrote:
> On Tue, Oct 22, 2019 at 11:39:59AM -0700, Mike Miller wrote:
> >
> > On 2019-10-18 10:23, Ricky Teachey wrote:
> > >but i'm -0 because i am very concerned it will not be obvious to new
> > >learners, without constantly looking it up, whethe
On Tue, Oct 22, 2019 at 12:05 AM Jan Greis wrote:
> On 21/10/2019 21:14, Dominik Vilsmeier wrote:
> > Exactly, so the dict "+" behavior would match the set "|" behavior,
> preserving the keys. But how many users will be concerned about whether the
> keys are going to be preserved? I guess almost
On Fri, Oct 18, 2019 at 3:18 AM Victor Stinner wrote:
> If possible, please try to read the whole PEP before replying. I would
> prefer to avoid knee-jerk reactions :-) The backward compatibility is
> complex topic where things are not black or white: it's more a
> grayscale.
The proposal seems
On Fri, Oct 18, 2019 at 6:39 PM Steven D'Aprano wrote:
> You seem to have come up with a completely unique symbol which has, as
> far as I can tell, never been used before. As far as I can see, neither
> APL nor Perl use it as an operator. I can't see it in Unicode, or as an
> emoticon.
>
What i
On Fri, Oct 18, 2019 at 2:49 PM Chris Angelico wrote:
> On Fri, Oct 18, 2019 at 11:41 PM Richard Musil
> wrote:
> >
> > I know this has been somewhat addressed in PEP, but I simply cannot see,
> how adding another ambiguity to the '+' symbol, can be better,
On Thu, Oct 17, 2019 at 7:35 AM Brandt Bucher
wrote:
> Please let us know what you think – we'd love to hear any *new* feedback
> that hasn't yet been addressed in the PEP or the related discussions it
> links to! We plan on updating the PEP at least once more before review.
I, personally, do n
>
> On Oct 13, 2019, at 22:54, Chris Angelico wrote:
> >
> > Mathematically, what's the difference between '1' and '1+0j' (or
> > '1+0i')?
>
1 is perfectly valid natural number, rational number (equivalent to 1/1),
real number (equivalent to 1.0) and complex number (equivalent to
1.0+0.0i). Every
On Mon, Oct 14, 2019 at 1:34 AM David Mertz wrote:
> This put a certain thumb on the scale since I searched for .append() which
> will automatically only find lists. Or maybe it's a deque. Or something
> else. I don't actually know for sure (but I kinda think the programmers who
> did this would
On Tue, Oct 1, 2019 at 6:48 PM Andrew Barnert wrote:
> Virtual subclassing is key to the way ABCs work. It would be nice if it
> were explained better in the docs, but I suppose usually people don’t need
> to know the details unless they’re actually getting involved in something
> like designing
On Tue, Oct 1, 2019 at 8:48 AM Ben Rudiak-Gould wrote:
> Is it? Subtyping in type theory satisfies some axioms, one of which is
> transitivity. The addition of the ABCs broke transitivity:
>
> >>> issubclass(list, object)
> True
> >>> issubclass(object, collections.abc.Hashable)
>
On Tue, Sep 24, 2019 at 10:26 AM Nutchanon Ninyawee
wrote:
> Talking about `del` and `unaid()` ("un-alias" or `unlink()` in my previous
> mention), I think `del` should keep its ability to let garbage collection
> free the memory.
> if we use the keyword del to "unbind" and "un-alias" that could
On Tue, Sep 24, 2019 at 5:55 AM Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> Richard Musil writes:
>
> > The implementation can be an additional attribute on an identifier
>
> That's not an implementation yet. From the point of view of the
&g
I had an idea for an abstract representation of the feature Nutchanon
described. Let's call it aliasing and let's define it intuitively:
a = 1
b alias a
print(b) -> 1
b = 2
print(a) -> 2
The abstract representation would define a new construct
_aliased_identifier_ (aid in short), which will behave
On Mon, Sep 23, 2019 at 12:21 AM Richard Higginbotham
wrote:
> I really appreciate the time and thought you have put into it (and others
> here as well), and its been educational / fun for me too. One of the
> concerns I have about using timeit is that it puts a lot of focus on the
> exact statem
On Sun, Sep 22, 2019 at 8:25 PM Andrew Barnert wrote:
> One case I think you didn’t test is when the strings are generated in
> already-sorted order. In that case, as opposed to the case where you
> generate in random order and then sort, I think the PyUnicode objects and
> the actual character a
On Sat, Sep 21, 2019 at 1:44 AM Richard Higginbotham
wrote:
> It's written in Python. It used to require containers with 100k or more
> elements to see a speed improvement over some other unnamed methods. These
> days its closer to 50 million with the only other contender being set (hash
> based
>
> On Thu, Sep 19, 2019 at 10:25:20PM -0500, Tim Peters wrote:
> [...]
> > Something I haven't seen mentioned here, but I may have missed it:
> > when timing algorithms with sets and dicts, people often end up merely
> > measuring the bad effects of hardware data cache misses when the
> > containe
On Fri, Sep 20, 2019 at 1:52 AM Andrew Barnert wrote:
> On Sep 19, 2019, at 15:18, Richard Musil wrote:
> >
> > Ok, I misread the original code, the lists were not sorted in the
> previous results (and their should be). So with the correction to have them
> sorted,
>
&
On Thu, Sep 19, 2019 at 11:58 PM Richard Musil wrote:
> I did not verify the results (I hope they are correct), but the timing
> suggest that the set operation is always faster. When however we add the
> set setup to the mix, the build up time, which is O(n + m) becomes more
> sign
On Thu, Sep 19, 2019 at 10:18 PM Richard Higginbotham
wrote:
> I'm sorry I haven't used the mail list before and didn't send my comments
> to the list. Please see my response to Chris for some example times. I'm
> reluctant to use anything less than about a ms for timing purposes. There's
> too m
On Tue, Sep 17, 2019 at 8:19 PM Rupert Spann wrote:
>
> related to: pep-0584, PEP-0218, and ???
>
> The request is that since dictionary keys can not be duplicated / are
> unique that they may behave the same as sets - and have the set operators
> actions and return sets.
>
This is a correct ob
On Fri, Sep 13, 2019 at 7:28 PM Andrew Barnert via Python-ideas <
python-ideas@python.org> wrote:
> First, I’m pretty sure that, contrary to your claims, C++ does not support
> this. C++ doesn’t even support shared memory out of the box. The
> third-party Boost library does provide it—as long as y
On Fri, Sep 13, 2019 at 6:56 PM Rhodri James wrote:
> I repeat, how does this work? If you want atomicity across processes,
> you need some kind of lock at some level.
>
For the atomic operations the lock is on the hardware level (i.e.
implemented in the CPU, across the mem BUS, cache, etc.), f
On Fri, Sep 13, 2019 at 6:27 PM Rhodri James wrote:
> On 13/09/2019 17:07, Vinay Sharma wrote:
> > Please see my second mail in this thread, where I have comprehensively
> explained what I mean by atomic types.
> > It is nothing but multiprocessing.Value, which can have an Atomic
> variant to be
I was thinking more in this direction:
d = dict()
d[action in not None and 'action'] = action
d[minval > 0 and 'minval'] = minval
...
del d[False]
There are few things I do not particularly like about this (assigning to
dict, even when value is discarded later, or necessity of the del
d[False]),
On Tue, Aug 27, 2019 at 8:04 PM Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> Paul Moore writes:
>
> > [S]ubjecting a newcomer to the need to [deal with extra
> > requirements from other participants] right up front isn't exactly
> > fair or helpful.
>
> But avoiding that
On Tue, Aug 27, 2019 at 10:48 AM Antoine Pitrou wrote:
> On Sun, 11 Aug 2019 20:09:41 -0400
> David Shawley
> wrote:
> > On Aug 8, 2019, at 3:55 PM, Chris Angelico wrote:
> >
> > I proposed something similar about a year ago [1]. I really like the
> idea
> > of a protocol for this. Especially
Paul,
thanks for an insightful reflection from "the other side", I really
appreciate it. It feels like we share some understanding after all.
Richard
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-l
I gave it some thought over the weekend and came to the conclusion that I
am not going to go further with it (where "it" means my or anyone else's
idea). The reason is that I totally lost any motivation. I however feel
some more elaborate answer might be due and I will try to give one.
The other d
On Sat, Aug 24, 2019 at 9:25 AM Michael Hooreman
wrote:
> Running __main.py__ as a script works *only* if we use absolute imports.
> And I consider that using absolute imports in a package to itself is a very
> bad practice. So, __main.py__ is not an executable.
>
I probably should clarify my or
On Fri, Aug 23, 2019 at 11:54 PM Michael Hooreman
wrote:
> The issue is with package foobar containing __main__.py file (not with a
> module called as a script, which is your case), and called via python -m
> foobar
>
> See the last paragraph of https://docs.python.org/3/library/__main__.html
> :
Hello Michaël,
in your PEP your wrote:
---
The standard library's ``argparse.ArgumentParser`` uses by default
``sys.argv[0]`` for his ``prog`` property.
It means that when using the ``python -m foobar`` invocation, which calls
under
the hood the ``foobar.__main__`` module, the ``prog`` will be
``
I have originally planned to post the proposal on bpo, but things turned
out unexpectedly (for me), so I am returning here.
I wrote the patch (for the Python part). If anyone is interested it is here:
https://github.com/python/cpython/compare/master...risa2000:json_patch
The patch follows the ori
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 exa
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 confo
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,
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
Christopher, I understood that the risk of producing invalid JSON if custom
type is allowed to serialize into output stream seems to be a major problem for
many. This has been already mentioned in this discussion. However, I thought it
was related to the original idea of "raw output" (for generi
Christopher, let me go through your summary and add some remarks, hopefully for
the benefit of all (who made it so far) in this conversation:
Christopher Barker wrote:
> TL;DR : I propose that python's JSON encoder encode the Decimal type as
> maintaining full precision.
My proposal will be to
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 PR
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
> bar
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 be
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 a
Joao S. O. Bueno wrote:
> yes, just that it should be called dump_as_float and take either a
> class
> or a tuple-of-classes
I saw kind of symmetry with the `parse_float` which only accepted one class for
having only one class on the output as well. Besides there are probably not
many (differen
Joao S. O. Bueno wrote:
> However, as noted, there is no way to customize Python JSON encoder
> to encode an arbitrary decimal number in JSON, even though the standard does
> allow it, and Python supports then via decimal.Decimal.
> Short of a long term solution, like a __json__ protocol, or at le
Alright, when I made the reference to the json.org I made a mistake. Should
have made the reference to the RFC. You are right that the RFC makes it clear
that it is aware of possible interoperability problems and that some "common
ground" should be acceptable for the underlying representation.
There is no "normalized" representation for JSON. If you look at the "standard"
it is pretty simple (json.org). The JSON object is defined solely by its
textual representation (string of characters).
The way how different parsers choose to represent it in the binary form, so
they can process it
JSON objects are specified by their textual representation (json.org). Choosing
some binary representation for them (so they can be processed efficinetly)
which does not preserve their value is the problem of the underlying binary
representation, not of the JSON format per se.
__
On the second though though, what you propose should work right, if:
1) json.dumps will be extended to accept `dump_float` keyword argument, which
would accept a custom class (for example decimal.Decimal, but could the same
one which was specified with `parse_float`).
2) Then the serializer whe
@Dominik, I believe your proposal (if I understand it correctly) will break it
for people, who are already serializing the decimal.Decimal into the string
(for lack of better support).
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscr
Please, let me explain once more what want.
I need a JSON codec (serializer-deserializer), which can preserve its input on
its output. After some thought it seems to be really concerning only the
floats. (The attempt to generalize this should be regarded as secondary - just
suggestion subject t
After some thinking it seems that the float is only case where this "loss of a
precision" happen.
With the current implementation (in the standard module) of how
`JSONEncoder.default`, I believe I can serialize pretty much everything else.
The "composite" types (i.e. the custom types in the sen
The hash was an argument for having the means to preserve the precision (or
representation) of the float (in its textual form) over decode-encode. The
example was just chosen because I had experienced it in my project.
But I never said that I need the underlying binary representation to be bit t
I meant Chris (Angelico), sorry for that :(.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https:
I have not asked for means to serialize invalid JSON objects. Yes, with the
"raw" output, you can create invalid JSON, but it does not mean you have to.
Let's take a look at it from a different POV and focus on the original problem.
Imagine this situation, I have a JSON string with this value:
`
Chris Angelico wrote:
> 2) Should there be a protocol obj.__json__() to return a string
> representation of an object for direct insertion into a JSON file?
> However, this is a much broader topic, and if you want to push for
> that, I would recommend starting a new thread. As Andrew pointed out,
The hash is calculated over the "normalized" JSON output, where "normalized"
basically means stripped of all whitespaces by the "generator". This is as
canonical as it gets. Then the same data are transmitted in "loose" form, i.e.
with some indentation so it is humanly readable. The other party
I am not sure `(str(o),)` is what I want. For a comparison here are three
examples:
```
json:orig = {"val": 0.6441726684570313}
json:pyth = {'val': 0.6441726684570312}
json:seri = {"val": 0.6441726684570312}
dson:orig = {"val": 0.6441726684570313}
dson:pyth = {'val': Decimal('0.6441726684570313')
I appreciate the responses though I feel like I stirred a completely different
topic than I wanted :).
I am aware of the limitations of the float binary representation, and
consequently also the Python handling of that matter, and I am perfectly fine
with it.
This was not the point of my post.
I have found myself in an awkward situation with current (Python 3.7) JSON
module. Basically it boils down to how it handles floats. I had been hit on
this particular case:
In [31]: float(0.6441726684570313)
Out[31]: 0.6441726684570312
but I guess it really does not matter.
What matters is tha
64 matches
Mail list logo
