[issue27513] email.utils.getaddresses does not handle Header objects

[Zackery Spytz]

Change by Zackery Spytz :


--
keywords: +patch
pull_requests: +13682
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/13797

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37141] Allow multiple separators in Stream.readuntil

[Jeffrey Kintscher]

Change by Jeffrey Kintscher :


--
nosy: +Jeffrey.Kintscher

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36707] The "m" ABI flag of SOABI for pymalloc is no longer needed

[Kubilay Kocak]

Kubilay Kocak  added the comment:

Those script names would already have code to handle name changes based on 
existing abiflags/soabi string (as FreeBSD does), and would be trivial to 
modify for 'm' removal.

For third party stuff: we use setuptools --record for 'everything', so as long 
as filenames are 'correct' for the files that are actually installed, and 
downstreams are clear what the scope of the changes are, 'm' removal is not an 
issue when it come so packaging third party packages/extensions.

A new file extension format or substantially more complex magic would be, on 
the other hand.

A new minor is a good time to make these changes, and there's nothing really 
blocking about a new python38 port/package, and nothing consumes it yet in 
downstream OS's

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37134] [EASY] Use PEP570 syntax in the documentation

[Grant Jenks]

Grant Jenks  added the comment:

FWIW, I would rather not see the docs littered with "/". I've taught Python to 
hundreds of professional software engineers over the last five years and in all 
that time nobody has ever asked when the args need to be positional. It's easy 
to experiment to find out and it's historically been an implementation detail. 
I think the number of times people are surprised is far less than the number of 
times people never notice at all. As Raymond described, this change will 
elevate the feature to a day-1 topic and it's pretty useless to a day-1 user. 
This is another step toward making what I see as an unfortunate implementation 
detail into formal semantics.

--
nosy: +grantjenks

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36707] The "m" ABI flag of SOABI for pymalloc is no longer needed

[Ned Deily]

Ned Deily  added the comment:

Another user-visible difference:

$ ls /tmp/py37/bin/python*
/tmp/py37/bin/python3/tmp/py37/bin/python3.7-config  
/tmp/py37/bin/python3.7m-config
/tmp/py37/bin/python3.7  /tmp/py37/bin/python3.7m
/tmp/py37/bin/python3-config
$ ls /tmp/py38/bin/python*
/tmp/py38/bin/python3/tmp/py38/bin/python3.8-config
/tmp/py38/bin/python3.8  /tmp/py38/bin/python3-config

Granted, these differences aren't the end of the world but:

"But I'm not sure of what are the things impacting by ABIFLAGS="" rather than 
ABIFLAGS="m"."

Not to beat a dead horse but - we really should not make changes like this 
without first understanding what the impact will be.  As it stands, this change 
potentially affects end-users, third-party distributors of Python, and package 
developers.  And, for what reason?  I don't wsee how this change provides any 
real value for anyone and it does cause people to have to change things, like 
creating conditional code for 3.7- and 3.8+.  If we were starting from scratch 
today, sure - "m" is not needed.  But just because we can change something 
doesn't mean we should.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37134] [EASY] Use PEP570 syntax in the documentation

[Raymond Hettinger]

Raymond Hettinger  added the comment:

> Another part of the PEP's reasoning was that this notation
> is difficult to understand at least partially because it 
> is rarely encountered, so "people don't understand it" as 
> a reason to exclude it from the documentation becomes a
> bit of a self-fulfilling prophecy

We know that isn't true because people already see it frequently in the 
tooltips for C functions.  What I've observed is that after repeated exposures, 
users learn to treat it as noise and tune it out.  I've not found a single 
instance where a user found it to be helpful.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36707] The "m" ABI flag of SOABI for pymalloc is no longer needed

[Ned Deily]

Ned Deily  added the comment:

> One question I have is, can/does SOABI flag removal affect any third party 
> package/extension builds in any way, particularly affecting the names of 
> files they produce?

Yep, the default file names of C extension modules differ on most/all? Unix-y 
platforms (certainly vanilla Linux and macOS) because the SOABI is included in 
the file name.

