[issue30749] Non-atomic and unusual (wrong) rename behavior under OS X

[Ronald Oussoren]

Ronald Oussoren added the comment:

What version of macOS did you test on?

--

___
Python tracker 

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

[issue6739] IDLE: refuse invalid key bindings

[Terry J. Reedy]

Terry J. Reedy added the comment:

Guilherme, thank you for the patch.  Sorry it took so long to be applied.  
Cheryl, thank you for making the PR.  Writing invalid, exception-raising 
sequences to user config files was a definite bug.

--
resolution:  -> fixed
stage: test needed -> 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

[issue6739] IDLE: refuse invalid key bindings

[Terry J. Reedy]

Terry J. Reedy added the comment:


New changeset 64a0c266e78c6b5363668012fa7fb614f6018930 by terryjreedy in branch 
'3.6':
[3.6] bpo-6739: IDLE: Check for valid keybinding in config_keys (GH-2377) 
(#2397)
https://github.com/python/cpython/commit/64a0c266e78c6b5363668012fa7fb614f6018930


--

___
Python tracker 

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

[issue29304] dict: simplify lookup functions

[Tim Peters]

Tim Peters added the comment:

Oops!  I undercounted the shifts in the current scheme:  there's an additional 
shift for "perturb".  That doesn't exist in the "double hashing" alternatives.

--

___
Python tracker 

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

[issue29304] dict: simplify lookup functions

[Tim Peters]

Tim Peters added the comment:

I suggest reading the thread I started here[1] before pursuing this:  it looks 
very likely that the entire collision resolution scheme should be replaced with 
one of the "double hashing" ones given there, a bona fide algorithmic 
improvement for small tables and pathological key sets.  Whether it actually 
runs faster remains a mystery ;-)  The loop guts change from a shift, three 
adds, and a mask (or a multiply, two adds, and a mask) to just one add and a 
mask.  But the post-first-probe pre-loop setup gets more expensive.

[1] https://mail.python.org/pipermail/python-ideas/2017-June/046143.html

--
nosy: +tim.peters

___
Python tracker 

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

[issue30441] os.environ raises RuntimeError: dictionary changed size during iteration

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Osvaldo, could you please create a pull request on GitHub based on your first 
patch? But use list() instead of dict().

--

___
Python tracker 

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

[issue30747] _Py_atomic_* not actually atomic on Windows with MSVC

[Jeffrey Yasskin]

Jeffrey Yasskin added the comment:

