[issue27647] Update Windows build to Tcl/Tk 8.6.6

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Why not? 8.5.15 is 3 years old. There were 4 bugfix releases since it.

--

___
Python tracker 

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

[issue11145] '%o' % user-defined instance

[Armin Rigo]

Armin Rigo added the comment:

I reviewed your patch again.  It does look good after all: I find only one 
issue---it seems I implied there were several ones but I can't find more.  The 
issue is that PyString_AsString(result) will succeed if 'result' is a unicode.  
Then you call PyString_GET_SIZE(result), which gives nonsense for unicode 
objects.

--

___
Python tracker 

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

[issue28781] On Installation of 3.5 Python get error message

[Mark Harris]

Mark Harris added the comment:

This is everything I have in my temp file that I could possibly send you, hope 
it helps.

--
Added file: http://bugs.python.org/file45698/Python 4.zip

___
Python tracker 

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

[issue28832] Reduce memset in dict creation

[INADA Naoki]

Changes by INADA Naoki :


Added file: http://bugs.python.org/file45699/default.json.gz

___
Python tracker 

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

[issue28832] Reduce memset in dict creation

[INADA Naoki]

INADA Naoki added the comment:

I ran pyperformance again on more large machine (Azure D2 -> D4) for more 
robust result.

$ ./python-default -m perf compare_to default.json.gz patched.json.gz -G
Slower (4):
- xml_etree_generate: 425 ms +- 18 ms -> 442 ms +- 19 ms: 1.04x slower
- call_method: 25.7 ms +- 0.9 ms -> 26.1 ms +- 1.3 ms: 1.02x slower
- xml_etree_iterparse: 345 ms +- 17 ms -> 349 ms +- 20 ms: 1.01x slower
- chameleon: 44.9 ms +- 1.9 ms -> 45.5 ms +- 2.1 ms: 1.01x slower

Faster (39):
- scimark_sor: 874 ms +- 32 ms -> 811 ms +- 33 ms: 1.08x faster
- unpickle_pure_python: 1.41 ms +- 0.07 ms -> 1.31 ms +- 0.08 ms: 1.08x faster
- raytrace: 2.19 sec +- 0.07 sec -> 2.05 sec +- 0.04 sec: 1.07x faster
- sympy_integrate: 78.3 ms +- 9.2 ms -> 73.1 ms +- 4.8 ms: 1.07x faster
- pickle_dict: 105 us +- 11 us -> 98.5 us +- 4.4 us: 1.06x faster
- html5lib: 385 ms +- 21 ms -> 362 ms +- 16 ms: 1.06x faster
- pathlib: 80.5 ms +- 5.1 ms -> 76.1 ms +- 3.4 ms: 1.06x faster
- pickle: 38.1 us +- 2.7 us -> 36.0 us +- 2.9 us: 1.06x faster
- sqlite_synth: 15.7 us +- 0.8 us -> 14.8 us +- 0.9 us: 1.06x faster
- meteor_contest: 318 ms +- 18 ms -> 301 ms +- 12 ms: 1.06x faster
- hexiom: 37.4 ms +- 1.9 ms -> 35.5 ms +- 1.8 ms: 1.05x faster
- telco: 34.6 ms +- 2.1 ms -> 32.9 ms +- 1.4 ms: 1.05x faster
- go: 957 ms +- 35 ms -> 914 ms +- 36 ms: 1.05x faster
- regex_compile: 702 ms +- 24 ms -> 671 ms +- 23 ms: 1.05x faster
- regex_dna: 421 ms +- 14 ms -> 403 ms +- 15 ms: 1.04x faster
- genshi_xml: 314 ms +- 9 ms -> 301 ms +- 13 ms: 1.04x faster
- tornado_http: 664 ms +- 29 ms -> 636 ms +- 27 ms: 1.04x faster
- sqlalchemy_imperative: 103 ms +- 9 ms -> 98.6 ms +- 7.8 ms: 1.04x faster
- dulwich_log: 265 ms +- 16 ms -> 254 ms +- 10 ms: 1.04x faster
- richards: 291 ms +- 15 ms -> 279 ms +- 14 ms: 1.04x faster
- json_dumps: 45.2 ms +- 2.5 ms -> 43.5 ms +- 1.8 ms: 1.04x faster
- scimark_lu: 768 ms +- 40 ms -> 738 ms +- 32 ms: 1.04x faster
- mako: 65.9 ms +- 3.9 ms -> 63.4 ms +- 2.1 ms: 1.04x faster
- logging_simple: 52.9 us +- 3.5 us -> 51.0 us +- 2.0 us: 1.04x faster
- regex_effbot: 7.64 ms +- 0.48 ms -> 7.36 ms +- 0.43 ms: 1.04x faster
- pickle_pure_python: 2.08 ms +- 0.13 ms -> 2.01 ms +- 0.09 ms: 1.04x faster
- scimark_monte_carlo: 414 ms +- 26 ms -> 399 ms +- 20 ms: 1.04x faster
- unpack_sequence: 196 ns +- 11 ns -> 189 ns +- 6 ns: 1.04x faster
- logging_silent: 1.17 us +- 0.07 us -> 1.13 us +- 0.05 us: 1.04x faster
- sympy_expand: 1.68 sec +- 0.06 sec -> 1.62 sec +- 0.06 sec: 1.03x faster
- call_simple: 20.9 ms +- 1.0 ms -> 20.3 ms +- 0.9 ms: 1.03x faster
- nqueens: 411 ms +- 19 ms -> 401 ms +- 19 ms: 1.03x faster
- sympy_str: 762 ms +- 29 ms -> 743 ms +- 23 ms: 1.03x faster
- pidigits: 488 ms +- 18 ms -> 476 ms +- 12 ms: 1.02x faster
- logging_format: 62.2 us +- 3.2 us -> 60.8 us +- 3.0 us: 1.02x faster
- sympy_sum: 351 ms +- 18 ms -> 343 ms +- 16 ms: 1.02x faster
- spectral_norm: 413 ms +- 21 ms -> 405 ms +- 18 ms: 1.02x faster
- float: 464 ms +- 18 ms -> 456 ms +- 19 ms: 1.02x faster
- python_startup_no_site: 15.2 ms +- 0.8 ms -> 15.0 ms +- 0.7 ms: 1.01x faster

