On Fri, 11 Aug 2017 08:49 am, Ben Finney wrote:
> The comprehension encourages thinking in sets: an operation that takes a
> collection as input, and emits a different collection, through one
> conceptual operation.
>
> Adding ‘while’ in there encourages thinking not in terms of a single
> set-ba
On Fri, 11 Aug 2017 12:54 pm, Mikhail V wrote:
> but at a first glance, "while" reads as "if" as in english.
In English the two words don't mean the same thing.
That's why
if foo:
...
and
while foo:
...
are different.
--
Steve
“Cheer up,” they said, “things could be worse.”
On Fri, 11 Aug 2017 06:45 am, Cecil Westerhof wrote:
> Correct:
> SyntaxError: invalid syntax
Perhaps you missed the key words in the subject line, that this is PROPOSED NEW
syntax, rather than existing syntax.
--
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and s
>
> What would you expect this syntax to return?
>
> [x + 1 for x in (0, 1, 2, 999, 3, 4) while x < 5]
>
Nice question BTW
I'd suppose two possible outcomes:
a) It will behave exactly the same as if there was "if" instead of "while"
so [1, 2, 3, 4, 5].
b) It will return syntax error, because "whi
Marko Rauhamaa wrote:
Of course, some algorithms can (and, we have learned, do) prefer some
bits over others, but that's inside the implementation black box. I
would think every bit should carry an approximately equal weight.
Ideally that would be true, but you need to consider the performance
Steve D'Aprano wrote:
On Thu, 10 Aug 2017 07:00 pm, Peter Otten wrote:
/* bottom 3 or 4 bits are likely to be 0; rotate y by 4 to avoid
excessive hash collisions for dicts and sets */
which I think agrees with my comment: using the id() itself would put too many
objects in the same b
Python wrote:
Marko Rauhamaa wrote:
id() is actually an ideal return value of __hash__(). The only criterion
is that the returned number should be different if the __eq__() is
False. That is definitely true for id()
nan is a clear, simple, undeniable counterexample to that claim.
It's a cou
Steve D'Aprano writes:
> Every few years, the following syntax comes up for discussion, with
> some people saying it isn't obvious what it would do, and others
> disagreeing and saying that it is obvious. So I thought I'd do an
> informal survey.
>
> What would you expect this syntax to return?
>
Chris Angelico :
> On Fri, Aug 11, 2017 at 7:17 AM, Marko Rauhamaa wrote:
>> That's interesting, but suggests there's something weird (~ suboptimal)
>> going on with CPython's scrambling algorithm. Also, your performance
>> test might yield completely different results on other Python
>> implemen
On Fri, Aug 11, 2017 at 7:17 AM, Marko Rauhamaa wrote:
> That's interesting, but suggests there's something weird (~ suboptimal)
> going on with CPython's scrambling algorithm. Also, your performance
> test might yield completely different results on other Python
> implementations.
>
> Apart from
Chris Angelico :
> I'm aware of this. Doesn't change the fact that the *INITIAL INDEX* is
> based on exactly what I said.
>
> Yaknow?
What you're saying is that CPython heavily prefers the low-order bits to
be unique performance-wise. I don't know why that particular heuristic
bias was chosen.
Peter Otten <__pete...@web.de>:
> Marko Rauhamaa wrote:
>> I see no point in CPython's rotation magic.
>
> Let's see:
>
> $ cat hashperf.py
> class A(object):
> __slots__ = ["_hash"]
>
> def __hash__(self):
> return self._hash
>
> def no_magic():
> a = A()
> a._hash = id(a)
On Fri, Aug 11, 2017 at 6:56 AM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> On Fri, Aug 11, 2017 at 6:03 AM, Marko Rauhamaa wrote:
>>> I see no point in CPython's rotation magic.
>>
>> Have you ever implemented a hashtable? The most common way to pick a
>> bucket for an object is to use modulo
Terry Reedy writes:
> On 8/10/2017 10:28 AM, Steve D'Aprano wrote:
>> Every few years, the following syntax comes up for discussion, with some
>> people
>> saying it isn't obvious what it would do, and others disagreeing and saying
>> that it is obvious. So I thought I'd do an informal survey.
>
Chris Angelico :
> On Fri, Aug 11, 2017 at 6:03 AM, Marko Rauhamaa wrote:
>> I see no point in CPython's rotation magic.
>
> Have you ever implemented a hashtable? The most common way to pick a
> bucket for an object is to use modulo on the number of buckets.
Like I said earlier, CPython takes t
Marko Rauhamaa wrote:
> Peter Otten <__pete...@web.de>:
>
>> Steve D'Aprano wrote:
>>> The C code says:
>>>
/* bottom 3 or 4 bits are likely to be 0; rotate y by 4 to avoid
excessive hash collisions for dicts and sets */
>>>
>>> which I think agrees with my comment: using the id() itsel
On Thu, Aug 10, 2017 at 1:49 PM, Terry Reedy wrote:
> On 8/10/2017 10:28 AM, Steve D'Aprano wrote:
>>
>> Every few years, the following syntax comes up for discussion, with some
>> people
>> saying it isn't obvious what it would do, and others disagreeing and
>> saying
>> that it is obvious. So I
On Fri, Aug 11, 2017 at 6:03 AM, Marko Rauhamaa wrote:
> Peter Otten <__pete...@web.de>:
>
>> Steve D'Aprano wrote:
>>> The C code says:
>>>
/* bottom 3 or 4 bits are likely to be 0; rotate y by 4 to avoid
excessive hash collisions for dicts and sets */
>>>
>>> which I think agrees with my
On 2017-08-10 20:11, Jussi Piitulainen wrote:
MRAB writes:
[snip]
How about these?
[x + y for x in (0, 1, 2, 999, 3, 4) while x < 5 for y in (100, 200)]
[x + y for x in (0, 1, 2, 999, 3, 4) if x < 5 for y in (100, 200)]
Thanks for your comments!
There's a subtlety there.
Initially I wou
Peter Otten <__pete...@web.de>:
> Steve D'Aprano wrote:
>> The C code says:
>>
>>>/* bottom 3 or 4 bits are likely to be 0; rotate y by 4 to avoid
>>>excessive hash collisions for dicts and sets */
>>
>> which I think agrees with my comment: using the id() itself would put
>> too many objects in
On 8/10/2017 10:28 AM, Steve D'Aprano wrote:
Every few years, the following syntax comes up for discussion, with some people
saying it isn't obvious what it would do, and others disagreeing and saying
that it is obvious. So I thought I'd do an informal survey.
What would you expect this syntax t
MRAB writes:
> On 2017-08-10 15:28, Steve D'Aprano wrote:
>> Every few years, the following syntax comes up for discussion, with
>> some people saying it isn't obvious what it would do, and others
>> disagreeing and saying that it is obvious. So I thought I'd do an
>> informal survey.
>>
>> What
Then what about
[x for x in (0, 1, 2, 3, 4, 66, 7, 8, 9, 10)
while x < 10
if x % 2 == 0]
Seems it should be valid and [0, 2, 4].
On Thu, Aug 10, 2017, 14:06 Jussi Piitulainen, <
jussi.piitulai...@helsinki.fi> wrote:
> Steve D'Aprano writes:
>
> > Every few years, the following syntax comes up f
Steve D'Aprano writes:
> Every few years, the following syntax comes up for discussion, with
> some people saying it isn't obvious what it would do, and others
> disagreeing and saying that it is obvious. So I thought I'd do an
> informal survey.
>
> What would you expect this syntax to return?
>
In <598c6d74$0$1588$c3e8da3$54964...@news.astraweb.com> Steve D'Aprano
writes:
> What would you expect this syntax to return?
> [x + 1 for x in (0, 1, 2, 999, 3, 4) while x < 5]
[1, 2, 3]
> For comparison, what would you expect this to return? (Without actually
> trying it, thank you.)
> [x
On 10/08/2017 15:28, Steve D'Aprano wrote:
> Every few years, the following syntax comes up for discussion, with some
> people
> saying it isn't obvious what it would do, and others disagreeing and saying
> that it is obvious. So I thought I'd do an informal survey.
>
> What would you expect this
Steve D'Aprano wrote:
> The C code says:
>
>>/* bottom 3 or 4 bits are likely to be 0; rotate y by 4 to avoid
>>excessive hash collisions for dicts and sets */
>
> which I think agrees with my comment: using the id() itself would put too
> many objects in the same bucket (i.e. too many collision
On 2017-08-10 15:28, Steve D'Aprano wrote:
Every few years, the following syntax comes up for discussion, with some people
saying it isn't obvious what it would do, and others disagreeing and saying
that it is obvious. So I thought I'd do an informal survey.
What would you expect this syntax to
Python :
> Marko Rauhamaa wrote:
> I didn't disagree with any of these statements about __hash__, but only
> your statement about id and __eq__:
>
>> id() is actually an ideal return value of __hash__(). The only
>> criterion is that the returned number should be different if the
>> __eq__() is Fa
On Fri, Aug 11, 2017 at 2:41 AM, Steve D'Aprano
wrote:
> On Fri, 11 Aug 2017 12:58 am, Chris Angelico wrote:
>
>> On Fri, Aug 11, 2017 at 12:45 AM, Steve D'Aprano
>> wrote:
>>
>>> The C code says:
>>>
/* bottom 3 or 4 bits are likely to be 0; rotate y by 4 to avoid
excessive
On Thu, 10 Aug 2017 at 15:28 Steve D'Aprano
wrote:
> Every few years, the following syntax comes up for discussion, with some
> people
> saying it isn't obvious what it would do, and others disagreeing and saying
> that it is obvious. So I thought I'd do an informal survey.
>
> What would you exp
On Fri, 11 Aug 2017 12:58 am, Chris Angelico wrote:
> On Fri, Aug 11, 2017 at 12:45 AM, Steve D'Aprano
> wrote:
>
>> The C code says:
>>
>>> /* bottom 3 or 4 bits are likely to be 0; rotate y by 4 to avoid
>>>excessive hash collisions for dicts and sets */
>>
>> which I think agrees
Marko Rauhamaa wrote:
Python :
Marko Rauhamaa wrote:
Python :
Marko Rauhamaa wrote:
id() is actually an ideal return value of __hash__(). The only criterion
is that the returned number should be different if the __eq__() is
False. That is definitely true for id().
$ python
Python 2.7.13 (
On 08/10/2017 04:28 PM, Steve D'Aprano wrote:
Every few years, the following syntax comes up for discussion, with some people
saying it isn't obvious what it would do, and others disagreeing and saying
that it is obvious. So I thought I'd do an informal survey.
What would you expect this syntax
On Thu, Aug 10, 2017 at 11:42 AM, alister via Python-list
wrote:
> On Thu, 10 Aug 2017 09:38:49 -0400, Larry Martell wrote:
>
>> On Wed, Aug 9, 2017 at 8:33 PM, Cameron Simpson wrote:
>>> On 09Aug2017 10:46, Jon Ribbens wrote:
On 2017-08-09, Cameron Simpson wrote:
>
> On 08Aug
On Thu, 10 Aug 2017 09:38:49 -0400, Larry Martell wrote:
> On Wed, Aug 9, 2017 at 8:33 PM, Cameron Simpson wrote:
>> On 09Aug2017 10:46, Jon Ribbens wrote:
>>>
>>> On 2017-08-09, Cameron Simpson wrote:
On 08Aug2017 17:31, Jon Ribbens wrote:
>
> ... but bear in mind, there hav
On Thu, Aug 10, 2017 at 7:28 AM, Steve D'Aprano
wrote:
> Every few years, the following syntax comes up for discussion, with some
> people
> saying it isn't obvious what it would do, and others disagreeing and saying
> that it is obvious. So I thought I'd do an informal survey.
>
> What would you
Python :
> Marko Rauhamaa wrote:
>> Python :
>>
>>> Marko Rauhamaa wrote:
id() is actually an ideal return value of __hash__(). The only criterion
is that the returned number should be different if the __eq__() is
False. That is definitely true for id().
>>>
>>> $ python
>>> Python
> What would you expect this syntax to return?
>
> [x + 1 for x in (0, 1, 2, 999, 3, 4) while x < 5]
[1, 2, 3]
> For comparison, what would you expect this to return? (Without actually trying
> it, thank you.)
>
> [x + 1 for x in (0, 1, 2, 999, 3, 4) if x < 5]
[1, 2, 3, 4, 5]
> How about these?
On Fri, Aug 11, 2017 at 12:45 AM, Steve D'Aprano
wrote:
> The C code says:
>
>> /* bottom 3 or 4 bits are likely to be 0; rotate y by 4 to avoid
>>excessive hash collisions for dicts and sets */
>
> which I think agrees with my comment: using the id() itself would put too many
> objec
On Thu, 10 Aug 2017 07:00 pm, Peter Otten wrote:
> Steven D'Aprano wrote:
>
>> On Wed, 09 Aug 2017 20:07:48 +0300, Marko Rauhamaa wrote:
>>
>>> Good point! A very good __hash__() implementation is:
>>>
>>> def __hash__(self):
>>> return id(self)
>>>
>>> In fact, I didn't know Pytho
On Thu, Aug 10, 2017 at 8:28 AM, Steve D'Aprano
wrote:
> Every few years, the following syntax comes up for discussion, with some
> people
> saying it isn't obvious what it would do, and others disagreeing and saying
> that it is obvious. So I thought I'd do an informal survey.
>
> What would you
On Fri, Aug 11, 2017 at 12:28 AM, Steve D'Aprano
wrote:
> How about these?
>
> [x + y for x in (0, 1, 2, 999, 3, 4) while x < 5 for y in (100, 200)]
>
> [x + y for x in (0, 1, 2, 999, 3, 4) if x < 5 for y in (100, 200)]
>
I know exactly what the current syntax does, and yet I fell into an
automat
On 08/10/2017 09:28 AM, Steve D'Aprano wrote:
> Every few years, the following syntax comes up for discussion, with some
> people
> saying it isn't obvious what it would do, and others disagreeing and saying
> that it is obvious. So I thought I'd do an informal survey.
>
> What would you expect t
Every few years, the following syntax comes up for discussion, with some people
saying it isn't obvious what it would do, and others disagreeing and saying
that it is obvious. So I thought I'd do an informal survey.
What would you expect this syntax to return?
[x + 1 for x in (0, 1, 2, 999, 3, 4)
Marko Rauhamaa wrote:
Python :
Marko Rauhamaa wrote:
id() is actually an ideal return value of __hash__(). The only criterion
is that the returned number should be different if the __eq__() is
False. That is definitely true for id().
$ python
Python 2.7.13 (default, Jan 19 2017, 14:48:08)
[G
Python :
> Marko Rauhamaa wrote:
>> id() is actually an ideal return value of __hash__(). The only criterion
>> is that the returned number should be different if the __eq__() is
>> False. That is definitely true for id().
>
> $ python
> Python 2.7.13 (default, Jan 19 2017, 14:48:08)
> [GCC 6.3.0
On 8/9/2017 11:48 PM, Nagy László Zsolt wrote:
Hi!
On the official python site, it is possible to download python 3.4.4 here:
https://www.python.org/downloads/release/python-344/
There are binary installation files for Windows. But Python 3.4.4 is two
years old. There is 3.4.7 that was just re
Marko Rauhamaa wrote:
id() is actually an ideal return value of __hash__(). The only criterion
is that the returned number should be different if the __eq__() is
False. That is definitely true for id().
$ python
Python 2.7.13 (default, Jan 19 2017, 14:48:08)
[GCC 6.3.0 20170118] on linux2
Type
On Wed, Aug 9, 2017 at 8:33 PM, Cameron Simpson wrote:
> On 09Aug2017 10:46, Jon Ribbens wrote:
>>
>> On 2017-08-09, Cameron Simpson wrote:
>>>
>>> On 08Aug2017 17:31, Jon Ribbens wrote:
... but bear in mind, there have been ways of doing denial-of-service
attacks with valid-but-
Peter Otten <__pete...@web.de>:
> Steven D'Aprano wrote:
>> On Wed, 09 Aug 2017 20:07:48 +0300, Marko Rauhamaa wrote:
>>
>>> Good point! A very good __hash__() implementation is:
>>>
>>> def __hash__(self):
>>> return id(self)
>>>
>>> In fact, I didn't know Python (kinda) did this by
On Aug 10, 2017 7:15 AM, wrote:
>
>
>
> solutions manual to MODERN OPERATING SYSTEMS 3rd ed A.S.TANENBAUM
>
>
> can you plz provide it for me..
This mailing list is for the Python programming language, not for operating
systems. It is possible that someone else on this list might be able to
help
solutions manual to MODERN OPERATING SYSTEMS 3rd ed A.S.TANENBAUM
can you plz provide it for me..
--
https://mail.python.org/mailman/listinfo/python-list
On 2017-08-10, Cameron Simpson wrote:
> On 09Aug2017 10:46, Jon Ribbens wrote:
>>On 2017-08-09, Cameron Simpson wrote:
>>> On 08Aug2017 17:31, Jon Ribbens wrote:
... but bear in mind, there have been ways of doing denial-of-service
attacks with valid-but-nasty regexps in the past, and I
On 10 August 2017 at 10:47, Hartmut Goebel wrote:
> Hello,
>
> Is there some tool or online-service which can check patches if they
> contain white-space-only changes and all test-wrapping changes?
>
> One of the projects I'm maintaining (pyinstaller) wants to forbid
> changes of theses types. If
On Thu, Aug 10, 2017 at 7:42 PM, Ned Batchelder wrote:
> On 8/10/17 4:47 AM, Hartmut Goebel wrote:
>> Hello,
>>
>> Is there some tool or online-service which can check patches if they
>> contain white-space-only changes and all test-wrapping changes?
>>
>> One of the projects I'm maintaining (pyin
On 8/10/17 4:47 AM, Hartmut Goebel wrote:
> Hello,
>
> Is there some tool or online-service which can check patches if they
> contain white-space-only changes and all test-wrapping changes?
>
> One of the projects I'm maintaining (pyinstaller) wants to forbid
> changes of theses types. If we could
Steven D'Aprano wrote:
> On Wed, 09 Aug 2017 20:07:48 +0300, Marko Rauhamaa wrote:
>
>> Good point! A very good __hash__() implementation is:
>>
>> def __hash__(self):
>> return id(self)
>>
>> In fact, I didn't know Python (kinda) did this by default already. I
>> can't find that in
Hello,
Is there some tool or online-service which can check patches if they
contain white-space-only changes and all test-wrapping changes?
One of the projects I'm maintaining (pyinstaller) wants to forbid
changes of theses types. If we could integrate resp. checks into the
tooling (github), this
On Wed, 09 Aug 2017 20:07:48 +0300, Marko Rauhamaa wrote:
> Good point! A very good __hash__() implementation is:
>
> def __hash__(self):
> return id(self)
>
> In fact, I didn't know Python (kinda) did this by default already. I
> can't find that information in the definition of obje
Nagy László Zsolt writes:
> Problem solved!
Congratulations. And thank you for reporting the succesful resolution :-)
--
\ “It is clear that thought is not free if the profession of |
`\ certain opinions makes it impossible to earn a living.” |
_o__) —Bertrand Russell, _
61 matches
Mail list logo
