Re: [Python-Dev] Issue #21071: change struct.Struct.format type from bytes to str
On 16 June 2017 at 14:19, Serhiy Storchaka wrote: > 27.03.17 15:12, Victor Stinner пише: >> >> I would like to change struct.Struct.format type from bytes to str. I >> don't expect that anyone uses this attribute, and struct.Struct() >> constructor accepts both bytes and str. >> >> http://bugs.python.org/issue21071 >> >> It's just to be convenient: more functions accept str than bytes in >> Python 3. Example: print() (python3 -bb raises an exceptions if you >> pass bytes to print). >> >> Is anything opposed to breaking the backward compatibility? > > > If nobody opposed to this change it will be made in short time. As long as it's noted in the "Porting to Python 3.7" section of the 3.7 What's New guide, this seems like a sensible change to me. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue #21071: change struct.Struct.format type from bytes to str
2017-06-16 10:40 GMT+02:00 Nick Coghlan : > As long as it's noted in the "Porting to Python 3.7" section of the > 3.7 What's New guide, this seems like a sensible change to me. Yes, the change is already documented there: https://github.com/python/cpython/pull/845/files Victor ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] New work-in-progress bisection tool for the Python test suite (in regrtest)
Hi,
Last weeks, I worked on a new tool to bisect failing tests because
it's painful to bisect manually reference leaks (I remove as much code
as possible until the code is small enough to be reviewable manually).
See the bisect_test.py script attached to this issue:
http://bugs.python.org/issue29512
With the help of Louie Lu, I added new --list-cases option to "python
-m test", so you can now list all test cases and write it into a text
file:
./python -m test --list-cases test_os > tests
I also added a new --matchfile option, to filter tests using a text
file which contains one pattern per line:
./python -m test --matchfile=tests test_os
fnmatch is used to match test names, so "*" joker character can be
used in test names.
My bisection tool takes a text file with the --matchfile format (one
pattern per line) and creates a random subset of tests with half of
the tests. If tests still fail, use the subset. Otherwise, create a
new random subset. Loop until the subset contains a single test
(configurable threshold, -n command line option).
The long term plan is to integrate the bisection feature directly into regrtest.
Right now, my script is hardcoded to bisect reference leak bugs, but
it should be easy to modify it to bisect other test issues like test
creating files without removing it ("ENV_CHANGED" failure in
regrtest).
For example, a core file is dumped when running test_subprocess on
FreeBSD buildbots:
http://bugs.python.org/issue30448
But I'm unable to reproduce the issue on my FreeBSD. It would be nice
to be able to automate the bisection on the buildbot directly.
--list-cases and --matchfile options are now available in 2.7, 3.5,
3.6 and master (3.7) branches.
TODO: doctest tests are only partially supported, see:
http://bugs.python.org/issue30683
Victor
___
Python-Dev mailing list
[email protected]
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
ACTIVITY SUMMARY (2017-06-09 - 2017-06-16) Python tracker at http://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: open6034 ( -1) closed 36405 (+70) total 42439 (+69) Open issues with patches: 2366 Issues opened (48) == #17870: Python does not provide PyLong_FromIntMax_t() or PyLong_FromUi http://bugs.python.org/issue17870 reopened by Devin Jeanpierre #30616: Cannot use functional API to create enum with zero values http://bugs.python.org/issue30616 opened by Gerrit.Holl #30617: IDLE: Add docstrings and unittests to outwin.py http://bugs.python.org/issue30617 opened by csabella #30618: readlink for pathlib paths http://bugs.python.org/issue30618 opened by smheidrich #30619: typing.Union doc incoherence in case a class and its subclass http://bugs.python.org/issue30619 opened by khyox #30622: Fix NPN guard for OpenSSL 1.1 http://bugs.python.org/issue30622 opened by msopacua #30623: python-nightly import numpy fails since recently http://bugs.python.org/issue30623 opened by Arek Bulski #30625: Documentation is unclear how "y*" and "y#" format units vary http://bugs.python.org/issue30625 opened by Gregory.Szorc #30629: lower() is called twice http://bugs.python.org/issue30629 opened by motoki #30630: Missing MSI files http://bugs.python.org/issue30630 opened by Mark Airey #30633: Python 3.6.1 installation issues on OpenSuse 42.1: ModuleNotFo http://bugs.python.org/issue30633 opened by zopyx #30637: Syntax error reported on compile(...), but not on compile(..., http://bugs.python.org/issue30637 opened by hniksic #30638: Additional dependencies and rule for `make regen-all` http://bugs.python.org/issue30638 opened by serhiy.storchaka #30639: inspect.getfile(obj) calls object repr on failure http://bugs.python.org/issue30639 opened by takluyver #30640: NULL + 1 in _PyFunction_FastCallDict() http://bugs.python.org/issue30640 opened by serhiy.storchaka #30645: imp.py: load_package() appends to its own loop variable http://bugs.python.org/issue30645 opened by Alexandru Ardelean #30647: CODESET error on AMD64 FreeBSD 10.x Shared 3.x caused by the P http://bugs.python.org/issue30647 opened by haypo #30648: test_logout() of test_imaplib.RemoteIMAP_STARTTLSTest failed r http://bugs.python.org/issue30648 opened by haypo #30649: test_utime_current_old() of test_os fails randomy on x86 Windo http://bugs.python.org/issue30649 opened by haypo #30651: test_poplib.test_stls_context() access violation on x86 Window http://bugs.python.org/issue30651 opened by haypo #30652: test_threading_not_handled() of test_socketserver hangs random http://bugs.python.org/issue30652 opened by haypo #30653: test_socket hangs in ThreadableTest.tearDown() on AMD64 FreeBS http://bugs.python.org/issue30653 opened by haypo #30654: signal module always overwrites SIGINT on interpreter shutdown http://bugs.python.org/issue30654 opened by pkerling #30657: Unsafe arithmetic in PyString_DecodeEscape http://bugs.python.org/issue30657 opened by jaybosamiya #30658: Buildbot: don't sent email notification for custom builders http://bugs.python.org/issue30658 opened by haypo #30660: Lossless Optimization of PNG files http://bugs.python.org/issue30660 opened by tfs #30661: Support tarfile.PAX_FORMAT in shutil.make_archive http://bugs.python.org/issue30661 opened by ncoghlan #30662: fix OrderedDict.__init__ docstring to reflect PEP 468 http://bugs.python.org/issue30662 opened by jonathaneunice #30663: IDLE: Add lineno sidebar to editor window http://bugs.python.org/issue30663 opened by louielu #30664: Change unittest's _SubTest to not sort its params when printin http://bugs.python.org/issue30664 opened by eric.smith #30665: pass big values for arg to fcntl.ioctl http://bugs.python.org/issue30665 opened by ukl #30666: IDLE: add tests for autocomplete window. http://bugs.python.org/issue30666 opened by terry.reedy #30667: IDLE: revise doc subsections 'Completions' http://bugs.python.org/issue30667 opened by terry.reedy #30668: DOC: missing word in license.rst http://bugs.python.org/issue30668 opened by csabella #30670: pprint for dict in sorted order or insert order? http://bugs.python.org/issue30670 opened by josephsmeng #30671: dict: improve lookup function http://bugs.python.org/issue30671 opened by Dmitry Rubanovich #30672: PEP 538: Unexpected locale behaviour on Mac OS X http://bugs.python.org/issue30672 opened by ncoghlan #30673: Add -t option (timeout) to Tools/buildbot/test.bat for "AMD64 http://bugs.python.org/issue30673 opened by haypo #30674: IDLE: add docstrings to grep.py http://bugs.python.org/issue30674 opened by csabella #30675: test_zipfile leaks references on Python 3.5 on the wo Refleaks http://bugs.python.org/issue30675 opened by haypo #30677: Enhance documentation of os.mkdir() http://bugs.python.org/issue30677 opened by ebi
Re: [Python-Dev] New work-in-progress bisection tool for the Python test suite (in regrtest)
Great idea! I had thought about doing something similar to this years ago
to help diagnose when a test passes in isolation but somehow fails due to
one of the bazillion of other tests that ran previously (which can be hard
to narrow down if the failure is not early on in a test run).
On Fri, 16 Jun 2017 at 09:06 Victor Stinner
wrote:
> Hi,
>
> Last weeks, I worked on a new tool to bisect failing tests because
> it's painful to bisect manually reference leaks (I remove as much code
> as possible until the code is small enough to be reviewable manually).
>
> See the bisect_test.py script attached to this issue:
> http://bugs.python.org/issue29512
>
> With the help of Louie Lu, I added new --list-cases option to "python
> -m test", so you can now list all test cases and write it into a text
> file:
>
>./python -m test --list-cases test_os > tests
>
> I also added a new --matchfile option, to filter tests using a text
> file which contains one pattern per line:
>
>./python -m test --matchfile=tests test_os
>
> fnmatch is used to match test names, so "*" joker character can be
> used in test names.
>
>
> My bisection tool takes a text file with the --matchfile format (one
> pattern per line) and creates a random subset of tests with half of
> the tests. If tests still fail, use the subset. Otherwise, create a
> new random subset. Loop until the subset contains a single test
> (configurable threshold, -n command line option).
>
> The long term plan is to integrate the bisection feature directly into
> regrtest.
>
>
>
> Right now, my script is hardcoded to bisect reference leak bugs, but
> it should be easy to modify it to bisect other test issues like test
> creating files without removing it ("ENV_CHANGED" failure in
> regrtest).
>
> For example, a core file is dumped when running test_subprocess on
> FreeBSD buildbots:
>
>http://bugs.python.org/issue30448
>
> But I'm unable to reproduce the issue on my FreeBSD. It would be nice
> to be able to automate the bisection on the buildbot directly.
>
>
> --list-cases and --matchfile options are now available in 2.7, 3.5,
> 3.6 and master (3.7) branches.
>
> TODO: doctest tests are only partially supported, see:
>
> http://bugs.python.org/issue30683
>
> Victor
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Language proposal: variable assignment in functional context
Hello, I would like to propose an idea for the language but I don't know where I can talk about it. In a nutshell, I would like to be able to write: y = (b+2 for b = a + 1) Or in list comprehension: Y = [b+2 for a in L for b = a+1] Which can already be done like this: Y = [b+2 for a in L for b in [a+1]] Which is less obvious, has a small overhead (iterating over a list) and get messy with multiple assignment: Y = [b+c+2 for a in L for b,c in [(a+1,a+2)]] New syntax would allow to write: Y = [b+c+2 for a in L for b,c = (a+1,a+2)] The parenthesis are needed for syntax reason I think. One could have successive assignements My first example (b+2 for b = a+1) can already be done using ugly syntax using lambda y = (lambda b: b+2)(b=a+1) y = (lambda b: b+2)(a+1) y = (lambda b=a+1: b+2)() Choice of syntax: for is good because it uses current keyword, and the analogy for x = 5 vs for x in [5] is natural. But the "for" loses the meaning of iteration. The use of "with" would maybe sound more logical. Python already have the "functional if", lambdas, list comprehension, but not simple assignment functional style. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Language proposal: variable assignment in functional context
2017-06-16 13:32 UTC+02:00, Robert Vanden Eynde : > Hello, I would like to propose an idea for the language but I don't know > where I can talk about it. Hi, May I suggest Python-ideas? https://mail.python.org/mailman/listinfo/python-ideas Thanks. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New work-in-progress bisection tool for the Python test suite (in regrtest)
2017-06-16 19:00 GMT+02:00 Brett Cannon :
> Great idea! I had thought about doing something similar to this years ago to
> help diagnose when a test passes in isolation but somehow fails due to one
> of the bazillion of other tests that ran previously (which can be hard to
> narrow down if the failure is not early on in a test run).
Yeah, sometimes a test only fails if it is run after other tests. The
well known issue of side effects ;-)
Each time that my script bisect_test.py script succeed to reduce the
number of tests, it writes the test list on disk. So you can interrupt
it the script is stuck and you consider that the output is small
enough to a manual review.
Victor
> On Fri, 16 Jun 2017 at 09:06 Victor Stinner
> wrote:
>>
>> Hi,
>>
>> Last weeks, I worked on a new tool to bisect failing tests because
>> it's painful to bisect manually reference leaks (I remove as much code
>> as possible until the code is small enough to be reviewable manually).
>>
>> See the bisect_test.py script attached to this issue:
>> http://bugs.python.org/issue29512
>>
>> With the help of Louie Lu, I added new --list-cases option to "python
>> -m test", so you can now list all test cases and write it into a text
>> file:
>>
>>./python -m test --list-cases test_os > tests
>>
>> I also added a new --matchfile option, to filter tests using a text
>> file which contains one pattern per line:
>>
>>./python -m test --matchfile=tests test_os
>>
>> fnmatch is used to match test names, so "*" joker character can be
>> used in test names.
>>
>>
>> My bisection tool takes a text file with the --matchfile format (one
>> pattern per line) and creates a random subset of tests with half of
>> the tests. If tests still fail, use the subset. Otherwise, create a
>> new random subset. Loop until the subset contains a single test
>> (configurable threshold, -n command line option).
>>
>> The long term plan is to integrate the bisection feature directly into
>> regrtest.
>>
>>
>>
>> Right now, my script is hardcoded to bisect reference leak bugs, but
>> it should be easy to modify it to bisect other test issues like test
>> creating files without removing it ("ENV_CHANGED" failure in
>> regrtest).
>>
>> For example, a core file is dumped when running test_subprocess on
>> FreeBSD buildbots:
>>
>>http://bugs.python.org/issue30448
>>
>> But I'm unable to reproduce the issue on my FreeBSD. It would be nice
>> to be able to automate the bisection on the buildbot directly.
>>
>>
>> --list-cases and --matchfile options are now available in 2.7, 3.5,
>> 3.6 and master (3.7) branches.
>>
>> TODO: doctest tests are only partially supported, see:
>>
>> http://bugs.python.org/issue30683
>>
>> Victor
>> ___
>> Python-Dev mailing list
>> [email protected]
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> https://mail.python.org/mailman/options/python-dev/brett%40python.org
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Language proposal: variable assignment in functional context
On 16/06/17 12:32, Robert Vanden Eynde wrote: Hello, I would like to propose an idea for the language but I don't know where I can talk about it. Robert, I have replied to this on the "python-ideas" ML. Regards, E. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Language proposal: variable assignment in functional context
Welcome Robert. My response below. Follow-ups to Python-Ideas, thanks. You'll need to subscribe to see any further discussion. On Fri, Jun 16, 2017 at 11:32:19AM +, Robert Vanden Eynde wrote: > In a nutshell, I would like to be able to write: > y = (b+2 for b = a + 1) I think this is somewhat similar to a suggestion of Nick Coghlan's. One possible syntax as a statement might be: y = b + 2 given: b = a + 1 https://www.python.org/dev/peps/pep-3150/ In mathematics, I might write: y = b + 2 where b = a + 1 although of course I wouldn't do so for anything so simple. Here's a better example, the quadratic formula: -b ± √Δ x = ─ 2a where Δ = b² - 4ac although even there I'd usually write Δ in place. > Python already have the "functional if", lambdas, list comprehension, > but not simple assignment functional style. I think you mean "if *expression*" rather than "functional if". The term "functional" in programming usually refers to a particular paradigm: https://en.wikipedia.org/wiki/Functional_programming -- Steve ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Language proposal: variable assignment in functional context
Thanks! Le 17 juin 2017 06:19, "Shloub" mailto:[email protected]>> a écrit : 2017-06-16 13:32 UTC+02:00, Robert Vanden Eynde mailto:[email protected]>>: > Hello, I would like to propose an idea for the language but I don't know > where I can talk about it. Hi, May I suggest Python-ideas? https://mail.python.org/mailman/listinfo/python-ideas Thanks. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 538 (review round 2): Coercing the legacy C locale to a UTF-8 based locale
On 12 June 2017 at 22:05, Nick Coghlan wrote: > On 12 June 2017 at 17:47, Martin (gzlist) wrote: >> Having thought about it a bit more, my preferred option is having the >> disable be if either LC_ALL or LC_CTYPE vars are exactly 'C', then >> don't override. Otherwise (including for LANG=C), force C.UTF-8. The >> CLI usage docs could have a LC_CTYPE entry that goes into details of >> why. > > LC_ALL=C doesn't actually disable the locale coercion (i.e. we still > set LC_CTYPE). The coercion just doesn't have any effect, since LC_ALL > takes precedence. After improving the test suite to better cover this case, it seems my assumptions regarding the behaviour of setlocale() when LC_ALL is set may have been incorrect - when LC_ALL=C is set, we *only* get the legacy locale warning, *not* the locale coercion warning (at least on Fedora - we'll know more about the behaviour on other platforms once I test my proposed resolution for https://bugs.python.org/issue30565 across the buildbot fleet). So if we chose to, we could treat an explicit "LC_CTYPE=C" the same way we treat "PYTHONCOERCECLOCALE=0" - it's definitely worth considering, so please file an RFE for that. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
