[issue25847] CPython not using Visual Studio code analysis!

Alexander Riccio added the comment: > That is, (as I undersatnd it) we've done a lot of work to not have compiler > warnings generated during compilation, and we don't want to backtrack on that. Well, as-is, simply building as x64 generates a bunch of warnings, so it's not *quite* clean. I

[issue25847] CPython not using Visual Studio code analysis!

Alexander Riccio added the comment: > In which direction do you find us to be mad? That's really quite a low warning level! For a large project, I can't imagine anything less than /W4! -- ___ Python tracker

[issue25863] ISO-2022 seeking forgets state

New submission from Martin Panter: >>> from io import * >>> text = TextIOWrapper(BytesIO(), "iso-2022-jp") >>> text.write(u"P") 1 >>> text.tell() 1 >>> text.write(u"anter 正") 7 >>> text.tell() 12 >>> text.write(u"孝") 1 >>> text.seek(12) 12 >>> text.read() # Should return 孝, not ASCII "9'" >>>

[issue25847] CPython not using Visual Studio code analysis!

Alexander Riccio added the comment: Actually, hmm... the very naive version *DOES NOT* work. Grr. -- ___ Python tracker ___

[issue20120] Percent-signs (%) in .pypirc should not be interpolated

Thomas Levine added the comment: The error message could just say. something to the effect of ".pypyrc works differently in Python 2 and Python 3. If you want a percent sign in Python 3, you have to escape it with another percent sign". Suppose someone is already using a configuration file

[issue25847] CPython not using Visual Studio code analysis!

Zachary Ware added the comment: In which direction do you find us to be mad? -- ___ Python tracker ___ ___

[issue20120] Percent-signs (%) in .pypirc should not be interpolated

Jason R. Coombs added the comment: It doesn't make sense to give guidance to use one percent sign on one Python and two on another because .pypirc applies to all Python versions. I'm sure it's not uncommon for one to use different versions of Python for various package releases. I'm planning

[issue25847] CPython not using Visual Studio code analysis!

Alexander Riccio added the comment: Hold on... CPython builds at /W3???!? What is this madness??!? -- Added file: http://bugs.python.org/file41312/CPythonW3.PNG ___ Python tracker

[issue25847] CPython not using Visual Studio code analysis!

Steve Dower added the comment: Doing the work to clean up the warnings really has to come second, ultimately. The buildbot script also should be updated to pass that option. -- ___ Python tracker

[issue25862] TextIOWrapper assertion failure after read() and SEEK_CUR