Benchmark hidden because not significant (21): 2to3, call_method_slots, 
call_method_unknown, chaos, crypto_pyaes, deltablue, django_template, fannkuch, 
genshi_text, json_loads, nbody, pickle_list, python_startup, regex_v8, 
scimark_fft, scimark_sparse_mat_mult, sqlalchemy_declarative, unpickle, 
unpickle_list, xml_etree_parse, xml_etree_process

--
Added file: http://bugs.python.org/file45700/patched.json.gz

___
Python tracker 

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

[issue11145] '%o' % user-defined instance

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Good catch Armin! Thank you for your review.

Updated patch uses PyString_AsStringAndSize() and adds a check that result is 
exact str before changing it in-place.

--
Added file: http://bugs.python.org/file45701/issue11145_5.patch

___
Python tracker 

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

[issue11145] '%o' % user-defined instance

[Armin Rigo]

Armin Rigo added the comment:

Looks ok now!

--

___
Python tracker 

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

[issue28832] Reduce memset in dict creation

[INADA Naoki]

INADA Naoki added the comment:

> I think that clearing 120 bytes at a time is faster than clear it later 
> entry-by-entry.

Ah, my word was wrong. This patch skips zero clear entirely.
In pseudo code:

  // When allocating PyDictKeyObject.
- memset(dk_entries, 0, sizeof(dk_entries));

  // When inserting new item.
  n = dk_nentries++
  e = &dk_entries[dk_nentries++];
  e->me_hash = hash;
  e->me_key = key;
  if (split_table) {
+ e->me_value = NULL;
  ma_values[n] = value;
  } else {
  e->me_value = value;
  }


> Your patch removes some asserts, this looks not good.

This patch fills dk_entries with 0xcc when Py_DEBUG is enabled.
It can find unintentional access to value which comes from reused memory.

I'll search more points I can insert effective asserts.


> Could your provide microbenchmarks that show the largest speed up and the 
> largest slow down? So we would see what type of code gets the benefit.

Avoiding cache pollution is more important than avoiding 120byte memset in this 
case.
It's difficult to write simple micro benchmark to show effects of cache 
pollution...

$ ./python-patched -m perf timeit --rigorous --compare-to `pwd`/python-default 
--duplicate 8 -- '{}'
python-default: . 44.6 ns +- 2.4 ns
python-patched: . 44.1 ns +- 1.8 ns
Median +- std dev: [python-default] 44.6 ns +- 2.4 ns -> [python-patched] 44.1 
ns +- 1.8 ns: 1.01x faster

--

___
Python tracker 

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

[issue28820] Typo in section 6 of the Python 3.4 documentation

[Roundup Robot]

Roundup Robot added the comment:

New changeset 4f24641cd030 by Martin Panter in branch '2.7':
Issue #28820: Fix spelling of “practice” as a noun
https://hg.python.org/cpython/rev/4f24641cd030

--
nosy: +python-dev

___
Python tracker 

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

[issue28820] Typo in section 6 of the Python 3.4 documentation

[Martin Panter]

Martin Panter added the comment:

I’m waiting for the 3.6 release candidate before pushing to the Py 3 branches.

--

___
Python tracker 

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

[issue22039] PyObject_SetAttr doesn't mention value = NULL

[Martin Panter]

Martin Panter added the comment:

As of Issue 25701, the null-to-delete feature is documented as being deprecated 
in favour of calling the related Del functions or macros. There was a 
python-dev thread at .

I’m not sure if that is good enough, or do we need to e.g. clarify that the 
deprecation is only at the API (C header) level, and not the ABI level?

--

___
Python tracker 

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

[issue28837] 2to3 does not wrap zip correctly

[Carsten]

New submission from Carsten:

The following Python 2.7 code is not converted correctly to Python 3 by 2to3:

c = [(1, 10), (2, 20)]

# get a tuple with the first entries of every tuple in c,
# i.e. (1, 2)
x = zip(*c)[0]

print x


The result is


c = [(1, 10), (2, 20)]

# get a tuple with the first entries of every tuple in c,
# i.e. (1, 2)
x = zip(*c)[0]

print(x)



However running it with python3 gives the following exception

Traceback (most recent call last):
  File "result.py", line 7, in 
x = zip(*c)[0]
TypeError: 'zip' object is not subscriptable



Tested with 2to3-2.7 and 2to3-3.4 on debian stable (jessie)

--
components: 2to3 (2.x to 3.x conversion tool)
messages: 282075
nosy: cvk
priority: normal
severity: normal
status: open
title: 2to3 does not wrap zip correctly
type: behavior
versions: Python 2.7, Python 3.4

___
Python tracker 

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

[issue25701] Document that tp_setattro and tp_setattr are used for deleting attributes

[Roundup Robot]

Roundup Robot added the comment:

New changeset 83e3c863594c by Martin Panter in branch '2.7':
Issue #25701: Document that some C APIs can both set and delete items
https://hg.python.org/cpython/rev/83e3c863594c

--

___
Python tracker 

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

[issue25701] Document that tp_setattro and tp_setattr are used for deleting attributes

[Martin Panter]

Martin Panter added the comment:

I made one minor change: element → slice

--
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

___
Python tracker 

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

[issue28838] Uniformize argument names of "call" functions (C API)

[STINNER Victor]

Changes by STINNER Victor :


--
title: Uniformize argument names of "call" functions -> Uniformize argument 
names of "call" functions (C API)

___
Python tracker 

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

[issue28838] Uniformize argument names of "call" functions

[STINNER Victor]

New submission from STINNER Victor:

See python-dev thread about my changeset 7efddbf1aa70:
https://mail.python.org/pipermail/python-dev/2016-November/146885.html

Serhiy asked me to revert it. It's now reverted by the revision 20bb8babc505. 
So, here is my change as a patch to review it.

See the thread for my rationale on argument names.

--

Uniformize argument names of "call" functions

* Callable object: callable, o, callable_object => func
* Object for method calls: o => obj
* Method name: name or nameid => method

Cleanup also the C code:

* Don't initialize variables to NULL if they are not used before their first
  assignement
* Add braces for readability

--
components: Interpreter Core
files: call.patch
keywords: patch
messages: 282078
nosy: haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Uniformize argument names of "call" functions
type: enhancement
versions: Python 3.7
Added file: http://bugs.python.org/file45702/call.patch

___
Python tracker 

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

[issue28839] _PyFunction_FastCallDict(): replace PyTuple_New() with PyMem_Malloc()

[STINNER Victor]

