Re: Why Python 3?

[Chris Angelico]

On Sat, Apr 19, 2014 at 4:40 PM, Paul Rubin  wrote:
> If you're starting a new project and you get to choose between 2 and 3,
> other things equal I'd say use 3.  I've kept using 2 basically because
> it's the path of least resistance.  I'm somewhat following the 3
> situation and of course I'd use 3 if I were doing something that
> benefited from it, but so far it hasn't been an issue.
>
> Eventually the main Linux distros will include 3 instead of 2 by
> default, and we'll probably see more migration then.  Right now I type
> "python" and get 2, so I use it.

Several of the main distros are already including Python 3 by default
(eg Ubuntu), but when you type "python", you still get Python 2, for
reasons of compatibility. (See PEP 394.) As long as you set your
shebang to say python3, it'll work just fine.

I strongly recommend going for Python 3 unless something actually
stops you from doing so. If you absolutely must use Python 2, try to
aim for a minimum of 2.6 or 2.7, and start your program with this
line:

from __future__ import print_function, unicode_literals, division

That'll make Python 2.6/2.7 behave like Python 3.x in three ways:
firstly, "print" will be a function instead of a statement (and it's
more powerful than the statement form, as well as being more
flexible); secondly, quoted strings will be Unicode strings, not byte
strings (that'll help you to start thinking about what's bytes and
what's text, which is an important distinction in Python 3); and
thirdly, though less important than the others, the division of two
integers will result in a floating point, not an integer. I personally
think the last one was a mistake on Python 3's part (why bless float
specifically? what if you're working with integers and
decimal.Decimals?), but if you're going to move to Python 3, you may
as well have your code start working that way, so you get used to
typing // to divide integers and get an integer (floor division).

But if you possibly can, aim for Python 3. Every new version adds
features, and new versions within the 3.x line break very little
(generally only what would have been working with a bug anyway, like
narrow Unicode builds of 3.2 becoming universal on 3.3). If you aim
for 3.2 today, and tomorrow try to run your code on 3.4, chances are
it'll work. The main thing is, know what's a text string and what's a
string of bytes; that's critical in 3.x, but not in 2.x. Force
yourself to think about that, and your code will be more reliable -
regardless of even what language you write it in.

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

Re: Why Python 3?

[Ian Kelly]

On Sat, Apr 19, 2014 at 1:34 AM, Chris Angelico  wrote:
> That'll make Python 2.6/2.7 behave like Python 3.x in three ways:
> firstly, "print" will be a function instead of a statement (and it's
> more powerful than the statement form, as well as being more
> flexible); secondly, quoted strings will be Unicode strings, not byte
> strings (that'll help you to start thinking about what's bytes and
> what's text, which is an important distinction in Python 3); and
> thirdly, though less important than the others, the division of two
> integers will result in a floating point, not an integer. I personally
> think the last one was a mistake on Python 3's part (why bless float
> specifically? what if you're working with integers and
> decimal.Decimals?), but if you're going to move to Python 3, you may
> as well have your code start working that way, so you get used to
> typing // to divide integers and get an integer (floor division).

If you're working with decimals, then the result is a decimal.  If one
side is an integer and the other is a decimal, then the result is
still a decimal.  Similarly if one of the operands is a fraction, then
the result is a fraction.  The change from / denoting "classic
division" to "true division" really only affects the case where both
operands are integers, so far as I'm aware.  If you want to divide two
integers and get a decimal result, then convert one or both of them to
decimals first; you would have needed to do the same with classic
division.

We also gained a consistent and explicit way to differentiate between
the two different styles of division that classic division
represented, as opposed to picking at run-time based on type.

As for "why float" specifically, the division __future__ import has
been around since 2.2, longer than either decimals or fractions.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why Python 3?

[Chris Angelico]

On Sat, Apr 19, 2014 at 7:25 PM, Ian Kelly  wrote:
> The change from / denoting "classic
> division" to "true division" really only affects the case where both
> operands are integers, so far as I'm aware.  If you want to divide two
> integers and get a decimal result, then convert one or both of them to
> decimals first; you would have needed to do the same with classic
> division.

If float were a perfect superset of int, and the only logical superset
when you want non-integers, then it'd be fine. But if you're mixing
int and Decimal, you have to explicitly convert, whereas if you're
mixing int and float, you don't. Why is it required to be explicit
with Decimal but not float? Of all the possible alternate types, why
float? Only because...

> As for "why float" specifically, the division __future__ import has
> been around since 2.2, longer than either decimals or fractions.

... it already existed. There's no particular reason to up-cast to
float, specifically, and it can cause problems with large integers -
either by losing accuracy, or by outright overflowing.

Suppose you take an integer, multiply it by 10, and divide it by 5. In
theory, that's the same as multiplying by 2, right? Mathematically it
is. In C it might not be, because the multiplication might overflow;
but Python, like a number of other modern languages, has an integer
type that won't overflow. In Python 2, doing the obvious thing works:

x * 10 / 5 == x * 2

In Python 3, you have to say "Oh but I want my integer division to
result in an integer":

x * 10 // 5 == x * 2

Yes, I can see that it's nice for simple interactive use. You type
"1/2" and you get back 0.5. But doesn't it just exchange one set of
problems ("dividing integers by integers rounds") for another set
("floating point arithmetic isn't real number arithmetic")?

Anyway. While I think it was a mistake to bless float in that way, I'm
aware that it isn't going to change. Which is why, for anyone who's
looking at starting a project fresh, I recommend "from __future__
import division", as it'll make the port to Py3 that much easier.

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

