Re: Insert missing keys using defaultdict

[George Sakkis]

On Mar 11, 5:02 pm, Gnarlodious  wrote:

> I am trying to grok this documentation but need 
> help:http://docs.python.org/library/collections.html#defaultdict-examples
>
> In a perfect world the dict looks like this:
> plistDict={'Style':'ExternalURL', 'Ref':'http://Gnarlodious.com/',
> 'Tip':'Opens in a new window', 'Text':'Gnarlodious.com'}
>
> Let's say I want to prep a dict from a plist to insert the values into
> an HTML link string:
> "%(Text)s" %
> plistDict
>
> However, in this imperfect world the dict might look like this:
> plistDict={'Ref':'http://Gnarlodious.com/', 'Text':'Gnarlodious.com'}
>
> which would error:
> KeyError: 'Style'
>
> So using defaultdict:
> from collections import defaultdict
>
> How do create a dict assigning every missing key with a default
> string?

"%(Text)s" %
defaultdict(lambda:'_MISSING_', plistDict)

HTH,
George
-- 
http://mail.python.org/mailman/listinfo/python-list

Multiple import of the same module under different names

[George Sakkis]

The import mechanism is not very smart in identifying whether two
modules imported under different name are actually the same module, at
least when dealing with implicit relative imports and sys.path
manipulation. However, at least in cases of plain file modules, the
module's __file__ would be adequate (or at least better than __name__)
in determining this. Below is an illustration of the different
situations (absolute imports, explicit relative imports, implicit
relative import, sys.path tweaking). So why does not import consult
__file__ before deciding to create a new module instance ?

George


=== File structure =

~/pkg/
   __init__.py  # empty
   mod1.py
   mod2.py
   mod3.py
   mod4.py
   main.py
   subpkg/
  __init__.py  # empty
  foo.py # empty

=== Run  =

~$ PYTHONPATH=. python pkg/main.py

=== Output  =

Imported foo from pkg.subpkg:   
Imported foo from subpkg:   
Imported foo from pkg.mod1: 
Imported foo from mod1: 
Imported foo from pkg.mod2: 
Failed to import foo from mod2:Attempted relative import in non-package
Imported foo from pkg.mod3: 
Imported foo from mod3: 
Imported foo from pkg.mod4: 
Imported foo from mod4: 

* 9 total module(s)
* 3 distinct module(s)



* 1 distinct file(s)
/home/george/pkg/subpkg/foo.py

=== Code  =

### mod1.py ###
# implicit relative import
from subpkg import foo

### mod2.py ###
# explicit relative import
from .subpkg import foo

### mod3.py ###
# absolute import
from pkg.subpkg import foo

### mod4.py ###
# absolute import after tweaking sys.path
import sys
from os.path import dirname,join
sys.path.append(join(dirname(__file__), 'subpkg'))
import foo

### main.py ###
#!/usr/bin/env python

from os.path import abspath, normpath

def test(*modules):
module_set = set(modules)
file_set = set(module_file(m) for m in modules)
print '* %d total module(s)' % len(modules)
print '* %d distinct module(s)' % len(module_set)
for m in module_set:
print '\t', m
print '* %d distinct file(s)' % len(file_set)
for f in file_set:
print '\t', f

def module_file(mod):
f = abspath(normpath(mod.__file__))
if f.endswith('.pyc'):
f = f[:-1]
return f

if __name__ == '__main__':
from pkg.subpkg import foo
print 'Imported foo from pkg.subpkg:\t', foo
from subpkg import foo as rel_foo
print 'Imported foo from subpkg:\t\t', rel_foo

from pkg.mod1 import foo as foo1
print 'Imported foo from pkg.mod1:\t', foo1
from mod1 import foo as rel_foo1
print 'Imported foo from mod1:\t\t', rel_foo1

from pkg.mod2 import foo as foo2
print 'Imported foo from pkg.mod2:\t', foo2
try: from mod2 import foo as rel_foo2
except ValueError, ex:
print 'Failed to import foo from mod2:', ex

from pkg.mod3 import foo as foo3
print 'Imported foo from pkg.mod3:\t', foo3
from mod3 import foo as rel_foo3
print 'Imported foo from mod3:\t\t', rel_foo3

from pkg.mod4 import foo as foo4
print 'Imported foo from pkg.mod4:\t', foo4
from mod4 import foo as rel_foo4
print 'Imported foo from mod4:\t\t', rel_foo4

print
test(foo, rel_foo,
 foo1, rel_foo1,
 foo2, # rel_foo2,
 foo3, rel_foo3,
 foo4, rel_foo4)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: When will Python go mainstream like Java?

[George Sakkis]

On Feb 23, 3:49 pm, mk  wrote:

> Well I for one wouldn't want Python to go exactly Java way, see this:
>
> http://www.itjobswatch.co.uk/charts/permanent-demand-trend.aspx?s=jav...
>
> This is the percentage of job offers in UK where the keyword "Java" appears.
>
> Same for C#, it looks like C# is eating Java's lunch now:
>
> http://www.itjobswatch.co.uk/charts/permanent-demand-trend.aspx?s=csh...

This seems to be a UK-specific trend; in the US (and most other
countries I know of) Java is still going strong, e.g.
http://www.indeed.com/jobtrends?q=java%2C+c%23&l=

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

To (monkey)patch or not to (monkey)patch, that is the question

[George Sakkis]

I was talking to a colleague about one rather unexpected/undesired
(though not buggy) behavior of some package we use. Although there is
an easy fix (or at least workaround) on our end without any apparent
side effect, he strongly suggested extending the relevant code by hard
patching it and posting the patch upstream, hopefully to be accepted
at some point in the future. In fact we maintain patches against
specific versions of several packages that are applied automatically
on each new build. The main argument is that this is the right thing
to do, as opposed to an "ugly" workaround or a fragile monkey patch.
On the other hand, I favor practicality over purity and my general
rule of thumb is that "no patch" > "monkey patch" > "hard patch", at
least for anything less than a (critical) bug fix.

So I'm wondering if there is a consensus on when it's better to (hard)
patch, monkey patch or just try to work around a third party package
that doesn't do exactly what one would like. Does it have mainly to do
with the reason for the patch (e.g. fixing a bug, modifying behavior,
adding missing feature), the given package (size, complexity,
maturity, developer responsiveness), something else or there are no
general rules and one should decide on a case-by-case basis ?

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

Re: Your beloved python features

[George Sakkis]

On Feb 5, 2:45 am, "Bruce C. Baker" 
wrote:

> "Terry Reedy"  wrote in message
>
> news:mailman.1929.1265328905.28905.python-l...@python.org...
>
> > Iterators, and in particular, generators.
> > A killer feature.
>
> > Terry Jan Reedy

+1, iterators/generators is among Python's best features for me too.

> Neither unique to Python.

Can you name a single feature that is unique to a language, Python or
other ? Every idea that's any good has been copied over, usually more
than once.

> And then're the other killer "features" superfluous ":"s and rigid
> formatting!

I'll give the benefit of doubt and assume you're joking rather than
trolling.

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

Re: Symbols as parameters?

[George Sakkis]

On Jan 25, 1:05 am, Steven D'Aprano
 wrote:
> On Sun, 24 Jan 2010 10:11:07 -0800, George Sakkis wrote:
> > Both in your example and by using a context manager, you can get away
> > with not passing locals() explicitly by introspecting the stack frame.
>
> You say that as if it were less of an ugly hack than the locals() trick.
> But sys._getframe is a private implementation detail, so you're no better
> off.

The client *is* better off in that he doesn't have to pass locals() to
some magic decorator to achieve his goal; how this is implemented is a
different issue. As for being an ugly hack, you may use inspect.stack
() if the underscore in sys._getframe() makes you feel dirty.

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

Re: Symbols as parameters?

[George Sakkis]

On Jan 22, 8:39 pm, Martin Drautzburg 
wrote:

> Martin Drautzburg wrote:
> >> with scope():
> >>     # ...
> >>     # use up, down, left, right here
>
> >> # up, down, left, right no longer defined after the with block exits.
>
> Just looked it up again. It's a cool thing. Too bad my locals() hack
> would still be required. The result would be less noisy (and actually
> really beautiful) than the decorator implementation though. Thanks
> again for pointing this out to me.

Both in your example and by using a context manager, you can get away
with not passing locals() explicitly by introspecting the stack frame.
Here's a context manager that does the trick:

from __future__ import with_statement
from contextlib import contextmanager
import sys

@contextmanager
def enums(*consts):
# 2 levels up the stack to bypass the contextmanager frame
f_locals = sys._getframe(2).f_locals
new_names = set()
reset_locals, updated_locals = {}, {}
for const in consts:
updated_locals[const] = const
if const in f_locals:
reset_locals[const] = f_locals[const]
else:
new_names.add(const)
f_locals.update(updated_locals)
try:
yield
finally:
for name in new_names:
del f_locals[name]
f_locals.update(reset_locals)


if __name__ == '__main__':
def move(aDirection):
print "moving " + aDirection

up = "outerScopeUp"
with enums("up", "down", "left", "right"):
move(up)
move(down)
move(left)
move(right)
print "in the outer scope up is still:", up
print "this should fail:"
down


Of course, as all other attempts to mess with locals() shown in this
thread, this only "works" when locals() is globals(). If you try it
within a function, it fails:

def test():
up = "outerScopeUp"
with enums("up", "down", "left", "right"):
move(up)
move(down)
move(left)
move(right)
print "in the outer scope up is still:", up
print "this should fail:"
down

## XXX: doesn't work within a function
test()

So it's utility is pretty limited; a custom DSL is probably better
suited to your problem.

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

PyTrie 0.1

[George Sakkis]

I'm pleased to announce the first release of PyTrie, a pure Python
implementation of the trie (prefix tree) data structure [1].

Tries extend the mapping interface with methods that facilitate
finding the keys/values/items for a given prefix, and vice versa,
finding the prefixes (or just the longest one) of a given key K.

Project links:
- PyPI entry: http://pypi.python.org/pypi/PyTrie
- Documentation: http://packages.python.org/PyTrie
- Repository: http://bitbucket.org/gsakkis/pytrie

Regards,
George


[1] http://en.wikipedia.org/wiki/Trie
-- 
http://mail.python.org/mailman/listinfo/python-list

int rich comparisons

[George Sakkis]

I stumbled upon the following strangeness (python 2.6.2):

>>> getattr(int, '__gt__')


>>> getattr(5, '__gt__')
Traceback (most recent call last):n
  File "", line 1, in 
AttributeError: 'int' object has no attribute '__gt__'

Is this a bug ?

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

Re: [Python-ideas] possible attribute-oriented class

[George Sakkis]

On Fri, Sep 4, 2009 at 4:37 PM, Jan Kaliszewski wrote:
> 04-09-2009 Ken Newton  wrote:
>
>> I like this version very much. I'm ready to put this into practice to see
>> how it works in practice.
>
> [snip]
>
> Not only you (Ken) and me. :-) It appears that the idea is quite old. Nick
> Coghlan replied at python-id...@python.org:
>
>> Jan Kaliszewski wrote:
>>>
>>> What do you think about it?
>>
>> It reminds me a bit of the old (short-lived) namespaces module:
>>
>>
>> http://web.archive.org/web/20060216094030/http://namespace.python-hosting.com/
>>
>> Steven's draft PEP on the topic is still available in the python-list
>> archives:
>>
>> http://mail.python.org/pipermail/python-list/2005-February/307235.html
>>
>> The problem we found with it was that the basic solutions (empty class
>> and now named_tuple) were good enough that it wasn't worth the hassle
>> involved in grabbing an extra library for it.
>
> Named tuples (which indeed are really very nice) are read-only, but the
> approach they represent could (and IMHO should) be extended to some kind
> of mutable objects.

Maybe something like http://code.activestate.com/recipes/576555/ ?

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

Re: ANN: Shed Skin 0.2, an experimental (restricted) Python-to-C++ compiler

[George Sakkis]

On Jul 22, 12:45 pm, William Dode  wrote:
> On 22-07-2009, George Sakkis wrote:
>
>
>
> > On Jul 22, 7:38 am, William Dode  wrote:
>
> >> I updated the script (python, c and java) with your unrolled version
> >> + somes litle thinks.
>
> >> I also tried with python3.1, unladen Q2, ironpython1.1.1
>
> >> Unfortunately it doesn't work more with shedskin, i'll see on the
> >> shedskin group...
>
> >> c 1.85s
> >> gcj 2.15s
> >> java 2.8s
> >> python2.5 + psyco 3.1s
> >> unladen-2009Q2 145s (2m45)
> >> python2.5 254s (4m14s)
> >> python3.1 300s (5m)
> >> ironpython1.1.1 680s (11m20)
>
> > Cool; it would be interesting to see the numbers for Jython and Boo as
> > well if it's not too much effort.
>
> I just tried with jython, but oddly it's faster without array.

FYI Jython 2.5 was released last month, you may want to try this
instead of 2.2.

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

Re: ANN: Shed Skin 0.2, an experimental (restricted) Python-to-C++ compiler

[George Sakkis]

On Jul 22, 7:38 am, William Dode  wrote:

> I updated the script (python, c and java) with your unrolled version
> + somes litle thinks.
>
> I also tried with python3.1, unladen Q2, ironpython1.1.1
>
> Unfortunately it doesn't work more with shedskin, i'll see on the
> shedskin group...
>
> c 1.85s
> gcj 2.15s
> java 2.8s
> python2.5 + psyco 3.1s
> unladen-2009Q2 145s (2m45)
> python2.5 254s (4m14s)
> python3.1 300s (5m)
> ironpython1.1.1 680s (11m20)

Cool; it would be interesting to see the numbers for Jython and Boo as
well if it's not too much effort.

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

Re: How do I sample randomly based on some probability(wightage)?

[George Sakkis]

