I know this has come up in the past.
Could the consensus have changed regarding bool's inheritance from int?
This is not intuitive (to me), and recently bit me as a bug:
Python 3.9.1 (default, Dec 13 2020, 11:55:53)
[GCC 10.2.0] on linux
Type "help", "copyright", "credits" or "license" for more
I sure hope this never happens! It would break millions of working lines
and kill a common useful pattern.
ntrue = sum(this == that for this, that in items)
-100.
On Mon, Dec 21, 2020, 3:00 AM Paul Bryan wrote:
> I know this has come up in the past.
>
> Could the consensus have changed regardi
Wouldn't that still work if bool's __int__ returns 1?
On Mon, 2020-12-21 at 03:09 -0500, David Mertz wrote:
> I sure hope this never happens! It would break millions of working
> lines and kill a common useful pattern.
>
> ntrue = sum(this == that for this, that in items)
>
> -100.
>
> On Mon,
Hmm, I see ints, floats and decimal.Decimal all produce the same hashes
for integer values, so they also suffer the same fate in sets and
dicts.
On Mon, 2020-12-21 at 03:09 -0500, David Mertz wrote:
> I sure hope this never happens! It would break millions of working
> lines and kill a common usef
On Mon, Dec 21, 2020 at 7:00 PM Paul Bryan wrote:
>
> I know this has come up in the past.
>
> Could the consensus have changed regarding bool's inheritance from int?
>
> This is not intuitive (to me), and recently bit me as a bug:
>
> Python 3.9.1 (default, Dec 13 2020, 11:55:53)
>
> [GCC 10.2.0]
On Mon, Dec 21, 2020 at 7:15 PM Paul Bryan wrote:
>
> Hmm, I see ints, floats and decimal.Decimal all produce the same hashes for
> integer values, so they also suffer the same fate in sets and dicts.
>
Yes, because they compare equal. (The hash is secondary to that.)
Since 1 == 1.0, they must b
Hello,
I posted on python-dev a question regarding builtin vars() vs .__dict__
attribute dichotomy:
https://mail.python.org/archives/list/python-...@python.org/thread/JAFIBBUU5UE7VMX3SFYXQOHNK6TDZBV3/
It could as well be one among the earliest cases of the violation of
"There should be one-- and
Sometimes it is useful to get the number of tasks currently holding the
semaphore. Currently, assuming that every call to acquire is paired with a
call to release in the same task (e.g. the semaphore is only used in
[async] with statements), one can do
INITIAL_VALUE - sem._value
where INITIAL
Surely what you're looking for is some kind of typed hash table? Maybe you
should be suggesting adding a TypedMapping to collections or something like
that? But it seems to be your solution is fine, but maybe could abstract away
the types in the keys in the class dunders?
```
class TypedMapping
On Mon, Dec 21, 2020 at 8:26 AM Paul Bryan wrote:
> Wouldn't that still work if bool's __int__ returns 1?
>
Yes, there are ways you could accomplish the `sum(trues)` pattern other
than making bool a subclass of int. But as Chris points out, the value of
`1 == True == 1.0` is pretty fundamental
> Surely what you're looking for is some kind of typed hash table?
Maybe, maybe not. My impression is that the Typed hash table is a kluge to
get around this one issue.
As others have pointed out, 1 and 1.0 are considered equal, and thus hash
the same — a typed hash table would not consider th
Christopher Barker wrote:
> > Surely what you're looking for is some kind of typed
> > hash table?
> > Maybe, maybe not. My impression is that the Typed hash table is a kluge to
> get around this one issue.
> As others have pointed out, 1 and 1.0 are considered equal, and thus hash
> the same — a
On Mon, Dec 21, 2020 at 5:27 PM Christopher Barker
wrote:
> Surely what you're looking for is some kind of typed hash table?
>
> Maybe, maybe not. My impression is that the Typed hash table is a kluge
> to get around this one issue. As others have pointed out, 1 and 1.0 are
> considered equal, a
I'm interested in knowing when (id(x), x) would be preferable over
(type(x), x).
On Mon, 2020-12-21 at 17:52 +, David Mertz wrote:
> On Mon, Dec 21, 2020 at 5:27 PM Christopher Barker
> wrote:
> > Surely what you're looking for is some kind of typed hash table?
> >
> > Maybe, maybe not. My i
On Mon, Dec 21, 2020 at 5:56 PM Paul Bryan wrote:
> I'm interested in knowing when (id(x), x) would be preferable over
> (type(x), x).
>
Something along these lines:
>>> class Point:
... def __init__(self, x, y):
... self.x = x
... self.y = y
... def __eq__(self, other):
On Tue, Dec 22, 2020 at 5:20 AM David Mertz wrote:
>
> On Mon, Dec 21, 2020 at 5:56 PM Paul Bryan wrote:
>>
>> I'm interested in knowing when (id(x), x) would be preferable over (type(x),
>> x).
>
>
> Something along these lines:
>
> >>> class Point:
> ... def __init__(self, x, y):
> ...
On Mon, Dec 21, 2020 at 9:25 AM Christopher Barker
wrote:
> [Mathew Elman wrote:]
>
>> Surely what you're looking for is some kind of typed hash table?
>
>
> Maybe, maybe not. My impression is that the Typed hash table is a kluge
> to get around this one issue.
>
For what it's worth, functools.
On Mon, Dec 21, 2020 at 6:32 PM Chris Angelico wrote:
> But the real question is: Why do points compare equal based on their
> locations, if you need them to be independently stored in a set?
> Logically, if they are equal, the set either contains that one thing
> or it doesn't.
>
This is a 3 mi
On Tue, Dec 22, 2020 at 5:59 AM David Mertz wrote:
>
> On Mon, Dec 21, 2020 at 6:32 PM Chris Angelico wrote:
>>
>> But the real question is: Why do points compare equal based on their
>> locations, if you need them to be independently stored in a set?
>> Logically, if they are equal, the set eith
Hello,
On Sat, 19 Dec 2020 21:24:40 +0300
Paul Sokolovsky wrote:
> Hello,
>
> On Sat, 19 Dec 2020 03:52:46 +0100
> Marco Sulla wrote:
>
> > Maybe it's a crazy idea, but what if we could decorate a single line
> > of code?
>
[]
>
> Bottom line: this should be doable, and should be doable
Hi Paul
I get a syntax error. The code won't even compile. I don't see how your
code can avoid it. Are you sure your example works?
$ python3.8
Python 3.8.0 (default, Oct 28 2019, 16:14:01)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> @TimeIt
...
On Sun, Dec 20, 2020 at 4:12 PM Cameron Simpson wrote:
> Untested:
> cls_bs = None
>
> def clear_screen():
> if cls_bs is None:
> try:
> import curses
> except ImportError:
> cls_bs=curses.tigetstr('clear')
> print(cl
Jonathan, did you notice:
python3 -m imphook -i mod_stmt_deco -m example_stmt_deco
I suspect mod_stmt_deco is some code that Paul wrote.
Guessing now, you can implement with with an import_hook, and I'm also
guessing that that import hook translates:
@TimeIt
a_statement
into something like:
w
Hi Christopher
I did notice the unusual command line, but didn't think any more of it. I
thought everything I needed to look at was already in the message.
A reference to https://pypi.org/project/importhook/ would have helped me. I
don't see importhook providing a practical implementation of the
On Sun, Dec 20, 2020 at 11:59:36PM -0800, Paul Bryan wrote:
> I've worked around it by storing tuple(type, value) in the set, which
> is fugly. Yes, I need mixed types in the set, and I'm using the set for
> efficient lookup.
An alternative, which may be better or worse but is probably worth
con
On Mon, Dec 21, 2020 at 1:09 PM Jonathan Fine wrote:
> Going back to that, I don't see why something like
> a = Timer(time_consuming_function)()
> shouldn't actually provide the semantics wanted for
> @Timer
> a = time_consuming_function()
>
that was my first thought on this thread -
On 22/12/20 6:24 am, Christopher Barker wrote:
What I think the OP wants, and I happen to agree, is for Booleans to not
only not BE integers in the subclassing sense, but also to not behave as
numbers in the. Duck Typing sense.
However, that ship has sailed. I think it would have been minima
On Mon, Dec 21, 2020 at 3:37 PM Greg Ewing
wrote:
> > However, that ship has sailed. I think it would have been minimally
> > disruptive when True and False were first introduced,
>
> It would have been just as disruptive back then -- that's the
> reason bool was made a subclass of int in the fir
On Tue, Dec 22, 2020 at 11:52 AM Christopher Barker wrote:
>
> On Mon, Dec 21, 2020 at 3:37 PM Greg Ewing
> wrote:
>>
>> > However, that ship has sailed. I think it would have been minimally
>> > disruptive when True and False were first introduced,
>>
>> It would have been just as disruptive ba
On Tue, Dec 22, 2020 at 1:14 AM Chris Angelico wrote:
> > I know why, but I'm not so sure -- no one was using a built in True or
> False as an integer, because they didn't exist.
>
> No, but AIUI people were creating their own globals to do that job.
>
Indeed. The discussion around this was qui
On Sun, Dec 20, 2020 at 8:06 PM Eryk Sun wrote:
> The entire buffer can be scrolled out, like
> the CMD shell's CLS command, or one can just scroll the buffer enough
> to clear the visible window.
>
The Windows console model is a bit different from POSIX terminals. Instead
of having a screen and
On Mon, Dec 21, 2020 at 04:36:21PM +0300, Paul Sokolovsky wrote:
> Hello,
>
> I posted on python-dev a question regarding builtin vars() vs .__dict__
> attribute dichotomy:
> https://mail.python.org/archives/list/python-...@python.org/thread/JAFIBBUU5UE7VMX3SFYXQOHNK6TDZBV3/
>
> It could as well
32 matches
Mail list logo