Re: Why Python 3?

[Marko Rauhamaa]

Ian Kelly :

> On Sat, Apr 19, 2014 at 1:34 AM, Chris Angelico  wrote:
>> if you're going to move to Python 3, you may as well have your code
>> start working that way, so you get used to typing // to divide
>> integers and get an integer (floor division).
>
> [...]
>
> We also gained a consistent and explicit way to differentiate between
> the two different styles of division that classic division
> represented, as opposed to picking at run-time based on type.

Very often when integer division is needed, so is the remainder. Then,
it is good to remember the builtin divmod() function:

   https://docs.python.org/3.4/library/functions.html#divmod

In fact, divmod() goes a long way toward removing the need for // and %
in Python code.


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

Re: Why Python 3?

[Ben Finney]

Anthony Papillion  writes:

> So I've been working with Python for a while and I'm starting to take
> on more and more serious projects with it. I've been reading a lot
> about Python 2 vs Python 3 and the community kind of seems split on
> which should be used.

The community is in transition; the direction is clear, but different
people have different situations.

> Some say 'Python 3 is the future, use it for everything now' and other
> say 'Python 3 is the future but you can't do everything in it now so
> use Python 2'.

Well, it's clear: Python 3 is uncontroversially the future :-) Also:
Python 3 is the only path which is currently being maintained as a
target for new code.

Python 2 is in bug-fix mode only, has been for years, will not be
supported indefinitely, and will never get new features.

Python 3 support is already excellent now, is getting better all the
time, and Python 2 is losing ground and will continue to do so.

> What is the general feel of /this/ community?

I'd advise: that's less important than the specific needs of what *you*
will be doing. If you can drop Python 2 for your specific project, do
so; if you can't yet, set yourself up such that you can drop Python 2 as
soon as feasible, and agitate for the blockers to be removed ASAP.

> I'm about to start a large scale Python project. Should it be done in
> 2 or 3? What are the benefits, aside from the 'it's the future'
> argument?

* Python 3 (unlike Python 2) gets Unicode right. This makes it almost
  unique among today's programming languages, and has become essential
  for 21st century programming.

  Any programs you begin today – in any programming language – can
  expect to be used with international text, and increasingly so as time
  goes on. Unicode is the only game in town for freely mixing all
  writing systems of the world. You need Unicode to be correct to the
  core of the language.

* Python 3 (unlike Python 2) comes with support for virtual Python
  environments, namespace packages, third-party package installation,
  and other improvements that make it much simpler to deploy complex
  projects (which you'll likely need sooner than you think with any new
  project).

* Python 3 (unlike Python 2) has more secure and efficient parallel and
  concurrent processing: multiprocessing, asynchronous processing,
  generator delegation, and “futures” all make it a more capable,
  reliable, and expressive language for distributed programming.

* Python 3 (unlike Python 2) has a better-kept house: its standard
  library, exception hierarchy, bytecode files and extension modules,
  and import mechanics, have all undergone consolidation and are more
  predictable and uniform across implementations.

There are https://docs.python.org/3/whatsnew/> many other benefits.
See https://wiki.python.org/moin/Python2orPython3> for a discussion
of how to determine whether it's yet time for you to go with Python 3.

In brief though, from that last document:

Short version: Python 2.x is legacy, Python 3.x is the present and
future of the language
[…]
Which version you ought to use is mostly dependent on what you want
to get done.

If you can do exactly what you want with Python 3.x, great!

-- 
 \“Spam will be a thing of the past in two years' time.” —Bill |
  `\ Gates, 2004-01-24 |
_o__)  |
Ben Finney

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

Re: Why Python 3?

[Rustom Mody]

On Saturday, April 19, 2014 4:35:41 PM UTC+5:30, Ben Finney wrote:
> Well, it's clear: Python 3 is uncontroversially the future :-) Also:

>  \"Spam will be a thing of the past in two years' time." --Bill |
>   `\ Gates, 2004-01-24 |
> _o__)  |
> 

!

I wonder if the main content of your post was the post or this footer?!?!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why Python 3?

[Steve Hayes]

On Fri, 18 Apr 2014 22:28:05 -0500, Anthony Papillion 
wrote:

>Hello Everyone,
>
>So I've been working with Python for a while and I'm starting to take
>on more and more serious projects with it. I've been reading a lot
>about Python 2 vs Python 3 and the community kind of seems split on
>which should be used.
>
>Some say 'Python 3 is the future, use it for everything now' and other
>say 'Python 3 is the future but you can't do everything in it now so
>use Python 2'.

Yes, that made me more or less abandon my attempt to learn Python.

I had Python 3 on my computer (came on one of those freebie discs you get with
magazines, I think) and my son had a book on it, so I thought with the program
and the instructions I should be able to learn something. 

It took me a week, with some help from this forum, to get the Print statement
to work. 


-- 
Steve Hayes from Tshwane, South Africa
Web:  http://www.khanya.org.za/stevesig.htm
Blog: http://khanya.wordpress.com
E-mail - see web page, or parse: shayes at dunelm full stop org full stop uk
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: module and namespace

[bob gailer]

On 4/16/2014 6:38 AM, Egon Frerich wrote:

If I use the interpreter I get:

