subject:"Re\: Should non\-security 2.7 bugs be fixed\?"

Mark Lawrence breamore...@yahoo.co.uk writes:
 ...
 So I most humbly suggest, as I may have hinted at once or twice
 earlier in this thread, that people either put up or shut up.

In another of your contributions to this thread, you spoke of another
alternative: do a bit of begging. That is what some of us are doing.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?

Ian Kelly ian.g.ke...@gmail.com writes:

 On Sun, Jul 19, 2015 at 10:10 AM, Cecil Westerhof ce...@decebal.nl wrote:
 On Sunday 19 Jul 2015 15:42 CEST, Mark Lawrence wrote:

 On 19/07/2015 03:13, Terry Reedy wrote:
 On 7/18/2015 7:50 PM, Devin Jeanpierre wrote:
 to 2.7, surely bug fixes are also allowed?

 Of course, allowed.  But should they be made, and if so, by who?

 The people who want the fixes.

 Babies want clean diapers. So babies have to change diapers
 themselves?

 Poor analogy. Babies need others to change their diapers for them
 because they're not capable of doing it for themselves.

I believe Cecil was aware of this and wanted to stress:
not everyone who needs a fix is also able to backport a corresponding
patch.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?

Mark Lawrence breamore...@yahoo.co.uk writes:

 On 19/07/2015 18:14, Cecil Westerhof wrote:
 On Sunday 19 Jul 2015 18:38 CEST, Mark Lawrence wrote:
 ...
 You think so? I think that a lot of people who are using 2.7 would
 like to have the fixes. They know how to use Python, but they would
 not now how to implement a patch. That is why I made this comment.


 I don't think so, I know.  If they want the patches that badly and
 can't do it themselves they'll have to grin and bear it, or do a bit
 of begging, or pay somebody to do it for them.

Well, there might be budget constraints and the difficulty
to find someone capable of doing a backport.

We are doing here some form of begging. Thus, we are in line with
your recommendations ;-)

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?

Mark Lawrence breamore...@yahoo.co.uk writes:

 On 19/07/2015 17:10, Cecil Westerhof wrote:
 On Sunday 19 Jul 2015 15:42 CEST, Mark Lawrence wrote:
 ...
 Babies want clean diapers. So babies have to change diapers
 themselves?


 That has to be the worst analogy I've ever read.  We are discussing
 backporting working patches, *NOT* having to go through the whole
 shooting match from scratch.

Nevertheless, the task is (usually) far from trivial.
Beside the pure functional aspect, you need at least also address
testing againt interference with other features, i.e. you need
detailed knowledge about Python's test suite and its setup.
This obviously is non trivial - as I have seen fixes break other things.

If C code is envolved, you need also understand Python's build environment
-- another huge requirement of specific knowledge. Especially, because
the Python build process must function on many platforms and typical
users only use a single one.

The first point causes me prefer external packages - where I (not
a community) decide about the extent of testing. It is also easy to
remove an external package should it really make problems.

The second point causes me to prefer working around problems envolving
C code rather than fixing it.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?

2015-07-20 Thread Terry Reedy


On 7/19/2015 9:20 PM, Devin Jeanpierre wrote:


Search your logs for https://bugs.python.org/issue17094
http://bugs.python.org/issue5315

I was most frustrated by the first case --

 the patch was (informally) rejected

By 'the patch', I presume you mean current-frames-cleanup.patch
by Stefan Ring, who said it is certainly not the most complete 
solution, but it solves my problem.. It was reviewed a month later by a 
core dev, who said it had two defects.  Do you expect us to apply 
defective patches?



in favor of the right fix,


right is your word. Natali simply uploaded an alternate patch that did 
not have the defects cited.  It went through 4 versions, two by Pitrou, 
before the commit and close 2 months later, with the comment Hopefully 
there aren't any applications relying on the previous behaviour.


and the right fix was (informally) rejected because it changed behavior,

The bugfix was rejected *for both 2.7 and 3.3* in msg186011.  The 
rejection therefore does not indicate animus against 2.7 versus 3.x. The 
reason is that it did more than just fix the bug. When this is the case, 
we only apply to the upcoming release.  If we broke working code as a 
side-effect, as opposed to a direct effect, of a bugfix, many people 
would be frustrated. See some of the other comments in this thread.


Two years later, last May, you proposed and uploaded a patch with what 
looks to be a new and different approach.  It has been ignored.  In the 
absence of a core dev focused on 2.7, I expect that this will continue. 
Too bad you did not upload it in Feb 2013, before the review and fix 
started.


 and http://bugs.python.org/issue5315

Another fairly obscure issue for most of us. Five years ago, this was 
turned into a doc issue, but no patch was ever submitted for either 2.x 
or 3.x.  Again, no particular prejudice against 2.x.


In May, you posted a bugfix which so far has been ignored.  Not too 
surprising.  I submitted a ping and updated the versions.  If anyone 
responds, you might be asked for a patch against 3.4 or 3.5.


--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?

Rick Johnson rantingrickjohn...@gmail.com writes:

 On Sunday, July 19, 2015 at 1:44:25 PM UTC-5, bream...@gmail.com wrote:
 No, it's simply that nobody can force volunteers to back
 port something when they're just not interested in doing
 the work, for whatever reason.  Hence my statement above,
 of which you have focused on the last eight words.

 Well i argue that the free labor *WOULD* exists *IF* the
 patching mechanism were more inclusive and intuitive.

Thinking of myself, I am not sure. Ensuring the quality of
a distribution goes far beyond a single bug fix. While I usually
are ready to share a bug fix I have found, I am reluctant to get
involved in the complete quality ensurance process (such as
the test suite, review process, style guides, ...). This would
require far more time than that for analysing and fixing the initial
problem. Thus, from my point of view, it calls for a division of labor --
where quality ensurance experts do the integration of my patch/backport.


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?

Rick Johnson rantingrickjohn...@gmail.com writes:

 On Sunday, July 19, 2015 at 12:54:34 AM UTC-5, dieter wrote:
 From my point of view: if you want help with fixing bugs,
 you must ensure that there is a high probability that
 those contributions really find their way into the main
 development lines. As I understand from other messages in
 this thread, this is also a problem with Python bug
 fixing.

 (Not sure who said this, so my apologies if the attribution
 is incorrect)
 
 Bug fixing is not something most programmers find enjoyable,
 at least not for long durations. I prefer to spend my time
 solving real world problems, and designing intuitive APIs,
 this is what brings me joy. 

This was me.

And I am like you. I do not hunt bugs I find in a bug tracker
but only bugs I get hit in real world problems.
But once hit, I usually find a solution (or work around)
and like to share it with others who might get hit in the future.
That's why I take the time to file bug reports (often with patches).

But when those bug reports and patches seem to be ignored by
the core development team - I look for other means, such as
external packages.


 Heck, there have been many times that i purposefully re-
 invented the wheel simply because solving the problem is
 much easier (and more enjoyable) than trying to understand
 another programmer's atrocious spaghetti code. Therefor, we
 should not be surprised that the bug list is so understaffed
 and lacks vigor.

In my experience (with other open source projects), I think
almost none of my patches was ever taken over without modifications.
In my view, the changes were usually of a cosmetic nature.
For me, this is fine - as long as the problem gets fixed.

 ...
 What is becoming apparent to me though, is that most of the
 complaints i had voiced (years ago) about the exclusive
 attitudes, horrible interface, and the burdensome workflow
 of submitting patches is contributing to the lack of
 interest in this process - and it seems i am not alone!

 I can remember twice getting excited about helping out, to
 only quickly become frustrated with the politics and
 interface. Why should i have to fight just to volunteer?

Experience like this (in another project) causes me to
be very reluctant to become a core contributor (in the sense
of actively fixing things in the core). You need a lot of knowledge
(coding conventions, test setup, change workflow, ...) whichs
goes far beyond the functionality of the fix -- and you
must be resilient, patient and maybe even fighting to get the work
accepted.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?

2015-07-20 Thread Devin Jeanpierre

I think you're missing the line where I said all the relevant
conversation happened in IRC, and that you should refer to logs.

On Sun, Jul 19, 2015 at 11:25 PM, Terry Reedy tjre...@udel.edu wrote:
 On 7/19/2015 9:20 PM, Devin Jeanpierre wrote:

 Search your logs for https://bugs.python.org/issue17094
 http://bugs.python.org/issue5315

 I was most frustrated by the first case --

 the patch was (informally) rejected

 By 'the patch', I presume you mean current-frames-cleanup.patch
 by Stefan Ring, who said it is certainly not the most complete solution,
 but it solves my problem.. It was reviewed a month later by a core dev, who
 said it had two defects.  Do you expect us to apply defective patches?

No, I meant my patch. It was discussed in IRC, and I gave the search
term to grep for. (The issue URL.)

 in favor of the right fix,


 right is your word. Natali simply uploaded an alternate patch that did not
 have the defects cited.  It went through 4 versions, two by Pitrou, before
 the commit and close 2 months later, with the comment Hopefully there
 aren't any applications relying on the previous behaviour.

No, right is the word used by members of #python-dev, referrig to
Antoine's fix.

 Two years later, last May, you proposed and uploaded a patch with what looks
 to be a new and different approach.  It has been ignored.  In the absence of
 a core dev focused on 2.7, I expect that this will continue. Too bad you did
 not upload it in Feb 2013, before the review and fix started.

I'm not sure what you're implying here. It couldn't be helped.

 and http://bugs.python.org/issue5315

 Another fairly obscure issue for most of us. Five years ago, this was turned
 into a doc issue, but no patch was ever submitted for either 2.x or 3.x.
 Again, no particular prejudice against 2.x.

 In May, you posted a bugfix which so far has been ignored.  Not too
 surprising.  I submitted a ping and updated the versions.  If anyone
 responds, you might be asked for a patch against 3.4 or 3.5.

Again, the prejudice was expressed in IRC. It was ignored because you
can just use asyncio in 3.x, and because the bug was old.

-- Devin
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?

2015-07-20 Thread Mark Lawrence

On 20/07/2015 03:16, Rustom Mody wrote:

On Monday, July 20, 2015 at 7:16:50 AM UTC+5:30, Mark Lawrence wrote:

On 20/07/2015 02:20, Devin Jeanpierre wrote:

I don't like how this is being redirected to surely you
misunderstood or I don't believe you. The fact that some core devs
are hostile to 2.x development is really bleedingly obvious, you
shouldn't need quotes or context thrown at you. The rhetoric almost
always shies _just_ short of ceasing bugfixes (until 2020, when that
abruptly becomes a cracking good idea). e.g. in 2.7 is here until
2020, please don't call it a waste.

A couple of things.

First some core devs are hostile, actually some have stated that
they're simply not interested in 2.7 and will not work on it.

Second how has the thread got here, as it was originally asking about
back porting bug fixes from 3.x to 2.7? Further it said:-

quote
If the vast majority of Python programmers are focused on 2.7, why are
volunteers to help fix 2.7 bugs so scarce?
/quote

So I most humbly suggest, as I may have hinted at once or twice earlier
in this thread, that people either put up or shut up.

I just ran the following command
$ hg log --template {author|person}\n | sort | uniq -c | sort -nr

as giving all the committers to python in sorted order.
I get the list below.
Dont see any Mark Lawrence there
Of course I dont know hg at all well... Just picked up the above command from
http://stackoverflow.com/questions/6126678/how-to-list-commiters-sorted-by-number-of-commits-commit-count

So... May I humbly ask where are your precious commits??

Thank you for showing your complete ignorance as to how Python works.

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

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?

On Sunday, July 19, 2015 at 9:17:11 PM UTC-5, Rustom Mody wrote:


 List of python committers:
 -
  11081 Guido van Rossum
 [snip: long list]

Thanks for posting this list of names. I had put in a pyFOIA
request for this data a few years ago, but to my surprise, was
flat out denied. I'm not sure how exhaustive this list may be,
but publicly displaying the commit hierarchy within the Python
community is very import for those who may want to get involved.

[Talking to Mark Lawrence, Rustom said:]
 So... May I humbly ask where are your precious commits??

Thanks for putting Mark in his place. He has been brow
beating folks on this list (myself included) for years, and
i'll bet he now feels as tiny as D'Aprano did -- when GvR
scolded him for disrespecting a Noob on Python-ideas.

  Yeah, i was watching! 

  I'M *ALWAYS* WATCHING!

  ಠ_ಠ

Now that Mark's lack of commit cred has been exposed, we can
safely ignore his hollow and hypocritical bullying. And now
that he has been de-fanged, he will be forced to seek employment
elsewhere. Hmm, my suggestion is that he market himself as an
on-call peanut butter removal service. A venture that will
no doubt be successful, seeing that he has two heads up on
his competition! 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?

2015-07-20 Thread Rustom Mody

