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

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

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

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 t

[issue16569] Preventing errors of simultaneous access in zipfile

Serhiy Storchaka added the comment: Closed in favor of issue14099. -- resolution: -> rejected stage: patch review -> resolved status: open -> closed ___ Python tracker ___ _

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

Serhiy Storchaka added the comment: Thanks Stepan for the idea. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___ ___

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

Serhiy Storchaka added the comment: Arfrever have suggested on IRC to backport documentation part of the patch to 3.4. -- ___ Python tracker ___

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

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

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

Changes by Greg Turner : -- title: types._calculate_meta nit: isinstance != PyType_IsSubtype -> Lib/types.py nit: isinstance != PyType_IsSubtype ___ Python tracker ___ _

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

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 PE

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

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

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

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 n

[issue22986] Improved handling of __class__ assignment

Changes by Eric Snow : -- nosy: +eric.snow ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.

[issue22986] Improved handling of __class__ assignment

Changes by Nick Coghlan : -- nosy: +ncoghlan ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pytho

[issue22986] Improved handling of __class__ assignment

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

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

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

[issue14134] xmlrpc.client.ServerProxy needs timeout parameter

Changes by Florent Xicluna : -- nosy: +flox versions: +Python 3.5 -Python 3.3 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue22986] Improved handling of __class__ assignment

Changes by Ethan Furman : -- nosy: +ethan.furman ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.p

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

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

[issue22986] Improved handling of __class__ assignment

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

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

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 NE

[issue22985] Segfault on time.sleep

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 m

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

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 _

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

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 pa

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

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 overla

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

David Wilson added the comment: Sounds great :) -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail

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

Changes by Serhiy Storchaka : -- resolution: -> fixed stage: commit review -> resolved status: open -> closed ___ Python tracker ___

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

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

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

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

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

Changes by Serhiy Storchaka : -- nosy: +serhiy.storchaka ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https:

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

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

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

Serhiy Storchaka added the comment: Committed the first patch (showing closefd always) with additional test from second path. -- versions: -Python 3.4 ___ Python tracker ___ __

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

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

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

Changes by STINNER Victor : -- title: Unformatted “Windows Error 0x%X” exception message -> Unformatted “Windows Error 0x%X” exception message on Wine ___ Python tracker ___ ___

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

Changes by STINNER Victor : -- components: +Windows nosy: +steve.dower, tim.golden, zach.ware ___ Python tracker ___ ___ Python-bugs-l

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

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\

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

Serhiy Storchaka added the comment: How about just "Objects returned by :meth:`.open` can operate independently of the ZipFile."? -- ___ Python tracker ___ _

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

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 s

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

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

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

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

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

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 v

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

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

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

Antoine Pitrou added the comment: @Steve: IIRC, pyc files should be portable, so there's no need to differentiate between various bitnesses. -- ___ Python tracker ___ __

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

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

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

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 e

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

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 package

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

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

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

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 cours

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

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 alterna

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

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

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

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 eno

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

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

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

Benjamin Peterson added the comment: Okay for 2.7.10. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https:

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

Antoine Pitrou added the comment: > Note that there's a difference between the platform's architecture Yes, that's pointed out above. -- ___ Python tracker ___ _

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

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.

[issue22983] Cookie parsing should be more permissive

Demian Brecht added the comment: Sorry, bad example. Replace "[" in the previous example with any actually invalid character. -- ___ Python tracker ___ _

[issue22983] Cookie parsing should be more permissive

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 i

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

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 ___

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

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

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

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 ___

[issue22983] Cookie parsing should be more permissive

Antoine Pitrou added the comment: Well, remember that we recently made parsing stricter in response to a security issue... -- nosy: +orsenthil, pitrou ___ Python tracker ___ ___

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

Changes by Arfrever Frehtes Taifersar Arahesis : -- nosy: +Arfrever ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue22475] asyncio task get_stack documentation seems to contradict itself

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 tha

[issue19361] Specialize exceptions thrown by JSON parser

Changes by Arfrever Frehtes Taifersar Arahesis : -- nosy: +Arfrever ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue22475] asyncio task get_stack documentation seems to contradict itself

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 __

[issue22931] cookies with square brackets in value

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

[issue22914] Rewrite of Python 2/3 porting HOWTO

Changes by Tshepang Lekhonkhobe : -- nosy: +tshepang ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://ma

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

Changes by Arfrever Frehtes Taifersar Arahesis : -- nosy: +Arfrever ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue22983] Cookie parsing should be more permissive

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 s

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

Changes by Arfrever Frehtes Taifersar Arahesis : -- nosy: +Arfrever ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

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

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

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

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

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

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

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

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

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

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

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

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

[issue9584] Allow curly brace expansion

Changes by Arfrever Frehtes Taifersar Arahesis : -- nosy: +Arfrever versions: +Python 3.5 -Python 3.4 ___ Python tracker ___ ___ Python

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

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

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

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

[issue22981] Use CFLAGS when extracting multiarch

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

[issue22979] Use of None in min and max

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 mai

[issue22978] Logical Negation of NotImplemented

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 th

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

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 inf

[issue22979] Use of None in min and max

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 b

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

Changes by R. David Murray : -- nosy: +sbt ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.

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

Changes by Antoine Pitrou : -- nosy: +ned.deily ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.py

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

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

[issue22979] Use of None in min and max

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 intende

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

Changes by Florent Xicluna : -- nosy: +flox ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python

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

Serhiy Storchaka added the comment: There is explicit note in the documentation about incompatibility with JavaScript. -- ___ Python tracker ___

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

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

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

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 _

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

STINNER Victor added the comment: See also the PEP 3149. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: htt

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

Changes by STINNER Victor : -- nosy: +haypo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python

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

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 re

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

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

[issue22979] Use of None in min and max

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 ove

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

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 pa

[issue22978] Logical Negation of NotImplemented

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

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

Changes by Serhiy Storchaka : -- nosy: +serhiy.storchaka ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https:/

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

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 _

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

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 ___

  1   2   >