Re: [Python-Dev] Oddity PEP 0 key
2009-05-02 07:34:15 Stephen J. Turnbull napisał(a): Barry Warsaw writes: On May 1, 2009, at 5:55 PM, Michael Foord wrote: P for Proposal (to replace Active Proposal)? Every active PEP is a proposal... +1 Maybe even s/Active/Proposed/g ? Shouldn't that be s/Active/Proposed/g No. From `info sed 'sed Programs' 'The s Command'`: The `s' Command === The syntax of the `s' (as in substitute) command is `s/REGEXP/REPLACEMENT/FLAGS'. The `/' characters may be uniformly replaced by any other single character within any given `s' command. The `/' character (or whatever other character is used in its stead) can appear in the REGEXP or REPLACEMENT only if it is preceded by a `\' character. ... The `s' command can be followed by zero or more of the following FLAGS: `g' Apply the replacement to _all_ matches to the REGEXP, not just the first. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] FWD: svn down?
- Forwarded message from \Martin v. L?wis\ mar...@v.loewis.de - Date: Sat, 02 May 2009 08:18:56 +0200 From: \Martin v. L?wis\ mar...@v.loewis.de To: Aahz a...@pythoncraft.com CC: pydot...@python.org Subject: Re: [Pydotorg] FWD: [Python-Dev] svn down? Benjamin Peterson reports being unable to ssh to dinsdale I have rebooted the machine; it seems now to be working again. Regards, Martin - End forwarded message - -- Aahz (a...@pythoncraft.com) * http://www.pythoncraft.com/ Typing is cheap. Thinking is expensive. --Roy Smith ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Oddity PEP 0 key
Alexander Belopolsky wrote: .. leaving just 'Rejected' and 'Replaced' to be disambiguated. 'X' or 'Z' for Rejected? Looks like a perfect start for a bikeshed discussion. :-) Are there Unicode codepoints for smilies? I'm thinking of :-) for 'Accepted' and :-( for 'Rejected'. :-) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Oddity PEP 0 key
MRAB wrote: Are there Unicode codepoints for smilies? I'm thinking of :-) for 'Accepted' and :-( for 'Rejected'. :-) Yes there are, but we'd need to set the font size to 'humongous' to see the smilies: ☹ ☺. In py3k: print(chr(0x2639), chr(0x263a)) In trunk: print(unichr(0x2639), unichr(0x263a)) attachment: smilies.png___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Oddity PEP 0 key
On Sat, 2 May 2009, MRAB wrote: Alexander Belopolsky wrote: .. leaving just 'Rejected' and 'Replaced' to be disambiguated. 'X' or 'Z' for Rejected? Looks like a perfect start for a bikeshed discussion. :-) Are there Unicode codepoints for smilies? I'm thinking of :-) for 'Accepted' and :-( for 'Rejected'. :-) U+2639 WHITE FROWNING FACE U+263A WHITE SMILING FACE Also, U+2694 CROSSED SWORDS for vehement discussion on mailing list, U+2696 SCALES for BDFL is considering, and U+2678 BLACK UNIVERSAL RECYCLING SYMBOL for proposal previously rejected is being re-proposed due to changed circumstances. For code don't forget great math operator symbols like U+2264 LESS-THAN OR EQUAL TO and U+222A UNION. But I doubt if anybody would want to bake in an absolute requirement for Unicode support in order to be able to read or write Python code. Isaac Morland CSCF Web Guru DC 2554C, x36650WWW Software Specialist ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] yield from?
2009/5/1 Guido van Rossum gu...@python.org: Alas, I haven't been following it either recently. Too bad, really, because before I left (now three weeks ago) it was already pretty close. We could perhaps even check in Greg's patch (which I tried and looked like a solid implementation of his proposal at the time) and finagle it for b2. One problem though is that Greg's code is based on 2.6... I don't believe the compiler has changed between 2.6 and the trunk, so a patch against the trunk would probably not be too hard. I volunteer to review it if it is produced. -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] multi-with statement
Hi, this is just a short notice that Mattias Brändström and I have finished a patch to implement the previously discussed and mostly warmly welcomed extension to with's syntax, allowing with A() as a, B() as b: to be written instead of with A() as a: with B() as b: This syntax was chosen (over with A(), B() as a, b:) because it has more syntactical similarity to the written-out version. Also, our current uses of as all have only one expression on the right. The patch implements it as a simple AST transformation, which guarantees semantic equivalence. It is at http://codereview.appspot.com/53094. If there is no strong opposition, I will commit it and port it to py3k before 3.1 enters beta stage. cheers, Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] multi-with statement
On Sat, May 2, 2009 at 9:01 PM, Georg Brandl g.bra...@gmx.net wrote: Hi, this is just a short notice that Mattias Brändström and I have finished a patch to implement the previously discussed and mostly warmly welcomed extension to with's syntax, allowing with A() as a, B() as b: to be written instead of with A() as a: with B() as b: This syntax was chosen (over with A(), B() as a, b:) because it has more syntactical similarity to the written-out version. Also, our current uses of as all have only one expression on the right. The patch implements it as a simple AST transformation, which guarantees semantic equivalence. It is at http://codereview.appspot.com/53094. If there is no strong opposition, I will commit it and port it to py3k before 3.1 enters beta stage. cheers, Georg I was hoping for the other syntax in order to be able to create a nested context in advance as a simple tuple: with A, B: pass context = A, B with context: pass (I.e. a tuple, or perhaps any iterable, would be a valid context manager.) With the syntax in the patch, I will still have to implement a custom nesting context manager to do this, which sort of defeats the purpose. Fredrik ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] multi-with statement
FWIW, I prefer Fredrik's wish too. Alex On Sat, May 2, 2009 at 12:26 PM, Fredrik Johansson fredrik.johans...@gmail.com wrote: On Sat, May 2, 2009 at 9:01 PM, Georg Brandl g.bra...@gmx.net wrote: Hi, this is just a short notice that Mattias Brändström and I have finished a patch to implement the previously discussed and mostly warmly welcomed extension to with's syntax, allowing with A() as a, B() as b: to be written instead of with A() as a: with B() as b: This syntax was chosen (over with A(), B() as a, b:) because it has more syntactical similarity to the written-out version. Also, our current uses of as all have only one expression on the right. The patch implements it as a simple AST transformation, which guarantees semantic equivalence. It is at http://codereview.appspot.com/53094. If there is no strong opposition, I will commit it and port it to py3k before 3.1 enters beta stage. cheers, Georg I was hoping for the other syntax in order to be able to create a nested context in advance as a simple tuple: with A, B: pass context = A, B with context: pass (I.e. a tuple, or perhaps any iterable, would be a valid context manager.) With the syntax in the patch, I will still have to implement a custom nesting context manager to do this, which sort of defeats the purpose. Fredrik ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/aleaxit%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] CVE-2008-5983 untrusted python modules search path
Hello, I don't think it has already posted to the list, apologies if it has. Some Linux tools and vendors have been hit by an alleged security hole where an embedded Python interpreter will prepend the current working directory to sys.path as soon as PySys_SetArgv() is called by the embedding application. This means, for example, that a Python file in the working directory can break plugins or extensions written for that application if the Python file happens to shadow another module. Regardless of whether this is a security hole or not, it certainly can make things disturbingly surprising when the situation arises. In the bug report (http://bugs.python.org/issue5753), I suggested we add a new function PySys_SetArgvEx() which would take an additional parameter telling whether to touch sys.path or not (in the same spirit as Py_InitializeEx() providing a more flexible API than Py_Initialize()). On the other hand, I don't think we can change the default behaviour of PySys_SetArgv(), since there are probably tools and applications relying on it (the obvious use case which comes to my mind is a third-party interactive interpreter). Any opinions? Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] multi-with statement
Fredrik Johansson schrieb: On Sat, May 2, 2009 at 9:01 PM, Georg Brandl g.bra...@gmx.net wrote: Hi, this is just a short notice that Mattias Brändström and I have finished a patch to implement the previously discussed and mostly warmly welcomed extension to with's syntax, allowing with A() as a, B() as b: to be written instead of with A() as a: with B() as b: I was hoping for the other syntax in order to be able to create a nested context in advance as a simple tuple: with A, B: pass context = A, B with context: pass (I.e. a tuple, or perhaps any iterable, would be a valid context manager.) I see; you want to construct your context manager programmatically and pass it to with without knowing what is in there. While this would be possible, we have to be aware that with this we would effectively change the context manager protocol, rather like the iterator protocol's __getitem__ alternate realization. This muddies the definition of a context manager. (The interesting thing is that you could already implement *that* version without any new syntactic support, by giving tuples an __enter__/__exit__ method pair.) With the syntax in the patch, I will still have to implement a custom nesting context manager to do this, which sort of defeats the purpose. Not really. Having an unknown number of stacked context managers is not the purpose -- for that, I'd still say a custom nesting context manager is better, because it is also more explicit when created not at the with site. (You could even write it as a tuple subclass, if you like the tuple interface.) Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Oddity PEP 0 key
Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com writes: 2009-05-02 07:34:15 Stephen J. Turnbull napisał(a): Barry Warsaw writes: Maybe even s/Active/Proposed/g ? Shouldn't that be s/Active/Proposed/g No. From `info sed 'sed Programs' 'The s Command'`: Stephen was, I suspect, feeling a little frisky when he wrote that, and attempted a joke (the shortcut “g” is often used in this forum for “insert a silly grin here”). Knowing him, I grade the joke “4 out of 10, could do better”. -- \ “Think for yourselves and let others enjoy the privilege to do | `\ so too.” —Voltaire, _Essay On Tolerance_ | _o__) | Ben Finney pgpFAljzQLkSS.pgp Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 383 and GUI libraries
[cross-posting to python-dev and tahoe-dev] On Fri, May 1, 2009 at 8:12 PM, James Y Knight f...@fuhm.net wrote: If I were designing a new system such as this, I'd probably just go for utf8b *always*. Ah, this would be a very tempting possibility -- abandon all unix users who are slow to embrace our utf-8b future! However, it is moot because Tahoe is not a new system. It is currently at v1.4.1, has a strong policy of backwards-compatibility, and already has lots of data, lots of users, and programmers building on top of it. It currently uses utf-8 for its internal storage (note: nothing to do with reading or writing files from external sources -- only for storing filenames in the decentralized storage system which is accessed by Tahoe clients), and we can't start putting non-utf-8-valid sequences in the filename slot because other Tahoe clients would then get a UnicodeDecodeError exception when trying to read those directories. We *could* create a new metadata entry to hold things other than utf-8. Current Tahoe clients would never look at that entry (the metadata is a JSON-serialized dictionary, so we can add a new key name into it without disturbing the existing clients), but future Tahoe clients could look for that new key. That is where it is possible that future versions of Tahoe might be able to benefit from utf-8b or PEP 383, although what PEP 383 offers for this use case remains unclear to me. But if you don't do that, then, I still don't see what purpose your requirements serve. If I have two systems: one with a UTF-8 locale, and one with a Latin-1 locale, why should transmitting filenames from system 1 to system 2 through tahoe preserve the raw bytes, but doing the reverse *not* preserve the raw bytes? (all byte-sequences are valid in latin-1, remember, so they'll all decode into unicode without error, and then be reencoded in utf-8...). This seems rather a useless behavior to me. I see I'm not explaining the Tahoe requirements clearly. It's probably that I'm not understanding them clearly myself. Hopefully the following will help. There are two different things stored in Tahoe for each directory entry: the filename and the metadata. Suppose you have run tahoe cp -r myfiles/ tahoe: on a Linux system and then you inspect the files in the Tahoe filesystem, such as by examining the web interface [1] or by running tahoe ls, either of which you could do either from the same machine where you ran tahoe cp or from a different machine (which could be using any operating system). We have the following requirements about what ends up in your Tahoe directory after that cp -r. Requirement 1 (unicode): Each filename that you see needs to be valid unicode (it is stored internally in utf-8). This eliminates utf-8b and PEP 383 from being directly applicable to the filename part, although perhaps they could be useful for the metadata part (about which more below). Requirement 2 (faithful if unicode): For each filename (byte string) in your myfiles directory, if that bytestring is the valid encoding of some string in your stated locale, then the resulting filename in Tahoe is that (unicode) string. Nobody ever doesn't want this, right? Well, maybe some people don't want this sometimes, because it could be that the locale was wrong for this byte string and the resulting successfully-decoded unicode name is gibberish. This is especially acute if the locale is an 8-bit encoding such as latin-1 or windows-1252. However, what's the alternative? Guessing that their locale shouldn't be set to latin-1 and instead decoding their bytes some other way? It seems like we're not going to do better than requirement 2 (faithful if unicode). Requirement 3 (no file left behind): For each filename (byte string) in your myfiles directory, whether or not that byte string is the valid encoding of anything in your stated locale, then that file will be added into the Tahoe filesystem under *some* name (a good candidate would be mojibake, e.g. decode the bytes with latin-1, but that is not the only possibility). I have heard some developers say that they don't want to support this requirement and would rather tell the users to fix their filenames before they can back up or share those files through Tahoe. On the other hand, users have said that they require this and they are not going to go mucking about with all their filenames just so that they can use my backup and filesharing tool. Now already we can say that these three requirements mean that there can be collisions -- for example a directory could have two entries, one of which is not a valid encoding in the locale, and whatever unicode string we invent to name it with in order to satisfy requirements 3 (no file left behind) and 1 (unicode) might happen to be the same as the (correctly-encoded) name of the other file. Therefore these three requirements imply that we have to detect such collisions and deal with them somehow. (Thanks to Martin v. Löwis for