On Tuesday, July 21, 2015 at 8:34:30 AM UTC+5:30, Rick Johnson wrote:
 On Sunday, July 19, 2015 at 9:17:11 PM UTC-5, Rustom Mody wrote:
 
 
  List of python committers:
  -
   11081 Guido van Rossum
  [snip: long list]
 
 Thanks for posting this list of names. I had put in a pyFOIA
 request for this data a few years ago, but to my surprise, was
 flat out denied. I'm not sure how exhaustive this list may be,
 but publicly displaying the commit hierarchy within the Python
 community is very import for those who may want to get involved.
 
 [Talking to Mark Lawrence, Rustom said:]
  So... May I humbly ask where are your precious commits??
 
 Thanks for putting Mark in his place. He has been brow
 beating folks on this list (myself included) for years, and
 i'll bet he now feels as tiny as D'Aprano did -- when GvR
 scolded him for disrespecting a Noob on Python-ideas.
 
   Yeah, i was watching! 
 
   I'M *ALWAYS* WATCHING!
 
   ಠ_ಠ
 
 Now that Mark's lack of commit cred has been exposed, we can
 safely ignore his hollow and hypocritical bullying. And now
 that he has been de-fanged, he will be forced to seek employment
 elsewhere. Hmm, my suggestion is that he market himself as an
 on-call peanut butter removal service. A venture that will
 no doubt be successful, seeing that he has two heads up on
 his competition!

Hey Rick!
Lets have a useful discussion
And cut the rhetoric
Please

[Chris already showed that this list is inaccurate -- probably related 
to hg not having sighoff distinct from commit like git]
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?

2015-07-20 Thread Chris Angelico

On Tue, Jul 21, 2015 at 1:15 PM, Rustom Mody rustompm...@gmail.com wrote:
 [Chris already showed that this list is inaccurate -- probably related
 to hg not having sighoff distinct from commit like git]

It's also the manner of workflow. If you want to accept patches and
have them acknowledged to their original authors, the patches need to
carry metadata identifying the authors. I went to the tracker and hit
Random Issue and got one with an attached file as the first hit:

http://bugs.python.org/issue12982
http://bugs.python.org/file26008/issue12982.diff

Repeated the exercise and won again:

http://bugs.python.org/issue4733
http://bugs.python.org/file12437/urlopen_text.diff

Notice how the patch files start straight in with content. There's no
authorship information retained.

By comparison, a patch created with 'git format-patch' and applied
with 'git am' starts with RFC 822 headers, provides a commit message,
and generally is intended as a way of transmitting a *commit*, rather
than simply some changes. I'm not overly familiar with Mercurial
workflows, but I think 'hg export' and 'hg import' give the same sort
of information; I tried on CPython and got this:

# HG changeset patch
# User Robert Collins rbtcoll...@hp.com
# Date 1436838700 -43200
#  Tue Jul 14 13:51:40 2015 +1200
# Branch 3.5
# Node ID 7021d46c490e8d9d3422737c69980dc1602f90db
# Parent  0127b0cad5ecb83c39ce58a4be27bf6d43a78d91
Issue #23661: unittest.mock side_effects can now be exceptions again.

This was a regression vs Python 3.4. Patch from Ignacio Rossi

diff -r 0127b0cad5ec -r 7021d46c490e Lib/unittest/mock.py
--- a/Lib/unittest/mock.py  Sat Jul 11 16:33:39 2015 -0700
+++ b/Lib/unittest/mock.py  Tue Jul 14 13:51:40 2015 +1200
@@ -506,7 +506,8 @@
 if delegated is None:

(chomp actual details)

Whether it's possible to have authorship retained or not, though, a
lot of patches can logically be credited to multiple people. Whose
name goes on it? With the CPython workflow, it's always the core
committer who applied it, nobody else. (That's consistent, at least.)
So the names in the log are of the people who have write access to the
repo, and nobody else.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?]

2015-07-20 Thread Rustom Mody

On Sunday, July 19, 2015 at 10:15:37 AM UTC+5:30, Steven D'Aprano wrote:
  JFTR: My kids (um... students) have just managed to add devanagari
  numerals to python.
  ie we can now do
  
  १ + २
  3
 
 That is actually quite awesome, and I would support a new feature that set
 the numeric characters to a particular script, e.g. Latin, Arabic,
 Devanagari, whatever, and printed them in that same script. It seems
 unfortunate that १ + २ prints as 3 rather than ३.

BTW my boys have just mailed me their latest:

 九.九九

9.99

Can some unicode/Chinese literate person inform me whether
that ideograph is equivalent to roman '9' or roman 'nine'?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?]

2015-07-20 Thread Chris Angelico

On Tue, Jul 21, 2015 at 1:30 PM, Rustom Mody rustompm...@gmail.com wrote:
 BTW my boys have just mailed me their latest:

 九.九九

 9.99

 Can some unicode/Chinese literate person inform me whether
 that ideograph is equivalent to roman '9' or roman 'nine'?

I'm not Chinese-literate, but I know how to dig up info from the
Unicode side of things.

'\u4e5d' CJK UNIFIED IDEOGRAPH-4E5D

Thanks, very helpful.

Perhaps slightly more useful:

https://en.wiktionary.org/wiki/%E4%B9%9D

But it still doesn't disambiguate digit vs word.

Playing around with Google Translate suggests that it functions mostly
like a digit; 九九 means Ninety-nine and 九八 means Ninety-eight. But
I'll leave further confirmation to someone who fits your second
description.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?

On Monday, July 20, 2015 at 12:59:53 AM UTC-5, Steven D'Aprano wrote:
  Not quite; one is @yahoo.co.uk, and the other is @gmail.com.
 
 Ah, so they are. You're right, I was wrong, they're not
 the same email address. But still, accusations of sock-
 puppetry from a change in email provider is unreasonable,
 and I believe that Rick should acknowledge that he over-
 reacted.

I'm not sure if i misinterpreted the puppetry, or not. I
thought Mark was hiding behind the bream account, but i'm
not so sure now. Weird things were happening yesterday with my
quotes (i even mentioned the strangeness in one of my
replies, check the archives).

But even if i am wrong, the worse thing i did was mis-
interpret his and another post. But since he still owes me
an apology for insulting my integrity, i'd say we're even.
Funny thing is, no one called for Mark to apologize... GO
FIGURE! I guess pets get preferential treatment.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?

On Monday, July 20, 2015 at 1:30:03 AM UTC-5, dieter wrote: 
 Experience like this (in another project) causes me to be
 very reluctant to become a core contributor (in the sense
 of actively fixing things in the core). You need a lot of
 knowledge (coding conventions, test setup, change
 workflow, ...) whichs goes far beyond the functionality of
 the fix -- and you must be resilient, patient and maybe
 even fighting to get the work accepted.

Thanks for sharing your experiences. I hope many more will
come forward and do the same. We are obviously ignoring some
talented people out there, and as i stressed before, we need
to prevent further hemorrhaging of this talent. I know there
are tons of folks who will get involved if we can remove the
onerous barriers.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?

2015-07-20 Thread Terry Reedy


On 7/20/2015 11:33 PM, Chris Angelico wrote:


It's also the manner of workflow. If you want to accept patches and
have them acknowledged to their original authors, the patches need to
carry metadata identifying the authors. Notice how the patch files start 
straight in with content. There's no
authorship information retained.

By comparison, a patch created with 'git format-patch' and applied
with 'git am' starts with RFC 822 headers, provides a commit message,
and generally is intended as a way of transmitting a *commit*, rather
than simply some changes. I'm not overly familiar with Mercurial
workflows, but I think 'hg export' and 'hg import' give the same sort
of information; I tried on CPython and got this:


hg has an option to produce git-format patches.  However, they do not 
work with the Rietveld code review tool, and so are discouraged.  I do 
not know if the extra information would survive an hg commit.


--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?

On Monday, July 20, 2015 at 1:47:00 AM UTC-5, dieter wrote:
 Thinking of myself, I am not sure. Ensuring the quality of
 a distribution goes far beyond a single bug fix. While I
 usually are ready to share a bug fix I have found, I am
 reluctant to get involved in the complete quality
 ensurance process (such as the test suite, review process,
 style guides, ...).

Of course. I believe there are many folks out there like
yourself, who come across this or that bug, but don't bother
sharing the patch because of the reluctance to deal with red
tape or fear of a brow beating.

Participation, on a regular basis, requires a special kind
of person with special talents. For example: Terry Reedy has
been working over at pybugs for years. I don't think
everyone wants to be, or can be, a Terry Reedy. But i do
believe the current system is presenting obstacles to those
that could offer help in whatever limited capacity they can
handle.


OUTLINE OF FOUR POSSIBLE LEVELS OF PARTICIPATION:

  LEVEL1: Anyone, no matter what coding skills they have,
  can bring attention to a problem, and allow someone else
  to write the code. HEY, I FOUND A PROBLEM - BLAH, BLAH,
  BLAH. Also, not all programmers are experts with the
  written word. And a poorly described problem can result in
  it never getting the attention is deserves. We not only
  need coders, we need writer who can peruse the complaints
  and reformat them for comprehension and coherency. We need
  a diversity of talent, and not just code monkey talent,
  all forms!

  LEVEL2: Even someone with sketchy knowledge of the fix
  can write up an outline, or a list of steps that could be
  taken, in order to fix the problem. Possibly pointing out
  some of the subtle bugs that may crop up if not carefully
  considered. Very few of us know *everything* about every
  module or dark corner of Python. For example, I've talked
  with a few grand masters, who had little or no knowledge
  of Tkinter or IDLE.

  LEVEL3: The next level would be to write draft code. Maybe
  the code would not even be considered professional. But
  it could serve as a rough draft that a more experienced
  programmer can build from.
  
  LEVEL4 The last level is a fully functioning patch. This
  would be written, or approved by, one of the trustees.

And even if the contributor can only participate at level1
or level2, if they find the process is smooth, then they are
more likely to participate again. And as they become more
experienced, will offer help at a higher level of expertise.
I know the wheel is being re-invented all the time, simply
because of the obstacles inherent in the patching process.
  
There needs to exist a linear path from bug to patch. We
don't want Terry Reedy wasting his expertise on the first
two or three levels, no, we need to place him at a level
where his talents are not wasted reading ridiculous feature
requests that will never go beyond level1 or level2.

My point is, we're unproductive because: (1) we're scaring
away intermediate and specialized talents (2) and we're mis-
applying the limited talent we do have.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?

2015-07-20 Thread Terry Reedy


On 7/19/2015 6:19 PM, Terry Reedy wrote:


I, and others, have already made some changes to eliminate differences
that are unnecessary, at least for 2.7 versus 3.3+ or now 3.4+.


I just got smacked in the face by a difference I had not run into 
before.  I added about 10 lines to a test file is a section that is 
identical in 2.7 and 3.4+.  One line is

self.assertEqual(type(obj), intended class)
It failed in 2.7.

Quiz: when is the type of an instance not the class that the instance is 
an instance of.  (I expect Steven A. is raising his hand now.)


Give up?

Answer: When you write a class in 2.x without making it a subclass of 
object.


 class Class():
pass

 inst = Class()
 type(inst) is Class
False
 type(inst)
type 'instance'

Since I do not remember how to fix the assert, and was not prepared to 
make the class, in a file other than the one tested, new-style, I just 
commented it out.


This is an example of my claim that backports are best written by 
someone who is a current 2.x user with the particular 2.x knowledge 
needed.  I am not sure I ever had all the knowledge needed to handle the 
backport properly and I now I would prefer to forget about old-style 
classes.


--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?


On 7/18/2015 11:52 PM, Rustom Mody wrote:
among other things, a complaint about rejection of his desire for a 
mechanism for subsetting Python for teaching purposes.


Response 2: Core python is the most conservatively maintained part of 
Python.  Trying to change it radically, as distributed by PSF, is 
practically asking for rejection.  For subsetting, I suggest a different 
tack: filtering input before sending it to python and raise if it 
contains forbidden code.


After Response 1, I posted on the Devanagari thread a similar 
suggestion. I also posted an idea for implementing the idea by extending 
the internal reach of Idle extensions.  I limited the idea to the 
interactive shell because I could not immediately think of a use for 
filtering code before compiling.  Then I thought of this issue.  Among 
other things, code could be tokenized or parsed to an ast for filtering.


--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?

In a message of Sat, 18 Jul 2015 19:36:33 -0400, Terry Reedy writes:
If the vast majority of Python programmers are focused on 2.7, why are 
volunteers to help fix 2.7 bugs so scarce?

Because volunteers to fix any bugs are scarce?  Because most people really
only think of bug fixing when they have one, and when they get that
one fixed they drop back into thinking that everything is perfect?

Does they all consider it perfect (or sufficient) as is?

Should the core developers who do not personally use 2.7 stop 
backporting, because no one cares if they do?

-- 
Terry Jan Reedy