New submission from STINNER Victor:

Attached patch is a minor optimization for _PyFunction_FastCallDict(): avoid 
the creation of a tuple to pass keyword arguments, use a simple C array 
allocated by PyMem_Malloc().

It also uses a small stack of 80 bytes (2*5*sizeof(PyObject*)) allocated on the 
C stack to pass up to 5 keyword arguments (5 key+value pairs): it avoids 
completely the allocation on the heap memory 

I wrote _PyFunction_FastCallDict() (issue #27809): the code was based on 
function_call() which also uses PyTuple_New(). When I wrote the function, I 
didn't notice that PyEval_EvalCodeEx() doesn't expect a Python tuple object, 
but a C array.

The patch also modifies function_call() to call _PyFunction_FastCallDict(), so 
it gets _PyFunction_FastCallDict() optimizations.

--
files: fastcalldict.patch
keywords: patch
messages: 282079
nosy: haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: _PyFunction_FastCallDict(): replace PyTuple_New() with PyMem_Malloc()
type: performance
versions: Python 3.7
Added file: http://bugs.python.org/file45703/fastcalldict.patch

___
Python tracker 

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

[issue28839] _PyFunction_FastCallDict(): replace PyTuple_New() with PyMem_Malloc()

[STINNER Victor]

STINNER Victor added the comment:

fastcalldict.patch avoided INCREF/DECREF on keyword keys and values. This is 
wrong: we must hold strong references because the keyword dictionary can be 
technically modified: see issue #2016 and test_extcall.

Hum, I'm quite sure that it's not the first time that I was bitten by this bug. 
That's maybe why I didn't try to implement this optimization the first time.

fastcalldict-2.patch keeps INCREF/DECREF and so doesn't crash on test_extcall.

--
Added file: http://bugs.python.org/file45704/fastcalldict-2.patch

___
Python tracker 

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

[issue28838] Uniformize argument names of "call" functions (C API)

[Nick Coghlan]

Nick Coghlan added the comment:

Independently of anything else, any changes made to the parameter names in the 
implementation should be reflected in the API docs: 
https://docs.python.org/3/c-api/object.html#c.PyCallable_Check

A style guide addition to PEP 7 would also be useful as a record of the 
preferred naming scheme.

That said, one of the problems you're up against inside the C code base is that 
we really do have some code evaluation APIs that only work with true Python 
functions, while a abstract APIs handle arbitrary callables. Reserving "func" 
for the former cases helps make it clear which is which.

By contrast, end user code (and even the standard library) can usually get away 
with saying "func" even when they mean "arbitrary callable" without causing 
confusion, as there's only the one Python-level call syntax.

So perhaps one way to start here would be to propose an addition to 
https://www.python.org/dev/peps/pep-0007/#naming-conventions specifically for 
dealing with callable parameters in APIs that covers parameters that are:

- arbitrary callables
- specifically a synchronous Python function
- method names (whether as const char *, PyObject *, or _Py_Identifier)

--
nosy: +ncoghlan

___
Python tracker 

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

[issue28840] IDLE not handling long lines correctly

[piotr.sk]

New submission from piotr.sk:

IDLE included in Python 3.5.2 does not display correctly files with very long 
lines under Windows 7.

Attached example file does not show the third line correctly in Windows 7. 
These lines are part of a script that attempts to parse the messages.
Even though very long lines are not according to Python convention, they should 
be displayed correctly in the editor. 
If Notepad does it correctly, I would assume IDLE can handle long lines too ;-)

--
assignee: terry.reedy
components: IDLE
files: test.py
messages: 282082
nosy: piotr.sk, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE not handling long lines correctly
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file45705/test.py

___
Python tracker 

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

[issue24339] iso6937 encoding missing

[John Helour]

Changes by John Helour :


Removed file: http://bugs.python.org/file45697/iso6937.py

___
Python tracker 

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

[issue24339] iso6937 encoding missing

[John Helour]

Changes by John Helour :


Removed file: http://bugs.python.org/file45706/iso6937.py

___
Python tracker 

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

[issue24339] iso6937 encoding missing

[John Helour]

Changes by John Helour :


Added file: http://bugs.python.org/file45706/iso6937.py

___
Python tracker 

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

[issue24339] iso6937 encoding missing

[John Helour]

Changes by John Helour :


Added file: http://bugs.python.org/file45707/iso6937.py

___
Python tracker 

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

[issue18777] Cannot compile _ssl.c using openssl > 1.0

[James Matthews]

James Matthews added the comment:

This is marked as fixed but am still seeing this error in 2.7.12 on HP-UX 11.31.

/opt/hp-gcc64-4.7.1/bin/gcc -pthread -shared 
build/temp.hp-ux-B.11.31-9000-800-2.7/root/build/Python-2.7.12/Modules/_ssl.o 
-L/usr/local/lib -lssl -lcrypto -o build/lib.hp-ux-B.11.31-9000-800-2.7/_ssl.sl
/usr/lib/pa20_64/dld.sl: Unsatisfied code symbol 'CRYPTO_THREADID_set_callback' 
in load module 'build/lib.hp-ux-B.11.31-9000-800-2.7/_ssl.sl'.
/bin/sh: 23510 Killed
gmake: *** [sharedmods] Error 137

--
nosy: +James Matthews

___
Python tracker 

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

[issue24339] iso6937 encoding missing

[John Helour]

Changes by John Helour :


Removed file: http://bugs.python.org/file45707/iso6937.py

___
Python tracker 

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

[issue24339] iso6937 encoding missing

[John Helour]

John Helour added the comment:

Please ignore my previous question about:
tmp += bytearray(encoding_map[c], 'latin1', 'ignore')

The latest version don't needs such encoding ...

--
Added file: http://bugs.python.org/file45708/iso6937.py

___
Python tracker 

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

[issue28838] Uniformize argument names of "call" functions (C API)

[STINNER Victor]

STINNER Victor added the comment:

Serhiy: Can you please elaborate "Other changes looks not well justified too."?

--

___
Python tracker 

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

[issue28841] urlparse.urlparse() parses invalid URI without generating an error (examples provided)

[Amrith Kumar]

New submission from Amrith Kumar:

The urlparse library incorrectly accepts a URI which specifies an invalid host 
identifier.

Example:

http://www.example.com:/abc

Looking at the URI specifications, this is an invalid URI.

By definition, you are supposed to specify a "hostport" and a hostport is 
defined as:

