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

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

RE Module Performance

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

Contents

  RE Module Performance Devyn Collier Johnson <devyncjohnson@gmail.com> - 2013-07-11 19:44 -0400
    Re: RE Module Performance wxjmfauth@gmail.com - 2013-07-12 02:23 -0700
      Re: RE Module Performance Chris Angelico <rosuav@gmail.com> - 2013-07-12 19:27 +1000
      Re: RE Module Performance Joshua Landau <joshua@landau.ws> - 2013-07-12 10:39 +0100
      Re: RE Module Performance Chris Angelico <rosuav@gmail.com> - 2013-07-12 19:40 +1000
      Re: RE Module Performance Devyn Collier Johnson <devyncjohnson@gmail.com> - 2013-07-12 06:45 -0400
      Re: RE Module Performance Joshua Landau <joshua@landau.ws> - 2013-07-12 16:59 +0100
      Re: RE Module Performance Peter Otten <__peter__@web.de> - 2013-07-12 18:15 +0200
      Re: RE Module Performance Chris Angelico <rosuav@gmail.com> - 2013-07-13 02:21 +1000
      Re: RE Module Performance Devyn Collier Johnson <devyncjohnson@gmail.com> - 2013-07-12 13:58 -0400
        Re: RE Module Performance Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-07-13 05:37 +0000
          Re: RE Module Performance 88888 Dihedral <dihedral88888@gmail.com> - 2013-07-14 11:17 -0700
            Re: RE Module Performance Devyn Collier Johnson <devyncjohnson@gmail.com> - 2013-07-15 06:06 -0400
              Re: RE Module Performance Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-07-15 12:36 +0000
                Dihedral Devyn Collier Johnson <devyncjohnson@gmail.com> - 2013-07-15 08:52 -0400
                Re: Dihedral Joel Goldstick <joel.goldstick@gmail.com> - 2013-07-15 09:03 -0400
                Re: Dihedral Wayne Werner <wayne@waynewerner.com> - 2013-07-15 17:43 -0500
                Re: Dihedral Fábio Santos <fabiosantosart@gmail.com> - 2013-07-15 23:54 +0100
                Re: Dihedral Chris Angelico <rosuav@gmail.com> - 2013-07-16 08:59 +1000
                Re: Dihedral Tim Delaney <timothy.c.delaney@gmail.com> - 2013-07-16 16:06 +1000
                Re: Dihedral Stefan Behnel <stefan_ml@behnel.de> - 2013-07-24 20:08 +0200
                Re: Dihedral Chris Angelico <rosuav@gmail.com> - 2013-07-25 04:23 +1000
                Re: Dihedral Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-07-24 20:15 -0400
      Re: RE Module Performance Tim Delaney <timothy.c.delaney@gmail.com> - 2013-07-13 08:16 +1000
      Re: RE Module Performance Michael Torrie <torriem@gmail.com> - 2013-07-12 17:13 -0600
        Re: RE Module Performance wxjmfauth@gmail.com - 2013-07-24 06:40 -0700
          Re: RE Module Performance Chris Angelico <rosuav@gmail.com> - 2013-07-24 23:48 +1000
          Re: RE Module Performance David Hutto <dwightdhutto@gmail.com> - 2013-07-24 10:17 -0400
          Re: RE Module Performance David Hutto <dwightdhutto@gmail.com> - 2013-07-24 10:19 -0400
          Re: RE Module Performance Chris Angelico <rosuav@gmail.com> - 2013-07-25 00:34 +1000
            Re: RE Module Performance Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-07-25 07:02 +0000
              Re: RE Module Performance Chris Angelico <rosuav@gmail.com> - 2013-07-25 17:39 +1000
          Re: RE Module Performance Michael Torrie <torriem@gmail.com> - 2013-07-24 08:47 -0600
            Re: RE Module Performance wxjmfauth@gmail.com - 2013-07-25 02:27 -0700
              Re: RE Module Performance Chris Angelico <rosuav@gmail.com> - 2013-07-25 20:14 +1000
                Re: RE Module Performance wxjmfauth@gmail.com - 2013-07-25 12:07 -0700
                  Re: RE Module Performance Chris Angelico <rosuav@gmail.com> - 2013-07-26 05:18 +1000
                  RE: RE Module Performance "Prasad, Ramit" <ramit.prasad@jpmorgan.com> - 2013-07-25 19:30 +0000
                  Re: RE Module Performance Michael Torrie <torriem@gmail.com> - 2013-07-25 21:06 -0600
          Re: RE Module Performance Michael Torrie <torriem@gmail.com> - 2013-07-24 09:00 -0600
            Re: RE Module Performance Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-07-25 05:56 +0000
          Re: RE Module Performance Chris Angelico <rosuav@gmail.com> - 2013-07-25 00:56 +1000
          Re: RE Module Performance Terry Reedy <tjreedy@udel.edu> - 2013-07-24 13:52 -0400
          Re: RE Module Performance Chris Angelico <rosuav@gmail.com> - 2013-07-25 04:15 +1000
            Re: RE Module Performance Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-07-25 07:15 +0000
              Re: RE Module Performance Chris Angelico <rosuav@gmail.com> - 2013-07-25 17:58 +1000
                Re: RE Module Performance Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-07-25 09:22 +0000
                  Re: RE Module Performance Chris Angelico <rosuav@gmail.com> - 2013-07-25 20:07 +1000
          Re: RE Module Performance Terry Reedy <tjreedy@udel.edu> - 2013-07-24 18:09 -0400
          Re: RE Module Performance Chris Angelico <rosuav@gmail.com> - 2013-07-25 08:19 +1000
          Re: RE Module Performance Michael Torrie <torriem@gmail.com> - 2013-07-24 16:59 -0600
          Re: RE Module Performance Chris Angelico <rosuav@gmail.com> - 2013-07-25 09:24 +1000
          Re: RE Module Performance Serhiy Storchaka <storchaka@gmail.com> - 2013-07-25 08:49 +0300
          Re: RE Module Performance Chris Angelico <rosuav@gmail.com> - 2013-07-25 15:58 +1000
          Re: RE Module Performance Jeremy Sanders <jeremy@jeremysanders.net> - 2013-07-25 14:36 +0100
            Re: RE Module Performance Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-07-25 15:26 +0000
              Re: RE Module Performance Chris Angelico <rosuav@gmail.com> - 2013-07-26 01:36 +1000
                Re: RE Module Performance Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-07-25 17:18 +0000
                  Re: RE Module Performance Chris Angelico <rosuav@gmail.com> - 2013-07-26 03:27 +1000
                  Re: RE Module Performance Ian Kelly <ian.g.kelly@gmail.com> - 2013-07-25 15:45 -0500
                    Re: RE Module Performance Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-07-26 02:48 +0000
                      Re: RE Module Performance Ian Kelly <ian.g.kelly@gmail.com> - 2013-07-25 21:20 -0600
                        Re: RE Module Performance wxjmfauth@gmail.com - 2013-07-26 06:36 -0700
                        Re: RE Module Performance wxjmfauth@gmail.com - 2013-07-26 08:46 -0700
                          Re: RE Module Performance Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-07-27 06:28 +0000
                        Re: RE Module Performance Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-07-27 03:37 +0000
                          Re: RE Module Performance Ian Kelly <ian.g.kelly@gmail.com> - 2013-07-26 22:12 -0600
                            Re: RE Module Performance Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-07-27 05:04 +0000
                          Re: RE Module Performance Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-07-27 12:13 -0400
                    Re: RE Module Performance wxjmfauth@gmail.com - 2013-07-26 06:19 -0700
                  Re: RE Module Performance Michael Torrie <torriem@gmail.com> - 2013-07-25 21:09 -0600
                    Re: RE Module Performance wxjmfauth@gmail.com - 2013-07-26 06:21 -0700
                      Re: RE Module Performance Michael Torrie <torriem@gmail.com> - 2013-07-26 20:05 -0600
                        Re: RE Module Performance wxjmfauth@gmail.com - 2013-07-27 11:21 -0700
                          Re: RE Module Performance Ian Kelly <ian.g.kelly@gmail.com> - 2013-07-27 21:53 -0600
                            Re: RE Module Performance wxjmfauth@gmail.com - 2013-07-28 11:13 -0700
                              Re: RE Module Performance MRAB <python@mrabarnett.plus.com> - 2013-07-28 20:04 +0100
                                Re: RE Module Performance wxjmfauth@gmail.com - 2013-07-28 12:30 -0700
                                  Re: RE Module Performance Lele Gaifax <lele@metapensiero.it> - 2013-07-28 22:45 +0200
                                  Re: RE Module Performance Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-07-28 22:01 +0200
                            Re: RE Module Performance wxjmfauth@gmail.com - 2013-07-30 07:01 -0700
                              Re: RE Module Performance Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-07-30 16:38 +0200
                              Re: RE Module Performance Chris Angelico <rosuav@gmail.com> - 2013-07-30 15:45 +0100
                              Re: RE Module Performance MRAB <python@mrabarnett.plus.com> - 2013-07-30 17:13 +0100
                              Re: RE Module Performance Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-07-30 18:39 +0200
                              Re: RE Module Performance MRAB <python@mrabarnett.plus.com> - 2013-07-30 18:14 +0100
                                Re: RE Module Performance Neil Hodgson <nhodgson@iinet.net.au> - 2013-07-31 13:09 +1000
                              Re: RE Module Performance Tim Delaney <timothy.c.delaney@gmail.com> - 2013-07-31 03:27 +1000
                              Re: RE Module Performance Joshua Landau <joshua@landau.ws> - 2013-07-30 18:40 +0100
                              Re: RE Module Performance Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-07-30 20:19 +0200
                                Re: RE Module Performance wxjmfauth@gmail.com - 2013-07-30 12:09 -0700
                                  Re: RE Module Performance Chris Angelico <rosuav@gmail.com> - 2013-07-30 21:04 +0100
                                  Re: RE Module Performance Michael Torrie <torriem@gmail.com> - 2013-07-30 21:54 -0600
                                  Re: RE Module Performance Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-07-31 05:45 +0000
                                    Re: RE Module Performance Chris Angelico <rosuav@gmail.com> - 2013-07-31 08:17 +0100
                                    Re: RE Module Performance wxjmfauth@gmail.com - 2013-07-31 13:15 -0700
                                      Re: RE Module Performance Chris Angelico <rosuav@gmail.com> - 2013-07-31 21:41 +0100
                                  Re: RE Module Performance Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-07-31 10:11 +0200
                                    Re: RE Module Performance wxjmfauth@gmail.com - 2013-07-31 01:32 -0700
                                      Re: RE Module Performance Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-07-31 10:59 +0200
                                      Re: RE Module Performance Michael Torrie <torriem@gmail.com> - 2013-07-31 08:44 -0600
                              Re: RE Module Performance Terry Reedy <tjreedy@udel.edu> - 2013-07-30 17:05 -0400
                              Re: RE Module Performance Michael Torrie <torriem@gmail.com> - 2013-07-30 21:30 -0600
                              Re: RE Module Performance Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-07-31 09:23 +0200
                              Re: RE Module Performance Michael Torrie <torriem@gmail.com> - 2013-07-31 08:27 -0600
                          Re: RE Module Performance Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-07-28 10:45 +0200
                          FSR and unicode compliance - was Re: RE Module Performance Michael Torrie <torriem@gmail.com> - 2013-07-28 09:52 -0600
                            Re: FSR and unicode compliance - was Re: RE Module Performance wxjmfauth@gmail.com - 2013-07-28 12:23 -0700
                              Re: FSR and unicode compliance - was Re: RE Module Performance MRAB <python@mrabarnett.plus.com> - 2013-07-28 20:44 +0100
                              Re: FSR and unicode compliance - was Re: RE Module Performance Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-07-28 21:55 +0200
                              Re: FSR and unicode compliance - was Re: RE Module Performance Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-07-28 20:52 +0000
                                Re: FSR and unicode compliance - was Re: RE Module Performance wxjmfauth@gmail.com - 2013-07-29 04:43 -0700
                                  Re: FSR and unicode compliance - was Re: RE Module Performance Chris Angelico <rosuav@gmail.com> - 2013-07-29 12:57 +0100
                                    Re: FSR and unicode compliance - was Re: RE Module Performance wxjmfauth@gmail.com - 2013-07-29 05:56 -0700
                                    Re: FSR and unicode compliance - was Re: RE Module Performance wxjmfauth@gmail.com - 2013-07-29 07:20 -0700
                                      Re: FSR and unicode compliance - was Re: RE Module Performance Chris Angelico <rosuav@gmail.com> - 2013-07-29 15:49 +0100
                                        Re: FSR and unicode compliance - was Re: RE Module Performance wxjmfauth@gmail.com - 2013-07-29 09:31 -0700
                                  Re: FSR and unicode compliance - was Re: RE Module Performance Heiko Wundram <modelnine@modelnine.org> - 2013-07-29 14:06 +0200
                                  Re: FSR and unicode compliance - was Re: RE Module Performance Devyn Collier Johnson <devyncjohnson@gmail.com> - 2013-07-29 08:43 -0400
                          Re: FSR and unicode compliance - was Re: RE Module Performance Chris Angelico <rosuav@gmail.com> - 2013-07-28 18:03 +0100
                          Re: FSR and unicode compliance - was Re: RE Module Performance Terry Reedy <tjreedy@udel.edu> - 2013-07-28 13:36 -0400
                            Re: FSR and unicode compliance - was Re: RE Module Performance wxjmfauth@gmail.com - 2013-07-29 06:36 -0700
                          Re: FSR and unicode compliance - was Re: RE Module Performance Chris Angelico <rosuav@gmail.com> - 2013-07-28 19:03 +0100
                          Re: RE Module Performance Joshua Landau <joshua@landau.ws> - 2013-07-28 19:19 +0100
                          Re: RE Module Performance Chris Angelico <rosuav@gmail.com> - 2013-07-28 19:29 +0100
                          Re: RE Module Performance Terry Reedy <tjreedy@udel.edu> - 2013-07-28 15:06 -0400
                          Re: RE Module Performance Joshua Landau <joshua@landau.ws> - 2013-07-28 23:14 +0100
                          Re: RE Module Performance Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-07-28 20:51 +0200
                          Re: RE Module Performance Chris Angelico <rosuav@gmail.com> - 2013-07-29 00:07 +0100
                      Re: RE Module Performance Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-07-26 22:38 +0200
          Re: RE Module Performance Devyn Collier Johnson <devyncjohnson@gmail.com> - 2013-07-25 09:44 -0400
          Re: RE Module Performance Ian Kelly <ian.g.kelly@gmail.com> - 2013-07-25 15:53 -0500
      Re: RE Module Performance MRAB <python@mrabarnett.plus.com> - 2013-07-13 00:16 +0100
      Re: RE Module Performance Tim Delaney <timothy.c.delaney@gmail.com> - 2013-07-14 05:34 +1000
      Re: RE Module Performance Devyn Collier Johnson <devyncjohnson@gmail.com> - 2013-07-16 06:30 -0400
        Re: RE Module Performance 88888 Dihedral <dihedral88888@gmail.com> - 2013-07-18 13:17 -0700

Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7  Next page →

