Noob script needs some input: CVS PatchMaker
I needed a tool for extracting patches from CVS based on the log
messages. I.e. we mark our fixes and features with a "Bugdb XYZ"
And sometimes you need to move a fix/feature to another branch or maybe
you just want to inspect exactly what changes were related to a
specific bugdb issue.
Now I've searched hi and low for this and I now it's out there
somewhere bleeding obvious - can't imagine I'm the first to have this
thought. I just haven't been able to find it...
Well, that was an excellent opportunity to get some python practice, so
below is my first shot at the problem.
Any feedback on what would be "the pythonic way" to do this would be
much appreciated!
Usage:
cd myproject
patchmaker
Ouput is a diff of involved files+revs
Thank you,
/Holger
--
#!/usr/bin/env python
# Copyright 2006 Holger Lindeberg Bille
import sys, re, os
import popen2
workingfile = re.compile("^Working file: *(.*)$")
revision= re.compile("^revision *(.*)$")
fileend =
re.compile("^===")
details = re.compile("^date: *")
entryend= re.compile("^")
branches= re.compile("^branches:( *(.*);)*")
class LogEntry:
def __init__(self):
self.rev = 0
self.prevrev = 0
self.text = []
def setName(self, name):
self.name = name
def read(self, file):
done = 0
for line in file:
regx = details.search(line)
if regx:
pass
else:
if entryend.search(line):
break
else:
if fileend.search(line):
done = 1
break
else:
self.text.append(line.strip())
return done
def GuessPrevRev(self):
pass
def filter(self, filter):
found = 0
for line in self.text:
if filter.search(line):
found = 1
break
return found
def calcPrevRev(self):
# todo: get this from CVS instead of guessing
self.rev = "1.1"
self.prevrev = "1.1"
ver = self.name.split(".")
n = int(ver.pop()) - 1
while len(ver) >= 1:
if n >= 1:
ver.append(str(n))
self.prevrev = ".".join(ver)
self.rev = self.name
break
else:
ver.pop() # throw this away
n = int(ver.pop())
def patchDump(self, file):
cmd = "cvs -q diff -u -b -r %s -r %s %s" % (self.prevrev,
self.rev, file)
# print cmd
outp, inp = popen2.popen2(cmd)
for line in outp:
print line,
outp.close()
inp.close()
def dump(self):
print "--"
print "rev = %s" % self.name
for line in self.text:
print line
class FileLog:
def __init__(self):
self.revs = []
def setName(self, name):
self.name = name
def read(self, file):
for line in file:
regx = revision.search(line)
if regx:
rev = LogEntry()
rev.setName(regx.group(1))
done = rev.read(file)
self.revs.append(rev)
if done:
break
def filter(self, filter):
found = 0
newrevs = []
for rev in self.revs:
if rev.filter(filter):
found = 1
newrevs.append(rev)
self.revs = newrevs
return found
def calcPrevRev(self):
for rev in self.revs:
rev.calcPrevRev()
def patchDump(self):
for rev in self.revs:
rev.patchDump(self.name)
def dump(self):
print "File = %s" % self.name
print "No. of revs %d" % len(self.revs)
for rev in self.revs:
rev.dump()
print "==="
class LogDB:
def __init__(self):
self.flogs = []
def read(self):
outp, inp = popen2.popen2('cvs -q log -N')
found = 0
for line in outp:
regx = workingfile.search(line)
if regx:
flog = FileLog()
flog.setName(regx.group(1))
flog.read(outp)
self.flogs.append(flog)
outp.close()
inp.close()
def filter(self, filter):
newflogs = []
for flog in self.flogs:
if flog.filter(filter):
newflo
Re: Noob script needs some input: CVS PatchMaker
John Machin wrote: > > Any feedback on what would be "the pythonic way" to do this would be > > much appreciated! --snip-- > > IMHO that flight of geese heading equatorwards for winter is not Xic for > any language X. Compare with: He he, good point. > 2nd comment: Make a habit of NOT using the names of built-ins like > "file" for your own names. Pretend they are reserved words. Doesn't > matter in this case, but will save you grief some day soon. > Agree. > 3rd comment: Read the section in the re manual that explains the > difference between search and match. Searching for "^foo" will give the > same results as using match() with "foo" or the redundantly anchored > "^foo". However some regex engines when presented with Good point. > 4th comment: what you have called "regx" is a match object. "mobj" might > be a better choice. The term "regex" is applied to a pattern, or > sometimes to the compiled re object. ] > > HTH, > John Thank you for taking the time :-) All points are noted. Holger, -- http://mail.python.org/mailman/listinfo/python-list
Frequency spectrum with fft of a real valued array...?
Dear all, I need to do a FFT on an array of 20k real values. Origin of the sampled data is a sinus wave with light harmonics. The goal is an frequency spectrum with the magnitudes of the first 50. harmonics. I addressed python like: test_arr = src_data_dict[ channel ][0:19599] target_data_dict[ channel ] = FFT.fft(test_arr,n=50,axis=-1) This results in an array of complex values but with unexpected big coefficients... (much higher than the original signal magnitudes) How do I get the absolute magnitudes of the harmonics, which are much lower than the resulting absolute values of the coefficients? The result should be like this: 1.harmonic (50 Hz) 1,0 2.harmonic (100 Hz) 0,01 3.harmonic (100 Hz) 0,08 4.harmonic (100 Hz) 0,0035 etc. at the moment I get a resulting array like: CH1 (1729.80103418+0j) (366.689810532+19.5196963754j) (370.688444025+32.162562652j) (372.122246668+46.9545880507j) (379.273599053+59.0724599622j) (369.889589421+75.9247281559j) (381.070551892+99.07345873j) (378.800462354+106.761629308j) (375.014128346+131.34177586j) (389.110601354+149.320740829j) (389.23247472+158.909042086j) (398.875237165+197.86980788j) (397.927158223+196.858459101j) (402.455325066+234.651276425j) (411.599088579+256.32156894j) (414.469935576+254.512014918j) (417.198515262+291.400509132j) (426.745545674+320.769421334j) (433.987466212+321.929780157j) (446.124386798+350.810581686j) (455.876025379+383.099789898j) (458.083277747+405.592129477j) (470.908512117+433.929598454j) (482.083855098+468.256188814j) What does it mean to me? How do I get to the wanted frequenca spectrum??? .. btw The maximum magnitudes of the original data are app. 70 peak Thanks in advance for your help!!! Regards Holger -- http://mail.python.org/mailman/listinfo/python-list
Re: Frequency spectrum with fft of a real valued array...?
Hello Robert! Thank you for your tips. They were very useful. Bye Holger Am 11.01.2007, 19:08 Uhr, schrieb Robert Kern <[EMAIL PROTECTED]>: > Holger wrote: > >> What does it mean to me? How do I get to the wanted frequenca >> spectrum??? > > It's packed in the conventional FFT format. Here is a function in numpy > (the > successor to Numeric, which I assume that you are using) that generates > the > corresponding frequencies in the same packed format: > > In [324]: import numpy > > In [325]: numpy.fft.fftfreq? > Type: function > Base Class: > Namespace: Interactive > File: > /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/numpy-1.0.2.dev3507-py2.5-macosx-10.4-i386.egg/numpy/fft/helper.py > Definition: numpy.fft.fftfreq(n, d=1.0) > Docstring: > fftfreq(n, d=1.0) -> f > > DFT sample frequencies > > The returned float array contains the frequency bins in > cycles/unit (with zero at the start) given a window length n and a > sample spacing d: > > f = [0,1,...,n/2-1,-n/2,...,-1]/(d*n) if n is even > f = [0,1,...,(n-1)/2,-(n-1)/2,...,-1]/(d*n) if n is odd > > -- http://mail.python.org/mailman/listinfo/python-list
compound statement from C "?:"
Hi
I have not been able to figure out how to do compound statement from C
- "?:"
But something similar must exist...?!
I would like to do the equivalent if python of the C line:
printf("I saw %d car%s\n", n, n != 1 ? "s" : "")
Please help
/Holger
--
http://mail.python.org/mailman/listinfo/python-list
Re: compound statement from C "?:"
Thanks all for good input.
It seems like there's no the-python-way for this one.
Currently I'm forced to use cygwin - and python in cygwin is still not
2.5 so I can't use the new inline if-else ternary operator.
> >> if n == 1:
> >> print "I saw a car"
> >> else:
> >> print "I saw %d cars" % n
Personally I don't like the if-else approach because of the don't-
repeat-yourself philosophy
> D'accord. Did I mention that, as a "for fun" approach, "s" * (n != 1) is
> quite clever :-)
>
> Peter
I like this one :-)
> print "I saw %d car%s\n" % (n, ("", "s")[n != 1])
And this one.
/Holger
--
http://mail.python.org/mailman/listinfo/python-list
noob question: "TypeError" wrong number of args
Hi guys Tried searching for a solution to this, but the error message is so generic, that I could not get any meaningfull results. Anyways - errormessage: TypeError: addFile() takes exactly 1 argument (2 given) The script is run with two args "arg1" and "arg2": import sys class KeyBase: def addFile(file): print "initialize the base with lines from this file" print "These are the args" print "Number of args %d" % len(sys.argv) print sys.argv print sys.version_info print sys.version f = sys.argv[1] print "f = '%s'" % f b = KeyBase() b.addFile(f) The output - including error message (looks like stdout and stderr are a bit out of sync...): These are the args Traceback (most recent call last): Number of args 3 ['C:\\home\\<.. bla bla snip ...>\\bin\\test.py', 'arg1', 'arg2'] (2, 4, 2, 'final', 0) 2.4.2 (#67, Oct 30 2005, 16:11:18) [MSC v.1310 32 bit (Intel)] f = 'arg1' File "C:\Program Files\ActiveState Komodo 3.5\lib\support\dbgp\pythonlib\dbgp\client.py", line 1806, in runMain self.dbg.runfile(debug_args[0], debug_args) File "C:\Program Files\ActiveState Komodo 3.5\lib\support\dbgp\pythonlib\dbgp\client.py", line 1529, in runfile h_execfile(file, args, module=main, tracer=self) File "C:\Program Files\ActiveState Komodo 3.5\lib\support\dbgp\pythonlib\dbgp\client.py", line 590, in __init__ execfile(file, globals, locals) File "C:\home\hbille\projects\bc4rom\bin\test.py", line 20, in __main__ b.addFile(f) TypeError: addFile() takes exactly 1 argument (2 given) I'm running this inside ActiveState Komodo on WinXP. Hope one you wizards can give me pointers to either what I'm doing wrong or maybe advise me what to modify in my setup. Thank you! Regards, Holger -- http://mail.python.org/mailman/listinfo/python-list
Re: noob question: "TypeError" wrong number of args
oops, that was kinda embarrassing. But thx anyway :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: noob question: "TypeError" wrong number of args
I guess I deserved that. :-( I *did* read the tutorial, but then I forgot and didn't notice... My brain is getting is slow - so thx for the friendly slap in the face ;-) -- http://mail.python.org/mailman/listinfo/python-list
Re: noob question: "TypeError" wrong number of args
And thank you gentlemen for turning my somewhat banale question into a worthwhile discussion. :-) I shall not forget self ever again! -- http://mail.python.org/mailman/listinfo/python-list
Using python Serial module on windows
Hi I'm using python Serial from: http://switch.dl.sourceforge.net/sourceforge/pyserial/pyserial-2.4.tar.gz to implement ymodem and other protocols on the PC com port And it works like a charm in cygwin, but when I try to use it directly in python under windows using active state python installation, it says it's missing the module win32file. But the win32file module looks like it is no longer in development and support stopped at python 2.2 Am I going about this issue the wrong way? Can anyone suggest a way out of this fix? Thank You Holger -- http://mail.python.org/mailman/listinfo/python-list
Re: how to get the thighest bit position in big integers?
On 6 Okt., 10:37, Mark Dickinson <[EMAIL PROTECTED]> wrote: > See alsohttp://bugs.python.org/issue3439 > where there's a proposal to expose the _PyLong_NumBits method. This > would give an O(1) solution. Doesn't that depend on the underlying implementation? Anyway, here's a pretty one (I think): def highest_bit(n, maxbits = 256): bit = 0 while maxbits > 1: maxbits = maxbits >> 1 mask_b = ((1<> maxbits else: n = b return bit I suspect you would call that a O(logn)) solution Holger -- http://mail.python.org/mailman/listinfo/python-list
Re: how to get the thighest bit position in big integers?
def highest_bit(n, maxbits = 256): bit = 0 while maxbits > 1: maxbits >>= 1 a = n >> maxbits if a: bit += maxbits n = a return bit is sligtly better -- http://mail.python.org/mailman/listinfo/python-list
Re: Using python Serial module on windows
Turns out there's a windows package that works bautifully with activestate python: pyserial-2.4.win32.exe Thank you. -- http://mail.python.org/mailman/listinfo/python-list
Clever way of sorting strings containing integers?
I tried to do this elegantly, but did not come up with a good solution Sort strings like foo1bar2 foo10bar10 foo2bar3 foo10bar2 So that they come out: foo1bar2 foo2bar3 foo10bar2 foo10bar10 I.e. isolate integer parts and sort them according to integer value. Thx Holger -- http://mail.python.org/mailman/listinfo/python-list
Re: Clever way of sorting strings containing integers?
On 9 Okt., 09:41, Holger <[EMAIL PROTECTED]> wrote: > I tried to do this elegantly, but did not come up with a good solution > > Sort strings like > foo1bar2 > foo10bar10 > foo2bar3 > foo10bar2 > > So that they come out: > foo1bar2 > foo2bar3 > foo10bar2 > foo10bar10 > > I.e. isolate integer parts and sort them according to integer value. > > Thx > Holger or even: foo1bar2 foo10bar10 foo2bar3 foo10bar2 fo bar1000 777 To: 777 bar1000 fo foo1bar2 foo2bar3 foo10bar2 foo10bar10 Here's my own take, but it doesn't quite work yet: txtline = re.compile(r'(\D*)(\d+)') lines = [x.strip() for x in sys.stdin.readlines()] res = [] for l in [ x for x in lines if x]: groups = txtline.findall(l) res.append([[[x[0], int(x[1],0)] for x in groups],l]) res.sort() for x in res: print x[1] -- http://mail.python.org/mailman/listinfo/python-list
Re: Clever way of sorting strings containing integers?
On 9 Okt., 10:57, Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> wrote: > On Thu, 09 Oct 2008 00:41:27 -0700, Holger wrote: > > I tried to do this elegantly, but did not come up with a good solution > > > Sort strings like > > foo1bar2 > > foo10bar10 > > foo2bar3 > > foo10bar2 > > > So that they come out: > > foo1bar2 > > foo2bar3 > > foo10bar2 > > foo10bar10 > > > I.e. isolate integer parts and sort them according to integer value. > > import re > > def key_func(string): > result = re.split(r'(\d+)', string) > for i in xrange(1, len(result), 2): > result[i] = int(result[i]) > return result > > def main(): > lines = ['foo1bar2', > 'foo10bar10', > 'foo2bar3', > 'foo10bar2', > 'fo', > 'bar1000', > '777'] > lines.sort(key=key_func) > print '\n'.join(lines) Perfect! Thank you. -- http://mail.python.org/mailman/listinfo/python-list
Re: read() does not read whole file in activepython/DOS
On Nov 7, 2:40 pm, Holger <[EMAIL PROTECTED]> wrote:
> This is what it looks like in DOS:
> ===
> C:\production>python
> ActivePython 2.5.2.2 (ActiveState Software Inc.) based on
> Python 2.5.2 (r252:60911, Mar 27 2008, 17:57:18) [MSC v.1310 32 bit
> (Intel)] on
> win32
> Type "help", "copyright", "credits" or "license" for more information.>>> b =
> open('boot.bin').read()
> >>> len(b)
> 1067
> >>> import os
> >>> os.path.getsize('boot.bin')
>
> 18308L
> ===
>
> What is wrong? / What am I doing wrong?
> I would expect it to read the whole file.
Solution: open(, 'rb')
--
http://mail.python.org/mailman/listinfo/python-list
read() does not read whole file in activepython/DOS
This is what it looks like in DOS:
===
C:\production>python
ActivePython 2.5.2.2 (ActiveState Software Inc.) based on
Python 2.5.2 (r252:60911, Mar 27 2008, 17:57:18) [MSC v.1310 32 bit
(Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> b = open('boot.bin').read()
>>> len(b)
1067
>>> import os
>>> os.path.getsize('boot.bin')
18308L
===
And this is what is says in cygwin:
===
$ python
Python 2.5.1 (r251:54863, May 18 2007, 16:56:43)
[GCC 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)] on cygwin
Type "help", "copyright", "credits" or "license" for more information.
>>> b = open('boot.bin').read()
>>> len(b)
18308
>>> import os
>>> os.path.getsize('boot.bin')
18308L
===
What is wrong? / What am I doing wrong?
I would expect it to read the whole file.
Help appreciated :-)
Holger
--
http://mail.python.org/mailman/listinfo/python-list
execnet-1.1: cross-interpreter distributed execution library
execnet-1.1 is a backward compatible beta release of the popular (>53000 pypi downloads of 1.0.9) cross-interpreter execution library. If you are in need of connecting Python2 and Python3 and/or want to throw PyPy in your deployment mix, then you might want to join Quora and many others and try out execnet. execnet provides a share-nothing model with channel-send/receive communication and distributed execution across many Python interpreters across version, platform and network barriers. See below for changes and see here for extensive documentation and tested examples: http://codespeak.net/execnet Particular thanks to Ronny Pfannschmidt for a lot of internal cleanups and to Alex Gaynor for providing feature patches. Have fun, holger 1.1 (compared to 1.0.9) - introduce execnet.dumps/loads providing serialization between python interpreters, see http://codespeak.net/execnet/basics.html#dumps-loads - group.remote_exec now supports kwargs as well - support per channel string coercion configuration, helping with dealing with mixed Python2/Python3 environments. - Popen2IO.read now reads correct amounts of bytes from nonblocking fd's - added a ``dont_write_bytecode`` option to Popen gateways, this sets the ``sys.dont_write_bytecode`` flag on the spawned process, this only works on CPython 2.6 and higher. Thanks to Alex Gaynor. - added a pytest --broken-isp option to skip tests that assume DNS queries for unknown hosts actually are resolved as such (Thanks Alex Gaynor) - fix issue 1 - decouple string coercion of channels and gateway - fix issue #2 - properly reconfigure the channels string coercion for rsync, so it can send from python2 to python3 - refactor socketserver, so it can be directly remote_exec'd for starting a socket gateway on a remote -- http://mail.python.org/mailman/listinfo/python-list
Re: Dr. Dobb's Python-URL! - weekly Python news and links (Dec 30)
On Fri, Dec 31, 2004 at 19:18 +0100, Alex Martelli wrote: > Cameron Laird <[EMAIL PROTECTED]> wrote: >... > > Yippee! The martellibot promises to explain Unicode for Pythoneers. > > http://groups-beta.google.com/group/comp.lang.python/msg/6015a5a05c206712 > > Uh -- _did_ I? Eeep... I guess I did... mostly, I was pointing to > Holger Krekel's very nice recipe (not sure he posted it to the site as > well as submitting it for the printed edition, but, lobby _HIM_ about > that;-). FWIW, i added the recipe back to the online cookbook. It's not perfectly formatted but still useful, i hope. http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/361742 cheers, holger P.S: happy new year. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python evolution: Unease
Hi Roman, On Wed, Jan 05, 2005 at 00:44 +0300, Roman Suzi wrote: > Python could have honest support of concepts. Everything else will be > available with them. > > That is the whole point that Python supports GP. It is only one step > to do concepts right (and GvR it seems want type-checking into Python 3.0 > anyway), so support for concepts/concept checking is very logical, > isn't it? As an innocent by-dropper into this thread: a) do you know Armin Rigo's "semantic model" page dealing with concepts? http://arigo.tunes.org/semantic_models.html b) do you have some concise definition of what you mean by "concept"? Myself, i appreciate the combination of testing and python's flexibility so much that i don't long for type declarations, at least not to the degree that would warrant syntax additions. Now for interfaces, for me this references more a documentation issue than a syntax one: I'd like to have a full-featured runtime browser that allows to quickly navigate cross-referenced life python objects. Back and forth in execution time, preferably. This probably requires the interpreter to help, track and record more information (which is one of the possibilities with PyPy). It doesn't neccessarily require any new syntax though. And I don't really see the point of adding interface hierarchies to already large frameworks. To me this adds to - what i call - "naming complexity", i.e. the number of names a programmer needs to remember to deal with a library or framework. For me, it's not really the syntax that is the problem with interfaces in Zope3 or twisted, but the sheer amount of names (each indicating certain concepts and behaviours) i am confronted with. Not sure why i am saying all this here but have fun, holger -- http://mail.python.org/mailman/listinfo/python-list
Re: AttributeError of a module instance
On Mon, Dec 26, 2005 at 17:41 +, Paolino wrote: > I'd like to catch AttributeError on the module level,so that I can > declare default bindings for useds defore definition.How is this to be > done?Thanks for help. It cannot be done directly but with a small hack. This is the idea: import sys class A: def __getattr__(self,name): if name[:1] != '_': return name raise AttributeError(name) sys.modules['a'] = A() import a print a.helloworld # will print "helloworld" Note, that subsequently you can "import a" also from other modules because the import statement consults sys.modules. This is all a bit bothersome and thus it's often easier to just do "from somemod import a" directly and forget about the above magic. cheers, holger -- http://mail.python.org/mailman/listinfo/python-list
Re: parsing WSDL
>>>>> "Alessandro" == Alessandro Crugnola <[EMAIL PROTECTED]> writes: Alessandro> Is there a way, maybe using 4suite, to read a wsdl Alessandro> file and find for every method all the input/output Alessandro> params and their type? Have you had a look at the Python WS tools? They do have some sort of WSDL support, so I assume you could get the info from those classes. http://pywebsvcs.sf.net/ Holger -- http://mail.python.org/mailman/listinfo/python-list
How do I access avariable named "return"?
Hi,
I have a small problem: I have a WSDL file where different functions are
described. It worked perfectly until I have a function which has a
return-value named "return":
Here is my program:
--- cut here ---
from SOAPpy import WSDL
wsdlFile = 'mypbx.wsdl'
server = WSDL.Proxy(wsdlFile)
version=server.Version()
#print version.GatekeeperID # Works fine
#print version.FirmwareVersion # Works also
resp=server.Initialize(user="Wirtz, Holger - DFN-Verein",appl="PySOAP")
print resp
print resp.return
--- cut here ---
When the line "print resp.return" is comented out I got:
: {'return':
'221', 'key': '1424926643'}
But with the "print resp.return" I got:
File "pywsdl.py", line 10
print resp.return
^
SyntaxError: invalid syntax
I think this seems to be a problem due to the use of a forbidden word. But I
have no chance to change the WSDL definition, so: How can I get the
variable resp.return? Any suggestions?
Thanks, Holger
--
http://mail.python.org/mailman/listinfo/python-list
Re: How do I access avariable named "return"?
Brian Beck wrote: >> I think this seems to be a problem due to the use of a forbidden word. >> But I have no chance to change the WSDL definition, so: How can I get the >> variable resp.return? Any suggestions? > > To get it: getattr(resp, 'return') > To set it: setattr(resp, 'return', value) > > -- > Brian Beck > Adventurer of the First Order Ahhh! That's it! Thanks a lot!!! Holger -- http://mail.python.org/mailman/listinfo/python-list
Re: SOAP and XMLRPC
>>>>> "Daniel" == dcrespo <[EMAIL PROTECTED]> writes: Daniel> Someone knows if is there possible to have a Python SOAP Daniel> or XMLRPC server that works with VB? Sure, why not? What have you tried that didn't work? Getting SOAP libraries to interoperate is often a pain but usually possible unless you want to be able to have more than one type of library for clients. Daniel> My examples are: [...] Good. So you seem to have the Python side going. Are you asking in the Python group for help with VB? Or do you have a VB solution/attempt that you can't get your Python server to work with? In the former case I suggest you contact a VB group in the latter that you post infos on what you have tried already so we don't have to guess. As an additional pointer, I can tell you that I have had success with getting a PocketSOAP client to talk to a SoapPy server. You may want to give that a try. Holger -- http://mail.python.org/mailman/listinfo/python-list
Re: Release of PyPy 0.7.0
Hi Valentino, Michael, all, On Sun, Aug 28, 2005 at 20:46 +0200, Valentino Volonghi aka Dialtone wrote: > Michael Sparks <[EMAIL PROTECTED]> wrote: > > Would it be useful for people to start trying out their modules/code to see > > if they work with this release, and whether they can likewise be translated > > using the C/LLVM backends, or would you say this is too early? (I'm more > > thinking in terms of it providing real world usecases in the hope of > > finding things that don't work - rather than anything else) > > This is not how it works. Pypy doesn't translate your code to C/LLVM. > Currently PyPy can only translate a pretty simple subset of python > called RPython which has a very C-like syntax (but without memory > management code). This is needed to allow type inference inside the > interpreter code. This is mostly true but maybe a bit misleading. The subset of Python that we can translate does not involve special syntax. For example we can translate http://codespeak.net/pypy/dist/pypy/translator/goal/richards.py and gain some speed up by a factor of 70 over interpretation with CPython. The "RPython" limitation mainly refers to the way how dynamically you use Python and how unambigously your values flow across your functions and methods. Also you cannot, for example, create classes dynamically while creating instances is, of course, no problem. Also, we support all Python control flow statements. For a more detailed list, look at: http://codespeak.net/pypy/dist/pypy/doc/coding-guide.html#rpython-definition-not The real culprit is that we don't currently intend to try offering a tool that can automatically translate Python modules to C because we are still experimenting with and targeting our own Python interpreter and tackling the challenges that arise out of translating this efficiently. It's a matter of focus of the current dev group and not one of technical feasibility. If one or more people would want to care for producing, testing and documenting such a tool on top of our current code base then the next weeks might be good for that as we intend to go for some cleanup refactorings anyway. > The code in your application is application code and can be whatever you > want, you may try to translate it to C/LLVM but it won't be that good of > course because the annotator is not that intelligent. See above. You can try to translate python programs with a bit of effort and determination to find your way :-) > Just In Time compilation a-la-psyco is planned before the 1.0 release of > pypy. We don't have a fixed version roadmap but indeed, we plan to work on JIT compilation and other niceties rather soon now. cheers, holger -- http://mail.python.org/mailman/listinfo/python-list
Re: Pypy - Which C modules still need converting to py?
Hi Caleb, On Tue, Feb 08, 2005 at 22:32 -0500, Caleb Hattingh wrote: > I saw it on a webpage a few days ago, can't seem to find it again. Tried > a google search for > > "pypy needed translate C modules" > > but that didn't turn up what I was looking for. Anyone have that page > ref handy listing the C modules that the pypy team need translated into > python? I think that currently the best page for that actually is the compliancy test results page: http://codespeak.net/~hpk/pypy-testresult/ especially in the "non-core" section further below. You'll see a list of the currently not implemented C-level modules. However, most interesting is completing full posix/os-module support e.g. for listdir() and process-creation functionality. Also having a socket-API wrapper at RPython/low-level-function level and for e.g. 'zlib' seem like "big time" enablers for allowing more programs/modules to run on top of pypy-c/pypy-llvm. (we are employing a "pypy-XYZ" scheme where XYZ marks the backend). Recently, Niklaus Heidimann successfully implemented the array and _sre module as part of his SOC project, of which he got the latter to translate to low-level during the last Heidelberg sprint! cheers, holger -- http://mail.python.org/mailman/listinfo/python-list
Re: py.test anyone?
Hi Stephen, [Stephen Boulet Mon, Nov 22, 2004 at 11:14:57AM -0600] > Have people been using py.test? I was hoping to try it out but was > running into subversion problems (behind a corporate firewall, though > there is a windows registry hack for that which didn't work for me). you may try to use the svn apache instance at 8080 aka svn co http://codespeak.net:8080/svn/py/dist distpy Also please note that 'py.test' has not been released yet. I plan to release it beginning of next year after it received some more development and a big real-life integration into the PyPy project. Nevertheless, there is quite some documentation under the 'py.test' link found here: http://codespeak.net/py/current/doc/ there also is a "getting started" link which now incorporates the above ":8080" suggestion. have fun, holger -- http://mail.python.org/mailman/listinfo/python-list
Re: style query: function attributes for return codes?
Hi George,
[george young Fri, Dec 10, 2004 at 10:45:47AM -0500]
> [python 2.3.3, x86 linux]
> I recently found myself writing something like:
>
> def get_connection():
> if tcp_conn():
> if server_allows_conn():
> return 'good_conn'
> else:
> return 'bad_auth'
> else:
> return 'no_server'
>
> cn = get_connection()
> if cn == 'good_con': ...
>
>
> This is obviously just evil, since a misspelling in the string
> return is treacherous.
Right.
I usually like to look at such problems from the angle of
what is most convenient for the *caller* side?
And having to adress function attributes does
not seem convenient. I'd probably like to do from
the caller side something like:
conn = get_connection()
if conn.good:
...
elif conn.badauth:
...
elif conn.noserver:
...
which allows you to freely choose and hide your actual
implementation at the "called" side. Example:
class Connection(object):
def __init__(self, **kw):
for name in kw:
assert name in ('good', 'badauth', 'noserver'), name
setattr(self, name, kw[name])
def get_connection():
if tcp_conn():
if server_allows_conn():
return Connection(good=True)
else:
return Connection(badauth=True)
else:
return Connection(noserver=True)
And btw, the view of "what do i want at the caller side?"
is natural if you do test-driven development and actually
first write your tests. Another reason why testing is
a good thing :-)
cheers & HTH,
holger
--
http://mail.python.org/mailman/listinfo/python-list
Re: style query: function attributes for return codes?
[Reinhold Birkenfeld Fri, Dec 10, 2004 at 08:42:10PM +0100]
> holger krekel wrote:
> > class Connection(object):
> > def __init__(self, **kw):
> > for name in kw:
> > assert name in ('good', 'badauth', 'noserver'), name
> > setattr(self, name, kw[name])
> >
> > def get_connection():
> > if tcp_conn():
> > if server_allows_conn():
> > return Connection(good=True)
> > else:
> > return Connection(badauth=True)
> > else:
> > return Connection(noserver=True)
>
> That's evil, because "if conn.good" raises an AttributeError instead of
> evaluating to False if the connection is not good. You would have to
> inizialize all three attributes in every construction of a Connection
> object.
Ups, you are right of course. I somehow managed to delete the line ...
class Connection(object):
good = badauth = noserver = False
thanks for pointing it out.
holger
--
http://mail.python.org/mailman/listinfo/python-list
Re: [Distutils] Call for information - What assumptions can I make about Unix users' access to Windows?
On Sat, Nov 15, 2014 at 10:45 +, Paul Moore wrote: > On 7 November 2014 15:46, Paul Moore wrote: > > To that end, I'd like to get an idea of what sort of access to Windows > > a typical Unix developer would have. > > Thanks to all who contributed to this thread. > > Based on the feedback, I think it's going to be useful to provide two > options. First of all, an EC2 AMI that can be used by people without > access to a local Windows system. While other cloud providers are a > possibility, EC2 provides a free tier (for the first year) and is > well-known, so it's probably the easiest to get started with (at least > it was for me!) Also, I will provide a script that can be used to > automatically build the environment on a newly-installed machine. The > idea is that you can use this on a Windows VM (something that a number > of people have said they have access to). > > The script may be usable on an existing machine, but it's hard to make > it robust, as there are too many failure modes to consider (software > already installed, configuration and/or permission differences, etc). > So while such use may be possible, I probably won't consider it as > supported. Thanks Paul for going through this! Looking forward to the link/code. holger > Thanks again, > Paul > ___ > Distutils-SIG maillist - [email protected] > https://mail.python.org/mailman/listinfo/distutils-sig > -- https://mail.python.org/mailman/listinfo/python-list
Python 2.4.2 gcc 3.4.4 Solaris 8 build issues
Hi, I encountered some build issues when compiling Python 2.4.4 on a Solaris 8 box using gcc 3.4.4: 1. Running configure detects that a C++-built main needs C++-linking. Therefore, Python gets linked with g++, creating a dependency on libstdc++. Some research showed up a rather elaborate discussion in the python-dev/c++-sig-archives, ending up in a patch that replaces the --with-cxx option with a --with-cxx-main switch and tries to set CXX to some sensible value in the generated Makefile even if Python gets built C-only. (SF #1324762 Compiling and linking main() with C++ compiler, by Christoph Ludwig; pending) Now, I am still not 100 % sure about what I need to do. I need C++-extensions, but I do not want to link anything statically with Python, i.e. everything will be dynamically imported extension modules. I *think* I can build Python C-only, avoiding possible runtime problems with C++-extensions that might have been built with different C++ compilers. Can anyony clear that up? 2. We have some stuff in non-standard locations here. To build properly, I need to tell this to configure (using CXX, CPPFLAGS, LD_LIBRARY_PATH). Unfortunately, none of this gets communicated to the setup.py step with its find_library_file() stuff, so it is also necessary to either modify setup.py or add a setup.cfg file. Is there some better way to do that? (Probably the Makefile template could be changed to supply setup.py with some appropriate command line options for build_ext, but I do not know the autotools stuff. Any recommendations for some good tutorial?) 3. The test_locale test fails: ./python Lib/test/test_locale.py '%f' % 1024 =? '1,024.00' ... no '%f' % 1024 == '1024.00' != '1,024.00' '%f' % 102 =? '102.00' ... yes '%f' % -42 =? '-42.00' ... yes '%+f' % -42 =? '-42.00' ... yes '%20.f' % -42 =? ' -42' ... yes '%+10.f' % -4200 =? '-4,200' ... no '%+10.f' % -4200 == '-4200' != '-4,200' '%-10.f' % 4200 =? '4,200 ' ... no '%-10.f' % 4200 == '4200 ' != '4,200 ' ' '.isspace() =? True ... yes '\xa0'.isspace() =? False ... no '\xa0'.isspace() == True != False '\xa1'.isspace() =? False ... yes '\xc0'.isalpha() =? False ... no '\xc0'.isalpha() == True != False '\xc0'.isalnum() =? False ... no '\xc0'.isalnum() == True != False '\xc0'.isupper() =? False ... no '\xc0'.isupper() == True != False '\xc0'.islower() =? False ... yes '\xec\xa0\xbc'.split() =? ['\xec\xa0\xbc'] ... no '\xec\xa0\xbc'.split() == ['\xec', '\xbc'] != ['\xec\xa0\xbc'] '\xed\x95\xa0'.strip() =? '\xed\x95\xa0' ... no '\xed\x95\xa0'.strip() == '\xed\x95' != '\xed\x95\xa0' '\xcc\x85'.lower() =? '\xcc\x85' ... no '\xcc\x85'.lower() == '\xec\x85' != '\xcc\x85' '\xed\x95\xa0'.upper() =? '\xed\x95\xa0' ... no '\xed\x95\xa0'.upper() == '\xcd\x95\xa0' != '\xed\x95\xa0' ?? Is this a known problem on Solaris? Thanks in advance for any hints, Holger Der Inhalt dieser E-Mail ist vertraulich. Falls Sie nicht der angegebene Empfänger sind oder falls diese E-Mail irrtümlich an Sie adressiert wurde, verständigen Sie bitte den Absender sofort und löschen Sie die E-Mail sodann. Das unerlaubte Kopieren sowie die unbefugte Übermittlung sind nicht gestattet. Die Sicherheit von Übermittlungen per E-Mail kann nicht garantiert werden. Falls Sie eine Bestätigung wünschen, fordern Sie bitte den Inhalt der E-Mail als Hardcopy an. The contents of this e-mail are confidential. If you are not the named addressee or if this transmission has been addressed to you in error, please notify the sender immediately and then delete this e-mail. Any unauthorized copying and transmission is forbidden. E-Mail transmission cannot be guaranteed to be secure. If verification is required, please request a hard copy version. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 2.4.2 gcc 3.4.4 Solaris 8 build issues [solved]
>Martin v. Löwis wrote: > >> 2. We have some stuff in non-standard locations here. To build >> properly, I need to tell this to configure (using CXX, CPPFLAGS, >> LD_LIBRARY_PATH). Unfortunately, none of this > gets communicated to >> the setup.py step with its find_library_file() stuff, so it is also >> necessary to either modify setup.py or add a setup.cfg file. >Why do you say that? If you set CC before invoking configure, >it will get into Makefile, and from there into setup.py. >More generally: setup.py will take everything from Makefile, >so just check whether Makefile looks right. Hmm, I just got it wrong. I did not see that settings like LDFLAGS are noticed by distutils. After quite some tries I can now happily build with - LD_LIBRARY_PATH set (needed to find libstdc++ during configure step) - LDFLAGS set to find the lib dirs - CPPFLAGS set to find the include dirs Then distutils adds the appropriate -Wl,-R stuff; I don´t even need LD_RUN_PATH. Before, I seem to always have left out LDFLAGS. >As for LD_LIBRARY_PATH: If it is set when setup.py is running, >it will certainly apply. However, I really recommend to use >crle(8) instead: > > crle -u -l /opt/sfw/lib > >Then, your users will never have to set LD_LIBRARY_PATH >for /opt/sfw/lib. Nice. I didn´t even know that feature. Reminds me of the possibilty to use relative RPATHs with $ORIGIN, which is (also) little under-documented. But then again I´m no compiler wizard. >> Der Inhalt dieser E-Mail ist vertraulich. >So ein Quatsch. Selbst Google hat jetzt eine Kopie dieser Mail: Wie wahr. Schon mal gegen Windmühlen gekämpft? ;-) Thanks a lot, Holger Der Inhalt dieser E-Mail ist vertraulich. Falls Sie nicht der angegebene Empfänger sind oder falls diese E-Mail irrtümlich an Sie adressiert wurde, verständigen Sie bitte den Absender sofort und löschen Sie die E-Mail sodann. Das unerlaubte Kopieren sowie die unbefugte Übermittlung sind nicht gestattet. Die Sicherheit von Übermittlungen per E-Mail kann nicht garantiert werden. Falls Sie eine Bestätigung wünschen, fordern Sie bitte den Inhalt der E-Mail als Hardcopy an. The contents of this e-mail are confidential. If you are not the named addressee or if this transmission has been addressed to you in error, please notify the sender immediately and then delete this e-mail. Any unauthorized copying and transmission is forbidden. E-Mail transmission cannot be guaranteed to be secure. If verification is required, please request a hard copy version. -- http://mail.python.org/mailman/listinfo/python-list
call of __del__ non-deterministic in python 2.4 (cpython)?
Hi all, I've recently run into a problem that I haven't seen with python 1.5.2 and python 2.3. It seems that under certain conditions __del__ does not get immediately called when a local variable goes out of scope. I ended up with deadlocks in a threaded application because a locked section was supposed to be entered from within __del__ but apparently the same thread (the main thread, in that case) was already holding that lock. The result looked really strange with the main thread entering the locked section and then suddenly the delayed call of __del__ taking control, also wanting to acquire the lock but never being able to. Unfortunately I fail to put together a minimal example. Anyway: Is relying on __del__ getting called immediately when the refcount drops to 0 a no-no? If so should that maybe be prominently stated in the docs? Cheers, Holger Der Inhalt dieser E-Mail ist vertraulich. Falls Sie nicht der angegebene Empfänger sind oder falls diese E-Mail irrtümlich an Sie adressiert wurde, verständigen Sie bitte den Absender sofort und löschen Sie die E-Mail sodann. Das unerlaubte Kopieren sowie die unbefugte Übermittlung sind nicht gestattet. Die Sicherheit von Übermittlungen per E-Mail kann nicht garantiert werden. Falls Sie eine Bestätigung wünschen, fordern Sie bitte den Inhalt der E-Mail als Hardcopy an. The contents of this e-mail are confidential. If you are not the named addressee or if this transmission has been addressed to you in error, please notify the sender immediately and then delete this e-mail. Any unauthorized copying and transmission is forbidden. E-Mail transmission cannot be guaranteed to be secure. If verification is required, please request a hard copy version. -- http://mail.python.org/mailman/listinfo/python-list
[unicode] inconvenient unicode conversion of non-string arguments
Hi there, I consider the behaviour of unicode() inconvenient wrt to conversion of non-string arguments. While you can do: >>> unicode(17.3) u'17.3' you cannot do: >>> unicode(17.3, 'ISO-8859-1', 'replace') Traceback (most recent call last): File "", line 1, in ? TypeError: coercing to Unicode: need string or buffer, float found >>> This is somehow annoying when you want to convert a mixed-type argument list to unicode strings, e.g. for a logging system (that's where it bit me) and want to make sure that possible raw string arguments are also converted to unicode without errors (although by force). Especially as this is a performance-critical part in my application so I really do not like to wrap unicode() into some custom tounicode() function that handles such cases by distinction of argument types. Any reason why unicode() with a non-string argument should not allow the encoding and errors arguments? Or some good solution to work around my problem? (Currently running on python 2.4.3) Regards, Holger Der Inhalt dieser E-Mail ist vertraulich. Falls Sie nicht der angegebene Empfänger sind oder falls diese E-Mail irrtümlich an Sie adressiert wurde, verständigen Sie bitte den Absender sofort und löschen Sie die E-Mail sodann. Das unerlaubte Kopieren sowie die unbefugte Übermittlung sind nicht gestattet. Die Sicherheit von Übermittlungen per E-Mail kann nicht garantiert werden. Falls Sie eine Bestätigung wünschen, fordern Sie bitte den Inhalt der E-Mail als Hardcopy an. The contents of this e-mail are confidential. If you are not the named addressee or if this transmission has been addressed to you in error, please notify the sender immediately and then delete this e-mail. Any unauthorized copying and transmission is forbidden. E-Mail transmission cannot be guaranteed to be secure. If verification is required, please request a hard copy version. -- http://mail.python.org/mailman/listinfo/python-list
Re: Re: inconvenient unicode conversion of non-string arguments
[EMAIL PROTECTED] schrieb am 13.12.2006 11:02:30: > > Holger Joukl wrote: > > Hi there, > > > > I consider the behaviour of unicode() inconvenient wrt to conversion of > > non-string > > arguments. > > While you can do: > > > > >>> unicode(17.3) > > u'17.3' > > > > you cannot do: > > > > >>> unicode(17.3, 'ISO-8859-1', 'replace') > > Traceback (most recent call last): > > File "", line 1, in ? > > TypeError: coercing to Unicode: need string or buffer, float found > > >>> > > [...] > > Any reason why unicode() with a non-string argument should not allow the > > encoding and errors arguments? > > There is reason: encoding is a property of bytes, it is not applicable > to other objects. Ok, but I still don't see why these arguments shouldn't simply be silently ignored for non-string arguments. > > Or some good solution to work around my problem? > > Do not put undecoded bytes in a mixed-type argument list. A rule of > thumb working with unicode: decode as soon as possible, encode as late > as possible. It's not always that easy when you deal with a tree data structure with the tree elements containing different data types and your user may decide to output root.element.subelement.whateverData. I have the problems in a logging mechanism, and it would vanish if unicode(, encoding, errors) would work and just ignore the obsolete arguments. Best regards, Holger Der Inhalt dieser E-Mail ist vertraulich. Falls Sie nicht der angegebene Empfänger sind oder falls diese E-Mail irrtümlich an Sie adressiert wurde, verständigen Sie bitte den Absender sofort und löschen Sie die E-Mail sodann. Das unerlaubte Kopieren sowie die unbefugte Übermittlung sind nicht gestattet. Die Sicherheit von Übermittlungen per E-Mail kann nicht garantiert werden. Falls Sie eine Bestätigung wünschen, fordern Sie bitte den Inhalt der E-Mail als Hardcopy an. The contents of this e-mail are confidential. If you are not the named addressee or if this transmission has been addressed to you in error, please notify the sender immediately and then delete this e-mail. Any unauthorized copying and transmission is forbidden. E-Mail transmission cannot be guaranteed to be secure. If verification is required, please request a hard copy version. -- http://mail.python.org/mailman/listinfo/python-list
Re: Re: call of __del__ non-deterministic in python 2.4 (cpython)?
[EMAIL PROTECTED] schrieb am 13.12.2006 11:09:13: > Holger Joukl wrote: > > > Anyway: Is relying on __del__ getting called immediately when the refcount > > drops to 0 a no-no? > > yes, but more importantly, relying on the refcount dropping to 0 when > something goes out of scope is a major no-no. In my particular use case I think can rule out the problematic situations, except for the object being referenced in the stack trace, but that won't put me into problems (and there were no exceptions at all when I ran into the deadlocks) > > If so should that maybe be prominently stated in the docs? > > is it perhaps the color that made you miss the big bold boxes in the > documentation? > > http://docs.python.org/ref/customization.html#l2h-177 > > I did read this but didn't think it applied to my situation. I'm quite sure that the refcount of the local variable is 1 before the local scope is left. So let me rephrase the question: Even if I can make sure that non of the problematic situtions apply, might it _still_ happen that __del__ gets called after some other code has already been "entered"? Thanks, Holger Der Inhalt dieser E-Mail ist vertraulich. Falls Sie nicht der angegebene Empfänger sind oder falls diese E-Mail irrtümlich an Sie adressiert wurde, verständigen Sie bitte den Absender sofort und löschen Sie die E-Mail sodann. Das unerlaubte Kopieren sowie die unbefugte Übermittlung sind nicht gestattet. Die Sicherheit von Übermittlungen per E-Mail kann nicht garantiert werden. Falls Sie eine Bestätigung wünschen, fordern Sie bitte den Inhalt der E-Mail als Hardcopy an. The contents of this e-mail are confidential. If you are not the named addressee or if this transmission has been addressed to you in error, please notify the sender immediately and then delete this e-mail. Any unauthorized copying and transmission is forbidden. E-Mail transmission cannot be guaranteed to be secure. If verification is required, please request a hard copy version. -- http://mail.python.org/mailman/listinfo/python-list
Re: Re: inconvenient unicode conversion of non-string arguments
[EMAIL PROTECTED] schrieb am 13.12.2006 11:37:03: > Holger Joukl wrote: > > > Ok, but I still don't see why these arguments shouldn't simply be silently > > ignored > > >>> import this > > > You probably refer to "Explicit is better than implicit.". In that particular case I still think it wouldn't hurt to allow the encoding/errors arguments to keep the unicode() signature consistent for all types of the first argument. I'd go with "Although practicality beats purity." ;-) Holger (But maybe I'm not aware of tricky-implementation issues...) Der Inhalt dieser E-Mail ist vertraulich. Falls Sie nicht der angegebene Empfänger sind oder falls diese E-Mail irrtümlich an Sie adressiert wurde, verständigen Sie bitte den Absender sofort und löschen Sie die E-Mail sodann. Das unerlaubte Kopieren sowie die unbefugte Übermittlung sind nicht gestattet. Die Sicherheit von Übermittlungen per E-Mail kann nicht garantiert werden. Falls Sie eine Bestätigung wünschen, fordern Sie bitte den Inhalt der E-Mail als Hardcopy an. The contents of this e-mail are confidential. If you are not the named addressee or if this transmission has been addressed to you in error, please notify the sender immediately and then delete this e-mail. Any unauthorized copying and transmission is forbidden. E-Mail transmission cannot be guaranteed to be secure. If verification is required, please request a hard copy version. -- http://mail.python.org/mailman/listinfo/python-list
Re: Re: inconvenient unicode conversion of non-string arguments
[EMAIL PROTECTED] schrieb am 13.12.2006 12:05:33: > Holger Joukl wrote: > > >>> Ok, but I still don't see why these arguments shouldn't simply be > >>> silently ignored > >> > >> >>> import this > > > > You probably refer to "Explicit is better than implicit.". > > "Errors should never pass silently." is a better match, I think. you're > trying to do an invalid operation. python tells you to fix your code. > > I'm not doing an invalid operation with unicode(17.3) What's invalid about unicode(17.3, "latin-1", "replace")? IMHO the encoding/errors args can only ever apply for string arguments so this could well fall back to unicode(17.3). Might be I'm overlooking something grave, but I'm still not convinced. But thanks for your advice, Holger Der Inhalt dieser E-Mail ist vertraulich. Falls Sie nicht der angegebene Empfänger sind oder falls diese E-Mail irrtümlich an Sie adressiert wurde, verständigen Sie bitte den Absender sofort und löschen Sie die E-Mail sodann. Das unerlaubte Kopieren sowie die unbefugte Übermittlung sind nicht gestattet. Die Sicherheit von Übermittlungen per E-Mail kann nicht garantiert werden. Falls Sie eine Bestätigung wünschen, fordern Sie bitte den Inhalt der E-Mail als Hardcopy an. The contents of this e-mail are confidential. If you are not the named addressee or if this transmission has been addressed to you in error, please notify the sender immediately and then delete this e-mail. Any unauthorized copying and transmission is forbidden. E-Mail transmission cannot be guaranteed to be secure. If verification is required, please request a hard copy version. -- http://mail.python.org/mailman/listinfo/python-list
Re: Stupid email disclaimers (was: [unicode] inconvenient unicodeconversion of non-string arguments)
[EMAIL PROTECTED] schrieb am 13.12.2006 23:10:38: > [...] > In all likelihood, the OP isn't choosing specifically to attach it; > these things are often done to *every* outgoing message at an > organisational level by people who don't think the issue through very > well. > > http://goldmark.org/jeff/stupid-disclaimers/> That's exactly the case. > Please, those with such badly-configured systems, discuss the issue of > public discussion forums with the boneheads who think these disclaimer > texts are a good idea and at least try to change that behaviour. Believe me I've tried, in subtle and not-so-subtle ways. They won't change it, it's stupid and that's that. > Alternatively, post from some other mail system that doesn't slap > these obnoxious blocks onto your messages. I would but my browser environment is different from the rest so I can not copy source text or attach files to mails I could write via web mail. That would render mailing lists quite unusable for me. This is going to change soon, hopefully. So my apologies for the disclaimer but I an not do anything about it right now. Holger And now for another mighty stupid disclaimer ;-): Der Inhalt dieser E-Mail ist vertraulich. Falls Sie nicht der angegebene Empfänger sind oder falls diese E-Mail irrtümlich an Sie adressiert wurde, verständigen Sie bitte den Absender sofort und löschen Sie die E-Mail sodann. Das unerlaubte Kopieren sowie die unbefugte Übermittlung sind nicht gestattet. Die Sicherheit von Übermittlungen per E-Mail kann nicht garantiert werden. Falls Sie eine Bestätigung wünschen, fordern Sie bitte den Inhalt der E-Mail als Hardcopy an. The contents of this e-mail are confidential. If you are not the named addressee or if this transmission has been addressed to you in error, please notify the sender immediately and then delete this e-mail. Any unauthorized copying and transmission is forbidden. E-Mail transmission cannot be guaranteed to be secure. If verification is required, please request a hard copy version. -- http://mail.python.org/mailman/listinfo/python-list
[ann] first release of PyPy
Welcome to PyPy 0.6 *The PyPy Development Team is happy to announce the first public release of PyPy after two years of spare-time and half a year of EU funded development. The 0.6 release is eminently a preview release.* What it is and where to start - Getting started:http://codespeak.net/pypy/index.cgi?doc/getting_started.html PyPy Documentation: http://codespeak.net/pypy/index.cgi?doc PyPy Homepage: http://codespeak.net/pypy/ PyPy is a MIT-licensed reimplementation of Python written in Python itself. The long term goals are an implementation that is flexible and easy to experiment with and retarget to different platforms (also non-C ones) and such that high performance can be achieved through high-level implementations of dynamic optimisation techniques. The interpreter and object model implementations shipped with 0.6 can be run on top of CPython and implement the core language features of Python as of CPython 2.3. PyPy passes around 90% of the Python language regression tests that do not depend deeply on C-extensions. Some of that functionality is still made available by PyPy piggy-backing on the host CPython interpreter. Double interpretation and abstractions in the code-base make it so that PyPy running on CPython is quite slow (around 2000x slower than CPython ), this is expected. This release is intended for people that want to look and get a feel into what we are doing, playing with interpreter and perusing the codebase. Possibly to join in the fun and efforts. Interesting bits and highlights - The release is also a snap-shot of our ongoing efforts towards low-level translation and experimenting with unique features. * By default, PyPy is a Python version that works completely with new-style-classes semantics. However, support for old-style classes is still available. Implementations, mostly as user-level code, of their metaclass and instance object are included and can be re-made the default with the ``--oldstyle`` option. * In PyPy, bytecode interpretation and object manipulations are well separated between a bytecode interpreter and an *object space* which implements operations on objects. PyPy comes with experimental object spaces augmenting the standard one through delegation: * an experimental object space that does extensive tracing of bytecode and object operations; * the 'thunk' object space that implements lazy values and a 'become' operation that can exchange object identities. These spaces already give a glimpse in the flexibility potential of PyPy. See demo/fibonacci.py and demo/sharedref.py for examples about the 'thunk' object space. * The 0.6 release also contains a snapshot of our translation-efforts to lower level languages. For that we have developed an annotator which is capable of infering type information across our code base. The annotator right now is already capable of successfully type annotating basically *all* of PyPy code-base, and is included with 0.6. * From type annotated code, low-level code needs to be generated. Backends for various targets (C, LLVM,...) are included; they are all somehow incomplete and have been and are quite in flux. What is shipped with 0.6 is able to deal with more or less small/medium examples. Ongoing work and near term goals - Generating low-level code is the main area we are hammering on in the next months; our plan is to produce a PyPy version in August/September that does not need to be interpreted by CPython anymore and will thus run considerably faster than the 0.6 preview release. PyPy has been a community effort from the start and it would not have got that far without the coding and feedback support from numerous people. Please feel free to give feedback and raise questions. contact points: http://codespeak.net/pypy/index.cgi?contact contributor list: http://codespeak.net/pypy/index.cgi?doc/contributor.html have fun, Armin Rigo, Samuele Pedroni, Holger Krekel, Christian Tismer, Carl Friedrich Bolz PyPy development and activities happen as an open source project and with the support of a consortium funded by a two year EU IST research grant. Here is a list of partners of the EU project: Heinrich-Heine University (Germany), AB Strakt (Sweden) merlinux GmbH (Germany), tismerysoft GmbH(Germany) Logilab Paris (France), DFKI GmbH (Germany) ChangeMaker (Sweden) -- http://mail.python.org/mailman/listinfo/python-list
PyPy 0.6.1
Hi again, On Fri, May 20, 2005 at 23:38 +0200, holger krekel wrote: > The PyPy 0.6 release > has already been superseded by the PyPy 0.6.1 bug-fix release. We are temporarily not having access to that time machine and thus have to fix things the old way, unfortunately. But we are working on improving this situation. The bug is trivial enough: py.py crashes on string formatting the second time you run it. You can find the fixed packages and svn-locations here: Getting started: http://codespeak.net/pypy/index.cgi?doc/getting_started.html have fun & sorry for the inconvenience, holger krekel > *The PyPy Development Team is happy to announce the first > public release of PyPy after two years of spare-time and > half a year of EU funded development. The 0.6 release > is eminently a preview release.* > > What it is and where to start > - > > Getting started: > http://codespeak.net/pypy/index.cgi?doc/getting_started.html > > PyPy Documentation: http://codespeak.net/pypy/index.cgi?doc > > PyPy Homepage: http://codespeak.net/pypy/ > > PyPy is a MIT-licensed reimplementation of Python written in > Python itself. The long term goals are an implementation that > is flexible and easy to experiment with and retarget to > different platforms (also non-C ones) and such that high > performance can be achieved through high-level implementations > of dynamic optimisation techniques. > > The interpreter and object model implementations shipped with 0.6 can > be run on top of CPython and implement the core language features of > Python as of CPython 2.3. PyPy passes around 90% of the Python language > regression tests that do not depend deeply on C-extensions. Some of > that functionality is still made available by PyPy piggy-backing on > the host CPython interpreter. Double interpretation and abstractions > in the code-base make it so that PyPy running on CPython is quite slow > (around 2000x slower than CPython ), this is expected. > > This release is intended for people that want to look and get a feel > into what we are doing, playing with interpreter and perusing the > codebase. Possibly to join in the fun and efforts. > > Interesting bits and highlights > - > > The release is also a snap-shot of our ongoing efforts towards > low-level translation and experimenting with unique features. > > * By default, PyPy is a Python version that works completely with > new-style-classes semantics. However, support for old-style classes > is still available. Implementations, mostly as user-level code, of > their metaclass and instance object are included and can be re-made > the default with the ``--oldstyle`` option. > > * In PyPy, bytecode interpretation and object manipulations > are well separated between a bytecode interpreter and an > *object space* which implements operations on objects. > PyPy comes with experimental object spaces augmenting the > standard one through delegation: > > * an experimental object space that does extensive tracing of > bytecode and object operations; > > * the 'thunk' object space that implements lazy values and a 'become' > operation that can exchange object identities. > > These spaces already give a glimpse in the flexibility potential of > PyPy. See demo/fibonacci.py and demo/sharedref.py for examples > about the 'thunk' object space. > > * The 0.6 release also contains a snapshot of our translation-efforts > to lower level languages. For that we have developed an > annotator which is capable of infering type information > across our code base. The annotator right now is already > capable of successfully type annotating basically *all* of > PyPy code-base, and is included with 0.6. > > * From type annotated code, low-level code needs to be generated. > Backends for various targets (C, LLVM,...) are included; they are > all somehow incomplete and have been and are quite in flux. What is > shipped with 0.6 is able to deal with more or less small/medium examples. > > > Ongoing work and near term goals > - > > Generating low-level code is the main area we are hammering on in the > next months; our plan is to produce a PyPy version in August/September > that does not need to be interpreted by CPython anymore and will > thus run considerably faster than the 0.6 preview release. > > PyPy has been a community effort from the start and it would > not have got that far without the coding and feedback support > from numerous people. Please fee
Re: first release of PyPy
On Sun, May 22, 2005 at 19:18 +0200, ionel wrote: > this is interesting > anyway i'm to lazy to read so i'll just ask: > can PyPy at the current state of develepment help me improve my python > programs? (speed) no, it can't at this stage. You might check out Psyco, the specializing compiler for Python: http://psyco.sf.net holger -- http://mail.python.org/mailman/listinfo/python-list
Re: first release of PyPy
Hi Kay, On Mon, May 23, 2005 at 13:39 -0700, Kay Schluehr wrote: > Does it mean You create an RPython object that runs on top of CPython, > but is just an RPython facade wrapped around a CPython object? So You > have four kinds of Pythons: > > RPy - translateable into LL code > APy - non-translateable but interpretable by translated RPy > RPy* - non-translateable but consistent interface with RPy. Calls > APy* > APy* - not translateable and not interpreteable by translated RPy > > "Selfhosting" would imply vanishing RPy* and APy*. But the problem > seems to be that selfhosting must somehow be broken because the system > needs to interact with OS-dependend librarys. As long as You run the > system upon CPython the problem does not occur but once You drop it, a > kind of "extension objectspace" must be created which is translated > into code with nice interfacing properties. You are mostly right but 'extension objectspace' is misleading. Object Spaces are only responsible for manipulating Python application objects. To get rid of 'faked' objects we need implementations for IO access and operating system interactions. Those can sometimes even be written in pure python (applevel) as is the case for a preliminary version of a file object. > RPython translations will be sufficient and another ext-objectspace is > just useless epi-cycling? Conceptually, we need a good concept to perform foreign function invocation (FFI) much like ctypes or other approaches do. However, concretely, we might at first just write some very low-level code (even lower level than RPython) to interact with os-level APIs and weave that into the translation process. This is an area we are beginning to explore in more depth currently. cheers, holger -- http://mail.python.org/mailman/listinfo/python-list
Re: Re: XML + SOAP + Webservices
Hi there, just about now I´ve started to write a little howto for the first steps with a python ZSI-based webservice to be consumed from C++ clients (gSOAP) and an Excel XP spreadsheet. More or less I am just documenting what I did, and I am by no means an expert on the subject, but still...might be helpful to you. I can probably post the first part this afternoon or tomorrow morning (will not be finished by then). Meanwhile, you might also want to check out the pywebsvcs mailing list on sourceforge. Cheers, H. Der Inhalt dieser E-Mail ist vertraulich. Falls Sie nicht der angegebene Empfänger sind oder falls diese E-Mail irrtümlich an Sie adressiert wurde, verständigen Sie bitte den Absender sofort und löschen Sie die E-Mail sodann. Das unerlaubte Kopieren sowie die unbefugte Übermittlung sind nicht gestattet. Die Sicherheit von Übermittlungen per E-Mail kann nicht garantiert werden. Falls Sie eine Bestätigung wünschen, fordern Sie bitte den Inhalt der E-Mail als Hardcopy an. The contents of this e-mail are confidential. If you are not the named addressee or if this transmission has been addressed to you in error, please notify the sender immediately and then delete this e-mail. Any unauthorized copying and transmission is forbidden. E-Mail transmission cannot be guaranteed to be secure. If verification is required, please request a hard copy version. -- http://mail.python.org/mailman/listinfo/python-list
Re: XML + SOAP + Webservices
This may be of some help for you. It´s unfinished business, though.
So far, the ZSI stuff has worked quite well for me, but as mentioned I am
also a web services beginner.
I am writing this in lyx so I might be able to post in other formats. For
the time being, this is
the first part in pure text.
Cheers,
Holger
>>>
Interoperable WSDL/SOAP web services introduction: Python ZSI , Excel
XP & gSOAP C/C++
Holger Joukl
LBBW Financial Markets Technologies
Abstract
Despite the hype & buzzword-storm, building web services servers and
clients still is no piece of cake. This is partly due to the relative
newness of technology. For the most part, though, this results from
the actual complexness of the protocols/specs, the toolkit magic
behind which this complexness is hidden, and the documentation gaps
that exist for the toolkits. This document is intended to be an
example-loaded simple tutorial, to ease the use for web services
newcomers (like I am one).
It features the Python ZSI module that is used to build the server
side machinery and clients that access the exposed services from
Python, MS Excel XP, and C/C++ using gSOAP.
Copyright © 2005 Holger Joukl. All rights reserved.
Redistribution and use in source (LyX, LaTeX) and 'compiled' forms
(SGML, HTML, PDF, PostScript, RTF and so forth) with or without
modification, are permitted provided that the following conditions are met:
1. Redistributions of source code (LyX, LaTeX) must retain the above
copyright notice, this list of conditions and the following
disclaimer as the first lines of this file unmodified.
2. Redistributions in compiled form (transformed to other DTDs,
converted to PDF, PostScript, RTF and other formats) must reproduce
the above copyright notice, this list of conditions and the
following disclaimer in the documentation and/or other materials
provided with the distribution.
THIS DOCUMENTATION IS PROVIDED "AS IS" AND ANY EXPRESS OR IMPLIED
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
IN NO EVENT SHALL THE FREEBSD DOCUMENTATION PROJECT BE LIABLE FOR ANY
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER
IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION,
EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
1 Introduction
We assume the reader is familiar with Python, C/C++ and MS
Excel/VisualBasic. While some basic concepts regarding WSDL, SOAP,
HTTP servers etc. might be touched this document is NOT a tutorial on
these. If you want to know more there´s plenty of stuff on the web.
Please note that currently, throughout most examples, certain host
names and ports are used - substitute them with the setup for your site..
Versions used:
* Python 2.3
* PyXML 0.8.3
* ZSI 1.6.1
* ...
To Describe: WS-I, rpc/literal
2 The SquareService
This first example will implement a service that exposes a function
which takes a double argument and returns the square of it (
x{}^{\textrm{2}} ) as a
double. I.e. this examples uses simple scalar datatypes, one single
argument and one single return value.
2.1 The SquareService WSDL
This is the WSDL file that determines the contract for the
SquareService, called SquareService.wsdl:
http://dev-b.handel-dev.local:8080/SquareService";
xmlns:tns="http://dev-b.handel-dev.local:8080/SquareService";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/";
xmlns="http://schemas.xmlsoap.org/wsdl/";>
the square method
http://schemas.xmlsoap.org/soap/http"/>
http://dev-b.handel-dev.local:8080/SquareService"/>
http://dev-b.handel-dev.local:8080/SquareService"/>
Returns x^2 (x**2, square(x)) for a given float
x
http://dev-b.handel-dev.local:8080/SquareService"/>
Comments:
* The style "rpc" and the use "literal" are used, to be WS-I-compliant.
WS-I only supports rpc/literal and document/literal.
2.2 A Python ZSI server for the SquareService
The Python ZSI package [key-1] is one of two pywebsvcs packages
implementing
web services for Python, namely SOAP messaging and WSDL capabilities.
It is powerful and very easy to get started with, but lacks some
documentation enhancements when it comes to WSDL-driven servic
Re: multiline regular expression (replace)
Hi,
yes:
import re
a="""
I Am
Multiline
but short anyhow"""
b="(I[\s\S]*line)"
print re.search(b, a,re.MULTILINE).group(1)
gives
I Am
Multiline
Be aware that . matches NO newlines!!!
May be this caused your problems?
regards
Holger
Zdenek Maxa wrote:
> [EMAIL PROTECTED] wrote:
>> On May 29, 2:03 am, Zdenek Maxa <[EMAIL PROTECTED]> wrote:
>>
>>> Hi all,
>>>
>>> I would like to perform regular expression replace (e.g. removing
>>> everything from within tags in a XML file) with multiple-line pattern.
>>> How can I do this?
>>>
>>> where = open("filename").read()
>>> multilinePattern = "^ <\/tag>$"
>>> re.search(multilinePattern, where, re.MULTILINE)
>>>
>>> Thanks greatly,
>>> Zdenek
>>>
>>
>> Why not use an xml package for working with xml files? I'm sure
>> they'll handle your multiline tags.
>>
>> http://effbot.org/zone/element-index.htm
>> http://codespeak.net/lxml/
>>
>> ~Sean
>>
>>
>
> Hi,
>
> that was merely an example of what I would like to achieve. However, in
> general, is there a way for handling multiline regular expressions in
> Python, using presumably only modules from distribution like re?
>
> Thanks,
> Zdenek
--
http://mail.python.org/mailman/listinfo/python-list
PyPy trillke sprints (Feb/March 2007)
= PyPy Trillke "EU and beyond!" sprints (25-28th Feb, 1-5th March 2006) = ..image:: http://www.trillke.net/images/HausPanorama0304_113kb.jpg Some two years and some thousands of commits later, the EU project period of the PyPy (http://codespeak.net/pypy) project is about to close ... and a new period to begin: we are going for a sprint of three days of focusing on EU reports and administrative issues, and another three day sprint of happy hacking on the numerous interesting open ends of PyPy, the source code. We also intend to discuss and state our view on the time after the EU period (March 2007 is the last EU funded month), because clearly the project will not stop after our successful (knock knock!) completion of the EU project. It's already clear that some of us seriously plan for a relaxation time, i.e. one without having many obligations. But that should not keep us from thinking and envisioning the development from April on. So to the Sprint: we have two parts of the sprint, first the EU and second the public all-invited part:: 26th Feb - 28th Feb EU reports and adminstrative sprint 1st March break day / arrival for coding sprint 2nd March - 4th March public coding "beyond EU" sprint days All days are meant as full days, so please arrive 25th Feb / 1st March and leave 5th March if you can (this help us with pairing, introductions and logistical planning). - Possible Topics for the coding sprint - * working on .NET, Java and other backends * working on the Javascript, Prolog or a new frontend * Tuning the JIT, refining approaches `[1]`_ * Fixing PyPy-1.0 problems / improving it (PyPy-1.0 is scheduled for Mid February, btw) * improving the py lib/py.test, build environments, preparing for server administration efforts from April on * Work on/with prototypes that use the new features that PyPy enables: distribution `[2]`_ (based on transparent proxying `[3]`_), security `[4]`_, persistence `[5]`_, etc. `[6]`_. * discussion about the time after March, and how to organize/co-ordinate ourselves * all topics that are of interest otherwise (including maybe working on some particular EU related topics still!) .. _[1]: http://codespeak.net/pypy/dist/pypy/doc/jit.html .. _[2]: http://codespeak.net/svn/pypy/dist/pypy/lib/distributed/ .. _[3]: http://codespeak.net/pypy/dist/pypy/doc/proxy.html .. _[4]: http://codespeak.net/pypy/dist/pypy/doc/project-ideas.html#security .. _[5]: http://codespeak.net/pypy/dist/pypy/doc/project-ideas.html#persistence .. _[6]: http://codespeak.net/pypy/dist/pypy/doc/project-ideas.html --- Location --- The sprint takes place at the Trillke Gut Steinbergstr. 42 Hildesheim, Germany http://www.trillke.net If you come to Hildesheim main station, take the Bus Number 3 (Hildesheimer Wald) and get out at "Waldquelle". Walking back a 100 meters gets you to a small street on the right leading to a big white building, the Trillke Gut. We'll have at least one larger room for sprinting, and a kitchen for our use. --- Accomodation --- We can probably arrange for some cheap or no-cost private accomodation, in private rooms located up in the house (and being part of "living groups" of 5-10 people). There also is a nice Guest house that has been used during recent events: http://www.gaestehaus-klocke.de/ and a four-star hotel 500 meters away from the Trillke: http://www.berghoelzchen.de/ --- Registration --- please subscribe to the pypy-sprint mailing list http://codespeak.net/mailman/listinfo/pypy-sprint and register by subversion: http://codespeak.net/svn/pypy/extradoc/sprintinfo/trillke-2007/people.txt or - if you have no checkin-rights - post to the pypy-sprint list above. -- merlinux GmbH Steinbergstr. 4231139 Hildesheim http://merlinux.de tel +49 5121 20800 75 (fax 77) -- http://mail.python.org/mailman/listinfo/python-list
ANN: py lib 0.9.0: py.test, distributed execution, microthreads ...
py lib 0.9.0: py.test, distributed execution, greenlets and more
==
Welcome to the 0.9.0 py lib release - a library aiming to
support agile and test-driven python development on various levels.
Main API/Tool Features:
* py.test: cross-project testing tool with many advanced features
* py.execnet: ad-hoc code distribution to SSH, Socket and local sub processes
* py.magic.greenlet: micro-threads on standard CPython ("stackless-light")
* py.path: path abstractions over local and subversion files
* rich documentation of py's exported API
* tested against Linux, OSX and partly against Win32, python 2.3-2.5
All these features and their API have extensive documentation,
generated with the new "apigen", which we intend to make accessible
for other python projects as well.
Download/Install: http://codespeak.net/py/0.9.0/download.html
Documentation/API: http://codespeak.net/py/0.9.0/index.html
Work on the py lib has been partially funded by the
European Union IST programme and by http://merlinux.de
within the PyPy project.
best, have fun and let us know what you think!
Holger Krekel, Maciej Fijalkowski,
Guido Wesdorp, Carl Friedrich Bolz
--
http://mail.python.org/mailman/listinfo/python-list
execnet-1.0.1: more robust and rapid python deployment
Hi everybody,
Just uploaded execnet-1.0.1 featuring a new motto:
execnet is about rapid-python deployment, be it for
multiple CPUs, different platforms or python versions.
This release brings a bunch of refinements and most
importantly more robust termination, handling of CTRL-C
and automatically tested documentation::
http://codespeak.net/execnet
have fun,
holger
1.0.1
- revamp and better structure documentation
- new method: gateway.hasreceiver() returns True
if the gateway is still receive-active. remote_status
now only carries information about remote execution status.
- new: execnet.MultiChannel provides basic iteration/contain interface
- new: execnet.Group can be indexed by integer
- new: group.makegateway() uses group.default_spec if no spec is given
and the execnet.default_group uses ``popen`` as a default spec.
- have popen-gateways use imports instead of source-strings,
also improves debugging/tracebacks, as a side effect
popen-gateway startup can be substantially faster (>30%)
- refine internal gateway exit/termination procedure
and introduce group.terminate(timeout) which will
attempt to kill all subprocesses that did not terminate
within time.
- EOFError on channel.receive/waitclose if the other
side unexpectedly went away. When a gateway exits
it now internally sends an explicit termination message
instead of abruptly closing.
- introduce a timeout parameter to channel.receive()
and default to periodically internally wake up
to let KeyboardInterrupts pass through.
- EXECNET_DEBUG=2 will cause tracing to go to stderr,
which with popen slave gateways will relay back
tracing to the instantiator process.
1.0.0
* introduce execnet.Group for managing gateway creation
and termination. Introduce execnet.default_group through which
all "global" calls are routed. cleanup gateway termination.
All Gateways get an id through which they can be
retrieved from a group object.
* deprecate execnet.XYZGateway in favour of direct makegateway() calls.
* refine socketserver-examples, experimentally introduce a
way to indirectly setup a socket server ("installvia")
through a gateway url.
* refine and automatically test documentation examples
1.0.0b3
* fix EXECNET_DEBUG to work with win32
* add support for serializing longs, sets and frozensets (thanks
Benjamin Peterson)
* introduce remote_status() method which on the low level gives
information about the remote side of a gateway
* disallow explicit close in remote_exec situation
* perform some more detailed tracing with EXECNET_DEBUG
1.0.0b2
* make internal protocols more robust against serialization failures
* fix a seralization bug with nested tuples containing empty tuples
(thanks to ronny for discovering it)
* setting the environment variable EXECNET_DEBUG will generate per
process trace-files for debugging
1.0.0b1
* added new examples for NumPy, Jython, IronPython
* improved documentation
* include apipkg.py for lazy-importing
* integrated new serializer code from Benjamin Peterson
* improved support for Jython-2.5.1
1.0.0alpha2
* improve documentation, new website
* use sphinx for documentation, added boilerplate files and setup.py
* fixes for standalone usage, adding boilerplate files
* imported py/execnet and made it work standalone
--
http://mail.python.org/mailman/listinfo/python-list
py.test-1.2.0: junitxml, standalone test scripts, pluginization
Hi all,
i just released some bits related to automated testing with Python:
py-1.2.0: py.test core which grew junitxml, standalone-script generation
pytest-xdist-1.0: separately installable dist-testing & looponfailing plugin
pytest-figleaf-1.0: separately installable figleaf-coverage testing plugin
See below or at this URL for the announcement:
http://pylib.org/announce/release-1.2.0.html
If you didn't experience much speed-up or previously had problems with
distributed testing i recommend you try to install "pytest-xdist" now and see
if it works better. For me it speeds up some tests runs by 500% on a 4 CPU
machine due to its better internal model and several fixes. (It's five
times because several tests depend on IO and don't block CPU meanwhile).
Another tip: if you use "pip" (best with a virtualenv) you can do e.g.:
pip install pytest-xdist
pip uninstall pytest-xdist
to conveniently activate/deactivate plugins for py.test. easy_install
works ok as well but has no uninstall, yet remains the only option
for installing with Python3 at the moment, though. You need to use
the fine 'distribute' project's easy_install for the latter.
cheers & have fun,
holger
py.test/pylib 1.2.0: junitxml, standalone test scripts, pluginization
py.test is an advanced automated testing tool working with
Python2, Python3 and Jython versions on all major operating
systems. It has a simple plugin architecture and can run many
existing common Python test suites without modification. It offers
some unique features not found in other testing tools.
See http://pytest.org for more info.
py.test 1.2.0 brings many bug fixes and interesting new abilities:
* --junitxml=path will create an XML file for use with CI processing
* --genscript=path creates a standalone py.test-equivalent test-script
* --ignore=path prevents collection of anything below that path
* --confcutdir=path only lookup conftest.py test configs below that path
* a 'pytest_report_header' hook to add info to the terminal report header
* a 'pytestconfig' function argument gives direct access to option values
* 'pytest_generate_tests' can now be put into a class as well
* on CPython py.test additionally installs as "py.test-VERSION", on
Jython as py.test-jython and on PyPy as py.test-pypy-XYZ
Apart from many bug fixes 1.2.0 also has better pluginization:
Distributed testing and looponfailing testing now live in the
separately installable 'pytest-xdist' plugin. The same is true for
'pytest-figleaf' for doing coverage reporting. Those two plugins
can serve well now as blue prints for doing your own.
thanks to all who helped and gave feedback,
have fun,
holger krekel, January 2010
Changes between 1.2.0 and 1.1.1
=
- moved dist/looponfailing from py.test core into a new
separately released pytest-xdist plugin.
- new junitxml plugin: --junitxml=path will generate a junit style xml file
which is processable e.g. by the Hudson CI system.
- new option: --genscript=path will generate a standalone py.test script
which will not need any libraries installed. thanks to Ralf Schmitt.
- new option: --ignore will prevent specified path from collection.
Can be specified multiple times.
- new option: --confcutdir=dir will make py.test only consider conftest
files that are relative to the specified dir.
- new funcarg: "pytestconfig" is the pytest config object for access
to command line args and can now be easily used in a test.
- install 'py.test' and `py.which` with a ``-$VERSION`` suffix to
disambiguate between Python3, python2.X, Jython and PyPy installed versions.
- new "pytestconfig" funcarg allows access to test config object
- new "pytest_report_header" hook can return additional lines
to be displayed at the header of a test run.
- (experimental) allow "py.test path::name1::name2::..." for pointing
to a test within a test collection directly. This might eventually
evolve as a full substitute to "-k" specifications.
- streamlined plugin loading: order is now as documented in
customize.html: setuptools, ENV, commandline, conftest.
also setuptools entry point names are turned to canonical namees ("pytest_*")
- automatically skip tests that need 'capfd' but have no os.dup
- allow pytest_generate_tests to be defined in classes as well
- deprecate usage of 'disabled' attribute in favour of pytestmark
- deprecate definition of Directory, Module, Class and Function nodes
in conftest.py files. Use pytest collect hooks instead.
- collection/item node specific runtest/collect hooks are only called exactly
on matching conftest.py files, i.e. ones which
Re: Writing an assembler in Python
Giorgos Tzampanakis wrote: > I'm implementing a CPU that will run on an FPGA. I want to have a > (dead) simple assembler that will generate the machine code for > me. I want to use Python for that. Are there any libraries that > can help me with the parsing of the assembly code? Why coding assembler if you can type in hexdumps... scnr Holger -- http://www.kati-und-holger.de/holgersblog.php -- http://mail.python.org/mailman/listinfo/python-list
detect endianness of a binary with python
Hi all, I use python 2.5 and I am looking for a possibility to determine a file type. Especially the endianness of a file is needed for me. Is there a way to detect this easily in python? Something like the "file" utility for linux would be very helpfull. Any help is appreciated. Best regards Holger Brunck -- http://mail.python.org/mailman/listinfo/python-list
Re: detect endianness of a binary with python
>> Something like the "file" utility for linux would be very helpfull.
>>
>> Any help is appreciated.
>You're going to have to describe in detail what's in the file before
>anybody can help.
We are creating inside our buildsystem for an embedded system a cram filesystem
image. Later on inside our build process we have to check the endianness,
because it could be Little Endian or big endian (arm or ppc).
The output of the "file" tool is for a little endian cramfs image:
: Linux Compressed ROM File System data, little endian size 1875968
version #2 sorted_dirs CRC 0x8721dfc0, edition 0, 462 blocks, 10 files
It would be possible to execute
ret = os.system("file | grep "little endian")
and evaluate the return code.
But I don't like to evaluate a piped system command. If there is an way without
using the os.system command this would be great.
Best regards
Holger
--
http://mail.python.org/mailman/listinfo/python-list
pylib/py.test 1.0.0 released
Hello everyone,
i am happy to announce pylib/py.test 1.0.0, a MIT-licensed
library geared towards advanced testing and elastic distributed
programming with Python. It features the mature cross-project
py.test automated testing tool with many new features, aiming to:
* allow writing zero-boilerplate automated tests in Python
* offer strong debugging and reporting of test failures
* rapidly run and ad-hoc distribute tests to multiple CPUs/platforms
* support unit-, functional and integration testing
* be easy to extend and tackle growing testing needs,
(current prime example oejskit, a live-browser javascript
unittesting 3rd party plugin)
Please check things out at: http://pytest.org or read the blogged
release announcement:
http://tetamap.wordpress.com/2009/08/04/pylib-1-0-0
or read on for some ...
Distinctive new features shipping with py.test 1.0.0
--
For those already knowing about the older 0.9.2 release or
being experienced with other testing approaches i'll try to
give a summary of the distinctive testing features
shipping with 1.0.0:
* test function arguments ("funcargs"): With this, python test
functions can name arguments and one writes factory functions to
provide instances for such "fixture" arguments. This page
http://codespeak.net/py/dist/test/funcargs.html
contains reference info and tutorial examples.
Test function arguments also allow for natural test parametrization -
one provides several different argument values,
no changes to the test function needed, no magic "yield" for
generating tests anymore - although 1.0 still allows them and
of course still supports traditional xUnit-style setup_module/class/function
or (new) direct runs of unittest.TestCase style tests.
* distributed testing: distributing test runs among Linux/OSX/Windows
hosts and across python-2.4 till python-2.6 interpreters
works reasonably stable now. This means that you can easily
iron out test-module/function specific problems across a
variety of platforms, accelerating the change & test feedback cycle.
* xfail: a new way to mark tests as "expected to fail" which
means they run normally but are reported/counted specially.
This "xfail" mark is meant to mark missing / wrong implementation
rather than missing dependencies / wrong platforms for which one
uses "skip". Especially for larger test suites making
this distinction is very helpful.
* IO-capturing: output of test functions is captured per-test,
by default including any output from sub processes.
This works on all platforms and also (now) interacts well
with the logging module without importing/using it itself so
there are no interferences.
* pastebin: new command line option "--pastebin" to send your test
session output or individual test failures to the Pocoo pastebin
service and prints out URLs. Convenient for quick IRC/messaging
communication.
* plugins: it is now easy to write plugins by implementing one
or more of the 37 hooks which py.test calls to implement
the testing process. There are many examples, among them
the "oejskit" plugin which integrates testing of javascript
code in real-life browsers into a regular test run.
Apart from such separately distributed "cross-project" plugins
you can also write per-project plugins/extensions that lives
with your testing code.
cheers & have fun,
holger
--
Metaprogramming, Python, Testing: http://tetamap.wordpress.com
Python, PyPy, pytest contracting: http://merlinux.eu
--
http://mail.python.org/mailman/listinfo/python-list
