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

2014-06-11 Thread alister
On Wed, 11 Jun 2014 08:29:06 +1000, Tim Delaney wrote: On 11 June 2014 05:43, alister alister.nospam.w...@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

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

2014-06-11 Thread Ben Finney
alister alister.nospam.w...@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

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

2014-06-11 Thread Michael Torrie
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. --

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

2014-06-10 Thread alister
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

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

2014-06-10 Thread Tim Delaney
On 11 June 2014 05:43, alister alister.nospam.w...@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

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

2014-06-10 Thread Mark Lawrence
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

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

2014-06-10 Thread Devin Jeanpierre
Please don't be unnecessarily cruel and antagonistic. -- Devin On Tue, Jun 10, 2014 at 4:16 PM, Mark Lawrence breamore...@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

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

2014-06-10 Thread Steven D'Aprano
On Tue, 10 Jun 2014 19:43:13 +, 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

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

2014-06-10 Thread Ethan Furman
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~ --

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

2014-06-10 Thread Mark Lawrence
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

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

2014-06-06 Thread Anssi Saari
Chris Angelico ros...@gmail.com writes: I don't have an actual use-case for this, as I don't target microcontrollers, but I'm curious: What parts of Py3 syntax aren't supported? I meant to say % formatting for strings but that's apparently been added recently. My previous micropython build

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

2014-06-06 Thread Travis Griggs
On Jun 4, 2014, at 4:01 AM, Tim Chase python.l...@tim.thechases.com 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. It’s universal, not prone to endian issues, etc. So one *advantage* you

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

2014-06-06 Thread Roy Smith
In article mailman.10822.1402073958.18130.python-l...@python.org, Travis Griggs travisgri...@gmail.com wrote: On Jun 4, 2014, at 4:01 AM, Tim Chase python.l...@tim.thechases.com wrote: If you use UTF-8 for everything It seems to me, that increasingly other libraries (C, etc), use utf8 as

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

2014-06-06 Thread Tim Chase
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

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

2014-06-05 Thread Roy Smith
In article f935e85f-f86a-4821-86ab-3ab7e5e21...@googlegroups.com, Rustom Mody rustompm...@gmail.com wrote: On Thursday, June 5, 2014 12:12:06 AM UTC+5:30, Roy Smith wrote: Yup. I wrote a while(*) back about the pain I was having importing some data into a MySQL(**) database Here's my

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

2014-06-05 Thread Chris Angelico
On Thu, Jun 5, 2014 at 11:59 PM, Roy Smith r...@panix.com wrote: It turns out, we could have upgraded to a newer version of MySQL, which did handle astral characters correctly. But, what we did was discarded the records containing non-BMP data. Of course, that's a decision that can only be

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

2014-06-04 Thread Ian Kelly
On Jun 3, 2014 11:27 PM, Steven D'Aprano st...@pearwood.info wrote: For technical reasons which I don't fully understand, Unicode only uses 21 of those 32 bits, giving a total of 1114112 available code points. I think mainly it's to accommodate UTF-16. The surrogate pair scheme is sufficient

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

2014-06-04 Thread Terry Reedy
On 6/4/2014 1:55 AM, Ian Kelly wrote: On Jun 3, 2014 11:27 PM, Steven D'Aprano st...@pearwood.info mailto:st...@pearwood.info wrote: For technical reasons which I don't fully understand, Unicode only uses 21 of those 32 bits, giving a total of 1114112 available code points. I think

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

2014-06-04 Thread Chris Angelico
On Wed, Jun 4, 2014 at 5:00 PM, Terry Reedy tjre...@udel.edu wrote: On 6/4/2014 1:55 AM, Ian Kelly wrote: On Jun 3, 2014 11:27 PM, Steven D'Aprano st...@pearwood.info mailto:st...@pearwood.info wrote: For technical reasons which I don't fully understand, Unicode only uses 21 of those 32

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

2014-06-04 Thread Chris Angelico
On Wed, Jun 4, 2014 at 2:40 PM, Rustom Mody rustompm...@gmail.com wrote: On Wednesday, June 4, 2014 9:22:54 AM UTC+5:30, Chris Angelico wrote: On Wed, Jun 4, 2014 at 1:37 PM, Rustom Mody wrote: And so a pure BMP-supporting implementation may be a reasonable compromise. [As long as no

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

2014-06-04 Thread Chris Angelico
On Wed, Jun 4, 2014 at 3:02 PM, Ian Kelly ian.g.ke...@gmail.com wrote: On Tue, Jun 3, 2014 at 10:40 PM, Rustom Mody rustompm...@gmail.com wrote: 1) Most or all Chinese and Japanese characters Dont know how you count 'most' | One possible rationale is the desire to limit the size of the full

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

