[issue32980] Remove functions that do nothing in _Py_InitializeCore()

[Nick Coghlan]

Nick Coghlan  added the comment:

Yeah, dropping _PyFrame_Init/Fini for 3.8+ would make sense.

It's PyByteArray_Init/Fini that probably aren't worth the hassle of removing, 
since the lack of a leading underscore means they'd need to go through a 
deprecation cycle.

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

___
Python tracker 

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

[issue32989] IDLE: Incorrect signature in call from editor to pyparse.find_good_parse_start

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Since _synchre is never passed, it should not be a parameter either.  I think 
we should either limit this to fixing the call, with no unit test added, or 
expand to 'fix find_good_parse_start and buggy call', with revised tests.

It might be interesting to verify that the time it takes to find a better start 
point is less that the time saved in later analysis.

--

___
Python tracker 

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

[issue32989] IDLE: Incorrect signature in call from editor to pyparse.find_good_parse_start

[Terry J. Reedy]

Terry J. Reedy  added the comment:

If fgps never returns 0, then returning 0 instead of None would allow 
simplification of

if bod is not None or startat == 1:
break
parser.set_lo(bod or 0)

to
if bod or startat == 1:
break
parser.set_lo(bod)

If it can (or should) ever return 0, separate from None, I would like to see a 
test case for that.  We could then think about whether or not the loop should 
break on 0 as well as None.

Perhaps separate issue: the 'if use_ps1' statements in editor and hyperparser, 
and a couple of lines before, is nearly identical, and could be factored into a 
separate editor method that returns a parser instance ready for analysis.  It 
could then be tested in isolation.  The method should return a parser instance 
ready for analysis.

Both blocks have an explicit set_lo(0) call, which does nothing, and could be 
removed.

--

___
Python tracker 

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

[issue32989] IDLE: Incorrect signature in call from editor to pyparse.find_good_parse_start

[Terry J. Reedy]

Terry J. Reedy  added the comment:

To be clear, the signature that got changed in 2005 is the signature for 
find_good_parse_start ('fgps'), which was previously

def find_good_parse_start(self, use_ps1, is_char_in_string=None,
 _synchre=_synchre)

When the use_ps1 parameter was removed, the 'if use_ps1' code was moved to the 
else: branch of the new 'if not use_ps1: ... else: ' in the editor method, but 
the call in question, moved into the 'if not use_ps1' branch, was not changed.  
The immediate fix is to remove the extra argument.

The similar call in the then new hyperparser module is correct.

 bod = parser.find_good_parse_start(
 editwin._build_char_in_string_func(startatindex))

The erroneous call has not been detected in execution because of this bug:
  not is_char_in_string
is too general.  It should have been specifically
  is_char_in_string is None
so False does not trigger the early return, but gets called, raising TypeError. 
 We should add a test that find_good_parse_start(False, lambda: True) does so, 
with reference to this issue.

Both calls to fgps (editor and hyperparser) pass 
_build_char_in_string_func(initial_start), which unconditionally returns a 
function.  So I think we can delete '=None' and the early return, rather than 
changing the early return condition.

--
stage:  -> test needed

___
Python tracker 

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

[issue32988] datetime.datetime.strftime('%s') always uses local timezone, even with aware datetimes

[Adam Williamson]

Adam Williamson  added the comment:

Yeah, I've added a comment there. I agree we can keep subsequent discussion in 
that issue. Closing this as a dupe.

I actually have the same thought as you, but I suspect making something that 
"worked" before start throwing an error might be a hard sell for some. Perhaps 
at least some kind of warning?

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

___
Python tracker 

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

[issue12750] add cross-platform support for %s strftime-format code

[Adam Williamson]

Adam Williamson  added the comment:

On the "attractive nuisance" angle: I just ran right into this problem, and 
reported https://bugs.python.org/issue32988 .

As I suggested there, if Python doesn't try to fix this, I'd suggest it should 
at least *explicitly document* that using %s is unsupported and dangerous in 
more than one way (might not work on all platforms, does not do what it should 
for 'aware' datetimes on platforms where it *does* work). I think explicitly 
telling people NOT to use it would be better than just not mentioning it. At 
least for me, when I saw real code using it and that the docs just didn't 
mention it, my initial thought was "I guess it must be OK, and the docs just 
missed it out for some reason". If I'd gone to the docs and seen an explicit 
note that it's not supported and doesn't work right, that would've been much 
clearer and I wouldn't have had to figure that out for myself :)

For Python 2, btw, the arrow library might be a suitable alternative to 
suggest: you can do something like this, assuming you have an aware datetime 
object called 'awaredate' you want to get the timestamp for:

import arrow
ts = arrow.get(awaredate).timestamp

and it does the right thing.

--
nosy: +adamwill

___
Python tracker 

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

[issue32988] datetime.datetime.strftime('%s') always uses local timezone, even with aware datetimes

