[issue31286] import in finally results in SystemError

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Confirmed. The bug is 3.7 only.

--
nosy: +brett.cannon, eric.snow, ncoghlan, serhiy.storchaka

___
Python tracker 

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

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

[Terry J. Reedy]

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 recursively calls the .destroy methods of its children.  Here, 
ListedTopLevel.destroy is called.  It calls TopLevel.destroy and 
registry.delete.  Its menubar child and its dropdown submenu are also 
destroyed.  But LTL.destroy does *not* call the close method of the 
EditorWindow instance (which is *not* a widget).  Without a reference, it 
cannot.

Registry.delete, which is called for each ListedTopLevel *calls all the 
callbacks*, which it exactly should not do at shutdown.  It does not unregister 
the associated callback.  That is part of editor.close.

In IDLE's normal operation, editor.close must somehow get called.  In test 
setups and teardowns, I am careful to undo things in reverse order of creation. 
 It is, in a sense, a bug, as things now stand, to create an OutputWindow(root) 
without calling its close method before destroying root.

In configdialog, the callbacks are the Var tracers.  The configdialog test 
teardown removes them all.  Closing editorwindows should do the same.  This is 
not to deny that making shutdown less fragile would be a good thing.

I think having separate EditorWindow and EditorFrame classes that *are* widgets 
would help, as then better auxilliary shutdowns could be either part of or 
called from the destroy methods that get called when root.destroy is called.

Aside from the ".!menu.windows" message in the idle shell, messages like the 
following appear in the command window if there is one, with or without the 
editor.close() call.

 invalid command name "96611576font_timer_event"
while executing
"96611576font_timer_event"
("after" script)

"89887864font_timer_event"
("after" script)
invalid command name "89718392timer_event"
while executing
Functions timer_event and font_timer_event are CodeContext methods.  The 
messages don't appear if code_context is not enabled.  I don't know how the 
messages are prevented (normally) when CondContext is enabled.  The is no 
obvious graceful shutdown of the loops.  They seem to end when self.text no 
longer exists so that self.text.after must fail.  I already knew that this 
class needs work ;-).

--

___
Python tracker 

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

[issue31286] import in finally results in SystemError

[Thomas Caswell]

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
---
SystemError   Traceback (most recent call last)
 in ()
> 1 import_in_finally_fail()

/tmp/py2661VBj in import_in_finally_fail()

SystemError: 'finally' pops bad exception


The exact import does matter, but it needs to be at least 2 modules deep and be 
aliased.  

By patching cpython to put what finally pops off the stack in the error message 
it looks like it is the parent module of the import.

