[Python-Dev] Reminder: Python 3.4 feature freeze in a week

2013-11-16 Thread Larry Hastings
We're on schedule to tag Python 3.4 Beta 1 next Saturday. And when that happens we go into feature freeze on Python trunk; no new features will be accepted in trunk until we branch the 3.4 release branch next February. Time to get those checkins in folks. Last call, everyone, //arry/

Re: [Python-Dev] Add transform() and untranform() methods

2013-11-16 Thread Nick Coghlan
On 16 Nov 2013 10:47, Victor Stinner victor.stin...@gmail.com wrote: 2013/11/16 Nick Coghlan ncogh...@gmail.com: To address Serhiy's security concerns with the compression codecs (which are technically independent of the question of restoring the aliases), I also plan to document how to

Re: [Python-Dev] The pysandbox project is broken

2013-11-16 Thread Nick Coghlan
On 16 Nov 2013 11:35, Christian Tismer tis...@stackless.com wrote: IOW: Do we really need a full abstraction, embedded in a virtual OS, or is there already a compromise that suits 98 percent of the common needs? I think as a starter, categorizing the expectations of some measure of 'secure

Re: [Python-Dev] Add transform() and untranform() methods

2013-11-16 Thread Victor Stinner
Why not using str type for str and str subtypes, and bytes type for bytes and bytes-like object (bytearray, memoryview)? I don't think that we need an ABC here. Victor Le 16 nov. 2013 10:44, Nick Coghlan ncogh...@gmail.com a écrit : On 16 Nov 2013 10:47, Victor Stinner victor.stin...@gmail.com

Re: [Python-Dev] The pysandbox project is broken

2013-11-16 Thread Maciej Fijalkowski
On Sat, Nov 16, 2013 at 12:12 PM, Nick Coghlan ncogh...@gmail.com wrote: On 16 Nov 2013 11:35, Christian Tismer tis...@stackless.com wrote: IOW: Do we really need a full abstraction, embedded in a virtual OS, or is there already a compromise that suits 98 percent of the common needs? I think

Re: [Python-Dev] The pysandbox project is broken

2013-11-16 Thread Maciej Fijalkowski
On Fri, Nov 15, 2013 at 6:56 PM, Trent Nelson tr...@snakebite.org wrote: On Tue, Nov 12, 2013 at 01:16:55PM -0800, Victor Stinner wrote: pysandbox cannot be used in practice To protect the untrusted namespace, pysandbox installs a lot of different

Re: [Python-Dev] Add transform() and untranform() methods

2013-11-16 Thread Nick Coghlan
On 16 November 2013 20:45, Victor Stinner victor.stin...@gmail.com wrote: Why not using str type for str and str subtypes, and bytes type for bytes and bytes-like object (bytearray, memoryview)? I don't think that we need an ABC here. We'd only need an ABC if info was added for supported input

Re: [Python-Dev] Add transform() and untranform() methods

2013-11-16 Thread M.-A. Lemburg
On 16.11.2013 01:47, Victor Stinner wrote: Adding transform()/untransform() method to bytes and str is a non trivial change and not everybody likes them. Anyway, it's too late for Python 3.4. Just to clarify: I still like the idea of adding those methods. I just don't see what this addition

Re: [Python-Dev] Add transform() and untranform() methods

2013-11-16 Thread Antoine Pitrou
On Sat, 16 Nov 2013 19:44:51 +1000 Nick Coghlan ncogh...@gmail.com wrote: Aye, that was my conclusion (hence my proposal on issue 7475 back in April). Can I take that observation as a +1 for restoring the aliases as well? I see no harm in restoring the aliases personally, so +1 from me.

Re: [Python-Dev] Add transform() and untranform() methods

2013-11-16 Thread Nick Coghlan
On 16 November 2013 21:38, Nick Coghlan ncogh...@gmail.com wrote: On 16 November 2013 20:45, Victor Stinner victor.stin...@gmail.com wrote: Why not using str type for str and str subtypes, and bytes type for bytes and bytes-like object (bytearray, memoryview)? I don't think that we need an ABC

Re: [Python-Dev] Add transform() and untranform() methods

2013-11-16 Thread Nick Coghlan
On 16 November 2013 21:49, M.-A. Lemburg m...@egenix.com wrote: On 16.11.2013 01:47, Victor Stinner wrote: Adding transform()/untransform() method to bytes and str is a non trivial change and not everybody likes them. Anyway, it's too late for Python 3.4. Just to clarify: I still like the

