[issue5053] http.client.HTTPMessage.getallmatchingheaders() always returns []

[Glenn Linderman]

Glenn Linderman added the comment:

It is certainly true that getallmatchingheaders is broken... because the data 
it is looking at has changed format.

Here is a replacement that is as compatible as can be, based on the changed 
format.

name = name.lower()
n = len(name)
lst = []
for line, data in self.items():
if line.lower() == name:
lst.append(line + ': ' + data)
return lst

The changed format has merged continuation lines, and separated keys and values 
into a list of duplet tuples. Iterators keys, values, and items exist, keys are 
not necessarily unique.

--
nosy: +v+python

___
Python tracker 

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

[issue29844] Windows Python installers not installing DLL to System32/SysWOW64

[Paul "TBBle" Hampson]

Paul "TBBle" Hampson added the comment:

If this is just a documentation fix, then there's two places that need it:

* https://github.com/python/cpython/blob/master/Tools/msi/README.txt contains 
the text I quoted in the original report.

* Some kind of release note (https://docs.python.org/3/whatsnew/3.5.html) so 
that things that have relied on this behaviour in the past (e.g. gvim with the 
Python3/dynamic build option) can have all their documentation updated to tell 
people to... I don't know? Grab the embedded version into the gvim install 
directory? What _is_ the recommended approach here, to give 
system-wide-installed applications access to a system-wide-installed Python 
environment?

==

I don't agree that this change is correct. It's inconsistent with the Linux 
experience of an all-users installation (i.e. anything on the system can link 
against libpython2.7.so and get the expected behaviour of using the 
system-installed Python) and I would also consider an All-Users install to *be* 
a system component, since the intent is clearly to make it available to all 
users and applications without further effort.

Unlike putting python.exe in the path, the DLLs are version-named, so you don't 
suffer the conflict of *which Python* you get. The Python Launcher for Windows 
has taken care of that nicely, and if I have to add all the Python install 
directories to my path to ensure the DLLs are visible to applications that link 
against them, that seems to be a regression in the behaviour that launcher was 
trying to fix.

An issue I see with the embedded installation approach is that if I want to 
make modules available to something like gvim's Python environment, then I need 
to maintain those modules distinctly from the modules I maintain on the system 
level. It also means I need to be modifying gvim's install directory to add 
that embedded distribution, and that leaves a whole bunch of manual tracking of 
installed things I need to worry about.

I have the same concerns (manual tracking of things) if I have to add extra 
infrastructure to manage a copy of python3.X.dll in System32. Searching Google 
for this issue suggests that many people are just grabbing a random DLL off the 
internet named python3.5.dll and putting it in System32 when they encounter 
this problem, because "it used to work with Python 3.2".

Alternatively... Does it make sense to have a "System Component" installer 
version of Python for use by other applications that want to offer (optional) 
Python interpreter support? It would be pretty-much identical to the installer 
we have now, except putting the DLL entry point (python3.x.dll) into the system 
path, but not having python.exe in the path to confuse command-line usage.

--

___
Python tracker 

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

[issue29850] file access, other drives

[Eryk Sun]

Eryk Sun added the comment:

When you say "to be precise...C:/Windows/...System32", do you mean that this is 
the only directory that you've tested? If so, what you're seeing may be WOW64 
file-system redirection, if your 2.7 installation is 64-bit and 3.6 
installation is 32-bit, or vice versa. 

In a WOW64 process, accessing the %SystemRoot%\System32 directory in most cases 
gets redirected to the 32-bit system directory, %SystemRoot%\SysWOW64. You can 
access the native system directory via %SystemRoot%\SysNative.

--
nosy: +eryksun

___
Python tracker 

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

[issue29849] fix memory leak in import_from

[Xiang Zhang]

Changes by Xiang Zhang :


--
title: fix memory in import_from -> fix memory leak in import_from

___
Python tracker 

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

[issue29700] readline memory corruption when sys.stdin fd >= FD_SETSIZE for select()

[Martin Panter]

Martin Panter added the comment:

Marien’s pull request is for 2.7 and adds two new paths when raw_input is 
called:

* On Linux (actually glibc), use “poll” rather than “select”
* In other cases, if sys.stdin cannot be used with “select”, raise ValueError

Marien admits that even in the best case, some versions of the Readline library 
still crash because they use “select” themselves. Marien: can you identify 
which versions? Gnu Readline, or the wrapper in Editline? New versions vs 
superseded versions?

Assuming we add some catch-all behaviour like the ValueError, any further parts 
like the Linux “poll” implementation seem like new features, and are only 
appropriate for the next version of Python (3.7 atm). But it seems the bug 
would be hard to trigger in Python 3, so I doubt the Linux-specific 
implementation is worthwhile.

IMO the simplest solution may be to use one of the existing fallbacks if 
“select” is not usable. Either the other readline_until_enter_or_signal 
implementation (which hooks SIGINT rather than using the callback API), or 
PyOS_StdioReadline, or the raw_input fallback for non-interactive mode.

I would only bother with the complication of “poll” if there is a strong 
use-case. Gregory: do you really care if the “readline” module is used, or 
would a fallback like PyOS_StdioReadline be fine in your case (which is used if 
you never import the “readline” module)?

--

___
Python tracker 

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

[issue29833] Avoid raising OverflowError if possible

[Raymond Hettinger]

Raymond Hettinger added the comment:

> I don't expect that any code rely on OverflowError. 
> ...
> As MemoryError, it's not common to catch these exceptions.

So why bother making any changes here at all?  It seems like an invented 
problem resulting in unnecessary churn, creating more work for downstream 
implementations and test suites.  It isn't even clear that Python will be any 
better after the change.

One thing I'm strongly against is changing the published C API for things like 
PyLong_AsUnsignedLong, 
https://docs.python.org/3/c-api/long.html#c.PyLong_AsUnsignedLong .  Also, in 
the content of converting to and from fixed-width C type, an OverflowError 
seems like exactly the right error.

--

___
Python tracker 

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

[issue29851] importlib.reload references None object

[Richard Cooper]

New submission from Richard Cooper:

importlib.reload doesn't work; gives an error about NoneType having no name 
attribute.

See attached a simple repo testcase

When run it yields the following [disappointing] result.  I'm running 
Python3.0.6.1 (installed from brew) on OSX 10.12.3

```
iMac:python_package_loader cooper$ python3 bug.py 
module loaded
Traceback (most recent call last):
  File "bug.py", line 14, in 
importlib.reload(sys.modules[moduleName])
  File 
"/usr/local/Cellar/python3/3.6.0_1/Frameworks/Python.framework/Versions/3.6/lib/python3.6/importlib/__init__.py",
 line 166, in reload
_bootstrap._exec(spec, module)
  File "", line 589, in _exec
AttributeError: 'NoneType' object has no attribute 'name'
```

--
components: Library (Lib)
files: bug.py
messages: 289834
nosy: Richard Cooper
priority: normal
severity: normal
status: open
title: importlib.reload references None object
type: crash
Added file: http://bugs.python.org/file46737/bug.py

___
Python tracker 

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

[issue15988] Inconsistency in overflow error messages of integer argument

[Oren Milman]

Oren Milman added the comment:

Here is a patch including only changes related to formats using
the 'c' specifier.

(I ran the test module, and on my Windows 10, the same tests failed with
and without my patches. However, on my Ubuntu 16.04 VM, none of the tests
failed.)

--
Added file: http://bugs.python.org/file46736/formats_patchVer1.diff

___
Python tracker 

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

[issue29850] file access, other drives

[Paul Moore]

Paul Moore added the comment:

Please provide a script reproducing this issue, and precise details of your 
Python version. It's extremely unlikely that the problem is as broad as you 
describe, as otherwise we'd have lots of reports of issues. But we'll need a 
more specific description to pinpoint the actual problem here.

--

___
Python tracker 

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

[issue29850] file access, other drives

[Gabriel POTTER]

New submission from Gabriel POTTER:

If python 3 is installed on another drive (for instance D:/), then it cannot 
access any C:/ files, but can access D:/ files.

I use:
open("C:/path/")
The same function did work under python 2.7 but now doesn't anymore.

That means that os.path.isfile, open(file) do not work.

Any help ?

--
components: Windows
messages: 289830
nosy: Gabriel POTTER, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: file access, other drives
type: behavior
versions: Python 3.6

___
Python tracker 

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

[issue29850] file access, other drives

[Gabriel POTTER]

Gabriel POTTER added the comment:

To be precise, i cannot detect (only know if the file exist) any file located in
C:/Windows/... (in particulary System32)

contrary to Python 2.7 where it was possible.

--

___
Python tracker 

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

[issue29843] errors raised by ctypes.Array for invalid _length_ attribute

[Oren Milman]

Oren Milman added the comment:

here is the patch updated according to your suggestions, Serhiy.


however, I wonder about the case of a too large _length_.
shouldn't we raise a MemoryError in such a case, in accordance with #29833?

BTW, while inspecting code related to a too large _length_, I came across this
(in PyCArrayType_new):
if (length * itemsize < 0) {
PyErr_SetString(PyExc_OverflowError,
"array too large");
goto error;
}
I am not sure, but isn't this check unsafe? (e.g. if length == 2 ** 30, and
itemsize == 4, couldn't the product be 0 on some platforms?)
but maybe the code before this check makes more checks. I didn't make a
thorough inspection...

--
Added file: http://bugs.python.org/file46735/patchDraft2.diff

___
Python tracker 

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

[issue29848] Cannot use Decorators of the same class that requires an instance of itself to change variables in that class.

[R. David Murray]

R. David Murray added the comment:

Decorators are called with the decorated *function* objection when the class is 
compiled.  There can be no instance involved by their very nature, since the 
instance doesn't exist yet.  So no, you can't have a decorator that affects 
instance attributes at the compile step.  You *can* have a decorator that 
*effectively* manipulates instance attributes by returning a wrapper function, 
which will receive self when called, and can do whatever it wants.

There is no bug here, nor any need for a feature.  You can already do what you 
want, you just have to write your decorator correctly.  You can even have it as 
a static method of the class, though I'm not sure I'd consider that good style 
(but people's opinions on style differ).

--
nosy: +r.david.murray
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue29846] ImportError: Symbol not found: __PyCodecInfo_GetIncrementalDecoder when building 2.7.x on macOS

[Adam Stewart]

Adam Stewart added the comment:

> I'm certainly not going to try to deeply analyze a build that inserts *that* 
> many separate -I and -L options into the compiler calls

I believe those were necessary to get the build working. Spack doesn't install 
anything into /usr/, and without those flags, Python doesn't know where to 
search for its dependencies. I tried removing them anyway but it didn't help.

> My guess is that you will find that the problem goes away if you avoid the 
> use of '--enable-shared' on the Python configure

Just tried this and it does indeed go away! I can try convincing the other 
developers that this is the best option.

> most Python distributions on macOS use --enable-framework rather than 
> --enable-shared and we seldom test it.

I just tried using using `--enable-framework` and `make install` failed. Seeing 
lots of `ImportError: No module named site` errors.

> You should also check that there are no third-party Python 2.7's on PATH 
> and/or Python 2.7 shared libraries on the dyld library search paths, other 
> than the Apple-supplied pythons in /usr/bin.

This could very well be the cause of the problem. I happen to have both Python 
2 and 3 installed with both Homebrew and Anaconda, and all 4 are in my PATH. I 
don't have any PYTHON or LD/DYLD related env vars though. If you think it's 
worth testing, I can try removing everything from my PATH except /usr/bin:/bin

--

___
Python tracker 

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

[issue29833] Avoid raising OverflowError if possible

[STINNER Victor]

STINNER Victor added the comment:

I don't expect that any code rely on OverflowError. I don't remember any
code catching explicitly this exception.

As MemoryError, it's not common to catch these exceptions.

I expect that Python abstract the hardware if the cost on performance is
acceptable.

--

___
Python tracker 

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

[issue29546] A more helpful ImportError message

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
pull_requests:  -615

___
Python tracker 

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

[issue29849] fix memory in import_from

[Xiang Zhang]

Changes by Xiang Zhang :


--
pull_requests: +632

___
Python tracker 

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

[issue29849] fix memory in import_from

[Xiang Zhang]

New submission from Xiang Zhang:

import_from suffer from memory leak since #29546. Propose a PR to fix it. :-)

--
messages: 289825
nosy: barry, brett.cannon, mbussonn, xiang.zhang
priority: normal
severity: normal
stage: patch review
status: open
title: fix memory in import_from
versions: Python 3.7

___
Python tracker 

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

[issue29830] pyexpat.errors doesn't have __spec__ and __loader__ set

[Brett Cannon]

Brett Cannon added the comment:

ExtensionFileLoader.is_package() is accurate because it's not typical for an 
extension module to inject its own submodules like pyexpat is. Usually people 
who use an extension module in a package use it just for a submodule and not 
even as an __init__.

IOW there's a long history of built-ins and extensions not being in packages 
that people bump up against that no one has taken the time to try and 
straighten out due to it not being an issue on a regular basis.

--

___
Python tracker 

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

[issue29822] inspect.isabstract does not work on abstract base classes during __init_subclass__

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

LGTM, but would be nice if Yury and Nick take a look.

--

___
Python tracker 

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

[issue29846] ImportError: Symbol not found: __PyCodecInfo_GetIncrementalDecoder when building 2.7.x on macOS

[Ned Deily]

Changes by Ned Deily :


--
title: ImportError: No module named _io -> ImportError: Symbol not found: 
__PyCodecInfo_GetIncrementalDecoder when building 2.7.x on macOS

___
Python tracker 

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

[issue29846] ImportError: No module named _io

[Ned Deily]

Ned Deily added the comment:

I'm not familiar with Spack and I'm certainly not going to try to deeply 
analyze a build that inserts *that* many separate -I and -L options into the 
compiler calls :)  But there have been a number of reports of problems with 
this symptom in the past (try searching the web) and at least one previous 
issue opened here (Issue26498).  The root cause in all of these is that at some 
point there is a mismatch between a python executable of one 2.7.x version 
being dynamically linked at run time with python shared libraries of a 
different 2.7.x version.  While a python build should guard against this 
happening, often it doesn't matter when such a mismatch occurs.  However, there 
was an incompatibility introduced in the lifetime of 2.7.x involving 
__PyCodecInfo_GetIncrementalDecoder (I forget the details).  My guess is that 
you will find that the problem goes away if you avoid the use of 
'--enable-shared' on the Python configure; most Python distributions on macOS 
use --enable-framework rathe
 r than --enable-shared and we seldom test it.  Or use neither.  You should 
