On 20 mar, 11:29, jmfauth wrote:
> On 20 mar, 10:30, Phil Thompson wrote:
-
>
>
> Strangely, I had not problem (if I recall correctly) with a
> very basic application (QMainWindow + QLineEdit).
ADDENDUM, CORRECTION
It fails too. I forgot to rename PySide --> PyQt4 !
On 20 mar, 22:02, Tim Delaney wrote:
> On 21 March 2013 06:40, jmfauth wrote:
>
> >
> > [snip usual rant from jmf]
>
>
> It has been acknowledged as a real regression, but he keeps hijacking every
> thread where strings are mentioned to harp on about it. He
On 21 mar, 04:12, rusi wrote:
> On Mar 21, 12:40 am, jmfauth wrote:
>
> >
>
> > Courageous people can try to do something with the unicode
> > collation algorithm (see unicode.org). Some time ago, for the fun,
> > I wrote something (not perfec
On 23 mar, 17:17, Mark Lawrence wrote:
> On 23/03/2013 09:24, jmfauth wrote:
>
>
>
>
>
>
>
>
>
> > On 20 mar, 22:02, Tim Delaney wrote:
> >> On 21 March 2013 06:40, jmfauth wrote:
>
> >>>
> >>> [snip usual rant from
On 25 mar, 22:51, Chris Angelico wrote:
> The Python 3 merge of int and long has effectively penalized
> small-number arithmetic by removing an optimization. As we've seen
> from PEP 393 strings (jmf aside), there can be huge benefits from
> having a single type with multiple representations inter
On 26 mar, 20:03, Chris Angelico wrote:
> On Wed, Mar 27, 2013 at 5:50 AM, jmfauth wrote:
> > On 25 mar, 22:51, Chris Angelico wrote:
> >> The Python 3 merge of int and long has effectively penalized
> >> small-number arithmetic by removing an optimization. As w
On 26 mar, 22:08, Grant Edwards wrote:
>
> I think we all agree that jmf is a character.
>
--
The characters are also "intrisic characteristics" of a
group in the Group Theory.
If you are not a mathematician, but eg a scientist in
need of these characters, they are available in
"precalculat
On 28 mar, 07:12, Ethan Furman wrote:
> On 03/27/2013 08:49 PM, rusi wrote:
>
> > In particular "You are a liar" is as bad as "You are an idiot"
> > The same statement can be made non-abusively thus: "... is not true
> > because ..."
>
> I don't agree. With all the posts and micro benchmarks and
On 28 mar, 11:30, Chris Angelico wrote:
> On Thu, Mar 28, 2013 at 8:03 PM, jmfauth wrote:
-
> You really REALLY need to sort out in your head the difference between
> correctness and performance. I still haven't seen one single piece of
> evidence from you that Python
On 28 mar, 14:01, Steven D'Aprano wrote:
> On Thu, 28 Mar 2013 23:11:55 +1100, Neil Hodgson wrote:
> > Ian Foote:
>
>
> > One benefit of
> > UTF-8 over Python's flexible representation is that it is, on average,
> > more compact over a wide set of samples.
>
> Sure. And over a different set of sam
On 28 mar, 15:38, Chris Angelico wrote:
> On Fri, Mar 29, 2013 at 1:12 AM, jmfauth wrote:
> > This flexible string representation is so absurd that not only
> > "it" does not know you can not write Western European Languages
> > with latin-1, "it" pen
On 28 mar, 16:14, jmfauth wrote:
> On 28 mar, 15:38, Chris Angelico wrote:
>
>
>
>
>
>
>
>
>
> > On Fri, Mar 29, 2013 at 1:12 AM, jmfauth wrote:
> > > This flexible string representation is so absurd that not only
> > > "it" does
Chris,
Your problem with int/long, the start of this thread, is
very intersting.
This is not a demonstration, a proof, rather an illustration.
Assume you have a set of integers {0...9} and an operator,
let say, the addition.
Idea.
Just devide this set in two chunks, {0...4} and {5...9}
and work
On 28 mar, 17:33, Ian Kelly wrote:
> On Thu, Mar 28, 2013 at 7:34 AM, jmfauth wrote:
> > The flexible string representation takes the problem from the
> > other side, it attempts to work with the characters by using
> > their representations and it (can only) fails...
>
&
On 28 mar, 18:55, Chris Angelico wrote:
> On Fri, Mar 29, 2013 at 4:48 AM, jmfauth wrote:
> > If Python had imlemented Unicode correctly, there would
> > be no difference in using an "a", "é", "€" or any character,
> > what the narrow builds did
On 28 mar, 21:29, Benjamin Kaplan wrote:
> On Thu, Mar 28, 2013 at 10:48 AM, jmfauth wrote:
> > On 28 mar, 17:33, Ian Kelly wrote:
> >> On Thu, Mar 28, 2013 at 7:34 AM, jmfauth wrote:
> >> > The flexible string representation takes the problem from the
> >
On 28 mar, 22:11, jmfauth wrote:
> On 28 mar, 21:29, Benjamin Kaplan wrote:
>
>
>
>
>
>
>
>
>
> > On Thu, Mar 28, 2013 at 10:48 AM, jmfauth wrote:
> > > On 28 mar, 17:33, Ian Kelly wrote:
> > >> On Thu, Mar 28, 2013 at 7:34 AM, jmfauth
--
Neil Hodgson:
"The counter-problem is that a French document that needs to include
one mathematical symbol (or emoji) outside Latin-1 will double in size
as a Python string."
Serious developers/typographers/users know that you can not compose
a text in French with "latin-1". This is now a
-
I'm not whining or and I'm not complaining (and never did).
I always exposed facts.
I'm not especially interested in Python, I'm interested in
Unicode.
Usualy when I posted examples, there are confirmed.
What I see is this (std "download-abled" Python's on Windows 7 (and
other
Windo
On 1 avr, 21:28, Chris Angelico wrote:
> On Tue, Apr 2, 2013 at 6:15 AM, jmfauth wrote:
> > Py32
> >>>> import timeit
> >>>> timeit.repeat("'a' * 1000 + 'ẞ'")
> > [0.7005365263669056, 0.6810694766790423, 0.6811978
On 2 avr, 01:43, Neil Hodgson wrote:
> Mark Lawrence:
>
> > You've given many examples of the same type of micro benchmark, not many
> > examples of different types of benchmark.
>
> Trying to work out what jmfauth is on about I found what appears to
>
On 2 avr, 10:03, Chris Angelico wrote:
> On Tue, Apr 2, 2013 at 6:24 PM, jmfauth wrote:
> > An editor may reflect very well the example a gave. You enter
> > thousand ascii chars, then - boum - as you enter a non ascii
> > char, your editor (assuming is uses a mechanism like
On 2 avr, 10:35, Steven D'Aprano wrote:
> On Tue, 02 Apr 2013 19:03:17 +1100, Chris Angelico wrote:
>
> So what? Who cares if it takes 0.2 second to insert a character
> instead of 0.1 second? That's still a hundred times faster than you
> can type.
>
-
This not the problem. The i
On 2 avr, 16:03, Steven D'Aprano wrote:
> On Tue, 02 Apr 2013 11:58:11 +0100, Steve Simmons wrote:
>
> I'm sure you didn't intend to be insulting, but some of us *have* taken
> JMF seriously, at least at first. His repeated overblown claims of how
> Python is destroying Unicode ...
Sorrry I neve
On 2 avr, 18:57, rusi wrote:
> On Apr 2, 8:17 pm, Ethan Furman wrote:
>
> > Simmons (too many Steves!), I know you're new so don't have all the history
> > with jmf that many
> > of us do, but consider that the original post was about numbers, had
> > nothing to do with
> > characters or unicod
This FSR is wrong by design. A naive way to embrace Unicode.
jmf
--
http://mail.python.org/mailman/listinfo/python-list
On 4 avr, 03:36, Steven D'Aprano wrote:
> Although PEP 8 is only compulsory for the Python standard library, many
> users like to stick to PEP 8 for external projects.
>
> http://www.python.org/dev/peps/pep-0008/
>
> With perhaps one glaring exception: many people hate, or ignore, PEP 8's
> recomm
On 9 avr, 15:32, [email protected] wrote:
> I'm new to learning python and creating a basic program to convert units of
> measurement which I will eventually expand upon but im trying to figure out
> how to loop the entire program. When I insert a while loop it only loops the
> first 2 l
In a previous post,
http://groups.google.com/group/comp.lang.python/browse_thread/thread/6aec70817705c226#
,
Chris “Kwpolska” Warrick wrote:
“Is Unicode support so hard, especially in the 21st century?”
--
Unicode is not really complicate and it works very well (more
than two decades of develo
I'm planning to build an external lib. This lib will exchange
a lot of strings between the lib and the "core Python code"
of applications.
I wish this lib to be modern, 100% unicode compliant. It will
be developped for Python 2.7 and for Python 3. In an early
phase, technically, it will be develop
Thanks for the reply. Subject closed.
--
http://mail.python.org/mailman/listinfo/python-list
On 23 Dez., 09:33, Yan Cheng CHEOK wrote:
> Currently, I have the following text file
> (https://sites.google.com/site/yanchengcheok/Home/TEST.TXT?attredirect...)
> written by C++ wostringstream.
>
The coding of the file is utf-16le. You should take care
of this coding when you *read* the file,
I wrote miscellaneous interactive interpreters and
I fall on this.
In Python 2.7 (understand Python > 2.6), a source code
can be compiled with "native" '\r\n' as eol.
In Python 3.1, it does not seem to be the case.
(Python 3.2.a/b not checked).
Bug, regression, deliberate choice?
>>> sys.vers
On 29 Dez., 21:14, Terry Reedy wrote:
> On 12/29/2010 2:31 PM, Terry Reedy wrote:
>
> > "Changed in version 3.2: Allowed use of Windows and Mac newlines. Also
> > input in 'exec' mode does not have to end in a newline anymore. Added
> > the optimize parameter."
>
> Retest shows that above is corre
On 30 Dez., 00:11, Terry Reedy wrote:
> On 12/29/2010 4:06 PM, jmfauth wrote:
>
>
>
> > On 29 Dez., 21:14, Terry Reedy wrote:
> >> On 12/29/2010 2:31 PM, Terry Reedy wrote:
>
> >>> "Changed in version 3.2: Allowed use of Windows and Mac newlines. A
After having read the discussion about the issue 1602,
http://bugs.python.org/issue1602, I came to the idea
to test Python with the PowerShell. I thought, it
could help and manage "unicode" better than the
std "dosbox" does
My experience with PowerShell is closed to zero, so
take the following as
Just an info, addendum.
>>> sys.version
'3.2rc1 (r32rc1:88035, Jan 15 2011, 21:05:51) [MSC v.1500 32 bit
(Intel)]'
>>> compile('if True:\r\nprint(999)\r\n', '', 'exec')
at 0x023CA610, file "", line 2>
>>> exec(compile('if True:\r\nprint(999)\r\n', '', 'exec'))
999
>>>
--
http://mail.p
As a scientist using computer tools, and not as a computer
scientist, I discovered Python long time ago (it was in its
1.5.6 version) and I remain an happy user up to now date.
Yesterday, I was happy to download and test Python 3.2rc1.
Python is still this powerful and pleasant language, but...
I
> No, I'm sorry, they're not obvious at all.
These reasons become obious as soon as you start working.
Let's take a practical point view. It did not take a long time
to understand, that it is much simpler to delete the __pycache__
directory everytime I compile my scripts than to visit it just
bec
On Jan 18, 6:07 am, Terry Reedy wrote:
> ...
> This is the 21-year-old behavior now changed.
> ...
Yes, you summarized the situation very well. The way of
working has changed and probably more deeply that one
may think.
It is now practically impossible to launch a Python
application via a .pyc
>
> > If you think the site is bad, send me a ONE better screenshot, or link
> > thereto, of wx on WinXP/Vista/7. I promise to look at it. Then urge
> > Robin to update the page.
>
No wxWidgets, but real Python / wxPython applications, all updated on
Windows 7.
http://spinecho.ze.cx/
--
http://m
My "nightmare" was mainly due, because when I read the
the "What's new?", I did not understand too much this
caching stuff. It's only later, after testing some
applications, I really got the surprise to understand
it. (Py3.1 and Py3.2 pyc's mixture).
Having said this, to tell you the truth. I do r
On Jan 19, 7:03 pm, Antoine Pitrou wrote:
> On Wed, 19 Jan 2011 08:30:12 -0800 (PST)
>
> jmfauth wrote:
> > Yes, I can launch a pyc, when I have a single file.
> > But what happens, if one of your cached .pyc file import
> > a module with a name as defined in th
On Jan 19, 11:33 pm, Terry Reedy wrote:
> On 1/19/2011 1:02 PM, Tim Harig wrote:
>
> > Right, but I only have to do that once. After that, I can directly address
> > any piece of the stream that I choose. If I leave the information as a
> > simple UTF-8 stream, I would have to walk the stream ag
Python all versions.
It's not a bug, but I'm suprised the following does
not raise a SyntaxError (missing space between
'9' and 'for').
>>> [9for c in 'abc']
[9, 9, 9]
>>>
Side effect: If this behaviour is considered as correct,
it makes a correct Python code styling (IDLE, editors, ...)
practic
On 4 juil, 12:35, Carl Banks wrote:
> On Jul 4, 1:31 am, jmfauth wrote:
>
Thanks for having explained in good English my feelings.
>
> Some other places were keyword can follow a number:
>
Note, that this does not envolve numbers only.
>>> ['z' for c i
Thank you all for the discussion and the explanations.
> Mark Dickinson
I toyed a littled bit this afternoon and I wrote a colouriser
(British spelling?) with the tokenize module. It is quite
simple and easy.
BTW, if I understand correctly the module tokenize import
the module token. So your exa
Small inconsistency in the format.__doc__
>>> sys.version
2.7 (r27:82525, Jul 4 2010, 09:01:59) [MSC v.1500 32 bit (Intel)]
>>> ''.format.__doc__
S.format(*args, **kwargs) -> unicode
>>> type('{}'.format(999))
>>> type('{}'.format('abcé'))
--
http://mail.python.org/mailman/listinfo/python-li
A quick question.
I understand how to get these numbers
34.5231263880373081783294677734375
and
47 (from 2**47)
and the sign.
with the decimal module, but I fail to find this one
4858258098025923
Possible?
--
http://mail.python.org/mailman/listinfo/python-list
On 13 août, 17:43, Mark Dickinson wrote:
> On Aug 13, 3:03 pm, jmfauth wrote:
>
>
>
> > A quick question.
>
> > I understand how to get these numbers
>
> > 34.5231263880373081783294677734375
>
> > and
>
> > 47 (from 2**47)
&g
I think there is a small point here.
>>> sys.version
2.7 (r27:82525, Jul 4 2010, 09:01:59) [MSC v.1500 32 bit (Intel)]
>>> print unichr.__doc__
unichr(i) -> Unicode character
Return a Unicode string of one character with ordinal i; 0 <= i <=
0x10.
>>> # but
>>> unichr(0x10fff)
Traceback (mos
Short comments:
1) I'm aware Python can be built in "ucs2" or "ucs4" mode. It remains
that the unichr doc string does not seem correct.
2) 0x0 versus 0
Do not take this too seriously. Sure the value of 0x0 and 0 are equal,
but the "unit" sounds strange.
Eg. If a is a length, I would not express a
I hope my understanding is correct and I'm not dreaming.
When an endianess is not specified, (BE, LE, unmarked forms),
the Unicode Consortium specifies, the default byte serialization
should be big-endian.
See http://www.unicode.org/faq//utf_bom.html
Q: Which of the UTFs do I need to support?
and
On 12 oct, 15:47, Antoine Pitrou wrote:
> On Tue, 12 Oct 2010 06:28:23 -0700 (PDT)
>
>
>
> Python uses the host's endianness by default. So, on a little-endian
> machine, utf-16 and utf-32 will use little-endian encoding.
Thanks. I never have been aware of this.
--
http://mail.python.org/mailm
On 12 oct, 22:00, John Machin wrote:
> jmfauth gmail.com> writes:
>
> > When an endianess is not specified, (BE, LE, unmarked forms),
> > the Unicode Consortium specifies, the default byte serialization
> > should be big-endian.
>
> > Seehttp://www.unicode.o
101 - 155 of 155 matches
Mail list logo
