On Sun, Jun 28, 2020 at 3:39 AM Steven D'Aprano wrote:
>
> TL;DR
>
> If the `set.add` feature can return a flag stating whether or not the
> element was previously present or not cheaply and atomically, without
> slowing down the single-threaded case with locks, then that's great (as
> I already
TL;DR
If the `set.add` feature can return a flag stating whether or not the
element was previously present or not cheaply and atomically, without
slowing down the single-threaded case with locks, then that's great (as
I already stated...) and this entire subthread about threading is
Reading PEP554 https://www.python.org/dev/peps/pep-0554/#a-disclaimer-about-the-gil seems like at the current implementation of subinterpretters there will be no separate GIL … But I am wondering, why ?Each subinterpreter has it own object management and Garbage Collection … Why subinterpreters
Guido van Rossum wrote:
> In Python 3.10 we will no longer be burdened by the old parser (though 3rd
> party tooling needs to catch up).
> One thing that the PEG parser makes possible in about 20 lines of code is
> something not entirely different from the old print statement. I have a
>
On Sun, 28 Jun 2020 01:41:01 +1000
Steven D'Aprano wrote:
>
> and ECMA-262 section 24.5.2, JSON.stringify, NOTE 4, page 683 states:
>
> "Finite numbers are stringified as if by calling ToString(number). NaN
> and Infinity regardless of sign are represented as the String null."
Ahh... typical
On Sat, Jun 27, 2020 at 6:40 AM Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> Keara Berlin writes:
>
> I wouldn't object to
>
> When writing English, write clearly and understandably. Consider
> your audience -- many readers of your comments in Python sources
>
>
> Given dict.setdefault, a parallel method like set.add_unique, which
> returns the existing element or None, might be the better approach.
>
Although it breaks the convention of these methods returning the item, I'm
not sure returning the element is a good idea.
"set.add_unique(None)" will
On Sat, Jun 27, 2020 at 03:33:55PM +0300, Serhiy Storchaka wrote:
> 27.06.20 11:58, Steven D'Aprano пише:
> >The JSON standard didn't just accidently fail to specify what to do with
> >NANs and INFs. It mandates that they are turned into null. JSON is
> >designed to take your numeric data and
Oh, sorry, I will take a look.
Thanks!
Em sáb., 27 de jun. de 2020 às 12:06, Guido van Rossum
escreveu:
> Please read PEP 505 before rehashing this old idea.
>
> On Sat, Jun 27, 2020 at 06:35 Daniel. wrote:
>
>> When I need to traverse nested dicts, is a common pattern to do
>>
>>
Please read PEP 505 before rehashing this old idea.
On Sat, Jun 27, 2020 at 06:35 Daniel. wrote:
> When I need to traverse nested dicts, is a common pattern to do
>
> somedict.get('foo', {}).get('bar', {})
>
> But there is no such equivalent for arrays, wouldn't be nice if we can
> follow
>
>
On 6/27/20 8:51 AM, Serhiy Storchaka wrote:
> 27.06.20 10:23, Steven D'Aprano пише:
>> On Wed, Jun 17, 2020 at 09:18:00AM +0300, Serhiy Storchaka wrote:
>>> Adding NANs and INFs to JSON will break virtually every software which
>>> reads JSON because many (most?) of existing standard-conforming
When I need to traverse nested dicts, is a common pattern to do
somedict.get('foo', {}).get('bar', {})
But there is no such equivalent for arrays, wouldn't be nice if we can
follow
somedict.get('foo', {}).get('bar', []).get(10) ... ?
What I do in this case is surround with try/except
Dan Sommers writes:
> Perhaps by your standard [it's not EAFP]. The code I wrote[:]
already_there = seen.add(element)
if already_there:
# handle the duplicate case
> performs an operation, and then asks whether or not some condition
> was met, as opposed to asking whether
On Sat, Jun 27, 2020 at 10:06 PM Rob Cliffe wrote:
>
>
>
> On 27/06/2020 05:33, Chris Angelico wrote:
> > On Sat, Jun 27, 2020 at 2:29 PM Steven D'Aprano wrote:
> >> Seriously, I genuinely thought that the existing behaviour was the
> >> opposite and that `add` unconditionally added the element.
27.06.20 10:23, Steven D'Aprano пише:
On Wed, Jun 17, 2020 at 09:18:00AM +0300, Serhiy Storchaka wrote:
Adding NANs and INFs to JSON will break virtually every software which
reads JSON because many (most?) of existing standard-conforming
implementations do not support them.
It won't break
27.06.20 11:58, Steven D'Aprano пише:
The JSON standard didn't just accidently fail to specify what to do with
NANs and INFs. It mandates that they are turned into null. JSON is
designed to take your numeric data and throw values away, and this is a
real problem for people:
Could you please
On Saturday, June 27, 2020, at 03:46 -0500, Chris Angelico wrote:
I grew up with concurrency being a perfectly normal thing. To
me,
EVERYTHING is concurrent. (Back then, it was single-core CPUs,
so
technically most machine code instructions could be assumed to
be
atomic, but at any higher
On Friday, June 26, 2020, at 23:25 -0500, Steven D'Aprano wrote:
On Fri, Jun 26, 2020 at 06:16:05AM -0500, Dan Sommers wrote:
>already_there = seen.add(element)
>if already_there:
># handle the duplicate case
>
>Who thinks like that? *wink*
Anyone who practices EAFP rather
Keara Berlin writes:
> Here is the current line in PEP-8: "When writing English, follow
> Strunk and White." I propose changing this line to "When writing
> English, ensure that your comments are clear and easily
> understandable to other English speakers."
That's the same thing ("clear and
On Wed, Jun 17, 2020 at 05:06:29PM +1000, Chris Angelico wrote:
> > In Javascript:
> >
> > js> typeof(NaN)
> > number
> > js> typeof(Infinity)
> > number
> >
> > Odd as it may seem, NANs and INFs are numbers. And the JSON standard
> > isn't capable of encoding them. The JSON
On Sat, Jun 27, 2020 at 4:59 PM Steve Barnes wrote:
>
> Can I suggest an addition to this discussion that the phrase: "Must adhere to
> python community guidelines" otherwise it is possible to be disrespectful,
> abusive, sexist, etc., while being clean and understandable (and even
> adhering
On Sat, Jun 27, 2020 at 4:54 PM Steven D'Aprano wrote:
>
> On Fri, Jun 26, 2020 at 10:10:22PM +1000, Chris Angelico wrote:
> > On Fri, Jun 26, 2020 at 7:58 PM Steven D'Aprano wrote:
> > > Most importantly, it matches the way people think about the task:
> > >
> > > # Task: look for
On Wed, Jun 17, 2020 at 09:18:00AM +0300, Serhiy Storchaka wrote:
> 17.06.20 08:29, Steven D'Aprano пише:
> >What exactly is getting in the way here? Standards do change. One
> >standard (JSON) is not capable of representing all values from another
> >standard (IEEE-754). Removing NANs and INFs
On Sat, Jun 27, 2020 at 04:57:32PM +1000, Steven D'Aprano wrote:
> I did find one thing... I was removing an unorded sequence by dropping
> the elements into a set then converting back to a list, and documented
> it as "last seen wins" in the case of duplicates.
Sheesh, I was removing
On Sat, Jun 27, 2020 at 06:09:02PM +1200, Greg Ewing wrote:
> On 27/06/20 4:25 pm, Steven D'Aprano wrote:
> >Seriously, I genuinely thought that the existing behaviour was the
> >opposite and that `add` unconditionally added the element. "Last seen
> >wins".
>
> The fact that you haven't noticed
Can I suggest an addition to this discussion that the phrase: "Must adhere to
python community guidelines" otherwise it is possible to be disrespectful,
abusive, sexist, etc., while being clean and understandable (and even adhering
strictly to Strunk & White). It is completely possible to be
On Fri, Jun 26, 2020 at 10:10:22PM +1000, Chris Angelico wrote:
> On Fri, Jun 26, 2020 at 7:58 PM Steven D'Aprano wrote:
> > Most importantly, it matches the way people think about the task:
> >
> > # Task: look for duplicates
> > if element in seen:
> > # it's a duplicate
> >
On 27/06/20 5:30 pm, David Mertz wrote:
My point is that _Elements of Style_ is not a set of rules. It's a nice
book with generally good advice; it's not a style guide in a formal
sense.
Also, does it actually say anything that would forbid or discourage
use of terms such as "chocker" and
On 27/06/20 4:25 pm, Steven D'Aprano wrote:
Seriously, I genuinely thought that the existing behaviour was the
opposite and that `add` unconditionally added the element. "Last seen
wins".
The fact that you haven't noticed until now suggests that
you've never written any code that depends on
On 27/06/20 4:33 pm, Steven D'Aprano wrote:
Take the word out of the sentence, and does the sentence still mean the
same thing? Then the word was needless. That's an objective test.
But in something a fuzzy as natural language, "the same thing"
is not a boolean value. How close in meaning does
30 matches
Mail list logo
