[issue39592] Year not updated at python.org

[Ammar Askar]

Ammar Askar  added the comment:

Please direct this to https://github.com/python/pythondotorg/issues

This tracker is for issues pertaining to the interpreter.

--
nosy: +ammar2
resolution:  -> third party
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

[issue39592] Year not updated at python.org

[F4zi]

New submission from F4zi :

The year in https://www.python.org/psf/donations/python-dev/

Should be changed from 2019 to 2020

--
assignee: docs@python
components: Documentation
messages: 361645
nosy: F4zi, docs@python, eric.araujo, ezio.melotti, mdk, willingc
priority: normal
severity: normal
status: open
title: Year not updated at python.org

___
Python tracker 

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

[issue39491] Import PEP 593 (Flexible function and variable annotations) support already implemented in typing_extensions

[Andy Lester]

Change by Andy Lester :


--
pull_requests: +17799
pull_request: https://github.com/python/cpython/pull/18422

___
Python tracker 

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

[issue39491] Import PEP 593 (Flexible function and variable annotations) support already implemented in typing_extensions

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
pull_requests:  -17793

___
Python tracker 

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

[issue39491] Import PEP 593 (Flexible function and variable annotations) support already implemented in typing_extensions

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
pull_requests:  -17797

___
Python tracker 

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

[issue39590] collections.deque.__contains__ and .count should hold strong references.

[Dennis Sweeney]

Dennis Sweeney  added the comment:

Should there be a similar generic test case in test.seq_test?

--

___
Python tracker 

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

[issue39591] Functions in Python/traceback.c can take const pointer arguments

[Andy Lester]

Change by Andy Lester :


--
pull_requests:  -17794

___
Python tracker 

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

[issue39591] Functions in Python/traceback.c can take const pointer arguments

[Andy Lester]

Change by Andy Lester :


--
pull_requests: +17798
pull_request: https://github.com/python/cpython/pull/18422

___
Python tracker 

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

[issue39491] Import PEP 593 (Flexible function and variable annotations) support already implemented in typing_extensions

[Andy Lester]

Change by Andy Lester :


--
pull_requests: +17797
pull_request: https://github.com/python/cpython/pull/18422

___
Python tracker 

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

[issue39590] collections.deque.__contains__ and .count should hold strong references.

[Dennis Sweeney]

Change by Dennis Sweeney :


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

___
Python tracker 

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

[issue39573] Make PyObject an opaque structure in the limited C API

[hai shi]

Change by hai shi :


--
pull_requests: +17795
pull_request: https://github.com/python/cpython/pull/18419

___
Python tracker 

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

[issue39591] Functions in Python/traceback.c can take const pointer arguments

[Andy Lester]

Change by Andy Lester :


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

___
Python tracker 

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

[issue39491] Import PEP 593 (Flexible function and variable annotations) support already implemented in typing_extensions

[Andy Lester]

Change by Andy Lester :


--
pull_requests: +17793
pull_request: https://github.com/python/cpython/pull/18420

___
Python tracker 

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

[issue39591] Functions in Python/traceback.c can take const pointer arguments

[Andy Lester]

New submission from Andy Lester :

The functions tb_displayline and tb_printinternal can take const pointers on 
some of their arguments.

tb_displayline(PyObject *f, PyObject *filename, int lineno, const PyObject 
*name)

tb_printinternal(const PyTracebackObject *tb, PyObject *f, long limit)

--
components: Interpreter Core
messages: 361643
nosy: petdance
priority: normal
severity: normal
status: open
title: Functions in Python/traceback.c can take const pointer arguments
type: enhancement

___
Python tracker 

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

[issue39590] collections.deque.__contains__ and .count should hold strong references.

[Dennis Sweeney]

New submission from Dennis Sweeney :

Similar to https://bugs.python.org/issue39453, but with deques:

Python 3.9.0a3+:

>>> from collections import deque
>>> class A:
... def __eq__(self, other):
... L.clear()
... return NotImplemented
...
>>> L = [A(), A(), A()]
>>> 17 in L
False
>>> L = deque([A(), A(), A()])
>>> 17 in L

(Crashes with "Unhandled exception thrown: read access violation.")

--
components: Library (Lib)
messages: 361642
nosy: Dennis Sweeney
priority: normal
severity: normal
status: open
title: collections.deque.__contains__ and .count should hold strong references.
type: crash
versions: Python 3.9

