Re: Favorite non-python language trick?

[Shai]

Joseph Garvin wrote:
>
> I'm curious -- what is everyone's favorite trick from a non-python
> language? And -- why isn't it in Python?
>

1. Lisp's "dynamically scoped" variables (Perl has them, and calls them
"local", but as far as I've seen their use their is discouraged). These
are global variables which are given time-local bindings. That is,
structuring the syntax after what's used for globals,

x=10
def foo():
  # No need to define x as it is only read -- same as globals
  print x

def bar():
  dynamic x
  x = 11
  foo()

def baz():
  bar() # prints 11
  foo() # prints 10; the binding in bar is undone when bar exits

This feature makes using "globals" sensible, providing a way to avoid
many important uses (and some say, misuses) of objects if you are so
inclined. It allows you to do some things better than objects do,
because it does to library parameters, what exceptions do to return
codes: instead of passing them in all the way from outside until a
piece of code which actually uses them, they are only mentioned where
you set them and where you really need to access them.

It would not be too hard to implement a version of this (inefficiently)
in the existing language, if frame objects could carry a modifiable
dictionary.

I suppose it is not in Python because (most) Pythoners are not looking
(hard enough) for alternatives to OOP.

2. Prolog's ability to add operators to the language. Though this
facility is quite clanky in Prolog (because there is no elegant way to
specify precedence), the idea is appealing to me. It would allow a
better implementation of my (awkward, granted) recipe for adding logic
programming constructs to Python. It is not in the language because it
might fragmentize it, and because it is very hard to make
recursive-descent parsers like CPython's programmable this way.

3. Lisp's Macros, of course, which have been mentioned already in this
thread. Even Boo-like macros, which are nowhere as strong as Lisp's,
would be very useful. Not in the language, besides its being hard in
any non-lisp-like language, for the reasons mentioned for adding
operators.

On the other hand, there's no end to the features I wish I could copy
from Python to other languages...

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Favorite non-python language trick?

[Shai]

I only saw this today... sorry about the late response. Anyway,
replying to your two messages at once:

Mike Meyer wrote:

> Last time I checked, dynamic binding variables were frowned on in LISP
> systems as well. Scheme doesn't have them.  Common LISP requires
> special forms to use them.

They're called "Special vars", and you need to define them (unlike
local LISP variables, which behave essentially like Python vars), but
then you use them just like other vars (that is, you usually bind them
with LET). This is the first I hear about them being ill-considered in
LISP; http://www.gigamonkeys.com/book/ is a recently published LISP
book which recommends them. I don't know about Scheme, but I think it
does have them.

The one "special" thing you see in every use of these vars in LISP is a
naming convention; as LISP symbols can contain most characters, they
are usually named with asterisks on both ends to distinguish them.
Thus, in the example above, the dynamic var would be named "*x*".

> The problem with the given use case is that it lets every routine in
> the call chain substitute it's own variable for the library parameter
> you want to use, with no local indication that this is going
> on. This makes bugs in dynamically scoped variables a PITA to find.

In LISP, the naming convention indeed takes care of that; and indeed, I
consider taking the LISP way would be better. The definition of x as
dynamic would then be not in bar nor its callers, but in the definition
of x, as in

dynamic x=10
def bar():
  print x

I specified the syntax as I did, specifically to make it match the
current definition of globals, which "enjoys" the same problems you
noted with my dynamics.

>
> >> x=10
> >> def foo():
> >>   # No need to define x as it is only read -- same as globals
> >>   print x
> >>
> >> def bar():
> >>   dynamic x
> >>   x = 11
> >>   foo()
> >>
> >> def baz():
> >>   bar() # prints 11
> >>   foo() # prints 10; the binding in bar is undone when bar exits
>
> Here's the problem with that. Consider this script:
>
> import foo
> x = 10
> def bar():
> print x
>
> foo.foogle(bar)
>
> If foo.foogle includes "dynamic x" and then invokes bar, bar could
> print anything. This makes the behavior of bar unpredictable by
> examining the sourc, with no hint that that is going on.
>
While I didn't write it explicitly, if both LISP and Python globals are
to be followed, the dynamic x should somehow be defined in the scope of
its module. On second thought, this means "dynamic" _must_ be added in
the variable definition, for foo.foogle will simply access it as
"othermodule.x", which doesn't differentiate globals from dynamics.

Either way, Python as it is now allows foo.foogle to change x even
without dynamic variables; it is accessible as barmodule.x. bar()
should expect to have other functions mess with its globals, and
dynamics are no different.

