[Python-Dev] Summary of Python tracker Issues

2014-05-30 Thread Python tracker 

ACTIVITY SUMMARY (2014-05-23 - 2014-05-30)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open4635 (+13)
  closed 28750 (+40)
  total  33385 (+53)

Open issues with patches: 2127 


Issues opened (41)
==

#16638: support multi-line docstring signatures in IDLE calltips
http://bugs.python.org/issue16638  reopened by rhettinger

#21561: help() on enum34 enumeration class creates only a dummy docume
http://bugs.python.org/issue21561  opened by andymaier

#21563: Segv during call to builtin_execfile in application embedding 
http://bugs.python.org/issue21563  opened by snoeberger

#21564: Declaration of EVP_MD_CTX causes crash when switching between 
http://bugs.python.org/issue21564  opened by Ryan.Calhoun

#21566: make use of the new default socket.listen() backlog argument
http://bugs.python.org/issue21566  opened by neologix

#21567: cannot create multipart alternative message with us-ascii char
http://bugs.python.org/issue21567  opened by Viktor.Szépe

#21568: Win32 pip doesn't use relative path to found site-packages.
http://bugs.python.org/issue21568  opened by 勇刚.罗

#21569: PEP 466: Python 2.7 What's New preamble changes
http://bugs.python.org/issue21569  opened by ncoghlan

#21571: Python build should check CPATH, C_INCLUDE_PATH for module dep
http://bugs.python.org/issue21571  opened by JanKanis

#21572: Use generic license web page rather than requiring release-spe
http://bugs.python.org/issue21572  opened by ned.deily

#21573: Clean up turtle.py code formatting
http://bugs.python.org/issue21573  opened by jesstess

#21574: Port image types detections from PIL to the imghdr module
http://bugs.python.org/issue21574  opened by serhiy.storchaka

#21576: Overwritten (custom) uuid inside dictionary
http://bugs.python.org/issue21576  opened by beta990

#21577: Help for ImportError should show a more useful signature.
http://bugs.python.org/issue21577  opened by eric.snow

#21578: Misleading error message when ImportError called with invalid 
http://bugs.python.org/issue21578  opened by eric.snow

#21579: Python 3.4: tempfile.close attribute does not work
http://bugs.python.org/issue21579  opened by mmarkk

#21580: PhotoImage(data=...) apparently has to be UTF-8 or Base-64 enc
http://bugs.python.org/issue21580  opened by vadmium

#21581: Consider dropping importlib.abc.Loader.create_module()
http://bugs.python.org/issue21581  opened by brett.cannon

#21582: use support.catpured context managers - test_asyncore
http://bugs.python.org/issue21582  opened by diana

#21583: use support.catpured_stderr context manager - test_logging
http://bugs.python.org/issue21583  opened by diana

#21585: Run Tkinter tests with wantobjects=False
http://bugs.python.org/issue21585  opened by serhiy.storchaka

#21588: Idle: make editor title bar user configurable
http://bugs.python.org/issue21588  opened by terry.reedy

#21590: Systemtap and DTrace support
http://bugs.python.org/issue21590  opened by bkabrda

#21591: "exec(a, b, c)" not the same as "exec a in b, c" in nested fun
http://bugs.python.org/issue21591  opened by Robert.Jordens

#21592: Make statistics.median run in linear time
http://bugs.python.org/issue21592  opened by Thomas.Dybdahl.Ahle

#21593: Clarify re.search documentation first match
http://bugs.python.org/issue21593  opened by Joshua.Landau

#21594: asyncio.create_subprocess_exec raises OSError
http://bugs.python.org/issue21594  opened by Sebastian.Kreft.Deezer

#21595: Creating many subprocess generates lots of internal BlockingIO
http://bugs.python.org/issue21595  opened by Sebastian.Kreft.Deezer

#21596: asyncio.wait fails when futures list is empty
http://bugs.python.org/issue21596  opened by Sebastian.Kreft.Deezer

#21597: Allow turtledemo code pane to get wider.
http://bugs.python.org/issue21597  opened by terry.reedy

#21599: Argument transport in attach and detach method in Server class
http://bugs.python.org/issue21599  opened by vajrasky

