[issue29584] 2D list with Bugs when defined by using Multiplication

Ezio Melotti added the comment: Not a bug, see https://docs.python.org/3/faq/programming.html#how-do-i-create-a-multidimensional-list and https://docs.python.org/3/faq/programming.html#why-did-changing-list-y-also-change-list-x -- assignee: -> ezio.melotti nosy: +ezio.melotti

[issue29584] 2D list with Bugs when defined by using Multiplication

New submission from Yaowei Zhang: #If we define a list by: nums = [[0]*3]*3 #nums = [[0,0,0],[0,0,0],[0,0,0]] nums[0][1] = 1 print(mums) # the result is [[0,1,0],[0,1,0],[0,1,0]] #I think it is because all the line use the same list variable, but it suppose #not. -- components: +Build

[issue29533] urllib2 works slowly with proxy on windows

Julia Dolgova added the comment: I sincerely appreciate your time. Thank you very much for your answer. I'll try to test this on python 3.5 -- ___ Python tracker

[issue29584] 2D list with Bugs when defined by using Multiplication

Changes by Yaowei Zhang : -- components: Library (Lib) nosy: Yaowei Zhang priority: normal severity: normal status: open title: 2D list with Bugs when defined by using Multiplication versions: Python 3.5 ___ Python tracker

[issue29583] Python 3.6 won't install on Windows 2012 R2

Eryk Sun added the comment: To install KB3118401 [3], you may first need to install KB2919442 [1] and KB2919355 [2]. The installation order would be as follows: KB2919442: Windows8.1-KB2919442-x64.msu KB2919355: clearcompressionflag.exe Windows8.1-KB2919355-x64.msu

[issue29583] Python 3.6 won't install on Windows 2012 R2

New submission from Lane Campbell: When trying to install Python 3.6 using the "python-3.6.0-amd64.exe" installer on Windows 2012 R2 I encounter a failure. I'm flagging the options in the installer for: Customize Installation Add Python 3.6 to PATH Leaving all Optional Features selected

[issue29157] random.c: Prefer getrandom() over getentropy() to support glibc 2.24 on Linux

Christian Heimes added the comment: Some vendors backport security features to older glibc. -- ___ Python tracker ___

[issue29157] random.c: Prefer getrandom() over getentropy() to support glibc 2.24 on Linux

Vladimír Čunát added the comment: Nitpick: here you always state that it's about glibc-2.24 but I'm very confident it only started with 2.25. -- nosy: +Vladimír Čunát ___ Python tracker

[issue29453] Remove reference to undefined dictionary ordering in Tutorial

Changes by Jim Fasarakis-Hilliard : -- pull_requests: +100 ___ Python tracker ___ ___

[issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5

Big Stone added the comment: Thanks Steve. Change applied, byebye python._pth. -- ___ Python tracker ___ ___

[issue29582] Add Python coverage make target(s)

Barry A. Warsaw added the comment: +1 Probably ought to reconfigure .travis.yml to use the new targets too, if possible. -- ___ Python tracker ___

[issue29582] Add Python coverage make target(s)

New submission from Zachary Ware: Inspired by Barry's post to core-workflow, I'd like to suggest renaming the current "coverage" target to "ccoverage", adding a "pycoverage" target that does what .travis.yml currently does for coverage (minus uploading to codecov), and a "fullcoverage" target

[issue29580] "Built-in Functions" not being functions

R. David Murray added the comment: Agreed with Marc. I don't think there is anything to do here. The fact that python allows classes (which are callables) to be substituted for functions is a strength, but can lead to confusion (and people getting upset when classes end up with lowercase

[issue29581] __init_subclass__ causes TypeError when used with standard library metaclasses (such as ABCMeta)

New submission from Nate Soares: I believe I've found a bug (or, at least, critical shortcoming) in the way that python 3.6's __init_subclass__ interacts with abc.ABCMeta (and, presumably, most other metaclasses in the standard library). In short, if a class subclasses both an abstract class

[issue29580] "Built-in Functions" not being functions

Marc-Andre Lemburg added the comment: While "functions" may not be accurate anymore, they are all callables. Historically, those callables were functions. Later on some of the built-ins were replaced with type objects. Regarding your last comment: It is common in Python to write "func()" for

[issue29442] Use argparse and drop dirty optparse hacks in setup.py

Stefan Krah added the comment: It's okay to reopen if some conditions have changed (which is the case here). -- ___ Python tracker ___

[issue29565] Still broken ctypes calling convention on MSVC / 64-bit Windows (large structs)

Steve Dower added the comment: The contents of the struct is just being big enough to reach the point where it is passed by reference rather than by value. This issue is pointing out that it should be a reference to a temporary copy of the struct, so that if the called function modifies the

[issue29580] "Built-in Functions" not being functions

Stefan Pochmann added the comment: The page also contains many references like "As repr(), return a string containing..." where the "()" should be removed. -- ___ Python tracker

[issue29580] "Built-in Functions" not being functions

New submission from Stefan Pochmann: About https://docs.python.org/3/library/functions.html: The title "Built-in Functions", the table header "Built-in Functions" and the "functions" in the URL all suggest that what's on this page are functions. But many things on that page don't appear to be

[issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5

Steve Dower added the comment: > starting with python-3.6.1rc Works with 3.6.0. The only relevant changes in 3.6.1 are to skip empty lines in the ._pth file, and to avoid overwriting sys.path[0] arbitrarily. -- ___ Python tracker

[issue29565] Still broken ctypes calling convention on MSVC / 64-bit Windows (large structs)

Vinay Sajip added the comment: Just trying to confirm my understanding - in both this issue and #22273, the example struct has a single array member. Is the problem confined just to how ctypes describes arrays in structs/unions to libffi? The comment on #22273 seems to suggest so. --

[issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5

Big Stone added the comment: ok, I understand that the improvement over current solution is, starting with python-3.6.1rc: - remove "python._pth" - check I have a "Lib\os.py" (otherwise a "python36.zip"), - and no pixie dust here or there ? -- ___

[issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5

Paul Moore added the comment: >> an alternative standalone Python interpreter > > It's a convenient way to avoid having your standard library hijacked by > registry keys installed by the regular interpreter. Ah yes, that makes sense - it's maybe not the *right* way, but as a practical approach

[issue29442] Use argparse and drop dirty optparse hacks in setup.py

Changes by Chi Hsuan Yen : Removed file: http://bugs.python.org/file46511/setup-argparse.patch ___ Python tracker ___

[issue29442] Use argparse and drop dirty optparse hacks in setup.py

Chi Hsuan Yen added the comment: Now I have a working patch at PR 139, and dropping optparse is still the way to go, so I reopen it. I'm not familiar with CPython conventions. Sorry if reopening an issue is impolite. -- resolution: not a bug -> status: closed -> open

[issue29442] Use argparse and drop dirty optparse hacks in setup.py

Changes by Chi Hsuan Yen : -- pull_requests: +99 ___ Python tracker ___ ___

[issue29567] Allow argparse to be used in setup.py

Chi Hsuan Yen added the comment: As PR 119 is closed, I'll continue this in issue29442 -- resolution: -> duplicate stage: -> resolved status: open -> closed ___ Python tracker

[issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5

Steve Dower added the comment: > an alternative standalone Python interpreter It's a convenient way to avoid having your standard library hijacked by registry keys installed by the regular interpreter. However, if it detects "Lib\os.py" or "python36.zip" alongside the executable, it

[issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5

Paul Moore added the comment: It's probably worth also saying that maybe winpython shouldn't even be using the _pth file feature. I don't know why it is, but the intended use case for _pth files is embedded systems, so it's not clear how an alternative standalone Python interpreter matches

[issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5

Steve Dower added the comment: The semantics of the ._pth file won't be changing to accommodate security vulnerabilities, sorry. Add a sitecustomize.py file to modify sys.path if you want that behavior. -- ___ Python tracker

[issue29579] Windows Python 3.7 installer broken by README.txt renamed to README.rst

Steve Dower added the comment: I see absolutely no reason to use other projects on github as precedent here, as the developers have likely not made an explicit decision and are just shipping files that they already have. Github may be the home of our development now, but most users don't know

[issue22807] uuid.uuid1() should use uuid_generate_time_safe() if available

Changes by Barry A. Warsaw : -- pull_requests: +98 ___ Python tracker ___ ___

[issue22807] uuid.uuid1() should use uuid_generate_time_safe() if available

Barry A. Warsaw added the comment: I changed my mind on whether this should affect older versions of Python. I have a branch which adds an UUID.is_safe attribute that relays the platform information about whether the UUID was generated safely or not, if available. It's an enum named

[issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5

Big Stone added the comment: If I place a blank line or a semi-column, nothing happen. If i put my relative path ..\test, then I must do "import t1" If I set a __path__ in t2.py, then I have to do "from . import t1" "There should be one-- and preferably only one --obvious way to do it.", but I

[issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5

Big Stone added the comment: or just I add a blank line in current python._pth and all is ok immediately ? -- ___ Python tracker ___

[issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5

Big Stone added the comment: Hi Steve, Could there be a "" (or "@source" or whatever string) convention be added in python._pth to explicitely allow that "formerly default" situation ? It would not break anything backward, and allow again classic Python-3.5 code to work unchanged in all

[issue28787] Out of tree --with--dtrace builds fail with a traceback

Changes by Charalampos Stratakis : -- pull_requests: +97 ___ Python tracker ___ ___

[issue29573] NamedTemporaryFile with delete=True should not fail if file already deleted

Andrew Nester added the comment: I've just added PR fixing this issue. -- nosy: +andrewnester ___ Python tracker ___

[issue29573] NamedTemporaryFile with delete=True should not fail if file already deleted

Changes by Andrew Nester : -- pull_requests: +96 ___ Python tracker ___ ___

[issue29523] latest setuptools breaks virtualenvs due to unbundling dependencies

Changes by Charalampos Stratakis : -- pull_requests: +95 ___ Python tracker ___ ___

[issue29533] urllib2 works slowly with proxy on windows

Eryk Sun added the comment: gethostbyname_ex won't do a reverse lookup on an IP to get the fully-qualified domain name, which seems pointless for a function named getfqdn. I think calling gethostbyaddr is intentional here and goes back to the Python 1.x days. Also, FYI, socket_gethostbyaddr

[issue29533] urllib2 works slowly with proxy on windows

Steve Dower added the comment: There's a few reasons why you haven't heard a reply. First among them is that we're all volunteers with limited free time, and second is that we just migrated to github and all that free time is being consumed right now. Python 2.7 is only receiving security

[issue29324] test_aead_aes_gcm fails on Kernel 4.9

STINNER Victor added the comment: Even when the fix will be backported to Python 3.6, please keep the issue open until Christian Heimes has time to review the kernel changes. Copy/paste of his message on the PR#133: "I still haven't had time to study the changes in the Linux kernel. Let's

[issue29579] Windows Python 3.7 installer broken by README.txt renamed to README.rst

STINNER Victor added the comment: Another option (don't know if it's a good idea or not) is to not include any README file in the installer. Is it really worth it? Why not pointing to docs.python.org/3.7/ for example? Or suggest to install the "Windows help file" package? I just checked on my

[issue29553] Argparser does not display closing parentheses in nested mutex groups

Brian Curtin added the comment: PR 120 looks fine to me, but Steven Bethard is the maintainer of argparse so he's better suited to say for sure if exclusive groups are ok how they are in 120 or if 117 is actually the way forward. -- assignee: -> bethard

[issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5

Steve Dower added the comment: The ._pth file is certainly not meant to cover beginner scenarios. But with that list of paths you should get almost exactly the same sys.path by default. Modifying a module's __path__ will only affect that module (and imports via that module), whereas sys.path

[issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5

Paul Moore added the comment: No more so than any other method of adding entries to sys.path (which is what __path__ does for packages, I've just never seen it used for modules). -- ___ Python tracker

[issue29579] Windows Python 3.7 installer broken by README.txt renamed to README.rst

Steve Dower added the comment: I'm okay with including a html readme in the installer, but it has to be fully self-contained with no separate images or style sheets, and can't have any dependencies on reaching the network (until the user clicks a link, obviously). My concern with just

[issue29553] Argparser does not display closing parentheses in nested mutex groups

Andrew Nester added the comment: any updates on this? -- ___ Python tracker ___ ___ Python-bugs-list mailing

[issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5

Big Stone added the comment: Using sys.path.append could result in an arbitrary long sys.path, full of duplicates, isn't it ? -- ___ Python tracker ___

[issue29324] test_aead_aes_gcm fails on Kernel 4.9

Changes by jan matejek : -- pull_requests: +94 ___ Python tracker ___ ___ Python-bugs-list

[issue29577] Enum: mixin classes don't mix well with already mixed Enums

Ethan Furman added the comment: Possibilities: - only allow one base Enum class (fails with All and IntFlag) - only allow base Enum classes that are compatible (so not an Enum and a Flag) (would require multiple base classes for the same behavior: DocEnum, DocFlag, etc.) - only allow

[issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5

Paul Moore added the comment: I'm not sure about this, I've never seen __path__ used like this. Why can't you just set sys.path? sys.path.append(os.path.dirname(os.path.abspath(__file__))) That's how scripts typically adjust their search path if needed. --

[issue29571] test_re is failing when local is set for `en_IN`

Serhiy Storchaka added the comment: > Seriously? Not a GitHub pull request? ;-) (old habit?) I'm not experienced with git, and devguide still looks not ready. -- ___ Python tracker

[issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5

Big Stone added the comment: ok, I found this as a possible workaound. I hope it's correct on t2.py, specify the __path__ variable before importing t1. import os __path__=[os.path.dirname(os.path.abspath(__file__))] from . import t1 print("t2 done") --

[issue29577] Enum: mixin classes don't mix well with already mixed Enums

Ethan Furman added the comment: While only IntColor fails with an error, Color also fails as it is not a Flag type Enum: >>> list(Color) [, , ] It should have values of 1, 2, 4. -- ___ Python tracker

[issue20210] Provide configure options to enable/disable Python modules and extensions

Xavier de Gaye added the comment: The PR https://github.com/python/cpython/pull/132 implements the support of the *disabled* marker in a Setup file as suggested by Martin. -- versions: +Python 3.7 -Python 3.5 ___ Python tracker

[issue20210] Provide configure options to enable/disable Python modules and extensions

Changes by Xavier de Gaye : -- pull_requests: +92 ___ Python tracker ___ ___

[issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5

Big Stone added the comment: and I fail to understand why IDLE doesn't feel the problem. -- ___ Python tracker ___

[issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5

Big Stone added the comment: The "targeted" user, a beginner in Python, will put its t1.py & t2.py examples anywhere on his disk, and discover that it doesn't work like in the book. It is very annoying for WinPython intended purpose, if a simple trick cannot provide the beginner "expected"

[issue29026] time.time() documentation should mention UTC timezone

Changes by Eric Appelt : -- pull_requests: +91 ___ Python tracker ___ ___

[issue29026] time.time() documentation should mention UTC timezone

STINNER Victor added the comment: New changeset 23557d59b819f57800ddef0b1373acef8e024670 by Victor Stinner in branch 'master': bpo-29026: Clarify documentation of time.time (#34) https://github.com/python/cpython/commit/23557d59b819f57800ddef0b1373acef8e024670 --

[issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5

Paul Moore added the comment: No (see the doc link I referenced) - paths are absolute, or relative to the _pth file. So "." means "in the same place as the pth file". I don't think there's a way with _pth files to get the "add the location of the executed script to the front of sys.path"

[issue29579] Windows Python 3.7 installer broken by README.txt renamed to README.rst

STINNER Victor added the comment: I proposed to convert README.rst to HTML and provide the HTML file in the Windows installer. -- ___ Python tracker ___

[issue29579] Windows Python 3.7 installer broken by README.txt renamed to README.rst

New submission from STINNER Victor: Copy of https://github.com/python/cpython/pull/104#issuecomment-280174576 --- The Windows installer build picks up this readme file and distributes it as readme.txt (see Tools/msi/exe/exe_files.wxs, which now needs fixing). I vote we should keep both so that

[issue29521] Minor warning messages when compiling documentation

STINNER Victor added the comment: New changeset 5e04dfecec478db13031fa507d6b2e21adbce035 by GitHub in branch '3.5': Backport35 doc fixes: PR#68 and PR#124 (#125) (#126) https://github.com/python/cpython/commit/5e04dfecec478db13031fa507d6b2e21adbce035 --

[issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5

Big Stone added the comment: doesn't the "." entry means "look at same place as current source file" ? Could there be a way to get that "classic" behavior on Python-3.6 ? -- ___ Python tracker

[issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5

Paul Moore added the comment: This sounds like a bug in winpython, not in Python itself. You need the location of t1.py in your _pth file. See https://docs.python.org/3.6/using/windows.html#finding-modules for details. Python 3.5 didn't use the _pth file mechanism, which is why the behaviour

[issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5

Changes by Big Stone : -- title: "python.exe t2.py" doesn't work the same on Pythn-3.6 as Python-3.5 -> "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5 ___ Python tracker

[issue29578] "python.exe t2.py" doesn't work the same on Pythn-3.6 as Python-3.5

New submission from Big Stone: Hi, I have two file "t1.py" and "t2.py" in the same directory. "t2.py" can't import "t1.py" when launched from python.exe on Python-3.6. it was ok on Python-3.5 (all other things being equal). And it's ok when launched from IDLE. Has there been a volontary

[issue29574] python-3.6.0.tgz permissions borked

Marc-Andre Lemburg added the comment: Indeed, there are two issue with the .tgz file: * it uses "staff" as group for all files (which will likely exist on some systems), but this appears unrelated in you case * all subdirs have go-x set, which prevents changing into the dir if you're not in