Article on the future of Python

[Mark Lawrence]

But, by that time, the guy who closed the sale has already cashed his
bonus check, bought his new BMW, and moved on to another company.

And around that time, some poor schmuck of a dev manager is telling his
team what the sales guy sold. And that they have 12 weeks to design,
build, and deliver it.

How long did you just say??? I promised it in 8 weeks, not 12 you
complete moron

 

[Kevin Walzer]

IronPython in C#. Jython is written in Java. CLPython is written in Lisp.
Berp and HoPe are written in Haskell. Nuitka is written in C++. Skulpt is
written in Javascript. Vyper is written in Ocaml. PyPy is written in
RPython.

Some of those Python compilers are obsolete, unmaintained or
experimental. Others are not. But either way, it is certainly not true
that Python is written in C. One specific Python compiler happens to be
written in C, that is all.

Apart from IronPython, what constituency do these alternative
implementations of Python have that would raise them above the level of
interesting experiments?

 

[Littlefield, Tyler]

"Plonk" it if you want. Your homosexual ideologies have no effect on
me. Butt, back to the discussion, there are quite a few ways to
encode, as well as translate code.

You remind me of a little kid. When anything doesn't go your way, we
revert to homosexual comments (who said anything about homosexual
anyway), and you keep bringing up this whole nut hair deal. I think it's
you leaning that way buddy, especially since "most of us on here are guys."

Plonk it in your mouth, and let the nut hairs tickle your throat.

Take your trash somewhere else. You've provided nothing in terms of good feedback or responses, and I doubt you will provide more than insults.

PS: Anyone know if rantingrik had relatives?



--
Take care,
Ty
http://tds-solutions.net
The aspen project: a barebones light-weight mud engine:
http://code.google.com/p/aspenmud
He that will not reason is a bigot; he that cannot reason is a fool; he that dares not reason is a slave.

 

[Chris Angelico]

You are always selling the same argument.
Py3.3 is the only computer language I'm aware of which
is maltreating Unicode in such a way.

You mean, the only computer language that represents Unicode
characters as integers, and then stores them as an array of 8-bit,
16-bit, or 32-bit numbers depending on the highest codepoint? No, it's
not. I can disprove your statement with a single counterexample, but
it's entirely possible and (IMHO) likely that there are others too:

http://pike.lysator.liu.se/generated/manual/modref/ex/predef_3A_3A/String/width.html

Pike stores strings in largely the same way Python 3.3 does. Pike
strings are immutable and guaranteed to be interned, so it makes good
sense to store them as compactly as possible.

After all, if replacing a Nabla operator in a string take
10 times more times in Py33 than in Python32, it takes 10
times more . There is nothing more to say.

Comparing against a Py32 wide build, I find it hard to believe that
anything would take ten times as long. But I'll give you the benefit
of the doubt; maybe your number is in binary. I still do not expect
that it'd take twice as long. <voice imitate="Maxwell Smart">Would you
believe... barely slower?</voice> And even that's pushing it.

sigh... Why am I arguing this. I should get plonked myself for feeding
the trolls. Sorry all.

ChrisA

 

[Mark Lawrence]

PS: Anyone know if rantingrik had relatives?

I say steady on old chap that's just not cricket. I've been known to
have a go at rr in the past for good reasons, but when he gets stuck
into Tkinter he is an extremely useful contributor. I certainly prefer
him to Xah Lee, who's attempts at improving Python documentation were
beautifully torn to pieces here, IIRC by Ethan Furman, apologies to him
and the actual author if I'm incorrect.

 

[Chris Angelico]

I say steady on old chap that's just not cricket. I've been known to have a
go at rr in the past for good reasons, but when he gets stuck into Tkinter
he is an extremely useful contributor. I certainly prefer him to Xah Lee,
who's attempts at improving Python documentation were beautifully torn to
pieces here, IIRC by Ethan Furman, apologies to him and the actual author if
I'm incorrect.

You know how people sometimes ask "What sort of idiot do you think I
am??!?", thus falling foul of the sage advice "Never test for an error
condition you don't know how to handle" [1]... well, on this list, it
makes good sense to ask what sort of troll someone is. We even have
Troll Rankings in which there's very definite striations of "useful
contributors who sometimes troll", "useless people who nevertheless
trigger interesting threads", and "utterly useless flamers". Troll
taxonomy is a science we could all benefit from studying...

ChrisA

[1] eg http://www.theregister.co.uk/2008/10/24/bofh_2008_episode_34/

 

