Re: [Python-Dev] Exception chaining and generator finalisation
Antoine Pitrou wrote:
It only happens if you call close() explicitly:
Well, that's only because the exception is being ignored and
you're not getting a traceback at all.
If you arrange to get a traceback, the same thing happens.
import traceback as tb
def g():
try:
try:
yield 1
finally:
raise ValueError(Hovercraft contains eels)
except Exception:
tb.print_exc()
gi = g()
next(gi)
del gi
--
Greg
def g():
... try: yield 1
... finally: 1/0
...
gi = g()
next(gi)
1
del gi
Exception ZeroDivisionError: ZeroDivisionError('division by zero',) in
generator object g at 0x7fe50351ddc0 ignored
gi = g()
next(gi)
1
next(gi)
Traceback (most recent call last):
File stdin, line 1, in module
File stdin, line 3, in g
ZeroDivisionError: division by zero
Regards
Antoine.
___
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/greg.ewing%40canterbury.ac.nz
___
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] Exception chaining and generator finalisation
Nick Coghlan wrote: A toy example, that isn't obviously broken at first glance, but in fact fails when close() is called: Okay, you've convinced me. I'll consider it to be correct behaviour and update my expected yield-from test results accordingly. -- Greg ___ 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] No response to posts
On 01/08/2010 02:00, Brian Curtin wrote: On Sat, Jul 31, 2010 at 19:48, Mark Lawrencebreamore...@yahoo.co.ukwrote: Hi all, I have been wading through outstanding issues today and have noticed that there are several where there has been no response at all to the initial post. Failing that, the only response has been Terry Reedy back in May 2010, and that only updating the versions affected. Would it be possible to get some code in place whereby if there is no response to the initial post, this could be flagged up after (say) 24 hours? Surely any response back to the OP is better than a complete wall of silence? Kindest regards. Mark Lawrence. We could just add globally visible query which shows all issues with a message count of 1. That query currently shows 372 issues, most of which were entered within the last few months. The query strikes me as KISS, let's try it and see how we go. On this thread on c.l.py 500 tracker orphans; we need more reviewers started by Terry Reedy it was quoted that there were 510 orphans as at Jun 19, 3:37 am. We're getting there. 24 hours seems too soon for any kind of notification. Who would receive this notification? I plucked this figure out of the air thinking that if an issue was going to drop under the radar, this would be the most likely time. I was considering a worst case scenario where several core triage people are at a big Python event, others are on holiday [ shame on you :) ], some looking after the kids, yet more off sick etc. Hum, perhaps 24 hours is too soon, what about a week, opinions anybody? Notifications would go to the bugs mailing list and/or #python-dev. But this is hypothetical anyway if the message count of 1 query works. Only one way to find out, let's try it. Kindest regards. Mark Lawrence. ___ 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] Yield-From Implementation Updated for Python 3
I have updated my prototype yield-from implementation to work with Python 3.1.2. I've also fixed a small bug that was affecting one of the corner cases concerning exceptions thrown into a subgenerator. Interested parties can obtain it here: http://www.cosc.canterbury.ac.nz/greg.ewing/python/yield-from/ -- Greg ___ 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] [RELEASED] Python 3.2 alpha 1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On behalf of the Python development team, I'm happy to announce the first alpha preview release of Python 3.2. Python 3.2 is a continuation of the efforts to improve and stabilize the Python 3.x line. Since the final release of Python 2.7, the 2.x line will only receive bugfixes, and new features are developed for 3.x only. Since PEP 3003, the Moratorium on Language Changes, is in effect, there are no changes in Python's syntax and built-in types in Python 3.2. Development efforts concentrated on the standard library and support for porting code to Python 3. Highlights are: * numerous improvements to the unittest module * PEP 3147, support for .pyc repository directories * an overhauled GIL implementation that reduces contention * many consistency and behavior fixes for numeric operations * countless fixes regarding string/unicode issues; among them full support for a bytes environment (filenames, environment variables) * a sysconfig module to access configuration information * a pure-Python implementation of the datetime module * additions to the shutil module, among them archive file support * improvements to pdb, the Python debugger For an extensive list of changes in 3.2, see Misc/NEWS in the Python distribution. To download Python 3.2 visit: http://www.python.org/download/releases/3.2/ 3.2 documentation can be found at: http://docs.python.org/3.2/ Please consider trying Python 3.2 with your code and reporting any bugs you may notice to: http://bugs.python.org/ Enjoy! - -- Georg Brandl, Release Manager georg at python.org (on behalf of the entire python-dev team and 3.2's contributors) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAkxVQJsACgkQN9GcIYhpnLBxIgCcCiVu/QUkFf0bYM2Vmi8St3mZ 2N4An04q36lr47OA+bslqG/4Zj7ZwVOX =iL8N -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] No response to posts
On Sun, Aug 1, 2010 at 5:41 PM, Mark Lawrence breamore...@yahoo.co.uk wrote: I plucked this figure out of the air thinking that if an issue was going to drop under the radar, this would be the most likely time. I was considering a worst case scenario where several core triage people are at a big Python event, others are on holiday [ shame on you :) ], some looking after the kids, yet more off sick etc. Hum, perhaps 24 hours is too soon, what about a week, opinions anybody? Notifications would go to the bugs mailing list and/or #python-dev. But this is hypothetical anyway if the message count of 1 query works. Only one way to find out, let's try it. Perhaps just another number to track in the weekly bug summary? 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] No response to posts
Perhaps just another number to track in the weekly bug summary? *puts bug person hat on* I made the same suggestion to Ezio, so +1 I’ve just created a public query named “Reports without replies”, you should be able to add it to your queries list, or a tracker admin could decide to add it to the queries that are always visible in the sidebar. 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] Yield-From Implementation Updated for Python 3
On Sun, Aug 1, 2010 at 3:54 AM, Greg Ewing greg.ew...@canterbury.ac.nzwrote: I have updated my prototype yield-from implementation to work with Python 3.1.2. My work is primarily on the management and analysis of huge genomics datasets. I use Python generators extensively and intensively to perform efficient computations and transformations on these datasets that avoid the need to materialize them in main memory to the extent possible. I've spent a great deal of effort working around the lack of an efficient yield from construct and would be very excited to see this feature added. More so, now that BioPython, NumPy, SciPy and other libraries that I depend on are well on their way to supporting Python 3, the availability of this feature alone would be incentive enough to update my code base to Python 3. So in short: +1 -Kevin ___ 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 31 Jul, 2010, at 13:57, Michael Foord wrote: On 31/07/2010 12:46, Michael Foord wrote: [snip...] If PEP 376 goes ahead then we could keep the user plugin I meant keep the user config file. Speaking of which... Your documentation says it's named ~/unittest.cfg, could you make this a file in the user base (that is, the prefix where 'setup.py install --user' will install files)? Ronald smime.p7s Description: S/MIME cryptographic 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)
Speaking of which... Your documentation says it's named ~/unittest.cfg, could you make this a file in the user base (that is, the prefix where 'setup.py install --user' will install files)? Putting .pydistutils.cfg .pypirc .unittest2.cfg .idlerc and possibly other in the user home directory (or %APPDATA% on win32 and what-have-you on Mac) is unnecessary clutter. However, $PYTHONUSERBASE is not the right directory for configuration files, as pointed in http://bugs.python.org/issue7175 It would be nice to agree on a ~/.python (resp. %APPADATA%/Python) or $XDG_CONFIG_HOME/python directory and put config files there. 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 Sun, 01 Aug 2010 17:22:55 +0200, mer...@netwok.org wrote: Speaking of which... Your documentation says it's named ~/unittest.cfg, could you make this a file in the user base (that is, the prefix where 'setup.py install --user' will install files)? Putting .pydistutils.cfg .pypirc .unittest2.cfg .idlerc and possibly other in the user home directory (or %APPDATA% on win32 and what-have-you on Mac) is unnecessary clutter. However, $PYTHONUSERBASE is not the right directory for configuration files, as pointed in http://bugs.python.org/issue7175 It would be nice to agree on a ~/.python (resp. %APPADATA%/Python) or $XDG_CONFIG_HOME/python directory and put config files there. +1 Certainly ~/unittest.cfg is the wrong name for unix (it doesn't start with a '.'), and certainly the location is OS specific. Anyone who cares about config file locations should read issue 7175. -- R. David Murray 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] No response to posts
On Sun, 01 Aug 2010 21:28:05 +1000, Nick Coghlan ncogh...@gmail.com wrote: On Sun, Aug 1, 2010 at 5:41 PM, Mark Lawrence breamore...@yahoo.co.uk wrote: I plucked this figure out of the air thinking that if an issue was going to drop under the radar, this would be the most likely time. I was considering a worst case scenario where several core triage people are at a big Python event, others are on holiday [ shame on you :) ], some looking after the kids, yet more off sick etc. Hum, perhaps 24 hours is too soon, what a bout a week, opinions anybody? Notifications would go to the bugs mailing list and/or #python-dev. But this is hypothetical anyway if the message count of 1 query works. Only one way to find out, let's try it. Perhaps just another number to track in the weekly bug summary? Better, a table section giving the bugids, titles, and URL. Ezio just finished reworking the summary script to be more easily modified, so I bet he would find this easy to add at this point. --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] Yield-From Implementation Updated for Python 3
At 08:49 AM 8/1/2010 -0400, Kevin Jacobs jac...@bioinformed.com wrote: On Sun, Aug 1, 2010 at 3:54 AM, Greg Ewing mailto:greg.ew...@canterbury.ac.nzgreg.ew...@canterbury.ac.nz wrote: I have updated my prototype yield-from implementation to work with Python 3.1.2. My work is primarily on the management and analysis of huge genomics datasets. I use Python generators extensively and intensively to perform efficient computations and transformations on these datasets that avoid the need to materialize them in main memory to the extent possible. I've spent a great deal of effort working around the lack of an efficient yield from construct and would be very excited to see this feature added. Just so you know, you don't need to wait for this to be added to Python in order to have such a construct; it just won't have the extra syntax sugar. See the sample code I posted here using a @From.container decorator, and a yield From() call: http://mail.python.org/pipermail/python-dev/2010-July/102320.html This code effectively reduces your generator nesting depth to a constant, no matter how deeply you nest sub-generator invocations. It's not as efficient as the equivalent C implementation, but if you're actually being affected by nesting overhead now, it will nonetheless provide you with some immediate relief, if you backport it to 2.x code. (It's not very 3.x-ish as it sits, really.) ___ 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 01/08/2010 18:38, R. David Murray wrote: On Sun, 01 Aug 2010 17:22:55 +0200,mer...@netwok.org wrote: Speaking of which... Your documentation says it's named ~/unittest.cfg, could you make this a file in the user base (that is, the prefix where 'setup.py install --user' will install files)? Putting .pydistutils.cfg .pypirc .unittest2.cfg .idlerc and possibly other in the user home directory (or %APPDATA% on win32 and what-have-you on Mac) is unnecessary clutter. However, $PYTHONUSERBASE is not the right directory for configuration files, as pointed in http://bugs.python.org/issue7175 It would be nice to agree on a ~/.python (resp. %APPADATA%/Python) or $XDG_CONFIG_HOME/python directory and put config files there. +1 Certainly ~/unittest.cfg is the wrong name for unix (it doesn't start with a '.'), and certainly the location is OS specific. Anyone who cares about config file locations should read issue 7175. I'm happy to choose a location / name based on consensus. There doesn't seem to be any consensus yet. As a (mainly ex) windows user I would hate to have user editable data in APPDATA as it is not a location the user ever expects to visit. The home directory, or a subdirectory thereof, for user editable app specific data is more usual and more friendly. All the best, Michael Foord -- R. David Murray 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/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 1 Aug, 2010, at 17:22, Éric Araujo wrote: Speaking of which... Your documentation says it's named ~/unittest.cfg, could you make this a file in the user base (that is, the prefix where 'setup.py install --user' will install files)? Putting .pydistutils.cfg .pypirc .unittest2.cfg .idlerc and possibly other in the user home directory (or %APPDATA% on win32 and what-have-you on Mac) is unnecessary clutter. However, $PYTHONUSERBASE is not the right directory for configuration files, as pointed in http://bugs.python.org/issue7175 It would be nice to agree on a ~/.python (resp. %APPADATA%/Python) or $XDG_CONFIG_HOME/python directory and put config files there. ~/Library/Python would be a good location on OSX, even if the 100% formally correct location would be ~/Preferences/Python (at least of framework builds, unix-style builds may want to follow the unix convention). Ronald smime.p7s Description: S/MIME cryptographic 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] No response to posts
On 01/08/2010 20.43, R. David Murray wrote: On Sun, 01 Aug 2010 21:28:05 +1000, Nick Coghlanncogh...@gmail.com wrote: On Sun, Aug 1, 2010 at 5:41 PM, Mark Lawrencebreamore...@yahoo.co.uk wrote: I plucked this figure out of the air thinking that if an issue was going to drop under the radar, this would be the most likely time. I was considering a worst case scenario where several core triage people are at a big Python event, others are on holiday [ shame on you :) ], some looking after the kids, yet more off sick etc. Hum, perhaps 24 hours is too soon, what a bout a week, opinions anybody? Notifications would go to the bugs mailing list and/or #python-dev. But this is hypothetical anyway if the message count of 1 query works. Only one way to find out, let's try it. Perhaps just another number to track in the weekly bug summary? Better, a table section giving the bugids, titles, and URL. Ezio just finished reworking the summary script to be more easily modified, so I bet he would find this easy to add at this point. --David FWIW this morning I added a new version of the roundup-summary script [0] that includes a Recent issues with no replies table with bugids, titles and URLs. (I hope Guido doesn't mind if I used the time machine ;) [0]: http://psf.upfronthosting.co.za/roundup/meta/issue284 ___ 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] PEP 376 proposed changes for basic plugins support
Hello, Here's a proposal to extend PEP 376 to support a basic plugins feature -- you should read PEP 376 before reading this mail It's basically Phillip's entry points, but with an activation flag, and a per-user config file. = adding a PLUGINS file = A new file called 'PLUGINS' is added to the dist-info directory at install time, and contains a list of plugins for the installed distribution. The file is a CSV file like the RECORD file, containing one plugin per line. (see the RECORD file for details on the syntax) A plugin is defined by : - an application name : a string containing a name of a group of plugins. It can be the name of the application that supports plugins, or any string. The recommended value is the distutils name of the project, as it appears at PyPI. max length: 64, chars: [a-z0-9] - a plugin type name: a string containing a name of a type of plugins. It can be combined with the application name to create one class of plugins for a given application. 64 chars [a-z0-9] -- default value 'plugin' - a name: a string containing a name for the plugin. Combined with the application name and plugin type, it defines this plugin. 64 chars [a-z0-9] - a description: a string describing the plugin. 256 chars. - a state: 1 or 0. 1 means the plugin is activated, 0 means it's not activated - a code link: a link to the plugin object (whether its a module, class, object, etc). This link is the complete import path. For example, a plugin class called Foo located in the bar module, located in the baz package, is noted: baz.bar.Foo (the project that uses plugins is responsible for iteratting, picking and loading plugins) = PLUGINS example = Here's an example of a PLUGINS file for a 'UnittestPlugins' project that implements 2 unitest2 plugins: unittest2;plugin;pep8;pep8 checker;1;unittestplugins.pep8 unittest2;plugin;debugger,Cool debugger;1;unittestplugins.debug = per-user plugins = A plugin can be activated or disable globally, but a user should be able to configure them differently. A ini-like plugins.cfg file is added per-user (its location to be defined -- its discussed in another thread) and overrides the state of the installed plugin. It provides a value for each app.type.name plugin. [plugins] unittest2.plugin.pep8 = 0 distutils2.commands.funkycommand = 0 Notice that the user can have plugins provided by distributions installed in his own per-user site packages. = Implementation = I don't want to go into great details here yet, until we get a consensus on the PLUGINS file. But basically we will add these features in pkgutil: - browse plugins and get their info. - activate/disable a plugin, by writing its state - load a plugin and return it by importing the 'code link' and in distutils2: - let the user configure if plugins are automatically activated when the project is installed - provide a end-user script to browse plugins - provide a way to define plugins statically in setup.cfg 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] PEP 376 proposed changes for basic plugins support
On Mon, Aug 2, 2010 at 6:37 AM, Tarek Ziadé ziade.ta...@gmail.com wrote: Hello, Here's a proposal to extend PEP 376 to support a basic plugins feature -- you should read PEP 376 before reading this mail It's basically Phillip's entry points, but with an activation flag, and a per-user config file. = adding a PLUGINS file = A new file called 'PLUGINS' is added to the dist-info directory at install time, and contains a list of plugins for the installed distribution. The file is a CSV file like the RECORD file, containing one plugin per line. (see the RECORD file for details on the syntax) A plugin is defined by : - an application name : a string containing a name of a group of plugins. It can be the name of the application that supports plugins, or any string. The recommended value is the distutils name of the project, as it appears at PyPI. max length: 64, chars: [a-z0-9] - a plugin type name: a string containing a name of a type of plugins. It can be combined with the application name to create one class of plugins for a given application. 64 chars [a-z0-9] -- default value 'plugin' - a name: a string containing a name for the plugin. Combined with the application name and plugin type, it defines this plugin. 64 chars [a-z0-9] - a description: a string describing the plugin. 256 chars. - a state: 1 or 0. 1 means the plugin is activated, 0 means it's not activated - a code link: a link to the plugin object (whether its a module, class, object, etc). This link is the complete import path. For example, a plugin class called Foo located in the bar module, located in the baz package, is noted: baz.bar.Foo (the project that uses plugins is responsible for iteratting, picking and loading plugins) Is dealing with name conflicts left up to the application? 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] Metadata: charset (was: PEP 376 proposed changes for basic plugins support)
On Sun, Aug 01, 2010 at 10:37:47PM +0200, Tarek Ziad? wrote: The file is a CSV file In what encoding (charset)? I quickly skimmed over PEPs 262, 241, 314 and 376, but didn't encountered any mention of the words encoding or charset. Documentation for the csv module also doesn't provide any clear indication of encoding/charset. 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] PEP 376 proposed changes for basic plugins support
On Sun, Aug 1, 2010 at 11:55 PM, Nick Coghlan ncogh...@gmail.com wrote: ... Is dealing with name conflicts left up to the application? When an application iterates on the plugins that are supposely built for it, it will probably expect a single type of object. For instance unitest2 will want classes that are overriding its Plugin base class. So it should be able to drop objects that are not compliant with its system. Now, since the distutils id at PyPI is unique, using it for the application name in the plugin like I proposed, should also help preventing this issue. ___ 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] Metadata: charset (was: PEP 376 proposed changes for basic plugins support)
On Sun, Aug 1, 2010 at 11:58 PM, Oleg Broytman p...@phd.pp.ru wrote: On Sun, Aug 01, 2010 at 10:37:47PM +0200, Tarek Ziad? wrote: The file is a CSV file In what encoding (charset)? I quickly skimmed over PEPs 262, 241, 314 and 376, but didn't encountered any mention of the words encoding or charset. Documentation for the csv module also doesn't provide any clear indication of encoding/charset. utf-8. I'll add this info in PEP 376 -- Thanks Oleg. -- Oleg Broytman http://phd.pp.ru/ ...@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/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] Metadata: charset
On Mon, Aug 02, 2010 at 12:11:06AM +0200, Tarek Ziad? wrote: On Sun, Aug 1, 2010 at 11:58 PM, Oleg Broytman p...@phd.pp.ru wrote: On Sun, Aug 01, 2010 at 10:37:47PM +0200, Tarek Ziad? wrote: The file is a CSV file In what encoding (charset)? I quickly skimmed over PEPs 262, 241, 314 and 376, but didn't encountered any mention of the words encoding or charset. Documentation for the csv module also doesn't provide any clear indication of encoding/charset. utf-8. I'll add this info in PEP 376 -- Thanks Thank you for the clarification! 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] PEP 376 proposed changes for basic plugins support
On 01/08/2010 21:37, Tarek Ziadé wrote: Hello, Here's a proposal to extend PEP 376 to support a basic plugins feature -- you should read PEP 376 before reading this mail It's basically Phillip's entry points, but with an activation flag, and a per-user config file. = adding a PLUGINS file = A new file called 'PLUGINS' is added to the dist-info directory at install time, and contains a list of plugins for the installed distribution. The file is a CSV file like the RECORD file, containing one plugin per line. (see the RECORD file for details on the syntax) A plugin is defined by : - an application name : a string containing a name of a group of plugins. It can be the name of the application that supports plugins, or any string. The recommended value is the distutils name of the project, as it appears at PyPI. max length: 64, chars: [a-z0-9] - a plugin type name: a string containing a name of a type of plugins. It can be combined with the application name to create one class of plugins for a given application. 64 chars [a-z0-9] -- default value 'plugin' - a name: a string containing a name for the plugin. Combined with the application name and plugin type, it defines this plugin. 64 chars [a-z0-9] - a description: a string describing the plugin. 256 chars. - a state: 1 or 0. 1 means the plugin is activated, 0 means it's not activated - a code link: a link to the plugin object (whether its a module, class, object, etc). This link is the complete import path. For example, a plugin class called Foo located in the bar module, located in the baz package, is noted: baz.bar.Foo (the project that uses plugins is responsible for iteratting, picking and loading plugins) = PLUGINS example = Here's an example of a PLUGINS file for a 'UnittestPlugins' project that implements 2 unitest2 plugins: unittest2;plugin;pep8;pep8 checker;1;unittestplugins.pep8 unittest2;plugin;debugger,Cool debugger;1;unittestplugins.debug This seems fine; I mean it isn't written directly by humans or intended to be read directly by humans I guess. :-) (Users will specify plugins in the setup metadata and this will be written on install by distutils2 - right?.) = per-user plugins = A plugin can be activated or disable globally, but a user should be able to configure them differently. A ini-like plugins.cfg file is added per-user (its location to be defined -- its discussed in another thread) and overrides the state of the installed plugin. It provides a value for each app.type.name plugin. [plugins] unittest2.plugin.pep8 = 0 distutils2.commands.funkycommand = 0 Notice that the user can have plugins provided by distributions installed in his own per-user site packages. I don't think that unittest would use a distutils2 (or pkgutil) supplied API for activation. unittest needs *separate* per user and per project activation (a plugin active for a project may not be needed in other projects and so won't be enabled at the user level for example). unittest also needs plugin *configuration* and it makes sense to keep configuration and activation in the same place. The interesting part of this proposal for unittest is the plugin discovery. unittest will use the two config file solution (location of user config still to be determined) and probably a plugins subcommand (eventually) to manage the config file from the command line. On the other hand the activation is likely to be wanted by other projects that use plugins and it certainly doesn't hurt unittest. = Implementation = I don't want to go into great details here yet, until we get a consensus on the PLUGINS file. But basically we will add these features in pkgutil: - browse plugins and get their info. Yes, great. - activate/disable a plugin, by writing its state - load a plugin and return it by importing the 'code link' Also great. and in distutils2: - let the user configure if plugins are automatically activated when the project is installed - provide a end-user script to browse plugins - provide a way to define plugins statically in setup.cfg All sounds good to me. Michael 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
Re: [Python-Dev] No response to posts
On 8/1/2010 7:44 AM, Éric Araujo wrote: +1 On a prebuilt search This is not as easy as it seems. A nosy count of 1 misses posts where someone added themself as nosy without saying anything, waiting for someone else to answer (and maybe no one ever did). A message count of 1 misses posts where a person follows up with a correction (because he cannot edit!) or addition. nosy = 1 or message = 1 would be better, and one cannot do that from search form, which, ANDS things together. Can a custom sql query do an OR? Perhaps just another number to track in the weekly bug summary? *puts bug person hat on* I made the same suggestion to Ezio, so +1 If Friday report marked issues without responses, I would make a special effort to look at those. -- 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] Is it intentional that sys.__debug__ = 1 isillegal in Python 2.7?
On 7/31/2010 5:02 PM, Guido van Rossum wrote: But yes, the docs should clarify that *any* use of __*__ names, in *any* context, that does not follow explicitly documented use, is subject to breakage without warning. http://bugs.python.org/issue9451 Strengthen __*__ system name warning My suggested new version, incorporating Guido's sentence: System-defined names. These names are defined by the interpreter and its implementation (including the standard library). Current system names are discussed in the Special method names section and elsewhere. More will likely be defined in future versions of Python. *Any* use of __*__ names, in any* context, that does not follow explicitly documented use, is subject to breakage without warning. -- 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] No response to posts
On 08/01/2010 06:14 PM, Terry Reedy wrote: On 8/1/2010 7:44 AM, Éric Araujo wrote: +1 On a prebuilt search This is not as easy as it seems. A nosy count of 1 misses posts where someone added themself as nosy without saying anything, waiting for someone else to answer (and maybe no one ever did). A message count of 1 misses posts where a person follows up with a correction (because he cannot edit!) or addition. nosy = 1 or message = 1 would be better, and one cannot do that from search form, which, ANDS things together. Can a custom sql query do an OR? There is an activity field which gets any issues with activity on a specific day. I'm not sure how useful that is. shrug Something that may be more useful, is a no activity search field with choices of day, week, month, year, etc... and make the output sortable on time without activity. That not only would cover the short term cases of no response, but also the longer term items that slip though the cracks. Ron ___ 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 376 proposed changes for basic plugins support
On Mon, Aug 2, 2010 at 1:11 AM, Michael Foord fuzzy...@voidspace.org.uk wrote: This seems fine; I mean it isn't written directly by humans or intended to be read directly by humans I guess. :-) (Users will specify plugins in the setup metadata and this will be written on install by distutils2 - right?.) Yes, exactly = per-user plugins = A plugin can be activated or disable globally, but a user should be able to configure them differently. A ini-like plugins.cfg file is added per-user (its location to be defined -- its discussed in another thread) and overrides the state of the installed plugin. It provides a value for each app.type.name plugin. [plugins] unittest2.plugin.pep8 = 0 distutils2.commands.funkycommand = 0 Notice that the user can have plugins provided by distributions installed in his own per-user site packages. I don't think that unittest would use a distutils2 (or pkgutil) supplied API for activation. But the discovery API you will use might just simply filter out disabled plugins. In any case, if unittest2 tries to bypass this activation flag I don't see the point of having it there since its purpose is to let the end-user deactivate a plugin that might be used by several applications. unittest needs *separate* per user and per project activation (a plugin active for a project may not be needed in other projects and so won't be enabled at the user level for example). And sharing plugins across apps is a use case too: Nose could use unittest2 plugins and vice-versa. Tarek ___ 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 376 proposed changes for basic plugins support
On 02/08/2010 00:46, Tarek Ziadé wrote: [snip...] I don't think that unittest would use a distutils2 (or pkgutil) supplied API for activation. But the discovery API you will use might just simply filter out disabled plugins. I did consider asking this but thought it was a silly question - there *must* be an API to get all plugins otherwise applications couldn't activate or deactivate them (or allow their users to do this) - and then how could users activate a non-active plugin? (I guess there could be private APIs that only distutils2 is supposed to use, or the script that you mentioned.) On the other hand if the user has deactivated a plugin through distutils2 I have no problem with it not being available to unittest. In any case, if unittest2 tries to bypass this activation flag I don't see the point of having it there since its purpose is to let the end-user deactivate a plugin that might be used by several applications. Right. As I explained, I don't think unittest *can* use this mechanism since it can have plugins active for one project but not for another. I would really have no problem with this machinery existing, but it wouldn't be useful/usable by unittest for plugins. It sounds like it can fairly easily be bolted on as a new feature set later *anyway*, so dropping it for now simplifies the initial implementation. Wouldn't that mean that distutils2 would still need its *own* system for telling whether or not installed plugins are active? So maybe you have to build it anyway. unittest needs *separate* per user and per project activation (a plugin active for a project may not be needed in other projects and so won't be enabled at the user level for example). And sharing plugins across apps is a use case too: Nose could use unittest2 plugins and vice-versa. Hehe, well - that's a different story... Michael 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] PEP 376 proposed changes for basic plugins support
On Mon, Aug 2, 2010 at 1:56 AM, Michael Foord fuzzy...@voidspace.org.uk wrote: On 02/08/2010 00:46, Tarek Ziadé wrote: [snip...] I don't think that unittest would use a distutils2 (or pkgutil) supplied API for activation. But the discovery API you will use might just simply filter out disabled plugins. I did consider asking this but thought it was a silly question - there *must* be an API to get all plugins otherwise applications couldn't activate or deactivate them (or allow their users to do this) - and then how could users activate a non-active plugin? (I guess there could be private APIs that only distutils2 is supposed to use, or the script that you mentioned.) yes, there will be a way to retrieve them all ... It sounds like it can fairly easily be bolted on as a new feature set later *anyway*, so dropping it for now simplifies the initial implementation. but then we would be back to the problem mentioned about entry points: installing projects can implicitly add a plugin and activate it, and break existing applications that iterate over entry points without further configuration. So being able to disable plugins from the beginning seems important to me ___ 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
Hello, I'm the submitter of the original patch and would like to help with it if I can. 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. For whatever it's worth, it worked for me with python trunk (2.x) on Vista, when I tried it manually. But I don't know how to implement the unit test there (subprocess module doesn't support sending SIGINT programmatically on windows either). So the test_pdb2 test does not check signal behavior on Windows platforms. Buildbot failures are still a total mystery for me ;-): the failures were happening elsewhere and seemed to be unrelated to test_pdb2. Is there any other way to apply the patch and run the tests on failing platforms? Ilya 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/ilya.sandler%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] PEP 376 proposed changes for basic plugins support
On 02/08/2010 01:03, Tarek Ziadé wrote: On Mon, Aug 2, 2010 at 1:56 AM, Michael Foordfuzzy...@voidspace.org.uk wrote: On 02/08/2010 00:46, Tarek Ziadé wrote: [snip...] I don't think that unittest would use a distutils2 (or pkgutil) supplied API for activation. But the discovery API you will use might just simply filter out disabled plugins. I did consider asking this but thought it was a silly question - there *must* be an API to get all plugins otherwise applications couldn't activate or deactivate them (or allow their users to do this) - and then how could users activate a non-active plugin? (I guess there could be private APIs that only distutils2 is supposed to use, or the script that you mentioned.) yes, there will be a way to retrieve them all ... It sounds like it can fairly easily be bolted on as a new feature set later *anyway*, so dropping it for now simplifies the initial implementation. but then we would be back to the problem mentioned about entry points: installing projects can implicitly add a plugin and activate it, and break existing applications that iterate over entry points without further configuration. So being able to disable plugins from the beginning seems important to me I agree it sounds like an important feature - a point of control for the user or the system as you said on irc. I still don't think unittest *can* use it, but I'm quite happy with the fact that if a user deactivates a plugin through distutils2 then it is no longer *available* to unittest. 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] PEP 376 proposed changes for basic plugins support
At 02:03 AM 8/2/2010 +0200, Tarek Ziadé wrote: but then we would be back to the problem mentioned about entry points: installing projects can implicitly add a plugin and activate it, and break existing applications that iterate over entry points without further configuration. So being able to disable plugins from the beginning seems important to me So which are these apps that don't allow configuration, and which are the plugins that break them? Have the issues been reported so that the authors can fix them? ISTM that the issue can only arise in cases where you are installing plugins to a *global* environment, rather than to an environment specific to the application. In the case of setuptools, for example, it's expected that a project will use 'setup_requires' to identify the plugins it wishes to use, apart from any that were intentionally installed globally. (The requested plugins are then added to sys.path only for the duration of the setup script execution.) Other applications have plugin directories where their plugins are to be installed, and still others have explicit configuration to enable named plugins. Even in the worst-case scenario, where an app has no plugin configuration and no private plugin directory, you can still control plugin availability by installing plugins to the directory where the application's main script is located, or point PYTHONPATH to point to a directory you've chosen to hold the plugins of your choice. So without specific examples of why this is a problem, it's hard to see why a special Python-specific set of configuration files is needed to resolve it, vs. say, encouraging application authors to use the available alternatives for doing plugin directories, config files, etc. ___ 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] No response to posts
2010/7/31 Éric Araujo wins...@netwok.org: Good call. Alternative idea: Have a new status “unread” to make searching easier for bug people. Or a predefined custom search for nosy_count == 1. Please, let's stop messing with the tracker for everything. I think the current set up works reasonably well, and we should focus on the real problem: manpower -- 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] Is it intentional that sys.__debug__ = 1 is illegal in Python 2.7?
2010/7/30 Barry Warsaw ba...@python.org: It looks like Benjamin's change in r67171 was the relevant diff. The reason behind this was to make __debug__ assignment consistent with that of other reserved names. For example, x.None = 3 raised and thus, so should x.__debug__ = 3. -- 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] [RELEASED] Python 3.2 alpha 1
Hey, Georg! Congrats on your first release! 2010/8/1 Georg Brandl ge...@python.org: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On behalf of the Python development team, I'm happy to announce the first alpha preview release of Python 3.2. Python 3.2 is a continuation of the efforts to improve and stabilize the Python 3.x line. Since the final release of Python 2.7, the 2.x line will only receive bugfixes, and new features are developed for 3.x only. Since PEP 3003, the Moratorium on Language Changes, is in effect, there are no changes in Python's syntax and built-in types in Python 3.2. Development efforts concentrated on the standard library and support for porting code to Python 3. Highlights are: * numerous improvements to the unittest module * PEP 3147, support for .pyc repository directories * an overhauled GIL implementation that reduces contention * many consistency and behavior fixes for numeric operations * countless fixes regarding string/unicode issues; among them full support for a bytes environment (filenames, environment variables) * a sysconfig module to access configuration information * a pure-Python implementation of the datetime module * additions to the shutil module, among them archive file support * improvements to pdb, the Python debugger For an extensive list of changes in 3.2, see Misc/NEWS in the Python distribution. To download Python 3.2 visit: http://www.python.org/download/releases/3.2/ 3.2 documentation can be found at: http://docs.python.org/3.2/ Please consider trying Python 3.2 with your code and reporting any bugs you may notice to: http://bugs.python.org/ Enjoy! - -- Georg Brandl, Release Manager georg at python.org (on behalf of the entire python-dev team and 3.2's contributors) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAkxVQJsACgkQN9GcIYhpnLBxIgCcCiVu/QUkFf0bYM2Vmi8St3mZ 2N4An04q36lr47OA+bslqG/4Zj7ZwVOX =iL8N -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/benjamin%40python.org -- 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] Yield-From Implementation Updated for Python 3
On Sun, Aug 1, 2010 at 11:16 AM, P.J. Eby p...@telecommunity.com wrote: Just so you know, you don't need to wait for this to be added to Python in order to have such a construct; it just won't have the extra syntax sugar. See the sample code I posted here using a @From.container decorator, and a yield From() call: http://mail.python.org/pipermail/python-dev/2010-July/102320.html This code effectively reduces your generator nesting depth to a constant, no matter how deeply you nest sub-generator invocations. It's not as efficient as the equivalent C implementation, but if you're actually being affected by nesting overhead now, it will nonetheless provide you with some immediate relief, if you backport it to 2.x code. (It's not very 3.x-ish as it sits, really.) Hi Phillip, Your code is fiendishly clever (and I mean that as a compliment). Even though only a few weeks ago I wrote a trampoline along these lines (more similar to the one in PEP 342, example 3, but extended to support async I/O), I don't understand all the details and corner cases (e.g. the concatenation of stacks, which seems to have to do with the special-casing of From objects in __new__) but I trust that it works. I am curious whether, if you need a trampoline for async I/O anyway, there would be a swaying argument for integrating this functionality into the general trampoline (as in the PEP 342 example), or whether it would be better to separate the async I/O trampoline from the From trampoline. The latter would in a sense be more future-proof because once PEP 380 becomes a reality the From class can be dropped in favor of yield-from syntax (and raise StopIteration(x) in favor of return x). But it seems a bit of a waste to have two different trampolines, especially since the trampoline itself is so hard to understand (speaking for myself here :-). ISTM that the single combined trampoline is easier to understand than the From class. I am CC'ing Raymond so he can loop the author of Monocle (his colleague) into this discussion -- I'd like to hear their opinion (Monocle seems to require a decorator but it looks like it uses the PEP 342 approach to simulate yield-from while avoiding stack buildup). PS For Raymond and his colleague: I also still hope that Monocle will change its mind about the proper convention for returning a value from a coroutine -- I really think it should be raise StopIteration(value) rather than yield value, since the latter (a) doesn't signal sufficiently strongly (to the human reader) that the generator will not be resumed ever again, and (b) could easily be confused with the other uses of yield. (IOW I think yield is being overloaded too much in Monocle.) -- --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 Aug 1, 2010, at 3:52 PM, Ronald Oussoren wrote: On 1 Aug, 2010, at 17:22, Éric Araujo wrote: Speaking of which... Your documentation says it's named ~/unittest.cfg, could you make this a file in the user base (that is, the prefix where 'setup.py install --user' will install files)? Putting .pydistutils.cfg .pypirc .unittest2.cfg .idlerc and possibly other in the user home directory (or %APPDATA% on win32 and what-have-you on Mac) is unnecessary clutter. However, $PYTHONUSERBASE is not the right directory for configuration files, as pointed in http://bugs.python.org/issue7175 It would be nice to agree on a ~/.python (resp. %APPADATA%/Python) or $XDG_CONFIG_HOME/python directory and put config files there. ~/Library/Python would be a good location on OSX, even if the 100% formally correct location would be ~/Preferences/Python (at least of framework builds, unix-style builds may want to follow the unix convention). 100% formally speaking, MacOS behaves like UNIX in many ways. http://en.wikipedia.org/wiki/Single_UNIX_Specification#Mac_OS_X_and_Mac_OS_X_Server It's fine to have a mac-pathname-convention-following place for such data, but please _also_ respect the UNIX-y version on the Mac. The only possible outcome of python on the Mac respect only Mac pathnames is to have automation scripts that work fine on BSD and Linux, but then break when you try to run them on a Mac. There is really no benefit to intentionally avoiding honoring the UNIX conventions. (For another example, note that although Python resides in /System/Library, on the mac, the thing that's in your $PATH when you're using a terminal is the symlink in /usr/bin/python.) Also, no, ~/Preferences isn't the right place for it either; there's no such thing. You probably meant ~/Library/Preferences. I'd say that since ~/Library/Python is already used, there's no particular reason to add a new ~/Library/Preferences/Python location. After all, if you really care a lot about platform conventions, you should put it in ~/Library/Preferences/org.python.distutils.plist, but I don't see what benefit that extra complexity would have for anyone. ___ 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
