Re: [Python-Dev] Why does _pyio.*.readinto have to work with 'b' arrays?

On 15 June 2014 14:57, Nikolaus Rath wrote: > On 06/14/2014 09:31 PM, Nick Coghlan wrote: >> On 15 June 2014 10:41, Benjamin Peterson wrote: >>> On Sat, Jun 14, 2014, at 15:39, Nikolaus Rath wrote: It seems to me that a much cleaner solution would be to simply declare _pyio's readinto t

Re: [Python-Dev] subprocess shell=True on Windows doesn't escape ^ character

On 15/06/2014 02:22, Ryan Gonzalez wrote: Of course cmd.exe is hardcoded; Of course it's not: (from Lib/subprocess.py) comspec = os.environ.get("COMSPEC", "cmd.exe") I don't often expect, in these post-command.com days, to get anything other than cmd.exe. But alternative command processors

Re: [Python-Dev] Why does _pyio.*.readinto have to work with 'b' arrays?

On 06/14/2014 09:31 PM, Nick Coghlan wrote: > On 15 June 2014 10:41, Benjamin Peterson wrote: >> On Sat, Jun 14, 2014, at 15:39, Nikolaus Rath wrote: >>> It seems to me that a much cleaner solution would be to simply declare >>> _pyio's readinto to only work with bytearrays, and to explicitly rais

Re: [Python-Dev] Criticism of execfile() removal in Python3

