[issue29723] 3.6.1rc1 adds the current directory to sys.path when running a subdirectory's __main__.py; previous versions did not

[Nick Coghlan]

Nick Coghlan added the comment:

So a potentially more robust fix here would be to always call 
`PySys_SetArgVEx(argc, argv, 0)` rather than the plain `PySys_SetArgV` when we 
know we're going to be relying on RunMainFromImporter.

That way RunMainFromImporter could just *always* insert at the front, and not 
have to try to guess whether or not a different sys.path[0] entry had already 
been populated.

This would involve splitting RunMainFromImporter into two pieces (one to check 
whether the given filename is a valid sys.path entry, the second to actually 
modify sys.path and run __main__), but that's entirely feasible.

--

___
Python tracker 

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

[issue29723] 3.6.1rc1 adds the current directory to sys.path when running a subdirectory's __main__.py; previous versions did not

[Nick Coghlan]

Nick Coghlan added the comment:

Ah, interesting, I didn't know there was a difference between the platforms in 
when the placeholder got resolved to a full path.

However, after browsing the code and running some local tests, it seems that 
injecting sys.path[0] isn't handled by Py_GetPath() or PySys_SetPath(), 
regardless of OS.

Instead, it's handled as a side effect of calling PySys_SetArgV(), with 
PySys_SetArgVEx() adding a flag to disable the side effect (for the benefit of 
the isolated mode implementation).

The actual side effect itself is implemented in sys_update_path: 
https://github.com/python/cpython/blob/3.6/Python/sysmodule.c#L2162

So in the case of running `./python Tools` (which exercises the paths of 
interest here) with some strategically placed printf() and PySys_FormatStdout() 
calls, I get:

```
$ ./python Tools
module_search_path: 
/usr/local/lib/python36.zip:/home/ncoghlan/devel/py36/Lib:/home/ncoghlan/devel/py36/Lib:/home/ncoghlan/devel/py36/build/lib.linux-x86_64-3.6
sys.path[0]: '/home/ncoghlan/devel/py36'
sys.path: ['/home/ncoghlan/devel/py36', '/usr/local/lib/python36.zip', 
'/home/ncoghlan/devel/py36/Lib', 
'/home/ncoghlan/devel/py36/build/lib.linux-x86_64-3.6', 
'/home/ncoghlan/.local/lib/python3.6/site-packages']
/home/ncoghlan/devel/py36/python: can't find '__main__' module in 'Tools'
```

The first line is from `Py_GetPath()`, the second is from `sys_update_path()`, 
the third is from `RunMainFromImporter` (before it makes any sys.path changes), 
and the last is the expected error because our `Tools` directory isn't 
executable.

In this scenario, we want the "Tools" entry to *overwrite* sys.path[0].

While in isolated mode I get:

```
$ ./python -I Tools
module_search_path: 
/usr/local/lib/python36.zip:/home/ncoghlan/devel/py36/Lib:/home/ncoghlan/devel/py36/Lib:/home/ncoghlan/devel/py36/build/lib.linux-x86_64-3.6
sys.path: ['/usr/local/lib/python36.zip', '/home/ncoghlan/devel/py36/Lib', 
'/home/ncoghlan/devel/py36/build/lib.linux-x86_64-3.6']
/home/ncoghlan/devel/py36/python: can't find '__main__' module in 'Tools'
```

In this scenario, we want the "Tools" entry to be inserted *before* sys.path[0].

Note that this has been buggy since the -I switch was introduced, but the entry 
we've been overwriting has been the one for the stdlib-as-a-zip-archive, so it 
didn't cause any problems for anyone using the default directory-based 
installation layout.

However, we can't reliably figure out which to do based on the contents of 
sys.path, we need to look at Py_IsolatedFlag instead. (I'm not sure why the 
current check is working on Windows, as sys_update_path() attempts to resolve 
an absolute path entry from the archive or directory name there as well)

--

___
Python tracker 

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

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

[Xiang Zhang]

Xiang Zhang added the comment:

Any reason our _Py_stat_struct on Windows uses a signed type to represent 
st_ino?

--
nosy: +eryksun, steve.dower

___
Python tracker 

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

[issue29753] Ctypes Packing Incorrectly - Linux

[Eryk Sun]

Changes by Eryk Sun :


--
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

[issue29753] Ctypes Packing Incorrectly - Linux

[Eryk Sun]

Eryk Sun added the comment:

To make it simpler to diagram the fields, I've rewritten your structure using 
field names A-J:

import ctypes

class MyStructure(ctypes.Structure):
_pack_ = 1
_fields_ = (('A', ctypes.c_uint16), # 2 bytes
('B', ctypes.c_uint16, 9),
('C', ctypes.c_uint16, 1),
('D', ctypes.c_uint16, 1),
('E', ctypes.c_uint16, 1),
('F', ctypes.c_uint16, 1),
('G', ctypes.c_uint16, 3),  # 4 bytes
('H', ctypes.c_uint32, 10),
('I', ctypes.c_uint32, 20),
('J', ctypes.c_uint32, 2))  # 8 bytes

ctypes is attempting to extend the bitfield for H by switching to a c_uint 
storage unit with an offset of 2 bytes and adding H field with a 16-bit offset:

>>> MyStructure.H


Here's the correct layout:

| uint16| uint16|uint32 
|--16---|--16---|---10|20-|-
A---BCDEFG--H-I---J-

and here's the layout that ctypes creates, which wastes 2 bytes:

| uint32|
| uint16| uint16|   | uint32


|--16---|--16---|---10|--6--|20-|-|---10

A---BCDEFG--H---I---J---

The current strategy for extending bitfields to work like gcc on Linux is 
obviously failing us here. Hopefully someone can flesh out the exact rules to 
make this code accurate. Bitfields are such a pain.

--
nosy: +eryksun

___
Python tracker 

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

[issue29753] Ctypes Packing Incorrectly - Linux

[Charles Machalow]

