[issue27660] Replace size_t with Py_ssize_t as the type of local variable in list_resize

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
assignee:  -> rhettinger
nosy: +rhettinger, serhiy.storchaka, tim.peters

___
Python tracker 

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

[issue27655] [Patch] Don't require presence of POLLPRI

[Benjamin Peterson]

Benjamin Peterson added the comment:

Why do you remove the flag rather than just making it a noop?

--
nosy: +benjamin.peterson

___
Python tracker 

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

[issue27662] Check against PY_SSIZE_T_MAX instead of PY_SIZE_MAX in List_New

[Raymond Hettinger]

Raymond Hettinger added the comment:

Mark, this is your code.  Care to comment?

--
assignee:  -> mark.dickinson

___
Python tracker 

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

[issue1621] Do not assume signed integer overflow behavior

[Xiang Zhang]

Xiang Zhang added the comment:

I agree. For multibytecode, how about switching the positions of the two 
checks? If npendings + ctx->pendingsize overflows, the result can be anything, 
larger, smaller than or equal to MAXDECPENDING. For ast, although a SystemError 
may be raised but the message seems not obvious to the reason.

--

___
Python tracker 

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

[issue27558] SystemError with bare `raise` in threading or multiprocessing

[Xiang Zhang]

Xiang Zhang added the comment:

Update the patch with Berker's suggestion: add test in test_threading instead 
of test_raise. Hope someone is willing to merge this.

--
Added file: http://bugs.python.org/file43971/issue27558_v2.patch

___
Python tracker 

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

[issue27662] Check against PY_SSIZE_T_MAX instead of PY_SIZE_MAX in List_New

[Xiang Zhang]

Xiang Zhang added the comment:

Thanks for your replies.

I update the patch with PyMem_Calloc. I think it's better than PyMem_Resize 
since we need to initialize the memory here, there is a memset(op->ob_item, 0, 
nbytes) below.

--
Added file: http://bugs.python.org/file43970/List_New_Calloc.patch

___
Python tracker 

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

[issue1621] Do not assume signed integer overflow behavior

[Martin Panter]

Martin Panter added the comment:

Looking over r60793, the overflow check at 
Modules/cjkcodecs/multibytecodec.c:836 looks vulnerable to being optimized 
away, because it can only detect the overflow if the line above has already 
overflowed. Perhaps change PY_SSIZE_T_MAX to MAXDECPENDING. I wonder if any of 
the GCC optimization and warning modes can detect this case?

Also, Python/ast.c:3988 checks using PY_SIZE_MAX, but then passes the value to 
PyBytes_FromStringAndSize(), which expects ssize_t and in the best case would 
raise SystemError.

--

___
Python tracker 

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

[issue27660] Replace size_t with Py_ssize_t as the type of local variable in list_resize

[Martin Panter]

Martin Panter added the comment:

The patch looks okay to me.

--
stage:  -> patch review

___
Python tracker 

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

[issue27662] Check against PY_SSIZE_T_MAX instead of PY_SIZE_MAX in List_New

[Martin Panter]

Martin Panter added the comment:

It looks like PyMem_RESIZE() would be a truer equivalent than PyMem_Calloc(), 
since PyMem_MALLOC() does not initialize the memory. I would be happy with 
changing to that if you want.

PyMem_Malloc() has been limited to PY_SSIZE_T_MAX since Issue 2620, although 
the documentation 
 only mentions 
“size_t”. There is no match for “ssize_t” etc anywhere on that page.

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

[issue27662] Check against PY_SSIZE_T_MAX instead of PY_SIZE_MAX in List_New

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
nosy: +mark.dickinson

___
Python tracker 

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

[issue27662] Check against PY_SSIZE_T_MAX instead of PY_SIZE_MAX in List_New

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
Removed message: http://bugs.python.org/msg271797

___
Python tracker 

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

[issue27662] Check against PY_SSIZE_T_MAX instead of PY_SIZE_MAX in List_New