In the tiny corner of industrial automation where I do a lot of work,
nobody is using 3.0.  It is not clear that this is ever going to change.
It would have to be driven by 'lack of people who know 2.x syntax'
or something like that. Not 'third party library compatibility' because
we really don't use them all that much.

In this corner of the world, the favourite language for developing in
is C (because we work close to hardware) and one of the things we like
about it, a whole lot, is that the language never changes out from
under you.  So there is great hope among industrial users of Python
that we can get a hold of a 'never going to change any more' version
of Python, and then code in that 'forever' knowing that a code change
isn't going to come along and break all our stuff.

Bug fixes aren't supposed to do this, of course, in the same way that
backporting of features do, but every so often something that was
introduced to fix bug X ends up breaking something else Y.  If the
consequences of a bug can be 10s of thousands of Euros lost, you
can see the appeal of 'this isn't going to happen any more'.

While nobody likes to get bit by bugs, there is some sort of fuzzy
belief out there that the bugs fixes that have gone into 2.7 are
more about things that we would never run into, and thus we get the
risk of change without the benefit of the bugfix.  This belief isn't
one that people substantiate -- it is 'just a feeling'.

So from this corner of the world, which admittedly is a very small corner,
yes, the news is 'Life is good.  Please leave us alone.'  This is in
large part, I think, due to the belief that 'if things aren't breaking,
things are perfect' which is completely untrue, but that's the way
people are thinking.

Laura
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?]

On Sunday, July 19, 2015 at 12:46:26 PM UTC+5:30, Marko Rauhamaa wrote:
 Chris Angelico:
 
  On Sun, Jul 19, 2015 at 2:45 PM, Steven D'Aprano  wrote:
  sys.setdigits('Devanagari')
 
  Easiest way to play with this would be a sys.displayhook, I think;
 
 I think the numeral selection is analogous to the number base:

Nice analogy

 
 0o10
8
 {:o}.format(0o10)
'10'
 
 what we need is:
 
 {:d/base({base})}.format(0o10, base=7)