[wxjmfauth]

Le mercredi 26 septembre 2012 11:55:16 UTC+2, Chris Angelico a écrit :

We've been over this thread. The only reason you're counting 3.3 as

worse is because you're comparing against a narrow build of Python

3.2. Narrow builds are **BUGGY** and this needed to be resolved.



When you compare against a wide build, semantics of 3.2 and 3.3 are

identical, and then - and ONLY then - can you sanely compare

performance. And 3.3 stacks up much better.



ChrisA

No, I'm comparing Py33 with Py32 narrow build [*].
And I am not a Python newbie. Others in a previous
discussion have pointed "bad" numbers and even
TR wrote something like "I'm baffled (?) by these
numbers".

I took a look at the test suites, unfortunatelly
they are mainly testing "special cases", something
like one of the 3 internal representations, eg
"latin-1".

I can also add to this, that it is not only one
of the internal representation which may be
suspect (it is probably different now, Py32/Py33) but
also the "switch" between these representations
which is causing troubles.

[*] I have not the knowledge to compile a wide
build and I do not wish to spend my time in something
that will be most probably a nightmare for me.
I'm reacting like a "normal" Python user.

jmf

 

[wxjmfauth]

Le mercredi 26 septembre 2012 11:55:16 UTC+2, Chris Angelico a écrit :

We've been over this thread. The only reason you're counting 3.3 as

worse is because you're comparing against a narrow build of Python

3.2. Narrow builds are **BUGGY** and this needed to be resolved.



When you compare against a wide build, semantics of 3.2 and 3.3 are

identical, and then - and ONLY then - can you sanely compare

performance. And 3.3 stacks up much better.



ChrisA

No, I'm comparing Py33 with Py32 narrow build [*].
And I am not a Python newbie. Others in a previous
discussion have pointed "bad" numbers and even
TR wrote something like "I'm baffled (?) by these
numbers".

I took a look at the test suites, unfortunatelly
they are mainly testing "special cases", something
like one of the 3 internal representations, eg
"latin-1".

I can also add to this, that it is not only one
of the internal representation which may be
suspect (it is probably different now, Py32/Py33) but
also the "switch" between these representations
which is causing troubles.

[*] I have not the knowledge to compile a wide
build and I do not wish to spend my time in something
that will be most probably a nightmare for me.
I'm reacting like a "normal" Python user.

jmf

 

[Chris Angelico]

No, I'm comparing Py33 with Py32 narrow build [*].

Then look at the broken behaviour that Python, up until now, shared
with Javascript and various other languages, in which a one-character
string appears as two characters, and slicing and splicing strings can
split surrogates apart. The new rule is simple: One Unicode codepoint
takes up the space of one character. Anything else is mindbogglingly
counterintuitive.

ChrisA

 

[wxjmfauth]

I should add that I have not the knowledge to dive
in the Python code. But I "see" what has been done.
As I have a very good understanding of all this
coding of characters stuff, I can just pick up
- in fact select characters or combination
of characters - which I supspect to be problematic
and I see the results.

Not only this, I can select characters, I know
a user is supposed to use or will use eg. a specific
scrit/language, a typographical work, ...
(Do not ask how and why, I know this).

I'm not interesting in the other languages or in
unicode therory (also I not bad on this level).

I just see the results and the facts. For an end
user, this is the only thing that counts.

jmf

 

[wxjmfauth]

I should add that I have not the knowledge to dive
in the Python code. But I "see" what has been done.
As I have a very good understanding of all this
coding of characters stuff, I can just pick up
- in fact select characters or combination
of characters - which I supspect to be problematic
and I see the results.

Not only this, I can select characters, I know
a user is supposed to use or will use eg. a specific
scrit/language, a typographical work, ...
(Do not ask how and why, I know this).

I'm not interesting in the other languages or in
unicode therory (also I not bad on this level).

I just see the results and the facts. For an end
user, this is the only thing that counts.

jmf

 

[Chris Angelico]

I just see the results and the facts. For an end
user, this is the only thing that counts.

Then what counts is that Python 3.2 (like Javascript) exhibits
incorrect behaviour, and Python (like Pike) performs correctly.

I think this tee applies to you. http://www.thinkgeek.com/product/f147/

ChrisA
wouldn't have bothered to respond except that that link was asking to be shared

 

[Mark Lawrence]

I should add that I have not the knowledge to dive
in the Python code. But I "see" what has been done.
How?

