[issue37513] Fix a type error in ctypes.rst

[hai shi]

hai shi  added the comment:

or the value error replace type error in struct_init().

--

___
Python tracker 

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

[issue37513] Fix a type error in ctypes.rst

[hai shi]

Change by hai shi :


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

___
Python tracker 

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

[issue37513] Fix a type error in ctypes.rst

[hai shi]

New submission from hai shi :

Python 3.9.0a0 (heads/master-dirty:80097e0, Jul  6 2019, 02:14:54)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-36)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from ctypes import *
>>> class POINT(Structure):
... _fields_ = [("x", c_int),
... ("y", c_int)]
...
>>> POINT(1, 2, 3)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: too many initializers

and the init function in:
https://github.com/python/cpython/blob/master/Modules/_ctypes/_ctypes.c#L4335

--
assignee: docs@python
components: Documentation
messages: 347419
nosy: docs@python, shihai1991
priority: normal
severity: normal
status: open
title: Fix a type error in ctypes.rst

___
Python tracker 

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

[issue37508] A wrong return type in memory.rst

[miss-islington]

miss-islington  added the comment:


New changeset cf294c48e4f97117f708c116362208d28ebfe08f by Miss Islington (bot) 
in branch '3.8':
closes bpo-37508: Fix name of type in memory.rst. (GH-14604)
https://github.com/python/cpython/commit/cf294c48e4f97117f708c116362208d28ebfe08f


--

___
Python tracker 

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

[issue37508] A wrong return type in memory.rst

[miss-islington]

miss-islington  added the comment:


New changeset af5e62e9e2b56017d3716fce40d959adfb753554 by Miss Islington (bot) 
in branch '3.7':
closes bpo-37508: Fix name of type in memory.rst. (GH-14604)
https://github.com/python/cpython/commit/af5e62e9e2b56017d3716fce40d959adfb753554


--
nosy: +miss-islington

___
Python tracker 

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

[issue37508] A wrong return type in memory.rst

[Benjamin Peterson]

Benjamin Peterson  added the comment:


New changeset 39a5d17a7f1387582eb484422df450bc09a5543e by Benjamin Peterson 
(Hai Shi) in branch 'master':
closes bpo-37508: Fix name of type in memory.rst. (GH-14604)
https://github.com/python/cpython/commit/39a5d17a7f1387582eb484422df450bc09a5543e


--
nosy: +benjamin.peterson
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

[issue37508] A wrong return type in memory.rst

[miss-islington]

Change by miss-islington :


--
pull_requests: +14428
pull_request: https://github.com/python/cpython/pull/14614

___
Python tracker 

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

[issue37508] A wrong return type in memory.rst

[miss-islington]

Change by miss-islington :


--
pull_requests: +14427
pull_request: https://github.com/python/cpython/pull/14613

___
Python tracker 

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

[issue37221] PyCode_New API change breaks backwards compatibility policy

[STINNER Victor]

STINNER Victor  added the comment:

I created https://github.com/cython/cython/issues/3034 "Cython doesn't work on 
Python 3.8 beta2"

--

___
Python tracker 

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

[issue37221] PyCode_New API change breaks backwards compatibility policy

[STINNER Victor]

STINNER Victor  added the comment:

I reopen the issue. Cython 0.29.11 doesn't work on Python 3.8 beta2. 
Installation fails with a compiler error:

Cython-0.29.11/Cython/Plex/Scanners.c:7244:274: error: macro "__Pyx_PyCode_New" 
requires 16 arguments, but only 15 given

Cython commit 0d88839168013fd69350d31eaee5514cd2f727b9 is not part of Cython 
tag 0.29.11.

Stefan: it seems like a new Cython release is needed.

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

___
Python tracker 

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

[issue37510] argparse removing more "--" than it should

[paul j3]

paul j3  added the comment:

There are earlier bug/issues about the '--'.  

Also look at the parser code itself.  Keep in mind that parsing is done in two 
passes - once to identify flags versus arguments ('O/A') and then to allocate 
strings to arguments.  I don't recall when '--' is being handled, possibly in 
both.

--

___
Python tracker 

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

[issue37512] Error in the documentation about string concatenation