$ /tmp/py38/bin/python3.7 -m pip install --no-binary :all: psutil
$ ls /tmp/py37/lib/python3.7/site-packages/psutil/*.so
/tmp/py37/lib/python3.7/site-packages/psutil/_psutil_linux.cpython-37m-i386-linux-gnu.so
/tmp/py37/lib/python3.7/site-packages/psutil/_psutil_posix.cpython-37m-i386-linux-gnu.so

$ /tmp/py38/bin/python3.8 -m pip install --no-binary :all: psutil
$ ls /tmp/py38/lib/python3.8/site-packages/psutil/*.so
/tmp/py38/lib/python3.8/site-packages/psutil/_psutil_linux.cpython-38-i386-linux-gnu.so
/tmp/py38/lib/python3.8/site-packages/psutil/_psutil_posix.cpython-38-i386-linux-gnu.so

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36964] `python3 -m venv NAME`: virtualenv is not portable

[Marco Sulla]

Marco Sulla  added the comment:

> Changing VIRTUAL_ENV will break code

VIRTUAL_ENV it's the same if you don't move the venv. Moving it will be an 
unofficial unsupported bonus, and if you coded bad and it doesn't work, it's 
your fault.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36707] The "m" ABI flag of SOABI for pymalloc is no longer needed

[Kubilay Kocak]

Kubilay Kocak  added the comment:

For FreeBSD Python language ports, the change doesn't have a big negative 
impact for the Python language/interpreter ports themselves

We have the following block in lang/python3? ports:

.if ${PORT_OPTIONS:MPYMALLOC}
ABIFLAGS:=  m${ABIFLAGS}
.endif

.if ${PORT_OPTIONS:MDEBUG}
ABIFLAGS:=  d${ABIFLAGS}
.endif


We then use the variable to substitute the correct suffix into the pkg-plist 
items:

.if !empty(ABIFLAGS)
PLIST_FILES+=   bin/python${PYTHON_VER}${ABIFLAGS} \
bin/python${PYTHON_VER}${ABIFLAGS}-config \
libdata/pkgconfig/python-${PYTHON_VER}${ABIFLAGS}.pc

${INSTALL_DATA} ${WRKSRC}/Tools/gdb/libpython.py \

${STAGEDIR}${PREFIX}/lib/libpython${PYTHON_VER}${ABIFLAGS}.so.1.0-gdb.py

One question I have is, can/does SOABI flag removal affect any third party 
package/extension builds in any way, particularly affecting the names of files 
they produce?

We have a ton of python packages/extensions in the ports tree, so anything that 
affected their builds, particularly when it comes to setuptools --record output 
changes, would be a blocker for supporting 3.8

For example, we had to produce custom ports framework code to account for 
PEP488 [1] and PEP3147 [2] filename suffixes, for these filename differences, 
which was painful at the time:

# PEP 0488 (https://www.python.org/dev/peps/pep-0488/)
.if ${PYTHON_REL} < 3500
PYTHON_PYOEXTENSION=pyo
.else
PYTHON_PYOEXTENSION=opt-1.pyc
.endif


.if ${PYTHON_REL} >= 3200 && defined(_PYTHON_FEATURE_PY3KPLIST)
# When Python version is 3.2+ we rewrite all the filenames
# of TMPPLIST that end with .py[co], so that they conform
# to PEP 3147 (see https://www.python.org/dev/peps/pep-3147/)
PYMAGICTAG= ${PYTHON_CMD} -c 'import sys; 
print(sys.implementation.cache_tag)'
_USES_stage+=   935:add-plist-python
add-plist-python:
@${AWK} '\
/\.py[co]$$/ && !($$0 ~ "/" pc "/") {id = match($$0, 
/\/[^\/]+\.py[co]$$/); if (id != 0) {d = substr($$0, 1, RSTART - 1); dirs[d] = 
1}; sub(/\.pyc$$/,  "." mt "&"); sub(/\.pyo$$/, "." mt "." pyo); 
sub(/[^\/]+\.py[co]$$/, pc "/&"); print; next} \
/^@dirrm / {d = substr($$0, 8); if (d in dirs) {print $$0 "/" 
pc}; print $$0; next} \
/^@dirrmtry / {d = substr($$0, 11); if (d in dirs) {print $$0 
"/" pc}; print $$0; next} \
{print} \
' \
pc="__pycache__" mt="$$(${PYMAGICTAG})" pyo="opt-1.pyc" \
${TMPPLIST} > ${TMPPLIST}.pyc_tmp
@${MV} ${TMPPLIST}.pyc_tmp ${TMPPLIST}


[1] https://www.python.org/dev/peps/pep-0488/
[2] https://www.python.org/dev/peps/pep-3147/

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21492] email.header.decode_header sometimes returns bytes, sometimes str

[Ezio Melotti]

Ezio Melotti  added the comment:

If we can't fix the behavior, it should at least be documented.

Currently the docs says "This function returns a list of (decoded_string, 
charset) pairs containing each of the decoded parts of the header.".  One could 
assume that this means that a Unicode string is returned, but and as far as I 
can tell, "decoded_string" means decoded from the format used by the header, 
not from bytes -- in fact the example below shows a byte string.
#24797 suggest an alternative solution, but there is no indications about it in 
the docs except an easy-to-miss note about the new API at the top.

Coincidentally as I was reporting this issue I also found the recently opened 
#37139.  There are also a few other reports: #24797, #37139, #32975, #6302, 
#4661.

If this method is not actually deprecated, I would document the current 
behavior (i.e. sometimes it returns bytes, sometimes unicode -- bonus points if 
there's a simple rule to predict which one), explain that it exists for 
legacy/backward-compatibility reasons, and point to the alternatives.


FWIW here are 3 more samples that show the inconsistency.

>>> from email.header import decode_header
>>> # str + None
>>> h = '\x80SOKCrGxsbw= '; decode_header(h)
[('\x80SOKCrGxsbw= ', None)]
>>> # bytes + '', bytes + None
>>> h = '=??b?SOKCrGxsbw=?= '; decode_header(h)
[(b'H\xe2\x82\xacllo', ''), (b' ', None)]
>>> # bytes + 'utf8', bytes + None
>>> h = '=?utf8?b?SOKCrGxsbw==?= '; decode_header(h)
[(b'H\xe2\x82\xacllo', 'utf8'), (b' ', None)]

--
assignee:  -> docs@python
components: +Documentation
nosy: +docs@python, ezio.melotti, louis.abra...@yahoo.fr
resolution: duplicate -> 
stage: resolved -> needs patch
status: closed -> open
type: behavior -> enhancement

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37130] pathlib.with_name() doesn't like unnamed files.

[Jeffrey Kintscher]

Change by Jeffrey Kintscher :


--
nosy: +Jeffrey.Kintscher

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37134] [EASY] Use PEP570 syntax in the documentation

[Paul Ganssle]

Paul Ganssle  added the comment:

> I respectfully disagree with logic, "the language now permits this, so we 
> should change all the docs to display it everywhere".  That moves it from 
> optional knowledge to mandatory knowledge, from a day ten lesson to a day one 
> lesson, from "once in a while, a user may benefit from being able to mark 
> arguments as positional-only" to the category of "every single user will see 
> this every time they see the docs".  There is a huge difference.

A decent part of the reasoning for the PEP was actually to create a standard 
way to document when arguments to a function are positional-only. By adopting 
the notation (already used in the numpy documentation IIRC), it makes a concise 
documentation clear.

Another part of the PEP's reasoning was that this notation is difficult to 
understand at least partially because it is rarely encountered, so "people 
don't understand it" as a reason to exclude it from the documentation becomes a 
bit of a self-fulfilling prophecy.

I am not really an expert in documentation and front-end design, but maybe it 
would be possible to have some sort of unobtrusive tooltip that activates on 
signatures that contain positional-only arguments?

--
nosy: +p-ganssle

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33416] Add endline and endcolumn to every AST node

[Guido van Rossum]

Guido van Rossum  added the comment:

It seems we're keeping the new PyCode_New() signature, so we can do the same 
here. Just document it; a versionchanged (if there isn't one yet) and a mention 
in What's New sound appropriate.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37134] [EASY] Use PEP570 syntax in the documentation

[Raymond Hettinger]

Raymond Hettinger  added the comment:

I respectfully disagree with logic, "the language now permits this, so we 
should change all the docs to display it everywhere".  That moves it from 
optional knowledge to mandatory knowledge, from a day ten lesson to a day one 
lesson, from "once in a while, a user may benefit from being able to mark 
arguments as positional-only" to the category of "every single user will see 
this every time they see the docs".  There is a huge difference.

My almost daily experience with end-users regarding the \ annotation has been 
decidedly negative.  And my experience as a professional tech writer teaches 
that "people will just have to figure it out" is not a phrase to live by when 
it comes to documentation (it is an anti-pattern).

There is no reason that we have to do this to the docs.  Please at least go 
with Carol's suggestion to defer all the trailing \ annotations for at least 
another release so that you can get more user feedback.

I know some regard The Zen of Python as just poetry, but the "readability 
counts" and "beautiful is better than ugly" parts mean something.  Those key 
attractors to the language should not be discarded lightly.

And while a blog post might be nice, the odds are that fewer than 1% of Python 
users will ever see it.  Python has millions of users and blog posts are rarely 
seen by more than tens of thousands.  Even then, blog post knowledge is 
transient and quickly becomes yesterday's news.  The entire notion of training 
away the problem is specious; you really shouldn't have to have training to 
read documentation.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37134] [EASY] Use PEP570 syntax in the documentation

[STINNER Victor]

STINNER Victor  added the comment:

A first enhancement would be to add an index entry for "/" at:
https://docs.python.org/dev/genindex-Symbols.html

> I'll note that Googling on: "python slash in formal argument list" ...

We have to find a cute name for the "/ operator" in function definition! Like 
the "walrus operator" for "x := 1" :-D Nobody is able to find "/" in Google. 
And I'm not sure that "slash" is accurate enough, since it has multiple meaning.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37137] test_asyncio: test_cancel_gather_2() dangling thread

[STINNER Victor]

STINNER Victor  added the comment:

Thanks Andrew! Sorry that you had to revert your change :-(

We can reconsider to merge again your change after beta1 (if our release 
manager is fine with that).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36818] Add PyInterpreterState.runtime.

[STINNER Victor]

STINNER Victor  added the comment:

By the way, I have questions about the rationale of this change.

> Currently we use the _PyRuntime static global to access the runtime state in 
> various places.  At the same time, in thread contexts we get access to the 
> thread state from Thread-Local Storage and the interpreter state by 
> indirection from there.  We should do the same for the runtime state instead 
> of using the global directly.

Right now I'm confused. _PyRuntimeState contains scatted states: things which 
should be moved to PyInterpreterState or even PyThreadState, and things which 
should remain in _PyRuntimeState. My notes on this topic:
https://pythoncapi.readthedocs.io/runtime.html

Is PyInterpreterState.runtime a temporary fix until things are moved?

Or do you plan to never access _PyRuntime directly, and always through 
interp->runtime?

It seems like in the short term, we must continue to access "_PyRuntime" 
through a separated "runtime" pointer passed to functions, to handle daemon 
threads during Python shutdown.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36818] Add PyInterpreterState.runtime.

[STINNER Victor]

STINNER Victor  added the comment:

This change introduced a regression:
https://bugs.python.org/issue37135#msg344511

I had to revert the change to fix Python for 3.8 beta1 release.

--
resolution: fixed -> 
status: closed -> open

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36818] Add PyInterpreterState.runtime.

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 0fd2c300c2a85b3b227a907b2a39ef79fa86d850 by Victor Stinner in 
branch 'master':
Revert "bpo-36818: Add PyInterpreterState.runtime field. (gh-13129)" (GH-13795)
https://github.com/python/cpython/commit/0fd2c300c2a85b3b227a907b2a39ef79fa86d850


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37140] ctypes change made clang fail to build

[Paul Monson]

Change by Paul Monson :


--
keywords: +patch
pull_requests: +13681
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/13796

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15474] Differentiate decorator and decorator factory in docs

[Windson Yang]

Windson Yang  added the comment:

Hi, Andrés Delfino. Are you still working on it?

--
nosy: +Windson Yang

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37135] test_multiprocessing_spawn segfaults on AMD64 FreeBSD CURRENT Shared 3.x

[STINNER Victor]

STINNER Victor  added the comment:

> commit 396e0a8d9dc65453cb9d53500d0a620602656cfe (refs/bisect/bad)

Extract of this change:
 
 static inline void
-exit_thread_if_finalizing(_PyRuntimeState *runtime, PyThreadState *tstate)
+exit_thread_if_finalizing(PyThreadState *tstate)
 {
+_PyRuntimeState *runtime = tstate->interp->runtime;
 /* _Py_Finalizing is protected by the GIL */
 if (runtime->finalizing != NULL && !_Py_CURRENTLY_FINALIZING(runtime, 
tstate)) {
 drop_gil(>ceval, tstate);
@@ -236,7 +237,7 @@ PyEval_AcquireLock(void)
 Py_FatalError("PyEval_AcquireLock: current thread state is NULL");
 }
 take_gil(ceval, tstate);
