[issue32134] Crash on OSX

[Jonas]

New submission from Jonas :

The Idle Editor or Idle Python Shell crashes if ` character is typed in. 
Character looks like an ` with underscore. 

How to repeat this problem:
1. In OSX open any .py file or the Idle Shell with Idle.
2. Switch to german keyboard layout
3. Type the letter by pressing shift and the  +=  button, left of the delete 
button. (Keyboard hardware layout is US)

I attached only the crash report of version 3.6.3. This issue happens also to 
all previous versions. I didn't checked with versions higher than 3.6.3.

Info from shell (not crashed yet):
Python 3.6.3 (v3.6.3:2c5fed86e0, Oct  3 2017, 00:32:08) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "copyright", "credits" or "license()" for more information.
>>>

--
assignee: terry.reedy
components: IDLE
files: Idle363_crash_report.txt
messages: 306971
nosy: jonasfi...@aol.com, terry.reedy
priority: normal
severity: normal
status: open
title: Crash on OSX
type: crash
versions: Python 3.6
Added file: https://bugs.python.org/file47297/Idle363_crash_report.txt

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

[issue32134] Crash on OSX

[Jonas]

Jonas  added the comment:

See screenshot from character:

without: ` and with underscore: `

(underscore is not shown as text in comment. See screen shot)

--
Added file: https://bugs.python.org/file47298/Screen Shot 2017-11-25 at 
19.45.50.png

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

[issue46047] When using Py_NewInterpreter, some modules fail to import in Python 3.10

[Jonas Witschel]

New submission from Jonas Witschel :

