[issue34812] support.args_from_interpreter_flags() doesn't inherit -I (isolated) flag

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

Thanks Victor for the details. Can this be classified as an easy issue? I guess 
the fix will be as below : 

1. Add an entry for '-I' at 
https://github.com/python/cpython/blob/4b430e5f6954ef4b248e95bfb4087635dcdefc6d/Lib/subprocess.py#L260

2. Add a test for '-I' at 
https://github.com/python/cpython/blob/4b430e5f6954ef4b248e95bfb4087635dcdefc6d/Lib/test/test_support.py#L472.
 
The only thing here is that '-I' returns '-s -E -I' unlike other options where 
args can be used for comparison logic in check_options. check_options should be 
changed so that this can take given args and the expected args for comparison 
to accommodate -I. Maybe there is a better way?

Off topic : I don't know why '-I' is not documented as sys.flags.isolated at 
https://docs.python.org/3.7/library/sys.html#sys.flags . Maybe I will open up a 
separate issue for this?

--

___
Python tracker 

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

[issue28655] Tests altered the execution environment in isolated mode

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

I guess this can be safely closed as fixed since 3.6 changes were merged and I 
verified the PR changes locally at msg326477. The issue regarding using -I 
along with -j0 is tracked at issue34812 .

Thanks Serhiy and Victor for the fixes :)

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

___
Python tracker 

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

[issue33698] `._pth` does not allow to populate `sys.path` with empty entry

[Simon Sapin]

Change by Simon Sapin :


--
nosy: +ssapin

___
Python tracker 

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

[issue34841] Script’s directory not in sys.path with embeddable Windows distribution

[Simon Sapin]

New submission from Simon Sapin :

https://docs.python.org/3/library/sys.html#sys.path documents:

> As initialized upon program startup, the first item of this list, path[0], is 
> the directory containing the script that was used to invoke the Python 
> interpreter.

On Windows with an embeddable zip file distribution, this does not happen.

Steps to reproduce:

* Create a foo.py file that contains `import bar`
* Create an empty bar.py file
* With your usual Python installed from the "normal" executable installer, 
check that `python foo.py` runs without output or error
* Download and extract 
https://www.python.org/ftp/python/3.7.0/python-3.7.0-embed-amd64.zip
* Run `..\python-3.7.0-embed-amd64\python foo.py`

Expected result:

The script runs again without output or error.

Actual result:

Traceback (most recent call last):
  File "foo.py", line 1, in 
import bar
ModuleNotFoundError: No module named 'bar'


This might be an occurrence of https://bugs.python.org/issue33698, since the 
embeddable distribution has a python37._pth file that contains "python37.zip" 
and "."

print(sys.path) shows [
  'C:\\Users\\example\\python-3.7.0-embed-amd64\\python37.zip',
  'C:\\Users\\example\\python-3.7.0-embed-amd64'
]

This StackOverflow question describes the same issue: 
https://stackoverflow.com/q/51403126/1162888

--
messages: 326671
nosy: ssapin
priority: normal
severity: normal
status: open
title: Script’s directory not in sys.path with embeddable Windows distribution
type: behavior

___
Python tracker 

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

[issue32291] Value error for string shared memory in multiprocessing

[hongweipeng]

Change by hongweipeng :


--
nosy: +hongweipeng

___
Python tracker 

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

[issue34842] Incorrect error messages in bisect

[Dan Snider]

New submission from Dan Snider :

internal_bisect_left and internal_bisect_right use PySequence_Size when a "hi" 
argument wasn't provided, which causes this silly error message:

>>> bisect.bisect_right(dict.fromkeys(range(10)), 5)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: object of type 'dict' has no len()

They could use PyObject_Size and let PySequence_GetItem in the loop catch the 
error:

>>> bisect.bisect_right(dict.fromkeys(range(10)), 5, 0, 10)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: 'dict' object does not support indexing

Since that actually makes sense and is more efficient / less verbose than 
adding a PySequence_Check.