#51157 — Re: Dihedral

Fábio Santos, 16.07.2013 00:54:
>> On 07/15/2013 08:36 AM, Steven D'Aprano wrote:
>>>
>>> Devyn,
>>>
>>> 88888 Dihedral is our resident bot, not a human being. Nobody knows who
>>> controls it, and why they are running it, but we are pretty certain that
>>> it is a bot responding mechanically to keywords in people's posts.
>>>
>>> It's a very clever bot, but still a bot. About one post in four is
>>> meaningless jargon, the other three are relevant enough to fool people
>>> into thinking that maybe it is a human being. It had me fooled for a long
>>> time.
> 
> Does this mean he passes the Turing test?

I'd say that "it" appears more correct. Or is there any indication of a
specific bot gender? (I sure might have missed it...)

Note that being of a specific gender is definitely not required to pass the
Turing test. I'm not even sure pretending to have one is required.

Stefan

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

#51160 — Re: Dihedral

On Thu, Jul 25, 2013 at 4:08 AM, Stefan Behnel <stefan_ml@behnel.de> wrote:
> Fábio Santos, 16.07.2013 00:54:
>> Does this mean he passes the Turing test?
>
> I'd say that "it" appears more correct. Or is there any indication of a
> specific bot gender? (I sure might have missed it...)
>
> Note that being of a specific gender is definitely not required to pass the
> Turing test. I'm not even sure pretending to have one is required.