Charles Machalow added the comment:

Some more debug with print statements in the c code seems to confirm my 
suspicion:

bitsize, pfield_size, bitofs, dict->size prints were added just above the if 
chain to determine fieldtype and fieldtype was just after that if chain. That 
code looks something like this:

printf("bitsize: %d\n" , (int)bitsize);
printf("pfield_size: %u\n", (size_t)*pfield_size);
printf("bitofs: %d\n", (int)*pbitofs);
printf("dict->size: %d\n", (int)dict->size);
if (bitsize /* this is a bitfield request */
&& *pfield_size /* we have a bitfield open */
#ifdef MS_WIN32
/* MSVC, GCC with -mms-bitfields */
&& dict->size * 8 == *pfield_size
#else
/* GCC */
&& dict->size * 8 <= *pfield_size
#endif
&& (*pbitofs + bitsize) <= *pfield_size) {
/* continue bit field */
fieldtype = CONT_BITFIELD;
#ifndef MS_WIN32
} else if (bitsize /* this is a bitfield request */
&& *pfield_size /* we have a bitfield open */
&& dict->size * 8 >= *pfield_size
&& (*pbitofs + bitsize) <= dict->size * 8) {
/* expand bit field */
fieldtype = EXPAND_BITFIELD;
#endif
} else if (bitsize) {
/* start new bitfield */
fieldtype = NEW_BITFIELD;
*pbitofs = 0;
*pfield_size = dict->size * 8;
} else {
/* not a bit field */
fieldtype = NO_BITFIELD;
*pbitofs = 0;
*pfield_size = 0;
}

printf("Fieldtype: %d\n--\n", fieldtype);

And the run with the custom-built Python 2.7.13:

>>> from test import *
bitsize: 0
pfield_size: 0
bitofs: 255918304
dict->size: 2
Fieldtype: 0
--
bitsize: 9
pfield_size: 0
bitofs: 0
dict->size: 2
Fieldtype: 1
--
bitsize: 1
pfield_size: 16
bitofs: 9
dict->size: 2
Fieldtype: 2
--
bitsize: 1
pfield_size: 16
bitofs: 10
dict->size: 2
Fieldtype: 2
--
bitsize: 1
pfield_size: 16
bitofs: 11
dict->size: 2
Fieldtype: 2
--
bitsize: 1
pfield_size: 16
bitofs: 12
dict->size: 2
Fieldtype: 2
--
bitsize: 3
pfield_size: 16
bitofs: 13
dict->size: 2
Fieldtype: 2
--
bitsize: 10
pfield_size: 16
bitofs: 16
dict->size: 4
Fieldtype: 3
--
bitsize: 20
pfield_size: 32
bitofs: 26
dict->size: 4
Fieldtype: 1
--
bitsize: 2
pfield_size: 32
bitofs: 20
dict->size: 4
Fieldtype: 2
--
10
>>> MyStructure.P

>>> MyStructure.T

>>> MyStructure.R

>>> MyStructure.P

>>> MyStructure.L

>>> MyStructure.Pro

>>> MyStructure.R

>>> MyStructure.T

>>> MyStructure.C


--

___
Python tracker 

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

[issue17441] Do not cache re.compile

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
resolution:  -> rejected
stage: patch 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

[issue20087] Mismatch between glibc and X11 locale.alias

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Not all platforms use glibc 2.24 as libc.

Ideally most of entries should even not exist. We should ask libc for the 
default encoding if it is not included in the locale name. The aliases table 
should be used only for mapping commonly used but unsupported by libc locales 
to supported by libc locales.

--

___
Python tracker 

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

[issue29753] Ctypes Packing Incorrectly - Linux

[Charles Machalow]

Charles Machalow added the comment:

Took a quick look at the c code for this. The area at fault appears to be this 
section in cfield.c:

#ifndef MS_WIN32
} else if (bitsize /* this is a bitfield request */
&& *pfield_size /* we have a bitfield open */
&& dict->size * 8 >= *pfield_size
&& (*pbitofs + bitsize) <= dict->size * 8) {
/* expand bit field */
fieldtype = EXPAND_BITFIELD;
#endif

The problem seems to be after the end of the 2nd c_uint16, it seems to think 
that the next 10 bytes should extend that c_uint16 to a c_uint32 instead of 
taking the type as the beginning of a new c_uint32. So I guess it is making the 
structure something like this:

  ("P",   c_uint16),
  ("L",   c_uint32, 9),
  ("Pro", c_uint32, 1),
  ("G",   c_uint32, 1),
  ("IB",  c_uint32, 1),
  ("IR",  c_uint32, 1),
  ("R",   c_uint32, 3),
  ("T",   c_uint32, 10),
  # And now this needs an extra 6 bits of padding to fill 
the c_uint32
  ("C",   c_uint32, 20),
  ("R2",  c_uint32, 2)
  # And now this needs an extra 10 bits of padding to fill 
the c_uint32.

I guess that is how we get to 10... instead of the expected 8 bytes. I don't 
believe that this behavior is desired nor really makes logical sense.

--

___
Python tracker 

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

[issue29723] 3.6.1rc1 adds the current directory to sys.path when running a subdirectory's __main__.py; previous versions did not

[Eryk Sun]

Eryk Sun added the comment:

> It's actually "adding" the current directory

It's the script directory, which gets added on all platforms when PySys_SetArgv 
is called with Py_IsolatedFlag == 0. In this case we're running "__main__.py" 
from a directory or zip file, and we don't want its parent directory in 
sys.path.

> The behavior on Windows is correct 

Here's what I see on a current build of 3.6:

C:\Temp>python_d -i main361
>>> import sys
>>> sys.version
'3.6.0+ (default, Mar  8 2017, 06:51:22) [MSC v.1900 64 bit (AMD64)]'
>>> sys.path[:2]
['main361', 'C:\\Temp']

C:\Temp doesn't belong in sys.path in this case. When we're not in isolated 
mode, RunMainFromImporter should set the __main__.py import source as index 0 
rather than insert it.

--

___
Python tracker 

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

[issue29514] Add a test case that prevents magic number changes in minor releases

[Nick Coghlan]

Nick Coghlan added the comment:

I just merged 
https://github.com/python/cpython/commit/93602e3af70d3b9f98ae2da654b16b3382b68d50
 as the fix for issue #29537, so 3.5.4+ should handle legacy bytecode files 
without any complaints (and redistributors can backport it to 3.5.3 as needed).

For *this* issue, the main requested change to the proposed test case is to 
simplify it to use Serhiy's suggested approach: just define a single 
"EXPECTED_MAGIC_NUMBER" in the test suite, and have that be different on 
different maintenance branches.

For branches in alpha and beta phase, the test case should be skipped with a 
message like "Bytecode stability is not checked in alpha & beta releases"

--
stage:  -> patch review
type:  -> enhancement

___
Python tracker 

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

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

[Benjamin Peterson]

Changes by Benjamin Peterson :


--
pull_requests: +457

___
Python tracker 

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

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

[Benjamin Peterson]

Changes by Benjamin Peterson :


--
pull_requests: +456

___
Python tracker 

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

[issue29537] Alternative fix for BUILD_MAP_UNPACK_WITH_CALL opcode in 3.5

[Nick Coghlan]

Nick Coghlan added the comment:

Merged (with test cases) in 
https://github.com/python/cpython/commit/93602e3af70d3b9f98ae2da654b16b3382b68d50

The test cases even cover ensuring the backwards compatibility also applies to 
frozen bytecode :)

