Re: PyWart: Namespace asinitiy and the folly of the global statement
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 do). Having no previous knowledge >> of any other GUI toolkit (and really only writing 2 or 3 _real_ GUIs >> total), it wasn't hard to pick up enough from effbot/stackoverflow/tkinter >> documentation to get a working GUI with (what I think is) decent code >> organization. >> >> Just my personal experience. > > My first experience with GUI programming was with MFC on windows. Yuck! > Anything is better. Although wxWidgets seems to follow the MFC model > in some ways, and that has always left a sour taste in my mouth. > > Since then I've done both GTK and Qt programming and both are a > pleasure, especially in Python. Lately I've done all my GUI work with GTK, and it's worked out nicely for me. But I still assume that it'll take as long to learn as the language I'm using - which, for good languages like Python, isn't all that long, but it's not like mastering urllib. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Namespace asinitiy and the folly of the global statement
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 toolkit (and really only writing 2 or 3 _real_ GUIs > total), it wasn't hard to pick up enough from effbot/stackoverflow/tkinter > documentation to get a working GUI with (what I think is) decent code > organization. > > Just my personal experience. My first experience with GUI programming was with MFC on windows. Yuck! Anything is better. Although wxWidgets seems to follow the MFC model in some ways, and that has always left a sour taste in my mouth. Since then I've done both GTK and Qt programming and both are a pleasure, especially in Python. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Namespace asinitiy and the folly of the global statement
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 quite informal. > > > > Not informal, "intuited". If he doesn't already know something, it's > > apparently not important. > > I wonder how he learned about Tk. To be quite frank, I've not found > tkinter to be particularly intuitive, and I've been doing GUI > programming since the early 90s (with a wide variety of toolkits). > 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 toolkit (and really only writing 2 or 3 _real_ GUIs total), it wasn't hard to pick up enough from effbot/stackoverflow/tkinter documentation to get a working GUI with (what I think is) decent code organization. Just my personal experience. --Jason [1] Tkinter is part of the stdlib, and I try to minimize external dependencies -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Namespace asinitiy and the folly of the global statement
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 know something, it's > apparently not important. I wonder how he learned about Tk. To be quite frank, I've not found tkinter to be particularly intuitive, and I've been doing GUI programming since the early 90s (with a wide variety of toolkits). Mind, that's not necessarily an indictment of tkinter per se; MOST windowing toolkits take a bit of mastering. But my general estimate is that it takes roughly as long to learn a GUI toolkit as to learn a language, and takes comparable effort. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Namespace asinitiy and the folly of the global statement
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://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Namespace asinitiy and the folly of the global statement
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 recognise which namespace the variables are found in, > but you really shouldn't assume others suffer under that same affliction. Very interesting to hear the crickets chirping over this one as the trolling continues on another thread. Rick seems to know his stuff about Tk programming, but his knowledge of programming language theory and formal computing seems quite informal. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Namespace asinitiy and the folly of the global statement
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 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 recognise which namespace the variables are found in, but you really shouldn't assume others suffer under that same affliction. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Namespace asinitiy and the folly of the global statement
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
>>> outside of the local scope a programmer MUST qualify that variable with
>>> the func, class, or module identifiers. Consider the following examples
>>
>> Okay. Now start actually working with things, instead of just making
>> toys. All your builtins now need to be qualified:
>>
>> __builtins__.print("There
>> are",__builtins__.len(self.some_list),"members in this list,
>> namely:",__builtins__.repr(self.some_list))
>
>
> Pardon me, but since __builtins__ is a global, you have to say:
>
> globals.__builtins__.print("screw this for a game of soldiers")
>
> or equivalent.
And isn't globals a builtin?
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Namespace asinitiy and the folly of the global statement
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 variable with
>> the func, class, or module identifiers. Consider the following examples
>
> Okay. Now start actually working with things, instead of just making
> toys. All your builtins now need to be qualified:
>
> __builtins__.print("There
> are",__builtins__.len(self.some_list),"members in this list,
> namely:",__builtins__.repr(self.some_list))
Pardon me, but since __builtins__ is a global, you have to say:
globals.__builtins__.print("screw this for a game of soldiers")
or equivalent.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Namespace asinitiy and the folly of the global statement
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 properly to the module > namespace. But this does not answer your question, merely a side note > > So your assertion is wrong. Built-ins /would/ be available at the module > level with no qualification just as they are now. But they would also be > available in /every/ namespace because how else would we use them Chris? So what you're saying is that builtins are available without qualification inside a function, but other names imported into the module namespace aren't? MAGIC. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Namespace asinitiy and the folly of the global statement
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 local scope a programmer MUST qualify that variable with the
> > func, class, or module identifiers. Consider the following examples
>
> Okay. Now start actually working with things, instead of just making
> toys. All your builtins now need to be qualified:
Chris you are very trollish, and a total tool of Deaprano, but you are damn
funny sometimes and for that reason i still respond to you. ;-)
> __builtins__.print("There
> are",__builtins__.len(self.some_list),"members in this list,
> namely:",__builtins__.repr(self.some_list))
That's funny, and i laughed whilst reading it, but i do have to admit that i
did not explain this detail. IMHO, all builtins should not be auto-imported,
the programmer should import them either on a case by case basis, or do the
global import:
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 properly to the module
namespace. But this does not answer your question, merely a side note
So your assertion is wrong. Built-ins /would/ be available at the module level
with no qualification just as they are now. But they would also be available in
/every/ namespace because how else would we use them Chris?
It's very simple, when python encounters a unqualified symbol, it looks first
for a match in the built-in symbols array, and if not match is found it then
raises a NameError.
> Or are you going to make builtins and imports magically available as
> PHP-style superglobals?
Hmm, what are they now Chris? Python built-ins are known everywhere without
qualification and require no import. I think super-global about sums it up.
--
http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Namespace asinitiy and the folly of the global statement
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, or module identifiers. Consider the following examples
Okay. Now start actually working with things, instead of just making
toys. All your builtins now need to be qualified:
__builtins__.print("There
are",__builtins__.len(self.some_list),"members in this list,
namely:",__builtins__.repr(self.some_list))
And your imports happen at module level, so they need extra qualification:
# file: example.py
import sys
def foo():
__builtins__.print("My args were:",example.sys.argv)
Actually, you already ran up against this. Your example needs to become:
for x in __builtins__.range(100):
# Increment the module level variable count.
example.count += 1
Or are you going to make builtins and imports magically available as
PHP-style superglobals?
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Namespace asinitiy and the folly of the global statement
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=x" statement inside the for loop. That's entirely within the local scope. Names bound to objects always default to the local namespace, whatever that is. If your function referred to "count" without any assignment, then it's unclear as to which namespace it is in. It could be the class namespace, or the module namespace. But that's a problem no different than in any language. Python does differ, from, say C, where global variables can be read and written to without any special declarations in a function, though you can tell at a glance whether or not a variable is declared in the local scope. -- http://mail.python.org/mailman/listinfo/python-list
