from:"Fuzzyman"

On Aug 5, 12:29 pm, Ryan heni...@yahoo.com wrote:
 In the context of descriptors, the __set__ method is not called for
 class attribute access. __set__ is only
 called to set the attribute on an instance instance of the owner class
 to a new value, value. WHY?

It's an unfortunate asymmetry in the descriptor protocol. You can
write class descriptors with behaviour on get, but not on set.

As others point out, metaclasses are an ugly way round this
(particularly given that *basically* a class can only have one
metaclass - so if you're inheriting from a class that already has a
custom metaclass you can't use this technique).

Michael Foord
--
http://voidspace.org.uk/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: set method is not called for class attribute access

On Aug 5, 1:16 pm, Duncan Booth duncan.bo...@invalid.invalid wrote:
 Ryan heni...@yahoo.com wrote:
  In the context of descriptors, the __set__ method is not called for
  class attribute access. __set__ is only
  called to set the attribute on an instance instance of the owner class
  to a new value, value. WHY? Is there some other mechanism for
  accomplishing this outcome. This subtle difference from __get__cost me
  some time to track down. Might think about pointing that out the
  documentation.

  class RevealAccess(object):
      A data descriptor that sets and returns values
         normally and prints a message logging their access.
      

      def __init__(self, initval=None, name='var'):
          self.val = initval
          self.name = name

      def __get__(self, obj, objtype):
          print 'Retrieving', self.name
          return self.val

      def __set__(self, obj, val):
          print 'Updating' , self.name
          self.val = val

  class MyClass(object):
      x = RevealAccess(10, 'var x')
      y = 5

  print MyClass.x
  MyClass.x = 20
  print MyClass.x
  MyClass.x = 30
  print MyClass.x

  Retrieving var x
  10
  20
  30

  I am at a lost on how to intercept class attribute sets. Can anyone
  help :-/

 The descriptor protocol only works when a value is being accessed or set
 on an instance and there is no instance attribute of that name so the
 value is fetched from the underlying class.


That's not true. Properties, for example, can be got or set even when
they shadow an instance attribute. You're (probably) thinking of
__getattr__ which isn't invoked when an instance attribute exists.

Also, the descriptor protocol *is* invoked for getting an attribute
from a class - but not when setting a class attribute. An unfortunate
asymmetry. It just wasn't considered as a use case when the descriptor
protocol was implemented.

Michael
--
http://voidspace.org.uk/

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

Re: how to dynamically generate name for an object?

On Aug 7, 4:06 am, Eric Snow ericsnowcurren...@gmail.com wrote:
 Thought I knew how to provide a dynamic __name__ on instances of a
 class.  My first try was to use a non-data descriptor:

 # module base.py

 class _NameProxy(object):
     def __init__(self, oldname):
         self.oldname = oldname
     def __get__(self, obj, cls):
         if obj is None:
             return self.oldname
         if __name__ not in obj.__dict__:
             return str(obj.__context__)
         return obj.__name__

 class _BaseMeta(type):
     def __init__(cls, name, bases, namespace):
         cls.__name__ = _NameProxy(name)

 class Base(object):
     __metaclass__ = _BaseMeta

 $ python _base.py
 Traceback (most recent call last):
   ...
   File /usr/local/lib/python2.4/site-packages/base.py, line xx, in __init__
     cls.__name__ = _NameProxy(name)
 TypeError: Error when calling the metaclass bases
     can only assign string to Base.__name__, not '_NameProxy'

 Needless to say I was surprised.  After looking in typeobject.c, I
 believe that __name__ must be a string where classes are concerned[1].
  So if I want all my instances to have a __name__ attribute, and for
 it to be dynamically provided if it isn't set on the instance, what
 are my options?  Or maybe I did something wrong and it should work as
 I expected?


__name__ can be a descriptor, so you just need to write a descriptor
that can be fetched from classes as well as instances.

Here's an example with a property (instance only):

 class Foo(object):
...   @property
...   def __name__(self):
... return 'bar'
...
 Foo().__name__
'bar'

Michael
--
http://voidspace.org.uk/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: how to dynamically generate name for an object?

On Aug 10, 4:25 pm, Ian Kelly ian.g.ke...@gmail.com wrote:
 On Wed, Aug 10, 2011 at 8:48 AM, Fuzzyman fuzzy...@gmail.com wrote:
  __name__ can be a descriptor, so you just need to write a descriptor
  that can be fetched from classes as well as instances.

  Here's an example with a property (instance only):

  class Foo(object):
  ...   @property
  ...   def __name__(self):
  ...     return 'bar'
  ...
  Foo().__name__
  'bar'

 But:

  Foo.__name__
 'Foo'

That's why I said you just need to _write_ a descriptor that can be
fetched from classes as well as instances. The example with property
was to show that it *could* be a descriptor. You can write descriptors
with custom behaviour when fetched from a class.

However it turns out that you're right and I'm wrong; __name__ is
special:

 class descriptor(object):
...  def __get__(*args):
...   return 'bar'
...
 class Foo(object):
...  __name__ = descriptor()
...
 Foo.__name__
'Foo'
 Foo().__name__
'bar'
 class Foo(object):
...  name = descriptor()
...
 Foo.name
'bar'

As Eric points out in his original slot, types have their __name__
slot filled in with a string in typeobject.c

All the best,

Michael
--
http://voidspace.org.uk/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: set method is not called for class attribute access

On Aug 10, 5:27 pm, Eric Snow ericsnowcurren...@gmail.com wrote:
 On Wed, Aug 10, 2011 at 8:33 AM, Fuzzyman fuzzy...@gmail.com wrote:
  On Aug 5, 12:29 pm, Ryan heni...@yahoo.com wrote:
  In the context of descriptors, the __set__ method is not called for
  class attribute access. __set__ is only
  called to set the attribute on an instance instance of the owner class
  to a new value, value. WHY?

  It's an unfortunate asymmetry in the descriptor protocol. You can
  write class descriptors with behaviour on get, but not on set.

  As others point out, metaclasses are an ugly way round this
  (particularly given that *basically* a class can only have one
  metaclass - so if you're inheriting from a class that already has a
  custom metaclass you can't use this technique).

 Keep in mind that you can still do something like this:

 class XMeta(Base.__class__):
     Customize here

 class X(Base, metaclass=XMeta):
     Do your stuff.

 They you would put your descriptor hacking in XMeta and still take
 advantage of the original metaclass.

Yeah, the way round the more than one metaclass problem is to have
your new metaclass inherit from the first one. That's not a general
purpose solution though.

Michael
--
http://voidspace.org.uk/
-- 
http://mail.python.org/mailman/listinfo/python-list

ANN: mock 0.7.0 final release

2011-03-22 Thread Fuzzyman

Yay for conference driven development, I got the final release of mock
0.7.0 done in time for PyCon. No api changes since the release
candidate. The only changes are documentation improvements (double
yay!)

* http://pypi.python.org/pypi/mock/ (download)
* http://www.voidspace.org.uk/python/mock/ (documentation)
* https://code.google.com/p/mock/ (repo and issue tracker)

At PyCon I gave a talk on mock. It was an intro talk on how to use
mock and why you should use it, but also covered some of the shiny new
features in 0.7.0. The video of the talk is up (thanks to the PyCon
video team):

* PyCon Video: Testing with mock https://blip.tv/file/4881513

Here's the release announcement for mock 0.7.0 final.

mock is a Python library for simple mocking and patching (replacing
objects with mocks during test runs). The headline features in 0.7.0
are Python 3 support and the ability to mock magic methods. You can
now mock objects that behave like containers or are used as context
managers. mock is designed for use with unittest, based on the action
- assertion pattern rather than record - replay. People are
happily using mock with Python test frameworks like nose and py.test.
0.7.0 is a major new release with a bunch of other new features and
bugfixes as well.


The big change since 0.7.0 rc 1 is documentation changes including a
stylish
new Sphinx theme. https://github.com/coordt/ADCtheme/

Three new pages particularly worth looking at are:

* Mocking Magic Methods http://www.voidspace.org.uk/python/mock/magicmock.html
* Further examples of mock http://www.voidspace.org.uk/python/mock/examples.html
* Comparison with other mock frameworks 
http://www.voidspace.org.uk/python/mock/compare.html

The full set of changes since 0.6.0 are:

http://www.voidspace.org.uk/python/mock/changelog.html#version-0-7-0

* Python 3 compatibility
* Ability to mock magic methods with `Mock` and addition of
`MagicMock`
  with pre-created magic methods
* Addition of `mocksignature` and `mocksignature` argument to `patch`
and
  `patch.object`
* Addition of `patch.dict` for changing dictionaries during a test
* Ability to use `patch`, `patch.object` and `patch.dict` as class
decorators
* Renamed ``patch_object`` to `patch.object` (``patch_object`` is
  deprecated)
* Addition of soft comparisons: `call_args`, `call_args_list` and
`method_calls`
  now return tuple-like objects which compare equal even when empty
args
  or kwargs are skipped
* patchers (`patch`, `patch.object` and `patch.dict`) have start and
stop
  methods
* Addition of `assert_called_once_with` method
* Mocks can now be named (`name` argument to constructor) and the name
is used
  in the repr
* repr of a mock with a spec includes the class name of the spec
* `assert_called_with` works with `python -OO`
* New `spec_set` keyword argument to `Mock` and `patch`. If used,
  attempting to *set* an attribute on a mock not on the spec will
raise an
  `AttributeError`
* Mocks created with a spec can now pass `isinstance` tests
(`__class__`
  returns the type of the spec)
* Added docstrings to all objects
* Improved failure message for `Mock.assert_called_with` when the mock
  has not been called at all
* Decorated functions / methods have their docstring and `__module__`
  preserved on Python 2.4.
* BUGFIX: `mock.patch` now works correctly with certain types of
objects that
  proxy attribute access, like the django settings object
* BUGFIX: mocks are now copyable (thanks to Ned Batchelder for
reporting and
  diagnosing this)
* BUGFIX: `spec=True` works with old style classes
* BUGFIX: ``help(mock)`` works now (on the module). Can no longer use
``__bases__``
  as a valid sentinel name (thanks to Stephen Emslie for reporting and
  diagnosing this)
* BUGFIX: ``side_effect`` now works with ``BaseException`` exceptions
like
  ``KeyboardInterrupt``
* BUGFIX: `reset_mock` caused infinite recursion when a mock is set as
its own
  return value
* BUGFIX: patching the same object twice now restores the patches
correctly
* with statement tests now skipped on Python 2.4
* Tests require unittest2 (or unittest2-py3k) to run
* Tested with `tox http://pypi.python.org/pypi/tox`_ on Python 2.4 -
3.2,
  jython and pypy (excluding 3.0)
* Added 'build_sphinx' command to setup.py (requires setuptools or
distribute)
  Thanks to Florian Bauer
* Switched from subversion to mercurial for source code control
* `Konrad Delong http://konryd.blogspot.com/`_ added as co-maintainer
-- 
http://mail.python.org/mailman/listinfo/python-announce-list

Support the Python Software Foundation:
http://www.python.org/psf/donations/

ANN: mock 0.7.0 release candidate 1

2011-02-25 Thread Fuzzyman

There is a new release of mock: mock 0.7.0 rc1

http://pypi.python.org/pypi/mock

This is intended to be the last release of mock before 0.7.0 final and
the only changes anticipated are documentation changes which I've
finally started work on.

mock is a Python library for simple mocking and patching (replacing
objects with mocks during test runs). The headline features in 0.7.0
are Python 3 support and the ability to mock magic methods. You can
now mock objects that behave like containers or are used as context
managers. mock is designed for use with unittest, based on the action
- assertion pattern rather than record - replay. People are
happily using mock with Python test frameworks like nose and py.test.
0.7.0 is a major new release with a bunch of other new features and
bugfixes as well.

http://pypi.python.org/pypi/mock/ (download)
http://www.voidspace.org.uk/python/mock/ (documentation)
https://code.google.com/p/mock/ (repo and issue tracker)

Changelog:

http://www.voidspace.org.uk/python/mock/changelog.html#version-0-7-0-rc-1

Changes since beta 4:

* Tested with jython, pypy and Python 3.2 and 3.1
* Decorated functions / methods have their docstring and __module__
preserved on Python 2.4
* BUGFIX: mock.patch now works correctly with certain types of objects
that proxy attribute access, like the django settings object
* BUGFIX: reset_mock caused infinite recursion when a mock is set as
its own return value

Michael Foord
-- 
http://mail.python.org/mailman/listinfo/python-announce-list

Support the Python Software Foundation:
http://www.python.org/psf/donations/

Re: Interrput a thread

2011-01-04 Thread Fuzzyman

On Dec 29 2010, 11:31 pm, gervaz ger...@gmail.com wrote:
 Hi all, I need to stop a threaded (using CTR+C or kill) application if
 it runs too much or if I decide to resume the work later.
 I come up with the following test implementation but I wanted some
 suggestion from you on how I can implement what I need in a better or
 more pythonic way. Here the code:

This is a case that .NET (C#) handles better than Python or Java.

It is unsafe to terminate an os level thread at an arbitrary point
because it may be executing code in a critical section. Both Java
and .NET used to provide ways to terminate threads safely by raising
an asynchronous exception in the thread. Releasing locks (etc) that
the thread holds could then be done in a finally section protecting
the code. Python doesn't allow you to abort threads.

Unfortunately the thread abort exception could also be raised in the
finally section - prematurely aborting the lock / resource cleanup.

Java handled this by deprecating thread aborting. (Python has never
had it I believe.)

.NET handled it by changing the semantics of thread aborting - the
thread abort exception will never be raised in a finally block. This
makes thread aborting safe, although technically you can subvert it by
putting all your code in a finally block (you can also catch and
cancel the thread abort exception).

The standard advice is to use a flag and do manual checking to abort
threads. This only works for fine grained operations and *doesn't*
work for very coarse grained operations or where there aren't
convenient places to check the flag. It's another place where people
sometimes have a genuine need/use case yet people will insist on
telling them they don't *really* want it...

Anyway, although there are ways based on ctypes to abort Python
threads it's not really safe. If you google you should find them,
hopefully with intelligible caveat emptor warnings...

All the best,

Michael Foord



 import os
 import signal
 import time
 from threading import Thread, current_thread
 from queue import LifoQueue, Empty

 COMMAND = {STOP: 0, NORMAL: 1}
 THREAD_NUM = 5

 lq = LifoQueue()

 print({0}\n.format(os.getpid()))

 class InterceptInterrupt(Exception):
     pass

 class Handler:
     def __init__(self, queue):
         self._queue = queue
     def __del__(self):
         print(Bye bye!)
     def getHandler(self, signum, frame):
         print(Interrupt raised!)
         for _ in range(THREAD_NUM):
             self._queue.put((COMMAND[STOP], None))
         raise InterceptInterrupt

 h = Handler(lq)

 signal.signal(signal.SIGINT, h.getHandler)

 for i in range(25):
     lq.put((COMMAND[NORMAL], i))

 def do_work(queue):
     while True:
         time.sleep(5)
         try:
             cmd, value = queue.get(block=False)
             if cmd == COMMAND[STOP]:
                 print({0}: STOP command
 received!.format(current_thread().name))
                 break
             elif cmd == COMMAND[NORMAL]:
                 print(value)
         except Empty:
             break

 threads = [Thread(target=do_work, args=(lq,)) for _ in
 range(THREAD_NUM)]

 for t in threads:
     t.start()

 while not lq.empty():
     try:
         time.sleep(1)
     except (IOError, InterceptInterrupt):
         break

 for t in threads:
     t.join()

 if lq.empty():
     print(The queue is empty.)
 else:
     print(The queue is NOT empty. Some additional work has to be
 done.)

 Thank you,
 Mattia

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

Re: Interrput a thread

2011-01-04 Thread Fuzzyman

On Jan 4, 3:12 pm, Fuzzyman fuzzy...@gmail.com wrote:
 On Dec 29 2010, 11:31 pm, gervaz ger...@gmail.com wrote:

  Hi all, I need to stop a threaded (using CTR+C or kill) application if
  it runs too much or if I decide to resume the work later.
  I come up with the following test implementation but I wanted some
  suggestion from you on how I can implement what I need in a better or
  more pythonic way. Here the code:

 This is a case that .NET (C#) handles better than Python or Java.


Heh, so one possible option is to use IronPython :-)

Michael Foord

 It is unsafe to terminate an os level thread at an arbitrary point
 because it may be executing code in a critical section. Both Java
 and .NET used to provide ways to terminate threads safely by raising
 an asynchronous exception in the thread. Releasing locks (etc) that
 the thread holds could then be done in a finally section protecting
 the code. Python doesn't allow you to abort threads.

 Unfortunately the thread abort exception could also be raised in the
 finally section - prematurely aborting the lock / resource cleanup.

 Java handled this by deprecating thread aborting. (Python has never
 had it I believe.)

 .NET handled it by changing the semantics of thread aborting - the
 thread abort exception will never be raised in a finally block. This
 makes thread aborting safe, although technically you can subvert it by
 putting all your code in a finally block (you can also catch and
 cancel the thread abort exception).

 The standard advice is to use a flag and do manual checking to abort
 threads. This only works for fine grained operations and *doesn't*
 work for very coarse grained operations or where there aren't
 convenient places to check the flag. It's another place where people
 sometimes have a genuine need/use case yet people will insist on
 telling them they don't *really* want it...

 Anyway, although there are ways based on ctypes to abort Python
 threads it's not really safe. If you google you should find them,
 hopefully with intelligible caveat emptor warnings...

 All the best,

 Michael Foord



  import os
  import signal
  import time
  from threading import Thread, current_thread
  from queue import LifoQueue, Empty

  COMMAND = {STOP: 0, NORMAL: 1}
  THREAD_NUM = 5

  lq = LifoQueue()

  print({0}\n.format(os.getpid()))

  class InterceptInterrupt(Exception):
      pass

  class Handler:
      def __init__(self, queue):
          self._queue = queue
      def __del__(self):
          print(Bye bye!)
      def getHandler(self, signum, frame):
          print(Interrupt raised!)
          for _ in range(THREAD_NUM):
              self._queue.put((COMMAND[STOP], None))
          raise InterceptInterrupt

  h = Handler(lq)

  signal.signal(signal.SIGINT, h.getHandler)

  for i in range(25):
      lq.put((COMMAND[NORMAL], i))

  def do_work(queue):
      while True:
          time.sleep(5)
          try:
              cmd, value = queue.get(block=False)
              if cmd == COMMAND[STOP]:
                  print({0}: STOP command
  received!.format(current_thread().name))
                  break
              elif cmd == COMMAND[NORMAL]:
                  print(value)
          except Empty:
              break

  threads = [Thread(target=do_work, args=(lq,)) for _ in
  range(THREAD_NUM)]

  for t in threads:
      t.start()

  while not lq.empty():
      try:
          time.sleep(1)
      except (IOError, InterceptInterrupt):
          break

  for t in threads:
      t.join()

  if lq.empty():
      print(The queue is empty.)
  else:
      print(The queue is NOT empty. Some additional work has to be
  done.)

  Thank you,
  Mattia

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

Re: Interrput a thread

2011-01-04 Thread Fuzzyman

On Jan 4, 3:31 pm, Roy Smith r...@panix.com wrote:
 In article
 2ebc11a5-1b45-4faa-97b9-c84f0db01...@k22g2000yqh.googlegroups.com,

  Fuzzyman fuzzy...@gmail.com wrote:
  It is unsafe to terminate an os level thread at an arbitrary point
  because it may be executing code in a critical section.
  [...]
  The standard advice is to use a flag and do manual checking to abort
  threads. This only works for fine grained operations and *doesn't*
  work for very coarse grained operations or where there aren't
  convenient places to check the flag.

 Another possibility is to not use threads!  If you

 1) Need asynchronous operation

 2) Need iterruptability

 3) Can't poll for an please stop signal

 You should look at running your thread as a separate process, which
 you can send a kill signal to when you want it to go away.  You can then
 communicate with it via pipes, sockets, shared memory segments, whatever.

 Threads are a wonderful invention, but they are not a panacea for all
 possible parallelism tasks.  Sometimes they're just the wrong tool.