This was found via the Matplotlib test suite (ex 
https://travis-ci.org/matplotlib/matplotlib/jobs/262907186 ) and reported to 
pytest (https://github.com/pytest-dev/pytest/issues/2674)

--
components: Interpreter Core
messages: 300911
nosy: tcaswell
priority: normal
severity: normal
status: open
title: import in finally results in SystemError
type: crash
versions: Python 3.7

___
Python tracker 

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

[issue28638] Optimize namedtuple creation

[Ethan Smith]

Changes by Ethan Smith :


--
nosy: +Ethan Smith

___
Python tracker 

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

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

[Cheryl Sabella]

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 

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

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

[Cheryl Sabella]

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 =  outwin.OutputWindow(None, None, None, root)
w.text = Text(root)
root.mainloop()


I agree that it would be best to fix the root of the problem.  I thought maybe 
with the test, it's the way the OutputWindow is created  I tried adding an 
flist, but that still didn't suppress the warning.

--

___
Python tracker 

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

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

[Cheryl Sabella]

Changes by Cheryl Sabella :


--
pull_requests: +3254

___
Python tracker 

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

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

[Terry J. Reedy]

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")
...
windows.add_windows_to_menu(menu)

".!menu.windows" is the tk Windows Menu name, generated by tkinter and saved in 
menudict.  The function claims that it is only called when the menu exists, but 
the error is that it does not exist, even though it is still in the dict.  This 
is a bug.  It must result from a bug either in IDLE or the test teardown code, 
or maybe both.  I would rather fix the bug than shoot the messenger ;-)

Side note: the callback handling strikes me as slightly crazy.  Creating a 
ListedTopLevel calls registry.add, which calls all the callbacks, each of which 
regenerates the menu.

--

___
Python tracker 

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

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

[Terry J. Reedy]

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 selected in config.py with

@staticmethod
def default_keys():
if sys.platform[:3] == 'win':
return 'IDLE Classic Windows'
elif sys.platform == 'darwin':
return 'IDLE Classic OSX'
else:
return 'IDLE Modern Unix'

This change accompanied the addition of the Modern Unix keyset.

If the makefile for 3.6+ still has the sed command to replace 'Windows' with 
'OSX', you can remove it.


B1. #27099 is moving all built-in user-configurable key defs in 
config-extensions.def to individual keysets in config-keys.def.  These are:

force-open-completions = 
expand-word = 
force-open-calltip = 
format-paragraph = 
flash-paren = 
run-module = 
check-module = 
zoom-height = 

According to my reading of
https://hg.python.org/cpython/rev/13826ff147e4
the makefile changes each 'Alt-Key-' to  'Command-Key-', with an additional 
change for zoom-height.  We can instead put the correct keys in the Mac and OSX 
keysets.

B2. Serhiy: Are any of the above 'wrong' for Unix/Linux?  Or should any 
alternatives be added?

B3. Custom keysets will initially be missing the new defs.  IdleConf currently 
replaces missing values with the windows values (hard-coded into the file).  I 
think it should instead get replacements from the OS-specific default -- and 
perhaps check for conflicts.  Then it should, if possible, write-back the 
complete keyset.


C. There are various proposals to add new customizable key definitions for 
existing and new features.  The issues in B, customizing default keysets and 
augmenting custom keysets, will come up repeatedly.  When I decide to add a new 
key definition, I could nosy you two, Ned and Serhiy, or add a note to this 
issue.

--
dependencies: +IDLE: turn builting extensions into regular modules

___
Python tracker 

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

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

[Terry J. Reedy]

Changes by Terry J. Reedy :


--
nosy: +serhiy.storchaka -westley.martinez

___
Python tracker 

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

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

[Terry J. Reedy]

Terry J. Reedy added the comment:

This issue is almost done.  There are just a few things missed by the closed 
dependencies.

--

___
Python tracker 

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

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

[Terry J. Reedy]

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 includes the circle and 
label.)
* Button flat (I know that we could restore 'old-fashioned' relief with 
explicit styles) and sometimes larger.
Font sample left-justified instead of centered.  No necessarily bad.

Overall, a slight improvement even on Windows.  We can tweak details when 
revising individual pages.

The dynamic option menus look out of place, and should be replaced.

--
dependencies:  -IDLE: configdialog - add tests for ConfigDialog GUI.
resolution:  -> fixed
stage: test needed -> 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

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

[Terry J. Reedy]

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


--

___
Python tracker 

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

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

[Charles Wohlganger]

Changes by Charles Wohlganger :


--
pull_requests: +3253

___
Python tracker 

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

[issue31265] Remove doubly-linked list from C OrderedDict

[Raymond Hettinger]

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 more challenging 
for people to upgrade their python -- the standard library is intended to be 
standard rather than highly mutable). It is a big deal to rip-out the pure 
python version and impose obligations on other implementations.  Over time, 
we've tried to move in the direction of more pure python code rather than less. 
 The pure python code is easier to understand, easier to maintain, generally 