also check that there are no third-party Python 2.7's on PATH and/or Python 2.7 
shared libraries on the dyld library search paths, other than the 
Apple-supplied pythons in /usr/bin.  It would be nice to finally figure out and 
resolve where the hole is but I've never been able to reproduce the failure 
myself.

--
nosy: +ned.deily

___
Python tracker 

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

[issue29833] Avoid raising OverflowError if possible

[Guido van Rossum]

Guido van Rossum added the comment:

If I had to do it over again I would have used OverflowError only for some very 
narrowly defined conditions and ValueError for "logical" range limitations. In 
particular OverflowError suggests that the abstraction is slightly broken 
(since we usually don't think much about how large an integer fits in a 
register) while ValueError suggests that the caller passed something of the 
right type but with an inappropriate value.

I'm not too worried about breaking APIs in this case (but that could change if 
someone finds data showing there are common idioms in actual use that would 
break).

--

___
Python tracker 

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

[issue29694] race condition in pathlib mkdir with flags parents=True

[Berker Peksag]

Changes by Berker Peksag :


--
components: +Library (Lib)
nosy: +berker.peksag
stage:  -> patch review

___
Python tracker 

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

[issue29848] Cannot use Decorators of the same class that requires an instance of itself to change variables in that class.

[Decorater]

