Re: [Python-Dev] Test failures under Windows?
David Bolen wrote: I don't know why they are happening so frequently now when there was a reasonable period when they weren't an issue (something about new I/O support in 3.x perhaps?), but without preventing them it seems the Windows build slaves are going to become (if not already) quite a bit less useful. Don't know about anyone else's but I can't watch mine 7x24. -- David CRT Assertion was totally disabled before, but recently was enabled, and workarounds were patched for problematic functions. (ex: fdopen and dup) Probably this *patch* is not perfect. See http://bugs.python.org/issue4804 I'm now +3/4 for the idea disabling assertion by default, and enabling by startup option or environment variable. (Or enabling by default and disabling by environment variable?) ___ 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] "setuptools has divided the Python community"
Tennessee Leeuwenburg a écrit : I would suggest there may be three use cases for Python installation tools. Bonus -- I'm not a web developer! :) Case One: Developer wishing to install additional functionality into the system Python interpreter forever Case Two: Developer wishing to install additional functionality into the system Python interpreter for a specific task Case Three: Person wanting to install an application which happens to be written in Python a maybe more exotic Case Four: the enlightened open-source user, who wants to install an application, but might like to look under the hood, either to tweek it to his needs, or to investigate a bug. In that case, each application comming with a private version of various system libraries is unwelcomed complication, so that using the platform's package manager is a much better solution. Cheers, B. ___ 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] "setuptools has divided the Python community"
Tres Seaver a écrit : Note that the kind of applications I work on tend to be the sort which will run as server apps, and which will (in production) be the entire rasion d'etre for the machine they run on, which makes the cost of isolation tiny compared to the consequences of failed isolation. Indeed. More fundamentally, different use cases call for the dependency management to happen in different places. In the case of the web application, the dependencies must be resolved on the developper machine, and tested there, then the full bundle is pushed to the production server where failure is not an option. This is in strong contrast with the Debian (for example) use case, where you want the dependencies to be resolved on the end user machine, because that way Debian has to support just N independant packages, not NxN possible user configurations. Cheers, B. ___ 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] CPython and C++ object GC
Csaba Balazs wrote: > Hello Everybody, > > I would like to use a C++ gui library with the following (simplified) > interface > in Python. This is a question for python-list/comp.lang.python (i.e. development *using* Python, including the C API), not python-dev (which is for development of the language itself). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ 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] CPython and C++ object GC
Nick Coghlan wrote: Csaba Balazs wrote: Hello Everybody, I would like to use a C++ gui library with the following (simplified) interface in Python. This is a question for python-list/comp.lang.python (i.e. development *using* Python, including the C API), not python-dev (which is for development of the language itself). There's also the capi-sig mailing list, http://mail.python.org/mailman/listinfo/capi-sig. ___ 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] CPython and C++ object GC
Hello Everybody,
I would like to use a C++ gui library with the following (simplified) interface
in Python.
#include
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
___
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] "setuptools has divided the Python community"
On Fri, Mar 27, 2009 at 4:27 PM, Barry Warsaw wrote: > On Mar 27, 2009, at 2:27 PM, Eric Smith wrote: >> Olemis Lang wrote: I also think the feature should go. If you want functionality that's so difficult to provide when you install as a zip file, the answer is not to make things more complex, but to not install as zip files. >>> What about environments like Google App Engine ? I mean, AFAIK using >>> ZIP files is the *official* solution to meet some quotas & >>> requirements ... CMIIW anyway ... >> >> I mentioned yesterday (in the language summit) that we really need to get >> all the requirements together before we start any work. I fear that there >> are many hidden requirements (or ones that I'm personally not aware of, at I remembered another similar use case (which is mentioned in PEP 302 -motivation AFAICR- ) ... what about importing Py modules/pkgs packaged in .JAR files to be used in Jython ? ... Hm? I dont think its a good idea so far to remove zip imports | installs and similar ... at least I'll need further arguments and solutions to concrete use cases to understand this decision a little bit better... ;) >> least). I don't know gettext well enough give an answer yet. > > The class-based API for gettext takes streams, so resource_stream() would > work just fine. I think i18n plugins for Python do not necessarily need to > use the classic gettext API. > In fact ... I use Babel (... especially Translations & Locale classes ;) quite often ... :P Besides web frameworks and apps also need specific artifacts (e.g. Genshi template filters for i18n ...) to fully accomplish these tasks ... ;o) -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article: Comandos : Pipe Viewer ... ¿Qué está pasando por esta tubería? ___ 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] My summit notes (packaging)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tarek Ziadé wrote: > On Fri, Mar 27, 2009 at 9:54 PM, Kevin Teague wrote: > >> >> Tarek, was there any further discussion on "Requires" vs "install_requires" >> or any decisions made on what to do about this? >> >> (I've got a +1 ready for including 'install_requires' in the standard >> package metadata and marking 'Requires' as deprecated if that was put forth >> :P) > > Yes that is what we were thinking of doing. (deprectating Requires and > Provides and and install_requires) 'Provides' could actually be a potentially useful missing feature in setuptools, if it meant "virtual distutils project" rather than "specific module or package." Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ0MxT+gerLs4ltQ4RAgldAJ0Y0arjMeQJYK/G/6pkLqj2WV/Y/gCeL8b9 WnN4ZUWoaZUcFEysEWYsyXE= =wOf2 -END PGP SIGNATURE- ___ 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] 3to2 Project
During the Language summit this past Thursday, pretty much everyone agreed that a python 3 to python 2 tool would be a very large improvement in helping developers be able to write "pure" python 3 code. The idea being a large project such as Django could completely cut over to Python3, but then run the 3to2 tool on the code based to continue to support version 2.x. I raised my hand to help move this along, I've spoke to Benjamin Peterson, and he's amendable to mentoring a GSoC student for this project and he's already received at least one proposal for this. Additionally, there's been a number of developers here at PyCon who are more than ready to help contribute. So, if people are interested in helping, coordinating work/etc - feel free to sync up with Benjamin - he's started a wiki page here: http://wiki.python.org/moin/3to2 I'll help coordinate where I can! -Jesse ___ 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] And the winner is...
Dear Python developers, The decision is made! I've selected a DVCS to use for Python. We're switching to Mercurial (Hg). The implementation and schedule is still up in the air -- I am hoping that we can switch before the summer. It's hard to explain my reasons for choosing -- like most language decisions (especially the difficult ones) it's mostly a matter of gut feelings. One thing I know is that it's better to decide now than to spend another year discussing the pros and cons. All that could be said has been said, pretty much, and my mind is made up. To me, the advantages of using *some* DVCS are obvious. At PyCon, Brett already announced that Git was no longer being considered -- while it has obviously many fans, it also provokes strong antipathies. So it was between Hg and Bzr (both of which happen to be implemented in Python FWIW). Based on a completely unscientific poll (basically whatever feedback I received in my personal inbox or on Twitter), Hg has a strong following among Python developers and few detractors, while few (except Canonical employees) seem to like Bzr. In addition, most timing experiments point towards Hg being faster than Bzr for most operations, and Hg is (again, subjectively) easier to learn for SVN users than Bzr. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] CMake Evaluation
Hi,
I noticed the thread on CMake evaluation, and as a CMake developer I am
interested in helping you evaluate CMake.
I guess four issues were raised:
>A. It has no equivalent of autoheader, so we'd have to maintain
pyconfig.h.in by hand.
This is currently true, but if this were a deal breaker, I am sure
something could be added to CMake to accommodate the need. It might even
be possible to create a CMake function that does something like this
without having to modify CMake itself.
>B. It does not allow the CMakeLists.txt file control the --help
output. This appears to be an intentional decision
(http://www.cmake.org/pipermail/cmake-promote/2006-May/95.html).
To replace it, they have an interactive mode (which asks you about
each possible option) and a -LH flag (which runs the whole configure
process and then tells you about the flags you could have set if you
knew about them).
CMake now has a cmake-gui (qt based application) for configuring a
project.
C. It does not allow the CMakeLists.txt file to see the command line,
so we can't stay backward compatible with the configure script, and
we'd have to replace flags like --with-pydebug with
-Dpydebug:bool=true. We could write a separate configure script to
mitigate this and the previous problem, but we'd have to keep that in
sync with CMakeLists.txt manually.
We have talked about adding this to CMake several times, and it is a
good idea. However, it has not been a huge issue for many projects.
D. It doesn't have an expression language, so to replace
ac_md_system=`echo $ac_sys_system |
tr -d '[/ ]' | tr '[[A-Z]]' '[[a-z]]'`
you have to write:
string(REGEX REPLACE "[/ ]" "" ac_md_system ${ac_sys_system})
string(TOLOWER ${ac_md_system} ac_md_system)
However, the above CMake script will work on any platform with CMake
installed, and does not use tr. Also, the CMake code for the above
should actually run faster as it is not running two processes with pipe
communication.
I would not think that this list of issues would be a deal breaker. The
benefits of CMake are a single build system that works cross platform.
Developers can use the native tools that they are used to using (VS IDE,
Xcode IDE, Eclipse IDE, nmake command line, gmake command line, etc.).
The original Python CMake work done by Alex, was done to support the
building of ParaView (www.paraview.org) on a Cray Xt5 computer using
CMake's cross-compilation support. This worked very well. The choice
is obviously yours to make, but if you have any specific questions about
CMake, I will lurk on this mailing list and try to answer them. I think
it would be a good fit for CMake to build Python, and make things easier
for some of our customers building ParaView which depends on Python on
machines like the Cray Xt5.
Thanks.
-Bill
___
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] And the winner is...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Guido van Rossum wrote: > The decision is made! I've selected a DVCS to use for Python. We're > switching to Mercurial (Hg). Bravo. - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:j...@jabber.org _/_/_/_/ _/_/_/_/_/ . _/_/ _/_/_/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/_/_/ _/_/_/_/ _/_/ "My name is Dump, Core Dump" _/_/_/_/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBSdDxSplgi5GaxT1NAQLacgP9GdVfg1LWpy4UakHrGC1MFMRV3PCZ9HuL B63k368rX/QOzYc67Y6smzTzKJUFsGCGCUsg70NTIxNwGLJIspBjQ46xKrcNRHYS nXvzT/WKRz5HgEMEHwDLXMFdsXWBsVAT5ZkiXZeGIa1WnPvWxmhqwJPd105JusqE BRH5dhg8MbU= =dnwD -END PGP SIGNATURE- ___ 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] ¿Nueva reunión mensual en Madrid ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Va tocando hacer una nueva reunión mensual en Madrid. ¿Propuestas de fecha y lugar?. La última vez estuvo bastante bien, aunque éramos poquitos. ¿Hacemos otra a la vuelta de semana santa?. - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:j...@jabber.org _/_/_/_/ _/_/_/_/_/ . _/_/ _/_/_/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/_/_/ _/_/_/_/ _/_/ "My name is Dump, Core Dump" _/_/_/_/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBSdD3x5lgi5GaxT1NAQI0PgQAoPtOHTNfc5HOqj6YhChWalVt7JHidouh v779NvzJ4BxepT/g6bs0N59twUX0zkodiRshc/9Hc4zKpXzTFJ3ku4f8yg2KFfL0 jH7A4EvRHrr2xWlcbYtB4qeorPhdRnsuuxfAX09LRdjD9m5VxGso/nVBSt0N5BMd nni9xP72/gM= =oInB -END PGP SIGNATURE- ___ 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] ¿Nueva reunión mensual en Madrid ?
Excuse me. Wrong mailing list. ___ 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] Test failures under Windows?
Hirokazu Yamamoto writes: > CRT Assertion was totally disabled before, but recently was enabled, > and workarounds were patched for problematic functions. (ex: fdopen > and dup) Probably this *patch* is not perfect. See > http://bugs.python.org/issue4804 Ah - that ticket may explain why my buildbot hadn't been having problems until recently, even though the -n option in test.bat was removed quite a while back. > I'm now +3/4 for the idea disabling assertion by default, > and enabling by startup option or environment variable. (Or enabling > by default and disabling by environment variable?) This is a bit more than I'm looking to have changed. I'm only discussing disabling the GUI assertions during buildbot test runs. It's fine if there are other circumstances when one might also want a mechanism to disable them, but I'd rather not intermingle such cases since there may be different pros and cons to different cases. The nature of the development process is that you're going to have issues at times which is why you're testing, and given the consequences of a pop-up box on an unattended build slave, it just seems very strange to me that there could be any good reason to leave a potential for such popups (which at this point is easy to disable) in the buildbot environment. -- David ___ 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] Evaluated cmake as an autoconf replacement
Hi, On Mon, Mar 30, 2009 at 1:22 AM, Christian Heimes wrote: > Jeffrey Yasskin wrote: > >> 1. It can autogenerate the Visual Studio project files instead of >> needing them to be maintained separately > > I'm familiar with the Unix and the Windows build system. More than a > year ago I went to a great deal of work to migrate the Windows builds > from VS 7.1 to VS 9.0. I'm in doubt that any automatic tool can create > configuration files that are as good as our hand made files. This of course depends on the definition of "as good as" ;-) Well, I have met Windows-only developers which use CMake because it is able to generate project files for different versions of Visual Studio, and praise it for that. > The VS project files support debug, non debug and profile guided > optimization builds for X86 and AMD64 including cross compilation of > AMD64 binaries. CMake supports different build configurations. > The project files are using multiple inheritance to > avoid duplication of options. No idea. Maybe it wouldn't be necessary ? With CMake you can just generate different buildtrees with different options, so you can get different behaviour in these trees. > The differences between Windows and Unix builds are fairly large, too. > On Windows lots of modules are built in and the remaining Python > extensions are build with VS directly. On Unix most modules are build as > shared libraries using distutils and setup.py. That's right. Is there actually a real reason for this ? When I posted the cmake files for python in 2007 I think they also worked for Windows,, but I didn't test this that much. > In my opinion any change to an automated system is a waste of precious > developer times and makes our Windows support worse. Seriously, I don't think so. In KDE, our (small group of) Windows developers are the ones which appreciate CMake most. At Kitware, support for Windows and MSVC is a primary feature of CMake, not an afterthought. Alex ___ 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] Evaluated cmake as an autoconf replacement
On Mon, Mar 30, 2009 at 12:09 AM, Neil Hodgson wrote: ... > while so I can't remember the details. The current Python project > files are hierarchical, building several DLLs and an EXE and I think > this was outside the scope of the tools I looked at. Not sure I understand. Having a project which builds (shared) libraries and executables which use them (and which maybe have to be executed later on during the build) is no problem for CMake, also with the VisualStudio projects. >From what I remember when I wrote the CMake files for python it was quite straight forward. Alex ___ 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] 3to2 Project
On Mon, Mar 30, 2009 at 7:44 AM, Jesse Noller wrote: > During the Language summit this past Thursday, pretty much everyone > agreed that a python 3 to python 2 tool would be a very large > improvement in helping developers be able to write "pure" python 3 > code. The idea being a large project such as Django could completely > cut over to Python3, but then run the 3to2 tool on the code based to > continue to support version 2.x. > > I raised my hand to help move this along, I've spoke to Benjamin > Peterson, and he's amendable to mentoring a GSoC student for this > project and he's already received at least one proposal for this. > > Additionally, there's been a number of developers here at PyCon who > are more than ready to help contribute. > > So, if people are interested in helping, coordinating work/etc - feel > free to sync up with Benjamin - he's started a wiki page here: > > http://wiki.python.org/moin/3to2 If anyone is interested in working on this during the PyCon sprints or otherwise, here are some easy, concrete starter projects that would really help move this along: - The core refactoring engine needs to be broken out from 2to3. In particular, the tests/ and fixes/ need to get pulled up a directory, out of lib2to3/. - Once that's done, lib2to3 should then be renamed to something like librefactor or something else that indicates its more general nature. This will allow both 2to3 and 3to2 to more easily share the core components. - If you're more performance-minded, 2to3 and 3to2 would benefit heavily from some work on the pattern matching system. The current pattern matcher is a fairly simple AST interpreter; compiling the patterns down to pure Python code would be a win, I believe. This is all pretty heavily tested, so you wouldn't run much risk of breaking it. Collin ___ 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 380 (yield from a subgenerator) comments
P.J. Eby wrote: Sure. But right now, the return value of a generator function *is the generator*. And you're free to ignore that, sure. But this is a "second" return value that only goes to a special place with special syntax -- without that syntax, you can't access it. But in the use cases where you'd actually want to make such a function return a value to begin with, it's because that value is the value you *really* want from the function -- the only reason it's a generator is because it needs to be paused and resumed along the way to getting that return value. How about if 'yield from' returns the generator object, and the return value is accessed with an attribute. g = yield from gen x = g.__value__ Or x = (yield from gen).__value__ Another possibility is to be able to break from a 'yield from' at some point and then continue it to get any final values. # yield values of sub generator g = yield from gen # get remaining unused value of sub generator x = g.next() ___ 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] Evaluated cmake as an autoconf replacement
On Tue, Mar 31, 2009 at 2:37 AM, Alexander Neundorf wrote: > On Mon, Mar 30, 2009 at 12:09 AM, Neil Hodgson wrote: > ... >> while so I can't remember the details. The current Python project >> files are hierarchical, building several DLLs and an EXE and I think >> this was outside the scope of the tools I looked at. > > Not sure I understand. > Having a project which builds (shared) libraries and executables which > use them (and which maybe have to be executed later on during the > build) is no problem for CMake, also with the VisualStudio projects. > >From what I remember when I wrote the CMake files for python it was > quite straight forward. I think Christian meant that since on windows, those are built with visual studio project files, but everywhere else, it is built with distutils, you can't use a common system without first converting everything to cmake for all the other platforms. Also, when converting a project from one build system to another, doing the 80 % takes 20 % in my experience. The most time consuming part is all small the details on not so common platforms. David ___ 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] 3to2 Project
On Mon, Mar 30, 2009 at 12:37 PM, Collin Winter wrote: > On Mon, Mar 30, 2009 at 7:44 AM, Jesse Noller wrote: >> During the Language summit this past Thursday, pretty much everyone >> agreed that a python 3 to python 2 tool would be a very large >> improvement in helping developers be able to write "pure" python 3 >> code. The idea being a large project such as Django could completely >> cut over to Python3, but then run the 3to2 tool on the code based to >> continue to support version 2.x. >> >> I raised my hand to help move this along, I've spoke to Benjamin >> Peterson, and he's amendable to mentoring a GSoC student for this >> project and he's already received at least one proposal for this. >> >> Additionally, there's been a number of developers here at PyCon who >> are more than ready to help contribute. >> >> So, if people are interested in helping, coordinating work/etc - feel >> free to sync up with Benjamin - he's started a wiki page here: >> >> http://wiki.python.org/moin/3to2 > > If anyone is interested in working on this during the PyCon sprints or > otherwise, here are some easy, concrete starter projects that would > really help move this along: > - The core refactoring engine needs to be broken out from 2to3. In > particular, the tests/ and fixes/ need to get pulled up a directory, > out of lib2to3/. > - Once that's done, lib2to3 should then be renamed to something like > librefactor or something else that indicates its more general nature. > This will allow both 2to3 and 3to2 to more easily share the core > components. > - If you're more performance-minded, 2to3 and 3to2 would benefit > heavily from some work on the pattern matching system. The current > pattern matcher is a fairly simple AST interpreter; compiling the > patterns down to pure Python code would be a win, I believe. This is > all pretty heavily tested, so you wouldn't run much risk of breaking > it. > A second note on performance, is that Benjamin was about to checkin a version of 3to2 which used multiprocessing to help speed it up a bit - he had to catch a plane, so he should have it done some time shortly. -jesse ___ 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 380 (yield from a subgenerator) comments
Ron Adam wrote: P.J. Eby wrote: Sure. But right now, the return value of a generator function *is the generator*. And you're free to ignore that, sure. But this is a "second" return value that only goes to a special place with special syntax -- without that syntax, you can't access it. But in the use cases where you'd actually want to make such a function return a value to begin with, it's because that value is the value you *really* want from the function -- the only reason it's a generator is because it needs to be paused and resumed along the way to getting that return value. How about if 'yield from' returns the generator object, and the return value is accessed with an attribute. g = yield from gen x = g.__value__ Or x = (yield from gen).__value__ Another possibility is to be able to break from a 'yield from' at some point and then continue it to get any final values. # yield values of sub generator g = yield from gen # get remaining unused value of sub generator x = g.next() This could possibly be done in one line as well... x = (yield from gen).next() ___ 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] Python 3.0.2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 We made a decision at the sprints today about Python 3.0. We've agreed that there will be one more release, 3.0.2 and then that's it. Because of the earlier decision to drop all support for Python 3.0 once 3.1 is released, we won't be doing any more releases after that. I don't have an ETA for 3.0.2, but I'm happy to do it whenever it makes sense. Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSdEMYXEjvBPtnXfVAQLNLQP/XY9Wv3QvoqvEhgberz45inXqMpiMuhAL knw+tjtpwtizim4yXFR4EQxa0OhsAgqMPCe+m4CDTGSqcasQAa5iRkk5He5h0Z2C gBP3/DxfECb84r1aDuP4t1wCjqPmNq2T7kIiB7rTRTZktma/1vL2NH3zA4AErQnf b/wjc4zIExg= =kbT0 -END PGP SIGNATURE- ___ 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] Evaluated cmake as an autoconf replacement
On Mon, Mar 30, 2009 at 8:04 PM, David Cournapeau wrote: > On Tue, Mar 31, 2009 at 2:37 AM, Alexander Neundorf > wrote: ... >> Not sure I understand. >> Having a project which builds (shared) libraries and executables which >> use them (and which maybe have to be executed later on during the >> build) is no problem for CMake, also with the VisualStudio projects. >> >From what I remember when I wrote the CMake files for python it was >> quite straight forward. > > I think Christian meant that since on windows, those are built with > visual studio project files, but everywhere else, it is built with > distutils, you can't use a common system without first converting > everything to cmake for all the other platforms. Can you please explain ? What is "those" ? > Also, when converting a project from one build system to another, > doing the 80 % takes 20 % in my experience. Getting it working took me like 2 days, if that's 20% it's not too bad ;-) > The most time consuming > part is all small the details on not so common platforms. Yes. Alex ___ 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] Evaluated cmake as an autoconf replacement
On Tue, Mar 31, 2009 at 3:16 AM, Alexander Neundorf wrote: > > Can you please explain ? What is "those" ? Everything in Lib. On windows, I believe this is done through project files, but on linux at least, and I guess on most other OS, those are handled by distutils. I guess the lack of autoconf on windows is one reason for this difference ? > >> Also, when converting a project from one build system to another, >> doing the 80 % takes 20 % in my experience. > > Getting it working took me like 2 days, if that's 20% it's not too bad ;-) So it means ten days of work to convert to a new system that maybe most python maintainers do not know. What does it bring ? I think supporting cross compilation would be more worthwhile, for example, in the build department. cheers, David ___ 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] Evaluated cmake as an autoconf replacement
Hallo Alexander! Alexander Neundorf wrote: > This of course depends on the definition of "as good as" ;-) > Well, I have met Windows-only developers which use CMake because it is > able to generate project files for different versions of Visual > Studio, and praise it for that. So far I haven't heard any complains about or feature requests for the project files. ;) Most Windows related issue where about the SxS assembly issues with the new MSVCRT library. The multitude of project files formats are an issue for most open source libraries. Each minor version of Python has only one supported version of Visual Studio due to possible issues with mixed MSVCRTs. 99% of all Windows users are using the official MSI package provided by Martin. We also have project files for VS 6.0, 7.1 and 8.0 in the PC/ subdirectory. The VS 8.0 are created from the VS 9.0 project files. The remaining projects are maintained manually. >> The VS project files support debug, non debug and profile guided >> optimization builds for X86 and AMD64 including cross compilation of >> AMD64 binaries. > > CMake supports different build configurations. Does it support all eight build configurations? (Debug, Release, PGO instrument, PGO update for X86 and X64) > No idea. Maybe it wouldn't be necessary ? With CMake you can just > generate different buildtrees with different options, so you can get > different behaviour in these trees. I don't know, too. > That's right. Is there actually a real reason for this ? > When I posted the cmake files for python in 2007 I think they also > worked for Windows,, but I didn't test this that much. As far as I remember DLL take considerable more time to load than shared libraries on Unix OSes. The VS project driven build also makes it possible to cross compile builds for Itanium and AMD64 platforms on a X86 Windows. Distutils doesn't support cross compilation so far. You have to ask Martin von Löwis and Mark Hammond for detailed information. >> In my opinion any change to an automated system is a waste of precious >> developer times and makes our Windows support worse. > > Seriously, I don't think so. > In KDE, our (small group of) Windows developers are the ones which > appreciate CMake most. > At Kitware, support for Windows and MSVC is a primary feature of > CMake, not an afterthought. Please understand my previous mail in the context of Python core development. For KDE it makes perfectly sense to use cmake. For Python on Windows I just don't see any relevant benefits. I'm not against a CMake approach if somebody else is able to pull it off. So +0 from me. Christian ___ 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] Evaluated cmake as an autoconf replacement
David Cournapeau wrote: > On Tue, Mar 31, 2009 at 3:16 AM, Alexander Neundorf > wrote: >> Can you please explain ? What is "those" ? > > Everything in Lib. On windows, I believe this is done through project > files, but on linux at least, and I guess on most other OS, those are > handled by distutils. I guess the lack of autoconf on windows is one > reason for this difference ? All modules under Modules/ and PC/ are build inside the VS project. Some dependencies like gzip, bzip2, openssl etc. are build inside the project, too. Other dependencies are using shell scripts and nmake. On Unix the builtin modules are compiled with a custom build system (Modules/Setup.* and friends). The shared libraries are build by a distutils script (setup.py) in the root folder of the Python distribution. I already explained the reasons for the Windows build in a previous mail about 15 minutes ago. Christian ___ 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] 3to2 Project
Ron Duplain and I have been working on this at the sprint. We're working on getting the necessary 3to2 fixes in place and verified first since dropping this in was quite simple. The fixes don't look to be too involved which should provide time for the recommended refactorings. Paul On Mon, Mar 30, 2009 at 1:05 PM, Jesse Noller wrote: > On Mon, Mar 30, 2009 at 12:37 PM, Collin Winter wrote: >> On Mon, Mar 30, 2009 at 7:44 AM, Jesse Noller wrote: >>> During the Language summit this past Thursday, pretty much everyone >>> agreed that a python 3 to python 2 tool would be a very large >>> improvement in helping developers be able to write "pure" python 3 >>> code. The idea being a large project such as Django could completely >>> cut over to Python3, but then run the 3to2 tool on the code based to >>> continue to support version 2.x. >>> >>> I raised my hand to help move this along, I've spoke to Benjamin >>> Peterson, and he's amendable to mentoring a GSoC student for this >>> project and he's already received at least one proposal for this. >>> >>> Additionally, there's been a number of developers here at PyCon who >>> are more than ready to help contribute. >>> >>> So, if people are interested in helping, coordinating work/etc - feel >>> free to sync up with Benjamin - he's started a wiki page here: >>> >>> http://wiki.python.org/moin/3to2 >> >> If anyone is interested in working on this during the PyCon sprints or >> otherwise, here are some easy, concrete starter projects that would >> really help move this along: >> - The core refactoring engine needs to be broken out from 2to3. In >> particular, the tests/ and fixes/ need to get pulled up a directory, >> out of lib2to3/. >> - Once that's done, lib2to3 should then be renamed to something like >> librefactor or something else that indicates its more general nature. >> This will allow both 2to3 and 3to2 to more easily share the core >> components. >> - If you're more performance-minded, 2to3 and 3to2 would benefit >> heavily from some work on the pattern matching system. The current >> pattern matcher is a fairly simple AST interpreter; compiling the >> patterns down to pure Python code would be a win, I believe. This is >> all pretty heavily tested, so you wouldn't run much risk of breaking >> it. >> > > A second note on performance, is that Benjamin was about to checkin a > version of 3to2 which used multiprocessing to help speed it up a bit - > he had to catch a plane, so he should have it done some time shortly. > > -jesse > ___ > 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/kippesp%2Bpythondev%40gmail.com > ___ 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 3.0.2
Barry Warsaw wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 We made a decision at the sprints today about Python 3.0. We've agreed that there will be one more release, 3.0.2 and then that's it. Because of the earlier decision to drop all support for Python 3.0 once 3.1 is released, we won't be doing any more releases after that. I don't have an ETA for 3.0.2, but I'm happy to do it whenever it makes sense. Perhaps midway between 3.0.1 and 3.1, which would likely be late April. ___ 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] Evaluated cmake as an autoconf replacement
On Mon, Mar 30, 2009 at 8:49 PM, Christian Heimes wrote: > David Cournapeau wrote: >> On Tue, Mar 31, 2009 at 3:16 AM, Alexander Neundorf >> wrote: >>> Can you please explain ? What is "those" ? >> >> Everything in Lib. On windows, I believe this is done through project >> files, but on linux at least, and I guess on most other OS, those are >> handled by distutils. I guess the lack of autoconf on windows is one >> reason for this difference ? > > All modules under Modules/ and PC/ are build inside the VS project. Some > dependencies like gzip, bzip2, openssl etc. are build inside the > project, too. Other dependencies are using shell scripts and nmake. AFAIK we also have cmake-based builds for gzip, bzip2 and other dependencies KDE needs somewhere. > On Unix the builtin modules are compiled with a custom build system > (Modules/Setup.* and friends). The shared libraries are build by a > distutils script (setup.py) in the root folder of the Python distribution. With CMake I was also building the Modules directly with CMake, i.e. not using distutils, so these were already taken care of. In Lib/ there are only python files, and they should be compiled to pyc files, right ? I didn't do this back then. We are right now getting better support for this in KDE, which would probably help here: http://lists.kde.org/?l=kde-buildsystem&m=123795136609498&w=2 Alex ___ 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 3.0.2
On Mon, Mar 30, 2009 at 12:02, Terry Reedy wrote: > Barry Warsaw wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> We made a decision at the sprints today about Python 3.0. We've agreed >> that there will be one more release, 3.0.2 and then that's it. Because of >> the earlier decision to drop all support for Python 3.0 once 3.1 is >> released, we won't be doing any more releases after that. >> >> I don't have an ETA for 3.0.2, but I'm happy to do it whenever it makes >> sense. >> > > Perhaps midway between 3.0.1 and 3.1, which would likely be late April. I would think that after 3.1 would be best to get any and all fixes that go into 3.1. -Brett ___ 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 3.0.2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 30, 2009, at 4:40 PM, Brett Cannon wrote: I would think that after 3.1 would be best to get any and all fixes that go into 3.1. That fits nicely with our general policy, so that the only difference with 3.0 is that we won't do any security-only releases after the final patch release. Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSdE+0HEjvBPtnXfVAQL4AQQAnYyOeFlVfitJvsJF5gPXJbz5D2BqH9OA 2B9lEuUpVBooaZpsu/CHHgTCUYAVsrqvVBYbRCwsfsvy1mMet7503703vCaJbzxc MyEBzaHllX6q8froEDc26tQC8aYUs2/kLUL9C9O/inhLAN/i/9HQI9keQ1oP5ubi JTM5Ryp1nVc= =2VJ8 -END PGP SIGNATURE- ___ 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] Broken import?
[Adding python-dev. I'm quoting the entire original message.]
> On Thu, Mar 19, 2009 at 6:40 PM, Fredrik Lundh
> wrote:
>> PS. Is it just me, or is import broken in 3.0? Consider this:
>>
>> $ more package\a.py
>> print("in a")
>>
>> import b
>>
>> def a():
>> print("here")
>>
>> def main():
>> b.b()
>>
>> $ more package\b.py
>> print("in b")
>>
>> import a
>>
>> def b():
>> a.a()
>>
>> Under 2.X, this prints "in a" "in b" and "here", as expected. Under
>> 3.0, using the "from . import" form for relative imports, it bombs out
>> with a:
>>
>> in a
>> in b
>> Traceback (most recent call last):
>> File "main.py", line 1, in
>> from package import a
>> File "package/a.py", line 3, in
>> from . import b
>> File "package\b.py", line 3, in
>> from . import a
>> ImportError: cannot import name a
>>
>> Sure, it's a recursive import, but there's no recursive dependency
>> here - nobody will access the module contents until the main program
>> calls the library. What am I missing?
On Mon, Mar 30, 2009 at 5:44 PM, Guido van Rossum wrote:
> I reproduced this, but it seems to have more to do with "from . import
> ..." than with the Python version. If I add the "from ." before each
> of the imports, "python -c 'import p.a' " fails with roughly the above
> traceback for any version of Python that supports this syntax, while
> without that it passes for any 2.x.
>
> If I use the "from ." syntax in a.py but not in b.py, "import p.a"
> passes but "import p.b" fails.
>
> I'll see if anyone present at the sprints has a clue.
Made some progress. Anything using "from import b" (where
is either '.' or 'p') will fail when b's import is not
completed. OTOH using "import p.b" works. I reduced it to:
p/a.py == "from p import b"
p/b.py == "import a"
python -c "import p.b"
The reason seems to be that until the outermost import (in this case
p.b) is completed, while sys.modules has the (incomplete) modules 'p',
'p.a' and 'p.b', the attributes p.a and p.b aren't added until after
their import is completed. Which it isn't during recursive import.
Apparently 'from import ' looks for the
attribute in the object. This is because
"from...import" can also be used to import objects other than modules
(e.g. "from M import C"). I'm guessing that setting the attribute is
delayed until the import is totally complete, because upon a failed
import we remove the half-imported module object from sys.modules, but
apparently we didn 't want to be in the business of removing the
attribute from the parent package, so that's only set after the import
is deemed successful.
At least, this is my hypothesis, thinking about it -- I might look at
the code later. :-)
The most portable solution is to avoid "from...import" and instead
write something like
import p.b as b
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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] And the winner is...
> We're switching to Mercurial (Hg). And two hours later, GNOME announces their migration to git is underway. I'd suspect a series of April Fools jokes, if it weren't two days early. :) -- Michael Urman ___ 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] Broken import?
On Mon, Mar 30, 2009 at 6:17 PM, Guido van Rossum wrote:
> [Adding python-dev. I'm quoting the entire original message.]
>
>> On Thu, Mar 19, 2009 at 6:40 PM, Fredrik Lundh
>> wrote:
>>> PS. Is it just me, or is import broken in 3.0? Consider this:
>>>
>>> $ more package\a.py
>>> print("in a")
>>>
>>> import b
>>>
>>> def a():
>>> print("here")
>>>
>>> def main():
>>> b.b()
>>>
>>> $ more package\b.py
>>> print("in b")
>>>
>>> import a
>>>
>>> def b():
>>> a.a()
>>>
>>> Under 2.X, this prints "in a" "in b" and "here", as expected. Under
>>> 3.0, using the "from . import" form for relative imports, it bombs out
>>> with a:
>>>
>>> in a
>>> in b
>>> Traceback (most recent call last):
>>> File "main.py", line 1, in
>>> from package import a
>>> File "package/a.py", line 3, in
>>> from . import b
>>> File "package\b.py", line 3, in
>>> from . import a
>>> ImportError: cannot import name a
>>>
>>> Sure, it's a recursive import, but there's no recursive dependency
>>> here - nobody will access the module contents until the main program
>>> calls the library. What am I missing?
>
> On Mon, Mar 30, 2009 at 5:44 PM, Guido van Rossum wrote:
>> I reproduced this, but it seems to have more to do with "from . import
>> ..." than with the Python version. If I add the "from ." before each
>> of the imports, "python -c 'import p.a' " fails with roughly the above
>> traceback for any version of Python that supports this syntax, while
>> without that it passes for any 2.x.
>>
>> If I use the "from ." syntax in a.py but not in b.py, "import p.a"
>> passes but "import p.b" fails.
>>
>> I'll see if anyone present at the sprints has a clue.
>
> Made some progress. Anything using "from import b" (where
> is either '.' or 'p') will fail when b's import is not
> completed. OTOH using "import p.b" works. I reduced it to:
>
> p/a.py == "from p import b"
> p/b.py == "import a"
> python -c "import p.b"
>
> The reason seems to be that until the outermost import (in this case
> p.b) is completed, while sys.modules has the (incomplete) modules 'p',
> 'p.a' and 'p.b', the attributes p.a and p.b aren't added until after
> their import is completed. Which it isn't during recursive import.
> Apparently 'from import ' looks for the
> attribute in the object. This is because
> "from...import" can also be used to import objects other than modules
> (e.g. "from M import C"). I'm guessing that setting the attribute is
> delayed until the import is totally complete, because upon a failed
> import we remove the half-imported module object from sys.modules, but
> apparently we didn 't want to be in the business of removing the
> attribute from the parent package, so that's only set after the import
> is deemed successful.
>
> At least, this is my hypothesis, thinking about it -- I might look at
> the code later. :-)
>
> The most portable solution is to avoid "from...import" and instead
> write something like
>
> import p.b as b
So it turns out that "from X import Y" compiles into this bytecode:
0 LOAD_CONST 0 (-1)
3 LOAD_CONST 1 (('Y',))
6 IMPORT_NAME 0 (X)
9 IMPORT_FROM 1 (Y)
12 STORE_NAME 1 (Y)
15 POP_TOP
The first three opcodes (through IMPORT_NAME) call __import__('X',
None, None, ('Y',)) and push the result on top of the stack; this
result is the toplevel package X. The IMPORT_FROM opcode is
essentially a getattr call that turns an AttributeError into an
ImportError exception. I changed p/a.py into
p = __import__('p', None, None, ['b'])
print(p.b)
and confirmed that it fails on the print() line in p.b.
Does anyone feel that this ought to be fixed?
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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] And the winner is...
Michael Urman wrote: We're switching to Mercurial (Hg). And two hours later, GNOME announces their migration to git is underway. I'd suspect a series of April Fools jokes, if it weren't two days early. :) Like Python, Gnome was/is using SVN and tested (at least) GIT, bzr, and hg mirrors, starting somewhat earlier than Python, for DVCS migration. As announced in January, the majority of *their* developers preferred GIT. They started conversion then, in January, and made a progress announcement on March 19 (not yesterday). http://permalink.gmane.org/gmane.comp.gnome.devel.announce/15 I fail to see any joke. Different people have different tool preferences. tjr ___ 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] And the winner is...
Just for curiosity's sake, could someone outline the five (or so) most significant pluses of hg relative to git? (My personal feeling is that any of the three is a huge improvement over subversion. I think git probably should have been written in Python with some stuff in C where necessary, and (perhaps) the hg guy really is right when he claims that Linus should have skipped git and used hg from the start. That notwithstanding, though, it kind of looks like git has won the mindshare war at this point, and I think the best hg can hope for from this point forward is a sort of *BSD to git's Linux. I do hope that it lives on, shutouts being fascist, etc. Aside: I once worked with the guy maintaining git, and he might have the greatest sum of talent plus humility of any programmer I ever met.) ___ 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] Broken import?
Guido van Rossum wrote:
On Mon, Mar 30, 2009 at 6:17 PM, Guido van Rossum wrote:
[Adding python-dev. I'm quoting the entire original message.]
On Thu, Mar 19, 2009 at 6:40 PM, Fredrik Lundh wrote:
PS. Is it just me, or is import broken in 3.0? Consider this:
[snip]
Sure, it's a recursive import, but there's no recursive dependency
here - nobody will access the module contents until the main program
calls the library. What am I missing?
Problems with recursive imports are a perennial topic on Python list. A
common suggestion is to refactor to avoid them.
On Mon, Mar 30, 2009 at 5:44 PM, Guido van Rossum wrote:
I reproduced this, but it seems to have more to do with "from . import
..." than with the Python version. If I add the "from ." before each
of the imports, "python -c 'import p.a' " fails with roughly the above
traceback for any version of Python that supports this syntax, while
without that it passes for any 2.x.
If I use the "from ." syntax in a.py but not in b.py, "import p.a"
passes but "import p.b" fails.
I'll see if anyone present at the sprints has a clue.
Made some progress. Anything using "from import b" (where
is either '.' or 'p') will fail when b's import is not
completed. OTOH using "import p.b" works. I reduced it to:
p/a.py == "from p import b"
p/b.py == "import a"
python -c "import p.b"
The reason seems to be that until the outermost import (in this case
p.b) is completed, while sys.modules has the (incomplete) modules 'p',
'p.a' and 'p.b', the attributes p.a and p.b aren't added until after
their import is completed. Which it isn't during recursive import.
Apparently 'from import ' looks for the
attribute in the object. This is because
"from...import" can also be used to import objects other than modules
(e.g. "from M import C"). I'm guessing that setting the attribute is
delayed until the import is totally complete, because upon a failed
import we remove the half-imported module object from sys.modules, but
apparently we didn 't want to be in the business of removing the
attribute from the parent package, so that's only set after the import
is deemed successful.
At least, this is my hypothesis, thinking about it -- I might look at
the code later. :-)
The most portable solution is to avoid "from...import"
When doing recursive imports (it seems to work fine otherwise).
and instead write something like
import p.b as b
So it turns out that "from X import Y" compiles into this bytecode:
0 LOAD_CONST 0 (-1)
3 LOAD_CONST 1 (('Y',))
6 IMPORT_NAME 0 (X)
9 IMPORT_FROM 1 (Y)
12 STORE_NAME 1 (Y)
15 POP_TOP
The first three opcodes (through IMPORT_NAME) call __import__('X',
None, None, ('Y',)) and push the result on top of the stack; this
result is the toplevel package X. The IMPORT_FROM opcode is
essentially a getattr call that turns an AttributeError into an
ImportError exception. I changed p/a.py into
p = __import__('p', None, None, ['b'])
print(p.b)
and confirmed that it fails on the print() line in p.b.
If I understand, you are saying that
from x import y
is equivalent in effect to
import x
y = x.y
del x
except that the binding of 'x' never happens.
This is pretty much what the (3.0.1) doc says: "The from form does not
bind the module name: it goes through the list of identifiers, looks
each one of them up in the module found in step (1), and binds the name
in the local namespace to the object thus found. " where step 1 is the
(completed) initialization of the module.
So it seems to me that the behavior Fredrik noticed is implied by the
doc. It could be main plainer though. I have not read Brett's proposed
import doc yet.
Does anyone feel that this ought to be fixed?
What would be the new doc?
Terry Jan Reedy
___
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] Broken import?
Terry Reedy wrote: Guido van Rossum wrote: The reason seems to be that until the outermost import (in this case p.b) is completed, while sys.modules has the (incomplete) modules 'p', 'p.a' and 'p.b', the attributes p.a and p.b aren't added until after their import is completed. Which it isn't during recursive import. Apparently 'from import ' looks for the attribute in the object. This is because "from...import" can also be used to import objects other than modules (e.g. "from M import C"). I'm guessing that setting the attribute is delayed until the import is totally complete, because upon a failed import we remove the half-imported module object from sys.modules, but apparently we didn 't want to be in the business of removing the attribute from the parent package, so that's only set after the import is deemed successful. I remember a pydev discussion on this point. ___ 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] 3to2 Project
2009/3/30 Collin Winter : > If anyone is interested in working on this during the PyCon sprints or > otherwise, here are some easy, concrete starter projects that would > really help move this along: > - The core refactoring engine needs to be broken out from 2to3. In > particular, the tests/ and fixes/ need to get pulled up a directory, > out of lib2to3/. > - Once that's done, lib2to3 should then be renamed to something like > librefactor or something else that indicates its more general nature. > This will allow both 2to3 and 3to2 to more easily share the core > components. FWIW, I think it is unfortunately too late to make this change. We've already released it as lib2to3 in the standard library and I have actually seen it used in other projects. (PythonScope, for example.) -- Regards, Benjamin ___ 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] And the winner is...
On Mon, Mar 30, 2009 at 7:59 PM, Mike Coleman wrote: > Just for curiosity's sake, could someone outline the five (or so) most > significant pluses of hg relative to git? > > > (My personal feeling is that any of the three is a huge improvement > over subversion. I think git probably should have been written in > Python with some stuff in C where necessary, and (perhaps) the hg guy > really is right when he claims that Linus should have skipped git and > used hg from the start. That notwithstanding, though, it kind of > looks like git has won the mindshare war at this point, and I think > the best hg can hope for from this point forward is a sort of *BSD to > git's Linux. I do hope that it lives on, shutouts being fascist, etc. Yeah, I also think I'll just stop developing Python now and suggest that you all switch to Java, which has clearly won the mindshare war for languages. :-) > Aside: I once worked with the guy maintaining git, and he might have > the greatest sum of talent plus humility of any programmer I ever > met.) But is his humility enough to cancel out Linus's attitude? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] CMake Evaluation
On Mon, 30 Mar 2009 at 11:50, Bill Hoffman wrote: B. It does not allow the CMakeLists.txt file control the --help output. This appears to be an intentional decision (http://www.cmake.org/pipermail/cmake-promote/2006-May/95.html). To replace it, they have an interactive mode (which asks you about each possible option) and a -LH flag (which runs the whole configure process and then tells you about the flags you could have set if you knew about them). CMake now has a cmake-gui (qt based application) for configuring a project. A GUI is not a replacement for useful command line help :) -- R. David Murray http://www.bitdance.com ___ 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] And the winner is...
On Mon, Mar 30, 2009, Terry Reedy wrote: > Michael Urman wrote: >> Guido: >>> >>> We're switching to Mercurial (Hg). >> >> And two hours later, GNOME announces their migration to git is >> underway. I'd suspect a series of April Fools jokes, if it weren't two >> days early. :) > > Like Python, Gnome was/is using SVN and tested (at least) GIT, bzr, and > hg mirrors, starting somewhat earlier than Python, for DVCS migration. > As announced in January, the majority of *their* developers preferred > GIT. They started conversion then, in January, and made a progress > announcement on March 19 (not yesterday). > http://permalink.gmane.org/gmane.comp.gnome.devel.announce/15 > > I fail to see any joke. Different people have different tool preferences. As Michael said, joke suspicion comes from the timing. Combine that with Guido's previous post about the Van Lindberg clause... -- Aahz (a...@pythoncraft.com) <*> http://www.pythoncraft.com/ "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." --Brian W. Kernighan ___ 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] And the winner is...
On Mon, Mar 30, 2009 at 10:57 PM, Aahz wrote: > On Mon, Mar 30, 2009, Terry Reedy wrote: >> Michael Urman wrote: >>> Guido: We're switching to Mercurial (Hg). >>> >>> And two hours later, GNOME announces their migration to git is >>> underway. I'd suspect a series of April Fools jokes, if it weren't two >>> days early. :) >> >> Like Python, Gnome was/is using SVN and tested (at least) GIT, bzr, and >> hg mirrors, starting somewhat earlier than Python, for DVCS migration. >> As announced in January, the majority of *their* developers preferred >> GIT. They started conversion then, in January, and made a progress >> announcement on March 19 (not yesterday). >> http://permalink.gmane.org/gmane.comp.gnome.devel.announce/15 >> >> I fail to see any joke. Different people have different tool preferences. > > As Michael said, joke suspicion comes from the timing. AFAIC the only joke was that I announced the decision on Twitter first... > Combine that with Guido's previous post about the Van Lindberg clause... Um, that was on psf-members, which has much smaller audience than python-dev. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] And the winner is...
Guido van Rossum wrote: > On Mon, Mar 30, 2009 at 7:59 PM, Mike Coleman wrote: >> Just for curiosity's sake, could someone outline the five (or so) most >> significant pluses of hg relative to git? >> >> >> (My personal feeling is that any of the three is a huge improvement >> over subversion. I think git probably should have been written in >> Python with some stuff in C where necessary, and (perhaps) the hg guy >> really is right when he claims that Linus should have skipped git and >> used hg from the start. That notwithstanding, though, it kind of >> looks like git has won the mindshare war at this point, and I think >> the best hg can hope for from this point forward is a sort of *BSD to >> git's Linux. I do hope that it lives on, shutouts being fascist, etc. > > Yeah, I also think I'll just stop developing Python now and suggest > that you all switch to Java, which has clearly won the mindshare war > for languages. :-) > >> Aside: I once worked with the guy maintaining git, and he might have >> the greatest sum of talent plus humility of any programmer I ever >> met.) > > But is his humility enough to cancel out Linus's attitude? > All the humility in the world pales besides Linus's attitude. But that's probably just because we are all fools. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ Want to know? Come to PyCon - soon! http://us.pycon.org/ ___ 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] And the winner is...
Mike Coleman writes: > Just for curiosity's sake, could someone outline the five (or so) > most significant pluses of hg relative to git? I think really it comes down to Guido's intuition. However, without attempting to channel Guido, as the git proponent in the PEP I'd like to go on record as saying that I'm quite satisfied with the outcome. The main thing is that git strongly encourages direct manipulation of the commit DAG, in the way that Lisp encourages direct manipulation of lists (even more so than Python does!) This opens the door to dramatic changes in the public workflow over time, viz. movement toward a Linux-kernel-like workflow. But the BDFL is not Linus, and Python is not the Linux kernel. My feeling (as the git proponent in the PEP who was surprised about the pushback I felt) is that some Python developers are visceral conservatives about workflow. Even cracking that door is unnerving. And most would rather avoid changes in the *community* workflow, despite eagerly looking forward to the changes in *personal* workflow that any of the distributed VCSes will enable. My feeling is that in that context, it's not a matter of which is "best". They're all good. But from the point of view of maintaining the good points of the current workflow, while enabling experiment and improvement by individual developers, I think Mercurial is most conservative alternative of the three. I also just wrote a long post about the comparison of bzr to hg responding to a comment on baz...@canonical.com. I won't recap it here but it might be of interest. > I think git probably should have been written in Python with some > stuff in C where necessary, It wouldn't be that hard to do a rewrite in Python, but the git programmers are mostly kernel people. They write in C and shell. No big deal -- except to Pythonistas. > and (perhaps) the hg guy really is right when he claims that Linus > should have skipped git and used hg from the start. Unlikely. As Terry says, people have different preferences for tools. The important one here is whether you see history as immutable fact and direct manipulations of the commit DAG as falsification, or not. People who lean toward the DAG as *recording* history will prefer Mercurial or Bazaar. People who tend to see the DAG as a tool for *presenting* changes will prefer git. ___ 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] CMake Evaluation
2009/3/31 R. David Murray : > On Mon, 30 Mar 2009 at 11:50, Bill Hoffman wrote: >>> >>> B. It does not allow the CMakeLists.txt file control the --help >> >> output. This appears to be an intentional decision >> (http://www.cmake.org/pipermail/cmake-promote/2006-May/95.html). >> To replace it, they have an interactive mode (which asks you about >> each possible option) and a -LH flag (which runs the whole configure >> process and then tells you about the flags you could have set if you >> knew about them). >> >> >> CMake now has a cmake-gui (qt based application) for configuring a >> project. > > A GUI is not a replacement for useful command line help :) You can also use ccmake, IIRC. Matthieu -- Information System Engineer, Ph.D. Website: http://matthieu-brucher.developpez.com/ Blogs: http://matt.eifelle.com and http://blog.developpez.com/?blog=92 LinkedIn: http://www.linkedin.com/in/matthieubrucher ___ 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
