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
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
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.
--
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
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
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
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
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
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~
--
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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)
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
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
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
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
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,
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
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
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
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
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/
--
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
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
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
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
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
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.
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
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
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
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
48 matches
Mail list logo