Re: [Python-Dev] (#19562) Asserts in Python stdlib code (datetime.py)

2013-11-16 Thread Maciej Fijalkowski
On Sat, Nov 16, 2013 at 3:51 AM, Terry Reedy tjre...@udel.edu wrote: http://bugs.python.org/issue19562 propose to change the first assert in Lib/datetime.py assert 1 = month = 12, month to assert 1 = month = 12,'month must be in 1..12' to match the next two asserts out of the *53* in the

Re: [Python-Dev] (#19562) Asserts in Python stdlib code (datetime.py)

2013-11-16 Thread Nick Coghlan
On 16 November 2013 23:17, Maciej Fijalkowski fij...@gmail.com wrote: On Sat, Nov 16, 2013 at 3:51 AM, Terry Reedy tjre...@udel.edu wrote: If user input can trigger an assert, then the code should raise a normal exception that will not disappear with -OO. May I assert that -OO should instead

Re: [Python-Dev] (#19562) Asserts in Python stdlib code (datetime.py)

2013-11-16 Thread Maciej Fijalkowski
On Sat, Nov 16, 2013 at 5:09 PM, Nick Coghlan ncogh...@gmail.com wrote: On 16 November 2013 23:17, Maciej Fijalkowski fij...@gmail.com wrote: On Sat, Nov 16, 2013 at 3:51 AM, Terry Reedy tjre...@udel.edu wrote: If user input can trigger an assert, then the code should raise a normal exception

Re: [Python-Dev] (#19562) Asserts in Python stdlib code (datetime.py)

2013-11-16 Thread Maciej Fijalkowski
On Sat, Nov 16, 2013 at 5:33 PM, Maciej Fijalkowski fij...@gmail.com wrote: On Sat, Nov 16, 2013 at 5:09 PM, Nick Coghlan ncogh...@gmail.com wrote: On 16 November 2013 23:17, Maciej Fijalkowski fij...@gmail.com wrote: On Sat, Nov 16, 2013 at 3:51 AM, Terry Reedy tjre...@udel.edu wrote: If user

Re: [Python-Dev] (#19562) Asserts in Python stdlib code (datetime.py)

2013-11-16 Thread Antoine Pitrou
On Sat, 16 Nov 2013 17:34:15 +0200 Maciej Fijalkowski fij...@gmail.com wrote: On Sat, Nov 16, 2013 at 5:33 PM, Maciej Fijalkowski fij...@gmail.com wrote: On Sat, Nov 16, 2013 at 5:09 PM, Nick Coghlan ncogh...@gmail.com wrote: On 16 November 2013 23:17, Maciej Fijalkowski fij...@gmail.com

Re: [Python-Dev] (#19562) Asserts in Python stdlib code (datetime.py)

2013-11-16 Thread Nick Coghlan
On 17 November 2013 01:34, Maciej Fijalkowski fij...@gmail.com wrote: On Sat, Nov 16, 2013 at 5:33 PM, Maciej Fijalkowski fij...@gmail.com wrote: On Sat, Nov 16, 2013 at 5:09 PM, Nick Coghlan ncogh...@gmail.com wrote: On 16 November 2013 23:17, Maciej Fijalkowski fij...@gmail.com wrote: On

Re: [Python-Dev] (#19562) Asserts in Python stdlib code (datetime.py)

2013-11-16 Thread Nick Coghlan
On 17 November 2013 01:46, Antoine Pitrou solip...@pitrou.net wrote: I agree that conflating the two doesn't help the discussion. While removing docstrings may be beneficial on memory-constrained devices, I can't remember a single situation where I've wanted to remove asserts on a production

Re: [Python-Dev] (#19562) Asserts in Python stdlib code (datetime.py)

2013-11-16 Thread Donald Stufft
Personally I think that none of the -O* should be removing asserts. It feels like a foot gun to me. I’ve seen more than one codebase that would be completely broken under -O* because they used asserts without even knowing -O* existed. Removing __debug__ blogs and doc strings I don’t think is as

Re: [Python-Dev] (#19562) Asserts in Python stdlib code (datetime.py)

2013-11-16 Thread Antoine Pitrou
On Sat, 16 Nov 2013 11:16:48 -0500 Donald Stufft don...@stufft.io wrote: Personally I think that none of the -O* should be removing asserts. It feels like a foot gun to me. I’ve seen more than one codebase that would be completely broken under -O* because they used asserts without even knowing

Re: [Python-Dev] (#19562) Asserts in Python stdlib code (datetime.py)

2013-11-16 Thread Gregory Salvan
Hi, Some languages (C#, java) do the reverse by removing assertions if we don't tell compiler to keep them. Personnaly, I find this solution relatively accurate as I expect assertions not to be run in production. It would be painful to have this behaviour in python now, but I hope we'll keep a

Re: [Python-Dev] The pysandbox project is broken

2013-11-16 Thread Trent Nelson
On Sat, Nov 16, 2013 at 02:53:22AM -0800, Maciej Fijalkowski wrote: On Fri, Nov 15, 2013 at 6:56 PM, Trent Nelson tr...@snakebite.org wrote: On Tue, Nov 12, 2013 at 01:16:55PM -0800, Victor Stinner wrote: pysandbox cannot be used in practice To

[Python-Dev] What's the story on Py_FrozenMain?

2013-11-16 Thread Eric Snow
While looking at something unrelated, I happened to peek at Python/frozenmain.c and found Py_FrozenMain(). I kind of get the idea of it, but am curious what motivated the addition and who might be using it. The function is not documented and doesn't have much explanation. I'm guessing that not

Re: [Python-Dev] What's the story on Py_FrozenMain?

2013-11-16 Thread M.-A. Lemburg
On 16.11.2013 18:48, Eric Snow wrote: While looking at something unrelated, I happened to peek at Python/frozenmain.c and found Py_FrozenMain(). I kind of get the idea of it, but am curious what motivated the addition and who might be using it. The function is not documented and doesn't have

Re: [Python-Dev] What's the story on Py_FrozenMain?

2013-11-16 Thread Guido van Rossum
This is very old DNA. The persistent user request was a way to bundle up a Python program as a single executable file that could be sent to a friend or colleague and run without first having to install Python. If you Google for python freeze you'll still see old references to it. IIRC I did the

Re: [Python-Dev] What's the story on Py_FrozenMain?

2013-11-16 Thread Eric Snow
On Sat, Nov 16, 2013 at 10:55 AM, M.-A. Lemburg m...@egenix.com wrote: It's used as main()-function for frozen Python interpreters. See eGenix PyRun as an example and the freeze tool in Tools/freeze/ for the implementation that uses this API: http://www.egenix.com/products/python/PyRun/ On

[Python-Dev] Accepting PEP 3154 for 3.4?

2013-11-16 Thread Antoine Pitrou
Hello, Alexandre Vassalotti (thanks a lot!) has recently finalized his work on the PEP 3154 implementation - pickle protocol 4. I think it would be good to get the PEP and the implementation accepted for 3.4. As far as I can say, this has been a low-controvery proposal, and it brings fairly

[Python-Dev] PyParallel: alternate async I/O and GIL removal

2013-11-16 Thread Trent Nelson
Hi folks, Video of the presentation I gave last weekend at PyData NYC regarding PyParallel just went live: https://vimeo.com/79539317 Slides are here: https://speakerdeck.com/trent/pyparallel-how-we-removed-the-gil-and-exploited-all-cores-1 The work was driven by the async I/O

[Python-Dev] Mixed up core/module source file locations in CPython

2013-11-16 Thread Eric Snow
If you look at the Python and Modules directories in the cpython repo, you'll find modules in Python/ and core files (like python.c and main.c) in Modules/. (It's like parking on a driveway and driving on a parkway. wink) It's not that big a deal and not that hard to figure out (so I'm fine with

Re: [Python-Dev] Accepting PEP 3154 for 3.4?

2013-11-16 Thread Eric Snow
On Sat, Nov 16, 2013 at 11:15 AM, Antoine Pitrou solip...@pitrou.net wrote: Hello, Alexandre Vassalotti (thanks a lot!) has recently finalized his work on the PEP 3154 implementation - pickle protocol 4. I think it would be good to get the PEP and the implementation accepted for 3.4. +1

[Python-Dev] NTPath or WindowsPath?

2013-11-16 Thread Antoine Pitrou
Hello, In a (private) discussion about PEP 428 and pathlib, Guido proposed that maybe NTPath should be renamed to WindowsPath, since the name is more likely to stay relevant in the middle term. What do you think? Regards Antoine. ___ Python-Dev

Re: [Python-Dev] NTPath or WindowsPath?

2013-11-16 Thread Benjamin Peterson
2013/11/16 Antoine Pitrou solip...@pitrou.net: Hello, In a (private) discussion about PEP 428 and pathlib, Guido proposed that maybe NTPath should be renamed to WindowsPath, since the name is more likely to stay relevant in the middle term. What do you think? I agree with Guido. --

Re: [Python-Dev] NTPath or WindowsPath?

2013-11-16 Thread Steve Dower
Sounds good to me. NT is already an obsolete term - Win32 would be more accurate - but WinRT hasn't changed the path format, so WindowsPath will be accurate for the foreseeable future. Cheers, Steve Top posted from my Windows Phone From: Benjamin

Re: [Python-Dev] NTPath or WindowsPath?

2013-11-16 Thread Serhiy Storchaka
16.11.13 21:15, Antoine Pitrou написав(ла): In a (private) discussion about PEP 428 and pathlib, Guido proposed that maybe NTPath should be renamed to WindowsPath, since the name is more likely to stay relevant in the middle term. What do you think? What about nturl2path, os.name,

Re: [Python-Dev] Mixed up core/module source file locations in CPython

2013-11-16 Thread Brett Cannon
On Sat, Nov 16, 2013 at 1:40 PM, Eric Snow ericsnowcurren...@gmail.comwrote: If you look at the Python and Modules directories in the cpython repo, you'll find modules in Python/ and core files (like python.c and main.c) in Modules/. (It's like parking on a driveway and driving on a parkway.

Re: [Python-Dev] Accepting PEP 3154 for 3.4?

2013-11-16 Thread Nick Coghlan
On 17 Nov 2013 04:45, Eric Snow ericsnowcurren...@gmail.com wrote: On Sat, Nov 16, 2013 at 11:15 AM, Antoine Pitrou solip...@pitrou.net wrote: Hello, Alexandre Vassalotti (thanks a lot!) has recently finalized his work on the PEP 3154 implementation - pickle protocol 4. I think it

Re: [Python-Dev] Mixed up core/module source file locations in CPython

2013-11-16 Thread Nick Coghlan
On 17 Nov 2013 09:48, Brett Cannon br...@python.org wrote: I personally think it would be a good idea to re-arrange the files to make things more beginner-friendly. I believe Nick was also talking about renaming directories, etc. at some point. Yeah, the main ones I am interested in are a

Re: [Python-Dev] PyParallel: alternate async I/O and GIL removal

2013-11-16 Thread Guido van Rossum
Trent, I watched your video and read your slides. (Does the word motormouth mean anything to you? :-) Clearly your work isn't ready for python-dev -- it is just too speculative. I've moved python-dev to BCC and added python-ideas. It possibly doesn't even belong on python-ideas -- if you are

Re: [Python-Dev] Accepting PEP 3154 for 3.4?

2013-11-16 Thread Guido van Rossum
On Sat, Nov 16, 2013 at 10:15 AM, Antoine Pitrou solip...@pitrou.netwrote: Alexandre Vassalotti (thanks a lot!) has recently finalized his work on the PEP 3154 implementation - pickle protocol 4. I think it would be good to get the PEP and the implementation accepted for 3.4. As far as I can

Re: [Python-Dev] PyParallel: alternate async I/O and GIL removal

2013-11-16 Thread Terry Reedy
On 11/16/2013 8:39 PM, Guido van Rossum wrote: Trent, I watched your video and read your slides. I only read the slides. (Does the word motormouth mean anything to you? :-) The extra background (and repetition) was helpful to me in filling in things, especially about Windows, that I could

Re: [Python-Dev] (#19562) Asserts in Python stdlib code (datetime.py)

2013-11-16 Thread Steven D'Aprano
On Sat, Nov 16, 2013 at 04:46:00PM +0100, Antoine Pitrou wrote: I agree that conflating the two doesn't help the discussion. While removing docstrings may be beneficial on memory-constrained devices, I can't remember a single situation where I've wanted to remove asserts on a production

Re: [Python-Dev] (#19562) Asserts in Python stdlib code (datetime.py)

2013-11-16 Thread Steven D'Aprano
On Sun, Nov 17, 2013 at 01:50:31AM +1000, Nick Coghlan wrote: No, that's the wrong question to ask. The onus is on *you* to ask Who is this feature for? Do they still need it? Can we meet their needs in a different way?. You're the one proposing to break things, so it's up to you to make the

Re: [Python-Dev] (#19562) Asserts in Python stdlib code (datetime.py)

2013-11-16 Thread Steven D'Aprano
On Sat, Nov 16, 2013 at 11:16:48AM -0500, Donald Stufft wrote: Personally I think that none of the -O* should be removing asserts. It feels like a foot gun to me. I’ve seen more than one codebase that would be completely broken under -O* because they used asserts without even knowing -O*