[issue31635] test_strptime failure on OpenBSD

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

I used OpenBSD 6.1. I'll check on more modern versions when have chance.

--

___
Python tracker 

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

[issue34659] Inconsistency between functools.reduce & itertools.accumulate

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

This looks like a duplicate of issue25193.

See also a long discussion on the Python-ideas mailing list 5 months ago: 
[Start argument for 
itertools.accumulate()](https://mail.python.org/pipermail/python-ideas/2018-April/049649.html).

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue34673] make the eval loop more editable

[Benjamin Peterson]

Benjamin Peterson  added the comment:


New changeset ddd1949fea59f256e51191540a4446f75ed608fa by Benjamin Peterson in 
branch 'master':
closes bpo-34673: Tweaks to make ceval more editable. (GH-9289)
https://github.com/python/cpython/commit/ddd1949fea59f256e51191540a4446f75ed608fa


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

[issue34709] Suggestion: make getuser.getpass() also look at SUDO_USER environment variable

[Amos S]

New submission from Amos S :

When doing "sudo python-script.py", the output of "getpass.getuser()" is pretty 
much useless for what it's used (I assume mainly logging and tracking purposes, 
that's what we use it for ourselves).

I worked around this limitation by using it in expression likes:

  username = os.environ.get("SUDO_USER") or getpass.getuser()

I think it'll be useful to many other users if getpass.getuser() could 
integrate this behavior.

I'd love to provide the code change if this is approved.

--
messages: 325511
nosy: Amos S
priority: normal
severity: normal
status: open
title: Suggestion: make getuser.getpass() also look at SUDO_USER environment 
variable
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5, 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

[issue34708] Odd crashes/freezes when sys.stdout.shell.console is typed

[Harrison Chudleigh]

Change by Harrison Chudleigh :


--
type:  -> crash

___
Python tracker 

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

[issue34708] Odd crashes/freezes when sys.stdout.shell.console is typed

[Harrison Chudleigh]

Harrison Chudleigh  added the comment:

Edit: I checked Python 3.4 (Windows XP SP3). It hangs in the same way as Python 
3.6/3.7.

--

___
Python tracker 

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

[issue34708] Odd crashes/freezes when sys.stdout.shell.console is typed

[Harrison Chudleigh]

New submission from Harrison Chudleigh 
:

If sys is imported and sys.stdout.shell.console is typed, IDLE does not return 
to the prompt. Ctrl-C has no effect and after a restart with Ctrl-F6, IDLE does 
not react after a command is typed in. This also occurs when other variables 
such as sys.stdout.shell.stdout are used, but not with non-existent variables 
such as sys.stdout.shell.not_a_variable. No such issue occurs using the command 
line; however, sys.stdout.shell is not defined in the command line. This 
behaviour exists in at least Python 3.6.1 and 3.7.0 on Mac OS X 10.9.

This might be related to a similar issue that occurs in at least Python 3.2 on 
Windows 2000. Entering sys.stdout.shell.console causes IDLE to crash 
immediately; a crash also occurs when you type sys.stdout.shell.console. and 
wait for IDLE to bring up the list of attributes.

I know that this bug shouldn't be encountered unless you're using the IDLE 
PyShell object for some reason, but it still seems weird that getting the value 
of a variable causes crashes and hangs, especially when I know that the 
variable exists from looking at idlelib.

This is marked as Python 3.4 to 3.7 because I tested with 3.7, 3.6 and 3.2 and 
I don't think that this would have been fixed and then broken again. I don't 
know about 3.8, though.

--
assignee: terry.reedy
components: IDLE
files: fail.py
messages: 325509
nosy: Harrison Chudleigh, terry.reedy
priority: normal
severity: normal
status: open
title: Odd crashes/freezes when sys.stdout.shell.console is typed
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7
Added file: https://bugs.python.org/file47808/fail.py

___
Python tracker 

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

[issue34707] Python not reentrant

[john skaller]

New submission from john skaller :