--
resolution:  -> fixed
stage: patch 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

[issue20087] Mismatch between glibc and X11 locale.alias

[Benjamin Peterson]

Benjamin Peterson added the comment:

Why is the X11 locale alias map used at all? It seems like it can only create 
confusion with libc.

--
nosy: +benjamin.peterson

___
Python tracker 

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

[issue29754] sorted ignores reverse=True when sorting produces same list

[Tim Peters]

Tim Peters added the comment:

Your last line can't possibly return True, because `somelist.reverse()` returns 
None.

So the last line is irrelevant.  Your complaint appears to be about the line 
before, which shows that the list retains its original order.

That's expected.  All the keys are equal, so a stable sort _must_ retain the 
original order (that's what "stable" means).  So that's not a bug - it's a 
feature.

The idea that `x.sort(reverse=True)` must do the same as `x.sort(); 
x.reverse()` is something you made up in your head ;-)  That is, the docs don't 
say that.  What they do say:

"""
reverse is a boolean value. If set to True, then the list elements are sorted 
as if each comparison were reversed.
"""

That has no effect on keys that compare equal.  It means that keys that compare 
"less than" are treated as if they had compared "greater than" instead, and 
vice versa.

While it may not be immediately obvious, what `x.sort(reverse=True)` is 
actually equivalent to is the sequence:

x.reverse()
x.sort()
x.reverse()

--
nosy: +tim.peters
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type:  -> behavior

___
Python tracker 

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

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

[Benjamin Peterson]

Changes by Benjamin Peterson :


--
pull_requests: +455

___
Python tracker 

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

[issue19837] Wire protocol encoding for the JSON module

[Clay Gerrard]

Clay Gerrard added the comment:

and for *encoding* case?  Can you just add the encoding argument back to 
json.dumps?  Have it default to None because of backwards compatibility in 
python3 and continue to return strings by default... 

... and then *everyone* that ever wants to *serialize* an object to json 
because they want to put it on a wire or w/e will hopefully someday learn when 
you call json.dumps you *always* set encoding='utf-8' and it will always return 
utf-8 encoded bytes (which is the same thing it would have done py2 regardless)?

Is it confusing for the py3 encoding argument to mean something different than 
py2?  Probably?  The encoding argument in py2 was there to tell the Encoder how 
to decode keys and values who's strings were acctually utf-8 encoded bytes.  
But w/e py3 doesn't have that problem - so py3 can unambiguously hijack dumps' 
encoding param to mean bytes!  Then, sure, maybe the fact I can write:

sock.send(json.dumps(obj, encoding='utf-8'))

... in either language is just a happy coincidence - but it'd be useful 
nevertheless.

Or I could be wrong.  I've not been thinking about this for 3 years.  But I 
have bumped into this a couple of times in the years since starting to dream of 
python 3.2^H4^H5^H6^H7 support - but until then I do seem to frequently forget 
json.dumps(obj).decode('utf-8') so maybe my suggestion isn't really any better!?

--
nosy: +Clay Gerrard

___
Python tracker 

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

[issue29754] sorted ignores reverse=True when sorting produces same list

[Tomas Dabašinskas]

New submission from Tomas Dabašinskas:

sorted ignores reverse=True when sorting produces same list, I was expecting 
reverse regardless of the sorting outcome.

Python 3.5.2 (default, Jul 17 2016, 00:00:00) 
[GCC 4.8.4] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> data = [{'name': 'first', 'weight': 1},{'name': 'second', 'weight': 
>>> 1},{'name': 'third', 'weight': 1}, {'name': 'fourth', 'weight': 1}]
>>> sorted(data, key=lambda x: x['weight'], reverse=True)
[{'name': 'first', 'weight': 1}, {'name': 'second', 'weight': 1}, {'name': 
'third', 'weight': 1}, {'name': 'fourth', 'weight': 1}]
>>> sorted(data, key=lambda x: x['weight'], reverse=True) == sorted(data, 
>>> key=lambda x: x['weight']).reverse()
False

Thanks!

--
components: Library (Lib)
messages: 289202
nosy: Tomas Dabašinskas
priority: normal
severity: normal
status: open
title: sorted ignores reverse=True when sorting produces same list
versions: Python 2.7, 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

[issue29723] 3.6.1rc1 adds the current directory to sys.path when running a subdirectory's __main__.py; previous versions did not