> > Given that it's a feature I don't want programmers using, I'd only be
> > willing to see it added to the language if you can show that it has no
> > overhead so long as you don't use it. I'm not sure that can be done.
>
That sounds like a fine requirement. Now, with my corrected
proposition, it would be implementable at the module-object level, so
that only module which use the feature, and modules which use them,
would be affected.

> Here's a proposal for dynamically bound variables that you should be
> able to implement without affecting the runtime behavior of code that
> doesn't use it.
>
> Instead of dynamic meaning "all references to the named variable(s)
> will be dynamic until this function exits", have it mean "the named
> variable(s) will be dynamic in this function." Whether it should only
> check local variables in the calling routines, check local + global,
> or check for all free variables, is an open question.
>
> I.e. - your example would be written:
>
> x = 10
> def foo():
> dynamic x
> print x
>
> def bar():
> x = 11
> foo()
>
> def baz():
> bar()   # prints 11
> foo()   # Possibly an error?
>

This introduces the same problem you noted with my original proposal,
but in reverse: Now, in bar(), you define and use a local variable, and
suddenly some library function changes its behavior misteriously.

> For my example above, bar would *always* print 10. Nothing that
> foo.foogle did would change that. However, you could write:
>
> import foo
> def bar():
> dynamic x
> print x
>
> foo.foogle(bar)
>
> In this case, bar will print whatever foo.foogle sets x to - and it's
> noted in the source to bar. This means that functions that don't
> declare a dynamic variable can be compiled to the same code they are
> compiled to now.
>

This is, I believe, disproved by my comment above.

Thanks for your time and effort,

Shai.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Favorite non-python language trick?

[Shai]

Mike Meyer wrote:
> "Shai" <[EMAIL PROTECTED]> writes:
>
> > They're called "Special vars", and you need to define them (unlike
> > local LISP variables, which behave essentially like Python vars), but
> > then you use them just like other vars (that is, you usually bind them
> > with LET). This is the first I hear about them being ill-considered in
> > LISP; http://www.gigamonkeys.com/book/ is a recently published LISP
> > book which recommends them. I don't know about Scheme, but I think it
> > does have them.
>
> I'm pretty sure scheme doesn't have dynamically bound variables. I
> just went through r5rs to check, and couldn't find them.
>

Yes, you're right. One learns.

> > dynamic x=10
> > def bar():
> >   print x
> >
>
> This looks different from what I understood before. You're now
> declaring the variable dynamic in the global scope, rather than in the
> function that makes it dynamic. This is a *much* more palatable
> situation.
>

This is indeed different from what I said first. It copies the Common
LISP construct without regard to consistency with the Python global
construct.

> Globals are lexically scoped. As such, you can find the defintion of
> the variable by examining the module that includes the function. Yes,
> other modules can reach into your module and change them - but you can
> find those, because they reference your module by name.
>
> A dynamic variable declared so in a function has no such clue
> associated with it. If the variable is declared dynamic in the module
> of the enclosed function, that provides a contextual clue.

In my original proposal, dynamic variables are seen as globals from the
function in their module which reads them; no more, no less. The
important point I want from dynamic scope is the time-locality of
asignments, that
is, the fact that they are undone when the (lexical) scope of the new
binding ends. This allows the use of globals, with a lot less fear of
unintended interactions between users of the module (well, this is only
accurate until multithreading enters the picture, but that can be
handled
too).

[rest snipped]

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Cleaning up after failing to contructing objects

[Shai]

Since nobody else mentioned this...

Python classes have a magic method called __del__ which is usually
called just before an object is garbage-collected. Further, Python
uses reference-counting to tell when an object is no longer
accessible. This means that if your resource classes define __del__
methods, these will be called properly when the object using them is
destroyed, and you don't need to write an explicit close() method for
this.

class Resource(object):
  def __init__(self, param):
# acquire resource

  def __del__(self):
# release resource

not_my_responsibility = Resource(1)

class Foo(object):
  def __init__(self):
 self.ref = not_my_responsibility # self.ref.__del__() will not be
called as long as the module exists
 local = Resource(2) # local.__del__() will be called as soon as
__init__ is exited
 self.held = Resource(3) # self.held.__del__() will be called when
the object dies
 z = 1/0 # The exception in the initializer will kill the object,
triggering some Resource.__del__() calls

There are two caveats:

1) __del__ methods prevent instances of your class from being
collected when they are involved in cyclical structures; this means if
your structures start to get complex (sometimes a doubly-linked list
is complex enough), you may find yourself leaking memory.