[Paul Ganssle]

Paul Ganssle  added the comment:

I suspect discussion should be centralized in issue 12750, but if it were up to 
me %s would either work as expected or throw an error. Silently giving the 
wrong answer is a terrible compromise.

--

___
Python tracker 

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

[issue32988] datetime.datetime.strftime('%s') always uses local timezone, even with aware datetimes

[Adam Williamson]

Adam Williamson  added the comment:

I'd suggest that if that is the case, it would be better for the docs to 
*specifically mention* that `%s` is not supported and should not be used, 
rather than simply not mentioning it.

When it's used in real code (note someone in the SO issue mentions "I have been 
going crazy trying to figure out why i see strftime("%s") a lot, yet it's not 
in the docs") and just *not mentioned* in the docs, this tends to give the 
impression that it's something usable that was perhaps just forgotten from the 
docs, or something. The situation would be much clearer if the docs said "DO 
NOT USE THIS, IT'S DANGEROUS AND DOESN'T DO WHAT YOU THINK" in big letters. 
(And suggested using .timestamp() on Python 3.3+, and possibly arrow's 
.timestamp on 2.7?)

--

___
Python tracker 

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

[issue32988] datetime.datetime.strftime('%s') always uses local timezone, even with aware datetimes

[Adam Williamson]

Adam Williamson  added the comment:

Paul: right. This is on Linux - specifically Fedora Linux, but I don't think it 
matters. glibc strftime and strptime depend on an underlying struct called 
'tm'. 'man strftime' says:

   %s The number of seconds since the Epoch, 1970-01-01 00:00:00 + 
(UTC). (TZ) (Calculated from mktime(tm).)

And 'man mktime' says:

The  mktime() function converts a broken-down time structure, expressed as 
local time, to calendar time representation. ... On success, mktime() returns 
the calendar time (seconds since the Epoch), expressed as a value of type 
time_t."

I am finding it hard to determine whether various C standards require the tm 
struct and mktime and strftime and so on to handle timezones, but I'm sort of 
inclining to the answer that "no they don't".

Basically I suspect what's going on in this case is that the timezone 
information gets lost somewhere in the chain down from Python to system 
strftime to system mktime, and Python doesn't make any adjustment to the actual 
date / time values before calling system strftime to try and account for this.

I think Python must do *something* more than purely converting to a tm and 
calling system strftime, though, as %Z does work, which it wouldn't if Python 
was purely converting to a non-timezone-aware tm struct and calling system 
strftime, I don't think...

--

___
Python tracker 

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

[issue28124] Rework SSL module documentation

[Roundup Robot]

Change by Roundup Robot :


--
pull_requests: +5731

___
Python tracker 

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

[issue32988] datetime.datetime.strftime('%s') always uses local timezone, even with aware datetimes

[Paul Ganssle]

Paul Ganssle  added the comment:

It seems that %s is not supported and the fact that it works at all is 
incidental. See issue 12750 and this SO thread:

https://stackoverflow.com/questions/11743019/convert-python-datetime-to-epoch-with-strftime

--

___
Python tracker 

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

[issue32988] datetime.datetime.strftime('%s') always uses local timezone, even with aware datetimes

[Paul Ganssle]

Paul Ganssle  added the comment:

adamwill: I think datetime's strftime is a wrapper around the system strftime, 
so it varies between platforms. Might be useful to specify which platform you 
are seeing this behavior on.

--
nosy: +p-ganssle

___
Python tracker 

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

[issue32989] IDLE: Incorrect signature in call from editor to pyparse.find_good_parse_start

[Cheryl Sabella]

New submission from Cheryl Sabella :

>From msg312726 on issue32880.

The call to find_good_parse_start:

bod = y.find_good_parse_start(self.context_use_ps1, 
 self._build_char_in_string_func(startatindex))

sends 3 parameters.  And in pyparse.find_good_parse_start(), the signature 
allows 3.  However, the signature is:

def find_good_parse_start(self, is_char_in_string=None,
  _synchre=_synchre):


This means that the `False` value in `self.use_context_ps1` is the first value 
instead of the function, so pyparse is always executing:

if not is_char_in_string:
# no clue -- make the caller pass everything
return None


Here's the commit that changed the signature:
https://github.com/python/cpython/commit/b17544551fc8dfd1304d5679c6e444cad4d34d97

--
assignee: terry.reedy
components: IDLE
messages: 313170
nosy: csabella, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE: Incorrect signature in call from editor to 
pyparse.find_good_parse_start
type: enhancement
versions: Python 3.6, 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

[issue32880] IDLE: Fix and update and cleanup pyparse

[Cheryl Sabella]

Change by Cheryl Sabella :


--
dependencies: +IDLE: Incorrect signature in call from editor to 
pyparse.find_good_parse_start

___
Python tracker 

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