--
components: Interpreter Core
messages: 326672
nosy: bup
priority: normal
severity: normal
status: open
title: Incorrect error messages in bisect
versions: Python 3.6, Python 3.7

___
Python tracker 

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

[issue32291] Value error for string shared memory in multiprocessing

[hongweipeng]

hongweipeng  added the comment:

This problem seems to be support for str.

import multiprocessing
import ctypes

def child_process_fun(share):
share.value = 'bb'

if __name__ == '__main__':
share = multiprocessing.Value(ctypes.c_wchar_p, 'aa')
process = multiprocessing.Process(target=child_process_fun, args=(share, ))
process.start()
process.join()
print(share.value)

It also raises ValueError.When use c_double or c_int, it works well.

Test in python3.7 and 3.8

--

___
Python tracker 

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

[issue34609] Importing certain modules while debugging raises an exception

[Antoine Pitrou]

Antoine Pitrou  added the comment:

I think pperry nailed it above:

> Pdb fails because it is attempting to import the readline module every time 
> its `trace_dispatch` is called, and the import implementation is not 
> reentrant in that way.

More precisely, _ModuleLock.acquire() in 
https://github.com/python/cpython/blob/master/Lib/importlib/_bootstrap.py#L101 
is not reentrant.  If pdb steps into that function and tries to call it again 
by making an "import" call, `_blocking_on[tid]` will be overwritten and then 
deleted inside the nested call, so `del _blocking_on` in the enclosing call 
will raise a KeyError.

I think the solution would be either one of:
1) pdb avoids doing anything import-related as part of its step function
2) pdb avoids stepping inside importlib internals (e.g. by blacklisting 
importlib modules)

--

___
Python tracker 

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

[issue34842] Incorrect error messages in bisect

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

It was fixed in issue32500. This is a new feature and it was not backported.

>>> bisect.bisect_right(dict.fromkeys(range(10)), 5)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: dict is not a sequence
>>> bisect.bisect_right(dict.fromkeys(range(10)), 5, 0, 10)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: dict is not a sequence

--
nosy: +rhettinger, serhiy.storchaka

___
Python tracker 

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

[issue34843] logging cookbook docs: remove 'recent' when referring to multiprocessing

[Cheryl Sabella]

Change by Cheryl Sabella :


--
keywords: +patch
pull_requests: +9028
stage:  -> patch review

___
Python tracker 

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

[issue34843] logging cookbook docs: remove 'recent' when referring to multiprocessing

[Cheryl Sabella]

New submission from Cheryl Sabella :

In the logging cookbook docs, the word 'recent' is used to describe versions of 
Python containing the multiprocessing module.  Since multiprocessing is 10 
years old, I think it may be safe to remove the word 'recent'.

--
assignee: docs@python
components: Documentation
messages: 326676
nosy: cheryl.sabella, docs@python
priority: normal
severity: normal
status: open
title: logging cookbook docs: remove 'recent' when referring to multiprocessing
type: enhancement
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

[issue34835] Multiprocessing module update fails with pip3

[Cheryl Sabella]

Cheryl Sabella  added the comment:

As Steven said,
> In Python 2.6+ multiprocessing is a std lib module

This means that multiprocessing will be current with the version of Python 3 
that you have installed.  If you're currently on 3.7.0, when 3.7.1 is released 
and you install it, you will get all the updates to multiprocessing (if there 
were any).

--
nosy: +cheryl.sabella

___
Python tracker 

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

[issue34841] Script’s directory not in sys.path with embeddable Windows distribution

[Simon Sapin]

Simon Sapin  added the comment:

Removing python37._pth restores the documented behavior, I don’t know if it has 
adverse effects.

--

___
Python tracker 

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

[issue34833] [CI] Azure Pipeline: Initialize Agent failed

[Steve Dower]

Steve Dower  added the comment:

I'll pass it along in case someone is collecting statistics on the team, but 
unless it's consistently broken for us (e.g. as apt-get was recently) there's 
not much value in opening a bug. Transient failures occur, ultimately, and 
nobody needs encouragement to add the "re-run check" feature besides GitHub 
(and their response is to use the new UI, which is also a top priority for 
Pipelines right now).

Victor, if you'd like your account enabled to be able to restart builds though 
the Azure DevOps page, send me your Microsoft Account 
email(live.com/hotmail.com/etc) and I'll happily add you. But I'm still not 
sure whether that hooks up properly with GitHub's checks.

--

___
Python tracker 

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

[issue34832] "Short circuiting" in base64's b64decode, decode, decodebytes

[Felipe Rodrigues]

Felipe Rodrigues  added the comment:

For reference in future discussions, Python's base64 module implements RFC 3548 
(https://tools.ietf.org/html/rfc3548) whose section 2.3 
(https://tools.ietf.org/html/rfc3548#section-2.3) discusses about 
"Interpretation of non-alphabet characters in encoded data".

The section's content is:

   Base encodings use a specific, reduced, alphabet to encode binary
   data.  Non alphabet characters could exist within base encoded data,
   caused by data corruption or by design.  Non alphabet characters may
   be exploited as a "covert channel", where non-protocol data can be
   sent for nefarious purposes.  Non alphabet characters might also be
   sent in order to exploit implementation errors leading to, e.g.,
   buffer overflow attacks.

   Implementations MUST reject the encoding if it contains characters
   outside the base alphabet when interpreting base encoded data, unless
   the specification referring to this document explicitly states
   otherwise.  Such specifications may, as MIME does, instead state that
   characters outside the base encoding alphabet should simply be
   ignored when interpreting data ("be liberal in what you accept").
   Note that this means that any CRLF constitute "non alphabet
   characters" and are ignored.  Furthermore, such specifications may
   consider the pad character, "=", as not part of the base alphabet
   until the end of the string.  If more than the allowed number of pad
   characters are found at the end of the string, e.g., a base 64 string
   terminated with "===", the excess pad characters could be ignored.

In my opinion, the RFC is rather permissive about strange characters in the 
encoded data. The RFC refers to the MIME specification that ignores the data 
and hints the possibility of rejecting the pad symbol '=' unless it is found in 
the end of the string.

I think that our best option if we would like to address this issue is to add 
an 'errors' argument whose default value will keep the current behavior for 
backwards compatibility but will accept more options in order to both ignore 
the strange characters and carry on with the processing - like bytes.decode's 
errors=ignore flag - and to raise an error in such situations, like 
bytes.decode's errors=strict.

--

___
Python tracker 

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

[issue31370] Remove support for threads-less builds

[Brian Curtin]

Brian Curtin  added the comment:


New changeset eef059657d6b10babdb4831e1148d60cc644ee9a by Brian Curtin (Zackery 
Spytz) in branch 'master':
bpo-31370: Remove references to threadless builds (#8805)
https://github.com/python/cpython/commit/eef059657d6b10babdb4831e1148d60cc644ee9a


--
nosy: +brian.curtin

___
Python tracker 

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

[issue32606] Email Header Injection Protection Bypass

[Cheryl Sabella]

Cheryl Sabella  added the comment:

Should this be closed as 'not a bug'?

--
nosy: +cheryl.sabella

___
Python tracker 

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

[issue27351] Unexpected ConfigParser.read() behavior when passed fileobject

[miss-islington]

Change by miss-islington :


--
pull_requests: +9030

___
Python tracker 

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

[issue27351] Unexpected ConfigParser.read() behavior when passed fileobject

[Brian Curtin]

Brian Curtin  added the comment:


New changeset e45473e3ca31e5b78dc85cab575f5bb60d5b7f8f by Brian Curtin (Zackery 
Spytz) in branch 'master':
bpo-27351: Fix ConfigParser.read() documentation and docstring (GH-8123)
https://github.com/python/cpython/commit/e45473e3ca31e5b78dc85cab575f5bb60d5b7f8f


--
nosy: +brian.curtin

___
Python tracker 

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

[issue27351] Unexpected ConfigParser.read() behavior when passed fileobject

[miss-islington]

Change by miss-islington :


--
pull_requests: +9029

___
Python tracker 

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

[issue34778] Memoryview for column-major (f_contiguous) arrays from bytes impossible to achieve

[mattip]

mattip  added the comment:

Sorry, I meant a "strides" keyword. "shape" is already a valid keyword

--

___
Python tracker 

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

[issue27351] Unexpected ConfigParser.read() behavior when passed fileobject

[Brian Curtin]

Brian Curtin  added the comment:


New changeset b0b8f9bd4e6f78ac7383b4e56cfb6cbacc77da89 by Brian Curtin (Miss 
Islington (bot)) in branch '3.7':
bpo-27351: Fix ConfigParser.read() documentation and docstring (GH-8123)
https://github.com/python/cpython/commit/b0b8f9bd4e6f78ac7383b4e56cfb6cbacc77da89


--

___
Python tracker 

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

[issue27351] Unexpected ConfigParser.read() behavior when passed fileobject

[Brian Curtin]

Brian Curtin  added the comment:


New changeset 3cd5e8e83c9785d9f505138903c7a50dc964101e by Brian Curtin (Miss 
Islington (bot)) in branch '3.6':
bpo-27351: Fix ConfigParser.read() documentation and docstring (GH-8123)
https://github.com/python/cpython/commit/3cd5e8e83c9785d9f505138903c7a50dc964101e


--

___
Python tracker 

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

[issue13407] tarfile doesn't support multistream bzipped tar files

[Brian Curtin]

Brian Curtin  added the comment:


New changeset 8d3b0f49021e6cd25030a1eb979218cfceb44061 by Brian Curtin (Andrés 
Delfino) in branch '2.7':
[2.7] bpo-13407: Mention that bz2/tarfile doesn't support multi-stream bzip2 
files (GH-8428)
https://github.com/python/cpython/commit/8d3b0f49021e6cd25030a1eb979218cfceb44061


--
nosy: +brian.curtin

___
Python tracker 

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

[issue34842] Incorrect error messages in bisect

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Dan, thanks for the suggestion.  Changing to PyObject_Size() would have been 
the right thing to do if the error message had not been fixed.  But since the 
new error message "TypeError: dict is not a sequence" is more helpful than 
"TypeError: 'dict' object does not support indexing", we should leave the code 
as-is.

--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue34842] Incorrect error messages in bisect

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
resolution: not a bug -> out of date

___
Python tracker 

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

[issue34778] Memoryview for column-major (f_contiguous) arrays from bytes impossible to achieve

[Laurent Gautier]

Laurent Gautier  added the comment:

Wouldn't a contiguity argument ('C' or 'F') be simpler ?
 
(Independently, an argument strides is likely also missing from "cast").

Do you know what are the next possible steps here ? Bring this to the 
python-dev list ? Submit a patch ?

--
components: +Extension Modules, Library (Lib) -Interpreter Core

___
Python tracker 

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

[issue34844] logging.Formatter enhancement - Checking on style and

[Luna Chen]

New submission from Luna Chen :

Issue: Currently logging.Formatter does not check if the format passed in is 
valid style or if the field is valid when creating the logging.Formatter 
object. It would be nice to have such check in the constructor of the 
logging.Formatter.

Here are 2 scenarios:

Scenario 1: Passing in invalid `fmt` when creating the logging.Formatter.
Example:
import logging
logger = logging.getLogger('my_logger')
handler = logging.StreamHandler()

fmt = logging.Formatter("blah-blah", style="{")
handler.setFormatter(fmt)

logger.addHandler(handler)
logger.setLevel(logging.DEBUG)

logger.info('This is my logging message.')

The above example would output the fmt string("blah-blah") whenever a logging 
operation is performed, such as `logging.info`, `logging.warning`.
And this goes the same for mismatching style and fmt, like so:
fmt = logging.Formatter("{asctime}-{message}", style="%")


Scenario 2: Passing in invalid fields to logging.Formatter

import logging
logger = logging.getLogger('my_logger')
handler = logging.StreamHandler()

fmt = logging.Formatter("%(FuncName)s-%(message)s")
handler.setFormatter(fmt)

logger.addHandler(handler)
logger.setLevel(logging.DEBUG)

logger.info('This is my logging message.'
)
As you can see from the above example, the "%(FuncName)s" field is misspelled 
with a capital "F", which should have been a lowercase "f". In this scenario, 
we would get an interesting stacktrace:

--- Logging error ---
Traceback (most recent call last):
  File 
"/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/logging/__init__.py",
 line 992, in emit
msg = self.format(record)
  File 
"/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/logging/__init__.py",
 line 838, in format
return fmt.format(record)
  File 
"/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/logging/__init__.py",
 line 578, in format
s = self.formatMessage(record)
  File 
"/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/logging/__init__.py",
 line 547, in formatMessage
return self._style.format(record)
  File 
"/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/logging/__init__.py",
 line 391, in format
return self._fmt % record.__dict__
KeyError: 'FuncName'
Call stack:
  File "", line 1, in 
Message: 'This is my logging message.'
Arguments: ()

Personally, I think the "KeyError" here can be misleading and confusing to 
some. 



Proposal:

I would like to make a PR with the following changes:
- Checking fmt to match the style in the constructor of logging.Formatting
- When calling log message functions such as "logger.info()", an "extra" key 
word arg can be passed for custom format fields, 
  for example:
  fmt = logging.Formatter("{cpuUsage} - {message}", style="{") # In this case, 
cpuUsage would be custom
  logger.info("my logging message", extra={"cpuUsage": "my_cpu_usage"})

  - I would like to have custom fields passed in as an additional (optional) 
argument into the constructor for logging.Formatter
  - Another option is to have an additional member method for adding additional 
fields
  - I think we could essentially have both options
  - With this, we can remove the "extra" argument in Logger.makeRecord()


Draw Backs:

- This change might essentially break some existing code where someone might 
use the "extra" argument in log message functions, as we would do the check on 
logging.Formatter level



Please let me know your thoughts, and I thought it would be nice to get some 
new ideas and areas I haven't thought about before I make this PR.


Best regards,
Luna Chen (BNMetrics)

--
components: Library (Lib)
messages: 326690
nosy: BNMetrics, gvanrossum
priority: normal
severity: normal
status: open
title: logging.Formatter enhancement - Checking on style and
type: enhancement
versions: Python 3.6

___
Python tracker 

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

[issue34844] logging.Formatter enhancement - Checking on style and fmt fields

[Luna Chen]

Change by Luna Chen :


--
title: logging.Formatter enhancement - Checking on style and -> 
logging.Formatter enhancement - Checking on style and fmt fields

___
Python tracker 

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

[issue34844] logging.Formatter enhancement - Checking on style and fmt fields

[Guido van Rossum]

Guido van Rossum  added the comment:

Moving to Python 3.8 because this is a feature proposal. Adding Vinay to nosy 
list because this is about logging.

--
nosy: +vinay.sajip
versions: +Python 3.8 -Python 3.6

___
Python tracker 

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

[issue34845] allow exprlist as the iterators of comprehensions to be consistent with for statements

[thautwarm]

New submission from thautwarm :

Currently we can use `exprlist` as the iterator in a `for` 
statement:

  ```
  for i in 1, 2,:
 print(i)

  1
  2
  ```

  However, when it comes to comprehension expressions:

  ```
  [i for i in 1, 2]

  SyntaxError: invalid syntax
  ```

  I know there might be some reason that leads to the absence of the 
consistency between `for` expression and statement, but IMO until now it could 
be better to allow `exprlist` to be the iterator of comprehensions. I'm not 
sure whether our community has noticed this problem so I'm to propose it here.

  A crucial benefit from this change is that we can avoid the ambiguity when a 
comprehension is accepted as function parameter.

  ```
  f(for i in [1, 2, 3], 1, 2)
  ```
  We now get a SyntaxError when writing such codes, but people who know this 
syntax might think the parameters can be distinguished from each other, but 
it's still not allowed. 
  
  Allowing `exprlist` to be the iterator slot of a comprehension would be a 
rational solution. If `f(for i in [1, 2, 3], 1, 2)` is equivalent to `f(for i 
([1, 2, 3], 1, 2))`, it will be natural to restrict the number of parameters to 
be just 1 when the parameter is a comprehension.

  You can slightly accept this workaround and try following examples:
  ```
  f(for i in 1,)
  f(for i in 1, for j in 2, 3,)
  f(for i in 1, 2 if cond(i) for j in 3, for k in 4,)
  ```
  Obviously, in each of above cases, the number of parameters is 1,
just because a `exprlist` could the iterator of a comprehension.

  The disadvantage of this change is, there is not too many related use cases, 
for any `[expr for target in iter_elem1, iter_elem2, ...]` could be altered as 
`[expr for target in (iter_elem1, iter_elem2, ...)]`. Meanwhile, that might not 
be true when it comes to someone works frequently with interactive python.
 
  
  Finally, I have finished this implementation at 
https://github.com/thautwarm/cpython/tree/exprlist-in-comprehensions, and I do 
want to make contributions to cpython projects. If most of you feel comfortable 
with this change, may I make a PR next?

--
messages: 326692
nosy: gvanrossum, serhiy.storchaka, thautwarm, yselivanov
priority: normal
severity: normal
status: open
title: allow exprlist as the iterators of comprehensions to be consistent with 
for statements

___
Python tracker 

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

[issue34845] allow exprlist as the iterators of comprehensions to be consistent with for statements

[thautwarm]

Change by thautwarm :


--
components: +Interpreter Core
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

[issue34845] allow exprlist as the iterators of comprehensions to be consistent with for statements

[Guido van Rossum]

Guido van Rossum  added the comment:

This is intentional. We don't want people accidentally writing e.g.

[i for i in range(10), j for j in range(10)]

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

[issue34845] allow exprlist as the iterators of comprehensions to be consistent with for statements

[thautwarm]

thautwarm  added the comment:

Well, sorry for that.

--

___
Python tracker 

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

[issue34785] pty.spawn -- auto-termination after child process is dead (a zombie)

[Martin Panter]

Martin Panter  added the comment:

Is this to get “spawn” working on a non-Linux platform like a recent Free BSD, 
OS X, or Solaris? If so, see Issue 26228.

If not, you might have to explain your use case better. Polling for the child 
exiting is going to race with handling the child’s output, and if there are 
other processes writing to the terminal after the child exits this will change 
the behaviour.

--
nosy: +martin.panter

___
Python tracker 

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

[issue13407] tarfile doesn't support multistream bzipped tar files

[Andrés Delfino]

Andrés Delfino  added the comment:

I believe this can be closed.

--

___
Python tracker 

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

[issue13407] tarfile doesn't support multistream bzipped tar files

[Andrés Delfino]

Change by Andrés Delfino :


--
type:  -> enhancement

___
Python tracker 

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

[issue34846] Runtime failure with Failed to import site module

[Satheesh Thomas]

New submission from Satheesh Thomas :

Run time failure to execute python scripts. It was running for long time 
without any issue . But sometimes get this error which stops the entire 
execution. Looks like some .pyc file got corrupted .

--
components: Build
files: Python error1.png
messages: 326697
nosy: sat@gmail.com
priority: normal
severity: normal
status: open
title: Runtime failure with Failed to import site module
type: crash
versions: Python 3.5
Added file: https://bugs.python.org/file47837/Python error1.png

___
Python tracker 

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

[issue32291] Value error for string shared memory in multiprocessing

[hongweipeng]

hongweipeng  added the comment:

I think I know the reason. `c_wchar_p` corresponds to the string pointer 
`wchar_t *`.It's not a good idea to pass pointers between processes. As quoted 
from `multiprocessing` docs:

Note Although it is possible to store a pointer in shared memory remember that 
this will refer to a location in the address space of a specific process. 
However, the pointer is quite likely to be invalid in the context of a second 
process and trying to dereference the pointer from the second process may cause 
a crash.

https://docs.python.org/3.6/library/multiprocessing.html?#module-multiprocessing.sharedctypes

--

___
Python tracker 

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

[issue32756] argparse: parse_known_args: raising exception on unknown arg following known one

[paul j3]

Change by paul j3 :


--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue32833] argparse doesn't recognise two option aliases as equal

[paul j3]

paul j3  added the comment:

I'm going to close this issue.  The current behavior is a logical consequence 
of how option_strings and abbreviations are handled.  Handling this particular 
case differently would be require adding a special test, as opposed to a minor 
tweak to the current code.

It could be reopened if some one wrote a clever and complete patch (and/or made 
a compelling case that it is needed).

--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue34847] asyncio: Add PHA for TLS 1.3

