[issue15456] Correct __sizeof__ support for code objects

Changes by Jesús Cea Avión : -- nosy: +jcea ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue15502] Meta path finders and path entry finders are different, but share an ABC

Nick Coghlan added the comment: On the "self-contained" packages point, I was going to suggest that name, but the ability to set __path__ from __init__.py messes with it. "Regular packages" isn't great, but I'm willing to tolerate it (mainly because it was the terminology used in the approved

[issue15537] MULTILINE confuses re.split

Ezio Melotti added the comment: See also #11957. -- resolution: -> invalid stage: -> committed/rejected status: open -> closed type: -> behavior ___ Python tracker ___ ___

[issue15537] MULTILINE confuses re.split

Dave Abrahams added the comment: Dang! Thanks, and sorry for wasting everyone's time on this. -- ___ Python tracker ___ ___ Python-bu

[issue15544] math.isnan fails with some Decimal NaNs

New submission from Steven D'Aprano: math.nan fails on some Decimal NANs. For example, while this works: >>> import math >>> from decimal import Decimal >>> math.isnan(Decimal('nan')) True These both fail with ValueError: math.isnan(Decimal('snan')) math.isnan(Decimal('nan123'))

[issue15544] math.isnan fails with some Decimal NaNs

Changes by Steven D'Aprano : -- components: +Library (Lib) type: -> behavior ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue15459] ctypes Structures with subclassed types in the _fields_ list

Meador Inge added the comment: OK, I finally had some time to look at this. The attached patch does fix the issue. However, it has a nasty side effect in that the encoded bitfield size stays with the field member object: >>> class SubByte(c_ubyte): pass ... >>> class A(Structure):

[issue15544] math.isnan fails with some Decimal NaNs

Changes by Ezio Melotti : -- nosy: +mark.dickinson, skrah ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http:

[issue15502] Meta path finders and path entry finders are different, but share an ABC

Eric Snow added the comment: The more I think about it the more I think there needs to be a harder separation between the import system proper and the path-based subsystem. I hadn't really thought of it this way until the discussion of the last few days, but it has really clicked in my mind.

[issue15311] Dev Guide update procedure documentation in dev guide outdated

Roundup Robot added the comment: New changeset 864cd63db2bb by Ned Deily in branch 'default': Closes #15311 - update devguide publication info. http://hg.python.org/devguide/rev/864cd63db2bb -- resolution: -> fixed stage: -> committed/rejected status: open -> closed __

[issue13119] Newline for print() is \n on Windows, and not \r\n as expected

Atsuo Ishimoto added the comment: On Fri, Aug 3, 2012 at 5:16 AM, STINNER Victor wrote: >> I wonder why "print(1, file=sys.stderr)" returns '1' instead of '1\n'. > > I suppose that you mean "returns '1\n' instead of '1'". No, sorry for my lame wording. In the test I submitted, printing to st

[issue15502] Meta path finders and path entry finders are different, but share an ABC

Nick Coghlan added the comment: See my comment above about explicitly defining the "path import subsystem" and renaming the "path importer" to be the "path import finder". I think the subsystem is well worth calling out explicitly, as when most people think of Python's import system, they're f

[issue14330] don't use host python, use host search paths for host compiler

Georg Brandl added the comment: Matthias, any comments? -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http

[issue15502] Meta path finders and path entry finders are different, but share an ABC

Eric Snow added the comment: This patch implements most of Brett's recommendation. I've held off on actually deprecating Finder just yet. However, it would probably entail a message in the docs like this: The API signatures for meta path finders and path entry finders were separated by PEP 4

[issue15540] Python 3.3 and numpy

Martin v. Löwis added the comment: > This is a mis-understanding of what NumPy does and why.There is > a need to byte-swap only when the data is stored on disk in the > reverse order from the native machine So is there ever a need to byte-swap Unicode strings? I can see how *numeric* dat

<    1   2