#21600: mock.patch.stopall doesn't work with patch.dict to sys.modules
http://bugs.python.org/issue21600  opened by kakuma

#21601: Cancel method for Asyncio Task is not documented
http://bugs.python.org/issue21601  opened by vajrasky

#21603: IDLE SaveAs drops the extension in the prompted filename
http://bugs.python.org/issue21603  opened by rhettinger

#21604: Misleading 2to3 fixer name in documentation: standard_error
http://bugs.python.org/issue21604  opened by wluebbe

#21605: Add tests for Tkinter images
http://bugs.python.org/issue21605  opened by serhiy.storchaka

#21608: logging.handlers.HTTPHandler.setFormatter() has no effect
http://bugs.python.org/issue21608  opened by bk2zsto

#21610: load_module not closing opened files
http://bugs.python.org/issue21610  opened by mattip

#21611: int() docstring - unclear what number is
http://bugs.python.org/issue21611  opened by and

#21612: IDLE should not

Re: [Python-Dev] Language Summit Follow-Up

2014-05-30 Thread Chris Barker 
On Thu, May 29, 2014 at 4:43 AM, Nick Coghlan  wrote:

> For that last point, my interest is as much educational as it is in
> easing the transition from Python 2. The parentheses in "print('Hello
> world!')" mean introducing the idea of function calls early to explain
> how it works, while being able to omit them makes it easier to gloss
> over the distinction between statements and function calls initially
> and then cover it later after the basics of flow control have been
> nailed down.
>

I've been doing a lot of intro-to-python teaching lately (py2 so far...),
and I understand this desire. IN fact, a lot of notes point to the fact
that python's "hello world" is simply : print "hello world", rather than
what is required in some languages to do something that simple.

However, I also believe that when teaching it's better to introduce the
"right way" to do something up front, rather than a "beginners' way", then
later say, well, you really SHOULD do it this other way... So if we want
our students to use print as a function, we might a well start them off
that way. Saying that their very first easy program is:

print("hello world")

is fine -- they don't have to know or understand what a function call is --
they simply copy the syntax. And frankly, we get to simple function calls,
VERY early in the program -- you can't really do anything without them...

In fact, in my latest class, we've made an effort to introduce
forward-thinking up front, even before we explain quite what it all means:

use u"a string" to make a string

you write a class like:

class C(object):
   ...

before we talk about subclassing, or what "object" is...

just my $0.02

-Chris












> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   [email protected]   |   Brisbane, Australia
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/chris.barker%40noaa.gov
>



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

[email protected]
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Language Summit Follow-Up

2014-05-30 Thread Mark Roberts 
On Thu, May 29, 2014 at 9:30 AM, Terry Reedy  wrote:

> On 5/28/2014 6:26 PM, Glyph Lefkowitz wrote:
>
>  I hope it's
>> not controversial to say that most new Python code is still being
>> written against Python 2.7 today;
>>
>
> Given that Python 3 downloads now outnumber Python 2 downloads, I think
> 'most' might be an overstatement. But I think it a moot point.



How can you determine that Python3 downloads actually outnumber Python2
downloads?  It seems that looking at Windows downloads (as I saw in a
thread earlier this month) is fallacious at absolute best.  Linux and OSX
both ship with Python2, and most downloads happen via individual package
management tools.  Even including Python3.4 as a default Python3 doesn't
mean that it's the default Python on the system.

>From my perspective as an engineer and library maintainer: Pypi seems to
indicate an overwhelming number of Python2 usage, and so do the job
requisitions that I've seen.  Furthermore, even Python based libraries for
cutting edge technologies are still written in Python2 and later converted
to Python3.  I just don't understand how we (as a community) can make the
assertion that most "new Python" is written in Python 3.

What I'd really like to see is a Python 2.8 that makes sufficient changes
to Python 2 that writing libraries which cross the boundary between 2 and 3
is relatively easy instead of a painful nightmarish chore.  Because when
push comes to shove, Python 2 support is still infinitely more important
than Python 3.

-Mark
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Language Summit Follow-Up

