Mailman 3 May 2007 - Python-ideas

Alternate quote delimiters
by Ron Adam 13 May '07

13 May '07

While watching the various issues about raw strings and quotes being discussed, I decided look into other ways to resolve string delimiter collisions that might also improve pythons string handling in general. And I'd figure I'd let it get shot full of holes here first. ;-) Here's a nice overview of the issue with various examples. http://en.wikipedia.org/wiki/String_literal *Note: The wiki python raw string example has a trailing backslash which would cause an error. r"The Windows path is C:\Foo\Bar\Baz\" In the case of raw strings, the escaped quotes are only needed in order for tokenize.c to locate the end of the string. The back slashes remain in the string. The end of the string is the first unescaped quote of the same type as the starting quote. >>> s = r"\"Hello World\"" >>> print s \"Hello World\" This allows you to enter, back-slash + quote, pairs into a string, but ... - This doesn't help in entering only quotes. You still need to either use a different quotes than what is in the string or not use raw strings. - A minor side effect is that you can't have a raw string end with a single slash as in the incorrect wiki example above. Other languages which use escape characters in raw strings have the same issue. - If you have a long string with multiple quotes as you can in regular expressions the increased number of \ characters can make the regular expression more difficult to read and can add up to be more characters than needed. - Another minor issue I've found is doctest that do test on quoted strings may have multiple nested doc strings which may require careful selection of quote characters. The problem arises because the start and end delimiters are the same. The start of the nested string ends the top level string. The current solution is to pick different quote characters or escape quote characters in the nested strings. So how about a multiple quoting solution? The examples of this in the wiki page are of the form... qq^I said, "Can you hear me?"^ qq@I said, "Can you hear me?"@ qq§I said, "Can you hear me?"§ But that doesn't fit well with pythons use of quotes. But a variation of this would. Add a 'q' string prefix similar to the 'u' and 'r' prefix's that takes the first character inside the quotes as an additional delimiter. Then ending quote will then need to have that same character proceeding it. q"^I said, "Can you hear me?"^" q"""|I said, "Can you hear me?"|""" The vertical bar is part of the quote here, not part of the string. rq"^The Windows path is C:\Foo\Bar\Baz\^" This example will work as expected. Because the beginning and ending of the strings are not identical, it's possible that they can allow nesting. rq"""^ rq"""^ This is a nested string. ^""" """ Another nested string. """ ^""" The most useful feature of this would be in temporarily commenting out large blocks of python code. Currently this doesn't work well if the block that contain triple quoted doc strings. Another option might be to designate certain quote delimiters for special purposes. Dedented strings. q"""< This is a Dedented Paragraph. <""" Commented out source code. q"""# def foo(bar): """ A bar checker. """ return bar is True #""" ReST formatted strings. rq""": Bullet lists: - This is item 1 - This is item 2 - Bullets are "-", "*" or "+". Continuing text must be aligned after the bullet and whitespace. Note that a blank line is required before the first item and after the last, but is optional between items. :""" This use would require some way to preserve it's quoting type so it can later be used to render the text. (Any ideas?) Cheers, Ron

5 6

Re: [Python-ideas] parser in stdlib
by Aaron Brady 13 May '07

13 May '07

