Le mardi 21 janvier 2014 18:34:44 UTC+1, Terry Reedy a écrit :
> On 1/21/2014 6:38 AM, Tim Chase wrote:
>
> > On 2014-01-21 00:00, xeysx...@gmail.com wrote:
>
> >> Well, I retired early, and I guess now I've got some spare time to
>
> >> learn about programming, which always seemed rather myster
Le mercredi 15 janvier 2014 13:13:36 UTC+1, Ned Batchelder a écrit :
>
> ... more than one codepoint makes up a grapheme ...
No
> In Unicode terms, an encoding is a mapping between codepoints and bytes.
No
jmf
--
https://mail.python.org/mailman/listinfo/python-list
Le lundi 13 janvier 2014 11:57:28 UTC+1, Chris Angelico a écrit :
> On Mon, Jan 13, 2014 at 9:38 PM, Steven D'Aprano
>
> wrote:
>
> > I think you are using "from __future__ import unicode_literals".
>
> > Otherwise, that cannot happen in Python 2.x.
>
> >
>
>
>
> Alas, not true.
>
>
>
>
Le lundi 13 janvier 2014 09:27:46 UTC+1, Thomas Rachel a écrit :
> Am 12.01.2014 08:50 schrieb wxjmfa...@gmail.com:
>
> sys.version
>
> > 2.7.6 (default, Nov 10 2013, 19:24:18) [MSC v.1500 32 bit (Intel)]
>
> s = 'Stra�e'
>
> assert len(s) == 6
>
> assert s[5] == 'e'
>
>
>>> sys.version
2.7.6 (default, Nov 10 2013, 19:24:18) [MSC v.1500 32 bit (Intel)]
>>> s = 'Straße'
>>> assert len(s) == 6
>>> assert s[5] == 'e'
>>>
jmf
--
https://mail.python.org/mailman/listinfo/python-list
Le jeudi 9 janvier 2014 19:49:27 UTC+1, Ethan Furman a écrit :
> So I'm working with postgres, and I get a datadump which I try to restore to
> my test system, and I get this:
>
>
>
> ERROR: value too long for type character varying(4)
>
> CONTEXT: COPY res_currency, line 32, column symbol:
Le mercredi 8 janvier 2014 20:00:02 UTC+1, Bischoop a écrit :
> Walter Hurry wrote:
>
>
>
> > On Mon, 30 Dec 2013 18:38:20 +, Bischoop wrote:
>
> >
>
> >> I have a txt file with some words, and need simply program that will
>
> >> print me words containing provided letters.
>
> >>
>
>
Le mercredi 8 janvier 2014 12:05:49 UTC+1, Robin Becker a écrit :
> On 07/01/2014 19:48, Serhiy Storchaka wrote:
>
>
>
> > data[0] == b'\xE1'[0] works as expected in both Python 2.7 and 3.x.
>
> >
>
> >
>
> I have been porting a lot of python 2 only code to a python2.7 + 3.3 version
Le mercredi 8 janvier 2014 01:02:22 UTC+1, Terry Reedy a écrit :
> On 1/7/2014 9:54 AM, Terry Reedy wrote:
>
> > On 1/7/2014 8:34 AM, wxjmfa...@gmail.com wrote:
>
> >> Le dimanche 5 janvier 2014 23:14:07 UTC+1, Terry Reedy a écrit :
>
> >
>
> >>> Memory: Point 2. A *design goal* of FSR was to s
Le dimanche 5 janvier 2014 23:14:07 UTC+1, Terry Reedy a écrit :
> On 1/5/2014 9:23 AM, wxjmfa...@gmail.com wrote:
>
> > Le samedi 4 janvier 2014 23:46:49 UTC+1, Terry Reedy a écrit :
>
> >> On 1/4/2014 2:10 PM, wxjmfa...@gmail.com wrote:
>
> >>> And I could add, I *never* saw once one soul, who
Le samedi 4 janvier 2014 23:46:49 UTC+1, Terry Reedy a écrit :
> On 1/4/2014 2:10 PM, wxjmfa...@gmail.com wrote:
>
> > Le samedi 4 janvier 2014 15:17:40 UTC+1, Chris Angelico a écrit :
>
>
>
> >> any, and Python has only one, idiot like jmf who completely
>
>
>
> Chris, I appreciate the many
Le dimanche 5 janvier 2014 03:54:29 UTC+1, Chris Angelico a écrit :
> On Sun, Jan 5, 2014 at 1:41 PM, Steven D'Aprano
>
> wrote:
>
> > wxjmfa...@gmail.com wrote:
>
> >
>
> >> The very interesting aspect in the way you are holding
>
> >> unicodes (strings). By comparing Python 2 with Python 3.
Le samedi 4 janvier 2014 15:17:40 UTC+1, Chris Angelico a écrit :
> On Sun, Jan 5, 2014 at 12:55 AM, Roy Smith wrote:
>
> > In article ,
>
> > Mark Lawrence wrote:
>
> >
>
> >> Surely everybody prefers fast but incorrect code in
>
> >> preference to something that is correct but slow?
>
>
Le vendredi 3 janvier 2014 12:14:41 UTC+1, Robin Becker a écrit :
> On 02/01/2014 18:37, Terry Reedy wrote:
>
> > On 1/2/2014 12:36 PM, Robin Becker wrote:
>
> >
>
> >> I just spent a large amount of effort porting reportlab to a version
>
> >> which works with both python2.7 and python3.3. I h
It's time to understand the Character Encoding Models
and the math behind it.
Unicode does not differ from any other coding scheme.
How? With a sheet of paper and a pencil.
jmf
--
https://mail.python.org/mailman/listinfo/python-list
Le vendredi 27 décembre 2013 12:37:17 UTC+1, Steven D'Aprano a écrit :
> tomasz.kaczo...@gmail.com wrote:
>
>
>
> > hello,
>
> > can I ask you for help? when I try to print s[0] i vane the message:
>
> > UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-1:
>
> > ordinal
Le lundi 23 décembre 2013 21:53:13 UTC+1, Terry Reedy a écrit :
> On 12/23/2013 2:05 PM, wxjmfa...@gmail.com wrote:
>
>
>
> > Le lundi 23 décembre 2013 18:59:41 UTC+1, Wolfgang Keller a écrit :
>
> >> [me]
>
> >>> I'll note that Python core developers do care about memory leaks.
>
> >> And th
Le lundi 23 décembre 2013 18:59:41 UTC+1, Wolfgang Keller a écrit :
> > > On an actual operating system, the attitude of the developers (do
>
> > > they actually care or just don't give a darn) is *the* critical
>
> > > issue for end-user productivity. If a developer makes a statement
>
> > > su
Le vendredi 20 décembre 2013 18:52:44 UTC+1, Martin Schöön a écrit :
> This thread hasn't been close to Python for while now and should
>
> be shut down. But, it is actually kind of interesting since you
>
> debate possible mechanisms behind the behaviour of my Windows box
>
> at work: "Not re
Le vendredi 20 décembre 2013 00:10:58 UTC+1, wmcb...@gmail.com a écrit :
> On Monday, December 16, 2013 10:58:06 PM UTC-5, Terry Reedy wrote:
>
>
> In this case, I already know that the glyphs I chose work with the default
> fonts for OS X 10.4+ and Windows 7+, but not for (for example) Win XP
Le jeudi 19 décembre 2013 09:25:14 UTC+1, Mark Lawrence a écrit :
> On 19/12/2013 08:10, wxjmfa...@gmail.com wrote:
>
>
>
> >
>
> > Same experience with PyQt4.
>
> >
>
> > Py 3.2 : PyQt4.QtCore.PYQT_VERSION_STR -> 4.8.6
>
> > Py 3.3 : PyQt4.QtCore.PYQT_VERSION_STR -> 4.10
>
> >
>
> > jmf
>
Le mardi 17 décembre 2013 20:00:14 UTC+1, wxjm...@gmail.com a écrit :
> Le mardi 17 décembre 2013 19:06:35 UTC+1, Michael Torrie a écrit :
>
> > On 12/17/2013 08:00 AM, Wolfgang Keller wrote:
>
> >
>
> > >> Python is sooo slow when it waits for the human.
>
> >
>
> > >
>
> >
>
> > >
Le mardi 17 décembre 2013 20:00:14 UTC+1, wxjm...@gmail.com a écrit :
> Le mardi 17 décembre 2013 19:06:35 UTC+1, Michael Torrie a écrit :
>
> > On 12/17/2013 08:00 AM, Wolfgang Keller wrote:
>
> >
>
> > >> Python is sooo slow when it waits for the human.
>
> >
>
> > >
>
> >
>
> > >
Le mardi 17 décembre 2013 19:06:35 UTC+1, Michael Torrie a écrit :
> On 12/17/2013 08:00 AM, Wolfgang Keller wrote:
>
> >> Python is sooo slow when it waits for the human.
>
> >
>
> > With Windows systems, I waste something like 90% of my work time waiting
>
> > for that system to stop "No
Addendum.
I should say, I had also a lot of fun in writing my own
"styling engine".
Because when one has to deal with a language, which does
not recognize its own keywords...
>>> 1and 444
444
>>>
tokenize.py could have been a solution, but it's really
too slow.
jmf
--
https://mail.python.org/
Le mardi 17 décembre 2013 14:03:03 UTC+1, Robert Kern a écrit :
> On 2013-12-17 11:13, Steven D'Aprano wrote:
>
> > On Tue, 17 Dec 2013 09:39:06 +, Mark Lawrence wrote:
>
> >
>
> >> Personally I am convinced that wxPython can't handle unicode for the
>
> >> simple reason that it doesn't yet
Le mardi 17 décembre 2013 10:29:28 UTC+1, Steven D'Aprano a écrit :
> On Mon, 16 Dec 2013 23:58:15 -0800, wxjmfauth wrote:
>
>
>
> > From all the toolkits, wxPython is probably the most interesting. I used
>
> > all versions from 2.0 (?) up to 2.8. Then it has b
Le mardi 17 décembre 2013 09:33:24 UTC+1, Mark Lawrence a écrit :
> On 17/12/2013 07:58, wxjmfa...@gmail.com wrote:
>
> > From all the toolkits, wxPython is probably the most
>
> > interesting. I used all versions from 2.0 (?) up to 2.8. Then
>
> > it has been decided to go unicode.
>
> >
>
>
From all the toolkits, wxPython is probably the most
interesting. I used all versions from 2.0 (?) up to 2.8. Then
it has been decided to go unicode.
Let see in the wx interactive intepreter, it is only
the top of the iceberg. (Py27, wxPy294)
>>> len('ሴЃ')
5
---
It has alos been decided to rewo
Le dimanche 15 décembre 2013 06:07:09 UTC+1, Terry Reedy a écrit :
> On 12/14/2013 9:39 PM, Steven D'Aprano wrote:
>
> > On Sat, 14 Dec 2013 13:43:41 -0500, Terry Reedy wrote:
>
> >
>
> >> This was reported by Victor Stinner as part of
>
> >> http://bugs.python.org/issue19914
>
> >> to explain
Le samedi 14 décembre 2013 19:43:41 UTC+1, Terry Reedy a écrit :
> On 12/14/2013 9:03 AM, wxjmfa...@gmail.com wrote:
>
>
>
> > D:\>chcp 65001
>
> > Page de codes active : 65001
>
> > D:\>echo "*"
>
> > "*"
>
>
>
> Try pasting *your* original echo command: echo "ሴé€㑖Ѓ⌴*"
>
>
>
> To repea
Le samedi 14 décembre 2013 00:30:38 UTC+1, Terry Reedy a écrit :
>
>
>
>
>
> What is not clear to me is whether Windows internally uses UCS-2, which
>
> only codes BMP chars, and which would *not* be excellent, or UTF-16,
>
> which covers all chars by using surrogates. I will guess the lat
Le vendredi 13 décembre 2013 19:32:58 UTC+1, Chris Angelico a écrit :
> On Sat, Dec 14, 2013 at 5:27 AM, wrote:
>
> > My guess is that you are referring to that
>
> > sentence "(With an excellent unicode coding scheme!)".
>
> > I do not need to cite anything. That's my opinion.
>
>
>
> Just
Le vendredi 13 décembre 2013 17:27:35 UTC+1, Chris Angelico a écrit :
> On Sat, Dec 14, 2013 at 3:15 AM, wrote:
>
> > One should recognize, with win7, MS, finally, produce
>
> > a full unicode system. Strangely, among all the "bashing"
>
> > one can read about that system, this is rarely menti
Le jeudi 12 décembre 2013 18:55:15 UTC+1, Terry Reedy a écrit :
>
>
>
>
>
> If you mean cp65xxx (I forget exact numbers), MS Command Prompt fails,
>
> not Python. One should not use any other code page, but only other code
>
> pages work.
>
>
>
-
Please, do not exaggerate too much
Le jeudi 12 décembre 2013 15:47:40 UTC+1, Chris Angelico a écrit :
> On Fri, Dec 13, 2013 at 1:34 AM, wrote:
>
> > Le jeudi 12 décembre 2013 11:28:35 UTC+1, Chris Angelico a écrit :
>
> >> On Thu, Dec 12, 2013 at 8:17 PM, wrote:
>
> >>
>
> >> > Windows, Py2.(7), ascii. It is not a secret Py
Le jeudi 12 décembre 2013 11:28:35 UTC+1, Chris Angelico a écrit :
> On Thu, Dec 12, 2013 at 8:17 PM, wrote:
>
> > Windows, Py2.(7), ascii. It is not a secret Python uses
>
> > ascii for the representation.
>
>
>
> Actually no, it doesn't.
>
>
>
> Python 2.7.4 (default, Apr 6 2013, 19:54
Le mercredi 11 décembre 2013 11:45:43 UTC+1, Chris Angelico a écrit :
> On Wed, Dec 11, 2013 at 7:43 PM, Chris Angelico wrote:
>
> > When you tell a story, it's important to engage the reader from the
>
> > start.
>
>
>
> On Wed, Dec 11, 2013 at 8:39 PM, wrote:
>
> > A few practical consid
A few practical considerations, far away from theoretical
aspects. Mainly for non ascii, understand non native English
speakers.
Python is an "ascii oriented product".
Platform. On Windows, the solely version which works
harmoniously with the system is Py 2.7 in a byte string
mode (ie non unicode
Rusi:
"unicode as a medium is universal in the same way that
ASCII used to be"
Probably, you do not realize deeply how this sentence
is correct. Unicode and ascii are constructed in the
same way. It has not even to do with "characters", but
with mathematics.
It is on this level the FSR fails. It
Le mardi 3 décembre 2013 15:26:45 UTC+1, Ethan Furman a écrit :
> On 12/02/2013 12:38 PM, Ethan Furman wrote:
>
> > On 11/29/2013 04:44 PM, Steven D'Aprano wrote:
>
> >>
>
> >> Out of the nine tests, Python 3.3 passes six, with three tests being
>
> >> failures or dubious. If you believe that t
Le mardi 3 décembre 2013 06:06:26 UTC+1, Steven D'Aprano a écrit :
> On Mon, 02 Dec 2013 16:14:13 -0500, Ned Batchelder wrote:
>
>
>
> > On 12/2/13 3:38 PM, Ethan Furman wrote:
>
> >> On 11/29/2013 04:44 PM, Steven D'Aprano wrote:
>
> >>>
>
> >>> Out of the nine tests, Python 3.3 passes six,
Le dimanche 1 décembre 2013 21:54:48 UTC+1, Tim Delaney a écrit :
> On 2 December 2013 07:15, wrote:
>
>
> 0.11.13 02:44, Steven D'Aprano написав(ла):
>
>
> > (2) If you reverse that string, does it give "lëon"? The implication of
>
> > this question is that strings should operate on graphem
0.11.13 02:44, Steven D'Aprano написав(ла):
> (2) If you reverse that string, does it give "lëon"? The implication of
> this question is that strings should operate on grapheme clusters rather
> than code points. ...
>
BTW, a grapheme cluster *is* a code points cluster.
jmf
--
https://mail.pyth
Le dimanche 1 décembre 2013 00:07:36 UTC+1, Ned Batchelder a écrit :
> On 11/30/13 5:37 PM, Gregory Ewing wrote:
>
> > wxjmfa...@gmail.com wrote:
>
> >> And do you know the origin of this typographical feature?
>
> >> Because, mechanically, the dot of the "i" broke too often.
>
> >>
>
> >> In
Le samedi 30 novembre 2013 03:08:49 UTC+1, Roy Smith a écrit :
>
>
>
> The whole idea of ligatures like fi is purely typographic. The crossbar
>
> on the "f" (at least in some fonts) runs into the dot on the "i".
>
> Likewise, the top curl on an "f" run into the serif on top of the "l"
>
Le lundi 25 novembre 2013 16:11:22 UTC+1, Michael Torrie a écrit :
> I only respond here, as unicode in general is an important concept that
>
> the OP will to make sure his students understand in Python, and I don't
>
> want you to dishonestly sow the seeds of uncertainty and doubt.
>
>
>
> O
Le samedi 23 novembre 2013 03:01:26 UTC+1, Steven D'Aprano a écrit :
>
>
>
> * Python 3 (although not Python 2) is one of the few languages that get
>
> Unicode *right*. Strings in Python 3 are text, sequences of Unicode
>
> characters, not a thinly disguised blob of bytes. Starting with Pyt
Le lundi 18 novembre 2013 14:31:33 UTC+1, Steven D'Aprano a écrit :
>
>
> ... choose one of the three bad choices: ...
>
>
>
> * choose UTF-16 or UTF-8, and have O(n) primitive string operations (like
>
> Haskell and, apparently, Ceylon);
>
>
>
> * or UTF-16 without support for the sup
character
Satisfied Interfaces: Comparable, Enumerable,
Ordinal
A 32-bit Unicode character.
Satisfied Interfaces: Category, Cloneable>, Collection,
Comparable, Correspondence, Iterable,
List, Ranged, Summable
string
Satisfied Interfaces: Category, Cloneable>, Collection,
Comparable, Corresponden
Le mercredi 13 novembre 2013 02:25:55 UTC+1, Terry Reedy a écrit :
> On 11/12/2013 1:25 PM, wxjmfa...@gmail.com wrote:
>
> > Le mardi 12 novembre 2013 03:11:48 UTC+1, Terry Reedy a écrit :
>
>
>
> >> with full discussion. (I know that you, Mark, could have found that, but
>
> >> not everyone r
Le mardi 12 novembre 2013 03:11:48 UTC+1, Terry Reedy a écrit :
> On 11/11/2013 4:41 PM, Mark Lawrence wrote:
>
> > From http://docs.python.org/dev/whatsnew/3.4.html#optimizations "The
>
> > UTF-32 decoder is now 3x to 4x faster.". Does anybody have any
>
> > references to this work? All I ca
>
>
> * Some languages are just fundamentally bad.
The flexible string representation is a perfect exemple.
Again, a short explanation:
This FSR splits unicode in chunks. Two immediate consequences:
- It's necessary to keep track of "each individual internal pieces of text".
- It's necessary
Le samedi 9 novembre 2013 01:46:32 UTC+1, Steven D'Aprano a écrit :
> On Fri, 08 Nov 2013 12:43:43 -0800, wxjmfauth wrote:
>
>
>
> > "(say, 1 kbyte each)": one "kilo" of characters or bytes?
>
> >
>
> > Glad to read some users ar
"(say, 1 kbyte each)": one "kilo" of characters or bytes?
Glad to read some users are still living in an ascii world,
at the "Unicode time" where an encoded code point size may vary
between 1-4 bytes.
Oops, sorry, I'm wrong, it can be much more.
>>> sys.getsizeof('ab')
27
>>> sys.getsizeof('a\
Le vendredi 1 novembre 2013 08:16:36 UTC+1, Steven D'Aprano a écrit :
> On Thu, 31 Oct 2013 03:33:15 -0700, wxjmfauth wrote:
>
>
>
> > Le jeudi 31 octobre 2013 08:10:18 UTC+1, Steven D'Aprano a écrit :
>
>
>
> >> I'm glad that yo
Le jeudi 31 octobre 2013 08:10:18 UTC+1, Steven D'Aprano a écrit :
> On Wed, 30 Oct 2013 01:49:28 -0700, wxjmfauth wrote:
>
>
>
> >> The right solution to that is to treat it no differently from other
>
> >> fuzzy
>
> >> searches. A good s
Le mercredi 30 octobre 2013 18:54:05 UTC+1, Michael Torrie a écrit :
> On 10/30/2013 10:08 AM, wxjmfa...@gmail.com wrote:
>
> > My comment had nothing to do with Python, it was a
>
> > general comment. A diacritical mark just makes a letter
>
> > a different letter; a "ï " and a "i" are "as
>
>
Le mercredi 30 octobre 2013 13:44:47 UTC+1, Ned Batchelder a écrit :
> On 10/30/13 4:49 AM, wxjmfa...@gmail.com wrote:
>
> > Le mardi 29 octobre 2013 06:24:50 UTC+1, Steven D'Aprano a écrit :
>
> >> On Mon, 28 Oct 2013 09:23:41 -0500, Tim Chase wrote:
>
> >>
>
> >>
>
> >>
>
> >>> On 2013-10-2
Le mardi 29 octobre 2013 06:24:50 UTC+1, Steven D'Aprano a écrit :
> On Mon, 28 Oct 2013 09:23:41 -0500, Tim Chase wrote:
>
>
>
> > On 2013-10-28 07:01, wxjmfa...@gmail.com wrote:
>
> >>> Simply ignoring diactrics won't get you very far.
>
> >>
>
> >> Right. As an example, these four French
Le mercredi 30 octobre 2013 03:17:21 UTC+1, Chris Angelico a écrit :
> On Wed, Oct 30, 2013 at 2:56 AM, Mark Lawrence
> wrote:
>
> > You've stated above that logically unicode is badly handled by the fsr. You
>
> > then provide a trivial timing example. WTF???
>
>
>
> His idea of bad handl
Le mardi 29 octobre 2013 16:52:49 UTC+1, Tim Chase a écrit :
> On 2013-10-29 08:38, wxjmfa...@gmail.com wrote:
>
> > >>> import timeit
>
> > >>> timeit.timeit("a = 'hundred'; 'x' in a")
>
> > 0.12621293837694095
>
> > >>> timeit.timeit("a = 'hundreij'; 'x' in a")
>
> > 0.26411553466961735
>
Le mardi 29 octobre 2013 06:22:27 UTC+1, Steven D'Aprano a écrit :
> On Mon, 28 Oct 2013 07:01:16 -0700, wxjmfauth wrote:
>
>
>
> > And of course, logically, they are very, very badly handled with the
>
> > Flexible String Representation.
>
>
>
&g
Le dimanche 27 octobre 2013 04:21:46 UTC+1, Nobody a écrit :
>
>
>
> Simply ignoring diactrics won't get you very far.
>
>
Right. As an example, these four French words :
cote, côte, coté, côté .
>
> Most languages which use diactrics have standard conversions, e.g.
>
> ö -> oe, which are
Le mardi 15 octobre 2013 23:00:29 UTC+2, Mark Lawrence a écrit :
> On 15/10/2013 21:11, wxjmfa...@gmail.com wrote:
>
> > Le lundi 14 octobre 2013 21:18:59 UTC+2, John Nagle a écrit :
>
> >
>
> >
>
> >
>
> > [...]
>
> >>
>
> >> No, Python went through the usual design screwups. Loo
Le lundi 14 octobre 2013 21:18:59 UTC+2, John Nagle a écrit :
[...]
>
> No, Python went through the usual design screwups. Look at how
>
> painful the slow transition to Unicode was, from just "str" to
>
> Unicode strings, ASCII strings, byte strings, byte arrays,
>
> 16 and 31 bit
Le mercredi 9 octobre 2013 08:20:05 UTC+2, Steven D'Aprano a écrit :
>
>
> > http://www.unicode.org/versions/Unicode6.2.0/ch02.pdf#G13708 "All three
>
> > encoding forms can be used to represent the full range of encoded
>
> > characters in the Unicode Standard; ... Each of the three Unicode
>
>>> sys.version
'3.3.2 (v3.3.2:d047928ae3f6, May 16 2013, 00:03:43) [MSC v.1600 32 bit (Intel)]'
>>> '\ud800'.encode('utf-8')
Traceback (most recent call last):
File "", line 1, in
UnicodeEncodeError: 'utf-8' codec can't encode character '\ud800' in position
0:
surrogates not allowed
Le mardi 24 septembre 2013 11:42:22 UTC+2, J. Bagg a écrit :
> I'm having trouble with the BOM that is now prepended to codecs files.
>
> The files have to be read by java servlets which expect a clean file
>
> without any BOM.
>
>
>
> Is there a way to stop the BOM being written?
>
>
>
>
>>> 1and 0
0
>>> 'a'or 1
'a'
>>> 5if True else 999
5
jmf
--
https://mail.python.org/mailman/listinfo/python-list
Le vendredi 6 septembre 2013 17:46:14 UTC+2, Piet van Oostrum a écrit :
> wxjmfa...@gmail.com writes:
>
>
>
> > The Flexible String Representation has conceptually to
>
> > face the same problem. It splits "unicode" in chunks and
>
> > it has to solve two problems at the same time, the coding
Short comment about the "detection" tools from a previous
discussion.
The tools supposed to detect the coding scheme are all
working with a simple logical mathematical rule:
p ==> q<==> non q ==> non p .
Shortly -- and consequence -- they do not detect a
coding scheme they only detect
Le mercredi 4 septembre 2013 10:01:50 UTC+2, Antoon Pardon a écrit :
> Op 03-09-13 17:23, wxjmfa...@gmail.com schreef:
>
>
>
> >
>
> >
>
> > The Latin alphabet uses Greek lettering.
>
> >
>
> > The Cyrillic alphabet uses Greek lettering.
>
> >
>
> > Greek: One should not confus
Le lundi 2 septembre 2013 16:44:34 UTC+2, MRAB a écrit :
> On 02/09/2013 13:24, Dave Angel wrote:
>
> > On 2/9/2013 07:56, MRAB wrote:
>
> >
>
> >> On 02/09/2013 12:38, Dave Angel wrote:
>
> >
>
> >
>
> >
>
> >>> ¶γνωστοόνομα συστήματος
>
> >>>
>
> >>> I don't have a clue what it migh
Le mercredi 28 août 2013 18:44:53 UTC+2, John Levine a écrit :
> I have a crufty old DNS provisioning system that I'm rewriting and I
>
> hope improving in python. (It's based on tinydns if you know what
>
> that is.)
>
>
>
> The record formats are, in the worst case, like this:
>
>
>
> fo
Le samedi 24 août 2013 18:47:19 UTC+2, David M. Cotter a écrit :
> > What _are_ you using?
>
> i have scripts in a file, that i am invoking into my embedded python within a
> C++ program. there is no terminal involved. the "print" statement has been
> redirected (via sys.stdout) to my custom
Le mardi 20 août 2013 09:55:44 UTC+2, Antoon Pardon a écrit :
> Op 20-08-13 09:31, wxjmfa...@gmail.com schreef:
>
> > Le mardi 20 août 2013 08:55:18 UTC+2, Antoon Pardon a écrit :
>
> >>
>
> >>>
>
> >>
>
> >
>
> >>
>
> >>
>
> >>
>
> >>> If you consider the implementation of sin and cos fu
Le mardi 20 août 2013 08:55:18 UTC+2, Antoon Pardon a écrit :
>
> >
>
>
>
>
> > If you consider the implementation of sin and cos functions, they usually
>
> > reduce the argument modulo π to something in the first quadrant, and then
>
> > use symmetry to adjust the value. So changing th
Le mardi 20 août 2013 07:48:37 UTC+2, Steven D'Aprano a écrit :
> On Mon, 19 Aug 2013 22:34:00 +0200, Antoon Pardon wrote:
>
>
>
> > Op 19-08-13 19:05, Steven D'Aprano schreef:
>
> >
>
> >
>
> >> I wish Python had stronger support for enforcing constantness, to whit,
>
> >> some way to say
Le dimanche 18 août 2013 01:30:14 UTC+2, Gregory Ewing a écrit :
> wxjmfa...@gmail.com wrote:
>
> > Na + Cl --> NaCl
>
> >
>
> > the chemist combines *one mole* of sodium and *one
>
> > mole* of chlorine to get *one mole* of sodium chloride
>
> >
>
> > It's independent of the number of
Le vendredi 16 août 2013 15:23:37 UTC+2, Roy Smith a écrit :
> In article <2d88bc0f-fdcb-4685-87ed-c17998dd3...@googlegroups.com>,
>
> wxjmfa...@gmail.com wrote:
>
>
>
> > A chemist has to work and is always working in mole; as his
>
> > balance can only measure a mass, the calculation mole <
-
A mole is an amount of matter measured in [kg] .
The Avogadro's number can only be a dimensionless number, [1] .
The Avogadro's constant is the Avogadro's number (of "pieces" or
"objects") per mol, [1 / mol].
A chemist has to work and is always working in mole; as his
balance can only measu
I perfectly knows what Python does.
I missinterpreting nothing.
I opened my example in binary mode just to show the real
endings.
It still remains the """...""" has its owns EOL and one
has to be aware of it.
No more, no less.
("""...""" and tokenize.py is funny)
jmf
--
http://mail.p
A technical ascpect of triple quoted strings is
that the "end of lines" are not respected.
>>> import zzz
>>> zzz.__doc__
'abc\ndef\n'
>>> with open('zzz.py', 'rb') as fo:
... r = fo.read()
...
>>> r
b'"""abc\r\ndef\r\n"""\r\n'
Now, one can argue...
jmf
--
http://mail.python.org/mailma
Le mercredi 14 août 2013 19:14:59 UTC+2, Chris Angelico a écrit :
> On Wed, Aug 14, 2013 at 6:05 PM, wrote:
>
> > On Wed, Aug 14, 2013, at 10:32, wxjmfa...@gmail.com wrote:
>
> >> I'm always and still be suprised by the number of hard coded
>
> >> '\n' one can find in Python code when the port
Le mercredi 14 août 2013 13:55:23 UTC+2, Joshua Landau a écrit :
> On 14 August 2013 12:45, Peter Otten <__pete...@web.de> wrote:
>
> > Joshua Landau wrote:
>
> >> On 14 August 2013 09:30, Alister wrote:
>
> >>> I would agree with the last statement.
>
> >>> Please write list definitions as li
Le dimanche 11 août 2013 11:09:44 UTC+2, Steven D'Aprano a écrit :
> On Sun, 11 Aug 2013 07:17:42 +0100, Joshua Landau wrote:
>
>
>
>
> The reason some accented letters have single code point forms is to
>
> support legacy charsets; ...
No.
jmf
PS Unicode normalization is failing expectedl
Le jeudi 8 août 2013 18:27:06 UTC+2, Kurt Mueller a écrit :
> Now I have this small example:
>
> --
>
> #!/usr/bin/env python
>
> # vim: set fileencoding=utf-8 :
>
>
>
> from __future__ import print_function
>
> import sys, shlex
>
>
Le jeudi 8 août 2013 22:29:00 UTC+2, Terry Reedy a écrit :
> On 8/8/2013 7:41 AM, Chris Angelico wrote:
>
> > On Thu, Aug 8, 2013 at 7:20 AM, wrote:
>
> > def z2():
>
> >> ... letters = 'abc'
>
> >> ... while True:
>
> >> ... c = input('letter: ')
>
> >> ... if c
I wrote many times on this list, the ascii (generic name for
"byte string") world and the unicode world are two incompatible
worlds. There are bridges, basically there are incompatible,
they requires to think differently.
There is an interesting case on the dev list:
http://mail.python.org/piperma
Le mercredi 7 août 2013 10:17:21 UTC+2, eschne...@comcast.net a écrit :
> I'm trying to create an option for the program to repeat if the user types
> 'y' or 'yes', using true and false values, or otherwise end the program. If
> anyone could explain to me how to get this code working, I'd appreci
Le samedi 3 août 2013 13:35:29 UTC+2, Nicholas a écrit :
> On Friday, 2 August 2013, Chris “Kwpolska” Warrick wrote:
>
>
> [snip]
>
>
>
> So, what are you feasting for? Nothing?
>
>
> I have long since ceased to be amazed at the number of people who would like
> their personal and arbitra
Le vendredi 2 août 2013 17:19:11 UTC+2, Skip Montanaro a écrit :
> > The solely valid solution, assuming there is some wish,
>
> > is to define a maximal line width (preferably in SI units ;-)
>
>
>
> So, 79 * 8 points == 0.22295696 meters, right? :-)
>
>
>
> Skip
You can correct your m
Le vendredi 2 août 2013 13:07:47 UTC+2, Chris “Kwpolska” Warrick a écrit :
> On Fri, Aug 2, 2013 at 2:51 AM, Roy Smith wrote:
>
> > In article ,
>
> > Terry Reedy wrote:
>
> >
>
> >> Newly revised this morning:
>
> >> http://www.python.org/dev/peps/pep-0008/#maximum-line-length
>
> >> summ
Le jeudi 1 août 2013 02:50:13 UTC+2, Chris Angelico a écrit :
> ...
> rather than OO/LibreOffice. (I'll not distinguish those two. Far as
>
> I'm concerned, they're one product with two names.)
...
Very interesting aspect in LibreOffice.
As the "center of gravity of the development" has move
Le mercredi 31 juillet 2013 07:45:18 UTC+2, Steven D'Aprano a écrit :
> On Tue, 30 Jul 2013 12:09:11 -0700, wxjmfauth wrote:
>
>
>
> > And do not forget, in a pure utf coding scheme, your char or a char will
>
> > *never* be larger than 4 bytes.
>
> >
FSR:
===
The 'a' in 'a€' and 'a\U0001d11e:
>>> ['{:#010b}'.format(c) for c in 'a€'.encode('utf-16-be')]
['0b', '0b0111', '0b0010', '0b10101100']
>>> ['{:#010b}'.format(c) for c in 'a\U0001d11e'.encode('utf-32-be')]
['0b', '0b', '0b', '0b0111',
'0b00
Matable, immutable, copyint + xxx, bufferint, O(n)
Yes, but conceptualy the reencoding happen sometime, somewhere.
The internal "ucs-2" will never automagically be transformed
into "ucs-4" (eg).
>>> timeit.timeit("'a'*1 +'€'")
7.087220684719967
>>> timeit.timeit("'a'*1 +'z'")
1.568521
Le dimanche 28 juillet 2013 05:53:22 UTC+2, Ian a écrit :
> On Sat, Jul 27, 2013 at 12:21 PM, wrote:
>
> > Back to utf. utfs are not only elements of a unique set of encoded
>
> > code points. They have an interesting feature. Each "utf chunk"
>
> > holds intrisically the character (in fact th
Le lundi 29 juillet 2013 16:49:34 UTC+2, Chris Angelico a écrit :
> On Mon, Jul 29, 2013 at 3:20 PM, wrote:
>
> >>c:\python32\pythonw -u "timitmod.py"
>
> > 15.258061416225663
>
> >>Exit code: 0
>
> >>c:\Python33\pythonw -u "timitmod.py"
>
> > 17.052203122286194
>
> >>Exit code: 0
>
>
>
101 - 200 of 328 matches
Mail list logo