However some tasks / algorithms are done much better with threads than
processes.

Asynchronous operations are good for IO bound concurrency but not for
CPU bound concurrency.

Michael Foord
--
http://www.voidspace.org.uk/

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

Re: what a cheap rule

2010-11-26 Thread Fuzzyman

On Nov 26, 1:10 am, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info wrote:
 On Thu, 25 Nov 2010 08:15:21 -0800, Yingjie Lan wrote:
  Intuition #1: as if you raise an exception type, and then match that
  type.
  It seems that no instances
  are involved here (Intuitively).

 Your intuition is not my intuition, nor does it match what Python
 actually does. You can only go so far on *guessing* what a programming
 statement does, sometimes you need to actually read the Fine Manual.

  See an example code here:

  try: raise KeyError
  except KeyError: pass

 As the documentation states, this creates an instance of KeyError.

     raise evaluates the first expression as the exception object.
     It must be either a subclass or an instance of BaseException.
     If it is a class, the exception instance will be obtained when
     needed by instantiating the class with no arguments.

 http://docs.python.org/py3k/reference/simple_stmts.html#the-raise-sta...

 So there is no semantic difference between raise KeyError and
 raise KeyError(). Why should there be? What practical difference would
 you expect?


There *can* be a difference though.

 raise UnicodeDecodeError
Traceback (most recent call last):
  File stdin, line 1, in module
TypeError: function takes exactly 5 arguments (0 given)

:-)


 You seem to have misunderstood both forms of the raise statement. Should
 we make exceptions illegal because you can't correctly guess what they do?

Sometimes people not being able to understand them is a good reason
for making things illegal (or rather for not making them legal in the
first place). I don't think it applies to this particular case though.

All the best,

Michael Foord

--
http://www.voidspace.org.uk/
-- 
http://mail.python.org/mailman/listinfo/python-list

ANN: mock 0.7.0 beta 4 release

2010-11-16 Thread Fuzzyman

I've released mock 0.7.0 beta 4. This is intended to be the last
release of 0.7.0 before the final.

http://pypi.python.org/pypi/mock/ (download)
http://www.voidspace.org.uk/python/mock/ (documentation)
https://code.google.com/p/mock/ (repo and issue tracker)

mock is a Python library for simple mocking and patching (replacing
objects with mocks during test runs). The headline features in 0.7.0
are Python 3 support and the ability to mock magic methods. You can
now mock objects that behave like containers or are used as context
managers. mock is designed for use with unittest, based on the action
- assertion pattern rather than record - replay. People are
happily using mock with Python test frameworks like nose and py.test.

0.7.0 is a major new release with a bunch of other new features and
bugfixes as well.

The latest beta is now up on PyPI. 0.7.0 beta 4 is intended to be the
last release before 0.7.0 final (read my lips - no new features), so
please try it out and report any issues.

The work remaining before the final release is updating the
documentation, especially the examples, to include the new features.

Changes since beta 3 are:

* patchers (patch, patch.object and patch.dict) have start and
stop methods
* Addition of assert_called_once_with method
* repr of a mock with a spec includes the class name of the spec
* assert_called_with works with python -OO
* New spec_set keyword argument to Mock and patch. If this is set,
attempting to set an attribute on a mock not on the spec will raise an
AttributeError
* Attributes and return value of a MagicMock are MagicMock objects
* Attempting to set an unsupported magic method now raises an
AttributeError
* patch.dict works as a class decorator
* Switched from subversion to mercurial for source code control
* BUGFIX: mocks are now copyable (thanks to Ned Batchelder for
reporting and diagnosing this)
* BUGFIX: spec=True works with old style classes
* BUGFIX: mocksignature=True can now patch instance methods via
patch.object

For more details, including full changelog since 0.6.0 and examples of
using the new start / stop methods on patchers, see the announcement
on my blog:

http://www.voidspace.org.uk/python/weblog/arch_d7_2010_11_13.shtml#e1193

All the best,

Michael Foord
-- 
http://mail.python.org/mailman/listinfo/python-announce-list

Support the Python Software Foundation:
http://www.python.org/psf/donations/

Re: Spreadsheet-style dependency tracking

2010-10-18 Thread Fuzzyman

On Oct 17, 12:35 pm, Florian Weimer f...@deneb.enyo.de wrote:
 * Chris Torek:

  In article 87y69xbz6h@mid.deneb.enyo.de
  Florian Weimer  f...@deneb.enyo.de wrote:
 Are there libraries which implement some form of spreadsheet-style
 dependency tracking?  The idea is to enable incremental updates to
 some fairly convoluted computation.  I hope that a general dependency
 tracking framework would avoid making the computation even more
 convoluted and difficult to change.

  Don't know of any libraries myself, but I wrote some code to do
  topological sort for dependencies, which I can paste here.  It
  is also worth noting that a lot of spreadsheets cheat: they just
  repeat a sheet-wide computation until values stop changing (or a
  cycle count limit runs out).

 I think most of the relevant implementations use dependency
 information to speed up incremental recomputation.  For instance,
 gnumeric seems to have code for this.  This is the part I'm most
 interested in.  I already have got an explicit ordering of the
 computations (fortunately, that part is fairly simple).

And note that the repeating sheet-wide computation is a feature not a
cheat (the default should still be to report cycles). Allowing
calculations to complete even in the presence of cycles can be very
useful.

Michael Foord
--
http://www.voidspace.org.uk/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: namespace hacking question

2010-10-01 Thread Fuzzyman

On Sep 30, 6:07 pm, kj no.em...@please.post wrote:
 This is a recurrent situation: I want to initialize a whole bunch
 of local variables in a uniform way, but after initialization, I
 need to do different things with the various variables.

 What I end up doing is using a dict:

 d = dict()
 for v in ('spam', 'ham', 'eggs'):
     d[v] = init(v)

 foo(d['spam'])
 bar(d['ham'])
 baz(d['eggs'])

 This is fine, but I'd like to get rid of the tedium of typing all
 those extra d['...']s.

 I.e., what I would *like* to do is something closer to this:

 d = locals()
 for v in ('spam', 'ham', 'eggs'):
     d[v] = init(v)

 foo(spam)
 bar(ham)
 baz(eggs)

 ...but this results in errors like NameError: global name 'spam' is
 not defined.

 But the problem is deeper than the fact that the error above would
 suggest, because even this fails:

 spam = ham = eggs = None
 d = locals()
 for v in ('spam', 'ham', 'eggs'):
     d[v] = init(v)

 foo(spam) # calls foo(None)
 bar(ham)  # calls bar(None)
 baz(eggs) # calls baz(None)

 In other words, setting the value of locals()['x'] does not set
 the value of the local variable x.

 I also tried a hack using eval:

 for v in ('spam', 'ham', 'eggs'):
     eval %s = init('%s') % (v, v)

 but the = sign in the eval string resulted in a SyntaxError:
 invalid syntax.

 Is there any way to use a loop to set a whole bunch of local
 variables (and later refer to these variables by their individual
 names)?


One way:

import sys
module = sys.modules[__name__]

for entry in ('spam', 'eggs', 'ham'):
setattr(module, entry, 'some value')


Michael Foord
--
http://www.voidspace.org.uk/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: grailbrowser now running under python 2.5 (probably above too)

2010-07-12 Thread Fuzzyman

On Jul 12, 1:21 am, rantingrick rantingr...@gmail.com wrote:
 On Jul 11, 5:28 pm,Fuzzymanfuzzy...@gmail.com wrote:

  But why hijack someone else's announcement to do that? Congratulations
  alone would have been great. However good your intentions your message
  came across as but it would really have been better if you had been
  doing something else instead

 Micheal i think you're just simply projecting some inner feelings on
 to my post resulting in a complete mis-understanding. And i *did not*
 say the project was useless, on the contrary i am very happy the OP
 resurrected this lost script. I only suggested a similar project that
 the OP *may* find to be interesting. Maybe not, but lets leave the
 decision for the OP, Ok.

Plenty of people have told you in multiple threads how you come
across. Eventually you have to realise that they aren't *all*
projecting... :-)

Michael
--
http://www.voidspace.org.uk/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: grailbrowser now running under python 2.5 (probably above too)

2010-07-11 Thread Fuzzyman

On Jul 11, 5:16 pm, rantingrick rantingr...@gmail.com wrote:
 On Jul 11, 9:01 am, a...@pythoncraft.com (Aahz) wrote:

  As usual, you would rather tell other people what to do instead of doing
  any work yourself.

 Dear God! My statement was intended to fetch responses like...

   Hey, that sounds like a great idea or \
   Hey, lets get hacking on this.

 I am so sick of you people constantly accusing me of being lazy. You
 don't even know me. Also i think you're really a bit jealous because i
 have the brass cohones to initiate a coding project without your
 express written permission. I will not allow myself to be brow beaten
 by anyone!

But why hijack someone else's announcement to do that? Congratulations
alone would have been great. However good your intentions your message
came across as but it would really have been better if you had been
doing something else instead

All the best,

Michael Foord
--
http://www.voidspace.org.uk/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The real problem with Python 3 - no business case for conversion (was I strongly dislike Python 3)

2010-07-07 Thread Fuzzyman

On Jul 5, 1:34 am, sturlamolden sturlamol...@yahoo.no wrote:
 On 5 Jul, 01:58, John Nagle na...@animats.com wrote:

       Exactly.

       The incompatible with all extension modules I need part
  is the problem right now.  A good first step would be to
  identify the top 5 or 10 modules that are blocking a move to
  Python 3 by major projects with many users.

 The big danger is Python 2.x becoming abandonware (2.7 being the final
 release) before major projects are ported. Using Python 2.x for new
 projects is not advisable (at least many will think so), and using 3.x
 is not possible. What to do? It's not a helpful situation for Python.

But Python 2.3, 2.4  2.5 are *already* abandonware and see *major*
use in many systems and businesses. Python development has always gone
ahead of what *some* people use - and they don't seem to mind that
they're using essentially abandoned versions of Python.

Now that 2.7 is out I *might* be able to persuade my current company
to migrate to 2.6 on the servers, and they're far faster at adopting
tech than many companies I know.

All the best,

Michael Foord
--
http://www.voidspace.org.uk
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Overriding setattr of a module - possible?

2010-06-19 Thread Fuzzyman

On Jun 18, 5:25 am, Gabriel Genellina gagsl-...@yahoo.com.ar
wrote:
 En Thu, 17 Jun 2010 07:12:23 -0300, Fuzzyman fuzzy...@gmail.com escribiï¿½:

  On Jun 17, 10:29 am, Gabriel Genellina gagsl-...@yahoo.com.ar
  wrote:
  En Thu, 17 Jun 2010 04:52:48 -0300, Alf P. Steinbach al...@start.no  
  escribiï¿½:

   But who would have thunk that Python *isn't dynamic enough*? :-)

  Yep... There are other examples too (e.g. the print statement in 2.x  
  bypasses sys.stdout.write;

  What do you mean by this? The print statement in 2.x does *not* bypass
  sys.stdout. It may use other methods besides write (writeln perhaps)
  but you can *definitely* override sys.stdout to capture the output
  from print statements.

 Suppose you want to implement a tee variant in Python: print output
 should go to stdout and also to some file (with timestamp added, just to
 be fancy). First attempt:

 py import sys
 py import time
 py
 py class tee(file):
 ...   def write(self, data):
 ...     file.write(self, '%s: %r\n' % (time.ctime(), data))
 ...     sys.__stdout__.write(data)
 ...
 py sys.stdout = tee('test.txt', 'w')
 py print Hello world
 py print Bye
 py ^Z

 D:\TEMPtype test.txt
 Hello world
 Bye

 Note:
 - no output to stdout inside the interpreter
 - no timestamp in the file

 This modified version works fine:

 py class tee():
 ...   def __init__(self, filename, mode):
 ...     self.file = open(filename, mode)
 ...   def write(self, data):
 ...     self.file.write('%s: %r\n' % (time.ctime(), data))
 ...     sys.__stdout__.write(data)

 What happened? When sys.stdout is an instance of some class inheriting
    from file (that is, isinstance(sys.stdout, file) is true) then the print
 statement ignores sys.stdout.write() completely -- instead it calls
 directly some C stdio functions (fwrite).
 The only way to influence 'print' is *not* to inherit from file in the
 first place.

 It's an optimization, sure.  I guess it is there before inheriting from
 builtin types was allowed (in such scenario, it's a perfectly valid
 optimization).  Now, perhaps the test for 'file' should be more strict,
 only taking the C shortcut when using an actual file instance, not a
 subclass of it.  This would allow the example above to work correctly.



Ah, so by bypasses you mean under certain specific circumstances
bypasses.  By all means file a bug report on this, I agree that
bypassing the optimization for file subclasses (assuming your
diagnosis is correct) would be a sensible approach.

All the best,

Michael


 --
 Gabriel Genellina

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

Re: Overriding setattr of a module - possible?

2010-06-17 Thread Fuzzyman

On Jun 17, 10:29 am, Gabriel Genellina gagsl-...@yahoo.com.ar
wrote:
 En Thu, 17 Jun 2010 04:52:48 -0300, Alf P. Steinbach al...@start.no  
 escribió:

  But who would have thunk that Python *isn't dynamic enough*? :-)

 Yep... There are other examples too (e.g. the print statement in 2.x  
 bypasses sys.stdout.write;


What do you mean by this? The print statement in 2.x does *not* bypass
sys.stdout. It may use other methods besides write (writeln perhaps)
but you can *definitely* override sys.stdout to capture the output
from print statements.

Michael Foord


 see also a recent thread Which objects are  
 expanded by double-star ** operator?)

 Most of them seem to be speed optimizations, some might be considered  
 subtle bugs. But in this case (global variable references) speed is so  
 critical than even the dict lookup is inlined; the code in ceval.c says:

 /* Inline the PyDict_GetItem() calls.
 WARNING: this is an extreme speed hack.
 Do not try this at home. */

 Python is dynamic but not so much as to make it crawl like a snail...

 --
 Gabriel Genellina

--
http://www.voidspace.org.uk/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python is cool!!

2010-05-09 Thread Fuzzyman

On Mar 23, 10:04 pm, geremy condra debat...@gmail.com wrote:
 On Tue, Mar 23, 2010 at 1:07 PM, Tim Golden m...@timgolden.me.uk wrote:
  On 23/03/2010 16:55, Jose Manuel wrote:

  I have been learning Python, and it is amazing  I am using the
  tutorial that comes with the official distribution.

  At the end my goal is to develop applied mathematic in engineering
  applications to be published on the Web, specially on app. oriented to
  simulations and control systems, I was about to start learning Java
  but I found Python which seems easier to learn that Java.

  Would it be easy to integrate Python in Web pages with HTML? I have
  read many info on Internet saying it is, and I hope so 

  You probably want to be looking at IronPython and Silverlight.
  In fact, the prolific Michael Foord has already produced an
  example of this, which gives you the Python tutorial online!

   http://trypython.org

  TJG

 Granted that I know next to nothing about webwork, but
 is there a reason why you recommended a competing,
 nonstandard technology rather than simply pointing him
 towards more standards compliant tools that exist to do
 exactly what he asked for? Seems a bit dodgy to
 advocate a closed solution when the alternative has 100%
 market share.



Maybe because it is a good tool and for the specific task it achieves
there is nothing close...

The closest is Skulpt which is very much an incomplete implementation
of Python that runs in the browser.

Michael Foord

--
http://voidspace.org.uk/blog
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Dreaming of new generation IDE

2010-02-10 Thread Fuzzyman

On Feb 3, 7:38 pm, Phlip phlip2...@gmail.com wrote:
 On Feb 3, 10:57 am, Adam Tauno Williams awill...@opengroupware.us
 wrote:

   Current editors suck because they can't see into the code and browse
   it - unless it's so statically typed it's painful.

  ?  I edit Python in MonoDevelop  2.2;  and I can browse my file,
  classes, etc...  So I don't know what you mean by can't see into the
  code.  It works pretty well.

  Of course it can't tell that I've set x = {an integer}, as that only
  happens at runtime.

   That's why I wrote this:
  http://www.oreillynet.com/onlamp/blog/2008/05/dynamic_languages_vs_ed...

 You just said that your code browsing works pretty well, except when
 it doesn't.

 Hence my blog entry. If your editor analyzed your code at runtime,
 instead of just static analysis, then it could see that x = an
 integer, or an object, no matter how dynamic your language.


The Wingware Wing IDE has an integrated debugger. The IDE does type
inferencing through static analysis to provide autocomplete and code
navigation features. If you run the code under the debugger it will
also use 'actual' type information to augment the static analysis.

Michael Foord

--
http://www.voidspace.org.uk/
-- 
http://mail.python.org/mailman/listinfo/python-list

ANN: mock 0.6.0, Python mocking and testing library

2009-08-22 Thread Fuzzyman

mock is a Python mock object library for testing, with additional
support for runtime monkey patching.

Most mocking libraries follow the ‘record - replay’ pattern of
mocking. I prefer the ‘action - assertion’ pattern, which is more
readable and intuitive; particularly when working with the Python
unittest module.

This release, version 0.6.0, is a minor release but with a few new
features:

* mock homepage http://www.voidspace.org.uk/python/mock/
* download http://www.voidspace.org.uk/downloads/mock-0.6.0.zip
* PDF documentation http://www.voidspace.org.uk/downloads/mock.pdf
* Google code project and SVN repository http://code.google.com/p/mock/

New in 0.6.0:

* New test layout compatible with test discovery
* Descriptors (static methods / class methods etc) can now be patched
and restored correctly
* Mocks can raise exceptions when called by setting side_effect to an
exception class or instance
* Mocks that wrap objects will not pass on calls to the underlying
object if an explicit return_value is set

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

ANN: discover 0.3.0 released, automatic test discovery for unittest

2009-08-20 Thread Fuzzyman

The discover module is a backport of the automatic test discovery from
the unittest module in Python-trunk (what will become Python 2.7 and
3.2).

The discover module should work on versions of Python 2.4 upwards:

* discover module on PyPI: http://pypi.python.org/pypi/discover

The discover module can be used to run all, or a subset, of your
unittest based tests automatically from the command line. See the PyPI
page for details.

Version 0.3.0 has two new features:

* Failing to import a file (e.g. due to a syntax error) no longer
halts discovery but is reported as an error.
* Discovery will not attempt to import test files whose names are not
valid Python identifiers, even if they match the pattern.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Is python buffer overflow proof?

2009-08-07 Thread Fuzzyman

On Aug 3, 10:04 pm, sturlamolden sturlamol...@yahoo.no wrote:
 On 2 Aug, 15:50, Jizzai jiz...@gmail.com wrote:

  Is a _pure_ python program buffer overflow proof?

  For example in C++ you can declare a char[9] to hold user input.
  If the user inputs 10+ chars a buffer overflow occurs.

 Short answer: NO

 Bounds checking on sequence types is a protection against buffer
 overflow, but is certainly not sufficient.

 The Python interpreter is written in C. Python extension modules are
 written in C (or something similar). If you find an unprotected buffer
 in this C code, you can possibly overflow this buffer. This can be
 used for nasty things like corrupting the stack and injecting
 malicious code. There is a reason why the Python sandbox (rexec and
 Bastion modules) was disabled in Python 2.3.

 IronPython and Jython provides better protection against buffer
 overflow than CPython, as these interpreters are written in safer
 languages (C# and Java). You thus get an extra layer of protection
 between the Python code and the unsafe C (used in JVM and .NET
 runtimes).

Well, both Java and .NET both have their own FFI that let you do
whatever you want (more or less).

Michael Foord
--
http://www.ironpythoninaction.com/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Is python buffer overflow proof?

2009-08-07 Thread Fuzzyman

On Aug 4, 6:06 am, John Nagle na...@animats.com wrote:
 Gabriel Genellina wrote:
  En Mon, 03 Aug 2009 18:04:53 -0300, sturlamolden sturlamol...@yahoo.no
  escribió:

  On 2 Aug, 15:50, Jizzai jiz...@gmail.com wrote:

  Is a _pure_ python program buffer overflow proof?

  For example in C++ you can declare a char[9] to hold user input.
  If the user inputs 10+ chars a buffer overflow occurs.

  Short answer: NO
  I disagree. You've just translated the responsability to check for
  buffer overflows, from the Python VM, to the Java VM or the .Net runtime
  (and all three suffered from buffer overruns and other problems in some
  way or another).

     A more useful question is whether the standard libraries are being
 run through any of the commercial static checkers for possible buffer
 overflows.

                                 John Nagle

Python has been run through valgrind which did expose (and result in
the fixing) of several theoretical problems.

Pure Python can be crashed (cause segfaults) in various ways - there
is even a directory of tests that do this in the test suite. I don't
think any are due to buffer overflows.

Michael Foord
--
http://www.ironpythoninaction.com/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: pyc files not automatically compiled on import

2009-07-26 Thread Fuzzyman

On Jul 26, 5:22 pm, Baz Walter baz...@ftml.net wrote:
 hello

 i thought that python automatically compiled pyc files after a module is
 successfully imported. what could prevent this happening?

 Python 2.6.1 (r261:67515, Apr 12 2009, 03:51:25)
 [GCC 4.3.2] on linux2
 Type help, copyright, credits or license for more information.
   import os
   os.mkdir('/home/baz/tmp/foo')
   os.chdir('/home/baz/tmp/foo')
   f = open('foo.py', 'w')
   f.write('print hello world\n')
   f.close()
   os.listdir('.')
 ['foo.py']
   import foo
 hello world
   os.listdir('.') # why no pyc file?
 ['foo.py']
   import py_compile
   py_compile.compile('foo.py')
   os.listdir('.')
 ['foo.py', 'foo.pyc']

Works for me I'm afraid (Mac OS X and Python 2.6).

Michael Foord
--
http://www.ironpythoninaction.com/
-- 
http://mail.python.org/mailman/listinfo/python-list

ANN: IronPython training in Stockholm 23-24th September

2009-07-20 Thread Fuzzyman

September 23-24th I'll be presenting a two day training session in
Stockholm (the training is in English) with addskills. It is aimed
at .NET developers looking to use IronPython for application
development, scripting, embedding, testing or just as another useful
tool. It will be a comprehensive training session for those with .NET
experience who are interested in making practical use of IronPython.

For more information please see:

* http://www.addskills.se/Utbildning/Kurs/?CourseID=469#
* http://www.voidspace.org.uk/python/weblog/arch_d7_2009_07_18.shtml#e1109

This course is about how to make the most of dynamic languages like
IronPython and IronRuby on the .NET framework; with a particular focus
on IronPython. The dynamic language runtime, which is being
incorporated into .NET 4.0 and is the basis of IronPython and
IronRuby, enables a new class of language to run on the .NET
framework. In the last few years dynamic languages have gained a
reputation for increased developer productivity and being easy to
learn. These new languages for the .NET framework have potential
applications in everything from scripting tasks to application
development to embedding in .NET programs as ready made scripting
engines.

Michael Foord
-- 
http://mail.python.org/mailman/listinfo/python-announce-list

Support the Python Software Foundation:
http://www.python.org/psf/donations/

discover: automatic test discovery for unittest

2009-06-21 Thread Fuzzyman

The discover module is a backport of the automatic test discovery from
python-trunk (what will become Python 2.7  3.2) to work with Python
2.4 or more recent (including Python 3.0).

Test discovery allows you to run all the unittest based tests (or just
a subset of them) in your project without you having to write your own
test collection or running machinery. Once installed, test discovery
can be invoked with ``python -m discover``. I've tested the discover
module with Python 2.4 and 3.0.

The discover module also implements the ``load_tests`` protocol which
allows you to customize test loading from modules and packages. Test
discovery and ``load_tests`` are implemented in the
``DiscoveringTestLoader`` which can be used from your own test
framework.

* discover module on PyPI http://pypi.python.org/pypi/discover

discover can be installed with pip or easy_install. After installing
switch the
current directory to the top level directory of your project and run::

   python -m discover
   python discover.py

This will discover all tests (with certain restrictions) from the
current
directory. The discover module has several options to control its
behavior (full
usage options are displayed with ``python -m discover -h``)::

Usage: discover.py [options]

Options:
  -v, --verboseVerbose output
  -s directory Directory to start discovery ('.' default)
  -p pattern   Pattern to match test files ('test*.py'
default)
  -t directory Top level directory of project (default to
   start directory)

For test discovery all test modules must be importable from the
top
level directory of the project.

For example to use a different pattern for matching test modules run::

python -m discover -p '*test.py'

(Remember to put quotes around the test pattern or shells like bash
will do
shell expansion rather than passing the pattern through to discover.)

Test discovery is implemented in
``discover.DiscoveringTestLoader.discover``. As
well as using discover as a command line script you can import
``DiscoveringTestLoader``, which is a subclass of
``unittest.TestLoader``, and
use it in your test framework.

This method finds and returns all test modules from the specified
start
directory, recursing into subdirectories to find them. Only test files
that
match *pattern* will be loaded. (Using shell style pattern matching.)

All test modules must be importable from the top level of the project.
If
the start directory is not the top level directory then the top level
directory must be specified separately.

The ``load_tests`` protocol allows test modules and packages to
customize how
they are loaded. This is implemented in
``discover.DiscoveringTestLoader.loadTestsFromModule``. If a test
module defines
a ``load_tests`` function then tests are loaded from the module by
calling
``load_tests`` with three arguments: `loader`, `standard_tests`,
`None`.

If a test package name (directory with `__init__.py`) matches the
pattern then the package will be checked for a ``load_tests``
function. If this exists then it will be called with *loader*,
*tests*,
*pattern*.

If ``load_tests`` exists then discovery does  *not* recurse into the
package,
``load_tests`` is responsible for loading all tests in the package.

The pattern is deliberately not stored as a loader attribute so that
packages can continue discovery themselves. *top_level_dir* is stored
so
``load_tests`` does not need to pass this argument in to
``loader.discover()``.

discover.py is maintained in a google code project (where bugs and
feature
requests should be posted): http://code.google.com/p/unittest-ext/

The latest development version of discover.py can be found at:
http://code.google.com/p/unittest-ext/source/browse/trunk/discover.py

Michael Foord
-- 
http://mail.python.org/mailman/listinfo/python-announce-list

Support the Python Software Foundation:
http://www.python.org/psf/donations/

Re: A Special Thanks

2009-04-21 Thread Fuzzyman

On Apr 21, 3:52 pm, a...@pythoncraft.com (Aahz) wrote:
 In article slrnguqvne.eol.n...@irishsea.home.craig-wood.com,
 Nick Craig-Wood  n...@craig-wood.com wrote:



 Python also converted me to using unit tests.  If you add unit tests
 into your methodology above then when you re-organize (or refactor to
 use the modern jargon) the code you can be 100% sure that you didn't
 break anything which is a wonderful feeling.

 Not quite: you can be 100% sure you didn't break anything you had
 appropriate tests for.  If you use pure TDD (test-driven development),
 you can be pretty close to 100% comfortable, but my impression is that
 few people do pure TDD.

Few is obviously a relative term. Amongst some of the circles I move
in it is genuinely most - but a lot of them are using C#. The Python
community, whilst having a strong testing culture, seems to be a bit
behind the times with TDD.

*Personally* it has changed the way I develop dramatically; and
despite the name is much more about the way you approach design than
purely for the sake of tests.

But there you go. :-)

Michael Foord
--
http://www.ironpythoninaction.com/

 --
 Aahz (a...@pythoncraft.com)           *        http://www.pythoncraft.com/

 If you think it's expensive to hire a professional to do the job, wait
 until you hire an amateur.  --Red Adair

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

ANN: Mock 0.5.0 Release

2009-04-20 Thread Fuzzyman

Mock 0.5.0 has just been released.

* Mock Homepage http://www.voidspace.org.uk/python/mock/
* Download Mock 0.5.0 release (zip) 
http://www.voidspace.org.uk/downloads/mock-0.5.0.zip
* Mock Documentation as a PDF http://www.voidspace.org.uk/downloads/mock.pdf
* Mock entry on PyPI http://pypi.python.org/pypi/mock/
* Repository and Issue Tracker on Google Code http://code.google.com/p/mock/

This *isn't* backwards compatible as it cleans up the API in a few
ways, but they're all good changes I promise.

One of the new features is that the Mock class now supports wrapping
objects; using the ``wraps`` keyword.

Mock is a library for the creation of simple mock objects that track
how they are used so that you can make assertions. It uses the action -
 assertion pattern rather than the record - replay pattern. Action -
 assertion puts your tests after you have used the objects, which
seems more natural and means that you can make assertions about only
the behavior you are interested in. Mock also contains two decorators
(``patch`` and ``patch_object``) which make it easy to safely mock out
dependencies in the module under test purely within the scope of the
test itself (unpatching is done automatically on exit whether or not
the test passes). One of the changes in this release is that these
decorators also become context managers allowing them to be used with
the 'with statement'.

Mock can be installed with:

``easy_install mock``

The changelog for all changes in this release is:

* Made DEFAULT part of the public api.
* Documentation built with Sphinx.
* ``side_effect`` is now called with the same arguments as the mock is
called with and
  if returns a non-DEFAULT value that is automatically set as the
``mock.return_value``.
* ``wraps`` keyword argument used for wrapping objects (and passing
calls through to the wrapped object).
* ``Mock.reset`` renamed to ``Mock.reset_mock``, as reset is a common
API name.
* ``patch`` / ``patch_object`` are now context managers and can be
used with ``with``.
* A new 'create' keyword argument to patch and patch_object that
allows them to patch
  (and unpatch) attributes that don't exist. (Potentially unsafe to
use - it can allow
  you to have tests that pass when they are testing an API that
doesn't exist - use at
  your own risk!)
* The methods keyword argument to Mock has been removed and merged
with spec. The spec
  argument can now be a list of methods or an object to take the spec
from.
* Nested patches may now be applied in a different order (created
mocks passed
  in the opposite order). This is actually a bugfix.
* patch and patch_object now take a spec keyword argument. If spec is
  passed in as 'True' then the Mock created will take the object it is
replacing
  as its spec object. If the object being replaced is a class, then
the return
  value for the mock will also use the class as a spec.
* A Mock created without a spec will not attempt to mock any magic
methods / attributes
  (they will raise an ``AttributeError`` instead).

Many thanks to all those who gave feedback, feature requests and
patches!

What *isn't* in 0.5.0 is support for mocking magic methods. I do have
a technique in mind for this, which I implemented for the container
methods. It is very clean, but different from the pattern used to mock
out other methods. As I'm not currently using it I'm going to wait
until I need it and see if it works well in practise.

If you're interested in trying it, the code (with full documentation)
in a 'magics branch':

* http://code.google.com/p/mock/source/browse/#svn/branches/magics
--
http://mail.python.org/mailman/listinfo/python-announce-list

Support the Python Software Foundation:
http://www.python.org/psf/donations.html

ANN: Mock 0.5.0 Release

2009-04-19 Thread Fuzzyman

Mock 0.5.0 has just been released.

* Mock Homepage http://www.voidspace.org.uk/python/mock/
* Download Mock 0.5.0 release (zip) 
http://www.voidspace.org.uk/downloads/mock-0.5.0.zip
* Mock Documentation as a PDF http://www.voidspace.org.uk/downloads/mock.pdf
* Mock entry on PyPI http://pypi.python.org/pypi/mock/
* Repository and Issue Tracker on Google Code http://code.google.com/p/mock/

This *isn't* backwards compatible as it cleans up the API in a few
ways, but they're all good changes I promise. {sm;:wink:}

One of the new features is that the Mock class now supports wrapping
objects; using the ``wraps`` keyword.

One of the other big changes is that the documentation is now built
with the ever-wonderful Sphinx, so the homepage is new and there also
a PDF of the documentation.

Mock is a library for the creation of simple mock objects that track
how they are used so that you can make assertions. It uses the action -
 assertion pattern rather than the record - replay pattern. Action -
 assertion puts your tests after you have used the objects, which
seems more natural and means that you can make assertions about only
the behavior you are interested in. Mock also contains two decorators
(``patch`` and ``patch_object``) which make it easy to safely mock out
dependencies in the module under test purely within the scope of the
test itself (unpatching is done automatically on exit whether or not
the test passes). One of the changes in this release is that these
decorators also become context managers allowing them to be used with
the 'with statement'.

Mock can be installed with:

``easy_install mock``

The changelog for all changes in this release is:

* Made DEFAULT part of the public api.
* Documentation built with Sphinx.
* ``side_effect`` is now called with the same arguments as the mock is
called with and
  if returns a non-DEFAULT value that is automatically set as the
``mock.return_value``.
* ``wraps`` keyword argument used for wrapping objects (and passing
calls through to the wrapped object).
* ``Mock.reset`` renamed to ``Mock.reset_mock``, as reset is a common
API name.
* ``patch`` / ``patch_object`` are now context managers and can be
used with ``with``.
* A new 'create' keyword argument to patch and patch_object that
allows them to patch
  (and unpatch) attributes that don't exist. (Potentially unsafe to
use - it can allow
  you to have tests that pass when they are testing an API that
doesn't exist - use at
  your own risk!)
* The methods keyword argument to Mock has been removed and merged
with spec. The spec
  argument can now be a list of methods or an object to take the spec
from.
* Nested patches may now be applied in a different order (created
mocks passed
  in the opposite order). This is actually a bugfix.
* patch and patch_object now take a spec keyword argument. If spec is
  passed in as 'True' then the Mock created will take the object it is
replacing
  as its spec object. If the object being replaced is a class, then
the return
  value for the mock will also use the class as a spec.
* A Mock created without a spec will not attempt to mock any magic
methods / attributes
  (they will raise an ``AttributeError`` instead).

Many thanks to all those who gave feedback, feature requests and
patches!

What *isn't* in 0.5.0 is support for mocking magic methods. I do have
a technique in mind for this, which I implemented for the container
methods. It is very clean, but different from the pattern used to mock
out other methods. As I'm not currently using it I'm going to wait
until I need it and see if it works well in practise.

If you're interested in trying it, the code (with full documentation)
in a 'magics branch':

* http://code.google.com/p/mock/source/browse/#svn/branches/magics
--
http://mail.python.org/mailman/listinfo/python-list

ANN: ConfigObj 4.6.0 and Validate 1.0.0 released

2009-04-18 Thread Fuzzyman

Finally a fresh release ConfigObj and Validate.

* ConfigObj Home page: http://www.voidspace.org.uk/python/configobj.html
* Validate Home page: http://www.voidspace.org.uk/python/validate.html

**ConfigObj** is a simple to use but powerful Python library for the
reading and writing of configuration (ini) files. Through **Validate**
it integrates a config file validation and type conversion system.

Features of ConfigObj include:

* Nested sections (subsections), to any level
* List values
* Multiple line values
* Full Unicode support
* String interpolation (substitution)
* Integrated with a powerful validation system

- including automatic type checking/conversion
- and allowing default values
- repeated sections

* All comments in the file are preserved
* The order of keys/sections is preserved
* Powerful ``unrepr`` mode for storing/retrieving Python data-types

Release 4.6.0 fixes bugs and adds new features, particularly making
configspec handling more flexible.

Full details on the changes can be found at:
http://www.voidspace.org.uk/python/weblog/arch_d7_2009_04_11.shtml#e1078

The changelog for ConfigObj 4.6.0 is:

* Pickling of ConfigObj instances now supported (thanks to Christian
Heimes)
* Hashes in confgspecs are now allowed (see note below)
* Replaced use of hasattr (which can swallow exceptions) with getattr
* ``__many__`` in configspecs can refer to scalars (ordinary values)
as well as sections
* You can use ``___many___`` (three underscores!) where you want to
use ``__many__`` as well
* You can now have normal sections inside configspec sections that use
``__many__``
* You can now create an empty ConfigObj with a configspec,
programmatically set values and then validate
* A section that was supplied as a value (or vice-versa) in the actual
config file would cause an exception during validation (the config
file is still broken of course, but it is now handled gracefully)
* Added ``as_list`` method
* Removed the deprecated ``istrue``, ``encode`` and ``decode`` methods
* Running test_configobj.py now also runs the doctests in the
configobj module
* Through the use of validate 1.0.0 ConfigObj can now validate multi-
line values

As the public API for Validate is stable, and there are no outstanding
issues or feature requests, I've bumped the version number to 1.0.0.
The full change log is:

* BUGFIX: can now handle multiline strings
* Addition of 'force_list' validation option
--
http://mail.python.org/mailman/listinfo/python-announce-list

Support the Python Software Foundation:
http://www.python.org/psf/donations.html

ANN: ConfigObj 4.6.0 and Validate 1.0.0 released

2009-04-17 Thread Fuzzyman

Finally a fresh release ConfigObj and Validate.

* ConfigObj Home page: http://www.voidspace.org.uk/python/configobj.html
* Validate Home page: http://www.voidspace.org.uk/python/validate.html

**ConfigObj** is a simple to use but powerful Python library for the
reading and writing of configuration (ini) files. Through **Validate**
it integrates a config file validation and type conversion system.

Features of ConfigObj include:

* Nested sections (subsections), to any level
* List values
* Multiple line values
* Full Unicode support
* String interpolation (substitution)
* Integrated with a powerful validation system

- including automatic type checking/conversion
- and allowing default values
- repeated sections

* All comments in the file are preserved
* The order of keys/sections is preserved
* Powerful ``unrepr`` mode for storing/retrieving Python data-types

Release 4.6.0 fixes bugs and adds new features, particularly making
configspec handling more flexible.

Full details on the changes can be found at:
http://www.voidspace.org.uk/python/weblog/arch_d7_2009_04_11.shtml#e1078

The changelog for ConfigObj 4.6.0 is:

* Pickling of ConfigObj instances now supported (thanks to Christian
Heimes)
* Hashes in confgspecs are now allowed (see note below)
* Replaced use of hasattr (which can swallow exceptions) with getattr
* ``__many__`` in configspecs can refer to scalars (ordinary values)
as well as sections
* You can use ``___many___`` (three underscores!) where you want to
use ``__many__`` as well
* You can now have normal sections inside configspec sections that use
``__many__``
* You can now create an empty ConfigObj with a configspec,
programmatically set values and then validate
* A section that was supplied as a value (or vice-versa) in the actual
config file would cause an exception during validation (the config
file is still broken of course, but it is now handled gracefully)
* Added ``as_list`` method
* Removed the deprecated ``istrue``, ``encode`` and ``decode`` methods
* Running test_configobj.py now also runs the doctests in the
configobj module
* Through the use of validate 1.0.0 ConfigObj can now validate multi-
line values

As the public API for Validate is stable, and there are no outstanding
issues or feature requests, I've bumped the version number to 1.0.0.
The full change log is:

* BUGFIX: can now handle multiline strings
* Addition of 'force_list' validation option
--
http://mail.python.org/mailman/listinfo/python-list

Re: llvm vs. parrot

2009-04-12 Thread Fuzzyman

On Apr 11, 12:16 am, Paul Watson paul.hermeneu...@gmail.com wrote:
 Is Parrot out of favor these days?  It appears that Google is going to
 use llvm.

 http://code.google.com/p/unladen-swallow/

Has Parrot ever been in favour?

Actually they're quite different things.

Michael
--
http://www.ironpythoninaction.com/
--
http://mail.python.org/mailman/listinfo/python-list

[ANN] IronPython in Action available

2009-04-11 Thread Fuzzyman

After two and a half years of work IronPython in Action is finally
available!

http://www.ironpythoninaction.com/

IronPython in Action is the first book (in English anyway...) on
IronPython. It is written by myself and my colleague Christian
Muirhead, with a foreword by Jim Hugunin (the original creator of
IronPython). The technical editor is Dino Viehland, core IronPython
developer.

Two of the chapters are available for free download:

* Chapter 1: A New Lanugage for .NET
* Chapter 7: Agile Testing - Where Dynamic Typing Shines

Links to the free chapters, and IronPython in Action on the Manning
site, Amazon.com and the Safari bookshelf are on the book website.

IronPython is the first of a new wave of dynamic languages for
the .NET framework, built on the Dynamic Language Runtime. IronPython
in Action is aimed at C# / VB.NET programmers interested in dynamic
languages and the possibilities of the DLR, plus Python programmers
wanting to take advantage of the .NET framework.

Michael Foord
--
http://mail.python.org/mailman/listinfo/python-announce-list

Support the Python Software Foundation:
http://www.python.org/psf/donations.html

Re: PyPy Progress (and Psyco)

2009-03-15 Thread Fuzzyman

On Mar 15, 3:46 pm, Gerhard Häring g...@ghaering.de wrote:
 andrew cooke wrote:
  This looks very promising -
 http://www.voidspace.org.uk/python/weblog/arch_d7_2009_03_14.shtml#e1063

  I am really looking forwards to PyPy having a final release.  I hope it
  happens.

 Me too. I doubt it, though. From an outside view, the project seems to
 lack focus. To me, it looks like a research platform, and producing a
 successor to CPython seems to be just one out of a dozen projects.

 -- Gerhard

Well, I know the guys involved and they are focused on making PyPy a
practical (and importantly a faster) alternative to CPython. It has
just taken a long time - but is finally showing real progress.

They did get distracted along the way, but one of things that happened
last year was a culling of a lot of the side projects that made it
harder to make progress on the core goals.

At the moment PyPy is the best hope for a native implementation of
Python with an effective JIT.

Michael Foord
--
http://www.ironpythoninaction.com/
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3: range objects cannot be sliced

2009-01-25 Thread Fuzzyman

On Jan 25, 2:28 pm, Alan G Isaac alan.is...@gmail.com wrote:
 On 1/16/2009 3:13 PM Alan G Isaac apparently wrote:
   It is documented:
  http://docs.python.org/3.0/library/stdtypes.html#sequence-types-str-b...

 But then again, the opposite is also documented,
 since `range` is a sequence type.  Quoting:

      Sequences also support slicing ...

      Some sequences also support “extended slicing”

 Is this a documentation bug, or a bug in `range`?
 (I'd think the latter.)

 Cheers,
 Alan Isaac

Where does the documentation say that range objects are sequences?
They're iterables.

Michael Foord
--
http://www.ironpythoninaction.com/
--
http://mail.python.org/mailman/listinfo/python-list

Re: vb2py status?

2009-01-17 Thread Fuzzyman

On Jan 17, 3:52 pm, Vito De Tullio zak.mc.kra...@libero.it wrote:
 Giampaolo Rodola' wrote:
   So is vb2py dead? If not, any idea when it'll support python 3?
  I don't know this vb2py, but you can do a 2 pass conversion
  [vb] - (vb2py) - [py2] - (2to3) - [py3]
  ...and presumibly get something which doesn't work at all. =)

 why?
 AFAIK there aren't problems into the 2to3 phase
 I don't think the resulted python code would be the best one, but at least
 it should work...

 --
 By ZeD

2to3 is far from perfect, and assuming the same is true of vb2py
(inevitably) then you get imperfection squared. :-)

Michael Foord
--
http://www.ironpythoninaction.com/
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3: range objects cannot be sliced

2009-01-16 Thread Fuzzyman

On Jan 16, 5:45 pm, Alan G Isaac alan.is...@gmail.com wrote:
 Is the behavior below expected? Documented?
 (The error msg is misleading.)
 Thanks,
 Alan Isaac

   x = range(20)
   s = slice(None,None,2)
   x[s]
 Traceback (most recent call last):
    File stdin, line 1, in module
 TypeError: sequence index must be integer, not 'slice'

Well, it has the same behaviour as the iterator returned by xrange in
Python 2.X - so expected I guess. The error message is also the same
in Python 2.X.

Michael Foord
--
http://www.ironpythoninaction.com/
--
http://mail.python.org/mailman/listinfo/python-list

Re: mod_pylite?

On Jan 2, 2:49 pm, excord80 excor...@gmail.com wrote:
[snip...]

 It sounds interesting, however, after reading a bit about it, I see
 that a large part of wsgi is providing a nice interface between web
 server and webapp. I don't think I need any such interface, or at
 least, a replacement for CGI. I just need something like CGI but with
 a persistent Python so the web server doesn't have to restart python
 for every request. And I don't need need it to work with anything else
 other than Apache.



And indeed that is exactly what mod_wsgi is / does. It does a bit more
- because CGI really isn't enough for most web apps these days, but
WSGI can be used very simply.

Michael Foord
--
http://www.ironpythoninaction.com/
--
http://mail.python.org/mailman/listinfo/python-list

Re: If your were going to program a game...

On Jan 2, 3:02 pm, J Kenneth King ja...@agentultra.com wrote:
 Tokyo Dan huff...@tokyo.email.ne.jp writes:
  If your were going to program a game in python what technologies would
  you use?

  The game is a board game with some piece animations, but no movement
  animation...think of a chess king exploding. The game runs in a
  browser in a window of a social site built around the game. The social
  site has login, chat, player stats, list of active games, etc. AND
  there is also be a desktop client that accesses the game server via
  the same communication mechanism (like an AIR-based desktop client/
  app) as the browser-based version - I guess using JSON/RPC.

 Ever see chess.com?

 I don't know what they're using in the backend, but the client is
 entirely javascript.

 You could probably roll your own python javascript compiler to suit your
 needs. It could probably even build up your own DSL for writing these
 games.

 It's a worthwhile project and I think there might be support for it from
 other developers.

There's a project called Pyjamas, and PyPy also has a Python to
Javascript compiler.

Imagine debugging it though - ouch. Just write some Javascript
already. ;-)

Michael Foord
--
http://www.ironpythoninaction.com/
--
http://mail.python.org/mailman/listinfo/python-list

Re: FW: python import sys.path

On Jan 2, 2:28 pm, John Machin sjmac...@lexicon.net wrote:
 On Jan 3, 1:09 am, Kelly, Brian brian.ke...@uwsp.edu wrote: After 
 following your suggestions I was able to confirm that the 2.5
  interpreter was being invoked. So then I grepped for all instances of python
  in the scripts that were imported as modules: from bacula_conf import *

  The calling script cleanup.py is invoking purge_client.py like an external
  script:

  def purgeAll(options, computer_name):
      cmd = python purge_client.py %s % computer_name
      if options.pretend  True:

 Who wrote that?

          error = os.system(cmd)
      else:
          _log.info(Done. No changes made due to --pretend flag.)

             error is not defined in this branch     if not error:  
 Splat!
          return True
      else:
          return False

  AArrgh! Try:

    return not error


That will still blow up with a NameError when the path doing the
logging is invoked.

How about:


def purgeAll(options, computer_name):
cmd = python purge_client.py %s % computer_name
if options.pretend != True:  # if not options.pretend (assuming it
is a bool)
error = os.system(cmd)
return not error

_log.info(Done. No changes made due to --pretend flag.)
return True


Michael
--
http://www.ironpythoninaction.com/
--
http://mail.python.org/mailman/listinfo/python-list

Re: Is there a better algorithm?

On Jan 2, 6:11 pm, Kottiyath n.kottiy...@gmail.com wrote:
 I have the following list of tuples:
 L = [(1, 2), (3, 4, 5), (6, 7)]

 I want to loop through the list and extract the values.
 The only algorithm I could think of is: for i in l:

 ...  u = None
 ...  try:
 ...   (k, v) = i
 ...  except ValueError:
 ...   (k, u, v) = i
 ...  print k, u, v
 -
 1 None 2
 3 4 5
 6 None 7
 -
 But, this algorithm doesnt look very beautiful - like say - for k, u,
 v in L:
 Can anyone suggest a better algorithm to get the values?

for i in l:
   u = None
   if len(i) == 2:
  k, v = i
   else:
   k, u, v = i

Best I could come up with.

Alternatively:

def mangle(i):
if len(i) == 3:
return i
k, v = i
return k, None, v

for i in l:
k, u, v = mangle(i)

I'm sure there is a clever one liner using the Python 2.5 ternary
expression syntax. On the other hand I'm not sure it would be very
readable, so a straightforward (if less clever) solution is probably
better.

Michael
--
http://www.ironpythoninaction.com/
--
http://mail.python.org/mailman/listinfo/python-list

Re: If your were going to program a game...

On Jan 2, 6:16 pm, Jean-Paul Calderone exar...@divmod.com wrote:
 On Fri, 2 Jan 2009 09:44:55 -0800 (PST), Fuzzyman fuzzy...@gmail.com wrote:
 On Jan 2, 3:02 pm, J Kenneth King ja...@agentultra.com wrote:
  Tokyo Dan huff...@tokyo.email.ne.jp writes:
   If your were going to program a game in python what technologies would
   you use?

   The game is a board game with some piece animations, but no movement
   animation...think of a chess king exploding. The game runs in a
   browser in a window of a social site built around the game. The social
   site has login, chat, player stats, list of active games, etc. AND
   there is also be a desktop client that accesses the game server via
   the same communication mechanism (like an AIR-based desktop client/
   app) as the browser-based version - I guess using JSON/RPC.

  Ever see chess.com?

  I don't know what they're using in the backend, but the client is
  entirely javascript.

  You could probably roll your own python javascript compiler to suit your
  needs. It could probably even build up your own DSL for writing these
  games.

  It's a worthwhile project and I think there might be support for it from
  other developers.

 There's a project called Pyjamas, and PyPy also has a Python to
 Javascript compiler.

 No, PyPy includes an RPython to JavaScript compiler.  RPython and Python are
 different languages.


Well valid RPython is valid Python - so different for some value of
different...

The advantage of PyPy is that it even does things like turn runtime
exceptions into Python exceptions, so it should be much easier to
debug. It is much more 'heavyweight' though.

Michael Foord
--
http://www.ironpythoninaction.com/
--
http://mail.python.org/mailman/listinfo/python-list

Re: Why not Ruby?

On Jan 1, 8:32 pm, Paul Rubin http://phr...@nospam.invalid wrote:
[snip...]
  Of course pythons list, dict, strings in my opinion just can't be beat,

 On many occasions I've wished for a functional dictionary
 implementation in Python, like Haskell's Data.Map.  One of these years
 I'll get around to writing one.

Care to save me the effort of looking it up and tell me what Data.Map
does that Python's dict doesn't?

I guess if it is functional then every mutation must copy and return a
new data structure? (Which will be much more efficient in Haskell than
in Python - Haskell can share most of the underlying data whereas
Python would have to create a new dict every time. At least it only
stores references.)

Michael Foord
--
http://www.ironpythoninaction.com/
--
http://mail.python.org/mailman/listinfo/python-list

Re: If your were going to program a game...

On Jan 1, 8:55 pm, Chris Rebert c...@rebertia.com wrote:
 On Thu, Jan 1, 2009 at 12:24 PM, excord80 excor...@gmail.com wrote:
  On Jan 1, 2:37 pm, Kay Schluehr kay.schlu...@gmx.net wrote:

  There is no solution to this problem from a Python perspective. Do
  what everyone does right now: [snip]

  It still surprises me that no one has implemented the solution for
  this yet.

  Maybe it's harder than it seems, but it *seeems* like it's just a
  matter of telling Firefox, hey, when you see this special html
  element that tells you to run this python code from the web, do it.
  Then have FF load up a python interpreter, sandbox it somehow (that
  is, limit it to only a safe subset of its std lib), it runs the code

 The sandbox it somehow part is significantly harder than you seem to
 believe it would be. Python tried previously with the rexec and
 Bastion modules, but they were found to be irreparably flawed and thus
 were removed.
 However, Google App Engine seems to have found at least a partial
 solution, but they're keeping it to themselves as far as I know, and
 it's server-side rather than client-side anyway.


PyPy allows *true* sandboxing, as does IronPython through AppDomains.
I wouldn't recommend either for 'in the browser' use though.

You can do client side programming in the browser with Silverlight.
It's great fun to program, and very flexible, but limited to Safari,
IE  Firefox on Mac and Windows. Moonlight is making good progress
which will bring Silverlight to Firefox on Linux - and eventually more
browsers and platforms.

Michael Foord
--
http://www.ironpythoninaction.com/
--
http://mail.python.org/mailman/listinfo/python-list

Re: If your were going to program a game...

On Jan 1, 10:24 pm, Aaron Brady castiro...@gmail.com wrote:
 On Jan 1, 2:55 pm, Chris Rebert c...@rebertia.com wrote:



  On Thu, Jan 1, 2009 at 12:24 PM, excord80 excor...@gmail.com wrote:
   On Jan 1, 2:37 pm, Kay Schluehr kay.schlu...@gmx.net wrote:

   There is no solution to this problem from a Python perspective. Do
   what everyone does right now: [snip]

   It still surprises me that no one has implemented the solution for
   this yet.

   Maybe it's harder than it seems, but it *seeems* like it's just a
   matter of telling Firefox, hey, when you see this special html
   element that tells you to run this python code from the web, do it.
   Then have FF load up a python interpreter, sandbox it somehow (that
   is, limit it to only a safe subset of its std lib), it runs the code

  The sandbox it somehow part is significantly harder than you seem to
  believe it would be. Python tried previously with the rexec and
  Bastion modules, but they were found to be irreparably flawed and thus
  were removed.

 Suppose you compiled a version with no file type and a reduced os
 module?

How would it be able to import? (I realise there is an answer to that
question, but it would require more changes than you might think.)

Python uses Python - so pulling bits out tends to break things...

Michael Foord
--
http://www.ironpythoninaction.com/
--
http://mail.python.org/mailman/listinfo/python-list

Re: Why not Ruby?

On Jan 2, 12:16 am, Steven D'Aprano st...@remove-this-
cybersource.com.au wrote:
 On Thu, 01 Jan 2009 12:32:53 -0800, Paul Rubin wrote:
  On many occasions I've wished for a functional dictionary implementation
  in Python, like Haskell's Data.Map.  One of these years I'll get around
  to writing one.

 You don't think Python's dict implementation is functional? That's pretty
 strange, Python dicts are the basis of much of the language. They
 certainly work, and work well, what makes you think they aren't
 functional? What does Data.Map do that dicts don't?


He almost certainly (I assume) means functional in the way that
Haskell is a functional language.

Michael Foord
--
http://www.ironpythoninaction.com/
--
http://mail.python.org/mailman/listinfo/python-list

Re: why cannot assign to function call

On Dec 29 2008, 9:34 am, John Machin sjmac...@lexicon.net wrote:
 On Dec 29, 5:01 pm, scsoce scs...@gmail.com wrote:

  I have a function return a reference,

 Stop right there. You don't have (and can't have, in Python) a
 function which returns a reference that acts like a pointer in C or C+
 +. Please tell us what manual, tutorial, book, blog or Usenet posting
 gave you that idea, and we'll get the SWAT team sent out straight
 away.

  and want to assign to the
  reference, simply like this:
   def f(a)
            return a

 That's not a very useful function, even after you fix the syntax error
 in the def statement. Would you care to give us a more realistic
 example of what you are trying to achieve?

       b = 0
      * f( b ) = 1*

 Is the * at the start of the line meant to indicate pointer
 dereferencing like in C? If not, what is it? Why is there a * at the
 end of the line?

  but the last line will be refused as can't assign to function call.
  In my thought , the assignment is very nature,

 Natural?? Please tell us why you would want to do that instead of:

     b = 1

  but  why the interpreter
  refused to do that ?

 Because (the BDFL be praised!) it (was not, is not, will not be) in
 the language grammar.

Although not being able to do the following has on occasion annoyed
me:

f(x) += 1

If the object returned by f(x) supports in place operations then it is
an entirely logical meaning, but not the interpreter can't know ahead
of time whether that is the case or not.

Michael Foord
--
http://www.ironpythoninaction.com/
--
http://mail.python.org/mailman/listinfo/python-list

Re: On Whose Desktop

2008-12-23 Thread Fuzzyman

On Dec 23, 12:06 pm, Steve Holden st...@holdenweb.com wrote:
 Thanks to Barry Warsaw the On Your Desktop blog now has a new entry:

  http://onyourdesktop.blogspot.com/

 Who would you like to see profiled next?

 regards
  Steve
 --
 Steve Holden        +1 571 484 6266   +1 800 494 3119
 Holden Web LLC              http://www.holdenweb.com/

Guido (of course), Brett Cannon, Martin v Loewis, Jim Hugunin, Ted
Leung, Dino Viehland (core developer of IronPython), Titus Brown, Ivan
Kristic, Mark Shuttleworth, Tim Golden, Michele Simionato, Thomas
Heller, Greg Ewing - any and all of these would be great.

Any women in Python you could ask - how about Anna Ravenscroft?

Conspicuously missing from the ones you have already done is Steve
Holden of course...

All the best,

Michael Foord
--
http://www.ironpythoninaction.com/
--
http://mail.python.org/mailman/listinfo/python-list

ANN: Resolver One Spreadsheet Challenge - win $17000

2008-12-18 Thread Fuzzyman

Resolver One is the Python powered spreadsheet created by Resolver
Systems.

Resolver One is a highly programmable spreadsheet program built with
IronPython. It is capable of creating powerful spreadsheet systems,
but is easy to program with Python and .NET libraries.

We’re convinced that Resolver One allows people to create astonishing
things that simply aren’t possible in a traditional spreadsheet
environment. And we want to prove it. Enter the Resolver One
Spreadsheet Challenge:

http://www.resolversystems.com/competition/

The Resolver One Challenge

We're so confident about the revolutionary potential of Resolver One
that we've set up the $25,000 Resolver One Challenge. Every month
between now and May, we will be giving away $2,000 for the best
spreadsheet we receive. And in late May, we'll be handing over $15,000
for the best of the best.
Let your imagination run wild

Build a blogging engine directly in Resolver One. Hook Resolver One up
to existing .NET or Python libraries in unusual ways. Build the game
of life, or a Mandelbrot viewer directly into the grid. Get Infocom
adventure games running inside a spreadsheet; or for that matter, have
a conversation with Eliza. Make a music player that does
visualisations in the cells.
Or something more businesslike?

Use the sophisticated web integration to pull of stock prices, or
integrate your spreadsheet with Google Maps. (Perhaps you could build
a spreadsheet that plots a map, showing in which part of the country
stock or house prices are rising or falling the most.) Build an
election predictor (and use a combination of Monte Carlo analysis and
the web front end to make it really special).

In other words: Resolver One gives you the tools, you just need to use
your imagination, and your Python and spreadsheet skills!

Resolver One is free to try and for non-commercial and Open Source
uses. You can download it from:

http://www.resolversystems.com/download/

To get you started with Resolver One we have a new tutorial. It takes
you through all the major features, with examples to try:

http://www.resolversystems.com/documentation/index.php/Tutorial.html

Michael Foord
Software Developer
Resolver Systems
--
http://mail.python.org/mailman/listinfo/python-announce-list

Support the Python Software Foundation:
http://www.python.org/psf/donations.html

Re: Looking for the best way to translate an idiom

2008-12-14 Thread Fuzzyman

On Dec 14, 5:51 pm, Paul  Moore p.f.mo...@gmail.com wrote:
 On 14 Dec, 16:22, Bruno Desthuilliers

 bdesth.quelquech...@free.quelquepart.fr wrote:
  if you only want the first returned value, you can just apply a slice:

  def f():
      return 1,2,3

  a = f()[0] + 1

 Hmm, true. I'm not sure it's any less ugly, though :-)

  FWIW, Python 2.6 has NamedTuple objects...

 I know, but I want to target 2.5+ (I still have a number of systems
 running 2.5)


There is a Python implementation of NamedTuple on the Python cookbook
that is compatible with Python 2.5.

Michael Foord
http://www.ironpythoninaction.com/
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3.0 crashes displaying Unicode at interactive prompt

2008-12-14 Thread Fuzzyman


 That's an interesting definition of crash. You're just like saying: C
 has crashed because I made a bug in my program. In this context, it is
 your program that crashes, not python nor C, it is misleading to say so.

 It will be python's crash if:
 1. Python 'segfault'ed
 2. Python interpreter exits before there is instruction to exit (either
 implicit (e.g. falling to the last line of the script) or explicit (e.g
 sys.exit or raise SystemExit))
 3. Python core dumped
 4. Python does something that is not documented

It seems to me to be a generally accepted term when an application
stops due to an unhandled error to say that it crashed.

Michael Foord
http://www.ironpythoninaction.com/
--
http://mail.python.org/mailman/listinfo/python-list

Re: Dabo 0.9.0 Released

2008-12-10 Thread Fuzzyman

On Dec 10, 7:24 pm, Ed Leafe [EMAIL PROTECTED] wrote:
 We are proud (and relieved!) to finally release Dabo 0.9.0, the first  
 official release of the framework in six months. We haven't been  
 taking it easy during that period; rather, we made some changes that  
 clean up some weak spots in the codebase, and as a result can offer a  
 much more solid framework, and are on course for a 1.0 release in the  
 near future.


Congratulations Ed and crew.

Michael Foord
--
http://www.ironpythoninaction.com/
--
http://mail.python.org/mailman/listinfo/python-list

Re: Exhaustive Unit Testing