Consider the following minimal example C code which is trying to import 
jsonschema (https://python-jsonschema.readthedocs.io/en/stable/), compiled 
using "gcc test_newinterpreter.c -I /usr/include/python3.10 -lpython3.10 -o 
test_newinterpreter" or similar:

#include 

int main(void) {
Py_Initialize();
PyThreadState *interpreter = Py_NewInterpreter();
PyRun_SimpleString("import jsonschema");
Py_Finalize();  
}

In Python 3.9.9, this works as expected. However in Python 3.10.0, the 
following error is produced:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3.10/site-packages/jsonschema/__init__.py", line 21, in 

from jsonschema._types import TypeChecker
  File "/usr/lib/python3.10/site-packages/jsonschema/_types.py", line 168, in 

draft3_type_checker = TypeChecker(
TypeError: TypeChecker() takes no arguments

Removing the Py_NewInterpreter() call makes the example work as expected in 
Python 3.10.0.

This might be related to the enhancements to the type cache from bpo-42745.

Another recent bug report I found that might possibly be related is bpo-46036.

This bug breaks some WeeChat plugins that try to import one of the affected 
modules, e.g. weechat-matrix (https://github.com/poljar/weechat-matrix).

--
components: C API, Subinterpreters
messages: 408295
nosy: diabonas
priority: normal
severity: normal
status: open
title: When using Py_NewInterpreter, some modules fail to import in Python 3.10
type: compile error
versions: Python 3.10

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

[issue46047] When using Py_NewInterpreter, some modules fail to import in Python 3.10

[Jonas Witschel]

Jonas Witschel  added the comment:

Downstream bug report in Arch Linux: https://bugs.archlinux.org/task/72979

--

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

[issue46047] When using Py_NewInterpreter, some modules fail to import in Python 3.10

[Jonas Witschel]

Jonas Witschel  added the comment:

I notice this has already been reported as bpo-46006 and bpo-46034, so closing 
in favour of these.

--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed

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

[issue46006] [subinterpreter] _PyUnicode_EqualToASCIIId() issue with subinterpreters

[Jonas Witschel]

Change by Jonas Witschel :


--
nosy: +diabonas

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

[issue46067] SSLContext.set_npn_protocols broken in Python 3.10, tries to call non-existing _set_npn_protocols

[Jonas Witschel]

New submission from Jonas Witschel :

Consider the following minimal example:

import ssl
context = ssl.create_default_context()
context.set_npn_protocols(['http/1.1', 'spdy/2'])

In Python 3.10, it fails with the following error:

AttributeError: 'SSLContext' object has no attribute '_set_npn_protocols'. Did 
you mean: 'set_npn_protocols'?

This is because bpo-43669 
(https://github.com/python/cpython/commit/39258d3595300bc7b952854c915f63ae2d4b9c3e)
 removed _set_npn_protocols, while it is still used by 
SSLContext.set_npn_protocols: 
https://github.com/python/cpython/blob/191c431de7d9b23484dd16f67e62c6e85a1fac7f/Lib/ssl.py#L551

Note that the function is already deprecated in Python 3.10 and throws a

DeprecationWarning: ssl NPN is deprecated, use ALPN instead

but should still probably continue working for now.

--
assignee: christian.heimes
components: SSL
messages: 408466
nosy: christian.heimes, diabonas
priority: normal
severity: normal
status: open
title: SSLContext.set_npn_protocols broken in Python 3.10, tries to call 
non-existing _set_npn_protocols
type: compile error
versions: Python 3.10

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

[issue13351] Strange time complexity when creating nested lists

[Jonas LM]

New submission from Jonas LM :

Consider the following snippets:

def lists(n):
start_time = time.time()
lists = [None]*n
for i in xrange(n):
lists[i] = [None]*n
for j in xrange(n):
lists[i][j] = []
print time.time() - start_time

def simple_lists(n):
start_time = time.time()
lists = [None]*n
for i in xrange(n):
lists[i] = [None]*n
for j in xrange(n):
lists[i][j] = False
print time.time() - start_time

Both of these snippets seem like they should run in O(n^2), right?

Observe the following test runs:

>>> for i in [4000, 8000, 16000]: simple_lists(i)
2.11170578003
8.67467808723
34.0958559513
>>> for i in [1000, 2000, 4000]: lists(i)
1.13742399216
7.39806008339
78.0808939934

While simple_lists() seem to run roughly in O(n^2), it seems like lists() runs 
in upwards of O(n^3) or worse! Something funky is going on, and I have no idea 
what.

--
components: None
messages: 147126
nosy: quakes
priority: normal
severity: normal
status: open
title: Strange time complexity when creating nested lists
type: performance
versions: Python 2.6

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

[issue13351] Strange time complexity when creating nested lists

[Jonas LM]

Jonas LM  added the comment:

Confirmed that this was caused by the garbage collector, as pitrou suspected. 
Thanks!

--
resolution:  -> works for me
status: open -> closed

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

[issue11975] Fix referencing of built-in types (list, int, ...)

[Jonas H.]

Jonas H.  added the comment:

Does that look good to you? If it does, I'll go on using the script 
(http://paste.pocoo.org/show/396661/) on the 3.x docs.

--
keywords: +patch
Added file: http://bugs.python.org/file22164/p1.patch

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

[issue11975] Fix referencing of built-in types (list, int, ...)

[Jonas H.]

Jonas H.  added the comment:

Linking a class using a function directive is counter-intuitive. That's why we 
need to make use of class directives rather than function directives here.

--

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

[issue11975] Fix referencing of built-in types (list, int, ...)

[Jonas H.]

Jonas H.  added the comment:

I'm not.

My patch doesn't address the problem of unlinkable methods but wrong type 
declarations (read, wrong usage of ".. function::" directives) for builtins 
like int, float, bool, list etc. Because the directives change, the roles used 
to link to them (":func:`list`") have to be changed accordingly.  That's what 
this patch does.

I want to address `list` method documentation in the next step.

--

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

[issue11975] Fix referencing of built-in types (list, int, ...)

[Jonas H.]

Jonas H.  added the comment:

> Could you make an effort to accept our word that using :class: instead of 
> :func: would bring zero value to the indexing system nor to human readers?

I'm already doing; but I don't see anyone having made a good point against my 
preference of using ".. class::" to document classes.

--

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

[issue11975] Fix referencing of built-in types (list, int, ...)

[Jonas H.]

Jonas H.  added the comment:

What's wrong with the changes I propose with the patch, then? Sorry, I really 
don't get it, no matter how hard I try.

--

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

[issue11975] Fix referencing of built-in types (list, int, ...)

[Jonas H.]

Jonas H.  added the comment:

> when you mark up something with a mod, func, class or meth role, Sphinx will 
> find the target without paying attention to its type.  So changing :func: to 
> :class: does not bring anything.

>From a quick test this seems to hold true for links within one project but not 
>for Sphinx' intersphinx extension, which actually cares about types.

So the question is whether we keep CPython implementation details (many 
builtins being both a class and a function) out of the documentation or we get 
the Sphinx developers to change intersphinx behaviour.  I guess you'd suggest 
the latter, right? :-)

--

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

[issue11975] Fix referencing of built-in types (list, int, ...)

[Jonas H.]

Jonas H.  added the comment:

> So the intersphinx behavior is the "correct" one, but we can't change the 
> other now because of compatibility.

Could you be convinced to use that legacy behaviour for intersphinx, too? :-)

--

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

[issue11975] Fix referencing of built-in types (list, int, ...)

[Jonas H.]

Jonas H.  added the comment:

> Jonas, I owe you an apology [...]

Thanks Éric, I got a bit worried about getting on your nerves...

Based on Ezio's idea: What happens if we have both a ".. function:: foo" and 
".. class:: foo" -- where do :func:`foo` and :class:`foo` link to (internally 
and using intersphinx)?

--

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

[issue11975] Fix referencing of built-in types (list, int, ...)

[Jonas H.]

Jonas H.  added the comment:

Having one page with two objects of the same name, e.g.

  .. function:: foo

  .. class:: foo

renders to two entries with the same anchor name (#foo). The first entry gets a 
link-to-this-paragraph marker, the second one doesn't.

Internal references (from within the same document) always link to the first 
entry because they use #foo anchor. (So if you put the class directive first, 
all links go to the class anchor.)

The first external reference (using intersphinx) always goes to the first 
target document element - no matter which type both have. The second reference 
isn't turned into a hyperlink.

This behaviour seems consistent with how HTML anchors work.

Having the two objects on two different pages however shows slightly odd 
results. Say we have this code on page 1:

  .. class:: foo

  :class:`foo`
  :func:`foo`

and

  .. function:: foo

on page 2, then both links in page 1 go to the page 1 'foo' (the class). 
However if you change order (putting the func role before the class role), 
those links go to the page 2 'foo' (the function).

All intersphinx-ed links go to the object on page 1, no matter the role order 
on page 1 or the external page.


I think we can conclude that using class and function directives at the same 
time doesn't help very much...

--

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

[issue12284] argparse.ArgumentParser: usage example option

[Jonas H.]

New submission from Jonas H. :

I'd like to see an `examples` option added to argparse.ArgumentParser as found 
in many man pages.

This could also be done using the `epilog` option, but that misses the 
"%(proc)s" replacement which makes usage examples like this

  Example usage:
./script.py option1 option2

impossible.

--
components: Library (Lib)
messages: 137905
nosy: jonash
priority: normal
severity: normal
status: open
title: argparse.ArgumentParser: usage example option
type: feature request
versions: Python 2.7

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

[issue12284] argparse.ArgumentParser: usage example option

[Jonas H.]

Jonas H.  added the comment:

Nope. I want an "examples" section, for example from `man git log`:


EXAMPLES
   git log --no-merges
   Show the whole commit history, but skip any merges

   git log v2.6.12.. include/scsi drivers/scsi
   Show all commits since version v2.6.12 that changed any file in the 
include/scsi or drivers/scsi subdirectories

   ...

--

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

[issue12411] cgi.parse_multipart is broken on 3.x

[Jonas Wagner]

New submission from Jonas Wagner :

While writing tests for the cgi module I came across what looks like a 
conversion bug.

cgi.parse_multipart is comparing values it reads from a binary file like with a 
string literal:
line = fp.readline()
...
if line.startswith("--"):

This patch adds fixes the issue and adds test for it.

--
components: Library (Lib)
files: cgi-coverage.diff
keywords: patch
messages: 139082
nosy: jonas.wagner
priority: normal
severity: normal
status: open
title: cgi.parse_multipart is broken on 3.x
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file22470/cgi-coverage.diff

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

[issue7744] Allow site.addsitedir insert to beginning of sys.path

[Jonas Meurer]

Jonas Meurer  added the comment:

I would be interested in that feature as well. It's currently impossible to use 
custom new versions of a python module by adding the directory with 
site.addsitedir in case a old version of the module is already installed in the 
python systemwide path.

--
nosy: +mejo
status: pending -> open
versions: +Python 2.6

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

[issue12411] cgi.parse_multipart is broken on 3.x

[Jonas Wagner]

Jonas Wagner  added the comment:

Hi Tal,

Thanks a lot for your feedback.

My primary objective was to increase the test coverage for cgi.py. If it is a 
problem to have the additional tests in this patch I'm happy to create a new 
issue with a separate patch. 

The default value for the boundary was an oversight, sorry for that.

You are right regarding the commented out boundary as well, I forgot to refresh 
the patch. Again, sorry.

Do you think valid_boundary should contain a check to ensure it is a byte 
object?

--
Added file: http://bugs.python.org/file22567/cgi-coverage-2.diff

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

[issue12877] Popen(...).stdout.seek(...) throws "Illegal seek"

[Jonas H.]

New submission from Jonas H. :

from subprocess import Popen, PIPE
p = Popen(['ls'], stdout=PIPE)
p.wait()
p.stdout.seek(0)


Traceback (most recent call last):
  File "t.py", line 5, in 
p.stdout.seek(0)
IOError: [Errno 29] Illegal seek

Python 2.7.2, Arch Linux x86-64 (Kernel 3.0)

--
messages: 143323
nosy: jonash
priority: normal
severity: normal
status: open
title: Popen(...).stdout.seek(...) throws "Illegal seek"
versions: Python 2.7

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

[issue12877] Popen(...).stdout.seek(...) throws "Illegal seek"

[Jonas H.]

Jonas H.  added the comment:

Why does it have a 'seek' method then?

--

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

[issue1731717] race condition in subprocess module

[Jonas H.]

Changes by Jonas H. :


--
nosy: +jonash

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

[issue11258] ctypes: Speed up find_library() on Linux by 500%

[Jonas H.]

Changes by Jonas H. :


Added file: 
http://bugs.python.org/file20874/faster-find-library1-py3k-with-escaped-name.diff

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

[issue11258] ctypes: Speed up find_library() on Linux by 500%

[Jonas H.]

Jonas H.  added the comment:

As far as I can tell, it doesn't matter.

We're looking for the part after the => in any case - ignoring the 
ABI/architecture information - so the regex would chose the first of those 
entries.

--

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

[issue11258] ctypes: Speed up find_library() on Linux by 500%

[Jonas H.]

Jonas H.  added the comment:

Humm. Would be great to have the `ldconfig -p` output of such a machine... I 
can't get ldconfig to recognize 64-bit libraries on my 32-bit machines, so I 
have no output to test against...

--

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

[issue11345] Fix a link in library/json docs

[Jonas H.]

New submission from Jonas H. :

I guess this should be a link.

--
assignee: docs@python
components: Documentation
files: fix-json-link.diff
keywords: patch
messages: 129629
nosy: docs@python, jonash
priority: normal
severity: normal
status: open
title: Fix a link in library/json docs
versions: Python 3.3
Added file: http://bugs.python.org/file20932/fix-json-link.diff

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

[issue11258] ctypes: Speed up find_library() on Linux by 500%

[Jonas H.]

Jonas H.  added the comment:

> the orig impl matches the abi_type at the beginning of the parentheses,
> yours simply ignores the abi_type (that should have caught my eye, but that
> regex looked so much like magic that I didn't try to make sense of it :-))

Same here. :)

The version I attached seems to work for me. It's some kind of compromise -- 
basically it's the original regex but with the unneccessary, 
performance-decreasing cruft stripped away.

btw, "Jonas H." is perfectly fine - I don't care about being honored, I just 
want to `import uuid` without waiting forever. :-)

--
Added file: 
http://bugs.python.org/file20935/faster-find-library1-py3k-with-escaped-name-try2.diff

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

[issue4600] __class__ assignment: new-style? heap? == confusing

[Jonas H.]

Jonas H.  added the comment:

Here comes a patch, changing the behaviour to:

./python -q
>>> class C:
...   pass
... 
>>> (1).__class__ = 1
Traceback (most recent call last):
  File "", line 1, in 
TypeError: __class__ must be set to a class defined by a class statement, not 
'int' object
>>> (1).__class__ = object
Traceback (most recent call last):
  File "", line 1, in 
TypeError: class__ must be set to a class defined by a class statement, not 
'object'
>>> (1).__class__ = C
Traceback (most recent call last):
  File "", line 1, in 
TypeError: __class__ assignment: only for instances of classes defined by class 
statements

--
keywords: +patch
nosy: +jonash
Added file: http://bugs.python.org/file20937/4600.diff

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

[issue11484] `with_traceback` in 2.7 docs but not implemented

[Jonas H.]

New submission from Jonas H. :

Either a `BaseException.with_traceback` implementation is missing or the docs 
are wrong.

http://docs.python.org/library/exceptions.html?highlight=with_traceback#exceptions.BaseException.with_traceback

python3 -c 'print("with_traceback" in dir(BaseException))'
True
python2 -c 'print("with_traceback" in dir(BaseException))'
False

--
assignee: docs@python
components: Documentation
messages: 130760
nosy: docs@python, jonash
priority: normal
severity: normal
status: open
title: `with_traceback` in 2.7 docs but not implemented
versions: Python 2.7

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

[issue11258] ctypes: Speed up find_library() on Linux by 500%

[Jonas H.]

Jonas H.  added the comment:

*push* Any way to get this into the codebase?

--

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

[issue11975] Fix intersphinx-ing of built-in types (list, int, ...)

[Jonas H.]

New submission from Jonas H. :

Intersphinx-ing of int, list, float, ... should work with ":class:`int`" (list, 
float, ...). Also, intersphinx-ing list methods, e.g. ":meth:`list.insert`", 
should work.

--
assignee: docs@python
components: Documentation
messages: 134923
nosy: docs@python, jonash
priority: normal
severity: normal
status: open
title: Fix intersphinx-ing of built-in types (list, int, ...)

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

[issue11976] Provide proper documentation for list data type

[Jonas H.]

New submission from Jonas H. :

Provide a proper `list` method reference (like the one for `dict`, 
http://docs.python.org/library/stdtypes.html#dict).

Right now, documentation about lists is spread over multiple topics (.rst 
files) and methods are documented in footnotes.

Also, intersphinx-ing and list methods is not possible -- :meth:`list.foo` does 
not create any links due to missing documentation. This is also related to 
#11975.

--
assignee: docs@python
components: Documentation
messages: 134924
nosy: docs@python, jonash
priority: normal
severity: normal
status: open
title: Provide proper documentation for list data type

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

[issue11977] Document int.conjugate, .denominator, ...

[Jonas H.]

New submission from Jonas H. :

Various `int` attributes and methods seem undocumented (at least it does not 
work to intersphinx them):

* .conjugate
* .denominator
* .imag
* .numerator
* .real

--
assignee: docs@python
components: Documentation
messages: 134926
nosy: docs@python, jonash
priority: normal
severity: normal
status: open
title: Document int.conjugate, .denominator, ...
versions: Python 2.7

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

[issue11975] Fix referencing of built-in types (list, int, ...)

[Jonas H.]

Jonas H.  added the comment:

Actually I need to be able to intersphinx (because my documentation work is not 
the Python docs :-) but I guess it boils down to the same problem of incomplete 
Sphinx module/class indices.

--

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

[issue11975] Fix referencing of built-in types (list, int, ...)

[Jonas H.]

Jonas H.  added the comment:

Indeed they do; but documentation writers need to know that `int()` and 
`float()` are functions, which is counterintuitive. (and a CPython 
implementation detail)

--

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

[issue11975] Fix referencing of built-in types (list, int, ...)

[Jonas H.]

Jonas H.  added the comment:

> Is this a problem in our markup or a bug in intersphinx?

It's a markup problem -- those types are documented as functions, using the 
:func: role/`.. func::` directive.

It's not only a markup mismatch but, strictly speaking, it's *wrong* 
documentation: str, int, ... aren't functions, they're *classes* and should be 
documented as such. It's a bit odd to search for information on the str *class* 
in the list of built-in *functions*.


> If this work within one documentation set (as I believe it does)

It does not. For example, in http://docs.python.org/library/functions.html#max 
there's a reference to list.sort using :meth:`list.sort` but no link could be 
generated. How could it possibly work without decent documentation about the 
list data type?

--

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

[issue11977] Document int.conjugate, .denominator, ...

[Jonas H.]

Jonas H.  added the comment:

It doesn't. Sphinx still can't make any links, which btw also means that it's 
impossible to reference those methods within the Python documentation.

Also I want to point out that I find the information very hard to find as a 
human. The fact that integers are based on `numbers.Number` is -- at this point 
in time where 95% of all Python developers don't know about the `numbers` 
module or abstract base classes in general -- an implementation detail and as 
such should not affect the way `int` is documented.

I propose to have decent class references for int, str, ... similar to the 
reference for dict -- that is, document all attributes and methods in one place 
and make them referencable. For those who want to deep-dive into CPython 
internals, a note about those functionality actually being implemented in ABCs 
could be added.

(But I think that's out of scope for this ticket. I could open a new one if 
anyone agrees with me... :-)

--

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

[issue11975] Fix referencing of built-in types (list, int, ...)

[Jonas H.]

Jonas H.  added the comment:

Shouldn't have used "decent" here, sorry. What I was trying to say is that 
there's no "reference-like" documentation for the list datatype (as for dict). 
There's more than enough quality documentation about lists but I think the way 
it's arranged can be improved.

--

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

[issue11258] ctypes: Speed up find_library() on Linux by 500%

[Jonas H.]

New submission from Jonas H. :

(This applies to all versions of Python I investigated, although the attached 
patch is for Python 2.7)

I wondered why `import uuid` took so long, so I did some profiling.

It turns out that `find_library` wastes at lot of time because of this crazy 
regular expression in `_findSoname_ldconfig`.

A quick look at the ldconfig source (namely, the print_cache routine which is 
invoked when you call `ldconfig -p`, 
http://sourceware.org/git/?p=glibc.git;a=blob;f=elf/cache.c#l127) confirmed my 
suspicion that the ldconfig's output could easily be parsed without such a 
regex monster.

I attached two patches that fix this problem. Choose one! ;-)

The ctypes tests pass with my fixes, and here comes some benchmarking:

$ cat benchmark_ctypes.py 
from ctypes.util import find_library
for i in xrange(10):
  for lib in ['mm', 'c', 'bz2', 'uuid']:
find_library(lib)

# Current implementation
$ time python benchmark_ctypes.py 
real0m11.813s
...
$ time python -c 'import uuid'
real0m0.625s
...

# With my patch applied
$ cp /tmp/ctypesutil.py ctypes/util.py
$ time python benchmark_ctypes.py 
real0m1.785s
...
$ time python -c 'import uuid'
real0m0.182s
...

--
assignee: theller
components: ctypes
files: faster-find-library1.diff
keywords: patch
messages: 128910
nosy: jonash, theller
priority: normal
severity: normal
status: open
title: ctypes: Speed up find_library() on Linux by 500%
type: performance
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20808/faster-find-library1.diff

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

[issue11258] ctypes: Speed up find_library() on Linux by 500%

[Jonas H.]

Changes by Jonas H. :


Added file: http://bugs.python.org/file20809/faster-find-library2.diff

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

[issue11258] ctypes: Speed up find_library() on Linux by 500%

[Jonas H.]

Jonas H.  added the comment:

(might also be related to http://bugs.python.org/issue11063)

--

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

[issue3212] ssl module - should test for a wrong cert

[Jonas Wagner]

New submission from Jonas Wagner <[EMAIL PROTECTED]>:

Currently test_ssl.py only tests for empty or broken certificates. One
can break certificate validation in _ssl.c and they still pass.

The following patch should fix this.

- Jonas

--
components: Tests
files: add_wrong_cert_test.diff
keywords: patch
messages: 68797
nosy: janssen, jonas.wagner
severity: normal
status: open
title: ssl module - should test for a wrong cert
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file10745/add_wrong_cert_test.diff

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3212>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7795] BaseManager of multiprocessing module throws an exception if socket.setdefaulttimeout is set

[Jonas Weismüller]

New submission from Jonas Weismüller :

If socket.setdefaulttimeout is set to any value (except None), the BaseManager 
raises an exception and the execution of the remote object fails:
Traceback (most recent call last):
  File "client.py", line 16, in 
m = Manager()
  File "client.py", line 12, in __init__
self.connect()
  File "/usr/lib/python2.6/multiprocessing/managers.py", line 474, in connect
conn = Client(self._address, authkey=self._authkey)
  File "/usr/lib/python2.6/multiprocessing/connection.py", line 140, in Client
answer_challenge(c, authkey)
  File "/usr/lib/python2.6/multiprocessing/connection.py", line 371, in 
answer_challenge
message = connection.recv_bytes(256) # reject large message

See the attached client.py (uploading soon) and server.py file to reproduce the 
error.

Python version used:
Python 2.6 (r26:66714, Jun  8 2009, 16:07:26)
[GCC 4.4.0 20090506 (Red Hat 4.4.0-4)] on linux2

Same behaviour with python version:
Python 2.6 (r26:66714, Nov  3 2009, 17:33:38)
[GCC 4.4.1 20090725 (Red Hat 4.4.1-2)] on linux2

The operating system is Fedora 11.

--
components: Library (Lib)
files: server.py
messages: 98427
nosy: MrRagga
severity: normal
status: open
title: BaseManager of multiprocessing module throws an exception if 
socket.setdefaulttimeout is set
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file16025/server.py

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

[issue7795] BaseManager of multiprocessing module throws an exception if socket.setdefaulttimeout is set

[Jonas Weismüller]

Jonas Weismüller  added the comment:

uploading missing client file, changing the socket.setdefaulttimeout shows the 
issue.

--
Added file: http://bugs.python.org/file16026/client.py

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

[issue38337] inspect: getmembers calls properties

[Jonas Drotleff]

New submission from Jonas Drotleff :

When calling inspect.getmembers on a class that has a property (@property), the 
property will be called by the getattr call in getmembers.

Example:

import inspect

class Example:
def __init__(self, var):
self._var = var
print('__init__')

def foo(self, bar):
print(bar)
print('foo')

@property
def var(self):
print('Access property')
return self._var


if __name__ == '__main__':
ex = Example('Hello')
print('--- getmembers from instance ---')
print(inspect.getmembers(ex))
print('--- getmembers from class---')
print(inspect.getmembers(Example))


Result:

__init__
--- getmembers from instance ---
Access property
[('__class__', ), ..., ('var', 
'Hello')]
--- getmembers from class---
[('__class__', ), ..., ('var', 
)]


Expected:

__init__
--- getmembers from instance ---
[('__class__', ), ..., ('var', 
)]
--- getmembers from class---
[('__class__', ), ..., ('var', 
)]

--
components: Library (Lib)
messages: 353688
nosy: jnsdrtlf
priority: normal
severity: normal
status: open
title: inspect: getmembers calls properties
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

[issue38337] inspect: getmembers calls properties

[Jonas Drotleff]

Change by Jonas Drotleff :


--
keywords: +patch
pull_requests: +16113
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/16521

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

[issue14364] Argparse incorrectly handles '--' as argument to option

[Jonas Schäfer]

Jonas Schäfer  added the comment:

Since I have been adversely affected by this bug ([1]), I looked at the patches.

I combined issue14364.test.patch (which adds test cases for --foo=--) and 
dbldash.patch in my local working tree and that seems to resolve the issue 
(tests pass if and only if I apply dbldash.patch and my reproducer from [1]) 
passes too).

The patches do not contain any type of metainformation, so I’m not comfortable 
with submitting this as a PR. I am also not at all familiar with the process of 
managing the changelog etc.

This should serve as a confirmation that this issue can be resolved with the 
patches. Someone more familiar than me with the process could take up the task 
to get this merged.

Note: As you can see in [1], this issue has already caused data loss.

   [1]: https://github.com/borgbackup/borg/issues/4769

--
nosy: +jssfr

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

[issue38337] inspect: getmembers calls properties

[Jonas Drotleff]

Jonas Drotleff  added the comment:

> The results of this example are different from mine(version 3.7.4)

I do not really see any difference. What do you mean?

--
nosy:  -Sanjay

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

[issue38337] inspect: getmembers calls properties

[Jonas Drotleff]

Jonas Drotleff  added the comment:

Oh, yes I see what you mean. That's my fault, it seems like I copied the wrong 
line. Sorry.

But the important piece is the 'var' attribute. Sorry for the confusion.

--

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

[issue38536] Trailing space in formatted currency with international=True and locale de_DE

[Jonas Aschenbrenner]

Change by Jonas Aschenbrenner :


--
type:  -> behavior

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

[issue38536] Trailing space in formatted currency with international=True and locale de_DE

[Jonas Aschenbrenner]

New submission from Jonas Aschenbrenner :

>>> import locale
>>> locale.setlocale(locale.LC_ALL, ('de_DE', 'UTF-8'))
'de_DE.UTF-8'
>>> locale.currency(1345345345352.22, international=True)
'1345345345352,22 EUR '

Expected: '1345345345352,22 EUR'

--
components: Library (Lib)
messages: 354989
nosy: Jonas Aschenbrenner
priority: normal
severity: normal
status: open
title: Trailing space in formatted currency with international=True and locale 
de_DE
versions: Python 3.7

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

[issue45462] Speed up re.match with pre-compiled patterns

[Jonas H.]

New submission from Jonas H. :

re.match(p, ...) with a pre-compiled pattern p = re.compile(...) can be much 
slower than calling p.match(...). Probably mostly in cases with "easy" patterns 
and/or short strings.

The culprit is that re.match -> re._compile can spend a lot of time looking up 
p its internal _cache, where it will never find p:

def _compile(pattern, flags):
...
try:
return _cache[type(pattern), pattern, flags]
except KeyError:
pass
if isinstance(pattern, Pattern):
...
return pattern
...
_cache[type(pattern), pattern, flags] = p
...

_compile will always return before the _cache is set if given a Pattern object.

By simply reordering the isinstance(..., Pattern) check we can safe a lot of 
time.

I've seen speedups in the range of 2x-5x on some of my data. As an example:

Raw speed of re.compile(p, ...).match():
time ./python.exe -c 'import re'\n'pat = re.compile(".").match'\n'for _ in 
range(1_000_000): pat("asdf")'
Executed in  190.59 millis

Speed with this optimization:
time ./python.exe -c 'import re'\n'pat = re.compile(".")'\n'for _ in 
range(1_000_000): re.match(pat, "asdf")'
Executed in  291.39 millis

Speed without this optimization:
time ./python.exe -c 'import re'\n'pat = re.compile(".")'\n'for _ in 
range(1_000_000): re.match(pat, "asdf")'
Executed in  554.42 millis

--
components: Regular Expressions
messages: 403851
nosy: ezio.melotti, jonash, mrabarnett
priority: normal
severity: normal
status: open
title: Speed up re.match with pre-compiled patterns
type: performance
versions: Python 3.11

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

[issue45462] Speed up re.match with pre-compiled patterns

[Jonas H.]

Change by Jonas H. :


--
keywords: +patch
pull_requests: +27224
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/28936

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

[issue45462] Speed up re.match with pre-compiled patterns

[Jonas H.]

Jonas H.  added the comment:

I agree with your statement in principle. Here are numbers for the slowdown 
that's introduced:

Without the change:
  ./python.exe -m timeit -s 'import re'\n'[re.compile(f"fill_cache{i}") for i 
in range(512)]'\n'pat = re.compile(".")' 're.match(pat, "asdf")'
  50 loops, best of 5: 462 nsec per loop
  ./python.exe -m timeit -s 'import re'\n'[re.compile(f"fill_cache{i}") for i 
in range(512)]'\n'pat = re.compile(".")' 're.match(".", "asdf")'
  100 loops, best of 5: 316 nsec per loop

