[issue30050] Please provide a way to disable the warning printed if the signal module's wakeup fd overflows

[Nathaniel Smith]

Change by Nathaniel Smith :


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

___
Python tracker 

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

[issue31506] Improve the error message logic for object_new & object_init

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

780acc89bccf332d334a27887684cc942eb6 reintroduced the part of the original 
bug fixed in a6c0c0695614177c8b6e1840465375eefcfee586. object.__new__() and 
object.__init__() require an argument (cls and self correspondingly).

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

___
Python tracker 

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

[issue32257] Support Disabling Renegotiation for SSLContext

[Christian Heimes]

Christian Heimes  added the comment:

We don't work that way. Closed means closed forever. Please leave the bug open.

--
priority: normal -> high
resolution: later -> 
stage: resolved -> 
status: closed -> open
type: enhancement -> security
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

[issue32257] Support Disabling Renegotiation for SSLContext

[Qichao Chu]

Qichao Chu  added the comment:

Thanks Christian! Let's wait for OpenSSL then.
I will close this bug for now and reopen when OpenSSL releases 1.1.1 with the 
new flag.

--
resolution:  -> later
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

[issue32257] Support Disabling Renegotiation for SSLContext

[Christian Heimes]

Christian Heimes  added the comment:

I took Guido's keys to the time machine: 
https://github.com/openssl/openssl/issues/4739

--

___
Python tracker 

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

[issue29302] add contextlib.AsyncExitStack

[Ilya Kulakov]

Ilya Kulakov  added the comment:

Charyl, I made the PR.

Where is the AbstractAsyncContextManager? I see that typing.py references it, 
but there is no actual implementation.

--

___
Python tracker 

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

[issue29302] add contextlib.AsyncExitStack

[Ilya Kulakov]

Change by Ilya Kulakov :


--
keywords: +patch
pull_requests: +4690
stage: needs patch -> patch review

___
Python tracker 

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

[issue29137] Fix fpectl-induced ABI breakage

[Nathaniel Smith]

Change by Nathaniel Smith :


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

___
Python tracker 

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

[issue24991] Define instance mutability explicitly on type objects?

[Raymond Hettinger]

Change by Raymond Hettinger :


--
assignee: rhettinger -> 

___
Python tracker 

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

[issue32263] Template string docs refer to "normal %-based substitutions"

[Raymond Hettinger]

Change by Raymond Hettinger :


--
versions:  -Python 3.4, Python 3.5, Python 3.7, Python 3.8

___
Python tracker 

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

[issue32263] Template string docs refer to "normal %-based substitutions"

[Raymond Hettinger]

Raymond Hettinger  added the comment:

FWIW, this was already fixed in the 3.7 docs.  I don't feel any real need to 
backport it.

--
assignee: rhettinger -> 

___
Python tracker 

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

[issue32245] OSError: raw write() returned invalid length on latest Win 10 Consoles

[Simon Depiets]

Simon Depiets  added the comment:

The issue doesn't seem to happen on either 3.6 (with the new stdio mode) or 
with win_unicode_console enabled.

I was able to reproduce it on 3.6 with the PYTHONLEGACYWINDOWSSTDIO flag 
enabled, it's easier to trigger when using directional keys or mouse clicks 
within the console.

chcp : Active code page : 437

System locale : en-us

--

___
Python tracker 

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

[issue32145] Wrong ExitStack Callback recipe

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