On May 26, 2:39 pm, Sumitava Mukherjee  wrote:
> Hi all,
> I need to randomly sample from a list where all choices have weights
> attached to them. The probability of them being choosen is dependent
> on the weights.
> If say Sample list of choices are [A,B,C,D,E] and weights of the same
> are [0.895,0.567,0.765,0.890,0.60] when I draw (say 2) samples then I
> want the likeliness of them being chosen be in the order : D>A>C>E>B
>
> In short I mean if prob of a H is .9 and probability of T be 0.1 then
> if I draw 10 samples, 9 should be H and 1 should be T.
>
> I coudn't find a function in the module random that does so.
> Please can someone guide me how the above could be implemented [either
> through some function which exists and I don't know or pointers to
> some code snippets which does so]?

1. Normalize the weights so that they sum up to 1.
2. Form the cumulative sequence S = [0, w0, w0+w1, w0+w1+w2, ..., sum
(w)==1.0]
3. Call random.random() -> x
4. Find the bucket in S that x belongs to, i.e. the i so that s[i] <=
x < s[i+1] (you can do this fast using the bisect module).
5. Return choice[i]
6. Test.
7. Submit homework ;)

HTH,
George
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Wrapping methods of built-in dict

[George Sakkis]

On May 21, 5:55 pm, shailesh  wrote:

> There doesn't seem to be a predicate returning method wrappers. Is
> there an alternate way to query an object for attributes that are of
> method wrappers?

Sure:
>>> MethodWrapper = type({}.__init__)
>>> isinstance([].__len__, MethodWrapper)
True

But you're better off catching everything by checking with callable()
(or equivalently hasattr(obj, '__call__')).

> This exercise also makes me question if I'm going about this
> correctly. If I want to add functionality to the methods of a class or
> an object are decorators and the inspect module the pythonic way to go
> about it? I can think of alternative implementations either through
> metaclasses or proxy objects.

In my experience, it's quite unlikely to really want to decorate
indiscriminately *all* methods of a class/instance, let alone all the
special methods (e.g. __getattribute__ very rarely needs to be
overridden). Do you have an actual use case or are you just playing
around ?

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

Re: Adding a Par construct to Python?

[George Sakkis]

On May 18, 5:27 am, jer...@martinfamily.freeserve.co.uk wrote:

> My suggestion is primarily about using multiple threads and sharing
> memory - something akin to the OpenMP directives that one of you has
> mentioned. To do this efficiently would involve removing the Global
> Interpreter Lock, or switching to Jython or Iron Python as you
> mentioned.
>
> However I *do* actually want to add syntax to the language.

Good luck with that. The GIL is not going away any time soon (or
probably ever) and as long as CPython is the "official"
implementation, there are almost zero chances of adding syntax support
for this. Besides, Guido and other py-devs are not particularly keen
on threads as a parallelization mechanism.

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

Re: introspection question: get return type

[George Sakkis]

On May 14, 3:55 pm, a...@pythoncraft.com (Aahz) wrote:
> In article <4a0c6e42$0$12031$426a7...@news.free.fr>,
> Bruno Desthuilliers   wrote:
>
> >Marco Mariani a écrit :
> >> Bruno Desthuilliers wrote:
>
> >>> Oh, you meant the "return type" ? Nope, no way. It just doesn't make
> >>> sense given Python's dynamic typing.
>
> >> Unless he's really trying to write in Nohtyp,
>
> >You meant "Notype" ?-)
>
> Marco's spelling is correct.  Try "Nohtyp".reverse()

I tried it:

>>> "Nohtyp".reverse()
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'str' object has no attribute 'reverse'

This newfangled Nohtyp language is no good, I want my money back.

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

Re: Nimrod programming language

[George Sakkis]

On May 12, 12:49 pm, Mensanator  wrote:
> On May 12, 8:27 am, rump...@web.de wrote:
>
> > > > > The language and library are missing arbitrary precision integer
> > > > > arithmetic, using GMP or something like that.
>
> > > > True, but currently not a high priority for me.
>
> > > Too bad. That makes Nimrod officially "worthless", i.e., of no
> > > value to me.
>
> > Well, you could write a wrapper for GMP (and contribute to the
> > project ;-)).
>
> But such a thing already exists in Python. And I spend my time
> USING arbitrary precision numbers to do math research.
>
> Just thought you'ld like to be aware that some people actually
> make their language choices based on the availability (and
> performance)
> of arbitrary precision numbers.

I'm sure developers of a new language have to deal with much more
pressing issues before accommodating each and every self important
niche.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Decorating methods - where do my arguments go?

[George Sakkis]

On May 8, 11:33 am, Mikael Olofsson  wrote:

> Hi all!
>
> I have long tried to avoid decorators, but now I find myself in a
> situation where I think they can help. I seem to be able to decorate
> functions, but I fail miserably when trying to decorate methods. The
> information I have been able to find on-line focuses on decorating
> functions, and do not mention any special problem regarding methods.
>
> Consider the following example. I start by defining a simple decorator:
>
>  >>> class test_decorator(object):
> ... def __init__(self,func):
> ... self._func = func
> ... def __call__(self, *args):
> ... print 'Decorator:', args
> ... self._func(*args)
>
> Then I decorate a function:
>
>  >>> @test_decorator
> ... def func(*args):
> ... print 'Function: ', args
>
> Let's try that:
>
>  >>> func(1,2,3)
> Decorator: (1, 2, 3)
> Function:  (1, 2, 3)
>
> OK! That was what I expected. Let's decorate a method:
>
>  >>> class cls(object):
> ... @test_decorator
> ... def meth(self,*args):
> ... print 'Method:   ', args
>
> Then try that:
>
>  >>> cls().meth(1,2,3)
> Decorator: (1, 2, 3)
> Method:(2, 3)
>
> Oops! That's weird. I had expected - or at least wanted - the same
> result as for the function above.
>
> Where did the first argument go? If it was sent to the original method
> meth as the real first argument (self), then why did I not get an exception?
>
> More importantly: How do I write a decorator that does not drop arguments?
>
> I guess it all has to do with the fact that the returned callable isn't
> a method of cls. Is it possible to write a decorator that returns a
> callable that is a method of cls, when used on methods in cls?

Yes, just return an actual function from the decorator instead of a
callable object:

def test_decorator2(func):
def wrapper(*args):
print 'Decorator2:', args
func(*args)
return wrapper


class cls(object):
@test_decorator
def meth(self,*args):
print 'Method:   ', args

@test_decorator2
def meth2(self,*args):
print 'Method2:   ', args

>>> cls.meth
<__main__.test_decorator object at 0x87663cc>

>>> cls.meth2


>>> cls().meth2(1,2,3)
Decorator2: (<__main__.cls object at 0x8766ecc>, 1, 2, 3)
Method2:(1, 2, 3)

The reason this works is that functions are already descriptors, so
you don't have to explicitly define __get__() as you would for a new
callable class (see Peter's example).

HTH,
George
--
http://mail.python.org/mailman/listinfo/python-list

Re: Self function

[George Sakkis]

On May 6, 10:32 pm, Luis Alberto Zarrabeitia Gomez 
wrote:

> A bit offtopic: a while ago I think I saw a recipe for a decorator that, via
> bytecode hacks, would bind otherwise global names to the local namespace of 
> the
> function. Can anyone remember it/point me to it?

Maybe you saw http://code.activestate.com/recipes/277940/ ?

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

Re: ActiveState Komodo Edit?

[George Sakkis]

On Apr 26, 11:08 pm, John Doe  wrote:

> Having trouble tabifying a section of Python code.
> Code -- Tabify Region
> Does it work for anyone else?

Yes it does, you have to select a region before (e.g. ctrl+A for the
whole file). Regardless, the common standard indentation is 4 spaces;
avoid tabs if you can.

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

Re: The Python standard library and PEP8

[George Sakkis]

On Apr 19, 6:01 pm, "Martin P. Hellwig"

> Besides, calling Python Object-Orientated is a bit of an insult :-). I
> would say that Python is Ego-Orientated, it allows me to do what I want.

+1 QOTW
--
http://mail.python.org/mailman/listinfo/python-list

Re: Overriding methods per-object

[George Sakkis]

On Apr 17, 9:22 pm, Pavel Panchekha  wrote:

> I've got an object which has a method, __nonzero__
> The problem is, that method is attached to that object not that class
>
> > a = GeneralTypeOfObject()
> > a.__nonzero__ = lambda: False
> > a.__nonzero__()
>
> False
>
> But:
>
> > bool(a)
>
> True
>
> What to do?


FYI this works as you expect if GeneralTypeOfObject is an old-style
class (i.e. does not inherit from object). If this feature is so more
important than all those that come with new-style classes, you have
control over the involved classes and don't care about Python 3.x
(where old-style classes are gone), you may choose to downgrade
GeneralTypeOfObject to old-style.

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

Re: absolute newbie: divide a list into sublists (nested lists?) of fixed length

[George Sakkis]

On Apr 11, 6:05 pm, ergconce...@googlemail.com wrote:
> On Apr 11, 11:18 pm, George Sakkis  wrote:
>
>
>
> > The numpy import *is* important if you want to use numpy-specific
> > features; there are many "tricks" you can do easily with numpy arrays
> > that you have to write manually for, say, regular python lists. For
> > example what you want to do is trivial with numpy:
>
> > >>>import numpy as N
> > >>> s = N.array([ 0.84971586,  0.05786009,  0.9645675,  0.84971586,  
> > >>> 0.05786009,
>
> > 0.9645675, 0.84971586,  0.05786009,  0.9645675,  0.84971586,
> > 0.05786009,  0.9645675])>>> # convert to a 4by3 array in place
> > >>> s.shape = (4,3)
> > >>> s
>
> > array([[ 0.84971586,  0.05786009,  0.9645675 ],
> >        [ 0.84971586,  0.05786009,  0.9645675 ],
> >        [ 0.84971586,  0.05786009,  0.9645675 ],
> >        [ 0.84971586,  0.05786009,  0.9645675 ]])
>
> Thanks very much - works fine! Now for a follow-up question:)
>
> Actually my original list called "mylist" contains 81217 elements - I
> shape those into
>
>
>
> >>> len(mylist)
> 81217
> >>> s = N.array(mylist)
> >>> s.shape = (241,337)
>
> which works because the "total size of new array must be
> unchanged" (241x337=81217)
>
> Now this "matrix" actually is a 2D colorcoded map - I want to plot
> this using the imshow splot routine in mayavi2..
>
> However, there might be a problem: I believe that sometimes my
> original array will not exactly contain 81217 elements, but maybe only
> 81216 or so. Nevertheless, I know that time x times y - structure will
> always be the same (that is, 241 columns). What is of interest to me
> is the first 241 x 241 part of the matrix anyway. Is there an easy way
> to reshape my original array into a symmetric 241x241 matrix?

Yes, use numpy.resize:

>>> s = N.resize(my_list, (241,241))