Executive Summary: Python currently is not properly re-entrant. This comment 
applies to the CAPI and particularly embedding. A fix is not possible in Python 
3.x but should be scheduled for Python 4. On Linux all binary plugins are 
broken as well.

The fault is exhibited by the need to first call PyInitialise(). This is 
clearly wrong because there is nowhere to put the initialised data. The correct 
sequence should be to first create an interpreter handle, and then initialise 
that. Other API calls exhibit the same fault. For example PyErr_Occured().

Use of thread local storage is NOT enough.

A general embedding scenario is this: a thunk program is used to dynamically 
load a shared library and execute a function in it. That function may load 
other shared libraries. Note carefully there is no global data, the libraries 
are pure code. [This is not an imagined scenario, my whole system works this 
way]

The same library may be loaded several times. For example, A can load B and C, 
and both B and C can load D. Proper visibility control means A cannot see any 
symbols of D.

In this scenario if D wishes to run a Python interpreter, it must call 
PyInitialise(), and it will be called twice, since D is called twice, once from 
A, and once from B. Indeed, if the top level spawns multiple threads, it can be 
called many more times than that. 

Remember the libraries are pure code and fully reentrant. There is no way to 
record if a function has been called already.

In order for Python to be fully re-entrant there is a simple test: if the C 
code of the Python library contains ANY global variables at all then Python is 
wrong. Global variables INCLUDE thread local storage. ALL data and ALL 
functions must hang off a handle so that all functionality and behaviour is 
fully isolated to each handle.

Exceptions to the rule: poorly designed OS such as Unix have some non-reentrant 
features. The worst of these in Unix is signal handling. It is not possible to 
handle signals without a global variable to communicate between the signal 
handler and application. The right way to do this would have been to use a 
polling service to detect the signal. In any case systems like Python do have 
to work with badly designed API's sometimes and therefore these special cases 
do form legitimate exceptions to the requirement that the API be re-entrant. My 
recommendation is to provide a cheat API which looks re-entrant but actually 
isn't, because it delegates to a hidden lower level which isn't, of necessity. 
YMMV: how to handle bad underlying API's should be open for discussion.

Other consequences: On linux at least ALL plugin extensions are built 
incorrectly. The correct way to build a plugin requires explicitly linking 
against the Python library, so that symbols in the Python API can be found. 
These symbols must NOT be found in the application because this is, quite 
simply, not possible, if the application does not include those symbols. In my 
scenario, the top level application is three lines of C than does nothing other 
than load a library and run a fixed function in it. And that library has no 
idea that one of the libraries IT loads may call another library which happens 
to want to run some Python code. Indeed my system can *generate* Python 
modules, and compile and link them against the Python library, but it cannot 
load any existing plugins on Linux, because those plugins were incorrectly 
built and do not link to the Python library as they should. They expect to find 
symbols in the symbol table magically provided but those symbols are not there.