https://www.w3.org/Addressing/URL/uri-spec.html

hostport
host [ : port ]

The BNF indicates that : is only valid if a port is also specified.

See current behavior; I submit to you that this should generate an exception.

https://gist.github.com/anonymous/8504f160ff90649890b5a2a82f8028b0

--
components: Library (Lib)
messages: 282086
nosy: amrith
priority: normal
severity: normal
status: open
title: urlparse.urlparse() parses invalid URI without generating an error 
(examples provided)
type: behavior
versions: Python 2.7, Python 3.4

___
Python tracker 

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

[issue28427] WeakValueDictionary next bug (with multithreading)

[Antoine Pitrou]

Antoine Pitrou added the comment:

Here is a pure Python patch.

--
Added file: http://bugs.python.org/file45709/issue28427-3.patch

___
Python tracker 

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

[issue28427] WeakValueDictionary next bug (with multithreading)

[Antoine Pitrou]

Antoine Pitrou added the comment:

Note the issue with this patch is that it may keep keys (with dead values) 
alive longer than necessary:
- this may prevent memory consumption from decreasing
- this may keep alive some system resources

This is ok when keys are small simple objects (strings or tuples), though.

--

___
Python tracker 

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

[issue28841] urlparse.urlparse() parses invalid URI without generating an error (examples provided)

[SilentGhost]

Changes by SilentGhost :


--
nosy: +orsenthil
versions: +Python 3.5, Python 3.6, Python 3.7 -Python 3.4

___
Python tracker 

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

[issue28427] WeakValueDictionary next bug (with multithreading)

[Antoine Pitrou]

Antoine Pitrou added the comment:

Here is a patch showing the "atomic C function" approach.  It will avoid the 
aforementioned memory growth in the common case, in exchange for a small bit of 
additional C code.

--
Added file: http://bugs.python.org/file45710/issue28427-atomic.patch

___
Python tracker 

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

[issue28427] WeakValueDictionary next bug (with multithreading)

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
stage:  -> patch review

___
Python tracker 

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

[issue28840] IDLE not handling long lines correctly

[Terry J. Reedy]

Terry J. Reedy added the comment:

The lengths of the strings on the 3 lines are 644, 432, and 7728, as determined 
by adding 4th line to print them.  In Win10, the editor window shows.

MESSAGE_1 = '02 
MESSAGE_2 = 'Ag 
MESSAGE_1 = 

The problem is the blank after '=' on line 3.  If I put the cursor anywhere in 
the false blank, the line is filled in up to the cursor.

IDLE uses tkinter, which wraps tk.  It is known that tk Text widgets do not 
handle long lines well.  There is a previous issue (which I cannot find at the 
moment) about long lines (in Shell) making scrolling slow, Printing the third 
line in Shell, where long lines are wrapped, works.

I do not remember seeing this disappearing text problem before.  Putting the 
string without blanks on a line by itself, the limit for correct behavior (the 
beginning of the line appears when the file is freshly loaded) is 2730 chars, 
including the quotes.I guess no one inclined to report a problem has tried 
anything longer before.

The need for such long literals in a code file is unusual, but definitely 
legitimate for testing.  On stackoverflow, I constantly urge people to develop 
programs that read and parse data by putting sample data in the code file.  (If 
not in a separate test file.) The workaround for literals over 2728 chars is to 
use Python's implicit string literal concatenation.  For instance, "s = 'a' 'b' 
'c'" results in "s == 'abc'".  Using this, you could define your third string 
thusly:

m3 = (
''
''
''
''
) # 7728 chars

IDLE's column indicator makes this easy enough.

Not wrapping longs lines in the editor is intentional.  So is not adding a 
horizontal scrollbar (not my decision).  But if adding one solves this problem, 
I will reconsider.  In the meanwhile, I will consider a new IDLE doc section 
"2.6 Tkinter limitations", which could also mention non-display of astral 
characters.

--

___
Python tracker 

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

[issue28842] PyInstanceMethod_Type isn't hashable

[David Wolever]

New submission from David Wolever:

The PyInstanceMethod_Type, unlike all other method types, isn't hashable.

It seems like the code exists, it's just been commented out: 
https://github.com/python/cpython/blame/c30098c8c6014f3340a369a31df9c74bdbacc269/Objects/classobject.c#L569

This came up here: https://github.com/wolever/pprintpp/issues/18

And Christian Heimes doesn't remember why it was commented out: 
https://twitter.com/ChristianHeimes/status/803900655324790784

--
messages: 282091
nosy: wolever
priority: normal
severity: normal
status: open
title: PyInstanceMethod_Type isn't hashable
type: behavior
versions: Python 3.3, Python 3.4, 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

[issue28843] asyncio.Task implemented in C loses __traceback__ for exceptions

[Yury Selivanov]

New submission from Yury Selivanov:

When a coroutine wrapped in a C asyncio.Task raises an Exception, the Task 
fails to correctly save the __traceback__.

--
assignee: yselivanov
components: asyncio
files: task_tb.patch
keywords: patch
messages: 282092
nosy: gvanrossum, inada.naoki, ned.deily, yselivanov
priority: release blocker
severity: normal
status: open
title: asyncio.Task implemented in C loses __traceback__ for exceptions
versions: Python 3.6, Python 3.7
Added file: http://bugs.python.org/file45711/task_tb.patch

___
Python tracker 

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

[issue28791] update sqlite to 3.15.2

[Big Stone]

Big Stone added the comment:

I understand the decision. Yet it always baffles me that a version correcting 
known bugs is not included at beta stage.

--

___
Python tracker 

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

[issue28842] PyInstanceMethod_Type isn't hashable

[Josh Rosenberg]

Josh Rosenberg added the comment:

Note: It's a little strange that instancemethod as a type sticks around even 
though literally nothing in Python uses it. Is there some reason we kept it in 
the 3.x transition? Extension types are using it, so I guess we can't drop it 
now, but I'm trying to figure out why it was kept around, allowing the 
extensions to develop dependencies on it.

--
nosy: +josh.r

___
Python tracker 

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

[issue28839] _PyFunction_FastCallDict(): replace PyTuple_New() with PyMem_Malloc()

[Josh Rosenberg]

Josh Rosenberg added the comment:

Given you can't avoid the refcounting overhead, how much does this really help? 
Are there meaningful benefits in microbenchmarks? I'd worry that unconditional 
allocation from PyMem_Malloc might lose out relative to PyTuple_New, which is 
likely to not involve memory allocation at all (pulling from tuple free list).

