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

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* ex

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

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

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

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 sy

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

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 coul

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

On Sat, Nov 16, 2013 at 10:15 AM, Antoine Pitrou wrote: > 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

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

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 se

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

On 17 Nov 2013 09:48, "Brett Cannon" 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 separate "Progra

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

On 17 Nov 2013 04:45, "Eric Snow" wrote: > > On Sat, Nov 16, 2013 at 11:15 AM, Antoine Pitrou 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

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

On Sat, Nov 16, 2013 at 1:40 PM, Eric Snow wrote: > 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. ) It's not that big a

Re: [Python-Dev] NTPath or WindowsPath?

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, sysconfig.get

Re: [Python-Dev] NTPath or WindowsPath?

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 Peterson

Re: [Python-Dev] NTPath or WindowsPath?

2013/11/16 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? I agree with Guido. -- Regards, Benjamin _

[Python-Dev] NTPath or WindowsPath?

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 mail

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

On Sat, Nov 16, 2013 at 11:15 AM, Antoine Pitrou 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 Once the cor

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

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. ) It's not that big a deal and not that hard to figure out (so I'm fine with the

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

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 d

[Python-Dev] Accepting PEP 3154 for 3.4?

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 obvi

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

On Sat, Nov 16, 2013 at 10:55 AM, M.-A. Lemburg 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 Sat, Nov 1

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

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 or

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

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 h

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

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 m

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

On Sat, Nov 16, 2013 at 02:53:22AM -0800, Maciej Fijalkowski wrote: > On Fri, Nov 15, 2013 at 6:56 PM, Trent Nelson wrote: > > On Tue, Nov 12, 2013 at 01:16:55PM -0800, Victor Stinner wrote: > >> pysandbox cannot be used in practice > >> > >> > >> To protect th

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

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 way

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

On Sat, 16 Nov 2013 11:16:48 -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* existed.

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

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 bi

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

On 17 November 2013 01:46, 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 system. While I

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

On 17 November 2013 01:34, Maciej Fijalkowski wrote: > On Sat, Nov 16, 2013 at 5:33 PM, Maciej Fijalkowski wrote: >> On Sat, Nov 16, 2013 at 5:09 PM, Nick Coghlan wrote: >>> On 16 November 2013 23:17, Maciej Fijalkowski wrote: On Sat, Nov 16, 2013 at 3:51 AM, Terry Reedy wrote: > If u

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

On Sat, 16 Nov 2013 17:34:15 +0200 Maciej Fijalkowski wrote: > On Sat, Nov 16, 2013 at 5:33 PM, Maciej Fijalkowski wrote: > > On Sat, Nov 16, 2013 at 5:09 PM, Nick Coghlan wrote: > >> On 16 November 2013 23:17, Maciej Fijalkowski wrote: > >>> On Sat, Nov 16, 2013 at 3:51 AM, Terry Reedy wrote:

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

On Sat, Nov 16, 2013 at 5:33 PM, Maciej Fijalkowski wrote: > On Sat, Nov 16, 2013 at 5:09 PM, Nick Coghlan wrote: >> On 16 November 2013 23:17, Maciej Fijalkowski wrote: >>> On Sat, Nov 16, 2013 at 3:51 AM, Terry Reedy wrote: If user input can trigger an assert, then the code should raise

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

On Sat, Nov 16, 2013 at 5:09 PM, Nick Coghlan wrote: > On 16 November 2013 23:17, Maciej Fijalkowski wrote: >> On Sat, Nov 16, 2013 at 3:51 AM, Terry Reedy wrote: >>> If user input can trigger an assert, then the code should raise a normal >>> exception that will not disappear with -OO. >> >> Ma

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

On 16 November 2013 23:17, Maciej Fijalkowski wrote: > On Sat, Nov 16, 2013 at 3:51 AM, Terry Reedy 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 be killed? "I don't care

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

On Sat, Nov 16, 2013 at 3:51 AM, Terry Reedy 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 file.

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

On 16 November 2013 21:49, M.-A. Lemburg 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 idea of a

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

On 16 November 2013 21:38, Nick Coghlan wrote: > On 16 November 2013 20:45, Victor Stinner 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

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

On Sat, 16 Nov 2013 19:44:51 +1000 Nick Coghlan 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. Regards Antoine.

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

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

On 16 November 2013 20:45, Victor Stinner 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 types. However, that'

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

On Fri, Nov 15, 2013 at 6:56 PM, Trent Nelson 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 protections. Bec

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

On Sat, Nov 16, 2013 at 12:12 PM, Nick Coghlan wrote: > On 16 Nov 2013 11:35, "Christian Tismer" 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 t

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

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" a écrit : > On 16 Nov 2013 10:47, "Victor Stinner" wrote: > > > > 2013/11/16 Nick Coghlan

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

On 16 Nov 2013 11:35, "Christian Tismer" 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 python' > would

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

On 16 Nov 2013 10:47, "Victor Stinner" wrote: > > 2013/11/16 Nick Coghlan : > > 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 systematically blacklist particular

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

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/