On 15 June 2014 13:15, Steve Dower wrote: > So is exec(tokenize.open(file).read()) the actual replacement for > execfile()? Not too bad, but still not obvious (or widely promoted - I'd > never heard of it). Yes, that's pretty close. It's still a dubious idea due to the implicit modification of th

Re: [Python-Dev] Why does _pyio.*.readinto have to work with 'b' arrays?

On 15 June 2014 10:41, Benjamin Peterson wrote: > On Sat, Jun 14, 2014, at 15:39, Nikolaus Rath wrote: >> It seems to me that a much cleaner solution would be to simply declare >> _pyio's readinto to only work with bytearrays, and to explicitly raise a >> (more helpful) TypeError if anything else

Re: [Python-Dev] Criticism of execfile() removal in Python3

So is exec(tokenize.open(file).read()) the actual replacement for execfile()? Not too bad, but still not obvious (or widely promoted - I'd never heard of it). Top-posted from my Windows Phone From: Nick Coghlan Sent: ‎6/‎14/‎2014 18:31 T

Re: [Python-Dev] subprocess shell=True on Windows doesn't escape ^ character

On Thu, Jun 12, 2014 at 12:07 PM, Chris Angelico mailto:ros...@gmail.com>> wrote: > ISTM what you want is not shell=True, but a separate function that > follows the system policy for translating a command name into a > path-to-binary. According to the docs, subprocess.Popen sh

Re: [Python-Dev] subprocess shell=True on Windows doesn't escape ^ character

Of course cmd.exe is hardcoded; there are no other shells on Windows! (I'm purposely ignoring MinGW, Cygwin, command.com, etc.) If anything, auto-escaping will break scripts that are already designed to escape carets on Windows. On Sat, Jun 14, 2014 at 2:54 PM, anatoly techtonik wrote: > On Fri

Re: [Python-Dev] Criticism of execfile() removal in Python3

On 15 Jun 2014 09:37, "Steve Dower" wrote: > > I think the point is that the encoding may be embedded in the file as a coding comment and there's no obvious way to deal with that. Opening source files correctly is the intended use case for tokenize.open(). Cheers, Nick. _

Re: [Python-Dev] Criticism of execfile() removal in Python3

On 15 Jun 2014 06:52, "Paul Sokolovsky" wrote: > > Hello, > > On Tue, 10 Jun 2014 17:36:02 +1000 > Nick Coghlan wrote: > > > On 10 June 2014 12:23, Paul Sokolovsky wrote: > > > 1. It hampers interactive mode - instead of short and easy to type > > > execfile("file.py") one needs to use exec(open

Re: [Python-Dev] Why does _pyio.*.readinto have to work with 'b' arrays?

On Sat, Jun 14, 2014, at 15:39, Nikolaus Rath wrote: > It seems to me that a much cleaner solution would be to simply declare > _pyio's readinto to only work with bytearrays, and to explicitly raise a > (more helpful) TypeError if anything else is passed in. That seems reasonable. I don't think _p

Re: [Python-Dev] Criticism of execfile() removal in Python3

> you say "do this once", but actually it's "do it in each interactive > session again and again", ... That's what your Python startup file is for. I have been running with several tweaked builtin functions for years. Never have to consciously load them. If I wanted execfile badly enough, I'd def

Re: [Python-Dev] Criticism of execfile() removal in Python3

I think the point is that the encoding may be embedded in the file as a coding comment and there's no obvious way to deal with that. Top-posted from my Windows Phone From: Greg Ewing Sent: ‎6/‎14/‎2014 16:19 To: python-dev@pytho

Re: [Python-Dev] Criticism of execfile() removal in Python3

Fabio Zadrozny wrote: Well, I must say that the exec(open().read()) is not really a proper execfile implementation because it may fail because of encoding issues... It's not far off, though -- all it needs is an optional encoding parameter. -- Greg

[Python-Dev] Why does _pyio.*.readinto have to work with 'b' arrays?

Hello, The _pyio.BufferedIOBase class contains the following hack to make sure that you can read-into array objects with format 'b': try: b[:n] = data except TypeError as err: import array if not isinstance(b, array.array): raise

Re: [Python-Dev] Criticism of execfile() removal in Python3

On Sat, Jun 14, 2014 at 6:00 PM, Markus Unterwaditzer < mar...@unterwaditzer.net> wrote: > On Tue, Jun 10, 2014 at 05:23:12AM +0300, Paul Sokolovsky wrote: > > Hello, > > > > I was pleasantly surprised with the response to recent post about > > MicroPython implementation details > > (https://mail.

Re: [Python-Dev] Criticism of execfile() removal in Python3

On Tue, Jun 10, 2014 at 05:23:12AM +0300, Paul Sokolovsky wrote: > Hello, > > I was pleasantly surprised with the response to recent post about > MicroPython implementation details > (https://mail.python.org/pipermail/python-dev/2014-June/134718.html). I > hope that discussion means that posts ab

Re: [Python-Dev] Criticism of execfile() removal in Python3

Hello, On Tue, 10 Jun 2014 17:36:02 +1000 Nick Coghlan wrote: > On 10 June 2014 12:23, Paul Sokolovsky wrote: > > 1. It hampers interactive mode - instead of short and easy to type > > execfile("file.py") one needs to use exec(open("file.py").read()). > > I'm sure that's not going to bother a l

Re: [Python-Dev] subprocess shell=True on Windows doesn't escape ^ character

On Thu, Jun 12, 2014 at 5:12 AM, Chris Angelico wrote: > On Thu, Jun 12, 2014 at 12:07 PM, Chris Angelico wrote: > > ISTM what you want is not shell=True, but a separate function that > > follows the system policy for translating a command name into a > > path-to-binary. That's something that, A

Re: [Python-Dev] subprocess shell=True on Windows doesn't escape ^ character

On Fri, Jun 13, 2014 at 5:11 AM, Nikolaus Rath wrote: > "R. David Murray" writes: > > Also notice that using a list with shell=True is using the API > > incorrectly. It wouldn't even work on Linux, so that torpedoes > > the cross-platform concern already :) > > > > This kind of confusion is why

Re: [Python-Dev] subprocess shell=True on Windows doesn't escape ^ character

On Fri, Jun 13, 2014 at 2:55 AM, Ryan Gonzalez wrote: > SHELLS ARE NOT CROSS-PLATFORM Seriously, there are going to be > differences. If you really must: > > escape = lambda s: s.replace('^', '^^') if os.name == 'nt' else s > It is not about generic shell problem, it is about specific behavi

Re: [Python-Dev] Criticism of execfile() removal in Python3

Hello, On Tue, 10 Jun 2014 13:03:03 +1000 Steven D'Aprano wrote: > On Tue, Jun 10, 2014 at 05:23:12AM +0300, Paul Sokolovsky wrote: > > > execfile() builtin function was removed in 3.0. This brings few > > problems: > > > > 1. It hampers interactive mode - instead of short and easy to type > >