Decorater added the comment:

hmm, I see. Well I was looking for an way to actually be able to use decorators 
made in the same class to be able to somehow pass in the same instance as well. 
Currently the only way to use class decorators is for them to be static (which 
would not allow using or changing variables to the class (or functions in other 
classes bound to self). So, yeah there is got to be a way to do this, to use an 
decorator that takes in the same instance of a class.

On the other hand they get realize there is a certain way to use classes, 
decorators, and instances.

--

___
Python tracker 

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

[issue29848] Cannot use Decorators of the same class that requires an instance of itself to change variables in that class.

[Steven D'Aprano]

Steven D'Aprano added the comment:

Its not clear what you are asking for here. Do you think the current behaviour 
is a bug? Are you asking for a new feature? What do you want?

When the decorator is called, "self" doesn't exist, so of course 
@self.decorator *must* fail. What else could it do? Which instance should 
Python use, if there is no instance that exists yet?

You say "many people rely on Decorators in class that accepts an instance of 
itself", but I doubt that. I've never wanted code like that, and the example 
you show wouldn't work even if "self" existed. Can you give a better example?

Personally, I think this is a good learning experience for programmers, not 
something that needs to be fixed. Anyone who tries to decorate a method in a 
class by calling self.method is confused about classes, instances and 
decorators, and this is a good lesson for them to learn.

--
nosy: +steven.daprano

___
Python tracker 

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

[issue29848] Cannot use Decorators of the same class that requires an instance of itself to change variables in that class.

[Decorater]

New submission from Decorater:

So, many people rely on Decorators in class that accepts an instance of itself 
like so:

class ExampleClass:
"""Example class with an example decorator that cannot be used."""

def __init__(self):
self.list_of_items = []

def add_item(self, item):
self.list_of_items.append(item)

@self.add_item("test_item")
def test_item():
print("Example function of ExampleClass that demonstrates the inability 
to use decorators with self passed to it.")

Many people fall for this on classes and then they are like "Why is it not 
letting me do this?". As such there is got to be a way to somehow support 
something like this in Python 3.7 as it could be useful on classes like this. 
The class above is an example, however I know of an library out there that 
allows you to import from a file and also allows you to use the same thing 
(that is imported) that would be bound to "self.[whatever it is called in the 
class]". As such people try to avoid that import and use the one in 
"self.[whatever it is called in the class]" to try to fit their needs (which 
ends up failing for them).

--
messages: 289818
nosy: Decorater
priority: normal
severity: normal
status: open
title: Cannot use Decorators of the same class that requires an instance of 
itself to change variables in that class.
versions: Python 3.7

___
Python tracker 

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

[issue29847] Path takes and ignores **kwargs

[Jelle Zijlstra]

New submission from Jelle Zijlstra:

pathlib.Path.__new__ takes **kwargs, but doesn't do anything with them 
(https://github.com/python/cpython/blob/master/Lib/pathlib.py#L979). This 
doesn't appear to be documented.

This feature should presumably be either documented or removed (probably 
removed unless I'm missing some reason for having it).

Brief discussion on a typeshed PR at 
https://github.com/python/typeshed/pull/991#discussion-diff-105813974R100

--
messages: 289817
nosy: Jelle Zijlstra, pitrou
priority: normal
severity: normal
status: open
title: Path takes and ignores **kwargs

___
Python tracker 

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

[issue29844] Windows Python installers not installing DLL to System32/SysWOW64

[Steve Dower]

Steve Dower added the comment:

I don't even think there's documentation to fix, the install page should say 
where things are installed.

The system directory is for the system to install files - the Python installer 
is not a system component, it's a developer kit. For most cases, the install 
directory was "fixed" rather than broken.

If you have particular needs to install a system-wide python3x.dll, I'd suggest 
crafting your own install script from the files in a normal install (though 
putting the install directory on PATH should also enable dependency resolution 
for most processes).

--

___
Python tracker 

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

[issue29846] ImportError: No module named _io

[Adam Stewart]

New submission from Adam Stewart:

I'm trying to build Python 2.7.13 with clang on macOS 10.12.3 with the Spack 
package manager, but it fails to build the _io module. The exact error message 
from the build log can be seen here:

https://github.com/LLNL/spack/issues/3478#issuecomment-287548431

This only seems to occur for me on macOS; I can't reproduce it on Linux. I 
checked my environment, but I don't have any Python-related environment 
variables, nor do I have any variables like DYLD_LIBRARY_PATH set that could 
cause problems. I'm a developer for the Spack package manager, so any problems 
that you help me solve will greatly benefit our community.

I have attached the build log. Please let me know if there is any more 
information I can provide you with.

--
components: Build
files: spack-build.out
messages: 289815
nosy: ajstewart
priority: normal
severity: normal
status: open
title: ImportError: No module named _io
type: compile error
versions: Python 2.7
Added file: http://bugs.python.org/file46734/spack-build.out

___
Python tracker 

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

[issue15988] Inconsistency in overflow error messages of integer argument

[Oren Milman]

Oren Milman added the comment:

Here is a patch including only changes related to PyLong_As* and PyArg_Parse*
functions.

(I ran the test module, and on my Windows 10, the same tests failed with
and without my patches. However, on my Ubuntu 16.04 VM, none of the tests
failed.)

--
Added file: 
http://bugs.python.org/file46733/PyLong_As_and_PyArg_Parse_patchVer1.diff

___
Python tracker 

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

[issue29822] inspect.isabstract does not work on abstract base classes during __init_subclass__

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
nosy: +ncoghlan

___
Python tracker 

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

[issue29843] errors raised by ctypes.Array for invalid _length_ attribute

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Opened issue29845 for _testcapi issues.

--

___
Python tracker 

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

[issue29845] Mark tests that use _testcapi as CPython-only

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
pull_requests: +631

___
Python tracker 

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

[issue29845] Mark tests that use _testcapi as CPython-only

[Serhiy Storchaka]

New submission from Serhiy Storchaka:

Most tests that use _testcapi are optional or marked as CPython-only. But there 
are few tests that aren't. Proposed patch fixes this.

--
components: Tests
messages: 289812
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Mark tests that use _testcapi as CPython-only
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7

___
Python tracker 

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

[issue24796] Deleting names referencing from enclosed and enclosing scopes

[Ivan Levkivskyi]

Ivan Levkivskyi added the comment:

It looks like it is safe to just remove this line from docs. This code

>>> x = 1
>>> def f():
... global x
... del x
... 
>>> f()
>>> x

Works as expected, i.e. raises NameError. (The same happens for nonlocal but 
with UnboundLocalError.)

--

___
Python tracker 

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

[issue21253] unittest assertSequenceEqual can lead to Difflib.compare() crashing on mostly different sequences

[Ivan Levkivskyi]

Changes by Ivan Levkivskyi :


--
versions: +Python 3.5, Python 3.6, Python 3.7

___
Python tracker 

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

[issue28980] ResourceWarning when imorting antigravity in 3.6

[Ivan Levkivskyi]

Ivan Levkivskyi added the comment:

It looks like this is fixed on master, but the problem still appears on 3.6

--

___
Python tracker 

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

[issue29734] nt._getfinalpathname handle leak

[Mark Becwar]

Changes by Mark Becwar :


--
pull_requests:  -628

___
Python tracker 

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

[issue29843] errors raised by ctypes.Array for invalid _length_ attribute

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I'm working on this. Right now I'm searching other tests that use _testcapi 
without guards.

--

___
Python tracker 

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

[issue29843] errors raised by ctypes.Array for invalid _length_ attribute

[Oren Milman]

Oren Milman added the comment:

yes, you are right, of course.


but regardless of this issue, shouldn't test_structures.py be changed
(in a seperate issue)?
ISTM it has a cpython-specific test not decorated in @cpython_only.

--

___
Python tracker 

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

[issue29844] Windows Python installers not installing DLL to System32/SysWOW64

[Eryk Sun]

Eryk Sun added the comment:

3.5+ doesn't install files to system directories -- except the py launcher in 
%SystemRoot%. This was an intentional change, so I'm flagging this as a 
documentation issue.

--
assignee:  -> docs@python
components: +Documentation, Windows
keywords: +easy
nosy: +docs@python, eryksun, paul.moore, steve.dower, tim.golden, zach.ware
stage:  -> needs patch
versions: +Python 3.7

___
Python tracker 

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

[issue29843] errors raised by ctypes.Array for invalid _length_ attribute

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I suggest just remove the test with LONG_MAX.

--

___
Python tracker 

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

[issue29843] errors raised by ctypes.Array for invalid _length_ attribute

[Oren Milman]

Oren Milman added the comment:

"If use _testcapi the tests should be decorated with cpython_only."

at first, I thought so too, but then I searched for 'cpython_only' in
Lib/ctypes/test, and found nothing. then I searched for '_testcapi' there,
and found a top level 'import _testcapi' in
Lib/ctypes/test/test_structures.py, and a test using _testcapi.INT_MAX.

so I assumed that test_ctypes itself is cpython_only.

should test_structures.py be changed, then?

--

___
Python tracker 

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

[issue29843] errors raised by ctypes.Array for invalid _length_ attribute

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

LGTM, but I prefer `overflow > 0` over `overflow == 1`.

If use _testcapi the tests should be decorated with cpython_only. But I think 
that it is better to not use it. Limiting _length_ to C long (rather than 
size_t) is an implementation detail. The test with _length_ = 1 << 1000 should 
be enough.

--
nosy: +amaury.forgeotdarc, belopolsky, meador.inge
stage:  -> patch review

___
Python tracker 

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

[issue29116] Make str and bytes error messages on concatenation conform with other sequences

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

PR 709 fixes the order of types for concatenating bytes and and bytearray. 
b''+0 will raise "can't concat str to bytes" rather than "can't concat bytes to 
str".

PR 710 makes error message for str concatenation more informative and similar 
to error messages for list, tuple, deque, array. '' + b'' will raise "can only 
concatenate str (not "bytes") to str" rather than "must be str, not bytes".

--

___
Python tracker 

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

[issue29116] Make str and bytes error messages on concatenation conform with other sequences

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
pull_requests: +630

___
Python tracker 

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

[issue29116] Make str and bytes error messages on concatenation conform with other sequences

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
pull_requests: +629

___
Python tracker 

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

[issue29843] errors raised by ctypes.Array for invalid _length_ attribute

[Oren Milman]

Oren Milman added the comment:

A patch draft (which doesn't change anything about the case of _length_ == 0)
is attached.
(I am not opening a PR, because I am not sure the behavior change would be
accepted.)

I ran the test module on my Windows 10, and it seems the patch doesn't break
anything.

--
keywords: +patch
Added file: http://bugs.python.org/file46732/patchDraft1.diff

___
Python tracker 

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

[issue29844] Windows Python installers not installing DLL to System32/SysWOW64

[Paul "TBBle" Hampson]

Changes by Paul "TBBle" Hampson :


--
components: +Installation
type:  -> behavior

___
Python tracker 

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

[issue29844] Windows Python installers not installing DLL to System32/SysWOW64

[Paul "TBBle" Hampson]

New submission from Paul "TBBle" Hampson:

As noted in https://github.com/python/cpython/tree/master/Tools/msi
===
When installed for all users, the following files are installed to
either "%SystemRoot%\System32" or "%SystemRoot%\SysWOW64" as
appropriate. For the current user, they are installed in the Python
install directory.

.\python3x.dll  The core interpreter
.\python3.dll   The stable ABI reference
===

However, at least with the Python 3.5.3 and Python 3.6.0 installers from the 
official download page, even an all-users install puts the relevant DLLs in the 
installation directory instead.

This is the both with the command-line option and checking the relevant box 
during installation.

I've also confirmed that it happens whether you add Python to the path or not. 
The latter is my use-case as I have multiple versions of Python installed and 
use the Python Launcher for Windows to select a version to run or virtualenv to 
build.

Looking at the source, I suspect this feature was completely lost when the MSI 
build system was rewritten in commit 
https://github.com/python/cpython/commit/bb24087a2cbfb186b540cc71a74ec8c39c1ebe3a
 (formerly https://hg.python.org/cpython/rev/e7dbef447157) for issue #23260 
which removed all references to SystemFolder or System64Folder

--
messages: 289801
nosy: TBBle
priority: normal
severity: normal
status: open
title: Windows Python installers not installing DLL to System32/SysWOW64
versions: Python 3.5, Python 3.6

___
Python tracker 

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

[issue29843] errors raised by ctypes.Array for invalid _length_ attribute

[Oren Milman]

New submission from Oren Milman:

With regard to ctypes.Array:

currently:
>>> from ctypes import *
>>> class T(Array):
... _type_ = c_int
... _length_ = -1
...
Traceback (most recent call last):
  File "", line 1, in 
OverflowError: array too large
>>> class T(Array):
... _type_ = c_int
... _length_ = -1 << 1000
...
Traceback (most recent call last):
  File "", line 1, in 
OverflowError: The '_length_' attribute is too large


Obviously, here the _length_ attribute is too small, not too large.
Thus, the error messages should be changed to be more accurate (optimally, for
any negative _length_, the error message should be the same).

Moreover, in accordance with #29833 (this is a sub-issue of #29833), ValueError
should be raised for any negative _length_ attribute (instead of
OverflowError).


Also, Note that currently, in case _length_ == 0, no error is raised. ISTM that
a ctypes Array of length 0 is useless, so maybe we should raise a ValueError in
this case too?

--
components: ctypes
messages: 289800
nosy: Oren Milman, serhiy.storchaka
priority: normal
severity: normal
status: open
title: errors raised by ctypes.Array for invalid _length_ attribute
type: behavior
versions: Python 3.7

___
Python tracker 

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

[issue15988] Inconsistency in overflow error messages of integer argument

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

it is hard to discuss such large patch on GitHub since diffs and comments to 
all files are shown on one page. Rietveld is more appropriate since it shows 
only one file at the time. I suggest you Oren to provide the next version of 
your patch as a patch for reviewing on Rietveld and make PRs only for ready 
patches.

Even after withdrawing some changes or extracting them as separate issues the 
patch can be too large. I suggest to commit first the part that relates to 
PyArg_Parse* ang PyLong_As*.

--

___
Python tracker 

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

[issue29834] Raise ValueError rather of OverflowError in PyLong_AsUnsignedLong()

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

_Py_Uid_Converter() in Modules/posixmodule.c is not an example because it calls 
PyLong_AsUnsignedLong() only for positive integers > LONG_MAX.

PyLong_AsUnsignedLong() is used not much. The motivation of this issue was that 
if use PyLong_AsUnsignedLong() for converting non-negative by its nature values 
ValueError can be more appropriate since this limitation is not platform or 
implementation dependent. Strictly speaking raising OverflowError for negative 
values doesn't fits the definition of an OverflowError, since the result is not 
large at all.

I was going to investigate all usages of PyLong_AsUnsignedLong() and if in 
majority of them ValueError is appropriate and desirable, changing the 
exception type at that level can make the implementation simpler.

--

___
Python tracker 

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

[issue29834] Raise ValueError rather of OverflowError in PyLong_AsUnsignedLong()

[Raymond Hettinger]

Raymond Hettinger added the comment:

Looking back in time, this API isn't as old as I thought.  The other concerns 
about breaking a published API still stand.

--
nosy:  -gvanrossum

___
Python tracker 

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

[issue29834] Raise ValueError rather of OverflowError in PyLong_AsUnsignedLong()

[Raymond Hettinger]

Raymond Hettinger added the comment:

Strong -1 on this.  For zero benefit, this breaks everything (within Python and 
third-party code) that ever relied on the documented behavior , 
https://docs.python.org/3/c-api/long.html#c.PyLong_AsUnsignedLong .

The cause perfectly fits the definition of an OverflowError:

class OverflowError(ArithmeticError)
 |  Result too large to be represented.

The time to challenge API design decisions is when they are created, not after 
they've been published and relied upon for over decade.

Also, we really don't everyone who writes cross-platform code and tests to have 
to catch both exceptions because they don't know which version is being run.  
This creates yet another barrier to upgrading Python and as far as I can tell 
isn't solving any reported user problem.  Instead, it is second-guessing design 
decisions made long ago.

--
nosy: +gvanrossum, rhettinger

___
Python tracker 

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

[issue29833] Avoid raising OverflowError if possible

[Raymond Hettinger]

Raymond Hettinger added the comment:

IIRC, there have been previous discussions about little inconsistencies between 
when objects raise an OverflowError versus MemoryError and IndexError, and 
ValueError.   I believe that Guido had opined that the choices were made 
somewhat arbitrarily (by different people at different times) but that it 
hadn't proved to be an actual problem in practice and that changing exception 
types after an API has already been released is more disruptive to users 
(potentially breaking existing, tested code) than living with the minor 
inconsistencies.

Guido, do you want these exceptions changed and do you agree with the Serhiy's 
new principles?   

My own thoughts are:
* As a starting point, it seems reasonable to want consistent errors across 
ranges of input values.  And being more predictable is a virtue as well.
* Changing existing APIs is disruptive, making it more difficult to maintain 
cross-version code, breaking existing code or tests that use the current 
exceptions, and creating unnecessary work for Jython, IronPython, and PyPy who 
would have to follow our myriad of little changes.
* Personally, I find OverflowError to be more self-explanatory of the cause of 
an exception than MemoryError which is more jarring and seemingly indicative of 
inadequate memory.
* Likewise, Overflow error is more precise and helpful than ValueError which is 
very generic, covering a wide variety of problems.
* A lot of third-party tools have evolved over time that mimic the behaviors of 
built-in types.  If we change those behaviors now, the ecosystem will likely 
never fully sync-up.

--
nosy: +gvanrossum

___
Python tracker 

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

[issue29822] inspect.isabstract does not work on abstract base classes during __init_subclass__

[Nate Soares]

Nate Soares added the comment:

I didn't know about issue29638, and I'm not sure whether my PR fixes it. 
Looking at that bug, I don't think that my PR would fix it, because I still 
trust TPFLAGS_IS_ABSTRACT when __abstractmethods__ exists. That said, I'm not 
clear on how the cache works, so it's possible that my PR would fix 29638.

My issue appears when one uses py3.6's new __init_subclass__ hook with an ABC. 
__init_subclass__ is run by type.__new__, which means that, as of py3.6, users 
can (in a natural/reasonable way) inspect ABCMeta classes before 
ABCMeta.__new__ finishes executing. I didn't see any reasonable way to have 
ABCMeta.__new__ finish setting up the ABC before calling super().__new__, so I 
figured the fix should go into inspect.isabstract. But there may be better 
solutions I just didn't think of.

--

___
Python tracker 

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

[issue20087] Mismatch between glibc and X11 locale.alias

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
pull_requests:  -602

___
Python tracker 

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

[issue29572] Upgrade installers to OpenSSL 1.0.2k

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
pull_requests:  -579

___
Python tracker 

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

[issue29619] st_ino (unsigned long long) is casted to long long in posixmodule.c:_pystat_fromstructstat

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
pull_requests:  -599

___
Python tracker 

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

[issue28692] gettext: deprecate selecting plural form by fractional numbers

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
pull_requests:  -605

___
Python tracker 

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

[issue29139] operator.concat/iconcat could only work if left operand is a sequence

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
pull_requests:  -590

___
Python tracker 

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