Python 3.3.5 (default, Apr 12 2014, 23:34:20)
[GCC 4.6.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
import mptt
print(mptt)



But if I import mptt in my program the print-statement gives



What is the meaning? When does this happened?
I can't reproduce that behavior. Running a script with just those 2 
lines in gives me the same result as running in the interactive session.


Please post the program. Otherwise we are shooting in the dark.

Also note print is a function not a statement.

Be sure to:
-  Place your answers following the relevant text.
-  Delete old text that is no longer relevant.
-  Ensure a copy of your reply goes to the list.

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

Re: Why Python 3?

[Chris Angelico]

On Sat, Apr 19, 2014 at 9:53 PM, Steve Hayes  wrote:
>>Some say 'Python 3 is the future, use it for everything now' and other
>>say 'Python 3 is the future but you can't do everything in it now so
>>use Python 2'.
>
> Yes, that made me more or less abandon my attempt to learn Python.
>
> I had Python 3 on my computer (came on one of those freebie discs you get with
> magazines, I think) and my son had a book on it, so I thought with the program
> and the instructions I should be able to learn something.
>
> It took me a week, with some help from this forum, to get the Print statement
> to work.

If your book and your interpreter didn't match, then that's a problem,
just as if you were working with different versions of any other
software. (Can you imagine reading through a Microsoft Excel tutorial
and trying to do the exercises in a different version of Excel?) The
print statement wouldn't work because there isn't one; the print
*function* will work quite happily, though. All you need is for
someone to explain it to you as a function, and you'll be fine.

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

Re: Why Python 3?

[Ian Foote]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 19/04/14 05:49, Andrew Berg wrote:
> On 2014.04.18 22:28, Anthony Papillion wrote:
>> What is the general feel of /this/ community? I'm about to start
>> a large scale Python project. Should it be done in 2 or 3? What
>> are the benefits, aside from the 'it's the future' argument?
> Python 3 is not the future; it is the present. If you're developing
> an application, just use Python 3.4 and don't look back unless you 
> absolutely positively *need* one of the big libraries that doesn't
> fully support Python 3 yet. The smaller ones either support it or
> have been replaced, and the few remaining (e.g., Twisted, Django)
> are getting there.

Django has been there since 1.5. My company has been using python3 in
production since 1.6 was released. There have been a few other third
party libraries we've wanted to use but can't, but we've been able to
work around that.

Regards,
Ian F

-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTUnMOAAoJEODsV4MF7PWzhEsH/infLqjUcGh+vSTaMNEvjuRn
/vqaxiok5/9opocoDtBbK707rpJz55V+NP1ajhso0llhLlQ1T7XyAK2QQthfvcTd
FIyn7uw7ud5nofivXUkkO3g9FoHRASZnAc9mXZGGV7O1RKjA3YvEccOakJKpq/jC
UYzBYLOfkUzLYV9yQPaE5Dxt/rRmO1NLNzdBMXXTBOy4s6hd+B+TSCCgAgGy05ZJ
yNePgO98N2wq7W/iG4EAw409rxXYxR0cAHNSID7+m1omSTPls4PV+jyIfmoS+eBl
6nWkqjVw3yw2cF0gBs1k/sjxPZ/aXOjD1FxpIhBOvh+upNieFSP0AT2X5R3NRnw=
=wW3W
-END PGP SIGNATURE-
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why Python 3?

[Andrew Berg]

On 2014.04.19 07:58, Ian Foote wrote:
> Django has been there since 1.5. My company has been using python3 in
> production since 1.6 was released. There have been a few other third
> party libraries we've wanted to use but can't, but we've been able to
> work around that.
I guess I'm a bit behind the times then. Last I checked, only certain parts of 
it were working on Python 3. Nice to hear that it fully
supports Python 3 now. :)

-- 
CPython 3.4.0 | Windows NT 6.2.9200 / FreeBSD 10.0
-- 
https://mail.python.org/mailman/listinfo/python-list

converting old project to Python 3 was: Re: Why Python 3?

[Eric S. Johansson]

On 4/19/2014 12:04 AM, Ryan Hiebert wrote:
If you are starting a new project, I'd highly encourage you to use 
Python 3. It is a stable, well supported, and beautiful language, and 
gives you the full power of the innovation that is current in the 
Python world. Python 2 is still well supported (for a while to come), 
but you won't have the same access to new features and ideas that you 
would on Python 3.


The only reason that I'd still be on Python 2 is if I absolutely had 
to use a library that for some reason is not yet working on Python 3. 
Even then, I'd work hard to try and write it in Python 3 style Python 
2, because I'd want to be on Python 3 as soon as possible.


The Python extensions to NaturallySpeaking are combination of C++ for a 
COM interface and Python for grammar management. 
http://qh.antenna.nl/unimacro/implementation_and_acceptance_of_natlink.pdf


How hard is it to convert from C++ extensions for 2.x to 3.x? are there 
any tools to help with the process?


Thanks for any insights.

--- eric

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

Re: Why Python 3?

[Roy Smith]

Chris Angelico  wrote:

> I strongly recommend going for Python 3 unless something actually
> stops you from doing so.

One of the problems is you don't know in advance if something is going 
to stop you.  By committing to P3 now, you are eliminating from possible 
future use, all of those third-party modules which only support P2.  And 
you don't know which of those you'll need until you sometime in the 
future.

It's rare to find a modern, actively maintained module which doesn't 
either support P3 already, or at least has that on its roadmap, but 
there's a lot of old stuff out there which is still very useful.

> If you absolutely must use Python 2, try to
> aim for a minimum of 2.6 or 2.7

That I absolutely agree with.  Unless I had some specific legacy use 
case I needed to continue to support, I wouldn't waste any time worrying 
about 2.5 support, and we're quickly reaching the point where the same 
can be said about 2.6.