2014-05-30 Thread Chris Angelico 
On Sat, May 31, 2014 at 3:40 AM, Mark Roberts  wrote:
> What I'd really like to see is a Python 2.8 that makes sufficient changes to
> Python 2 that writing libraries which cross the boundary between 2 and 3 is
> relatively easy instead of a painful nightmarish chore.  Because when push
> comes to shove, Python 2 support is still infinitely more important than
> Python 3.

That's of absolutely ZERO value to anyone who has to maintain support
for Python 2.3 or even 2.7. Will this hypothetical 2.8 run, unchanged,
all code written for 2.7? If not, all you've done is add a third
branch to maintain, and solved nothing; and if it will, how much can
you really change?

ChrisA
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Language Summit Follow-Up

2014-05-30 Thread Mark Lawrence 

On 30/05/2014 18:40, Mark Roberts wrote:


What I'd really like to see is a Python 2.8 that makes sufficient
changes to Python 2 that writing libraries which cross the boundary
between 2 and 3 is relatively easy instead of a painful nightmarish
chore.  Because when push comes to shove, Python 2 support is still
infinitely more important than Python 3.

-Mark



What is the point of flogging a horse that's been dead for so long that 
it's already down to a skeleton?


--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Language Summit Follow-Up

2014-05-30 Thread Ethan Furman 

On 05/30/2014 09:46 AM, Chris Barker wrote:

On Thu, May 29, 2014 at 4:43 AM, Nick Coghlan wrote:


For that last point, my interest is as much educational as it is in
easing the transition from Python 2. The parentheses in "print('Hello
world!')" mean introducing the idea of function calls early to explain
how it works, while being able to omit them makes it easier to gloss
over the distinction between statements and function calls initially
and then cover it later after the basics of flow control have been
nailed down.



However, I also believe that when teaching it's better to introduce the "right 
way" to do something up front, rather
than a "beginners' way", then later say, well, you really SHOULD do it this 
other way...


+1

Function calls are not that hard to understand.  Anybody who has ever asked someone to do something for them should have 
a basic grasp of the nature of a function call.


--
~Ethan~
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython: Issue #20383: Introduce importlib.util.module_from_spec().

2014-05-30 Thread Eric Snow 
On Fri, May 30, 2014 at 12:55 PM, brett.cannon
 wrote:
> http://hg.python.org/cpython/rev/b26d021081d2
> changeset:   90915:b26d021081d2
> parent:  90913:69011f6ce573
> user:Brett Cannon 
> date:Fri May 30 14:55:29 2014 -0400
> summary:
>   Issue #20383: Introduce importlib.util.module_from_spec().
>
> diff --git a/Lib/importlib/_bootstrap.py b/Lib/importlib/_bootstrap.py
> --- a/Lib/importlib/_bootstrap.py
> +++ b/Lib/importlib/_bootstrap.py
> @@ -581,20 +581,19 @@
>  return loader
>
>
> -def _load_module_shim(self, fullname):
> +def _load_module_shim(spec, fullname):
>  """Load the specified module into sys.modules and return it.

This should have stayed "self", no?

-eric
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython: Issue #20383: Introduce importlib.util.module_from_spec().

2014-05-30 Thread Brett Cannon 
On Fri May 30 2014 at 3:39:47 PM, Eric Snow 
wrote:

> On Fri, May 30, 2014 at 12:55 PM, brett.cannon
>  wrote:
> > http://hg.python.org/cpython/rev/b26d021081d2
> > changeset:   90915:b26d021081d2
> > parent:  90913:69011f6ce573
> > user:Brett Cannon 
> > date:Fri May 30 14:55:29 2014 -0400
> > summary:
> >   Issue #20383: Introduce importlib.util.module_from_spec().
> >
> > diff --git a/Lib/importlib/_bootstrap.py b/Lib/importlib/_bootstrap.py
> > --- a/Lib/importlib/_bootstrap.py
> > +++ b/Lib/importlib/_bootstrap.py
> > @@ -581,20 +581,19 @@
> >  return loader
> >
> >
> > -def _load_module_shim(self, fullname):
> > +def _load_module_shim(spec, fullname):
> >  """Load the specified module into sys.modules and return it.
>
> This should have stayed "self", no?
>
>
Yes. Fixed with an added comment to explain why since it isn't obvious in
isolation.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Language Summit Follow-Up