--
nosy: +josh.r

___
Python tracker 

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

[issue28733] Show how to use mock_open in modules other that __main__

[Michał Bultrowicz]

Michał Bultrowicz added the comment:

Ok, I've checked again and now patching "file_writer.open" works. I have no 
idea what I was doing wrong the last time I checked... So I guess I'll close 
the issue.

--

___
Python tracker 

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

[issue28733] Show how to use mock_open in modules other that __main__

[Michał Bultrowicz]

Changes by Michał Bultrowicz :


--
status: open -> closed

___
Python tracker 

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

[issue28791] update sqlite to 3.15.2

[Steve Dower]

Steve Dower added the comment:

I don't think we have anyone actively tracking SQLite right now, like we do for 
OpenSSL.

All it really needs is someone to prepare and test the patch during the beta 
period, and to be available in case more fixes are required. At this stage, 
we're in the RC period, so there really needs to be a recall-level issue to 
justify a change, and even then we'd prefer a maintenance update rather than a 
feature update (e.g. 3.14.3 vs. 3.15.x - if it's not a recall-level issue for 
SQLite, then it's hard to call it a recall-level issue for Python).

--

___
Python tracker 

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

[issue28839] _PyFunction_FastCallDict(): replace PyTuple_New() with PyMem_Malloc()

[Josh Rosenberg]

Josh Rosenberg added the comment:

Minor correction: No allocation when small stack used, so you'd only see 
(possibly) regressions with 6+ keyword arguments (assuming the tuple free list 
applies for tuples that large). Admittedly a minor concern; keyword processing 
is already pretty slow, and large numbers of keywords being passed are likely a 
tiny fraction of call cases, so I'd guess microbenchmarks wouldn't show a big 
change, and broad benchmarks would be completely unaffected, but worth checking.

--

___
Python tracker 

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

[issue28844] Pickling units

[Adam]

New submission from Adam:

See below code to show you can't round-trip units through pickle:

Python 3.5.1 |Anaconda 4.0.0 (64-bit)| (default, Feb 16 2016, 09:49:46) [MSC 
v.1900 64 bit AMD64)]
import units
u = units.unit('myUnit')
x = u(3.0)
import pickle
f = open('C:/temp/what.pkl', 'wb')
pickle.dump(x, f)
f.close()
f = open('C:/temp/what.pkl', 'rb')
y = pickle.load(f)
---
TypeError Traceback (most recent call last)
 in ()
> 1 y = pickle.load(f)

TypeError: __new__() missing 2 required positional arguments: 'num' and 'unit'

--
messages: 282099
nosy: abz64
priority: normal
severity: normal
status: open
title: Pickling units
type: behavior
versions: Python 3.5

___
Python tracker 

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

[issue28844] Pickling units

[R. David Murray]

R. David Murray added the comment:

unit is not part of the stdlib.  Please report this to whatever the upstream is 
for the package and/or to Anaconda.

--
nosy: +r.david.murray
resolution:  -> third party
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

[issue28844] Pickling units

[R. David Murray]

R. David Murray added the comment:

To clarify: it looks from your report like units hasn't implemented pickling 
support.  It isn't automatic for all classes.

--

___
Python tracker 

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

[issue28742] argparse.ArgumentDefaultsHelpFormatter sometimes provides inaccurate documentation of defaults, so they should be overrideable

[Peter Eckersley]

Peter Eckersley added the comment:

Thanks for your feedback Paul! I agree your proposed implementation strategy 
would probably be saner; I'll revise the patch to use that approach or 
something like it.

As for the question of necessity, there are definitely more cases than just the 
store_false ones -- I documented these in the linked Certbot bug but very 
briefly they include:

* Programs where the default value of a variable is "Ask interactively" if no 
flag is provided
* Cases where the default value is the result of some complicated computation 
(for instance, reading it from a defaults file)

--

___
Python tracker 

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

[issue28833] cross compilation of third-party extension modules

[Xavier de Gaye]

Xavier de Gaye added the comment:

> I don't think that identifying the target by some path is the right way to 
> go, and you should be able to identify the target by giving the target 
> triplet as used by the configure parameters and then deduce the location from 
> the target (or have an explicit location given).
> 
> The idea here is to use the platform identifier which we already had in the 
> trunk before the PLATDIR was removed (the multiarch id or if not defined the 
> platform). So by having a  specifier, you could deduce a path, or a 
> -python-config executable and you're done. No need to know about a 
> path directly.  Of course python cross builds would have to install the 
> -python-config executable or symlink.

Hum, you still need to provide the native python interpreter with the _path_ to 
the -python-config executable that can be anywhere on the file system 
(its location is relative to the cross compiled build, not the native 
interpreter), so it seems that this contradicts your previous sentence saying 
"I don't think that identifying the target by some path is the right way to go".

--

___
Python tracker 

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

[issue28833] cross compilation of third-party extension modules

[Xavier de Gaye]

Xavier de Gaye added the comment:

So I suggest we start with this patch as it works for:
* The standard library extension modules (for debian as well).
* The third-party extension modules on platforms that have multiarch defined 
and on platforms that do not have multiarch defined (on debian systems one can 
only use the build directory for XBUILD_PYTHON_DIR, the other systems can use 
the three options described in msg281993).

Then we can later extend the semantics of XBUILD_PYTHON_DIR to include the 
multiarch triplet if this is necessary for debian systems, unless the debian 
developers want to continue using the system they have developed and are 
currently using to cross compile third-party extension modules.

--

___
Python tracker 

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

[issue28845] Clean up known issues for AIX

[Eric N. Vander Weele]

New submission from Eric N. Vander Weele:

This patch cleans up Misc/README.AIX for addressed known issues.

Issues that have been marked fixed: #11184, #11185
Issues resolved by new AIX version: #1745108
Issues resolved, but not yet marked fixed/closed: #11188

Additionally, it looks like #10709 can be closed out as well.

For #1745108 and #11188, I have verified they are addressed as of Python 3.5.2 
on AIX 7.1 locally.  The Python Buildbot is failing to build the curses module, 
but I believe Setup.local is needed for _curses and _curses_panel.  I have 
gotten the aforementioned curses modules building locally and will figure out 
the appropriate channels getting Python's PPC64 AIX Buildbot updated 
independently.

