Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #111116 > unrolled thread
| Started by | Chris Angelico <rosuav@gmail.com> |
|---|---|
| First post | 2016-07-05 19:21 +1000 |
| Last post | 2016-07-05 20:08 -0700 |
| Articles | 5 — 4 participants |
Back to article view | Back to comp.lang.python
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: How well do you know Python? Chris Angelico <rosuav@gmail.com> - 2016-07-05 19:21 +1000
Re: How well do you know Python? Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-07-05 12:51 +0300
Re: How well do you know Python? Steven D'Aprano <steve@pearwood.info> - 2016-07-05 20:46 +1000
Re: How well do you know Python? Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-07-06 09:19 +0300
Re: How well do you know Python? Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-07-05 20:08 -0700
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-07-05 19:21 +1000 |
| Subject | Re: How well do you know Python? |
| Message-ID | <mailman.93.1467710511.2295.python-list@python.org> |
On Tue, Jul 5, 2016 at 6:36 PM, Peter Otten <__peter__@web.de> wrote:
> What will
>
> $ cat foo.py
> import foo
> class A: pass
> print(isinstance(foo.A(), A))
> $ python -c 'import foo'
> ...
> $ python foo.py
> ...
>
> print?
I refuse to play around with isinstance and old-style classes.
Particularly when circular imports are involved. Run this under Python
3 and/or explicitly subclass object, and then I'd consider it. :)
> It looks like
>
> $ python3 -c 'print({1, 2})'
> {1, 2}
> $ python3 -c 'print({2, 1})'
> {1, 2}
>
> will always print the same output. Can you construct a set from two small
> integers where this is not the case? What's the difference?
Given that the display (iteration) order of sets is arbitrary, I'm not
sure what the significance would ever be, but my guess is that the
display order would be the same for any given set, if constructed this
way. But it sounds as if you know of a set that behaves differently.
> What happens if you replace the ints with strings? Why?
Then hash randomization kicks in, and you can run the exact same line
of code multiple times and get different results. It's a coin toss.
rosuav@sikorsky:~$ python3 -c 'print({"1", "2"})'
{'1', '2'}
rosuav@sikorsky:~$ python3 -c 'print({"1", "2"})'
{'1', '2'}
rosuav@sikorsky:~$ python3 -c 'print({"1", "2"})'
{'1', '2'}
rosuav@sikorsky:~$ python3 -c 'print({"1", "2"})'
{'2', '1'}
rosuav@sikorsky:~$ python3 -c 'print({"1", "2"})'
{'2', '1'}
rosuav@sikorsky:~$ python3 -c 'print({"1", "2"})'
{'1', '2'}
rosuav@sikorsky:~$ python3 -c 'print({"1", "2"})'
{'2', '1'}
rosuav@sikorsky:~$ python3 -c 'print({"1", "2"})'
{'1', '2'}
rosuav@sikorsky:~$ python3 -c 'print({"1", "2"})'
{'2', '1'}
rosuav@sikorsky:~$ python3 -c 'print({"1", "2"})'
{'1', '2'}
rosuav@sikorsky:~$ python3 -c 'print({"1", "2"})'
{'1', '2'}
ChrisA
[toc] | [next] | [standalone]
| From | Jussi Piitulainen <jussi.piitulainen@helsinki.fi> |
|---|---|
| Date | 2016-07-05 12:51 +0300 |
| Message-ID | <lf537noe7lg.fsf@ling.helsinki.fi> |
| In reply to | #111116 |
Chris Angelico writes:
> On Tue, Jul 5, 2016 at 6:36 PM, Peter Otten wrote:
>> It looks like
>>
>> $ python3 -c 'print({1, 2})'
>> {1, 2}
>> $ python3 -c 'print({2, 1})'
>> {1, 2}
>>
>> will always print the same output. Can you construct a set from two small
>> integers where this is not the case? What's the difference?
>
> Given that the display (iteration) order of sets is arbitrary, I'm not
> sure what the significance would ever be, but my guess is that the
> display order would be the same for any given set, if constructed this
> way. But it sounds as if you know of a set that behaves differently.
The first thing that came to mind, {-1,-2} and {-2,-1}.
But I haven't a clue. It doesn't happen with -1 and -3, or with another
pair that I tried, and it doesn't seem to be about object identity.
>> What happens if you replace the ints with strings? Why?
>
> Then hash randomization kicks in, and you can run the exact same line
> of code multiple times and get different results. It's a coin toss.
Oh, nice, a new way to generate random bits in shell scripts.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-07-05 20:46 +1000 |
| Message-ID | <577b9008$0$22141$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #111118 |
On Tue, 5 Jul 2016 07:51 pm, Jussi Piitulainen wrote:
> Chris Angelico writes:
>
>> On Tue, Jul 5, 2016 at 6:36 PM, Peter Otten wrote:
>>> It looks like
>>>
>>> $ python3 -c 'print({1, 2})'
>>> {1, 2}
>>> $ python3 -c 'print({2, 1})'
>>> {1, 2}
>>>
>>> will always print the same output. Can you construct a set from two
>>> small integers where this is not the case? What's the difference?
>>
>> Given that the display (iteration) order of sets is arbitrary, I'm not
>> sure what the significance would ever be, but my guess is that the
>> display order would be the same for any given set, if constructed this
>> way. But it sounds as if you know of a set that behaves differently.
>
> The first thing that came to mind, {-1,-2} and {-2,-1}.
>
> But I haven't a clue. It doesn't happen with -1 and -3, or with another
> pair that I tried, and it doesn't seem to be about object identity.
The hash of most small ints is equal to the int itself:
py> for i in range(100):
... assert hash(i) == i
...
py>
With one exception:
py> hash(-2)
-2
py> hash(-1)
-2
That's because in the C implementation of hash, -1 is used to indicate an
error.
>>> What happens if you replace the ints with strings? Why?
>>
>> Then hash randomization kicks in, and you can run the exact same line
>> of code multiple times and get different results. It's a coin toss.
>
> Oh, nice, a new way to generate random bits in shell scripts.
O_o
You're joking, right?
I'll just leave this here...
https://docs.python.org/3.6/library/secrets.html
--
Steven
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.
[toc] | [prev] | [next] | [standalone]
| From | Jussi Piitulainen <jussi.piitulainen@helsinki.fi> |
|---|---|
| Date | 2016-07-06 09:19 +0300 |
| Message-ID | <lf5vb0jwap0.fsf@ling.helsinki.fi> |
| In reply to | #111120 |
Steven D'Aprano writes:
> On Tue, 5 Jul 2016 07:51 pm, Jussi Piitulainen wrote:
>
>> Chris Angelico writes:
>>
>>> On Tue, Jul 5, 2016 at 6:36 PM, Peter Otten wrote:
>>>> It looks like
>>>>
>>>> $ python3 -c 'print({1, 2})'
>>>> {1, 2}
>>>> $ python3 -c 'print({2, 1})'
>>>> {1, 2}
>>>>
>>>> will always print the same output. Can you construct a set from two
>>>> small integers where this is not the case? What's the difference?
>>>
>>> Given that the display (iteration) order of sets is arbitrary, I'm not
>>> sure what the significance would ever be, but my guess is that the
>>> display order would be the same for any given set, if constructed this
>>> way. But it sounds as if you know of a set that behaves differently.
>>
>> The first thing that came to mind, {-1,-2} and {-2,-1}.
>>
>> But I haven't a clue. It doesn't happen with -1 and -3, or with another
>> pair that I tried, and it doesn't seem to be about object identity.
>
> The hash of most small ints is equal to the int itself:
>
> py> for i in range(100):
> ... assert hash(i) == i
> ...
> py>
>
> With one exception:
>
> py> hash(-2)
> -2
> py> hash(-1)
> -2
Thanks. That must be the explanation. I tried object identity but I did
not think of comparing hashes directly.
Amusing that I didn't know this, yet I happened to think of just this
one pair of numbers. Literally the first thing that I thought to try,
and it turns out to be the only thing.
> That's because in the C implementation of hash, -1 is used to indicate
> an error.
>
>>>> What happens if you replace the ints with strings? Why?
>>>
>>> Then hash randomization kicks in, and you can run the exact same
>>> line of code multiple times and get different results. It's a coin
>>> toss.
>>
>> Oh, nice, a new way to generate random bits in shell scripts.
>
> O_o
>
> You're joking, right?
Er, ok, better not escalate this: Of course I am.
> I'll just leave this here...
>
> https://docs.python.org/3.6/library/secrets.html
Ok.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <lawrencedo99@gmail.com> |
|---|---|
| Date | 2016-07-05 20:08 -0700 |
| Message-ID | <1578346e-738a-4ce8-b1c5-63dbdbe9a678@googlegroups.com> |
| In reply to | #111118 |
On Tuesday, July 5, 2016 at 9:51:21 PM UTC+12, Jussi Piitulainen wrote: > > Chris Angelico writes: > >> Then hash randomization kicks in, and you can run the exact same line >> of code multiple times and get different results. It's a coin toss. > > Oh, nice, a new way to generate random bits in shell scripts. Please, don’t do that...
[toc] | [prev] | [standalone]
Back to top | Article view | comp.lang.python
csiph-web