[issue32988] datetime.datetime.strftime('%s') always uses local timezone, even with aware datetimes

[Adam Williamson]

New submission from Adam Williamson :

Test script:

import pytz
import datetime
utc = pytz.timezone('UTC')
print(datetime.datetime(2017, 1, 1, tzinfo=utc).strftime('%s'))

Try running it with various system timezones:

[adamw@xps13k pagure (more-timezone-fun %)]$ TZ='UTC' python /tmp/test2.py
1483228800
[adamw@xps13k pagure (more-timezone-fun %)]$ TZ='America/Winnipeg' python 
/tmp/test2.py
1483250400
[adamw@xps13k pagure (more-timezone-fun %)]$ TZ='America/Vancouver' python 
/tmp/test2.py
1483257600

That's Python 2.7.14; same results with Python 3.6.4.

This does not seem correct. The correct Unix time for an aware datetime object 
should be a constant: for 2017-01-01 00:00 UTC it *is* 1483228800 . No matter 
what the system's local timezone, that should be the output of strftime('%s'), 
surely. What it seems to be doing instead is just outputting the Unix time for 
2017-01-01 00:00 in the system timezone.

I *do* note that strftime('%s') is completely undocumented in Python; neither 
https://docs.python.org/2/library/datetime.html#strftime-and-strptime-behavior 
nor 
https://docs.python.org/3/library/datetime.html#strftime-and-strptime-behavior 
mentions it. However, it does exist, and is used in the real world; I found 
this usage of it, and the bug, in a real project, Pagure.

--
components: Library (Lib)
messages: 313169
nosy: adamwill
priority: normal
severity: normal
status: open
title: datetime.datetime.strftime('%s') always uses local timezone, even with 
aware datetimes
versions: Python 2.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

[issue25427] Remove the pyvenv script in Python 3.8

[Brett Cannon]

Change by Brett Cannon :


--
keywords: +patch
pull_requests: +5730
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

[issue32987] tokenize.py parses unicode identifiers incorrectly

[Steve B]

New submission from Steve B :

Here is an example involving the unicode character MIDDLE DOT · : The line

ab·cd = 7

is valid Python 3 code and is happily accepted by the CPython interpreter. 
However, tokenize.py does not like it. It says that the middle-dot is an error 
token. Here is an example you can run to see that:

import tokenize
from io import BytesIO

test = 'ab·cd = 7'.encode('utf-8')

x = tokenize.tokenize(BytesIO(test).readline)
for i in x: print(i)

For reference, the official definition of identifiers is: 

https://docs.python.org/3.6/reference/lexical_analysis.html#identifiers

and details about MIDDLE DOT are at

https://www.unicode.org/Public/10.0.0/ucd/PropList.txt

MIDDLE DOT has the "Other_ID_Continue" property, so I think the interpreter is 
behaving correctly (i.e. consistent with the documented spec), while 
tokenize.py is wrong.

--
components: Library (Lib), Unicode
messages: 313168
nosy: ezio.melotti, steve, vstinner
priority: normal
severity: normal
status: open
title: tokenize.py parses unicode identifiers incorrectly
type: behavior
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

[issue32963] Python 2.7 tutorial claims source code is UTF-8 encoded

[Brett Cannon]

Brett Cannon  added the comment:

Thanks for the bug report, Martijn!

--
keywords:  -patch
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

[issue32963] Python 2.7 tutorial claims source code is UTF-8 encoded

[Brett Cannon]

Brett Cannon  added the comment:


New changeset 20003f9162631c47b79202316036d13d74484e4c by Brett Cannon in 
branch '2.7':
bpo-32963: Fix the tutorial to state source has a default encoding of ASCII 
(GH-5961)
https://github.com/python/cpython/commit/20003f9162631c47b79202316036d13d74484e4c


--

___
Python tracker 

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

[issue32758] Stack overflow when parse long expression to AST

[Brett Cannon]

Brett Cannon  added the comment:

The PR adds the documentation warnings. Serhiy, can you double-check that I 
have the appropriate functions and the comment is acceptable?

--

___
Python tracker 

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

[issue32963] Python 2.7 tutorial claims source code is UTF-8 encoded

[Brett Cannon]

Change by Brett Cannon :


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

___
Python tracker 

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

[issue32958] socket module calls with long host names can fail with idna codec error

[Aaron Black]

Aaron Black  added the comment:

Just to be clear, I don't know if the socket needs to support 64 character long 
host name sections, so here's an example url that is at the root of my problem 
that I'm pretty sure it should support:

>>> import socket
>>> h = 
>>> "username:long_api_key0123456789012345678901234567890123456...@www.example.com"
>>> socket.gethostbyname(h)
Traceback (most recent call last):
  File "/Users/ablack/miniconda3/lib/python3.6/encodings/idna.py", line 165, in 
