Re: Why Python 3?
Hi, I can't give you the advise for a concrete version anyway there are lot of arguments given by the other posters. BUT there is a way how you can circumvent the problem to some extend: Are you intending to use Jenkins? I don't want to convince you here why to use Jenkins but maybe I don't need to and THEN you just install the ShiningPanda plugin and each time your project is build automatically because of a change all tests are running across multiple Python versions. This way you won't have too many problems to switch to another newer Python version. Keep the build green. 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? -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 3?
Chris Angelico wrote: As it is, we have the case that most lowish integers have equivalent floats (all integers within the range that most people use them), and beyond that, you have problems. No, I don't. I'm not talking about representing ints using floats, I'm talking about representing floats using ints. *Every* possible integer-valued float value can be written exactly as a Python int. It doesn't matter that there are some ints that can't be represented as floats, because when I'm writing an int literal as a shorthand for a float, I'm not going to be using any of those values -- or if I do, I'm willing to accept the resulting loss of precision, because in my mind they're *not* ints, they're floats. But would you rather have to deal with the problem straight away, or when your program is some day given a much bigger number to swallow, and it quietly rounds it off to the nearest multiple of 8? I don't understand what problem you're imagining here. Any program that needs to do exact calculations with integer values should work with ints throughout and use // or divmod() if it needs to do any division. Nothing will get unexpectedly rounded off then. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 3?
wxPhoenix. The funny side of wxPhoenix is, that it *also* has its own understanding of unicode and it finally only succeeds to produce mojibakes. I've tried to explained... (I was an early wxPython user from wxPython 2.0 (!). I used, tested, reported about, all wxPython versions up to the shift to the wxPython 2.9 unicode only versions, then I gave up). -- Something else. I'm ready to bet, the unicode related bugs I found in Python 3 (core Python) are still here in five years from now. -- Something else, part 2. IDLE. Ten seconds to make it crashing, just by using unicode. -- Working with Python 2.7 + third party libs (even in iso-8859-1) *in* a pure cp1252 mode, including source code is a very, very solid experience. -- The Microsoft, Adobe, foundries... , and in the open software, the golang, ruby2, TeX unicode engines, all are working very correctly and smoothly with unicode. jmf PS Yes, I'm aware such comments are not really fair play. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 3?
Chris Angelico wrote: Earlier it was said that having both / and // lets you explicitly choose whether you want a float result or an int by picking an operator. I'm saying that's not so; the operator and the type aren't quite orthogonal, but close to. I don't think I said that, or if I did I was using sloppy language. As someone pointed out a couple of posts ago, it's not really about types, it's about selecting which *operation* you want to perform. Ordinary division and floor division are very different operations, and you want to be sure you get the right one. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 3?
Chris Angelico wrote: All other basic arithmetic operations on two numbers of the same type results in another number of that type. ... There's just one special case: dividing an integer by an integer yields a float, if and only if you use truediv. It sticks out as an exception. I take your point, but I think this is a case where practicality beats purity by a large margin. The idea that arithmetic should always give a result of the same type is all very nice in theory, but it just isn't practical where division is concerned. The reason it doesn't work well is because of the automatic promotion of ints to floats when they meet other floats. This leads to a style where people often use ints to stand for int-valued floats and expect them to be promoted where necessary. Things would be different if ints and floats were completely separate types, like str and bytes, but that would be extremely inconvenient. I used a language like that once, and it wasn't a pleasant experience. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 3?
On Tue, Apr 22, 2014 at 8:28 AM, Gregory Ewing greg.ew...@canterbury.ac.nz wrote: The reason it doesn't work well is because of the automatic promotion of ints to floats when they meet other floats. This leads to a style where people often use ints to stand for int-valued floats and expect them to be promoted where necessary. Things would be different if ints and floats were completely separate types, like str and bytes, but that would be extremely inconvenient. I used a language like that once, and it wasn't a pleasant experience. I do see that there are two sides to this. The question of Is 1.0 equal to 1? has a very obvious answer... whichever answer you go with, it's absolutely obvious! (Yes! They're the same number, of course they're equal! vs No! They're completely different representations, like 1 and 1 and \1 are all different!) Separating the types makes very good sense, and unifying them makes very good sense, and for different reasons. Unifying them in as many ways as possible means you don't need the syntactic salt of .0 on every number; you should be able to add 2.5+1 and get 3.5, just as if you'd added 2.5+1.0. And that's fine. Separating them also makes sense, though; it means that an operation on Type X and Type Y will behave equally sanely regardless of the values of those objects. As it is, we have the case that most lowish integers have equivalent floats (all integers within the range that most people use them), and beyond that, you have problems. This is, in my opinion, analogous to a UTF-16 string type; if you work with strings of nothing but BMP characters, everything works perfectly, but put in an astral character and things may or may not work. A lot of operations will work fine, but just a few will break. Python 3 has fixed that by giving us the pain of transition *right at the beginning*; you look at Text and at Bytes as completely separate things. People who like their ASCII like the idea that the letter A is equivalent to the byte 0x41. It's convenient, it's easy. But it leads to problems later. Now, the analogy does break down a bit in that it's probably more likely that a program will have to deal with non-ASCII characters than with integers that can't be represented in IEEE double precision. But would you rather have to deal with the problem straight away, or when your program is some day given a much bigger number to swallow, and it quietly rounds it off to the nearest multiple of 8? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 3?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 20/04/14 03:34, Michael Torrie wrote: 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. I don't know if you'd count it as an Enterprise distribution, but ubuntu 14.04 (LTS) ships with python 3.4 (and 2.7). Regards, Ian F -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTU4mGAAoJEODsV4MF7PWzR2sIAL4P0DhzWr5b7T4tfxSFWvlM A31VEwh1MiL8qQKi+ukzm1lumnqF0VZG5a8VYOrq9F/AgbPmkmdaJ3vwlNSZYYrq X6E0zdszTbnK6ec3zNHsqhWd7id/vzyJG5OQkDgg7K9dHY2r2lYfneIUhKvGy01q 6kaqWWXs77UIeWam2amjhtAMsUZtte/828CoIugHBdZgUhmbbNA8PK6/38w6BSgw 3NzT2kCz0298jqPUUZw++pap0Bb/9tQ+Ceps6KKeCE3QJ12Qn7Viv7TnrpQQnkeT Wt56VWoS9VGodB8h7ozHFGeA11VePN9YdLeM+CuUqNsOxXhuean7ysMiazMU30s= =mv5B -END PGP SIGNATURE- -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 3?
Paul Rubin no.email@nospam.invalid writes: [people I know] use whatever is in the OS distro, and that is generally still 2.6 or 2.7. When the OS contains *both* Python 2 and Python 3, does Python 3 count as “in the OS”? Or will you only count Python 3 as “in the OS” when Python 2 is not present at all in the OS? I think your description isn't accurate. Python 3 is very likely in the OS also, so you are using some other criterion to decide to use the legacy Python 2 instead of the current Python 3 also supplied with the OS. -- \ Moriarty: “Forty thousand million billion dollars? That money | `\must be worth a fortune!” —The Goon Show, _The Sale of | _o__) Manhattan_ | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 3?
On Fri, 18 Apr 2014 21:50:09 -0700, Ethan Furman wrote: Use Python 3 if you can. The best reason not to is if you have some critical library that you absolutely need and it's not yet available on 3. That's good advice, but it isn't just applicable to Python 3, it applies to *any* critical library that does not support recent versions of Python. Suppose you have a library that only supports Python 2.2, 2.3 and 2.4, and you cannot do without that library or reinvent it yourself. Then you would surely use Python 2.4. That shouldn't be seen as a rejection of all the versions from 2.5 onwards, but a painful and necessary decision due to the requirement to use that library. In practice, most libraries that don't support 2.5 and better are more or less abandoned. But you might still choose to use an abandoned library because it works and you don't need to worry about security updates. So really the advice comes down to: - if you can, use the latest version of Python, which is 3.4; - if you must, use the version of Python provided by your operating system, which could be anything from Python 2.3 to 3.3; - if you have no choice except to use a library that only supports version X, then use version X, no matter what X happens to be. None of this should be controversial. It should be common sense. (There are, of course, a few difficult questions relating to what counts as must. You may weigh up the cost of doing without that annoyingly old library versus the benefit of using a more recent Python version, and decide that maybe you can do without it. Or not.) -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 3?
On Fri, 18 Apr 2014 23:40:18 -0700, Paul Rubin wrote: It's just that the improvement from 2 to 3 is rather small, and 2 works perfectly well and people are used to it, so they keep using it. Spoken like a true ASCII user :-) The killer feature of Python 3 is improved handling of Unicode, which now brings Python 3 firmly into the (very small) group of programming languages with first-class support for more than 128 different characters by default. Unfortunately, that made handling byte strings a bit more painful, but 3.4 improves that, and 3.5 ought to fix it. People doing a lot of mixed Unicode text + bytes handling should pay attention to what goes on over the next 18 months, because the Python core developers are looking to fix the text/byte pain points. Your feedback is wanted. There are nice tools that help port your codebase from 2 to 3 with fairly little effort. But, you can also keep your codebase on 2 with zero effort. So people choose zero over fairly little. True. But for anyone wanting long term language support, a little bit of effort today will save them a lot of effort in six years time. -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 3?
On Sat, 19 Apr 2014 09:26:53 -0400, Roy Smith wrote: 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. I believe this is more of an issue in theory than in practice. My on-line web portal app could potentially use any of a thousand different Python 2.x only libraries, but in practice I'm probably only going to use half a dozen libraries, or fewer, and know very early in the design phase what I need (web templating software, yes, library to control radio telescopes, probably not). And I'm likely to eliminate from contention most libraries that seem unsupported or abandoned, and if they only support Python 2 five years since the introduction of Python 3, they better have a good reason for it. -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Integer and float division [was Re: Why Python 3?]
On Sat, 19 Apr 2014 19:37:31 +1000, Chris Angelico wrote:
On Sat, Apr 19, 2014 at 7:25 PM, Ian Kelly ian.g.ke...@gmail.com
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,
I don't think so. Operations on mixed int/Decimal arguments return
Decimal. There's no conversion needed except to get the original Decimal
number in the first place. (Decimal is not a built-in and there's no
literal syntax for them.)
py from decimal import Decimal as D
py x, y = 1, D(2)
py x/y
Decimal('0.5')
py x//y
Decimal('0')
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...
Because float is built-in and Decimal is not. Because Decimal wasn't
introduced until Python 2.4 while the change to the division operator was
first begun back in Python 2.2.
http://python.org/dev/peps/pep-0238/
Guido writes about why his decision to emulate C's division operator was
a mistake:
http://python-history.blogspot.com.au/2009/03/problem-with-integer-division.html
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.
If you reject C integer division, you have to do *something* with 1/2.
Ideally you'll get a number numerically equal to one half. It can't be a
Decimal, or a Fraction, because back in 2001 there were no Decimal or
Fraction types, and even now in 2014 they aren't built-ins.
(Besides, both of those choices have other disadvantages. Fractions are
potentially slow and painful, with excessive accuracy. See Guido's
comments in his blog post above. And Decimal uses base 10 floating point,
which is less suitable for serious numeric work than base 2 floats.)
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?
That's a bit of a contrived example. But go on.
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.
Only since, um, version 2.2 I think. I don't have 2.1 easily available,
but here's 1.5:
[steve@ando ~]$ python1.5
Python 1.5.2 (#1, Aug 27 2012, 09:09:18) [GCC 4.1.2 20080704 (Red Hat
4.1.2-52)] on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
2**31*10
Traceback (innermost last):
File stdin, line 1, in ?
OverflowError: integer pow()
So don't forget the historical context of what you are discussing.
In Python 2, doing the obvious thing works:
x * 10 / 5 == x * 2
Ignoring old versions of Python 2.x, correct. But that is a contrived
example. Mathematically x/5*10 also equals 2*x, but not with C division
semantics. This is with Python 2.7:
x = 7
x/5*10, x*10/5, x*2
(10, 14, 14)
Let's try it with true (calculator) division:
x/5*10, x*10/5, x*2
(14.0, 14.0, 14)
With a bit of effort, I'm sure you can find values of x where they are
not all equal, but that's because floats only have a finite precision. In
general, true division is less surprising and causes fewer unexpected
truncation errors.
In Python 3, you have to say Oh but I want my integer division to
result in an integer:
x * 10 // 5 == x * 2
No, // doesn't mean divide and coerce to an integer, it is
*truncating* division. The type being truncated may choose to return
an int, but that's not compulsory:
from decimal import Decimal as D
x = D(23.5)
x/4, x//4
(Decimal('5.875'), Decimal('5'))
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)
It doesn't round, it truncates.
[steve@ando ~]$ python2.7 -c print round(799.0/100)
8.0
[steve@ando ~]$ python2.7 -c print 799/100
7
for another set (floating
point arithmetic isn't real number arithmetic)?
It's not like that avoiding that problem is an option.
--
Steven D'Aprano
http://import-that.dreamwidth.org/
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 3?
On 2014-04-20 09:43, Steven D'Aprano wrote: So really the advice comes down to: - if you can, use the latest version of Python, which is 3.4; - if you must, use the version of Python provided by your operating system, which could be anything from Python 2.3 to 3.3; - if you have no choice except to use a library that only supports version X, then use version X, no matter what X happens to be. None of this should be controversial. It should be common sense. This. Except for the fact that what should be common sense often ends up being controversial on c.l.p ;-) -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: Integer and float division [was Re: Why Python 3?]
Steven D'Aprano writes: It doesn't round, it truncates. [steve@ando ~]$ python2.7 -c print round(799.0/100) 8.0 [steve@ando ~]$ python2.7 -c print 799/100 7 Seems it floors rather than truncates: $ python2.7 -c from math import trunc;print trunc(799./-100) -7 $ python2.7 -c from math import floor;print floor(799./-100) -8.0 $ python2.7 -c print 799/-100 -8 $ python3.2 -c print(799//-100) -8 -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 3?
On 04/20/2014 02:47 AM, Ian Foote wrote: 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. I don't know if you'd count it as an Enterprise distribution, but ubuntu 14.04 (LTS) ships with python 3.4 (and 2.7). And I hope RHEL 7 will also ship Python 3.3 or 3.4 when it's finished. Of course if it does, it will be stuck with that version for the next 5-10 years. But that's the nature of software in this space. I say this as I work on a server that's running RHEL 5 still. :) -- https://mail.python.org/mailman/listinfo/python-list
Re: Integer and float division [was Re: Why Python 3?]
On Sun, 20 Apr 2014 15:38:03 +0300, Jussi Piitulainen wrote: Steven D'Aprano writes: It doesn't round, it truncates. [steve@ando ~]$ python2.7 -c print round(799.0/100) 8.0 [steve@ando ~]$ python2.7 -c print 799/100 7 Seems it floors rather than truncates: $ python2.7 -c from math import trunc;print trunc(799./-100) -7 $ python2.7 -c from math import floor;print floor(799./-100) -8.0 $ python2.7 -c print 799/-100 -8 $ python3.2 -c print(799//-100) -8 Ah yes, so it does. Sorry for the confusion. This has been reported as a bug at least twice, but it is actually working as intended. // floors, not truncates towards zero. http://bugs.python.org/issue19446 http://bugs.python.org/issue19574 -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 3?
On Apr 19, 2014 2:54 PM, Chris Angelico ros...@gmail.com wrote: On Sun, Apr 20, 2014 at 6:38 AM, Ian Kelly ian.g.ke...@gmail.com 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: When I'm writing a generic average function, I probably don't know whether it will ever be used to average complex numbers. That shouldn't matter, because I should be able to rely on this code working for whatever numeric type I pass in: def average(values): return sum(values) / len(values) This works for decimals, it works for fractions, it works for complex numbers, it works for numpy types, and in Python 3 it works for ints. 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. First, that's not equivalent. Try the following in Python 3: values = [int(sys.float_info.max / 10)] * 20 print(average(values)) Now try this: print(average(map(float, values))) I don't have an interpreter handy to test, but I expect the former to produce the correct result and the latter to raise OverflowError on the call to sum. Second, why should the calling code have to worry about this implementation detail anyway? The point of a generic function is that it's generic. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 3?
On 2014-04-20 17:22, Ian Kelly wrote: On Apr 19, 2014 2:54 PM, Chris Angelico ros...@gmail.com mailto:ros...@gmail.com wrote: On Sun, Apr 20, 2014 at 6:38 AM, Ian Kelly ian.g.ke...@gmail.com mailto:ian.g.ke...@gmail.com 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: When I'm writing a generic average function, I probably don't know whether it will ever be used to average complex numbers. That shouldn't matter, because I should be able to rely on this code working for whatever numeric type I pass in: def average(values): return sum(values) / len(values) This works for decimals, it works for fractions, it works for complex numbers, it works for numpy types, and in Python 3 it works for ints. 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. First, that's not equivalent. Try the following in Python 3: values = [int(sys.float_info.max / 10)] * 20 print(average(values)) Now try this: print(average(map(float, values))) I don't have an interpreter handy to test, but I expect the former to produce the correct result and the latter to raise OverflowError on the call to sum. Python 3.4.0 (v3.4.0:04f714765c13, Mar 16 2014, 19:25:23) [MSC v.1600 64 bit (AMD64)] on win32 Type help, copyright, credits or license for more information. import sys def average(values): ... return sum(values) / len(values) ... values = [int(sys.float_info.max / 10)] * 20 print(average(values)) 1.7976931348623158e+307 print(average(map(float, values))) Traceback (most recent call last): File stdin, line 1, in module File stdin, line 2, in average TypeError: object of type 'map' has no len() print(average(list(map(float, values inf In fact, that's true back to Python 3.1 Second, why should the calling code have to worry about this implementation detail anyway? The point of a generic function is that it's generic. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 3?
On Mon, Apr 21, 2014 at 2:22 AM, Ian Kelly ian.g.ke...@gmail.com wrote: When I'm writing a generic average function, I probably don't know whether it will ever be used to average complex numbers. This keeps coming up in these discussions. How often do you really write a function that generic? And if you do, isn't it doing something so simple that it's then the caller's responsibility (not the function's, and not the language's) to ensure that it gets the right result? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 3?
On Saturday, April 19, 2014 12:50:09 PM UTC+8, Ethan Furman wrote: On 04/18/2014 08:28 PM, 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? This community is also split. ;) Use Python 3 if you can. The best reason not to is if you have some critical library that you absolutely need and it's not yet available on 3. In which case, program as if your code base was going to run on both 2 and 3 so you can update easily once your dependency upgrades. -- ~Ethan~ OK, I'll suggest to use Python 2.7X with pytoexe buldled as an executable to be called by the shell from Python 3.X for programs that need to mix Python 2.X and Python 3.X together. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 3?
Michael Torrie schrieb: 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, python2.7 and python3.3 are availabe in RedHat Software Collections: https://access.redhat.com/site/documentation/en-US/Red_Hat_Software_Collections/1/html/1.0_Release_Notes/chap-RHSCL.html http://developerblog.redhat.com/2014/02/18/migrate-to-python3-w-rhscl/ So there is at least a chance if you want to (or have to) use official packages from the distributor. Regards, Bernd -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 3?
On 04/20/2014 12:02 PM, Bernd Waterkamp wrote: Michael Torrie schrieb: 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, python2.7 and python3.3 are availabe in RedHat Software Collections: https://access.redhat.com/site/documentation/en-US/Red_Hat_Software_Collections/1/html/1.0_Release_Notes/chap-RHSCL.html http://developerblog.redhat.com/2014/02/18/migrate-to-python3-w-rhscl/ So there is at least a chance if you want to (or have to) use official packages from the distributor. Brilliant! Thanks. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 3?
In article mailman.9383.1398012417.18130.python-l...@python.org, Chris Angelico ros...@gmail.com wrote: On Mon, Apr 21, 2014 at 2:22 AM, Ian Kelly ian.g.ke...@gmail.com wrote: When I'm writing a generic average function, I probably don't know whether it will ever be used to average complex numbers. This keeps coming up in these discussions. How often do you really write a function that generic? And if you do, isn't it doing something so simple that it's then the caller's responsibility (not the function's, and not the language's) to ensure that it gets the right result? ChrisA Hmmm. Taking the average of a set of complex numbers has a reasonable physical meaning. But, once you start down that path, I'm not sure how far you can go before things no long make sense. What's the standard deviation of a set of complex numbers? Does that even have any meaning? -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 3?
On 4/20/2014 5:40 PM, Roy Smith wrote: In article mailman.9383.1398012417.18130.python-l...@python.org, Chris Angelico ros...@gmail.com wrote: On Mon, Apr 21, 2014 at 2:22 AM, Ian Kelly ian.g.ke...@gmail.com wrote: When I'm writing a generic average function, I probably don't know whether it will ever be used to average complex numbers. This keeps coming up in these discussions. How often do you really write a function that generic? And if you do, isn't it doing something so simple that it's then the caller's responsibility (not the function's, and not the language's) to ensure that it gets the right result? ChrisA Hmmm. Taking the average of a set of complex numbers has a reasonable physical meaning. But, once you start down that path, I'm not sure how far you can go before things no long make sense. What's the standard deviation of a set of complex numbers? Does that even have any meaning? One can either calculate variance from the sum of squared distances from the mean point, or calculate x and y deviations separately and calculate the covariance matrix thereof. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 3?
On 4/20/14, 5:40 PM, Roy Smith wrote: In article mailman.9383.1398012417.18130.python-l...@python.org, Chris Angelico ros...@gmail.com wrote: On Mon, Apr 21, 2014 at 2:22 AM, Ian Kelly ian.g.ke...@gmail.com wrote: When I'm writing a generic average function, I probably don't know whether it will ever be used to average complex numbers. This keeps coming up in these discussions. How often do you really write a function that generic? And if you do, isn't it doing something so simple that it's then the caller's responsibility (not the function's, and not the language's) to ensure that it gets the right result? ChrisA Hmmm. Taking the average of a set of complex numbers has a reasonable physical meaning. But, once you start down that path, I'm not sure how far you can go before things no long make sense. What's the standard deviation of a set of complex numbers? Does that even have any meaning? If you thing of the Standard Deviation being the Root Mean Norm2 of the deviations, it has a very similar meaning as to over the reals, a measure of the spread of the values. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 3?
Chris Angelico wrote: 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. If you know you're dealing with either ints or floats, which is true in the vast majority of cases, then you know that / will always perform float division. As for why int/int should yield float and not some other type, float is alreay special -- it's built-in and has syntactic support in the form of literals. It's the most obvious choice. If a version of Python were ever to exist in which floating-point literals produced Decimals instead of floats, then int/int would produce a Decimal. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 3?
Terry Reedy wrote: On 4/19/2014 9:06 PM, Gregory Ewing wrote: Similarly, when you write // you're explicitly requesting integer division. One is requesting 'floor division' 3.0//2.0 1.0 In general that's true, but I'm talking about a context in which you have some expectations as to the types of the operands. Most of the time, there are two possible scenarios: 1) The algorithm operates on integers, and the contract is that you only get passed ints. In that case, you use // and know that the result will be an int. 2) The algorithm operates on non-integers, and the contract is that you get passed either ints or floats, with ints being understood as standing in for floats. In that case, you use / and know that it will perform float division and return a float. If someone passes you a float in case (1) it's true that // won't return an int, but then they've violated the contract. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 3?
On Mon, Apr 21, 2014 at 8:52 AM, Gregory Ewing greg.ew...@canterbury.ac.nz wrote: Chris Angelico wrote: 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. If you know you're dealing with either ints or floats, which is true in the vast majority of cases, then you know that / will always perform float division. And that's what I mean about the common non-trivial case. It's easy enough to come up with contrived or trivial cases that use any types, but in most cases, it'd be fine to explicitly call float() on one of the operands to explicitly request floating-point division. Choosing between two division operators is not the same thing as choosing a data type. Explicitly choosing float division: x / float(y) Explicitly choosing to truncate: math.trunc(x / y) Both explicit forms can be done cleanly without empowering the language with the magic of int/int-float. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Integer and float division [was Re: Why Python 3?]
On Sat, 19 Apr 2014 19:37:31 +1000, Chris Angelico wrote: In Python 3, you have to say Oh but I want my integer division to result in an integer: I don't see why that's such a big hardship. There are clear advantages to having an explicit way to request non-floor division. Whatever way is chosen for that, some other way has to be chosen to request floor division. One could debate whether it would have been better to make / mean floor division and invent something else for non-floor division, but then some people would complain Oh, but I have to say I want my float division to return a float! Either way requires people to make some changes in their habits. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 3?
On Sat, 19 Apr 2014 20:25:32 -0700, Paul Rubin wrote: Terry Reedy tjre...@udel.edu 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. I would use Python 3 in a flash if only wxPython would support it. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 3?
Ian Kelly wrote: def average(values): return sum(values) / len(values) This works for decimals, it works for fractions, it works for complex numbers, it works for numpy types, and in Python 3 it works for ints. That depends on what you mean by works. I would actually find it rather disturbing if an average() function implicitly used floor division when given all ints. The reason is that people often use ints as stand-ins for floats in computations that are conceptually non-integer. So a general-purpose function like average(), given a list of ints, has no way of knowing whether they're intended to be interpreted as ints or floats. To my way of thinking, floor division is a specialised operation that is only wanted in particular circumstances. It's rare that I would actually want it done in the context of taking an average, and if I do, I would rather be explicit about it using e.g. int(floor(average(...)) or a specialised int_average() function. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 3?
On Mon, Apr 21, 2014 at 9:50 AM, Walter Hurry walterhu...@lavabit.com wrote: I would use Python 3 in a flash if only wxPython would support it. There seems to be a Project Phoenix (found it at the other end of a Google search) with that goal. I've no idea what its status is, but you could help that project along by expressing interest and maybe helping with their bug tracker, or hosting a buildbot (they seem to use the same buildbot software that Python uses), or something like that. If you're really serious about wanting Python 3 support, go the whole way and actually help to port it! ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 3?
On 4/20/2014 7:13 PM, Gregory Ewing wrote: Terry Reedy wrote: On 4/19/2014 9:06 PM, Gregory Ewing wrote: Similarly, when you write // you're explicitly requesting integer division. One is requesting 'floor division' 3.0//2.0 1.0 The name 'floor division' and the float result are intentional, not accidents. In general that's true, but I'm talking about a context in which you have some expectations as to the types of the operands. Most of the time, there are two possible scenarios: 1) The algorithm operates on integers, and the contract is that you only get passed ints. In that case, you use // and know that the result will be an int. 2) The algorithm operates on non-integers, and the contract is that you get passed either ints or floats, with ints being understood as standing in for floats. In that case, you use / and know that it will perform float division and return a float. If someone passes you a float in case (1) it's true that // won't return an int, but then they've violated the contract. Not necessarily if the float has an integer value. The intention of the change was to make the value of number operations less dependent on the type of the operands. Where the result type does matter is if the result is used, for example, in indexing -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 3?
On 21/04/2014 00:50, Walter Hurry wrote: On Sat, 19 Apr 2014 20:25:32 -0700, Paul Rubin wrote: Terry Reedy tjre...@udel.edu 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. I would use Python 3 in a flash if only wxPython would support it. It's getting there with the Phoenix project. Snapshots available here http://wxpython.org/Phoenix/snapshot-builds/ -- 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?
Richard Damon wrote: If you thing of the Standard Deviation being the Root Mean Norm2 of the deviations, it has a very similar meaning as to over the reals, a measure of the spread of the values. NumPy appears to handle this: http://docs.scipy.org/doc/numpy/reference/generated/numpy.std.html See the comment on that page about complex numbers. So yes, it is meaningful and apparently people use it. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 3?
On Apr 20, 2014 8:01 PM, Gregory Ewing greg.ew...@canterbury.ac.nz wrote: Ian Kelly wrote: def average(values): return sum(values) / len(values) This works for decimals, it works for fractions, it works for complex numbers, it works for numpy types, and in Python 3 it works for ints. That depends on what you mean by works. I would actually find it rather disturbing if an average() function implicitly used floor division when given all ints. The code above never uses floor division in Python 3. Therefore it works. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 3?
On Sun, 20 Apr 2014 14:40:38 -0700, Roy Smith wrote: In article mailman.9383.1398012417.18130.python-l...@python.org, Chris Angelico ros...@gmail.com wrote: On Mon, Apr 21, 2014 at 2:22 AM, Ian Kelly ian.g.ke...@gmail.com wrote: When I'm writing a generic average function, I probably don't know whether it will ever be used to average complex numbers. This keeps coming up in these discussions. How often do you really write a function that generic? And if you do, isn't it doing something so simple that it's then the caller's responsibility (not the function's, and not the language's) to ensure that it gets the right result? ChrisA Hmmm. Taking the average of a set of complex numbers has a reasonable physical meaning. But, once you start down that path, I'm not sure how far you can go before things no long make sense. What's the standard deviation of a set of complex numbers? Does that even have any meaning? Yes it does. Stdev is a measure of scale of the distribution, and is always real and non-negative. For complex values, you can calculate it using: (abs(x - mean))**2 which is how numpy does it, or from the complex conjugate: x1 = x-mean x1.conj()*x1 which is how Matlab does it. http://docs.scipy.org/doc/numpy/reference/generated/numpy.std.html http://www.mathworks.com.au/matlabcentral/newsreader/view_thread/57323 Hence the variance is always non-negative, and the standard deviation is always real. See also: https://en.wikipedia.org/wiki/Variance#Generalizations -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 3?
On Mon, 21 Apr 2014 09:24:09 +1000, Chris Angelico wrote: On Mon, Apr 21, 2014 at 8:52 AM, Gregory Ewing greg.ew...@canterbury.ac.nz wrote: Chris Angelico wrote: 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. If you know you're dealing with either ints or floats, which is true in the vast majority of cases, then you know that / will always perform float division. And that's what I mean about the common non-trivial case. It's easy enough to come up with contrived or trivial cases that use any types, but in most cases, it'd be fine to explicitly call float() on one of the operands to explicitly request floating-point division. Choosing between two division operators is not the same thing as choosing a data type. Nobody says that they are. Choosing between / and // means to choose between two different operator. / performs true division, the sort that you learn about in school (modulo the usual floating point issues -- floats are not mathematical reals). // performs division which floors towards negative infinity. (For positive values, that's equivalent to truncation.) Hence the two special methods: __truediv__ and __floordiv__ (plus the reversed __r*__ versions). I think you need to stop thinking about integer division, because (1) integer division is not well-defined, and (2) in the general case, // doesn't return an int, although it should return a value that is integer valued. Why is integer division not well-defined? Because division of integers doesn't necessarily return an integer: the integers are not closed with the division operator. Cases like 10/5 are easy, that's just 2. What about 11/5 or -7/3? I can think of at least six things that integer division might do in those cases: - round to nearest, ties round to even (banker's rounding); - round to nearest, ties round to odd; - round towards positive infinity (ceiling); - round towards negative infinity (floor); - round towards zero (truncate); - raise an exception; so before talking about integer division we have to decide which of those apply. Python doesn't talk about integer division, well not officially, but talks about *floor division*. The nice thing about this is that there's no requirement that it return an actual int: py 11.0//2 5.0 just an integer-valued value. It's up to the class to decide how it works. Explicitly choosing float division: x / float(y) But here you're not choosing an *operator*, you're choosing a *type*. With this model, how do I distinguish between floor division and true division using, say, Fractions? py from fractions import Fraction as F py F(1799, 27)/F(3) # True division. Fraction(1799, 81) py F(1799, 27)//F(3) # Floor division. 22 Converting to floats is not an option, since (1) it returns a float, not a Fraction, and (2) it introduces rounding errors: py F(1799, 27)/F(3) == F(1799, 27)/3.0 False [...] Both explicit forms can be done cleanly without empowering the language with the magic of int/int-float. It's hardly magic, and I really am having difficult in working out exactly what your objection to it is. Is it really as simple as operations on ints should only return ints, like in C? -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 3?
On Mon, 21 Apr 2014 10:00:01 +1000, Chris Angelico wrote: On Mon, Apr 21, 2014 at 9:50 AM, Walter Hurry walterhu...@lavabit.com wrote: I would use Python 3 in a flash if only wxPython would support it. There seems to be a Project Phoenix (found it at the other end of a Google search) with that goal. I've no idea what its status is, but you could help that project along by expressing interest and maybe helping with their bug tracker, or hosting a buildbot (they seem to use the same buildbot software that Python uses), or something like that. If you're really serious about wanting Python 3 support, go the whole way and actually help to port it! Yes, I'm keeping an eye on Fawkes*. Alas, my skillset is not up to your other suggestions, but thanks. * http://harrypotter.wikia.com/wiki/Fawkes -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 3?
On Mon, Apr 21, 2014 at 1:43 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Explicitly choosing float division: x / float(y) But here you're not choosing an *operator*, you're choosing a *type*. With this model, how do I distinguish between floor division and true division using, say, Fractions? Earlier it was said that having both / and // lets you explicitly choose whether you want a float result or an int by picking an operator. I'm saying that's not so; the operator and the type aren't quite orthogonal, but close to. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 3?
On Mon, Apr 21, 2014 at 1:43 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Both explicit forms can be done cleanly without empowering the language with the magic of int/int-float. It's hardly magic, and I really am having difficult in working out exactly what your objection to it is. Is it really as simple as operations on ints should only return ints, like in C? All other basic arithmetic operations on two numbers of the same type results in another number of that type. You wouldn't expect the product of two Fractions to be a Decimal, nor the sum of two complex numbers be a float (even if it results in an imaginary part of zero, it'll still be a complex: (1+2j) + (2-2j) -- (3+0j) not 3.0). There's just one special case: dividing an integer by an integer yields a float, if and only if you use truediv. It sticks out as an exception. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 3?
Anthony Papillion papill...@gmail.com writes: 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'. Python 3 is generally better than Python 2, except for a few packages that haven't been ported. That said, I don't know anyone who actually uses Python 3. I don't think it's a matter of wanting to use some problematic package, or having particular technical concerns. It's just that the improvement from 2 to 3 is rather small, and 2 works perfectly well and people are used to it, so they keep using it. There are nice tools that help port your codebase from 2 to 3 with fairly little effort. But, you can also keep your codebase on 2 with zero effort. So people choose zero over fairly little. 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. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 3?
On Sat, Apr 19, 2014 at 4:40 PM, Paul Rubin no.email@nospam.invalid 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?
On Sat, Apr 19, 2014 at 1:34 AM, Chris Angelico ros...@gmail.com 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?
On Sat, Apr 19, 2014 at 7:25 PM, Ian Kelly ian.g.ke...@gmail.com 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?
Ian Kelly ian.g.ke...@gmail.com: On Sat, Apr 19, 2014 at 1:34 AM, Chris Angelico ros...@gmail.com 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?
Anthony Papillion papill...@gmail.com 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 URL:https://docs.python.org/3/whatsnew/ many other benefits. See URL: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?
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?
On Fri, 18 Apr 2014 22:28:05 -0500, Anthony Papillion papill...@gmail.com 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: Why Python 3?
On Sat, Apr 19, 2014 at 9:53 PM, Steve Hayes hayes...@telkomsa.net 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?
-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?
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?
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?
Chris Angelico ros...@gmail.com 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?
On Sat, Apr 19, 2014 at 11:26 PM, Roy Smith r...@panix.com wrote: Chris Angelico ros...@gmail.com 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: Why Python 3?
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: Why Python 3?
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?
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?
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?
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?
On Sun, Apr 20, 2014 at 3:23 AM, Terry Reedy tjre...@udel.edu 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?
- Original Message - From: Chris Angelico ros...@gmail.com To: Cc: python-list@python.org python-list@python.org Sent: Saturday, April 19, 2014 3:42 PM Subject: Re: Why Python 3? snip 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?
On Sat, Apr 19, 2014 at 3:37 AM, Chris Angelico ros...@gmail.com wrote:
On Sat, Apr 19, 2014 at 7:25 PM, Ian Kelly ian.g.ke...@gmail.com 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?
On Sun, Apr 20, 2014 at 5:58 AM, Ian Kelly ian.g.ke...@gmail.com 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?
On Sat, Apr 19, 2014 at 2:31 PM, Chris Angelico ros...@gmail.com wrote: On Sun, Apr 20, 2014 at 5:58 AM, Ian Kelly ian.g.ke...@gmail.com 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?
On Sun, Apr 20, 2014 at 6:38 AM, Ian Kelly ian.g.ke...@gmail.com 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 pyshell#19, line 1, in module 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 pyshell#25, line 1, in module 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?
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?
On Sun, Apr 20, 2014 at 11:06 AM, Gregory Ewing greg.ew...@canterbury.ac.nz 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?
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?
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?
Terry Reedy tjre...@udel.edu 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?
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
Why Python 3?
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? Thanks, Anthony -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 3?
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. On Fri, Apr 18, 2014 at 10:28 PM, Anthony Papillion papill...@gmail.comwrote: 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? Thanks, Anthony -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 3?
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. Python 2 still exists because there are very large existing projects (some public, some private) that are not able to use Python 3 for some reason (like heavy dependence on a third-party that doesn't support Python 3). If you are developing a new library, the decision is not likely going to be easy, but in general, I'd say the larger it is, the more you should lean toward not having Python 2 support. Of course, there are going to be other factors such as your audience and what, if any, third-party libraries you will need yourself. It's an awkward time to write a new library since supporting both 2 and 3 is a major pain, and Python 2 is eventually going away, but you will still have a significant amount of people who will want to use the library with things that can't support Python 3. Use Python 2 if you must, but know that you will end up needing to migrate to Python 3 eventually. It used to be that support for Python 3 among third-party libraries was small, but that is no longer true: http://python3wos.appspot.com/ -- CPython 3.4.0 | Windows NT 6.2.9200 / FreeBSD 10.0 -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 3?
On 04/18/2014 08:28 PM, 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? This community is also split. ;) Use Python 3 if you can. The best reason not to is if you have some critical library that you absolutely need and it's not yet available on 3. In which case, program as if your code base was going to run on both 2 and 3 so you can update easily once your dependency upgrades. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 3?
On 2007-12-05, Chris Gonnerman [EMAIL PROTECTED] wrote: I spent some time today reading about Python 3, and specifically the differences between Python 3 and Python 2, and I was left with a question... why? Why bother to change to Python 3, when the CPython implementation is slower, and probably will be for a while? I think to preserve the smoothness of switching versions, like you do now. As user, you can smoothly 'upgrade' to using new Python features in the pace that you like. Unfortunately for the developers, not all users do that at the same rate and switch to the same sub-set (and that is good, I think). As a result, the developers have to be very backwards compatible. In other words, you can probably run a lot of the Python 1.5.2 code you wrote several years ago using today's Python 2.5. To make that possible, all 1.5.2 stuff is still in today's Python 2.5 interpreter, even though there are not many users that code in 1.5.2 style any more. As you can imagine, this old stuff piles up as we progress in Python versions. Python 3 is the breaking point where the old stuff (that (almost) nobody uses any more, since everybody is using new coding styles) is really gone. That gives room for a new design of the interpreter from the ground up, using today's coding practices and ideas as starting point. For you as user, the transition to Python 3 will probably be smooth too. Unless you stopped reading about new Python versions after 1.5.2, and are still using that old 1.5.2 book as ultimate Python reference, your coding style has changed too towards newer Python versions (and ultimately towards Python 3). In addition, knowing the Python development cycle, as the features of Python 3 become more clear, they will first be implemented in the Python 2.x range for testing and for giving users the chance to already pick up the new coding styles, so by the time the last 2.x version is retired, Python 3 will have (almost) no sudden transitions for you. But... almost all of my old 1.5 code ported painlessly to 2.x. No need for a 1.5to2 script, whereas I see that there is a 2to3 script for Well, Python 3 design is from the ground up, and aimed at the future, so they are quite a few steps ahead of today's coding practice, let alone today's code base (which is still 1.5 compatible as you discovered). To run any form of practical experiments, one needs a way to quickly convert the current code to the new conventions/ideas. Since programmers rather let the computer do boring repetitive tasks, they write a script for the conversions. Since Python is open source, you may also want to experiment with Python 3, and in that case the script is very handy. Imho, existence of such a script today does not automatically mean that you will need to use a script at the moment you (or I) switch to Python 3. programming knowledge. In fact, the things I rarely or never use in Python tend to be those things I find hardest to read (like list comprehensions). Few of the changes along the way have required me to I use them a lot, and they are very powerful. On the other hand, I never use generators, which is probably a loss for me. change how I *write* code; probably the worst was the integer division I think you change the way you write code continuously. I have been programming computers for 20+ years, and are still changing the way I code. change, which I disagreed with, but I went along with the community. Some changes are for your own good, even though you do not realize it now :) For you it is the integer division. For me, I have a problem with new-style classes, where the __eq__ method is already implemented, blurring the difference between 'is' and '=='. Ah well, no language is perfect, and there is probably a very good reason for the change even if I don't see it. (and if there is really none, the change will be undone with Python 4... :) ) I don't see myself using Python 3 for a long time. Probably as long as I can hold out. Where are my goodies? What is my payoff for learning how to write code the new way? I can't see it. Many things seem a lot A lot of the new goodies give you more punch per line, ie less lines to express what you want to calculate. This is good, since the chance making an error is a constant per line, so less lines is less errors. less obvious... like, what was wrong with dict.keys() returning a list? Now it returns some strange object type. In addition, Python is generalizing programming. Why would you want to write a for-loop yourself if you can push the loop into that strange object type? This may look useless, but what actually happens here is that the level of abstraction in programming is raised further (just like the main benefit of switching from eg C to Python is the step up in abstraction (you get eg dictionaries and lists built in, rather than having to program them yourself from struct's for the umpteenth time). Ultimately, when you start
Re: Why Python 3?
A.T.Hofkamp wrote: Well, Python 3 design is from the ground up, and aimed at the future, so they are quite a few steps ahead of today's coding practice, let alone today's code base (which is still 1.5 compatible as you discovered). Just a small note from me: Several people think that we are rewriting Python 3.0 from the scratch. That is *not* correct. The 3.x series shares lots of code with the 2.x series. We are still merging changes from the trunk (2.6) into the py3k branch and we are going to backport several features from 3.0 into 2.6. Some parts are of Python 3.0 are new and the majority of the rest is just cleaned up a bit. Some new features like the new immutable bytes type in 3.0a2 are mostly based on existing code. At http://www.joelonsoftware.com/articles/fog69.html Joel explains why rewriting from the scratch is often the worst strategy. Christian -- http://mail.python.org/mailman/listinfo/python-list
Re: Why Python 3?
On 5 Dez., 15:32, Christian Heimes [EMAIL PROTECTED] wrote: Athttp://www.joelonsoftware.com/articles/fog69.htmlJoel explains why rewriting from the scratch is often the worst strategy. About migration strategies: I do not exactly recollect whether it was in Eastland or Jugemanland, but I remember that in the midst of a dreary forest I spied a terrible wolf making after me, with all the speed of ravenous winter hunger. He soon overtook me. There was no possibility of escape. Mechanically I laid myself down flat in the sledge, and let my horse run for our safety. What I wished, but hardly hoped or expected, happened immediately after. The wolf did not mind me in the least, but took a leap over me, and falling furiously on the horse, began instantly to tear and devour the hind-part of the poor animal, which ran the faster for his pain and terror. Thus unnoticed and safe myself, I lifted my head slyly up, and with horror I beheld that the wolf had ate his way into the horse's body; it was not long before he had fairly forced himself into it, when I took my advantage, and fell upon him with the butt-end of my whip. This unexpected attack in his rear frightened him so much, that he leaped forward with all his might: the horse's carcase dropped on the ground, but in his place the wolf was in the harness, and I on my part whipping him continually: we both arrived in full career safe at St. Petersburg, contrary to our respective expectations, and very much to the astonishment of the spectators. http://bulfinch.englishatheist.org/baron/Baron.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Why Python 3?
Kay Schluehr wrote: This unexpected attack in his rear frightened him so much, that he leaped forward with all his might: the horse's carcase dropped on the ground, but in his place the wolf was in the harness, and I on my part whipping him continually: we both arrived in full career safe at St. Petersburg, contrary to our respective expectations, and very much to the astonishment of the spectators. http://bulfinch.englishatheist.org/baron/Baron.html in order, I presume, to counterpoint the surrealism of the underlying metaphor http://flag.blackened.net/dinsdale/dna/book1.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Why Python 3?
Chris Gonnerman [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] |I spent some time today reading about Python 3, and specifically the | differences between Python 3 and Python 2, and I was left with a | question... why? Overall, to delete accumulated stuff, much of which would have been deleted already if not for the prospect of Python3 and the decision to put off deletions until then. | Why bother to change to Python 3, when the CPython | implementation is slower, and probably will be for a while? Guido's philosophy is to get it right first and then speed it up. I would not judge the future 3.0 final by the current alpha1. | But... almost all of my old 1.5 code ported painlessly to 2.x. | No need for a 1.5to2 script, That is because deletion of obsolete features has been put off until 3.0 instead of being done release by release, as was the policy once, until people persuaded Guido to bunch up code-breaking changes. Also, 2.0 would have been 1.6.1 or 1.7 but for legal and political reasons related to the change of venue. Similarly, 2.1 would have been 1.7 or 1.8. 2.2, with iterators and new-style classes should have been 2.0. That was the real break. But old-style classes were kept for the 2.x series even though they make learning, maintenance, and upgrades a bit harder. | whereas I see that there is a 2to3 script for converting modules. If stuff were deleted (or incompatibly changed) every release, people would want a converter script for every release. I believe the idea may have arisen in the discussion of redefining int/int. Changing that from 'future' to 'present' has been put off much longer than originally planned. | Python 1.5 and 2.x are executable pseudocode, | something that can be easily read by anyone with a modicum of | programming knowledge. The subset of 3.0 that is basically the same as 1.4, the version for which I coined that phrase, still should be. | In fact, the things I rarely or never use in | Python tend to be those things I find hardest to read (like list | comprehensions). Yes, I have thought about whether I should use l.c.s in didactic programs primarily meant for human readers who are not necessarily Python programmers. | Few of the changes along the way have required me to | change how I *write* code; Because most code-breaking changes that would have required you to change have been put off to 3.0. | probably the worst was the integer division | change, which I disagreed with, but I went along with the community. But that change has not happened yet (without a future import) -- because it was put off to 3.0. Learning Python today would be easier if int/int did *not* still have two possible meanings, and it will be easier when the change is complete. I see four possible policies with respect to replacing features with intended improvements. A. Never do it, so there is never a reason to delete anything. B. Add new versions of a feature but keep the old version also forever. C Add new versions and delete the old soon after. D. Add new versions but delete the old in a bunch after several additions. Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Why Python 3?
I spent some time today reading about Python 3, and specifically the differences between Python 3 and Python 2, and I was left with a question... why? Why bother to change to Python 3, when the CPython implementation is slower, and probably will be for a while? When I learned Python, 1.5 was the current version. Each new version from 2.0 on brought goodies to the table... I think I have made use of about half of the advancements that have come along since. But I was swayed into taking Python seriously by Eric Raymond's article in Linux Journal, where he talked about how much easier it was to read his old code in Python than in Perl, and how the whole white space thing wasn't so bad. I discovered I agreed with him. Python has been my favorite language ever since. But... almost all of my old 1.5 code ported painlessly to 2.x. No need for a 1.5to2 script, whereas I see that there is a 2to3 script for converting modules. Python 1.5 and 2.x are executable pseudocode, something that can be easily read by anyone with a modicum of programming knowledge. In fact, the things I rarely or never use in Python tend to be those things I find hardest to read (like list comprehensions). Few of the changes along the way have required me to change how I *write* code; probably the worst was the integer division change, which I disagreed with, but I went along with the community. I don't see myself using Python 3 for a long time. Probably as long as I can hold out. Where are my goodies? What is my payoff for learning how to write code the new way? I can't see it. Many things seem a lot less obvious... like, what was wrong with dict.keys() returning a list? Now it returns some strange object type. I don't think I can surely be the only one. Certainly, I'm nobody important; it's not as if my opinion has any real bearing on the situation. I suspect that many Python coders will stay with 2.x; after all, this is Open Source... there is no Micro$oft forcing us to upgrade to get more licenses. If enough people stay with 2.x... will the project fork? Will there be enough of us to maintain Python 2 indefinitely? Will module maintainers have to choose which version of Python to support? It's already a pain for me to keep the GDmodule up with the current Python release... and it's a pretty small module. I just don't see the point. I feel like we already have all we need in Python 2. I feel like the language is becoming less and less friendly and readable as it evolves. Just my two cents, I guess. -- Chris Gonnerman -- http://mail.python.org/mailman/listinfo/python-list
Re: Why Python 3?
On Dec 4, 11:39 pm, Chris Gonnerman I don't think I can surely be the only one. Certainly, I'm nobody important; it's not as if my opinion has any real bearing on the situation. I suspect that many Python coders will stay with 2.x; after all, this is Open Source... there is no Micro$oft forcing us to upgrade to get more licenses. If enough people stay with 2.x... will the project fork? There's no need to get that concerned; Python 2.x will exist and be maintained alongside Python 3.x for quite a while, probably 10 years. FWIW: I think the Python 3 effort has done well to keep things from getting out of hand; I expect transitions to be mostly smooth. Probably the trickiest aspect of transition will be getting Unicode and byte strings straight. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
