Re: [Python-Dev] We now have C code coverage!

[Brett Cannon]

On Thu, Jun 28, 2018, 21:28 Terry Reedy,  wrote:

> On 6/24/2018 5:03 AM, Ammar Askar wrote:
> >> Is it possible, given that we are not paying for those reports, to
> >> customize the 'exclude_lines' definitions?
> >
> > Do you want to exclude python code or C code?
>
> Python code.
>
> > For Python code, coverage.py also has some comments you can
> > put down to exclude lines:
> > http://coverage.readthedocs.io/en/coverage-4.2/excluding.html
>
> Yes, by default, one can use '# pragma: no cover' and if one uses the
> --branch flag, '# pragma: no branch'.  For more 'advanced exclusion',
> one can use the following, normally in .coveragerc.
> [report]
> exclude_lines = ...
> "This is useful if you have often-used constructs to exclude that can be
> matched with a regex. You can exclude them all at once without littering
> your code with exclusion pragmas."
>
> For IDLE's test suite, I use a customized .coveragerc.  I strongly
> prefer to not abandon that and litter the code with # pragmas.
>
> In order to make sense of the coverage report and have it be truthful,
> one needs to know what options are being used.
> Is the --branch flag set?
> Is .coveragerc or some other configuration file in use?
> If so, what is the content?
> Do we have any control over the use and content of exclusion settings?
>

Everything is either covered by the Travis or codecov configuration files
which are both checked into the cpython repo. (I'm on vacation or else I
would provide links to the files themselves.)



> --
> Terry Jan Reedy
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 3.7.0 is now available! (and so is 3.6.6)

[Eric Snow]

On Wed, Jun 27, 2018 at 7:05 PM Ned Deily  wrote:
> On behalf of the Python development community and the Python 3.7 release
> team, we are pleased to announce the availability of Python 3.7.0.

Thanks, Ned (and everyone), for a great job on this release!  And
thanks to all for yet another great Python version!

-eric
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Summary of Python tracker Issues

[Python tracker]

ACTIVITY SUMMARY (2018-06-22 - 2018-06-29)
Python tracker at https://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open6705 ( +5)
  closed 39046 (+52)
  total  45751 (+57)

Open issues with patches: 2664 


Issues opened (42)
==

#33932: Calling Py_Initialize() twice now triggers a fatal error (Pyth
https://bugs.python.org/issue33932  reopened by vstinner

#33944: Deprecate and remove pth files
https://bugs.python.org/issue33944  opened by barry

#33947: Dataclasses can raise RecursionError in __repr__
https://bugs.python.org/issue33947  opened by eric.smith

#33948: doc truncated lines in PDF
https://bugs.python.org/issue33948  opened by Mikhail_D

#33949: tests: allow to select tests using loadTestsFromName
https://bugs.python.org/issue33949  opened by blueyed

#33953: The DEFAULT_ENTROPY variable used to store the current default
https://bugs.python.org/issue33953  opened by lig

#33954: float.__format__('n') fails with _PyUnicode_CheckConsistency a
https://bugs.python.org/issue33954  opened by vstinner

#33955: Implement PyOS_CheckStack on macOS using pthread_get_stack*_np
https://bugs.python.org/issue33955  opened by ronaldoussoren

#33959: doc Remove time complexity mention from list Glossary entry
https://bugs.python.org/issue33959  opened by adelfino

#33960: IDLE REPL: Strange indentation
https://bugs.python.org/issue33960  opened by mdk

#33961: Inconsistency in exceptions for dataclasses.dataclass document
https://bugs.python.org/issue33961  opened by chriscog

#33962: IDLE: use ttk.spinbox
https://bugs.python.org/issue33962  opened by terry.reedy

#33963: IDLE macosx: add tests.
https://bugs.python.org/issue33963  opened by terry.reedy

#33964: IDLE maxosc.overrideRootMenu: remove unused menudict
https://bugs.python.org/issue33964  opened by terry.reedy

#33965: [Windows WSL] Fatal Python error: _Py_InitializeMainInterprete
https://bugs.python.org/issue33965  opened by vstinner

#33966: test_multiprocessing_spawn.WithProcessesTestPool.test_tracebac
https://bugs.python.org/issue33966  opened by vstinner

#33967: functools.singledispatch: Misleading exception when calling wi
https://bugs.python.org/issue33967  opened by doerwalter

#33968: os.makedirs and empty string
https://bugs.python.org/issue33968  opened by CarlAndersson

#33969: "copytree" refuses to copy to a mount point
https://bugs.python.org/issue33969  opened by james_r_c_stevens

#33971: os.mknod is subject to "umask"
https://bugs.python.org/issue33971  opened by james_r_c_stevens

#33972: AttributeError in email.message.iter_attachments()
https://bugs.python.org/issue33972  opened by skrohlas

#33973: HTTP request-line parsing splits on Unicode whitespace
https://bugs.python.org/issue33973  opened by tburke

#33974: _stringify handles quoted strings incorrectly
https://bugs.python.org/issue33974  opened by gauchj

