Re: [Python-ideas] Use __all__ for dir(module) (Was: PEP 562)

[Cody Piersall]

On Sun, Sep 17, 2017 at 9:49 PM, Guido van Rossum  wrote:
> I ave to agree with the other committers who already spoke up.
>
> I'm not using tab completion much (I have a cranky old Emacs setup), but
> isn't making tab completion better a job for editor authors (or
> language-support-for-editor authors) rather than for the core language? What
> editor are you using that calls dir() for tab completion?
>
>> From my perspective, the big benefit of this change is that
>> tab-completion will get better for libraries which are already
>> defining __all__.  This will make for a better REPL experience.  The
>> only code in the stdlib that broke were tests in test_pkg which were
>> explicitly checking the return value of dir().  Apart from that,
>> nothing broke.

I'm sorry, I should have been more specific here. The tab completion
provided by Jupyter uses dir() to provide the relevant tab-completion
options.  I was motivated to put this PR together whenever someone (I
think Nathaniel Smith) was talking about setting a custom __dir__ on a
module by overriding class, and IIRC his motivation was so that no one
tab-completes to use a deprecated attribute.  I spend a _lot_ of time
in a Jupyter environment, so most of my tab completion is provided by
whatever dir() returns.  I think this is a pretty common setup.

The default REPL also uses dir() for populating the completion list.
Since my only interaction with dir() has to do with tab completion, I
may be unaware of use cases where this PR would actually break working
code.  I understand (and agree with!) the emphasis the Python
developers place on backwards compatibility, but I just can't think of
code that would be broken by this change.  Of course, that doesn't
mean it doesn't exist!

Cody
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Use __all__ for dir(module) (Was: PEP 562)

[Guido van Rossum]

I ave to agree with the other committers who already spoke up.

I'm not using tab completion much (I have a cranky old Emacs setup), but
isn't making tab completion better a job for editor authors (or
language-support-for-editor authors) rather than for the core language?
What editor are you using that calls dir() for tab completion?

On Sun, Sep 17, 2017 at 7:34 PM, Cody Piersall 
wrote:

> On Tue, Sep 12, 2017 at 3:26 AM, Ivan Levkivskyi 
> wrote:
> > @Cody
> >> I still think the better way
> >> to solve the custom dir()  would be to change the module __dir__
> >> method to check if __all__ is defined and use it to generate the
> >> result if it exists. This seems like a logical enhancement to me,
> >> and I'm planning on writing a patch to implement this. Whether it
> >> would be accepted is still an open issue though.
> >
> > This seems a reasonable rule to me, I can also make this patch if
> > you will not have time.
>
> I submitted a PR:https://github.com/python/cpython/pull/3610
> and a BPO issue: https://bugs.python.org/issue31503
>
> R. David Murray pointed out that this is a backwards-incompatible
> change.  This is technically true, but I don't know of any code that
> depends on this behavior.  (Of course, that does not mean it does not
> exist!)
>
> From my perspective, the big benefit of this change is that
> tab-completion will get better for libraries which are already
> defining __all__.  This will make for a better REPL experience.  The
> only code in the stdlib that broke were tests in test_pkg which were
> explicitly checking the return value of dir().  Apart from that,
> nothing broke.
>
> If a module does not have __all__ defined, then nothing changes for that
> module.
>
> Cody
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Use __all__ for dir(module) (Was: PEP 562)

[Cody Piersall]

On Tue, Sep 12, 2017 at 3:26 AM, Ivan Levkivskyi  wrote:
> @Cody
>> I still think the better way
>> to solve the custom dir()  would be to change the module __dir__
>> method to check if __all__ is defined and use it to generate the
>> result if it exists. This seems like a logical enhancement to me,
>> and I'm planning on writing a patch to implement this. Whether it
>> would be accepted is still an open issue though.
>
> This seems a reasonable rule to me, I can also make this patch if
> you will not have time.

I submitted a PR:https://github.com/python/cpython/pull/3610
and a BPO issue: https://bugs.python.org/issue31503

R. David Murray pointed out that this is a backwards-incompatible
change.  This is technically true, but I don't know of any code that
depends on this behavior.  (Of course, that does not mean it does not
exist!)

>From my perspective, the big benefit of this change is that
tab-completion will get better for libraries which are already
defining __all__.  This will make for a better REPL experience.  The
only code in the stdlib that broke were tests in test_pkg which were
explicitly checking the return value of dir().  Apart from that,
nothing broke.

If a module does not have __all__ defined, then nothing changes for that module.

Cody
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Make map() better

[Abdur-Rahmaan Janhangeer]

in that case you presented maybe it is more readeable but considering that
lists as ["a","b"] can be inputted, not just using range, the result might
be as it was. change x y people are happy change y and z people hate it

Abdur-Rahmaan Janhangeer,
Mauritius
abdurrahmaanjanhangeer.wordpress.com

On 13 Sep 2017 19:10, "Jason H"  wrote:

> The format of map seems off. Coming from JS, all the functions come
> second. I think this approach is superior.
>
> Currently:
> map(lambda x: chr(ord('a')+x), range(26)) # ['a', 'b', 'c', 'd', 'e', 'f',
> 'g', 'h', 'i', 'j', 'k', 'l', 'm', 'n', 'o', 'p', 'q', 'r', 's', 't', 'u',
> 'v', 'w', 'x', 'y', 'z']
>
> But I think this reads better:
> map(range(26), lambda x: chr(ord('a')+x))
>
> Currently that results in:
> TypeError: argument 2 to map() must support iteration
>
> Also, how are we to tell what supports map()?
> Any iterable should be able to map via:
> range(26).map(lambda x: chr(ord('a')+x)))
>
> While the line length is the same, I think the latter is much more
> readable, and the member method avoids parameter order confusion
>
> For the global map(),
> having the iterable first also increases reliability because the lambda
> function is highly variable in length, where as parameter names are
> generally shorter than even the longest lambda expression.
>
> More readable: IMHO:
> map(in, lambda x: chr(ord('a')+x))
> out = map(out, lambda x: chr(ord('a')+x))
> out = map(out, lambda x: chr(ord('a')+x))
>
> Less readable (I have to parse the lambda):
> map(lambda x: chr(ord('a')+x), in)
> out = map(lambda x: chr(ord('a')+x), out)
> out = map(lambda x: chr(ord('a')+x), out)
>
> But I contend:
> range(26).map(lambda x: chr(ord('a')+x)))
> is superior to all.
>
>
>
>
>
>
>
>
>
>
>
>
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Move some regrtest or test.support features into unittest?

[Antoine Pitrou]

On Wed, 13 Sep 2017 15:42:56 +0200
Victor Stinner 
wrote:
> I would like to see if and how we can integrate/move some regrtest
> features into the unittest module. Example of regrtest features:
> 
> * skip a test if it allocates too much memory, command line argument
> to specify how many memory a test is allowed to allocate (ex:
> --memlimit=2G for 2 GB of memory)

That would be suitable for a plugin if unittest had a plugin
architecture, but not as a core functionality IMO.

> * concept of "resource" like "network" (connect to external network
> servers, to the Internet), "cpu" (CPU intensive tests), etc. Tests are
> skipped by default and enabled by the -u command line option (ex: "-u
> cpu).

Good as a core functionality IMO.

> * track memory leaks: check the reference counter, check the number of
> allocated memory blocks, check the number of open file descriptors.

Good for a plugin IMO.

> * detect if the test spawned a thread or process and the
> thread/process is still running at the test exit

Good for a plugin IMO.

> * --timeout: watchdog killing the test if the run time exceed the
> timeout in seconds (use faulthandler.dump_traceback_later)

Good for a plugin IMO.

> * multiprocessing: run tests in subprocesses, in parallel

Good as a core functionality IMO.

> * redirect stdout/stderr to pipes (StringIO objects), ignore them on
> success, or dump them to stdout/stderr on test failure

Good for a plugin IMO.

> * --slowest: top 10 of the slowest tests

Good for a plugin IMO.

> * --randomize: randomize test order

Will be tricky to mix with setupClass.

> * --match, --matchfile, -x: filter tests

Good as a core functionality IMO.

> * --forever: run the test in a loop until it fails (or is interrupted by 
> CTRL+c)

Good for a plugin IMO.

> * --list-tests / --list-cases: list test files / test methods

Good as a core functionality IMO.

> * --fail-env-changed: mark tests as failed if a test altered the environment

Good for a plugin IMO.

> * detect if a "global variable" of the standard library was modified
> but not restored by the test:

Good for a plugin IMO.

> * test.bisect: bisection to identify the failing method, used to track
> memory leaks or identify a test leaking a resource (ex: create a file
> but don't remove it)

Good as a core functionality IMO.

> I started to duplicate code in many files of Lib/test/test_*.py to
> check if tests "leak running threads" ("dangling threads"). Example
> from Lib/test/test_theading.py:
> 
> class BaseTestCase(unittest.TestCase):
> def setUp(self):
> self._threads = test.support.threading_setup()
> 
> def tearDown(self):
> test.support.threading_cleanup(*self._threads)
> test.support.reap_children()
> 
> I would like to get this test "for free" directly from the regular
> unittest.TestCase class, but I don't know how to extend the unittest
> module for that?

Instead of creating tons of distinct base TestCase classes, you can just
provide helper functions / methods calling addCleanup().

Regards

Antoine.


___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] A PEP to define basical metric which allows to guarantee minimal code quality

[alexandre . galode]

Hi,

thanks for your answer, and your questions. Very good draw. I printed it in 
my office ^^

First i'd like to precise that, as in title, aim is not to gurantee quality 
but minimal quality. I think it's really two different things.

About metrics, my ideas was about following (for the moment):

   - Basical Python Rules respect: PEP8 & PEP20 respect
   - Docstring/documentation respect: PEP257 respect
   - Code readability: percentage of commentary line and percentage of 
   blank line
   - Code maintainability / complexity: the facility to re-read code if old 
   code, or to understand code for an external developer. If not 
   comprehensive, for example, i use McCabe in my work
   - Code coverage: by unit tests
   
>From your question on objective metrics, i don't think that reliable 
metrics exists. We can only verify that minimal quality can be reached. As 
you say, it's a subjective apprehension, but in my mind, this "PEP" could 
be a guideline to improve development for some developers.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/