encode
raise UnicodeError("label empty or too long")
UnicodeError: label empty or too long

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "", line 1, in 
UnicodeError: encoding with 'idna' codec failed (UnicodeError: label empty or 
too long)

--

___
Python tracker 

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

[issue32958] socket module calls with long host names can fail with idna codec error

[Ned Deily]

Ned Deily  added the comment:

Thanks for the report.  The behavior you see can be further isolated to 
socket.gethostbyname:

>>> import socket
>>> h = 
>>> "0123456789012345678901234567890123456789012345678901234567890123.example.com"
>>> socket.gethostbyname(h)
Traceback (most recent call last):
  File "/usr/lib/python3.6/encodings/idna.py", line 165, in encode
raise UnicodeError("label empty or too long")
UnicodeError: label empty or too long

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "", line 1, in 
UnicodeError: encoding with 'idna' codec failed (UnicodeError: label empty or 
too long)

Other socket module calls accepting host names fail similarly, such as 
getaddrinfo.

--
nosy: +ned.deily
stage:  -> needs patch
title: Urllib proxy_bypass crashes for urls containing long basic auth strings 
-> socket module calls with long host names can fail with idna codec error
type: crash -> 
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

[issue32758] Stack overflow when parse long expression to AST

[Brett Cannon]

Change by Brett Cannon :


--
keywords: +patch
pull_requests: +5728
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

[issue32985] subprocess.Popen: Confusing documentation for restore_signals

[Ned Deily]

Change by Ned Deily :


--
nosy: +giampaolo.rodola, gregory.p.smith

___
Python tracker 

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

[issue32732] LoggingAdapter ignores extra kwargs of Logger#log()

[Vinay Sajip]

Vinay Sajip  added the comment:

The existing LoggerAdapter functionality has been around since Jan 2008, and it 
seems that no one in that time has raised this as a must-have. In summary:

1. If you want to pass different kwargs in every time, use a logger.
2. If you want to pass particular contextual information in which fits the 
"extra" parameter approach, use a LoggerAdapter.
3. If that doesn't do it for you, subclass LoggerAdapter and implement what you 
need.

You haven't really explained why you need this to work in this particular way, 
so I suspect it could be an XY problem.

--

___
Python tracker 

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

[issue32986] multiprocessing, default assumption of Pool size unhelpful

[Ned Deily]

Change by Ned Deily :


--
nosy: +davin, pitrou

___
Python tracker 

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

[issue32955] IDLE crashes when trying to save a file

[Terry J. Reedy]

Terry J. Reedy  added the comment:

What do you mean by crash?  An exception from Python (which is not a crash)? or 
something from MacOS?

--

___
Python tracker 

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

[issue32933] mock_open does not support iteration around text files.

[Terry J. Reedy]

Change by Terry J. Reedy :


--
nosy: +ezio.melotti, michael.foord, rbcollins
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

[issue32983] UnicodeDecodeError 'ascii' codec can't decode byte in position - ordinal not in range(128)

[Glenn Linderman]

Glenn Linderman  added the comment:

The problem here is that the error message is trying to write to an output 
device using ASCII.  If there is no error, there is no error message print 
attempt. The error message, when written to an ASCII device, needs to be 
escaped.

You don't show the code, so it is hard to say more about the issue.

--
nosy: +v+python

___
Python tracker 

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

[issue32982] Parse out invisible Unicode characters?

[Glenn Linderman]

Glenn Linderman  added the comment:

Characters should not be stripped during compilation. But I can see where it 
might be helpful if the codepoint of the character, and the printed form just 
in case it is printable, could helpfully be included in the error message, as 
well as having the ^ pointer pointing to it.

--
nosy: +v+python

___
Python tracker 

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

[issue32963] Python 2.7 tutorial claims source code is UTF-8 encoded

[Mariatta Wijaya]

Mariatta Wijaya  added the comment:

I'm not intending to work on this, nothing until after PyCon :) Feel free to 
pick it up.

--

___
Python tracker 

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

[issue32963] Python 2.7 tutorial claims source code is UTF-8 encoded

[Brett Cannon]

Brett Cannon  added the comment:

If no one gets to this before the sprints at PyCon US I will take care of it, 
but anyone can feel free to submit a pull request to fix this.

--
assignee: docs@python -> brett.cannon
keywords: +easy

___
Python tracker 

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

[issue32378] test_npn_protocols broken with LibreSSL 2.6.1+

[Bernard Spil]

Bernard Spil  added the comment:

My pleasure! Glad we sorted this out for no-nextprotoneg and LibreSSL :D

--

___
Python tracker 

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

[issue32982] Parse out invisible Unicode characters?

[Matthew Barnett]

Matthew Barnett  added the comment:

For the record, '\u200e' is '\N{LEFT-TO-RIGHT MARK}'.

--
nosy: +mrabarnett

___
Python tracker 

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

[issue32968] Fraction modulo infinity should behave consistently with other numbers

[Elias Zamaria]