[Steven D'Aprano]

Steven D'Aprano  added the comment:

Eric is correct that this is a CPython optimization, it is not a language 
feature.

Furthermore, it is an optimization that can be affected by rather subtle 
factors such as the operating system memory management. Here is a thread 
demonstrating that code that relied on this optimization ran fast on Linux and 
slow on Windows, literally hundreds of times slower than other tools:

https://mail.python.org/archives/list/python-...@python.org/thread/EQO6HDZXHFCP4DBEE5Q7MYLHPJMGJ7DQ/

If you prefer the old mailman archives, here are a few relevant posts:

https://mail.python.org/pipermail/python-dev/2009-August/091125.html

https://mail.python.org/pipermail/python-dev/2009-September/091582.html

https://mail.python.org/pipermail/python-dev/2009-September/091592.html

Best practice is to *not* rely on this optimization, but to use str.join. That 
ensures that:

- your code remains fast if run on alternate implementations;
- your code remains fast if the OS memory management changes;
- your code remains fast if you change your code slightly.

For example, I expect both of the following to show the documented quadratic 
behaviour:

- Prepending instead of appending

- keeping two or more references to the string being appended to

  partials = []
  current = ''
  for s in list_of_strings:
  partials.append(current)
  current += s

There may be others.

Perhaps we ought to document this optimization specifically so we can suggest 
that it is intended for improving performance of casual scripts, and that *best 
practice* for professional quality code remains str.join.

--
nosy: +steven.daprano

___
Python tracker 

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

[issue37510] argparse removing more "--" than it should

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +paul.j3

___
Python tracker 

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

[issue37367] octal escapes applied inconsistently throughout the interpreter and lib

[Jeffrey Kintscher]

Jeffrey Kintscher  added the comment:

Here is the problematic code in _PyBytes_DecodeEscape in Objects/bytesobject.c:

c = s[-1] - '0';
if (s < end && '0' <= *s && *s <= '7') {
c = (c<<3) + *s++ - '0';
if (s < end && '0' <= *s && *s <= '7')
c = (c<<3) + *s++ - '0';
}
*p++ = c;

c is an int, and p is a char pointer to the new bytes object's string buffer.  
For b'\407', c gets correctly calculated as 263 (0x107), but the upper bits are 
lost when it gets recast as a char and stored in the location pointed to by p.  
Hence, b'\407' becomes b'\x07' when the object is created.

IMO, this should raise "ValueError: bytes must be in range(0, 256)" instead of 
silently throwing away the upper bits.  I will work on a PR.

I also took a look at how escaped hex values are handled by the same function.  
It may seem at first glance that

>>> b'\x107'
b'\x107'

is returning the hex value 0x107, but in reality it is returning '\x10' as the 
first character and '7' as the second character.  While visually misleading, it 
is syntactically and semantically correct.

--

___
Python tracker 

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

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

> Which should be fixed, if possible.  But, as damage goes - sorry! - it just 
> seems minimal to me.

I think I failed to express myself correctly there :( I have absolutely no 
problem with the way that behaves currently, I just wanted to point out the 
possible differences and view points regarding optimization and how 
"implementation details" percolate to observable behavior.

--

___
Python tracker 

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

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

[Tim Peters]

Tim Peters  added the comment:

> we could say that it does not matter if
>
> def f():
>   if 0:
> yield
>
> should be or not a generator

Slippery slope arguments play better if they're made _before_ a decade has 
passed after the slope was fully greased.

There's nothing accidental about how `yield` behaves here.  I wrote the 
original generator PEP, and very deliberately added these to its doctests (in 
test_generators.py):

"""
>>> def f():
...if 0:
...yield
>>> type(f())



>>> def f():
... if 0:
... yield 1
>>> type(f())


>>> def f():
...if "":
...yield None
>>> type(f())

"""

Any alternate implementation that decided that whether "it's a generator" 
depended on optimizations would likely fail at least one of those tests.  It 
was intended to be solely a compile-time decision, based purely on syntactic 
analysis.

So I've seen no reason to believe - or expect - that the damage here goes - or 
will ever go - deeper than that some dead code isn't raising compile-time 
errors in some rare cases (statements allowed only at function level being used 
in dead code outside function level).

Which should be fixed, if possible.  But, as damage goes - sorry! - it just 
seems minimal to me.

--

___
Python tracker 

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

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

> So, to my eyes, absolutely nothing of the optimization remained.  At least 
> not in the example Ned posted here.

This is because his example did not include the changes in PR14116 that 
implemented that.

--

___
Python tracker 

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

[issue37510] argparse removing more "--" than it should

[Jorge L. Martinez]

Jorge L. Martinez  added the comment:

To be clear, my opinion is that a single call of parse_args() should only ever 
remove the first "--". Right now, it seems that it removes the first of each 
argument group, as determined by nargs, I guess.

--

___
Python tracker 

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

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

[Tim Peters]

Tim Peters  added the comment:

> Using jumps is not removing the optimization
> entirely, is just a weaker and more incomplete
> way of doing the same. 

Sorry, I'm afraid I have no idea what that means.  The generated code before 
and after was wildly different, as shown in Ned's original report here.  In 
what possible sense was his "if 0:" being "optimized" if it generated code to 
load 0 onto the stack, then POP_JUMP_IF_FALSE, and then jumped over all the 
code generated for the dead block?

The generated code after is nearly identical if I replace his "if 0:" with "if 
x:" (which the compiler takes to mean a global or builtin about whose 
truthiness it knows nothing at all).  Indeed, the only difference in the byte 
code is that instead of doing a LOAD_CONST to load 0, it does a LOAD_GLOBAL to 
load x.

So, to my eyes, absolutely nothing of the optimization remained.  At least not 
in the example Ned posted here.

--

___
Python tracker 

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

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

I think I have found a simple way to make everyone happy: we can add a new 
field to the compiler that tells it to not emit bytecode. In this way we can 
detect errors by walking the blocks but no bytecode will be emitted.

I have updated PR 14612 to use this approach.

--

___
Python tracker 

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

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

> It's the expected result of fixing a bug _by_ eliminating the optimization 
> entirely. 

Using jumps is not removing the optimization entirely, is just a weaker and 
more incomplete way of doing the same. The optimization introduced the bug in 
the first place. If this was done today it would have been reverted. The only 
thing legitimating the "error" is time. But this is basically elevating a bug 
to a feature, making this even more relevant than ever:

https://xkcd.com/1172/

--

___
Python tracker 

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

[issue17535] IDLE: Add an option to show line numbers along the left side of the editor window, and have it enabled by default.

[Tal Einat]

Tal Einat  added the comment:

I've made some significant improvements in several aspects:

1. Scrolling: performance and behavior
2. Selection entire lines by dragging over line numbers
3.  Color config: a separate highlighting setting for line numbers, which takes 
effect immediately

I've also remove the Tk version >= 8.5 check, and replaced the hack for getting 
font updates to take immediate effect.


As far as I can see, the only things left to resolve are:

1. Clear, consistent behavior regarding whether line numbers are enabled by 
default, and when and how this default is changed.
2. Menu item location, type (boolean flag?) and correctly reflecting the state 
of each window.

--

___
Python tracker 

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

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

Tim, you made very good points in you email to Python-dev. I am convinced that 
the better thing to do at this pointis to revert this until we can think this a 
bit more :)

I have made a PR to revert the change, could you review it, please?

--

___
Python tracker 

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

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

[Tim Peters]

Tim Peters  added the comment:

> This is the expected result of fixing a bug that has been
> open since 2008

It's the expected result of fixing a bug _by_ eliminating the optimization 
entirely.  It's not an expected result of merely fixing the bug.  It's quite 
obviously _possible_ to note that

if 0:
return

is forbidden at module level, yet not emit any bytecode for it.  Indeed, it's 
so obvious that everyone here did it in their head without even noticing they 
had done so ;-)

--
nosy: +tim.peters

___
Python tracker 

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

[issue37512] Error in the documentation about string concatenation

[Eric V. Smith]

Eric V. Smith  added the comment:

It's my understanding that this is a quality of implementation issue, and that 
in other (non-CPython) implementations, the run time for repeated concatenation 
may indeed be quadratic.

The optimization in CPython relies on knowing the reference count is 1. If 
CPython were to switch away from reference counting, I would expect the 
behavior of repeated concatenation to be quadratic again.

I'm not sure if the deserves a documentation note or not.

--
nosy: +eric.smith

___
Python tracker 

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

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


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

___
Python tracker 

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

[issue37510] argparse removing more "--" than it should

[Eric V. Smith]

Change by Eric V. Smith :


--
nosy: +eric.smith

___
Python tracker 

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

[issue37478] Docs: Method os.chdir() does not mention errors that can be raised

[Kyle Stanley]

Kyle Stanley  added the comment:

Actually, I don't believe that I have the appropriate permissions to manually 
specify reviewers for PRs in the cpython repository. Do I have to be added a 
member of the Python organization on GitHub for this? I'm registered as a PSF 
contributing member, but I don't think that alone translates to any repository 
permissions. Could I be added as a member with low level permissions such as 
editing issue labels without being granted commit? This would also be helpful 
for adding "skip news" labels on any other issues, I've been doing a decent 
amount of PR reviews recently.

--

___
Python tracker 

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

[issue37478] Docs: Method os.chdir() does not mention errors that can be raised

[Kyle Stanley]

Change by Kyle Stanley :


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

___
Python tracker 

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

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

> I see optimizing away 'if __debug__: ...' clauses, when __debug__ is False 
> (and 0) as currently documented language behavior, not a 'deep implementation 
> detail'.
https://docs.python.org/3/reference/simple_stmts.html#the-assert-statement

I don't think you can conclude that is documented with this argument. What's 
documented is what happens with the assert statement, not with arbitrary dead 
code. The link between the two is at least an interpretation, not an explicitly 
documented think.

--

___
Python tracker 

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

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

> In either case, I don't think it should have been applied as is in b2

Just to clarify: this was added before beta2.

--

___
Python tracker 

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

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

[Ned Deily]

Ned Deily  added the comment:

For the record, this change in behavior was originally backported to the 3.7 
branch and appeared in 3.7.4rc1 and rc2.  Now that the compatibility issues are 
clearer, it will be reverted for 3.7.4 final and will not be considered for 
future 3.7.x releases.

--
versions: +Python 3.9 -Python 3.7

___
Python tracker 

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

[issue37478] Docs: Method os.chdir() does not mention errors that can be raised

[Kyle Stanley]

Kyle Stanley  added the comment:

Thanks for the feedback terry. Do you think it would be helpful to work through 
some of the other commonly used functions in OS, adding condensed explanations 
of exceptions which can be raised? In general, it seems quite useful for users 
to be able to figure out the exceptions in which they may need to account for 
when using each of the functions. 