less buggy, and is more portable.  People currently using OrderedDict are 
choosing it specifically because they want the ordering behavior.  That is 
currently implemented in an algorithmically correct way that preserves the 
big-oh behavior in the face of deletions and updates.  In contrast, the regular 
dict only happens to be ordered and internally is achieving order by 
maintaining a sequence of consecutive pointers.  This doesn't have the same 
perfor
 mance characteristics and would be a step backwards for some use cases.  
Lastly, if the ordering of regular dicts becomes guaranteed, then 
collections.OrderedDict() will mostly become irrelevant so there is no need to 
change it all.

For now, this proposal is on hold because 1) it isn't clear that it should be 
done, 2) it needs a lot of serious discussion before proceeding, 3) it may be 
premature while the status of the regular dict is still in flux.

--
assignee:  -> rhettinger
resolution:  -> later

___
Python tracker 

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

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

[R. David Murray]

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 direct reference, and changing builtins won't 
change it.  So this is really just a specific example of how python namespacing 
works in general.

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

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

[Oren Milman]

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
module_globals['__loader__'].get_source(module_globals['__name__']).splitlines()
is a list.

--

___
Python tracker 

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

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

[Raymond Hettinger]

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 that it is possible to either shadow or alter builtins).  I 
don't see any magic here beyond changing a variable name to refer to a new 
object while previous references (or builtin references) to that name continue 
to refer to old object.

--
nosy: +rhettinger

___
Python tracker 

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

[issue30761] pdb: Add step / next count arguments

[Barry A. Warsaw]

Changes by Barry A. Warsaw :


--
nosy: +barry

___
Python tracker 

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

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

[Emily Morehouse]

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 free 
to break lines to avoid this. If you would like to submit a PR on Github for 
these changes, it can more easily be merged in. (Check 
https://docs.python.org/devguide/pullrequest.html for more info).

--

___
Python tracker 

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

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

[Vedran Čačić]

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 a lot of places it would be possible to say that some builtin is 
implicit in the statement itself: e.g.

while t:   is equivalent to   while bool(t):
for a in b: is equivalent tofor a in iter(b):

- of course, the docs _don't_ currently say so, so maybe this occurance too 
should just be deleted. But I still think there are lots of places where docs 
refer to builtins directly.]

--

___
Python tracker 

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

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

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Thank you for your contribution Oren!

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

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

[Elena Oat]

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 

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

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

[Vedran Čačić]

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 docs, in various places it is written that some code is 
equivalent to some other code, where it's obvious that those are not completely 
equivalent in your sense.

E.g. "a_list += [1, 2, 3] is equivalent to a_list.extend([1, 2, 3])" 
(https://docs.python.org/3.5/faq/programming.html?highlight=equivalent#why-did-changing-list-y-also-change-list-x)

where it's obvious that the second one is an expression, while the first one is 
not. Also, the docs are full of "equivalents" to various idioms from _other 
programming languages_, where again it's obvious that total behavioral 
equivalence is not what's intended.

--

___
Python tracker 

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

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

[Serhiy Storchaka]

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)
https://github.com/python/cpython/commit/bc80fd1bd2e8b6817accbc101e7fe5e50ba8f768


--

___
Python tracker 

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

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

[Oren Milman]

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 BadSource()

del warnings._showwarnmsg
warnings.warn_explicit(message='foo', category=ArithmeticError, filename='bar',
   lineno=1, module_globals={'__loader__': BadLoader(),
 '__name__': 'foobar'})

in short, the assertion failure would happen in warnings.warn_explicit() in case
module_globals['__loader__'].get_source(module_globals['__name__']).splitlines()[lineno-1]
is not a str.


2.
the following raises a SystemError:

import warnings

class BadLoader:
def get_source(self, fullname):
class BadSource:
def splitlines(self):
return 42
return BadSource()

warnings.warn_explicit(message='foo', category=UserWarning, filename='bar',
   lineno=42, module_globals={'__loader__': BadLoader(),
  '__name__': 'foobar'})

in short, warnings.warn_explicit() raises the SystemError in case
module_globals['__loader__'].get_source(module_globals['__name__']).splitlines()
is not a list.



