Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Article on the future of Python

Reply
Thread Tools

Article on the future of Python

 
 
Mark Lawrence
Guest
Posts: n/a
 
      09-26-2012
On 26/09/2012 14:01, Roy Smith wrote:
> In article <(E-Mail Removed)>,
> Hannu Krosing <(E-Mail Removed)> wrote:
>
>> You can get only so far using "sales". At some point you have to deliver.

>
> 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

--
Cheers.

Mark Lawrence.

 
Reply With Quote
 
 
 
 
Kevin Walzer
Guest
Posts: n/a
 
      09-26-2012
On 9/25/12 11:35 AM, Steven D'Aprano wrote:
> 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?

--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com
 
Reply With Quote
 
 
 
 
Littlefield, Tyler
Guest
Posts: n/a
 
      09-26-2012
On 9/26/2012 2:11 AM, Dwight Hutto wrote:
>>> Well, we can all use american as a standard, or maybe you'd prefer to
>>> borrow my Latin for Idiots handbook. But then again google has a
>>> Universal Communicator going, so, does it matter?

>> Never in the field of human discussion has there been so much reason
>> for so many to plonk so few.
>>

> "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?


>> ChrisA
>> --
>> http://mail.python.org/mailman/listinfo/python-list

>
>



--
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.

 
Reply With Quote
 
Chris Angelico
Guest
Posts: n/a
 
      09-26-2012
On Wed, Sep 26, 2012 at 10:19 PM, <(E-Mail Removed)> wrote:
> 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...ing/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
 
Reply With Quote
 
Mark Lawrence
Guest
Posts: n/a
 
      09-26-2012
On 26/09/2012 14:31, Littlefield, Tyler wrote:

>
> 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.

--
Cheers.

Mark Lawrence.

 
Reply With Quote
 
Chris Angelico
Guest
Posts: n/a
 
      09-26-2012
On Wed, Sep 26, 2012 at 11:43 PM, Mark Lawrence <(E-Mail Removed)> wrote:
> On 26/09/2012 14:31, Littlefield, Tyler wrote:
>
>>
>> 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.


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...08_episode_34/
 
Reply With Quote
 
wxjmfauth@gmail.com
Guest
Posts: n/a
 
      09-26-2012
Le mercredi 26 septembre 2012 11:55:16 UTC+2, Chris Angelico a écrit*:
> On Wed, Sep 26, 2012 at 7:31 PM, <(E-Mail Removed)> wrote:
>
> > you are correct. But the price you pay for this is extremely

>
> > high. Now, practically all characters are affected, espacially

>
> > those *in* the Basic *** Multilingual*** Plane, these characters

>
> > used by non "American" user (No offense here, I just use this

>
> > word for ascii/latin-1).

>
> >

>
> > I'm ready to be considered as an idiot, but I'm not blind.

>
> > As soon as I tested these characters, Py3.3 performs really

>
> > badly. It seems to me it is legitimate to consider, there

>
> > is a serious problem here.

>
>
>
> 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

 
Reply With Quote
 
wxjmfauth@gmail.com
Guest
Posts: n/a
 
      09-26-2012
Le mercredi 26 septembre 2012 11:55:16 UTC+2, Chris Angelico a écrit*:
> On Wed, Sep 26, 2012 at 7:31 PM, <(E-Mail Removed)> wrote:
>
> > you are correct. But the price you pay for this is extremely

>
> > high. Now, practically all characters are affected, espacially

>
> > those *in* the Basic *** Multilingual*** Plane, these characters

>
> > used by non "American" user (No offense here, I just use this

>
> > word for ascii/latin-1).

>
> >

>
> > I'm ready to be considered as an idiot, but I'm not blind.

>
> > As soon as I tested these characters, Py3.3 performs really

>
> > badly. It seems to me it is legitimate to consider, there

>
> > is a serious problem here.

>
>
>
> 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

 
Reply With Quote
 
Chris Angelico
Guest
Posts: n/a
 
      09-26-2012
On Thu, Sep 27, 2012 at 12:19 AM, <(E-Mail Removed)> wrote:
> 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
 
Reply With Quote
 
wxjmfauth@gmail.com
Guest
Posts: n/a
 
      09-26-2012
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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: Article on the future of Python Michael Harleman Python 0 09-25-2012 10:51 AM
Re: Calling a Perl Module from Python ( future direction of Python) Steve Holden Python 1 04-07-2005 02:44 PM
Re: Calling a Perl Module from Python ( future direction of Python) gf gf Python 5 04-07-2005 02:09 PM
Toward Python's future article daniel narf Python 3 10-08-2004 05:18 AM
My future Python IDE article David Mertz Python 41 09-13-2003 02:25 PM



Advertisments