Also, should the naming convention be "method" or "function"? The two roughly 
refer to the same thing, but as far as I'm aware, the convention in Python is 
to refer to them as "functions". I'm  used to calling them "methods" from my 
prior experience with OOP, so that's why I did so in my initial condensed 
description. On the docs for OS, there seems to be a few instances where the 
term "method" is used. 

Personally, I don't mind the usage of either term, at the end of the day it's 
just semantics. But for the purposes of documentation, consistency seems 
preferable. Should I create a PR for replacing the mentions of "method" with 
"function"? Since it's quite minor and in the same OS.rst file, should I link 
it to this issue instead of creating a new one?

--

___
Python tracker 

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

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

[Paul Ganssle]

Paul Ganssle  added the comment:

> CPython has acted the current way for about 15 years (since 2.4 was 
> released), and this is the first time anyone has raised an objection. 

This is the expected result of fixing a bug that has been open since 2008 (11 
years), which itself was noticed independently, also in 2008 (#1875 and #1920, 
respectively). I also independently discovered the same issue last year when 
writing some tests for IPython, and I suspect others have hit it as well and 
shrugged it off because it's not that hard to work around and there was an open 
issue for it.

I will also note that this "not raising a SyntaxError" behavior is a 
CPython-specific implementation detail (and is quite fragile to boot), note:

$ cat syntax_err.py
if 0:
return

$ python syntax_err.py   # Works on 2.7 and <3.8
$ pypy syntax_err.py # Same behavior with pypy3.6
  File "syntax_err.py", line 2
return
^
SyntaxError: return outside function

I am not sure if pypy emits the same bytecode, but I think that


> Please don't break a package as fundamental as coverage.

I think it's a bit melodramatic to consider this "breaking" coverage, 
particularly since I would find it very weird if any code under an "if 0" were 
simply *ignored* by coverage, and I would probably report it as a bug. It 
changes the behavior, sure, but this was code that is legitimately not covered. 
I don't think it's a big problem to add `# pragma: nocover` to code blocks you 
don't want covered.

--
nosy: +p-ganssle

___
Python tracker 

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

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

[Terry J. Reedy]

Terry J. Reedy  added the comment:

I agree with Tim.  Detect SyntaxErrors in dead code if you can, but don't 
change the current code deletion, at least not without proper  discussion 
(which Pablo just started on pydev).  The latter is what I consider to be a 
release blocker needing release manager consideration.

I see optimizing away 'if __debug__: ...' clauses, when __debug__ is False (and 
0) as currently documented language behavior, not a 'deep implementation 
detail'.
https://docs.python.org/3/reference/simple_stmts.html#the-assert-statement
Assert statements are equivalent to 'if __debug__' clauses.  They are optimized 
away when __debug__ is False, when python is run with -0.

Given that False and True are 0 and 1 with extra behavior, it is not a stretch 
to infer that 'if 0:' clauses are optimized away, as they currently are (or 
were, until PR 13332).

To my mind, PR 13332 is either an enhancement or a bugfix + additional 
regressive behavior change that I do not believe is absolutely necessary.  In 
either case, I don't think it should have been applied as is in b2.  But that 
is past.  I think it should be either reverted or fixed before b3 to only 
detect SyntaxErrors without leaving code that should be removed.  I don't know 
how close PR 14116 comes to this.

--
nosy: +lukasz.langa, terry.reedy -Mark.Williams, p-ganssle, scoder, tim.peters
priority: normal -> release blocker

___
Python tracker 

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

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

> CPython has acted the current way for about 15 years (since 2.4 was 
> released), and this is the first time anyone has raised an objection.

Although I tend to agree with your words, I have to insist that correctness in 
the reference implementation is very important, is not just a "pragmatic" 
thing. For example, under this argument, we could say that it does not matter if

def f():
  if 0:
yield

should be or not a generator. But that changes things massively. It happens 
that it will always be a generator due to how we check for that property, but 
under this argument is ok if it is undefined.

This also makes the thing even more confusing as there are some syntax 
consequences of unreachable code, but no others. (Like the bytecode for that 
yield will be gone!!. Is impossible to know if that is a generator or not from 
the bytecode).

I have seen many people confused already and it makes very difficult to guess 
what are the consequences of code that is unreachable at runtime. For these 
reasons I think consistency is key.

I agree that the way this is done is not ideal, but we could not find a better 
way to do this :(

--

___
Python tracker 

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

[issue37130] pathlib.Path.with_name() handles '.' and '..' inconsistently

[Brett Cannon]

Brett Cannon  added the comment:

Thinking about this a bit, I my gut says having Path('.').name == '.' makes 
more sense than returning ''. My reasoning is that in any case where there's a 
single value -- e.g. Path('spam') -- you end up with the part returned in 
`name`. That suggests to me that '.' isn't any more special or ambiguous than 
'spam' or '..'.

Antoine, what do you think?

--

___
Python tracker 

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

[issue37512] Error in the documentation about string concatenation

[Dmitriy]

New submission from Dmitriy :

There is an error in documentation about string concatenation:

https://docs.python.org/3/library/stdtypes.html

---
Common Sequence Operations
[...]
6. Concatenating immutable sequences always results in a new object. This means 
that building up a sequence by repeated concatenation will have a quadratic 
runtime cost in the total sequence length. To get a linear runtime cost, you 
must switch to one of the alternatives below:

- if concatenating str objects, you can build a list and use str.join() at the 
end or else write to an io.StringIO instance and retrieve its value when 
complete
---

It is not true for str objects anymore. Example using timeit module shows that 
time grows linearly:
>>> timeit('a+="a"', setup='a=""', number=1)
0.000575412530014
>>> timeit('a+="a"', setup='a=""', number=10)
0.00581984246645

But for bytes it is still right:
>>> timeit('a+=b"a"', setup='a=b""', number=1)
0.001766980786645
>>> timeit('a+=b"a"', setup='a=b""', number=10)
0.2075841416916

--
assignee: docs@python
components: Documentation
messages: 347390
nosy: dmitriym, docs@python
priority: normal
severity: normal
status: open
title: Error in the documentation about string concatenation
type: enhancement
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

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

[Tim Peters]

Tim Peters  added the comment:

There's "correctness" that matters and "correctness" that's merely pedantic ;-) 
 CPython has acted the current way for about 15 years (since 2.4 was released), 
and this is the first time anyone has raised an objection.  That's just not 
enough harm to justify tossing out well over a decade of "facts on the ground". 
 Practicality beats purity.

I, of course, have no objection to detecting syntax errors in dead code.  It's 
the disruptive _way_ that's being done that's objectionable.  I don't have a 
better way in mind, nor the bandwidth to try to dream one up.  But, at heart, 
I'd rather it never "get fixed" than get fixed at this cost.

--

___
Python tracker 

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

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

I have opened a thread in Python dev:

https://mail.python.org/archives/list/python-...@python.org/thread/RHP4LTM4MSTAPJHGMQGGHERYI4PZR23R/

--

___
Python tracker 

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

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

[Mark Williams]

Mark Williams  added the comment:

As a user of Python who maintains at least one large code base, I rely on 
coverage to limit the damage my changes can inflict.  Some of the code I 
maintain uses __debug__; I would not expect moving to 3.8 to be the cause of 
reduced line coverage in that project, and I would be baffled by the difference 
between a coverage report from 3.8 and < 3.8.

Please don't break a package as fundamental as coverage.  Can the compiler be 
changed to not emit bytecode under some circumstances?

--
nosy: +Mark.Williams