You should probably be able to find the answer to most of your
upcoming numpy questions at http://numpy.scipy.org/numpydoc/numpy.html
(especially the array functions,
http://numpy.scipy.org/numpydoc/numpy-9.html)

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

Re: absolute newbie: divide a list into sublists (nested lists?) of fixed length

[George Sakkis]

On Apr 11, 4:14 pm, ergconce...@googlemail.com wrote:
> Hi,
> I have a list looking like
>
> [ 0.84971586,  0.05786009,  0.9645675,  0.84971586,  0.05786009,
> 0.9645675, 0.84971586,  0.05786009,  0.9645675,  0.84971586,
> 0.05786009,  0.9645675]
>
> and I would like to break this list into subsets of fixed length (say,
> three elements), i.e. to convert the list into a form such as the one
> generated by the following example code which I have found:
>
> >>>import numpy
> >>>s = numpy.random.random((3,3))
> >>>s
>
> array([[ 0.11916176,  0.96409475,  0.72602155],
>        [ 0.84971586,  0.05786009,  0.96456754],
>        [ 0.81617437,  0.845342  ,  0.09109779]])
>
> How can I create such a 2d array (i.e., something like a symmetric
> matrix) from my data?
>
> Thanks in advance,
>
> Bernard
>
> PS: Note that the numpy import is not important here, it is just the
> structure of the data that matters..

The numpy import *is* important if you want to use numpy-specific
features; there are many "tricks" you can do easily with numpy arrays
that you have to write manually for, say, regular python lists. For
example what you want to do is trivial with numpy:

>>>import numpy as N
>>> s = N.array([ 0.84971586,  0.05786009,  0.9645675,  0.84971586,  0.05786009,
0.9645675, 0.84971586,  0.05786009,  0.9645675,  0.84971586,
0.05786009,  0.9645675])
>>> # convert to a 4by3 array in place
>>> s.shape = (4,3)
>>> s
array([[ 0.84971586,  0.05786009,  0.9645675 ],
   [ 0.84971586,  0.05786009,  0.9645675 ],
   [ 0.84971586,  0.05786009,  0.9645675 ],
   [ 0.84971586,  0.05786009,  0.9645675 ]])


HTH,
George
--
http://mail.python.org/mailman/listinfo/python-list

Re: Unsupported operand types in if/else list comprehension

[George Sakkis]

On Apr 11, 4:26 pm, Mike H  wrote:

> George,
>
> I'd love to. Can you give me an idea of where to start looking? I've
> gone through a couple of books, and Googled a ton of websites. Maybe
> I'm just not using the right terms. My background is definitely not
> CompSci. But if you'd give me a suggestion of where to look, I'd
> appreciate it.

Sure; off the top of my head, check out SQLAlchemy [1], SQLObject [2]
or Storm [3]. SQLAlchemy is probably the most powerful but it has
arguably the steepest learning curve, so you might find it less
appealing initially. In any case, something as simple as an insert
should be trivial in all frameworks, e.g. in SQLAlchemy (if you don't
use the object-relational mapper) you can create an insert statement
as:

# create the statement (my_table: an sqlalchemy.Table)
>>> ins = my_table.insert().values(field1=value1, field2=value2, ..., 
>>> fieldN=valueN)

# you can print to see the actual generated SQL
>>> str(ins)
'INSERT INTO my_table (field1, field2, ... fieldN) VALUES
(:field1, :field2, ... :fieldN)'

# execute it (conn: an active sqlachemy.engine.Connection)
>>> result = conn.execute(ins)

HTH,
George


[1] http://www.sqlalchemy.org/
[2] http://www.sqlobject.org/
[3] https://storm.canonical.com/

> On Sat, Apr 11, 2009 at 4:18 PM, George Sakkis  
> wrote:
> > On Apr 11, 3:03 pm, Mike H  wrote:
>
> >> Can I not use the cursor.execute command to pass variables that aren't
> >> immediately next to each other? If so, is there a better way to go
> >> about solving this problem?
>
> > Yes, there is. Use one of the several production quality python SQL
> > toolkits built for exactly this purpose instead of putting together an
> > ad-hoc, informally-specified bug-ridden slow implementation of half of
> > their feature set.
>
> > George
> > --
> >http://mail.python.org/mailman/listinfo/python-list

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

Re: Unsupported operand types in if/else list comprehension

[George Sakkis]

On Apr 11, 3:03 pm, Mike H  wrote:

> Can I not use the cursor.execute command to pass variables that aren't
> immediately next to each other? If so, is there a better way to go
> about solving this problem?

Yes, there is. Use one of the several production quality python SQL
toolkits built for exactly this purpose instead of putting together an
ad-hoc, informally-specified bug-ridden slow implementation of half of
their feature set.

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

Re: Returning different types based on input parameters

[George Sakkis]

On Apr 7, 3:18 pm, Adam Olsen  wrote:

> On Apr 6, 3:02 pm, George Sakkis  wrote:
>
> > For example, it is common for a function f(x) to expect x to be simply
> > iterable, without caring of its exact type. Is it ok though for f to
> > return a list for some types/values of x, a tuple for others and a
> > generator for everything else (assuming it's documented), or it should
> > always return the most general (iterator in this example) ?
>
> For list/tuple/iterable the correlation with the argument's type is
> purely superficial, *because* they're so compatible.  Why should only
> tuples and lists get special behaviour?  Why shouldn't every other
> argument type return a list as well?

That's easy; because the result might be infinite. In which case you
may ask "why shouldn't every argument type return an iterator then",
and the reason is usually performance; if you already need to store
the whole result sequence (e.g. sorted()), why return just an iterator
to it and force the client to copy it to another list if he needs
anything more than iterating once over it ?

> A counter example is python 3.0's str/bytes functions.  They're
> mutually incompatible and there's no default.

As already mentioned, another example is filter() that tries to match
the input sequence type and falls back to list if it fails.

> > To take it further, what if f wants to return different types,
> > differing even in a duck-type sense? That's easier to illustrate in a
> > API-extension scenario. Say that there is an existing function `solve
> > (x)` that returns `Result` instances.  Later someone wants to extend f
> > by allowing an extra optional parameter `foo`, making the signature
> > `solve(x, foo=None)`. As long as the return value remains backward
> > compatible, everything's fine. However, what if in the extended case,
> > solve() has to return some *additional* information apart from
> > `Result`, say the confidence that the result is correct ? In short,
> > the extended API would be:
>
> >     def solve(x, foo=None):
> >         '''
> >         @rtype: `Result` if foo is None; (`Result`, confidence)
> > otherwise.
> >         '''
>
> > Strictly speaking, the extension is backwards compatible; previous
> > code that used `solve(x)` will still get back `Result`s. The problem
> > is that in new code you can't tell what `solve(x,y)` returns unless
> > you know something about `y`. My question is, is this totally
> > unacceptable and should better be replaced by a new function `solve2
> > (x, foo=None)` that always returns (`Result`, confidence) tuples, or
> > it might be a justifiable cost ? Any other API extension approaches
> > that are applicable to such situations ?
>
> At a minimum it's highly undesirable.  You lose a lot of readability/
> maintainability.  solve2/solve_ex is a little ugly, but that's less
> overall, so it's the better option.

That's my feeling too, at least in a dynamic language. For a static
language that allows overloading, that should be a smaller (or perhaps
no) issue.

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

Re: Returning different types based on input parameters

[George Sakkis]

On Apr 6, 7:57 pm, "andrew cooke"  wrote:
> andrew cooke wrote:
> > George Sakkis wrote:
> >> That's more of a general API design question but I'd like to get an
> >> idea if and how things are different in Python context. AFAIK it's
> >> generally considered bad form (or worse) for functions/methods to
> >> return values of different "type" depending on the number, type and/or
> >> values of the passed parameters. I'm using "type" loosely in a duck-
> >> typing sense, not necessarily as a concrete class and its descendants,
> >> although I'm not sure if even duck-typing is endorsed for return
> >> values (as opposed to input parameters).
> > [...]
>
> > you probably want to look up substitutability:
> >http://www.google.cl/search?q=substitutability+principle
>
> actually, this is better:http://www.google.cl/search?q=substitution+principle
>
> the idea being that if the "contract" for your function is that it returns
> a certain type, then any subclass should also be ok (alternatively, that
> subclasses should be written so that they can be returned when a caller
> was expecting the superclass)

I'm not sure if Liskov substitution addresses the same problem. The
question here is, what's the scope of the contract ? Does it apply to
the original signature only or any future extended version of it ? In
the former case, the contract is still valid: whenever someone calls
"solve(x)" gets the promised type. The original contract didn't
specify what should the result be when the function is called as "solve
(x, y)" (since the function didn't support a second argument
originally). Only if one interprets the contract as applicable to the
current plus all future extensions, then Liskov substitution comes
into play.

Perhaps that's more obvious in statically typed languages that allow
overloading. IIRC the presence of a method with the signature
   float foo(float x);
does not preclude its overloading (in the same or a descendant class)
with a method
   char* foo(float x, int y);
The two methods just happen to share the same name but other than that
they are separate, their return value doesn't have to be
substitutable. Is this considered bad practice ?

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

Re: Returning different types based on input parameters

[George Sakkis]

On Apr 6, 5:56 pm, MRAB  wrote:

> In your example I would possibly suggest returning a 'Result' object and
> then later subclassing to give 'ConfidenceResult' which has the
> additional 'confidence' attribute.

That's indeed one option, but not very appealing if `Result` happens
to be a builtin (e.g. float or list). Technically you can subclass
builtins but I think, in this case at least, the cure is worse than
the disease.

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

Returning different types based on input parameters

[George Sakkis]

That's more of a general API design question but I'd like to get an
idea if and how things are different in Python context. AFAIK it's
generally considered bad form (or worse) for functions/methods to
return values of different "type" depending on the number, type and/or
values of the passed parameters. I'm using "type" loosely in a duck-
typing sense, not necessarily as a concrete class and its descendants,
although I'm not sure if even duck-typing is endorsed for return
values (as opposed to input parameters).

For example, it is common for a function f(x) to expect x to be simply
iterable, without caring of its exact type. Is it ok though for f to
return a list for some types/values of x, a tuple for others and a
generator for everything else (assuming it's documented), or it should
always return the most general (iterator in this example) ?

To take it further, what if f wants to return different types,
differing even in a duck-type sense? That's easier to illustrate in a
API-extension scenario. Say that there is an existing function `solve
(x)` that returns `Result` instances.  Later someone wants to extend f
by allowing an extra optional parameter `foo`, making the signature
`solve(x, foo=None)`. As long as the return value remains backward
compatible, everything's fine. However, what if in the extended case,
solve() has to return some *additional* information apart from
`Result`, say the confidence that the result is correct ? In short,
the extended API would be:

def solve(x, foo=None):
'''
@rtype: `Result` if foo is None; (`Result`, confidence)
otherwise.
'''

Strictly speaking, the extension is backwards compatible; previous
code that used `solve(x)` will still get back `Result`s. The problem
is that in new code you can't tell what `solve(x,y)` returns unless
you know something about `y`. My question is, is this totally
unacceptable and should better be replaced by a new function `solve2
(x, foo=None)` that always returns (`Result`, confidence) tuples, or
it might be a justifiable cost ? Any other API extension approaches
that are applicable to such situations ?

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

Re: object knows which object called it?

[George Sakkis]

On Apr 6, 10:53 am, Reckoner  wrote:
> hi,
>
> I have the following problem: I have two objects, say, A and B, which
> are both legitimate stand-alone objects with lives of their own.
>
> A contains B as a property, so I often do
>
> A.B.foo()
>
> the problem is that some functions inside of B actually need A
> (remember I said they were both standalone objects), so I have to
> often do:
>
> A.B.foo_func(A)
>
> Which is kind of awkward.
>
> Is there some way that B.foo_func() could somehow know that it was
> called as a property of A in this way?
>
> Note that I'm looking for the calling object and NOT the calling
> function.

Read up on descriptors [1], it seems that's what you're looking for.

HTH,
George

[1] http://users.rcn.com/python/download/Descriptor.htm
--
http://mail.python.org/mailman/listinfo/python-list

Re: "Pythoner",Wish me luck!

[George Sakkis]

On Apr 3, 3:47 pm, barisa  wrote:
> On Apr 3, 8:58 pm, nrball...@gmail.com wrote:
>
>
>
> > On Apr 3, 12:33 pm, barisa  wrote:
>
> > > On Apr 3, 11:39 am, "Hendrik van Rooyen"  wrote:
>
> > > > "Matteo"  wrote:
>
> > > > On Apr 3, 9:05 am, Linuxwell  wrote:
>
> > > > >> Starting today I would like to study Python,Wish me luck!
>
> > > > >Good luck!
>
> > > > >Don't forget to...
>
> > > >  print 'Hello World!'
>
> > > > This is better advice than what you may think,
> > > > because the interactive interpreter is your very
> > > > best friend when studying the language.
>
> > > > You get there by typing "python" at the command
> > > > line, and pressing enter.
>
> > > > Using it, you will save yourself many hours of
> > > > misunderstanding.
>
> > > > - Hendrik
>
> > > Hi,
> > > I'm also begginer in python;
> > > i did few basic programs about graph etc..
>
> > > my question is : what benefit is using interactive intrepreter ?
>
> > > i come from java backround, so I use eclipse for python as well.
> > > I start my program, it does it's job, and that's it.  (after some
> > > debugging ofc)
>
> > I'm also a beginner in Python, but from my own experience the
> > interactive interpreter is great for experimenting with new modules
> > and output formatting because it allows you to see the immediate
> > output of a function before you write it into your program.  The
> > immediate result is that you'll see any errors and be able to fix them
> > before they end up in your script.
>
> > Nick Ballardhttp://90daysofpython.blogspot.com
>
> thanks, i'll give it a try

Or even better, install IPython [1], a python interpreter on steroids.
It's the first 3rd party python package I install on every new system
I work on; it's so powerful and versatile, it has almost displaced the
regular linux shell for me. I highly recommend it.

George

[1] http://ipython.scipy.org/
--
http://mail.python.org/mailman/listinfo/python-list

Re: Best way to extract from regex in if statement

[George Sakkis]

On Apr 3, 9:56 pm, Jon Clements  wrote:
> On 4 Apr, 02:14, bwgoudey  wrote:
>
>
>
> > I have a lot of if/elif cases based on regular expressions that I'm using to
> > filter stdin and using print to stdout. Often I want to print something
> > matched within the regular expression and the moment I've got a lot of cases
> > like:
>
> > ...
> > elif re.match("^DATASET:\s*(.+) ", line):
> >         m=re.match("^DATASET:\s*(.+) ", line)
> >         print m.group(1))
>
> > which is ugly because of the duplication but I can't think of a nicer of way
> > of doing this that will allow for a lot of these sorts of cases. Any
> > suggestions?
> > --
> > View this message in 
> > context:http://www.nabble.com/Best-way-to-extract-from-regex-in-if-statement-...
> > Sent from the Python - python-list mailing list archive at Nabble.com.
>
> How about something like:
>
> your_regexes = [
>     re.compile('rx1'),
>     re.compile('rx2'),
>     # etc
> ]
>
> for line in lines:
>     for rx in your_regexes:
>         m = rx.match(line)
>         if m:
>             print m.group(1)
>             break # if only the first matching regex is required,
> otherwise leave black for all
>
> Untested, but seems to make sense

Or in case you want to handle each regexp differently, you can
construct a dict {regexp : callback_function} that picks the right
action depending on which regexp matched. As for how to populate the
dict, if most methods are short expressions, lambda comes in pretty
handly, e.g.

{
  rx1: lambda match: match.group(1),
  rx2: lambda match: sum(map(int, match.groups())),
 ...
}

If not, you can combine the handler definition with the mapping update
by using a simple decorator factory such as the following (untested):

def rxhandler(rx, mapping):
  rx = re.compile(rx)
  def deco(func):
  mapping[rx] = func
  return func
   return deco

d = {}

@rxhandler("^DATASET:\s*(.+) ", d)
def handle_dataset(match):
   ...

@rxhandler("^AUTHORS:\s*(.+) ", d)
def handle_authors(match):
   ...

HTH,
George
--
http://mail.python.org/mailman/listinfo/python-list

Re: simple iterator question

[George Sakkis]

On Apr 2, 8:32 am, Neal Becker  wrote:

> How do I interleave 2 sequences into a single sequence?
>
> How do I interleave N sequences into a single sequence?

http://lmgtfy.com/?q=python+interleave+sequences
http://code.activestate.com/recipes/511480/
http://code.activestate.com/recipes/528936/

HTH,
George
--
http://mail.python.org/mailman/listinfo/python-list

Re: Candidate for a new itertool

[George Sakkis]

On Mar 7, 8:47 pm, Raymond Hettinger  wrote:

> The existing groupby() itertool works great when every element in a
> group has the same key, but it is not so handy when groups are
> determined by boundary conditions.
>
> For edge-triggered events, we need to convert a boundary-event
> predicate to groupby-style key function.  The code below encapsulates
> that process in a new itertool called split_on().
>
> Would love you guys to experiment with it for a bit and confirm that
> you find it useful.  Suggestions are welcome.

That's pretty close to a recipe [1] I had posted some time ago (and
you commented improving it:)). As they stand, none is a generalization
of the other; your version allows either start or stop events (but not
both) while mine requires the start but takes an optional stop event
(plus an option to control whether separators are returned). If we
were to generalize them, the resulting signature would be something
like:

def split_on(iterable, **kwds):
'''Split iterable on event boundaries.

@keyword start,stop: The start and stop boundaries. Both are
optional
 (but at least one of them must be given).
@keyword yield_bounds: If True, yield also the boundary events.
'''


On a related note, I recently needed a grouper that I couldn't come up
with either groupby() or the split_on() above. The reason is that
instead of one, it needs two consecutive events to decide whether to
make a split or not. An example would be to partition an iterable of
numbers (or any orderable objects for that matter) in increasing or
non-decreasing groups:

>>> from operator import gt, ge
>>> list(groupby_needsbettername([3,4,4,2,2,5,1], gt))
[[3, 4, 4], [2, 2, 5], [1]]
>>> list(groupby_needsbettername([3,4,4,2,2,5,1], ge))
[[3, 4], [4], [2], [2, 5], [1]]

def groupby_needsbettername(iterable, is_boundary):
it = iter(iterable)
try: cur = it.next()
except StopIteration:
return
group = [cur]
for next in it:
if is_boundary(cur,next):
yield group
group = []
group.append(next)
cur = next
yield group


George

[1] http://code.activestate.com/recipes/521877/
--
http://mail.python.org/mailman/listinfo/python-list

Re: Disable automatic interning

[George Sakkis]

On Mar 18, 4:50 pm, "andrew cooke"  wrote:

> this is completely normal (i do exactly this all the time), BUT you should
> use "==", not "is".  

Typically, but not always; for example check out the identity map [1]
pattern used in SQLAlchemy [2].

George

[1] http://martinfowler.com/eaaCatalog/identityMap.html
[2] http://www.sqlalchemy.org/docs/05/session.html#what-does-the-session-do
--
http://mail.python.org/mailman/listinfo/python-list

Re: Disable automatic interning

[George Sakkis]

On Mar 18, 4:06 pm, Daniel Fetchinson 
wrote:

> > I'm working on some graph generation problem where the node identity
> > is significant (e.g. "if node1 is node2: # do something) but ideally I
> > wouldn't want to impose any constraint on what a node is (i.e. require
> > a base Node class). It's not a show stopper, but it would be
> > problematic if something broke when nodes happen to be (small)
> > integers or strings.
>
> But if two different nodes are both identified by, let's say the
> string 'x' then you surely consider this an error anyway, don't you?
> What's the point of identifying two different nodes by the same
> string?

In this particular problem the graph represents web surfing behavior
and in the simplest case the nodes are plain URLs. Now suppose a
session log has recorded the URL sequence [u1, u2, u1]. There are two
scenarios for the second occurrence of u1: it's either caused by a
forward action (e.g. clicking on a link to u1 from page u2) or a back
action (i.e. the user clicked the back button). If this information is
available, it makes sense to differentiate them. One way to do so is
to represent the result of every forward action with a brand-new node
and the result of a back action with an existing node. So even though
the state of the two occurrences of u1 are the same, they are not
necessarily represented by a single node.

If it was always possible to make a copy of  a string instance (say,
with a str.new() classmethod), then it would be sufficient to pass "map
(str.new, session_urls)" to the graph generator. Equality would still
work as before but all instances in the sequence would be guaranteed
to be unique. Thankfully, as Martin mentioned, this is easy even
without str.new(), simply by wrapping each url in an instance of a
small Node class.

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

Re: Disable automatic interning

[George Sakkis]

On Mar 18, 2:13 pm, "R. David Murray"  wrote:
> George Sakkis  wrote:
> > Is there a way to turn off (either globally or explicitly per
> > instance) the automatic interning optimization that happens for small
> > integers and strings (and perhaps other types) ? I tried several
> > workarounds but nothing worked:
>
> No.  It's an implementation detail.
>
> What use case do you have for wanting to disable it?

I'm working on some graph generation problem where the node identity
is significant (e.g. "if node1 is node2: # do something) but ideally I
wouldn't want to impose any constraint on what a node is (i.e. require
a base Node class). It's not a show stopper, but it would be
problematic if something broke when nodes happen to be (small)
integers or strings.

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

Re: How complex is complex?

[George Sakkis]

On Mar 18, 1:30 pm, Kottiyath  wrote:

> When we say readability counts over complexity, how do we define what
> level of complexity is ok?
> For example:
> Say I have dict a = {'a': 2, 'c': 4, 'b': 3}
> I want to increment the values by 1 for all keys in the dictionary.
> So, should we do:>>> for key in a:
>
> ...   a[key] = a[key] + 1
> or is it Ok to have code like:
> dict(map(lambda key: (key, a[key] + 1), a))
>
> How do we decide whether a level of complexity is Ok or not?

The second alternative is:
- unreadable (took me 10 seconds to parse vs 1 for the former).
- slower (makes a function call on every round).
- broken (creates a new dict instead of modifying the original in
place).

Really, there's not much of a dilemma here.

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

Disable automatic interning

[George Sakkis]

Is there a way to turn off (either globally or explicitly per
instance) the automatic interning optimization that happens for small
integers and strings (and perhaps other types) ? I tried several
workarounds but nothing worked:

>>> 'x' is 'x'
True
>>> 'x' is 'x'+''
True
>>> 'x' is ''+'x'
True
>>> 'x' is 'x'*1
True
>>> 'x' is str('x')
True
>>> 'x' is str('x')+str('')
True
>>> 'x' is str.__new__(str,'x')
True


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

Preserving file permissions with distutils

[George Sakkis]

I'm trying to use distutils to install some package data and
additional files, some of which may be executable. It turns out that
distutils does not preserve the permissions. Digging in the code,
there is the following comment on distutils/command/build_py:

# XXX copy_file by default preserves mode, which appears to be
the
# wrong thing to do: if a file is read-only in the working
# directory, we want it to be installed read/write so that the
next
# installation of the same module distribution can overwrite
it
# without problems.  (This might be a Unix-specific issue.)
Thus

If the only reason for not preserving the mode is ensuring it's read/
write, why not preserve the rest permissions and set the write flag
for the owner ? The comment continues:

# we turn off 'preserve_mode' when copying to the build
directory,
# since the build directory is supposed to be exactly what the
# installation will look like (ie. we preserve mode when
# installing).

But installing copies from the build dir which has forgotten the
original permissions, so there is no actual preservation! Am I reading
this wrong or should I submit a bug report ?

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

Re: Python is slow

[George Sakkis]

On Dec 15, 8:15 am, Luis M. González  wrote:
> On Dec 15, 1:38 am, cm_gui  wrote:
>
> > hahaha, do you know how much money they are spending on hardware to
> > make
> > youtube.com fast???
>
> > > By the way... I know of a very slow Python site called YouTube.com. In
> > > fact, it is so slow that nobody ever uses it.
>
> Buddy, just stop whining and go with c++ if it makes you happy.
> By the way, what's the blazingly fast application you need to write so
> desperately?
> What kind of performance problem have you find in python that makes
> you so unhappy?
> What are you going to do with all the extra speed provided by c++ (a
> Hello World! ?)...

Folks, do you *really* feel the urge to feed this troll and his 8-year-
old "arguments" again and again ? Please think twice before hitting
send on this pointless thread.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[George Sakkis]

On Dec 10, 1:42 pm, cm_gui <[EMAIL PROTECTED]> wrote:

> http://blog.kowalczyk.info/blog/2008/07/05/why-google-should-sponsor-...
>
> I fully agree with Krzysztof Kowalczyk .
> Can't they build a faster VM for Python since they love the language
> so much?

WTF is Krzysztof Kowalczyk and why should we care ?

Thanks for playing, the exit for the trolls is right down the hall.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Best way to report progress at fixed intervals

[George Sakkis]

On Dec 10, 2:50 am, Slaunger <[EMAIL PROTECTED]> wrote:
>
> Sorry, apparently I did not realize that at first sight. Anyway, I'd
> rather avoid using further external modules besides the standard
> batteries, as I would have to update several workstations with
> different OSes (some of which I do not have admin access to) to use
> the new module.

How is this different from writing your own module from scratch ? You
don't need admin access to use a 3rd party package.

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

Re: Best way to report progress at fixed intervals

[George Sakkis]

On Dec 9, 11:40 am, Slaunger <[EMAIL PROTECTED]> wrote:

> I would therefore like some feedback on this proposed generic "report
> progress at regular intervals" approach presented here. What could I
> do better?

There is a pypi package that might do what you're looking for (haven't
used it though): http://pypi.python.org/pypi/progressbar/.

HTH,
George
--
http://mail.python.org/mailman/listinfo/python-list

Re: "as" keyword woes

[George Sakkis]

On Dec 9, 9:28 am, MRAB <[EMAIL PROTECTED]> wrote:

> I certainly wouldn't want something like PL/I, where "IF", "THEN" and
> "ELSE" could be identifiers, so you could have code like:
>
>      IF IF = THEN THEN
>          THEN = ELSE;
>      ELSE
>          ELSE = IF;

Although I agree with the sentiment, you can write uncomprehensibly
insane code in any language; Python already gives a lot of horsepower
to run wild with metaclass magic, bytecode hacking, etc. The fact that
you *can* write abominations as the above doesn't mean that you
should; the OP's use case - using "foo.as(int)" - is pretty reasonable
and readable. I believe the responsibility to not abuse the power of
the language should be on the application programmer, not the language
designer.

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

Re: How to initialize a class variable once

[George Sakkis]

On Dec 9, 10:36 am, Joe Strout <[EMAIL PROTECTED]> wrote:

> On Dec 9, 2008, at 4:31 AM, Brian Allen Vanderburg II wrote:
>
> > There is one situation where a module can be imported/executed  
> > twice, if it is the __main__ module.
>
> That's an excellent point -- this is something I've run into, and it  
> always feels a bit awkward to code around it. What's the standard  
> idiom for avoiding this issue in a complex app?  Have a "main" file  
> that is not imported by anything else, and which does little but  
> launch stuff from some other module?

Yes, I believe that's the common practice. Still, whenever I end up
putting stuff in a "main" file and run into the double import problem
(e.g. when pickling), I do an explicit "from main import *" after all
the definitions, i.e.:

# myscript.py

__all__ = ['foo', 'Bar']

def foo(x,y):
   ...

class Bar(object):
   

from myscript import *

if __name__ == '__main__':
assert foo.__module__ == Bar.__module__ == 'myscript'


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

Re: Rich Comparisons Gotcha

[George Sakkis]

On Dec 7, 6:37 pm, Steven D'Aprano <[EMAIL PROTECTED]
cybersource.com.au> wrote:
> On Sun, 07 Dec 2008 23:20:12 +, Steven D'Aprano wrote:
> > On Sun, 07 Dec 2008 15:32:53 -0600, Robert Kern wrote:
>
> >> Rasmus Fogh wrote:
>
> >>> Current behaviour is both inconsistent and counterintuitive, as these
> >>> examples show.
>
> >> x = float('NaN')
> >> x == x
> >>> False
>
> >> Blame IEEE for that one. Rich comparisons have nothing to do with that
> >> one.
>
> > There is nothing to blame them for. This is the correct behaviour. NaNs
> > should *not* compare equal to themselves, that's mathematically
> > incoherent.
>
> Sorry, I should explain why.
>
> Given:
>
> x = log(-5)  # a NaN
> y = log(-2)  # the same NaN
> x == y  # Some people want this to be true for NaNs.
>
> Then:
>
> # Compare x and y directly.
> log(-5) == log(-2)
> # If x == y then exp(x) == exp(y) for all x, y.
> exp(log(-5)) == exp(log(-2))
> -5 == -2
>
> and now the entire foundations of mathematics collapses into a steaming
> pile of rubble.

And why doesn't this happen with the current behavior if x = y = log
(-5) ? According to the same proof,  -5 != -5.

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

Re: how to get a beep, OS independent ?

[George Sakkis]

On Dec 7, 7:49 am, Stef Mientki <[EMAIL PROTECTED]> wrote:

> Chris Rebert wrote:
> > On Sun, Dec 7, 2008 at 1:27 AM, Stef Mientki <[EMAIL PROTECTED]> wrote:
>
> >> Rainy wrote:
>
> >>> On Dec 6, 3:40 pm, Stef Mientki <[EMAIL PROTECTED]> wrote:
>
>  hello,
>
>  I want to give a small beep,
>  for windows there's message-beep,
>  and there seems to be something like " curses" ,
>  but that package seems to be totally broken in P2.5 for windows.
>
>  Any other suggestions ?
>
>  thanks,
>  Stef Mientki
>
> >>> For win there's winsound, you have to check sys.platform and do
> >>> what's necessary for the platform in question. In linux I think
> >>> you can just print '\a' (or does that only work in terminals?).
> >>> If you know that ext. speakers are always on, you can do a nicer
> >>> beep by using some wav file, in linux it's probably easiest to
> >>> use an external program to play it, like wavplay. Basically,
> >>> there is no single answer, it depends on circumstances.
> >>> --
> >>>http://mail.python.org/mailman/listinfo/python-list
>
> >> '\a' or chr(7) prints an inverted "BEL".
>
> > Inverted bell?
>
> In the output window (stdout) which is black letters on white background,
> it prints "bell" in white letters with a black background.>  What do you 
> mean? And what version dependency are you
> > referring to?
>
> Well some of you actually hear something,
> I don't,
> so I expect that the Python version differs.

Works for me on WinXP, Python 2.5:

C:\>python -c "print chr(7)"

makes a beep.

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

Re: Don't you just love writing this sort of thing :)

[George Sakkis]