Elias Zamaria  added the comment:

Any suggestions as to what I should do? I can either update my pull request 
with my floordiv change, or create a new pull request, or wait a while to see 
if anyone else has any opinion on changing the behavior.

--

___
Python tracker 

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

[issue28134] socket.socket(fileno=fd) does not work as documented

[YoSTEALTH]

YoSTEALTH  added the comment:

It would be nice if "python" accounted for such low level os things. None the 
less client.detach() method works fine.

I really did enjoy your talk, kinda bummed it was short and didn't get into 
more details.

Thanks for your help and patience Christian :)

--

___
Python tracker 

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

[issue32984] IDLE: set and unset __file__ for startup files

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Revised, more exact, URL:
https://stackoverflow.com/questions/49054093/cannot-use-file-when-running-startup-file-in-idles-normal-mode

--

___
Python tracker 

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

[issue32984] IDLE: set and unset __file__ for startup files

[Terry J. Reedy]

Terry J. Reedy  added the comment:

When the IDLE GUI process is started, its main.__file__ is set to the idlelib 
.py file used to start the process.  If IDLE is started with -n, so that user 
code is run in the same process (the original mode), the -r or -s startup file 
and code entered at >>> sees this value*, rather than the user startup file 
name or a NameError.

* I am not sure why it does not see the value of __file__ in the pyshell 
module, which I would expect to be '.../idlelib/pyshell.py'.

The change proposed above would fix __file__ for -n also, but would disable any 
subsequently executed idle code that uses __file__ that gets unset.  So I think 
the wrapping should be conditioned on use_subprocess (True unless -n).

--

___
Python tracker 

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

[issue32986] multiprocessing, default assumption of Pool size unhelpful

[Roundup Robot]

Change by Roundup Robot :


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

___
Python tracker 

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

[issue32986] multiprocessing, default assumption of Pool size unhelpful

[M J Harvey]

New submission from M J Harvey :

Hi,

multiprocessing's default assumption about Pool size is os.cpu_count() ie all 
the cores visible to the OS.

This is tremendously unhelpful when running multiprocessing code inside an HPC 
batch system (PBS Pro in my case), as there's no way to hint to the code that 
the # of cpus actually allocated to it may be fewer.

It's quite tedious to have to explain this to every single person trying to use 
it.

Proposal: multiprocessing should look for a hint for default Pool size from the 
environment variable "NCPUS" which most batch systems set. If that's not set, 
or its value is invalid, fall back to os.cpu_count() as before

--
components: Library (Lib)
messages: 313150
nosy: M J Harvey
priority: normal
severity: normal
status: open
title: multiprocessing, default assumption of Pool size unhelpful
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

[issue32978] Issues with reading large float values in AIFC files

[Mark Dickinson]

Mark Dickinson  added the comment:

> But I don't know the exact format for infinities and NaNs.

>From the Intel software developer manuals:

For infinities:

Sign bit: 0 or 1 (positive or negative infinity)
Exponent field (15 bits): all ones
Significand (64 bits): first bit 1, all remaining bits 0.

NaN:

Sign bit: 0 or 1
Exponent field (15 bits): all ones
Significand (64 bits): first bit 1, at least one of the remaining bits 1.

--

___
Python tracker 

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

[issue32973] Importing the same extension module under multiple names breaks non-reinitialisable extension modules

[Stefan Behnel]

Stefan Behnel  added the comment:

> change the extension module cache to key on filename and init function name

... or on the pointer to the PyInit function. If that's the same, we obviously 
have the same extension module. If it differs, even for the same module name, 
then other globals of the modules will probably also be distinct.

--

___
Python tracker 

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

[issue32973] Importing the same extension module under multiple names breaks non-reinitialisable extension modules

[Stefan Behnel]

Change by Stefan Behnel :


--
components: +Extension Modules
nosy: +scoder

___
Python tracker 

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

[issue32978] Issues with reading large float values in AIFC files

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

But I don't know the exact format for infinities and NaNs.

--

___
Python tracker 

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

[issue32985] subprocess.Popen: Confusing documentation for restore_signals

[Alicia Boya García]

New submission from Alicia Boya García :

The docs state:

> If restore_signals is true (the default) all signals that Python has set to 
> SIG_IGN are restored to SIG_DFL in the child process before the exec. 
> Currently this includes the SIGPIPE, SIGXFZ and SIGXFSZ signals. (POSIX only)

The first phrase and the second may seem contradictory for anyone that uses 
signal handling in their code.

I would definitely not describe the set of "SIGPIPE, SIGXFZ and SIGXFSZ" as 
"all signals that Python has set". It actually means "all the signals that 
Python set at startup"; the user could have changed different signals than 
these (e.g. SIGINT) for various purposes (e.g. not getting a KeyboardInterrupt 
while an interactive process is running).

