[issue31286] import in finally results in SystemError

Serhiy Storchaka added the comment: Confirmed. The bug is 3.7 only. -- nosy: +brett.cannon, eric.snow, ncoghlan, serhiy.storchaka ___ Python tracker ___

[issue31284] IDLE: Fix WindowList invalid command name error when running tests

Terry J. Reedy added the comment: As you gave the code, the two windows just sit there with mainloop running. Replace it with root.update() #w.close() root.destroy() and run from IDLE editor and I see the ".!menu.windows" message. Uncomment the close and it goes away. Root.destroy

[issue31286] import in finally results in SystemError

New submission from Thomas Caswell: Code to reproduce: def import_in_finally_fail(): try: print('yo') finally: import asyncio.queues as aq Results in: In [68]: import_in_finally_fail() yo ---

[issue28638] Optimize namedtuple creation

Changes by Ethan Smith : -- nosy: +Ethan Smith ___ Python tracker ___ ___ Python-bugs-list

[issue1447222] tkinter Dialog fails when more than four buttons are used

Cheryl Sabella added the comment: I tried the example code under 3.7 and it produced the correct the output. I think this issue can be closed. -- nosy: +csabella ___ Python tracker

[issue31284] IDLE: Fix WindowList invalid command name error when running tests

Cheryl Sabella added the comment: I saw it on my PR for the tests in outwin (issue30617) and I also found a comment from someone else in test_paragraph.py about it. I can reproduce it with this code: from idlelib import outwin from tkinter import Tk, Text root = Tk() w =

[issue30781] IDLE: configdialog -- switch to ttk widgets.

Changes by Cheryl Sabella : -- pull_requests: +3254 ___ Python tracker ___ ___

[issue31284] IDLE: Fix WindowList invalid command name error when running tests

Terry J. Reedy added the comment: I don't remember ever seeing that message. Do you have code that reliably reproduces the problem? def postwindowsmenu(self): # Only called when Windows menu exists menu = self.menudict['windows'] end = menu.index("end") ...

[issue20580] IDLE should support platform-specific default config defaults

Terry J. Reedy added the comment: A. In 3.6+, the [Keys] section of config-main.def reads [Keys] default= 1 name= name2= # name2 set in user config-main.cfg for keys added after 2016 July 1 The name is no longer 'IDLE Classic Windows'. Instead, if default is left true, the actual default is

[issue20580] IDLE should support platform-specific default config defaults

Changes by Terry J. Reedy : -- nosy: +serhiy.storchaka -westley.martinez ___ Python tracker ___

[issue30780] IDLE: configdialog - add tests for ConfigDialog GUI.

Terry J. Reedy added the comment: This issue is almost done. There are just a few things missed by the closed dependencies. -- ___ Python tracker ___

[issue30781] IDLE: configdialog -- switch to ttk widgets.

