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


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

Re: "More About Unicode in Python 2 and 3"

Started byGene Heskett <gheskett@wdtv.com>
First post2014-01-06 09:32 -0500
Last post2014-01-07 04:30 +1100
Articles 2 — 2 participants

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: "More About Unicode in Python 2 and 3" Gene Heskett <gheskett@wdtv.com> - 2014-01-06 09:32 -0500
    Re: "More About Unicode in Python 2 and 3" Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-01-07 04:30 +1100

#63282 — Re: "More About Unicode in Python 2 and 3"

FromGene Heskett <gheskett@wdtv.com>
Date2014-01-06 09:32 -0500
SubjectRe: "More About Unicode in Python 2 and 3"
Message-ID<mailman.5017.1389018766.18130.python-list@python.org>
On Monday 06 January 2014 08:52:42 Ned Batchelder did opine:
[...]
> You are still talking about whether Armin is right, and whether he
> writes well, about flaws in his statistics, etc.  I'm talking about the
> fact that an organization (Python core development) has a product
> (Python 3) that is getting bad press.  Popular and vocal customers
> (Armin, Kenneth, and others) are unhappy.  What is being done to make
> them happy?  Who is working with them?  They are not unique, and their
> viewpoints are not outliers.
> 
> I'm not talking about the technical details of bytes and Unicode.  I'm
> talking about making customers happy.

+1 Ned. Quite well said.

And from my lurking here, its quite plain to me that 3.x python has a 
problem with everyday dealing with strings.  If it is not solved relatively 
quickly, then I expect there will be a fork, a 2.8 by those most heavily 
invested. Or an exodus to the next "cool" language.

No language will remain "cool" for long if it cannot simply and dependably 
solve the everyday problem of printing the monthly water bill.  If it can 
be done in assembly, C or even bash, then it should be doable in python 
even simpler.

Its nice to be able abstract the functions so they become one word macro's 
that wind up using 2 megs of program memory and 200k of stack to print 
Hello World, but I can do that with 3 or 4 lines of assembly on a coco3 
running nitros9.  Or 3 lines of C.  The assembly will use perhaps 20 bytes 
of stack, the C version maybe 30.  And the assembly will be lightening fast 
on a cpu with a less than 2 megahertz clock.

Given that the problem IS understood, a language that can simplify solving 
a problem is nice, and will be used.  But if the problem is not well 
understood, then you can write gigo crap in your choice of languages.

Python is supposed to be a problem solver, not a problem creator.

I'll get me coat. :)

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

We are using Linux daily to UP our productivity - so UP yours!
		-- Adapted from Pat Paulsen by Joe Sloan
A pen in the hand of this president is far more
dangerous than 200 million guns in the hands of
         law-abiding citizens.

[toc] | [next] | [standalone]


#63312

FromSteven D'Aprano <steve+comp.lang.python@pearwood.info>
Date2014-01-07 04:30 +1100
Message-ID<52cae831$0$29971$c3e8da3$5496439d@news.astraweb.com>
In reply to#63282
Gene Heskett wrote:

> And from my lurking here, its quite plain to me that 3.x python has a
> problem with everyday dealing with strings.

I've been using Python 3.x since Python 3.1 came out, and I haven't come
across any meaningful problems with the everyday dealing with strings.
Quite the opposite -- I never quite understood the difference between text
strings and byte strings until I started using Python 3.

Perhaps you would care to explain what these everyday problems are that you
have seen?


-- 
Steven

[toc] | [prev] | [standalone]


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


csiph-web