[issue39772] Python 2 FAQ shown in h...@python.org auto reply

[wyz23x2]

New submission from wyz23x2 :

The auto-reply from help@python contains this:

The Python FAQ is available at

http://docs.python.org/2/faq/index.html

Why is it .org/2/faq, not .org/3/faq?

--
components: email
files: email.png
messages: 362784
nosy: barry, r.david.murray, wyz23x2
priority: normal
severity: normal
status: open
title: Python 2 FAQ shown in h...@python.org auto reply
Added file: https://bugs.python.org/file48919/email.png

___
Python tracker 

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

[issue38112] Compileall improvements

[Gregory P. Smith]

Gregory P. Smith  added the comment:

https://bugs.python.org/issue39769 may be of interest.  compileall's ddir= does 
not behave properly in recursive subdirectories, it did the right thing in 2.7 
which is similar to a combination of compile_dir(dir, prependdir=ddir, 
stripdir=dir) after this issue's feature.

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

[issue39769] compileall.compile_dir(..., ddir="") omits the intermediate package paths when prepending the prefix

[Gregory P. Smith]

Gregory P. Smith  added the comment:

Ironically 3.9a4 gains some compileall enhancements that could be used as an 
awkward workaround from https://bugs.python.org/issue38112:

python 2.7 compile_dir(d, ddir="") behavior can be had with
python 3.9a4 compile_dir(d, prependdir="", stripdir=d)

I still intend to fix the actual ddir behavior as it is wrong.

--

___
Python tracker 

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

[issue39771] EmailMessage.add_header doesn't work

[hwgdb Smith]

hwgdb Smith  added the comment:

"but msg.as_string() doesn't change. " , I mean using 

  filename=file_name  
or
  filename=("GBK", "", f"{file_name}")
or
  filename=("utf-8", "", f"{file_name}")

msg.as_string() doesn't change.

--

___
Python tracker 

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

[issue39771] EmailMessage.add_header doesn't work

[hwgdb Smith]

New submission from hwgdb Smith :

here is the partial code:
msg = EmailMessage()
file_name = "超e保3000P.csv"
ctype, encoding = mimetypes.guess_type(file_name)
if ctype is None or encoding is not None:
ctype = "application/octet-stream"
maintype, subtype = ctype.split("/", 1)

with open(file_name, "rb") as f:
msg.add_attachment(f.read(), maintype=maintype, subtype=subtype, 
filename=("GBK", "", f"{file_name}"))


The file has non-ascii characters name, so I use the three tuple filename with 
encode GBK, but msg.as_string() doesn't change. 
print(msg.as_string()) I find the filename is  'filename*=utf-8\'\'%E8%B6 
..'. The encoding is not correct. And of course, after send the message, I 
saw the attached file's filename displayed incorrect on my mail client or web 
mail.
But when i use the legacy API, and using the Header class to generate the 
filename, it works.

--
components: email
messages: 362780
nosy: barry, hwgdb Smith, r.david.murray
priority: normal
severity: normal
status: open
title: EmailMessage.add_header doesn't work
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

[issue36144] Dictionary union. (PEP 584)

[Brandt Bucher]

Brandt Bucher  added the comment:

> I think for `|=` the only choice is for it to be essentially an alias to 
> `.update()`. So that means `cm |= other` becomes `cm.maps[0].update(other)`.

Agreed.

> These semantics make `|=` behave rather differently from `|`. Is that okay? 
> If not, which of them should change, and how?

I don’t like this. Let me try to explain why:

So far (and to the best of my knowledge), setting and updating values on a 
ChainMap works exactly the same as it does for dict, with all of the same 
semantics (the docs themselves even say that “all of the usual dictionary 
methods are supported”… which now could be interpreted as meaning | and |= as 
well). It’s only when deleting or using the new interfaces that things get more 
specialized.

But that doesn’t really apply here. Having different (or worse, inconsistent) 
behavior for these operators, I feel, would be more confusing than helpful. 
Remember, a major goal of this proposal is to aid in duck typing.

So, Josh’s understanding of my intended semantics is correct, I propose that, 
for:

d1 = {'a': 1, 'b': 2}
d2 = {'b': 3, 'c': 4}
d3 = {'a': 5, 'd': 6}
d4 = {'d': 7, 'e': 8}
cm1 = ChainMap(d1, d2)
cm2 = ChainMap{d3, d4)

cm3 = cm1 | cm2

Gives cm3 a value of:

ChainMap(d1 | d4 | d3, d2)  # Or, equivalently: ChainMap(d1 | dict(cm2), d2)

And:

cm1 |= cm2

Is equivalent to:

d1 |= cm2

I don’t want to change which map is "first", and I think changing the winning 
behavior from that of dict will create more problems than it solves. We only 
need to look at how ChainMap handles the update method… it keeps the same exact 
behavior, rather than trying to be lazy or reversed or something.

If we *are* deciding to do something different, then I think it should have no 
relationship to PEP 584, which reasons out a carefully considered merge 
operation for dict, not ChainMap. But, it would also probably need a different 
operator, and be able to stand on its own merits.

--

___
Python tracker 

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

[issue39768] remove tempfile.mktemp()

[wyz23x2]

Change by wyz23x2 :


--
nosy:  -ZackerySpytz

___
Python tracker 

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

[issue39770] Remove unnecessary size calculation in array_modexec in Modules/arraymodule.c

[Andy Lester]

Change by Andy Lester :


--
pull_requests:  -18035

___
Python tracker 

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

[issue39770] Remove unnecessary size calculation in array_modexec in Modules/arraymodule.c

[Andy Lester]

Change by Andy Lester :


--
pull_requests: +18035
pull_request: https://github.com/python/cpython/pull/18673

___
Python tracker 

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

[issue39770] Remove unnecessary size calculation in array_modexec in Modules/arraymodule.c

[Andy Lester]

Change by Andy Lester :


--
pull_requests: +18034
pull_request: https://github.com/python/cpython/pull/18674

___
Python tracker 

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

[issue39770] Remove unnecessary size calculation in array_modexec in Modules/arraymodule.c

[Andy Lester]

Change by Andy Lester :


--
pull_requests:  -18034

___
Python tracker 

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

[issue39768] remove tempfile.mktemp()

[wyz23x2]

wyz23x2  added the comment:

Reopen.
1.See https://mail.python.org/pipermail/python-dev/2019-March/156765.html and 
https://owasp.org/www-community/vulnerabilities/Insecure_Temporary_File. It's 
*serious*.
2.Why not use this to generate a
temporary name that an other program will create/act on?
import secrets
path = f"{x}{secrets.token_hex(n)}" # n is an large int
# x is a path like "/tmp"
# do something...

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

___
Python tracker 

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

[issue39770] Remove unnecessary size calculation in array_modexec in Modules/arraymodule.c

[Andy Lester]

Change by Andy Lester :


--
pull_requests:  -18032

___
Python tracker 

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

[issue39770] Remove unnecessary size calculation in array_modexec in Modules/arraymodule.c

[Andy Lester]

Change by Andy Lester :


--
pull_requests:  -18031

___
Python tracker 

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

[issue39770] Remove unnecessary size calculation in array_modexec in Modules/arraymodule.c

[Andy Lester]

Change by Andy Lester :


--
pull_requests: +18033
pull_request: https://github.com/python/cpython/pull/18675

___
Python tracker 

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

[issue39768] remove tempfile.mktemp()

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Remove tempfile.mktemp()

___
Python tracker 

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

[issue39768] remove tempfile.mktemp()

[wyz23x2]

wyz23x2  added the comment:

Sorry, in (a)(b) is should be with "open(mktemp(),'x') as f:".

--

___
Python tracker 

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

[issue39768] remove tempfile.mktemp()

[wyz23x2]

wyz23x2  added the comment:

I know it's hard to achieve :)

--

___
Python tracker 

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

[issue39768] remove tempfile.mktemp()

[wyz23x2]

wyz23x2  added the comment:

case c is used for the case that is stated in 
https://mail.python.org/pipermail/python-dev/2019-March/156725.html (a
temporary name that an other program will create / act on).

--

___
Python tracker 

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

[issue39770] Remove unnecessary size calculation in array_modexec in Modules/arraymodule.c

[Andy Lester]

Change by Andy Lester :


--
pull_requests: +18032
pull_request: https://github.com/python/cpython/pull/18674

___
Python tracker 

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

[issue36144] Dictionary union. (PEP 584)

[Guido van Rossum]

Guido van Rossum  added the comment:

I think for `|=` the only choice is for it to be essentially an alias to 
`.update()`. So that means `cm |= other` becomes `cm.maps[0].update(other)`.

For `|` we are breaking new ground and we could indeed make `cm | other` do 
something like `ChainMap(other, *cm.maps)`.

I've not used ChainMap much (though I've seen some code that uses it) so I'm 
probably not the best judge of whether this is a good feature to have.

Note that `other | cm` will just do whatever `other.__or__` does, since 
ChainMap isn't a true subclass of dict, so it will not fall back to 
`cm.__ror__`. Basically ChainMap will not get control in this case.

Other thoughts:

- Maybe `cm1 | cm2` (both ChainMaps) ought to return `ChainMap(*cm2.maps, 
*cm1.maps)`?

- These semantics make `|=` behave rather differently from `|`. Is that okay? 
If not, which of them should change, and how?

--

___
Python tracker 

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

[issue39770] Remove unnecessary size calculation in array_modexec in Modules/arraymodule.c

[Andy Lester]

Change by Andy Lester :


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

___
Python tracker 

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

[issue39768] remove tempfile.mktemp()

[wyz23x2]

wyz23x2  added the comment:

(c)
from tempfile import mktemp
# do something...
path = mktemp()
# do something... (the "path" var is not used at all)

## No Warning

--

___
Python tracker 

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

[issue39770] Remove unnecessary size calculation in array_modexec in Modules/arraymodule.c

[Andy Lester]

New submission from Andy Lester :

The array_modexec function in Modules/arraymodule.c has a loop that calculates 
the number of elements in the descriptors array.  This size was used at one 
point, but is no longer.  The loop can be removed.

--
components: Interpreter Core
messages: 362772
nosy: petdance
priority: normal
severity: normal
status: open
title: Remove unnecessary size calculation in array_modexec in 
Modules/arraymodule.c

___
Python tracker 

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

[issue39768] remove tempfile.mktemp()

[wyz23x2]

wyz23x2  added the comment:

You could add a check that does this:
(a)
from tempfile import mktemp
with open(mktemp()) as f:
# do something...

## No Warnings
(b)
from tempfile import mktemp
path = mktemp()
# do something...
with open(mktemp()) as f:
# do something...

## RuntimeWarning: mktemp() is unsafe. Use NamedTemporaryFile(delete=False).

--

___
Python tracker 

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

[issue39768] remove tempfile.mktemp()

[wyz23x2]

wyz23x2  added the comment:

But I think the function should redirect to NamedTemporaryFile(delete=False).

--

___
Python tracker 

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

[issue39768] remove tempfile.mktemp()

[wyz23x2]

wyz23x2  added the comment:

Sorry, didn't realize that.

--

___
Python tracker 

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

[issue39769] compileall.compile_dir(..., ddir="") omits the intermediate package paths when prepending the prefix

[Gregory P. Smith]

Gregory P. Smith  added the comment:

This has probably been happening for many 3 releases.  I noticed it on 3.6 when 
investigating a problem with wrong paths in tracebacks coming from code which 
we used compileall.compile_dir(src_root, quiet=1, ddir=") on.

I'm guessing ddir= (-d on the cli) isn't widely used?

--
components: +Library (Lib)
stage:  -> needs patch
type:  -> behavior

___
Python tracker 

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

[issue39769] compileall.compile_dir(..., ddir="") omits the intermediate package paths when prepending the prefix

[Gregory P. Smith]

New submission from Gregory P. Smith :

Easiest to demonstrate as such:

```shell
#!/bin/bash

mkdir bug
touch bug/__init__.py
mkdir bug/foo
touch bug/foo/__init__.py
touch bug/foo/bar.py

python3 -m compileall -d "" bug
python2 -m compileall -d "" bug

echo "prefix embedded in PY3 pyc code object for lib.foo.bar:"
strings bug/foo/__pycache__/bar.cpython-3*.pyc | grep prefix
echo "prefix embedded in PY2 pyc code object for lib.foo.bar:"
strings bug/foo/bar.pyc | grep prefix
```

Run that script and you'll see:
Listing 'bug'...
Compiling 'bug/__init__.py'...
Listing 'bug/foo'...
Compiling 'bug/foo/__init__.py'...
Compiling 'bug/foo/bar.py'...
Listing bug ...
Compiling bug/__init__.py ...
Listing bug/__pycache__ ...
Listing bug/foo ...
Compiling bug/foo/__init__.py ...
Listing bug/foo/__pycache__ ...
Compiling bug/foo/bar.py ...
prefix embedded in PY3 pyc code object for lib.foo.bar:
/bar.py
prefix embedded in PY2 pyc code object for lib.foo.bar:
/foo/bar.pyt


Notice that the Python 3 pyc file contains a code.co_filename of 
"/bar.py" instead of the correct value (that Python 2 inserts) of 
"/foo/bar.py".

--
messages: 362767
nosy: gregory.p.smith
priority: normal
severity: normal
status: open
title: compileall.compile_dir(..., ddir="") omits the intermediate 
package paths when prepending the prefix
versions: 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

[issue39087] [C API] No efficient C API to get UTF-8 string from unicode object.

[Inada Naoki]

Inada Naoki  added the comment:


New changeset 02a4d57263a9846de35b0db12763ff9e7326f62c by Inada Naoki in branch 
'master':
bpo-39087: Optimize PyUnicode_AsUTF8AndSize() (GH-18327)
https://github.com/python/cpython/commit/02a4d57263a9846de35b0db12763ff9e7326f62c


--

___
Python tracker 

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

[issue37497] Add inspect.Signature.from_text().

[Yury Selivanov]

Yury Selivanov  added the comment:

What's the actual use case for exposing this functionality?

--

___
Python tracker 

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

[issue39768] remove tempfile.mktemp()

[Zackery Spytz]

Zackery Spytz  added the comment:

I think this is a duplicate of bpo-36309.

--
nosy: +ZackerySpytz

___
Python tracker 

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

[issue39768] remove tempfile.mktemp()

[wyz23x2]

Change by wyz23x2 :


--
components: +Library (Lib)

___
Python tracker 

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

[issue39768] remove tempfile.mktemp()

[wyz23x2]

wyz23x2  added the comment:

A small typo in the 1st comment:
The tempfile.mktemp() function was deprecated since version 2.3; it's long ago 
(nearly 17 years!). It should be removed since it causes security holes, as 
stated in the tempfile doc 
(https://docs.python.org/3/library/tempfile.html#tempfile.mktemp).

--

___
Python tracker 

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

[issue39768] remove tempfile.mktemp()

[wyz23x2]

New submission from wyz23x2 :

the tempfile.mktemp() function was deprecated since version 2.3; it's long ago 
(nearly 17 years)! It should be removed since it causes security holes, as 
stated in the tempfile doc 
(https://docs.python.org/3/library/tempfile.html#tempfile.mktemp).

--
components: IO
messages: 362762
nosy: wyz23x2
priority: normal
severity: normal
status: open
title: remove tempfile.mktemp()
type: security
versions: 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

[issue36144] Dictionary union. (PEP 584)

[Josh Rosenberg]

Josh Rosenberg  added the comment:

Sorry, I think I need examples to grok this in the general case. ChainMap 
unioned with dict makes sense to me (it's equivalent to update or 
copy-and-update on the top level dict in the ChainMap). But ChainMap unioned 
with another ChainMap is less clear. Could you give examples of what the 
expected end result is for:

d1 = {'a': 1, 'b': 2}
d2 = {'b': 3, 'c': 4}
d3 = {'a': 5, 'd': 6}
d4 = {'d': 7, 'e': 8}
cm1 = ChainMap(d1, d2)
cm2 = ChainMap{d3, d4)

followed by either:

cm3 = cm1 | cm2

or
cm1 |= cm2

? As in, what is the precise state of the ChainMap cm3 or the mutated cm1, 
referencing d1, d2, d3 and d4 when they are still incorporated by references in 
the chain?

My impression from what you said is that the plan would be for the updated cm1 
to preserve references to d1 and d2 only, with the contents of cm2 (d3 and d4) 
effectively flattened and applied as an in-place update to d1, with an end 
result equivalent to having done:

cm1 = ChainMap(d1, d2)
d1 |= d4
d1 |= d3

(except the key ordering would actually follow d3 first, and d4 second), while 
cm3 would effectively be equivalent to having done (note ordering):

cm3 = ChainMap(d1 | d4 | d3, d2)

though again, key ordering would be based on d1, then d3, then d4, not quite 
matching the union behavior. And a reference to d2 would be preserved in the 
final result, but not any other original dict. Is that correct? If so, it seems 
like it's wasting ChainMap's key feature (lazy accumulation of maps), where:

cm1 |= cm2

could be equivalent to either:

cm1.maps += cm2.maps

though that means cm1 wins overlaps, where normal union would have cm2 win, or 
to hew closer to normal union behavior, make it equivalent to:

cm1.map[:0] = cm2.maps

prepending all of cm2's maps to have the same duplicate handling rules as 
regular dicts (right side wins) at the expense of changing which map cm1 uses 
as the target for writes and deletes. In either case it would hew to the spirit 
of ChainMap, making dict "union"-ing an essentially free operation, in exchange 
for increasing the costs of lookups that don't hit the top dict.

--

___
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

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Thanks Andrés.  

I'm going to close this one as it has been open for a long time and not 
attracted interest.  Also, in practice this ambiguity doesn't seem to be an 
issue and people almost universally refer to anything usable with the 
@-notation as a decorator.  Further, it has become common for tooling such as 
@lru_cache and @dataclass to be usable both with and without arguments, so the 
distinction no longer makes sense in some cases.

--
nosy: +rhettinger
resolution:  -> out of date
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

[issue36144] Dictionary union. (PEP 584)

[Brandt Bucher]

Brandt Bucher  added the comment:

The plan is to follow dict’s semantics. The |= operator will basically delegate 
to the first map in the chain. The | operator will create a new ChainMap where 
the first map is the merged result of the old first map, and the others are the 
same.

So, basically update / copy-and-update, respectively.

--

___
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

[Andrés Delfino]

Andrés Delfino  added the comment:

Hi, no I'm no longer working on this.

--

___
Python tracker 

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

[issue36144] Dictionary union. (PEP 584)

[Josh Rosenberg]

Josh Rosenberg  added the comment:

What is ChainMap going to do? Normally, the left-most argument to ChainMap is 
the "top level" dict, but in a regular union scenario, last value wins. 

Seems like layering the right hand side's dict on top of the left hand side's 
would match dict union semantics best, but it feels... wrong, given ChainMap's 
normal left-to-right precedence. And top-mostness affects which dict receives 
all writes, so if  chain1 |= chain2 operates with dict-like precedence (chain2 
layers over chain1), then that also means the target of writes/deletions/etc. 
changes to what was on top in chain2.

--

___
Python tracker 

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

[issue38597] C Extension import limit

[Xinfa Zhu]

Xinfa Zhu  added the comment:

I have had wheel installed. Following this SO answer 
(https://stackoverflow.com/a/50314071/7269441), I added "import setuptools" 
before distutils (my setup.py attached).

Following is the log, where we see the VS path it is using. BTW, I am trying to 
reduce my package to <120 modules and test it.

(base) 
C:\Users\xinfa\Documents\code\ezcad-dev\beta>C:\Users\xinfa\AppData\Local\Continuum\anaconda3\python.exe
 setup.py build_ext
Include directory: C:\Users\xinfa\Documents\code\ezcad-dev\beta
Number of ext modules = 225
running build_ext
building 'ezcad.__main__' extension
C:\Program Files (x86)\Microsoft Visual 
Studio\2019\BuildTools\VC\Tools\MSVC\14.24.28314\bin\HostX86\x64\cl.exe /c 
/nologo /Ox /W3 /GL /DNDEBUG /MT -IC:\Users\xinfa\Documents\code\ezcad-dev\beta 
-I. -IC:\Users\xinfa\AppData\Loca
l\Continuum\anaconda3\include 
-IC:\Users\xinfa\AppData\Local\Continuum\anaconda3\include "-IC:\Program Files 
(x86)\Microsoft Visual 
Studio\2019\BuildTools\VC\Tools\MSVC\14.24.28314\include" "-IC:\Program Files 
(x86)\Windows Kits
\10\include\10.0.18362.0\ucrt" "-IC:\Program Files (x86)\Windows 
Kits\10\include\10.0.18362.0\shared" "-IC:\Program Files (x86)\Windows 
Kits\10\include\10.0.18362.0\um" "-IC:\Program Files (x86)\Windows 
Kits\10\include\10.0.1836
2.0\winrt" "-IC:\Program Files (x86)\Windows 
Kits\10\include\10.0.18362.0\cppwinrt" /Tcezcad\__main__.c 
/Fobuild\temp.win-amd64-3.7\Release\ezcad\__main__.obj
__main__.c
C:\Program Files (x86)\Microsoft Visual 
Studio\2019\BuildTools\VC\Tools\MSVC\14.24.28314\bin\HostX86\x64\link.exe 
/nologo /INCREMENTAL:NO /LTCG /nodefaultlib:libucrt.lib ucrt.lib /DLL 
/MANIFEST:EMBED,ID=2 /MANIFESTUAC:NO /LIBPAT
H:C:\Users\xinfa\AppData\Local\Continuum\anaconda3\libs 
/LIBPATH:C:\Users\xinfa\AppData\Local\Continuum\anaconda3\PCbuild\amd64 
"/LIBPATH:C:\Program Files (x86)\Microsoft Visual 
Studio\2019\BuildTools\VC\Tools\MSVC\14.24.28314\l
ib\x64" "/LIBPATH:C:\Program Files (x86)\Windows 
Kits\10\lib\10.0.18362.0\ucrt\x64" "/LIBPATH:C:\Program Files (x86)\Windows 
Kits\10\lib\10.0.18362.0\um\x64" 
build\temp.win-amd64-3.7\Release\ezcad\__main__.obj /OUT:build\lib.win
-amd64-3.7\ezcad\__main__.cp37-win_amd64.pyd
   Creating library build\lib.win-amd64-3.7\ezcad\__main__.cp37-win_amd64.lib 
and object build\lib.win-amd64-3.7\ezcad\__main__.cp37-win_amd64.exp
Generating code
Finished generating code
version = 0.1.9

--
versions: +Python 3.7 -Python 3.6
Added file: https://bugs.python.org/file48918/setup.py

___
Python tracker 

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

[issue39699] Some CIs silence potentially useful output from make

[Steve Dower]

Steve Dower  added the comment:

Had to disable the doctests in the 3.7 branch because I just couldn't get them 
passing. Pablo did the work for 3.8 and later though, so they're on for those.

--
resolution:  -> fixed
stage: patch review -> 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

[issue39767] create multiprocessing.SharedMemory by pointing to existing memoryview

[Dariusz Trawinski]

New submission from Dariusz Trawinski :

Currently, in order to share numpy array between processes via 
multiprocessing.SharedMemory object, it is required to copy the memory content 
with:
input = np.ones((1,10,10,10))
shm = shared_memory.SharedMemory(create=True, size=input.nbytes)
write_array = np.ndarray(input.shape, dtype=input.dtype,buffer=shm.buf)
write_array1[:] = input[:]
In result the original numpy array is duplicated in RAM. It also adds extra cpu 
cycles to copy the content.

I would like to recommend adding an option to create shared memory object by 
pointing it to existing memoryview object, beside current method of using 
shared memory name. 
Is that doable?

--
components: C API
messages: 362754
nosy: Dariusz Trawinski
priority: normal
severity: normal
status: open
title: create multiprocessing.SharedMemory by pointing to existing memoryview
type: performance
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

[issue39766] unittest's assertRaises removes locals from tracebacks

[daniel hahler]

daniel hahler  added the comment:

The test for issue9815 passes since bbd3cf8f1e (bpo-23890).

It seems like `traceback.clear_frames(tb)` should probably removed altogether?

--
nosy: +vstinner

___
Python tracker 

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

[issue39763] distutils.spawn should use subprocess (hang in parallel builds on QNX)

[Guido van Rossum]

Guido van Rossum  added the comment:

When I run this on macOS, either with the bug, or with the buggy line commented 
out, I get the same hang. When I interrupt it, I get
 a separate traceback from each thread. Here's the full session:

Parent 78918
Parent 78919
Child 78918
Parent 78920
Child 78919
Parent 78921
Child 78920
Child 78921
  C-c C-cTraceback (most recent call last):
  File "tt.py", line 18, in 
fut.result()
  File "/usr/local/lib/python3.8/concurrent/futures/_base.py", line 434, in 
result
self._condition.wait(timeout)
  File "/usr/local/lib/python3.8/threading.py", line 302, in wait
waiter.acquire()
KeyboardInterrupt
Exception in worker
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/concurrent/futures/thread.py", line 78, in 
_worker
work_item = work_queue.get(block=True)
KeyboardInterrupt
Exception in worker
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/concurrent/futures/thread.py", line 78, in 
_worker
work_item = work_queue.get(block=True)
KeyboardInterrupt
Exception in worker
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/concurrent/futures/thread.py", line 78, in 
_worker
work_item = work_queue.get(block=True)
KeyboardInterrupt
Exception in worker
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/concurrent/futures/thread.py", line 78, in 
_worker
work_item = work_queue.get(block=True)
KeyboardInterrupt
Done 78918 78917
Done 78921 78917
Done 78919 78917
Done 78920 78917

(I added some prints to the script. Here's the script I ran:)

import os
from concurrent.futures import ThreadPoolExecutor

def new_process(arg):
pid = os.fork()
if pid == 0:
print("Child", os.getpid())
## os.execl("/usr/bin/true", "/usr/bin/true")
else:
print("Parent", pid)
pid, status = os.waitpid(pid, 0)
print("Done", pid, os.getpid())

executor = ThreadPoolExecutor(max_workers=4)
futures = [executor.submit(new_process, None)
   for i in range(0, 4)]
for fut in futures:
fut.result()

When I uncomment the os.execl() line, the program runs and completes.

--

___
Python tracker 

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

[issue39622] KeyboardInterrupt is ignored when await asyncio.sleep(0)

[Maor Kleinberger]

Maor Kleinberger  added the comment:

I have pushed an update to my PR. While implementing the new solution I made 
the following list:

Examples for code segments where KeyboardInterrupt must not be raised:
 - Between popping and running a handle from the ready queue (a handle is lost)
 - After running a handle and before a subsequent call_soon finished running 
(the handle that should have been added by call_soon is lost)
 - After a handle is popped from the _scheduled heap and added to the _ready 
queue (a handle is lost)

Code segments where KeyboardInterrupt must be raised:
 - During the select call (can be achieved using signal.default_int_handler or 
signal.set_wakeup_fd)
 - During a running callback (can be achieved using signal.default_int_handler)

I think that while the loop is running, the signal handler should not raise a 
KeyboardInterrupt by default, as there are at least 3 unsafe code segments, and 
more might be added in the future. Currently, the only two segments that have 
to be directly interrupted by a SIGINT are the ones listed above, and I think 
this behavior should be allowed explicitly.
This is what I did in the new revision of my PR.

--

___
Python tracker 

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

[issue39761] Python 3.9.0a4 fails to build when configured with --with-dtrace

[David CARLIER]

Change by David CARLIER :


--
keywords: +patch
nosy: +devnexen
nosy_count: 4.0 -> 5.0
pull_requests: +18029
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18672

___
Python tracker 

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

[issue39765] asyncio loop.add_signal_handler() may not behave as expected

[Roger Dahl]

Roger Dahl  added the comment:

> I'm sorry. but loop.set_signal_handler() method doesn't exist.

Oops, fixed.

> Assuming you mean loop.add_signal_handler() method, I would say that a 
> minute-long delay is a sign of long blocking calls in your program.

During the delay for the callback to occur, I see my program logging work 
performed on other asyncio tasks and receiving timer events from another 
thread. So, not long blocking?

--

___
Python tracker 

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

[issue39762] PyLong_AS_LONG missing from longobject.h

[Enji Cooper]

Enji Cooper  added the comment:

PyInt_AS_LONG doesn't exist on python 3, however:

$ grep -r PyInt_AS_LONG /usr/include/
[/usr/include/python2.7/intobject.h:#define PyInt_AS_LONG(op) (((PyIntObject 
*)(op))->ob_ival)

The code smell for the pieces that use PyInt_AS_LONG seems a bit questionable 
since they're used as array indexes; I'll poke a bit more and look at using one 
of the other sets of C APIs instead in our project.

--

___
Python tracker 

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

[issue39765] asyncio loop.add_signal_handler() may not behave as expected

[Andrew Svetlov]

Andrew Svetlov  added the comment:

Assuming you mean loop.add_signal_handler() method, I would say that a 
minute-long delay is a sign of long blocking calls in your program.

Typical asyncio program blocks the loop for 1-10 milliseconds at most, and 
signal handlers are called with this delay.
This is not your case as I see.

--
title: asyncio loop.set_signal_handler() may not behave as expected -> asyncio 
loop.add_signal_handler() may not behave as expected

___
Python tracker 

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

[issue39765] asyncio loop.set_signal_handler() may not behave as expected

[Andrew Svetlov]

Andrew Svetlov  added the comment:

I'm sorry. but loop.set_signal_handler() method doesn't exist.

--

___
Python tracker 

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

[issue38884] __import__ is not thread-safe on Python 3

[Ryan Petrello]

Ryan Petrello  added the comment:

I believe I'm also encountering some version of this bug while importing code 
from the kombu library within a multi-threaded context.

For what it's worth, I'm able to reproduce the reported deadlock 
(https://bugs.python.org/file48737/issue38884.zip) using python3.8 on RHEL8 and 
CentOS 8 builds.

More details about what I'm encountering here: 
https://github.com/ansible/awx/issues/5617
https://github.com/ansible/awx/issues/5617#issuecomment-591618205

My intended workaround for now is to just not use a thread (we'll see if it 
helps):

https://github.com/ansible/awx/pull/6093

--
nosy: +ryan.petrello

___
Python tracker 

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

[issue39699] Some CIs silence potentially useful output from make

[Steve Dower]

Steve Dower  added the comment:


New changeset 3bf9de2fb954bd1131f4f41517d7d5c316fb95f8 by Steve Dower in branch 
'3.7':
bpo-39699: Don't silence make on Azure and Github CIs (GH-18583)
https://github.com/python/cpython/commit/3bf9de2fb954bd1131f4f41517d7d5c316fb95f8


--

___
Python tracker 

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

[issue39766] unittest's assertRaises removes locals from tracebacks

[daniel hahler]

New submission from daniel hahler :

I was a bit surprised to find that unittest's assertRaises clears the locals on 
the traceback, which e.g. prevents pytest to display them in case of failures.

This was done via https://bugs.python.org/issue9815 
(https://github.com/python/cpython/commit/9681022f1ee5c6c9160c515b24d2a3d1efe8b90d).

Maybe this should only get done for expected failures, so that unexpected 
exceptions can be inspected better?

--
components: Library (Lib)
messages: 362744
nosy: blueyed
priority: normal
severity: normal
status: open
title: unittest's assertRaises removes locals from tracebacks
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

[issue39763] distutils.spawn should use subprocess (hang in parallel builds on QNX)

[Elad Lahav]

Elad Lahav  added the comment:

"Your script contains a bug (there is no definition of 'exec_fn')"

Told you I wasn't much of a Python developer ;-) 
This was just copy-pasted from spawn.py and I missed the fact that exec_fn() is 
not a library function.

Your last comment wasn't clear - do you see this problem on macOS? Is it only 
after you fixed the example? For me it hangs with the bug, as the problem 
occurs before the call to exec_fn().

--

___
Python tracker 

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

[issue27657] urlparse fails if the path is numeric

[Ned Deily]

Ned Deily  added the comment:

FYI, for those following along, now that 3.8.2 has been released with the 
revert of the regression, we are planning to accelerate the schedule for 3.7.7, 
the next 3.7.x bugfix release, in part to get the revert out to 3.7.x users 
sooner 
(https://discuss.python.org/t/3-7-7-schedule-accelerated-cutoff-now-2020-03-02/3511).

--

___
Python tracker 

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

[issue39760] ast.FormattedValue.format_spec unnecessarily wrapped in JoinedStr

[Eric V. Smith]

Eric V. Smith  added the comment:

> FYI you can use ast CLI:

I did not know that. That's awesome, thanks for pointing it out.

--

___
Python tracker 

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

[issue36144] Dictionary union. (PEP 584)

[Brandt Bucher]

Brandt Bucher  added the comment:

Yep. I'm currently working on OrderedDict, defaultdict, and MappingProxyType.

My brother is looking to make his first contribution, so he'll be taking care 
of ChainMap.

--

___
Python tracker 

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

[issue39761] Python 3.9.0a4 fails to build when configured with --with-dtrace

[Miro Hrončok]

Miro Hrončok  added the comment:

Oh, my bad.

DFLAGS=" "

^ that indeed works.

--

___
Python tracker 

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

[issue39758] StreamWriter.wait_closed() can hang indefinitely.

[Julien Palard]

Julien Palard  added the comment:

Can reproduce in:

- 3.8.0
- 3.8.2
- 3.7.6

--
nosy: +mdk

___
Python tracker 

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

[issue39761] Python 3.9.0a4 fails to build when configured with --with-dtrace

[David Carlier]

David Carlier  added the comment:

If it works for you, it might mean making a specific case for Linux systems in 
configure.ac as a proper fix.

--

___
Python tracker 

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

[issue38066] Hide internal asyncio.Stream methods

[tzickel]

tzickel  added the comment:

The documentation needs to scrub this methods as well, for example:

https://docs.python.org/3/library/asyncio-stream.html#asyncio.StreamReader.at_eof

still mentions them.

--
nosy: +tzickel

___
Python tracker 

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

[issue39761] Python 3.9.0a4 fails to build when configured with --with-dtrace

[David Carlier]

David Carlier  added the comment:

ah sorry I meant DFLAGS=" " (with a space).

--

___
Python tracker 

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

[issue39765] asyncio loop.set_signal_handler() may not behave as expected

[Roger Dahl]

Change by Roger Dahl :


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

___
Python tracker 

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

[issue39765] asyncio loop.set_signal_handler() may not behave as expected

[Roger Dahl]

New submission from Roger Dahl :

This is a ticket to document two ways in which the behavior of 
loop.set_signal_handler() may not match what the user expects.

First, callbacks to handlers registered with loop.set_signal_handler() may be 
significantly delayed. I have a program where I've encountered delays of up to 
maybe a minute or so between hitting Ctrl-C and getting the callback for the 
SIGINT handler. During this time, the program works through queued aiohttp 
tasks. Though it's possible to have delays in callbacks for events set with 
signal.signal(), I haven't personally seen that, and I think that's the case 
for most users. So I think this point should be included in the docs.

Second, set_signal_handler() silently and implicitly removes corresponding 
handlers set with signal.signal(). Though perhaps logical, this potentially 
removes a "fast" handler and replaces it with a "slow" one. I think this should 
be documented as well.

--
components: asyncio
messages: 362734
nosy: asvetlov, rogerdahl, yselivanov
priority: normal
severity: normal
status: open
title: asyncio loop.set_signal_handler() may not behave as expected
type: behavior
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

[issue39761] Python 3.9.0a4 fails to build when configured with --with-dtrace

[Miro Hrončok]

Miro Hrončok  added the comment:

$ make clean && make distclean
$ git clean -x
$ export DFLAGS=""
$ export DFFLAGS=""
$ ./configure --with-dtrace && make
...
undefined reference to `python_audit_semaphore'
...

--

___
Python tracker 

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

[issue39763] distutils.spawn should use subprocess (hang in parallel builds on QNX)

[Guido van Rossum]

Guido van Rossum  added the comment:

@Antoine: I can sort of see why you consider the small example a red herring, 
since it mixes threads and fork. Nevertheless, a simpler version (not using an 
executor) would probably work just fine? It's the edge cases where the mixture 
becomes explosive. So I still think there's something that could be improved in 
ThreadPoolExecutor.

@Elad: Your script contains a bug (there is no definition of 'exec_fn'). But 
anything that returns or raises from the child process does indeed hang.

Since I can repro this on macOS I do QNX is a red herring here.

--

___
Python tracker 

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

[issue39763] distutils.spawn should use subprocess (hang in parallel builds on QNX)

[Elad Lahav]

Elad Lahav  added the comment:

I'm not convinced that a multi-threaded fork()+exec() from C would be any 
better, unless the Python code goes to great lengths to avoid any 
non-async-signal-safe operations between the fork() and the exec().
So along with the proposed change to switch to the subprocess() module I would 
like to propose that that module switch to using posix_spawn() instead of 
fork()+exec().

--
type: behavior -> 
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

[issue22947] Enable 'imageop' - "Multimedia Srvices Feature module" for 64-bit platform

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Python 2.7 no longer supported.

--
nosy: +serhiy.storchaka
resolution:  -> out of date
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

[issue39763] distutils.spawn should use subprocess (hang in parallel builds on QNX)

[Antoine Pitrou]

Change by Antoine Pitrou :


--
nosy: +dstufft, eric.araujo, p-ganssle, vstinner

___
Python tracker 

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

[issue39763] distutils.spawn should use subprocess (hang in parallel builds on QNX)

[Antoine Pitrou]

Change by Antoine Pitrou :


--
title: Hang after fork due to logging trying to reacquire the module lock in an 
atfork() handler -> distutils.spawn should use subprocess (hang in parallel 
builds on QNX)

___
Python tracker 

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

[issue36144] Dictionary union. (PEP 584)

[Guido van Rossum]

Guido van Rossum  added the comment:

@Brandt: you have some more followup PRs planned right? Let's keep this issue 
open until you've done all of those.

--

___
Python tracker 

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

[issue39763] Hang after fork due to logging trying to reacquire the module lock in an atfork() handler

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Note the original problem stems when you using "setup.py -j ".

The attached reproducer is a bit of a red herring, because indeed doing fork() 
+ exec() in pure Python is too fragile.  That is why the standard subprocess 
does it in C.  The problem here is that the `distutils.spawn` module still has 
its hand-baked fork() + exec() pure Python code from the 1990s.

So the solution to the OP's actual problem should be to recode 
`distutils.spawn` using the subprocess module.

Original mailing-list discussion at:
https://mail.python.org/archives/list/python-...@python.org/thread/PTJ3UAZNYBYBYQ4WLMSERZR2XIVWISLM/

--
type:  -> behavior
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

[issue36144] Dictionary union. (PEP 584)

[Guido van Rossum]

Guido van Rossum  added the comment:


New changeset d0ca9bd93bb9d8d4aa9bbe939ca7fd54ac870c8f by Brandt Bucher in 
branch 'master':
bpo-36144: Document PEP 584 (GH-18659)
https://github.com/python/cpython/commit/d0ca9bd93bb9d8d4aa9bbe939ca7fd54ac870c8f


--

___
Python tracker 

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

[issue39762] PyLong_AS_LONG missing from longobject.h

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

The reason why there was the PyInt_AS_LONG macro is that it is very simple and 
efficient. It never fails, because the value of the int object always fits in 
the C long. PyInt_AsLong is much slower. If you know that the object is int, 
you can use PyInt_AS_LONG for performance and simplicity.

In contrary, converting the long object to the C long value requires a loop and 
it can overflow. There is no reason to implement it as a macro. You can use the 
PyLong_AsLong function.

--

___
Python tracker 

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

[issue39763] Hang after fork due to logging trying to reacquire the module lock in an atfork() handler

[Guido van Rossum]

Change by Guido van Rossum :


--
nosy: +gvanrossum, pitrou

___
Python tracker 

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

[issue39699] Some CIs silence potentially useful output from make

[Steve Dower]

Steve Dower  added the comment:


New changeset 343bc06d8047e4a2e675394528dbb5155be1b3b5 by Steve Dower in branch 
'3.8':
bpo-39699: Don't silence make on Azure and Github CIs (GH-18583)
https://github.com/python/cpython/commit/343bc06d8047e4a2e675394528dbb5155be1b3b5


--

___
Python tracker 

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

[issue39698] asyncio.sleep() does not adhere to time.sleep() behavior for negative numbers

[Marco Sulla]

Marco Sulla  added the comment:

> I also distinctly remember seeing code (and writing such code myself) that 
> performs computation on timeouts and does not care if the end value goes 
> below 0.

This is not a good statistics. Frankly we can't measure the impact of the 
change from these considerations. And furthermore, `asyncio.sleep()` is used 
often, testing and mocking apart? I doubt it.

> we always try to have a very good explanation "why" we want to bother 
> ourselves and users to break backwards compat.

Coherence and unhide mistakes are *very* strong points.

That said, I'm not so much interested in practice. Do as you wish. The problem 
is I always considered Python a very elegant programming language, and this 
behavior is not elegant at all. But, hey, amen.

--

___
Python tracker 

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

[issue39698] asyncio.sleep() does not adhere to time.sleep() behavior for negative numbers

[Marco Sulla]

Change by Marco Sulla :


--
resolution: not a bug -> rejected

___
Python tracker 

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

[issue39699] Some CIs silence potentially useful output from make

[Steve Dower]

Change by Steve Dower :


--
pull_requests: +18027
pull_request: https://github.com/python/cpython/pull/18671

___
Python tracker 

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

[issue39699] Some CIs silence potentially useful output from make

[Steve Dower]

Change by Steve Dower :


--
pull_requests: +18026
pull_request: https://github.com/python/cpython/pull/18670

___
Python tracker 

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

[issue39761] Python 3.9.0a4 fails to build when configured with --with-dtrace

[David Carlier]

David Carlier  added the comment:

Weird I just tried on ubuntu/systemtap...

--

___
Python tracker 

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

[issue39764] PyAsyncGenObject causes task.get_stack() raising AttributeError

[Lidi Zheng]

New submission from Lidi Zheng :

This issue exists since 3.6.

The implementation of get stack on Task is looking for two attribute [1]: 
"cr_frame" for coroutines, "gi_frame" for generators (legacy coroutines). 
However, PyAsyncGenObject provides none of them but "ag_frame" [2].

Fix PR: https://github.com/python/cpython/pull/18669

A simple reproduce:

def test_async_gen_aclose_compatible_with_get_stack(self):
async def async_generator():
yield object()

async def run():
ag = async_generator()
asyncio.create_task(ag.aclose())
tasks = asyncio.all_tasks()
for task in tasks:
# No AttributeError raised
task.get_stack()

self.loop.run_until_complete


I found this in my project I want to view who created the Tasks.

[1] 
https://github.com/python/cpython/blob/21da76d1f1b527d62b2e9ef79dd9aa514d996341/Lib/asyncio/base_tasks.py#L27
[2] 
https://github.com/python/cpython/blob/21da76d1f1b527d62b2e9ef79dd9aa514d996341/Objects/genobject.c#L1329

--
components: asyncio
messages: 362722
nosy: asvetlov, lidiz, yselivanov
priority: normal
pull_requests: 18025
severity: normal
status: open
title: PyAsyncGenObject causes task.get_stack() raising AttributeError
type: behavior
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

[issue39761] Python 3.9.0a4 fails to build when configured with --with-dtrace

[Miro Hrončok]

Miro Hrončok  added the comment:

Nope.

--

___
Python tracker 

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

[issue39761] Python 3.9.0a4 fails to build when configured with --with-dtrace

[David Carlier]

David Carlier  added the comment:

What about DFFLAGS=" " ?

--

___
Python tracker 

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

[issue39699] Some CIs silence potentially useful output from make

[Steve Dower]

Steve Dower  added the comment:


New changeset 6aa1f1ecf7142a4117eedb8c570f30da1598616c by Ammar Askar in branch 
'master':
bpo-39699: Don't silence make on Azure and Github CIs (GH-18583)
https://github.com/python/cpython/commit/6aa1f1ecf7142a4117eedb8c570f30da1598616c


--

___
Python tracker 

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

[issue25397] improve ac_cv_have_long_long_format GCC fallback

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

It is too later for 2.7. The long long type is required for recent Python 3 
versions, so this macro is no longer used.

--
nosy: +serhiy.storchaka
resolution:  -> out of date
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

[issue39763] Hang after fork due to logging trying to reacquire the module lock in an atfork() handler

[Elad Lahav]

New submission from Elad Lahav :

The attached code causes the child processes to hang on QNX. The hang is caused 
by the logging module trying to acquire the module lock while in an atfork() 
handler. In a system where semaphore state is kept in user mode and is thus 
inherited from the parent on fork() the semaphore may appear to have a value of 
0, and thus will never be posted to in the single-threaded child.
I don't know how it works on other systems - may be pure chance.

--
components: Library (Lib)
files: fork_mt.py
messages: 362717
nosy: Elad Lahav
priority: normal
severity: normal
status: open
title: Hang after fork due to logging trying to reacquire the module lock in an 
atfork() handler
versions: Python 3.8
Added file: https://bugs.python.org/file48917/fork_mt.py

___
Python tracker 

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

[issue23164] "pydoc filter" documentation restrictive

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

It was fixed in Python 3, and it is too late for 2.7.

--
nosy: +serhiy.storchaka
resolution:  -> out of date
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

[issue22714] target of 'import statement' entry in general index for 'i' is wrong

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

There are 5 links for the "import statement" entry. Issue35506 partially solved 
the problem -- the main link is now emphasized. But it is still the last of 
links. I afraid it is a limitation of Sphinx.

If no other solution be proposed I'll close this issue as "won't fix".

--
nosy: +serhiy.storchaka
status: open -> pending

___
Python tracker 

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

[issue34396] Certain methods that heap allocated subtypes inherit suffer a 50-80% performance penalty

[Marco Sulla]

Marco Sulla  added the comment:

I asked why on StackOverflow, and an user seemed to find the reason. The 
problem for him/her is in `update_one_slot()`. 

`dict` implements directly `__contains__()` and `__getitem__()`. Usually, 
`sq_contains` and `mp_subscript` are wrapped to implement `__contains__()` and 
`__getitem__()`, but this way `dict` is a little faster.

The problem is that `update_one_slot()` searches for the wrappers. If it does 
not find them, it does not inherit the `__contains__()` and `__getitem__()` of 
the class, but create a `__contains__()` and `__getitem__()` functions that do 
an MRO search and call the superclass method. This is why `__contains__()` and 
`__getitem__()` of `dict` subclasses are slower.


Is it possible to modify `update_one_slot()` so that, if no wrapper is found, 
the explicit implementation is inherited?

SO answer: https://stackoverflow.com/a/59914459/1763602

--
components: +C API -Interpreter Core
nosy: +Marco Sulla
versions: +Python 3.9 -Python 3.8

___
Python tracker 

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

[issue39754] update_one_slot() does not inherit sq_contains and mp_subscript if they are explictly declared

[Marco Sulla]

Change by Marco Sulla :


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

[issue39762] PyLong_AS_LONG missing from longobject.h

[Enji Cooper]

Enji Cooper  added the comment:

@serhiy.storchaka: understood. Figured this would be a good errata note for 
others to potentially find in the future.

--

___
Python tracker 

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

[issue39761] Python 3.9.0a4 fails to build when configured with --with-dtrace

[Miro Hrončok]

Miro Hrončok  added the comment:

export DFLAGS="" does not seem to workaround this.

$ make distclean && export DFLAGS="" && ./configure --with-dtrace && make
...
undefined reference to `python_line_semaphore'
...

--

___
Python tracker 

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

[issue31015] PyErr_WriteUnraisable should be more verbose in Python 2.7

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

It is too late for 2.7.

--
nosy: +serhiy.storchaka
resolution:  -> wont fix
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

[issue8269] Missing return values for PyUnicode C/API functions

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Sorry, we missed this issue.

refcounts.dat was updated in other issues.

--
nosy: +serhiy.storchaka
resolution:  -> out of date
stage: patch review -> 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

[issue39762] PyLong_AS_LONG missing from longobject.h

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Python 2 is no longer supported.

--
nosy: +serhiy.storchaka
resolution:  -> out of date
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

[issue39762] PyLong_AS_LONG missing from longobject.h

[Enji Cooper]

Enji Cooper  added the comment:

Workaround PR posted here: https://github.com/encukou/py3c/pull/28

--

___
Python tracker 

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

[issue39762] PyLong_AS_LONG missing from longobject.h

[Enji Cooper]

Enji Cooper  added the comment:

For the record, this seems like it might be the only discrepancy, per the py3c 
project's exported PyInt APIs:

$ for api in `awk '$2 ~ /^PyInt/ { print $3 }' include/py3c/compat.h`; do grep 
-q $api /usr/include/python2.7/longobject.h || echo $api; done
PyLong_AS_LONG

--

___
Python tracker 

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

[issue39762] PyLong_AS_LONG missing from longobject.h

[Enji Cooper]

Enji Cooper  added the comment:

For the record, some projects (like Cython, pywin32) worked around this by 
adding a preprocessor alias, PyLong_AS_LONG -> PyInt_AS_LONG with python 2.x.

--

___
Python tracker 

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