Re: [Python-Dev] Core projects for Summer of Code
> Hey guys/gals > > Summer of Code is ramping up. Every year the common complaint is that not > enough Python core projects get proposed by students, and of course a big > reason for that is often the only encouragement we offer prospective > students is a link to the PEP index. > > So let's make this year different. > > Accepted students are paid a total of $4500 to work for roughly 30 hours a > week, 12 weeks, on their proposed project. > > The challenge is finding project ideas for them that could reasonably occupy > them for the entire Summer and which the results of their work can be > demonstrated. They're being paid for specific projects so "Spend the Summer > fixing bugs on the tracker" is a no-go, and Google has outlined that Summer > of Code is about code, not documentation. > > I've seen and heard that a lot of work is still needed on > http://svn.python.org/view/python/trunk both during the 3.1 release cycle, > optimization possible all over the place. It'd be great if those of you > working closely with this can shout out some ideas, brainstorm a bit. > > PSF was announced as one of the mentoring orgs today, this week before > student applications are open is for students to talk to their prospective > mentors and iron out the wrinkles in their plans, so there's not much time > to get core project ideas together. How about porting PIL to 3.0? There were many such requests on python-list and image-sig (including mine :)) Cheers, Daniel -- Psss, psss, put it down! - http://www.cafepress.com/putitdown ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Core projects for Summer of Code
>>> Summer of Code is ramping up. Every year the common complaint is that >>> not >>> enough Python core projects get proposed by students, and of course a big >>> reason for that is often the only encouragement we offer prospective >>> students is a link to the PEP index. >>> >>> So let's make this year different. >>> >>> Accepted students are paid a total of $4500 to work for roughly 30 hours >>> a >>> week, 12 weeks, on their proposed project. >>> >>> The challenge is finding project ideas for them that could reasonably >>> occupy >>> them for the entire Summer and which the results of their work can be >>> demonstrated. They're being paid for specific projects so "Spend the >>> Summer >>> fixing bugs on the tracker" is a no-go, and Google has outlined that >>> Summer >>> of Code is about code, not documentation. >>> >>> I've seen and heard that a lot of work is still needed on >>> http://svn.python.org/view/python/trunk both during the 3.1 release >>> cycle, >>> optimization possible all over the place. It'd be great if those of you >>> working closely with this can shout out some ideas, brainstorm a bit. >>> >>> PSF was announced as one of the mentoring orgs today, this week before >>> student applications are open is for students to talk to their >>> prospective >>> mentors and iron out the wrinkles in their plans, so there's not much >>> time >>> to get core project ideas together. >> >> How about porting PIL to 3.0? >> There were many such requests on python-list and image-sig (including mine >> :)) >> > > I have ported it to the stage where its tests passes (which are far > from covering all the code) and some of my own tests, there is a git > repo on the image-sig that points to it. I wasn't really careful with > some of the things (and I would even consider redoing some of them), > but only one or two people got a copy of it so apparently people don't > want/need it on python 3.0 just yet (not it alone at least). I did a "git clone git://gpolo.ath.cx/pil-py3k.git" but it failed: gpolo.ath.cx[0: 189.7.18.241]: errno=Connection timed out fatal: unable to connect a socket (Connection timed out) fetch-pack from 'git://gpolo.ath.cx/pil-py3k.git' failed. By the way the reason I think few people checked it out is that people mostly are waiting for an "official" PIL release that is known to be stable. Did you try making your port part of the "official" PIL distribution? Cheers, Daniel -- Psss, psss, put it down! - http://www.cafepress.com/putitdown ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Core projects for Summer of Code
> Summer of Code is ramping up. Every year the common complaint is that > not > enough Python core projects get proposed by students, and of course a > big > reason for that is often the only encouragement we offer prospective > students is a link to the PEP index. > > So let's make this year different. > > Accepted students are paid a total of $4500 to work for roughly 30 > hours > a > week, 12 weeks, on their proposed project. > > The challenge is finding project ideas for them that could reasonably > occupy > them for the entire Summer and which the results of their work can be > demonstrated. They're being paid for specific projects so "Spend the > Summer > fixing bugs on the tracker" is a no-go, and Google has outlined that > Summer > of Code is about code, not documentation. > > I've seen and heard that a lot of work is still needed on > http://svn.python.org/view/python/trunk both during the 3.1 release > cycle, > optimization possible all over the place. It'd be great if those of > you > working closely with this can shout out some ideas, brainstorm a bit. > > PSF was announced as one of the mentoring orgs today, this week before > student applications are open is for students to talk to their > prospective > mentors and iron out the wrinkles in their plans, so there's not much > time > to get core project ideas together. How about porting PIL to 3.0? There were many such requests on python-list and image-sig (including mine :)) >>> >>> I have ported it to the stage where its tests passes (which are far >>> from covering all the code) and some of my own tests, there is a git >>> repo on the image-sig that points to it. I wasn't really careful with >>> some of the things (and I would even consider redoing some of them), >>> but only one or two people got a copy of it so apparently people don't >>> want/need it on python 3.0 just yet (not it alone at least). >> >> I did a "git clone git://gpolo.ath.cx/pil-py3k.git" but it failed: >> >> gpolo.ath.cx[0: 189.7.18.241]: errno=Connection timed out >> fatal: unable to connect a socket (Connection timed out) >> fetch-pack from 'git://gpolo.ath.cx/pil-py3k.git' failed. >> > > Thanks for noticing that, maybe more people had this same problem > then, I will consider using github or some similar service (or maybe > take the chance to bazaar, or mercurial, or svn, or..). > >> By the way the reason I think few people checked it out is that people >> mostly are waiting for an "official" PIL release that is known to be >> stable. Did you try making your port part of the "official" PIL >> distribution? >> > > I have talked with Fredrik, he said he would be running it on another > test suite to check how much of it really works. But, no, I didn't > really try pushing it to be integrated into the next PIL release and > it also wouldn't be possible without distributing a py3k version only > -- I didn't do the port with the ability to work in python 3.x and > python 2.x but this can be arranged. Maybe I'm misunderstanding you but I didn't mean to say that this version should work on both python 2.x and python 3.x. Ideally, there would be a PIL distribution for 2.x only and another one for 3.x only. The only thing is that people (myself included) will only be comfortable with the PIL for 3.x version if it comes with the blessings of Fredrik, i.e. if I were you I'd try pushing this with Fredrik. After all if all tests pass including the ones Fredrik has for himself, there should be no problem and I suppose he would be happy to have a PIL for python 3.x. Until then I'd be happy to check out your own port, whenever you have a working repository copy please let us know. Cheers, Daniel -- Psss, psss, put it down! - http://www.cafepress.com/putitdown ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] decorator module in stdlib?
The decorator module [1] written by Michele Simionato is a very useful tool for maintaining function signatures while applying a decorator. Many different projects implement their own versions of the same functionality, for example turbogears has its own utility for this, I guess others do something similar too. Was the issue whether to include this module in the stdlib raised? If yes, what were the arguments against it? If not, what do you folks think, shouldn't it be included? I certainly think it should be. Originally I sent this message to c.l.p [2] and Michele suggested it be brought up on python-dev. He also pointed out that a PEP [3] is already written about this topic and it is in draft form. What do you guys think, wouldn't this be a useful addition to functools? Cheers, Daniel [1] http://pypi.python.org/pypi/decorator [2] http://groups.google.com/group/comp.lang.python/browse_thread/thread/d4056023f1150fe0 [3] http://www.python.org/dev/peps/pep-0362/ -- Psss, psss, put it down! - http://www.cafepress.com/putitdown ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] decorator module in stdlib?
>> Then perhaps you misunderstand the goal of the decorator module. >> The raison d'etre of the module is to PRESERVE the signature: >> update_wrapper unfortunately *changes* it. >> >> When confronted with a library which I do not not know, I often run >> over it pydoc, or sphinx, or a custom made documentation tool, to extract >> the >> signature of functions. > > Ah, I see. Personally I rarely trust automatically extracted > documentation -- too often in my experience it is out of date or > simply absent. Extracting the signatures in theory wouldn't lie, but > in practice I still wouldn't trust it -- not only because of what > decorators might or might not do, but because it might still be > misleading. Call me old-fashioned, but I prefer to read the source > code. > > For instance, if I see a method >> get_user(self, username) I have a good hint about what it is supposed >> to do. But if the library (say a web framework) uses non >> signature-preserving >> decorators, my documentation tool says to me that there is function >> get_user(*args, **kwargs) which frankly is not enough [this is the >> optimistic case, when the author of the decorator has taken care >> to preserve the name of the original function]. > > But seeing the decorator is often essential for understanding what > goes on! Even if the decorator preserves the signature (in truth or > according inspect), many decorators *do* something, and it's important > to know how a function is decorated. For example, I work a lot with a > small internal framework at Google whose decorators can raise > exceptions and set instance variables; they also help me understand > under which conditions a method can be called. > >> I *hate* losing information about the true signature of functions, since >> I also >> use a lot IPython, Python help, etc. > > I guess we just have different styles. That's fine. > I must admit that while I still like decorators, I do like them as much as in the past. >> >> Of course there was a missing NOT in this sentence, but you all understood >> the intended meaning. >> >>> (All this BTW is not to say that I don't trust you with commit >>> privileges if you were to be interested in contributing. I just don't >>> think that adding that particular decorator module to the stdlib would >>> be wise. It can be debated though.) >> >> Fine. As I have repeated many time that particular module was never >> meant for inclusion in the standard library. > > Then perhaps it shouldn't -- I haven't looked but if you don't plan > stdlib inclusion it is often the case that the API style and/or > implementation details make stdlib inclusion unrealistic. (Though > admittedly some older modules wouldn't be accepted by today's > standards either -- and I'm not just talking PEP-8 compliance! :-) > >> But I feel strongly about >> the possibility of being able to preserve (not change!) the function >> signature. > > That could be added to functools if enough people want it. My original suggestion for inclusion in stdlib was motivated by this reason alone: I'd like to see an official one way of preserving function signatures by decorators. If there are better ways of doing it than the decorator module, that's totally fine, but there should be one. Cheers, Daniel >> I do not think everybody disagree with your point here. My point still >> stands, though: objects should not lie about their signature, especially >> during debugging and when generating documentation from code. > > Source code never lies. Debuggers should make access to the source > code a key point. And good documentation should be written by a human, > not automatically cobbled together from source code and a few doc > strings. -- Psss, psss, put it down! - http://www.cafepress.com/putitdown ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3144 review.
>>> 188 (check that, 190) people have downloaded the 2.0 release in the >>> last week (numbers publicly available from the code.google.com). I >>> can't tell you how many (if any) have downloaded it via svn. >> >> Downloading and using are not the same thing. > > Correct, but there is a strong positive correlation between the two. > If you have a better method for determining what you would consider an > appropriate level of usage, I'm all ears. A good way of determining the level of usage would be pointing to open source projects that are popular in the python community and which incorporate your module. Cheers, Daniel -- Psss, psss, put it down! - http://www.cafepress.com/putitdown ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3144 review.
> 188 (check that, 190) people have downloaded the 2.0 release in the > last week (numbers publicly available from the code.google.com). I > can't tell you how many (if any) have downloaded it via svn. Downloading and using are not the same thing. >>> >>> Correct, but there is a strong positive correlation between the two. >>> If you have a better method for determining what you would consider an >>> appropriate level of usage, I'm all ears. >> >> A good way of determining the level of usage would be pointing to open >> source projects that are popular in the python community and which >> incorporate your module. > > well, the 2.0 release is still new. codesearch.google.com shows some > projects using the 1.x release; hopefully some of those 200 > downloaders will put up some publicly indexable python code at some > point. I think one first needs to wait until this happens, I meana large user base is formed, before a meaningful discussion can be done on whether to include it in the stdlib or not. The long and largely academic thread here I think illustrates this point. Without a large user base it's up to anybody's gut feelings what is 'right' and what 'feels wrong'. Cheers, Daniel -- Psss, psss, put it down! - http://www.cafepress.com/putitdown ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Distutils and Distribute roadmap (and some words on Virtualenv, Pip)
>> My opinion is that this tool exists only because Python doesn't >> support the installation of multiple versions for the same >> distributions. > > This is not at all how I use virtualenv. For me virtualenv is a > sandbox so that I don't have to become root whenever I need to install > a Python package for testing purposes and to allow me to hop between > sets of installed Python packages while developing on multiple Python > projects. I also use it as a sandbox for build bots so that multiple > bots on the same machine can each build their own projects with just > the known dependencies installed. +1 I also don't use virtualenv for supporting multiple versions, but rather for sandboxing, testing and experimentation. To make sure that an app works with the exact dependencies I think it should work with. Also, it's important that the 'global' site-packages typically requires root privileges while installing to a virtualenv doesn't. Cheers, Daniel -- Psss, psss, put it down! - http://www.cafepress.com/putitdown ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] readonly __doc__
> Speaking of the __doc__ property, I just noticed the following thing on > py3k: > class C: pass > ... C.__doc__ = "hop" > Traceback (most recent call last): > File "", line 1, in > AttributeError: attribute '__doc__' of 'type' objects is not writable Happens also with new style classes in python 2.x: Python 2.5.1 (r251:54863, Oct 30 2007, 13:45:26) [GCC 4.1.2 20070925 (Red Hat 4.1.2-33)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class C(object): pass ... >>> C.__doc__ = 'hello' Traceback (most recent call last): File "", line 1, in AttributeError: attribute '__doc__' of 'type' objects is not writable >>> But not with old style classes: Python 2.5.1 (r251:54863, Oct 30 2007, 13:45:26) [GCC 4.1.2 20070925 (Red Hat 4.1.2-33)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class C: pass ... >>> C.__doc__ = 'hello' >>> Cheers, Daniel -- Psss, psss, put it down! - http://www.cafepress.com/putitdown ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Package Management Roadmap in Python Releases
>> (*) Remember, however, that Tarek and work on Distribute, and also on >> bringing pieces of setuptools/Distribute functionality into distutils. > > But if that's the case then why not work on any third party tool..? like > pip or setuptools? > > It seems are very longwinded process if the only way to work on > python is to work on distutils but before doing that you have to > first work on distribute and then wait for all the changes to work > their way back up the chain.. > > Actually, I have finally worked out what I want. That is shell support > in the python windows distribution so that you can right click an > .egg and install it. > > I don't see how that can be achieved by following the workprocess > that you describe above. As has been said by many, you are entirely welcome to work on whatever tool you think is useful. Once you are done you are again welcome to distribute your tool or application to users and see how many users are happy with it. Once you are done with this step as well, you are again encouraged to come back to python-dev and say: "In the last X months my app/tool became very popular in the python community. There are Y developers working on the app/tool and there are Z happy users. I'd suggest including it in the python stdlib or I'd suggest coordinating the releases of my app/tool with that of python." At this point a useful conversation can start. Please note that a similarly useful conversation is impossible to take place before all the above steps have been completed. HTH, Daniel -- Psss, psss, put it down! - http://www.cafepress.com/putitdown ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Sort out formatting differences in decimal and float
> Sorry for being a curmudgeon, however...
>
> >>> format(Decimal(1234), '020,g')
> '0,000,000,000,001,234'
> >>> format(Decimal(1234), '0=20,g')
> '0001,234'
>
> Why in the world would you ever want to insert commas as separators and not
> use them consistently?
>
> >>> format(Decimal('nan'), '020,g')
> ' NaN'
> >>> format(Decimal('nan'), '0=20,g')
> '0NaN'
>
> Why in the world would you ever want to zero pad Nan (or Inf, for that
> matter)?
Because you didn't know in advance that the number ending up in your
format call was a nan (or inf)?
Cheers,
Daniel
> Stefan> The advantage of decimal is that the user has the option to
> Stefan> suppress commas. The behaviour of float is slightly easier to
> Stefan> implement in C.
>
> Why? If the user asked for them why would you want to suppress (some of)
> them?
--
Psss, psss, put it down! - http://www.cafepress.com/putitdown
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pronouncement on PEP 389: argparse?
>> If you're only concerned about 2.X, then yes, optparse will *never* be >> removed from 2.X. There will be a deprecation note in the 2.X >> documentation but deprecation warnings will only be issued when the -3 >> flag is specified. Please see the "Deprecation of optparse" section of >> the PEP: >> >> http://www.python.org/dev/peps/pep-0389/#deprecation-of-optparse > > I do not think that optparse should be deprecated at. It is good at > what it does and its limitations make its starting point less > confusing for people with different backgrounds that Python. > > Compare: > http://docs.python.org/library/optparse.html > http://argparse.googlecode.com/svn/tags/r101/doc/index.html > > argparse should be recommended as advanced and more featured variant > of optparse - that goes without saying, but forcing people to switch > and annoying them with deprecation messages brings only headache. As has been noted already nobody is forcing people to switch. Optparse will be available as a separate package and everybody will be free to install it and will not have any deprecation messages anywhere. > Just > like optparse is better getopt, the latter could also be useful for > people coming from other languages and porting their libraries to > Python. > > I would better concentrate on real code examples how argparse solves > problems and would really want to see > http://www.python.org/dev/peps/pep-0389/#out-of-scope-various-feature-requests > implemented until argparse enters phase where backward incompatible > changes in API are impossible. > > I would prefer to see PEP 389 as a document describing proposed > solutions to argument parsing problems rather than petition to replace > one library with another. So, it should display common argument > parsing scenarios (use cases) with examples that are also useful > recipes for documentation. I guess more than 90% people here doesn't > have time to read argparse methods descriptions to see what they could > be useful for. -- Psss, psss, put it down! - http://www.cafepress.com/putitdown ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython
A question from someone writing C extension modules for python but not involved in python-dev: It has been said that compiling python with --without-llvm would not include unladen swallow and would bypass llvm together with all C++. Basically, as I understand it, --without-llvm gives the 'usual' cpython we have today. Is this correct? If this is correct, I still have one worry: since I wouldn't want to touch the python install most linux distributions ship or most windows/mac users install (or what MS/Apple ships) I will simply have no choice than working with the python variant that is installed. Is it anticipated that most linux distros and MS/Apple will ship the python variant that comes with llvm/US? I suppose the goal of merging llvm/US into python 3.x is this. If this is the case then I, as a C extension author, will have no choice than working with a python installation that includes llvm/US. Which, as far as I undestand it, means dealing with C++ issues. Is this correct? Or the same pure C extension module compiled with C-only compilers would work with llvm-US-python and cpython? Cheers, Danil -- Psss, psss, put it down! - http://www.cafepress.com/putitdown ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython
>> If this is the case then I, as a C extension author, will have no >> choice than working with a python installation that includes llvm/US. >> Which, as far as I undestand it, means dealing with C++ issues. Is >> this correct? Or the same pure C extension module compiled with C-only >> compilers would work with llvm-US-python and cpython? > > As a C extension author you will be fine (the source and linker > interface will all still be C-only). Thanks, that is good to hear! Cheers, Daniel > C++ extension authors may need to care about making the version of the > C++ runtime that they link against match that used internally by > CPython/LLVM (although I'm a little unclear on that point myself). -- Psss, psss, put it down! - http://www.cafepress.com/putitdown ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython
>> A question from someone writing C extension modules for python > > I doubt that this will have any impact on C extension developers. > > >> If this is correct, I still have one worry: since I wouldn't want to >> touch the python install most linux distributions ship or most >> windows/mac users install (or what MS/Apple ships) I will simply have >> no choice than working with the python variant that is installed. >> >> Is it anticipated that most linux distros and MS/Apple will ship the >> python variant that comes with llvm/US? I suppose the goal of merging >> llvm/US into python 3.x is this. > > Depends on the distro. My guess is that they will likely provide both as > separate packages Yes, it's clear that various packages will be available but what I was asking about is the default python version that gets installed if a user installs a vanilla version of a particular linux distro. It's a big difference for developers of C extension modules to say "just install this module and go" or "first download the python version so-and-so and then install my module and go". But as I understand from you and Nick, this will not be a problem for C extension module authors. > (unless one turns out to be clearly 'better'), and > potentially even support their parallel installation. That's not > unprecedented, just think of different JVM implementations (or even just > different Python versions). > > >> If this is the case then I, as a C extension author, will have no >> choice than working with a python installation that includes llvm/US. >> Which, as far as I undestand it, means dealing with C++ issues. > > I don't think so. Replacing the eval loop has no impact on the C-API > commonly used by binary extensions. It may have an impact on programs that > embed the Python interpreter, but not the other way round. > > Remember that you usually don't have to compile the Python interpreter > yourself. Once it's a binary, it doesn't really matter anymore in what > language(s) it was originally written. > >> Or the same pure C extension module compiled with C-only >> compilers would work with llvm-US-python and cpython? > > That's to be expected. Okay, that's great, basically Nick confirmed the same thing. Cheers, Daniel -- Psss, psss, put it down! - http://www.cafepress.com/putitdown ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft PEP on RSON configuration file format
> Finding .ini configuration files too limiting, JSON and XML to hard to > manually edit [snip] > I call the new format RSON (for "Readable Serial Object Notation"), > and it is designed to be a superset of JSON. Quick question: if JSON is too hard to manually edit, how can RSON be any easier when it is a *superset* of JSON? Cheers, Daniel -- Psss, psss, put it down! - http://www.cafepress.com/putitdown ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] adding new function
> how can i simply add new functions to module after its initialization > (Py_InitModule())? I'm missing something like > PyModule_AddCFunction(). This type of question really belongs to python-list aka comp.lang.python which I CC-d now. Please keep the discussion on that list. Cheers, Daniel -- Psss, psss, put it down! - http://www.cafepress.com/putitdown ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] *** glibc detected *** gdb: malloc(): smallbin double linked list
> Hi, > > I've compiled > Python 2.7 (r27:82500, Nov 2 2010, 09:00:37) > [GCC 4.4.3] on linux2 > > with the following configure options > ./configure --prefix=/home/john/local/python-dbg --with-pydebug > > I've installed numpy and some other packages but when I try to run my > extension code under gdb I get the errors below. Does anyone have any > ideas of how to track down what's happening here? I imagine I've > misconfigured something somewhere. Is valgrind the answer? > > Thanks, > John. Hi John, the right place for asking such questions is the python mailing list python-l...@python.org, please see http://mail.python.org/mailman/listinfo/python-list This python-dev list is for the development *of* python and not development *with* python. For the latter python-list is the appropriate forum. Cheers, Daniel -- Psss, psss, put it down! - http://www.cafepress.com/putitdown ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