On Dec 5, 8:06 am, Marco Mariani <[EMAIL PROTECTED]> wrote:
> Steven D'Aprano wrote:
> > Gosh Lawrence, do tell, which category do YOU fall into?
>
> I suppose a mix-up between a cowbody (or Fonzie) coder and a troll.

Naah.. more likely an (ex?) Lisper/Schemer.
--
http://mail.python.org/mailman/listinfo/python-list

Re: RELEASED Python 3.0 final

[George Sakkis]

On Dec 4, 4:49 pm, [EMAIL PROTECTED] wrote:

>     Andreas> Whenever has it been a pythonic ideal to "not allow" stuff? You
>     Andreas> get warnings. Everything else is up to you.
>
> It's more than warnings.  With properly crafted combinations of spaces and
> tabs you can get code which looks like it has a certain indentation to the
> human observer but which looks like it has different indentation (and thus
> different semantics) to the byte code compiler.  There is often no warning.

Amazing.. was it a conscious decision to keep the current behavior in
3.x or it was not even considered dropping it ?? Does anyone have a
link where this was decided ?

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

Re: Python 3 read() function

[George Sakkis]

On Dec 4, 2:01 pm, Дамјан Георгиевски <[EMAIL PROTECTED]> wrote:
> > I don't think it matters.  Here's a quick comparison between 2.5 and
> > 3.0 on a relatively small 17 meg file:
>
> > C:\>c:\Python30\python -m timeit -n 1
> > "open('C:\\work\\temp\\bppd_vsub.csv', 'rb').read()"
> > 1 loops, best of 3: 36.8 sec per loop
>
> > C:\>c:\Python25\python -m timeit -n 1
> > "open('C:\\work\\temp\\bppd_vsub.csv', 'rb').read()"
> > 1 loops, best of 3: 33 msec per loop
>
> > That's 3 orders of magnitude slower on python3.0!
>
> Isn't this because you have the file cached in memory on the second run?

That's probably it; I see much more modest slowdown (2-3X) if I repeat
many times each run.

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

Re: Overriding a method at the instance level on a subclass of a builtin type

[George Sakkis]

On Dec 4, 1:03 pm, "Zac Burns" <[EMAIL PROTECTED]> wrote:
> Ok... but why are the special methods handled differently?

Because otherwise they wouldn't be special ;-) And also for
performance and implementation reasons I believe.

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

Re: Overriding a method at the instance level on a subclass of a builtin type

[George Sakkis]

On Dec 4, 12:31 pm, Arnaud Delobelle <[EMAIL PROTECTED]> wrote:
> "Zac Burns" <[EMAIL PROTECTED]> writes:
> > The class method seems to be the most promising, however I have more
> > 'state' methods to worry about so I might end up building new classes
> > on the fly rather than have a class per permutation of states! Now the
> > code isn't quite as clear as I thought it was going to be.
>
> > It seems unfortunate to me that methods are always looked up on the
> > class for new style objects. Was this done for speed reasons?
>
> It's only special methods such as __getitem__, ...
>
> You can override normal method on a per-object basis just by adding a
> callable attribute with its name to the object:
>
> >>> class A(object):
>
> ...     def foo(self): print 'A.foo'
> ...>>> a = A()
> >>> a.foo()
> A.foo
> >>> def a_foo(): print 'a.foo'
> ...
> >>> a.foo = a_foo
> >>> a.foo()

Note that the overriden "method" here is a plain function; it doesn't
take self as the first argument. If you want to bind it to a callable
that expects the first argument to be self, you have to bind
explicitly self to the object:

>>> def a_foo(self): print 'a.foo'
>>> a.foo = a_foo
>>> a.foo()
TypeError: a_foo() takes exactly 1 argument (0 given)
>>> from functools import partial
>>> a.foo = partial(a_foo,a)
>>> a.foo()
a_foo

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

Re: Pythonic design patterns

[George Sakkis]

On Dec 4, 10:02 am, Steven D'Aprano <[EMAIL PROTECTED]
cybersource.com.au> wrote:
> On Thu, 04 Dec 2008 01:09:08 -0800, Slaunger wrote:
> > I find myself spending a lot of time in Python making some designs, to
> > solve some task, which is the end turn out to be closely related to well
> > established design patterns / programming idioms, which other users in
> > this forum has been kind enough to point out. Only my implementations
> > are often not that clean, and I may call things something different than
> > the normal convention, which is a source of confusion for myself and
> > others trying to communicate with me.
>
> > I guess I could boost my productivity by learning these well-proven and
> > well-established design patterns by heart.
>
> This is all very good, but don't drink the design pattern Kool-Aid and
> start pushing design patterns everywhere. (Not everything needs to be a
> singleton. No, really.)

Obligatory reading: http://www.mortendahl.dk/thoughts/blog/view.aspx?id=122

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

Re: Mathematica 7 compares to other languages

[George Sakkis]

On Dec 2, 4:57 pm, Lew <[EMAIL PROTECTED]> wrote:

> There is no reason for you to engage in an /ad hominem/ attack.  It
> does not speak well of you to resort to deflection when someone
> expresses a contrary opinion, as you did with both Jon Harrop and with
> me.  I suggest that your ideas will be taken more seriously if you
> engage in more responsible behavior.

As a Slashdotter would put it... you must be new here ;-)
--
http://mail.python.org/mailman/listinfo/python-list

Re: Overriding a method at the instance level on a subclass of a builtin type

[George Sakkis]

On Dec 2, 7:58 pm, "Zac Burns" <[EMAIL PROTECTED]> wrote:

> Sorry for the long subject.
>
> I'm trying to create a subclass dictionary that runs extra init code
> on the first __getitem__ call. However, the performance of __getitem__
> is quite important - so I'm trying in the subclassed __getitem__
> method to first run some code and then patch in the original dict
> method for the instance to avoid even the check to see if the init
> code has been run. Various recipes using instancemethod and the like
> have failed me.

For new-style classes, special methods are always looked up in the
class, not the instance, so you're out of luck there. What are you
trying to do? Perhaps there is a less magic solution to the general
problem.

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

Re: Scanner class

[George Sakkis]

On Dec 1, 5:42 pm, Arnaud Delobelle <[EMAIL PROTECTED]> wrote:
> George Sakkis <[EMAIL PROTECTED]> writes:
> > Is there any stdlib or (more likely) 3rd party module that provides a
> > similar functionality to the java.util.Scanner class [1] ? If not,
> > would there be any interest in porting it (with a more Pythonic API of
> > course) or are there better alternatives ?
>
> > George
>
> > [1]http://java.sun.com/j2se/1.5.0/docs/api/java/util/Scanner.html
>
> Have you looked at:
>
> >>> import re
> >>> re.Scanner
>
> 
>
> Last time I checked it was undocumented though, although I vaguely
> recall a Cookbook recipe.  Ah here it is:
>
> http://code.activestate.com/recipes/457664/

Thanks, didn't know about it. I also found Plex [1] which seems more
powerful.

George

[1] 
http://www.cosc.canterbury.ac.nz/greg.ewing/python/Plex/version/doc/index.html
--
http://mail.python.org/mailman/listinfo/python-list

Re: How to instantiate in a lazy way?

[George Sakkis]

On Dec 2, 10:01 am, Slaunger <[EMAIL PROTECTED]> wrote:
> Just wanted to show the end result in its actual implementation!
>
> I ended up *not* making a decorator, as I already had a good idea
> about how to do it
> using __getattr__
>
> class PayloadDualFrqIQOnDemand(PayloadDualFrqIQ):
>     """
>     This class has the same interface as its parent,
>     but unlike its parent, it is instantiated without
>     its payload parsed up in its instance attributes
>     Q1, I1, Q2 and I2. Instead it stores a reference to
>     the file object in which the Payload data can be
>     read, the file position and
>     the version of the payload data.
>
>     On accessing one of the data attributes, the actual
>     payload data are read from the file, and the reference to
>     the file object is unbound.
>     The constructor signature is therefore different from its
>     parent as it takes the file object, position and version
>     as arguments instead of the actual data.
>     """
>
>     @classmethod
>     def _unpack_from_file(cls, f, samples, ver):
>         bytes = samples * cls.bytes_per_sample
>         initial_pos = f.tell()
>         f.seek(initial_pos + bytes) #Skip over the payload
>         return cls(f, initial_pos, samples, ver)
>
>     @classmethod
>     def unpack_from_ver3_file(cls, f, samples):
>         return cls._unpack_from_file(f, samples, ver=3)
>
>     @classmethod
>     def unpack_from_ver4_file(cls, f, samples):
>         return cls._unpack_from_file(f, samples, ver=4)
>
>     data_attr_names = frozenset(["Q1", "I1", "Q2", "I2"])
>
>     def __init__(self, a_file, a_file_position, samples, a_version):
>         """
>         Returns an instance where the object knows where to
>         look for the payload but it will only be loaded on the
>         first attempt to read one of the data attributes
>         in a "normal" PayloadDualFrqIQ object.
>         """
>         self.f = a_file
>         self.file_position = a_file_position
>         self.samples = samples
>         self.ver = a_version
>
>     def __getattr__(self, attr_name):
>         """
>         Checks if a request to read a non-existing data attribute
>         has an attribute corresponding to one of the data attributes
>         in a normal PayloadDualFrqIQ object.
>
>         If true, the data attributes are created and bound to the
>         object using the file object instance, the file position
>         and the version.
>
>         It is a prerequisite that the file object is still open.
>         The function leaves the file object at the file position
>         when it entered the method
>
>         """
>         cls = self.__class__
>         if attr_name in cls.data_attr_names:
>             initial_pos = self.f.tell()
>             try:
>                 bytes = self.samples * cls.bytes_per_sample
>                 self.f.seek(self.file_position)
>                 buf = self.f.read(bytes)
>                 if self.ver == 3:
>                     bytes_to_data = cls._v3_byte_str_to_data
>                 elif self.ver == 4:
>                     bytes_to_data = cls._v4_byte_str_to_data
>                 else:
>                     raise TermaNotImplemented, \
>                         "Support for ver. %d not implemented." %
> self.ver
>                 I1, Q1, I2, Q2 = bytes_to_data(buf)
>                 self.__dict__["I1"] = I1
>                 self.__dict__["Q1"] = Q1
>                 self.__dict__["I2"] = I2
>                 self.__dict__["Q2"] = Q2
>                 return self.__dict__[attr_name]
>             finally:
>                 # Restore file position
>                 self.f.seek(initial_pos)
>                 # Unbind lazy attributes
>                 del self.f
>                 del self.ver
>                 del self.file_position
>                 del self.samples
>
> This seems to work out well. No infinite loops in __getattr__!
>
> At least it passes the unit test cases I have come up with so far.
>
> No guarantees though, as I may simply not have been smart enough to
> bring forth unit test cases which make it crash.
>
> Comments on the code is still appreciated though.

A trivial improvement: replace

> I1, Q1, I2, Q2 = bytes_to_data(buf)
> self.__dict__["I1"] = I1
> self.__dict__["Q1"] = Q1
> self.__dict__["I2"] = I2
> self.__dict__["Q2"] = Q2

with:

self.__dict__.update(zip(self.data_attr_names, bytes_to_data
(buf)))

where data_attr_names = ("I1", "Q1", "I2", "Q2") instead of a
frozenset. A linear search in a size-4 tuple is unlikely to be the
bottleneck with much I/O anyway.

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

Scanner class

[George Sakkis]

Is there any stdlib or (more likely) 3rd party module that provides a
similar functionality to the java.util.Scanner class [1] ? If not,
would there be any interest in porting it (with a more Pythonic API of
course) or are there better alternatives ?

George

[1] http://java.sun.com/j2se/1.5.0/docs/api/java/util/Scanner.html
--
http://mail.python.org/mailman/listinfo/python-list

Re: HELP!...Google SketchUp needs a Python API

[George Sakkis]

On Nov 28, 4:16 pm, "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote:

> Now, up up and away into my killfilter,

Ditto; apparently it's either a troll or an 8-year old.

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

Re: Great exercise for python expert !

[George Sakkis]

On Nov 28, 9:19 am, manatlan <[EMAIL PROTECTED]> wrote:

> On 28 nov, 14:58, George Sakkis <[EMAIL PROTECTED]> wrote:
>
>
>
> > On Nov 28, 5:36 am, manatlan <[EMAIL PROTECTED]> wrote:
>
> > > I'd like to make a "jquery python wrapper" ...
>
> > > here is my code :
> > > ===
> > > #!/usr/bin/env python
> > > # -*- coding: utf-8 -*-
>
> > > class JQueryCaller(object):
> > >     def __init__(self,callback):
> > >         self.__callback=callback
> > >         self._s=[]
>
> > >     def __getattr__(self,name):
> > >         def _caller(*args):
> > >             sargs=["'%s'"%i for i in args]
> > >             self._s.append("%s(%s)"%(name,",".join(sargs)))
> > >             return self
> > >         return _caller
>
> > >     def __call__(self):
> > >         return self.__callback(".".join(self._s))
>
> > > class MyObject(object):
> > >     def __init__(self):
> > >         self.js = JQueryCaller(self.__add)
>
> > >     def __add(self,j):
> > >         print "Add:"+j
>
> > > if __name__ == "__main__":
> > >     o=MyObject()
>
> > >     o.js.kiki(12).kuku()()
> > > ===
> > > If i run the script : it will display :
>
> > > Add:kiki('12').kuku()
>
> > > Because the JQueryCaller caller is called, by the "()" trick at the
> > > end of the last line
>
> > > I'd like to display the same thing, but without the need to put the
> > > "()" at then end !
> > > (by calling simply : "o.js.kiki(12).kuku()" not "o.js.kiki(12).kuku()
> > > ()")
> > > (or how to call the MyObject._add (callback) without using the caller
> > > on my JQueryCaller)
>
> > Why don't you rename __call__ to __str__ and have MyObject.__add
> > return a string instead of printing it directly?
>
> > class MyObject(object):
> >     def __add(self,j):
> >         return "Add:"+j
>
> > if __name__ == "__main__":
> >     o = MyObject()
> >     s = o.js.kiki(12).kuku()
> >     print s
>
> > HTH,
> > George
>
> sure, it works like you said ... but it's not what I want.
> by doing that, you create an action ... when you will call "print" it
> will call the __str__ (__repr__ is better in that case), which will
> call the callback of myobject.
> In my preceding post, the action was called by the "()" trick at the
> end of line

... which you apparently don't like, and rightly so. __getattr__ and
__call__ do totally different things in your example, why do you want
to conflate them ?

> In fact, MyObject will handle a list of all "js call"
> If i do :
>   o.js.toto()
>   o.js.toto().titi(12,13)
>
> I'd like my MyObject contains a list like that ["toto()","toto().titi
> (12,23)"]

Of course this still happens when you rename __call__ to __str__.

> another idea ?

Yes, put a little more thought on your design and give a more
realistic example of what you're really trying to do; so far it seems
more like a pointless hack.

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

Re: Great exercise for python expert !

[George Sakkis]

On Nov 28, 5:36 am, manatlan <[EMAIL PROTECTED]> wrote:
> I'd like to make a "jquery python wrapper" ...
>
> here is my code :
> ===
> #!/usr/bin/env python
> # -*- coding: utf-8 -*-
>
> class JQueryCaller(object):
>     def __init__(self,callback):
>         self.__callback=callback
>         self._s=[]
>
>     def __getattr__(self,name):
>         def _caller(*args):
>             sargs=["'%s'"%i for i in args]
>             self._s.append("%s(%s)"%(name,",".join(sargs)))
>             return self
>         return _caller
>
>     def __call__(self):
>         return self.__callback(".".join(self._s))
>
> class MyObject(object):
>     def __init__(self):
>         self.js = JQueryCaller(self.__add)
>
>     def __add(self,j):
>         print "Add:"+j
>
> if __name__ == "__main__":
>     o=MyObject()
>
>     o.js.kiki(12).kuku()()
> ===
> If i run the script : it will display :
>
> Add:kiki('12').kuku()
>
> Because the JQueryCaller caller is called, by the "()" trick at the
> end of the last line
>
> I'd like to display the same thing, but without the need to put the
> "()" at then end !
> (by calling simply : "o.js.kiki(12).kuku()" not "o.js.kiki(12).kuku()
> ()")
> (or how to call the MyObject._add (callback) without using the caller
> on my JQueryCaller)

Why don't you rename __call__ to __str__ and have MyObject.__add
return a string instead of printing it directly?

class MyObject(object):
def __add(self,j):
return "Add:"+j

if __name__ == "__main__":
o = MyObject()
s = o.js.kiki(12).kuku()
print s


HTH,
George
--
http://mail.python.org/mailman/listinfo/python-list

Re: HELP!...Google SketchUp needs a Python API

[George Sakkis]

On Nov 27, 10:45 pm, r <[EMAIL PROTECTED]> wrote:

> I am still flabbergasted by the solid resistance to promoting Python.
> Here of all places, NOT even one person(well Terry did kinda half
> agree with me =), wants to support Python. I am completely perplexed.
> I had to check and make sure this was comp.lang.python and NOT
> comp.lang.ruby.
>
> (more inane rambling snipped)

It's indeed comp.lang.python, a list which for whatever sociological
reason attracts mainly moderate posters rather than rabid fanboys and
script kiddies, unlike other communities you may be more familiar
with. Perhaps you chose the wrong group for your new adopted religion.
Why don't you go read a tutorial, write up some code, and come back
with any real questions next time.

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

Re: Applying a decorator to a module

[George Sakkis]

On Nov 27, 2:54 pm, lkcl <[EMAIL PROTECTED]> wrote:
> On Nov 27, 7:43 pm, [EMAIL PROTECTED] wrote:
>
> >     lkcl> Very simple question: how do you apply a decorator to an entire
> >     lkcl> module?
>
> > Function-by-function or class-by-class.  There is no decorator support for
> > modules.
>
> awWww!  i'm going to quietly throw my toys out of my pram.
>
> ... but seriously - doesn't that strike people as... a slightly odd
> omission?

Not really; functions and classes are explicitly defined by "def .."
and "class ...", modules are not.

You can always pass the module to the decorator explicitly:

import mymod
mymod = decorator(mymod)

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

Re: what's so difficult about namespace?

[George Sakkis]

On Nov 26, 11:42 am, Stefan Behnel <[EMAIL PROTECTED]> wrote:
> Xah Lee wrote:
> >> The IT community has enough trouble getting a few ISPs to upgrade their
> >> DNS software. How are you going to get millions of general users to
> >> upgrade?
>
> > alright, that's speaks for Javascript.
>
> > But how's that apply to, say, Scheme lisp, Emacs lisp, PHP?
>
> Think before you write. It's exactly the same thing. How would you get all
> Emacs users in the world to upgrade?

The same way you would get all Python users to upgrade to 3.0 ? It's
not like Joe User runs emacs to edit his grocery store list.

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

Re: Instance attributes vs method arguments

[George Sakkis]

On Nov 25, 8:49 pm, John O'Hagan <[EMAIL PROTECTED]> wrote:

> is there an
> difference in efficiency (for large enough number of methods and arguments)
> between
>
> a) passing all arguments to __init__() and accessing them via self within
> individual methods:
>
> class = Class(all_class_args)
> class.method_a()
> class.method_b()
> ...
> or
>
> b) passing the arguments needed by each method when it is called on an
> instance:
>
> class = Class()
> class.method_a(a_args)
> class.method_b(b_args)
> ...

The difference in API here is more crucial than the difference in
performance. Deciding between the two based on the (guessed or
measured) performance improvement misses the point of OO design.

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

Re: end of print = lower productivity ?

[George Sakkis]

On Nov 25, 5:03 pm, Paul Rubin  wrote:
> [EMAIL PROTECTED] writes:
> > > BUT you now can do
> > > >>> p = print
> > > >>> p("f")
> > All right. Let's talk about that.
>
> > When I write "print", it is both effortless and instantaneous : my
> > hands do not move, a wave goes through my fingers, it all happens in a
> > tenth of a second.
>
> > Contrast this with what one has to go through to catch the SHIFT key ...
>
> You could say:
>
>     class Printer:
>         def __isub__(self, x): print(x)
>     p = Printer()
>
> Then
>
>     p-= "foo"
>
> doesn't need use of the shift key.  Use of -= instead of - gets rid
> of operator precedence issues.

Please don't forget the smileyes when you make such ludicrous
suggestions; if anyone takes them seriously you could be cursed to
maintain his code ;-)
--
http://mail.python.org/mailman/listinfo/python-list

Re: end of print = lower productivity ?

[George Sakkis]

On Nov 25, 10:52 am, [EMAIL PROTECTED] wrote:
>     >> Now the print statement disappeared, and I have to write print("f")
>     >> instead. These parentheses not only take time to write, they also make
>     >> me think twice about using print for debugging purposes. Pressing <
>     >> SHIFT > then < ( > then < " > makes the whole process quite a hassle.
>
> :rollseyes:
>
> I hope there was a missing smiley in that post.  If a couple extra parens
> destroys your debugging productivity I suspect you need a fresh approach to
> the task.

Seconded; I thought he's either joking or trolling.

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

Re: Python 3 __cmp__ semantic change?

[George Sakkis]

On Nov 23, 6:14 am, Arnaud Delobelle <[EMAIL PROTECTED]> wrote:

> So how did I get it into my head that defining __eq__ would create the
> correct behaviour for __ne__ automatically?  And more puzzlingly, how
> come it is what actually happens?  Which should I believe: the
> documentation or the implementation?

According to Guido, the implementation:
http://mail.python.org/pipermail/python-ideas/2008-October/002235.html.

George


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

Re: how to dynamically instantiate an object inheriting from several classes?

[George Sakkis]

On Nov 22, 9:32 am, Joe Strout <[EMAIL PROTECTED]> wrote:
> On Nov 21, 2008, at 7:02 PM, Steven D'Aprano wrote:
>
> >> I have a function that takes a reference to a class,
>
> > Hmmm... how do you do that from Python code? The simplest way I can  
> > think
> > of is to extract the name of the class, and then pass the name as a
> > reference to the class, and hope it hasn't been renamed in the  
> > meantime...
>
> Please quit trying to confuse the kids at home.  Classes in Python are  
> first-class objects, and any time you refer to a class or any other  
> object in Python, what you have is a reference to it.

..which makes the phrase "a reference to an X" a more verbose,
redundant version of "an X" since it applies to *every* Python object.
You have made your point in the 300+ posts thread, so please quit the
terminology trolling in every new thread.

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

Re: how to dynamically instantiate an object inheriting from several classes?

[George Sakkis]

On Nov 21, 5:11 pm, Joe Strout <[EMAIL PROTECTED]> wrote:
> I have a function that takes a reference to a class, and then  
> instantiates that class (and then does several other things with the  
> new instance).  This is easy enough:
>
>     item = cls(self, **itemArgs)
>
> where "cls" is the class reference, and itemArgs is obviously a set of  
> keyword arguments for its __init__ method.
>
> But now I want to generalize this to handle a set of mix-in classes.  
> Normally you use mixins by creating a class that derives from two or  
> more other classes, and then instantiate that custom class.  But in my  
> situation, I don't know ahead of time which mixins might be used and  
> in what combination.  So I'd like to take a list of class references,  
> and instantiate an object that derives from all of them, dynamically.
>
> Is this possible?  If so, how?

Easily:

derived_cls = type('Derived', (cls1, cls2, *rest_classes), {})
item = derived_cls(**itemArgs)

You will probably want to cache the generated classes so that at most
one class is created for each combination of mixins.

HTH,
George
--
http://mail.python.org/mailman/listinfo/python-list

Re: matching exactly a 4 digit number in python

[George Sakkis]

On Nov 21, 4:46 pm, harijay <[EMAIL PROTECTED]> wrote:

> Hi
> I am a few months new into python. I have used regexps before in perl
> and java but am a little confused with this problem.
>
> I want to parse a number of strings and extract only those that
> contain a 4 digit number anywhere inside a string
>
> However the regexp
> p = re.compile(r'\d{4}')
>
> Matches even sentences that have longer than 4 numbers inside
> strings ..for example it matches "I have 3324234 and more"
>
> I am very confused. Shouldnt the \d{4,} match exactly four digit
> numbers so a 5 digit number sentence should not be matched .

No, why should it ? What you're saying is "give me 4 consecutive
digits", without specifying what should precede or follow these
digits. A correct expression is a bit more hairy:

p = re.compile(r'''
(?:\D|\b)# find a non-digit or word boundary..
(\d{4})   # .. followed by the 4 digits to be matched as group
#1..
(?:\D|\b)# .. which are followed by non-digit or word boundary
''', re.VERBOSE)


HTH,
George
--
http://mail.python.org/mailman/listinfo/python-list

Re: initialization in argument definitions

[George Sakkis]

On Nov 21, 4:25 pm, Brentt <[EMAIL PROTECTED]> wrote:

> Hi, I know this is a terribly simple question, but the docs seem to be
> designed for people who probably find a the answer to this question
> terribly obvious. But its not at all obvious to me.

Don't worry, it's not obvious to *anyone* new to Python (and many not-
so-new for that matter).

> I can't figure out why when I define a function, a variable
> (specifically a list) that I define and initialize in the argument
> definitions, will not initialize itself every time its called. So for
> example, when making a simple list of a counting sequence from num (a
> range list), if I call the function multiple times, it appends the
> elements to the list generated the times it was called before, even
> though the variable for the list is initialized in the argument
> definitions.
>
> def foo_range(num,aList = []):
> aList = []
> #why is this seemingly extra initialization necessary? shouldn't it be
> initialized in the argument definitions?
> #but if its not there and the function is called multiple times the
> elements generated (see below)
> #append to the list generated before.
> while num <= 10:
> aList.append(num)
> num +=1
> else:
> return aList
>
> Why is this? Thanks, hope its not a stupid quesiton.

Sigh.. no it's not stupid at all; actually it is (and will probably
remain, unfortunately) the most FAQ of all times:
   
http://www.python.org/doc/faq/general/#why-are-default-values-shared-between-objects

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

Re: Need help converting text to csv format

[George Sakkis]

On Nov 21, 2:01 pm, Richard Riley <[EMAIL PROTECTED]> wrote:

> George Sakkis <[EMAIL PROTECTED]> writes:
> > On Nov 21, 11:05 am, Steve Holden <[EMAIL PROTECTED]> wrote:
> >> George Sakkis wrote:
> >> > On Nov 21, 10:18 am, Chuck Connors <[EMAIL PROTECTED]> wrote:
>
> >> >> Any help, pseudo code, or whatever push in the right direction would
> >> >> be most appreciated.  I am a novice Python programmer but I do have a
> >> >> good bit of PHP programming experience.
>
> >> > I'm wondering if PHP experience precludes the ability to use a search
> >> > engine before asking for help...
>
> >> I'm wondering why you bothered to write that. Next time, save yourself
> >> the ten seconds and just skip to the next message. The world will be a
> >> better place.
>
> > RTFM and doing an elementary search is an even better way to making
> > the world a better place.
>
> > George
>
> So you will be replying in this tone to each and every question which
> has an answer discoverable by Google and in depth knowledge of the "FM"
> then I assume?

No, only to those which is blatantly obvious that they didn't put any
effort whatsoever to find an answer on their own; "python csv" has
1,420,000 hits in Google, the first one linking to the csv module
docs. Feel free to check out my 4-year posting history in c.l.py to
get a more accurate idea of the usefulness and tone of my posts.

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

Re: Need help converting text to csv format

[George Sakkis]

On Nov 21, 11:05 am, Steve Holden <[EMAIL PROTECTED]> wrote:
> George Sakkis wrote:
> > On Nov 21, 10:18 am, Chuck Connors <[EMAIL PROTECTED]> wrote:
>
> >> Any help, pseudo code, or whatever push in the right direction would
> >> be most appreciated.  I am a novice Python programmer but I do have a
> >> good bit of PHP programming experience.
>
> > I'm wondering if PHP experience precludes the ability to use a search
> > engine before asking for help...
>
> I'm wondering why you bothered to write that. Next time, save yourself
> the ten seconds and just skip to the next message. The world will be a
> better place.

RTFM and doing an elementary search is an even better way to making
the world a better place.

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

Re: Dynamic features used

[George Sakkis]

On Nov 21, 7:55 am, [EMAIL PROTECTED] wrote:

> It's not easy to define what my point was :-) I try again, but the
> following questions don't cover all the points:
> - What are the dynamic features of Python that you use in your code?
> (excluding ones that can can be done with a good static template
> system).

Off the top of my head, getattr/setattr are the most frequent dynamic
features I use.

> - Are them worth the decrease in running speed?
> - Is it good for Python to become two languages in one, a fast
> statically typed one and a dynamically one, like pypy shows to like
> with RPython, or is it better to go the way of the Boo language, that
> (while being mostly static) is mixing dynamic and static typing in the
> same code, but that must rely on a very complex virtual machine to
> work?
> - Or maybe is it better to find other ways like CLips ones, that allow
> to mix dynamic and static features, generally keeping programs fast
> enough (Lisp-like syntax can lead to high performance too, as shown by
> the Stalin Scheme 
> compilerhttp://en.wikipedia.org/wiki/Stalin_(Scheme_implementation)

Very valid points, and I also often think that dynamic typing is
overrated; most programs don't need to add or remove attributes at
will or change the class hierarchy. I don't know which of the
alternatives you mention would be better but I would welcome changes
towards the "static by default" direction, provided that (1) it *is*
still possible to write dynamic code if necessary and (2) the extra
effort in writing and reading it is not off-putting (e.g. no C++
template metaprogramming atrocities)

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

Re: Need help converting text to csv format

[George Sakkis]

On Nov 21, 10:18 am, Chuck Connors <[EMAIL PROTECTED]> wrote:

> Any help, pseudo code, or whatever push in the right direction would
> be most appreciated.  I am a novice Python programmer but I do have a
> good bit of PHP programming experience.

I'm wondering if PHP experience precludes the ability to use a search
engine before asking for help...
--
http://mail.python.org/mailman/listinfo/python-list

Re: Using eval, or something like it...

[George Sakkis]

On Nov 20, 6:54 pm, r0g <[EMAIL PROTECTED]> wrote:

> It would seem from this setattr function that the proper term for these
> is 'attributes'. That for many years I have considered pretty much any
> named thing that may vary a 'variable' might be at the root of the
> problem here as it's a very un-specific term...

Exactly, refrain from using the term "variable", or "value" for that
matter, in Python context as they are notorious for causing more
trouble than they deserve..

> So I gather you are saying that the fragments of state within a class
> are so distinct from ordinary common or garden variables that it is
> incorrect to think of them, or describe them, as variables, much like
> quarks should not really be regarded as distinct particles, and they
> should only be thought of and described as 'attributes' to avoid confusion?
>
> Is this correct enough for me to avoid the aforementioned bug pile?

No, a class can have attributes just like a instance can, and you can
use setattr() to set an attribute for a class just like you do it for
instances:

class Foo():
  bar = 1
  gum = 2

>>> setattr(Foo, 'bar', 3)
>>> Foo.bar
3

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

Re: Python 3 __cmp__ semantic change?

[George Sakkis]

On Nov 20, 6:58 pm, [EMAIL PROTECTED] wrote:

>     Johannes> Seems it was removed on purpose - I'm sure there was a good
>     Johannes> reason for that, but may I ask why?
>
> Start here:
>
>     http://www.mail-archive.com/[EMAIL PROTECTED]/msg11474.html
>
> Also, a comment to this blog post suggests creating a CmpMixin:
>
>    http://oakwinter.com/code/porting-setuptools-to-py3k/
>
> Skip

Dropping __cmp__ without providing implicit or at least easy explicit
[1] total ordering is (was?) a mistake; it opens the door to subtle
bugs or redundant boilerplate code.

[1] E.g. http://code.activestate.com/recipes/576529/
--
http://mail.python.org/mailman/listinfo/python-list

Re: function parameter scope python 2.5.2

[George Sakkis]

On Nov 20, 6:40 pm, J Kenneth King <[EMAIL PROTECTED]> wrote:
> J Kenneth King <[EMAIL PROTECTED]> writes:
>
>
>
> > I recently encountered some interesting behaviour that looks like a bug
> > to me, but I can't find the appropriate reference to any specifications
> > to clarify whether it is a bug.
>
> > Here's the example code to demonstrate the issue:
>
> > class SomeObject(object):
>
> >     def __init__(self):
> >         self.words = ['one', 'two', 'three', 'four', 'five']
>
> >     def main(self):
> >         recursive_func(self.words)
> >         print self.words
>
> > def recursive_func(words):
> >     if len(words) > 0:
> >         word = words.pop()
> >         print "Popped: %s" % word
> >         recursive_func(words)
> >     else:
> >         print "Done"
>
> > if __name__ == '__main__':
> >     weird_obj = SomeObject()
> >     weird_obj.main()
>
> > The output is:
>
> > Popped: five
> > Popped: four
> > Popped: three
> > Popped: two
> > Popped: one
> > Done
> > []
>
> > Of course I expected that recursive_func() would receive a copy of
> > weird_obj.words but it appears to happily modify the object.
>
> > Of course a work around is to explicitly create a copy of the object
> > property befor passing it to recursive_func, but if it's used more than
> > once inside various parts of the class that could get messy.
>
> > Any thoughts? Am I crazy and this is supposed to be the way python works?
>
> Of course, providing a shallow (or deep as necessary) copy makes it
> work, I'm curious as to why the value passed as a parameter to a
> function outside the class is passed a reference rather than a copy.

Why should it be a copy by default ? In Python all copies have to be
explicit.

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

Re: help with comparison

[George Sakkis]

On Nov 19, 10:21 pm, tekion <[EMAIL PROTECTED]> wrote:
> Hi,
> Could some one take a look at the below code snipet which keep
> failing:
>
> import optparse
> p = optparse.OptionParser(description="script to do stuff",
> prog="myscript.py", )
> p.add_option("-c" "--compress", help="0 is noncompress")
> function1(options.compress)
>
> here's what the what function definition looks like:
> function1(zipfile) :
> if (zipfile == 1):
>    do stuff here with for compress file
> else
>    do stuff here
>
> when I call the script "myscript.py 1", the above test keeps falling
> to the else clause.  I am thinking the object zipfile is not the same
> as "1". Any thoughts as how I should test if the argument being pass
> in and parse by optparse is 1 or "0"?  Thanks.

1 (without quotes) is not the same as "1" (with quotes); the first is
an integer, the second a string. optparse returns strings by default,
so the easiest change would be to make the check 'if zipfile == "1"'.

Even better, since it's a boolean option, pass action="store_true" to
p.add_option(). The test then is reduced to "if zipfile" and the
program is to be called by "myscript.py -c". Read the docs [1] for
more details.

HTH,
George

[1] http://docs.python.org/library/optparse.html#standard-option-actions
--
http://mail.python.org/mailman/listinfo/python-list

Re: Using eval, or something like it...

[George Sakkis]

On Nov 19, 7:44 pm, r0g <[EMAIL PROTECTED]> wrote:
> Hi There,
>
> I know you can use eval to dynamically generate the name of a function
> you may want to call. Can it (or some equivalent method) also be used to
> do the same thing for the variables of a class e.g.
>
> class Foo():
>   bar = 1
>   gum = 2
>
> mylist = ['bar','gum']
>
> a = Foo()
> for each in mylist:
>   a.eval(each) = 999
>
> If so, what is the proper syntax/method for this.

for each in mylist:
setattr(a, each, 999)


HTH,
George
--
http://mail.python.org/mailman/listinfo/python-list

Re: Optional parameter object re-used when instantiating multiple objects

[George Sakkis]

On Nov 19, 1:05 pm, Dennis Lee Bieber <[EMAIL PROTECTED]> wrote:

> On Wed, 19 Nov 2008 05:41:57 -0800 (PST), Rick Giuly
> <[EMAIL PROTECTED]> declaimed the following in comp.lang.python:
>
>
>
> > (By "better" I mean that over many years of time programmers will be
> > more productive because the language will be learned a bit faster with
> > a fewer surprises - and still retain its power.)
>
>         Your opinion... I'm sure there are some libraries out there that
> rely upon the current behavior

That's a straw man; of course they rely on it since they can. The same
would be even more true if the opposite behavior was selected from the
beginning, many more libraries would rely on it instead of (ab)using
None as default.

>  -- not to mention the hit on processing
> speed.

That's the only argument that may worth some merit. It's interesting
though that C++, a language much more obsessed with performance, picks
the runtime semantics:

#include 
using namespace std;

int a = 1;

int f(int a) {
  cout << "f(" << a << ") called\n";
  return a;
}

int g(int x = f(a)) { return x; }

int main() {
  cout << g() << endl;
  a = 2;
  cout << g() << endl;
}

#= output ==
f(1) called
1
f(2) called
2

>         I wouldn't expect a language like Ada to somehow re-evaluate a
> default argument on each call; why would I expect Python to do such?

Again, non sequitur. Python is not Ada (neither is C++, which does the
expected thing in this case).

>         Besides, learning is good for one -- and having something like this
> in Python gives one an excuse to learn something about language
> implementation choices 
>
>         And what behavior do you expect from:
>
>
>
> >>> d1 = [ 1, 2 ]
> >>> def what(arg = d1):
> ...     print arg
>
> ...    
> >>> what()
> [1, 2]
> >>> d1 = ( 3.14159, 2.78)
> >>> what()
> [1, 2]
>
>         If one does reevaluation of the default on each call, the second
> call should be printing
>
> (3.14159, 2.78)
>
>
>
> >>> del d1
> >>> what()
> [1, 2]
>
>         And that sequence would result in an exception
>
> Traceback (most recent call last):
>   File "", line 1, in 
> NameError: name 'd1' is not defined
>
>         Do you really want a "default" argument that changes value depending
> upon actions performed in the /surrounding/ scope?

Yes, the surrounding scope in this case is the global scope; changing
or deleting globals has by definition global reach. Regardless, how
common is this usage in real code ? I believe an order of magnitude
less than the need for fresh mutable objects.

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

Re: python vs smalltalk 80

[George Sakkis]

On Nov 19, 1:53 am, gavino <[EMAIL PROTECTED]> wrote:

> python vs smalltalk 80
>
> which is nicer?

Dunno but there's an interesting talk about this: 
http://www.youtube.com/watch?v=oHg5SJYRHA0

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

Re: More elegant way to try running a function X times?

[George Sakkis]

On Nov 19, 10:21 am, Gilles Ganault <[EMAIL PROTECTED]> wrote:

> On 19 Nov 2008 14:37:06 + (GMT), Sion Arrowsmith
>
> <[EMAIL PROTECTED]> wrote:
> >Note very carefully that the "else" goes with the "for" and not the "if".
>
> Thanks guys.

And if you end up doing this for several different functions, you can
factor it out with the following decorator:

class MaxRetriesExceededError(Exception):
pass

def retry(n):
def decorator(f):
def wrapper(*args, **kwds):
for i in xrange(n):
r = f(*args, **kwds)
if r: return r
raise MaxRetriesExceededError
return wrapper
return decorator

If the number of retries is fixed and known at "compile" time, you can
use the standard decorator syntax:

@retry(5)
def CheckIP():
   ...

If not, just decorate it explicitly at runtime:

def CheckIP():
  ...

n = int(raw_input('Give number of retries:'))
CheckIP = retry(n)(CheckIP)


HTH,
George
--
http://mail.python.org/mailman/listinfo/python-list

Re: Optional parameter object re-used when instantiating multiple objects

[George Sakkis]

On Nov 19, 8:41 am, Rick Giuly <[EMAIL PROTECTED]> wrote:

> Python provides, for the most part, an *excellent* user
> interface to the programmer. Why not make it even "better"
> by evaluating the arguments each time the function is called?
> It will be harder to change the language 10 years from now,
> so why not change it now?

You probably messed up with your time machine; "now" is 2008, not
1991 ;-)

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

Re: Python-URL! - weekly Python news and links (Nov 17)

[George Sakkis]

On Nov 17, 12:44 pm, [EMAIL PROTECTED] wrote:
> On Nov 17, 8:54 am, "Gabriel Genellina" <[EMAIL PROTECTED]>
> wrote:
>
> >     Candidate to *Longest and Most Boring Thread of the Year* - started
> >     more than a month ago, currently discussing "The official definition
> >     of call-by-value", and "What't the value of an object":
> >        http://groups.google.com/group/comp.lang.python/t/6163956596a8c082/
>
> Nice.  The Python Reference defines objects, the core concept
> of Python, as id, type, and value, and then leaves one clueless
> about what a value is, and several notable Python contributors
> declare the subject boring.
>
> I guess this goes a long way to explaining why the Python docs
> suck so badly in many areas.

No, this goes a long way to explain why you don't need a PhD in
denotational semantics or ontology to use Python effectively. The
current discussion on that thread may be interesting to language
lawyers and philosophers but it's pretty much irrelevant in
understanding how Python works.

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

Re: Python and Its Libraries--Who's on First?

[George Sakkis]

On Nov 17, 12:25 am, "W. eWatson" <[EMAIL PROTECTED]> wrote:
> Is there some repository that says something like for Python 2.5 it works 
> with:
>
> Win OSes: W2K, XP, Vista
> numpy vers y, matplotlib vers x. scipy z, etc.

http://www.catb.org/~esr/faqs/smart-questions.html#writewell
--
http://mail.python.org/mailman/listinfo/python-list

Re: Optional parameter object re-used when instantiating multiple objects

[George Sakkis]

