Re: isatty() for file-like objects: Implement or not?
HOWARD GOLDEN wrote: > The standard documentation for isatty() says: > > "Return True if the file is connected to a tty(-like) device, else > False. Note: If a file-like object is not associated with a real file, > this method should not be implemented." > > In his book, "Text Processing in Python," David Mertz says: "... > implementing it to always return 0 is probably a better approach." > > My reaction is to agree with Mertz. I agree, I think the doc is wrong, e.g. StringIO has isatty() which returns False. I think the doc was probably a thinko (or things have changed) since Guido checked it in over 3 years ago. It would be great if you can provide a patch or at least a bug report on SourceForge. Thanks, n -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 2.4.2 HPUX-PARISC compile issues
[EMAIL PROTECTED] wrote: > When compiling HPUX for PARISC with the following environemnt variables > I get the following errors. > > CFLAGS=+DD64 -fast > CC=aCC > LDFLAGS=+DD64 > > What do I need to do in order to get this to compile? This info should be in the README file for 2.4.2: + To build a 64-bit executable on an Itanium 2 system using HP's + compiler, use these environment variables: + + CC=cc + CXX=aCC + BASECFLAGS="+DD64" + LDFLAGS="+DD64 -lxnet" + + and call configure as: + + ./configure --without-gcc Did you do that? If so, you will probably have to track this down. LONG_BIT is supposed to be there according to POSIX AFAIK. It would mean the wrong header file wasn't included (unlikely) or that some #define prevented it from being defined (more likely). Good luck, n -- http://mail.python.org/mailman/listinfo/python-list
Re: Idle bytecode query on apparently unreachable returns
Tom Anderson wrote: > Evening all, > > Here's a brief chat with the interpretator: [snip] > What puzzles me, though, are bytecodes 17, 39 and 42 - surely these aren't > reachable? Does the compiler just throw in a default 'return None' > epilogue, with routes there from every code path, even when it's not > needed? If so, why? I think the last RETURN_VALUE (None) isn't thrown in unless there is some sort of conditional the precedes it as in this example. As to why: it's easier and no one has done anything about fixing it. If you (or anyone else) are interested, the code is in Python/compile.c. Search for the optimize_code() function. n -- http://mail.python.org/mailman/listinfo/python-list
Re: Python reliability
Ville Voipio wrote: > > The software should be running continously for > practically forever (at least a year without a reboot). > Is the Python interpreter (on Linux) stable and > leak-free enough to achieve this? Jp gave you the answer that he has done this. I've spent quite a bit of time since 2.1 days trying to improve the reliability. I think it has gotten much better. Valgrind is run on (nearly) every release. We look for various kinds of problems. I try to review C code for these sorts of problems etc. There are very few known issues that can crash the interpreter. I don't know of any memory leaks. socket code is pretty well tested and heavily used, so you should be in fairly safe territory, particularly on Unix. n -- http://mail.python.org/mailman/listinfo/python-list
Re: Can module access global from __main__?
Steve Holden wrote: > Neal Becker wrote: > > > > Still curious about the answer. If I know that I am imported from __main__, > > then I can do access X as sys.modules[__main__].X. In general, I don't > > know how to determine who is importing me. > > > I don't think you can without huge amounts of introspection - it's even > worse than the "what's the name of this object" question that seems to > come up regularly. import sys frame = sys._getframe() caller = frame.f_back print 'Called from', caller.f_code.co_filename, caller.f_lineno # for more info, look into the traceback module > A module can be imported from multiple modules, and > you only get to execute code on the first import. > Even then (on the first import) I am not sure how you could introspect > to find the answer you want. You can install your own __import__() hook to catch all imports. Just because you can do something, it doesn't follow that you should do it, especially in this case. Unless you really, really need these tricks, they shouldn't be used. n -- http://mail.python.org/mailman/listinfo/python-list
Re: python interpreter
g.franzkowiak wrote: > Hi everybody, > > my interest is for the internals of the Python interpreter. > > I've used up to now FORTH for something and this indirect interpreter is > very smart. > --- ASM --- > > Where can I find informations like this for Python ? Depends on what you want. If you want to see the disassembled bytes similar to what I cut out, see the dis module. (e.g., dis.dis(foo_func)) If you want to know how the byte codes are created, it's mostly in Python/compile.c. If you want to know how the byte codes are executed, it's mostly in Python/ceval.c. All base Python objects implemented in C are under Objects/. All standard modules implemented in C are under Modules/. Get the source and build it. It's quite readable. n -- http://mail.python.org/mailman/listinfo/python-list
Re: Python script produces "sem_trywait: Permission denied"
Mark E. Hamilton wrote: > Sorry, I probably should have re-stated the problem: > > We're using Python 2.3.5 on AIX 5.2, and get the follow error messages > from some of our code. I haven't yet tracked down exactly where it's > coming from: > > sem_trywait: Permission denied > sem_wait: Permission denied > sem_post: Permission denied I'm I would be very concerned about these. Permission denied is somewhat baffling to me. man sem_wait on Linux doesn't show EPERM as a possible error condition. The code that likely generates these messages is in Python/thread_pthread.h near line 319. Do you have lots of threads? Do you make heavy use of semaphores? Maybe they are running out or something. Do you know if your locking is really working? > We don't run these scripts as root, so I can't say whether they work as > root. I suspect they would, though, since root has permissions to do > anything. I'm not sure. I don't know what the Permission denied really means. I wonder if there some weird compiler optimization thing going on. Not that I'm blaming the compiler, it could well be a python problem. I just don't know. Do you have any memory debugging tools that you can run python under to see if there's something weird python is doing? Valgrind should work on PPC now, but you may need to apply a patch, I'm not sure PPC support is mainline in v3. Other possibilities include purify if that works on AIX or sentinel. n -- http://mail.python.org/mailman/listinfo/python-list
Re: make: circular dependency for Modules/signalmodule.o
James Buchanan wrote: > Hi group, > > I'm preparing Python 2.4.2 for the upcoming Minix 3.x release, and I > have problems with make. configure runs fine and creates the makefile, > but right at the end ends with an error about a circular dependency in > Modules/signalmodule.o. I've never heard of this problem. The Makefile is generated by configure so this is possibly a configure issue. In my (generated) Makefile, signalmodule.o is listed in MODOBJS, but not in SIGNAL_OBJS. Maybe your signalmodule.o is listed in both? Search through the Makefile for signalmodule and see what you can find. Mine has two long lines for the rules which cause signalmodule.c to be compiled. Modules/signalmodule.o: $(srcdir)/Modules/signalmodule.c; $(CC) $(PY_CFLAGS) -c $(srcdir)/Modules/signalmodule.c -o Modules/signalmodule.o Modules/signalmodule$(SO): Modules/signalmodule.o; $(LDSHARED) Modules/signalmodule.o -o Modules/signalmodule$(SO) Good luck, n -- http://mail.python.org/mailman/listinfo/python-list
Re: Extention Woes
Tuvas wrote: > Forgot, var declartions > > int can_han; > int com; > char len; > char dat[8]; That should probably be: int len; char *dat; IIRC, "z" returns the internal string pointer. "#" is definitely not going to return a char. I'm pretty sure it returns an int and not a long. n -- http://mail.python.org/mailman/listinfo/python-list
Re: python gc performance in large apps
Jp Calderone wrote: > On Fri, 21 Oct 2005 16:13:09 -0400, Robby Dermody <[EMAIL PROTECTED]> wrote: > > > > [snip - it leaks memory] > > One thing to consider is that the process may be growing in size, not because > garbage objects are not being freed, but because objects which should be > garbage are being held onto by application-level code. This is a big problem with Java too. It's also likely to be a large source of the memory growth here given that there isn't much cylcic garbage. I'm assuming that memory leaks in the python core are going to be a small percentage of the total. (Probably also true even if there are memory leaks in Twisted, etc) It's so easy to keep data around you don't realize. I don't have any particular insight into this problem. I think Zope servers can run a long without similar issues, so I think (certainly hope) it's not endemic to the Python core. I don't recall any significant memory leaks fixed between 2.3 and current CVS. But it would be interesting to try your app on 2.4 at least to see if it works. CVS would also be interesting. You might want to consider building your own python configuring --with-pydebug. This will cause your program to run slower and consume more memory, but it has additional information available to help find reference leaks. Definitely also run under valgrind if possible. Given the size, I don't know if electric fence or dbmalloc are realistic options. Feel free to mail me if you need help with valgrind etc. I'm very curious what the root cause of your problem is. It's possible you are exercising code in python that isn't commonly used and so we haven't found a problem yet. Also consider looking into the issues of the third party libraries. Jp mentioned some problems with Twisted stuff. It would be good if you could provide small test cases that create the problems you have encountered. n -- http://mail.python.org/mailman/listinfo/python-list
Re: dictionary that have functions with arguments
Ron Adam wrote:
>
> Eval or exec aren't needed. Normally you would just do...
>
> execfunc['key1'](**args)
>
> If your arguments are stored ahead of time with your function...
>
> Committed revision 41366.
>
> You could then do...
>
> func, args = execfunc['key1']
> func(**args)
Interesting that both Ron and Alex made the same mistake. Hmmm, makes
me wonder if they are two people or not...
If args is a tuple, it should be:
func(*args)
If you want the full generality and use keyword args:
func(*args, **kwargs)
kwargs would be a dictionary with string keys.
E.g.,
execfunc = {'key1':(func1, (1,), {'keyarg': 42})}
HTH,
n
--
http://mail.python.org/mailman/listinfo/python-list
Re: best way to discover this process's current memory usage, cross-platform?
Alex Martelli wrote: > > So, I thought I'd turn to the "wisdom of crowds"... how would YOU guys > go about adding to your automated regression tests one that checks that > a certain memory leak has not recurred, as cross-platform as feasible? > In particular, how would you code _memsize() "cross-platformly"? (I can > easily use C rather than Python if needed, adding it as an auxiliary > function for testing purposes to my existing extension). If you are doing Unix, can you use getrusage(2)? >>> import resource >>> r = resource.getrusage(resource.RUSAGE_SELF) >>> print r[2:5] I get zeroes on my gentoo amd64 box. Not sure why. I thought maybe it was Python, but C gives the same results. Another possibiity is to call sbrk(0) which should return the top of the heap. You could then return this value and check it. It requires a tiny C module, but should be easy and work on most unixes. You can determine direction heap grows by comparing it with id(0) which should have been allocated early in the interpreters life. I realize this isn't perfect as memory becomes fragmented, but might work. Since 2.3 and beyond use pymalloc, fragmentation may not be much of an issue. As memory is allocated in a big hunk, then doled out as necessary. These techniques could apply to Windows with some caveats. If you are interested in Windows, see: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnucmg/html/UCMGch09.asp Can't think of anything fool-proof though. HTH, n -- http://mail.python.org/mailman/listinfo/python-list
Re: best way to discover this process's current memory usage, cross-platform?
Alex Martelli wrote: > matt <[EMAIL PROTECTED]> wrote: > > > Perhaps you could extend Valgrind (http://www.valgrind.org) so it works > > with python C extensions? (x86 only) > > Alas, if it's x86 only I won't even look into the task (which does sound > quite daunting as the way to solve the apparently-elementary question > "how much virtual memory is this process using right now?"...!), since I > definitely cannot drop support for all PPC-based Macs (nor would I WANT > to, since they're my favourite platform anyway). Valgrind actually runs on PPC (32 only?) and amd64, but I don't think that's the way to go for this problem. Here's a really screwy thought that I think should be portable to all Unixes which have dynamic linking. LD_PRELOAD. You can create your own version of malloc (and friends) and free. You intercept each call to malloc and free (by making use of LD_PRELOAD), keep track of the info (pointers and size) and pass the call along to the real malloc/free. You then have all information you should need. It increases the scope of the problem, but I think it makes it soluble and somewhat cross-platform. Using LD_PRELOAD, requires the app be dynamically linked which shouldn't be too big of a deal. If you are using C++, you can hook into new/delete directly. n -- http://mail.python.org/mailman/listinfo/python-list
Re: Any college offering Python short term course?
There is the BayPiggies user group: [EMAIL PROTECTED] It meets monthly alternating between Mt. VIew (Google) and San Bruno (IronPort). n -- bruce wrote: > hey... > > i'm looking for classes (advanced) in python/php in the bay area as well... > actually i'm looking for the students/teachers/profs of these classes... any > idea as to how to find them. calling the various schools hasn't really been > that helpful. The schools/institutions haven't had a good/large selection... > it appears that some of the classes are taught by adjunct/part-time faculty, > and they're not that easy to get to... > > if anybody knows of user-groups that also have this kind of talent, i'd > appreciate it as well... > > send responses to the list as well!!! > > thanks > > -bruce > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf > Of arches73 > Sent: Sunday, November 20, 2005 4:04 PM > To: python-list@python.org > Subject: Any college offering Python short term course? > > > Hi, > > I want to learn Python. I appreciate if someone point me to the > colleges / institutions offering any type of course in Python > programming in the Bay area CA. Please send me the links to my email. > > Thanks, > Arches > > > > -- > http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: 2.4.2 on AIX 4.3 make fails on threading
Paul Watson wrote: > When I try to build 2.4.2 on AIX 4.3, it fails on missing thread > objects. I ran ./configure --without-threads --without-gcc. > > Before using --without-threads I had several .pthread* symbols missing. Perhaps you need to add -lpthread to the link line. This should be able to work. What is the link line output from make? > Can anyone > suggest a configuration or some change that I can make to cause this to > build correctly? Thanks. > > ld: 0711-317 ERROR: Undefined symbol: ._PyGILState_NoteThreadState I think that problem has been fixed. Try downloading this file and replace the one in your build directory: http://svn.python.org/projects/python/branches/release24-maint/Python/pystate.c n -- http://mail.python.org/mailman/listinfo/python-list
Re: Singleton and C extensions
Emmanuel Briot wrote:
>
> I am not really good at python, but I was trying to implement the
> singleton design pattern in C, so that for instance calling the constructor
>
>ed = Editor ("foo")
>
> would either return an existing instance of Editor currently editing
> "foo", or would create a new instance.
Hmm, if there can be more than one Editor I wouldn't call it a
singleton.
But this should do what you want:
class Editor(object):
_cache = {}
def __init__(self, arg):
self._cache[arg] = self
def __new__(cls, arg):
if arg in cls._cache:
return cls._cache[arg]
return object.__new__(cls, arg)
> Has any one an example on how to do that in C, or maybe even at the
> python level itself, and I will try to adapt it ?
C is a *lot* more work and tricky too.
hth,
n
--
http://mail.python.org/mailman/listinfo/python-list
Re: A bug in struct module on the 64-bit platform?
[EMAIL PROTECTED] wrote:
> Hi,
>
> I have a user who complained about how "struct" module computes C
> struct data size on Itanium2 based 64-bit machine.
I wouldn't be surprised, but I don't understand the problem.
>>>struct.calcsize('idi')
>16
>>>struct.calcsize('idid')
>24
>>>struct.calcsize('did')
>20
These are what I would expect on a 32 or 64 bit platform. i == int, d
== float. ints are typically 4 bytes on 64 bit platforms. If you want
8 byte integers, you typically need to use longs (format letter is ell,
l).
You didn't say which version of python, so it's possible this was a bug
that was fixed too.
On my system:
python: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for
GNU/Linux 2.4.1, dynamically linked (uses shared libs), not stripped
>>> struct.calcsize('l') #that's a lowercase ell
8
If you think it's a bug, you should file a bug report on source forge.
n
--
http://mail.python.org/mailman/listinfo/python-list
Re: tkinter socket client ?
You are probably looking for Tkinter.createfilehandler(). Here are some snippets to get you started: tk_reactor = Tkinter._tkinter self.sd = socket(AF_INET, SOCK_STREAM) self.sd.connect((HOST, PORT)) tk_reactor.createfilehandler(self.sd, Tkinter.READABLE, self.handle_input) def handle_input(self, sd, mask): data = self.sd.recv(SIZE) (Sorry if the formatting is busted, blame google groups.) HTH, Neal -- http://mail.python.org/mailman/listinfo/python-list
PyChecker lives, version 0.8.15 released
Special thanks to Ken Pronovici. He did a lot of work for this
release and helped ensure it occurred.
Version 0.8.15 of PyChecker is available. It's been over a year since
the last release. Wow, time really does fly. Since it's been so long
I'm sure I screwed something up, treat it delicately. It may have bugs
and erase your hard drive. If that happens, look on the bright side,
you won't have any more bugs. :-)
PyChecker is a tool for finding bugs in Python source code.
It finds problems that are typically caught by a compiler for less
dynamic languages, like C and C++. It is similar to lint.
Comments, criticisms, new ideas, and other feedback is welcome.
Since I expect there may be a bit more bugs than normal, I will try to
put out another release in a few weeks. Please file bug reports
including problems with installation, false positives, &c on Source Forge.
You are welcome to use the mailling list to discuss anything pychecker
related, including ideas for new checks.
Changes from 0.8.14 to 0.8.15:
* Fix spurious warning about catching string exceptions
* Don't barf if there is # -*- encoding: ... -*- lines and unicode strings
* setup.py was rewritten to honor --root, --home, etc options
* Fix internal error on processing nested scopes
* Fix constant tuples in Python 2.4
* Don't warn about implicit/explicit returns in Python 2.4, we can't tell
* Fix crash when __slots__ was an instance w/o __len__
* Fix bug that declared {}.pop to only take one argument, it takes 1 or 2
* Fix spurious warning when using tuples for exceptions
* Fix spurious warning /
* Fix spurious warnings for sets module about __cmp__, __hash__
* Changed abstract check to require raising NotImplementedError
rather than raising any error
* Fix spurious warnings in Python 2.4 for Using is (not) None warnings
* Fix spurious warnings for some instances of No class attribute found
* Fix spurious warnings for implicit returns when using nested functions
PyChecker is available on Source Forge:
Web page: http://pychecker.sourceforge.net/
Project page: http://sourceforge.net/projects/pychecker/
Mailing List: [EMAIL PROTECTED]
Neal
--
[EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python Design Principles
[EMAIL PROTECTED] wrote:
>
> But I am still puzzled by the argument that has been given for why
> methods that operate on mutable types should return None, namely, that
> the designers of python didn't want the users to shoot themselves in
> the foot by thinking a method simply returned a result and left the
> data structure unchanged.
Let me try to answer your question with a question. Given this code:
>>> d = {}
>>> e = d.update([(1, 2)])
If .update() returned a dictionary, does d == e?
I'm not sure what you would guess. I am pretty sure that everyone
wouldn't agree whether d should equal e or not. If they are not equal,
that would mean a new copy would be made on each update which could be
incredibly expensive in speed and memory. It is also different from
how Python works today, since the update() method mutates the
dictionary.
> In the context of fundamental design principles, if you asked a random
> sample of Python gurus what is more Pythonesque: preventing users from
> shooting themselves in the foot or making things easier to accomplish,
> my impression is that people would overwhelmingly choose the latter.
Probably true, but ...
> After all, the fact that Python is not strongly typed and is
> interpreted rather than compiled gives plenty of ways for people to
> shoot themselves in the foot but what is gained is the abilitity to do
> more with less code.
I think most people programming Python are pretty pragmatic. There is
no single language that is ideal in all circumstances. There are
necessarily some trade-offs. Many believe that tools can help bridge
this gap. There are at least 2 tools for finding bugs (or gotchas) of
this sort: pychecker and pylint.
> But in this instance, by not allowing operations on mutable types to
> return the mutated objects, it seems that the other side is being
> taken, sacrificing programmer producitivity for concerns about
> producing possible side effects. It is somewhat ironic, I think, that
> Java, a language whose design principles clearly side on preventing
> users from shooting themselves in the foot, much more so thatn Python,
> generally allows you to get back the mutated object.
I think Python has attempted to create an internal consistency. I
believe Java has tried to do the same. However, these aren't the same
sets of consistency. People are always going to have assumptions.
Python strives to be as intuitive as possible. However, it can't be
right 100% of the time for all people.
HTH,
n
--
http://mail.python.org/mailman/listinfo/python-list
Re: Simplifying imports?
[EMAIL PROTECTED] wrote: > I like to keep my classes each in a separate file with the same name of > the class. The problem with that is that I end up with multiple imports > in the beginning of each file, like this: > > from foo.Bar import Bar > from foo.Blah import Blah > from foo.Zzz import Zzz Must ... resist ... temptation ... to ... complain ... about ... J... > What I'd like to do would be to replace it all by a single line: > > from foo.* import * > > Of course, that doesn't work, but is there a way to do something like > that? In foo there is a file __init__.py, right? If you have 3 class files in foo: bar.py, baz.py, and bax.py, you're __init__.py could contain: # __init__.py from foo.bar import Bar from foo.baz import Baz from foo.bax import Bax # end of __init__.py Then, voila: >>> import foo >>> dir(foo) ['Bar', 'Bax', 'Baz', '__builtins__', '__doc__', '__file__', '__name__', '__path__', 'bar', 'bax', 'baz'] You could write code in __init__.py to import all the files in foo/ if you wanted. That way you wouldn't have to explicitly list each file. (Hint: see os.listdir() and __import__().) HTH, n PS. I don't really like this approach. It seems too implicit (magical). -- http://mail.python.org/mailman/listinfo/python-list
[ANN] PyChecker 0.8.17 released
A new version of PyChecker is available. There are two notable new features (command line options): --only and -#/--limit. --only will only print warnings from files specified on the command line. --limit will limit the number of warnings printed. By default, only 10 warnings are printed unless you disable the limit check: -# 0. What is it? PyChecker is a tool for finding bugs in Python source code. It finds problems that are typically caught by a compiler for less dynamic languages, like C and C++. It is similar to lint. Comments, criticisms, new ideas, and other feedback is welcome. Changes from 0.8.16 to 0.8.17: * Fix spurious warning for Statement with no effect using bit shifts * Add -#/--limit command line option to set the max # of warnings to show * Remove broken command line options: -e/--errors, --complexity * Add -e/--level command line options which allows the error level to be specified: error, security, warning, unused, deprecated, style. These names map to numbers: 90, 90, 70, 50, 40, 10 (error == security). Specifying a value means all levels equal to or greater than it. * Add --only option which displays warnings only for files specified on the command line * Add --evil option for users to prevent the interpreter from crashing due to broken C extensions * Fix wrong file name when warning about returning values from __init__ functions. (#1291116) * Fix a few more glitches with setup.py. * Suppress warning about integer division when the code is: int(x / y) * Add code to skip testing objects from extension modules that are known to crash the interpreter. Currently, the list includes old versions of matplotlib.axes.BinOpType and wx.TheClipboard. * Support ROT_THREE and ROT_FOUR opcodes PyChecker is available on Source Forge: Web page: http://pychecker.sourceforge.net/ Project page: http://sourceforge.net/projects/pychecker/ Mailing List: [EMAIL PROTECTED] Enjoy and don't forget to provide feedback! Neal -- [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: porting help
You may need to write your own dynload_vxworks.c. Notice there are various OS specific dynload_*.c files. You can try to use dynload_stub.c to see if you can get it to compile. You may also need to muck with Include/pyport.h and configure to get things going. Good Luck! n -- http://mail.python.org/mailman/listinfo/python-list
Re: Binding the names in a module in a class instance
Jacob H wrote:
> Hello all,
>
> I would like to be able to take a module full of class instances,
> functions, etc and bind all its names to a separate container class
in
> a different module. I have come up with the following way to do it..
[snip]
> I feel uneasy about this method. I foresee bad namespace clashes.
> What's a better way? :)
Perhaps this is more like what you are looking for:
import stuff # stuff we want to copy
import everything # initially empty module where to store stuff
# loop over each attribute name in stuff
for attr in dir(stuff):
# skip over __special__ attributes, probably don't want them
if attr.startswith('__') and attr.endswith('__'):
continue
value = getattr(stuff, attr)
setattr(everything, attr, value)
You can add more checking for clashes or whatever by looking at the
attribute name (attr) which is a string.
hth,
n
--
http://mail.python.org/mailman/listinfo/python-list
Re: any macro-like construct/technique/trick?
Andrew's approach is good, but you could so something a little simpler/more flexible. Untested of course. :-) Every callable object is followed by the args to pass it. So this: debug_emit(DbgObjFoo(a, b, costly_function(c))) becomes: debug_emit(DbgObjFoo, (a, b, costly_function, (c,))) def debug_emit(*args): if not debug: return # assume last arg is not a callable and skip it i = len(args) - 2 while i > 0: if callable(args[i]): # call it! assume the next arg is a tuple of params new_value = args[i](*args[i+1]) args = args[:i] + (new_value,) + args[i+2:] emit_dbg_code(*args) cheers, n -- http://mail.python.org/mailman/listinfo/python-list
Python Software Foundation seeks mentors and students for Google Summer of Code
This spring and summer, Google will again provide stipends for students (18+, undergraduate thru PhD programs) to write new open-source code. The Python Software Foundation (PSF) http://www.python.org/psf/ will again act as a sponsoring organization in Google's Summer of Code, matching mentors and projects benefiting Python and Python users. Projects can include work on the core Python language, programmer utilities, libraries, packages, frameworks related to Python, or other Python implementations like Jython, PyPy, or IronPython. Please add your project ideas to the existing set at http://wiki.python.org/moin/SummerOfCode Mentoring instructions are also on this page. The deadline is soon, so please sign up as a mentor early. If you are a student considering a project, you should start deciding now. Feel free to ask questions on python-dev@python.org The main page for the Summer of Code is http://code.google.com/summerofcode.html At the bottom are links to StudentFAQ, MentorFAQ, and TermsOfService. The first two have the timeline. Note that student applications are due between May 1, 17:00 PST and May 8, 17:00 PST. People interested in mentoring a student though PSF are encouraged to contact me, Neal Norwitz at [EMAIL PROTECTED] People unknown to Guido or myself should find a couple of people known within the Python community who are willing to act as references. Feel free to contact me if you have any questions. I look forward to meeting many new mentors and students. Let's improve Python! Cheers, n -- http://mail.python.org/mailman/listinfo/python-list
Summer of Code mailing list
There's a new SoC mailing list. [EMAIL PROTECTED] You can sign up here: http://mail.python.org/mailman/listinfo/soc2006 This list is for any SoC discussion: mentors, students, idea, etc. Student can submit applications starting May 1, so now is the time to get students interested in your ideas! Please pass this information along. Cheers, n -- http://mail.python.org/mailman/listinfo/python-list
Seeking students for the Summer of Code
There is less than a week left before students must submit a final application. There are a bunch of ideas up on the wiki: http://wiki.python.org/moin/SummerOfCode/ The wiki has instructions for how to submit a proposal. There are many different areas including: core language features, libraries, and applications. This is a great opportunity to get real coding experience. Not to mention the chance to work with a nice and fun group of people. The earlier you submit an application, the more feedback you can get to improve it and increase your liklihood of getting accepted. Feel free to contact me if you have any questions. Cheers, n -- http://mail.python.org/mailman/listinfo/python-list
IMPORTANT 2.5 API changes for C Extension Modules and Embedders
If you don't write or otherwise maintain Python Extension Modules written in C (or C++) or embed Python in your application, you can stop reading. Python 2.5 alpha 1 was released April 5, 2006. The second alpha should be released in a few weeks. There are several changes which can cause C extension modules or embedded applications to crash the interpreter if not fixed. Periodically, I will send out these reminders with updated information until 2.5 is released. * support for 64-bit sequences (eg, > 2GB strings) * memory allocation modifications 64-bit changes -- There are important changes that are in 2.5 to support 64-bit systems. The 64-bit changes can cause Python to crash if your module is not upgraded to support the changes. Python was changed internally to use 64-bit values on 64-bit machines for indices. If you've got a machine with more than 16 GB of RAM, it would be great if you can test Python with large (> 2GB) strings and other sequences. For more details about the Python 2.5 schedule: http://www.python.org/dev/peps/pep-0356/ For more details about the 64-bit change: http://www.python.org/dev/peps/pep-0353/ How to fix your module: http://www.python.org/dev/peps/pep-0353/#conversion-guidelines The effbot wrote a program to check your code and find potential problems with the 64-bit APIs. http://svn.effbot.python-hosting.com/stuff/sandbox/python/ssizecheck.py Memory Allocation Modifications --- In previous versions of Python, it was possible to use different families of APIs (PyMem_* vs. PyObject_*) to allocate and free the same block of memory. APIs in these families include: PyMem_*:PyMem_Malloc, PyMem_Realloc, PyMem_Free, PyObject_*: PyObject_Malloc, PyObject_Realloc, PyObject_Free There are a few other APIs with similar names and also the macro variants. In 2.5, if allocate a block of memory with one family, you must reallocate or free with the same family. That means: If you allocate with PyMem_Malloc (or MALLOC), you must reallocate with PyMem_Realloc (or REALLOC) and free with PyMem_Free (or FREE). If you allocate with PyObject_Malloc (or MALLOC), you must reallocate with PyObject_Realloc (or REALLOC) and free with PyObject_Free (or FREE). Using inconsistent APIs can cause double frees or otherwise crash the interpreter. It is fine to mix and match functions or macros within the same family. Please test and upgrade your extension modules! Cheers, n -- http://mail.python.org/mailman/listinfo/python-list
IMPORTANT 2.5 API changes for C Extension Modules and Embedders
If you don't write or otherwise maintain Python Extension Modules written in C (or C++) or embed Python in your application, you can stop reading. Python 2.5 alpha 1 was released April 5, 2006. The second alpha should be released in a few weeks. There are several changes which can cause C extension modules or embedded applications to crash the interpreter if not fixed. Periodically, I will send out these reminders with updated information until 2.5 is released. * support for 64-bit sequences (eg, > 2GB strings) * memory allocation modifications 64-bit changes -- There are important changes that are in 2.5 to support 64-bit systems. The 64-bit changes can cause Python to crash if your module is not upgraded to support the changes. Python was changed internally to use 64-bit values on 64-bit machines for indices. If you've got a machine with more than 16 GB of RAM, it would be great if you can test Python with large (> 2GB) strings and other sequences. For more details about the Python 2.5 schedule: http://www.python.org/dev/peps/pep-0356/ For more details about the 64-bit change: http://www.python.org/dev/peps/pep-0353/ How to fix your module: http://www.python.org/dev/peps/pep-0353/#conversion-guidelines The effbot wrote a program to check your code and find potential problems with the 64-bit APIs. http://svn.effbot.python-hosting.com/stuff/sandbox/python/ssizecheck.py Memory Allocation Modifications --- In previous versions of Python, it was possible to use different families of APIs (PyMem_* vs. PyObject_*) to allocate and free the same block of memory. APIs in these families include: PyMem_*:PyMem_Malloc, PyMem_Realloc, PyMem_Free, PyObject_*: PyObject_Malloc, PyObject_Realloc, PyObject_Free There are a few other APIs with similar names and also the macro variants. In 2.5, if allocate a block of memory with one family, you must reallocate or free with the same family. That means: If you allocate with PyMem_Malloc (or MALLOC), you must reallocate with PyMem_Realloc (or REALLOC) and free with PyMem_Free (or FREE). If you allocate with PyObject_Malloc (or MALLOC), you must reallocate with PyObject_Realloc (or REALLOC) and free with PyObject_Free (or FREE). Using inconsistent APIs can cause double frees or otherwise crash the interpreter. It is fine to mix and match functions or macros within the same family. Please test and upgrade your extension modules! Cheers, n -- http://mail.python.org/mailman/listinfo/python-list