[Steve Dower]

Steve Dower added the comment:

It's actually "adding" the current directory by not replacing the empty string 
that's normally there, presumably because it's already been resolved into a 
path at this stage. The behavior on Windows is correct, so I expect it's 
actually a difference between getpath.c and getpathp.c, rather than an 
isolated/non-isolated mode issue.

I'll try and take a look - my plate is fairly full over the next few weeks 
though, so if anyone is able to help out I'd appreciate it, especially since 
it's not my usual platform.

--

___
Python tracker 

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

[issue29537] Alternative fix for BUILD_MAP_UNPACK_WITH_CALL opcode in 3.5

[Nick Coghlan]

Nick Coghlan added the comment:

I just realised I need to add some test cases to 
test_importlib/source/test_file_loader.py before merging it, but since Larry 
hasn't objected to the proposed approach, I'm going to go ahead and implement 
this fix.

--

___
Python tracker 

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

[issue29740] Visual C++ CRT security update from 14 June 2011

[Steve Dower]

Steve Dower added the comment:

There will be no changes to the CRT in the update. It's been released as a 
major upgrade package rather than a patch, which is why it contains all the 
files, but the last version field typically (and in this case definitely) 
indicates no change to the API or implementation beyond that described in the 
associated KB article.

So thanks for being through and bringing it to our attention, but it's not 
necessary to change anything here on our side, and it's probably riskier to 
make any change than to not make it.

--

___
Python tracker 

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

[issue29319] Embedded 3.6.0 distribution cannot run pyz files

[Steve Dower]

Steve Dower added the comment:

Oh, well that's by design. Neither the current working directory nor the 
directory of the initial script are in sys.path by default - they need to be 
added explicitly.

The intent of this distro is that you know exactly where relative to the 
executable your modules are, that won't change after you release your app, and 
that you want to avoid other code using your private (embedded) copy of Python.

--

___
Python tracker 

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

[issue23267] multiprocessing pool.py doesn't close inqueue and outqueue pipes on termination

[Josh Rosenberg]

Changes by Josh Rosenberg :


--
nosy: +josh.r

___
Python tracker 

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

[issue27151] multiprocessing.Process leaves read pipes open (Process.sentinel)

[Josh Rosenberg]

Changes by Josh Rosenberg :


--
nosy: +josh.r

___
Python tracker 

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

[issue29568] undefined parsing behavior with the old style string formatting

[Xiang Zhang]

Changes by Xiang Zhang :


--
resolution:  -> fixed
stage: patch 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

[issue26915] Test identity first in membership operation of ItemsView, ValuesView and Sequence in collections.abc

[Xiang Zhang]

Changes by Xiang Zhang :


--
resolution:  -> fixed
stage: patch 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

[issue24329] __qualname__ and __slots__

[Xiang Zhang]

Changes by Xiang Zhang :


--
resolution:  -> fixed
stage: patch 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

[issue26915] Test identity first in membership operation of ItemsView, ValuesView and Sequence in collections.abc

[Xiang Zhang]

Changes by Xiang Zhang :


--
pull_requests: +454

___
Python tracker 

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

[issue17441] Do not cache re.compile

[Matthew Barnett]

Matthew Barnett added the comment:

If we were doing it today, maybe we wouldn't cache them, but, as you say, it's 
been like that for a long time. (The regex module also caches them, because the 
re module does.) Unless someone can demonstrate that it's a problem, I'd say 
just leave it as it is.

--

___
Python tracker 

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

[issue19225] lack of PyExc_BufferError doc

[Tomohiko Kinebuchi]

Tomohiko Kinebuchi added the comment:

This issue seems pending.

> beng94

Would you create a pull request?

--
nosy: +cocoatomo

___
Python tracker 

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

[issue17441] Do not cache re.compile

[Raymond Hettinger]

Raymond Hettinger added the comment:

Can this be closed.  Caching of regexes has been around for a very long time 
and I expect that a lot of code depends on it.  This should not be washed away 
without considerable discussion.

--
nosy: +rhettinger
status: pending -> open

___
Python tracker 

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

[issue27151] multiprocessing.Process leaves read pipes open (Process.sentinel)

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
assignee:  -> davin

___
Python tracker 

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

[issue29319] Embedded 3.6.0 distribution cannot run pyz files

[Eric Frederich]

Eric Frederich added the comment:

I can confirm that this is NOT fixed in 3.6.1rc1 embeddable zip.

This is extremely easy to reproduce.  Look at the contents of foo.py and 
bar.py.  Just throw them in the same directory and try to run 
C:\path\to\extracted\python.exe foo.py

--
versions: +Python 3.6

___
Python tracker 

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

[issue29753] Ctypes Packing Incorrectly - Linux

[Charles Machalow]

New submission from Charles Machalow:

There appears to be a bug related to sizing/packing of ctypes Structures on 
Linux. I'm not quite sure how, but this structure:

class MyStructure(Structure):
_pack_  = 1
_fields_= [ 
  ("P",   c_uint16),# 2 Bytes
  ("L",   c_uint16, 9),
  ("Pro", c_uint16, 1),
  ("G",   c_uint16, 1),
  ("IB",  c_uint16, 1),
  ("IR",  c_uint16, 1),
  ("R",   c_uint16, 3), # 4 Bytes
  ("T",   c_uint32, 10),
  ("C",   c_uint32, 20),
  ("R2",  c_uint32, 2)  # 8 Bytes
  ]

Gives back a sizeof of 8 on Windows and 10 on Linux. The inconsistency makes it 
difficult to have code work cross-platform.

Running the given test.py file will print out the size of the structure on your 
platform.

Tested with Python 2.7.6 and Python 3.4.3 (builtin to Ubuntu 14.04), Python 
2.7.13, (built from source) both on Ubuntu 14.04. On Linux all Python builds 
were 32 bit.

On Windows I tried with 2.7.7 (both 32 and 64 bit).