With the change:
  ./python.exe -m timeit -s 'import re'\n'[re.compile(f"fill_cache{i}") for i 
in range(512)]'\n'pat = re.compile(".")' 're.match(pat, "asdf")'
100 loops, best of 5: 207 nsec per loop
  ./python.exe -m timeit -s 'import re'\n'[re.compile(f"fill_cache{i}") for i 
in range(512)]'\n'pat = re.compile(".")' 're.match(".", "asdf")'
100 loops, best of 5: 351 nsec per loop

So we have a 2x speedup in the uncommon case and a 10% slowdown in the common 
case.

--

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

[issue45462] Speed up re.match with pre-compiled patterns

[Jonas H.]

Jonas H.  added the comment:

pat.match() has 110 nsec.

Feel free to close the issue and PR if you think this isn't worth changing.

--

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

[issue38750] Solve IPv4 categorisation issues with the ipaddress module

[sam jonas]

sam jonas  added the comment:

Hi i am also facing the same issue, please provide a good solution

--
nosy: +samjonas

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

[issue38337] inspect: getmembers calls properties

[Jonas Drotleff]

Jonas Drotleff  added the comment:

> Here is a link to the discussion of this on ideas

Thank you for posting the link.

I feel like I came to a dead end with this issue. As I am fairly new to CPython 
and have never contributed to this project before, I have no idea how to 
address this and to whom. Maybe this is just to irrelevant and not important, 
but even then we should probably close this issue or mark it as "indefinitely 
postponed" or something similar.