ISTM that adding a check in warnings_warn_explicit() (in Python/_warnings.c),
to check whether
module_globals['__loader__'].get_source(module_globals['__name__'])
is a str (after existing code found out that it isn't None) would prevent both
the assertion failure and the SystemError.

What do you think? Is it OK to permit get_source() to return only None or a str?

--
components: Interpreter Core
messages: 300892
nosy: Oren Milman
priority: normal
severity: normal
status: open
title: a SystemError and an assertion failure in warnings.warn_explicit()
type: crash
versions: Python 3.7

___
Python tracker 

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

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

[shadowadler]

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 mentioned in the documentation. It 
led me to expect one behaviour and find another. That is the extent of my 
issue, and the fix seems to be to be small.

--

___
Python tracker 

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

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

[Terry J. Reedy]

Changes by Terry J. Reedy :


--
pull_requests: +3252

___
Python tracker 

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

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

[Terry J. Reedy]

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


--

___
Python tracker 

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

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

[Jim Fulton]

Jim Fulton added the comment:

See: https://github.com/pypa/pip/issues/4695

--

___
Python tracker 

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

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

[Oren Milman]

Changes by Oren Milman :


--
pull_requests: +3251

___
Python tracker 

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

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

[Vedran Čačić]

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 None, which means to use the default values. If no 
objects are given, print() will just write end. The file argument must be an 
object with a write(string) method; if it is not present or None, sys.stdout 
will be used.

Is the above so different than writing:

print(*args, file=f, sep=s, end=e)

is equivalent to

f.write(s.join(map(str, args))+e)

? In my head, no. It's just that sometimes we use Python, and sometimes 
English, to describe the semantics.

--

___
Python tracker 

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

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

[Serhiy Storchaka]

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)
https://github.com/python/cpython/commit/9bcbc6cba385a83cac8f1ff430cad7617184d2bc


--

___
Python tracker 

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

[issue31072] add filter to zipapp

[Paul Moore]

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


--

___
Python tracker 

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

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

[Cheryl Sabella]

Changes by Cheryl Sabella :


--
pull_requests: +3250

___
Python tracker 

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

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

[Cheryl Sabella]

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 `postwindowsmenu()` from editor, which is set for the `windows` 
menu.  The line `end = menu.index("end")` is the line that fails.

--
assignee: terry.reedy
components: IDLE
messages: 300885
nosy: csabella, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE: Fix WindowList invalid command name error when running tests
type: enhancement
versions: Python 3.7

___
Python tracker 

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

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

[Serhiy Storchaka]

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 side, adding a check for 
bytes can break existing user code that is passed now by accident. 
_PyBytes_Join() in 2.7 supports unicode objects.

I think that the fix should be backported, and the proper fix should allow 
bytes and unicode objects. But I left the decision on Benjamin.

--
nosy: +benjamin.peterson

___
Python tracker 

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

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

[shadowadler]

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.

--

___
Python tracker 

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

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