#33976: Enums don't support nested classes
https://bugs.python.org/issue33976  opened by edwardw

#33977: [Windows] test_compileall fails randomly with PermissionError:
https://bugs.python.org/issue33977  opened by vstinner

#33978: logging.config.dictConfig with file handler leaks resources
https://bugs.python.org/issue33978  opened by maggyero

#33980: SSL Error when uploading package to your own pypi
https://bugs.python.org/issue33980  opened by javidr

#33982: cgi.FieldStorage doesn't parse QUERY_STRING with POST that is 
https://bugs.python.org/issue33982  opened by Daniel Klein

#33983: unify types for lib2to3.pytree.Base.children
https://bugs.python.org/issue33983  opened by jreese

#33984: test_multiprocessing_forkserver leaked [1, 2, 1] memory blocks
https://bugs.python.org/issue33984  opened by vstinner

#33986: asyncio: Typo in documentation: BaseSubprocessTransport -> Sub
https://bugs.python.org/issue33986  opened by kbumsik

#33987: need ttk.Frame inside Toplevel(s)
https://bugs.python.org/issue33987  opened by markroseman

#33988: [EASY] [3.7] test_platform fails when run with -Werror
https://bugs.python.org/issue33988  opened by vstinner

#33989: ms.key_compare is not initialized in all pathes of list_sort_i
https://bugs.python.org/issue33989  opened by johnchen902

#33990: CPPFLAGS during ./configure are not passed-through in sysconfi
https://bugs.python.org/issue33990  opened by ericvw

#33991: lib2to3 should parse f-strings
https://bugs.python.org/issue33991  opened by skreft

#33994: python build egg fails with error while compiling test cases
https://bugs.python.org/issue33994  opened by sabakauser

#33995: test_min_max_version in test_ssl.py fails when Python is built
https://bugs.python.org/issue33995  opened by Alan.Huang

#33996: Crash in gen_send_ex(): _PyErr_GetTopmostException() returns f
https://bugs.python.org/issue33996  opened by vstinner

#33997: multiprocessing Pool hangs in terminate()
https://bugs.python.org/issue33997  opened by Erik Wolf

#33998: random.randra

Re: [Python-Dev] We now have C code coverage!

[Terry Reedy]

On 6/29/2018 9:25 AM, Brett Cannon wrote:

On Thu, Jun 28, 2018, 21:28 Terry Reedy, > wrote:

[question about our coverage bot]

Everything is either covered by the Travis or codecov configuration 
files which are both checked into the cpython repo. (I'm on vacation or 
else I would provide links to the files themselves.)


Ammar Askar privately asked for my coveragerc file so he could 
experiment with the configuration.


--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] We now have C code coverage!

[Ammar Askar]

Oh whoops, sorry about that. I haven't really used mailing lists
before and so I assumed hitting reply in gmail would send it to
python-dev, not just your personal email. Just so the config file
locations are publicly documented, here's what I responded with:

> For IDLE's test suite, I use a customized .coveragerc.  I strongly prefer to 
> not abandon that and litter the code with # pragmas.


Yup, I agree completely. Having pragmas everywhere is really annoying,
its really only useful for small one-off stuff.

> In order to make sense of the coverage report and have it be truthful, one 
> needs to know what options are being used.
> Is the --branch flag set?
> Is .coveragerc or some other configuration file in use?
> If so, what is the content?
> Do we have any control over the use and content of exclusion settings?


To answer all these questions at once, yeah, we have complete control
over all the coverage parameters. Currently we aren't building with
`--branch` and don't have a coveragrc file. We could put one in the
root of CPython (which would get picked up automatically) but
personally I think CI related crud should go into its own folder.
Luckily we do have a ".github" folder, so I'd suggest putting the
coveragerc file in there and then adding the parameter
`--rcfile=.github/coveragerc`

All the parameters to coverage.py can be configured here
https://github.com/python/cpython/blob/master/.travis.yml#L82

If you wanna send over your IDLE coveragerc file, I can experiment and
try to get it working for Travis, or you can explore it yourself if
you want.

On Fri, Jun 29, 2018 at 9:14 AM, Terry Reedy  wrote:
> On 6/29/2018 9:25 AM, Brett Cannon wrote:
>
>> On Thu, Jun 28, 2018, 21:28 Terry Reedy, > > wrote:
>
> [question about our coverage bot]
>
>> Everything is either covered by the Travis or codecov configuration files
>> which are both checked into the cpython repo. (I'm on vacation or else I
>> would provide links to the files themselves.)
>
>
> Ammar Askar privately asked for my coveragerc file so he could experiment
> with the configuration.
>
> --
> Terry Jan Reedy
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/ammar%40ammaraskar.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

[Chris Barker - NOAA Federal via Python-Dev]

> On Jun 28, 2018, at 8:21 PM, Tim Peters  wrote:

Seems it’s all been said, and Tim’s latest response made an excellent
case for consistency.

But:

> Regardless of how assignment expressions work in listcomps and genexps, this 
> example (which uses neither) _will_ rebind the containing block's `x`:
>
> [x := 1]

This reinforces my point that it’s not just about comprehensions, but
rather that the local namespace can be altered anywhere an expression
is used  — which is everywhere.

That trivial example is unsurprising, but as soon as your line of code
gets a bit longer, it could be far more hidden.

I’m not saying it’s not worth it, but it a more significant
complication than simply adding a new feature like augmented
assignment or terniary expressions, where the effect is seen only
where it is used.

A key problem with thinking about this is that we can scan existing
code to find places where this would improve the code, and decide if
those use-cases would cause confusion.

But we really can’t anticipate all the places where it might get used
(perhaps inappropriately) that would cause confusion. We can hope that
people won’t tend to do that, but who knows?

Example: in a function argument:

result = call_a_func(arg1, arg2, kwarg1=x, kwarg2=x:=2*y)

Sure, there are always ways to write bad code, and most people
wouldn’t do that, but someone, somewhere, that thinks shorter code is
better code might well do it. Or something like it.

After all, expressions can be virtually anywhere in your code.

Is this a real risk? Maybe not, but it is a complication.

-CHB
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

[Tim Peters]

[Tim]
>> Regardless of how assignment expressions work in listcomps and genexps,
>> this example (which uses neither) _will_ rebind the containing block's
`x`:

> >>

> >> [x := 1]

>
[Chris Barker]
> This reinforces my point that it’s not just about comprehensions,

I agree, it's not at all - and I'm amazed at the over-the-top passion that
minor issues of scope in comprehensions have ... inspired.  It's the tip of
the tail of the dog.

> but rather that the local namespace can be altered anywhere
> an expression is used  — which is everywhere.

Yes, everywhere.  But what of it?  Have you read the PEP?  The examples are
all simple and straightforward and "local".  My example above was wholly
contrived to make a specific point, and I expect we'll _never_ see that
line in real code.

>

> That trivial example is unsurprising, but as soon as your
> line of code gets a bit longer, it could be far more hidden.

It's not possible to prevent people from writing horrible code, and I'm
hard pressed to think of _any_ programming feature that can't be so
abused.  From
ridiculouslyLongVariableNamesWhoseVerbostiySeemsToBeAGoalInItself. massive
overuse of globals, insanely deep nesting, horridly redundant
parenthesization, functions with 20 undocumented arguments, creating
Byzantine class structures spread over a directory full of modules to
implement a concept that _could_ have been done faster and better with a
list, ...

So on a scale of 1 ("wake me up when it's over") to 100 ("OMG!  It's the
end of the world!!!"), "but it can be horridly abused" rates about a 2 on
my weighting scale.  Do we really think so little of our fellow
Pythoneers?  Key point:  absolutely nobody has expressed a fear that they
_themself_ will abuse assignment expressions.  It's always some seemingly
existential dread that someone else will ;-)


> I’m not saying it’s not worth it, but it a more significant

> > complication than simply adding a new feature like augmented

> > assignment or terniary expressions, where the effect is seen only

> > where it is used.

Which is good to keep in mind when using a feature like this.  Python is an
imperative language, and side effects are rampant.  Controlling them is
important.


> A key problem with thinking about this is that we can scan existing
> code to find places where this would improve the code, and decide if
> those use-cases would cause confusion.

I went through that exercise for the PEP's Appendix A.  I assume you
haven't read it.  I found many places where assignment expressions would
make for a small improvement, and got surprised by concluding it was really
the multitude of tiny, extremely-local improvements that "added up" to the
real win overall, not the much rarer cases where assignment expressions
really shine (such as in collapsing chains of semantically misleading
ever-increasing indentation in long
assign/f/else/assign/if/else/assign/if/else ...structures).  I also gave
examples of places where, despite being "small and local" changes, using
assignment expressions appeared to be a _bad_ idea.


> But we really can’t anticipate all the places where it might get used

> > perhaps inappropriately) that would cause confusion. We can hope that
> people won’t tend to do that, but who knows?

Having spent considerable time on it myself (see just above), I do not
assume that other Pythonistas are incapable of reaching sane conclusions
too ;-)


> Example: in a function argument:

> >

> > result = call_a_func(arg1, arg2, kwarg1=x, kwarg2=x:=2*y)

The PEP already calls that one a SyntaxError.  I can't imagine why a sane
programmer would want to do that, but if they really must the PEP _will_
allow it if they parenthesize the assignment expression in this context (so
"kwarg2=(x:=2*y)" instead.


> Sure, there are always ways to write bad code, and most people

> > wouldn’t do that, but someone, somewhere, that thinks shorter code is

> > better code might well do it. Or something like it.

Someone will!  No doubt about it.  But what of it?  If someone is
programming for their own amusement, why should I care?  If they're working
with a group, bad practice should be discouraged by the group's coding
standards and enforced by the group's code review process.  For this
feature, and all others.

"Consenting adults" is a key Python principle too.  And I believe in it,
despite that I wrote tabnanny.py ;-)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com