--

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

[issue39728] Instantiating enum with invalid value results in ValueError twice

[Jonas Malaco]

New submission from Jonas Malaco :

Trying to instantiate an enum with an invalid value results in "During handling 
of the above exception, another exception occurred:".


$ cat > test.py << EOF
from enum import Enum

class Color(Enum):
RED = 1
GREEN = 2
BLUE = 3

Color(0)
EOF


$ python --version
Python 3.8.1


$ python test.py
ValueError: 0 is not a valid Color

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "test.py", line 8, in 
Color(0)
  File "/usr/lib/python3.8/enum.py", line 304, in __call__
return cls.__new__(cls, value)
  File "/usr/lib/python3.8/enum.py", line 595, in __new__
raise exc
  File "/usr/lib/python3.8/enum.py", line 579, in __new__
result = cls._missing_(value)
  File "/usr/lib/python3.8/enum.py", line 608, in _missing_
raise ValueError("%r is not a valid %s" % (value, cls.__name__))
ValueError: 0 is not a valid Color


I think this might be related to 019f0a0cb85e ("bpo-34536: raise error for 
invalid _missing_ results (GH-9147)"), but I haven't been able to confirm.

--
components: Library (Lib)
messages: 362496
nosy: jonasmalaco
priority: normal
severity: normal
status: open
title: Instantiating enum with invalid value results in ValueError twice
type: behavior
versions: Python 3.8, Python 3.9

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

[issue38337] inspect: getmembers calls properties

[Jonas Drotleff]

Jonas Drotleff  added the comment:

I'm still thinking about this bug/issue/undefined behaviour. Today I wanted to 
test its behaviour with async:

import inspect


class Foo:
def __init__(self, bar):
self._bar = bar

@property
async def spam(self):
print('Called spam')
return self._bar


if __name__ == '__main__':
instance = Foo('eggs')
members = inspect.getmembers(instance)

##

This will result in a RuntimeWarning:


RuntimeWarning: coroutine 'Foo.spam' was never awaited
  members = inspect.getmembers(instance)
RuntimeWarning: Enable tracemalloc to get the object allocation traceback


Sure, async properties might not be particularly beautiful or best-practice, 
but I frequently stumble upon code where getmembers would fail – just like this 
example. However, I am still clueless about what to do.

--

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

[issue41295] CPython 3.8.4 regression on __setattr__ in multiinheritance with metaclasses

[Jonas Schäfer]

Change by Jonas Schäfer :


--
nosy: +jssfr

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

[issue41295] CPython 3.8.4 regression on __setattr__ in multiinheritance with metaclasses

[Jonas Schäfer]

Jonas Schäfer  added the comment:

@kam193 Thanks for running the aioxmpp tests. I built the patched python 
yesterday, but I didn’t manage to get a virtualenv with it up&running.

Good to hear that the fix works as expected!

--

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

[issue41710] Timeout is affected by jumps in system time

[Jonas Norling]

New submission from Jonas Norling :

The timeout for threading.Lock, threading.Condition, etc, is not using a 
monotonic clock — it is affected if the system time (realtime clock) is set.

The attached program can be used to show the problem. It is expected to print 
"Took 2.000 s" repeatedly, but if run with permissions to set the system time, 
it prints:
$ sudo ./time_test.py
Took 2.400 s
Took 1.657 s
Took 2.044 s
Took 2.401 s
...

(the 1.6 s time can be explained by NTP correcting the clock)

There are already a number of closed bugs for this and related issues: bpo 
23428, bpo 31267, bpo 35747.

This happens in Python 3.7.7 (ARM32, Yocto Warrior), Python 3.8.2 (AMD64, 
Ubuntu Linux 20.04) and Python v3.9.0rc1 (AMD64, Ubuntu Linux 20.04).

--
components: Interpreter Core
files: time_test.py
messages: 376338
nosy: wocket
priority: normal
severity: normal
status: open
title: Timeout is affected by jumps in system time
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file49440/time_test.py

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

[issue41710] Timeout is affected by jumps in system time

[Jonas Norling]

Jonas Norling  added the comment:

sys.thread_info = sys.thread_info(name='pthread', lock='semaphore', 
version='NPTL 2.31') on my system. Looking at the source I think the semaphore 
implementation will be used on all modern Linux systems.

In my tests it works as expected on a Macintosh (3.8.5 with lock='mutex+cond') 
and also if I force a Linux build to use the mutex+cond implementation by 
defining HAVE_BROKEN_POSIX_SEMAPHORES.

Doesn't look like those glibc and Linux bug reports will get any attention 
anytime soon. I will find a workaround instead :-/

--

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

[issue19270] Document that sched.cancel() doesn't distinguish equal events and can break order

[Jonas Norling]

Jonas Norling  added the comment:

@bar.harel: I didn't find a PR, so I'd like to encourage you to submit one :-)