Gender:  [ ] Male   [ ] Female   [ ] Both   [ ] Neither   [ ] Robot   [ ] Other

In absence of specific information to the contrary, I'll usually refer
to computers and programs by masculine pronouns; no particular reason
for it, just the same sort of convention that has most ships and boats
being "she".

And you're quite right, gender and the pretense thereto are completely
optional in a Turing test, even though the Turing test was derived
from a similar concept involving gender.

ChrisA

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

#51177 — Re: Dihedral

On Thu, 25 Jul 2013 04:23:45 +1000, Chris Angelico <rosuav@gmail.com>
declaimed the following:

>
>In absence of specific information to the contrary, I'll usually refer
>to computers and programs by masculine pronouns; no particular reason
>for it, just the same sort of convention that has most ships and boats
>being "she".
>
	Heh... The Grey Wolf (1999 Jeep Cherokee) is "female", but the
Dungbeetle (Aprilia Scarabeo 500) tends to be an "it" <G>
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

#50558

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

On 13 July 2013 03:58, Devyn Collier Johnson <devyncjohnson@gmail.com>wrote:

>
> Thanks for the thorough response. I learned a lot. You should write
> articles on Python.
> I plan to spend some time optimizing the re.py module for Unix systems. I
> would love to amp up my programs that use that module.


