Re: [Python-Dev] Terminology for PEP 343
Raymond Hettinger wrote: > With 343 accepted, we can now add __enter__() and __exit__() methods to > objects. > > What term should describe those objects in the documentation? Witty objects? ___ 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] Terminology for PEP 343
Raymond Hettinger wrote: > Whatever term is selected, it should be well thought-out and added to > the glossary. The choice of words will likely have a great effect on > learnability and on how people think about the new tool. When writing PEP 346, I ended up choosing "user defined statement" as a generic term for the sundry ways that the 'with' statement could be used. Signal blocking, exception logging, transactions, resource management, etc. . . For me, the key point was that to understand what a 'with' statement is really doing, you needed to understand the behaviour of the supplied object. This is far less the case with other compound Python statements. For 'if' statements and 'while' loops, the supplied object will always be interpreted as a boolean. In 'for' loops, the supplied object is guaranteed to return a series of other objects. An 'except' clause always expects an exception type of some description. For 'with' statements, all we really know is that the object may do something before the suite it is entered, and something else as the suite is exited. Other than that, it could be (or do) anything. Hence, 'user defined statement'. With that piece of terminology in place, the natural outcome was to call objects that supplied __enter__ and __exit__ methods "statement templates". I also used this term to come up with PEP 346's name for the generator to statement template conversion decorator: "stmt_template" (Like others, the fact that 'with' is a verb makes it very hard for me to interpret "with_template" correctly when I see it as a decorator - I always want to ask "with which template?") Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ 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] Decimal rounding doc
I'm preparing the pre-PEP of a Money module, and I don't want to explain the rounding methods there again. So my idea was to point to Decimal documentation regarding them. And I couldn't find them. Could it be we missed the explanation of each rounding mode in the Decimal docs? Or the sprints burned my head? If somebody confirm me that they're not explained, I'll open a bug to myself to do it... Thanks. .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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] Decimal rounding doc
Facundo Batista wrote: > I'm preparing the pre-PEP of a Money module, and I don't want to > explain the rounding methods there again. > > So my idea was to point to Decimal documentation regarding them. And I > couldn't find them. > > Could it be we missed the explanation of each rounding mode in the > Decimal docs? Or the sprints burned my head? > > If somebody confirm me that they're not explained, I'll open a bug to > myself to do it... The best I found was this bit in the documentation of the 'Context' constructor: "The rounding option is one of: ROUND_CEILING (towards Infinity), ROUND_DOWN (towards zero), ROUND_FLOOR (towards -Infinity), ROUND_HALF_DOWN (towards zero), ROUND_HALF_EVEN, ROUND_HALF_UP (away from zero), or ROUND_UP (away from zero)." Something a bit more forthcoming probably wouldn't hurt - specifically, explaining the reasoning behind 'ROUND_HALF_EVEN' would be good. Maybe you could put some headings on the 'Floating point notes' page and include an explanation of the rounding modes with the two existing discussions on that page: - Rounding Errors and Precision (existing) - Rounding Modes (new) - Special Floating Point Values (existing) Regards, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ 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] getch() in msvcrt does not accept extended characters.
On Fri, Jul 01, 2005, Darryl Dixon wrote: > > Is it worth sending in a patch to the sourceforge patch-tracker > implementing this? Is it OK for msvcrt_getch to return Unicode when > appropriate? Let's put it this way: you probably won't get much in the way of forward motion on this unless you do post a patch. It passes the smell test of not being horribly unPythonic, if that's what you want to know. Note that you're likely to be required to add a new function with this feature, but that can be argued later. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ f u cn rd ths, u cn gt a gd jb n nx prgrmmng. ___ 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] Decimal rounding doc
On Fri, Jul 01, 2005, Facundo Batista wrote: > > I'm preparing the pre-PEP of a Money module, and I don't want to > explain the rounding methods there again. > > So my idea was to point to Decimal documentation regarding them. And I > couldn't find them. > > Could it be we missed the explanation of each rounding mode in the > Decimal docs? Or the sprints burned my head? My suspicion is that someone at some point thought that Cowlishaw was sufficient; we probably should write some base-level docs that explain the Python mechanisms and refer to Cowlishaw for details. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ f u cn rd ths, u cn gt a gd jb n nx prgrmmng. ___ 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] Decimal rounding doc
On 7/1/05, Aahz <[EMAIL PROTECTED]> wrote: > My suspicion is that someone at some point thought that Cowlishaw was > sufficient; we probably should write some base-level docs that explain > the Python mechanisms and refer to Cowlishaw for details. Well, it's already well explained, with examples and all, in the PEP 327: http://www.python.org/peps/pep-0327.html#rounding-algorithms I'll point to there from the Money PEP, but I think this should be somewhere in the docs. I mean, as a final user, you shouldn't read a PEP or a 3rd party doc to know how to use a module. .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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] getch() in msvcrt does not accept extended characters.
"Darryl Dixon" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Python on Windows. The Python interface to this function is in the C > code in msvcrtmodule.c, which has a (very thin) wrapper around the raw > OS system call. I think Fredrik made two points in this regard. 1) The current thin-wrapperness is intentional, not a bug. 2) Changing the behavior would break programs that depend on this feature. Not good. So, as Aahz also suggested, I suspect a new function might have more chance. Terry J. 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] Terminology for PEP 343
On Thu, 2005-06-30 at 22:41, Raymond Hettinger wrote: > With 343 accepted, we can now add __enter__() and __exit__() methods to > objects. > > What term should describe those objects in the documentation? Their raison d'etre is to bracket user code with setup and teardown methods, so how about the term "bracketing object"? Mark Russell ___ 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] Decimal rounding doc
> http://www.python.org/peps/pep-0327.html#rounding-algorithms > > I'll point to there from the Money PEP, but I think this should be > somewhere in the docs. I mean, as a final user, you shouldn't read a > PEP or a 3rd party doc to know how to use a module. I've got it from here. Will update the docs. Raymond ___ 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] Terminology for PEP 343
At 05:41 PM 6/30/2005 -0400, Raymond Hettinger wrote: >With 343 accepted, we can now add __enter__() and __exit__() methods to >objects. > >What term should describe those objects in the documentation? Resource managers. ___ 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] Decimal rounding doc
On Friday 01 July 2005 08:55, Facundo Batista wrote: > I'll point to there from the Money PEP, but I think this should be > somewhere in the docs. I mean, as a final user, you shouldn't read a > PEP or a 3rd party doc to know how to use a module. Please file a documentation bug on SF, with this link to the specific PEP section, so that we can get this fixed. Unless, of course, you have the time and inclination to finish it off yourself. :-) (I know, I've not been very helpful getting doc issues cleared up lately; I'm hoping that'll get a bit better soon.) -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] Missing docs (was Decimal rounding doc)
On Fri, Jul 01, 2005, Facundo Batista wrote: > On 7/1/05, Aahz <[EMAIL PROTECTED]> wrote: >> >> My suspicion is that someone at some point thought that Cowlishaw was >> sufficient; we probably should write some base-level docs that explain >> the Python mechanisms and refer to Cowlishaw for details. > > Well, it's already well explained, with examples and all, in the PEP 327: > > http://www.python.org/peps/pep-0327.html#rounding-algorithms > > I'll point to there from the Money PEP, but I think this should be > somewhere in the docs. I mean, as a final user, you shouldn't read a > PEP or a 3rd party doc to know how to use a module. Agreed. Unfortunately, that's one big area where Python needs work; new-style classes are probably the worst. If you wanted to take the lead and push a sprint on doc work, you'd be a hero. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ f u cn rd ths, u cn gt a gd jb n nx prgrmmng. ___ 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] Decimal rounding doc
On Friday 01 July 2005 11:36, Raymond Hettinger wrote: > I've got it from here. Will update the docs. Dang, a race condition. :-) Ok, Facundo, never mind the SF tracker item. -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] Terminology for PEP 343
On Friday 01 July 2005 11:44, Phillip J. Eby wrote: > Resource managers. Yeah, I was thinking that, but was somewhat ambivalent. But I definately like it better than anything else proposed so far. -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] Decimal rounding doc
On 7/1/05, Fred L. Drake, Jr. <[EMAIL PROTECTED]> wrote: > On Friday 01 July 2005 11:36, Raymond Hettinger wrote: > > I've got it from here. Will update the docs. > > Dang, a race condition. :-) > > Ok, Facundo, never mind the SF tracker item. :p. My original idea was to ask you for another pair of eyes, and I'd solve it myself. But, well, the sprint day here is finishing and I still didn't ended the Money test cases, so Raymond, go ahead if you like... and thanks! .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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] Missing docs (was Decimal rounding doc)
On 7/1/05, Aahz <[EMAIL PROTECTED]> wrote: > Agreed. Unfortunately, that's one big area where Python needs work; > new-style classes are probably the worst. If you wanted to take the > lead and push a sprint on doc work, you'd be a hero. Ehhh... what a good idea for PyCon 2006!! :D .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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] Terminology for PEP 343
On 7/1/05, Fred L. Drake, Jr. <[EMAIL PROTECTED]> wrote: > On Friday 01 July 2005 11:44, Phillip J. Eby wrote: > > Resource managers. > > Yeah, I was thinking that, but was somewhat ambivalent. But I definately like > it better than anything else proposed so far. > I say we steal from the C++ and the RAII paradigm and go with RMUW (Resource Management Using 'with'). No need to get cutesy and we already have acronym overload anyway, so one more won't kill us. -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
[Python-Dev] Money module
People: The Money two-days sprint in EuroPython 2005 has finished. We advanced a lot. The pre-PEP is almost done, and the corresponding test cases are all written. We need to finish the structure procesing for currency general information, and bring general functions to the module, but most of the decision-taking part is done. So, it's not a chaos any more, it's in a very coherent state, but yet it's not everything written in stone. So, if you want to influence somehow in the Money module, this is the moment to get in and participate. The project is in SourceForge (http://sourceforge.net/projects/pymoney), and there we have a mailing list (just to not bloat this one). Thank you. .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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] Inconsistent API for sets.Set and build-in set
On Thu, 2005-06-30 at 13:37, Raymond Hettinger wrote: > > If there are no objections, I propose to do the following (only in > > Python 2.4 and 2.5): > > > > * Add set.union_update() as an alias for set.update(). > > No. It was intentional to drop the duplicate method with the > hard-to-use name. There was some thought given to deprecating > sets.union_update() but that would have just caused unnecessary grief. Oh, okay. Did you run out of clever abbreviations after s/union_update/update/ or do you think that symmetric_difference_update is already easy enough to use? ;) Why was "update" chosen when you have two other forms of longer *_update() methods on sets? This is after all, a union and it's arguably more confusing not to have that in the name (especially given the "easy-to-use" other *_update() methods). > > I consider this a bug in 2.4, not a new feature, because without it, > it > > makes more work in porting applications. > > Bah. It's just one of the handful of search/replace steps: > >Set --> set >ImmutableSet --> frozenset >union_update --> update But an unnecessary one, IMO. > > I'm willing to Just Fix It, > > Please don't. All of the differences between set and Set were > intentional improvements (i.e. the hash algorithm's are different). I don't care about the implementation, I'm sure it's vastly superior. I'm concerned with the API. I don't agree that dropping union_update() is necessarily an improvement, but I guess I had my chance when the PEP was being debated, so I'll drop it. I do think you owe it to users to describe the differences in PLR $2.3.7 to aid people in the transition process. -Barry signature.asc Description: This is a digitally signed message part ___ 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] Terminology for PEP 343
[Brett Cannon] > I say we steal from the C++ and the RAII paradigm and go with RMUW > (Resource Management Using 'with' Or the-keyword-formerly-known-as-do Raymond ___ 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] Money module
[Facundo] > The pre-PEP is almost done, and the corresponding > test cases are all written. What is the part about the pre-PEP? Something like this probably shouldn't go in the standard library until it has been proven in the field. This doubly true for a module that has made some unusual OO design choices and has an unconventional decomposition of financial functions. * The exchange rate mechanism may end-up not being workable as it does not incorporate rate changes over time, differing forward and reverse rates, non-linear factors such as commission/fees, source currency, or multiple suppliers. * Time value of money computations are typically dimensionless (not sensitive to currency type or formatting) and they often have algorithm specific rounding needs (round at the end of compounding period or each year or only at the end). * The absence of a division operator may prove problematic for allocation routines. * Usually numeric formatting is kept independent from the rest of the design. It will be interesting to see how workable it is to make it part of the Context object. In Excel for instance, formatting is a property of some part of the hierarchy of worksheet, row or column, or specific cell. It is not linked to the context for mathematical operations. While the Money module remains experimental, it should remain a third-party package. Raymond ___ 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] Terminology for PEP 343
Nick Coghlan wrote: > Raymond Hettinger wrote: > >>Whatever term is selected, it should be well thought-out and added to >>the glossary. The choice of words will likely have a great effect on >>learnability and on how people think about the new tool. I tried to bring this up on python-list, but I didn't get much of a response. I suggested "witherator" as a too cute alternative, but was hoping to get some alternatives to that. http://mail.python.org/pipermail/python-list/2005-June/286684.html > For 'with' statements, all we really know is that the object may do > something before the suite it is entered, and something else as the > suite is exited. Other than that, it could be (or do) anything. Hence, > 'user defined statement'. I would say the key attribute is the "and something else as the suite is exited" part. With out that, the "with" statement isn't needed and a regular function or generator would work. A term which stresses finalizing may be appropriate. > With that piece of terminology in place, the natural outcome was to > call objects that supplied __enter__ and __exit__ methods "statement > templates". Will objects be created that can be used with and without "with" statements? I think that this could be a source of confusion. It seems to me that "with" statements require a "with" object, and that those objects probably shouldn't be used without the "with" statement. Having a clear separation might be a good idea. Should there be a "with" (different name most likely) type? Would there be any advantages of a "with" base object that can have constructor methods that can accept either a try-finally generator or two functions to insert into the __enter__ and __exit__ methods as arguments? For example, call a with object a "manage" object then: with manage.generator(open_file_gen) as f: BLOCK with manage.enter_exit(lock_func, unlock_func) as lock: BLOCK > I also used this term to come up with PEP 346's name for the generator > to statement template conversion decorator: "stmt_template" > > (Like others, the fact that 'with' is a verb makes it very hard for me > to interpret "with_template" correctly when I see it as a decorator - > I always want to ask "with which template?") I agree, the decorator adds a layer of complexity to it. I think the with-generator behavior needs to be described without the decorator version first, then the decorator becomes syntactic sugar to make it easier to do the same thing. Ron ___ 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] List copy and clear (was Re: Inconsistent API for sets.Set and build-in set)
Raymond Hettinger wrote: > Several thoughts: As I told you in a private dicussion, you have convinced me about copy. About clear, however, I feel I have to defend my colleagues and myself, who almost all wasted time once (but only once) searching how to clear a list. Improving the docs (like adding an additional example in the table at http://www.python.org/doc/2.4.1/lib/typesseq-mutable.html) would be good. To me, "del mylist[:]" and "mylist[:] = []" are not "how to clear a list" but "how to clear list using slicing". That's why I think it's counter-intuitive, since you end up using slicing in a situation that has nothing to do with slicing. We agree there's no need about generic clearing. It's only about consistency and ease of learning/self-documentation. So let's look at the reasons to not do it: - It's only useful for new Python programmers (I mean first-time clearers), once you know it, you know it. - That would be a third way to clear a list. However, I don't like this argument in this specific case, because IMO the current ways are just slicing capabilities, as "<< 1" and "* 2" can be the same on a int. - All APIs trying to emulate a list would end up incomplete. I have difficulty judging that one. A method addition doesn't sound so bad to me. If it is the showstopper, maybe a Python 3000 thing? Overall, I think the addition of clear would be an improvement to the language, particularly in the autocompletion world of ours;) Regards, Nicolas ___ 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] Terminology for PEP 343
[Raymond] > >>Whatever term is selected, it should be well thought-out and added to > >>the glossary. The choice of words will likely have a great effect on > >>learnability and on how people think about the new tool. [Ron Adam] > I tried to bring this up on python-list, but I didn't get much of a > response. I suggested "witherator" as a too cute alternative, but was > hoping to get some alternatives to that. That wins in the cuteness and trademarkability categories ;-) Here is a more plain and direct alternative proposal: "Decimal objects support the enter/exit protocol" On a separate note, I also propose that __exit__() be renamed to __leave__(). The enter/leave word pairing are a better fit in standard English: Entering the Austin city limits ... Leaving the Austin city limits. You may enter ... You may leave. Enter the Dragon ... Elvis has left the building. FWIW, there is precedent in x86 assembly language: enter: sets up nested procedure definition leave: reverses the effect of enter Likewise, GUI programmers use Enter and Leave for mouse events. Google has no shortage of hits for the pairing: http://www.google.com/search?q="enter+or+leave"; Raymond ___ 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] Terminology for PEP 343
Raymond writes: > On a separate note, I also propose that __exit__() be renamed to > __leave__(). The enter/leave word pairing are a better fit in standard > English: I don't feel strongly about it, but I tend to disagree. Certainly you will admit that enter-exit IS a gramatically correct pairing in English. Raymond argues that: > Google has no shortage of hits for the pairing: Yes, but google has about half as many hits for the enter-exit pairing. I think a factor of 2 is not really that big for this sort of thing. I would take that to mean that enter-leave and enter-exit are roughly equally frequent pairs with enter-leave being somewhat more prevelant. > FWIW, there is precedent in x86 assembly language: > Likewise, GUI programmers use Enter and Leave for mouse events. These precedents stand. I don't find them compelling, but they are certainly valid. In favor of "exit" over "leave" I have only two arguments. First, I just like "exit" better. Hmm... didn't find that compelling? I was afraid of that. The second (also not a very strong argument) is that "exit" is somewhat more distinct in meaning than "leave". Somehow for me "exit" has a faint connotation of a distinct boundary being crossed, while "leave" is somewhat less crisp. I would use "She left the ballpark." for someone walking into the dugout, climbing up into the stands, or walking out of the stadium, and might refer to the entire process. Using "She exited the ballpark." to me suggests the exact moment that she went through the door dividing outside from inside. If you accept this connotation, then it's clear that "exit" is a closer match for the with statement's behavior than "leave". Anyway, this stuff is always very subjective and, as I said, I'm just expressing an opinion. So take it for what it's worth. -- Michael Chermside ___ 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] Terminology for PEP 343
> I would use "She left the ballpark." for someone walking into the > dugout, climbing up into the stands, or walking out of the stadium, > and might refer to the entire process. Using "She exited the ballpark." > to me suggests the exact moment that she went through the door > dividing outside from inside. If you accept this connotation, then > it's clear that "exit" is a closer match for the with statement's > behavior than "leave". > > Anyway, this stuff is always very subjective and, as I said, I'm just > expressing an opinion. So take it for what it's worth. Hmm, that got me to thinking a bit more. Here's another subjective two cents worth. "exit" seems to be a more global concept and "leave" seems more local. For instance, I leave a room but exit a building. In Python, sys.exit and os._exit are grand exits rather than local exits for functions or modules. Raymond ___ 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] reducing self.x=x; self.y=y; self.z=z boilerplate code
Hi, I often find myself writing: class grouping: def __init__(self, x, y, z): self.x = x self.y = y self.z = z I hate it, and every time I show this to a Python newcomer I get that skeptic look. How about this for a change? class grouping: def __init__(self, .x, .y, .z): pass This is supposed to work the same way as: def __init__(self, x, y, z): self.x = x del x self.y = y del y self.z = z del z Currently the .x syntax leads to: def __init__(self, .x, .y, .z): ^ SyntaxError: invalid syntax I.e. it seems to me that there shouldn't be any backward compatibility issues. I'll write a PEP if I hear a few voices of support. (Otherwise I'll stick to my "adopt_init_args" workaround: http://phenix-online.org/cctbx_sources/libtbx/libtbx/introspection.py which does a similar job but doesn't look as elegant and is also quite inefficient). Cheers, Ralf ___ 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] reducing self.x=x; self.y=y; self.z=z boilerplate code
At 03:59 PM 7/1/2005 -0700, Ralf W. Grosse-Kunstleve wrote:
>Hi,
>
>I often find myself writing:
>
> class grouping:
>
> def __init__(self, x, y, z):
> self.x = x
> self.y = y
> self.z = z
>
>I hate it, and every time I show this to a Python newcomer I get that
>skeptic look. How about this for a change?
>
> class grouping:
>
> def __init__(self, .x, .y, .z):
> pass
This extends to any number of arguments:
class grouping:
def __init__(self, x, y, z):
self.__dict__.update(locals())
del self.self
Or if you prefer a more generic approach:
def initialize(ob, args):
if 'self' in args:
del args['self']
for k, v in args.items():
setattr(ob,k,v)
class grouping:
def __init__(self, x, y, z):
initialize(self, locals())
There's really no need for special syntax here, if your goal is simply to
reduce boilerplate.
>I'll write a PEP if I hear a few voices of support.
-1; there are lots of good solutions for this. For me, I usually have a
base class with something like this:
def __init__(self, **kw):
for k, v in kw.items():
if not hasattr(self.__class__, k):
raise TypeError("%s has no %r attribute" % (self.__class__,k))
else:
setattr(self,k,v)
And then subclasses define their attributes and defaults using class
attributes, properties, or other descriptors.
>(Otherwise I'll stick to my "adopt_init_args" workaround:
>http://phenix-online.org/cctbx_sources/libtbx/libtbx/introspection.py
>which does a similar job but doesn't look as elegant and is also
>quite inefficient).
There are more efficient solutions, especially __dict__.update().
___
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] reducing self.x=x; self.y=y; self.z=z boilerplate code
On Fri, 01 Jul 2005 19:22:20 -0400, "Phillip J. Eby" <[EMAIL PROTECTED]> wrote: >At 03:59 PM 7/1/2005 -0700, Ralf W. Grosse-Kunstleve wrote: > [snip] > >This extends to any number of arguments: > > class grouping: > def __init__(self, x, y, z): > self.__dict__.update(locals()) > del self.self If you use vars(self).update(locals()), it even looks halfway pleasant ;) I'm not sure what python-dev's current opinion of vars(obj) is though (I'm hoping someone'll tell me). Of course, both of these fall over for __slots__'ful classes. It'd be nice if there were a general way to deal with attributes of an instance, regardless of the implementation details of its memory layout. Jp ___ 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] reducing self.x=x; self.y=y; self.z=z boilerplate code
I am happy to see that others agree we need something better than self.x=x; self.y=y; self.z=z. Phillip J. Eby wrote: >class grouping: >def __init__(self, x, y, z): >initialize(self, locals()) Been there (older code): http://phenix-online.org/cctbx_sources/scitbx/scitbx/python_utils/misc.py I don't like it because - I do have to remember how to import adopt_init_args/initialize. - I also have to remember the locals() part (unpythonic boilerplate again). - I get both self.x and x. This lead to subtle bugs a few times when I accidentally assigned to x instead of self.x or vice versa in the wrong place). - It is sure to be less efficient than the .x support I propose. I'd be happy if - adopt_init_args/initialize became a (efficiently implemented) Python built-in. - and the locals() part is not needed. However, IMO the .x solution is still far better because I often want to do something like this: class grouping: def __init__(self, .keep_this, .and_this, but_not_this, .but_this_again): pass With the adopt_init_args/initialize solution you'd have to write: class grouping: def __init__(self, keep_this, and_this, but_not_this, but_this_again): initialize(self, locals(), exclude=["but_not_this"]) Unpythonic boilerplate again (the but_not_this duplication). Cheers, Ralf ___ 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] reducing self.x=x; self.y=y; self.z=z boilerplate code
Jp Calderone wrote: > If you use vars(self).update(locals()), it even looks halfway > pleasant ;) I'm not sure what python-dev's current opinion of > vars(obj) is though (I'm hoping someone'll tell me). > > Of course, both of these fall over for __slots__'ful classes. It'd > be nice if there were a general way to deal with attributes of an > instance, regardless of the implementation details of its memory > layout. That's where PJE's more generic approach comes in: def initialize(ob, args, excluded=['self']): for k in excluded: if k in args: del args[k] for k, v in args.items(): setattr(ob,k,v) class grouping: def __init__(self, x, y, z): initialize(self, locals()) Or, one could have a look at the 'namespace' module, which came out of the last pre-PEP covering this kind of area: http://namespace.python-hosting.com/ 'Record' is particularly interesting from an auto-initialisation point of view (the class attributes define the expected instance attributes). Although I may be a little biased, since I wrote that class. . . Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ 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] Terminology for PEP 343
Michael Chermside wrote: > In favor of "exit" over "leave" I have only two arguments. First, I > just like "exit" better. Hmm... didn't find that compelling? I was > afraid of that. I have a pretty simple reason for liking the enter/exit pair over the enter/leave pair. In the former case, both words start with the letter 'e', providing an obvious visual pairing that doesn't exist in the latter case. Since we're talking about source code, the visual mnemonic means more to me than the exact semantics of the actual words. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ 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] reducing self.x=x; self.y=y; self.z=z boilerplate code
Jp Calderone wrote: > If you use vars(self).update(locals()), it even looks halfway > pleasant ;) I'm not sure what python-dev's current opinion of > vars(obj) is though (I'm hoping someone'll tell me). http://docs.python.org/lib/built-in-funcs.html#l2h-76 is pretty clear: vars([object]) Without arguments, return a dictionary corresponding to the current local symbol table. With a module, class or class instance object as argument (or anything else that has a __dict__ attribute), returns a dictionary corresponding to the object's symbol table. The returned dictionary should not be modified: the effects on the corresponding symbol table are undefined. > Of course, both of these fall over for __slots__'ful classes. It'd be > nice if there were a general way to deal with attributes of an > instance, regardless of the implementation details of its memory > layout. I agree. Ideally I'd like this class grouping: __slots__ = True def __init__(self, .x, .y, .z): pass to be equivalent to: class grouping: __slots__ = ["x", "y", "z"] def __init__(self, x, y, z): self.x = x del x self.y = y del y self.z = z del z Cheers, Ralf ___ 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] Terminology for PEP 343
Raymond Hettinger wrote: > On a separate note, I also propose that __exit__() be renamed to > __leave__(). The enter/leave word pairing are a better fit in standard > English: I tend to associate leave with leaving, and leaving with arriving. I didn't even think the __enter__ / __exit__ names were an issue. Then again there's alway __premanage__ and __postmanage__. That fits Nicks requirement for visual pairing as they both start with 'p'. And then calling it a manager object fits very nicely too. Hmmm, wonder if you could implement programs based on gant charts using nested manager objects? Would the nested managers be mid-level managers? This might have some marketing appeal to large corporations. ;-) Ron ___ 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] reducing self.x=x; self.y=y; self.z=z boilerplate code
Nick Coghlan <[EMAIL PROTECTED]> wrote: > Jp Calderone wrote: > > If you use vars(self).update(locals()), it even looks halfway > > pleasant ;) I'm not sure what python-dev's current opinion of > > vars(obj) is though (I'm hoping someone'll tell me). > > > > Of course, both of these fall over for __slots__'ful classes. It'd > > be nice if there were a general way to deal with attributes of an > > instance, regardless of the implementation details of its memory > > layout. > > That's where PJE's more generic approach comes in: > > def initialize(ob, args, excluded=['self']): > for k in excluded: > if k in args: > del args[k] > for k, v in args.items(): > setattr(ob,k,v) > > class grouping: > def __init__(self, x, y, z): > initialize(self, locals()) I'm with everyone else on this, -1 on .x syntax. As provided in the 6 line function above, everything desired is available. You want something that you don't need to use the excluded argument for, but still has the same stench as what Ralf originally offered? def initialize(ob, args): for k, v in args.items(): if k[:1] == '_': setattr(ob,k[1:],v) class grouping: def __init__(self, _x, _y, _z): initialize(self, locals()) Now, don't get me wrong, definining __slots__ can be a pain in the tookus, but with a proper metaclass, that metaclass can define the __slots__ attribute based on the argument list for __init__(). There you go. A syntax change is wholly unnecessary. - Josiah ___ 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] Adding the 'path' module (was Re: Some RFE for review)
Thomas Heller: > OTOH, Python is lacking a lot when you have to handle unicode strings on > sys.path, in command line arguments, environment variables and maybe > other places. A new patch #1231336 "Add unicode for sys.argv, os.environ, os.system" is now in SourceForge. New parallel features sys.argvu and os.environu are provided and os.system accepts unicode arguments similar to PEP 277. A screenshot showing why the existing features are inadequate and the new features an enhancement are at http://www.scintilla.org/pyunicode.png One problem is that when using "python -c cmd args", sys.argvu includes the "cmd" but sys.argv does not. They both contain the "-c". os.system was changed to make it easier to add some test cases but then that looked like too much trouble. There are far too many variants on exec*, spawn* and popen* to write a quick patch for these. Neil ___ 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] reducing self.x=x; self.y=y; self.z=z boilerplate code
Josiah Carlson wrote: > Now, don't get me wrong, definining __slots__ can be a pain in the > tookus, but with a proper metaclass, that metaclass can define the > __slots__ attribute based on the argument list for __init__(). > > There you go. Where? The meta-class idea sounds interesting. Could you work it out? > A syntax change is wholly unnecessary. I wonder why everybody gets so agitated about a syntax enhancement proposal. I am not proposing a syntax change! I know enhancing the syntax is work, but shouldn't a syntax leading to less code clutter be the higher value? IMO a long-term gain counts for much more than avoiding a one-time investment implementing a useful feature. Take, for example, the syntax enhancement supporting "import foo as bar". I could just as easily write: import foo bar = foo del foo "A syntax change is wholly unnecessary." Why was it important enough anyway? It was a good enhancement because it is clearly more expressive and reduces clutter. In my experience the self.x=x; self.y=y etc. problem arises much more often than the problem solved by "import foo as bar". IMO a *built-in* solution is much more important in practice. Why does everybody have to reinvent the adopt_init_args/initialize wheel, or have to sheepishly type self.x=x...? I am not wedded to the .x idea, but counter-proposals should be at least approximately as powerful as what I propose. > class grouping: > def __init__(self, _x, _y, _z): > initialize(self, locals()) The "_x" alternative looks interesting but is problematic: it doesn't have a special meaning so far, but it is also not a syntax error. You are also not getting rid of the odd (from a learner's viewpoint) requirement to stick in "locals()". Remember where Python comes from: it goes back to a teaching language, enabling non-geeks to write programs. "initialize(self, locals())" doesn't fit that bill, especially if you have to import initialize first. In contrast def __init__(self, .x, .y, .z): almost looks like ^^ self.x and should therefore be easy to learn and remember. I'd also be happy with def __init__(self, self.x, self.y, self.z): which wouldn't be too different from unpacking tuples (and is currently a syntax error). However, remember, elegance = power/length. .x above has the same power as self.x, but is shorter, therefore more elegant. :) Hoping-that-this-leads-to-some-consensus-for-a-*built-in*-solution-ly yours, Ralf ___ 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] reducing self.x=x; self.y=y; self.z=z boilerplate code
Ralf W. Grosse-Kunstleve wrote: > I know enhancing the syntax is work, but shouldn't a syntax leading to > less code clutter be the higher value? IMO a long-term gain counts for > much more than avoiding a one-time investment implementing a useful > feature. Take, for example, the syntax enhancement supporting "import > foo as bar". I could just as easily write: > > import foo > bar = foo > del foo > > "A syntax change is wholly unnecessary." > Why was it important enough anyway? It was a good enhancement because > it is clearly more expressive and reduces clutter. > > In my experience the self.x=x; self.y=y etc. problem arises much more > often than the problem solved by "import foo as bar". IMO a *built-in* > solution is much more important in practice. Why does everybody have to > reinvent the adopt_init_args/initialize wheel, or have to sheepishly > type self.x=x...? Actually, this reminds me of a recent suggestion (from AMK?) about being able to get at both the packed and unpacked form of an argument via: def f(arg as (a, b, c)): print arg print c, b, a Then f([1, 2, 3]) would print: [1, 2, 3] 3 2 1 If the right hand side of 'as' permitted the same forms as are going to be permitted for the 'as' clause in 'with' statements, then Ralf's situation could be handled via: def __init__(self as s, x as s.x, y as s.y, z as s.z): pass Essentially, it allows arguments to be given two names - a public name (before the 'as', used for keyword arguments), and a private name (after the 'as', not used for keyword arguments, allows easy shorthand aliasing of self, unpacking of tuple arguments, and easy assignment of instance variables). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ 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] reducing self.x=x; self.y=y; self.z=z boilerplate code
On Fri, Jul 01, 2005, Ralf W. Grosse-Kunstleve wrote: > > I often find myself writing: > > class grouping: > > def __init__(self, x, y, z): > self.x = x > self.y = y > self.z = z > > I hate it, and every time I show this to a Python newcomer I get that > skeptic look. How about this for a change? > > class grouping: > > def __init__(self, .x, .y, .z): > pass This is off-topic for python-dev. Please take it to comp.lang.python. (It's not immediately obvious that this is off-topic, I know, but please take my word for it.) -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ f u cn rd ths, u cn gt a gd jb n nx prgrmmng. ___ 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] reducing self.x=x; self.y=y; self.z=z boilerplate code
On Saturday 02 July 2005 08:59, Ralf W. Grosse-Kunstleve wrote: > I hate it, and every time I show this to a Python newcomer I get that > skeptic look. How about this for a change? > > class grouping: > > def __init__(self, .x, .y, .z): > pass -1. Syntax should not look like grit on my monitor. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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