[R. David Murray]

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 python, an entity is identified by an id (which is a 
memory address in CPython, but that's an implementation detail).  A name is 
just a convenience label used to refer to that id.  When you rebind a name, you 
change what id it points to, but any other piece of python that is already 
using the original id is not affected.  But anything using an indirect 
reference through another object (such as builtins) *will* see the change.

Your argument, then, is that it is not documented that 'class x:' is using a 
direct reference to object rather than an indirect reference.  Our argument is 
that this is obviously the way Python works (the interpreter itself refers 
directly to the fundamental entities such as the base of the exception 
hierarchy and object).

The number of places that would need to be changed to make this explicit is 
much smaller than I was thinking when I closed the issue, but I'm still not 
convinced it is something that needs to be explicitly documented.  It is just 
part of the way Python works at a fundamental level, and because it is a 
*statement* that does not refer to a variable, it is intuitive that it is going 
to reference the original object, not whatever builtins.object is referring to.

We do say that explicit is better than implicit, but in this case we're talking 
about a fundamental part of the language, and the specification of how this 
works probably belongs in some overview section on statements.  On the other 
hand, are there any examples *other* than class and except where this 
distinction matters?

--
resolution: not a bug -> 
stage: resolved -> 
status: closed -> open

___
Python tracker 

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

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

[shadowadler]

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.

--

___
Python tracker 

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

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

[R. David Murray]

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 disclaimers in thousands of places in the 
documentation.  That's not something that is going to be done :)

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

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

[Steve Dower]

Changes by Steve Dower :


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

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

[shadowadler]

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.

--

___
Python tracker 

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

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

[Vedran Čačić]

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 
builtin. E.g.

(print): All non-keyword arguments are converted to strings like str() does
(repr): this function makes an attempt to return a string that would yield an 
object with the same value when passed to eval()
(type): The isinstance() built-in function is recommended for testing the type 
of an object

Of course, all of these must be changed, since they don't work as advertised if 
you rebind str, eval or isinstance.

I claim this is nonsense. If anything, we should educate people that when 
documentation refers to "the builtin X", it doesn't mean "whatever is current 
referrent of builtins.X". Never. Only "__import__" kinda works this way (though 
not in builtins, but in globals), and that's mostly a historic accident.

--

___
Python tracker 

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

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

[Eric V. Smith]

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 

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

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

[Jim Fulton]

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 tracker 

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

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

[Roundup Robot]

Changes by Roundup Robot :


--
pull_requests: +3249

___
Python tracker 

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

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

[Serhiy Storchaka]

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)
https://github.com/python/cpython/commit/8e67981fc8e1bf3cb9774b5fbf4a39b8d65ba4ff


--

___
Python tracker 

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

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