2014-06-04 Thread Steven D'Aprano
On Wed, 04 Jun 2014 17:16:13 +1000, Chris Angelico wrote: On Wed, Jun 4, 2014 at 2:40 PM, Rustom Mody rustompm...@gmail.com wrote: On Wednesday, June 4, 2014 9:22:54 AM UTC+5:30, Chris Angelico wrote: On Wed, Jun 4, 2014 at 1:37 PM, Rustom Mody wrote: And so a pure BMP-supporting

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

2014-06-04 Thread Paul Rubin
Steven D'Aprano st...@pearwood.info writes: Maybe there's a use-case for a microcontroller that works in ISO-8859-5 natively, thus using only eight bits per character, That won't even make the Russians happy, since in Russia there are multiple incompatible legacy encodings. I've never

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

2014-06-04 Thread Wolfgang Maier
On 04.06.2014 09:16, Chris Angelico wrote: The point is not that you might be able to get away with sticking your head in the sand and wishing Unicode would just go away. Even if you can, it's not something Python 3 can ever do. Exactly. These endless discussions about different encodings

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

2014-06-04 Thread Robin Becker
On 04/06/2014 08:58, Paul Rubin wrote: Steven D'Aprano st...@pearwood.info writes: Maybe there's a use-case for a microcontroller that works in ISO-8859-5 natively, thus using only eight bits per character, That won't even make the Russians happy, since in Russia there are multiple

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

2014-06-04 Thread Tim Chase
On 2014-06-04 00:58, Paul Rubin wrote: Steven D'Aprano st...@pearwood.info writes: Maybe there's a use-case for a microcontroller that works in ISO-8859-5 natively, thus using only eight bits per character, That won't even make the Russians happy, since in Russia there are multiple

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

2014-06-04 Thread Robin Becker
On 04/06/2014 12:01, Tim Chase wrote: On 2014-06-04 00:58, Paul Rubin wrote: Steven D'Aprano st...@pearwood.info writes: Maybe there's a use-case for a microcontroller that works in ISO-8859-5 natively, thus using only eight bits per character, That won't even make the Russians happy, since

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

2014-06-04 Thread Marko Rauhamaa
Tim Chase python.l...@tim.thechases.com: On 2014-06-04 00:58, Paul Rubin wrote: I've never understood why not use UTF-8 for everything. If you use UTF-8 for everything, then you end up in a world where string-indexing (see ChrisA's other side thread on this topic) is no longer an O(1)

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

2014-06-04 Thread Marko Rauhamaa
Robin Becker ro...@reportlab.com: u'\xc5ngstr\xf6m'==u'\xc5ngstro\u0308m' False Now *that* would be a valid reason for our resident Unicode expert to complain! Py3 in no way solves text representation issues definitively. I know this is artificial Not at all. It probably is out of scope for

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

