Mailman 3 March 2009 - Python-Dev

CPython and C++ object GC
by Csaba Balazs March 30, 2009

March 30, 2009

Hello Everybody, I would like to use a C++ gui library with the following (simplified) interface in Python. #include <stdio.h> class Gui; class GuiObject { public: GuiObject(Gui *Gui) {printf("creating GuiObject(gui: %X)\n", Gui);} ~GuiObject() {printf("deleting GuiObject\n");} void Move(int x, int y) {printf("GuiObject move(%d, %d)\n", x, y);}; }; class Gui { public: Gui() {printf("creating Gui\n");} ~Gui() {printf("deleting Gui\n");} GuiObject* AddImage() { GuiObject* ob = new GuiObject(this); return ob; } void Print() {printf("Gui: %X\n", this);} }; int main() { Gui *gui = new Gui(); gui->Print(); GuiObject *obj = gui->AddImage(); obj->Move(50, 50); /*GuiObject *obj2 = new GuiObject(gui); // not allowed delete obj2;*/ delete obj; delete gui; return 0; } I created the Python Gui and GuiObject classes (PyTypeObject), and added it to main module (PyModule_AddObject). It works, but there is a problem at the Gui::AddImage(), with constructs a new GuiObject, which is available in Python layer but finally it is not collected and freed by GC: ... obj = _PyObject_New(&GuiObjectType); PyObject_Init(obj, &GuiObjectType); ... I cannot invoke the GuiObject object constructor directly from Python, because of the implementation of the C++ gui library (in this case it would be collected). I use the embedded CPython as an interpreter, so I cannot add additional external .py file for it. So the following Python code would be the target: gui = GUI(); background = gui.AddImage(); #background = GuiObject(gui); <-- Collected but not allowed background.ImageFile("bg.jpg"); background.Move(0, 0); ... How could I implement the AddImage function in order to be freed the constructed object at the end? Thanks in advance! All-the-best, Csaba

3 2

Python 2.6.2
by Barry Warsaw March 29, 2009

March 29, 2009

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'd like to release Python 2.6.2 the week after the conference. I've talked to a few people here about it and the general consensus is that we do one brown-paper-bag-avoiding release candidate first. Looking at the calendar, I propose the following schedule: Monday April 6: 2.6.2 rc1 Friday April 10: 2.6.2 final As usual, I plan on freezing the tree to create the Subversion tags at UTC 2200 or 6pm US/Eastern the day before the release to give Martin time to build the Windows installers. If you have stuff to get into 2.6.2, please do so before rc1. You'll need to get approval from me for all changes between 2.6.2rc1 and 2.6.2 final. Please let me know if this schedule does not work for you. Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSc/t63EjvBPtnXfVAQLL1QQAs1MQKs4x4Zvg5kMyzfcM/7Gtl7OmB8it dYVz0F0xuaWoNrAVxWrSnnIA4jaorZtWGk7/E0pn2kJ1oDdZdyqYQa0T86pKh1q0 n8/2ml8jNph92SlWK8UvgijK92x21rTBO1DZ+KJPJ0JYuCD2QTOTJY25MGk9M5LV k8E5IzSr7R0= =3Ezw -----END PGP SIGNATURE-----

1 0

python core project
by garg vikas March 29, 2009

March 29, 2009