-exit_thread_if_finalizing(runtime, tstate);
+exit_thread_if_finalizing(tstate);
 }
 

This change is fine for regular Python threads. But for daemon threads, tstate 
is likely already corrupted, so it's no longer possible to get interp from 
interp, and so also not possible to get 'runtime'.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36818] Add PyInterpreterState.runtime.

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +13680
pull_request: https://github.com/python/cpython/pull/13795

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37135] test_multiprocessing_spawn segfaults on AMD64 FreeBSD CURRENT Shared 3.x

[STINNER Victor]

STINNER Victor  added the comment:

I used git bisect and I found:

commit 396e0a8d9dc65453cb9d53500d0a620602656cfe (refs/bisect/bad)
Author: Eric Snow 
Date:   Fri May 31 21:16:47 2019 -0600

bpo-36818: Add PyInterpreterState.runtime field. (gh-13129)

stress.py starts to crash at this change.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35814] Syntax quirk with variable annotations

[Ivan Levkivskyi]

Change by Ivan Levkivskyi :


--
pull_requests: +13679
pull_request: https://github.com/python/cpython/pull/13794

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37135] test_multiprocessing_spawn segfaults on AMD64 FreeBSD CURRENT Shared 3.x

[STINNER Victor]

STINNER Victor  added the comment:

If you apply attached sleep_at_exit.patch and run attach stress.py, you should 
quickly get a crash:

$ git apply sleep_at_exit.patch
$ make && ./python stress.py 
Segmentation fault (core dumped)

That's a simplified example of the multiprocessing crash.

--
keywords: +patch
Added file: https://bugs.python.org/file48388/sleep_at_exit.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37135] test_multiprocessing_spawn segfaults on AMD64 FreeBSD CURRENT Shared 3.x

[STINNER Victor]

Change by STINNER Victor :


Added file: https://bugs.python.org/file48387/stress.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37135] test_multiprocessing_spawn segfaults on AMD64 FreeBSD CURRENT Shared 3.x

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

Note that the core dump that we are talking about is something that we produced 
afterwards when trying to reproduce the issue. The core that is produced as 
part of the tests could be different. I am trying to get access to the test 
files.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33416] Add endline and endcolumn to every AST node

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

So what was the conclusion about PyCode_New()? Situation is quite similar here 
(except that these functions are used less often). Should we just document the 
changes in What's New?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36839] Support the buffer protocol in code objects

[Inada Naoki]

Inada Naoki  added the comment:

On Tue, Jun 4, 2019 at 8:45 AM Dino Viehland  wrote:
>
> The 20MB of savings is actually the amount of byte code that exists in the IG 
> code base.

Wait, do you expect you can reduce 100% saving of co_code object?
co_code takes 0byte?
You said "the overhead it just takes a byte code w/ 16 opcodes before
it breaks even" later.
So I believe you must understand there is overhead.

>  I was just measuring the web site code, and not the other various Python 
> code in the process (e.g. no std lib code, no 3rd party libraries, etc...).  
> The IG code base is pretty monolithic and starting up the site requires about 
> half of the code to get imported.  So I think the 20MB per process is a 
> pretty realistic number.

How many MBs your application takes?  20MB of 200MB is attractive.
20MB of 20GB is not attractive.
Absolute number is not important here.  You should use ratio.

>
> It's certainly true that the byte code isn't the #1 source of memory here 
> (the code objects themselves are pretty big), but in the serialized state it 
> ends up representing 25% of the serialized data.

"25% of the serialized data" is misleading information.
You are trying to reduce memory usage, not serialized data size.
You should use ratio of total RAM usage, not serialized data size.

> I can't make any promises about open sourcing the import system, but I can 
> certainly look into that as well.

Open sourcing is not necessary.  Try it by yourself and share the real
number, instead of
number of your estimation.
How much RSS is used by Python, and how much of it you can reduce by
this system, actually?

Regards,
-- 
Inada Naoki  

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37135] test_multiprocessing_spawn segfaults on AMD64 FreeBSD CURRENT Shared 3.x

[STINNER Victor]

STINNER Victor  added the comment:

I marked bpo-37143 "multiprocessing crashed with EXCEPTION_ACCESS_VIOLATION on 
Python on x86 Windows7 3.x" as a duplicate of this issue. Even if bpo-37143 
looks very different (crash in a different file, on a different operating 
system), I'm now quite sure that it has the same root cause.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37143] multiprocessing crashed with EXCEPTION_ACCESS_VIOLATION on Python on x86 Windows7 3.x

[STINNER Victor]

STINNER Victor  added the comment:

I mark this issue as a duplicate of bpo-37135.

--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37143] multiprocessing crashed with EXCEPTION_ACCESS_VIOLATION on Python on x86 Windows7 3.x

[STINNER Victor]

STINNER Victor  added the comment:

New fresh crash on x86 Windows7 3.x, even after the revert:

https://buildbot.python.org/all/#/builders/58/builds/2566