On OSX, however, it works. That is because on OSX, a --framework is used to 
contain the Python library and all plugins HAVE to be linked against the 
framework. I expect the Windows builds to work too, for the same reason (but 
I'm not sure).

This issue is related to the lack of re-entrancy because the same principle is 
broken in both cases. If you need a service, you must ask for it, and when you 
get it, it is exclusively yours.

--
components: Interpreter Core
messages: 325508
nosy: skaller
priority: normal
severity: normal
status: open
title: Python not reentrant
type: behavior
versions: Python 3.8

___
Python tracker 

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

[issue34660] Replace ableist terms and pejoratives in source code.

[Carol Willing]

Carol Willing  added the comment:

Hi all,

I'm going to close this issue for now. As I mentioned earlier (sorry Terry for 
not being clearer), I will be doing a comprehensive review of the docs and 
source code over the next few months. I will make recommendations as PRs and 
issues as I go through the review (see #msg325291).

In the review, I will take into account PSF values, clarity in source code as 
well as testing of code changes, and best practices in documentation.

Thanks everyone for respecting my intent to treat this review in a respectful 
and thoughtful manner.

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

[issue34660] Replace ableist terms and pejoratives in source code.

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Gabriel, I believe I addressed most your concerns in my previous post.  You 
might reread it in that light.  

There seems to be a misperception that we have collectively changed how we 
judge doc proposals.  Should we 'announce' that we proceed as we have been?

Are you are suggesting that we judge proposals by the proposer, rather than the 
substance of the proposal? In general, I should hope we do not have to.

If you want to be concretely helpful, comment on one or more of the specific 
proposals in PR9335, forgetting who made the proposal and why.  Or, pretend 
that I suggested making those changes for better clarity.  (But skip the 
multiple 'crazy' to 'weird' changes, as I have decided against those.)

--

___
Python tracker 

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

[issue33649] asyncio docs overhaul

[Yury Selivanov]

Yury Selivanov  added the comment:


New changeset 5cc583d94095ed3bb543fa2f032f9593a6315a52 by Yury Selivanov 
(Bumsik Kim) in branch 'master':
bpo-33649: Clarify protocol_factory as a method parameter (GH-9330)
https://github.com/python/cpython/commit/5cc583d94095ed3bb543fa2f032f9593a6315a52


--

___
Python tracker 

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

[issue34694] Dismiss To Avoid Slave/Master wording cause it easier for non English spoken programmers

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Jose: The purpose of the tracker is to facilitate patches to the CPython code 
and docs.  Your post and personal perspective (with 'srecentrly uddenly' 
corrected),though related, belongs elsewhere, such as python-list.

Gabriel: Insults so not solve issues.  Rather they discourage people from 
volunteering to improve Python.  They are a violation of the Code of Conduct.  
Please consider this a warning and don't repeat.

--
components:  -2to3 (2.x to 3.x conversion tool), Argument Clinic, Build, 
Cross-Build, Demos and Tools, Distutils, Documentation, Extension Modules, 
FreeBSD, IDLE, IO, Installation, Interpreter Core, Library (Lib), Regular 
Expressions, SSL, Tests, Tkinter, Unicode, Windows, XML, asyncio, ctypes, 
email, macOS

___
Python tracker 

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

[issue34660] Replace ableist terms and pejoratives in source code.

[Gabriel Marko]

Gabriel Marko  added the comment:

@terry.reedy: By madness I meant:

1. blank replacement of words without relevant justification. Collecting 5 
links and labelling some words as pejorative or ist or do it for 
“diversity reasons” etc. is no justification. I have no problem with changing 
wording in documentation but it has to be justified.

2. that IMO this is _de facto_ PC/SJW language mutilation/censorship. I've made 
my main claim about that here: https://bugs.python.org/issue34605#msg324825 and 
IMO this is a continuation of the BPO34605 which is not any better or even 
worse than this one. I also expect more BPOs and PRs like this and IMHO _no 
more BPOs or PRs like this should be accepted or merged_.

If I can advise: There should be a clear statement about how PSF and core 
developers will handle BPOs and PRs like this or BPO34605 i.e. if you 
accept/reject them in the future eventually what is going to be the rule of 
thumb for acceptance. It can bring some clarity into this whole 
issue/discussion. What I’ve experienced so far is very disappointing. Repeating 
“there will be no more discussion about this” is not a solution and I consider 
this to be damaging for Python community’s reputation.

--

___
Python tracker 

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

[issue34706] Signature.from_callable sometimes drops subclassing

[Buck Evan]

Change by Buck Evan :


--
type:  -> behavior

___
Python tracker 

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

[issue34659] Inconsistency between functools.reduce & itertools.accumulate

[Lisa Roach]

Change by Lisa Roach :


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

___
Python tracker 

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

[issue34660] Replace ableist terms and pejoratives in source code.

[Terry J. Reedy]

Terry J. Reedy  added the comment:

David and Brett: I consider part of the actions of the anonymous person using 
the temporary aliases 25.45 and jonsees to be violations of our Code of 
Conduct.  I would therefore like you two to issue a warning, if not a ban.

I consider the first part of the initial message to be arrogant and rude.  I 
let that go, took "The goal of this issue is not to stir up arguments, but to 
figure out the alternatives and ways to replace those problematic terms." at 
face value, re-opened the issue, and reviewed the second PR.  In response, 
'jonsees' refused to fix the bug and make or discuss the other requested 
revisions, but instead insulted and lied*.  In other words, 'argument' rather 
than 'figuring out'.  This treatment of my volunteer efforts makes me less 
willing to contribute more.

* In the context of Victor's changes on another issue, Raymond merging his 
first PR, Carol's promise to review the docs for inconsiderate language, and me 
reviewing the second PR and approving parts thereof, "Python developers have no 
desire of actually accepting any of these changes" is an insulting lie.
---

Gabriel: From what you wrote here, it was not immediately clear what 'madness' 
you want stopped.  The presence of certain words in the docs?  Or the blanket 
removal of certain words from the docs?  I am guessing the latter.  If so, that 
is not what any core devs that I know of are openly advocating.

The fact that I have to guess illustrates what I wrote in the review: "the 
'sin' of these words is that they tend to be vague and say more about the 
writer's opinion than about the ostensible subject."  Do you think it madness 
to replace vague (and somewhat sloppy) words with more precise words that 
better communicate real meaning to users?  That is what Raymond did and what I 
intended to do.
---

I am leaving this issue open so that I can at least remove "Windows is lunatic" 
in a new PR.

--
nosy: +brett.cannon, r.david.murray

___
Python tracker 

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

[issue34706] Signature.from_callable sometimes drops subclassing

[Roundup Robot]

Change by Roundup Robot :


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

___
Python tracker 

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

[issue34706] Signature.from_callable sometimes drops subclassing

[Buck Evan]

New submission from Buck Evan :

Specifically in the case of a class that does not override its constructor 
signature inherited from object.

Github PR incoming shortly.

--
components: Library (Lib)
messages: 325501
nosy: bukzor
priority: normal
severity: normal
status: open
title: Signature.from_callable sometimes drops subclassing
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

[issue34605] Avoid master/slave terminology

[Gabriel Marko]

Gabriel Marko  added the comment:

@serhiy.storchaka: IMO, the problem isn't the master/slave terminology itself 
but the way how the changes were introduced (no discussion) and the 
justification ("diversity reasons"???).

IMO this is the next level: https://bugs.python.org/issue34660 and I can't 
imagine what comes next. I find this nonsensical and I'm very disappointed that 
this ideological nonsense is infecting Python.

IMO the core developers should make a clear statement about this (either pro or 
contra). Once it's made, I'll have no other choice than respect that stance and 
act accordingly. Saying that "there will be not more discussions" or sending 
people to twitter like Guido did is not a solution and it's rather damaging the 
Python community and its reputation. :(

--

___
Python tracker 

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

[issue34694] Dismiss To Avoid Slave/Master wording cause it easier for non English spoken programmers

[Gabriel Marko]

Gabriel Marko  added the comment:

@Mariatta:

> There will be no further discussion about this.

Repeating this over and over again won't solve the (any) issue. This madness 
reached another level here: https://bugs.python.org/issue34660. That was 
exactly my point here: https://bugs.python.org/issue34605#msg324825. 
But let me guess: There will no (further) discussion about that 
either. 

I find this behavior from the Python core developers and representatives simply 
irresponsible.

--
nosy: +suic

___
Python tracker 

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

[issue34561] Replace list sorting merge_collapse()?

[Tim Peters]

Tim Peters  added the comment:

Another runstack.py adds a bad case for 2-merge, and an even worse 
(percentage-wise) bad case for timsort.  powersort happens to be optimal for 
both.

So they all have contrived bad cases now.  powersort's bad cases are the least 
bad.  So far ;-)  But I expect that to remain so.

--
Added file: https://bugs.python.org/file47807/runstack.py

___
Python tracker 

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

[issue31635] test_strptime failure on OpenBSD

[Paul Ganssle]

Paul Ganssle  added the comment:

This appears to be a duplicate of issue #13414, which was resolved as fixed in 
BSD. @serhiy Are you using a very old version of BSD?

--

___
Python tracker 

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

[issue31635] test_strptime failure on OpenBSD

[Paul Ganssle]

Paul Ganssle  added the comment:

I think this is the relevant test: 
https://github.com/python/cpython/blob/3.7/Lib/test/test_strptime.py#L536

The issue seems to be in `strftime` rather than in `strptime`. According to 
Serhiy's paste, it seems that `datetime.datetime.strftime("%G %V %w")` on BSD 
results in "1904 53 0", whereas on Linux it results in "1904 52 0".

I suspect the confusion *may* be related to the fact that ISO weekdays go 
Monday (1) to Sunday (7), where as %w goes Sunday (0) to Saturday (6).

--

___
Python tracker 

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

[issue32313] Wrong inspect.getsource for datetime

[Paul Ganssle]

Paul Ganssle  added the comment:

I think this is *mostly* the correct behavior (though it may indeed be 
confusing). Note that `datetime.py` *is* the source of the module `datetime`, 
it's just that most of the code in there is shadowed by the line you've linked.

If you try and get the source of individual methods that were imported from 
`_datetime`, you'll get the expected failure:

>>> inspect.getsource(datetime.datetime.fromisoformat)
-- Long traceback --
TypeError: module, class, method, function, traceback, frame, or code object 
was expected, got builtin_function_or_method


That said, `inspect.getsource` does seem to be erroneously using the Python 
source for classes, e.g. `print(inspect.getsource(datetime.date))`

This is consistent with the behavior of `functools`, where the Python code for 
`functools.partial`, even when the C implementation is used.

Not sure if this is something that should be a warning, an exception or if the 
behavior should simply be documented in the `inspect` documentation.

I'll note that both `inspect.getsource(datetime)` and 
`inspect.getsource(datetime.date)` were IOError exceptions in Python 2.7, but 
have been returning the Python source code since at least Python 3.4.

--
components: +Library (Lib)
nosy: +belopolsky, yselivanov
type:  -> behavior
versions: +Python 3.4, Python 3.5, 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

[issue34363] dataclasses.asdict() mishandles dataclass instance attributes that are instances of subclassed typing.NamedTuple

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

> [..] but I think it's the best we can do. It's consistent with any other 
> class derived from tuple or list: [...]

I agree with this argument. Sorry for delay with my response and thank you Eric 
for taking care about this issue!

--

___
Python tracker 

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

[issue34682] Typo reports on docs@

[ZooDSS]

ZooDSS  added the comment:

Wanted to add a little bit more, but didn't know where to, so here it goes.

https://docs.python.org/3/reference/expressions.html#membership-test-operations

"The operator not in is defined to have the inverse true value of in." may be 
better to use "... the inverse truth value of in." as it is used in the next 
section, for identity comparisons explanation:

"x is not y yields the inverse truth value."


https://docs.python.org/3/reference/expressions.html#is-not

In this section "object identity" is used two times. May be better to say 
"object's identity", as identity is a part of an object. Object has identity.

"...test for object identity" - here.
"Object identity is determined..." - and here.

--
nosy: +ZooDSS

___
Python tracker 

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

[issue34589] Py_Initialize() and Py_Main() should not enable C locale coercion

[Nick Coghlan]

Nick Coghlan  added the comment:

I'd strongly prefer to just go back to the PEP 538 design. It's much simpler to 
implement, we don't actually want anyone turning off locale coercion except for 
debugging purposes (unlike UTF-8 mode), and the only argument against doing 
this the way PEP 538 describes is a purist one, not a practical one (which was 
already resolved in favour of practicality when PEP 538 was accepted).

However, if you were willing to do the updates on my PR branch to implement it, 
then I'd accept an alternative that added a pass through the command line 
arguments that checks for at least one of the two following cases after a 
legacy locale has been detected:

- the new option "-X coerce_c_locale=0" (ASCII) is present in the arg list
- neither "-E" nor "-I" (ASCII) are present in the arg list, and 
PYTHONCOERCECLOCALE is not set to zero

The code that sets warn_on_c_locale in the core config would then look for `-X 
coerce_c_locale=warn` in addition to looking for `PYTHONCOERCECLOCALE=warn`.

That's quite a bit of code to add for the sake of a flag we don't really want 
anyone to ever use, though. (If it hadn't been for the 
debugging-CentOS-7-problems-on-Fedora issue, I doubt I would have included the 
off switch in PEP 538 at all)

--

___
Python tracker 

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

[issue21109] tarfile: Traversal attack vulnerability

[Tal Einat]

Tal Einat  added the comment:

For one thing, the new diffs are still missing tests.

Tests should include, at the least:

1. *Safely* testing SafeTarFile against examples of problematic tarballs. 
Perhaps from Jakub's collection of "sly" tarballs could be used, assuming those 
could be licensed appropriately.
2. SafeTarFile should pass all of the normal TarFile tests.

--

___
Python tracker 

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

[issue34705] Python 3.8 changes how returns through finally clauses are traced

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Humm, the optimization is not related here. Even if it is not involved (replace 
17 with []), the line 4 is reported twice, because RETURN_VALUE is executed 
after CALL_FINALLY.

  4  10 BUILD_LIST   0
 12 POP_BLOCK
 14 CALL_FINALLY 2 (to 18)
 16 RETURN_VALUE

In 3.7 RETURN_VALUE was the opcode executed at line 4. The stack of blocks was 
unwinded at interpreted loop implicitly when execute RETURN_VALUE. But in 3.8 
calling the finally code is explicit.

--
nosy: +Mark.Shannon

___
Python tracker 

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

[issue29883] asyncio: Windows Proactor Event Loop UDP Support

[Carol Willing]

Change by Carol Willing :


--
nosy: +willingc
stage: test needed -> patch review

___
Python tracker 

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

[issue34705] Python 3.8 changes how returns through finally clauses are traced

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

This is a side effect of specific optimization. If the return value is 
constant, it is pushed on the stack after executing the finally code (see 
LOAD_CONST at offset 14 below). But other opcodes at this line (POP_BLOCK and 
CALL_FINALLY) are executed after executing the finally code. Thus it looks like 
the line 4 is executed twice, but actually different opcodes marked with the 
same line are executed before and after executing the finally code.

Disassembly of ", line 1>:
  2   0 SETUP_FINALLY   16 (to 18)

  3   2 LOAD_GLOBAL  0 (print)
  4 LOAD_CONST   1 ('returning')
  6 CALL_FUNCTION1
  8 POP_TOP

  4  10 POP_BLOCK
 12 CALL_FINALLY 4 (to 18)
 14 LOAD_CONST   2 (17)
 16 RETURN_VALUE

  6 >>   18 LOAD_GLOBAL  0 (print)
 20 LOAD_CONST   3 ('finally')
 22 CALL_FUNCTION1
 24 POP_TOP
 26 END_FINALLY
 28 LOAD_CONST   0 (None)
 30 RETURN_VALUE

The benefit of this optimization is that it can make the stack smaller. This 
decreases the memory consumption of the Python function frame by one pointer 
and speeds up the Python function frame creation time (one pointer assignment 
less). It is tiny, but I think it is worth to keep it.

I don't know what is the right solution here.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue32490] subprocess: duplicate filename in exception message

[Zackery Spytz]

Zackery Spytz  added the comment:

There was also some relevant discussion in #22536.

--

___
Python tracker 

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

[issue32153] mock.create_autospec fails if an attribute is a partial function

[Anthony Flury]

Anthony Flury  added the comment:

Am not a big fan of special casing, 

I think the functools.update_wrapper is the way to go - will have a look later 
and produce a pull request with some test cases.

--

___
Python tracker 

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

[issue34660] Replace ableist terms and pejoratives in source code.

[Gabriel Marko]

Gabriel Marko  added the comment:

Come on guys. Stop this madness. :(

--
nosy: +suic

___
Python tracker 

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

[issue33367] Multiprocessing Pool workers initiated with maxtasksperchild do not execute when sharing logging

[Soumyadipta Das]

Change by Soumyadipta Das :


--
nosy: +vinay.sajip

___
Python tracker 

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

[issue33367] Multiprocessing Pool workers initiated with maxtasksperchild do not execute when sharing logging

[Soumyadipta Das]

Change by Soumyadipta Das :


--
nosy: +pitrou

___
Python tracker 

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

[issue34705] Python 3.8 changes how returns through finally clauses are traced

[Ned Batchelder]

Ned Batchelder  added the comment:

This affects coverage.py, as reported in this bug: 
https://github.com/nedbat/coveragepy/issues/707

--

___
Python tracker 

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

[issue34705] Python 3.8 changes how returns through finally clauses are traced

[Ned Batchelder]

New submission from Ned Batchelder :

When a return statement also executes a finally clause, the sequence of lines 
reported to the trace function is different in 3.8 than it has been before 3.8:

$ cat finally_trace.py
def return_from_finally():
try:
print("returning")
return 17
finally:
print("finally")

def trace(frame, event, arg):
print(frame.f_lineno, event)
return trace

import sys
sys.settrace(trace)
return_from_finally()

$ python3.7 finally_trace.py
1 call
2 line
3 line
returning
4 line
6 line
finally
6 return

$ python3.8 finally_trace.py
1 call
2 line
3 line
returning
4 line
6 line
finally
4 line
4 return


Is this intentional? Is it a bug? Will it change back before 3.8 is shipped?

--
components: Interpreter Core
messages: 325484
nosy: nedbat
priority: normal
severity: normal
status: open
title: Python 3.8 changes how returns through finally clauses are traced
type: behavior
versions: Python 3.8

___
Python tracker 

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

[issue32152] Add pid to .cover filename in lib/trace.py

[Ned Batchelder]

Ned Batchelder  added the comment:

The trace module doesn't get much use.  Have you tried using coverage.py?  
https://pypi.org/project/coverage/

--
nosy: +nedbat

___
Python tracker 

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

[issue34704] Do not access ob_type directly, introduce Py_TP

[Neil Schemenauer]

Change by Neil Schemenauer :


--
pull_requests: +8767

___
Python tracker 

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

[issue34704] Do not access ob_type directly, introduce Py_TP

[Neil Schemenauer]

New submission from Neil Schemenauer :

My long term goal is to make it possible to make PyObject an opaque structure.  
Obviously that would break nearly every 3rd party extension at this point.  
However, to allow freedom on certain interpreter implementation strategies, it 
is helpful if code does not access ob_type, ob_refcnt and ob_size directly.  
Cleaning up core Python is not too hard.

There is closed bug #26824 which proposed a similar change.  There was two main 
issues with that patch.  One, it causes a fair amount of code churn.  This 
patch does that too.  Second, replace ob->ob_type with Py_TYPE(ob) adds an 
extra type-cast to PyObject*.  That's not good.

In this patch, I introduce Py_TP() as a non-typecast version of Py_TYPE().  I 
think the name is nice as it is short and matches the struct field prefix.

This change overlaps with Victor's proposed %t or %T format code change.  The 
code churn is mostly caused by code that does ob->ob_type->tp_name.  I'm not 
against the format code idea but personally I think trying to remove borrowed 
references is a difficult problem and it should not hold up the relatively 
simple task of allowing PyObject to be opaque.

Also, I doesn't see any immediate need to make PyTypeObject opaque.  The tp_* 
are used everywhere and so making access macros or functions for those would be 
hugely disruptive.  PyTypeObject is already opaque for the limited API.  I 
think that's good enough for now.

If this change gets accepted, I have follow-up patches to fix access to 
ob_refcnt and ob_size.  Those are much smaller patches since those fields are 
not often accessed.

--
components: Interpreter Core
files: py_tp_macro.txt
keywords: needs review, patch
messages: 325482
nosy: nascheme, serhiy.storchaka, vstinner
priority: normal
severity: normal
stage: patch review
status: open
title: Do not access ob_type directly, introduce Py_TP
type: enhancement
Added file: https://bugs.python.org/file47806/py_tp_macro.txt

___
Python tracker 

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

[issue26979] The danger of PyType_FromSpec()

[Neil Schemenauer]

Change by Neil Schemenauer :


--
nosy: +nascheme

___
Python tracker 

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

[issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

[Neil Schemenauer]

Neil Schemenauer  added the comment:

I would suggest that sharing of objects between interpreters should be stamped 
out.  Could we have some #ifdef debug checking that would warn or assert so 
this doesn't happen?  I know currently we share a lot of objects.  However, in 
the long term, that does not seem like the correct design.  Instead, each 
interpreter should have its own objects and any passing or sharing should be 
tightly controlled.

--
nosy: +nascheme

___
Python tracker 

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

[issue34382] test_os.test_mode fails when directory base directory has g+s set

[Michael Felt]

Michael Felt  added the comment:

Closing this, and my PR, as issue34664 is a repeat and already merged.

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

[issue34703] Unexpected Arithmetic Result

[Mark Dickinson]

Mark Dickinson  added the comment:

This isn't a bug; it's a result of Python using the hardware-provided binary 
floating-point, which can't represent all decimal numbers exactly.

Please take a look at https://docs.python.org/3/tutorial/floatingpoint.html for 
more information.

--
nosy: +mark.dickinson
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue34703] Unexpected Arithmetic Result

[chengxuncc]

New submission from chengxuncc :

>>> 2359296/10/1000**2
0.235929602

>>> 2359296/1000
0.2359296

You can see it.

--
components: Interpreter Core
messages: 325478
nosy: chengxuncc
priority: normal
severity: normal
status: open
title: Unexpected Arithmetic Result
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

[issue32990] Supporting extensible format(PCM) for wave.open(read-mode)

[Zackery Spytz]

Zackery Spytz  added the comment:

Andrea, are you still working on this issue? If not, I will submit a PR.

--
nosy: +ZackerySpytz

___
Python tracker 

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

[issue34560] Backport of uuid1() failure fix

[Riccardo Mottola]

Riccardo Mottola  added the comment:

https://github.com/python/cpython/pull/9125

should close it

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

[issue34702] urlopen doesn't handle query strings with "file" scheme

[Guillaume Ayoub]

New submission from Guillaume Ayoub :

urlopen includes query strings in the filename with "file"-scheme URLs.

>>> from urllib.request import urlopen
>>> urlopen('file:///tmp/test')
>
>>> urlopen('file:///tmp/test?q')
Traceback (most recent call last):
  File "/usr/lib/python3.7/urllib/request.py", line 1473, in open_local_file
stats = os.stat(localfile)
FileNotFoundError: [Errno 2] No such file or directory: '/tmp/test?q'

This behavior seems to be OK with what RFC 8089 tells, but many other 
implementations (including browsers and curl) remove query strings from the 
filename.

--
messages: 325475
nosy: liZe
priority: normal
severity: normal
status: open
title: urlopen doesn't handle query strings with "file" scheme
type: behavior

___
Python tracker 

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

[issue34697] ctypes: Crash if manually-created CField instance is used

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +xtreak

___
Python tracker 

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

[issue19417] Bdb: add a unittest file (test.test_bdb)

[miss-islington]

miss-islington  added the comment:


New changeset 57e70d3802a2a78e638999c6923053c63fe373f8 by Miss Islington (bot) 
(xdegaye) in branch '2.7':
[2.7] bpo-19417: Add test_bdb.py (GH-5217) (GH-6156)
https://github.com/python/cpython/commit/57e70d3802a2a78e638999c6923053c63fe373f8


--

___
Python tracker 

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