hi everybody , i am going to do the project on nose compatibility with core-python testing infrastructure. so i have written the abstract for this project if someone want to mentor this project plesae contact me ? Core Python Testing Infrastructure | Nose compatibility ABSTRACT :- Python is improving day by day by providing more features and facilites to python programmers,but the developers of core-python has week testing infrastructure, but as they are well known of the python code so they can use their own hackish testing ,but "testing the core-python code" is great problem for the new developers who want to participate in developing core-python and are new to this core-python code.So "core-python Testing Framework" requires improvements which can be provided by using "nose - unit test discovery and execution framework" which provides you selectively execute certain tests, capture and collate error output, and add coverage and profiling information in addition to finding and running your tests.so nose has such great features but it has not campatible with core-python testing suit.So that is my aim of project to provide nose framework to "core-python testing suit".nose also provides one more good feature, that is plugins support means you can write your plugins which helps in providing 1. support for testing suits which are not compatible with nose 2. improve the functionality of nose to provide features to your testing infrastructure. second aim of this project is not going to change anything of core-python testing infrastructure or with nose but this project will be an bridge between nose and core-python which will include nose -plugins and wrappers for providing beautiful features like tag-based execution,code-coverage and many more features to the core-python testing infrastructure.it will make testing of code more relevent,make easy fixing of bugs and as with its tag-based execution property will help in running selective tests and which will also help in lowering testing time.It's code-coverage property will make help in finding all untested places in "code of core-python". My email:- vikas_it_pec(a)yahoo.co.in Thanks vikas garg Add more friends to your messenger and enjoy! Go to http://messenger.yahoo.com/invite/

1 0

Are buffer overflows in modules deleted in py3k ignorable?
by R. David Murray March 29, 2009

March 29, 2009

I'm reviewing http://bugs.python.org/issue2591, which is marked as 'security' because it is a potential buffer overflow. almodule.c has been dropped in py3k, so my impulse is to close the bug as "won't fix". But I thought I should check in to find out what the policy is before doing that since it is a 'security' bug. -- R. David Murray http://www.bitdance.com

2 2

Core projects for Summer of Code
by Arc Riley March 29, 2009

March 29, 2009

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.

19 54

suggestion for try/except program flow
by Mark Donald March 29, 2009

March 29, 2009

I frequently have this situation: try: try: raise Thing except Thing, e: # handle Thing exceptions raise except: # handle all exceptions, including Thing It would be much more readable if there were a way to recatch a named exception with the generic (catch-all) except clause of its own try, something like this: try: raise Thing except Thing, e: # handle Thing exceptions recatch except: # handle all exceptions, including Thing

2 1

Re: [Python-Dev] PEP 380 (yield from a subgenerator) comments
by P.J. Eby March 28, 2009

March 28, 2009

At 12:27 PM 3/26/2009 -0700, Guido van Rossum wrote: >There is some clear low-hanging fruit for Greg's proposal >where no trampoline or helpers are needed -- but where currently >refactoring complex code containing many yield statements is >cumbersome due to the nee to write each "subroutine" call as "for x in >subroutine(): yield x" -- being able to replace this with "yield from >subroutine()" is a conceptual advantage to me that is not proportional >to the number of characters saved. Right - I don't object to the concept of "yield from" -- I'm -0 on that. What I don't like is the confusion of adding "return values" to generators, at least using the 'return' statement.

5 16

package resources [was: "setuptools has divided the Python community"]
by Jim Jewett March 28, 2009

March 28, 2009

At 11:27 PM 3/26/2009 +0000, Paul Moore wrote: >> What I'd really like is essentially some form of "virtual filesystem" >> access to stuff addressed relative to a Python package name, P.J. Eby responded: > Note that relative to a *Python package name* isn't quite as useful, > due to namespace packages. To be unambiguous as to the targeted > resource, one needs to be able to reference a specific project, and > that requires you to go off the name of a module *within* a > package. For example, 'zope.somemodule' rather than just 'zope'. I would expect it to be *most* important then. If I know for sure that an entire package is all together in a single directory, I can just use that directory. If I want all xxx files used by zope, then ... I *do* want information on the duplicates, and the multiple locations. -jJ

1 0

Re: [Python-Dev] Unladen-Swallow: A faster python
by andrew cooke March 28, 2009

March 28, 2009

