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 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
| From | Alain Ketterlin <alain@dpt-info.u-strasbg.fr> |
|---|---|
| Date | 2014-06-06 13:20 +0200 |
| Message-ID | <87sininv2y.fsf@dpt-info.u-strasbg.fr> |
| In reply to | #72769 |
Chris Angelico <rosuav@gmail.com> writes: > 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 in Swift as well. > 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]. I don't how this can happen in C++, unless you actually have an instance of the base class. Anyway, I didn't mention C++. [I agree with the rest of your explanation.] -- Alain.
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-06-06 22:23 +1000 |
| Message-ID | <mailman.10812.1402057433.18130.python-list@python.org> |
| In reply to | #72833 |
On Fri, Jun 6, 2014 at 9:20 PM, Alain Ketterlin <alain@dpt-info.u-strasbg.fr> wrote: >> 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]. > > I don't how this can happen in C++, unless you actually have an instance > of the base class. Anyway, I didn't mention C++. Mostly if you forget to declare the method 'virtual'; there are other ways to muck things up, but that's the main one. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Christian Gollwitzer <auriocus@gmx.de> |
|---|---|
| Date | 2014-06-07 09:30 +0200 |
| Message-ID | <lmuf2p$4fv$1@dont-email.me> |
| In reply to | #72833 |
Am 06.06.14 13:20, schrieb Alain Ketterlin: > Chris Angelico <rosuav@gmail.com> writes: >> 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]. > > I don't how this can happen in C++, unless you actually have an instance > of the base class. Anyway, I didn't mention C++. A special, but important case of this is inside the constructor. Until you exit the constructor, C++ treats the object as not fully constructed, and if you call a virtual method there, it calls the method of the base class. http://www.parashift.com/c++-faq/calling-virtuals-from-ctors.html The answer is, of course, to create a *separate* init function in addition to the constructor and to require the user of the class to call it after the constructor, or to hide the real constructor away and require the user to call a factory function instead. I love C++. (seriously, but not /that/ part) Christian
[toc] | [prev] | [next] | [standalone]
| From | Terry Reedy <tjreedy@udel.edu> |
|---|---|
| Date | 2014-06-05 18:18 -0400 |
| Message-ID | <mailman.10778.1402006717.18130.python-list@python.org> |
| In reply to | #72753 |
On 6/5/2014 4:07 PM, Alain Ketterlin wrote: >> When I compile Cython modules I use LLVM on this computer. > > Cython is not Python, it is another language, with an incompatible > syntax. Cython compiles Python with optional extensions that allow additional speed ups over compiling Python as is. In other word, the Cython language is a Python superset. -- Terry Jan Reedy
[toc] | [prev] | [next] | [standalone]
| From | Alain Ketterlin <alain@dpt-info.u-strasbg.fr> |
|---|---|
| Date | 2014-06-06 13:11 +0200 |
| Message-ID | <87wqcunvhh.fsf@dpt-info.u-strasbg.fr> |
| In reply to | #72776 |
Terry Reedy <tjreedy@udel.edu> writes: > On 6/5/2014 4:07 PM, Alain Ketterlin wrote: > >>> When I compile Cython modules I use LLVM on this computer. >> >> Cython is not Python, it is another language, with an incompatible >> syntax. > > Cython compiles Python with optional extensions that allow additional > speed ups over compiling Python as is. In other word, the Cython > language is a Python superset. You're right. What I question is the fact that anybody uses Cython without the additional syntax. There is little chance that a "pure" Python program will see any significant speedup when compiled with Cython (or, if it does, it means that the "canonical" Python interpreter has some sub-optimal behavior that will, eventually, be corrected). The nice thing with optional type annotations and an hypothetical Python compiler would be that you could, e.g., continue using the interpreter during development and then compile for production use. Or whatever mix you need. -- Alain.
[toc] | [prev] | [next] | [standalone]
| From | Terry Reedy <tjreedy@udel.edu> |
|---|---|
| Date | 2014-06-06 13:06 -0400 |
| Message-ID | <mailman.10823.1402074399.18130.python-list@python.org> |
| In reply to | #72832 |
On 6/6/2014 7:11 AM, Alain Ketterlin wrote: > Terry Reedy <tjreedy@udel.edu> writes: > >> On 6/5/2014 4:07 PM, Alain Ketterlin wrote: >> >>>> When I compile Cython modules I use LLVM on this computer. >>> >>> Cython is not Python, it is another language, with an incompatible >>> syntax. >> >> Cython compiles Python with optional extensions that allow additional >> speed ups over compiling Python as is. In other word, the Cython >> language is a Python superset. I am assuming here that the claim to have reached this goal is correct. > You're right. What I question is the fact that anybody uses Cython > without the additional syntax. There is little chance that a "pure" > Python program will see any significant speedup when compiled with I believe the Cython author has claimed a 2x-5x speedup for stdlib modules when compiled 'as is'. > Cython (or, if it does, it means that the "canonical" Python interpreter > has some sub-optimal behavior that will, eventually, be corrected). I believe that there is some inherent overhead that Cython bypasses. -- Terry Jan Reedy
[toc] | [prev] | [next] | [standalone]
| From | alex23 <wuwei23@gmail.com> |
|---|---|
| Date | 2014-06-10 15:32 +1000 |
| Message-ID | <ln65ab$2ni$1@dont-email.me> |
| In reply to | #72832 |
On 6/06/2014 9:11 PM, Alain Ketterlin wrote: > The nice thing with optional type annotations and an hypothetical Python > compiler would be that you could, e.g., continue using the interpreter > during development and then compile for production use. s/annotations/decorators/ and you effectively have Cython's "pure Python" mode.
[toc] | [prev] | [next] | [standalone]
| From | Sturla Molden <sturla.molden@gmail.com> |
|---|---|
| Date | 2014-06-05 23:02 +0000 |
| Message-ID | <mailman.10783.1402009506.18130.python-list@python.org> |
| In reply to | #72753 |
Alain Ketterlin <alain@dpt-info.u-strasbg.fr> wrote: >> Perhaps. Python has strong type safety. > > Come on. You cannot spoof the type of an object in Python. In C++ you can downcast any address to void* and make an object be treated as anything. You cannot make Python treat an int as a float and return garbage. Types in Python are strictly enforced. Sturla
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2014-06-05 23:08 +0000 |
| Message-ID | <5390f882$0$29978$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #72753 |
On Thu, 05 Jun 2014 22:07:18 +0200, 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. No, Sturla is correct. Python has strongly-typed values and dynamically- typed variables, which means that you get type errors at run-time, not compile-time. But you still get type errors: py> '1' + 2 Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: Can't convert 'int' object to str implicitly [...] >> When I compile Cython modules I use LLVM on this computer. > > Cython is not Python, it is another language, with an incompatible > syntax. Cython is best considered a superset of Python, with a pure-Python compatibility mode. It can run standard Python code. -- Steven D'Aprano http://import-that.dreamwidth.org/
[toc] | [prev] | [next] | [standalone]
| From | Sturla Molden <sturla.molden@gmail.com> |
|---|---|
| Date | 2014-06-05 23:08 +0000 |
| Message-ID | <mailman.10784.1402009809.18130.python-list@python.org> |
| In reply to | #72753 |
Chris Angelico <rosuav@gmail.com> wrote: > "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]. Exactly. I have no hopes that those who claim Python lacks type safety will understand this, however. > 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. And then there is nothing that prevents the function from raising a TypeError. Sturla
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-06-06 09:21 +1000 |
| Message-ID | <mailman.10786.1402010495.18130.python-list@python.org> |
| In reply to | #72753 |
On Fri, Jun 6, 2014 at 9:02 AM, Sturla Molden <sturla.molden@gmail.com> wrote:
> You cannot spoof the type of an object in Python.
Not without fiddling around. Python 3.4 on win32:
>>> class Foo:
def spam(self):
print(self,"spams")
>>> class Bar:
def spam(self):
print(self,"eats spam")
>>> x = Foo()
>>> x.spam()
<__main__.Foo object at 0x0169AB10> spams
>>> x.__class__ = Bar
>>> x.spam()
<__main__.Bar object at 0x0169AB10> eats spam
The thing has the same id (as shown in its repr), but has changed
class. However, you can't turn it into an int:
>>> x.__class__ = int
Traceback (most recent call last):
File "<pyshell#36>", line 1, in <module>
x.__class__ = int
TypeError: __class__ assignment: only for heap types
So there are limits. (Obviously with ctypes you can do anything, but
at that point, you're not working with Python any more, you're
fiddling with CPython's RAM. That's quite different.)
ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2014-06-06 03:16 +0000 |
| Message-ID | <53913292$0$29978$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #72790 |
On Fri, 06 Jun 2014 09:21:26 +1000, Chris Angelico wrote: > On Fri, Jun 6, 2014 at 9:02 AM, Sturla Molden <sturla.molden@gmail.com> > wrote: >> You cannot spoof the type of an object in Python. > > Not without fiddling around. Python 3.4 on win32: [...] >>>> x = Foo() >>>> x.spam() > <__main__.Foo object at 0x0169AB10> spams >>>> x.__class__ = Bar >>>> x.spam() > <__main__.Bar object at 0x0169AB10> eats spam > > The thing has the same id (as shown in its repr), but has changed class. That's not spoofing types. That is a language feature: within limits, instances can change their type. It has been around for a long, long time, back to Python 1.5 or older, and it has real-world use-cases: http://code.activestate.com/recipes/68429-ring-buffer/ -- Steven D'Aprano http://import-that.dreamwidth.org/
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-06-06 13:27 +1000 |
| Message-ID | <mailman.10804.1402025249.18130.python-list@python.org> |
| In reply to | #72813 |
On Fri, Jun 6, 2014 at 1:16 PM, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote: > On Fri, 06 Jun 2014 09:21:26 +1000, Chris Angelico wrote: > >> On Fri, Jun 6, 2014 at 9:02 AM, Sturla Molden <sturla.molden@gmail.com> >> wrote: >>> You cannot spoof the type of an object in Python. >> >> Not without fiddling around. Python 3.4 on win32: > [...] >>>>> x = Foo() >>>>> x.spam() >> <__main__.Foo object at 0x0169AB10> spams >>>>> x.__class__ = Bar >>>>> x.spam() >> <__main__.Bar object at 0x0169AB10> eats spam >> >> The thing has the same id (as shown in its repr), but has changed class. > > That's not spoofing types. That is a language feature: within limits, > instances can change their type. It has been around for a long, long > time, back to Python 1.5 or older, and it has real-world use-cases: > > http://code.activestate.com/recipes/68429-ring-buffer/ True, it's not *spoofing*, in the same way that this C code is: float x = 3.14159; int y = *(int *)&x; And I'm aware that it's a language feature (why else would it be specifically limited with a clear exception when you try to assign something you can't?). So's the C-level fiddling, albeit for different reasons and in different ways. Anyway, I was broadly agreeing - Python's type system is "objects have types", rather than "stuff is in memory and data types are just how you look at it". It just happens to be possible to fiddle if you want to :) ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Michael Torrie <torriem@gmail.com> |
|---|---|
| Date | 2014-06-05 08:33 -0600 |
| Message-ID | <mailman.10736.1401978833.18130.python-list@python.org> |
| In reply to | #72690 |
On 06/05/2014 08:10 AM, Sturla Molden wrote: > Perhaps, perhaps not. My experience is that only a small percentage of > the CPU time is spent in the Python interpreter. Depends greatly on the type of application. While it's true that most apps that aren't CPU bound are idle most of the time, there's more to the story than that. A handy utility for analyzing power usage by applications is Intel's powertop. It measures things like how many wakeups a program caused, and which sleep states a CPU is spending time in. It's more complicated and nuanced than simply adding up CPU time. In any case I'm a bit surprised by people comparing Python to Swift at all, implying that Python would have worked just as well and Apple should have chosen it to replace Objective C. Why are we comparing an interpreter with a compiled language? Apple's goal is to produce a language that they can transition from Objective C to, and use to build apps as well as core system frameworks. Swift provides a cleaner system for developers to work in than Obj C did (which, by the way has reference counting), but carries on the same object model that developers are used to (and existing frameworks use).
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-06-06 01:44 +1000 |
| Message-ID | <mailman.10740.1401983077.18130.python-list@python.org> |
| In reply to | #72690 |
On Fri, Jun 6, 2014 at 12:10 AM, Sturla Molden <sturla.molden@gmail.com> wrote: > My experience is that only a small percentage of the CPU time is spent in > the Python interpreter. > [various examples ] > - 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? And I'd go further: With several of these examples (particularly this last one), contradictory examples are code smell at the level of the Mythbusters' Corvette. I've had a few times when a GUI program written in a high level language is perceptibly slow; the most recent example was complete proof of your assertion, because under certain circumstances it could saturate a CPU core - but generally it would be 25% in my code and 75% in Xorg. The bug was that it was redrawing a ridiculous amount of "stuff" that hadn't changed (and in a lot of cases wasn't even visible), in response to a sweep of user actions. (Imagine marking and highlighting text in your favourite editor, and every time you move the mouse a pixel across, the entire buffer gets redrawn.) So even when response time was appalling, most of the time was actually spent inside API calls, not my code. Given how much easier it is to debug Python code than C code, I'd say this puts the advantage squarely on the high level language. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Sturla Molden <sturla.molden@gmail.com> |
|---|---|
| Date | 2014-06-05 18:09 +0200 |
| Message-ID | <mailman.10742.1401984609.18130.python-list@python.org> |
| In reply to | #72690 |
On 05/06/14 16:33, Michael Torrie wrote: > In any case I'm a bit surprised by people comparing Python to Swift at > all, implying that Python would have worked just as well and Apple > should have chosen it to replace Objective C. Because if you look at the spec, Swift is essentially a statically typed Python. Swift and Python will also be used in the same niche. C will still be used for low-level stuff. Swift is not a replacement for C. It's a replacement for Objective-C. > Swift provides a cleaner system > for developers to work in than Obj C did (which, by the way has > reference counting), but carries on the same object model that > developers are used to (and existing frameworks use). That is what PyObjC does as well. Sturla
[toc] | [prev] | [next] | [standalone]
| From | Michael Torrie <torriem@gmail.com> |
|---|---|
| Date | 2014-06-05 11:18 -0600 |
| Message-ID | <mailman.10748.1401988709.18130.python-list@python.org> |
| In reply to | #72690 |
On 06/05/2014 10:09 AM, Sturla Molden wrote: > On 05/06/14 16:33, Michael Torrie wrote: > > > In any case I'm a bit surprised by people comparing Python to Swift at > > all, implying that Python would have worked just as well and Apple > > should have chosen it to replace Objective C. > > Because if you look at the spec, Swift is essentially a statically typed > Python. I guess I'm not following your argument. Are you saying Swift should adopted Python syntax (similar to the .net language Boo) or are you saying Apple should have adopted Python instead? > Swift and Python will also be used in the same niche. C will still be > used for low-level stuff. Swift is not a replacement for C. It's a > replacement for Objective-C. No they won't be used in the same niche. Objective C is certainly not used in the same niche as Python, so why would Swift? I don't expect to see any major OS X app written completely in Python, nor would I expect and of the core frameworks to be written in Python. They will be written in Swift however. > > Swift provides a cleaner system > > for developers to work in than Obj C did (which, by the way has > > reference counting), but carries on the same object model that > > developers are used to (and existing frameworks use). > > That is what PyObjC does as well. Not quite what I mean. As you said yourself, Swift is aiming to replace ObjC. Thus core system frameworks will slowly be replaced over time with frameworks written in Swift (binary, compiled frameworks). So you'll be using PySwift in the future instead of PyObjC, which should be an easy bridge to create since the object model is not changing.
[toc] | [prev] | [next] | [standalone]
| From | Mark H Harris <harrismh777@gmail.com> |
|---|---|
| Date | 2014-06-05 13:49 -0500 |
| Message-ID | <lmqe3k$i3f$1@speranza.aioe.org> |
| In reply to | #72734 |
On 6/5/14 12:18 PM, Michael Torrie wrote:
> No they won't be used in the same niche. Objective C is certainly not
> used in the same niche as Python, so why would Swift? I don't expect to
> see any major OS X app written completely in Python, nor would I expect
> and of the core frameworks to be written in Python. They will be
> written in Swift however.
>
OS X apps will indeed be written in Swift; esp if they will be
distributed from the Apple Store--- Python apps are streng verboten in
Apple land.
OTOH, much of my Python work is done on the mac for the mac... just
not distributed from the Apple Store.
OTOH, it only makes sense to code with Apple's tools if the app is
going to be Apple Store ready.
OTOH, I don't view the mac as an "Apple" thing. My mac is a *nix
clone (freeBSD variant) which is a stable platform for Python coding and
debug|test. I won't be using Swift; however, I will be using IDLE.
JFTR, Apple should have adopted Python3, IMHO.
marcus
[toc] | [prev] | [next] | [standalone]
| From | Travis Griggs <travisgriggs@gmail.com> |
|---|---|
| Date | 2014-06-05 23:28 -0700 |
| Message-ID | <mailman.10806.1402036090.18130.python-list@python.org> |
| In reply to | #72690 |
> On Jun 5, 2014, at 1:14, Alain Ketterlin <alain@dpt-info.u-strasbg.fr> wrote: > > 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. Except that while you don't need to regularly worry about cycles in python, you do in swift. Which means you get to think constantly about direct and indirect cycles, figure out where to put weak stuff, when to use a local to keep a weak property alive until it finds it's strong home, etc.
[toc] | [prev] | [next] | [standalone]
| From | Alain Ketterlin <alain@dpt-info.u-strasbg.fr> |
|---|---|
| Date | 2014-06-06 10:25 +0200 |
| Message-ID | <874mzyphpm.fsf@dpt-info.u-strasbg.fr> |
| In reply to | #72819 |
Travis Griggs <travisgriggs@gmail.com> writes: >> On Jun 5, 2014, at 1:14, Alain Ketterlin <alain@dpt-info.u-strasbg.fr> wrote: >> >> 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. > > Except that while you don't need to regularly worry about cycles in > python, you do in swift. Right. You can't just ignore cycle in Swift. > Which means you get to think constantly about direct and indirect > cycles, figure out where to put weak stuff, when to use a local to > keep a weak property alive until it finds it's strong home, etc. Well, I don't consider this a bad trade-off. Deciding which refs are weak and which are strong, or even designing an explicit deallocation strategy, are design decisions. -- Alain.
[toc] | [prev] | [next] | [standalone]
Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
Back to top | Article view | comp.lang.python
csiph-web