Re: [Python-Dev] proto-pep: plugin proposal (for unittest)

Glyph Lefkowitz wrote: I'd say that since ~/Library/Python is already used, there's no particular reason to add a new ~/Library/Preferences/Python location. I think the reason for separating out Preferences is so that you can install a new version of a library or application without losing the

Re: [Python-Dev] proto-pep: plugin proposal (for unittest)

On 2 Aug, 2010, at 7:18, Glyph Lefkowitz wrote: > > 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

Re: [Python-Dev] [RELEASED] Python 3.2 alpha 1

Thanks, Benjamin! I'd also like to thank Martin and Ronald for the prompt binaries, and the folks of #python-dev for support. RMing was a pleasant experience so far. Georg Am 02.08.2010 05:01, schrieb Benjamin Peterson: > Hey, Georg! Congrats on your first release! > > 2010/8/1 Georg Brandl :

Re: [Python-Dev] Yield-From Implementation Updated for Python 3

At 09:24 PM 8/1/2010 -0700, Guido van Rossum wrote: I don't understand all the details and corner cases (e.g. the concatenation of stacks It's just to ensure that you never have From's iterating over other From's, vs. just iterating whatever's at the top of the stack. which seems to have t

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

Re: [Python-Dev] Yield-From Implementation Updated for Python 3

On Sun, Aug 1, 2010 at 11:16 AM, P.J. Eby 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()

Re: [Python-Dev] [RELEASED] Python 3.2 alpha 1

Hey, Georg! Congrats on your first release! 2010/8/1 Georg Brandl : > -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

Re: [Python-Dev] Is it intentional that "sys.__debug__ = 1" is illegal in Python 2.7?

2010/7/30 Barry Warsaw : > > 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 _

Re: [Python-Dev] No response to posts

2010/7/31 Éric Araujo : > 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 s

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 dis

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 Foord 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 w

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 y

Re: [Python-Dev] PEP 376 proposed changes for basic plugins support

On Mon, Aug 2, 2010 at 1:56 AM, Michael Foord 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 >> d

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 ques

Re: [Python-Dev] PEP 376 proposed changes for basic plugins support

On Mon, Aug 2, 2010 at 1:11 AM, Michael Foord 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, exa

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 di

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 sugg

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

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

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 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

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 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 > "cha

Re: [Python-Dev] PEP 376 proposed changes for basic plugins support

On Sun, Aug 1, 2010 at 11:55 PM, Nick Coghlan 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 over

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 a

Re: [Python-Dev] PEP 376 proposed changes for basic plugins support

On Mon, Aug 2, 2010 at 6:37 AM, 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. > > = a

[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

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 Coghlan wrote: On Sun, Aug 1, 2010 at 5:41 PM, Mark Lawrence 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

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

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, 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)? Putti

Re: [Python-Dev] Yield-From Implementation Updated for Python 3

At 08:49 AM 8/1/2010 -0400, Kevin Jacobs wrote: On Sun, Aug 1, 2010 at 3:54 AM, Greg Ewing <greg.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 analy

Re: [Python-Dev] No response to posts

On Sun, 01 Aug 2010 21:28:05 +1000, Nick Coghlan wrote: > On Sun, Aug 1, 2010 at 5:41 PM, Mark Lawrence 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

Re: [Python-Dev] proto-pep: plugin proposal (for unittest)

On Sun, 01 Aug 2010 17:22:55 +0200, 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

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

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

Re: [Python-Dev] Yield-From Implementation Updated for Python 3

On Sun, Aug 1, 2010 at 3:54 AM, Greg Ewing 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 comput

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 th

Re: [Python-Dev] No response to posts

On Sun, Aug 1, 2010 at 5:41 PM, Mark Lawrence 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, ot

[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 li

[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/yie

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 Lawrencewrote: 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

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 ___

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: