The page is fixed BTW >>>import this On Sun, Sep 17, 2017 at 6:13 AM, <python-list-requ...@python.org> wrote:
> Send Python-list mailing list submissions to > python-list@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-requ...@python.org > > You can reach the person managing the list at > python-list-ow...@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 (breamore...@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?" > (breamore...@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 <wlfr...@ix.netcom.com> > To: python-list@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 <i...@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 > wlfr...@ix.netcom.com HTTP://wlfraed.home.netcom.com/ > > > > > ---------- Forwarded message ---------- > From: Stefan Ram <r...@zedat.fu-berlin.de> > To: python-list@python.org > Cc: > Bcc: > Date: 16 Sep 2017 18:00:00 GMT > Subject: Re: Old Man Yells At Cloud > Steve D'Aprano <steve+pyt...@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 <r...@zedat.fu-berlin.de> > To: python-list@python.org > Cc: > Bcc: > Date: 16 Sep 2017 19:12:58 GMT > Subject: Re: Which database system? > Peter Otten <__pete...@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: breamore...@gmail.com > To: python-list@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 <benja...@python.org> > To: "python-announce-l...@python.org" <python-announce-l...@python.org>, " > python-list@python.org" <python-list@python.org>, python-...@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: breamore...@gmail.com > To: python-list@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+pyt...@pearwood.info> > To: python-list@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 <johnp...@jptechnical.co.uk> > To: python-list@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+pyt...@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+pyt...@pearwood.info> > To: python-list@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+pyt...@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 <pyt...@mrabarnett.plus.com> > To: python-list@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 <ros...@gmail.com> > To: "python-list@python.org" <python-list@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 <pyt...@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 <ros...@gmail.com> > To: "python-list@python.org" <python-list@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 <ros...@gmail.com> wrote: > > On Sun, Sep 17, 2017 at 11:28 AM, MRAB <pyt...@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 <wlfr...@ix.netcom.com> > To: python-list@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+pyt...@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 > wlfr...@ix.netcom.com HTTP://wlfraed.home.netcom.com/ > > > > > ---------- Forwarded message ---------- > From: "Steve D'Aprano" <steve+pyt...@pearwood.info> > To: python-list@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, breamore...@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 <r...@zedat.fu-berlin.de> > To: python-list@python.org > Cc: > Bcc: > Date: 17 Sep 2017 03:37:43 GMT > Subject: Re: Old Man Yells At Cloud > Steve D'Aprano <steve+pyt...@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@nospam.invalid> > To: python-list@python.org > Cc: > Bcc: > Date: Sat, 16 Sep 2017 21:07:57 -0700 > Subject: Re: Old Man Yells At Cloud > Steve D'Aprano <steve+pyt...@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.ke...@gmail.com> > To: Python <python-list@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+pyt...@pearwood.info> wrote: > > On Sun, 17 Sep 2017 09:04 am, breamore...@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 <r...@zedat.fu-berlin.de> > To: python-list@python.org > Cc: > Bcc: > Date: 17 Sep 2017 04:31:00 GMT > Subject: Re: Old Man Yells At Cloud > Paul Rubin <no.email@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.pyt...@gmail.com> > To: Wildman <best_...@yahoo.com> > Cc: python-list@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@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 <tjre...@udel.edu> > To: python-list@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, breamore...@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 <ros...@gmail.com> > To: "python-list@python.org" <python-list@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 <tjre...@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 <tjre...@udel.edu> > To: python-list@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 <tjre...@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.ew...@canterbury.ac.nz> > To: python-list@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.ew...@canterbury.ac.nz> > To: python-list@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 <n...@invalid.com> > To: python-list@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 <i...@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+pyt...@pearwood.info> > To: python-list@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+pyt...@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+pyt...@pearwood.info> > To: python-list@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 <tjre...@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.boube...@gmail.com> > To: Stefan Ram <r...@zedat.fu-berlin.de> > Cc: python-list <python-list@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" <r...@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 <al...@universite-de-strasbourg.fr.invalid> > To: python-list@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 <leamh...@gmail.com> > To: "python-list@python.org" <python-list@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.pyt...@gmail.com> > To: "Steve D'Aprano" <steve+pyt...@pearwood.info> > Cc: python-list@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+pyt...@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 <pizzapyt...@gmx.com> > To: python-list@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 <leamh...@gmail.com> > To: "python-list@python.org" <python-list@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 <ros...@gmail.com> > To: "python-list@python.org" <python-list@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+pyt...@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+pyt...@pearwood.info> > To: python-list@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+pyt...@pearwood.info> > To: python-list@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 <leamh...@gmail.com> > To: "python-list@python.org" <python-list@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.mo...@gmail.com> > To: Leam Hall <leamh...@gmail.com> > Cc: "python-list@python.org" <python-list@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 <leamh...@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 <ros...@gmail.com> > To: "python-list@python.org" <python-list@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 <leamh...@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 <leamh...@gmail.com> > To: "python-list@python.org" <python-list@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 <leamh...@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+pyt...@pearwood.info> > To: python-list@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+pyt...@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 <__pete...@web.de> > To: python-list@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 <leamh...@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 * -- https://mail.python.org/mailman/listinfo/python-list