___
Python tracker 

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

[issue39587] Mixin repr overrides Enum repr in some cases

[Raymond Hettinger]

Change by Raymond Hettinger :


--
assignee:  -> ethan.furman

___
Python tracker 

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

[issue39587] Mixin repr overrides Enum repr in some cases

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +barry, eli.bendersky, ethan.furman

___
Python tracker 

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

[issue39589] Logging QueueListener should support context manager

[Simon]

Change by Simon :


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

___
Python tracker 

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

[issue39589] Logging QueueListener should support context manager

[Simon]

New submission from Simon :

The QueueListener could be extended to support the context manager.

--
components: Library (Lib)
messages: 361641
nosy: sbrugman
priority: normal
severity: normal
status: open
title: Logging QueueListener should support context manager
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

___
Python tracker 

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

[issue39588] Use memcpy() instead of for() loops in _PyUnicode_To*

[Andy Lester]

Andy Lester  added the comment:

Thanks for replying. I figured that might be the case, which is why I made a 
ticket before bothering with a pull request.

I've also seen this kind of thing around:

i = ctx->pattern[0];
Py_ssize_t groupref = i+i;

instead of

Py_ssize_t groupref = ctx->pattern[0]*2;

Is that also the kind of thing we would leave for the compiler to sort out?

--

___
Python tracker 

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

[issue39573] Make PyObject an opaque structure in the limited C API

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 7f6f7eef5206858030cbe4f80a7c04b02781cc9a by Dong-hee Na in branch 
'master':
bpo-39573: Use Py_TYPE() macro in ctypes.h (GH-18411)
https://github.com/python/cpython/commit/7f6f7eef5206858030cbe4f80a7c04b02781cc9a


--

___
Python tracker 

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

[issue39588] Use memcpy() instead of for() loops in _PyUnicode_To*

[Raymond Hettinger]

Raymond Hettinger  added the comment:

In the past, we've also gotten some gains by replacing memcpy() with for-loops. 
 These kinds of optimization choices are best left to the compiler.

--
nosy: +rhettinger
resolution:  -> rejected
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

[issue39150] See if PyToken_OneChar would be faster as a lookup table

[Andy Lester]

Andy Lester  added the comment:

I'm closing this as it seems there's not much interest in this.

--
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

[issue39588] Use memcpy() instead of for() loops in _PyUnicode_To*

[Andy Lester]

New submission from Andy Lester :

Four functions in Objects/unicodectype.c copy values out of lookup tables with 
a for loop

int i;
for (i = 0; i < n; i++)
res[i] = _PyUnicode_ExtendedCase[index + i];

instead of a memcpy

memcpy(res, &_PyUnicode_ExtendedCase[index], n * sizeof(Py_UCS4));

My Apple clang version 11.0.0 on my Mac optimizes away the for loop and 
generates equivalent code to the memcpy.

gcc 4.8.5 on my Linux box (the newest GCC I have) does not optimize away the 
loop.

The four functions are:
_PyUnicode_ToLowerFull
_PyUnicode_ToTitleFull
_PyUnicode_ToUpperFull
_PyUnicode_ToFoldedFull

--
components: Unicode
messages: 361636
nosy: ezio.melotti, petdance, vstinner
priority: normal
severity: normal
status: open
title: Use memcpy() instead of for() loops in _PyUnicode_To*
type: performance

___
Python tracker 

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

[issue39587] Mixin repr overrides Enum repr in some cases

[Ryan McCampbell]

New submission from Ryan McCampbell :

In Python 3.6 the following works:

class HexInt(int):
def __repr__(self):
return hex(self)

class MyEnum(HexInt, enum.Enum):
A = 1
B = 2
C = 3

>>> MyEnum.A


However in Python 3.7/8 it instead prints
>>> MyEnum.A
0x1

It uses HexInt's repr instead of Enum's. Looking at the enum.py module it seems 
that this occurs for mixin classes that don't define __new__ due to a change in 
the _get_mixins_ method. If I define a __new__ method on the HexInt class then 
the expected behavior occurs.

--
components: Library (Lib)
messages: 361635
nosy: rmccampbell7
priority: normal
severity: normal
status: open
title: Mixin repr overrides Enum repr in some cases
type: behavior
versions: Python 3.7, Python 3.8

___
Python tracker 

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

