[Python-Dev] Simple IDLE issues to commit before Python 2.7.4 release in two weeks on 4/6/2013

[Todd Rovito]

Python 2.7.4 release candidate was just announced and is ready for testing here:
http://python.org/download/releases/2.7.4/

Now the clock is ticking and we have two weeks to get IDLE issues
pushed into CPython before the final release of 2.7.4.  Below is my
list of low risk issues that would be great to get pushed into
CPython.  I hope this email will encourage CPython Core Developers to
make the commits or tell us what we can do, like more testing or
better documentation, to get these issues cleaned up and committed
before 2.7.4 ships.  PEP-434 is still being discussed, I asked PEP
authors to post latest version on 3/24, but I think most folks agree
with the principle.  IDLE might have more issues that could be fixed
easily so feel free to add to the list.  Thanks for everybody’s hard
work to make IDLE better!
http://bugs.python.org/issue7136 Idle File Menu Option Improvement
http://bugs.python.org/issue17390 display python version on idle title bar
http://bugs.python.org/issue17511 Idle find function closes after each
find operation
http://bugs.python.org/issue6699 IDLE: Warn user about overwriting a
file that has a newer version on filesystem
http://bugs.python.org/issue10747 Include version info in Windows
shortcuts the issue is for 3.x but perhaps simple to implement for
2.7?