I stumbled onto this bug when the scheduler would cancel the wrong event for me 
(Python 3.7, 3.8). Raymond's suggestion 1 sounds reasonable; it would be very 
unlikely to break code that doesn't depend on internals in sched, and it 
simplifies the implementation a bit.

--
nosy: +wocket

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

[issue37769] Windows Store installer should warn user about MAX_PATH

[Jonas Binding]

New submission from Jonas Binding :

The "Windows Store" installer for Python has a seemingly low entry barrier, 
causing people to install without reading something like 
https://docs.python.org/3.7/using/windows.html. 

However, due to the really long path it uses for Python (e.g. 
C:\Users\USERNAME\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.7_qbz5n2kfra8p0\),
 the chances of running into issues with paths longer than 260 characters are 
really high. 

For example installing pytorch already fails due to this limitation, see 
https://github.com/pytorch/pytorch/issues/23823 and 
https://www.reddit.com/r/pytorch/comments/c6cllq/issue_installing_pytorch/

Therefore, the Windows Store installer should offer to change the registry key 
to enable longer paths, or at least show a message to this effect.

--
components: Windows
messages: 349079
nosy: Jonas Binding, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Windows Store installer should warn user about MAX_PATH
type: enhancement
versions: Python 3.7

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

[issue36790] test_asyncio fails with application verifier!