> and start your program with this line:
> 
> from __future__ import print_function, unicode_literals, division

That seems reasonable, but be prepared for possible unicode issues.  
There is code out there in third party modules which makes 
unicode-unfriendly assumptions about strings.  For example:

https://github.com/brandon-rhodes/pyephem/issues/35

I'm not saying don't use unicode_literals (we do), just we aware that 
you might have to explicitly cast things to str() once in a while.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why Python 3?

[Chris Angelico]

On Sat, Apr 19, 2014 at 11:26 PM, Roy Smith  wrote:
> Chris Angelico  wrote:
>
>> I strongly recommend going for Python 3 unless something actually
>> stops you from doing so.
>
> One of the problems is you don't know in advance if something is going
> to stop you.  By committing to P3 now, you are eliminating from possible
> future use, all of those third-party modules which only support P2.  And
> you don't know which of those you'll need until you sometime in the
> future.

Conversely, committing to Py2 now eliminates from possible future use
all modules which support only Py3. Is there strong evidence that one
of those groups is larger than the other?

>> If you absolutely must use Python 2, try to
>> aim for a minimum of 2.6 or 2.7
>
> That I absolutely agree with.  Unless I had some specific legacy use
> case I needed to continue to support, I wouldn't waste any time worrying
> about 2.5 support, and we're quickly reaching the point where the same
> can be said about 2.6.

Red Hat? :) Though that's likely to be the last bastion of ancient
Python out there, soon. Debian Squeeze (oldstable) ships with 2.6, so
if you aim for 2.6+, you should catch all the distros that derive from
Debian (the current Debian stable, Wheezy, ships with 2.7). But Red
Hat will be supporting older Pythons for a good while.

>> and start your program with this line:
>>
>> from __future__ import print_function, unicode_literals, division
>
> That seems reasonable, but be prepared for possible unicode issues.
> There is code out there in third party modules which makes
> unicode-unfriendly assumptions about strings.

Right. It's not the magic line that fixes everything; if it were,
Python 3 wouldn't be a big deal at all. Go Py3 if you can, but if you
can't, at least make your double-quoted strings Unicode strings, and
then you have a chance to find problems.

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

Re: TeX $\times$ symbol not working in matplotlib?

[gwhite]

On Friday, April 18, 2014 8:46:13 PM UTC-7, Larry Hudson wrote:
> On 04/18/2014 04:14 PM, gwhite wrote:
> 
> > [snip]
> > I'm not sure when a backslash continuation might be needed, or if that 
> > requirement has been designed out of Python.
> 
> ['they' meaning trailing backslashes]
> 
> No, 'they' are still definitely in Python, but can usually be avoided.
> 
> As already mentioned, strings are automatically concatenated if they are 
> separated by only 
> whitespace (spaces/tabs/newlines).  But there is a difference between this 
> concatenation and 
> using a trailing backslash.  For example:
> 
> print('this, that, '
>  'the other')
>  
> gives -> 'this, that, the other'
> 
> print('this, that, \
>  the other')
> 
> gives -> 'this, that, the other'
> 
> The leading whitespace in the second example is significant, but is ignored 
> in the first.
> 
> The other places you can avoid the trailing backslash is within brackets, ie. 
> (), [] or {}.
> Here you can split at any 'natural' position, that is following a comma, dot 
> or an operator.
> 
> ['spam',
>  'eggs',
> 'bacon']
>  
> gives -> ['spam', 'eggs', 'bacon']
> 
> - 
> [2 +
>   3, 
>'spam']
>
> gives -> [5, 'spam']
> 
> -
> print('this' and
>  'that' or
>  'other')
> 
> gives -> 'that'
> 
> -
> print('{}'.
>  format('spam'))
> 
> gives -> 'spam'
> 
> These examples are somewhat contrived, but they do show what I'm talking 
> about.
> 
> Of course, you can still use the trailing backslash method, but when you can 
> avoid it it usually 
> looks cleaner.  Besides simply using either method to split long lines, it is 
> often used to line 
> things up, either for the appearance or for documentation.  Here is a 
> dictionary example of what 
> I mean (and the backslash method will NOT work here):
> 
> d = {1 : 'one',#  Describe this key/value pair
>  2 : 'two',#  Describe this one
>  3 : 'three'   #  Etc.
> }
> 
> Play around in the interactive mode to check out how this splitting works.

Thank you, Larry.  Your concise examples are nicely illustrative of the 
essentials.  I appreciate the explanation.

Thanks again to everyone.  

If I had the time, I would become a Python addict.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why Python 3?

[Rick Johnson]

On Friday, April 18, 2014 10:28:05 PM UTC-5, Anthony Papillion wrote:
> Hello Everyone,
> So I've been working with Python for a while and I'm starting to take
> on more and more serious projects with it. I've been reading a lot
> about Python 2 vs Python 3 and the community kind of seems split on
> which should be used.
> Some say 'Python 3 is the future, use it for everything now' and other
> say 'Python 3 is the future but you can't do everything in it now so
> use Python 2'.
> What is the general feel of /this/ community? I'm about to start a
> large scale Python project. Should it be done in 2 or 3? What are the
> benefits, aside from the 'it's the future' argument?

Python 3000 is the direct result of a hubris that even
surpasses Hitler's boneheaded attempt to fight the war on two
fronts. Yes, most of us agree that the changes are "positive
evolution" HOWEVER, are these minor repairs REALLY worth
polarizing a vibrant community and causing Python's
propagation to stagnate?

HELL NO!