New submission from Martin Panter: Python 3.5.1+ (3.5:014e6f7d7c1a, Dec 14 2015, 11:20:58) [GCC 5.3.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> from io import * >>> text = TextIOWrapper(BytesIO(b"x"), "ascii") >>> text.read(1) 'x' >>> text.read() ''

[issue20120] Percent-signs (%) in .pypirc should not be interpolated

Jason R. Coombs added the comment: This same issue applies to setuptools (https://bitbucket.org/pypa/setuptools/issues/442/setuptools-1832-cannot-access-pypi-if-pypi). I've created a test that captures the failure, but I struggled to find a solution that doesn't break across Python versions.

[issue25860] os.fwalk() silently skips remaining directories when error occurs

Changes by Samson Lee : -- nosy: +hynek, neologix ___ Python tracker ___ ___

[issue25860] os.fwalk() silently skips remaining directories when error occurs

Changes by Samson Lee : -- nosy: +benhoyt, haypo ___ Python tracker ___ ___

[issue25860] os.fwalk() silently skips remaining directories when error occurs

New submission from Samson Lee: I noticed os.fwalk() produced different results as os.walk(). It turned out that os.fwalk() skips all remaining directories when OSError occurs (e.g. due to PermissionError). To reproduce the bug, first create a test directory structure: $ mkdir 1; touch 1/a

[issue25849] files, opened in unicode (text): write() returns symbols count, but seek() expect offset in bytes

Martin Panter added the comment: You might be right about the “reconstruction algorithm”. This text was added in revision 0bba533c0959; maybe Antoine can comment whether we should clarify or remove it. I think the text added for TextIOBase.seek() in revision 03e61104f7a2 (Issue 12922) is

[issue25864] collections.abc.Mapping should include a __reversed__ that raises TypeError

New submission from Andrew Barnert: Example: class MyDict(collections.abc.Mapping): def __init__(self, d): self.d = d def __len__(self): return len(self.d) def __getitem__(self, key): return self.d[key] def __iter__(self): return iter(self.d) d = {1:2,

[issue25864] collections.abc.Mapping should include a __reversed__ that raises TypeError

Swati Jaiswal added the comment: > If you do `reversed(d)`, you get a nice `TypeError: argument to reversed() > must be a sequence`. But if you do `reversed(m)`, you get a reversed` > iterator. And when you iterate it, presumably expecting to get 0 and 1 in > some arbitrary order, you instead

[issue25190] Define StringIO seek offset as code point offset

Martin Panter added the comment: There were a few tricky bits doing this with _pyio.StringIO, but I think I was successful. Here is a patch with both implementations and some tests. If people think this should go ahead, I can add documentation. In the process I may have discovered a bug with

[issue25864] collections.abc.Mapping should include a __reversed__ that raises TypeError

Andrew Barnert added the comment: > It seems no more interesting or problematic than sequence argument unpacking > working with dictionaries, "a, b = {'one': 1, 'two': 2}". Dictionaries (including dicts, dict subclasses, and custom Mappings) are iterables. People use that fact every time they

[issue25843] lambdas on the same line may incorrectly share code objects

Mark Lawrence added the comment: http://code.activestate.com/recipes/578353-code-to-source-and-back/ compares code objects as part of round trip testing. -- nosy: +BreamoreBoy ___ Python tracker

[issue25843] lambdas on the same line may incorrectly share code objects

Emanuel Barry added the comment: I see. Is there any to special-case those so that only closures use that? Maybe by checking on the function object itself - the function itself would be quite similar, as well. @Mark - I think you've misunderstood me (others did too, so I'm going to assume I

[issue25857] csv: unexpected result

R. David Murray added the comment: Well, since there's no real standard for csv, it might have been. Since it is iherently ambiguous according to "normal" csv rules, though, I'd say that if that is the case the originating spreadsheet is the one with the bug. If you can prove there is a

[issue25843] lambdas on the same line may incorrectly share code objects

Raymond Hettinger added the comment: [Emanuel Barry] > In which circumstances does comparing two code objects > (at function creation time, what's more) make any sense? It makes closures efficient: >>> def f(x): def g(y): return x + y return g

[issue25861] Can't use Pickle. AttributeError: 'module' object has no attribute '_new_Index'

Changes by SilentGhost : -- nosy: +alexandre.vassalotti, pitrou type: crash -> behavior ___ Python tracker ___

[issue25861] Can't use Pickle. AttributeError: 'module' object has no attribute '_new_Index'

Serhiy Storchaka added the comment: _new_Index is a function used in pandas to unpickle its Index objects. Added 29 Jul 2014 (https://github.com/pydata/pandas/commit/8d3cb3f36e2f7b415531e3b910f490c01657ecca). May be your current pandas is older than that used for pickling. In any case this

[issue25843] lambdas on the same line may incorrectly share code objects

Serhiy Storchaka added the comment: > It makes closures efficient: No, code objects are not compared here. The code object is constant, and f() returns different closure objects using the same code object. AFAIK the comparison of different code objects is used exclusively in testing.

[issue1753718] base64 "legacy" functions violate RFC 3548

R. David Murray added the comment: How about we just make the docs more correct and say that input is read until readline() returns an empty bytes object? That should make it clear that a line-oriented file is expected. -- ___ Python tracker

[issue20782] base64 module docs do not use the terms 'bytes' and 'string' consistently.

R. David Murray added the comment: Darn. I *thought* I remembered there being an existing patch for this when I was working on that other issue, but I couldn't find it. -- ___ Python tracker

[issue25847] CPython not using Visual Studio code analysis!

R. David Murray added the comment: OK, let's move this to patch needed, then, and see if anyone is ambitious enough to do the work needed to make it useful to us :) -- stage: -> needs patch type: -> enhancement versions: +Python 3.6 ___ Python

[issue25857] csv: unexpected result

Ioan Fintescu added the comment: There seems to be a CSV specification, namely IETF RFC 4180, and, as far as I can tell, it indicates you are correct, and I am wrong. Especially points 5., 6., and 7 on page 3. Here is a quote from 5 (RFC 4180, page 2

[issue25864] collections.abc.Mapping should include a __reversed__ that raises TypeError

Swati Jaiswal added the comment: Can it be reproduced in default branch? I tried but got: AttributeError: module 'collections' has no attribute 'abc' -- nosy: +curioswati ___ Python tracker

[issue25864] collections.abc.Mapping should include a __reversed__ that raises TypeError

Raymond Hettinger added the comment: I've seen no evidence that this a problem in practice. It seems no more interesting or problematic than sequence argument unpacking working with dictionaries, "a, b = {'one': 1, 'two': 2}". -- nosy: +rhettinger

[issue25849] files, opened in unicode (text): write() returns symbols count, but seek() expect offset in bytes

Martin Panter added the comment: I’m starting to understand that there might be a “reconstruction algorithm” needed. When reading, TextIOWrapper buffers decoded characters. If you call tell() and there is unread but decoded data, it is not enough to return the incremental decoder state. You

[issue25865] 7.2 Assignment statements documentation is vague and slightly misleading

New submission from Andrew Barnert: >From >https://docs.python.org/3/reference/simple_stmts.html#assignment-statements > If the target list contains one target prefixed with an asterisk, called a > “starred” target: The object must be a sequence with at least as many items > as there are

[issue25864] collections.abc.Mapping should include a __reversed__ that raises TypeError

Emanuel Barry added the comment: You need to do 'import collections.abc' as abc is a submodule of collections, and is not imported from a bare 'import collections'. -- nosy: +ebarry ___ Python tracker

[issue25864] collections.abc.Mapping should include a __reversed__ that raises TypeError

Changes by Raymond Hettinger : -- priority: normal -> low versions: +Python 3.6 ___ Python tracker ___

[issue25865] 7.2 Assignment statements documentation is vague and slightly misleading

Andrew Barnert added the comment: As a side note, why isn't () allowed as an empty target list, like []? Then the rules for target lists vs. single targets would be exactly parallel to the rules for tuple and list displays. And the error message `can't assign to ()` seems a bit weird--you

[issue25864] collections.abc.Mapping should include a __reversed__ that raises TypeError

Andrew Barnert added the comment: > What are we exactly expecting here? Well, naively, I was expecting a TypeError, just as you get for dict, or a subclass of dict, or a custom extension type that implements the C-API mapping protocol. Once you understand how reversed works, you can

[issue25861] Can't use Pickle. AttributeError: 'module' object has no attribute '_new_Index'

New submission from Geoffrey Mégardon: Hello, I am trying to run a piece of code that I programmed some time ago. Back then, it was working fine and it was plotting some data. But today, while I am trying to improve the plots, I ran the code and did not work! Here the message:

[issue22137] Test imaplib API on all methods specified in RFC 3501

Maciej Szulik added the comment: Per the discussion we've had with David on IRC here's what happening. The last patch I've submitted is meant to clean up the tests by: 1. having single _setup method 2. the _setup method should addClenup to clean the environment 3. have stubs with implemented

[issue25857] csv: unexpected result

R. David Murray added the comment: There's no place to generate an error message, the csv module parsed the line according to the rules. I'm glad that there's an RFC now. There wasn't when the module was written (which was well before my time on this project...) --

[issue25857] csv: unexpected result

R. David Murray added the comment: Oh, maybe there is. We could add an RFC-strict dialect that would raise an error, if I'm understanding your quotes from it correctly. That would be a new feature, though. -- ___ Python tracker

[issue25843] lambdas on the same line may incorrectly share code objects

R. David Murray added the comment: Ah, haypo explained the code to me, and now I understand your comment Serhiy. So, the replacement happens because of (a) an optimizer general rule and (b) the fact that code object *can* be compared. So it sounds like Armin's suggestion of making an

[issue25843] lambdas on the same line may incorrectly share code objects

Serhiy Storchaka added the comment: Indeed. My answer actually is an answer to implicit question: could we make different code objects be always non-equal? Answer: no, because we use the comparison of different code objects to test compiler and marshaller. May be we can get rid of code

[issue25843] lambdas on the same line may incorrectly share code objects

STINNER Victor added the comment: compiler_add_o() uses an heuristic to compare and merge duplicated constants. It has special cases for float and complex numbers, but it's not designed to handle more types. Funny, I had the same isue last week why I added support for tuple and frozenset

[issue25843] lambdas on the same line may incorrectly share code objects

STINNER Victor added the comment: code_richcompare.patch: fix code_richcompare() to not consider that constants (1,) and (1.0,) are equal. The patch lacks an unit test. We may use the new _PyCode_ConstantKey() function to compare other code attributes? -- keywords: +patch Added

[issue1753718] base64 "legacy" functions violate RFC 3548

R. David Murray added the comment: Updated patch. -- Added file: http://bugs.python.org/file41306/issue-01753718.patch ___ Python tracker ___

[issue25843] lambdas on the same line may incorrectly share code objects

STINNER Victor added the comment: > Would option (1) work if wrap 1 and 1.0 in a tuple? In a list? In a custom > collection? Right now, the Python compiler is quite limited. It only produces constants for integers and strings, not complex types. The peephole optimizers is responsible to

[issue25857] csv: unexpected result

Ioan Fintescu added the comment: If you consider that, you should take a look at the RFC; it also contains a BNF like grammar plus some pointers to another RFC (2234). It may require more effort that it is worth, absent some demand for it. ...muss On Mon, Dec 14, 2015 at 9:34 AM, R. David

[issue25857] csv: unexpected result

R. David Murray added the comment: Yeah, we'll leave it alone until someone actually submits an enhancment request...and the only way it'll get done is if they do it, I suspect :) -- ___ Python tracker

[issue25843] lambdas on the same line may incorrectly share code objects

STINNER Victor added the comment: > The frozenset are different are expected. Oh wait, in this example, it works, but not because of the expected reason. frozenset({1}) is equal to frozenset({1.0}) and code_richcompare() doesn't create a special key to make them different. The example only

[issue25843] lambdas on the same line may incorrectly share code objects

STINNER Victor added the comment: code_eq.py: code to test that frozenset() are inequal. The code hacks constants, don't run the code with new constants or it will crash! -- Added file: http://bugs.python.org/file41309/code_eq.py ___ Python tracker

[issue25861] Can't use Pickle. AttributeError: 'module' object has no attribute '_new_Index'

Changes by R. David Murray : -- resolution: not a bug -> third party ___ Python tracker ___

[issue25843] lambdas on the same line may incorrectly share code objects

R. David Murray added the comment: Serhiy: that can't be entirely true, since we have here a bug where two lambdas on the same line are getting the same code object incorrectly, and that is not a testing context. -- ___ Python tracker

[issue25591] refactor imaplib tests

Maciej Szulik added the comment: I'm reopening this issue per discussion with David we've had on IRC. The scope of this issue to refactor current tests to make them more readable and clean. The most important work is: 1. having single _setup method 2. the _setup method should addClenup to

[issue25843] lambdas on the same line may incorrectly share code objects

Serhiy Storchaka added the comment: Would option (1) work if wrap 1 and 1.0 in a tuple? In a list? In a custom collection? -- ___ Python tracker ___

[issue25843] lambdas on the same line may incorrectly share code objects

Changes by STINNER Victor : -- nosy: +haypo ___ Python tracker ___ ___

[issue21258] Add __iter__ support for mock_open

Changes by José Luis Lafuente : -- nosy: +José.Luis.Lafuente ___ Python tracker ___

[issue25843] lambdas on the same line may incorrectly share code objects

STINNER Victor added the comment: code_richcompare-2.patch: Updated patch to handle also frozenset, the other constant type generated by the peephole optimizer. -- Added file: http://bugs.python.org/file41308/code_richcompare-2.patch ___ Python

[issue1753718] base64 "legacy" functions violate RFC 3548

Martin Panter added the comment: The change to readline() works well. Any thoughts regarding my other comments? In particular, altchars and ignorechars cannot be arbitrary bytes-like objects. -- ___ Python tracker

[issue25567] shlex.quote doesn't work on bytestrings

Martin Panter added the comment: I think the documentation needs a “Changed in version 3.6” notice -- nosy: +martin.panter ___ Python tracker ___

[issue12484] The Py_InitModule functions no longer exist, but remain in the docs

Terry J. Reedy added the comment: Sorry, another week for 3.4 -- versions: +Python 3.4 ___ Python tracker ___

[issue25853] Compile error with pytime.h - struct timespec declared inside parameter list

Martin Panter added the comment: What platform, C library, etc do you have? According to Posix, struct timespec is normally defined in , but can also be gotten via various other include files, many of which are included before "pytime.h". In particular, includes "pyport.h", which has

[issue12484] The Py_InitModule functions no longer exist, but remain in the docs

Anish Shah added the comment: will try to create a patch for this issue in a day. Thanks! -- nosy: +Anish.Shah ___ Python tracker ___

[issue12484] The Py_InitModule functions no longer exist, but remain in the docs

Changes by Anish Shah : -- keywords: +patch Added file: http://bugs.python.org/file41310/remove_Py_InitModule_from_docs.patch ___ Python tracker

[issue25843] lambdas on the same line may incorrectly share code objects

Serhiy Storchaka added the comment: If go this way, I would add explicit support of all types supported in marshal, and include id(obj) into the key of all other types. -- ___ Python tracker

[issue12484] The Py_InitModule functions no longer exist, but remain in the docs

Changes by Zachary Ware : -- versions: +Python 3.4, Python 3.5, Python 3.6 -Python 3.1, Python 3.2, Python 3.3 ___ Python tracker

[issue12484] The Py_InitModule functions no longer exist, but remain in the docs

Terry J. Reedy added the comment: 3.4 is also on security fix only status. -- nosy: +terry.reedy versions: -Python 3.4 ___ Python tracker ___

[issue12484] The Py_InitModule functions no longer exist, but remain in the docs

Changes by Terry J. Reedy : -- stage: -> needs patch type: -> behavior ___ Python tracker ___

[issue25567] shlex.quote doesn't work on bytestrings

Changes by Carol Willing : -- nosy: +willingc stage: needs patch -> patch review ___ Python tracker ___

[issue12174] Multiprocessing logging levels unclear

Camilla Montonen added the comment: This issue raises the fact that the 2.X documentation lists two logging levels (SUBDEBUG and SUBWARNING) without explaining how these two fit into the logging hierarchy of the logging levels provided by the standard library logging module (ie, is SUBDEBUG

[issue25849] files, opened in unicode (text): write() returns symbols count, but seek() expect offset in bytes

Марк Коренберг added the comment: First, it seems that there are no real "reconstruction algorithm" at all. Seek is allowed to point to any byte position, even to place "inside" characters for multibyte encodings, such as UTF-8. Second, about performance: I talk about implementation

[issue25849] files, opened in unicode (text): write() returns symbols count, but seek() expect offset in bytes

Марк Коренберг added the comment: s/peek/tell/ -- status: closed -> open ___ Python tracker ___ ___

[issue25849] files, opened in unicode (text): write() returns symbols count, but seek() expect offset in bytes

Марк Коренберг added the comment: Also, can you provide the case, where such random seeks can be used on text files? It would be programmer error to seek to places other I mention. Does not it ? -- ___ Python tracker

[issue25849] files, opened in unicode (text): write() returns symbols count, but seek() expect offset in bytes

R. David Murray added the comment: I think you haven't quite gotten what "opaque token" means in this context. The way you use tell/seek with text files is: you have read to some certain point in the file. You call 'tell' and get back an opqaue token. Later you can call seek with that

[issue1753718] base64 "legacy" functions violate RFC 3548

R. David Murray added the comment: I missed the other comments somehow. Will take a look soon. -- ___ Python tracker ___

[issue24505] shutil.which wrong result on Windows

Toby Tobkin added the comment: Hopefully this isn't too much of an amateur question, but I ran into a semantics issue: should which be imitating the semantics of the Windows shell or of CreateProcess[3]? The current implementation of shutil.which implies Windows shell, but Python uses

[issue25859] EOFError in test_nntplib.NetworkedNNTPTests.test_starttls()

New submission from Martin Panter: The AMD64 Debian root buildbot and the x86 Gentoo Installed with X buildbot have been persistently failing test_nntplib for a while, and I can also reproduce it locally when “test -unetwork” is enabled. Six test cases fail. There is a pause before

[issue25766] __bytes__ doesn't work for str subclasses

Serhiy Storchaka added the comment: Other conversion special methods work in str subclass. >>> class I(str): ... def __int__(self): ... return 42 ... >>> int(I('35')) 42 >>> int(I('35'), 8) 29 -- nosy: +mark.dickinson, skrah ___ Python

[issue25847] CPython not using Visual Studio code analysis!

Alexander Riccio added the comment: > OK, let's move this to patch needed, then, and see if anyone is ambitious > enough to do the work needed to make it useful to us :) I can try and hack it in, just as proof of concept. I think I should just be able to add something like:

[issue25847] CPython not using Visual Studio code analysis!

R. David Murray added the comment: It seems to me that adding the CLI flag is the least of the work. You then have to make it compile cleanly :) (That's why I said 'ambitious enough'). That is, (as I undersatnd it) we've done a lot of work to not have compiler warnings generated during

[issue25847] CPython not using Visual Studio code analysis!

Alexander Riccio added the comment: Yup, the very naive version works. -- keywords: +patch Added file: http://bugs.python.org/file41311/EnableCodeAnalysis.patch ___ Python tracker

[issue25847] CPython not using Visual Studio code analysis!

Mark Lawrence added the comment: There are all ready numerous compiler warnings in the Windows builds, see #9566, #18295 and #18407. -- components: +Windows nosy: +BreamoreBoy ___ Python tracker