On Sun, Jun 24, 2018 at 4:33 PM, Nick Coghlan wrote:
> On 24 June 2018 at 15:56, Steven D'Aprano wrote:
>> 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 whic
On 24 June 2018 at 15:56, Steven D'Aprano wrote:
> 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 lik
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 assignment
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 syn
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 and
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 wh
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 'test_id
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 wonderin
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.>>> from
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
> http://bui
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 s
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 (th
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 s
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
compli
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 b
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 f
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 wh
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 prop
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).
_
22 matches
Mail list logo