The issue below has been talked about in the recent past on idle-dev
(http://mail.python.org/pipermail/idle-dev/2013-March/003228.html) it
will take some work to get committed because of the deletion of the
Option menu on the Mac.  But even if it gets committed then is
disabled for the Mac with a simple sys.platform it would be a huge
victory for IDLE in my mind.
http://bugs.python.org/issue2704 IDLE: Patch to make PyShell behave
more like a Terminal interface
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Simple IDLE issues to commit before Python 2.7.4 release in two weeks on 4/6/2013

[Benjamin Peterson]

2013/3/25 Todd Rovito :
> Python 2.7.4 release candidate was just announced and is ready for testing 
> here:
> http://python.org/download/releases/2.7.4/
>
> Now the clock is ticking and we have two weeks to get IDLE issues
> pushed into CPython before the final release of 2.7.4.

I'm afraid the ship has sailed on that. After a bugfix release
candidate, I only take patches that fix regressions from earlier
releases of the same series. (The goal is to not make any changes
between the release candidate and final release.) Assuming PEP 343
becomes policy, IDLE changes can land for 2.7.5, which will be in
approximately 6 months.


-- 
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Can we triple quoted string as a comment?

[Victor Stinner]

Hi,

I just realized that the Python peephole optimizer removes useless
instructions like numbers and strings between other instructions,
without raising an error nor emiting an error. Example:

$ python -Wd -c 'print "Hello"; "World"'
Hello

As part of my astoptimizer project, I wrote a function to detect such
useless instructions which emit a warning. I opened the following
issue to report what I found:
http://bugs.python.org/issue17516

Different modules use long strings as comments. What is the "official"
policy about such strings? Should we use strings or comments?

(IMO a comment should be used instead.)

Victor
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Can we triple quoted string as a comment?

[Gregory P. Smith]

On Mon, Mar 25, 2013 at 2:16 PM, Victor Stinner wrote:

> Hi,
>
> I just realized that the Python peephole optimizer removes useless
> instructions like numbers and strings between other instructions,
> without raising an error nor emiting an error. Example:
>
> $ python -Wd -c 'print "Hello"; "World"'
> Hello
>
> As part of my astoptimizer project, I wrote a function to detect such
> useless instructions which emit a warning. I opened the following
> issue to report what I found:
> http://bugs.python.org/issue17516
>
> Different modules use long strings as comments. What is the "official"
> policy about such strings? Should we use strings or comments?
>

Comments.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Simple IDLE issues to commit before Python 2.7.4 release in two weeks on 4/6/2013

[Ned Deily]

In article 
,
 Todd Rovito  wrote:
> Now the clock is ticking and we have two weeks to get IDLE issues
> pushed into CPython before the final release of 2.7.4.  Below is my
> list of low risk issues that would be great to get pushed into
> CPython.  I hope this email will encourage CPython Core Developers to
> make the commits or tell us what we can do, like more testing or
> better documentation, to get these issues cleaned up and committed
> before 2.7.4 ships.

Todd,

Thanks for your suggestions and work to improve IDLE and Python, in 
general.  There has been a lot of discussions recently, including your 
PEP proposal.  I have not commented on the discussions yet, though I 
plan to in the next few days.  Unfortunately, it comes at one of the 
busiest times for those of us working on releases.  Not only is the 
2.7.4 release in preparation but 3.2.4rc1 and 3.3.0.rc1 are about to be 
announced, all on similar schedules.  So just a few comments from my 
release team perspective.  No doubt, others may have other opinions.

Bugfix releases, like these three, follow an abbreviated version of the 
full feature release process, outlined in the developer's guide:

   http://docs.python.org/devguide/devcycle.html#stages

For bugfix releases, we typically skip alphas and betas and go right to 
the release candidate stage, under the assumption that the criteria used 
for commits added to bugfix releases are designed to avoid incompatible 
changes and new features, unless explicitly approved for good reasons.  
That means that a release candidate is meant to be just that: the final 
set of bits that will be released.   All of us involved in software 
development have our own war stories of how some little last-minute 
change caused some unexpected breakage.  So the normal expectation is 
that, if any change is accepted and cherry-picked  after a release 
candidate has been published, a new RC cycle will need to happen unless 
the release manager decides the change is trivial enough that the risk 
is truly minimal, e.g. something like an obvious typo or a doc change.   
Certainly the changes proposed here would not normally fit those 
criteria.

Also, before the changes could be considered to be cherry-picked for a 
release, they need to be applied to the branches first and given some 
amount of testing, preferably on all of the major platforms where we 
support IDLE: X11, Windows, OS X.  So that's what needs to happen next.  
There are various developers who have been applying IDLE fixes and now 
Roger is able to do so as well (yay!).  Once they are in, then the 
question of release becomes relevant.  There are a couple of possible 
scenarios I can see.   1. It's possible that problems will show up in 
one or more of the current RCs, necessitating another RC cycle, at which 
time the release manager(s) *might* be amenable to cherrypicking one or 
more fixes from the current branches.  2.  It's also possible (probable, 
I hope) that 2.7.5 and/or 3.3.2 will follow relatively quickly after 
2.7.4 and 3.3.1.  (3.2.4 is expected to be the final 3.2.x bugfix 
release before it enters security-only fix mode.)  The period since the 
last maint releases for 2.7.x and 3.2.x was unusually long, for various 
good reasons, so there are about a year's worth of fixes going out for 
them this time, thereby raising the likelihood that new problems will be 
found requiring a fix in a new bugfix release.  Plus there are some 
security issues that need a final resolution in a release.  So, I'm 
hopeful that we won't have to wait nearly as long to see 2.7.5 after 
2.7.4.  There's not as long a gap since 3.3.0 but still somewhat long 
for a first bugfix release.

BTW, there is a fair amount of activity that goes on somewhat behind the 
scenes with getting releases out-the-door.  There a number of release 
artifacts that need to be produced and tested, webpages that need to be 
updated, announcements sent, etc.  For example, for OS X, we normally 
release two variants of installers for each beta, rc, and final release.  
Between the two variants, we support 13 different 
architecture/os-release combinations (only 11 for 3.3.x).  That means, 
at the moment, we have 37 different combinations we could test 
(including those for 2.7.4rc1, 3.2.4rc1, and 3.3.1rc1).  I don't 
personally test every one of them but I do run the Python tests on a 
representative sample (various OS levels vs. ppc/Intel-32/Intel-64) of 
configurations, including at least very minimal manual tests of IDLE to 
cover things like different versions of Tcl/Tk we support on OS X and 
current fixes like the recent infamous preferences panel crash.  Then 
there's the time required to investigate and writeup test failures, and 
decide on a fix strategy (e.g. is it a release blocker?).  Similar 
things happen for the WIndows installers and for the main source 
packages.  All of these things are part of what goes in to having a good 
batteries-included experience for our users

