[issue22746] cgitb html: wrong encoding for utf-8

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

We can convert cgitb.hook to produce ASCII-compatible output with charrefs in 
3.x. But there is a problem with str in 2.7. 8-bit string can contain non-ASCII 
data and the encoding is not known in general case.

--

___
Python tracker 

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

[issue22721] pprint output for sets and dicts is not stable

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

My question to Raymond is should we use the "<" operator or special methods 
__lt__ and __gt__ (this is the difference between alternative patches)?

The use of repr instead of id is different issue.

--

___
Python tracker 

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

[issue16569] Preventing errors of simultaneous access in zipfile

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Closed in favor of issue14099.

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

[issue14099] ZipFile.open() should not reopen the underlying file

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Thanks Stepan for the idea.

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

[issue17401] io.FileIO closefd parameter is not documented nor shown in repr

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Arfrever have suggested on IRC to backport documentation part of the patch to 
3.4.

--

___
Python tracker 

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

[issue14099] ZipFile.open() should not reopen the underlying file

[Roundup Robot]

Roundup Robot added the comment:

New changeset c2c4cde55f6f by Serhiy Storchaka in branch '2.7':
Issue #14099: ZipFile.open() no longer reopen the underlying file.  Objects
https://hg.python.org/cpython/rev/c2c4cde55f6f

New changeset e5bb3044402b by Serhiy Storchaka in branch '3.4':
Issue #14099: ZipFile.open() no longer reopen the underlying file.  Objects
https://hg.python.org/cpython/rev/e5bb3044402b

New changeset 334c01aa7f93 by Serhiy Storchaka in branch 'default':
Issue #14099: ZipFile.open() no longer reopen the underlying file.  Objects
https://hg.python.org/cpython/rev/334c01aa7f93

--
nosy: +python-dev

___
Python tracker 

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

[issue22968] Lib/types.py nit: isinstance != PyType_IsSubtype

[Greg Turner]

Changes by Greg Turner :


--
title: types._calculate_meta nit: isinstance != PyType_IsSubtype -> 
Lib/types.py nit: isinstance != PyType_IsSubtype

___
Python tracker 

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

[issue22968] types._calculate_meta nit: isinstance != PyType_IsSubtype

[Greg Turner]

Greg Turner added the comment:

> perhaps "isinstance(x, type)" should have been "issubclass(x, type)" to 
> correctly capture how python 2 does it.

Actually, scratch that -- its a brain fart.

IIUC new_class was created because, at the time, there was no exposed turnkey 
method to execute the PEP3115 protocol... if that's right, is it worth 
considering, now that __build_class__ is exposed, a reimplementation like:

def _pass(ns): pass

def new_class(name, bases=(), kwds={}, exec_body=_pass):
__build_class__(exec_body, name, *bases, **kwds)

?  But this is the wrong place to ask.

...

BTW, since my original post I've figured out a bunch of things, or think I have:

* new_class should model __build_class__

* __build_class__ need not model type_new in terms of what it allows.

I think point one is what was confusing me before.

It is perhaps worth asking, if the differences between type_new and 
__build_class__ make sense, given that python 3's type_new is stricter than 
python 2's?  I think I've figured that out too:

A given (metatype, bases) tuple may be sensibly used to implement the PEP3115 
protocol only if either:

  A) it can be proved that type_new will return NULL if it
 is invoked like type_new(metatype, name, bases,...), or,

  B) it can be proved that type_new, when invoked like
 type_new(metatype, name, bases, ...), will use metatype,
 and not some other (e.g., more derived) type, as the tp_base
 of the thing it creates, in the event that it does not return NULL.

If the above is falsified, we pretty clearly have a situation where build_type 
has used the wrong metaclass.

But the fact that __build_class__ is more liberal than type_new is not a 
problem from the perspective of type_new -- indeed it's a feature, and I'm now 
satisfied that the above constraint holds.

I've attached a new patch, this time I tested it.

--
Added file: http://bugs.python.org/file37348/fix_types_calculate_meta_v2.patch

___
Python tracker 

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

[issue21963] 2.7.8 backport of Issue1856 (avoid daemon thread problems at shutdown) breaks ceph

[Dan Mick]

Dan Mick added the comment:

Belaboring this a bit just in case what I learn helps with the interpreter 
change: 

seems like threading.Thread.start() is hanging in its normal "wait for start" 
code:

