On Tue, Feb 12, 2013 at 6:15 AM, Michael Torrie wrote:
> On 02/11/2013 11:32 AM, Jason Swails wrote:
>>
>> Perhaps that's your problem ;). Tkinter was the first--and only--GUI
>> toolkit I learned [1] (I do almost exclusively CLI, and GUI only for fun --
>> and I program as a result of the work I
On 02/11/2013 11:32 AM, Jason Swails wrote:
>
> Perhaps that's your problem ;). Tkinter was the first--and only--GUI
> toolkit I learned [1] (I do almost exclusively CLI, and GUI only for fun --
> and I program as a result of the work I do). Having no previous knowledge
> of any other GUI toolki
On Mon, Feb 11, 2013 at 1:27 AM, Chris Angelico wrote:
> On Mon, Feb 11, 2013 at 1:42 PM, alex23 wrote:
> > On Feb 9, 2:25 pm, Michael Torrie wrote:
> >> Rick seems to know his stuff
> >> about Tk programming, but his knowledge of programming language theory
> >> and formal computing seems quit
On Mon, Feb 11, 2013 at 1:42 PM, alex23 wrote:
> On Feb 9, 2:25 pm, Michael Torrie wrote:
>> Rick seems to know his stuff
>> about Tk programming, but his knowledge of programming language theory
>> and formal computing seems quite informal.
>
> Not informal, "intuited". If he doesn't already kno
On Feb 9, 2:25 pm, Michael Torrie wrote:
> Rick seems to know his stuff
> about Tk programming, but his knowledge of programming language theory
> and formal computing seems quite informal.
Not informal, "intuited". If he doesn't already know something, it's
apparently not important.
--
http://
On 02/08/2013 04:45 AM, Steven D'Aprano wrote:
> Rick Johnson wrote:
>> Of course in this simplistic example we can see that count is @ module
>> level
>
> But it isn't. It is a local variable.
>
> Rick, I appreciate your honesty in telling us that you have no idea how to
> read Python code and r
Rick Johnson wrote:
> When reading over some source code we really have no idea in which
> namespace a variable lives. Consider the following:
>
> count = 0
> class Blah:
> def meth():
> for x in range(100):
> count = x
>
> Where is count living?
>
> Of course in this si
On Fri, Feb 8, 2013 at 10:29 PM, Steven D'Aprano
wrote:
> Chris Angelico wrote:
>
>> On Fri, Feb 8, 2013 at 3:30 PM, Rick Johnson
>> wrote:
>>> It is my strong opinion that all "unqualified" variables must be local to
>>> the containing block, func/meth, class, or module. To access any variable
>
Chris Angelico wrote:
> On Fri, Feb 8, 2013 at 3:30 PM, Rick Johnson
> wrote:
>> It is my strong opinion that all "unqualified" variables must be local to
>> the containing block, func/meth, class, or module. To access any variable
>> outside of the local scope a programmer MUST qualify that vari
On Fri, Feb 8, 2013 at 6:23 PM, Rick Johnson
wrote:
> from builtins import print, len, repr
> from builtins import * # This is not recommended!
>
> This would serve two purposes (1) the reader would know which builtins where
> being used in this module (2) the names would be bound prop
On Friday, February 8, 2013 12:25:34 AM UTC-6, Chris Angelico wrote:
> On Fri, Feb 8, 2013 at 3:30 PM, Rick Johnson wrote:
> > It is my strong opinion that all "unqualified" variables must be local to
> > the containing block, func/meth, class, or module. To access any variable
> > outside of the
On Fri, Feb 8, 2013 at 3:30 PM, Rick Johnson
wrote:
> It is my strong opinion that all "unqualified" variables must be local to the
> containing block, func/meth, class, or module. To access any variable outside
> of the local scope a programmer MUST qualify that variable with the func,
> class
On 02/07/2013 09:30 PM, Rick Johnson wrote:
> count = 0
> class Blah:
> def meth():
> for x in range(100):
> count = x
>
> Where is count living?
>
> Of course in this simplistic example we can see that count is @
> module level
Except that it's not after the "count=
Python's use of namespaces is, as we all quite know, "one honking great idea!";
and i must wholeheartedly agree, however, accessing and declaring variables
living in python namespaces is a kludge at best, and a malevolent obfuscation
at worst!
14 matches
Mail list logo
