Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #72539 > unrolled thread
| Started by | Sturla Molden <sturla.molden@gmail.com> |
|---|---|
| First post | 2014-06-03 17:28 +0000 |
| Last post | 2014-06-08 13:09 +1200 |
| Articles | 20 on this page of 132 — 27 participants |
Back to article view | Back to comp.lang.python
OT: This Swift thing Sturla Molden <sturla.molden@gmail.com> - 2014-06-03 17:28 +0000
Re: OT: This Swift thing Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2014-06-05 10:14 +0200
Re: OT: This Swift thing Chris Angelico <rosuav@gmail.com> - 2014-06-05 18:38 +1000
Re: OT: This Swift thing Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2014-06-05 11:42 +0200
Re: OT: This Swift thing Chris Angelico <rosuav@gmail.com> - 2014-06-05 22:48 +1000
Re: OT: This Swift thing Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2014-06-05 22:27 +0200
Re: OT: This Swift thing Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-06-05 22:28 +0100
Re: OT: This Swift thing Sturla Molden <sturla.molden@gmail.com> - 2014-06-05 23:03 +0000
Re: OT: This Swift thing Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2014-06-06 13:21 +0200
Re: OT: This Swift thing Sturla Molden <sturla.molden@gmail.com> - 2014-06-07 01:54 +0000
Re: OT: This Swift thing Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2014-06-07 10:20 +0200
Re: OT: This Swift thing Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-06-07 09:32 +0100
Re: OT: This Swift thing Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2014-06-07 11:54 +0200
Re: OT: This Swift thing Johannes Bauer <dfnsonfsduifb@gmx.de> - 2014-06-15 10:55 +0200
Re: OT: This Swift thing Roy Smith <roy@panix.com> - 2014-06-07 08:52 -0400
Re: OT: This Swift thing Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-06-07 11:13 -0400
Re: OT: This Swift thing Roy Smith <roy@panix.com> - 2014-06-07 11:54 -0400
Re: OT: This Swift thing Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-06-07 17:10 -0400
Re: OT: This Swift thing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-07 23:32 +0000
Re: OT: This Swift thing Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-06-06 00:41 +0100
Re: OT: This Swift thing Sturla Molden <sturla.molden@gmail.com> - 2014-06-06 01:54 +0200
Re: OT: This Swift thing Roy Smith <roy@panix.com> - 2014-06-05 20:13 -0400
Re: OT: This Swift thing Sturla Molden <sturla.molden@gmail.com> - 2014-06-06 02:35 +0200
Re: OT: This Swift thing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-06 05:45 +0000
Re: OT: This Swift thing Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2014-06-06 13:39 +0200
Re: OT: This Swift thing Sturla Molden <sturla.molden@gmail.com> - 2014-06-07 01:54 +0000
Re: OT: This Swift thing Sturla Molden <sturla.molden@gmail.com> - 2014-06-06 02:03 +0200
Re: OT: This Swift thing wxjmfauth@gmail.com - 2014-06-05 02:09 -0700
Re: OT: This Swift thing Sturla Molden <sturla.molden@gmail.com> - 2014-06-05 16:10 +0200
Re: OT: This Swift thing Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2014-06-05 22:07 +0200
Re: OT: This Swift thing Chris Angelico <rosuav@gmail.com> - 2014-06-06 06:18 +1000
Re: OT: This Swift thing Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2014-06-05 23:12 +0200
Re: OT: This Swift thing Sturla Molden <sturla.molden@gmail.com> - 2014-06-05 23:02 +0000
Re: OT: This Swift thing Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-06-05 22:23 +0100
Re: OT: This Swift thing Marko Rauhamaa <marko@pacujo.net> - 2014-06-06 00:53 +0300
Re: OT: This Swift thing Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-06-05 23:13 +0100
Re: OT: This Swift thing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-06 02:52 +0000
Re: OT: This Swift thing Johannes Bauer <dfnsonfsduifb@gmx.de> - 2014-06-15 11:33 +0200
Re: OT: This Swift thing Marko Rauhamaa <marko@pacujo.net> - 2014-06-15 16:10 +0300
Re: OT: This Swift thing Chris Angelico <rosuav@gmail.com> - 2014-06-06 07:36 +1000
Re: OT: This Swift thing Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2014-06-06 13:20 +0200
Re: OT: This Swift thing Chris Angelico <rosuav@gmail.com> - 2014-06-06 22:23 +1000
Re: OT: This Swift thing Christian Gollwitzer <auriocus@gmx.de> - 2014-06-07 09:30 +0200
Re: OT: This Swift thing Terry Reedy <tjreedy@udel.edu> - 2014-06-05 18:18 -0400
Re: OT: This Swift thing Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2014-06-06 13:11 +0200
Re: OT: This Swift thing Terry Reedy <tjreedy@udel.edu> - 2014-06-06 13:06 -0400
Re: OT: This Swift thing alex23 <wuwei23@gmail.com> - 2014-06-10 15:32 +1000
Re: OT: This Swift thing Sturla Molden <sturla.molden@gmail.com> - 2014-06-05 23:02 +0000
Re: OT: This Swift thing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-05 23:08 +0000
Re: OT: This Swift thing Sturla Molden <sturla.molden@gmail.com> - 2014-06-05 23:08 +0000
Re: OT: This Swift thing Chris Angelico <rosuav@gmail.com> - 2014-06-06 09:21 +1000
Re: OT: This Swift thing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-06 03:16 +0000
Re: OT: This Swift thing Chris Angelico <rosuav@gmail.com> - 2014-06-06 13:27 +1000
Re: OT: This Swift thing Michael Torrie <torriem@gmail.com> - 2014-06-05 08:33 -0600
Re: OT: This Swift thing Chris Angelico <rosuav@gmail.com> - 2014-06-06 01:44 +1000
Re: OT: This Swift thing Sturla Molden <sturla.molden@gmail.com> - 2014-06-05 18:09 +0200
Re: OT: This Swift thing Michael Torrie <torriem@gmail.com> - 2014-06-05 11:18 -0600
Re: OT: This Swift thing Mark H Harris <harrismh777@gmail.com> - 2014-06-05 13:49 -0500
Re: OT: This Swift thing Travis Griggs <travisgriggs@gmail.com> - 2014-06-05 23:28 -0700
Re: OT: This Swift thing Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2014-06-06 10:25 +0200
Re: OT: This Swift thing Michael Torrie <torriem@gmail.com> - 2014-06-06 20:41 -0600
Re: OT: This Swift thing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-07 04:57 +0000
Re: OT: This Swift thing Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-06-07 11:23 -0400
Re: OT: This Swift thing Roy Smith <roy@panix.com> - 2014-06-07 11:51 -0400
Re: OT: This Swift thing Marko Rauhamaa <marko@pacujo.net> - 2014-06-07 19:18 +0300
Re: OT: This Swift thing MRAB <python@mrabarnett.plus.com> - 2014-06-08 15:10 +0100
Re: OT: This Swift thing Michael Torrie <torriem@gmail.com> - 2014-06-07 11:37 -0600
Re: OT: This Swift thing Roy Smith <roy@panix.com> - 2014-06-07 14:11 -0400
Re: OT: This Swift thing Michael Torrie <torriem@gmail.com> - 2014-06-07 13:00 -0600
Re: OT: This Swift thing Roy Smith <roy@panix.com> - 2014-06-07 15:11 -0400
Re: OT: This Swift thing Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-06-07 17:59 -0400
Re: OT: This Swift thing Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-06-08 13:25 +1200
Re: OT: This Swift thing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-07 23:38 +0000
Re: OT: This Swift thing Roy Smith <roy@panix.com> - 2014-06-07 20:09 -0400
Re: OT: This Swift thing Chris Angelico <rosuav@gmail.com> - 2014-06-08 10:37 +1000
Re: OT: This Swift thing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-08 03:50 +0000
Re: OT: This Swift thing Roy Smith <roy@panix.com> - 2014-06-08 10:51 -0400
Re: OT: This Swift thing Gene Heskett <gheskett@wdtv.com> - 2014-06-08 11:21 -0400
Re: OT: This Swift thing Roy Smith <roy@panix.com> - 2014-06-08 12:09 -0400
Re: OT: This Swift thing Gene Heskett <gheskett@wdtv.com> - 2014-06-08 13:14 -0400
Re: OT: This Swift thing Chris Angelico <rosuav@gmail.com> - 2014-06-09 03:25 +1000
Re: OT: This Swift thing Sturla Molden <sturla.molden@gmail.com> - 2014-06-08 18:09 +0000
Re: OT: This Swift thing Chris Angelico <rosuav@gmail.com> - 2014-06-09 04:16 +1000
Re: OT: This Swift thing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-09 01:44 +0000
Re: OT: This Swift thing Rustom Mody <rustompmody@gmail.com> - 2014-06-08 19:24 -0700
Re: OT: This Swift thing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-09 04:20 +0000
Re: OT: This Swift thing Rustom Mody <rustompmody@gmail.com> - 2014-06-08 23:32 -0700
Re: OT: This Swift thing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-09 09:27 +0000
Re: OT: This Swift thing Rustom Mody <rustompmody@gmail.com> - 2014-06-09 04:51 -0700
Re: OT: This Swift thing Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-06-11 19:41 +1200
Re: OT: This Swift thing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-11 13:44 +0000
Re: OT: This Swift thing Rustom Mody <rustompmody@gmail.com> - 2014-06-11 08:28 -0700
Re: OT: This Swift thing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-12 02:08 +0000
Re: OT: This Swift thing Chris Angelico <rosuav@gmail.com> - 2014-06-12 12:16 +1000
Re: OT: This Swift thing Steven D'Aprano <steve@pearwood.info> - 2014-06-12 09:06 +0000
Re: OT: This Swift thing alister <alister.nospam.ware@ntlworld.com> - 2014-06-12 09:34 +0000
Re: OT: This Swift thing Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-06-12 23:32 +1200
Re: OT: This Swift thing Anssi Saari <as@sci.fi> - 2014-06-16 13:57 +0300
Re: OT: This Swift thing Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-06-17 10:12 +1200
Re: OT: This Swift thing Chris Angelico <rosuav@gmail.com> - 2014-06-17 08:34 +1000
Re: OT: This Swift thing alister <alister.nospam.ware@ntlworld.com> - 2014-06-17 11:16 +0000
Re: OT: This Swift thing Bob Martin <bob.martin@excite.com> - 2014-06-18 07:41 +0100
Re: OT: This Swift thing Rustom Mody <rustompmody@gmail.com> - 2014-06-12 05:54 -0700
Re: OT: This Swift thing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-12 17:04 +0000
Re: OT: This Swift thing Chris Angelico <rosuav@gmail.com> - 2014-06-13 03:18 +1000
Re: OT: This Swift thing Rustom Mody <rustompmody@gmail.com> - 2014-06-12 18:59 -0700
Re: OT: This Swift thing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-13 03:26 +0000
Re: OT: This Swift thing Gene Heskett <gheskett@wdtv.com> - 2014-06-12 14:43 -0400
Re: OT: This Swift thing albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-27 23:21 +0000
Re: OT: This Swift thing Joshua Landau <joshua@landau.ws> - 2014-06-15 02:51 +0100
Re: OT: This Swift thing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-15 03:33 +0000
Re: OT: This Swift thing Gene Heskett <gheskett@wdtv.com> - 2014-06-09 10:11 -0400
Re: OT: This Swift thing Marko Rauhamaa <marko@pacujo.net> - 2014-06-09 17:27 +0300
Re: OT: This Swift thing Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-06-11 18:56 +1200
Re: OT: This Swift thing Roy Smith <roy@panix.com> - 2014-06-09 09:14 -0400
Re: OT: This Swift thing Michael Torrie <torriem@gmail.com> - 2014-06-09 07:56 -0600
Re: OT: This Swift thing Marko Rauhamaa <marko@pacujo.net> - 2014-06-09 17:30 +0300
Re: OT: This Swift thing Rustom Mody <rustompmody@gmail.com> - 2014-06-08 19:35 -0700
Re: OT: This Swift thing Chris Angelico <rosuav@gmail.com> - 2014-06-09 12:23 +1000
Re: OT: This Swift thing Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-06-11 19:50 +1200
Re: OT: This Swift thing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-11 12:34 +0000
Re: OT: This Swift thing Roy Smith <roy@panix.com> - 2014-06-11 08:48 -0400
Re: OT: This Swift thing Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-06-11 20:17 -0400
Re: OT: This Swift thing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-12 01:25 +0000
Re: OT: This Swift thing Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-06-12 14:11 +1200
Re: OT: This Swift thing Gene Heskett <gheskett@wdtv.com> - 2014-06-11 23:06 -0400
Re: OT: This Swift thing Roy Smith <roy@panix.com> - 2014-06-13 08:55 -0400
Re: OT: This Swift thing Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-06-09 21:51 -0400
Re: OT: This Swift thing Carlos Anselmo Dias <carlos@premium-sponsor.com> - 2014-06-08 18:56 +0100
Re: OT: This Swift thing Sturla Molden <sturla.molden@gmail.com> - 2014-06-08 23:34 +0000
Re: OT: This Swift thing Rustom Mody <rustompmody@gmail.com> - 2014-06-08 19:32 -0700
Re: OT: This Swift thing Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-06-08 13:09 +1200
Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
| From | Sturla Molden <sturla.molden@gmail.com> |
|---|---|
| Date | 2014-06-06 01:54 +0200 |
| Message-ID | <mailman.10789.1402012487.18130.python-list@python.org> |
| In reply to | #72760 |
On 05/06/14 22:27, Alain Ketterlin wrote: > I have seen dozens of projects where Python was dismissed because of the > lack of static typing, and the lack of static analysis tools. If you are worried your code will bring down the next Ariane launch, I can understand this argument. If you are only worried a junior developer will make stupid mistankes that the test suite will trap, then no... In Python you cannot spoof an object's type, which means the type safety is strong. You cannot make Python silently return bytes of garbage by using objects of incompatible types. You cannot add a char to a float, and you cannot make a bit be treated bitwise as a float. You cannot make Python silently treat four bytes as an int. The worst thing that can happen is a TypeError raised at run-time. Yes, an unhandled TypeError exception could in theory bring down Ariane. But you are probably not developing for it. When is static analysis actually needed and for what purpose? The problem seems to be that managers, team leaders, CEOs, or (insert your favorite tite), are not qualified to answer this question. So to be on the safe side they go for as much static analysis as possible. But still they avoid Ada, because, you know, the journals they read are full of Java buzzwords. Sturla
[toc] | [prev] | [next] | [standalone]
| From | Roy Smith <roy@panix.com> |
|---|---|
| Date | 2014-06-05 20:13 -0400 |
| Message-ID | <roy-1E42CA.20132805062014@news.panix.com> |
| In reply to | #72794 |
In article <mailman.10789.1402012487.18130.python-list@python.org>, Sturla Molden <sturla.molden@gmail.com> wrote: > On 05/06/14 22:27, Alain Ketterlin wrote: > > I have seen dozens of projects where Python was dismissed because of the > > lack of static typing, and the lack of static analysis tools. > > If you are worried your code will bring down the next Ariane launch, I > can understand this argument. If you are only worried a junior developer > will make stupid mistankes that the test suite will trap, then no... > > In Python you cannot spoof an object's type, which means the type safety > is strong. You cannot make Python silently return bytes of garbage by > using objects of incompatible types. Well, you *can* play evil games with the struct module :-)
[toc] | [prev] | [next] | [standalone]
| From | Sturla Molden <sturla.molden@gmail.com> |
|---|---|
| Date | 2014-06-06 02:35 +0200 |
| Message-ID | <mailman.10792.1402014958.18130.python-list@python.org> |
| In reply to | #72798 |
On 06/06/14 02:13, Roy Smith wrote: > Well, you *can* play evil games with the struct module :-) But then you are asking for it, it does not happen by accident. Sturla
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2014-06-06 05:45 +0000 |
| Message-ID | <53915577$0$29978$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #72794 |
On Fri, 06 Jun 2014 01:54:32 +0200, Sturla Molden wrote: > When is static analysis actually needed and for what purpose? The > problem seems to be that managers, team leaders, CEOs, or (insert your > favorite tite), are not qualified to answer this question. So to be on > the safe side they go for as much static analysis as possible. Replace "as much as possible" with "the bare minimum provided by the compiler", and you will be usually right :-) Managers rarely choose languages like Haskell or Ada(?) where programs can be provably shown to be correct. They choose languages with just enough compile-time type checking to get in the way of rapid development, but not enough to lead to actual correct code. Some want languages like C that offer type-checking, but not languages like Pascal and its derivatives which enforce that type-checking -- Pascal is a "bondage and discipline" language, while C lets you escape from the discipline of types with the freedom of casts and other dangerous weak-typing features. -- Steven D'Aprano http://import-that.dreamwidth.org/
[toc] | [prev] | [next] | [standalone]
| From | Alain Ketterlin <alain@dpt-info.u-strasbg.fr> |
|---|---|
| Date | 2014-06-06 13:39 +0200 |
| Message-ID | <87k38unu7a.fsf@dpt-info.u-strasbg.fr> |
| In reply to | #72794 |
Sturla Molden <sturla.molden@gmail.com> writes: > On 05/06/14 22:27, Alain Ketterlin wrote: >> I have seen dozens of projects where Python was dismissed because of the >> lack of static typing, and the lack of static analysis tools. [...] > When is static analysis actually needed and for what purpose? For example WCET analysis (where predictability is more important than performance). Or code with strong security constraint. Or overflow detection tools. Or race condition analyzers. And there are many others. And I don't even mention engineering tools for dependence analysis, packaging, etc. (or even IDEs). > [...] But still they avoid Ada [...] Sorry, I forgot Ada in my list. -- Alain.
[toc] | [prev] | [next] | [standalone]
| From | Sturla Molden <sturla.molden@gmail.com> |
|---|---|
| Date | 2014-06-07 01:54 +0000 |
| Message-ID | <mailman.10841.1402106106.18130.python-list@python.org> |
| In reply to | #72836 |
Alain Ketterlin <alain@dpt-info.u-strasbg.fr> wrote: >> When is static analysis actually needed and for what purpose? > > For example WCET analysis (where predictability is more important than > performance). Or code with strong security constraint. Or overflow > detection tools. Or race condition analyzers. And there are many others. > And I don't even mention engineering tools for dependence analysis, > packaging, etc. (or even IDEs). You don't have to answer a rhetorical question. Sturla
[toc] | [prev] | [next] | [standalone]
| From | Sturla Molden <sturla.molden@gmail.com> |
|---|---|
| Date | 2014-06-06 02:03 +0200 |
| Message-ID | <mailman.10790.1402013044.18130.python-list@python.org> |
| In reply to | #72760 |
On 06/06/14 01:41, Mark Lawrence wrote: > s/almost// :) Sometimes it is the right decision, like when your code is firmware for some avionics or medial life-support apparatus. Sturla
[toc] | [prev] | [next] | [standalone]
| From | wxjmfauth@gmail.com |
|---|---|
| Date | 2014-06-05 02:09 -0700 |
| Message-ID | <e0e15f2f-25b5-4fd3-af9b-b471dda6224a@googlegroups.com> |
| In reply to | #72690 |
Le jeudi 5 juin 2014 10:14:15 UTC+2, Alain Ketterlin a écrit : > Sturla Molden <sturla.molden@gmail.com> writes: > > > > > Dear Apple, > > > > > > Why should I be exited about an illegitmate child of Python, Go and > > > JavaScript? > > [...] > > > > Type safety. (And with it comes better performance ---read battery > > life--- and better static analysis tools, etc.) LLVM (an Apple-managed > > project) for the middle- and back-end, and a brand new front-end > > incorporating a decent type system (including optional types for > > instance). > > > > Swift's memory management is similar to python's (ref. counting). Which > > makes me think that a subset of python with the same type safety would > > be an instant success. > > About type. A very quick look at the doc and at what is interesting me. "A string [type] is an ordered collection of characters [type], such..." []: my addendum It seems they are understanding unicode (zeroth order approximation). jmf
[toc] | [prev] | [next] | [standalone]
| From | Sturla Molden <sturla.molden@gmail.com> |
|---|---|
| Date | 2014-06-05 16:10 +0200 |
| Message-ID | <mailman.10735.1401977435.18130.python-list@python.org> |
| In reply to | #72690 |
On 05/06/14 10:14, Alain Ketterlin wrote: > Type safety. Perhaps. Python has strong type safety. It is easier to spoof a type in C or C++ than Python. Python 3 also has type annotations that can be used to ensure the types are correct when we run tests. In a world of consenting adults I am not sure we really need static types compared to ducktyping. >(And with it comes better performance ---read battery > life--- and better static analysis tools, etc.) Perhaps, perhaps not. My experience is that only a small percentage of the CPU time is spent in the Python interpreter. - The GPU does not care if my OpenGL shaders are submitted from Python or C. Nor do any other library or framework. If I use OpenCV to capture live video, it could not care less if I use Python or C. A cocoa app using PyObjC will not use Python to prepare each pixel on the screen. Even if the screen is frequently updated, the battery is spent somewhere else than in the Python interpreter. - A GUI program that is mostly idle spends more battery on lighting the screen than executing code. - If I use a 3g connection on my iPad, most of the battery will be spent transmitting and receiving data on the mobile network. - Where is the battery spent if I stream live video? In the Python interpreter that executes a few LOC for each frame? I will make the bold statement that an equivalent C program would exhaust the battery equally fast. - If an web app seems slow, it is hardly every due to Python on the server side. - If the response time in a GUI is below the limits of human perception, can the user tell my Python program is slower than a C program? For the rare case where I actually have to run algorithmic code in Python, there is always Numba (an LLVM-based JIT compiler) or Cython which can be used to speed things up to C performance when the Python prototype works. I rarely need to do this, though. > LLVM (an Apple-managed > project) for the middle- and back-end, and a brand new front-end > incorporating a decent type system (including optional types for > instance). Numba uses LLVM. When I compile Cython modules I use LLVM on this computer. > Swift's memory management is similar to python's (ref. counting). Which > makes me think that a subset of python with the same type safety would > be an instant success. A Python with static typing would effectively be Cython :) It is the tool of choice in many scientific Python projects today. Most projects affiliated with NumPy and SciPy prefer Cython to C or Fortran for new code. Sturla
[toc] | [prev] | [next] | [standalone]
| From | Alain Ketterlin <alain@dpt-info.u-strasbg.fr> |
|---|---|
| Date | 2014-06-05 22:07 +0200 |
| Message-ID | <87tx7zi0i1.fsf@dpt-info.u-strasbg.fr> |
| In reply to | #72706 |
Sturla Molden <sturla.molden@gmail.com> writes: > On 05/06/14 10:14, Alain Ketterlin wrote: > >> Type safety. > > Perhaps. Python has strong type safety. Come on. [...] >>(And with it comes better performance ---read battery >> life--- and better static analysis tools, etc.) > > Perhaps, perhaps not. My experience is that only a small percentage of > the CPU time is spent in the Python interpreter. [...] Basically, you're saying that a major fraction of python programs is written in another language. An interesting argument... >> LLVM (an Apple-managed project) for the middle- and back-end, and a >> brand new front-end incorporating a decent type system (including >> optional types for instance). > > Numba uses LLVM. As far as I know, Numba deals only with primitive types. You will gain nothing for classes. (And Numba is a JIT.) > When I compile Cython modules I use LLVM on this computer. Cython is not Python, it is another language, with an incompatible syntax. >> Swift's memory management is similar to python's (ref. counting). Which >> makes me think that a subset of python with the same type safety would >> be an instant success. > > A Python with static typing would effectively be Cython :) I don't think so. The various proposals mentioned elsewhere in this thread give concrete examples of what static typing would look like in Python. -- Alain.
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-06-06 06:18 +1000 |
| Message-ID | <mailman.10762.1401999505.18130.python-list@python.org> |
| In reply to | #72753 |
On Fri, Jun 6, 2014 at 6:07 AM, Alain Ketterlin <alain@dpt-info.u-strasbg.fr> wrote: >> Perhaps, perhaps not. My experience is that only a small percentage of >> the CPU time is spent in the Python interpreter. > > Basically, you're saying that a major fraction of python programs is > written in another language. An interesting argument... No, a major fraction of Python program execution time is deep inside code written in another language. In extreme cases, you might have a tiny bit of Python glue and the bulk of your code is actually, say, FORTRAN - such as a hefty numpy number crunch - which lets you take advantage of multiple cores, since there's no Python code running most of the time. And that's counting only CPU time. If you count wall time, your typical Python program spends most of its time deep inside kernel API calls, waiting for the user or I/O or something. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Alain Ketterlin <alain@dpt-info.u-strasbg.fr> |
|---|---|
| Date | 2014-06-05 23:12 +0200 |
| Message-ID | <87lhtbhxhx.fsf@dpt-info.u-strasbg.fr> |
| In reply to | #72755 |
Chris Angelico <rosuav@gmail.com> writes: > On Fri, Jun 6, 2014 at 6:07 AM, Alain Ketterlin > <alain@dpt-info.u-strasbg.fr> wrote: >>> Perhaps, perhaps not. My experience is that only a small percentage of >>> the CPU time is spent in the Python interpreter. >> >> Basically, you're saying that a major fraction of python programs is >> written in another language. An interesting argument... > > No, a major fraction of Python program execution time is deep inside > code written in another language. In extreme cases, you might have a > tiny bit of Python glue and the bulk of your code is actually, say, > FORTRAN - such as a hefty numpy number crunch - which lets you take > advantage of multiple cores, since there's no Python code running most > of the time. This is actually what I meant. I find it sad to keep Python such a glue language (the kind of language you throw away when the trend changes---like Perl for example). > And that's counting only CPU time. If you count wall time, your > typical Python program spends most of its time deep inside kernel API > calls, waiting for the user or I/O or something. But this is true of any IO-bound program, whatever the language. I see no reason why Python should be restricted to simple processing tasks. -- Alain.
[toc] | [prev] | [next] | [standalone]
| From | Sturla Molden <sturla.molden@gmail.com> |
|---|---|
| Date | 2014-06-05 23:02 +0000 |
| Message-ID | <mailman.10782.1402009393.18130.python-list@python.org> |
| In reply to | #72765 |
Alain Ketterlin <alain@dpt-info.u-strasbg.fr> wrote: >> And that's counting only CPU time. If you count wall time, your >> typical Python program spends most of its time deep inside kernel API >> calls, waiting for the user or I/O or something. > > But this is true of any IO-bound program, whatever the language. Exactly, this is true even with Swift. The Swift and the Python program would spend most of the time doing the same thing (idle processing). Thus a GUI program written in Python would not exhaust the battery faster than a program written in Swift. In both cases, the majority of the wall time is spent inside the kernel waiting for some UI event (keyboard, mouse, whatever). And in both cases the battery is spent lighting up a screen that is mostly static. And in both bases the graphics displayed on the screen is generated inside some UI framework written in Objective-C. Sturla
[toc] | [prev] | [next] | [standalone]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2014-06-05 22:23 +0100 |
| Message-ID | <mailman.10769.1402003441.18130.python-list@python.org> |
| In reply to | #72753 |
On 05/06/2014 21:07, Alain Ketterlin wrote: > Sturla Molden <sturla.molden@gmail.com> writes: > >> On 05/06/14 10:14, Alain Ketterlin wrote: >> >>> Type safety. >> >> Perhaps. Python has strong type safety. > > Come on. > I don't understand that comment, please explain. -- 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
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2014-06-06 00:53 +0300 |
| Message-ID | <87y4xbt447.fsf@elektro.pacujo.net> |
| In reply to | #72766 |
Mark Lawrence <breamoreboy@yahoo.co.uk>:
> On 05/06/2014 21:07, Alain Ketterlin wrote:
>> Sturla Molden <sturla.molden@gmail.com> writes:
>>> On 05/06/14 10:14, Alain Ketterlin wrote:
>>>> Type safety.
>>> Perhaps. Python has strong type safety.
>> Come on.
>
> I don't understand that comment, please explain.
I guess what is referred to is static typing. It serves two purposes:
1. It makes the managers of software development teams believe the
junior developers in their teams won't be able to do too much damage
as the compiler at least enforces some rigor in the code. Hence,
"safety."
2. It makes it much easier to automatically optimize the code.
Unfortunately, it also has serious downsides:
3. The code becomes very tedious to type in. You may need hundreds of
lines of boilerplate code before it actually does anything. It also
easily makes you lose your focus.
4. The flow of the code becomes hard to understand because of the
boilerplate. Ironically, the very straitjacket that seeks to force
good quality on you prevents you from seeing the forest for the
trees.
Example:
Map<StreetAddress, ZipCode> makeStreetAddressMap(
List<StreetInfo> infoList) {
Map<StreetAddress, ZipCode> map =
new HashMap<StreetAddress, ZipCode>();
for (StreetInfo info : infoList)
map.put(info.getStreetAddress(), info.getZipCode());
return map;
}
vs
def make_street_address_map(info_list):
map = {}
for info in info_list:
map[info.get_street_address()] = info.get_zip_code()
return map
or:
def make_street_address_map(info_list):
return dict((info.get_street_address(), info.get_zip_code())
for info in info_list)
Marko
[toc] | [prev] | [next] | [standalone]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2014-06-05 23:13 +0100 |
| Message-ID | <mailman.10776.1402006397.18130.python-list@python.org> |
| In reply to | #72771 |
On 05/06/2014 22:53, Marko Rauhamaa wrote:
> Mark Lawrence <breamoreboy@yahoo.co.uk>:
>
>> On 05/06/2014 21:07, Alain Ketterlin wrote:
>>> Sturla Molden <sturla.molden@gmail.com> writes:
>>>> On 05/06/14 10:14, Alain Ketterlin wrote:
>>>>> Type safety.
>>>> Perhaps. Python has strong type safety.
>>> Come on.
>>
>> I don't understand that comment, please explain.
>
> I guess what is referred to is static typing. It serves two purposes:
>
> 1. It makes the managers of software development teams believe the
> junior developers in their teams won't be able to do too much damage
> as the compiler at least enforces some rigor in the code. Hence,
> "safety."
>
> 2. It makes it much easier to automatically optimize the code.
>
> Unfortunately, it also has serious downsides:
>
> 3. The code becomes very tedious to type in. You may need hundreds of
> lines of boilerplate code before it actually does anything. It also
> easily makes you lose your focus.
>
> 4. The flow of the code becomes hard to understand because of the
> boilerplate. Ironically, the very straitjacket that seeks to force
> good quality on you prevents you from seeing the forest for the
> trees.
>
> Example:
>
>
> Map<StreetAddress, ZipCode> makeStreetAddressMap(
> List<StreetInfo> infoList) {
> Map<StreetAddress, ZipCode> map =
> new HashMap<StreetAddress, ZipCode>();
> for (StreetInfo info : infoList)
> map.put(info.getStreetAddress(), info.getZipCode());
> return map;
> }
>
> vs
>
> def make_street_address_map(info_list):
> map = {}
> for info in info_list:
> map[info.get_street_address()] = info.get_zip_code()
> return map
>
> or:
>
> def make_street_address_map(info_list):
> return dict((info.get_street_address(), info.get_zip_code())
> for info in info_list)
>
>
> Marko
>
Interesting. We've gone from "Python has strong type safety" to "come
on" to "I guess what is referred to is static typing". I'll simply say
that I understand Python to be strongly, dynamically typed.
--
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
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2014-06-06 02:52 +0000 |
| Message-ID | <53912cdb$0$29978$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #72774 |
On Thu, 05 Jun 2014 23:13:00 +0100, Mark Lawrence wrote: > I'll simply say that I > understand Python to be strongly, dynamically typed. Correct. Anyone who hasn't done so needs to read this: http://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wrote/ I wouldn't quite go so far as to say that weakly typed is a meaningless concept, but I would agree that there are degrees of weakness. -- Steven D'Aprano http://import-that.dreamwidth.org/
[toc] | [prev] | [next] | [standalone]
| From | Johannes Bauer <dfnsonfsduifb@gmx.de> |
|---|---|
| Date | 2014-06-15 11:33 +0200 |
| Message-ID | <lnjp8j$ign$1@news.albasani.net> |
| In reply to | #72771 |
On 05.06.2014 23:53, Marko Rauhamaa wrote:
> or:
>
> def make_street_address_map(info_list):
> return dict((info.get_street_address(), info.get_zip_code())
> for info in info_list)
>
or, what I think is even clearer than your last one:
def make_street_address_map(info_list):
return { info.get_street_address(): info.get_zip_code()
for info in info_list }
Regards,
Johannes
--
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
- Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org>
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2014-06-15 16:10 +0300 |
| Message-ID | <87a99etj2g.fsf@elektro.pacujo.net> |
| In reply to | #73288 |
Johannes Bauer <dfnsonfsduifb@gmx.de>:
> def make_street_address_map(info_list):
> return { info.get_street_address(): info.get_zip_code()
> for info in info_list }
Live and learn. Have been an the lookout for dict comprehensions, but
didn't notice they were already included.
Marko
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-06-06 07:36 +1000 |
| Message-ID | <mailman.10772.1402004202.18130.python-list@python.org> |
| In reply to | #72753 |
On Fri, Jun 6, 2014 at 7:23 AM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote: > On 05/06/2014 21:07, Alain Ketterlin wrote: >> >> Sturla Molden <sturla.molden@gmail.com> writes: >> >>> On 05/06/14 10:14, Alain Ketterlin wrote: >>> >>>> Type safety. >>> >>> Perhaps. Python has strong type safety. >> >> Come on. > > I don't understand that comment, please explain. "Type safety" means many different things to different people. What Python has is untyped variables, and hierarchically typed objects. It's impossible to accidentally treat an integer as a float, and have junk data [1]. It's impossible to accidentally call a base class's method when you ought to have called the overriding method in the subclass, which is a risk in C++ [2]. If you mistakenly pass a list to a function that was expecting an integer, that function will *know* that it got a list, because objects in Python are rigidly typed. But some languages stipulate the types that a variable can take, and that's something Python doesn't do. If you want to say that this function argument must be an integer, you have to explicitly check it inside the function. (And the Pythonic thing to do is to *not* check it, but that's a separate point.) This is something that function annotations can be used for, but I'm not seeing a huge thrust to make use of them everywhere. Why not? I suspect because the need for it just isn't as great as some people think. ChrisA [1] Note that in some circumstances, you can (deliberately) fiddle with an object's type. But you can't just reinterpret the bits in memory, the way you can in C, by casting a pointer and dereferencing it. Hence, it's impossible to *accidentally* muck this up. [2] Again, you can muck things up, by explicitly pulling up a function from the base class, rather than using method lookup on the object. But again, you can't do it accidentally.
[toc] | [prev] | [next] | [standalone]
Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
Back to top | Article view | comp.lang.python
csiph-web