I wasn't even aware that pop_all() tries to create the concrete subtype.  I 
wonder how common subclassing ExitStack is in practice.  (Of course, the answer 
is that we'll never know.)

For 3.7, we should probably delegate instance creation to a new non-private 
method, e.g.

new_stack = self._make_instance()

so *if* you subclass, you can create the new ExitStack subclass instances any 
way you want.  I would then change the default implementation to make an 
ExitStack() explicitly, as per the current documentation.

+1 for fixing the recipe and not changing the code for 3.6.  You might want to 
add a note describing the current behavior for <= 3.6 and indicating that this 
will change for 3.7+

Finally, while you're at it, is there any reason not to change the recipe to 
use:

super().__init__()

instead?

--

___
Python tracker 

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

[issue32262] Fix linting errors in asyncio code; use f-strings consistently

[Yury Selivanov]

Yury Selivanov  added the comment:


New changeset 19d0d5480931117d9e0bf396a0234707bbdaa494 by Yury Selivanov in 
branch 'master':
bpo-32262: Fix f-string (#4787)
https://github.com/python/cpython/commit/19d0d5480931117d9e0bf396a0234707bbdaa494


--

___
Python tracker 

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

[issue32262] Fix linting errors in asyncio code; use f-strings consistently

[Yury Selivanov]

Change by Yury Selivanov :


--
pull_requests: +4688

___
Python tracker 

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

[issue32255] csv.writer converts None to '""\n' when it is first line, otherwise '\n'

[Licht Takeuchi]

Licht Takeuchi  added the comment:

Thanks for your investigation!
Would you mind if I create a new patch?

--

___
Python tracker 

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

[issue32273] Remove asyncio.test_utils

[Yury Selivanov]

Change by Yury Selivanov :


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

___
Python tracker 

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

[issue13553] Tkinter Tk args and Gnome Shell application name

[Cheryl Sabella]

Change by Cheryl Sabella :


--
versions: +Python 3.7 -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

[issue13553] Tkinter Tk args and Gnome Shell application name

[Cheryl Sabella]

Change by Cheryl Sabella :


--
keywords: +patch
pull_requests: +4687
stage: needs patch -> patch review

___
Python tracker 

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

[issue32273] Remove asyncio.test_utils

[Yury Selivanov]

New submission from Yury Selivanov :

asyncio.test_utils was never part of asyncio API and was never even documented. 
 It's purely due to historical reasons that test_utils.py is in the Lib/asyncio 
directory.

--
components: asyncio
messages: 308008
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Remove asyncio.test_utils
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

[issue32272] Remove asyncio.async function

[Yury Selivanov]

Change by Yury Selivanov :


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

___
Python tracker 

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

[issue32272] Remove asyncio.async function

[Yury Selivanov]

New submission from Yury Selivanov :

asyncio.async() is a deprecated alias for asyncio.ensure_future().

Since Python 3.7, async and await are proper keywords, and it is no longer 
possible to use the function.  I.e. both 'from asyncio import async' and 
'asyncio.async(...)' are a SyntaxError.

--
components: asyncio
messages: 308006
nosy: yselivanov
priority: normal
severity: normal
status: open
title: Remove asyncio.async function
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

[issue32272] Remove asyncio.async function

[Yury Selivanov]

Yury Selivanov  added the comment:

The function has been deprecated since Python 3.4.4.

--

___
Python tracker 

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

[issue32272] Remove asyncio.async function

[Yury Selivanov]

Change by Yury Selivanov :


--
nosy: +asvetlov

___
Python tracker 

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

[issue32262] Fix linting errors in asyncio code; use f-strings consistently

[Yury Selivanov]

Change by Yury Selivanov :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type:  -> enhancement

___
Python tracker 

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

[issue32262] Fix linting errors in asyncio code; use f-strings consistently

[Yury Selivanov]

Yury Selivanov  added the comment:


New changeset 6370f345e1d5829e1fba59cd695c8b82c5a8c620 by Yury Selivanov in 
branch 'master':
bpo-32262: Fix codestyle; use f-strings formatting where necessary. (#4775)
https://github.com/python/cpython/commit/6370f345e1d5829e1fba59cd695c8b82c5a8c620


--

___
Python tracker 

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

[issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected

[Camion]

Camion  added the comment:

Woops, my mistake... I fumbled this one : the file was empty

--
keywords: +patch
Added file: 
https://bugs.python.org/file47330/issue-32259-iterable-unpackable.patch

___
Python tracker 

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

[issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected

[Camion]

Camion  added the comment:

Well I submitted a patch, but I don't see it anywhere on this page.. Is this 
normal ?

--

___
Python tracker 

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

[issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected

[Camion]

Camion  added the comment:

@Raymond: I know that you have no obligation to make changes just because I'm 
demanding them and that's why I'm just trying to convince people of the 
validity of my observations, here. 
I apologize if my tone may seem "insistent", but please take in account than 
English is not my mother tongue.
 
I agree with the fact that part of learning a language is learning to reason 
from error message to root cause but I cannot ignore that Python's Zen asks for 
explicitness, and Steven agreed with that this situation was tricky to 
interpret.

It would be sly to suggest I'm be looking for vindication for one of my own 
programming errors. I'm experienced enough in trouble-shooting to have solved 
it by myself. It's just that I do not believe normal that this situation took 
me so much time and energy to solve from the error message **in regard with 
other similar situations**.



@David : What other contexts are you talking about ? Instead of looking in the 
documentation which also talks about e.g.:unpacking archive files, You should 
probably grep the source code for strings containing the word unpack and it 
will show you that the word unpack is used in contexts fully related with the 
error in my example.
(SEARCH='".*unpack.*"'; find -name '*.c' -print0 | xargs -0 grep -li "$SEARCH" 
| while read F; do echo "$F" | sed 'p;s/./-/g'; grep -niC 5 "$SEARCH" "$F"; 
done) | less



I don't know about what would be the right error message, but since I 
experimented on in and Serhiy asked for it, I made a sample patch on version 
3.6.3 which contains all the change which I believe, would be required.

--

___
Python tracker 

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

[issue32234] Add context management to mailbox.Mailbox

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

It's possible that the Mailman example can just assume that the mailbox will be 
flushed and unlocked on __exit__(), so it could just call .close().  Then the 
question is whether entering the CM should lock the mailbox.  The two cases are:

1. It doesn't, so you'd have to do:

with mbox(...) as mb:
mb.lock()
# ...

2. It does, so if for some reason you didn't want the lock, you'd have to:

with mbox(...) as mb:
mb.unlock()

We *could* add a `lock` argument to the constructor to take the ambiguity away. 
 But I would claim that it doesn't make much sense to acquire an mbox in a CM 
and *not* lock it.  The idiom says to me "I want to do things to the mbox, 
exclusively, and if that requires locking it, JFDI".

So I would argue that the __enter__() should acquire the lock by default if the 
underlying mailbox supports it.

--

___
Python tracker 

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

[issue32236] open() shouldn't silently ignore buffering=1 in binary mode

[Alexey Izbyshev]

Alexey Izbyshev  added the comment:

I'm in favor of raising an exception because it'll expose existing code with 
incorrect assumptions. I'll check whether it breaks any tests and submit a PR.

--

___
Python tracker 

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

[issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Camion, the problem is not in the error message. The problem is in the complex 
expression that produces an error. If you have a complex expression you always 
have a change to misidentify the source of error. In your case the expression 
contains two implicit iter() invocations.

I have looked at the code. It is possible to make the error message in this 
case more specific. There are precedences of this when pass wrong type as 
var-positional or var-keyword arguments:

>>> print(*1)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: print() argument after * must be an iterable, not int
>>> print(**1)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: print() argument after ** must be a mapping, not int

In the following cases the error message is general. It is possible to make it 
more specific.

>>> a, b = 1
Traceback (most recent call last):
  File "", line 1, in 
TypeError: 'int' object is not iterable
>>> [*1]
Traceback (most recent call last):
  File "", line 1, in 
TypeError: 'int' object is not iterable
>>> {*1}
Traceback (most recent call last):
  File "", line 1, in 
TypeError: 'int' object is not iterable
>>> {**1}
Traceback (most recent call last):
  File "", line 1, in 
TypeError: 'int' object is not a mapping

But PyObject_GetIter() is called in 88 places in CPython core and extensions. 
In all these cases we can make error messages more specific. But I have large 
doubts that it is worth to do. And I'm not sure even about the above examples.

If somebody provide a patch we could discuss it (I'm not sure it will be 
accepted at end).

--

___
Python tracker 

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

[issue32217] freeze.py fails to work.

[Decorater]

Decorater  added the comment:

After thinking about this, maybe a better aproach is to somehow make freeze 
when used on windows somehow read pyconfig.h

--

___
Python tracker 

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

[issue32255] csv.writer converts None to '""\n' when it is first line, otherwise '\n'

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

For restoring the 3.4 behavior the single empty field must be quoted. This 
allows to distinguish a 1-element row with the single empty field from an empty 
row.

--

___
Python tracker 

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

[issue32263] Template string docs refer to "normal %-based substitutions"

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

On Dec 10, 2017, at 14:36, Raymond Hettinger  wrote:
> 
> Raymond Hettinger  added the comment:
> 
> We can remove the word "normal" but otherwise the docs read fairly well.

+1

> FWIW, when there docs were written, the {} new-style string formatting didn't 
> exist, so the wording was reasonable at the time.

Exactly.

--

___
Python tracker 

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

[issue32270] subprocess closes redirected fds even if they are in pass_fds

[Alexey Izbyshev]

Alexey Izbyshev  added the comment:

Regarding fixing (1), I'm worrying about backward compatibility a bit. Some 
people who discovered that behavior might rely on such "move" semantics and 
expect that the redirected descriptor is not leaked into the child. OTOH, since 
descriptors are non-inheritable by default since 3.4, it might be less of an 
issue now. What do you think?

Otherwise, yes, I'd like to fix this, but fixing is a bit trickier than it may 
seem because sometimes descriptors are duplicated in _posixsubprocess.c (in 
case of low fds), so we need to track the ownership properly. I've already 
performed some work and discovered another issue: in a corner case involving 
closed standard fds, pipes created by subprocess may leak into the child and/or 
an incorrect redirection may occur. Since I can't completely fix this issue 
without affecting a discovered one, I think I'll do the opposite: file a new 
issue, fix it, and then go back to this one.

--

___
Python tracker 

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

[issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected

[Raymond Hettinger]

Raymond Hettinger  added the comment:

@Camion, please adopt a less insistent tone.  We've devoting time and thought 
to your concerns but are under no obligation to make a change just because you 
are demanding it.  

Part of learning any programming language is learning to reason from error 
message to root cause.  Good error messages help, but they don't eliminate the 
underlying not always comfortable path of learning the world-view of the 
language and its mechanisms.  That is partly why the devguide includes this 
passage, "Be careful accepting requests for documentation changes from the rare 
but vocal category of reader who is looking for vindication for one of their 
programming errors".

A instructor for several thousand engineers, I've not encountered a single case 
where the current message has been problematic, nor have we had tracker issue 
arise over Python's 27 year history.  And so far all the proposed wording 
changes make the message less accurate in other contexts where the message 
might arise. Based on that and on the comments by the other respondents, it 
would reasonable to close this issue.

--

___
Python tracker 

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

[issue32268] quopri.decode(): string argument expected, got 'bytes'

[R. David Murray]

R. David Murray  added the comment:

Right, this is not a bug, it is working as documented.  You could submit an 
enhancement request, but I'm surprised to find that anyone is actually using 
that module :)

We unfortunately have multiple implementations of quoted printable handling in 
the stdlib.  You might be interested in the functions in the binascii module, 
which do accept unicode input when doing decoding.

--
nosy: +r.david.murray
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type:  -> behavior

___
Python tracker 

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

[issue32270] subprocess closes redirected fds even if they are in pass_fds

[Nitish]

Change by Nitish :


--
nosy: +nitishch

___
Python tracker 

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

[issue32267] strptime misparses offsets with microsecond format

[R. David Murray]

Change by R. David Murray :


--
nosy: +belopolsky

___
Python tracker 

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

[issue1410680] Add 'surgical editing' to ConfigParser

[Fipaddict]

Change by Fipaddict :


--
nosy: +fipaddict

___
Python tracker 

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

[issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected

[R. David Murray]

R. David Murray  added the comment:

I shouldn't have searched the docs for 'unpackable', I should have searched for 
'unpack'.  Doing that reveals that the term 'unpack' is used for other 
concepts, whereas the term 'iterable' is precise.  So I think it would 
unacceptably lower the precision of the error message to add that word.

--

___
Python tracker 

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

[issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected

[R. David Murray]

R. David Murray  added the comment:

> How about "[TYPE] object is not iterable/unpackable"

I just grepped the docs, and the term 'unpackable' does not appear anywhere in 
them.  I don't think this would be an improvement.

As for the earlier suggestion of adding "expected tuple" does not work, because 
it is not a tuple being expected, it is an iterable, and saying "expected 
iterable" would be redundant with saying "is not iterable".

What about "TypeError: expected iterable but found "?  That's parallel to 
some other type error messages we already generate.  Would that be any clearer? 
 (I'm not sure it would be, it says the same thing.)

--
nosy: +r.david.murray

___
Python tracker 

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

[issue32271] test_ssl test failed on Fedora 27

[Amit Ghadge]

Amit Ghadge  added the comment:

Thanks, Christian for your help.

--

___
Python tracker 

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

[issue32271] test_ssl test failed on Fedora 27

[Christian Heimes]

Christian Heimes  added the comment:

This is a bug tracker, not a support forum. If you are having trouble compiling 
and testing CPython, please use the Python users mailing list or IRC (#python 
on freenode).

--
assignee: christian.heimes -> 
resolution:  -> out of date
status: open -> closed
type:  -> behavior

___
Python tracker 

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

[issue32257] Support Disabling Renegotiation for SSLContext

[Christian Heimes]

Christian Heimes  added the comment:

Thanks for checking! I had only checked 1.0.2 and 1.1.0 branch...

I can easily expose the info cb in Python -- but there is no simple way to 
bubble up an exception from a callback to Python. The server name callback 
ignores exception and just prints them with PyErr_WriteUnraisable().

Since OpenSSL 1.1.1 will have SSL_OP_NO_RENEGOTIATION, I'm leaning towards not 
making the code more complicated. Either we have to wait for 1.1.1 or ask 
OpenSSL to backport the feature to 1.0.2 and 1.1.0.

--

___
Python tracker 

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

[issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected

[Camion]

Camion  added the comment:

@Serhiy : I asked you to explain by what mean you supported the affirmation 
that our feeling (that the current message can be misleading in the specific 
situation) is wrong, but you didn't give us any element to understand your 
position. Steven and I did it: I gave you a sample code showing how and why a 
situation could be misinterpreted in regard of the current message, and Steven 
explained that as an experience python programmer, he experienced the same 
misunderstanding (I'm also an experienced programmer: started in the eighties, 
I'm new in Python only).

May be, if you gave us some sound argument element, we could also better 
understand the reason why you affirm that our feeling is wrong. Because in the 
current situation, you only declared your own feeling, but didn't give it any 
support, and all we can conclude is that you are a very experienced python 
programmer who can understand what was beyond the text of the message, but it 
seems in contradiction with the principle of making things clear.



@Raymond : I do not understand how you make the link between both your 
affirmations. The initial problem is related with the fact that in some 
situation, the error message lead to think that there is a problem with the 
loop/generator/iterator, where the problem is in reality with a simple type 
which cannot be unpacked or iterated. 

Let's assume that the interpreter could never make the difference. In what way, 
does it support the fact that the message shouldn't in any way, hint the 
programmer on the fact that the problem is not with the 
generator/iterator/loop, but with the returned type ?



@Steven (& everybody), 
How about : "[TYPE] object is not iterable/unpackable" ?



About patching the sources in c, the message "object is not iterable" appears 
in four places in the version 3.6.3 : in ./Objects/object.c:1023, twice in 
./Objects/typeobject.c (lines 6329 & 6344), and in ./Objects/abstract.c:3135. I 
have patched them to make them recognizable from one another, and it appear 
that all observed messages have been generated from abstract.c:3135 (in 3.6.3) 
and not from the other lines.

This poses problem, because not even the regression test show a case where 
those other 3 parts of the code are used, and I haven't figured out (yet?) what 
condition makes them occur.

--

___
Python tracker 

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

[issue32255] csv.writer converts None to '""\n' when it is first line, otherwise '\n'

[R. David Murray]

R. David Murray  added the comment:

The second case is indeed the bug, as can be seen by running the examples 
against python2.7.  It looks like this was probably broken by 7901b48a1f89 from 
issue 23171.

--
components: +Library (Lib) -IO
nosy: +r.david.murray
stage: patch review -> needs patch
versions:  -Python 2.7, Python 3.4, Python 3.5, Python 3.8

___
Python tracker 

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

[issue32255] csv.writer converts None to '""\n' when it is first line, otherwise '\n'

[R. David Murray]

R. David Murray  added the comment:

Serhiy, since it was your patch that probably introduced this bug, can you take 
a look?  Obviously it isn't a very high priority bug, since no one has reported 
a problem (even this issue isn't reporting the change in behavior as a 
*problem* :)

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue32271] test_ssl test failed on Fedora 27

[Amit Ghadge]

Amit Ghadge  added the comment:

I get the latest changes but now facing with different issue.

--
resolution: out of date -> 
status: closed -> open
type: behavior -> 

___
Python tracker 

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

[issue32257] Support Disabling Renegotiation for SSLContext

[Nathaniel Smith]

Nathaniel Smith  added the comment:

It looks like openssl master has SSL_OP_NO_RENEGOTIATION: 
https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_options.html

Before that, I guess one could use SSL_CTX_sess_{connect,accept}_renegotiate to 
detect when a renegotiation has occurred and then error out? Admittedly this is 
more effective in nonblocking or memorybio mode. Or you could do something 
similar with the info callback: allow the current operation to succeed, but 
mark the connection as "poisoned". (Heck, in socket bio mode you could flat out 
close the socket. That'll shut things down.)

For bonus annoyance, note that RFC 7240 does allow implementations to support 
renegotiation that happens before any data is exchanged, to allow for the 
encrypted client cert hack.

--

___
Python tracker 

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

[issue32271] test_ssl test failed on Fedora 27

[Christian Heimes]

Christian Heimes  added the comment:

Please update. The problem was fixed in 
7b40cb7293cb14e5c7c8ed123efaf9acb33edae2.

--
resolution:  -> out of date
stage:  -> resolved
status: open -> closed
type:  -> behavior

___
Python tracker 

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

[issue32271] test_ssl test failed on Fedora 27

[Amit Ghadge]

Amit Ghadge  added the comment:

No, I'm not on latest commit,

$ git log -1 
commit 3b0f620c1a2a21272a9e2aeca6ca1d1ac10f8162 (HEAD -> master, origin/master, 
origin/HEAD)
Author: Louie Lu 
Date:   Thu Aug 10 08:58:13 2017 +0800

bpo-19903: IDLE: Calltips changed to use inspect.signature (#2822)

--

___
Python tracker 

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

[issue32271] test_ssl test failed on Fedora 27

[Amit Ghadge]

Amit Ghadge  added the comment:

Recompile source but this test failed again.

--

___
Python tracker 

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

[issue32271] test_ssl test failed on Fedora 27

[Christian Heimes]

Christian Heimes  added the comment:

Same for me, are you on latest HEAD of master? The latest commit is:

$ git log -1
commit c4d9df5fd719ad08e68e0950ce22a80f43e4f35d (HEAD -> master, 
upstream/master, upstream/HEAD)
Author: Yury Selivanov 
Date:   Sun Dec 10 12:40:19 2017 -0500

--

___
Python tracker 

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

[issue32271] test_ssl test failed on Fedora 27

[Amit Ghadge]

Amit Ghadge  added the comment:

$ rpm -qa openssl

openssl-1.1.0g-1.fc27.x86_64

--

___
Python tracker 

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

[issue32271] test_ssl test failed on Fedora 27

[Christian Heimes]

Christian Heimes  added the comment:

What's your package version? Please post the output of 'rpm -qa openssl'.

Please also try to build and compile from scratch:

$ make clean
$ ./configure --with-pydebug
$ make
$ ./python -m test -v test_ssl

--

___
Python tracker 

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

[issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

My objections were about the original report. The title of this issue still 
implies there is a bug that is not true. You proposition Steve may  make sense, 
but we need a concrete code for discussing the advantages and the drawbacks of 
this change.

--

___
Python tracker 

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

[issue31940] copystat on symlinks fails for alpine -- faulty lchmod implementation?

[Anthony Sottile]

Change by Anthony Sottile :


--
pull_requests: +4684

___
Python tracker 

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

[issue32263] Template string docs refer to "normal %-based substitutions"

[Raymond Hettinger]

Raymond Hettinger  added the comment:

We can remove the word "normal" but otherwise the docs read fairly well.

FWIW, when there docs were written, the {} new-style string formatting didn't 
exist, so the wording was reasonable at the time.

--
assignee: docs@python -> rhettinger
nosy: +rhettinger

___
Python tracker 

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

[issue32271] test_ssl test failed on Fedora 27

[Amit Ghadge]

Amit Ghadge  added the comment:

My Openssl version is,
OpenSSL 1.1.0g-fips  2 Nov 2017
So, that need to be upgrade Openssl?.

--

___
Python tracker 

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

[issue32271] test_ssl test failed on Fedora 27

[Christian Heimes]

Christian Heimes  added the comment:

All ssl tests are passing for me on Fedora 27 with openssl-1.1.0g-1.fc27.x86_64 
and latest HEAD of master.

--

___
Python tracker 

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

[issue32271] test_ssl test failed on Fedora 27

[Amit Ghadge]

New submission from Amit Ghadge :

I cloned Python repo on my machine, 
below command run successfully,
$ ./configure --with-pydebug && make -j 

But When I was run $./python -m test
test_ssl failed,

0:08:44 load avg: 4.65 [303/406/1] test_ssl failed
Exception in thread Thread-85:
Traceback (most recent call last):
  File "/home/aghadge/my/Open_Source/cpython/Lib/threading.py", line 917, in 
_bootstrap_inner
self.run()
  File "/home/aghadge/my/Open_Source/cpython/Lib/test/test_ssl.py", line 1936, 
in run
if not self.wrap_conn():
  File "/home/aghadge/my/Open_Source/cpython/Lib/test/test_ssl.py", line 1881, 
in wrap_conn
self.sock, server_side=True)
  File "/home/aghadge/my/Open_Source/cpython/Lib/ssl.py", line 401, in 
wrap_socket
_context=self, _session=session)
  File "/home/aghadge/my/Open_Source/cpython/Lib/ssl.py", line 808, in __init__
self.do_handshake()
  File "/home/aghadge/my/Open_Source/cpython/Lib/ssl.py", line 1061, in 
do_handshake
self._sslobj.do_handshake()
  File "/home/aghadge/my/Open_Source/cpython/Lib/ssl.py", line 683, in 
do_handshake
self._sslobj.do_handshake()
OSError: [Errno 0] Error

test test_ssl failed -- Traceback (most recent call last):
  File "/home/aghadge/my/Open_Source/cpython/Lib/test/test_ssl.py", line 3273, 
in test_alpn_protocols
self.assertIsInstance(stats, ssl.SSLError)
AssertionError: {'compression': None, 'cipher': ('ECDHE-RSA-AES256-GCM-SHA384', 
'TLSv1.2', 256), 'peercert': {}, 'client_alpn_protocol': None, 
'client_npn_protocol': None, 'version': 'TLSv1.2', 'session_reused': False, 
'session': <_ssl.Session object at 0x7f8acc86d608>, 'server_alpn_protocols': 
[None], 'server_npn_protocols': [None], 'server_shared_ciphers': 
[[('ECDHE-ECDSA-AES256-GCM-SHA384', 'TLSv1.2', 256), 
('ECDHE-RSA-AES256-GCM-SHA384', 'TLSv1.2', 256), 
('ECDHE-ECDSA-AES128-GCM-SHA256', 'TLSv1.2', 128), 
('ECDHE-RSA-AES128-GCM-SHA256', 'TLSv1.2', 128), 
('ECDHE-ECDSA-CHACHA20-POLY1305', 'TLSv1.2', 256), 
('ECDHE-RSA-CHACHA20-POLY1305', 'TLSv1.2', 256), ('DHE-DSS-AES256-GCM-SHA384', 
'TLSv1.2', 256), ('DHE-RSA-AES256-GCM-SHA384', 'TLSv1.2', 256), 
('DHE-DSS-AES128-GCM-SHA256', 'TLSv1.2', 128), ('DHE-RSA-AES128-GCM-SHA256', 
'TLSv1.2', 128), ('DHE-RSA-CHACHA20-POLY1305', 'TLSv1.2', 256), 
('ECDHE-ECDSA-AES256-CCM8', 'TLSv1.2', 256), ('ECDHE-ECDSA-AES256-CCM', 
'TLSv1.2', 256), ('ECDHE-ECD
 SA-AES256-SHA384', 'TLSv1.2', 256), ('ECDHE-RSA-AES256-SHA384', 'TLSv1.2', 
256), ('ECDHE-ECDSA-AES256-SHA', 'TLSv1.0', 256), ('ECDHE-RSA-AES256-SHA', 
'TLSv1.0', 256), ('DHE-RSA-AES256-CCM8', 'TLSv1.2', 256), 
('DHE-RSA-AES256-CCM', 'TLSv1.2', 256), ('DHE-RSA-AES256-SHA256', 'TLSv1.2', 
256), ('DHE-DSS-AES256-SHA256', 'TLSv1.2', 256), ('DHE-RSA-AES256-SHA', 
'SSLv3', 256), ('DHE-DSS-AES256-SHA', 'SSLv3', 256), 
('ECDHE-ECDSA-AES128-CCM8', 'TLSv1.2', 128), ('ECDHE-ECDSA-AES128-CCM', 
'TLSv1.2', 128), ('ECDHE-ECDSA-AES128-SHA256', 'TLSv1.2', 128), 
('ECDHE-RSA-AES128-SHA256', 'TLSv1.2', 128), ('ECDHE-ECDSA-AES128-SHA', 
'TLSv1.0', 128), ('ECDHE-RSA-AES128-SHA', 'TLSv1.0', 128), 
('DHE-RSA-AES128-CCM8', 'TLSv1.2', 128), ('DHE-RSA-AES128-CCM', 'TLSv1.2', 
128), ('DHE-RSA-AES128-SHA256', 'TLSv1.2', 128), ('DHE-DSS-AES128-SHA256', 
'TLSv1.2', 128), ('DHE-RSA-AES128-SHA', 'SSLv3', 128), ('DHE-DSS-AES128-SHA', 
'SSLv3', 128), ('ECDHE-ECDSA-CAMELLIA256-SHA384', 'TLSv1.2', 256), 
('ECDHE-RSA-CAMELLIA256-S
 HA384', 'TLSv1.2', 256), ('ECDHE-ECDSA-CAMELLIA128-SHA256', 'TLSv1.2', 128), 
('ECDHE-RSA-CAMELLIA128-SHA256', 'TLSv1.2', 128), 
('DHE-RSA-CAMELLIA256-SHA256', 'TLSv1.2', 256), ('DHE-DSS-CAMELLIA256-SHA256', 
'TLSv1.2', 256), ('DHE-RSA-CAMELLIA128-SHA256', 'TLSv1.2', 128), 
('DHE-DSS-CAMELLIA128-SHA256', 'TLSv1.2', 128), ('DHE-RSA-CAMELLIA256-SHA', 
'SSLv3', 256), ('DHE-DSS-CAMELLIA256-SHA', 'SSLv3', 256), 
('DHE-RSA-CAMELLIA128-SHA', 'SSLv3', 128), ('DHE-DSS-CAMELLIA128-SHA', 'SSLv3', 
128), ('AES256-GCM-SHA384', 'TLSv1.2', 256), ('AES128-GCM-SHA256', 'TLSv1.2', 
128), ('AES256-CCM8', 'TLSv1.2', 256), ('AES256-CCM', 'TLSv1.2', 256), 
('AES128-CCM8', 'TLSv1.2', 128), ('AES128-CCM', 'TLSv1.2', 128), 
('AES256-SHA256', 'TLSv1.2', 256), ('AES128-SHA256', 'TLSv1.2', 128), 
('AES256-SHA', 'SSLv3', 256), ('AES128-SHA', 'SSLv3', 128), 
('CAMELLIA256-SHA256', 'TLSv1.2', 256), ('CAMELLIA128-SHA256', 'TLSv1.2', 128), 
('CAMELLIA256-SHA', 'SSLv3', 256), ('CAMELLIA128-SHA', 'SSLv3', 128)]]} is not 
an instan
 ce of 

--
assignee: christian.heimes
components: SSL
messages: 307972
nosy: amitg-b14, christian.heimes
priority: normal
severity: normal
status: open
title: test_ssl test failed on Fedora 27
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

[issue24991] Define instance mutability explicitly on type objects?

[Raymond Hettinger]

Raymond Hettinger  added the comment:

I think this is a hazardous path that should be avoided.  Mutability is an 
elusive concept that is hard to pin down.

Files are immutable when opened in a read-only mode and mutable if opened in a 
write mode.  Tuples are immutable but may contain mutable elements.  Tuples are 
immutable to Python programmers but fully mutable to C programmers.  Some 
objects have some fields than can be mutated and some that can't.  Regular 
Python classes are always mutable in the sense that there is usually some path 
to changing almost everything even if __setattr__ has been overridden.  It is 
more a matter of convention (public API) than a technical point.

I prefer that Python be left as a "consenting adults" language rather than go 
down this precarious path.  For comparison, think about the issue of constants 
in Python.  A constant is just a variable that by convention you don't change.  
It isn't declared or enforced, yet for the most part this is just fine.

--
assignee:  -> rhettinger
nosy: +rhettinger

___
Python tracker 

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

[issue29302] add contextlib.AsyncExitStack

[Cheryl Sabella]

Change by Cheryl Sabella :


--
stage:  -> needs patch

___
Python tracker 

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

[issue29302] add contextlib.AsyncExitStack

[Cheryl Sabella]

Cheryl Sabella  added the comment:

Alexander,

Did you want to submit a PR for this?

--
nosy: +csabella

___
Python tracker 

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

[issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected

[Raymond Hettinger]

Raymond Hettinger  added the comment:

I think the current error message should stay as is.  The interpreter is in no 
position to guess what kind of iterable may have been intended.

--
nosy: +rhettinger

___
Python tracker 

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

[issue32236] open() shouldn't silently ignore buffering=1 in binary mode

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> I suggest to raise a ValueError if buffering=1 is used for binary mode.

Either that, or we instead accept buffering=1 as a regular buffer size.  But 
since buffering=1 means something else for text mode, maybe you're right that 
it's better to raise in binary mode, to avoid any possible confusion.

--
nosy: +benjamin.peterson, stutzbach

___
Python tracker 

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

[issue32270] subprocess closes redirected fds even if they are in pass_fds

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Thanks for the report and the investigation!

> 1. The fact that file descriptors specified for redirection are closed (even 
> with close_fds=False) unless in range [0, 2] is not documented and not tested.

That sounds like a bug to me, so we should fix it if decently possible.

> 2. pass_fds interaction with (1) should be fixed and documented. We may 
> either raise ValueError if pass_fds contains a redirected fd or don't close 
> such a redirected fd.

Same here, it seems like a bug which deserves fixing.

Do you want to submit a PR for this?

--

___
Python tracker 

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

[issue32257] Support Disabling Renegotiation for SSLContext

[Qichao Chu]

Qichao Chu  added the comment:

How about exposing the internal ssl object? This will allow applications to 
control the flag.

--

___
Python tracker 

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

[issue32257] Support Disabling Renegotiation for SSLContext

[Christian Heimes]

Christian Heimes  added the comment:

There must be a better way than custom BIOs. An implemented based on Apache's 
approach is probably > 1,000 lines of C code and a massive compliciation of the 
module.

--

___
Python tracker 

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

[issue32114] The get_event_loop change in bpo28613 did not update the documentation

[Yury Selivanov]

Change by Yury Selivanov :


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

[issue32114] The get_event_loop change in bpo28613 did not update the documentation

[Yury Selivanov]

Yury Selivanov  added the comment:


New changeset 77106b2c21e59d0466742cc3afa50f9e8345e186 by Yury Selivanov (Pablo 
Galindo) in branch 'master':
bpo-32114: Updated the documentation for get_event_loop to reflect the policy 
change (#4510)
https://github.com/python/cpython/commit/77106b2c21e59d0466742cc3afa50f9e8345e186


--

___
Python tracker 

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

[issue32269] Add `asyncio.get_running_loop()` function

[Yury Selivanov]

Change by Yury Selivanov :


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

___
Python tracker 

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

[issue32257] Support Disabling Renegotiation for SSLContext

[Qichao Chu]

Qichao Chu  added the comment:

Thank you for the investigation. This does seem better than the flag. Shall we 
go ahead implement this?

--

___
Python tracker 

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

[issue32270] subprocess closes redirected fds even if they are in pass_fds

[Alexey Izbyshev]

New submission from Alexey Izbyshev :

Demonstration:

$ cat test.py
import os
import subprocess
import sys

fd = os.dup(sys.stdout.fileno())
subprocess.call([sys.executable, '-c',
 'import sys;'
 'print("Hello stdout");'
 'print("Hello fd", file=open(int(sys.argv[1]), "w"))',
 str(fd)],
stdout=fd,
pass_fds=[fd])


$ python3 test.py
Hello stdout
Traceback (most recent call last):
  File "", line 1, in 
OSError: [Errno 9] Bad file descriptor

I see two issues here:

1. The fact that file descriptors specified for redirection are closed (even 
with close_fds=False) unless in range [0, 2] is not documented and not tested. 
If I change the corresponding code in _posixsubprocess.c to close them only if 
they are ends of pipes created by subprocess itself, all tests still pass. 
Also, shells behave differently: e.g., in command 'echo 3>&1' fd 3 is 
duplicated but not closed in the child, so subprocess behavior may be not what 
people expect.

2. pass_fds interaction with (1) should be fixed and documented. We may either 
raise ValueError if pass_fds contains a redirected fd or don't close such a 
redirected fd.

Please provide your thoughts.

--
components: Library (Lib)
files: test.py
messages: 307962
nosy: gregory.p.smith, izbyshev, pitrou, vstinner
priority: normal
severity: normal
status: open
title: subprocess closes redirected fds even if they are in pass_fds
type: behavior
versions: Python 3.6, Python 3.7
Added file: https://bugs.python.org/file47329/test.py

___
Python tracker 

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

[issue32269] Add `asyncio.get_running_loop()` function

[Yury Selivanov]

Change by Yury Selivanov :


--
components: +asyncio
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

[issue32269] Add `asyncio.get_running_loop()` function

[Yury Selivanov]

New submission from Yury Selivanov :

In many contexts `asyncio._get_running_loop()` is more useful than 
`asyncio.get_event_loop()`.  The former function is predictable and simple, the 
latter can change its behaviour depending on the current policy and can even 
create new event loops.

Both `asyncio._get_running_loop()` and `asyncio._set_running_loop()` are public 
asyncio API, although the leading underscore suggests that they are special and 
shouldn't be used by regular users.  That's true for 
`asyncio._set_running_loop()`, which is intended to be used by event loops 
exclusively.

I propose to remove the leading underscore from `asyncio._get_running_loop()`, 
making it `asyncio.get_running_loop()`, and thus promoting a safer alternative 
to `asyncio.get_event_loop()`.

`asyncio._get_running_loop()` will be deprecated and removed in Python 3.9.

--
assignee: yselivanov
messages: 307961
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Add `asyncio.get_running_loop()` function

___
Python tracker 

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

[issue26858] setting SO_REUSEPORT fails at API 21

[Xavier de Gaye]

Xavier de Gaye  added the comment:

This is issue 26855.

--

___
Python tracker 

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

[issue32268] quopri.decode(): string argument expected, got 'bytes'

[Christoph Reiter]

Christoph Reiter  added the comment:

The documentation [0] states: "input and output must be binary file objects" 
and you are not passing a binary file object.

[0] https://docs.python.org/3.6/library/quopri.html#quopri.decode

--
nosy: +lazka

___
Python tracker 

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

[issue32257] Support Disabling Renegotiation for SSLContext

[Christian Heimes]

Christian Heimes  added the comment:

Apache mod_ssl implements CVE-2009-3555 by carefully tracking renegotiation 
state through-out the code base and a custom IO layer that refuses IO when the 
reneg_state becomes invalid.

[1] 
https://github.com/apache/httpd/blob/trunk/modules/ssl/ssl_private.h#L502-L513
[2] 
https://github.com/apache/httpd/blob/trunk/modules/ssl/ssl_engine_io.c#L202-L250

--

___
Python tracker 

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

[issue32268] quopri.decode(): string argument expected, got 'bytes'

[Alexey Luchko]

New submission from Alexey Luchko :

$ python3 -c 'import io, quopri; quopri.decode(io.StringIO("some initial text 
data"), io.StringIO())'
Traceback (most recent call last):
  File "", line 1, in 
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/quopri.py",
 line 125, in decode
output.write(odata)
TypeError: string argument expected, got 'bytes'

--
components: Library (Lib)
messages: 307957
nosy: luch
priority: normal
severity: normal
status: open
title: quopri.decode(): string argument expected, got 'bytes'
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

[issue32257] Support Disabling Renegotiation for SSLContext

[Christian Heimes]

Christian Heimes  added the comment:

Sounds about right, but I cannot find a good way to disable renegotiation.

* SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS doesn't look right. For one it's an 
internal, undocumented flag. But more important it is no longer supported in 
OpenSSL 1.1.0.

* The info_callback trick does not work. The info callback cannot return an 
error indicator. In OpenSSL 1.1.0 the function signature is ``void (*cb) (const 
SSL *ssl, int type, int val)``, which means it cannot modify the SSL object in 
order to abort the connection forcefully.

--

___
Python tracker 

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

[issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected

[Steven D'Aprano]

Steven D'Aprano  added the comment:

On Sun, Dec 10, 2017 at 10:00:27AM +, Camion wrote:

> Understanding that, I suggest to simply add "(expected 'tuple')" at the end 
> of the message.
> ex : TypeError: 'int' object is not iterable (expected 'tuple')

That is incorrect: a tuple is not expected. Any iterable (sequence, 
iterator, tuple, list, set, frozenset, dict, etc) will do. One thing we 
should not do is give a misleading, overly-specific message that implies 
only a tuple will work.

We could say 

TypeError: 'int' object is not iterable (expected iterable)

but that's redundants, since the comment in the parentheses is implied 
by the fact that *not* being iterable is an error.

I think the right thing to do here (if possible!) is to distinguish 
between unpacking and other iteration. E.g.

for x in 20: ... 
=> TypeError: 'int' object is not iterable

a, b = 20
=> TypeError: cannot unpack 'int' object (not iterable)

or similar. I'm less concerned about the exact wording than the fact 
that we give a hint that it was the unpacking operation that failed, 
rather than iteration in some other context.

--

___
Python tracker 

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

[issue19678] smtpd.py: channel should be passed to process_message

[Sanyam Khurana]

Sanyam Khurana  added the comment:

Leslie, would you like to work on a patch for this?

--
nosy: +CuriousLearner

___
Python tracker 

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

[issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected

[Steven D'Aprano]

Steven D'Aprano  added the comment:

On Sun, Dec 10, 2017 at 09:15:16AM +, Serhiy Storchaka wrote:
> My point is that the current error message is correct and is not misleading. 

With respect Serhiy, in this bug report you have TWO PEOPLE who have 
said that it is misleading in this context -- the person who raised the 
bug report, and me. It might not be misleading to you, but it mislead 
us. I've been using Python for over a decade and a half, and when I read 
the exception it confused me too: why is the for loop trying to iterate 
over a Fraction? Did the generator accidentally call return instead of 
yield?

I was especially confused because I was expecting a ValueError too 
many/too few values to unpack.

Of course, with a bit more thought I realised that the error isn't 
generated by the for loop, but the unpacking. 15 years of reading 
exceptions does count for something :-)

If you prefer "lacking sufficient information" over misleading, I won't 
disagree. Putting aside pointless quibbles over the exact wording of 
*why* the current error message is suboptimal, I hope that we can all 
agree that if the error occurs during an unpacking operation, the error 
message should preferably say that the object cannot be unpacked. Is 
there any advantage to not giving that information if we can?

> And this is a standard error message raised in many other cases. There 
> is no a bug.

I agreed that it isn't a bug, and changed this to an enhancement. Better 
error messages should be welcomed, not rejected because they aren't 
fixing a bug.

> *Maybe* it can be improved in some specific cases. Do you want to 
> provide a patch Steven? Without concrete patch the following 
> discussion doesn't make sense. We even don't know if such patch is 
> possible.

Someone who knows C and the interpreter internals better than me will 
have to provide a patch. I wouldn't even know where to start looking. 
But my guess would be the UNPACK_SEQUENCE op-code.

--

___
Python tracker 

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

[issue32267] strptime misparses offsets with microsecond format

[Mario Corchero]

Change by Mario Corchero :


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

___
Python tracker 

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

[issue32267] strptime misparses offsets with microsecond format

[Mario Corchero]

New submission from Mario Corchero :

At the moment strptime misparses all microsecond specifications that do not 
have exactly 6 digits as it is just converted into an int and considered 
microsecond.

This bug was introduced with the implementation in bpo-31800

Example:
_strptime._strptime("+01:30:30.001", "%z") == 
_strptime._strptime("+01:30:30.01", "%z")

--
components: Library (Lib)
messages: 307952
nosy: mariocj89
priority: normal
severity: normal
status: open
title: strptime misparses offsets with microsecond format
type: behavior
versions: Python 3.7, Python 3.8

___
Python tracker 

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

[issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected

[Camion]

Camion  added the comment:

Serhiy, I think I got a better understanding of what is happening. It is well 
described by the following example :

>>> a, b = 1,

Traceback (most recent call last):
  File "", line 1, in 
a, b = 1,
ValueError: need more than 1 value to unpack
>>> a, b = 1

Traceback (most recent call last):
  File "", line 1, in 
a, b = 1
TypeError: 'int' object is not iterable

Again, the message might be correct, but in this case, the combination between 
the message and the ambiguous syntax, makes it lack from explicitness.

Understanding that, I suggest to simply add "(expected 'tuple')" at the end of 
the message.
ex : TypeError: 'int' object is not iterable (expected 'tuple')

--

___
Python tracker 

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

[issue26858] setting SO_REUSEPORT fails at API 21

[STINNER Victor]

STINNER Victor  added the comment:

Do we have a function in Python to get the running Android version?

--

___
Python tracker 

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

[issue32262] Fix linting errors in asyncio code; use f-strings consistently

[Andrew Svetlov]

Andrew Svetlov  added the comment:

Agree with Yury, at lease for asyncio library.

--

___
Python tracker 

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

[issue26865] Meta-issue: support of the android platform

[Xavier de Gaye]

Change by Xavier de Gaye :


--
versions: +Python 3.7 -Python 3.6

___
Python tracker 

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

[issue26865] Meta-issue: support of the android platform

[Xavier de Gaye]

Xavier de Gaye  added the comment:

Remove depencies that are not specific to Android.

--
dependencies:  -add the '--disable-test-suite' option to configure, add the 
'--enable-sourceless-distribution' option to configure, cross compilation of 
third-party extension modules

___
Python tracker 

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

[issue26858] setting SO_REUSEPORT fails at API 21

[Xavier de Gaye]

Xavier de Gaye  added the comment:

This problem does not occur at API 24.

--
title: setting SO_REUSEPORT fails -> setting SO_REUSEPORT fails at API 21

___
Python tracker 

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

[issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

My point is that the current error message is correct and is not misleading. 
And this is a standard error message raised in many other cases. There is no a 
bug.

*Maybe* it can be improved in some specific cases. Do you want to provide a 
patch Steven? Without concrete patch the following discussion doesn't make 
sense. We even don't know if such patch is possible.

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

[issue30928] Copy modified blurbs to idlelib/NEWS.txt

[Roundup Robot]

Change by Roundup Robot :


--
pull_requests: +4681

___
Python tracker 

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

[issue32258] Rewrite asyncio docs to use async/await syntax

[Andrew Svetlov]

Change by Andrew Svetlov :


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

___
Python tracker 

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

[issue32266] test_pathlib fails if current path has junctions

[Ivan Pozdeev]

Change by Ivan Pozdeev :


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

___
Python tracker 

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

[issue32266] test_pathlib fails if current path has junctions

[Ivan Pozdeev]

New submission from Ivan Pozdeev :

On this machine, C:\Users is a junction to D:\Users .

Sample failure:

Running Release|x64 interpreter...
FFFs...s..s.s.ss..FF...FFFs...s..s.s.ss..FF...
==
FAIL: test_complex_symlinks_absolute (__main__.PathTest)
--
Traceback (most recent call last):
  File "Lib\test\test_pathlib.py", line 2027, in test_complex_symlinks_absolute
self._check_complex_symlinks(BASE)
  File "Lib\test\test_pathlib.py", line 1994, in _check_complex_symlinks
self.assertEqual(p, P)
AssertionError: 
WindowsPath('D:/Users/Ivan/Documents/cpython_all/@test_2376_tmp') != 
WindowsPath('C:/Users/Ivan/Documents/cpython_all/@test_2376_tmp')

==
FAIL: test_complex_symlinks_relative (__main__.PathTest)
--
Traceback (most recent call last):
  File "Lib\test\test_pathlib.py", line 2031, in test_complex_symlinks_relative
self._check_complex_symlinks('.')
  File "Lib\test\test_pathlib.py", line 1994, in _check_complex_symlinks
self.assertEqual(p, P)
AssertionError: 
WindowsPath('D:/Users/Ivan/Documents/cpython_all/@test_2376_tmp') != 
WindowsPath('C:/Users/Ivan/Documents/cpython_all/@test_2376_tmp')

==
FAIL: test_complex_symlinks_relative_dot_dot (__main__.PathTest)
--
Traceback (most recent call last):
  File "Lib\test\test_pathlib.py", line 2035, in 
test_complex_symlinks_relative_dot_dot
self._check_complex_symlinks(os.path.join('dirA', '..'))
  File "Lib\test\test_pathlib.py", line 1994, in _check_complex_symlinks
self.assertEqual(p, P)
AssertionError: 
WindowsPath('D:/Users/Ivan/Documents/cpython_all/@test_2376_tmp') != 
WindowsPath('C:/Users/Ivan/Documents/cpython_all/@test_2376_tmp')

==
FAIL: test_resolve_common (__main__.PathTest)
--
Traceback (most recent call last):
  File "Lib\test\test_pathlib.py", line 1491, in test_resolve_common
os.path.join(BASE, 'foo'))
AssertionError: 'D:\\Users\\Ivan\\Documents\\cpython_all\\@test_2376_tmp\\foo' 
!= 'C:\\Users\\Ivan\\Documents\\cpython_all\\@test_2376_tmp\\foo'
- D:\Users\Ivan\Documents\cpython_all\@test_2376_tmp\foo
? ^
+ C:\Users\Ivan\Documents\cpython_all\@test_2376_tmp\foo
? ^


==
FAIL: test_resolve_dot (__main__.PathTest)
--
Traceback (most recent call last):
  File "Lib\test\test_pathlib.py", line 1550, in test_resolve_dot
self.assertEqual(q.resolve(strict=True), p)
AssertionError: 
WindowsPath('D:/Users/Ivan/Documents/cpython_all/@test_2376_tmp') != 
WindowsPath('C:/Users/Ivan/Documents/cpython_all/@test_2376_tmp')

==
FAIL: test_complex_symlinks_absolute (__main__.WindowsPathTest)
--
Traceback (most recent call last):
  File "Lib\test\test_pathlib.py", line 2027, in test_complex_symlinks_absolute
self._check_complex_symlinks(BASE)
  File "Lib\test\test_pathlib.py", line 1994, in _check_complex_symlinks
self.assertEqual(p, P)
AssertionError: 
WindowsPath('D:/Users/Ivan/Documents/cpython_all/@test_2376_tmp') != 
WindowsPath('C:/Users/Ivan/Documents/cpython_all/@test_2376_tmp')

==
FAIL: test_complex_symlinks_relative (__main__.WindowsPathTest)
--
Traceback (most recent call last):
  File "Lib\test\test_pathlib.py", line 2031, in test_complex_symlinks_relative
self._check_complex_symlinks('.')
  File "Lib\test\test_pathlib.py", line 1994, in _check_complex_symlinks
self.assertEqual(p, P)
AssertionError: 
WindowsPath('D:/Users/Ivan/Documents/cpython_all/@test_2376_tmp') != 
WindowsPath('C:/Users/Ivan/Documents/cpython_all/@test_2376_tmp')

==
FAIL: test_complex_symlinks_relative_dot_dot (__main__.WindowsPathTest)
--
Traceback (most recent call last):
  File