--
assignee: docs@python
components: Documentation
files: cleanup-readme-aix.patch
keywords: patch
messages: 282105
nosy: David.Edelsohn, docs@python, ericvw
priority: normal
severity: normal
status: open
title: Clean up known issues for AIX
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file45712/cleanup-readme-aix.patch

___
Python tracker 

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

[issue28845] Clean up known issues for AIX

[Zachary Ware]

Changes by Zachary Ware :


--
nosy: +Michael.Felt
stage:  -> patch review
versions:  -Python 3.3, Python 3.4

___
Python tracker 

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

[issue28755] Rework syntax highlighing in howto/clinic.rst

[Julien Palard]

Julien Palard added the comment:

Bump, 10 days later, hope this diff is still straightforward to merge.

--

___
Python tracker 

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

[issue10444] A mechanism is needed to override waiting for Python threads to finish

[Julien Palard]

Julien Palard added the comment:

If nobody has nothing to add on this issue, I think it just should be closed.

--

___
Python tracker 

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

[issue26363] __builtins__ propagation is misleading described in exec and eval documentation

[Julien Palard]

Julien Palard added the comment:

Hi Xavier,

> It is not the dictionary of builtin module, which is inserted in , but the 
> current __builtin__ global 

It looks wrong, I'll even say the exact contrary: It _is_ the dictionary of 
builtin module which is inserted in, not the current __builtin__ global, with 
this proof:

$ ./python
Python 3.7.0a0 (default, Nov 29 2016, 11:20:17) 
[GCC 5.4.1 20161019] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> print(id(__builtins__), id(__builtins__.__dict__))
140325888797784 14032540368
>>> eval("""print(id(__builtins__))""", {})
14032540368


> the current __builtin__ global which happen to be normally the dictionnary of 
> builtin.

That's not necessarily true, according to [the builtins 
doc](https://docs.python.org/dev/library/builtins.html):

> The value of __builtins__ is normally either this module or the value of this 
> module’s __dict__ attribute.

Typically:
$ ./python
Python 3.7.0a0 (default, Nov 29 2016, 11:20:17) 
[GCC 5.4.1 20161019] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import builtins
>>> id(builtins), id(builtins.__dict__), id(__builtins__)
(139706743340120, 139706743382704, 139706743340120)

Here, __builtins__ is the module, not its dict.

--

___
Python tracker 

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

[issue28845] Clean up known issues for AIX

[Julien Palard]

Julien Palard added the comment:

You're also removing:

> * Python has not been fully tested on AIX when compiled as a 64 bit
>   application.

I do not have an AIX at hand but can someone at least confirm that all test 
passes? Having a few issues fixed does not mean that Python has been fully 
tested.

--
nosy: +mdk

___
Python tracker 

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

[issue20185] Derby #17: Convert 49 sites to Argument Clinic across 13 files

[Julien Palard]

Julien Palard added the comment:

Look like this has never been applied, any reason for this?

Tip has probably highly diverged, but I may try to rebase it, should I?

--
nosy: +mdk

___
Python tracker 

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

[issue2771] Test issue

[Ezio Melotti]

Ezio Melotti added the comment:

Testing PR linking

--
pull_requests: +1

___
Python tracker 

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

[issue28845] Clean up known issues for AIX

[Eric N. Vander Weele]

Eric N. Vander Weele added the comment:

> Having a few issues fixed does not mean that Python has been fully tested.

I uploaded cleanup-readme-aix2.patch, which revives back the line removed in 
question and only removes lines which reference issues.

I just noticed the results of Python's tests on my AIX box differ from Python's 
PPC64 Buildbot.  I'll investigate separately and submit patches for getting the 
tests to pass, which then it may be more appropriate to remove that line.

--
Added file: http://bugs.python.org/file45713/cleanup-readme-aix2.patch

___
Python tracker 

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

[issue17490] Improve ast.literal_eval test suite coverage

[Julien Palard]

Julien Palard added the comment:

> I also discovered several holes in the test suite coverage while refactoring 
> it.

Are they all tested in the current diff?

--
nosy: +mdk

___
Python tracker 

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

[issue28845] Clean up known issues for AIX

[Julien Palard]

Julien Palard added the comment:

Look like issue1745108 has only be closed for being "outdated" (msg240919 ), it 
does not clearly mean that the bug does no longer exists.

Have you been able to test the example in it?

--

___
Python tracker 

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

[issue28838] Uniformize argument names of "call" functions (C API)

[Eric V. Smith]

Eric V. Smith added the comment:

Isn't this just a lot of churn for not a lot of benefit? I'm all for 
consistency, but you'll break patches on the bug tracker and externally 
maintained patches.

--
nosy: +eric.smith

___
Python tracker 

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

[issue28841] urlparse.urlparse() parses invalid URI without generating an error (examples provided)

[Eric V. Smith]

Eric V. Smith added the comment:

Can you please paste your code into a comment on this issue? Gist content has a 
habit of vanishing. Thanks!

--
nosy: +eric.smith

___
Python tracker 

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

[issue28841] urlparse.urlparse() parses invalid URI without generating an error (examples provided)

[Amrith Kumar]

Amrith Kumar added the comment:

As requested ...

>>> urlparse.urlparse('http://www.google.com:/abc')
ParseResult(scheme='http', netloc='www.google.com:', path='/abc', params='', 
query='', fragment='')

I submit to you that this should generate an error.

--

___
Python tracker 

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

[issue28846] Add a ProviderKey to the installer bundle

[Steve Dower]

New submission from Steve Dower:

Currently the installer bundles for 3.5 and later have an automatically 
generated dependency provider key. This makes it difficult for other installers 
to correctly depend on the bundle.

For example, Visual Studio 2017 has an option to install CPython 3.5, but it 
cannot accurately determine when it is already installed, which may lead to 
Python being uninstalled unexpectedly. This is the purpose of the provider key 
- to provide a reliable key by which to reference the bundle.

For 3.5.2 and earlier, the key is a GUID that changes each release, but really 
the key should be stable for each version that cannot be installed side-by-side.

The change is to Tools/msi/bundle/bundle.wxs and adds the last attribute to 
this element:

  http://www.python.org/";
  DisableModify="button"
  Compressed="no"
  
dep:ProviderKey="CPython-$(var.MajorVersionNumber).$(var.MinorVersionNumber)$(var.PyArchExt)$(var.PyTestExt)">

This will produce keys like "CPython-3.5", "CPython-3.5-32", "CPython-3.5-test" 
and "CPython-3.5-32-test" (the "-test" suffixed installers are never released, 
but may be produced by Tools/msi/build.bat).

I haven't tested it yet, but I believe this change will also fix a minor issue 
where the web and non-web installers conflict, even when the versions match.

Since it is important this metadata be consistent throughout the lifetime of a 
release, I'd like to get the change into Python 3.6.0rc1 after I've spent the 
time testing it. Ned - your thoughts?

--
assignee: steve.dower
components: Windows
messages: 282118
nosy: ned.deily, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Add a ProviderKey to the installer bundle
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

[issue28841] urlparse.urlparse() parses invalid URI without generating an error (examples provided)

[Martin Panter]

Martin Panter added the comment:

The Python documentation refers to RFC 3986, which allows an empty port string 
introduced by a colon, although it recommends against it: 


The “port” subcomponent of “authority” is designated by an optional port number 
in decimal following the host and delimited from it by a single colon. . . . 
URI producers and normalizers should omit the port component and its “:” 
delimiter if “port” is empty . . .

What problem are you trying to solve by raising an error?

See also Issue 20059, where accessing the “port” field now raises ValueError 
for out-of-range values, and Issue 20271, discussing invalid URL handling more 
generally.

--
nosy: +martin.panter

___
Python tracker 

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

[issue28841] urlparse.urlparse() parses invalid URI without generating an error (examples provided)

[Martin Panter]

Martin Panter added the comment:

Also, this is in direct contradiction to Issue 20270.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue28820] Typo in section 6 of the Python 3.4 documentation