(gdb) py-bt
#4 Frame 0x25d4de0, for file /usr/lib64/python2.7/threading.py, line 339, in 
wait (self=<_Condition(_Verbose__verbose=False, _Condition__lock=, acquire=, _Condition__waiters=[], release=) at remote 0x7fe618b29110>, timeout=None, 
balancing=True, waiter=, saved_state=None)
waiter.acquire()
#8 Frame 0x7fe618b06d38, for file /usr/lib64/python2.7/threading.py, line 623, 
in wait (self=<_Event(_Verbose__verbose=False, _Event__flag=False, 
_Event__cond=<_Condition(_Verbose__verbose=False, _Condition__lock=, acquire=, _Condition__waiters=[], release=) at remote 0x7fe618b29110>) at remote 0x7fe6176a76d0>, 
timeout=None, balancing=True)
self.__cond.wait(timeout, balancing)
#12 Frame 0x7fe6175917d0, for file /usr/lib64/python2.7/threading.py, line 753, 
in start (self=, 
_Thread__block=<_Condition(_Verbose__verbose=False, 
_Condition__lock=, acquire=, 
_Condition__waiters=[], release=) at remote 0x7fe618b29150>, 
_Thread__name='Thread-11', _Thread__daemonic=True, args=(,), _Thread__started=<_Event(_Verbose__verbose=False, 
_Event__flag=False, _Event__cond=<_Condition(_Verbose__verbose=False, 
_Condition__lock=, acquire=, 
_Condition__waiters=[], release=, args=(,), timeout=0, 
sys=, interrupt=False, countdown=0, 
t=, 
_Thread__block=<_Condition(_Verbose__verbose=False, 
_Condition__lock=, acquire=, 
_Condition__waiters=[], release=) at remote 0x7fe618b29150>, 
_Thread__name='Thread-11', _Thread__daemonic=True, args=(...), 
_Thread__started=<_Event(_Verbose__verbose=False, _Event__flag=False, 
_Event__cond=<_Condition(_Verbose__verbose=False, _Condition__lock=, acquire=, _Condition__waiters=[, 
state='connected', librados=, rados_mon_command=<_FuncPtr(__name__='rados_mon_command') at remote 
0x7fe617611a10>, rados_buffer_free=<_FuncPtr(__name__='rados_buffer_free') at 
remote 0x7fe617611ae0>, rados_conf_set=<_FuncPtr(__name__='rados_conf_set') at 
remote 0x7fe6176117a0>, _handle=39608352, _name='librados.so.2', 
rados_create2=<_FuncPtr(__name__='rados_create2') at remote 0x7fe6176116d0>, 
rados_conf_read_file=<_FuncPtr(__name__='rados_conf_read_file') at remote 
0x7fe617611870>, rados_connect=<_FuncPtr(__name__='rados_connect') at remote 
0x7fe617611940>, rados_shutdown=<_FuncPtr(__name__='rados_shutdown') at remote 
0x7fe617611bb0>) at remote 0x7fe617572a10>, rados_id=None) at remote 
0x7fe6175729d0>)
run_in_thread(self.librados.rados_shutdown, (self.cluster,))
#22 Frame 0x7fe617683c20, for file /usr/lib/python2.7/site-packages/rados.py, 
line 264, in __del__ (self=, 
state='connected', librados=, rados_mon_command=<_FuncPtr(__name__='rados_mon_command') at remote 
0x7fe617611a10>, rados_buffer_free=<_FuncPtr(__name__='rados_buffer_free') at 
remote 0x7fe617611ae0>, rados_conf_set=<_FuncPtr(__name__='rados_conf_set') at 
remote 0x7fe6176117a0>, _handle=39608352, _name='librados.so.2', 
rados_create2=<_FuncPtr(__name__='rados_create2') at remote 0x7fe6176116d0>, 
rados_conf_read_file=<_FuncPtr(__name__='rados_conf_read_file') at remote 
0x7fe617611870>, rados_connect=<_FuncPtr(__name__='rados_connect') at remote 
0x7fe617611940>, rados_shutdown=<_FuncPtr(__name__='rados_shutdown') at remote 
0x7fe617611bb0>) at remote 0x7fe617572a10>, rados_id=None) at remote 
0x7fe6175729d0>)
self.shutdown()

--

___
Python tracker 

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

[issue22980] C extension naming doesn't take bitness into account

[Ned Deily]

Ned Deily added the comment:

Re PEP 3149 file names: it hadn't struck me until fairly recently that PEP 
3149-style extension file names were never implemented for OS X, i.e. they are 
still of the form _helperlib.so.  I'm not sure why that is the case since other 
aspects of PEP 3149-like file names do exist on OS X, including naming 
libpython; perhaps it was just erring on the side of caution.

Re bitness: As Marc-Andre points out, Apple addressed the multi-arch problem 
with the concept of universal (or "fat") binary files, implemented for 
executables, libs (static and dynamic), and bundles (e.g .so's).  In general, 
dealing with multiple architectures is abstracted away by the compiler tool 
chain at build time and the dynamic loader at run time and it's not something 
either Python or the user have to deal with (usually), as various combinations 
of architectures (currently up to 4 on OS X) are contained within the same 
file; for example:

$ file _socket.so
_socket.so: Mach-O universal binary with 3 architectures
_socket.so (for architecture x86_64):   Mach-O 64-bit bundle x86_64
_socket.so (for architecture i386): Mach-O bundle i386
_socket.so (for architecture ppc7400):  Mach-O bundle ppc
$ file /usr/bin/python
/usr/bin/python: Mach-O universal binary with 3 architectures
/usr/bin/python (for architecture x86_64):  Mach-O 64-bit executable x86_64
/usr/bin/python (for architecture i386):Mach-O executable i386
/usr/bin/python (for architecture ppc7400): Mach-O executable ppc

So, I agree with Marc-Andre that adding arch info (like bitiness) to extension 
module file names on OS X would add unneeded complexity for little, if any, 
benefit.  That part works well today.  Changing builds on OS X to use today's 
PEP 3149 file names is a separate question.  It could help in the case where 
one site-packages library is used with multiple Python instances but, even 
there, that is probably not a big issue outside of developer environments: (1) 
I don't know of any distributor of Python for OS X who supports multiple ABIs 
(e.g. non-debug vs debug) in one package; (2) Python OS X framework builds, 
used by python.org, Apple, and most third-parties, generally have separate 
install locations including their lib-dynload and site-packages directories so 
installing multiple instances of the same Python version from different vendors 
isn't a big deal.  It would be nice to be able to allow non-debug vs debug 
builds to co-exist better (the primary use case I see for PEP 3149 file
  names for Py3 on OS X) but I don't recall anyone asking for it.  If we were 
to change OS X to use today's PEP 3149 file names, I would only want to do it 
in a new release, not backport it.

--

___
Python tracker 

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

[issue22986] Improved handling of __class__ assignment

[Eric Snow]

Changes by Eric Snow :


--
nosy: +eric.snow

___
Python tracker 

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

[issue22986] Improved handling of __class__ assignment

[Nick Coghlan]

Changes by Nick Coghlan :


--
nosy: +ncoghlan

___
Python tracker 

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

[issue22986] Improved handling of __class__ assignment

[Nathaniel Smith]

Nathaniel Smith added the comment:

Here's a slightly improved patch spurred by a parenthetical comment of 
Antoine's on the mailing list :-).

The only change is that it adds a check in subclass_dealloc to correct the 
reference counting in the weird case that someone converts a HEAPTYPE object 
into a non-HEAPTYPE object while it is being deallocated.

I should probably also mention that I ran the full test suite against the 
patched version and everything passed; and with -R 3:2 the only difference is a 
new reference leak in test_zipfile. I'm guessing this might be spurious, given 
that AFAIK this test shouldn't be touching __class__ assignment at all? But IDK.

--
Added file: 
http://bugs.python.org/file37347/better-__class__-assignment-v2.patch

___
Python tracker 

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

[issue22980] C extension naming doesn't take bitness into account

[Nick Coghlan]

Nick Coghlan added the comment:

My initial thought is to add an "abitags" attribute to sys.implementation
(plural so we can also indicate stable ABI support).

If we define the algorithm clearly, then setuptools & distlib could make it
available on earlier Python versions.

--

___
Python tracker 

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

[issue14134] xmlrpc.client.ServerProxy needs timeout parameter

[Florent Xicluna]

Changes by Florent Xicluna :


--
nosy: +flox
versions: +Python 3.5 -Python 3.3

___
Python tracker 

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

[issue22986] Improved handling of __class__ assignment

[Ethan Furman]

Changes by Ethan Furman :


--
nosy: +ethan.furman

___
Python tracker 

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

[issue12987] Demo/scripts/newslist.py has non-free licensing terms

[Roundup Robot]

Roundup Robot added the comment:

New changeset 54af09408795 by Benjamin Peterson in branch '2.7':
nuke ancient script with dubious license (closes #12987)
https://hg.python.org/cpython/rev/54af09408795

--
nosy: +python-dev
resolution:  -> fixed
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

[issue22986] Improved handling of __class__ assignment

[Nathaniel Smith]

New submission from Nathaniel Smith:

Following on from the discussion starting here:

http://thread.gmane.org/gmane.comp.python.devel/150438/focus=150604

Here's a patch to improve __class__ assignment.

1) We remove the HEAPTYPE check from object_set_class, and move it to 
same_slots_added. This fixes an outright bug: previously it was possible for 
non-HEAPTYPE types to get passed into same_slots_added (either b/c the loop in 
compatible_for_assignment ended up with non-HEAPTYPE types, or via __bases__ 
assignment), and it would then wander off following pointers through random 
memory.

2) Now that object_set_class can potentially accept non-HEAPTYPE types, adjust 
the reference counting appropriately.

3) To clarify the logic of compatible_for_assignment, rename equiv_structs to 
compatible_with_tp_base, tweak accordingly, and add a nice comment explaining 
the logic. (compatible_for_assignment is equiv_structs's only caller so this is 
totally safe.)

4) Now that equiv_structs/compatible_with_tp_base has a clearer purpose, also 
move the tp_dealloc check from compatible_for_assignment into 
compatible_with_tp_base. In the process, add special-case handling for 
subclass_dealloc, b/c subclass_dealloc delegates to the parent class tp_dealloc 
anyway.

These changes together make it possible to assign to module instances's 
__class__ slot, which is useful for reasons described in the above thread. So I 
added a test for this to check the new code.