2014-05-30 Thread Antoine Pitrou 
On Wed, 28 May 2014 15:26:38 -0700
Glyph Lefkowitz  wrote:
> Backport 'yield from' to allow people to use Tulip and Tulip-compatible code, 
> and to facilitate the development of Tulip-friendly libraries and a Tulip 
> ecosystem.  A robust Tulip ecosystem requires the participation of people who 
> are not yet using Python 3.

I was wondering whether you were trolling or not on this one.
>From a quality assurance point of view, adding major features to a
bugfix branch is extremely destructive, so I'm strongly -1 on it.

> Get rid of 2to3. Particularly, of any discussion of using 2to3 in the 
> documentation.  More than one very experienced, well-known Python developer 
> in this discussion has told me that they thought 2to3 was the blessed way to 
> port their code, and it's no surprise that they think so, given that the 
> first technique  mentions is 
> still 2to3.

2to3 is certainly fine if you are porting to 3.x without looking to
keep your code 2.x-compatible. Until there's a better alternative, of
course.
So what we should do is better explain the choice (if you want to port
your code to 3.x, use 2to3; if you want to maintain dual-compatible
code, use six or something similar).

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Language Summit Follow-Up

2014-05-30 Thread Guido van Rossum 
2to3 is poorly named. With different fixers it is a fine tool for
converting 2-only code to 2-and-3 straddling code. Even when using six, you
need to do things like convert print statements to print() calls with
future import, use 'as' in except clauses, and so on.


On Fri, May 30, 2014 at 1:47 PM, Antoine Pitrou  wrote:

> On Wed, 28 May 2014 15:26:38 -0700
> Glyph Lefkowitz  wrote:
> > Backport 'yield from' to allow people to use Tulip and Tulip-compatible
> code, and to facilitate the development of Tulip-friendly libraries and a
> Tulip ecosystem.  A robust Tulip ecosystem requires the participation of
> people who are not yet using Python 3.
>
> I was wondering whether you were trolling or not on this one.
> From a quality assurance point of view, adding major features to a
> bugfix branch is extremely destructive, so I'm strongly -1 on it.
>
> > Get rid of 2to3. Particularly, of any discussion of using 2to3 in the
> documentation.  More than one very experienced, well-known Python developer
> in this discussion has told me that they thought 2to3 was the blessed way
> to port their code, and it's no surprise that they think so, given that the
> first technique  mentions
> is still 2to3.
>
> 2to3 is certainly fine if you are porting to 3.x without looking to
> keep your code 2.x-compatible. Until there's a better alternative, of
> course.
> So what we should do is better explain the choice (if you want to port
> your code to 3.x, use 2to3; if you want to maintain dual-compatible
> code, use six or something similar).
>
> Regards
>
> Antoine.
>
>
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Language Summit Follow-Up

2014-05-30 Thread Nick Coghlan 
On 31 May 2014 08:42, "Guido van Rossum"  wrote:
>
> 2to3 is poorly named. With different fixers it is a fine tool for
converting 2-only code to 2-and-3 straddling code. Even when using six, you
need to do things like convert print statements to print() calls with
future import, use 'as' in except clauses, and so on.

Both modernize & futurize build on lib2to3 to do the heavy lifting - they
don't reinvent that wheel, they just change which fixes are applied by
default and add a few more of their own.

However, even if going straight to Python 3, I suspect folks would still be
better off doing something like:

* futurize --stage1 (migrates to 2.6+, but adds no new runtime dependencies
- the output should be fairly idiomatic Python 2.6/7 code)
* 2to3 (wholesale migration to Python 3)

The trick, though, is that the granularity of that approach is at the
process level - the entire application must be converted at once. You also
can't start your own migration until all your dependencies are available in
Python 3.

By contrast, migration via the common subset can be incremental and
opportunistic:

* the granularity of migration is individual modules, rather than entire
processes, so you can make a low risk gradual transition, even without a
comprehensive regression test suite
* you initially stay on Python 2, so you can start whenever is convenient
for you, rather than having to wait for all your dependencies

Cheers,
Nick.

>
>
> On Fri, May 30, 2014 at 1:47 PM, Antoine Pitrou 
wrote:
>>
>> On Wed, 28 May 2014 15:26:38 -0700
>> Glyph Lefkowitz  wrote:
>> > Backport 'yield from' to allow people to use Tulip and
Tulip-compatible code, and to facilitate the development of Tulip-friendly
libraries and a Tulip ecosystem.  A robust Tulip ecosystem requires the
participation of people who are not yet using Python 3.
>>
>> I was wondering whether you were trolling or not on this one.
>> From a quality assurance point of view, adding major features to a
>> bugfix branch is extremely destructive, so I'm strongly -1 on it.
>>
>> > Get rid of 2to3. Particularly, of any discussion of using 2to3 in the
documentation.  More than one very experienced, well-known Python developer
in this discussion has told me that they thought 2to3 was the blessed way
to port their code, and it's no surprise that they think so, given that the
first technique  mentions
is still 2to3.
>>
>> 2to3 is certainly fine if you are porting to 3.x without looking to
>> keep your code 2.x-compatible. Until there's a better alternative, of
>> course.
>> So what we should do is better explain the choice (if you want to port
>> your code to 3.x, use 2to3; if you want to maintain dual-compatible
>> code, use six or something similar).
>>
>> Regards
>>
>> Antoine.
>>
>>
>> ___
>> Python-Dev mailing list
>> [email protected]
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/guido%40python.org
>
>
>
>
> --
> --Guido van Rossum (python.org/~guido)
>
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
>
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Language Summit Follow-Up

2014-05-30 Thread Nick Coghlan 
On 31 May 2014 02:47, "Chris Barker"  wrote:
> However, I also believe that when teaching it's better to introduce the
"right way" to do something up front, rather than a "beginners' way", then
later say, well, you really SHOULD do it this other way... So if we want
our students to use print as a function, we might a well start them off
that way. Saying that their very first easy program is:
>
> print("hello world")
>
> is fine -- they don't have to know or understand what a function call is
-- they simply copy the syntax. And frankly, we get to simple function
calls, VERY early in the program -- you can't really do anything without
them...

OK, that's a fair criticism of that particular argument, so I'll stop using
it. There are others, though:

* improve consistency between IPython's existing implied call support and
vanilla Python 3.5+
* retroactively make a lot of Python 2 examples also valid for Python 3.5+
* ease the migration to Python 3 for ad hoc utility scripts (which often
use print heavily)
* reduce the syntactic noise in migration patches (although large
applications tend to use print less than scripts do)
* largely eliminate one of the *human* barriers to migration from Python 2
(forgetting the parens for print at the interactive console and in ad hoc
scripts)