___
Python tracker 

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

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

CPython being the reference implementation of Python, people could interpret 
that this optimization is part of the language and its behavior should be 
mirror in every other implementation. That's why under my understanding, 
correctness should always be prioritized.

Tim, do you have any other way that can remove the bytecode but reporting 
SyntaxErrors for these blocks?

--

___
Python tracker 

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

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

> No tests or jumps at all.  That made the optim...

I understand that, but we would need a way of reporting syntax errors in blocks 
even if they will not be executed. Although I agree with your analysis, 
correctness should be prioritized over optimization, IMHO.

--

___
Python tracker 

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

[issue37369] Issue with pip in venv on Powershell in Windows

[Paul Moore]

Paul Moore  added the comment:

On Fri, 5 Jul 2019 at 21:33, Steve Dower  wrote:
> Yeah. We probably need to be clear about which approaches are actually 
> supported and which ones are not.
>
> Ultimately though, I think this is a situation where the breakage is forced 
> upon us (by the operating system), and so fixing the behaviour of our 
> built-in functionality pretty clearly outweight preserving the assumptions 
> made by third-parties (especially since those assumptions are going to break).

Well, given that this is an issue specific to the store distribution
of Python, I'd say that it's the release of the store build that
forces it on us, not the OS, and releasing the store build was our
choice, so if we did so with the store build not meeting existing
implicit (i.e. undocumented, I agree) contracts, then we made that
choice. I think it was the right choice, because the store
distribution is a huge plus, but I do think we should be cautious
about impacting the existing user base simply because of a very new,
and explicitly documented as "still experimental" build. (Yes, I'm
still a bit sore about the hassle involved in getting virtualenv to
work - although the final resolution to that issue was IMO clean and a
huge improvement on the previous status quo, so I'm not *really* sore
:-))

> > IMO, we should bite the bullet here and actually document the
> > interfaces involved in virtual environments, so that tools have a
> > stable contract to work with. That way we'd limit the need for people
> > to rely on undocumented behaviour in the first place.
>
> I feel like I've made this argument before, but I suspect if we'd documented 
> them prior to this change, we'd now have no choice but to remain broken.

Hardly. We would simply have had to document the changed behaviour and
follow our existing transition/compatibility processes. Documenting
things doesn't lock them in stone, it just requires us to give due
consideration to our users when we change things. Conversely, *not*
documenting things makes it easier for us to change things, at the
cost of not giving users supported ways to do certain things that they
may still need to do.

> The interfaces that should be documented are "-m venv", venv.VenvBuilder, and 
> the activation scripts, none of which had to change. But if we start making 
> promises about how "python.exe" actually behaves in a venv then we're going 
> to paint ourselves into a corner very quickly - the venv approach just 
> doesn't scale well to the range of systems people use. (Obligatory mention 
> that PEP 582 would have avoided this whole mess by not requiring us to 
> duplicate python.exe anywhere. But it just wasn't meant to be.)

I assume you're missing my key point here (not unlikely, as I didn't
state it explicitly - I guess I'm relying on undocumented information
myself ;-)). The point here is that venv doesn't exist in a vacuum,
before it existed, virtualenv was the standard way to produce virtual
environments. And because neither virtualenv nor venv document any of
their internal details, they are plagued with incompatibilities, and
work badly together. As a result, tools like pipenv, or pew, or pipx,
can't support both but end up picking just one - and because of
backward compatibility requirements, they pick virtualenv, which has
significantly hindered adoption of venv, which is (for hopefully
obvious reasons) a substantially more robust solution.

It may be that it's just too late to worry about this, and we should
simply accept that tools will be dropping Python 2 support very soon
now, at which point there's no real reason to continue using
virtualenv (apart from no-one having the time to make the change, but
if virtualenv adopts venv as its internal mechanism we can get around
that). But personally, I'd rather not rely on an assumption like that,
just yet (maybe in 3.9?).