[Raymond Hettinger]

Raymond Hettinger added the comment:

The whole computation on that line is in size_t, so the use of PY_SIZE_MAX 
seems correct.

--
nosy: +rhettinger, tim.peters

___
Python tracker 

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

[issue27666] "stack smashing detected" in PyCursesWindow_Box

[Steve Fink]

New submission from Steve Fink:

When attempting to run |hg chistedit|, which uses the python curses module, I 
am getting *** stack smashing detected ***: /usr/bin/python terminated

The problem is in PyCursesWindow_Box in _cursesmodule.c:

if (!PyArg_ParseTuple(args,"ll;vertint,horint", , ))
return NULL;

ch1 and ch2 are of type 'chtype', which is a 4-byte integer on my platform. (I 
am on a fresh install of Fedora 24 x86_64.) The format string 'l' is writing 8 
bytes. It is hard to fit 8 bytes into a 4 byte variable.

I scanned through the rest of the file. Most places are very careful about 
this; if needed, they'll parse into a 'long' temporary and then assign. But 
here's another one in PyCurses_UngetMouse:

MEVENT event;
PyCursesInitialised;
if (!PyArg_ParseTuple(args, "hiiil",
  ,
  , , ,
  (int *) ))
return NULL;

event.bstate is of type mmask_t, which is also 4 bytes.

I did not find any more in that file.

% rpm -q python-libs
python-libs-2.7.12-1.fc24.x86_64

--
components: Library (Lib)
messages: 271796
nosy: Steve Fink
priority: normal
severity: normal
status: open
title: "stack smashing detected" in PyCursesWindow_Box
type: crash
versions: Python 2.7

___
Python tracker 

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

[issue27665] Make create_server able to listen on several ports

[Alexander Bayandin]

Alexander Bayandin added the comment:

Furthermore, there is a problem with overlapped ports for multiple created 
server objects. Also, I can quote a comment from 'original' issue: 
http://bugs.python.org/msg237794

--

___
Python tracker 

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

[issue27665] Make create_server able to listen on several ports

[Alexander Bayandin]

Alexander Bayandin added the comment:

I think it is just handier than creating several server objects like it is 
already done for a list of hosts.
For me in particular, need to have exactly the same logic for multiple ports 
which generates randomly and I want to have one predefined port for manually 
checking/debugging.

--

___
Python tracker 

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

[issue27665] Make create_server able to listen on several ports

[Guido van Rossum]

Guido van Rossum added the comment:

IIRC we got a similar PR before. But what's the problem with creating multiple 
server objects?

--

___
Python tracker 

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

[issue27665] Make create_server able to listen on several ports

[Alexander Bayandin]

New submission from Alexander Bayandin:

Make create_server accept a list of ports to listen.
Now it contains only code changes without updates in docs and tests.
If these changes will be considered as helpful I'll be glad to add tests and 
update documentation for the method.

--
components: asyncio
files: create_server-multiple-ports.patch
keywords: patch
messages: 271792
nosy: Alexander.Bayandin, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: Make create_server able to listen on several ports
type: enhancement
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file43969/create_server-multiple-ports.patch

___
Python tracker 

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

[issue27477] IDLE: Switch search dialogs to ttk widgets, and other refinement

[Mark Roseman]

Mark Roseman added the comment:

Have attached search.diff, which does an initial bit of cosmetics: adds inner 
frame with spacing, tweaks a couple labels, and for Mac and X11, puts the 
command buttons at the bottom of the dialog rather than on the right (where 
they remain on Windows).

--
Added file: http://bugs.python.org/file43968/search.diff

___
Python tracker 

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

[issue27664] Allow specifying prefix for thread name in concurrent.futures.ThreadPoolExecutor

[Zachary Ware]

Changes by Zachary Ware :


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

[issue27664] Allow specifying prefix for thread name in concurrent.futures.ThreadPoolExecutor

[Gregory P. Smith]

Changes by Gregory P. Smith :