Terry J. Reedy added the comment: Main effects on Windows: * Label in LabelFrame is blue. * Widget frames turn blue when target by mouse. (This is especially nice for checkbuttons, where the visible 'frame' is the circle, while the mouse just needs to be inside the invisible actual frame that

[issue30781] IDLE: configdialog -- switch to ttk widgets.

Terry J. Reedy added the comment: New changeset 7b556025ff7d663233e7fcb84785eb071f5e2ba7 by Terry Jan Reedy in branch '3.6': [3.6] bpo-30781: IDLE - use ttk widgets in configdialog (GH-2654) (#3214) https://github.com/python/cpython/commit/7b556025ff7d663233e7fcb84785eb071f5e2ba7 --

[issue20580] IDLE should support platform-specific default config defaults

Changes by Charles Wohlganger : -- pull_requests: +3253 ___ Python tracker ___

[issue31265] Remove doubly-linked list from C OrderedDict

Raymond Hettinger added the comment: I'll bring this up at the language sprints. Last year, there was an explicit decision to not go down this path. Here are a few thoughts for now: It is a big deal to change the API. We try hard not to do that (breaking code for no reason and making it

[issue31283] Inconsistent behaviours with explicit and implicit inheritance from object

R. David Murray added the comment: OK, agreed. The general principle is: if you reference the name, it is looked up in the the builtins namespace at runtime (effectively an indirect reference). If the syntax doesn't explicitly mention the name, then it is going to be (the equivalent of) a

[issue31285] a SystemError and an assertion failure in warnings.warn_explicit()

Oren Milman added the comment: on a second thought, BadSource could be a subclass of str, so maybe we should just check whether module_globals['__loader__'].get_source(module_globals['__name__']).splitlines()[lineno-1] is a str, and whether

[issue31283] Inconsistent behaviours with explicit and implicit inheritance from object

Raymond Hettinger added the comment: I agree with the other commenters and recommend this be closed. There doesn't seem to be a a useful issue here. It seems more like a pedantic twisting of words that ignores how Python works (i.e. that you can specify a specific class to inherit from and

[issue30761] pdb: Add step / next count arguments

Changes by Barry A. Warsaw : -- nosy: +barry ___ Python tracker ___ ___ Python-bugs-list

[issue26656] Documentation for re.compile is a bit outdated

Emily Morehouse added the comment: PR 3211 - LGTM, but is not CLA signed. Elena, a couple of notes on your patch. Using :ref:`regular expression object ` to link to the section of the documentation is preferred, as it does not rely on a consistent URL. Also, be mindful of line lengths, feel

[issue31283] Inconsistent behaviours with explicit and implicit inheritance from object

Vedran Čačić added the comment: > On the other hand, are there any examples *other* than class and except where > this distinction matters? Of course. For example, "for" semantics mentions StopIteration. Of course it doesn't mean "whatever builtins.StopIteration currently refers to". [And in

[issue28261] wrong error messages when using PyArg_ParseTuple to parse normal tuples

Serhiy Storchaka added the comment: Thank you for your contribution Oren! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue26656] Documentation for re.compile is a bit outdated

Elena Oat added the comment: Added the link to the regular expression objects. -- keywords: +patch nosy: +Elena.Oat Added file: http://bugs.python.org/file47103/issue26656.diff ___ Python tracker

[issue31283] Inconsistent behaviours with explicit and implicit inheritance from object

Vedran Čačić added the comment: I don't know whether the fix is small, since there is no fix that I see yet. I'd just want to draw your attention to the fact that Python is extremely expressive language: almost nothing is "equivalent" to anything else, if you look hard enough. Surely, in the

[issue28261] wrong error messages when using PyArg_ParseTuple to parse normal tuples

Serhiy Storchaka added the comment: New changeset bc80fd1bd2e8b6817accbc101e7fe5e50ba8f768 by Serhiy Storchaka (Oren Milman) in branch '2.7': [2.7] bpo-28261: Prevent raising SystemError where PyArg_ParseTuple is used to parse non-args. (#3213)

[issue31285] a SystemError and an assertion failure in warnings.warn_explicit()

New submission from Oren Milman: 1. the following causes an assertion failure in Python/_warnings.c in show_warning(): import warnings class BadLoader: def get_source(self, fullname): class BadSource: def splitlines(self): return [42] return

[issue31283] Inconsistent behaviours with explicit and implicit inheritance from object

shadowadler added the comment: The two phrases you present are significantly different- one draws an equivalence. The other does not. That in essence is what this is all about. The difference between an indirect and direct reference in the class inheritance syntax is neither implied nor

[issue30781] IDLE: configdialog -- switch to ttk widgets.

Changes by Terry J. Reedy : -- pull_requests: +3252 ___ Python tracker ___ ___

[issue30781] IDLE: configdialog -- switch to ttk widgets.

Terry J. Reedy added the comment: New changeset 7028e5986fceeeb73dffb5d5bf8f03d88f73b63d by Terry Jan Reedy (Cheryl Sabella) in branch 'master': bpo-30781: IDLE - use ttk widgets in configdialog (#2654) https://github.com/python/cpython/commit/7028e5986fceeeb73dffb5d5bf8f03d88f73b63d

[issue31280] Namespace packages in directories added to path aren't importable if packages from the same namespace are in site-packages

Jim Fulton added the comment: See: https://github.com/pypa/pip/issues/4695 -- ___ Python tracker ___ ___

[issue28261] wrong error messages when using PyArg_ParseTuple to parse normal tuples

Changes by Oren Milman : -- pull_requests: +3251 ___ Python tracker ___ ___

[issue31283] Inconsistent behaviours with explicit and implicit inheritance from object

Vedran Čačić added the comment: Sorry, I fail to see the big difference. Let's take print as an example: All non-keyword arguments are converted to strings like str() does and written to the stream, separated by sep and followed by end. Both sep and end must be strings; they can also be

[issue31271] an assertion failure in io.TextIOWrapper.write

Serhiy Storchaka added the comment: New changeset 9bcbc6cba385a83cac8f1ff430cad7617184d2bc by Serhiy Storchaka (Oren Milman) in branch '3.6': [3.6] bpo-31271: Fix an assertion failure in io.TextIOWrapper.write. (GH-3201) (#3209)

[issue31072] add filter to zipapp

Paul Moore added the comment: New changeset 0780bf7578dc4c9c3852dc5e869aba515a2c65b1 by Paul Moore in branch 'master': bpo-31072: Rename the new filter argument for zipapp.create_archive. (#3049) https://github.com/python/cpython/commit/0780bf7578dc4c9c3852dc5e869aba515a2c65b1 --

[issue31284] IDLE: Fix WindowList invalid command name error when running tests

Changes by Cheryl Sabella : -- pull_requests: +3250 ___ Python tracker ___ ___

[issue31284] IDLE: Fix WindowList invalid command name error when running tests

New submission from Cheryl Sabella: When running tests that use an EditorWindow, the following warning message occurs: warning: callback failed in WindowList : invalid command name ".!menu.windows" This warning comes from `call_callbacks` in WindowsList in windows.py when the callback is

[issue31271] an assertion failure in io.TextIOWrapper.write

Serhiy Storchaka added the comment: > do you still think we should backport to 2.7? This is not trivial question. On one side, using PyString_GET_SIZE() with non-bytes object definitely is a bug. It is better to catch it earlier rather than hope on failing in the following code. On other

[issue31283] Inconsistent behaviours with explicit and implicit inheritance from object

shadowadler added the comment: You have put that much more precisely than I could have. I'm not aware that it is an issie elsewhere, but given that I only ran into this today I may not the person best qualified to answer that question. -- ___

[issue31283] Inconsistent behaviours with explicit and implicit inheritance from object

R. David Murray added the comment: I see I didn't specifically address your counter argument ("that would obviously be absurd"). Having thought it it some more, your are right, there *is* a difference between the examples you think it would be absurd to disclaim and your example here. In

[issue31283] Inconsistent behaviours with explicit and implicit inheritance from object

shadowadler added the comment: I really don't see that as a logical extension of what I am saying at all. Sure, shadowing builtins changes what they do, but if you're saying the syntax is equivalent then te effect of the shadowing should be consistent. --

[issue31283] Inconsistent behaviours with explicit and implicit inheritance from object

R. David Murray added the comment: shadowadler, the documentation assumes *throughout* that you have not created any variable that shadows any standard Python entities. There is no other rational way to write the documentation. To change that policy would, as has been pointed out, require

[issue29741] BytesIO methods don't accept integer types, while StringIO counterparts do

Changes by Steve Dower : -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker ___

[issue31283] Inconsistent behaviours with explicit and implicit inheritance from object

shadowadler added the comment: Not at all- what you are talking about is obviously absurd. I am merely asserting that the statement in the docs you point to - that the two statements are equivalent - is untrue, the two statements are not equivalent in their behaviour. --

[issue31283] Inconsistent behaviours with explicit and implicit inheritance from object

Vedran Čačić added the comment: It's not hard to find a link. https://docs.python.org/3.7/reference/compound_stmts.html#class-definitions But trying to change that to incorporate what OP is asking is a wild goose chase. There are numerous instances when a documentation is referring to a

[issue31280] Namespace packages in directories added to path aren't importable if packages from the same namespace are in site-packages

Eric V. Smith added the comment: No problem. If you open a pypa issue, can you post a link here? Thanks. -- resolution: -> not a bug type: -> behavior ___ Python tracker

[issue31280] Namespace packages in directories added to path aren't importable if packages from the same namespace are in site-packages

Jim Fulton added the comment: Wow, OK. It didn't occur to me to look for .pth files. (Buildout doesn't use them.) I guess this is a pip bug or misfeature. I'll head over to pypa. Thanks! -- stage: -> resolved status: open -> closed ___ Python

[issue26656] Documentation for re.compile is a bit outdated

Changes by Roundup Robot : -- pull_requests: +3249 ___ Python tracker ___

[issue28261] wrong error messages when using PyArg_ParseTuple to parse normal tuples

Serhiy Storchaka added the comment: New changeset 8e67981fc8e1bf3cb9774b5fbf4a39b8d65ba4ff by Serhiy Storchaka (Oren Milman) in branch '3.6': [3.6] bpo-28261: Prevent raising SystemError where PyArg_ParseTuple is used to parse non-args. (#3210)

[issue31283] Inconsistent behaviours with explicit and implicit inheritance from object

Steven D'Aprano added the comment: > the documentation states that the two examples I gave should yield identical > results. Got a link to the specific documentation that says this? And a suggested improvement? -- assignee: -> docs@python components: +Documentation nosy:

[issue31283] Inconsistent behaviours with explicit and implicit inheritance from object

shadowadler added the comment: Still not disagreeing with you- I just don't think that this is what the documentation implies. -- ___ Python tracker ___

[issue31283] Inconsistent behaviours with explicit and implicit inheritance from object

Steven D'Aprano added the comment: I don't think this is a bug, I think it is standard behaviour which should be expected if you think about Python's execution model. If you inherit from object implicitly: class Spam: ... then the interpreter gets to pick the base class, and it uses the

[issue31283] Inconsistent behaviours with explicit and implicit inheritance from object

shadowadler added the comment: I accept what you are saying as consistent. Nevertheless, the documentation states that the two examples I gave should yield identical results. They do not, they perform different actions, albeit subtly. Ergo, this is unexpected behaviour from a documentation

[issue31072] add filter to zipapp

Paul Moore added the comment: OK. There's been no further comments, and I think the differences with PyZipFile's filterfunc are sufficient to warrant using a different name. I'm going to go with "filter". It's short, and says what it means. -- ___

[issue31283] Inconsistent behaviours with explicit and implicit inheritance from object

Vedran Čačić added the comment: Yes, they are obviously not equivalent if you execute object = int before that. :-D And (like I said) "received wisdom" is also that "except:" is equivalent to "except BaseException:", but of course it isn't equivalent if you execute BaseException =

[issue31283] Inconsistent behaviours with explicit and implicit inheritance from object

shadowadler added the comment: Out of curiosity, given that you can change every other point in the hierarchy by changing the binding of modules, what is your philosophical objection to being able to change the top of the hierarchy? -- ___ Python

[issue31283] Inconsistent behaviours with explicit and implicit inheritance from object

shadowadler added the comment: I don't necessarily disagree with what you are saying- however, the received wisdom (as per my response to the SO question) is that class SomeClass(object): pass and class SomeClass: pass Should do the same thing. They evidently don't. It might be that

[issue31283] Inconsistent behaviours with explicit and implicit inheritance from object

Vedran Čačić added the comment: To me, it seems like obvious behavior. What exactly do you think is inconsistent here? Of course, the default inherit-class is "what's usually known as builtins.object", and it's always the same class. You should not be able to change it just by rebinding

[issue31283] Inconsistent behaviours with explicit and implicit inheritance from object

Changes by shadowadler : -- type: -> behavior ___ Python tracker ___ ___

[issue28261] wrong error messages when using PyArg_ParseTuple to parse normal tuples

Changes by Oren Milman : -- pull_requests: +3248 ___ Python tracker ___ ___

[issue31283] Inconsistent behaviours with explicit and implicit inheritance from object

New submission from shadowadler: I discovered this while messing about with an unrelated idea, but the issue is that if you inherit explicitly from object, you get different behaviour than when you inherit implicitly. This is duplicated from my SO answer here:

[issue31260] [2.7] Enhance PC/VS9.0/ project to produce python.bat, as PCbuild/

Changes by Jeremy Kloth : -- nosy: +jkloth ___ Python tracker ___ ___

[issue31271] an assertion failure in io.TextIOWrapper.write

Changes by Oren Milman : -- pull_requests: +3247 ___ Python tracker ___ ___

[issue31065] Documentation for Popen.poll is unclear

Elena Oat added the comment: I've added a sentence saying about the explicit return value. -- keywords: +patch nosy: +Elena.Oat Added file: http://bugs.python.org/file47102/issue31065.diff ___ Python tracker

[issue31271] an assertion failure in io.TextIOWrapper.write

Oren Milman added the comment: all three versions do 'self->pending_bytes_count += PyBytes_GET_SIZE(b);', while 'b' is the object the encoder returned. in 3.6 and 3.7, the implementation of PyBytes_GET_SIZE() includes 'assert(PyBytes_Check(op))', but in 2.7, the implementation is

[issue31282] C APIs called without GIL in PyOS_Readline

Changes by Serhiy Storchaka : -- nosy: +haypo, serhiy.storchaka ___ Python tracker ___