==
ERROR: test_multiprocessing (test.test_venv.BasicTest)
--
Traceback (most recent call last):
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_venv.py", 
line 327, in test_multiprocessing
out, err = check_output([envpy, '-c',
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_venv.py", 
line 42, in check_output
raise subprocess.CalledProcessError(
subprocess.CalledProcessError: Command 
'['d:\\temp\\tmp1rikh6ck\\Scripts\\python_d.exe', '-c', 'from multiprocessing 
import Pool; print(Pool(1).apply_async("Python".lower).get(3))']' returned 
non-zero exit status 3221225477.


Same on FreeBSD:
https://bugs.python.org/issue37135#msg344495

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37135] test_multiprocessing_spawn segfaults on AMD64 FreeBSD CURRENT Shared 3.x

[STINNER Victor]

STINNER Victor  added the comment:

I looked at the coredump with Pablo. In short, the main thread is calling 
Py_Exit() to exit the process and so released memory, and a daemon thread does 
crash on calling PyEval_RestoreThread() because tstate memory was freed.

The question is now if this bug is a regression compared to Python 3.7 or not. 
I'm trying to reproduce it on Linux by adding "sleep(1)" before exit, but my 
attempts are unsuccessful so far.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36656] Please add race-free os.link and os.symlink wrapper / helper

[Robert Collins]

Robert Collins  added the comment:

I'd like to add a few notes; please do consider Windows interactions here - 
Windows does not have the same model for inode replacement that Posix has.

Secondly, I note that the thread model discussed here hasn't been particular 
well articulated. In particular the vagaries of directories with the sticky bit 
set are quite different to those where attacker and victim share group 
permissions : TOCTTOU attacks do imply that post-atomic operation attacks will 
be possible, and I disagree with the analysis by Serhiy suggesting that they 
are necessarily so.

However I also agree with Toshio that the os module is not the right place to 
provide a more secure API: we have to have the basic primitive exposed to 
Python code somewhere, otherwise the higher level APIs such as you'd like to 
use are not creatable.

My suggestion is that you put a module up on PyPI that provides the secure 
behaviour necessary, get some feedback on that, get some cross-platform 
experience, and then, if desired, propose it for inclusion in shutil or similar 
in the stdlib.

I'm also going to retitle this - because actually, os.link and os.symlink 
aren't racy *per se* on Posix - its how they are used that is racy: and the 
very fact that a secure variant can be written (however ugly) is demonstration 
of that.

--
nosy: +rbcollins
title: Race conditions due to os.link and os.symlink POSIX specification -> 
Please add race-free os.link and os.symlink wrapper / helper

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35621] asyncio.create_subprocess_exec() only works with main event loop

[miss-islington]

miss-islington  added the comment:


New changeset 9535aff9421f0a5639f6e4c4bb0f07a743ea8dba by Miss Islington (bot) 
(Andrew Svetlov) in branch 'master':
Revert "bpo-35621: Support running subprocesses in asyncio when loop is 
executed in non-main thread (#13630)" (GH-13793)
https://github.com/python/cpython/commit/9535aff9421f0a5639f6e4c4bb0f07a743ea8dba


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37135] test_multiprocessing_spawn segfaults on AMD64 FreeBSD CURRENT Shared 3.x

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

CURRENT-amd64% lldb ./python -c python.core
(lldb) target create "./python" --core "python.core"
Core file '/home/pablo/cpython/python.core' (x86_64) was loaded.
(lldb) bt
* thread #1, name = 'python', stop reason = signal SIGBUS
  * frame #0: 0x0035cfad python`take_gil(tstate=0x000802b34010) at 
ceval_gil.h:216:13
frame #1: 0x0035d499 
python`PyEval_RestoreThread(tstate=0x000802b34010) at ceval.c:281:5
frame #2: 0x0040c045 python
frame #3: 0x0047cc51 python
frame #4: 0x0034f59c 
python`_PyMethodDef_RawFastCallKeywords(method=0x000802b34010, 
self=0x0008011c1578, args=0x0092, nargs=2, 
kwnames=) at call.c:653:18
frame #5: 0x0034e549 
python`_PyCFunction_FastCallKeywords(func=0x0008011c8280, 
args=, nargs=, kwnames=) at call.c:732:14
frame #6: 0x0036d850 
python`call_function(pp_stack=0x7fffdfbfbcc8, oparg=, 
kwnames=) at ceval.c:4673:9
frame #7: 0x00368d09 
python`_PyEval_EvalFrameDefault(f=, throwflag=) at 
ceval.c:3294:19
frame #8: 0x0036e59c python`_PyEval_EvalCodeWithName [inlined] 
PyEval_EvalFrameEx(f=, throwflag=0) at ceval.c:624:12
frame #9: 0x0036e586 
python`_PyEval_EvalCodeWithName(_co=, globals=, 
locals=, args=, argcount=2, 
kwnames=0x, kwargs=0x00080266e5f8, kwcount=0, kwstep=1, 
defs=0x000802533558, defcount=1, kwdefs=0x, 
closure=0x, name=0x0008017355f0, 
qualname=0x000802524d60) at ceval.c:4035
frame #10: 0x0034e438 
python`_PyFunction_FastCallKeywords(func=, stack=, 
nargs=, kwnames=) at call.c:435:12
frame #11: 0x0036d9c7 
python`call_function(pp_stack=0x7fffdfbfc020, oparg=, 
kwnames=) at ceval.c:4721:17
frame #12: 0x00368bae 
python`_PyEval_EvalFrameDefault(f=, throwflag=) at 
ceval.c:3280:23
frame #13: 0x0034ebaa 
python`function_code_fastcall(co=, args=, nargs=2, 
globals=) at call.c:285:14
frame #14: 0x0036d9c7 
python`call_function(pp_stack=0x7fffdfbfc230, oparg=, 
kwnames=) at ceval.c:4721:17
frame #15: 0x00368bae 
python`_PyEval_EvalFrameDefault(f=, throwflag=) at 
ceval.c:3280:23
frame #16: 0x0036e59c python`_PyEval_EvalCodeWithName [inlined] 
PyEval_EvalFrameEx(f=, throwflag=0) at ceval.c:624:12
frame #17: 0x0036e586 
python`_PyEval_EvalCodeWithName(_co=, globals=, 
locals=, args=, argcount=2, 
kwnames=0x, kwargs=0x00080271eb58, kwcount=0, kwstep=1, 
defs=0x00080251dbd8, defcount=2, kwdefs=0x, 
closure=0x, name=0x00080187fd60, 
qualname=0x000802522340) at ceval.c:4035
frame #18: 0x0034e438 
python`_PyFunction_FastCallKeywords(func=, stack=, 
nargs=, kwnames=) at call.c:435:12
frame #19: 0x0036d9c7 
python`call_function(pp_stack=0x7fffdfbfc520, oparg=, 
kwnames=) at ceval.c:4721:17
frame #20: 0x00368bae 
python`_PyEval_EvalFrameDefault(f=, throwflag=) at 
ceval.c:3280:23
frame #21: 0x0034ebaa 
python`function_code_fastcall(co=, args=, nargs=2, 
globals=) at call.c:285:14
frame #22: 0x0036d9c7 
python`call_function(pp_stack=0x7fffdfbfc730, oparg=, 
kwnames=) at ceval.c:4721:17
frame #23: 0x00368bae 
python`_PyEval_EvalFrameDefault(f=, throwflag=) at 
ceval.c:3280:23
frame #24: 0x0034ebaa 
python`function_code_fastcall(co=, args=, nargs=2, 
globals=) at call.c:285:14
frame #25: 0x0034f934 
python`_PyObject_Call_Prepend(callable=0x0008025b4100, 
obj=0x000801878b30, args=, kwargs=0x00080267e980) at 
call.c:906:14
frame #26: 0x0034e75f 
python`PyObject_Call(callable=0x0008021008d8, args=0x0008017a7cb0, 
kwargs=0x00080267e980) at call.c:247:18
frame #27: 0x003690a9 python`_PyEval_EvalFrameDefault [inlined] 
do_call_core(func=, callargs=, 
kwdict=0x00080267e980) at ceval.c:4775:12
frame #28: 0x0036907e 
python`_PyEval_EvalFrameDefault(f=, throwflag=) at 
ceval.c:3353
frame #29: 0x0034ebaa 
python`function_code_fastcall(co=, args=, nargs=1, 
globals=) at call.c:285:14
frame #30: 0x0036d9c7 
python`call_function(pp_stack=0x7fffdfbfcba0, oparg=, 
kwnames=) at ceval.c:4721:17
frame #31: 0x00368bae 
python`_PyEval_EvalFrameDefault(f=, throwflag=) at 
ceval.c:3280:23
frame #32: 0x0034ebaa 
python`function_code_fastcall(co=, args=, nargs=1, 
globals=) at call.c:285:14
frame #33: 0x0036d9c7 
python`call_function(pp_stack=0x7fffdfbfcdb0, oparg=, 
kwnames=) at ceval.c:4721:17
frame #34: 0x00368bae 
python`_PyEval_EvalFrameDefault(f=, throwflag=) at 
ceval.c:3280:23
frame #35: 0x0034ebaa 
python`function_code_fastcall(co=, args=, nargs=1, 
globals=) at call.c:285:14
frame #36: 0x0034f934 

