Re: [Python-Dev] Terminology for PEP 343
Michael Hudson wrote: > (I think Raymond has identified the problem I have with resource > manager more clearly then I did; I certainly don't think I'd realise > what "decimal.Context() is a resource manager" meant at first > reading). I'm also worried that "resource manager" is too narrow a term, and would only fit by considerable stretching in many cases. I'm thinking about something like "context manager", or at least something with "context" in it. Greg ___ 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
Phillip J. Eby wrote: > At 11:48 PM 7/3/2005 -0400, Raymond Hettinger wrote: > with context_expression as variable: > # perform actions within a context > > The "with" statement establishes a context in which some operations are to > be performed. I like this. > The object produced by 'context_expression' must have __enter_context__ and > __exit_context__ methods, which will be invoked by the "with" statement > when the context is entered... And we could call this the "context protocol". Greg ___ 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:
>>"""
>>With Statements and Suite Management
>
>
>
> This is nicely done :-)
>
> Nit: Replace "e.g." with "such as".
>
> BTW, do you support changing __exit__ to __leave__? I think it provides
> a small but useful gain in usability.
I was initially -0 on the idea, and I've moved to a solid -1 after
spending more time thinking about it.
The only real pro I can see for 'leave' is that it is more common than
'exit' in conversational English, particularly when using the past
tense. However, I've come to see significant pros for staying with 'exit':
1. 'Exit' is more precise than 'leave'. 'exit' has just the one real
meaning - to go out of something. It has a couple of variants on the
theme, and can be used as both a verb and a noun, but the basic
meaning stays the same. However, the same cannot be said for 'leave'.
In addition to its usage as a synonym for 'exit', it can be used in
the sense of not taking something ('leave it behind'), not doing
something ('leave the lights on') or handing over responsibility
('leave it to me'). When used as a noun, it refers to permission ('you
have my leave') and absences ('annual leave').
'Exit' covers just what we mean, while 'leave' covers that and a hell
of a lot more, leading me to favour 'exit' as the more precise term.
2. Enter/exit and arrive/leave are the natural terminology pairings in
English. The first pair are more specific, implying the existence of
an 'inside' and an 'outside', while the latter pair are significantly
less fussy (e.g. consider arriving at and leaving a picnic in the
park, versus trying to enter and exit that same picnic). It is just a
quirk of the language that the more general term 'leave' is
substituted for many uses of 'exit' (particularly when the past tense
is involved). I suspect the single syllable of 'left' tends to win out
over the three syllable verbal gymnastics of 'exited' (try saying the
two words out loud - I found the difference to be surprising, and
significantly more marked than the difference between 'enter' and
'arrive').
In our case, code is written and read far more often than it is
spoken, again leading me to favour the use of 'exit', this time as the
more natural counterpart to 'enter'.
3. The common starting letter gives a nice visual pairing for
enter/exit. This is not the case for enter/leave, again leading to a
preference for the use of 'exit'.
Using 'leave' instead of 'exit' is an interesting idea, but I think
these are good reasons to stick with the PEP 343 terminology.
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
Raymond Hettinger wrote: > This is much improved. I think we're getting close. So far, I like > Nick's most recent version the best, but this is in the ballpark. I like some of Phillip's suggestions, particularly the 'context' term. I'll put some thought into combining the two over the next couple of days. I spent too much time today thinking about the differences between exit and leave ;) 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
On Tuesday 05 July 2005 02:57, Greg Ewing wrote: > I'm thinking about something like "context manager", > or at least something with "context" in it. Oh, I like this one. "Context manager" / "context protocol" work well for me. -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
[Python-Dev] getch() in msvcrt does not accept extended characters.
Hi, I'm sorry, I don't seem to have done a very good job at explaining the situation. I'll try again: 'getch()' is a low-level function provided on Windows to capture a single character of input from a user, /without echoing it to the screen/. As far as I can tell there's no other way of doing this with 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. Microsoft provide a way of accepting both normal ASCII codes, and extended characters via this system call. Currently, the Python wrapper in msvcrtmodule.c only supports the semantics of getting the bare ASCII codes, and not the extended characters. I would strongly suggest that it should support both. So, I guess in answer to the questions raised below; 1) I can't do it in Python code without getch() (hence the original email) 2) I would argue that in fact getch() is 'broken' in its current Python implementation, as it doesn't support what the OS implies /should/ be supported (and, indeed, if I input an extended character in response to a 'getch()' call, all I get back currently is an empty string). Hope this helps, D Fredrik wrote: >Darryl Dixon wrote: > >> Microsoft support capturing extended characters via _getch, but it requires >> making a >> second call to getch() if one of the 'magic' returns is encountered in the >> first call (0x00 >> or 0xE0). > >so why not do that in your python code? > >> The relevant chunk of code in Python that would probably need to be >> changed to support this appears to be in msvcrtmodule.c: > >if you change msvcrt, you'll break all the programs that uses getch() in >the prescribed way... > > -- Darryl Dixon <[EMAIL PROTECTED]> ___ 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] List copy and clear (was Re: Inconsistent API for sets.Set and build-in set)
>* and because Guido believes beginners tend to copy too much > (that is one reason why copy.copy is not a builtin) and that > the language should encourage correct behavior. OTOH, beginners tend to copy not enough - when for example iterating over a list being acting upon. Though my real argument for list.copy() as an aid to beginners is otherwise - a bit more obtuse/non-linear than that - so much so that it doesn't get much sympahty. It isn't realistic to expect beginners to pick up idioms near the outset of the learning process. Now, copying lists is not something the beginner will often want to do, and the argument that once they want to do so, they will also be comfortable with slicing and with more idiomatic Python is not an unreasonable argument. But I believe it misses something more fundamental. It is a belief that is extracted from my own experience in tackling Python as a first language - as an adult, being able - I think - to introspect a bit better as to the process than I could if I were doing so at a younger age, and more in the normal course. The downside of Guido hiding "copy" to the extent it is - by not having a list.copy(), by not having copy.copy as a built-in, by even rejecting the notion of a short blurb of the copy module in the tutorial - is that the confrontation with the distinction between copying and "=" assignment gets delayed and confusion on the point becomes frustrating - fundamentally so. It doens't seem to me that this is an outlandish notion by any means. It can't be - as I seemed to have experienced it. Guido called this "one of my favorite subjects" in my last go around here on this issue. Well, it is indeed an opinion I hold. Not of earthshaking importance. But I hold it firmly enough, nonetheless. My flexiblity is more on the issue as to the extent that Python should design itself around the needs of beginners. If the conclusion is that list.copy() is a distraction to the experienced programmer, and that the motivated beginner will get to where they need to get, in any case, with or without it - I'm on board. If the thought is that hiding "copy", or relying on idioms for a construct as fundamental as the list - is a favor to the beginner, I very much am not. Art ___ 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.
Whatever it is that you need 'getch' to do, can't you incorporate it first in an extension module you bundle with your application or library, rather than using the (broken?) wrapper in the msvcrt module? Jeff pgpArc0XfxgA7.pgp Description: PGP signature ___ 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] using pyhon from the MSYS shell
Aahz wrote: >>I was trying to compile a python plugin (for gimp) using the MSYS >>shell and the MINGW compiler. > > > python-dev is the wrong place for this question Actually, it isn't - he is really asking what the best way of porting Python to MSYS is. Regards, Martin ___ 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] using pyhon from the MSYS shell
lode leroy wrote: > maybe someone could extend os.path to do this in the standard distribution: > implement an msyspath.py, which calls ntpath for each function, and does a > replace at the end of the evaluation. The chances are good that nobody else will work on this - so it is likely that it is either you who are doing this, or nobody else. Then, when you eventually come up with a patch, somebody will tell you that you partially erred, and that it should have been done in a different way. Still, I think this might be the only way to come to a solution that gets integrated with Python. I'm personally in favour of supporting "MSYS" as a target system. If you want to do it, I'm willing to review patches, but I'm not willing to do them myself, as I don't use MSYS. If you believe that MSYS is a target system in a way similar to mingw32, and to cygwin, I believe it should get the same treatment as mingw32 and cygwin. That means all places that currently deal with either of these two systems should also deal with MSYS in a similar way. What this means in actual code, I don't know. OTOH, I already fail to follow you in the very first assumption: why is it that you need to change os.sep on MSYS? Regards, Martin ___ 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] Possible C API problem?
Gary Robinson wrote:
> #include
> static double gfSumChiSquare = 123.0;
>
> static PyObject *
> getSumChiSquare(PyObject *self, PyObject *args){
> return Py_BuildValue("d", gfSumChiSquare);
> }
>
> static PyMethodDef SimMethods[] = {
> {"getSumChiSquare", getSumChiSquare, METH_NOARGS, "Return
> fSumChiSquare"},
> {NULL, NULL, 0, NULL}/* Sentinel */
> };
>
> PyMODINIT_FUNC
> inittestfloat(void)
> {
> (void) Py_InitModule("testfloat", SimMethods);
> }
> Could it be that this is a python bug? Or am I doing something wrong?
You are doing something wrong. As getSumChiSquare is a METH_NOARGS
method, it shouldn't have a PyObject*args argument.
However, python-dev really isn't the place to get urgent help if
"there is intense time pressure to get the next release of our product
(http://www.goombah.com) ready". Instead, if you need help in this
case, you should hire somebody.
Regards,
Martin
___
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] >I'm sorry, I don't seem to have done a very good job at explaining > the situation. I'll try again: Actually, I think you did fine the first time, and the second time, and I see nothing new here. You, like thousands of others (including Guido himself), want at least one little bit of Python to be different. But you seem more persistent in ignoring responses and not takinge 'no' for an answer. So I suggest that you reread previous responses more carefully, and/or take your complaint to comp.lang.python. > 'getch()' is a low-level function provided on Windows to capture a > single character of input from a user, /without echoing it to the > screen/. As far as I can tell there's no other way of doing this with > 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. How many people have to say how many times that the thinness is intentional. The module was added some years ago to make life easier for Windows programmers to wanted to use the calls they were familiar with in the way they were familiar with, even though it makes their programs non-portable. > Microsoft provide a way of accepting both normal ASCII > codes, and extended characters via this system call. According to you, Microsoft requires two calls. Quoting you: >>> Microsoft support capturing extended characters via _getch, >>> but it requires making a second call to getch() if one of the >>> 'magic' returns is encountered in the first call (0x00 or 0xE0). You seem to be complaining that Python mimics Microsoft too well. > Currently, the > Python wrapper in msvcrtmodule.c only supports the semantics of getting > the bare ASCII codes, and not the extended characters. Based on the source code and your posts, the Python sematics is the same as the MS semantics with 'Python char' (string of length 1) substituted for 'C char'. So it seems untrue that Microsoft supports something Python does not and I am baffled why you keep saying so. If making a second call from Python somehow acts differently than making a second call from C, then you *have* failed to demonstrate or explain *that*, and that seems to me like itmight be a legitimate reason to complain. 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] Possible C API problem?
> You are doing something wrong. As getSumChiSquare is a METH_NOARGS > method, it shouldn't have a PyObject*args argument. While I am aware enough of your general expertise to be surprised if you were in error in your statement below about VAR_NOARGS, your statement obove does seem to contradict the docs: METH_VARARGS This is the typical calling convention, where the methods have the type PyCFunction. The function expects two PyObject* values. The first one is the self object for methods; for module functions, it has the value given to Py_InitModule4() (or NULL if Py_InitModule() was used). The second parameter (often called args) is a tuple object representing all arguments. This parameter is typically processed using PyArg_ParseTuple() or PyArg_UnpackTuple. ... METH_NOARGS Methods without parameters don't need to check whether arguments are given if they are listed with the METH_NOARGS flag. They need to be of type PyCFunction. When used with object methods, the first parameter is typically named self and will hold a reference to the object instance. In all cases the second parameter will be NULL. (http://python.fyxm.net/doc/2.3.5/api/common-structs.html#l2h-832 In other words the docs seem to explicitly state that the args will be supplied and what they will contain, so I'd assume that the C method should have them in their declaration. Moreover, METH_NOARGS needs to correspond to type PyCFunction, and the definition of type PyCFunction states that it must receive two args of PyObject*. Are the docs wrong or am I misreading them? Or are you wrong? Re your other comments, as mentioned in my personal email, the word done by folks in a couple of python forums in running tests does seem to confirm that there is some kind of bug involving gcc 3.3. The bus error appears independently of whether VAR_METHARGS or VAR_VARARGS is used. Also, (again as mentioned in my personal email) I do have 4 F/T experienced people working on this project, none of whom has the expertise to resolve this. Given that it looks like a real bug was uncovered, I think it was appropriate to post on the python forums about this. I only posted to python-dev because it was suggested that I do so by someone on the C++ sig. Gary -- Gary Robinson CTO Emergent Music, LLC [EMAIL PROTECTED] 207-942-3463 Company: http://www.goombah.com Blog:http://www.garyrobinson.net ___ 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.
Sorry all, It seems that the list mods have finally released a duplicate message that I wrote last week when I wasn't subscribed to the list. Please ignore the message below if you have read the previous copy already. D On Thu, 2005-06-30 at 09:43 +1200, Darryl Dixon wrote: > Hi, > > I'm sorry, I don't seem to have done a very good job at explaining > the situation. I'll try again: > 'getch()' is a low-level function provided on Windows to capture a > single character of input from a user, /without echoing it to the > screen/. As far as I can tell there's no other way of doing this with > 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. Microsoft provide a way of accepting both normal ASCII > codes, and extended characters via this system call. Currently, the > Python wrapper in msvcrtmodule.c only supports the semantics of getting > the bare ASCII codes, and not the extended characters. I would strongly > suggest that it should support both. > > So, I guess in answer to the questions raised below; > > 1) I can't do it in Python code without getch() (hence the original > email) > > 2) I would argue that in fact getch() is 'broken' in its current Python > implementation, as it doesn't support what the OS implies /should/ be > supported (and, indeed, if I input an extended character in response to > a 'getch()' call, all I get back currently is an empty string). > > Hope this helps, > D > > > Fredrik wrote: > >Darryl Dixon wrote: > > > >> Microsoft support capturing extended characters via _getch, but it > >> requires making a > >> second call to getch() if one of the 'magic' returns is encountered in the > >> first call (0x00 > >> or 0xE0). > > > >so why not do that in your python code? > > > >> The relevant chunk of code in Python that would probably need to be > >> changed to support this appears to be in msvcrtmodule.c: > > > >if you change msvcrt, you'll break all the programs that uses getch() in > >the prescribed way... > > > > -- Darryl Dixon <[EMAIL PROTECTED]> ___ 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] using pyhon from the MSYS shell
On Tue, Jul 05, 2005, "Martin v. L?wis" wrote: > Aahz wrote: >>Martin removed the attribution here: >>> >>>I was trying to compile a python plugin (for gimp) using the MSYS >>>shell and the MINGW compiler. >> >> python-dev is the wrong place for this question > > Actually, it isn't - he is really asking what the best way of > porting Python to MSYS is. Hrm. I thought we told people to start with comp.lang.python for porting questions, but I'm happy to be corrected. -- 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] Possible C API problem?
Gary Robinson wrote: > Are the docs wrong or am I misreading them? Or are you wrong? It turns out that I am wrong. The NOARGS functions are indeed called with an additional NULL argument; it's just that many functions with NOARGS in Python itself are declared without the additional argument. Regards, Martin ___ 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] using pyhon from the MSYS shell
Aahz wrote: > Hrm. I thought we told people to start with comp.lang.python for > porting questions, but I'm happy to be corrected. I'm unaware of such a policy, but I may have missed the relevant discussion. I could understand that questions of the kind "I tried to build Python on X, and the compiler gave me the error message Y" are for comp.lang.python - these messages are really the of the "I need help" kind. The specific message was more of the "I would like to change code fragment X to Y to make it work on platform Z" kind - although in the end, he still indicated that he appreciated help. Oh well, Martin ___ 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)
Arthur wrote: > If the thought is that hiding "copy", or relying on idioms for a > construct as fundamental as the list - is a favor to the beginner, > I very much am not. I don't think anyone believes that. It's more a feeling that Python shouldn't be cluttered up with things that are *only* for beginners. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [EMAIL PROTECTED] +--+ ___ 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
Fred L. Drake, Jr. wrote: > Oh, I like this one. "Context manager" / "context protocol" work well for me. And it means we get to say "decimal.context supports the context protocol", which sounds perfectly sensible, even obvious. :-) -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [EMAIL PROTECTED] +--+ ___ 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] using pyhon from the MSYS shell
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Aahz wrote: >> Hrm. I thought we told people to start with comp.lang.python for >> porting questions, but I'm happy to be corrected. > > I'm unaware of such a policy, but I may have missed the relevant > discussion. I could understand that questions of the kind "I tried > to build Python on X, and the compiler gave me the error message > Y" are for comp.lang.python - these messages are really the of the > "I need help" kind. I had the same impression as Aahz: questions about how to use the existing distribution should go to c.l.p. Besides keeping pydev clear, someone once claimed (as I remember) that there are many people with experience building Python on various systems that read c.l.p but not pydev. (Still true? don't know!) On the otherhand, once that fails and someone thinks the codebase needs more #ifdefs, then it does become a pydev matter. And you saw right off that MSYS support might need just that. 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
[Python-Dev] Weekly Python Patch/Bug Summary
Patch / Bug Summary ___ Patches : 348 open ( +4) / 2879 closed ( +4) / 3227 total ( +8) Bugs: 898 open ( +1) / 5103 closed ( +9) / 6001 total (+10) RFE : 193 open ( +2) / 170 closed ( +0) / 363 total ( +2) New / Reopened Patches __ tarfile.py: ExFileObject's tell() is wrong after readline() (2005-06-30) http://python.org/sf/1230446 opened by Lars Gustäbel Patch for (Doc) #1168746 (2005-06-30) CLOSED http://python.org/sf/1230615 opened by Peter van Kampen Patch for (Doc) #1162912 (2005-07-03) CLOSED http://python.org/sf/1231890 opened by Peter van Kampen audioop - alaw encoding/decoding added, code updated (2005-07-01) http://python.org/sf/1231053 opened by Lars Immisch Add unicode for sys.argv, os.environ, os.system (2005-07-02) http://python.org/sf/1231336 opened by Neil Hodgson Typo fix in compiler/transformer.py (WalkerEror) (2005-07-02) CLOSED http://python.org/sf/1231538 opened by Adrien Di Mascio MS Windows - module search path fix (2005-07-04) http://python.org/sf/1232023 opened by K. Thananchayan PyOS_Readline (2005-07-04) http://python.org/sf/1232343 opened by Lisandro Dalcin Patches Closed __ Patch for (Doc) #1168746 (2005-06-30) http://python.org/sf/1230615 closed by birkenfeld Patch for (Doc) #1162912 (2005-07-03) http://python.org/sf/1231890 closed by birkenfeld Patch for (Doc) bug #1228904 (2005-06-29) http://python.org/sf/1229935 closed by birkenfeld Typo fix in compiler/transformer.py (WalkerEror) (2005-07-02) http://python.org/sf/1231538 closed by birkenfeld New / Reopened Bugs ___ Build failure (2005-06-30) http://python.org/sf/1230161 opened by L.M tokenize bug (2005-06-30) http://python.org/sf/1230484 opened by Eduardo Aguiar sys.excepthook doesn't work in threads (2005-06-30) http://python.org/sf/1230540 opened by Jonathan Ellis decimal module is no longer 2.3 compatible (2005-06-30) CLOSED http://python.org/sf/1230553 opened by Mike Orr ioctl has problem with -ive request codes (2005-07-01) http://python.org/sf/1231069 opened by Barry Alan Scott chr() returns ? when input > 127 in OS X (2005-07-02) http://python.org/sf/1231488 opened by Craig Howard typesseq-mutable lacks note on combined key/cmp usage (2005-03-14) CLOSED http://python.org/sf/1162912 reopened by birkenfeld OverflowError in time.utime() causes strange traceback (2005-07-04) CLOSED http://python.org/sf/1232517 opened by Joe Peterson Mistakes in online docs under "5.3 Pure Embedding" (2005-07-05) http://python.org/sf/1232768 opened by Matt Smart non-admin install may fail (win xp pro) (2005-07-05) http://python.org/sf/1232947 opened by pvrijlandt openssl-0.9.8 requires _ssl.mak change (2005-07-05) http://python.org/sf/1233049 opened by Alan Meyer Bugs Closed ___ Two requests to one file are not done in parallel (2005-06-25) http://python.org/sf/1227480 closed by jafo usage of type "char*" instead of "const char*" (2005-06-27) http://python.org/sf/1228053 closed by tjreedy decimal module is no longer 2.3 compatible (2005-06-30) http://python.org/sf/1230553 closed by rhettinger frame.f_exc_type,value,traceback (2005-03-23) http://python.org/sf/1168746 closed by birkenfeld __getattribute__ documentation error? (2005-05-19) http://python.org/sf/1204734 closed by birkenfeld weakref example broken (2005-06-28) http://python.org/sf/1228904 closed by birkenfeld typesseq-mutable lacks note on combined key/cmp usage (2005-03-14) http://python.org/sf/1162912 closed by birkenfeld typesseq-mutable lacks note on combined key/cmp usage (2005-03-14) http://python.org/sf/1162912 closed by birkenfeld random.py/os.urandom robustness (2005-04-06) http://python.org/sf/1177468 closed by birkenfeld OverflowError in time.utime() causes strange traceback (2005-07-05) http://python.org/sf/1232517 closed by mwh New / Reopened RFE __ platform.processor() could be smarter (2005-07-01) http://python.org/sf/1231081 opened by Stephan Springer Links to tutorials and howtos from references (2005-07-04) http://python.org/sf/1232073 opened by Michael Hoffman ___ 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] Triple-quoted strings and indentation
In general, I find triple-quoted strings to be very handy, particularly for standalone scripts. However, the fact that they have to be written in the left-hand column to avoid leading whitespace really grates, particularly when they're nested within a block or two -- it's a wart: try: options, args = getopt.getopt(sys.argv[1:], "cf:s") except getopt.GetoptError: print """Usage: dostuff Options: -c - blah blah -f - do stuff with file "filename" -s - more blah""" sys.exit(1) This really makes the code hard to read, as the indentation is all mixed up (visually). I have written a patch that changes the way triple-quoted strings are scanned so that leading whitespace is ignored in much the same way that pep 257 handles it for docstrings. Largely this was for a learning experience in hacking the parser, but it would be very nice IMO if something of this sort could be implemented in a future version of Python. To this end, I have sketched out a draft PEP (which was itself a good learning exercise in thinking out the issues of such a change). Should I post it here for discussion? Andrew ___ 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] Triple-quoted strings and indentation
On 7/5/05, Andrew Durdin <[EMAIL PROTECTED]> wrote:
> print """Usage: dostuff
>
> Options:
> -c - blah blah
> -f - do stuff with file "filename"
> -s - more blah"""
Isn't the standard idiom for this already:
import textwrap
...
print textwrap.dedent("""\
Usage: dostuff
Options:
-c - blah blah
-f - do stuff with file "filename"
-s - more blah""")
STeVe
--
You can wordify anything if you just verb it.
--- Bucky Katt, Get Fuzzy
___
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] Triple-quoted strings and indentation
"Andrew Durdin" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > In general, I find triple-quoted strings to be very handy, > particularly for standalone scripts. However, the fact that they have > to be written in the left-hand column to avoid leading whitespace > really grates, particularly when they're nested within a block or two > -- it's a wart: > >try: >options, args = getopt.getopt(sys.argv[1:], "cf:s") >except getopt.GetoptError: >print """Usage: dostuff > > Options: > -c - blah blah > -f - do stuff with file "filename" > -s - more blah""" > >sys.exit(1) > > This really makes the code hard to read, as the indentation is all > mixed up (visually). > > I have written a patch that changes the way triple-quoted strings are > scanned so that leading whitespace is ignored in much the same way > that pep 257 handles it for docstrings. Largely this was for a > learning experience in hacking the parser, but it would be very nice > IMO if something of this sort could be implemented in a future version > of Python. To this end, I have sketched out a draft PEP (which was > itself a good learning exercise in thinking out the issues of such a > change). Should I post it here for discussion? > > Andrew > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.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] Triple-quoted strings and indentation
"Andrew Durdin" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > In general, I find triple-quoted strings to be very handy, > particularly for standalone scripts. However, the fact that they have > to be written in the left-hand column to avoid leading whitespace > really grates, particularly when they're nested within a block or two At present I think I would do usage_text = '''\ text how I want it ''' perhaps in global context or at top of function and then >try: >options, args = getopt.getopt(sys.argv[1:], "cf:s") >except getopt.GetoptError: print usage_text I long ago found it advantageous to pull message texts from scattered locations into a central place where easier to find and edit. I also make program logic easier to read without a long block in the way. YMMV Doc strings, first meant for the code reader, need to be where they are. They also come before the code itself, so don't interfere. > -- it's a wart: That is rather extreme, and is definitely an opinion. > I have written a patch that changes the way triple-quoted strings are > scanned so that leading whitespace is ignored. And what if I want the leading whitespace left just the way I carefully put it? And what of existing code dependent on literals being as literal as they currently are? I think the soonest this could be considered is Python 3.0. 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
