Research paper "Energy Efficiency across Programming Languages: How does energy, time, and memory relate?"
3.1415926535897932384626433832795
jjenne025 at go.tahomasd.us
Mon Oct 2 16:31:30 EDT 2017
The page is fixed BTW
>>>import this
On Sun, Sep 17, 2017 at 6:13 AM, <python-list-request at python.org> wrote:
> Send Python-list mailing list submissions to
> python-list at python.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mail.python.org/mailman/listinfo/python-list
> or, via email, send a message with subject or body 'help' to
> python-list-request at python.org
>
> You can reach the person managing the list at
> python-list-owner at python.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Python-list digest..."
>
> Today's Topics:
>
> 1. Re: Old Man Yells At Cloud (Dennis Lee Bieber)
> 2. Re: Old Man Yells At Cloud (Stefan Ram)
> 3. Re: Which database system? (Stefan Ram)
> 4. CPython has hit 100,000 commits (breamoreboy at gmail.com)
> 5. [RELEASE] Python 2.7.14 (Benjamin Peterson)
> 6. Research paper "Energy Efficiency across Programming
> Languages: How does energy, time, and memory relate?"
> (breamoreboy at gmail.com)
> 7. Re: Old Man Yells At Cloud (Steve D'Aprano)
> 8. Re: Old Man Yells At Cloud (John Pote)
> 9. Re: Old Man Yells At Cloud (Steve D'Aprano)
> 10. Re: Old Man Yells At Cloud (MRAB)
> 11. Re: Old Man Yells At Cloud (Chris Angelico)
> 12. Re: Old Man Yells At Cloud (Chris Angelico)
> 13. Re: Old Man Yells At Cloud (Dennis Lee Bieber)
> 14. Re: Research paper "Energy Efficiency across Programming
> Languages: How does energy, time, and memory relate?" (Steve
> D'Aprano)
> 15. Re: Old Man Yells At Cloud (Stefan Ram)
> 16. Re: Old Man Yells At Cloud (Paul Rubin)
> 17. Re: Research paper "Energy Efficiency across Programming
> Languages: How does energy, time, and memory relate?" (Ian Kelly)
> 18. Re: Old Man Yells At Cloud (Stefan Ram)
> 19. Re: ttk.Notebook Tabs Question (Abdur-Rahmaan Janhangeer)
> 20. Re: Research paper "Energy Efficiency across Programming
> Languages: How does energy, time, and memory relate?" (Terry Reedy)
> 21. Re: Research paper "Energy Efficiency across Programming
> Languages: How does energy, time, and memory relate?" (Chris
> Angelico)
> 22. Re: Research paper "Energy Efficiency across Programming
> Languages: How does energy, time, and memory relate?" (Terry Reedy)
> 23. Re: Old Man Yells At Cloud (Gregory Ewing)
> 24. Re: Old Man Yells At Cloud (Gregory Ewing)
> 25. Re: Old Man Yells At Cloud (mm0fmf)
> 26. Re: Old Man Yells At Cloud (Steve D'Aprano)
> 27. Re: Research paper "Energy Efficiency across Programming
> Languages: How does energy, time, and memory relate?" (Steve
> D'Aprano)
> 28. Re: Which database system? (Amirouche Boubekki)
> 29. Typo-squatting PyPi (Alain Ketterlin)
> 30. Re: Old Man Yells At Cloud (Leam Hall)
> 31. Re: Old Man Yells At Cloud (Abdur-Rahmaan Janhangeer)
> 32. speech_to_text python command not working (pizza python)
> 33. Re: Old Man Yells At Cloud (Leam Hall)
> 34. Re: Old Man Yells At Cloud (Chris Angelico)
> 35. Python built-ins versus Javascript [was Re: Old Man Yells At
> Cloud] (Steve D'Aprano)
> 36. Re: Old Man Yells At Cloud (Steve D'Aprano)
> 37. Unicode (was: Old Man Yells At Cloud) (Leam Hall)
> 38. Re: Unicode (was: Old Man Yells At Cloud) (Paul Moore)
> 39. Re: Unicode (was: Old Man Yells At Cloud) (Chris Angelico)
> 40. Re: Unicode (Leam Hall)
> 41. Re: Old Man Yells At Cloud (Steve D'Aprano)
> 42. Re: Unicode (Peter Otten)
>
>
> ---------- Forwarded message ----------
> From: Dennis Lee Bieber <wlfraed at ix.netcom.com>
> To: python-list at python.org
> Cc:
> Bcc:
> Date: Sat, 16 Sep 2017 12:52:59 -0400
> Subject: Re: Old Man Yells At Cloud
> On Sat, 16 Sep 2017 09:59:43 -0500, Tim Daneliuk <info at tundraware.com>
> declaimed the following:
>
>
>
> >Well, the whole integer floor division thing years ago was the beginning
> >of the end - Python was doomed ...
>
> Yes -- that would give me fits if I were using Python3 currently...
> Since so many of the languages I've learned over the past years use the
> concept integer / integer => integer_result
>
> Come to think of it -- wasn't there a post from someone (seems to
> expired or been filtered from my client) asking for help with some sorting
> program... I'm pretty sure the partitioning logic would croak on Python3
> due to floating point results in the slice indices:
>
> pA = part[:n/2]
> pB = part[n/2:]
>
> --
> Wulfraed Dennis Lee Bieber AF6VN
> wlfraed at ix.netcom.com HTTP://wlfraed.home.netcom.com/
>
>
>
>
> ---------- Forwarded message ----------
> From: Stefan Ram <ram at zedat.fu-berlin.de>
> To: python-list at python.org
> Cc:
> Bcc:
> Date: 16 Sep 2017 18:00:00 GMT
> Subject: Re: Old Man Yells At Cloud
> Steve D'Aprano <steve+python at pearwood.info> writes:
> >"Hi, I've been programming in Python for what seems like days now, and
> here's
> >all the things that you guys are doing wrong.
>
> I never ever have written a line of Python 2. I started with
> Python 3.6.0. Yet a very frequent mistake of mine is the
> imission of parentheses after »print«.
>
> WRT my other common errors, It thought of writing
> a program that autocorrects my source code as follows:
>
> Whenever the next line is indented more, add a colon:
>
> abd def ghi
> jkl mno pqr
>
> --------------------->
>
> abd def ghi:
> jkl mno pqr
>
> Whenever the next line is indented more, add "def" to
> what looks like a call (and does not start with »class«
> or »def«;
>
> f( x ):
> return x * x
>
> --------------------->
>
> def f( x ):
> return x * x
>
> Whenever a line starts with "print" and no parentheses
> are following, add them:
>
> print x, 2
>
> --------------------->
>
> print( x, 2 )
>
> Implementing algorithms from "The Art of Computer
> Programming" might sometimes be difficult in Python, since
> those algorithms IIRC often use »goto«.
>
>
>
>
> ---------- Forwarded message ----------
> From: Stefan Ram <ram at zedat.fu-berlin.de>
> To: python-list at python.org
> Cc:
> Bcc:
> Date: 16 Sep 2017 19:12:58 GMT
> Subject: Re: Which database system?
> Peter Otten <__peter__ at web.de> writes:
> >Based on the example I wonder if you really want a table, or whether
> >something tree-like would be more appropriate:
>
> Thanks for the suggestions!
>
> I will think about the tree approach.
>
>
>
>
> ---------- Forwarded message ----------
> From: breamoreboy at gmail.com
> To: python-list at python.org
> Cc:
> Bcc:
> Date: Sat, 16 Sep 2017 12:30:07 -0700 (PDT)
> Subject: CPython has hit 100,000 commits
> Looks as if people have been busy over the years. Read all about it
> https://github.com/python/cpython
>
> --
> Kindest regards.
>
> Mark Lawrence.
>
>
>
> ---------- Forwarded message ----------
> From: Benjamin Peterson <benjamin at python.org>
> To: "python-announce-list at python.org" <python-announce-list at python.org>, "
> python-list at python.org" <python-list at python.org>, python-dev at python.org
> Cc:
> Bcc:
> Date: Sat, 16 Sep 2017 15:05:32 -0700
> Subject: [RELEASE] Python 2.7.14
> I'm happy to announce to the immediate availability of Python 2.7.14,
> yet another bug fix release in the Python 2.7 series. 2.7.14 includes 9
> months of conservative bug fixes from the 3.x branch.
>
> Downloads of source code and binaries are at:
> https://www.python.org/downloads/release/python-2714/
>
> Bugs may be reported at
> https://bugs.python.org/
>
> Warmly,
> Benjamin
> 2.7 release manager
> (on behalf of all of 2.7's contributors)
>
>
>
> ---------- Forwarded message ----------
> From: breamoreboy at gmail.com
> To: python-list at python.org
> Cc:
> Bcc:
> Date: Sat, 16 Sep 2017 16:04:03 -0700 (PDT)
> Subject: Research paper "Energy Efficiency across Programming Languages:
> How does energy, time, and memory relate?"
> I thought some might find this https://sites.google.com/view/
> energy-efficiency-languages/ interesting.
>
> --
> Kindest regards.
>
> Mark Lawrence.
>
>
>
> ---------- Forwarded message ----------
> From: "Steve D'Aprano" <steve+python at pearwood.info>
> To: python-list at python.org
> Cc:
> Bcc:
> Date: Sun, 17 Sep 2017 11:00:42 +1000
> Subject: Re: Old Man Yells At Cloud
> On Sun, 17 Sep 2017 02:52 am, Dennis Lee Bieber wrote:
>
>
> > Yes -- that would give me fits if I were using Python3 currently...
> > Since so many of the languages I've learned over the past years use the
> > concept integer / integer => integer_result
>
> That would be C, and C derived languages, perhaps?
>
> Pascal uses integer / integer => float (except Pascal calls it "Real"). If
> you
> want integer division, use "div".
>
> I think so did Algol.
>
>
> > Come to think of it -- wasn't there a post from someone (seems to
> > expired or been filtered from my client) asking for help with some
> sorting
> > program... I'm pretty sure the partitioning logic would croak on Python3
> > due to floating point results in the slice indices:
> >
> > pA = part[:n/2]
> > pB = part[n/2:]
>
>
> If you want integer division, you have to use integer division :-)
>
> pA = part[:n//2]
>
>
>
> --
> Steve
> “Cheer up,” they said, “things could be worse.” So I cheered up, and sure
> enough, things got worse.
>
>
>
>
> ---------- Forwarded message ----------
> From: John Pote <johnpote at jptechnical.co.uk>
> To: python-list at python.org
> Cc:
> Bcc:
> Date: Sun, 17 Sep 2017 01:15:41 +0100
> Subject: Re: Old Man Yells At Cloud
>
>
> On 16/09/2017 19:00, Stefan Ram wrote:
>
>> Steve D'Aprano <steve+python at pearwood.info> writes:
>>
>>> "Hi, I've been programming in Python for what seems like days now, and
>>> here's
>>> all the things that you guys are doing wrong.
>>>
>> I never ever have written a line of Python 2. I started with
>> Python 3.6.0. Yet a very frequent mistake of mine is the
>> imission of parentheses after »print«.
>>
>> WRT my other common errors, It thought of writing
>> a program that autocorrects my source code as follows:
>>
>> Whenever the next line is indented more, add a colon:
>>
>> abd def ghi
>> jkl mno pqr
>>
> I've used Komodo in the past and that editor works other way round, type a
> ':' at the end of a line and the next line is indented. I would presume
> other language aware editors take the same approach.
> print """
> Your idea would require considerable inteligence in the editor,
> 1. Otherwise the previous line would print with a ':'
> 2. That would frustrate me.....
> """
>
>>
>> --------------------->
>>
>> abd def ghi:
>> jkl mno pqr
>>
>> Whenever the next line is indented more, add "def" to
>> what looks like a call (and does not start with »class«
>> or »def«;
>>
>> f( x ):
>> return x * x
>>
>> --------------------->
>>
>> def f( x ):
>> return x * x
>>
>> Whenever a line starts with "print" and no parentheses
>> are following, add them:
>>
>> print x, 2
>>
> Strangely I find it irksome to have to write print as a function call in
> Python 3. Must reflect those long ago days when I started to program (oops,
> I mean code - programming came later). Come to think of it there's
> something irksome about every language I've ever used. Python probably the
> least.....
>
>>
>> --------------------->
>> print( x, 2 )
>>
>> Implementing algorithms from "The Art of Computer
>> Programming" might sometimes be difficult in Python, since
>> those algorithms IIRC often use »goto«.
>>
> Good point. I also have a copy of that work of art (and the fascicles - I
> must get out more). Sadly little work these days requires diving into them.
> In fairness to Knuth his pseudo code is a high level assembler fully
> described in Vol:1 and done as such so folk from any high level language
> background could follow the algorithms. Back then many like myself, or
> indeed most coders, had a hardware background and well used to assembler.
> The nearest thing most silicon has to structured programming is call and
> return, gotos are everywhere.
> I always think one of the reasons Basic became so popular was its /goto
> /statement. The other was the run command, no need to compile.
> See /http://entrian.com/goto// for a Python implementation from many
> years ago. No idea if it still works. To be honist never needed it - Python
> has exceptions.
> Also there was a interesting thread '/"Goto" statement in Python/' in
> April this year (not the 1st). Although mainly interesting for its
> references to gotos in 'C' which I use daily now. err 'C' that is. . . . . .
> Used to wind up colleagues by saying loudly "Great, I can use a /*goto
> */here.....". This attracted considerable verbal abuse from purists in
> earshot and instruction from the boss NOT TO which I pretended to ignore.
> After all Python programming is supposed to be fun!
>
>
>>
>
>
>
> ---------- Forwarded message ----------
> From: "Steve D'Aprano" <steve+python at pearwood.info>
> To: python-list at python.org
> Cc:
> Bcc:
> Date: Sun, 17 Sep 2017 11:09:18 +1000
> Subject: Re: Old Man Yells At Cloud
> On Sun, 17 Sep 2017 04:00 am, Stefan Ram wrote:
>
> > Steve D'Aprano <steve+python at pearwood.info> writes:
> >>"Hi, I've been programming in Python for what seems like days now, and
> here's
> >>all the things that you guys are doing wrong.
> >
> > I never ever have written a line of Python 2. I started with
> > Python 3.6.0. Yet a very frequent mistake of mine is the
> > imission of parentheses after »print«.
>
> That's remarkable.
>
> Do you also forget the parentheses around `len`, and `iter`, and
> `math.sin()`?
> If not, what's so special about print?
>
> Javascript (at least the Rhino interpreter, if not others) includes a print
> function. It too requires parentheses:
>
> js> print 21
> js: "<stdin>", line 5: missing ; before statement
> js: print 21
> js: .......^
> js> print(21)
> 21
>
>
> > WRT my other common errors, It thought of writing
> > a program that autocorrects my source code as follows:
> [...]
> > Whenever the next line is indented more, add "def" to
> > what looks like a call (and does not start with »class«
> > or »def«;
> >
> > f( x ):
> > return x * x
>
> Seriously Stefan, forgetting colons is one thing, but if you regularly
> forget to
> start function definitions with "def", I fear that you're just not paying
> attention to what you are doing.
>
> Do you occasionally find yourself halfway down the street after leaving
> home
> when you realise you're not wearing any pants? :-)
>
>
>
> --
> Steve
> “Cheer up,” they said, “things could be worse.” So I cheered up, and sure
> enough, things got worse.
>
>
>
>
> ---------- Forwarded message ----------
> From: MRAB <python at mrabarnett.plus.com>
> To: python-list at python.org
> Cc:
> Bcc:
> Date: Sun, 17 Sep 2017 02:28:37 +0100
> Subject: Re: Old Man Yells At Cloud
> On 2017-09-17 02:00, Steve D'Aprano wrote:
>
>> On Sun, 17 Sep 2017 02:52 am, Dennis Lee Bieber wrote:
>>
>>
>> Yes -- that would give me fits if I were using Python3 currently...
>>> Since so many of the languages I've learned over the past years use the
>>> concept integer / integer => integer_result
>>>
>>
>> That would be C, and C derived languages, perhaps?
>>
>> Or Fortran.
>
> [snip]
>
>
>
> ---------- Forwarded message ----------
> From: Chris Angelico <rosuav at gmail.com>
> To: "python-list at python.org" <python-list at python.org>
> Cc:
> Bcc:
> Date: Sun, 17 Sep 2017 11:42:05 +1000
> Subject: Re: Old Man Yells At Cloud
> On Sun, Sep 17, 2017 at 11:28 AM, MRAB <python at mrabarnett.plus.com> wrote:
> > On 2017-09-17 02:00, Steve D'Aprano wrote:
> >>
> >> On Sun, 17 Sep 2017 02:52 am, Dennis Lee Bieber wrote:
> >>
> >>
> >>> Yes -- that would give me fits if I were using Python3 currently...
> >>> Since so many of the languages I've learned over the past years use the
> >>> concept integer / integer => integer_result
> >>
> >>
> >> That would be C, and C derived languages, perhaps?
> >>
> > Or Fortran.
>
> Or machine code on every CPU I've ever worked with. Dividing integers
> yields an integer.
>
> ChrisA
>
>
>
> ---------- Forwarded message ----------
> From: Chris Angelico <rosuav at gmail.com>
> To: "python-list at python.org" <python-list at python.org>
> Cc:
> Bcc:
> Date: Sun, 17 Sep 2017 11:42:22 +1000
> Subject: Re: Old Man Yells At Cloud
> On Sun, Sep 17, 2017 at 11:42 AM, Chris Angelico <rosuav at gmail.com> wrote:
> > On Sun, Sep 17, 2017 at 11:28 AM, MRAB <python at mrabarnett.plus.com>
> wrote:
> >> On 2017-09-17 02:00, Steve D'Aprano wrote:
> >>>
> >>> On Sun, 17 Sep 2017 02:52 am, Dennis Lee Bieber wrote:
> >>>
> >>>
> >>>> Yes -- that would give me fits if I were using Python3 currently...
> >>>> Since so many of the languages I've learned over the past years use
> the
> >>>> concept integer / integer => integer_result
> >>>
> >>>
> >>> That would be C, and C derived languages, perhaps?
> >>>
> >> Or Fortran.
> >
> > Or machine code on every CPU I've ever worked with. Dividing integers
> > yields an integer.
>
> (Or more technically, yields two integers - div/mod)
>
> ChrisA
>
>
>
> ---------- Forwarded message ----------
> From: Dennis Lee Bieber <wlfraed at ix.netcom.com>
> To: python-list at python.org
> Cc:
> Bcc:
> Date: Sat, 16 Sep 2017 21:56:25 -0400
> Subject: Re: Old Man Yells At Cloud
> On Sun, 17 Sep 2017 11:00:42 +1000, Steve D'Aprano
> <steve+python at pearwood.info> declaimed the following:
>
> >On Sun, 17 Sep 2017 02:52 am, Dennis Lee Bieber wrote:
> >
> >
> >> Yes -- that would give me fits if I were using Python3 currently...
> >> Since so many of the languages I've learned over the past years use the
> >> concept integer / integer => integer_result
> >
> >That would be C, and C derived languages, perhaps?
> >
>
> FORTRAN, C/C++, Ada (and, of course, Python 1.4 or thereabouts
> through
> 2.x)
>
> >
> >
> >If you want integer division, you have to use integer division :-)
> >
> >pA = part[:n//2]
> >
> My thought was that the OP of the sort question might have been
> using a
> 2.x source, but running a 3.x Python... Since they didn't provide any
> explanation of what the wrong behavior was I couldn't comment on if it were
> a traceback for having a float index, or some other matter.
> --
> Wulfraed Dennis Lee Bieber AF6VN
> wlfraed at ix.netcom.com HTTP://wlfraed.home.netcom.com/
>
>
>
>
> ---------- Forwarded message ----------
> From: "Steve D'Aprano" <steve+python at pearwood.info>
> To: python-list at python.org
> Cc:
> Bcc:
> Date: Sun, 17 Sep 2017 12:01:25 +1000
> Subject: Re: Research paper "Energy Efficiency across Programming
> Languages: How does energy, time, and memory relate?"
> On Sun, 17 Sep 2017 09:04 am, breamoreboy at gmail.com wrote:
>
> > I thought some might find this
> > https://sites.google.com/view/energy-efficiency-languages/ interesting.
>
> "Made with the new Google Sites, an effortless way to create beautiful
> sites."
>
> More like an effortless way to create a complete dog's breakfast. Once
> upon a
> time, web sites would degrade gracefully. If something interrupted the page
> loading, or something wasn't quite right, or you'd still get something
> usable.
> Now, if the tiniest thing goes wrong, you get a junk.
>
> I've tried to see the results, but I just get a bunch of broken images :-(
>
>
> On the linked page, starting from the top and scrolling down, I see:
>
> - about two screens worth of black white space;
>
> - followed by three giant black horizontal bars, each one about an inch
> high;
>
> - more white space;
>
> - what looks like something that was intended to be a side-bar, containing:
>
> SLE'17
> Home
> Results
> Setup
> More
>
> - a giant down-pointing arrowhead, about three inches tall, which turns
> grey when you mouse-over it but doesn't do anything when clicked;
>
> - three more links:
>
> Home
> Results
> Setup
>
> which disappear when you mouse-over them;
>
> - finally some content!
>
> The tools and graphical data pointed by this page are included in the
> research paper "Energy Efficiency across Programming Languages: How
> does
> Energy, Time and Memory Relate?", accepted at the International
> Conference
> on Software Language Engineering (SLE)
>
> [1] Measuring Framework & Benchmarks
> [2] Complete Set of Results
> [3] Setup
> [4] Paper
>
>
> where the last four bits are links;
>
> - the smug, self-congratulatory comment quoted above about "beautiful
> sites";
>
> - a button "Create a site"
>
> - What was presumably intended to be a link, but is actually just a piece
> of
> plain text: "Report abuse";
>
> - more whitespace;
>
> - and finally a giant blue "i", pointed at the bottom, and slanted at 45
> degrees. Presumably a logo for somebody or something.
>
>
> And yes, I am allowing scripts from Google and Gstatic to run, and the
> page is
> still broken.
>
>
> Including the hyperlinks, that's about 700 bytes of actual content. Let's
> double
> it for the overhead of HTML over plain text, so somewhat less than 1.5 KiB
> of
> content.
>
> The actual page is 27285 bytes or over 26 KiB. That gives us something
> with a
> useful content to bloat factor of 1:17, and *the page still doesn't work.*
>
> And that's not even counting any additional files the page requires, like
> CSS,
> external javascript files, images, ads, web-bugs, etc. You want to know why
> browsing the web today on full ADSL or faster speeds is *slower* than
> using a
> dial up modem in the 1990s? This is why.
>
> www.antipope.org/charlie/blog-static/2008/05/why_your_
> internet_experience_i.html
>
> Nine years later, and the problem is worse, not better.
>
>
>
>
> --
> Steve
> “Cheer up,” they said, “things could be worse.” So I cheered up, and sure
> enough, things got worse.
>
>
>
>
> ---------- Forwarded message ----------
> From: Stefan Ram <ram at zedat.fu-berlin.de>
> To: python-list at python.org
> Cc:
> Bcc:
> Date: 17 Sep 2017 03:37:43 GMT
> Subject: Re: Old Man Yells At Cloud
> Steve D'Aprano <steve+python at pearwood.info> writes:
> >Do you also forget the parentheses around `len`, and `iter`, and
> `math.sin()`?
>
> (Parentheses around `len`, and `iter`, and `math.sin()`?
> Like in »(len)«, »(iter)«, and »(math.sin())«? No, whenever
> I write in LISP, I do not forget them.)
>
> No. I also not forget them after
> »java.lang.System.out.println«.
>
> >If not, what's so special about print?
>
> Maybe it's a habit of an old BASIC programmer. It might
> be triggered by a line starting with the word »print«.
>
> >Do you occasionally find yourself halfway down the street after leaving
> home
> >when you realise you're not wearing any pants? :-)
>
> So far, this only happened in dreams IIRC, it surely was
> embarrassing.
>
>
>
>
> ---------- Forwarded message ----------
> From: Paul Rubin <no.email at nospam.invalid>
> To: python-list at python.org
> Cc:
> Bcc:
> Date: Sat, 16 Sep 2017 21:07:57 -0700
> Subject: Re: Old Man Yells At Cloud
> Steve D'Aprano <steve+python at pearwood.info> writes:
> >> concept integer / integer => integer_result
> > That would be C, and C derived languages, perhaps?
>
> Certainly not. Fortran, machine languages, etc. all do that too.
>
> Haskell does the right thing and makes int/int a compile time type
> error. Its integer division functions are div and quot.
>
> Python 2 does something reasonable and Python 3 does something that is
> also debatably reasonable. Switching from one reasonable thing to
> another without a very good reason is called fixing things that weren't
> broken. Python 2 wasn't broken in that area and didn't need to be
> fixed.
>
>
>
> ---------- Forwarded message ----------
> From: Ian Kelly <ian.g.kelly at gmail.com>
> To: Python <python-list at python.org>
> Cc:
> Bcc:
> Date: Sat, 16 Sep 2017 22:22:32 -0600
> Subject: Re: Research paper "Energy Efficiency across Programming
> Languages: How does energy, time, and memory relate?"
> On Sat, Sep 16, 2017 at 8:01 PM, Steve D'Aprano
> <steve+python at pearwood.info> wrote:
> > On Sun, 17 Sep 2017 09:04 am, breamoreboy at gmail.com wrote:
> >
> >> I thought some might find this
> >> https://sites.google.com/view/energy-efficiency-languages/ interesting.
> >
> > "Made with the new Google Sites, an effortless way to create beautiful
> sites."
> >
> > More like an effortless way to create a complete dog's breakfast. Once
> upon a
> > time, web sites would degrade gracefully. If something interrupted the
> page
> > loading, or something wasn't quite right, or you'd still get something
> usable.
> > Now, if the tiniest thing goes wrong, you get a junk.
> >
> > I've tried to see the results, but I just get a bunch of broken images
> :-(
> >
> >
> > On the linked page, starting from the top and scrolling down, I see:
> >
> > - about two screens worth of black white space;
> >
> > - followed by three giant black horizontal bars, each one about an inch
> high;
> >
> > - more white space;
> >
> > - what looks like something that was intended to be a side-bar,
> containing:
> >
> > SLE'17
> > Home
> > Results
> > Setup
> > More
> >
> > - a giant down-pointing arrowhead, about three inches tall, which turns
> > grey when you mouse-over it but doesn't do anything when clicked;
> >
> > - three more links:
> >
> > Home
> > Results
> > Setup
> >
> > which disappear when you mouse-over them;
> >
> > - finally some content!
> >
> > The tools and graphical data pointed by this page are included in the
> > research paper "Energy Efficiency across Programming Languages: How
> does
> > Energy, Time and Memory Relate?", accepted at the International
> Conference
> > on Software Language Engineering (SLE)
> >
> > [1] Measuring Framework & Benchmarks
> > [2] Complete Set of Results
> > [3] Setup
> > [4] Paper
> >
> >
> > where the last four bits are links;
> >
> > - the smug, self-congratulatory comment quoted above about "beautiful
> sites";
> >
> > - a button "Create a site"
> >
> > - What was presumably intended to be a link, but is actually just a
> piece of
> > plain text: "Report abuse";
> >
> > - more whitespace;
> >
> > - and finally a giant blue "i", pointed at the bottom, and slanted at 45
> > degrees. Presumably a logo for somebody or something.
> >
> >
> > And yes, I am allowing scripts from Google and Gstatic to run, and the
> page is
> > still broken.
>
> It looks fine to me.
>
>
> > Including the hyperlinks, that's about 700 bytes of actual content.
> Let's double
> > it for the overhead of HTML over plain text, so somewhat less than 1.5
> KiB of
> > content.
> >
> > The actual page is 27285 bytes or over 26 KiB. That gives us something
> with a
> > useful content to bloat factor of 1:17, and *the page still doesn't
> work.*
> >
> > And that's not even counting any additional files the page requires,
> like CSS,
> > external javascript files, images, ads, web-bugs, etc. You want to know
> why
> > browsing the web today on full ADSL or faster speeds is *slower* than
> using a
> > dial up modem in the 1990s? This is why.
> >
> > www.antipope.org/charlie/blog-static/2008/05/why_your_
> internet_experience_i.html
> >
> > Nine years later, and the problem is worse, not better.
>
> If you're using a cell phone over 2G, then I tentatively agree. But on
> my laptop over WiFi, this page that you're complaining about loaded in
> 783 ms when I tried it.
>
>
>
> ---------- Forwarded message ----------
> From: Stefan Ram <ram at zedat.fu-berlin.de>
> To: python-list at python.org
> Cc:
> Bcc:
> Date: 17 Sep 2017 04:31:00 GMT
> Subject: Re: Old Man Yells At Cloud
> Paul Rubin <no.email at nospam.invalid> writes:
> >Haskell does the right thing and makes int/int a compile time type
> >error. Its integer division functions are div and quot.
>
> In VBA, one uses »\« for integer division, which just so
> happens to be the symbol that also is used for integer
> division in traditional mathematics. (And also for set
> difference IIRC.)
>
> >Python 2 does something reasonable and Python 3 does something that is
> >also debatably reasonable. Switching from one reasonable thing to
> >another without a very good reason is called fixing things that weren't
> >broken. Python 2 wasn't broken in that area and didn't need to be
> >fixed.
>
> I agree.
>
> However, not having octal literals, like »0123«, and »3/2«
> having decimal places makes teaching to beginners slightly
> more easy.
>
>
>
>
> ---------- Forwarded message ----------
> From: Abdur-Rahmaan Janhangeer <arj.python at gmail.com>
> To: Wildman <best_lay at yahoo.com>
> Cc: python-list at python.org
> Bcc:
> Date: Sun, 17 Sep 2017 08:45:27 +0400
> Subject: Re: ttk.Notebook Tabs Question
> by widget["width"] i meant replace widget with your widget
>
> Abdur-Rahmaan Janhangeer,
> Mauritius
> abdurrahmaanjanhangeer.wordpress.com
>
> On 12 Sep 2017 06:45, "Wildman via Python-list" <python-list at python.org>
> wrote:
>
> > I am working on a program that has a ttk.Notebook with
> > 12 tabs. Is there a way to determine the total width
> > of the tabs in pixels. Just to be clear I am not talking
> > about width of the nb container. I am talking about
> > tabs themselves that contain the text.
> >
> > I want the program to be resizable but I don't want to
> > allow the window width to fall below that of the tabs
> > which would hide them. Since I can find no way to have
> > more than one row of tabs, this appears to be my only
> > option. Any suggestions would be appreciated.
> >
> > --
> > <Wildman> GNU/Linux user #557453
> > May the Source be with you.
> > --
> > https://mail.python.org/mailman/listinfo/python-list
> >
>
>
>
> ---------- Forwarded message ----------
> From: Terry Reedy <tjreedy at udel.edu>
> To: python-list at python.org
> Cc:
> Bcc:
> Date: Sun, 17 Sep 2017 02:00:25 -0400
> Subject: Re: Research paper "Energy Efficiency across Programming
> Languages: How does energy, time, and memory relate?"
> On 9/16/2017 7:04 PM, breamoreboy at gmail.com wrote:
>
>> I thought some might find this https://sites.google.com/view/
>> energy-efficiency-languages/ interesting.
>>
>
> By 'energy', they only mean electricity, not food calories. This is the
> email I sent to the authors.
> -----------
>
> As a two-decade user of Python, I was interested to read your paper.
> Unfortunately, it is deeply flawed with respect to Python in the sense that
> your conclusions are inapplicable to real-world usage of Python.
>
> The problem is your use of the Computer Language Benchmark Game. As the
> name says, it is a *game*. As a game, it has artificial rules dictated by
> the game masters. It uses toy problems, and for Python, the rules dictate
> unrealistic toy solutions. In particular, it appears to disallow use of
> 'import' with 3rd-party modules, whereas real-world Python is expected to
> use them, and nearly always does.
>
> The particular crippler for CLBG problems is the non-use of numpy in
> numerical calculations, such as the n-body problem. Numerical python
> extensions are over two decades old and give Python code access to
> optimized, compiled BLAS, LinPack, FFTPack, and so on. The current one,
> numpy, is the third of the series. It is both a historical accident and a
> continuing administrative convenience that numpy is not part of the Python
> stdlib. However, it is easily installed from the PSF-maintained repository
> (python -m pip install numpy), and is included with most third-party
> distributions of Python.
>
> The numerical extensions have been quasi-official in the sense that at
> least 3 language enhancements have been make for their use. Nearly all
> real-world scientific, financial, and neural-network Python programs are
> build on top of numpy. When a Python program spend 95% of the time in the
> optimized compiled C routines, it is nearly as fast as a 100% C solution.
> The reason people use Python instead of C for the other 5% is to save human
> time.
>
> Even when it come to executing the pure Python solutions, the CLBG rules
> apparently require the slowest execution possible. Execution would be at
> least 2 to 5 times faster if compilation to machine code were allowed,
> either before or during execution. But the point of the game is to provide
> a 'level' playing field for competition between Python programmers, even if
> the cost is to cripple comparison with other language solution.
>
> Terry Jan Reedy
>
>
>
>
> --
> Terry Jan Reedy
>
>
>
>
> ---------- Forwarded message ----------
> From: Chris Angelico <rosuav at gmail.com>
> To: "python-list at python.org" <python-list at python.org>
> Cc:
> Bcc:
> Date: Sun, 17 Sep 2017 16:04:32 +1000
> Subject: Re: Research paper "Energy Efficiency across Programming
> Languages: How does energy, time, and memory relate?"
> On Sun, Sep 17, 2017 at 4:00 PM, Terry Reedy <tjreedy at udel.edu> wrote:
> > The numerical extensions have been quasi-official in the sense that at
> least
> > 3 language enhancements have been make for their use.
>
> I know about the matrix multiplication operator. What are the other
> two (or more)?
>
> ChrisA
>
>
>
> ---------- Forwarded message ----------
> From: Terry Reedy <tjreedy at udel.edu>
> To: python-list at python.org
> Cc:
> Bcc:
> Date: Sun, 17 Sep 2017 02:16:42 -0400
> Subject: Re: Research paper "Energy Efficiency across Programming
> Languages: How does energy, time, and memory relate?"
> On 9/17/2017 2:04 AM, Chris Angelico wrote:
>
>> On Sun, Sep 17, 2017 at 4:00 PM, Terry Reedy <tjreedy at udel.edu> wrote:
>>
>>> The numerical extensions have been quasi-official in the sense that at
>>> least
>>> 3 language enhancements have been make for their use.
>>>
>>
>> I know about the matrix multiplication operator. What are the other
>> two (or more)?
>>
>
> Stride slicing, which later became valid in regular code, and Ellipsis. (I
> could be wrong on the latter.)
>
> --
> Terry Jan Reedy
>
>
>
>
> ---------- Forwarded message ----------
> From: Gregory Ewing <greg.ewing at canterbury.ac.nz>
> To: python-list at python.org
> Cc:
> Bcc:
> Date: Sun, 17 Sep 2017 18:19:59 +1200
> Subject: Re: Old Man Yells At Cloud
> Chris Angelico wrote:
>
>> Or machine code on every CPU I've ever worked with. Dividing integers
>> yields an integer.
>>
>
> Every machine language I've used has different sets
> of instructions for int and float arithmetic, so
> there's no chance of confusion.
>
> --
> Greg
>
>
>
> ---------- Forwarded message ----------
> From: Gregory Ewing <greg.ewing at canterbury.ac.nz>
> To: python-list at python.org
> Cc:
> Bcc:
> Date: Sun, 17 Sep 2017 18:27:37 +1200
> Subject: Re: Old Man Yells At Cloud
> Paul Rubin wrote:
>
>> Python 2 does something reasonable
>>
>
> I don't agree. It might be reasonable in a statically-typed
> language, but in a dynamically-typed language where you're
> encouraged to use ints as stand-ins for integer-valued floats,
> it's an invitation for trouble. There are good reasons it was
> changed in Python 3.
>
> --
> Greg
>
>
>
> ---------- Forwarded message ----------
> From: mm0fmf <none at invalid.com>
> To: python-list at python.org
> Cc:
> Bcc:
> Date: Sun, 17 Sep 2017 07:56:39 +0100
> Subject: Re: Old Man Yells At Cloud
> On 16/09/2017 17:52, Dennis Lee Bieber wrote:
>
>> On Sat, 16 Sep 2017 09:59:43 -0500, Tim Daneliuk <info at tundraware.com>
>> declaimed the following:
>>
>>
>>
>> Well, the whole integer floor division thing years ago was the beginning
>>> of the end - Python was doomed ...
>>>
>>
>> Yes -- that would give me fits if I were using Python3
>> currently...
>> Since so many of the languages I've learned over the past years use the
>> concept integer / integer => integer_result
>>
>> Come to think of it -- wasn't there a post from someone (seems to
>> expired or been filtered from my client) asking for help with some sorting
>> program... I'm pretty sure the partitioning logic would croak on Python3
>> due to floating point results in the slice indices:
>>
>> pA = part[:n/2]
>> pB = part[n/2:]
>>
>>
> What does 2to3 do when fed code involving division?
>
> I've only used it once and did good job on the code I fed it. But it would
> not have been too hard to manually convert the Python2 code in that case.
>
>
>
> ---------- Forwarded message ----------
> From: "Steve D'Aprano" <steve+python at pearwood.info>
> To: python-list at python.org
> Cc:
> Bcc:
> Date: Sun, 17 Sep 2017 17:54:24 +1000
> Subject: Re: Old Man Yells At Cloud
> On Sun, 17 Sep 2017 02:07 pm, Paul Rubin wrote:
>
> > Steve D'Aprano <steve+python at pearwood.info> writes:
> >>> concept integer / integer => integer_result
> >> That would be C, and C derived languages, perhaps?
> >
> > Certainly not. Fortran, machine languages, etc. all do that too.
> >
> > Haskell does the right thing and makes int/int a compile time type
> > error.
>
> Its not the right thing. Pascal did the right thing: int/int returns a
> floating
> point value. Python does the right thing. Pocket calculators do the right
> thing.
>
> Haskell is great in many ways, but it is also obnoxiously pedantic about
> type
> safety. At the point that the compiler won't even automatically coerce
> ints to
> floats, but requires you to sign a release form that you take all
> responsibility for it, er I mean manually do the coercion yourself, that's
> excessive.
>
> There's no reason why they couldn't have allowed int/int to return a float
> of
> some sort, or a fraction if they want to be exact. In my arrogant opinion,
> its
> just obnoxious, pretentious purity-beyond-all-sense to make "int / int" an
> error. Its not like division on integers is undefined, its just not
> closed, but
> lots of operations in Haskell aren't closed. The Haskell equivalent of
> len(some_string) does not return a string.
>
> To even *know* that there are branches of maths where int/int isn't
> defined, you
> need to have learned aspects of mathematics that aren't even taught in most
> undergrad maths degrees. (I have a degree in maths, and if we ever covered
> areas where int/int was undefined, it was only briefly, and I've long since
> forgotten it.)
>
> There's a perfectly good, almost intuitive, understanding of int/int
> giving some
> sort of rational value. Why don't they use it? They go so far as to
> provide two
> pairs of division/remainder functions, differing only in their treatment of
> negative values:
>
> (x ‘quot‘ y)⋆y + (x ‘rem‘ y) == x
> (x ‘div‘ y)⋆y + (x ‘mod‘ y) == x
>
> but can't provide an operator to do ordinary rational-valued division.
>
>
> > Its integer division functions are div and quot.
>
> quot is "integer division truncated toward zero", div is "integer division
> truncated toward negative infinity".
>
>
>
> > Python 2 does something reasonable
>
> Except that it isn't. It's surprising, and error prone, and was changed
> because
> it was a bug magnet.
>
>
> > and Python 3 does something that is
> > also debatably reasonable. Switching from one reasonable thing to
> > another without a very good reason is called fixing things that weren't
> > broken. Python 2 wasn't broken in that area and didn't need to be
> > fixed.
>
> Python 2 was badly broken in this area. The / operator doing integer
> division on
> integers and true division on everything else was a constant source of
> pain and
> silent errors. You would write a perfectly reasonable maths expression:
>
> y = math.sin((2*x - 1)/(3*x + 1))
>
> and test it with floats and it would work perfectly, then some day someone
> slips
> an integer into x and you silently get garbage output, which you would
> probably
> never even realise.
>
>
>
>
> --
> Steve
> “Cheer up,” they said, “things could be worse.” So I cheered up, and sure
> enough, things got worse.
>
>
>
>
> ---------- Forwarded message ----------
> From: "Steve D'Aprano" <steve+python at pearwood.info>
> To: python-list at python.org
> Cc:
> Bcc:
> Date: Sun, 17 Sep 2017 18:14:37 +1000
> Subject: Re: Research paper "Energy Efficiency across Programming
> Languages: How does energy, time, and memory relate?"
> On Sun, 17 Sep 2017 04:16 pm, Terry Reedy wrote:
>
> > On 9/17/2017 2:04 AM, Chris Angelico wrote:
> >> On Sun, Sep 17, 2017 at 4:00 PM, Terry Reedy <tjreedy at udel.edu> wrote:
> >>> The numerical extensions have been quasi-official in the sense that at
> least
> >>> 3 language enhancements have been make for their use.
> >>
> >> I know about the matrix multiplication operator. What are the other
> >> two (or more)?
> >
> > Stride slicing, which later became valid in regular code, and Ellipsis.
> > (I could be wrong on the latter.)
>
>
> Nope, both are correct.
>
> Slice strides were first supported in Python 1.4, but used exclusively by
> Numerical Python (numpy's ancient predecessor), and didn't finally get
> supported by Python builtins until as late as version 2.3!
>
> https://docs.python.org/2.3/whatsnew/section-slices.html
>
> Ellipsis was used for multi-dimensional slicing, and was added for
> Numerical
> Python. It wasn't until recently (Python 3.4 perhaps?) that it finally
> became
> legal to write '...' instead of 'Ellipsis' outside of slice notation.
>
> Here's Peter Otten talking about it way back in 2004:
>
> http://grokbase.com/t/python/python-list/042jd5y60n/ellipsis-usage
>
>
>
>
> --
> Steve
> “Cheer up,” they said, “things could be worse.” So I cheered up, and sure
> enough, things got worse.
>
>
>
>
> ---------- Forwarded message ----------
> From: Amirouche Boubekki <amirouche.boubekki at gmail.com>
> To: Stefan Ram <ram at zedat.fu-berlin.de>
> Cc: python-list <python-list at python.org>
> Bcc:
> Date: Sun, 17 Sep 2017 01:21:21 -0700
> Subject: Re: Which database system?
> Le 15 sept. 2017 20:05, "Stefan Ram" <ram at zedat.fu-berlin.de> a écrit :
>
> When one is building an in-memory database that has a single
> table that is built at the start of the program and then one
> writes some complex queries to the table, what can be expected
> to be faster:
>
> - implementing the table as a builtins.list of builtins.tuples
> with builtins.dicts as indexes for faster lookups and
> additional sorted builtins.lists for sorted "views" on the
> table
>
> - implementing the table as a database table in sqlite3
> (":memory:") and using SQL commands for insertion
>
>
> There is other solutions like shelve mentioned previously or plyvel (easy
> api) or my preferred wiredtiger. But the issue with maintenance costs is
> still valid. Choose the later if nothing else works.
>
>
>
> ---------- Forwarded message ----------
> From: Alain Ketterlin <alain at universite-de-strasbourg.fr.invalid>
> To: python-list at python.org
> Cc:
> Bcc:
> Date: Sun, 17 Sep 2017 10:37:24 +0200
> Subject: Typo-squatting PyPi
>
> In case you haven't heard about this:
>
> https://developers.slashdot.org/story/17/09/16/2030229/
> pythons-official-repository-included-10-malicious-typo-squatting-modules
>
> Here is the Slashdot summary:
>
> | The Slovak National Security Office (NBU) has identified ten malicious
> | Python libraries uploaded on PyPI -- Python Package Index -- the
> | official third-party software repository for the Python programming
> | language. NBU experts say attackers used a technique known as
> | typosquatting to upload Python libraries with names similar to
> | legitimate packages -- e.g.: "urlib" instead of "urllib." The PyPI
> | repository does not perform any types of security checks or audits
> | when developers upload new libraries to its index, so attackers had no
> | difficulty in uploading the modules online.
> |
> | Developers who mistyped the package name loaded the malicious
> | libraries in their software's setup scripts. "These packages contain
> | the exact same code as their upstream package thus their functionality
> | is the same, but the installation script, setup.py, is modified to
> | include a malicious (but relatively benign) code," NBU explained.
> | Experts say the malicious code only collected information on infected
> | hosts, such as name and version of the fake package, the username of
> | the user who installed the package, and the user's computer hostname.
> | Collected data, which looked like "Y:urllib-1.21.1 admin testmachine",
> | was uploaded to a Chinese IP address. NBU officials contacted PyPI
> | administrators last week who removed the packages before officials
> | published a security advisory on Saturday."
>
> -- Alain.
>
>
>
> ---------- Forwarded message ----------
> From: Leam Hall <leamhall at gmail.com>
> To: "python-list at python.org" <python-list at python.org>
> Cc:
> Bcc:
> Date: Sun, 17 Sep 2017 06:03:16 -0400
> Subject: Re: Old Man Yells At Cloud
> Different view, I guess. I'm glad all the young Javascripters have that
> issue. As an old guy trying to re-learn more python it gives me an
> advantage. I'm usually interested in the best thislanguage-native way to do
> something. Doing so makes me learn the language faster and tends to
> generate better code.
>
> That said, I'll often steal what I've learned before to understand the
> new. Some helpful folks on IRC asked why I was using getopt instead of
> argparse. Mostly because I come from a bash background. Looking at Python's
> argparse would have stumped me if I hadn't already done the same thing with
> Ruby's argparse.
>
> I'm still trying to figure out how to convert a string to unicode in
> Python 2. I've done it in Ruby 1.8.7 so I assume Python 2 can do it and
> that I'm just a bit slow.
>
> Leam
>
>
>
> ---------- Forwarded message ----------
> From: Abdur-Rahmaan Janhangeer <arj.python at gmail.com>
> To: "Steve D'Aprano" <steve+python at pearwood.info>
> Cc: python-list at python.org
> Bcc:
> Date: Sun, 17 Sep 2017 14:02:47 +0400
> Subject: Re: Old Man Yells At Cloud
> as someone who really dislike js, i have to admit : python's globals are
> really really bad !
>
> js is a charm at that a real charm !
>
> Abdur-Rahmaan Janhangeer,
> Mauritius
> abdurrahmaanjanhangeer.wordpress.com
>
> On 16 Sep 2017 09:40, "Steve D'Aprano" <steve+python at pearwood.info> wrote:
>
> > /rant on
> >
> > So apparently everyone who disagrees that Python should be more like
> > Javascript
> > is an old greybeard fuddy-duddy yelling "Get off my lawn!" to the cool
> > kids --
> > and is also too stupid to know how dumb they are.
> >
> > "Hi, I've been programming in Python for what seems like days now, and
> > here's
> > all the things that you guys are doing wrong. I insist that you fix them
> > immediately, it doesn't matter how much code it will break, that's not
> > important. What is important is that Javascript programmers like me
> > shouldn't
> > be expected to learn anything new or different when they program with
> > Python."
> >
> > /rant off
> >
> > And no, for once it wasn't Ranting Rick.
> >
> >
> >
> >
> > --
> > Steve
> > “Cheer up,” they said, “things could be worse.” So I cheered up, and sure
> > enough, things got worse.
> >
> > --
> > https://mail.python.org/mailman/listinfo/python-list
> >
>
>
>
> ---------- Forwarded message ----------
> From: pizza python <pizzapython at gmx.com>
> To: python-list at python.org
> Cc:
> Bcc:
> Date: Sun, 17 Sep 2017 12:11:44 +0200
> Subject: speech_to_text python command not working
> Hello all.
>
>
> I'm on Linux Mint 18.2 Cinnamon 64-bit.
>
> I am trying to get IBM Watson BlueMix Speech-To-Text to transcribe my
> spoken-word audio files. Because I'm not a coder, I tried to find the
> simplest way to use BlueMix Speech-to-Text. And what I found
> is [1]https://github.com/rmotr/speech-to-text
>
> It's in PyPi Libary: https://pypi.python.org/pypi/speech-to-text/0.0.1
>
> Step 1: "pip install speech-to-text". I ran it with sudo to make it work.
>
>
>
>
> Step 2: I then ran: speech_to_text -u myUserNameGoesHere -p
> myPasswordGoesHere
> -f html -i voice2.ogg transcript.html Starting Upload.
> [===========================================================
> ==============]
> 100% Upload finished. Waiting for Transcript Traceback (most recent call
> last):
> File "/usr/local/bin/speech_to_text", line 11, in <module>
> sys.exit(speech_to_text()) File
> "/usr/local/lib/python2.7/dist-packages/click/core.py", line 722, in
> __call__
> return self.main(*args, **kwargs) File
> "/usr/local/lib/python2.7/dist-packages/click/core.py", line 697, in
> main rv =
> self.invoke(ctx) File "/usr/local/lib/python2.7/
> dist-packages/click/core.py",
> line 895, in invoke return ctx.invoke(self.callback, **ctx.params) File
> "/usr/local/lib/python2.7/dist-packages/click/core.py", line 535, in
> invoke
> return callback(*args, **kwargs) File
> "/usr/local/lib/python2.7/dist-packages/speech_to_text/command.py", line
> 60, in
> speech_to_text formatted_output = FormatterClass().format(result) File
> "/usr/local/lib/python2.7/dist-packages/speech_to_text/formatters.py",
> line 36,
> in format for obj in self._parse(data)) File
> "/usr/local/lib/python2.7/dist-packages/speech_to_text/formatters.py",
> line 10,
> in _parse for obj in data[`results']) KeyError: `results'
>
>
>
> __________
>
> I was expecting an html with the transcript. So why did I get the errors
> above?
>
>
>
>
>
>
>
> python
> Python 2.7.12 (default, Nov 19 2016, 06:48:10)
> [GCC 5.4.0 20160609] on linux2
>
> __________________________________
>
> dpkg -l python
> Desired=Unknown/Install/Remove/Purge/Hold
> |
> Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/
> trig-aWait/Trig-pend
> |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
> ||/ Name Version Architecture Description
> +++-==============-============-============-===============
> ==================
> ii python 2.7.11-1 amd64 interactive high-level
> object-ori
> ____________________________________
>
> python3
> Python 3.5.2 (default, Nov 17 2016, 17:05:23)
> [GCC 5.4.0 20160609] on linux
>
> ____________________________________
>
> dpkg -l python3
> Desired=Unknown/Install/Remove/Purge/Hold
> |
> Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/
> trig-aWait/Trig-pend
> |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
> ||/ Name Version Architecture Description
> +++-==============-============-============-===============
> ==================
> ii python3 3.5.1-3 amd64 interactive high-level
> object-ori
>
> References
>
> Visible links
> 1. https://github.com/rmotr/speech-to-text
>
>
>
> ---------- Forwarded message ----------
> From: Leam Hall <leamhall at gmail.com>
> To: "python-list at python.org" <python-list at python.org>
> Cc:
> Bcc:
> Date: Sun, 17 Sep 2017 06:22:34 -0400
> Subject: Re: Old Man Yells At Cloud
> Hmm... scratch the "young" and "Javascripters". Why lump them together
> since I bet it's just a vocal few? Better to have said "people who don't
> want to really learn the new language".
>
> On 09/17/2017 06:03 AM, Leam Hall wrote:
>
>> Different view, I guess. I'm glad all the young Javascripters have that
>> issue. As an old guy trying to re-learn more python it gives me an
>> advantage. I'm usually interested in the best thislanguage-native way to do
>> something. Doing so makes me learn the language faster and tends to
>> generate better code.
>>
>> That said, I'll often steal what I've learned before to understand the
>> new. Some helpful folks on IRC asked why I was using getopt instead of
>> argparse. Mostly because I come from a bash background. Looking at Python's
>> argparse would have stumped me if I hadn't already done the same thing with
>> Ruby's argparse.
>>
>> I'm still trying to figure out how to convert a string to unicode in
>> Python 2. I've done it in Ruby 1.8.7 so I assume Python 2 can do it and
>> that I'm just a bit slow.
>>
>> Leam
>>
>
>
>
> ---------- Forwarded message ----------
> From: Chris Angelico <rosuav at gmail.com>
> To: "python-list at python.org" <python-list at python.org>
> Cc:
> Bcc:
> Date: Sun, 17 Sep 2017 20:43:02 +1000
> Subject: Re: Old Man Yells At Cloud
> On Sun, Sep 17, 2017 at 5:54 PM, Steve D'Aprano
> <steve+python at pearwood.info> wrote:
> > To even *know* that there are branches of maths where int/int isn't
> defined, you
> > need to have learned aspects of mathematics that aren't even taught in
> most
> > undergrad maths degrees. (I have a degree in maths, and if we ever
> covered
> > areas where int/int was undefined, it was only briefly, and I've long
> since
> > forgotten it.)
>
> How about this:
>
> >>> (1<<10000)/2
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> OverflowError: integer division result too large for a float
>
> int/int is now undefined. In Py2, it perfectly correctly returns
> another integer (technically a long), but in Py3, it can't return a
> float, so it errors out. This is nothing to do with the mathematical
> notion of a "real", which is a superset of the mathematical notion of
> an "integer"; it's all to do with the Python notion of a "float",
> which is NOT a superset of the Python notion of an "integer".
>
> In Python 2, an ASCII string could be implicitly promoted to a Unicode
> string:
>
> >>> user_input = u"Real Soon Now™"
> >>> print("> " + user_input + " <")
> > Real Soon Now™ <
>
> In Python 2 and 3, a small integer can be implicitly promoted to float:
>
> >>> user_input = 3.14159
> >>> print(user_input + 1)
> 4.14159
>
> Both conversions can cause data-dependent failures when used with
> arbitrary input, but are unlikely to cause problems when you're
> promoting literals. Both conversions require proximity to the other
> type. As long as you're explicit about the data type used for user
> input, you can short-hand your literals and get away with it:
>
> >>> # more likely, input came as text
> >>> user_input = float("1.234")
> >>> print(user_input + 1)
> 2.234
> >>> # and hey, it works with other types too!
> >>> user_input = decimal.Decimal("1.234")
> >>> print(user_input + 1)
> 2.234
> >>> user_input = fractions.Fraction("1.234")
> >>> print(user_input + 1)
> 1117/500
>
> The trouble only comes when you take two pieces of user input in
> different types, and try to combine them:
>
> >>> user_1 = float("1.234")
> >>> user_2 = int("9"*999) # imagine someone typed it
> >>> user_1 + user_2
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> OverflowError: int too large to convert to float
>
> Solution? Always use the right data types for user input. Easy enough.
>
> Python 3 introduces a completely different way to get failure, though.
> You can be 100% consistent with your data types, but then get
> data-dependent failures if, and only if, you divide. (Technically, not
> completely new in Py3; you can get this in Py2 with exponentiation -
> "2**-1" will yield a float. Far less likely to be hit, but could
> potentially cause the same problems.) I don't know of any exploits
> that involve this, but I can imagine that you could attack a Python
> script by forcing it to go floating-point, then either crashing it
> with a huge integer, or exploiting round-off, depending on whether the
> program is assuming floats or assuming ints.
>
> Python 3 *removed* one of these data-dependent distinctions, by making
> bytes+text into an error:
>
> >>> b"asdf" + u"qwer"
> u'asdfqwer'
>
> >>> b"asdf" + u"qwer"
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> TypeError: can't concat str to bytes
>
> But it added a different one, by allowing a common and normal
> operation to change a data type. Is it better to make things
> convenient for the case of small integers (the ones that are perfectly
> representable as floats), while potentially able to have problems on
> larger ones? Considering how large a "small integer" can be, most
> programmers won't think to test for overflow - just as many
> programmers won't test non-ASCII data. Thanks to Python 3, the
> "non-ASCII data" one isn't a problem, because you'll get the same
> exception with ASCII data as with any other; but the "small integer"
> one now is.
>
> Data-dependent type errors don't seem like a smart thing to me.
>
> ChrisA
>
>
>
> ---------- Forwarded message ----------
> From: "Steve D'Aprano" <steve+python at pearwood.info>
> To: python-list at python.org
> Cc:
> Bcc:
> Date: Sun, 17 Sep 2017 20:54:51 +1000
> Subject: Python built-ins versus Javascript [was Re: Old Man Yells At
> Cloud]
> On Sun, 17 Sep 2017 08:02 pm, Abdur-Rahmaan Janhangeer wrote:
>
> > as someone who really dislike js, i have to admit : python's globals are
> > really really bad !
> >
> > js is a charm at that a real charm !
>
> Can you explain what you think is so bad about them, and why Javascript's
> are
> better?
>
>
>
> --
> Steve
> “Cheer up,” they said, “things could be worse.” So I cheered up, and sure
> enough, things got worse.
>
>
>
>
> ---------- Forwarded message ----------
> From: "Steve D'Aprano" <steve+python at pearwood.info>
> To: python-list at python.org
> Cc:
> Bcc:
> Date: Sun, 17 Sep 2017 21:25:21 +1000
> Subject: Re: Old Man Yells At Cloud
> On Sun, 17 Sep 2017 08:03 pm, Leam Hall wrote:
>
> > I'm still trying to figure out how to convert a string to unicode in
> > Python 2.
>
>
> A Python 2 string is a string of bytes, so you need to know what encoding
> they
> are in. Let's assume you got them from a source using UTF-8. Then you
> would do:
>
> mystring.decode('utf-8')
>
> and it will return a Unicode string of "code points" (think: more or less
> characters).
>
>
>
> --
> Steve
> “Cheer up,” they said, “things could be worse.” So I cheered up, and sure
> enough, things got worse.
>
>
>
>
> ---------- Forwarded message ----------
> From: Leam Hall <leamhall at gmail.com>
> To: "python-list at python.org" <python-list at python.org>
> Cc:
> Bcc:
> Date: Sun, 17 Sep 2017 07:38:35 -0400
> Subject: Unicode (was: Old Man Yells At Cloud)
> On 09/17/2017 07:25 AM, Steve D'Aprano wrote:
>
>> On Sun, 17 Sep 2017 08:03 pm, Leam Hall wrote:
>>
>> I'm still trying to figure out how to convert a string to unicode in
>>> Python 2.
>>>
>>
>>
>> A Python 2 string is a string of bytes, so you need to know what encoding
>> they
>> are in. Let's assume you got them from a source using UTF-8. Then you
>> would do:
>>
>> mystring.decode('utf-8')
>>
>> and it will return a Unicode string of "code points" (think: more or less
>> characters).
>>
>
>
> Still trying to keep this Py2 and Py3 compatible.
>
> The Py2 error is:
> UnicodeEncodeError: 'ascii' codec can't encode character u'\xf6'
> in position 8: ordinal not in range(128)
>
> even when the string is manually converted:
> name = unicode(self.name)
>
> Same sort of issue with:
> name = self.name.decode('utf-8')
>
>
> Py3 doesn't like either version.
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Paul Moore <p.f.moore at gmail.com>
> To: Leam Hall <leamhall at gmail.com>
> Cc: "python-list at python.org" <python-list at python.org>
> Bcc:
> Date: Sun, 17 Sep 2017 12:51:21 +0100
> Subject: Re: Unicode (was: Old Man Yells At Cloud)
> On 17 September 2017 at 12:38, Leam Hall <leamhall at gmail.com> wrote:
> > On 09/17/2017 07:25 AM, Steve D'Aprano wrote:
> >>
> >> On Sun, 17 Sep 2017 08:03 pm, Leam Hall wrote:
> >>
> >>> I'm still trying to figure out how to convert a string to unicode in
> >>> Python 2.
> >>
> >>
> >>
> >> A Python 2 string is a string of bytes, so you need to know what
> encoding
> >> they
> >> are in. Let's assume you got them from a source using UTF-8. Then you
> >> would do:
> >>
> >> mystring.decode('utf-8')
> >>
> >> and it will return a Unicode string of "code points" (think: more or
> less
> >> characters).
> >
> >
> >
> > Still trying to keep this Py2 and Py3 compatible.
> >
> > The Py2 error is:
> > UnicodeEncodeError: 'ascii' codec can't encode character u'\xf6'
> > in position 8: ordinal not in range(128)
> >
> > even when the string is manually converted:
> > name = unicode(self.name)
> >
> > Same sort of issue with:
> > name = self.name.decode('utf-8')
> >
> >
> > Py3 doesn't like either version.
>
> Your string is likely not UTF-8 with a character \xf6 in it. Maybe
> it's latin-1? The key here is there's no way for Python (or any
> program) to know the encoding of the byte string, so you have to tell
> it.
>
> Paul
>
>
>
> ---------- Forwarded message ----------
> From: Chris Angelico <rosuav at gmail.com>
> To: "python-list at python.org" <python-list at python.org>
> Cc:
> Bcc:
> Date: Sun, 17 Sep 2017 22:30:26 +1000
> Subject: Re: Unicode (was: Old Man Yells At Cloud)
> On Sun, Sep 17, 2017 at 9:38 PM, Leam Hall <leamhall at gmail.com> wrote:
> > Still trying to keep this Py2 and Py3 compatible.
> >
> > The Py2 error is:
> > UnicodeEncodeError: 'ascii' codec can't encode character u'\xf6'
> > in position 8: ordinal not in range(128)
> >
> > even when the string is manually converted:
> > name = unicode(self.name)
> >
> > Same sort of issue with:
> > name = self.name.decode('utf-8')
> >
> >
> > Py3 doesn't like either version.
>
> You got a Unicode *EN*code error when you tried to *DE* code. That's a
> quirk of Py2's coercion behaviours, so the error's a bit obscure, but
> it means that you (most likely) actually have a Unicode string
> already. Check what type(self.name) is, and see if the problem is
> actually somewhere else.
>
> (It's hard to give more specific advice based on this tiny snippet, sorry.)
>
> ChrisA
>
>
>
> ---------- Forwarded message ----------
> From: Leam Hall <leamhall at gmail.com>
> To: "python-list at python.org" <python-list at python.org>
> Cc:
> Bcc:
> Date: Sun, 17 Sep 2017 08:44:24 -0400
> Subject: Re: Unicode
> On 09/17/2017 08:30 AM, Chris Angelico wrote:
>
>> On Sun, Sep 17, 2017 at 9:38 PM, Leam Hall <leamhall at gmail.com> wrote:
>>
>>> Still trying to keep this Py2 and Py3 compatible.
>>>
>>> The Py2 error is:
>>> UnicodeEncodeError: 'ascii' codec can't encode character u'\xf6'
>>> in position 8: ordinal not in range(128)
>>>
>>> even when the string is manually converted:
>>> name = unicode(self.name)
>>>
>>> Same sort of issue with:
>>> name = self.name.decode('utf-8')
>>>
>>>
>>> Py3 doesn't like either version.
>>>
>>
>> You got a Unicode *EN*code error when you tried to *DE* code. That's a
>> quirk of Py2's coercion behaviours, so the error's a bit obscure, but
>> it means that you (most likely) actually have a Unicode string
>> already. Check what type(self.name) is, and see if the problem is
>> actually somewhere else.
>>
>> (It's hard to give more specific advice based on this tiny snippet,
>> sorry.)
>>
>> ChrisA
>>
>>
> Chris, thanks! I see what you mean.
>
> The string source is a SQLite3 database with a bunch of names. Some have
> non-ASCII characters. The database is using varchar which seems to be
> utf-8, utf-16be or utf-16le. I probably need to purge the data.
>
> What I find interesting is that utf-8 works in the Ruby script that pulls
> from the same database. That's what makes me think it's utf-8.
>
> I've tried different things in lines 45 and 61.
>
> https://gist.github.com/LeamHall/054f9915af17dc1b1a33597b9b45d2da
>
> Leam
>
>
>
> ---------- Forwarded message ----------
> From: "Steve D'Aprano" <steve+python at pearwood.info>
> To: python-list at python.org
> Cc:
> Bcc:
> Date: Sun, 17 Sep 2017 23:03:36 +1000
> Subject: Re: Old Man Yells At Cloud
> On Sun, 17 Sep 2017 08:43 pm, Chris Angelico wrote:
>
> > On Sun, Sep 17, 2017 at 5:54 PM, Steve D'Aprano
> > <steve+python at pearwood.info> wrote:
> >> To even *know* that there are branches of maths where int/int isn't
> defined,
> >> you need to have learned aspects of mathematics that aren't even taught
> in
> >> most undergrad maths degrees. (I have a degree in maths, and if we ever
> >> covered areas where int/int was undefined, it was only briefly, and
> I've long
> >> since forgotten it.)
> >
> > How about this:
> >
> >>>> (1<<10000)/2
> > Traceback (most recent call last):
> > File "<stdin>", line 1, in <module>
> > OverflowError: integer division result too large for a float
> >
> > int/int is now undefined.
>
> No, it's perfectly defined: you get an overflow error if the arguments are
> too
> big to convert, or an underflow error if the denominator is too small, or a
> divide by zero error if you divide by zero...
>
>
> What do you make of this?
>
> py> float(1<<10000)/2.0
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> OverflowError: int too large to convert to float
>
>
> Would you like to argue that this shows that coercing ints to floats
> is "undefined"?
>
>
> Overflow and underflow errors are limitations of the float data type. We
> could
> fix that in a couple of ways:
>
> - silently underflow to zero (as Python already does!) or infinity, as
> needed;
>
> - use a bigger ~~boat~~ float;
>
> - or even an arbitrary precision float;
>
> - or return a rational number (fraction or similar);
>
> - or introduce a float context that allows you to specify the behaviour
> that you want, as the decimal module does.
>
> There may be other solutions I haven't thought of. But these will do.
>
> The distinction between Python floats and real numbers ℝ is a red-herring.
> It
> isn't relevant.
>
>
> > In Py2, it perfectly correctly returns
> > another integer (technically a long), but in Py3, it can't return a
> > float, so it errors out.
>
> Apart from your "correctly", which I disagree with, that's a reasonable
> description. The problem is that your example returns the correct result by
> accident. Forget such ludicrously large values, and try something more
> common:
>
> 1/2
>
> Most people aren't expecting integer division, but true division, and
> silently
> returning the wrong result (0 instead of 0.5) is a silent source of bugs.
>
> This isn't some theoretical problem that might, maybe, perhaps, be an
> issue for
> some people sometimes. It was a regular source of actual bugs leading to
> code
> silently returning garbage.
>
>
> > This is nothing to do with the mathematical
> > notion of a "real",
>
> I don't believe I ever mentioned Reals. I was pretty careful not to.
>
>
> > which is a superset of the mathematical notion of
> > an "integer"; it's all to do with the Python notion of a "float",
> > which is NOT a superset of the Python notion of an "integer".
>
> So? Operations don't *have* to return values from their operands' type.
>
> len('abc') doesn't return a string.
>
> alist.find(1) doesn't have to return either a list or an int.
>
> And 1/2 doesn't have to return an int. Why is this such a big deal?
>
>
> > In Python 2, an ASCII string could be implicitly promoted to a Unicode
> string:
> >
> >>>> user_input = u"Real Soon Now™"
> >>>> print("> " + user_input + " <")
> >> Real Soon Now™ <
>
> And that was a bug magnet, like using / for integer division sometimes and
> true
> division other times was a big magnet. So Python 3 got rid of both bad
> design
> decisions.
>
>
> > In Python 2 and 3, a small integer can be implicitly promoted to float:
> >
> >>>> user_input = 3.14159
> >>>> print(user_input + 1)
> > 4.14159
>
> Yes, as it should. Why force the user to call float() on one argument when
> the
> interpreter can do it? What advantage is there?
>
> Can you demonstrate any failure of dividing two ints n/m which wouldn't
> equally
> fail if you called float(n)/float(m)? I don't believe that there is any
> such
> failure mode. Forcing the user to manually coerce to floats doesn't add any
> protection.
>
>
> > Both conversions can cause data-dependent failures when used with
> > arbitrary input,
>
> There's a difference:
>
> - with automatic promotion of bytes to Unicode, you get errors that
> pass silently and garbage results;
>
> - with automatic promotion of bytes to Unicode, you get errors that
> pass silently and garbage results;
>
> - but with true division, if int/int cannot be performed using
> floats, you get an explicit error.
>
>
> Silently returning the wrong result was a very common consequence of the
> int/int
> behaviour in Python 2. Is there any evidence of common, real-world bugs
> caused
> by true division?
>
> Beginners who make assumptions that Python is C (or any other language) and
> use / when they should use // don't count: that's no different from
> somebody
> using ^ for exponentiation.
>
>
> [...]
> > The trouble only comes when you take two pieces of user input in
> > different types, and try to combine them:
> >
> >>>> user_1 = float("1.234")
> >>>> user_2 = int("9"*999) # imagine someone typed it
> >>>> user_1 + user_2
> > Traceback (most recent call last):
> > File "<stdin>", line 1, in <module>
> > OverflowError: int too large to convert to float
>
> I'm sorry, I fail to see why you think this is "trouble". It's just normal
> Python behaviour in the face of errors: raise an exception. If you pass a
> bad
> value, you get an exception of some kind.
>
> Are these "trouble" too?
>
> py> ''[5]
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> IndexError: string index out of range
>
> py> int('xyz')
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> ValueError: invalid literal for int() with base 10: 'xyz'
>
>
> Getting an explicit exception on error is the right thing to do. Silently
> returning garbage is not.
>
> If you want to argue that int/int should return infinity, or a NAN, on
> overflow,
> that's possibly defensible. But arguing that somehow the division operator
> is
> uniquely or specifically "trouble" because it raises an exception when
> given
> bad data, well, that's just weird.
>
>
> > Python 3 introduces a completely different way to get failure, though.
> > You can be 100% consistent with your data types, but then get
> > data-dependent failures if, and only if, you divide.
>
> Its true that most operations on integers will succeed. But not all.
>
> Try (1<<10000)**(1<<10000) if you really think that integer ops are
> guaranteed
> to succeed. (I'm scared to try it myself, because I've had bad experiences
> in
> the past with unreasonably large ints.)
>
> But then, what of it? All that means is that division can fail. But even
> integer
> division can fail:
>
> py> 1//0
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> ZeroDivisionError: integer division or modulo by zero
>
>
> [...]
> > I don't know of any exploits
> > that involve this, but I can imagine that you could attack a Python
> > script by forcing it to go floating-point, then either crashing it
> > with a huge integer, or exploiting round-off, depending on whether the
> > program is assuming floats or assuming ints.
>
> You're not seriously arguing that true division is a security
> vulnerability?
>
> In any case, the error here is an exception, not silent failures.
>
> "I find it amusing when novice programmers believe their
> main job is preventing programs from crashing. ... More
> experienced programmers realize that correct code is
> great, code that crashes could use improvement, but
> incorrect code that doesn’t crash is a horrible nightmare."
> -- Chris Smith
>
>
> Using / for integer division, if and only if both arguments are integers,
> was
> exactly that horrible nightmare.
>
>
> --
> Steve
> “Cheer up,” they said, “things could be worse.” So I cheered up, and sure
> enough, things got worse.
>
>
>
>
> ---------- Forwarded message ----------
> From: Peter Otten <__peter__ at web.de>
> To: python-list at python.org
> Cc:
> Bcc:
> Date: Sun, 17 Sep 2017 15:13:09 +0200
> Subject: Re: Unicode
> Leam Hall wrote:
>
> > On 09/17/2017 08:30 AM, Chris Angelico wrote:
> >> On Sun, Sep 17, 2017 at 9:38 PM, Leam Hall <leamhall at gmail.com> wrote:
> >>> Still trying to keep this Py2 and Py3 compatible.
> >>>
> >>> The Py2 error is:
> >>> UnicodeEncodeError: 'ascii' codec can't encode character
> >>> u'\xf6' in position 8: ordinal not in range(128)
> >>>
> >>> even when the string is manually converted:
> >>> name = unicode(self.name)
> >>>
> >>> Same sort of issue with:
> >>> name = self.name.decode('utf-8')
> >>>
> >>>
> >>> Py3 doesn't like either version.
> >>
> >> You got a Unicode *EN*code error when you tried to *DE* code. That's a
> >> quirk of Py2's coercion behaviours, so the error's a bit obscure, but
> >> it means that you (most likely) actually have a Unicode string
> >> already. Check what type(self.name) is, and see if the problem is
> >> actually somewhere else.
> >>
> >> (It's hard to give more specific advice based on this tiny snippet,
> >> sorry.)
> >>
> >> ChrisA
> >>
> >
> > Chris, thanks! I see what you mean.
>
> I don't think so. You get a unicode from the database,
>
> $ python
> Python 2.7.6 (default, Oct 26 2016, 20:30:19)
> [GCC 4.8.4] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import sqlite3
> >>> db = sqlite3.connect(":memory:")
> >>> cs = db.cursor()
> >>> cs.execute("select 'foo';").fetchone()
> (u'foo',)
> >>>
>
> and when you try to decode it (which is superfluous as you already have
> unicode!) Python does what you ask for. But to be able to decode it has to
> encode first and by default it uses the ascii codec for that attempt. For
> an
> all-ascii string
>
> u"foo".encode("ascii") --> "foo"
>
> and thus
>
> u"foo".decode("utf-8)
>
> implemented as
>
> u"foo".encode("ascii").decode("utf-8") --> u"foo"
>
> is basically a noop. However
>
> u"äöü".encode("ascii") --> raises UnicodeENCODEError
>
> and thus
>
> u"äöü".decode("utf-8")
>
> fails with that. Unfortunately nobody realizes that the encoding failed and
> thus will unsuccessfully try and specify other encodings for the decoding
> step
>
> u"äöü".decode("latin1") # also fails
>
> Solution: if you already have unicode, leave it alone.
>
> > The string source is a SQLite3 database with a bunch of names. Some have
> > non-ASCII characters. The database is using varchar which seems to be
> > utf-8, utf-16be or utf-16le. I probably need to purge the data.
> >
> > What I find interesting is that utf-8 works in the Ruby script that
> > pulls from the same database. That's what makes me think it's utf-8.
> >
> > I've tried different things in lines 45 and 61.
> >
> > https://gist.github.com/LeamHall/054f9915af17dc1b1a33597b9b45d2da
> >
> > Leam
>
>
>
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
> ...
>
> [Message clipped]
--
*Joseph *
More information about the Python-list
mailing list