I believe on both platforms it should return a sizeof 8.

--
components: ctypes
files: test.py
messages: 289193
nosy: Charles Machalow, amaury.forgeotdarc, belopolsky, meador.inge
priority: normal
severity: normal
status: open
title: Ctypes Packing Incorrectly - Linux
type: behavior
versions: Python 2.7, Python 3.4
Added file: http://bugs.python.org/file46708/test.py

___
Python tracker 

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

[issue28685] Optimizing list.sort() by performing safety checks in advance

[Elliot Gorokhovsky]

Elliot Gorokhovsky added the comment:

Will post the final version of this patch as a pull request on Github.

--
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

[issue29752] Enum._missing_ not called for __getattr__ failures

[Ethan Furman]

New submission from Ethan Furman:

class Label(Enum):

RedApple = 1
GreenApple = 2

@classmethod
def _missing_(cls, name):
for member in cls:
if member.name.lower() == name.lower():
return member

Currently, _missing_ is only called when using the functional API. In words:

Label('redapple')  # works
Label.redapple # does not

--
assignee: ethan.furman
messages: 289191
nosy: barry, eli.bendersky, ethan.furman
priority: normal
severity: normal
stage: test needed
status: open
title: Enum._missing_ not called for __getattr__ failures
type: behavior
versions: 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

[issue29751] PyLong_FromString fails on decimals with leading zero and base=0

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
assignee:  -> docs@python
components: +Documentation -Interpreter Core
nosy: +docs@python, mark.dickinson
type: behavior -> enhancement

___
Python tracker 

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

[issue29751] PyLong_FromString fails on decimals with leading zero and base=0

[Martin Panter]

Martin Panter added the comment:

My guess is this is supposed to emulate (or is actually the implementation of) 
the "int" constructor and the Python syntax. In these cases, numbers with 
leading zeros are disallowed. This was to help with Python 2 porting, where a 
leading zero specified an octal number.

>>> 010
010
  ^
SyntaxError: invalid token
>>> int("010", 0)
ValueError: invalid literal for int() with base 0: '010'

Maybe it is better to fix the documentation.

--
nosy: +martin.panter

___
Python tracker 

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

[issue13535] Improved two's complement arithmetic support: to_signed() and to_unsigned()

[STINNER Victor]

STINNER Victor added the comment:

If you open the can of worms, other features will be requested like 
uint32+uint32 which would silently overflow.

IMHO it would be better to have a package (on PyPI) providing integers of fixed 
size implementing two's complement arithmetic: int8, uint16, etc. I failed to 
find an existing module.

--

___
Python tracker 

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

[issue29751] PyLong_FromString fails on decimals with leading zero and base=0

[Cubi]

New submission from Cubi:

Calling PyLong_FromString(str, NULL, 0) fails, if str is a string containing a 
decimal number with leading zeros, even though such strings should be parsed as 
decimal numbers according to the documentation:

"If base is 0, the radix will be determined based on the leading characters of 
str: if str starts with '0x' or '0X', radix 16 will be used; if str starts with 
'0o' or '0O', radix 8 will be used; if str starts with '0b' or '0B', radix 2 
will be used; otherwise radix 10 will be used"

Examples:
PyLong_FromString("15", NULL, 0); // Returns int(15) (Correct)
PyLong_FromString("0xF", NULL, 0); // Returns int(15) (Correct)
PyLong_FromString("015", NULL, 0); // Should return int(15), but raises 
ValueError: invalid literal for int() with base 0: '015'

Version information:
Python 3.5.2 (v3.5.2:4def2a2901a5, Jun 25 2016, 22:18:55) [MSC v.1900 64 bit 
(AMD64)] on win32

--
components: Interpreter Core
messages: 289188
nosy: cubinator
priority: normal
severity: normal
status: open
title: PyLong_FromString fails on decimals with leading zero and base=0
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

[issue29740] Visual C++ CRT security update from 14 June 2011

[Markus]

Markus added the comment:

I beg pardon to be pedantic.
The issue is not MFC, but CRT.