[sam jonas]

sam jonas  added the comment:

Thanks for the solution...

--
nosy: +samjonas

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

[issue32679] concurrent.futures should store full sys.exc_info()

[Jonas H.]

New submission from Jonas H. :

Use case: Try to get a future's result using 
concurrent.futures.Future.result(), and log the full exception if there was any.

Currently, only "excinst" (sys.exc_info()[1]) is provided with the 
Future.exception() method.

Proposal: Add new Future.exc_info() method that returns the full sys.exc_info() 
at the time of the exception.

--
components: Library (Lib)
messages: 310762
nosy: jonash
priority: normal
severity: normal
status: open
title: concurrent.futures should store full sys.exc_info()
type: enhancement
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

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

[issue32679] concurrent.futures should store full sys.exc_info()

[Jonas H.]

Jonas H.  added the comment:

See also 
https://stackoverflow.com/questions/19309514/getting-original-line-number-for-exception-in-concurrent-futures
 for other people having the same problem

--

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

[issue33248] Different behavior on macos and linux (docker) with __await__

[Jonas Obrist]

New submission from Jonas Obrist :

The attached code runs fine on MacOS using 3.6.5 from homebrew. However on 
Windows (I tested on 3.6.4 with the 32bit installer from the website) and Linux 
(using the python:3.6.5 docker image) it errors with "TypeError: cannot 'yield 
from' a coroutine object in a non-coroutine generator".

On MacOS I tried both _UnixSelectorEventLoop with Kqueue and Select selectors, 
on Linux _UnixSelectorEventLoop with Epoll and Select.

Which behavior is the expected one?

As an aside, what I'm trying to achieve is to have an awaitable object that 
which if unawaited evaluates to False if used in if statements.

--
components: asyncio
files: nta.py
messages: 315119
nosy: Jonas Obrist, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Different behavior on macos and linux (docker) with __await__
type: behavior
versions: Python 3.6
Added file: https://bugs.python.org/file47526/nta.py

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

