On Sat, 06 Oct 2007 19:16:47 +1300, Lawrence D'Oliveiro wrote:
> In message <[EMAIL PROTECTED]>, Marc 'BlackJack' Rintsch
> wrote:
>
>> To me a `variable` is made of a name, a memory address, a data type, and
>> a value. In languages like C the address and type are attached to the
>> name while
In message <[EMAIL PROTECTED]>, Marc 'BlackJack' Rintsch
wrote:
> To me a `variable` is made of a name, a memory address, a data type, and
> a value. In languages like C the address and type are attached to the
> name while in Python both are attached to the value.
How does C++ with RTTI fit int
Steven D'Aprano wrote:
> On Fri, 05 Oct 2007 07:37:34 -0400, Steve Holden wrote:
>
>> Steven D'Aprano wrote:
>>> On Fri, 05 Oct 2007 00:12:33 -0500, Robert Kern wrote:
>>>
This is somewhat odd, because most modules aren't exposed that way.
They are either in their own file and accessed b
On Fri, 05 Oct 2007 07:37:34 -0400, Steve Holden wrote:
> Steven D'Aprano wrote:
>> On Fri, 05 Oct 2007 00:12:33 -0500, Robert Kern wrote:
>>
>>> This is somewhat odd, because most modules aren't exposed that way.
>>> They are either in their own file and accessed by importing them
>>> directly,
On 2007-10-05, Lawrence D'Oliveiro <[EMAIL PROTECTED]> wrote:
> In message <[EMAIL PROTECTED]>, Neil Cerutti wrote:
>
>> On 2007-10-03, Lawrence D'Oliveiro <[EMAIL PROTECTED]>
>> wrote:
>>> In Python, all names _are_ variables. They are not "bound" to
>>> objects. The value of os.path is a pointer.
Steven D'Aprano wrote:
> On Fri, 05 Oct 2007 00:12:33 -0500, Robert Kern wrote:
>
>> This is somewhat odd, because most modules aren't exposed that way. They
>> are either in their own file and accessed by importing them directly, or
>> they are inside a package.
>
> Any time you say:
>
> import
On Fri, 05 Oct 2007 00:12:33 -0500, Robert Kern wrote:
> This is somewhat odd, because most modules aren't exposed that way. They
> are either in their own file and accessed by importing them directly, or
> they are inside a package.
Any time you say:
import parrot
in one of your modules, you
On Fri, 05 Oct 2007 19:51:05 +1300, Lawrence D'Oliveiro wrote:
> There is no sense in which any Python object can "contain" any other.
>>> L = [1, 2, 3]
>>> 2 in L
True
>>> L.__contains__(3)
True
--
Steven.
--
http://mail.python.org/mailman/listinfo/python-list
On Fri, 05 Oct 2007 19:51:05 +1300, Lawrence D'Oliveiro wrote:
> It is not the _name_ that is being reassigned, it is the _variable_ that
> the name is bound to. All names in Python are bound to variables at all
> times.
I think this is the source of the confusion. Most people don't seem
to shar
"Steve Holden" <[EMAIL PROTECTED]> wrote:
> Hendrik van Rooyen wrote:
> > "Steve Holden" wrote:
> >
> >> religious issues for me. It's more like "This problem has a cross head,
> >> so I'll need a Philips screwdriver".
> >
> > As long as it is not a Pozidrive, that is a commendable attitude.
> >
Lawrence D'Oliveiro a écrit :
> In message <[EMAIL PROTECTED]>, Steven D'Aprano wrote:
>
>> What does type(os.path) return when you try it?
>
> It returns the type of the value contained in that variable, of course:
Certainly not. You're confusing Python with C. In Python, 'variables'
are *not*
In message <[EMAIL PROTECTED]>, Robert
Kern wrote:
> Lawrence D'Oliveiro wrote:
>> In message <[EMAIL PROTECTED]>, Steven D'Aprano wrote:
>>
>>> What does type(os.path) return when you try it?
>>
>> It returns the type of the value contained in that variable, of course:
>>
>> >>> import os
Lawrence D'Oliveiro wrote:
> In message <[EMAIL PROTECTED]>, Steven D'Aprano wrote:
>
>> What does type(os.path) return when you try it?
>
> It returns the type of the value contained in that variable, of course:
>
> >>> import os
> >>> os.path = 3
> >>> type(os.path)
>
>
> See
In message <[EMAIL PROTECTED]>, Neil Cerutti wrote:
> On 2007-10-03, Lawrence D'Oliveiro <[EMAIL PROTECTED]>
> wrote:
>> In message <[EMAIL PROTECTED]>, Ben Finney wrote:
>>
>>> Lawrence D'Oliveiro <[EMAIL PROTECTED]> writes:
>>>
On my Gentoo system:
>>> import os
>>>
In message <[EMAIL PROTECTED]>, Steven D'Aprano wrote:
> What does type(os.path) return when you try it?
It returns the type of the value contained in that variable, of course:
>>> import os
>>> os.path = 3
>>> type(os.path)
See, it's just a variable, like any other.
--
http:/
On Oct 4, 11:11 am, Steve Holden <[EMAIL PROTECTED]> wrote:
> Hendrik van Rooyen wrote:
> > "Steve Holden" wrote:
>
> >> religious issues for me. It's more like "This problem has a cross head,
> >> so I'll need a Philips screwdriver".
>
> > As long as it is not a Pozidrive, that is a commendable a
On Thu, 04 Oct 2007 23:01:06 +1300, Lawrence D'Oliveiro wrote:
> In message <[EMAIL PROTECTED]>, Steven D'Aprano wrote:
>
>> ... pedants ...
>
> When people use that word against me, it's generally a sign they're
> trying not to admit I'm right.
Yeah, you keep telling yourself that.
What does
On 2007-10-03, Lawrence D'Oliveiro <[EMAIL PROTECTED]> wrote:
> In message <[EMAIL PROTECTED]>, Ben Finney wrote:
>
>> Lawrence D'Oliveiro <[EMAIL PROTECTED]> writes:
>>
>>> On my Gentoo system:
>>>
>>> >>> import os
>>> >>> os.path
>>>
>>>
>>> It's just a variable that happens to p
Lawrence D'Oliveiro a écrit :
> In message <[EMAIL PROTECTED]>, Carsten
> Haese wrote:
>
>> On Thu, 2007-10-04 at 11:11 +1300, Lawrence D'Oliveiro wrote:
>>
>>> In Python, all names _are_ variables. They are not "bound" to objects.
>>> The value of os.path is a pointer.
>> No. "os.path" refers to
Lawrence D'Oliveiro wrote:
> In message <[EMAIL PROTECTED]>, Steven D'Aprano wrote:
>
>> ... pedants ...
>
> When people use that word against me, it's generally a sign they're trying
> not to admit I'm right.
If it were less important to be right and more important to be
considerate this threa
Hendrik van Rooyen wrote:
> "Steve Holden" wrote:
>
>> religious issues for me. It's more like "This problem has a cross head,
>> so I'll need a Philips screwdriver".
>
> As long as it is not a Pozidrive, that is a commendable attitude.
>
I said cross head, not Pozidriv (tm). But then I have
In message <[EMAIL PROTECTED]>, Steven D'Aprano wrote:
> ... pedants ...
When people use that word against me, it's generally a sign they're trying
not to admit I'm right.
--
http://mail.python.org/mailman/listinfo/python-list
On Thu, 04 Oct 2007 11:11:03 +1300, Lawrence D'Oliveiro wrote:
> In Python, all names _are_ variables. They are not "bound" to objects.
The general convention among Python programmers is to describe names
being bound to values. While the analogy to real life binding of objects,
it's close enoug
"Lawrence D'Oliveiro" <[EMAIL PROTECTED]> wote:
> Honestly, why do people react to the word "pointer" as though computers have
> to wear underwear to conceal something shameful going on in their nether
> regions?
I think it is because a pointer is a variable containing as a value the address
of s
"Steve Holden" wrote:
> religious issues for me. It's more like "This problem has a cross head,
> so I'll need a Philips screwdriver".
As long as it is not a Pozidrive, that is a commendable attitude.
- Hendrik
--
http://mail.python.org/mailman/listinfo/python-list
In message <[EMAIL PROTECTED]>, Carsten
Haese wrote:
> On Thu, 2007-10-04 at 11:11 +1300, Lawrence D'Oliveiro wrote:
>
>> In Python, all names _are_ variables. They are not "bound" to objects.
>> The value of os.path is a pointer.
>
> No. "os.path" refers to the object that's known as the "path"
Ben Finney wrote:
> Steve Holden <[EMAIL PROTECTED]> writes:
>
>> You and I know that the semantics of Python names are precisely
>> those of (to use an Algol 68 term, unless I am mistaken)
>> automatically dereferenced pointers to objects of arbitrary type.
>
> Yes. That's exactly why it's wrong
Steve Holden <[EMAIL PROTECTED]> writes:
> You and I know that the semantics of Python names are precisely
> those of (to use an Algol 68 term, unless I am mistaken)
> automatically dereferenced pointers to objects of arbitrary type.
Yes. That's exactly why it's wrong to refer to them as pointers
Lawrence D'Oliveiro wrote:
> In message <[EMAIL PROTECTED]>, Ben Finney wrote:
>
>> Lawrence D'Oliveiro <[EMAIL PROTECTED]> writes:
>>
>>> On my Gentoo system:
>>>
>>> >>> import os
>>> >>> os.path
>>>
>>>
>>> It's just a variable that happens to point to the posixpath module.
>> Ther
Lawrence D'Oliveiro wrote:
> In message <[EMAIL PROTECTED]>, Ben Finney wrote:
>
>> Lawrence D'Oliveiro <[EMAIL PROTECTED]> writes:
>>
>>> On my Gentoo system:
>>>
>>> >>> import os
>>> >>> os.path
>>>
>>>
>>> It's just a variable that happens to point to the posixpath module.
>> Ther
On Thu, 2007-10-04 at 11:11 +1300, Lawrence D'Oliveiro wrote:
> In Python, all names _are_ variables. They are not "bound" to objects. The
> value of os.path is a pointer.
No. "os.path" refers to the object that's known as the "path" attribute
of the object known as "os". That object, in turn, is
In message <[EMAIL PROTECTED]>, Ben Finney wrote:
> Lawrence D'Oliveiro <[EMAIL PROTECTED]> writes:
>
>> On my Gentoo system:
>>
>> >>> import os
>> >>> os.path
>>
>>
>> It's just a variable that happens to point to the posixpath module.
>
> There's no "pointing" going on. It's an
+1 Subject line of the week (SLOTW)
rjcarr wrote:
> So my question is ... why are they [os.path and logging.handlers] different?
[A] wrote:
> Because you misspelled it. First, do a dir() on logging:
[B] wrote:
> No, he didn't... OP: logging is a package and logging.handlers is one module
> in t
Lawrence D'Oliveiro wrote:
> In message <[EMAIL PROTECTED]>, Robert
> Kern wrote:
>
>> Lawrence D'Oliveiro wrote:
>>
>>> In message <[EMAIL PROTECTED]>, Robert
>>> Kern wrote:
>>>
Not all of the modules in a package are imported by importing the
top-level package.
>>> You can't import pa
On Wed, 2007-10-03 at 17:24 +, wang frank wrote:
> Sorry for the wrong title of this email. Please ignore this email. I
> have resend the question with correct title.
But it's still in the wrong thread. When asking a new question, you
should compose a new message instead of replying to an exis
Sorry for the wrong title of this email. Please ignore this email. I have
resend the question with correct title.
Thanks
frank
From: [EMAIL PROTECTED]: [EMAIL PROTECTED]: RE: module confusionDate: Wed, 3
Oct 2007 17:14:19 +
Hi, I am moving from Matlab to Python+numpy+scipy. In Matla
Hi,
I am moving from Matlab to Python+numpy+scipy. In Matlab you can use function
dec2bin, hex2dec, dec2hex bin2dec functions to convert decimal to binary and
heximal etc. Before I try to implement my own function in Python, I want to
know whether in Python such functionalities are already t
En Wed, 03 Oct 2007 07:12:17 -0300, Lawrence D'Oliveiro
<[EMAIL PROTECTED]> escribi�:
> In message <[EMAIL PROTECTED]>, Robert
> Kern wrote:
>
>> Lawrence D'Oliveiro wrote:
>>
>>> In message <[EMAIL PROTECTED]>,
>>> Robert
>>> Kern wrote:
>>>
Not all of the modules in a package are import
Lawrence D'Oliveiro a écrit :
> In message <[EMAIL PROTECTED]>, Robert
> Kern wrote:
>
>> Lawrence D'Oliveiro wrote:
>>
>>> In message <[EMAIL PROTECTED]>, Robert
>>> Kern wrote:
>>>
Not all of the modules in a package are imported by importing the
top-level package.
>>> You can't import
Lawrence D'Oliveiro <[EMAIL PROTECTED]> writes:
> On my Gentoo system:
>
> >>> import os
> >>> os.path
>
>
> It's just a variable that happens to point to the posixpath module.
There's no "pointing" going on. It's another name bound to the same
object, of equal status to the 'posix
In message <[EMAIL PROTECTED]>, Steve
Holden wrote:
> You *can* import a package ...
You're right. I was misremembering the behaviour of PyCrypto, where
importing the upper-level packages do little more than give you a list of
what algorithms are available.
--
http://mail.python.org/mailman/list
In message <[EMAIL PROTECTED]>, Robert
Kern wrote:
> Lawrence D'Oliveiro wrote:
>
>> In message <[EMAIL PROTECTED]>, Robert
>> Kern wrote:
>>
>>> Not all of the modules in a package are imported by importing the
>>> top-level package.
>>
>> You can't import packages, only modules.
>>
>>> os.pat
Lawrence D'Oliveiro wrote:
> In message <[EMAIL PROTECTED]>, Robert
> Kern wrote:
>
>> Not all of the modules in a package are imported by importing the
>> top-level package.
>
> You can't import packages, only modules.
>
>> os.path is a particularly weird case because it is just an alias to the
Lawrence D'Oliveiro wrote:
> In message <[EMAIL PROTECTED]>, Robert
> Kern wrote:
>
>> Not all of the modules in a package are imported by importing the
>> top-level package.
>
> You can't import packages, only modules.
>
>> os.path is a particularly weird case because it is just an alias to the
On Tue, 02 Oct 2007 19:34:29 +1300, Lawrence D'Oliveiro wrote:
> In message <[EMAIL PROTECTED]>, Robert
> Kern wrote:
>
>> Not all of the modules in a package are imported by importing the
>> top-level package.
>
> You can't import packages, only modules.
Oh come on, this is unnecessary nitpick
In message <[EMAIL PROTECTED]>, Robert
Kern wrote:
> Not all of the modules in a package are imported by importing the
> top-level package.
You can't import packages, only modules.
> os.path is a particularly weird case because it is just an alias to the
> platform-specific path-handling module;
[EMAIL PROTECTED] wrote:
> On Oct 1, 10:03?pm, rjcarr <[EMAIL PROTECTED]> wrote:
>> Sorry if this is a completely newbie question ...
>>
>> I was trying to get information about the logging.handlers module, so
>> I imported logging, and tried dir(logging.handlers), but got:
>>
>> AttributeError: 'm
On Oct 1, 10:03?pm, rjcarr <[EMAIL PROTECTED]> wrote:
> Sorry if this is a completely newbie question ...
>
> I was trying to get information about the logging.handlers module, so
> I imported logging, and tried dir(logging.handlers), but got:
>
> AttributeError: 'module' object has no attribute 'h
Sorry if this is a completely newbie question ...
I was trying to get information about the logging.handlers module, so
I imported logging, and tried dir(logging.handlers), but got:
AttributeError: 'module' object has no attribute 'handlers'
The only experience I have in modules is os and os.pat
49 matches
Mail list logo