--
nosy: +gregory.p.smith

___
Python tracker 

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

[issue27664] Allow specifying prefix for thread name in concurrent.futures.ThreadPoolExecutor

[Augie Fackler]

New submission from Augie Fackler:

This is mostly useful for when you've got a large number of threads and want to 
try and identify what threadpool is going nuts.

--
components: Library (Lib)
files: cpython.patch
keywords: patch
messages: 271790
nosy: durin42
priority: normal
severity: normal
status: open
title: Allow specifying prefix for thread name in 
concurrent.futures.ThreadPoolExecutor
type: enhancement
Added file: http://bugs.python.org/file43967/cpython.patch

___
Python tracker 

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

[issue27621] Finish IDLE Query dialog appearance and behavior.

[Mark Roseman]

Mark Roseman added the comment:

I've attached query.patch, which does the cosmetic and layout changes, and adds 
a couple Mac-specific things. I've added the inline error message widget but 
don't use it yet (as this will involve changes to the subclasses and the tests, 
given errors will show up when the dialog is running, not after).

Given I'm a bit rusty at this, would appreciate if someone could check this out 
and make sure I did things correctly. :-)

--
Added file: http://bugs.python.org/file43966/query.patch

___
Python tracker 

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

[issue27661] Add tzinfo= argument to datetime.combine

[Alexander Belopolsky]

Changes by Alexander Belopolsky :


Added file: http://bugs.python.org/file43965/issue27661-3.diff

___
Python tracker 

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

[issue27661] Add tzinfo= argument to datetime.combine

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

>From review comments:

Lib/datetime.py:1482: def combine(cls, date, time, tzinfo=True):
On 2016/08/01 12:23:12, berkerpeksag wrote:
> On 2016/08/01 08:47:14, SilentGhost wrote:
> > This strikes me as an odd default value, why not use a more conventional
None?
> 
> Agreed. It would also be good to make it keyword-only.

tzinfo is not kw-only in the other constructors and I don't think it should be 
here.  Unlike "fold", tzinfo value is usually recognizable at the call site.  
It is either called something like "tzinfo", "tz" or "New_York" or is a call 
such as 'tz.get('US/Eastern').

I would always prefer datetime.combine(d, t, tzinfo) to  datetime.combine(d, t, 
tzinfo=tzinfo).  datetime.combine(d, t, New_York) vs. datetime.combine(d, t, 
tzinfo=New_York) is a closer call, but still the first form is readable enough.


See 
.

--

___
Python tracker 

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

[issue27661] Add tzinfo= argument to datetime.combine

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

>From review comments:

Lib/datetime.py:1482: def combine(cls, date, time, tzinfo=True):
On 2016/08/01 08:47:14, SilentGhost wrote:
> This strikes me as an odd default value, why not use a more conventional None?

This is the same default as used in the .replace() methods.  Arguably, a proper 
sentinel value would be a better choice, but I think True delivers better 
performance.  In any case, this is not something I would change without 
consulting with the PyPy folks.

See 
.

--
stage: patch review -> commit review

___
Python tracker 

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

[issue27661] Add tzinfo= argument to datetime.combine

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

The second patch includes documentation changes and addresses review commments.

--
Added file: http://bugs.python.org/file43964/issue27661-2.diff

___
Python tracker 

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

[issue27660] Replace size_t with Py_ssize_t as the type of local variable in list_resize

[R. David Murray]

R. David Murray added the comment:

Erg.  You mention your English proficiency and then I go using a colequialism 
:(  "better C chops" means someone with more skill than I am currently 
exhibiting.

--

___
Python tracker 

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

[issue27660] Replace size_t with Py_ssize_t as the type of local variable in list_resize

[R. David Murray]

R. David Murray added the comment:

No, I was the one who missed something.  Just ignore my comment and lets wait 
for someone with more current C chops to answer :)

--

___
Python tracker 

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

[issue1005895] curses for win32

[Matej Cepl]