[Berker Peksag]

Berker Peksag added the comment:

Ned can correct me if I'm wrong, but you can push documentation patches without 
waiting for 3.6.0rc1.

--
nosy: +berker.peksag

___
Python tracker 

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

[issue28841] urlparse.urlparse() parses invalid URI without generating an error (examples provided)

[Eric V. Smith]

Eric V. Smith added the comment:

And note that there are tests that explicitly check that the colon with no port 
works (via issue 20270).

Given that this behavior has been around for a while, and is explicitly 
allowed, I would recommend against changing this to an error.

--

___
Python tracker 

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

[issue28755] Rework syntax highlighing in howto/clinic.rst

[Martin Panter]

Martin Panter added the comment:

It will apply to the 3.5 and 3.6 branches if I first backport revision 
0a18d2cfeb52 (Issue 28753), which I think is valid. But I would wait until 
there is a branch for 3.6.1, and then commit to all three branches. (Ned asked 
for only release-critical changes to go into 3.6 at the moment.)

On the other hand, Larry only applied the other patch to 3.7, so we could just 
do that again if people prefer.

--
nosy: +martin.panter
stage:  -> commit review
versions: +Python 3.5 -Python 2.7

___
Python tracker 

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

[issue28771] Update documented signatures of tp_get/setattr

[Roundup Robot]

Roundup Robot added the comment:

New changeset 2fd070fa6c15 by Martin Panter in branch '2.7':
Issue #28771: Correct documentation of signatures using const
https://hg.python.org/cpython/rev/2fd070fa6c15

--
nosy: +python-dev

___
Python tracker 

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

[issue28728] test_host_resolution in test_socket fails

[Martin Panter]

Martin Panter added the comment:

Maybe you could factor out the first part of test_bad_address() that skips the 
test. It would only need to be used by negative test cases (that purposefully 
test invalid names). I presume positive tests would not need to be wrapped.

--

___
Python tracker 

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

[issue28815] test_socket fails if /proc/modules is existent but not readable

[Martin Panter]

Martin Panter added the comment:

This seems reasonable in general.

Did you test this exact patch Patrila? It looks to me like you need to change 
ENOENT → errno.ENOENT, etc.

--
components: +Tests
nosy: +martin.panter
stage:  -> patch review
type:  -> behavior
versions:  -Python 3.3, Python 3.4

___
Python tracker 

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

[issue28846] Add a ProviderKey to the installer bundle

[Ned Deily]

Ned Deily added the comment:

Sounds good to me.

--

___
Python tracker 

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

[issue28820] Typo in section 6 of the Python 3.4 documentation

[Ned Deily]

Ned Deily added the comment:

Yes, there is no restriction on doc changes at the moment as long as they are 
relevant to 3.6.0.

--
nosy: +ned.deily

___
Python tracker 

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

[issue28841] urlparse.urlparse() parses invalid URI without generating an error (examples provided)

[Amrith Kumar]

Amrith Kumar added the comment:

Eric, Martin,

I'm sure this is an interpretation (and I'll be fair and give you both) that a 
URL of the form:

http://hostname.domain.tld:/path

should be held invalid. The rationale is per the section of the spec you quoted.

The other side of the argument is that the hostname and port are defined as:

hostname [ : port ] 

where port is defined as

*DIGIT

This implies that 0 digits is also valid.

I submit to you that the ambiguity would be removed if they:

- removed the paragraph telling people not to emit a : if there was no port, or
- changing the port definition to 1*DIGIT

Absent that, I believe that the paragraph implies that the intent was 1*DIGIT.

And therefore a : with no following number should generate an error.

I raise this because the behavior of urlparse() (the way it does things now) is 
being cited as the reason why other routines in OpenStack should handle this 
when the reason we were getting URL's with a : and no port was in fact an 
oversight.

So, in hearing the rationalization as being that "urlparse() does it, so ..." I 
figured I'd come to the source and see if we could make urlparse() do things 
unambiguously.

Now, if the reason it does this is because someone who came before me made the 
argument that a : with no port should be accepted, I guess I'm out of luck.

--

___
Python tracker 

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

[issue28837] 2to3 does not wrap zip correctly

[Xiang Zhang]

Changes by Xiang Zhang :


--
nosy: +benjamin.peterson
versions: +Python 3.6, Python 3.7 -Python 3.4

___
Python tracker 

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

[issue26483] docs unclear on difference between str.isdigit() and str.isdecimal()

[Martin Panter]

Martin Panter added the comment:

“digits which do not form decimal radix forms”

I see you have taken this from a Unicode document, but “forming a form” seems a 
long way of saying very little. The difference seems a bit vague, but I gather 
that digits not in the Unicode “decimal digit” category are often (always?) 
still decimal digits, but primarily used for a symbolic or typographical 
meaning more than in a plain number, e.g. superscripts, subscripts and other 
fonts, added circles and other decorations.

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

