Terry J. Reedy added the comment:
Files were renamed later in May. Some things were backported to 3.5 and even
2.7 for 3.5.3 and 2.7.13. Anything involving ttk, which will soon be nearly
all tkinter code, could not and cannot be backported.
--
resolution: postponed -> rejected
Terry J. Reedy added the comment:
I finished reopening #24225 (renaming), for 3.6 only. I will open a new issue
with Larry Hastings nosy, should I proposed (next fall) to backport the
revamped idlelib to 3.5.
--
resolution: -> postponed
superseder: -> Idlelib: changing file names
Terry J. Reedy added the comment:
Both Serhiy and Ned have expressed concern about the difficulty of merging
patches from 3.5 to 3.6 once the 3.6 files are renamed. To me, this is a
non-issue since I don't expect to do that more than a few times, and some may
be null merges of backports of
Terry J. Reedy added the comment:
In response to Nick's point 4: To me, these are important aspects of 'in the
stdlib'.
First is having issues on this tracker. As Guido said in his King Day speech,
non-trivial software is a collective project. IDLE needs continued access to
dependency
Terry J. Reedy added the comment:
I should have explained my usage of 'idle2' and 'idle3'. 'Idle1' was the
original IDLE that executed user code in the idle process. 'Idle2' was the
re-write, still in use, that executes user code in a separate process. 'Idle3'
is intended to be a re-write
Nick Coghlan added the comment:
+1 for Ned's point that PEP 434 grants the IDLE developers *permission* to
backport IDLE enhancements to maintenance releases, but doesn't *oblige* them
to provide such backports.
For Python 3.6, another point to keep in mind is that if anyone particularly
Ned Deily added the comment:
Glad to be of help with regards to 8.4 :=) With my 3.6 release manager hat on,
I think the best way to think of this is as a new feature: call it "Ttk IDLE"
or some such (and not idle2 vs idle3 which I think is confusing) and, rather
than inventing something new,
Terry J. Reedy added the comment:
Ned, thank you for the helpful response. Yes, I *was* proposing two versions
in 3.5 and subsequent releases until the current version could be deleted. Its
an ugly, least bad alternative that only made sense under the presumption that
'idle2' had to remain
Ned Deily added the comment:
Terry, I'm all for having IDLE using the newer Ttk widgets and for refactoring
to make it easier to enhance and maintain IDLE. I'm not sure I understand the
proposal to make two sets of IDLE files: does this mean there would be two
versions of IDLE in one branch,
Terry J. Reedy added the comment:
In response to 1. I considered copying idlelib as a whole as a serious
possibility, meant to include it as an alternative, and am willing to
reconsider my choice. I specifically thought of something like idlelib3 or
idlelib/idle3, but not _idlelib, A
Nick Coghlan added the comment:
Terry, have you considered also doing a top level idlelib -> _idlelib rename in
addition to the file level name changes?
My rationale for suggesting that:
1. The idle2 vs idle3 distinction will be clear at a glance (as they'll be in
different directories)
2.
New submission from Terry J. Reedy:
Proposal: duplicate nearly all of the existing idlelib *.py files, with new
names. This would implement the intention of PEP 434 with respect to freely
changing idlelib APIs. I view it as a prerequisite for most anticipated
patches. A longer than usual
12 matches
Mail list logo