Has enough time passed that you can use the C11 atomic types and operations 
instead of special-casing these for each compiler? (e.g. 
http://en.cppreference.com/w/c/atomic/atomic_store)

--

___
Python tracker 

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

[issue6739] IDLE: refuse invalid key bindings

[Terry J. Reedy]

Changes by Terry J. Reedy :


--
pull_requests: +2444

___
Python tracker 

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

[issue6739] IDLE: refuse invalid key bindings

[Terry J. Reedy]

Terry J. Reedy added the comment:


New changeset 8c78aa70c888a370af18896a72cabd00e4120f09 by terryjreedy 
(csabella) in branch 'master':
bpo-6739: IDLE: Check for valid keybinding in config_keys (#2377)
https://github.com/python/cpython/commit/8c78aa70c888a370af18896a72cabd00e4120f09


--

___
Python tracker 

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

[issue29304] dict: simplify lookup functions

[Xavier G. Domingo]

Changes by Xavier G. Domingo :


--
nosy: +xgdomingo

___
Python tracker 

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

[issue30757] pyinstaller can be added to docs, py2exe ref can be updated

[Denis Akhiyarov]

Changes by Denis Akhiyarov :


--
pull_requests: +2443

___
Python tracker 

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

[issue30757] pyinstaller can be added to docs, py2exe ref can be updated

[Denis Akhiyarov]

New submission from Denis Akhiyarov:

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

It is not clear why this FAQ item is written in addition to this document:

https://github.com/python/cpython/blob/master/Doc/faq/windows.rst#how-do-i-make-python-scripts-executable

https://github.com/python/cpython/blob/master/Doc/faq/programming.rst#how-can-i-create-a-stand-alone-binary-from-a-python-script

--
assignee: docs@python
components: Documentation
messages: 296844
nosy: denfromufa, docs@python
priority: normal
severity: normal
status: open
title: pyinstaller can be added to docs, py2exe ref can be updated
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7

___
Python tracker 

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

[issue30756] ttk: GUI tests fail on Ubuntu

[Terry J. Reedy]

Changes by Terry J. Reedy :


--
stage:  -> needs patch
type:  -> behavior

___
Python tracker 

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

[issue30756] ttk: GUI tests fail on Ubuntu

[Terry J. Reedy]

Terry J. Reedy added the comment:

My Win 10 machine consistently runs 272 tests OK in 3 seconds.

--

___
Python tracker 

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

[issue30734] 200000 indexes crashes eval and python (without eval)

[Nick Coghlan]

Nick Coghlan added the comment:

We have quite a few of them: 
https://github.com/python/cpython/tree/master/Lib/test/crashers

Python 2.7 is ancient, so our tolerance for intrusive interpreter level fixes 
to address rare problems that are easy to avoid at the development level is 
pretty low.

Fixing those kinds of problems in Python 3.x is encouraged, but still not 
necessarily easy.

--

___
Python tracker 

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

[issue30744] Local variable assignment is broken when combined with threads + tracing + closures

[Nick Coghlan]

Nick Coghlan added the comment:

Sorry, I wasn't clear: I don't see any problem for the cases that don't 
optimize local variable access, and don't think any of those should change.

Instead, I think we should tighten up the formal specification of locals() to 
better match how it is actually used in practice: 
https://mail.python.org/pipermail/python-dev/2013-May/125917.html

(https://bugs.python.org/issue17960 is the corresponding issue, although I 
clearly got distracted by other things and never followed up with a patch for 
the language reference. https://bugs.python.org/issue17546 is another issue 
lamenting the current underspecification in this area)

However, function bodiess are already inherently different from other execution 
namespaces, and that stems from a particular special case assumption that we 
don't make anywhere else: we assume that at compile time, the compiler can see 
all of the names added to the local namespace of a function.

That assumption wasn't quite valid in Python 2 (since unqualified exec 
statements and function level wildcard imports could mess with it), but it's 
much closer to being true in Python 3.

Checking the 3.7 code, the only remaining ways to trigger it are:

- via a tracing function (since LocalsToFast gets called after the tracing 
function runs)
- by injecting an IMPORT_STAR opcode into a function code object (the compiler 
disallows that in Python 3 and emits a SyntaxWarning for it in Python 2, but 
the LocalsToFast call is still there in the eval loop)

So I think an entirely valid way forward here would be to delete LocalsToFast 
in 3.7+, and say that if you want to write access to a function namespace from 
outside the function, you need to either implement an eval hook (not just a 
tracing hook), or else use a closure that closes over all the variables that 
you want write access to.

However, the less drastic way forward would be to make it so that writing a 
tracing function is the only way to get access to the FastToLocals result, and 
have locals() on a frame running a code object compiled for fast locals return 
f->f_locals.copy() rather than a direct reference to the original.

--

___
Python tracker 

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

[issue17960] Clarify the required behaviour of locals()

[Nick Coghlan]

Changes by Nick Coghlan :


--
versions: +Python 3.7 -Python 3.4

___
Python tracker 

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

[issue30756] ttk: GUI tests fail on Ubuntu

[Louie Lu]

Changes by Louie Lu :


--
components: +Tkinter
title: GUI tests fail on Ubuntu -> ttk: GUI tests fail on Ubuntu

___
Python tracker 

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

[issue30576] http.server should support HTTP compression (gzip)

[Glenn Linderman]

Glenn Linderman added the comment:

"veery" should be "veering" in above comment, sorry.

--

___
Python tracker 

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

[issue30576] http.server should support HTTP compression (gzip)

[Glenn Linderman]

Glenn Linderman added the comment:

Martin, I understood what you meant, but sadly, doing that least to confusion. 
Follow your link, it displays fine, and then save the file. At least in 
Firefox, the default name to save as is "nGzip — A File Compressor.html". This 
looks appropriate, but the saved file is actually the compressed .gz form, so 
attempting to display it later, from the default name, displays the compressed 
gibberish, because the name does not reflect the encoding. Perhaps this should 
be considered a Firefox bug? Chrome saves the uncompressed version with the 
same default name. I can't actually figure out how to save the file from Edge, 
so don't know what it might do.

I'm surprised that Firefox, since it saves the compressed version, didn't offer 
the name "index.en.html.gz", and that Chrome, for the uncompressed version, 
didn't offer "index.en.html". Deriving the name from the title feels weird, but 
maybe only because I create web pages, and know what the real file names are. 
But this paragraph, other than the lack of ".gz" for Firefox naming, is veery 
off-topic.

The point I'm trying to make, though, is that the URIs shouldn't contain file 
extensions that include the compression, because that is confusing. The 
compression should be an internally negotiated detail between the browser and 
the web server, and the URI should reflect the content to be displayed, not the 
form in which it was encoded for transfer (or storage).  When .gz or .br is 
included in the URI, I would expect the browser to offer to save it to disk as 
a binary, compressed file, just like .zip. The variant behavior of Firefox and 
Chrome makes me wonder if there is even a standard that applies in this area... 
if there is, and if either one of them is following it, it is certainly not 
what I would expect.

--

___
Python tracker 

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

[issue30749] Non-atomic and unusual (wrong) rename behavior under OS X

[Alex Groce]

Alex Groce added the comment:

Checked, and this is a problem on Python 3 as well as 2.7.

--
title: Non-atomic and unusual (wrong) rename behavior under OS X, Python 2.7.13 
-> Non-atomic and unusual (wrong) rename behavior under OS X
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

[issue30687] build.bat should locate msbuild.exe rather than vcvarsall.bat

[Steve Dower]

Steve Dower added the comment:

The bug is  MSBuild 15.0 should be able to locate earlier versions of VC, even 
if you haven't installed it for VS 2017.

--

___
Python tracker 

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

[issue24813] Redesign Help => About IDLE, make it non-modal

[Cheryl Sabella]

Cheryl Sabella added the comment:

Created issue 30756.

On Sun, Jun 25, 2017 at 2:10 PM, Terry J. Reedy 
wrote:

>
> Terry J. Reedy added the comment:
>
> You should have enough data to open an issue; make Serhiy Storchaka (and
> me) nosy. Does the same test fail consistently or not?  % of failures. When
> it takes longer, is there a particular place in the stream of results where
> it pauses?  When I run it on master, it consistently takes 3 seconds, and
> there is a deprecation warning that I think should be caught in the test.
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue30756] GUI tests fail on Ubuntu