If you are finding that regular expressions are taking too much time, have
a look at the https://pypi.python.org/pypi/re2/ and
https://pypi.python.org/pypi/regex/2013-06-26 modules to see if they
already give you enough of a speedup.

Tim Delaney

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

#50563

On 07/12/2013 09:59 AM, Joshua Landau wrote:
> If you're interested, the basic of it is that strings now use a
> variable number of bytes to encode their values depending on whether
> values outside of the ASCII range and some other range are used, as an
> optimisation.

Variable number of bytes is a problematic way to saying it.  UTF-8 is a
variable-number-of-bytes encoding scheme where each character can be 1,
2, 4, or more bytes, depending on the unicode character.  As you can
imagine this sort of encoding scheme would be very slow to do slicing
with (looking up a character at a certain position).  Python uses
fixed-width encoding schemes, so they preserve the O(n) lookup speeds,
but python will use 1, 2, or 4 bytes per every character in the string,
depending on what is needed.  Just in case the OP might have
misunderstood what you are saying.

jmf sees the case where a string is promoted from one width to another,
and thinks that the brief slowdown in string operations to accomplish
this is a problem.  In reality I have never seen anyone use the types of
string operations his pseudo benchmarks use, and in general Python 3's
string behavior is pretty fast.  And apparently much more correct than
if jmf's ideas of unicode were implemented.

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

#51131

Le samedi 13 juillet 2013 01:13:47 UTC+2, Michael Torrie a écrit :
> On 07/12/2013 09:59 AM, Joshua Landau wrote:
> 
> > If you're interested, the basic of it is that strings now use a
> 
> > variable number of bytes to encode their values depending on whether
> 
> > values outside of the ASCII range and some other range are used, as an
> 
> > optimisation.
> 
> 
> 
> Variable number of bytes is a problematic way to saying it.  UTF-8 is a
> 
> variable-number-of-bytes encoding scheme where each character can be 1,
> 
> 2, 4, or more bytes, depending on the unicode character.  As you can
> 
> imagine this sort of encoding scheme would be very slow to do slicing
> 
> with (looking up a character at a certain position).  Python uses
> 
> fixed-width encoding schemes, so they preserve the O(n) lookup speeds,
> 
> but python will use 1, 2, or 4 bytes per every character in the string,
> 
> depending on what is needed.  Just in case the OP might have
> 
> misunderstood what you are saying.
> 
> 
> 
> jmf sees the case where a string is promoted from one width to another,
> 
> and thinks that the brief slowdown in string operations to accomplish
> 
> this is a problem.  In reality I have never seen anyone use the types of
> 
> string operations his pseudo benchmarks use, and in general Python 3's
> 
> string behavior is pretty fast.  And apparently much more correct than
> 
> if jmf's ideas of unicode were implemented.

------

Sorry, you are not understanding Unicode. What is a Unicode
Transformation Format (UTF), what is the goal of a UTF and
why it is important for an implementation to work with a UTF.

Short example. Writing an editor with something like the
FSR is simply impossible (properly).

jmf

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

#51132

On Wed, Jul 24, 2013 at 11:40 PM,  <wxjmfauth@gmail.com> wrote:
> Short example. Writing an editor with something like the
> FSR is simply impossible (properly).

jmf, have you ever written an editor with *any* string representation?
Are you speaking from any level of experience at all?

ChrisA

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

#51133

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

I've screwed up plenty of times in python, but can write code like a pro
when I'm feeling better(on SSI and medicaid). An editor can be built
simply, but it's preference that makes the difference. Some might have used
tkinter, gtk. wxpython or other methods for the task.

I think the main issue in responding is your library preference, or widget
set preference. These can make you right with some in your response, or
wrong with others that have a preferable gui library that coincides with
one's personal cognitive structure that makes t




On Wed, Jul 24, 2013 at 9:48 AM, Chris Angelico <rosuav@gmail.com> wrote:

> On Wed, Jul 24, 2013 at 11:40 PM,  <wxjmfauth@gmail.com> wrote:
> > Short example. Writing an editor with something like the
> > FSR is simply impossible (properly).
>
> jmf, have you ever written an editor with *any* string representation?
> Are you speaking from any level of experience at all?
>
> ChrisA
> --
> http://mail.python.org/mailman/listinfo/python-list
>



-- 
Best Regards,
David Hutto
*CEO:* *http://www.hitwebdevelopment.com*

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

#51134

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

I've screwed up plenty of times in python, but can write code like a pro
when I'm feeling better(on SSI and medicaid). An editor can be built
simply, but it's preference that makes the difference. Some might have used
tkinter, gtk. wxpython or other methods for the task.

I think the main issue in responding is your library preference, or widget
set preference. These can make you right with some in your response, or
wrong with others that have a preferable gui library that coincides with
one's personal cognitive structure that makes it more usable in relation to
how you learned a preferable gui kit.


On Wed, Jul 24, 2013 at 10:17 AM, David Hutto <dwightdhutto@gmail.com>wrote:

> I've screwed up plenty of times in python, but can write code like a pro
> when I'm feeling better(on SSI and medicaid). An editor can be built
> simply, but it's preference that makes the difference. Some might have used
> tkinter, gtk. wxpython or other methods for the task.
>
> I think the main issue in responding is your library preference, or widget
> set preference. These can make you right with some in your response, or
> wrong with others that have a preferable gui library that coincides with
> one's personal cognitive structure that makes t
>
>
>
>
> On Wed, Jul 24, 2013 at 9:48 AM, Chris Angelico <rosuav@gmail.com> wrote:
>
>> On Wed, Jul 24, 2013 at 11:40 PM,  <wxjmfauth@gmail.com> wrote:
>> > Short example. Writing an editor with something like the
>> > FSR is simply impossible (properly).
>>
>> jmf, have you ever written an editor with *any* string representation?
>> Are you speaking from any level of experience at all?
>>
>> ChrisA
>> --
>> http://mail.python.org/mailman/listinfo/python-list
>>
>
>
>
> --
> Best Regards,
> David Hutto
> *CEO:* *http://www.hitwebdevelopment.com*
>



-- 
Best Regards,
David Hutto
*CEO:* *http://www.hitwebdevelopment.com*

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

#51135

On Thu, Jul 25, 2013 at 12:17 AM, David Hutto <dwightdhutto@gmail.com> wrote:
> I've screwed up plenty of times in python, but can write code like a pro
> when I'm feeling better(on SSI and medicaid). An editor can be built simply,
> but it's preference that makes the difference. Some might have used tkinter,
> gtk. wxpython or other methods for the task.
>
> I think the main issue in responding is your library preference, or widget
> set preference. These can make you right with some in your response, or
> wrong with others that have a preferable gui library that coincides with
> one's personal cognitive structure that makes t

jmf's point is more about writing the editor widget (Scintilla, as
opposed to SciTE), which most people will never bother to do. I've
written several text editors, always by embedding someone else's
widget, and therefore not concerning myself with its internal string
representation. Frankly, Python's strings are a *terrible* internal
representation for an editor widget - not because of PEP 393, but
simply because they are immutable, and every keypress would result in
a rebuilding of the string. On the flip side, I could quite plausibly
imagine using a list of strings; whenever text gets inserted, the
string gets split at that point, and a new string created for the
insert (which also means that an Undo operation simply removes one
entire string). In this usage, the FSR is beneficial, as it's possible
to have different strings at different widths.

But mainly, I'm just wondering how many people here have any basis
from which to argue the point he's trying to make. I doubt most of us
have (a) implemented an editor widget, or (b) tested multiple
different internal representations to learn the true pros and cons of
each. And even if any of us had, that still wouldn't have any bearing
on PEP 393, which is about applications, not editor widgets. As stated
above, Python strings before AND after PEP 393 are poor choices for an
editor, ergo arguing from that standpoint is pretty useless. Not that
that bothers jmf...

ChrisA

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

#51197

On Thu, 25 Jul 2013 00:34:24 +1000, Chris Angelico wrote:

> But mainly, I'm just wondering how many people here have any basis from
> which to argue the point he's trying to make. I doubt most of us have
> (a) implemented an editor widget, or (b) tested multiple different
> internal representations to learn the true pros and cons of each. And
> even if any of us had, that still wouldn't have any bearing on PEP 393,
> which is about applications, not editor widgets. As stated above, Python
> strings before AND after PEP 393 are poor choices for an editor, ergo
> arguing from that standpoint is pretty useless.

That's a misleading way to put it. Using immutable strings as editor 
buffers might be a bad way to implement all but the most trivial, low-
performance (i.e. slow) editor, but the basic concept of PEP 393, picking 
an internal representation of the text based on its contents, is not. 
That's just normal. The only difference with PEP 393 is that the choice 
is made on the fly, at runtime, instead of decided in advance by the 
programmer.

I expect that the PEP 393 concept of optimizing memory per string buffer 
would work well in an editor. However the internal buffer is arranged, 
you can safely assume that each chunk of text (word, sentence, paragraph, 
buffer...) will very rarely shift from "all Latin 1" to "all BMP" to 
"includes SMP chars". So, for example, entering a SMP character will need 
to immediately up-cast the chunk from 1-byte per char to 4-bytes per 
char, which is relatively pricey, but it's a one-off cost. Down-casting 
when the SMP character is deleted doesn't need to be done immediately, it 
can be performed when the application is idle.

If the chunks are relatively small (say, a paragraph rather than multiple 
pages of text) then even that initial conversion will be invisible. A 
fast touch typist hits a key about every 0.1 of a second; if it takes a 
millisecond to convert the chunk, you wouldn't even notice the delay. You 
can copy and up-cast a lot of bytes in a millisecond.


-- 
Steven

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

#51202

On Thu, Jul 25, 2013 at 5:02 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Thu, 25 Jul 2013 00:34:24 +1000, Chris Angelico wrote:
>
>> But mainly, I'm just wondering how many people here have any basis from
>> which to argue the point he's trying to make. I doubt most of us have
>> (a) implemented an editor widget, or (b) tested multiple different
>> internal representations to learn the true pros and cons of each. And
>> even if any of us had, that still wouldn't have any bearing on PEP 393,
>> which is about applications, not editor widgets. As stated above, Python
>> strings before AND after PEP 393 are poor choices for an editor, ergo
>> arguing from that standpoint is pretty useless.
>
> That's a misleading way to put it. Using immutable strings as editor
> buffers might be a bad way to implement all but the most trivial, low-
> performance (i.e. slow) editor, but the basic concept of PEP 393, picking
> an internal representation of the text based on its contents, is not.
> That's just normal. The only difference with PEP 393 is that the choice
> is made on the fly, at runtime, instead of decided in advance by the
> programmer.

Maybe I worded it poorly, but my point was the same as you're saying
here: that a Python string is a poor buffer for editing, regardless of
PEP 393. It's not that PEP 393 makes Python strings worse for writing
a text editor, it's that immutability does that.

ChrisA

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

#51137

On 07/24/2013 07:40 AM, wxjmfauth@gmail.com wrote:
> Sorry, you are not understanding Unicode. What is a Unicode
> Transformation Format (UTF), what is the goal of a UTF and
> why it is important for an implementation to work with a UTF.

Really?  Enlighten me.

Personally, I would never use UTF as a representation *in memory* for a
unicode string if it were up to me.  Why?  Because UTF characters are
not uniform in byte width so accessing positions within the string is
terribly slow and has to always be done by starting at the beginning of
the string.  That's at minimum O(n) compared to FSR's O(1).  Surely you
understand this.  Do you dispute this fact?

UTF is a great choice for interchange, though, and indeed that's what it
was designed for.

Are you calling for UTF to be adopted as the internal, in-memory
representation of unicode?  Or would you simply settle for UCS-4?
Please be clear here.  What are you saying?

> Short example. Writing an editor with something like the
> FSR is simply impossible (properly).

How? FSR is just an implementation detail.  It could be UCS-4 and it
would also work.

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

#51209

Le mercredi 24 juillet 2013 16:47:36 UTC+2, Michael Torrie a écrit :
> On 07/24/2013 07:40 AM, wxjmfauth@gmail.com wrote:
> 
> > Sorry, you are not understanding Unicode. What is a Unicode
> 
> > Transformation Format (UTF), what is the goal of a UTF and
> 
> > why it is important for an implementation to work with a UTF.
> 
> 
> 
> Really?  Enlighten me.
> 
> 
> 
> Personally, I would never use UTF as a representation *in memory* for a
> 
> unicode string if it were up to me.  Why?  Because UTF characters are
> 
> not uniform in byte width so accessing positions within the string is
> 
> terribly slow and has to always be done by starting at the beginning of
> 
> the string.  That's at minimum O(n) compared to FSR's O(1).  Surely you
> 
> understand this.  Do you dispute this fact?
> 
> 
> 
> UTF is a great choice for interchange, though, and indeed that's what it
> 
> was designed for.
> 
> 
> 
> Are you calling for UTF to be adopted as the internal, in-memory
> 
> representation of unicode?  Or would you simply settle for UCS-4?
> 
> Please be clear here.  What are you saying?
> 
> 
> 
> > Short example. Writing an editor with something like the
> 
> > FSR is simply impossible (properly).
> 
> 
> 
> How? FSR is just an implementation detail.  It could be UCS-4 and it
> 
> would also work.

---------

A coding scheme works with a unique set of characters (the repertoire),
and the implementation (the programming) works with a unique set
of encoded code points. The critical step is the path
{unique set of characters} <--> {unique set of encoded code points}


Fact: there is no other way to do it properly (This is explaining
why we have to live today with all these coding schemes or also
explaining why so many coding schemes hadto be created).

How to understand it? With a sheet of paper and a pencil.

In the byte string world, this step is a no-op.

In Unicode, it is exactly the purpose of a "utf" to achieve this
step. "utf": a confusing name covering at the same time the
process and the result of the process.
A "utf chunk", a series of bits (not bytes), hold intrisically
the information about the character it is representing.

Other "exotic" coding schemes like iso6937 of "CID-fonts" are woking
in the same way.

"Unicode" with the help of "utf(s)" does not differ from the basic
rule.

-----

ucs-2: ucs-2 is a perfecly and correctly working coding scheme.
ucs-2 is not different from the other coding schemes and does
not behave differently (cp... or iso-... or ...). It only
covers a smaller repertoire.

-----

utf32: as a pointed many times. You are already using it (maybe
without knowing it). Where? in fonts (OpenType technology),
rendering engines, pdf files. Why? Because there is not other
way to do it better.

------

The Unicode table (its constuction) is a problem per se.
It is not a technical problem, a very important "linguistic
aspect" of Unicode.
See https://groups.google.com/forum/#!topic/comp.lang.python/XkTKE7U8CS0

------