[issue28859] os.path.ismount sometimes raises FileNotFoundError on Windows

[Nishant Misra]

Nishant Misra  added the comment:

I would like to take this issue as my first issue to start contributing to 
Python development.

--
nosy: +scic0

___
Python tracker 

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

[issue39586] Deprecate bdist_msi: use bdist_wheel instead

[Hugo van Kemenade]

Change by Hugo van Kemenade :


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

___
Python tracker 

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

[issue39586] Deprecate bdist_msi: use bdist_wheel instead

[Hugo van Kemenade]

New submission from Hugo van Kemenade :

According to the "Deprecate bdist_wininst" discussion (July 2019), bdist_msi 
can be deprecated:

https://discuss.python.org/t/deprecate-bdist-wininst/1929

Victor Stinner wrote:

"Now the question is if someone here wants to go further is deprecate all 
distutils commands except sdist and bdist_wheel? Steve Dower wants to deprecate 
bdist_msi as well: I’m not sure who use bdist_msi. It’s another form of GUI 
installer, so it’s similar to bdist_wininst. I would also strongly encourage to 
use bdist_wheel rather than bdist_msi."

Brett Cannon wrote:

"Probably a good idea, but I personally don’t have the time."

Steve Dower wrote:

"I think the others are fine to leave (though if people who work more closely 
with those tools want to say drop them then I’m fine with that too).

"bdist_msi and bdist_exe don’t integrate with any other package managers, can’t 
be integrated with any other installer besides our own Python installer, and in 
any case are worse than simply copying the files. (If we had a bdist_msm I’d be 
slightly more sympathetic, but we don’t and probably should not :) )

"I also don’t necessarily think that wheels are always the alternative, 
particularly for embedded scenarios, but I do think that the fewer options we 
provide by default will help people find the option they actually need, rather 
than assuming that because it’s “blessed” it must see correct."


And in "Remove distutils bdist_wininst command" (February 2020):

https://discuss.python.org/t/remove-distutils-bdist-wininst-command/3115

Victor Stinner wrote:

"I don’t plan to remove bdist_msi, even if wheel packages are now recommended."

Steve Dower wrote:

"We should, though. Installing a package using an MSI is worse than an EXE, as 
it leaves far more cruft behind if you don’t uninstall it before 
changing/removing the Python install.

"Standalone apps should bundle everything, like pynsist or briefcase. GPO 
deployment should create their own MSI with everything they want in the bundle 
and deploy that. Perhaps someone can make an “installer” based on the py.exe 
launcher (which I believe supports an attached zip file) that will use pip and 
a local/embedded wheel.

"But we should really discourage package installs that don’t support venv 
and/or leave cruft behind."

Victor Stinner wrote:

"If you want to see it disappear, you should start by deprecating it in Python 
3.9. It would be a first step."

PR to follow.

See also:
* https://bugs.python.org/issue37481 "Deprecate bdist_wininst: use bdist_wheel 
instead"
* https://bugs.python.org/issue39541 "distutils: Remove bdist_wininst (Windows 
.exe installers) in favor of bdist_wheel (.whl)"

--
components: Distutils, Windows
messages: 361633
nosy: dstufft, eric.araujo, hugovk, paul.moore, steve.dower, tim.golden, 
zach.ware
priority: normal
severity: normal
status: open
title: Deprecate bdist_msi: use bdist_wheel instead
versions: Python 3.9

___
Python tracker 

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

[issue39584] MacOS crashes by running attached Python code

[SilentGhost]

Change by SilentGhost :


--
nosy: +davin, vstinner

___
Python tracker 

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

[issue39585] Delete a pending item in _warning.c

[hai shi]

hai shi  added the comment:

If I am wrong, remove the check operation of `name` is fine.

--

___
Python tracker 

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

[issue39585] Delete a pending item in _warning.c

[hai shi]

Change by hai shi :


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

___
Python tracker 

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

[issue39573] Make PyObject an opaque structure in the limited C API

[STINNER Victor]

STINNER Victor  added the comment:

> "static inline" functions are not opaque

I'm well aware of that :-) But once the CPython code base will stop accessing 
directly PyObject fields directly, it would become possible to experiment 
changing PyObject layout, at least testing it in CPython.

First changes are just to prepare the code base to experiment the real change. 
But as Serhiy pointed out, the second part will have an impact on performance 
and so should be carefully benchmarked to balance advantages and drawbacks, 
even if it's only done in the limited C API.