> -----Original Message----- > From: george.sakkis(a)gmail.com [mailto:george.sakkis@gmail.com] On Behalf > Of George Sakkis > Sent: Thursday, May 10, 2007 10:36 PM > To: Aaron Brady > Subject: Re: [Python-ideas] parser in stdlib > > On 5/10/07, Aaron Brady <castironpi(a)comcast.net> wrote: > > > Huge bag of worms, I see now. I was tinkering for hobby Python use. I > > hadn't proposed a syntax change, not there yet. I was wanting to > intercept > > parser somewhere after it's started parsing source, but before it gets > to > > the rules. The particular change I'm tinkering with was replacing an > equal > > sign with a natural word. > > > > 1, 2 to a, c > > -and- > > to a, c 1, 2 > > > > map to: > > > > a, c = 1, 2 > > A perfect example of why programmable syntax is out of question for > Python. > > George Hence the quote. First thing I said was, "...it might not be advisable either, subject to abuse, per GvR...." But that doesn't preclude exposing `parser'. It is the extent of my question, no more. Can we expose the module? Do I take the powers that be to have said, "No, that would open too many doors and give the programmers too much freedom?" If so, that's straight-forward and honest, and presents the next problem for solutions. Can we expose that and still keep programs up to standard?

7 10

Re: [Python-ideas] the future of the GIL
by Aahz 12 May '07

12 May '07

[excessive quoting ahead to move to python-ideas from python-3000, please trim when you followup] On Wed, May 09, 2007, Talin wrote: > Greg Ewing wrote: >> Giovanni Bajo wrote: >>> >>> using multiple processes cause some >>> headaches with frozen distributions (PyInstaller, py2exe, etc.), >>> like those usually found on Windows, specifically because Windows >>> does not have fork(). >> >> Isn't that just a problem with Windows generally? I don't >> see what the method of packaging has to do with it. >> >> Also, I've seen it suggested that there may actually be >> a way of doing something equivalent to a fork in Windows, >> even though it doesn't have a fork() system call as such. >> Does anyone know more about this? > > I also wonder about embedded systems and game consoles. I don't know how > many embedded microprocessors support fork(), but I know that modern > consoles such as PS/3 and Xbox do not, since they have no support for > virtual memory at all. > > Also remember that the PS/3 is supposed to be one of the poster children > for multiprocessing -- the whole 'cell processor' thing. You can't write > an efficient game on the PS/3 unless it uses multiple processors. > > Admittedly, not many current console-based games use Python, but that > need not always be the case in the future, and a number of PC-based > games are using it already. > > This much I agree: There's no point in talking about supporting multiple > processors using threads as long as we're living in a refcounting world. > > Thought experiment: Suppose you were writing and brand-new dynamic > language today, designed to work efficiently on multi-processor systems. > Forget all of Python's legacy implementation details such as GILs and > refcounts and such. What would it look like, and how well would it > perform? (And I don't mean purely functional languages a la Erlang.) > > For example, in a language that is based on continuations at a very deep > level, there need not be any "global interpreter" at all. Each separate > flow of execution is merely a pointer to a call frame, the evaluation of > which produces a pointer to another call frame (or perhaps the same > one). Yes, there would still be some shared state that would have to be > managed, but I wouldn't think that the performance penalty of managing > that would be horrible. One of the primary goals of Python was/is to be an easy glue language for C libraries. How do you propose to handle the issue that many C libraries use global state? -- Aahz (aahz(a)pythoncraft.com) <*> http://www.pythoncraft.com/ "Look, it's your affair if you want to play with five people, but don't go calling it doubles." --John Cleese anticipates Usenet

1 0

Re: [Python-ideas] parameter omit
by Jan Kanis 12 May '07

12 May '07

On Fri, 11 May 2007 20:09:39 +0200, Aaron Brady <castironpi(a)comcast.net> wrote: >> -----Original Message----- >> From: Jan Kanis [mailto:jan.kanis@phil.uu.nl] >> Sent: Friday, May 11, 2007 6:59 AM >> >> In short, any new addition has to have a *lot* of utility to be >> acceptable, or else it wil lead to the way of the Perl side. > > Agreed entirely. You mean, like this? > > Who brings up the manual? Good. Document something. It isn't really about the manual, and I think I meant something like 'language reference' (sorry, not native English). It's about the complexity of the language. The size of the language reference can be seen as a more or less objective way to measure language complexity. Your proposal adds a little bit more complexity, and most people here agree that the benefits, which are there, are not worth it.

1 0

Re: [Python-ideas] parameter omit
by Steven Bethard 11 May '07

11 May '07

Steven Bethard [mailto:steven.bethard@gmail.com] > Can you show me code that would make your new "morpheme" work? All > the implementations I can imagine involve making it some sort of > special keyword. On 5/11/07, Aaron Brady <castironpi(a)comcast.net> wrote: > Nope, routine object. I defined it earlier: > > paramdefault= object() Yes, but how is it going to *work*? Say I wrote the function:: def foo(bar=1, baz=2): print bar, baz Now if I call that like:: foo(bar=paramdefault, baz=paramdefault) I'm going to see something like:: <object object at 0x009A0468> <object object at 0x009A0468> Is that really what you want? I thought you wanted this to work for all functions... STeve -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy

3 2

Re: [Python-ideas] parameter omit
by Steven Bethard 11 May '07

11 May '07

On 5/11/07, Aaron Brady <castironpi(a)comcast.net> wrote: > > -----Original Message----- > > From: Steven Bethard [mailto:steven.bethard@gmail.com] > > Sent: Friday, May 11, 2007 1:50 AM > > > > On 5/11/07, Aaron Brady <castironpi(a)comcast.net> wrote: > > > Take a shot at this one. > > > > > > class WebRetrieveElement: > > > def netretrieveOld( self ): > > > if hasattr( self,'hook' ) and self.filename: > > > urlretrieve( self.url, self.filename, self.hook > > ) > > > elif hashook: > > > urlretrieve( self.url, reporthook= self.hook ) > > > else: > > > urlretrieve( self.url, self.filename ) > > > > def netretrieve(self): > > kwargs = {} > > if self.filename: > > kwargs['filename'] = self.filename > > if hasattr(self, 'hook'): > > kwargs['reporthook'] = self.hook > > urlretrieve(self.url, **kwargs) > > Right. That's the alternative, -as- I keep bringing up. > > Now let's compare, and judge if X is worth Y. > > My solution, 3 lines. Yours, 6. If you really care about lines and characters, you can write:: k = {} if self.filename: k['filename'] = self.filename if hasattr(self, 'hook'): k['reporthook'] = self.hook urlretrieve(self.url, **k) That's 4 lines, 132 characters, compared to your 3 lines, 133 characters. But the fact that you're drawing the "lets count lines of code" card suggests that there's no point discussing this any further. Good luck with your proposal. STeVe -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy

2 1

Re: [Python-ideas] parameter omit
by Steven Bethard 11 May '07

11 May '07

On 5/11/07, Aaron Brady <castironpi(a)comcast.net> wrote: > Take a shot at this one. > > class WebRetrieveElement: > def netretrieveOld( self ): > if hasattr( self,'hook' ) and self.filename: > urlretrieve( self.url, self.filename, self.hook ) > elif hashook: > urlretrieve( self.url, reporthook= self.hook ) > else: > urlretrieve( self.url, self.filename ) def netretrieve(self): kwargs = {} if self.filename: kwargs['filename'] = self.filename if hasattr(self, 'hook'): kwargs['reporthook'] = self.hook urlretrieve(self.url, **kwargs) STeVe -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy

2 1

Re: [Python-ideas] parameter omit
by Josiah Carlson 11 May '07

11 May '07

Adding python-ideas in as a CC, because I'm a jerk. "Aaron Brady" <castironpi(a)comcast.net> wrote: > On a personal note, Josiah, you strike first. "Pestering" is pejorative. > My statements do not merit it. Keep it off the newsgroup. You insult me > without grounds; and in fact -after- my abilities are demonstrated. Quote > me instead, as I do, to disagree. > > The discussion reads as follows. "Better except that it has no support." > So support it. Who's to blame: myself, or those with pull? > > I have a good idea by newsgroup standards. You reveal bias to summarily > dismiss. I urge you to reconsider; practice diplomacy here. Post what you want. If people aren't offering +1 or -1, it could be for any number of reasons; from being busy (it is in the middle of the week), to just not caring enough either way, believing that their opinions and interests are already being expressed, etc. But when you post something, then 24 hours and 40 minutes later you ask, "Also, any follow-up on this? (I posted at top.)" at the bottom of a 95 line quote of your own last post without cutting out the unimportant parts, it is pestering, and a very low signal to noise ratio 1:95. Never mind that you only recently seemed to learn that we don't top post in Python mailing lists, but you still haven't realized that we trim unimportant parts of quoted posts. Had you top posted or failed to trim either in python-list (or the equivalent comp.lang.python), any number of people would have told you as much. But hey, you are being such the good usenet poster, you couldn't have made a mistake, of course not. Get over yourself. With that said, I don't particularly like the addition of syntax for something that can already be done other ways (TOOWTDI), or the addition of a new builtin to signal something that I've never heard *anyone* ask about before. Really, the only *reasonable* name is 'default', which is used at least 146 times in the Python standard library (according to my regular expression of default\s*=), and I'm sure thousands of times in 3rd party code. It would necessitate a huge change for a feature that no one (but you) as asked for so that you can use... foo(a, b=default, c=1234) foo(a, b=253463, c=default) rather than... foo(a, c=1234) foo(a, b=253463) Personally, I find the latter more consistant (only pass arguments that you care to change). If you don't, that's fine. The burdon of proof isn't on me, or anyone else in python-ideas to prove to you that your idea sucks; it's on you to prove to everyone else that your idea *doesn't* suck. Good luck on that. Local jerk, - Josiah

3 6

Re: [Python-ideas] parameter omit
by Talin 11 May '07

11 May '07

Aaron Brady wrote: >>> Specific and concise. Clearly better, by all measures I read. >> With PEP 3102 in place you don't even need the **kwargs: >> >> http://www.python.org/dev/peps/pep-3102/ >> >> -- Talin > > I'm not adding restrictions. I'm simplifying. The subject solution is > general. Less code in all cases, meaning still as clear or clearer. Non-sequitur? How does that relate to what I said? Let me state in different words what others have already stated: There are already ways to accomplish most what you are trying to do. In Python, any argument will have its default value if you omit it from the argument list when calling the function. There's no need to explicitly tell it to use the default value, it just does this naturally. Now, the only case where this might be a problem is a fairly rare and odd case where you are specifying arguments positionally and not by keyword, where you want to specify the value of argument N+1 but want argument N to be its default. But the language should not make a special cases to support this particular case, for 3 reasons: 1) The case is rare. 2) There are easy ways around it: Simply supply the value of argument N+1 by keyword instead of by position. 3) If your function has lots of positional arguments, each of which has a different meaning, then your function probably needs to be refactored anyway. Using keywords is much safer in such cases, and if you use keywords, then the whole problem you raise goes away. -- Talin

2 1

Re: [Python-ideas] parameter omit
by Josiah Carlson 11 May '07

11 May '07

"Aaron Brady" <castironpi(a)comcast.net> wrote: > Also, any follow-up on this? (I posted at top.) I don't like it. The current calling semantics are sufficient for the vast majority of cases. For those cases that are not covered by the current calling semantics, there is a PEP for allowing variations in optional arguments, keyword arguments, etc. I can't remember the number, but the PEP index has it. As for signaling "use the default", there is a standard method: omit the argument. If you want the argument to always be required to be a keyword argument, you can use... def foo(arg1, **kwargs): arg2 = kwargs.get('arg2', 1.2325) arg3 = kwargs.get('arg3', 'hello') ... - Josiah

3 3