On Nov 29, 3:33 am, Emanuele D'Arrigo [EMAIL PROTECTED] wrote:
 On Nov 29, 12:35 am, Fuzzyman [EMAIL PROTECTED] wrote:

  Your experiences are one of the reasons that writing the tests *first*
  can be so helpful. You think about the *behaviour* you want from your
  units and you test for that behaviour - *then* you write the code
  until the tests pass.

 Thank you Michael, you are perfectly right in reminding me this. At
 this particular point in time I'm not yet architecturally foresighted
 enough to be able to do that. While I was writing the design documents
 I did write the list of methods each object would have needed and from
 that description theoretically I could have made the tests first. In
 practice, while eventually writing the code for those methods, I've
 come to realize that there was a large amount of variance between what
 I -thought- I needed and what I -actually- needed. So, had I written
 the test before, I would have had to rewrite them again. That been
 said, I agree that writing the tests before must be my goal. I hope
 that as my experience increases I'll be able to know beforehand the
 behaviors I need from each method/object/module of my applications.
 One step at the time I'll get there... =)



Personally I find writing the tests an invaluable part of the design
process. It works best if you do it 'top-down'. i.e. You have a
written feature specification (a user story) - you turn this into an
executable specification in the form of a functional test.

Next to mid level unit tests and downwards - so your tests become your
design documents (and the way you think about design), but better than
a document they are executable. So just like code conveys intent so do
the tests (it is important that tests are readable).

For the situation where you don't really know what the API should look
like, Extreme Programming (of which TDD is part) includes a practise
called spiking. I wrote a bit about that here:

http://www.voidspace.org.uk/python/weblog/arch_d7_2007_11_03.shtml#e867

Mocking can help reduce the number of code paths you need to test for
necessarily complex code. Say you have a method that looks something
like:

def method(self):
if conditional:
# do stuff
else:
# do other stuff
# then do more stuff

You may be able to refactor this to look more like the following

def method(self):
if conditional:
self.method2()
else:
self.method3()
self.method4()

You can then write unit tests that *only* tests methods 2 - 4 on their
own. That code is then tested. You can then test method by mocking out
methods 2 - 4 on the instance and only need to test that they are
called in the right conditions and with the right arguments (and you
can mock out the return values to test that method handles them
correctly).

Mocking in Python is very easy, but there are plenty of mock libraries
to make it even easier. My personal favourite (naturally) is my own:

http://www.voidspace.org.uk/python/mock.html

All the best,

Michael
--
http://www.ironpythoninaction.com/



 Manu

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

Re: double import protection - how to ?

On Nov 29, 3:40 pm, Helmut Jarausch [EMAIL PROTECTED] wrote:
 Peter Otten wrote:
  Helmut Jarausch wrote:

  I have a module which gets imported at several different places
  not all of which are under my control.

  How can I achieve that  all/some statements within that module
  get executed only at the very first import?

  What you describe is Python's default behaviour. A module is executed once
  and then cached in sys.modules. The second import is then just a cache
  lookup.

  This may only fail if a module is imported under different names, typically
  when you have directory  in sys.path that is part of a package, or when you
  import the main script.

  Peter

 Thanks Steven, thanks Peter.

 Then it's a problem with a problem with a webserver written in Python 
 (Karrigell-3.0)
 and probably related to multi-threading (the statements in my module get 
 definitely
 executed more than once).


Python has an import lock - so multi-threaded code simultaneously
executing import statements only do the initial import once.

Michael Foord


 Thanks for your help,
 Helmut.

 --
 Helmut Jarausch

 Lehrstuhl fuer Numerische Mathematik
 RWTH - Aachen University
 D 52056 Aachen, Germany

--
http://www.ironpythoninaction.com/
--
http://mail.python.org/mailman/listinfo/python-list

Re: Pycon 2009

On Nov 29, 4:22 am, r [EMAIL PROTECTED] wrote:
 Sorry friend, i could not view your link, but if you are trying to
 garner support for python nobody here cares. I have already been
 lynched by the community for tying to promote python.

 see the 
 thread:http://groups.google.com/group/comp.lang.python/browse_thread/thread/...

 You will see exactly what i am talking about.

Yeah best to abandon this newsgroup and find somewhere else. Just for
kicks, come back in a few years and reread that thread. You might be a
bit surprised... ;-)

Ah the joys of the internet. Embarrassing us in the years to come.

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

Re: Windows Installer testing using python.

On Nov 28, 10:02 am, kalyan [EMAIL PROTECTED] wrote:
 Hi,

 How can we test Windows Installer using python.
 Is there any module available for testing?
 Please mail to [EMAIL PROTECTED]

 Thanks,
 Kalyan.

What do you need to test? We test our msi installers by automating
them from Python. We use the subprocess module to launch the
installers. We then test that the right files have been created and
the correct shortcuts pointing to the right locations. We then launch
the installed application (again with subprocess) and then use the
win32api to check that the application has started correctly.

Michael Foord
--
http://www.ironpythoninaction.com/
--
http://mail.python.org/mailman/listinfo/python-list

Re: Exhaustive Unit Testing

2008-11-28 Thread Fuzzyman

On Nov 27, 4:32 pm, Emanuele D'Arrigo [EMAIL PROTECTED] wrote:
 On Nov 27, 5:00 am, Steven D'Aprano

 [EMAIL PROTECTED] wrote:
  Refactor until your code is simple enough to unit-test effectively, then
  unit-test effectively.

 Ok, I've taken this wise suggestion on board and of course I found
 immediately ways to improve the method. -However- this generates
 another issue. I can fragment the code of the original method into one
 public method and a few private support methods. But this doesn't
 reduce the complexity of the testing because the number and complexity
 of the possible path stays more or less the same. The solution to this
 would be to test the individual methods separately, but is the only
 way to test private methods in python to make them (temporarily) non
 private? I guess ultimately this would only require the removal of the
 appropriate double-underscores followed by method testing and then
 adding the double-underscores back in place. There is no cleaner
 way, is there?

 Manu


Your experiences are one of the reasons that writing the tests *first*
can be so helpful. You think about the *behaviour* you want from your
units and you test for that behaviour - *then* you write the code
until the tests pass.

This means that your code is testable, but which usually means simpler
and better.

By the way, to reduce the number of independent code paths you need to
test you can use mocking. You only need to test the logic inside the
methods you create (testing behaviour), and not every possible
combination of paths.

Michael Foord
--
http://www.ironpythoninaction.com/
--
http://mail.python.org/mailman/listinfo/python-list

Re: Installing Python 2.6 on Vista

On Nov 9, 7:39 pm, Martin v. Löwis [EMAIL PROTECTED] wrote:
  Heh. Well it would, except the administrator user doesn't have a
  password (purely a VM) and this is unacceptable for runas. :-)

 There is, unfortunately, no other way to install Python 2.6 on Vista.
 So your choices are really:
 1. activate the Administrator account
 2. disable UAC
 3. go back to XP
 4. go back to Python 2.5

 Regards,
 Martin

It installs fine for 'just me', so no problem. I was just curious as
to why I couldn't install it for all users. Even for a VM I should
probably set an admin password.

Thanks

Michael
--
http://www.ironpythoninaction.com/
--
http://mail.python.org/mailman/listinfo/python-list

Installing Python 2.6 on Vista

Hello guys,

Not sure if this is a Windows question or a Python problem...

I'm trying to install Python 2.6 from the msi, on Windows Vista as an
administrative user with UAC on. If I try to install for all users
then I am told I don't have privileges to do that... (No UAC prompt.)

The only other user on the machine is the standard guest account, so
it isn't an issue, I just wondered why this would be?

Michael
--
http://www.ironpythoninaction.com/
--
http://mail.python.org/mailman/listinfo/python-list

Re: Installing Python 2.6 on Vista

On Nov 9, 6:23 pm, Guilherme Polo [EMAIL PROTECTED] wrote:
 On Sun, Nov 9, 2008 at 4:14 PM, Fuzzyman [EMAIL PROTECTED] wrote:
  Hello guys,

  Not sure if this is a Windows question or a Python problem...

  I'm trying to install Python 2.6 from the msi, on Windows Vista as an
  administrative user with UAC on. If I try to install for all users
  then I am told I don't have privileges to do that... (No UAC prompt.)

  The only other user on the machine is the standard guest account, so
  it isn't an issue, I just wondered why this would be?

 There is a Vista note inhttp://www.python.org/download/releases/2.6/

 runas /user:Administrator msiexec /i path\file.msi

Heh. Well it would, except the administrator user doesn't have a
password (purely a VM) and this is unacceptable for runas. :-)

Michael


 Does that work for you ?

  Michael
  --
 http://www.ironpythoninaction.com/
  --
 http://mail.python.org/mailman/listinfo/python-list

 --
 -- Guilherme H. Polo Goncalves

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

Re: Is psyco available for python 2.6?

On Nov 9, 2:18 pm, Anton Vredegoor [EMAIL PROTECTED] wrote:
 On Thu, 30 Oct 2008 17:45:40 +0100

 Gerhard Häring [EMAIL PROTECTED] wrote:
  psyco seems to just work on Linux with Python 2.6. So it is probably
  only a matter of compiling it on Windows for Python 2.6.

 Yes. I compiled it using wp setup.py build --compiler=mingw32 with
 cygwin, where wp was an alias for my windows xp python executable.

 For the OP and other people interested in windows binaries:

 I am in no way connected to or involved in the psyco development
 process -- except that I downloaded and compiled it -- but I have put a
 zip file on line for people who have a lot of trust in me and little
 patience for waiting for the official distribution. Just unpack it and
 put it in your site-packages directory.

 http://members.home.nl/anton.vredegoor/psyco/

 A.

I've built a Windows installer if anyone is interested:

http://www.voidspace.org.uk/python/modules.shtml

Michael
--
http://www.ironpythoninaction.com/
--
http://mail.python.org/mailman/listinfo/python-list

Re: Finding the instance reference of an object

2008-10-30 Thread Fuzzyman

On Oct 30, 1:13 am, Joe Strout [EMAIL PROTECTED] wrote:
 On Oct 29, 2008, at 4:52 PM, Fuzzyman wrote:

  You're pretty straightforwardly wrong. In Python the 'value' of a
  variable is not the reference itself.

 That's the misconception that is leading some folks around here into
 tangled nots of twisty mislogic, ultimately causing them to make up
 new terms for what every other modern language is perfectly happy
 calling Call-By-Value.

 I've thought a lot about why this misconception is so widespread here,
 and I think it must be one of the following:

 1. There was one community leader with this idea, who has been
 successful at promoting it widely, much to the detriment of all; or,

 2. Because everything in Python is an object, you're not forced to
 think clearly (and more generally) about references as values as you
 are in languages (such as Java, VB.NET, etc.) which have both simple
 types and object types.



But those languages clearly make the distinction between values and
references that you refuse to make! Go figure...

Michael

 Either way, it's wrong (or at least, a needlessly complicated way of
 looking at things).

  .NET does draw a distinction between 'value types' and reference types
  - where using reference types are called by reference (the reference
  is passed) and value types are called by value (the value itself is
  copied).

 Quite right.  Now, note that ByRef and ByVal apply to both.
 Generalize to Python.  There you go.

 Best,
 - Joe

 P.S. I really am trying to quit responding to this thread.  Sometimes
 the urge is too strong.  But I'll keep trying!

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

Re: Finding the instance reference of an object

2008-10-30 Thread Fuzzyman

On Oct 30, 1:13 am, Joe Strout [EMAIL PROTECTED] wrote:
 On Oct 29, 2008, at 4:52 PM, Fuzzyman wrote:

  You're pretty straightforwardly wrong. In Python the 'value' of a
  variable is not the reference itself.

 That's the misconception that is leading some folks around here into
 tangled nots of twisty mislogic, ultimately causing them to make up
 new terms for what every other modern language is perfectly happy
 calling Call-By-Value.

 I've thought a lot about why this misconception is so widespread here,
 and I think it must be one of the following:

 1. There was one community leader with this idea, who has been
 successful at promoting it widely, much to the detriment of all; or,

 2. Because everything in Python is an object, you're not forced to
 think clearly (and more generally) about references as values as you
 are in languages (such as Java, VB.NET, etc.) which have both simple
 types and object types.



To make it clearer for you, call by value means that the value is
copied in - and therefore changes to the value won't be visible to the
caller.

In .NET this is true of mutable value types - changes made are made to
a copy and not visible to the caller. In Python we *only* have
reference types, so changes to *any* mutable object are visible to the
caller.

In .NET you can call by reference with a value type - and the runtime
does boxing for you so that you can see the changes. You have to
explicitly ask for call by reference though.

Michael

 Either way, it's wrong (or at least, a needlessly complicated way of
 looking at things).

  .NET does draw a distinction between 'value types' and reference types
  - where using reference types are called by reference (the reference
  is passed) and value types are called by value (the value itself is
  copied).

 Quite right.  Now, note that ByRef and ByVal apply to both.
 Generalize to Python.  There you go.

 Best,
 - Joe

 P.S. I really am trying to quit responding to this thread.  Sometimes
 the urge is too strong.  But I'll keep trying!

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

Re: Finding the instance reference of an object

2008-10-29 Thread Fuzzyman

On Oct 28, 3:59 pm, Joe Strout [EMAIL PROTECTED] wrote:
 On Oct 27, 2008, at 11:28 PM, Gabriel Genellina wrote:



  En Tue, 28 Oct 2008 00:58:10 -0200, greg  
  [EMAIL PROTECTED] escribió:

  Let's look at the definitions of the terms:

  (1) Call by value: The actual parameter is an expression. It is
     evaluated and the result is assigned to the formal parameter.
     Subsequent assignments to the formal parameter do not affect
     the actual parameter.

  (2) Call by reference: The actual parameter is an lvalue. The
     formal parameter becomes an alias for the actual parameter,
     so that assigning to the formal parameter has the same
     effect as assigning to the actual parameter.

  Seems to me that (1) describes exactly how parameter passing
  works in Python. So why insist that it's *not* call by value?

 Greg is right on the money here.  It really is as simple as that.

  Those definitions are only applicable to unstructured, primitive  
  types, where the only relevant operations are get value and  
  assign value.

 Nonsense.  They apply to any type.  See here for an introduction to  
 the topic in VB.NET:

    http://www.homeandlearn.co.uk/net/nets9p4.html

 The example shown uses an Integer, but guess what -- you can pass ANY  
 type either ByRef or ByVal, including object references (which are, of  
 course, quite common in VB.NET).  The default is ByVal, which means  
 that (as in Python) the actual parameter is an expression, and no  
 assignments to it can affect the actual parameter.  It DOES NOT MATTER  
 that both the formal parameter and the actual parameter may refer to  
 the same object, and if that object is mutable, you can mutate that  
 object.


You're pretty straightforwardly wrong. In Python the 'value' of a
variable is not the reference itself. If that sentence has any meaning
for Python then the value is the object itself.

.NET does draw a distinction between 'value types' and reference types
- where using reference types are called by reference (the reference
is passed) and value types are called by value (the value itself is
copied).

Value types (all numeric types, structs, enumerations etc) actually
live on the stack, whereas reference types (strings, classes etc) live
in the heap and have a
pointer on the stack.

It is complicated by the fact that .NET perpetuates the myth that the
primitives (the value types) inherit from System.Object (a reference
type). The runtime does auto-boxing for you where this matters.

This means that when you pass a value type into a method the value
*is* copied. Structs can be arbitrarily big, so this can be a
performance problem. It is often a performance win for working with
the numeric types as you remove a level of indirection.

It isn't without problems though - and some of these can be seen in
IronPython.

System.Drawing.Point is a struct, but it is effectively a mutable
value type. However, when you access it you are often accessing a copy
- and if you attempt to mutate it then your changes will be lost.

The following code illustrates the problem:

 r = Rectangle(0, 1002 20, 40)
 r.Location.X
0
 r.Location.X = 20
 r.Location.X

0

Because r.Location returns a value type (a Point), the update to it is
'lost'.

By this definition Python objects (all of them) are clearly reference
ypes and not value types.