Re: [Python-Dev] Simple IDLE issues to commit before Python 2.7.4 release in two weeks on 4/6/2013

[Glyph]

On Mar 25, 2013, at 1:40 PM, Benjamin Peterson  wrote:

> ... Assuming PEP 343 becomes policy ...

Are you sure you got this PEP number right?  The 'with' statement?



-glyph___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Simple IDLE issues to commit before Python 2.7.4 release in two weeks on 4/6/2013

[Benjamin Peterson]

2013/3/25 Glyph :
>
> On Mar 25, 2013, at 1:40 PM, Benjamin Peterson  wrote:
>
> ... Assuming PEP 343 becomes policy ...
>
>
> Are you sure you got this PEP number right?  The 'with' statement?

Sorry, I meant PEP 434.



-- 
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Simple IDLE issues to commit before Python 2.7.4 release in two weeks on 4/6/2013

[Maciej Fijalkowski]

On Mon, Mar 25, 2013 at 3:57 PM, Glyph  wrote:
>
> On Mar 25, 2013, at 1:40 PM, Benjamin Peterson  wrote:
>
> ... Assuming PEP 343 becomes policy ...
>
>
> Are you sure you got this PEP number right?  The 'with' statement?
>
> 
>

Don't worry even google confuses the two :)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Simple IDLE issues to commit before Python 2.7.4 release in two weeks on 4/6/2013

[Todd Rovito]

On Mon, Mar 25, 2013 at 4:40 PM, Benjamin Peterson  wrote:
> I'm afraid the ship has sailed on that. After a bugfix release
> candidate, I only take patches that fix regressions from earlier
> releases of the same series. (The goal is to not make any changes
> between the release candidate and final release.) Assuming PEP 343
> becomes policy, IDLE changes can land for 2.7.5, which will be in
> approximately 6 months.
Benjamin,
   No problem we can wait 6 months.  I should of read the dev guide
section about Python releases before I sent the email.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Can we triple quoted string as a comment?

[Raymond Hettinger]

On Mar 25, 2013, at 2:16 PM, Victor Stinner  wrote:

> Hi,
> 
> I just realized that the Python peephole optimizer removes useless
> instructions like numbers and strings between other instructions,
> without raising an error nor emiting an error. Example:
> 
> $ python -Wd -c 'print "Hello"; "World"'
> Hello

IIRC, this happens upstream from the peephole optimizer
and has been a part of Python for a long time.

You can also "comment-out" code with "if 0:"

>>> def f(x):
if 0:
print x
return x+1

>>> from dis import dis
>>> dis(f)
  4   0 LOAD_FAST0 (x)
  3 LOAD_CONST   1 (1)
  6 BINARY_ADD  
  7 RETURN_VALUE 

> 
> As part of my astoptimizer project, I wrote a function to detect such
> useless instructions which emit a warning. I opened the following
> issue to report what I found:
> http://bugs.python.org/issue17516

Make sure it is a warning you can turn-off.

I've seen code in many organizations that use multi-line
strings to "turn-off" a section of code but not actually remove the code
from the source.


> 
> Different modules use long strings as comments. What is the "official"
> policy about such strings? Should we use strings or comments?
> 
> (IMO a comment should be used instead.)

The module authors typically make their own decisions
with respect to readability and ease of commenting.

If you're editing with Emacs, it is really easy to reflow paragraphs
and to insert or remove multiline comments each prefixed with #.
But with other editors, it can be a PITA and a multiline string is
the easiest to maintain and works well when cutting-and-pasting
the comments from somewhere else.

I worry that because you just discovered this feature, the initial
reaction is that is a horribly wrong thing to do and should be
"fixed" everywhere.

Instead, it would be better to live-and-let live.
No need for wholesale code changes or imposition
"you must do it the way I do it" policies.


