[issue6598] calling email.utils.make_msgid frequently has a non-trivial probability of generating colliding ids

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
assignee:  -> serhiy.storchaka

___
Python tracker 

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

[issue6598] calling email.utils.make_msgid frequently has a non-trivial probability of generating colliding ids

[Roundup Robot]

Roundup Robot added the comment:

New changeset 6969bac411fa by Serhiy Storchaka in branch '2.7':
Issue #6598: Increased time precision and random number range in
https://hg.python.org/cpython/rev/6969bac411fa

New changeset ea878f847eee by Serhiy Storchaka in branch '3.4':
Issue #6598: Increased time precision and random number range in
https://hg.python.org/cpython/rev/ea878f847eee

New changeset 933addbc7041 by Serhiy Storchaka in branch 'default':
Issue #6598: Increased time precision and random number range in
https://hg.python.org/cpython/rev/933addbc7041

--
nosy: +python-dev

___
Python tracker 

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

[issue6598] calling email.utils.make_msgid frequently has a non-trivial probability of generating colliding ids

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Now there is a question. Is it worth to use base16 (hexadecimal) to compact 
message id to 34 characters or base32 to compact it to 27 characters? Using 
base16 is pretty easy: just replace %d with %x. Using base32 is more 
complicated.

With base64 and base85 the length can be decreased to 23 and 21, but I doubt 
that this is safe.

--

___
Python tracker 

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

[issue4709] Mingw-w64 and python on windows x64

[Ruben Van Boxem]

Ruben Van Boxem added the comment:

Paul,

Thank you for your serious take on the issue.

I'm Ruben, a long-time contributor and 3-ish year toolchain builder for 
MinGW-w64. I originally helped patching Qt 4.5/4.6 so that it worked with 
MinGW-w64 on 64-bit Windows.

I can help liaison between you and the MinGW-w64 project, and point you towards 
stable, well-maintained MinGW-w64 builds. Perhaps we can discuss all the nitty 
gritty details elsewhere (or I can continue here of course), so we can get this 
straightened out.

In short, this is the story:
 - MinGW.org is the "old" MinGW project, which has become pretty stale and is 
behind in s many aspects that it isn't even funny anymore (mostly new 
Windows APIs, DirectX support, and C++11 threading support is lacking). 
MinGW-w64 is a clean-room implementation that was released into the public 
domain, and by now included in all (I repeat, all) major Linux distro's as a 
cross compiler. Arch, Debian/Ubuntu, Fedora/Redhat etc. all provide a MinGW-w64 
based cross-compiler. A complete list of MinGW-w64 features can be found on the 
web page: http://mingw-w64.yaxm.org/doku.php
 - TDM is a famous name in the MinGW world because he provided a high quality 
toolchain with installer when MinGW.org lacked in providing the new GCC 4. 
Unfortunately, he applies (perhaps useful) patches which break binary 
compatibility with upstream GCC. Since my toolchains (first uploads in 
September of 2010, last one in June 2013), and later with the MinGW-builds 
toolchains which are now installable through the MinGW-w64 website directly 
(and shipped with Qt), there is really no reason to go look elsewhere for 
toolchains. The MSYS2 project also provides numerous binary packages and I 
think almost exactly the same toolchains within their environment. The official 
MinGW-w64 installer can be found here:
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/installer/mingw-w64-install.exe
(it might occasionally complain it cannot download repo.txt, that's a 
Sourceforge redirect error thing that's proving might hard to fix, in any case 
you can also find the toolchains directly below)
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/

 - There are several ABI incompatible variants, explained nicely on the Qt wiki:
http://wiki.qt.io/MinGW-64-bit#Exception_handling:_SJLJ.2C_DWARF.2C_and_SEH
http://wiki.qt.io/MinGW-64-bit#GCC_Threading_model_.28posix_vs_win32.29
This is a choice you'll have to make. The greatest compatibility is offered by 
the "posix threading" (which gives C++11  support) and 32-bit sjlj and 
64-bit seh variants. The 32-bit-dw2 provides a bit more juice in exception 
heavy code, but has the caveat that exceptions cannot be thrown across 
non-GCC-built code. The 32-bit dw2 variant is also what works with Clang, and 
is what is delivered in MSYS2 when installing the 32-bit toolchain. Since the 
32-bit sturctured exception handling Borland Patents have expired, maybe a new, 
32-bit seh version will emerge, but I have heard nothing concrete towards this 
direction.

 - The MSYS2 project also provides GCC-built Python binaries, which of course 
needs quite heavy patching. These patches and build scripts can be found here:
https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-python3
https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-python2

 - the -mno-cygwin option is really a dinosaur, and should be thrown into a 
deep pit, buried, and forgotten. Cygwin provides MinGW-w64 cross-compilers 
({x86_64,i686}-w64-mingw32-gcc) which work in exactly the same way as a 
Linux->Windows cross-compiler. The official Windows binaries are just "gcc" and 
work as any native compiler on Linux.

I hope this provides you with much of the information you need. If anything is 
unclear (I wrote this up in like ten minutes) or you need some concrete help 
figuring some things out, feel free to contact me directly or through the 
bugtracker.
I sent an email to the MinGW-w64 public mailing list (subscription needed to 
post though, otherwise your message will be lost in the review queue) stating 
your and my intentions and current state of affairs:
http://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/CALc40c_p56PAg8mfPyoUvAKWsqn0PBYQmgQW_qFMcRupof8wGg%40mail.gmail.com/#msg34124287

Ruben

--

___
Python tracker 

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

[issue19662] smtpd.py should not decode utf-8

[Arfrever Frehtes Taifersar Arahesis]

Arfrever Frehtes Taifersar Arahesis added the comment:

> New changeset a7d3074fa888 by R David Murray in branch 'default':
> #19662: Make requirement to support arbitrary keywords explicit.
> https://hg.python.org/cpython/rev/a7d3074fa888

s/keword/keyword/

--
nosy: +Arfrever

___
Python tracker 

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

[issue23780] Surprising behaviour when passing list to os.path.join.

[Roundup Robot]

Roundup Robot added the comment:

New changeset 84af71e8c051 by Serhiy Storchaka in branch 'default':
Issue #23780: Improved error message in os.path.join() with single argument.
https://hg.python.org/cpython/rev/84af71e8c051

--
nosy: +python-dev

___
Python tracker 

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

[issue24212] Idle, 2.7, backport idlelib.__main__, enable py -m idlelib

[Arfrever Frehtes Taifersar Arahesis]

Changes by Arfrever Frehtes Taifersar Arahesis :


--
nosy: +Arfrever

___
Python tracker 

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

[issue4709] Mingw-w64 and python on windows x64

[Paul Moore]

Paul Moore added the comment:

Ruben,
Thanks for the detailed explanations. Just to be clear, I am *not* the person 
that will take this aspect of the process forward - that will be the community 
of people building (or wanting to build) extensions for Python with mingw. I 
don't know if that community has a spokesperson yet (or even if it's a 
well-defined "community") but they would be the ones to to engage with the 
mingw developers.