Who would want to choose Python for a scripting language for
their project when EVEN the community cannot agree on which
version is best to use? But even *IF* every respected member
was a total "high-knee smooching tool" of GvR parroting off
that "Python 3000 is the best!", we cannot ignore the
functionality concerns that will result from choosing
between 2x or 3x.

NOBODY IS ACTIVELY CHOOSING PYTHON ANYMORE FOLKS!

Python is destined to destroy itself internally JUST like
the American society is currently destroying itself, and
what a travesty, since Python was the shining light of what
a program should be.

THE REVOLUTION WILL NOT BE TELEVISED!

Python is set to become extinct because GvR bought his time
machine AFTER infecting the code base with a print
statement -- thanks Guido, thanks for everything! Maybe next
time you should consider buying bean stalk beans instead!


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

Re: module and namespace

[Egon Frerich]

Am 18.04.2014 13:48, schrieb Peter Otten:
> Egon Frerich wrote:
> 

> 
> Basically Python 3 allows for packages to omit the __init__.py
> 
> $ mkdir aaa
> $ python3 -c'import aaa; print(aaa)'
> 
> $ touch aaa/__init__.py
> $ python3 -c'import aaa; print(aaa)'
> 
> 
> Namespace packages have advantages when you want to merge submodules from 
> multiple places into one package. See 
>  for the details.
> 
> Your actual problem is probably that the parent directory for the mptt 
> package is not in your sys.path,


The init-file in the parent directory was copied and had got the wrong
ownership.

Thanks Peter

Egon




smime.p7s
Description: S/MIME Cryptographic Signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: module and namespace

[Egon Frerich]

Am 19.04.2014 14:33, schrieb bob gailer:
> On 4/16/2014 6:38 AM, Egon Frerich wrote:
>> If I use the interpreter I get:
>>
>> Python 3.3.5 (default, Apr 12 2014, 23:34:20)
>> [GCC 4.6.3] on linux
>> Type "help", "copyright", "credits" or "license" for more information.
>> import mptt
>> print(mptt)
>> 
>>
>>
>> But if I import mptt in my program the print-statement gives
>>
>> 
>>
>> What is the meaning? When does this happened?
> I can't reproduce that behavior. Running a script with just those 2
> lines in gives me the same result as running in the interactive session.
> 
> Please post the program. Otherwise we are shooting in the dark.
> 
> Also note print is a function not a statement.
> 
> Be sure to:
> -  Place your answers following the relevant text.
> -  Delete old text that is no longer relevant.
> -  Ensure a copy of your reply goes to the list.
> 


Bob,

Peter Otten gave the hint. The __init__.py in the parent dictionary have
got the wrong ownership so it was not accessible.

Egon




smime.p7s
Description: S/MIME Cryptographic Signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why Python 3?

[Rustom Mody]

On Saturday, April 19, 2014 5:23:01 PM UTC+5:30, Steve Hayes wrote:
> It took me a week, with some help from this forum, to get the Print statement
> to work. 

How long does it take one to learn to drive a car?
To play the piano? To become a brain surgeon?

No I am not exactly in the "gung-ho over python 3" camp
However if you dont start out learning programming with an estimate of work 
somewhere between learning to:
- drive-a-car
- play-the-piano
you are setting yourself up for failure.
But its equally unreasonable to expect to learn programming more easy than to 
drive a car.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: converting old project to Python 3 was: Re: Why Python 3?

[Mark Lawrence]

On 19/04/2014 14:06, Eric S. Johansson wrote:


On 4/19/2014 12:04 AM, Ryan Hiebert wrote:

If you are starting a new project, I'd highly encourage you to use
Python 3. It is a stable, well supported, and beautiful language, and
gives you the full power of the innovation that is current in the
Python world. Python 2 is still well supported (for a while to come),
but you won't have the same access to new features and ideas that you
would on Python 3.

The only reason that I'd still be on Python 2 is if I absolutely had
to use a library that for some reason is not yet working on Python 3.
Even then, I'd work hard to try and write it in Python 3 style Python
2, because I'd want to be on Python 3 as soon as possible.


The Python extensions to NaturallySpeaking are combination of C++ for a
COM interface and Python for grammar management.
http://qh.antenna.nl/unimacro/implementation_and_acceptance_of_natlink.pdf

How hard is it to convert from C++ extensions for 2.x to 3.x? are there
any tools to help with the process?

Thanks for any insights.

--- eric



https://docs.python.org/3/howto/cporting.html

--
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: Why Python 3?

[Terry Reedy]

On 4/19/2014 2:40 AM, Paul Rubin wrote:


That said, I don't know anyone who actually uses Python 3.


I have no idea who you know ;-)

LibreOffice bundles 3.3. So anyone who does Python scripting in 
LibreOffice is using Python 3. Actually, I believe LO uses Python 
internally for some of its scripting. If so, everyone using LO is 
indirectly using 3.3.


--
Terry Jan Reedy

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

Re: Why Python 3?

[Mark Lawrence]

On 19/04/2014 07:40, Paul Rubin wrote:


That said, I don't know anyone who actually uses Python 3.



You do now :)

--
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: Why Python 3?

[Chris Angelico]

On Sun, Apr 20, 2014 at 3:23 AM, Terry Reedy  wrote:
> LibreOffice bundles 3.3. So anyone who does Python scripting in LibreOffice
> is using Python 3.

This much I agree with...

> Actually, I believe LO uses Python internally for some of
> its scripting. If so, everyone using LO is indirectly using 3.3.

