On Sun, 26 Aug 2012 16:12:40 -0400, Dennis Lee Bieber wrote:
> On 26 Aug 2012 13:43:33 GMT, Steven D'Aprano
> declaimed the following in
> gmane.comp.python.general:
>
>
>
>> (In some older versions of Python, wildcard imports are allowed, and
>> the function then falls back on a namespace ins
On Mon, 27 Aug 2012 00:54:05 +1000, Chris Angelico wrote:
> On Mon, Aug 27, 2012 at 12:18 AM, Steven D'Aprano
> wrote:
>> Also, built-ins require a name lookup too. As you point out, locals are
>> special, but Python will search an arbitrarily deep set of nested
>> nonlocal scopes, then globals,
On Mon, Aug 27, 2012 at 12:18 AM, Steven D'Aprano
wrote:
> Also, built-ins require a name lookup too. As you point out, locals are
> special, but Python will search an arbitrarily deep set of nested
> nonlocal scopes, then globals, then builtins.
Ah, builtins, forgot that. So yes, global scope in
On Sun, 26 Aug 2012 23:58:31 +1000, Chris Angelico wrote:
> On Sun, Aug 26, 2012 at 11:43 PM, Steven D'Aprano
> wrote:
>> It gets worse: Python has multiple namespaces that are searched.
>>
>> "Go to the Excelsior Hotel and ask the concierge for Mr Smith. If Mr
>> Smith isn't staying there, go ac
On Mon, Aug 27, 2012 at 12:02 AM, Roy Smith wrote:
> In article <503a2804$0$6574$c3e8da3$54964...@news.astraweb.com>,
> Steven D'Aprano wrote:
>
The mapping of name:address is part of the *compilation* process --
the compiler knows that variable 'x' corresponds to location
1234567
On Mon, Aug 27, 2012 at 12:02 AM, Mark Lawrence wrote:
> On 26/08/2012 14:34, Chris Angelico wrote:
>>
>> Okay, that may be a bit of a fairy tale ending and completely illogical.
>>
>> ChrisA
>
> Then stick to the thread about flexible string representation, unicode and
> typography :)
Hehe. Prob
In article <503a2804$0$6574$c3e8da3$54964...@news.astraweb.com>,
Steven D'Aprano wrote:
>>> The mapping of name:address is part of the *compilation* process --
>>> the compiler knows that variable 'x' corresponds to location
>>> 12345678
Just to pick a nit, the compiler probably doesn't know
On 26/08/2012 14:34, Chris Angelico wrote:
Okay, that may be a bit of a fairy tale ending and completely illogical.
ChrisA
Then stick to the thread about flexible string representation, unicode
and typography :)
--
Cheers.
Mark Lawrence.
--
http://mail.python.org/mailman/listinfo/python
On Sun, Aug 26, 2012 at 11:43 PM, Steven D'Aprano
wrote:
> It gets worse: Python has multiple namespaces that are searched.
>
> "Go to the Excelsior Hotel and ask the concierge for Mr Smith. If Mr
> Smith isn't staying there, go across the road to the Windsor Hotel and
> ask there. If he's not the
On Sun, 26 Aug 2012 00:45:55 -0500, Evan Driscoll wrote:
> On 08/24/2012 05:00 AM, Steven D'Aprano wrote:
>> No. The compiler remembers the address of 'a' by keeping notes about it
>> somewhere in memory during the compilation process. When you run the
>> compiled program, there is no longer any r
In article ,
Chris Angelico wrote:
> On Sun, Aug 26, 2012 at 3:45 PM, Evan Driscoll wrote:
> > Third, and more wackily, you could technically create a C implementation
> > that works like Python, where it stores variables (whose addresses aren't
> > taken) in a dict keyed by name, and generates
On Sun, Aug 26, 2012 at 10:02 PM, Steven D'Aprano
wrote:
> On Sun, 26 Aug 2012 16:22:05 +1000, Chris Angelico wrote:
>
>> On Sun, Aug 26, 2012 at 3:45 PM, Evan Driscoll
>> wrote:
>>> Third, and more wackily, you could technically create a C
>>> implementation that works like Python, where it stor
On Sun, 26 Aug 2012 16:22:05 +1000, Chris Angelico wrote:
> On Sun, Aug 26, 2012 at 3:45 PM, Evan Driscoll
> wrote:
>> Third, and more wackily, you could technically create a C
>> implementation that works like Python, where it stores variables (whose
>> addresses aren't taken) in a dict keyed by
On Sun, Aug 26, 2012 at 3:45 PM, Evan Driscoll wrote:
> Third, and more wackily, you could technically create a C implementation
> that works like Python, where it stores variables (whose addresses aren't
> taken) in a dict keyed by name, and generates code that on a variable access
> looks up the
Jan Kuiken於 2012年8月24日星期五UTC+8上午2時02分00秒寫道：
> On 8/23/12 06:11 , Steven D'Aprano wrote:
>
>
>
> >> 2) Related to the above, you can infinitely nest scopes. There's nothing
>
> >> wrong with having six variables called 'q'; you always use the innermost
>
> >> one. Yes, this can hurt readability
On 08/24/2012 05:00 AM, Steven D'Aprano wrote:
No. The compiler remembers the address of 'a' by keeping notes about it
somewhere in memory during the compilation process. When you run the
compiled program, there is no longer any reference to the name 'a'.
...
The mapping of name:address is part
On 08/24/2012 10:04 PM, Steven D'Aprano wrote:
The fact that the end result is the same is hardly surprising -- Python's
VM is built on top of C pointer indirection, so of course you can start
with pointers and end up with Python semantics. But the practice of
coding are very different:
* in C,
On Sun, Aug 26, 2012 at 5:56 AM, Dennis Lee Bieber
wrote:
> On Sat, 25 Aug 2012 09:55:27 +0100, Mark Lawrence
> declaimed the following in
> gmane.comp.python.general:
>
>>
>> I'm just wondering out aloud if the number of times this type of thread
>> has been debated here will fit into a Python l
On 25/08/2012 11:23, Chris Angelico wrote:
On Sat, Aug 25, 2012 at 6:55 PM, Mark Lawrence wrote:
I'm just wondering out aloud if the number of times this type of thread has
been debated here will fit into a Python long or float?
Well, when I have to store currency information, I like to store
On Sat, Aug 25, 2012 at 6:55 PM, Mark Lawrence wrote:
> I'm just wondering out aloud if the number of times this type of thread has
> been debated here will fit into a Python long or float?
Well, when I have to store currency information, I like to store it as
an integer, using the native currenc
On 25/08/2012 07:34, Chris Angelico wrote:
On Sat, Aug 25, 2012 at 1:04 PM, Steven D'Aprano
I'm just wondering out aloud if the number of times this type of thread
has been debated here will fit into a Python long or float?
--
Cheers.
Mark Lawrence.
--
http://mail.python.org/mailman/listin
On Sat, Aug 25, 2012 at 1:04 PM, Steven D'Aprano
wrote:
> You're confusing two different levels of explanation here. On the one
> hand, you're talking about C semantics, where you are explicitly
> responsible for managing unnamed data via indirection (pointers).
> Typically, the *pointers* get giv
On Fri, 24 Aug 2012 08:00:59 +1000, Chris Angelico wrote:
> On Fri, Aug 24, 2012 at 3:56 AM, Steven D'Aprano
> wrote:
>> But name bindings are a kind of variable. Named memory locations are a
>> *different* kind of variable. The behaviour of C variables and Python
>> variables do not follow the L
On Fri, Aug 24, 2012 at 11:27 PM, Grant Edwards wrote:
> Ah, but as we are always fond of saying in this group "that's an
> implementation detail, and not part of the language definition". The
> model where a compiler is "keeping notes about it in Narnia" is also
> perfectly valid. However, RAM i
On 2012-08-24, Steven D'Aprano wrote:
> On Fri, 24 Aug 2012 04:14:27 -0500, Evan Driscoll wrote:
>
>> On 8/23/2012 22:17, alex23 wrote:
>>> But Roy's point was that referring to 'a' as a 'variable' makes no
>>> sense, as it's not an allocated piece of memory.
>>
>> Does the computer just remember
On 23.08.2012 20:30, Dennis Lee Bieber wrote:
> On Thu, 23 Aug 2012 15:33:33 +1000, Chris Angelico
> declaimed the following in gmane.comp.python.general:
>> x = 1;
>>
>> In C, this means: Assign the integer 1 to the variable x (possibly
>> with implicit type casting, eg to floating point).
>>
>
On Fri, Aug 24, 2012 at 7:14 PM, Evan Driscoll wrote:
> On 8/23/2012 22:17, alex23 wrote:
> > But Roy's point was that referring to 'a' as a 'variable' makes no
> > sense, as it's not an allocated piece of memory.
>
> Does the computer just remember what 'a' refers to by keeping notes
> about it
On Thu, 23 Aug 2012 20:36:27 -0400, Roy Smith wrote:
> The id has changed! Now, we all know that the id of an object is its
> memory address (that's not guaranteed, but in the standard C
> implementation of Python, that's what it is).
It's not only "not guaranteed", it is *explicitly* noted as a
On Fri, 24 Aug 2012 04:14:27 -0500, Evan Driscoll wrote:
> On 8/23/2012 22:17, alex23 wrote:
>> But Roy's point was that referring to 'a' as a 'variable' makes no
>> sense, as it's not an allocated piece of memory.
>
> Does the computer just remember what 'a' refers to by keeping notes
> about it
On 8/23/2012 22:17, alex23 wrote:
> But Roy's point was that referring to 'a' as a 'variable' makes no
> sense, as it's not an allocated piece of memory.
Does the computer just remember what 'a' refers to by keeping notes
about it in Narnia?
Put it this way. If C removed the & operator -- and thu
On 24-08-12 09:38, Antoon Pardon wrote:
> On 23-08-12 01:58, Ben Finney wrote:
>
>> You haven't discovered anything about types; what you have discovered is
>> that Python name bindings are not variables.
>>
>> In fact, Python doesn't have variables – not as C or Java programmers
>> would unders
On 23-08-12 01:58, Ben Finney wrote:
>
> You haven't discovered anything about types; what you have discovered is
> that Python name bindings are not variables.
>
> In fact, Python doesn't have variables – not as C or Java programmers
> would understand the term. What it has instead are references
On Aug 24, 11:34 am, Chris Angelico wrote:
> On Fri, Aug 24, 2012 at 10:36 AM, Roy Smith wrote:
> > Even id() thinks they're the same thing:
> id(a)
> > 1755402140
> id(globals()["a"])
> > 1755402140
>
> Ah, no. What you have there is actually id(4) and nothing to do with a at all.
Wel
On Fri, Aug 24, 2012 at 10:36 AM, Roy Smith wrote:
> In fact, I can even write it that way and everything works:
>
globals()["a"] = 42
a
> 42
>
> Even id() thinks they're the same thing:
>
id(a)
> 1755402140
id(globals()["a"])
> 1755402140
Ah, no. What you have there is actual
In article ,
Evan Driscoll wrote:
> > In fact, Python doesn't have variables not as C or Java programmers
> > would understand the term. What it has instead are references to objects
> > (with names as one kind of reference).
>
> OK, I've seen this said a few times, and I have to ask: what do
On Fri, Aug 24, 2012 at 9:54 AM, Dennis Lee Bieber
wrote:
> On Fri, 24 Aug 2012 08:00:59 +1000, Chris Angelico
> declaimed the following in gmane.comp.python.general:
>
>>
>> But again, that probably doesn't help explain the variables. Unless
>> you've come from (or can at least imagine) an envir
Steven D'Aprano writes:
> No offence to Ben Finney, but I think sometimes he's a bit too eager
> to emphasise the subtle differences between Python and other
> languages, rather than the similarities.
No offense taken.
> Again, context is important:
Indeed. Note that my assertion was in respon
On Fri, Aug 24, 2012 at 3:56 AM, Steven D'Aprano
wrote:
> But name bindings are a kind of variable. Named memory locations are a
> *different* kind of variable. The behaviour of C variables and Python
> variables do not follow the Liskov Substitution Principle -- you can't
> rip out the entire "na
On 8/23/12 20:17 , Ian Kelly wrote:
...
Well, there you go. There *is* something wrong with having six variables
called 'q'.
Sometimes you don't want only six variables called 'q' but a hundred
of them :-)
def fac(q):
if q < 1 :
return 1
else:
return q
On Thu, Aug 23, 2012 at 12:02 PM, Jan Kuiken wrote:
> On 8/23/12 06:11 , Steven D'Aprano wrote:
>
>>> 2) Related to the above, you can infinitely nest scopes. There's nothing
>>> wrong with having six variables called 'q'; you always use the innermost
>>> one. Yes, this can hurt readability
>>
>>
On 8/23/12 06:11 , Steven D'Aprano wrote:
2) Related to the above, you can infinitely nest scopes. There's nothing
wrong with having six variables called 'q'; you always use the innermost
one. Yes, this can hurt readability
Well, there you go. There *is* something wrong with having six variabl
On 23/08/12 17:44, Evan Driscoll wrote:
On 08/23/2012 04:19 AM, lipska the kat wrote:
Well we don't want to turn this into a language comparison thread do we,
that might upset too many people but I can't remember ever writing a
method that took an Object as argument, you just can't do that much
On Thu, 23 Aug 2012 12:17:03 -0500, Evan Driscoll wrote:
> I definitely *wouldn't* say "Python
> classes aren't really classes" -- even though (I assert) Python classes
> are *far* further from Simula-style (/Java/C++) classes than Python
> variables are from Java variables.
Well, Python classes
On 8/23/2012 10:43 AM, Jerry Hill wrote:
Personally, when I was learning python I found the idea of python
having names and values (rather than variables and references) to
clear up a lot of my misconceptions of the python object model. I
think it's done the same for other people too, especiall
[I have some things to say to a few people so I'm just putting it all in
one rather than clutter up your email box even more.]
On 08/23/2012 12:33 AM, Chris Angelico wrote:
> [Snip discussion on names vs variables]
>
> Does that sort things out, or just make things more confusing?
>
> ChrisA
I...
On Aug 23, 9:34 am, Steven D'Aprano wrote:
> On Wed, 22 Aug 2012 18:46:43 +0100, lipska the kat wrote:
> > We need to separate out the 'view' from the 'implementation' here. Most
> > developers I know, if looking at the code and without the possibly
> > dubious benefit of knowing that in Python 'e
On 08/23/2012 04:19 AM, lipska the kat wrote:
> Well we don't want to turn this into a language comparison thread do we,
> that might upset too many people but I can't remember ever writing a
> method that took an Object as argument, you just can't do that much with
> an Object.
In the pre-Java-1.
On Thu, Aug 23, 2012 at 4:59 AM, Jussi Piitulainen
wrote:
> I don't get it either. To me the python-has-no-variables campaigners
> seem confused. As far as I can see, Python can be seen in terms of
> variables bound to (locations containing) values perfectly well, in a
> way that should be quite f
On 23/08/12 14:59, Ben Finney wrote:
lipska the kat writes:
On 23/08/12 05:14, Steven D'Aprano wrote:
I think that's uncalled for.
[…]
Excellent advice as usual, but I'm more than capable of looking after
myself thank you.
As is usual, it's not all about you; Steven is demonstrating that
lipska the kat writes:
> On 23/08/12 14:59, Ben Finney wrote:
> > lipska the kat writes:
> >
> >> On 23/08/12 05:14, Steven D'Aprano wrote:
> >>> I think that's uncalled for.
> > […]
> >
> >> Excellent advice as usual, but I'm more than capable of looking after
> >> myself thank you.
> >
> > As
lipska the kat writes:
> On 23/08/12 05:14, Steven D'Aprano wrote:
> > I think that's uncalled for.
[…]
> Excellent advice as usual, but I'm more than capable of looking after
> myself thank you.
As is usual, it's not all about you; Steven is demonstrating that we
require civil behaviour here,
On 23/08/2012 09:59, Jussi Piitulainen wrote:
Steven D'Aprano writes:
On Wed, 22 Aug 2012 23:49:17 -0500, Evan Driscoll wrote:
> On 8/22/2012 18:58, Ben Finney wrote:
>> You haven't discovered anything about types; what you have
>> discovered is that Python name bindings are not variables.
>>
>
On 22/08/12 22:31, Evan Driscoll wrote:
On 08/22/2012 02:45 PM, lipska the kat wrote:
On 22/08/12 20:03, Evan Driscoll wrote:
Second, this concept isn't *so* unfamiliar to you. If I give you the
following Java code:
void foo(Object o) { ... }
looking at this method declaration I can see
Steven D'Aprano writes:
> On Wed, 22 Aug 2012 23:49:17 -0500, Evan Driscoll wrote:
>
> > On 8/22/2012 18:58, Ben Finney wrote:
> >> You haven't discovered anything about types; what you have
> >> discovered is that Python name bindings are not variables.
> >>
> >> In fact, Python doesn't have var
On 23/08/12 05:14, Steven D'Aprano wrote:
On Thu, 23 Aug 2012 01:19:49 +, Walter Hurry wrote:
On Wed, 22 Aug 2012 18:46:43 +0100, lipska the kat wrote:
Well I'm a beginner
Then maybe you should read more and write less.
I think that's uncalled for. Lipska isn't trolling. He's making
o
On 23/08/12 02:19, Walter Hurry wrote:
On Wed, 22 Aug 2012 18:46:43 +0100, lipska the kat wrote:
Well I'm a beginner
Then maybe you should read more and write less.
Really ? I read all the responses to my posts and learn more from them
in less time than I ever have from reading the 'docume
On Wed, 22 Aug 2012 23:49:17 -0500, Evan Driscoll wrote:
> On 8/22/2012 18:58, Ben Finney wrote:
>> You haven't discovered anything about types; what you have discovered
>> is that Python name bindings are not variables.
>>
>> In fact, Python doesn't have variables – not as C or Java programmers
On Thu, Aug 23, 2012 at 2:49 PM, Evan Driscoll wrote:
> On 8/22/2012 18:58, Ben Finney wrote:
>> You haven't discovered anything about types; what you have discovered is
>> that Python name bindings are not variables.
>>
>> In fact, Python doesn't have variables – not as C or Java programmers
>> w
On Thu, Aug 23, 2012 at 2:11 PM, Steven D'Aprano
wrote:
> On Thu, 23 Aug 2012 12:02:16 +1000, Chris Angelico wrote:
>
>> 2) Related to the above, you can infinitely nest scopes. There's nothing
>> wrong with having six variables called 'q'; you always use the innermost
>> one. Yes, this can hurt r
On 8/22/2012 18:58, Ben Finney wrote:
> You haven't discovered anything about types; what you have discovered is
> that Python name bindings are not variables.
>
> In fact, Python doesn't have variables – not as C or Java programmers
> would understand the term. What it has instead are references
On Wed, 22 Aug 2012 18:46:43 +0100, lipska the kat wrote:
> We need to separate out the 'view' from the 'implementation' here. Most
> developers I know, if looking at the code and without the possibly
> dubious benefit of knowing that in Python 'everything is an object'
> would not call this 'stro
On Thu, 23 Aug 2012 12:02:16 +1000, Chris Angelico wrote:
> 2) Related to the above, you can infinitely nest scopes. There's nothing
> wrong with having six variables called 'q'; you always use the innermost
> one. Yes, this can hurt readability
Well, there you go. There *is* something wrong with
On Wed, 22 Aug 2012 21:46:29 +0100, Mark Lawrence wrote:
>> On 22/08/2012 20:45, lipska the kat wrote:
>>>
>>> compare this to a function declaration in Python
>>>
>>> def foo(self):
[...]
> Looking at the self I'm assuming that's a method and not a function.
Actually, it is a function. It doesn
On Thu, Aug 23, 2012 at 5:03 AM, lipska the kat
wrote:
> On 22/08/12 19:15, Ian Kelly wrote:
>>
>> You're conflating "strong typing" with "static typing". Strong typing
>> does not refer to restrictions on what type of data can be stored
>> where, but to restrictions on how operations on that dat
On Wed, 22 Aug 2012 18:46:43 +0100, lipska the kat wrote:
> Well I'm a beginner
Then maybe you should read more and write less.
--
http://mail.python.org/mailman/listinfo/python-list
On Wed, Aug 22, 2012 at 5:58 PM, Ben Finney wrote:
> Those people are confused, then. Python is strongly typed: objects
> always know their type, the type is always exact, and the type of an
> object can't be changed.
Except when it can.
>>> class A: pass
...
>>> class B: pass
...
>>> a = A()
>>
lipska the kat writes:
> If, in a language, I find I am able to say
>
> a = 1
>
> then later, in the same scope I can say
>
> a = "foo"
>
> then later again in the same scope I can say
>
> a = ([1,2,3], "xyz", True)
>
> then, and I may be missing something here, to me, that doesn't say
> strongly
On 08/22/2012 02:45 PM, lipska the kat wrote:
> On 22/08/12 20:03, Evan Driscoll wrote:
>> Second, this concept isn't *so* unfamiliar to you. If I give you the
>> following Java code:
>>
>>void foo(Object o) { ... }
>>
> looking at this method declaration I can see that the method takes an
> ar
On 22/08/2012 21:31, MRAB wrote:
On 22/08/2012 20:45, lipska the kat wrote:
compare this to a function declaration in Python
def foo(self):
[snip]
That's not actually a declaration but a definition. :-)
The function's body is bound to the name at runtime, so:
def double_it(x):
On 22/08/2012 20:45, lipska the kat wrote:
On 22/08/12 20:03, Evan Driscoll wrote:
On 08/22/2012 12:46 PM, lipska the kat wrote:
If you can show me a 'type' that cannot be assigned to
a
in the same scope then I would be most interested to know, I haven't
found one yet.
[snip]
Second, th
On 22/08/12 20:03, Evan Driscoll wrote:
On 08/22/2012 12:46 PM, lipska the kat wrote:
If you can show me a 'type' that cannot be assigned to
a
in the same scope then I would be most interested to know, I haven't
found one yet.
[snip]
Second, this concept isn't *so* unfamiliar to you. If
On 22/08/12 19:07, Mark Lawrence wrote:
On 22/08/2012 18:06, lipska the kat wrote:
On 22/08/12 17:30, Mark Lawrence wrote:
On 22/08/2012 17:10, lipska the kat wrote:
On 22/08/12 16:58, MRAB wrote:
On 22/08/2012 15:59, lipska the kat wrote:
On 22/08/12 15:13, shaun wrote:
[snip]
Maybe b
On 08/22/2012 12:46 PM, lipska the kat wrote:
> If you can show me a 'type' that cannot be assigned to
>
> a
>
> in the same scope then I would be most interested to know, I haven't
> found one yet.
As other people have said, you've just pointed out the difference
between static typing and dynam
On 22/08/12 19:15, Ian Kelly wrote:
On Wed, Aug 22, 2012 at 11:46 AM, lipska the kat
wrote:
If, in a language, I find I am able to say
a = 1
[snip]
You're conflating "strong typing" with "static typing". Strong typing
does not refer to restrictions on what type of data can be stored
whe
On 22/08/2012 18:46, lipska the kat wrote:
On 22/08/12 18:01, Terry Reedy wrote:
On 8/22/2012 10:59 AM, lipska the kat wrote:
There is no real enforced concept of information hiding, no binding of
type to variable in fact no concept of typing at all as far as I can
see.
Given that type(valid
On Wed, Aug 22, 2012 at 11:46 AM, lipska the kat
wrote:
> If, in a language, I find I am able to say
>
> a = 1
>
> then later, in the same scope I can say
>
> a = "foo"
>
> then later again in the same scope I can say
>
> a = ([1,2,3], "xyz", True)
>
> then, and I may be missing something here, to
On 22/08/2012 18:06, lipska the kat wrote:
On 22/08/12 17:30, Mark Lawrence wrote:
On 22/08/2012 17:10, lipska the kat wrote:
On 22/08/12 16:58, MRAB wrote:
On 22/08/2012 15:59, lipska the kat wrote:
On 22/08/12 15:13, shaun wrote:
[snip]
Im very new to python and the object orientated fea
On 22/08/12 18:01, Terry Reedy wrote:
On 8/22/2012 10:59 AM, lipska the kat wrote:
There is no real enforced concept of information hiding, no binding of
type to variable in fact no concept of typing at all as far as I can
see.
Given that type(valid_name) always returns a type(class), that is
In addition to the excellent feedback that Dave gave you:
On Wed, Aug 22, 2012 at 9:25 AM, shaun wrote:
> def breakuparray(self):
> for row in self.array:
> mer = row[0].ljust(25, ' ')
> merc = row[1].ljust(13, ' ')
>
On 22/08/12 17:30, Mark Lawrence wrote:
On 22/08/2012 17:10, lipska the kat wrote:
On 22/08/12 16:58, MRAB wrote:
On 22/08/2012 15:59, lipska the kat wrote:
On 22/08/12 15:13, shaun wrote:
[snip]
Im very new to python and the object orientated feature doesnt seem
to be as well put together
On 8/22/2012 10:59 AM, lipska the kat wrote:
There is no real enforced concept of information hiding, no binding of
type to variable in fact no concept of typing at all as far as I can
see.
Given that type(valid_name) always returns a type(class), that is a
slightly strange statement. What is
On 22/08/2012 17:10, lipska the kat wrote:
On 22/08/12 16:58, MRAB wrote:
On 22/08/2012 15:59, lipska the kat wrote:
On 22/08/12 15:13, shaun wrote:
[snip]
Im very new to python and the object orientated feature doesnt seem
to be as well put together as Java. Can anyone help with this proble
On 22/08/12 16:58, MRAB wrote:
On 22/08/2012 15:59, lipska the kat wrote:
On 22/08/12 15:13, shaun wrote:
[snip]
Im very new to python and the object orientated feature doesnt seem
to be as well put together as Java. Can anyone help with this problem?
From one Java head to another I suggest
On 22/08/2012 16:47, Chris Angelico wrote:
For what you're doing there, though, a class is overkill. Remember,
Python isn't Java; the most natural way to do everything isn't
necessarily to write a class that unpacks things and packs them up
again in a different way.
ChrisA
This shows just ho
On 22/08/2012 15:59, lipska the kat wrote:
On 22/08/12 15:13, shaun wrote:
[snip]
Im very new to python and the object orientated feature doesnt seem to be as
well put together as Java. Can anyone help with this problem?
From one Java head to another I suggest you park what you know about
On 08/22/2012 11:25 AM, shaun wrote:
> Here is some code:
> //This is the object I want to create:
> #!/usr/bin/python
> import cx_Oracle
> import sys
> import time
> import datetime
>
>
> class batchParam:
>
> def __init__(self,array):
> self.array=arra
On Thu, Aug 23, 2012 at 1:25 AM, shaun wrote:
> def breakuparray(self):
> for row in self.array:
> mer = row[0].ljust(25, ' ')
> merc = row[1].ljust(13, ' ')
> mertype = row[2]
>
Here is some code:
//This is the object I want to create:
#!/usr/bin/python
import cx_Oracle
import sys
import time
import datetime
class batchParam:
def __init__(self,array):
self.array=array
def breakuparray(self):
for
In <18409992-1e28-4721-8e64-60c69668d...@googlegroups.com> shaun
writes:
> I'm having an issue its my first time using python and i set up a class one
> of the methods is supposed to return a string but instead returns:
> 389E0>>
It looks like you're referencing the method object itself, ins
On 22/08/12 15:13, shaun wrote:
[snip]
Im very new to python and the object orientated feature doesnt seem to be as
well put together as Java. Can anyone help with this problem?
From one Java head to another I suggest you park what you know about
Java and approach Python with a clear mind.
shaun wrote:
> I'm having an issue its my first time using python and i set up a class
> one of the methods is supposed to return a string but instead returns:
>
> 389E0>>
>
> Im very new to python and the object orientated feature doesnt seem to be
> as well put together as Java.
It's defini
shaun writes:
> I'm having an issue its my first time using python and i set up a
> class one of the methods is supposed to return a string but instead
> returns:
>
> 389E0>>
>
> Im very new to python and the object orientated feature doesnt seem
> to be as well put together as Java. Can anyone
On Wed, Aug 22, 2012 at 10:13 AM, shaun wrote:
> I'm having an issue its my first time using python and i set up a class one
> of the methods is supposed to return a string but instead returns:
>
> 389E0>>
>
> Im very new to python and the object orientated feature doesnt seem to be as
> well p
93 matches
Mail list logo