--
components: Interpreter Core
files: better-__class__-assignment-v1.patch
keywords: patch
messages: 232061
nosy: njs
priority: normal
severity: normal
status: open
title: Improved handling of __class__ assignment
Added file: 
http://bugs.python.org/file37346/better-__class__-assignment-v1.patch

___
Python tracker 

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

[issue18053] Add checks for Misc/NEWS in make patchcheck

[Terry J. Reedy]

Terry J. Reedy added the comment:

> As of now the patchcheck utility adds a notice to modify Misc/NEWS for every 
> patch.
Patchcheck truthfully reports whether /docs, ACKS, and NEWS have been modified. 
I do not read it as saying anything about whether they *should* be updated.  
For Docs and NEWS, *should* is a judgement call for core devs, which would be 
very hard to automate.  The only remotely simple check would be whether a NEWS 
item contains a name not in ACKS, and even that is only a suggestion.  So lets 
leave it alone.

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

[issue22985] Segfault on time.sleep

[Omer Katz]

New submission from Omer Katz:

I have found what appears to be a segfualt in time.sleep but I'm not sure.
I have verified that the segfualt occurs both on Python 2.7.8 and 3.4.2.

The following program that reproduces the segfault uses my fork of billiard, a 
replacement for the multiprocessing module that is used by celery.

In order to install: pip install 
git+https://github.com/thedrow/billiard@topic/dill-with-threads

The program:
from billiard.pool import ThreadPool

p1 = ThreadPool()

class Foo(object):
def a(self):
print("a")
return 1

def do(self):
return p1.apply_async(self.a)


foo = Foo()
r = foo.do()

print(r.get())
p1.close()
p1.join()

The output from gdb:
gdb -ex r -q --args python mt_example.py
Reading symbols from python...done.
Starting program: /home/omer/.virtualenvs/billiard/bin/python mt_example.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x731db700 (LWP 2897)]
[New Thread 0x729da700 (LWP 2898)]
[New Thread 0x721d9700 (LWP 2899)]
[New Thread 0x719d8700 (LWP 2900)]
[New Thread 0x711d7700 (LWP 2901)]
[New Thread 0x709d6700 (LWP 2902)]
[New Thread 0x7fffdbfff700 (LWP 2903)]

Program received signal SIGTERM, Terminated.
[Switching to Thread 0x721d9700 (LWP 2899)]
0x771dc1c3 in select () at ../sysdeps/unix/syscall-template.S:81
81  ../sysdeps/unix/syscall-template.S: No such file or directory.
(gdb) bt
#0  0x771dc1c3 in select () at ../sysdeps/unix/syscall-template.S:81
#1  0x75fd5d5d in floatsleep (secs=) at 
Modules/timemodule.c:948
#2  time_sleep (self=, args=) at 
Modules/timemodule.c:206
#3  0x004b658c in call_function (oparg=, 
pp_stack=0x721d8540) at Python/ceval.c:4033
#4  PyEval_EvalFrameEx (f=f@entry=0x7463eda8, throwflag=throwflag@entry=0) 
at Python/ceval.c:2679
#5  0x004b6f6b in PyEval_EvalCodeEx (co=, 
globals=, locals=locals@entry=0x0, args=, 
argcount=argcount@entry=4, kws=, kwcount=0, 
defs=0x740bab68, defcount=1, closure=0x0) at Python/ceval.c:3265
#6  0x004b5b28 in fast_function (nk=, na=4, n=, pp_stack=0x721d8730, func=0x731e2938)
at Python/ceval.c:4129
#7  call_function (oparg=, pp_stack=0x721d8730) at 
Python/ceval.c:4054
#8  PyEval_EvalFrameEx (f=f@entry=0x7fffe8000b50, throwflag=throwflag@entry=0) 
at Python/ceval.c:2679
#9  0x004b6f6b in PyEval_EvalCodeEx (co=, 
globals=, locals=locals@entry=0x0, args=, 
argcount=argcount@entry=1, kws=, kwcount=0, defs=0x0, 
defcount=0, closure=0x0) at Python/ceval.c:3265
#10 0x004b5b28 in fast_function (nk=, na=1, n=, pp_stack=0x721d8920, func=0x731e28c0)
at Python/ceval.c:4129
#11 call_function (oparg=, pp_stack=0x721d8920) at 
Python/ceval.c:4054
#12 PyEval_EvalFrameEx (f=f@entry=0x7fffe8000910, throwflag=throwflag@entry=0) 
at Python/ceval.c:2679
#13 0x004b5bc7 in fast_function (nk=, na=1, n=, pp_stack=0x721d8a70, func=0x77e55230)
---Type  to continue, or q  to quit---
at Python/ceval.c:4119
#14 call_function (oparg=, pp_stack=0x721d8a70) at 
Python/ceval.c:4054
#15 PyEval_EvalFrameEx (f=f@entry=0x731f1210, throwflag=throwflag@entry=0) 
at Python/ceval.c:2679
#16 0x004b6f6b in PyEval_EvalCodeEx (co=, 
globals=, locals=locals@entry=0x0, 
args=args@entry=0x731dca68, argcount=, 
kws=kws@entry=0x0, kwcount=kwcount@entry=0, defs=defs@entry=0x0, 
defcount=defcount@entry=0, closure=0x0) at Python/ceval.c:3265
#17 0x00529e70 in function_call (func=0x77e55140, 
arg=0x731dca50, kw=0x0) at Objects/funcobject.c:526
#18 0x00422f5a in PyObject_Call (func=func@entry=0x77e55140, 
arg=arg@entry=0x731dca50, kw=kw@entry=0x0)
at Objects/abstract.c:2529
#19 0x0042747d in instancemethod_call (func=0x77e55140, 
arg=0x731dca50, kw=0x0) at Objects/classobject.c:2602
#20 0x00422f5a in PyObject_Call (func=func@entry=0x74636d70, 
arg=arg@entry=0x77f93050, kw=)
at Objects/abstract.c:2529
#21 0x004b07f7 in PyEval_CallObjectWithKeywords (func=0x74636d70, 
arg=0x77f93050, kw=) at Python/ceval.c:3902
#22 0x004fae92 in t_bootstrap (boot_raw=0x8899c0) at 
./Modules/threadmodule.c:614
#23 0x77bc40a5 in start_thread (arg=0x721d9700) at 
pthread_create.c:309
#24 0x771e484d in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:111

--
components: Interpreter Core
messages: 232059
nosy: Omer.Katz
priority: normal
severity: normal
status: open
title: Segfault on time.sleep
type: crash
versions: Python 2.7, Python 3.4

___
Python tracker 

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

[issue13027] python 2.6.6 interpreter core dumps on modules command from help prompt

[Terry J. Reedy]

Terry J. Reedy added the comment:

I would close this anyway, but 2.6 is no longer maintained even for security 
patches.

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

[issue18967] Find a less conflict prone approach to Misc/NEWS

[Terry J. Reedy]

Terry J. Reedy added the comment:

Thanks for the reminder/suggestion.  Re-reading Ezio's two patches 
(newsmerge.py and .hg/hgrc additions in msg217079), they appear to jointly 
automate what I now do by hand (revert to local and dump merge artifacts, 
replace with edited file with new entries pasted in, and mark as resolved) .  I 
also checked that the current Windows installers make .py files executable, so 
hg should be able to run newsmerge on Windows.  I have downloaded the file and 
made the additions to my 3.5 hgrc to test next time I have a news entry.