In .NET you can specify that a parameter to a method takes a reference
('out' in C# or ByRef in VB.NET). If you pass in a value type as a
reference parameter then the .NET runtime will do boxing / unboxing
for you.

This means that we can write code like the following C#:

int x = 3;
SomeMethod(out x);

The value of x can be changed by 'SomeMethod' and can have a different
value - something that can't happen in Python.

In a 'way' immutable Python types behave a bit like .NET value types,
and mutable types like reference types. As you can see, this analogy
breaks down.

Michael Foord
--
http://www.ironpythoninaction.com/



 But ByRef is another option, and if you pass an object reference  
 ByRef, then the formal parameter is an alias for the actual parameter,  
 and assignments to it change the actual parameter.  Python doesn't  
 have this feature (nor much need for it, given its other features,  
 like tuple packing/unpacking).  So, parameter passing in ByRef is  
 clearly exactly the same as the default ByVal parameter passing in  
 VB.NET... as well as Java, RB, C++ (when you remember that an object  
 reference in modern languages is like a pointer in C++), and every  
 other OOP language I've looked into.

 Some of those languages, like Python, don't have different modes, and  
 so the language designers had no call to give their one mode a name.  
 So let's look at those that did have such a need, like VB.NET and  
 REALbasic.  What's the default mode called?  Why, it's ByVal.  Even  
 when that value is an object reference.  This is short for by value  
 -- it's not short for by sharing or by object or any

Re: Global dictionary or class variables

2008-10-25 Thread Fuzzyman

On Oct 24, 9:44 pm, Mr.SpOOn [EMAIL PROTECTED] wrote:
 Hi,
 in an application I have to use some variables with fixed valuse.

 For example, I'm working with musical notes, so I have a global
 dictionary like this:

 natural_notes = {'C': 0, 'D': 2, 'E': 4 }

 This actually works fine. I was just thinking if it wasn't better to
 use class variables.

 Since I have a class Note, I could write:

 class Note:
     C = 0
     D = 2
     ...

 Which style maybe better? Are both bad practices?

I would *probably* find 'Note.C' more natural to use than
natural_notes['C'].

Michael Foord

--
http://www.ironpythoninaction.com/
--
http://mail.python.org/mailman/listinfo/python-list

Re: How to examine the inheritance of a class?

2008-10-25 Thread Fuzzyman

On Oct 24, 7:27 pm, Derek Martin [EMAIL PROTECTED] wrote:
 On Fri, Oct 24, 2008 at 11:59:46AM +1000, James Mills wrote:
  On Fri, Oct 24, 2008 at 11:36 AM, John Ladasky [EMAIL PROTECTED] wrote:
   etc.  The list of subclasses is not fully defined.  It is supposed to
   be extensible by the user.

  Developer. NOT User.

 It's a semantic argument, but John's semantics are fine.  A library is
 code intended to be consumed by developers.  The developers *are* the
 users of the library.  *End users* use applications, not libraries.


Except in the case of user scripting where end users of your
applications may well be using your APIs. :-)

Michael Foord

--
http://www.ironpythoninaction.com/
--
http://mail.python.org/mailman/listinfo/python-list

Re: Finding the instance reference of an object

2008-10-22 Thread Fuzzyman

On Oct 17, 10:39 pm, Joe Strout [EMAIL PROTECTED] wrote:
 On Oct 17, 2008, at 3:19 PM, Grant Edwards wrote:

  And my real point is that this is exactly the same as in every
  other modern language.

  No, it isn't.  In many other languages (C, Pascal, etc.), a
  variable is commonly thought of as a fixed location in memory
  into which one can put values.  Those values may be references
  to objects.

 Right, though not in languages like C and Pascal that don't HAVE the  
 notion of objects.  We really ought to stop bringing up those  
 dinosaurs and instead compare Python to any modern OOP language.

   In Python, that's not how it works.  There is no
  location in memory that corresponds to a variable with a
  particular name the way there is in C or Pascal or Fortran or
  many other languages.

 No?  Is there any way to prove that, without delving into the Python  
 source itself?



.NET makes a clear distinction between 'value types' and reference
types. These are analagous to the call by value and call by reference
that have been discussed in this thread.

My understanding of the difference is that value types (all numeric
types, structs, enumerations etc) actually live on the stack, whereas
reference types (strings, classes etc) live in the heap and have a
pointer on the stack.

It is complicated by the fact that .NET perpetuates the myth that the
primitives (the value types) inherit from System.Object (a reference
type). The runtime does auto-boxing for you where this matters.

This means that when you pass a value type into a method the value
*is* copied. Structs can be arbitrarily big, so this can be a
performance problem. It is often a performance win for working with
the numeric types as you remove a level of indirection.

It isn't without problems though - and some of these can be seen in
IronPython.

System.Drawing.Point is a struct, but it is effectively a mutable
value type. However, when you access it you are often accessing a copy
- and if you attempt to mutate it then your changes will be lost.

The following code illustrates the problem:

 r = Rectangle(0, 1002 20, 40)
 r.Location.X
0
 r.Location.X = 20
 r.Location.X
0

Because r.Location returns a value type, the update to it is 'lost'.

By this definition Python objects (all of them) are clearly reference
types and not value types.

In .NET you can specify that a parameter to a method takes a reference
('out' in C# or ByRef in VB.NET). If you pass in a value type as a
reference parameter then the .NET runtime will do boxing / unboxing
for you.

This means that we can write code like the following (roughly C#
pseudo code):

int x = 3;
SomeMethod(out x);

x can now be mutated by 'SomeMethod' and can have a different value.

In a 'way' immutable Python types behave a bit like .NET value types,
and mutable types like reference types. As you can see, this analogy
breaks down.

Michael Foord
--
http://www.ironpythoninaction.com/
--
http://mail.python.org/mailman/listinfo/python-list

ANN: Mock 0.4.0 released

2008-10-14 Thread Fuzzyman

Mock 0.4.0 has just been released, the first release in about ten
months (but worth the wait).

Mock is a simple library for testing: specifically for mocking,
stubbing and patching.

* Mock Homepage  Documentation http://www.voidspace.org.uk/python/mock.html
* mock.py (module only) http://www.voidspace.org.uk/downloads/mock.py
* mock-0.4.0.zip (module, tests and documentation) http://
www.voidspace.org.uk/downloads/mock-0.4.0.zip
* mock.txt (documentation) http://www.voidspace.org.uk/python/docs/
mock.txt
* Google Code Home  Subversion Repository http://code.google.com/p/
mock/

This new release brings in some cool new features, but some are
backwards incompatible so read the release notes if you are updating.
Thanks to all those who emailed me with
suggestions and feature requests - *most* of them got in one way or
another...

What is Mock?
===

Mock makes simple mocking trivially easy. It also provides decorators
to help patch module and class level attributes within the scope of a
test. In this release the ``patch`` decorator got even easier to use.
You can now call it with one argument - a string which is the fully
qualified name of the object you wish to patch, in the form
'package_name.module_name.ClassName'. ``patch`` patches the class in
the specified module with a Mock object, which is passed in to the
decorated function. (As well as ``patch`` creating mocks for you, you
can also explicitly pass in an alternative object to patch with.)


What's New?
==

The are now eggs  (for Python 2.4-2.6) up on the `Mock Cheeseshop Page
http://pypi.python.org/pypi/mock/`_. This means that if you have
setuptools you should be able to install mock with:

``easy_install mock``

The full changelog is:


* Default return value is now a new mock rather than None
* 'return_value' added as a keyword argument to the constructor
* New method 'assert_called_with'
* Added 'side_effect' attribute / keyword argument called when mock is
called
* patch decorator split into two decorators:

- ``patch_object`` which takes an object and an attribute name to
patch
  (plus optionally a value to patch with which defaults to a mock
object)
- ``patch`` which takes a string specifying a target to patch; in
the form
  'package.module.Class.attribute'. (plus optionally a value to
  patch with which defaults to a mock object)

* Can now patch objects with ``None``
* Change to patch for nose compatibility with error reporting in
wrapped functions
* Reset no longer clears children / return value etc - it just resets
  call count and call args. It also calls reset on all children (and
  the return value if it is a mock).

Thanks to Konrad Delong, Kevin Dangoor and others for patches and
suggestions.

See the following for examples of using Mock and patch:

* http://www.voidspace.org.uk/python/weblog/arch_d7_2008_10_11.shtml#e1019
--
http://mail.python.org/mailman/listinfo/python-announce-list

Support the Python Software Foundation:
http://www.python.org/psf/donations.html

ANN: Mock 0.4.0 released

2008-10-13 Thread Fuzzyman

Mock 0.4.0 has just been released, the first release in about ten
months (but worth the wait).

Mock is a simple library for testing: specifically for mocking,
stubbing and patching.

* Mock Homepage  Documentation http://www.voidspace.org.uk/python/mock.html
* mock.py (module only) http://www.voidspace.org.uk/downloads/mock.py
* mock-0.4.0.zip (module, tests and documentation) http://
www.voidspace.org.uk/downloads/mock-0.4.0.zip
* mock.txt (documentation) http://www.voidspace.org.uk/python/docs/
mock.txt
* Google Code Home  Subversion Repository http://code.google.com/p/
mock/

This new release brings in some cool new features, but some are
backwards incompatible so read the release notes if you are updating.
Thanks to all those who emailed me with
suggestions and feature requests - *most* of them got in one way or
another...

What is Mock?
===

Mock makes simple mocking trivially easy. It also provides decorators
to help patch module and class level attributes within the scope of a
test. In this release the ``patch`` decorator got even easier to use.
You can now call it with one argument - a string which is the fully
qualified name of the object you wish to patch, in the form
'package_name.module_name.ClassName'. ``patch`` patches the class in
the specified module with a Mock object, which is passed in to the
decorated function. (As well as ``patch`` creating mocks for you, you
can also explicitly pass in an alternative object to patch with.)


What's New?
==

The are now eggs  (for Python 2.4-2.6) up on the `Mock Cheeseshop Page
http://pypi.python.org/pypi/mock/`_. This means that if you have
setuptools you should be able to install mock with:

``easy_install mock``

The full changelog is:


* Default return value is now a new mock rather than None
* 'return_value' added as a keyword argument to the constructor
* New method 'assert_called_with'
* Added 'side_effect' attribute / keyword argument called when mock is
called
* patch decorator split into two decorators:

- ``patch_object`` which takes an object and an attribute name to
patch
  (plus optionally a value to patch with which defaults to a mock
object)
- ``patch`` which takes a string specifying a target to patch; in
the form
  'package.module.Class.attribute'. (plus optionally a value to
  patch with which defaults to a mock object)

* Can now patch objects with ``None``
* Change to patch for nose compatibility with error reporting in
wrapped functions
* Reset no longer clears children / return value etc - it just resets
  call count and call args. It also calls reset on all children (and
  the return value if it is a mock).

Thanks to Konrad Delong, Kevin Dangoor and others for patches and
suggestions.

See the following for examples of using Mock and patch:

* http://www.voidspace.org.uk/python/weblog/arch_d7_2008_10_11.shtml#e1019
--
http://mail.python.org/mailman/listinfo/python-list

Re: Making class attributes non-case-sensitive?

2008-10-13 Thread Fuzzyman

On Oct 13, 10:11 am, Rafe [EMAIL PROTECTED] wrote:
 Hi,

 I'm working within an application (making a lot of wrappers), but the
 application is not case sensitive. For example, Typing obj.name,
 obj.Name, or even object.naMe is all fine (as far as the app is
 concerned). The problem is, If someone makes a typo, they may get an
 unexpected error due accidentally calling the original attribute
 instead of the wrapped version. Does anyone have a simple solution for
 this?

 I can protect against some cases just by making an 'alias':
 class AClass(object):
 def name(self):
 print hello

 Name = name

 ...but this doesn't protect against typos, it gets more complicated
 with multi-word attribute names, and it makes my epydocs confusing to
 read since all spelling versions are shown (I AM concerned about my
 docs being clear, but not as much as stopping typo related errors).

 I thought about using my wrapper's __getattr__ and __setattr__, but I
 I am concerned about the overhead of every delegated attribute call
 running a search and compare (paramName.lower() based compare?).

 Any ideas or precedence?

If you define '__getattr__' then it will only be called for attribute
names that don't exist. So only explicitly define the names you want
in the lowercase variant and then have something like the following:

def __getattr__(self, name):
return object.__getattr__(self, name.lower())

That way each name only appears once and you only get the extra
'__getattr__' in your epydoc docs.

Michael



 Cheers,

 - Rafe

--
http://www.ironpythoninaction.com/
--
http://mail.python.org/mailman/listinfo/python-list

Re: compile() and comments

2008-10-13 Thread Fuzzyman

Hello Ed,

It is certainly an odd restriction, but the docs for compile [1] do
explicitly state that the input must be newline terminated.

When compiling multi-line statements, two caveats apply: line
endings must be represented by a single newline character ('\n'), and
the input must be terminated by at least one newline character.

I always throw an extra newline onto any input to compile. I think the
behaviour maybe for detecting incomplete statements when you pass in
the obscure 'don't imply dedent' flag for interactive interpreter
loops.

[1] http://www.python.org/doc/2.5.2/lib/built-in-funcs.html

Michael Foord

On Oct 13, 1:06 pm, Ed Leafe [EMAIL PROTECTED] wrote:
 I've noticed an odd behavior with compile() and code that does not
 contain a trailing newline: if the last line is a comment inside of
 any block, a syntax error is thrown, but if the last line is a non-
 comment Python statement, there is no error. Here's an example (using
 2.5.1 on OS X)

   txt = 
 ... def foo():
 ...   print 'bar' 
   compcode = compile(t.strip(), , exec)
   compcode
 code object module at 0x79608, file , line 2

   txt +=   # Comment on last line
   compcode = compile(txt.strip(), , exec)
 Traceback (most recent call last):
   File stdin, line 1, in module
   File , line 4
 # Comment on last line
 ^
 SyntaxError: invalid syntax
   compcode = compile(txt.strip() + \n, , exec)
   compcode
 code object module at 0x79a40, file , line 2

 Obviously the easy workaround is to add a newline and all is well, so
 this isn't a show-stopper, but is this a bug?

 -- Ed Leafe


--
http://www.ironpythoninaction.com/
--
http://mail.python.org/mailman/listinfo/python-list

Re: Is PyFIT dead and abandoned?

2008-10-07 Thread Fuzzyman

On Oct 7, 1:34 am, Ben Finney [EMAIL PROTECTED]
wrote:
James Mills [EMAIL PROTECTED] writes:
On Tue, Oct 7, 2008 at 5:18 AM, [EMAIL PROTECTED] wrote:
Has PyFIT been completely abandoned? Is there a better alternative or
other resources to help me integrate fitnesse and python?

I for one am not interested in this kind of framework for testing -
and yet I come from a strict Software Engineering background where
this kind of User Acceptance and Requirements-based testing is
taught.

How, then, do you automate functional testing of the full system?

I think you'll find most developers prefer to use unit test
frameworks and python has a great one built-in to the standard
library. In 99.9% of use cases, writing unit tests and well
documented and well designed, re-usable units of code is far better
than what any Requirements and Interactive testing framework could
ever offer.

I completely disagree. Unit tests are essential for testing code
*units*; e.g. functions and classes and attributes (oh my).They're a
poor fit for testing the behaviour of the overall system: for that, a
functional test suite is needed, and PyFIT seems to be a good .

Automated unit tests and automated functional tests are complementary,
and do not replace one another. Both are needed to have confidence in
the code.

At Resolver Systems we have built our own functional test framework on
top of unittest. It automates the applications but uses the usual
'assert*' methods and patterns to make assertions about the
application state.

Michael