As I have a very good understanding of all this
coding of characters stuff, I can just pick up
- in fact select characters or combination
of characters - which I supspect to be problematic
and I see the results.

Have you run the Python benchmarks yet, as people have more trust in
something tangible than a claim that "I see the results"? You were
asked to do this one month ago. If yes please publish your results. If
no why not, if your claims were correct running the benchmarks would
obviously support you?

Not only this, I can select characters, I know
a user is supposed to use or will use eg. a specific
scrit/language, a typographical work, ...
(Do not ask how and why, I know this).

Please state how and why.

I'm not interesting in the other languages or in
unicode therory (also I not bad on this level).

Please prove your statement in brackets, nothing less is acceptable if
you're making claims, you need to substantiate them.

I just see the results and the facts. For an end
user, this is the only thing that counts.

The modern day Pinball Wizard? Or a physic? Or what?

jmf

#pseudo code
for _ in range(-inf, +inf, 1): print(FUD)

 

[wxjmfauth]

Le mercredi 26 septembre 2012 16:56:55 UTC+2, Chris Angelico a écrit :

Then what counts is that Python 3.2 (like Javascript) exhibits

incorrect behaviour, and Python (like Pike) performs correctly.



I think this tee applies to you. http://www.thinkgeek.com/product/f147/



ChrisA

wouldn't have bothered to respond except that that link was asking to be shared

"You" have gained a broader range of unicode code points
and the same time you "broke" a correct BMP behaviour.

There is a simple solution to solve this. "You" do not wish
to use it.
Luckily for me, the tools I'm using use that one.

jmf

 

[wxjmfauth]

Le mercredi 26 septembre 2012 16:56:55 UTC+2, Chris Angelico a écrit :

Then what counts is that Python 3.2 (like Javascript) exhibits

incorrect behaviour, and Python (like Pike) performs correctly.



I think this tee applies to you. http://www.thinkgeek.com/product/f147/



ChrisA

wouldn't have bothered to respond except that that link was asking to be shared

"You" have gained a broader range of unicode code points
and the same time you "broke" a correct BMP behaviour.

There is a simple solution to solve this. "You" do not wish
to use it.
Luckily for me, the tools I'm using use that one.

jmf

 

[Chris Angelico]

for _ in range(-inf, +inf, 1): print(FUD)

That'll never work. Try this:

import itertools
list(map(print,itertools.cycle(('FUD',))))

ChrisA

 

[wxjmfauth]

Sorry guys, I'm "only" able to see this
(with the Python versions an end user can
download):
[31.44532887821319, 31.409585124813844, 31.40705548932476]
[323.56687741054805, 323.1660997337247, 325.52611455786905]
[31.48614883771855, 31.472262820580987, 31.467803762040184]
[320.55378064913526, 321.6890182785167, 321.4132045160866]

(Will wait for the final)

jmf

 

[wxjmfauth]

Sorry guys, I'm "only" able to see this
(with the Python versions an end user can
download):
[31.44532887821319, 31.409585124813844, 31.40705548932476]
[323.56687741054805, 323.1660997337247, 325.52611455786905]
[31.48614883771855, 31.472262820580987, 31.467803762040184]
[320.55378064913526, 321.6890182785167, 321.4132045160866]

(Will wait for the final)

jmf

 

[Ian Kelly]

For the first time in Python's history, Python on 32-bit systems handles
strings containing Supplementary Multilingual Plane characters correctly,
and it does so without doubling or quadrupling the amount of memory every
single string takes up.

Indeed. Here's an interesting article about Unicode handling that
identifies Python 3.3 as one of only four programming languages that
handle Unicode correctly (the other three being Bash, Haskell 98, and
Scheme R6RS).

http://unspecified.wordpress.com/20...e-of-language-level-abstract-unicode-strings/

 

[Ethan Furman]

I say steady on old chap that's just not cricket. I've been known to
have a go at rr in the past for good reasons, but when he gets stuck
into Tkinter he is an extremely useful contributor. I certainly prefer
him to Xah Lee, who's attempts at improving Python documentation were
beautifully torn to pieces here, IIRC by Ethan Furman, apologies to him
and the actual author if I'm incorrect.

I don't think it was me -- my troll tolerance is extremely low;
currently there are sixteen in my troll trap.

I could easily see it being D'Aprano, though -- he's excellent at
shredding ridiculous arguments and even seems to enjoy it. Least ways,
I enjoy reading his responses.

~Ethan~