I already have too many other things on my todo list to work this up into a
full PEP, but the proof of concept (along with IPython's existing support)
shows there's no *technical* barrier to adding the feature. It's a question
of whether or not we *want* to blur the boundary between simple statements
and simple imperative function calls like that.

Cheers,
Nick.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Language Summit Follow-Up

2014-05-30 Thread Nick Coghlan 
On 31 May 2014 03:42, "Mark Roberts"  wrote:
>
> What I'd really like to see is a Python 2.8 that makes sufficient changes
to Python 2 that writing libraries which cross the boundary between 2 and 3
is relatively easy instead of a painful nightmarish chore.

That's what projects like python-future are for. Python 2.8 wouldn't help,
since most folks still target 2.6 for compatibility with stable Linux
platforms like RHEL, CentOS, Debian Stable & Ubuntu LTS.

This is a key point folks often miss in these discussions: even putting
Python 3 aside entirely, the migration of the overall ecosystem from Python
2.6 to Python *2.7* is not yet finished. RHEL 7 (which uses 2.7 as the
system Python) is currently only available as a release candidate, and the
same necessarily holds true for its downstream rebuilds like CentOS. We saw
this happen with Python 2.4 as well: for a lot of library developers, the
day CentOS 6 finally landed (with Python 2.6 as the system Python) was the
day they finally decided to drop support for Python 2.4.

It's that slow adoption cycle for new feature releases *within* the Python
2 series that means the effort that would be needed to create a Python 2.8
release is better put into tools and utilities that people can use *now*
(like PyPI backports of standard library modules, python-future and the
"pymigrate" utility Steve Dower suggested and Eric Snow has started working
on), tweaks to 2.7 itself (like PEP 466 and a possible future backport of
the ensurepip changes) and Python 3 changes that improve both Python 3
*and* the subset it shares with Python 2 (like the restoration of binary
interpolation support approved for 3.5).

Cheers,
Nick.

P.S. I've written more about adoption cycles for new Python versions at
http://python-notes.curiousefficiency.org/en/latest/python3/questions_and_answers.html#wouldn-t-a-python-2-8-release-help-ease-the-transition
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Updating turtle.py

2014-05-30 Thread Terry Reedy 
I have two areas of questions about updating turtle.py. First the module 
itself, then a turtle tracker issue versus code cleanup policies.


A. Unlike most stdlib modules, turtle is copyrighted and licensed by an 
individual.

'''
# turtle.py: a Tkinter based turtle graphics module for Python
# Version 1.1b - 4. 5. 2009
# Copyright (C) 2006 - 2010  Gregor Lingl
# email: [email protected]
'''
I am not sure what the copyright covers other than the exact text 
contributed, with updates, by Gregor. It certainly does not cover the 
API and whatever code he copied from the previous version (unless that 
was also by him, and I have no idea how much he copied when 
reimplementing). I don't think it should cover additions made by others 
either. Should there be another line to cover these?

'''
# Permission is granted to anyone to use this software for any purpose,
# including commercial applications, and to alter it and redistribute it
# freely, subject to the following restrictions:
#
# 1. The origin of this software must not be misrepresented; you must not
#claim that you wrote the original software. If you use this software
#in a product, an acknowledgment in the product documentation would be
#appreciated but is not required.
# 2. Altered source versions must be plainly marked as such, and must not be
#misrepresented as being the original software.
# 3. This notice may not be removed or altered from any source distribution.
'''
As to point 2, the source has been altered a bit (by others) but it is 
not marked as such. How should it be?

'''
_ver = "turtle 1.1b- - for Python 3.1   -  4. 5. 2009"
'''
Obsolete; delete or alter (how)?

When this replaced the previous turtle.py, it was considered 'owned' by 
Gregor in that changes had to go through him. However, he became 
inactive soon after and maintenance ceased. There has been only one 
turtle-specific code change that I know of (by Ned Daily, a month ago, 
for OSX. So is turtle.py unpatchable by anyone or fair game for anyone?


A particular example: Gregor added intermediate layers to isolate turtle 
from tkinter. (He had a plan to add other backends, but I believe he 
abandoned that.) If someone wanted to reduce the layering and make the 
code easier to understand and maintain, while speeding execution, would 
that be allowed now?



B. Lets assuming that turtle.py is, at least to some degree, fair game 
for fixes and enhancements. PSF Python PyLadies (Jessica Keller, Lynn 
Root) are participating in the 2014 GNOME Outreach Program for Women 
(OPW) https://wiki.python.org/moin/OPW/2014 . One of the projects 
(bottem of that page) is Graphical Python, in particular Turtle.


A few days ago, Jessica posted
http://bugs.python.org/issue21573 Clean up turtle.py code formatting
"Lib/turtle.py has some code formatting issues. Let's clean them up to 
make the module easier to read as interns start working on it this 
summer." She want to follow cleanup with code examination, fixes, and 
enhancements.


Responding today, I cautioned that clean-up only patches, such as she 
apparently would like to start with, are not in favor. But I cannot say 
how the policy applies to her proposal. Does the 'promise' of later work 
on the code make preliminary clean-up ok?


Since she only marked the issue for 3.5, I also cautioned that 3.5-only 
cleanups would make fixing bugs in other issues harder. Is the code 
clean-up policy the same for all branches?


Test? you ask?. There are apparently no unittests for turtle. On the 
other hand, turtledemo tests the overall function of the module and of 
many (most) of the top-level turtle functions.


--
Terry Jan Reedy

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Language Summit Follow-Up

2014-05-30 Thread Guido van Rossum 
On Fri, May 30, 2014 at 7:05 PM, Nick Coghlan  wrote:

> I already have too many other things on my todo list to work this up into
> a full PEP, but the proof of concept (along with IPython's existing
> support) shows there's no *technical* barrier to adding the feature.
>

That doesn't follow. A PoC and even IPython can ignore all kinds of
*technical* issues (e.g. giving code that's valid today a different
meaning). Please drop this idea or at least take it out of this thread and
focus on what *can* and *should* be done, in particular adding warnings
with good hints about what went wrong when Python 3 encounters what appears
to be a print statement.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Language Summit Follow-Up

2014-05-30 Thread Guido van Rossum 
Right. The point is that the current HOWTO gives information that is not
useful for most people who are tasked with a port.


On Fri, May 30, 2014 at 6:46 PM, Nick Coghlan  wrote:

>
> On 31 May 2014 08:42, "Guido van Rossum"  wrote:
> >
> > 2to3 is poorly named. With different fixers it is a fine tool for
> converting 2-only code to 2-and-3 straddling code. Even when using six, you
> need to do things like convert print statements to print() calls with
> future import, use 'as' in except clauses, and so on.
>
> Both modernize & futurize build on lib2to3 to do the heavy lifting - they
> don't reinvent that wheel, they just change which fixes are applied by
> default and add a few more of their own.
>
> However, even if going straight to Python 3, I suspect folks would still
> be better off doing something like:
>
> * futurize --stage1 (migrates to 2.6+, but adds no new runtime
> dependencies - the output should be fairly idiomatic Python 2.6/7 code)
> * 2to3 (wholesale migration to Python 3)
>
> The trick, though, is that the granularity of that approach is at the
> process level - the entire application must be converted at once. You also
> can't start your own migration until all your dependencies are available in
> Python 3.
>
> By contrast, migration via the common subset can be incremental and
> opportunistic:
>
> * the granularity of migration is individual modules, rather than entire
> processes, so you can make a low risk gradual transition, even without a
> comprehensive regression test suite
> * you initially stay on Python 2, so you can start whenever is convenient
> for you, rather than having to wait for all your dependencies
>
> Cheers,
> Nick.
>
> >
> >
> > On Fri, May 30, 2014 at 1:47 PM, Antoine Pitrou 
> wrote:
> >>
> >> On Wed, 28 May 2014 15:26:38 -0700
> >> Glyph Lefkowitz  wrote:
> >> > Backport 'yield from' to allow people to use Tulip and
> Tulip-compatible code, and to facilitate the development of Tulip-friendly
> libraries and a Tulip ecosystem.  A robust Tulip ecosystem requires the
> participation of people who are not yet using Python 3.
> >>
> >> I was wondering whether you were trolling or not on this one.
> >> From a quality assurance point of view, adding major features to a
> >> bugfix branch is extremely destructive, so I'm strongly -1 on it.
> >>
> >> > Get rid of 2to3. Particularly, of any discussion of using 2to3 in the
> documentation.  More than one very experienced, well-known Python developer
> in this discussion has told me that they thought 2to3 was the blessed way
> to port their code, and it's no surprise that they think so, given that the
> first technique  mentions
> is still 2to3.
> >>
> >> 2to3 is certainly fine if you are porting to 3.x without looking to
> >> keep your code 2.x-compatible. Until there's a better alternative, of
> >> course.
> >> So what we should do is better explain the choice (if you want to port
> >> your code to 3.x, use 2to3; if you want to maintain dual-compatible
> >> code, use six or something similar).
> >>
> >> Regards
> >>
> >> Antoine.
> >>
> >>
> >> ___
> >> Python-Dev mailing list
> >> [email protected]
> >> https://mail.python.org/mailman/listinfo/python-dev
> >> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
> >
> >
> >
> >
> > --
> > --Guido van Rossum (python.org/~guido)
> >
> > ___
> > Python-Dev mailing list
> > [email protected]
> > https://mail.python.org/mailman/listinfo/python-dev
> > Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
> >
>
>


-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com