--
\ “Injustice is relatively easy to bear; what stings is justice.” |
`\ —Henry L. Mencken |
_o__) |
Ben Finney

--
http://www.ironpythoninaction.com/
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python 2.6: Determining if a method is inherited

2008-10-07 Thread Fuzzyman

On Oct 7, 2:29 am, Terry Reedy [EMAIL PROTECTED] wrote:
 Fuzzyman wrote:
  On Oct 6, 7:02 pm, Terry Reedy [EMAIL PROTECTED] wrote:
  fuzzyman wrote:
  Doesn't sound like a particularly *good* solution to me. :-)
   From what you posted, 'type object at' should work.

  It's still a hack...

 I am sorry if I offended you by pointing out to you a quick and dirty
 solution that would solve your problem immediately.

Your smiley parsing is obviously broken.

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

Re: Python on JavaScript VM's (such as V8)?

2008-10-07 Thread Fuzzyman

On Oct 2, 1:06 pm, lkcl [EMAIL PROTECTED] wrote:
 On Sep 3, 10:02 pm, [EMAIL PROTECTED] wrote:

  Berco Beute:

   I wonder what it would take to implement Python in JavaScript so it

  it's been done.  http://pyjamas.sf.net


That's hardly an implementation of Python in Javascript - it's a
partial Python to Javascript translator.

Still looks good though.

Michael
--
http://www.ironpythoninaction.com/
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python 2.6 / 3.0: Determining if a method is inherited

On Oct 6, 1:13 am, MRAB [EMAIL PROTECTED] wrote:
 Fuzzyman wrote:
  Hello all,

  I may well be being dumb (it has happened before), but I'm struggling
  to fix some code breakage with Python 2.6.

  I have some code that looks for the '__lt__' method on a class:

  if hasattr(clr, '__lt__'):

  However - in Python 2.6 object has grown a default implementation of
  '__lt__', so this test always returns True.

   class X(object): pass
  ...
   X.__lt__
  method-wrapper '__lt__' of type object at 0xa15cf0
   X.__lt__ == object.__lt__
  False

  So how do I tell if the X.__lt__ is inherited from object? I can look
  in the '__dict__' of the class - but that doesn't tell me if X
  inherits '__lt__' from a base class other than object. (Looking inside
  the method wrapper repr with a regex is not an acceptable answer...)

  Some things I have tried:

   X.__lt__.__self__
  class '__main__.X'
   dir(X.__lt__)
  ['__call__', '__class__', '__cmp__', '__delattr__', '__doc__',
  '__format__', '__getattribute__', '__hash__', '__init__', '__name__',
  '__new__', '__objclass__', '__reduce__', '__reduce_ex__', '__repr__',
  '__self__', '__setattr__', '__sizeof__', '__str__',
  '__subclasshook__']
   X.__lt__.__func__
  Traceback (most recent call last):
File stdin, line 1, in module
  AttributeError: 'method-wrapper' object has no attribute '__func__'

  Hmmm... I can get this working with Python 2.6 with:

  if '__lt__' in dir(cls):

  The default implementation of '__lt__' doesn't appear in the dir of
  classes. However this fails with Python 3 where the default
  implementation *does* appear in the output of 'dir'. Any suggestions?

 Methods are objects. How do you know if two references refer to the
 same object? You use is:

 X.__lt__ is object.__lt__

Didn't you see that even an equality test fails - so they are not the
same (that being the problem)...

They are unbound method objects - in Python 3 the unbound method has
gone away, so the problem is with Python 2.6.

Michael
--
http://www.ironpythoninaction.com/
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python 2.6: Determining if a method is inherited

On Oct 5, 11:54 pm, Terry Reedy [EMAIL PROTECTED] wrote:
 Fuzzyman wrote:
  Hello all,

  I may well be being dumb (it has happened before), but I'm struggling
  to fix some code breakage with Python 2.6.

  I have some code that looks for the '__lt__' method on a class:

  if hasattr(clr, '__lt__'):

  However - in Python 2.6 object has grown a default implementation of
  '__lt__', so this test always returns True.

  class X(object): pass
  ...
  X.__lt__
  method-wrapper '__lt__' of type object at 0xa15cf0
  X.__lt__ == object.__lt__
  False

 In 3.0, the test returns true because function attributes only get
 wrapped when bound.  In the meanwhile,  'object' in repr(X.__lt__)
 should do it for you.



So long as its never used on a class with 'object' in the name.
Doesn't sound like a particularly *good* solution to me. :-)

Michael

 tjr

--
http://www.ironpythoninaction.com/
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python 2.6: Determining if a method is inherited

On Oct 6, 7:16 am, Christian Heimes [EMAIL PROTECTED] wrote:
 Terry Reedy wrote:
  In 3.0, the test returns true because function attributes only get
  wrapped when bound.  In the meanwhile,  'object' in repr(X.__lt__)
  should do it for you.

 This session should give you some hints how to archive your goal :)
 Have fun!

   import types
   class A(object):
 ... def __lt__(self):
 ... pass
 ...
   isinstance(A.__lt__, types.MethodType)
 True
   isinstance(A.__gt__, types.MethodType)
 False

   type(A.__lt__)
 type 'instancemethod'
   type(A.__gt__)
 type 'method-wrapper'
   type(A.__str__)
 type 'wrapper_descriptor'
   type(A.__new__)
 type 'builtin_function_or_method'

   A.__lt__.im_func
 function __lt__ at 0x7f03f9298500
   A.__lt__.im_func == A.__lt__.im_func
 True
   A.__gt__.im_func
 Traceback (most recent call last):
File stdin, line 1, in module
 AttributeError: 'method-wrapper' object has no attribute 'im_func'

However - I need to detect whether a method is inherited from
*object*. All those differences you have shown behave identically if
the class inherits from 'int'.

I am trying to detect explicit implementation of comparison methods -
so there is a big difference between inheriting from int and
inheriting from object (meaningful comparison methods existing on one
and not the other).

What I went for in the end:

import sys as _sys

if _sys.version_info[0] == 3:
def _has_method(cls, name):
for B in cls.__mro__:
if B is object:
continue
if name in B.__dict__:
return True
return False
else:
def _has_method(cls, name):
for B in cls.mro():
if B is object:
continue
if name in B.__dict__:
return True
return False

See this page for why I needed it:

http://www.voidspace.org.uk/python/weblog/arch_d7_2008_10_04.shtml#e1018

Michael

--
http://www.ironpythoninaction.com/
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python 2.6 / 3.0: Determining if a method is inherited

On Oct 6, 7:01 pm, Aaron \Castironpi\ Brady [EMAIL PROTECTED]
wrote:
 On Oct 6, 4:30 am, Fuzzyman [EMAIL PROTECTED] wrote:



  On Oct 6, 1:13 am, MRAB [EMAIL PROTECTED] wrote:

   Fuzzyman wrote:
Hello all,

I may well be being dumb (it has happened before), but I'm struggling
to fix some code breakage with Python 2.6.

I have some code that looks for the '__lt__' method on a class:

if hasattr(clr, '__lt__'):

However - in Python 2.6 object has grown a default implementation of
'__lt__', so this test always returns True.

 class X(object): pass
...
 X.__lt__
method-wrapper '__lt__' of type object at 0xa15cf0
 X.__lt__ == object.__lt__
False

So how do I tell if the X.__lt__ is inherited from object? I can look
in the '__dict__' of the class - but that doesn't tell me if X
inherits '__lt__' from a base class other than object. (Looking inside
the method wrapper repr with a regex is not an acceptable answer...)

Some things I have tried:

 X.__lt__.__self__
class '__main__.X'
 dir(X.__lt__)
['__call__', '__class__', '__cmp__', '__delattr__', '__doc__',
'__format__', '__getattribute__', '__hash__', '__init__', '__name__',
'__new__', '__objclass__', '__reduce__', '__reduce_ex__', '__repr__',
'__self__', '__setattr__', '__sizeof__', '__str__',
'__subclasshook__']
 X.__lt__.__func__
Traceback (most recent call last):
  File stdin, line 1, in module
AttributeError: 'method-wrapper' object has no attribute '__func__'

Hmmm... I can get this working with Python 2.6 with:

if '__lt__' in dir(cls):

The default implementation of '__lt__' doesn't appear in the dir of
classes. However this fails with Python 3 where the default
implementation *does* appear in the output of 'dir'. Any suggestions?

   Methods are objects. How do you know if two references refer to the
   same object? You use is:

   X.__lt__ is object.__lt__

  Didn't you see that even an equality test fails - so they are not the
  same (that being the problem)...

  They are unbound method objects - in Python 3 the unbound method has
  gone away, so the problem is with Python 2.6.

  Michael
  --http://www.ironpythoninaction.com/

 Not tested extensively.

 class NoLTException( Exception ): pass

 class NoLT( object ):
     def __lt__( self, other ):
             raise NoLTException()

 class A( NoLT ):
     pass

 class B( A ):
     def __lt__( self, other ):
             return self

 def test_lt( obj ):
     try:
             obj.__lt__( None )
     except NoLTException:
             return False
     except:
             pass
     return True



  a= A()
  b= B()
  test_lt( a )
 False
  test_lt( b )
 True

 This method won't work for arbitrary classes, only ones that you
 control, that inherit from 'NoLT'.  The 'test_lt' function works by
 trying to call '__lt__' on its argument.  The parameter to it doesn't
 matter because of what happens next.  If '__lt__' raises a
 NoLTException, you know it was inherited from NoLT.  Otherwise, even
 if another exception occurs, the object you know has '__lt__'.

 It's a very object oriented solution.  Essentially you're inheriting
 all the classes that you want to fail, from a class that does.

But not a very good solution to the problem...

The specific problem is to determine if an arbitrary class implements
a specified comparison method. The general problem (that gives rise to
the specific problem) is to write a class decorator that can implement
all comparison methods from a class that implements only one.

See: http://code.activestate.com/recipes/576529/

Michael
--
http://www.ironpythoninaction.com/
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python 2.6 / 3.0: Determining if a method is inherited

On Oct 6, 7:23 pm, Aaron \Castironpi\ Brady [EMAIL PROTECTED]
wrote:
 On Oct 6, 1:17 pm, Fuzzyman [EMAIL PROTECTED] wrote:



  On Oct 6, 7:01 pm, Aaron \Castironpi\ Brady [EMAIL PROTECTED]
  wrote:
   It's a very object oriented solution.  Essentially you're inheriting
   all the classes that you want to fail, from a class that does.

  But not a very good solution to the problem...

  The specific problem is to determine if an arbitrary class implements
  a specified comparison method. The general problem (that gives rise to
  the specific problem) is to write a class decorator that can implement
  all comparison methods from a class that implements only one.

  See:http://code.activestate.com/recipes/576529/

  Michael
  --http://www.ironpythoninaction.com/

 Nope, I'm out of ideas, I'm afraid.

Thankfully that page I pointed you to has the solution I came up with
- walk the method resolution order of the class checking in the
classes' '__dict__' to see what they explicitly implement.

Given that you can get hold of X.__lt__ I was surprised by how hard it
was to tell whether that was an inherited implementation or not.

Michael
--
http://www.ironpythoninaction.com
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python 2.6: Determining if a method is inherited

On Oct 6, 7:02 pm, Terry Reedy [EMAIL PROTECTED] wrote:
 Fuzzyman wrote:
  On Oct 5, 11:54 pm, Terry Reedy [EMAIL PROTECTED] wrote:
  Fuzzyman wrote:
  Hello all,
  I may well be being dumb (it has happened before), but I'm struggling
  to fix some code breakage with Python 2.6.
  I have some code that looks for the '__lt__' method on a class:
  if hasattr(clr, '__lt__'):
  However - in Python 2.6 object has grown a default implementation of
  '__lt__', so this test always returns True.
  class X(object): pass
  ...
  X.__lt__
  method-wrapper '__lt__' of type object at 0xa15cf0
  X.__lt__ == object.__lt__
  False
  In 3.0, the test returns true because function attributes only get
  wrapped when bound.  In the meanwhile,  'object' in repr(X.__lt__)
  should do it for you.
  So long as its never used on a class with 'object' in the name.
  Doesn't sound like a particularly *good* solution to me. :-)

  From what you posted, 'type object at' should work.

It's still a hack...
--
http://mail.python.org/mailman/listinfo/python-list

Python 2.6: Determining if a method is inherited

Hello all,

I may well be being dumb (it has happened before), but I'm struggling
to fix some code breakage with Python 2.6.

I have some code that looks for the '__lt__' method on a class:

if hasattr(clr, '__lt__'):

However - in Python 2.6 object has grown a default implementation of
'__lt__', so this test always returns True.

 class X(object): pass
...
 X.__lt__
method-wrapper '__lt__' of type object at 0xa15cf0
 X.__lt__ == object.__lt__
False

So how do I tell if the X.__lt__ is inherited from object? I can look
in the '__dict__' of the class - but that doesn't tell me if X
inherits '__lt__' from a base class other than object. (Looking inside
the method wrapper repr with a regex is not an acceptable answer...)

Some things I have tried:


 X.__lt__.__self__
class '__main__.X'
 dir(X.__lt__)
['__call__', '__class__', '__cmp__', '__delattr__', '__doc__',
'__format__', '__getattribute__', '__hash__', '__init__', '__name__',
'__new__', '__objclass__', '__reduce__', '__reduce_ex__', '__repr__',
'__self__', '__setattr__', '__sizeof__', '__str__',
'__subclasshook__']
 X.__lt__.__func__
Traceback (most recent call last):
  File stdin, line 1, in module
AttributeError: 'method-wrapper' object has no attribute '__func__'

Michael Foord
--
http://www.ironpythoninaction.com/
--
http://mail.python.org/mailman/listinfo/python-list

Python 2.6 / 3.0: Determining if a method is inherited

Hello all,

I may well be being dumb (it has happened before), but I'm struggling
to fix some code breakage with Python 2.6.

I have some code that looks for the '__lt__' method on a class:

if hasattr(clr, '__lt__'):

However - in Python 2.6 object has grown a default implementation of
'__lt__', so this test always returns True.

 class X(object): pass
...
 X.__lt__
method-wrapper '__lt__' of type object at 0xa15cf0
 X.__lt__ == object.__lt__
False

So how do I tell if the X.__lt__ is inherited from object? I can look
in the '__dict__' of the class - but that doesn't tell me if X
inherits '__lt__' from a base class other than object. (Looking inside
the method wrapper repr with a regex is not an acceptable answer...)

Some things I have tried:

 X.__lt__.__self__
class '__main__.X'
 dir(X.__lt__)
['__call__', '__class__', '__cmp__', '__delattr__', '__doc__',
'__format__', '__getattribute__', '__hash__', '__init__', '__name__',
'__new__', '__objclass__', '__reduce__', '__reduce_ex__', '__repr__',
'__self__', '__setattr__', '__sizeof__', '__str__',
'__subclasshook__']
 X.__lt__.__func__
Traceback (most recent call last):
  File stdin, line 1, in module
AttributeError: 'method-wrapper' object has no attribute '__func__'


Hmmm... I can get this working with Python 2.6 with:

if '__lt__' in dir(cls):

The default implementation of '__lt__' doesn't appear in the dir of
classes. However this fails with Python 3 where the default
implementation *does* appear in the output of 'dir'. Any suggestions?

Michael Foord
--
http://www.ironpythoninaction.com/
--
http://mail.python.org/mailman/listinfo/python-list

Python 2.6 / 3.0: Determining if a method is inherited (Fixed)

Hello all,

Sorry - my messages aren't showing up via google groups, so I'm kind
of posting on faith...

Anyway, I solved my problem (I think)...

import sys

if sys.version_info[0] == 3:
def _has_method(cls, name):
for B in cls.__mro__:
if B is object:
continue
if name in B.__dict__:
return True
return False
else:
def _has_method(cls, name):
for B in cls.mro():
if B is object:
continue
if name in B.__dict__:
return True
return False

I've reposted the question that this is the answer to below...


I may well be being dumb (it has happened before), but I'm struggling
to fix some code breakage with Python 2.6.

I have some code that looks for the '__lt__' method on a class:

if hasattr(clr, '__lt__'):

However - in Python 2.6 object has grown a default implementation of
'__lt__', so this test always returns True.

 class X(object): pass
...
 X.__lt__
method-wrapper '__lt__' of type object at 0xa15cf0
 X.__lt__ == object.__lt__
False

So how do I tell if the X.__lt__ is inherited from object? I can look
in the '__dict__' of the class - but that doesn't tell me if X
inherits '__lt__' from a base class other than object. (Looking inside
the method wrapper repr with a regex is not an acceptable answer...)

Some things I have tried:

 X.__lt__.__self__
class '__main__.X'
 dir(X.__lt__)
['__call__', '__class__', '__cmp__', '__delattr__', '__doc__',
'__format__', '__getattribute__', '__hash__', '__init__', '__name__',
'__new__', '__objclass__', '__reduce__', '__reduce_ex__', '__repr__',
'__self__', '__setattr__', '__sizeof__', '__str__',
'__subclasshook__']
 X.__lt__.__func__
Traceback (most recent call last):
  File stdin, line 1, in module
AttributeError: 'method-wrapper' object has no attribute '__func__'


Hmmm... I can get this working with Python 2.6 with:

if '__lt__' in dir(cls):

The default implementation of '__lt__' doesn't appear in the dir of
classes. However this fails with Python 3 where the default
implementation *does* appear in the output of 'dir'. Any suggestions?

Michael Foord
--
http://www.ironpythoninaction.com/
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python 2.6: Determining if a method is inherited