The current wording may suggest that all signals changed by the user are reset 
in the child process, but this is not the case -- I could confirm by looking at 
_Py_RestoreSignals(). Only these three specific signals are restored.

--
components: Library (Lib)
messages: 313146
nosy: ntrrgc
priority: normal
severity: normal
status: open
title: subprocess.Popen: Confusing documentation for restore_signals
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

[issue32978] Issues with reading large float values in AIFC files

[Mark Dickinson]

Mark Dickinson  added the comment:

> What if return 80-bit infinities and NaN as 64-bit infinities and NaN and 
> raise an error in the case of finite numbers overflow?

That's certainly reasonable from a pure floating-point-conversion perspective: 
it's exactly what I'd expect a general purpose extended-precision to 
double-precision converter to do.

--

___
Python tracker 

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

[issue32978] Issues with reading large float values in AIFC files

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

What if return 80-bit infinities and NaN as 64-bit infinities and NaN and raise 
an error in the case of finite numbers overflow?

--

___
Python tracker 

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

[issue32978] Issues with reading large float values in AIFC files

[Mark Dickinson]

Mark Dickinson  added the comment:

> If left the OverflowError propagated I would catch it at the caller place 
> (_read_float() is used only once) and reraise as aifc.Error.

Ah, if there's a dedicated exception type already then yes, agreed that raising 
aifc.Error (with a suitable message) makes much more sense than raising an 
OverflowError or a ValueError.

> if there are files with an exponent of 0x7fff in wild

I hope there aren't, and I'd consider any such file to be broken/corrupted. 
That is, unless there's a common practice of using NaNs or infinities for the 
frame rate. I suppose it's conceivable that people us this as a placeholder 
meaning "I don't know the sample rate". No idea whether that's true in 
practice: I'm not a frequent user of this format.

--

___
Python tracker 

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

[issue30811] A venv created and activated from within a virtualenv uses the outer virtualenv's site-packages rather than its own.

[Tzu-ping Chung]

Tzu-ping Chung  added the comment:

@cosven you are correct! I made some additional observation while working on 
adding venv support to pew, in this thread: 
https://github.com/berdario/pew/pull/173. I’ll try to summarise below.

The root problem is indeed virtualenv’s custom site module, but even then it is 
possible for venv (or any tool built around it) to know where the “original” 
Python is, since virtualenv stores the old sys.prefix in sys.real_prefix. 
Unfortunately, however, this is not as useful as it seems. What we really want 
in this situation is sys.exec_prefix, which may or may not be the same as 
sys.prefix. I did manage to cobble together a hack, but it is by no means 
bullet-proof.

To actually deal with this problem, we will need to amend the site module 
provided by virtualenv, as you mentioned. But this still can’t “solve” it. 
Since the site module is vendored in the produced virtualenv, existing 
virtualenvs will stay broken even after we managed to upgrade the virtualenv 
installations.

--

___
Python tracker 

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

[issue32978] Issues with reading large float values in AIFC files

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Thank you for your review Mark.

If left the OverflowError propagated I would catch it at the caller place 
(_read_float() is used only once) and reraise as aifc.Error. OverflowError is 
not expected exception. It never is raised for valid AIFC files, and the 
probability of raising it rather of aifc.Error for a random binary file is very 
small. I suppose that most users of this module don't catch it. See also 
issue32056.

But on other side, if there are files with an exponent of 0x7fff in wild, they 
are currently opened without errors. Raising an exception can be a regression.

--

___
Python tracker 

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

[issue32984] IDLE: set and unset __file__ for startup files

[Terry J. Reedy]

New submission from Terry J. Reedy :

'python somefile.py' sets main.__file__ to 'somefile.py'. 'python' leaves 
__file__ unset.  If PYTHONSTARTUP is set to somefile.py, 'python' executes 
somefile.py in main with __file__ set to 'somefile.py', then unsets __file__ 
before the >>> prompt, as if somefile has not been executed.  Any explicit 
setting of __file__ in somefile is undone.

tem2.py:
print(__name__, __file__)
__file__ = 'abc.py'

> F:\dev\3x> set PYTHONSTARTUP=f:/python/a/tem2.py
> F:\dev\3x> python
...
__main__ f:/python/a/tem2.py
>>> __file__
Traceback (most recent call last):
  File "", line 1, in 
NameError: name '__file__' is not defined

With IDLE, when 'python -m idlelib.idle' is run with '-s' or '-r 
f:/python/a/tem2.py', NameError is raised for the print in tem2.py. This was 
reported this SO question.
https://stackoverflow.com/questions/49054093/cannot-use-file-when-opening-module-in-idle
 

In both cases, the file is run with execfile(filename).

def execfile(self, filename, source=None):
"Execute an existing file"
if source is None:
with tokenize.open(filename) as fp:
source = fp.read()

My guess is that wrapping the source with f"__file__ = {filename}\n" and "del 
__file__\n" should work.