(Side issue, I don't really see the relevance of PEP 582 here, as I
don't think it's something that tools like tox and pipenv could
replace virtual environments with - but maybe I'm wrong, if so the
arguments for PEP 582 didn't really get that point across).

--

___
Python tracker 

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

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

[Tim Peters]

Tim Peters  added the comment:

I hate this change :-(  The code generated for something like this today:

def f():
if 0:
x = 1
elif 0:
x = 2
elif 1:
x = 3
elif 0:
x = 4
else:
x = 5
print(x)

is the same as for:

def f():
x = 3
print(x)

No tests or jumps at all.  That made the optimization an extremely efficient, 
and convenient, way to write code with the _possibility_ of using different 
algorithms by merely flipping a 0 and 1 or two in the source code, with no 
runtime costs at all (no cycles consumed, no bytecode bloat, no useless 
unreferenced co_consts members, ...).  Also a zero-runtime-cost way to 
effectively comment out code blocks (e.g., I've often put expensive debug 
checking under an "if 1:" block).

--
nosy: +tim.peters

___
Python tracker 

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

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

> To add to the confusion, the treatment of "if __debug__:" and "if not 
> __debug__:" is now asymmetric:

After the code in PR 14116 this becomes:

  5   0 LOAD_GLOBAL  0 (print)
  2 LOAD_CONST   1 ('debug')
  4 CALL_FUNCTION1
  6 POP_TOP
  8 JUMP_ABSOLUTE   30

  7  10 LOAD_GLOBAL  0 (print)
 12 LOAD_CONST   2 ('not debug')
 14 CALL_FUNCTION1
 16 POP_TOP

  8  18 JUMP_ABSOLUTE   30

  9  20 LOAD_GLOBAL  0 (print)
 22 LOAD_CONST   3 ('NOT DEBUG')
 24 CALL_FUNCTION1
 26 POP_TOP
 28 JUMP_FORWARD 8 (to 38)

 11 >>   30 LOAD_GLOBAL  0 (print)
 32 LOAD_CONST   4 ('DEBUG')
 34 CALL_FUNCTION1
 36 POP_TOP
>>   38 LOAD_CONST   0 (None)
 40 RETURN_VALUE

and

  4   0 JUMP_ABSOLUTE   12

  5   2 LOAD_GLOBAL  0 (print)
  4 LOAD_CONST   1 ('debug')
  6 CALL_FUNCTION1
  8 POP_TOP
 10 JUMP_FORWARD 8 (to 20)

  7 >>   12 LOAD_GLOBAL  0 (print)
 14 LOAD_CONST   2 ('not debug')
 16 CALL_FUNCTION1
 18 POP_TOP

  9 >>   20 LOAD_GLOBAL  0 (print)
 22 LOAD_CONST   3 ('NOT DEBUG')
 24 CALL_FUNCTION1
 26 POP_TOP
 28 JUMP_FORWARD 8 (to 38)

 11  30 LOAD_GLOBAL  0 (print)
 32 LOAD_CONST   4 ('DEBUG')
 34 CALL_FUNCTION1
 36 POP_TOP
>>   38 LOAD_CONST   0 (None)

--

___
Python tracker 

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

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

>Before this change, code could have had an unreported SyntaxError, but it was 
>code that was being discarded by the optimizer anyway

if __debug__ can a valid form of if 0 and therefore any syntax error will not 
be reported until that branch becomes true.

> How many people are benefiting from those SyntaxErrors?

I don't know how to give numbers, but is a matter of correctness. SyntaxErrors 
are reported without the need to execute any code (is a parse error) and should 
be reported independently of bytecode and what code runs or does not run. Is a 
property of the code being written, not of the code being executed. 

> Have users of the language been complaining that they don't see SyntaxErrors 
> in their optimized-away code?

Yes, I have seen many people surprised by this. Paul Ganssle (added to the 
noisy list) was one of the latest ones. Also, is a matter of correctness, is a 
syntax error and should be reported.

>If we keep this change, I will hear from people unhappy with the drop in their 
>coverage measurement.  Have users of the language been complaining that they 
>don't see SyntaxErrors in their optimized-away code?

I am very sorry that this change affects your users in a negative way. But I 
think you were relying on an implementation detail of the interpreter that was 
never assured to have backwards compatibility.

--
nosy: +p-ganssle

___
Python tracker 

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

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

[Ned Batchelder]

Ned Batchelder  added the comment:

To add to the confusion, the treatment of "if __debug__:" and "if not 
__debug__:" is now asymmetric:

Here is debug.py:

import dis
import sys
print(sys.version)

def f():
if __debug__:
print("debug")
else:
print("not debug")
if not __debug__:
print("NOT DEBUG")
else:
print("DEBUG")

dis.dis(f)


$ python3.8 /tmp/debug.py
3.8.0b2 (default, Jul  4 2019, 22:38:04)
[Clang 10.0.0 (clang-1000.10.44.4)]
  7   0 LOAD_GLOBAL  0 (print)
  2 LOAD_CONST   1 ('debug')
  4 CALL_FUNCTION1
  6 POP_TOP

 10   8 LOAD_CONST   2 (False)
 10 POP_JUMP_IF_FALSE   22

 11  12 LOAD_GLOBAL  0 (print)
 14 LOAD_CONST   3 ('NOT DEBUG')
 16 CALL_FUNCTION1
 18 POP_TOP
 20 JUMP_FORWARD 8 (to 30)

 13 >>   22 LOAD_GLOBAL  0 (print)
 24 LOAD_CONST   4 ('DEBUG')
 26 CALL_FUNCTION1
 28 POP_TOP
>>   30 LOAD_CONST   0 (None)
 32 RETURN_VALUE

$ python3.8 -O /tmp/debug.py
3.8.0b2 (default, Jul  4 2019, 22:38:04)
[Clang 10.0.0 (clang-1000.10.44.4)]
  6   0 LOAD_CONST   1 (False)
  2 POP_JUMP_IF_FALSE   14

  7   4 LOAD_GLOBAL  0 (print)
  6 LOAD_CONST   2 ('debug')
  8 CALL_FUNCTION1
 10 POP_TOP
 12 JUMP_FORWARD 8 (to 22)

  9 >>   14 LOAD_GLOBAL  0 (print)
 16 LOAD_CONST   3 ('not debug')
 18 CALL_FUNCTION1
 20 POP_TOP

 11 >>   22 LOAD_GLOBAL  0 (print)
 24 LOAD_CONST   4 ('NOT DEBUG')
 26 CALL_FUNCTION1
 28 POP_TOP
 30 LOAD_CONST   0 (None)
 32 RETURN_VALUE

In 3.7 (and earlier) the behavior was balanced:

$ python3.7 /tmp/debug.py
3.7.3 (default, Apr 10 2019, 10:27:53)
[Clang 10.0.0 (clang-1000.10.44.4)]
  7   0 LOAD_GLOBAL  0 (print)
  2 LOAD_CONST   1 ('debug')
  4 CALL_FUNCTION1
  6 POP_TOP

 13   8 LOAD_GLOBAL  0 (print)
 10 LOAD_CONST   2 ('DEBUG')
 12 CALL_FUNCTION1
 14 POP_TOP
 16 LOAD_CONST   0 (None)
 18 RETURN_VALUE

$ python3.7 -O /tmp/debug.py
3.7.3 (default, Apr 10 2019, 10:27:53)
[Clang 10.0.0 (clang-1000.10.44.4)]
  9   0 LOAD_GLOBAL  0 (print)
  2 LOAD_CONST   1 ('not debug')
  4 CALL_FUNCTION1
  6 POP_TOP

 11   8 LOAD_GLOBAL  0 (print)
 10 LOAD_CONST   2 ('NOT DEBUG')
 12 CALL_FUNCTION1
 14 POP_TOP
 16 LOAD_CONST   0 (None)
 18 RETURN_VALUE


Is this really the desired behavior?

--

___
Python tracker 

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

[issue37510] argparse removing more "--" than it should

[Jorge L. Martinez]

Jorge L. Martinez  added the comment:

Sorry, I forgot to add details on my machine.

Python: 3.7.3
OS: Archlinux

--

___
Python tracker 

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

[issue37511] mmap module add OpenBSD MADV_CONCEAL flag

[David Carlier]

Change by David Carlier :


--
nosy: David Carlier
priority: normal
pull_requests: 14424
severity: normal
status: open
title: mmap module add OpenBSD MADV_CONCEAL flag
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

[issue18374] ast.parse gives wrong position (col_offset) for some BinOp-s

[Carl Friedrich Bolz-Tereick]

Change by Carl Friedrich Bolz-Tereick :


--
pull_requests: +14423
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/14607

___
Python tracker 

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

[issue37510] argparse removing more "--" than it should

[Jorge L. Martinez]

New submission from Jorge L. Martinez :

$ python -c '
import argparse
p = argparse.ArgumentParser()
p.add_argument("first_arg")
p.add_argument("args", nargs="*")
r = p.parse_args(["foo", "--", "bar", "--", "baz", "--", "zap"])
print(r.first_arg + " " + " ".join(r.args))
'

returns:

foo bar baz -- zap

when I think it should return:

foo bar -- baz -- zap

--
components: Library (Lib)
messages: 347378
nosy: jol
priority: normal
severity: normal
status: open
title: argparse removing more "--" than it should
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

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

[Ned Batchelder]

Ned Batchelder  added the comment:

I can see the logic of the argument that says the code exists, and should be 
measured.  But this is changing behavior that has been in place for at least 15 
years.

Before this change, code could have had an unreported SyntaxError, but it was 
code that was being discarded by the optimizer anyway.  How many people are 
benefiting from those SyntaxErrors?  The only way the code would ever run is if 
they changed the "if 0:" to something else, at which point they would have seen 
the SyntaxErrors without this change.

If we keep this change, I will hear from people unhappy with the drop in their 
coverage measurement.  Have users of the language been complaining that they 
don't see SyntaxErrors in their optimized-away code?

--

___
Python tracker 

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

[issue37369] Issue with pip in venv on Powershell in Windows

[Steve Dower]

Steve Dower  added the comment:

> I'm pretty sure there is code in the wild that expects  /
> python.exe to be the Python executable (when you're not in a virtual
> environment) ... for example, when getting
> sys.prefix from the registry (um, I don't think that's right, as the
> executable path is in the registry too - but you get the idea).

Yeah, for sure. Though as you say, when sys.executable is easily accessible, 
they're probably (hopefully) going to be using that.

Older versions of Python definitely omitted the full executable path from the 
registry. PEP 514 added that in, though in this case unfortunately I don't 
think we have any way to fix what goes in the registry :(

> What I'd say is that we should be cautious here, as we risk trading
> one breakage for another, rather than actually fixing the issue.

Yeah. We probably need to be clear about which approaches are actually 
supported and which ones are not.

Ultimately though, I think this is a situation where the breakage is forced 
upon us (by the operating system), and so fixing the behaviour of our built-in 
functionality pretty clearly outweight preserving the assumptions made by 
third-parties (especially since those assumptions are going to break).

> IMO, we should bite the bullet here and actually document the
> interfaces involved in virtual environments, so that tools have a
> stable contract to work with. That way we'd limit the need for people
> to rely on undocumented behaviour in the first place.

I feel like I've made this argument before, but I suspect if we'd documented 
them prior to this change, we'd now have no choice but to remain broken.

The interfaces that should be documented are "-m venv", venv.VenvBuilder, and 
the activation scripts, none of which had to change. But if we start making 
promises about how "python.exe" actually behaves in a venv then we're going to 
paint ourselves into a corner very quickly - the venv approach just doesn't 
scale well to the range of systems people use. (Obligatory mention that PEP 582 
would have avoided this whole mess by not requiring us to duplicate python.exe 
anywhere. But it just wasn't meant to be.)

--

___
Python tracker 

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

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

[Stefan Behnel]

Stefan Behnel  added the comment:

> it should not be rely upon

IMHO, the correct behaviour under coverage analysis is to keep the code and not 
discard it. After all, it is code that exists, and that is not being executed, 
so it should count as uncovered code. The fact that some Python versions can 
detect at compile time that it will never be executed, and thus discard it 
ahead of time, should not have an impact on the coverage analysis.

--
nosy: +scoder

___
Python tracker 

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

[issue37369] Issue with pip in venv on Powershell in Windows

[Paul Moore]

Paul Moore  added the comment:

On Thu, 27 Jun 2019 at 18:08, Steve Dower  wrote:
> However, it does mean that we need to start reporting a sys.executable that 
> is not inside sys.prefix, and I'm not sure whether that is a good idea.
>
> Looking at venv (+Vinay for confirmation here), it seems to treat "home" as 
> "the directory containing the original Python binary" rather than "the 
> directory containing the Python install". So in theory (and in my simple 
> testing), using the sys.executable-not-in-prefix here is fine. But is that 
> intentional?

I'm pretty sure there is code in the wild that expects  /
python.exe to be the Python executable (when you're not in a virtual
environment). I seem to recall that virtualenv might do that sort of
thing. Sorry I can't be precise here, I've just come back from holiday
and won't be back into the swing of open source for a while yet, but
my recollection is that it gets done in situations where
sys.executable isn't (easily) accessible - for example, when getting
sys.prefix from the registry (um, I don't think that's right, as the
executable path is in the registry too - but you get the idea).

What I'd say is that we should be cautious here, as we risk trading
one breakage for another, rather than actually fixing the issue.
Certainly the assumption I quote above is unwarranted, and code making
it can't complain too much if it breaks, but the problem is that you
*have* to make that assumption as the necessary information isn't
available any other way. So we should do some careful testing of 3rd
party tools like virtualenv, pipenv, pipx, pew, tox, etc, to make sure
any "solution" here doesn't break them, and provide or document
transition options for them if necessary (because such tools can't
realistically avoid continuing to support older versions of Python).

IMO, we should bite the bullet here and actually document the
interfaces involved in virtual environments, so that tools have a
stable contract to work with. That way we'd limit the need for people
to rely on undocumented behaviour in the first place.

Paul

--

___
Python tracker 

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

[issue37487] PyList_GetItem() document regarding index

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Good catch. (In the future, try to include the url, as below.)

The full sentence in question, at 
https://docs.python.org/3/c-api/list.html#c.PyList_GetItem, is "The position 
must be positive, indexing from the end of the list is not supported."  
'positive' should be 'non-negative'.  The next sentence deal with out-of-bounds 
positions, and these could be specified as '(< 0, > len(list))'

--
nosy: +terry.reedy

___
Python tracker 

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

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

[Ned Batchelder]

Ned Batchelder  added the comment:

I don't know what you mean by, "it should not be rely upon."  Are you saying 
that in 3.8 you want to keep the lines in the compiled bytecode?  Do you 
understand the implications for coverage measurement?

--

___
Python tracker 

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

[issue37496] Support annotations in signature strings.

[Ivan Levkivskyi]

Change by Ivan Levkivskyi :


--
nosy: +levkivskyi

___
Python tracker 

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

[issue37504] Documentation fails to build when using Sphinx' texinfo builder

[Dmitry Shachnev]

Change by Dmitry Shachnev :


--
title: 3.8 b2 now requires sphinx2, but only has documented 1.8 -> 
Documentation fails to build when using Sphinx' texinfo builder

___
Python tracker 

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

[issue37504] 3.8 b2 now requires sphinx2, but only has documented 1.8

[Dmitry Shachnev]

Change by Dmitry Shachnev :


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

___
Python tracker 

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

[issue37478] Docs: Method os.chdir() does not mention errors that can be raised

[Terry J. Reedy]

Terry J. Reedy  added the comment:

> what exactly is the standard for mentioning errors
My impression is that there is none, or that it is inconsistent, but that the 
trend is to say more.  If you want to followup, check the documentation 
chapters of the devguide, and if there is nothing clear now, post to the pydev 
list.

https://docs.python.org/3/library/os.html#os-file-dir has

 os.chdir(path)
Change the current working directory to path.
This function can support specifying a file descriptor. The descriptor must 
refer to an opened directory, not an open file.

Most of the other entries in do not mention errors, but is_dir has the line 
mentioned.  I think the condensed line is enough to add, as the sub-exception 
names are self-explanatory; and when they occur, the full message certainly is. 
 (I verified both possibilities mentioned.)  Most users should just catch 
OSError, if anything.

Make a PR with the short message and request me as a reviewer.

--
nosy: +terry.reedy

___
Python tracker 

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

[issue18374] ast.parse gives wrong position (col_offset) for some BinOp-s

[Carl Friedrich Bolz-Tereick]

Carl Friedrich Bolz-Tereick  added the comment:

I think the attached patch fixes the problem. Will create a pull request soon.

--
versions: +Python 3.5 -Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file48458/binop-offset.patch

___
Python tracker 

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

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

[miss-islington]

miss-islington  added the comment:


New changeset 7d93effeb4f8e86dfa283f2376ec5362275635c6 by Miss Islington (bot) 
(Pablo Galindo) in branch '3.7':
[3.7] bpo-37500: Revert commit 85ed1712e428f93408f56fc684816f9a85b0ebc0 
(GH-14605)
https://github.com/python/cpython/commit/7d93effeb4f8e86dfa283f2376ec5362275635c6


--
nosy: +miss-islington

___
Python tracker 

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

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


--
Removed message: https://bugs.python.org/msg347367

___
Python tracker 

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

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

Ned, I have prepared PR14605 for the 3.7 branch to revert 
85ed1712e428f93408f56fc684816f9a85b0ebc0. As this is somehow changing behavior 
in the 3.7 series, I think is the best course of action for 3.7.

For 3.8 the proposed way to do this is now using an unconditional jump to skip 
the conditional (in progress in PR 14116). The reason is that we need to 
compile the blocks to detect syntax errors even if the block will be 
unreachable. This is also a deep implementation detail and it should not be 
rely upon, in my opinion.

--

___
Python tracker 

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

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

Ned, I have prepared PR14605 for the 3.7 branch to revert 
85ed1712e428f93408f56fc684816f9a85b0ebc0. As this is somehow changing behavior 
in the 3.7 series, I think is the best course of action for 3.7.

For 3.8 the proposed way to do this is not using an unconditional jump to skip 
the conditional (in progress in PR 14116). The reason is that we need to 
compile the blocks to detect syntax errors even if the block will be 
unreachable. This is also a deep implementation detail and it should not be 
rely upon, in my opinion.

--
keywords:  -patch
stage: patch review -> 

___
Python tracker 

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

[issue37476] Adding a unit test of unicode in test_unicode.py

[Terry J. Reedy]

Change by Terry J. Reedy :


--
nosy: +vstinner

___
Python tracker 

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

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


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

___
Python tracker 

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

[issue37506] os.mkdir creates invalid folder when path string has trailing space and slash

[Steve Dower]

Steve Dower  added the comment:

Yeah, I'd rather not do this level of validation in Python.

If Windows decides to reject or automatically correct this, fine, but Python is 
just being a thin layer over the operating system here. We shouldn't try and 
prevent things that the OS allows.

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

[issue30090] Failed to build these modules: _ctypes

[hai shi]

hai shi  added the comment:

In centos, `sudo yum install -y libffi libffi-devel` should worked

--
nosy: +shihai1991

___
Python tracker 

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

[issue37509] OSError preadv()

[YoSTEALTH]

New submission from YoSTEALTH :

import os
import ctypes

# Stdlib
# --
def test_preadv_stdlib(path):
fd = os.open(path, os.O_RDWR | os.O_CREAT)
buffer = bytearray(10)
buffers = [buffer]
try:
length = os.preadv(fd, buffers, 0, os.RWF_NOWAIT)
# OSError: [Errno 95] Operation not supported
print('length:', length)
print('buffer:', buffer)
finally:
os.close(fd)


# Cyptes Libc
# ---
class iovec(ctypes.Structure):
_fields_ = [('iov_base', ctypes.c_char_p), ('iov_len', ctypes.c_size_t)]


libc = ctypes.CDLL('libc.so.6')


def test_preadv_libc(path):
fd = os.open(path, os.O_RDWR | os.O_CREAT)
buffer = bytes(10)
buffers = (iovec*1)()
buffers[0].iov_base = buffer
buffers[0].iov_len = 10
try:
length = libc.preadv2(fd, buffers, len(buffers), 0, os.RWF_NOWAIT)
print('length:', length)  # length: -1
print('buffer:', buffer)  # buffer: 
b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
finally:
os.close(fd)


# Test Run
# 
def test():
path = '/dev/shm/test-preadv-in-ram-file'

# Test-1 stdlib implementation
try:
test_preadv_stdlib(path)  # OSError: [Errno 95] Operation not supported
except OSError:
print('OSError is raised. This should not raise OSError')

# Test-2 custom ctype `libc` implementation
test_preadv_libc(path)


if __name__ == '__main__':
test()


This code is just to demonstrate working vs receiving an OSError in this 
specific usage.

System:   Linux 4.19.56-1-MANJARO
Python:   3.8.0b2

When the file in question is stored in ram ('/dev/shm') stdlib implementation 
raises an OSError while libc version does not.

--
messages: 347364
nosy: YoSTEALTH, pablogsal, vstinner
priority: normal
severity: normal
status: open
title: OSError preadv()
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

[issue37501] Test failures when CPython is built without docstrings

[Eric V. Smith]

Eric V. Smith  added the comment:

Also surprised by the marked dataclasses tests. I don't see anything there that 
requires docstrings. See my review on the PR.

--

___
Python tracker 

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

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

[Ned Batchelder]

Ned Batchelder  added the comment:

The real-word implications from my world are this: if your code has "if 0:" 
clauses in it, and you measure its coverage, then because the lines have not 
been optimized away, coverage.py will think the lines are a possible execution 
path, and will be considered a miss because they are not executed.  This will 
reduce your coverage percentage. 

I can't estimate how many people this will affect.

--

___
Python tracker 

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

[issue37501] Test failures when CPython is built without docstrings

[Brett Cannon]

Brett Cannon  added the comment:

Bit surprised by the test_importlib failure. What has crept into there that 
requires docstrings?

--
nosy: +brett.cannon

___
Python tracker 

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

[issue37504] 3.8 b2 now requires sphinx2, but only has documented 1.8

[Dmitry Shachnev]

Change by Dmitry Shachnev :


--
nosy: +mitya57

___
Python tracker 

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

[issue37505] Early auditing broken

[Christian Heimes]

Christian Heimes  added the comment:

The hooks are about auditing the behavior of an interpreter. It's not strictly 
tight to some attack scenario. I would find it useful to either get back the 
old behavior or to have some sort of event, which indicates the start of the 
auditing log.

--

___
Python tracker 

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

[issue37151] Calling code cleanup after PEP 590

[Petr Viktorin]

Petr Viktorin  added the comment:


New changeset 7b57c03a7cb63ccfb2b8dfa82a1bf169268d80ba by Petr Viktorin (Jeroen 
Demeyer) in branch 'master':
bpo-37151: remove _PyMethodDef_RawFastCall* functions (GH-14603)
https://github.com/python/cpython/commit/7b57c03a7cb63ccfb2b8dfa82a1bf169268d80ba


--

___
Python tracker 

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

[issue37505] Early auditing broken

[STINNER Victor]

STINNER Victor  added the comment:

PySys_Audit() exit immediately if ts=NULL:

/* Early exit when no hooks are registered */
if (!should_audit(ts)) {
return 0;
}

It exits before calling:

/* Dtrace USDT point */
if (dtrace) {
PyDTrace_AUDIT(event, (void *)eventArgs);
}

where eventArgs is the tuple.

Do you really care of getting an audit event when the *main* interpreter is 
created? It doesn't sound like an attack vector to start Python, no? If you 
need an event "Python started", we can add one later, when the PySys_Audit() is 
usable.

--

___
Python tracker 

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

[issue37505] Early auditing broken

[Steve Dower]

Steve Dower  added the comment:

Yeah, at some point we had to add an initialization check to the audit calls 
because of the tuple, so it essentially became a subinterpreter event but not 
the main one.

But I thought the dtrace call happened before that check? Looking through the 
linked commit, apparently not, but I don't actually recall right now why and I 
can't quite see enough context. Did we need the tuple there too?

--

___
Python tracker 

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

[issue37508] A wrong return type in memory.rst

[hai shi]

Change by hai shi :


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

___
Python tracker 

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

[issue37508] A wrong return type in memory.rst

[hai shi]

New submission from hai shi :

the result should be a bytes object in #L70 in 
https://github.com/python/cpython/blob/master/Doc/c-api/memory.rst

--
assignee: docs@python
components: Documentation
messages: 347356
nosy: docs@python, shihai1991
priority: normal
severity: normal
status: open
title: A wrong return type in memory.rst

___
Python tracker 

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

[issue37151] Calling code cleanup after PEP 590

[Jeroen Demeyer]

Change by Jeroen Demeyer :


--
pull_requests: +14418
pull_request: https://github.com/python/cpython/pull/14603

___
Python tracker 

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

[issue37421] Some tests leak temporary files

[miss-islington]

miss-islington  added the comment:


New changeset 229f6e85f8b4d57a2e742e0d3fc361c5bd15f1cb by Miss Islington (bot) 
in branch '3.8':
bpo-37421: multiprocessing tests now stop ForkServer (GH-14601)
https://github.com/python/cpython/commit/229f6e85f8b4d57a2e742e0d3fc361c5bd15f1cb


--

___
Python tracker 

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

[issue23312] google thinks the docs are mobile unfriendly

[Ned Deily]

Change by Ned Deily :


--
nosy: +mdk
versions: +Python 3.9 -Python 2.7, Python 3.4, Python 3.5

___
Python tracker 

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

[issue37506] os.mkdir creates invalid folder when path string has trailing space and slash

[Steven D'Aprano]

Steven D'Aprano  added the comment:

> it would be better for an exception to be thrown rather than creating a 
> corrupt folder.

I am not convinced that Python should refuse to create a perfectly valid 
directory because some components of Windows sometimes have trouble resolving 
the pathname under some circumstances.

Microsoft say:

"Do not end a file or directory name with a space or a period. Although the 
underlying file system may support such names, the Windows shell and user 
interface does not."

https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file#naming_conventions

but Python is talking to the file system, not the shell or Windows Explorer.

This is a common problem, with numerous solutions:

https://superuser.com/questions/198256/how-to-delete-a-folder-containing-trailing-spaces

It's apparently quite common in shared environments where (for example) Mac 
users may copy files ending with a space onto Windows drives.

--
components: +Windows
nosy: +paul.moore, steve.dower, steven.daprano, tim.golden, zach.ware

___
Python tracker 

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

[issue37505] Early auditing broken

[STINNER Victor]

STINNER Victor  added the comment:

I don't see how the first call to PyInterpreterState_New() can be audited: 
PySys_Audit() builds a tuple to call hooks, but there is no interpreter yet, so 
we cannot even build tuples.

Are you talking about the "main" interpreter, or sub-interpreters?

I'm surprised that it worked previously for the main interpreter.

--

___
Python tracker 

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

[issue37421] Some tests leak temporary files

[STINNER Victor]

STINNER Victor  added the comment:

I created a follow-up issue: bpo-37507 "multiprocessing: Add a stop() method to 
ForkServer".

--

___
Python tracker 

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

[issue37507] multiprocessing: Add a stop() method to ForkServer

[STINNER Victor]

New submission from STINNER Victor :

While working on bpo-37421, I fixed multiprocessing tests to explicitly call 
_run_finaliers(), so temporary directories are removed:

New changeset 039fb49c185570ab7b02f13fbdc51c859cfd831e by Victor Stinner in 
branch 'master':
bpo-37421: multiprocessing tests call _run_finalizers() (GH-14527)
https://github.com/python/cpython/commit/039fb49c185570ab7b02f13fbdc51c859cfd831e

Problem: some tests started to fail when run more than once, which happens 
using ./python -m test -R 3:3 (hunt reference leaks). So I made a first change:

New changeset 9d40554e0da09a44a8547f3f3a2b9dedfeaf7928 by Victor Stinner in 
branch 'master':
bpo-37421: Fix multiprocessing get_temp_dir() finalizer (GH-14572)
https://github.com/python/cpython/commit/9d40554e0da09a44a8547f3f3a2b9dedfeaf7928

But I also had to explicitly stop the ForkServer:

New changeset 9d40554e0da09a44a8547f3f3a2b9dedfeaf7928 by Victor Stinner in 
branch 'master':
bpo-37421: Fix multiprocessing get_temp_dir() finalizer (GH-14572)
https://github.com/python/cpython/commit/9d40554e0da09a44a8547f3f3a2b9dedfeaf7928


I propose to add a public ForkServer.stop() method to stop the server. The 
method would block until the server stops. The server doesn't track its 
children, so if there are running child processes, they will continue to run 
after stop() completes. Child processes are tracked by APIs like 
multiprocessing Pool.

I dislike relying on implicit resource management. I prefer to handle them 
explicitly, to ensure that errors are properly reported if something goes 
wrong. Implicit resource management rely on Python destructor which may be 
called very late during Python finalization, while other modules are already 
cleaned up, and so some function may fail silently (the machineny to report 
issues is broken as well).


In short, I propose to rename the new _stop() method as stop() and document it 
properly :-)

--
components: Library (Lib)
messages: 347351
nosy: davin, pablogsal, pitrou, vstinner
priority: normal
severity: normal
status: open
title: multiprocessing: Add a stop() method to ForkServer
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

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

[Ned Deily]

Ned Deily  added the comment:

How serious a regression is this?  We still have time to revert the 3.7 commit 
of Issue1875 (85ed1712e428f93408f56fc684816f9a85b0ebc0) from 3.7.4 final if we 
act immediately.

--
nosy: +ned.deily
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

[issue1875] "if 0: return" not raising SyntaxError

[Ned Deily]

Ned Deily  added the comment:

See also discussion in Issue37500.

--
nosy: +ned.deily

___
Python tracker 

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

[issue37421] Some tests leak temporary files

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 8fbeb14312b4c1320d31ad86e69749515879d1c3 by Victor Stinner in 
branch 'master':
bpo-37421: multiprocessing tests now stop ForkServer (GH-14601)
https://github.com/python/cpython/commit/8fbeb14312b4c1320d31ad86e69749515879d1c3


--

___
Python tracker 

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

[issue37421] Some tests leak temporary files

[miss-islington]

Change by miss-islington :


--
pull_requests: +14417
pull_request: https://github.com/python/cpython/pull/14602

___
Python tracker 

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

[issue36974] Implement PEP 590

[Petr Viktorin]

Petr Viktorin  added the comment:

Buildbots are green, closing.

Thank you for the implementation!

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

[issue37506] os.mkdir creates invalid folder when path string has trailing space and slash

[Holly]

New submission from Holly :

If we use os.mkdir to create a folder as follows:
os.mkdir("C:/test /")
Then we successfully create a folder with name "test ". This folder can be 
accessed normally, but it cannot be renamed or deleted. Instead we get the 
following error message:
Could not find this item
This is no longer located in C:\. Verify the item's location and try again.
I used Python 3.7.3 (64 bit) and Windows 1809

Obviously this is down to how windows doesn't handle paths particularly nicely, 
so it's not really python's fault. However even if it's decided that python 
shouldn't handle this then it would be better for an exception to be thrown 
rather than creating a corrupt folder.

Note: We can delete the folder by using the Long UNC path, eg. rd "\\?\C:\test "

--
components: IO
messages: 347346
nosy: hollyroberts
priority: normal
severity: normal
status: open
title: os.mkdir creates invalid folder when path string has trailing space and 
slash
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

[issue37505] Early auditing broken

[Christian Heimes]

Christian Heimes  added the comment:

3.8.0b1 is also broken, so it may have been a different commit. I'm sure that I 
was able to see interpreter initialization with dtrace hooks.

# audit.stp
probe process("/usr/lib64/libpython3.8.*").provider("python").mark("audit") {
printf("%s\n", user_string($arg1))
}

$ sudo stap audit.stp -c python3.8

--

___
Python tracker 

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

[issue37505] Early auditing broken

[STINNER Victor]

STINNER Victor  added the comment:

Oh. How can I reproduce this issue?

--

___
Python tracker 

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

[issue37149] link to official documentation tkinter failed !!!

[Guilloux]

Change by Guilloux :


--
versions: +Python 2.7, Python 3.5, Python 3.6

___
Python tracker 

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

[issue37421] Some tests leak temporary files

[STINNER Victor]

STINNER Victor  added the comment:

./python -u -m test test_multiprocessing_spawn -R 3:3 still fail:

ERROR: test_context (test.test_multiprocessing_spawn.TestStartMethod)
ERROR: test_set_get (test.test_multiprocessing_spawn.TestStartMethod)

PR 14601 fix these tests when test_multiprocessing_spawn is run more than once.

--

___
Python tracker 

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

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

[Ned Batchelder]

Ned Batchelder  added the comment:

Since this was backported to 3.7 but not yet released, I'm adding 3.7regression.

--
keywords: +3.7regression

___
Python tracker 

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