[Cheryl Sabella]

New submission from Cheryl Sabella:

Running the tests over up to date build on Ubuntu 16.04 64-bit.

./python -m test.test_ttk_guionly -v


Sometimes this runs without failure and sometimes it 'hangs' and then produces 
failures.  When it hangs, my computer freezes completely.  As you can see, it 
can run for 8 minutes.

It seems to hang most often on test_idenify in EntryTest.

Here's one set of failures:

==
FAIL: test_identify (tkinter.test.test_ttk.test_widgets.EntryTest)
--
Traceback (most recent call last):
  File "/home/cheryl/cpython/Lib/tkinter/test/test_ttk/test_widgets.py", line 
332, in test_identify
self.assertEqual(self.entry.identify(5, 5), "textarea")
AssertionError: '' != 'textarea'
+ textarea

==
FAIL: test_get (tkinter.test.test_ttk.test_widgets.ScaleTest)
--
Traceback (most recent call last):
  File "/home/cheryl/cpython/Lib/tkinter/test/test_ttk/test_widgets.py", line 
807, in test_get
self.assertEqual(self.scale.get(scale_width, 0), self.scale['to'])
AssertionError: 0.0 != 1.0

==
FAIL: test_set (tkinter.test.test_ttk.test_widgets.ScaleTest)
--
Traceback (most recent call last):
  File "/home/cheryl/cpython/Lib/tkinter/test/test_ttk/test_widgets.py", line 
849, in test_set
self.assertEqual(conv(self.scale.get(self.scale.winfo_width(), 0)), max)
AssertionError: 0.0 != 1.0

==
FAIL: test_identify (tkinter.test.test_ttk.test_widgets.WidgetTest)
--
Traceback (most recent call last):
  File "/home/cheryl/cpython/Lib/tkinter/test/test_ttk/test_widgets.py", line 
71, in test_identify
), "label")
AssertionError: '' != 'label'
+ label

--
Ran 272 tests in 491.572s

FAILED (failures=4)



Here's another set from a different run:

==
FAIL: test_get (tkinter.test.test_ttk.test_widgets.ScaleTest)
--
Traceback (most recent call last):
  File "/home/cheryl/cpython/Lib/tkinter/test/test_ttk/test_widgets.py", line 
807, in test_get
self.assertEqual(self.scale.get(scale_width, 0), self.scale['to'])
AssertionError: 0.0 != 1.0

==
FAIL: test_set (tkinter.test.test_ttk.test_widgets.ScaleTest)
--
Traceback (most recent call last):
  File "/home/cheryl/cpython/Lib/tkinter/test/test_ttk/test_widgets.py", line 
849, in test_set
self.assertEqual(conv(self.scale.get(self.scale.winfo_width(), 0)), max)
AssertionError: 0.0 != 1.0

