On 19 June 2014 20:39, Joseph Martinot-Lagarde
wrote:
> Another way is to open the file in binary, then exec() checks itself if an
> encoding is defined in the file. This is what is used in spyder:
>
> exec(open(file, 'rb').read())
>
> Here is the discussion for reference:
> https://bitbucket.org/
Le 15/06/2014 05:15, Steve Dower a écrit :
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).
Another way is to open the file in binary, then exec() checks itself if
an encoding is define
On 18 Jun 2014 01:59, "Chris Barker" wrote:
>
> By the way: iPython, while coming from, and heavily used by, the
scientific/numeric computing community, is a great tool for all sorts of
other python development as well. But probably too heavyweight for
micropython.
(we're drifting off topic, so t
On Mon, Jun 16, 2014 at 3:39 PM, Nick Coghlan wrote:
> > FWIW, when I started using python (15?) years ago -- the first thing I
> looked for was a way to "just run a file", at the interactive prompt, like
> I had in MATLAB. I found and used execfile().
>
> Yes, if people are looking for a MATLAB
On 17 Jun 2014 03:42, "Chris Barker" wrote:
>
> On Sat, Jun 14, 2014 at 1:11 PM, 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()).
>>
>> >
>> > If the amount of typing is
On 06/16/2014 10:40 AM, Chris Barker wrote:
My conclusions:
1) runfile() is not really very usefull, it's fine to hve removed it.
s/runfile/execfile
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listin
On Sat, Jun 14, 2014 at 1:11 PM, 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()).
>
> > If the amount of typing is the problem, that's easy to solve:
> >
> > # do this once
>
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
2014 18:31
To: Steve Dower<mailto:steve.do...@microsoft.com>
Cc: Greg Ewing<mailto:greg.ew...@canterbury.ac.nz>;
python-dev@python.org<mailto:python-dev@python.org>
Subject: Re: [Python-Dev] Criticism of execfile() removal in Python3
On 15 Jun 2014 09:37, "Steve Dower&
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.
_
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
> 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
python-dev@python.org<mailto:python-dev@python.org>
Subject: 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
> i
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
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.
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
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
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
> >
On 10 June 2014 23:05, R. David Murray wrote:
> On Tue, 10 Jun 2014 19:07:40 +1000, Nick Coghlan wrote:
>> I believe it's a space/speed trade-off, so I'd be surprised if it made
>> sense for CPython in general. There are also some behavioural differences
>> when it comes to handling syntax errors
On Tue, 10 Jun 2014 19:07:40 +1000, Nick Coghlan wrote:
> On 10 Jun 2014 18:41, "Paul Moore" wrote:
> >
> > On 10 June 2014 08:36, Nick Coghlan wrote:
> > > The standard implementation of run_path reads the whole file into
> > > memory, but MicroPython would be free to optimise that and do
> > >
On 10 Jun 2014 18:41, "Paul Moore" wrote:
>
> On 10 June 2014 08:36, Nick Coghlan wrote:
> > The standard implementation of run_path reads the whole file into
> > memory, but MicroPython would be free to optimise that and do
> > statement by statement execution instead (while that will pose some
On 10 June 2014 08:36, Nick Coghlan wrote:
> The standard implementation of run_path reads the whole file into
> memory, but MicroPython would be free to optimise that and do
> statement by statement execution instead (while that will pose some
> challenges in terms of handling encoding cookies, f
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 lot of people - after all, the
> easiest way to execute a Python file is t
On Mon, Jun 9, 2014 at 9:03 PM, Steven D'Aprano wrote:
> ...
> There's nothing stopping alternative implementations having their own
> implementation-specific standard library modules.
>
> steve@orac:/home/s$ jython
> Jython 2.5.1+ (Release_2_5_1, Aug 4 2010, 07:18:19)
> [OpenJDK Server VM (Sun M
On 6/9/2014 11:03 PM, 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.
Because it was hardly ever used. For short bits of code, it is usually
inferior to exec with a string in the file. For substantial bit
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
> execfile("file.py") one needs to use exec(open("file.py").read()).
If the amount
26 matches
Mail list logo