The related safety bulletin 
(https://technet.microsoft.com/library/security/ms11-025) says

Your application may be an attack vector if all of the following conditions 
are true:

 - Your application makes use of the Microsoft Foundation Class (MFC) 
Library
 - Your application allows the loading of dynamic link libraries from 
untrusted locations, such as WebDAV shares

This is clearly **not** the case for Python.
So far so good.

I am concerned that the security update contains an updated vc90.crt 
9.0.30729.6161. 
If Python find the 6161 update, it will use it.

I found no information on the change between the 4940 version (from Python 
2.7.13) and the 6161 update (from the security update).

But as Python uses the 6161 update (if it is installed) I would like to raise 
the question if Python should ship it.

I am not a security expert, so this issue is based completely on the above 
observations and a crumb of logic.

--

___
Python tracker 

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

[issue29750] smtplib doesn't handle unicode passwords

[R. David Murray]

R. David Murray added the comment:

See msg253287.  Someone should check the RFC.  It is not obvious that just 
encoding using utf8 is correct; fundamentally passwords are binary data.  But 
the auth methods don't currently accept binary data.  UTF8 is a reasonable 
default these days, I think, but if we support more than ascii I think we need 
to support binary, with utf8 as the default encoding.

--
components: +email
nosy: +barry, r.david.murray
type:  -> enhancement
versions: +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

[issue27151] multiprocessing.Process leaves read pipes open (Process.sentinel)

[Camilla Montonen]

Changes by Camilla Montonen :


--
nosy: +Winterflower

___
Python tracker 

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

[issue29750] smtplib doesn't handle unicode passwords

[david]

david added the comment:

I'm sorry I rushed my comment. Same thing happens on line 604


return encode_base64(s.encode('ascii'), eol='')


changing both from 'ascii' to 'utf-8' works for me.

--

___
Python tracker 

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

[issue29750] smtplib doesn't handle unicode passwords

[david]

New submission from david:

Trying to use unicode passwords on smtplib fails miserably on python3.
My particular issue arises on line 643 of said library:

(code, resp) = self.docmd(encode_base64(password.encode('ascii'), eol=''))

which obviously dies when trying to handle unicode chars.

--
components: Library (Lib)
messages: 289184
nosy: david__
priority: normal
severity: normal
status: open
title: smtplib doesn't handle unicode passwords
versions: Python 3.4

___
Python tracker 

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

[issue29740] Visual C++ CRT security update from 14 June 2011

[Steve Dower]

Steve Dower added the comment:

We don't use MFC in Python, so we are not affected.

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

___
Python tracker 

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

[issue29319] Embedded 3.6.0 distribution cannot run pyz files

[Steve Dower]

Steve Dower added the comment:

Eric - that sounds like the same issue. Can you test with 3.6.1rc1 to see if it 
is fixed for you?

--

___
Python tracker 

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

[issue29695] Weird keyword parameter names in builtins

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

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

[issue1158490] locale fails if LANGUAGE has multiple locales

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
resolution:  -> out of date
stage: patch review -> resolved
status: pending -> closed

___
Python tracker 

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

[issue25641] urllib/request.py/getproxies_environment() throws "dictionary changed size during iteration" error occasionally

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
resolution:  -> not a bug
stage: test needed -> resolved
status: pending -> closed

___
Python tracker 

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

[issue20525] Got compiler warning when compiling readline module

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
resolution:  -> works for me
stage:  -> resolved
status: pending -> closed

___
Python tracker 

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

[issue16429] Emit SyntaxWarning for code that risks UnboundLocalError

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
stage:  -> resolved
status: pending -> closed

___
Python tracker 

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

[issue19469] Duplicate namespace package portions (but not on Windows)

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
resolution:  -> out of date
stage: test needed -> resolved
status: pending -> closed

___
Python tracker 

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

[issue2263] struct.pack() + numpy int raises SystemError

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
resolution:  -> third party
stage:  -> resolved
status: pending -> closed

___
Python tracker 

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

[issue13535] Improved two's complement arithmetic support: to_signed() and to_unsigned()

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
resolution:  -> rejected
stage: needs patch -> resolved
status: pending -> closed

___
Python tracker 

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

[issue29319] Embedded 3.6.0 distribution cannot run pyz files

[Eric Frederich]

Eric Frederich added the comment:

I'm wondering if I'm experiencing this same issue.
In a simple directory with a foo.py and a bar.py where foo tries to import from 
bar I cannot get it to work with the embeddable 3.6.0 zip, but the standard 
3.6.0 that gets "installed" works fine.  Also 3.5.3 works fine

C:\Users\eric\Desktop\wtf>more foo.py
from bar import bar

print(bar('hi'))

C:\Users\eric\Desktop\wtf>more bar.py
def bar(s):
return s.upper()

C:\Users\eric\Desktop\wtf>C:\Users\eric\Downloads\python-3.5.3-embed-amd64\python.exe
 foo.py
HI

C:\Users\eric\Desktop\wtf>C:\Users\eric\Downloads\python-3.6.0-embed-amd64\python.exe
 foo.py
Traceback (most recent call last):
  File "foo.py", line 1, in 
from bar import bar
ModuleNotFoundError: No module named 'bar'

--
nosy: +eric.frederich

___
Python tracker 

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

[issue25547] Improve repr for files to show whether the file is open or closed.

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
resolution: not a bug -> out of date
status: pending -> closed

___
Python tracker 

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

[issue25841] In FancyURLopener error in example with http address.

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
stage: needs patch -> resolved
status: pending -> closed

___
Python tracker 

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

[issue26016] io.TextIOWrapper.tell() report 65bit number when mix readline() + tell()

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
stage:  -> resolved
status: pending -> closed

___
Python tracker 

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

[issue1283110] Give __len__() advice for "don't know"

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
keywords: +needs review
stage:  -> patch review
status: pending -> open
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

[issue6445] Add check parameter to subprocess.Popen.communicate

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
stage: test needed -> resolved
status: pending -> closed

___
Python tracker 

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

[issue19253] PyArg_ParseTuple: wrong use of seterror() clips helpful type error annotation

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
resolution:  -> out of date
stage: patch review -> resolved
status: pending -> closed

___
Python tracker 

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

[issue8238] Proxy handling very slow

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
resolution:  -> out of date
stage:  -> resolved
status: pending -> closed

___
Python tracker 

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

[issue23150] urllib parse incorrect handing of params

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
stage: test needed -> resolved
status: pending -> closed

___
Python tracker 

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

[issue28025] Use IntEnum and IntFlags in ssl module

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


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

___
Python tracker 

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

[issue25901] `make test` crashes in test_httpservers

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
resolution:  -> works for me
stage:  -> resolved
status: pending -> closed

___
Python tracker 

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

[issue27619] getopt should strip whitespace from long arguments

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
stage: patch review -> resolved
status: pending -> closed

___
Python tracker 

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

[issue27235] Heap overflow occurred due to the int overflow (Python-2.7.11/Modules/posixmodule.c)

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
stage: test needed -> resolved
status: pending -> closed

___
Python tracker 

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

[issue24549] string.format() should have a safe_substitute equivalent, to be run consecutively

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
resolution:  -> rejected
stage:  -> resolved
status: pending -> closed

___
Python tracker 

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

[issue26340] modal dialog with transient method; parent window fails to iconify

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
resolution:  -> works for me
stage:  -> resolved
status: pending -> closed

___
Python tracker 

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

[issue17343] Add a version of str.split which returns an iterator

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
resolution:  -> rejected
stage: needs patch -> resolved
status: pending -> closed

___
Python tracker 

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

[issue19159] 2to3 incorrectly converts two parameter unicode() constructor to str()

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
resolution:  -> wont fix
stage: needs patch -> resolved
status: pending -> closed

___
Python tracker 

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

[issue20612] cElementTree has problems with StringIO object containing unicode content

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
resolution:  -> wont fix
stage:  -> resolved
status: pending -> closed

___
Python tracker 

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

[issue23267] multiprocessing pool.py doesn't close inqueue and outqueue pipes on termination

[Camilla Montonen]

Camilla Montonen added the comment:

I did some investigating using a test script and Python 3.7.0a0

from multiprocessing import Pool
import os
import time

def f(x):
time.sleep(30)
return x*x

if __name__=='__main__':
print('Main pid {0}'.format(os.getpid()))
p = Pool(5)
p.map(f, [1,2,3])
print('Returned')
time.sleep(30)
and grepping for pipe and the parentpid in the output from lsof ( lsof | grep 
python.*.*pipe ). The pipes opened at the start of the script are 
still open even after the line print('Returned') is executed. I suppose this is 
expected because I did not call *p.close()*. All pipes are cleaned up after the 
parent process finishes.

When I repeat the experiment calling p.close() after p.map returns, all that is 
left is the 9 pipes opened by the parent. All pipes are cleaned up after parent 
script exits. 

@shani - could you please clarify how you were able to detect the leaking pipes?

--

___
Python tracker 

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

[issue28826] Programming with Python 3.6

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
resolution:  -> fixed
stage:  -> resolved
status: pending -> closed

___
Python tracker 

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

[issue20087] Mismatch between glibc and X11 locale.alias

[Marc-Andre Lemburg]

Marc-Andre Lemburg added the comment:

On 07.03.2017 18:23, Serhiy Storchaka wrote:
> 
> Serhiy Storchaka added the comment:
> 
>> 'cy_GB.ISO8859-1' to 'cy_GB.ISO8859-14'
> 
> Looks as just fixing an error. The default West-European ISO8859-1 is changed 
> to Celtic cy_GB.ISO8859-14. This looks better option for Welsh.
> 
>> 'tg_TJ.KOI8-C' to 'tg_TJ.KOI8-T'
> 
> KOI8-C is not supported by Python, but KOI8-T is supported. I don't know what 
> KOI8-C means, there are several rarely used incompatible encodings with this 
> name.

While all this may make sense, I'm missing some more reasoning
behind the differences between X.org and glibc.

This change also looks strange:

-'ka_ge':'ka_GE.GEORGIAN-ACADEMY',
+'ka_ge':'ka_GE.GEORGIAN_PS',
 'ka_ge.georgianacademy':'ka_GE.GEORGIAN-ACADEMY',
 'ka_ge.georgianps': 'ka_GE.GEORGIAN-PS',
 'ka_ge.georgianrs': 'ka_GE.GEORGIAN-ACADEMY',

Why is GEORGIAN_PS written with an underscore whereas the other
mappings use dashes ?

Or this one:

-'fi_fi':'fi_FI.ISO8859-15',
+'fi_fi':'fi_FI.ISO8859-1',

Why would a locale switch away from an encoding having
the Euro sign to one without it ?

Or why is this latin variant removed:

-'nan_tw@latin': 'nan_TW.UTF-8@latin',

Why should Russians switch back to ISO ?

-'ru_ru':'ru_RU.UTF-8',
+'ru_ru':'ru_RU.ISO8859-5',

or from ISO to KOI ?

-'russian':  'ru_RU.ISO8859-5',
+'russian':  'ru_RU.KOI8-R',

The more I look at these changes, the more I believe we
should not simply take everything we find in the files
for granted. They obviously both have bugs.

>> I also don't understand why some "xx.utf-8" locale mappings were removed - I 
>> don't think we should remove those, unless they are no longer needed due to 
>> some other logic implying these mappings.
> 
> The aliases table is a table of exceptions. Removed entries no longer are 
> exceptional.

It's not a table of exceptions, it's a table mapping commonly
used locale settings to ones which the lib C understands :-)