--

___
Python tracker 

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

[issue39585] Delete a pending item in _warning.c

[hai shi]

New submission from hai shi :

a pend item could be removed 
(https://github.com/python/cpython/blob/master/Python/_warnings.c#L493).

two reasons:
1) every warning have `__name__` and it must not NULL(`The tp_name slot must be 
set;` from pep0253)
2) the `__name__` of Warning class(including children class) can not be removed.

```
>>> del UserWarning.__name__
Traceback (most recent call last):
  File "", line 1, in 
TypeError: can't set attributes of built-in/extension type 'UserWarning'
```

--
components: Interpreter Core
messages: 361630
nosy: shihai1991
priority: normal
severity: normal
status: open
title: Delete a pending item in _warning.c
versions: Python 3.9

___
Python tracker 

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

[issue39584] MacOS crashes by running attached Python code

[Vinay Sharma]

New submission from Vinay Sharma :

Consider the following python Code.

```
from multiprocessing.shared_memory import SharedMemory
shm = SharedMemory(name='test-crash', create=True, size=100)
```

This causes macOS Catalina, Mojave to freeze and then crash. Although, this 
works fine on ubuntu.

After, debugging I realised that this is due to the ftruncate call. I could 
replicate the same by calling os.ftruncate and also using ftruncate in C code.

Following C++ code also crashes, which confirms that ftruncate in macOS is 
broken:

```
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

int main() {

int shm_fd = shm_open("/test-shm2", O_CREAT | O_RDWR, 0666);

if (shm_fd == -1) {
throw "Shared Memory Object couldn't be created or opened";
}

int rv = ftruncate(shm_fd, (long long)100);

}
```

Should python, in any way handle this, so as to prevent any crashes using 
python code.

--
components: C API
messages: 361629
nosy: vinay0410
priority: normal
severity: normal
status: open
title: MacOS crashes by running attached Python code
versions: Python 3.8, Python 3.9

___
Python tracker 

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

[issue39584] MacOS crashes by running attached Python code

[Vinay Sharma]

Change by Vinay Sharma :


--
type:  -> crash

___
Python tracker 

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