[issue37140] ctypes change made clang fail to build

[Paul Monson]

Paul Monson  added the comment:

Reading the related bugs more carefully I think the struct/union passing 
conventions are different on Windows x64 and Linux.  I have a fix which works 
for Windows but preserves the prior code for Linux.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37137] test_asyncio: test_cancel_gather_2() dangling thread

[Andrew Svetlov]

Andrew Svetlov  added the comment:

Got you. https://github.com/python/cpython/pull/13793

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35621] asyncio.create_subprocess_exec() only works with main event loop

[Andrew Svetlov]

Change by Andrew Svetlov :


--
pull_requests: +13678
pull_request: https://github.com/python/cpython/pull/13793

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31006] typing.NamedTuple should add annotations to its constructor (__new__) parameters.

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

Thanks! It looks like this was fixed in typing and then forward ported to 
CPython.

--
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37135] test_multiprocessing_spawn segfaults on AMD64 FreeBSD CURRENT Shared 3.x

[STINNER Victor]

STINNER Victor  added the comment:

> FTR Victor reverted GH-13714 that triggers this.

Sadly, this revert wasn't enough. New fresh coredump on "AMD64 FreeBSD CURRENT 
Shared 3.x":
https://buildbot.python.org/all/#builders/168/builds/1145

Warning -- Dangling processes: {}
Warning -- Dangling processes: {}
Warning -- multiprocessing.process._dangling was modified by
test_multiprocessing_spawn
  Before: set()
  After:  {}
Warning -- files was modified by test_multiprocessing_spawn
  Before: []
  After:  ['python.core']

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36839] Support the buffer protocol in code objects

[Dino Viehland]

Dino Viehland  added the comment:

The 20MB of savings is actually the amount of byte code that exists in the IG 
code base.  I was just measuring the web site code, and not the other various 
Python code in the process (e.g. no std lib code, no 3rd party libraries, 
etc...).  The IG code base is pretty monolithic and starting up the site 
requires about half of the code to get imported.  So I think the 20MB per 
process is a pretty realistic number.

I've also created a C extension and the object implementing the buffer protocol 
looks like:

typedef struct {
PyObject_HEAD
const char* data;
size_t size;
Py_ssize_t hash;
CIceBreaker *breaker;
size_t exports;
PyObject* code_obj; /* borrowed reference, the code object keeps us alive */
} CIceBreakerCode;

All of the modules are currently getting compiled into a single memory mapped 
file and then these objects get created which implement the buffer protocol for 
each function.  So the overhead it just takes a byte code w/ 16 opcodes before 
it breaks even, so it is significantly lighter weight than using a memoryview 
object.

It's certainly true that the byte code isn't the #1 source of memory here (the 
code objects themselves are pretty big), but in the serialized state it ends up 
representing 25% of the serialized data.  I would expect when you add in ref 
counts and typing information it's not quite as good, but reducing the overhead 
of code by 20% is still a pretty nice win.

I can't make any promises about open sourcing the import system, but I can 
certainly look into that as well.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37140] ctypes change made clang fail to build

[Paul Monson]

Paul Monson  added the comment:

If I undo the changes to StructUnionType_paramfunc then test_pass_by_value 
(ctypes.test.test_structures.StructureTestCase) fails on x64 on Windows.  
Looking at the code I don't think this is specific to Windows.

This is a test for fixing this issue: https://bugs.python.org/issue29565

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37137] test_asyncio: test_cancel_gather_2() dangling thread

[STINNER Victor]

STINNER Victor  added the comment:

> 2. Revert added watchers entirely

I prefer this option just because we must fix all bugs as soon as possible to 
get the beta1 released, and this bug is just one bug in a list of bugs.

I might try to help you *later* to fix the change to prevent this bug.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37137] test_asyncio: test_cancel_gather_2() dangling thread

[Andrew Svetlov]

Andrew Svetlov  added the comment:

We have two options:
1. Apply https://github.com/python/cpython/pull/13792 to wait for dangling 
threads
2. Revert added watchers entirely

What do you prefer?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37137] test_asyncio: test_cancel_gather_2() dangling thread

[Andrew Svetlov]

Change by Andrew Svetlov :


--
pull_requests: +13677
pull_request: https://github.com/python/cpython/pull/13792

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37137] test_asyncio: test_cancel_gather_2() dangling thread

[STINNER Victor]

STINNER Victor  added the comment:

> I suspect that I've added this dangling thread by 
> https://github.com/python/cpython/blob/master/Lib/asyncio/unix_events.py#L1248-L1251
>  :(

Can you please try to revert commit 13ed07998ad93dbdd94991ba0451b9b559f07972?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37137] test_asyncio: test_cancel_gather_2() dangling thread

[Andrew Svetlov]

Andrew Svetlov  added the comment:

Working on PR

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33694] test_asyncio: test_start_tls_server_1() fails on Python on x86 Windows7 3.7 and 3.x

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


--
nosy:  -pablogsal

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33694] test_asyncio: test_start_tls_server_1() fails on Python on x86 Windows7 3.7 and 3.x

[Andrew Svetlov]

Change by Andrew Svetlov :


--
nosy:  -asvetlov

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33694] test_asyncio: test_start_tls_server_1() fails on Python on x86 Windows7 3.7 and 3.x

[Inada Naoki]

Change by Inada Naoki :


--
pull_requests: +13676
pull_request: https://github.com/python/cpython/pull/13787

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37137] test_asyncio: test_cancel_gather_2() dangling thread

[Andrew Svetlov]

Andrew Svetlov  added the comment:

I suspect that I've added this dangling thread by 
https://github.com/python/cpython/blob/master/Lib/asyncio/unix_events.py#L1248-L1251
 :(

--
nosy: +asvetlov

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35763] IDLE calltips: make positional note less obtrusive

[Terry J. Reedy]

Change by Terry J. Reedy :


--
keywords: +patch
pull_requests: +13675
stage: test needed -> patch review
pull_request: https://github.com/python/cpython/pull/13791

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5680] Simulate command-line arguments for program run in IDLE

[Cheryl Sabella]

Cheryl Sabella  added the comment:

I've pushed a change for a more generic dialog for a 'Run Custom' option and I 
changed the keybinding to Shift-F5.  Sorry for not doing that on the initial 
commit; I didn't fully understand the difference between what you were asking 
for and the minimal version I had committed.

For this change, I also added a 'Restart shell' checkbox to the dialog, more as 
a proof-of-concept than anything else (although I did hook it up, so it should 
be functional).  Is this the type of dialog you had in mind?

I made some comments on the PR as to some of the decisions I've run into so far 
with the design.

Thanks!

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37146] opcode cache for LOAD_GLOBAL emits false alarm in memory leak hunting

[STINNER Victor]

STINNER Victor  added the comment:

INADA-san wrote PR 13787 to disable opcache when Python is compiled in debug 
mode. Pablo and me approved the change, so I merged it.

Pablo wrote a more robust solution, PR 13789, to disable opcache only in 
regrtest, to look for memory leaks. But INADA-san had a good argument against 
this approach:
https://github.com/python/cpython/pull/13789#issuecomment-498449735

"The code object will be optimized only when ++co->co_opcache_flag == 
opcacheminruns. So decreasing min_runs by _setopcacheminruns()will cause some 
hot codes will be not optimized forever. I don't want to expose such switch."

