On Sun, Jun 24, 2018 at 02:33:59PM +1000, Nick Coghlan wrote:
> Given that PEP 572 *is* proposing implicit comprehension state export,
"Implicit" and "explicit" are two terms which often get misused to mean
"I don't like it" and "I do like it".
Making the intentional choice to use an
On 23 June 2018 at 13:48, Steven D'Aprano wrote:
> On Sat, Jun 23, 2018 at 12:22:33AM +1000, Nick Coghlan wrote:
> [...]
>> plenty of
>> functional-language-inspired documentation to instead encourage folks
>> to view comprehensions as tightly encapsulated declarative container
>> construction
On 2018-06-22 19:46, Steven D'Aprano wrote:
- the inexplicable (to me) decision to say "for x of array" instead of
"for x in array";
Believe JavaScript has for…in, but as usual in the language it is broken and
they needed a few more tries to get it right. for…of is the latest version
On 23 June 2018 at 09:06, Greg Ewing wrote:
> Nick Coghlan wrote:
>>
>> x:= f():" implies "x" is already defined as a target somewhere else in
>> the current scope, while "if x := f() given x:" potentially introduces
>> "x" as a new local target
>
>
> N. this is just taking a bad idea and
This particular breakage is explicitly listed in PEP 560, see an example
with List and List[int] in
https://www.python.org/dev/peps/pep-0560/#backwards-compatibility-and-impact-on-users-who-don-t-use-typing
In general, isinstance() with typing types should be avoided when possible
(Mark Shannon
On 6/23/2018 5:48 PM, Zachary Ware wrote:
On Sat, Jun 23, 2018 at 2:20 PM, Terry Reedy wrote:
Rechecking now, on Gentoo
test_idle appears and passed on these 3.6 and 3.7 pages
http://buildbot.python.org/all/#/builders/82/builds/414/steps/5/logs/stdio
Neither Firefox nor Edge can find
First, the typing module is still provisional, so there is no strict
backwards compatibility guarantee.
With that out of the way, I can reproduce your problem, and I assume it's
caused by the implementation of PEP 560, which is meant to speed up the
typing module (among other goals).
I'm
Python 3.7 in the status of RC, but I do not see information about the fact that python3.7 is backwards incompatible with python3.5. $ ~ python3.5Python 3.5.2 (default, Nov 23 2017, 16:37:01) [GCC 5.4.0 20160609] on linuxType "help", "copyright", "credits" or "license" for more information.>>>
On Sat, Jun 23, 2018 at 2:20 PM, Terry Reedy wrote:
> Rechecking now, on Gentoo
>
> test_idle appears and passed on these 3.6 and 3.7 pages
> http://buildbot.python.org/all/#/builders/82/builds/414/steps/5/logs/stdio
>
> Neither Firefox nor Edge can find 'test_idle' on these 3.x pages
>
Let's make it so.
On Sat, Jun 23, 2018, 08:53 Terry Reedy wrote:
> On 6/23/2018 4:54 AM, Serhiy Storchaka wrote:
> > 23.06.18 10:27, Jeroen Demeyer пише:
> >> On 2018-06-23 03:50, Steven D'Aprano wrote:
> >>> I think it is more important that builtin methods and Python methods
> >>> behave the
On 6/23/2018 1:09 PM, Zachary Ware wrote:
On Sat, Jun 23, 2018 at 11:31 AM, Terry Reedy wrote:
I have suggested that, and before that, the same for buildbots. The reality
is that tkinter, IDLE, or turtle could be disabled on *nix by regressions
and the official testing would not notice.
I'm
On 23.06.2018 13:52, Paul Moore wrote:
On 22 June 2018 at 23:21, Brett Cannon wrote:
Thanks to a PR from Ammar Askar we now run Python under lcov as part of the
code coverage build. And thanks to codecov.io automatically merging code
coverage reports we get a complete report of our coverage
On Sat, Jun 23, 2018 at 11:31 AM, Terry Reedy wrote:
> I have suggested that, and before that, the same for buildbots. The reality
> is that tkinter, IDLE, or turtle could be disabled on *nix by regressions
> and the official testing would not notice.
I'm looking into enabling the GUI tests on
On 6/22/2018 9:40 PM, Nathaniel Smith wrote:
On Fri, Jun 22, 2018 at 6:16 PM, Terry Reedy wrote:
I discovered the answer to 2. by shift-clicking on a text_x file to see
their coverage report for the file. The colors actually do reflect the test
lines executed. codecov.io excludes gui tests*,
On 6/23/2018 4:54 AM, Serhiy Storchaka wrote:
23.06.18 10:27, Jeroen Demeyer пише:
On 2018-06-23 03:50, Steven D'Aprano wrote:
I think it is more important that builtin methods and Python methods
behave the same.
+1
This inconsistency is the *real* problem here. It's one little extra
On 22 June 2018 at 23:21, Brett Cannon wrote:
> Thanks to a PR from Ammar Askar we now run Python under lcov as part of the
> code coverage build. And thanks to codecov.io automatically merging code
> coverage reports we get a complete report of our coverage (the first results
> of which can now
On 23.06.2018 5:46, Steven D'Aprano wrote:
On Fri, Jun 22, 2018 at 10:59:43AM -0700, Michael Selik wrote:
I've started testing the proposed syntax when I teach. I don't have a
large
sample yet, but most students either dislike it or don't appreciate the
benefits. They state a clear preference
Hi,
On 23 June 2018 at 10:54, Serhiy Storchaka wrote:
> +1 too. But I think the right solution should be opposite: reverting
> issue1350060 changes and making all methods equality be based on the
> identity of __self__.
The arguments in this thread are the kind of discussion I was looking
for
23.06.18 10:27, Jeroen Demeyer пише:
On 2018-06-23 03:50, Steven D'Aprano wrote:
I think it is more important that builtin methods and Python methods
behave the same.
+1
This inconsistency is the *real* problem here. It's one little extra
complication to merging those classes (which was
On 2018-06-23 03:50, Steven D'Aprano wrote:
I think it is more important that builtin methods and Python methods
behave the same.
+1
This inconsistency is the *real* problem here. It's one little extra
complication to merging those classes (which was proposed in PEP 575,
576 and 579).
23.06.18 05:21, Guido van Rossum пише:
A bound method is a fairly complicated object, and for builtin bound
methods, the == comparison has the following definition:
- if the `__self__` objects are not the same object, return False
- otherwise, return True iff it's the same method (i.e. the same
21 matches
Mail list logo