... but this is kinda pushing it, I think. You're not *using* it any
more than you're using Python whenever you post to Savoynet [1] -
after all, Savoynet is a Mailman list, and Mailman runs on Python. But
all those theatre people don't become Python users because of that.
I'd have to say that "using Python 3" means writing code that runs in
Python 3. So the LO people would, by your statement, be using Py3.3,
as would anyone who actually writes LO scripts; but someone who just
fires up LO, edits a document in the WYSIWYG editor, and goes about
his business, isn't really using Python.

Though the broader definition does have its uses. It's fun to explain
to someone how that little device that shows him a map and where he is
on it is depending on both special and general relativity. (GPS
signals are strongly based on time, and the satellites are moving
relative to the observer, and gravity is weaker up there.) But you're
not really making use of the science yourself, you're depending on
someone else having made use of it - same as you can hop on an
airliner without understanding the physics of flight, much less the
effects of birdstrike on jet engines. You're just glad that someone,
somewhere, has worked all that out :)

ChrisA

[1] http://savoynet.oakapplepress.com/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why Python 3?

[Albert-Jan Roskam]

- Original Message -

> From: Chris Angelico 
> To: 
> Cc: "python-list@python.org" 
> Sent: Saturday, April 19, 2014 3:42 PM
> Subject: Re: Why Python 3?



> Right. It's not the magic line that fixes everything; if it were,
> Python 3 wouldn't be a big deal at all. Go Py3 if you can, but if you
> can't, at least make your double-quoted strings Unicode strings, and
> then you have a chance to find problems.

Totally agree. It's not that hard at all. I consider it true craftmanship that 
Guido had the guts break backward compatibility and clean up some mistakes. 
Compare this with CRAN R, where so much illogical S-plus stuff is present (word 
count for "historical anomaly": 1000+ ;-). 

Am I the only one who always thinks of Rogers' Diffusion of Innovations curve 
with these Python2/3 debates? 
http://en.wikipedia.org/wiki/File:Diffusion_of_ideas.svg. source: 
http://en.wikipedia.org/wiki/Diffusion_of_innovations
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why Python 3?

[Ian Kelly]

On Sat, Apr 19, 2014 at 3:37 AM, Chris Angelico  wrote:
> On Sat, Apr 19, 2014 at 7:25 PM, Ian Kelly  wrote:
>> The change from / denoting "classic
>> division" to "true division" really only affects the case where both
>> operands are integers, so far as I'm aware.  If you want to divide two
>> integers and get a decimal result, then convert one or both of them to
>> decimals first; you would have needed to do the same with classic
>> division.
>
> If float were a perfect superset of int, and the only logical superset
> when you want non-integers, then it'd be fine.

Decimal is also not a perfect superset of int (although I believe it
is a superset of the intersection of int and float).  Even if it were,
I'm not sure it would be appropriate to bless Decimal in this way
either, because they have no place in Python's number type hierarchy:

>>> from decimal import Decimal
>>> from numbers import Real
>>> isinstance(Decimal('1.23'), Real)
False

> But if you're mixing
> int and Decimal, you have to explicitly convert, whereas if you're
> mixing int and float, you don't. Why is it required to be explicit
> with Decimal but not float? Of all the possible alternate types, why
> float? Only because...
>
>> As for "why float" specifically, the division __future__ import has
>> been around since 2.2, longer than either decimals or fractions.
>
> ... it already existed. There's no particular reason to up-cast to
> float, specifically, and it can cause problems with large integers -
> either by losing accuracy, or by outright overflowing.

The authors of PEP 238 expressed their hope that when a rational type
(i.e. Fraction) was implemented, it would become the result type for
true division on two integers.  I don't know why that never came to
pass; perhaps performance considerations won out.

> In Python 3, you have to say "Oh but I want my integer division to
> result in an integer":
>
> x * 10 // 5 == x * 2

Technically this says "I want the result of floor division", not "I
want the result as an integer".  If you apply the floor division
operator to a non-int type, you'll get a non-int result.  It just so
happens that the result of floor division of two integers can be given
as an integer, whereas the result of true division cannot.

Considering that Fraction and Decimal did not exist yet, what type do
you think the PEP 238 implementers should have chosen for the result
of dividing two ints?  If float is not acceptable, and int is not
acceptable (which was the whole point of the PEP), then the only
alternative I can see would have been to raise a TypeError and force
the user to upcast explicitly.  In that case, dividing arbitrary ints
using floating-point math would not be possible for those ints that
are outside the range of floats; you would get OverflowError on the
upcast operation, regardless of whether the result of division would
be within the range of a float.

> Yes, I can see that it's nice for simple interactive use.

More importantly, it's useful for implementers of generic mathematical
routines.  If you're passed arbitrary inputs, you don't have to check
the types of the values you were given and then branch if both of the
values you were about to divide happened to be ints just because the
division operator arbitrarily does something different on ints.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why Python 3?

[Chris Angelico]

On Sun, Apr 20, 2014 at 5:58 AM, Ian Kelly  wrote:
> Considering that Fraction and Decimal did not exist yet, what type do
> you think the PEP 238 implementers should have chosen for the result
> of dividing two ints?  If float is not acceptable, and int is not
> acceptable (which was the whole point of the PEP), then the only
> alternative I can see would have been to raise a TypeError and force
> the user to upcast explicitly.  In that case, dividing arbitrary ints
> using floating-point math would not be possible for those ints that
> are outside the range of floats; you would get OverflowError on the
> upcast operation, regardless of whether the result of division would
> be within the range of a float.
>
>> Yes, I can see that it's nice for simple interactive use.
>
> More importantly, it's useful for implementers of generic mathematical
> routines.  If you're passed arbitrary inputs, you don't have to check
> the types of the values you were given and then branch if both of the
> values you were about to divide happened to be ints just because the
> division operator arbitrarily does something different on ints.