my-two-cents,


Raymond___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Simple IDLE issues to commit before Python 2.7.4 release in two weeks on 4/6/2013

[Todd Rovito]

On Mon, Mar 25, 2013 at 5:31 PM, Ned Deily  wrote:
> Todd,
>
> Thanks for your suggestions and work to improve IDLE and Python, in
> general.  There has been a lot of discussions recently, including your
> PEP proposal.  I have not commented on the discussions yet, though I
> plan to in the next few days.
No problem I enjoy working on Python  I look forward to reading
your comments.

> Unfortunately, it comes at one of the
> busiest times for those of us working on releases.  Not only is the
> 2.7.4 release in preparation but 3.2.4rc1 and 3.3.0.rc1 are about to be
> announced, all on similar schedules.  So just a few comments from my
> release team perspective.  No doubt, others may have other opinions.
>
> Bugfix releases, like these three, follow an abbreviated version of the
> full feature release process, outlined in the developer's guide:
>
>http://docs.python.org/devguide/devcycle.html#stages
Thanks for the reference I will read it again this time more
carefully.  Before I sent the email I should have reviewed it so
perhaps I jumped the gun a little.

> For bugfix releases, we typically skip alphas and betas and go right to
> the release candidate stage, under the assumption that the criteria used
> for commits added to bugfix releases are designed to avoid incompatible
> changes and new features, unless explicitly approved for good reasons.
> That means that a release candidate is meant to be just that: the final
> set of bits that will be released.   All of us involved in software
> development have our own war stories of how some little last-minute
> change caused some unexpected breakage.  So the normal expectation is
> that, if any change is accepted and cherry-picked  after a release
> candidate has been published, a new RC cycle will need to happen unless
> the release manager decides the change is trivial enough that the risk
> is truly minimal, e.g. something like an obvious typo or a doc change.
> Certainly the changes proposed here would not normally fit those
> criteria.
Thanks for taking the time to explain that to mefor sure I don't
mean to rush the process.  I do know that the Python team releases a
high quality product and why change a good thing.

> Also, before the changes could be considered to be cherry-picked for a
> release, they need to be applied to the branches first and given some
> amount of testing, preferably on all of the major platforms where we
> support IDLE: X11, Windows, OS X.  So that's what needs to happen next.
I agree 100% so we just need to get these simple issues committed and
done.  It seems like now is a bad time so I can wait patiently, I
don't want to be a pest but it drives me nuts that some of these
issues have been fixed and they go uncommitted.  More than anything I
want the Python Core Developers to know that work has happened on IDLE
and many times the patches simply don't get committed.  I admit there
are various reasons some of these IDLE issues don't get resolved but
these first four are a slam dunk.  Please Python Core Developers don't
take offense I know everybody is busy moving the language forward
which is super important, I want to gently tickle your belly buttons
as a reminder only.

> There are various developers who have been applying IDLE fixes and now
> Roger is able to do so as well (yay!).  Once they are in, then the
> question of release becomes relevant.
Giving Roger commit rights will speed things up no doubt about that
but he is learning the ropes and I was hoping to get these four simple
issues committed and done with before 2.7.4 comes out.  Knowing now
that we have 6 months (instead of two weeks) relaxes me a little.

> There are a couple of possible
> scenarios I can see.   1. It's possible that problems will show up in
> one or more of the current RCs, necessitating another RC cycle, at which
> time the release manager(s) *might* be amenable to cherrypicking one or
> more fixes from the current branches.  2.  It's also possible (probable,
> I hope) that 2.7.5 and/or 3.3.2 will follow relatively quickly after
> 2.7.4 and 3.3.1.  (3.2.4 is expected to be the final 3.2.x bugfix
> release before it enters security-only fix mode.)  The period since the
> last maint releases for 2.7.x and 3.2.x was unusually long, for various
> good reasons, so there are about a year's worth of fixes going out for
> them this time, thereby raising the likelihood that new problems will be
> found requiring a fix in a new bugfix release.  Plus there are some
> security issues that need a final resolution in a release.  So, I'm
> hopeful that we won't have to wait nearly as long to see 2.7.5 after
> 2.7.4.  There's not as long a gap since 3.3.0 but still somewhat long
> for a first bugfix release.
All this is good information and makes me feel even better about
waiting a few months to get these four issues and possibly more IDLE
issues fixed before the next release.


