Re: [Python-Dev] gettext.py bug #1448060
On Tuesday 25 April à 01:24, "Martin v. Löwis" wrote: > Sylvain Thénault wrote: > > I've posted a patch (#1475523) for this and assigned it to Martin Von > > Loewis since he was the core developper who has made some followup on > > the original bug. Could someone (Martin or someone else) quick review > > this patch ? I really need a fix for this, so if anyone feels my > > patch is not correct, and explain why and what should be done, I can > > rework on it. > > If you need quick patch, you should just go ahead and use it > (unreviewed). It will take several more months until either Python 2.4.4 > or Python 2.5 is released. yep, that's what I intend to do anyway... But I wish to contribute the fix back so I can drop the overriden module asap (even if asap means in a few months in that case), and I would feel better if the patch was validated and checked in. But you're right that it doesn't have to be done so quickly since I'll be stuck with my own patched module until an official python release. -- Sylvain Thénault LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org ___ Python-Dev mailing list [email protected] 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 343 update (with statement context terminology)
On 4/25/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: > PEP 343 made a *deliberate, conscious design decision* to copy the semantics > of iterators by making the context management protocol a superset of the > context protocol (or rather, the context specification protocol in alpha 2). OK. It's possible I'll need to go back to PEP 343 to locate the justification for this design decision (as I can't find it in the documentation). I haven't done so thus far, as I am deliberately trying to retain a position as "newcomer who has only ready the documentation", because I want to offer that perspective. I've been drawn so far into design discussions now, that I am probably no longer of any use in that role. So now, I'm really just supporting Phillip's side of the discussion. Which isn't much help, as all we seem to be achieving is a 2 vs 1 impasse, rather than the previous 1 vs 1 :-( > What I don't understand is why you and Phillip are so keen on breaking this > deliberate symmetry with an existing part of the language design. Of course it > isn't necessary, but then neither was it necessary to make the iterator > protocol a superset of the iterable protocol. What *I* don't understand, is why the symmetry is so crucial to you. OK, I'll give in on this one (as Philip has done). I'll accept that objects providing __enter__ and __exit__ must also provide __context__. I'll accept your argument above that the parallel with generators and __iter__ is enough. I'll even accept that the name of the decorator is the only issue, and it's just a naming and documentation fix we're after here. But that leaves one fundamental point (I'm tempted to shout here, but I won't :-)) I still found the alpha 1 terminology and documentation completely natural and intuitive. Completely. Not "acceptable", but "completely natural". From the perspective of someone with limited understanding of the design, looking to the documentation for enlightenment. And that's got to be my last word. I can't judge the alpha 2 documentation any more, I'm too close to the problem now. Heck, I no longer even have usable terms to describe the objects involved, because every reference has to be qualified with (a1 terminology) or (a2 terminology). So I'll bow out at this point. +1 on a1 terminology, can't judge on anything else. (Oh, and +10 on just getting the damn thing resolved once and for all). I hope my contributions have been useful. Paul. ___ Python-Dev mailing list [email protected] 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 343 update (with statement context terminology)
Paul Moore wrote: > On 4/25/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: > I still found the alpha 1 terminology and documentation completely > natural and intuitive. Completely. Not "acceptable", but "completely > natural". From the perspective of someone with limited understanding > of the design, looking to the documentation for enlightenment. Don't get me wrong, I *like* the alpha1 terminology - looking at it in isolation it is very attractive (indeed, one of my early suggestions after AMK brought up the conflict between the docs and the implementation was to change the implementation to match the alpha 1 docs). But I backed away from that idea, because I believe the alpha 1 terminology will break badly as soon as you try to put it in a wider context. The term "context" is already overloaded with too many meanings (decimal arithmetic contexts, GUI drawing context objects, parser contexts, etc, etc). Normally the overloaded meanings don't matter, because you'll be working in one problem domain or another, so it will be clear which meaning is intended. The issue this poses for the with statement, however, is that its just a programming tool, so its potential use spans all application domains. And under the alpha 1 terminology, almost none of those existing context objects would be able to serve as with statement context objects (at best, they'd be context managers). So things like decimal.Context get left trying to find a sane name for what their __context__ method returns. decimal.Context.__context__() returns a . . . context? What? Wasn't it already a context? Oh, so it actually returns a "with statement context object". But that object still isn't really the context from a user's point of view - the context of interest to a user is the effect that object has on the runtime state (i.e. setting the decimal context for the current thread). That said, that might actually still be salvageable if the term 'context object' is appropriately qualified. . . "when requested by the with statement, a context manager returns a with statement context object that sets up and tears down the desired runtime context" The only implementation changes needed then would be to change contextlib.contextmanager to contextlib.context, contextlib.GeneratorContextManager to contextlib.GeneratorContext and change decimal.ContextManager to decimal.WithStatementContext > And that's got to be my last word. I can't judge the alpha 2 > documentation any more, I'm too close to the problem now. Heck, I no > longer even have usable terms to describe the objects involved, > because every reference has to be qualified with (a1 terminology) or > (a2 terminology). > So I'll bow out at this point. +1 on a1 terminology, can't judge on > anything else. (Oh, and +10 on just getting the damn thing > resolved once and for all). Since the only other two people who seem to really care about this are dead set against me, I'll see how the qualified term "with statement context object" pans out for clearing up any potential naming conflicts with domain-specific context objects, or with the nebulous entity that is the runtime context. I haven't seen an alpha2 freeze announcement yet, so I hopefully still have time to look into this. . . Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] SoC proposal: "fix some old, old bugs in sourceforge"
On Mon, Apr 24, 2006 at 09:45:41PM -0700, Neal Norwitz wrote: > hard bugs to fix. I guess there are also a lot that we can't > reproduce and the submitter is MIA. Those might be easier. Ping them > if not reproducible, if no response in a month, we close. The last time there was a thread suggesting closing old bugs, wasn't the consensus to leave them open for information purposes? --amk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Visual studio 2005 express now free
"Neil Hodgson" <[EMAIL PROTECTED]> writes: > Martin v. Löwis: > >> Apparently, the status of this changed right now: it seems that >> the 2003 compiler is not available anymore; the page now says >> that it was replaced with the 2005 compiler. >> >> Should we reconsider? > >I expect Microsoft means that Visual Studio Express will be > available free forever, not that you will always be able to download > Visual Studio 2005 Express. I don't think that's what Herb Sutter said in his ACCU keynote, which is where I'm pretty sure Guido got his information at the start of this thread (he was there too and the email appeared soon after). If I remember right, he said that 2005 was free, forever, and they'd think about later versions. I may be misremembering, and I certainly haven't read any official stuff from Microsoft... Cheers, mwh -- I also feel it essential to note, [...], that Description Logics, non-Monotonic Logics, Default Logics and Circumscription Logics can all collectively go suck a cow. Thank you. -- http://advogato.org/person/Johnath/diary.html?start=4 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] EuroPython 2006: Call for papers
Hi all, A shameless plug and reminder for EuroPython 2006 (July 3-5): * you can submit talk proposals until May 31st. * there is a refereed papers track; deadline for abstracts: May 5th. See the full call for papers below. A bientot, Armin Rigo & Carl Friedrich Bolz EuroPython 2006 CERN, Geneva, 3-5 July Refereed Track: Call for Paper http://www.europython.org EuroPython is the only conference in the Python world that has a properly prestigious peer-reviewed forum for presenting technical and scientific papers. Such papers, with advanced and highly innovative contents, can equally well stem from academic research or industrial research. We think this is an important function for EuroPython, so we are even making some grants available to help people with travel costs. For this refereed track, we will be happy to consider papers in subject areas including, but not necessarily limited to, the following: * Python language and implementations * Python modules (in the broadest sense) * Python extensions * Interoperation between Python and other languages / subsystems * Scientific applications of Python * Python in Education * Benchmarking Python We are looking for Python-related scientific and technical papers of advanced, highly innovative content that present the results of original research (be it of the academic or "industrial research" kind), with proper attention to "state of the art" and previous relevant literature/results (whether such relevant previous literature is itself directly related to Python or not). We do not intend to let the specific subject area block a paper's acceptance, as long as the paper satisfies other requirements: innovative, Python-related, reflecting original research, with proper attention to previous literature. Abstracts = Please submit abstracts of no more than 200 words to the refereeing committee. You can send submissions no later than 5 May 2006. We shall inform you whether your paper has been selected no later than 15 May 2006. For all details regarding the submission of abstracts, please see the EuroPython website (http://www.europython.org). Papers If your abstract is accepted, you must submit your corresponding paper before 17 June 2006. You should submit the paper as a PDF file, in A4 format, complete, "stand-alone", and readable on any standards-compliant PDF reader (basically, the paper must include all fonts and figures it uses, rather than using external pointers to them; by default, most PDF-preparation programs typically produce such valid "stand-alone" PDF documents). Refereeing == The refereeing committee, selected by Armin Rigo, will examine all abstracts and papers. The committee may consult external experts as it deems fit. Referees may suggest or require certain changes and editing in submissions, and make acceptance conditional on such changes being performed. We expect all papers to reflect the abstract as approved and reserve the right, at our discretion, to reject a paper, despite having accepted the corresponding abstract, if the paper does not substantially correspond to the approved abstract. Presentation The paper must be presented at EuroPython by one or more of the authors. Presentation time will be either half an hour or an hour, including time for questions and answers, depending on each paper's details, and also on the total number of papers approved for presentation. Proceedings === We will publish the conference's proceedings in purely electronic form. By presenting a paper, authors agree to give the EuroPython conference non-exclusive rights to publish the paper in electronic forms (including, but not limited to, partial and total publication on web sites and/or such media as CDROM and DVD-ROM), and warrant that the papers are not infringing on the rights of any third parties. Authors retain all other intellectual property rights on their submitted abstracts and papers excepting only this non-exclusive license. Subsidised travel = We have funds available to subsidise travel costs for some presenters who would otherwise not be able to attend EuroPython. When submitting your abstract, please indicate if you would need such a subsidy as a precondition of being able to come and present your paper. (Yes, this possibility does exist even if you are coming from outside of Europe. Papers from people in New Zealand who can only come if their travel is subsidised, for example, would be just fine with us...). ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman
Re: [Python-Dev] PEP 343 update (with statement context terminology)
At 07:24 PM 4/25/2006 +1000, Nick Coghlan wrote: >So things like decimal.Context get left trying to find a sane name for what >their __context__ method returns. decimal.Context.__context__() returns a . . >. context? What? Wasn't it already a context? Oh, so it actually returns a >"with statement context object". But that object still isn't really the >context from a user's point of view - the context of interest to a user is >the >effect that object has on the runtime state (i.e. setting the decimal context >for the current thread). > >That said, that might actually still be salvageable if the term 'context >object' is appropriately qualified. . . > >"when requested by the with statement, a context manager returns a with >statement context object that sets up and tears down the desired runtime >context" If qualification of "context" is the only problem, I propose: context manager -- thing with __context__ method execution context object -- thing with __enter__/__exit__/__context__ execution context -- the abstract thing set up and torn down by the ECO "When requested by the with statement, a context manager returns an execution context object that sets up and tears down the desired execution context for the block." And I still call for @contextfactory as a decorator that creates a factory function returning an execution context. I don't think that calling it an "executioncontextfactory" or "executionfactory" or anything like that adds anything useful; it is after all coming from a library for dealing with execution contexts, so it's sufficiently clear, um, in context. :) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Updated context management documentation
I won't call this a resolution yet, since it'll probably be a few days before I get time to update the PEP itself, and the changes below are based on pulling together a few different threads of the recent discussion. However, I believe (hope?) we're very close to being done :) The heart of the matter is that, having put together a full documentation set based on the interpretation I intended when I updated PEP 343 last year, I've come to agree that, despite its problems, the alpha 1 documentation generally reads better than my intended approach did. So I just checked in a change that reverts to the alpha 1 terminology - the phrase "context specifier" disappears, and "context manager" goes back to referring to any object with a __context__ method. However, I made the changes below in order to address the conflicts between the alpha 1 documentation and implementation. Avoiding ambiguity Reverting to the alpha 1 terminology still left the problem of ambiguity in the terms "context" and "context object". Aside from the terms "runtime context" and "context of execution" to refer to application state when particular code is run, and the general English usage of the word "context", there are also too many kinds of context object (like decimal.Context) already out in the wild for us to simply adopt the term "context object" without qualifying it in some fashion. Lacking a better solution, I went for the straightforward approach of using "with statement context object" (and variants along those lines) in a number of places where the alpha 1 docs just used "context object". It's clumsy, but it seems to work (and in cases where application domain context objects like decimal.Context don't intrude, it's still possible to shorten the phrase). (An idea that just occurred to me in writing this email is "managed context". That's a lot less clumsy, and fits with the context manager idea. If other folks like it, we could probably switch to that either before or after alpha 2, depending on when Anthony wants to make the alpha release happen). Context expressions In response to a comment Aahz made, I tweaked the language reference to explicitly refer to the expression in the with statement as a "context expression". The result of the context expression must then be a context manager in order for the with statement to operate correctly. This means that, as far as users are concerned, the context expression defines the runtime context for the block of code in the with statement. Unless you're writing your own objects, the existence of context managers and with statement context objects will generally be an irrelevant implementation detail. Dealing with decimal.ContextManager I renamed this to decimal.WithStatementContext. It's ugly but it works, and the existence of this object is really an implementation detail anyway. (decimal.ManagedContext would definitely look better. . .) Dealing with contextlib.contextmanager As recently suggested (by Terry, IIRC), I renamed this to contextlib.contextfactory, as the decorator creates a factory function for producing with statement context objects. This name works fine for both standalone context factories and the __context__ method of a context manager (as that method is itself a context factory). (As a fortuitous accident, this actually aligns with descriptions I've read of normal generator functions as iterator factories. . .) Dealing with contextlib.GeneratorContextManager I renamed this to contextlib.GeneratorContext. The fact that it's in the contextlib module provides sufficient context to indicate that this is a with statement context object, so I could avoid the clumsy naming that was needed in the decimal module. Changes to contextlib.closing These changes weren't actually terminology related, but they got mixed in with the rest of the changes to the contextlib module. Firstly, as the state to be retained is trivial, contextlib.closing is now implemented directly rather than via a generator. Secondly, the documentation now shows an example of a class with a close() method using contextlib.closing directly as its own __context__() method. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] SoC proposal: "fix some old, old bugs in sourceforge"
Terry Reedy wrote: >> My unglamorous proposal is to review bugs & patches (starting with the >> oldest) and resolve at least 200 of them. > Funny, and nice!, that you should propose this. I thought of adding > something like this to the Python wiki as something I might mentor, but > hesitated because reviewing *is* not glamourous, because Google wants > code-writing projects, and because I am not one to mentor C code writing. I suppose the "new code" emphasis may make writing a proposal to fix bugs an exercise in futility. :) I'll submit it anyway, since I don't have any new whiz-bang features/applications/frameworks that I think deserve to be inflicted upon anybody. > The thing I worry about, besides you or whoever getting too bored after a > week, is that a batch of 50-100 nice new patches could then sit unreviewed > on the patch tracker along with those already there. Although I didn't state it explicitly, my intention was to push each item to completion, so that at the end bug+patch is closed with new code checked into svn. Since I should probably restrict the proposal to fixing things that actually require new code to be written (assuming closing out bogus/inappropriate bugs doesn't meet Google's expectations for SoC), I'll revise my number down to the 25-75 range so that there's time to make sure they're actually completed. ___ Python-Dev mailing list [email protected] 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 343 update (with statement context terminology)
Phillip J. Eby wrote: > If qualification of "context" is the only problem, I propose: > > context manager -- thing with __context__ method > execution context object -- thing with __enter__/__exit__/__context__ > execution context -- the abstract thing set up and torn down by the ECO > > "When requested by the with statement, a context manager returns an > execution context object that sets up and tears down the desired > execution context for the block." I just checked in a change that reverts to the alpha 1 terminology, but uses "with statement context" to work around the ambiguity issues. Hopefully as just an interim fix until we find something better, but I could live with it if I absolutely had to :) 'execution context object' I still find too ambiguous, because I'd like to be able to drop the 'object' off the end and still have something that refers to the right kind of object (just as we don't need to tack 'object' onto the end of context manager all the time). The best I've thought of is 'managed context' (and that only occurred to me about five minutes ago): "When requested by the with statement, a context manager returns a managed context object that sets up and tears down the desired execution context for the block." > And I still call for @contextfactory as a decorator that creates a > factory function returning an execution context. I don't think that > calling it an "executioncontextfactory" or "executionfactory" or > anything like that adds anything useful; it is after all coming from a > library for dealing with execution contexts, so it's sufficiently clear, > um, in context. :) I'm definitely sold on that one - I included it as part of my latest checkin since it dealt nicely with the alpha 1 documentation's contextmanager problem. As you say, the fact that it's in contextlib provides ample indication that it's talking about with statement contexts. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] SoC proposal: "fix some old, old bugs in sourceforge"
A.M. Kuchling wrote: > On Mon, Apr 24, 2006 at 12:30:12PM -0400, Alan McIntyre wrote: > >> My unglamorous proposal is to review bugs & patches (starting with the >> oldest) and resolve at least 200 of them. Is that too much? Too few? >> > I'd suggest 75 or maybe 100 bugs or patches, not 200. > > Thanks; that's helpful. I'll probably make a cursory pass over the bug list and get a better feel for what's there (I suppose I should have done that before posting my original email :). ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Updated context management documentation
On Wed, Apr 26, 2006 at 12:08:47AM +1000, Nick Coghlan wrote: > However, I made the > changes below in order to address the conflicts between the alpha 1 > documentation and implementation. IMHO this set of changes makes the terminology reasonably clear, so I'm happy with it. I've edited the What's New accordingly. --amk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] SoC proposal: "fix some old, old bugs in sourceforge"
On Tue, 25 Apr 2006, A.M. Kuchling wrote: > On Mon, Apr 24, 2006 at 09:45:41PM -0700, Neal Norwitz wrote: >> hard bugs to fix. I guess there are also a lot that we can't >> reproduce and the submitter is MIA. Those might be easier. Ping them >> if not reproducible, if no response in a month, we close. > > The last time there was a thread suggesting closing old bugs, wasn't > the consensus to leave them open for information purposes? maybe a note or special state "off" (open-for-fun) would be helpful for unwary newbies, looking for there little feat. cheers -- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Updated context management documentation
At 12:08 AM 4/26/2006 +1000, Nick Coghlan wrote: >Secondly, the documentation now shows an example >of a class with a close() method using contextlib.closing directly as its own >__context__() method. Sadly, that would only work if closing() were a function. Classes don't get turned into methods, so you'll need to change that example to use: def __context__(self): return closing(self) instead. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] SoC proposal: "fix some old, old bugs in sourceforge"
"Alan McIntyre" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > I suppose the "new code" emphasis may make writing a proposal to fix > bugs an exercise in futility. :) I personally consider anything *you* write to be 'new code'. Let us see what Google thinks. Patches that other people have written would be 'old code', so merely reviewing such, no matter how useful to us, would seem to not meet the criteria. > I'll submit it anyway, Please do. To me, this project would be as useful to Google as many. > Although I didn't state it explicitly, my intention was to push each > item to completion, so that at the end bug+patch is closed with new code > checked into svn. Good intention. One think you can't do is the necessary review of your own patch. Perhaps you could get pre-commitments to review patches for particular bugs. Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] SoC proposal: "fix some old, old bugs in sourceforge"
"A.M. Kuchling" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > On Mon, Apr 24, 2006 at 09:45:41PM -0700, Neal Norwitz wrote: >> hard bugs to fix. I guess there are also a lot that we can't >> reproduce and the submitter is MIA. Those might be easier. Ping them >> if not reproducible, if no response in a month, we close. > > The last time there was a thread suggesting closing old bugs, wasn't > the consensus to leave them open for information purposes? There was an opinion, but certainly not a consensus from me. I think that we should be more agressive in closing bug reports. 1. Open items should represent needed action on the Python documentation or the CPython implementation. Keeping invalid or unactioable items open constitutes noise that interferes with action on valid items. 2. Closed items are just as available for information purposes as open items. Just don't restrict a search a search to open items. 3. Closed items can be reopened either immediately, when the weekly tracker come out, or later, when new information arrives. Consider [ python-Bugs-1437614 ] can't send files via ftp on my MacOS X 10.3.9. https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1437614&group_id=5470 Both I and Ronald Oussoren though it almost certainly not a bug, but neither of us closed at the time. The OP never responded to argue otherwise. Does anyone really think this should be left open indefinitely 'for information purposes'? I just closed it. Perhaps next time I review part of the list, I will pick out a few items (say 5) I think should be closed but am less sure of and post here for other opinions. Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Must objects with __enter__/__exit__ also supply __context__?
But what's the use case? Have we actually got an example where it makes sense to use the "thing with __enter__ and __exit__ methods" in a with-statement, other than the (many) examples where the original __context__ method returns "self"? --Guido On 4/24/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Phillip J. Eby wrote: > > At 09:35 PM 4/24/2006 +0100, Paul Moore wrote: > >> The current, alpha 2, documentation insists that objects with > >> __enter__ and __exit__ methods must also define __context__ in such a > >> way that it returns self. > >> > >> I don't understand why that is necessary. > > It's not necessary at all. It's a deliberate design decision in the PEP, > deliberately copying the semantics of the iterator protocol. > > >> I can understand that it is convenient, in cases where __context__ > >> doesn't need to create a new object each time, but is it *necessary*? > >> > >> Specifically, is there a use case where you need to say "with x" where > >> x is the return value of a __context__ method, or where you call > >> __context__ on something you got from __context__? I can't find one in > >> the PEP or in the code for contextlib... > > There aren't any current use cases that require it, no. But how much harder > would it have been to develop itertools if the "all iterators are iterables" > identity hadn't been part of the original design? > > Requiring that all context managers also be context specifiers is harmless. > Not requiring it breaks the parallel with iterators and iterables, which means > that parallel can't be leveraged to explain how things work anymore. > > > The only benefit to this is that it allows us to have only one > > decorator. If the decorator is defined as returning a thing with > > __enter__ and __exit__, and such things must also have a __context__, > > then there is no need for a separate decorator that's defined as > > returning things that have __context__, nor to tweak the docs to explain > > that the single decorator does both, nor to have two names for the same > > decorator. > > > > So, it's sort of a documentation hack. :) > > It's a deliberate design decision to parallel the existing model provided by > iterators and iterables. > > Otherwise, you have to have three concepts: > >context specifiers (have __context__ method) >context managers (have __enter__/__exit__ methods) >combined specifier/managers (which have all three) > > There was no need for iterators to be iterables, either - that was a > deliberate design decision taken at the time iterators were introduced. I > merely copied that pre-existing approach for PEP 343. > > Cheers, > Nick. > > -- > Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia > --- > http://www.boredomandlaziness.org > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Must objects with __enter__/__exit__ also supply __context__?
At 11:37 AM 4/25/2006 -0700, Guido van Rossum wrote: >But what's the use case? Have we actually got an example where it >makes sense to use the "thing with __enter__ and __exit__ methods" in >a with-statement, other than the (many) examples where the original >__context__ method returns "self"? Objects returned by @contextfactory-decorated functions must have __enter__ and __exit__ (so @contextfactory can be used to define __context__ methods) *and* they must also have __context__, so they can be used directly in a "with" statement. I think that in all cases where you want this (enter/exit implies context method availability), it's going to be the case that you want the context method to return self, just as iterating an object with a next() method normally returns that object. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Reviewed patches [was: SoC proposal: "fix some old, old bugs in sourceforge"]
> The latest weekly tracker summary says about 1300, + 200 RFEs. ... > I worry about ... a batch of 50-100 nice new patches could then sit > unreviewed on the patch tracker along with those already there. Is there a good way to flag a patch as reviewed and recommendation made? I understand that if I do 5 at a time *and* want someone to look at a sixth, I can post to python-dev. Normally, though, I'll only look at one or two at a time. I don't see a good way to say "It looks good to me". I don't see any way to say "There were issues, but I think they're resolved now". So either way, I and the author are both sort of waiting for a committer to randomly happen back over old patches. -jJ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] what do you like about other trackers and what do you hate about SF?
I am starting to hash out what the Call for Trackers is going to say on the Infrastructure mailing list. Laura Creighton suggested we have a list of features that we would like to see and what we all hate about SF so as to provide some guidelines in terms of how to set up the test trackers that people try to sell us on. So, if you could, please reply to this message with ONE thing you have found in a tracker other than SF that you have liked (especially compared to SF) and ONE thing you dislike/hate about SF's tracker. I will use the replies as a quick-and-dirty features list of stuff that we would like to see demonstrated in the test trackers. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reviewed patches [was: SoC proposal: "fix some old, old bugs in sourceforge"]
On Tue, Apr 25, 2006 at 04:10:02PM -0400, Jim Jewett wrote: > I don't see a good way to say "It looks good to me". I don't see any > way to say "There were issues, but I think they're resolved now". So > either way, I and the author are both sort of waiting for a committer > to randomly happen back over old patches. If there are too many patches waiting for a committer to assess them, that probably points up the need for more committers. --amk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 343 update (with statement context terminology)
> So things like decimal.Context get left trying to find a sane > name for what their __context__ method returns. > decimal.Context.__context__() returns a . . . context? What? > Wasn't it already a context? Oh, so it actually returns a > "with statement context object". [I was OK with "context specifiers", but here is another attempt.] --- With statements execute in a temporary context. with with_expression as temporary_context_name: stmt1 stmt2 The with_expression must return an object implementing the Temporary Context protocol. The Temporary Context's __enter__ method runs before the statement block, and its __exit__ method runs after the block. Temporary Contexts can represent arbitrary changes to the execution environment. Often, they just ensure that a file is closed in a timely fashion. A more advanced example is Decimal.Context, which controls the precision of certain math calculations. Decimal.Context also implements the Temporary Context protocol, so that you can increase the precision of a few calculations without slowing down the rest of the program. -jJ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Reviewed patches [was: SoC proposal: "fix some old, old bugs in sourceforge"]
> If there are too many patches waiting for a committer to assess them, > that probably points up the need for more committers. Perhaps; part of the problem is with the SF workflow. New bug or patch comes in. Shows up on the list of new bugs, but not obviously ready for action. Not assigned to anyone, because it says not to. Patch added. email sent to anyone who made an explicit comment, but perhaps not to any committers. More comments. More patches. Finally ready. Another comment is made, maybe saying so, but certainly not with any magic words. The patch isn't even on the front page any more. ... So how are the committers supposed to even know that it is waiting for assessment? The solutions that I've seen work are (a) A committer gets involved (at least to be sent email) early (b) Someone bugs a committer out of band (despite the don't-assign rhetoric) (c) It gets fixed really fast, before it can fall off the first screen (d) Someone (such as Georg, recently) makes a point of going through old tickets almost at random. These are all pretty ad-hoc -jJ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Builtin exit, good in interpreter, bad in code.
On Mon, Apr 24, 2006 at 08:31:19AM +0200, "Martin v. L?wis" wrote: >Sean Reifschneider wrote: >> Thoughts? > >In Python 2.5, exit(0) exits. Eeexcellent. Thanks, Sean -- UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things. -- Doug Gwyn Sean Reifschneider, Member of Technical Staff <[EMAIL PROTECTED]> tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Internal documentation for egg formats now available
Please see http://svn.python.org/projects/sandbox/trunk/setuptools/doc/formats.txt for source, or http://peak.telecommunity.com/DevCenter/EggFormats for an HTML-formatted version. Included are summary descriptions of the formats of all of the standard metadata produced by setuptools, along with pointers to the existing manuals that describe the syntax used for representing requirements, entry points, etc. as text. The .egg, .egg-info, and .egg-link formats and layouts are also specified, along with the filename syntax used to embed project/version/Python version/platform metadata. Last, but not least, there are detailed explanations of how resources (such as C extensions) are extracted on-the-fly and cached, how C extensions get imported from zipfiles, and how EasyInstall works around the limitations of Python's default sys.path initialization. If there's anything else you'd like in there, please let me know. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Updated context management documentation
Nick Coghlan wrote: > (An idea that just occurred to me in writing this email is "managed > context". That's a lot less clumsy, and fits with the context manager > idea. +1 > Context expressions > In response to a comment Aahz made, I tweaked the language > reference to explicitly refer to the expression in the with statement > as a "context expression". The result of the context expression must > then be a context manager in order for the with statement to operate > correctly. +1 > Dealing with decimal.ContextManager > (decimal.ManagedContext would definitely look better. . .) +1 > Dealing with contextlib.contextmanager > As recently suggested (by Terry, IIRC), I renamed this to > contextlib.contextfactory, as the decorator creates a factory > function for producing with statement context objects. +1 > Dealing with contextlib.GeneratorContextManager >I renamed this to contextlib.GeneratorContext. The fact that it's > in the contextlib module provides sufficient context to indicate that > this is a with statement context object, so I could avoid the clumsy > naming that was needed in the decimal module. Might still be better to name this as contextlib.ManagedGeneratorContext (or contextlib.GeneratorManagedContext, but I think the former works better). This has been a long, tiring set of threads, but I think the end result is an improvement (particularly contextlib.contextfactory). Tim Delaney ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Must objects with __enter__/__exit__ also supply __context__?
On 4/25/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 11:37 AM 4/25/2006 -0700, Guido van Rossum wrote: > >But what's the use case? Have we actually got an example where it > >makes sense to use the "thing with __enter__ and __exit__ methods" in > >a with-statement, other than the (many) examples where the original > >__context__ method returns "self"? > > Objects returned by @contextfactory-decorated functions must have __enter__ > and __exit__ (so @contextfactory can be used to define __context__ methods) > *and* they must also have __context__, so they can be used directly in a > "with" statement. That doesn't make sense. *Except* for cases where __context__() returns self, when would I ever use the object returned by __context__() in a with statement? That would mean that I would have to write code like this: A = B.__context__() # Here, A is not B with A: I don't see any reason to write such code!!! The more I think about it the more I believe the parallel with __iter__ is a fallacy. There are many ways to get an iterator in your hands without calling X.__iter__(): not just iter(X), but also X.iterkeys(), enumerate(X), and so on. It makes total sense (in fact it is sometimes the only use case) to pass those things to a for loop for iteration, which implies calling iter() on them, which implies calling __iter__() method. But (again, *excluding* objects whose __context__ returns self!) I don't see any use cases for calling __context__() explicitly -- that is *always* done by a with-statement. So, again, I'm asking for a real use case, similar to the one provided by enumerate() or iterkeys(). > I think that in all cases where you want this (enter/exit implies context > method availability), it's going to be the case that you want the context > method to return self, just as iterating an object with a next() method > normally returns that object. Yeah, of course, just like for iterators. But the question remains, under what circumstances is it convenient to call __context__() explicit, and pass the result to a with-statement? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] what do you like about other trackers and what do youhate about SF?
"Brett Cannon" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > So, if you could, please reply to this message with ONE thing you have > found in a tracker other than SF that you have liked (especially > compared to SF) and ONE thing you dislike/hate about SF's tracker. I > will use the replies as a quick-and-dirty features list of stuff that > we would like to see demonstrated in the test trackers. The most useful thing I can think of is to be able to tag each item by the doc section (lang ref, lib ref, tut, pep) most applicable to the item and then be able to sort tracker items (on any of the lists, possibly) by such tags or be able to extract all tracker items, or all open tracker items, for a particular section. Terry Jan Reedy ___ Python-Dev mailing list [email protected] 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 343 update (with statement context terminology)
On 4/24/06, Aahz <[EMAIL PROTECTED]> wrote: > Let's go back to a pseudo-coded with statement: > > with EXPRESSION [as NAME]: > BLOCK > > What happens while BLOCK is being executed? Again, here's what I said > originally: > > EXPRESSION returns a value that the with statement uses to create a > context (a special kind of namespace). The context is used to > execute the BLOCK. The block might end normally, get terminated by > a break or return, or raise an exception. No matter which of those > things happens, the context contains code to clean up after the > block. I strongly object to your use of the term "namespace" here. The with statement does *not* create a new namespace. Using the term namespace will only confuse people who understand what it means (in Python) -- we have the global namespace, the builtin namespace, the local namespace, classes introduce a new namespace, etc. The with-statement does *not* create a namespace in this sense -- there's no new place where name lookup can take place. In particular, this code prints 42: x = 1 with whatever(doesnt_matter): x = 42 print x -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reviewed patches [was: SoC proposal: "fix some old, old bugs in sourceforge"]
"Jim Jewett" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] >> The latest weekly tracker summary says about 1300, + 200 RFEs. ... > >> I worry about ... a batch of 50-100 nice new patches could then sit >> unreviewed on the patch tracker along with those already there. > > Is there a good way to flag a patch as reviewed and recommendation made? Perhaps you could submit this as your wish item for a new tracker (see Brett's post). (I already used up mine ;-) tjr ___ Python-Dev mailing list [email protected] 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 343 update (with statement context terminology)
On Tue, Apr 25, 2006, Guido van Rossum wrote: > On 4/24/06, Aahz <[EMAIL PROTECTED]> wrote: >> >> Let's go back to a pseudo-coded with statement: >> >> with EXPRESSION [as NAME]: >> BLOCK >> >> What happens while BLOCK is being executed? Again, here's what I said >> originally: >> >> EXPRESSION returns a value that the with statement uses to create a >> context (a special kind of namespace). The context is used to >> execute the BLOCK. The block might end normally, get terminated by >> a break or return, or raise an exception. No matter which of those >> things happens, the context contains code to clean up after the >> block. > > I strongly object to your use of the term "namespace" here. The with > statement does *not* create a new namespace. Using the term namespace > will only confuse people who understand what it means (in Python) -- > we have the global namespace, the builtin namespace, the local > namespace, classes introduce a new namespace, etc. The with-statement > does *not* create a namespace in this sense -- there's no new place > where name lookup can take place. Right -- I've already been chastised for that. Unless someone has a better idea, I'm going to call it a "wrapper". -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "Argue for your limitations, and sure enough they're yours." --Richard Bach ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Internal documentation for egg formats now available
"Included are summary descriptions of the formats of all of the standard metadata produced by setuptools, along with pointers to the existing manuals that describe the syntax used for representing requirements, entry points, etc. as text. The .egg, .egg-info, and .egg-link formats and layouts are also specified" I also follow the chicken Scheme mailing list, and initially though this was a mistaken reference to http://www.call-with-current-continuation.org/eggs/. Is there any concern that the use of 'egg' might cause some confusion? -Brent ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Must objects with __enter__/__exit__ also supply __context__?
At 04:18 PM 4/25/2006 -0700, Guido van Rossum wrote: >But the question remains, >under what circumstances is it convenient to call __context__() >explicit, and pass the result to a with-statement? Oh. I don't know of any; I previously asked the same question myself. I just eventually answered myself with "I don't care; we need to require self-returning __context__ on execution context objects so that the documentation can appear vaguely sane." :) So, I don't know of any non-self-returning use cases for __context__ on an object that has __enter__ and __exit__. In fact, I suspect that we could strengthen the requirements to say that: 1. If you have __enter__ and __exit__, you MUST have a self-returning __context__ 2. If you don't have __enter__ and __exit__, you MUST NOT have a self-returning __context__ #2 is obvious since you can't use the object with "with" otherwise. #1 reflects the fact that it doesn't make any sense to take the context of a context. ___ Python-Dev mailing list [email protected] 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 343 update (with statement context terminology)
At 04:31 PM 4/25/2006 -0700, Aahz wrote: >Right -- I've already been chastised for that. Unless someone has a >better idea, I'm going to call it a "wrapper". Better idea: just delete the parenthetical about a namespace and leave the rest of your text alone, at least until the dust settles. I thought your original text was perfect except for the namespace thing. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Must objects with __enter__/__exit__ also supply __context__?
On 4/25/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 04:18 PM 4/25/2006 -0700, Guido van Rossum wrote: > >But the question remains, > >under what circumstances is it convenient to call __context__() > >explicit, and pass the result to a with-statement? > > Oh. I don't know of any; I previously asked the same question myself. I > just eventually answered myself with "I don't care; we need to require > self-returning __context__ on execution context objects so that the > documentation can appear vaguely sane." :) > > So, I don't know of any non-self-returning use cases for __context__ on an > object that has __enter__ and __exit__. In fact, I suspect that we could > strengthen the requirements to say that: > > 1. If you have __enter__ and __exit__, you MUST have a self-returning > __context__ > > 2. If you don't have __enter__ and __exit__, you MUST NOT have a > self-returning __context__ > > #2 is obvious since you can't use the object with "with" otherwise. #1 > reflects the fact that it doesn't make any sense to take the context of a > context. I would augment #1 to clarify that if you have __enter__ and __exit__ you may not have __context__ at all; if you have all three, __context__ must return self. #2 is unnecessary (already covered elsewhere). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Must objects with __enter__/__exit__ also supply __context__?
At 05:20 PM 4/25/2006 -0700, Guido van Rossum wrote: >I would augment #1 to clarify that if you have __enter__ and __exit__ >you may not have __context__ at all; if you have all three, >__context__ must return self. Well, requiring the __context__ allows us to ditch the otherwise complex problem of why @contextfactory functions' return value is usable by "with", without having to explain it separately. So, I don't think there's any reason to provide an option; there should be Only One Way To Do It. Well, actually, two. That is, you can have one method or all three. Two is right out. :) (ObMontyPython: Wait, I'll come in again...) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Internal documentation for egg formats now available
At 04:41 PM 4/25/2006 -0700, Brent Fulgham wrote: >"Included are summary descriptions of the formats of all of the standard >metadata produced by setuptools, along with pointers to the existing >manuals that describe the syntax used for representing requirements, entry >points, etc. as text. The .egg, .egg-info, and .egg-link formats and >layouts are also specified" > >I also follow the chicken Scheme mailing list, and initially though this was >a mistaken reference to http://www.call-with-current-continuation.org/eggs/. > >Is there any concern that the use of 'egg' might cause some confusion? Not for the software, anyway. As long as nobody asks EasyInstall to install something from that page, and as long as they're not in the habit of installing Scheme extensions to their Python directories, everything will be fine. :) Just for the heck of it, I tried asking easy_install to install some of the stuff on that page, and it griped about most of the eggs listed on that page not having version numbers, and then it barfed with a ZipImportError after downloading the .egg and observing that it was not a valid zip file. (It hadn't actually installed the egg file yet, so no changes were made to the Python installation.) So, also just for the heck of it, I'm tempted to add some code to easy_install to notice when it encounters a tarball .egg (which is what the Scheme/Chicken eggs are), and maybe have it explain that Scheme eggs aren't Python eggs, perhaps in humorous fashion. If I did add such code, you might even call it an "easter egg", I suppose... ;) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] what do you like about other trackers and what doyouhate about SF?
"Terry Reedy" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > The most useful thing I can think of is to be able to tag each item by > the doc section (lang ref, lib ref, tut, pep) most applicable to the item > and then be able to sort tracker items (on any of the lists, possibly) by > such tags or be able to extract all tracker items, or all open tracker > items, for a particular section. In thinking some more, I realized that the *basic problem* is that the SF bug tracker is a mostly-closed, fixed-design, shared DB application with data access restricted to the canned interface. What I therefore think we need is an extensible application (preferably open-source) written on top of an rdbms (ditto). We should be able to add fields, tables, reports, and scripts. We should be able to write the latter in Python using the standard DB API. If necessary, we should be able to add the interface if not already existent. I think being able to access *our* data and do whatever we want with it is, in the long run, more important than any specific list of canned features. My first post, quoted above, illustrates the sort of Python-specific feature that I would not expect to find exactly built in to any tracker but which we could add with the flexibility that is my real wish. Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] draft of externally maintained packages PEP
here is the rough draft of the PEP for packages maintained externally from Python itself. There is some missing, though, that I would like help filling in. I don't know who to list as the contact person (i.e., the Python developer in charge of the code) for Expat, Optik or pysqlite. I know Greg Ward wrote Optik, but I don't know if he is still active at all (I saw AMK's email on Greg being busy). I also thought Gerhard Haering was in charge of pysqlite, but he has never responded to any emails about this topic. Maybe the responsibility should go to Anthony since I know he worked to get the package in and probably cares about keeping it updated? As for Expat (the parser), is that Fred? I also don't know what version of ctypes is in 2.5 . Thomas, can you tell me? Otherwise, I have cc:ed the people I do know who are in charge of some packages. Can you please look over your package information and let me know if you want anything changed? --- PEP: XXX Title: Externally Maintained Packages Version: $Revision: 43251 $ Last-Modified: $Date: 2006-03-23 06:28:55 -0800 (Thu, 23 Mar 2006) $ Author: Brett Cannon <[EMAIL PROTECTED]> Status: Active Type: Informational Content-Type: text/x-rst Created: XX-XXX-2006 Abstract There are many great pieces of Python software developed outside of the Python standard library. Sometimes it makes sense to incorporate these externally maintained packages into the standard library in order to fill a gap in the tools provided by Python. But by having the packages maintained externally it means Python's developers do not have direct control over the packages. Some package developers prefer to have bug reports and patches go through them first instead of being directly applied by Python developers. This PEP is meant to record details of packages in the standard library. Specifically, it is meant to keep track of any specific maintenance needs for each package. It also is meant to allow people to know which version of a package is in which version of Python. Externally Maintained Packages == Below is a list of modules/packages within Python that are externally maintained. Any special notes in terms of maintenance of the code within the Python code repository are mentioned. The section title is the name of the package as known outside of the Python standard library. The "standard library name" is what the package is named within Python. The "contact person" is the Python developer in charge of maintaining the package. The "synchronisation history" lists what external version of the package was included in each version of Python (if different from the previous version). ctypes -- - Web page http://starship.python.net/crew/theller/ctypes/ - Standard library name ctypes - Contact person Thomas Heller - Synchronisation history * XXX (2.5) Bugs can be reported to either the Python tracker [#python-tracker]_ or the ctypes tracker [#ctypes-tracker]_ and assigned to Thomas Heller. ElementTree --- - Web page http://effbot.org/zone/element-index.htm - Standard library name xml.etree - Contact person Fredrik Lundh - Synchronisation history * 1.2.6 (2.5) Patches should not be directly applied to Python HEAD, but instead reported to the Python tracker [#python-tracker]_ (critical bug fixes are the exception). Bugs should also be reported to the Python tracker. Both bugs and patches should be assigned to Fredrik Lundh. Expat XML parser - Web page http://www.libexpat.org/ - Standard library name N/A (this refers to the parser itself, and not the Python bindings) - Contact person XXX - Synchronisation history * 1.95.8 (2.4) * 1.95.7 (2.3) Optik - - Web site http://optik.sourceforge.net/ - Standard library name optparse - Contact person XXX - Synchronisation history * 1.5.1 (2.5) * 1.5a1 (2.4) * 1.4 (2.3) pysqlite - Web site http://www.sqlite.org/ - Standard library name sqlite3 - Contact person XXX - Synchronisation history * 2.1.3 (2.5) References == .. [#python-tracker] Python tracker (http://sourceforge.net/tracker/?group_id=5470) .. [#ctypes-tracker] ctypes tracker (http://sourceforge.net/tracker/?group_id=71702) Copyright = This document has been placed in the public domain. .. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 coding: utf-8 End: ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PY_FORMAT_SIZE_T warnings on OS X
On 4/2/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Tim Peters wrote: > > For gcc we _could_ solve it in the obvious way, which I guess Martin > > was hoping to avoid: change Unixish config to detect whether the > > platform C supports the "z" format modifier (I believe gcc does), and > > if so arrange to stick > > > > #define PY_FORMAT_SIZE_T "z" > > It's not gcc to support "z" (except for the compile-time check); it's > the C library (on Unix, the C library is part of the system, not part > of the compiler). > > But yes: if we could detect in configure that the C library supports > %zd, then we should use that. I created patch 1474907 with a fix for it. Checks if %zd works for size_t and if so sets PY_FORMAT_SIZE_T to "z", otherwise just doesn't set the macro def. Assigned to Martin to make sure I didn't foul it up, but pretty much anyone could probably double-check it. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Must objects with __enter__/__exit__ also supply __context__?
On 4/25/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 05:20 PM 4/25/2006 -0700, Guido van Rossum wrote: > >I would augment #1 to clarify that if you have __enter__ and __exit__ > >you may not have __context__ at all; if you have all three, > >__context__ must return self. > > Well, requiring the __context__ allows us to ditch the otherwise complex > problem of why @contextfactory functions' return value is usable by "with", > without having to explain it separately. Really? I thought that that was due to the magic in the decorator (and in the class it uses). In this case the use of magic is fine by me; I know I could reconstruct it from scratch if I had to (with only one or two bugs :-) but it's convenient to have it in the library. The primary use case is this: @contextfactory def foo(): ... with foo(): ... but a secondary one is this: class C: ... @contextfactory def __context__(self): ... with C(): Because of these two different uses it makes sense for @contextfactory to return an object that has both __context__ and __enter__/__exit__ methods. But that *still* doesn't explain why we are recommending that everything providing __enter__/__exit__ must also provide __context__! I still think we should take it out. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Must objects with __enter__/__exit__ also supply __context__?
At 08:09 PM 4/25/2006 -0700, Guido van Rossum wrote: >On 4/25/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > > At 05:20 PM 4/25/2006 -0700, Guido van Rossum wrote: > > >I would augment #1 to clarify that if you have __enter__ and __exit__ > > >you may not have __context__ at all; if you have all three, > > >__context__ must return self. > > > > Well, requiring the __context__ allows us to ditch the otherwise complex > > problem of why @contextfactory functions' return value is usable by "with", > > without having to explain it separately. > >Really? I thought that that was due to the magic in the decorator (and >in the class it uses). Actually, I got that explanation backwards above. What I meant is that the hard thing to explain is why you can use @contextfactory to define a __context__ method. All other examples of @contextfactory are perfectly fine, it's only the fact that you can use it to define a __context__ method. See, if @contextfactory functions return a thing *with* a __context__ method, how is that usable with "with"? It isn't, unless the thing also happens to have __enter__/__exit__ methods. This was the hole in the documentation that caused Nick to seek to revisit the decorator name in the first place. >But that *still* doesn't explain why we are recommending that >everything providing __enter__/__exit__ must also provide __context__! Because it means that users never have to worry about which kind of object they have. Either you pass a 1-method object to "with", or a 3-method object to "with". If you have a 2-method object, you can never pass it to "with". Here's the thing: you're going to have 1-method objects and you're going to have 3-method objects, we know that. But the only time a 2-method object is useful is if it's a tag-along to a 1-method object. It's easier from a documentation perspective to just say "you can have one method or three", and not get into this whole "well, you can also have two, but only if you use it with a one". And if you rule out the existence of the two-method variant, you don't have to veer into any complex questions of when you should use three methods instead of two, because the answer is simply "always use three". This isn't a technical problem, in other words. I had exactly the same POV as you on this until I read enough of Nick's rants on the subject to finally see it from the education perspective; it's easier to explain two things, one of which is a subtype of the other, versus explaining two orthogonal things that sometimes go together and sometimes don't, and the reasons that you might or might not want to put them together are tricky to explain. Of course, this approach opens a new hole, which is how to deal with people asking "why does it have to have a __context__ method if it's never called". So far, Nick's answer is "because we said so" (aka "deliberate design decision"), which isn't great, but at least it's honest. :) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Must objects with __enter__/__exit__ also supply __context__?
At 11:29 PM 4/25/2006 -0400, Phillip J. Eby wrote: >See, if @contextfactory functions return a thing *with* a __context__ >method, how is that usable with "with"? It isn't, unless the thing also >happens to have __enter__/__exit__ methods. This was the hole in the >documentation that caused Nick to seek to revisit the decorator name in the >first place. Argh. I seem to be tongue-tied this evening. What I mean is, if @contextfactory functions' return value is usable as a "with" expression, that means it must have a __context__ method. But, if you are using @contextfactory to *define* a __context__ method, the return value should clearly have __enter__ and __exit__ methods. What this means is that if we describe the one method and the two methods as independent things, there is no *single* name we can use to describe the return value of a @contextfactory function. It's a wave and a particle, so we either have to start talking about "wavicles" or have some detailed explanation of why @contextfactory function return values are both waves and particles at the same time. However, if we say that particles are a kind of wave, and have all the same features as waves but just add a few others, then we can simply say @contextfactory functions return particles, and the waviness is implied, and all is right in the world. At least, until AMK comes along and asks why you can't separate the particleness from the waveness, which was what started this whole thing in the first place... :) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] GNU info version of documentation
Something's gone south in the GNU info conversion of the documentation on the
trunk. If there's anyone here with time to look at it, I'd appreciate it.
Unfortunately, the GNU info conversion is one of the bits I understand the
least in the doc tool chain, and there's little information in the error
message:
$ make info
cd info && make EMACS=emacs WHATSNEW=whatsnew25
make[1]: Entering directory `/home/fdrake/projects/python/trunk/Doc/info'
Using emacs to build the info docs
EMACS=emacs ../tools/mkinfo ../lib/lib.tex python-lib.texi python-lib.info
emacs -batch -q --no-site-file
-l /home/fdrake/projects/python/trunk/Doc/tools/py2texi.el --eval (setq
py2texi-dirs '("/home/fdrake/projects/python/trunk/Doc/lib"
"/home/fdrake/projects/python/trunk/Doc/commontex" "../texinputs")) --eval
(setq py2texi-texi-file-name "python-lib.texi") --eval (setq
py2texi-info-file-name "python-lib.info") --eval (py2texi
"/home/fdrake/projects/python/trunk/Doc/lib/lib.tex") -f kill-emacs
Mark set
Unknown environment: quote
Unknown environment: quote
Unknown environment: quote
Unknown environment: quote
Unknown environment: longtable
Wrong type argument: char-or-string-p, nil
make[1]: *** [python-lib.info] Error 255
make[1]: Leaving directory `/home/fdrake/projects/python/trunk/Doc/info'
make: *** [info] Error 2
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Must objects with __enter__/__exit__ also supply __context__?
I'm not convinced. On 4/25/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 11:29 PM 4/25/2006 -0400, Phillip J. Eby wrote: > >See, if @contextfactory functions return a thing *with* a __context__ > >method, how is that usable with "with"? It isn't, unless the thing also > >happens to have __enter__/__exit__ methods. This was the hole in the > >documentation that caused Nick to seek to revisit the decorator name in the > >first place. > > Argh. I seem to be tongue-tied this evening. What I mean is, if > @contextfactory functions' return value is usable as a "with" expression, > that means it must have a __context__ method. But, if you are using > @contextfactory to *define* a __context__ method, the return value should > clearly have __enter__ and __exit__ methods. > > What this means is that if we describe the one method and the two methods > as independent things, there is no *single* name we can use to describe the > return value of a @contextfactory function. It's a wave and a particle, so > we either have to start talking about "wavicles" or have some detailed > explanation of why @contextfactory function return values are both waves > and particles at the same time. > > However, if we say that particles are a kind of wave, and have all the same > features as waves but just add a few others, then we can simply say > @contextfactory functions return particles, and the waviness is implied, > and all is right in the world. At least, until AMK comes along and asks > why you can't separate the particleness from the waveness, which was what > started this whole thing in the first place... :) > > > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] draft of externally maintained packages PEP
Brett Cannon wrote: > here is the rough draft of the PEP for packages maintained externally > from Python itself. There is some missing, though, that I would like > help filling in. > > I don't know who to list as the contact person (i.e., the Python > developer in charge of the code) for Expat, Optik or pysqlite. I know > Greg Ward wrote Optik, but I don't know if he is still active at all > (I saw AMK's email on Greg being busy). I also thought Gerhard > Haering was in charge of pysqlite, but he has never responded to any > emails about this topic. Maybe the responsibility should go to > Anthony since I know he worked to get the package in and probably > cares about keeping it updated? As for Expat (the parser), is that > Fred? > > I also don't know what version of ctypes is in 2.5 . Thomas, can you tell me? > ctypes > -- > - Web page > http://starship.python.net/crew/theller/ctypes/ > - Standard library name > ctypes > - Contact person > Thomas Heller > - Synchronisation history * 0.9.9.4 (2.5a1) * 0.9.9.6 (2.5a2) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
