Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #73118 > unrolled thread

Re: Micro Python -- a lean and efficient implementation of Python 3

Back to article view | Back to comp.lang.python

Contents

  Re: Micro Python -- a lean and efficient implementation of Python 3 alister <alister.nospam.ware@ntlworld.com> - 2014-06-10 19:43 +0000
    Re: Micro Python -- a lean and efficient implementation of Python 3 Tim Delaney <timothy.c.delaney@gmail.com> - 2014-06-11 08:29 +1000
      Re: Micro Python -- a lean and efficient implementation of Python 3 alister <alister.nospam.ware@ntlworld.com> - 2014-06-11 08:14 +0000
        Re: Micro Python -- a lean and efficient implementation of Python 3 Ben Finney <ben@benfinney.id.au> - 2014-06-11 21:37 +1000
        Re: Micro Python -- a lean and efficient implementation of Python 3 wxjmfauth@gmail.com - 2014-06-11 05:30 -0700
    Re: Micro Python -- a lean and efficient implementation of Python 3 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-06-11 00:16 +0100
    Re: Micro Python -- a lean and efficient implementation of Python 3 Devin Jeanpierre <jeanpierreda@gmail.com> - 2014-06-10 16:29 -0700
    Re: Micro Python -- a lean and efficient implementation of Python 3 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-11 00:04 +0000
      Re: Micro Python -- a lean and efficient implementation of Python 3 wxjmfauth@gmail.com - 2014-06-11 22:50 -0700
    Re: Micro Python -- a lean and efficient implementation of Python 3 Ethan Furman <ethan@stoneleaf.us> - 2014-06-10 16:49 -0700
    Re: Micro Python -- a lean and efficient implementation of Python 3 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-06-11 02:01 +0100
    Re: Micro Python -- a lean and efficient implementation of Python 3 wxjmfauth@gmail.com - 2014-06-11 00:40 -0700
    Re: Micro Python -- a lean and efficient implementation of Python 3 Michael Torrie <torriem@gmail.com> - 2014-06-11 09:38 -0600
      Re: Micro Python -- a lean and efficient implementation of Python 3 wxjmfauth@gmail.com - 2014-06-11 11:12 -0700

#73118 — Re: Micro Python -- a lean and efficient implementation of Python 3

On Tue, 10 Jun 2014 12:27:26 -0700, wxjmfauth wrote:

> Le samedi 7 juin 2014 04:20:22 UTC+2, Tim Chase a écrit :
>> On 2014-06-06 09:59, Travis Griggs wrote:
>> 
>> > On Jun 4, 2014, at 4:01 AM, Tim Chase wrote:
>> 
>> > > If you use UTF-8 for everything
>> 
>> 
>> > 
>> > It seems to me, that increasingly other libraries (C, etc), use
>> 
>> > utf8 as the preferred string interchange format.
>> 
>> 
>> 
>> I definitely advocate UTF-8 for any streaming scenario, as you're
>> 
>> iterating unidirectionally over the data anyways, so why use/transmit
>> 
>> more bytes than needed.  The only failing of UTF-8 that I've found in
>> 
>> the real world(*) is when you have to requirement of constant-time
>> 
>> indexing into strings.
>> 
>> 
>> 
>> -tkc
> 
> And once again, just an illustration,
> 
>>>> timeit.repeat("(x*1000 + y)", setup="x = 'abc'; y = 'z'")
> [0.9457552436453511, 0.9190932610143818, 0.9322044912393039]
>>>> timeit.repeat("(x*1000 + y)", setup="x = 'abc'; y = '\u0fce'")
> [2.5541921791045183, 2.52434366066052, 2.5337417948967413]
>>>> timeit.repeat("(x*1000 + y)", setup="x = 'abc'.encode('utf-8'); y =
>>>> 'z'.encode('utf-8')")
> [0.9168235779232532, 0.8989583403075017, 0.8964204541650247]
>>>> timeit.repeat("(x*1000 + y)", setup="x = 'abc'.encode('utf-8'); y =
>>>> '\u0fce'.encode('utf-8')")
> [0.9320969737165115, 0.9086006535332558, 0.9051715140790861]
>>>> 
>>>> 
>>>> sys.getsizeof('abc'*1000 + '\u0fce')
> 6040
>>>> sys.getsizeof(('abc'*1000 + '\u0fce').encode('utf-8'))
> 3020
>>>>
>>>>
> 
> But you know, that's not the problem.
> 
> When a see a core developper discussing benchmarking,
> when the same application using non ascii chars become 1, 2, 5, 10, 20
> if not more, slower comparing to pure ascii, I'm wondering if there is
> not a serious problem somewhere.
> 
> (and also becoming slower that Py3.2)
> 
> BTW, very easy to explain.
> 
> I do not understand why the "free, open, what-you-wish-here, ... "
> software is so often pushing to the adoption of serious corporate
> products.
> 
> jmf

Your error reports always seem to resolve around benchmarks despite speed 
not being one of Pythons prime objectives

Computers store data using bytes
ASCII Characters can be used storing a single byte
Unicode code-points cannot be stored in a single byte
therefore Unicode will always be inherently slower than ASCII

implementation details mean that some Unicode characters may be handled 
more efficiently than others, why is this wrong?
why should all Unicode operations be equally slow?



-- 
There isn't any problem

[toc] | [next] | [standalone]

#73137

[Multipart message — attachments visible in raw view] — view raw

On 11 June 2014 05:43, alister <alister.nospam.ware@ntlworld.com> wrote:

>
> Your error reports always seem to resolve around benchmarks despite speed
> not being one of Pythons prime objectives
>

By his own admission, jmf doesn't use Python anymore. His only reason to
remain on this emailing/newsgroup is to troll about the FSR. Please don't
reply to him (and preferably add him to your killfile).

Tim Delaney

[toc] | [prev] | [next] | [standalone]

#73158

On Wed, 11 Jun 2014 08:29:06 +1000, Tim Delaney wrote:

> On 11 June 2014 05:43, alister <alister.nospam.ware@ntlworld.com> wrote:
> 
> 
>> Your error reports always seem to resolve around benchmarks despite
>> speed not being one of Pythons prime objectives
>>
>>
> By his own admission, jmf doesn't use Python anymore. His only reason to
> remain on this emailing/newsgroup is to troll about the FSR. Please
> don't reply to him (and preferably add him to your killfile).
> 

I couldn't kill file JMF I find his posts useful
Every time i find myself agreeing with him I know I have got it wrong.



-- 
The nice thing about Windows is - It does not just crash, it displays a
dialog box and lets you press 'OK' first.

[toc] | [prev] | [next] | [standalone]

#73164

alister <alister.nospam.ware@ntlworld.com> writes:

> On Wed, 11 Jun 2014 08:29:06 +1000, Tim Delaney wrote:
> > By his own admission, jmf doesn't use Python anymore. His only
> > reason to remain on this emailing/newsgroup is to troll about the
> > FSR. Please don't reply to him (and preferably add him to your
> > killfile).
>
> I couldn't kill file JMF I find his posts useful

That's fine, kill-filing his posts is a matter that affects only you.

But please do not reply to them, nor taunt him in unrelated posts; it
disrupts this forum.
Instead, give him no reason to think anyone is interested.

-- 
 \     “Too many pieces of music finish too long after the end.” —Igor |
  `\                                                       Stravinskey |
_o__)                                                                  |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#73166

Le mercredi 11 juin 2014 10:14:02 UTC+2, alister a écrit :
> On Wed, 11 Jun 2014 08:29:06 +1000, Tim Delaney wrote:
> 
> 
> 
> > On 11 June 2014 05:43, alister <alister.nospam.ware@ntlworld.com> wrote:
> 
> > 
> 
> > 
> 
> >> Your error reports always seem to resolve around benchmarks despite
> 
> >> speed not being one of Pythons prime objectives
> 
> >>
> 
> >>
> 
> > By his own admission, jmf doesn't use Python anymore. His only reason to
> 
> > remain on this emailing/newsgroup is to troll about the FSR. Please
> 
> > don't reply to him (and preferably add him to your killfile).
> 
> > 
> 
> 
> 
> I couldn't kill file JMF I find his posts useful
> 
> Every time i find myself agreeing with him I know I have got it wrong.
> 
> 
> 
> 
> 
> 
> 
> -- 
> 
> The nice thing about Windows is - It does not just crash, it displays a
> 
> dialog box and lets you press 'OK' first.

%%%%%%%%%%

There are good books, but not too many, explaining
the coding of characters and unicode, unfortunately
thick and expansive.

The Unicode.org doc is - per definition - excellent. It
suffers from one point: it is dry, it explains the "how"
but not the "why". And it assumes the coding of characters
is already known!

A very interesting source is not in pure computing
stuff, it is to find in the literature speaking
about languages, scripts, ... (I can almost say,
it is always a little bit the same story, much
better to have linguists with computing knowledge
that computer scientits attempting to understand
scripting and languages. Same problem in science.)

On the web, well, be extremly careful.

Unicode and iso-14*** have been mainly created
by linguists, and later... comes the *x world :-(

jmf

[toc] | [prev] | [next] | [standalone]

#73139

On 10/06/2014 20:43, alister wrote:
> On Tue, 10 Jun 2014 12:27:26 -0700, wxjmfauth wrote:
>

[snip the garbage]

>>
>> jmf
>
> Your error reports always seem to resolve around benchmarks despite speed
> not being one of Pythons prime objectives
>
> Computers store data using bytes
> ASCII Characters can be used storing a single byte
> Unicode code-points cannot be stored in a single byte
> therefore Unicode will always be inherently slower than ASCII
>
> implementation details mean that some Unicode characters may be handled
> more efficiently than others, why is this wrong?
> why should all Unicode operations be equally slow?
>

I'd like to dedicate a song to jmf.  From the "Canterbury Sound" band 
Caravan, the album "The Battle Of Hastings", the song title "Liar".

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

[toc] | [prev] | [next] | [standalone]

#73140

Please don't be unnecessarily cruel and antagonistic.

-- Devin

On Tue, Jun 10, 2014 at 4:16 PM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
> On 10/06/2014 20:43, alister wrote:
>>
>> On Tue, 10 Jun 2014 12:27:26 -0700, wxjmfauth wrote:
>>
>
> [snip the garbage]
>
>
>>>
>>> jmf
>>
>>
>> Your error reports always seem to resolve around benchmarks despite speed
>> not being one of Pythons prime objectives
>>
>> Computers store data using bytes
>> ASCII Characters can be used storing a single byte
>> Unicode code-points cannot be stored in a single byte
>> therefore Unicode will always be inherently slower than ASCII
>>
>> implementation details mean that some Unicode characters may be handled
>> more efficiently than others, why is this wrong?
>> why should all Unicode operations be equally slow?
>>
>
> I'd like to dedicate a song to jmf.  From the "Canterbury Sound" band
> Caravan, the album "The Battle Of Hastings", the song title "Liar".
>
> --
> 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

[toc] | [prev] | [next] | [standalone]

#73142

On Tue, 10 Jun 2014 19:43:13 +0000, alister wrote:

> On Tue, 10 Jun 2014 12:27:26 -0700, wxjmfauth wrote:

Please don't feed the troll.

I don't know whether JMF is trolling or if he is a crank who doesn't 
understand what he is doing, but either way he's been trying to square 
this circle for the last couple of years. He believes, or *claims* to 
believe, that a performance regression (one which others cannot 
replicate) is *mathematical proof* that Python's Unicode handling is 
invalid. What can one say to crack-pottery of this magnitude?

Just kill-file his posts and be done.



-- 
Steven D'Aprano
http://import-that.dreamwidth.org/

[toc] | [prev] | [next] | [standalone]

#73206

Le mercredi 11 juin 2014 02:04:53 UTC+2, Steven D'Aprano a écrit :
> On Tue, 10 Jun 2014 19:43:13 +0000, alister wrote:
> 
> 
> 
> > On Tue, 10 Jun 2014 12:27:26 -0700, wxjmfauth wrote:
> 
> 
> 
> Please don't feed the troll.
> 
> 
> 
> I don't know whether JMF is trolling or if he is a crank who doesn't 
> 
> understand what he is doing, but either way he's been trying to square 
> 
> this circle for the last couple of years. He believes, or *claims* to 
> 
> believe, that a performance regression (one which others cannot 
> 
> replicate) is *mathematical proof* that Python's Unicode handling is 
> 
> invalid. What can one say to crack-pottery of this magnitude?
> 
> 
> 
> Just kill-file his posts and be done.
> 
> 
> 
> 
> 
> 
> 
> -- 
> 
> Steven D'Aprano
> 
> http://import-that.dreamwidth.org/

==========

Coding of characters and math: sets, operators, logic,
relation (bijection, [injection, surjection]). These
are the relavant parts.

Explained in every serious book about that subject,
and even indirectly in Unicode.org.

jmf

[toc] | [prev] | [next] | [standalone]

#73145

On 06/10/2014 04:29 PM, Devin Jeanpierre wrote:
>
> Please don't be unnecessarily cruel and antagonistic.

I completely agree.  jmf should leave us alone and stop cruelly and antagonizingly baiting us with stupidity and falsehoods.

--
~Ethan~

[toc] | [prev] | [next] | [standalone]

#73149

On 11/06/2014 00:29, Devin Jeanpierre wrote:
> Please don't be unnecessarily cruel and antagonistic.
>
> -- Devin

I am simply giving our resident unicode expert a taste of his own 
medicine.  If you don't like that complain to the PSF about the root 
cause of the problem, not the symptoms.

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

[toc] | [prev] | [next] | [standalone]

#73155

Le mardi 10 juin 2014 21:43:13 UTC+2, alister a écrit :
> On Tue, 10 Jun 2014 12:27:26 -0700, wxjmfauth wrote:
> 
> 
> 
> > Le samedi 7 juin 2014 04:20:22 UTC+2, Tim Chase a écrit :
> 
> >> On 2014-06-06 09:59, Travis Griggs wrote:
> 
> >> 
> 
> >> > On Jun 4, 2014, at 4:01 AM, Tim Chase wrote:
> 
> >> 
> 
> >> > > If you use UTF-8 for everything
> 
> >> 
> 
> >> 
> 
> >> > 
> 
> >> > It seems to me, that increasingly other libraries (C, etc), use
> 
> >> 
> 
> >> > utf8 as the preferred string interchange format.
> 
> >> 
> 
> >> 
> 
> >> 
> 
> >> I definitely advocate UTF-8 for any streaming scenario, as you're
> 
> >> 
> 
> >> iterating unidirectionally over the data anyways, so why use/transmit
> 
> >> 
> 
> >> more bytes than needed.  The only failing of UTF-8 that I've found in
> 
> >> 
> 
> >> the real world(*) is when you have to requirement of constant-time
> 
> >> 
> 
> >> indexing into strings.
> 
> >> 
> 
> >> 
> 
> >> 
> 
> >> -tkc
> 
> > 
> 
> > And once again, just an illustration,
> 
> > 
> 
> >>>> timeit.repeat("(x*1000 + y)", setup="x = 'abc'; y = 'z'")
> 
> > [0.9457552436453511, 0.9190932610143818, 0.9322044912393039]
> 
> >>>> timeit.repeat("(x*1000 + y)", setup="x = 'abc'; y = '\u0fce'")
> 
> > [2.5541921791045183, 2.52434366066052, 2.5337417948967413]
> 
> >>>> timeit.repeat("(x*1000 + y)", setup="x = 'abc'.encode('utf-8'); y =
> 
> >>>> 'z'.encode('utf-8')")
> 
> > [0.9168235779232532, 0.8989583403075017, 0.8964204541650247]
> 
> >>>> timeit.repeat("(x*1000 + y)", setup="x = 'abc'.encode('utf-8'); y =
> 
> >>>> '\u0fce'.encode('utf-8')")
> 
> > [0.9320969737165115, 0.9086006535332558, 0.9051715140790861]
> 
> >>>> 
> 
> >>>> 
> 
> >>>> sys.getsizeof('abc'*1000 + '\u0fce')
> 
> > 6040
> 
> >>>> sys.getsizeof(('abc'*1000 + '\u0fce').encode('utf-8'))
> 
> > 3020
> 
> >>>>
> 
> >>>>
> 
> > 
> 
> > But you know, that's not the problem.
> 
> > 
> 
> > When a see a core developper discussing benchmarking,
> 
> > when the same application using non ascii chars become 1, 2, 5, 10, 20
> 
> > if not more, slower comparing to pure ascii, I'm wondering if there is
> 
> > not a serious problem somewhere.
> 
> > 
> 
> > (and also becoming slower that Py3.2)
> 
> > 
> 
> > BTW, very easy to explain.
> 
> > 
> 
> > I do not understand why the "free, open, what-you-wish-here, ... "
> 
> > software is so often pushing to the adoption of serious corporate
> 
> > products.
> 
> > 
> 
> > jmf
> 
> 
> 
> Your error reports always seem to resolve around benchmarks despite speed 
> 
> not being one of Pythons prime objectives
> 
> 
> 
> Computers store data using bytes
> 
> ASCII Characters can be used storing a single byte
> 
> Unicode code-points cannot be stored in a single byte
> 
> therefore Unicode will always be inherently slower than ASCII
> 
> 
> 
> implementation details mean that some Unicode characters may be handled 
> 
> more efficiently than others, why is this wrong?
> 
> why should all Unicode operations be equally slow?
> 
> 
> 
> 
> 
> 
> 
> -- 
> 
> There isn't any problem

%%%%%%%%

The point is elsewhere.

1) In unicode, ascii does not exist. "ascii" only means a
reference to the "characters" of the ascii coding scheme.

2) Python 32, 33, 34.

Python 33 is optimizing ascii comparing to py32 (memcopy, ...),
but if the gain of the performance level is, let say, a factor
n, the loss of perfomance in non-ascii range is let say
(m * n) with m >>> 1.

Comparing 33 and 34 is very interesting. A lot of work
has been done, but what has been gained in some "methods",
has been lost, couterbalanced, on other sides. What is wrong
by design will always stay wrong by design. (I patiently
waited for py34, and what I expected just happend!).

Again an *illustration* (with a BDFL example who is not
happy about the Python performance!).
The following summarizes a little bit the situation.

py32:

>>> timeit.timeit("a = 'hundred'; 'x' in a")
0.09113662222722835
>>> timeit.timeit("a = 'hundre EURO'; 'x' in a")
0.1029297261915687

py33:
timeit.timeit("a = 'hundred'; 'x' in a")
0.12081905832395669
timeit.timeit("a = 'hundre EURO'; 'x' in a")
0.2453480765512026

Ditto for py34

Not only py33+ is worth than py33-. The situation
is even "more worse than worth" with non ascii chars.

The memory situation is not better.

py33
>>> sys.getsizeof('a')
26
>>> sys.getsizeof('EURO')
40
>>> sys.getsizeof('\U00010000')
44

This is very easy to explain with a sheet of paper
and a pencil (should I write a blackboard and
a piece of chalk?).

----

I'm still using Python, it just becomes the best tool
to illustrate unicode! (when it is not failing or
crashing).

Do not blame me, if I do not recommend Python and
if I'm using Python a demonstration tool, it is
impossible to find something worse when it comes
to unicode handling.

There are plenty of other very bad side effects
(prerequisite stuff: a good undestanding of the
coding of characters and unicode).

When I see all these links pointing to wikipedia
or other sites, and practically never on the
unicode.org ...

I'm optimistic, py devs will never put their
fingers in a TeX unicode engine, how could
it be? ;-)

I'm observing all this stuff from a unicode perspective.
Nothing wrong. Hobbyist tools will always stay hobbyist
tools.

jmf

[toc] | [prev] | [next] | [standalone]

#73178

On 06/10/2014 01:43 PM, alister wrote:
> On Tue, 10 Jun 2014 12:27:26 -0700, wxjmfauth wrote:
>> BTW, very easy to explain.

Yeah he keeps saying that, but he never does explain--just flails around
and mumbles "unicode.org."  Guess everyone has to have his or her
windmill to tilt at.

[toc] | [prev] | [next] | [standalone]

#73184

Le mercredi 11 juin 2014 17:38:33 UTC+2, Michael Torrie a écrit :
> On 06/10/2014 01:43 PM, alister wrote:
> 
> > On Tue, 10 Jun 2014 12:27:26 -0700, wxjmfauth wrote:
> 
> >> BTW, very easy to explain.
> 
> 
> 
> Yeah he keeps saying that, but he never does explain--just flails around
> 
> and mumbles "unicode.org."  Guess everyone has to have his or her
> 
> windmill to tilt at.

=========

Did you ever attempt once to reproduce my examples?

So that, you can at least even reply "Sorry, I do not see
this on my platform."

jmf

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web