'11'
 {:d/numeral('{num}').format(0o10, num=European)
'8'
 {:d/numeral('{num}').format(0o10, num=Roman)
'VIII'
 {:d/numeral('{num}').format(0o10, num=RomanLowerCase)
'viii'
 {:d/numeral('{num}').format(0o10, num=EasternArabic)
'٨'
 {:d/numeral('{num}').format(0o10, num=Devanagari)
'८'
 
 IOW, don't make it global.

But it is willy-nilly global.
Python:
 4+5
9
 

Unix bc:
$ bc
bc 1.06.95
Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'. 
4+5
9
obase=8
4+5
11

IOW bc has two (global) variables ibase and obase for input and output base.
If you dont provide these as settable you hardwire them at 10 (8/16 in some
assembly languages)¹

Hopefully you will agree that python is more full-featured than bc and should
subsume bc functionality?

[Implementability is a second question and ease of implementability a third]

I believe numeral-language is similar

---
¹ When Ive played around with writing assemblers for toy machines, the hardwired
10-base has often been a nuisance. Of course one can in principle rebuild an 
REPL.
Repurposing the existing one is usually a far more palatable option (for me).
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?]

2015-07-19 Thread Marko Rauhamaa

Rustom Mody rustompm...@gmail.com:

 On Sunday, July 19, 2015 at 12:46:26 PM UTC+5:30, Marko Rauhamaa wrote:
 IOW, don't make it global.

 But it is willy-nilly global.
 Python:
 4+5
 9

The interactive mode is not all that interesting, but ok, make that
configurable as well.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?]


On 7/19/2015 12:45 AM, Steven D'Aprano wrote:

On Sun, 19 Jul 2015 01:52 pm, Rustom Mody wrote:



JFTR: My kids (um... students) have just managed to add devanagari
numerals to python.
ie we can now do


१ + २

3


That is actually quite awesome, and I would support a new feature that set
the numeric characters to a particular script, e.g. Latin, Arabic,
Devanagari, whatever, and printed them in that same script. It seems
unfortunate that १ + २ prints as 3 rather than ३.

Python already, and has for many years, supported non-ASCII digits in string
conversions. This is in Python 2.4:

py int(u'१२')
12
py float(u'.१२')
0.12


so the feature goes back a long time.

I think that Python should allow int and float literals using any sequences
of digits from the same language, e.g. 12 or १२ but not १2.


This could be done easily by adding 10 modified productions from
https://docs.python.org/3/reference/lexical_analysis.html#integer-literals
for each language.  The problem of doing the above in the grammar, 
including the no mixing rule, is that is *would* take a separate set of 
productions for each language supported.


 One might have

an interpreter hook which displayed ints and floats using non-ASCII digits,
or one might even build that function into the intepreter, e.g. have a
global setting which tells ints and floats what digits to use, e.g.:

sys.setdigits('Devanagari')

I would support this, or something like this, as a language feature. If we
can write Python using Hindi identifiers, why not Hindi numerals?


As I remember, when non-ascii-digit inputs to int were last discussed 
(python-ideas?, pydev?), the possibility of expanding literals was 
mentioned.  As I remember, to idea was rejected or deferred on the basis 
that nearly all numbers used in production programs are read from files 
as numbers or converted by int or float.  The few numeric literals in 
programs could just as well be converted first, or the int expression 
could be used.


These true observations do not cover the shell, as in the examples 
above.  At some time, Guido has expresses the opinion that interactive 
console python should remain plain and basic and the fancier interaction 
features are the domain of replacement shells.


That brings me, anyway, to Idle.  It currently imitates console python 
in sending keystrokes as is to compile() and output streams as are to 
the tk display.  There are a couple of tracker issues claiming that this 
means that Idle does not imitate console python because a tk display 
does not treat backspace and return the same way simulated terminal 
consoles usually do.


While the bug claims have been rejected, I have been thinking that the 
Idle extension interface could and maybe should be extended so that 
extensions could filter and either transform or act on the input/output 
streams.


With a general mechanism in place, it would be trivial to use 
str.maketrans and str.translate in the input/output streams.  This would 
not disable ascii digit input, including mixtures in a single literal, 
but output has to all be in one digit set.  Selecting a language is a 
somewhat solved problem because last summer we added a extension 
configuration dialog that dynamically generates a dialog tab for each 
extension present.


--
Terry Jan Reedy


--
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?


On 7/18/2015 8:03 PM, Gary Herron wrote:

On 07/18/2015 04:36 PM, Terry Reedy wrote:

  I would like more viewpoints from 2.7 users.


I read that (incorrectly of course) and just had to ask:
How do you intend to extract a viewpoint from that last 7/10 of a user?

With apologies,


Some humor is definitely welcome.

--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?

2015-07-19 Thread Gary Herron


On 07/18/2015 04:36 PM, Terry Reedy wrote:

  I would like more viewpoints from 2.7 users.


I read that (incorrectly of course) and just had to ask:
   How do you intend to extract a viewpoint from that last 7/10 of a user?

With apologies,

Gary Herron




--
Dr. Gary Herron
Department of Computer Science
DigiPen Institute of Technology
(425) 895-4418

--
https://mail.python.org/mailman/listinfo/python-list

Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?]

2015-07-19 Thread Anuradha Laxminarayan

On Sunday, July 19, 2015 at 10:15:37 AM UTC+5:30, Steven D'Aprano wrote:
 On Sun, 19 Jul 2015 01:52 pm, Rustom Mody wrote:

  Not to mention actively hostile attitude to discussions that could at the
  moment be tangential to current CPython. See (and whole thread)
  https://mail.python.org/pipermail/python-ideas/2015-May/033708.html

 I stand by my comments there. I have no disagreement with your aim to build
 a specialised language for teaching functional programming. I don't believe
 that should be Python.


  JFTR: My kids (um... students) have just managed to add devanagari
  numerals to python.
  ie we can now do
 
  १ + २
  3

 That is actually quite awesome, and I would support a new feature that set
 the numeric characters to a particular script, e.g. Latin, Arabic,
 Devanagari, whatever, and printed them in that same script. It seems
 unfortunate that १ + २ prints as 3 rather than ३.

Thanks. [I am part of this team]


 Python already, and has for many years, supported non-ASCII digits in string
 conversions. This is in Python 2.4:

 py int(u'१२')
 12
 py float(u'.१२')
 0.12


Very useful to know!


 so the feature goes back a long time.

 I think that Python should allow int and float literals using any sequences
 of digits from the same language, e.g. 12 or १२ but not १2. One might have
 an interpreter hook which displayed ints and floats using non-ASCII digits,
 or one might even build that function into the intepreter, e.g. have a
 global setting which tells ints and floats what digits to use, e.g.:

 sys.setdigits('Devanagari')



Currently our code works with UTF-8 byte sequences not unicode codepoints
because thats how tokenizer.c is structured: messy and not generalizable 
(easily) to things beyond devanagari.  How far this can be improved (without 
too deep surgery) is not quite clear yet.

In other words, this generality is nice to talk about but easier said than done 
at the moment.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?


On 7/18/2015 11:52 PM, Rustom Mody wrote:


Not to mention actively hostile attitude to discussions that could at the
moment be tangential to current CPython. See (and whole thread)
https://mail.python.org/pipermail/python-ideas/2015-May/033708.html


Rustom, I think this is grossly unfair.  Python-ideas was started by 
Guido as a forum for ideas about *future* versions of Python.  Your post 
was about teaching Python,which is something different, as are lost of 
other Python-related topics. It would have fit either this list or 
edu-sig better.


Your post
https://mail.python.org/pipermail/python-ideas/2015-May/033661.html
started a thread with nearly 40 responses, which is far more than 
average.  Thou doth protest too much. This

https://mail.python.org/pipermail/python-ideas/2015-May/thread.html#33672
is the list for May; there might be a few more in June.

To the extent that you were (vaguely) proposing a change to core python 
itself, by splitting it up into 'teachpacks' (whatever those are) and 
'concentric rings', the idea was quickly rejected. It is too 
specialized, being aimed as one use, and impractically complicated for a 
mostly volunteer development group.  It is the sort of thing one might 
do with a $5 million grant.


Beyond that, the thread veered ogf onto topics that even you labelled 
off-topic.  Yes, we are hostile to prolonged off-topic discussions. 
They detract from the purpose of the list.


--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?]

2015-07-19 Thread Marko Rauhamaa

Chris Angelico ros...@gmail.com:

 On Sun, Jul 19, 2015 at 2:45 PM, Steven D'Aprano st...@pearwood.info wrote:
 sys.setdigits('Devanagari')

 Easiest way to play with this would be a sys.displayhook, I think;

I think the numeral selection is analogous to the number base:

0o10
   8
{:o}.format(0o10)
   '10'

what we need is:

{:d/base({base})}.format(0o10, base=7)
   '11'
{:d/numeral('{num}').format(0o10, num=European)
   '8'
{:d/numeral('{num}').format(0o10, num=Roman)
   'VIII'
{:d/numeral('{num}').format(0o10, num=RomanLowerCase)
   'viii'
{:d/numeral('{num}').format(0o10, num=EasternArabic)
   '٨'
{:d/numeral('{num}').format(0o10, num=Devanagari)
   '८'

IOW, don't make it global.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?


On 19/07/2015 03:13, Terry Reedy wrote:

On 7/18/2015 7:50 PM, Devin Jeanpierre wrote:

to 2.7, surely bug fixes are also allowed?


Of course, allowed.  But should they be made, and if so, by who?


The people who want the fixes.




I have contributed both performance improvements and bug fixes to 2.7.
In my experience, the problem is not the lack of contributors, it's
the lack of code reviewers.


I understand the general problem quite well.  But feeling that one would
have to do a 2.7 backport after writing, editing, or reviewing a 3.x
patch can discourage doing a review in the first place. I am at that
point now with respect to Idle patches.


Do the work with the 3.x patch and finish.  Let somebody who needs the 
patch for 2.7 do the work.  If nobody steps up to the mark that's not 
Terry Reedy's problem, you've done way more than your fair share over 
the years.


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

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?


On 19/07/2015 04:45, Paul Rubin wrote:

Terry Reedy tjre...@udel.edu writes:

I am suggesting that if there are 10x as many 2.7only programmers as
3.xonly programmers, and none of the 2.7 programmers is willing to do
the backport *of an already accepted patch*, then maybe it should not
be done at all.


The patch acceptance/approval process is frankly daunting.



Correct, which is why PEP 0462 -- Core development workflow automation 
for CPython https://www.python.org/dev/peps/pep-0462/, PEP 0474 -- 
Creating forge.python.org https://www.python.org/dev/peps/pep-0474/ and 
a separate core-workflow mailing list exist.


Admittedly things had stalled but I understand that they're being picked 
up again.


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

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?


On 19/07/2015 04:52, Rustom Mody wrote:


Not to mention actively hostile attitude to discussions that could at the
moment be tangential to current CPython. See (and whole thread)
https://mail.python.org/pipermail/python-ideas/2015-May/033708.html



This https://mail.python.org/pipermail/python-ideas/2015-May/033686.html 
is actively hostile?  Sour grapes springs to my mind.


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

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?

On Sun, 19 Jul 2015 07:27 pm, Laura Creighton wrote:

 In the tiny corner of industrial automation where I do a lot of work,
 nobody is using 3.0.

I should hope not, because 3.0 was rubbish and is unsupported :-)

I expect you mean 3.x in general.


 It is not clear that this is ever going to change. 
 It would have to be driven by 'lack of people who know 2.x syntax'
 or something like that. Not 'third party library compatibility' because
 we really don't use them all that much.
 
 In this corner of the world, the favourite language for developing in
 is C (because we work close to hardware) and one of the things we like
 about it, a whole lot, is that the language never changes out from
 under you.

Bug for bug compatible back to the 1970s, right? :-)

I sympathise, really I do. Particularly in the application space (Firefox,
I'm looking at you) I'm really fed up with every security update breaking
functionality, removing features, and adding anti-features.


 So there is great hope among industrial users of Python 
 that we can get a hold of a 'never going to change any more' version
 of Python, and then code in that 'forever' knowing that a code change
 isn't going to come along and break all our stuff.

Presumably they like the 2.7 features too much to go back to an even older
version. Because 2.5 or even 1.5 are pretty stable now.

I'm not kidding about 1.5, a year or two ago there was (so I'm told) a
fellow at PyCon in the US who was still using 1.5. If it ain't broke,
don't fix it -- he wasn't concerned about security updates, or new
features, he just needed to keep his legacy applications running.

I get it, I really do, and so do the core developers. (Well, most of them,
and certainly Guido.) It cannot be said often enough and loudly enough that
if you find yourself in the lucky position where you don't need to care
about security updates, bug fixes or new functionality, there is absolutely
nothing wrong with using an old, unmaintained, stable version forever.



-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?


On 19/07/2015 06:53, dieter wrote:

Mark Lawrence breamore...@yahoo.co.uk writes:

...

If the vast majority of Python programmers are focused on 2.7, why are
volunteers to help fix 2.7 bugs so scarce?


I have not done much work related to Python bug fixing. But, I had
bad experience with other open source projects: many of my patches
(and bug reports) have been ignored over decades. This caused me
to change my attitude: I now report bugs (sometimes with patches)
and publish a potential solution in a separate package
(-- dm.zopepatches.*, dm.zodbpatches.*). This way, affected
people can use a solution even if the core developpers don't care.

 From my point of view: if you want help with fixing bugs,
you must ensure that there is a high probability that those contributions
really find their way into the main development lines.
As I understand from other messages in this thread, this is also
a problem with Python bug fixing.



The entire workflow is the problem.  This is now being addressed, see my 
earlier reply to Paul Rubin.


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

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?

On Sunday, July 19, 2015 at 2:42:41 PM UTC+5:30, Terry Reedy wrote:
 On 7/18/2015 11:52 PM, Rustom Mody wrote:
 among other things, a complaint about rejection of his desire for a 
 mechanism for subsetting Python for teaching purposes.

Sorry Terry if the compliant sounded louder than the answer. You asked:
 If the vast majority of Python programmers are focused on 2.7, why are
 volunteers to help fix 2.7 bugs so scarce? 

As someone who's been associated in one way or other with teaching for near 3 
decades, I'd say that of the two factors which destroy an education institute --
bar to entry too high, bar to entry too low  -- the second is by far the more
dangerous.

I believe open source is no different.  If every patch is to be accepted (or 
even given a polite answer) there will be no remaining working code.
And this will become more true the more the project is successful.

Super successful projects like the linux kernel are that way because the top 
guys are ruthlessly meritocratic: If your submission is poor you are told 
Your code is shit

If you persist, the Your code shortens to You

As I said it to Paul: I am thankful that python is meritocratic

As for that specific exchange I would rather not flog that horse further
[in public at least -- we can continue off list]
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?

On Sunday, July 19, 2015 at 12:54:34 AM UTC-5, dieter wrote:
 From my point of view: if you want help with fixing bugs,
 you must ensure that there is a high probability that
 those contributions really find their way into the main
 development lines. As I understand from other messages in
 this thread, this is also a problem with Python bug
 fixing.

(Not sure who said this, so my apologies if the attribution
is incorrect)

Bug fixing is not something most programmers find enjoyable,
at least not for long durations. I prefer to spend my time
solving real world problems, and designing intuitive APIs,
this is what brings me joy. 

Heck, there have been many times that i purposefully re-
invented the wheel simply because solving the problem is
much easier (and more enjoyable) than trying to understand
another programmer's atrocious spaghetti code. Therefor, we
should not be surprised that the bug list is so understaffed
and lacks vigor.

What is becoming apparent to me though, is that most of the
complaints i had voiced (years ago) about the exclusive
attitudes, horrible interface, and the burdensome workflow
of submitting patches is contributing to the lack of
interest in this process - and it seems i am not alone!

I can remember twice getting excited about helping out, to
only quickly become frustrated with the politics and
interface. Why should i have to fight just to volunteer?
What's the point? The whole system is self defeating.

Time for some introspection folks.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?

In a message of Sun, 19 Jul 2015 09:29:11 -0600, Ian Kelly writes:
I think this is an unrealistic and unattainable goal. Even if you stop
patching your Python 2.7 version altogether, what about the
environment that it runs in? Are you going to stop patching the OS
forever? Are you going to fix the current machine architecture exactly
as it is, forever? I don't know if industrial code uses a network much
or at all, but if it does, are you never going to upgrade your network
infrastructure?

There is clearly some wishful thinking going around here, but
in terms of having the same machine architecture forever ... well, my
friend the hardware guy can make you a board that you can plug your
old perfectly working, reliable 1970s tech machines into -- because they
really want to be plugged into a pdp-11 running RSX-11.  Then we fake
things using Python to simulate enough RSX-11 to keep on running.

We figure the machines will still be running long after we are dead.

Laura
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?


On 19/07/2015 23:10, Cecil Westerhof wrote:

On Sunday 19 Jul 2015 22:28 CEST, Mark Lawrence wrote:


On 19/07/2015 21:05, Cecil Westerhof wrote:

On Sunday 19 Jul 2015 21:01 CEST, Ian Kelly wrote:


On Sun, Jul 19, 2015 at 10:10 AM, Cecil Westerhof ce...@decebal.nl wrote:

On Sunday 19 Jul 2015 15:42 CEST, Mark Lawrence wrote:


On 19/07/2015 03:13, Terry Reedy wrote:

On 7/18/2015 7:50 PM, Devin Jeanpierre wrote:

to 2.7, surely bug fixes are also allowed?


Of course, allowed. But should they be made, and if so, by who?


The people who want the fixes.


Babies want clean diapers. So babies have to change diapers
themselves?


Poor analogy. Babies need others to change their diapers for them
because they're not capable of doing it for themselves.


That is why I think it is good analogy. I think that most of the
users of 2.7 who would be delighted with fixes would have no idea
how to get those fixes into 2.7.



They could try reading the development guide to start with, or is
that also too much to ask?


My impression is that you and some other people are in an ivory tower
and find it very cosy.

It reminds me about the man on dry land who responded to the person
who fell in water and shouted
 “Help, I cannot swim!”
with
 “Why are you screaming?
  I cannot swim also.
  Do you hear me yelling about it?



You are now suggesting that people shouldn't even bother reading the 
develoment guide, just great.  Do they have to do anything themselves to 
get patches through?  Presumably the core devs give up their paid work, 
holidays, families, other hobbies and the like, just so some bunch of 
lazy, bone idle gits can get what they want, for nothing, when it suits 
them?  It appears that babies aren't the only people who need their 
nappies changing around here.


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

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?


On 20/07/2015 02:20, Devin Jeanpierre wrote:



I don't like how this is being redirected to surely you
misunderstood or I don't believe you. The fact that some core devs
are hostile to 2.x development is really bleedingly obvious, you
shouldn't need quotes or context thrown at you. The rhetoric almost
always shies _just_ short of ceasing bugfixes (until 2020, when that
abruptly becomes a cracking good idea). e.g. in 2.7 is here until
2020, please don't call it a waste.



A couple of things.

First some core devs are hostile, actually some have stated that 
they're simply not interested in 2.7 and will not work on it.


Second how has the thread got here, as it was originally asking about 
back porting bug fixes from 3.x to 2.7?  Further it said:-


quote
If the vast majority of Python programmers are focused on 2.7, why are 
volunteers to help fix 2.7 bugs so scarce?

/quote

So I most humbly suggest, as I may have hinted at once or twice earlier 
in this thread, that people either put up or shut up.


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

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?

On Mon, 20 Jul 2015 08:51 am, Mark Lawrence wrote:

 You are now suggesting that people shouldn't even bother reading the
 develoment guide, just great.  Do they have to do anything themselves to
 get patches through?  Presumably the core devs give up their paid work,
 holidays, families, other hobbies and the like, just so some bunch of
 lazy, bone idle gits can get what they want, for nothing, when it suits
 them?

Just a reminder that at least some of the core devs, including Guido, are
paid to work on Python.

And another reminder that open source software doesn't have any restrictions
about only distributing software to those who are willing and able to write
patches for it. Anyone can use Python, including children and
non-programmers. Being able to hack on the interpreter C code and produce
quality patches is not a pre-requisite.

I know that I've reported bugs in Python that I was unqualified or incapable
of fixing, at least without going through months or years of learning. At
least one of those bugs has been fixed by others who have the skills.



-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?

2015-07-19 Thread breamoreboy

On Sunday, July 19, 2015 at 10:27:58 PM UTC+1, Rick Johnson wrote:
 On Sunday, July 19, 2015 at 3:36:21 PM UTC-5, bream...@gmail.com wrote:
  Wrong, not all programmers need the patches as a lot of
  people couldn't care two hoots about 2.7.  
 
 Well you should. Because apparently, you're incapable of
 recognizing that Py2 and Py3 are existentially joined at the
 hip! The world of language survival is more complex than your
 selfish desires.

Wrong again, 2.7 doesn't have all the goodies now poring into 3.x, so there is 
nothing in 2.7 to make me care.  Further as I'm a one man band I do what I 
like, so having canned it several years back, as have many core devs, it's 
staying canned.  Selfish desires, very funny, I'll have to remember that one, 
you really are excelling yourself.

 
 If you're unable to draw parallels between py2 and py3,
 it's only because your focused is far too narrow. Negative
 perception of py2 translates to negative perception of py3.

I have no negative perception of 2.7, it simply no longer interests me, to 
repeat in the same way that it no longer interests some core devs.

 
 Python is the sum of all it's parts. Not merely the small
 part (or rattle) that you happen to find amusing. And since
 py3 is the smallest part of Python, and py2 is the largest,
 you would be wise to consider the consequences of a failed,
 or even perceived failure, of Py2.

2.7 is pretty much rock steady Eddie, so it is never going to be a perceived 
failure, let alone an actual failure.

 
 If you change the diapers in Py3 nursery but refuse to change 
 them in Py2 nursery, you might alleviate the your diaper rash, 
 but other babies poop will always smell worse than your own!

I'll repeat, those who want 2.7 supported do the work, can it get any simpler?  
You can support it, or are you still too busy working on your fork, 
RickedPython?  I'm not interested in it, I'm wouldn't touch it even if someone 
offered to pay me, end of story.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?

On Sunday, July 19, 2015 at 8:26:52 PM UTC-5, bream...@gmail.com wrote:
 On Monday, July 20, 2015 at 1:49:58 AM UTC+1, Rick Johnson wrote:
  On Sunday, July 19, 2015 at 7:28:28 PM UTC-5, Mark Lawrence wrote:

  Every time i defeat [MARK LAWRENCE], and drag him out
  through an opening in the caverns of code, and take
  him to a secret grove owned by D'Aprano, he always
  escapes and returns to guard the entrance again -- he's
  very loyal!
 
 Your total number of victories over me is zero, although I
 personally come here to give or get knowledge, not look
 for such things.

I figured that was you *MARK LAWRENCE*. I shall add sock-puppeting 
to your many egregious offenses! And poorly executed sock-puppeting 
as well! You're a zero.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?]

On Monday, July 20, 2015 at 4:43:57 AM UTC+5:30, Terry Reedy wrote:
 On 7/19/2015 3:32 AM, Rustom Mody wrote:
 
  Unix bc:
  $ bc
  bc 1.06.95
  Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006 Free Software Foundation, 
  Inc.
  This is free software with ABSOLUTELY NO WARRANTY.
  For details type `warranty'.
  4+5
  9
  obase=8
  4+5
  11
 
  IOW bc has two (global) variables ibase and obase for input and output base.
  If you dont provide these as settable you hardwire them at 10 (8/16 in some
  assembly languages)¹
 
  Hopefully you will agree that python is more full-featured than bc and 
  should
  subsume bc functionality?
 
 Nice try ;-) However, I think is not especially relevant.  I do not 
 believe that Guido would agree that bc should govern python design. Do 
 *you* really think that?  Python is fundamentally a general purpose 
 batch-mode language.  Interactive mode is secondary and generally 
 subservient to writing real programs.  I know that he has said that he 
 is not inclined to add additional interactive-mode-only features to Python.

We will have to agree to disagree then.

I wrote this in 2012 (that is to say not in context of this discussion):
http://blog.languager.org/2012/10/functional-programming-lost-booty.html

in which I list an REPL as one of the factors that distinguish a modern, 
powerful v hi-level language from stodgy old-fashioned blub languages.

Regarding your earlier points about idle, I think you are (to use a traditional 
OS metaphor) mixing up policy with mechanism.
Policy: Having a REPL (things like Idle)
Mechanism: How exactly its bundled

eg in pythonland python the interpreter and the interactive version are the same
executable functioning in different modes
In other languages (haskell has ghci, ruby has irb) the interactive interpreter
is a different program (just a thin wrapper) on the main interpreter (compiler
for haskell)
Likewise in debian (ubuntu) vs windows the bundling is v different.
In debian python comes for free and the system would not work without it but 
tkinter, idle etc need to be installed with their dependencies
In windows, one needs to install one bundle and one gets the whole lot...

Of course as recently discussed, it may be time to have ipython replace vanilla
python and therefore break that off from the core. 

These are (to me) minor points compared to the existence/non-existence of  an 
interactive interpreter.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?

On Mon, 20 Jul 2015 05:01 am, Ian Kelly wrote:

 On Sun, Jul 19, 2015 at 10:10 AM, Cecil Westerhof ce...@decebal.nl
 wrote:
 On Sunday 19 Jul 2015 15:42 CEST, Mark Lawrence wrote:

 On 19/07/2015 03:13, Terry Reedy wrote:
 On 7/18/2015 7:50 PM, Devin Jeanpierre wrote:
 to 2.7, surely bug fixes are also allowed?

 Of course, allowed.  But should they be made, and if so, by who?

 The people who want the fixes.

 Babies want clean diapers. So babies have to change diapers
 themselves?
 
 Poor analogy. Babies need others to change their diapers for them
 because they're not capable of doing it for themselves.

Good analogy. Most Python programmers are no more able to write patches for
Python than babies are able to change their own nappy.



-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?

On Mon, Jul 20, 2015 at 12:16 PM, Rustom Mody rustompm...@gmail.com wrote:
I just ran the following command
$ hg log --template {author|person}\n | sort | uniq -c | sort -nr

So... May I humbly ask where are your precious commits??

Same place that mine aren't. Compare:

http://bugs.python.org/issue24610
https://hg.python.org/cpython/rev/02b81a82a57d

(It's a trivial docs patch, but that makes for a better demo than the
messy PEP 479/issue22906 stuff, where different parts got committed at
different times.)

I create a patch on my local clone of the CPython repository, and
rather than push it directly (which technically I _could_ do, but
socially I don't have jurisdiction over the main source code), I
create a tracker issue and attach the patch. Then someone else commits
it - and it's his name that's on the commit. Same here:

http://bugs.python.org/issue24435
https://hg.python.org/cpython/rev/a9c34db88d79

No matter how many patches I write (not that I write very many), I
won't show up on your list unless I actually push my own code. Mark
isn't a core committer, so you won't see him. A quick search of the
tracker came up with this:

http://bugs.python.org/issue19980

It's a closed issue with a patch by Mark Lawrence. (There may well be
others, I have no idea. All I know is that this one came up in the
search.) The author of the resulting commit is Serhiy, not Mark, so
that's who you'll be counting in your stats.

Sorry to say, the flaw is in your testing methodology.

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?

On Mon, 20 Jul 2015 11:20 am, Devin Jeanpierre wrote:

 On Sat, Jul 18, 2015 at 9:45 PM, Steven D'Aprano st...@pearwood.info
 wrote:
 It gets really boring submitting 2.7-specific patches, though, when
 they aren't accepted, and the committers have such a hostile attitude
 towards it. I was told by core devs that, instead of fixing bugs in
 Python 2, I should just rewrite my app in Python 3.

 Really? Can you point us to this discussion?
 
 Yes, really. It was on #python-dev IRC.

Ah, pity, because I really would have liked to have seen the context. (I
assume there are no archives of #python and #python-dev. At least, I've
never found them.)


 If you are right, and that was an official pronouncement, then it seems
 that non-security bug fixes to 2.7 are forbidden.
 
 I never said it was a pronouncement, or official. It wasn't. I have no
 idea where you got that idea from, given that I specifically have said
 that I think non-security bug fixes are allowed.

You said that core devs told you not to fix bugs in Python 2. Do you really
think it's a big stretch to go from core devs said don't fix Python 2
bugs to it's core dev policy to not fix Python 2 bugs?


 Search your logs for https://bugs.python.org/issue17094 and
 http://bugs.python.org/issue5315
 
 I was most frustrated by the first case -- the patch was (informally)
 rejected in favor of the right fix, and the right fix was
 (informally) rejected because it changed behavior, leaving me only
 with the option of absurd workarounds of a bug in Python, or moving to
 python 3.

In the first case, 17094, your comments weren't added until TWO YEARS after
the issue was closed. It's quite possible that nobody has even noticed
them. In the second case, the issue is still open. So I don't understand
your description above: there's no sign that the patch in 17094 was
rejected, the patch had bugs and it was fixed and applied to 3.4. It wasn't
applied to 2.7 for the reasons explained in the tracker: it could break
code that is currently working.

For the second issue, it has neither been applied nor rejected.


 I don't like how this is being redirected to surely you
 misunderstood or I don't believe you. The fact that some core devs
 are hostile to 2.x development is really bleedingly obvious, 

Not to me it isn't. At worst, I would say that some of them are indifferent
to 2.7.


 you 
 shouldn't need quotes or context thrown at you. The rhetoric almost
 always shies _just_ short of ceasing bugfixes (until 2020, when that
 abruptly becomes a cracking good idea). e.g. in 2.7 is here until
 2020, please don't call it a waste.

Right. So you take an extended ten year maintenance period for Python 2.7 as
evidence that the core devs are *hostile* to maintaining 2.7? That makes no
sense to me.

If you want to say that *some individuals* who happen to have commit rights
are hostile to Python 2.7, I can't really argue with that. Individuals can
have all sorts of ideas and opinions. But the core devs as a group are very
supportive of Python 2.7, even going to the effort of back-porting
performance improvements.



-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?


On 7/19/2015 5:27 AM, Laura Creighton wrote:

In a message of Sat, 18 Jul 2015 19:36:33 -0400, Terry Reedy writes:

If the vast majority of Python programmers are focused on 2.7, why are
volunteers to help fix 2.7 bugs so scarce?


Because volunteers to fix any bugs are scarce?  Because most people really
only think of bug fixing when they have one, and when they get that
one fixed they drop back into thinking that everything is perfect?


Does they all consider it perfect (or sufficient) as is?

Should the core developers who do not personally use 2.7 stop
backporting, because no one cares if they do?

--
Terry Jan Reedy


In the tiny corner of industrial automation where I do a lot of work,
nobody is using 3.0.  It is not clear that this is ever going to change.
It would have to be driven by 'lack of people who know 2.x syntax'
or something like that. Not 'third party library compatibility' because
we really don't use them all that much.

In this corner of the world, the favourite language for developing in
is C (because we work close to hardware) and one of the things we like
about it, a whole lot, is that the language never changes out from
under you.  So there is great hope among industrial users of Python
that we can get a hold of a 'never going to change any more' version
of Python, and then code in that 'forever' knowing that a code change
isn't going to come along and break all our stuff.


Any version of Python too old even for security patches would qualify. 
Of course, in a chaotic environment, static code may mean unstatic 
behavior.  Changing internet attacks and changing build environments are 
the prime reason for extending 2.7 maintenance.



Bug fixes aren't supposed to do this, of course, in the same way that
backporting of features do, but every so often something that was
introduced to fix bug X ends up breaking something else Y.  If the
consequences of a bug can be 10s of thousands of Euros lost, you
can see the appeal of 'this isn't going to happen any more'.

While nobody likes to get bit by bugs, there is some sort of fuzzy
belief out there that the bugs fixes that have gone into 2.7 are
more about things that we would never run into, and thus we get the
risk of change without the benefit of the bugfix.  This belief isn't
one that people substantiate -- it is 'just a feeling'.

So from this corner of the world, which admittedly is a very small corner,
yes, the news is 'Life is good.  Please leave us alone.'  This is in
large part, I think, due to the belief that 'if things aren't breaking,
things are perfect' which is completely untrue, but that's the way
people are thinking.


The extended extended maintenance for 2.7 (from now to 2020) is 
primarily for security and build fixes.  I am beginning to think that 
the ambiguity of 'secondarily for other fixes, on a case-by-case basis, 
as determined by the whim of individual core developers' is a disservice 
to most users as well as most core developers.


--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?

On Sunday, July 19, 2015 at 3:36:21 PM UTC-5, bream...@gmail.com wrote:
 Wrong, not all programmers need the patches as a lot of
 people couldn't care two hoots about 2.7.  

Well you should. Because apparently, you're incapable of
recognizing that Py2 and Py3 are existentially joined at the
hip! The world of language survival is more complex than your
selfish desires.

If you're unable to draw parallels between py2 and py3,
it's only because your focused is far too narrow. Negative
perception of py2 translates to negative perception of py3.

Python is the sum of all it's parts. Not merely the small
part (or rattle) that you happen to find amusing. And since
py3 is the smallest part of Python, and py2 is the largest,
you would be wise to consider the consequences of a failed,
or even perceived failure, of Py2.

If you change the diapers in Py3 nursery but refuse to change 
them in Py2 nursery, you might alleviate the your diaper rash, 
but other babies poop will always smell worse than your own!








-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?


On 7/19/2015 1:53 AM, dieter wrote:

Mark Lawrence breamore...@yahoo.co.uk writes:

...

If the vast majority of Python programmers are focused on 2.7, why are
volunteers to help fix 2.7 bugs so scarce?


I have not done much work related to Python bug fixing. But, I had
bad experience with other open source projects: many of my patches
(and bug reports) have been ignored over decades. This caused me
to change my attitude: I now report bugs (sometimes with patches)
and publish a potential solution in a separate package
(-- dm.zopepatches.*, dm.zodbpatches.*). This way, affected
people can use a solution even if the core developpers don't care.


Patches uploaded to the cpython tracker are public and can be and 
sometimes are used by other people without or before being officially 
applied.  Separate packages are fine too.



 From my point of view: if you want help with fixing bugs,
you must ensure that there is a high probability that those contributions
really find their way into the main development lines.
As I understand from other messages in this thread, this is also
a problem with Python bug fixing.


Yes.  There are two competing proposals (PEPs) for improvement waiting 
for a decision from an appointed judge.



Does they all consider it perfect (or sufficient) as is?


I have not much blame for Python 2.7. I see a few minor points

   *  pdb is quite weak - but I could fix some (but
  by far not all) aspects in dm.pdb.


This is not a security issue, so enhancements cannot go in 2.7.


   *  https has been weakly handled in earlier versions,
  but someone has done the Python 3 backport work in
  an external package before the backport finally arrived in
  Python 2.7.


This was determined to be an internet security fix.


Should the core developers who do not personally use 2.7 stop
backporting, because no one cares if they do?


I am grateful that the above mentioned https backport
was finally integrated into Python 2.7 -- even though
I find it acceptable to use an external package to get it.

Thus, there are people who care. Of course, I will not tell
core developers that they must do backporting. If they don't
more external packages will come into existence which contain
(unofficial) backports.


Some core developers have backported new modules they wrote as external 
packages.  Thank you for your comments.


--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?


On 20/07/2015 00:23, Cecil Westerhof wrote:

On Monday 20 Jul 2015 00:51 CEST, Mark Lawrence wrote:


On 19/07/2015 23:10, Cecil Westerhof wrote:

On Sunday 19 Jul 2015 22:28 CEST, Mark Lawrence wrote:


On 19/07/2015 21:05, Cecil Westerhof wrote:

On Sunday 19 Jul 2015 21:01 CEST, Ian Kelly wrote:


On Sun, Jul 19, 2015 at 10:10 AM, Cecil Westerhof ce...@decebal.nl wrote:

On Sunday 19 Jul 2015 15:42 CEST, Mark Lawrence wrote:


On 19/07/2015 03:13, Terry Reedy wrote:

On 7/18/2015 7:50 PM, Devin Jeanpierre wrote:

to 2.7, surely bug fixes are also allowed?


Of course, allowed. But should they be made, and if so, by
who?


The people who want the fixes.


Babies want clean diapers. So babies have to change diapers
themselves?


Poor analogy. Babies need others to change their diapers for
them because they're not capable of doing it for themselves.


That is why I think it is good analogy. I think that most of the
users of 2.7 who would be delighted with fixes would have no idea
how to get those fixes into 2.7.



They could try reading the development guide to start with, or is
that also too much to ask?


My impression is that you and some other people are in an ivory
tower and find it very cosy.

It reminds me about the man on dry land who responded to the person
who fell in water and shouted
“Help, I cannot swim!”
with
“Why are you screaming?
I cannot swim also.
Do you hear me yelling about it?



You are now suggesting that people shouldn't even bother reading the
develoment guide, just great. Do they have to do anything themselves
to get patches through? Presumably the core devs give up their paid
work, holidays, families, other hobbies and the like, just so some
bunch of lazy, bone idle gits can get what they want, for nothing,
when it suits them? It appears that babies aren't the only people
who need their nappies changing around here.


No use replying anymore. You make a caricature of what I am saying and
put words in my mouth I never said. Just stay in your cosy ivory
tower. But please do not pretend that you are open for discussion,
because you are not.



Thank goodness for that as you make no sense at all.

As for this ivory tower nonsense, you clearly haven't bothered reading 
anything I've said about the proposed improvements to the core workflow. 
 But then of course you wouldn't bother with that, you again expect 
somebody else to do all the work for you, for free, and probably still 
complain that the benefits that you're getting aren't enough.  Quite 
frankly your attitude throughout this thread makes me puke.


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

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?

On Sunday, July 19, 2015 at 7:28:28 PM UTC-5, Mark Lawrence wrote:

 Thank goodness for that as you make no sense at all. As
 for this ivory tower nonsense, [...]

Cecil, don't pay too much attention to Mark, he's a glory
hound. He's like the Python community version of Cerberus --
you know, the three headed dog guarding the entrance to the
Greek underworld. 

Every time i defeat him, and drag him out through an opening in
the caverns of code, and take him to a secret grove owned
by D'Aprano, he always escapes and returns to guard the
entrance again -- he's very loyal!

He won't allow you to enter because you're still alive, and
as such, you still have the capacity to feel emotions like
compassion. These emotions are forbidden in the underworld!!!

But don't worry, his bark is worse than his bite, and he is
just the first of many daemons you must defeat on your quest
to challenge the benevolent Hades.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?


On 7/18/2015 10:48 PM, Zachary Ware wrote:

On Sat, Jul 18, 2015 at 9:13 PM, Terry Reedy tjre...@udel.edu wrote:

I understand the general problem quite well.  But feeling that one would
have to do a 2.7 backport after writing, editing, or reviewing a 3.x patch
can discourage doing a review in the first place. I am at that point now
with respect to Idle patches.


I wonder if it would be worth the significant one-time effort to port
IDLE to 2/3, so that future bugfixes/improvements don't require any
extra effort than testing them with all versions.


I am not aware of any version problems with tkinter code. In general, in 
the modules I have looked at, the main necessary differences are the 
Tkinter/tkinter, MessageBox/messagebox imports. In some files, the 
exception changes in 3.3 are even more a nuisance, since the name 
differences can be anywhere in the file.


Since 2.7 patching will end sooner or later, I am reluctant to add 'if 
version' to 3.x.  The exception changes could be masked in 2.7 by 
rebinding exception names at the top, but I am not sure that this would 
be a good idea.


I, and others, have already made some changes to eliminate differences 
that are unnecessary, at least for 2.7 versus 3.3+ or now 3.4+.  For 
instance, I believe all 'except X, msg:' statements have been converted 
to 'except X as msg:'.  Most of the files with 'print' still need 
conversion to a future imports + function call.  I have eliminated most 
other differences in at least a couple of modules before patching, and 
in one module that needs multiple patches.


Hmm.  After manual insertion of future print imports in 2.7 files, 2to3 
could be used to convert the 2.7 print statements.  This would be much 
easier than manual conversion and or copying for 3.x.  Thanks for the 
inspiration.

https://bugs.python.org/issue24671

--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?

On Sunday, July 19, 2015 at 7:45:43 PM UTC-5, bream...@gmail.com wrote:
 I have no negative perception of 2.7, it simply no longer
 interests me, to repeat in the same way that it no longer
 interests some core devs.

Your apathy towards Py2 will not shield you from the
collateral damage caused by it's demise.

What matters is what the *WORLD* thinks about Python. And if
the global perception is that: Python is buggy, or that:
the python community is fractured - then all hope in
widespread future adoption is gone! Then, both Py2 and Py3
die. Then, you will be forced to use another language? 

  GOT IT?

This is *NOT* about you, or me, this is about the
*PERCEPTION* of Python within the *ENTIRE* programming
community.

 are you still too busy working on your fork, RickedPython?  

I've never seen you before. Are you a regular hiding behind
a fake name?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?

2015-07-19 Thread breamoreboy

On Monday, July 20, 2015 at 1:49:58 AM UTC+1, Rick Johnson wrote:
 On Sunday, July 19, 2015 at 7:28:28 PM UTC-5, Mark Lawrence wrote:
 
  Thank goodness for that as you make no sense at all. As
  for this ivory tower nonsense, [...]
 
 Cecil, don't pay too much attention to Mark, he's a glory
 hound. He's like the Python community version of Cerberus --
 you know, the three headed dog guarding the entrance to the
 Greek underworld. 
 
 Every time i defeat him, and drag him out through an opening in
 the caverns of code, and take him to a secret grove owned
 by D'Aprano, he always escapes and returns to guard the
 entrance again -- he's very loyal!
 
 He won't allow you to enter because you're still alive, and
 as such, you still have the capacity to feel emotions like
 compassion. These emotions are forbidden in the underworld!!!
 
 But don't worry, his bark is worse than his bite, and he is
 just the first of many daemons you must defeat on your quest
 to challenge the benevolent Hades.

Gosh you don't half spout some rubbish.  Your total number of victories over me 
is zero, although I personally come here to give or get knowledge, not look for 
such things.

As for the cobblers about Cerburus and challenging the benevolent Hades would 
you be kind enough to:-

a) list just how many Python bugs you have worked on

b) state how much work you intend doing on the planned core workflow 
improvements

For the latter you can find the relevant PEPs easily enough for yourself, or 
just like Cecil do you expect someone to do that for you as well?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?

On Monday, July 20, 2015 at 7:16:50 AM UTC+5:30, Mark Lawrence wrote:
On 20/07/2015 02:20, Devin Jeanpierre wrote:

A couple of things.

First some core devs are hostile, actually some have stated that
they're simply not interested in 2.7 and will not work on it.

Second how has the thread got here, as it was originally asking about
back porting bug fixes from 3.x to 2.7? Further it said:-

quote
If the vast majority of Python programmers are focused on 2.7, why are
volunteers to help fix 2.7 bugs so scarce?
/quote

So I most humbly suggest, as I may have hinted at once or twice earlier
in this thread, that people either put up or shut up.

I just ran the following command
$ hg log --template {author|person}\n | sort | uniq -c | sort -nr

So... May I humbly ask where are your precious commits??

List of python committers:
-
11081 Guido van Rossum
6172 Fred Drake
6120 Georg Brandl
5603 Benjamin Peterson
4077 Raymond Hettinger
3874 Victor Stinner
3774 Antoine Pitrou
3157 Jack Jansen
3089 Martin v. Löwis
2668 Tim Peters
2372 Serhiy Storchaka
2219 Andrew M. Kuchling
2205 Barry Warsaw
2038 Ezio Melotti
2016 Neal Norwitz
2009 Mark Dickinson
1966 Brett Cannon
1307 R David Murray
1180 Christian Heimes
1159 Senthil Kumaran
1108 Gregory P. Smith
1075 Éric Araujo
1071 Vinay Sajip
1065 Jeremy Hylton
903 Tarek Ziadé
872 Greg Ward
871 Thomas Heller
780 R. David Murray
777 Terry Jan Reedy
728 Skip Montanaro
695 Nick Coghlan
687 Ned Deily
581 Ronald Oussoren
579 Walter Dörwald
527 Kurt B. Kaiser
519 Michael W. Hudson
511 Amaury Forgeot d'Arc
481 Stefan Krah
450 Andrew Svetlov
432 Thomas Wouters
423 Zachary Ware
422 Anthony Baxter
403 Brian Curtin
400 Florent Xicluna
387 Eli Bendersky
383 Eric Smith
370 Hirokazu Yamamoto
364 Charles-François Natali
362 Alexander Belopolsky
354 Just van Rossum
344 Marc-André Lemburg
340 Alexandre Vassalotti
334 Michael Foord
317 Neil Schemenauer
314 Fredrik Lundh
293 Jesus Cea
285 Sandro Tosi
282 Larry Hastings
264 Yury Selivanov
260 Matthias Klose
259 Berker Peksag
239 Richard Oudkerk
233 Nadeem Vawda
202 Kristján Valur Jónsson
189 Petri Lehtinen
174 Collin Winter
166 Lars Gustäbel
163 Hye-Shik Chang
159 Mark Hammond
159 Facundo Batista
156 Armin Rigo
154 Andrew MacIntyre
153 Steve Dower
153 doko
153 Chris Jerdonek
152 Sjoerd Mullender
123 Łukasz Langa
121 cvs2svn
118 Giampaolo Rodolà
112 Andrew Kuchling
109 Guilherme Polo
109 Giampaolo Rodola'
106 Eric Snow
102 Ka-Ping Yee
101 Meador Inge
101 Jesse Noller
101 Jason R. Coombs
97 Trent Nelson
97 Steven M. Gava
96 Hynek Schlawack
93 Tim Golden
93 Eric S. Raymond
91 Ethan Furman
87 Moshe Zadka
87 Johannes Gijsbers
87 Jeffrey Yasskin
79 Roger E. Masse
77 Ross Lagerwall
67 Donald Stufft
65 George Yoshida
63 Phillip J. Eby
63 Philip Jenvey
62 Gustavo Niemeyer
59 Jeroen Ruigrok van der Werven
58 Steven Bethard
51 Eric V. Smith
50 Roger Serwy
46 Bob Ippolito
45 Terry Reedy
45 Peter Schneider-Kamp
45 Gerhard Häring
42 Tarek Ziade
42 Edward Loper
40 Peter Astrand
39 Alex Martelli
38 Daniel Stutzbach
37 Sean Reifscheider
37 Jason Tishler
36 Bill Janssen
34 Trent Mick
34 Piers Lauder
33 Jack Diederich
31 Mark Summerfield
31 Jim Fulton
29 Greg Stein
28 Nicholas Bastin
27 Andrew McNamara
23 Robert Schuppenies
23 Josiah Carlson
22 Vladimir Marangozov
21 Kristjan Valur Jonsson
21 Brian Quinlan
20 Paul Prescod
18 Tony Lownds
18 Steve Purcell
18 Andrew Dalke
17 Finn Bock
17 David Wolever
16 Steve Holden
16 Robert Collins
16 Jean-Paul Calderone
16 Charles-Francois Natali
15 Žiga Seilnacht
15 David Malcolm
15 Armin Ronacher
14 Travis E. Oliphant
14 Tal Einat
14 Richard

Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?]

2015-07-19 Thread MRAB


On 2015-07-19 22:16, Chris Angelico wrote:

On Mon, Jul 20, 2015 at 5:55 AM, Tim Chase
python.l...@tim.thechases.com wrote:

On 2015-07-20 04:07, Chris Angelico wrote:

The int() and float() functions accept, if I'm not mistaken,
anything with Unicode category Nd (Number, decimal digit). In
your examples, the fraction (U+215B) is No, and the Roman numerals
(U+2168, U+2182) are Nl, so they're not supported. Adding support
for these forms might be accepted as a feature request, but it's
not a bug.


Ah, that makes sense.  Some simple testing (thanks, unicodedata
module) supports your conjecture.

It's not a particularly big deal so not really worth the brain-cycles
to add support for them.  Just upon hearing Python's int() does
smart things with Unicode characters, those were some of my first
characters to try.  The failure struck me as odd until you explained
the simple difference.


The other part of the problem is: What should float(2⅛3) be? Should
it be equal to 21.0/83.0? Should the first part be parsed as a classic
mixed number (2 + 1/8), and then what should the 3 mean? While it's
easy to see what an individual character should represent (just check
unicodedata.numeric(ch) - for ⅛ it's 0.125), the true meaning of a
string of such characters is less than clear. Similarly, Roman
numerals aren't meant to be used after the decimal point, so Ⅸ.Ⅴ
does not normally mean nine and a half... not to mention the confusing
situation that ⅠⅤ would naively parse as 15 but Ⅳ is definitely 4.
Since these kinds of complexities exist, it's safest to reserve this
level of parsing for a special-purpose function. If someone can come
up with a really strong argument for the float() and int()
constructors interpreting these, I'd expect to see it deployed as a
third-party module first, before being pointed out as see, you can
use float() for all these, but if you want to use those, you should
use Float() instead. (Incidentally, I fully expect to see, some day,
pytz.localize() semantics brought into the standard library
datetime.datetime class, for precisely this reason.)

Unicode is awesome, but it's not a panacea :)


What's the result of, say, float('1e.3')?

It raises an exception.

So float(2⅛3) should also raise an exception.

--
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?

On Sunday 19 Jul 2015 22:28 CEST, Mark Lawrence wrote:

 On 19/07/2015 21:05, Cecil Westerhof wrote:
 On Sunday 19 Jul 2015 21:01 CEST, Ian Kelly wrote:

 On Sun, Jul 19, 2015 at 10:10 AM, Cecil Westerhof ce...@decebal.nl wrote:
 On Sunday 19 Jul 2015 15:42 CEST, Mark Lawrence wrote:

 On 19/07/2015 03:13, Terry Reedy wrote:
 On 7/18/2015 7:50 PM, Devin Jeanpierre wrote:
 to 2.7, surely bug fixes are also allowed?

 Of course, allowed. But should they be made, and if so, by who?

 The people who want the fixes.

 Babies want clean diapers. So babies have to change diapers
 themselves?

 Poor analogy. Babies need others to change their diapers for them
 because they're not capable of doing it for themselves.

 That is why I think it is good analogy. I think that most of the
 users of 2.7 who would be delighted with fixes would have no idea
 how to get those fixes into 2.7.


 They could try reading the development guide to start with, or is
 that also too much to ask?

My impression is that you and some other people are in an ivory tower
and find it very cosy.

It reminds me about the man on dry land who responded to the person
who fell in water and shouted
“Help, I cannot swim!”
with
“Why are you screaming?
 I cannot swim also.
 Do you hear me yelling about it?

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?]


On 7/19/2015 3:32 AM, Rustom Mody wrote:


Unix bc:
$ bc
bc 1.06.95
Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'.
4+5
9
obase=8
4+5
11

IOW bc has two (global) variables ibase and obase for input and output base.
If you dont provide these as settable you hardwire them at 10 (8/16 in some
assembly languages)¹

Hopefully you will agree that python is more full-featured than bc and should
subsume bc functionality?


Nice try ;-) However, I think is not especially relevant.  I do not 
believe that Guido would agree that bc should govern python design. Do 
*you* really think that?  Python is fundamentally a general purpose 
batch-mode language.  Interactive mode is secondary and generally 
subservient to writing real programs.  I know that he has said that he 
is not inclined to add additional interactive-mode-only features to Python.


--
Terry Jan Reedy


--
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?

2015-07-19 Thread Devin Jeanpierre

On Sat, Jul 18, 2015 at 9:45 PM, Steven D'Aprano st...@pearwood.info wrote:
 It gets really boring submitting 2.7-specific patches, though, when
 they aren't accepted, and the committers have such a hostile attitude
 towards it. I was told by core devs that, instead of fixing bugs in
 Python 2, I should just rewrite my app in Python 3.

 Really? Can you point us to this discussion?

Yes, really. It was on #python-dev IRC.

 If you are right, and that was an official pronouncement, then it seems that
 non-security bug fixes to 2.7 are forbidden.

I never said it was a pronouncement, or official. It wasn't. I have no
idea where you got that idea from, given that I specifically have said
that I think non-security bug fixes are allowed.

 I suspect though that it's not quite that black and white. Perhaps there was
 some doubt about whether or not the patch in question was fixing a bug or
 adding a feature (a behavioural change). Or the core dev in question was
 speaking for themselves, not for all.

They weren't speaking for all. And, I never said they were. Nor did I
imply that they were.

Search your logs for https://bugs.python.org/issue17094 and
http://bugs.python.org/issue5315

I was most frustrated by the first case -- the patch was (informally)
rejected in favor of the right fix, and the right fix was
(informally) rejected because it changed behavior, leaving me only
with the option of absurd workarounds of a bug in Python, or moving to
python 3.

 It has even been
 implied that bugs in Python 2 are *good*, because that might help with
 Python 3 adoption.

 Really? Can you point us to this discussion?

 As they say on Wikipedia, Citation Needed. I would like to see the context
 before taking that at face value.

Of course, it was a joke. The format of the joke goes like this:
people spend a lot of time debugging and writing bugfixes for Python
2.7, and you say:

  dev2 guido wants all python 3 features in python 2, so ssbr` maybe
choose the right time to ask a backport ;-)
  dev1 oh. if i would be paid to contribute to cpython, i would
probably be ok to backport anything from python 3 to python 2
  dev1 since i'm not paid for that, i will to kill python 2, it must
suffer a lot

And that's about as close to logs as I am comfortable posting. Grep
your logs for that, too.



I don't like how this is being redirected to surely you
misunderstood or I don't believe you. The fact that some core devs
are hostile to 2.x development is really bleedingly obvious, you
shouldn't need quotes or context thrown at you. The rhetoric almost
always shies _just_ short of ceasing bugfixes (until 2020, when that
abruptly becomes a cracking good idea). e.g. in 2.7 is here until
2020, please don't call it a waste.

I don't want to argue over who said what. I am sure everyone meant the
best, and I misunderstood them given a complicated context and a rough
day. Let's end this thread here, please.

-- Devin
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?

On Mon, 20 Jul 2015 06:21 am, breamore...@gmail.com wrote:

 All in all though I have to admit that overall it's a really onerous task.
  Once you've produced the patch you have to go to all the trouble of
 logging on to the issue tracker, finding the appropriate issue and
 uploading the patch.  You may even be inclined to make a comment.  In this
 case this entire process could take as much as two whole minutes.

It's very interesting that you ignore the two hardest parts of the process:

(1) Producing the patch in the first place.

(2) Convincing those with appropriate commit rights to accept the patch.


-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?

On Monday, July 20, 2015 at 6:19:58 AM UTC+5:30, Rick Johnson wrote:
 But don't worry, his bark is worse than his bite, and he is
 just the first of many daemons you must defeat on your quest
 to challenge the benevolent Hades.

Do you give lessons in rhetoric Rick?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?]

On Mon, Jul 20, 2015 at 5:55 AM, Tim Chase
python.l...@tim.thechases.com wrote:
 On 2015-07-20 04:07, Chris Angelico wrote:
 The int() and float() functions accept, if I'm not mistaken,
 anything with Unicode category Nd (Number, decimal digit). In
 your examples, the fraction (U+215B) is No, and the Roman numerals
 (U+2168, U+2182) are Nl, so they're not supported. Adding support
 for these forms might be accepted as a feature request, but it's
 not a bug.

 Ah, that makes sense.  Some simple testing (thanks, unicodedata
 module) supports your conjecture.

 It's not a particularly big deal so not really worth the brain-cycles
 to add support for them.  Just upon hearing Python's int() does
 smart things with Unicode characters, those were some of my first
 characters to try.  The failure struck me as odd until you explained
 the simple difference.

The other part of the problem is: What should float(2⅛3) be? Should
it be equal to 21.0/83.0? Should the first part be parsed as a classic
mixed number (2 + 1/8), and then what should the 3 mean? While it's
easy to see what an individual character should represent (just check
unicodedata.numeric(ch) - for ⅛ it's 0.125), the true meaning of a
string of such characters is less than clear. Similarly, Roman
numerals aren't meant to be used after the decimal point, so Ⅸ.Ⅴ
does not normally mean nine and a half... not to mention the confusing
situation that ⅠⅤ would naively parse as 15 but Ⅳ is definitely 4.
Since these kinds of complexities exist, it's safest to reserve this
level of parsing for a special-purpose function. If someone can come
up with a really strong argument for the float() and int()
constructors interpreting these, I'd expect to see it deployed as a
third-party module first, before being pointed out as see, you can
use float() for all these, but if you want to use those, you should
use Float() instead. (Incidentally, I fully expect to see, some day,
pytz.localize() semantics brought into the standard library
datetime.datetime class, for precisely this reason.)

Unicode is awesome, but it's not a panacea :)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?

On Monday 20 Jul 2015 00:51 CEST, Mark Lawrence wrote:

 On 19/07/2015 23:10, Cecil Westerhof wrote:
 On Sunday 19 Jul 2015 22:28 CEST, Mark Lawrence wrote:

 On 19/07/2015 21:05, Cecil Westerhof wrote:
 On Sunday 19 Jul 2015 21:01 CEST, Ian Kelly wrote:

 On Sun, Jul 19, 2015 at 10:10 AM, Cecil Westerhof ce...@decebal.nl 
 wrote:
 On Sunday 19 Jul 2015 15:42 CEST, Mark Lawrence wrote:

 On 19/07/2015 03:13, Terry Reedy wrote:
 On 7/18/2015 7:50 PM, Devin Jeanpierre wrote:
 to 2.7, surely bug fixes are also allowed?

 Of course, allowed. But should they be made, and if so, by
 who?

 The people who want the fixes.

 Babies want clean diapers. So babies have to change diapers
 themselves?

 Poor analogy. Babies need others to change their diapers for
 them because they're not capable of doing it for themselves.

 That is why I think it is good analogy. I think that most of the
 users of 2.7 who would be delighted with fixes would have no idea
 how to get those fixes into 2.7.


 They could try reading the development guide to start with, or is
 that also too much to ask?

 My impression is that you and some other people are in an ivory
 tower and find it very cosy.

 It reminds me about the man on dry land who responded to the person
 who fell in water and shouted
 “Help, I cannot swim!”
 with
 “Why are you screaming?
 I cannot swim also.
 Do you hear me yelling about it?


 You are now suggesting that people shouldn't even bother reading the
 develoment guide, just great. Do they have to do anything themselves
 to get patches through? Presumably the core devs give up their paid
 work, holidays, families, other hobbies and the like, just so some
 bunch of lazy, bone idle gits can get what they want, for nothing,
 when it suits them? It appears that babies aren't the only people
 who need their nappies changing around here.

No use replying anymore. You make a caricature of what I am saying and
put words in my mouth I never said. Just stay in your cosy ivory
tower. But please do not pretend that you are open for discussion,
because you are not.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?]

2015-07-19 Thread Tim Chase

On 2015-07-19 14:45, Steven D'Aprano wrote:
 ie we can now do
 १ + २  
 3  
 
 That is actually quite awesome, and I would support a new feature
 that set the numeric characters to a particular script, e.g. Latin,
 Arabic, Devanagari, whatever, and printed them in that same script.
 It seems unfortunate that १ + २ prints as 3 rather than ३.
 
 Python already, and has for many years, supported non-ASCII digits
 in string conversions. This is in Python 2.4:
 
 py int(u'१२')  
 12
 py float(u'.१२')  
 0.12
 
 so the feature goes back a long time.

Agreed that it's pretty awesome.  It seems to have some holes though:

Python 3.4.2 (default, Oct  8 2014, 10:45:20) 
[GCC 4.9.1] on linux
Type help, copyright, credits or license for more information.
 print('\N{VULGAR FRACTION ONE EIGHTH}')
⅛
 print(float('\N{VULGAR FRACTION ONE EIGHTH}'))
Traceback (most recent call last):
  File stdin, line 1, in module
ValueError: could not convert string to float: '⅛'
 print('\N{ROMAN NUMERAL NINE}')
Ⅸ
 int('\N{ROMAN NUMERAL NINE}')
Traceback (most recent call last):
  File stdin, line 1, in module
ValueError: invalid literal for int() with base 10: 'Ⅸ'
 print('\N{ROMAN NUMERAL TEN THOUSAND}')
ↂ
 int('\N{ROMAN NUMERAL TEN THOUSAND}')
Traceback (most recent call last):
  File stdin, line 1, in module
ValueError: invalid literal for int() with base 10: 'ↂ'

-tkc




-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?

On Sunday, July 19, 2015 at 12:55:06 PM UTC-5, Mark Lawrence wrote:
 I don't think so, I know.  If they want the patches that
 badly and can't do it themselves they'll have to grin and
 bear it, or do a bit of begging, or pay somebody to do it
 for them. 

It's all about the effing money then? So the barriers are not a
bug, but a feature? Mr. Gates would be *SO* proud!


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?

On Sunday, July 19, 2015 at 2:02:12 PM UTC-5, Ian wrote:
 Poor analogy. Babies need others to change their diapers
 for them because they're not capable of doing it for
 themselves.

Duh! That was the point of his analogy, Ian. *ALL* Python
programmers need the patches. Whether or not they possess
the skill to create them is irrelevant.

But the baby is not the only victim if the diapers are not
changed. Imagine the foul odors that rumors of bugginess
will emit into the household, and if unchecked long enough,
out into the neighborhood.

A some point a social worker will be dispatched, and the
baby will be taken away to a home that provides the
necessary sanitary conditions. But not before the parents
will be thrown in prison, ridiculed, and forgotten. The end
result is a broken family Ian.

Is any of this sinking in?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?

2015-07-19 Thread Ian Kelly

On Sun, Jul 19, 2015 at 3:27 AM, Laura Creighton l...@openend.se wrote:
 In this corner of the world, the favourite language for developing in
 is C (because we work close to hardware) and one of the things we like
 about it, a whole lot, is that the language never changes out from
 under you.  So there is great hope among industrial users of Python
 that we can get a hold of a 'never going to change any more' version
 of Python, and then code in that 'forever' knowing that a code change
 isn't going to come along and break all our stuff.

I think this is an unrealistic and unattainable goal. Even if you stop
patching your Python 2.7 version altogether, what about the
environment that it runs in? Are you going to stop patching the OS
forever? Are you going to fix the current machine architecture exactly
as it is, forever? I don't know if industrial code uses a network much
or at all, but if it does, are you never going to upgrade your network
infrastructure?

At some point in the future, maybe far in the future, but eventually,
assumptions made in the Python 2.7 code will no longer hold true, and
at that point Python 2.7 will break.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?

On Sunday, July 19, 2015 at 1:44:25 PM UTC-5, bream...@gmail.com wrote:
 No, it's simply that nobody can force volunteers to back
 port something when they're just not interested in doing
 the work, for whatever reason.  Hence my statement above,
 of which you have focused on the last eight words.

Well i argue that the free labor *WOULD* exists *IF* the
patching mechanism were more inclusive and intuitive.

PS: My apologies to Mark Lawrence for mis-attributing the 
quote to him. I seem to be having a bad quote day.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?

On Sunday 19 Jul 2015 21:01 CEST, Ian Kelly wrote:

 On Sun, Jul 19, 2015 at 10:10 AM, Cecil Westerhof ce...@decebal.nl wrote:
 On Sunday 19 Jul 2015 15:42 CEST, Mark Lawrence wrote:

 On 19/07/2015 03:13, Terry Reedy wrote:
 On 7/18/2015 7:50 PM, Devin Jeanpierre wrote:
 to 2.7, surely bug fixes are also allowed?

 Of course, allowed.  But should they be made, and if so, by who?

 The people who want the fixes.

 Babies want clean diapers. So babies have to change diapers
 themselves?

 Poor analogy. Babies need others to change their diapers for them
 because they're not capable of doing it for themselves.

That is why I think it is good analogy. I think that most of the users
of 2.7 who would be delighted with fixes would have no idea how to get
those fixes into 2.7.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?


On 19/07/2015 21:05, Cecil Westerhof wrote:

On Sunday 19 Jul 2015 21:01 CEST, Ian Kelly wrote:


On Sun, Jul 19, 2015 at 10:10 AM, Cecil Westerhof ce...@decebal.nl wrote:

On Sunday 19 Jul 2015 15:42 CEST, Mark Lawrence wrote:


On 19/07/2015 03:13, Terry Reedy wrote:

On 7/18/2015 7:50 PM, Devin Jeanpierre wrote:

to 2.7, surely bug fixes are also allowed?


Of course, allowed.  But should they be made, and if so, by who?


The people who want the fixes.


Babies want clean diapers. So babies have to change diapers
themselves?


Poor analogy. Babies need others to change their diapers for them
because they're not capable of doing it for themselves.


That is why I think it is good analogy. I think that most of the users
of 2.7 who would be delighted with fixes would have no idea how to get
those fixes into 2.7.



They could try reading the development guide to start with, or is that 
also too much to ask?


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

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?

On Sunday 19 Jul 2015 18:38 CEST, Mark Lawrence wrote:

 On 19/07/2015 17:10, Cecil Westerhof wrote:
 On Sunday 19 Jul 2015 15:42 CEST, Mark Lawrence wrote:

 On 19/07/2015 03:13, Terry Reedy wrote:
 On 7/18/2015 7:50 PM, Devin Jeanpierre wrote:
 to 2.7, surely bug fixes are also allowed?

 Of course, allowed.  But should they be made, and if so, by who?

 The people who want the fixes.

 Babies want clean diapers. So babies have to change diapers
 themselves?


 That has to be the worst analogy I've ever read.  We are discussing
 backporting working patches, *NOT* having to go through the whole
 shooting match from scratch.

You think so? I think that a lot of people who are using 2.7 would
like to have the fixes. They know how to use Python, but they would
not now how to implement a patch. That is why I made this comment.

Comments are (almost) always an exaggeration. When someone tells me:
“I have been 1.000 times to the store to get my money back”, most of
the time I would not take this literally, but understand it means very
often.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?

2015-07-19 Thread Ian Kelly

On Sun, Jul 19, 2015 at 10:10 AM, Cecil Westerhof ce...@decebal.nl wrote:
 On Sunday 19 Jul 2015 15:42 CEST, Mark Lawrence wrote:

 On 19/07/2015 03:13, Terry Reedy wrote:
 On 7/18/2015 7:50 PM, Devin Jeanpierre wrote:
 to 2.7, surely bug fixes are also allowed?

 Of course, allowed.  But should they be made, and if so, by who?

 The people who want the fixes.

 Babies want clean diapers. So babies have to change diapers
 themselves?

Poor analogy. Babies need others to change their diapers for them
because they're not capable of doing it for themselves.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?


On 7/18/2015 10:33 PM, Devin Jeanpierre wrote:

On Sat, Jul 18, 2015 at 6:34 PM, Terry Reedy tjre...@udel.edu wrote:

On 7/18/2015 8:27 PM, Mark Lawrence wrote:

On 19/07/2015 00:36, Terry Reedy wrote:
Programmers don't much like doing maintainance work when they're paid to
do it, so why would they volunteer to do it?


Right.  So I am asking: if a 3.x user volunteers a 3.x patch and a 3.x core
developer reviews and edits the patch until it is ready to commit, why
should either of them volunteer to do a 2.7 backport that they will not use?


Because it helps even more people.


Writing another 3.x patch would also help other people and might be more 
'fun'.  That is the situation I am in with respect to Idle.



It gets really boring submitting 2.7-specific patches, though, when
they aren't accepted, and the committers have such a hostile attitude
towards it. I was told by core devs that, instead of fixing bugs in
Python 2, I should just rewrite my app in Python 3. It has even been
implied that bugs in Python 2 are *good*, because that might help with
Python 3 adoption.


Like Steven, I would be interested in specifics, though I do not 
disbelieve you.  I do not believe those two attitudes are exactly 
official policy, and I may request more discussion of them on pydev.



Then even if you do the
work to fix *ANY* bug there is no guarantee that it gets committed.


I am discussing the situation where there *is* a near guarantee (if the
backport works and does not break anything and has not been so heavily
revised as to require a separate review).


That is not how I have experienced contribution to CPython.


I know.  Some core developers are trying to revamp the issue-patch 
handling process to remove some of the busywork, use our time more 
efficiency, and make it work more smoothly for everyone.


But let me try again.  I am discussing a situation where a core 
developer has either requested or already agreed to apply a 2.7 
backport.  I have seen such in the past, but maybe this is now rare.


I specifically would like to be able to request backports for Idle 
patches and get responses.  When requested, I really would apply 
responses that worked.  Really.


But I now realized that most people would rather write a patch, on their 
own schedule, for an issue that bugs them, and perhaps use it locally, 
even if rejected for the repository, than write a guaranteed patch 
'right now for a issue of no interest to them (and which might require 
python knowledge they do not have).



If the issue was closed as fixed before I contributed the backported
patch, does anyone even see it?


Yes.  All changes on as issue, including uploads, are emailed to all on 
the nosy list regardless of open/closed/... status.  However, I would 
inquire first.  If I backport the committed bugfix to 2.7, would you 
apply it?


--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?

In a message of Sun, 19 Jul 2015 23:59:29 +1000, Steven D'Aprano writes:

Bug for bug compatible back to the 1970s, right? :-)

