f



Python 3 is killing Python

--047d7bfceec297d37804fa7abe05
Content-Type: text/plain; charset=UTF-8

Somthing I came across in my travels through the ether:

https://medium.com/@deliciousrobots/5d2ad703365d/

--047d7bfceec297d37804fa7abe05
Content-Type: text/html; charset=UTF-8

<div dir="ltr"><div>Somthing I came across in my travels through the ether:<br></div><div><br></div><a href="https://medium.com/@deliciousrobots/5d2ad703365d/" target="_blank">https://medium.com/@deliciousrobots/5d2ad703365d/</a><br>
</div>

--047d7bfceec297d37804fa7abe05--
0
Larry
5/28/2014 7:23:17 PM
comp.lang.python 77058 articles. 6 followers. Post Follow

312 Replies
4241 Views

Similar Articles

[PageSpeed] 57

On 28/05/2014 20:58, Larry Martell wrote:
> On Wed, May 28, 2014 at 2:49 PM, Paul Rubin <no.email@nospam.invalid
> <mailto:no.email@nospam.invalid>> wrote:
>
>     Larry Martell <larry.martell@gmail.com
>     <mailto:larry.martell@gmail.com>> writes:
>      > Somthing I came across in my travels through the ether:
>      > [1]https://medium.com/@deliciousrobots/5d2ad703365d/
>
>     "Python 3 can revive Python" https://medium.com/p/2a7af4788b10
>        long HN comment thread: https://news.ycombinator.com/item?id=7801834
>
>     "Python 3 is fine" http://sealedabstract.com/rants/python-3-is-fine/
>
>     OT: wow that medium site is obnoxious.
>
>
> No company that I work for is using python 3 - they just have too much
> of an investment in a python 2 code base to switch. I'm just saying.
>

So you're happy because you've support until at least 2020, and the 
people using Python 3 are happy, mainly because of the vastly improved 
unicode handling via the FSR and asyncio in 3.4.  Presumably the only 
unhappy people are those who keep bleating on about forking Python to 
produce a 2.8, or has work on this already started without my knowledge?

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

Mark Lawrence

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


0
Mark
5/28/2014 1:01:01 AM
On 28.05.2014 21:23, Larry Martell wrote:
> Somthing I came across in my travels through the ether:
> 
> https://medium.com/@deliciousrobots/5d2ad703365d/

Sub-headline "The Python community should fork Python 2". Which could
also read "Someone else should REALLY fork Py2 because I'm mad about Py3
yet too lazy to fork Py2 myself".

I wish all these ridiculous dumb whiners would finally shut up and fork
Python away. That would be win-win: They could use their fork of 2.4
forever and ever, maybe fork 1.4 too while they're at it. Then maintain
it. Above all: They would complain to each other and stay away from the
mailing lists of people who actually *embrace* progress and who
appreciate the wonderful features Py3 has given us.

What a wonderful world it would be. So, I agree with the above blogpost.
Some lazy blogwriting bum should fork Py2!

Cheers,
Johannes

-- 
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
 - Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org>
0
Johannes
5/28/2014 7:39:08 PM
I agree that Py3 made a grave error in breaking backward-compatibility.
However, that's the reality and the transition will take place over
time, possibly even before IPv6 overtakes IPv4 in popularity.

But then, I was never really beholden to third-party libraries and
frameworks. Instead, the batteries-included philosophy still has a great
appeal to me.


Marko
0
Marko
5/28/2014 7:41:22 PM
Larry Martell <larry.martell@gmail.com> writes:
> Somthing I came across in my travels through the ether:
> [1]https://medium.com/@deliciousrobots/5d2ad703365d/

"Python 3 can revive Python" https://medium.com/p/2a7af4788b10
  long HN comment thread: https://news.ycombinator.com/item?id=7801834

"Python 3 is fine" http://sealedabstract.com/rants/python-3-is-fine/

OT: wow that medium site is obnoxious.
0
Paul
5/28/2014 7:49:59 PM
--f46d0442685a13c50a04fa7b3bcc
Content-Type: text/plain; charset=UTF-8

On Wed, May 28, 2014 at 2:49 PM, Paul Rubin <no.email@nospam.invalid> wrote:

> Larry Martell <larry.martell@gmail.com> writes:
> > Somthing I came across in my travels through the ether:
> > [1]https://medium.com/@deliciousrobots/5d2ad703365d/
>
> "Python 3 can revive Python" https://medium.com/p/2a7af4788b10
>   long HN comment thread: https://news.ycombinator.com/item?id=7801834
>
> "Python 3 is fine" http://sealedabstract.com/rants/python-3-is-fine/
>
> OT: wow that medium site is obnoxious.
>

No company that I work for is using python 3 - they just have too much of
an investment in a python 2 code base to switch. I'm just saying.

--f46d0442685a13c50a04fa7b3bcc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, May 28, 2014 at 2:49 PM, Paul Rubin <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:no.email@nospam.invalid" target=3D"_blank">no.email@nospam.invalid</a>=
&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Larry Martell &lt;<a href=3D"mailto:larry.ma=
rtell@gmail.com">larry.martell@gmail.com</a>&gt; writes:<br>
&gt; Somthing I came across in my travels through the ether:<br>
&gt; [1]<a href=3D"https://medium.com/@deliciousrobots/5d2ad703365d/" targe=
t=3D"_blank">https://medium.com/@deliciousrobots/5d2ad703365d/</a><br>
<br>
&quot;Python 3 can revive Python&quot; <a href=3D"https://medium.com/p/2a7a=
f4788b10" target=3D"_blank">https://medium.com/p/2a7af4788b10</a><br>
=C2=A0 long HN comment thread: <a href=3D"https://news.ycombinator.com/item=
?id=3D7801834" target=3D"_blank">https://news.ycombinator.com/item?id=3D780=
1834</a><br>
<br>
&quot;Python 3 is fine&quot; <a href=3D"http://sealedabstract.com/rants/pyt=
hon-3-is-fine/" target=3D"_blank">http://sealedabstract.com/rants/python-3-=
is-fine/</a><br>
<br>
OT: wow that medium site is obnoxious.<br></blockquote><div><br></div><div>=
No company that I work for is using python 3 - they just have too much of a=
n investment in a python 2 code base to switch. I&#39;m just saying.=C2=A0<=
/div>
</div></div></div>

--f46d0442685a13c50a04fa7b3bcc--
0
Larry
5/28/2014 7:58:05 PM
On Thu, May 29, 2014 at 5:58 AM, Larry Martell <larry.martell@gmail.com> wrote:
> No company that I work for is using python 3 - they just have too much of an
> investment in a python 2 code base to switch. I'm just saying.

And that's not a problem. Every whinging blog author seems to forget
that Python 2.7 support is going to continue for a long time! Yes, you
won't get new features. But the recommendation is "new and unfettered
projects should take advantage of Python 3", not "every Python 2
project needs to be ported". There've been some recent discussions
about exactly what security fixes and improvements can be backported;
the underlying guiding principle is "it's acceptable and expected that
there will be large, net-facing Python 2 applications for the
foreseeable future".

Or maybe the complaint is that there are fancy new features in Python
3.x that aren't in 2.7? Oh wait, that directly contradicts the whine.
So if Python 3 has added nothing, what's the rush to move onto it?

Whiners gonna whine.

ChrisA
0
Chris
5/28/2014 8:15:45 PM
Larry Martell <larry.martell@gmail.com> writes:

> No company that I work for is using python 3 - they just have too much
> of an investment in a python 2 code base to switch.

There are many large companies still using FORTRAN and COBOL because of
a large investment in those languages, which are far more outdated than
Python 2. What's your point?

> I'm just saying.

Ah, so no point that you're willing to defend, then.

-- 
 \     “Books and opinions, no matter from whom they came, if they are |
  `\     in opposition to human rights, are nothing but dead letters.” |
_o__)                                                  —Ernestine Rose |
Ben Finney

0
Ben
5/28/2014 10:38:22 PM
Ben Finney <ben@benfinney.id.au> writes:
> There are many large companies still using FORTRAN and COBOL because of
> a large investment in those languages, which are far more outdated than
> Python 2. What's your point?

I think some of us see Python 2 as perfectly fine--we've looked into
Python 3 and found some minor improvements along with some minor
breakage, and figure it's not worth the cognitive burden of switching
from something that already works, even if Python 3 is slightly better
in the scheme of things.  

While I'm sure it will change over time, I currently don't actually know
anyone using Python 3 even for new projects.  I know *of* people using
Python 3 including here on this newsgroup, but I'm currently not
personally acquainted with any of them.
0
Paul
5/28/2014 11:22:29 PM
On 5/28/2014 3:49 PM, Paul Rubin wrote:
> Larry Martell <larry.martell@gmail.com> writes:
>> Somthing I came across in my travels through the ether:
>> [1]https://medium.com/@deliciousrobots/5d2ad703365d/
>
> "Python 3 can revive Python" https://medium.com/p/2a7af4788b10

This makes the same false claim "It=E2=80=99s not like anyone is using Py=
thon 3=20
anyway, (so go ahead and bread existing Py3 code". At least some of the=20
20+ million windows downloads must be in use.

>    long HN comment thread: https://news.ycombinator.com/item?id=3D78018=
34

One legitimate request is better installation of dependencies, which is=20
in progress. This is not a 2 versus 3 issue, unless there are 3-only=20
improvement.

Some want concurrency primitives like go has. Guido went for a new=20
module instead. I don't know what the importand differences are.

Some want a better REPL, including color. The Idle shell already has the =

syntax colorizing. I don't know what else might have been meant.

> "Python 3 is fine" http://sealedabstract.com/rants/python-3-is-fine/

In my opinion, about the best non-developer blog on Python 3 -- by a=20
sensible, satisfied user. "in March 2014 Python 3 downloads overtook=20
Python 2 downloads by a healthy margin 54% vs 46%." OK, that was boosted =

by the release of 3.4. But the point still stands.

--=20
Terry Jan Reedy


0
Terry
5/29/2014 1:57:16 AM
On Wed, 28 May 2014 14:58:05 -0500, Larry Martell wrote:

> On Wed, May 28, 2014 at 2:49 PM, Paul Rubin <no.email@nospam.invalid>
> wrote:
> 
>> Larry Martell <larry.martell@gmail.com> writes:
>> > Somthing I came across in my travels through the ether:
>> > [1]https://medium.com/@deliciousrobots/5d2ad703365d/
>>
>> "Python 3 can revive Python" https://medium.com/p/2a7af4788b10
>>   long HN comment thread: https://news.ycombinator.com/item?id=7801834
>>
>> "Python 3 is fine" http://sealedabstract.com/rants/python-3-is-fine/
>>
>> OT: wow that medium site is obnoxious.
>>
>>
> No company that I work for is using python 3 - they just have too much
> of an investment in a python 2 code base to switch. I'm just saying.

Is that Python 2 code base aimed at Python 2.7 or 2.6? Or 2.5? Or 2.4? Or 
even 2.3? Or all of the above?

One of the most pernicious myths about this is that there is one single 
Python 2 ecosystem. There isn't. The company I work for is stuck with 2.6 
for the foreseeable future, because that's the version of Python provided 
by the OS of choice. I recently migrated a client's code base from 2.3 to 
2.6, and they will likely stay with 2.6 forever. And I know of at least 
one company who is using Python 1.5 (yes, 1.5) and have no plans to 
migrate. 1.5 works for them, and they apparently don't need or don't care 
about security updates, so why should they migrate?

This is all good. If 2.x works for your application, and you don't care 
about all the awesome new features in 3.3+, don't care about bug fixes 
and security updates, and don't mind being stuck with a version of Python 
that will slowly but surely become more and more obsolete, more power to 
you.

The Python core developers have recent committed to providing security 
updates for 2.7 until 2020. And Redhat have paid support for 2.7 until 
2023. So there's no rush.

But anyone who makes that decision to stay with 2.x forever is in the 
same position as those who stay with 1.5 forever. Eventually, you'll have 
no OS support, no vendor support, no security updates, no bug fixes, it 
will become harder and harder to find programmers who know that 
particular version of the language, and even harder to find third party 
libraries that support it, training new staff in the obsolete version 
will be hard because all the books and tutorials will be written for more 
recent versions...

My prediction is:

- over the next three or four years, there will be a steady trickle of 
people complaining about Python 3, slowly fading as more people move to 
Python 3;

- when the main Linux distros start using Python 3 as their system 
Python, there will be a sudden rush of people to Python 3;

- about six months before Python 2 drops out of free support, there will 
be a sudden flood of panicky cries for help from people who didn't bother 
making a *single* step towards migration over the previous ten years, and 
suddenly realise that they need to migrate yesterday.



-- 
Steven
0
Steven
5/29/2014 3:49:50 AM
Steven D'Aprano <steve@pearwood.info> writes:
> The Python core developers have recent committed to providing security 
> updates for 2.7 until 2020. And Redhat have paid support for 2.7 until 
> 2023. So there's no rush.

Perhaps Python 4 will be out by then and the Python 2 holdouts can skip
over Python 3.

> - over the next three or four years, there will be a steady trickle of 
> people complaining about Python 3, slowly fading as more people move to 
> Python 3;
> - when the main Linux distros start using Python 3 as their system 
> Python, there will be a sudden rush of people to Python 3;

This is more realistic--people don't explicitly switch but rather the
stuff that comes with the OS changes.
0
Paul
5/29/2014 4:23:31 AM
Le mercredi 28 mai 2014 22:24:15 UTC+2, Mark Lawrence a =E9crit=A0:
> On 28/05/2014 20:58, Larry Martell wrote:
>=20
> > On Wed, May 28, 2014 at 2:49 PM, Paul Rubin <no.email@nospam.invalid
>=20
> > <mailto:no.email@nospam.invalid>> wrote:
>=20
> >
>=20
> >     Larry Martell <larry.martell@gmail.com
>=20
> >     <mailto:larry.martell@gmail.com>> writes:
>=20
> >      > Somthing I came across in my travels through the ether:
>=20
> >      > [1]https://medium.com/@deliciousrobots/5d2ad703365d/
>=20
> >
>=20
> >     "Python 3 can revive Python" https://medium.com/p/2a7af4788b10
>=20
> >        long HN comment thread: https://news.ycombinator.com/item?id=3D7=
801834
>=20
> >
>=20
> >     "Python 3 is fine" http://sealedabstract.com/rants/python-3-is-fine=
/
>=20
> >
>=20
> >     OT: wow that medium site is obnoxious.
>=20
> >
>=20
> >
>=20
> > No company that I work for is using python 3 - they just have too much
>=20
> > of an investment in a python 2 code base to switch. I'm just saying.
>=20
> >
>=20
>=20
>=20
> So you're happy because you've support until at least 2020, and the=20
>=20
> people using Python 3 are happy, mainly because of the vastly improved=20
>=20
> unicode handling via the FSR and asyncio in 3.4.  Presumably the only=20
>=20
> unhappy people are those who keep bleating on about forking Python to=20
>=20
> produce a 2.8, or has work on this already started without my knowledge?
>=20
>=20
>=20
> --=20
>=20
> My fellow Pythonistas, ask not what our language can do for you, ask=20
>=20
> what you can do for our language.
>=20
>=20
>=20
> Mark Lawrence
>=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Unicode: a reason to not use Python.

jmf
0
wxjmfauth
5/29/2014 6:14:46 AM
--f46d0442685a7404b704fa885ede
Content-Type: text/plain; charset=UTF-8

On Wed, May 28, 2014 at 10:49 PM, Steven D'Aprano <steve@pearwood.info>
wrote:

> On Wed, 28 May 2014 14:58:05 -0500, Larry Martell wrote:
>
> > On Wed, May 28, 2014 at 2:49 PM, Paul Rubin <no.email@nospam.invalid>
> > wrote:
> >
> >> Larry Martell <larry.martell@gmail.com> writes:
> >> > Somthing I came across in my travels through the ether:
> >> > [1]https://medium.com/@deliciousrobots/5d2ad703365d/
> >>
> >> "Python 3 can revive Python" https://medium.com/p/2a7af4788b10
> >>   long HN comment thread: https://news.ycombinator.com/item?id=7801834
> >>
> >> "Python 3 is fine" http://sealedabstract.com/rants/python-3-is-fine/
> >>
> >> OT: wow that medium site is obnoxious.
> >>
> >>
> > No company that I work for is using python 3 - they just have too much
> > of an investment in a python 2 code base to switch. I'm just saying.
>
> Is that Python 2 code base aimed at Python 2.7 or 2.6? Or 2.5? Or 2.4? Or
> even 2.3? Or all of the above?
>

One company is using 2.5. Another has been using 2.6 but they are moving to
2.7 because it's required by a package they need.  I think that will be the
driving force for companies to upgrade.

--f46d0442685a7404b704fa885ede
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, May 28, 2014 at 10:49 PM, Steven D&#39;Aprano <span dir=3D"ltr">&lt;<a =
href=3D"mailto:steve@pearwood.info" target=3D"_blank">steve@pearwood.info</=
a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">On Wed, 28 May 2014 14:58:05 -0500, Larry Ma=
rtell wrote:<br>
<br>
&gt; On Wed, May 28, 2014 at 2:49 PM, Paul Rubin &lt;no.email@nospam.invali=
d&gt;<br>
<div class=3D"">&gt; wrote:<br>
&gt;<br>
&gt;&gt; Larry Martell &lt;<a href=3D"mailto:larry.martell@gmail.com">larry=
..martell@gmail.com</a>&gt; writes:<br>
&gt;&gt; &gt; Somthing I came across in my travels through the ether:<br>
&gt;&gt; &gt; [1]<a href=3D"https://medium.com/@deliciousrobots/5d2ad703365=
d/" target=3D"_blank">https://medium.com/@deliciousrobots/5d2ad703365d/</a>=
<br>
&gt;&gt;<br>
&gt;&gt; &quot;Python 3 can revive Python&quot; <a href=3D"https://medium.c=
om/p/2a7af4788b10" target=3D"_blank">https://medium.com/p/2a7af4788b10</a><=
br>
</div><div class=3D"">&gt;&gt; =C2=A0 long HN comment thread: <a href=3D"ht=
tps://news.ycombinator.com/item?id=3D7801834" target=3D"_blank">https://new=
s.ycombinator.com/item?id=3D7801834</a><br>
&gt;&gt;<br>
</div><div class=3D"">&gt;&gt; &quot;Python 3 is fine&quot; <a href=3D"http=
://sealedabstract.com/rants/python-3-is-fine/" target=3D"_blank">http://sea=
ledabstract.com/rants/python-3-is-fine/</a><br>
&gt;&gt;<br>
</div>&gt;&gt; OT: wow that medium site is obnoxious.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt; No company that I work for is using python 3 - they just have too much=
<br>
&gt; of an investment in a python 2 code base to switch. I&#39;m just sayin=
g.<br>
<br>
Is that Python 2 code base aimed at Python 2.7 or 2.6? Or 2.5? Or 2.4? Or<b=
r>
even 2.3? Or all of the above?<br></blockquote><div><br></div><div>One comp=
any is using 2.5. Another has been using 2.6 but they are moving to 2.7 bec=
ause it&#39;s required by a package they need. =C2=A0I think that will be t=
he driving force for companies to upgrade.=C2=A0</div>
</div></div></div>

--f46d0442685a7404b704fa885ede--
0
Larry
5/29/2014 11:38:33 AM
On Wed, 28 May 2014 14:23:17 -0500, Larry Martell <larry.martell@gmail.com>
wrote:

>Somthing I came across in my travels through the ether:
>
>https://medium.com/@deliciousrobots/5d2ad703365d/

I just bought a new book on Python, since the one I had borrowed from my son
only dealt with Python 2.3, and everyone told me that was old. 

So I bought this book, and decided that whatever version of Python it deals
with, that's the one I will download and use.

The book is:

Cunningham, Katie. 2014. Teach yourself Python in 24 hours.
               Indianapolis: Sams.
               ISBN: 978-0-672-33687-4
                   For Python 2.7.5

I'll leave Python 3.2 on my computer, but 2.7.5 will be the one I'm installing
now. Even if I could *find* a book that deals with Python 3.x, couldn't afford
to but yet another Python book. 


-- 
Steve Hayes from Tshwane, South Africa
Web:  http://www.khanya.org.za/stevesig.htm
Blog: http://khanya.wordpress.com
E-mail - see web page, or parse: shayes at dunelm full stop org full stop uk
0
Steve
5/31/2014 1:01:01 AM
On 31.05.2014 12:07, Steve Hayes wrote:

> So I bought this book, and decided that whatever version of Python it deals
> with, that's the one I will download and use.

This sounds like remarkably bad advice. That's like saying "I bought a
can of motor oil in my department store and whatever engine that is good
for that's the car that I'll buy and put into!"

> The book is:
> 
> Cunningham, Katie. 2014. Teach yourself Python in 24 hours.
>                Indianapolis: Sams.
>                ISBN: 978-0-672-33687-4
>                    For Python 2.7.5
> 
> I'll leave Python 3.2 on my computer, but 2.7.5 will be the one I'm installing
> now. Even if I could *find* a book that deals with Python 3.x, couldn't afford
> to but yet another Python book. 

Lucky for you 2.7.5 isn't all that different from Py3 and most of it
will apply. You'll be missing out on a bunch of cool features (arbitrary
precision ints, int division operator, real Unicode support) but that's
no big deal.

Regards,
Johannes

-- 
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht �ffentlich!
Ah, der neueste und bis heute genialste Streich unsere gro�en
Kosmologen: Die Geheim-Vorhersage.
 - Karl Kaos �ber R�diger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org>
0
Johannes
5/31/2014 11:09:45 AM
Johannes Bauer, 31.05.2014 13:09:
> Lucky for you 2.7.5 isn't all that different from Py3 and most of it
> will apply. You'll be missing out on a bunch of cool features (arbitrary
> precision ints

Py2 has them as well (although they are called long). 1 << 300 gives the
right answer in both Py2 and Py3, whether the result is a "long" or an "int".


> int division operator

AFAIR, that was added in Py2.5, so a book about Py2.7 should mention it
somewhere.


> real Unicode support

Now, that is really something that has improved in Py3, and certainly a
reason for many people to prefer Py3 over Py2.

Stefan


0
Stefan
5/31/2014 11:22:47 AM
On Sat, 31 May 2014 12:07:59 +0200, Steve Hayes wrote:

> I'll leave Python 3.2 on my computer, but 2.7.5 will be the one I'm
> installing now. Even if I could *find* a book that deals with Python
> 3.x, couldn't afford to but yet another Python book.

Version 2.7 is a good choice, and it will be around for a long time: it 
will be supported until at least 2020, so you should get many years of 
use from it.

Do not be discouraged about Python 3. There are differences, but they 
aren't so different as to be a major barrier. By the time you have a bit 
of experience with 2.7, you will be more than capable of dealing with the 
differences with version 3. They are not different languages, think of 
them as slightly different dialects of the same language, like UK and 
South African English.



-- 
Steven D'Aprano
http://import-that.dreamwidth.org/
0
Steven
5/31/2014 12:30:11 PM
Steve Hayes <hayesstw@telkomsa.net>:

> I'll leave Python 3.2 on my computer, but 2.7.5 will be the one I'm
> installing now. Even if I could *find* a book that deals with Python
> 3.x, couldn't afford to but yet another Python book.

Unfortunately, in the computer field, if there's a book written on a
topic, it will most likely be out of date.

In the 1990's, I used to buy computer books on various topics. I don't
think I have bought one for ten years. Either it is online or it doesn't
exist.

There's enough Python material online to become a pro in it:

 * tutorials,

 * the complete language reference,

 * the complete library reference,

 * the complete reference implementation,

 * this discussion group.


Marko
0
Marko
5/31/2014 12:44:46 PM
Le samedi 31 mai 2014 14:30:11 UTC+2, Steven D'Aprano a =E9crit=A0:
> On Sat, 31 May 2014 12:07:59 +0200, Steve Hayes wrote:
>=20
>=20
>=20
> > I'll leave Python 3.2 on my computer, but 2.7.5 will be the one I'm
>=20
> > installing now. Even if I could *find* a book that deals with Python
>=20
> > 3.x, couldn't afford to but yet another Python book.
>=20
>=20
>=20
> Version 2.7 is a good choice, and it will be around for a long time: it=
=20
>=20
> will be supported until at least 2020, so you should get many years of=20
>=20
> use from it.
>=20
>=20
>=20
> Do not be discouraged about Python 3. There are differences, but they=20
>=20
> aren't so different as to be a major barrier. By the time you have a bit=
=20
>=20
> of experience with 2.7, you will be more than capable of dealing with the=
=20
>=20
> differences with version 3. They are not different languages, think of=20
>=20
> them as slightly different dialects of the same language, like UK and=20
>=20
> South African English.
>=20
>=20
>=20
>=20
=3D=3D=3D=3D=3D=3D

At least Py2 does not crash when using non ascii
(eg sticking with cp1252).

I just noticed this last week, Thursday, when presenting
the absurdity of the Flexible String Representation.

jmf
0
wxjmfauth
5/31/2014 3:48:43 PM
>=20
> I just bought a new book on Python, since the one I had borrowed from my
> son
> only dealt with Python 2.3, and everyone told me that was old.
>=20
> So I bought this book, and decided that whatever version of Python it
> deals
> with, that's the one I will download and use.
>=20
> The book is:
>=20
> Cunningham, Katie. 2014. Teach yourself Python in 24 hours.
>                Indianapolis: Sams.
>                ISBN: 978-0-672-33687-4
>                    For Python 2.7.5
>=20
> I'll leave Python 3.2 on my computer, but 2.7.5 will be the one I'm
> installing
> now. Even if I could *find* a book that deals with Python 3.x, couldn't
> afford
> to but yet another Python book.
>=20
>=20
> --
> Steve Hayes from Tshwane, South Africa
> Web:  http://www.khanya.org.za/stevesig.htm
> Blog: http://khanya.wordpress.com
> E-mail - see web page, or parse: shayes at dunelm full stop org full stop
> uk
> --
> https://mail.python.org/mailman/listinfo/python-list

In my search for information to learn about object oriented programming, =
since I come from a pre oop background, I found this site: =
http://it-ebooks.info/

tons of free books, many fairly up-to-date.  A wealth of knowledge for the =
do it yourself learner. =20

Hope this is helpful to you.

Deb in WA, USA

____________________________________________________________
FREE 3D MARINE AQUARIUM SCREENSAVER - Watch dolphins, sharks & orcas on =
your desktop=21
Check it out at http://www.inbox.com/marineaquarium


0
Deb
5/31/2014 5:28:25 PM
On Sat, 31 May 2014 13:09:45 +0200, Johannes Bauer <dfnsonfsduifb@gmx.de>
wrote:

>On 31.05.2014 12:07, Steve Hayes wrote:
>
>> So I bought this book, and decided that whatever version of Python it deals
>> with, that's the one I will download and use.
>
>This sounds like remarkably bad advice. That's like saying "I bought a
>can of motor oil in my department store and whatever engine that is good
>for that's the car that I'll buy and put into!"

No, it's a bit like flying in a Boeing 747 rather than a Concorde. The latyer
may be later and more technically advanced and flew faster, but no one uses or
supports it. 


>
>> The book is:
>> 
>> Cunningham, Katie. 2014. Teach yourself Python in 24 hours.
>>                Indianapolis: Sams.
>>                ISBN: 978-0-672-33687-4
>>                    For Python 2.7.5
>> 
>> I'll leave Python 3.2 on my computer, but 2.7.5 will be the one I'm installing
>> now. Even if I could *find* a book that deals with Python 3.x, couldn't afford
>> to but yet another Python book. 
>
>Lucky for you 2.7.5 isn't all that different from Py3 and most of it
>will apply. You'll be missing out on a bunch of cool features (arbitrary
>precision ints, int division operator, real Unicode support) but that's
>no big deal.

I'm prepared to forgo whatever advantages those may have to avoid the
frustration of example code not working and not knowing why. 


-- 
Steve Hayes from Tshwane, South Africa
Web:  http://www.khanya.org.za/stevesig.htm
Blog: http://khanya.wordpress.com
E-mail - see web page, or parse: shayes at dunelm full stop org full stop uk
0
Steve
6/1/2014 2:57:27 AM
On 31 May 2014 12:30:11 GMT, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:

>On Sat, 31 May 2014 12:07:59 +0200, Steve Hayes wrote:
>
>> I'll leave Python 3.2 on my computer, but 2.7.5 will be the one I'm
>> installing now. Even if I could *find* a book that deals with Python
>> 3.x, couldn't afford to but yet another Python book.
>
>Version 2.7 is a good choice, and it will be around for a long time: it 
>will be supported until at least 2020, so you should get many years of 
>use from it.
>
>Do not be discouraged about Python 3. There are differences, but they 
>aren't so different as to be a major barrier. By the time you have a bit 
>of experience with 2.7, you will be more than capable of dealing with the 
>differences with version 3. They are not different languages, think of 
>them as slightly different dialects of the same language, like UK and 
>South African English.

That's more or less what the book said, about why it chose to use 2 rather
than 3. 


-- 
Steve Hayes from Tshwane, South Africa
Web:  http://www.khanya.org.za/stevesig.htm
Blog: http://khanya.wordpress.com
E-mail - see web page, or parse: shayes at dunelm full stop org full stop uk
0
Steve
6/1/2014 3:00:09 AM
On Sat, 31 May 2014 15:44:46 +0300, Marko Rauhamaa <marko@pacujo.net> wrote:

>Steve Hayes <hayesstw@telkomsa.net>:
>
>> I'll leave Python 3.2 on my computer, but 2.7.5 will be the one I'm
>> installing now. Even if I could *find* a book that deals with Python
>> 3.x, couldn't afford to but yet another Python book.
>
>Unfortunately, in the computer field, if there's a book written on a
>topic, it will most likely be out of date.
>
>In the 1990's, I used to buy computer books on various topics. I don't
>think I have bought one for ten years. Either it is online or it doesn't
>exist.
>
>There's enough Python material online to become a pro in it:

I hate reading stuff online, and find it diffucult to learn anything with that
method. I use MS Word 97 in preference to Libre Office wor Word 2010 (both of
which I have) because I have a book on the first, but not on the others. I
can't read online books in the bath or in bed. 


-- 
Steve Hayes from Tshwane, South Africa
Web:  http://www.khanya.org.za/stevesig.htm
Blog: http://khanya.wordpress.com
E-mail - see web page, or parse: shayes at dunelm full stop org full stop uk
0
Steve
6/1/2014 3:05:05 AM
On Sun, Jun 1, 2014 at 12:57 PM, Steve Hayes <hayesstw@telkomsa.net> wrote:
> On Sat, 31 May 2014 13:09:45 +0200, Johannes Bauer <dfnsonfsduifb@gmx.de>
> wrote:
>
>>On 31.05.2014 12:07, Steve Hayes wrote:
>>
>>> So I bought this book, and decided that whatever version of Python it deals
>>> with, that's the one I will download and use.
>>
>>This sounds like remarkably bad advice. That's like saying "I bought a
>>can of motor oil in my department store and whatever engine that is good
>>for that's the car that I'll buy and put into!"
>
> No, it's a bit like flying in a Boeing 747 rather than a Concorde. The latyer
> may be later and more technically advanced and flew faster, but no one uses or
> supports it.

"Conky" is more like Python 1 - nobody uses it now (actually, there
are more people using Python 1.x than flying Concorde), but it had its
place in history.

You're flying in a 747-400, which is fine, but when I want to go to
England, I'd much rather go in a 777-300ER. (And yes, I've flown in
both. Can't remember what model Queenie was, but with the 777s it's
usually an Emirates 300ER.) The 747 is still functional, but no more
functional than its era, and life's a lot better with the newer
aircraft. If you want to start a brand new airline, you won't go for
747s if you can get 777s and A380s for the same price. For those who
have 747s in their fleet, there's no problem - there'll be spare parts
available from the manufacturer until at least donkey's years, and
even after that, you can probably get third-party spare parts from
some ex-Soviet mob (at least, they must be Soviets, why else would
they wear red hats?); but you'll only get the features that were in
the 747s when they were built, plus maybe some minor upgrades to the
ancillary bits and pieces. Sure, you can get some of the fancy
interior pieces that were designed for the 777s (enum, for instance),
but the main hull isn't changing.

So if you want to start a one-man airline (where you're managing the
company, flying the plane, and everything else), do you start by
looking at the relative merits of the 747-400 and 777-300ER and
choosing, or do you poke around in your local second-hand shop for
"Learn To Fly A Jet In Twenty-Four Hours" and see which cockpit it's
showing photos of? There are courses for both types; both aircraft
come with excellent "quick start" guides (see
https://docs.python.org/2/tutorial/ and
https://docs.python.org/3/tutorial/ ); and everything you want to ask
about either type can be answered by the team of
Boeing-List@Boeing.Org people, any hour of the day or night. All
you're doing is picking your technology on the basis of *one*
dead-tree book that you happen to have found. Is that really the most
important deciding point?

ChrisA
0
Chris
6/1/2014 3:35:11 AM
On Sunday, June 1, 2014 9:05:11 AM UTC+5:30, Chris Angelico wrote:
> So if you want to start a one-man airline (where you're managing the
> company, flying the plane, and everything else), do you start by
> looking at the relative merits of the 747-400 and 777-300ER

I guess a person starting a one-man airline would be choosing a
7-15 seater and doing short to medium runs.

Are there 7[47]7's in 7-15 seater range <wink>?

And the earlier description of the choice for Word 97 reminded me of one of the 'prophet's' quotes from Illusions:

  <<Argue for your limitations and sure enough they are yours>>

[Disclaimer: I was a Richard Bach fan in my youth]
0
Rustom
6/1/2014 4:11:12 AM
On 01/06/2014 07:01, Bob Martin wrote:
> in 722929 20140601 035727 Steve Hayes <hayesstw@telkomsa.net> wrote:
>
>> No, it's a bit like flying in a Boeing 747 rather than a Concorde. The latyer
>> may be later and more technically advanced and flew faster, but no one uses or
>> supports it.
>
> Actually, the Concorde preceded the 747, and wasn't as "technically advanced",
> it was just faster.
>

I recall Barnes Wallis slagging off the droop nose, but what did he know 
about aircraft?

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

Mark Lawrence

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


0
Mark
6/1/2014 6:52:47 AM
in 722929 20140601 035727 Steve Hayes <hayesstw@telkomsa.net> wrote:

>No, it's a bit like flying in a Boeing 747 rather than a Concorde. The latyer
>may be later and more technically advanced and flew faster, but no one uses or
>supports it.

Actually, the Concorde preceded the 747, and wasn't as "technically advanced",
it was just faster.
0
Bob
6/1/2014 7:01:46 AM
On Sun, 1 Jun 2014 13:35:11 +1000, Chris Angelico <rosuav@gmail.com> wrote:

>Boeing-List@Boeing.Org people, any hour of the day or night. All
>you're doing is picking your technology on the basis of *one*
>dead-tree book that you happen to have found. Is that really the most
>important deciding point?

Yes.


-- 
Steve Hayes from Tshwane, South Africa
Web:  http://www.khanya.org.za/stevesig.htm
Blog: http://khanya.wordpress.com
E-mail - see web page, or parse: shayes at dunelm full stop org full stop uk
0
Steve
6/1/2014 11:38:21 AM
On Sun, 01 Jun 2014 07:01:46 BST, Bob Martin <bob.martin@excite.com> wrote:

>in 722929 20140601 035727 Steve Hayes <hayesstw@telkomsa.net> wrote:
>
>>No, it's a bit like flying in a Boeing 747 rather than a Concorde. The latyer
>>may be later and more technically advanced and flew faster, but no one uses or
>>supports it.
>
>Actually, the Concorde preceded the 747, and wasn't as "technically advanced",
>it was just faster.

Boeing 747s were in airline service in 1970, Concorde didn't enter service
till 4-5 years later. 

Not that it matters, it was just an analogy. I'm pretty certain that Python
2.x preceded Python 3.x


-- 
Steve Hayes from Tshwane, South Africa
Web:  http://www.khanya.org.za/stevesig.htm
Blog: http://khanya.wordpress.com
E-mail - see web page, or parse: shayes at dunelm full stop org full stop uk
0
Steve
6/1/2014 11:41:33 AM
On 01/06/2014 12:41, Steve Hayes wrote:
> On Sun, 01 Jun 2014 07:01:46 BST, Bob Martin <bob.martin@excite.com> wrote:
>
>> in 722929 20140601 035727 Steve Hayes <hayesstw@telkomsa.net> wrote:
>>
>>> No, it's a bit like flying in a Boeing 747 rather than a Concorde. The latyer
>>> may be later and more technically advanced and flew faster, but no one uses or
>>> supports it.
>>
>> Actually, the Concorde preceded the 747, and wasn't as "technically advanced",
>> it was just faster.
>
> Boeing 747s were in airline service in 1970, Concorde didn't enter service
> till 4-5 years later.
>
> Not that it matters, it was just an analogy. I'm pretty certain that Python
> 2.x preceded Python 3.x
>

Clearly you know nothing about the Python time machine :)

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

Mark Lawrence

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


0
Mark
6/1/2014 11:53:44 AM
On Sun, 01 Jun 2014 13:41:33 +0200, Steve Hayes wrote:

> On Sun, 01 Jun 2014 07:01:46 BST, Bob Martin <bob.martin@excite.com>
> wrote:
> 
>>in 722929 20140601 035727 Steve Hayes <hayesstw@telkomsa.net> wrote:
>>
>>>No, it's a bit like flying in a Boeing 747 rather than a Concorde. The
>>>latyer may be later and more technically advanced and flew faster, but
>>>no one uses or supports it.
>>
>>Actually, the Concorde preceded the 747, and wasn't as "technically
>>advanced",
>>it was just faster.
> 
> Boeing 747s were in airline service in 1970, Concorde didn't enter
> service till 4-5 years later.
> 
Concord first flight march 2 1969 757 First flight Feb 9 1969
so there is not actually that much in it

747 entered service much sooner however

> Not that it matters, it was just an analogy. I'm pretty certain that
> Python 2.x preceded Python 3.x





-- 
There seems no plan because it is all plan.
		-- C.S. Lewis
0
alister
6/1/2014 5:21:24 PM
in 722944 20140601 124133 Steve Hayes <hayesstw@telkomsa.net> wrote:
>On Sun, 01 Jun 2014 07:01:46 BST, Bob Martin <bob.martin@excite.com> wrote:
>
>>in 722929 20140601 035727 Steve Hayes <hayesstw@telkomsa.net> wrote:
>>
>>>No, it's a bit like flying in a Boeing 747 rather than a Concorde. The latyer
>>>may be later and more technically advanced and flew faster, but no one uses or
>>>supports it.
>>
>>Actually, the Concorde preceded the 747, and wasn't as "technically advanced",
>>it was just faster.
>
>Boeing 747s were in airline service in 1970, Concorde didn't enter service
>till 4-5 years later.

Concorde design started in the early 50s, 747 mid-to-late 60s.
0
Bob
6/2/2014 7:14:56 AM
--20cf30363ccfe3153904fadba929
Content-Type: text/plain; charset=UTF-8

On Jun 1, 2014 12:11 PM, <wxjmfauth@gmail.com> wrote:

> At least Py2 does not crash when using non ascii
> (eg sticking with cp1252).
>
> I just noticed this last week, Thursday, when presenting
> the absurdity of the Flexible String Representation.

So have you reported this alleged crash bug to the bug tracker? If not,
then you're not contributing to Python or the discussion here in any useful
way; you're just trolling.

--20cf30363ccfe3153904fadba929
Content-Type: text/html; charset=UTF-8

<p dir="ltr"><br>
On Jun 1, 2014 12:11 PM, &lt;<a href="mailto:wxjmfauth@gmail.com">wxjmfauth@gmail.com</a>&gt; wrote:</p>
<p dir="ltr">&gt; At least Py2 does not crash when using non ascii<br>
&gt; (eg sticking with cp1252).<br>
&gt;<br>
&gt; I just noticed this last week, Thursday, when presenting<br>
&gt; the absurdity of the Flexible String Representation.</p>
<p dir="ltr">So have you reported this alleged crash bug to the bug tracker? If not, then you&#39;re not contributing to Python or the discussion here in any useful way; you&#39;re just trolling.<br>
</p>

--20cf30363ccfe3153904fadba929--
0
Ian
6/2/2014 3:01:01 PM
On Mon, 02 Jun 2014 09:01:01 -0600, Ian Kelly wrote:

> On Jun 1, 2014 12:11 PM, <wxjmfauth@gmail.com> wrote:
> 
>> At least Py2 does not crash when using non ascii (eg sticking with
>> cp1252).
>>
>> I just noticed this last week, Thursday, when presenting the absurdity
>> of the Flexible String Representation.
> 
> So have you reported this alleged crash bug to the bug tracker? If not,
> then you're not contributing to Python or the discussion here in any
> useful way; you're just trolling.


There's a corollary to Poe's Law that says that a sufficiently advanced 
troll is indistinguishable from a crank. Whichever JMF is, please don't 
feed him attention.



-- 
Steven D'Aprano
http://import-that.dreamwidth.org/
0
Steven
6/2/2014 4:15:12 PM
In article <538ca310$0$29978$c3e8da3$5496439d@news.astraweb.com>,
 Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:

> On Mon, 02 Jun 2014 09:01:01 -0600, Ian Kelly wrote:
> 
> > On Jun 1, 2014 12:11 PM, <wxjmfauth@gmail.com> wrote:
> > 
> >> At least Py2 does not crash when using non ascii (eg sticking with
> >> cp1252).
> >>
> >> I just noticed this last week, Thursday, when presenting the absurdity
> >> of the Flexible String Representation.
> > 
> > So have you reported this alleged crash bug to the bug tracker? If not,
> > then you're not contributing to Python or the discussion here in any
> > useful way; you're just trolling.
> 
> 
> There's a corollary to Poe's Law that says that a sufficiently advanced 
> troll is indistinguishable from a crank. Whichever JMF is, please don't 
> feed him attention.

Are we talking Tolkien trolls, Pratchett trolls, Rowling trolls, D&D 
trolls, WoW trolls, or what?  Details matter.
0
Roy
6/2/2014 4:21:45 PM
On Tue, Jun 3, 2014 at 2:21 AM, Roy Smith <roy@panix.com> wrote:
> Are we talking Tolkien trolls, Pratchett trolls, Rowling trolls, D&D
> trolls, WoW trolls, or what?  Details matter.

Don't forget Frozen trolls, they're love experts!

ChrisA
(Why aren't you running?)
0
Chris
6/2/2014 4:30:36 PM
On Mon, 02 Jun 2014 12:21:45 -0400, Roy Smith wrote:

>> There's a corollary to Poe's Law that says that a sufficiently advanced
>> troll is indistinguishable from a crank. Whichever JMF is, please don't
>> feed him attention.
> 
> Are we talking Tolkien trolls, Pratchett trolls, Rowling trolls, D&D
> trolls, WoW trolls, or what?  Details matter.

Now I think you're trolling :-)

Internet troll. As I'm sure you know.

http://rationalwiki.org/wiki/Don%27t_feed_the_Troll




-- 
Steven D'Aprano
http://import-that.dreamwidth.org/
0
Steven
6/2/2014 4:52:02 PM
On 02.06.2014 18:21, Roy Smith wrote:

> Are we talking Tolkien trolls, Pratchett trolls, Rowling trolls, D&D 
> trolls, WoW trolls, or what?  Details matter.

Monkey Island trolls, obviously.

Cheers,
Johannes

-- 
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht �ffentlich!
Ah, der neueste und bis heute genialste Streich unsere gro�en
Kosmologen: Die Geheim-Vorhersage.
 - Karl Kaos �ber R�diger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org>
0
Johannes
6/2/2014 5:16:31 PM
On Mon, Jun 2, 2014 at 10:15 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Mon, 02 Jun 2014 09:01:01 -0600, Ian Kelly wrote:
>
>> On Jun 1, 2014 12:11 PM, <wxjmfauth@gmail.com> wrote:
>>
>>> At least Py2 does not crash when using non ascii (eg sticking with
>>> cp1252).
>>>
>>> I just noticed this last week, Thursday, when presenting the absurdity
>>> of the Flexible String Representation.
>>
>> So have you reported this alleged crash bug to the bug tracker? If not,
>> then you're not contributing to Python or the discussion here in any
>> useful way; you're just trolling.
>
>
> There's a corollary to Poe's Law that says that a sufficiently advanced
> troll is indistinguishable from a crank. Whichever JMF is, please don't
> feed him attention.

While his description of the bug is so vague that I'm not inclined to
believe that it actually exists, if it's real then he should be
encouraged to report it.  This is the last time, though.  If he
continues to complain about bugs without reporting or otherwise
identifying them, I'll just ignore it.
0
Ian
6/2/2014 5:53:50 PM
On 02/06/2014 18:53, Ian Kelly wrote:
> On Mon, Jun 2, 2014 at 10:15 AM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
>> On Mon, 02 Jun 2014 09:01:01 -0600, Ian Kelly wrote:
>>
>>> On Jun 1, 2014 12:11 PM, <wxjmfauth@gmail.com> wrote:
>>>
>>>> At least Py2 does not crash when using non ascii (eg sticking with
>>>> cp1252).
>>>>
>>>> I just noticed this last week, Thursday, when presenting the absurdity
>>>> of the Flexible String Representation.
>>>
>>> So have you reported this alleged crash bug to the bug tracker? If not,
>>> then you're not contributing to Python or the discussion here in any
>>> useful way; you're just trolling.
>>
>>
>> There's a corollary to Poe's Law that says that a sufficiently advanced
>> troll is indistinguishable from a crank. Whichever JMF is, please don't
>> feed him attention.
>
> While his description of the bug is so vague that I'm not inclined to
> believe that it actually exists, if it's real then he should be
> encouraged to report it.  This is the last time, though.  If he
> continues to complain about bugs without reporting or otherwise
> identifying them, I'll just ignore it.
>

It's a pleasant change having him complain about bugs, as opposed to 
simply complain about nonexistent problems.


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

Mark Lawrence

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


0
Mark
6/2/2014 5:59:48 PM
Le lundi 2 juin 2014 17:01:01 UTC+2, Ian a =E9crit=A0:
> On Jun 1, 2014 12:11 PM, <wxjm...@gmail.com> wrote:
>=20
> > At least Py2 does not crash when using non ascii
>=20
> > (eg sticking with cp1252).
>=20
> >
>=20
> > I just noticed this last week, Thursday, when presenting
>=20
> > the absurdity of the Flexible String Representation.
>=20
> So have you reported this alleged crash bug to the bug tracker? If not, t=
hen you're not contributing to Python or the discussion here in any useful =
way; you're just trolling.

------

I was myself really suprised to fall on such a case and
after thinking no, such cases may logically happen.

It's not important. I'm no more writing Py apps, only
considering software through an unicode eye.

jmf
0
wxjmfauth
6/3/2014 6:12:30 AM
On Tuesday, June 3, 2014 11:42:30 AM UTC+5:30, jmf wrote:

> after thinking no

Yes [Also called Oui]
0
Rustom
6/3/2014 6:30:28 AM
On 03/06/2014 07:30, Rustom Mody wrote:
> On Tuesday, June 3, 2014 11:42:30 AM UTC+5:30, jmf wrote:
>
>> after thinking no
>
> Yes [Also called Oui]
>

I'm very puzzled over "thinking", what context was this in as I've 
kill-filed our most illustrious resident unicode expert?

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

Mark Lawrence

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


0
Mark
6/3/2014 8:03:12 AM
On 6/3/14 4:03 AM, Mark Lawrence wrote:
> On 03/06/2014 07:30, Rustom Mody wrote:
>> On Tuesday, June 3, 2014 11:42:30 AM UTC+5:30, jmf wrote:
>>
>>> after thinking no
>>
>> Yes [Also called Oui]
>>
>
> I'm very puzzled over "thinking", what context was this in as I've
> kill-filed our most illustrious resident unicode expert?
>

Let's please not have a recounting of other peoples' posts, especially 
if they are posts we try to minimize.

-- 
Ned Batchelder, http://nedbatchelder.com

0
Ned
6/3/2014 11:22:42 AM
Steve Hayes <hayesstw@telkomsa.net> on Sun, 01 Jun 2014 05:05:05 +0200
typed in comp.lang.python  the following:
>On Sat, 31 May 2014 15:44:46 +0300, Marko Rauhamaa <marko@pacujo.net> wrote:
>
>>Steve Hayes <hayesstw@telkomsa.net>:
>>
>>> I'll leave Python 3.2 on my computer, but 2.7.5 will be the one I'm
>>> installing now. Even if I could *find* a book that deals with Python
>>> 3.x, couldn't afford to but yet another Python book.
>>
>>Unfortunately, in the computer field, if there's a book written on a
>>topic, it will most likely be out of date.
>>
>>In the 1990's, I used to buy computer books on various topics. I don't
>>think I have bought one for ten years. Either it is online or it doesn't
>>exist.
>>
>>There's enough Python material online to become a pro in it:
>
>I hate reading stuff online, and find it diffucult to learn anything with that
>method. I use MS Word 97 in preference to Libre Office wor Word 2010 (both of
>which I have) because I have a book on the first, but not on the others. I
>can't read online books in the bath or in bed. 

	Hear, hear!
--  
pyotr filipivich
The fears of one class of men are not the measure of the rights of another. 
-- George Bancroft
0
pyotr
7/12/2014 5:50:04 PM
On Wednesday, May 28, 2014 3:15:45 PM UTC-5, Chris Angelico wrote:
> On Thu, May 29, 2014 at 5:58 AM, Larry Martell wrote:
> > No company that I work for is using python 3 - they just
> > have too much of an investment in a python 2 code base
> > to switch. I'm just saying.
> And that's not a problem. Every whinging blog author seems
> to forget [...] Or maybe the complaint is that there are
> fancy new features in Python 3.x that aren't in 2.7? Oh
> wait, that directly contradicts the whine. So if Python 3
> has added nothing, what's the rush to move onto it?

What's wrong with people wanting new features WITHOUT
suffering through the headaches of porting code? I think
your missing the point Chris.

You and i both know that most of the features could be added
without breaking Python, but the choice was made to break
Python anyway, and that would have been fine IF the powers
that be would have REALLY made Python better, but they
only "slightly" improved the language!

Look, along the course of ANY learning curve, a designer, or
an artist, or an engineer, is going to realize he made some
catastrophic mistakes -- okay, no problem, we are ALL but
human after all, even the "Anointed One" is not beyond
mistakes, HOWEVER, the choice to fracture a community over
"minor improvements" was a poor choice and i think some
"owning up" is in order!

Also, this "idea" of yours that people should just shut up
and do what the "regime" commands, is just utter nonsense.
Python is a public offering, and as such is equally subject
to both praise and ridicule.

    FREEDOM OF SPEECH IS A REAL BEECH!

If the "powers that be" cannot handle the heat, then they
should withdraw Python from the public and then they can
decree any ridiculous fascist rules they please, until then,
what's that old adage about "reaping" and "sewing"...?

QUESTION:
    "What's worse than fracturing a community?"

ANSWER:
    "Creating a leadership vacuum."

--And nature *abhors* a vacuum!

Besides, "opposing and competing forces" are a fundamental
part of evolution (psst: do you remember that little thing
called "evolution" Chris?) and so we must NEVER forget the
absolute necessity of dissent! Just think of what our world
would be like if every idea was NOT placed under the
microscope for scrutiny.

    I SHUTTER TO THINK!

Image, for a moment, a world WITHOUT the great USA! Yes, i
know you little commies love to curse the USA, and yes,
there are many dark sins committed within AND beyond her
borders, but try to tell me you bass-turds, what nation in
modern history has contributed more technological
achievements [1] or engendered a revolution of social
justice around the world, or, propagated the idea that all
men are created equal and endowed by their creator with
unalienable rights? What would have happened if the colonies
just threw their hands and and said:

    "WELL, GEORGE KNOWS BEST!"

> Whiners gonna whine.

And brown-nosing little shills gonna shill!

[1]: even IF many of them were "borrowed". HEY, TO THE VICTOR GO THE SPOILS!
0
Rick
7/14/2014 10:12:25 PM
On 14/07/2014 23:12, Rick Johnson wrote:
>   I SHUTTER TO THINK!

It's "I shudder to think"!

shut�ter  [shuht-er]

noun
1. a solid or louvered movable cover for a window.
2. a movable cover, slide, etc., for an opening.
3. a person or thing that shuts.
4. Photography . a mechanical device for opening and closing the 
aperture of a camera lens to expose film or the like.

verb (used with object)
5. to close or provide with shutters: She shuttered the windows.
6. to close (a store or business operations) for the day or permanently.

shud�der  [shuhd-er]

verb (used without object)
1. to tremble with a sudden convulsive movement, as from horror,fear, or 
cold.
noun
2. a convulsive movement of the body, as from horror, fear, or cold.


0
mm0fmf
7/14/2014 10:37:18 PM
On 2014-07-14 23:12, Rick Johnson wrote:
> On Wednesday, May 28, 2014 3:15:45 PM UTC-5, Chris Angelico wrote:
>> On Thu, May 29, 2014 at 5:58 AM, Larry Martell wrote:
>>> No company that I work for is using python 3 - they just have too
>>> much of an investment in a python 2 code base to switch. I'm just
>>> saying.
>> And that's not a problem. Every whinging blog author seems to
>> forget [...] Or maybe the complaint is that there are fancy new
>> features in Python 3.x that aren't in 2.7? Oh wait, that directly
>> contradicts the whine. So if Python 3 has added nothing, what's the
>> rush to move onto it?
>
> What's wrong with people wanting new features WITHOUT suffering
> through the headaches of porting code? I think your missing the point
> Chris.
>
> You and i both know that most of the features could be added without
> breaking Python, but the choice was made to break Python anyway, and
> that would have been fine IF the powers that be would have REALLY
> made Python better, but they only "slightly" improved the language!
>
> Look, along the course of ANY learning curve, a designer, or an
> artist, or an engineer, is going to realize he made some catastrophic
> mistakes -- okay, no problem, we are ALL but human after all, even
> the "Anointed One" is not beyond mistakes, HOWEVER, the choice to
> fracture a community over "minor improvements" was a poor choice and
> i think some "owning up" is in order!
>
> Also, this "idea" of yours that people should just shut up and do
> what the "regime" commands, is just utter nonsense. Python is a
> public offering, and as such is equally subject to both praise and
> ridicule.
>
> FREEDOM OF SPEECH IS A REAL BEECH!
>
> If the "powers that be" cannot handle the heat, then they should
> withdraw Python from the public and then they can decree any
> ridiculous fascist rules they please, until then, what's that old
> adage about "reaping" and "sewing"...?
>
Why it should "they" withdraw it (whatever that means)?

"They" are entitled to keep it public if they want to.

Those who aren't interested are not obliged to take any notice of it,
and any group or individual who wants to develop Python 2 further can
just fork Python 2.7 and continue from there.

> QUESTION: "What's worse than fracturing a community?"
>
> ANSWER: "Creating a leadership vacuum."
>
> --And nature *abhors* a vacuum!
>
> Besides, "opposing and competing forces" are a fundamental part of
> evolution (psst: do you remember that little thing called "evolution"
> Chris?) and so we must NEVER forget the absolute necessity of
> dissent! Just think of what our world would be like if every idea was
> NOT placed under the microscope for scrutiny.
>
Evolution is also about competition, and there's nothing stopping
someone creating a fork of Python 2 to compete with Python 3.

> I SHUTTER TO THINK!
>
[snip]
BTW, that's "SHUDDER", not "SHUTTER".
0
MRAB
7/14/2014 10:47:14 PM
On Tue, Jul 15, 2014 at 8:12 AM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
> If the "powers that be" cannot handle the heat, then they
> should withdraw Python from the public and then they can
> decree any ridiculous fascist rules they please, until then,
> what's that old adage about "reaping" and "sewing"...?

You've already been told about "shutter" vs "shudder", but I'd like to
also point out that this would be "sowing", as it's a reference to
this passage from the Bible:

https://www.biblegateway.com/passage/?search=Galatians+6%3A7-8&version=NIV

which is itself a reference to the work of planting (sowing seeds) and
then harvesting (reaping).

> Besides, "opposing and competing forces" are a fundamental
> part of evolution (psst: do you remember that little thing
> called "evolution" Chris?)

Actually, no. I don't remember evolving from anything else. Do you?
Because I've always been the same thing I am now. What am I supposed
to be remembering, exactly?

> Image, for a moment, a world WITHOUT the great USA!

"Imagine". If you were worth the effort, I could easily "image" a
world without the USA, by Photoshopping something out of a world map.
(I'd probably use the Gimp, or Pike's image manipulation libraries,
but everyone knows what Photoshopping is.)

And I know what would happen if the USA weren't here. People in other
countries would have made similar improvements to the world. Oh, and
just for reference, I'm not in the US. I'm an Aussie, and we boast a
fairly impressive per-capita invention rate. Some of them (like the
stump-jump plough) are specific to our peculiar land, but there are
plenty of awesome tools of general interest that have come from here.
Just start poking around in various technical documents (RFCs, ISO and
ANSI standards, etc, etc) and see how many contributors' addresses say
Australia; chances are it'll be a lot more than our ~20M population
would suggest. There are a few European countries that, similarly,
contribute far more than their apparent size would imply.

> what nation in
> modern history has contributed more technological
> achievements [1] or engendered a revolution of social
> justice around the world, or, propagated the idea that all
> men are created equal and endowed by their creator with
> unalienable rights?

Social justice? Do you honestly think the USofA is the example to hold
up and say "Look, we have perfectly solved the problems of social
injustice"? I guess you've eliminated racism since I last heard.

Oh, and I agree that all people are created equal. (I'll leave aside
the argument about whether your statement is proof that English is
sexist, or that the US founding fathers were the sexist ones.) I also
believe that our Creator sees us as equal. But all through history, we
flawed human beings have had a problem with seeing people differently,
for various reasons. The Apostle James wrote about a major problem
with "wealthist" Christians:

https://www.biblegateway.com/passage/?search=James+2%3A1-4&version=NIV

And there've been plenty of other problems creeping in. God treats us
all the same way: flawed, fallible people whom He loves enough to die
for. If you want to believe in true equality, you need to follow His
example.

ChrisA
0
Chris
7/14/2014 11:28:19 PM
On 15/07/2014 00:28, Chris Angelico wrote:
> On Tue, Jul 15, 2014 at 8:12 AM, Rick Johnson
> <rantingrickjohnson@gmail.com> wrote:
>
>> Image, for a moment, a world WITHOUT the great USA!
>
> "Imagine". If you were worth the effort, I could easily "image" a
> world without the USA, by Photoshopping something out of a world map.
> (I'd probably use the Gimp, or Pike's image manipulation libraries,
> but everyone knows what Photoshopping is.)
>

No more World Series in sport.  No more hunting for weapons of mass 
destruction in Iraq.  No more big mouthed Yanks who insist that they won 
WWII despite the fact that as usual they didn't bother turning up at the 
start.  And apart from that...

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

Mark Lawrence

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


0
Mark
7/14/2014 11:59:46 PM
On Monday, July 14, 2014 5:47:14 PM UTC-5, MRAB wrote:
> Why it should "they" withdraw it (whatever that means)?
> "They" are entitled to keep it public if they want to.

I'm not suggesting they *must* withdraw Python, I'm only
suggesting that IF they wish to *prevent* dissent or scrutiny,
then the only remedy they can employ is to "withdraw" the
language from public view. 

I'm merely highlighting the difference between public and
private property. Python is currently public property, and
just as a public park is open to whoever wishes to visit, so
too is the the Python language.

Sure, nobody wants to see the unwashed homeless people
there, feeding the pigeons until they grow so fat they can
only muster sporadic momentary flight, in between Jackson
Pollock inspired park bench repainting sessions via
cementitious bowel ejections... THOSE VERMIN! 

But we must suffer them, because if we believe in freedom,
we must celebrate the "comfortable" whilst suffering the
"uncomfortable".

> Those who aren't interested are not obliged to take any
> notice of it, and any group or individual who wants to
> develop Python 2 further can just fork Python 2.7 and
> continue from there.

Actually, no. You need to understand some ground rules of
free societies:

============================================================
 When a *public* "entity" is created, an "individual" *may*:
============================================================

    * Ignore the entity altogether. At which point, no
    future interaction occurs UNLESS the "individual"
    decides to change his relationship with the *public*
     "entity"

    * Engage the entity in one or more forms:
        1. Participate in debate. Which may include accolades, 
           dissent, or even vile rebukes.
        2. Take from the entity any offerings the entity may
           provide.
        3. All of the above.
        
    You see, the "entity" merely offers something for the
    taking, and the "individual" decides to take the
    offering, or not to take the offering; to participate,
    or not to participate; -- extrapolations to infinity...!
    
    And not only does the "individual" control the time,
    place, and manner of the interaction, he also has the
    capacity to insert or remove himself from participation
    at any time. THIS, is the manner of free "individuals"
    operating in the realm of *public* "entities".
    
An "individual", a FREE individual that is, has many more
choices than the single choice you provided. What you're
attempting to do is "compel" an "individual" to engage a
*public* entity in a manner that is most pleasing to YOU,
and i will not allow that to happen!

I've seen this "vulgar display of animosity" before,
predominately in short, angry white women driving
"Scandinavian armored personnel carriers" (aka: Volvo), with
closely trimmed eyebrows, and beaming scowls of superiority
down on the "little people" as she transports her "honor
role student" to school at twenty miles below the speed
limit!

0
Rick
7/15/2014 1:00:42 AM
On Tuesday, July 15, 2014 9:31:31 AM UTC-5, Chris Angelico wrote:
> [...] That said, though, I would advise you to give 2to3 a
> shot. You never know, it might do exactly what you need
> right out-of-the-box and give you a 3.x-compatible
> codebase in one hit.

Ha! 

Are you so foolish as to believe that if code runs cleanly
*immediately* after translating via "2to3", that the code is
now completely free from translation bugs?

You act as if 2to3 is some "magical" code that can root out
every bug no matter how subtle. No, for those of us who care
about our reputation, we are not about to release code that
could blow chunks and leave egg all over our face, or worse,
cause us to loose a contract!

> Ultimately, the solution is simply to keep Python 2.7
> around for a good long time, until the carrot of new Py3
> features becomes attractive enough for it to be worth
> switching. And if that's not before 2020, no problem. Even
> if it's after 2020, there's a fair chance that you'll
> still be able to run your 2.7 code -

So in other words, "we're" know now we made a bad decision by
creating this Python3000 thing, because nobody seems to be
jumping on the bandwagon, but instead of admitting we were
wrong, we'll just cling to our new shiny *THING* and hope
*EVENTUALLY*, if we brow-beat *ENOUGH* people, that well,
*MAYBE* most of them will embrace this *ABORTION* and join us.

> it's just that there's no promise (at the moment) of
> patches, even security patches, from python.org. 

Oh yes, i see... when brow-beating does not work, we adopt
the malevolent tactics of $MS  and $OS by allowing security
holes and virus infections to riddle the code base obsolete.

    COME AND GET THE NEXT NEW SHINY RATTLE YOU INFANTS!

    MEET THE NEW RATTLE...
    SAME AS THE OLD RATTLE...

i pray we don't get fooled again!
    
0
Rick
7/15/2014 1:01:01 AM
> 
> Image, for a moment, a world WITHOUT the great USA! Yes, i know you
> little commies love to curse the USA, and yes,
> there are many dark sins committed within AND beyond her borders, but
> try to tell me you bass-turds, what nation in modern history has
> contributed more technological achievements [1]

The one you revolted from.
The Same one that is your first port of call for assistance whenever you 
get yourselves involved in conflict.

I think you will find that more inventions have originated on this 
desolate windswept island of the north coast of Europe than the USA.

We are called Great Britain, the clue is in the name.


-- 
Charm is a way of getting the answer "Yes" -- without having asked any
clear question.
0
alister
7/15/2014 1:01:01 AM
On 15/07/2014 04:58, Michael Torrie wrote:
> On 06/03/2014 12:12 AM, wxjmfauth@gmail.com wrote:
>> I was myself really suprised to fall on such a case and
>> after thinking no, such cases may logically happen.
>
> Putting in this comment not for JMF but for poor souls who find this
> thread on a search and are led astray by jmf's trolling.
>
> Either it was your code or an issue with the Windows console that caused
> the exception.  When you try to print out unicode strings, Python must
> convert them to the character encoding of the terminal in order to print
> them out.  On sane systems this is UTF-8.  On Windows it could be
> anything.  Do you want Python to fail silently or do you want to fail
> with a useful message, with the option of specifying the exact behavior
> you want (replace unrepresentable characters with spaces, question
> marks, etc)?

Sorry if I'm repeating myself but this is relevant 
http://bugs.python.org/issue21927 specifically msg222761.

>
> Seems like jmf, though being a self-proclaimed unicode expert,
> continually confusing unicode with encoding schemes.

He's been spouting his bile on this subject on this list for IIRC nearly 
two years.  Still he gets away with it.  Is he sleeping with the right 
people I ask myself?

>
>>
>> It's not important. I'm no more writing Py apps, only
>> considering software through an unicode eye.
>
> Please just stop posting to this list.
>
> thanks.
>

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

Mark Lawrence

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


0
Mark
7/15/2014 1:01:01 AM
On Tue, Jul 15, 2014 at 11:00 AM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
> On Monday, July 14, 2014 5:47:14 PM UTC-5, MRAB wrote:
>> Why it should "they" withdraw it (whatever that means)?
>> "They" are entitled to keep it public if they want to.
>
> I'm not suggesting they *must* withdraw Python, I'm only
> suggesting that IF they wish to *prevent* dissent or scrutiny,
> then the only remedy they can employ is to "withdraw" the
> language from public view.

Python 3 stands up just fine to scrutiny, and dissent is a normal part of life.

> I'm merely highlighting the difference between public and
> private property. Python is currently public property, and
> just as a public park is open to whoever wishes to visit, so
> too is the the Python language.

Python is not public property. Whatever gave you that idea?

> I've seen this "vulgar display of animosity" before,
> predominately in short, angry white women driving
> "Scandinavian armored personnel carriers" (aka: Volvo), with
> closely trimmed eyebrows, and beaming scowls of superiority
> down on the "little people" as she transports her "honor
> role student" to school at twenty miles below the speed
> limit!

Wow. There is just so much US-centrism in that paragraph... I don't
understand half of it half as well as I'd like, and I like less than
half of it half as well as it deserves.

ChrisA
0
Chris
7/15/2014 1:18:07 AM
On Monday, July 14, 2014 6:28:19 PM UTC-5, Chris Angelico wrote:
> And I know what would happen if the USA weren't here.
> People in other countries would have made similar
> improvements to the world.

Yes, i wholeheartedly agree with that statement.

Is the USA the *ONLY* country to have ever liberated the world
from the clutches of evil?...No! Will the USA be the *LAST* to
do so?...OF COURSE NOT! I'm not so blind as you may believe.

But, if the USA *DID NOT* exist during the perilous times of
the world wars, how many generations of people would have
suffered before a powerful enough contender came along to
unclench the grips of evil?

    I "SHUDDER" TO THINK!

How many minutes, or hours, or days in a concentration camp
would YOU, Chris Angelico, trade so you could have your
selfish wish to wipe USA's prestige from the history books?

You see Chris, the battle between "good" and "evil" [1] will
always exist, and in fact, if it did not exist, the world
would be a stagnate cess-pool of rot and decay because it is
the very battle that is waged against "evil", which is just
another form of competition, that spins the cogs of
evolution.

Of course the "moral authority" of "doing good" has it's
hormonal payoffs, yes?

    SELFISHNESS, MEET GLUTTONY
    GLUTTONY, SELFISHNESS!

Ha, however, our "chemically induced" happiness is just a
method of pacification, and protects our delicate emotional
"beings" from the most abysmal of apathetic truths.

Living creatures are lazy by nature, and we will, if not
"challenged", waste away, in order to maintain forward
evolution, the tools of pain, jealously, terror, envy, etc,
etc... are employed to "compel" us to compete with each
other --from the friendliest of banter to the deepest depths
of human depravity-- we are but pawns in a greater game!

    LET THE GAMES BEGIN!

> Social justice? Do you honestly think the USofA is the
> example to hold up and say "Look, we have perfectly solved
> the problems of social injustice"?

Point to my statement that mentioned ANYTHING about
"perfect". I don't believe in perfection, since such an
"idea" is unattainable by both the human hand, or human mind.

> I guess you've eliminated racism since I last heard.

Yup. And next we've decided to solve the middle east crisis!

> Oh, and I agree that all people are created equal. (I'll
> leave aside the argument about whether your statement is
> proof that English is sexist, or that the US founding
> fathers were the sexist ones.) I also believe that our
> Creator sees us as equal. But all through history, we
> flawed human beings have had a problem with seeing people
> differently, for various reasons. The Apostle James wrote
> about a major problem with "wealthist" Christians: And
> there've been plenty of other problems creeping in. God
> treats us all the same way: flawed, fallible people whom
> He loves enough to die for. If you want to believe in true
> equality, you need to follow His example.

I'm confused by your logic. First you admit all humans are
fallible, but somehow, you believe that a collection of
humans should be "infallible". Please explain this enigma.


REFERENCES:

[1] And i use the terms very loosely here. Please, let's not
    get into a debate of what "good" and "evil" are with all
    the religious nonsense and such.
0
Rick
7/15/2014 1:54:07 AM
On Tue, Jul 15, 2014 at 11:54 AM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
> But, if the USA *DID NOT* exist during the perilous times of
> the world wars, how many generations of people would have
> suffered before a powerful enough contender came along to
> unclench the grips of evil?
>
>     I "SHUDDER" TO THINK!
>
> How many minutes, or hours, or days in a concentration camp
> would YOU, Chris Angelico, trade so you could have your
> selfish wish to wipe USA's prestige from the history books?

I dunno. It's not like Great Britain, Australia, or New Zealand did
anything significant in either war, is it. And a lot of US citizens
fought in British or other military units, because the US wasn't in
the war yet. That's what I mean by "if the US were not, others would
take up the slack" - the same people would do the same work, under a
different flag.

> You see Chris, the battle between "good" and "evil" [1] will
> always exist, and in fact, if it did not exist, the world
> would be a stagnate cess-pool of rot and decay because it is
> the very battle that is waged against "evil", which is just
> another form of competition, that spins the cogs of
> evolution.
>
> [1] And i use the terms very loosely here. Please, let's not
>     get into a debate of what "good" and "evil" are with all
>     the religious nonsense and such.

Easiest to use the Dungeons & Dragons definitions of those terms
(which don't conflict with most religious definitions): evil is
selfishness, good is altruism.

>> I guess you've eliminated racism since I last heard.
>
> Yup. And next we've decided to solve the middle east crisis!

Good. Call me when you get there, and I'll give you the rest of the
directions. Some people in Australia are still racist, but racism is
nothing like the problem it is in America, where you boast so much of
equality.

>> Oh, and I agree that all people are created equal. (I'll
>> leave aside the argument about whether your statement is
>> proof that English is sexist, or that the US founding
>> fathers were the sexist ones.) I also believe that our
>> Creator sees us as equal. But all through history, we
>> flawed human beings have had a problem with seeing people
>> differently, for various reasons. The Apostle James wrote
>> about a major problem with "wealthist" Christians: And
>> there've been plenty of other problems creeping in. God
>> treats us all the same way: flawed, fallible people whom
>> He loves enough to die for. If you want to believe in true
>> equality, you need to follow His example.
>
> I'm confused by your logic. First you admit all humans are
> fallible, but somehow, you believe that a collection of
> humans should be "infallible". Please explain this enigma.

Where do I say anything about a collection of humans being infallible?
I believe I specifically said *fallible*. That's, uhh, the opposite of
infallible.

ChrisA
0
Chris
7/15/2014 2:11:47 AM
On 05/31/2014 09:48 AM, jmf wrote:
> <falsehoods about python and unicode>

Absolutely FALSE.  Python 3.3 and up can handle any and all unicode
characters you want to throw at it, without surprises such as what you
get in javascript.  Python 3 uses UTF-4 encoding under the hood, with a
compression optimization that removes leading zeros from binary
representation of each character.

Windows command consoles are not unicode compliant, and so running
python programs a command prompt console will often lead to exceptions
because Python must convert unicode to the character set that the
console is using, and when a character is hit that cannot be encoded
Python defaults to being correct and throws an exception, instead of
failing silently.

0
Michael
7/15/2014 3:47:32 AM
On 06/03/2014 12:12 AM, wxjmfauth@gmail.com wrote:
> I was myself really suprised to fall on such a case and
> after thinking no, such cases may logically happen.

Putting in this comment not for JMF but for poor souls who find this
thread on a search and are led astray by jmf's trolling.

Either it was your code or an issue with the Windows console that caused
the exception.  When you try to print out unicode strings, Python must
convert them to the character encoding of the terminal in order to print
them out.  On sane systems this is UTF-8.  On Windows it could be
anything.  Do you want Python to fail silently or do you want to fail
with a useful message, with the option of specifying the exact behavior
you want (replace unrepresentable characters with spaces, question
marks, etc)?

Seems like jmf, though being a self-proclaimed unicode expert,
continually confusing unicode with encoding schemes.

> 
> It's not important. I'm no more writing Py apps, only
> considering software through an unicode eye.

Please just stop posting to this list.

thanks.
0
Michael
7/15/2014 3:58:05 AM
On Monday, July 14, 2014 9:11:47 PM UTC-5, Chris Angelico wrote:
> I dunno. It's not like Great Britain, Australia, or New
> Zealand did anything significant in either war, is it.

Most of Europe occupied, London bombed into the stone age;
things were looking grim Chris! Maybe you should read up on
some WW2 history, it's quite humbling to think what *could*
have happened.

> Some people in Australia are still racist, but racism is
> nothing like the problem it is in America, where you boast
> so much of equality.

Where do you get your info about America, from CNN? And for
someone who is a self-described "Aussie" you sure seem to
know more about Americans than Americans know about
themselves... hmm, another enigma!

Chris, one thing you need to understand about America is
that a whole grievance industry exists to perpetuate hate.
And sadly, most Americans are too stupid to realize this.

You see, a divided people are not going to cause the rulers
any troubles because they are too busy fighting amongst
themselves -- the same effect is employed in prison
populations to protect the guards.

In ancient Rome, the Caesars used games and bread to control
the masses, today, they use the grievance industry and, for
the complete moronic zombies, sporting events.

All "isms" and social problems just boil down to hate. And
since you can never remove hate from the heart of man, you
will *NEVER* solve these issues. The best you can hope for
is to reduce the levels a bit via "intelligent interventions".

So in short, none of these issues will ever be solved until
people realize who the real enemy is -> themselves.

    MIRROR, MIRROR, ON THE WALL, WHO'S THE MOST JUDGMENTAL 
    OF THEM ALL?
    
============================================================
 The origins of xenophobia:
============================================================

In order to defeat our own hatred of others, we must
circumvent our per-programmed primal fears, which is not
easy to do, and while these fears play a vital survival role
in *early* development of both the *individuals* of a group
AND the group itself, in modern times, these fears have
become a crutch preventing humans from evolving socially.

    HENCE THE GRIEVANCE INDUSTRY PERPETRATED BY A MEDIA 
    CIRCUS THAT WILL DO ANYTHING TO GET RATINGS!

  ====================
   THOUGHT EXPERIMENT
  ====================
  
  Imagine your a small kitten: innocent, carefree, and full
  of curiosity! You love exploring the world, stuffing
  yourself into boxes, climbing to high places, and chasing
  balls of strings -- ah what a life!
  
  You see your siblings and notice they have fur like you ,
  and whiskers like you, and paws and tails and blah like
  you. And you are comfortable because these other
  "lifeforms" resemble you, and so you consider them to be
  "safe".
  
  Then one day, whilst frolicking in the backyard, you see a
  glimmer from under a log, ooh, whats this you ask
  rhetorically...?
  
  So you get closer to inspect, and you see two eyes, and
  you think, hmm, it has two eyes just like my bothers and
  sisters so it must be safe...!
  
  And so you get yet closer, but just then you start to
  notice some differences, whoa, this thing has no fur, it
  has no paws, and no whiskers, and it has strange patterns
  on it's back and it's making a rattling noise, oh well, no
  need to let fear get in my way, i'll just go over and
  introduce myself... AND THAT WAS THE END OF "FLUFFY THE
  KITTEN"!
  
  MEOW!
    
You see, since hate is merely an extrapolation of
xenophobia, which is itself a per-programmed reflex utilized
unconsciously to protect an organism from self destruction
via *utter* ignorance of dangerous predators, we are
fighting a losing battle when we expect the vast majority of
earths "intelligent" inhabitants, of which most are
zombie-fied *idiots*, to violate their own source code.

    JUST GO GRAB A BEER AND WATCH THE GAME YOU BEER-BELLIED FOOL!

PS: That was a "general" you, not to be taken as a literal 
statement to Chris.

0
Rick
7/15/2014 4:18:05 AM
On Tue, Jul 15, 2014 at 1:47 PM, Michael Torrie <torriem@gmail.com> wrote:
> Python 3 uses UTF-4 encoding under the hood, with a
> compression optimization that removes leading zeros from binary
> representation of each character.

Sorry to nitpick, but in the interests of terminological accuracy I
have to point out that it's UTF-32 or UCS-4, not UTF-4 :)

But otherwise, yes, quite correct. And a system that few, but not no,
other languages use; I do wonder if other languages have considered
switching to this kind of system, but avoided it lest jmf start
haunting them too...

ChrisA
0
Chris
7/15/2014 4:20:36 AM
------1GJ5384F5LUDMOPLWUI11YBIVLX1ME
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
 charset=UTF-8

Yes, we all know that Abu Ghraib, Guantanamo, school shootings and the lack of proper health care for all are the pinnacle of US culture. Or figments of the imagination of Baghdad Bob. 

Now, maybe return to Python? 

/martin 

On 15 Jul 2014, Rick Johnson <rantingrickjohnson@gmail.com> wrote:
>On Monday, July 14, 2014 9:11:47 PM UTC-5, Chris Angelico wrote:
>> I dunno. It's not like Great Britain, Australia, or New
>> Zealand did anything significant in either war, is it.
>
>Most of Europe occupied, London bombed into the stone age;
>things were looking grim Chris! Maybe you should read up on
>some WW2 history, it's quite humbling to think what *could*
>have happened.
>
>> Some people in Australia are still racist, but racism is
>> nothing like the problem it is in America, where you boast
>> so much of equality.
>
>Where do you get your info about America, from CNN? And for
>someone who is a self-described "Aussie" you sure seem to
>know more about Americans than Americans know about
>themselves... hmm, another enigma!
>
>Chris, one thing you need to understand about America is
>that a whole grievance industry exists to perpetuate hate.
>And sadly, most Americans are too stupid to realize this.
>
>You see, a divided people are not going to cause the rulers
>any troubles because they are too busy fighting amongst
>themselves -- the same effect is employed in prison
>populations to protect the guards.
>
>In ancient Rome, the Caesars used games and bread to control
>the masses, today, they use the grievance industry and, for
>the complete moronic zombies, sporting events.
>
>All "isms" and social problems just boil down to hate. And
>since you can never remove hate from the heart of man, you
>will *NEVER* solve these issues. The best you can hope for
>is to reduce the levels a bit via "intelligent interventions".
>
>So in short, none of these issues will ever be solved until
>people realize who the real enemy is -> themselves.
>
>    MIRROR, MIRROR, ON THE WALL, WHO'S THE MOST JUDGMENTAL 
>    OF THEM ALL?
>    
>============================================================
> The origins of xenophobia:
>============================================================
>
>In order to defeat our own hatred of others, we must
>circumvent our per-programmed primal fears, which is not
>easy to do, and while these fears play a vital survival role
>in *early* development of both the *individuals* of a group
>AND the group itself, in modern times, these fears have
>become a crutch preventing humans from evolving socially.
>
>    HENCE THE GRIEVANCE INDUSTRY PERPETRATED BY A MEDIA 
>    CIRCUS THAT WILL DO ANYTHING TO GET RATINGS!
>
>  ====================
>   THOUGHT EXPERIMENT
>  ====================
>  
>  Imagine your a small kitten: innocent, carefree, and full
>  of curiosity! You love exploring the world, stuffing
>  yourself into boxes, climbing to high places, and chasing
>  balls of strings -- ah what a life!
>  
>  You see your siblings and notice they have fur like you ,
>  and whiskers like you, and paws and tails and blah like
>  you. And you are comfortable because these other
>  "lifeforms" resemble you, and so you consider them to be
>  "safe".
>  
>  Then one day, whilst frolicking in the backyard, you see a
>  glimmer from under a log, ooh, whats this you ask
>  rhetorically...?
>  
>  So you get closer to inspect, and you see two eyes, and
>  you think, hmm, it has two eyes just like my bothers and
>  sisters so it must be safe...!
>  
>  And so you get yet closer, but just then you start to
>  notice some differences, whoa, this thing has no fur, it
>  has no paws, and no whiskers, and it has strange patterns
>  on it's back and it's making a rattling noise, oh well, no
>  need to let fear get in my way, i'll just go over and
>  introduce myself... AND THAT WAS THE END OF "FLUFFY THE
>  KITTEN"!
>  
>  MEOW!
>    
>You see, since hate is merely an extrapolation of
>xenophobia, which is itself a per-programmed reflex utilized
>unconsciously to protect an organism from self destruction
>via *utter* ignorance of dangerous predators, we are
>fighting a losing battle when we expect the vast majority of
>earths "intelligent" inhabitants, of which most are
>zombie-fied *idiots*, to violate their own source code.
>
>    JUST GO GRAB A BEER AND WATCH THE GAME YOU BEER-BELLIED FOOL!
>
>PS: That was a "general" you, not to be taken as a literal 
>statement to Chris.

-- Sent with K-@ Mail - the evolution of emailing.
------1GJ5384F5LUDMOPLWUI11YBIVLX1ME
Content-Type: text/html;
 charset=utf-8
Content-Transfer-Encoding: 8bit

<html><head></head><body>Yes, we all know that Abu Ghraib, Guantanamo, school shootings and the lack of proper health care for all are the pinnacle of US culture. Or figments of the imagination of Baghdad Bob. <br clear="none">
<br clear="none">
Now, maybe return to Python? <br clear="none">
<br clear="none">
/martin <br clear="none"><br clear="none"><div class="gmail_quote">On 15 Jul 2014, Rick Johnson &lt;rantingrickjohnson@gmail.com&gt; wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k10mail">On Monday, July 14, 2014 9:11:47 PM UTC-5, Chris Angelico wrote:<br clear="none"></pre><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">I dunno. It's not like Great Britain, Australia, or New<br clear="none">Zealand did anything significant in either war, is it.</blockquote><br clear="none">Most of Europe occupied, London bombed into the stone age;<br clear="none">things were looking grim Chris! Maybe you should read up on<br clear="none">some WW2 history, it's quite humbling to think what *could*<br clear="none">have happened.<br clear="none"><br clear="none"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">Some people in Australia are still racist, but racism is<br clear="none">nothing like the problem it is in America, where you boast<br clear="none">so much of equality.</blockquote><br clear="none">Where do you get your
info about America, from CNN? And for<br clear="none">someone who is a self-described "Aussie" you sure seem to<br clear="none">know more about Americans than Americans know about<br clear="none">themselves... hmm, another enigma!<br clear="none"><br clear="none">Chris, one thing you need to understand about America is<br clear="none">that a whole grievance industry exists to perpetuate hate.<br clear="none">And sadly, most Americans are too stupid to realize this.<br clear="none"><br clear="none">You see, a divided people are not going to cause the rulers<br clear="none">any troubles because they are too busy fighting amongst<br clear="none">themselves -- the same effect is employed in prison<br clear="none">populations to protect the guards.<br clear="none"><br clear="none">In ancient Rome, the Caesars used games and bread to control<br clear="none">the masses, today, they use the grievance industry and, for<br clear="none">the complete moronic zombies, sporting events.<br
clear="none"><br clear="none">All "isms" and social problems just boil down to hate. And<br clear="none">since you can never remove hate from the heart of man, you<br clear="none">will *NEVER* solve these issues. The best you can hope for<br clear="none">is to reduce the levels a bit via "intelligent interventions".<br clear="none"><br clear="none">So in short, none of these issues will ever be solved until<br clear="none">people realize who the real enemy is -&gt; themselves.<br clear="none"><br clear="none">MIRROR, MIRROR, ON THE WALL, WHO'S THE MOST JUDGMENTAL <br clear="none">OF THEM ALL?<br clear="none"><br clear="none"><hr><br clear="none">The origins of xenophobia:<br clear="none"><hr><br clear="none"><br clear="none">In order to defeat our own hatred of others, we must<br clear="none">circumvent our per-programmed primal fears, which is not<br clear="none">easy to do, and while these fears play a vital survival role<br clear="none">in *early* development of both the
*individuals* of a group<br clear="none">AND the group itself, in modern times, these fears have<br clear="none">become a crutch preventing humans from evolving socially.<br clear="none"><br clear="none">HENCE THE GRIEVANCE INDUSTRY PERPETRATED BY A MEDIA <br clear="none">CIRCUS THAT WILL DO ANYTHING TO GET RATINGS!<br clear="none"><br clear="none">====================<br clear="none">THOUGHT EXPERIMENT<br clear="none">====================<br clear="none"><br clear="none">Imagine your a small kitten: innocent, carefree, and full<br clear="none">of curiosity! You love exploring the world, stuffing<br clear="none">yourself into boxes, climbing to high places, and chasing<br clear="none">balls of strings -- ah what a life!<br clear="none"><br clear="none">You see your siblings and notice they have fur like you ,<br clear="none">and whiskers like you, and paws and tails and blah like<br clear="none">you. And you are comfortable because these other<br clear="none">"lifeforms" resemble
you, and so you consider them to be<br clear="none">"safe".<br clear="none"><br clear="none">Then one day, whilst frolicking in the backyard, you see a<br clear="none">glimmer from under a log, ooh, whats this you ask<br clear="none">rhetorically...?<br clear="none"><br clear="none">So you get closer to inspect, and you see two eyes, and<br clear="none">you think, hmm, it has two eyes just like my bothers and<br clear="none">sisters so it must be safe...!<br clear="none"><br clear="none">And so you get yet closer, but just then you start to<br clear="none">notice some differences, whoa, this thing has no fur, it<br clear="none">has no paws, and no whiskers, and it has strange patterns<br clear="none">on it's back and it's making a rattling noise, oh well, no<br clear="none">need to let fear get in my way, i'll just go over and<br clear="none">introduce myself... AND THAT WAS THE END OF "FLUFFY THE<br clear="none">KITTEN"!<br clear="none"><br clear="none">MEOW!<br clear="none"><br
clear="none">You see, since hate is merely an extrapolation of<br clear="none">xenophobia, which is itself a per-programmed reflex utilized<br clear="none">unconsciously to protect an organism from self destruction<br clear="none">via *utter* ignorance of dangerous predators, we are<br clear="none">fighting a losing battle when we expect the vast majority of<br clear="none">earths "intelligent" inhabitants, of which most are<br clear="none">zombie-fied *idiots*, to violate their own source code.<br clear="none"><br clear="none">JUST GO GRAB A BEER AND WATCH THE GAME YOU BEER-BELLIED FOOL!<br clear="none"><br clear="none">PS: That was a "general" you, not to be taken as a literal <br clear="none">statement to Chris.<br clear="none"></blockquote></div><br clear="none">-- Sent with <b><a shape="rect" href="https://play.google.com/store/apps/details?id=com.onegravity.k10.pro2">K-@ Mail</a></b> - the evolution of emailing.</body></html>


------1GJ5384F5LUDMOPLWUI11YBIVLX1ME--

0
Martin
7/15/2014 4:31:13 AM
On Tue, Jul 15, 2014 at 2:18 PM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
> On Monday, July 14, 2014 9:11:47 PM UTC-5, Chris Angelico wrote:
>> I dunno. It's not like Great Britain, Australia, or New
>> Zealand did anything significant in either war, is it.
>
> Most of Europe occupied, London bombed into the stone age;
> things were looking grim Chris! Maybe you should read up on
> some WW2 history, it's quite humbling to think what *could*
> have happened.

Yeah, because nobody managed to do anything during all that time, the
Royal Air Force was nowhere to be seen, and the various Resistances in
occupied countries were completely ineffectual.

>> Some people in Australia are still racist, but racism is
>> nothing like the problem it is in America, where you boast
>> so much of equality.
>
> Where do you get your info about America, from CNN? And for
> someone who is a self-described "Aussie" you sure seem to
> know more about Americans than Americans know about
> themselves... hmm, another enigma!

No... I have friends who are America experts. Actually, when I say
friends... they're more like family really. I don't want to scare you,
they can be a little bit inappropriate... and loud... and heavy.
Really, morbidly obese. I'm talking about the genuine article here,
and I converse with them on a daily basis.

And this is distinctly off-topic for this list. Talk about Python or
drop the issue, it really isn't as significant as you think it is.

ChrisA
0
Chris
7/15/2014 4:40:14 AM
On Mon, 14 Jul 2014 21:18:05 -0700, Rick Johnson wrote:

> London bombed into the stone age


Sigh. How can one even begin to answer a statement of such ignorance?


For what little it is worth, if any one country won World War Two, it was 
the USSR. I don't recall the exact numbers off the top of my head, but 
while the Brits and Americans were having a relatively easy time of it 
fighting the second-best German soldiers, the best, and by far the 
majority, of the German armed forces were on the Eastern Front engaged in 
the biggest, fiercest, most brutal battles of the war, bar none.

The Soviets destroyed the German airforce, smashed their tank battalions, 
bled their armies dry, then steamrolled over Eastern Europe, East 
Germany, and Berlin. The Western Front was, in comparison, a school 
picnic. One can understand why, following WW2, the western powers formed 
NATO and were so worried about the Red Army that they invited the Germans 
to join.


-- 
Steven
0
Steven
7/15/2014 5:41:29 AM
On 15/07/2014 05:40, Chris Angelico wrote:
> On Tue, Jul 15, 2014 at 2:18 PM, Rick Johnson
> <rantingrickjohnson@gmail.com> wrote:
>
> Yeah, because nobody managed to do anything during all that time, the
> Royal Air Force was nowhere to be seen, and the various Resistances in
> occupied countries were completely ineffectual.
>

Some might like to know that some US guys gave up their passports to 
fight with the RAF.  The most successful squadron during the Battle of 
Britain was 303 which was Polish flyers.  Apparently they were brilliant 
having learnt their trade flying biplanes against Messerschmitt BF109s.

1940 invasion of Britain?  No chance, we took years building the moat we 
call the English Channel.

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

Mark Lawrence

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


0
Mark
7/15/2014 7:05:10 AM
Le mardi 15 juillet 2014 05:58:05 UTC+2, Michael Torrie a =E9crit=A0:
> On 06/03/2014 12:12 AM, wxjmfauth@gmail.com wrote:
>=20
>=20
>=20
>=20
> Seems like jmf, though being a self-proclaimed unicode expert,
>=20
> continually confusing unicode with encoding schemes.
>=20
>=20
>=20

Sorry, but no. I have always been very consistent
and attempted to be very concise. Eg. not mixing
Unicode Transformation Unit and byte.

I you wish an example of a confused discussion,
read the pep 393 (?) discussion and you will see
how people are discussing Unicode without being
able to use a unicode terminology.

At least the Py core developper, who wrote
(I do not remember if it was in one of the
lists or a private mail and I do not remember
exactly the phrasing)

"If you are not happy, switch to Py 2.7,
use Ruby or try to convince the BDFL"=20

has, in my mind, a little bit more undersanding of
the situation.

jmf
0
wxjmfauth
7/15/2014 7:23:00 AM
My two cents as a new pythonista and a scientist: isn't python2 killing 
python? This old stuff is everywhere in the tutorials, docs, etc. and 
this is quite annoying. When I download a python notebook, the first 
thing I have to do is to translate it to py3. Which is not an easy task, 
given the fact that I am the tutorial *user* and am supposed to learn ;)

Side note: Debian/Ubuntu/Mint announced the total migration to python3, 
which is good but still work in progress:
https://wiki.ubuntu.com/Python/3
0
Fabien
7/15/2014 12:17:54 PM
On Mon, 14 Jul 2014 21:18:05 -0700, Rick Johnson wrote:

> On Monday, July 14, 2014 9:11:47 PM UTC-5, Chris Angelico wrote:
>> I dunno. It's not like Great Britain, Australia, or New Zealand did
>> anything significant in either war, is it.
> 
> Most of Europe occupied, London bombed into the stone age; things were
> looking grim Chris! Maybe you should read up on some WW2 history, it's
> quite humbling to think what *could* have happened.

Perhaps you should read history more thoroughly.
Great Britain had successfully fended off German plans to invade BEFORE 
the USA joined the war (Google Battle of Britain). Had we failed there 
would have been nowhere available to launch the 'D' Day landings & the 
USSR would almost certainly have rolled over the whole of Europe.

so contrary to the much held belief by Americans that they saved or 
bottoms in WWII the opposite is in fact the case.
  
> 
>> Some people in Australia are still racist, but racism is nothing like
>> the problem it is in America, where you boast so much of equality.
> 
> Where do you get your info about America, from CNN? And for someone who
> is a self-described "Aussie" you sure seem to know more about Americans
> than Americans know about themselves... hmm, another enigma!

I guarantee he knows more about he USA than the average Ammerican knows 
about Australia or anywhere outside their own border, I once had an 
American ask what state London was in (& we are quite a big part of your 
history)!

> 
> Chris, one thing you need to understand about America is that a whole
> grievance industry exists to perpetuate hate.
> And sadly, most Americans are too stupid to realize this.

Now that is the 1st thing you have read that I agree with 100%

-- 
You'll never see all the places, or read all the books, but fortunately,
they're not all recommended.
0
alister
7/15/2014 12:30:11 PM
On Tue, Jul 15, 2014 at 10:17 PM, Fabien <fabien.maussion@gmail.com> wrote:
> My two cents as a new pythonista and a scientist: isn't python2 killing
> python?

You're new to Python, and so you correctly want to work with Python 3.
That's fine. That's excellent, in fact. You're starting out the right
way, and avoiding all the problems that Py3 specifically set out to
solve.

However, people-new-to-Python is not the only audience that the
language supports. Everyone who *already has code*, written for (say)
Python 2.5, wants some sort of assurance that it will still be
runnable. It's a matter of trust; python.org implicitly promises that
it's not a waste of time writing code in Python, and that's a promise
that would be broken by cutting off Py2 support.

The problem isn't Python 2, nor Python 3, nor even the fact that there
are two Pythons. The problem is that a lot of people don't understand
when to choose one or the other, don't understand what the promises of
support are, and (perhaps worst of all) keep hearing FUD about how
Python 3 is killing Python. And so the confusion perpetuates.
Eventually the world will get past that, but in the meantime, we have
to deal with these sorts of storms-in-teacups from people who simply
cannot comprehend what's going on.

ChrisA
0
Chris
7/15/2014 1:00:51 PM
Le mardi 15 juillet 2014 14:17:54 UTC+2, Fabien a =E9crit=A0:
> My two cents as a new pythonista and a scientist: isn't python2 killing=
=20
>=20
> python? This old stuff is everywhere in the tutorials, docs, etc. and=20
>=20
> this is quite annoying. When I download a python notebook, the first=20
>=20
> thing I have to do is to translate it to py3. Which is not an easy task,=
=20
>=20
> given the fact that I am the tutorial *user* and am supposed to learn ;)
>=20
>=20
>=20
> Side note: Debian/Ubuntu/Mint announced the total migration to python3,=
=20
>=20
> which is good but still work in progress:
>=20
> https://wiki.ubuntu.com/Python/3

------

One more good reason to stay away from these
products.

jmf
0
wxjmfauth
7/15/2014 1:33:00 PM
On 7/15/14, 9:00 AM, Chris Angelico wrote:
> The problem isn't Python 2, nor Python 3, nor even the fact that there
> are two Pythons. The problem is that a lot of people don't understand
> when to choose one or the other, don't understand what the promises of
> support are, and (perhaps worst of all) keep hearing FUD about how
> Python 3 is killing Python. And so the confusion perpetuates.
> Eventually the world will get past that, but in the meantime, we have
> to deal with these sorts of storms-in-teacups from people who simply
> cannot comprehend what's going on.

I think it's more than a tempest in a teacup.

The number of language revisions that result in deliberate, code-level 
incompatibility out there is pretty small. People rightly expect that 
code written for version 2.x of a language will continue to work with 
version 3.x, even if 3.x is designed to go in another direction.

I can only think of two widely used languages in the last decade where 
there was this type of major break in binary compatibility: Perl and 
Visual Basic. Perl 6 is kind of a moot point because it's never shipped 
(insert reference to Duke Nukem or GNU HURD here, as appropriate), and 
Perl 5 has not just seen continued development, but invigorated 
development in recent years. But the example of VB is instructive. 
VB.NET is similar, but not identical, to classic VB, and as far as I am 
aware its uptake has not been nearly as wide as classic VB. Microsoft 
was able to force what limited migration we've seen mainly because VB is 
not open source and they can simply drop support for it from Windows.

I've stayed with Python 2.7 because I've seen no benefit in 3.x that 
outweighs the hassle of going through my code line by line to make it 
compatible. As a Mac developer I deal with this kind of code/API churn 
with each release of Mac OS X, and I have no desire to increase my 
headaches.

Though I expect I will eventually update to 3.x, however, like many 
other developers I am also annoyed by the decision to break backwards 
compatibility in Python. The decision strikes me as arrogant. Cruft and 
backwards compatibility are an inevitable part of any mature programming 
language, and maintaining compatibility is important--more important 
than bolting on shiny new features, in my view. If shiny new features 
must be added, they should be added side-by-side with older API's.

I think the Python developers have undervalued the conservator part of 
their role. Yes, they have provided tools to help application and 
library developers migrate their code, but it should not be incumbent on 
third-party developers to re-architect stable, working code simply 
because the language has broken binary compatibility. Defenders of the 
3.x migration portray such developers as laggards, but I see Python 
3.x's failure to silently and successfully import 2.x code as a failure 
on the language's end.

I won't go so far as to say that Python 3 is killing Python. Python will 
survive. But the headaches of migration are substantial, and should not 
be necessary.

--Kevin

-- 
Kevin Walzer
Code by Kevin/Mobile Code by Kevin
http://www.codebykevin.com
http://www.wtmobilesoftware.com
0
Kevin
7/15/2014 1:57:15 PM
On Tue, Jul 15, 2014 at 11:57 PM, Kevin Walzer <kw@codebykevin.com> wrote:
> The number of language revisions that result in deliberate, code-level
> incompatibility out there is pretty small. People rightly expect that code
> written for version 2.x of a language will continue to work with version
> 3.x, even if 3.x is designed to go in another direction.

That's not strictly true. I would generally expect some concept of
version numbering along the lines of semver.org's recommendations, or
the Debian packaging guidelines (I think), or, or, or, or, or. You
know the sort of thing: major.minor.revision, where "revision" changes
shouldn't break anything unless you were, perhaps unwittingly,
depending on a bug; "minor" changes add features, and might break code
that was, say, using a new language keyword as an identifier (eg you
can use "with" as a function name in Python 2.4, but in Python 2.6
that won't work); and "major" changes can cause backward
incompatibility. That's not absolutely strictly true of all Python
versions, but it's certainly very close.

You would expect Python version 3.x to be broadly the same language as
Python 2.x, but you cannot expect code to automatically run
unmodified. That's the whole point of a major version number change.
And that's exactly what we see; the similarities between Python 2.7
and 3.4 are pretty huge compared to the differences. They are
definitely the same language.

> I can only think of two widely used languages in the last decade where there
> was this type of major break in binary compatibility: Perl and Visual Basic.

ANSI C broke quite a bit compared to previous C implementations.
Doesn't have quite a "version number", but it's the same concept.
Object REXX (OREXX) breaks several things in Classic REXX (REXX). Both
of those precede "the last decade", but I'd say the same thing
applies: if the name or major version number changes, you can expect
differences.

(For this reason, I have never actually released a RosMud version 2.0;
once I went stable with 1.0, I never needed to make
backward-incompatible changes. The latest - and probably last -
version is 1.7.0, and the project has been succeeded by Gypsum, which
is a brand new project... new name, incompatible APIs.)

> I've stayed with Python 2.7 because I've seen no benefit in 3.x that
> outweighs the hassle of going through my code line by line to make it
> compatible.

And that's fine! The python-dev team has promised that 2.7 will
continue to be supported; that means some headaches, especially on
Windows (the Python 2.7 support will long outlast upstream Microsoft
support for the compiler it's built on), but it's a promise that you
can continue to run your 2.7 code.

That said, though, I would advise you to give 2to3 a shot. You never
know, it might do exactly what you need right out-of-the-box and give
you a 3.x-compatible codebase in one hit.

> Though I expect I will eventually update to 3.x, however, like many other
> developers I am also annoyed by the decision to break backwards
> compatibility in Python. The decision strikes me as arrogant. Cruft and
> backwards compatibility are an inevitable part of any mature programming
> language, and maintaining compatibility is important--more important than
> bolting on shiny new features, in my view. If shiny new features must be
> added, they should be added side-by-side with older API's.

Big problem with that: it means that everyone who learns the language
has to wrestle with *both* APIs. It's impossible to fix bugs. So how
about this as a compromise: We'll have this special flag at the top of
the program that says whether it should be in "compatibility mode" or
"shiny new features mode". And hey, let's write it like this:

#!/usr/local/bin/python2
# This program runs in compatibility mode.

#!/usr/local/bin/python3
# This program gets all the new features.

Python *is* maintaining backward compatibility. It's fundamentally not
possible to add some of Python 3's features without some pretty big
changes (look at, for instance, the str/bytes changes - essential to
proper i18n, but impossible to do to a Py2-compatible interpreter), so
the only way to do it is to continue to support Py2 while doing new
development on Py3.

> I think the Python developers have undervalued the conservator part of their
> role.

No, they haven't. That's exactly why Python 2.7 is to be supported for
so long (2020 according to current plans), and why PEP 466 and such
are so important. There's a lot of Python 2 code out there, and
python-dev's taking the responsibility very seriously.

> ... I see Python 3.x's failure to silently and
> successfully import 2.x code as a failure on the language's end.

Fine. Tell me how you would go about adding true Unicode support to
Python 2.7, while still having it able to import an unchanged program.
Trick question - it's fundamentally impossible, because an unchanged
program will not distinguish between bytes and text, but true Unicode
support requires that they be distinguished. The best you could do
would be to rewrite your code into some kind of hybrid, which would
then be able to run on both versions; there are ways of doing this,
but if you're going to rewrite your code, you may as well go straight
to Py3 and take advantage of its features.

Ultimately, the solution is simply to keep Python 2.7 around for a
good long time, until the carrot of new Py3 features becomes
attractive enough for it to be worth switching. And if that's not
before 2020, no problem. Even if it's after 2020, there's a fair
chance that you'll still be able to run your 2.7 code - it's just that
there's no promise (at the moment) of patches, even security patches,
from python.org. If you're running RHEL, you might get full support
for several more years after 2020. That's a pretty long time, when you
consider that Python 3.1 came out in 2009.

ChrisA
0
Chris
7/15/2014 2:31:31 PM
On 2014-07-15 13:19, alister wrote:
>>
>> Image, for a moment, a world WITHOUT the great USA! Yes, i know
>> you little commies love to curse the USA, and yes, there are many
>> dark sins committed within AND beyond her borders, but try to tell
>> me you bass-turds, what nation in modern history has contributed
>> more technological achievements [1]
>
> The one you revolted from. The Same one that is your first port of
> call for assistance whenever you get yourselves involved in
> conflict.
>
> I think you will find that more inventions have originated on this
> desolate windswept island of the north coast of Europe than the USA.
>
I'd say it's more north-west than north.

> We are called Great Britain, the clue is in the name.
>
"Great Britain" is the name of the largest island in the "British
Isles".
0
MRAB
7/15/2014 2:50:46 PM
Kevin Walzer <kw@codebykevin.com> writes:

> I can only think of two widely used languages in the last decade where
> there was this type of major break in binary compatibility: Perl and
> Visual Basic.

 Lua 5.1, 5.2 and 5.3 are all incompatible to some extent. It's
debatable how widely used Lua is as a stand-alone language, but the
usage is pretty widespread; it's just mostly concealed inside another
application.

-- 
/Wegge

Leder efter redundant peering af dk.*,linux.debian.*
0
Anders
7/15/2014 3:02:30 PM
On 15/07/2014 13:19, alister wrote:
>>
>> Image, for a moment, a world WITHOUT the great USA! Yes, i know you
>> little commies love to curse the USA, and yes,
>> there are many dark sins committed within AND beyond her borders, but
>> try to tell me you bass-turds, what nation in modern history has
>> contributed more technological achievements [1]
>
> I think you will find that more inventions have originated on this
> desolate windswept island of the north coast of Europe than the USA.
>

Like the technology that was used to break the sound barrier?  Handed to 
the Yanks in a deal that they promptly broke but refused to hand the 
technology back.  Special relationship, yep, they were kind enough to 
give us 60 years to pay off the loans we took out during WWII.  As 
Aurthur Daley used to say "nice little earner".

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

Mark Lawrence

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


0
Mark
7/15/2014 3:35:35 PM
On 2014-07-15, Kevin Walzer <kw@codebykevin.com> wrote:

> I think it's more than a tempest in a teacup.
>
> The number of language revisions that result in deliberate, code-level 
> incompatibility out there is pretty small. People rightly expect that 
> code written for version 2.x of a language will continue to work with 
> version 3.x, even if 3.x is designed to go in another direction.

I disagree.  I don't expect backwards compatability across major
version number changes.  I've been doing software development for 30
years, and that has always been a pretty common rule for the projects
I've worked on.

-- 
Grant Edwards               grant.b.edwards        Yow! I feel partially
                                  at               hydrogenated!
                              gmail.com            
0
Grant
7/15/2014 3:43:02 PM
On 15/07/2014 15:31, Chris Angelico wrote:
> On Tue, Jul 15, 2014 at 11:57 PM, Kevin Walzer <kw@codebykevin.com> wrote:
>
>> I've stayed with Python 2.7 because I've seen no benefit in 3.x that
>> outweighs the hassle of going through my code line by line to make it
>> compatible.
>
> And that's fine! The python-dev team has promised that 2.7 will
> continue to be supported; that means some headaches, especially on
> Windows (the Python 2.7 support will long outlast upstream Microsoft
> support for the compiler it's built on), but it's a promise that you
> can continue to run your 2.7 code.
>
> That said, though, I would advise you to give 2to3 a shot. You never
> know, it might do exactly what you need right out-of-the-box and give
> you a 3.x-compatible codebase in one hit.
>

Or any one of

https://pypi.python.org/pypi/six/1.7.3
https://github.com/mitsuhiko/python-modernize
http://python-future.org/
https://github.com/nandoflorestan/nine

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

Mark Lawrence

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


0
Mark
7/15/2014 3:44:34 PM
On Wed, Jul 16, 2014 at 1:44 AM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
> Or any one of
>
> https://pypi.python.org/pypi/six/1.7.3
> https://github.com/mitsuhiko/python-modernize
> http://python-future.org/
> https://github.com/nandoflorestan/nine

AIUI most of those sorts of things are designed for people maintaining
a dual-version codebase, not for making a one-time switch. But yes,
there are a variety of tools to help make the changes necessary.

ChrisA
0
Chris
7/15/2014 3:48:41 PM
Chris Angelico <rosuav@gmail.com>:

> Fine. Tell me how you would go about adding true Unicode support to
> Python 2.7, while still having it able to import an unchanged program.
> Trick question - it's fundamentally impossible, because an unchanged
> program will not distinguish between bytes and text, but true Unicode
> support requires that they be distinguished.

Python 2 has always had unicode strings and [byte] strings. They were
always clearly distinguished. You really didn't have to change anything
for "true Unicode support".

> you may as well go straight to Py3 and take advantage of its features.

The first real new feature in Python 3 is asyncio. I've been perfectly
happy with select.epoll myself and written my own 50-line asyncio
equivalents so it remains to be seen how much traction asyncio will
have.


Marko
0
Marko
7/15/2014 5:38:40 PM
On Tue, 15 Jul 2014 15:50:46 +0100, MRAB wrote:

> On 2014-07-15 13:19, alister wrote:
>>>
>>> Image, for a moment, a world WITHOUT the great USA! Yes, i know you
>>> little commies love to curse the USA, and yes, there are many dark
>>> sins committed within AND beyond her borders, but try to tell me you
>>> bass-turds, what nation in modern history has contributed more
>>> technological achievements [1]
>>
>> The one you revolted from. The Same one that is your first port of call
>> for assistance whenever you get yourselves involved in conflict.
>>
>> I think you will find that more inventions have originated on this
>> desolate windswept island of the north coast of Europe than the USA.
>>
> I'd say it's more north-west than north.

Doesn't roll of the tongue as well though
> 
>> We are called Great Britain, the clue is in the name.
>>
> "Great Britain" is the name of the largest island in the "British
> Isles".

Never let the facts get in the way of a good punchline :-)



-- 
The one day you'd sell your soul for something, souls are a glut.
0
alister
7/15/2014 5:38:56 PM
Rick Johnson <rantingrickjohnson@gmail.com>:

> So in other words, "we're" know now we made a bad decision by creating
> this Python3000 thing, because nobody seems to be jumping on the
> bandwagon, but instead of admitting we were wrong, we'll just cling to
> our new shiny *THING* and hope *EVENTUALLY*, if we brow-beat *ENOUGH*
> people, that well, *MAYBE* most of them will embrace this *ABORTION*
> and join us.

I agree it was a grave mistake. However, what's done is done. Instead of
fighting it or defending it, just cope with it and move on.


Marko
0
Marko
7/15/2014 6:08:03 PM
On 2014-07-15, alister <alister.nospam.ware@ntlworld.com> wrote:

> Never let the facts get in the way of a good punchline :-)

Ah!

That explains it!

The Iraq war must have been a _joke_.  It sure went over my head...

-- 
Grant Edwards               grant.b.edwards        Yow! My Aunt MAUREEN was a
                                  at               military advisor to IKE &
                              gmail.com            TINA TURNER!!
0
Grant
7/15/2014 6:23:17 PM
On Tue, 15 Jul 2014 11:01:53 -0700, Rick Johnson wrote:

> Are you so foolish as to believe that if code runs cleanly *immediately*
> after translating via "2to3", that the code is now completely free from
> translation bugs?

If your code has a thorough set of unittests that continue to pass, then 
changes are better than excellent that it is free of translation bugs.


> You act as if 2to3 is some "magical" code that can root out every bug no
> matter how subtle.

Of course not. 2to3 certainly won't remove bugs that already exist in 
your code. It will happily translate them to version 3 dialect for you, 
so you can have the fun of fixing them yourself.


[...snip foolish grandstanding...]

>> Ultimately, the solution is simply to keep Python 2.7 around for a good
>> long time, until the carrot of new Py3 features becomes attractive
>> enough for it to be worth switching. And if that's not before 2020, no
>> problem. Even if it's after 2020, there's a fair chance that you'll
>> still be able to run your 2.7 code -
> 
> So in other words, "we're" know now we made a bad decision by creating
> this Python3000 thing, because nobody seems to be jumping on the
> bandwagon,

Don't be childish.

There are still people using Python 2.3. There are even a few people -- 
just a handful -- happily using Python 1.5, which is probably older than 
you. People have all sorts of reasons for sticking to what works, instead 
of jumping from version to version and having to deal with code churn 
every 18 months. And they have the right to do so. No adult expect them 
to upgrade just because there is a new version out.

Redhat still offers commercial support for Python 2.4. I believe that 
Python 2.3 has only *just* come out of commercial support a few months 
ago. Some people will upgrade, some are happy to keep using a product 
that works, and require no support. The choice is theirs.

The same will apply to Python 2.7. The Python developers have promised to 
give 2.7 extended support until 2020, and Red Hat has committed to 
extended commercial support until 2023. Capitalism at work: Red Hat 
expects to be able to make money from supporting this for nearly another 
decade, and good on them.

[...snip childish insults...]

>> it's just that there's no promise (at the moment) of patches, even
>> security patches, from python.org.
> 
> Oh yes, i see... when brow-beating does not work, we adopt the
> malevolent tactics of $MS  and $OS by allowing security holes and virus
> infections to riddle the code base obsolete.

No software developer is obliged to support their software forever, 
especially if they are giving it away for free, and writing it out of 
love. Nobody but nobody is supporting Python 1.1 any more, no matter how 
many security holes it has. So what? Who cares?

Python 2.7 is open source software, if you think that there is a market 
for providing support for it for the next twenty years, go right ahead. 
You can even charge money for it.

But of course you won't. Because it's much easier to bitch and moan and 
pretend to be oh-so-superior than to actually write code, fix bugs, and 
provide support.



-- 
Steven
0
Steven
7/15/2014 6:53:27 PM
On Tue, Jul 15, 2014 at 12:01 PM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
> On Tuesday, July 15, 2014 9:31:31 AM UTC-5, Chris Angelico wrote:
>> [...] That said, though, I would advise you to give 2to3 a
>> shot. You never know, it might do exactly what you need
>> right out-of-the-box and give you a 3.x-compatible
>> codebase in one hit.
>
> Ha!
>
> Are you so foolish as to believe that if code runs cleanly
> *immediately* after translating via "2to3", that the code is
> now completely free from translation bugs?
>
> You act as if 2to3 is some "magical" code that can root out
> every bug no matter how subtle. No, for those of us who care
> about our reputation, we are not about to release code that
> could blow chunks and leave egg all over our face, or worse,
> cause us to loose a contract!

This is what tests are for: so you know whether your code is working or not.

1) Run 2to3.
2) Run your test suite.
3) If there's a UI, exercise it manually.

At that point you should know how many things you need to fix. If that
number is 0, then you're basically ready to release (depending on your
test coverage and your release cycle and your overall level of comfort
with releasing the result).
0
Ian
7/15/2014 6:53:31 PM
On Tue, 15 Jul 2014 21:08:03 +0300, Marko Rauhamaa wrote:

> I agree it was a grave mistake.

On what basis do you believe it was a mistake?



-- 
Steven
0
Steven
7/15/2014 6:57:49 PM
On Tue, 15 Jul 2014 20:38:40 +0300, Marko Rauhamaa wrote:

> Python 2 has always had unicode strings and [byte] strings. They were
> always clearly distinguished. You really didn't have to change anything
> for "true Unicode support".

If that were true, then migrating from Python 2 to 3 would be much 
simpler than it is.

Unicode strings in Python 2 are second class entities. It's not just that 
people will, in general, take the lazy way and write "foo" instead of 
u"foo" for their strings. But it is that the whole Python virtual machine 
is based on byte-strings, not Unicode strings, and u"" strings are bolted 
on top.

[steve@ando ~]$ python3.3 -c "π = 3.14; print(π+1)"
4.140000000000001
[steve@ando ~]$ python2.7 -c "π = 3.14; print(π+1)"
  File "<string>", line 1
    π = 3.14; print(π+1)
    ^
SyntaxError: invalid syntax

Python 2 "helpfully" tries to guess what you want when you work with 
bytes-pretending-to-be-strings, and when it guesses right, it's nice, but 
when it guesses wrongly, you'll left with mysterious encoding and 
decoding errors from code that don't appear to involve either. The whole 
thing is a mess.



-- 
Steven
0
Steven
7/15/2014 7:06:23 PM
Steven D'Aprano <steve+comp.lang.python@pearwood.info>:

> On Tue, 15 Jul 2014 21:08:03 +0300, Marko Rauhamaa wrote:
>
>> I agree it was a grave mistake.
>
> On what basis do you believe it was a mistake?

The supposed flaws in Python 2 weren't a good enough reason to break
backward-compatibility.


Marko
0
Marko
7/15/2014 7:49:07 PM
Steven D'Aprano <steve+comp.lang.python@pearwood.info>:

> Unicode strings in Python 2 are second class entities.

I don't see that. They form a type just like, say, complex.

> It's not just that people will, in general, take the lazy way and
> write "foo" instead of u"foo" for their strings.

People live with their choices, and I don't see the consequences of that
lazy way as very bad.

In fact, I find the lazy use of Unicode strings at least as scary as the
lazy use of byte strings, especially since Python 3 sneaks Unicode to
the outer interfaces of the program (files, IPC).

> But it is that the whole Python virtual machine is based on
> byte-strings, not Unicode strings, and u"" strings are bolted on top.

The internal implementation of the VM is free to change as long as the
external semantics stay the same.

> [steve@ando ~]$ python3.3 -c "π = 3.14; print(π+1)"
> 4.140000000000001
> [steve@ando ~]$ python2.7 -c "π = 3.14; print(π+1)"
>   File "<string>", line 1
>     π = 3.14; print(π+1)
>     ^
> SyntaxError: invalid syntax

My native language uses ä and ö, but I don't see any pressing need to
embed those characters in identifiers.

> Python 2 "helpfully" tries to guess what you want when you work with 
> bytes-pretending-to-be-strings, and when it guesses right, it's nice, but 
> when it guesses wrongly, you'll left with mysterious encoding and 
> decoding errors from code that don't appear to involve either. The whole 
> thing is a mess.

I can't think of a matching example.


Marko
0
Marko
7/15/2014 8:01:25 PM
On Tuesday, July 15, 2014 1:53:27 PM UTC-5, Steven D'Aprano wrote:

> No software developer is obliged to support their software
> forever, especially if they are giving it away for free
> [...] Nobody but nobody is supporting Python 1.1 any more,
> no matter how many security holes it has.

Of course not, Python 1.1 is pre-1999, heck, it's so old i
cannot find a release date for it, and it's probably
completely useless in today's world

    BUT THAT IS NOT MY POINT!

What you fail to realize is that the *MAJORITY* of Python
programmers cut their teeth on the Python 2.x line, and as
such, the majority of today's Python programmers are still
using the Python 2.x line -- anything to with Python 1.1
might as well be ancient history, it's irrelevant due to age
and it's abysmal utilization.

Python's popularity started increasing significantly only
*AFTER* Python 2 was rolled out. If you look at the TIOBE
stats (2003-2013), Python made the *MOST* improvements in
the years of 2007 and 2013

    PYTHON-2.0.1 WAS RELEASED ON JUNE 22, 2001

But nothing *significant* happened until Python-2.5

    PYTHON-2.5.0 WAS RELEASED ON SEPT. 19, 2006
    
Which coincides with the spike of 2007!

Now begs the question, what caused the 2013 spike? Simple,
the 2013 spike was a result of all the *BUZZ* of Python-3000,
NOT *BECAUSE* OF PYTHON-3000, but, because of the *BUZZ*.

Remember, GvR went on an extensive campaign to sale this
"new and improved" snake oil, with all his Google speeches
and evangelizing and whatnot. But very quickly the
"curiosity" and "excitement" turned into the "summer of
discontent".

I remember watching some speeches where the audience was not
at all pleased with the breaks and "great new
functionality".

The blogisphere has been set ablaze with bemoaning of
breaking code over such "miniscule" things as lazy
iterators, print, input,etc... and the misguided attempts to
"sanitize" Python of functional programming!
    
    SHOULD I DRAW YOU A "MAP"?
    
I think we can all agree that the roll out of Python3 was
not as "smooth" as the dictator has expected

Also, keep in mind that most of the tutorials and books out
there are written for Python 2.x, whereas Python 3.x is very
limited[1]. Too many noobs have downloaded Python3 and
whilst unwittingly following a "Googled tutorial" or book,
get hammered with esoteric exception messages and then
quickly give up and move on to another language, unaware
that the versions are incompatible in many respects.

Kind of sad when you realize that most of the functions that
were broken are the same functions a noob is using during "day
one" (print, input, etc...)

2.x also has years and years of *MATURE* third party modules
for the taking, whereas Python 3.x is quite disappointing[1].

> Python 2.7 is open source software, if you think that
> there is a market for providing support for it for the
> next twenty years, go right ahead

There *WILL* be a market for Python for the next ten or so
years no matter what happens to Python3! Since the vast
majority of Python code (in the wild) is written in the 2.x
line (most likely written using Python-2.5), python-3000 was
a lame duck before it was even released!

    print("QUACK!")


[1]: yes, yes, i know there are 3.x resources but no where even
     close to 2.x!


0
Rick
7/15/2014 8:20:07 PM
On 15/07/2014 18:38, Marko Rauhamaa wrote:
> Chris Angelico <rosuav@gmail.com>:
>
>> Fine. Tell me how you would go about adding true Unicode support to
>> Python 2.7, while still having it able to import an unchanged program.
>> Trick question - it's fundamentally impossible, because an unchanged
>> program will not distinguish between bytes and text, but true Unicode
>> support requires that they be distinguished.
>
> Python 2 has always had unicode strings and [byte] strings. They were
> always clearly distinguished. You really didn't have to change anything
> for "true Unicode support".
>

That is the funniest tongue in cheek comment I've read in the 10+ years 
I''ve been hanging around here.  It was tongue in cheek, wasn't it?

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

Mark Lawrence

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


0
Mark
7/15/2014 8:24:07 PM
On Tue, Jul 15, 2014 at 2:20 PM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
> On Tuesday, July 15, 2014 1:53:27 PM UTC-5, Steven D'Aprano wrote:
>
>> No software developer is obliged to support their software
>> forever, especially if they are giving it away for free
>> [...] Nobody but nobody is supporting Python 1.1 any more,
>> no matter how many security holes it has.
>
> Of course not, Python 1.1 is pre-1999, heck, it's so old i
> cannot find a release date for it, and it's probably
> completely useless in today's world
>
>     BUT THAT IS NOT MY POINT!
>
> What you fail to realize is that the *MAJORITY* of Python
> programmers cut their teeth on the Python 2.x line, and as
> such, the majority of today's Python programmers are still
> using the Python 2.x line -- anything to with Python 1.1
> might as well be ancient history, it's irrelevant due to age
> and it's abysmal utilization.

When Python 2.0 was released, the majority of Python programmers at
the time had learned on Python 1.x, and for a while the majority of
them were still using 1.x. That's the same situation you're describing
today. At some point in the future, Python 2.x will be "ancient
history" also.

> Python's popularity started increasing significantly only
> *AFTER* Python 2 was rolled out. If you look at the TIOBE
> stats (2003-2013), Python made the *MOST* improvements in
> the years of 2007 and 2013
>
>     PYTHON-2.0.1 WAS RELEASED ON JUNE 22, 2001
>
> But nothing *significant* happened until Python-2.5

Seriously? If you ask me, the changes introduced in 2.2 were a lot
more significant than anything in 2.5. 2.2 fixed the type system by
giving us new-style classes. It also added the iterator interface,
introduced generators, and removed the distinction between int and
long. All of those things were huge. What did Python 2.5 add?
Conditional expressions and the with statement, both of which are
useful but not nearly as compelling.

> Now begs the question, what caused the 2013 spike? Simple,
> the 2013 spike was a result of all the *BUZZ* of Python-3000,
> NOT *BECAUSE* OF PYTHON-3000, but, because of the *BUZZ*.

Python 3.0 was released in 2008. I don't understand why you think the
buzz surrounding that would have occurred 5 years later.

> Remember, GvR went on an extensive campaign to sale this
> "new and improved" snake oil, with all his Google speeches
> and evangelizing and whatnot. But very quickly the
> "curiosity" and "excitement" turned into the "summer of
> discontent".

No, I have no idea what you're referring to. If Guido was talking more
about Python 3 in 2012 than at any time in the six years prior, then I
for one didn't notice.

> [1]: yes, yes, i know there are 3.x resources but no where even
>      close to 2.x!

Actually, the Wall of Superpowers is showing quite a lot of green these days.

https://python3wos.appspot.com/
0
Ian
7/15/2014 8:46:35 PM
On Tue, Jul 15, 2014 at 1:24 PM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
> On 15/07/2014 18:38, Marko Rauhamaa wrote:
>>
>> Chris Angelico <rosuav@gmail.com>:
>>
>>> Fine. Tell me how you would go about adding true Unicode support to
>>> Python 2.7, while still having it able to import an unchanged program.
>>> Trick question - it's fundamentally impossible, because an unchanged
>>> program will not distinguish between bytes and text, but true Unicode
>>> support requires that they be distinguished.
>>
>>
>> Python 2 has always had unicode strings and [byte] strings. They were
>> always clearly distinguished. You really didn't have to change anything
>> for "true Unicode support".
>>
>
> That is the funniest tongue in cheek comment I've read in the 10+ years
> I''ve been hanging around here.  It was tongue in cheek, wasn't it?

What isn't "true" about Python 2.x's unicode support? The only feature
I ever missed was case folding. (Not that 3.x does much better at that... :)

The stdlib had poor unicode support, if that's what you mean. That
could've been fixed without introducing backwards-incompatible
changes, though.

-- Devin
0
Devin
7/15/2014 8:47:22 PM
--001a11346d5c68664404fe42318f
Content-Type: text/plain; charset=UTF-8

Umm..Guido Van Rossum said in Pycon 2014 that Py 2.x would be supported
only until 2015 :-| So...you know.. you have like an year before you *do *have
to migrate to 3.x .


On Wed, Jul 16, 2014 at 2:17 AM, Devin Jeanpierre <jeanpierreda@gmail.com>
wrote:

> On Tue, Jul 15, 2014 at 1:24 PM, Mark Lawrence <breamoreboy@yahoo.co.uk>
> wrote:
> > On 15/07/2014 18:38, Marko Rauhamaa wrote:
> >>
> >> Chris Angelico <rosuav@gmail.com>:
> >>
> >>> Fine. Tell me how you would go about adding true Unicode support to
> >>> Python 2.7, while still having it able to import an unchanged program.
> >>> Trick question - it's fundamentally impossible, because an unchanged
> >>> program will not distinguish between bytes and text, but true Unicode
> >>> support requires that they be distinguished.
> >>
> >>
> >> Python 2 has always had unicode strings and [byte] strings. They were
> >> always clearly distinguished. You really didn't have to change anything
> >> for "true Unicode support".
> >>
> >
> > That is the funniest tongue in cheek comment I've read in the 10+ years
> > I''ve been hanging around here.  It was tongue in cheek, wasn't it?
>
> What isn't "true" about Python 2.x's unicode support? The only feature
> I ever missed was case folding. (Not that 3.x does much better at that...
> :)
>
> The stdlib had poor unicode support, if that's what you mean. That
> could've been fixed without introducing backwards-incompatible
> changes, though.
>
> -- Devin
> --
> https://mail.python.org/mailman/listinfo/python-list
>



-- 
Abhiram.R
M.Tech CSE (Sem 3)
RVCE
Bangalore

--001a11346d5c68664404fe42318f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:georgia,=
serif">Umm..Guido Van Rossum said in Pycon 2014 that Py 2.x would be suppor=
ted only until 2015 :-| So...you know.. you have like an year before you <i=
>do </i>have to migrate to 3.x .=C2=A0</div>

</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Wed,=
 Jul 16, 2014 at 2:17 AM, Devin Jeanpierre <span dir=3D"ltr">&lt;<a href=3D=
"mailto:jeanpierreda@gmail.com" target=3D"_blank">jeanpierreda@gmail.com</a=
>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"">On Tue, Jul 15, 2014 at 1:24=
 PM, Mark Lawrence &lt;<a href=3D"mailto:breamoreboy@yahoo.co.uk">breamoreb=
oy@yahoo.co.uk</a>&gt; wrote:<br>


&gt; On 15/07/2014 18:38, Marko Rauhamaa wrote:<br>
&gt;&gt;<br>
&gt;&gt; Chris Angelico &lt;<a href=3D"mailto:rosuav@gmail.com">rosuav@gmai=
l.com</a>&gt;:<br>
&gt;&gt;<br>
&gt;&gt;&gt; Fine. Tell me how you would go about adding true Unicode suppo=
rt to<br>
&gt;&gt;&gt; Python 2.7, while still having it able to import an unchanged =
program.<br>
&gt;&gt;&gt; Trick question - it&#39;s fundamentally impossible, because an=
 unchanged<br>
&gt;&gt;&gt; program will not distinguish between bytes and text, but true =
Unicode<br>
&gt;&gt;&gt; support requires that they be distinguished.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; Python 2 has always had unicode strings and [byte] strings. They w=
ere<br>
&gt;&gt; always clearly distinguished. You really didn&#39;t have to change=
 anything<br>
&gt;&gt; for &quot;true Unicode support&quot;.<br>
&gt;&gt;<br>
&gt;<br>
&gt; That is the funniest tongue in cheek comment I&#39;ve read in the 10+ =
years<br>
&gt; I&#39;&#39;ve been hanging around here. =C2=A0It was tongue in cheek, =
wasn&#39;t it?<br>
<br>
</div>What isn&#39;t &quot;true&quot; about Python 2.x&#39;s unicode suppor=
t? The only feature<br>
I ever missed was case folding. (Not that 3.x does much better at that... :=
)<br>
<br>
The stdlib had poor unicode support, if that&#39;s what you mean. That<br>
could&#39;ve been fixed without introducing backwards-incompatible<br>
changes, though.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
-- Devin<br>
--<br>
<a href=3D"https://mail.python.org/mailman/listinfo/python-list" target=3D"=
_blank">https://mail.python.org/mailman/listinfo/python-list</a><br>
</font></span></blockquote></div><br><br clear=3D"all"><div><br></div>-- <b=
r><div dir=3D"ltr"><div style=3D"font-family:georgia,serif">Abhiram.R</div>=
<div style=3D"font-family:georgia,serif">M.Tech CSE (Sem 3)</div><div style=
=3D"font-family:georgia,serif">

RVCE</div><div style=3D"font-family:georgia,serif">Bangalore=C2=A0</div></d=
iv>
</div>

--001a11346d5c68664404fe42318f--
0
Abhiram
7/15/2014 9:35:17 PM
--001a11c2ae0eeddc5804fe42385c
Content-Type: text/plain; charset=UTF-8

Annd I just saw that the lifetime has been pushed up to 2020 :)
#SelfCorrected


On Wed, Jul 16, 2014 at 3:05 AM, Abhiram R <abhi.darkness@gmail.com> wrote:

> Umm..Guido Van Rossum said in Pycon 2014 that Py 2.x would be supported
> only until 2015 :-| So...you know.. you have like an year before you *do *have
> to migrate to 3.x .
>
>
> On Wed, Jul 16, 2014 at 2:17 AM, Devin Jeanpierre <jeanpierreda@gmail.com>
> wrote:
>
>> On Tue, Jul 15, 2014 at 1:24 PM, Mark Lawrence <breamoreboy@yahoo.co.uk>
>> wrote:
>> > On 15/07/2014 18:38, Marko Rauhamaa wrote:
>> >>
>> >> Chris Angelico <rosuav@gmail.com>:
>> >>
>> >>> Fine. Tell me how you would go about adding true Unicode support to
>> >>> Python 2.7, while still having it able to import an unchanged program.
>> >>> Trick question - it's fundamentally impossible, because an unchanged
>> >>> program will not distinguish between bytes and text, but true Unicode
>> >>> support requires that they be distinguished.
>> >>
>> >>
>> >> Python 2 has always had unicode strings and [byte] strings. They were
>> >> always clearly distinguished. You really didn't have to change anything
>> >> for "true Unicode support".
>> >>
>> >
>> > That is the funniest tongue in cheek comment I've read in the 10+ years
>> > I''ve been hanging around here.  It was tongue in cheek, wasn't it?
>>
>> What isn't "true" about Python 2.x's unicode support? The only feature
>> I ever missed was case folding. (Not that 3.x does much better at that...
>> :)
>>
>> The stdlib had poor unicode support, if that's what you mean. That
>> could've been fixed without introducing backwards-incompatible
>> changes, though.
>>
>> -- Devin
>> --
>> https://mail.python.org/mailman/listinfo/python-list
>>
>
>
>
> --
> Abhiram.R
> M.Tech CSE (Sem 3)
> RVCE
> Bangalore
>



-- 
Abhiram.R
M.Tech CSE (Sem 3)
RVCE
Bangalore

--001a11c2ae0eeddc5804fe42385c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:georgia,=
serif">Annd I just saw that the lifetime has been pushed up to 2020 :) #Sel=
fCorrected</div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmai=
l_quote">

On Wed, Jul 16, 2014 at 3:05 AM, Abhiram R <span dir=3D"ltr">&lt;<a href=3D=
"mailto:abhi.darkness@gmail.com" target=3D"_blank">abhi.darkness@gmail.com<=
/a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:georgia,=
serif">Umm..Guido Van Rossum said in Pycon 2014 that Py 2.x would be suppor=
ted only until 2015 :-| So...you know.. you have like an year before you <i=
>do </i>have to migrate to 3.x .=C2=A0</div>


</div><div class=3D"gmail_extra"><div><div class=3D"h5"><br><br><div class=
=3D"gmail_quote">On Wed, Jul 16, 2014 at 2:17 AM, Devin Jeanpierre <span di=
r=3D"ltr">&lt;<a href=3D"mailto:jeanpierreda@gmail.com" target=3D"_blank">j=
eanpierreda@gmail.com</a>&gt;</span> wrote:<br>


<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div>On Tue, Jul 15, 2014 at 1:24 PM, Mark L=
awrence &lt;<a href=3D"mailto:breamoreboy@yahoo.co.uk" target=3D"_blank">br=
eamoreboy@yahoo.co.uk</a>&gt; wrote:<br>



&gt; On 15/07/2014 18:38, Marko Rauhamaa wrote:<br>
&gt;&gt;<br>
&gt;&gt; Chris Angelico &lt;<a href=3D"mailto:rosuav@gmail.com" target=3D"_=
blank">rosuav@gmail.com</a>&gt;:<br>
&gt;&gt;<br>
&gt;&gt;&gt; Fine. Tell me how you would go about adding true Unicode suppo=
rt to<br>
&gt;&gt;&gt; Python 2.7, while still having it able to import an unchanged =
program.<br>
&gt;&gt;&gt; Trick question - it&#39;s fundamentally impossible, because an=
 unchanged<br>
&gt;&gt;&gt; program will not distinguish between bytes and text, but true =
Unicode<br>
&gt;&gt;&gt; support requires that they be distinguished.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; Python 2 has always had unicode strings and [byte] strings. They w=
ere<br>
&gt;&gt; always clearly distinguished. You really didn&#39;t have to change=
 anything<br>
&gt;&gt; for &quot;true Unicode support&quot;.<br>
&gt;&gt;<br>
&gt;<br>
&gt; That is the funniest tongue in cheek comment I&#39;ve read in the 10+ =
years<br>
&gt; I&#39;&#39;ve been hanging around here. =C2=A0It was tongue in cheek, =
wasn&#39;t it?<br>
<br>
</div>What isn&#39;t &quot;true&quot; about Python 2.x&#39;s unicode suppor=
t? The only feature<br>
I ever missed was case folding. (Not that 3.x does much better at that... :=
)<br>
<br>
The stdlib had poor unicode support, if that&#39;s what you mean. That<br>
could&#39;ve been fixed without introducing backwards-incompatible<br>
changes, though.<br>
<span><font color=3D"#888888"><br>
-- Devin<br>
--<br>
<a href=3D"https://mail.python.org/mailman/listinfo/python-list" target=3D"=
_blank">https://mail.python.org/mailman/listinfo/python-list</a><br>
</font></span></blockquote></div><br><br clear=3D"all"><div><br></div></div=
></div><span class=3D"HOEnZb"><font color=3D"#888888">-- <br><div dir=3D"lt=
r"><div style=3D"font-family:georgia,serif">Abhiram.R</div><div style=3D"fo=
nt-family:georgia,serif">

M.Tech CSE (Sem 3)</div><div style=3D"font-family:georgia,serif">
RVCE</div><div style=3D"font-family:georgia,serif">Bangalore=C2=A0</div></d=
iv>
</font></span></div>
</blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div dir=3D"=
ltr"><div style=3D"font-family:georgia,serif">Abhiram.R</div><div style=3D"=
font-family:georgia,serif">M.Tech CSE (Sem 3)</div><div style=3D"font-famil=
y:georgia,serif">

RVCE</div><div style=3D"font-family:georgia,serif">Bangalore=C2=A0</div></d=
iv>
</div>

--001a11c2ae0eeddc5804fe42385c--
0
Abhiram
7/15/2014 9:37:23 PM
On 15/07/2014 22:35, Abhiram R wrote:
> Umm..Guido Van Rossum said in Pycon 2014 that Py 2.x would be supported
> only until 2015 :-| So...you know.. you have like an year before you /do
> /have to migrate to 3.x .
> --
> Abhiram.R
> M.Tech CSE (Sem 3)
> RVCE
> Bangalore
>
>

a) please don't top post, this is almost as heinous a crime as using the 
infamous google groups
b) complete nonsense, it's actually 2020

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

Mark Lawrence

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


0
Mark
7/15/2014 9:49:47 PM
--089e01160c0ebd744804fe42b96c
Content-Type: text/plain; charset=UTF-8

a) What is "top post"?
b)I did correct myself in the next post. Or maybe you missed that.


On Wed, Jul 16, 2014 at 3:19 AM, Mark Lawrence <breamoreboy@yahoo.co.uk>
wrote:

> On 15/07/2014 22:35, Abhiram R wrote:
>
>> Umm..Guido Van Rossum said in Pycon 2014 that Py 2.x would be supported
>> only until 2015 :-| So...you know.. you have like an year before you /do
>> /have to migrate to 3.x .
>>
>> --
>> Abhiram.R
>> M.Tech CSE (Sem 3)
>> RVCE
>> Bangalore
>>
>>
>>
> a) please don't top post, this is almost as heinous a crime as using the
> infamous google groups
> b) complete nonsense, it's actually 2020
>
>
> --
> My fellow Pythonistas, ask not what our language can do for you, ask what
> you can do for our language.
>
> Mark Lawrence
>
> ---
> This email is free from viruses and malware because avast! Antivirus
> protection is active.
> http://www.avast.com
>
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>



-- 
Abhiram.R

--089e01160c0ebd744804fe42b96c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:georgia,=
serif">a) What is &quot;top post&quot;?=C2=A0</div><div class=3D"gmail_defa=
ult" style=3D"font-family:georgia,serif">b)I did correct myself in the next=
 post. Or maybe you missed that.</div>

<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Wed, Jul 1=
6, 2014 at 3:19 AM, Mark Lawrence <span dir=3D"ltr">&lt;<a href=3D"mailto:b=
reamoreboy@yahoo.co.uk" target=3D"_blank">breamoreboy@yahoo.co.uk</a>&gt;</=
span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"">On 15/07/2014 22:35, Abhiram=
 R wrote:<br>
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div class=3D"">
Umm..Guido Van Rossum said in Pycon 2014 that Py 2.x would be supported<br>=
</div>
only until 2015 :-| So...you know.. you have like an year before you /do<br=
>
/have to migrate to 3.x .<div class=3D""><br>
--<br>
Abhiram.R<br>
M.Tech CSE (Sem 3)<br>
RVCE<br>
Bangalore<br>
<br>
<br>
</div></blockquote>
<br>
a) please don&#39;t top post, this is almost as heinous a crime as using th=
e infamous google groups<br>
b) complete nonsense, it&#39;s actually 2020<div class=3D"HOEnZb"><div clas=
s=3D"h5"><br>
<br>
-- <br>
My fellow Pythonistas, ask not what our language can do for you, ask what y=
ou can do for our language.<br>
<br>
Mark Lawrence<br>
<br>
---<br>
This email is free from viruses and malware because avast! Antivirus protec=
tion is active.<br>
<a href=3D"http://www.avast.com" target=3D"_blank">http://www.avast.com</a>=
<br>
<br>
<br>
-- <br>
<a href=3D"https://mail.python.org/mailman/listinfo/python-list" target=3D"=
_blank">https://mail.python.org/<u></u>mailman/listinfo/python-list</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>=
<div dir=3D"ltr"><div style=3D"font-family:georgia,serif">Abhiram.R</div><d=
iv style=3D"font-family:georgia,serif"><br></div></div>
</div></div>

--089e01160c0ebd744804fe42b96c--
0
Abhiram
7/15/2014 10:13:24 PM
"Top posting" is the practice of responding to an e-mail thread by 
putting your response at the top of the text you are quoting. It's 
standard practice in the corporate world...

On 7/15/14, 6:13 PM, Abhiram R wrote:
> a) What is "top post"?Â

....but  Unix/newsgroup ettiquette says that it's gauche to do this, 
because it presents an unacceptable cognitive burden to the user trying 
to catch the context of the thread by forcing them to read your reply 
first, before they read the preceding quoted comments.

--Kevin
-- 
Kevin Walzer
Code by Kevin/Mobile Code by Kevin
http://www.codebykevin.com
http://www.wtmobilesoftware.com
0
Kevin
7/15/2014 10:30:15 PM
On 15/07/2014 23:13, Abhiram R wrote:
> a) What is "top post"?
> b)I did correct myself in the next post. Or maybe you missed that.
>
> On Wed, Jul 16, 2014 at 3:19 AM, Mark Lawrence <breamoreboy@yahoo.co.uk
> <mailto:breamoreboy@yahoo.co.uk>> wrote:
>
>     On 15/07/2014 22:35, Abhiram R wrote:
>
>         Umm..Guido Van Rossum said in Pycon 2014 that Py 2.x would be
>         supported
>         only until 2015 :-| So...you know.. you have like an year before
>         you /do
>         /have to migrate to 3.x .
>
>         --
>         Abhiram.R
>         M.Tech CSE (Sem 3)
>         RVCE
>         Bangalore
>
>     a) please don't top post, this is almost as heinous a crime as using
>     the infamous google groups
>     b) complete nonsense, it's actually 2020
>
>     --
>     My fellow Pythonistas, ask not what our language can do for you, ask
>     what you can do for our language.
>
>     Mark Lawrence
>
>     ---

Top posting is the extremely annoying habit of replying to a message at 
the top instead of at the bottom as I'm doing here, or interspersing 
your answers in with the related paragraphs.  I did see your correction 
but it gave me an opportunity to mention google groups, something that 
just can't be missed :)

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

Mark Lawrence

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


0
Mark
7/15/2014 10:38:40 PM
--001a11c368cca3d9fc04fe431aaf
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Jul 16, 2014 at 4:00 AM, Kevin Walzer <kw@codebykevin.com> wrote:

> "Top posting" is the practice of responding to an e-mail thread by puttin=
g
> your response at the top of the text you are quoting. It's standard
> practice in the corporate world...
>
> On 7/15/14, 6:13 PM, Abhiram R wrote:
>
>> a) What is "top post"?=C3=82
>>
>
> ...but  Unix/newsgroup ettiquette says that it's gauche to do this,
> because it presents an unacceptable cognitive burden to the user trying t=
o
> catch the context of the thread by forcing them to read your reply first,
> before they read the preceding quoted comments.
>
>
> --Kevin
> --
> Kevin Walzer
> Code by Kevin/Mobile Code by Kevin
> http://www.codebykevin.com
> http://www.wtmobilesoftware.com
> --
> https://mail.python.org/mailman/listinfo/python-list
>


=E2=80=8BAah. Understood. Apologies for the "noobishness" :) =E2=80=8B

=E2=80=8B-=E2=80=8B
Abhiram.R

--001a11c368cca3d9fc04fe431aaf
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:georgia,=
serif"><span style=3D"font-family:arial">On Wed, Jul 16, 2014 at 4:00 AM, K=
evin Walzer </span><span dir=3D"ltr" style=3D"font-family:arial">&lt;<a hre=
f=3D"mailto:kw@codebykevin.com" target=3D"_blank">kw@codebykevin.com</a>&gt=
;</span><span style=3D"font-family:arial"> wrote:</span><br>

</div><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex">&quot;Top posting&quot; is the practice of responding to an=
 e-mail thread by putting your response at the top of the text you are quot=
ing. It&#39;s standard practice in the corporate world...<br>


<br>
On 7/15/14, 6:13 PM, Abhiram R wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
a) What is &quot;top post&quot;?=C3=82<br>
</blockquote>
<br>
....but =C2=A0Unix/newsgroup ettiquette says that it&#39;s gauche to do this=
, because it presents an unacceptable cognitive burden to the user trying t=
o catch the context of the thread by forcing them to read your reply first,=
 before they read the preceding quoted comments.<div class=3D"HOEnZb">

<div class=3D"h5"><br>
<br>
--Kevin<br>
-- <br>
Kevin Walzer<br>
Code by Kevin/Mobile Code by Kevin<br>
<a href=3D"http://www.codebykevin.com" target=3D"_blank">http://www.codebyk=
evin.com</a><br>
<a href=3D"http://www.wtmobilesoftware.com" target=3D"_blank">http://www.wt=
mobilesoftware.<u></u>com</a><br>
-- <br>
<a href=3D"https://mail.python.org/mailman/listinfo/python-list" target=3D"=
_blank">https://mail.python.org/<u></u>mailman/listinfo/python-list</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><div><div class=3D"gma=
il_default" style=3D"font-family:georgia,serif">=E2=80=8BAah. Understood. A=
pologies for the &quot;noobishness&quot; :) =E2=80=8B</div><br></div><div d=
ir=3D"ltr"><div style=3D"font-family:georgia,serif">

<div class=3D"gmail_default" style=3D"font-family:georgia,serif;display:inl=
ine">=E2=80=8B-=E2=80=8B</div>Abhiram.R</div><div style=3D"font-family:geor=
gia,serif"><br></div></div>
</div></div>

--001a11c368cca3d9fc04fe431aaf--
0
Abhiram
7/15/2014 10:40:29 PM
On 15 July 2014 23:40, Abhiram R <abhi.darkness@gmail.com> wrote:
> On Wed, Jul 16, 2014 at 4:00 AM, Kevin Walzer <kw@codebykevin.com> wrote:
>>
>> ...but  Unix/newsgroup ettiquette says that it's gauche to [top post],
>> because it presents an unacceptable cognitive burden to the user trying to
>> catch the context of the thread by forcing them to read your reply first,
>> before they read the preceding quoted comments.
>
> Aah. Understood. Apologies for the "noobishness" :)

Also heinous is the crime of not trimming. A post should contain all
of the context needed to understand the reply, in order, and nothing
more.
0
Joshua
7/15/2014 11:45:14 PM
On Tuesday, July 15, 2014 5:40:29 PM UTC-5, Abhiram R wrote:
> [snip excessive quotations]
> Aah. Understood. Apologies for the "noobishness" :) 

Noobishness can be tolerated for a "reasonable" time,
especially when the "noob" actively seeks to improve his
skills, as you are doing, so kudos to you.

The next skill to learn, after NOT top posting, is the art
of trimming quotations to the most relevant bits. You'll
have to use your own judgment for most quoted text, however,
if nothing else, be sure to remove any links to the quoted
persons web site or blog, and any "famous quotes". 

Some folks even have software that "blabs" about how great a
job it is doing protecting the posters computer (like we
really care!), so if you see any taglines that mention "this
is a virus free message" (oh thanks, now i can sleep at
night!), or some pretentious line about "this was sent from
my i-phone" -- send that crap to the bitbucket!


0
Rick
7/15/2014 11:53:39 PM
On 7/15/14, 6:38 PM, Mark Lawrence wrote:
>    I did see your correction but it gave me an opportunity to mention
> google groups, something that just can't be missed

If the newgroup had a filter to trim out complaints about Google groups, 
half the traffic would be gone. :-)

-- 
Kevin Walzer
Code by Kevin/Mobile Code by Kevin
http://www.codebykevin.com
http://www.wtmobilesoftware.com
0
Kevin
7/16/2014 12:43:03 AM
Steven D'Aprano <steve+comp.lang.python@pearwood.info>:

> On Tue, 15 Jul 2014 23:01:25 +0300, Marko Rauhamaa wrote:
>> In fact, I find the lazy use of Unicode strings at least as scary as
>> the lazy use of byte strings, especially since Python 3 sneaks
>> Unicode to the outer interfaces of the program (files, IPC).
>
> I'm not entirely sure I understand what you mean by "lazy use of
> Unicode strings". And I especially don't understand what you mean by
> "sneak". The fact that strings are Unicode is *the* biggest and most
> obvious new feature of Python 3.

I mean that sys.stdin and sys.stdout should deal with byte strings. I
mean that open(path) should open a file in binary mode. Thankfully, the
subprocess methods exchange bytes by default.

To me, the main difference between Python 2 and Python 3 is that in the
former, I use "..." everywhere, and in the latter, I use b"..."
everywhere. If I should need advanced text processing features, I'll go
through a decode() and encode().

> The Python devs aren't slaves, they get to choose what features they
> work on and which they don't. They don't owe *anybody* any feature
> they don't want to build, or care to support, and that includes
> continuing the 2.x series.

No need to erect straw men. Of course, the Python gods do whatever they
want. And you asked me to clarify my opinion, which I did. The breakage
of backward compatibility wasn't worth the new features.

But as I said, what is done is done. We'll live with the reality.

> As of right now, *new* projects ought to be written in Python 3.3 or
> better, unless you have a compelling reason not to. You don't have to
> port old projects in order to take advantage of Python 3 for new
> projects.

But my distro only provides Python 3.2. What's wrong with Python 3.2?
Why didn't anybody tell me to put off the migration?


Marko
0
Marko
7/16/2014 1:01:01 AM
Chris Angelico <rosuav@gmail.com>:

> Python defaults to the most common case, where they're connected to a
> console, and does its best to allow print() to write Unicode to any
> console.

I don't know where you pull your statistics.

Be that as it may, the main purpose of sys.stdin is to receive the
workload and sys.stdout to deliver the goods.


Marko
0
Marko
7/16/2014 1:01:01 AM
On 2014-07-16 00:53, Rick Johnson wrote:
> On Tuesday, July 15, 2014 5:40:29 PM UTC-5, Abhiram R wrote:
>> [snip excessive quotations]
>> Aah. Understood. Apologies for the "noobishness" :)
>
> Noobishness can be tolerated for a "reasonable" time, especially when
> the "noob" actively seeks to improve his skills, as you are doing, so
> kudos to you.
>
> The next skill to learn, after NOT top posting, is the art of
> trimming quotations to the most relevant bits. You'll have to use
> your own judgment for most quoted text, however, if nothing else, be
> sure to remove any links to the quoted persons web site or blog, and
> any "famous quotes".
>
> Some folks even have software that "blabs" about how great a job it
> is doing protecting the posters computer (like we really care!), so
> if you see any taglines that mention "this is a virus free message"
> (oh thanks, now i can sleep at night!), or some pretentious line
> about "this was sent from my i-phone" -- send that crap to the
> bitbucket!
>
"This was sent from my iPhone" == "I have an iPhone!"

Also annoying is some footnote that says that the email contains
confidential information and that if you're not the intended recipient
you should delete it, etc.

That's somewhat pointless if it's being sent to a public forum!
0
MRAB
7/16/2014 1:57:24 AM
On Wed, 16 Jul 2014 03:07:23 +0530, Abhiram R wrote about Python 2.7:

> Annd I just saw that the lifetime has been pushed up to 2020 :)
> #SelfCorrected

Even when free support runs out, commercial support will be available. 
Red Hat is already committed to supporting Python 2.7 until 2023, and if 
there really is demand, nothing stops people or companies supporting it 
for the next 30 years.


-- 
Steven
0
Steven
7/16/2014 2:08:20 AM
--089e01227abc9be74e04fe47413f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Jul 16, 2014 at 5:23 AM, Rick Johnson <rantingrickjohnson@gmail.com=
>
wrote:

> On Tuesday, July 15, 2014 5:40:29 PM UTC-5, Abhiram R wrote:
> > [snip excessive quotations]
> > Aah. Understood. Apologies for the "noobishness" :)
>
> Noobishness can be tolerated for a "reasonable" time,
> especially when the "noob" actively seeks to improve his
> skills, as you are doing, so kudos to you.


=E2=80=8BThank you Rick :)=E2=80=8B



> The next skill to learn, after NOT top posting, is the art
> of trimming quotations to the most relevant bits. You'll
> have to use your own judgment for most quoted text, however,
> if nothing else, be sure to remove any links to the quoted
> persons web site or blog, and any "famous quotes".
>
>
> Added to =E2=80=8Bmy TIL-list :D=E2=80=8B

=E2=80=8B=E2=80=8B

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



--=20
Abhiram.R

--089e01227abc9be74e04fe47413f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:georgia,=
serif"><br></div><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Jul 16, 2014 at 5:23 AM, Rick Johnson <span dir=3D"ltr">&lt;<a href=3D"=
mailto:rantingrickjohnson@gmail.com" target=3D"_blank">rantingrickjohnson@g=
mail.com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">On Tuesday, July 15, 2014 5:40:29 PM UTC-5, =
Abhiram R wrote:<br>
&gt; [snip excessive quotations]<br>
<div class=3D"">&gt; Aah. Understood. Apologies for the &quot;noobishness&q=
uot; :)<br>
<br>
</div>Noobishness can be tolerated for a &quot;reasonable&quot; time,<br>
especially when the &quot;noob&quot; actively seeks to improve his<br>
skills, as you are doing, so kudos to you.</blockquote><div><br></div><div>=
<div class=3D"gmail_default" style=3D"font-family:georgia,serif">=E2=80=8BT=
hank you Rick :)=E2=80=8B</div><br></div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">

The next skill to learn, after NOT top posting, is the art<br>
of trimming quotations to the most relevant bits. You&#39;ll<br>
have to use your own judgment for most quoted text, however,<br>
if nothing else, be sure to remove any links to the quoted<br>
persons web site or blog, and any &quot;famous quotes&quot;.<br>
<br><span class=3D"HOEnZb"><font color=3D"#888888"><br></font></span></bloc=
kquote><div><div class=3D"gmail_default" style=3D"font-family:georgia,serif=
">Added to =E2=80=8Bmy TIL-list :D=E2=80=8B</div><br></div><div class=3D"gm=
ail_default" style=3D"font-family:georgia,serif">

=E2=80=8B=E2=80=8B</div><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"HOEnZ=
b"><font color=3D"#888888">
<br>
--<br>
<a href=3D"https://mail.python.org/mailman/listinfo/python-list" target=3D"=
_blank">https://mail.python.org/mailman/listinfo/python-list</a><br>
</font></span></blockquote></div><br><br clear=3D"all"><div><br></div>-- <b=
r><div dir=3D"ltr"><div style=3D"font-family:georgia,serif">Abhiram.R</div>=
<div style=3D"font-family:georgia,serif"><br></div></div>
</div></div>

--089e01227abc9be74e04fe47413f--
0
Abhiram
7/16/2014 3:37:43 AM
On Tue, 15 Jul 2014 23:01:25 +0300, Marko Rauhamaa wrote:

> Steven D'Aprano <steve+comp.lang.python@pearwood.info>:
> 
>> Unicode strings in Python 2 are second class entities.
> 
> I don't see that. They form a type just like, say, complex.

I didn't say they were a second class type. I choose my words carefully, 
although I guess what I was trying to get across may have been a bit 
subtle, sorry about that. But if you read on, where I explain some of the 
consequences, it should be clear: Python 2.x has the assumption that 
strings are 8-bit deeply embedded in the compiler.


>> It's not just that people will, in general, take the lazy way and write
>> "foo" instead of u"foo" for their strings.
> 
> People live with their choices, and I don't see the consequences of that
> lazy way as very bad.

The consequences are that it is too hard to write correct text handling 
code in Python 2, and too many programs which assume that text=ASCII as 
if it were 1965.

In the same way that a language like Python is supposed to make it hard 
for programmers (good, lazy or careless programmers) to write code with 
(say) buffer overflow bugs, so a language like Python is supposed to make 
it hard for programmers to write code that assumes that text is 8-bit. It 
is disgraceful that in 2014 there are still languages like PHP that don't 
know how to handle text, and Python fortunately is not one of them.


> In fact, I find the lazy use of Unicode strings at least as scary as the
> lazy use of byte strings, especially since Python 3 sneaks Unicode to
> the outer interfaces of the program (files, IPC).

I'm not entirely sure I understand what you mean by "lazy use of Unicode 
strings". And I especially don't understand what you mean by "sneak". The 
fact that strings are Unicode is *the* biggest and most obvious new 
feature of Python 3.


>> But it is that the whole Python virtual machine is based on
>> byte-strings, not Unicode strings, and u"" strings are bolted on top.
> 
> The internal implementation of the VM is free to change as long as the
> external semantics stay the same.

Which is the whole point. *They cannot*, or at least not without a level 
of effort far beyond what is reasonable for an all-volunteer effort. And 
even if they could, why bother when most developers will then ignore that 
and use "" byte strings because it saves one character typing?

The Python devs aren't slaves, they get to choose what features they work 
on and which they don't. They don't owe *anybody* any feature they don't 
want to build, or care to support, and that includes continuing the 2.x 
series. That leaves you with choices:

- You can follow the lead of the core developers and migrate to 3.x in 
your own time, when it works for you.

- You can get enough people on the PSF board, and enough trusted, core 
developers, that the old guard get pushed out and you can take over and 
set the direction of Python development.

- You can hunker down and stick with Python 2 forever, and do without 
free support after 2020.

- You can stick with Python 2 until 2020, or pay for support until 2023, 
then reconsider the decision not to migrate.

- You can fork Python and take over support of MyPython 2.7.

- Or you can port your code to another language.

Perhaps the *stupidest* thing the author of the "Python 3 is killing 
Python" blog post wrote was that it's easier to port Python code to a 
*completely different language*. I cannot fathom the idiocy of somebody 
who bitches and moans that having to re-write or redesign, oh, let's 
conservatively say 5% of your Python 2 code is harder than writing your 
code *completely from scratch* in a completely different language, with 
completely different third party libraries.


And you can make that choice on a project-by-project basis.

As of right now, *new* projects ought to be written in Python 3.3 or 
better, unless you have a compelling reason not to. You don't have to 
port old projects in order to take advantage of Python 3 for new projects.



>> [steve@ando ~]$ python3.3 -c "π = 3.14; print(π+1)" 4.140000000000001
>> [steve@ando ~]$ python2.7 -c "π = 3.14; print(π+1)"
>>   File "<string>", line 1
>>     π = 3.14; print(π+1)
>>     ^
>> SyntaxError: invalid syntax
> 
> My native language uses ä and ö, but I don't see any pressing need to
> embed those characters in identifiers.

And good for you that you don't. I mean it. But there are 7 billion 
people in the world, and they're not all Python programmers, but most 
people are keen to program in their native tongues rather than English.


>> Python 2 "helpfully" tries to guess what you want when you work with
>> bytes-pretending-to-be-strings, and when it guesses right, it's nice,
>> but when it guesses wrongly, you'll left with mysterious encoding and
>> decoding errors from code that don't appear to involve either. The
>> whole thing is a mess.
> 
> I can't think of a matching example.


[steve@ando ~]$ python2.7 -c "print u'π' + 'p'"
Ïp

Where did the Ï come from?

[steve@ando ~]$ python3.3 -c "print('π' + 'p')"
πp



-- 
Steven
0
Steven
7/16/2014 3:51:56 AM
On Wed, Jul 16, 2014 at 1:51 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> Perhaps the *stupidest* thing the author of the "Python 3 is killing
> Python" blog post wrote was that it's easier to port Python code to a
> *completely different language*. I cannot fathom the idiocy of somebody
> who bitches and moans that having to re-write or redesign, oh, let's
> conservatively say 5% of your Python 2 code is harder than writing your
> code *completely from scratch* in a completely different language, with
> completely different third party libraries.

There's only one way that it's easier to port to a completely new
language. Pick another language where string handling is as naive as
my last boss (who told me to make sure that my code was "eight-bit
clean, that is to say, Unicode safe", and used the words "Unicode" and
"UTF-8" as synonymous), and then you can continue to stick your head
in the sand and pretend that ASCII is what matters, that "special
characters" work because of the magic of UTF-8, and that oh, yeah, I
guess we'd better occasionally test our code with a few of those
annoyingly different characters, but ehh, it doesn't really matter
much.

Having been guilty of something like that (actually, in one program I
assumed all the incoming text was CP-1252, so it really *was*
byte==char), I am extremely aware of the problems that it causes. But
it does make initial coding a lot easier - at the expense of debugging
later, when you discover that some things don't work. The Py3 approach
forces you to fix things up-front, and that's hard! But then there are
no bugs.

I know which one I'd rather.

ChrisA
0
Chris
7/16/2014 4:20:37 AM
On Wed, Jul 16, 2014 at 3:52 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
> Steven D'Aprano <steve+comp.lang.python@pearwood.info>:
>
>> On Tue, 15 Jul 2014 23:01:25 +0300, Marko Rauhamaa wrote:
>>> In fact, I find the lazy use of Unicode strings at least as scary as
>>> the lazy use of byte strings, especially since Python 3 sneaks
>>> Unicode to the outer interfaces of the program (files, IPC).
>>
>> I'm not entirely sure I understand what you mean by "lazy use of
>> Unicode strings". And I especially don't understand what you mean by
>> "sneak". The fact that strings are Unicode is *the* biggest and most
>> obvious new feature of Python 3.
>
> I mean that sys.stdin and sys.stdout should deal with byte strings. I
> mean that open(path) should open a file in binary mode. Thankfully, the
> subprocess methods exchange bytes by default.

Let's take a step back from the standard I/O streams and look at this
one concept: Asking the user to enter his/her name. The user will have
a name which consists of characters (at least, we hope so; cases where
this is not true do exist, but are outside the scope of this
discussion), not bytes. The program wants to use those characters, not
bytes. If I create a window with tkinter and ask the user to enter a
name, I'll get back a Unicode string:

http://www.python-course.eu/tkinter_entry_widgets.php

(By the way, this suffers from the common flaw of asking for separate
first and last names. That's not reliable in terms of people's names,
but it's no different in terms of bytes and strings.)

(Also by the way, why is a Python course advertising that its web site
is written in PHP?)

Whether I use Python 2 (changing the import to Tkinter) or Python 3
(running the code unchanged), I get back a Unicode string (easily
proven by looking at its repr() in show_entry_fields()), because the
user typed *text* into the widget. This is what everyone will expect.

Now, the standard I/O streams might be connected to a console, or
might be reading from a pipe. This does add a level of complexity, as
it's possible to read either text or bytes from them; but Python
defaults to the most common case, where they're connected to a
console, and does its best to allow print() to write Unicode to any
console. (With limited success on some consoles; Windows' cmd.exe has
problems. That's not Python's fault.) If you want binary, you can
easily switch to binary mode. Maybe it would be better to have a
simple function "change standard stream(s) to binary", but the default
is still correct: most of the time, you want to work with text.

> To me, the main difference between Python 2 and Python 3 is that in the
> former, I use "..." everywhere, and in the latter, I use b"..."
> everywhere. If I should need advanced text processing features, I'll go
> through a decode() and encode().

Why do you work with the underlying representation (bytes) instead of
the abstraction (strings)? To be consistent, you should probably
eschew Python dictionaries in favour of a manually-implemented
hashtable, and studiously avoid Python source code by hand-writing
CPython bytecode.

>> As of right now, *new* projects ought to be written in Python 3.3 or
>> better, unless you have a compelling reason not to. You don't have to
>> port old projects in order to take advantage of Python 3 for new
>> projects.
>
> But my distro only provides Python 3.2. What's wrong with Python 3.2?
> Why didn't anybody tell me to put off the migration?

It's pretty easy to spin up a CPython 3.4 for Debian Wheezy. Or you
might be able to just grab a package from Jessie, where CPython 3.4 is
standard. Debian, like Red Hat, values stability over currency, so
once Wheezy went into freeze on 2012-06-30 [1], the
current-at-the-time Python was locked in (Python 3.3 wasn't released
until 2012-09-29 [2]), in order to allow packages to depend on it and
be able to trust it.

(It's possible you're not on Debian Wheezy, but on some other distro
that also ships 3.2 with its current release. The policies are likely
to be similar.)

ChrisA

[1] https://wiki.debian.org/DebianWheezy
[2] https://www.python.org/download/releases/3.3.0/
0
Chris
7/16/2014 6:26:03 AM
On Wed, Jul 16, 2014 at 4:44 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
> Chris Angelico <rosuav@gmail.com>:
>
>> Python defaults to the most common case, where they're connected to a
>> console, and does its best to allow print() to write Unicode to any
>> console.
>
> I don't know where you pull your statistics.

Heaps and HEAPS of personal experience, of myself and many other
people. I frequently run programs that manipulate text and work with a
console that displays text, which means that a consistent encoding
(usually UTF-8) can be hidden away as an implementation detail. As
long as the console correctly announces the encoding it expects and
the program correctly writes in that encoding, all is well, and the
program can simply "write text to the console".

> Be that as it may, the main purpose of sys.stdin is to receive the
> workload and sys.stdout to deliver the goods.

Yes, but is that workload text or bytes? To be sure, there are
programs whose stdin is usually or always bytes, but most use text.
The default should be the most common and most useful option, and the
alternative should be available when you want it.

ChrisA
0
Chris
7/16/2014 6:50:26 AM
Le mercredi 16 juillet 2014 07:52:31 UTC+2, Marko Rauhamaa a =E9crit :
> Steven D'Aprano <steve+comp.lang.python@pearwood.info>:
>=20
>=20
>=20
> > On Tue, 15 Jul 2014 23:01:25 +0300, Marko Rauhamaa wrote:
>=20
> >> In fact, I find the lazy use of Unicode strings at least as scary as
>=20
> >> the lazy use of byte strings, especially since Python 3 sneaks
>=20
> >> Unicode to the outer interfaces of the program (files, IPC).
>=20
> >
>=20
> > I'm not entirely sure I understand what you mean by "lazy use of
>=20
> > Unicode strings". And I especially don't understand what you mean by
>=20
> > "sneak". The fact that strings are Unicode is *the* biggest and most
>=20
> > obvious new feature of Python 3.
>=20
>=20
>=20
> I mean that sys.stdin and sys.stdout should deal with byte strings. I
>=20
> mean that open(path) should open a file in binary mode. Thankfully, the
>=20
> subprocess methods exchange bytes by default.
>=20
>=20
>=20
> To me, the main difference between Python 2 and Python 3 is that in the
>=20
> former, I use "..." everywhere, and in the latter, I use b"..."
>=20
> everywhere. If I should need advanced text processing features, I'll go
>=20
> through a decode() and encode().
>=20
>=20
>=20
> > The Python devs aren't slaves, they get to choose what features they
>=20
> > work on and which they don't. They don't owe *anybody* any feature
>=20
> > they don't want to build, or care to support, and that includes
>=20
> > continuing the 2.x series.
>=20
>=20
>=20
> No need to erect straw men. Of course, the Python gods do whatever they
>=20
> want. And you asked me to clarify my opinion, which I did. The breakage
>=20
> of backward compatibility wasn't worth the new features.
>=20
>=20
>=20
> But as I said, what is done is done. We'll live with the reality.
>=20
>=20
>=20
> > As of right now, *new* projects ought to be written in Python 3.3 or
>=20
> > better, unless you have a compelling reason not to. You don't have to
>=20
> > port old projects in order to take advantage of Python 3 for new
>=20
> > projects.
>=20
>=20
>=20
> But my distro only provides Python 3.2. What's wrong with Python 3.2?
>=20
> Why didn't anybody tell me to put off the migration?
>=20
>=20
>=20
>=20
>=20
> Marko

-----------


From a unicode perspective, Py32 is the best
Python. (Yes it's ucs2).

(From a BDFL example)

>>> sys.version_info
sys.version_info(major=3D3, minor=3D2, micro=3D5, releaselevel=3D'final', s=
erial=3D0)
>>> timeit.repeat("a =3D 'hundred'; 'x' in a")
[0.09090468709446498, 0.07743860966057525, 0.07695655307486504]
>>> timeit.repeat("a =3D 'hundre EURO'; 'x' in a")
[0.09373873872100091, 0.07633783502242864, 0.0762649751626725]


sys.version_info
sys.version_info(major=3D3, minor=3D4, micro=3D0, releaselevel=3D'final', s=
erial=3D0)
timeit.repeat("a =3D 'hundred'; 'x' in a")
[0.1174619090622306, 0.09338822371994088, 0.09350361798433393]
timeit.repeat("a =3D 'hundre EURO'; 'x' in a")
[0.2306057883810979, 0.21599837108983877, 0.2168407886036121]


>>> sys.version_info
sys.version_info(major=3D3, minor=3D4, micro=3D0, releaselevel=3D'final', s=
erial=3D0)
>>> sys.getsizeof('hundred')
32
>>> sys.getsizeof('hundre EURO')
52


>>> sys.getsizeof('hundred')
44
>>> sys.getsizeof('hundre EURO')
44


Just an illustration of a systematical behaviour.
Not only Py32 works much better than Py33+,
it works much better for non ascii users!


The Py devs succeeded to transform Python into
a ascii product!

In my mind, it would be nicer to spend time in
solving bugs, instead of reinventing "unicode".
And before reinventing "unicode", it would be
good to undersand it (I fell by chance on
a video: "The Guts of Unicode in Python").


Hobbyist tools will alway stay hobbyist tools.

------

Something different, "micropython". Luckily
they are people who are understanding "unicode"
as whole very correctly and are not following
py devs advices. I'm thinking about this
UEFI stuff. It is beyond my knowledge. it seems to me
that it is a similar situation.

jmf

0
wxjmfauth
7/16/2014 7:11:57 AM
On Wed, 16 Jul 2014 14:20:37 +1000, Chris Angelico wrote:

> On Wed, Jul 16, 2014 at 1:51 PM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
>> Perhaps the *stupidest* thing the author of the "Python 3 is killing
>> Python" blog post wrote was that it's easier to port Python code to a
>> *completely different language*. I cannot fathom the idiocy of somebody
>> who bitches and moans that having to re-write or redesign, oh, let's
>> conservatively say 5% of your Python 2 code is harder than writing your
>> code *completely from scratch* in a completely different language, with
>> completely different third party libraries.
> 
> There's only one way that it's easier to port to a completely new
> language. Pick another language where string handling is as naive as my
> last boss

But even then, you still have to re-write all your code in the new 
language. Using different libraries. All your unit tests are obsolete 
(although your integration tests may not be). End-user documentation will 
probably be re-usable, but documentation aimed at your developers will 
need to be re-written.



-- 
Steven
0
Steven
7/16/2014 7:33:03 AM
On Wed, 16 Jul 2014 08:52:31 +0300, Marko Rauhamaa wrote:

> Steven D'Aprano <steve+comp.lang.python@pearwood.info>:
> 
>> On Tue, 15 Jul 2014 23:01:25 +0300, Marko Rauhamaa wrote:
>>> In fact, I find the lazy use of Unicode strings at least as scary as
>>> the lazy use of byte strings, especially since Python 3 sneaks Unicode
>>> to the outer interfaces of the program (files, IPC).
>>
>> I'm not entirely sure I understand what you mean by "lazy use of
>> Unicode strings". And I especially don't understand what you mean by
>> "sneak". The fact that strings are Unicode is *the* biggest and most
>> obvious new feature of Python 3.
> 
> I mean that sys.stdin and sys.stdout should deal with byte strings. 

There are certainly use-cases for stdin and stdout to use bytes, but 
there are also use-cases for them to deal with strings. I'll certainly 
grant you that there ought to be an easy way to get access to the binary 
streams, but I think for a high-level language like Python, the default 
should be text, not bytes.

> I mean that open(path) should open a file in binary mode. Thankfully,
> the subprocess methods exchange bytes by default.

Likewise for files: by default, I should be able to do this:

open("foo.txt", "w").write("foo bar baz")

and have something sensible happen. Although I'm open to the suggestion 
that maybe the Pythonic way to do that should be:

print("foo bar baz", file="foo.txt")


Most programming languages I know of default to opening files in text 
mode, not binary mode, and I don't see any strong reason for Python to go 
against the tide there.

And I don't have an opinion on the subprocess module.


> To me, the main difference between Python 2 and Python 3 is that in the
> former, I use "..." everywhere, and in the latter, I use b"..."
> everywhere. If I should need advanced text processing features, I'll go
> through a decode() and encode().

Having len('λ') == 1 is not an advanced text processing feature.


[...]
>> As of right now, *new* projects ought to be written in Python 3.3 or
>> better, unless you have a compelling reason not to. You don't have to
>> port old projects in order to take advantage of Python 3 for new
>> projects.
> 
> But my distro only provides Python 3.2. What's wrong with Python 3.2?
> Why didn't anybody tell me to put off the migration?

Nothing is "wrong" with Python 3.2, except in the sense that it's now 
about 3 years old there are better versions (3.3 and 3.4) to choose from. 
If you're wedded to the idea of only using the version of Python that 
your distro supports, you may find yourself a version or four behind the 
latest release. (Red Hat only recently stopped supporting a distro where 
the system python was 2.3. Yay.)


-- 
Steven
0
Steven
7/16/2014 7:49:19 AM
On 16/07/2014 00:53, Rick Johnson wrote:

Another thing that irritates is those people who insist on shouting LIKE 
THIS throughout their posts.

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

Mark Lawrence

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


0
Mark
7/16/2014 8:18:19 AM
On Wed, Jul 16, 2014 at 5:49 PM, Steven D'Aprano <steve@pearwood.info> wrote:
> ... Although I'm open to the suggestion
> that maybe the Pythonic way to do that should be:
>
> print("foo bar baz", file="foo.txt")
>

And I would argue against that suggestion, having worked with a
language where that's the case. In REXX, you write to files using the
LINEOUT and CHAROUT functions (the former adds end-of-line after its
written content, the latter doesn't):

call lineout "foo.txt","foo bar baz"
/* or */
call charout "foo.txt","foo bar "
call lineout "foo.txt","baz"

And correspondingly, CHARIN and LINEIN to read from files. This is
nice and convenient, but it has a number of problems:

1) Hidden global state. Somewhere there's a mapping of file names to
open file handles, and it's not obvious.
2) Corollary: Surprising behaviour if you try to use a file twice in
one program.
3) Closing a file is sometimes unobvious. If you terminate the program
with open files, there's no problem, but if the program keeps running,
its files stay open.
4) Very VERY occasionally, you might run into a problem with too many
open files. (It should be noted that I learned REXX back in the 90s.
It's entirely possible that "too many open files" would be at some
insanely ridiculous number now.) At that point, you need to close
something... but how can you know?

Here's a REXX-style set of functions, implemented in Python:

# files.py
_filemap = {}
def _open(fn, mode): _filemap[fn] = open(fn, mode)

def charout(fn, s):
    if fn not in _filemap: _open(fn, "w")
    _filemap[fn].write(s)

def lineout(fn, s): charout(fn, s+"\n")

def charin(fn, n=1):
    if fn not in _filemap: _open(fn, "r")
    return _filemap[fn].read(n)

# Okay, the stream() function does a *lot* more than
# closing files, but that's all I'm implementing.
def stream(fn, *args):
    if args != ["c","close"]: raise NotImplemented
    del _filemap[fn]



That's more-or-less how REXX does things. There are a lot more
complications (I didn't implement LINEIN, which requires buffering -
more global state), but that's the basic layout. Now, that's already
scaring you a bit (all that global state!), but it gets worse: you
either have heaps of duplication all through your code (repeating the
file name in every output statement), or you have a variable with the
file name that functions as a cookie - it's the same as a file handle
integer, or a FILE *fp with the C stdio library, or a file object in
Python, or anything like that. Usage would be like this:

fn = "foo.txt"
print("foo bar baz", file=fn)
print("hello, world", file=fn)
close_file(fn)

Which has no significant improvement over the current:

f = open("foo.txt", "w")
print("foo bar baz", file=f)
print("hello, world", file=f)
f.close()

And it's worse, because if you put this into a function and return
early from it, the second form will garbage-collect f and close the
file, but the first form won't. That's a recipe for surprises down the
track.

There is a use-case where this is an improvement: you can have a
function that writes to a log file or something, and it doesn't need
to monitor state:

def some_func(...)
    do_stuff()
    if condition: print(some_state, file="some.log")
    do_more_stuff()

With Python's normal style, this would need to either keep on opening
and closing the file (slow and inefficient), or keep track of an open
file object somewhere (global state). If you're going to have global
state anyway, then it's easier to push it to someone else. But I'd
much rather NOT have that state... not to mention the potential
problems from having aliases to the file. I've never tried, for
instance, opening a file using two equivalent names, but it'd probably
open the file twice. Even more confusion.

It's great to be open to suggestions. It's great to be able to discuss
them and figure out which ones are actually worth pursuing :)

ChrisA
0
Chris
7/16/2014 8:44:38 AM
A little more off-topic:

On Wed, Jul 16, 2014 at 3:57 AM, MRAB <python@mrabarnett.plus.com> wrote:
> On 2014-07-16 00:53, Rick Johnson wrote:
>> Some folks even have software that "blabs" about how great a job it
>> is doing [=E2=80=A6], so if you see [=E2=80=A6] some pretentious line
>> about "this was sent from my i-phone" -- send that crap to the
>> bitbucket!
>>
> "This was sent from my iPhone" =3D=3D "I have an iPhone!"

I personally parse those lines as =E2=80=9Csent from my iPhone, which has a=
n
on-screen touch keyboard, and it=E2=80=99s harder to type on it=E2=80=9D.

> Also annoying is some footnote that says that the email contains
> confidential information and that if you're not the intended recipient
> you should delete it, etc.
>
> That's somewhat pointless if it's being sent to a public forum!

Corporate lawyers for the win!  99.9% of people who send e-mail with
this line are forced to do so by their corporation=E2=80=99s legal departme=
nt.

Also, the correct solution for all those is getting a sane client that
can hide quotes and signatures.  Like Gmail (which defaults to
top-posting, but fixing this is one click per message away*).  And if
someone brings the =E2=80=9Cpeople need to download it anyway=E2=80=9D argu=
ment: it=E2=80=99s
2014, people: hard-drives are large nowadays (or you can just use
IMAP) and if you=E2=80=99re paying $100 per kilobyte, you=E2=80=99re doing =
it wrong
and should not be online in the first place.

* trickier on mobile, though.

--=20
Chris =E2=80=9CKwpolska=E2=80=9D Warrick <http://chriswarrick.com/>
PGP: 5EAAEA16
stop html mail | always bottom-post | only UTF-8 makes sense
0
UTF
7/16/2014 10:20:44 AM
Steven D'Aprano <steve@pearwood.info>:

> Likewise for files: by default, I should be able to do this:
>
> open("foo.txt", "w").write("foo bar baz")
>
> and have something sensible happen.

I'd prefer:

   open("foo.txt", "wt").write("foo bar baz")

or:

   open("foo.txt", "w", encoding="utf-8").write("foo bar baz")

or:

   open("foo.txt", "w").write("foo bar baz".encode())

Python 3 really is on a mission to elevate text into the mainstream at
the expense of bytes. I'm guessing this is done primarily to promote the
cross-platform transparency of Python code.

For me, a linux system and network programmer, that layer of frosting
only gets in my way and I need to wash it off.

> Most programming languages I know of default to opening files in text
> mode, not binary mode, and I don't see any strong reason for Python to
> go against the tide there.

In unix and linux, there never was a separate text mode for files. When
you open a file, you open a file -- and stuff bytes in it. There is no
commonly accepted text file encoding. UTF-8 comes close to being a
standard, but I know somebody who sticks to an ISO-8859-1 locale.

> Having len('λ') == 1 is not an advanced text processing feature.

There are (relative rare) occasions where you'd like to treat text as
text. Then, it's nice to be able to move the data on the operating table
with .decode() and when the patient has been sewn back together, you can
release them with .encode().

More often, len(b'λ') is what I want.


Marko
0
Marko
7/16/2014 10:46:45 AM
On Wed, 16 Jul 2014 18:44:38 +1000, Chris Angelico wrote:

> On Wed, Jul 16, 2014 at 5:49 PM, Steven D'Aprano <steve@pearwood.info>
> wrote:
>> ... Although I'm open to the suggestion that maybe the Pythonic way to
>> do that should be:
>>
>> print("foo bar baz", file="foo.txt")
>>
>>
> And I would argue against that suggestion, having worked with a language
> where that's the case.
[...]

> 1) Hidden global state. Somewhere there's a mapping of file names to
> open file handles, and it's not obvious. 

Absolutely not! What do you take me for, the designer of REXX???

:-P

What I had in mind was for print to open the file in append mode, write, 
then close the file. Something like this:


def print(*values, sep=' ', end='\n', file=sys.stdout, flush=False):
    def write(f):
        for value in values:
            f.write(str(value) + sep)
        f.write(end)
        if flush:
            f.flush()
    if isinstance(file, (str, bytes)):
        with open(file, 'a') as f:
            write(f)
    else:
        write(f)
        


The downside of this is that it doesn't handle encodings and error 
handlers, or any of the other, more obscure, arguments to open(). But 
since print is intended as a convenience function, I'm okay with that. If 
you need more than the default settings, you should open the file 
yourself:

f = open('something.txt', 'w', encoding='UTF=32')
print("fe fi fo fum", file=f)


> 2) Corollary: Surprising
> behaviour if you try to use a file twice in one program.

Not with my idea. The only surprises are if you try to use it with the 
filename from different threads, but that's a relatively advanced thing 
to do. If you're using print from two threads at once, don't pass a file 
name.


> 3) Closing a file is sometimes unobvious. If you terminate the program
> with open files, there's no problem, but if the program keeps running,
> its files stay open.
> 4) Very VERY occasionally, you might run into a problem with too many
> open files. (It should be noted that I learned REXX back in the 90s.
> It's entirely possible that "too many open files" would be at some
> insanely ridiculous number now.) At that point, you need to close
> something... but how can you know?

Neither of these will be a problem.

Well, technically, if you opened like a million threads, and had every 
thread try to print to a different file name at the same time, that could 
be a problem. But if you're doing that, you deserve whatever happens.

;-)



-- 
Steven
0
Steven
7/16/2014 11:35:40 AM
On Wed, Jul 16, 2014 at 9:35 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> What I had in mind was for print to open the file in append mode, write,
> then close the file.

Ahh, okay. Very different from what I thought you were talking about,
and distinctly different in behaviour from REXX :)

In that case, it avoids the problems that I described, at the expense
of being potentially an attractive nuisance - imagine code like this:

for line in open("input.txt"):
    print(transform(line), file="output.txt")

Looks like a really nice clean way to process a file, right? But it's
going to be horrendously slow.

Actually, this could be quite reasonably added as a feature of
print(). Could be monkey-patched in fairly easily

_origprint = print
def print(*a, **kw):
    if isinstance(kw.get("file"), (str, bytes)):
        with open(kw["file"], 'a') as f:
            kw["file"] = f
            _origprint(*a, **kw)
    else:
        _origprint(*a, **kw)

And it'd have its uses. The only risk would be if there's a file-like
object that's a subclass of either str or bytes, which admittedly *is*
theoretically possible...

ChrisA
0
Chris
7/16/2014 11:54:21 AM
On Wed, 16 Jul 2014 13:46:45 +0300, Marko Rauhamaa wrote:

> Python 3 really is on a mission to elevate text into the mainstream at
> the expense of bytes. I'm guessing this is done primarily to promote the
> cross-platform transparency of Python code.

Ahead of bytes? Possibly. At the expense of bytes? Certainly not. If 
there is anything that you cannot conveniently do with bytes, that you 
could do in Python 2, it's likely a bug, or at least an obviously missing 
feature. The core devs recognise that they missed some use-cases (e.g. 
mixed bytes and text) which is now harder than it should be, and are on a 
mission to rectify that as much as possible within the constraints of 
backward compatibility.

E.g. having b"abc"[0] return 97 instead of b"a" was probably a mistake, 
but there are four versions of Python 3.x that do it that way and it's 
too late to change until Python 5000. (Python 4 is unlikely to break 
backwards compatibility in a big way.)


> For me, a linux system and network programmer, that layer of frosting
> only gets in my way and I need to wash it off.

Linux, like all Unixes, is primarily a text-based platform. With a few 
exceptions, /etc is filled with text files, not binary files, and half 
the executables on the system are text (Python, Perl, bash, sh, awk, 
etc.). 

www.catb.org/esr/writings/taoup/html/ch05s01.html

To say that *dealing with text* gets in your way on a Linux system is 
rather like saying that you love Mac OS X except for its gosh-awful GUI 
and APIs.

Of course, as a network programmer, you have to deal with bytes, so I'll 
give you a bit of leeway.


>> Most programming languages I know of default to opening files in text
>> mode, not binary mode, and I don't see any strong reason for Python to
>> go against the tide there.
> 
> In unix and linux, there never was a separate text mode for files. When
> you open a file, you open a file -- and stuff bytes in it. There is no
> commonly accepted text file encoding. UTF-8 comes close to being a
> standard, but I know somebody who sticks to an ISO-8859-1 locale.

And they should be dragged out into the street and beaten with a Clue 
Stick. They're the sort of people who are holding us back from the 
shining utopia of UTF-8 everywhere!

(only half joking)

But seriously, I cannot imagine any *rational* reason for using a legacy 
encoding, but I'm willing to give this person the benefit of the doubt 
that he's not a raving lunatic or old West European-centric curmudgeon 
trying to deny the existence of the rest of the world.

http://i.imgur.com/UeZan.jpg

That being the case, then good luck to him. As far as everyone else:

http://www.utf8everywhere.org/


>> Having len('λ') == 1 is not an advanced text processing feature.
> 
> There are (relative rare) occasions where you'd like to treat text as
> text.

o_O

Relatively rare. Like, um, email, news, html, Unix config files, Windows 
ini files, source code in just about every language ever, SMSes, XML, 
JSON, YAML, instant messenger apps, word processors... even *graphic* 
applications invariably have a text tool. Now, it may be true that some 
of those things may not use text under the hood, but even so, text is 
ubiquitous.

Even binary protocols often include chunks of recognisable human-readable 
text in them:

[steve@ando Pictures]$ hexdump -n 64 -C picture.jpg
00000000  ff d8 ff e0 00 10 4a 46  49 46 00 01 01 00 00 01  |......JFIF......|
00000010  00 01 00 00 ff e2 0f 38  49 43 43 5f 50 52 4f 46  |.......8ICC_PROF|
00000020  49 4c 45 00 01 01 00 00  0f 28 61 70 70 6c 02 10  |ILE......(appl..|
00000030  00 00 6d 6e 74 72 52 47  42 20 58 59 5a 20 07 de  |..mntrRGB XYZ ..|
00000040


> Then, it's nice to be able to move the data on the operating table
> with .decode() and when the patient has been sewn back together, you can
> release them with .encode().
> 
> More often, len(b'λ') is what I want.

Oh really? Are you sure? What exactly is b'λ'?

I couldn't have made up a better example of the confusion between bytes 
and text if I had tried. Thank you.



-- 
Steven
0
Steven
7/16/2014 12:10:16 PM
On Wed, Jul 16, 2014 at 10:10 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> Linux, like all Unixes, is primarily a text-based platform. With a few
> exceptions, /etc is filled with text files, not binary files, and half
> the executables on the system are text (Python, Perl, bash, sh, awk,
> etc.).

An interesting assertion. I know "half" is not meant to be an actual
estimate, but out of curiosity, I whipped up a quick script to figure
out just how many of my executables are text and how many aren't.

#!/usr/bin/env python3
import os, subprocess
text = binary = unknown = unreadable = 0
for path in os.environ["PATH"].split(":"):
    for file in os.listdir(path):
        fn = os.path.join(path, file)
        try:
            t = subprocess.check_output(["file", "-L", fn])
        except subprocess.CalledProcessError:
            print("Unreadable: %s" % fn)
            unreadable += 1
            continue
        if isinstance(t, bytes): t = t.decode("ascii")
        # Now to try to figure out what's text and what's binary.
        if "text" in t:
            # Most Unixes follow the convention of having "text" in
            # the output of all files that can be safely blatted to
            # a terminal - for instance, "ASCII text executable" is
            # used to describe most shell scripts etc; this file is
            # a "Python script, ASCII text executable". If I put in
            # a non-ASCII char, the 'file' descr becomes changes to
            # "Python script, UTF-8 Unicode text executable".
            text += 1
        elif "directory" in t:
            # Ignore directories.
            pass
        elif "LSB executable" in t or "LSB shared object" in t:
            binary += 1
        else:
            print(t.strip())
            unknown += 1
print("%d text, %d binary" % (text, binary))
if unknown: print("Also %d unknowns, which are probably binary." % unknown)
if unreadable: print("Plus %d files that couldn't be read." % unreadable)


On my system, it says:
rosuav@sikorsky:~$ python3 exectypes.py
/usr/local/bin/youtube-dl: data
Unreadable: /usr/bin/wine-safe
/usr/bin/mptopdf: LaTeX auxiliary file,
/usr/bin/gvfs-less: Palm OS dynamic library data "#!/bin/sh"
Unreadable: /usr/bin/gserialver
1140 text, 2060 binary
Also 3 unknowns, which are probably binary.
Plus 2 files that couldn't be read.

So a bit more than a third of my executables are text. That's a pretty
high proportion, and not very far off the rough guesstimate of half.
(And I tried this on three other Linuxes I have around the house,
getting broadly the same proportion, although the numbers are quite
different.)

ChrisA
0
Chris
7/16/2014 12:55:54 PM
Le mercredi 16 juillet 2014 14:10:16 UTC+2, Steven D'Aprano a =E9crit :

> ...


You are right iso-8859-1 is a plague.

py340

>>> timeit.repeat("'abc'.find('z')")
[0.3915996913892741, 0.3671049942086313, 0.3669506100733315]
>>> timeit.repeat("'abc'.find('oe')")
[0.5678031885837811, 0.5447948325424363, 0.5424782828388004]


note py325
>>> timeit.repeat("'abc'.find('z')")
[0.34638522543825445, 0.32732154158861704, 0.3253417225882629]
>>> timeit.repeat("'abc'.find('oe')")
[0.3162405415102256, 0.3027008165424263, 0.30290324880145647]


py340

>>> sys.getsizeof('z'*123 + 'z')
149
>>> sys.getsizeof('z'*123 + 'oe')
286

py325

>>> sys.getsizeof('z'*123 + 'z')
278
>>> sys.getsizeof('z'*123 + 'oe')
278

Brillant no?


jmf
0
wxjmfauth
7/16/2014 1:10:33 PM
Steven D'Aprano <steve+comp.lang.python@pearwood.info>:

> With a few exceptions, /etc is filled with text files, not binary
> files, and half the executables on the system are text (Python, Perl,
> bash, sh, awk, etc.).

Our debate seems to stem from a different idea of what text is. To me,
text in the Python sense is a sequence of UCS-4 character code points.
The opposite of text is not necessarily binary.

Most of those "text" files under /etc expect ASCII. In many contexts,
they tolerate UTF-8 or Latin-3 or whatever, but it's a bit iffy (how are
extra-ASCII passwords encoded in the /etc/shadow?). Also, the files
under /etc, /var/log etc should not depend on the locale since they are
typically interpreted by daemons, which typically don't possess locales.

> Relatively rare. Like, um, email, news, html, Unix config files,
> Windows ini files, source code in just about every language ever,
> SMSes, XML, JSON, YAML, instant messenger apps,

I would be especially wary of letting Python 3 interpret those files for
me. Python's [text] strings could be a wonderful tool on the inside of
my program, but I definitely would like to micromanage the I/O. Do I
obey the locale or not? That's too big (and painful) a question for
Python to answer on its own (and pretend like everything's under
control).

> word processors... even *graphic* applications invariably have a text
> tool.

Thing is, the serious text utilities like word processors probably need
lots of ancillary information so Python's [text] strings might be too
naive to represent even a single character.

>> More often, len(b'λ') is what I want.
>
> Oh really? Are you sure? What exactly is b'λ'?

That's something that ought to work in the UTF-8 paradise.
Unfortunately, Python only allows ASCII in bytes. ASCII only! In this
day and age! Even C is not so picky:

   #include <stdio.h>

   int main()
   {
       printf("Hyvää yötä\n");
       return 0;
   }


Marko
0
Marko
7/16/2014 1:11:26 PM
Le mercredi 16 juillet 2014 15:11:26 UTC+2, Marko Rauhamaa a =C3=A9crit=C2=
=A0:
> Steven D'Aprano <steve+comp.lang.python@pearwood.info>:
>=20
>=20
>=20
> > With a few exceptions, /etc is filled with text files, not binary
>=20
> > files, and half the executables on the system are text (Python, Perl,
>=20
> > bash, sh, awk, etc.).
>=20
>=20
>=20
> Our debate seems to stem from a different idea of what text is. To me,
>=20
> text in the Python sense is a sequence of UCS-4 character code points.
>=20
> The opposite of text is not necessarily binary.
>=20
>=20
>=20
> Most of those "text" files under /etc expect ASCII. In many contexts,
>=20
> they tolerate UTF-8 or Latin-3 or whatever, but it's a bit iffy (how are
>=20
> extra-ASCII passwords encoded in the /etc/shadow?). Also, the files
>=20
> under /etc, /var/log etc should not depend on the locale since they are
>=20
> typically interpreted by daemons, which typically don't possess locales.
>=20
>=20
>=20
> > Relatively rare. Like, um, email, news, html, Unix config files,
>=20
> > Windows ini files, source code in just about every language ever,
>=20
> > SMSes, XML, JSON, YAML, instant messenger apps,
>=20
>=20
>=20
> I would be especially wary of letting Python 3 interpret those files for
>=20
> me. Python's [text] strings could be a wonderful tool on the inside of
>=20
> my program, but I definitely would like to micromanage the I/O. Do I
>=20
> obey the locale or not? That's too big (and painful) a question for
>=20
> Python to answer on its own (and pretend like everything's under
>=20
> control).
>=20
>=20
>=20
> > word processors... even *graphic* applications invariably have a text
>=20
> > tool.
>=20
>=20
>=20
> Thing is, the serious text utilities like word processors probably need
>=20
> lots of ancillary information so Python's [text] strings might be too
>=20
> naive to represent even a single character.
>=20
>=20
>=20
> >> More often, len(b'=CE=BB') is what I want.
>=20
> >
>=20
> > Oh really? Are you sure? What exactly is b'=CE=BB'?
>=20
>=20
>=20
> That's something that ought to work in the UTF-8 paradise.
>=20
> Unfortunately, Python only allows ASCII in bytes. ASCII only! In this
>=20
> day and age! Even C is not so picky:
>=20
>=20
>=20
>    #include <stdio.h>
>=20
>=20
>=20
>    int main()
>=20
>    {
>=20
>        printf("Hyv=C3=A4=C3=A4 y=C3=B6t=C3=A4\n");
>=20
>        return 0;
>=20
>    }
>=20
>=20
>=20
>=20
>=20
> Marko

--------

And if you are visiting, spying the bugs tracker,
dev lists and ... you will happily, this perpertual
way of thinking:

if ascii:
    do stuff
else:
    find a work around

It's quite funny for a tool which pretends
to live in the unicode world.


jmd
0
wxjmfauth
7/16/2014 1:22:46 PM
On Wed, Jul 16, 2014 at 11:11 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
> Steven D'Aprano <steve+comp.lang.python@pearwood.info>:
>
>> With a few exceptions, /etc is filled with text files, not binary
>> files, and half the executables on the system are text (Python, Perl,
>> bash, sh, awk, etc.).
>
> Our debate seems to stem from a different idea of what text is. To me,
> text in the Python sense is a sequence of UCS-4 character code points.
> The opposite of text is not necessarily binary.

Let's shift things a moment for an analogy. What is audio? What is
sound? (Music, if you like, but I'm not going to get into the debate
of whether or not Band So-and-so's output should be called music.) I
have a variety of files that store music; some are RIFF WAVs, some are
MPEG level 3s, some are Ogg Vorbis files, and right now I have an MKV
of "Do you wanna build a snowman?" playing. (As far as I'm concerned,
it's primarily there for music, and the video image is buried behind
other windows. But I'll accept the argument that that's just a
container for some other format of audio, probably MPEG but I haven't
checked.) Sound, fundamentally, is a waveform, or a series of air
pressures.

Text, similarly, is not UCS-4, but a series of characters. We are
fortunate enough to have Unicode and can therefore define that text is
a sequence of Unicode codepoints, but the distinction isn't a feature
of Unicode; if you ask a primary school child to identify the letters
in a word, s/he should be able to do so, and that without any computer
involvement at all. Letters, digits, and other characters exist
independently of encodings or even character sets, but it's really
REALLY hard for computers to manipulate what they can't identify. So
let's define Unicode text as "a sequence of Unicode codepoints" or "a
sequence of Unicode characters", and proceed from there.

A file on a Unix or Windows file system consists of a sequence of
bytes. Ergo, a file cannot actually contain text; it must store
*encoded* text. But this is far and away the most common type of file
on any file system. Tweaking the previous script to os.walk() my home
directory, rather than scanning $PATH, the ratios are roughly 2:1 the
other way - heaps more text files than binary. And this is with my
Downloads/ directory being almost entirely binaries, and lots of them;
various zip files, deb packages, executables of various types... about
the only actual text there would be .patch files.

>> Relatively rare. Like, um, email, news, html, Unix config files,
>> Windows ini files, source code in just about every language ever,
>> SMSes, XML, JSON, YAML, instant messenger apps,
>
> I would be especially wary of letting Python 3 interpret those files for
> me. Python's [text] strings could be a wonderful tool on the inside of
> my program, but I definitely would like to micromanage the I/O. Do I
> obey the locale or not? That's too big (and painful) a question for
> Python to answer on its own (and pretend like everything's under
> control).

That's a problem that will be solved progressively, by daemons
shifting to UTF-8 for everything. But until then, you have to treat
log files as "messy" - you can't trust to a simple encoding. But
that's unusual compared to the common case. If you're reading your own
config files, you can simply stipulate that they are to be encoded
UTF-8, and if they're not, you throw an error. Simple! Works with the
easy way of opening files in Python. If you're reading someone else's
config files, you can either figure out what that program is
documented as expecting (and error out if the file's misencoded), or
treat it as messy and read it as binary.

>> word processors... even *graphic* applications invariably have a text
>> tool.
>
> Thing is, the serious text utilities like word processors probably need
> lots of ancillary information so Python's [text] strings might be too
> naive to represent even a single character.

Ancillary information? (La)TeX files are entirely text, and have all
that info in them somewhere. Open Documents are basically zip files of
XML data, where XML is ... all text. Granted, it's barely-readable
text, but it is UTF-8 encoded text. (I just checked an odt file that I
have sitting here, and it does contain a thumbnail in PNG format. But
the primary content is all XML files.)

>>> More often, len(b'=CE=BB') is what I want.
>>
>> Oh really? Are you sure? What exactly is b'=CE=BB'?
>
> That's something that ought to work in the UTF-8 paradise.
> Unfortunately, Python only allows ASCII in bytes. ASCII only! In this
> day and age! Even C is not so picky:
>
>    #include <stdio.h>
>
>    int main()
>    {
>        printf("Hyv=C3=A4=C3=A4 y=C3=B6t=C3=A4\n");
>        return 0;
>    }

And I have a program that lets me store 1.75 in an integer variable!
That's ever so much better than most programs. It's so much less
picky!

 Actually, Python allows all bytes in a bytestring, not just ASCII.
However, b'=CE=BB' has no meaning; in fact, even b'asdf' is dubious, and
this kind of notation exists only because there are many file formats
that mix ASCII text and binary data. To be truly accurate, b'asdf'
ought to be written as x'61736466' or something, because it's as
likely to mean 1634952294 or 1717859169 as it is to mean "asdf".

What is C actually storing in that string? Do you know? Can you be
truly sure that it's UTF-8? No, you cannot. Anyone might transcode
your source file, and I don't think C compilers are aware of character
literals and their associated encodings. More importantly, you cannot
be sure that that will print "Hyv=C3=A4=C3=A4 y=C3=B6t=C3=A4" to the consol=
e; if the
console is set to an encoding other than the one your source file was
using, you'll get mojibake. With Python, at least the interpreter gets
some idea of what's going on.

ChrisA
0
Chris
7/16/2014 2:04:41 PM
"Marko Rauhamaa" <marko@pacujo.net> wrote in message 
news:87egxl4zq8.fsf@elektro.pacujo.net...
> Steven D'Aprano <steve+comp.lang.python@pearwood.info>:
>
>> On Tue, 15 Jul 2014 23:01:25 +0300, Marko Rauhamaa wrote:
>>> In fact, I find the lazy use of Unicode strings at least as scary as
>>> the lazy use of byte strings, especially since Python 3 sneaks
>>> Unicode to the outer interfaces of the program (files, IPC).
>>
>> I'm not entirely sure I understand what you mean by "lazy use of
>> Unicode strings". And I especially don't understand what you mean by
>> "sneak". The fact that strings are Unicode is *the* biggest and most
>> obvious new feature of Python 3.
>
> I mean that sys.stdin and sys.stdout should deal with byte strings. I
> mean that open(path) should open a file in binary mode. Thankfully, the
> subprocess methods exchange bytes by default.
>
> To me, the main difference between Python 2 and Python 3 is that in the
> former, I use "..." everywhere, and in the latter, I use b"..."
> everywhere. If I should need advanced text processing features, I'll go
> through a decode() and encode().
>
>> The Python devs aren't slaves, they get to choose what features they
>> work on and which they don't. They don't owe *anybody* any feature
>> they don't want to build, or care to support, and that includes
>> continuing the 2.x series.
>
> No need to erect straw men. Of course, the Python gods do whatever they
> want. And you asked me to clarify my opinion, which I did. The breakage
> of backward compatibility wasn't worth the new features.
>
> But as I said, what is done is done. We'll live with the reality.
>

This sub-thread is the most constructive one I have seen yet that deals with 
the 'problems' that Python3 has created, and how to deal with them.

I take my hat off to Marko for his approach - it has affected him adversely, 
but it has not prevented him from continuing to develop using Python3.

FWIW, here are my thoughts -

1. There were many backward-incompatible changes made in Python3, but the 
only one that seems to cause problems is the change to the bytes/str types. 
I agree that it is a big change, but the others seem to have been accepted 
without argument, so it seems to me that the python devs got an awful lot 
right.

2. Those adversely affected by the change are very vocal, but we hear very 
little from those who have benefited from it. This is to be expected - they 
are just getting on with developing in Python3 and have no need to get 
involved in controversies.

I just tried an experiment in my own project. Ned Batchelder, in his 
Pragmatic Unicode presentation, http://nedbatchelder.com/text/unipain.html, 
suggests that you always have some unicode characters in your data, just to 
ensure that they are handled correctly. He has a tongue-in-cheek example 
which spells the word PYTHON using various exotic unicode characters. I used 
this to populate a field in my database, to see if it would display in my 
browser-based client.

The hardest part was getting it in. There are 6 characters, but utf-8 
requires 16 bytes to store it -

    b'\xe2\x84\x99\xc6\xb4\xe2\x98\x82\xe2\x84\x8c\xc3\xb8\xe1\xbc\xa4'.decode('utf-8')

However, that was it. Without any changes to my program, it read it from the 
database and displayed it on the screen. IE8 could only display 2 out of the 
6 characters correctly, and Chrome could display 5 out of 6, but that is a 
separate issue. Python3 handled it perfectly.

Would this have been so easy using Python2 - I don't think so. What follows 
is blatant speculation, but it is quite possible that there are many 
non-English speakers out there that have had their lives made much easier by 
the changes to Python3  - a 'silent majority'? I don't mean an absolute 
majority, as I believe there are still more Python2 users than Python3. But 
of those who have made the switch from 2 to 3, maybe most of them are quite 
happy. If so, then the python devs got that right as well.

Unfortunately, human nature being what it is, the possibility of this split 
in the community continuing, to the detriment of Python itself, is all too 
real. I don't know what more the python devs can do, but there are no 
guarantees of success :-(

Frank Millman



0
Frank
7/16/2014 2:27:56 PM
Chris Angelico <rosuav@gmail.com>:

> On Wed, Jul 16, 2014 at 11:11 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
>> I would be especially wary of letting Python 3 interpret those files for
>> me. [...]
>
> If you're reading your own config files, you can simply stipulate that
> they are to be encoded UTF-8, and if they're not, you throw an error.
> Simple! Works with the easy way of opening files in Python.

That's my point! It does not work.

   $ python3 -c "
   > import sys
   > sys.stdout.write(sys.stdin.read())" <<<"Hyvää yötä"
   Hyvää yötä
   $ LANG=en_US.ASCII python3 -c "
   > import sys
   > sys.stdout.write(sys.stdin.read())" <<<"Hyvää yötä"
   Traceback (most recent call last):
     File "<string>", line 3, in <module>
     File "/usr/lib/python3.2/encodings/ascii.py", line 26, in decode
       return codecs.ascii_decode(input, self.errors)[0]
   UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 3\
   : ordinal not in range(128)

In other words, the well-meaning Python3 blindly obeys the locale even
though I "simply stipulated" that my input is UTF-8.

>> Thing is, the serious text utilities like word processors probably
>> need lots of ancillary information so Python's [text] strings might
>> be too naive to represent even a single character.
>
> Ancillary information? (La)TeX files are entirely text,

I mean on the inside. For example, if emacs were to be written in
Python3, I don't know if it could use Python3's strings.

   Each character position in a buffer or a string can have a text property
   list, much like the property list of a symbol (see Property Lists). The
   properties belong to a particular character at a particular place, such
   as, the letter ‘T’ at the beginning of this sentence or the first ‘o’ in
   ‘foo’—if the same character occurs in two different places, the two
   occurrences in general have different properties. <URL:
   http://www.gnu.org/software/emacs/manual/html_node/elisp/Text-Prope
   rties.html>.

> What is C actually storing in that string? Do you know? Can you be
> truly sure that it's UTF-8? No, you cannot.

I happen to know it does. And again, I may "stipulate" it to use your
word.

Python, happily, is even more explicit about it:

   #!/usr/bin/env python3
   # -*- coding: utf-8 -*-


Marko
0
Marko
7/16/2014 2:39:17 PM
On Thu, Jul 17, 2014 at 12:27 AM, Frank Millman <frank@chagford.com> wrote:
> FWIW, here are my thoughts -
>
> 1. There were many backward-incompatible changes made in Python3, but the
> only one that seems to cause problems is the change to the bytes/str type=
s.
> I agree that it is a big change, but the others seem to have been accepte=
d
> without argument, so it seems to me that the python devs got an awful lot
> right.

There are quite a few changes that are almost completely
insignificant, like renaming (eg Tkinter to tkinter), where there's
this tiny difference at the top of your program and absolutely no
difference elsewhere. And there are a few where, for instance,
FileNotFoundError was created, as a subclass of OSError; I have a
program that needs to catch that exception, and I just have a trap at
the top that, if there's no FNFE, assigns it equal to OSError, and
then proceeds as normal. (This does mean that, under Python 2, the
mini HTTP server returns 404s for other types of OSError attempting to
read from certain files; under Python 3, those will result in 500s and
logged errors. I'm not overly concerned about that difference, but I
prefer the Py3 behaviour.) These sorts of changes, while technically
backward-incompatible, aren't going to cause argument - you just zip
through your code and change stuff (probably with a script like 2to3),
or else add a bit of header to ensure compatibility with both
versions. Pretty easy.

Then there are the changes that, while again technically
backward-incompatible, are practically identical *in normal usage*.
For instance, range no longer returns a list, but most range usage is
with iteration anyway. Dict views rather than lists might cause some
problems (if you iterate over d.keys() while mutating d, you'll have
problems in Py3, but in Py2 it's fine), but again, any place where you
have issues, you just tweak it to the new recommended style. Several
of these changes are actually less significant than one change that
happened within the 2.x line - the change from string exceptions to
subclasses of (Base)Exception. There have been a few complaints, but
they're not the stuff about which people say "Python 3 is killing
Python".

> 2. Those adversely affected by the change are very vocal, but we hear ver=
y
> little from those who have benefited from it. This is to be expected - th=
ey
> are just getting on with developing in Python3 and have no need to get
> involved in controversies.

That's very true. Sometimes you get an idea of how silent something is
and therefore how successful; for example, my house has been
progressively migrated almost exclusively to Linux, and the days that
go by without anyone asking me for help are proof that Linux is a
perfectly acceptable desktop OS. (Actually, even when people _do_ ask
me for help, it's usually either something to do with git, or
something advanced like "How can I find out which files in this whole
directory tree have been changed recently?", which your average user
wouldn't know off-hand how to do on Windows or OS/2 either.) Python 3
has served many people just fine, and those people aren't writing blog
posts about how unexciting their lives have become now that they don't
have to deal with bug reports about stuff the language just does for
them.

> I just tried an experiment in my own project. Ned Batchelder, in his
> Pragmatic Unicode presentation, http://nedbatchelder.com/text/unipain.htm=
l,
> suggests that you always have some unicode characters in your data, just =
to
> ensure that they are handled correctly. He has a tongue-in-cheek example
> which spells the word PYTHON using various exotic unicode characters. I u=
sed
> this to populate a field in my database, to see if it would display in my
> browser-based client.
>
> The hardest part was getting it in. There are 6 characters, but utf-8
> requires 16 bytes to store it -
>
>     b'\xe2\x84\x99\xc6\xb4\xe2\x98\x82\xe2\x84\x8c\xc3\xb8\xe1\xbc\xa4'.d=
ecode('utf-8')
>

Ideally, you would have a browser-based input system as well, which
would allow you to do the whole thing directly. Also, I would strongly
recommend using a database back-end that stores Unicode; and if that
back-end is MySQL, be aware that "utf8" is actually a messed-up
encoding that's like UTF-8 only restricted to three bytes (and
therefore the BMP), and you have to use "utf8mb4" to store all of
Unicode. With a decent back-end like PostgreSQL, you can do this sort
of thing directly:

rosuav=3D> create table test (id serial primary key,txt text);
CREATE TABLE
rosuav=3D> insert into test (txt) values ('U+1234 is =E1=88=B4');
INSERT 0 1
rosuav=3D> insert into test (txt) values ('U+12345 is =F0=92=8D=85');
INSERT 0 1
rosuav=3D> select id,txt,length(txt) from test;
 id |     txt      | length
----+--------------+--------
  1 | U+1234 is =E1=88=B4  |     11
  2 | U+12345 is =F0=92=8D=85 |     12
(2 rows)

Looks fine to me. You should be able to read and write Unicode from Python,=
 too.

> However, that was it. Without any changes to my program, it read it from =
the
> database and displayed it on the screen. IE8 could only display 2 out of =
the
> 6 characters correctly, and Chrome could display 5 out of 6, but that is =
a
> separate issue. Python3 handled it perfectly.

That's more of a font issue than anything else. I played around with
U+12345 in the above example, and it didn't display usefully in either
my console or Chrome here, but it's still obviously there as a single
character.

> Would this have been so easy using Python2 - I don't think so.

If all you ever do is read stuff from one place and write it to
another, it doesn't make a lot of difference whether you're working
with Unicode text or UTF-8 bytes. The trouble comes when you want to
take the length of it, trim it, or anything like that; for instance,
suppose you want to have a preview of the text, ellipsizing if the
full text is longer than (say) 30 characters, with the full text
available by clicking or hovering the mouse or something. At that
point, UTF-8 becomes a dashed nuisance, and true Unicode support makes
it a breeze.

> What follows
> is blatant speculation, but it is quite possible that there are many
> non-English speakers out there that have had their lives made much easier=
 by
> the changes to Python3  - a 'silent majority'? I don't mean an absolute
> majority, as I believe there are still more Python2 users than Python3. B=
ut
> of those who have made the switch from 2 to 3, maybe most of them are qui=
te
> happy. If so, then the python devs got that right as well.

It's impossible to say how many Py2 users there are and how many Py3.
But I would say that there are a HUGE number of people who've either
written Py3 code brand new, or ported something from Py2, and had no
significant trouble.

> Unfortunately, human nature being what it is, the possibility of this spl=
it
> in the community continuing, to the detriment of Python itself, is all to=
o
> real. I don't know what more the python devs can do, but there are no
> guarantees of success :-(

What split, exactly? There are always these talks of a split... but I
don't see one happening. I don't see, for instance,
python2-list@python.org or comp.lang.python2 being separated out. I
don't see Linux distributions choosing to support only one branch and
not the other (only one can be the default and the system Python, but
the other is usually just an apt-get/yum/pacman away). I don't see
anyone taking the Python 2 source code and backporting a bunch of
Python 3 features (and/or adding a bunch of their own features) and
creating the Python 2.8 that http://blog.startifact.com/guido_no.jpg
rejects. What split is actually occurring, or going to occur? I think
anyone who talks of splitting has an unrealistically low idea of the
costs of such a split; moving away from what the core Python devs are
doing means setting up everything fresh, and it's just way too much
work to do that.

I don't know what's going to happen in 2020, though. There might be a
split between three communities: the Python 3 community, the Red Hat
supported Python 2 community, and the ActiveState supported Python 2
community. Or maybe there'll be some other commercial support. Or
maybe there'll still be some measure of community support for Python 2
here on python-list and other such places, and there won't be a split
even then. (People have come here talking about Python 1.5, although
there isn't a huge amount of support for that anywhere!) Frankly, the
Python devs need do nothing and can do nothing; the mass of users will
go where it goes, 800lb gorilla style, and it's up to them to either
find their own bananas or join the python.org banana plantation. One
way or another, it'll work out.

ChrisA
0
Chris
7/16/2014 3:18:59 PM
On Thu, Jul 17, 2014 at 12:39 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
> In other words, the well-meaning Python3 blindly obeys the locale even
> though I "simply stipulated" that my input is UTF-8.

Except that you didn't - that input was not UTF-8. When you put a text
string as redirected input and then change LANG, you're lying to the
system, and you deserve all you get. Why are you even doing this,
other than to be able to point and laugh at programs that do the wrong
thing - when you've instructed them wrongly?

ChrisA
0
Chris
7/16/2014 3:23:25 PM
Chris Angelico <rosuav@gmail.com>:

> On Thu, Jul 17, 2014 at 12:39 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
>> In other words, the well-meaning Python3 blindly obeys the locale even
>> though I "simply stipulated" that my input is UTF-8.
>
> Except that you didn't - that input was not UTF-8. When you put a text
> string as redirected input and then change LANG, you're lying to the
> system, and you deserve all you get. Why are you even doing this,
> other than to be able to point and laugh at programs that do the wrong
> thing - when you've instructed them wrongly?

The example was artificial to make it small enough. The point is,
though, that it is dangerous to assume that the file formats agree with
the locale.


Marko
0
Marko
7/16/2014 3:48:18 PM
On 7/16/2014 10:27 AM, Frank Millman wrote:
> Would this have been so easy using Python2 - I don't think so. What follows
> is blatant speculation, but it is quite possible that there are many
> non-English speakers out there that have had their lives made much easier by
> the changes to Python3  - a 'silent majority'? I don't mean an absolute
> majority, as I believe there are still more Python2 users than Python3. But
> of those who have made the switch from 2 to 3, maybe most of them are quite
> happy. If so, then the python devs got that right as well.

Python3 has helped me cope with unexpected non-ASCII characters in other 
systems on our university campus while using a program written back 
before I knew anything about unicode.

When I first spotted mojibake appearing in a student's name and address, 
it was only a couple of emails and a little investigation to determine 
which encoding= bits to sprinkle into my program. And I was finished.

I wrote these applications a decade ago in Python2, and never worried 
about unicode. I translated them to Python3 years ago, and still never 
worried about unicode. The database is supposed to be sanitized against 
non-ASCII by an address and name-scrubbing application, which we aspend 
large amounts of cash on (I don't understand why, but that's what we do).

And thanks to Python3, even though "illegal" characters have crept in, 
and even though I had never worried about unicode before, I could fix my 
program(s) the instant I knew which encodings to use. It would have been 
much harder to get right using Python2.
-- 
Neil Cerutti


0
Neil
7/16/2014 3:48:20 PM
On Thu, Jul 17, 2014 at 1:48 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
> it is dangerous to assume that the file formats agree with
> the locale.

Of course. You never assume anything about encodings. What you do is
expect something about the encoding, and either throw an error if it's
wrong, or figure out some other encoding to use. With anything that
you broadly control (eg if your program is configured by a file in
/etc that nothing else uses), you just decode with whatever you
document your program as using, and any failure is *not your problem*.
It's that simple. You don't replace /etc/passwd with a JPEG encoded
photograph of your family tree and expect all your family to be able
to log in; no more should you expect a file to be parsed correctly if
it's meant to be UTF-8 and you save it in ISO-8859-4. The two cases
are equally ridiculous.

The only thing that might be an issue is that you can't use open(fn)
to read your files, but you have to explicitly state the encoding.
That would be an understandable problem, especially for someone who
develops on a single platform and forgets that the default differs. As
long as you always explicitly say encoding="utf-8", and document that
you do so, any problems are someone else's.

ChrisA
0
Chris
7/16/2014 4:07:28 PM
Chris Angelico <rosuav@gmail.com>:

> The only thing that might be an issue is that you can't use open(fn)
> to read your files, but you have to explicitly state the encoding.
> That would be an understandable problem, especially for someone who
> develops on a single platform and forgets that the default differs. As
> long as you always explicitly say encoding="utf-8", and document that
> you do so, any problems are someone else's.

Yes. I don't like open() guessing the enconding:

   The default encoding is platform dependent (whatever
   locale.getpreferredencoding() returns)

Also, I don't like sys.std* guessing the encoding:

   Under other platforms, the locale encoding is used (see
   locale.getpreferredencoding()).

In each case, it would have been better to default to bytes just like
subprocess does.


Marko
0
Marko
7/16/2014 4:20:14 PM
> I don't see anyone taking the Python 2 source code and backporting a
> bunch of Python 3 features (and/or adding a bunch of their own
> features) and creating the Python 2.8 that
> http://blog.startifact.com/guido_no.jpg rejects. What split is
> actually occurring, or going to occur? I think anyone who talks of
> splitting has an unrealistically low idea of the costs of such a
> split; moving away from what the core Python devs are doing means
> setting up everything fresh, and it's just way too much work to do
> that.

Up to now there have been no attemps of forking because python2.x was
still being developed and they even ported some of the features of
python3 to 2.6/2.7.

I think there has been a severe miscalculation, and the change in the
name of the interpreter python3 to python
http://legacy.python.org/dev/peps/pep-0394/ is a good example of the
disconnection between GvR and the real world.

Arch Linux was the only distro to fall in the trap, and those who use
it (as myself) need to put fake executables in /usr/local/bin
for everything: (python, sphinx, virtualenv...) selecting 2 or 3

http://sindhus.bitbucket.org/manage-python-2-3.html

Things are a bit more complex than just changing '#!/usr/bin/env python'
to '#!/usr/bin/env python2'

Let's see what it happens now that no more features are added to 2.x.
2.8 fork anybody?
0
Javier
7/16/2014 5:33:44 PM
On 16/07/2014 15:27, Frank Millman wrote:
>
> This sub-thread is the most constructive one I have seen yet that deals with
> the 'problems' that Python3 has created, and how to deal with them.
>

How many of the Python3 'problems' were backported to 2.7 or even 2.6?

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

Mark Lawrence

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


0
Mark
7/16/2014 5:34:36 PM
On Wed, Jul 16, 2014 at 11:33 AM, Javier <nospam@nospam.com> wrote:
> I think there has been a severe miscalculation, and the change in the
> name of the interpreter python3 to python
> http://legacy.python.org/dev/peps/pep-0394/ is a good example of the
> disconnection between GvR and the real world.

Er, that PEP currently recommends that python be a symlink to python2.
It states that at some point in the future, the recommendation will
change to have python symlink to python3.

> Arch Linux was the only distro to fall in the trap

You've got the order of events backward.  That PEP was created
*because* Arch decided to link python to python3.  Neither GvR nor
anybody else who work on Python have any control over that.
0
Ian
7/16/2014 5:50:24 PM
On 7/16/2014 3:49 AM, Steven D'Aprano wrote:

> There are certainly use-cases for stdin and stdout to use bytes, but
> there are also use-cases for them to deal with strings. I'll certainly
> grant you that there ought to be an easy way to get access to the binary
> streams,

As has been discussed before on this list, there is in 3.x.
https://docs.python.org/3/library/sys.html#sys.stdin

 >>> b=sys.stdin.buffer.readline()
a line
 >>> b
b'a line\r\n'

In other words, 3.x text mode (which essentially nothing to do with 2.x 
'text' mode), is a wrapped binary mode that gives users the *choice* to 
read bytes or text.

-- 
Terry Jan Reedy

0
Terry
7/16/2014 9:02:42 PM
On Wednesday, July 16, 2014 9:27:56 AM UTC-5, Frank Millman wrote:

> 2. Those adversely affected by the change are very vocal,
> but we hear very little from those who have benefited from
> it. This is to be expected - they are just getting on with
> developing in Python3 and have no need to get involved in
> controversies.

And those that "vote with their feet" are not vocal either.

Now, you might think: 
    
    "Why do i *I* care if people start using other languages?", 

Well, if you enjoy writing Python code, and understand (like
i do) that Python is truly valuable to the programming
community, then you should also understand that as the number
of members drop, so too does the "collective intelligence"
of the community. 

Not to mention that at some point, when the numbers get low
*enough*, maintaining a project as big as Python becomes
untenable.

Of course, no community or project can expect expansion of
members "forever", but the last thing you want is people
running away from your project. At a minimum, you want to
maintain a reasonable "average" of community members.

I personally know of few major software developers, who
whilst "shopping" for a scripting language for their API,
wanted to integrate Python because of it's clean syntax and
auto-encapsulation, but they where forced to choose *another*
language because of all the headaches that backwards
incompatibility of Python 3000 would induce in the users of
the API.



0
Rick
7/16/2014 10:41:38 PM
On 7/16/2014 5:02 PM, Terry Reedy wrote:
> On 7/16/2014 3:49 AM, Steven D'Aprano wrote:
>
>> There are certainly use-cases for stdin and stdout to use bytes, but
>> there are also use-cases for them to deal with strings. I'll certainly
>> grant you that there ought to be an easy way to get access to the binary
>> streams,
>
> As has been discussed before on this list, there is in 3.x.
> https://docs.python.org/3/library/sys.html#sys.stdin
>
>  >>> b=sys.stdin.buffer.readline()
> a line
>  >>> b
> b'a line\r\n'
>
> In other words, 3.x text mode (which essentially nothing to do with 2.x
> 'text' mode), is a wrapped binary mode that gives users the *choice* to
> read bytes or text.

One can also convert a stream permanently with .detach()
 >>> import sys
 >>> sys.stdin = sys.stdin.detach()
 >>> b = sys.stdin.readline()
a line
 >>> b
b'a line\r\n'

This does diable the input() function ;-).
 >>> b = input()
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
AttributeError: '_io.BufferedReader' object has no attribute 'errors'

-- 
Terry Jan Reedy

0
Terry
7/16/2014 10:47:37 PM
On 16/07/2014 23:41, Rick Johnson wrote:
>
> Not to mention that at some point, when the numbers get low
> *enough*, maintaining a project as big as Python becomes
> untenable.
>

I'm not aware of any mass exodus from core Python 3 to the fork that has 
consistently proposed to give the world Python 2.8.  Do you know 
something that I don't?

Further the number of people assisting on the bug tracker at the moment 
appears to me to be going up, not down.  It therefore strikes me that 
Python is extremely tenable, thus indicating that people are not falling 
for the FUD about Python 2 versus Python 3.

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

Mark Lawrence

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


0
Mark
7/16/2014 11:00:16 PM
On Wednesday, July 16, 2014 6:00:16 PM UTC-5, Mark Lawrence wrote:
> I'm not aware of any mass exodus from core Python 3 to the
> fork that has consistently proposed to give the world
> Python 2.8.  Do you know something that I don't?

Well, currently at least, we don't even *need* a Python 2.8,
not for the next couple of years anyway.

But i think that when the time arrives, the "someone", or
"some entity" will inevitably decide that, whilst Python2.x
was the best high level language available to date, it has
many flaws that cannot be worked around "cleanly", so
instead of continuing on with Python "as-is", we should take
all the good ideas of Python, plus all the good ideas of
Ruby, plus few good ideas in Perl, Javascript, etc... and
create a *whole* new language that will supersede them all.

    BECAUSE REMEMBER, EVOLUTION IS A GOOD THING!

This is what i wished the Python dev *would* have devoted
their energies to, not the abortion of "Python3" we have
today. Look, i don't mean to dismiss all the difficult work
invoked in creating Python3, but i just cannot support
something that is a lackluster improvement at best. If we're
going to break Python, let's do it "correctly".

You see, people just hate updating code for what is
basically the same language. HOWEVER, if you give them a
*new* language, that is an "intelligent evolution" of the
old language, then they will be *EXCITED* to write code
again.

> Further the number of people assisting on the bug tracker
> at the moment appears to me to be going up, not down.  It
> therefore strikes me that Python is extremely tenable,
> thus indicating that people are not falling for the FUD
> about Python 2 versus Python 3.

Again, your "metrics", are tainted. I believe the spike in
bug reports has less to do with:

    "New community members jumping in to help"

And more to do with:

    "Damn, this Python3 is buggy and i need to tell someone
    so i can get my customers off my back and this egg off
    my face, lest my feet move faster than Fred Flintstone!"

0
Rick
7/17/2014 1:16:16 AM
On Wed, 16 Jul 2014 19:20:14 +0300, Marko Rauhamaa wrote:

> Chris Angelico <rosuav@gmail.com>:
> 
>> The only thing that might be an issue is that you can't use open(fn) to
>> read your files, but you have to explicitly state the encoding. That
>> would be an understandable problem, especially for someone who develops
>> on a single platform and forgets that the default differs. As long as
>> you always explicitly say encoding="utf-8", and document that you do
>> so, any problems are someone else's.
> 
> Yes. I don't like open() guessing the enconding:

It doesn't *guess*. It has a sensible default encoding which, for most 
users most of the time, does the right thing. Ultimately though, the 
encoding is under your control: you can specify it if you think you know 
better.


>    The default encoding is platform dependent (whatever
>    locale.getpreferredencoding() returns)

Right. Most text files will be written using the preferred encoding, 
unless the user explicitly uses something else when writing the file. In 
that case it's the user's responsibility. Or if they've got the file from 
another system with a different encoding. But even then, the most common 
encodings are ASCII-compatible, which means that the lowest common 
denominator case (reading and writing ASCII files) will Just Work.

From a purity stand-point, no, open() shouldn't have a default encoding, 
and the user should have to specify it. But what makes you imagine that 
the user will know the correct encoding better than Python does? The 
average coder[1] shouldn't have to care about encodings just to do 
file.write("Hello World"), and on the average computer they don't have to 
because Python sets a sensible default.


But you know what? From a purity stand-point, *even binary mode* assumes 
an encoding of sorts. How do you know that binary files on your platform 
use eight-bit bytes? Some DSPs use 9-bit bytes, and historically 
computers had as few as 6 or as many as 60 bits per byte. This is why the 
C standard requires that a byte is *at least* 8 bits.

But, having said that, the assumption that binary files are based on 8-
bit bytes is pretty safe. It would be foolish to force the majority of 
people, who don't need to care about these sorts of details, to care 
about them just to suit the one in ten-thousand who do.

Likewise with text files. Python makes sensible defaults which will suit 
most people, rather than force people to guess the wrong encoding. But 
it's only a default, you can explicitly set it if you believe the file in 
question uses a different encoding.


[...]
> In each case, it would have been better to default to bytes just like
> subprocess does.

Better for whom? You? Maybe. For the typical programmer that Python is 
designed for? Hell no.




[1] Lets be honest, there still is a bias towards English and ASCII in 
computing, and probably this will remain the case until English ceases to 
be a de facto lingua franca. Most programming languages are written for 
J. Random Hacker, not Jランダムハッカー.


-- 
Steven
0
Steven
7/17/2014 2:51:56 AM
On Wed, 16 Jul 2014 18:16:16 -0700, Rick Johnson wrote:

> On Wednesday, July 16, 2014 6:00:16 PM UTC-5, Mark Lawrence wrote:
>> I'm not aware of any mass exodus from core Python 3 to the fork that
>> has consistently proposed to give the world Python 2.8.  Do you know
>> something that I don't?
> 
> Well, currently at least, we don't even *need* a Python 2.8, not for the
> next couple of years anyway.

There will never be a Python 2.8. When push comes to shove, the people 
bitching about Python 3 will not do the work necessary to fork Python 2.7 
and make a version 2.8.



-- 
Steven
0
Steven
7/17/2014 3:14:24 AM
On Thu, Jul 17, 2014 at 12:51 PM, Steven D'Aprano <steve@pearwood.info> wro=
te:
> Most programming languages are written for
> J. Random Hacker, not J=E3=83=A9=E3=83=B3=E3=83=80=E3=83=A0=E3=83=8F=E3=
=83=83=E3=82=AB=E3=83=BC.

I had to paste that into Google Translate to be able to understand
what you meant (although I could guess just fine)... but to actually
see the characters, I had to paste it into my MUD client. Yeah. Figure
that out. A MUD client had better font support for other languages
than a web browser with a dedicated translation tool.

ChrisA
0
Chris
7/17/2014 3:15:37 AM
On Wed, 16 Jul 2014 15:41:38 -0700, Rick Johnson wrote:

> I personally know of few major software developers, who whilst
> "shopping" for a scripting language for their API, wanted to integrate
> Python because of it's clean syntax and auto-encapsulation, but they
> where forced to choose *another* language because of all the headaches
> that backwards incompatibility of Python 3000 would induce in the users
> of the API.

Oh Really?

I call bullshit. Name names. Name projects.

If they are "shopping" for a scripting language, that means they don't 
have one yet. Which means their users have no existing scripts that need 
to be ported from Python 2 to 3. Whatever language is chosen, whether it 
is Ruby, Lua, Python 3 or something else, its all equally as new.


-- 
Steven
0
Steven
7/17/2014 3:16:00 AM
On Thu, Jul 17, 2014 at 11:16 AM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
> But i think that when the time arrives, the "someone", or
> "some entity" will inevitably decide that, whilst Python2.x
> was the best high level language available to date, it has
> many flaws that cannot be worked around "cleanly", so
> instead of continuing on with Python "as-is", we should take
> all the good ideas of Python, plus all the good ideas of
> Ruby, plus few good ideas in Perl, Javascript, etc... and
> create a *whole* new language that will supersede them all.
>
>     BECAUSE REMEMBER, EVOLUTION IS A GOOD THING!

Let 'em. If you believe evolution is such a good thing, you're most
welcome to arrange it. Personally, I believe that *guided development*
is a good thing, and whaddayaknow, that's exactly what we have here
from GvR and from the python-dev team. Proper development of a large
or small project requires an intelligent person with a hand on the
tiller, not randomly undirected additions (or, perhaps not
"undirected" so much as "directed by every single whining mailing list
post" - which is the same thing, really); someone needs to decide
which ideas are good and which are bad. Undirected evolution is
destructive. Directed cultivation is constructive.

ChrisA
0
Chris
7/17/2014 3:20:57 AM
On Wed, 16 Jul 2014 11:50:24 -0600, Ian Kelly wrote:

> On Wed, Jul 16, 2014 at 11:33 AM, Javier <nospam@nospam.com> wrote:
>> I think there has been a severe miscalculation, and the change in the
>> name of the interpreter python3 to python
>> http://legacy.python.org/dev/peps/pep-0394/ is a good example of the
>> disconnection between GvR and the real world.
> 
> Er, that PEP currently recommends that python be a symlink to python2.
> It states that at some point in the future, the recommendation will
> change to have python symlink to python3.
> 
>> Arch Linux was the only distro to fall in the trap
> 
> You've got the order of events backward.  That PEP was created *because*
> Arch decided to link python to python3.  Neither GvR nor anybody else
> who work on Python have any control over that.

This is correct. When Arch first announced this change, oh, four years 
ago if I remember correctly, the core devs were rather dismayed. Some of 
them would prefer to see "python" mean "python2" forever (which I happen 
to disagree with) but even those who would like to see "python" some day 
mean "python3" thought it was *way* too early.

I think that the sensible approach is to start by migrating internal 
tools to "python2" rather than "python", then migrate internal tools to 
python3, and gradually move towards having "python" mean "the user's 
python" rather than "the system python". That will be future-proof for 
Python 4 and Python 5.



-- 
Steven
0
Steven
7/17/2014 3:33:11 AM
Abhiram R <abhi.darkness@gmail.com> writes:

> ​Aah. Understood. Apologies for the "noobishness" :) ​

Thanks for understanding. Here is a good explanation of “Interleaved style”
<URL:https://en.wikipedia.org/wiki/Posting_style#Interleaved_style>
which is the proper etiquette for text-based discussions.

-- 
 \          “I used to be an airline pilot. I got fired because I kept |
  `\       locking the keys in the plane. They caught me on an 80 foot |
_o__)                    stepladder with a coathanger.” —Steven Wright |
Ben Finney

0
Ben
7/17/2014 4:02:35 AM
Chris “Kwpolska” Warrick <kwpolska@gmail.com> writes:

> Also, the correct solution for all those is getting a sane client that
> can hide quotes and signatures.

No, there is often useful (or at least interesting) information in a
message signature block; the problem is with *some* of them, not all of
them.

And the problem is that one message presents obnoxious crap to every
reader; suggesting that the recipient is the one responsible for
avoiding obnoxious behaviour in a public forum is a mistake of ethics.

The correct solution to obnoxious crap boilerplate in messages is for
the sender to take action to stop generating obnoxious crap boilerplate
in messages. And our job is to convince them to implement that solution.

-- 
 \       “If you define cowardice as running away at the first sign of |
  `\   danger, screaming and tripping and begging for mercy, then yes, |
_o__)               Mr. Brave man, I guess I'm a coward.” —Jack Handey |
Ben Finney

0
Ben
7/17/2014 4:17:02 AM
On Wed, 16 Jul 2014 17:33:44 +0000, Javier wrote:

> 2.8 fork anybody?

It already exists. It is called 2.7, and 2.6 before that. Python 3.0 came 
out on December 3rd, 2008, a couple of weeks before the last release of 
2.4 and in parallel with 2.5 (2.4.6 and 2.5.3 both came out on the 19th 
December). 2.6 and 2.7 are the transitional versions between 2.x and 3.x.

The core devs deliberately set out to have a long (10 years or more) 
transition period. Early adaptors can help iron out the issues with 
Python 3.0, 3.1 and 3.2, 3.3 starts going mainstream, and it won't be 
until probably 3.5 or 3.6 that Python 3 will be truly mainstream.

If you're still using Python 2.7 when Python 3.7 comes out in (likely 4 
or 5 years), you'll be in the same position as those who are still using 
Python 2.2 or 2.3 now: you'll either be happy with the status quo (and 
lack of external support) and will never change, or you've missed the 
boat.



-- 
Steven
0
Steven
7/17/2014 4:25:01 AM
On Wednesday, July 16, 2014 10:16:00 PM UTC-5, Steven D'Aprano wrote:
> If they are "shopping" for a scripting language, that
> means they don't have one yet. Which means their users
> have no existing scripts that need to be ported from
> Python 2 to 3. Whatever language is chosen, whether it is
> Ruby, Lua, Python 3 or something else, its all equally as
> new.

Sometimes, when we become proficient in an area of
expertise, we forget about all the stumbling blocks that
impede the neophytes -- which explains your befuddlement!

Even though i will freely admit that Python is the easiest
language to learn (IMHO), and more so because GvR did not
allow TIM-TOWDI to run rampant, Python2 already had many
stumbling blocks (new classes vs old classes crap!), but
Python3 exacerbated the problem by interjecting many, *MANY*
more stumbling blocks!

You and i don't use "print", and especially not "input" all
that much, but both of these (types of) functions are
*VITAL* lifelines for the noob when learning a language!

Not to mention the issues of looking at the wrong "version"
of a tutorial when using the "other" version of Python.
Again, you and i won't make these mistakes, but a noob will!

Look, Python has gone from: 
    "A noob friendly language"
    
to:
    "A Noobie subtle bug hell!". 
    
And since not all APIs are intended for "professional
programmers", choosing a language that is easy to learn, but
also, not "overly confusing" and "easy to misuse", is vital!

You cannot expect, say: "audio and video" people, to be
"professional programmers" -- who know all the "do's" and
"don'ts" of a dozen or so different languages and have
degrees in computer science and extensive knowledge of
algorithmic and logic theories!

They are just people who need to automate this or that task,
or create a functionality that does not exist via the GUI
interface, and as such, they should *NOT* need to be
burdened with the pitfalls of a backwards compatibility and
fractured community nightmare!

    NO THANKS PYTHON, WE WANT OUR USERS TO BE "PRODUCTIVE"!

0
Rick
7/17/2014 4:47:08 AM
"Steven D'Aprano" <steve+comp.lang.python@pearwood.info> wrote in message 
news:53c66ba8$0$9505$c3e8da3$5496439d@news.astraweb.com...
>
> E.g. having b"abc"[0] return 97 instead of b"a" was probably a mistake,
> but there are four versions of Python 3.x that do it that way and it's
> too late to change until Python 5000. (Python 4 is unlikely to break
> backwards compatibility in a big way.)
>

If it was considered important enough, couldn't they just introduce a new 
datatype, say B'...', with the desired behaviour. B'' would be backported to 
Python 2.7 as an alternative to b'', to faciliate writing code that works on 
both versions.

There would be a lot of overlap with b'...', but the differences could be 
documented. Methods could be added to B'' to replicate any behaviour of b'' 
which has been changed. Then over time b'' could be deprecated, and in 
Python 4 b'' could replace B''.

Frank Millman



0
Frank
7/17/2014 5:18:54 AM
On 15/07/2014 11:57 PM, Kevin Walzer wrote:
> The number of language revisions that result in deliberate, code-level
> incompatibility out there is pretty small. People rightly expect that
> code written for version 2.x of a language will continue to work with
> version 3.x, even if 3.x is designed to go in another direction.

PHP regularly breaks compatibility between _minor_ version releases:

http://php.net/manual/en/migration53.incompatible.php

Even more so with major releases:

http://php.net/manual/en/migration5.incompatible.php

And yet I never see anywhere near as much angst and agony as Python 3.x 
has caused.
0
alex23
7/17/2014 5:48:38 AM
"Chris Angelico" <rosuav@gmail.com> wrote in message 
news:CAPTjJmr4nPA6euD-j2uNAN==h=iDs1o5BDHGJ0FnjKJO9WfLXg@mail.gmail.com...
> On Thu, Jul 17, 2014 at 12:27 AM, Frank Millman <frank@chagford.com> 
> wrote:
>
>> Unfortunately, human nature being what it is, the possibility of this 
>> split
>> in the community continuing, to the detriment of Python itself, is all 
>> too
>> real.
>
> What split, exactly? There are always these talks of a split... but I
> don't see one happening.

It is worth watching this -
    https://www.youtube.com/watch?v=skYBOXE02OQ

This is the intro -

Kenneth Reitz, Python evangelist at Heroku and author of the popular 
Requests library, discusses the state of Python today, the division in the 
community, and how we can forge ahead into a shiny future. Pythonistas 
unite!


Frank



0
Frank
7/17/2014 6:31:14 AM
On Thu, Jul 17, 2014 at 4:31 PM, Frank Millman <frank@chagford.com> wrote:
> It is worth watching this -
>     https://www.youtube.com/watch?v=skYBOXE02OQ

Not in a position to watch Youtube vids at the moment. A blog post I'd
read, but a talk is not well suited to all forms of delivery... What's
it saying, can you summarize?

ChrisA
0
Chris
7/17/2014 6:41:12 AM
On Thu, 17 Jul 2014 15:48:38 +1000, alex23 wrote:

> On 15/07/2014 11:57 PM, Kevin Walzer wrote:
>> The number of language revisions that result in deliberate, code-level
>> incompatibility out there is pretty small. People rightly expect that
>> code written for version 2.x of a language will continue to work with
>> version 3.x, even if 3.x is designed to go in another direction.
> 
> PHP regularly breaks compatibility between _minor_ version releases:
> 
> http://php.net/manual/en/migration53.incompatible.php
> 
> Even more so with major releases:
> 
> http://php.net/manual/en/migration5.incompatible.php
> 
> And yet I never see anywhere near as much angst and agony as Python 3.x
> has caused.


Thank you for pointing this out! I thought that was the case with PHP, 
but I wasn't sure. Nice to have it confirmed.




-- 
Steven
0
Steven
7/17/2014 7:03:06 AM
"Chris Angelico" <rosuav@gmail.com> wrote in message 
news:CAPTjJmoT9q2CUYy5JC6kEYCxyp8_uSjHR1y8E+Z+T70QNc54xQ@mail.gmail.com...
> On Thu, Jul 17, 2014 at 4:31 PM, Frank Millman <frank@chagford.com> wrote:
>> It is worth watching this -
>>     https://www.youtube.com/watch?v=skYBOXE02OQ
>
> Not in a position to watch Youtube vids at the moment. A blog post I'd
> read, but a talk is not well suited to all forms of delivery... What's
> it saying, can you summarize?

I an also not in a position to watch it at the moment, but from memory ...

The talk is recent - the video is dated 1st July 2014.

He quotes some stats from PyPi, which shows number of downloads over a 
period, broken down by version. Over a recent period, Python2 downloads 
exceed Python3 downloads by a factor of 10:1 (subject to my memory ...)

He has talked to many influential pythonistas in the recent past. He 
particularly comments on discussions with one of the prominent Python3 
dissenters - Armin [can't remenber his surname].

He senses a great inertia in the established python community towards 
adopting Python3. He goes through some of the familiar reasons, most, if not 
all, relating to bytes/unicode.

He is concerned about a growing division in the community, not only between 
users of the two versions, but between the mainstream users many of whom are 
resisting the move to Python3, and the developers, who are committed to 
Python3 but can only improve it by getting feedback from users.

His closing plea was for users to get involved with Python3, help to improve 
it, and thereby help to re-unite the Python community.

Frank

P.S. If anyone watches the video, feel free to chip in and add to/correct 
what I have written above.



0
Frank
7/17/2014 7:09:59 AM
On 17/07/2014 04:14, Steven D'Aprano wrote:
> On Wed, 16 Jul 2014 18:16:16 -0700, Rick Johnson wrote:
>
>> On Wednesday, July 16, 2014 6:00:16 PM UTC-5, Mark Lawrence wrote:
>>> I'm not aware of any mass exodus from core Python 3 to the fork that
>>> has consistently proposed to give the world Python 2.8.  Do you know
>>> something that I don't?
>>
>> Well, currently at least, we don't even *need* a Python 2.8, not for the
>> next couple of years anyway.
>
> There will never be a Python 2.8. When push comes to shove, the people
> bitching about Python 3 will not do the work necessary to fork Python 2.7
> and make a version 2.8.
>

Actually I like the logic behind 2.8.

"We've only had eight years to port our code to Python 3.  That's not 
been long enough.  So to work around the situation we'll throw all of 
our miniscule resources into forking Python to solve all of the problems 
that Python has created for us".

Where is Walter Mitty when you need him?

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

Mark Lawrence

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


0
Mark
7/17/2014 7:17:06 AM
On Thu, 17 Jul 2014 07:18:54 +0200, Frank Millman wrote:

> "Steven D'Aprano" <steve+comp.lang.python@pearwood.info> wrote in
> message news:53c66ba8$0$9505$c3e8da3$5496439d@news.astraweb.com...
>>
>> E.g. having b"abc"[0] return 97 instead of b"a" was probably a mistake,
>> but there are four versions of Python 3.x that do it that way and it's
>> too late to change until Python 5000. (Python 4 is unlikely to break
>> backwards compatibility in a big way.)
>>
>>
> If it was considered important enough, couldn't they just introduce a
> new datatype, say B'...', with the desired behaviour. B'' would be
> backported to Python 2.7 as an alternative to b'', to faciliate writing
> code that works on both versions.

Sure, if it were considered important enough. But such an addition would 
add complexity and redundancy to the language, and would add one more 
thing that people have to learn and decide about. People would confuse 
which one was which, which would lead to bugs.

Since b'abcd'[0:1] takes only a tiny bit more effort than b'abcd'[0], 
fixing this is not considered worth the cost.


-- 
Steven
0
Steven
7/17/2014 7:49:13 AM
On Thu, Jul 17, 2014 at 5:09 PM, Frank Millman <frank@chagford.com> wrote:
> He quotes some stats from PyPi, which shows number of downloads over a
> period, broken down by version. Over a recent period, Python2 downloads
> exceed Python3 downloads by a factor of 10:1 (subject to my memory ...)

These kinds of stats are always flawed. In a lot of cases, they're
skewed heavily by defaults, and in other cases, skewed even more
heavily by long dependency trees - so, for instance, a single Django
installation might involve fetching large numbers of packages from
PyPI, even though no new code has been written at all. Might add quite
a bit to the download stats for one version or the other. And what
about upgrades? Stable installations are still likely to want to get
the latest, which means downloading from PyPI, ergo it's another hit.

ChrisA
0
Chris
7/17/2014 7:59:30 AM
On 17.07.2014 06:47, Rick Johnson wrote:> Even though i will freely 
admit that Python is the easiest
 > language to learn (IMHO)

For non-informatic students (i.e the vast majority of 
science/engineering students) I don't think that's true. Less general 
languages like Matlab appear much easier to me: unified doc, unified 
IDE, unified debugger, you can spend years without being confronted to 
what an "object" is, etc.

 > You and i don't use "print", and especially not "input" all
 > that much, but both of these (types of) functions are
 > *VITAL*  lifelines for the noob when learning a language!

Some argue that making print() working like all other python functions 
make it more consistent. Here for example:
http://tinyurl.com/o2oxp9m

 > Not to mention the issues of looking at the wrong "version"
 > of a tutorial when using the "other" version of Python.
 > Again, you and i won't make these mistakes, but a noob will!

It happened to me quite often that interesting tutorials where available 
in py2 only, despite the fact that all the concerned libraries were 
ported to py3 long ago.
But on the other hand, this is not python specific. Forums keep track of 
all questions/answers and some very old threads remain highly visible in 
the search results, making new users reinvent the wheel all the time. 
Everyone should be able to decide if the information found on blogs, 
forums or even newspapers is up-to-date or not.

Fab
0
Fabien
7/17/2014 10:12:23 AM
On Thu, Jul 17, 2014 at 8:12 PM, Fabien <fabien.maussion@gmail.com> wrote:
> On 17.07.2014 06:47, Rick Johnson wrote:> Even though i will freely admit
> that Python is the easiest
>> language to learn (IMHO)
>
> For non-informatic students (i.e the vast majority of science/engineering
> students) I don't think that's true. Less general languages like Matlab
> appear much easier to me: unified doc, unified IDE, unified debugger, you
> can spend years without being confronted to what an "object" is, etc.

That's always going to be true. If you have mathematical experience,
you'll be much more comfortable with a math-specific setup than with a
general programming environment. But for general programming, the IDE
isn't that much help, and the math-specific language is going to get
in the way. This is why there are so many different environments to
choose from; if you want something that makes it really easy to put a
Windows GUI program together, you probably grab one of the Microsoft
tools, but if you want something that lets you run your program on any
platform and still have a usable GUI, you want something
cross-platform (tkinter, GTK, wx, Qt). This is not a problem with
Python; it's simply how the world works.

ChrisA
0
Chris
7/17/2014 11:12:25 AM
On 2014-07-17 04:15, Chris Angelico wrote:
> On Thu, Jul 17, 2014 at 12:51 PM, Steven D'Aprano <steve@pearwood.info> wrote:
>> Most programming languages are written for
>> J. Random Hacker, not Jランダムハッカー.
>
> I had to paste that into Google Translate to be able to understand
> what you meant (although I could guess just fine)... but to actually
> see the characters, I had to paste it into my MUD client. Yeah. Figure
> that out. A MUD client had better font support for other languages
> than a web browser with a dedicated translation tool.
>
I can see the characters in both Thunderbird and Firefox.

0
MRAB
7/17/2014 11:27:09 AM
On Thursday, July 17, 2014 12:48:38 AM UTC-5, alex23 wrote:
> PHP regularly breaks compatibility between _minor_ version
> releases: [...] more so with major releases: [...] yet I
> never see anywhere near as much angst and agony as Python
> 3.x has caused.

Because you *IGNORE* the fact that people *ACTIVELY* choose
to use languages like Python, however, people *MOSTLY* use
languages like PHP and Javascript because they are *FORCED*

Of course, nature always contains "abnormalities" so i'm
sure there are few instances of people "seeking out" those
languages, but they *ARE* in the minority.

So, keeping those facts in mind, you can now understand why
people are so passionate about Python code breaks, and so
un-passionate about PHP and Javascript code breaks -- they're
already loathing in agony, so why would they seek to acerbate
it?
    
    POOR PITIFUL FOOLS!
0
Rick
7/17/2014 5:36:43 PM
On Fri, Jul 18, 2014 at 3:36 AM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
> they're already loathing in agony, so why would they seek to
> acerbate it?

This is a truly amazing demonstration. You have outdone Gaelmaen for
comprehensibly incorrect use of English.

ChrisA
0
Chris
7/17/2014 5:52:29 PM
On Thursday, July 17, 2014 5:12:23 AM UTC-5, Fabien wrote:
> For non-informatic students [...] I don't think that's true.
> Less general languages like Matlab appear much easier to
> me: unified doc, unified IDE, unified debugger

I'll agree that the lack of a "quality" IDE in Python is a
point of inadequacy. Sure, IDLE is not *useless*, however, it
is in fact woefully inadequate and should be embarrassing to
the whole community, both in it's buggy-ness and it's poorly
written source code.

I would love to see IDLE become a bit more "polished",
because, i believe that even though the software is outdated
and poorly structured , a simplistic *INTEGRATED* IDE can
be very helpful for new Python programmers who have no prior
programming experience.

Sadly, all of my calls to improve IDLE have been meet with
rebukes about me "whining". The "powers that be" would wise
to *UTILIZE* and *ENCOURAGE* my participation instead of
*IGNORING* valuable talent and *IMPEDING* the expansion of
this "private boys club".

> you can spend years without being confronted to what an
> "object" is, etc.

I believe one could eaisly ignore the OOP aspects of Pyhton
for as long as they wished, maybe even forever? Python is a
multi-paridigm language, and i'm quite happy with that fact

> Some argue that making print() work like all other
> python functions made it more consistent.

Yes, and i agree! Print should have been a function from day
one, however, i am not lamenting the "evolution" of "print",
i am merely lamenting the confusion induced from backwards
incompatibility between "new print" and "old print".

> It happened to me quite often that interesting tutorials
> where available in py2 only, despite the fact that all the
> concerned libraries were ported to py3 long ago. But on
> the other hand, this is not python specific. Forums keep
> track of all questions/answers and some very old threads
> remain highly visible in the search results, making new
> users reinvent the wheel all the time. Everyone should be
> able to decide if the information found on blogs, forums
> or even newspapers is up-to-date or not.

Really? Even noobies?

The internet is a double edged sword (when used to learn any
language) because although there is a vast wealth of
information out there for just about any question a noob
might have, if he does not phrase his google queries "just
so", he is doomed to read information that is at beast
confusing, and at worse just flat out lies.

I wish "we", as members of internet communities, had some
control over the vast amount of information lying around in
the darkest corners of the web. Because, we cannot rely
*solely* on our "official" tutorials to answer every
question a noob may have. And since we cannot control the
content of private sites, blogs, groups, etc..., our only
remedy is some sort of "official filtered search engine"
that will hide the outdated information, and expose only the
most relevant and updated information for the version
requested.

A database where pythonistas can categorize and "up vote" or
"down vote" the value of each piece of information. A sort
of "Stack Overflow" of the entire set of Python related
information violable on the web.

Of course it would need to utilize some heavy crowd
sourcing, but i believe something like this would be both
beneficial and feasible.




0
Rick
7/17/2014 6:15:59 PM
On Fri, Jul 18, 2014 at 4:15 AM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
> Sadly, all of my calls to improve IDLE have been meet with
> rebukes about me "whining". The "powers that be" would wise
> to *UTILIZE* and *ENCOURAGE* my participation instead of
> *IGNORING* valuable talent and *IMPEDING* the expansion of
> this "private boys club".

Do you write patches, or just say "This is terrible. Aorta do summing
about it."? [1] If you want something done, the best way is to do it.
Simply telling someone else what to do is not "participation" which
should be "encourage[d]", but is indeed likely to be whining.

Oh, and when you talk about it like this, you make everyone absolutely
sure that it really IS just whining.

ChrisA

[1] http://www.textfiles.com/humor/strine.txt
0
Chris
7/17/2014 6:27:28 PM
> On Fri, Jul 18, 2014 at 3:36 AM, Rick Johnson
> This is a truly amazing demonstration. You have outdone
> Gaelmaen for comprehensibly incorrect use of English.

Of all my impassioned pleas, astute logical reasoning, and
empathetic motivational speeches, of all of that "gold", all
you can muster is to harp about a few misspellings?

    ARE YOU SERIOUS?

Okay, i admit it. My spell checker is broken -- maybe it
was written in Python3 and it's fuzzy logic is a little too
fuzzy for it's own good?

0
Rick
7/17/2014 6:38:43 PM
Rick Johnson <rantingrickjohnson@gmail.com>:

> Sure, IDLE is not *useless*, however, it is in fact woefully
> inadequate and should be embarrassing to the whole community, both in
> it's buggy-ness and it's poorly written source code.

This is beneath trolling. Redeem yourself by apologizing.


Marko
0
Marko
7/17/2014 6:44:20 PM
On Fri, Jul 18, 2014 at 4:38 AM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
>> This is a truly amazing demonstration. You have outdone
>> Gaelmaen for comprehensibly incorrect use of English.
>
> Of all my impassioned pleas, astute logical reasoning, and
> empathetic motivational speeches, of all of that "gold", all
> you can muster is to harp about a few misspellings?
>
>     ARE YOU SERIOUS?
>
> Okay, i admit it. My spell checker is broken -- maybe it
> was written in Python3 and it's fuzzy logic is a little too
> fuzzy for it's own good?

Yeah, sure. That was absolute gold there, totally amazing stuff. I was
so absolutely astonished by the sheer ... uh, amazingness of it, that
I couldn't find anything to say.

Either that, or it was a load of drivel. Kinda hard to tell one from
the other, face like yours. But I imagine if if it were fear, your
eyes would be wider. Or something like that.

ChrisA
0
Chris
7/17/2014 6:48:19 PM
On 17/07/2014 19:15, Rick Johnson wrote:
> On Thursday, July 17, 2014 5:12:23 AM UTC-5, Fabien wrote:
>
> Sadly, all of my calls to improve IDLE have been meet with
> rebukes about me "whining". The "powers that be" would wise
> to *UTILIZE* and *ENCOURAGE* my participation instead of
> *IGNORING* valuable talent and *IMPEDING* the expansion of
> this "private boys club".
>

Terry Reedy and Co have been pouring improvements into IDLE via the bug 
tracker for months if not years.  How many times have you logged on 
there to help out?

The background that allows this to happen 
http://legacy.python.org/dev/peps/pep-0434/.  How strongly this 
contrasts with '*IGNORING* valuable talent and *IMPEDING* the expansion 
of this "private boys club"'.

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

Mark Lawrence

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


0
Mark
7/17/2014 7:06:51 PM
On 7/17/2014 11:15 AM, Rick Johnson wrote:

> Sadly, all of my calls to improve IDLE have been meet with
> rebukes about me "whining". The "powers that be" would wise
> to *UTILIZE* and *ENCOURAGE* my participation instead of
> *IGNORING* valuable talent and *IMPEDING* the expansion of
> this "private boys club".

I imagine those that would be in a position to improve idle don't see 
the point of it.  IMO, idle was never intended as a production 
development editor but more as an extensive example of gui programming 
with python.  Yes, you _can_ use it to edit, and there are nice python 
hooks, but I doubt that anyone with the skills to enhance idle actually 
uses idle.

You-can-also-program-using-notepad-eeew-ly y'rs,

Emile

0
Emile
7/17/2014 7:22:53 PM
On 17/07/2014 20:22, Emile van Sebille wrote:
> On 7/17/2014 11:15 AM, Rick Johnson wrote:
>
>> Sadly, all of my calls to improve IDLE have been meet with
>> rebukes about me "whining". The "powers that be" would wise
>> to *UTILIZE* and *ENCOURAGE* my participation instead of
>> *IGNORING* valuable talent and *IMPEDING* the expansion of
>> this "private boys club".
>
> I imagine those that would be in a position to improve idle don't see
> the point of it.  IMO, idle was never intended as a production
> development editor but more as an extensive example of gui programming
> with python.  Yes, you _can_ use it to edit, and there are nice python
> hooks, but I doubt that anyone with the skills to enhance idle actually
> uses idle.
>
> You-can-also-program-using-notepad-eeew-ly y'rs,
>
> Emile
>

Some of the top core developers teach classes using IDLE as it's the 
only tool guaranteed to be available on all the major platforms.  You 
might also like to view this https://www.youtube.com/watch?v=d1a4Jbjc-vU

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

Mark Lawrence

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


0
Mark
7/17/2014 8:37:31 PM
On 7/17/2014 3:22 PM, Emile van Sebille wrote:

> I imagine those that would be in a position to improve idle don't see
> the point of it.  IMO, idle was never intended as a production
> development editor but more as an extensive example of gui programming
> with python.  Yes, you _can_ use it to edit, and there are nice python
> hooks, but I doubt that anyone with the skills to enhance idle actually
> uses idle.

That is something of a problem as people 'graduate' to multi-language 
environments. However, while I have programmed in about 20 languages 
during my lifetime, I have now 'contracted' to using only Python (except 
for the occasional .bat file). So I use Idle to work on both my own 
stuff and on fixing Idle.  When I notice an issue while working on an 
issue, I file a new issue.

-- 
Terry Jan Reedy

0
Terry
7/17/2014 9:30:12 PM
On 17/07/2014 02:16, Rick Johnson wrote:
> On Wednesday, July 16, 2014 6:00:16 PM UTC-5, Mark Lawrence wrote:
>
>> Further the number of people assisting on the bug tracker
>> at the moment appears to me to be going up, not down.  It
>> therefore strikes me that Python is extremely tenable,
>> thus indicating that people are not falling for the FUD
>> about Python 2 versus Python 3.
>
> Again, your "metrics", are tainted. I believe the spike in
> bug reports has less to do with:

Where did I say anything about a spike in bug reports?  There are a 
large number of open reports, but a backlog built up as the core 
developers were at one point having to commit changes to five different 
versions.  Design work is being done to simplify this process and hence 
free up core developers' time.  It will take time but in a year or three 
I expect to see the number of open bugs dropping considerably.

>
>      "New community members jumping in to help"

The above is true, greatly helped by the core mentorship mailing list.

>
> And more to do with:
>
>      "Damn, this Python3 is buggy and i need to tell someone
>      so i can get my customers off my back and this egg off
>      my face, lest my feet move faster than Fred Flintstone!"
>

Wrong, e.g. there were far more bug reports about encode or decode 
errors in Python 2 than we (the Python community) see for Python 3.

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

Mark Lawrence

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


0
Mark
7/17/2014 10:54:58 PM
On 7/17/2014 2:15 PM, Rick Johnson wrote:
a partial disinformation rant again Idle
that repeats things said before, more than once.

In general, your rants seem to serve the social purpose of providing 
cover to other people to join in loose, off-topic discussions. In this 
one, you align yourself with the 'private boys club' idle haters you 
profess to disdain.

Some facts. Idlelib has about 60 modules. The tracker has, as I write, 
133 open issues (behavior and enhancements, with the boundary sometimes 
fuzzy) marked Component: Idle. That is about two issues per module. It 
is definitely less than 1 bug per 100 lines. There is only 1 bug, 
Windows-specific, that routinely gets in my way.

The stdlib has, I believe, less than 1000 modules. There are right now 
4545 open issues, or at least 4, maybe more, per module. Anyone who 
calls Idle (or anything else) 'buggy' and 'embarassing' should do some 
research and say 'compared to what' and 'by what standard'.

Last January, I discovered that tokenize.untokenize had about 5 bugs in 
about 25 lines of code. The new mode was hardly usable. I think *that* 
could be called 'embarassing' -- compared to the rest of the stdlib and 
by the standard of being basically usable. I fixed all but 1 of the 
implementation bugs.

More facts. Since 2.7 was released in July 2010, there have been 94 
issues with improvements recorded in idlelib/news.txt (extracted from 
the 2.7 news/changelog).  (Some issues have multiple patches, and some 
patches no recorded issue, but we can stick with the recorded issue 
count.)  Has the patch rate gone down or up?  Over half (46) of the 
issue patches are recorded in the last 15 months out of 48, less than a 
third, after the release of 2.7.5 on 2013 April 4. The reason for the 
uptick is PEP 434, which ended the blockage of Idle patches by useless 
debates over 'behavior' versus 'enhancement' and backport or not'.  It 
also ended (most of) the Idle hate rants on pydev.

> Sadly, all of my calls to improve IDLE have been meet with
> rebukes about me "whining".

Each of the 133 issues on the tracker is a specific, usually actionable, 
'call' to improve Idle. They are gradually being attended to. Generic 
'calls for improvement' on this list are useless.

 > The "powers that be"

When it comes to Idle, that means me as much as anyone.

> would wise to *UTILIZE* and *ENCOURAGE* my participation  <blah blah ...>

Still more facts ;-). About three (four?) years ago, you posted a 
similar rant. Being wise, I encouraged your participation and utilized 
the patch you anonymously posted on the tracker (to maintain your 
Ranting Rick pose) in one of my first commits. I invite you to resume 
your participation, either anonymously or openly.  As before, you can 
email me privately to discuss what would best suite you and also be helpful.

I will mention that one barrier to improving Idle code, beyond making 
small local fixes, is the need for automated tests before refactoring. I 
started a unittest suite in May 2013 with the help of GSOC (Google 
Summer of Code) students. In May 2014, this year's student and I 
collected together and improved the human-run tests.

-- 
Terry Jan Reedy

0
Terry
7/18/2014 12:13:44 AM
On 18/07/2014 01:13, Terry Reedy wrote:
> On 7/17/2014 2:15 PM, Rick Johnson wrote:
> a partial disinformation rant again Idle
> that repeats things said before, more than once.
>
> Still more facts ;-). About three (four?) years ago, you posted a
> similar rant. Being wise, I encouraged your participation and utilized
> the patch you anonymously posted on the tracker (to maintain your
> Ranting Rick pose) in one of my first commits. I invite you to resume
> your participation, either anonymously or openly.  As before, you can
> email me privately to discuss what would best suite you and also be
> helpful.
>

I'm looking forward to see the massive number of fixes that come from 
rr, assuming of course that he signs the CLA to make this possible.  Or 
has he already done so?

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

Mark Lawrence

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


0
Mark
7/18/2014 12:26:36 AM
On 2014.07.17 19:26, Mark Lawrence wrote:
> I'm looking forward to see the massive number of fixes that come from 
> rr, assuming of course that he signs the CLA to make this possible.  Or 
> has he already done so?
> 
Maybe he's too busy working on RickPy 4000 (or whatever it was called).
0
Andrew
7/18/2014 12:45:10 AM
On Fri, Jul 18, 2014 at 7:30 AM, Terry Reedy <tjreedy@udel.edu> wrote:
> That is something of a problem as people 'graduate' to multi-language
> environments. However, while I have programmed in about 20 languages during
> my lifetime, I have now 'contracted' to using only Python (except for the
> occasional .bat file). So I use Idle to work on both my own stuff and on
> fixing Idle.  When I notice an issue while working on an issue, I file a new
> issue.

Glad to hear it. Best way to make sure Idle stays developed is for its
core developers to actively use it.

For myself, though, I completely do not use the editor half of it; but
it's spectacularly useful (with limitations) as my primary interactive
interpreter. That's partly because, on Windows, the command-line
interpreter absolutely *sucks* (because most of its UI comes from
cmd.exe - my view might be different if I had a different shell, but
there's no point because Idle just blows it away), and partly because
command recall/editing works on entire syntactic units rather than on
lines. In fact, if I were to name *one single feature* that made Idle
useful rather than a mere toy, it would have to be the ability to
recall an entire function/class definition from command history for
further editing. That is hugely helpful to me. It's what makes Python
actually 100% usable in interactive mode - go right ahead, define
functions and classes just as you would in a file! (Okay, you have to
watch out about blank lines. Not usually an issue, but you'll possibly
notice that I seldom have any internal blanks when I post a class
definition on-list - it's because I usually write them in Idle.)

The only problem I have with it is that blatting ridiculous amounts of
text to the console can take a very long time, esp on Windows. If I
accidentally display a large object when I thought I was displaying a
small one, it'll hang for quite a while, churning through something,
and it's not easy to see why or to halt it. But I suspect that's more
of a Windows and/or Tk issue than an Idle one.

ChrisA
0
Chris
7/18/2014 2:15:15 AM
On Thursday, July 17, 2014 1:44:20 PM UTC-5, Marko Rauhamaa wrote:
> Rick Johnson :
> > Sure, IDLE is not *useless*, however, it is in fact
> > woefully inadequate and should be embarrassing to the
> > whole community, both in it's buggy-ness and it's poorly
> > written source code.
> This is beneath trolling. Redeem yourself by apologizing.

Apologize for what? 

For telling the truth? 

I have been using IDLE since around 2006, well at least,
that is as far back as i remember. When i first learned
Python, IDLE was my editor of choice, and i *STILL* use IDLE
to this very day! -- although not as much as i have written
my own IDE.

I have logged thousands upon thousands of hours with IDLE,
how many hours have *YOU* logged?

I would even venture to say, and the comments on this list
have supported my evidence for years, that i may be the
*SOLE* heavy user of IDLE in the *ENTIRE* community.
Although, i need to compare my stats with Terry because he
claims to use the software quite often also.

If *ANYBODY* in this damn community has a *RIGHT* to
complain about IDLE, then *I* am that person. HOW DARE YOU
chastise me for voicing my grievances regarding a
software that *YOU* most likely have *NEVER*, or only 
*SLIGHTLY*, used!

0
Rick
7/18/2014 2:24:34 AM
On Fri, Jul 18, 2014 at 12:24 PM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
> I would even venture to say, and the comments on this list
> have supported my evidence for years, that i may be the
> *SOLE* heavy user of IDLE in the *ENTIRE* community.
> ...
>
> If *ANYBODY* in this damn community has a *RIGHT* to
> complain about IDLE, then *I* am that person. HOW DARE YOU
> chastise me for voicing my grievances regarding a
> software that *YOU* most likely have *NEVER*, or only
> *SLIGHTLY*, used!

Even if it is true that you're the only *user* of IDLE (or Idle; Terry
seems to spell it the latter way, I'm not sure what's the official
recommendation now), that does not give you any right whatsoever to
complain about it. There are two valid reasons for claiming a right to
complain:

1) You are the primary *developer* of the system, and put in many
hours of work actually making it happen; or
2) You have paid money to someone, paying them a reasonable hourly
rate for the same sort of level of work.

So I would say Terry has a right to complain. I certainly don't, even
though it's my primary Windows Python interface (on Linux boxes, I
usually use 'python' or 'python3' in a regular xfce4-terminal; I do
use IDLE on Linux as well, but not as often and certainly not as my
primary interface to Python). To me, IDLE is a gift; a freely-granted
boon to my use of this language. It's a huge step up from REXXTry (or
even EREXXTry, the 'extended' version that has decent command-line
editing tools); due to limitations on the REXX 'INTERPRET' command,
it's impossible to define functions interactively, and a few other
things. (That said, though, EREXXTry was for over a decade my sole
interactive interpreter for any language. It was either that or save
something to a file and run it.) Do I whine and complain because my
gift isn't absolutely perfect? No. I might *humbly* open a discussion,
but it's with the attitude of "these people have given hugely of their
time" rather than "these people have done something which is WRONG".

ChrisA
0
Chris
7/18/2014 2:39:15 AM
On 17/07/2014 1:14 PM, Steven D'Aprano wrote:
> There will never be a Python 2.8. When push comes to shove, the people
> bitching about Python 3 will not do the work necessary to fork Python 2.7
> and make a version 2.8.

+1

The idea that forking and maintaining Python 2.8 is somehow _less 
effort_ than porting code to Python 3.x is batshit crazy. The Py2.8 
claims seem to me to be nothing more than a shallow attempt to blackmail 
the core devs.

0
alex23
7/18/2014 2:49:05 AM
On 18/07/2014 10:26 AM, Mark Lawrence wrote:
> I'm looking forward to see the massive number of fixes that come from
> rr

I'm still waiting for RickPython, the One True Python.

Remember when he used to rant as if he was actually working on it and 
not just pissing in the wind?

0
alex23
7/18/2014 2:54:12 AM
On 18/07/2014 10:45 AM, Andrew Berg wrote:
> Maybe he's too busy working on RickPy 4000 (or whatever it was called).

I believe the new working name is PypeDream.

0
alex23
7/18/2014 3:01:13 AM
On Thu, Jul 17, 2014 at 7:49 PM, alex23 <wuwei23@gmail.com> wrote:
> On 17/07/2014 1:14 PM, Steven D'Aprano wrote:
>>
>> There will never be a Python 2.8. When push comes to shove, the people
>> bitching about Python 3 will not do the work necessary to fork Python 2.7
>> and make a version 2.8.
>
>
> +1
>
> The idea that forking and maintaining Python 2.8 is somehow _less effort_
> than porting code to Python 3.x is batshit crazy.

Probably.

I'd say that if anything kills Python, it'll be the people who are
afraid of a small dose of positive change.
0
Dan
7/18/2014 3:34:25 AM
On Thursday, July 17, 2014 9:15:15 PM UTC-5, Chris Angelico wrote:
> For myself, though, I completely do not use the editor half of [IDLE]; but
> it's spectacularly useful (with limitations) as my primary interactive
> interpreter. 

Yes Chris, i also think that the IDLE shell is "spectacular"
when i'm using it, especially when i press
"CONTROL+LEFT_ARROW" and the insertion cursor lands *BEHIND*
the start of the interactive command marker " >>>", an
area where key presses are not allowed, so *NOW* I must press
"CONTROL+RIGHT_ARROW" three times to get to my destination!

I'm also just "gushing with exuberance" when i open a new
block and i get *EIGHT SPACE INDENTION*!

And I get a raging semi each time IDLE hangs between run
sessions when i'm editing Tkinter code, yes Chris,  I GET A
BIG FAT ERECTION! Sometimes, when it does not go away
after four hours, i have to visit the local emergency room
and take some pills.

 THAT'S HOW MUCH I JUST *LOVE* THIS CRAPPY SOFTWARE CHRIS! 

 I'M SO GLAD WE CAN SHARE THESE "WONDERFUL" EXPERIENCES TOGETHER!
 
 MAYBE NEXT WE CAN RE-INACT THE LAST SCENE OF ROMEO AND JULIETTE?

> [...] The only problem I have with it is that blatting
> ridiculous amounts of text to the console can take a very
> long time, esp on Windows. If I accidentally display a
> large object when I thought I was displaying a small one,
> it'll hang for quite a while, churning through something,
> and it's not easy to see why or to halt it. But I suspect
> that's more of a Windows and/or Tk issue than an Idle one.

The *PROBLEM* is that user has no method of "undo-ing" an
accidental display of huge amounts of data , forcing the
user to close and then re-open the entire software -- can
you understand now *WHY* i complain about this software? 

This is *EMBARRASSING*, and you should *ALL* be ashamed
that, not only does Python include such an amateurish piece
of crap software, but it has been there for years! 
    
    UNCHANGED FOR YEARS!!!

0
Rick
7/18/2014 3:37:07 AM
On 07/17/2014 08:24 PM, Rick Johnson wrote:
> i *STILL* use IDLE
> to this very day! -- although not as much as i have written
> my own IDE.

Maybe you should release it so we can make demands of you without
bothering to contribute to it's development, either in code, or in bug
reports.



0
Michael
7/18/2014 3:40:59 AM
Rick Johnson <rantingrickjohnson@gmail.com>:

> On Thursday, July 17, 2014 1:44:20 PM UTC-5, Marko Rauhamaa wrote:
>> Rick Johnson :
>> > Sure, IDLE is not *useless*, however, it is in fact woefully
>> > inadequate and should be embarrassing to the whole community, both
>> > in it's buggy-ness and it's poorly written source code.

>> This is beneath trolling. Redeem yourself by apologizing.
>
> Apologize for what? 
>
> For telling the truth? 

The truth has nothing to do about it. You just don't talk like that
about somebody's labor of love.


Marko
0
Marko
7/18/2014 5:24:50 AM
On Fri, Jul 18, 2014 at 1:37 PM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
> I'm also just "gushing with exuberance" when i open a new
> block and i get *EIGHT SPACE INDENTION*!

Actually, you don't. And it wouldn't be a bug if you did.

ChrisA
0
Chris
7/18/2014 5:34:31 AM
On 18/07/2014 01:45, Andrew Berg wrote:
> On 2014.07.17 19:26, Mark Lawrence wrote:
>> I'm looking forward to see the massive number of fixes that come from
>> rr, assuming of course that he signs the CLA to make this possible.  Or
>> has he already done so?
>>
> Maybe he's too busy working on RickPy 4000 (or whatever it was called).
>

I believe that rick would be a very apt word in this case.

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

Mark Lawrence

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


0
Mark
7/18/2014 7:24:54 AM
On 18/07/2014 03:24, Rick Johnson wrote:
> On Thursday, July 17, 2014 1:44:20 PM UTC-5, Marko Rauhamaa wrote:
>> Rick Johnson :
>>> Sure, IDLE is not *useless*, however, it is in fact
>>> woefully inadequate and should be embarrassing to the
>>> whole community, both in it's buggy-ness and it's poorly
>>> written source code.
>> This is beneath trolling. Redeem yourself by apologizing.
>
> Apologize for what?
>
> For telling the truth?
>
> I have been using IDLE since around 2006, well at least,
> that is as far back as i remember. When i first learned
> Python, IDLE was my editor of choice, and i *STILL* use IDLE
> to this very day! -- although not as much as i have written
> my own IDE.
>
> I have logged thousands upon thousands of hours with IDLE,
> how many hours have *YOU* logged?
>
> I would even venture to say, and the comments on this list
> have supported my evidence for years, that i may be the
> *SOLE* heavy user of IDLE in the *ENTIRE* community.
> Although, i need to compare my stats with Terry because he
> claims to use the software quite often also.
>
> If *ANYBODY* in this damn community has a *RIGHT* to
> complain about IDLE, then *I* am that person. HOW DARE YOU
> chastise me for voicing my grievances regarding a
> software that *YOU* most likely have *NEVER*, or only
> *SLIGHTLY*, used!
>

Please list for everybody to see the issue numbers that you've worked 
on, on IDLE, on the bug tracker.  Thank you.

I now routinely use IDLE as it has been so much improved due to the 
efforts of Terry & Co.  You are conspicious by your absence.

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

Mark Lawrence

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


0
Mark
7/18/2014 7:34:14 AM
On Thu, Jul 17, 2014 at 9:37 PM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
> On Thursday, July 17, 2014 9:15:15 PM UTC-5, Chris Angelico wrote:
>> For myself, though, I completely do not use the editor half of [IDLE]; but
>> it's spectacularly useful (with limitations) as my primary interactive
>> interpreter.
>
> Yes Chris, i also think that the IDLE shell is "spectacular"
> when i'm using it, especially when i press
> "CONTROL+LEFT_ARROW" and the insertion cursor lands *BEHIND*
> the start of the interactive command marker " >>>", an
> area where key presses are not allowed, so *NOW* I must press
> "CONTROL+RIGHT_ARROW" three times to get to my destination!

I just tried to reproduce this using IDLE 3.4 on Windows and was not able to.

> I'm also just "gushing with exuberance" when i open a new
> block and i get *EIGHT SPACE INDENTION*!

In the file editor when I press Tab I get four spaces as I would
expect, using the default configuration. In the interactive
interpreter I get an actual tab character again as I would expect.
That's probably as it should be since I wouldn't want to not be able
to type a tab character there.
0
Ian
7/18/2014 8:21:13 AM
On Fri, Jul 18, 2014 at 6:21 PM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
>> Yes Chris, i also think that the IDLE shell is "spectacular"
>> when i'm using it, especially when i press
>> "CONTROL+LEFT_ARROW" and the insertion cursor lands *BEHIND*
>> the start of the interactive command marker " >>>", an
>> area where key presses are not allowed, so *NOW* I must press
>> "CONTROL+RIGHT_ARROW" three times to get to my destination!
>
> I just tried to reproduce this using IDLE 3.4 on Windows and was not able to.

Actually, now you mention it, I do recall experiencing a bug like this
in previous versions. It's not the case in either my 2.7 (point
something, but I don't remember what) nor 3.4, so I'm guessing it's
been fixed.

ChrisA
0
Chris
7/18/2014 8:27:03 AM
On 2014-07-18, alex23 <wuwei23@gmail.com> wrote:
> On 17/07/2014 1:14 PM, Steven D'Aprano wrote:
>> There will never be a Python 2.8. When push comes to shove, the people
>> bitching about Python 3 will not do the work necessary to fork Python 2.7
>> and make a version 2.8.
>
> +1
>
> The idea that forking and maintaining Python 2.8 is somehow _less 
> effort_ than porting code to Python 3.x is batshit crazy. The Py2.8 
> claims seem to me to be nothing more than a shallow attempt to blackmail 
> the core devs.

IMO, it's not even a credible "threat".  It's more like idle whinging
from people whom if given a brand new free BMW with lifetime
maintenance, gasoline, insurance, taxes and registration paid (and a
garage to keep it in) would bitch about the color of the interior.

-- 
Grant Edwards               grant.b.edwards        Yow! I'm pretending that
                                  at               we're all watching PHIL
                              gmail.com            SILVERS instead of RICARDO
                                                   MONTALBAN!
0
Grant
7/18/2014 2:17:03 PM
On 2014-07-18, Rick Johnson <rantingrickjohnson@gmail.com> wrote:
> On Thursday, July 17, 2014 1:44:20 PM UTC-5, Marko Rauhamaa wrote:
>> Rick Johnson :

>>> Sure, IDLE is not *useless*, however, it is in fact woefully
>>> inadequate and should be embarrassing to the whole community, both in
>>> it's buggy-ness and it's poorly written source code.

>> This is beneath trolling. Redeem yourself by apologizing.
>
> Apologize for what? 

Oh dear.  Where should we start...

> For telling the truth? 

Possibly, yes.  Truth is no excuse for being rude and insulting.  I've
never used IDLE, so don't know much about it. But, I do know that a
decent, civilized person just doesn't make insulting comments like
that about somebody else's work even if it is true (which I very much
doubt).

-- 
Grant Edwards               grant.b.edwards        Yow! If I am elected no one
                                  at               will ever have to do their
                              gmail.com            laundry again!
0
Grant
7/18/2014 2:19:59 PM
On Fri, Jul 18, 2014 at 8:19 AM, Grant Edwards <invalid@invalid.invalid> wrote:
> But, I do know that a
> decent, civilized person just doesn't make insulting comments like
> that about somebody else's work even if it is true (which I very much
> doubt).

Now, _that's_ funny. This is the internet. If you can't stand the heat
get out of the kitchen.
0
Larry
7/18/2014 2:35:18 PM
Hall�chen!

Larry Martell writes:

> On Fri, Jul 18, 2014 at 8:19 AM, Grant Edwards <invalid@invalid.invalid> wrote:
>
>> But, I do know that a decent, civilized person just doesn't make
>> insulting comments like that about somebody else's work even if
>> it is true (which I very much doubt).
>
> Now, _that's_ funny. This is the internet. If you can't stand the
> heat get out of the kitchen.

Now, _that's_ funny. This is the internet. If you can't stand people
who can't stand the heat get out of the kitchen.

Tsch�,
Torsten.

-- 
Torsten Bronger    Jabber ID: torsten.bronger@jabber.rwth-aachen.de
                                  or http://bronger-jmp.appspot.com
0
Torsten
7/18/2014 3:25:13 PM
On 18/07/2014 04:01, alex23 wrote:
> On 18/07/2014 10:45 AM, Andrew Berg wrote:
>> Maybe he's too busy working on RickPy 4000 (or whatever it was called).
>
> I believe the new working name is PypeDream.
>

For me a very good day just got better with that one, thanks :)

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

Mark Lawrence

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


0
Mark
7/18/2014 3:45:51 PM
On 2014-07-18 04:37, Rick Johnson wrote:
> On Thursday, July 17, 2014 9:15:15 PM UTC-5, Chris Angelico wrote:
>> For myself, though, I completely do not use the editor half of [IDLE]; but
>> it's spectacularly useful (with limitations) as my primary interactive
>> interpreter.
>
> Yes Chris, i also think that the IDLE shell is "spectacular"
> when i'm using it, especially when i press
> "CONTROL+LEFT_ARROW" and the insertion cursor lands *BEHIND*
> the start of the interactive command marker " >>>", an
> area where key presses are not allowed, so *NOW* I must press
> "CONTROL+RIGHT_ARROW" three times to get to my destination!
>
> I'm also just "gushing with exuberance" when i open a new
> block and i get *EIGHT SPACE INDENTION*!
>
> And I get a raging semi each time IDLE hangs between run
> sessions when i'm editing Tkinter code, yes Chris,  I GET A
> BIG FAT ERECTION! Sometimes, when it does not go away
> after four hours, i have to visit the local emergency room
> and take some pills.
>
>   THAT'S HOW MUCH I JUST *LOVE* THIS CRAPPY SOFTWARE CHRIS!
>
>   I'M SO GLAD WE CAN SHARE THESE "WONDERFUL" EXPERIENCES TOGETHER!
>
>   MAYBE NEXT WE CAN RE-INACT THE LAST SCENE OF ROMEO AND JULIETTE?
>
>> [...] The only problem I have with it is that blatting
>> ridiculous amounts of text to the console can take a very
>> long time, esp on Windows. If I accidentally display a
>> large object when I thought I was displaying a small one,
>> it'll hang for quite a while, churning through something,
>> and it's not easy to see why or to halt it. But I suspect
>> that's more of a Windows and/or Tk issue than an Idle one.
>
> The *PROBLEM* is that user has no method of "undo-ing" an
> accidental display of huge amounts of data , forcing the
> user to close and then re-open the entire software -- can
> you understand now *WHY* i complain about this software?
>
> This is *EMBARRASSING*, and you should *ALL* be ashamed
> that, not only does Python include such an amateurish piece
> of crap software, but it has been there for years!
>
>      UNCHANGED FOR YEARS!!!
>
I'm sorry to hear that you've been suffering all these years. If only
there were a way to fix it.

Here's a suggestion for the Python community: how about opening up the
source code and letting people contribute fixes? We could call this
"open source".

We could even open the source for CPython itself! Could that work?

What do you think?

0
MRAB
7/18/2014 3:46:31 PM
On 18/07/2014 04:37, Rick Johnson wrote:
> On Thursday, July 17, 2014 9:15:15 PM UTC-5, Chris Angelico wrote:
>> For myself, though, I completely do not use the editor half of [IDLE]; but
>> it's spectacularly useful (with limitations) as my primary interactive
>> interpreter.
>
> Yes Chris, i also think that the IDLE shell is "spectacular"
> when i'm using it, especially when i press
> "CONTROL+LEFT_ARROW" and the insertion cursor lands *BEHIND*
> the start of the interactive command marker " >>>", an
> area where key presses are not allowed, so *NOW* I must press
> "CONTROL+RIGHT_ARROW" three times to get to my destination!
>
> I'm also just "gushing with exuberance" when i open a new
> block and i get *EIGHT SPACE INDENTION*!
>
> And I get a raging semi each time IDLE hangs between run
> sessions when i'm editing Tkinter code, yes Chris,  I GET A
> BIG FAT ERECTION! Sometimes, when it does not go away
> after four hours, i have to visit the local emergency room
> and take some pills.
>
>   THAT'S HOW MUCH I JUST *LOVE* THIS CRAPPY SOFTWARE CHRIS!
>
>   I'M SO GLAD WE CAN SHARE THESE "WONDERFUL" EXPERIENCES TOGETHER!
>
>   MAYBE NEXT WE CAN RE-INACT THE LAST SCENE OF ROMEO AND JULIETTE?
>
>> [...] The only problem I have with it is that blatting
>> ridiculous amounts of text to the console can take a very
>> long time, esp on Windows. If I accidentally display a
>> large object when I thought I was displaying a small one,
>> it'll hang for quite a while, churning through something,
>> and it's not easy to see why or to halt it. But I suspect
>> that's more of a Windows and/or Tk issue than an Idle one.
>
> The *PROBLEM* is that user has no method of "undo-ing" an
> accidental display of huge amounts of data , forcing the
> user to close and then re-open the entire software -- can
> you understand now *WHY* i complain about this software?
>
> This is *EMBARRASSING*, and you should *ALL* be ashamed
> that, not only does Python include such an amateurish piece
> of crap software, but it has been there for years!
>
>      UNCHANGED FOR YEARS!!!
>

This is patently wrong, IDLE is constantly being improved.  I also don't 
recall ever seeing a bug report from yourself about IDLE.  Your gretest 
strength seems to be complaining, your biggest weakness doing anything 
about whatever it is that you're complaining about.

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

Mark Lawrence

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


0
Mark
7/18/2014 3:49:17 PM
On 18/07/2014 09:27, Chris Angelico wrote:
> On Fri, Jul 18, 2014 at 6:21 PM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
>>> Yes Chris, i also think that the IDLE shell is "spectacular"
>>> when i'm using it, especially when i press
>>> "CONTROL+LEFT_ARROW" and the insertion cursor lands *BEHIND*
>>> the start of the interactive command marker " >>>", an
>>> area where key presses are not allowed, so *NOW* I must press
>>> "CONTROL+RIGHT_ARROW" three times to get to my destination!
>>
>> I just tried to reproduce this using IDLE 3.4 on Windows and was not able to.
>
> Actually, now you mention it, I do recall experiencing a bug like this
> in previous versions. It's not the case in either my 2.7 (point
> something, but I don't remember what) nor 3.4, so I'm guessing it's
> been fixed.
>
> ChrisA
>

Fixed by whom, Terry Reedy & Co or rr?

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

Mark Lawrence

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


0
Mark
7/18/2014 3:50:44 PM
On 18/07/2014 16:46, MRAB wrote:
> On 2014-07-18 04:37, Rick Johnson wrote:
>> On Thursday, July 17, 2014 9:15:15 PM UTC-5, Chris Angelico wrote:
>>> For myself, though, I completely do not use the editor half of
>>> [IDLE]; but
>>> it's spectacularly useful (with limitations) as my primary interactive
>>> interpreter.
>>
>> Yes Chris, i also think that the IDLE shell is "spectacular"
>> when i'm using it, especially when i press
>> "CONTROL+LEFT_ARROW" and the insertion cursor lands *BEHIND*
>> the start of the interactive command marker " >>>", an
>> area where key presses are not allowed, so *NOW* I must press
>> "CONTROL+RIGHT_ARROW" three times to get to my destination!
>>
>> I'm also just "gushing with exuberance" when i open a new
>> block and i get *EIGHT SPACE INDENTION*!
>>
>> And I get a raging semi each time IDLE hangs between run
>> sessions when i'm editing Tkinter code, yes Chris,  I GET A
>> BIG FAT ERECTION! Sometimes, when it does not go away
>> after four hours, i have to visit the local emergency room
>> and take some pills.
>>
>>   THAT'S HOW MUCH I JUST *LOVE* THIS CRAPPY SOFTWARE CHRIS!
>>
>>   I'M SO GLAD WE CAN SHARE THESE "WONDERFUL" EXPERIENCES TOGETHER!
>>
>>   MAYBE NEXT WE CAN RE-INACT THE LAST SCENE OF ROMEO AND JULIETTE?
>>
>>> [...] The only problem I have with it is that blatting
>>> ridiculous amounts of text to the console can take a very
>>> long time, esp on Windows. If I accidentally display a
>>> large object when I thought I was displaying a small one,
>>> it'll hang for quite a while, churning through something,
>>> and it's not easy to see why or to halt it. But I suspect
>>> that's more of a Windows and/or Tk issue than an Idle one.
>>
>> The *PROBLEM* is that user has no method of "undo-ing" an
>> accidental display of huge amounts of data , forcing the
>> user to close and then re-open the entire software -- can
>> you understand now *WHY* i complain about this software?
>>
>> This is *EMBARRASSING*, and you should *ALL* be ashamed
>> that, not only does Python include such an amateurish piece
>> of crap software, but it has been there for years!
>>
>>      UNCHANGED FOR YEARS!!!
>>
> I'm sorry to hear that you've been suffering all these years. If only
> there were a way to fix it.
>
> Here's a suggestion for the Python community: how about opening up the
> source code and letting people contribute fixes? We could call this
> "open source".
>
> We could even open the source for CPython itself! Could that work?
>
> What do you think?
>

That plan is so cunning it makes Baldrick's cunning plans look good :)

http://en.wikipedia.org/wiki/Baldrick

Actually I believe we should just leave things alone, if it ain't broke, 
don't fix it.

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

Mark Lawrence

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


0
Mark
7/18/2014 4:22:04 PM
On Thu, 17 Jul 2014 10:36:43 -0700, Rick Johnson wrote:

> On Thursday, July 17, 2014 12:48:38 AM UTC-5, alex23 wrote:
>> PHP regularly breaks compatibility between _minor_ version releases:
>> [...] more so with major releases: [...] yet I never see anywhere near
>> as much angst and agony as Python 3.x has caused.
> 
> Because you *IGNORE* the fact that people *ACTIVELY* choose to use
> languages like Python, however, people *MOSTLY* use languages like PHP
> and Javascript because they are *FORCED*

That explains all those concentration camps in North Korea, filled with 
political prisoners sentenced to 30 years of PHP programming.



-- 
Steven
0
Steven
7/18/2014 6:01:25 PM
On Thu, 17 Jul 2014 11:15:59 -0700, Rick Johnson wrote:

> On Thursday, July 17, 2014 5:12:23 AM UTC-5, Fabien wrote:
>> For non-informatic students [...] I don't think that's true. Less
>> general languages like Matlab appear much easier to me: unified doc,
>> unified IDE, unified debugger
> 
> I'll agree that the lack of a "quality" IDE in Python is a point of
> inadequacy. 

https://wiki.python.org/moin/IntegratedDevelopmentEnvironments

PyDev, Eric, Komodo, PyCharm, WingIDE, SPE, Ninja-IDE, Geany, IEP, 
Spyder, Boa Constructor, PyScripter, NetBeans, Emacs, KDevelop, 
BlackAdder, ...



[...]
> Sadly, all of my calls to improve IDLE have been meet with rebukes about
> me "whining". 

Why don't you go volunteer to fix a few IDLE bugs, instead of just 
demanding that others do it?

http://bugs.python.org/issue17620



-- 
Steven
0
Steven
7/18/2014 6:20:10 PM
On 18/07/2014 19:20, Steven D'Aprano wrote:
> On Thu, 17 Jul 2014 11:15:59 -0700, Rick Johnson wrote:
>
>> Sadly, all of my calls to improve IDLE have been meet with rebukes about
>> me "whining".
>
> Why don't you go volunteer to fix a few IDLE bugs, instead of just
> demanding that others do it?
>
> http://bugs.python.org/issue17620
>

Has time to complain but doesn't have time to fix bugs?

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

Mark Lawrence

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


0
Mark
7/18/2014 6:31:23 PM
On Thu, 17 Jul 2014 20:13:44 -0400, Terry Reedy wrote:

> On 7/17/2014 2:15 PM, Rick Johnson wrote: a partial disinformation rant
> again Idle that repeats things said before, more than once.
[...]


Thanks for the detailed explanation Terry, and especially thanks for the 
good work you have done on IDLE. I'll admit I don't use it, I dislike the 
UI, but given all the solid work you and the GSOC students have put into 
it, perhaps I ought to check it out again soon.



> Still more facts ;-). About three (four?) years ago, you posted a
> similar rant. Being wise, I encouraged your participation and utilized
> the patch you anonymously posted on the tracker (to maintain your
> Ranting Rick pose) in one of my first commits.

Well well, I must admit I am shocked to learn that Rick has actually 
written some Python code.


-- 
Steven
0
Steven
7/18/2014 6:38:21 PM
On 2014-07-18 19:20, Steven D'Aprano wrote:
> On Thu, 17 Jul 2014 11:15:59 -0700, Rick Johnson wrote:
>
>> On Thursday, July 17, 2014 5:12:23 AM UTC-5, Fabien wrote:
>>> For non-informatic students [...] I don't think that's true. Less
>>> general languages like Matlab appear much easier to me: unified
>>> doc, unified IDE, unified debugger
>>
>> I'll agree that the lack of a "quality" IDE in Python is a point of
>> inadequacy.
>
> https://wiki.python.org/moin/IntegratedDevelopmentEnvironments
>
> PyDev, Eric, Komodo, PyCharm, WingIDE, SPE, Ninja-IDE, Geany, IEP,
> Spyder, Boa Constructor, PyScripter, NetBeans, Emacs, KDevelop,
> BlackAdder, ...
>
[snip]

Yes, but _apart_ from PyDev, Eric, Komodo, PyCharm, WingIDE, SPE,
Ninja-IDE, Geany, IEP, Spyder, Boa Constructor, PyScripter, NetBeans,
Emacs, KDevelop and BlackAdder, why isn't there a "quality" IDE?

(Sorry, but it had to be said. :-))
0
MRAB
7/18/2014 7:44:23 PM
On Friday, July 18, 2014 1:20:10 PM UTC-5, Steven D'Aprano wrote:
> PyDev, Eric, Komodo, PyCharm, WingIDE, SPE, Ninja-IDE,
> Geany, IEP, Spyder, Boa Constructor, PyScripter, NetBeans,
> Emacs, KDevelop, BlackAdder, ...

And tell me Steven, how many of those "quality" IDEs that
you listed actually *SHIP* with Python?

The *WHOLE* reason for GvR *CREATING* and then *SHIPPING*
IDLE, was to provide a simplistic native IDE for the noobs.
That was his gift to the noobs, HOWEVER, this community has
*SQUANDERED* that gift, and allowed it putrefy for over a
decade and a half!

A noob has not idea what an IDE *IS*, much less where to
find a decent IDE, or what IDEs are even compatible with
Python! IDLE was meant to provide a tool by which noobs can
use to start writing Python code "out of the box".

Do you remember the acronym of "CP4E"[1]? Sadly, most people
in this community seem to forgotten, *MAYBE* even the
dicktator himself!

[1]: https://www.python.org/doc/essays/cp4e/

0
Rick
7/18/2014 9:37:23 PM
On 7/18/14 5:37 PM, Rick Johnson wrote:
> On Friday, July 18, 2014 1:20:10 PM UTC-5, Steven D'Aprano wrote:
>> PyDev, Eric, Komodo, PyCharm, WingIDE, SPE, Ninja-IDE,
>> Geany, IEP, Spyder, Boa Constructor, PyScripter, NetBeans,
>> Emacs, KDevelop, BlackAdder, ...
>
> And tell me Steven, how many of those "quality" IDEs that
> you listed actually *SHIP* with Python?
>
> The *WHOLE* reason for GvR *CREATING* and then *SHIPPING*
> IDLE, was to provide a simplistic native IDE for the noobs.
> That was his gift to the noobs, HOWEVER, this community has
> *SQUANDERED* that gift, and allowed it putrefy for over a
> decade and a half!
>
> A noob has not idea what an IDE *IS*, much less where to
> find a decent IDE, or what IDEs are even compatible with
> Python! IDLE was meant to provide a tool by which noobs can
> use to start writing Python code "out of the box".
>
> Do you remember the acronym of "CP4E"[1]? Sadly, most people
> in this community seem to forgotten, *MAYBE* even the
> dicktator himself!
>
> [1]: https://www.python.org/doc/essays/cp4e/
>

As a group, we have dealt with caustic respondents before.  The way to 
get them to stop dragging threads into pointless arguments is to ignore 
them.  I would advise doing the same in this case.  All I see here is 
disrespectful trolling.

-- 
Ned Batchelder, http://nedbatchelder.com

0
Ned
7/18/2014 10:09:30 PM
On 7/17/2014 8:26 PM, Mark Lawrence wrote:
> On 18/07/2014 01:13, Terry Reedy wrote:
>> On 7/17/2014 2:15 PM, Rick Johnson wrote:
>> a partial disinformation rant again Idle
>> that repeats things said before, more than once.
>>
>> Still more facts ;-). About three (four?) years ago, you posted a
>> similar rant. Being wise, I encouraged your participation and utilized
>> the patch you anonymously posted on the tracker (to maintain your
>> Ranting Rick pose) in one of my first commits. I invite you to resume
>> your participation, either anonymously or openly.  As before, you can
>> email me privately to discuss what would best suite you and also be
>> helpful.
>>
>
> I'm looking forward to see the massive number of fixes that come from
> rr, assuming of course that he signs the CLA to make this possible.  Or
> has he already done so?

I don't remember the alias to check.


-- 
Terry Jan Reedy

0
Terry
7/18/2014 11:26:04 PM
On 7/17/2014 10:39 PM, Chris Angelico wrote:
> IDLE (or Idle; Terry
> seems to spell it the latter way, I'm not sure what's the official
> recommendation now),

You found me out ;-). FORTRAN is now Fortran, and I hate typing IDLE, 
and that spelling somehow strikes me as pretentious, so I decided to 
un-officially promote Idle by typing it this way.

-- 
Terry Jan Reedy

0
Terry
7/18/2014 11:45:21 PM
On 7/17/2014 11:37 PM, Rick Johnson wrote:
> On Thursday, July 17, 2014 9:15:15 PM UTC-5, Chris Angelico wrote:
>> For myself, though, I completely do not use the editor half of [IDLE]; but
>> it's spectacularly useful (with limitations) as my primary interactive
>> interpreter.
>
> Yes Chris, i also think that the IDLE shell is "spectacular"
> when i'm using it, especially when i press
> "CONTROL+LEFT_ARROW" and the insertion cursor lands *BEHIND*
> the start of the interactive command marker " >>>",

What ancient version, or oddball system are you using? For me, Win 7, 
both 2.7.8 and 3.4.1
 >>> abc "CONTROL+LEFT_ARROW" and the cursor is before the 'a'. The HOME 
key goes to the same place first, and they before >>> on the second 
press (and before 'a' on the third).

 > an
> area where key presses are not allowed, so *NOW* I must press
> "CONTROL+RIGHT_ARROW" three times to get to my destination!

If see different behavior with *current* Python+Idle, please give 
details. Let's try to find out why and fix it. Check 
..idlerc/config-keys.cfg in your home directory.

> I'm also just "gushing with exuberance" when i open a new
> block and i get *EIGHT SPACE INDENTION*!

http://bugs.python.org/issue7676 "IDLE shell shouldn't use TABs"
is a high-priority for me. The problem is agreeing on an *exact* 
specification for new behavior, that takes into account both the 
limitations and flexibility of tk. Maybe I should start a thread here or 
python-ideas, where people are willing to discuss details.


> IDLE hangs between run
> sessions when i'm editing Tkinter code

I cannot connect this description to behavior I have seen.

>> [...] The only problem I have with it is that blatting
>> ridiculous amounts of text to the console can take a very
>> long time, esp on Windows. If I accidentally display a
>> large object when I thought I was displaying a small one,
>> it'll hang for quite a while, churning through something,
>> and it's not easy to see why or to halt it. But I suspect
>> that's more of a Windows and/or Tk issue than an Idle one.

^C 'should' stop output 'eventually'.  Sometimes does, sometimes not.

> The *PROBLEM* is that user has no method of "undo-ing" an
> accidental display of huge amounts of data , forcing the
> user to close and then re-open the entire software

I believe there is a proposal to be able to clear the shell window. We 
just need to add "Clear and restart shell". There is also an idea to put 
help output in an output window. Undo-ing the result of hitting <enter> 
seems like a sensible extension of undoing the result of hitting a key 
in the editor.

I opened "Idle: better management of Shell window output"
http://bugs.python.org/issue22010
for all three ideas, and gave you credit for part of the undo idea.

>      UNCHANGED FOR YEARS!!!

So sign the contributor agreement and volunteer to write and review patches.

-- 
Terry Jan Reedy

0
Terry
7/19/2014 1:21:36 AM
On 7/18/2014 11:50 AM, Mark Lawrence wrote:
> On 18/07/2014 09:27, Chris Angelico wrote:
>> On Fri, Jul 18, 2014 at 6:21 PM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
>>>> Yes Chris, i also think that the IDLE shell is "spectacular"
>>>> when i'm using it, especially when i press
>>>> "CONTROL+LEFT_ARROW" and the insertion cursor lands *BEHIND*
>>>> the start of the interactive command marker " >>>", an
>>>> area where key presses are not allowed, so *NOW* I must press
>>>> "CONTROL+RIGHT_ARROW" three times to get to my destination!
>>>
>>> I just tried to reproduce this using IDLE 3.4 on Windows and was not
>>> able to.
>>
>> Actually, now you mention it, I do recall experiencing a bug like this
>> in previous versions. It's not the case in either my 2.7 (point
>> something, but I don't remember what) nor 3.4, so I'm guessing it's
>> been fixed.

I know there was an issue and fix for <Home> in the shell. I suspect 
Control+LeftArrow was looked at and fixed at the same time, if not before.

> Fixed by whom, Terry Reedy & Co or rr?

Other people.

-- 
Terry Jan Reedy

0
Terry
7/19/2014 1:27:47 AM
Earlier, I mentioned a considerable number of IDEs which are available 
for Python, including:

PyDev, Eric, Komodo, PyCharm, WingIDE, SPE, Ninja-IDE, Geany, IEP,
Spyder, Boa Constructor, PyScripter, NetBeans, Emacs, KDevelop, and
BlackAdder.

https://wiki.python.org/moin/IntegratedDevelopmentEnvironments

There is also IDLE, which is part of the standard Python installation, as 
well as my preference: Unix/Linux as an IDE.

http://blog.sanctum.geek.nz/series/unix-as-ide/
http://michaelochurch.wordpress.com/2013/01/09/ide-culture-vs-unix-philosophy/


Some people ask:

"How many of those quality IDEs ship with Python?"

Most don't, of course, since they are third-party tools. Not that it 
matters: it's 2014, not 1974, and anyone in the developed world 
interested in computer programming has easy access to the information 
superhighway sometimes know as "the Internet". (Many people in developing 
nations also have access to the Internet, and those who don't probably 
have bigger problems to worry about.) With the Internet, most of these 
IDEs are normally just a few clicks away.

People using Linux will generally find that they can install some of 
these IDEs using their package manager. For example, Red Hat Linux based 
systems such on Centos or Fedora can use the yum package manager, e.g.:

    yum install geany geany-plugins

while Debian and Ubuntu based systems (such as Mint) can use apt-get or 
aptitude, e.g.:

    aptitude install eric
    apt-get install spe

Of course, most Linux distros include a GUI front-end to their package 
manager, but frankly if you're programming on Linux and you're unwilling 
to use the command line, you're making life harder for yourself than it 
need be.

Windows and OS X users, sadly, miss out on the power of an integrated 
package manager. OS X have a couple of third-party packaging systems, 
MacPorts and Homebrew:

    http://www.macports.org/
    http://brew.sh/

Unfortunately, software development on Windows is something of a ghetto, 
compared to the wide range of free tools available for Linux. Outside of 
a few oases like Microsoft's own commercial development tools, it's hard 
to do development on Windows. Hard, but not impossible, of course, and 
there are quite a few resources available for the Windows user willing to 
download installers from the Internet. For Python users, the IDEs from 
Wingware and Activestate are notable:

    https://wingware.com/
    http://komodoide.com/


Some people are under the impression that IDEs are mostly or even solely 
for the benefit of "newbies" or "n00bs". That's a gross misunderstanding 
of the situation: the average newbie is likely to be happy writing code 
using Notepad, or whatever bare-bones text editor they're used to, and 
may not even know what an IDE is. It's those with some experience in 
programming (particularly in the Java and Visual Basic worlds) who are 
more likely to expect an IDE.

Another patronising view is that those who are new to programming are 
automatically too incompetent or ignorant to download or install an IDE 
without hand-holding. Even if that were the case, there is no shortage of 
hand-holding available on the Internet, with dozens or hundreds of 
forums, mailing lists, tutorial, videos and blogs offering to help. (It 
is undeniable that the quality of these is *extremely* variable, but 
that's another story.) This is the Internet generation, if software has a 
downloadable installer, or can be installed using a package manager, most 
people can deal with it, and those who can't have many opportunities to 
learn. (It's probably a bit much to expect the average newbie to install 
software from source, especially on Windows which doesn't come with much 
in the way of compilers and other development tools, but still, it has to 
be said that if you're hoping to become a programmer, installing software 
from source is one of the skills you should learn.)

So why does Python ship with IDLE? It's not because Python requires an 
IDE, or that newbies need one, or that there aren't alternatives. The 
biggest reason for Python shipping with an IDE is not that people are 
unable to install alternatives, but that a lot of people are *prohibited* 
from doing so. For those of us who have control over our computing 
environment, it's all too easy to forget that a lot of people (e.g. 
students using school computers, or people in corporate environments 
where the desktops are locked down to a standard operating environment) 
aren't able to install the IDE of their choice. It's relatively easy to 
get Python itself approved -- on many systems, Python comes pre-installed 
-- but trying to get approval to also install third-party software is 
difficult or impossible. It is for the sake of those people, people who 
prefer or require an IDE but don't have the choice to install third-party 
software, that Python ships with a minimal but usable IDE.



-- 
Steven
0
Steven
7/19/2014 7:28:40 AM
On Friday, July 18, 2014 8:21:36 PM UTC-5, Terry Reedy wrote:

> What ancient version, or oddball system are you using? For
> me, Win 7, both 2.7.8 and 3.4.1 "CONTROL+LEFT_ARROW" and
> the cursor is before the 'a' of [>>> abc]. The HOME key
> goes to the same place first, and they before >>> on the
> second press (and before 'a' on the third).

On versions 2.7.2 and 3.2.2 CONTROL+LEFT_ARROW is landing
*properly* in front of the prompt, so apparently that bug was
fixed since last i checked, my apologies for being ignorant
of the situation, but you should understand that i had given
up after years of no improvements.

However, a *bare* HOME_KEY press is placing the insertion
cursor *BEHIND* the prompt of the current line. In a shell
environment, you never want to be *BEHIND* the command
prompt.

Now, in the case of CONTROL+HOME (which places the insertion
cursor at the very *first* position of the entire text
buffer) and CONTROL+END (which places the insertion cursor
at the very *last* position of the text buffer), we should
leave the default behaviors alone. I don't see any benefit
of changing them.

> "IDLE shell shouldn't use TABs" is a high-priority for me.
> The problem is agreeing on an *exact* specification for
> new behavior, that takes into account both the limitations
> and flexibility of tk. Maybe I should start a thread here
> or python-ideas, where people are willing to discuss
> details.

First, i need to admit that i was wrong when i said: "eight
space indention", since the IDLE shell is using *tabs* for
indention, not spaces! However, a single tab is just as
annoying as 8 spaces

Now, even as much as i dislike tabs, i must admit there is a
benefit to using tabs over spaces, since tabs require only
*ONE* backspace key-press per "pseudo 4 spaces" as compared
to spaces which require a 1:1 ratio of key-presses. Of
course, even this problem can be abstracted away by
"backspace automation code", which the IDLE editor window
already employs!

But my point is: We *MUST* remove this *excessive*
indentation width from the IDLE shell!

> I cannot connect [your complaint about IDLE hanging] to
> behavior I have seen.

IDLE will hang when editing Tkinter code. It seems to happen
most often in two cases:

  1. When running code that results in a Tkinter error.
  
  This can happen when mixing the "grid" and "pack" geometry
  managers within the same "container" widget, which is a
  Tkinter NO-NO, but it can also happen during other Tkinter
  errors!
  
  2. During "quickly successive" back-to-back "run sessions"
  of Tkinter GUI apps.
  
  It seems that sometimes, if you don't give IDLE enough
  time to release resources from the *LAST* run session, it
  will freeze and then throw a "sub-process connection
  failure" message, which, sometimes you can remedy by just
  "trying again", but all to often you are forced to kill
  the entire IDLE (and related sub-) processes.
  
  THIS IS EXTREMELY ANNOYING!
        
However, *EVEN* in the instances where a problem is a direct
result of a "Tkinter NO-NO" (being witting or unwitting),
the user of IDLE should *NEVER* be forced to kill processes
because:

    THERE MUST BE A BETTER SOLUTION!   
    
And this bug is making the whole Python community look like
a bunch of amateurs!

> I believe there is a proposal to be able to clear the
> shell window. We just need to add "Clear and restart
> shell". There is also an idea to put help output in an
> output window. Undo-ing the result of hitting <enter>
> seems like a sensible extension of undoing the

> So sign the contributor agreement and volunteer to write
> and review patches.

I would be willing to help *IF* i received more thoughtful and
engaging replies like the type you always provide. Thank you
Terry for continuing to be a valuable and welcoming resource
for this community! If not for you and a handful of others,
i would have given up on this community a long time ago.

    NOBODY IS GOING TO HELP WHEN THEY GET RESISTANCE!

I will visit the bug tracker again and see if i can provide
some assistance there. Although, the last time i visited, i
remember being annoyed by the tracker interface -- which i
feel is overly noisy and far too complicated. All we need is
a flat list of issues. Is there some method to export
something more "readable"? Or, some sort of documentation?

I must admit, my excitement to help is usually depleted by
the tracker interface before i even have a chance to offer
anything substantial.

If this bug tracker does not improve, i will be forced to
continue posting my grievances here.

0
Rick
7/19/2014 4:29:08 PM
On Sun, Jul 20, 2014 at 2:29 AM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
> On versions 2.7.2 and 3.2.2 CONTROL+LEFT_ARROW is landing
> *properly* in front of the prompt, so apparently that bug was
> fixed since last i checked, my apologies for being ignorant
> of the situation, but you should understand that i had given
> up after years of no improvements.

Standard rule: Before complaining about something, upgrade to the
latest version - at least the latest bugfix version of that branch.
That would be 2.7.8 and either 3.2.5 or 3.4.1. Complaining about a bug
in an old release is quite pointless if that bug has already been
fixed.

> However, a *bare* HOME_KEY press is placing the insertion
> cursor *BEHIND* the prompt of the current line. In a shell
> environment, you never want to be *BEHIND* the command
> prompt.

I don't know about the old versions, but in 3.4, it seems to be set so
the Home key toggles between the beginning of the code and the
beginning of the line. Seems a useful feature, although I can
understand if you'd want to disable it and set the Home key to only
ever go to the beginning of code. But that's a configuration question;
this does not appear to be a bug.

> But my point is: We *MUST* remove this *excessive*
> indentation width from the IDLE shell!

Why *must*? Is it really that big a problem?

>     THERE MUST BE A BETTER SOLUTION!
>
> And this bug is making the whole Python community look like
> a bunch of amateurs!

Frankly, I doubt it. It's pretty obscure. Yes, all bugs should be
fixed where possible, but something of the nature you're describing
does NOT make Python look bad. (Side point: There's nothing bad about
being an amateur. I don't know why so many people think it's an
insulting term.)

ChrisA
0
Chris
7/19/2014 4:41:27 PM
On Sat, Jul 19, 2014 at 10:41 AM, Chris Angelico <rosuav@gmail.com> wrote:
>> However, a *bare* HOME_KEY press is placing the insertion
>> cursor *BEHIND* the prompt of the current line. In a shell
>> environment, you never want to be *BEHIND* the command
>> prompt.
>
> I don't know about the old versions, but in 3.4, it seems to be set so
> the Home key toggles between the beginning of the code and the
> beginning of the line. Seems a useful feature, although I can
> understand if you'd want to disable it and set the Home key to only
> ever go to the beginning of code. But that's a configuration question;
> this does not appear to be a bug.

I'd say that moving the cursor to a position where you can't type is a
bug. In that case, "beginning of the line" should be understood to be
after the prompt.

I see the use for it in an editing environment (I have an Emacs macro
that does the same thing), but I don't really see the point of having
the same feature in the shell other than for harmless consistency.
0
Ian
7/19/2014 6:00:29 PM
On 7/19/2014 12:28 AM, Steven D'Aprano wrote:
> Earlier, I mentioned a considerable number of IDEs which are available
> for Python, including:

I prefer to use Notepad++ (Windows) and TextWrangler (Mac). Text editors 
with code highlighting can get the job done as well, especially if the 
project is modest and doesn't require version control.

Chris Reimer
0
C
7/19/2014 6:08:10 PM
On 7/19/2014 3:28 AM, Steven D'Aprano wrote:

> So why does Python ship with IDLE?

On Windows the Idle shell is needed for sensible interactive use. For 
simply editing a Python file, running it, and fixing it, the Idle editor 
seems *about* as good as anything.

> It's not because Python requires an
> IDE, or that newbies need one, or that there aren't alternatives. The
> biggest reason for Python shipping with an IDE is not that people are
> unable to install alternatives, but that a lot of people are *prohibited*
> from doing so.

This is true, but I think it understates the case.

-- 
Terry Jan Reedy

0
Terry
7/19/2014 6:31:10 PM
[A missed point from my last reply...]

Terry Reedy said:
> I believe there is a proposal to be able to clear the
> shell window. We just need to add "Clear and restart
> shell".

A command that allows clearing the *entire* shell display
and also resets the global and local symbol tables,
*WITHOUT* requiring a re- start of the entire IDLE
application, would be a great addition!

However, sometimes you just want to remove the displayed
result of the *LAST* command executed --for instance, in
the case of accidentally printing a *very large* data
structure-- and i believe this "output undo action" should
be clearly *DISTINCT* from your normal "edit undo" actions
via: "CONTROL+Z"

To solve this dilemma in *MY* command shell, i use the
"ALT+UP_ARROW" to delete everything from the "last command
prompt" to the "end of the text buffer". I think IDLE needs
both functionality!

> There is also an idea to put help output in an
> output window.

I believe more windows just creates more confusion for the
user. Sometimes you have no choice but add additional
"views", however, in this case at least, i believe a menu
command (coupled with a keyboard event) is the only
solution that can keep the interface "manageable".
0
Rick
7/19/2014 8:39:17 PM
On 7/19/2014 12:29 PM, Rick Johnson wrote:
> On Friday, July 18, 2014 8:21:36 PM UTC-5, Terry Reedy wrote:
>
>> What ancient version, or oddball system are you using? For
>> me, Win 7, both 2.7.8 and 3.4.1 "CONTROL+LEFT_ARROW" and
>> the cursor is before the 'a' of [>>> abc]. The HOME key
>> goes to the same place first, and they before >>> on the
>> second press (and before 'a' on the third).
>
> On versions 2.7.2 and 3.2.2

These are ancient versions from years ago that no one should be running 
Idle on now.  Before you say another word about Idle, and I mean this 
literally, update to current versions.  There have been about 80 issues 
fixed since 2.7.2 and well more than 100 patches pushed.

> CONTROL+LEFT_ARROW is landing *properly* in front of the prompt,

Re-read my comment that you quoted. This has been fixed.

> But my point is: We *MUST* remove this *excessive*
> indentation width from the IDLE shell!

To repeat: I agree, Raymond Hettigner agrees, everyone seems to agree, 
and we all have for years. http://bugs.python.org/issue7676 is over 4 
years old.  But a patch can only implement a specific new behavior, not 
just 'stop the old'.

>> I cannot connect [your complaint about IDLE hanging] to
>> behavior I have seen.
>
> IDLE will hang when editing Tkinter code. It seems to happen
> most often in two cases:

If you are running your tkinter code in the same process with Idle's 
tkinter code, either with ancient Idle or the '-n' startup option 
(possibly buried in a script), the situation is hopeless.

If you are running your code in a separate process (now the default), 
then, most likely, Idle is not hanging. It is just waiting for your hung 
process. If so, Shell / Restart shell (^F6) will end the user process 
and start a new one.

>    1. When running code that results in a Tkinter error.
 >
>    This can happen when mixing the "grid" and "pack" geometry
>    managers within the same "container" widget, which is a
>    Tkinter NO-NO, but it can also happen during other Tkinter
>    errors!

The user process might hang trying to display a message from *tk*, as 
oppose to Python code, including tkinter. If you start Idle in a console 
window with 'python -m idlelib' or in the console interpreter with 
'import idlelib.idle', you might see messages from tk, as I sometimes do 
(especially with a repository debug build).

>    2. During "quickly successive" back-to-back "run sessions"
>    of Tkinter GUI apps.
>
>    It seems that sometimes, if you don't give IDLE enough
>    time to release resources from the *LAST* run session, it
>    will freeze and then throw a "sub-process connection
>    failure" message, which, sometimes you can remedy by just
>    "trying again", but all to often you are forced to kill
>    the entire IDLE (and related sub-) processes.

Use one of the startup options directly above to see if you can get more 
information.  A repeatable or at least semi-repeatable failure case is 
needed to do anything.

> However, *EVEN* in the instances where a problem is a direct
> result of a "Tkinter NO-NO" (being witting or unwitting),
> the user of IDLE should *NEVER* be forced to kill processes

If you are talking about user processes, and we are talking about 
patching Idle, as opposed to Python or the OS (such as Windows), I 
disagree. If you are talking about the Idle process, then yes, I would 
prefer that once Idle starts, it run forever, and recover from any 
problems caused by users. Roger Serwy fixed many Idle shutdowns before 
being swallowed by a PhD program a year ago, but there is more to do.

>> I believe there is a proposal to be able to clear the
>> shell window. We just need to add "Clear and restart
>> shell". There is also an idea to put help output in an
>> output window. Undo-ing the result of hitting <enter>
>> seems like a sensible extension of undoing the
>
>> So sign the contributor agreement and volunteer to write
>> and review patches.

In particular, go to
https://www.python.org/psf/contrib
to read *about* the contributor agreement and then go to 
https://www.python.org/psf/contrib-form/
(when the page is working -- it is not at the moment) with Javascript 
turned on to submit on-line (or submit by old-fashioned s-mail). When 
the form is processed, the Contributor Form Received field of your user 
profile at http://bugs.python.org/user12501 will be updated.
Also, please update the email on that page to your current one.

We are much stricter about getting Contributor Agreements than we used 
to be. I will usually not look as non-trivial patches until the author 
has at least signed the agreement and will not commit until it is recorded.

> I would be willing to help *IF* i received more thoughtful and
> engaging replies like the type you always provide.

On the tracker at least, be polite and ignore impolite posts. I get them 
occasionally.

>      NOBODY IS GOING TO HELP WHEN THEY GET RESISTANCE!

PEP 434 negated some forms of Idle resistance.  However, it did not stop 
resistance in the form of criticism based on how Idle was (or might have 
been) years ago.

> I will visit the bug tracker again and see if i can provide
> some assistance there. Although, the last time i visited, i
> remember being annoyed by the tracker interface -- which i
> feel is overly noisy and far too complicated.

The tracker could stand improvement, and there is a meta-tracker for 
that, though not many devs work on it. There is an infrastructure 
committee working on overhauling the entire workflow process, not just 
the tracker. In the meanwhile, the tracker serves to keep track of issue 
and patches well enough to get some work done.

> All we need is
> a flat list of issues. Is there some method to export
> something more "readable"?

If you do a search, such as for open issues with component 'Idle', the 
results page has a button to download *all* the results, not just those 
displayed, as a .csv file.  Do whatever you want with that.

 > Or, some sort of documentation?

The Tracker Documentation link at the bottom of the left margin now goes 
to https://docs.python.org/devguide/triaging.html. Most of the page is 
only relevant when opening an issue or editing the headers. The last 
section is relevant for posting messages. How to upload a patch (the 
Browse button) is not described.

> I must admit, my excitement to help is usually depleted by
> the tracker interface before i even have a chance to offer
> anything substantial.

Buck up ;-)

> If this bug tracker does not improve, i will be forced to
> continue posting my grievances here.

As long as you base them on current Idle and are specific, that's fine. 
Patches you must upload yourself, for the responsibility trail.

-- 
Terry Jan Reedy

0
Terry
7/19/2014 8:45:07 PM
--001a113363a85ad20904fe92dbfb
Content-Type: text/plain; charset=UTF-8

On 20 July 2014 04:08, C.D. Reimer <chris@cdreimer.com> wrote:

> On 7/19/2014 12:28 AM, Steven D'Aprano wrote:
>
>> Earlier, I mentioned a considerable number of IDEs which are available
>> for Python, including:
>>
>
> I prefer to use Notepad++ (Windows) and TextWrangler (Mac). Text editors
> with code highlighting can get the job done as well, especially if the
> project is modest and doesn't require version control.
>

IMO there is no project so modest that it doesn't require version control.
Especially since version control is as simple as:

cd project
hg init
hg add
hg commit

FWIW I also don't find a need for an IDE for Python - I'm quite happy using
EditPlus (which I preferred enough to other alternatives on Windows to pay
for many years ago).

Tim Delaney

--001a113363a85ad20904fe92dbfb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 2=
0 July 2014 04:08, C.D. Reimer <span dir=3D"ltr">&lt;<a href=3D"mailto:chri=
s@cdreimer.com" target=3D"_blank">chris@cdreimer.com</a>&gt;</span> wrote:<=
br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex">
<div class=3D"">On 7/19/2014 12:28 AM, Steven D&#39;Aprano wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Earlier, I mentioned a considerable number of IDEs which are available<br>
for Python, including:<br>
</blockquote>
<br></div>
I prefer to use Notepad++ (Windows) and TextWrangler (Mac). Text editors wi=
th code highlighting can get the job done as well, especially if the projec=
t is modest and doesn&#39;t require version control.<br></blockquote><div>
<br></div><div>IMO there is no project so modest that it doesn&#39;t requir=
e version control. Especially since version control is as simple as:</div><=
div><br></div><div>cd project</div><div>hg init</div><div>hg add</div><div>
hg commit</div><div><br></div><div>FWIW I also don&#39;t find a need for an=
 IDE for Python - I&#39;m quite happy using EditPlus (which I preferred eno=
ugh to other alternatives on Windows to pay for many years ago).</div><div>
<br></div><div>Tim Delaney=C2=A0</div></div></div></div>

--001a113363a85ad20904fe92dbfb--
0
Tim
7/19/2014 9:50:05 PM
[A missed point from my last reply...]

Terry Reedy said:
> I believe there is a proposal to be able to clear the
> shell window. We just need to add "Clear and restart
> shell".

A command that allows a user to clear the *ENTIRE* "shell
IO" and *ALSO* resets the global and local symbol tables
*WITHOUT* requiring a re-start of the IDLE application,
would be a great addition indeed!

Currently "IDLE shell" has *ONLY* the "Restart Shell"
command, which simply resets the symbol table whilst leaving
all previous "shell IO" untouched. Which is useful in some
situations, but not all...

    CONSIDER,

Sometimes you just want to remove the displayed result of
the *LAST* command executed *WHILST* maintaining any
previous displayed "shell IO" -- for instance, in the case
of accidentally printing a *very large* data structure, or a
horrendously untrimmed "dir()" requests.

    ############################################################
    #        DISAMBIGUATION: "EditUndo" vs "OutputUndo"        #
    ############################################################
    # In order to prevent confusion with the typical "edit-    #
    # undo" of "CONTROL+Z", we should refer to the action of   #
    # "remove the last output displayed" as an "output-undo".  #
    ############################################################

To solve this dilemma in *MY* command shell, i use the
"ALT+UP_ARROW" to delete everything from the "last command
prompt" up to "the end of the text buffer", in effect,
creating an "output-undo" command without *DEFILING* the
standard semantics of ubiquitous "CONTROL+Z".

I think IDLE needs all three functionality of:

  1. Reset symbol tables *WHILST* retaining previous "shell
  IO" (Already exists via "Shell->Restart Shell")

  2. Reset symbol tables *AND* clear all "shell IO" (Maybe:
  "Shell->Reset Shell")

  3. Remove the displayed result of the *LAST* command
  processed. (Maybe: "Shell->Remove Last Output")

Hotkeys for all three are a must and should be configurable
by the user.

> There is also an idea to put help output in an
> output window.

I believe more windows just creates more confusion for the
user. Sometimes you have no choice but to add additional
"views" to a GUI interface, however, in this case at least,
i believe a menu command (coupled with a keyboard event) is
a best solution to maintain the highest level of "interface
manageability" -- IMHO.

0
Rick
7/19/2014 10:50:19 PM
On Sun, Jul 20, 2014 at 4:00 AM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> On Sat, Jul 19, 2014 at 10:41 AM, Chris Angelico <rosuav@gmail.com> wrote:
>>> However, a *bare* HOME_KEY press is placing the insertion
>>> cursor *BEHIND* the prompt of the current line. In a shell
>>> environment, you never want to be *BEHIND* the command
>>> prompt.
>>
>> I don't know about the old versions, but in 3.4, it seems to be set so
>> the Home key toggles between the beginning of the code and the
>> beginning of the line. Seems a useful feature, although I can
>> understand if you'd want to disable it and set the Home key to only
>> ever go to the beginning of code. But that's a configuration question;
>> this does not appear to be a bug.
>
> I'd say that moving the cursor to a position where you can't type is a
> bug. In that case, "beginning of the line" should be understood to be
> after the prompt.

You can copy and paste from there. It's functionally equivalent to
being able to press Up arrow and move above the currently-editable
line. But even if it weren't for that, my statement would still be
correct: It's not a bug, and therefore not embarrassment, because it's
a feature that you may or may not like.

ChrisA
0
Chris
7/19/2014 11:10:49 PM
On Sun, Jul 20, 2014 at 6:39 AM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
> To solve this dilemma in *MY* command shell, i use the
> "ALT+UP_ARROW" to delete everything from the "last command
> prompt" to the "end of the text buffer". I think IDLE needs
> both functionality!

Okay, now I understand Rick's attitude. So long as Idle has one single
bug of which he is aware, or lacks one single feature which he can
think of, it is an utter and total embarrassment to the entire Python
community - not just those who work to make Idle what it is, but also
everyone who uses Idle... and everyone who doesn't use Idle, too.

Rick, start writing patches, and stop moaning like this just because
someone hasn't thought of something you've thought of. It may or may
not even be worth implementing this, but definitely you have the wrong
attitude toward feature requests.

ChrisA
0
Chris
7/19/2014 11:13:57 PM
On Sun, Jul 20, 2014 at 7:50 AM, Tim Delaney
<timothy.c.delaney@gmail.com> wrote:
> IMO there is no project so modest that it doesn't require version control.
> Especially since version control is as simple as:
>
> cd project
> hg init
> hg add
> hg commit

That said, though, there are some projects so modest they don't
require dedicated repositories. I have a repo called "shed" - it's a
collection of random tools that I've put together, no more logical
grouping exists. Generally each one is a single file, although I have
a couple of related ones in there. (Code at
https://github.com/Rosuav/shed if anyone's curious.) If I have an idea
for a program that doesn't really merit a full repo, I'll just save it
into shed. Keeps the "where did I put that, what did I call that" to a
minimum :)

ChrisA
0
Chris
7/19/2014 11:19:34 PM
On 7/19/2014 6:50 PM, Rick Johnson wrote:
>
> [A missed point from my last reply...]
>
> Terry Reedy said:
>> I believe there is a proposal to be able to clear the
>> shell window. We just need to add "Clear and restart
>> shell".

>      # In order to prevent confusion with the typical "edit-    #
>      # undo" of "CONTROL+Z", we should refer to the action of   #
>      # "remove the last output displayed" as an "output-undo".  #

That would make implementation easier.

> I think IDLE needs all three functionality of:
>
>    1. Reset symbol tables *WHILST* retaining previous "shell
>    IO" (Already exists via "Shell->Restart Shell")
>
>    2. Reset symbol tables *AND* clear all "shell IO" (Maybe:
>    "Shell->Reset Shell")
>
>    3. Remove the displayed result of the *LAST* command
>    processed. (Maybe: "Shell->Remove Last Output")
>
> Hotkeys for all three are a must

I consider them a nicety. We will eventually run out of simple hot keys.

> and should be configurable by the user.

I believe anything Idle controls is.

>> There is also an idea to put help output in an
>> output window.

In the new issue, I said 'move the last output' from the shell to a 
window, so it would be entirely optional.

> I believe more windows just creates more confusion for the
> user.

I expect to eventually look at G.Polo's patch for using tabbed 
notebooks, which will help with this.

-- 
Terry Jan Reedy

0
Terry
7/19/2014 11:23:43 PM
--089e012949b678520c04fe954063
Content-Type: text/plain; charset=UTF-8

On 20 July 2014 09:19, Chris Angelico <rosuav@gmail.com> wrote:

> On Sun, Jul 20, 2014 at 7:50 AM, Tim Delaney
> <timothy.c.delaney@gmail.com> wrote:
> > IMO there is no project so modest that it doesn't require version
> control.
> > Especially since version control is as simple as:
> >
> > cd project
> > hg init
> > hg add
> > hg commit
>
> That said, though, there are some projects so modest they don't
> require dedicated repositories. I have a repo called "shed" - it's a
> collection of random tools that I've put together, no more logical
> grouping exists.


Agreed. I have a "utils" one - but I do like "shed" and think I'm going to
rename :)

The main thing is that versioning should be automatic now - it's almost
free, and the benefits are huge because even trivial scripts end up
evolving.

Tim Delaney

--089e012949b678520c04fe954063
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 2=
0 July 2014 09:19, Chris Angelico <span dir=3D"ltr">&lt;<a href=3D"mailto:r=
osuav@gmail.com" target=3D"_blank">rosuav@gmail.com</a>&gt;</span> wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex">
<div class=3D"">On Sun, Jul 20, 2014 at 7:50 AM, Tim Delaney<br>
&lt;<a href=3D"mailto:timothy.c.delaney@gmail.com">timothy.c.delaney@gmail.=
com</a>&gt; wrote:<br>
&gt; IMO there is no project so modest that it doesn&#39;t require version =
control.<br>
&gt; Especially since version control is as simple as:<br>
&gt;<br>
&gt; cd project<br>
&gt; hg init<br>
&gt; hg add<br>
&gt; hg commit<br>
<br>
</div>That said, though, there are some projects so modest they don&#39;t<b=
r>
require dedicated repositories. I have a repo called &quot;shed&quot; - it&=
#39;s a<br>
collection of random tools that I&#39;ve put together, no more logical<br>
grouping exists.</blockquote><div><br></div><div>Agreed. I have a &quot;uti=
ls&quot; one - but I do like &quot;shed&quot; and think I&#39;m going to re=
name :)</div><div><br></div><div>The main thing is that versioning should b=
e automatic now - it&#39;s almost free, and the benefits are huge because e=
ven trivial scripts end up evolving.</div>
<div><br></div><div>Tim Delaney=C2=A0</div></div></div></div>

--089e012949b678520c04fe954063--
0
Tim
7/20/2014 12:41:31 AM
On Sat, 19 Jul 2014 14:31:10 -0400, Terry Reedy wrote:

> On 7/19/2014 3:28 AM, Steven D'Aprano wrote:
> 
>> So why does Python ship with IDLE?
> 
> On Windows the Idle shell is needed for sensible interactive use.

One might say that *some* IDE is needed, but Idle itself isn't 
compulsory :-)

It also depends on what you consider sensible.

I haven't used Python on Windows much, but when I did use it, I found the 
standard Python interactive interpreter running under cmd.exe to be bare-
bones but usable for testing short snippets. If I recall correctly, it is 
missing any sort of command history or line editing other than backspace, 
which I guess it would have been painful to use for extensive interactive 
work, but when I started using Python on Linux the interactive 
interpreter had no readline support either so it was just like old 
times :-)


-- 
Steven
0
Steven
7/20/2014 1:01:01 AM
On 7/19/2014 5:41 PM, Tim Delaney wrote:
> The main thing is that versioning should be automatic now - it's 
> almost free, and the benefits are huge because even trivial scripts 
> end up evolving.

I keep my modest Python scripts in a Dropbox directory and run a weekly 
Python script to zip up the Dropbox directory for safekeeping on the 
home file server and Microsoft OneDrive. If I really need a recent copy 
of a script, Time Machine on the Mac should have a copy from the Drop 
Box folder.

The only time I use version control is when I have a big project with 
many moving parts and/or I'm publishing software for other people to use.

Chris Reimer
0
C
7/20/2014 1:24:12 AM
On Saturday, July 19, 2014 3:45:07 PM UTC-5, Terry Reedy wrote:
> On 7/19/2014 12:29 PM, Rick Johnson wrote:
> [2.7.2 and 3.2.2] are ancient versions from years ago that
> no one should be running Idle on now.

I have just downloaded and installed versions 2.7.8 and
3.4.1, and i am happy to report that both the "HOME_KEY"
*AND* the "CONTROL+LEFT_ARROW" events are working properly
and intuitively. I also would like to give my deepest
gratitude and thanks to those who corrected these
abnormalities!

    KEEP UP THE GOOD WORK GUYS!

> To repeat: I agree [that tab indention is bad], Raymond
> Hettigner agrees, everyone seems to agree, and we all have
> for years. http://bugs.python.org/issue7676 is over 4
> years old.  But a patch can only implement a specific new
> behavior, not just 'stop the old'.

Just checked 3.4.1, and it is still using a tab for
indention. I know this issue is going to be a bit more
trouble to solve than the previous two "event" issues that i
mentioned, however, i feel it is an important issue to
solve.

To understand *HOW* we might resolve this issue, *FIRST* we
must understand the origins of the issue -- and as such, a
few basic "rules" of how the IDLE shell "interacts" with a
user is prerequisite.

  1. The shell presents a prompt (in the case of the IDLE
  shell the prompt is ">>> "), as a "starting" point for
  interactive commands.

  2. The user begins typing his command at the prompt...

    2a. In the process of typing his command, each time the
    user presses the "ENTER" or "RETURN" keys (which i shall
    from now on refer to them *singularly* as the: "ER-
    KEYS"), the shell "intuits" whether the user intended to
    complete his command "at-the-current-line" *OR* that the
    user intends to "continue-writing-more-code", on
    subsequent lines.

    Note: As you can see the actions taken by pressing the
    "ER-KEYS" depend on the context in which they where
    pressed! If the command is "believed" to be *COMPLETE*,
    then the action will be: "evaluate the users command now
    and display a result", however, if the command is
    "believed" to be *INCOMPLETE*, the action will be:
    "allow the user to continue entering his command".

    2b. If the "shell" believes that the user is finished
    writing his command, the shell will evaluate the
    *ENTIRETY* of the command (which could span one or more
    lines!) and then display the result of that evaluation
    *BENEATH* the command, however, if the shell "believes"
    that the user intends to "continue-writing-more-code",
    then the shell will allow the user to continue writing
    more code.

  STEP[N:]. There is much more to the interaction between
  "shells" and "users", however, these first two steps, and
  their subsequent "sub-steps", are all we need to concern
  ourselves with at this time, in order to solve *THIS*
  particular problem.

Now, between the "shell" and its "user" exists a contract,
and the preceding steps i outlined describe most of thast
contract, however, i realized that i can describe the full
contract more clearly by conflating the "shell" with "god"
and the "user" as some poor disciple. If we view the
contract through "the eyes of a *GODLIKE* shell" it might
read something like:

  And the "shell" so-eth declared:

  Ye shall be presented with a prompt, and from that prompt
  thou shalt humbly enter requests. When i find thouest
  requests pleasing, i shall reward thou with my vast
  knowledge by displaying to you the result utilizing an
  esthetically pleasing shade of blue, HOWEVER, shall i find
  thou request to be illogical or malformed, i shall punish
  thou with furious displays of my rebukes, utilizing the
  "fear color" of *BLOOD* red! And thou shalt know my name
  is the SHELL!

  Furthermore, ye shall not be allowed to edit previous
  request, no matter how blasphemous they may be! No, they
  shall live as a testimate to thouest ignorance, a *PUBLIC*
  testiment for all to see -- until which time thou decideth
  to terminate our contract.

Now that we understand the contract between "shells" and
"users" we can focus in on the problem. The problem
manifests itself when the user wants to write commands that
span *MORE* than one line. For instance, when i write the
first line of a "multi-line source code" like this:

    >>> for x in range(10):

And then i press the "enter key", the current IDLE shell is
going to insert a tab char (not good!), when it *SHOULD*
have inserted a "buffer prompt" of some kind, and then
calculated the correct "extrapolation-indentation" (by
adding four to the indent of line #1, which is four!) for
this new line of code.

    >>> for x in range(10):
    ...     do_something

Notice the "buffer prompt" of "... ", after which follows
the "extrapolation indent" of "    ", after which defines
the *BEGINNING* of my next command of "do_something"? Seems
simple enough huh? Oh but, my friend, *NOTHING* is simple in
this damn community is it!

============================================================
 Summary of the attempts to solve "INDENTION ISSUE" (at IDLE Bugs)
============================================================
The comments on how to solve this problem read like a book
titled: "devils advocate for dummies".

  IDEA_1: Hey, lets just use 8 space indention for the
  *FIRST* level of indentation, and 4 space indention for
  any *SUBSEQUENT* levels of indentation, that would not
  solve the copy-paste problem *DIRECTLY*, however, it would

  RESPONSE_1: Shhhhh! Are you nuts! Be quiet! We cannot
  allow such easy remedies, because if we did, we would not
  need a bug tracker! No sir, this software dev team takes
  the protestant approach to problems -- we will suffer and
  we will like it!!!


  IDEA_2: Hey, lets just insert a "buffer prompt" for every
  line that is *NOT* the *FIRST LINE* of the command, and
  then use 4 spaces for indention... problem solved!

  RESPONSE_2: Hardly! Can't do that because people cannot be
  denied their "adolescent accessorizing" via font choice.
  How can you expect people to use *ONLY* mono-spaced fonts,
  i mean, geez, that's fascism! Besides, web-dings is vital
  for the those of us who need to encrypt our code so
  "peeping toms" cannot steal our snippets -- you never know
  who might be watching!

      >_>

      <_<


  IDEA_3: Hey, let's remove the embedded prompt from the
  main shell window altogether and display it in a separate
  "thin" area to the left -- sort of like how line numbers
  are displayed in other IDEs. This would solve the copy
  paste issue *AND* the indention issue. Plus, we can take
  credit for Ricks idea from circa 2005, nobody listens to
  him anyway!

  RESPONSE_2: You fool! That would require *ACTUAL* skills
  that we *DON'T* have. Only rr knows how to "lock" the
  scrolling events of two Tkinter widgets, plus, he'd have
  to change the underlying design of the entire shell
  contract in such a *DRAMATIC* fashion that he'd be better
  off just starting from scratch -- the IDLE source is a
  discombobulated mess!

Does the IDLE bug-tracker exist to *SOLVE* problems or to
*PERPETUATE* them?

> If you are running your tkinter code in the same process
> with Idle's tkinter code, either with ancient Idle or the
> '-n' startup option (possibly buried in a script), the
> situation is hopeless. If you are running your code in a
> separate process (now the default), then, most likely,
> Idle is not hanging. It is just waiting for your hung
> process. If so, Shell / Restart shell (^F6) will end the
> user process and start a new one.

Now that i have the most current releases of both Python2
and Python3, i will use IDLE exclusively to determine if
this "hanging issue" has been resolved, and if it has, i
will go from IDLEs loudest dissenter, to it's most exuberant
supporter.

Granted, this "hanging" issue is not the *ONLY* remaining
issue, however, it is the *SOLE* issue that has motivated me
to stop using the software and write my own. I will only
change my position once i have not experienced this nuance
for a reasonable time... and only time will tell.

> Use one of the startup options directly above to see if
> you can get more information.  A repeatable or at least
> semi-repeatable failure case is needed to do anything.

Yes. The very next time i get a hang, i'm going to post a
test case for all to see, so we might figure this out.

> > However, *EVEN* in the instances where a problem is a
> > direct result of a "Tkinter NO-NO" (being witting or
> > unwitting), the user of IDLE should *NEVER* be forced to
> > kill processes
> If you are talking about user processes, and we are
> talking about patching Idle, as opposed to Python or the
> OS (such as Windows), I disagree. If you are talking about
> the Idle process, then yes, I would prefer that once Idle
> starts, it run forever, and recover from any problems
> caused by users. Roger Serwy fixed many Idle shutdowns
> before being swallowed by a PhD program a year ago, but
> there is more to do.

My point is, that, when i run a Python program using
"IDLE->Run->Run Program", i expect that IDLE is going to
execute my program, catch any errors, and then report them
to me. What i don't expect, is that IDLE is going to hang,
freeze, churn, or totally go bonkers.

If IDLE, which is written in Python, cannot understand when
a Python program has failed, and take necessary actions to
exit cleanly *OR* allow the user to *MANUALLY* exit cleanly
at *ANY* time, then it is useless as an IDE, and should be
"repackaged" and "sold" as a "texteditor(with aspirations of
being an IDE one day)".

    IF YOU CAN'T RUN WITH THE BIG DOGS, STAY ON THE PORCH!

PS: I do promise though to hold an optimistic view until
proven otherwise.


0
Rick
7/20/2014 1:31:27 AM
On Sun, Jul 20, 2014 at 11:23 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> If I recall correctly, it [Python under cmd.exe] is
> missing any sort of command history or line editing other than backspace,

Not quite, but it has some extreme oddities. I'd have to call them
features because I can't imagine them to be bugs, but they're very
surprising... like how you can recall something, but if you enter it
without any editing, your "current recall position" is retained. This
means you can re-enter a series of lines by recalling the first and
then pressing Down, Enter for each subsequent line (it's a feature!),
but it means that any usage where the lines are truly independent will
start getting very awkward.

In contrast, Idle recalls entire suites, rather than individual lines,
which (IMO) makes it superior to a readline-based interface.

ChrisA
0
Chris
7/20/2014 1:39:34 AM
On Sun, Jul 20, 2014 at 11:31 AM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
> Does the IDLE bug-tracker exist to *SOLVE* problems or to
> *PERPETUATE* them?

Definitely the latter. If it weren't for that tracker, bugs would just
quietly die on their own. The PSU has a roster for feeding the bugs,
changing their litter, and all other bug-related duties, and when
someone goes on holidays and forgets to schedule a replacement, heaps
of bugs just inexplicably die. (The PSU generally conceals this faux
pas under the name of a "release".)

ChrisA
0
Chris
7/20/2014 1:42:30 AM
On 7/19/2014 6:23 PM, Steven D'Aprano wrote:
> I haven't used Python on Windows much, but when I did use it, I found 
> the standard Python interactive interpreter running under cmd.exe to 
> be bare- bones but usable for testing short snippets. If I recall 
> correctly, it is missing any sort of command history or line editing 
> other than backspace, which I guess it would have been painful to use 
> for extensive interactive work, but when I started using Python on 
> Linux the interactive interpreter had no readline support either so it 
> was just like old times :-)

Windows PowerShell supports very basic Linux commands and has a command 
history. I'm always typing "ls" for a directory listing when I'm on a 
Windows machine. The regular command line would throw a DOS fit. 
PowerShell lets me get away with it.

http://en.wikipedia.org/wiki/Windows_PowerShell#Comparison_of_cmdlets_with_similar_commands

I prefer working on my vintage 2006 Black MacBook. Alas, the CPU fan is 
dying and MacBook shuts down after 15 minutes. I'm surprised at how well 
I was able to set up a equivalent programming environment on Windows.

Chris Reimer
0
C
7/20/2014 1:53:02 AM
--047d7bfcf8944e8a2904fe966674
Content-Type: text/plain; charset=ISO-8859-1

On Sat, Jul 19, 2014 at 12:28 AM, Steven D'Aprano <
steve+comp.lang.python@pearwood.info> wrote:

> For Python users, the IDEs from
> Wingware and Activestate are notable:
>
>     https://wingware.com/
>     http://komodoide.com/
>

I would say that since PyCharm (https://www.jetbrains.com/pycharm/) now has
a free Community Edition it is an even more notable IDE as the above two
programs cost $.

And as a Windows user, for version control I really like TortoiseHg (
http://tortoisehg.bitbucket.org/) for Mercurial. Likewise I tend to use
TortoiseSVN and TortoiseGit rather than the command line. PyCharm even has
support for those but I still like right-clicking on folders in Windows
Explorer and activating various hg commands from the popup menu. Especially
since not every program I write is written in Python :)

--047d7bfcf8944e8a2904fe966674
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
at, Jul 19, 2014 at 12:28 AM, Steven D&#39;Aprano <span dir=3D"ltr">&lt;<a =
href=3D"mailto:steve+comp.lang.python@pearwood.info" target=3D"_blank">stev=
e+comp.lang.python@pearwood.info</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div id=3D":1x0" class=3D=
"" style=3D"overflow:hidden">For Python users, the IDEs from<br>
Wingware and Activestate are notable:<br>
<br>
=A0 =A0 <a href=3D"https://wingware.com/" target=3D"_blank">https://wingwar=
e.com/</a><br>
=A0 =A0 <a href=3D"http://komodoide.com/" target=3D"_blank">http://komodoid=
e.com/</a></div></blockquote></div><br><div class=3D"gmail_default" style=
=3D"font-size:small">I would say that since PyCharm (<a class=3D"" href=3D"=
https://www.jetbrains.com/pycharm/" title=3D"Linkificator: https://www.jetb=
rains.com/pycharm/">https://www.jetbrains.com/pycharm/</a>) now has a free =
Community Edition it is an even more notable IDE as the above two programs =
cost $.<br>

<br></div><div class=3D"gmail_default" style=3D"font-size:small">And as a W=
indows user, for version control I really like TortoiseHg (<a class=3D"link=
ificator-ext" href=3D"http://tortoisehg.bitbucket.org" title=3D"Linkificato=
r: http://tortoisehg.bitbucket.org">http://tortoisehg.bitbucket.org</a>/) f=
or Mercurial. Likewise I tend to use TortoiseSVN and TortoiseGit rather tha=
n the command line. PyCharm even has support for those but I still like rig=
ht-clicking on folders in Windows Explorer and activating various hg comman=
ds from the popup menu. Especially since not every program I write is writt=
en in Python :)<br>

</div><br></div></div>

--047d7bfcf8944e8a2904fe966674--
0
TP
7/20/2014 2:03:01 AM
On 7/19/2014 7:03 PM, TP wrote:
> I would say that since PyCharm (https://www.jetbrains.com/pycharm/) 
> now has a free Community Edition it is an even more notable IDE as the 
> above two programs cost $.

PyCharm look really nice as an IDE. Thanks for the heads up.

Chris Reimer
0
C
7/20/2014 3:10:35 AM
--001a11c21eaee0c91904fe984995
Content-Type: text/plain; charset=UTF-8

On 20 July 2014 11:53, C.D. Reimer <chris@cdreimer.com> wrote:

>
> On 7/19/2014 6:23 PM, Steven D'Aprano wrote:
>
>> I haven't used Python on Windows much, but when I did use it, I found the
>> standard Python interactive interpreter running under cmd.exe to be bare-
>> bones but usable for testing short snippets. If I recall correctly, it is
>> missing any sort of command history or line editing other than backspace,
>> which I guess it would have been painful to use for extensive interactive
>> work, but when I started using Python on Linux the interactive interpreter
>> had no readline support either so it was just like old times :-)
>>
>
> Windows PowerShell supports very basic Linux commands and has a command
> history. I'm always typing "ls" for a directory listing when I'm on a
> Windows machine. The regular command line would throw a DOS fit. PowerShell
> lets me get away with it.
>
> http://en.wikipedia.org/wiki/Windows_PowerShell#Comparison_
> of_cmdlets_with_similar_commands
>
> I prefer working on my vintage 2006 Black MacBook. Alas, the CPU fan is
> dying and MacBook shuts down after 15 minutes. I'm surprised at how well I
> was able to set up a equivalent programming environment on Windows.


I advise anyone who works cross-platform to install MSYS on their Windows
boxes (for the simplest, most consistent behaviour ignore rxvt and just
launch bash -l - i directly). Or use cygwin if you prefer.

Tim Delaney

--001a11c21eaee0c91904fe984995
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 2=
0 July 2014 11:53, C.D. Reimer <span dir=3D"ltr">&lt;<a href=3D"mailto:chri=
s@cdreimer.com" target=3D"_blank">chris@cdreimer.com</a>&gt;</span> wrote:<=
br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex">
<div class=3D""><br>
On 7/19/2014 6:23 PM, Steven D&#39;Aprano wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
I haven&#39;t used Python on Windows much, but when I did use it, I found t=
he standard Python interactive interpreter running under cmd.exe to be bare=
- bones but usable for testing short snippets. If I recall correctly, it is=
 missing any sort of command history or line editing other than backspace, =
which I guess it would have been painful to use for extensive interactive w=
ork, but when I started using Python on Linux the interactive interpreter h=
ad no readline support either so it was just like old times :-)<br>

</blockquote>
<br></div>
Windows PowerShell supports very basic Linux commands and has a command his=
tory. I&#39;m always typing &quot;ls&quot; for a directory listing when I&#=
39;m on a Windows machine. The regular command line would throw a DOS fit. =
PowerShell lets me get away with it.<br>

<br>
<a href=3D"http://en.wikipedia.org/wiki/Windows_PowerShell#Comparison_of_cm=
dlets_with_similar_commands" target=3D"_blank">http://en.wikipedia.org/wiki=
/<u></u>Windows_PowerShell#Comparison_<u></u>of_cmdlets_with_similar_<u></u=
>commands</a><br>

<br>
I prefer working on my vintage 2006 Black MacBook. Alas, the CPU fan is dyi=
ng and MacBook shuts down after 15 minutes. I&#39;m surprised at how well I=
 was able to set up a equivalent programming environment on Windows.</block=
quote>
<div><br></div><div>I advise anyone who works cross-platform to install MSY=
S on their Windows boxes (for the simplest, most consistent behaviour ignor=
e rxvt and just launch bash -l - i directly). Or use cygwin if you prefer.<=
/div>
<div><br></div><div>Tim Delaney=C2=A0</div></div></div></div>

--001a11c21eaee0c91904fe984995--
0
Tim
7/20/2014 4:18:54 AM
On 20/07/2014 02:42, Chris Angelico wrote:
> On Sun, Jul 20, 2014 at 11:31 AM, Rick Johnson
> <rantingrickjohnson@gmail.com> wrote:
>> Does the IDLE bug-tracker exist to *SOLVE* problems or to
>> *PERPETUATE* them?
>
> Definitely the latter. If it weren't for that tracker, bugs would just
> quietly die on their own. The PSU has a roster for feeding the bugs,
> changing their litter, and all other bug-related duties, and when
> someone goes on holidays and forgets to schedule a replacement, heaps
> of bugs just inexplicably die. (The PSU generally conceals this faux
> pas under the name of a "release".)
>
> ChrisA
>

An alternative is that the PSU wait until some raving lunatic, 
sado-masochistic nutter who actually likes triaging comes only and bumps 
some of the sillier, lonely bugs, e.g a three year old failing test case 
on a buildbot.  Result, bug is closed as out of date.  Click on the 
stats link at bugs.python.org and observe the result of this crazy type 
of behaviour.

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

Mark Lawrence

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


0
Mark
7/20/2014 11:40:09 AM
On 7/19/2014 9:31 PM, Rick Johnson wrote:
> On Saturday, July 19, 2014 3:45:07 PM UTC-5, Terry Reedy wrote:

Idle's Shell currently uses a primary prompt ('>>> '), no secondary 
prompt*, and tabs for indents. This is a compromise between conflicting 
goals. It works but perhaps we can do better.

* The third paragraph below explains that Shell's prompt is a statement 
prompt rather than line prompt, so that a secondary line prompt would 
not be appropriate.

The problem with tabs is that tk displays them as a jump to the next 
'tab stop'. For fixed pitch fonts, the virtual tab stops are set at 8 
space intervals.  For proportional fonts, I suspect the spacing is 8 em 
quads, where an em quad is the height of the font, which is also about 
the width of the widest character. An em quad is much larger than the 
width of a space character, perhaps 4x larger and perhaps 1.5 times the 
average width.  Because of no secondary prompt, the first fixed-pitch 
indent looks like an indent of 4 spaces after a 'secondary prompt' of ' 
    ', while subsequent indents are really 8 spaces. The indents appear 
are uneven and the subsequent indents chew up screen width too quickly. 
  For proportional fonts, the problem is worst as the indents are about 
12 characters.

>> http://bugs.python.org/issue7676

> indention. I know this issue is going to be a bit more
> trouble to solve than the previous two "event" issues
>
> To understand *HOW* we might resolve this issue, *FIRST* we
> must understand the origins of the issue

The problem originates in differences between the console - interactive 
python interaction and Idle Shell - execution server interaction. 
Interactive python prints prompts to and reads lines from the console. 
Once the user submits a line by hitting return, it cannot be edited. 
(This is true on Widows. Could any linux and mac user confirm for their 
systems?)

The Idle Shell is much more active than at least the Windows console, 
and it is statement rather than line oriented. This is the important 
point. The Shell '>>> ' prompt is prompting for a complete statement, 
not a single line. This difference of meaning should be documented if it 
is not now.

Until a user indicates that a statement is completed, the user can edit 
*any* part of the statement, not just the last line. While Shell 
monitors keystrokes and modifies the text accordingly with color and 
indents, it does not send the statement to the execution server, which 
is running idle code in batch-mode python, until the statment is 
complete.  The execution server then exec()s the statement inside the 
Executive.run_code method and sends and response back.

Being able to enter, edit, and recall complete statements is an valuable 
Shell feature.

> The problem manifests itself when the user wants to write
 > commands that  span *MORE* than one line.

Right. Multiline statement issues go away when a statement is a single 
line. Now to the ideas on the tracker.

>    IDEA_1: Hey, lets just use 8 space indention for the

Or a tab for the first indent (this works if consistent)

>    *FIRST* level of indentation, and 4 space indention for
>    any *SUBSEQUENT* levels of indentation,

I am considering this as an option when the font is fixed pitch.

> that would not solve the copy-paste problem *DIRECTLY*,

The advantage of a single tab is that it is easy to turn it into 4 
spaces either in a custom copy or after pasting.

>    IDEA_2: Hey, lets just insert a "buffer prompt" for every
>    line that is *NOT* the *FIRST LINE* of the command, and
>    then use 4 spaces for indention... problem solved!
>
>    RESPONSE_2: Hardly! Can't do that because people cannot be
>    denied their "adolescent accessorizing" via font choice.

This idea, and your response, ignores the fact that Shell is *statement* 
oriented. Inserting a secondary prompts inside statement text would mean 
that they would have to first be protected from user editing and then 
deleted by Idle before the statement is sent to the Executive.

>    IDEA_3: Hey, let's remove the embedded prompt from the
>    main shell window altogether and display it in a separate
>    "thin" area to the left -- sort of like how line numbers
>    are displayed in other IDEs.   This would solve the copy paste
 >    issue *AND* the indention issue.

http://bugs.python.org/issue17535
GSOC Idle student Saimadhav Heblekar has worked on adding *optional* 
line numbers to Idle editor windows.  I plan to adapt the final patch to
the shell with, for instance '>>> ' and 'out:' labels.

As I said on the tracker, I think that output that is no longer dedented 
with respect to input will then need some more to distinguish it. For my 
copy of Idle, I have added blue and red background tint to standard and 
error output and I think that works well.

>    we can take credit for Ricks idea from circa 2005,

Ideas don't count until recorded on the tracker.

>    RESPONSE_2: You fool! That would require *ACTUAL* skills
>    that we *DON'T* have. Only rr knows how to "lock" the
>    scrolling events of two Tkinter widgets,

Saimadhav has locked together a thin canvas with the text for line 
numbers. It works in all my texts. I am just waiting for him to try it 
with a thin text instead.

If you know some secret you think he missed. please describe it here.

Idea 4 (which I already suggested on the tracker). Put statement input 
prompts and output separators on lines by themselves.  As with 3. above, 
use standard 4 space indents, as with

 >>>:
def f(x):
     if x:
         print('got it')
         return 'something'

 >>>:
f(3)
---
got it
 >>>:

Idle users other than Rick, any comments on the possible improvements?

-- 
Terry Jan Reedy


0
Terry
7/20/2014 9:52:36 PM
On Mon, Jul 21, 2014 at 7:52 AM, Terry Reedy <tjreedy@udel.edu> wrote:
> On 7/19/2014 9:31 PM, Rick Johnson wrote:
> The problem originates in differences between the console - interactive
> python interaction and Idle Shell - execution server interaction.
> Interactive python prints prompts to and reads lines from the console. Once
> the user submits a line by hitting return, it cannot be edited. (This is
> true on Widows. Could any linux and mac user confirm for their systems?)

If you mean that individual lines are separately edited, then yes,
that's the same on Linux.

> The Idle Shell is much more active than at least the Windows console, and it
> is statement rather than line oriented. This is the important point. The
> Shell '>>> ' prompt is prompting for a complete statement, not a single
> line. This difference of meaning should be documented if it is not now.

This is, in fact, Idle's greatest feature IMO. The ability to recall,
edit, and resubmit an entire function/class definition as a single
unit.

> The advantage of a single tab is that it is easy to turn it into 4 spaces
> either in a custom copy or after pasting.

If you're weighing up those two options specifically, I would tip the
balance toward a custom copy. If you paste into some other
application, it would be more consistent to work with four spaces for
every indentation level, rather than having every line begin with a
tab and then some spaces.

> This idea, and your response, ignores the fact that Shell is *statement*
> oriented. Inserting a secondary prompts inside statement text would mean
> that they would have to first be protected from user editing and then
> deleted by Idle before the statement is sent to the Executive.

The secondary prompts are actually quite annoying in copy/paste.
Anything that suppresses them is a distinct advantage IMO.

> As I said on the tracker, I think that output that is no longer dedented
> with respect to input will then need some more to distinguish it. For my
> copy of Idle, I have added blue and red background tint to standard and
> error output and I think that works well.

I'd have to have a look and see how that feels before I can judge
properly, but the notion of output not being indented by a prompt is
one that's found on... well, pretty much everything. Most command-line
interfaces work that way. Good MUD clients work hard to make sure that
the user's input is correctly indented by the prompt, even if the two
are quite separate in chronology; if you use input("........") and
print(), you'll end up with the same kind of interface. Explaining the
difference in color will be different, so it'll have to work extra
well to make up for that. Also, you can copy and paste into an email,
which will lose color. Count me dubious but reserving judgment.

>>    RESPONSE_2: You fool! That would require *ACTUAL* skills
>>    that we *DON'T* have. Only rr knows how to "lock" the
>>    scrolling events of two Tkinter widgets,
>
> Saimadhav has locked together a thin canvas with the text for line numbers.
> It works in all my texts. I am just waiting for him to try it with a thin
> text instead.
>
> If you know some secret you think he missed. please describe it here.

Huh, is combined scrolling really such an amazing thing? Only one
person in the whole world knows how to do it? So.... like this:

http://www.phdcomics.com/comics/archive.php?comicid=1723
http://catb.org/esr/writings/unix-koans/mcse.html

Considering that some GUI toolkits have that functionality as a core
feature (GTK scrolling is a bit more complex to support this exact
concept), I would be very much surprised if exactly one person knows
how to do it in Tk.

> Idea 4 (which I already suggested on the tracker). Put statement input
> prompts and output separators on lines by themselves.  As with 3. above, use
> standard 4 space indents, as with
>
>>>>:
> def f(x):
>     if x:
>         print('got it')
>         return 'something'
>
>>>>:
> f(3)
> ---
> got it
>>>>:
>
> Idle users other than Rick, any comments on the possible improvements?

I can't comment on how it interacts with the editor half of Idle, but
for the shell as a stand-alone app, and for copying and pasting into
other programs, this last idea is rather interesting. I'm broadly
happy with the current system (>>> def f(x):), and the prompt is a
little weird (">>>:"? but maybe "Python:" would be less weird; I don't
advise "Idle:" as it implies that something is idle that might be
busy), but this would make copy/paste that bit easier. It would tend
to de-emphasize the difference between input and output, though, which
may or may not be an issue. But definitely interesting.

ChrisA
0
Chris
7/21/2014 12:55:02 AM
On Sunday, July 20, 2014 4:52:36 PM UTC-5, Terry Reedy wrote:
> On 7/19/2014 9:31 PM, Rick Johnson wrote:
> > On Saturday, July 19, 2014 3:45:07 PM UTC-5, Terry Reedy wrote:

> * The third paragraph below explains that Shell's prompt
> is a statement prompt rather than line prompt, so that a
> secondary line prompt would not be appropriate.

Speaking strictly from the point of view of the *current*
IDLE implementation, yes.

> > To understand *HOW* we might resolve this issue, *FIRST* we
> > must understand the origins of the issue
> The problem originates in differences between the console
> - interactive python interaction and Idle Shell -
> execution server interaction

Actually, the "problem" you are describing is fundamentally
different from what i was talking about, but you *are* getting
closer to the *real* source of the design flaws that prevent
*easy* evolution of the IDLE software.

The *real* problem is that the "interactive events" of the
"editor window" and the "interactive events" of the "shell
window" are far too tightly integrated with one another. 

I myself appreciate the finger saving principles of "DRY",
however, sometimes, two distinct functionalities just 
cannot be implemented *IN A CLEAR MANNER* without repeating
*some* of the code.

We need to understand that IDLE is split into two distinct
"modes", if you will -- the "interactive shell" and the
"editor window". Attempting to use the same code to handle
keystrokes for the shell *AND* the editor is a stumbling
block to extending this mess. 

Instead, IDLE needs two distinct "pipelines" for which
events for each *SIDE* of this "split personality" can be
*written* and later, easily *COMPREHENDED* by the
maintenance programmer.

Our "real problem" is discombobulation, and until we wrangle
the beast of discombobulation, we will never improve this
software in a meaningful or clear manner. Instead, we will
only render the software exponentially less readable.

    YOU CANNOT IMPROVE ANY SOFTWARE UNTIL YOU CAN GROK IT'S SOURCE

> This idea, and your response, ignores the fact that Shell
> is *statement* oriented. Inserting a secondary prompts
> inside statement text would mean that they would have to
> first be protected from user editing and then deleted by
> Idle before the statement is sent to the Executive.

Yes and no. ;-) 

Hiding the "secondary prompts" from the "execution server"
is as simple as running the "command" through a "cleaner
function" *BEFORE* it gets evaluated.

As for the other issue of protecting the user from editing
the "secondary prompts", all you need to do is add a few
bits of extra logic to the backspace and clipboard events. But
you *could* even just let the user be responsible for his
own mistakes and allow documentation handle that issue.

But either way, both can be achieved without a complete re-
write *OR* fundamental architecture re-design.

> Saimadhav Heblekar has worked on adding *optional* line
> numbers to Idle editor windows.  I plan to adapt the final
> patch to the shell with, for instance '>>> ' and 'out:'
> labels. As I said on the tracker, I think that output that
> is no longer de-dented with respect to input will then need
> some more to distinguish it. For my copy of Idle, I have
> added blue and red background tint to standard and error
> output and I think that works well.

That sounds fine to me. There are many methods one can
utilize to differentiate input from output. And i like your
idea of input being black(with colorizer modification of
course), valid output as *ALL* blue, and error output as
*ALL* red.

> Ideas don't count until recorded on the tracker.

Hmm, okay.

> Saimadhav has locked together a thin canvas with the text
> for line numbers. It works in all my texts. I am just
> waiting for him to try it with a thin text instead. If you
> know some secret you think he missed. please describe it
> here.

How can i offer improvements if i don't know where to find
the code? And besides, if my comments here "don't count" i
will levy the punishment of Eric Theodore Cartman upon you:

    SCREW YOU GUYS, I'M GOING HOME!
0
Rick
7/21/2014 1:22:37 AM
On Mon, Jul 21, 2014 at 11:22 AM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
> How can i offer improvements if i don't know where to find
> the code?

Look in hg.python.org/cpython and see what you find. You never know,
it might even be there!

ChrisA
0
Chris
7/21/2014 1:32:14 AM
On 19/07/2014 21:45, Terry Reedy wrote:
>
> If you are talking about user processes, and we are talking about
> patching Idle, as opposed to Python or the OS (such as Windows), I
> disagree. If you are talking about the Idle process, then yes, I would
> prefer that once Idle starts, it run forever, and recover from any
> problems caused by users. Roger Serwy fixed many Idle shutdowns before
> being swallowed by a PhD program a year ago, but there is more to do.
>

Which has just reminded me of this http://idlex.sourceforge.net/ which 
is available from pypi, with the last update dated 2014-06-02.

I'll quote from the sourceforge page "IdleX is a collection of over 
twenty extensions and plugins that provide additional functionality to 
IDLE, a Python IDE provided in the standard library. It transforms IDLE 
into a more useful tool for academic research and development as well as 
exploratory programming.
IdleX runs with Python 2.6, 2.7, and 3.x."

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

Mark Lawrence

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


0
Mark
7/21/2014 1:54:29 AM
On 7/20/2014 8:55 PM, Chris Angelico wrote:

>> Idea 4 (which I already suggested on the tracker). Put statement input
>> prompts and output separators on lines by themselves.  As with 3. above, use
>> standard 4 space indents, as with
>>
>>>>> :
>> def f(x):
>>      if x:
>>          print('got it')
>>          return 'something'
>>
>>>>> :
>> f(3)
>> ---
>> got it
>>>>> :
>>
>> Idle users other than Rick, any comments on the possible improvements?

Note that single multiline statements can be directly copied for pasting 
by the normal method.

> I can't comment on how it interacts with the editor half of Idle, but
> for the shell as a stand-alone app, and for copying and pasting into
> other programs, this last idea is rather interesting. I'm broadly
> happy with the current system (>>> def f(x):), and the prompt is a
> little weird (">>>:"? but maybe "Python:" would be less weird; I don't
> advise "Idle:" as it implies that something is idle that might be
> busy), but this would make copy/paste that bit easier. It would tend
> to de-emphasize the difference between input and output, though, which
> may or may not be an issue. But definitely interesting.

The prompt and separator could be configurable.

A few users have noticed (and complained) that setting sys.ps1 and 
sys.ps2 *in the batch mode user process* has no effect. The Idle doc 
should better explain why this is and should be.  User code should not 
affect the operation of Idle. Idle is separately configured through dialogs.

-- 
Terry Jan Reedy

0
Terry
7/21/2014 3:28:21 AM
On Mon, Jul 21, 2014 at 1:28 PM, Terry Reedy <tjreedy@udel.edu> wrote:
> A few users have noticed (and complained) that setting sys.ps1 and sys.ps2
> *in the batch mode user process* has no effect. The Idle doc should better
> explain why this is and should be.  User code should not affect the
> operation of Idle. Idle is separately configured through dialogs.

As I understand it, setting them has *absolutely* no effect,
currently, right? There's no situation in which it would be useful to
set them? In that case, it might be useful to put some magic in there
(although I'm not sure it's possible; can't use @property at top level
in a module) that gives a notification - pointing users to the dialog.
No idea how you'd go about it, but telling someone when what s/he does
is useless can be helpful.

ChrisA
0
Chris
7/21/2014 3:34:01 AM
On 7/20/2014 9:22 PM, Rick Johnson wrote:
> On Sunday, July 20, 2014 4:52:36 PM UTC-5, Terry Reedy wrote:

> The *real* problem is that the "interactive events" of the
> "editor window" and the "interactive events" of the "shell
> window" are far too tightly integrated with one another.
>
> I myself appreciate the finger saving principles of "DRY",
> however, sometimes, two distinct functionalities just
> cannot be implemented *IN A CLEAR MANNER* without repeating
> *some* of the code.
>
> We need to understand that IDLE is split into two distinct
> "modes", if you will -- the "interactive shell" and the
> "editor window". Attempting to use the same code to handle
> keystrokes for the shell *AND* the editor is a stumbling
> block to extending this mess.

Slightly simplifying, the shell window and output windows are subclasses 
of the current editor window. I have thought about making all three 
inherit from a base interactive window. This would be a bit cleaner than 
the current design. I am not convinced of the need for more drastic change.

>> Ideas don't count until recorded on the tracker.

Which, as I reported back here, is why I promptly included both your 
OutputUndo idea and suggestion for a separate event and shortcut key in 
a new issue on the tracker.

> Hmm, okay.

>> Saimadhav has locked together a thin canvas with the text
>> for line numbers. It works in all my texts. I am just
>> waiting for him to try it with a thin text instead. If you
>> know some secret you think he missed. please describe it
>> here.
>
> How can i offer improvements if i don't know where to find
> the code?

http://bugs.python.org/issue17535

> And besides, if my comments here "don't count"

The ideas that I think are worth preserving and that I think are 
appropriate for the tracker I will put on the tracker. You can comment 
directly on the tracker yourself, but you would have to moderate your style.

-- 
Terry Jan Reedy

0
Terry
7/21/2014 3:49:37 AM
On 7/20/2014 11:34 PM, Chris Angelico wrote:
> On Mon, Jul 21, 2014 at 1:28 PM, Terry Reedy <tjreedy@udel.edu> wrote:
>> A few users have noticed (and complained) that setting sys.ps1 and sys.ps2
>> *in the batch mode user process* has no effect. The Idle doc should better
>> explain why this is and should be.  User code should not affect the
>> operation of Idle. Idle is separately configured through dialogs.
>
> As I understand it, setting them has *absolutely* no effect,
> currently, right?

As far as I know, setting sys.ps1 and sys.ps2 have no effect in any 
batch mode program.  This has nothing to do with Idle.

> There's no situation in which it would be useful to
> set them? In that case, it might be useful to put some magic in there
> (although I'm not sure it's possible; can't use @property at top level
> in a module) that gives a notification - pointing users to the dialog.

In general, Idle should execute user code the same way that the 
interpreter does, subject to the limitations of the different execution 
environment.

> No idea how you'd go about it, but telling someone when what s/he does
> is useless can be helpful.

What needs better documentation is what the execution environment is, 
and how the shell is different from a line-buffered console.

-- 
Terry Jan Reedy

0
Terry
7/21/2014 9:00:15 AM
On Mon, Jul 21, 2014 at 7:00 PM, Terry Reedy <tjreedy@udel.edu> wrote:
> In general, Idle should execute user code the same way that the interpreter
> does, subject to the limitations of the different execution environment.

Agreed, but I think the setting of prompts is a "different execution
environment" case. It's a fundamental difference between batch mode
and interactive, and Idle uses batch mode to implement interactive
mode. So something like:

>>> sys.ps1="Python> "
"Setting sys.ps1 has no effect in Idle; see the Options menu."
>>>

It might not be possible, but if it is, it wouldn't break any actual
viable use-cases.

ChrisA
0
Chris
7/21/2014 10:56:11 AM
On Sunday, July 20, 2014 9:53:02 AM UTC+8, C.D. Reimer wrote:
> On 7/19/2014 6:23 PM, Steven D'Aprano wrote:
> 
> > I haven't used Python on Windows much, but when I did use it, I found 
> 
> > the standard Python interactive interpreter running under cmd.exe to 
> 
> > be bare- bones but usable for testing short snippets. If I recall 
> 
> > correctly, it is missing any sort of command history or line editing 
> 
> > other than backspace, which I guess it would have been painful to use 
> 
> > for extensive interactive work, but when I started using Python on 
> 
> > Linux the interactive interpreter had no readline support either so it 
> 
> > was just like old times :-)
> 
> 
> 
> Windows PowerShell supports very basic Linux commands and has a command 
> 
> history. I'm always typing "ls" for a directory listing when I'm on a 
> 
> Windows machine. The regular command line would throw a DOS fit. 
> 
> PowerShell lets me get away with it.
> 
> 
> 
> http://en.wikipedia.org/wiki/Windows_PowerShell#Comparison_of_cmdlets_with_similar_commands
> 
> 
> 
> I prefer working on my vintage 2006 Black MacBook. Alas, the CPU fan is 
> 
> dying and MacBook shuts down after 15 minutes. I'm surprised at how well 
> 
> I was able to set up a equivalent programming environment on Windows.
> 
> 
> 
> Chris Reimer

Well, Python could be used as a 
scripting  language for routine jobs
in various Oses. 

But Python has been designed to be 
a cross-platform high-level general 
purpose programming  language from
the birth.

One can be sure that the investing in most of the programming concepts and skills  in Python 2.XX is still valid in Python 3.XX. 

Forget those non-investing imitators'  flase spamming claims.




0
CHIN
7/21/2014 3:37:40 PM
On 7/21/2014 6:56 AM, Chris Angelico wrote:
> On Mon, Jul 21, 2014 at 7:00 PM, Terry Reedy <tjreedy@udel.edu> wrote:
>> In general, Idle should execute user code the same way that the interpreter
>> does, subject to the limitations of the different execution environment.
>
> Agreed, but I think the setting of prompts is a "different execution
> environment" case. It's a fundamental difference between batch mode
> and interactive, and Idle uses batch mode to implement interactive
> mode. So something like:
>
>>>> sys.ps1="Python> "
> "Setting sys.ps1 has no effect in Idle; see the Options menu."
>>>>
>
> It might not be possible, but if it is, it wouldn't break any actual
> viable use-cases.

It would be a lot of work for close to 0 gain. It could not work 
consistent without special-casing sys assignments. Consider

 >>> prompt1 = 'Me>'
 >>> setps1 = sys.ps1
 >>> setps1(prompt1)

;-(.


Idle cannot exactly imitate the interactive interpreter (II) because it 
does not execute code in exactly the same way. For instance,
http://bugs.python.org/issue21997
reported that fact that the sequence

    >>>def dodebug():
	    pdb.set_trace()
    >>>dodebug()

behaves differently in Idle and II. Not knowing the details of Idle 
(currently only available in the code), the OP claimed that this is an 
Idle bug.  It turns out that running dodebug indirectly

 >>> def run_code(code): exec(code, globals())
 >>> run('dodebug()')

*in the II* behaves like Idle.  The above is essentially how Idle runs 
code.  (The difference is that it substitutes a custom namespace 
designed to look like the globals() of a main modules, include having 
__name__ == '__main__'.)

Well, at least I know now, so I know how to review claims that Idle is 
buggy when it acts a bit differently than the II.  The exec abstraction 
has a few tiny leaks if one looks hard enough, such as with the 
debugger.  Using inspect to look at the frame stack would also show a 
difference.

-- 
Terry Jan Reedy

0
Terry
7/21/2014 6:30:30 PM
On Tue, Jul 22, 2014 at 4:30 AM, Terry Reedy <tjreedy@udel.edu> wrote:
> It would be a lot of work for close to 0 gain. It could not work consistent
> without special-casing sys assignments.

The latter doesn't much matter (this is just a theory to help people
realize what they've done, not an actual preventative - it's like if
someone types "quit" and it comes back with a custom repr that tells
them about quit() or EOF), but the former is the important bit here.
Not a big deal, not worth a huge amount of effort.

At best, this is something to docket away as "here's another thing
that we could do if we had an equivalent for @property at
module-level", nothing more. (Because with that, it would be pretty
easy.)

ChrisA
0
Chris
7/21/2014 6:35:37 PM
Le lundi 21 juillet 2014 11:00:15 UTC+2, Terry Reedy a =E9crit=A0:
> On 7/20/2014 11:34 PM, Chris Angelico wrote:
>=20
> > On Mon, Jul 21, 2014 at 1:28 PM, Terry Reedy <tjreedy@udel.edu> wrote:
>=20
> >> A few users have noticed (and complained) that setting sys.ps1 and sys=
..ps2
>=20
> >> *in the batch mode user process* has no effect. The Idle doc should be=
tter
>=20
> >> explain why this is and should be.  User code should not affect the
>=20
> >> operation of Idle. Idle is separately configured through dialogs.
>=20
> >
>=20
> > As I understand it, setting them has *absolutely* no effect,
>=20
> > currently, right?
>=20
>=20
>=20
> As far as I know, setting sys.ps1 and sys.ps2 have no effect in any=20
>=20
> batch mode program.  This has nothing to do with Idle.
>=20
>=20
>=20
> > There's no situation in which it would be useful to
>=20
> > set them? In that case, it might be useful to put some magic in there
>=20
> > (although I'm not sure it's possible; can't use @property at top level
>=20
> > in a module) that gives a notification - pointing users to the dialog.
>=20
>=20
>=20
> In general, Idle should execute user code the same way that the=20
>=20
> interpreter does, subject to the limitations of the different execution=
=20
>=20
> environment.
>=20
>=20
>=20
> > No idea how you'd go about it, but telling someone when what s/he does
>=20
> > is useless can be helpful.
>=20
>=20
>=20
> What needs better documentation is what the execution environment is,=20
>=20
> and how the shell is different from a line-buffered console.
>=20
>=20
-----

Just the coding of characters is making a gui
application different from a console application.

A gui application is living with its own coding,
and not necessarly with the operating system coding.

That's why in my py3* interactive interpreters,
I have (I defined) very correctly things
like this:

>>> sys.stdout.encoding
'<unicode>'
>>> sys.stderr.encoding
'<unicode>'
>>> sys.stdin.encoding
'<unicode>'


The "sys coding" is not the operating system, it
is the "coding of the gui". In Py3, one does
not pass or populate a text widget with an
"encoded string", a string is passed directly as
a "unicode type", because the gui is built to
work like this. Something like an coding-less
string.


In the console ("dos-box"), the following is
correct:

>>> sys.stdout.encoding
'cp1252'

------

Generally, speaking, this is a perpetual annoyment
(to be polite) in Python. Python is always attempting
to find a solution for the "Python user", to enforce a
coding usage instead of letting the user/programmer
doing the task correctly.

I'm not alone to think like this and I have seen
many times people complaining about this.

jmf
0
wxjmfauth
7/21/2014 8:00:26 PM
On Wednesday, July 16, 2014 4:16:45 PM UTC+5:30, Marko Rauhamaa wrote:

> In unix and linux, there never was a separate text mode for files. When
> you open a file, you open a file -- and stuff bytes in it. There is no
> commonly accepted text file encoding. UTF-8 comes close to being a
> standard, but I know somebody who sticks to an ISO-8859-1 locale.

Here's the Solaris docs:

| The C locale, also known as the POSIX locale, is the POSIX system
| default locale for all POSIX-compliant systems. The Oracle Solaris
| operating system is a POSIX system. The Single UNIX Specification,
| Version 3, defines the C locale. You can register at
| http://www.unix.org/version3/online.html to read and download the
| specification.
|
| http://docs.oracle.com/cd/E23824_01/html/E26033/glmbx.html#glmar

Layman version:

ASCII - also known as the Unix locale - is the default for all *nix
compliant systems.

expanded further at 
http://blog.languager.org/2014/04/unicode-and-unix-assumption.html
0
Rustom
7/30/2014 9:31:52 PM
> Windows and OS X users, sadly, miss out on the power of an integrated 
> package manager.

Thankfully, all actually user-friendly operating systems (MacOS,
TOS, RiscOS, probably AmigaOS, MacOS X) spare(d) their users the
bottomless cesspit of "package management" and/or "installers".

Because on such operating systems, each and every application is an
entirely self-contained package that doesn't need any "packages" or
"installers" to use it.
 
Sincerely,

Wolfgang
0
Wolfgang
8/1/2014 11:10:35 AM
On Fri, Aug 1, 2014 at 9:10 PM, Wolfgang Keller <feliphil@gmx.net> wrote:
> Thankfully, all actually user-friendly operating systems (MacOS,
> TOS, RiscOS, probably AmigaOS, MacOS X) spare(d) their users the
> bottomless cesspit of "package management" and/or "installers".
>
> Because on such operating systems, each and every application is an
> entirely self-contained package that doesn't need any "packages" or
> "installers" to use it.

You mean everyone has to reinvent the proverbial wheel AND worry about
dependency collisions? Yeah, that's a heavenly thought.

ChrisA
0
Chris
8/1/2014 11:22:33 AM
Chris Angelico <rosuav@gmail.com>:

> On Fri, Aug 1, 2014 at 9:10 PM, Wolfgang Keller <feliphil@gmx.net> wrote:
>> Because on such operating systems, each and every application is an
>> entirely self-contained package that doesn't need any "packages" or
>> "installers" to use it.
>
> You mean everyone has to reinvent the proverbial wheel AND worry about
> dependency collisions? Yeah, that's a heavenly thought.

I'm guessing he's referring to the modern fad of application sandboxing.
Each application is installed with everything it needs on top of the
basic OS.

If you have ten Python apps, you'll have ten Python installations. Also
the applications have no way to communicate outside their respective
sandboxes. They can't access each others' files, for example.

Personally, I tend to stick to this package management strategy: install
whatever is available with yum and write the rest yourself.


Marko
0
Marko
8/1/2014 12:19:52 PM
On Fri, Aug 1, 2014 at 10:19 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
> I'm guessing he's referring to the modern fad of application sandboxing.
> Each application is installed with everything it needs on top of the
> basic OS.
>
> If you have ten Python apps, you'll have ten Python installations. Also
> the applications have no way to communicate outside their respective
> sandboxes. They can't access each others' files, for example.
>
> Personally, I tend to stick to this package management strategy: install
> whatever is available with yum and write the rest yourself.

Only if by "write" you also include compiling someone else's program
from source. I follow that strategy (except that I use apt rather than
yum), and there's a fair bit that I build from source but don't write.
Granted, that's partly because Debian Stable doesn't include a
sufficiently recent Python, for instance, but still, there's a lot to
be said for getting libraries (including dev versions) from the repo
and building some applications yourself.

ChrisA
0
Chris
8/1/2014 12:30:31 PM
Marko Rauhamaa wrote:

> Chris Angelico <rosuav@gmail.com>:
> 
>> On Fri, Aug 1, 2014 at 9:10 PM, Wolfgang Keller <feliphil@gmx.net> wrote:
>>> Because on such operating systems, each and every application is an
>>> entirely self-contained package that doesn't need any "packages" or
>>> "installers" to use it.
>>
>> You mean everyone has to reinvent the proverbial wheel AND worry about
>> dependency collisions? Yeah, that's a heavenly thought.
> 
> I'm guessing he's referring to the modern fad of application sandboxing.
> Each application is installed with everything it needs on top of the
> basic OS.
>
> If you have ten Python apps, you'll have ten Python installations. 

A horrible thought. Hard drives are cheap, but not that cheap that one can
trivially afford to turn every 1K Python script into a 25,000K install
(based on the size of the Windows binary-only installer). On my system, the
obvious application directories (I may have missed some) total 460MB:

[steve@ando ~]$ du -hc /bin/ /sbin/ /usr/bin/ /usr/local/bin/
7.9M    /bin/
38M     /sbin/
76K     /usr/bin/mergetools
380M    /usr/bin/
35M     /usr/local/bin/
460M    total

If those apps were an average of 10,000 times larger, that makes 4.6TB,
significantly larger than an entry level 1TB hard drive. It also makes
rescue DVDs and boot USB sticks impractical, to say nothing of the expense
of downloading upgrades. I can download (say) an entire Linux Mint system
in an hour or three, which is significantly better than the two years it
would take to download if everything was 10,000 times bigger.

But even more problematic... if there's a security vulnerability in Python,
would you rather wait for the vulnerability to patched once in a central
Python binary, or individually in each and every single Python script that
comes with a bundled Python binary?


> Also 
> the applications have no way to communicate outside their respective
> sandboxes. They can't access each others' files, for example.

If two applications can both write to the file system, they can communicate.
If they have sufficient file system privileges, they can even reach into
each other's bundle and modify anything they want.


> Personally, I tend to stick to this package management strategy: install
> whatever is available with yum and write the rest yourself.

+0.8 on that. Sometimes I install software outside of the package management
system, but I always feel a tad dirty when I do so :-)



-- 
Steven

0
Steven
8/1/2014 1:10:00 PM
On Fri, Aug 1, 2014 at 11:10 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> Marko Rauhamaa wrote:
>
>> I'm guessing he's referring to the modern fad of application sandboxing.
>> Each application is installed with everything it needs on top of the
>> basic OS.
>>
>> If you have ten Python apps, you'll have ten Python installations.
>
> A horrible thought. Hard drives are cheap, but not that cheap that one can
> trivially afford to turn every 1K Python script into a 25,000K install
> (based on the size of the Windows binary-only installer). On my system, the
> obvious application directories (I may have missed some) total 460MB:
>
> [steve@ando ~]$ du -hc /bin/ /sbin/ /usr/bin/ /usr/local/bin/
> 7.9M    /bin/
> 38M     /sbin/
> 76K     /usr/bin/mergetools
> 380M    /usr/bin/
> 35M     /usr/local/bin/
> 460M    total
>
> If those apps were an average of 10,000 times larger, that makes 4.6TB,
> significantly larger than an entry level 1TB hard drive. It also makes
> rescue DVDs and boot USB sticks impractical, to say nothing of the expense
> of downloading upgrades. I can download (say) an entire Linux Mint system
> in an hour or three, which is significantly better than the two years it
> would take to download if everything was 10,000 times bigger.

There is a solution. If all those binaries are marked as read-only,
you could have a file system that stores things based on their hashes,
effectively hardlinking (automatically) all the duplicates. Of course,
that only works if they really are duplicates. If one ships Python
2.7.3 and another ships 2.7.4, there'll be a lot of almost-duplicated
files that technically identical.

> But even more problematic... if there's a security vulnerability in Python,
> would you rather wait for the vulnerability to patched once in a central
> Python binary, or individually in each and every single Python script that
> comes with a bundled Python binary?

This is exactly the problem that sandboxing "fixes", though. As soon
as you upgrade the central Python binary, you risk breaking that
application that depended on the exact version that it shipped with.

Encouraging laziness and sloppy versioning, IMO.

>> Also
>> the applications have no way to communicate outside their respective
>> sandboxes. They can't access each others' files, for example.
>
> If two applications can both write to the file system, they can communicate.
> If they have sufficient file system privileges, they can even reach into
> each other's bundle and modify anything they want.

If you chroot to the sandbox, they shouldn't be able to. (Not to say
there's no such thing as chroot leakage, of course, but they
shouldn't.)

>> Personally, I tend to stick to this package management strategy: install
>> whatever is available with yum and write the rest yourself.
>
> +0.8 on that. Sometimes I install software outside of the package management
> system, but I always feel a tad dirty when I do so :-)

I don't. There's plenty that I've done that way - but only ever
applications, or libraries that completely don't exist in the repos.
I've never installed a newer version of a library than I can get from
repo.

ChrisA
0
Chris
8/1/2014 1:30:03 PM
On Fri, Aug 1, 2014 at 12:22 PM, Chris Angelico <rosuav@gmail.com> wrote:
> On Fri, Aug 1, 2014 at 9:10 PM, Wolfgang Keller <feliphil@gmx.net> wrote:
>> Thankfully, all actually user-friendly operating systems (MacOS,
>> TOS, RiscOS, probably AmigaOS, MacOS X) spare(d) their users the
>> bottomless cesspit of "package management" and/or "installers".
>>
>> Because on such operating systems, each and every application is an
>> entirely self-contained package that doesn't need any "packages" or
>> "installers" to use it.
>
> You mean everyone has to reinvent the proverbial wheel AND worry about
> dependency collisions? Yeah, that's a heavenly thought.

Actually, that's not right.  RiscOS had and OS X has (I'm sure the
others do as well) a concept that is similar to a shared library.  But
the joy of an application bundle is that installing an application
does not scatter its own files all over the file-system, putting
configuration files here, binary resources there, library files
somewhere else, executable files somewhere else again.  The result on
one of these other systems is that uninstalling an application is a
simple matter of deleting the relevant bundle, which contains all of
the resources necessary for that application.  All that remains are
whatever files exist within user directories.

I've worked with both.  Quite honestly, I really wish that other
operating systems had gone down this route. MS didn't possibly to make
it harder to steal software, and Unix...well, *nix has the concept of
the "distribution" that will manage all of this for you.  We all know
the problems that this causes.

N.
0
Nicholas
8/1/2014 2:28:56 PM
On Sat, Aug 2, 2014 at 12:28 AM, Nicholas Cole <nicholas.cole@gmail.com> wrote:
> Actually, that's not right.  RiscOS had and OS X has (I'm sure the
> others do as well) a concept that is similar to a shared library.  But
> the joy of an application bundle is that installing an application
> does not scatter its own files all over the file-system, putting
> configuration files here, binary resources there, library files
> somewhere else, executable files somewhere else again.

Shared libraries are a code execution model. The question is, how do
you locate them? Let's suppose I write a program that requires the
Nettle cryptography library. I can't depend on you already having that
on your system; you might, but I can't depend on it. What do I do? Do
I include it in my application bundle, or do I have some small record
that says "and by the way, I need libnettle"? Including it in the
application bundle means there'll be duplicates everywhere, possibly
of slightly different versions. Not including it means there needs to
be some kind of system for resolving dependencies, which is exactly
what apt-get, yum, pacman, and so on are for.

The installer has basically three choices.
1) Install libnettle inside the application directory
2) Install libnettle to some system library directory
3) Don't install libnettle, and demand that someone else (perhaps the
user, or the system package manager) install it.

Option 1 results in duplications. (Unless one application is allowed
to access a library in another application's directory, which is a
HORRIBLE mess.) Option 2 is exactly what you're complaining about,
scattering files all over the FS. And option 3 is what package
managers are for. What are you advocating?

ChrisA
0
Chris
8/1/2014 2:39:01 PM
Steven D'Aprano <steve+comp.lang.python@pearwood.info>:

> Marko Rauhamaa wrote:
>> If you have ten Python apps, you'll have ten Python installations. 
>
> A horrible thought. Hard drives are cheap, but not that cheap

Well, iPhones aren't *that* expensive...

>> Also the applications have no way to communicate outside their
>> respective sandboxes. They can't access each others' files, for
>> example.
>
> If two applications can both write to the file system,

They can't. They are sandboxed.

My WP8 phone has Python3 installed. Absolutely useless since it can't
get out of its sandbox (except for Microsoft's cloud drive, I think).


Marko
0
Marko
8/1/2014 3:13:57 PM
Am 01.08.2014 13:10, schrieb Wolfgang Keller:
> Because on such operating systems, each and every application is an
> entirely self-contained package that doesn't need any "packages" or
> "installers" to use it.
For people who have never used such a system it's probably difficult to see
the  advantages.

Besides the easy installation, backup and replication of software the 
RISC OS
way also had the advantage that you were able to organize your
applications in folders just like other folders and files.
There was no need for separate File and Program managers.
MS never got this right. Instead, they tried to fix things later with the
start menu and finally the box to type the software name to start it ...

One effect was that under DOS/Windows people usually saved their
documents in folders per application whereas under RISC OS they
were usually grouped by content/project.


When it came to usability, RISC OS had many advantages over the
other systems, e.g.
  - real drag'n'drop for loading *and* saving of files/selections
  - drag'n'drop also for transfer between applications
  - a standard vector graphics format that all applications supported
    (and for which an application was provided by default with the OS)
  - good font display (still better than e.g. MS Windows today)
  - three mouse buttons for select/menu/adjust
  - no menu bars
  - the icon bar for running applications, drives, shares and other 
resources
  - consistent, orthogonal & logical user interfaces instead of assistants
    and wizards for each and every task
  - complete programmers reference manual



Regards,

Dietmar

0
Dietmar
8/1/2014 5:16:43 PM
On 08/01/2014 08:39 AM, Chris Angelico wrote:
> The installer has basically three choices.
> 1) Install libnettle inside the application directory
> 2) Install libnettle to some system library directory
> 3) Don't install libnettle, and demand that someone else (perhaps the
> user, or the system package manager) install it.
> 
> Option 1 results in duplications. (Unless one application is allowed
> to access a library in another application's directory, which is a
> HORRIBLE mess.) Option 2 is exactly what you're complaining about,
> scattering files all over the FS. And option 3 is what package
> managers are for. What are you advocating?

Option 1 also is a huge security hole.  A prime example of this was the
so-called heartbleed bug.  In such a model, each app that distributes
openssl in the app bundle has to be updated or it is at risk.  This
turns out to be a huge vulnerability.

0
Michael
8/1/2014 8:22:20 PM
On 2014-08-01 18:16, Dietmar Schwertberger wrote:
> Am 01.08.2014 13:10, schrieb Wolfgang Keller:
>> Because on such operating systems, each and every application is an
>> entirely self-contained package that doesn't need any "packages" or
>> "installers" to use it.
> For people who have never used such a system it's probably difficult to see
> the  advantages.
>
> Besides the easy installation, backup and replication of software the
> RISC OS
> way also had the advantage that you were able to organize your
> applications in folders just like other folders and files.
> There was no need for separate File and Program managers.
> MS never got this right. Instead, they tried to fix things later with the
> start menu and finally the box to type the software name to start it ...
>
> One effect was that under DOS/Windows people usually saved their
> documents in folders per application whereas under RISC OS they
> were usually grouped by content/project.
>
>
> When it came to usability, RISC OS had many advantages over the
> other systems, e.g.
>    - real drag'n'drop for loading *and* saving of files/selections
>    - drag'n'drop also for transfer between applications
>    - a standard vector graphics format that all applications supported
>      (and for which an application was provided by default with the OS)
>    - good font display (still better than e.g. MS Windows today)
>    - three mouse buttons for select/menu/adjust
>    - no menu bars
>    - the icon bar for running applications, drives, shares and other
> resources
>    - consistent, orthogonal & logical user interfaces instead of assistants
>      and wizards for each and every task
>    - complete programmers reference manual
>
I'd heard people say how user-friendly Apple Macs were, but when I got
to use one I was somewhat disappointed.

When opening files, it used old-fashioned dialog boxes like RISC OS's
precursor from several years earlier. In RISC OS, if I had a directory
window open, I could save to it with a simple drag-and-drop, but in
MacOS, even if I had a directory window open, I had to navigate to the
directory in the Save dialog. (OK, not quite true, because of a
3rd-party extension called "Click There It Is".)

And don't mention the menu bar across the top, separated from the
window to which it belonged.

Or the way that clicking on any window of an application or the Finder
brought not only it but also all of the its siblings to the front. On
RISC OS, windows came to the front only when *I* wanted them to.

0
MRAB
8/1/2014 9:09:12 PM
Chris Angelico wrote:
> The installer has basically three choices.
> 1) Install libnettle inside the application directory
> 2) Install libnettle to some system library directory
> 3) Don't install libnettle, and demand that someone else (perhaps the
> user, or the system package manager) install it.
> 
> Option 2 is exactly what you're complaining about,
> scattering files all over the FS.

Not really. On MacOSX, if you installed a shared library
called libnettle, *all* the files relating to it
would be kept in one directory called Nettle.framework
(either in /Library/Frameworks or ~/Library/Frameworks
depending on whether it's system-wide or for a single user).

MacOSX doesn't currently have an automatic dependency
manager, but if it did, things would still be a lot neater
and tidier than they are in Linux or Windows, where what
is conceptually a single object (a package) gets split up
and its parts scattered around several obscure locations.

-- 
Greg
0
Gregory
8/1/2014 11:14:20 PM
On Sat, Aug 2, 2014 at 6:22 AM, Michael Torrie <torriem@gmail.com> wrote:
> On 08/01/2014 08:39 AM, Chris Angelico wrote:
>> The installer has basically three choices.
>> 1) Install libnettle inside the application directory
>> 2) Install libnettle to some system library directory
>> 3) Don't install libnettle, and demand that someone else (perhaps the
>> user, or the system package manager) install it.
>>
>> Option 1 results in duplications. (Unless one application is allowed
>> to access a library in another application's directory, which is a
>> HORRIBLE mess.) Option 2 is exactly what you're complaining about,
>> scattering files all over the FS. And option 3 is what package
>> managers are for. What are you advocating?
>
> Option 1 also is a huge security hole.  A prime example of this was the
> so-called heartbleed bug.  In such a model, each app that distributes
> openssl in the app bundle has to be updated or it is at risk.  This
> turns out to be a huge vulnerability.

More generally, that's exactly what Steven said about needing every
package to update before you can confidently say it's updated. But
that's also the greatest feature of the first option: you can't break
this application by upgrading that library, because only upgrading the
application (which hopefully will have been tested by the author) will
upgrade the library it uses.

ChrisA
0
Chris
8/1/2014 11:48:16 PM
On Sat, Aug 2, 2014 at 9:14 AM, Gregory Ewing
<greg.ewing@canterbury.ac.nz> wrote:
> Chris Angelico wrote:
>>
>> The installer has basically three choices.
>> 1) Install libnettle inside the application directory
>> 2) Install libnettle to some system library directory
>> 3) Don't install libnettle, and demand that someone else (perhaps the
>> user, or the system package manager) install it.
>>
>> Option 2 is exactly what you're complaining about,
>> scattering files all over the FS.
>
>
> Not really. On MacOSX, if you installed a shared library
> called libnettle, *all* the files relating to it
> would be kept in one directory called Nettle.framework
> (either in /Library/Frameworks or ~/Library/Frameworks
> depending on whether it's system-wide or for a single user).
>
> MacOSX doesn't currently have an automatic dependency
> manager, but if it did, things would still be a lot neater
> and tidier than they are in Linux or Windows, where what
> is conceptually a single object (a package) gets split up
> and its parts scattered around several obscure locations.

That's fine if I explicitly install libnettle - that's the third
option. What happens if I install Foo's Cool Chat App, and FCCA uses
libnettle to encrypt conversations? Is FCCA allowed to install
libnettle into /Library/Frameworks? If so, its files will be split
between there and its own app directory.

ChrisA
0
Chris
8/1/2014 11:50:13 PM
MRAB wrote:
> I'd heard people say how user-friendly Apple Macs were, but when I got
> to use one I was somewhat disappointed.

Well, they were compared to MS-DOS and the like, which was
all that was within reach of the general public when the
first Mac appeared. RISCOS came along somewhat later.

> in MacOS, even if I had a directory window open, I had to navigate to the
> directory in the Save dialog.

Yes, that was annoying. It wasn't a problem to begin with,
because the original Mac was strictly single-tasking --
you couldn't *have* a directory window and an application
open at the same time. And all your files were on floppies
in a flat file system -- folders only existed in the
Finder's imagination -- so the only real choice to be
made when saving a file was "which disk do I put it on".

When multitasking, hard disks and hierarchical file
systems came along, there was an opportunity for a
rethink, but it never really happened.

Things are somewhat better in MacOSX, where you can drag
a folder from a Finder window onto a file dialog to take
you there, but there is still more of a distinction between
Finder windows and save dialogs than there needs to be.

> And don't mention the menu bar across the top, separated from the
> window to which it belonged.

That seems to be a matter of taste. There are some
advantages to the menu-bar-at-top model. It's an easier
target to hit, because you can just flick the mouse up
to the top. It only takes up space once, instead of
once per window. It makes it possible for an app to
be running without having any windows, and still be
able to interact with it.

> Or the way that clicking on any window of an application or the Finder
> brought not only it but also all of the its siblings to the front.

MacOSX has fixed that one, thankfully. Only the window
you click comes to the front, now.

-- 
Greg
0
Gregory
8/2/2014 12:00:57 AM
On Sat, Aug 2, 2014 at 10:00 AM, Gregory Ewing
<greg.ewing@canterbury.ac.nz> wrote:
> MRAB wrote:
>> in MacOS, even if I had a directory window open, I had to navigate to the
>> directory in the Save dialog.
>
> Yes, that was annoying. It wasn't a problem to begin with,
> because the original Mac was strictly single-tasking --
> you couldn't *have* a directory window and an application
> open at the same time. And all your files were on floppies
> in a flat file system -- folders only existed in the
> Finder's imagination -- so the only real choice to be
> made when saving a file was "which disk do I put it on".

Okay, so it was like DOS 1.0...

> When multitasking, hard disks and hierarchical file
> systems came along, there was an opportunity for a
> rethink, but it never really happened.

.... and it didn't get improved when it grew directories like DOS 2.0
did. It's like how the default DOS prompt is actually $N$G when $P$G
is a lot more useful, except that changing the default prompt is
pretty easy and applies globally (not to mention that you might well
want to enhance the prompt beyond just $P$G).

>> And don't mention the menu bar across the top, separated from the
>> window to which it belonged.
>
> That seems to be a matter of taste. There are some
> advantages to the menu-bar-at-top model. It's an easier
> target to hit, because you can just flick the mouse up
> to the top. It only takes up space once, instead of
> once per window. It makes it possible for an app to
> be running without having any windows, and still be
> able to interact with it.

Downside: It separates (graphically and logically) a window from its
menu bar. The "easier target for the mouse" argument is valuable ONLY
when you use the mouse to access the menu bar. If you use the keyboard
(and take advantage of mnemonic letters), it's much more useful to
have the menu bar attached to its window. In the rare case of an app
that runs without any windows, incidentally, how do you tell the
system that you want that app's menu bar instead of (say) Finder,
which comes up when you click on the desktop?

ChrisA
0
Chris
8/2/2014 12:20:55 AM
This is a multi-part message in MIME format.
--------------020102020609010206010903
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 7/16/2014 7:27 AM, Frank Millman wrote:
> I just tried an experiment in my own project. Ned Batchelder, in his
> Pragmatic Unicode presentation, http://nedbatchelder.com/text/unipain.html,
> suggests that you always have some unicode characters in your data, just to
> ensure that they are handled correctly. He has a tongue-in-cheek example
> which spells the word PYTHON using various exotic unicode characters. I used
> this to populate a field in my database, to see if it would display in my
> browser-based client.
>
> The hardest part was getting it in. There are 6 characters, but utf-8
> requires 16 bytes to store it -
>
>      b'\xe2\x84\x99\xc6\xb4\xe2\x98\x82\xe2\x84\x8c\xc3\xb8\xe1\xbc\xa4'.decode('utf-8')
>
> However, that was it. Without any changes to my program, it read it from the
> database and displayed it on the screen. IE8 could only display 2 out of the
> 6 characters correctly, and Chrome could display 5 out of 6, but that is a
> separate issue. Python3 handled it perfectly.

wrapping the above in a print(), on Windows, I get:

Traceback (most recent call last):
   File "D:\my\py\python-utf8.py", line 1, in <module>
print(b'\xe2\x84\x99\xc6\xb4\xe2\x98\x82\xe2\x84\x8c\xc3\xb8\xe1\xbc\xa4'.decode('utf-8'))
   File "C:\Python33\lib\encodings\cp437.py", line 19, in encode
     return codecs.charmap_encode(input,self.errors,encoding_map)[0]
UnicodeEncodeError: 'charmap' codec can't encode characters in position 
0-5: character maps to <undefined>

So Python3 doesn't handle it perfectly on Windows.  And I saw someone 
blame the Windows console for that... but the Windows console can 
properly display all those characters if the proper APIs are used. The 
bug is 7 years old: http://bugs.python.org/issue1602 and hasn't been 
fixed, although the technology for fixing it is available, and various 
workarounds (with limitations) have been available for 5 years, and 
patches have been available for 3 years that work pretty good. However, 
just a few days ago, 26 July 2014, Drekin had an insight that may 
possibly lead to a patch that will work well enough to be integrated 
into some future version of Python... I hope he follows up on it. This 
is a serious limitation, and it is, and always has been, a bug in Python 
3 Unicode handling on Windows.

--------------020102020609010206010903
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#330033">
    <div class="moz-cite-prefix">On 7/16/2014 7:27 AM, Frank Millman
      wrote:<br>
    </div>
    <blockquote cite="mid:lq6255$gi5$1@ger.gmane.org" type="cite">
      <pre wrap="">I just tried an experiment in my own project. Ned Batchelder, in his 
Pragmatic Unicode presentation, <a class="moz-txt-link-freetext" href="http://nedbatchelder.com/text/unipain.html">http://nedbatchelder.com/text/unipain.html</a>, 
suggests that you always have some unicode characters in your data, just to 
ensure that they are handled correctly. He has a tongue-in-cheek example 
which spells the word PYTHON using various exotic unicode characters. I used 
this to populate a field in my database, to see if it would display in my 
browser-based client.

The hardest part was getting it in. There are 6 characters, but utf-8 
requires 16 bytes to store it -

    b'\xe2\x84\x99\xc6\xb4\xe2\x98\x82\xe2\x84\x8c\xc3\xb8\xe1\xbc\xa4'.decode('utf-8')

However, that was it. Without any changes to my program, it read it from the 
database and displayed it on the screen. IE8 could only display 2 out of the 
6 characters correctly, and Chrome could display 5 out of 6, but that is a 
separate issue. Python3 handled it perfectly.
</pre>
    </blockquote>
    <br>
    wrapping the above in a print(), on Windows, I get:<br>
    <br>
    Traceback (most recent call last):<br>
      File "D:\my\py\python-utf8.py", line 1, in &lt;module&gt;<br>
       
print(b'\xe2\x84\x99\xc6\xb4\xe2\x98\x82\xe2\x84\x8c\xc3\xb8\xe1\xbc\xa4'.decode('utf-8'))<br>
      File "C:\Python33\lib\encodings\cp437.py", line 19, in encode<br>
        return codecs.charmap_encode(input,self.errors,encoding_map)[0]<br>
    UnicodeEncodeError: 'charmap' codec can't encode characters in
    position 0-5: character maps to &lt;undefined&gt;<br>
    <br>
    So Python3 doesn't handle it perfectly on Windows.  And I saw
    someone blame the Windows console for that... but the Windows
    console can properly display all those characters if the proper APIs
    are used. The bug is 7 years old: <a class="moz-txt-link-freetext" href="http://bugs.python.org/issue1602">http://bugs.python.org/issue1602</a>
    and hasn't been fixed, although the technology for fixing it is
    available, and various workarounds (with limitations) have been
    available for 5 years, and patches have been available for 3 years
    that work pretty good. However, just a few days ago, 26 July 2014,
    Drekin had an insight that may possibly lead to a patch that will
    work well enough to be integrated into some future version of
    Python... I hope he follows up on it. This is a serious limitation,
    and it is, and always has been, a bug in Python 3 Unicode handling
    on Windows.<br>
  </body>
</html>

--------------020102020609010206010903--
0
Glenn
8/2/2014 6:18:47 AM
Chris Angelico wrote:
> The "easier target for the mouse" argument is valuable ONLY
> when you use the mouse to access the menu bar. If you use the keyboard
> (and take advantage of mnemonic letters), it's much more useful to
> have the menu bar attached to its window.

Seems to me that if you use the keyboard for everything,
it doesn't matter where the menu bar is. Unless you're
talking about the way you can use the keyboard to make
menus drop down in Windows... but that's not the way
Mac menu shortcuts work. The menu doesn't visually drop
down when you invoke a Mac menu command with the keyboard.

> In the rare case of an app
> that runs without any windows, incidentally, how do you tell the
> system that you want that app's menu bar instead of (say) Finder,
> which comes up when you click on the desktop?

In classic MacOS, there was a menu of running applications
in the top right corner. In MacOSX, you click on the app's
icon in the dock.

Also, while completely windowless applications might be
rare, it's not rare for an app to have some commands that
pertain to the app itself, and not to any particular
window, e.g. "New". It's more logical for those to appear
in a user interface element that's not tied to a window.

-- 
Greg
0
Gregory
8/2/2014 11:33:11 AM
On Sat, Aug 2, 2014 at 9:33 PM, Gregory Ewing
<greg.ewing@canterbury.ac.nz> wrote:
> Chris Angelico wrote:
>>
>> The "easier target for the mouse" argument is valuable ONLY
>> when you use the mouse to access the menu bar. If you use the keyboard
>> (and take advantage of mnemonic letters), it's much more useful to
>> have the menu bar attached to its window.
>
>
> Seems to me that if you use the keyboard for everything,
> it doesn't matter where the menu bar is. Unless you're
> talking about the way you can use the keyboard to make
> menus drop down in Windows... but that's not the way
> Mac menu shortcuts work. The menu doesn't visually drop
> down when you invoke a Mac menu command with the keyboard.

There are two forms of shortcut key. One is a direct-action keystroke
that immediately does the same thing that you can do using the menus
(say, Ctrl-O is the same as File... Open). With those, the menu is
completely unnecessary, except as a list of available keystrokes; it
could just as easily be a help screen that says "Press Ctrl-O to open
a file", so the menu's actual location is quite arbitrary. Downside:
There's only so many keystrokes available, and not all of them have
memorable meanings. It's usually best to keep this to the few most
common functions (opening a file, yes, but not "reinterpret this file
as ISO-8859-3", unless you make that configurable per user).

But the other form, usually described as menu mnemonics, is where you
press Alt-F to bring up the _File menu, and then O to activate _Open.
(In OS/2, those would be ~File and ~Open; in GTK, the mnemonic is
preceded by an underscore. Windows 3.1 used an ampersand, and I
believe Win32 does the same thing. It's a little awkward when you have
an invoicing screen and you put something like "P&O Shipping" as your
customer name, and suddenly Alt-O takes you someplace different. The
tilde has the advantage that it doesn't often come up accidentally;
the underscore makes sense because the mnemonic is underlined; I have
no idea why an ampersand should be used. But I digress.) When you work
this way, you aren't grabbing the mouse, so the advantage of not
needing to aim so carefully doesn't exist; but if the menu comes up
right near where your eyes are already focused, you need to move
_them_ less distance - and that means you can focus on the menu more
quickly, plus it emphasizes that the visual change (opening the menu)
occurred in your current program, not in something else.

In Xfce, I can press Alt-F1 to open up the main Applications Menu.
That's at the top of the screen (in fact, top left corner), so it gets
the "throw the mouse" benefit; I think I use the mouse with that a lot
more often than I use the mouse with a program's own menu, because
there's more likely to be something unusual in there. If I install a
new piece of software, I have to figure out where it's landed in the
menu; but Gypsum's four menus aren't changing unexpectedly, so I'm
happy using Alt-O, V to open up Advanced Options.

>> In the rare case of an app
>> that runs without any windows, incidentally, how do you tell the
>> system that you want that app's menu bar instead of (say) Finder,
>> which comes up when you click on the desktop?
>
> In classic MacOS, there was a menu of running applications
> in the top right corner. In MacOSX, you click on the app's
> icon in the dock.

Okay. So you need to first click on something in the dock - that's the
thing down the bottom of the screen, right? - and then go all the way
up to the top of the screen to use its menu bar. I think I'd much
rather have a popup menu - right-click the program's dock icon and get
the menu right there where the mouse already is. Oh wait, that
requires people to understand more than a single mouse button, so it's
contrary to Mac philosophy :)

> Also, while completely windowless applications might be
> rare, it's not rare for an app to have some commands that
> pertain to the app itself, and not to any particular
> window, e.g. "New". It's more logical for those to appear
> in a user interface element that's not tied to a window.

Sure, but those elements are usually rare enough that they can be
stuck on the window anyway. Audacity has a "New" that opens up a new
window, and it's slightly surprising the first couple of times, but
after that you get used to it. It's not a big enough issue to warrant
a change of UI. It is an issue, yes, but I wouldn't warp anything
around it any more than I'd warp my UI around the possibility of a
user having no screen or keyboard and is using the mouse blind. Sure
it happens (I've done it, and I know what I could code to make it
easier!), but not often.

ChrisA
0
Chris
8/2/2014 1:01:03 PM
On 2014-08-02 01:00, Gregory Ewing wrote:
> MRAB wrote:
[snip]
>> And don't mention the menu bar across the top, separated from the
>> window to which it belonged.
>
> That seems to be a matter of taste. There are some advantages to the
> menu-bar-at-top model. It's an easier target to hit, because you can
> just flick the mouse up to the top. It only takes up space once,
> instead of once per window. It makes it possible for an app to be
> running without having any windows, and still be able to interact
> with it.
>
RISC OS didn't have a menu bar at the top of each window either; its
menus were all pop-up. You didn't have to keep flicking the mouse at
all!
0
MRAB
8/2/2014 1:55:17 PM
In article <c42o1nFbrqdU1@mid.individual.net>,
 Gregory Ewing <greg.ewing@canterbury.ac.nz> wrote:

> > And don't mention the menu bar across the top, separated from the
> > window to which it belonged.
> 
> That seems to be a matter of taste. There are some
> advantages to the menu-bar-at-top model. It's an easier
> target to hit, because you can just flick the mouse up
> to the top. It only takes up space once, instead of
> once per window. It makes it possible for an app to
> be running without having any windows, and still be
> able to interact with it.

In the old days, we had really small screens (the original Mac had a 9 
inch screen with 512 x 342 resolution).  Most application windows filled 
most of the screen, so there really wasn't much difference between 
per-desktop and per-window menu bars.

These days, I'm running multiple 24 inch monitors.  The single menu bar 
paradigm starts to break down in an environment like that.  I find I 
tend to put the few windows I'm actively using near the top of my 
primary screen (the one with the menu bar), and use the second screen to 
hold windows I'm not interacting with much.
0
Roy
8/2/2014 2:27:03 PM
Chris Angelico wrote:
> It's a little awkward when you have
> an invoicing screen and you put something like "P&O Shipping" as your
> customer name, and suddenly Alt-O takes you someplace different.

An app that did that would be seriously broken, wouldn't it?
The & should only be interpreted that way in menu items, etc.,
not in user data.

> but if the menu comes up
> right near where your eyes are already focused, you need to move
> _them_ less distance

But putting the menu bar at the top of the window doesn't
guarantee that it will be near where your eyes are. If
you have a window taking up most of the screen and you're
editing something near the bottom, a menu bar at the top
of the window is nearly as far away as one at the top of
the screen.

It would make more sense to pop the menu up near the text
cursor. There's no law that says a menu summoned by
keystroke has to appear in the same place as one summoned
by mouse.

In any case, when you use a shortcut sequence, do you
really *look* at the menu that comes up, or do you just
memorise the appropriate alt-sequence? If you use it
frequently, I suspect the latter. If you don't use it
very often, having to look away doesn't matter so much.

> Okay. So you need to first click on something in the dock - that's the
> thing down the bottom of the screen, right? - and then go all the way
> up to the top of the screen to use its menu bar.

Because of the "throw the mouse" effect, going *all* the
way to the top takes a tiny fraction of a second and is
almost effortless. Going any lesser distance takes
*much* longer.

> I think I'd much
> rather have a popup menu - right-click the program's dock icon and get
> the menu right there where the mouse already is.

Dock icons do have a contextual menu, but it's just a
menu of windows. Fitting all of the app's menus in there
would require hierarchical menus, which are an abomination
you don't want to get me started on. :-)

> Oh wait, that
> requires people to understand more than a single mouse button, so it's
> contrary to Mac philosophy :)

The Mac philosophy on that seems to be widely misunderstood.
Having only one button on my mouse doesn't mean there's
only one thing I can do with it. I can shift-click, option-
click, command-click, and nowadays control-click, plus any
combination of those. That's enough for anyone to keep in
their head, I would have thought.

There's also one concrete advantage to using modifiers
instead of extra mouse buttons: you can provide feedback
by changing the cursor when a modifier is held down.

-- 
Greg
0
Gregory
8/3/2014 12:01:05 AM
MRAB wrote:
> RISC OS didn't have a menu bar at the top of each window either; its
> menus were all pop-up. You didn't have to keep flicking the mouse at
> all!

The main reason for having a menu bar is discoverability. The
idea is that you can browse through the menus and get a feel
for what commands are potentially available to you. That's not
so easy to do when everything is hidden in contextual menus.

-- 
Greg
0
Gregory
8/3/2014 12:04:56 AM
Roy Smith wrote:
> These days, I'm running multiple 24 inch monitors.  The single menu bar 
> paradigm starts to break down in an environment like that.

Yes, that's an issue. However, even on a large screen, most of
my windows are at least half a screen high, putting their tops
a considerable distance from where I'm working. And the targeting
effect means that a target at the top of the screen is still
easier to hit than one half way up.

Multiple screens are a problem. Probably what should happen is
for the menu bar to move to the screen holding the currently
active window, instead of being tied to one "primary" screen.

-- 
Greg
0
Gregory
8/3/2014 12:20:13 AM
On Sun, Aug 3, 2014 at 10:01 AM, Gregory Ewing
<greg.ewing@canterbury.ac.nz> wrote:
> Chris Angelico wrote:
>>
>> It's a little awkward when you have
>> an invoicing screen and you put something like "P&O Shipping" as your
>> customer name, and suddenly Alt-O takes you someplace different.
>
>
> An app that did that would be seriously broken, wouldn't it?
> The & should only be interpreted that way in menu items, etc.,
> not in user data.

Mnemonics can also be used on text labels, and then they apply to the
adjacent field - for instance, you could have "_Name" followed by an
entry field for the Name, and hitting Alt-N will take you to that
field. The app I'm talking about used a label to show the customer's
name, and we had exactly that issue (although more often with couples'
names - for instance, if we had an order from John and Mary Smith, but
didn't know their full names, we'd identify them as J&M Smith, and
voila, Alt-M would take us to... whatever field came after the display
of the name (which was the address).

To be quite honest, that particular program was a lot more broken than
that. But still, it did drive home the value of using ~ instead of &
for that job. And of course, _ makes enough sense that we can accept
its potential for collisions. (Plus it's usually possible to disable
underscore interpretation. Or, more properly, you have to explicitly
enable their interpretation; in GTK, I have to call
set_use_underline(1) before it'll create a mnemonic.)

>> but if the menu comes up
>> right near where your eyes are already focused, you need to move
>> _them_ less distance
>
>
> But putting the menu bar at the top of the window doesn't
> guarantee that it will be near where your eyes are. If
> you have a window taking up most of the screen and you're
> editing something near the bottom, a menu bar at the top
> of the window is nearly as far away as one at the top of
> the screen.

Putting it at the top of the window cannot possibly make it further
away than putting it at the top of the screen. It's potentially going
to be a lot closer, but at its worst, it'll be just as bad (modulo the
title bar's height).

> It would make more sense to pop the menu up near the text
> cursor. There's no law that says a menu summoned by
> keystroke has to appear in the same place as one summoned
> by mouse.

Sure. And I know of plenty of applications where that's possible. The
standard used to be Shift-F10 to bring up a context menu, identical to
right-clicking the mouse except that the menu appears at the object
you're working on rather than at the mouse's location. These days, you
often get something like that on the Menu key (aka the other Windows
key, on some keyboards); same result. But that's a context menu, not
the pull-down menu; although it's common to have the same menu items
on them.

> In any case, when you use a shortcut sequence, do you
> really *look* at the menu that comes up, or do you just
> memorise the appropriate alt-sequence? If you use it
> frequently, I suspect the latter. If you don't use it
> very often, having to look away doesn't matter so much.

If I'm using "Alt-F, O" as a command keystroke, then sure, it doesn't
make any difference where the menu is. But often I'll pull down a
menu, then look at it to figure out what I want to hit. Once my eye
has found it, I'll press its underlined letter, so I still don't use
the mouse; but I do need it to have a mnemonic, and I need the entire
menu to be near my eye.

>> Okay. So you need to first click on something in the dock - that's the
>> thing down the bottom of the screen, right? - and then go all the way
>> up to the top of the screen to use its menu bar.
>
> Because of the "throw the mouse" effect, going *all* the
> way to the top takes a tiny fraction of a second and is
> almost effortless. Going any lesser distance takes
> *much* longer.

Right, but it still takes time. Also, if your mouse is set fast enough
to go all the way from the bottom to the top of the screen in less
than 0.1s, then either your screen is fairly small (may have been true
in the past, but is getting pretty rare now), or you seriously
penalize any going-less-distance operations. In fact, it becomes
self-perpetuating: if you set the mouse fast, it becomes really
important to use the edges and avoid the middle, and if applications
always use the edges and never the middle, it's really important to
set your mouse faster. Conversely, slower mouse settings mean it's
easier to be precise with interior movements, while reducing the
advantage of the borders.

But no matter how fast you set the mouse, it still takes a nonzero
time to move it to a specific position. The absolute easiest place to
reach is... where you already are. Put the menu there! That's what
popup menus are for.

>> I think I'd much
>> rather have a popup menu - right-click the program's dock icon and get
>> the menu right there where the mouse already is.
>
> Dock icons do have a contextual menu, but it's just a
> menu of windows. Fitting all of the app's menus in there
> would require hierarchical menus, which are an abomination
> you don't want to get me started on. :-)

I detest window stacking. Each window stands alone, even if some are
from the same application. (Either that, or some of them are to be
altogether hidden. But anything that gets shown should be shown at top
level.)

>> Oh wait, that
>> requires people to understand more than a single mouse button, so it's
>> contrary to Mac philosophy :)
>
>
> The Mac philosophy on that seems to be widely misunderstood.
> Having only one button on my mouse doesn't mean there's
> only one thing I can do with it. I can shift-click, option-
> click, command-click, and nowadays control-click, plus any
> combination of those. That's enough for anyone to keep in
> their head, I would have thought.

I can do all those, AND I can do those with right-click. And bare
right-click has the advantage that it can be done one-handed; that can
be quite a difference when you have a son/daughter/brother/sister
hanging off your left arm...

> There's also one concrete advantage to using modifiers
> instead of extra mouse buttons: you can provide feedback
> by changing the cursor when a modifier is held down.

Sure. But that shouldn't preclude the use of additional mouse buttons too.

ChrisA
0
Chris
8/3/2014 1:12:39 AM
Am 03.08.2014 02:04, schrieb Gregory Ewing:
> MRAB wrote:
>> RISC OS didn't have a menu bar at the top of each window either; its
>> menus were all pop-up. You didn't have to keep flicking the mouse at
>> all!
> The main reason for having a menu bar is discoverability. The
> idea is that you can browse through the menus and get a feel
> for what commands are potentially available to you. That's not
> so easy to do when everything is hidden in contextual menus.
This was not a  problem with the RISC OS menu concept.
Only some menu items were depending on the mouse position.
Actually the menu items were easier to discover as the non-applicable
items were not hidden but greyed out.

Regards,

Dietmar

0
Dietmar
8/3/2014 7:46:20 AM
RIck,

On 7/17/14, 2:15 PM, Rick Johnson wrote:
> Sadly, all of my calls to improve IDLE have been meet with
> rebukes about me "whining". The "powers that be" would wise
> to*UTILIZE*  and*ENCOURAGE*  my participation instead of
> *IGNORING*  valuable talent and*IMPEDING*  the expansion of
> this "private boys club".

A bit late to this, I suppose...

Where are your patches? Can you point me to anywhere at the Python bug 
tracker where they can be found?

I'll highlight the two major patches I've submitted over the past few 
years:

http://bugs.python.org/issue15853
http://bugs.python.org/issue6075

One fixed a pretty bad crash on the Mac, and the other optimized IDLE's 
Mac port to adjust to some API changes in Tk because of a switch in the 
native back end (Carbon to Cocoa).

In both cases I posted an e-mail or two to the relevant mailing list 
(IDLE-dev and MacPython) to provide a head-up about the patch, answer 
questions, and so on--but that was it. No major "calls to improve IDLE," 
just some code that DID improve IDLE. The "powers that be" didn't commit 
the patches right away, and not without some modification and testing, 
but they eventually did commit them, and the outcome satisfied my 
intention in submitting the patches in the first place.

Both of these patches addressed issues that made IDLE pretty much 
un-usable for me. Obviously a crash will do this, but also, when I 
switched my installation of Tk from the Carbon-backed one to the 
Cocoa-backed one, there were lots of little glitches because of subtle 
differences in how Cocoa did things.

I suppose I simply could have filled the mailing lists with complaints 
that these things were Big Problems for me and Someone Should Do 
Something About Them, but there was no guarantee that someone would pick 
up the challenge. Fortunately, I had the knowledge, skills and time to 
submit patches that were sufficiently developed that the relevant Python 
maintainers could take them, apply them, modify slightly as required, 
test them, and then commit them. This did ensure that Something Would Be 
Done about my issue, because the Person Who Did Something About It was me.

I know you are proficient in both Python and Tkinter, as I've noted from 
the helpful advice you give Tkinter newbies on the list from time to 
time, and so I'm sure you have the skill set to put together some 
patches that address specific points of pain for you. And despite the 
disagreement that others may register with you in these threads from 
time to time, I'm quite confident that useful patches will be gratefully 
accepted, even if not immediately.

--Kevin

-- 
Kevin Walzer
Code by Kevin/Mobile Code by Kevin
http://www.codebykevin.com
http://www.wtmobilesoftware.com
0
Kevin
8/4/2014 1:21:26 AM
Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:

> Unfortunately, software development on Windows is something of a
> ghetto, compared to the wide range of free tools available for Linux.
> Outside of a few oases like Microsoft's own commercial development
> tools, it's hard to do development on Windows. Hard, but not
> impossible, of course, and there are quite a few resources available
> for the Windows user willing to download installers from the Internet.
> For Python users, the IDEs from Wingware and Activestate are notable:
> 
>     https://wingware.com/
>     http://komodoide.com/
> 
> 
> 
I missed this thread when it started, so please forgive me if this has 
been covered, but by dismissing Microsoft you look to have skipped over 
a very powerful Python IDE for Windows, namely PTVS.

Microsoft's PTVS is Windows only :-( and completely free (gratuit), 
partly free (libre): PTVS itself is Apache licensed and the required 
Visual Studio is of course closed source but PTVS now runs on the latest 
free versions of Visual Studio Express 2013 for Web or Visual Studio 
Express 2013 for Desktop (which includes C++).

Some of the features:

works with CPython (2.x or 3.x) or IronPython. Full support for 
virtualenv, packages can be installed directly from PTVS individually or 
from requirements.txt.

Intellisense uses a completion database generated in the background from 
the standard library and all installed libraries. It offers context 
sensitive completion which does a pretty good job of inferring the type 
of local variables based on the types of the values used to call the 
function.

Refactoring (Rename, Extract Method, Add Import, Remove unused imports) 

Interactive windows for all installed Python versions (can use standard 
shell or IPython)

Debugging locally or remotely including Linux and OS X targets (in fact 
they claim that anything capable of running Python can be debugged). 

Mixed mode Python and C++ debugging.

Profiling (CPython only).

Automatic test discovery for tests using unittest.

Support for PyLint.

Automatic deployment to Windows Azure.

Extensive support for Django (including Intellisense and debugging for 
templates and various Django specific commands such as sync db and admin 
shell).

-- 
Duncan Booth
0
Duncan
8/5/2014 1:29:26 PM
Duncan Booth wrote:

> Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
> 
>> Unfortunately, software development on Windows is something of a
>> ghetto, compared to the wide range of free tools available for Linux.

I remember writing this. But I don't remember when it was. Presumably some
time in the last six months :-)

>> Outside of a few oases like Microsoft's own commercial development
>> tools, it's hard to do development on Windows. Hard, but not
>> impossible, of course, and there are quite a few resources available
>> for the Windows user willing to download installers from the Internet.
>> For Python users, the IDEs from Wingware and Activestate are notable:
>> 
>>     https://wingware.com/
>>     http://komodoide.com/
>> 
>> 
>> 
> I missed this thread when it started, so please forgive me if this has
> been covered, but by dismissing Microsoft you look to have skipped over
> a very powerful Python IDE for Windows, namely PTVS.

Never heard of it :-)

Which is not surprising, since I'm not a Windows developer.

[snip feature list]

Nice. How does one get it?

If I gave the impression that one cannot do development on Windows, that was
not my intent. I tried to indicate that the difference was a matter of
degree, not impossibility. One of the reasons why so many of the core
developers for Python use Linux is that they got frustrated with the speed
humps on Windows, the poor "out of the box" experience for developers
(compare what dev tools you get with Windows by default versus what you get
on Linux by default), but that might also be somewhat self-selecting:
people who are happy with Windows development tend to stick to VB, Java,
C, .Net etc. while those who prefer lighter weight more agile environments
migrate to Linux. I don't know. 

But I do know that the existence of good quality Windows development tools
for Python is good news for the community, so thank you for mentioning
this.


-- 
Steven

0
Steven
8/5/2014 4:50:14 PM
Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:

> Duncan Booth wrote:
> 
>> Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
>> 
>>> Unfortunately, software development on Windows is something of a
>>> ghetto, compared to the wide range of free tools available for
>>> Linux. 
> 
> I remember writing this. But I don't remember when it was. Presumably
> some time in the last six months :-)
> 
>>> Outside of a few oases like Microsoft's own commercial development
>>> tools, it's hard to do development on Windows. Hard, but not
>>> impossible, of course, and there are quite a few resources available
>>> for the Windows user willing to download installers from the
>>> Internet. For Python users, the IDEs from Wingware and Activestate
>>> are notable: 
>>> 
>>>     https://wingware.com/
>>>     http://komodoide.com/
>>> 
>>> 
>>> 
>> I missed this thread when it started, so please forgive me if this
>> has been covered, but by dismissing Microsoft you look to have
>> skipped over a very powerful Python IDE for Windows, namely PTVS.
> 
> Never heard of it :-)
> 
> Which is not surprising, since I'm not a Windows developer.
> 
> [snip feature list]
> 
> Nice. How does one get it?

1) Get a Windows 8.1 VM, or a real PC if that's more convenient.

2) Download and install either "Microsoft Visual Studio Express 2013 with 
Update 3 for Web" or "Microsoft Visual Studio Express 2013 with Update 3 
for Windows Desktop" from 
http://www.visualstudio.com/downloads/download-visual-studio-vs

N.B. If you just download the original versions without update 3 you'll 
have to apply all updates before proceeding so easier to use the latest 
versions from the get go.

3) Download and install PTVS 2.1 Beta 2 from 
https://pytools.codeplex.com/releases

Note that you need at least PTVS 2.1 Beta and VS Express 2013 with at least 
Update 2 to be able to install with just free tools. Earlier versions will 
refuse to install.

There may be more intermediate steps of applying updates, but that's par 
for the Microsoft course. If you try this out in conjunction with a 
Microsoft Azure account then be sure to also install the Azure SDK.

Documentation is at https://pytools.codeplex.com/documentation
There's a Django tutorial at http://pytools.codeplex.com/wikipage?
title=Django%20Web%20Site/Cloud%20Service%20Tutorial which gives quite a 
good walkthrough.

> 
> If I gave the impression that one cannot do development on Windows,
> that was not my intent. I tried to indicate that the difference was a
> matter of degree, not impossibility. One of the reasons why so many of
> the core developers for Python use Linux is that they got frustrated
> with the speed humps on Windows, the poor "out of the box" experience
> for developers (compare what dev tools you get with Windows by default
> versus what you get on Linux by default), but that might also be
> somewhat self-selecting: people who are happy with Windows development
> tend to stick to VB, Java, C, .Net etc. while those who prefer lighter
> weight more agile environments migrate to Linux. I don't know. 
> 
> But I do know that the existence of good quality Windows development
> tools for Python is good news for the community, so thank you for
> mentioning this.
> 
So far they seem to have kept a pretty low profile; I suspect largely 
because until recently PTVS only worked with the pay versions of Visual 
Studio.


-- 
Duncan Booth
0
Duncan
8/5/2014 7:25:26 PM
--047d7ba97be6c0807404ffe88a6a
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Aug 5, 2014 at 12:25 PM, Duncan Booth <duncan.booth@invalid.invalid>
wrote:

> So far they seem to have kept a pretty low profile; I suspect largely
> because until recently PTVS only worked with the pay versions of Visual
> Studio.
>

Not true. When it didn't work with the free express versions of VS, it
worked with the free Visual Studio Shell (that people have also not heard
about :) So there has always been some free way of running PTVS.

--047d7ba97be6c0807404ffe88a6a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Tue, Aug 5, 2014 at 12:25 PM, Duncan Booth <span dir=3D"ltr">&lt;<a href=
=3D"mailto:duncan.booth@invalid.invalid" target=3D"_blank">duncan.booth@inv=
alid.invalid</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div id=3D":1uo" class=3D"a3s" style=3D"over=
flow:hidden">So far they seem to have kept a pretty low profile; I suspect =
largely<br>


because until recently PTVS only worked with the pay versions of Visual<br>
Studio.</div></blockquote></div><br><div class=3D"gmail_default" style=3D"f=
ont-size:small">Not true. When it didn&#39;t work with the free express ver=
sions of VS, it worked with the free Visual Studio Shell (that people have =
also not heard about :) So there has always been some free way of running P=
TVS.<br>

</div></div></div>

--047d7ba97be6c0807404ffe88a6a--
0
TP
8/5/2014 9:28:12 PM
> > Thankfully, all actually user-friendly operating systems (MacOS,
> > TOS, RiscOS, probably AmigaOS, MacOS X) spare(d) their users the
> > bottomless cesspit of "package management" and/or "installers".
> >
> > Because on such operating systems, each and every application is an
> > entirely self-contained package that doesn't need any "packages" or
> > "installers" to use it.
> 
> You mean everyone has to reinvent the proverbial wheel AND worry about
> dependency collisions? Yeah, that's a heavenly thought.

You should get a clue in stead of just fantasizing up assumptions based
on ignorance.

Sincerely,

Wolfgang
0
Wolfgang
8/6/2014 12:38:53 PM
> > Because on such operating systems, each and every application is an
> > entirely self-contained package that doesn't need any "packages" or
> > "installers" to use it.

> For people who have never used such a system it's probably difficult
> to see the  advantages.

That's the whole point.

The problem is that the ones who "decide" (well, they pretend to, but
actually can't, because they don't know the alternatives) are always
people who are "not even clueless".

I.e. they are totally clueless, *and* psychotically self-convinced of
their omnicompetence.

Sincerely,

Wolfgang
 
0
Wolfgang
8/6/2014 12:47:17 PM
> I've worked with both.  Quite honestly, I really wish that other
> operating systems had gone down this route. MS didn't possibly to make
> it harder to steal software, 

From the perspective of the computer-literate, proficient
screenworker, MS always got and gets everything completely wrong.

> and Unix...well, *nix has the concept of the "distribution" that will
> manage all of this for you.  We all know the problems that this
> causes.

Linux was made by geeks who didn't have a clue of ergonomics for
screenworkers and didn't care to get one.

Sincerely,

Wolfgang
0
Wolfgang
8/6/2014 12:47:58 PM
On Wed, Aug 6, 2014 at 10:38 PM, Wolfgang Keller <feliphil@gmx.net> wrote:
>> > Thankfully, all actually user-friendly operating systems (MacOS,
>> > TOS, RiscOS, probably AmigaOS, MacOS X) spare(d) their users the
>> > bottomless cesspit of "package management" and/or "installers".
>> >
>> > Because on such operating systems, each and every application is an
>> > entirely self-contained package that doesn't need any "packages" or
>> > "installers" to use it.
>>
>> You mean everyone has to reinvent the proverbial wheel AND worry about
>> dependency collisions? Yeah, that's a heavenly thought.
>
> You should get a clue in stead of just fantasizing up assumptions based
> on ignorance.

I've worked with a number of operating systems, a number of dependency
management systems, and a number of absences of such systems. I stand
by my earlier statements in this thread, and I think I have a fairly
good clue about what does and doesn't work in terms of installers.

There is one way to avoid most of the duplication and still make every
application perfectly self-contained. You simply decree that there are
no dependencies permitted except for the base OS itself and what it
provides. As long as that's a rich enough set of tools, everything can
work (that's what seems to be happening on mobile platforms, for
instance). But it does mean that any unusual dependencies have to be
considered part of the app, and that means duplication.

ChrisA
0
Chris
8/6/2014 12:51:42 PM
On Wednesday, May 28, 2014 6:38:22 PM UTC-4, Ben Finney wrote:
> Larry Martell <larry.martell@gmail.com> writes:
>=20
>=20
>=20
> > No company that I work for is using python 3 - they just have too much
>=20
> > of an investment in a python 2 code base to switch.
>=20
>=20
>=20
> There are many large companies still using FORTRAN and COBOL because of
>=20
> a large investment in those languages, which are far more outdated than
>=20
> Python 2. What's your point?

Fortran compiler vendors such as Intel, IBM, Oracle/SUN and open source pro=
jects such as gfortran are updating their compilers to the Fortran 2003 and=
 2008 standards while also keeping the ability to compile all the old Fortr=
an code. FORTRAN 77 programmers and programs will not be forced to move to =
modern Fortran, but I'm not sure that Python 2.x users can be as confident =
that Python 2.x will be supported on future operating systems.
0
beliavsky
8/6/2014 1:47:24 PM
On 8/6/2014 9:47 AM, beliavsky@aol.com.dmarc.invalid wrote:

> Fortran compiler vendors such as Intel, IBM, Oracle/SUN and open

*Vendors* sell compilers for money, which they can then use to *pay* 
people to do unfun stuff that volunteers don't want and should not have 
to do.

Actually, I am beginning to think that 2.7 should be split off for 3.x 
development and charged for.

> source projects such as gfortran are updating their compilers to the
> Fortran 2003 and 2008 standards while also keeping the ability to
> compile all the old Fortran code. FORTRAN 77 programmers and programs

According to https://gcc.gnu.org/fortran/ , gfortran is a standard 
Fortran 95 compiler with legacy (F77) support where practical and 
'significant' F2003 and F2008 support. Since it is free, one takes what 
one gets.

In multiple ways, Gfortran, as a whole, is significantly simpler to 
develop than Python. It is an alternate front end to the gcc compiler (a 
very smart decision).  The GNU projects distributes source code, which I 
presume consists of C code aimed at the GCC compiler.

> will not be forced to move to modern Fortran, but I'm not sure that
> Python 2.x users can be as confident that Python 2.x will be
> supported on future operating systems.

It will be for as long as 2.x users are willing to pay for support.

-- 
Terry Jan Reedy

0
Terry
8/6/2014 6:42:54 PM
Terry Reedy wrote:

> On 8/6/2014 9:47 AM, beliavsky@aol.com.dmarc.invalid wrote:
> 
>> Fortran compiler vendors such as Intel, IBM, Oracle/SUN and open
> 
> *Vendors* sell compilers for money, which they can then use to *pay*
> people to do unfun stuff that volunteers don't want and should not have
> to do.

Red Hat does this, and will offer support for 2.7 until 2023. But even Red
Hat doesn't offer to support software forever -- Python 2.3 has just
reached end of life with paid Red Hat support earlier this year. Anyone
still using 2.3 now has two choices, keep using it without support, or
upgrade. The same will apply to 2.7 users. It's not like their computer
will suddenly stop running 2.7.

Come 2020 when Python 2.7 stops receiving free support from the core
developers, there's a business opportunity for the 2.7-naysayers. Red Hat
support is Red Hat Enterprise Linux only. There may be paid support from
companies like ActiveState, but that's likely to be Windows only (I could
be wrong about that). So there's the opportunity: in 2020, those naysayers
who are convinced that Python 3 is a mistake can offer paid support on
whatever platforms they like.


> Actually, I am beginning to think that 2.7 should be split off for 3.x
> development and charged for.

Python is open source. Anyone can fork it, and release 2.8, 2.9, 2.10, as
many versions they like. The only thing they can't do is call it "Python
2.8" without agreement from the PSF, which they won't get.

But they won't fork it, for two reasons: Complaining is cheap, actually
maintaining a programming language is hard work. And deep down they know
that a fork will be just a waste of time. This is not like the fork of the
X-11 windowing system a few years back, for all the complaints and whinging
about Python 3 even the nay-sayers know that the world will remain full
behind Guido, the core developers and the PSF, who are all committed to
Python 3.

Let me be frank here: the core developers are committed to making the
process of migrating from 2 to 3 as easy as possible without compromising
Python 3 in any serious manner. E.g. minor cosmetic warts, like the
re-introduction of u"" syntax just for backwards compatibility reasons, may
be allowed, reversing design decisions like strings being Unicode rather
than bytes will not be. But ultimately, people will need to make a choice:

- spend the time and effort and money to migrate from Python 2 to 3;

- spend an order of magnitude more time and effort and money to 
  re-write their applications in another language;

- pay somebody to support Python 2.7 for as long as needed;

- or do without bug fixes and security updates.

If you want bug fixes, security updates AND feature enhancements, for free,
you have have to migrate to Python 3 (or another language). If you're
unhappy with that, write to Oprah, I'm sure she'll listen.




-- 
Steven

0
Steven
8/7/2014 2:42:22 AM
Wolfgang Keller wrote:

> Linux was made by geeks who didn't have a clue of ergonomics for
> screenworkers and didn't care to get one.

I can only repeat what you said earlier:

"You should get a clue in stead [sic] of just fantasizing up assumptions
based on ignorance."

I daresay that Linus Torvalds spends more time in front of a computer screen
than most 9 to 5 "screenworkers".


By the way, you keep replying to people, and quoting them, but deleting
their name. Please leave the attribution in place, so we know who you are
replying to.



-- 
Steven

0
Steven
8/7/2014 3:32:08 AM
beliavsky@aol.com wrote:

> Fortran compiler vendors such as Intel, IBM, Oracle/SUN and open source
> projects such as gfortran are updating their compilers to the Fortran 2003
> and 2008 standards while also keeping the ability to compile all the old
> Fortran code. FORTRAN 77 programmers and programs will not be forced to
> move to modern Fortran, 

How about FORTRAN IV and FORTRAN 66 users? Where's their support? Why aren't
they moaning and gnashing their teeth that they're so cruelly and
unreasonably forced to upgrade?

> but I'm not sure that Python 2.x users can be as 
> confident that Python 2.x will be supported on future operating systems.

Oh well, life wasn't meant to be easy. Fortunately they can run it under
Windows 98 or Centos 3.5 in a virtual machine.



-- 
Steven

0
Steven
8/7/2014 3:37:29 AM
On Thu, 07 Aug 2014 13:37:29 +1000, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> declaimed the following:

>beliavsky@aol.com wrote:
>
>> Fortran compiler vendors such as Intel, IBM, Oracle/SUN and open source
>> projects such as gfortran are updating their compilers to the Fortran 2003
>> and 2008 standards while also keeping the ability to compile all the old
>> Fortran code. FORTRAN 77 programmers and programs will not be forced to
>> move to modern Fortran, 
>
>How about FORTRAN IV and FORTRAN 66 users? Where's their support? Why aren't
>they moaning and gnashing their teeth that they're so cruelly and
>unreasonably forced to upgrade?
>
	Most likely, the formal standard document for Fortran still mandates
F77 compatibility -- yet most likely also lists those F77 features which
are deprecated/obsolete and may go away in the next standard. Just as F77
standard listed F-IV features that would be going away in the future.

	Also, being a fully compiled/static language, the compiler can probably
spend the needed time to determine the dialect being used for some
constructs. Python's run-time dynamics may preclude doing that.

	Third -- said compatibility may still require using a compile-time flag
to indicate dialect for some features.

	Heck, at one time the "FORTRAN standard" actually defined two levels of
the language, and the subset level could not compile stuff that was legal
in the full language level. Things like computed arguments in a subprogram
call:

	call xyz(i-1, i, i+1)

could be valid or invalid depending upon which level of the single standard
the compiler followed. I once was involved in an effort that ported an
application in "full" FORTRAN to a machine with the subset level. You
wouldn't believe the number of

inxs, inks, jinx, jynx, jinks, linx, lynx, lyncs etc. junk variables had to
be created:

	jinx = i-1
	lynx = i+1
	call xyz(jinx, i, lynx)

-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

0
Dennis
8/8/2014 1:07:40 AM
> >> > Thankfully, all actually user-friendly operating systems (MacOS,
> >> > TOS, RiscOS, probably AmigaOS, MacOS X) spare(d) their users the
> >> > bottomless cesspit of "package management" and/or "installers".
> >> >
> >> > Because on such operating systems, each and every application is
> >> > an entirely self-contained package that doesn't need any
> >> > "packages" or "installers" to use it.
> >>
> >> You mean everyone has to reinvent the proverbial wheel AND worry
> >> about dependency collisions? Yeah, that's a heavenly thought.
> >
> > You should get a clue in stead of just fantasizing up assumptions
> > based on ignorance.
> 
> I've worked with a number of operating systems, a number of dependency
> management systems, and a number of absences of such systems. I stand
> by my earlier statements in this thread, 

Then you seem to have a problem with elementary logical reasoning.

Your above statement (about "re-inventing the wheel AND worrying about
dependency collisions") is totally illogical nonsense.

Just one issue: MacOS application have always been far more compact
(both on disk and in RAM) than comparable Windows or Unix counterparts.
"Despite" the fact that they where GUI applications since MacOS 1.0. No
one has to "re-invent" any more wheels to develop a MacOS X application
than he has to do for a Windows or Linux application. In fact, usually,
there are less wheels to re-invent for MacOS X.

Next: The self-contained nature of applications is obviously exactly
what *eliminates* dependency collisions. 

Sincerely,

Wolfgang
0
Wolfgang
8/11/2014 9:08:36 AM
> > Linux was made by geeks who didn't have a clue of ergonomics for
> > screenworkers and didn't care to get one.
> 
> I can only repeat what you said earlier:
> 
> "You should get a clue in stead [sic] of just fantasizing up
> assumptions based on ignorance."
> 
> I daresay that Linus Torvalds spends more time in front of a computer
> screen than most 9 to 5 "screenworkers".

He's a developer, not a usual screenworker.
 
> By the way, you keep replying to people, and quoting them, but
> deleting their name. Please leave the attribution in place, so we
> know who you are replying to.

That's what the "References:"-Header is there for.

Sincerely,

Wolfgang
0
Wolfgang
8/11/2014 9:08:43 AM
On Mon, 11 Aug 2014 11:08:43 +0200, Wolfgang Keller wrote:

>> By the way, you keep replying to people, and quoting them, but deleting
>> their name. Please leave the attribution in place, so we know who you
>> are replying to.
> 
> That's what the "References:"-Header is there for.
> 
> Sincerely,
> 
> Wolfgang

Which is not normally visible unless you go looking for it
Also despite the problems it causes there are still an large number of 
posters that use Google groups & probably cant see those headers even if 
they wished. Common courtesy (or netiquet if you prefer) would be to 
follow the conventions of the group you are posting to.


-- 
You definitely intend to start living sometime soon.
0
alister
8/11/2014 9:37:38 AM
On Mon, Aug 11, 2014 at 7:37 PM, alister
<alister.nospam.ware@ntlworld.com> wrote:
> On Mon, 11 Aug 2014 11:08:43 +0200, Wolfgang Keller wrote:
>
>>> By the way, you keep replying to people, and quoting them, but deleting
>>> their name. Please leave the attribution in place, so we know who you
>>> are replying to.
>>
>> That's what the "References:"-Header is there for.
>
> Which is not normally visible unless you go looking for it
> Also despite the problems it causes there are still an large number of
> posters that use Google groups & probably cant see those headers even if
> they wished. Common courtesy (or netiquet if you prefer) would be to
> follow the conventions of the group you are posting to.

Additionally, the References header is good for at most one level in.
Can you see, by looking at my post here, who Alister is quoting? Yes,
easily, because his attribution line is part of the text that I've
quoted. Can you see who Wolfgang is quoting? No, because there's no
attribution line. It's completely impractical to dig through the
References header (Alister's post has nineteen message IDs in
References, and presumably mine will add a twentieth) to find out who
quoted whom three levels ago.

ChrisA
0
Chris
8/11/2014 10:20:13 AM
On 11/08/2014 10:08, Wolfgang Keller wrote:
>
>> By the way, you keep replying to people, and quoting them, but
>> deleting their name. Please leave the attribution in place, so we
>> know who you are replying to.
>
> That's what the "References:"-Header is there for.
>
> Sincerely,
>
> Wolfgang
>

The references header is conspicious by its absence.

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

Mark Lawrence

0
Mark
8/11/2014 1:45:40 PM
On 2014-08-06, Wolfgang Keller <feliphil@gmx.net> wrote:
>> > Because on such operating systems, each and every application is an
>> > entirely self-contained package that doesn't need any "packages" or
>> > "installers" to use it.
>
>> For people who have never used such a system it's probably difficult
>> to see the  advantages.
>
> That's the whole point.
>
> The problem is that the ones who "decide" (well, they pretend to, but
> actually can't, because they don't know the alternatives) are always
> people who are "not even clueless".

Ha!  I love it.  I presume that's an allusion to that-other-Wolfgang's
apocryphal "not even wrong" comment.  :)

-- 
Grant Edwards               grant.b.edwards        Yow! I want to mail a
                                  at               bronzed artichoke to
                              gmail.com            Nicaragua!
0
Grant
8/11/2014 6:39:28 PM
On 2014-08-11, Wolfgang Keller <feliphil@gmx.net> wrote:

> [somebody, but we don't know who, wrote]...

>> By the way, you keep replying to people, and quoting them, but
>> deleting their name. Please leave the attribution in place, so we
>> know who you are replying to.
>
> That's what the "References:"-Header is there for.

Your over-confidence in Usenet, mailing list archives, news-to-mail
gateways, and various client applications is showing...

-- 
Grant Edwards               grant.b.edwards        Yow! Can I have an IMPULSE
                                  at               ITEM instead?
                              gmail.com            
0
Grant
8/11/2014 6:42:22 PM
Wolfgang Keller wrote:

>> By the way, you keep replying to people, and quoting them, but
>> deleting their name. Please leave the attribution in place, so we
>> know who you are replying to.
> 
> That's what the "References:"-Header is there for.

The References header is for the benefit of news and mail clients, not human
readers. Giving attribution in the body of your text is for the benefit of
people reading your reply, and I maintain that people are far more
important than your news or mail client.

It is rude to deliberately refuse to give attributes:

- you're saying that the person you are replying to doesn't deserve to have
their identity acknowledged even in passing;

- you're saying that you expect all of your readers to spend significant
time and effort to follow the machine references in the headers if they
want to understand who you are talking to, just to save you the one-off
cost of turning on the phrase used when replying, which every mail and news
client I know of supports (including Sylpheed);

- you are saying that anyone reading this forum via unthreaded web archives
don't matter;

- and anyone who (for one reason or another) is missing some of the
referenced posts, possibly because they have expired, or were never
delivered in the first place.

So please stop being rude, and follow the convention of both email and
usenet (as well as broader society) to give attribution to those you quote.


-- 
Steven

0
Steven
8/12/2014 12:11:01 AM
On 2014-08-12 10:11, Steven D'Aprano wrote:
> It is rude to deliberately refuse to give attributes

While I find this true for first-level attribution, I feel far less
obligation to attribute additional levels (and the verbosity they
entail). If the reader is really that interested in who said what,
then they can go back to previous posts to disinter that
information.  I find that

  On 2013-12-14 Ian Paul Freely wrote:
  > On 2014-12-11 Xavier Onasis wrote:
  >> On 2014-12-10 Pat McCann wrote:
  >>> On 2014-12-09 Mike Easter wrote:
  >>>> Lunch for Mary's birthday?
  >>>
  >>> How's Wednesday?
  >>
  >> Wed is good, what time?
  >
  > Earlier is better for me. 11:30?

  How about at that little Greek place on 4th Street?

could just credit Ian and snip out the other attributions for the
sake of quoting just the parts that I find matter.

  On 2013-12-14 Ian Paul Freely wrote:
  >>>> Lunch for Mary's birthday?
  >>>
  >>> How's Wednesday?
  >>
  >> Wed is good, what time?
  >
  > Earlier is better for me. 11:30?

  How about at that little Greek place on 4th Street?

If I really care about who was associated with more historical
comments, I'll pull up my message history and read the details.

-tkc




0
Tim
8/12/2014 12:27:25 AM
On Mon, 11 Aug 2014 19:27:25 -0500, Tim Chase wrote:

> On 2014-08-12 10:11, Steven D'Aprano wrote:
>> It is rude to deliberately refuse to give attributes
> 
> While I find this true for first-level attribution, I feel far less
> obligation to attribute additional levels (and the verbosity they
> entail). If the reader is really that interested in who said what, then
> they can go back to previous posts to disinter that information.

I cannot disagree with that. I consider that the first-level attribution 
MUST be given, second-level SHOULD be given, and third- and subsequent 
levels MAY be given, where MUST/SHOULD/MAY have their conventional 
meanings from RFC 2119.

https://www.ietf.org/rfc/rfc2119.txt


With one proviso: if you respond *directly* to something quoted at the 
Nth-level, for any N, (as opposed to merely leaving it in to establish 
context), then you MUST given an attribution. Even if that attribution is 
just "Sorry, I don't know who said this", you ought to make an honest 
effort to give credit to those you quote directly.



-- 
Steven
0
Steven
8/12/2014 2:07:07 AM
On Tue, Aug 12, 2014 at 12:07 PM, Steven D'Aprano <steve@pearwood.info> wrote:
> I cannot disagree with that. I consider that the first-level attribution
> MUST be given, second-level SHOULD be given, and third- and subsequent
> levels MAY be given, where MUST/SHOULD/MAY have their conventional
> meanings from RFC 2119.
>
> https://www.ietf.org/rfc/rfc2119.txt

That's fair. It's also very easy to give first-level attribution (just
set your client up properly and that's that), while giving
second-level means carefully retaining it from upstream. If it's easy
(if you're quoting the beginning of the quote), then it's still of
value, but it's not as important as first-level.

ChrisA
0
Chris
8/12/2014 2:13:14 AM
On 2014-08-12 02:07, Steven D'Aprano wrote:
> >> It is rude to deliberately refuse to give attributes  
> > 
> > While I find this true for first-level attribution, I feel far
> > less obligation to attribute additional levels (and the verbosity
> > they entail). 
> 
> I cannot disagree with that. I consider that the first-level
> attribution MUST be given, second-level SHOULD be given, and third-
> and subsequent levels MAY be given
> 
> With one proviso: if you respond *directly* to something quoted at
> the Nth-level, for any N, (as opposed to merely leaving it in to
> establish context), then you MUST given an attribution.

For these case, I tend to do it interlinearly with my response, e.g.
"while you have some good points, I still lean towards Terry's 
recommendation to frobniculate the hammerjammer" rather than have a
long list of attributions at the top of the email.

-tkc



0
Tim
8/12/2014 2:23:10 AM
> >> By the way, you keep replying to people, and quoting them, but
> >> deleting their name. Please leave the attribution in place, so we
> >> know who you are replying to.
> > 
> > That's what the "References:"-Header is there for.
> 
> The References header is for the benefit of news and mail clients,
> not human readers.

Any half-decent news client will happily display a thread tree for you.
Based on that References:-Header.

> It is rude to deliberately refuse to give attributes:

> So please stop being rude, and follow the convention of both email and
> usenet (as well as broader society) to give attribution to those you
> quote.

I've been using mail and news for over 20 years now, you definitely
don't need to teach me anything.

End of subthread.

Good Bye,

Wolfgang
0
Wolfgang
8/13/2014 10:42:34 AM
> >> > Because on such operating systems, each and every application is
> >> > an entirely self-contained package that doesn't need any
> >> > "packages" or "installers" to use it.
> >
> >> For people who have never used such a system it's probably
> >> difficult to see the  advantages.
> >
> > That's the whole point.
> >
> > The problem is that the ones who "decide" (well, they pretend to,
> > but actually can't, because they don't know the alternatives) are
> > always people who are "not even clueless".
> 
> Ha!  I love it.  I presume that's an allusion to that-other-Wolfgang's
> apocryphal "not even wrong" comment.  :)

Exactly.

And it's also an allusion to that statement that "knowledge means to
know what you don't know".

Sincerely,

Wolfgang
0
Wolfgang
8/13/2014 11:46:45 AM
Wolfgang Keller wrote:

> I've been using mail and news for over 20 years now, you definitely
> don't need to teach me anything.

Except common courtesy.

You may have been rude for over 20 years, but I don't have to put up with it
for a second longer.

> Good Bye,

Agreed.

*plonk*


-- 
Steven

0
Steven
8/13/2014 1:35:04 PM
On 13/08/2014 11:42, Wolfgang Keller wrote:
>>>> By the way, you keep replying to people, and quoting them, but
>>>> deleting their name. Please leave the attribution in place, so we
>>>> know who you are replying to.
>>>
>>> That's what the "References:"-Header is there for.
>>
>> The References header is for the benefit of news and mail clients,
>> not human readers.
>
> Any half-decent news client will happily display a thread tree for you.
> Based on that References:-Header.
>
>> It is rude to deliberately refuse to give attributes:
>
>> So please stop being rude, and follow the convention of both email and
>> usenet (as well as broader society) to give attribution to those you
>> quote.
>
> I've been using mail and news for over 20 years now, you definitely
> don't need to teach me anything.

Very funny.  It strikes me that your knowledge of using mail and news is 
akin to that of our resident unicode expert's knowledge of the FSR.

>
> End of subthread.
>

The subthread ends when people want it to end, not when you state that 
it has ended.  It will not end until you stop being so downright rude in 
refusing to give attribution to those you quote.

> Good Bye,

Good riddance.

Ditto Steven D'Aprano's *plonk*

>
> Wolfgang
>


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

Mark Lawrence

0
Mark
8/13/2014 3:51:10 PM
Reply:

Similar Artilces:

This Python 3 is killing Python thread is killing me.
Can you all stop already with the non python US bashing? Please? Deb in WA, USA ____________________________________________________________ Protect your computer files with professional cloud backup. Get PCRx Backup and upload unlimited files automatically.=20 Learn more at http://backup.pcrx.com/mail On Wed, 16 Jul 2014 09:32:31 -0800, Deb Wyatt wrote: > Can you all stop already with the non python US bashing? Please? > > Deb in WA, USA > > ____________________________________________________________ Protect > your computer files with professional...

python is a python
python is a python ...

Repo/directory names (was Re: Python and IDEs [was Re: Python 3 is killing Python])
On Sun, Jul 20, 2014 at 10:41 AM, Tim Delaney <timothy.c.delaney@gmail.com> wrote: > On 20 July 2014 09:19, Chris Angelico <rosuav@gmail.com> wrote: >> >> That said, though, there are some projects so modest they don't >> require dedicated repositories. I have a repo called "shed" - it's a >> collection of random tools that I've put together, no more logical >> grouping exists. > > Agreed. I have a "utils" one - but I do like "shed" and think I'm going to > rename :) I first met tha...

embedding python in python #3
Hi, anyone had any experiences in embedding python in python? I've tried to do this but it doesn't work. eval("from Tkinter import *") Thanks maurice Use exec. On Wed, Sep 29, 2004 at 09:23:28AM +0000, Maurice LING wrote: > Hi, > > anyone had any experiences in embedding python in python? > > I've tried to do this but it doesn't work. > > eval("from Tkinter import *") Maurice LING <mauriceling@acm.org> wrote in message news:<415a7f0b$1@news.unimelb.edu.au>... > Hi, > > anyone had any experiences in embeddi...

python 2 to python 3
I am using Wing101 v.5 and it is using Python2, but I want to make it = use Python3 instead because need Python3 for a uni lab. How do I = change it?= Audrey McFarlane wrote: > I am using Wing101 v.5 and it is using Python2, but I want to make it use > Python3 instead because need Python3 for a uni lab. How do I change it? I'm afraid I don't use Wing so I can't give a good answer, but I googled and found this: http://stackoverflow.com/questions/25318792/how-do-i-configure-wing101-to-run-python-3-3 It's not very helpful, but it might point you in th...

[Python 3.3.0] Getting tkinter to work on Python 3
--047d7bf0d52ef12d7304d836299a Content-Type: text/plain; charset=ISO-8859-1 Hi. I'm having a problem trying to get this to work well. Basically, whenever I try to import tkinter, this is the issue that I have: >>> import tkinter Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/local/lib/python3.3/tkinter/__init__.py", line 40, in <module> import _tkinter # If this fails your Python may not be configured for Tk ImportError: No module named '_tkinter' I'm running Ubuntu. If...

[RELEASED] Python 3.2.5 and Python 3.3.2
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On behalf of the Python development team, I am pleased to announce the releases of Python 3.2.5 and 3.3.2. The releases fix a few regressions in 3.2.4 and 3.3.1 in the zipfile, gzip and xml.sax modules. Details can be found in the changelogs: http://hg.python.org/cpython/file/v3.2.5/Misc/NEWS and http://hg.python.org/cpython/file/v3.3.2/Misc/NEWS To download Python 3.2.5 or Python 3.3.2, visit: http://www.python.org/download/releases/3.2.5/ or http://www.python.org/download/releases/3.3.2/ respectively. As...

[RELEASED] Python 3.2.6, Python 3.3.6
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On behalf of the Python development team, I'm happy to announce the release of Python 3.2.6 and 3.3.6. Both are security-fix releases, which are provided source-only on python.org. The list of security-related issues fixed in the releases is given in the changelogs: https://hg.python.org/cpython/raw-file/v3.2.6/Misc/NEWS https://hg.python.org/cpython/raw-file/v3.3.6/Misc/NEWS To download the releases visit one of: https://www.python.org/downloads/release/python-326/ https://www.python.org/downloads/release/...

python-2.7.3 vs python-3.2.3
Greetings; I have need of using a script written for python3, but the default python on wheezy is 2.7.3. I see in the wheezy repos that 3.2.3-6 is available. Can/will they co-exist peacefully? Thank you. Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene> On 26/01/16 13:26, Gene Heskett wrote: > Greetings; > > I have need of using a script written for python3, but the default pytho...

[RELEASED] Python 3.2.6rc1, Python 3.3.6rc1
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On behalf of the Python development team, I'm happy to announce the release of Python 3.2.6rc1 and 3.3.6rc1. Both are release candidates for security-fix releases, which are provide source-only on python.org. The list of security-related issues fixed in the releases is given in the changelogs: https://hg.python.org/cpython/raw-file/v3.2.6rc1/Misc/NEWS https://hg.python.org/cpython/raw-file/v3.3.6rc1/Misc/NEWS To download the pre-releases visit one of: https://www.python.org/downloads/release/python-326rc1/ ...

[RELEASED] Python 3.2.5 and Python 3.3.2
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On behalf of the Python development team, I am pleased to announce the releases of Python 3.2.5 and 3.3.2. The releases fix a few regressions in 3.2.4 and 3.3.1 in the zipfile, gzip and xml.sax modules. Details can be found in the changelogs: http://hg.python.org/cpython/file/v3.2.5/Misc/NEWS and http://hg.python.org/cpython/file/v3.3.2/Misc/NEWS To download Python 3.2.5 or Python 3.3.2, visit: http://www.python.org/download/releases/3.2.5/ or http://www.python.org/download/releases/3.3.2/ respectively. As...

[RELEASED] Python 3.2.6, Python 3.3.6
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On behalf of the Python development team, I'm happy to announce the release of Python 3.2.6 and 3.3.6. Both are security-fix releases, which are provided source-only on python.org. The list of security-related issues fixed in the releases is given in the changelogs: https://hg.python.org/cpython/raw-file/v3.2.6/Misc/NEWS https://hg.python.org/cpython/raw-file/v3.3.6/Misc/NEWS To download the releases visit one of: https://www.python.org/downloads/release/python-326/ https://www.python.org/downloads/release/...

[RELEASED] Python 3.2.6rc1, Python 3.3.6rc1
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On behalf of the Python development team, I'm happy to announce the release of Python 3.2.6rc1 and 3.3.6rc1. Both are release candidates for security-fix releases, which are provide source-only on python.org. The list of security-related issues fixed in the releases is given in the changelogs: https://hg.python.org/cpython/raw-file/v3.2.6rc1/Misc/NEWS https://hg.python.org/cpython/raw-file/v3.3.6rc1/Misc/NEWS To download the pre-releases visit one of: https://www.python.org/downloads/release/python-326rc1/ ...

[RELEASED] Python 3.2.4 and Python 3.3.1
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On behalf of the Python development team, I am pleased to announce the final releases of Python 3.2.4 and 3.3.1. Python 3.2.4 is the final regular maintenance release for the Python 3.2 series, while Python 3.3.1 is the first maintenance release for the 3.3 series. Both releases include hundreds of bugfixes. There has recently been a lot of discussion about XML-based denial of service attacks. Specifically, certain XML files can cause XML parsers, including ones in the Python stdlib, to consume gigabytes of RAM and swamp the CPU. Th...

Web resources about - Python 3 is killing Python - comp.lang.python

The Act of Killing - Wikipedia, the free encyclopedia
When Sukarno was overthrown by Suharto following the tragic 30 September Movement in 1965, Anwar and his friends were promoted from small-time ...

Man stuck on icy roads accused of killing Good Samaritan
Police in North Carolina say that 27-year-old Marvin Lee shot and killed a man who tried to help him after his car became stuck on icy roads. ...