Re: The future of Python immutability
Steven D'Aprano wrote: On Fri, 04 Sep 2009 06:36:59 -0700, Adam Skutt wrote: Nope, preventing mutation of the objects themselves is not enough. You also have to forbid variables from being rebound (pointed at another object). Right. What's needed for safe concurrency without global locking looks something like this: Object categories: Immutable Mutable Synchronized Unsynchronized Owned by a thread. Owned by synchronized object "Synchronized" objects would be created with something like class foo(synchronized) : pass Only one thread can be active within a synchronized object, as in Java. So there's implicit locking at entry, unlocking at exit, and temporary unlocking when the thread is blocked on a lock. External access to non-function members of synchronized objects has to be prohibited, since that would allow race conditions. Everything else can be handled implicitly, without declarations or annotation. Here's the big problem: class foo(synchronized) : def __init__(self) : self.items = [] def putitem(self,item) : self.items.append(item) # adds item to object's list def getitem(self,item) : return(self.items.pop())# removes item def test() words = ["hello","there"] # a mutable object sobj = foo() # a synchronized object sobj.putitem(words)# add to object words[0] = "goodbye" # ERROR - no longer can access The concept here is that objects have an "owner", which is either a thread or some synchronized object. Locking is at the "owner" level. This is simple until "ownership" needs to be transferred. Can this be made to work in a Pythonic way, without explicit syntax? What we want to happen, somehow, is to transfer the ownership of "words" from the calling thread to the object in "putitem", and transfer it to the calling thread in "getitem". How can this be done? If ownership by a synchronized object has "priority" over ownership by a thread, it works. When "putitem" above does the "append", the instance of "foo" becomes the owner of "item". In general, when a reference to an object is created, and the reference is from an object owned by a synchronized object, the object being referenced has to undergo an ownership change. Once "putitem" has returned, after the ownership change, it is an error (a "sharing violation?") for the calling thread to access the object. That seems weird, but the alternative is some explicit way of swapping ownership. What's wrong with this? It takes two reference counts and a pointer for each mutable object, which is a memory cost. Worse, when a collection of unsynchronized mutable objects is passed in this manner, all the elements in the collection have to undergo an ownership change. That's expensive. (If you're passing trees around, it's better if the tree root is synchronized. Then the tree root owns the tree, and the tree can be passed around or even shared, with locking controlled by the root.) A compiler smart enough to notice when a variable goes "dead" can optimize out some of the checking. None of this affects single-thread programs at all. This is purely needed for safe, efficient concurrency. It's kind of a pain, but if servers are going to have tens or hundreds of CPUs in future, we're going to have to get serious about concurrency. John Nagle -- http://mail.python.org/mailman/listinfo/python-list
Re: Q on explicitly calling file.close
On Sat, Sep 5, 2009 at 6:51 PM, kj wrote: > In <02b2e6ca$0$17565$c3e8...@news.astraweb.com> Steven D'Aprano < > st...@remove-this-cybersource.com.au> writes: > > >(3) For quick and dirty scripts, or programs that only use one or two > >files, relying on the VM to close the file is sufficient (although lazy > >in my opinion *wink*) > > It's not a matter of laziness or industriousness, but rather of > code readability. The real problem here is not the close() per > se, but rather all the additional machinery required to ensure that > the close happens. When the code is working with multiple file > handles simultaneously, one ends up with a thicket of try/finally's > that makes the code just *nasty* to look at. E.g., even with only > two files, namely an input and an output file, compare: > This is precisely why the with statement exists; to provide a cleaner way to wrap a block in setup and teardown functions. Closing is one. Yeah, you get some extra indentation-- but you sorta have to live with it if you're worried about correct code. I think it's a good compromise between your examples of nasty and nice :) def compromise(from_, to_): with file(to_) as to_h: with file(from_) as from_h: for line in from_h: print >> to_h, munge(line) It's just too bad that 'with' doesn't support multiple separate "x as y" clauses. As for why you didn't see much of that style code in the wild-- that's because the with statement is just pretty new. 2.5 had it with a future statement, and although there's lots of code out there that /supports/ Python 2.5, there's not /that/ much which /requires/ it of yet. As time goes on and people stop wanting to support earlier versions of Python in various libraries, you'll see more of it in publicly available code. I'm personally rewriting a huge chunk of code in the office to convert everything from try/finally to with statements as we move our codebase to 2.5 finally, and am quite gleeful. It's a lot cleaner and clearer. --S -- http://mail.python.org/mailman/listinfo/python-list
Re: Problems with hex-conversion functions
On Fri, 04 Sep 2009 15:28:10 -0700, Arnon Yaari wrote:
> Hello everyone.
> Perhaps I'm missing something, but I see several problems with the two
> hex-conversion function pairs that Python offers: 1. binascii.hexlify
> and binascii.unhexlify 2. bytes.fromhex and bytes.hex
>
> Problem #1:
> bytes.hex is not implemented, although it was specified in PEP 358. This
> means there is no symmetrical function to accompany bytes.fromhex.
That would probably be an oversight. Patches are welcome.
> Problem #2:
> Both pairs perform the same function, although The Zen Of Python
> suggests that
> "There should be one-- and preferably only one --obvious way to do it."
That is not a prohibition against multiple ways of doing something. It is
a recommendation that there should be one obvious way (as opposed to no
way at all, or thirty five non-obvious ways) to do things. Preferably
only one obvious way, but it's not a prohibition against there being an
obvious way and a non-obvious way.
> I do not understand why PEP 358 specified the bytes function pair
> although it mentioned the binascii pair...
Because there are three obvious ways of constructing a sequence of bytes:
(1) from a sequence of characters, with an optional encoding;
(2) from a sequence of pairs of hex digits, such as from a hex dump of a
file;
(3) from a sequence of integers.
(1) and (2) are difficult to distinguish -- should "ab45" be interpreted
as four characters, "a" "b" "4" and "5", or as two pairs of hex digits
"ab" and "45"? The obvious solution is to have two different bytes
constructors.
> Problem #3:
> bytes.fromhex may receive spaces in the input string, although
> binascii.unhexlify may not.
> I see no good reason for these two functions to have different features.
There's clearly differences of opinion about how strict to be when
accepting input strings. Personally, I can see arguments for both. Given
that these are two different functions, there's no requirement that they
do exactly the same thing, so I wouldn't even call it a wart. It's just a
difference.
> Problem #4:
> binascii.unhexlify may receive both input types: strings or bytes,
> whereas bytes.fromhex raises an exception when given a bytes parameter.
> Again there is no reason for these functions to be different.
There's no reason for them to be the same. unhexlify() is designed to
take either strings or bytes, mostly for historical reasons: in Python
1.x and 2.x, it is normal to use byte-strings (called 'strings') as the
standard string type, and character-strings ('unicode') is relatively
rare, so unhexlify needs to accept bytes. In Python 3.x, the use of bytes
as character strings is discouraged, hence passing hex digits as bytes to
bytes.fromhex() is illegal.
> Problem #5:
> binascii.hexlify returns a bytes type - although ideally, converting to
> hex should always return string types and converting from hex should
> always return bytes.
This is due to historical reasons -- binascii comes from Python 1.x when
bytes were the normal string type. Presumably modifying binascii to
return strings in Python 3.x (but not 2.6 or 2.7) would probably be a
good idea. Patches are welcome.
[...]
> To fix these issues, three changes should be applied: 1. Deprecate
> bytes.fromhex.
-1 on that. I disagree strongly: bytes are built-ins, and constructing
bytes from a sequence of hex digits is such a natural and important
function that needing to import a module to do it is silly and wasteful.
[...]
> 2. In order to keep the functionality that bytes.fromhex has over
> unhexlify,
>the latter function should be able to handle spaces in its input
> (fix #3)
0 on that. I don't care either way.
> 3. binascii.hexlify should return string as its return type (fix #5)
+1 for the Python 3.x series, -1 for Python 2.6 and 2.7.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
midi file toolkit
## python 2.6.2
from tkFileDialog import askopenfilename, askdirectory
def nowindow(function):
def windowless():
from Tkinter import Tk
Tk().withdraw()
return function()
return windowless
getfilename = nowindow(askopenfilename)
getdirectoryname = nowindow(askdirectory)
def haskellize(pathname):
return '\\'.join(pathname.split('/'))
def newname():
from time import time
return 'NAME_' + ''.join(str(time()).split('.'))
def mangle(name):
return '__' + name + '__'
def pathsafe(name):
return '_'.join(name.split('/'))
def changefilename(filename,directoryname=None,rewrite=lambda
name:name):
from os.path import split, splitext, join
dirname, filename = split(filename)
filename, extension = splitext(filename)
filename = rewrite(filename)
directoryname = directoryname or dirname
return join(directoryname,filename) + extension
def readbytes(filename):
return [ord(x) for x in file(filename,'rb').read()]
def writebytes(numbers,filename):
file(filename,'wb').write(''.join([chr(x) for x in numbers]))
def playbytes(numbers):
from os import startfile
filename = newname() + '.mid'
writebytes(numbers,filename)
startfile(filename)
def IfThenElse(criterion,optionTrue,optionFalse):
if bool(criterion)==True: return optionTrue
if bool(criterion)==False: return optionFalse
def flatten(homogeneouslist):
from itertools import chain
while type(homogeneouslist[0])==list: homogeneouslist = list(chain
(*homogeneouslist))
return homogeneouslist
def number2digits(number,base):
digits = [number]
while digits[0]>=base: digits[0:1] = [digits[0]//base, digits
[0]%base]
return digits
def digits2number(digits,base):
reversedigits = list(reversed(digits))
return sum([reversedigits[i]*(base**i) for i in range(len
(digits))])
def number2fixedlength(number,numbytes):
digits = number2digits(number,2**8)
numleadingzeros = IfThenElse(len(digits)=(2**7): index = index + 1
endindex = index + 1
return numbers[startindex:endindex], endindex
headeridentifier = [ord(x) for x in 'MThd']
trackidentifier= [ord(x) for x in 'MTrk']
eventtypes = range(2**3)
noteoff= eventtypes[0] ## notenumber,
velocity = parameters
noteon = eventtypes[1] ## notenumber,
velocity = parameters
noteaftertouch = eventtypes[2] ## notenumber,
aftertouchvalue= parameters
controller = eventtypes[3] ## controllernumber,
controllervalue = parameters
programchange = eventtypes[4] ##
programnumber = parameters[0]
channelaftertouch = eventtypes[5] ##
aftertouchvalue= parameters[0]
pitchbend = eventtypes[6] ## pitchvalueLSB,
pitchvalueMSB = parameters
nonmidicontrol = eventtypes[7]
channels = range(2**4)
systemexclusive = channels[0]
meta = channels[15]
def chunk(identifier,flatdata):
return identifier + number2fixedlength(len(flatdata),4) + flatdata
def analyzeheaderdata(data):
formattype = data[0:2]
numtracks= data[2:4]
timedivision = data[4:6]
return [digits2number(x,2**8) for x in [formattype, numtracks,
timedivision]]
def synthesizeheaderdata(formattype,numtracks,timedivision):
datasegments = [number2fixedlength(x,2) for x in [formattype,
numtracks, timedivision]]
return datasegments[0] + datasegments[1] + datasegments[2]
def headerchunk(formattype,numtracks,timedivision):
return chunk(headeridentifier, synthesizeheaderdata(formattype,
numtracks, timedivision))
def trackchunk(events):
return chunk(trackidentifier,flatten(events))
def analyzestatus(status):
number = status[0]
eventtype = (number - 2**7) // (2**4)
channel = number % (2**4)
return eventtype, channel
def synthesizestatus(eventtype,channel):
number = (2**7) + eventtype*(2**4) + channel
return [number]
def midicontrolevent(deltatime,eventtype,channel,*parameters):
deltatime = number2variablelength(deltatime)
status = synthesizestatus(eventtype, channel)
return [deltatime, status, list(parameters)]
def nonmidicontrolevent(deltatime,messagedata,metatype=[]):
deltatime = number2variablelength(deltatime)
eventtype = nonmidicontrol
channel = IfThenElse(metatype, meta, systemexclusive)
status = synthesizestatus(eventtype, channel)
datalength = number2variablelength(len(messagedata))
return [deltatime, status, (metatype + datalength + messagedata)]
def getchunk(numbers,startindex):
identifier, startindex = getfixedlength(numbers,startindex,4)
chunksize, startindex = getfixedlength(numbers,startindex,4)
chunkdata, startindex = getfixedlength
(numbers,startindex,fixedlength2number(chunksize))
return [identifier, chunksize, chunkdata], startindex
def file2chunks(numbers):
strictupperbound = len(numbers)
startindex = 0
chunks = []
while star
Re: Q on explicitly calling file.close
On Sun, 06 Sep 2009 01:51:50 +, kj wrote: > In <02b2e6ca$0$17565$c3e8...@news.astraweb.com> Steven D'Aprano > writes: > >>(3) For quick and dirty scripts, or programs that only use one or two >>files, relying on the VM to close the file is sufficient (although lazy >>in my opinion *wink*) > > It's not a matter of laziness or industriousness, but rather of code > readability. The real problem here is not the close() per se, but > rather all the additional machinery required to ensure that the close > happens. When the code is working with multiple file handles > simultaneously, one ends up with a thicket of try/finally's that makes > the code just *nasty* to look at. Yep, that's because dealing with the myriad of things that *might* (but probably won't) go wrong when dealing with files is *horrible*. Real world code is almost always much nastier than the nice elegant algorithms we hope for. Most people know they have to deal with errors when opening files. The best programmers deal with errors when writing to files. But only a few of the most pedantic coders even attempt to deal with errors when *closing* the file. Yes, closing the file can fail. What are you going to do about it? At the least, you should notify the user, then continue. Dying with an uncaught exception in the middle of processing millions of records is Not Cool. But close failures are so rare that we just hope we'll never experience one. It really boils down to this... do you want to write correct code, or elegant code? -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: subprocess + python-daemon - bug/problem?
I got the same bug. Traceback (most recent call last): File "./script1.py", line 30, in call(["python", "script2.py", "arg1"], stdout=sys.stdout, stderr=STDOUT) File "/usr/lib/python2.6/subprocess.py", line 444, in call return Popen(*popenargs, **kwargs).wait() File "/usr/lib/python2.6/subprocess.py", line 1123, in wait pid, sts = os.waitpid(self.pid, 0) OSError: [Errno 10] No child processes -- http://mail.python.org/mailman/listinfo/python-list
Re: subprocess + python-daemon - bug/problem?
I got the same bug. Traceback (most recent call last): File "./script1.py", line 30, in call(["python", "script2.py", "arg1"], stdout=sys.stdout, stderr=STDOUT) File "/usr/lib/python2.6/subprocess.py", line 444, in call return Popen(*popenargs, **kwargs).wait() File "/usr/lib/python2.6/subprocess.py", line 1123, in wait pid, sts = os.waitpid(self.pid, 0) OSError: [Errno 10] No child processes -- http://mail.python.org/mailman/listinfo/python-list
Re: Pythonwin.exe Error?!?
On Sep 5, 2:37 pm, kennyken747 wrote: > HELP! So apparently after installing EPD 5.0 (a python 2.5 dist) aside > my main Python installation (2.6) I started getting this error. > > -Pure virtual function call > > Whenever I open up ActiveState Python, it gets this runtime error > under pythonwin.exe > > Already uninstalled EPD but am still getting this error. I've done > everything from re-install Python and ActiveState to deleting > everything in the registry to do with Python!!! I suggest that nobody > install that until they sort their problems out. > > But for now, any help is appreciated. Please. -- http://mail.python.org/mailman/listinfo/python-list
Re: Support for Windows 7 ?
On 2009-09-05, Pascale Mourier wrote:
> Well, os.listdir('C:') instead of raising an exception, for
> some reason behaves like os.listdir('.').
Windows (and DOS) have worked like that for decades. A lone
drive letter always refers to the "current directory" on that
drive. It's been that way since the very first versions of
PC-DOS and MS-DOS.
--
Grant
--
http://mail.python.org/mailman/listinfo/python-list
Re: The future of Python immutability
Adam Skutt wrote: On Sep 5, 11:29 am, Terry Reedy wrote: This is a pointless replacement for 'def b(x): return x+a' And? That has nothing to do with anything I was saying whatsoever. Agreed. However, posts are read by newbies. Posts that promote bad habits are fair game for comment. Python does not have lambda objects. It has lambda expressions that produce function objects identical except for .__name__ to the equivalent def statement output. Sure sounds like python has lambda objects to me then... The idea that Python has 'lambda objects' had caused no end of mischief over the years. tjr -- http://mail.python.org/mailman/listinfo/python-list
Re: How to refer to data files without hardcoding paths?
Ben Finney wrote: Matthew Wilson writes: Today I realized that I'm hardcoding paths in my app. They are relative paths based on os.getcwd(), but at some point, I'll be running scripts that use this code, these open(...) calls will fail. The conventional solution to this is: * Read configuration settings, whether directory paths or anything else, from a configuration file of declarative options. * Have the program read that configuration file from one location (or a small number of locations), and make those locations well-known in the documentation of the program. Python's standard library has the ‘configparser’ module, which is one possible implementation of this. Before you can decide what libraries to use, you need to determine your goal. Usually, you can separate the data files your application uses into two groups. One is the read-only files. Those ship with the application, and won't be edited after installation, or if they are, they would be deliberate changes by the administrator of the machine, not the individual user. Those should be located with the shipped .py and .pyc files. The other group (which might in turn be subdivided) is files that are either created by the application for configuration purposes (config files), or for the user (documents), or temp files (temp). The first files can/should be found by looking up the full path to a module at run time. Use the module's __file__ to get the full path, and os.path.dirname() to parse it. The second group of files can be located by various methods, such as using the HOMEPATH environment variable. But if there is more than one such location, one should generally create a config file first, and have it store the locations of the other files, after consulting with the end-user. Once you've thought about your goals, you should then look at supporting libraries to help with it. configparser is one such library, though both its name and specs have changed over the years. DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: Q on explicitly calling file.close
In <02b2e6ca$0$17565$c3e8...@news.astraweb.com> Steven D'Aprano writes: >(3) For quick and dirty scripts, or programs that only use one or two >files, relying on the VM to close the file is sufficient (although lazy >in my opinion *wink*) It's not a matter of laziness or industriousness, but rather of code readability. The real problem here is not the close() per se, but rather all the additional machinery required to ensure that the close happens. When the code is working with multiple file handles simultaneously, one ends up with a thicket of try/finally's that makes the code just *nasty* to look at. E.g., even with only two files, namely an input and an output file, compare: def nice(from_, to_): to_h = file(to_, "w") for line in file(from_): print >> to_h, munge(line) def nasty(from_, to_): to_h = file(to_, "w") try: from_h = file(from_) try: for line in from_h: print >> to_h, munge(line) finally: from_h.close() finally: to_h.close() I leave to your imagination the joys of reading the code for hairy(from_, to_, log_), where log_ is a third file to collect warning messages. kynn -- http://mail.python.org/mailman/listinfo/python-list
Re: How to refer to data files without hardcoding paths?
Matthew Wilson writes: > Today I realized that I'm hardcoding paths in my app. They are > relative paths based on os.getcwd(), but at some point, I'll be > running scripts that use this code, these open(...) calls will fail. The conventional solution to this is: * Read configuration settings, whether directory paths or anything else, from a configuration file of declarative options. * Have the program read that configuration file from one location (or a small number of locations), and make those locations well-known in the documentation of the program. Python's standard library has the ‘configparser’ module, which is one possible implementation of this. -- \ “I used to be an airline pilot. I got fired because I kept | `\ locking the keys in the plane. They caught me on an 80 foot | _o__)stepladder with a coathanger.” —Steven Wright | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Multiple inheritance - How to call method_x in InheritedBaseB from method_x in InheritedBaseA?
On Sep 4, 3:01 am, The Music Guy wrote: > I have a peculiar problem that involves multiple inheritance and method > calling. > > I have a bunch of classes, one of which is called MyMixin and doesn't > inherit from anything. MyMixin expects that it will be inherited along > with one of several other classes that each define certain > functionality. It defines method_x, which it assumes will also be > defined in the other class that MyMixin ends up getting inherited > with. For example, > > class MyMixin(object): > def method_x(self, a, b, c): > ... > > class BaseA(object): > def method_x(self, a, b, c): > ... > > class BaseB(object): > def method_x(self, a, b, c): > ... > > class BaseC(object): > def method_x(self, a, b, c): > ... > > class FooX(MyMixin, BaseA): > ... > > class FooY(MyMxin, BaseB): > ... > > class FooZ(MyMixin, BaseC): > ... > > This all appears fine at first, but there is a problem: Each Foo's > method_x must call the method_x of MyMixin as well as the method_x of > each respective Foo's second base class. One cannot simply call > FooN.method_x, because that will only call MyMixin.method_x and not > that of the other base. > > One might be tempted to amend MyMixin's method_x so that it calls the > parent's method_x before doing anything else: > > class MyMixin(object): > def method_x(self, a, b, c): > super(MyMixin, self).method_x(a, b, c) > ... > > ...but of course, that will fail with an AttributeError because > MyMixin's only superclass is object, which does not have a method_x. Out of curiosity, did you try this and are reporting that it resulted in an AttributeError, or did you merely deduce that it would raise AttributeError based on your knowledge of Python's inheritance? I ask this rhetorically. I know that you didn't try it (or that you tried it and made a mistake) because if you had tried it (and not made a mistake) you would have seen that it works exactly as you want it to. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
How to refer to data files without hardcoding paths?
When a python package includes data files like templates or images, what is the orthodox way of referring to these in code? I'm working on an application installable through the Python package index. Most of the app is just python code, but I use a few jinja2 templates. Today I realized that I'm hardcoding paths in my app. They are relative paths based on os.getcwd(), but at some point, I'll be running scripts that use this code, these open(...) calls will fail. I found several posts that talk about using __file__ and then walking to nearby directories. I also came across pkg_resources, and that seems to work, but I don't think I understand it all yet. Matt -- http://mail.python.org/mailman/listinfo/python-list
[ANN] pyKook 0.0.4 - a smart build tool similar to Make, Rake, or Ant
Hi,
I have released pyKook 0.0.4.
http://pypi.python.org/pypi/Kook/0.0.4
http://www.kuwata-lab.com/kook/
http://www.kuwata-lab.com/kook/pykook-users-guide.html
In this release, recipe syntax is changed (see below).
Overview
pyKook is a smart build tool similar to Make, Rake, Ant, or Cook.
pyKook regards software project as cooking.
Terms used in pyKook are cooking terms.
For example:
cookbook- Makefile
product - target file
ingredient - source file
recipe - how to create target from source
spices - command-line options for recipe
Cookbook (= Makefile) is written in pure Python.
You can write any statements or expressions in cookbook.
NOTICE: pyKook is under alpha release. Spec and features may be
changed
in the future without previous announcement.
Example
===
Example of cookbook (Kookbook.py):
--
##
## properties
##
cc = prop('cc', 'gcc')
cflags = prop('cflags', '-g -Wall')
##
## recipes
##
@recipe
@ingreds("hello")
def all(c):# or task_all(c)
pass
@recipe
@product("hello")
@ingreds("hello.o")
def file_command(c):
"""generates hello command"""
system(c%"$(cc) $(cflags) -o $(product) $(ingred)")
@recipe
@product("*.o")
@ingreds("$(1).c", if_exists("$(1).h"))
def file_ext_o(c):
"""compile '*.c' and '*.h'"""
system(c%"$(cc) $(cflags) -c $(1).c")
@recipe
def clean(c):
rm_f("*.o")
--
Exampe of result:
--
bash> ls
Kookbook.py hello.chello.h
bash> pykook -l
Properties:
cc : 'gcc'
cflags : '-g -Wall'
Task recipes:
all : cook all products
clean : remove by-products
File recipes:
hello : generates hello command
*.o : compile '*.c' and '*.h'
(Tips: you can set 'kook_default_product' variable in your
kookbook.)
bash> pykook all # or, pykook --cc=gcc4 all
### *** hello.o (func=file_ext_o)
$ gcc -g -Wall -c hello.c
### ** hello (func=file_command)
$ gcc -g -Wall -o hello hello.o
### * all (func=task_all)
--
See users-guide for more details.
http://www.kuwata-lab.com/kook/pykook-users-guide.html
Enhancements sice 0.0.3
===
- Compact style of @recipe decorator supported.
ex::
## normal style
@recipe
@product('*.o')
@ingreds('$(1).c', '$(1).h')
def file_o(c):
system(c%"gcc -c $(ingre)")
## compact style
@recipe('*.o', ['$(1).c', '$(1).h'])
def file_o(c):
system(c%"gcc -c $(ingre)")
- 'kk' script supports '$KK_CLIMB' environment variable.
If you set it, 'kk' script searches parent directories
when 'Kookbook.py' is not found.
ex::
sh> ls -F
Kookbook.pysrc/test/
sh> cd src/foo/bar/
sh> kk clean# ERROR
kk: No kookbook found.
sh> export KK_CLIMB=1
sh> kk clean# OK
### * clean (recipe=clean)
$ rm **/*.pyc
- New command-line option '-R' (recursively) supported.
If you specify '-R', pykook command searches Kookbook.py
in parent directory recursively.
ex::
sh> ls -F
Kookbook.pysrc/test/
sh> cd src/foo/bar/
sh> pykook clean# ERROR
pykook: Kookbook.py: not found.
sh> pykook -R clean # OK
### * clean (recipe=clean)
$ rm **/*.pyc
Have fun!
--
regards,
makoto kuwata
--
http://mail.python.org/mailman/listinfo/python-list
python smtp gmail authentication error (sending email through gmail smtp server)
Hi all,
I have the following code
import smtplib
from email.mime.text import MIMEText
smtpserver = 'smtp.gmail.com'
AUTHREQUIRED = 1 # if you need to use SMTP AUTH set to 1
smtpuser = 'ad...@myhost.com' # for SMTP AUTH, set SMTP username
here
smtppass = '123456' # for SMTP AUTH, set SMTP password here
RECIPIENTS = ['onli...@gmail.com']
SENDER = 'ad...@myhost.com'
msg = MIMEText('dsdsdsdsds\n')
msg['Subject'] = 'The contents of iii'
msg['From'] = 'ad...@myhost.com'
msg['To'] = ''onli...@gmail.com''
mailServer = smtplib.SMTP('smtp.gmail.com',587)
mailServer.ehlo()
mailServer.starttls()
mailServer.ehlo()
mailServer.login(smtpuser, smtppass)
mailServer.sendmail(smtpuser,RECIPIENTS,msg.as_string())
mailServer.close()
this code works fine on my desktop. but it failed with this error
smtplib.SMTPAuthenticationError: (535, '5.7.1 Username and
Password not accepted. Learn more at\n5.7.1
http://mail.google.com/support/bin/answer.py?answer=14257
21sm4713429agd.11')
on my linux server.
Not sure what went wrong, should i open some port/ install some
services on my linux server?
--
http://mail.python.org/mailman/listinfo/python-list
Re: efficiently splitting up strings based on substrings
On Sun, 06 Sep 2009 00:29:14 +0100, per wrote: it's exactly the same problem, except there are no constraints on the strings. so the problem is, like you say, matching the substrings against the string x. in other words, finding out where x "aligns" to the ordered substrings abc, and then determine what chunk of x belongs to a, what chunk belongs to b, and what chunk belongs to c. so in the example i gave above, the substrings are: a = 1030405, b = 1babcf, c = fUUIUP, so abc = 10304051babcffUUIUP given a substring like 4051ba, i'd want to split it into the chunks a, b, and c. in this case, i'd want the result to be: ["405", "1ba"] -- i.e. "405" is the chunk of x that belongs to a, and "1ba" the chunk that belongs to be. in this case, there are no chunks of c. if x instead were "4051babcffUU", the right output is: ["405", "1babcf", "fUU"], which are the corresponding chunks of a, b, and c that make up x respectively. i'm not sure how to approach this. any ideas/tips would be greatly appreciated. thanks again. I see, I think. Let me explain it back to you, just to be sure. You have a string x, and three component strings a, b and c. x is a substring of the concatenation of a, b and c (i.e. a+b+c). You want to find out how x overlaps a, b and c. Assuming I've understood this right, you're overthinking the problem. All you need to do is find the start of x in a+b+c, then do some calculations based on the string lengths and slice appropriately. I'd scribble some example code, but it's nearly 1am and I'd be sure to commit fence-post errors at this time of night. -- Rhodri James *-* Wildebeest Herder to the Masses -- http://mail.python.org/mailman/listinfo/python-list
Re: Multiple inheritance - How to call method_x in InheritedBaseB from method_x in InheritedBaseA?
On Sep 4, 6:01 am, The Music Guy wrote: > I have a peculiar problem that involves multiple inheritance and method > calling. > > I have a bunch of classes, one of which is called MyMixin and doesn't > inherit from anything. MyMixin expects that it will be inherited along > with one of several other classes that each define certain > functionality. It defines method_x, which it assumes will also be > defined in the other class that MyMixin ends up getting inherited > with. For example, > > class MyMixin(object): > def method_x(self, a, b, c): > ... > > class BaseA(object): > def method_x(self, a, b, c): > ... > > class BaseB(object): > def method_x(self, a, b, c): > ... > > class BaseC(object): > def method_x(self, a, b, c): > ... > > class FooX(MyMixin, BaseA): > ... > > class FooY(MyMxin, BaseB): > ... > > class FooZ(MyMixin, BaseC): > ... > > This all appears fine at first, but there is a problem: Each Foo's > method_x must call the method_x of MyMixin as well as the method_x of > each respective Foo's second base class. One cannot simply call > FooN.method_x, because that will only call MyMixin.method_x and not > that of the other base. > > One might be tempted to amend MyMixin's method_x so that it calls the > parent's method_x before doing anything else: > > class MyMixin(object): > def method_x(self, a, b, c): > super(MyMixin, self).method_x(a, b, c) > ... > > ...but of course, that will fail with an AttributeError because > MyMixin's only superclass is object, which does not have a method_x. > > The only way I can think to solve the problem would be to implement a > method_x for each Foo that calls the method_x for each of the bases: > > class FooX(MyMixin, BaseA): > def method_x(self, a, b, c): > MyMixin.method_x(self, a, b, c) > BaseA.method_x(self, a, b, c) > > class FooY(MyMxin, BaseB): > def method_x(self, a, b, c): > MyMixin.method_x(self, a, b, c) > BaseB.method_x(self, a, b, c) > > class FooZ(MyMixin, BaseC): > def method_x(self, a, b, c): > MyMixin.method_x(self, a, b, c) > BaseC.method_x(self, a, b, c) > > The problem with this solution is that method_x has to be explicitly > created for each Foo, even though they all do just about the same > thing, which kind of defeats the purpose of using multiple inheritance > in this situation. Besides that, I just don't like it! > > So, does anyone have an idea about how to remedy this, or at least > work around it? Hopefully I've interpreted your requirement correctly. In this particular case a workaround is to use super() in your base classes and then have your concrete classes inherit from the base *before* the mixin: class MyMixin(object): def method_x(self, a, b, c): print "MyMixin" class BaseA(object): def method_x(self, a, b, c): print "BaseA" super(BaseA, self).method_x(a, b, c) class FooX(BaseA, MyMixin): pass FooX().method_x(1, 2, 3) BaseA MyMixin And if you want to define method_x() in FooX, then simply have that use super() as well. -- http://mail.python.org/mailman/listinfo/python-list
Re: The future of Python immutability
On Sat, 05 Sep 2009 04:57:21 -0700, Adam Skutt wrote: >> > so the fact "Foo" and "Bar" are immutable isn't enough to solve the >> > problem. >> >> This is a side-effect of writing code that relies on global variables. >> Global variables are generally a bad idea. Global constants are fine. > > Nope, the variables don't have to be global to have this problem, they > just have to be shared: Yes, you're right, my bad. Globals are shared, but not all shared variables are global. >> What do you mean by "variables"? Do you mean names? > > In the case of python I mean the name and the value, since all variables > in Python are pointers. Let me see if I understand you... You say that by "variable" you mean the name and the value. Then you say that all variables are pointers. In other words... "all names and values in Python are pointers". Either you're not explaining yourself correctly, or you're badly confused about Python. In Python, names are keys in namespaces, and values are objects. Possibly some Python implementations use pointers in some way to implement namespaces, or objects, but Python the language doesn't have pointers, and the Python virtual machine that executes Python byte code doesn't have pointers either. > (Worrying about the difference though, is semantics) Semantics are important. If we can't agree on what things mean, how can we possibly communicate? >> What are pointer semantics? > > Assignment to the variable causes it to point to another object (as > opposed to assigning a new value to the current object, like a C++ > reference) and copying the variable does not create a copy of the > referred object (which necessarily implies their lifecycles are > independent). I can *guess* what you mean by all that, but it's just a guess. You say "assignment to the variable", but earlier you said that to you, variables are names and values, so I'm left wondering if you mean assignment to the name, assignment to the value, or both. Likewise for copying the variable. Here is my guess... you're pointing out the similarities between Python name binding and C pointers: * when you bind a name to a new object, you cause the name be associated with the new object rather than mutating the existing object to become equal to the new object; * assigning two names to a single object causes both names to be associated with the same object, rather than each name being associated with independent copies of the object; while ignoring the differences between Python name binding and C pointers: * Python names are keys, not numeric addresses, hence you can't perform anything like pointer arithmetic on them; * objects in Python have no idea what, if any, names are associated with them, unlike C pointers, where you can always ask for the address of a variable. Okay, I accept that if you focus only on the similarities and completely ignore the differences, Python name binding is just like pointer semantics. >> Assuming you mean names must be forbidden from being rebound, no, >> incorrect. It's only names which are shared between both threads which >> must not be re-bound. If you have names local to the thread, you can >> change them all you want without affecting any other thread. > > What does it matter, seeing as Python lacks the ability altogether? I don't understand what you mean. Python lacks the ability to do what altogether? If you mean that Python threads lack the ability to have local variables, that's not true at all. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Q on explicitly calling file.close
On Sat, 05 Sep 2009 16:14:02 +, kj wrote: > Finally, I was under the impression that Python closed filehandles > automatically when they were garbage-collected. (In fact (3) suggests > as much, since it does not include an implicit call to fh.close.) If so, > the difference between (1) and (3) does not seem very big. What am I > missing here? (1) Python the language will close file handles, but doesn't guarantee when. Some implementations (e.g. CPython) will close them immediately the file object goes out of scope. Others (e.g. Jython) will close them "eventually", which may be when the program exists. (2) If the file object never goes out of scope, say because you've stored a reference to it somewhere, the file will never be closed and you will leak file handles. Since the OS only provides a finite number of them, any program which uses large number of files is at risk of running out. (3) For quick and dirty scripts, or programs that only use one or two files, relying on the VM to close the file is sufficient (although lazy in my opinion *wink*) but for long-running applications using many files, or for debugging, you may want more control over what happens when. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: The future of Python immutability
On Sat, 05 Sep 2009 14:09:57 -0700, Adam Skutt wrote: >> Python does not have lambda objects. It has lambda expressions that >> produce function objects identical except for .__name__ to the >> equivalent def statement output. > > Sure sounds like python has lambda objects to me then... the fact > they're a special case of some more general construct is mostly > semantics, /especially/ in the context of the point I was actually > making, no? No. Lambdas are a *syntactical construct*, not an object. You wouldn't talk about "while objects" and "if objects" and "comment objects" *because they're not objects*. Neither are lambdas -- they're syntax, which creates ordinary functions: >>> def f(x): ... return x ... >>> g = lambda x: x >>> type(f) is type(g) True Functions created with def and functions created with lambda are *precisely* the same type of object. There is no such thing as a "lambda object" which is a "special case" of ordinary functions, there are just functions. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: efficiently splitting up strings based on substrings
On Sep 5, 7:07 pm, "Rhodri James" wrote:
> On Sat, 05 Sep 2009 23:54:08 +0100, per wrote:
> > On Sep 5, 6:42 pm, "Rhodri James" wrote:
> >> On Sat, 05 Sep 2009 22:54:41 +0100, per wrote:
> >> > I'm trying to efficiently "split" strings based on what substrings
> >> > they are made up of.
> >> > i have a set of strings that are comprised of known substrings.
> >> > For example, a, b, and c are substrings that are not identical to each
> >> > other, e.g.:
> >> > a = "0" * 5
> >> > b = "1" * 5
> >> > c = "2" * 5
>
> >> > Then my_string might be:
>
> >> > my_string = a + b + c
>
> >> > i am looking for an efficient way to solve the following problem.
> >> > suppose i have a short
> >> > string x that is a substring of my_string. I want to "split" the
> >> > string x into blocks based on
> >> > what substrings (i.e. a, b, or c) chunks of s fall into.
>
> >> > to illustrate this, suppose x = "00111". Then I can detect where x
> >> > starts in my_string
> >> > using my_string.find(x). But I don't know how to partition x into
> >> > blocks depending
> >> > on the substrings. What I want to get out in this case is: "00",
> >> > "111". If x were "00122",
> >> > I'd want to get out "00","1", "22".
>
> >> > is there an easy way to do this? i can't simply split x on a, b, or c
> >> > because these might
> >> > not be contained in x. I want to avoid doing something inefficient
> >> > like looking at all substrings
> >> > of my_string etc.
>
> >> > i wouldn't mind using regular expressions for this but i cannot think
> >> > of an easy regular
> >> > expression for this problem. I looked at the string module in the
> >> > library but did not see
> >> > anything that seemd related but i might have missed it.
>
> >> I'm not sure I understand your question exactly. You seem to imply
> >> that the order of the substrings of x is consistent. If that's the
> >> case, this ought to help:
>
> >> >>> import re
> >> >>> x = "00122"
> >> >>> m = re.match(r"(0*)(1*)(2*)", x)
> >> >>> m.groups()
>
> >> ('00', '1', '22')>>> y = "00111"
> >> >>> m = re.match(r"(0*)(1*)(2*)", y)
> >> >>> m.groups()
>
> >> ('00', '111', '')
>
> >> You'll have to filter out the empty groups for yourself, but that's
> >> no great problem.
>
> > The order of the substrings is consistent but what if it's not 0, 1, 2
> > but a more complicated string? e.g.
>
> > a = 1030405, b = 1babcf, c = fUUIUP
>
> > then the substring x might be 4051ba, in which case using a regexp
> > with (1*) will not work since both a and b substrings begin with the
> > character 1.
>
> Right. This looks approximately nothing like what I thought your
> problem was. Would I be right in thinking that you want to match
> substrings of your potential "substrings" against the string x?
>
> I'm sufficiently confused that I think I'd like to see what your
> use case actually is before I make more of a fool of myself.
>
> --
> Rhodri James *-* Wildebeest Herder to the Masses
it's exactly the same problem, except there are no constraints on the
strings. so the problem is, like you say, matching the substrings
against the string x. in other words, finding out where x "aligns" to
the ordered substrings abc, and then determine what chunk of x belongs
to a, what chunk belongs to b, and what chunk belongs to c.
so in the example i gave above, the substrings are: a = 1030405, b =
1babcf, c = fUUIUP, so abc = 10304051babcffUUIUP
given a substring like 4051ba, i'd want to split it into the chunks a,
b, and c. in this case, i'd want the result to be: ["405", "1ba"] --
i.e. "405" is the chunk of x that belongs to a, and "1ba" the chunk
that belongs to be. in this case, there are no chunks of c. if x
instead were "4051babcffUU", the right output is: ["405", "1babcf",
"fUU"], which are the corresponding chunks of a, b, and c that make up
x respectively.
i'm not sure how to approach this. any ideas/tips would be greatly
appreciated. thanks again.
--
http://mail.python.org/mailman/listinfo/python-list
Re: run-time inclusion of files
travis+ml-pyt...@subspacefield.org wrote:
> I'm interested in three seperate problems:
>
> 1) being able to import a file that isn't in the standard module include
> path
sys.path.insert(0, "/path/to/module"
module = __import__("module")
del sys.path[0]
Ideally this goes into a function, possibly with os.path.split to break
apart absolute paths.
> 2) being able to import a file whose name is specified in a python string
sys = __import__("sys")
> 3) being able to reload the file if it changes on disk
sys = reload(sys) # sys must have been imported already
Maybe use in conjunction with python-inotify and or Gamin for change
detection.
--
Stephen Fairchild
--
http://mail.python.org/mailman/listinfo/python-list
Re: efficiently splitting up strings based on substrings
On Sat, 05 Sep 2009 23:54:08 +0100, per wrote:
On Sep 5, 6:42 pm, "Rhodri James" wrote:
On Sat, 05 Sep 2009 22:54:41 +0100, per wrote:
> I'm trying to efficiently "split" strings based on what substrings
> they are made up of.
> i have a set of strings that are comprised of known substrings.
> For example, a, b, and c are substrings that are not identical to each
> other, e.g.:
> a = "0" * 5
> b = "1" * 5
> c = "2" * 5
> Then my_string might be:
> my_string = a + b + c
> i am looking for an efficient way to solve the following problem.
> suppose i have a short
> string x that is a substring of my_string. I want to "split" the
> string x into blocks based on
> what substrings (i.e. a, b, or c) chunks of s fall into.
> to illustrate this, suppose x = "00111". Then I can detect where x
> starts in my_string
> using my_string.find(x). But I don't know how to partition x into
> blocks depending
> on the substrings. What I want to get out in this case is: "00",
> "111". If x were "00122",
> I'd want to get out "00","1", "22".
> is there an easy way to do this? i can't simply split x on a, b, or c
> because these might
> not be contained in x. I want to avoid doing something inefficient
> like looking at all substrings
> of my_string etc.
> i wouldn't mind using regular expressions for this but i cannot think
> of an easy regular
> expression for this problem. I looked at the string module in the
> library but did not see
> anything that seemd related but i might have missed it.
I'm not sure I understand your question exactly. You seem to imply
that the order of the substrings of x is consistent. If that's the
case, this ought to help:
>>> import re
>>> x = "00122"
>>> m = re.match(r"(0*)(1*)(2*)", x)
>>> m.groups()
('00', '1', '22')>>> y = "00111"
>>> m = re.match(r"(0*)(1*)(2*)", y)
>>> m.groups()
('00', '111', '')
You'll have to filter out the empty groups for yourself, but that's
no great problem.
The order of the substrings is consistent but what if it's not 0, 1, 2
but a more complicated string? e.g.
a = 1030405, b = 1babcf, c = fUUIUP
then the substring x might be 4051ba, in which case using a regexp
with (1*) will not work since both a and b substrings begin with the
character 1.
Right. This looks approximately nothing like what I thought your
problem was. Would I be right in thinking that you want to match
substrings of your potential "substrings" against the string x?
I'm sufficiently confused that I think I'd like to see what your
use case actually is before I make more of a fool of myself.
--
Rhodri James *-* Wildebeest Herder to the Masses
--
http://mail.python.org/mailman/listinfo/python-list
Re: efficiently splitting up strings based on substrings
On Sep 5, 6:42 pm, "Rhodri James" wrote:
> On Sat, 05 Sep 2009 22:54:41 +0100, per wrote:
> > I'm trying to efficiently "split" strings based on what substrings
> > they are made up of.
> > i have a set of strings that are comprised of known substrings.
> > For example, a, b, and c are substrings that are not identical to each
> > other, e.g.:
> > a = "0" * 5
> > b = "1" * 5
> > c = "2" * 5
>
> > Then my_string might be:
>
> > my_string = a + b + c
>
> > i am looking for an efficient way to solve the following problem.
> > suppose i have a short
> > string x that is a substring of my_string. I want to "split" the
> > string x into blocks based on
> > what substrings (i.e. a, b, or c) chunks of s fall into.
>
> > to illustrate this, suppose x = "00111". Then I can detect where x
> > starts in my_string
> > using my_string.find(x). But I don't know how to partition x into
> > blocks depending
> > on the substrings. What I want to get out in this case is: "00",
> > "111". If x were "00122",
> > I'd want to get out "00","1", "22".
>
> > is there an easy way to do this? i can't simply split x on a, b, or c
> > because these might
> > not be contained in x. I want to avoid doing something inefficient
> > like looking at all substrings
> > of my_string etc.
>
> > i wouldn't mind using regular expressions for this but i cannot think
> > of an easy regular
> > expression for this problem. I looked at the string module in the
> > library but did not see
> > anything that seemd related but i might have missed it.
>
> I'm not sure I understand your question exactly. You seem to imply
> that the order of the substrings of x is consistent. If that's the
> case, this ought to help:
>
> >>> import re
> >>> x = "00122"
> >>> m = re.match(r"(0*)(1*)(2*)", x)
> >>> m.groups()
>
> ('00', '1', '22')>>> y = "00111"
> >>> m = re.match(r"(0*)(1*)(2*)", y)
> >>> m.groups()
>
> ('00', '111', '')
>
> You'll have to filter out the empty groups for yourself, but that's
> no great problem.
>
> --
> Rhodri James *-* Wildebeest Herder to the Masses
The order of the substrings is consistent but what if it's not 0, 1, 2
but a more complicated string? e.g.
a = 1030405, b = 1babcf, c = fUUIUP
then the substring x might be 4051ba, in which case using a regexp
with (1*) will not work since both a and b substrings begin with the
character 1.
your solution works if that weren't a possibility, so what you wrote
is definitely the kind of solution i am looking for. i am just not
sure how to solve it in the general case where the substrings might be
similar to each other (but not similar enough that you can't tell
where the substring came from).
--
http://mail.python.org/mailman/listinfo/python-list
Re: efficiently splitting up strings based on substrings
On Sat, 05 Sep 2009 22:54:41 +0100, per wrote:
I'm trying to efficiently "split" strings based on what substrings
they are made up of.
i have a set of strings that are comprised of known substrings.
For example, a, b, and c are substrings that are not identical to each
other, e.g.:
a = "0" * 5
b = "1" * 5
c = "2" * 5
Then my_string might be:
my_string = a + b + c
i am looking for an efficient way to solve the following problem.
suppose i have a short
string x that is a substring of my_string. I want to "split" the
string x into blocks based on
what substrings (i.e. a, b, or c) chunks of s fall into.
to illustrate this, suppose x = "00111". Then I can detect where x
starts in my_string
using my_string.find(x). But I don't know how to partition x into
blocks depending
on the substrings. What I want to get out in this case is: "00",
"111". If x were "00122",
I'd want to get out "00","1", "22".
is there an easy way to do this? i can't simply split x on a, b, or c
because these might
not be contained in x. I want to avoid doing something inefficient
like looking at all substrings
of my_string etc.
i wouldn't mind using regular expressions for this but i cannot think
of an easy regular
expression for this problem. I looked at the string module in the
library but did not see
anything that seemd related but i might have missed it.
I'm not sure I understand your question exactly. You seem to imply
that the order of the substrings of x is consistent. If that's the
case, this ought to help:
import re
x = "00122"
m = re.match(r"(0*)(1*)(2*)", x)
m.groups()
('00', '1', '22')
y = "00111"
m = re.match(r"(0*)(1*)(2*)", y)
m.groups()
('00', '111', '')
You'll have to filter out the empty groups for yourself, but that's
no great problem.
--
Rhodri James *-* Wildebeest Herder to the Masses
--
http://mail.python.org/mailman/listinfo/python-list
Re: run-time inclusion of files
On Sat, Sep 5, 2009 at 3:23 PM, wrote: > Hello, > > I was wondering if there was something like Perl's "require" that allows > you to import a file whose name is specified at run-time. So far I've only > seen imports of modules that are put in the standard module include path. You'll need to use the `imp` module: http://docs.python.org/library/imp.html#module-imp Cheers, Chris -- http://blog.rebertia.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Usage of main()
On Sep 4, 5:56 am, "Jan Kaliszewski" wrote: > 04-09-2009 o 08:37:43 r wrote: > > > Why use a nested function when you already *in* main? > > I understand you name global scope as 'main'. But (independently > of using the __main__ idiom and so on) it is still good idea not to > place to much code in the global scope but to place your app-logic > code in functions -- because, as we noted: > > * in practice it is considerably faster, > > * it helps you with using functions & class browsers. Ah yes, thanks Jan!. And the others mentioning of "side effects" from imports makes a lot of sense too. -- http://mail.python.org/mailman/listinfo/python-list
run-time inclusion of files
Hello, I was wondering if there was something like Perl's "require" that allows you to import a file whose name is specified at run-time. So far I've only seen imports of modules that are put in the standard module include path. I'm interested in three seperate problems: 1) being able to import a file that isn't in the standard module include path 2) being able to import a file whose name is specified in a python string 3) being able to reload the file if it changes on disk I'm pretty sure that the Pylons web framework does all this, and I'm also pretty sure that there's a simple solution, I am just not aware of what it is. -- Obama Nation | My emails do not have attachments; it's a digital signature that your mail program doesn't understand. | http://www.subspacefield.org/~travis/ If you are a spammer, please email j...@subspacefield.org to get blacklisted. pgpPfqVqghzQh.pgp Description: PGP signature -- http://mail.python.org/mailman/listinfo/python-list
efficiently splitting up strings based on substrings
I'm trying to efficiently "split" strings based on what substrings they are made up of. i have a set of strings that are comprised of known substrings. For example, a, b, and c are substrings that are not identical to each other, e.g.: a = "0" * 5 b = "1" * 5 c = "2" * 5 Then my_string might be: my_string = a + b + c i am looking for an efficient way to solve the following problem. suppose i have a short string x that is a substring of my_string. I want to "split" the string x into blocks based on what substrings (i.e. a, b, or c) chunks of s fall into. to illustrate this, suppose x = "00111". Then I can detect where x starts in my_string using my_string.find(x). But I don't know how to partition x into blocks depending on the substrings. What I want to get out in this case is: "00", "111". If x were "00122", I'd want to get out "00","1", "22". is there an easy way to do this? i can't simply split x on a, b, or c because these might not be contained in x. I want to avoid doing something inefficient like looking at all substrings of my_string etc. i wouldn't mind using regular expressions for this but i cannot think of an easy regular expression for this problem. I looked at the string module in the library but did not see anything that seemd related but i might have missed it. any help on this would be greatly appreciated. thanks. -- http://mail.python.org/mailman/listinfo/python-list
Re: Q on explicitly calling file.close
On Sep 5, 2:47 pm, Dennis Lee Bieber wrote: (snip) > > Finally, I was under the impression that Python closed filehandles > > automatically when they were garbage-collected. (In fact (3) > > suggests as much, since it does not include an implicit call to > > fh.close.) If so, the difference between (1) and (3) does not seem > > very big. What am I missing here? True, but i find the with statement (while quite useful in general practice) is not a "cure all" for situations that need and exception caught. In that case the laborious finger wrecking syntax of "f.close ()" must be painstaking typed letter by painful letter. f-.-c-l-o-s-e-(-) It's just not fair ;-( -- http://mail.python.org/mailman/listinfo/python-list
Re: incorrect DeprecationWarning?
I've filed a bug report: http://bugs.python.org/issue6844 Sadly the Twisted developers apparently did not file a bug report when they were bitten by this ... Alan Isaac -- http://mail.python.org/mailman/listinfo/python-list
Re: pysqlite throwing exception?
MRAB wrote: > I wonder whether it's complaining about the "as count" part because > "count" is the name of a function, although you do say that the same > query works elsewhere. Hey, good catch. Thanks; I'll change that. (It wasn't the problem, but no doubt someday it could be.) -Wm -- http://mail.python.org/mailman/listinfo/python-list
Re: pysqlite throwing exception?
william tanksley wrote: > Oh, this is Python 2.5 on Windows. New result: this works on Python 2.6. Obviously the SQLite format changed between the two runs. I'll call this "problem solved"; my app appears to run now. -Wm -- http://mail.python.org/mailman/listinfo/python-list
Re: pysqlite throwing exception?
william tanksley wrote:
I'm trying to modify an app I wrote a few months ago, but now it dies
on startup (it worked before). The app loads the SQLite Media Monkey
database, and crashes on its first query (when I try to get the number
of podcasts). At the end of this post is a reduced version of the
problem (which produces the same error).
Oh, this is Python 2.5 on Windows.
The following is the traceback for the reduced version:
Traceback (most recent call last):
File "C:\projects\podcasts\podstrand-mm\temp.py", line 16, in
cursor.execute("select count(*) as count from songs")
OperationalError: malformed database schema - near "VIRTUAL": syntax
error
It's the same error I get while running this code in context.
The major change is that I upgraded version of MediaMonkey, and I'd
think that might cause problems-- although all of my non-Python SQLite
support apps have no problem (including running the same query).
Unfortunately, if pysqlite's been upgraded, I can't find it --
pysqlite.org has been down the past 2 days.
-Wm
import os
import sqlite3
# Find the mediamonkey database.
conn = sqlite3.connect(
os.path.join(os.environ['USERPROFILE'],
'Local Settings',
'Application Data',
'MediaMonkey',
'MM.DB')
)
conn.row_factory = sqlite3.Row # provide named columns in results
# Ask mediamonkey for its data.
cursor = conn.cursor()
# Get the total number of songs.
cursor.execute("select count(*) as count from songs")
track_estimate = cursor.fetchall()[0]['count']
I wonder whether it's complaining about the "as count" part because
"count" is the name of a function, although you do say that the same
query works elsewhere.
--
http://mail.python.org/mailman/listinfo/python-list
Re: The future of Python immutability
On Sep 5, 11:29 am, Terry Reedy wrote: > > This is a pointless replacement for 'def b(x): return x+a' And? That has nothing to do with anything I was saying whatsoever. Point is: any mutable shared state is bad, and making objects immutable isn't enough to remove all shared state, or even reduce it to be available only with TEH EBIL global variables. > Python does not have lambda objects. It has lambda expressions that > produce function objects identical except for .__name__ to the > equivalent def statement output. Sure sounds like python has lambda objects to me then... the fact they're a special case of some more general construct is mostly semantics, /especially/ in the context of the point I was actually making, no? -- http://mail.python.org/mailman/listinfo/python-list
Re: Support for Windows 7 ?
Pascale Mourier wrote:
>
>YES IT IS! Sorry for the inconvenience. I usually start from this
>assumption. Yesterday this new student was really agressive, and I
>assumed he was right!
>
>Here's his mistake: with Windows the name of the directory rooted at a
>drive name (say C:) is called 'C:\' not 'C:', and it's been that way for
>ages.
The root of drive C: is, indeed, spelled "C:\". However, the spelling "C:"
has a well-defined meaning, and it has since MS-DOS 2 when directories were
introduced. It means "the current directory for C:".
>Well, os.listdir('C:') instead of raising an exception, for some reason
>behaves like os.listdir('.').
Because it's not an exception. The meaning is well-defined. This can be
very handy, for example, when copying between deeply nested paths on
different drives:
D:
cd "\Ridiculous\Long\Path\Names\For Annoyance"
C:
cd "\Another\Ridiculous\Long\Path\Name"
copy C:one.txt D:two.txt
--
Tim Roberts, t...@probo.com
Providenza & Boekelheide, Inc.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Formatted input function
Günther Dietrich a écrit : > > RTFM! :) > > In the python 2.5 manual: Chapter 4.2.6 (search pattern 'scanf' on the > index tab of python25.chm) Correct !! For once ;) the Manual gives an inambiguous answer : -- Simulating scanf() .-- Python does not currently have an equivalent to scanf(). Regular expressions are generally more powerful, though also more verbose, than scanf() format strings. -- I'm realizing that using re module is worthwhile but I never tried to learn it. -- http://mail.python.org/mailman/listinfo/python-list
pysqlite throwing exception?
I'm trying to modify an app I wrote a few months ago, but now it dies
on startup (it worked before). The app loads the SQLite Media Monkey
database, and crashes on its first query (when I try to get the number
of podcasts). At the end of this post is a reduced version of the
problem (which produces the same error).
Oh, this is Python 2.5 on Windows.
The following is the traceback for the reduced version:
Traceback (most recent call last):
File "C:\projects\podcasts\podstrand-mm\temp.py", line 16, in
cursor.execute("select count(*) as count from songs")
OperationalError: malformed database schema - near "VIRTUAL": syntax
error
It's the same error I get while running this code in context.
The major change is that I upgraded version of MediaMonkey, and I'd
think that might cause problems-- although all of my non-Python SQLite
support apps have no problem (including running the same query).
Unfortunately, if pysqlite's been upgraded, I can't find it --
pysqlite.org has been down the past 2 days.
-Wm
import os
import sqlite3
# Find the mediamonkey database.
conn = sqlite3.connect(
os.path.join(os.environ['USERPROFILE'],
'Local Settings',
'Application Data',
'MediaMonkey',
'MM.DB')
)
conn.row_factory = sqlite3.Row # provide named columns in results
# Ask mediamonkey for its data.
cursor = conn.cursor()
# Get the total number of songs.
cursor.execute("select count(*) as count from songs")
track_estimate = cursor.fetchall()[0]['count']
--
http://mail.python.org/mailman/listinfo/python-list
Re: Q on explicitly calling file.close
CPython uses reference counting, so an object is garbage collected as soon as there are no references to it, but that's just an implementation detail. Other implementations, such as Jython and IronPython, don't use reference counting, so you don't know when an object will be garbage collected, which means that the file might remain open for an unknown time afterwards in case 1 above. Most people use CPython, so it's not surprising that case 1 is so common. Additionally, many scripts just use a small number of files (say, 1-5 files) so having a file-handle open for the duration of the run it minimal overhead. On the other hand, when processing thousands of files, I always explicitly close each file to make sure I don't exhaust some file-handle limit the OS or interpreter may enforce. -tkc -- http://mail.python.org/mailman/listinfo/python-list
Pythonwin.exe Error?!?
HELP! So apparently after installing EPD 5.0 (a python 2.5 dist) aside my main Python installation (2.6) I started getting this error. -Pure virtual function call Whenever I open up ActiveState Python, it gets this runtime error under pythonwin.exe Already uninstalled EPD but am still getting this error. I've done everything from re-install Python and ActiveState to deleting everything in the registry to do with Python!!! I suggest that nobody install that until they sort their problems out. But for now, any help is appreciated. -- http://mail.python.org/mailman/listinfo/python-list
Re: Support for Windows 7 ?
* MRAB (Sat, 05 Sep 2009 17:54:00 +0100)
> Pascale Mourier wrote:
> > Martin v. Löwis a écrit :
> >
> >> Without having seen any details, I refuse to guess. Most likely, it is
> >> a user mistake.
> >
> > YES IT IS! Sorry for the inconvenience. I usually start from this
> > assumption. Yesterday this new student was really agressive, and I
> > assumed he was right!
> >
> > Here's his mistake: with Windows the name of the directory rooted at a
> > drive name (say C:) is called 'C:\' not 'C:', and it's been that way for
> > ages.
> > Well, os.listdir('C:') instead of raising an exception, for some reason
> > behaves like os.listdir('.').
>
> I believe that in Windows (and inherited from MS-DOS) there's a current
> directory for each drive. If you want to change the current directory to
> another directory on another drive in the Windows command prompt then
> you must change both the current drive and the current directory for
> that drive, eg:
Exactly (or use the "/d" parameter which is a newer improvement).
Thorsten
--
http://mail.python.org/mailman/listinfo/python-list
Re: Q on explicitly calling file.close
On Sep 5, 1:17 pm, Dave Angel wrote: > kj wrote: > > There's something wonderfully clear about code like this: > > > # (1) > > def spam(filename): > > for line in file(filename): > > do_something_with(line) > > > It is indeed pseudo-codely beautiful. But I gather that it is not > > correct to do this, and that instead one should do something like > > > # (2) > > def spam(filename): > > fh = file(filename) > > try: > > for line in fh: > > do_something_with(line) > > finally: > > fh.close() > > > ...or alternatively, if the with-statement is available: > > > # (3) > > def spam(filename): > > with file(filename) as fh: > > for line in fh: > > do_something_with(line) > > > Mind you, (3) is almost as simple as (1) (only one additional line), > > but somehow it lacks (1)'s direct simplicity. (And it adds one > > more indentation level, which I find annoying.) Furthermore, I > > don't recall ever coming across either (2) or (3) "in the wild", > > even after reading a lot of high-quality Python code (e.g. standard > > library modules). > > > Finally, I was under the impression that Python closed filehandles > > automatically when they were garbage-collected. (In fact (3) > > suggests as much, since it does not include an implicit call to > > fh.close.) If so, the difference between (1) and (3) does not seem > > very big. What am I missing here? > > > kynn > > We have to distinguish between reference counted and garbage collected. > As MRAB says, when the reference count goes to zero, the file is > immediately closed, in CPython implementation. So all three are > equivalent on that platform. > > But if you're not sure the code will run on CPython, then you have to > have something that explicitly catches the out-of-scopeness of the file > object. Both your (2) and (3) do that, with different syntaxes. > > DaveA Stop being lazy and close the file. You don't want open file objects just floating around in memory. Even the docs says something like "yes, python will free the memory associated with a file object but you can never *really* be sure *when* this will happen, so just explicitly close the damn thing!". Besides, you can't guarantee that any data has been written without calling f.flush() or f.close() first. What if your program crashes and no data is written? huh? I guess i could put my pants on by jumping into both legs at the same time thereby saving one step, but i my fall down and break my arm. I would much rather just use the one leg at a time approach... -- http://mail.python.org/mailman/listinfo/python-list
Re: Q on explicitly calling file.close
kj wrote: There's something wonderfully clear about code like this: # (1) def spam(filename): for line in file(filename): do_something_with(line) It is indeed pseudo-codely beautiful. But I gather that it is not correct to do this, and that instead one should do something like # (2) def spam(filename): fh = file(filename) try: for line in fh: do_something_with(line) finally: fh.close() ...or alternatively, if the with-statement is available: # (3) def spam(filename): with file(filename) as fh: for line in fh: do_something_with(line) Mind you, (3) is almost as simple as (1) (only one additional line), but somehow it lacks (1)'s direct simplicity. (And it adds one more indentation level, which I find annoying.) Furthermore, I don't recall ever coming across either (2) or (3) "in the wild", even after reading a lot of high-quality Python code (e.g. standard library modules). Finally, I was under the impression that Python closed filehandles automatically when they were garbage-collected. (In fact (3) suggests as much, since it does not include an implicit call to fh.close.) If so, the difference between (1) and (3) does not seem very big. What am I missing here? kynn We have to distinguish between reference counted and garbage collected. As MRAB says, when the reference count goes to zero, the file is immediately closed, in CPython implementation. So all three are equivalent on that platform. But if you're not sure the code will run on CPython, then you have to have something that explicitly catches the out-of-scopeness of the file object. Both your (2) and (3) do that, with different syntaxes. DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: Formatted input function
On Sat, Sep 5, 2009 at 8:00 AM, Terry Reedy wrote:
> Chris Rebert wrote:
>>
>> On Sat, Sep 5, 2009 at 3:13 AM, candide wrote:
>>>
>>> I have a text file and the first line provides the best score of a game.
>>> This
>>> line has the following format :
>>>
>>> Best score : 42
>>>
>>> In order to update the score, I try to retrieve the score value.
>>>
>>> In C, we would manage this with the following statement :
>>>
>>> fscanf(foo_file, "Best score : %d", &score);
>>>
>>> Does Python provide an equivalent ?
>>
>> Not an exact one, but it's still easily accomplished:
>>
>> score = int(foo_file.read().split(":").strip())
>
> One must, of course, select the second item from the list returned by
> .split.
(whacks forehead)
One should not answer threads at 3AM local time without
double-checking the solution...
- Chris
--
http://mail.python.org/mailman/listinfo/python-list
Re: Formatted input function
candide wrote: >In C, we would manage this with the following statement : > >fscanf(foo_file, "Best score : %d", &score); > >Does Python provide an equivalent ? RTFM! :) In the python 2.5 manual: Chapter 4.2.6 (search pattern 'scanf' on the index tab of python25.chm) There are some scanf-patterns with corresponding regular expressions listed. Works quite nice. Best regards, Günther -- http://mail.python.org/mailman/listinfo/python-list
Re: Q on explicitly calling file.close
kj wrote: There's something wonderfully clear about code like this: # (1) def spam(filename): for line in file(filename): do_something_with(line) It is indeed pseudo-codely beautiful. But I gather that it is not correct to do this, and that instead one should do something like # (2) def spam(filename): fh = file(filename) try: for line in fh: do_something_with(line) finally: fh.close() ...or alternatively, if the with-statement is available: # (3) def spam(filename): with file(filename) as fh: for line in fh: do_something_with(line) Mind you, (3) is almost as simple as (1) (only one additional line), but somehow it lacks (1)'s direct simplicity. (And it adds one more indentation level, which I find annoying.) Furthermore, I don't recall ever coming across either (2) or (3) "in the wild", even after reading a lot of high-quality Python code (e.g. standard library modules). Finally, I was under the impression that Python closed filehandles automatically when they were garbage-collected. (In fact (3) suggests as much, since it does not include an implicit call to fh.close.) If so, the difference between (1) and (3) does not seem very big. What am I missing here? CPython uses reference counting, so an object is garbage collected as soon as there are no references to it, but that's just an implementation detail. Other implementations, such as Jython and IronPython, don't use reference counting, so you don't know when an object will be garbage collected, which means that the file might remain open for an unknown time afterwards in case 1 above. Most people use CPython, so it's not surprising that case 1 is so common. -- http://mail.python.org/mailman/listinfo/python-list
Re: Support for Windows 7 ?
Pascale Mourier wrote:
Martin v. Löwis a écrit :
Without having seen any details, I refuse to guess. Most likely, it is
a user mistake.
YES IT IS! Sorry for the inconvenience. I usually start from this
assumption. Yesterday this new student was really agressive, and I
assumed he was right!
Here's his mistake: with Windows the name of the directory rooted at a
drive name (say C:) is called 'C:\' not 'C:', and it's been that way for
ages.
Well, os.listdir('C:') instead of raising an exception, for some reason
behaves like os.listdir('.').
I believe that in Windows (and inherited from MS-DOS) there's a current
directory for each drive. If you want to change the current directory to
another directory on another drive in the Windows command prompt then
you must change both the current drive and the current directory for
that drive, eg:
D:
chdir another_dir
--
http://mail.python.org/mailman/listinfo/python-list
Re: possible attribute-oriented class
05-09-2009 Steven D'Aprano wrote: On Fri, 04 Sep 2009 22:37:15 +0200, Jan Kaliszewski wrote: 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. [snip] What sort of extensions did you have in mind? Two useful (from my point of view) concepts have appeared (or been linked to) in this thread -- on python-list and python-ideas: * the namespace/AttrDict concept (see Ken Newton's, Nick Coghlan's and my posts). * record concept (see George Sakkis post). The old discussion, the above link points to, shows that such a dot-accessible dict-like class is something that many people need and repeatedly implemet it (more or less perfectly) for themselves. I think it's something which people copy from other languages because that's what they're used to, not because they need it. I don't think so, especially if we say about the former. IMHO it is simply useful in practice, especially for scripting (but not only) -- being more convenient than using empty class. It offers (in compact way, without additional efforts and verbose syntax -- once you have got such a tool implemented) three things at the same time, without necessity to choose between them: comfortable static attribute access, flexible dict-like dynamic access when needed and possibility of iteration. It's just a change in syntax. Whether you write x.key or x['key'] is a matter of convenience. Attribute access is optimized for when you know the key names at compile time, key access is optimized for when you don't know the names until runtime. Exactly. It is a matter of *convenience* (as well as large areas of Python) and that's the point. I suppose that that is the reason for people to repeatedly implement it for themselves. 05-09-2009 Steven D'Aprano wrote: On Fri, 04 Sep 2009 22:51:39 -0700, Ken Newton wrote: [snip] I would think this is much more than just copy from other language styles or 'just' a syntax change -- the apparent widespread use would hint at a deeper need. "Apparent" is the key word there. There are lots of people who *say* this this useful functionality, but how many of them *actually* use it? And of those who do use it, how many of them know what they're doing? There are an awful lot of bad programmers out there. If you do need such functionality, it's easy to implement. Here's one: Neither you nor me have hard evidence about popularity/unpopularity of the idea (number of places where you can find similar, more or less successful, attempts to implement it seems to testify in favour of the idea) -- nor about how it is used or abused. Obviously there are a lot of bad programmers who are able to use globals instead of function arguments etc Thats the fate of every language feature. But it's not the reason to resign from a feature that has particular common and proper use-cases. Even official Python tutorial mentions a case that is typical for the matter: http://docs.python.org/3.1/tutorial/classes.html#odds-and-ends As a general rule, if obj.x is an attribute, then every valid obj should have an attribute x. But if obj['x'] is a key/value, then it is data-specific: some instances will have an 'x' key, and some won't. It's often true but not always (see e.g. the above example in docs). Cheers, *j -- Jan Kaliszewski (zuo) -- http://mail.python.org/mailman/listinfo/python-list
Q on explicitly calling file.close
There's something wonderfully clear about code like this: # (1) def spam(filename): for line in file(filename): do_something_with(line) It is indeed pseudo-codely beautiful. But I gather that it is not correct to do this, and that instead one should do something like # (2) def spam(filename): fh = file(filename) try: for line in fh: do_something_with(line) finally: fh.close() ...or alternatively, if the with-statement is available: # (3) def spam(filename): with file(filename) as fh: for line in fh: do_something_with(line) Mind you, (3) is almost as simple as (1) (only one additional line), but somehow it lacks (1)'s direct simplicity. (And it adds one more indentation level, which I find annoying.) Furthermore, I don't recall ever coming across either (2) or (3) "in the wild", even after reading a lot of high-quality Python code (e.g. standard library modules). Finally, I was under the impression that Python closed filehandles automatically when they were garbage-collected. (In fact (3) suggests as much, since it does not include an implicit call to fh.close.) If so, the difference between (1) and (3) does not seem very big. What am I missing here? kynn -- http://mail.python.org/mailman/listinfo/python-list
Re: Turn-based game - experimental economics
On Saturday 05 September 2009 12:07:59 Paolo Crosetto wrote: 8<--- > > The problem I now face is to organise turns. Players, as in Scrabble, will > play in turns. So far I have developed the server and ONE client, and > cannot get my head round to - nor find many examples of - how to simply > develop a turn-based interaction. 8<-- > > Does anyone have any hints? Why do you not just write a loop, giving each player a turn? keep a list of players. for player in players: tell_her_to_respond(player) ans = get_the_answer(player) update_all(player,ans) This is of course very basic, as it needs stuff like timeouts. But maybe it can get you started. HTH - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Support for Windows 7 ?
Martin v. Löwis a écrit :
Without having seen any details, I refuse to guess. Most likely, it is
a user mistake.
YES IT IS! Sorry for the inconvenience. I usually start from this
assumption. Yesterday this new student was really agressive, and I
assumed he was right!
Here's his mistake: with Windows the name of the directory rooted at a
drive name (say C:) is called 'C:\' not 'C:', and it's been that way for
ages.
Well, os.listdir('C:') instead of raising an exception, for some reason
behaves like os.listdir('.').
--
http://mail.python.org/mailman/listinfo/python-list
Re: Turn-based game - experimental economics
Dear Terry, thanks. > > As I understand your description, the server and each client will be a > separate process on a separate machine (once deployed), so threads do > not seem applicable. (For development, you can use separate processes on > one machine communicating through sockets just as if they were on > multiple machines.) Exactly. And this is exactly how I do it now. I have a process for the server, and process for the client (I succeeded in having it working with one client). I use XMLRPC to setup the server and make calls from the client. > As I understand select, it is for select *any* > available client input, not just one in particular. I believe the > standard solution is to define a 'turn token' and write the clients so > that they only do 'turn' activities when and only when they have that > token. This is similar to what bouncynic suggested. I was thinking of having a status global variable in the server that register whose turn it is [eg a list of N zeroes for N players] and ask the client to read that variable and act only when their own element in the list turns to one, white otherwise. Does this make sense? > I presume you do not need to worry about players trying to cheat > by rewriting the client. No, not really :) I have one more question, then: how do I make the client stay alive during the waiting period? Let me explain with rubbish pseudocode. Right now the code for handling turns, with status held on alist on the server, would be: client: if server.getStatus[i]==1: ...play all the actions in one's turn... server.changeStatus[i] #changes to zero the global status var server.passTurn #the last action for client i is to set to 1 the triggervar for client i+1 else: wait Now, my question is: how do I implement 'wait' without making the client exit? With gui-based clients I guess it is done with mainloop() keeping the app alive until something closes it; how do I achieve that with stdout (bash) clients? Sorry for the not-so-much related question, and thanks for your suggestions. -- Paolo Crosetto - PhD Student in Economics DEAS - Department of Economics - University of Milan - -- http://mail.python.org/mailman/listinfo/python-list
Re: The future of Python immutability
Adam Skutt wrote: \ This is a side-effect of writing code that relies on global variables. Global variables are generally a bad idea. Global constants are fine. Nope, the variables don't have to be global to have this problem, they just have to be shared: >>> a = 3 >>> b = lambda x: x + a This is a pointless replacement for 'def b(x): return x+a' >>> print b(3) 6 >>> a = 4 >>> print b(3) 7 Passing any lambda Python does not have lambda objects. It has lambda expressions that produce function objects identical except for .__name__ to the equivalent def statement output. tjr -- http://mail.python.org/mailman/listinfo/python-list
Re: incorrect DeprecationWarning?
On 02:28 pm, alan.is...@gmail.com wrote: I am not sure how best to deprecate dependence on the Python 2.5 mistake, but this is not it. And I know at least one important library that is affected. I'll agree that it's not great. I certainly would have preferred it not to have been done. It is futile to complain about this kind of thing on python-list, though. Raise the issue on python-dev. I don't think anyone will listen to you, but who knows until you try. If you have an alternate suggestion to make, that might help gain some traction; if not, the issue will probably just be dismissed. Even so, I suspect someone will say "This is irrelevant, just rename your attribute." Python developers aren't much concerned with this kind of thing. Cynically, Jean-Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: Turn-based game - experimental economics
Paolo Crosetto wrote: Dear all, I am writing an application in Python for an experiment in Experimental Economics. For those who do not know what this is: experimental economics uses controlled, computerised lab experiments with real subjects, putting the subject in a game mimicking the situation of interest and collecting behavioural data about choices made. Hence, experiments involve the use of a multi-client architecture with one server, and are sort of online games, with actions taken by clients and computation, data collection, etc... handled by servers. I chose to use Python because I needed something flexible, powerful and easy - I am a beginner programmer. My game is a sort of scrabble, with palyers buying letters and producing words or extending existing words. I use a pipe to ispell -a for spellcheck, XMLRPC for the server-client infrastructure, and have developed all the rules of the game as server functions, called by a client. States of players and of words created are stored in instances of two basic classes, Player and Word, on the server side. The problem I now face is to organise turns. Players, as in Scrabble, will play in turns. So far I have developed the server and ONE client, and cannot get my head round to - nor find many examples of - how to simply develop a turn-based interaction. I basically need the server to freeze in writing all the clients while client i is playing, then when i is over passing the turn to i+1; clients are still accessible by the server at any time (the payoff of a player changes even as she is not playing, by royalties collected from other players extending her words). In another thread (about a battleship game) I found two possible leads to a solution: 1. using 'select'. 2. using threads. But in both cases I could not find any clear documentation on how to do this. The 'select' road was said to be the easiest, but I found no further hints. Does anyone have any hints? As I understand your description, the server and each client will be a separate process on a separate machine (once deployed), so threads do not seem applicable. (For development, you can use separate processes on one machine communicating through sockets just as if they were on multiple machines.) As I understand select, it is for select *any* available client input, not just one in particular. I believe the standard solution is to define a 'turn token' and write the clients so that they only do 'turn' activities when and only when they have that token. I presume you do not need to worry about players trying to cheat by rewriting the client. tjr -- http://mail.python.org/mailman/listinfo/python-list
Re: Formatted input function
Chris Rebert wrote:
On Sat, Sep 5, 2009 at 3:13 AM, candide wrote:
I have a text file and the first line provides the best score of a game. This
line has the following format :
Best score : 42
In order to update the score, I try to retrieve the score value.
In C, we would manage this with the following statement :
fscanf(foo_file, "Best score : %d", &score);
Does Python provide an equivalent ?
Not an exact one, but it's still easily accomplished:
score = int(foo_file.read().split(":").strip())
One must, of course, select the second item from the list returned by
.split. The .strip() seems not to be needed, at least in 3.1, as int()
ignores whitespace.
>>> s='Best score : 42\n'
>>> int(s.split(':')[1])
42
--
http://mail.python.org/mailman/listinfo/python-list
Re: How to access ODBC databases ?
Martin P. Hellwig wrote:
Timothy Madden wrote:
Martin P. Hellwig wrote:
Timothy Madden wrote:
>>> conn = pyodbc.connect('DRIVER={PostgreSQL
Unicode};Servername=127.0.0.1;UID=pikantBlue;Database=pikantBlue')
Traceback (most recent call last):
File "", line 1, in
pyodbc.Error: ('0', '[0] [nxDC (202) (SQLDriverConnectW)')
Not sure (i.e. wild guess) but that line makes me think it has
something to do with the encoding, is it possible to try a different
driver?
Thank you.
Slackware also comes with mysql, I guess I could try to install and
register a driver for it in my unixODBC installation.
What about the encoding ? What should I be looking for in this case ?
Indeed when I try
createdb --encoding=UTF-8 pikantBlue
I get the message that the server's /LC_TYPE settings require encoding
to be LATIN1/. What should I do about it ? Should I have been more
careful about the configure options when compiling postgresql ? I also
tried pyodbc on Ubuntu with the database installed with apt-get and I
still get the same problem.
Thank you
Timothy Madden
According to this:
http://psqlodbc.projects.postgresql.org/faq.html#2.5
You could try the 'PostgreSQL ANSI' driver.
Thank you.
The precompiled psqlodbca.so driver from apt-get worked on one of the
Ubuntu machines that I tried.
I would still like o use the Unicode driver if possible. Do you know
what the problem could be ? Or where ? pyodbc/unixODBC/psqlodbcw.so ?
Thank you,
Timothy Madden
--
http://mail.python.org/mailman/listinfo/python-list
Re: incorrect DeprecationWarning?
exar...@twistedmatrix.com wrote: On 12:20 pm, alan.is...@gmail.com wrote: I think you are missing my point. I understand it is just a DeprecationWarning. But **why** should I receive a deprecation warning when I am **not** using the deprecated practice? Since I am **not** using the deprecated practice, the warning is incorrect. (See the class definition above.) And this incorrect warning affects a lot of people! You are using the deprecated practice. Attributes are not scoped to a particular class. There is only one "message" attribute on your "MyError" instance. It does not belong just to "MyError". It does not belong just to "Exception". It does not belong just to "BaseException". It is shared by all of them. Because "BaseException" deprecates instances of it having a "message" attribute, any instance of any subclass of "BaseException" which uses this attribute will get the deprecation warning. Perhaps you weren't intending to use the "message" attribute as "BaseException" was using it, but this doesn't matter. There is only one "message" attribute, and "BaseException" already claimed it, and then deprecated it. What anyone who is **not** using the deprecated practice should expect in Python 2.6 is the Py3 behavior. That is not what we get: we get instead an incorrect deprecation warning. Possibly so, but there is no way for the runtime to know that you're not trying to use the deprecated behavior. All it can tell is that you're using the deprecated attribute name. Perhaps you can come up with a way for it to differentiate between these two cases and contribute a patch, though. It is sometimes hard to warn exactly when appropriate and impossible for the default action to satisfy everyone. The developers are, of course, aware of this. That is why there is a mechanism to turn off particular warnings. Checkout the extremely flexible warnings module. tjr -- http://mail.python.org/mailman/listinfo/python-list
Re: Math Notations, Computer Languages, and the “F orm” in Formalism
> Theorem provers > such as OCaml (HOL, Coq), Mizar does math formalism as a foundation, > also function as a generic computer language, but lacks abilities as a > computer algebra system or math notation representation. Isabelle's presentation layer is well integrated with LaTeX and you can use math notation in (presentation of) proofs. Slawekk -- http://mail.python.org/mailman/listinfo/python-list
Re: IMGCrush (New Python image optimizing tool)
In article , kiithsa...@gmail.com wrote: > >Requires ImageMagick and Python (coded in python 2.x, I'm running 2.6 >but it might run on older python as well) Why are you using ImageMagick instead of PIL? -- Aahz (a...@pythoncraft.com) <*> http://www.pythoncraft.com/ "Look, it's your affair if you want to play with five people, but don't go calling it doubles." --John Cleese anticipates Usenet -- http://mail.python.org/mailman/listinfo/python-list
Re: incorrect DeprecationWarning?
On 9/5/2009 9:07 AM, exar...@twistedmatrix.com wrote: You are using the deprecated practice. Clearly not, or it would fail in Python 3, which it does not. Attributes are not scoped to a particular class. There is only one "message" attribute on your "MyError" instance. It does not belong just to "MyError". It does not belong just to "Exception". It does not belong just to "BaseException". It is shared by all of them. No, it does not belong to any of those classes. It belongs to the instance. Because "BaseException" deprecates instances of it having a "message" attribute That is what is is doing, and that is precisely the problem. The DeprecationError is raised for the wrong thing. I mean be serious: this is flagging the use of a new attribute on a subclass. If you proposed building a class that way the screams on "unPythonic" on this list would be deafening. I am not sure how best to deprecate dependence on the Python 2.5 mistake, but this is not it. And I know at least one important library that is affected. Alan Isaac -- http://mail.python.org/mailman/listinfo/python-list
ANNOUNCE: Leo 4.6.3 released
Leo 4.6.3 final is now available at: http://sourceforge.net/project/showfiles.php?group_id=3458&package_id=29106 Leo is a text editor, data organizer, project manager and much more. See: http://webpages.charter.net/edreamleo/intro.html Leo 4.6.3 fixes a significant caching bug in Leo 4.6.2. Leo 4.6.3 also comes with an executable installer for Windows. The highlights of Leo 4.6 -- - Cached external files *greatly* reduces the time to load .leo files. - Leo now features a modern Qt interface by default. Leo's legacy Tk interface can also be used. - New --config, --file and --gui command-line options. - Leo tests syntax of .py files when saving them. - Leo can now open any kind of file into @edit nodes. - @auto-rst nodes allow easy editing of reStructuredText files. - Properties of commanders, positions and nodes simplify programming. - Improved Leo's unit testing framework. - Leo now requires Python 2.5 or later. - Dozens of small improvements and bug fixes. Links: -- Leo: http://webpages.charter.net/edreamleo/front.html Forum:http://groups.google.com/group/leo-editor Download: http://sourceforge.net/project/showfiles.php?group_id=3458 Bzr: http://code.launchpad.net/leo-editor/ Quotes: http://webpages.charter.net/edreamleo/testimonials.html Edward K. Ream email: edream...@yahoo.com Leo: http://webpages.charter.net/edreamleo/front.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Application-global "switches"?
In Ethan Furman writes: >I've seen a couple cool recipes implementing WORM* attributes if you >wanted to ensure that your settings were not re-set. >Steven D'Aprano wrote one with a class name of ConstantNamespace, you >can search on that if you're interested. I'd include the code, but I >have no idea if that's good netiquette or not. Thanks, I'll check this out. kynn -- http://mail.python.org/mailman/listinfo/python-list
Re: incorrect DeprecationWarning?
On 12:20 pm, alan.is...@gmail.com wrote:
Alan G Isaac wrote:
Python 2.6.2 (r262:71605, Apr 14 2009, 22:40:02) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more
information.
class MyError(Exception):
... def __init__(self, message):
... Exception.__init__(self)
... self.message = message
...
e = MyError('msg')
__main__:4: DeprecationWarning: BaseException.message has been
deprecated as of Python 2.6
So? Why would that mean I cannot add such an attribute
to derived classes?
On 9/4/2009 6:42 PM, Terry Reedy wrote:
It does not mean that. Try printing e.message and you should see
'msg'.
I believe what it does mean is the the special meaning of
exception.message (I have forgotten what it is) is gone in Python 3.
In Py3
class MyError(Exception):
def __init__(self, message):
Exception.__init__(self)
self.message = message
e = MyError('msg')
print(e.message)
# 'msg'
No warning any more.
Exactly!
I think you are missing my point.
I understand it is just a DeprecationWarning.
But **why** should I receive a deprecation warning
when I am **not** using the deprecated practice?
Since I am **not** using the deprecated practice, the
warning is incorrect. (See the class definition above.)
And this incorrect warning affects a lot of people!
You are using the deprecated practice. Attributes are not scoped to a
particular class. There is only one "message" attribute on your
"MyError" instance. It does not belong just to "MyError". It does not
belong just to "Exception". It does not belong just to "BaseException".
It is shared by all of them. Because "BaseException" deprecates
instances of it having a "message" attribute, any instance of any
subclass of "BaseException" which uses this attribute will get the
deprecation warning. Perhaps you weren't intending to use the "message"
attribute as "BaseException" was using it, but this doesn't matter.
There is only one "message" attribute, and "BaseException" already
claimed it, and then deprecated it.
What anyone who is **not** using the deprecated practice
should expect in Python 2.6 is the Py3 behavior. That is
not what we get: we get instead an incorrect deprecation
warning.
Possibly so, but there is no way for the runtime to know that you're not
trying to use the deprecated behavior. All it can tell is that you're
using the deprecated attribute name. Perhaps you can come up with a way
for it to differentiate between these two cases and contribute a patch,
though.
Jean-Paul
--
http://mail.python.org/mailman/listinfo/python-list
PyCon 2010 - Call for Tutorials
The Tutorial Committee for PyCon 2010 in Atlanta is now accepting proposals for classes. This year will feature 2 days of classes prior to the "official" conference. These classes are 3-hour long sessions concentrating on specific Python packages or techniques and are taught by some of the smartest cookies in the Python Universe. Anything Python may be submitted for consideration but there are a limited number of sessions to be filled. Topics taught or requested over the past two years include: * Python 101 - An introduction to programming Python, either for complete beginners or programmers experienced in other languages. * Python 201 - There has been repeated requests for classes covering "intermediate" topics; data structures, database techniques, classes/objects, standard library, eggs, etc. * Python 401 - Classes covering "advanced" topics; multi-processing/concurrency, iterators/generators, OOP, etc. * Web Topics - Frameworks, web testing, design, security, scraping. * Scientific Python - MatLab, SciPy * Testing - Frameworks, methods * GUI - Dabo, wxPython, TkInter, etc. * More: XML, GIS, SQLAlchemy, Jython, System Administration More information, including a sample proposal and blank template, are at http://us.pycon.org/2010/tutorials/proposals/. Questions? Email us at pycon-tutori...@python.org. Greg Lindstrom -- http://mail.python.org/mailman/listinfo/python-list
Re: incorrect DeprecationWarning?
Alan G Isaac wrote:
Python 2.6.2 (r262:71605, Apr 14 2009, 22:40:02) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
class MyError(Exception):
... def __init__(self, message):
... Exception.__init__(self)
... self.message = message
...
e = MyError('msg')
__main__:4: DeprecationWarning: BaseException.message has been
deprecated as of Python 2.6
So? Why would that mean I cannot add such an attribute
to derived classes?
On 9/4/2009 6:42 PM, Terry Reedy wrote:
It does not mean that. Try printing e.message and you should see 'msg'.
I believe what it does mean is the the special meaning of
exception.message (I have forgotten what it is) is gone in Python 3.
In Py3
class MyError(Exception):
def __init__(self, message):
Exception.__init__(self)
self.message = message
e = MyError('msg')
print(e.message)
# 'msg'
No warning any more.
Exactly!
I think you are missing my point.
I understand it is just a DeprecationWarning.
But **why** should I receive a deprecation warning
when I am **not** using the deprecated practice?
Since I am **not** using the deprecated practice, the
warning is incorrect. (See the class definition above.)
And this incorrect warning affects a lot of people!
What anyone who is **not** using the deprecated practice
should expect in Python 2.6 is the Py3 behavior. That is
not what we get: we get instead an incorrect deprecation
warning.
Alan Isaac
--
http://mail.python.org/mailman/listinfo/python-list
Re: The future of Python immutability
On Sep 5, 12:06 am, Steven D'Aprano wrote: > On Fri, 04 Sep 2009 06:36:59 -0700, Adam Skutt wrote: > > Nope, preventing mutation of the objects themselves is not enough. You > > also have to forbid variables from being rebound (pointed at another > > object). Consider this simple example: > > > -- Thread 1 -- | -- Thread 2 -- > > a = "Foo" > > spawn Thread 2 > > a = "Bar" print "thread 2: %s" % a > > print "thread 1: %s" % a > > > You could see (ignoring the fact the output isn't ordered): > > "thread 1: Bar" > > "thread 2: Foo" > > or: > > "thread 1: Bar" > > "thread 2: Bar" > > > so the fact "Foo" and "Bar" are immutable isn't enough to solve the > > problem. > > This is a side-effect of writing code that relies on global variables. > Global variables are generally a bad idea. Global constants are fine. Nope, the variables don't have to be global to have this problem, they just have to be shared: >>> a = 3 >>> b = lambda x: x + a >>> print b(3) 6 >>> a = 4 >>> print b(3) 7 Passing any lambda between threads will cause the problem I described above, regardless of whether the variables captured are global or not. > What do you mean by "variables"? Do you mean names? In the case of python I mean the name and the value, since all variables in Python are pointers. (Worrying about the difference though, is semantics) > > What are pointer semantics? Assignment to the variable causes it to point to another object (as opposed to assigning a new value to the current object, like a C++ reference) and copying the variable does not create a copy of the referred object (which necessarily implies their lifecycles are independent). > Assuming you mean names must be forbidden from being rebound, no, > incorrect. It's only names which are shared between both threads which > must not be re-bound. If you have names local to the thread, you can > change them all you want without affecting any other thread. What does it matter, seeing as Python lacks the ability altogether? Thanks, Adam -- http://mail.python.org/mailman/listinfo/python-list
Re: The future of Python immutability
On 5 Sep, 08:47, Steven D'Aprano wrote: > How do you know? After more than 10 years experience with scientific programming I just do. When it comes to numerics I have a gut feeling for what is fast and what is slow. It's not difficult actually. You just have to imagine how often the interpreter is invoked. Explicit loops are therefore evilness in numerical scripts. Vectorized array expressions tend to be comparable to C in performance, because they do a lot of work independent of the interpreter. What do we see here? Vectorized array expressions throughout the code, no significant amount of looping by the interpreter (just the recursion at the end). -- http://mail.python.org/mailman/listinfo/python-list
Query
We are developing a turn-based strategy game in Python 2.6. One of the features of this game is that several battles can be concurrently in progress which each one having a *user-defined* turn-length. So the problem here is coming up with a robust method of turn processing which ensures all initialized battles proceed according to their user-defined turn schedules. We're looking for ideas on how to accomplish this elegantly - so far we've only been able to implement a global timer function (defeats the original purpose). Can you folks help? We'll be very grateful. -Hassan Baig (The Varsity Heroes Team) -- http://mail.python.org/mailman/listinfo/python-list
Re: Turn-based game - experimental economics
As I Understand it I Would just use a simple shared variable or perhaps data wrote to a file to indicate busy or waiting and then use some kind of wait function or no-op to simulate' then recheck -- Sent via Cricket Mobile Email --Original Message-- From: Paolo Crosetto To: Date: Sat, 5 Sep 2009 12:07:59 PM +0200 Subject: Turn-based game - experimental economics Dear all, I am writing an application in Python for an experiment in Experimental Economics. For those who do not know what this is: experimental economics uses controlled, computerised lab experiments with real subjects, putting the subject in a game mimicking the situation of interest and collecting behavioural data about choices made. Hence, experiments involve the use of a multi-client architecture with one server, and are sort of online games, with actions taken by clients and computation, data collection, etc... handled by servers. I chose to use Python because I needed something flexible, powerful and easy - I am a beginner programmer. My game is a sort of scrabble, with palyers buying letters and producing words or extending existing words. I use a pipe to ispell -a for spellcheck, XMLRPC for the server-client infrastructure, and have developed all the rules of the game as server functions, called by a client. States of players and of words created are stored in instances of two basic classes, Player and Word, on the server side. The problem I now face is to organise turns. Players, as in Scrabble, will play in turns. So far I have developed the server and ONE client, and cannot get my head round to - nor find many examples of - how to simply develop a turn-based interaction. I basically need the server to freeze in writing all the clients while client i is playing, then when i is over passing the turn to i+1; clients are still accessible by the server at any time (the payoff of a player changes even as she is not playing, by royalties collected from other players extending her words). In another thread (about a battleship game) I found two possible leads to a solution: 1. using 'select'. 2. using threads. But in both cases I could not find any clear documentation on how to do this. The 'select' road was said to be the easiest, but I found no further hints. Does anyone have any hints? thanks! -- Paolo Crosetto - PhD Student in Economics DEAS - Department of Economics - University of Milan - -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Formatted input function
On Sat, Sep 5, 2009 at 3:13 AM, candide wrote:
> I have a text file and the first line provides the best score of a game. This
> line has the following format :
>
> Best score : 42
>
> In order to update the score, I try to retrieve the score value.
>
> In C, we would manage this with the following statement :
>
> fscanf(foo_file, "Best score : %d", &score);
>
> Does Python provide an equivalent ?
Not an exact one, but it's still easily accomplished:
score = int(foo_file.read().split(":").strip())
Cheers,
Chris
--
http://blog.rebertia.com
--
http://mail.python.org/mailman/listinfo/python-list
Formatted input function
I have a text file and the first line provides the best score of a game. This line has the following format : Best score : 42 In order to update the score, I try to retrieve the score value. In C, we would manage this with the following statement : fscanf(foo_file, "Best score : %d", &score); Does Python provide an equivalent ? -- http://mail.python.org/mailman/listinfo/python-list
Turn-based game - experimental economics
Dear all, I am writing an application in Python for an experiment in Experimental Economics. For those who do not know what this is: experimental economics uses controlled, computerised lab experiments with real subjects, putting the subject in a game mimicking the situation of interest and collecting behavioural data about choices made. Hence, experiments involve the use of a multi-client architecture with one server, and are sort of online games, with actions taken by clients and computation, data collection, etc... handled by servers. I chose to use Python because I needed something flexible, powerful and easy - I am a beginner programmer. My game is a sort of scrabble, with palyers buying letters and producing words or extending existing words. I use a pipe to ispell -a for spellcheck, XMLRPC for the server-client infrastructure, and have developed all the rules of the game as server functions, called by a client. States of players and of words created are stored in instances of two basic classes, Player and Word, on the server side. The problem I now face is to organise turns. Players, as in Scrabble, will play in turns. So far I have developed the server and ONE client, and cannot get my head round to - nor find many examples of - how to simply develop a turn-based interaction. I basically need the server to freeze in writing all the clients while client i is playing, then when i is over passing the turn to i+1; clients are still accessible by the server at any time (the payoff of a player changes even as she is not playing, by royalties collected from other players extending her words). In another thread (about a battleship game) I found two possible leads to a solution: 1. using 'select'. 2. using threads. But in both cases I could not find any clear documentation on how to do this. The 'select' road was said to be the easiest, but I found no further hints. Does anyone have any hints? thanks! -- Paolo Crosetto - PhD Student in Economics DEAS - Department of Economics - University of Milan - -- http://mail.python.org/mailman/listinfo/python-list
Re: possible attribute-oriented class
On Fri, 04 Sep 2009 22:51:39 -0700, Ken Newton wrote:
> On Fri, Sep 4, 2009 at 9:49 PM, Steven
> D'Aprano wrote: ...
>>
>>> The old discussion, the above link points to, shows that such a
>>> dot-accessible dict-like class is something that many people need and
>>> repeatedly implemet it (more or less perfectly) for themselves.
>>
>> I think it's something which people copy from other languages because
>> that's what they're used to, not because they need it.
>>
>> It's just a change in syntax. Whether you write x.key or x['key'] is a
>> matter of convenience. Attribute access is optimized for when you know
>> the key names at compile time, key access is optimized for when you
>> don't know the names until runtime. Compare:
>>
>> # You know the key when you write the code. x.key versus x['key']
>>
>> # You don't know the key until runtime. s = get_key()
>> getattr(x, s) versus x[s]
> ...
>
> I would think this is much more than just copy from other language
> styles or 'just' a syntax change -- the apparent widespread use would
> hint at a deeper need.
"Apparent" is the key word there. There are lots of people who *say* this
this useful functionality, but how many of them *actually* use it? And of
those who do use it, how many of them know what they're doing? There are
an awful lot of bad programmers out there.
If you do need such functionality, it's easy to implement. Here's one:
http://code.activestate.com/recipes/502219/
No comment, no votes.
Here's another:
http://code.activestate.com/recipes/361668/
Four comments, mostly negative, no votes.
To me, this seems like a superficially attractive idea which is actually
a bad idea, even when it's useful. Using a screwdriver as a chisel, or
crowbar is useful too, and I've done so myself, but it's still usually a
bad idea.
Key lookup and attribute access are superficially similar, and they're
implemented the same way in Python, but they're actually for different
conceptual purposes. Attributes are conceptually part of the object,
while key/values are conceptually data attached to the object. As a
general rule, if obj.x is an attribute, then every valid obj should have
an attribute x. But if obj['x'] is a key/value, then it is data-specific:
some instances will have an 'x' key, and some won't. Consequently,
obj.has_key('x') (better written these days as 'x' in obj) will be MUCH
more common than hasattr(obj, 'x').
For example, dict.clear has a special meaning shared by all dicts.
dict['clear'] does not. You confuse the two at your peril.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: print() a list
On Sep 5, 1:51 am, Dero wrote: > On Sep 5, 2:35 pm, "Mark Tolonen" wrote: > > > "DarkBlue" wrote in message > > >news:b9c0c4ac-5f8f-4133-b928-9e55ab4b2...@x5g2000prf.googlegroups.com... > > > >I am trying to get used to the new print() syntax prior to installing > > > python 3.1: ... > > Without the following statement, print does not work the "new" way. What > > you are printing is a tuple of the two list elements. > > > from __future__ import print_function ... > I thought in 2.6 both print and print() were equally implemented > without the future import requirement. That couldn't be done because the print() syntax can't be distinguished from old-style print with a tuple. ~$ python2.6 -c "print(1, 2)" (1, 2) ~$ python3.0 -c "print(1, 2)" 1 2 -- http://mail.python.org/mailman/listinfo/python-list
Re: recursive decorator
> def enable_recur(f): > print f.func_code.co_names > if 'recur' not in f.func_code.co_names: > return f # do nothing on non-recursive functions > c = Code.from_code(f.func_code) > c.code[1:1] = [(LOAD_GLOBAL, f.__name__), (STORE_FAST, 'recur')] > for i, (opcode, value) in enumerate(c.code[2:]): > if opcode == LOAD_GLOBAL and value == 'recur': > c.code[i+2] = (LOAD_FAST, 'recur') > f.func_code = c.to_code() > return f > There is a useless line 'print f.func_code.co_names' here, a left over of my tests, sorry. -- http://mail.python.org/mailman/listinfo/python-list
Re: Multiple inheritance - How to call method_x in InheritedBaseB from method_x in InheritedBaseA?
On Fri, Sep 4, 2009 at 11:23 AM, Scott David Daniels wrote: > The Music Guy wrote: >> >> I have a peculiar problem that involves multiple inheritance and method >> calling. >> >> I have a bunch of classes, one of which is called MyMixin and doesn't >> inherit from anything. MyMixin expects that it will be inherited along >> with one of several other classes that each define certain >> functionality. > > ... ... >> >> This all appears fine at first, but ... >> One might be tempted to amend MyMixin's method_x so that it calls the >> parent's method_x before doing anything else: >> >> class MyMixin(object): >> def method_x(self, a, b, c): >> super(MyMixin, self).method_x(a, b, c) >> ... >> >> ...but of course, that will fail with an AttributeError because >> MyMixin's only superclass is object, which does not have a method_x. > > Here the fix below works. > >> The only way I can think to solve the problem would be to implement a >> method_x for each Foo that calls the method_x for each of the bases: > > ... >> >> So, does anyone have an idea about how to remedy this, or at least >> work around it? > > The diamond inheritance stuff is meant to allow you to deal with > exactly this issue. If you define a class, MixinBase, with do- > nothing entries for all the methods you are inventing, and you > make all of your Mixin classes (and your main class) inherit > from MixinBase, you are guaranteed that all of the Mixins you > use will be earlier on the method resolution order (mro in the > docs) than MixinBase. If the set of actual methods is small > and pervasive, I might even be tempted rename MixinBase to > "Object": > if 1: > class MixinBase(object): > '''Base for solving mixin strategy. > > Also a nice common place to describe the args and meaning. > ''' > def method_x(self, a, b, c): > '''Suitable docstring''' > print 'MixinBase' > > class MyMixin(MixinBase): > def method_x(self, a, b, c): > super(MyMixin, self).method_x(a, b, c) > print 'Mixin' > class BaseA(MixinBase): > def method_x(self, a, b, c): > super(BaseA, self).method_x(a, b, c) > print 'BaseA' > class BaseB(MixinBase): > pass > class BaseC(MixinBase): > def method_x(self, a, b, c): > super(BaseC, self).method_x(a, b, c) > print 'BaseC' > class FooX(MyMixin, BaseA): > def method_x(self, a, b, c): > super(FooX, self).method_x(a, b, c) > print 'FooX' > class FooY(MyMixin, BaseB): > pass > class FooZ(MyMixin, BaseC): > def method_x(self, a, b, c): > super(FooZ, self).method_x(a, b, c) > print 'FooZ' > > FooZ().method_x(1,2,3) > MixinBase > BaseC > Mixin > FooZ FooY().method_x(1,2,3) > MixinBase > Mixin FooX().method_x(1,2,3) > MixinBase > BaseA > Mixin > FooX BaseA().method_x(1,2,3) > MixinBase > BaseA > --Scott David Daniels > scott.dani...@acm.org > -- > http://mail.python.org/mailman/listinfo/python-list > Thanks for your reply, Scott. I'm glad there's somebody here who is actually willing to help me with this; it seems like I usually don't get any response from posting to most mailing lists. However, I'm not sure I completely understand your solution. Two of my requirements are that 1.) no Foo class ever need implement a method_x because each FooN is merely a version of a BaseN with MyMixin features added in, and 2.) Each BaseN is a fully-usable class that does not have MyMixin features and does not need to be subclassed in order to be used (ie. even though it is usable as a base, it is also usable as an ordinary class). Here's some psuedocode that may make my intent more clear: class Widget(SomeBase, SomeOtherBase, ...): """ A GUI class that occupies a region of a screen. Can be contained by a Container class. """ def __init__(self, region): # Rect-ify the given region (no pun intended) self.region = Rect(region) class Container(Widget): """ A widget that can contain other widgets and show their regions in relation to the container's region. """ def __init__(self, region, children=()): Widget.__init__(self, region) self.children = [] for child in children: self.append(child) def __getitem__(self, index): return self.children[index] def __setitem__(self, index, new): self.children[index] = new def append(self, new): self.children.append(new) class MovableContainer(Container): """ Enhanced container that can be moved in response to the user clicking and dragging on an empty space in the container. """ ...code for handling mouse input... def append(self, child): """ Provides enhanced functionality for Container.append. """ super(MovableContainer, self).append(child) ... do some other stuff ... class LayoutControlMixin(o
Re: print syntax
On Thu, 03 Sep 2009 12:22:14 -0400, doug wrote: > I am new to python, working by way through 'Core Python Programming'. I > can find no description of using print with the built-in type for > formatting. I think I have got some [most?] of it from Chun, google, and > python.org. My comment is - it should not be that hard to find. I would > suggest a link from the print syntax section. > > What is seems to be is: > >print "format-spec" % (variable-list) > > I assume the '%' is required token. > > > > _ > Douglas Denault > http://www.safeport.com > d...@safeport.com > Voice: 301-217-9220 >Fax: 301-217-9277 You say "using print with the built-in type for formatting." - It's two separate things, print just prints a string. You can use the formatting quite separately on the string first. my_string = "%s %s %s" % (1, 2, 3)# creates string "1 2 3" print my_string so you probably would find difficulty is searching for 'print formatting', you should be looking for string formatting. -- http://mail.python.org/mailman/listinfo/python-list