No, till the last posix in 1989 or so.  Definitely not to the 1970s
as we want v7 c structs and x++ not the v6 ++x version.

:)

Laura
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?]

2015-07-19 Thread Tim Chase

On 2015-07-20 04:07, Chris Angelico wrote:
 The int() and float() functions accept, if I'm not mistaken,
 anything with Unicode category Nd (Number, decimal digit). In
 your examples, the fraction (U+215B) is No, and the Roman numerals
 (U+2168, U+2182) are Nl, so they're not supported. Adding support
 for these forms might be accepted as a feature request, but it's
 not a bug.

Ah, that makes sense.  Some simple testing (thanks, unicodedata
module) supports your conjecture.

It's not a particularly big deal so not really worth the brain-cycles
to add support for them.  Just upon hearing Python's int() does
smart things with Unicode characters, those were some of my first
characters to try.  The failure struck me as odd until you explained
the simple difference.

-tkc




-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?

In a message of Sun, 19 Jul 2015 23:59:29 +1000, Steven D'Aprano writes:
On Sun, 19 Jul 2015 07:27 pm, Laura Creighton wrote:

 In the tiny corner of industrial automation where I do a lot of work,
 nobody is using 3.0.

I should hope not, because 3.0 was rubbish and is unsupported :-)

I expect you mean 3.x in general.