2) The bit about reference counting, which allows predictable
destruction, holds for CPython, but not for Jython, and IIRC also not
for IronPython (I don't know about PyPy or other implementations). It
is a feature of the reference implementation, not the language
definition.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Override a method but inherit the docstring

[Shai]

On Jul 17, 10:52 am, Steven D'Aprano  wrote:
>
> When the decorator is called, the function object is just a function
> object, not a method, so there is no concept of "what class it is
> destined for".
>

... which points to the better solution: use a descriptor. With the
doc_inherit decorator defined below, one may write

class Foo(object):
def foo(self):
"Frobber"
pass

class Bar(Foo):
@doc_inherit
def foo(self):
pass

and it appears to work. The code below is a little longish because we
need to do slightly different things when called for a class and for
an instance. But there's no need to repeat the parent name, no need
to look into namespaces (which, as you said, is probably messy and
fragile), and it seems pretty readable, too.

from functools import wraps

class DocInherit(object):
"""
Docstring inheriting method descriptor

The class itself is also used as a decorator
"""

def __init__(self, mthd):
self.mthd = mthd
self.name = mthd.__name__

def __get__(self, obj, cls):
if obj:
return self.get_with_inst(obj, cls)
else:
return self.get_no_inst(cls)

def get_with_inst(self, obj, cls):

overridden = getattr(super(cls, obj), self.name, None)

@wraps(self.mthd, assigned=('__name__','__module__'))
def f(*args, **kwargs):
return self.mthd(obj, *args, **kwargs)

return self.use_parent_doc(f, overridden)

def get_no_inst(self, cls):

for parent in cls.__mro__[1:]:
overridden = getattr(parent, self.name, None)
if overridden: break

@wraps(self.mthd, assigned=('__name__','__module__'))
def f(*args, **kwargs):
return self.mthd(*args, **kwargs)

return self.use_parent_doc(f, overridden)

def use_parent_doc(self, func, source):
if source is None:
raise NameError, ("Can't find '%s' in parents"%self.name)
func.__doc__ = source.__doc__
return func

doc_inherit = DocInherit

Combining docstrings (as suggested by Jean-Paul Calderone), and
taking proper care of classmethods and staticmethods, are left
as an exercise to the reader.

Have fun,
Shai.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Override a method but inherit the docstring

[Shai]

On Jul 27, 5:05 pm, Jean-Michel Pichavant 
wrote:
> Ben Finney wrote:
> >
> > The docstring for ‘FooGonk.frobnicate’ is, intentionally, perfectly
> > applicable to the ‘BarGonk.frobnicate’ method also. Yet in overriding
> > the method, the original docstring is not associated with it.
>
> I've also tried within the python interpreter, and it can perfectly
> solve docstring inheritance. So why would you explicitly assign
> docstring to child methods ?
>

What do you mean by "can perfectly solve docstring inheritance" ?

After the following,

class Foo(object):
def foo(self):
"Frobber"
pass

class Bar(Foo):
def foo(self):
pass

help(Bar.foo) does not display "Frobber" on my interpreter.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Override a method but inherit the docstring

[Shai]

On Jul 26, 6:55 pm, a...@pythoncraft.com (Aahz) wrote:
>
> Nice!  Maybe stick this on the Cookbook?

http://code.activestate.com/recipes/576862/

Thanks for the suggestion,

Shai.
-- 
http://mail.python.org/mailman/listinfo/python-list

python database

[shai garcia]

can you pls help me to make a database program in python? It is a Quiz system 
which is database driven. The program has a choices which add question, edit, 
delete, list, take a quiz, quiz results, and exit. in take a quiz 
choice,questions should be randomly displayed and the result and name of the 
examinee should be saved as well as the date and time taken. pls 
help..tnx.Godbless

Submitted via EggHeadCafe - Software Developer Portal of Choice 
Book Review: Excel 2010 - The Missing Manual [OReilly]
http://www.eggheadcafe.com/tutorials/aspnet/7d211741-221d-46c7-b9c3-d34bf84568be/book-review-excel-2010--the-missing-manual-oreilly.aspx
-- 
http://mail.python.org/mailman/listinfo/python-list

python database

[shai garcia]

can you pls help me to make a database program in python? It is a Quiz system 
which is database driven. The program has a choices which add question, edit, 
delete, list, take a quiz, quiz results, and exit. in take a quiz 
choice,questions should be randomly displayed and the result and name of the 
examinee should be saved as well as the date and time taken. pls 
help..tnx.Godbless

Submitted via EggHeadCafe - Software Developer Portal of Choice 
Kentico CMS for ASP.NET Sites
http://www.eggheadcafe.com/tutorials/aspnet/ee551a85-2206-446e-bc7d-c978f60ec671/kentico-cms-for-aspnet-sites.aspx
-- 
http://mail.python.org/mailman/listinfo/python-list