If you are not understanding my "editor" analogy. One other
proposed exercise. Build/create a flexible iso-8859-X coding
scheme. You will quickly understand where the bottleneck
is.
Two working ways:
- stupidly with an editor and your fingers.
- lazily with a sheet of paper and you head.


----

About my benchmarks: No offense. You are not understanding them,
because you do not understand what this FSR does and the coding
of characters. It's a little bit a devil's circle.

Conceptually, this FSR is spending its time in solving the
problem it creates itsself, with plenty of side effects.

-----

There is a clear difference between FSR and ucs-4/utf32.

-----

See also:
http://www.unicode.org/reports/tr17/

(In my mind, quite "dry" and not easy to understand at
a first reading).


jmf

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

#51212

On Thu, Jul 25, 2013 at 7:27 PM,  <wxjmfauth@gmail.com> wrote:
> A coding scheme works with a unique set of characters (the repertoire),
> and the implementation (the programming) works with a unique set
> of encoded code points. The critical step is the path
> {unique set of characters} <--> {unique set of encoded code points}

That's called Unicode. It maps the character 'A' to the code point
U+0041 and so on. Code points are integers. In fact, they are very
well represented in Python that way (also in Pike, fwiw):

>>> ord('A')
65
>>> chr(65)
'A'
>>> chr(123456)
'\U0001e240'
>>> ord(_)
123456

> In the byte string world, this step is a no-op.
>
> In Unicode, it is exactly the purpose of a "utf" to achieve this
> step. "utf": a confusing name covering at the same time the
> process and the result of the process.
> A "utf chunk", a series of bits (not bytes), hold intrisically
> the information about the character it is representing.

No, now you're looking at another level: how to store codepoints in
memory. That demands that they be stored as bits and bytes, because PC
memory works that way.

> utf32: as a pointed many times. You are already using it (maybe
> without knowing it). Where? in fonts (OpenType technology),
> rendering engines, pdf files. Why? Because there is not other
> way to do it better.

And UTF-32 is an excellent system... as long as you're okay with
spending four bytes for every character.

> See https://groups.google.com/forum/#!topic/comp.lang.python/XkTKE7U8CS0

I refuse to click this link. Give us a link to the
python-list@python.org archive, or gmane, or something else more
suited to the audience. I'm not going to Google Groups just to figure
out what you're saying.

> If you are not understanding my "editor" analogy. One other
> proposed exercise. Build/create a flexible iso-8859-X coding
> scheme. You will quickly understand where the bottleneck
> is.
> Two working ways:
> - stupidly with an editor and your fingers.
> - lazily with a sheet of paper and you head.

What has this to do with the editor?

> There is a clear difference between FSR and ucs-4/utf32.

Yes. Memory usage. PEP 393 strings might take up half or even a
quarter of what they'd take up in fixed UTF-32. Other than that,
there's no difference.

ChrisA

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

#51253

Le jeudi 25 juillet 2013 12:14:46 UTC+2, Chris Angelico a écrit :
> On Thu, Jul 25, 2013 at 7:27 PM,  <wxjmfauth@gmail.com> wrote:
> 
> > A coding scheme works with a unique set of characters (the repertoire),
> 
> > and the implementation (the programming) works with a unique set
> 
> > of encoded code points. The critical step is the path
> 
> > {unique set of characters} <--> {unique set of encoded code points}
> 
> 
> 
> That's called Unicode. It maps the character 'A' to the code point
> 
> U+0041 and so on. Code points are integers. In fact, they are very
> 
> well represented in Python that way (also in Pike, fwiw):
> 
> 
> 
> >>> ord('A')
> 
> 65
> 
> >>> chr(65)
> 
> 'A'
> 
> >>> chr(123456)
> 
> '\U0001e240'
> 
> >>> ord(_)
> 
> 123456
> 
> 
> 
> > In the byte string world, this step is a no-op.
> 
> >
> 
> > In Unicode, it is exactly the purpose of a "utf" to achieve this
> 
> > step. "utf": a confusing name covering at the same time the
> 
> > process and the result of the process.
> 
> > A "utf chunk", a series of bits (not bytes), hold intrisically
> 
> > the information about the character it is representing.
> 
> 
> 
> No, now you're looking at another level: how to store codepoints in
> 
> memory. That demands that they be stored as bits and bytes, because PC
> 
> memory works that way.
> 
> 
> 
> > utf32: as a pointed many times. You are already using it (maybe
> 
> > without knowing it). Where? in fonts (OpenType technology),
> 
> > rendering engines, pdf files. Why? Because there is not other
> 
> > way to do it better.
> 
> 
> 
> And UTF-32 is an excellent system... as long as you're okay with
> 
> spending four bytes for every character.
> 
> 
> 
> > See https://groups.google.com/forum/#!topic/comp.lang.python/XkTKE7U8CS0
> 
> 
> 
> I refuse to click this link. Give us a link to the
> 
> python-list@python.org archive, or gmane, or something else more
> 
> suited to the audience. I'm not going to Google Groups just to figure
> 
> out what you're saying.
> 
> 
> 
> > If you are not understanding my "editor" analogy. One other
> 
> > proposed exercise. Build/create a flexible iso-8859-X coding
> 
> > scheme. You will quickly understand where the bottleneck
> 
> > is.
> 
> > Two working ways:
> 
> > - stupidly with an editor and your fingers.
> 
> > - lazily with a sheet of paper and you head.
> 
> 
> 
> What has this to do with the editor?
> 
> 
> 
> > There is a clear difference between FSR and ucs-4/utf32.
> 
> 
> 
> Yes. Memory usage. PEP 393 strings might take up half or even a
> 
> quarter of what they'd take up in fixed UTF-32. Other than that,
> 
> there's no difference.
> 
> 
> 
> ChrisA