--
assignee: terry.reedy
components: IDLE
messages: 313140
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: IDLE: set and unset __file__ for startup files
type: behavior
versions: Python 3.6, 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

[issue32980] Remove functions that do nothing in _Py_InitializeCore()

[Benjamin Peterson]

Benjamin Peterson  added the comment:

Future maintainers of what exactly can expect these functions to be called? 
CPython? If we need to do initialization of frameobject.c later, we can simply 
add _PyFrame_Init back. We certainly don't support ELF-interposition of 
_PyFrame_Init as an API.

Historically, we've been sloppy about putting private and public APIs in the 
same header files. But the leading underscore still means private; such APIs 
serve at our pleasure.

--
nosy: +benjamin.peterson

___
Python tracker 

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

[issue3177] Add shutil.open

[Socob]

Change by Socob <206a8...@opayq.com>:


--
nosy: +Socob

___
Python tracker 

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

[issue32973] Importing the same extension module under multiple names breaks non-reinitialisable extension modules

[Petr Viktorin]

Petr Viktorin  added the comment:

Well, PEP 489 basically punts this to module authors: generally, C globals are 
bad, but if you do have global state, please manage it, keeping in mind that 
multiple module objects can be created from the extension.

That's required to make everything work with subinterpreters.

See: 
https://www.python.org/dev/peps/pep-0489/#subinterpreters-and-interpreter-reloading

CCing Marcel, who's working on PEP 489-related stuff now.

--
nosy: +Dormouse759

___
Python tracker 

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

[issue32973] Importing the same extension module under multiple names breaks non-reinitialisable extension modules

[Eric Snow]

Eric Snow  added the comment:

PEP 489 ("Multi-phase extension module initialization") is relevant here, so 
I've nosied Petr.

--
nosy: +encukou

___
Python tracker 

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

[issue32978] Issues with reading large float values in AIFC files

[Mark Dickinson]

Mark Dickinson  added the comment:

> And I think that using math.ldexp() can be more preferable that pow(2.0, ...)

Yes, absolutely agreed. I'll take a look at the PR.

--

___
Python tracker 

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

[issue32968] Fraction modulo infinity should behave consistently with other numbers

[Mark Dickinson]

Mark Dickinson  added the comment:

[Elias Zamaria]

> I see exactly that.

Understood; that's how I interpreted your "changed one test to make sure that 
it works". It seems we understand each other. :-)

So yes, one always needs to be very cautious about changing deliberate, tested 
behaviour. But in this case I'm satisfied that I understand what the intent was 
when that test was written, namely that `Real.__floordiv__` returns an 
`Integral`. And since that part of PEP 3141 didn't actually get implemented for 
float // float (and the agreement on #22444 was that the PEP should be changed 
rather than the behaviour), that intent is now a little bogus, and I think it's 
reasonable to change the behaviour in this case. The change would make the 
overall behaviour of mixed-type operations simple to state and understand, and 
fix a consistency bug. It's also sufficiently much of a corner case that the 
change seems unlikely to break existing code.

In short, I'm +1 on making your suggested change to __floordiv__ as well as to 
__mod__.

I'm adding Jeffrey Yasskin (the original PEP 3141 author) to the nosy list, in 
case he has any comment. (I don't believe Jeffrey is still watching Python 
development, but would be happy to be proved wrong.)

--
nosy: +jyasskin

___
Python tracker 

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

[issue32983] UnicodeDecodeError 'ascii' codec can't decode byte in position - ordinal not in range(128)

[Jiri Prajzner]

Jiri Prajzner  added the comment:

Locate 
"\u179a\u1794\u17b6\u179a\u200b\u17a7\u1794\u1780\u179a\u178e\u17cd\u200b\u179a\u17bb\u1780\u179a\u1780\u200b"->"\u179f\u17d2\u179c\u17c2\u1784\u179a\u1780
 
\u17ac\u200b\u1794\u1789\u17d2\u1785\u17bc\u179b\u200b\u17a2\u17b6\u179f\u1799\u178a\u17d2\u178b\u17b6\u1793"
 and browse "http://www.google.com"; website 

versus 

Locate 
"\u179a\u1794\u17b6\u179a\u200b\u1798\u17c9\u17ba\u1793\u17bb\u1799"->"\u179f\u17d2\u179c\u17c2\u1784\u179a\u1780
 
\u17ac\u200b\u1794\u1789\u17d2\u1785\u17bc\u179b\u200b\u17a2\u17b6\u179f\u1799\u178a\u17d2\u178b\u17b6\u1793"
 and browse "http://www.columbia.edu/~fdc/utf8/"; website - this is km_KH.utf8 
locale. msg313133 is ja_JP.utf8 locale

it looks like python unicode decode cannot compare strings well in these 
locales.

--

___
Python tracker 

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

[issue32983] UnicodeDecodeError 'ascii' codec can't decode byte in position - ordinal not in range(128)