But regardless, I checked the code and it is already
smart enough to convert lib C incompatible spellings such
as "utf8" to "UTF-8", so these entries can indeed be
removed, but only if the locale is otherwise listed.

In some cases, it's probably better to drop the ".utf8"
to have more generic mappings, e.g.

+'bhb_in.utf8':  'bhb_IN.UTF-8',

or

 'de_li.utf8':   'de_LI.UTF-8',

though I'd expect that mapping to be:

 'de_li':   'de_LI.ISO8859-1',

as for all other "de" entries.

--

___
Python tracker 

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

[issue17003] Unification of read() and readline() argument names

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
resolution:  -> fixed
stage: patch 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

[issue29048] Coverage influence tests, make some of them fail

[Brett Cannon]

Changes by Brett Cannon :


--
nosy: +brett.cannon

___
Python tracker 

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

[issue29691] Some tests fail in coverage Travis check

[Brett Cannon]

Changes by Brett Cannon :


--
resolution:  -> duplicate
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

[issue29691] Some tests fail in coverage Travis check

[Brett Cannon]

Brett Cannon added the comment:

So the reason we don't have the coverage run complain loudly is it takes at 
least 40 minutes to complete, so having to wait for that could potentially be 
annoying if you're e.g. trying to merge a cherry-pick and you just want to 
verify you didn't break anything.

And yes, there might be some connection to issue #29048. To keep things simple 
we can close this in favour of the other issue and track the work there.

--
superseder:  -> Coverage influence tests, make some of them fail

___
Python tracker 

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

[issue29739] zipfile raises wrong exception for some incorrect passwords

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I don't think that this makes much sense. The exception raised for wrong 
password is not documented, even the fact that some exception is raised is not 
documented. In very rare cases you can read a data without any error using 
wrong password, but the result will be of course not correct.

--

___
Python tracker 

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

[issue20087] Mismatch between glibc and X11 locale.alias

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

> 'cy_GB.ISO8859-1' to 'cy_GB.ISO8859-14'

Looks as just fixing an error. The default West-European ISO8859-1 is changed 
to Celtic cy_GB.ISO8859-14. This looks better option for Welsh.