[Fantix King]

New submission from Fantix King :

This was raised in GH-9460 where the same post handshake authentication (PHA) 
was added to the ssl module. It should be added to asyncio too. This issue is 
to discuss the design of PHA API in asyncio, and implement it in Python 3.8.

One approach is to add _SSLProtocolTransport.verify_client_post_handshake(), 
but an additional new transport mixin type to asyncio/transports.py would be 
needed (Yury).

Yury also proposed another option to use get_extra_info() API to get something 
like an "SSLExtra" object with additional APIs.

--
components: asyncio
messages: 326700
nosy: asvetlov, fantix, yselivanov
priority: normal
severity: normal
status: open
title: asyncio: Add PHA for TLS 1.3
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

[issue34847] asyncio: Add PHA for TLS 1.3

[Christian Heimes]

Change by Christian Heimes :


--
keywords: +patch
pull_requests: +9031
stage:  -> patch review

___
Python tracker 

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

[issue34848] range.index only takes one argument when it's documented as taking the usual 3

[Dan Snider]

New submission from Dan Snider :

Unfortunately, it looks like there's no requirement for an abc.Sequence to 
implement the 3 argument form of seq.index, so I suppose this is technically 
just a documentation bug...

>>> range(5).index(2, 1)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: index() takes exactly one argument (2 given)