Mark Hammond wrote: > On 28/03/2009 9:50 PM, andrew cooke wrote: >> Tim Roberts wrote: >>> [...] IronPython has certainly shown that Python can be successfully >>> implemented in a JIT compiled VM in a performant way, but it has issues >>> running C extension modules. >>> >>> I'll be curious to see where this project goes. >> >> given the comments on python-dev i wonder if this is the first >> indication >> that python is going to split into separate implementations for windows >> and unix (via .net and llvm, respectively)? > > What comments are they? There is no indication that unladen-swallow is > fundamentally broken for Windows, just temporarily broken due to the > lack of windows developers/contributors... the comments you are referring to - that windows is not a priority, that they currently have no testing on windows machines, etc. i quote, for example: "None of the three of us have Windows machines, nor do we particularly want to acquire them :), and Windows support isn't going to be a big priority." > Saying-no-to-fud ly, which part of "i wonder" don't you understand? i'm not saying it is true, i'm just discussing the possibility. i am getting a little tired of people here acting so defensively... i'm discussing a programming language, not the size of your dick. andrew

3 3

My summit notes (packaging)
by Tarek Ziadé March 28, 2009

March 28, 2009

Here's a wrapup of my notes for the Distutils part (with Jim's help). The PyPI part will come later. I have presented the various problems developers have with packaging today, wether they are using Distutils, Setuptools or any other third party tools out there. Here's the short-list: - Distutils code is still undertested, with over 100 issues to take care of in the tracker. - Setuptools is the de-facto extension of Distutils. It brings a lot of good features, but some features are controversial amongst the community. - We have now two tools that install a package and look for its dependencies at PyPI and install them: pip and easy_install. The latter is included in setuptools. They both aim at the same goal besides a few differences, and they both rely on a new metadata introduced by setuptools, wich is. "install_requires". This new metadata extends the metadata. described in PEP 314 but is slightly different from. what is descibred in the Draft PEP 345 ("Requires"). .. PEP 345 introduces "Requires" and "Provides" wich are are implemented in Distutils and PyP, but are not widely used. 40 out of +4000 if I remember correctly. Martin will correct me here if I am wrong. - pip, easy_install and distutils use different formats for installed metadata. For instance, Distutils installs a PKG-INFO file whereas setuptools creates a directory with the PKG-INFO file in it. - There's no way to uninstall a package. The only way to do it is to remove manually the directory located in your site-packages and remove the line located in the .pth file that might point to it. - There's no standard way to use resource files, for instance to be able to read or write a resource file that might be installed in a specific place on the target system by the system packager. Most of the time people are just working with files located. in the package directory. Ian Bicking and Jim Fulton gave short presentations of virtualenv and zc.buildout. These tools will let you build an isolated environment, where you can install some packages of certain versions, that play well together to run an application, without having to put anything into your site-packages. Many agreed that adding packages into the system's site-packages for an application to run is not a good idea. Also, many agreed that these third party tools are doing their. job and that we shouldn't try to include some of the features they. provide in any way in the standard library. Such as supporting multiple. versions for the same package for example. Instead, the idea is to try to reduce the scope of Distutils and to provide some better API and conventions for people to access to the package metadata (wether it's installed or not) because people have different needs and purposes using these data. *What's next ?* Guido provided a high level plan for the work to be done in packaging. Let me quote him: - standardize more metadata, especially including dependencies,. and APIs for accessing the metadata and dependencies. - there should be an API to get metadata for a package without actually executing any of the package's installation script. - this will go into the stdlib for Python 2.7 and 3.1 - it will be provided as separately downloadable backports for prior versions (maybe using a bootstrap not unlike ez_install) - keep distutils, but start deprecating certain higher-level functionality in it (e.g. bdist_rpm) - don't try to provide higher-level functionality in the stdlib, but instead let third party tools built on top of these core APIs compete So we are currently working this week to flesh out this plan, and we will send a mail to Distutils-SIG with the ouput asap. Cheers Tarek -- Tarek Ziadé | Association AfPy | www.afpy.org Blog FR | http://programmation-python.org Blog EN | http://tarekziade.wordpress.com/

2 1