On Nov 16, 2:30 pm, "Chris Rebert" <[EMAIL PROTECTED]> wrote:
> On Sun, Nov 16, 2008 at 11:02 AM, George Sakkis <[EMAIL PROTECTED]> wrote:
> > On Nov 16, 8:28 am, Steve Holden <[EMAIL PROTECTED]> wrote:
>
> >> "Less obvious" is entirely in the mind of the reader.
>
> > Without documentation or peeking into the function body, a None
> > default conveys little or no information, so I don't think it's just
> > in the mind of the reader. Do you find the following less obvious than
> > the current workaround ?
>
> > from datetime import date
> > from timedelta import timedelta
>
> > def make_reservation(customer,
> >                     checkin=`date.today()`,
> >                     checkout=`checkin+timedelta(days=3)`):
> >   ...
>
> >> However I can see
> >> far more justification for the behavior Python currently exhibits than
> >> the semantic time-bomb you are proposing.
>
> > I didn't propose replacing the current behavior (that would cause way
> > too much breakage), only adding a new syntax which is now invalid, so
> > one would have to specify it explicitly.
>
> Minor FYI, but Guido has proscribed backticks ever being used in
> Python again. Seehttp://www.python.org/dev/peps/pep-3099/

I know, just used it for the sake of the example; the actual syntax is
much less of an issue in this case than the functionality.

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

Re: Need help in understanding a python code

[George Sakkis]

On Nov 16, 7:34 am, John Machin <[EMAIL PROTECTED]> wrote:
> On Nov 16, 11:04 pm, Steven D'Aprano <[EMAIL PROTECTED]
>
> >http://en.wikipedia.org/wiki/Style_over_substance_fallacy
>
> Quoted Wikipedia -> instant disqualification -> you lose. Good night.

When quoting wikipedia became the new Godwin's law ?? :)

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

Re: Optional parameter object re-used when instantiating multiple objects

[George Sakkis]

On Nov 16, 8:28 am, Steve Holden <[EMAIL PROTECTED]> wrote:
>
> > +1. Understanding and accepting the current behavior (mainly because
> > of the extra performance penalty of evaluating the default expressions
> > on every call would incur) is one thing, claiming that it is somehow
> > natural is plain silly, as dozens of threads keep showing time and
> > time again. For better or for worse the current semantics will
> > probably stay forever but I wish Python grows at least a syntax to
> > make the expected semantics easier to express, something like:
>
> > def foo(bar=`[]`):
> > bar.append(6)
>
> > where `expr` would mean "evaluate the expression in the function
> > body". Apart from the obvious usage for mutable objects, an added
> > benefit would be to have default arguments that depend on previous
> > arguments:
>
> Would you also retain the context surrounding the function declaration
> so it's obvious how it will be evaluated, or would you limit the default
> values to expressions with no bound variables?

No, all expressions would be allowed, and the semantics would be
identical to evaluating them in the function body; not context would
be necessary.

> > def foo(x, y=`x*x`, z=`x+y`):
> > return x+y+z
>
> > as opposed to the more verbose and less obvious current hack:
>
> > def foo(x, y=None, z=None):
> > if y is None: y = x*x
> > if z is None: z = x+y
> > return x+y+z
>
> "Less obvious" is entirely in the mind of the reader.

Without documentation or peeking into the function body, a None
default conveys little or no information, so I don't think it's just
in the mind of the reader. Do you find the following less obvious than
the current workaround ?

from datetime import date
from timedelta import timedelta

def make_reservation(customer,
 checkin=`date.today()`,
 checkout=`checkin+timedelta(days=3)`):
   ...


> However I can see
> far more justification for the behavior Python currently exhibits than
> the semantic time-bomb you are proposing.

I didn't propose replacing the current behavior (that would cause way
too much breakage), only adding a new syntax which is now invalid, so
one would have to specify it explicitly.

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

Re: Optional parameter object re-used when instantiating multiple objects

[George Sakkis]

On Nov 16, 2:05 am, Arnaud Delobelle <[EMAIL PROTECTED]> wrote:

> Steven D'Aprano <[EMAIL PROTECTED]> writes:
> > On Sat, 15 Nov 2008 01:40:04 -0800, Rick Giuly wrote:
>
> >> Hello All,
>
> >> Why is python designed so that b and c (according to code below)
> >> actually share the same list object? It seems more natural to me that
> >> each object would be created with a new list object in the points
> >> variable.
>
> > That's not natural *at all*. You're initialising the argument "points"
> > with the same list every time. If you wanted it to have a different list
> > each time, you should have said so. Don't blame the language for doing
> > exactly what you told it to do.
>
> Come on.  The fact that this questions comes up so often (twice in 24h)
> is proof that this is a surprising behaviour.  I do think it is the
> correct one but it is very natural to assume that when you write
>
>     def foo(bar=[]):
>          bar.append(6)
>          ...
>
> you are describing what happens when you _call_ foo, i.e.:
>
>     1. if bar is not provided, make it equal to []
>     2. Append 6 to bar
>     3. ...

+1. Understanding and accepting the current behavior (mainly because
of the extra performance penalty of evaluating the default expressions
on every call would incur) is one thing, claiming that it is somehow
natural is plain silly, as dozens of threads keep showing time and
time again. For better or for worse the current semantics will
probably stay forever but I wish Python grows at least a syntax to
make the expected semantics easier to express, something like:

def foo(bar=`[]`):
bar.append(6)

where `expr` would mean "evaluate the expression in the function
body". Apart from the obvious usage for mutable objects, an added
benefit would be to have default arguments that depend on previous
arguments:

def foo(x, y=`x*x`, z=`x+y`):
return x+y+z

as opposed to the more verbose and less obvious current hack:

def foo(x, y=None, z=None):
if y is None: y = x*x
if z is None: z = x+y
return x+y+z

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

Re: object creation

[George Sakkis]

On Nov 14, 5:16 pm, BiraRai <[EMAIL PROTECTED]> wrote:
> for record in roll:
>     x = box()
>     x.createSomething(record)
>     do something 
>
> Can anyone tell me why python keeps return the original object x that
> was created in the FOR loop.  I want to instantiate a new x object for
> each iteration of the FOR loop

What is box()? Pasting its definition would help.

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

Re: duck-type-checking?

[George Sakkis]

On Nov 14, 4:49 pm, Joe Strout <[EMAIL PROTECTED]> wrote:

> So things like this should suffice:
>
>         # simple element
>         assert(is_stringlike(foo))
>         assert(is_numeric(foo))
>         assert(is_like(foo, Duck))
>
>         # sequence of elements
>         assert(seqof_stringlike(foo))
>         assert(seqof_numeric(foo))
>         assert(seqof_like(foo, Duck))
>         # (also "listof_" variants for asserting mutable sequence of whatever)
>
>         # dictionary of elements
>         assert(dictof_like(foo, str, int))
>
> Hmm, I was already forced to change my approach by the time I got to  
> checking dictionaries.  Perhaps a better formalism would be a "like"  
> method that takes an argument, and something that indicates the  
> desired type.  This could be a tree if you want to check deeper into a  
> container.  Maybe something like:
>
>         assert(fits(foo, dictlike(strlike, seqlike(intlike
>
> which asserts that foo is something dictionary-like that maps string-
> like things to something like a sequence of integer-like things.  Most  
> cases would not be this complex, of course, but would be closer to
>
>         assert(fits(foo, strlike))
>
> But this is still pretty ugly.  Hmm.  Maybe I'd better wait for  
> ABCs.  :)

You might also be interested in the typecheck module whose syntax
looks nicer, at least for the common cases: 
http://oakwinter.com/code/typecheck/dev/

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

Re: duck-type-checking?

[George Sakkis]

On Nov 13, 10:55 pm, Steven D'Aprano <[EMAIL PROTECTED]
cybersource.com.au> wrote:

> Take this example:
>
> def foo(alist):
>     alist.sort()
>     alist.append(5)
>
> The argument can be any object with sort and append methods (assumed to
> act in place). But what happens if you pass it an object with a sort
> method but no append? The exception doesn't occur until *after* the
> object is sorted, which leaves it in an inconsistent state. This can be
> undesirable: you might need the function foo to be atomic, either the
> entire function succeeds, or none of it.

In this example atomicity is not guaranteed even if alist is a builtin
list (if it contains a complex number or other unorderable object),
let alone if not isistance(alist, list). It gets worse: false
positives are less likely for full-spelled methods with well-known
names such as "sort" and "append"  (i.e. if hasattr(alist, 'append'),
alist.append *probably* does what you think it does), but good luck
with that when testing for __getitem__, __iter__ for more than one
pass, __call__, and other special methods with ambiguous or undefined
semantics.

Let's face it, duck typing is great for small to medium complexity
projects but it doesn't scale without additional support in the form
of ABCs/interfaces, explicit type checking (at compile and/or run
time), design by contract, etc. It must not be a coincidence that both
Zope and Twisted had to come up with interfaces to manage their
massive (for Python at least) complexity.

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

Re: using "private" parameters as static storage?

[George Sakkis]

On Nov 13, 9:22 pm, Joe Strout <[EMAIL PROTECTED]> wrote:

> Steve wrote:
> > This is a pretty bizarre requirement, IMHO. The normal place to keep
> > such information is either class variables or instance variables.
>
> Holy cow, I thought it was just Chris, but there were half a dozen  
> similar responses after that.
>
> I'm starting to see a pattern here... any time Python lacks a feature,  
> the Python community's party line is "You don't need that feature!"
>
> I understand embracing the language rather than fighting against it,  
> but that can be taken too far -- if somebody expresses a need, and is  
> earnestly asking for input on a real programming problem, I'd think  
> the nice thing would be to explore the programming problem with them,  
> rather than arguing with them that they don't need what they claim  
> they need.

The burden of proof is on you to show that none of the several ways to
solve your problem in Python is good enough. So far your argument is
"I really miss that I can't do it exactly like in my pet-language".

> Hypothetically speaking, is it possible that there could be any  
> language feature Python doesn't have, which might be useful to anyone  
> in any situation?

Sure; true multithreading, macros, non-crippled lambda, optional
static typing are some reasonable features people miss in Python. The
topic of this thread just isn't one of them.

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

Re: duck-type-checking?

[George Sakkis]

On Nov 13, 10:15 am, Joe Strout <[EMAIL PROTECTED]> wrote:
> On Nov 12, 2008, at 7:32 PM, Steven D'Aprano wrote:
>
> > While the recipe is great, it can be tiresome to apply all the time. I
> > would factor out the checks into a function, something like this:
>
> > def isstringlike(obj, methods=None):
> >    """Return True if obj is sufficiently string-like."""
> >    if isinstance(obj, basestring):
> >        return True
> >    if methods is None:
> >        methods = ['upper', 'lower', '__len__', '__getitem__']
> >    for method in methods:
> >        if not hasattr(obj, method):
> >            return False
> >    # To really be string-like, the following test should pass.
> >    if len(obj) > 0:
> >        s = obj[0]
> >        if s[0] != s:
> >            return False
> >    return True
>
> Thanks for this, too; that's the sort of method I had in mind.  That  
> last test for string-likeness is particularly clever.  I'll need to  
> think more deeply about the implications.

To me this seems it combines the worst of both worlds: the
explicitness of LBYL with the heuristic nature of duck typing.. might
as well call it "doyoufeellucky typing". If you are going to Look
Before You Leap, try to stick to isinstance/issubclass checks
(especially in 2.6+ that they can be overriden) instead of crafting ad-
hoc rules of what makes an object be X-like.

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

Re: Official definition of call-by-value (Re: Finding the instance reference...)

[George Sakkis]

On Nov 12, 4:05 pm, Fredrik Lundh <[EMAIL PROTECTED]> wrote:

> greg wrote:
> >> It's not only misleading, it's also a seriously flawed reading of the
> >> original text - the Algol 60 report explicitly talks about assignment
> >> of *values*.
>
> > Do you agree that an expression in Python has a value?
>
> > Do you agree that it makes sense to talk about assigning
> > that value to something?
>
> Python's definition of the word "value" can be found in the language
> reference:
>
> http://docs.python.org/reference/datamodel.html#objects-values-and-types

Quoting the relevant part:

"The value of some objects can change. Objects whose value can change
are said to be mutable; objects whose value is unchangeable once they
are created are called immutable."

Strictly speaking that's not a definition; it doesn't say what a value
is, only how it relates to objects. But regardless, according to this,
a Python value is what the rest of the world usually calls "state",
while a value in a non-Python context is usually a synonym of
"object" (in the general sense, e.g. for Java including both
primitives and object references), i.e. there's the following
approximate mapping in terminology:

Python jargon  Non-python jargon
===
object value (primitive or composite)
value  state (set of an object's attribute bindings)

Thus both call-by-value and call-by-object can be correct
descriptions, depending on who you ask.

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

Re: duck-type-checking?

[George Sakkis]

On Nov 12, 1:35 pm, Terry Reedy <[EMAIL PROTECTED]> wrote:
> Cristina Yenyxe González García wrote:
>
> > 2008/11/12 Joe Strout <[EMAIL PROTECTED]>:
> >> So I need functions to assert that a given identifier quacks like a string,
> >> or a number, or a sequence, or a mutable sequence, or a certain class, or 
> >> so
> >> on.  (On the class check: I know about isinstance, but that's contrary to
> >> duck-typing -- what I would want that check to do instead is verify that
> >> whatever object I have, it has the same public (non-underscore) methods as
> >> the class I'm claiming.)
>
> >> Are there any standard methods or idioms for doing that?
>
> > You can use hasattr(object, name), with 'name' as the name of the
> > public method to check. It returns True if the object responds to that
> > method, False otherwise.
>
> Too hard. For methods, which are what define duck species, and any
> attribute guaranteed to not be null, "assert ob.name" is equivalent to
> "assert hasattr(ob, 'name')".

As you just showed they're not; one raises AttributeError and the
other AssertionError. Not that it matters much but these are typically
reported differently by testing frameworks.

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