[Python-Dev] A 'common' respository? (was Re: IDLE in the stdlib)

Philip James pjj at philipjohnjames.com
Thu Mar 21 07:06:31 CET 2013


I hope I'm not coming across as pedantic, because I think you have some
good arguments listed above, but shouldn't discussion like this go in
python-ideas rather than python-dev? I'm very new to these lists, so
forgive me if I'm stepping on any toes, I'm just trying to grok what kind
of content should go in each list.

PJJ
http://philipjohnjames.com


On Wed, Mar 20, 2013 at 7:30 PM, Terry Reedy <tjreedy at udel.edu> wrote:

> On 3/20/2013 8:15 PM, Terry Reedy wrote:
>
>  I will discuss repository separation in another response
>>
>
> Here is a radical idea I have been toying with: set up a 'common'
> repository to 'factor out' files that are, could be, or should be the same
> across versions. The 'common' files would be declared (especially to
> packagers, when relevant) to be a part of each branch. Each release would
> (somehow - not my department) incorporate the latest version of everything
> in 'common'.
>
> What would go here?
>
> Misc/ACKS: the sensible idea that there should only be one copy of this
> file has been discussed before.
>
> LICENSE: I believe this is the same across current versions and must be
> edited in parallel for all future branches.
>
> xxx: others that I have not thought of.
>
> Doc/tools (sphinx and dependencies): setting this up separately but
> identically for each branch is a bit silly if it could be avoided. The
> sphinx versions should, of course, be the new one that runs on both python
> 2 and 3.
>
> idlelib: already discussed. Having only one IDLE version would partially
> speed up development.
>
> (surely controvesial) tkinter and _tkinter: I think the _tkinter and
> tkinter for each release should work with and be tested with the most
> recent tcl/tk release. Having only one tkinter version might make having
> one version of IDLE even easier.
>
> (probably even more controversial) tcl/tk (or at least the files needed to
> fetch and build - but as long as the sources are on python.org anyway,
> the sources could also be moved here from svn): For IDLE to really work the
> same across versions, it needs to run on the same tcl/tk version with the
> same bugfixes. For example, over a year ago, a French professor wrote
> python-list or idle-sig or maybe both saying that he would like to use IDLE
> in a class in Sept 2012, but there was a bug keeping it from working
> properly with French keyboards. He wanted to know if we were likely to fix
> it. The first answer (provided by Kevin Walzer) was that it was a tcl/tk
> bug that he (Kevin) was working on. The fix made it into 8.5.9 a year ago
> and hence into 3.3 but 2.7.3 or 3.2.3, released a month after the fix. So I
> later told him he could use IDLE, but, at least on Windows, only with the
> then upcoming 3.3. (I don't know the tcl/tk version policy for the
> non-Apple builds.)
>
> I do not know if tcl/tk 8.5.z releases have added many features or are
> primarily bugfixes like our micro releases. If the latter, the case for
> distributing at least the most recent 8.5.z with windows would seem pretty
> strong. I also do not know what 8.6.z adds. But an tcl/tk 'enhancement' of
> supporting astral characters might look like a bugfix for IDLE. (Running
> from IDLE, print(astral_char) raises, but I believe the same code works in
> some Linux interpreters.)
>
> yyy: any other external dependencies that we update on all versions.
>
> ---
> Terry Jan Reedy
>
> ______________________________**_________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/**mailman/listinfo/python-dev<http://mail.python.org/mailman/listinfo/python-dev>
> Unsubscribe: http://mail.python.org/**mailman/options/python-dev/**
> pjj%40philipjohnjames.com<http://mail.python.org/mailman/options/python-dev/pjj%40philipjohnjames.com>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20130320/2836720a/attachment.html>


More information about the Python-Dev mailing list