> BTW, there is a fair amount of activity that goes on somewhat behind th

Re: [Python-Dev] Simple IDLE issues to commit before Python 2.7.4 release in two weeks on 4/6/2013

[Stephen J. Turnbull]

Todd Rovito writes:

 > All this is good information and makes me feel even better about
 > waiting a few months to get these four issues and possibly more IDLE
 > issues fixed before the next release.

+1 for more issues fixed in the next release! :-)

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] IDLE in the stdlib

[Terry Reedy]

On 3/22/2013 2:51 PM, francis wrote:


~$ python2.7 -m idlelib
/usr/bin/python2.7: No module named idlelib.__main__; 'idlelib' is a
package and cannot be directly executed

Same with python3...


C:\Programs>python33\python.exe -m idlelib

brings up IDLE on Windows. 2.7 and 3.2 do not work as above but require 
'idlelib.idle' instead of just 'idlelib'.


C:\Programs>python32\python.exe -m idlelib.idle

C:\Programs>python27\python.exe -m idlelib.idle

I have no idea if the change is to '-m' processing or to idlelib. If the 
latter, it is an example of a patch that might have been harmlessly 
backported with PEP434 accepted.


--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Simple IDLE issues to commit before Python 2.7.4 release in two weeks on 4/6/2013

[Terry Reedy]

On 3/25/2013 3:30 PM, Todd Rovito wrote:


http://bugs.python.org/issue7136 Idle File Menu Option Improvement
http://bugs.python.org/issue17390 display python version on idle title bar
http://bugs.python.org/issue17511 Idle find function closes after each
find operation
http://bugs.python.org/issue6699 IDLE: Warn user about overwriting a
file that has a newer version on filesystem
http://bugs.python.org/issue10747 Include version info in Windows
shortcuts the issue is for 3.x but perhaps simple to implement for
2.7?



http://bugs.python.org/issue2704 IDLE: Patch to make PyShell behave
more like a Terminal interface


I am waiting for 434 or an alternative to be accepted before pushing any 
IDLE patch. I have no interest in bikeshedding a somewhat meaningless, 
for IDLE, distinction between behavior and enhancement, nor in being 
asked to revert a patch that I tested on multiple versions.


However, I might use your list to select patches for testing on Windows.

--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] [RELEASED] Python 3.2.4 rc 1 and Python 3.3.1 rc 1

[Georg Brandl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On behalf of the Python development team, I am pleased to announce the
first release candidates of Python 3.2.4 and 3.3.1.

Python 3.2.4 will be the last regular maintenance release for the Python 3.2
series, while Python 3.3.1 is the first maintenance release for the 3.3
series.  Both releases include hundreds of bugfixes.

There has recently been a lot of discussion about XML-based denial of service
attacks. Specifically, certain XML files can cause XML parsers, including ones
in the Python stdlib, to consume gigabytes of RAM and swamp the CPU. These
releases do not include any changes in Python XML code to address these issues.
Interested parties should examine the defusedxml package on PyPI:
https://pypi.python.org/pypi/defusedxml

These are testing releases: Please consider trying them with your code
and reporting any bugs you may notice to:

http://bugs.python.org/

To download Python 3.2.4 or Python 3.3.1, visit:

http://www.python.org/download/releases/3.2.4/  or
http://www.python.org/download/releases/3.3.1/

respectively.


Enjoy!

- -- 
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and all contributors)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAlFRRIoACgkQN9GcIYhpnLD6jACgnzYdYRKZ4kwkKeN3zSLSZ3Zr
M/IAn17vlpxI3a3xk+i/ODOrCkMnRZro
=B5sA
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com