From: Tim P. <tp...@ma...> - 2002-01-11 18:04:41
|
I've been working with UserKit this week and I have a few questions maybe one of you could help me with. 1) What is the externalId that can be used to reference clients? 2) How can I keep the the user object in memory between pages? My plan is to optionally authenticate users, and display different content depending on the user. User creation works fine, but I'm having trouble tracking logins throughout a session. Right now, I have a page named UserTest. With the following code I can log them in without problem. mgr = UserManagerToFile() mgr.login(user, password) I'm guessing I need to place the code in a superclass like a UKSecurePage, but I'm not sure. The SecurePage class in the examples context might help me out, but does anyone have any other suggestions? 3) How would *you* handle preferences? I've simply creating a parameter in each user like user._prefs = { dictionary }, and then accessing _prefs by key. Although this seems to work, is there any official way to store extra info about users using UserKit? I couldn't find anything about it in the class desc. or documentation. I was also wondering why so many of the variables are named like _name or _password? I've seen this sort of naming convention a lot in python, but I'm unsure of what cases this is used in. Thanks. |
From: Frank B. <bar...@ph...> - 2002-01-12 12:08:18
|
Tim Payne hat gesagt: // Tim Payne wrote: > I was also wondering why so many of the variables are named like _name > or _password? I've seen this sort of naming convention a lot in python, > but I'm unsure of what cases this is used in. These are a kind of "private" variables. Names starting with an _underscore don't get imported if you do an "from foo import *" Example: --- foo.py --- class foo: "not private" pass class _foo: "private" pass --- test-foo.py --- from foo import * bar = _foo() try: # will raise NameError: bar = _foo() except NameError: print "_foo not defined" bye, -- __ __ Frank Barknecht ____ ______ ____ __ trip\ \ / /wire ______ / __// __ /__/ __// // __ \ \/ / __ \\ ___\ / / / ____/ / / / // ____// /\ \\ ___\\____ \ /_/ /_____/ /_/ /_//_____// / \ \\_____\\_____\ /_/ \_\ |
From: <ir...@ms...> - 2002-01-12 15:31:32
|
On Sat, Jan 12, 2002 at 01:07:33PM +0100, Frank Barknecht wrote: > Tim Payne hat gesagt: // Tim Payne wrote: > > > I was also wondering why so many of the variables are named like _name > > or _password? I've seen this sort of naming convention a lot in python, > > but I'm unsure of what cases this is used in. > > These are a kind of "private" variables. Names starting with an _underscore > don't get imported if you do an "from foo import *" Python has two levels of private variables. _variable works as above. Not only are they ignored by "from foo import *", but they are a signal to users of the class, "Don't use me directly." Sometimes you have to anyway, but those are borderline cases. The other level of private variable, __classAttributeOrMethod, works only inside a class definition. When the module is compiled, "__" is converted to "className_". This prevents subclasses, users and mixin classes from accidentally overriding them with same-name attributes that are used for a different purpose. Variables/attributes with an underscore at both ends; e.g., __name__, are not private. Instead, Python's predefined variables use this scheme to indicate the variable has some special effect. WebKit (but I don't know about UserKit) has sets of similarly-named attributes and methods. In each set, _variable is private. variable() is used to read the value, setVariable(newValue) to set it. For multi-value variables (dictionary-like), variables() returns a read-only dictionary of all values; e.g., fields(). There has been discussion about using Python 2.2's new "properties" feature to combine _variable, variable() and setVariable() into one property or "smart attribute" called simply variable, but no decision has been made yet. -- -Mike (Iron) Orr, ir...@ms... (if mail problems: ms...@oz...) http://iron.cx/ English * Esperanto * Russkiy * Deutsch * Espan~ol |
From: Tim P. <tp...@ma...> - 2002-01-12 16:36:40
|
On Saturday, January 12, 2002, at 10:37 AM, Mike Orr wrote: > <snip> Thanks Mike (and Frank). You both cleared up some misunderstandings I had about the way python dealt with variables/attributes. Since you guys brought it up, I was also wondering why WebKit uses this style of importing (from module import object) over (import module) I know that when you import the object(s) directly, you can use them like foo() instead of module.foo(), but is there any other advantage? I usually just import the module so that I don't get confused about where everything is being loaded from. Thanks. |
From: <ir...@ms...> - 2002-01-12 17:32:08
|
On Sat, Jan 12, 2002 at 11:36:33AM -0500, Tim Payne wrote: > Since you guys brought it up, I was also wondering why WebKit uses this > style of importing (from module import object) over (import module) > > I know that when you import the object(s) directly, you can use them > like foo() instead of module.foo(), but is there any other advantage? I > usually just import the module so that I don't get confused about where > everything is being loaded from. It's a stylistic preference. Why Chuck chose that style, you'd have to ask him. I generally prefer the os.path.join() style, but when the module only exists for a same-name class, I tend to use the "from module import class" style. Occasionally, like with Pickle and cPickle, you have a choice of implementations of compatible objects. In that case, it makes sense to do "from cPickle import dump, load". Then if you end up in a situation where cPickle isn't available (Jython, embedded systems, etc), you just change "cPickle" to "Pickle" in that one line and away yo go, rather than making changes all over the script. -- -Mike (Iron) Orr, ir...@ms... (if mail problems: ms...@oz...) http://iron.cx/ English * Esperanto * Russkiy * Deutsch * Espan~ol |
From: Stefan S. <ste...@tu...> - 2002-01-12 22:45:51
|
Hello Mike On Sat, 12 Jan 2002, Mike Orr wrote: > Occasionally, like with Pickle and cPickle, you have a choice of > implementations of compatible objects. In that case, it makes sense > to do "from cPickle import dump, load". Then if you end up in a > situation where cPickle isn't available (Jython, embedded systems, > etc), you just change "cPickle" to "Pickle" in that one line and > away yo go, rather than making changes all over the script. An alternative is to use import cPickle as pickle # doesn't work in Python 1.5.2 p = pickle.dumps([1, 2, 3]) Stefan |
From: Tavis R. <ta...@ca...> - 2002-01-12 18:35:24
|
On Saturday 12 January 2002 08:36, Tim Payne wrote: > On Saturday, January 12, 2002, at 10:37 AM, Mike Orr wrote: > > <snip> > > Thanks Mike (and Frank). You both cleared up some > misunderstandings I had about the way python dealt with > variables/attributes. > > Since you guys brought it up, I was also wondering why WebKit uses > this style of importing (from module import object) over (import > module) > > I know that when you import the object(s) directly, you can use > them like foo() instead of module.foo(), but is there any other > advantage? I usually just import the module so that I don't get > confused about where everything is being loaded from. In addition to what Mike said, it can be much faster at run time to use variables without lots of dots in them. This can make a huge performance difference in loops, and WebKit's request/response cycle is conceptually a big loop. SLOW: ----- import os.path def foo(): os.path.join(...) FASTER (but harder to follow in a large file): ----------------------------------------------- from os.path import join def foo(): join(...) FASTEST (my preferred style): -------- import os.path def foo(join=os.path.join): join(...) Tavis |
From: Frank B. <bar...@ph...> - 2002-01-12 17:34:07
|
I wrote: > --- test-foo.py --- > from foo import * > bar = _foo() that above was meant to be "bar = foo()", of course... -- Frank Barknecht |