On 01/28/2018 07:45 AM, Eric V. Smith wrote:
On 1/6/2018 5:13 PM, Eric V. Smith wrote:
On 12/10/2017 5:00 PM, Raymond Hettinger wrote:
2) Change the default value for "hash" from "None" to "False". This might take
a little effort because there is
currently an oddity where setting hash=False
On 1/29/2018 3:42 AM, Ethan Furman wrote:
On 01/28/2018 07:45 AM, Eric V. Smith wrote:
On 1/6/2018 5:13 PM, Eric V. Smith wrote:
On 12/10/2017 5:00 PM, Raymond Hettinger wrote:
2) Change the default value for "hash" from "None" to "False". This
might take a little effort because there is
cu
> On Jan 28, 2018, at 11:52 PM, Eric V. Smith wrote:
>
> I think it would be a bad design to have to opt-in to hashability if using
> frozen=True.
I respect that you see it that way, but it doesn't make sense to me. You can
have either one without the other. It seems to me that it is clear
On 01/29/2018 12:57 AM, Eric V. Smith wrote:
On 1/29/2018 3:42 AM, Ethan Furman wrote:
On 01/28/2018 07:45 AM, Eric V. Smith wrote:
I think the hashing logic explained in
https://bugs.python.org/issue32513#msg310830 is correct. It uses hash=None as
the
default, so that frozen=True objects a
Hi,
test_ftplib just failed on my PR, whereas my change couldn't explain
the failure.
I created https://bugs.python.org/issue32706:
"test_check_hostname() of test_ftplib started to fail randomly"
Temporary workaround: restart the failed Travis CI job.
Victor
2018-01-29 0:23 GMT+01:00 Ned Deily
On 1/29/2018 4:01 AM, Raymond Hettinger wrote:
On Jan 28, 2018, at 11:52 PM, Eric V. Smith wrote:
I think it would be a bad design to have to opt-in to hashability if using
frozen=True.
I respect that you see it that way, but it doesn't make sense to me. You can
have either one without t
I was going to argue, but it's not worth it. What you propose is fine.
On Sun, Jan 28, 2018 at 10:03 PM, Nick Coghlan wrote:
> On 29 January 2018 at 14:43, Guido van Rossum wrote:
> > So why can't you just run "make test" if that's faster?
>
> I can (and do), but I also run it the other way if
> * "-j1" would explicitly turn off multiprocessing
Running tests "sequentially" but run them in one subprocess per test
file is interesting for tests isolation. Runing tests one by one
reduces the risk of triggering a race condition (test only failing
when the system load is high).
-jN was alway
I don't think we're going to reach full agreement here, so I'm going to put
my weight behind Eric's rules.
I think the benefit of the complicated rules is that they almost always do
what you want, so you almost never have to think about it. If it doesn't do
what you want, setting hash=False or has
Dear Python developers,
PEP 8 says:
"Always use self for the first argument to instance methods.
Always use cls for the first argument to class methods.”
But what about metaclasses?
PEP 3115 seems to suggest `cls`, and so do many Python books, however tools
such as flake8 don’t seem to like it
I think it should be `cls` and flake8 etc. should be fixed.
On Mon, Jan 29, 2018 at 11:34 AM, Pim Schellart
wrote:
> Dear Python developers,
>
> PEP 8 says:
>
> "Always use self for the first argument to instance methods.
>
> Always use cls for the first argument to class methods.”
>
> But what
Coincidentally, I changed this in flake8's pep8-naming plugin about a month
ago[1], although the change has not yet made it into a release.
[1]: https://github.com/PyCQA/pep8-naming/pull/47
On Mon, Jan 29, 2018 at 11:53 AM, Guido van Rossum wrote:
> I think it should be `cls` and flake8 etc. sh
Raymond Hettinger wrote:
That list of features is mostly
easy-to-use except for hash=None which has three possible values, only one of
which is self-evident.
Maybe the value of the hash option should be an enum with
three explicitly-named values.
Or maybe there could be a separate "unhashable
Over the last 3 days I have had two situations come up where I was asked
for my opinion in regards to possible CoC violations. I just wanted to take
this opportunity to remind everyone that open source does not work if we
are not open, considerate, and respectful to one another (which also
happens
On 1/29/2018 6:16 PM, Brett Cannon wrote:
Over the last 3 days I have had two situations come up where I was
asked for my opinion in regards to possible CoC violations. I just
wanted to take this opportunity to remind everyone that open source
does not work if we are not open, considerate, and
On 1/28/2018 11:30 PM, Nick Coghlan wrote:
On my current system, "make test" runs in around 3 minutes, while
"./python -m test" runs in around 16 minutes. And that's with "make
test" actually running more tests (since it enables several of the
"-u" options).
Did you test with current 3.7.0a+, s
16 matches
Mail list logo