2014-06-04 Thread Tim Chase
On 2014-06-04 12:53, Robin Becker wrote: If you use UTF-8 for everything, then you end up in a world where string-indexing (see ChrisA's other side thread on this topic) is no longer an O(1) operation, but an O(N) operation. Some of us slice strings for a living. ;-) I believe

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

2014-06-04 Thread Tim Chase
On 2014-06-04 14:57, Marko Rauhamaa wrote: If you use UTF-8 for everything, then you end up in a world where string-indexing (see ChrisA's other side thread on this topic) is no longer an O(1) operation, but an O(N) operation. Most string operations are O(N) anyway. Besides, you could

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

2014-06-04 Thread Robin Becker
On 04/06/2014 13:17, Marko Rauhamaa wrote: . Note, for example, that Google manages to sort out issues like these. It sees past diacritics and even case ending. . I guess they must normalize all inputs to some standard form and then search / eigenvectorize on those. There are

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

2014-06-04 Thread Steven D'Aprano
On Wed, 04 Jun 2014 12:53:19 +0100, Robin Becker wrote: I believe that we should distinguish between glyph/character indexing and string indexing. Even in unicode it may be hard to decide where a visual glyph starts and ends. I assume most people would like to assign one glyph to one unicode,

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

2014-06-04 Thread Paul Rubin
Tim Chase python.l...@tim.thechases.com writes: As mentioned elsewhere, I've got a LOT of code that expects that string indexing is O(1) and rarely are those strings/offsets reused I'm streaming through customer/provider data files, so caching wouldn't do much good other than waste space and

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

2014-06-04 Thread Roy Smith
In article mailman.10673.1401853976.18130.python-l...@python.org, Chris Angelico ros...@gmail.com wrote: You can't ignore those. You might be able to say Well, my program will run slower if you throw these at it, but if you're going down that route, you probably want the full FSR and the

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

2014-06-04 Thread Rustom Mody
On Thursday, June 5, 2014 12:12:06 AM UTC+5:30, Roy Smith wrote: Chris Angelico wrote: You can't ignore those. You might be able to say Well, my program will run slower if you throw these at it, but if you're going down that route, you probably want the full FSR and the advantages it

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

2014-06-03 Thread Chris Angelico
On Tue, Jun 3, 2014 at 10:27 PM, Damien George damien.p.geo...@gmail.com wrote: - Supports almost full Python 3 syntax, including yield (compiles 99.99% of the Python 3 standard library). - It supports a growing subset of Python 3 types and operations. - Part of the Python 3 standard library

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

2014-06-03 Thread Steven D'Aprano
On Tue, 03 Jun 2014 13:27:11 +0100, Damien George wrote: Hi, We would like to announce Micro Python, an implementation of Python 3 optimised to have a low memory footprint. Fantastic! -- Steven D'Aprano http://import-that.dreamwidth.org/ --

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

2014-06-03 Thread Paul Sokolovsky
Hello, On Tue, 3 Jun 2014 23:11:46 +1000 Chris Angelico ros...@gmail.com wrote: On Tue, Jun 3, 2014 at 10:27 PM, Damien George damien.p.geo...@gmail.com wrote: - Supports almost full Python 3 syntax, including yield (compiles 99.99% of the Python 3 standard library). - It supports a

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

2014-06-03 Thread Chris Angelico
On Wed, Jun 4, 2014 at 2:49 AM, Paul Sokolovsky pmis...@gmail.com wrote: As can be seen from the dump above, MicroPython perfectly works on a Linux system, so we encourage any pythonista to touch a little bit of Python magic and give it a try! ;-) And we of course interested to get feedback

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

2014-06-03 Thread Paul Sokolovsky
Hello, On Wed, 4 Jun 2014 03:08:57 +1000 Chris Angelico ros...@gmail.com wrote: [] With that encouragement, I just cloned your repo and built it on amd64 Debian Wheezy. Works just fine! Except... I've just found one fairly major problem with your support of Python 3.x syntax. Your str type

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

2014-06-03 Thread Chris Angelico
On Wed, Jun 4, 2014 at 7:41 AM, Paul Sokolovsky pmis...@gmail.com wrote: Hello, On Wed, 4 Jun 2014 03:08:57 +1000 Chris Angelico ros...@gmail.com wrote: [] With that encouragement, I just cloned your repo and built it on amd64 Debian Wheezy. Works just fine! Except... I've just found one

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

2014-06-03 Thread Rustom Mody
On Wednesday, June 4, 2014 3:11:12 AM UTC+5:30, Paul Sokolovsky wrote: With that in mind, I, as many others, think that forcing Unicode bloat upon people by default is the most controversial feature of Python3. The reason is that you go very long way dealing with languages of the people of

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

2014-06-03 Thread Chris Angelico
On Wed, Jun 4, 2014 at 1:37 PM, Rustom Mody rustompm...@gmail.com wrote: 2. My casual/cursory reading of the contents of the SMP-planes suggests that the stuff there is are things like - egyptian hieroplyphics - mahjong characters - ancient greek musical symbols - alchemical symbols etc etc.

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

2014-06-03 Thread Rustom Mody
On Wednesday, June 4, 2014 9:22:54 AM UTC+5:30, Chris Angelico wrote: On Wed, Jun 4, 2014 at 1:37 PM, Rustom Mody wrote: And so a pure BMP-supporting implementation may be a reasonable compromise. [As long as no surrogate-pairs are there] Not if you're working on the internet. There are

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

2014-06-03 Thread Ian Kelly
On Tue, Jun 3, 2014 at 10:40 PM, Rustom Mody rustompm...@gmail.com wrote: 1) Most or all Chinese and Japanese characters Dont know how you count 'most' | One possible rationale is the desire to limit the size of the full | Unicode character set, where CJK characters as represented by

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

2014-06-03 Thread Steven D'Aprano
On Tue, 03 Jun 2014 20:37:27 -0700, Rustom Mody wrote: On Wednesday, June 4, 2014 3:11:12 AM UTC+5:30, Paul Sokolovsky wrote: With that in mind, I, as many others, think that forcing Unicode bloat upon people by default is the most controversial feature of Python3. The reason is that you go

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

2014-06-03 Thread Rustom Mody
On Wednesday, June 4, 2014 10:50:21 AM UTC+5:30, Steven D'Aprano wrote: On Tue, 03 Jun 2014 20:37:27 -0700, Rustom Mody wrote: And so a pure BMP-supporting implementation may be a reasonable compromise. [As long as no surrogate-pairs are there] At the cost on one extra bit, strings could