>>> help(range.index)
Help on method_descriptor:

index(...)
rangeobject.index(value, [start, [stop]]) -> integer -- return index of 
value.
Raise ValueError if the value is not present.

--
assignee: docs@python
components: Argument Clinic, Documentation
messages: 326701
nosy: bup, docs@python, larry
priority: normal
severity: normal
status: open
title: range.index only takes one argument when it's documented as taking the 
usual 3
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7

___
Python tracker 

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

[issue34745] asyncio ssl memory leak

[Fantix King]

Change by Fantix King :


--
nosy: +fantix

___
Python tracker 

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

[issue34849] Drop logging when asyncio waits in selector.select()

[Andrew Svetlov]

New submission from Andrew Svetlov :

The waiting is the pretty normal case: no IO is performed and no immediate 
activities are scheduled.

Therefore logging such cases is just a noise.

--
components: asyncio
messages: 326702
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Drop logging when asyncio waits in selector.select()
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

[issue34849] Drop logging when asyncio waits in selector.select()

[Andrew Svetlov]

Change by Andrew Svetlov :


--
keywords: +patch
pull_requests: +9032
stage:  -> patch review

___
Python tracker 

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

[issue34849] Drop logging when asyncio waits in selector.select()

[miss-islington]

miss-islington  added the comment:


New changeset d5bd036138881bb90a803397d992870a46fbdc2d by Miss Islington (bot) 
(Andrew Svetlov) in branch 'master':
bpo-34849: Don't log wating for selector.select in asyncio loop iteration 
(GH-9641)
https://github.com/python/cpython/commit/d5bd036138881bb90a803397d992870a46fbdc2d


--
nosy: +miss-islington

___
Python tracker 

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

[issue34848] range.index only takes one argument when it's documented as taking the usual 3

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Thank you for your report Dan. It is easy to fix a docstring.

Related issues are issue28197 and issue31942.

--
components:  -Argument Clinic
keywords: +easy (C)
nosy: +rhettinger, serhiy.storchaka -larry
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.8 -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

[issue32552] Improve text for file arguments in argparse.ArgumentDefaultsHelpFormatter class

[paul j3]

paul j3  added the comment:

https://bugs.python.org/issue28742
argparse.ArgumentDefaultsHelpFormatter sometimes provides inaccurate 
documentation of defaults, so they should be overrideable

is asking for something similar - the ability to override the automatic 
`%(default)s` in certain cases.

The proposed fix is to look for a string that is already displaying a default, 
such as '(default:'.

if '%(default)' not in action.help and '(default:' not in action.help:

--
resolution: rejected -> duplicate