[Jiri Prajzner]

Jiri Prajzner  added the comment:

Locate "URL 
\u307e\u305f\u306f\u691c\u7d22\u8a9e\u53e5\u3092\u5165\u529b\u3057\u307e\u3059"->"URL
 
\u307e\u305f\u306f\u691c\u7d22\u8a9e\u53e5\u3092\u5165\u529b\u3057\u307e\u3059" 
and browse "http://www.google.com"; website throws the same error. if the first 
"URL 
\u307e\u305f\u306f\u691c\u7d22\u8a9e\u53e5\u3092\u5165\u529b\u3057\u307e\u3059" 
is replaced with 
"\u30ca\u30d3\u30b2\u30fc\u30b7\u30e7\u30f3\u30c4\u30fc\u30eb\u30d0\u30fc" that 
is actually expected, there's no error.

--

___
Python tracker 

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

[issue32983] UnicodeDecodeError 'ascii' codec can't decode byte in position - ordinal not in range(128)

[Jiri Prajzner]

New submission from Jiri Prajzner :

Locate "Barra de navegació"->"Término de búsqueda o dirección" and browse 
"http://www.columbia.edu/~fdc/utf8/"; website - results in:
Exception UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 
73: ordinal not in range(128)

If i correct the word navegació to navegación, there's no UnicodeDecodeError

--
components: Unicode
messages: 313132
nosy: Jiri Prajzner, ezio.melotti, vstinner
priority: normal
severity: normal
status: open
title: UnicodeDecodeError 'ascii' codec can't decode byte in position - ordinal 
not in range(128)
type: compile error
versions: Python 2.7

___
Python tracker 

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

[issue32430] Simplify Modules/Setup{,.dist,.local}

[Kubilay Kocak]

Change by Kubilay Kocak :


--
nosy: +koobs

___
Python tracker 

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

[issue30811] A venv created and activated from within a virtualenv uses the outer virtualenv's site-packages rather than its own.

[cosven]

cosven  added the comment:

It is actually a bug in virtualenv instead of venv.

> the outer environment's pip leaks into the inner environment;

This is true, but why? In short, the inner-env python binary
use `outer-env/` directory as its `prefix` direcotry,
but the `inner-env/` directory is the right `prefix` directory.

When the Python binary is executed, it attempts to determine
its `prefix` (which it stores in sys.prefix), which is then used
to find the standard library and other key files, and by the
`site` module to determine the location of the site-package directories.

However, virtualenv has its own `site` module, which is different
implemented from the site module in stdlib. It makes the inner-python
get a wrong `prefix` value.

> (Could a fix on virtualenv's side help?)
In my own opinion, if virtualenv change its implementation of site.py,
there is a change to fix this.

--
nosy: +cosven

___
Python tracker 

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

[issue32980] Remove functions that do nothing in _Py_InitializeCore()

[Nick Coghlan]

Nick Coghlan  added the comment:

(Bringing my response from core-mentorship over to the main tracker)

These APIs are exposed to embedding applications via the pylifecycle header: 
https://github.com/python/cpython/blob/master/Include/pylifecycle.h#L143

While we technically *could* deprecate & remove them (since we're not currently 
using them for anything), the current cost/benefit assessment is that it isn't 
worth the API churn (even for the underscore prefixed _PyFrame_Init API) when 
it's relatively cheap to keep them around as no-ops.

Given that they exist in the code base in order to continue exporting the 
symbols though, future maintainers are entitled to expect that we'll keep 
calling them in the appropriate places, such that if anyone *does* add code to 
them in the future, that code will "just work".

--
nosy: +ncoghlan
resolution:  -> not a bug
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

[issue32964] Reuse a testing implementation of the path protocol in tests

[miss-islington]

miss-islington  added the comment:


New changeset a13b65422a1078104e9f53ad41945ea380a80798 by Miss Islington (bot) 
in branch '3.7':
bpo-32964: Reuse a testing implementation of the path protocol in tests. 
(GH-5930)
https://github.com/python/cpython/commit/a13b65422a1078104e9f53ad41945ea380a80798


--
nosy: +miss-islington

___
Python tracker 

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

[issue32964] Reuse a testing implementation of the path protocol in tests

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
pull_requests: +5725

___
Python tracker 

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

[issue32964] Reuse a testing implementation of the path protocol in tests

[miss-islington]

Change by miss-islington :


--
pull_requests: +5724

___
Python tracker 

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

[issue32964] Reuse a testing implementation of the path protocol in tests

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset b21d155f57d284aecf9092a9bd24258293965c2f by Serhiy Storchaka in 
branch 'master':
bpo-32964: Reuse a testing implementation of the path protocol in tests. (#5930)
https://github.com/python/cpython/commit/b21d155f57d284aecf9092a9bd24258293965c2f


--

___
Python tracker 

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