[issue28728] test_host_resolution in test_socket fails

[Xiang Zhang]

Changes by Xiang Zhang :


Added file: http://bugs.python.org/file45714/test_host_resolution.patch

___
Python tracker 

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

[issue26363] __builtins__ propagation is misleading described in exec and eval documentation

[Eryk Sun]

Eryk Sun added the comment:

As shown above, exec and eval default to calling PyEval_GetBuiltins when the 
globals dict doesn't define '__builtins__'. PyEval_GetBuiltins uses the current 
frame's f_builtins. If there isn't a current frame, it defaults to the 
interpreter's builtins, which should be the dict of the builtins module. 

If exec and eval didn't do this, the default behavior would be to create a 
minimal f_builtins dict for the new frame. This dict only contains a reference 
to None, and it doesn't get set as '__builtins__' in globals. For example:

from inspect import currentframe
from ctypes import pythonapi, py_object
g = py_object({'currentframe': currentframe})
code = py_object(compile('currentframe()', '', 'eval'))
frame = pythonapi.PyEval_EvalCode(code, g, g)

>>> frame.f_builtins
{'None': None}
>>> frame.f_globals
{'currentframe': }

This minimalist default isn't useful in general. exec and eval are saving 
people from the tedium of having to manually define a useful __builtins__ when 
passing a new globals. The frame object uses this __builtins__ to initialize 
its f_builtins. Also, it knows to look for __builtins__ as a module, as used by 
__main__:

g = py_object({'currentframe': currentframe, '__builtins__': __builtins__})
frame = pythonapi.PyEval_EvalCode(code, g, g)

>>> frame.f_builtins is vars(__builtins__)
True

--
nosy: +eryksun

___
Python tracker 

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

[issue28847] dumbdbm should not commit if

[Jonathan Ng]

Changes by Jonathan Ng :


--
nosy: Jonathan Ng
priority: normal
severity: normal
status: open
title: dumbdbm should not commit if
type: behavior

___
Python tracker 

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

[issue17490] Improve ast.literal_eval test suite coverage

[Nick Coghlan]

Nick Coghlan added the comment:

I don't know if the suggested test suite diff gives full coverage, but unless 
other improvements have been made to those tests in the meantime, it should 
give more coverage than we have right now.

--

___
Python tracker 

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

[issue28847] dumbdbm should not commit if in read mode

[Jonathan Ng]

New submission from Jonathan Ng:

Or at the very least, if there is an OSError in _update, an error should be 
raised instead of ignoring this error. 

In the current state of the code, if there was an OSError while reading the 
dirfile, the dirfile would be overwritten with a blank file when it is closed.

--
title: dumbdbm should not commit if -> dumbdbm should not commit if in read mode

___
Python tracker 

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

[issue28728] test_host_resolution in test_socket fails

[Martin Panter]

Martin Panter added the comment:

I think the original test is trying to ensure that an invalid numeric IP 
address results in an OSError. So changing it to skip the test on OSError does 
not seem wise. Also, Silent Ghost said that the problem was with 
gethostbyaddr(), not gethostbyname().

I was wondering if there was a separate way to detect the troublesome ISP 
environment, e.g. trying gethostbyname(bogus_domain).

--

___
Python tracker 

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

[issue28841] urlparse.urlparse() parses invalid URI without generating an error (examples provided)

[R. David Murray]

R. David Murray added the comment:

Yes, I'm afraid so.  But the rationale is presumably the same as it is in many 
RFCs: you should accept broken stuff if it can be interpreted unambiguously, 
but you should not *produce* the broken stuff.  So I'd say the RFC is correct 
as quoted.  It is then up to openstack whether or not it wants to accept such 
URLs in a given interface, and it if were me I'd base that decision on whether 
it was an 'internal' interface or an 'external' one.  But you can also argue 
that even an external interface could be strict, depending on the application 
domain of the interface.  urllib, on the other hand, needs to accept it, and we 
can't change it at this point for backward compatibility reasons if nothing 
else.

Based on the RFC, one could argue that urlunsplit should omit the colon.  That 
could break backward compatibility, too, though will a lot less likelyhood.  So 
we could still fix it in 3.7 if we decide we should.

--
nosy: +r.david.murray

___
Python tracker 

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

[issue28848] Add CopyingMock to mock.py

[wim glenn]

New submission from wim glenn:

Would people be interested to consider adding the CopyingMock example shown in 
the documentation section "coping with mutable arguments" into the mock module?

https://docs.python.org/3/library/unittest.mock-examples.html#coping-with-mutable-arguments
 

It seems like a useful and simple enough feature to add.

--
components: Library (Lib)
messages: 282136
nosy: wim.glenn
priority: normal
severity: normal
status: open
title: Add CopyingMock to mock.py
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

[issue28848] Add CopyingMock to mock.py

[wim glenn]

wim glenn added the comment:

Here's a first attempt at a patch.  

If it doesn't go into Lib finally, I'll just put up a CopyingMock on pypi 
instead.  But it seemed like the kind of feature which should just be in mock 
directly rather than 3rd party, preferably.

--
keywords: +patch
Added file: http://bugs.python.org/file45715/copying_mock.diff

___
Python tracker 

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

[issue28728] test_host_resolution in test_socket fails

[Xiang Zhang]

Xiang Zhang added the comment:

Ohh, sorry.

> I was wondering if there was a separate way to detect the troublesome ISP 
> environment.

How could you differentiate the failure between ISP environment caused and 
function behaved wrongly? Successfully resolve an invalid ip address doesn't 
mean you can successfully resolve a bogus domain.

I think this case should be rare. Maybe we can just fail the test and warn the 
user this failure is not 100% caused by function's misbehaviour, just like 
test_bad_address.

--
Added file: http://bugs.python.org/file45716/test_host_resolution-v2.patch

___
Python tracker 

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

[issue27647] Update Windows build to Tcl/Tk 8.6.6

[Benjamin Peterson]

Benjamin Peterson added the comment:

I don't mind if it gets updated.

On Wed, Nov 30, 2016, at 00:01, Serhiy Storchaka wrote:
> 
> Serhiy Storchaka added the comment:
> 
> Why not? 8.5.15 is 3 years old. There were 4 bugfix releases since it.
> 
> --
> 
> ___
> Python tracker 
> 
> ___

--

___
Python tracker 

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