Re: [Python-Dev] proto-pep: plugin proposal (for unittest)
On Fri, Jul 30, 2010 at 12:55 AM, Michael Foord fuzzy...@voidspace.org.uk wrote: ... The Plugin Class A sometimes-more-convenient way of creating plugins is to subclass the ``unittest2.events.Plugin`` class. By default subclassing ``Plugin`` will auto-instantiate the plugin and store the instance in a list of loaded plugins. Each plugin has a ``register()`` method that auto-hooks up all methods whose names correspond to events. Plugin classes may also provide ``configSection`` and ``commandLineSwitch`` class attributes which simplifies enabling the plugin through the command line and making available a section from the configuration file(s). What about using ABCs here instead ? The big advantage is that you don't force people to subclass your Plugin base class, and you get a registration mechanism for free. They would be able to explicitly register any class using : from unittest2.events import Plugin Plugin.register(MySuperPlugin) Regards Tarek -- Tarek Ziadé | http://ziade.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] proto-pep: plugin proposal (for unittest)
On 30/07/2010 11:09, Tarek Ziadé wrote: On Fri, Jul 30, 2010 at 12:55 AM, Michael Foord fuzzy...@voidspace.org.uk wrote: ... The Plugin Class A sometimes-more-convenient way of creating plugins is to subclass the ``unittest2.events.Plugin`` class. By default subclassing ``Plugin`` will auto-instantiate the plugin and store the instance in a list of loaded plugins. Each plugin has a ``register()`` method that auto-hooks up all methods whose names correspond to events. Plugin classes may also provide ``configSection`` and ``commandLineSwitch`` class attributes which simplifies enabling the plugin through the command line and making available a section from the configuration file(s). What about using ABCs here instead ? The big advantage is that you don't force people to subclass your Plugin base class, Is that an advantage? Subclassing Plugin provides functionality rather than particularly an interface. and you get a registration mechanism for free. Actually it looks like it would be *extra* code. (The registration mechanism is already free to the programmer when they subclass.) I will investigate this, but if the only benefit it provides is you don't have to subclass then I'm not sure there is any point. Note that the Plugin class is only sugar over hooking up to the events directly *anyway*, so there is no *need* to use Plugin to write extensions. I'm going to read your blog entry on the topic to evaluate it properly though: https://tarekziade.wordpress.com/2009/05/01/basic-plugin-system-using-abcs-and-the-extensions-package/ Michael They would be able to explicitly register any class using : from unittest2.events import Plugin Plugin.register(MySuperPlugin) Regards Tarek -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ 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] Basic Information about Python
Hi All, I am new to python based application developement. I am using Windows XP. 1. Can I create desktop application (just hello world program) with Python language like exe in VC++? 2. If First statement is Yes, Can I include this application with my existing setup(assume 10 MB) for windows? 3. If Second statement is Yes, What will be the setup size? Thank in advance. Regards, Durga. ___ 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] Basic Information about Python
Hello. We are sorry but we cannot help you. This mailing list is to work on developing Python (adding new features to Python itself and fixing bugs); if you're having problems learning, understanding or using Python, please find another forum. Probably python-list/comp.lang.python mailing list/news group is the best place; there are Python developers who participate in it; you may get a faster, and probably more complete, answer there. See http://www.python.org/community/ for other lists/news groups/fora. Thank you for understanding. On Fri, Jul 30, 2010 at 05:48:45PM +0530, Durga D wrote: Hi All, I am new to python based application developement. I am using Windows XP. 1. Can I create desktop application (just hello world program) with Python language like exe in VC++? 2. If First statement is Yes, Can I include this application with my existing setup(assume 10 MB) for windows? 3. If Second statement is Yes, What will be the setup size? Thank in advance. Regards, Durga. Oleg. -- Oleg Broytmanhttp://phd.pp.ru/p...@phd.pp.ru Programmers don't die, they just GOSUB without RETURN. ___ 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] Basic Information about Python
Thank you for your response. Regards, Durga. On Fri, Jul 30, 2010 at 6:05 PM, Oleg Broytman p...@phd.pp.ru wrote: Hello. We are sorry but we cannot help you. This mailing list is to work on developing Python (adding new features to Python itself and fixing bugs); if you're having problems learning, understanding or using Python, please find another forum. Probably python-list/comp.lang.python mailing list/news group is the best place; there are Python developers who participate in it; you may get a faster, and probably more complete, answer there. See http://www.python.org/community/ for other lists/news groups/fora. Thank you for understanding. On Fri, Jul 30, 2010 at 05:48:45PM +0530, Durga D wrote: Hi All, I am new to python based application developement. I am using Windows XP. 1. Can I create desktop application (just hello world program) with Python language like exe in VC++? 2. If First statement is Yes, Can I include this application with my existing setup(assume 10 MB) for windows? 3. If Second statement is Yes, What will be the setup size? Thank in advance. Regards, Durga. Oleg. -- Oleg Broytmanhttp://phd.pp.ru/p...@phd.pp.ru Programmers don't die, they just GOSUB without RETURN. ___ 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] proto-pep: plugin proposal (for unittest)
For those of you who found this document perhaps just a little bit too long, I've written up a *much* shorter intro to the plugin system (including how to get the prototype) on my blog: http://www.voidspace.org.uk/python/weblog/arch_d7_2010_07_24.shtml#e1186 Michael On 29 July 2010 23:55, Michael Foord fuzzy...@voidspace.org.uk wrote: Hello all, My apologies in advance if email mangles whitespace in the code examples. I can reformulate as a PEP if that is deemed useful and this document can be found online at: http://hg.python.org/unittest2/file/tip/description.txt (Please excuse errors and omissions - but do feel free to point them out.) This is a description, and request for feedback, of the unittest plugin system that I am currently prototyping in the plugins branch of unittest2_. My goal is to merge the plugin system back into unittest itself in Python 3.2. .. _unittest2: http://hg.python.org/unittest2 As part of the prototype I have been implementing some example plugins (in unittest2/plugins/) so I can develop the mechanism against real rather than imagined use cases. Jason Pellerin, creator of nose, has been providing me with feedback and has been trying it out by porting some of the nose plugins to unittest [#]_. He comments on the system it looks very flexible and clean. ;-) Example plugins available and included: * a pep8 and pyflakes checker * a debugger plugin that drops you into pdb on test fail / error * a doctest loader (looks for doctests in all text files in the project) * use a regex for matching files in test discovery instead of a glob * growl notifications on test run start and stop * filter individual *test methods* using a regex * load test functions from modules as well as TestCases * integration with the coverage module for coverage reporting In addition I intend to create a plugin that outputs junit compatible xml from a test run (for integration with tools like the hudson continuous integration server) and a test runner that runs tests in parallel using multiprocessing. Not all of these will be included in the merge to unittest. Which ones will is still an open question. I'd like feedback on the proposal, and hopefully approval to port it into unittest after discussion / amendment / completion. In particular I'd like feedback on the basic system, plus which events should be available and what information should be available in them. Note that the system is *not* complete in the prototype. Enough is implemented to get the general idea and to formalise the full system. It still needs extensive tests and the extra work in TestProgram makes it abundantly clear that refactoring there is well overdue... In the details below open questions and todos are noted. I *really* value feedback (but will ignore bikeshedding ;-) .. note:: Throughout this document I refer to the prototype implementation using names like ``unittest2.events.hooks``. Should this proposal be accepted then the names will live in the unittest package instead of unittest2. The core classes for the event system live in the current implementation in the ``unittest2.events`` namespace. Abstract unittest lacks a standard way of extending it to provide commonly requested functionality, other than subclassing and overriding (and reimplementing) parts of its behaviour. This document describes a plugin system already partially prototyped in unittest2. Aspects of the plugin system include: * an events mechanism where handlers can be registered and called during a test run * a Plugin class built over the top of this for easy creation of plugins * a configuration system for specifying which plugins should be loaded and for configuring individual plugins * command line integration * the specific set of events and the information / actions available to them As the plugin system essentially just adds event calls to key places it has few backwards compatibility issues. Unfortunately existing extensions that override the parts of unittest that call these events will not be compatible with plugins that use them. Framework authors who re-implement parts of unittest, for example custom test runners, may want to add calling these events in appropriate places. Rationale = Why a plugin system for unittest? unittest is the standard library test framework for Python but in recent years has been eclipsed in functionality by frameworks like nose and py.test. Among the reasons for this is that these frameworks are easier to extend with plugins than unittest. unittest makes itself particularly difficult to extend by using subclassing as its basic extension mechanism. You subclass and override behaviour in its core classes like the loader, runner and result classes. This means that where you have more than one extension working in the same area it is very hard for them to work together.
Re: [Python-Dev] proto-pep: plugin proposal (for unittest)
On Jul 30, 2010, at 11:38 AM, Michael Foord wrote: I'm going to read your blog entry on the topic to evaluate it properly though: https://tarekziade.wordpress.com/2009/05/01/basic-plugin-system-using-abcs- and-the-extensions-package/ Very interesting. For Mailman 3, I have YAPS (yet another plugin system) based on zope.interface and setuptools. Bazaar has its own plugin system which is different still. I bet there are as many plugin APIs as there are Python frameworks. (And isn't everything a framework these days? :) I'm glad to see discussion begin to focus on providing consolidation in the world of plugins for Python frameworks, and to begin to refactor basic functionality into common tools. I'd love to see a blessed plugin API promoted to the stdlib for Python 3.2. I think it has to address a number of issues: * Registration - How do third party plugins declare themselves to exist, and be enabled? Part of this seems to me to include interface declarations too. Is installation of the plugin enough to register it? How do end users enable and disable plugins that me be registered on their system? How do plugins describe themselves (provide short and log descriptions, declare options, hook into command line interfaces, etc.)? * Installation - How are plugins installed on the system? Do they have to appear in a special directory on the file system? Do they need special setup.py magic to write extra files? Do they need to live in a pre-defined namespace? * Discoverability - How do frameworks discover all the plugins that are available? Which available plugins claim to support a particular plugin-point? How to do strict type checking on plugins? Which plugins are enabled? I'm sure there are more. As always, I'd like to see simple APIs on both sides that cover the common 80%. Both Tarek's and Michael's posts and proto-peps are great starts. You guys should definitely write up a plugin PEP! -Barry signature.asc Description: 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] proto-pep: plugin proposal (for unittest)
On 30/07/2010 15:04, Barry Warsaw wrote: On Jul 30, 2010, at 11:38 AM, Michael Foord wrote: I'm going to read your blog entry on the topic to evaluate it properly though: https://tarekziade.wordpress.com/2009/05/01/basic-plugin-system-using-abcs- and-the-extensions-package/ Very interesting. For Mailman 3, I have YAPS (yet another plugin system) based on zope.interface and setuptools. Bazaar has its own plugin system which is different still. I bet there are as many plugin APIs as there are Python frameworks. (And isn't everything a framework these days? :) I'm glad to see discussion begin to focus on providing consolidation in the world of plugins for Python frameworks, and to begin to refactor basic functionality into common tools. I'd love to see a blessed plugin API promoted to the stdlib for Python 3.2. I think it has to address a number of issues: * Registration - How do third party plugins declare themselves to exist, and be enabled? Part of this seems to me to include interface declarations too. Is installation of the plugin enough to register it? How do end users enable and disable plugins that me be registered on their system? How do plugins describe themselves (provide short and log descriptions, declare options, hook into command line interfaces, etc.)? * Installation - How are plugins installed on the system? Do they have to appear in a special directory on the file system? Do they need special setup.py magic to write extra files? Do they need to live in a pre-defined namespace? * Discoverability - How do frameworks discover all the plugins that are available? Which available plugins claim to support a particular plugin-point? How to do strict type checking on plugins? Which plugins are enabled? I'm sure there are more. As always, I'd like to see simple APIs on both sides that cover the common 80%. Both Tarek's and Michael's posts and proto-peps are great starts. You guys should definitely write up a plugin PEP! Whilst in principle I agree with you... the plugin requirements for unittest(2) and disutils2 are very different. The biggest advantage of using ABCs in Tarek's post is around interfaces - you can ensure that registered plugins have the required interface. unittest doesn't *have* a required interface for plugins, which may optionally implement handlers for *any* of the unittest events and the rest of the functionality (configuration and command line interface integration) is provided by virtue of the subclassing. Explicit registration over implicit registration by subclassing is an interesting discussion, but I like the simplicity provided by just subclassing. unittest allows any namespace to provide a plugin but has no discoverability built in to it. Users specify which plugins they want to use (per project and per user), plugins are then activated by importing. Framework authors can load whichever plugins they want - it is probable that discoverability would be useful here. Automatic discoverability, a-la setuptools entry points, is not without its problems though. Tarek outlines some of these in a more recent blog post: https://tarekziade.wordpress.com/2010/07/25/plugins-system-thoughts-for-an-entry-points-replacement/ Again I think the *needs* of unittest and distutils are different, so I wonder if a single system can usefully suit both our needs (let alone universally support other systems). Definitely an area worth exploring though. Michael -Barry ___ 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/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (BOGUS AGREEMENTS) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ 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] proto-pep: plugin proposal (for unittest)
On Fri, Jul 30, 2010 at 4:04 PM, Barry Warsaw ba...@python.org wrote: .. * Registration - How do third party plugins declare themselves to exist, and be enabled? Part of this seems to me to include interface declarations too. Is installation of the plugin enough to register it? How do end users enable and disable plugins that me be registered on their system? How do plugins describe themselves (provide short and log descriptions, declare options, hook into command line interfaces, etc.)? * Installation - How are plugins installed on the system? Do they have to appear in a special directory on the file system? Do they need special setup.py magic to write extra files? Do they need to live in a pre-defined namespace? FWIW We are thinking about adding in distutils2 a system quite similar to the entry points setuptools has, but with extra abilities for the end user : - activate / deactivate plugins without having to remove the project that added them - configure globally if plugins are implicitely activated or not -- and maybe allow the distutils2 installer to ask the user when a plugin is detected if he wants it activate or not - provide a tool to browse them This will be done through files added in the dist-info/ dirs, with the new PEP 376 api we are adding to pkgutil The idea is that the end user should be able to have a full control on what's activated in his system, without relying on the developer choices Cheers Tarek -- Tarek Ziadé | http://ziade.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] proto-pep: plugin proposal (for unittest)
On Fri, Jul 30, 2010 at 4:04 PM, Barry Warsaw ba...@python.org wrote: You guys should definitely write up a plugin PEP! I am all for it, I am pretty sure we can come up with a generic tool that can be useful for many packages in the stdlib Starting this... -- Tarek Ziadé | http://ziade.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] proto-pep: plugin proposal (for unittest)
This is my first post to python-dev, so for those who might not know me, I'm the author of Pro Django and more recently, Pro Python. I haven't looked at the plugin landscape in a while, but I was very disappointed the last time I looked at how complex typical systems were in this regard. There seems to be entirely too much time spend worrying about type checking, interface requirements and the like. Python is based on simple ideas providing simple solutions, and I would argue that duck typing is a perfectly acceptable route to take. I'd suggest that any plugin system proposal start off simple and work up as needs arise, rather than trying to cover as many bases as possible at the outset. I know it doesn't cover all the bases yet (particularly with regard to discoverability), so I'm not throwing it in as a proper suggestion, but I'll point out that I wrote up a dead-simple plugin system a while back[1] that may provide a useful starting point for discussion. I haven't read the existing proposals yet, but I just wanted to breathe a word of caution into this before it gets too far into interfaces and whatnot. I'll be glad to help with any discussion that takes place on this, though. It'll be a good way to ease into the mailing list, since it's an area where I've already spent a good deal of thought. -Marty [1] http://martyalchin.com/2008/jan/10/simple-plugin-framework/ ___ 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] proto-pep: plugin proposal (for unittest)
On Fri, Jul 30, 2010 at 4:34 PM, Michael Foord fuzzy...@voidspace.org.uk wrote: ... Again I think the *needs* of unittest and distutils are different, so I wonder if a single system can usefully suit both our needs (let alone universally support other systems). Definitely an area worth exploring though. Yes, even if they do if for different needs, both projects want to do the same thing: to be easily extensible by third party project. If we can provide a generic tool for both unittest and distutils extensions use cases, that's great and that will probably be useful for other projects. If we fail, I doubt we will ever have a generic plugin system in the stdlib. But that worth trying I think, and having different use cases is good for this imho ___ 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] proto-pep: plugin proposal (for unittest)
On 30/07/2010 15:37, Tarek Ziadé wrote: On Fri, Jul 30, 2010 at 4:04 PM, Barry Warsawba...@python.org wrote: .. * Registration - How do third party plugins declare themselves to exist, and be enabled? Part of this seems to me to include interface declarations too. Is installation of the plugin enough to register it? How do end users enable and disable plugins that me be registered on their system? How do plugins describe themselves (provide short and log descriptions, declare options, hook into command line interfaces, etc.)? * Installation - How are plugins installed on the system? Do they have to appear in a special directory on the file system? Do they need special setup.py magic to write extra files? Do they need to live in a pre-defined namespace? FWIW We are thinking about adding in distutils2 a system quite similar to the entry points setuptools has, but with extra abilities for the end user : - activate / deactivate plugins without having to remove the project that added them - configure globally if plugins are implicitely activated or not -- and maybe allow the distutils2 installer to ask the user when a plugin is detected if he wants it activate or not - provide a tool to browse them This will be done through files added in the dist-info/ dirs, with the new PEP 376 api we are adding to pkgutil The idea is that the end user should be able to have a full control on what's activated in his system, without relying on the developer choices This system sounds great. unittest could certainly use it for discovering plugins provided by other packages. The question then is still how to decide which ones should be active for any individual project (just because a plugin is available doesn't mean you want it used for every project). A configuration system is still good for this, but that kind of negates the advantage of discovery if the user still has to configure the plugin *anyway*. For framework authors not using the default test runner (python -m unittest or unit2) this would be very useful. Michael Cheers Tarek -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ 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] proto-pep: plugin proposal (for unittest)
On 30/07/2010 15:41, Marty Alchin wrote: This is my first post to python-dev, so for those who might not know me, I'm the author of Pro Django and more recently, Pro Python. I haven't looked at the plugin landscape in a while, but I was very disappointed the last time I looked at how complex typical systems were in this regard. There seems to be entirely too much time spend worrying about type checking, interface requirements and the like. Python is based on simple ideas providing simple solutions, and I would argue that duck typing is a perfectly acceptable route to take. There is no type checking or interface requirements in my plugin proposal for unittest. It is essentially an event based system. I'd suggest that any plugin system proposal start off simple and work up as needs arise, rather than trying to cover as many bases as possible at the outset. I know it doesn't cover all the bases yet (particularly with regard to discoverability), so I'm not throwing it in as a proper suggestion, but I'll point out that I wrote up a dead-simple plugin system a while back[1] that may provide a useful starting point for discussion. Tarek and I will look at what common ground there is between our plugin needs and see if *that* can be usefully abstracted out. FWIW I think PEP 376 (as amended - needs updating I *believe*) for plugin installation and discovery probably covers most of the common ground anyway. For the actual plugins our two systems are very different. I haven't read the existing proposals yet, If you want to help us this may be a good place to start... ;-) Michael but I just wanted to breathe a word of caution into this before it gets too far into interfaces and whatnot. I'll be glad to help with any discussion that takes place on this, though. It'll be a good way to ease into the mailing list, since it's an area where I've already spent a good deal of thought. -Marty [1] http://martyalchin.com/2008/jan/10/simple-plugin-framework/ ___ 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/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ 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] proto-pep: plugin proposal (for unittest)
Le 30/07/2010 17:04, Michael Foord a écrit : There is no type checking or interface requirements in my plugin proposal for unittest. It is essentially an event based system. Event-based sounds good. unittest2 does have an interface IMO: configuration loading, plugin registration/activation, signal names. As you said, the common ground may be little more than an API to discover or register plugins, activate and configure them, and the design decision of using events and callbacks, but even this small subset is very much worth a PEP. Regards ___ 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] proto-pep: plugin proposal (for unittest)
On 30/07/2010 16:28, Éric Araujo wrote: Le 30/07/2010 17:04, Michael Foord a écrit : There is no type checking or interface requirements in my plugin proposal for unittest. It is essentially an event based system. Event-based sounds good. unittest2 does have an interface IMO: configuration loading, plugin registration/activation, signal names. It has an API, but the plugins are not interface based (so interface requirements don't need to be part of the plugin system). As you said, the common ground may be little more than an API to discover or register plugins, activate and configure them, and the design decision of using events and callbacks, but even this small subset is very much worth a PEP. PEP 376 is *very* promising for this part - well at least if the PLUGINS stuff becomes part of PEP 376, it doesn't seem to be mentioned at all at the moment. Based on what you and tarek are saying it *sounds* good though... (Metadata for packages to declare that they provide plugins for another package and an API for frameworks to discover installed plugins.) Michael Regards ___ 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/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ 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] proto-pep: plugin proposal (for unittest)
It has an API, but the plugins are not interface based (so interface requirements don't need to be part of the plugin system). Oh, I see. With duck-typing and ABCs, I don’t make a difference between protocols and interfaces in my head :) Also, the I in API does mean interface, but not imply bondage-and-discipline interface systems. PEP 376 is *very* promising for this part - well at least if the PLUGINS stuff becomes part of PEP 376, it doesn't seem to be mentioned at all at the moment. The dist-info directory introduced by PEP 376 will certainly be reused. Not sure if Tarek will want to edit PEP 376 (already accepted) to add plugins in metadata (provides-dist is in metadata, so having plugins here can make sense), or start a new PEP about a new concept in a new file. Regards ___ 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] unexpected import behaviour
On 29 July 2010 07:32, Daniel Waterworth da.waterwo...@gmail.com wrote:
Hi,
I'm not sure if this is a bug or not, I certainly didn't expect it. If
you create a file called test.py with the following contents,
class Test:
pass
def test_1():
import test
print Test == test.Test
if __name__ == '__main__':
test_1()
and then run it ($ python test.py), it'll print False. Now try:
$python
import test
test.test_1()
and it'll print True. Is this behaviour expected? What was the
rationale for it if is?
Thanks,
Daniel
--
active-thought.com
@Oleg: I know this list is plagued by people who should be on
comp.lang.python, but I assure you I'm not looking to learn to program
in python, in fact I've been programming competently in python for
many years. This is purely CPython bug-fixing/the discussion of
implementation choices.
@ Nick: In terms of backward compatibility, it would only break
someone's code if they were relying on having the same module imported
twice as different instances. Could this behaviour be added to
python3.2? I'm not sure how far you are through the release cycle. Or
even just a warning as Michael suggested?
@Michael: Yes, I guessed as much. In fact adding,
import sys, os
if globals().get(__file__) and __name__=='__main__':
base = os.path.basename(__file__)
ext = base.rfind('.')
if ext 0:
main_name = base[:ext]
else:
main_name = base
sys.modules[main_name] = __import__('__main__')
to the beginning of a file solves the problem, but seems more than a
little hacky and I think I've missed edge cases with packages.
Thanks for your answers,
Daniel
--
active-thought.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
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2010-07-23 - 2010-07-30) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 2804 open (+45) / 18443 closed (+27) / 21247 total (+72) Open issues with patches: 1151 Average duration of open issues: 689 days. Median duration of open issues: 481 days. Open Issues Breakdown open 2760 (+45) languishing16 ( +0) pending27 ( +0) Issues Created Or Reopened (79) ___ Add named tuple reader to CSV module 2010-07-25 http://bugs.python.org/issue1818reopened rhettinger patch MatchObject is not a hyperlink in the 're' module documentatio 2010-07-28 CLOSED http://bugs.python.org/issue6538reopened tjreedy patch, easy SysLogHandler can't handle Unicode 2010-07-26 http://bugs.python.org/issue7077reopened georg.brandl Extraneous newlines with csv.writer on Windows 2010-07-28 CLOSED http://bugs.python.org/issue7198reopened skip.montanaro Create a bytes version of os.environ and getenvb() 2010-07-29 http://bugs.python.org/issue8603reopened ezio.melotti patch Add annotation option to pickletools.dis 2010-07-26 http://bugs.python.org/issue9268reopened belopolsky patch, easy urllib.quote(None) returns None in 2.7 (raised TypeError befor 2010-07-27 http://bugs.python.org/issue9301reopened flox patch Improve queue tests2010-07-23 CLOSED http://bugs.python.org/issue9357created bbrazil patch Document fnmatch.translate's lack of support for escaping 2010-07-23 CLOSED http://bugs.python.org/issue9358created bbrazil patch Misspelled exception 2010-07-23 CLOSED http://bugs.python.org/issue9359created kwadrat patch nntplib cleanup2010-07-23 http://bugs.python.org/issue9360created Dmitry.Jemerov patch Tests for leapdays in calendar.py module 2010-07-23 http://bugs.python.org/issue9361created John.Chandler patch Make exit/quit hint more novice friendly 2010-07-23 http://bugs.python.org/issue9362created belopolsky easy data_files are not installed relative to sys.prefix2010-07-23 http://bugs.python.org/issue9363created rioch some problems with the documentation of pydoc 2010-07-24 http://bugs.python.org/issue9364created eli.bendersky Installing a distro without sqlite3 will require a reinstall o 2010-07-24 CLOSED http://bugs.python.org/issue9365created antlong Reference leak for local new style class 2010-07-24 CLOSED http://bugs.python.org/issue9366created kayhayen test_getgroups in test_posix fails 2010-07-24 CLOSED http://bugs.python.org/issue9367created DazWorrall patch Const-Correctness for Method
Re: [Python-Dev] proto-pep: plugin proposal (for unittest)
On Jul 30, 2010, at 6:23 AM, Michael Foord wrote: For those of you who found this document perhaps just a little bit too long, I've written up a *much* shorter intro to the plugin system (including how to get the prototype) on my blog: http://www.voidspace.org.uk/python/weblog/arch_d7_2010_07_24.shtml#e1186 Nice work. Raymond ___ 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] unexpected import behaviour
On Fri, Jul 30, 2010 at 07:26:26AM +0100, Daniel Waterworth wrote: @Oleg: ... This is purely CPython bug-fixing/the discussion of implementation choices. I am not sure it's a bug. By manipulating sys.path (or symlinks in the FS) one can import the same file as different modules as many times as [s]he wants. Should this be fixed for __main__? I doubt it. Instead of making __main__ a special case follow the rule: don't import the same module under different paths/names. Make your script simply from test import main main() Oleg. -- Oleg Broytmanhttp://phd.pp.ru/p...@phd.pp.ru Programmers don't die, they just GOSUB without RETURN. ___ 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] unexpected import behaviour
On 30/07/2010 17:59, Oleg Broytman wrote: On Fri, Jul 30, 2010 at 07:26:26AM +0100, Daniel Waterworth wrote: @Oleg: ... This is purely CPython bug-fixing/the discussion of implementation choices. I am not sure it's a bug. It isn't a bug but it's a very common *cause* of bugs, even for relatively experienced Python programmers (this exchange being another case in point). Michael By manipulating sys.path (or symlinks in the FS) one can import the same file as different modules as many times as [s]he wants. Should this be fixed for __main__? I doubt it. Instead of making __main__ a special case follow the rule: don't import the same module under different paths/names. Make your script simply from test import main main() Oleg. -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ 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] proto-pep: plugin proposal (for unittest)
On Fri, Jul 30, 2010 at 5:54 PM, Éric Araujo mer...@netwok.org wrote: It has an API, but the plugins are not interface based (so interface requirements don't need to be part of the plugin system). Oh, I see. With duck-typing and ABCs, I don’t make a difference between protocols and interfaces in my head :) Also, the I in API does mean interface, but not imply bondage-and-discipline interface systems. PEP 376 is *very* promising for this part - well at least if the PLUGINS stuff becomes part of PEP 376, it doesn't seem to be mentioned at all at the moment. The dist-info directory introduced by PEP 376 will certainly be reused. Not sure if Tarek will want to edit PEP 376 (already accepted) to add plugins in metadata (provides-dist is in metadata, so having plugins here can make sense), or start a new PEP about a new concept in a new file. What we want to do I think is to make dist-info a place when any file can be added, besides the ones described in PEP 376, then build the plugins proposal on this Regards ___ 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/ziade.tarek%40gmail.com -- Tarek Ziadé | http://ziade.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] unexpected import behaviour
On 30 July 2010 18:32, Michael Foord fuzzy...@voidspace.org.uk wrote:
On 30/07/2010 17:59, Oleg Broytman wrote:
On Fri, Jul 30, 2010 at 07:26:26AM +0100, Daniel Waterworth wrote:
@Oleg: ...
This is purely CPython bug-fixing/the discussion of
implementation choices.
I am not sure it's a bug.
It isn't a bug but it's a very common *cause* of bugs, even for relatively
experienced Python programmers (this exchange being another case in point).
Michael
By manipulating sys.path (or symlinks in the
FS) one can import the same file as different modules as many times as
[s]he wants. Should this be fixed for __main__? I doubt it. Instead of
making __main__ a special case follow the rule: don't import the same
module under different paths/names.
Make your script simply
from test import main
main()
Oleg.
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
READ CAREFULLY. By accepting and reading this email you agree, on behalf of
your employer, to release me from all obligations and waivers arising from
any and all NON-NEGOTIATED agreements, licenses, terms-of-service,
shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure,
non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have
entered into with your employer, its partners, licensors, agents and
assigns, in perpetuity, without prejudice to my ongoing rights and
privileges. You further represent that you have the authority to release me
from any BOGUS AGREEMENTS on behalf of your employer.
___
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/da.waterworth%40googlemail.com
Having thought it through thoroughly, my preference is for a warning.
I don't think it's a good practise to import the __main__ module by
filename, as renaming the file will break the code. I got stung after,
having dropped into a python interpreter shell and imported the
module, I executed a function that uses isinstance.
If a warning showed up after importing the module, explaining the
problem and suggested that I use __import__('__main__') instead, I
would have saved myself a fair amount of time debugging code. This is
another case of Explicit is better than implicit..
It also means that code that relies on the current behaviour will not be broken.
@Oleg: yes, but in the __main__ case, it's more difficult to tell that
you are importing something under a different name. I suppose the
proof is in the pudding, can anyone think of a case where someone has
been annoyed that, having imported that same module twice via
symlinks, they have had problems relating to modules being independent
instances?
Thanks,
Daniel
--
active-thought.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
[Python-Dev] configparser: `__name__` special key is mad
Hello guys,
I want to sum up all strange things about the behaviour of `__name__`, a
special key present in every section of a parser instance.
Hopefully it will be removed at once or in the worst case oficially deprecated
and removed in 3.4.
1. There is a special `__name__` key in every section.
2. Except for the DEFAULTSECT.
3. `__name__` key is set for every section read from a file.
4. and not when adding by `add_section()`.
5. if `__name__` does exist, it's not visible in `parser.options('section')`
6. but it is here: `parser.has_option('section', '__name__') == True`
7. and can be obtained by `parser.get('section', '__name__')`
8. and can be changed by `parser.set('section', '__name__', 'ANY VALUE')`
9. and can be removed by `parser.remove_option('section', '__name__')`
10. even if the value is changed by `parser.set()`, it won't be written back to
a file with `parser.write()`
All this looks like a feature that was not particularly complete and well
defined when it was first created. Or possibly, it became rotten with time and
now nobody is using it anyway. That way or the other, I couldn't come up with a
valid use case for `__name__` with the current implementation. It doesn't serve
any internal purpose and the *only* way you can actually get it is to
`parser.get('section', '__name__')` which returns 'section' anyway. About as
useless as it gets. Of course, one can go and take the internal
parser._sections data structure of the parser but that's evil.
If I were to say what to do with all this, I'd simply remove all mentions of a
special `__name__` key in configparser.py. I know that your default answer for
that kind of idea is no, backwards compatibility for the win. And I agree
with that. In this case however we have a concept that is so broken that you
can't actually use it.
Many of you are here for quite a long time, maybe someone can shed some light
on this. Maybe I'm missing something.
--
Best regards,
Łukasz Langa
tel. +48 791 080 144
WWW http://lukasz.langa.pl/
___
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] unexpected import behaviour
On Fri, Jul 30, 2010 at 07:46:44PM +0100, Daniel Waterworth wrote: can anyone think of a case where someone has been annoyed that, having imported that same module twice via symlinks, they have had problems relating to modules being independent instances? I've had problems with two instances of the same module imported after sys.path manipulations. Never had a problem with reimported scripts. Oleg. -- Oleg Broytmanhttp://phd.pp.ru/p...@phd.pp.ru Programmers don't die, they just GOSUB without RETURN. ___ 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] Bazaar branch of Python 2.7
Hello all! For those of you who use the Bazaar mirrors on Launchpad of the Python Subversion branches (dvcs ftw! :), I've just registered the Python 2.7 maintenance branch. It will take a little while to complete the import, but when it's done you can grab it with: % bzr branch lp:python/2.7 Series details are here: https://launchpad.net/python/2.7 Branch details are here: https://code.launchpad.net/~python-dev/python/2.7 Enjoy, -Barry signature.asc Description: 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] Is it intentional that sys.__debug__ = 1 is illegal in Python 2.7?
In working on making Python 2.7 available in Debian and Ubuntu, we ran into two packages that fail to byte compile against Python 2.7, where they are fine in Python 2.6. The Debian bug tracker issues are: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=590821 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=590822 Specifically, what fails now is assignment to the __debug__ attribute of a module, e.g. sys -- *not* builtin __debug__. % python2.6 Python 2.6.5 (r265:79063, Apr 16 2010, 13:57:41) [GCC 4.4.3] on linux2 Type help, copyright, credits or license for more information. __debug__ = 1 File stdin, line 1 SyntaxError: can not assign to __debug__ import sys sys.__debug__ = 1 % python2.7 Python 2.7.0+ (release27-maint:83294, Jul 30 2010, 15:49:51) [GCC 4.4.3] on linux2 Type help, copyright, credits or license for more information. __debug__ = 1 File stdin, line 1 SyntaxError: cannot assign to __debug__ import sys sys.__debug__ = 1 File stdin, line 1 SyntaxError: cannot assign to __debug__ I think it's actually somewhat questionable that this is now illegal. It certainly breaks at least two packages. More disturbing though is that I cannot find mention of this change in Misc/NEWS or in the tracker, so I don't actually know if this was intentional or not. It looks like Benjamin's change in r67171 was the relevant diff. Thoughts? Either way I will file a bug. IOW, if this change should *not* have been made, I think it should be reverted for Python 2.7.1 and I can patch our version of Python in the meantime. If this change is intentional, I'll file a bug against (or just fix) Misc/NEWS and the What's New. Cheers, -Barry signature.asc Description: 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] Speeding up 2to3: Results from a GSOC Project
Hi everyone, I haven't had a chance to introduce myself yet. I'm George Boutsioukis, a CS student from Greece and I'm currently enrolled as a GSOC student for the PSF. The task I was involved with for the past few weeks was speeding up the 2to3 tool. For those who are not aware of 2to3's internals, the tool matches a series of tree patterns to a python syntax tree and applies a code transformation on each match. The real bottleneck of this tool is the tree pattern matching algorithm, since the current version traverses all nodes of the tree, top-to-bottom, and checks each node against a set of tree patterns. The new algorithm I've implemented reduces the candidate nodes for matching. The process works in three steps: 1) Each pattern tree is reduced to the most 'characteristic' path, i.e. the rarest path you'll encounter on a real code tree. (this is simpler than it sounds) 2) From the set of the above linear patterns an Aho-Corasick automaton is constructed that is capable of inclusively matching all patterns(meaning that it may mark a wrong candidate but will never miss an instance) 3) The automaton is run on each leaf until the root of the tree is reached and the resulting match set is returned. And finally we apply each fixer for each node in the match set. Of course the process is a bit more complicated since we have to recheck the transformed code for new matches etc. Since it is quite a hard concept to illustrate in a post, tell me if you have any questions or need more info. The benefit of this somewhat complex process is substantial; the total run time is reduced by roughly 50%. The new module is still experimental code, but mature enough to pass all tests. I propose to include the new module with the next version of Python, perhaps as an explicit option for 2to3 until it can be thoroughly tested. The code repository can be found here: https://code.google.com/p/2to3-speedup2/source/browse/ (the code is a fork from py3k's 2to3 and was tested with version 3.1.2) The blog I've been using for GSOC(containing more details on the matching algorithm): http://george-gsoc.blogspot.com/ Regards, George ___ 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] Is it intentional that sys.__debug__ = 1 is illegal in Python 2.7?
On Fri, Jul 30, 2010 at 1:26 PM, Barry Warsaw ba...@python.org wrote: In working on making Python 2.7 available in Debian and Ubuntu, we ran into two packages that fail to byte compile against Python 2.7, where they are fine in Python 2.6. The Debian bug tracker issues are: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=590821 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=590822 Specifically, what fails now is assignment to the __debug__ attribute of a module, e.g. sys -- *not* builtin __debug__. % python2.6 Python 2.6.5 (r265:79063, Apr 16 2010, 13:57:41) [GCC 4.4.3] on linux2 Type help, copyright, credits or license for more information. __debug__ = 1 File stdin, line 1 SyntaxError: can not assign to __debug__ import sys sys.__debug__ = 1 % python2.7 Python 2.7.0+ (release27-maint:83294, Jul 30 2010, 15:49:51) [GCC 4.4.3] on linux2 Type help, copyright, credits or license for more information. __debug__ = 1 File stdin, line 1 SyntaxError: cannot assign to __debug__ import sys sys.__debug__ = 1 File stdin, line 1 SyntaxError: cannot assign to __debug__ I think it's actually somewhat questionable that this is now illegal. It certainly breaks at least two packages. More disturbing though is that I cannot find mention of this change in Misc/NEWS or in the tracker, so I don't actually know if this was intentional or not. Well it is a reserved name so those packages that were setting it should have known that they were using undefined behavior that could change at any time. It looks like Benjamin's change in r67171 was the relevant diff. Thoughts? Either way I will file a bug. IOW, if this change should *not* have been made, I think it should be reverted for Python 2.7.1 and I can patch our version of Python in the meantime. If this change is intentional, I'll file a bug against (or just fix) Misc/NEWS and the What's New. -- --Guido van Rossum (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] Speeding up 2to3: Results from a GSOC Project
Great! CS FTW! --Guido On Fri, Jul 30, 2010 at 1:28 PM, George Boutsioukis gboutsiou...@gmail.com wrote: Hi everyone, I haven't had a chance to introduce myself yet. I'm George Boutsioukis, a CS student from Greece and I'm currently enrolled as a GSOC student for the PSF. The task I was involved with for the past few weeks was speeding up the 2to3 tool. For those who are not aware of 2to3's internals, the tool matches a series of tree patterns to a python syntax tree and applies a code transformation on each match. The real bottleneck of this tool is the tree pattern matching algorithm, since the current version traverses all nodes of the tree, top-to-bottom, and checks each node against a set of tree patterns. The new algorithm I've implemented reduces the candidate nodes for matching. The process works in three steps: 1) Each pattern tree is reduced to the most 'characteristic' path, i.e. the rarest path you'll encounter on a real code tree. (this is simpler than it sounds) 2) From the set of the above linear patterns an Aho-Corasick automaton is constructed that is capable of inclusively matching all patterns(meaning that it may mark a wrong candidate but will never miss an instance) 3) The automaton is run on each leaf until the root of the tree is reached and the resulting match set is returned. And finally we apply each fixer for each node in the match set. Of course the process is a bit more complicated since we have to recheck the transformed code for new matches etc. Since it is quite a hard concept to illustrate in a post, tell me if you have any questions or need more info. The benefit of this somewhat complex process is substantial; the total run time is reduced by roughly 50%. The new module is still experimental code, but mature enough to pass all tests. I propose to include the new module with the next version of Python, perhaps as an explicit option for 2to3 until it can be thoroughly tested. The code repository can be found here: https://code.google.com/p/2to3-speedup2/source/browse/ (the code is a fork from py3k's 2to3 and was tested with version 3.1.2) The blog I've been using for GSOC(containing more details on the matching algorithm): http://george-gsoc.blogspot.com/ Regards, George ___ 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/guido%40python.org -- --Guido van Rossum (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] Is it intentional that sys.__debug__ = 1 is illegal in Python 2.7?
On Jul 30, 2010, at 01:42 PM, Guido van Rossum wrote: Well it is a reserved name so those packages that were setting it should have known that they were using undefined behavior that could change at any time. Shouldn't it be described here then? http://docs.python.org/reference/lexical_analysis.html#identifiers -Barry signature.asc Description: 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] Is it intentional that sys.__debug__ = 1 is illegal in Python 2.7?
On 30/07/2010 21:53, Barry Warsaw wrote: On Jul 30, 2010, at 01:42 PM, Guido van Rossum wrote: Well it is a reserved name so those packages that were setting it should have known that they were using undefined behavior that could change at any time. Shouldn't it be described here then? http://docs.python.org/reference/lexical_analysis.html#identifiers And raise a DeprecationWarning one release before becoming invalid syntax? Michael -Barry ___ 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/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (BOGUS AGREEMENTS) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ 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] proto-pep: plugin proposal (for unittest)
At 03:34 PM 7/30/2010 +0100, Michael Foord wrote: Automatic discoverability, a-la setuptools entry points, is not without its problems though. Tarek outlines some of these in a more recent blog post: FWIW, it's not discovery that's the problem, but configuring *which* plugins you wish to have active. Entry points support access by name, and it's up to the application using them to decide *which* ones to load. The underlying idea is that entry points expose a hook; it's up to the app to decide which ones it should actually import and use. An application also can list the available plugins and ask the user, etc.(For example, setuptools only loads setup() argument entry points for specified arguments, and command entry points only for the commands a user explicitly invokes.) IOW, entry points provide access to plugins, not policy or configuration for *which* plugins you wish to use. This was an intentional decision since applications vary widely in what sort of configuration mechanism they use. In the simplest cases (e.g. single-app environments like Chandler), simply making the plugin available on sys.path (e.g. via a special plugins directory) is configuration enough. In more complex use cases, an app might have to import plugins in order to get more information about them. ___ 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] proto-pep: plugin proposal (for unittest)
On 30/07/2010 21:56, P.J. Eby wrote: At 03:34 PM 7/30/2010 +0100, Michael Foord wrote: Automatic discoverability, a-la setuptools entry points, is not without its problems though. Tarek outlines some of these in a more recent blog post: FWIW, it's not discovery that's the problem, but configuring *which* plugins you wish to have active. Entry points support access by name, and it's up to the application using them to decide *which* ones to load. The underlying idea is that entry points expose a hook; it's up to the app to decide which ones it should actually import and use. An application also can list the available plugins and ask the user, etc. (For example, setuptools only loads setup() argument entry points for specified arguments, and command entry points only for the commands a user explicitly invokes.) IOW, entry points provide access to plugins, not policy or configuration for *which* plugins you wish to use. This was an intentional decision since applications vary widely in what sort of configuration mechanism they use. In the simplest cases (e.g. single-app environments like Chandler), simply making the plugin available on sys.path (e.g. via a special plugins directory) is configuration enough. In more complex use cases, an app might have to import plugins in order to get more information about them. Right (and thanks), and in the unittest plugin system the user decides which plugins should be active by listing them explicitly in the configuration file. Discovery could be useful for a tool that tells the user which plugins are available and modify the config file *for them* to switch plugins on and off. Useful metadata would then be which config options a plugin supports (and their defaults) so they can be added to the config file too when a plugin is activated. Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ 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] unexpected import behaviour
At 11:50 PM 7/30/2010 +0400, Oleg Broytman wrote: On Fri, Jul 30, 2010 at 07:46:44PM +0100, Daniel Waterworth wrote: can anyone think of a case where someone has been annoyed that, having imported that same module twice via symlinks, they have had problems relating to modules being independent instances? I've had problems with two instances of the same module imported after sys.path manipulations. Never had a problem with reimported scripts. I have. The unittest module used to have this problem, when used as a script. ___ 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] proto-pep: plugin proposal (for unittest)
At 04:37 PM 7/30/2010 +0200, Tarek Ziadé wrote: On Fri, Jul 30, 2010 at 4:04 PM, Barry Warsaw ba...@python.org wrote: .. * Registration - How do third party plugins declare themselves to exist, and be enabled? Part of this seems to me to include interface declarations too. Is installation of the plugin enough to register it? How do end users enable and disable plugins that me be registered on their system? How do plugins describe themselves (provide short and log descriptions, declare options, hook into command line interfaces, etc.)? * Installation - How are plugins installed on the system? Do they have to appear in a special directory on the file system? Do they need special setup.py magic to write extra files? Do they need to live in a pre-defined namespace? FWIW We are thinking about adding in distutils2 a system quite similar to the entry points setuptools has, but with extra abilities for the end user : - activate / deactivate plugins without having to remove the project that added them - configure globally if plugins are implicitely activated or not -- and maybe allow the distutils2 installer to ask the user when a plugin is detected if he wants it activate or not - provide a tool to browse them Note, by the way, that none of these are mutually exclusive to the entry point mechanism; it is simply up to an application developer to decide which of those features he/she wishes to provide. A library that provides common implementations of such features on top of entry points would be a good idea. pkg_resources already supplies one such tool, btw: the find_plugins() API for locating projects in one or more plugin directories that *could* be added to sys.path to provide plugins for an application. It's then up to the application to filter this list further (e.g. via its own configuration). ___ 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] Is it intentional that sys.__debug__ = 1 is illegal in Python 2.7?
2010/7/30 Barry Warsaw ba...@python.org: On Jul 30, 2010, at 01:42 PM, Guido van Rossum wrote: Well it is a reserved name so those packages that were setting it should have known that they were using undefined behavior that could change at any time. Shouldn't it be described here then? http://docs.python.org/reference/lexical_analysis.html#identifiers Doesn't the section http://docs.python.org/reference/lexical_analysis.html#reserved-classes-of-identifiers make this clear enough ? -Barry ___ 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/ggpolo%40gmail.com -- -- Guilherme H. Polo Goncalves ___ 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] Speeding up 2to3: Results from a GSOC Project
Love it! BTW, it's not a good idea to have an import statement under 3 level of loops: https://code.google.com/p/2to3-speedup2/source/browse/trunk/lib2to3/refactor.py#427 -- Alexandre ___ 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] Is it intentional that sys.__debug__ = 1 is illegal in Python 2.7?
On Fri, Jul 30, 2010 at 1:53 PM, Barry Warsaw ba...@python.org wrote: On Jul 30, 2010, at 01:42 PM, Guido van Rossum wrote: Well it is a reserved name so those packages that were setting it should have known that they were using undefined behavior that could change at any time. Shouldn't it be described here then? http://docs.python.org/reference/lexical_analysis.html#identifiers No, since it is covered here: http://docs.python.org/reference/lexical_analysis.html#reserved-classes-of-identifiers -- --Guido van Rossum (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] Is it intentional that sys.__debug__ = 1 isillegal in Python 2.7?
First appeared in docs for 2.6 (October 02, 2008). Not sure if that is when it first because constrained this way. http://docs.python.org/library/constants.html?highlight=__debug__#__debug__ -eric -Original Message- From: python-dev-bounces+esnow=verio@python.org [mailto:python-dev-bounces+esnow=verio@python.org] On Behalf Of Guilherme Polo Sent: Friday, July 30, 2010 3:06 PM To: Barry Warsaw Cc: Guido van Rossum; Python-Dev Dev Subject: Re: [Python-Dev] Is it intentional that sys.__debug__ = 1 isillegal in Python 2.7? 2010/7/30 Barry Warsaw ba...@python.org: On Jul 30, 2010, at 01:42 PM, Guido van Rossum wrote: Well it is a reserved name so those packages that were setting it should have known that they were using undefined behavior that could change at any time. Shouldn't it be described here then? http://docs.python.org/reference/lexical_analysis.html#identifiers Doesn't the section http://docs.python.org/reference/lexical_analysis.html#reserved-classes-of-identifiers make this clear enough ? -Barry ___ 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/ggpolo%40gmail.com -- -- Guilherme H. Polo Goncalves ___ 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/esnow%40verio.net This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you. ___ 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] Is it intentional that sys.__debug__ = 1 is illegal in Python 2.7?
On Sat, 31 Jul 2010 07:44:42 am Guido van Rossum wrote: On Fri, Jul 30, 2010 at 1:53 PM, Barry Warsaw ba...@python.org wrote: On Jul 30, 2010, at 01:42 PM, Guido van Rossum wrote: Well it is a reserved name so those packages that were setting it should have known that they were using undefined behavior that could change at any time. Shouldn't it be described here then? http://docs.python.org/reference/lexical_analysis.html#identifiers No, since it is covered here: http://docs.python.org/reference/lexical_analysis.html#reserved-class es-of-identifiers I have a small concern about the wording of that, specifically this: System-defined names. These names are defined by the interpreter and its implementation (including the standard library); applications SHOULD NOT EXPECT TO DEFINE additional names using this convention. The set of names of this class defined by Python may be extended in future versions. [emphasis added] This implies to me that at some time in the future, Python may make it illegal to assign to any __*__ name apart from those in a list of approved methods. Is that the intention? I have always understood that if you create your own __*__ names, you risk clashing with a special method, but otherwise it is allowed, if disapproved off. I would not like to see it become forbidden. -- Steven D'Aprano ___ 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] pdb mini-sprint report and questions
Hi, to warm up for tomorrow's 3.2alpha1 release, I did a mini-sprint on pdb issues today. I'm pleased to report that 14 issues could be closed, and pdb got a range of small new features, such as commands on the command line, until lineno or longlist showing all the code for the current function (the latter courtesy of Antonio Cuni's pdb++). One issue that's not yet closed is #7245, which adds a (very nice IMO) feature: when you press Ctrl-C while the program being debugged runs, you will not get a traceback but execution is suspended, and you can debug from the current point of execution -- just like in gdb. However, there were apparently issues with some of the buildbots when the patch was applied for a short time. I also don't know how and if it works on Windows, so I'd need some helpful people testing it. Another question is about a feature of pdb++ that I personally would like, but imagine would make others unhappy: one-letter abbreviations of commands such as c(ontinue) or l(ist) are also often-used variable names, so they are frequently typed without the required ! or print that would distinguish them from the command, and the command is actually executed. The feature in question would default to printing the variable in cases where one exists -- handy enough or too inconsistent? Also, are there any other features you would like to see? One feature of pdb++ that is general enough and has no dependencies would be watch expressions... Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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] pdb mini-sprint report and questions
On Fri, Jul 30, 2010 at 3:45 PM, Georg Brandl g.bra...@gmx.net wrote: to warm up for tomorrow's 3.2alpha1 release, I did a mini-sprint on pdb issues today. I'm pleased to report that 14 issues could be closed, and pdb got a range of small new features, such as commands on the command line, until lineno or longlist showing all the code for the current function (the latter courtesy of Antonio Cuni's pdb++). One issue that's not yet closed is #7245, which adds a (very nice IMO) feature: when you press Ctrl-C while the program being debugged runs, you will not get a traceback but execution is suspended, and you can debug from the current point of execution -- just like in gdb. However, there were apparently issues with some of the buildbots when the patch was applied for a short time. I also don't know how and if it works on Windows, so I'd need some helpful people testing it. Another question is about a feature of pdb++ that I personally would like, but imagine would make others unhappy: one-letter abbreviations of commands such as c(ontinue) or l(ist) are also often-used variable names, so they are frequently typed without the required ! or print that would distinguish them from the command, and the command is actually executed. The feature in question would default to printing the variable in cases where one exists -- handy enough or too inconsistent? Warning: 'p' is *not* the same as 'print'. 'p' is a built-in command that prints the expression's repr(). 'print' OTOH falls back through the interpreter and executes a print statement or function, which prints the str(). For me personally, the problem this feature tries to address is never a problem (of course I am probably unique as far as pdb users go :-) so I'd like a way to turn it off. Also, are there any other features you would like to see? One feature of pdb++ that is general enough and has no dependencies would be watch expressions... Cool. -- --Guido van Rossum (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] pdb mini-sprint report and questions
Am 31.07.2010 01:01, schrieb Guido van Rossum: On Fri, Jul 30, 2010 at 3:45 PM, Georg Brandl g.bra...@gmx.net wrote: to warm up for tomorrow's 3.2alpha1 release, I did a mini-sprint on pdb issues today. I'm pleased to report that 14 issues could be closed, and pdb got a range of small new features, such as commands on the command line, until lineno or longlist showing all the code for the current function (the latter courtesy of Antonio Cuni's pdb++). One issue that's not yet closed is #7245, which adds a (very nice IMO) feature: when you press Ctrl-C while the program being debugged runs, you will not get a traceback but execution is suspended, and you can debug from the current point of execution -- just like in gdb. However, there were apparently issues with some of the buildbots when the patch was applied for a short time. I also don't know how and if it works on Windows, so I'd need some helpful people testing it. Another question is about a feature of pdb++ that I personally would like, but imagine would make others unhappy: one-letter abbreviations of commands such as c(ontinue) or l(ist) are also often-used variable names, so they are frequently typed without the required ! or print that would distinguish them from the command, and the command is actually executed. The feature in question would default to printing the variable in cases where one exists -- handy enough or too inconsistent? Warning: 'p' is *not* the same as 'print'. 'p' is a built-in command that prints the expression's repr(). 'print' OTOH falls back through the interpreter and executes a print statement or function, which prints the str(). Not in py3k -- 'print' is an alias for 'p' there, otherwise 'print x' would be a syntax error. For me personally, the problem this feature tries to address is never a problem (of course I am probably unique as far as pdb users go :-) so I'd like a way to turn it off. Also, are there any other features you would like to see? One feature of pdb++ that is general enough and has no dependencies would be watch expressions... Cool. I take it you'd like to see them? ;) Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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] pdb mini-sprint report and questions
On Fri, Jul 30, 2010 at 4:07 PM, Georg Brandl g.bra...@gmx.net wrote: Am 31.07.2010 01:01, schrieb Guido van Rossum: Warning: 'p' is *not* the same as 'print'. 'p' is a built-in command that prints the expression's repr(). 'print' OTOH falls back through the interpreter and executes a print statement or function, which prints the str(). Not in py3k -- 'print' is an alias for 'p' there, otherwise 'print x' would be a syntax error. Ah, ok, even better. For me personally, the problem this feature tries to address is never a problem (of course I am probably unique as far as pdb users go :-) so I'd like a way to turn it off. Also, are there any other features you would like to see? One feature of pdb++ that is general enough and has no dependencies would be watch expressions... Cool. I take it you'd like to see them? ;) Sorry, yes, I meant that as a kewl cool, not lukewarm cool. IOW +1, not +0. :) -- --Guido van Rossum (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] proto-pep: plugin proposal (for unittest)
On Fri, Jul 30, 2010 at 10:23 PM, Michael Foord fuzzy...@voidspace.org.uk wrote: For those of you who found this document perhaps just a little bit too long, I've written up a *much* shorter intro to the plugin system (including how to get the prototype) on my blog: http://www.voidspace.org.uk/python/weblog/arch_d7_2010_07_24.shtml#e1186 This looks nice and simple, but I am a bit worried about the configuration file for registration. My experience is that end users don't like editing files much. I understand that may be considered as bikesheding, but have you considered a system analog to bzr instead ? A plugin is a directory somewhere, which means that disabling it is just removing a directory. In my experience, it is more reliable from a user POV than e.g. the hg way of doing things. The plugin system of bzr is one of the thing that I still consider the best in its category, even though I stopped using bzr for quite some time. The registration was incredibly robust and easy to use from a user and developer POV, 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] unexpected import behaviour
On Sat, Jul 31, 2010 at 4:46 AM, Daniel Waterworth da.waterwo...@gmail.com wrote: Having thought it through thoroughly, my preference is for a warning. That's actually harder than it sounds. Inserting __main__ into sys.modules under its normal name as well as __main__ is actually pretty easy (for both direct execution and -m). Making it generate a warning when accessing __main__ under its normal name is trickier (akin to the various lazy module loading hacks that are available in assorted packages on pypi). Extending this to work for arbitrary objects is very hard to do efficiently (you'd almost certainly need an additional index from __file__ values to sys.modules keys that would complain whenever the list of associated key entries for a given __file__ value contained more than 1 entry). That's a lot of infrastructure just to try and detect a fairly rare kind of bug. 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] unexpected import behaviour
On Fri, Jul 30, 2010 at 2:46 PM, Daniel Waterworth
da.waterwo...@gmail.com wrote:
..
Having thought it through thoroughly, my preference is for a warning.
I don't think it's a good practise to import the __main__ module by
filename, as renaming the file will break the code. I got stung after,
having dropped into a python interpreter shell and imported the
module, I executed a function that uses isinstance.
If a warning showed up after importing the module, explaining the
problem and suggested that I use __import__('__main__') instead, I
would have saved myself a fair amount of time debugging code. This is
another case of Explicit is better than implicit..
You can easily disallow importing __main__ module by filename by
simply giving your script a name that does not end with .py or by
using say '-' character in the filename. No change to python itself
is needed.
___
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] proto-pep: plugin proposal (for unittest)
On Sat, Jul 31, 2010 at 12:34 AM, Michael Foord fuzzy...@voidspace.org.uk wrote: Explicit registration over implicit registration by subclassing is an interesting discussion, but I like the simplicity provided by just subclassing. Note that ABCs are deliberately designed to let *users* choose to do either. Subclassing gets you better implementation support (since you pick up all the concrete method implementations for free), but you can still use explicit registration if you have an existing class that provides the API but isn't a subclass of the ABC. 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
