Re: python 3.44 float addition bug?

[Steven D'Aprano]

On Thu, 26 Jun 2014 13:39:23 +1000, Ben Finney wrote:

> Steven D'Aprano  writes:
> 
>> On Wed, 25 Jun 2014 14:12:31 -0700, Maciej Dziardziel wrote:
>>
>> > Floating points values use finite amount of memory, and cannot
>> > accurately represent infinite amount of numbers, they are only
>> > approximations. This is limitation of float type and applies to any
>> > languages that uses types supported directly by cpu. To deal with it
>> > you can either use decimal.Decimal type that operates using decimal
>> > system and saves you from such surprises
>>
>> That's a myth. decimal.Decimal *is* a floating point value
> 
> That's misleading: Decimal uses *a* floating-point representation, but
> not the one commonly referred to. That is, Decimal does not use IEEE-754
> floating point.

You're technically correct, but only by accident.

IEEE-754 covers both binary and decimal floating point numbers:

http://en.wikipedia.org/wiki/IEEE_floating_point


but Python's decimal module is based on IEEE-854, not 754.

http://en.wikipedia.org/wiki/IEEE_854-1987

So you're right on a technicality, but wrong in the sense of knowing what 
you're talking about *wink*


>> and is subject to *exactly* the same surprises as binary floats,
> 
> Since those “surprises” are the ones inherent to *decimal*, not binary,
> floating point, I'd say it's also misleading to refer to them as
> “exactly the same surprises”. They're barely surprises at all, to
> someone raised on decimal notation.

Not at all. They are surprises to people who are used to *mathematics*, 
fractions, rational numbers, the real numbers, etc. It is surprising that 
the rational number "one third" added together three times should fail to 
equal one. Ironically, binary float gets this one right:

py> 1/3 + 1/3 + 1/3 == 1
True
py> Decimal(1)/3 + Decimal(1)/3 + Decimal(1)/3 == 1
False


but for other rationals, that is not necessarily the case.

It is surprising when x*(y+z) fails to equal x*y + x*z, but that can 
occur with both binary floats and Decimals.

It is surprising when (x + y) + z fails to equal x + (y + z), but that 
can occur with both binary floats and Decimals.

It is surprising when x != 0 and y != 0 but x*y == 0, but that too can 
occur with both binary floats and Decimals. 

And likewise for most other properties of the rationals and reals, which 
people learn in school, or come to intuitively expect. People are 
surprised when floating-point arithmetic fails to obey the rules of 
mathematical arithmetic.

If anyone is aware of a category of surprise which binary floats are 
prone to, but Decimal floats are not, apart from the decimal-
representation issue I've already mentioned, I'd love to hear of it. But 
I doubt such a thing exists.

Decimal in the Python standard library has another advantage, it supports 
user-configurable precisions. But that doesn't avoid any category of 
surprise, it just mitigates against being surprised as often.


> This makes the Decimal functionality starkly different from the built-in
> ‘float’ type, and it *does* save you from the rather-more-surprising
> behaviour of the ‘float’ type. This is not mythical.

It simply is not true that Decimal avoids the floating point issues that 
"What Every Computer Scientist Needs To Know About Floating Point" warns 
about:

http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html

It *cannot* avoid them, because Decimal is itself a floating point 
format, it is not an infinite precision number type like 
fractions.Fraction.

Since Decimal cannot avoid these issues, all we can do is push the 
surprises around, and hope to have less of them, or shift them to parts 
of the calculation we don't care about. (Good luck with that.) Decimal, 
by default, uses 28 decimal digits of precision, about 11 or 12 more 
digits than Python floats are able to provide. So right away, by shifting 
to Decimal you gain precision and hence might expect fewer surprises, all 
else being equal.

But all else isn't equal. The larger the base, the larger the "wobble". 
See Goldberg above for the definition of wobble, but it's a bad thing. 
Binary floats have the smallest wobble, which is to their advantage.

If you stick to trivial calculations using nothing but trivially "neat" 
decimal numbers, like 0.1, you may never notice that Decimal is subject 
to the same problems as float (only worse, in some ways -- Decimal 
calculations can fail in some spectacularly horrid ways that binary 
floats cannot). But as soon as you start doing arbitrary calculations, 
particularly if they involve divisions and square roots, things are no 
longer as neat and tidy.

Here's an error that *cannot* occur with binary floats: the average of 
two numbers x and y is not guaranteed to lie between x and y!


py> from decimal import *
py> getcontext().prec = 3
py> x = Decimal('0.516')
py> y = Decimal('0.518')
py> (x + y) / 2
Decimal('0.515')


Ouch!



-- 
Steven
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to get Timezone from latitude/longitude ?

[codetarsier]

Thanks for the help people.
I was looking for the Malyasia City(lat/long)timezones.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: python 3.44 float addition bug?

[Chris Angelico]

On Thu, Jun 26, 2014 at 7:15 PM, Steven D'Aprano  wrote:
> Here's an error that *cannot* occur with binary floats: the average of
> two numbers x and y is not guaranteed to lie between x and y!
>
>
> py> from decimal import *
> py> getcontext().prec = 3
> py> x = Decimal('0.516')
> py> y = Decimal('0.518')
> py> (x + y) / 2
> Decimal('0.515')
>
>
> Ouch!

But what you're looking at is also a problem with intermediate
rounding, as the sum of .516 and .518 can't be represented in 3
digits. One rule of thumb that I learned back in my earliest coding
days was that your intermediate steps should have significantly more
precision than your end result; so if you want an end result with a
certain precision (say, 3 decimal digits), you should calculate with a
bit more. Of course, "a bit" is nearly impossible to define [1], but
if you're mostly adding and subtracting, or multiplying by smallish
constants, 1-2 extra digits' worth of precision is generally enough.
Or just give yourself lots of room, like using double-precision for
something like the above example. Compare this:

>>> from decimal import *
>>> getcontext().prec = 4
>>> x = Decimal('0.516')
>>> y = Decimal('0.519')
>>> avg = (x + y) / 2
>>> getcontext().prec = 3
>>> avg + 0
Decimal('0.518')
>>> (x + y) / 2
Decimal('0.52')

Doing the intermediate calculation with precision 3 exhibits the same
oddity Steven mentioned (only the other way around - result is too
high), but having a little extra room in the middle means the result
is as close to the correct answer as can be represented (0.517 would
be equally correct). With floating point on an 80x87, you can do this
with 80-bit FPU registers; I don't know of a way to do so with Python
floats, but (obviously) it's pretty easy with Decimal.

ChrisA

[1] Thank you, smart-aleck up the back, I am fully aware that "a bit"
is exactly one binary digit. That's not enough for a decimal float.
You've made your point, now shut up. :)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: protect psycopg script from sql injection?

[Peter Otten]

celati Laurent wrote:

> I coded this following python script via psycopg;
> 
> web_service_test.py
> 
> 
> 1/ When i execute it, the result is 'bad resquest'. Could you tell me why?

No, but you might find out yourself. When you remove the overly broad

try:
... # code that may fail
except:
print "Bad request"

and just keep the code in the try suite


... # code that may fail

Python will produce an informative traceback. In the (unlikely) case that 
with that extra information you still cannot find the problem in your code 
come back here and post the complete traceback.



-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Standard way to generate mail/news reply?

[Adam Funk]

On 2014-06-24, Skip Montanaro wrote:

> On Tue, Jun 24, 2014 at 6:46 AM, Adam Funk  wrote:
>> Is there some standard library or code for taking an e-mail or
>> newsgroup message & generating a reply to it?
>
> You might try searching for "mail reply" on pypi.python.org. That will
> return a number of hits. I know the python.org replybot is there and
> used frequently. It might be a good starting point.

It looks like I can use the email_reply_parser to do half the job, &
modify code from replybot to do the other half.  Thanks!


-- 
svn ci -m 'come back make, all is forgiven!' build.xml
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3.4.1 installer on Mac links Python to old Tcl/Tk

[Peter Tomcsanyi]

"Christian Gollwitzer"  wrote in message 
news:lofciv$nq6$1...@dont-email.me...
For PNG image support you can load either the Img package which gives 
support for a large variety of images, or the smaller tkpng package.


My first Google search for
"tkpng" "python"
gave no usable results. So I am not sure if and how can I use these Tk 
extensions from Python...
And finally I want to show the picture(s) on a Tk-based Canvas on top of 
each other with properly handled semi-transparency.


In our project we want to use as little as possible additonal packages 
because we expect that the end-users will use several platforms (Windows, 
Mac, Linux) and installing any extra Python-related package on non-Windows 
platform seems to be a nightmare, at least that is the result of the past 
three months of experience.
The need to go to the command line level for such a basic thing like 
installing or uninstalling something seems to me like going 20 to 30 years 
back in history. We cannot expect that our end-users (especially the 
Mac-based ones) will have that expertise even if they have enough expertise 
to program in Python when it is finally correctly installed on their 
computers.


For angled text it's right, I don't know, there used to be some hacks 
before, it's probably not possible in a clean way.


I was actually negatively surprised by the lack of this very basic feature 
(especially in a vector-graphics-based environment) when I started with 
Python+Tk a few months ago, so I was very glad to see it in 8.6 and I 
immediately started using it on Windows. But then I receved complaints from 
a Mac user that it just does not work...


Peter


--
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3.4.1 installer on Mac links Python to old Tcl/Tk

[Christian Gollwitzer]

Am 26.06.14 12:39, schrieb Peter Tomcsanyi:

"Christian Gollwitzer"  wrote in message
news:lofciv$nq6$1...@dont-email.me...

For PNG image support you can load either the Img package which gives
support for a large variety of images, or the smaller tkpng package.


My first Google search for
"tkpng" "python"
gave no usable results. So I am not sure if and how can I use these Tk
extensions from Python...


As I said, it doesn't have a special interface, you just load it and 
that's it. So if you do a tk.eval("package require tkpng"), your 
Tk.PhotoImage will magically recognize PNG. I don't know how widespread 
the installation is, but compilation is easy. An alternative is the 
widely available Img package, which adds support for many image formats 
like gif, bmp, jpeg, tga, tiff etc. On my Mac it came with the OS (I 
think); you'll do Tk.eval("package require Img"). Since there are no 
additional commands, it'll just work from Python as well. An alternative 
employed by Pythonistas is to load the image using PIL and create a Tk 
PhotoImage via the ImageTk bridge.



And finally I want to show the picture(s) on a Tk-based Canvas on top of
each other with properly handled semi-transparency.


This has been in the canvas for a long time, if you managed to create an 
image with an alpha channel.



In our project we want to use as little as possible additonal packages
because we expect that the end-users will use several platforms
(Windows, Mac, Linux) and installing any extra Python-related package on
non-Windows platform seems to be a nightmare, at least that is the
result of the past three months of experience.


I understand.


The need to go to the command line level for such a basic thing like
installing or uninstalling something seems to me like going 20 to 30
years back in history. We cannot expect that our end-users (especially
the Mac-based ones) will have that expertise even if they have enough
expertise to program in Python when it is finally correctly installed on
their computers.


On the Mac you can create an APP bundle which contains everything, 
including extra dependencies. It is a folder with a special structure, 
you put it into a DMG archive and it matches the expectation a Mac user 
has of an "installer". Unfortunately these things are very 
system-dependent, and it's a lot of work to provide deployment (do 
program icons, setup file associations etc.)