Matej Cepl added the comment:

Well, basically any solution is better than nothing ;)

--
nosy: +mcepl

___
Python tracker 

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

[issue27663] Inconsistent CSV Writer Behaviour

[G Young]

G Young added the comment:

Second time around does the charm. I see the hidden "-" in the scientific 
notation is causing this. Thanks!

--

___
Python tracker 

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

[issue27663] Inconsistent CSV Writer Behaviour

[G Young]

G Young added the comment:

That doesn't make sense to me. Can you explain how that is intended behaviour? 
I just changed from '-' to '?' in the lineterminator.

--

___
Python tracker 

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

[issue27663] Inconsistent CSV Writer Behaviour

[SilentGhost]

SilentGhost added the comment:

It is quoting the values when line terminator contains any of the special 
characters. Exactly like documented. 
https://docs.python.org/3/library/csv.html#csv.QUOTE_MINIMAL

--
nosy: +SilentGhost
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

[issue27663] Inconsistent CSV Writer Behaviour

[G Young]

New submission from G Young:

When writing scientific notation to CSV with custom line-terminators, the 
behaviour is inconsistent depending on the line-terminator you use.

In the file provided, two different line-terminator result in one quoting the 
number as a string and the other not. IMO the second example is correct, but I 
don't understand why the behaviours should be any different.

--
components: IO
files: bug.py
messages: 271779
nosy: G Young
priority: normal
severity: normal
status: open
title: Inconsistent CSV Writer Behaviour
versions: Python 3.5
Added file: http://bugs.python.org/file43963/bug.py

___
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

[Nick Coghlan]

Nick Coghlan added the comment:

dump_bytes() would be a binary counterpart to dumps()

The dump() case is already handled more gracefully, as the implicit encoding to 
UTF-8 can live on the file-like object, rather than needing to be handled by 
the JSON encoder.

I'm still not 100% sure on its utility though - it's only "json.loads assuming 
binary input is UTF-8 encoded text would be way more helpful than the current 
behaviour" that I'm confident about. If the assumption is wrong, you'll likely 
fail JSON deserialisation anyway, and when it's right, the common subset of 
Python 2 & 3 has been expanded in a useful way.

So perhaps we should split the question into two issues? A new one for 
accepting binary data as an input to json.loads, and make this one purely about 
whether or not to offer a combined serialise-and-encode operation for the wire 
protocol use case?

--

___
Python tracker 

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

[issue27589] asyncio doc: issue in as_completed() doc

[Hynek Schlawack]

Hynek Schlawack added the comment:

More explicitly:

The doc sells the function short.  If you have a bunch of futures and want to 
know as soon as one of them is ready: this is the function for you.

The only hint that this is the actual behavior comes from the *name* of the 
function; not the documentation.

--
nosy: +hynek

___
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

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Does dump_bytes() return bytes (similar to dumps()) or write to binary stream 
(similar to dump())?

--

___
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

[Nick Coghlan]

Nick Coghlan added the comment:

I'm currently migrating a project that predates requests, and ended up needing 
to replace several "json.loads" calls with a "_load_json" helper that is just 
an alias for json.loads in Python 2, and defined as this in Python 3:

def _load_json(data):
return json.loads(data.decode())

To get that case to "just work", all I would have needed is for json.loads to 
accept bytes input, and assume it is UTF-8 encoded, that same way simplejson 
does. Since there aren't any type ambiguities associated with that, I think it 
would make sense for us to go ahead and implement at least that much for Python 
3.6.

By contrast, if I'd been doing *encoding*, I don't think there's anything the 
Python 3 standard library could have changed *on its own* to make things just 
work - I would have needed to change my code somehow.

However, a new "dump_bytes" API could still be beneficial on that front as long 
as it was also added to simplejson: code that needed to run in the common 
Python 2/3 subset could use "simplejson.dump_bytes", while 3.6+ only code could 
just use the standard library version.