I would prefer to keep this issue until a long term approach is designed.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37146] opcode cache for LOAD_GLOBAL emits false alarm in memory leak hunting

[STINNER Victor]

STINNER Victor  added the comment:


New changeset eddef861b49f1635222a9e1771231c34a807debf by Victor Stinner (Inada 
Naoki) in branch 'master':
bpo-37146: disable opcache when Py_DEBUG is defined (GH-13787)
https://github.com/python/cpython/commit/eddef861b49f1635222a9e1771231c34a807debf


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36889] Merge StreamWriter and StreamReader into just asyncio.Stream

[Andrew Svetlov]

Change by Andrew Svetlov :


--
pull_requests: +13674
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/13790

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36707] The "m" ABI flag of SOABI for pymalloc is no longer needed

[Miro Hrončok]

Miro Hrončok  added the comment:

I'm not sure either. So far most affected buildscripts are confused by:

/usr/include/python3.Xm -> /usr/include/python3.X
/usr/lib64/libpython3.Xm -> /usr/lib64/libpython3.X
extension.cpython-3Xm-arch-linux-gnu.so -> 
extension.cpython-3X-arch-linux-gnu.so

However this is pretty much Linux specific, so I wouldn't know how to explain 
this in an OS agnostic way.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37146] opcode cache for LOAD_GLOBAL emits false alarm in memory leak hunting

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


--
pull_requests: +13673
pull_request: https://github.com/python/cpython/pull/13789

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36707] The "m" ABI flag of SOABI for pymalloc is no longer needed

[STINNER Victor]

STINNER Victor  added the comment:

> It's usually just custom ugly-hardcoded autotools/cmake. Nothing severe 
> enough.  However, this change still is not documented anywhere in 
> https://docs.python.org/dev/whatsnew/3.8.html

I concur that it should be documented. It's on my TODO list. But I'm not sure 
of what are the things impacting by ABIFLAGS="" rather than ABIFLAGS="m". 
Someone has to propose a PR to document that.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37093] http.client aborts header parsing upon encountering non-ASCII header names

[Tim Burke]

Change by Tim Burke :


--
keywords: +patch
pull_requests: +13672
stage: test needed -> patch review
pull_request: https://github.com/python/cpython/pull/13788

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37146] opcode cache for LOAD_GLOBAL emits false alarm in memory leak hunting

[Inada Naoki]

Change by Inada Naoki :


--
keywords: +patch
pull_requests: +13671
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/13787

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37134] [EASY] Use PEP570 syntax in the documentation

[Gregory P. Smith]

Gregory P. Smith  added the comment:

I agree with Brett and Carol here.  This is part of the language syntax.  We 
can educate people to that effect more if desired (I like the blog post idea).  
People will figure it out.

We've already got high ranked stackoverflow answers related to this when you 
search:
 
https://stackoverflow.com/questions/24735311/python-what-does-the-slash-mean-in-help-output/
 
https://stackoverflow.com/questions/28243832/what-is-the-meaning-of-a-forward-slash-in-a-python-method-signature-as-show/

Today, we don't document what is positional only, adding this notation is an 
improvement because it communicates that detail to anyone interested in 
understanding it without adding a pile of text to all sorts of function 
signatures.

--
nosy: +gregory.p.smith

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37137] test_asyncio: test_cancel_gather_2() dangling thread

[STINNER Victor]

STINNER Victor  added the comment:

My second attempt isn't fully successful :-( test_asyncio still fails with 
ENV_CHANGED :-(

https://buildbot.python.org/all/#/builders/185/builds/488

test_current_task_no_running_loop_implicit 
(test.test_asyncio.test_tasks.CCurrentLoopTests) ... Warning -- 
threading_cleanup() failed to cleanup -1 threads (count: 0, dangling: 1)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37145] collections.abc.MappingView mixins rely on undocumented _mapping

[Geoffrey Sneddon]

Geoffrey Sneddon  added the comment:

How do you use ItemsView without:

 * relying on __init__ and _mapping, which are both private implementation 
details, or
 * reimplementing __len__, __contains__, and __iter__?

Given you can't use the mixin implementations of __len__, __contains__, and 
__iter__ without relying on private implementation details, should they 
actually be considered mixin implementations? Shouldn't they just be abstract 
methods given you can't actually use them?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37137] test_asyncio: test_cancel_gather_2() dangling thread

[STINNER Victor]

STINNER Victor  added the comment:

I push a fix in asyncio, instead of trying to fix individual asyncio tests:

New changeset 0f0a30f4da4b529e0f7df857b9f575b231b32758 by Victor Stinner in 
branch 'master':
bpo-34037, asyncio: add BaseEventLoop.wait_executor_on_close (GH-13786)
https://github.com/python/cpython/commit/0f0a30f4da4b529e0f7df857b9f575b231b32758

See https://bugs.python.org/issue34037#msg344476

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36707] The "m" ABI flag of SOABI for pymalloc is no longer needed

[Miro Hrončok]

Miro Hrončok  added the comment:

It's usually just custom ugly-hardcoded autotools/cmake. Nothing severe enough. 
 However, this change still is not documented anywhere in 
https://docs.python.org/dev/whatsnew/3.8.html

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34037] asyncio: BaseEventLoop.close() shutdowns the executor without waiting causing leak of dangling threads

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 0f0a30f4da4b529e0f7df857b9f575b231b32758 by Victor Stinner in 
branch 'master':
bpo-34037, asyncio: add BaseEventLoop.wait_executor_on_close (GH-13786)
https://github.com/python/cpython/commit/0f0a30f4da4b529e0f7df857b9f575b231b32758


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34037] asyncio: BaseEventLoop.close() shutdowns the executor without waiting causing leak of dangling threads

[STINNER Victor]

STINNER Victor  added the comment:

"executor.shutdown(wait=False)" was added by this change:

commit 4ca7355901049ff9a873cf236091e6780d7a8126
Author: Antoine Pitrou 
Date:   Sun Oct 20 00:54:10 2013 +0200

Issue #19299: fix refleak test failures in test_asyncio

Guido van Rossum proposed to wait for the executor. Guido proposed " 
executor.shutdown(wait=False)", but he didn't comment why wait=False:

https://bugs.python.org/issue19299#msg200508

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34037] asyncio: BaseEventLoop.close() shutdowns the executor without waiting causing leak of dangling threads

[STINNER Victor]

STINNER Victor  added the comment:

I wrote PR 13786 to fix this issue.

--
versions: +Python 3.8 -Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37137] test_asyncio: test_cancel_gather_2() dangling thread

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +13670
pull_request: https://github.com/python/cpython/pull/13786

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37029] PyObject_Free is O(N) where N = # of arenas

[Tim Peters]

Tim Peters  added the comment:

Thank you, Friedl!  I appreciate the extra confirmation - and especially on 
even bigger test cases :-)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37134] [EASY] Use PEP570 syntax in the documentation

[Carol Willing]

Carol Willing  added the comment:

Tim's message resonated with me. Confusing users is something that I believe 
that we wish to minimize. I confess that I had a similar reaction as Tim when I 
saw functions with a trailing `/`. What I did find helpful was adding to the 
middle of the parameter list as was done in Serihy's earlier PRs.

Since we are balancing technical accuracy with user confusion (docs and 
docstrings), I propose the following: 

1. Remove the trailing / from 3.8 documentation but leave the / if it occurs in 
the middle of the parameter list. This increases technical accuracy from 
pre-3.8 and gives users more time to get comfortable with the change (since end 
users have found this a confusing area with args kwargs *).

2. Add to the documentation in 3.8 section on positional only parameters a note 
box that describes that in many/all cases where a / is not specified at the end 
and no * is found in the parameter list that a trailing slash would be accurate.

3. Give users time to absorb the positional only change in 3.8. Perhaps writing 
a blog post that explains in detail.