indeed.  Or should I be saying Python 3000.

Bug for bug compatible back to the 1970s, right? :-)

Exactly.

 So there is great hope among industrial users of Python 
 that we can get a hold of a 'never going to change any more' version
 of Python, and then code in that 'forever' knowing that a code change
 isn't going to come along and break all our stuff.

Presumably they like the 2.7 features too much to go back to an even older
version. Because 2.5 or even 1.5 are pretty stable now.

I'm not kidding about 1.5, a year or two ago there was (so I'm told) a
fellow at PyCon in the US who was still using 1.5. If it ain't broke,
don't fix it -- he wasn't concerned about security updates, or new
features, he just needed to keep his legacy applications running.

I have 1.5 code out there.  Unless something breaks there is
no way that I will get permission to ever change it.

I get it, I really do, and so do the core developers. (Well, most of them,
and certainly Guido.) It cannot be said often enough and loudly enough that
if you find yourself in the lucky position where you don't need to care
about security updates, bug fixes or new functionality, there is absolutely
nothing wrong with using an old, unmaintained, stable version forever.

Well, Terry asked.

In my corner of the world -- well, iterators are cool.  Though a
ton of my code broke when we got a 'yield' keyword, as I had used
that as a function name all over the place ...  But aside from
that, pretty much nothing post 1.5.2 really made a difference for
us.  Some bugs in struct got fixed, and that was nice, but, well
on the whole we'd like stone cold dead.
-- 
Steven

