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 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
> 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 "", 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
ctypes: returning an array from a subroutine
I have a C code function like this:
++
int __declspec(dllexport) __stdcall bnd2prb(float *in, float *out, int init)
{enum {OK, Error, Not_Valid};
...
return(OK):
}
++
And in Python I am trying to call this C function:
++
import ctypes
import struct
import array
_snns =
ctypes.windll.LoadLibrary(r'C:\MSDEV\Projects\Cyctrac\Debug\Cyctrac.dll')
_cosm = getattr(_snns, '_bnd2prb@12')
_cosm.argtypes = (ctypes.POINTER(ctypes.c_float),
ctypes.POINTER(ctypes.c_float),
ctypes.c_long)
_cosm.restype = ctypes.c_float
def snns(indata, outdat):
"""Calls the neural net, returns a vector of 4.
"""
global _cosm
init = ctypes.c_long(0)
ilen = len(indata)
olen = len(outdat)
itype = ctypes.c_float * ilen
otype = ctypes.c_float * olen
iok = _cosm(itype(*indata), ctypes.pointer(otype(*outdat)), init)
if not iok:
return True
else:
return False
indata = [0.5 for x in range(31)]
outdat = [0.0 for x in range(4)]
indata[1]=3.14
ok = snns(indata, outdat)
if ok:
print indata
print outdat
+++
This executes but leaves the outdat array unchanged.
Obviously I haven't understood ctypes well enough.
Returning arrays from FORTRAN I routinely do through a string_buffer.
That works very well but did not work here at all.
Any and all help welcome.
Alex van der Spek
--
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: ctypes: returning an array from a subroutine
Many hours later I found a working solutions in ctypes: The below makes sense to me but I am still at a loss why the first solution did not work. Anybody willing to explain for my better understanding? Regards, Alex van der Spek _snns = ctypes.windll.LoadLibrary(r'C:\MSDEV\Projects\Cyctrac\Debug\Cyctrac.dll') _cosm = getattr(_snns, '_bnd2prb@12') _cosm.restype = ctypes.c_int def snns(indata, outdat): """Calls the neural net, returns a vector of 4. """ global _cosm init = ctypes.c_long(0) odat = (ctypes.c_float * len(outdat))(*outdat) idat = (ctypes.c_float * len(indata))(*indata) iok = _cosm(ctypes.byref(idat), ctypes.byref(odat), init) for i, x in enumerate(odat): outdat[i] = x if not iok: return odat else: return False indata = [0.5 for x in range(31)] outdat = [0.0 for x in range(4)] ok = snns(indata, outdat) if ok: print indata print outdat +++ "Alex van der Spek" wrote in message news:[email protected]... I have a C code function like this: ++ int __declspec(dllexport) __stdcall bnd2prb(float *in, float *out, int init) {enum {OK, Error, Not_Valid}; ... return(OK): } ++ And in Python I am trying to call this C function: ++ import ctypes import struct import array _snns = ctypes.windll.LoadLibrary(r'C:\MSDEV\Projects\Cyctrac\Debug\Cyctrac.dll') _cosm = getattr(_snns, '_bnd2prb@12') _cosm.argtypes = (ctypes.POINTER(ctypes.c_float), ctypes.POINTER(ctypes.c_float), ctypes.c_long) _cosm.restype = ctypes.c_float def snns(indata, outdat): """Calls the neural net, returns a vector of 4. """ global _cosm init = ctypes.c_long(0) ilen = len(indata) olen = len(outdat) itype = ctypes.c_float * ilen otype = ctypes.c_float * olen iok = _cosm(itype(*indata), ctypes.pointer(otype(*outdat)), init) if not iok: return True else: return False indata = [0.5 for x in range(31)] outdat = [0.0 for x in range(4)] indata[1]=3.14 ok = snns(indata, outdat) if ok: print indata print outdat +++ This executes but leaves the outdat array unchanged. Obviously I haven't understood ctypes well enough. Returning arrays from FORTRAN I routinely do through a string_buffer. That works very well but did not work here at all. Any and all help welcome. Alex van der Spek -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 3?
On Apr 19, 2014 2:54 PM, "Chris Angelico" wrote: > > On Sun, Apr 20, 2014 at 6:38 AM, Ian Kelly wrote: > >> Or you just cast one of them to float. That way you're sure you're > >> working with floats. > > > > Which is inappropriate if the type passed in was a Decimal or a complex. > > In that case, you already have a special case in your code, so whether > that special case is handled by the language or by your code makes > little difference. Is your function so generic that it has to be able > to handle float, Decimal, or complex, and not care about the > difference, and yet has to ensure that int divided by int doesn't > yield int? Then say so; put in that special check. Personally, I've > yet to meet any non-toy example of a function that needs that exact > handling; most code doesn't ever think about complex numbers, and a > lot of things look for one specific type: 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
[OT] Testing and credentials best practices?
Greetings, How do you deal with tests (both on dev machine and Jenkins) that need credentials (such as AWS keys)?. I know of the following methods: 1. Test user with known (stored in source control) limited credentials 2. ~/.secrets (or any other known location) RC file which is not in source control 3. Credentials service (such as ZooKeeper) accessed only from VPN 4. Credentials pre user encrypted (gpg) and stored in source control What method are you using? Are there any best practices in the subject? Thanks, -- Miki -- 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" mailto:[email protected]>> wrote: > > On Sun, Apr 20, 2014 at 6:38 AM, Ian Kelly mailto:[email protected]>> 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 "", line 1, in File "", 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 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: [OT] Testing and credentials best practices?
On Mon, Apr 21, 2014 at 2:36 AM, Miki Tebeka wrote: > How do you deal with tests (both on dev machine and Jenkins) that need > credentials (such as AWS keys)?. I know of the following methods: > > 1. Test user with known (stored in source control) limited credentials > 2. ~/.secrets (or any other known location) RC file which is not in source > control > 3. Credentials service (such as ZooKeeper) accessed only from VPN > 4. Credentials pre user encrypted (gpg) and stored in source control I've done several of these. Another option that may work in some contexts is to mock the test altogether; have a server that simulates whatever you needed credentials for, and accepts a key of all zeroes or equivalent. Obviously that key can happily go into the source code :) 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
symple programming task
hi all, i have simple programming task: [quot] If we list all the natural numbers below 10 that are multiples of 3 or 5, we get 3, 5, 6 and 9. The sum of these multiples is 23. Find the sum of all the multiples of 3 or 5 below 1000. [/quote] this task from http://projecteuler.net/ site I wrote a solution in python http://pastebin.com/QXtNuRWU this script returned correctly result if "basis < 10", but if "basis < 1000" result is 266333 and it is not correctly answer on site http://projecteuler.net it is my script problem or site not working correctly? thanks sorry for my english -- https://mail.python.org/mailman/listinfo/python-list
Re: symple programming task
On Mon, Apr 21, 2014 at 4:43 AM, Ivan Ivanivich wrote: > [quot] > If we list all the natural numbers below 10 that are multiples of 3 or 5, we > get 3, 5, 6 and 9. The sum of these multiples is 23. > > Find the sum of all the multiples of 3 or 5 below 1000. > [/quote] > > this task from http://projecteuler.net/ site > > I wrote a solution in python > > http://pastebin.com/QXtNuRWU > > this script returned correctly result if "basis < 10", but if "basis < 1000" > result is 266333 and it is not correctly answer on site > http://projecteuler.net Try listing the actual numbers you're summing, and check if there's a problem there. Are all the numbers you expect appearing? Are any you don't want there? (I can see exactly what your problem is, but I'd rather give hints rather than simply tell you outright what's wrong.) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: symple programming task
Ivan Ivanivich wrote:
> hi all, i have simple programming task:
>
> [quot]
> If we list all the natural numbers below 10 that are multiples of 3 or 5,
> we get 3, 5, 6 and 9. The sum of these multiples is 23.
>
> Find the sum of all the multiples of 3 or 5 below 1000.
> [/quote]
>
> this task from http://projecteuler.net/ site
>
> I wrote a solution in python
>
> http://pastebin.com/QXtNuRWU
[for small scripts it is fine to include them directly in your post]
> #!/usr/bin/env python3.2
>
> total = 0
> for divider in 3, 5:
> basis=divider
> while basis < 1000:
> mod = basis % divider
> if mod == 0:
> total = total + basis
> print("total = ", total, "basis = ", basis)
>
> basis += 1
>
> print("total", total)
> this script returned correctly result if "basis < 10", but if "basis <
> 1000" result is 266333 and it is not correctly answer on site
> http://projecteuler.net
>
> it is my script problem or site not working correctly?
Your script. Try it for the numbers below 20, say, and then compare to a
result you calculated with pen and paper.
Or look closely at the output produced by the line
> print("total = ", total, "basis = ", basis)
in your code.
--
https://mail.python.org/mailman/listinfo/python-list
Re: symple programming task
On Sun, Apr 20, 2014 at 3:02 PM, Chris Angelico wrote: > On Mon, Apr 21, 2014 at 4:43 AM, Ivan Ivanivich > wrote: > > [quot] > > If we list all the natural numbers below 10 that are multiples of 3 or > 5, we get 3, 5, 6 and 9. The sum of these multiples is 23. > > > > Find the sum of all the multiples of 3 or 5 below 1000. > > [/quote] > > > > this task from http://projecteuler.net/ site > > > > I wrote a solution in python > > > > http://pastebin.com/QXtNuRWU > > > > this script returned correctly result if "basis < 10", but if "basis < > 1000" result is 266333 and it is not correctly answer on site > http://projecteuler.net > > Try listing the actual numbers you're summing, and check if there's a > problem there. Are all the numbers you expect appearing? Are any you > don't want there? > > (I can see exactly what your problem is, but I'd rather give hints > rather than simply tell you outright what's wrong.) > > ChrisA > -- > https://mail.python.org/mailman/listinfo/python-list > I second Chris's comments. Also, better to paste your code in email. More people will look at it, especially since it is short. It looks like you are looping thru all the numbers twice -- once for each divisor. You don't need to do that. You can loop thru and test for each divisor on each loop. You might want to ditch the while loop and use a for loop over a range: for i in range(1000): Its a more pythonic idiom. Also use 4 spaces, not 8 for indents. Minor points. Print() is your friend -- Joel Goldstick http://joelgoldstick.com -- https://mail.python.org/mailman/listinfo/python-list
Re: symple programming task
On Sunday, April 20, 2014 10:43:37 PM UTC+4, Ivan Ivanivich wrote: > hi all, i have simple programming task: > > > > [quot] > > If we list all the natural numbers below 10 that are multiples of 3 or 5, we > get 3, 5, 6 and 9. The sum of these multiples is 23. > > > > Find the sum of all the multiples of 3 or 5 below 1000. > > [/quote] > > > > this task from http://projecteuler.net/ site > > > > I wrote a solution in python > > > > http://pastebin.com/QXtNuRWU > > > > this script returned correctly result if "basis < 10", but if "basis < 1000" > result is 266333 and it is not correctly answer on site > http://projecteuler.net > > > > it is my script problem or site not working correctly? > > > > thanks > > > > sorry for my english thanks, i found the bag -- 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: [OT] Testing and credentials best practices?
In article <[email protected]>, Miki Tebeka wrote: > Greetings, > > How do you deal with tests (both on dev machine and Jenkins) that need > credentials (such as AWS keys)?. I know of the following methods: > > 1. Test user with known (stored in source control) limited credentials > 2. ~/.secrets (or any other known location) RC file which is not in source > control > 3. Credentials service (such as ZooKeeper) accessed only from VPN > 4. Credentials pre user encrypted (gpg) and stored in source control > > What method are you using? Are there any best practices in the subject? We've been looking at using etcd to store credentials (essentially the same solution as zookeeper). It seems like the right way to go. So far, my impression of etcd is "neat, promising, not ready for prime time yet" (to be fair, the etcd folks don't claim it's stable yet). ZooKeeper at least has the advantage of being in production use for a long time, so it should be pretty bullet-proof. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 3?
In article , Chris Angelico wrote: > On Mon, Apr 21, 2014 at 2:22 AM, Ian Kelly 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 , Chris Angelico wrote: On Mon, Apr 21, 2014 at 2:22 AM, Ian Kelly 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 , > Chris Angelico wrote: > >> On Mon, Apr 21, 2014 at 2:22 AM, Ian Kelly 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
how to string format when string have {
I have the following string:
nginx_conf = '''
server {
listen 80;
server_name dev.{project_url};
location / {
proxy_pass http://127.0.0.1:8080;
include /etc/nginx/proxy.conf;
}
location /media {
alias /home/mariano/PycharmProjects/{project_name}/{project_name}/media;
expires 30d;
}
location /static {
alias
/home/mariano/PycharmProjects/{project_name}/{project_name}/static;
expires 30d;
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
roothtml;
}
}'''
And I want to format like this:
context = {
"project_name":project_name,
"project_url":project_url,
}
nginx_conf.format(**context)
but since the string have { i can't.
Is there a way to solve this?
--
https://mail.python.org/mailman/listinfo/python-list
Re: how to string format when string have {
On Mon, Apr 21, 2014 at 8:34 AM, Mariano DAngelo
wrote:
> And I want to format like this:
>
> context = {
> "project_name":project_name,
> "project_url":project_url,
> }
>
> nginx_conf.format(**context)
>
>
> but since the string have { i can't.
> Is there a way to solve this?
Are you in full control of the source string? You can escape the
braces as explained here:
https://docs.python.org/3.4/library/string.html#format-string-syntax
If you're not in full control (eg if it comes from a user's input), or
if you don't like the idea of doubling all your braces, you could
switch to percent-formatting, or some other form of interpolation. But
the easiest would be to simply escape them.
ChrisA
--
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 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: how to string format when string have {
On 2014-04-20 15:34, Mariano DAngelo wrote:
> I have the following string:
...
> but since the string have { i can't.
> Is there a way to solve this?
I second Chris Angelico's suggestion about using the older percent
formatting:
nginx_conf = '''
server {
listen 80;
server_name dev.%(project_url)s;
location / {
proxy_pass http://127.0.0.1:8080;
include /etc/nginx/proxy.conf;
}
location /media {
alias
/home/mariano/PycharmProjects/%(project_name)s/%(project_name)s/media;
expires 30d;
}
location /static {
alias
/home/mariano/PycharmProjects/%(project_name)s/%(project_name)s/static;
expires 30d;
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
roothtml;
}
}'''
context = {
"project_name":project_name,
"project_url":project_url,
}
print(nginx_conf % context)
-tkc
--
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 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 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 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" 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 , > Chris Angelico wrote: > >> On Mon, Apr 21, 2014 at 2:22 AM, Ian Kelly >> 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
> 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 > 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 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 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