___
Python tracker 

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

[issue34476] asyncio.sleep(0) not documented

[Andrew Svetlov]

Andrew Svetlov  added the comment:

`asyncio.sleep()` always pauses the current task and switches execution to 
another one.
`asyncio.sleep(0)` has no special meaning (but it has internal optimization for 
the case).

Basically the same as `time.sleep(0)` for multithreaded program.

I doubt if we need to blow the documentation with all possible related details.

--

___
Python tracker 

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

[issue34744] New %(flag)s format specifier for argparse.add_argument help string

[paul j3]

paul j3  added the comment:

https://bugs.python.org/issue13280, argparse should use the new Formatter class

Raymond Hettinger argued against making such a switch.

However there may be some value in allowing its use in parallel with the '%' 
style of formatting.  That is, if the 'help' string has '%(...)' use the '%' 
formatting, if it has '{}' compatible formats use the '.format' expression.  I 
think that can be done transparently; but I haven't tested it.

The reason I bring it up here, is that I think `.format' can provide the 
functionality this issue is asking for.

If I define an Action like:

a1 = parser.add_argument('--foo', '-f', default='foobar'.
   help='help for {dest} or {option_strings[0]}, default is {default}'  

Then:

a1.help.format(**vars(a1))  
  

produces:

'help for foo or --foo, default is foobar'

So if there is another reason to add new style formatting to help lines, it's 
worth keeping this issue in mind.

--

___
Python tracker 

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

[issue13280] argparse should use the new Formatter class

[paul j3]

paul j3  added the comment:

Thinking about https://bugs.python.org/issue34744, I realized that the new 
style formatting could provide some added flexibility to the help lines.

I think new style formatting could be added in parallel with the existing 
style, as an alternative, not as a replacement.

With that option a help line like:

'help for {dest} or {option_strings[0]} default is {default}'  

could be used.

--

___
Python tracker 

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

[issue34476] asyncio.sleep(0) not documented

[Hrvoje Nikšić]

Hrvoje Nikšić  added the comment:

The issue is because the current documentation *doesn't* say that 
"`asyncio.sleep()` always pauses the current task and switches execution to 
another one", it just says that it "blocks for _delay_ seconds".

With that description a perfectly valid implementation could be further 
optimized with:

async def sleep(delay):
if delay <= 0:
return
...

In which case `await sleep(0)` would *not* cause a task switch. And this is not 
an unreasonable thing to expect because there are many other 
potentially-switching situations in asyncio that sometimes don't cause a 
switch, such as await `queue.get()` from a non-empty queue or await `await 
stream.readline()` from a socket stream that has a line to provide.

The user who wants to implement a "yield control to event loop" has to look at 
the source to find out how delay==0 is handled, and then they have to wonder if 
it's an implementation detail. https://github.com/python/asyncio/issues/284 
states that the behavior is explicit and here to stay, but that promise has 
never made it into the actual documentation.

--

___
Python tracker 

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