For angled text it's right, I don't know, there used to be some hacks
before, it's probably not possible in a clean way.


I was actually negatively surprised by the lack of this very basic
feature (especially in a vector-graphics-based environment)


Yes this was a long-deferred feature due to its inhomogeneous 
implementation on the supported platforms. There were some extensions 
like 10 years ago to do it, but only in 8.6 (2012) it made it into the 
core Tk.


Christian

--
https://mail.python.org/mailman/listinfo/python-list

OOP no Python

[Samuel David]

 

Olá,

Estou analisando algumas necessidades de nossa empresa e fiquei bastante
interessado em resolve-las utilizando Python, lendo o FAQ do site de vcs
percebo que está é uma linguagem bastante completa.

 

Mas estou com uma dúvida referente ao tópico “Por que eu deveria usar Python
e não ?”.

No comparativo entre Python e Delphi, vcs afirmam que em contrapartida ao
Delphi, o Python oferece uma linguagem Orientada a Objetos DE VERDADE
enquanto que o Delphi apenas implementam parte dos conceitos da OOP. 

Fiquei bastante curioso referente a quais conceitos da OOP o Python
implementa que não é suportado pelo Delphi?

A pergunta pode parecer um pouco capciosa, mas temos uma vertente forte de
Delphi na empresa e preciso de argumentos sólidos para expor a área de
desenvolvimento antes de decidirmos qual linguagem iremos adotar para este
novo projeto.

 

Obrigado,

Samuel Costa | Departamento de Desenvolvimento

Tel: + 55 51 3027-2910 Ramal: 3180 | samuel.co...@eos-hoepers.com

  http://www.eos-hoepers.com

EOS. With Head and Heart in Finance

EOS HOEPERS | Onze de Agosto, 56 · São João · CEP 91020-050 · Porto Alegre ·
RS

 

Salve a natureza. Não imprima esse e-mail se não for extremamente
necessário.

 

Esse e-mail pode conter informações confidenciais. Se você não for o
destinatário ou recebeu esse e-mail por engano, por favor, avise ao
remetente imediatamente e apague-o.

 

É rigorosamente proibida a divulgação ou distribuição do conteúdo do e-mail
sem autorização.

 

 

Save a tree. Don’t print this email unless it’s really necessary.

 

This email may contain confidential and/or privileged information. If you
are not the intended recipient or have this email in error, please notify
the sender immediately and destroy this email. 

 

Any unauthorized copying, disclosure or distribution of the material in this
email is strictly forbidden.

 

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: OOP no Python

[Stéphane Wirtel]

In English,

Sorry
On 26 Jun 2014, at 16:16, Samuel David wrote:


Olá,

Estou analisando algumas necessidades de nossa empresa e fiquei 
bastante
interessado em resolve-las utilizando Python, lendo o FAQ do site de 
vcs

percebo que está é uma linguagem bastante completa.



Mas estou com uma dúvida referente ao tópico “Por que eu deveria 
usar Python

e não ?”.

No comparativo entre Python e Delphi, vcs afirmam que em contrapartida 
ao

Delphi, o Python oferece uma linguagem Orientada a Objetos DE VERDADE
enquanto que o Delphi apenas implementam parte dos conceitos da OOP.

Fiquei bastante curioso referente a quais conceitos da OOP o Python
implementa que não é suportado pelo Delphi?

A pergunta pode parecer um pouco capciosa, mas temos uma vertente 
forte de
Delphi na empresa e preciso de argumentos sólidos para expor a área 
de
desenvolvimento antes de decidirmos qual linguagem iremos adotar para 
este

novo projeto.



Obrigado,

Samuel Costa | Departamento de Desenvolvimento

Tel: + 55 51 3027-2910 Ramal: 3180 | samuel.co...@eos-hoepers.com

 http://www.eos-hoepers.com

EOS. With Head and Heart in Finance

EOS HOEPERS | Onze de Agosto, 56 · São João · CEP 91020-050 · 
Porto Alegre ·

RS



Salve a natureza. Não imprima esse e-mail se não for extremamente
necessário.



Esse e-mail pode conter informações confidenciais. Se você não for 
o

destinatário ou recebeu esse e-mail por engano, por favor, avise ao
remetente imediatamente e apague-o.



É rigorosamente proibida a divulgação ou distribuição do 
conteúdo do e-mail

sem autorização.





Save a tree. Don’t print this email unless it’s really necessary.



This email may contain confidential and/or privileged information. If 
you
are not the intended recipient or have this email in error, please 
notify

the sender immediately and destroy this email.



Any unauthorized copying, disclosure or distribution of the material 
in this

email is strictly forbidden.



--
https://mail.python.org/mailman/listinfo/python-list



--
Stéphane Wirtel - http://wirtel.be - @matrixise
--
https://mail.python.org/mailman/listinfo/python-list

Re: OOP no Python

[Mark Lawrence]

On 26/06/2014 15:16, Samuel David wrote:

Olá,



python.pt
https://www.facebook.com/python.pt
IRC freenode #python-pt channel

I think :)

--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


--
https://mail.python.org/mailman/listinfo/python-list

Re: State of speeding up Python for full applications

[alister]

On Wed, 25 Jun 2014 20:54:29 -0700, CM wrote:

> I occasionally hear about performance improvements for Python by various
> projects like psyco (now old), ShedSkin, Cython, PyPy, Nuitka, Numba,
> and probably many others.  The benchmarks are out there, and they do
> make a difference, and sometimes a difference on par with C, from what
> I've heard.
> 
> What I have never quite been able to get is the degree to which one can
> currently use these approaches to speed up a Python application that
> uses 3rd party libraries...and that the approaches will "just work"
> without the developer having to know C or really do a lot of difficult
> under-the-hood sort of work.
> 
> For examples, and considering an application written for Python 2.7,
> say, and using a GUI toolkit, and a handful of 3rd party libraries:
> 
> - Can you realistically package up the PyPy interpreter and have the app
> run faster with PyPy?  And can the application be released as a single
> file executable if you use PyPy?
> 
> - Can you compile it with Nuitka to C?
> 
> I've had the (perhaps overly pessimistic) sense that you still *can't*
> do these things, because these projects only work on pure Python, or if
> they do work with other libraries, it's always described with major
> caveats that "I wouldn't try this in production" or "this is just a
> test" sort of thing, such as PyPy and wxPython.
> 
> I'd love to know what's possible, since getting some even modest
> performance gains would probably make apps feels snappier in some cases,
> and yet I am not up for the job of the traditional advice about
> "re-writing those parts in C".
> 
> Thanks.

1st find out where the true bottlenecks in your code only & only optimise 
those parts they absolutely need it
Rules for optimisation:-
1: Dont
2: (for advanced users only) Not Yet

2nd either move away from Google groups & use the mailing list/newsgroup 
or read posts regarding how to clean up the mess it makes, otherwise the 
only replies you are likely to see will be from the resident Unicode 
expert complaining about strings containing characters that can be 
represented by a single bite (ascii) performing faster than those that 
contain higher Unicode characters.



-- 
How do I type "for i in *.dvi do xdvi $i done" in a GUI?
-- Discussion in comp.os.linux.misc on the intuitiveness of 
interfaces
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: python-daemon for Python v3

[ryuanerin]

2014년 1월 19일 일요일 오후 7시 30분 27초 UTC+9, Asaf Las 님의 말:
> Hi Community 
> 
> 
> 
> Is there ported to Python v3 python-daemon package?
> 
> 
> 
> https://pypi.python.org/pypi/python-daemon/
> 
> 
> 
> i am afraid it is not as simple as correction of relative path input 
> 
> feature and except clauses in mentioned package.
> 
> 
> 
> Thanks 
> 
> 
> 
> Asaf

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: OOP no Python

[Chris Angelico]

2014-06-27 0:16 GMT+10:00 Samuel David :
> Mas estou com uma dúvida referente ao tópico “Por que eu deveria usar Python
> e não ?”.

Google Translate tells me you're asking "Why use Python instead of
?". (I'm going to respond only in English, as my
Portuguese is basically nil. Sorry.) Well, there are a lot of reasons
:)

One is that Python is a clear and simple language; a form of
"executable pseudo-code". If you start by writing what you want to do
as comments, then translate slightly into a more formal grammar to
make pseudo-code, you're pretty close to having stubby Python code.
There's a minimum of fuss, the language does its best to get out of
the way and let you do your work.

Closely related to that is Python's excellent interactive mode. Since
you don't have to declare variables or anything, you can simply fire
up Python interactively (eg by just typing "python", or with something
like IDLE), and it is simultaneously a clean environment in which you
just say "a = 2+3" and assign 5 to a, and a full programming
environment that gives you all the power you need (for instance, you
can define functions, then call them - that's something I was never
able to do in REXX, at least not without some fiddling). In contrast,
a language like Pike is that bit more wordy at its interactive prompt,
as you need to make appropriate declarations. And any language that
doesn't have first-class functions is going to be much less clean for
this sort of work - REXX doesn't have any concept of run-time function
creation at all, except that it can (ab)use the file system for that
job.

Another advantage of Python is Unicode support. Particularly if you're
using Python 3.3 or newer, you're guaranteed that a string consists of
a sequence of Unicode codepoints, and you can depend on being able to
index and slice it accordingly. This is way WAY better than C, or PHP,
or any other language that sticks its head in the sand and tries to
ignore character encodings altogether; and it's better than UTF-16
languages like JavaScript, because you avoid the subtle errors that
can creep in when you index a string with astral characters. You can
happily write your program and test it on Portuguese text, and be
confident that it'll work just as well with Hebrew.

Finally, Python is a well-established language. You can write an
application in Python and simply tell people "You'll need a Python
interpreter, version 3.3 or better, to run this", and be confident
that they'll be able to get one - most Linux distros include Python in
their repositories, a Mac probably has it installed, on Windows it's
just a matter of fetching the .msi, and there are unofficial builds
for obscure platforms like OS/2. (Which I make good use of,
incidentally. We have a legacy OS/2 system, now running as a virtual
machine under Linux, on which we run certain legacy software. How do
we back up the crucial data from there? Simple: A Python script that
archives the necessaries, sends them via TCP/IP, and reports its
status to the user. I think it took me all of half a screenful of code
to write that.)

There are other languages that I use and love, too; each one has its
strengths and weaknesses. These are just a few of Python's strengths.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Execute a python script with CGI ?

[dandrigo]

Dear all, 

I coded a python script (web service with query postgresql/postgis). Up to
now, i did several test on my local laptop station (windows). 

Now i want to execute this python script on our remote server (Web server :
Apache;OS :  Linux). 

How to write a CGI template please? 

Could you throw light for me? 

Thank you very much. 

Regards.



--
View this message in context: 
http://python.6.x6.nabble.com/Execute-a-python-script-with-CGI-tp5062183.html
Sent from the Python - python-list mailing list archive at Nabble.com.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Execute a python script with CGI ?

[gregor]

Hi,

Am Thu, 26 Jun 2014 08:24:56 -0700 (PDT)
schrieb dandrigo :

> I coded a python script (web service with query postgresql/postgis).
> Up to now, i did several test on my local laptop station (windows). 
> 
> Now i want to execute this python script on our remote server (Web
> server : Apache;OS :  Linux). 
> 
> How to write a CGI template please? 
> 
> Could you throw light for me? 

https://docs.python.org/2/library/cgi.html

--
Greg 

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: State of speeding up Python for full applications

[CM]

I'm reposting my question with, I hope, better 
formatting:  


I occasionally hear about performance improvements 
for Python by various projects like psyco (now old), 
ShedSkin, Cython, PyPy, Nuitka, Numba, and probably 
many others.  The benchmarks are out there, and they 
do make a difference, and sometimes a difference on 
par with C, from what I've heard.

What I have never quite been able to get is the 
degree  to which one can currently use these 
approaches to speed up a Python application that 
uses 3rd party libraries...and that the approaches 
will "just work" without the developer having to 
know C or really do a lot of difficult under-the-
hood sort of work.

For examples, and considering an application 
written for Python 2.7, say, and using a GUI 
toolkit, and a handful of 3rd party libraries:


- Can you realistically package up the PyPy 
interpreter and have the app run faster with PyPy?  
And can the application be released as a single file 
executable if you use PyPy?
 
- Can you compile it with Nuitka to C?

I've had the (perhaps overly pessimistic) sense 
that you still *can't* do these things, because 
these projects only work on pure Python, or if 
they do work with other libraries, it's always 
described with major caveats that "I wouldn't 
try this in production" or "this is just a test" 
sort of thing, such as PyPy and wxPython.

I'd love to know what's possible, since getting 
some even modest performance gains would probably 
make apps feels snappier in some cases, and yet I 
am not up for the job of the traditional advice 
about "re-writing those parts in C".

Thanks.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: State of speeding up Python for full applications

[Mark Lawrence]

On 26/06/2014 17:49, CM wrote:

I'm reposting my question with, I hope, better
formatting:


I occasionally hear about performance improvements
for Python by various projects like psyco (now old),
ShedSkin, Cython, PyPy, Nuitka, Numba, and probably
many others.  The benchmarks are out there, and they
do make a difference, and sometimes a difference on
par with C, from what I've heard.

What I have never quite been able to get is the
degree  to which one can currently use these
approaches to speed up a Python application that
uses 3rd party libraries...and that the approaches
will "just work" without the developer having to
know C or really do a lot of difficult under-the-
hood sort of work.

For examples, and considering an application
written for Python 2.7, say, and using a GUI
toolkit, and a handful of 3rd party libraries:


- Can you realistically package up the PyPy
interpreter and have the app run faster with PyPy?
And can the application be released as a single file
executable if you use PyPy?

- Can you compile it with Nuitka to C?

I've had the (perhaps overly pessimistic) sense
that you still *can't* do these things, because
these projects only work on pure Python, or if
they do work with other libraries, it's always
described with major caveats that "I wouldn't
try this in production" or "this is just a test"
sort of thing, such as PyPy and wxPython.

I'd love to know what's possible, since getting
some even modest performance gains would probably
make apps feels snappier in some cases, and yet I
am not up for the job of the traditional advice
about "re-writing those parts in C".

Thanks.



Have you tried everything listed here 
https://wiki.python.org/moin/PythonSpeed/PerformanceTips ?


--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


--
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3.4.1 installer on Mac links Python to old Tcl/Tk

[Christian Gollwitzer]

Am 26.06.14 14:37, schrieb Christian Gollwitzer:

Am 26.06.14 12:39, schrieb Peter Tomcsanyi:

"Christian Gollwitzer"  wrote in message
news:lofciv$nq6$1...@dont-email.me...

