[issue37796] ModuleFinder does not resolve ".." correctly

[Michael Kleehammer]

New submission from Michael Kleehammer :

The modulefinder module does not handle relative directories properly.  The 
error I found is when one subpackage attempts to import from a sibling 
subpackage using the form

from ..language import (
DirectiveDefinitionNode,
...
)

In this example, it would report "language.DirectiveDefinitionNode" is missing.

It correctly resolves the names when importing modules, but when an import 
fails because it is a variable or function, it records the name incorrectly and 
cannot filter it out later.

I've attached a small test case and there is a README describing the test and 
results.

--
components: Library (Lib)
files: test.tar.gz
messages: 349268
nosy: mkleehammer
priority: normal
severity: normal
status: open
title: ModuleFinder does not resolve ".." correctly
type: behavior
versions: Python 3.7, Python 3.8
Added file: https://bugs.python.org/file48535/test.tar.gz

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

[issue34202] 3.6 ZipFile fails with Path

[Michael Kleehammer]

New submission from Michael Kleehammer :

ZipFile is documented to accept "path-like" objects but is failing when I try 
to create one.  I've distilled it down to this small test:

import zipfile
from pathlib import Path

path = Path('test.zip')
zf = zipfile.ZipFile(path, 'w')
zf.writestr('test.txt', 'Hello, Sailor!')
zf.close()

On macOS I'm getting this error:

Traceback (most recent call last):
  File "test.py", line 7, in 
zf.writestr('test.txt', 'Hello, Sailor!')
  File 
"/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/zipfile.py", 
line 1644, in writestr
with self.open(zinfo, mode='w') as dest:
  File 
"/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/zipfile.py", 
line 1348, in open
return self._open_to_write(zinfo, force_zip64=force_zip64)
  File 
"/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/zipfile.py", 
line 1461, in _open_to_write
self.fp.write(zinfo.FileHeader(zip64))
  File 
"/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/zipfile.py", 
line 721, in write
n = self.fp.write(data)
AttributeError: 'PosixPath' object has no attribute 'write'

Using str(path) works fine.

--
components: Library (Lib)
messages: 322272
nosy: mkleehammer
priority: normal
severity: normal
status: open
title: 3.6 ZipFile fails with Path
type: behavior
versions: Python 3.6

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

[issue29236] 'an ASCII string of one or more PEM-encoded certificates' needs to be unicode

[Michael Kleehammer]

Changes by Michael Kleehammer <mich...@kleehammer.com>:


--
nosy: +mkleehammer

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29236>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18458] libedit history offset workaround

[Michael Kleehammer]

Michael Kleehammer added the comment:

Just wanted to chime in that I reported this to Apple and their response was 
exactly this.  (Perhaps Ronald works for Apple?)

Is there a temporary work around in the meantime other than rebuilding 
everything?

--
nosy: +mkleehammer

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18458
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9889] PyUnicode_FormatV and Py_UNICODE*?

[Michael Kleehammer]

New submission from Michael Kleehammer mich...@kleehammer.com:

Using Py_UNICODE* in Python 3 C extensions is significantly more cumbersome 
than using char* was in Python 2.x.  One addition that could help would be a 
Py_UNICODE* format type for PyUnicode_FormatV.

Many printf libraries us %S for wchar_t which would have been nicely analogous, 
but that is already taken for str(obj).

--
components: Extension Modules, Interpreter Core
messages: 116714
nosy: mkleehammer
priority: normal
severity: normal
status: open
title: PyUnicode_FormatV and Py_UNICODE*?
type: feature request
versions: Python 3.1, Python 3.2, Python 3.3

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9889
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com