4. Add the trailing / in 3.9 documentation to make consistent with docstrings 
or improve/create a better directive for function that provides a better 
accuracy and less confusion. A Sphinx extension may also be made to show a 
simple user-friendly view and with a click the fully accurate view.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37124] test_msilib is potentially leaking references and memory blocks

[Steve Dower]

Steve Dower  added the comment:

I have no idea. I don't ever use msilib, but there are a few people who do that 
don't have any way to get bugs fixed, so I'll help merge.

If it's just the test leak, probably it's in the test. I don't recall the 
change having any impact on resource usage. But at worst, removing the test 
completely is fine by me.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37137] test_asyncio: test_cancel_gather_2() dangling thread

[STINNER Victor]

STINNER Victor  added the comment:

My change didn't fix the issue:

https://buildbot.python.org/all/#/builders/176/builds/680

test_proc_exited (test.test_asyncio.test_subprocess.SubprocessTransportTests) 
... Warning -- threading_cleanup() failed to cleanup -1 threads (count: 0, 
dangling: 1)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37146] opcode cache for LOAD_GLOBAL emits false alarm in memory leak hunting

[STINNER Victor]

New submission from STINNER Victor :

opcode cache for LOAD_GLOBAL introduced false alarm in memory leak hunting 
(python3 -m test -R 3:3 ...).

=> opcache: bpo-26219.


Before the change:

$ git checkout 91234a16367b56ca03ee289f7c03a34d4cfec4c8^
$ make && ./python -m test -R 3:3 test_pprint 
...
Tests result: SUCCESS

After the change:

$ git checkout 91234a16367b56ca03ee289f7c03a34d4cfec4c8
$ make && ./python -m test -R 3:3 test_pprint 
...
test_pprint leaked [4, 2, 4] memory blocks, sum=10
...

The problem is that at each iteration of regrtest -R 3:3 (6 iterations), a few 
more code objects get this opcache allocated.

There are different solutions to fix regrtest -R 3:3.


(*) Always optimize:

diff --git a/Python/ceval.c b/Python/ceval.c
index 411ba3d73c..6cd148efba 100644
--- a/Python/ceval.c
+++ b/Python/ceval.c
@@ -103,7 +103,7 @@ static long dxp[256];
 #endif
 
 /* per opcode cache */
-#define OPCACHE_MIN_RUNS 1024  /* create opcache when code executed this time 
*/
+#define OPCACHE_MIN_RUNS 1  /* create opcache when code executed this time */
 #define OPCACHE_STATS 0  /* Enable stats */
 
 #if OPCACHE_STATS

$ make && ./python -m test -R 3:3 test_pprint 
...
Tests result: SUCCESS


(*) Never optimmize: disable opcache until a better fix can be found

diff --git a/Python/ceval.c b/Python/ceval.c
index 411ba3d73c..3c85df6fea 100644
--- a/Python/ceval.c
+++ b/Python/ceval.c
@@ -1230,6 +1230,7 @@ _PyEval_EvalFrameDefault(PyFrameObject *f, int throwflag)
 f->f_stacktop = NULL;   /* remains NULL unless yield suspends frame */
 f->f_executing = 1;
 
+#if 0
 if (co->co_opcache_flag < OPCACHE_MIN_RUNS) {
 co->co_opcache_flag++;
 if (co->co_opcache_flag == OPCACHE_MIN_RUNS) {
@@ -1244,6 +1245,7 @@ _PyEval_EvalFrameDefault(PyFrameObject *f, int throwflag)
 #endif
 }
 }
+#endif
 
 #ifdef LLTRACE
 lltrace = _PyDict_GetItemId(f->f_globals, ___ltrace__) != NULL;

$ make && ./python -m test -R 3:3 test_pprint 
...
Tests result: SUCCESS


(*) Find a way to explicitly deoptimize all code objects

Modules/gcmodule.c has a clear_freelists() function called by collect() if 
generation == NUM_GENERATIONS-1: on when gc.collect() is collected explicitly 
for example.

Lib/test/libregrtest/refleak.py also has a dash_R_cleanup() function which 
clears many caches.

Problem: currently, code objects are not explicitly tracked (for example, they 
are not tracked in a double linked list).


(*) Add way more warmup iterations to regrtest in buildbots.

I dislike this option. A build on a refleak buildbot worker already takes 2 to 
3 hours. Adding more warmup would make a build even way more slower.

--
components: Interpreter Core
messages: 344469
nosy: inada.naoki, vstinner, yselivanov
priority: normal
severity: normal
status: open
title: opcode cache for LOAD_GLOBAL emits false alarm in memory leak hunting
versions: Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26219] implement per-opcode cache in ceval

[STINNER Victor]

STINNER Victor  added the comment:

The opcode cache introduced an issue in reference leak hunting: see bpo-37146.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36964] `python3 -m venv NAME`: virtualenv is not portable

[Brett Cannon]

Brett Cannon  added the comment:

Changing VIRTUAL_ENV will break code, so I'm not sure if it's worth changing.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37134] [EASY] Use PEP570 syntax in the documentation

[Brett Cannon]

Brett Cannon  added the comment:

FYI when Guido said "call on the steering council" I think he meant open an 
issue at https://github.com/python/steering-council/issues as this will get 
lost otherwise (i.e. Guido already removed himself from the nosy list so this 
already doesn't have the whole council participating).

Anyway, from my personal view, I think we should use the syntax. It's 
officially part of the language at this point and so avoiding it in the docs 
seems odd, like we're saying that we're ashamed of this syntax and you should 
pretend it doesn't exist when it does and it isn't going anywhere. Otherwise 
aren't we're forcing users to realize that the function definition in the docs 
deviates from what is definable in this one instance and that one has to read 
the full text to know that something is doable syntactically but we're leaving 
it out of the docs? It adds inconsistency in what the definition line means IMO 
based on how we have usually chosen to try and express things in that 'def' 
line in the docs as succinctly as possible to communicate the semantics of 
calling that function.

And I realize that Raymond's "unscientific twitter poll had mostly WTF 
reactions from end-users", but that's also sampling from people who have 
probably never used the syntax in real life or read docs regularly that use it. 
I've actually been wanting to use the syntax to say "the name isn't important 
here" as I've had to already close a PR that wanted to tweak documentation for 
name consistency where it actually didn't matter because the code used 
positional-only parameters but they weren't explicitly documented as such. 
Going back and saying "positional-only" to communicate that everywhere that it 
applies versus using the syntax we have to express that seems unnecessary to me.

Or put another way, how would you want to update:

len(obj)
Return the number of items in a container.

to properly reflect the fact that *obj* is positional-only which is now an 
official concept in the language? We've been glazing over this for ages in the 
docs because we didn't have a way of expressing it succinctly and it only 
touched C-implemented code and we lacked a way to state it in Python, but now 
we have a way to state this fact. You could add a "The **obj** parameter is 
positional-only.", but to me that requires unnecessary reading of the text body 
if all I'm doing is checking the parameter order (and maybe the first 
sentence). And I realize we have gotten away with this until now, but as the 
concept of positional-only parameters grows that will become more of an issue.

Not using / also means that we're deviating from what help() emits, which could 
cause its own confusion as more people learn about the new syntax.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37120] Provide knobs to disable session ticket generation on TLS 1.3

[Christian Heimes]

Change by Christian Heimes :


--
resolution:  -> fixed
stage: patch review -> commit review
status: open -> pending

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36868] New behavior of OpenSSL hostname verification not exposed, incorrectly documented

[miss-islington]

miss-islington  added the comment:


New changeset cad4ff65eb12649cd650059b15d8e12f2ae951ef by Miss Islington (bot) 
in branch '3.7':
bpo-36868: Fix what's new for SSLContext.hostname_checks_common_name (GH-13248)
https://github.com/python/cpython/commit/cad4ff65eb12649cd650059b15d8e12f2ae951ef


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37120] Provide knobs to disable session ticket generation on TLS 1.3