==
FAIL: test_identify (tkinter.test.test_ttk.test_widgets.WidgetTest)
--
Traceback (most recent call last):
  File "/home/cheryl/cpython/Lib/tkinter/test/test_ttk/test_widgets.py", line 
71, in test_identify
), "label")
AssertionError: '' != 'label'
+ label

==
FAIL: test_horizontal_range 
(tkinter.test.test_ttk.test_extensions.LabeledScaleTest)
--
Traceback (most recent call last):
  File "/home/cheryl/cpython/Lib/tkinter/test/test_ttk/test_extensions.py", 
line 122, in test_horizontal_range
self.assertEqual(prev_xcoord, int(linfo_1['x']))
AssertionError: 16 != 1

--
Ran 272 tests in 353.180s

FAILED (failures=4)

--
components: Tests
messages: 296835
nosy: csabella, serhiy.storchaka, terry.reedy
priority: normal
severity: normal
status: open
title: GUI tests fail on Ubuntu
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

[issue24813] Redesign Help => About IDLE, make it non-modal

[Terry J. Reedy]

Terry J. Reedy added the comment:

You should have enough data to open an issue; make Serhiy Storchaka (and me) 
nosy. Does the same test fail consistently or not?  % of failures. When it 
takes longer, is there a particular place in the stream of results where it 
pauses?  When I run it on master, it consistently takes 3 seconds, and there is 
a deprecation warning that I think should be caught in the test.

--

___
Python tracker 

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

[issue30734] 200000 indexes crashes eval and python (without eval)

[George Shuklin]

George Shuklin added the comment:

Unfixed crash of code interpreter? This is sad.

--

___
Python tracker 

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

[issue7985] access to infinitely recursive list

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Correction to the last message. Issue5765 was a 3.x issue. It was fixed for 
3.3+, and it was decided to not fix it for 2.7 and 3.2. This issue is not 
reproduced in 3.3+.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue30734] 200000 indexes crashes eval and python (without eval)

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Which is a duplicate of issue5765 fixed for Python 3.3+. It was decided to not 
fix issue5765 for 2.7.

--
nosy: +serhiy.storchaka
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> stack overflow evaluating eval("()" * 3)

___
Python tracker 

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

[issue27945] Various segfaults with dict

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
pull_requests: +2442

___
Python tracker 

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

[issue30734] 200000 indexes crashes eval and python (without eval)

[Mark Dickinson]

Mark Dickinson added the comment:

Looks like a duplicate of http://bugs.python.org/issue7985

--
nosy: +mark.dickinson

___
Python tracker 

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

[issue18378] locale.getdefaultlocale() fails on Mac OS X with default language set to English

[Matthew Woodcraft]

Matthew Woodcraft added the comment:

That alias (C.UTF-8 to en_US.UTF-8) is surely a bug in itself nowadays. I've 
filed #30755 .

--
nosy: +mattheww

___
Python tracker 

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

[issue30755] locale.normalize() and getdefaultlocale() convert C.UTF-8 to en_US.UTF-8

[Matthew Woodcraft]

New submission from Matthew Woodcraft:

I have a system where the default locale is C.UTF-8, and en_US.UTF-8 is
not installed.

But locale.normalize() unhelpfully converts "C.UTF-8" to "en_US.UTF-8".

So the following crashes for me:

  python3.6 -c "import locale;locale.setlocale(locale.LC_ALL, ('C', 'UTF-8'))"


Similarly getdefaultlocale() returns ('en_US', 'UTF-8'), so this crashes too:

  export LANG=C.UTF-8
  unset LC_CTYPE
  unset LC_ALL
  unset LANGUAGE
  python3.6 -c "import locale;locale.setlocale(locale.LC_ALL, 
locale.getdefaultlocale())"


This behaviour is caused by a locale_alias entry in Lib/locale.py .

https://bugs.python.org/issue20076 documents its addition but doesn't
provide a rationale.