--

___
Python tracker 

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

[issue22976] multiprocessing Queue empty() is broken on Windows

[eryksun]

eryksun added the comment:

This also hangs for me in 2.7.8 64-bit, Windows 7. To poll the pipe, the parent 
process calls PeekNamedPipe, which blocks because the child has already called 
ReadFile.

> It is possible that the problem is also present in Python 3.

multiprocessing switched to overlapped I/O in 3.3, which avoids this problem.

--
nosy: +eryksun

___
Python tracker 

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

[issue14099] ZipFile.open() should not reopen the underlying file

[David Wilson]

David Wilson added the comment:

Sounds great :)

--

___
Python tracker 

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

[issue17401] io.FileIO closefd parameter is not documented nor shown in repr

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


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

___
Python tracker 

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

[issue22984] test_json.test_endless_recursion(): "Fatal Python error: Cannot recover from stack overflow." on x86 XP-4 3.x buildbot

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

JSON encoder uses recursion calls guards but they don't save from an overflow 
of C stack.

How to reproduce:

import json
sys.setrecursionlimit(10)
json.dumps(5j, check_circular=False, default=lambda o: [o])

--
components: +Extension Modules

___
Python tracker 

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

[issue12987] Demo/scripts/newslist.py has non-free licensing terms

[Terry J. Reedy]

Terry J. Reedy added the comment:

If we are going to backport the removal from the distribution of 
Demo/scripts/newslist.py to 2.7, it might as well be done immediately, before 
2.7.9 goes out.  Benjamin?

I am more concerned about separately licensed stdlib modules, such as turtle* 
(and others).  Do they all properly 'fall under the PSF license'?  Has this 
been systematically checked (and recorded)?  Is there a policy in place with 
respect to new modules?

* G.Lingl said in email he would sign he contributor agreement in August, but 
none is recorded yet.

--
nosy: +benjamin.peterson

___
Python tracker 

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

[issue22984] test_json.test_endless_recursion(): "Fatal Python error: Cannot recover from stack overflow." on x86 XP-4 3.x buildbot

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue22980] C extension naming doesn't take bitness into account

[STINNER Victor]

STINNER Victor added the comment:

Would it be possible to add something to the sys module, computed
during the compilation, instead of having to rely on platform,
sysconfig, struct or something else?

Note: There is also the funnny x32 platform project :-)
https://sites.google.com/site/x32abi/ 32-bit pointer on 64-bit CPU.

--

___
Python tracker 

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

[issue17401] io.FileIO closefd parameter is not documented nor shown in repr

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Committed the first patch (showing closefd always) with additional test from 
second path.

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

[issue17401] io.FileIO closefd parameter is not documented nor shown in repr

[Roundup Robot]

Roundup Robot added the comment:

New changeset fd80195b920f by Serhiy Storchaka in branch 'default':
Issue #17401: Output the closefd attribute as boolean.
https://hg.python.org/cpython/rev/fd80195b920f

--

___
Python tracker 

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

[issue22977] Unformatted “Windows Error 0x%X” exception message on Wine

[STINNER Victor]

Changes by STINNER Victor :


--
title: Unformatted “Windows Error 0x%X” exception message -> Unformatted 
“Windows Error 0x%X” exception message on Wine

___
Python tracker 

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

[issue22971] test_pickle: "Fatal Python error: Cannot recover from stack overflow." on FreeBSD buildbot

[STINNER Victor]

Changes by STINNER Victor :


--
components: +Windows
nosy: +steve.dower, tim.golden, zach.ware

___
Python tracker 

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

[issue22984] test_json.test_endless_recursion(): "Fatal Python error: Cannot recover from stack overflow." on x86 XP-4 3.x buildbot

[STINNER Victor]

New submission from STINNER Victor:

http://buildbot.python.org/all/builders/x86%20XP-4%203.x/builds/11271/steps/test/logs/stdio

[116/390] test_json
Fatal Python error: Cannot recover from stack overflow.

Current thread 0x0e84 (most recent call first):
  File 
"d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\json\encoder.py", 
line 250 in iterencode
  File 
"d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\json\encoder.py", 
line 192 in encode
  File 
"d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_json\test_recursion.py",
 line 96 in test_endless_recursion
  File 
"d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\case.py", 
line 577 in run
  File 
"d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\case.py", 
line 625 in __call__
  File 
"d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\suite.py", 
line 125 in run
  File 
"d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\suite.py", 
line 87 in __call__
  File 
"d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\suite.py", 
line 125 in run
  File 
"d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\suite.py", 
line 87 in __call__
  File 
"d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\suite.py", 
line 125 in run
  File 
"d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\suite.py", 
line 87 in __call__
  File 
"d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\suite.py", 
line 125 in run
  File 
"d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\suite.py", 
line 87 in __call__
  File 
"d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\suite.py", 
line 125 in run
  File 
"d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\suite.py", 
line 87 in __call__
  File 
"d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\runner.py", 
line 168 in run
  File 
"d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\support\__init__.py",
 line 1769 in _run_suite
  File 
"d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\support\__init__.py",
 line 1803 in run_unittest
  File 
"d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\PCbuild\..\lib\test\regrtest.py",
 line 1279 in test_runner
  File 
"d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\PCbuild\..\lib\test\regrtest.py",
 line 1280 in runtest_inner
  File 
"d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\PCbuild\..\lib\test\regrtest.py",
 line 967 in runtest
  File 
"d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\PCbuild\..\lib\test\regrtest.py",
 line 763 in main
  File 
"d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\PCbuild\..\lib\test\regrtest.py",
 line 1564 in main_in_temp_cwd
  File 
"d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\PCbuild\..\lib\test\regrtest.py",
 line 1589 in 

--
components: Tests
keywords: buildbot
messages: 232049
nosy: haypo
priority: normal
severity: normal
status: open
title: test_json.test_endless_recursion(): "Fatal Python error: Cannot recover 
from stack overflow." on x86 XP-4 3.x buildbot
type: crash
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

[issue14099] ZipFile.open() should not reopen the underlying file

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

How about just "Objects returned by :meth:`.open` can operate independently of 
the ZipFile."?

--

___
Python tracker 

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

[issue22980] C extension naming doesn't take bitness into account

[Marc-Andre Lemburg]

Marc-Andre Lemburg added the comment:

On 02.12.2014 20:10, Antoine Pitrou wrote:
> 
> Antoine Pitrou added the comment:
> 
> Le 02/12/2014 19:59, Marc-Andre Lemburg a écrit :
>>
>> My main point was that we shouldn't start adding tags for e.g.
>> PPC, Intel, ARM, etc. since platforms needing to support multiple
>> such architectures will typically support fat builds anyway.
>>
>> How about using these flags:
>>
>> b0 - 16-bit
>> b1 - 32-bit
>> b2 - 64-bit
>> b3 - 128-bit
> 
> Fair enough, although I think we only need 32-bit and 64-bit for now,
> and "32b" vs. "64b" would probably be more readable :-)

True, I'm just not sure what the parsing requirements are and
the ABI version names are too long already, IMO. PEP 425 used
a nice short variant for the Python part.

--

___
Python tracker 

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

[issue22977] Unformatted “Windows Error 0x%X” exception message

[eryksun]

eryksun added the comment:

This also affects SEH-related exceptions raised by ctypes. For example, VC++ 
uses exception code 0xE06D7363 (i.e. b'\xe0msc'), so unhandled VC++ exceptions 
leak into Python like  this:

>>> ctypes.windll.kernel32.RaiseException(0xe06d7363, 0, 0, None)
Traceback (most recent call last):
  File "", line 1, in 
OSError: [WinError -529697949] Windows Error 0x%X

The ctypes SEH handler defaults to calling PyErr_SetFromWindowsErr(code). Since 
this isn't actually a Windows error code, Win32 FormatMessageW fails. Then 
Python uses the following default: PyUnicode_FromFormat("Windows Error 0x%X", 
err). 

Normally (i.e. not under Wine) the OP's error number formats correctly:

>>> ctypes.windll.kernel32.RaiseException(10054, 0, 0, None) 
Traceback (most recent call last):
  File "", line 1, in 
ConnectionResetError: [WinError 10054] An existing connection was forcibly 
closed by the remote host

PyErr_SetExcFromWindowsErrWithFilenameObjects
https://hg.python.org/cpython/file/ab2c023a9432/Python/errors.c#l553

PyErr_SetFromErrnoWithFilenameObjects
https://hg.python.org/cpython/file/ab2c023a9432/Python/errors.c#l416

--
nosy: +eryksun

___
Python tracker 

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

[issue22980] C extension naming doesn't take bitness into account

[Antoine Pitrou]

Antoine Pitrou added the comment:

Le 02/12/2014 19:59, Marc-Andre Lemburg a écrit :
> 
> My main point was that we shouldn't start adding tags for e.g.
> PPC, Intel, ARM, etc. since platforms needing to support multiple
> such architectures will typically support fat builds anyway.
> 
> How about using these flags:
> 
> b0 - 16-bit
> b1 - 32-bit
> b2 - 64-bit
> b3 - 128-bit

Fair enough, although I think we only need 32-bit and 64-bit for now,
and "32b" vs. "64b" would probably be more readable :-)

--

___
Python tracker 

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

[issue22980] C extension naming doesn't take bitness into account

[Marc-Andre Lemburg]

Marc-Andre Lemburg added the comment:

On 02.12.2014 19:46, Antoine Pitrou wrote:
> 
>> Note that on Linux, 32-bit and 64-bit versions are typically placed
>> into different directory trees
> 
> By whom? Our standard installer doesn't (it uses ../lib/python-X.Y for all 
> builds).

By the system vendors. Packages (with extensions) will automatically
pick up their configuration.

> Also, one of the problems (and actually the problem which triggered this 
> tracker entry) is when doing development inside a working copy (either 
> through "setup.py develop" or "setup.py build_ext --inplace" - both copy C 
> extensions directly into the source tree).

Fair enough; it's a rare use case, but may be worth supporting.

My main point was that we shouldn't start adding tags for e.g.
PPC, Intel, ARM, etc. since platforms needing to support multiple
such architectures will typically support fat builds anyway.

How about using these flags:

b0 - 16-bit
b1 - 32-bit
b2 - 64-bit
b3 - 128-bit
and so on

--

___
Python tracker 

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

[issue22980] C extension naming doesn't take bitness into account

[Steve Dower]

Steve Dower added the comment:

@Antoine: You're right. I hereby withdraw all contributions to this thread 
after my first statement of support :)

--

___
Python tracker 

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

[issue22980] C extension naming doesn't take bitness into account

[Antoine Pitrou]

Antoine Pitrou added the comment:

@Steve: IIRC, pyc files should be portable, so there's no need to differentiate 
between various bitnesses.

--

___
Python tracker 

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

[issue22980] C extension naming doesn't take bitness into account

[Antoine Pitrou]

Antoine Pitrou added the comment:

> Note that on Linux, 32-bit and 64-bit versions are typically placed
> into different directory trees

By whom? Our standard installer doesn't (it uses ../lib/python-X.Y for all 
builds).

Also, one of the problems (and actually the problem which triggered this 
tracker entry) is when doing development inside a working copy (either through 
"setup.py develop" or "setup.py build_ext --inplace" - both copy C extensions 
directly into the source tree).

--

___
Python tracker 

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

[issue22980] C extension naming doesn't take bitness into account

[Marc-Andre Lemburg]

Marc-Andre Lemburg added the comment:

On 02.12.2014 19:40, Steve Dower wrote:
> 
> I was more interested in source file resolution than bytecode caching. If 
> Python 3.5 would prefer "spam.cpython-35.py" or "spam.cpython-3.py" over 
> "spam.py" and Python 2 preferred "spam.py", then I can more easily separate 
> the code that won't parse in the alternative.
> 
> Happy to be told it's unrelated and I should raise it separately, but from my 
> POV resolving .pyd filenames looks very similar to resolving .py files.

That's an interesting idea, but indeed unrelated to this ticket :-)

--

___
Python tracker 

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

[issue22980] C extension naming doesn't take bitness into account

[Steve Dower]

Steve Dower added the comment:

But since you pointed out cache-tag, should that distinguish for bitness as 
well? It seems to be 'cpython-34' for both 32-bit and 64-bit interpreters on 
Windows, which isn't really a problem now, but may become one if we start 
allowing/encouraging sharing packages between interpreters.

In fact, it probably is an issue now with user site-packages, since that path 
is the same for both 32-bit and 64-bit...

--

___
Python tracker 

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

[issue22980] C extension naming doesn't take bitness into account

[Antoine Pitrou]

Antoine Pitrou added the comment:

Fat binaries seem to exist under:
- OS X: yes, that's why I was asking for Ned's advice
- Linux: "A proof-of-concept Ubuntu 9.04 image is available"... enough said
- DOS: perhaps MicroPython is interested :-)

http://en.wikipedia.org/wiki/Fat_binary

--

___
Python tracker 

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

[issue22980] C extension naming doesn't take bitness into account

[Marc-Andre Lemburg]

Marc-Andre Lemburg added the comment:

On 02.12.2014 19:02, Antoine Pitrou wrote:
> Sticking to bitness should be easy (although I wonder if it would be 
> desirable for platforms with fat binaries - Ned?). If we can go the extra 
> mile and include platform identification all the better, of course.

I hear the "can of worms" alarm ringing :-)

Seriously, I think that putting platform infos into the file name
is bound to cause more trouble than it tries to solve. Fat builds
leave the decision to the linker, which is a good method and avoids
the file name clashes.

I think we should only focus on platforms where fat builds are
uncommon, while at the same time you do have to support multiple
architectures, like e.g. Windows:

http://en.wikipedia.org/wiki/Fat_binary

Note that on Linux, 32-bit and 64-bit versions are typically placed
into different directory trees:

http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

so I'm not sure whether it's a real problem on Linux.

--

___
Python tracker 

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

[issue22980] C extension naming doesn't take bitness into account

[Steve Dower]

Steve Dower added the comment:

I was more interested in source file resolution than bytecode caching. If 
Python 3.5 would prefer "spam.cpython-35.py" or "spam.cpython-3.py" over 
"spam.py" and Python 2 preferred "spam.py", then I can more easily separate the 
code that won't parse in the alternative.

Happy to be told it's unrelated and I should raise it separately, but from my 
POV resolving .pyd filenames looks very similar to resolving .py files.

--

___
Python tracker 

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

[issue14099] ZipFile.open() should not reopen the underlying file

[David Wilson]

David Wilson added the comment:

Could we also make a small tweak to zipfile.rst indicating the new behaviour? I 
had made an initial attempt in my patch but wasn't particularly happy with the 
wording.