[Steven D'Aprano]

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: +docs@python

___
Python tracker 

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

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

[shadowadler]

shadowadler added the comment:

Still not disagreeing with you- I just don't think that this is what the 
documentation implies.

--

___
Python tracker 

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

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

[Steven D'Aprano]

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 genuine, 
builtin object base class. There's no name lookup, it is all built into the 
guts of the interpreter.

But if you specify the name of a base class:

class Spam(foo): ...

then foo is looked up at runtime, regardless of whether you type "foo" or "int" 
or "str" or "object". If you have replaced or shadowed the builtin object with 
your own class, then you'll get *that* as the base for Spam, not the real 
built-in object base class.

--
nosy: +steven.daprano

___
Python tracker 

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

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

[shadowadler]

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 point of view, if 
nothing else. If we are to maintain the fiction that these two things are 
equivalent, then they should yield the same result. If they are not equivalent, 
then we should state that this is the case explicitly.

--

___
Python tracker 

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

[issue31072] add filter to zipapp

[Paul Moore]

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.

--

___
Python tracker 

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

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

[Vedran Čačić]

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

before.

Rebinding the names for fundamental objects in Python doesn't change the 
semantics of these objects. Python interpreter is an external thing: it doesn't 
exist "in-universe". It doesn't refer to these objects by names in some 
currently-executing-Python-instance namespace, it refers to them externally. 
And, mostly, so do we when explaining how Python works.

Let me give you an analogy: In the old days, you could rebind True and False, 
for example by saying

True, False = False, True

But of course, you would trivially understand that after such rebinding,

if 6 > 4:
print(1)
else:
print(2)

would print 1, not 2. Although we might say "(6>4) is True" while giving the 
semantics of "if" statement, we _don't_ mean "the object referred by the 
internal name 'True'". We mean the object _externally_ referred by the name 
'True'.

Same as with your "hierarchy question": if you _give_ the explicit list of 
bases, you give it as a list of names. Those names can be rebound and if the 
class definition is executed in such a changed namespace, the bases will 
differ. But you can't rebind anything if you haven't given any explicit base 
names in the first place. It doesn't matter whether a class is "at the top" or 
somewhere else; it matters whether its name is explicitly given.

An illustration: Let's say you have executed

class A: pass
class B(A): pass

so now A refers to some class, and B refers to another class, inherited from A. 
If you now execute

class C(B): pass  # *

you will have a new class C, inherited from B. Of course, if you now change B 
somehow, and then execute (*) again, you will have another class C, inherited 
from changed B - because (*) refers to B explicitly. But if you change _A_ 
somehow, and then execute (*) again, you will have C inherited from the same 
old B - because (*) doesn't refer to A explicitly. As you see, it doesn't 
matter whether A is "on the top" (in fact object is on the top, above A), what 
matters is whether the statement (*) that you re-execute in the changed 
namespace refers to it by name or not.

--

___
Python tracker 

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

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

[shadowadler]

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 tracker 

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

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

[shadowadler]

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 the correct 
"solution" is that this is more properly documented that the two are not 
equivalent.

--

___
Python tracker 

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

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

[Vedran Čačić]

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 builtins.object to something else. Just like you 
shouldn't be able to change the top of exception hierarchy by rebinding 
builtins.BaseException, for example. :-)

--
nosy: +veky

___
Python tracker 

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

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

[shadowadler]

Changes by shadowadler :


--
type:  -> behavior

___
Python tracker 

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

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

[Oren Milman]

Changes by Oren Milman :


--
pull_requests: +3248

___
Python tracker 

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

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

[shadowadler]

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: 
https://stackoverflow.com/questions/1238606/is-it-necessary-or-useful-to-inherit-from-pythons-object-in-python-3-x/45893772#45893772

If you explicitly inherit from object, what you are actually doing is 
inheriting from builtins.object regardless of what that points to at the time.

Therefore, I could have some (very wacky) module which overrides object for 
some reason. We'll call this first module "newobj.py":

import builtins

old_object = builtins.object  # otherwise cyclic dependencies

class new_object(old_object):

def __init__(self, *args, **kwargs):
super(new_object, self).__init__(*args, **kwargs)
self.greeting = "Hello World!" 

builtins.object = new_object  #overrides the default object
Then in some other file ("klasses.py"):

class Greeter(object):
pass

class NonGreeter:
pass
Then in a third file (which we can actually run):

import newobj, klasses  # This order matters!

greeter = klasses.Greeter()
print(greeter.greeting)  # prints the greeting in the new __init__

non_greeter = NonGreeter()
print(non_greeter.greeting) # throws an attribute error
So you can see that, in the case where it is explicitly inheriting from object, 
we get a different behaviour than where you allow the implicit inheritance.

--
messages: 300865
nosy: shadowadler
priority: normal
severity: normal
status: open
title: Inconsistent behaviours with explicit and implicit inheritance from 
object
versions: Python 3.5, Python 3.6

___
Python tracker 

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

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

[Jeremy Kloth]

Changes by Jeremy Kloth :


--
nosy: +jkloth

___
Python tracker 

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

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

[Oren Milman]

Changes by Oren Milman :


--
pull_requests: +3247

___
Python tracker 

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

[issue31065] Documentation for Popen.poll is unclear

[Elena Oat]

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 

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

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

[Oren Milman]

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 
'PyString_GET_SIZE',
which is just 'Py_SIZE(op)'.

and so, in 2.7 there isn't an assertion failure. Moreover,
'self->pending_bytes_count' is used only to determine whether a flush is needed.
so ISTM that probably the bug's only risk is not flushing automatically after
writing.
note that whenever _textiowrapper_writeflush() is finally called (when the
encoder returned a non-string object), it would raise a TypeError by calling
string_join() on a non-string object.

do you still think we should backport to 2.7?

--

___
Python tracker 

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

[issue31282] C APIs called without GIL in PyOS_Readline

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
nosy: +haypo, serhiy.storchaka

___
Python tracker 

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