Or you just cast one of them to float. That way you're sure you're
working with floats.

The main trouble is that float is not a perfect superset of int. If it
were, then it really would be upcasting, same as turning a float into
a complex is; there's no downside, other than performance.

If I'd been in charge, I would have simply let int/int continue to
return an int, as that's the one thing that is guaranteed not to
behave differently on different input values. Python 3 fixed Unicode
handling by ensuring that mixing text and bytes would cause problems
straight away, rather than waiting until you get a character with a
codepoint higher than U+00FF; 3.3 went further and made sure you
wouldn't get problems by going past U+ even on Windows. I think we
all agree (well, all bar the trolls) that that was a good thing. So
why do we have this sort of thing go weird?

def always_true(x):
assert type(x) is int
return x*10/2 == x*5

In Python 2, I believe that will indeed be always true, for any
integer x. (Yeah, there's a naughty type check in there. I'm talking
about integers, mmkay?) In Python 3, it might not be.

>>> always_true(2**53)
True
>>> always_true(2**53+1)
False

(32-bit Windows, because I'm on the laptop. Other Pythons, other CPUs,
etc, may have different points where that happens, but the same will
happen.)

So either you keep a very close eye on everything to make sure you
don't have floats infecting your calculations, or you ignore the
problem and then start seeing odd stuff happen with specific numbers.
I'd rather have to explicitly request floating-point division; that
way, you get issues a lot sooner and more simply. "Why is 34/10 equal
to 3?" is a lot easier to explain than "Why does my program not work
when I give it numbers with lots of data encoded in them, when it
works fine with sequential numbers from zero?". (Imagine if you work
with invoice numbers, for instance, and your code is fine; but if you
encode the date into the first eight digits, then put the store number
in the next three, register number in the next three, and then the
last three are sequential. Should work the same, right?)

Anyway, way too late to change now. That ship sailed in 2.2 or thereabouts.

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

Re: Why Python 3?

[Ian Kelly]

On Sat, Apr 19, 2014 at 2:31 PM, Chris Angelico  wrote:
> On Sun, Apr 20, 2014 at 5:58 AM, Ian Kelly  wrote:
>> Considering that Fraction and Decimal did not exist yet, what type do
>> you think the PEP 238 implementers should have chosen for the result
>> of dividing two ints?  If float is not acceptable, and int is not
>> acceptable (which was the whole point of the PEP), then the only
>> alternative I can see would have been to raise a TypeError and force
>> the user to upcast explicitly.  In that case, dividing arbitrary ints
>> using floating-point math would not be possible for those ints that
>> are outside the range of floats; you would get OverflowError on the
>> upcast operation, regardless of whether the result of division would
>> be within the range of a float.
>>
>>> Yes, I can see that it's nice for simple interactive use.
>>
>> More importantly, it's useful for implementers of generic mathematical
>> routines.  If you're passed arbitrary inputs, you don't have to check
>> the types of the values you were given and then branch if both of the
>> values you were about to divide happened to be ints just because the
>> division operator arbitrarily does something different on ints.
>
> Or you just cast one of them to float. That way you're sure you're
> working with floats.

Which is inappropriate if the type passed in was a Decimal or a complex.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why Python 3?

[Chris Angelico]

On Sun, Apr 20, 2014 at 6:38 AM, Ian Kelly  wrote:
>> Or you just cast one of them to float. That way you're sure you're
>> working with floats.
>
> Which is inappropriate if the type passed in was a Decimal or a complex.

In that case, you already have a special case in your code, so whether
that special case is handled by the language or by your code makes
little difference. Is your function so generic that it has to be able
to handle float, Decimal, or complex, and not care about the
difference, and yet has to ensure that int divided by int doesn't
yield int? Then say so; put in that special check. Personally, I've
yet to meet any non-toy example of a function that needs that exact
handling; most code doesn't ever think about complex numbers, and a
lot of things look for one specific type:

>>> "asdf"*3.0
Traceback (most recent call last):
  File "", line 1, in 
"asdf"*3.0
TypeError: can't multiply sequence by non-int of type 'float'

Maybe it's not your code that should be caring about what happens when
you divide two integers, but the calling code. If you're asking for
the average of a list of numbers, and they're all integers, and the
avg() function truncates to integer, then the solution is to use sum()
and explicitly cast to floating point before dividing. Why should the
language handle that? It's no different from trying to sum a bunch of
different numeric types:

>>> sum([1.0,decimal.Decimal("1")])
Traceback (most recent call last):
  File "", line 1, in 
sum([1.0,decimal.Decimal("1")])
TypeError: unsupported operand type(s) for +: 'float' and 'decimal.Decimal'

The language doesn't specify a means of resolving the conflict between
float and Decimal, but for some reason the division of two integers is
blessed with a language feature. Again, it would make perfect sense if
float were a perfect superset of int, so that you could simply declare
that 1.0 and 1 behave absolutely identically in all arithmetic (they
already hash and compare equally), but that's not the case, so I don't
see that division should try to pretend they are.

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

Re: Why Python 3?

[Gregory Ewing]

Chris Angelico wrote:

I'd rather have to explicitly request floating-point division;


When you write / in Python 3, you *are* explicitly requesting
floating-point division.

Similarly, when you write // you're explicitly requesting
integer division.

