On 3/18/19 7:12 PM, Steven D'Aprano wrote:
> On Mon, Mar 18, 2019 at 06:34:48PM -0500, Dan Sommers wrote:
>
>> So how many of you got tired of those three statements and
>> added something like the following function to your private
>> collection of useful functions:
>>
>> def
On Mon, Mar 18, 2019 at 06:34:48PM -0500, Dan Sommers wrote:
> So how many of you got tired of those three statements and
> added something like the following function to your private
> collection of useful functions:
>
> def merged_mappings(mapping, other):
> temp = mapping.copy()
>
On Mon, Mar 18, 2019 at 05:51:08AM -0700, Rémi Lapeyre wrote:
> Maths’ typing is explicit so you don’t need to spend brain cycles to
> determine them.
Surely that depends on how formal you are being?
Maths can vary hugely in formality, even at a professional level. It is
a terrible
On 3/18/19 6:08 PM, Steven D'Aprano wrote:
On Mon, Mar 18, 2019 at 03:12:52PM +0100, Antoine Pitrou wrote:
(also, don't forget you can still use the copy() + update() method)
If we had fluent method calls, we could write:
process(mapping.copy().update(other))
but we don't, so we use a
On Sat, Mar 16, 2019 at 07:13:04PM -0400, Terry Reedy wrote:
> > new = a.copy()
> > new.update(b)
> > # do something with new
>
> In my census of the stdlib, already posted and noted as subject to
> error, this was twice as common as all other non-update-in-place
>
On Mon, Mar 18, 2019 at 04:07:11PM +0100, Jimmy Girardet wrote:
> The syntax {**b,**c} wasn't hard to remember.
[...]
> And easy because at the end it's idiomatic.
It is only idiomatic if moderately experienced Python programmers can
automatically read it and write it without thinking about
On Mon, Mar 18, 2019 at 03:12:52PM +0100, Antoine Pitrou wrote:
> (also, don't forget you can still use the copy() + update() method)
If we had fluent method calls, we could write:
process(mapping.copy().update(other))
but we don't, so we use a pointless temporary variable:
temp =
בתאריך יום ג׳, 19 במרץ 2019, 0:41, מאת Greg Ewing <
greg.ew...@canterbury.ac.nz>:
> Rémi Lapeyre wrote:
>
> > You can make "inferences from the way things are used". But the
> > comparison with maths stops here, you don’t make such inferences because
> your
> > object must be well defined before
On Tue, Mar 19, 2019 at 11:32:56AM +1300, Greg Ewing wrote:
> Tim Delaney wrote:
> >I would argue the opposite - the use of "is" shows a clear knowledge
> >that True and False are each a singleton and the author explicitly
> >intended to use them that way.
>
> I don't think you can infer that.
On Mon, Mar 18, 2019 at 3:42 PM Greg Ewing
wrote:
> Tim Delaney wrote:
> > I would argue the opposite - the use of "is" shows a clear knowledge
> > that True and False are each a singleton and the author explicitly
> > intended to use them that way.
>
> I don't think you can infer that. It could
Tim Delaney wrote:
I would argue the opposite - the use of "is" shows a clear knowledge
that True and False are each a singleton and the author explicitly
intended to use them that way.
I don't think you can infer that. It could equally well be someone who's
*not* familiar with Python truth
Rémi Lapeyre wrote:
You can make "inferences from the way things are used". But the
comparison with maths stops here, you don’t make such inferences because your
object must be well defined before you start using it.
In maths texts it's very common to see things like 'Let y = f(x)...'
where
On Tue, Mar 19, 2019 at 09:58:55AM +1300, Greg Ewing wrote:
> Oleg Broytman wrote:
> > Three-way (tri state) checkbox. You have to distinguish False and
> >None if the possible valuse are None, False and True.
>
> In that case the conventional way to write it would be
>
> if
On Tue, 19 Mar 2019 at 08:42, Greg Ewing
wrote:
> Oleg Broytman wrote:
> >Three-way (tri state) checkbox. You have to distinguish False and
> > None if the possible valuse are None, False and True.
>
> In that case the conventional way to write it would be
>
> if settings[MY_KEY] ==
There are few cases where I would approve of 'if x is True'. However, the
names used in the example suggest it could be one of those rare cases.
Settings of True/False/None (i.e. not set) seem like a reasonable pattern.
In fact, in code like that, merely "truthy" values are probably a bug that
It was a VERY long time ago when True and False were not singletons. I
don't think we should still try to write code based on rules that stopped
applying more than a decade ago.
On Mon, Mar 18, 2019, 5:42 PM Greg Ewing
wrote:
> Oleg Broytman wrote:
> >Three-way (tri state) checkbox. You
Richard Damon wrote:
On 3/18/19 7:27 AM, Greg Ewing wrote:
if settings[MY_KEY]:
...
>
That means something VERY different.
Yes, but there needs to be justification for why the difference
matters and why this particular way is the best way to deal
with it.
Whenever you write 'x
Oleg Broytman wrote:
Three-way (tri state) checkbox. You have to distinguish False and
None if the possible valuse are None, False and True.
In that case the conventional way to write it would be
if settings[MY_KEY] == True:
...
It's not a major issue, but I get nervous when I
On Tue, Mar 19, 2019 at 7:53 AM Wes Turner wrote:
>
> 'True' is a keyword. (Which is now immutable in Python 3.X?)
>
> >>> True = 1
> File "", line 1
> SyntaxError: can't assign to keyword
In Python 3, the source code token "True" is a keyword literal that
always represents the bool value
'True' is a keyword. (Which is now immutable in Python 3.X?)
>>> True = 1
File "", line 1
SyntaxError: can't assign to keyword
https://docs.python.org/3/reference/datamodel.html#the-standard-type-hierarchy
https://docs.python.org/3/search.html?q=singleton
- "Since None is a singleton,
Seems reasonable to me.
Regards
Antoine.
On Mon, 18 Mar 2019 16:41:34 +0100
"Giampaolo Rodola'"
wrote:
> Hello,
> I've been having these 2 implemented in psutil for a long time. On
> POSIX these are convenience functions using os.kill() + SIGSTOP /
> SIGCONT (the same as CTRL+Z / "fg"). On
Hello,
I've been having these 2 implemented in psutil for a long time. On
POSIX these are convenience functions using os.kill() + SIGSTOP /
SIGCONT (the same as CTRL+Z / "fg"). On Windows they use undocumented
NtSuspendProcess and NtResumeProcess Windows APIs available since XP.
The same approach
On 18/03/2019 15:10, Eric Fahlgren wrote:
On Mon, Mar 18, 2019 at 7:04 AM Rhodri James wrote:
On 18/03/2019 12:19, Richard Damon wrote:
On 3/18/19 7:27 AM, Greg Ewing wrote:
Juancarlo Añez wrote:
if settings[MY_KEY] is True:
...
If I saw code like this, it would take a
Hi,
Please let me share my story of non experienced python programmer.
Last year I wanted to merge three dicts for config stuff.
I found very quickly the answer : a = {**b, **c, **d}
Sadly I was working on python 3.3 and that was nos possible to use this
syntax. I don't remember what I did
On Mon, Mar 18, 2019 at 7:04 AM Rhodri James wrote:
> On 18/03/2019 12:19, Richard Damon wrote:
> > On 3/18/19 7:27 AM, Greg Ewing wrote:
> >> Juancarlo Añez wrote:
> >>
> >>> if settings[MY_KEY] is True:
> >>> ...
> >>
> >> If I saw code like this, it would take a really good
On Mon, 18 Mar 2019 14:06:53 +
Rhodri James wrote:
> On 16/03/2019 12:01, Gustavo Carneiro wrote:
> > Already been said, but might have been forgotten, but the new proposed
> > syntax:
> >
> > new = a + b
> >
> > has to compete with the already existing syntax:
> >
> > new =
On 16/03/2019 12:01, Gustavo Carneiro wrote:
Already been said, but might have been forgotten, but the new proposed
syntax:
new = a + b
has to compete with the already existing syntax:
new = {**a, **b}
That's easy. Whether it's spelt with "+" or "|" or pretty much anything
On 18/03/2019 12:19, Richard Damon wrote:
On 3/18/19 7:27 AM, Greg Ewing wrote:
Juancarlo Añez wrote:
if settings[MY_KEY] is True:
...
If I saw code like this, it would take a really good argument to
convince me that it shouldn't be just
if settings[MY_KEY]:
...
Le 17 mars 2019 à 02:01:51, Greg Ewing
(greg.ew...@canterbury.ac.nz(mailto:greg.ew...@canterbury.ac.nz)) a
écrit:
> Richard Damon wrote:
> > Rémi, I believe, is assuming in their example that by defining the field
> > of mathematics being used, there is at least an implicit definition (if
> > not
On Tue, Mar 19, 2019 at 12:27:04AM +1300, Greg Ewing
wrote:
> Juancarlo A?ez wrote:
>
> >if settings[MY_KEY] is True:
> >...
>
> If I saw code like this, it would take a really good argument to
> convince me that it shouldn't be just
>
> if settings[MY_KEY]:
> ...
On 3/18/19 7:27 AM, Greg Ewing wrote:
> Juancarlo Añez wrote:
>
>> if settings[MY_KEY] is True:
>> ...
>
> If I saw code like this, it would take a really good argument to
> convince me that it shouldn't be just
>
> if settings[MY_KEY]:
> ...
>
That means something VERY
On 3/18/19 7:32 AM, Chris Angelico wrote:
> On Mon, Mar 18, 2019 at 10:14 PM Juancarlo Añez wrote:
>> It came to my attention that:
>>
>> In the original PEP True and False are said to be singletons
>> https://www.python.org/dev/peps/pep-0285/, but it's not in the Data Model
>>
Juancarlo Añez wrote:
if settings[MY_KEY] is True:
...
If I saw code like this, it would take a really good argument to
convince me that it shouldn't be just
if settings[MY_KEY]:
...
--
Greg
___
Python-ideas mailing list
On Mon, Mar 18, 2019 at 10:14 PM Juancarlo Añez wrote:
>
> It came to my attention that:
>
> In the original PEP True and False are said to be singletons
> https://www.python.org/dev/peps/pep-0285/, but it's not in the Data Model
> https://docs.python.org/3/reference/datamodel.html
>
>
> This
Le 18 mars 2019 à 12:15:05, Juancarlo Añez
(apal...@gmail.com(mailto:apal...@gmail.com)) a écrit:
> It came to my attention that:
>
> > In the original PEP True and False are said to be singletons
> > https://www.python.org/dev/peps/pep-0285/, but it's not in the Data Model
> >
It came to my attention that:
In the original PEP True and False are said to be singletons
https://www.python.org/dev/peps/pep-0285/, but it's not in the Data Model
https://docs.python.org/3/reference/datamodel.html
This came to my attention by code wanting to own the valid values in a
dict's
Stephanie:
Welcome. The "Python idea" here is to allow a broader range of types as
keys to a dictionary. The gap appears to be that certain types (like
set) "don't work" as keys (or rather their identities not values work),
but this is a misunderstanding. A set is mutable: it is as if, in an
37 matches
Mail list logo