[issue39583] Remove superfluous "extern C" bits from Include/cpython/*.h

[Skip Montanaro]

Change by Skip Montanaro :


--
nosy: +ncoghlan, vstinner

___
Python tracker 

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

[issue39583] Remove superfluous "extern C" bits from Include/cpython/*.h

[Skip Montanaro]

Change by Skip Montanaro :


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

___
Python tracker 

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

[issue39583] Remove superfluous "extern C" bits from Include/cpython/*.h

[Skip Montanaro]

New submission from Skip Montanaro :

I noticed that the files in Include/cpython also have extern C declarations, 
despite the fact that the only files which #include them do as well. Seems like 
a small bit of cleanup. PR incoming...

--
components: C API
messages: 361628
nosy: skip.montanaro
priority: normal
severity: normal
status: open
title: Remove superfluous "extern C" bits from Include/cpython/*.h
type: enhancement
versions: Python 3.9

___
Python tracker 

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

[issue39465] Design a subinterpreter friendly alternative to _Py_IDENTIFIER

[Nick Coghlan]

Nick Coghlan  added the comment:

As Petr notes, as long as all subinterpreters share the GIL, and share str 
instances, then the existing _Py_IDENTIFIER mechanism will work fine for both 
single phase and multi-phase initialisation.

However, that constraint also goes the other way: as long as we have modules 
that use the existing _Py_IDENTIFIER mechanism, then subinterpreters *must* 
share str instances, and hence *must* share the GIL.

Hence the "enhancement" classification: there's nothing broken right now, but 
if we're ever going to achieve the design goal of using subinterpreters to 
exploit multiple CPU cores without the overhead of running multiple full 
interpreter processes, we're going to need to design a different way of 
handling this.

Something to keep in mind with `_Py_IDENTIFIER` and any replacement API: the 
baseline for performance comparisons is 
https://docs.python.org/3/c-api/unicode.html#c.PyUnicode_InternFromString

The reason multi-phase initialisation makes this more complicated is that it 
means we can't use the memory addresses of C process globals as unique 
identifiers any more, since more than one module object may be created from the 
same C shared library.

However, if we assume we've moved to per-module state storage (to get unique 
memory addresses back), then we can largely re-use the existing 
`_Py_IDENTIFIER` machinery to make the lookup as fast as possible, while still 
avoiding conflicts between subinterpreters.

--

___
Python tracker 

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

[issue39573] Make PyObject an opaque structure in the limited C API

[Steve Dower]

Steve Dower  added the comment:

"static inline" functions are not opaque - as they get inlined into 3rd-party 
compiled code, we can't change anything they reference, and so the structure 
layout is still fixed and has to be visible to the user's compiler.

I'm not totally against the changes, but it's worth pointing out that you 
aren't achieving what the issue title claims, so it's really just code 
cleanliness (and/or introducing macro-users to static inline functions ;) ).

--
nosy: +steve.dower

___
Python tracker 

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

[issue39582] ossaudiodev update helpers signature

[David CARLIER]

Change by David CARLIER :


--
nosy: devnexen
priority: normal
pull_requests: 17786
severity: normal
status: open
title: ossaudiodev update helpers signature
versions: Python 3.9

___
Python tracker 

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

[issue31718] some methods of uninitialized io.IncrementalNewlineDecoder objects raise SystemError

[Cheryl Sabella]

Cheryl Sabella  added the comment:

The patch for this issue had some outstanding questions/changes to be made 
before being merged, but now a new PR needs to be opened to replace the 
original one.  Anyone who is interested can pick this up, but please only open 
one PR for this and please also credit the original author as per the dev 
guide.  Thank you!

--
nosy: +cheryl.sabella
versions: +Python 3.8, Python 3.9 -Python 2.7, Python 3.6, Python 3.7

___
Python tracker 

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

[issue39581] Python Interpreter Doesn't Work Well In Thread Class

[SilentGhost]

Change by SilentGhost :


--
nosy: +mark.dickinson
resolution:  -> not a bug
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

[issue39581] Python Interpreter Doesn't Work Well In Thread Class

[SilentGhost]

SilentGhost  added the comment:

SyntaxError is produced when there is a syntax problem in the code to be 
executed, this code is fine from the syntax perspective, so this particular 
error would not be raised.

It is also perfectly fine to have a function call where you have it, the only 
thing one would need to observe is that the returned value is a callable (or 
None which would be return value in your case had your function terminated). 
Perhaps there is an improvement to be made in documentation by way of giving an 
example, but the solution you're suggesting is not feasible.

--
assignee:  -> docs@python
components: +Documentation -Windows
nosy: +SilentGhost, docs@python, pitrou -mark.dickinson
resolution: not a bug -> 
stage: resolved -> 
status: closed -> open

___
Python tracker 

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

[issue39581] Python Interpreter Doesn't Work Well In Thread Class

[Mark Dickinson]

Mark Dickinson  added the comment:

There's no other reasonable way for Python to work here. It *is* an error to 
pass something that's not a callable as a thread "target", but it's a coding 
error that can only be detected at runtime, not a syntax error that can be 
detected statically before the code executes.

And because threadFunc() never returns, Python never gets the opportunity to 
check the arguments to threading.Thread: the arguments to a function call have 
to be evaluated before that function call can be made.

It is a fairly common error, though, and it might be possible for a linter to 
flag this error (though probably with a smattering of false positives and false 
negatives). That's out of scope for Python itself.

--
nosy: +mark.dickinson
resolution:  -> not a bug
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

[issue39581] Python Interpreter Doesn't Work Well In Thread Class

[임수진학부생]

New submission from 임수진학부생 <21600...@handong.edu>:


import threading
import time

def threadFunc():
while True:
print('new thread')
time.sleep(2)
def main():
th = threading.Thread(target=threadFunc())
th.start()
while True:
   print('main Thread')
   time.sleep(1)
th.join()
 
if __name__ == '__main__':
   main()
==

When I run the above code in python 3.7, it works in unexpected way.

I expected this code causes an syntax error for giving an improper argument to 
parameter because I gave "threaFunc()" not "threaFun" as an argument of target 
in Thread class. However, this code executes a function "threadFunc()" as a 
general function not thread.

--
components: Windows
messages: 361622
nosy: paul.moore, steve.dower, tim.golden, zach.ware, 임수진학부생
priority: normal
severity: normal
status: open
title: Python Interpreter Doesn't Work Well In Thread Class
type: behavior
versions: Python 3.7

___
Python tracker 

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