[Christian Heimes]

Christian Heimes  added the comment:

I have merged the PR to land the feature in time for the feature freeze.

Regarding your comment on client_context.num_ticket getter: IMHO it's not a 
good idea to raise an exception on attribute access. It may break introspection.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37134] [EASY] Use PEP570 syntax in the documentation

[Tim Peters]

Tim Peters  added the comment:

I haven't looked at anything in this PR, so just popping in to confirm that the 
first time I saw stuff like:

len(obj, /)

in the docs I had no idea at all what it was trying to say.  I thought it was a 
typo.

Also the second, third, fourth, ..., times I saw it.

However, because Python didn't _accept_ that syntax in my own function 
definitions, that may well have made it extraordinarily hard to figure out.

If the syntax is going to be accepted now, that does change things to my eyes.  
It becomes a question of discoverability then.

I'll note that Googling on

python slash in formal argument list

turns up an excellent Stackoverflow explanation as its top hit for me today, 
although not if "slash" is replaced with "/".

--
nosy: +tim.peters

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37120] Provide knobs to disable session ticket generation on TLS 1.3

[Christian Heimes]

Christian Heimes  added the comment:


New changeset 78c7d527799dacca91b9ed67057cb996efe526b0 by Christian Heimes in 
branch 'master':
bpo-37120: Add SSLContext.num_tickets (GH-13719)
https://github.com/python/cpython/commit/78c7d527799dacca91b9ed67057cb996efe526b0


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37130] pathlib.with_name() doesn't like unnamed files.

[Brett Cannon]

Change by Brett Cannon :


--
stage:  -> test needed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37130] pathlib.with_name() doesn't like unnamed files.

[Brett Cannon]

Brett Cannon  added the comment:

The inconsistency is a bit weird. Looking at 
https://github.com/python/cpython/blob/master/Lib/pathlib.py#L825 the question 
is why is self.name not being set for '.' but it is for '..'. I suspect there's 
special-casing for '.' somewhere that sets self.name to '' for '.' but leaves 
it alone in all other instances.

Based on what with_name() is supposed to do I would argue that '..' shouldn't 
work since without a filename the with_name() method makes no sense.

--
nosy: +brett.cannon

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37140] ctypes change made clang fail to build

[Paul Monson]

Paul Monson  added the comment:

The change causing the build failure comes from this commit.
https://github.com/python/cpython/pull/3806/commits/ea8a0dcea68409d37f3ad9e60e42777c76ad903b

The commit comment says: "Fix copy of structures when passed by value."

Steve, do you recall what this change fixed?

--
nosy: +Paul Monson, steve.dower

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36868] New behavior of OpenSSL hostname verification not exposed, incorrectly documented

[miss-islington]

Change by miss-islington :


--
keywords: +patch
pull_requests: +13669
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/13784

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36868] New behavior of OpenSSL hostname verification not exposed, incorrectly documented

[miss-islington]

miss-islington  added the comment:


New changeset 47eb2234061524562a4b484e3a395f4fdd6c1b76 by Miss Islington (bot) 
(Christian Heimes) in branch 'master':
bpo-36868: Fix what's new for SSLContext.hostname_checks_common_name (GH-13248)
https://github.com/python/cpython/commit/47eb2234061524562a4b484e3a395f4fdd6c1b76


--
nosy: +miss-islington

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34001] LibreSSL does not tolerate setting minimum_version greater than maximum_version

[Christian Heimes]

Change by Christian Heimes :


--
pull_requests: +13668
pull_request: https://github.com/python/cpython/pull/13783

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34271] Please support logging of SSL master secret by env variable SSLKEYLOGFILE

[Christian Heimes]

Christian Heimes  added the comment:


New changeset e35d1ba9eab07a59b98b700c5e18ceb13b2561a6 by Christian Heimes in 
branch 'master':
bpo-34271: Fix compatibility with 1.0.2 (GH-13728)
https://github.com/python/cpython/commit/e35d1ba9eab07a59b98b700c5e18ceb13b2561a6


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37081] Test with OpenSSL 1.1.1c

[miss-islington]

miss-islington  added the comment:


New changeset 3344197040fe1b05a3244bdb16d429f4647f35b8 by Miss Islington (bot) 
in branch '3.7':
[3.7] bpo-37081: Test with OpenSSL 1.1.1c (GH-13631) (GH-13782)
https://github.com/python/cpython/commit/3344197040fe1b05a3244bdb16d429f4647f35b8


--
nosy: +miss-islington

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37134] [EASY] Use PEP570 syntax in the documentation

[Raymond Hettinger]

Raymond Hettinger  added the comment:

> If you think me pushing for this change will impact somehow
> our ability to work together I will close the PR and the issue. 

Not at all.  I always enjoy working with you and appreciate the depth of 
thinking you bring to every task :-)

Here, we just disagree on whether changing the docs will be a net aid or net 
detriment to end users.  My belief is that the docs will be less usable, less 
intuitive, and less approachable.  People using the docs are already alone and 
in need of help.  Cryptic notation doesn't make this task easier.  While a 
person can be trained to read this notation, it is my belief that a person 
shouldn't have to have training to read the docs.

Unlike other decisions where predicting the future is uncertain, we already 
have some user testing results because the \ notation was exposed in help() via 
the argument clinic.  The results have not been favorable.  AFAICT not one 
single user has benefitted from seeing something like this output from 
help(len):

len(obj, /)
Return the number of items in a container.

The / is a stumbling block. My unscientific twitter poll had mostly WTF 
reactions from end-users. This wasn't limited to beginners -- Steve Holden and 
David Beazley have both found this notation detrimental to communication.

This week I joined a twitter thread where I needed to defend the existing docs. 
 The contention was that docs aren't very usable for end-users and that the 
existing core devs lacked writing skills and were too interested in technical 
details rather than plain communication. (I mostly disagree with this, but 
there is another core dev consistently giving this message in talks all around 
the world).  The essential point here is that there are already usability 
concerns with the documentation.  My belief is that this PR will make the 
situation worse.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37111] Logging - Inconsistent behaviour when handling unicode

[Steve Dower]

Steve Dower  added the comment:

I agree with Paul. Consistency with open() is the most important aspect here, 
and when we investigated changing that to UTF-8 it was decided to be too 
disruptive.

That said, I'm not opposed to adding encoding/errors to basicConfig if someone 
wants to do that (and the logging specialists are okay with it).

--
resolution: not a bug -> 
stage:  -> test needed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37081] Test with OpenSSL 1.1.1c

[miss-islington]

Change by miss-islington :


--
pull_requests: +13667
pull_request: https://github.com/python/cpython/pull/13782

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37081] Test with OpenSSL 1.1.1c

[Christian Heimes]

Christian Heimes  added the comment:


New changeset 06651ee418b5e4e013195d6b702763a1220706a7 by Christian Heimes in 
branch 'master':
bpo-37081: Test with OpenSSL 1.1.1c (GH-13631)
https://github.com/python/cpython/commit/06651ee418b5e4e013195d6b702763a1220706a7


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37134] [EASY] Use PEP570 syntax in the documentation

[Guido van Rossum]

Change by Guido van Rossum :


--
nosy:  -gvanrossum

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36027] Support negative exponents in pow() where a modulus is specified.

[Mark Dickinson]

Mark Dickinson  added the comment:

@Petr: Thanks for the quick fix!

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37135] test_multiprocessing_spawn segfaults on AMD64 FreeBSD CURRENT Shared 3.x

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

> FTR Victor reverted GH-13714 that triggers this.

Given the nature of the bugs, I would recommend to watch the buildbots

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com