Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #39463 > unrolled thread
| Started by | Piterrr <piterrr.dolinski@gmail.com> |
|---|---|
| First post | 2013-02-21 13:26 -0800 |
| Last post | 2013-02-25 19:37 -0800 |
| Articles | 20 on this page of 161 — 34 participants |
Back to article view | Back to comp.lang.python
Python Newbie Piterrr <piterrr.dolinski@gmail.com> - 2013-02-21 13:26 -0800
Re: Python Newbie Ian Kelly <ian.g.kelly@gmail.com> - 2013-02-21 14:54 -0700
Re: Python Newbie MRAB <python@mrabarnett.plus.com> - 2013-02-21 21:58 +0000
Re: Python Newbie Chris Angelico <rosuav@gmail.com> - 2013-02-22 08:59 +1100
Re: Python Newbie Peter Pearson <ppearson@nowhere.invalid> - 2013-02-21 22:03 +0000
Re: Python Newbie Dave Angel <davea@davea.name> - 2013-02-21 17:22 -0500
Re: Python Newbie piterrr.dolinski@gmail.com - 2013-02-21 14:40 -0800
Re: Python Newbie Chris Angelico <rosuav@gmail.com> - 2013-02-22 10:21 +1100
Re: Python Newbie piterrr.dolinski@gmail.com - 2013-02-21 15:34 -0800
Re: Python Newbie Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-02-21 23:48 +0000
Re: Python Newbie Chris Angelico <rosuav@gmail.com> - 2013-02-22 11:32 +1100
Re: Python Newbie Michael Torrie <torriem@gmail.com> - 2013-02-23 11:58 -0700
Re: Python Newbie piterrr.dolinski@gmail.com - 2013-02-21 15:34 -0800
Re: Python Newbie Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-02-21 23:27 +0000
Re: Python Newbie Ian Kelly <ian.g.kelly@gmail.com> - 2013-02-21 16:55 -0700
Re: Python Newbie rusi <rustompmody@gmail.com> - 2013-02-21 22:57 -0800
Re: Python Newbie Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-02-22 10:26 +0000
Re: Python Newbie Steve Simmons <square.steve@gmail.com> - 2013-02-22 12:05 +0100
Re: Python Newbie Chris Angelico <rosuav@gmail.com> - 2013-02-22 22:23 +1100
Re: Python Newbie Michael Torrie <torriem@gmail.com> - 2013-02-23 16:04 -0700
Re: Python Newbie Vito De Tullio <vito.detullio@gmail.com> - 2013-02-24 09:23 +0100
Re: Python Newbie "J.R." <groups_jr-1@yahoo.com.br> - 2013-02-24 23:02 -0300
Re: Python Newbie Roy Smith <roy@panix.com> - 2013-02-24 21:03 -0500
Re: Python Newbie "J.R." <groups_jr-1@yahoo.com.br> - 2013-02-24 23:35 -0300
Re: Python Newbie Chris Angelico <rosuav@gmail.com> - 2013-02-25 13:31 +1100
Re: Python Newbie Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-02-21 19:35 -0500
Re: Python Newbie Mitya Sirenef <msirenef@lightbird.net> - 2013-02-21 23:50 -0500
Re: Python Newbie Rui Maciel <rui.maciel@gmail.com> - 2013-02-22 11:58 +0000
Re: Python Newbie Chris Angelico <rosuav@gmail.com> - 2013-02-22 23:12 +1100
Re: Python Newbie Rui Maciel <rui.maciel@gmail.com> - 2013-02-22 13:50 +0000
Re: Python Newbie Chris Angelico <rosuav@gmail.com> - 2013-02-23 01:05 +1100
Re: Python Newbie Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-02-23 00:03 +0000
Re: Python Newbie Chris Angelico <rosuav@gmail.com> - 2013-02-23 11:21 +1100
Re: Python Newbie Duncan Booth <duncan.booth@invalid.invalid> - 2013-02-22 14:26 +0000
Re: Python Newbie Steve Simmons <square.steve@gmail.com> - 2013-02-22 15:45 +0100
Re: Python Newbie Duncan Booth <duncan.booth@invalid.invalid> - 2013-02-22 15:02 +0000
Re: Python Newbie Chris Angelico <rosuav@gmail.com> - 2013-02-23 02:06 +1100
Re: Python Newbie piterrr.dolinski@gmail.com - 2013-02-22 13:37 -0800
Re: Python Newbie Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-02-22 22:08 +0000
Re: Python Newbie Ian Kelly <ian.g.kelly@gmail.com> - 2013-02-22 15:45 -0700
Re: Python Newbie piterrr.dolinski@gmail.com - 2013-02-22 15:38 -0800
Re: Python Newbie Chris Angelico <rosuav@gmail.com> - 2013-02-23 11:17 +1100
Re: Python Newbie Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-02-23 13:29 -0500
Re: Python Newbie Chris Angelico <rosuav@gmail.com> - 2013-02-24 08:38 +1100
Re: Python Newbie Michael Torrie <torriem@gmail.com> - 2013-02-23 15:52 -0700
Re: Python Newbie Chris Angelico <rosuav@gmail.com> - 2013-02-24 10:18 +1100
Re: Python Newbie piterrr.dolinski@gmail.com - 2013-02-23 15:46 -0800
Re: Python Newbie Larry Hudson <orgnut@yahoo.com> - 2013-02-23 20:20 -0800
Re: Python Newbie Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-02-24 14:34 +0000
Re: Python Newbie piterrr.dolinski@gmail.com - 2013-02-24 07:46 -0800
Re: Python Newbie Chris Angelico <rosuav@gmail.com> - 2013-02-25 02:52 +1100
Re: Python Newbie Roy Smith <roy@panix.com> - 2013-02-24 11:22 -0500
Re: Python Newbie Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-02-24 17:44 +0000
Re: Python Newbie piterrr.dolinski@gmail.com - 2013-02-24 11:29 -0800
Re: Python Newbie Joshua Landau <joshua.landau.ws@gmail.com> - 2013-02-24 21:35 +0000
Re: Python Newbie piterrr.dolinski@gmail.com - 2013-02-24 14:43 -0800
Re: Python Newbie Joel Goldstick <joel.goldstick@gmail.com> - 2013-02-24 18:05 -0500
Re: Python Newbie Joshua Landau <joshua.landau.ws@gmail.com> - 2013-02-24 23:13 +0000
Re: Python Newbie piterrr.dolinski@gmail.com - 2013-02-24 14:43 -0800
Re: Python Newbie Larry Hudson <orgnut@yahoo.com> - 2013-02-26 00:32 -0800
Re: Python Newbie rurpy@yahoo.com - 2013-02-26 10:23 -0800
Re: Python Newbie Ethan Furman <ethan@stoneleaf.us> - 2013-02-26 10:59 -0800
Re: Python Newbie rurpy@yahoo.com - 2013-02-26 13:30 -0800
Re: Python Newbie Michael Torrie <torriem@gmail.com> - 2013-02-24 18:31 -0700
Re: Python Newbie Chris Angelico <rosuav@gmail.com> - 2013-02-25 09:08 +1100
Re: Python Newbie Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-02-24 23:18 +0000
Re: Python Newbie Joshua Landau <joshua.landau.ws@gmail.com> - 2013-02-24 22:51 +0000
Re: Python Newbie piterrr.dolinski@gmail.com - 2013-02-24 15:38 -0800
Re: Python Newbie Chris Angelico <rosuav@gmail.com> - 2013-02-25 10:45 +1100
Re: Python Newbie Ethan Furman <ethan@stoneleaf.us> - 2013-02-24 15:53 -0800
Re: Python Newbie piterrr.dolinski@gmail.com - 2013-02-24 16:08 -0800
Re: Python Newbie Joshua Landau <joshua.landau.ws@gmail.com> - 2013-02-25 00:28 +0000
Re: Python Newbie Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-02-25 00:38 +0000
Re: Python Newbie Ethan Furman <ethan@stoneleaf.us> - 2013-02-24 16:33 -0800
Re: Python Newbie Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-02-25 00:45 +0000
Re: Python Newbie Roy Smith <roy@panix.com> - 2013-02-24 19:50 -0500
Re: Python Newbie Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-02-25 01:04 +0000
Re: Python Newbie Chris Angelico <rosuav@gmail.com> - 2013-02-25 12:27 +1100
Re: Python Newbie Michael Torrie <torriem@gmail.com> - 2013-02-24 18:42 -0700
Re: Python Newbie Chris Angelico <rosuav@gmail.com> - 2013-02-25 12:24 +1100
Re: Python Newbie Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-02-25 01:44 +0000
Re: Python Newbie Chris Angelico <rosuav@gmail.com> - 2013-02-25 12:53 +1100
Re: Python Newbie MRAB <python@mrabarnett.plus.com> - 2013-02-25 02:23 +0000
Re: Python Newbie Ethan Furman <ethan@stoneleaf.us> - 2013-02-24 18:59 -0800
Re: Python Newbie piterrr.dolinski@gmail.com - 2013-02-24 16:08 -0800
Re: Python Newbie Roy Smith <roy@panix.com> - 2013-02-24 19:42 -0500
Re: Python Newbie piterrr.dolinski@gmail.com - 2013-02-24 15:38 -0800
Re: Python Newbie Joshua Landau <joshua.landau.ws@gmail.com> - 2013-02-24 23:21 +0000
Re: Python Newbie Dave Angel <davea@davea.name> - 2013-02-24 17:47 -0500
Re: Python Newbie Serhiy Storchaka <storchaka@gmail.com> - 2013-02-25 14:40 +0200
Re: Python Newbie piterrr.dolinski@gmail.com - 2013-02-24 07:46 -0800
Re: Python Newbie Michael Torrie <torriem@gmail.com> - 2013-02-23 22:23 -0700
Re: Python Newbie MRAB <python@mrabarnett.plus.com> - 2013-02-24 00:11 +0000
Re: Python Newbie Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-02-24 12:37 -0500
Re: Python Newbie Michael Torrie <torriem@gmail.com> - 2013-02-24 10:56 -0700
Re: Python Newbie Roy Smith <roy@panix.com> - 2013-02-24 13:07 -0500
Re: Python Newbie Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-02-24 21:01 -0500
Re: Python Newbie piterrr.dolinski@gmail.com - 2013-02-22 15:38 -0800
Re: Python Newbie Terry Reedy <tjreedy@udel.edu> - 2013-02-22 20:04 -0500
Re: Python Newbie rurpy@yahoo.com - 2013-02-22 18:48 -0800
Re: Python Newbie Mitya Sirenef <msirenef@lightbird.net> - 2013-02-22 20:47 -0500
Re: Python Newbie Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-02-23 02:02 +0000
Re: Python Newbie Chris Angelico <rosuav@gmail.com> - 2013-02-23 13:18 +1100
Re: Python Newbie Grant Edwards <invalid@invalid.invalid> - 2013-02-24 18:19 +0000
Re: Python Newbie Chris Angelico <rosuav@gmail.com> - 2013-02-25 07:25 +1100
Re: Python Newbie Mitya Sirenef <msirenef@lightbird.net> - 2013-02-22 21:40 -0500
Re: Python Newbie Chris Angelico <rosuav@gmail.com> - 2013-02-23 13:48 +1100
Re: Python Newbie Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-02-23 02:59 +0000
Re: Python Newbie Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-02-23 13:34 -0500
Re: Python Newbie Chris Angelico <rosuav@gmail.com> - 2013-02-24 08:40 +1100
Re: Python Newbie Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-02-24 12:41 -0500
Re: Python Newbie Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-02-23 04:13 +0000
Re: Python Newbie Serhiy Storchaka <storchaka@gmail.com> - 2013-02-23 11:48 +0200
Re: Python Newbie Rui Maciel <rui.maciel@gmail.com> - 2013-02-23 12:30 +0000
Re: Python Newbie Steve Simmons <square.steve@gmail.com> - 2013-02-23 16:43 +0100
Re: Python Newbie jmfauth <wxjmfauth@gmail.com> - 2013-02-23 10:44 -0800
Re: Python Newbie Ian Kelly <ian.g.kelly@gmail.com> - 2013-02-23 12:13 -0700
Re: Python Newbie Ethan Furman <ethan@stoneleaf.us> - 2013-02-23 11:08 -0800
Re: Python Newbie jmfauth <wxjmfauth@gmail.com> - 2013-02-23 12:53 -0800
Re: Python Newbie Chris Angelico <rosuav@gmail.com> - 2013-02-24 08:48 +1100
Re: Python Newbie Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-02-24 00:02 +0000
Re: Python Newbie Michael Torrie <torriem@gmail.com> - 2013-02-23 12:16 -0700
Re: Python Newbie Matej Cepl <mcepl@redhat.com> - 2013-02-24 00:06 +0100
Re: Python Newbie Chris Angelico <rosuav@gmail.com> - 2013-02-24 02:51 +1100
Re: Python Newbie Matej Cepl <mcepl@redhat.com> - 2013-02-24 00:04 +0100
Re: Python Newbie Ethan Furman <ethan@stoneleaf.us> - 2013-02-23 08:32 -0800
Re: Python Newbie Steve Simmons <square.steve@gmail.com> - 2013-02-23 18:39 +0100
Re: Python Newbie Michael Torrie <torriem@gmail.com> - 2013-02-23 12:19 -0700
Re: Python Newbie Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-02-24 17:11 +0000
Re: Python Newbie piterrr.dolinski@gmail.com - 2013-02-24 11:40 -0800
Re: Python Newbie Mitya Sirenef <msirenef@lightbird.net> - 2013-02-24 15:06 -0500
Re: Python Newbie "Michael Ross" <gmx@ross.cx> - 2013-02-24 21:33 +0100
Re: Python Newbie MRAB <python@mrabarnett.plus.com> - 2013-02-24 20:34 +0000
Re: Python Newbie Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-02-24 20:41 +0000
Re: Python Newbie Ethan Furman <ethan@stoneleaf.us> - 2013-02-24 12:34 -0800
Re: Python Newbie Chris Angelico <rosuav@gmail.com> - 2013-02-25 07:42 +1100
Re: Python Newbie Roy Smith <roy@panix.com> - 2013-02-24 15:48 -0500
Re: Python Newbie Joshua Landau <joshua.landau.ws@gmail.com> - 2013-02-24 21:58 +0000
Re: Python Newbie Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-02-24 21:08 -0500
Re: Python Newbie Joshua Landau <joshua.landau.ws@gmail.com> - 2013-02-25 02:59 +0000
Re: Python Newbie Chris Angelico <rosuav@gmail.com> - 2013-02-25 07:47 +1100
Re: Python Newbie Chris Angelico <rosuav@gmail.com> - 2013-02-25 07:58 +1100
Re: Python Newbie Roy Smith <roy@panix.com> - 2013-02-24 16:08 -0500
Re: Python Newbie Chris Angelico <rosuav@gmail.com> - 2013-02-25 08:44 +1100
Re: Python Newbie Mitya Sirenef <msirenef@lightbird.net> - 2013-02-24 17:40 -0500
Re: Python Newbie Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-02-25 01:11 +0000
Re: Python Newbie Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-02-25 00:42 +0000
Re: Python Newbie Michael Torrie <torriem@gmail.com> - 2013-02-24 18:34 -0700
Re: Python Newbie Ethan Furman <ethan@stoneleaf.us> - 2013-02-24 14:33 -0800
Re: Python Newbie Albert Hopkins <marduk@letterboxes.org> - 2013-02-24 18:32 -0500
Re: Python Newbie Chris Angelico <rosuav@gmail.com> - 2013-02-25 10:44 +1100
Re: Python Newbie Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-02-25 01:06 +0000
Re: Python Newbie piterrr.dolinski@gmail.com - 2013-02-24 11:40 -0800
Re: Python Newbie piterrr.dolinski@gmail.com - 2013-02-22 13:37 -0800
Re: Python Newbie Mitya Sirenef <msirenef@lightbird.net> - 2013-02-22 20:05 -0500
Re: Python Newbie Gene Heskett <gheskett@wdtv.com> - 2013-02-23 12:32 -0500
Re: Python Newbie Steve Simmons <square.steve@gmail.com> - 2013-02-23 19:10 +0100
Re: Python Newbie Michael Torrie <torriem@gmail.com> - 2013-02-23 11:40 -0700
Re: Python Newbie Michael Torrie <torriem@gmail.com> - 2013-02-23 12:15 -0700
Re: Python Newbie Gene Heskett <gheskett@wdtv.com> - 2013-02-23 17:49 -0500
Re: Python Newbie Nick Mellor <thebalancepro@gmail.com> - 2013-02-25 19:37 -0800
Page 4 of 9 — ← Prev page 1 2 3 [4] 5 6 7 8 9 Next page →
| From | rurpy@yahoo.com |
|---|---|
| Date | 2013-02-26 10:23 -0800 |
| Message-ID | <5982329b-9127-4b26-a619-ccba94a441d0@googlegroups.com> |
| In reply to | #39937 |
On 02/26/2013 01:32 AM, Larry Hudson wrote: > On 02/24/2013 02:43 PM, piterrr.dolinski@gmail.com wrote: > <snip> >> ... But for the moment I am trying to imitate familiar ground. > <snip> > This is EXACTLY why you're having trouble grasping Python. Python is a different language and > requires a different mind-set and different approach. In this, it is NO different from ANY > other new (to you) programming language. No. Programming languages have far more in common with other languages than differences. This is particularly true of Python which has always seemed to me as a very well-selected compilation of existing programming language features rather than consisting of groundbreaking new concepts. > Of course, don't forget general programming principles -- how to approach a problem, how to > select algorithms, and such. These apply to any language, but the details of syntax and such > ARE different in different languages. Trying to apply these old details to a new language only > hinders your learning process, it definitely does NOT help. > > Actually, your comments and questions make me wonder HOW you are trying to learn Python. All > the things you're asking about are clearly and completely discussed in any decent book or > tutorial. It makes me speculate that you're simply trying to use a Python reference instead of > something that actually teaches anything. A reference may give you the rules and syntax, but > not much about how to apply them properly. That is sadly true of the Python reference manuals (Language and Library) but need not and should not be true in general. There is no reason why someone with basic programming experience in another similar language should not be able to learn a new language from its *well written* reference manuals. > Please think about finding some better fundamental material -- there is a LOT available. And > please quit trying to force Python to be something it isn't. That is never going to be > effective and definitely harmful to your learning. Part of learning, indeed much of the value in learning, a new language when one already knows several others, is mentally unifying the things that are similar in the old and new languages, and distinguishing what is different. You do NOT need to throw out everything you learned about those other language to learn new one. Thinking of the features of the new language in terms of the old one is a necessary part of this process. I still think in terms of C pointers when thinking about how Python references objects. The problem arises when when one assumes that syntax that looks similar *should* behave similarly. As for migrating idioms from the previous language to the new one, such as adding redundant parenthesis around the conditional expression in an "if" statement, I think it is relatively harmless. Contrary to previous claims, it will NOT result in an "unmaintainable mess". I doubt if any maintainabilty difference in such code could even be measured other than that caused by a prima-donna-ish "eew, I'm not going to work on that code because I think it is UGLY!" effect. Perhaps if we were talking about a program manager setting such idioms in stone for 100's of kilolines of code it would be different but for the OPs situation, I see no harm in it. If it helps the OP transition to python, then I say do it. For the record, I did much the same thing coming to Python from Perl. After a while I came to the common view that such parens were more noise than clarifying but I reached that conclusion based on my own experience rather than being bludgeoned into it by extreme predictions of doom read here. > <snip> >> I wanted Python to register what type of variable I'm after... > > Python variables do NOT have any data type. The objects they reference have data types. > Variables can be assigned and RE-assigned to any data type at any time. Again, I emphasize, > QUIT THINKING IN ANOTHER LANGUAGE, it simply doesn't work. You might like it if it were so, but > it simply does not match reality. I have no problem interpreting the OP's statement (as quoted above) as meaning that he wanted to use a Python variable to consistently reference a particular type and wanted a name that would remind him of that type.
[toc] | [prev] | [next] | [standalone]
| From | Ethan Furman <ethan@stoneleaf.us> |
|---|---|
| Date | 2013-02-26 10:59 -0800 |
| Message-ID | <mailman.2568.1361906260.2939.python-list@python.org> |
| In reply to | #39983 |
On 02/26/2013 10:23 AM, rurpy@yahoo.com wrote: > On 02/26/2013 01:32 AM, Larry Hudson wrote: >> Python variables do NOT have any data type. > > I have no problem interpreting the OP's statement > as meaning that he wanted to use a Python variable to > consistently reference a particular type and wanted a name > that would remind him of that type. Which is all well and good, so long as the OP also realizes that the name does not have any restriction's on it from Python's side, and certain functions will end up pointing the name at a different object with a possibly different type than his original, as in my int/float example. -- ~Ethan~
[toc] | [prev] | [next] | [standalone]
| From | rurpy@yahoo.com |
|---|---|
| Date | 2013-02-26 13:30 -0800 |
| Message-ID | <52f063c0-0998-4487-bd44-058f5e9fa63b@googlegroups.com> |
| In reply to | #39994 |
On Tuesday, February 26, 2013 11:59:51 AM UTC-7, Ethan Furman wrote: > On 02/26/2013 10:23 AM, rurpy@yahoo.com wrote: > > On 02/26/2013 01:32 AM, Larry Hudson wrote: > >> Python variables do NOT have any data type. > > I have no problem interpreting the OP's statement > > as meaning that he wanted to use a Python variable to > > consistently reference a particular type and wanted a name > > that would remind him of that type. > > Which is all well and good, so long as the OP also realizes > that the name does not have any restriction's on it from > Python's side, and certain functions will end up pointing > the name at a different object with a possibly different type > than his original, as in my int/float example. Which I presume he did, given that he responded to your post with: On Sunday, February 24, 2013 5:08:06 PM UTC-7, piterrr....@gmail.com wrote: [...] > Yes I did see that it is possible to redefine the type of a variable. > But I don't think I would ever do this intentionally; need to be really > careful with Python.
[toc] | [prev] | [next] | [standalone]
| From | Michael Torrie <torriem@gmail.com> |
|---|---|
| Date | 2013-02-24 18:31 -0700 |
| Message-ID | <mailman.2479.1361757249.2939.python-list@python.org> |
| In reply to | #39800 |
On 02/24/2013 03:43 PM, piterrr.dolinski@gmail.com wrote: > I wanted Python to register what type of variable I'm after. So I > init my vars accordingly, int might be 0, float 0.0 and string with > null, err... None. As several people on the list have pointed out, there are no variables in Python. Let me repeat that. There are no variables in python. Thus to say, x=5 does not tell anything about what x can represent in the future. It merely says that the *name* "x" is bound to the object, which happens to be an immutable integer object that represents 5. That 5 can never change. Ever. In the future you can assign x to another object, maybe the result of an expression. So none of what you did "initialializes" a "variable." Probably sounds like I'm just being pedantic, but if you can learn to see the wisdom and strengths of python's way of doing things you'll end up writing very rapid code and very correct code too. Python's type system is dynamic but it is, in fact, a strong type system. You can't just arbitrary convert an object from one type to another. The aspect of python that gives it so much power over statically-typed languages is that as long as a type supports the interface you want to work with, the type just doesn't matter. Nor should it. This allows tremendous code re-use. For example I can totally change out one object for another object of a completely different type and my algorithms and logic still work. It's similar to C# generics, but much more powerful. In Python, it's called duck-typing. It's a very powerful concept.
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2013-02-25 09:08 +1100 |
| Message-ID | <mailman.2444.1361743717.2939.python-list@python.org> |
| In reply to | #39777 |
On Mon, Feb 25, 2013 at 8:35 AM, Joshua Landau <joshua.landau.ws@gmail.com> wrote: > def solve_quadratic(a, b, c): > """Solve a quadratic equation of the form ax² + bx + c = 0 > > The result will be a tuple of the two results; the results can be equal if > the determinant is 0. > This supports imaginary results for if the determinant is negative.""" > ... > results = [top/(2*a) for top in fraction_tops] Yeah, I think we know which one is the more readable... Just to nit-pick a little though, that returns a list when its docstring says it'll return a tuple :) Other than that (which is probably better solved by changing the docs than the code), the only change I'd make would be to ditch the fraction_tops temporary (and to throw out some of the comments that serve only to reexpress the code that immediately follows them, though for a demo they're entirely appropriate). Even in a language with mandatory declarations, the code would look pretty similar: # Assume that the declaration 'complex' permits a float - otherwise you need a Pike-style piped declaration eg "float|complex" # Details elided for brevity, keep the docstring and comments from the above version list(complex) solve_quadratic(float a, float b, float c): float determinant = b**2 - 4*a*c complex sqrt_determinant = determinant ** 0.5 tuple(complex) squareroots = sqrt_determinant, -sqrt_determinant return [(-b + d)/(2*a) for top in squareroots] Variable names seldom if ever need to identify their types, if by "type" you mean what the language sees as a type. There are times when it's useful to adorn a variable name with a unit, perhaps (length_ft and height_m shouldn't be multiplied together), or some other special marker (a "tainted" flag on all data that's come from user input, and which therefore must not be executed or interpolated into SQL or anything), but this is a much higher level of abstraction. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Oscar Benjamin <oscar.j.benjamin@gmail.com> |
|---|---|
| Date | 2013-02-24 23:18 +0000 |
| Message-ID | <mailman.2453.1361747930.2939.python-list@python.org> |
| In reply to | #39777 |
On 24 February 2013 21:35, Joshua Landau <joshua.landau.ws@gmail.com> wrote: > > determinant = b**2 - 4*a*c It's called the discriminant. A determinant is something altogether different. Oscar
[toc] | [prev] | [next] | [standalone]
| From | Joshua Landau <joshua.landau.ws@gmail.com> |
|---|---|
| Date | 2013-02-24 22:51 +0000 |
| Message-ID | <mailman.2454.1361748026.2939.python-list@python.org> |
| In reply to | #39777 |
[Multipart message — attachments visible in raw view] — view raw
On 24 February 2013 22:08, Chris Angelico <rosuav@gmail.com> wrote: > On Mon, Feb 25, 2013 at 8:35 AM, Joshua Landau > <joshua.landau.ws@gmail.com> wrote: > > def solve_quadratic(a, b, c): > > """Solve a quadratic equation of the form ax² + bx + c = 0 > > > > The result will be a tuple of the two results; the results can be equal > if > > the determinant is 0. > > This supports imaginary results for if the determinant is negative.""" > > ... > > results = [top/(2*a) for top in fraction_tops] > > Yeah, I think we know which one is the more readable... Just to > nit-pick a little though, that returns a list when its docstring says > it'll return a tuple :) > Good catch. > Other than that (which is probably better solved by changing the docs > than the code), the only change I'd make would be to ditch the > fraction_tops temporary (and to throw out some of the comments that > serve only to reexpress the code that immediately follows them, though > for a demo they're entirely appropriate). > I knew someone would critique it. It's an exaggerated demo for foo's sake. Heck, who even uses a function like that (or uses unicode in comments :P)?
[toc] | [prev] | [next] | [standalone]
| From | piterrr.dolinski@gmail.com |
|---|---|
| Date | 2013-02-24 15:38 -0800 |
| Message-ID | <2e9471ad-8320-4f7f-80ba-cd5a7f8f013d@googlegroups.com> |
| In reply to | #39816 |
>> intX = 32 # decl + init int var > How is it not obvious that "intX" is an integer *without* the comment? Indeed the assignment is enough to deduce "intX" is an int. The comment is there to let me know it is unlikely intX appears earlier in the code. Please, let me do things my way until I find reasons to the contrary. Regarding my use of None to mean NULL, point taken to use "" instead. Peter
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2013-02-25 10:45 +1100 |
| Message-ID | <mailman.2459.1361749549.2939.python-list@python.org> |
| In reply to | #39819 |
On Mon, Feb 25, 2013 at 10:38 AM, <piterrr.dolinski@gmail.com> wrote: > >>> intX = 32 # decl + init int var >> How is it not obvious that "intX" is an integer *without* the comment? > > Indeed the assignment is enough to deduce "intX" is an int. The comment is there to let me know it is unlikely intX appears earlier in the code. Please, let me do things my way until I find reasons to the contrary. > > Regarding my use of None to mean NULL, point taken to use "" instead. It's worth noting that None does make a good rendition of "null-as-opposed-to-blank", for instance when you're fetching data from an VARCHAR field in an SQL database. You'd use a string for anything that isn't NULL, and None for the others. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Ethan Furman <ethan@stoneleaf.us> |
|---|---|
| Date | 2013-02-24 15:53 -0800 |
| Message-ID | <mailman.2461.1361749985.2939.python-list@python.org> |
| In reply to | #39819 |
On 02/24/2013 03:38 PM, piterrr.dolinski@gmail.com wrote: > >>> intX = 32 # decl + init int var >> How is it not obvious that "intX" is an integer *without* the comment? > > Indeed the assignment is enough to deduce "intX" is an int. The comment is there to let me know it is unlikely intX appears earlier in the code. Please, let me do things my way until I find reasons to the contrary. Of course you can, but wouldn't you rather find reasons to the contrary by us telling you, instead of tripping over something yourself? For example (I believe it's already been mentioned) "declaring" intX with some integer value does *nothing* to maintain X as an integer: --> intX = 32 --> intX = intX / 3.0 --> intX 10.6666666666 -- ~Ethan~
[toc] | [prev] | [next] | [standalone]
| From | piterrr.dolinski@gmail.com |
|---|---|
| Date | 2013-02-24 16:08 -0800 |
| Message-ID | <da0ec7a1-decd-4cfb-9a0b-5722879f5864@googlegroups.com> |
| In reply to | #39824 |
> For example (I believe it's already been mentioned) "declaring" intX with some integer value does *nothing* to maintain > > X as an integer: > > --> intX = 32 > > --> intX = intX / 3.0 > > --> intX > > 10.6666666666 > Yes I did see that it is possible to redefine the type of a variable. But I don't think I would ever do this intentionally; need to be really careful with Python. Peter
[toc] | [prev] | [next] | [standalone]
| From | Joshua Landau <joshua.landau.ws@gmail.com> |
|---|---|
| Date | 2013-02-25 00:28 +0000 |
| Message-ID | <mailman.2464.1361752168.2939.python-list@python.org> |
| In reply to | #39826 |
[Multipart message — attachments visible in raw view] — view raw
On 25 February 2013 00:08, <piterrr.dolinski@gmail.com> wrote: > > For example (I believe it's already been mentioned) "declaring" intX > with some integer value does *nothing* to maintain > > > > X as an integer: > > > > --> intX = 32 > > > > --> intX = intX / 3.0 > > > > --> intX > > > > 10.6666666666 > > > > Yes I did see that it is possible to redefine the type of a variable. But > I don't think I would ever do this intentionally; need to be really careful > with Python. Not necessarily. Python duck types. If you don't know what that means, Google's got a ton on it. Take a look at my really bad quadratic equation solver. It supports integer input, float input and complex input. It will output a list of two floats or complex numbers. That's a use for having one variable have different types. You'll find thousands of parallels in real, working code. Hence, you don't really need to be careful. You'd probably benefit if you stopped thinking of supporting type-changing as "dangerous" and started thinking of it as "useful".
[toc] | [prev] | [next] | [standalone]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2013-02-25 00:38 +0000 |
| Message-ID | <mailman.2466.1361752662.2939.python-list@python.org> |
| In reply to | #39826 |
On 25/02/2013 00:08, piterrr.dolinski@gmail.com wrote: >> For example (I believe it's already been mentioned) "declaring" intX with some integer value does *nothing* to maintain >> >> X as an integer: >> >> --> intX = 32 >> >> --> intX = intX / 3.0 >> >> --> intX >> >> 10.6666666666 >> > > Yes I did see that it is possible to redefine the type of a variable. But I don't think I would ever do this intentionally; need to be really careful with Python. > > Peter > Yes this is a big downside with Python. Sadly it means us poor Python programmers have to waste a lot of time and effort testing our code, unlike those who use statically typed languages which work perfectly once they've been compiled. -- Cheers. Mark Lawrence
[toc] | [prev] | [next] | [standalone]
| From | Ethan Furman <ethan@stoneleaf.us> |
|---|---|
| Date | 2013-02-24 16:33 -0800 |
| Message-ID | <mailman.2467.1361752931.2939.python-list@python.org> |
| In reply to | #39826 |
On 02/24/2013 04:08 PM, piterrr.dolinski@gmail.com wrote: >> For example (I believe it's already been mentioned) "declaring" intX with some integer value does *nothing* to maintain >> >> X as an integer: >> >> --> intX = 32 >> >> --> intX = intX / 3.0 >> >> --> intX >> >> 10.6666666666 >> > > Yes I did see that it is possible to redefine the type of a variable. And that right there is one of the key aspects of Python: there are no variables, only objects, and objects' types cannot be changed. objects can be labeled with names, but the names are more like sticky notes, and can be peeled off and stuck on some other object. -- ~Ethan~
[toc] | [prev] | [next] | [standalone]
| From | Oscar Benjamin <oscar.j.benjamin@gmail.com> |
|---|---|
| Date | 2013-02-25 00:45 +0000 |
| Message-ID | <mailman.2468.1361753132.2939.python-list@python.org> |
| In reply to | #39826 |
On 25 February 2013 00:08, <piterrr.dolinski@gmail.com> wrote: Chris Angelico wrote: >> For example (I believe it's already been mentioned) "declaring" intX with some integer value does *nothing* to maintain >> >> X as an integer: >> >> --> intX = 32 >> >> --> intX = intX / 3.0 >> >> --> intX >> >> 10.6666666666 >> > > Yes I did see that it is possible to redefine the type of a variable. But I don't think I would ever do this intentionally; need to be really careful with Python. You do need to be careful around types in Python (as in all languages). It took some time for me to understand how to use types in Python. After a while I came to realise that not knowing exactly the type of a particular object is not as much of a problem as I initially thought. Once you understand how to use this ambiguity to your advantage it becomes possible to write very flexible code that can be reused without ambiguity in situations that you haven't yet anticipated. The key mental hurdle, I think, is to realise that instead of relying on compilation errors to spot (a small subset of) your programming errors, you are relying on runtime exceptions. Python still gives errors when you use an object in a way that is inconsistent with its type; you just don't see those errors at compile time. The trickier cases are ones where two types are very similar and can be used similarly in most, but not all, situations. An example of this would be the one that Chris has highlighted where an object that you expected to be an int is actually a float. I find that I need to be careful when using division on quantities that I expected to be integers (true in all languages) and careful about the notation used in a numeric literal. Once you get used to it, you will find it easy to see that the '.0' that Chris appended was deliberate in order to control the type of the resulting object. Oscar
[toc] | [prev] | [next] | [standalone]
| From | Roy Smith <roy@panix.com> |
|---|---|
| Date | 2013-02-24 19:50 -0500 |
| Message-ID | <roy-453BB0.19502224022013@news.panix.com> |
| In reply to | #39826 |
In article <da0ec7a1-decd-4cfb-9a0b-5722879f5864@googlegroups.com>, piterrr.dolinski@gmail.com wrote: > Yes I did see that it is possible to redefine the type of a variable. But I > don't think I would ever do this intentionally One does not need language features to protect themselves against things they do intentionally. They need language features to protect themselves against things they do by accident. Different languages protect you from different things. Compare, for example, C++ and Python. C++ protects you against accidentally passing an int where you were supposed to pass a float. Well, no, with automatic type promotion, that's a bad example. But it does prevent you from passing an IntThing where you were supposed to pass a FloatThing (assuming IntThing is not a subclass of FloatThing, and a few other details). But, Python protects you from dereferencing a null pointer, or double-freeing a pointer. There's just no way to even write those concepts in Python. You pays your money and you takes your chances. Pick which type of protection you feel is more important and use the language which gives you that. > need to be really careful with Python. You need to be really careful with all programming languages. You just need to be careful about different things.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2013-02-25 01:04 +0000 |
| Message-ID | <512ab8aa$0$29998$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #39826 |
On Sun, 24 Feb 2013 16:08:06 -0800, piterrr.dolinski wrote: >> For example (I believe it's already been mentioned) "declaring" intX >> with some integer value does *nothing* to maintain >> >> X as an integer: >> >> --> intX = 32 >> >> --> intX = intX / 3.0 >> >> --> intX >> >> 10.6666666666 >> >> > Yes I did see that it is possible to redefine the type of a variable. Variables do not have types in Python. Reset your thinking. Python is a dynamic language with name bindings and strongly-typed objects, not a static language with strongly-typed variables. If you don't understand the difference, ask. But so long as you make the wrong assumptions about the language, you will have a bad time. You will find programming much easier, and more pleasant, if you learn the semantics and idioms of the language you are using, instead of trying to treat every language as the same. > But I don't think I would ever do this intentionally; need to be really > careful with Python. Not at all. The only difference is whether you get a compiler error or a runtime error. Instead of: 10 Write code. 20 Compile. 30 If compiler error, GO TO 10. 40 REM code compiles, but it still needs to be tested 50 Test code. 60 If error, GO TO 10. 70 Deploy. we have: 10 Write code. 20 Test code. 30 If error, GO TO 10. 40 Deploy. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2013-02-25 12:27 +1100 |
| Message-ID | <mailman.2472.1361755679.2939.python-list@python.org> |
| In reply to | #39844 |
On Mon, Feb 25, 2013 at 12:04 PM, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote: > Not at all. The only difference is whether you get a compiler error or a > runtime error. Instead of: > > 10 Write code. > 20 Compile. > 30 If compiler error, GO TO 10. > 40 REM code compiles, but it still needs to be tested > 50 Test code. > 60 If error, GO TO 10. > 70 Deploy. > > we have: > > 10 Write code. > 20 Test code. > 30 If error, GO TO 10. > 40 Deploy. The advantage of compile-time errors is that you don't have to wait for *that branch* to be executed. So they're hugely advantageous when it comes to the "obvious problems" like syntactic errors... and looky here, Python does exactly that :) The only difference between "static" and "dynamic" is how much is done at each phase. If your program has no inputs or side effects, the compiler could theoretically convert it into a single static output statement. Voila! All your run-time errors have become compile-time errors. Conversely, you could compile your application from source just before running it. Voila! Everything's a run-time error, even the omission of a semicolon in C. Okay, both of those are pretty stupid examples, but there's really no fundamental difference. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Michael Torrie <torriem@gmail.com> |
|---|---|
| Date | 2013-02-24 18:42 -0700 |
| Message-ID | <mailman.2476.1361756531.2939.python-list@python.org> |
| In reply to | #39844 |
On 02/24/2013 06:04 PM, Steven D'Aprano wrote: > Variables do not have types in Python. > > Reset your thinking. Python is a dynamic language with name bindings and > strongly-typed objects, not a static language with strongly-typed > variables. If you don't understand the difference, ask. But so long as > you make the wrong assumptions about the language, you will have a bad > time. Yes, but according to my computer language theory class, strictly speaking, python has no variables, only names and objects, which for the most part aren't mutable. A variable by definition is a box in memory that you can write to. The closest thing python has to that are instances of mutable types like a list. "a=5" certainly doesn't allocate a box in memory somewhere and stick 5 in it. And then later "a += 1" or "a=6" doesn't mutate the value stored in the box represented by a. Instead it allocates a new object and makes a refer to that new object. I know all this is what you meant, but with the original poster's frustrations with python, it's important that he just throw out the notion of variations entirely because sooner or later that will get him in trouble here, like if he tries to make an empty list be a default value for a function parameter.
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2013-02-25 12:24 +1100 |
| Message-ID | <mailman.2471.1361755486.2939.python-list@python.org> |
| In reply to | #39826 |
On Mon, Feb 25, 2013 at 11:45 AM, Oscar Benjamin <oscar.j.benjamin@gmail.com> wrote: > On 25 February 2013 00:08, <piterrr.dolinski@gmail.com> wrote: > Chris Angelico wrote: >>> For example (I believe it's already been mentioned) "declaring" intX with some integer value does *nothing* to maintain >>> >>> X as an integer: >>> >>> --> intX = 32 >>> >>> --> intX = intX / 3.0 >>> >>> --> intX >>> >>> 10.6666666666 >>> >> >> Yes I did see that it is possible to redefine the type of a variable. But I don't think I would ever do this intentionally; need to be really careful with Python. > The trickier cases are ones where two types are very similar and can > be used similarly in most, but not all, situations. An example of this > would be the one that Chris has highlighted where an object that you > expected to be an int is actually a float. I find that I need to be > careful when using division on quantities that I expected to be > integers (true in all languages) and careful about the notation used > in a numeric literal. Once you get used to it, you will find it easy > to see that the '.0' that Chris appended was deliberate in order to > control the type of the resulting object. Once again, Ethan gets the short end of the citations stick... 'twarn't me wrote that, he did. Not that it's at all contrary to my views, and I might well have said it if he hadn't, but credit should go his direction :) Note though that in Python 3, you don't need the explicit .0 to force it to float (and __future__ can bring that to Python 2 too). 32/3 -> 10.66666, int/int->float. ChrisA
[toc] | [prev] | [next] | [standalone]
Page 4 of 9 — ← Prev page 1 2 3 [4] 5 6 7 8 9 Next page →
Back to top | Article view | comp.lang.python
csiph-web