In particular, the choices around ABI incompatible variants that you mention 
are precisely the sort of thing the community needs to establish - which 
variant is compatible with Python, how to get a maintained build of that 
variant (there seems to be a lot of "get such-and-such's personal build from 
this URL" in the current crop of instructions for building Python extensions 
with mingw - that's not really sustainable).

The problem boils down to there needing to be a definitive, simple, and 
maintained set of instructions and software for "how to set up a mingw build 
environment for Python extensions". The core Python developers can't provide 
that (as we use MSVC). What we can do, when such a thing exists, is look at 
whether it's a toolchain that we can reasonably support.

At the moment mingw patch requests come in based on someone's custom build 
environment, that we can't easily reproduce, and we can't be sure is the same 
as anyone else's. That's not something we can support - hence the frustration 
from the mingw-using community, because we have partial support from the days 
when mingw.org and cygwin were the only two options for gcc-on-windows and we 
didn't really communicate the change in status (which admittedly would have 
been "we no longer support mingw", so wouldn't have helped much...)

Hopefully, the discussion on this issue clarifies the position a bit. Give us a 
well-defined "gcc on Windows" (mingw) platform definition, and we'll look at 
supporting it. Otherwise, we can maintain the status quo (what's there remains, 
but patches pretty much never go in, because reproducing issues and testing 
changes is too much effort to be viable) or formally drop support for mingw 
(which I'd be reluctant to do, but it may be worth it just to offer clarity).

--

___
Python tracker 

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

[issue15836] unittest assertRaises should verify excClass is actually a BaseException class

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Core developers left a couple of notes and the patch itself is outdated. Here 
is updated patch that addresses all comments. It also extends the checking to 
assertRaisesRegex(), assertWarns() and assertWarnsRegex().

There is a risk to break existing incorrect tests if the argument is a tuple. 
They can be passed for now because caught exception or warning is found before 
incorrect value. For example:

with self.assertRaises((ValueError, None)):
int('a')

--
Added file: http://bugs.python.org/file39426/issue15836_2.patch

___
Python tracker 

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

[issue22939] integer overflow in iterator object

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

If Raymond will not stop me, I'll commit the patch tomorrow.

--
assignee:  -> serhiy.storchaka

___
Python tracker 

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

[issue7267] format method: c presentation type broken in 2.7

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
nosy: +benjamin.peterson

___
Python tracker 

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

[issue4709] Mingw-w64 and python on windows x64

[Ruben Van Boxem]

Ruben Van Boxem added the comment:

Paul,

OK, I understand your point of view. As you say, there is no single "MinGW" 
community, nor a guiding body that takes these decisions. If you're not willing 
to choose one, all I can say is this: it will probably not matter which version 
you choose (all will work), only mixing them won't work.

A sound choice would be to follow the Qt Project (it's what they ship in their 
SDK):
http://doc.qt.io/qt-5/supported-platforms.html#reference-configurations
They chose the dw2/posix combo, which IMHO is the best choice all-round.
For 64-bit, the obvious one is seh/posix.
Incidentally, that's what MSYS2 people chose, and they regularly build all of 
Python with these toolchains (plus some other packages including numpy/scipy), 
see https://github.com/Alexpux/MINGW-packages/ and search for "-python-".
These python builds are done from source, do not link to msvcr100, but just 
msvcrt.dll, which is the OS component MinGW GCC links to currently and in the 
foreseeable future.

As it stands, you can easily reproduce these builds by:
1. Installing MSYS2 (download and install, see 
http://sourceforge.net/p/msys2/wiki/MSYS2%20installation/)
2. Installing GCC (i.e. "pacman -S mingw-w64-i686-gcc" for 32-bit or "pacman -S 
mingw-w64-x86_64-gcc" for 64-bit)
3. Installing all of Python's dependencies (see e.g. PKGBUILD: 
https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-python2/PKGBUILD#L14)
4. running makepkg in the directory with the python PKGBUILD with the patches 
next to it. make sure to use the "MinGW-w64 Win64 Shell" or "MinGW-w64 Win32 
Shell") that MSYS2 places in your start menu. This sets PATH to include the 
relevant toolchains and tools, much like the VS command prompts.

You can then extract the necessary dependency DLLs from the MSYS2's 
/mingw32/bin and /mingw64/bin directories so that a standalone MinGW-w64 Python 
installation can be created from that without issue. 

If you feel this qualifies as an easy, maintainable, reproducible setup, 
perhaps work can be done to integrate the large amount of patches currently 
required. Note that these patches will work with any decent and/or official 
MinGW-w64 GCC build. The time of everyone needing to build their own toolchain 
is past. Even if some people still building all kinds of cludgy variants seem 
to have missed the memo.

Note that these builds differ from the official MSVC builds (which may not be a 
bad thing: it keeps MSVC<->GCC compatibility issues arising from mixing the 
code to a minimum). Obviously, when MinGW-w64/GCC supports the UCRT stuff, this 
incompatibility can be harmoniously resolved. Until then, this seems to me like 
a good solution, and it is how everyone else is doing it (i.e. separate GCC 
builds on Windows).

If there is no interest in having a (community-supported, semi-official) 
GCC-built Python on Windows, I'm sure something else can also be worked out, 
which would include stripping the current dinosaur -mno-cygwin code which is 
what this bug was originally all about.

--

___
Python tracker 

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

[issue24225] IDLE test filenames don't match script filenames.

[Al Sweigart]

Al Sweigart added the comment:

The idle_renaming.patch file is for the file renamings under idlelib

The idletest_renaming.patch file is for the file renamings under 
idlelib/idle_test

The idle_updating_imports.patch file is for the content updates (mostly for 
import statements) due to the renamings.

The unit tests all pass with these changes.

--
keywords: +patch
type:  -> enhancement
Added file: http://bugs.python.org/file39427/idle_renaming.patch

___
Python tracker 

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

[issue24225] IDLE test filenames don't match script filenames.

[Al Sweigart]

Changes by Al Sweigart :


Added file: http://bugs.python.org/file39428/idletest_renaming.patch

___
Python tracker 

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

[issue24225] IDLE test filenames don't match script filenames.

[Al Sweigart]

Al Sweigart added the comment:

(I can reformat these patch files if that helps.)

--
Added file: http://bugs.python.org/file39429/idle_updating_imports.patch

___
Python tracker 

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

[issue24225] IDLE test filenames don't match script filenames.

[Al Sweigart]

Al Sweigart added the comment:

For reference, here's all the files and their new filenames:

aboutDialog.pyabout_dialog.py
AutoComplete.pyautocomplete.py
AutoCompleteWindow.pyautocomplete_window.py
AutoExpand.pyautoexpand.py
Bindings.pybindings.py
CallTips.pycalltips.py
CallTipWindow.pycalltip_window.py
ClassBrowser.pyclass_browser.py
CodeContext.pycode_context.py
ColorDelegator.pycolor_delegator.py
configDialog.pyconfig_dialog.py
configHandler.pyconfig_handler.py
configHelpSourceEdit.pyconfig_help_source_edit.py
configSectionNameDialog.pyconfig_section_name_dialog.py
Debugger.pydebugger.py
Delegator.pydelegator.py
dynOptionMenuWidget.pydyn_option_menu_widget.py
EditorWindow.pyeditor_window.py
FileList.pyfile_list.py
FormatParagraph.pyformat_paragraph.py
GrepDialog.pygrep_dialog.py
HyperParser.pyhyper_parser.py
IdleHistory.pyidle_history.py
idlever.pyidle_ver.py
IOBinding.pyio_binding.py
keybindingDialog.pykeybinding_dialog.py
macosxSupport.pymac_osx_support.py
MultiCall.pymulti_call.py
MultiStatusBar.pymulti_status_bar.py
ObjectBrowser.pyobject_browser.py
OutputWindow.pyoutput_window.py
ParenMatch.pyparen_match.py
PathBrowser.pypath_browser.py
Percolator.pypercolator.py
PyParse.pypyparse.py
PyShell.pypyshell.py
RemoteDebugger.pyremote_debugger.py
RemoteObjectBrowser.pyremote_object_browser.py
ReplaceDialog.pyreplace_dialog.py
RstripExtension.pyrstrip_extension.py
ScriptBinding.pyscript_binding.py
ScrolledList.pyscrolled_list.py
SearchDialog.pysearch_dialog.py
SearchDialogBase.pysearch_dialog_base.py
SearchEngine.pysearch_engine.py
StackViewer.pystack_viewer.py
tabbedpages.pytabbed_pages.py
textView.pytext_view.py
ToolTip.pytool_tip.py
TreeWidget.pytree_widget.py
UndoDelegator.pyundo_delegator.py
WidgetRedirector.pywidget_redirector.py
WindowList.pywindow_list.py
ZoomHeight.pyzoom_height.py
test_config_name.pytest_config_section_name_dialog.py
test_configdialog.pytest_config_dialog.py
test_formatparagraph.pytest_format_paragraph.py
test_grep.pytest_grep_dialog.py
test_hyperparser.pytest_hyper_parser.py
test_idlehistory.pytest_idle_history.py
test_parenmatch.pytest_paren_match.py
test_pathbrowser.pytest_path_browser.py
test_rstrip.pytest_rstrip_extension.py
test_searchdialogbase.pytest_search_dialog_base.py
test_textview.pytest_text_view.py
test_searchengine.pytest_search_engine.py
test_widgetredir.pytest_widget_redirector.py

--

___
Python tracker 

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

[issue15836] unittest assertRaises should verify excClass is actually a BaseException class

[Martin Panter]

Martin Panter added the comment:

I posted a question on Reitveld, but the new patch looks fine in general.

I wouldn’t worry too much about the (ValueError, None) case, since such code is 
probably already broken. If it is a problem though, maybe this could only go 
into the next feature relase (3.5).

--

___
Python tracker 

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

[issue24225] IDLE test filenames don't match script filenames.

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Usually we avoid such mass renamings. This is errorprone and can break 
third-party plugins or even applications that use parts of IDLE. It also will 
made much harder to transfer patches between versions. I'm -1 for this 
proposition.

--
nosy: +kbk, roger.serwy, serhiy.storchaka, terry.reedy

___
Python tracker 

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

[issue24236] TestNG results to Junit results conversion

[R. David Murray]

R. David Murray added the comment:

This doesn't appear to have anything to do with Python.  What was your purpose 
in opening this issue?

--
nosy: +r.david.murray

___
Python tracker 

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

[issue16314] Support xz compression in distutils

[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

[issue24237] PEP 479: missing DeprecationWarning when generator_stop is not used

[Nick Coghlan]

New submission from Nick Coghlan:

>From the StopIteration-in-generators handling transition plan 
>(https://www.python.org/dev/peps/pep-0479/#transition-plan):

* Python 3.5: Enable new semantics under __future__ import; silent deprecation 
warning if StopIteration bubbles out of a generator not under __future__ 
import. 

The first half of that was implemented in issue 22906, but we missed the second 
half.

The reason the latter is needed is so that people can turn the 
DeprecationWarning into an error to test for compatibility with the future 
default behaviour without needing to add the new future flag to their code 
(which would break compatibility with older Python versions). Ram Rachum 
pointed out the absence on python-ideas: 
https://mail.python.org/pipermail/python-ideas/2015-May/033580.html

--
messages: 243576
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: PEP 479: missing DeprecationWarning when generator_stop is not used

___
Python tracker 

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

[issue24237] PEP 479: missing DeprecationWarning when generator_stop is not used

[Nick Coghlan]

Changes by Nick Coghlan :


--
dependencies: +PEP 479: Change StopIteration handling inside generators

___
Python tracker 

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

[issue22906] PEP 479: Change StopIteration handling inside generators

[Nick Coghlan]

Nick Coghlan added the comment:

We missed the deprecation warning part of the PEP (for when the future import 
is *not* in effect, but the default behaviour will change in 3.7), but rather 
than reopening this one, I filed a new issue: issue 24237

--

___
Python tracker 

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

[issue24238] Avoid entity expansion attacks in Element Tree

[Martin Panter]

New submission from Martin Panter:

This patch could be the basis of an alternative to Christian Heimes’s patch in 
Issue 17239. It adds a parser flag to the Element Tree modules so that they 
will immediately raise an exception when an entity declaration is encountered. 
I believe this should be sufficient to avoid DOS vulnerabilities like the 
Billion Laughs attack, where a small XML entity reference expands into a large 
string, and/or involves a large number of entity expansions.

I think the advantage of this patch over the patch in Issue 17239 is this one 
should work on the current Expat library (which I understand Python can load 
externally). The other patch modifies the Expat library itself, so would only 
be useful when Python’s internal Expat library is being used (or the external 
Expat library was also patched in a similar manner).

The disadvantage of this patch is that it disables handling XML data as soon as 
an entity is declared, even if the entities are not actually used, or they are 
only used in a non-malicious way. The other patch allows a limited amount of 
entity expansion.

I would like some feedback on:

* What others think of the basic approach, compared with Christian’s approach 
in Issue 17239
* If reject_entities=True should be switched on by default, which could break 
compatibility, but could be sensible for most cases of basic XML parsing
* If my changes to the examples in the documentation are excessive
* If other Element Tree APIs should be modified similarly to XMLParser

So far I have only changed the XMLParser class. The following APIs accept a 
parser object, so can also avoid the vulnerability by passing a custom parser 
object:

* fromstringlist()
* iterparse(), though “parser” is listed as deprecated (by Issue 17741)
* parse() (module-level function)
* XML()
* XMLID()
* ElementTree.parse() (method of ElementTree class)

These APIs don’t have a custom parser object, so they are still always 
vulnerable:

* fromstring()
* XMLPullParser

--
components: XML
files: etree_20130519.patch
keywords: patch
messages: 243577
nosy: christian.heimes, vadmium
priority: normal
severity: normal
status: open
title: Avoid entity expansion attacks in Element Tree
type: security
versions: Python 3.5
Added file: http://bugs.python.org/file39430/etree_20130519.patch

___
Python tracker 

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

[issue19662] smtpd.py should not decode utf-8

[Roundup Robot]

Roundup Robot added the comment:

New changeset a3f2b171b765 by R David Murray in branch 'default':
#19662: fix typo
https://hg.python.org/cpython/rev/a3f2b171b765

--

___
Python tracker 

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

[issue19662] smtpd.py should not decode utf-8

[R. David Murray]

R. David Murray added the comment:

Thanks, Arfrever.

--

___
Python tracker 

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

[issue17239] XML vulnerabilities in Python

[Martin Panter]

Martin Panter added the comment:

I have opened Issue 24238 with a patch for Element Tree that uses my 
EntityDeclHandler technique, instead of patching Expat. I would be interested 
in other people’s thoughts on the approach.

--

___
Python tracker 

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

[issue24215] test_trace uses test_pprint

[R. David Murray]

R. David Murray added the comment:

I've backed out the change set that broke the buildbots (see de9c43fabda6).

I can understand this changeset getting committed, since one doesn't normally 
expect a change in the tests to break other tests (though I myself do often run 
the full test suite anyway), but it is not acceptable that the breakage of the 
buildbots was not addressed quickly.  The problem should have been fixed or the 
changeset backed out within hours of the problem being recognized.

--
nosy: +r.david.murray

___
Python tracker 

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

[issue24229] pathlib.Path should have a copy() method

[Josh Holland]

Josh Holland added the comment:

Serhiy makes a series of good points, which I hadn't really considered before 
filing this report. It was mostly laziness on my part while dashing off a quick 
script - I knew I wouldn't have to deal with the edge cases so subconsciously 
dismissed them, especially as the code I wrote to copy was only a couple of 
lines.

So I'm happy for this bug to be closed with no change needed.

--

___
Python tracker 

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

[issue24215] test_trace uses test_pprint

[Roundup Robot]

Roundup Robot added the comment:

New changeset cf52756f19b6 by R David Murray in branch '3.4':
#24215: also back out changeset that broke test_trace in 3.4.
https://hg.python.org/cpython/rev/cf52756f19b6

--
nosy: +python-dev

___
Python tracker 

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

[issue24215] test_trace uses test_pprint

[R. David Murray]

Changes by R. David Murray :


--
priority: release blocker -> normal

___
Python tracker 

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

[issue6598] calling email.utils.make_msgid frequently has a non-trivial probability of generating colliding ids

[Barry A. Warsaw]

Barry A. Warsaw added the comment:

On May 19, 2015, at 07:23 AM, Serhiy Storchaka wrote:

>Now there is a question. Is it worth to use base16 (hexadecimal) to compact
>message id to 34 characters or base32 to compact it to 27 characters? Using
>base16 is pretty easy: just replace %d with %x. Using base32 is more
>complicated.

It might not be relevant, but we're using base 32 in Message-ID-Hash:

http://wiki.list.org/DEV/Stable%20URLs

We settled on base 32 after consulting with the curators of mail-archive.com
and others.

--

___
Python tracker 

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

[issue24091] Use after free in Element.extend (1)

[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

[issue24239] Allow to configure which gpg to use in distutils upload

[Cédric Krier]

New submission from Cédric Krier:

'gpg' is hard coded in distutils/command/upload.py and the spawn command 
doesn't even use the shell aliases.
So if you have only gpg2 installed it doesn't work.
I think the name (or even the all command line) should be configurable from 
~/.pypirc

--
components: Distutils
messages: 243586
nosy: ced, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: Allow to  configure which gpg to use in distutils upload
type: enhancement

___
Python tracker 

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

[issue24240] PEP 448: Update the language reference

[Stefan Krah]

New submission from Stefan Krah:

Since Grammar/Grammar relies on semantic postprocessing in ast.c,
it would be nice to have an update of the (human readable) Grammar
in the language reference docs.

--
messages: 243587
nosy: skrah
priority: normal
severity: normal
status: open
title: PEP 448: Update the language reference

___
Python tracker 

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

[issue24240] PEP 448: Update the language reference

[Stefan Krah]

Changes by Stefan Krah :


--
assignee:  -> docs@python
components: +Documentation
nosy: +docs@python
stage:  -> needs patch
type:  -> enhancement
versions: +Python 3.5

___
Python tracker 

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

[issue24215] test_trace uses test_pprint

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Sorry, I expected this issue be solved much faster.

Unfortunately Terry's recipe doesn't work. Here is a patch that reapplies 
changes that broke buildbots (additional tests for buildins and making 
test_pprint discoverable), and also fixes test_trace and makes it discoverable.

I found yet one issue with test_trace. It fails if run regrtest with the -m 
option (both patched and unpatched versions, there is no regression).

$ ./python -m test.regrtest test_trace
[1/1] test_trace
1 test OK.
$ ./python -m test.regrtest -m test_coverage test_trace
[1/1] test_trace
test test_trace failed -- Traceback (most recent call last):
  File "/home/serhiy/py/cpython-3.4/Lib/test/test_trace.py", line 313, in 
test_coverage
self.assertTrue("pprint.cover" in files)
AssertionError: False is not true

1 test failed:
test_trace

It fails because run_unittest() is used in tested script. That is yet one 
argument against using test_pprint in test_trace.

--
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file39431/issue24215.patch

___
Python tracker 

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

[issue16995] Add Base32 support for RFC4648 "Extended Hex" alphabet (patch attached)

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
stage:  -> patch review
versions: +Python 3.5 -Python 3.4

___
Python tracker 

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

[issue4709] Mingw-w64 and python on windows x64

[Paul Moore]

Paul Moore added the comment:

> If there is no interest in having a (community-supported, semi-
> official) GCC-built Python on Windows, I'm sure something else
> can also be worked out, which would include stripping the current
> dinosaur -mno-cygwin code which is what this bug was originally
> all about.

The issue is about building Python *extensions* with gcc, not about building 
Python itself - that's not a supported approach at all (MSYS2 does it, but the 
patches used aren't going to be integrated in core Python).

The problem is that the people who build those extensions (which is not me, nor 
is it anyone on the core Python team) have never settled on a single version of 
the mingw toolchain as "what they want the distutils to support". So each bug 
report or patch is needs different "how to install mingw" instructions to be 
followed before a core developer can work on it.

I'm suggesting that the people raising distutils bugs about mingw support get 
together and agree on a common toolchain that they'll use as a basis for any 
future bugs/patches.

--

___
Python tracker 

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

[issue24241] webbrowser (very often) doesn't support the 'new' parameter

[David Steele]

New submission from David Steele:

When calling webbrowser.open*(), the module goes through a list of installed 
browsers, and uses the first one that succeeds, to process the request.

The first 'browsers' in the 'X' list are 'xdg-open' and others of that ilk. The 
problem is that they only have one 'open' behavior - the 'new' parameter is 
ignored ('same window', 'new window', 'new tab').

I can get the fully supported default browser in GNOME with e.g.

def browser():
app = Gio.app_info_get_default_for_type('x-scheme-handler/https', True)
bpath = app.get_filename()

for candidate in webbrowser._tryorder:
if candidate in bpath:
return webbrowser.get(using=candidate)

return webbrowser.get()


... but this code accesses a private list.

The problems are:

1) webbrowser does not determine and return the current default browser.

2) There is no public interface for determining the current/installed browser 
type list.


The problem can be mitigated by resolving (1) and/or (2).


Also, the browser type list in the documentation is missing many entries.

Checked on 2.7 and 3.4. I believe this is valid across all supported versions.

--
messages: 243590
nosy: daves
priority: normal
severity: normal
status: open
title: webbrowser (very often) doesn't support the 'new' parameter
type: behavior

___
Python tracker 

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

[issue16995] Add Base32 support for RFC4648 "Extended Hex" alphabet (patch attached)

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

The patch can't be longer applied cleanly. It should be synchronized with 
sources. It is the last chance for this feature to get to 3.5 if somebody will 
update the patch and add the documentation.

The feature itself LGTM. The only my doubt is about the name of boolean 
parameter. "base32hex" is recommended as encoding name. Parameter can be named 
as "exthex" or "extended_hex". Or may be add separate functions 
b32hexencode/b32hexdecode. I'm not sure.

--
nosy: +pitrou

___
Python tracker 

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

[issue24215] test_trace uses test_pprint

[R. David Murray]

R. David Murray added the comment:

If you are looking for a small test file to switch to, perhaps test_uu would be 
a good candidate.  It isn't very likely to grow, since I don't think uu 
encoding is used much any more, so the likelyhood of someone caring about it is 
relatively low.  But I haven't looked at what test_trace is using test_pprint 
for, so perhaps it isn't suitable.

--

___
Python tracker 

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

[issue24241] webbrowser default browser detection and/or public API for _trylist.

[R. David Murray]

R. David Murray added the comment:

Any change is going to be an enhancement, so it will only go in 3.6 (at this 
point...beta/feature freeze for 3.5 is this weekend).

Would you like to propose a patch?

--
nosy: +r.david.murray
stage:  -> needs patch
title: webbrowser (very often) doesn't support the 'new' parameter -> 
webbrowser default browser detection and/or public API for _trylist.
type: behavior -> enhancement
versions: +Python 3.6

___
Python tracker 

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

[issue24215] test_trace uses test_pprint

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

There are issues with additional tests for uu.

The fact that test_trace fails with the -m option means that any file that runs 
unittest is not good example (unittest looks on sys.argv).

--

___
Python tracker 

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

[issue24242] property performance regression

[Hannes Ovrén]

New submission from Hannes Ovrén:

There seems to be a significant regression in performance when using @property 
in Python 2.x compared to 3.x.

Test code:

class A:
def __init__(self, x, y):
self.x = x
self.y = y
@property
def y(self):
return self._y
@y.setter
def y(self, value):
self._y = value

from timeit import timeit
a = A(1, 2)
timeit('a.x', 'from __main__ import a')
timeit('a.y', 'from __main__ import a')


On my machine (Fedora Linux, x64) I get the following timings:

2.7.8:
a.x : 0.05482792854309082
a.y : 0.05585598945617676

3.4.1:
a.x : 0.06391137995524332
a.y : 0.31193224899470806

I.e. The performace of using a property vs a ordinary member is more or less 
the same in 2.7, while it incurs a 5x penalty in 3.4.

--
messages: 243595
nosy: hovren
priority: normal
severity: normal
status: open
title: property performance regression
type: performance

___
Python tracker 

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

[issue23985] Crash when deleting slices from duplicated bytearray

[Martin Panter]

Martin Panter added the comment:

Posting a new patch which combines both fixes and adds some test cases. However 
the test needs Python to be built with “./configure --with-pydebug” to detect 
the buffer overrun; without this the test will probably silently pass.

I removed the offending buffer space check, and let it always call 
PyBufferArray_Resize(). I also looked around the bytearray module for similar 
errors for other operations but I couldn’t find any. The other cases already 
tend to always call PyByteArray_Resize().

--
Added file: http://bugs.python.org/file39432/bytearray-fixes.v2.patch

___
Python tracker 

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

[issue24242] property performance regression

[Raymond Hettinger]

Raymond Hettinger added the comment:

The test script has a bug.  The class needs to inherit from object in Python 2.7

--
nosy: +rhettinger
resolution:  -> not a bug
status: open -> closed

___
Python tracker 

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

[issue24241] webbrowser default browser detection and/or public API for _trylist.

[David Steele]

David Steele added the comment:

On Tue, May 19, 2015 at 10:19 AM, R. David Murray
 wrote:
...
> Would you like to propose a patch?

My preferred solution would be a bit intrusive - check for and use
xdg-settings or gi.repository.Gio to identify the default browser, and
match the result against the type list. I'm not sure that would get
approval, nor am I sure of the best standard-library-compliant way to
go about it.

--

___
Python tracker 

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

[issue24242] property performance regression

[Hannes Ovrén]

Hannes Ovrén added the comment:

Yes, changing to class A(object) does indeed cause the same magnitude of 
performance drop in Python 2.7 as well. Thanks!

--

___
Python tracker 

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

[issue23377] HTTPResponse may drop buffer holding next response

[Demian Brecht]

Demian Brecht added the comment:

If nobody else gets to it first, I'll try to get to review this later today or 
tomorrow. Apologies for the delay on the review Martin, a new baby (coming next 
month), moving /and/ taking on a new job all at the same time seems to limit 
free time a little ;)

--

___
Python tracker 

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

[issue12319] [http.client] HTTPConnection.putrequest not support "chunked" Transfer-Encodings to send data

[Demian Brecht]

Demian Brecht added the comment:

> What's the status on this one? It looks like some review comments need 
> addressing.

That's about it. Unfortunately I've been pretty tied up over the last month and 
a bit. I'll try to get to hopefully closing this out over the next few days.

--

___
Python tracker 

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

[issue24228] Interpreter triggers segmentation fault at the starting

[doz]

doz added the comment:

I manually disabled xxlimited (file xxlimited.c removed , and lines in setup.py 
 commented) because : 

In file included from ./Include/Python.h:68,
 from /build/python3-3.4.2/Modules/xxlimited.c:17:
./Include/object.h:65:2: error: #error Py_LIMITED_API is incompatible with 
Py_DEBUG, Py_TRACE_REFS, and Py_REF_DEBUG

So python has been rebuilt with option  -with-pydebug 
Now, I don't have segfault thanks to assert of line 821

#python
python: Objects/dictobject.c:821: insertdict: Assertion `ep->me_key != ((void 
*)0) && ep->me_key != (&_dummy_struct)' failed.
Aborted

buildroot-2015.02 set the following configuration options :
./configure --target=arm-buildroot-linux-gnueabi 
--host=arm-buildroot-linux-gnueabi --build=x86_64-unknown-linux-gnu 
--prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --localstatedir=/var 
--program-prefix="" --enable-ipv6  --enable-shared  --disable-curses 
--with-libmpdec=none --with-expat=none --enable-old-stdlib-cache 
--disable-sqlite3 --disable-codecs-cjk --disable-ossaudiodev --with-pydebug 
--without-ensurepip --without-cxx-main --with-system-ffi --disable-pydoc 
--disable-test-modules --disable-lib2to3 --disable-tk --disable-nis 
--disable-idle3 –disable-pyo-build

--

___
Python tracker 

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

[issue24228] Interpreter triggers segmentation fault at the starting

[doz]

doz added the comment:

value of ep->me_key equals 0

--

___
Python tracker 

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

[issue22931] cookies with square brackets in value

[Demian Brecht]

Demian Brecht added the comment:

> This needs a review from the people who created and applied the security 
> patch.

+ Guido (committed https://hg.python.org/cpython/rev/9e765e65e5cb)

--
nosy: +gvanrossum

___
Python tracker 

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

[issue4709] Mingw-w64 and python on windows x64

[Руслан Ижбулатов]

Руслан Ижбулатов added the comment:

>> If there is no interest in having a (community-supported, semi-
>> official) GCC-built Python on Windows, I'm sure something else
>> can also be worked out, which would include stripping the current
>> dinosaur -mno-cygwin code which is what this bug was originally
>> all about.
>
> The issue is about building Python *extensions* with gcc, not about
> building Python itself - that's not a supported approach at all
> (MSYS2 does it, but the patches used aren't going to be integrated
> in core Python).

Let's say you have the official, upstream W32 CPython, built with MSVC and 
linking with, say, msvcr90.dll
You build, say, libarchive-1.dll with MinGW-w64, because that's what you use to 
build stuff. Because it's MinGW-w64, libarchive-1.dll links to msvcrt.dll.
Then you want to build, say, pyarchive extension for your Python and you do 
that with MinGW-w64, because that's what you use to build stuff. Because it's 
msvcrt.dll, libpyarchive.pyd link to msvcrt.dll.
Then you run Python code that takes, say, sys.stdout file object and passes it 
to pyarchive. Python file object is backed by msvcr90 file descriptor. 
pyarchive expects a file object backed by msvcrt file descriptor. Boom.

Only three ways of avoiding this:
1) Use MSVC for everything. This is what upstream CPython does.
2) Use MinGW-w64 for everything (including CPython itself). This is what MSYS2 
does.
3) Use MSVC for CPython and MinGW-w64 for the rest and somehow ensure that FDs 
are converted when passing the CRT barrier. And stat structs as well. And 
everything else that differs. This is a path of frustration that leads nowhere 
and does not seem sustainable to me.

This is why the discussion keeps coming back to building Python with MinGW-w64. 
This is why Universal CRT can be a solution (the absence of CRT incompatibility 
would resolve a lot of issues; the rest is manageable - remember MinGW-w64 has 
to use the same CRT/W32API DLLs that MSVC does, so binary compatibility is 
always achievable for anything with C interface).

--
nosy: +LRN

___
Python tracker 

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

[issue24228] Interpreter triggers segmentation fault at the starting

[doz]

doz added the comment:

Problem also present with only configuration option :
 --enable-ipv6  --enable-shared  --disable-curses --with-libmpdec=none 
--with-expat=none --enable-old-stdlib-cache --disable-sqlite3 
--disable-codecs-cjk --disable-ossaudiodev --with-pydebug

--

___
Python tracker 

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

[issue4709] Mingw-w64 and python on windows x64

[Paul Moore]

Paul Moore added the comment:

On 19 May 2015 at 17:09, Руслан Ижбулатов  wrote:
> 3) Use MSVC for CPython and MinGW-w64 for the rest and somehow ensure that 
> FDs are converted when passing the CRT barrier. And stat structs as well. And 
> everything else that differs. This is a path of frustration that leads 
> nowhere and does not seem sustainable to me.

That is the one this issue is about. It *is* possible (mingw grew the
-lmsvcr100 and similar flags, at least in part to support it). But
it's not easy to set up, and the people asking for it to be supported
have never really addressed all of the issues involved (at least not
in a reproducible/supportable way).

Building Python with mingw, while out of scope for this particular
issue, has always failed because nobody has been willing to step up
and offer the long-term support commitment that would be required,
AIUI.

--

___
Python tracker 

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

[issue22107] tempfile module misinterprets access denied error on Windows

[Paul Moore]

Paul Moore added the comment:

==
ERROR: test_read_only_directory (test.test_tempfile.TestMkdtemp)
--
Traceback (most recent call last):
  File "C:\Work\Projects\cpython\lib\test\test_tempfile.py", line 267, in 
_inside_empty_temp_dir
yield
  File "C:\Work\Projects\cpython\lib\test\test_tempfile.py", line 286, in 
test_read_only_directory
self.skipTest("can't set the directory read-only")
  File "C:\Work\Projects\cpython\lib\unittest\case.py", line 645, in skipTest
raise SkipTest(reason)
unittest.case.SkipTest: can't set the directory read-only

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Work\Projects\cpython\lib\test\test_tempfile.py", line 289, in 
test_read_only_directory
self.assertEqual(os.listdir(tempfile.tempdir), [])
  File "C:\Work\Projects\cpython\lib\contextlib.py", line 77, in __exit__
self.gen.throw(type, value, traceback)
  File "C:\Work\Projects\cpython\lib\test\test_tempfile.py", line 269, in 
_inside_empty_temp_dir
support.rmtree(dir)
  File "C:\Work\Projects\cpython\lib\test\support\__init__.py", line 374, in 
rmtree
_rmtree(path)
  File "C:\Work\Projects\cpython\lib\test\support\__init__.py", line 354, in 
_rmtree
_waitfor(os.rmdir, path)
  File "C:\Work\Projects\cpython\lib\test\support\__init__.py", line 301, in 
_waitfor
func(pathname)
PermissionError: [WinError 5] Access is denied: 
'C:\\Users\\Gustav\\AppData\\Local\\Temp\\tmpe53kiky0'

==
ERROR: test_read_only_directory (test.test_tempfile.TestMkstempInner)
--
Traceback (most recent call last):
  File "C:\Work\Projects\cpython\lib\test\test_tempfile.py", line 267, in 
_inside_empty_temp_dir
yield
  File "C:\Work\Projects\cpython\lib\test\test_tempfile.py", line 286, in 
test_read_only_directory
self.skipTest("can't set the directory read-only")
  File "C:\Work\Projects\cpython\lib\unittest\case.py", line 645, in skipTest
raise SkipTest(reason)
unittest.case.SkipTest: can't set the directory read-only

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Work\Projects\cpython\lib\test\test_tempfile.py", line 289, in 
test_read_only_directory
self.assertEqual(os.listdir(tempfile.tempdir), [])
  File "C:\Work\Projects\cpython\lib\contextlib.py", line 77, in __exit__
self.gen.throw(type, value, traceback)
  File "C:\Work\Projects\cpython\lib\test\test_tempfile.py", line 269, in 
_inside_empty_temp_dir
support.rmtree(dir)
  File "C:\Work\Projects\cpython\lib\test\support\__init__.py", line 374, in 
rmtree
_rmtree(path)
  File "C:\Work\Projects\cpython\lib\test\support\__init__.py", line 354, in 
_rmtree
_waitfor(os.rmdir, path)
  File "C:\Work\Projects\cpython\lib\test\support\__init__.py", line 301, in 
_waitfor
func(pathname)
PermissionError: [WinError 5] Access is denied: 
'C:\\Users\\Gustav\\AppData\\Local\\Temp\\tmp0qwkkr7l'

--
nosy: +paul.moore

___
Python tracker 

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

[issue23970] Update distutils.msvccompiler for VC14

[Steve Dower]

Steve Dower added the comment:

New patch. I've renamed the new class _msvccompiler and changed ccompiler to 
use it instead of the old ones.

The old ones are still there to avoid breaking people who were using them 
directly, and the old tests are still there too.

Personally, I expect subtle breakages in actual use (that we couldn't possible 
test for reliably) and I don't like deliberately leaving cruft behind, but it 
seems like the best way to move forward without breaking people.

Would adding a deprecation warning to the orphaned modules make sense? They 
should never be imported in normal use.

--
Added file: http://bugs.python.org/file39433/msvccompiler_3.patch

___
Python tracker 

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

[issue24127] Fatal error in launcher: Job information querying failed

[Dan Bjorge]

Dan Bjorge added the comment:

Confirmed, this is a known Windows 10 tech preview bug - it is specific to 
using 32bit Python on 64bit Windows. It's already been fixed internally, and we 
expect the fix to make it out to one of the next couple of public tech preview 
builds.

Thanks!
-Dan Bjorge (MSFT)

--
nosy: +dbjorge

___
Python tracker 

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

[issue22107] tempfile module misinterprets access denied error on Windows

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Thank you Paul. What with updated patch?

--
Added file: http://bugs.python.org/file39434/tempfile_bad_tempdir_4.patch

___
Python tracker 

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

[issue24228] Interpreter triggers segmentation fault at the starting

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
nosy: +rhettinger

___
Python tracker 

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

[issue24225] IDLE test filenames don't match script filenames.

[Al Sweigart]

Al Sweigart added the comment:

Serhiy: I completely understand. My first instinct is to look at mass renamings 
and dismiss it as cosmetic changes for the sake of cosmetic changes. However, 
there are several problems that this fix corrects:

1) It makes it obvious which identifiers are modules and which are classes:

- AutoComplete.AutoComplete is a module and class with the same name, making 
them ambiguous.
- Same for AutoCompleteWindow.AutoCompleteWindow.
- Same for AutoExpand.AutoExpand.
- Bindings.py is a module but there is also a Bindings member in the 
EditorWindow class.
- Same for CallTips.CallTips having ambiguous module/class name.
- Same for ClassBrowser.ClassBrowser.
- Same for CodeContext.CodeContext.
- Same for ColorDelegator.ColorDelegator
- But not the same for configDialog.ConfigDialog.
- Same for Debugger.Debugger
- Same for Delegator.Delegator
- Same for EditorWindow (this is a big one, where the ambiguious use is in 
several files)
- Same for FileList.FileList
- Same for FormatParagraph.FormatParagraph
- Same for HyperParser.HyperParser
- Same for IOBinding.IOBinding
- Same for MultiCall.MultiCallCreator's inner class, MultiCall.
- Same for MultiStatusBar.MultiStatusBar
- Same for OutputWindow, ParenMatch, PathBrowser, Percolator, PyShell, 
ReplaceDialog, RstripExtension, ScriptBinding, ScrolledList, SearchDialog, 
SearchDialogBase, SearchEngine, ToolTip, UndoDelegator, WidgetRedirector, 
WindowList, ZoomHeight
- There is a StackViewer.py module and a StackViewer class, except the class is 
in Debugger.py

This isn't a trivial, "just remember it works like this in one or two places" 
kind of technical debt.

2) These ambiguous names can be mitigated with "from x import *" statements; 
always use "from idlelib.AutoExpand import AutoExpand" and you can always 
assume "AutoExpand" refers to the class, not the module.

But the codebase doesn't consistently do that. There is "from 
idlelib.AutoExpand import AutoExpand" but also "from idlelib import Debugger" 
(so in that file, Debugger refers to the module while Debugger.Debugger refers 
to the class).

2) It puts idle_test names in sync with the files they test. Currently there is 
a test_config_name.py but there is no config_name.py or configName.py file. (It 
tests configSectionNameDialog.py)

3) Any extensions that break due to these changes can be fixed in one line: 
import new_name as OldName

I agree that large changes are error prone. In this case, that's partly because 
names are confusing and ambiguous, which is precisely what this change tries to 
mitigate.

I really beg folks to not dismiss this change out of hand. These readability 
issues are death-by-a-thousand-paper-cuts. I think we should address this 
technical debt, not actively preserve it. IDLE dev is at a standstill, with the 
bulk of it resting on the efforts of a handful of people. Getting it into a 
better state can invite more contributors (I can personally name some people 
who would want to become involved with IDLE but are intimidated by labyrinthine 
codebases.)

I volunteer to test any extension people can name for compatibility issues with 
this change. (Where should I start? IDLEX? The 
https://wiki.python.org/moin/IDLEextensions also lists lwickjr. Are there any 
others?)


All the unit tests pass after these changes, which is something at least.

--

___
Python tracker 

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

[issue24225] IDLE test filenames don't match script filenames.

[Terry J. Reedy]

Terry J. Reedy added the comment:

The idlelib xyz.py filenames (about 60) are a collectively a mess.  There are 
about 6 different styles. I would like to *eventually* change all to short, 
lowercase, PEP-8 names, but the reasons have nothing to do with test names 
(which intentionally look to the future).

1. The variety of styles and length of some makes some hard to learn and 
remember. This discourages new people from working on Idle code.  After years, 
I still find some a problem. For this purpose, the patch does not go far 
enough.  Merely changing 'X' to '_x' does not make a long, multi word or word 
pieces name into a short, one-word name.  For examples: 
config_section_name_dialog.py and dyn_option_menu_widget.py are not where I 
want to end up.

2. Having a module and a class with the same name is confusing. Consider 
'EditorWindow'.  In text, having to disambiguate by appending 'module' or 
'class' is a nuisance.  In code, even that is not possible.  One must jump up 
to the top of a file to see if the import is 'import EditorWindow' or 'from 
EditorWindow import EditorWindow'.

3. A deeper reason I want name changes to be possible is that I would also like 
to be able to do some package-level refactoring.  60 files is already a lot and 
we may need more.  I think AutoComplete.py and AutoCompleteWindow.py should be 
combined into completions.py.  I would combine CallTips.py and CallTipWindow.py 
(I had to look to be sure it was not CallTipsWindow.py) into calltips.py.

In the other hand, PyShell.py has startup code (which I think might better be 
in a separate startup.py), some code for debugger and editor windows, and 
finally shell window code. I think the confusing Window class hierarchy should 
be redone, which would also mean some file reshuffling and renaming.

4. PEP434 suggested that a few generally useful, non-Idle specific files might 
be moved to the tkinter package.  This would also be a name change.


One problem with name changes is continued support for 2.7, which was 
originally scheduled to end about now.  If it were not for that, it would more 
easily be possible to introduce new names in some 3.x.0, possible after 
deprecation warnings.

Another barrier is the unknown usage by extensions of parts of idlelib 
beyond the narrow interface defined in extend.txt: an EditorWindow instance 
with Test, IOBinding, and FileList instances.

Summary: I agree with the goal.  But I have to reject the current patch because 
a) the change will have to be a process, not a single patch, and b) I do not 
agree with many of the new names.

--

___
Python tracker 

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

[issue24215] test_trace uses test_pprint

[Terry J. Reedy]

Terry J. Reedy added the comment:

My recipe worked for me, but I am not surprised that it might fail elsewhere.  
Is the specific purpose of the two problemmatic test_trace test to test that 
trace works with unittest?  It did not seem like it to me.  If not,  test_trace 
could be decoupled from other tests and use a 'tracetest.py' file that defines 
one function to be traced.

In the meanwhile, I think you should disable the two tests in test_trace and 
apply the test_pprint changes, rather than hold test_pprint hostage.

--

___
Python tracker 

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

[issue22442] subprocess.check_call hangs on large PIPEd data.

[juj]

juj added the comment:

This issue still reads open, but there has not been activity in a long time. 
May I ask what is the latest status on this?

Also, any chance whether this will be part of Python 2.x?

--

___
Python tracker 

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

[issue24127] Fatal error in launcher: Job information querying failed

[Paul Moore]

Paul Moore added the comment:

Fantastic news, thanks for the feedback.

Closing this as a third party issue.

--
resolution:  -> third party
status: open -> closed

___
Python tracker 

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

[issue22107] tempfile module misinterprets access denied error on Windows

[Paul Moore]

Paul Moore added the comment:

Works fine with the new patch:

>.\rt.bat -x64 -q test_tempfile

C:\Work\Projects\cpython\PCbuild>"C:\Work\Projects\cpython\PCbuild\amd64\python.exe"
  -Wd -E -bb "C:\Work\Projects\cpython\PCbuild\..\lib\test\regrtest.py" 
test_tempfile

[1/1] test_tempfile
1 test OK.

--

___
Python tracker 

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

[issue23985] Crash when deleting slices from duplicated bytearray

[Roundup Robot]

Roundup Robot added the comment:

New changeset 98c1201d8eea by Antoine Pitrou in branch '3.4':
Issue #23985: Fix a possible buffer overrun when deleting a slice from the 
front of a bytearray and then appending some other bytes data.
https://hg.python.org/cpython/rev/98c1201d8eea

New changeset 06fab9093973 by Antoine Pitrou in branch 'default':
Issue #23985: Fix a possible buffer overrun when deleting a slice from the 
front of a bytearray and then appending some other bytes data.
https://hg.python.org/cpython/rev/06fab9093973

--
nosy: +python-dev

___
Python tracker 

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

[issue23985] Crash when deleting slices from duplicated bytearray

[Antoine Pitrou]

Antoine Pitrou added the comment:

I've committed the patch. Thanks, Martin!

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

[issue24199] Idle: remove idlelib.idlever.py and its use in About dialog

[Terry J. Reedy]

Terry J. Reedy added the comment:

To answer my question, I checked test___all__.py. The check_all helper has this:
with support.check_warnings(
(".* (module|package)", DeprecationWarning),
("", ResourceWarning),
quiet=True):
I presume this means that DeprecationWarnings raised by the following import 
are suppressed.  (There is also a  blacklist.)

--

___
Python tracker 

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

[issue24127] Fatal error in launcher: Job information querying failed

[Henrik Heimbuerger]

Henrik Heimbuerger added the comment:

Dan, thanks so much for taking the time to post back here, and for the good 
news!

--

___
Python tracker 

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

[issue24225] Idlelib: changing file names

[Terry J. Reedy]

Terry J. Reedy added the comment:

Nick, as PEP 434 approver, I would like your comments on this issue.

The pep says that other than the startup modules, "the modules are undocumented 
and effectively private implementations."  It also says that the documented 
extension API should be respected but is vague about the extent to which the 
existence of extensions should otherwise be reasons to block changes to idlelib.

While this issue is about module names, changes to names and behavior within 
modules could also break extensions. We have in fact made such changes without 
worring about this.

Fedora 22 replaced yum with dnf as its package managater.  Accordig to
http://dnf.baseurl.org/2015/05/11/yum-is-dead-long-live-dnf/
one of the reasons is problems with extensions. "Yum plugins are using any 
method from Yum code base thus any change there would cause the sudden crash of 
the Yum utility."  (What yum and idlelib have is common is mostly being 
undocumented.)  In a comment, the author summed up my feelings with respect to 
idlelib: "It really hard to maintain a project where you can’t change anything."

An example is #24199. I want to remove a zombie module, idlever.  Can I?  At 
least for 2.7 and 3.4, I think I will add a deprecation warning.

If we rename and refactor modules for 3.6, I would propose to add stub files to 
2.7 and 3.5 with imports and a deprecation warning.  A combined completions 
module, for example, would get two stub files.  (An alternative for 2.7 could 
be to fix the worst bugs, declare Idle 2.7 frozen, and stop backporting.)

During the PEP 434 discussion, some core developers said that they would like 
to drop Idle completely.  This would break extensions much more thoroughly than 
changes proposed here.

Al: some research into extension practices would be helpful.  But keep in mind 
that idlex is much more than a set of extension modules. I believe it adds its 
own ui. 

Al: the current discrepancies between module and test names are intentional. 
The 'controversy' is entirely about idlelib, hence the title change.  When 
idlelib modules get 'nice' names, test names can be changed to match.

--
nosy: +ncoghlan
title: IDLE test filenames don't match script filenames. -> Idlelib: changing 
file names
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

[issue24225] Idlelib: changing file names

[Terry J. Reedy]

Terry J. Reedy added the comment:

Al, I meant to add that msg243612 better expresses the proper rationale for 
disruptive changes: making it easier for people (newcomers and this 
no-longer-newcomer) to learn idlelib, fix bugs, and make improvements

--

___
Python tracker 

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

[issue4709] Mingw-w64 and python on windows x64

[R. David Murray]

R. David Murray added the comment:

My understanding matches yours, Paul.  Core does not want to *distribute* a 
mingw built python, but if the mingw community came up with a support strategy, 
including one or more buildbots building using mingw, I believe that we would 
accept the patches.  Basically, it has to meet the PEP 11 rules for supported 
platforms (including enough userbase to produce the people to maintain it long 
term :)

--

___
Python tracker 

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

[issue4709] Mingw-w64 and python on windows x64

[Ralf Gommers]

Ralf Gommers added the comment:

A few comments from the perspective of what's needed for the scientific Python 
stack:

1. Of the three options mentioned in msg243605, it's definitely (3) that is of 
interest. We want to build extensions with MinGW-w64 that work with the 
standard MSVC Python builds. We've done this with mingw32 for a very long time 
(which works fine); not being able to do this for 64-bit extensions is the main 
reason why there are no official 64-bit Windows installers for Numpy, Scipy, 
etc.

2. There is work ongoing on a mingw-w64 toolchain that would work for the 
scientific Python stack: 
https://github.com/numpy/numpy/wiki/Mingw-static-toolchain. It actually works 
pretty well today, what needs to be sorted out is ensuring long-term 
maintainability. More details about what it's based on are provided in 
https://github.com/numpy/numpy/wiki/Mingw-w64-faq - I think it's consistent 
with what Ruben van Boxem recommends. Carl Kleffner, who has done a lot of the 
heavy lifting on this toolchain, is working with upstream mingw-w64 and with 
WinPython to ensure not creating yet another incompatible flavor mingw.

3. It's good to realize why making mingw-w64 work is especially important for 
the scientific Python stack: there's a lot of Fortran code in packages like 
Scipy, for which there is no free compiler that works with MSVC. So one could 
use MSVC + ifort + Intel MKL (which is what Enthought Canopy and Continuum 
Anaconda do), but that's quite expensive and therefore not a good solution for 
the many of contributors to the core scientific Python stack nor okay from the 
point of view of needing to provide official binaries that can be redistributed.

Paul's comments on picking a single mingw-w64 version, and that version not 
being a download from someone's personal homepage, make a lot of sense to me. 
We (Carl & several core numpy/scipy/scikit-learn devs) happened to have planned 
a call on this topic soon in order to move towards a long-term sustainable 
plan. I wouldn't expect everything to be sorted out in a couple of weeks (it's 
indeed a hard goal), but knowing that Paul is willing to review and merge 
patches definitely helps.

--

___
Python tracker 

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

[issue22107] tempfile module misinterprets access denied error on Windows

[Roundup Robot]

Roundup Robot added the comment:

New changeset 63f0ae6e218a by Serhiy Storchaka in branch '2.7':
Issue #22107: tempfile.gettempdir() and tempfile.mkdtemp() now try again
https://hg.python.org/cpython/rev/63f0ae6e218a

New changeset 3a387854d106 by Serhiy Storchaka in branch '3.4':
Issue #22107: tempfile.gettempdir() and tempfile.mkdtemp() now try again
https://hg.python.org/cpython/rev/3a387854d106

New changeset 1134198e23bd by Serhiy Storchaka in branch 'default':
Issue #22107: tempfile.gettempdir() and tempfile.mkdtemp() now try again
https://hg.python.org/cpython/rev/1134198e23bd

--
nosy: +python-dev

___
Python tracker 

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

[issue20691] inspect.signature: Consider exposing 'follow_wrapper_chains' option in public API

[Yury Selivanov]

Yury Selivanov added the comment:

Nick,

> However, as noted, I doubt the latter is worth it - let's just expose the 
> flag to decide whether to resolve wrapper chains or not, and leave the 
> inclusion of the already bound value in the reported signature solely as a 
> legacy behaviour of getargspec and getfullargspec.

I agree.  Please take a look at the attached patch.

BTW, Signature.from_function and Signature.from_builtin aren't documented.  Do 
you think it's OK if I drop them?  There is no good use case for them (and we 
have Signature.from_callable in 3.5).

Also, while working on the patch, I noticed that functools.wraps copies 
__annotations__ attribute.  This is really strange.  Most of the times, wrapper 
in python has signature akin to (*args, **kwargs).  Blindly copying 
__annotations__ doesn't make any sense.  What do you think about this?

--
keywords: +patch
Added file: http://bugs.python.org/file39435/sig_wrapped.patch

___
Python tracker 

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

[issue22107] tempfile module misinterprets access denied error on Windows

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Unfortunately the patch doesn't fix original issue and looks as this can't be 
fixed until os.access will be more useful on Windows. But it fixes several 
related issues. mkstemp() now fails early if parent directory doesn't exist or 
is a file. gettempdir() and mkdtemp() now try again in case of collision on 
Windows as well as on Unix. I hope that fixing os.access will automatically fix 
original issue.

Thanks Mark and Paul for testing on Windows. Thanks Tim for explaining issue 
with os.access.

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

[issue20691] inspect.signature: Consider exposing 'follow_wrapper_chains' option in public API

[Yury Selivanov]

Yury Selivanov added the comment:

> Do you think it's OK if I drop them?

Dropping == DeprecationWarning

--

___
Python tracker 

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

[issue4709] Mingw-w64 and python on windows x64

[Paul Moore]

Paul Moore added the comment:

Ralf, thanks for the comments. The scientific community is definitely the key 
group that *need* mingw (as opposed to people who merely want to use it because 
they don't want to buy into MS compilers, or for similar personal reasons).

My personal view is that if the scientific community comes up with a mingw/gcc 
toolchain that they are happy with, and willing to support, then I would see 
that as a reasonable target to be "the" supported mingw toolchain for distutils.

I'd like to see a single-file "download, unzip, and use" distribution rather 
than the current rather intimidating set of instructions on how to set the 
toolchain up - but I'm sure that's part of what you're intending to cover under 
"ensuring long-term maintainability".

--

___
Python tracker 

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

[issue10762] strftime('%f') segfault

[Majeed Arni]

Majeed Arni added the comment:

The problem still exists in 3.4 and 3.5 a4


Unhandled exception in thread started by

--
nosy: +MajeedArni
versions: +Python 3.4, Python 3.5 -Python 2.7, Python 3.1, Python 3.2, Python 
3.3

___
Python tracker 

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

[issue20344] subprocess.check_output() docs misrepresent what shell=True does

[Martin Panter]

Martin Panter added the comment:

“Only the first element . . . will be executed on Unix” is a bit simplistic. 
The behaviour is already described more fully in the “shell” documentation 
under .

Also, “args” is allowed to be a _sequence_, but an _iterable_ is a more general 
concept.

--
nosy: +vadmium

___
Python tracker 

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

[issue12020] Attribute error with flush on stdout,stderr

[Martin Panter]

Martin Panter added the comment:

The documentation already says that “stdout” and friends are meant to be text 
files, and that they may be replaced with file-like objects like StringIO. 
Perhaps the documentation could be more explicit about what text file API is 
required internally (either TextIOBase, or list the required subset of methods).

--
assignee:  -> docs@python
components: +Documentation
nosy: +docs@python, vadmium

___
Python tracker 

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

[issue6445] Add check parameter to subprocess.Popen.communicate

[Martin Panter]

Martin Panter added the comment:

In the mean time, a subprocess.run() API has been added which can call 
communicate() and raise CalledProcessError in one step (depending on 
arguments). See Issue 23342. This might satisfy some use cases, but maybe 
adding the check functionality to the low-level API would be nice as well.

Perhaps a separate check_exit_status() method would be more flexible? Or maybe 
a flag stored in the subprocess object that causes wait() and poll() to do the 
check?

--
nosy: +vadmium

___
Python tracker 

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

[issue4709] Mingw-w64 and python on windows x64

[Case Van Horsen]

Changes by Case Van Horsen :


--
nosy: +casevh

___
Python tracker 

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

[issue24225] Idlelib: changing file names

[Nick Coghlan]

Nick Coghlan added the comment:

One path you may want to consider is progressively factoring out a public 
"idlelib.extensions" API, and treat everything else in idlelib as fair game for 
renaming. Folks tend to be more tolerant of disruption if the new state of 
affairs is also clearly better for them, not just the folks making the change.

In terms of supporting legacy module names without retaining all that 
complexity in the main source code, I'd suggest looking into the way the 
"six.moves" module works.

--

___
Python tracker 

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

[issue10762] strftime('%f') segfault

[Ned Deily]

Ned Deily added the comment:

Majeed, the fixes for this issue were released several years ago and the issue 
has been closed.  Comments on it will likely be ignored.  If you believe there 
is a problem in the current versions of Python 3 (3.4.3) or Python 2 (2.7.9), 
please open a new issue with appropriate supporting documentation of how to 
reproduce the problem (including platforms and versions used) and any resulting 
tracebacks.

--
nosy: +ned.deily
versions: +Python 2.7, Python 3.2 -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

[issue23889] Speedup inspect.Signature.bind

[Yury Selivanov]

Yury Selivanov added the comment:

After some experiments, it looks like bind() is already pretty fast. The only 
way to increase its performance is to rewrite it in C.

I tried to approaches:

1. Refactor ._bind() to produce a high-level instruction set that can be 
cached, and is fast to iterate through and build BoundArguments.  Repo: 
https://github.com/1st1/cpython/tree/bind

Results:

  ===  ==  
===
function / call   bind (3.4)   bind cache hit  bind cache 
miss
  ===  ==  
===
() / ()   0.716s   0.746s  (-4%)   0.799s  
(-10%)
(a, b=1) / (10)   1.140s   0.910s  (+20%)  1.294s  
(-12%)
(a, b=1, *ar) / (10, 20, 30, 40)  1.352s   1.145s  (+15%)  1.520s  
(-11%)
(a, b=1, **ar) / (10, 20, z=30, y=4)  1.364s   1.233s  (+10%)  1.660s  
(-18%)
(a, b=1, *, z, **ar) / (1,2,z=3,y=4)  1.499s   1.363s  (+10%)  1.897s  
(-26%)


2. Refactor ._bind() to compile a function that builds BoundArguments for te 
given args/kwargs shape.  This approach yields more-or-less same results as 
(1), but performance of cache-miss case is just terrible (-200%).  Compiling 
functions on the fly is expensive.  Repo to play with: 
https://github.com/1st1/cpython/tree/bind_jit


I'm closing this issue, until I (or someone else) can implement bind() in C (or 
come up with a faster pure-python implementation).

--
resolution:  -> postponed
stage: needs patch -> 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

[issue20344] subprocess.check_output() docs misrepresent what shell=True does

[R. David Murray]

R. David Murray added the comment:

Can you suggest a better phrasing that is still succinct? (Maybe just 'appear 
to be executed' would make it accurate enough?)  But, that's why there needs to 
be a reference of *some* sort to the full explanation.

I'm not sure what the issue is with iterable/sequence.  check_output/Popen 
accepts an iterable.

--

___
Python tracker 

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

[issue16261] Fix bare excepts in various places in std lib

[Martin Panter]

Martin Panter added the comment:

I reviewed the patch on Reitveld. All of the changes that do not have comments 
look okay to me, although some will definitely have merge conflicts with the 
current code. If someone updated the patch based on the comments, I think it 
may be okay to commit.

--
nosy: +vadmium
stage:  -> needs patch

___
Python tracker 

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

[issue24243] behavior for finding an empty string is inconsistent with documentation

[swanson]

New submission from swanson:

Background:
---
Perhaps this has been addressed elsewhere, but I couldn't find it.  To me, 
semantically, the whole idea of finding nothing, whether in something or in 
nothing is complete and utter nonsense.  I'm a fail-quickly, fail-loudly kind 
of guy, and I'd prefer that any attempt to find nothing would result in an 
exception being raised.

But for whatever reason, the following behavior has long existed:
>>> "".index("") == "A".index("") == 0
True
>>> "" in "" and b"" in b"" and b"" in bytearray(b"")
True
>>> "" in "A" and b"" in b"A" and b"" in bytearray(b"A")
True


The Problem:

The various string types (str, bytes, bytearray) all have the following 
functions: count, find, rfind, index, rindex
Each of these functions accepts optional parameters "start" and "end".  The 
documentation for each says something like "Optional arguments start and end 
are interpreted as in slice notation."  This is not the case.

On the one hand:
>>> "".find("") == ""[0:0].find("") == "".find("", 0, 0) == 0
True

Consistent so far, however:
>>> "".find("") == ""[1:0].find("") == 0 and "".find("", 1, 0) == -1
True

So, you see that 'start' and 'end' are NOT in all cases interpreted the same 
way as slicing.  This problem has been around forever, affecting both Python 3 
and 2, so I don't know how many people's code you'd break if you changed the 
behavior to make it consistent with the docs.  But if it's not going to be 
changed, it should at least be a well-documented "feature" of the functions 
with a line or two of explanation in the relevant docs:
https://docs.python.org/3/library/stdtypes.html#bytes-and-bytearray-operations
https://docs.python.org/3/library/stdtypes.html#string-methods

The built-in types bytes, bytearray, and str also have the functions 
"startswith" and "endswith" that also take optional 'start' and 'end' 
arguments.  The documentation does not specifically say (as for count, (r)find, 
and (r)index) that these are "interpreted as in slice notation".  Instead, it 
says: "With optional start, test string beginning at that position. With 
optional end, stop comparing string at that position."  That wording is equally 
confusing and erroneous.  The natural interpretation of that would lead you to 
believe that, unlike slicing:
"A".startswith("A",0,0) == True
however it's really == False because the 'end' index is like slicing.

Now, as to the interpretation of finding nothing, it's a mixed bag:

For str:
>>> "".startswith("",0,0)
True
>>> "".startswith("",1,0)
True
>>> "".endswith("",0,0)
True
>>> "".endswith("",1,0)
True

For bytes: (and the same for bytearray)
>>> b"".startswith(b"",0,0)
True
>>> b"".startswith(b"",1,0)
False
>>> b"".endswith(b"",0,0)
True
>>> b"".endswith(b"",1,0)
False

--
assignee: docs@python
components: Documentation
messages: 243640
nosy: docs@python, swanson
priority: normal
severity: normal
status: open
title: behavior for finding an empty string is inconsistent with documentation
type: behavior

___
Python tracker 

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

[issue24244] Python Crash on strftime with %f on Python 3

[Majeed Arni]

New submission from Majeed Arni:

http://bugs.python.org/issue11735 fixed in 2.7, but in 3.4 and 3.5 the same 
problem exists. Just crashes python.

--
components: Library (Lib)
messages: 243641
nosy: MajeedArni
priority: normal
severity: normal
status: open
title: Python Crash on strftime with %f on Python 3
versions: 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

[issue24230] tempfile.mkdtemp() doesn't work with bytes paths

[Gregory P. Smith]

Gregory P. Smith added the comment:

Attached is a patch with implementation, tests and docs.  I didn't have to 
duplicate too much thankfully.  Just figure out where to put the type 
conversions.  Review would be nice, but I'll err on the side of getting this in 
before beta 1 (May 24 per https://www.python.org/dev/peps/pep-0478/) so any 
corrections can be dealt with during the beta cycle.

Augie & Matt, can you confirm that this patch does what y'all need for 
Mercurial?

--
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file39436/issue24230-gps01.patch

___
Python tracker 

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

[issue20344] subprocess.check_output() docs misrepresent what shell=True does

[Martin Panter]

Martin Panter added the comment:

Actually David I didn’t notice your suggested wording 
 before. Adding that last 
sentence, pointing to the full description of the Popen constructor, would be 
fine.

My complaint about mentioning “iterable” is that iterables are not mentioned 
anywhere else in the documentation. I would rather leave it out or change it to 
“sequence”, unless the rest of the documentation is made consistent, e.g. “args 
. . . should be a string, or a sequence of program arguments” would also need 
fixing.

--

___
Python tracker 

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

[issue24236] TestNG results to Junit results conversion

[Tushar]

Tushar added the comment:

The intention was to facilitate the user who want to port TestNG reports format 
to Junit standard format. I sent a mail to PSF mailing list and I got the 
pointer that this can't be part of standard library but PyPI. So I will upload 
this as a package instead of a part of std library.

--
components: +Devguide -Extension Modules
nosy: +ezio.melotti, willingc

___
Python tracker 

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

[issue24236] TestNG results to Junit results conversion

[Tushar]

Changes by Tushar :


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

___
Python tracker 

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

[issue24245] Eliminate do-nothing exception handlers

[Martin Panter]

New submission from Martin Panter:

These changes remove exception handlers that simply reraise the exception. They 
are not needed because either they are at the end of the exception handler 
list, or the exception being reraised would not be caught by any other handler 
(e.g. no need to reraise SystemExit if you are only interested in Exception). I 
think they make the code more confusing to read.

I noticed the tkinter/font.py dead code when reading the code, Victor Stinner 
pointed out the distutils case in Issue 21259, and I found the rest by 
searching for similar cases.

 Lib/distutils/core.py|   2 --
 Lib/idlelib/idle.pyw |  26 +++---
 Lib/idlelib/rpc.py   |   5 +
 Lib/test/regrtest.py |   4 
 Lib/test/test_queue.py   |  10 +++---
 Lib/test/test_urllib2net.py  |   2 --
 Lib/tkinter/font.py  |   2 --
 Lib/unittest/test/support.py |   4 

--
components: Distutils, IDLE, Library (Lib), Tests, Tkinter
files: reraise.patch
keywords: patch
messages: 243645
nosy: dstufft, eric.araujo, vadmium
priority: normal
severity: normal
stage: patch review
status: open
title: Eliminate do-nothing exception handlers
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file39437/reraise.patch

___
Python tracker 

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

[issue24244] Python Crash on strftime with %f on Python 3

[R. David Murray]

R. David Murray added the comment:

Please follow Ned's suggestion that prompted you to open this issue and report 
the exact version of python, your OS, and how to reproduce it.  I cannot 
reproduce it based on the existing issues using python 3.4.1 on Windows 7.

--
nosy: +r.david.murray

___
Python tracker 

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

[issue4709] Mingw-w64 and python on windows x64

[Ralf Gommers]

Ralf Gommers added the comment:

Indeed, our idea of "easy to install" was/is a wheel or set of wheels so that 
"pip install mingw64py" does all you need. If necessary that can of course be 
repackaged as single download to unzip as well.

--

___
Python tracker 

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