Laura

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?

On Sunday 19 Jul 2015 15:42 CEST, Mark Lawrence wrote:

 On 19/07/2015 03:13, Terry Reedy wrote:
 On 7/18/2015 7:50 PM, Devin Jeanpierre wrote:
 to 2.7, surely bug fixes are also allowed?

 Of course, allowed.  But should they be made, and if so, by who?

 The people who want the fixes.

Babies want clean diapers. So babies have to change diapers
themselves?

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?]

On Sun, Jul 19, 2015 at 10:56 PM, Tim Chase
python.l...@tim.thechases.com wrote:
 Agreed that it's pretty awesome.  It seems to have some holes though:

 Python 3.4.2 (default, Oct  8 2014, 10:45:20)
 [GCC 4.9.1] on linux
 Type help, copyright, credits or license for more information.
 print('\N{VULGAR FRACTION ONE EIGHTH}')
 ⅛
 print(float('\N{VULGAR FRACTION ONE EIGHTH}'))
 Traceback (most recent call last):
   File stdin, line 1, in module
 ValueError: could not convert string to float: '⅛'
 print('\N{ROMAN NUMERAL NINE}')
 Ⅸ
 int('\N{ROMAN NUMERAL NINE}')
 Traceback (most recent call last):
   File stdin, line 1, in module
 ValueError: invalid literal for int() with base 10: 'Ⅸ'
 print('\N{ROMAN NUMERAL TEN THOUSAND}')
 ↂ
 int('\N{ROMAN NUMERAL TEN THOUSAND}')
 Traceback (most recent call last):
   File stdin, line 1, in module
 ValueError: invalid literal for int() with base 10: 'ↂ'

The int() and float() functions accept, if I'm not mistaken, anything
with Unicode category Nd (Number, decimal digit). In your examples,
the fraction (U+215B) is No, and the Roman numerals (U+2168, U+2182)
are Nl, so they're not supported. Adding support for these forms might
be accepted as a feature request, but it's not a bug.

(I may be wrong about the definition being based on category. It may
be based on the Numeric type of each character. But again, the
characters that are accepted would be those which have a Digit type,
not merely Numeric, and again, it'd be a feature request to expand
that.)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Should non-security 2.7 bugs be fixed?