--

___
Python tracker 

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

[issue22980] C extension naming doesn't take bitness into account

[Antoine Pitrou]

Antoine Pitrou added the comment:

> I assume the hard part will be getting the details for Linux (doesn't bitness 
> have to be compiled in there? For Windows it can be determined at compile-
> time...), but preferring an extension with the ABI tag and falling back on
> one without seems easy enough.

Sticking to bitness should be easy (although I wonder if it would be desirable 
for platforms with fat binaries - Ned?). If we can go the extra mile and 
include platform identification all the better, of course.

--

___
Python tracker 

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

[issue22980] C extension naming doesn't take bitness into account

[Antoine Pitrou]

Antoine Pitrou added the comment:

Nothing new should be necessary for pyc files under Windows:

Python 3.4.2 |Continuum Analytics, Inc.| (default, Oct 22 2014, 11:51:45) [MSC 
v.1600 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.implementation.cache_tag
'cpython-34'

The problem is with C extensions:

>>> import _imp
>>> _imp.extension_suffixes()
['.pyd']

Compare with Linux:

>>> import _imp
>>> _imp.extension_suffixes()
['.cpython-35dm.so', '.abi3.so', '.so']

--

___
Python tracker 

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

[issue14099] ZipFile.open() should not reopen the underlying file

[Benjamin Peterson]

Benjamin Peterson added the comment:

Okay for 2.7.10.

--

___
Python tracker 

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

[issue22980] C extension naming doesn't take bitness into account

[Antoine Pitrou]

Antoine Pitrou added the comment:

> Note that there's a difference between the platform's architecture

Yes, that's pointed out above.

--

___
Python tracker 

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

[issue22980] C extension naming doesn't take bitness into account

[Marc-Andre Lemburg]

Marc-Andre Lemburg added the comment:

Note that there's a difference between the platform's architecture (which is 
what get_platform() returns) and the pointer size of the currently running 
Python executable.

On 64-bit Linux, it's rather rare to have an application built as 32-bit 
executable. On 64-bit Windows, it's rather common to have 32-bit applications 
running.

The best way to determine 32-bit vs. 64-bit is by using the struct module:

# Determine bitsize used by Python (not necessarily the same as
# the one used by the platform)
import struct
bits = struct.calcsize('P') * 8

This should be portable across all platforms and will always refer to the 
pointer size of the currently running Python executable.

--
nosy: +lemburg

___
Python tracker 

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

[issue22983] Cookie parsing should be more permissive

[Demian Brecht]

Demian Brecht added the comment:

Sorry, bad example. Replace "[" in the previous example with any actually 
invalid character.

--

___
Python tracker 

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

[issue22983] Cookie parsing should be more permissive

[Demian Brecht]

Demian Brecht added the comment:

Sure, but this is in regards to the initial matching, not the parsing. Because 
the pattern expects RFC conformity, in this cookie string:

Cookie: a=b; c=[; d=r; f=h

The only matching parts will be:

Cookie: a=b;

The rest will be discarded. What I'm proposing is that this should instead 
result in:

Cookie: a=b; d=r; f=h

The recent changes would stay intact.

--

___
Python tracker 

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

[issue22966] py_compile: foo.bar.py → __pycache__/foo.cpython-34.pyc

[Barry A. Warsaw]

Barry A. Warsaw added the comment:

I already pushed a fix.

http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.4/builds/702/steps/test/logs/stdio

(although asyncio is still failing there but that should be unrelated)

--
status: open -> closed

___
Python tracker 

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

[issue22980] C extension naming doesn't take bitness into account

[Steve Dower]

Steve Dower added the comment:

I'm very much in favor of adding this for .pyds on Windows.

I assume the hard part will be getting the details for Linux (doesn't bitness 
have to be compiled in there? For Windows it can be determined at 
compile-time...), but preferring an extension with the ABI tag and falling back 
on one without seems easy enough.

(Would/could this also work for .py files? So a 2.7/3.x or 
Jython/CPython/IronPython package could include tags in pure-Python code files?)

--

___
Python tracker 

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

[issue22982] BOM incorrectly inserted before writing, after seeking in text file

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc added the comment:

issue5006 was supposed to take care of this, but it has a flaw IMO:
This statement 
https://hg.python.org/cpython/file/0744ceb5c0ed/Lib/_pyio.py#l2003 is missing 
an "and whence!=2".

--
nosy: +amaury.forgeotdarc

___
Python tracker 

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

[issue22983] Cookie parsing should be more permissive

[Antoine Pitrou]

Antoine Pitrou added the comment:

Well, remember that we recently made parsing stricter in response to a security 
issue...

--
nosy: +orsenthil, pitrou

___
Python tracker 

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

[issue20453] json.load() error message changed in 3.4

[Arfrever Frehtes Taifersar Arahesis]

Changes by Arfrever Frehtes Taifersar Arahesis :


--
nosy: +Arfrever

___
Python tracker 

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

[issue22475] asyncio task get_stack documentation seems to contradict itself

[STINNER Victor]

STINNER Victor added the comment:

I fixed the most obvious issue in the documentation. I don't know the function 
enough to propose a better documentation, sorry.

Don't hesitate to write a patch on the documentation if you have a better 
explanation of how get_stack() behaves.

It is correct that get_stack() only returns 1 frame if the task is suspended, 
whereas it returns more frames if get_stack() is called while the task is 
running.

--

___
Python tracker 

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

[issue19361] Specialize exceptions thrown by JSON parser

[Arfrever Frehtes Taifersar Arahesis]

Changes by Arfrever Frehtes Taifersar Arahesis :


--
nosy: +Arfrever

___
Python tracker 

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

[issue22475] asyncio task get_stack documentation seems to contradict itself

[Roundup Robot]

Roundup Robot added the comment:

New changeset 4b6b03c1f4ff by Victor Stinner in branch '3.4':
Closes #22475: asyncio doc, fix Task.get_stack() doc
https://hg.python.org/cpython/rev/4b6b03c1f4ff

--
nosy: +python-dev
resolution:  -> fixed
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

[issue22931] cookies with square brackets in value

[Demian Brecht]

Demian Brecht added the comment:

I do think it should be a little more permissive when parsing cookies. I've 
created #22983 to address that as to not conflate this issue, which the 
attached patch does address.

--

___
Python tracker 

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

[issue22914] Rewrite of Python 2/3 porting HOWTO

[Tshepang Lekhonkhobe]

Changes by Tshepang Lekhonkhobe :


--
nosy: +tshepang

___
Python tracker 

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

[issue22980] C extension naming doesn't take bitness into account

[Arfrever Frehtes Taifersar Arahesis]

Changes by Arfrever Frehtes Taifersar Arahesis :


--
nosy: +Arfrever

___
Python tracker 

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

[issue22983] Cookie parsing should be more permissive

[Demian Brecht]

New submission from Demian Brecht:

As found in #22931, if an invalid cookie value is found while parsing, the rest 
of the cookie is silently ignored. The expected behavior is undefined in RFC 
6265, but does state that if unexpected values are encountered that user agents 
MAY ignore an entire set-cookie string (not just a subsection of it). Given 
that, invalid cookie portions should likely be handled by either:

1. Ignore the cookie string in its entirety and log an error message, or
2. Ignore invalid cookie-pairs but still parse the rest of the string

The latter would likely be the best path (Postel's law and all)

--
components: Library (Lib)
messages: 232020
nosy: demian.brecht
priority: normal
severity: normal
status: open
title: Cookie parsing should be more permissive
type: enhancement
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

[issue22966] py_compile: foo.bar.py → __pycache__/foo.cpython-34.pyc

[Arfrever Frehtes Taifersar Arahesis]

Changes by Arfrever Frehtes Taifersar Arahesis :


--
nosy: +Arfrever

___
Python tracker 

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

[issue22473] The gloss on asyncio "future with run_forever" example is confusing

[STINNER Victor]

STINNER Victor added the comment:

I rephrase the explanation of the example and I removed the useless note. 
Thanks for your feedback David. Don't hesitate to propose other enhancements to 
the documentation!

--

___
Python tracker 

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

[issue22473] The gloss on asyncio "future with run_forever" example is confusing

[Roundup Robot]

Roundup Robot added the comment:

New changeset a4b58e779a16 by Victor Stinner in branch '3.4':
Close #22473: asyncio doc: rephrase Future with run_forever() example
https://hg.python.org/cpython/rev/a4b58e779a16

--
nosy: +python-dev
resolution:  -> fixed
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

[issue22685] memory leak: no transport for pipes by create_subprocess_exec/shell

[STINNER Victor]

STINNER Victor added the comment:

> Buildbot failures observed on koobs-freebsd9 and koobs-freebsd10 for 3.x and 
> 3.4, respectively.

It looks like test_asyncio pass on the last 5 builds of the following 
buildbots, and so I consider the issue as closed.

http://buildbot.python.org/all/builders/AMD64 FreeBSD 9.x 3.x
http://buildbot.python.org/all/builders/AMD64%20FreeBSD%2010.0%203.x

--

___
Python tracker 

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

[issue22980] C extension naming doesn't take bitness into account

[STINNER Victor]

STINNER Victor added the comment:

There is also platform.architecture(). I don't like its implementation, it 
relies on the external file program :-(

--

___
Python tracker 

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

[issue22966] py_compile: foo.bar.py → __pycache__/foo.cpython-34.pyc

[Brett Cannon]

Brett Cannon added the comment:

Apparently this broke under Windows: 
http://buildbot.python.org/all/builders/x86%20Windows7%203.x/builds/8999/steps/test/logs/stdio

--
status: closed -> open

___
Python tracker 

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

[issue22982] BOM incorrectly inserted before writing, after seeking in text file

[MarkIngramUK]

New submission from MarkIngramUK:

If you open a text file for append, but then perform any form of seeking, 
before attempting to write to the file, it will cause the BOM to be written 
before you text. See the attached file for an example.

If you run the test, take a look at the output file, and you'll notice the 
UTF16 BOM gets written out before each number.

I'm running a 2014 iMac with Yosemite.

--
components: IO
files: append-test.py
messages: 232015
nosy: MarkIngramUK
priority: normal
severity: normal
status: open
title: BOM incorrectly inserted before writing, after seeking in text file
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file37345/append-test.py

___
Python tracker 

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

[issue9584] Allow curly brace expansion

[Arfrever Frehtes Taifersar Arahesis]

Changes by Arfrever Frehtes Taifersar Arahesis :


--
nosy: +Arfrever
versions: +Python 3.5 -Python 3.4

___
Python tracker 

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

[issue22980] C extension naming doesn't take bitness into account

[Antoine Pitrou]

Antoine Pitrou added the comment:

The MULTIARCH variable can help at least under Linux:

>>> import sysconfig
>>> sysconfig.get_platform()
'linux-x86_64'
>>> sysconfig.get_config_var('MULTIARCH')
'i386-linux-gnu'

--

___
Python tracker 

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

[issue18053] Add checks for Misc/NEWS in make patchcheck

[Brett Cannon]

Brett Cannon added the comment:

If it's bugging you, Terry, feel free to delete that part of the check as it's 
of more use to core devs and we won't forget.

--
assignee:  -> terry.reedy

___
Python tracker 

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

[issue22981] Use CFLAGS when extracting multiarch

[Antoine Pitrou]

New submission from Antoine Pitrou:

This patch fixes MULTIARCH computation when using CFLAGS=-m32:

diff --git a/configure b/configure
--- a/configure
+++ b/configure
@@ -5402,7 +5402,7 @@ hp*|HP*)
 esac;;
 esac
 
-MULTIARCH=$($CC --print-multiarch 2>/dev/null)
+MULTIARCH=$($CC $CFLAGS --print-multiarch 2>/dev/null)
 
 
 
diff --git a/configure.ac b/configure.ac
--- a/configure.ac
+++ b/configure.ac
@@ -788,7 +788,7 @@ hp*|HP*)
 esac;;
 esac
 
-MULTIARCH=$($CC --print-multiarch 2>/dev/null)
+MULTIARCH=$($CC $CFLAGS --print-multiarch 2>/dev/null)
 AC_SUBST(MULTIARCH)

--
messages: 232013
nosy: barry, doko, pitrou
priority: normal
severity: normal
status: open
title: Use CFLAGS when extracting multiarch
type: enhancement
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

[issue22979] Use of None in min and max

[R. David Murray]

R. David Murray added the comment:

Just select your initial value as something that works with the sequence you 
are iterating.  If necessary, you can define custom 'always maximum' and 
'always minimum' objects.  (You could try proposing builtin objects with that 
feature on the python-ideas mailing list, if you want to pursue this, but since 
this is a specialized need and usually you don't even need custom objects, I 
suspect you won't get much enthusiasm.  But I could be wrong, especially if you 
can some up with additional use cases.

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

[issue22978] Logical Negation of NotImplemented

[R. David Murray]

R. David Murray added the comment:

This would break Python's consistency.  'not' of a value returns its boolean 
inverse, and the boolean value of NotImplemented is True, just like the boolean 
value of any object that does not have methods that set its boolean value is 
True.  Having anything that is True return True when not is applied would be 
even more perverse than NANs are :)

The correct implementation of your __ne__ method is to not define it.  Python 
will then do the 'not __eq__(other)' call itself.

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

[issue22980] C extension naming doesn't take bitness into account

[Antoine Pitrou]

Antoine Pitrou added the comment:

As a side-note, it is interesting to note that Python currently wrongly 
identifies 32-bit builds under 64-bit Linux:

Python 3.5.0a0 (default:64a54f0c87d7, Nov  2 2014, 17:18:13) 
[GCC 4.9.1] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys, os, sysconfig
>>> sys.maxsize
2147483647
>>> os.uname()
posix.uname_result(sysname='Linux', nodename='fsol', 
release='3.16.0-25-generic', version='#33-Ubuntu SMP Tue Nov 4 12:06:54 UTC 
2014', machine='x86_64')
>>> sysconfig.get_platform()
'linux-x86_64'

AFAIU, sysconfig.get_platform() (or its sibling distutils.util.get_platform()) 
is used for the naming of binary distributions...

--

___
Python tracker 

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

[issue22979] Use of None in min and max

[Simeon Visser]

Simeon Visser added the comment:

So, to clarify, as the problem no longer occurs in Python 3 (as it requires the 
caller to provide only orderable objects) I'm not sure a meaningful change can 
be made here. It would require changing the behaviour of min/max in Python 
2.7.x in a way that could break existing code.

--

___
Python tracker 

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

[issue22976] multiprocessing Queue empty() is broken on Windows

[R. David Murray]

Changes by R. David Murray :


--
nosy: +sbt

___
Python tracker 

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

[issue22980] C extension naming doesn't take bitness into account

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +ned.deily

___
Python tracker 

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

[issue18290] json encoder does not support JSONP/JavaScript safe escaping

[Tom Christie]

Tom Christie added the comment:

> There is explicit note in the documentation about incompatibility with 
> JavaScript.

That may be, but we're still unnecessarily making for a poorer user experience. 
There's no good reason why we shouldn't just treat \u2028 and \u2029 as control 
characters - it's only going to making things better for developers using the 
json module. It is an unnecessary usability bug as it stands.

Just because JSON has a bug in its spec wrt those two characters, doesn't mean 
we can't help our users avoid ever having to know about that or work around it 
in user code.

--

___
Python tracker 

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

[issue22979] Use of None in min and max

[Simeon Visser]

Simeon Visser added the comment:

This doesn't happen in Python 3 as None can't be compared to other elements:

>>> min([1,2,3,None])
Traceback (most recent call last):
  File "", line 1, in 
TypeError: unorderable types: NoneType() < int()

I can also imagine people now using min with the intended behaviour of "give me 
the smallest element, or None if it happens to be present".

--
nosy: +simeon.visser

___
Python tracker 

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

[issue21161] list comprehensions don't see local variables in pdb in python3

[Florent Xicluna]

Changes by Florent Xicluna :


--
nosy: +flox

___
Python tracker 

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

[issue18290] json encoder does not support JSONP/JavaScript safe escaping

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

There is explicit note in the documentation about incompatibility with 
JavaScript.

--

___
Python tracker 

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

[issue22980] C extension naming doesn't take bitness into account

[Antoine Pitrou]

Antoine Pitrou added the comment:

Ideally, we would use distutils.util.get_platform(). However, there are two 
cases where it relies on other modules:
- the re module under CygWin
- the sysconfig and _osx_support under OS X

Of course, ideally we should be able to hardcode this into the compiled CPython 
executable...

--

___
Python tracker 

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

[issue22980] C extension naming doesn't take bitness into account

[Antoine Pitrou]

Antoine Pitrou added the comment:

PEP 3149 says """It is not currently clear that the facilities in this PEP are 
even useful for Windows""". Well, it seems I have found a use for it :-)

--

___
Python tracker 

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

[issue22980] C extension naming doesn't take bitness into account

[STINNER Victor]

STINNER Victor added the comment:

See also the PEP 3149.

--

___
Python tracker 

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

[issue22980] C extension naming doesn't take bitness into account

[STINNER Victor]

Changes by STINNER Victor :


--
nosy: +haypo

___
Python tracker 

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

[issue22980] C extension naming doesn't take bitness into account

[Antoine Pitrou]

New submission from Antoine Pitrou:

Currently, C extensions are named something like "_helperlib.cpython-34dm.so". 
This doesn't take into account the bitness of the interpreter (32- vs. 64-bit), 
which makes it awkward to use the same working copy with two different 
interpreters (you have to rebuild everything each time you switch bitnesses).

Worse, under Windows it seems ABI tags aren't even used, giving generic names 
such as "_helperlib.pyd". Why is that?

--
messages: 232000
nosy: barry, brett.cannon, eric.snow, ncoghlan, pitrou, steve.dower, 
tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: C extension naming doesn't take bitness into account
type: enhancement
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

[issue18290] json encoder does not support JSONP/JavaScript safe escaping

[Tom Christie]

Tom Christie added the comment:

I believe the status of this should be reassessed and that python should 
default to escaping '\u2028' and '\u2029'. *Strictly* speaking this isn't a bug 
and is per the JSON spec.

*However* this *is* a bug in the JSON spec - which *should* be a strict subset 
of JSON. Given that both escaped and unescaped are valid, ensuring that those 
two characters *are* always escaped would clearly be more user-friendly 
behavior on our part, and *would* lead to less bugs in, say web frameworks that 
use the JSON module and then pass the output to template (eg populating a 
javscript variable with some JSON output).

--
nosy: +tomchristie

___
Python tracker 

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

[issue22979] Use of None in min and max

[Maytag Metalark]

New submission from Maytag Metalark:

`None` should never be the result of the built-in `min` and `max` functions. 
When `None` is supplied as one of the values to check, it should never be 
chosen as the result.

This would make it much easier to find a minimum and/or maximum while iterating 
over values. For instance, the following is a common pattern:

mn = None
mx = None
for x in iterable:
if mn is None or x < mn:
mn = x
if mx is None or x > mx:
mx = x

Note that although the `min` and `max` functions could be applied directly to 
`iterable` in the above case, the above pattern is more efficient (only once 
through the loop) and covers the common case where additional operations are 
performed on each value of the iterable.

If the suggested enhancement was made, the above code could be written more 
simply as:

mn = None
mx = None
for x in iterable:
mn = min(mn, x)
mx = max(mx, x)

At present, this will actually work for `max`, as None evaluates as less than 
every number, but it will not work for `min` (for the same reason).

The suggested change would mean that None is simultaneously greater than and 
less than every other value, but that only matters if we assume a total 
ordering of all the values including None, which doesn't seem like it would be 
important.

--
messages: 231998
nosy: Brian.Mearns
priority: normal
severity: normal
status: open
title: Use of None in min and max
type: enhancement
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

[issue9647] os.confstr() does not handle value changing length between calls

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I agree with Victor that two calls to confstr() should be enough. An example in 
confstr manpage uses two calls and I think there is no many software (if any) 
in the world which does more.

--
keywords: +easy
nosy: +serhiy.storchaka
stage:  -> needs patch
versions: +Python 3.4, Python 3.5 -Python 3.1, Python 3.2

___
Python tracker 

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

[issue22978] Logical Negation of NotImplemented

[Maytag Metalark]

New submission from Maytag Metalark:

Performing a logical negation (`not`) on `NotImplemented` should return 
`NotImplemented`. Currently, it returns `False`.

A common pattern for implementing __eq__ and __ne__ is to implement the 
comparison in __eq__, and simply delegate to it in __ne__ with a negation. 
However, if two values are incomparable, then __eq__ and __ne__ should both 
return NotImplemented. If you try to negate NotImplemented in __ne__, you will 
end up with a value of False, instead of NotImplemented, so you have to 
specifically test for this case.

For instance, here is how one would write the code now:

def __ne__(self, other):
eq = self.__eq__(other)
if eq is NotImplemented:
return NotImplemented
return not eq

Where as the following would be simpler, and could be used if this change was 
made:

def __ne__(self, other):
return not self.__eq__(other)

This is not simply sugar to reduce typing, it is safer because some coders may 
forget about NotImplemented and implement __ne__ as shown in the second example 
anyway, which is not actually correct with the current behavior.

--
messages: 231996
nosy: Brian.Mearns
priority: normal
severity: normal
status: open
title: Logical Negation of NotImplemented
type: enhancement
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

[issue7567] Messed up terminal after calling curses.initscr() twice.

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue13027] python 2.6.6 interpreter core dumps on modules command from help prompt

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I suggest to close this issue as caused by a bug in third party extension.

--
nosy: +serhiy.storchaka
resolution:  -> third party
status: open -> pending

___
Python tracker 

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

[issue22701] Write unescaped unicode characters (Japanese, Chinese, etc) in JSON module when "ensure_ascii=False"

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Looks either you have opened a file with the backslashreplace error handler or 
ran Python with PYTHONIOENCODING which sets the backslashreplace error handler.

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