Having dump_bytes() next to dumps() in the documentation would also provide a 
better hook for explaining the difference between JSON-as-text-encoding (with 
"str" output) and JSON-as-wire-encoding (with "bytes" output after encoding the 
str representation as UTF-8).

In both cases, I think it would make sense to leave the non-UTF-8 support to 
simplejson and have the stdlib version be UTF-8 only.

--

___
Python tracker 

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

[issue27662] Check against PY_SSIZE_T_MAX instead of PY_SIZE_MAX in List_New

[Xiang Zhang]

New submission from Xiang Zhang:

List_New checks against PY_SIZE_MAX. The upper bound of PyMem_Malloc is 
PY_SSIZE_T_MAX.

Instead of simply changing the constant, another method is delegating overflow 
check to PyMem_Calloc, so we can avoid the check in unnecessary check in 
PyMem_Malloc. But I am not sure hiding the check in PyMem_Calloc is a good idea 
or not.

--
components: Interpreter Core
files: List_New.patch
keywords: patch
messages: 271774
nosy: martin.panter, xiang.zhang
priority: normal
severity: normal
status: open
title: Check against PY_SSIZE_T_MAX instead of PY_SIZE_MAX in List_New
type: enhancement
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file43962/List_New.patch

___
Python tracker 

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

[issue27643] test_ctypes fails on AIX with xlc

[aixtools]

aixtools added the comment:

On 30-Jul-16 02:51, Martin Panter wrote:
> Martin Panter added the comment:
>
> Looks like your Python 3 build is messed up. Maybe it doesn’t like running 
> from a different directory. I would try from the main build directory, and 
> note the test_bitfields has an S:
I would not know why - it is just a copy of the sources and then 
configure, make, make DESTDIR=/some/where install (rather than make 
install).
Same procedure I use for python2.7.

>
> ./python -m unittest -v ctypes.test.test_bitfields
No changes: 3.5.1