I don't see the problem. You write whatever you mean and it
does what you tell it to do.


So either you keep a very close eye on everything to make sure you
don't have floats infecting your calculations,


If you have something that works exclusively on ints and someone
passes you a float, and you don't check for that, you'll have
problems anyway even if no division is involved at all.

There's no way that Python 3 division can *introduce* a float
into an integer calculation unless you write / somewhere where
you really meant //. But that's the same kind of mistake as
calling foo() when you meant to call bar(). You can't blame
the language for that.


but if you
encode the date into the first eight digits, then put the store number
in the next three, register number in the next three, and then the
last three are sequential. Should work the same, right?)


It'll work fine as long as you use // when extracting the parts.
If you use / then you're *explicitly* saying to do the calculation
in floating point, which would not be a sane thing to do.

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

Re: Why Python 3?

[Chris Angelico]

On Sun, Apr 20, 2014 at 11:06 AM, Gregory Ewing
 wrote:
> Chris Angelico wrote:
>>
>> I'd rather have to explicitly request floating-point division;
>
>
> When you write / in Python 3, you *are* explicitly requesting
> floating-point division.
>
> Similarly, when you write // you're explicitly requesting
> integer division.
>
> I don't see the problem. You write whatever you mean and it
> does what you tell it to do.

Truncating vs true is not the same as int vs float. If you mean to
explicitly request float division, you call float() on one or both
arguments. You're being explicit about something different.

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

Re: Why Python 3?

[Gregory Ewing]

Chris Angelico wrote:

Is your function so generic that it has to be able
to handle float, Decimal, or complex, and not care about the
difference, and yet has to ensure that int divided by int doesn't
yield int?


It doesn't have to be that generic to cause pain. Even if
you're only dealing with floats, the old way meant you had
to stick float() calls all over the place in order to be
sure your divisions do what you want. Not only does that
clutter up and obscure the code, it's needlessy inefficient,
since *most* of the time they don't do anything.

There's also the annoyance that there's more than one
obvious way to do it. Do you write float(x)/y or
x/float(y)? Or do you go for a more symmetrical look
and write float(x)/float(y), even though it's redundant?

The new way makes *all* of that go away. The only downside
is that you need to keep your wits about you and select
the appropriate operator whenever you write a division.
But you had to think about that *anyway* under the old
system, or risk having your divisions silently do the
wrong thing under some circumstances -- and the remedy
for that was very clunky and inefficient.

I'm thoroughly convinced that the *old* way was the
mistake, and changing it was the right thing to do.


The language doesn't specify a means of resolving the conflict between
float and Decimal, but for some reason the division of two integers is
blessed with a language feature.


No, it's not. What the language does is recognise that
there are two kinds of division frequently used, and that
the vast majority of the time you know *when you write the
code* which one you intend. To support this, it provides two
operators. It's still up to the types concerned to implement
those operators in a useful way.

The built-in int and float types cooperate to make // mean
integer division and / mean float division, because that's
the most convenient meanings for them on those types.
Other types are free to do what makes the most sense for
them.

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

Re: Why Python 3?

[Michael Torrie]

On 04/18/2014 10:49 PM, Andrew Berg wrote:
> Python 3 is not the future; it is the present. If you're developing
> an application, just use Python 3.4 and don't look back unless you 
> absolutely positively *need* one of the big libraries that doesn't
> fully support Python 3 yet. 

Depends on what OS you want to be running on.  I don't know of any
currently-supported Enterprise distributions (long-term support) that
ship with Python 3.4.  Few ship Python 3.3 yet.  For example, RHEL 6 is
Red Hat's most current enterprise distribution and it does not yet even
ship Python 2.7, to say nothing of Python 3.  RHEL 7 has python 2.7 as
the default system dependency, and currently does not yet have any
python3 packages in the official main repo, though I imagine it will
probably show up, as it is in Fedora 19, which RHEL7 is based on.  Of
course you can easily install Python3 on most any distro, either from
third-party repos or source, neither of which would be allowed in the
enterprise I last worked in, unless the repo was trusted and vetted.
One could ship a compiled python 3.[34] interpreter with one's package I
suppose.

With Windows it's quite different. There's no system python to start
with so you can either bundle python with your app, or require one of
the official python 3.[34] packages as a prerequisite.

It's the conservative nature of LTS distributions that slows the
adoption of Python 3.  Especially in server space.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why Python 3?

[Paul Rubin]

Terry Reedy  writes:
> LibreOffice bundles 3.3. So anyone who does Python scripting in
> LibreOffice is using Python 3. Actually, I believe LO uses Python
> internally for some of its scripting. If so, everyone using LO is
> indirectly using 3.3.

I didn't even know LO supported Python scripting, but I wouldn't count
such indirect use anyway.  I meant I don't know any Python programmers
(at least in person) who use Python 3 for their daily coding.  I think
this is mostly because they (and I) use whatever is in the OS distro,
and that is generally still 2.6 or 2.7.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why Python 3?

[Terry Reedy]

On 4/19/2014 9:06 PM, Gregory Ewing wrote:

Chris Angelico wrote:

I'd rather have to explicitly request floating-point division;


When you write / in Python 3, you *are* explicitly requesting
floating-point division.

Similarly, when you write // you're explicitly requesting
integer division.


One is requesting 'floor division'

>>> 3.0//2.0
1.0

To me, calling that integer division is a bit misleading in that one 
might expect the result, at least, to be an int rather than a float. 
(Yes, it is an integer-valued float.)


--
Terry Jan Reedy

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