For PNG image support you can load either the Img package which gives
support for a large variety of images, or the smaller tkpng package.


My first Google search for
"tkpng" "python"
gave no usable results. So I am not sure if and how can I use these Tk
extensions from Python...


 On my Mac it came with the OS (I
think); you'll do Tk.eval("package require Img").


Just checked back with my vanilla VM install of Snow Leopard (10.6), 
that the Img package is installed. So doing this package require Img in 
case you detect 8.5 should solve your PNG problem on the Mac (you can do 
"package require Tk" to get the version number). I haven't checked alpha 
channel, though. For the rotated text there is no good solution. Of 
course, pushing people to install 8.6 is better:)


Christian

--
https://mail.python.org/mailman/listinfo/python-list

print statements and profiling a function slowed performance

[CM]

Huh. I learned two new Python facts this week:

1. print statements were slowing down my code enough to
really notice a particular transition. It went from about
2-3 seconds to a bit under 1 second. What at first seemed
unresponsive now seems almost snappy. The only difference
was removing a lot of print statements I had used for
debugging (Python 2.5, on a single core 1.97 Ghz machine).

2. Merely having a cPython decorator for profiling a 
function significantly slowed down performance...again,
from a about 2 seconds to just under a second (~1 second
doesn't seem much but these sorts of delays do affect 
user experience).  There is something ironic or 
Heisenbergian about that.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: OOP no Python

[Guilherme Rezende]

Samuel,

http://groups.google.com/group/python-brasil


On Thu, Jun 26, 2014 at 12:18 PM, Chris Angelico  wrote:

> 2014-06-27 0:16 GMT+10:00 Samuel David :
> > Mas estou com uma dúvida referente ao tópico “Por que eu deveria usar
> Python
> > e não ?”.
>
> Google Translate tells me you're asking "Why use Python instead of
> ?". (I'm going to respond only in English, as my
> Portuguese is basically nil. Sorry.) Well, there are a lot of reasons
> :)
>
> One is that Python is a clear and simple language; a form of
> "executable pseudo-code". If you start by writing what you want to do
> as comments, then translate slightly into a more formal grammar to
> make pseudo-code, you're pretty close to having stubby Python code.
> There's a minimum of fuss, the language does its best to get out of
> the way and let you do your work.
>
> Closely related to that is Python's excellent interactive mode. Since
> you don't have to declare variables or anything, you can simply fire
> up Python interactively (eg by just typing "python", or with something
> like IDLE), and it is simultaneously a clean environment in which you
> just say "a = 2+3" and assign 5 to a, and a full programming
> environment that gives you all the power you need (for instance, you
> can define functions, then call them - that's something I was never
> able to do in REXX, at least not without some fiddling). In contrast,
> a language like Pike is that bit more wordy at its interactive prompt,
> as you need to make appropriate declarations. And any language that
> doesn't have first-class functions is going to be much less clean for
> this sort of work - REXX doesn't have any concept of run-time function
> creation at all, except that it can (ab)use the file system for that
> job.
>
> Another advantage of Python is Unicode support. Particularly if you're
> using Python 3.3 or newer, you're guaranteed that a string consists of
> a sequence of Unicode codepoints, and you can depend on being able to
> index and slice it accordingly. This is way WAY better than C, or PHP,
> or any other language that sticks its head in the sand and tries to
> ignore character encodings altogether; and it's better than UTF-16
> languages like JavaScript, because you avoid the subtle errors that
> can creep in when you index a string with astral characters. You can
> happily write your program and test it on Portuguese text, and be
> confident that it'll work just as well with Hebrew.
>
> Finally, Python is a well-established language. You can write an
> application in Python and simply tell people "You'll need a Python
> interpreter, version 3.3 or better, to run this", and be confident
> that they'll be able to get one - most Linux distros include Python in
> their repositories, a Mac probably has it installed, on Windows it's
> just a matter of fetching the .msi, and there are unofficial builds
> for obscure platforms like OS/2. (Which I make good use of,
> incidentally. We have a legacy OS/2 system, now running as a virtual
> machine under Linux, on which we run certain legacy software. How do
> we back up the crucial data from there? Simple: A Python script that
> archives the necessaries, sends them via TCP/IP, and reports its
> status to the user. I think it took me all of half a screenful of code
> to write that.)
>
> There are other languages that I use and love, too; each one has its
> strengths and weaknesses. These are just a few of Python's strengths.
>
> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list
>



-- 
*Guilherme Bessa Rezende*
Software Engineer|DevOP
[ IT, Security, Telecom, ]
guilhermebr.com 
-- 
https://mail.python.org/mailman/listinfo/python-list

Newbie coding question

[Martin S]

Hi,

I've been following the tutorial here
http://anh.cs.luc.edu/python/hands-on/3.1/handsonHtml/
But when I get to section 1.10 there is

person = input('Enter your name: ')

However this generates an error


>>> person = input('Enter your name: ')
Enter your name: hi

Traceback (most recent call last):
  File "", line 1, in 
person = input('Enter your name: ')
  File "", line 1, in 
NameError: name 'hi' is not defined
>>>

I have no idea what I am doing wrong with this - it look correct to me.

I'm obviously doing something stupid, anyone can suggest what?

/M .
-- 
Regards,

Martin S
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Newbie coding question

[alister]

On Thu, 26 Jun 2014 20:53:35 +0200, Martin S wrote:

> Hi,
> 
> I've been following the tutorial here
> http://anh.cs.luc.edu/python/hands-on/3.1/handsonHtml/
> But when I get to section 1.10 there is
> 
> person = input('Enter your name: ')
> 
> However this generates an error
> 
> 
 person = input('Enter your name: ')
> Enter your name: hi
> 
> Traceback (most recent call last):
>   File "", line 1, in 
> person = input('Enter your name: ')
>   File "", line 1, in 
> NameError: name 'hi' is not defined


> I have no idea what I am doing wrong with this - it look correct to me.
> 
> I'm obviously doing something stupid, anyone can suggest what?
> 
> /M .

As a quick guess you are using python 2.X when the tutorial is written 
for python 3.X
Input is one of the incompatible changes between 2.x & 3.x
try raw_input instead (or install Python 3)



-- 
You can't get there from here.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: print statements and profiling a function slowed performance

[Michael Torrie]

On 06/26/2014 12:44 PM, CM wrote:
> Huh. I learned two new Python facts this week:
> 
> 1. print statements were slowing down my code enough to
> really notice a particular transition. It went from about
> 2-3 seconds to a bit under 1 second. What at first seemed
> unresponsive now seems almost snappy. The only difference
> was removing a lot of print statements I had used for
> debugging (Python 2.5, on a single core 1.97 Ghz machine).