[issue33248] __await__ behaves different with or without PYTHONASYNCIODEBUG

[Jonas Obrist]

Jonas Obrist  added the comment:

I've just realized the difference between the environments wasn't the operating 
system, but PYTHONASYNCIODEBUG. If it is set, the code works, however if it is 
unset the code does not work. See the updated (attached) code for reference.

--
title: Different behavior on macos and linux (docker) with __await__ -> 
__await__ behaves different with or without PYTHONASYNCIODEBUG
Added file: https://bugs.python.org/file47527/nta.py

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

[issue33248] __await__ behaves different with or without PYTHONASYNCIODEBUG

[Jonas Obrist]

Jonas Obrist  added the comment:

On 9c463ec88ba21764f6fff8e01d6045a932a89438 (master/3.7) both cases fail to 
execute. I would argue that this code should be allowed...

--

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

[issue33248] __await__ behaves different with or without PYTHONASYNCIODEBUG

[Jonas Obrist]

Jonas Obrist  added the comment:

I realized I have to call __await__ of the inner coroutine object in 
NonTrueAwaitable.__await__. This is not a bug, but my mistake.

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

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

[issue31526] Allow setting timestamp in gzip-compressed tarfiles

[Jonas H.]

Jonas H.  added the comment:

This affects me too.

--
nosy: +jonash

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

[issue32071] Add py.test-like "-k" test selection to unittest

[Jonas H.]

New submission from Jonas H. :

I'd like to add test selection based on parts of the test class/method name to 
unittest. Similar to py.test's "-k" option: 
https://docs.pytest.org/en/latest/example/markers.html#using-k-expr-to-select-tests-based-on-their-name

Here's a proof of concept implementation: 
https://github.com/jonashaag/cpython/compare/master...unittest-select

Is this something others find useful as well? If so, I'd like to work on 
getting this into Python stdlib proper. This is my first time contributing to 
the unittest framework; is the general approach taken in my PoC implementation 
correct in terms of abstractions? How can I improve the implementation?

Jonas

--
components: Library (Lib)
messages: 306490
nosy: jonash
priority: normal
severity: normal
status: open
title: Add py.test-like "-k" test selection to unittest
type: enhancement

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

[issue32071] Add py.test-like "-k" test selection to unittest

[Jonas H.]

Jonas H.  added the comment:

Just to be clear, the current implementation is limited to substring matches. 
It doesn't support py.test like "and/or" combinators. (Actually, py.test uses 
'eval' to support arbitrary patterns.)

So say we have test case

SomeClass
test_foo
test_bar

Then

- python -m unittest -k fo matches "test_foo"
- python -m unittest -k Some matches "test_foo" and "test_bar"
- python -m unittest -k some matches nothing

The -k option may be used multiple times, combining the patterns with "or":

- python -m unittest -k fo -k b matches "test_foo" and "test_bar"

It's also possible to use glob-style patterns, like -k "spam_*_eggs".

--

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

[issue32071] Add py.test-like "-k" test selection to unittest

[Jonas H.]

Jonas H.  added the comment:

Thanks Antoine. I will need some guidance as to what are the correct places to 
make these changes. I'm not quite sure about the abstractions here (runner, 
loader, suite, case, etc.)

My PoC (see GitHub link in first post) uses a TestSuite subclass. (The subclass 
is only so that it's easier to assess the general implementation approach; I 
guess it should be put into the main class instead.)

Things I'm unsure of:

1) Is suite the correct place for this kind of feature?
2) Is the hardcoded fnmatch-based pattern matcher ok, or do we need a new 
abstraction "NameMatcher"?
3) Is the approach of dynamically wrapping 'skip()' around to-be-skipped test 
cases OK?
4) The try...catch statement around 'test.id()' is needed because there are 
some unit tests (unit tests for the unittest module itself) that check for some 
error cases/error handling in the unittest framework, and crash if we try to 
call '.id()' on them. Please remove the try...catch to see these errors if 
you're interested in the details. Is the check OK like that, or is this a code 
smell?

Thanks
Jonas

--

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

[issue32071] Add py.test-like "-k" test selection to unittest

[Jonas H.]

Jonas H.  added the comment:

> > 3) Is the approach of dynamically wrapping 'skip()' around to-be-skipped 
> > test cases OK?

> I think this is the wrong approach.  A test that isn't selected shouldn't be 
> skipped, it should not appear in the output at all.  Another reason for 
> putting this in TestLoader :-)

My first implementation actually was mostly the test loader. Two things made me 
change my mind and try to make the changes in the suite code:

- The loader code really only deals with loading (i.e., finding + importing) 
tests. Yes it expects a file pattern like "test*.py" for identifying test case 
files. But apart from that it didn't "feel" right to put name based selection 
there.
- In py.test you'll get a console output like "5 tests passed, 1 test failed, 
12 tests deselected". We can't get anything similar without making bigger 
changes to the test loader, runner, etc. code. Using skip() we at least have 
some info on "skipped" tests, although they're technically not skipped.

Are you still saying this should go to the test loader?

--

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

[issue32071] Add py.test-like "-k" test selection to unittest

[Jonas H.]

Jonas H.  added the comment:

Interesting, Victor. I've had a look at the code you mentioned, but I'm afraid 
it doesn't really make sense to re-use any of the code.

Here's a new patch, implemented in the loader as suggested by Antoine, and with 
tests.

I'm happy to write documentation etc. once we're through with code review.

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

--
keywords: +patch
pull_requests: +4433
stage: needs patch -> patch review

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

[issue32071] Add py.test-like "-k" test selection to unittest

[Jonas H.]

Jonas H.  added the comment:

Sure!

--

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

[issue32071] Add py.test-like "-k" test selection to unittest

[Jonas H.]

Jonas H.  added the comment:

Ah, the problem isn't that it's running getattr() on test methods, but that it 
runs getattr() on all methods.

Former code: attrname.startswith(prefix) and \
callable(getattr(testCaseClass, attrname))

New code: testFunc = getattr(testCaseClass, attrname)
isTestMethod = attrname.startswith(self.testMethodPrefix) and 
callable(testFunc)

This is trivial to fix. @Core devs: Should I revert to original behaviour with 
the order of the prefix check and the getattr() call, and add a regression test 
that guarantees this behaviour?

--

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

[issue32071] Add py.test-like "-k" test selection to unittest

[Jonas H.]

Change by Jonas H. :


--
pull_requests: +4513

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

[issue32071] Add py.test-like "-k" test selection to unittest

[Jonas H.]

Jonas H.  added the comment:

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

- Add 3.7 What's New entry
- Fix regression (thanks Tim for the report)

--

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

[issue34087] django: segmentation fault on garbage collection in visit_decref()

[Jonas H.]

Jonas H.  added the comment:

I also have a segfault that goes away with malloc debugging. Not sure if it's 
the same issue.

My extension modules are