--------


Let start with a simple string \textemdash or \texttendash

>>> sys.getsizeof('–')
40
>>> sys.getsizeof('a')
26

jmf

jmf

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

#51254

On Fri, Jul 26, 2013 at 5:07 AM,  <wxjmfauth@gmail.com> wrote:
> Let start with a simple string \textemdash or \texttendash
>
>>>> sys.getsizeof('–')
> 40
>>>> sys.getsizeof('a')
> 26

Most of the cost is in those two apostrophes, look:

>>> sys.getsizeof('a')
26
>>> sys.getsizeof(a)
8

Okay, that's slightly unfair (bonus points: figure out what I did to
make this work; there are at least two right answers) but still, look
at what an empty string costs:

>>> sys.getsizeof('')
25

Or look at the difference between one of these characters and two:

>>> sys.getsizeof('aa')-sys.getsizeof('a')
1
>>> sys.getsizeof('––')-sys.getsizeof('–')
2

That's what the characters really cost. The overhead is fixed. It is,
in fact, almost completely insignificant. The storage requirement for
a non-ASCII, BMP-only string converges to two bytes per character.

ChrisA

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

#51258

Chris Angelico wrote:
> On Fri, Jul 26, 2013 at 5:07 AM,  <wxjmfauth@gmail.com> wrote:
> > Let start with a simple string \textemdash or \texttendash
> >
> >>>> sys.getsizeof('-')
> > 40
> >>>> sys.getsizeof('a')
> > 26
> 
> Most of the cost is in those two apostrophes, look:
> 
> >>> sys.getsizeof('a')
> 26
> >>> sys.getsizeof(a)
> 8
> 
> Okay, that's slightly unfair (bonus points: figure out what I did to
> make this work; there are at least two right answers) but still, look
> at what an empty string costs:

I like bonus points. :)
>>> a = None 
>>> sys.getsizeof(a)
8

Not sure what the other right answer is...booleans take 12 bytes (on 2.6)

> 
> >>> sys.getsizeof('')
> 25
> 
> Or look at the difference between one of these characters and two:
> 
> >>> sys.getsizeof('aa')-sys.getsizeof('a')
> 1
> >>> sys.getsizeof('--')-sys.getsizeof('-')
> 2
> 
> That's what the characters really cost. The overhead is fixed. It is,
> in fact, almost completely insignificant. The storage requirement for
> a non-ASCII, BMP-only string converges to two bytes per character.
> 
> ChrisA
> --
> http://mail.python.org/mailman/listinfo/python-list


Ramit



This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email.  

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

#51273

On 07/25/2013 01:07 PM, wxjmfauth@gmail.com wrote:
> Let start with a simple string \textemdash or \texttendash
> 
>>>> sys.getsizeof('–')
> 40
>>>> sys.getsizeof('a')
> 26

That's meaningless.  You're comparing the overhead of a string object
itself (a one-time cost anyway), not the overhead of storing the actual
characters.  This is the only meaningful comparison:

>>>> sys.getsizeof('––') - sys.getsizeof('–')

>>>> sys.getsizeof('aa') - sys.getsizeof('a')

Actually I'm not even sure what your point is after all this time of
railing against FSR.  You have said in the past that Python penalizes
users of character sets that require wider byte encodings, but what
would you have us do? use 4-byte characters and penalize everyone
equally?  Use 2-byte characters that incorrectly expose surrogate pairs
for some characters? Use UTF-8 in memory and do O(n) indexing?  Are your
programs (actual programs, not contrived benchmarks) actually slower
because of FSR?  Is FSR incorrect?  If so, according to what part of the
unicode standard?  I'm not trying to troll, or feed the troll.  I'm
actually curious.

I think perhaps you feel that many of us who don't use unicode often
don't understand unicode because some of us don't understand you.  If
so, I'm not sure that's actually true.

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

#51139

On 07/24/2013 08:34 AM, Chris Angelico wrote:
> Frankly, Python's strings are a *terrible* internal representation
> for an editor widget - not because of PEP 393, but simply because
> they are immutable, and every keypress would result in a rebuilding
> of the string. On the flip side, I could quite plausibly imagine
> using a list of strings; whenever text gets inserted, the string gets
> split at that point, and a new string created for the insert (which
> also means that an Undo operation simply removes one entire string).
> In this usage, the FSR is beneficial, as it's possible to have
> different strings at different widths.

Very good point.  Seems like this is exactly what is tripping up jmf in
general.  His pseudo benchmarks are bogus for this exact reason. No one
uses python strings in this fashion.  Editors certainly would not.  But
then again his argument in the past does not mention editors.  But it
makes me wonder if jmf is using python strings appropriately, or even
realizes they are immutable.

> But mainly, I'm just wondering how many people here have any basis 
> from which to argue the point he's trying to make. I doubt most of
> us have (a) implemented an editor widget, or (b) tested multiple 
> different internal representations to learn the true pros and cons
> of each. 

Maybe, but simply thinking logically, FSR and UCS-4 are equivalent in
pros and cons, and the cons of using UCS-2 (the old narrow builds) are
well known.  UCS-2 simply cannot represent all of unicode correctly.
This is in the PEP of course.

His most recent argument that Python should use UTF as a representation
is very strange to be honest.  The cons of UTF are apparent and widely
known.  The main con is that UTF strings are O(n) for indexing a
position within the string.

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

Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7  Next page →

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

csiph-web