Yes print statements are very useful, but you have to be careful with
them.  In Uni I remember working on a project where we coded up an
algorithm, and then attempted to work out by timing the O() runtime of
the algorithm.  Wanting to be fancy and print out a progress report, I
added an entire term to the O() runtime!  Instead of O(log n), it became
closer to O(n).  Oops!

Seems like over the years good old fashioned debugging skills have been
lost.  In the earliest days of IDEs (Turbo BASIC and QuickBASIC) I
regularly would employ debuggers with break points, watches, and step
through my code.  Nowadays it seems we loath to fire up the debugger.  I
imagine the currently available debugger frontends like ddd or kdbg
support pdb.  Not sure though.

> 2. Merely having a cPython decorator for profiling a 
> function significantly slowed down performance...again,
> from a about 2 seconds to just under a second (~1 second
> doesn't seem much but these sorts of delays do affect 
> user experience).  There is something ironic or 
> Heisenbergian about that.

Yes, it stands to reason that profiling code is going to introduce a
runtime cost.  How else would we expect profiling to work?  That's why a
production "release" is done with debugging and profiling stuff removed.
 What I do find Heisenbergian are bugs that show up when debugging and
profiling stuff are removed, but completely gone when present.  IE
profiling and debugging slow it down enough that often subtle race
conditions are masked.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: print statements and profiling a function slowed performance

[Mark Lawrence]

On 26/06/2014 19:44, CM wrote:

Huh. I learned two new Python facts this week:

1. print statements were slowing down my code enough to
really notice a particular transition. It went from about
2-3 seconds to a bit under 1 second. What at first seemed
unresponsive now seems almost snappy. The only difference
was removing a lot of print statements I had used for
debugging (Python 2.5, on a single core 1.97 Ghz machine).

2. Merely having a cPython decorator for profiling a
function significantly slowed down performance...again,
from a about 2 seconds to just under a second (~1 second
doesn't seem much but these sorts of delays do affect
user experience).  There is something ironic or
Heisenbergian about that.



3. use the logging module :)

--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


--
https://mail.python.org/mailman/listinfo/python-list

Re: Newbie coding question

[Martin S]

Ah, that was actually correct.
Thanks ...

/Martin S


2014-06-26 20:58 GMT+02:00 alister :

> On Thu, 26 Jun 2014 20:53:35 +0200, Martin S wrote:
>
> > Hi,
> >
> > I've been following the tutorial here
> > http://anh.cs.luc.edu/python/hands-on/3.1/handsonHtml/
> > But when I get to section 1.10 there is
> >
> > person = input('Enter your name: ')
> >
> > However this generates an error
> >
> >
>  person = input('Enter your name: ')
> > Enter your name: hi
> >
> > Traceback (most recent call last):
> >   File "", line 1, in 
> > person = input('Enter your name: ')
> >   File "", line 1, in 
> > NameError: name 'hi' is not defined
> 
> 
> > I have no idea what I am doing wrong with this - it look correct to me.
> >
> > I'm obviously doing something stupid, anyone can suggest what?
> >
> > /M .
>
> As a quick guess you are using python 2.X when the tutorial is written
> for python 3.X
> Input is one of the incompatible changes between 2.x & 3.x
> try raw_input instead (or install Python 3)
>
>
>
> --
> You can't get there from here.
> --
> https://mail.python.org/mailman/listinfo/python-list
>



-- 
Regards,

Martin S
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Newbie coding question

[Emile van Sebille]

On 6/26/2014 11:53 AM, Martin S wrote:

Hi,

I've been following the tutorial here
http://anh.cs.luc.edu/python/hands-on/3.1/handsonHtml/
But when I get to section 1.10 there is

person  =  input('Enter your name:')

However this generates an error


 >>> person = input('Enter your name: ')
Enter your name: hi

Traceback (most recent call last):
   File "", line 1, in 
 person = input('Enter your name: ')
   File "", line 1, in 
NameError: name 'hi' is not defined
 >>>

I have no idea what I am doing wrong with this - it look correct to me.

I'm obviously doing something stupid, anyone can suggest what?


I'd guess you're running Python2, and need to be running Python3.

Emile



--
https://mail.python.org/mailman/listinfo/python-list

Re: print statements and profiling a function slowed performance

[CM]

> Seems like over the years good old fashioned 
> debugging skills have been lost.  In the earliest 
> days of IDEs (Turbo BASIC and QuickBASIC) I 
> regularly would employ debuggers with break 
> points, watches, and step through my code.  

I do also use a debugger, but lazily use print 
statements, too.  When I use the debugger (in
my case, in the IDE I use, Boa Constructor), I
do use break points and step through my code, 
but I have never used watches.  How do you use
them?

> Yes, it stands to reason that profiling code 
> is going to introduce a runtime cost.  How else 
> would we expect profiling to work?  

I think I was hoping for magic. :D
 
>  What I do find Heisenbergian are bugs that show 
> up when debugging and profiling stuff are removed, 
> but completely gone when present.  IE profiling and 
> debugging slow it down enough that often subtle race
> conditions are masked.

Would never have occurred to me.  That *is* odd!

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: print statements and profiling a function slowed performance

[CM]

On Thursday, June 26, 2014 3:27:48 PM UTC-4, 
Mark Lawrence wrote:
 
> 3. use the logging module :)

I've just never got around to it, but I guess
I should.  Thanks for the nudge.

-- 
https://mail.python.org/mailman/listinfo/python-list

2.7.7 Built-in OpenSSL Library?

[David Andrzejewski]

Taking a look at:

http://bugs.python.org/issue21462

It looks like the OpenSSL library in Python 2.7.7 on Windows should be 1.0.1.

However, when I install Python 2.7.7 on my system,


C:\Python27>python
Python 2.7.7 (default, Jun  1 2014, 14:17:13) [MSC v.1500 32 bit (Intel)] on 
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import ssl
>>> ssl.OPENSSL_VERSION
'OpenSSL 0.9.8y 5 Feb 2013'
>>>


Which is the previous version.

Did I miss something, or did this not make it into 2.7.7?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: 2.7.7 Built-in OpenSSL Library?

[Zachary Ware]

On Thu, Jun 26, 2014 at 3:41 PM, David Andrzejewski
 wrote:
> Taking a look at:
>
> http://bugs.python.org/issue21462
>
> It looks like the OpenSSL library in Python 2.7.7 on Windows should be 1.0.1.
>
> However, when I install Python 2.7.7 on my system,
>
>
> C:\Python27>python
> Python 2.7.7 (default, Jun  1 2014, 14:17:13) [MSC v.1500 32 bit (Intel)] on 
> win32
> Type "help", "copyright", "credits" or "license" for more information.
 import ssl
 ssl.OPENSSL_VERSION