venv/lib/python3.7/site-packages//_yaml.cpython-37m-darwin.so
venv/lib/python3.7/site-packages//netifaces.cpython-37m-darwin.so
venv/lib/python3.7/site-packages//PIL/_webp.cpython-37m-darwin.so
venv/lib/python3.7/site-packages//PIL/_imagingft.cpython-37m-darwin.so
venv/lib/python3.7/site-packages//PIL/_imagingcms.cpython-37m-darwin.so
venv/lib/python3.7/site-packages//PIL/_imaging.cpython-37m-darwin.so
venv/lib/python3.7/site-packages//PIL/_imagingmath.cpython-37m-darwin.so
venv/lib/python3.7/site-packages//PIL/_imagingtk.cpython-37m-darwin.so
venv/lib/python3.7/site-packages//PIL/_imagingmorph.cpython-37m-darwin.so
venv/lib/python3.7/site-packages//lxml/builder.cpython-37m-darwin.so
venv/lib/python3.7/site-packages//lxml/_elementpath.cpython-37m-darwin.so
venv/lib/python3.7/site-packages//lxml/html/diff.cpython-37m-darwin.so
venv/lib/python3.7/site-packages//lxml/html/clean.cpython-37m-darwin.so
venv/lib/python3.7/site-packages//lxml/etree.cpython-37m-darwin.so
venv/lib/python3.7/site-packages//lxml/objectify.cpython-37m-darwin.so
venv/lib/python3.7/site-packages//coverage/tracer.cpython-37m-darwin.so

Unfortunately I can't test the application without any of these, but maybe we 
can match my list with fenrrir's.

--
nosy: +jonash

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

[issue34087] django: segmentation fault on garbage collection in visit_decref()

[Jonas H.]

Jonas H.  added the comment:

Btw my segfault is from Django too, but that may just be a coincidence

--

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

[issue34087] django: segmentation fault on garbage collection in visit_decref()

[Jonas H.]

Jonas H.  added the comment:

I can reproduce this on Ubuntu 18.04.

INADA, I have a full gdb backtrace with Python 3.7 development build. I'd like 
to share it with you privately as I'm concerned it may contain sensible 
information. I know that's a bit unconventional; if you have other suggestions 
I'm happy to follow along.

--

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

[issue34087] django: segmentation fault on random places

[Jonas H.]

Jonas H.  added the comment:

Reduced it to something that seems unicode related?

No extension modules involved. Vanilla Django project with a single url + 
template.

See testproj/urls.py and tmpl/index.html

--
Added file: https://bugs.python.org/file47688/testproj.tar.gz

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

[issue34087] django: segmentation fault on random places

[Jonas H.]

Jonas H.  added the comment:

Sure.

Unpack archive, create new 3.7 venv with Django (latest version is fine), 
./manage.py runserver, curl localhost:8000.

--

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

[issue34087] django: segmentation fault on random places

[Jonas H.]

Jonas H.  added the comment:

Here's a Docker image that reproduces the bug.

FROM ubuntu:18.04
RUN apt update && apt install -y python3.7-dbg python3.7-venv python3-venv wget
RUN python3.7 -m venv venv
RUN venv/bin/pip install django
RUN wget https://bugs.python.org/file47688/testproj.tar.gz -O - | tar xfz -
CMD cd /testproj && /venv/bin/python manage.py runserver & sleep 5; wget -t1 
localhost:8000 >/dev/null 2>/dev/null

Of course this also works outside Docker. I have reproduced with macOS 10.13.5 
(17F77) and Ubuntu 18.04 (Docker).

On macOS it's Python 3.7.0 (default, Jun 29 2018, 20:13:13) [Clang 9.1.0 
(clang-902.0.39.2)] on darwin, installed from Homebrew.

On Ubuntu it's whatever is in the 18.04 repositories.

--

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

[issue34087] int(s), float(s) and others may cause segmentation fault

[Jonas H.]

Jonas H.  added the comment:

I don't think this can be tested with Python code, unless you can make sure the 
target buffer _PyUnicode_TransformDecimalAndSpaceToASCII operates on is 
initialised with garbage bytes.

--

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

[issue34087] int(s), float(s) and others may cause segmentation fault

[Jonas H.]

Jonas H.  added the comment:

The assertion in the patched code, yes. The segfault in the unpatched code, no.

--

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

[issue18179] SMTP.local_hostname is undocumented

[Jonas H.]

New submission from Jonas H.:

The Sphinx docs don't contain any explanation for `local_hostname`.

--
assignee: docs@python
components: Documentation
messages: 190898
nosy: docs@python, jonash
priority: normal
severity: normal
status: open
title: SMTP.local_hostname is undocumented
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 
3.4, Python 3.5

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

[issue18240] hmac unnecessarily restricts input to "bytes"

[Jonas Borgström]

New submission from Jonas Borgström:

Problem:
In hmac.py there's a type check that verifies that the msg parameter is of type 
bytes().

if not isinstance(msg, bytes):
raise TypeError("expected bytes, but got %r" % type(msg).__name__)

That is incorrect. The hmac module should also work with other data types as 
long as they are supported by the underlying hashlib module, for example 
bytearray() and memoryview().

Suggestion:
Remove that type check. hashlib will make sure str() and other invalid data 
types raises a TypeError.

--
components: Library (Lib)
messages: 191321
nosy: jborg
priority: normal
severity: normal
status: open
title: hmac unnecessarily restricts input to "bytes"
type: behavior
versions: Python 3.3

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

[issue18240] hmac unnecessarily restricts input to "bytes"

[Jonas Borgström]

Changes by Jonas Borgström :


--
keywords: +patch
Added file: http://bugs.python.org/file30628/hmac.patch

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

[issue18240] hmac unnecessarily restricts input to "bytes"

[Jonas Borgström]

Jonas Borgström added the comment:

Patch updated to include tests and versionchanged tags

--
Added file: http://bugs.python.org/file30637/hmac2.patch

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

[issue18240] hmac unnecessarily restricts input to "bytes"

[Jonas Borgström]

Jonas Borgström added the comment:

Of course. I've now signed and filed the agreement.

--

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

[issue18547] os.path.dirname() does not behave as expected for path without /:es

[Jonas Eriksson]

New submission from Jonas Eriksson:

Only tested on marked python versions. Checked the code in hg (a5681f50bae2) 
and did not see anything related to this in the current development version.

Essentially, what I see is this:
>>> os.path.dirname("asdf")
''
>>> os.path.dirname("./asdf")
'.'
>>> 

What I expect is the same output as from the unix command dirname:
$ dirname asdf
.
$ dirname ./asdf
.
$ 

The change is quite straight forwards, Lib/posixpath.py needs something like if 
head = "": head = ".", and Lib/ntpath.py something similar.

Now, this bug is a tricky one since it alters the behavior of dirname. However, 
I cannot see any case where "" would be useful and have seen at least one bug 
because of this behaviour because the return value "" is treated like an error. 
So I gracefully hand over the final decision to you :)

--
components: Library (Lib)
messages: 193662
nosy: Jonas.Eriksson
priority: normal
severity: normal
status: open
title: os.path.dirname() does not behave as expected for path without /:es
type: behavior
versions: Python 2.7, Python 3.2

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