> 'tg_TJ.KOI8-C' to 'tg_TJ.KOI8-T'

KOI8-C is not supported by Python, but KOI8-T is supported. I don't know what 
KOI8-C means, there are several rarely used incompatible encodings with this 
name.

> I also don't understand why some "xx.utf-8" locale mappings were removed - I 
> don't think we should remove those, unless they are no lot needed due to some 
> other logic implying these mappings.

The aliases table is a table of exceptions. Removed entries no longer are 
exceptional.

--

___
Python tracker 

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

[issue29739] zipfile raises wrong exception for some incorrect passwords

[Jack Cushman]

Jack Cushman added the comment:

Ah, thanks! That makes sense. I see it's documented in "man unzip" as well:

"The correct password will always check out against the header, but there is a 
1-in-256 chance that an incorrect password will as well.  (This is a security 
feature of the PKWARE zipfile format; it helps prevent brute-force attacks  
that  might otherwise gain a large speed advantage by testing only the header.) 
 In the case that an incorrect password is given but it passes the header test 
anyway, either an incorrect CRC will be generated for  the  extracted  data  or 
 else  unzip  will  fail  during  the  extraction  because  the ``decrypted'' 
bytes do not constitute a valid compressed data stream."

Would it make sense to add a note to documentation for zipfile functions that 
take a password?

--

___
Python tracker 

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

[issue20087] Mismatch between glibc and X11 locale.alias

[Marc-Andre Lemburg]

Marc-Andre Lemburg added the comment:

I agree that it's reasonable to have glibc's aliases override
the X.org ones, but this patch makes some pretty significant changes to 
Python's default assumptions with respect to default encodings for several 
locales.

While some changes obviously make sense (e.g. 'ca_AD.ISO8859-1' to 
'ca_AD.ISO8859-15'), others are less clear (e.g. 'cy_GB.ISO8859-1' to 
'cy_GB.ISO8859-14' or 'tg_TJ.KOI8-C' to 'tg_TJ.KOI8-T' or several of the moves 
from ISO encodings to UTF-8). Is there some reference for why glibc chose 
different values than X.org for these ?

I also don't understand why some "xx.utf-8" locale mappings were removed - I 
don't think we should remove those, unless they are no lot needed due to some 
other logic implying these mappings.

Since these are major changes, we need an appropriate warning in the NEWS file 
(and the "What's New" document), an update of the top comment (under "### 
Database") to mention that the glibc database takes precedence and where to 
find it,

--

___
Python tracker 

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

[issue28856] %b format for bytes does not support objects that follow the buffer protocol

[Stefan Krah]

Stefan Krah added the comment:

For '%b', it looks like the PEP supports it. I didn't follow the PEP 
discussions, I think Ethan will know more.

--

___
Python tracker 

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

[issue28856] %b format for bytes does not support objects that follow the buffer protocol

[Xiang Zhang]

Xiang Zhang added the comment:

Isn't this a discussed behaviour that is explicitly documented in PEP 461?

--

___
Python tracker 

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

[issue6759] zipfile.ZipExtFile.read() is missing universal newline support

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Support of the 'U' mode is removed in 3.6 (issue27029).

--
resolution:  -> out of date
stage: needs patch -> 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

[issue29537] Alternative fix for BUILD_MAP_UNPACK_WITH_CALL opcode in 3.5

[Iryna]

Iryna added the comment:

If I may ask, what was the decision on this matter?

We are planning to rebase Python 3.5 for Fedora and this currently blocks us, 
if we do not work this around with a patch.
Let me know if there is anything I can help with to speed up the process.

--

___
Python tracker 

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

[issue29686] Unittest - Return empty string instead of None object on shortDescription()

[Vinícius Dantas]

Vinícius Dantas added the comment:

In the point of view of a tester, if it's an error, they will know right
away it is a test case problem, not an assert problem. That makes debugging
easier.
It is also important to note that, if it's an AssertionError, we may add a
message. While, if it is an error, no message would be displayed but the
original Exception's.

As Selenium's example, as I said, was just a use case example.

Finally, having the failure reason explicit is better than keeping it
implicit.

--

___
Python tracker 

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

[issue21509] json.load fails to read UTF-8 file with (BOM) Byte Order Marks

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

This issue is outdated since implementing automatic encoding detecting in 
issue17909.

--
resolution:  -> out of date
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

[issue19871] json module won't parse a float that starts with a decimal point

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
status: open -> pending

___
Python tracker 

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

[issue17441] Do not cache re.compile

[Guido van Rossum]

Changes by Guido van Rossum :


--
status: open -> pending

___
Python tracker 

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

[issue17441] Do not cache re.compile

[Guido van Rossum]

Changes by Guido van Rossum :


--
nosy:  -gvanrossum
status: pending -> open

___
Python tracker 

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

[issue29747] unittest - assertDoesNotRaise

[Vinícius Dantas]

Changes by Vinícius Dantas :


--
pull_requests: +453

___
Python tracker 

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

[issue16055] incorrect error text for int(base=1000, x='1')

[STINNER Victor]

STINNER Victor added the comment:

> Since the first parameter of int() is now positional-only, this issue looks 
> outdated.

Right, but Python 3.7 still has this issue: "The *base* argument can also be 
0." The error message should be:

"ValueError: int() base must be >= 2 and <= 36 or 0" (add "or 0")

--
nosy: +haypo
status: pending -> open

___
Python tracker 

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

[issue16055] incorrect error text for int(base=1000, x='1')

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Since the first parameter of int() is now positional-only, this issue looks 
outdated.

--
status: open -> pending

___
Python tracker 

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

[issue17441] Do not cache re.compile

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
status: open -> pending

___
Python tracker 

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

[issue29593] Improve UnboundLocalError message for deleted names

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

See also issue17792.

--

___
Python tracker 

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

[issue10030] Patch for zip decryption speedup

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
pull_requests: +452

___
Python tracker 

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