> 'OpenSSL 0.9.8y 5 Feb 2013'

>
>
> Which is the previous version.
>
> Did I miss something, or did this not make it into 2.7.7?

No, it did make it into 2.7.7:

   P:\tmp>py -2
   Python 2.7.7 (default, Jun  1 2014, 14:17:13) [MSC v.1500 32 bit
(Intel)] on win32
   Type "help", "copyright", "credits" or "license" for more information.
   >>> import ssl
   >>> ssl.OPENSSL_VERSION
   'OpenSSL 1.0.1g 7 Apr 2014'
   >>>

I'm not sure why it's different for you.  Could you check what values
you get for ssl.__file__, _ssl.__file__, and sys.path?  I was
concerned that perhaps you installed 2.7.7 over an existing 2.7.<=6
and _ssl.pyd just didn't get overwritten due to an installer bug, but
I just ruled that out by installing 2.7.7 over 2.7.6.

-- 
Zach
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: 2.7.7 Built-in OpenSSL Library?

[David Andrzejewski]

On Thursday, June 26, 2014 5:09:10 PM UTC-4, Zachary Ware wrote:
> On Thu, Jun 26, 2014 at 3:41 PM, David Andrzejewski
> 
>  wrote:
> 
> > Taking a look at:
> 
> >
> 
> > http://bugs.python.org/issue21462
> 
> >
> 
> > It looks like the OpenSSL library in Python 2.7.7 on Windows should be 
> > 1.0.1.
> 
> >
> 
> > However, when I install Python 2.7.7 on my system,
> 
> >
> 
> >
> 
> > C:\Python27>python
> 
> > Python 2.7.7 (default, Jun  1 2014, 14:17:13) [MSC v.1500 32 bit (Intel)] 
> > on win32
> 
> > Type "help", "copyright", "credits" or "license" for more information.
> 
>  import ssl
> 
>  ssl.OPENSSL_VERSION
> 
> > 'OpenSSL 0.9.8y 5 Feb 2013'
> 
> 
> 
> >
> 
> >
> 
> > Which is the previous version.
> 
> >
> 
> > Did I miss something, or did this not make it into 2.7.7?
> 
> 
> 
> No, it did make it into 2.7.7:
> 
> 
> 
>P:\tmp>py -2
> 
>Python 2.7.7 (default, Jun  1 2014, 14:17:13) [MSC v.1500 32 bit
> 
> (Intel)] on win32
> 
>Type "help", "copyright", "credits" or "license" for more information.
> 
>>>> import ssl
> 
>>>> ssl.OPENSSL_VERSION
> 
>'OpenSSL 1.0.1g 7 Apr 2014'
> 
>>>>
> 
> 
> 
> I'm not sure why it's different for you.  Could you check what values
> 
> you get for ssl.__file__, _ssl.__file__, and sys.path?  I was
> 
> concerned that perhaps you installed 2.7.7 over an existing 2.7.<=6
> 
> and _ssl.pyd just didn't get overwritten due to an installer bug, but
> 
> I just ruled that out by installing 2.7.7 over 2.7.6.
> 
> 
> 
> -- 
> 
> Zach

Ah! My PYTHONPATH environment variable was pointing to... somewhere else.  I 
unset it, and now I'm seeing what I expect!

Thanks very much!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3.4.1 installer on Mac links Python to old Tcl/Tk

[Ned Deily]

In article ,
 Christian Gollwitzer  wrote:

> Am 26.06.14 14:37, schrieb Christian Gollwitzer:
> > Am 26.06.14 12:39, schrieb Peter Tomcsanyi:
> >> "Christian Gollwitzer"  wrote in message
> >> news:lofciv$nq6$1...@dont-email.me...
> >>> For PNG image support you can load either the Img package which gives
> >>> support for a large variety of images, or the smaller tkpng package.
> >>
> >> My first Google search for
> >> "tkpng" "python"
> >> gave no usable results. So I am not sure if and how can I use these Tk
> >> extensions from Python...
> >
> >  On my Mac it came with the OS (I
> > think); you'll do Tk.eval("package require Img").
> Just checked back with my vanilla VM install of Snow Leopard (10.6), 
> that the Img package is installed. So doing this package require Img in 
> case you detect 8.5 should solve your PNG problem on the Mac (you can do 
> "package require Tk" to get the version number). I haven't checked alpha 
> channel, though. For the rotated text there is no good solution. Of 
> course, pushing people to install 8.6 is better:)

Just a reminder that you should *not* depend on the Apple-supplied Tk 
8.5 in OS X 10.6.  That was the first release of Cocoa Tk and it has 
proven to be almost unusable, at least with IDLE and some other 
Tkinter-based apps.  Install a newer Tcl/Tk 8.5.x, like from ActiveTcl, 
and use a python that links with it, like from the python.org 
installers. The ActiveTcl installer also installs "teacup" which allows 
you to easily install additional Tcl packages.

-- 
 Ned Deily,
 n...@acm.org

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Execute a python script with CGI ?

[Ian Kelly]

On Thu, Jun 26, 2014 at 9:24 AM, dandrigo  wrote:
> Dear all,
>
> I coded a python script (web service with query postgresql/postgis). Up to
> now, i did several test on my local laptop station (windows).
>
> Now i want to execute this python script on our remote server (Web server :
> Apache;OS :  Linux).
>
> How to write a CGI template please?
>
> Could you throw light for me?
>
> Thank you very much.
>
> Regards.

While you can run Python as a CGI, the recommended pattern is to use
WSGI.  I suggest starting here:

https://docs.python.org/2/howto/webservers.html
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: print statements and profiling a function slowed performance

[Michael Torrie]

On 06/26/2014 02:36 PM, CM wrote:
>>  What I do find Heisenbergian are bugs that show 
>> up when debugging and profiling stuff are removed, 
>> but completely gone when present.  IE profiling and 
>> debugging slow it down enough that often subtle race
>> conditions are masked.
> 
> Would never have occurred to me.  That *is* odd!

If you never work with threads then you probably won't encounter this issue.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: print statements and profiling a function slowed performance

[Chris Angelico]

On Fri, Jun 27, 2014 at 6:36 AM, CM  wrote:
>> Yes, it stands to reason that profiling code
>> is going to introduce a runtime cost.  How else
>> would we expect profiling to work?
>
> I think I was hoping for magic. :D