root@x064:[/data/prj/aixtools/python/python-3.5.1.2]./python -m unittest 
-v ctypes.test.test_bitfields
test_anon_bitfields (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_c_wchar (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_longlong (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_mixed_1 (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_mixed_2 (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_mixed_3 (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_mixed_4 (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_multi_bitfields_size (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_nonint_types (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_signed (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_single_bitfield_size (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_uint32 (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_uint32_swap_big_endian (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_uint32_swap_little_endian (ctypes.test.test_bitfields.BitFieldTest) 
... ok
test_uint64 (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_ulonglong (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_unsigned (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_ints (ctypes.test.test_bitfields.C_Test) ... FAIL
test_shorts (ctypes.test.test_bitfields.C_Test) ... FAIL

==
FAIL: test_ints (ctypes.test.test_bitfields.C_Test)
--
Traceback (most recent call last):
   File 
"/data/prj/aixtools/python/python-3.5.1.2/Lib/ctypes/test/test_bitfields.py", 
line 41, in test_ints
 self.assertEqual(getattr(b, name), func(byref(b), 
name.encode('ascii')))
AssertionError: -1 != 1

==
FAIL: test_shorts (ctypes.test.test_bitfields.C_Test)
--
Traceback (most recent call last):
   File 
"/data/prj/aixtools/python/python-3.5.1.2/Lib/ctypes/test/test_bitfields.py", 
line 48, in test_shorts
 self.assertEqual(getattr(b, name), func(byref(b), 
name.encode('ascii')))
AssertionError: -1 != 1

--
Ran 19 tests in 0.013s

FAILED (failures=2)

> What I am suggesting as a fix is to change line 381 from plain “int” to 
> “signed int”, and 382 to “signed short”. I can make a patch later if that 
> will help. Hopefully with these changes the C compiler will use signed 
> integer logic, matching what I believe the ctypes library uses for c_int and 
> c_short.
Working from Python-2.7.12 - added your changes, test still fails:

root@x064:[/data/prj/aixtools/python/python-2.7.12.0]./python -m 
unittest -v ctypes.test.test_bitfields
test_anon_bitfields (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_c_wchar (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_longlong (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_mixed_1 (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_mixed_2 (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_mixed_3 (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_mixed_4 (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_multi_bitfields_size (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_nonint_types (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_signed (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_single_bitfield_size (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_uint32 (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_uint32_swap_big_endian (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_uint32_swap_little_endian (ctypes.test.test_bitfields.BitFieldTest) 
... ok
test_uint64 (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_ulonglong (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_unsigned (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_ints (ctypes.test.test_bitfields.C_Test) ... ok
test_shorts (ctypes.test.test_bitfields.C_Test) ... FAIL

==
FAIL: test_shorts (ctypes.test.test_bitfields.C_Test)
--
Traceback (most recent call last):
   File 
"/data/prj/aixtools/python/python-2.7.12.0/Lib/ctypes/test/test_bitfields.py", 
line 48, in test_shorts
 

[issue27632] build on AIX fails when builddir != srcdir, more than bad path to ld_so_aix

[Michael Felt]

Michael Felt added the comment:

Yes, clearly related (maybe even duplicate).

What surprised me is that after I copied ld_so_aix to where it was expected I 
still see a premature end with:

Traceback (most recent call last):
  File "/var/aixtools/python/Python/2.7.12.0/opt/lib/python2.7/compileall.py", 
line 16, in 
import struct
  File "/var/aixtools/python/Python/2.7.12.0/opt/lib/python2.7/struct.py", line 
1, in 
from _struct import *
ImportError: No module named _struct

Not investigated (compileall.py and struct.py - these are the DESTDIR versions 
(asin "make DESTDIR=/var/aixtools/python/Python/2.7.12.0 install"

So, this would be, I think, the "new aka non-duplicate" part. If not, my 
apologies for the noise.

--

___
Python tracker 

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

[issue27661] Add tzinfo= argument to datetime.combine

[SilentGhost]

Changes by SilentGhost :


--
nosy: +SilentGhost

___
Python tracker 

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

[issue27575] dict viewkeys intersection slow for large dicts

[David Su]

Changes by David Su :


Added file: http://bugs.python.org/file43961/performance_test.sh

___
Python tracker 

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

[issue27575] dict viewkeys intersection slow for large dicts

[David Su]

Changes by David Su :


Added file: http://bugs.python.org/file43960/dictview_intersection_test.py

___
Python tracker 

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

[issue12319] [http.client] HTTPConnection.request not support "chunked" Transfer-Encoding to send data

[Rolf Krahl]

Rolf Krahl added the comment:

*ping*

It's more then four weeks ago that I revised my patch, still waiting for 
review.  I also still need feedback on the question whether the new 
EncodingError exception introduced by Damien should be kept or whether I should 
change this to a ValueError.

--

___
Python tracker 

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

[issue27575] dict viewkeys intersection slow for large dicts

[David Su]

David Su added the comment:

Attached is a patch that I had been working on. Could you please review and 
provide me with some feedback? Thanks!

--
keywords: +patch
Added file: http://bugs.python.org/file43959/dict_view_intersection.patch

___
Python tracker 

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

[issue1621] Do not assume signed integer overflow behavior

[Antti Haapala]

Antti Haapala added the comment:

I don't believe Python would really ever work on a platform with 
non-8-bit-bytes, I believe there are way too much assumptions *everywhere*. You 
can program in C on such a platform, yes, but not that sure about Python.

And on 8-bit-byte platfomrs, there is no large model with 16-bit pointers 
anywhere. There just are not enough bits that you could have multiple 64k 
byte-addressable segments that are addressed with 16-bit pointers. 

It might be that some obscure platform in the past would have had 128k memory, 
with large pointers, 2 allocatable 64k segments, >16 bit char pointer and 
16-bit object pointers pointing to even bytes, but I doubt you'd be really 
porting *Python 3* to such a platform, basically we're talking about something 
like Commodore 128 here.

--

___
Python tracker 

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