I can see that it might be helpful to provide such a conversion if
C.UTF-8 doesn't exist and en_US.UTF-8 does, but the current code is
breaking modern correctly-configured systems for the benefit of old
misconfigured ones (C.UTF-8 shouldn't really be in the environment if it
isn't available on the system, after all).

--
messages: 296828
nosy: mattheww
priority: normal
severity: normal
status: open
title: locale.normalize() and getdefaultlocale() convert C.UTF-8 to en_US.UTF-8
versions: Python 3.4, Python 3.5, Python 3.6

___
Python tracker 

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

[issue24813] Redesign Help => About IDLE, make it non-modal

[Cheryl Sabella]

Cheryl Sabella added the comment:

Sometimes that test fails and sometimes it doesn't, even if I run it several 
times in a row.  When it does fail, it runs a lot longer than when it doesn't.  
So, I'm trying to figure out the difference before reporting it.  Since the 
failure takes time, I'm thinking it might be resource contention of some sort.

--

___
Python tracker 

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

[issue30687] build.bat should locate msbuild.exe rather than vcvarsall.bat

[Pär Björklund]

Pär Björklund added the comment:

I don't believe that this is a bug in Visual Studio as MSBuild is used for .NET 
projects as well it should be available even without the C++ tooling installed.

Checking for the targets file seems like a workable solution.

--

___
Python tracker 

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

[issue30754] textwrap.dedent mishandles empty lines

[Julian Berman]

New submission from Julian Berman:

⊙  python2 -c 'from textwrap import dedent; print repr(dedent(" " * 2 + "\n" + 
" " * 4 + "\n"))'
'\n\n'

instead of the presumed '\n  \n'

The same appears to be the case for py3.6.


(At first glance, this seems unrelated to http://bugs.python.org/issue19479 
although that issue seems to have an unreviewed patch that changes the 
implementation, so it might also "accidentally" fix the issue).

--
components: Library (Lib)
messages: 296825
nosy: Julian, georg.brandl, terry.reedy
priority: normal
severity: normal
status: open
title: textwrap.dedent mishandles empty lines
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7

___
Python tracker 

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

[issue30703] test_multiprocessing_forkserver hangs on the master branch

[Matt Billenstein]

Matt Billenstein added the comment:

Yes, I'll email you the details.

--

___
Python tracker 

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

[issue30747] _Py_atomic_* not actually atomic on Windows with MSVC

[Steve Dower]

Steve Dower added the comment:

> Would there be any interest of implementing them for MSVC/ARM as well

Sure, since you're there. It's not easy to test, but I know people who are 
doing it, so it'll get noticed eventually.

Maybe there's some sort of stress test we can write that is likely to encounter 
issues? I've done that before to detect concurrency issues in particularly 
complex code.

--

___
Python tracker 

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

[issue30753] not able to execute print command on page 16 of documentation

[Steven D'Aprano]

Steven D'Aprano added the comment:

This is a bug in your code, not Python, and the error tells you how to fix it. 
You have to indent the block.

>>> while b < 1000:
... print(b, end=',')
... a, b = b, a+b

Remember to press TAB or spacebar inside indented blocks.

You should work through the tutorial.

https://docs.python.org/3/tutorial/index.html

By the way, you say page 16 of which documentation? Are you reading from a 
book? Which book?

--
nosy: +steven.daprano
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

[issue30753] not able to execute print command on page 16 of documentation

[Vishal Devgn]

New submission from Vishal Devgn:

>>> a, b = 0, 1
>>> while b < 1000:
... print(b, end=',')
... a, b = b, a+b

in 3.6 as soon as i write print command, it displays an indentation error.

--
files: 1.png
messages: 296821
nosy: Vishal Devgn
priority: normal
severity: normal
status: open
title: not able to execute print command on page 16 of documentation
type: compile error
versions: Python 3.6
Added file: http://bugs.python.org/file46974/1.png

___
Python tracker 

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

[issue30747] _Py_atomic_* not actually atomic on Windows with MSVC

[Pär Björklund]

Pär Björklund added the comment:

Antoine said it best.

It's very hard to prove that this code is correct or incorrect as it requires 
multiple threads accessing the same variable and very specific timings to 
produce an actual issue.

My PR only solved half of the issue because I didn't really have a good idea 
for how to handle the load macro but I think it out today so I'll be updating 
the PR.

Would there be any interest of implementing them for MSVC/ARM as well? It's 
basically the same code so not much work, however I don't have a platform to 
actually test it.

--

___
Python tracker 

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

[issue29464] Specialize FASTCALL for functions with positional-only parameters

[Stefan Behnel]

Stefan Behnel added the comment:

Can the PR be applied then? It looks good to me.

--

___
Python tracker 

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

[issue30752] Basic subtraction is wrong ( 1.83 - 1.52 == 0.31000000000000005)

[Mark Dickinson]

Mark Dickinson added the comment:

This is working as expected. Python's floats use the hardware-provided _binary_ 
floating-point format, which can't represent every finite decimal value 
exactly. I recommend reading 
https://docs.python.org/3.6/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

[issue30752] Basic subtraction is wrong ( 1.83 - 1.52 == 0.31000000000000005)

[René Podlogar]

New submission from René Podlogar:

My Python-Installations Python 2.7.12, Python 3.4.5 @linux64
and the CLI on the python.org-Website (interactive shell) affected:

Python 3.6.0 (default, Jan 13 2017, 00:00:00) 
[GCC 4.8.4] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 1.83 - 1.52
0.31005
>>> 

Expected= 0.31

Verified in irc-channel #python.de

--
messages: 296817
nosy: René Podlogar
priority: normal
severity: normal
status: open
title: Basic subtraction is wrong ( 1.83 - 1.52 == 0.31005)
versions: Python 2.7, Python 3.7

___
Python tracker 

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

[issue30696] infinite loop in PyRun_InteractiveLoopFlags()

[Xavier de Gaye]

Changes by Xavier de Gaye :


--
pull_requests:  -2416

___
Python tracker 

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

[issue30695] add a nomemory_allocator to the _testcapi module

[Xavier de Gaye]

Changes by Xavier de Gaye :


--
pull_requests:  -2415

___
Python tracker 

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

[issue30747] _Py_atomic_* not actually atomic on Windows with MSVC

[Antoine Pitrou]

Antoine Pitrou added the comment:

The general issue those macros want to prevent is that modern CPUs have a 
tendency to execute a lot of stuff out-of-order, *including* memory operations. 
 From the perspective of a single hardware core (or thread, really), that's 
fine since it  has a logically consistent view of the machine's state (it knows 
which operations have been reordered, which values have been committed to cache 
or not, etc.).  But what happens when another hardware core examines in-memory 
state at the same time? It might find values changing in a different order than 
the programmer had intended. If it's important that the visible order hasn't 
been changed, you have a bug.