Thank you for being honest :) The fact is, though, that time-of-day
and console output take a lot more time than many people seem to
realize; this is especially true if you print something repeatedly on
the same line, such as:

num = len(x)
for i,foo in enumerate(x):
print(i/num,end="\r")
# perform processing

If x is, say, range(100), a simple "for foo in x: pass" will
complete fairly quickly (maybe 100ms on my computer), while the
progress-indicated loop will take much longer (about 30 seconds when I
tried it). Obviously you'll be doing more work than just "pass", but
it's easy to completely dwarf the actual processing with the display
to the user. (And yes, this can happen in production code, too. We had
an old Windows 3 program that, for some reason, completed its
processing in less time if someone moved the mouse around than if it
sat idle. Its stupid animation - not even a progress indication, just
"hi, I'm still working here" - interacted badly with idle
sensitivity.)

>>  What I do find Heisenbergian are bugs that show
>> up when debugging and profiling stuff are removed,
>> but completely gone when present.  IE profiling and
>> debugging slow it down enough that often subtle race
>> conditions are masked.
>
> Would never have occurred to me.  That *is* odd!

Race conditions are by their nature subtle. I've seen all sorts of
crazy things change their behaviour... refactoring a function can
appear to introduce or eliminate a bug (because the call/return
sequence adds a small delay), and occasionally, even a completely
benign change can influence something - renaming a file on the disk
can cause a cache miss and make the program work perfectly (or fail to
work) the one next time it's run. Yeah, that can be fun.

(Though not as much fun as debugging a refcount error, where a program
will crash if certain things are done *and then certain others*. The
actually-faulty code just plants a land mine [1], and until you tread
on it, nothing goes wrong. Depending on how many other references
there are to that object, the freeing could happen at any time; and
even after it's freed, there might be no apparent problem, until the
memory gets reused somewhere. Now THAT is fun to debug. Pretty much
*any* change to the code can affect whether or not it crashes.)

ChrisA

[1] Like this guy.
http://media.wizards.com/images/magic/tcg/products/m15/sf0JdVsk2/EN_42um78zriv.png
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Newbie coding question

[Chris Angelico]

On Fri, Jun 27, 2014 at 4:53 AM, Martin S  wrote:
> I've been following the tutorial here
> http://anh.cs.luc.edu/python/hands-on/3.1/handsonHtml/

Be aware that this tutorial is aimed at Python 3.1, which is a quite
old version in the 3.x branch. I recommend you get the latest Python
(currently 3.4), and if the tutorial you're using doesn't work, try
this one:

https://docs.python.org/3/tutorial/index.html

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: python 3.44 float addition bug?

[Steven D'Aprano]

On Thu, 26 Jun 2014 19:38:45 +1000, Chris Angelico wrote:

> On Thu, Jun 26, 2014 at 7:15 PM, Steven D'Aprano 
> wrote:
>> Here's an error that *cannot* occur with binary floats: the average of
>> two numbers x and y is not guaranteed to lie between x and y!
>>
>>
>> py> from decimal import *
>> py> getcontext().prec = 3
>> py> x = Decimal('0.516')
>> py> y = Decimal('0.518')
>> py> (x + y) / 2
>> Decimal('0.515')
>>
>>
>> Ouch!
> 
> But what you're looking at is also a problem with intermediate rounding,
> as the sum of .516 and .518 can't be represented in 3 digits. 

Exactly. I picked 3 digits because it's much easier to write, and read, a 
3 digit example than a 28 digit example. But the failure here is not a 
property of "too few digits", to be fixed by adding more significant 
digits. No matter how many digits you have, there are some calculations 
which cannot be performed exactly in that many digits.

Although you seem to have missed the critical issue: this is a failure 
mode which *binary floats cannot exhibit*, but decimal floats can. The 
failure being that 

assert x <= (x+y)/2 <= y

may fail if x and y are base 10 floats.

I'm afraid my computational-mathematics skills are not good enough to 
prove this assertion, but Mark Dickinson on the Python-Dev mailing list 
made this claim, and I believe he knows what he is talking about.

https://mail.python.org/pipermail/python-ideas/2014-March/026851.html


If anyone can demonstrate such a failed assertion using floats, I'd love 
to see it.


-- 
Steven
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: print statements and profiling a function slowed performance

[Steven D'Aprano]

On Thu, 26 Jun 2014 13:37:41 -0700, CM wrote:

> On Thursday, June 26, 2014 3:27:48 PM UTC-4, Mark Lawrence wrote:
>  
>> 3. use the logging module :)
> 
> I've just never got around to it, but I guess I should.  Thanks for the
> nudge.

While using the logging module is recommended for logging, if you expect 
that logging will be faster than print, I expect you will be disappointed.



-- 
Steven
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: print statements and profiling a function slowed performance

[Chris Angelico]

On Fri, Jun 27, 2014 at 12:55 PM, Steven D'Aprano
 wrote:
> On Thu, 26 Jun 2014 13:37:41 -0700, CM wrote:
>
>> On Thursday, June 26, 2014 3:27:48 PM UTC-4, Mark Lawrence wrote:
>>
>>> 3. use the logging module :)
>>
>> I've just never got around to it, but I guess I should.  Thanks for the
>> nudge.
>
> While using the logging module is recommended for logging, if you expect
> that logging will be faster than print, I expect you will be disappointed.

I would expect it to be faster than print in the case where it ends up
not printing, which means you can make one change to logging level and
very quickly eliminate all the output. I haven't measured, but I would
expect the overhead of the logging module itself to be small compared
to the cost of actual console output.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: python 3.44 float addition bug?

[Chris Angelico]

On Fri, Jun 27, 2014 at 12:51 PM, Steven D'Aprano
 wrote:
> Although you seem to have missed the critical issue: this is a failure
> mode which *binary floats cannot exhibit*, but decimal floats can. The
> failure being that
>
> assert x <= (x+y)/2 <= y
>
> may fail if x and y are base 10 floats.

No, I didn't miss that; I said that what you were looking at was
*also* caused by intermediate rounding. It happens because .516 + .518
= 1.034, which rounds to 1.03; half of that is .515, which is outside
of your original range - but the intermediate rounding really reduced
the "effective precision" to two digits, by discarding some of the
information in the original. If you accept that your result is now
accurate to only two digits of precision, then that result is within
one ULP of correct (you'll record the average as either .51 or .52,
and your two original inputs are both .52, and the average of .52 and
.52 is clearly .52).

But you're right that this can be very surprising. And it's inherent
to the concept of digits having more range than just "high" or "low",
so there's no way you can get this with binary floats.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list