Note that C "volatile" is not enough: it only prevents the *compiler* from 
re-ordering or eliding memory accesses, but not the CPU.  As such, "volatile" 
is only useful if you have a single word-sized piece of state that you need to 
inspect from several threads at once.  But the eval loop uses several of them, 
and therefore needs to prevent the CPU from writing or reading them in the 
wrong order (which may produce synchronization bugs such as deadlocks).

Also note that traditionally, x86 has a "strong" memory ordering model which 
prevents nasty kinds of reorderings to happen.  But other architectures such as 
ARM or SPARC can have much weaker memory models (IIRC, we had sporadic hangs on 
an ARM buildbot a long time ago, because of that, but I can't find a reference).

I admit I'm unable to vouch that the current code is correct.  Jeffrey Yasskin 
did the original change adding the Py_atomic types and using them in the GIL 
implementation.

--
nosy: +jyasskin, pitrou

___
Python tracker 

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

[issue4926] putenv() accepts names containing '=', return value of unsetenv() not checked

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

The part of this issue ('=' in putenv()) is fixed in issue30746.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue30746] Reject environment variable names containing '='

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


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

[issue30746] Reject environment variable names containing '='

[Serhiy Storchaka]

Serhiy Storchaka added the comment:


New changeset 787826c9316b03ac8a197078ec1cdf98fa840c5c by Serhiy Storchaka in 
branch '2.7':
[2.7] bpo-30746: Prohibited the '=' character in environment variable names 
(GH-2382) (#2393)
https://github.com/python/cpython/commit/787826c9316b03ac8a197078ec1cdf98fa840c5c


--

___
Python tracker 

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

[issue30746] Reject environment variable names containing '='

[Serhiy Storchaka]

Serhiy Storchaka added the comment:


New changeset 99e9eb6111ef6a11bfff358866c9f2b0c201ac08 by Serhiy Storchaka in 
branch '3.5':
[3.5] bpo-30746: Prohibited the '=' character in environment variable names 
(GH-2382) (#2392)
https://github.com/python/cpython/commit/99e9eb6111ef6a11bfff358866c9f2b0c201ac08


--

___
Python tracker 

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

[issue30746] Reject environment variable names containing '='

[Serhiy Storchaka]

Serhiy Storchaka added the comment:


New changeset 9c2dc0c58a878ac3d1c44dd0048f8e1cfab2790e by Serhiy Storchaka in 
branch '3.6':
[3.6] bpo-30746: Prohibited the '=' character in environment variable names 
(GH-2382) (#2391)
https://github.com/python/cpython/commit/9c2dc0c58a878ac3d1c44dd0048f8e1cfab2790e


--

___
Python tracker 

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

[issue30746] Reject environment variable names containing '='

[Serhiy Storchaka]

Serhiy Storchaka added the comment:


New changeset af5392f5c6f8014659e995840df6ee7b5017f743 by Serhiy Storchaka in 
branch 'master':
bpo-30746: Port more tests for os.spawnvpe() and os.execve() from 2.7. (#2394)
https://github.com/python/cpython/commit/af5392f5c6f8014659e995840df6ee7b5017f743


--

___
Python tracker 

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

[issue30744] Local variable assignment is broken when combined with threads + tracing + closures

[Nathaniel Smith]

Nathaniel Smith added the comment:

Interesting idea! I'm not sure I fully understand how it would work though.

What would you do for the frames that don't use the fast array, and where 
locals() currently returns the "real" namespace?

How are you imagining that the trace function writeback would be implemented? 
Some sort of thread-local flag saying "we're inside a trace function for frame 
XX" that causes locals() and f_locals to switch to returning a "real" namespace 
object?

--

___
Python tracker 

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

[issue30422] Add roadmap.txt section to idlelib

[18z]

18z added the comment:

I strongly agree with the idea of writing documents that describe a bit of 
history to help orient new contributors to IDLE as to where the involved 
contributors see it going.

As a new comer, before I started to trace the codes of idlelib. A question 
bothers me all the time. "Why do we need idlelib since there are so many 
brilliant IDEs out there?" And I'm not sure whether should I keep reading the 
codes or not.

So, I want to say Thank you to Terry. Your draft helped me. 

I'm really happy to see this question had been discussed in summer 2010. And 
the result is to modernize idlelib. 

However, I have a suggestion :)

Although the result of the discussion is to modernize. I suggest to add few 
lines to describe the reasons why this decision had been made. And references 
(if possible) are needed to provide since some readers might want to see the 
original discussion.

How do you think? :)

--
nosy: +KunYu Chen

___
Python tracker 

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

[issue30744] Local variable assignment is broken when combined with threads + tracing + closures

[Nick Coghlan]

Nick Coghlan added the comment:

To make the behaviour more consistent in 3.7, I'd be more inclined to go in the 
other direction: make locals() return a truly independent snapshot when used in 
a function, rather than sharing a single snapshot between all locals() calls.

Shared snapshots that may potentially be written back to the frame locals would 
then be unique to trace functions, rather than being a feature of function 
level locals() calls in general.

--

___
Python tracker 

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

[issue30647] CODESET error on AMD64 FreeBSD 10.x Shared 3.x caused by the PEP 538

[Nick Coghlan]

Nick Coghlan added the comment:

Current status of the PR:

- testing suggests that "nl_langinfo(CODESET)" fails with LC_CTYPE=UTF-8 on Mac 
OS X as well, but that doesn't matter for Python start-up, since we hardcode 
UTF-8 as the locale encoding and never call nl_langinfo
- on Linux however, "nl_langingo(CODESET)" succeeds as expected

Accordingly, I've revised the tests as follows:

- on Linux and Mac OS X, having setlocale() succeed gets a locale added to the 
"available target locales" set for the tests. This reflects the fact that we 
skip the nl_langinfo(CODESET) check on Mac OS X, and expect it to always 
succeed on Linux if setlocale() succeeds
- on other platforms where "locale.nl_langinfo(locale.CODESET)" is supported, 
we only consider a locale an available target locale if that call returns a 
non-empty answer

At the locale coercion level, I've added an extra check where we save the 
initial locale (i.e. before we change anything), and if setlocale() succeeds, 
but nl_langinfo(CODESET) fails, we do setlocale(LC_CTYPE, initial_locale) to 
try to get things back to their original state.

This seems to *mostly* work on FreeBSD, but doesn't quite get readline back to 
where it is by default, so test_non_ascii in test_readline fails with the error:

```
==
FAIL: test_nonascii (test.test_readline.TestReadline)
--
Traceback (most recent call last):
  File 
"/usr/home/buildbot/python/custom.koobs-freebsd10/build/Lib/test/test_readline.py",
 line 203, in test_nonascii
self.assertIn(b"text 't\\xeb'\r\n", output)
AssertionError: b"text 't\\xeb'\r\n" not found in 
bytearray(b"^A^B^B^B^B^B^B^B\t\tx\t\r\n[\\357nserted]|t\x07\x08\x08\x08\x08\x08\x08\x08\x07\x07xrted]|t\x08\x08\x08\x08\x08\x08\x08\x07\r\nresult
 \'[\\udcefnsexrted]|t\'\r\nhistory \'[\\xefnsexrted]|t\'\r\n")

```

My two current guesses as to what may be going wrong there are:

* doing the equivalent of "setlocale(LC_CTYPE, setlocale(LC_CTYPE, NULL))" may 
be taking libc out of the weird initial state where it claims to be using 
ASCII, but is really using latin-1; or
* setting "surrogateescape" on "stdin" is causing some unexpected behaviour in 
the affected test case

I'm leaning towards the former, as if it was the latter, I'd expect to have 
already seen the same error *without* locale coercion.

--

___
Python tracker 

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

[issue30744] Local variable assignment is broken when combined with threads + tracing + closures

[Nathaniel Smith]

Nathaniel Smith added the comment:

It isn't obvious to me whether the write-through proxy idea is a good one on 
net, but here's the rationale for why it might be.

Currently, the user-visible semantics of locals() and f_locals are a bit 
complicated. AFAIK they aren't documented anywhere outside the CPython and PyPy 
source (PyPy is careful to match all these details), but let me take a stab at 
it:

The mapping object you get from locals()/f_locals represents the relevant 
frame's local namespace. For many frames (e.g. module level, class level, 
anything at the REPL), it literally *is* the local namespace: changes made by 
executing bytecode are immediately represented in it, and changes made to it 
are immediately visible to executing bytecode. Except, for function frames, it 
acts more like a snapshot copy of the local namespace: it shows you the 
namespace at the moment you call locals(), but then future changes to either 
the code's namespace or the object don't affect each other. Except except, the 
snapshot might be automatically updated later to incorporate namespace changes, 
e.g. if I do 'ns = locals()' and then later on someone accesses the frame's 
f_locals attribute, then reading that attribute will cause my 'ns' object to be 
silently updated. But it's still a snapshot; modifications to the mapping 
aren't visible to the executing frame. Except**3, if you happen to modify the 
mapping object while you're inside a trace function callback, then *those* 
modifications are visible to the executing frame. (And also if a function is 
being traced then as a side-effect this means that now our 'ns' object above 
does stay constantly up to date.) Except**4, you don't actually have to be 
inside a trace function callback for your modifications to be visible to the 
executing frame – all that's necessary is that *some* thread somewhere is 
currently inside a trace callback (even if it doesn't modify or even look at 
the locals itself, as e.g. coverage.py doesn't).

This causes a lot of confusion [1].

On top of that, we have this bug here. The writeback-only-if-changed idea would 
make it so that we at least correctly implement the semantics I described in 
the long paragraph above. But I wonder if maybe we should consider this an 
opportunity to fix the underlying problem, which is that allowing skew between 
locals() and the actual execution namespace is this ongoing factory for bugs 
and despair. Specifically, I'm wondering if we could make the semantics be:

"locals() and f_locals return a dict-like object representing the local 
namespace of the given frame. Modifying this object and modifying the 
corresponding local variables are equivalent operations in all cases."

(So I guess this would mean a proxy object that on reads checks the fast array 
first and then falls back to the dict, and on writes updates the fast array as 
well as the dict.)

> you can still have race conditions between "read-update-writeback" operations 
> that affect the cells directly, as well as with those that use the new 
> write-through proxy.

Sure, but that's just a standard concurrent access problem, no different from 
any other case where you have two different threads trying to mutate the same 
local variable or dictionary key at the same time. Everyone who uses threads 
knows that if you want to do that then you need a mutex, and if you don't use 
proper locking then it's widely understood how to recognize and debug the 
resulting failure modes. OTOH, the current situation where modifications to the 
locals object sometimes affect the namespace, and sometimes not, and sometimes 
they get overwritten, and sometimes they don't, and it sometimes depends on 
spooky unrelated things like "is some other thread currently being traced"? 
That's *way* more confusing that figuring out that there might be a race 
condition between 'x = 1' and 'locals()["x"] = 2'.

Plus, pdb depends on write-through working, and there are lots of frames that 
don't even use the fast array and already have my proposed semantics. So 
realistically our choices are either "consistently write-through" or 
"inconsistently write-through".

[1] https://www.google.com/search?q=python+modify+locals=utf-8=utf-8

--

___
Python tracker 

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

[issue30450] Pull Windows dependencies from GitHub rather than svn.python.org

[Ammar Askar]

Ammar Askar added the comment:

Looks like that error is coming from the fact that the Powershell on that 
buildbot is outdated. As the documentation notes:

https://msdn.microsoft.com/en-us/powershell/reference/5.1/microsoft.powershell.utility/invoke-webrequest

> This cmdlet was introduced in Windows PowerShell 3.0.


Before running the web request command maybe do a `powershell.exe -Command 
$PSVersionTable.PSVersion` in order to debug this issue on any other machines?

--
nosy: +ammar2

___
Python tracker 

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