On Thu, 30 Mar 2017 04:43 pm, Marko Rauhamaa wrote:
> Steven D'Aprano :
>
>> On Thu, 30 Mar 2017 07:29:48 +0300, Marko Rauhamaa wrote:
>>> I'd expect not having to deal with Unicode decoding exceptions with
>>> arbitrary input.
>>
>> That's just silly. If you have *arbitrary* bytes, not all
>> by
On Thu, Mar 30, 2017 at 4:57 PM, Marko Rauhamaa wrote:
> What I'm saying is that every program must behave in a minimally
> controlled manner regardless of its inputs (which are not in its
> control). With UTF-8, it is dangerously easy to write programs that
> explode surprisingly. What's more, re
Chris Angelico :
> On Thu, Mar 30, 2017 at 4:43 PM, Marko Rauhamaa wrote:
>> The input is not in my control, and bailing out may not be an option:
>>
>>$ echo
>> aa\n\xdd\naa' | grep aa
>>aa
>>aa
>>$ echo \xdd' | python2 -c 'import sys; sys.stdin.read(1)'
>>$ echo \xdd' | pyth
On Thu, Mar 30, 2017 at 4:43 PM, Marko Rauhamaa wrote:
> The input is not in my control, and bailing out may not be an option:
>
>$ echo
> aa\n\xdd\naa' | grep aa
>aa
>aa
>$ echo \xdd' | python2 -c 'import sys; sys.stdin.read(1)'
>$ echo \xdd' | python3 -c 'import sys; sys.stdi
Steven D'Aprano :
> On Thu, 30 Mar 2017 07:29:48 +0300, Marko Rauhamaa wrote:
>> I'd expect not having to deal with Unicode decoding exceptions with
>> arbitrary input.
>
> That's just silly. If you have *arbitrary* bytes, not all
> byte-sequences are valid Unicode, so you have to expect decoding
On Thu, 30 Mar 2017 07:29:48 +0300, Marko Rauhamaa wrote:
[...]
> I'd expect not having to deal with Unicode
> decoding exceptions with arbitrary input.
That's just silly. If you have *arbitrary* bytes, not all byte-sequences
are valid Unicode, so you have to expect decoding exceptions, if you'r
Steve D'Aprano :
> On Thu, 30 Mar 2017 06:47 am, Marko Rauhamaa wrote:
>> Huh? The standard input is the workload
>
> Which is usually typed by a human, read from a file containing
> human-readable text, a file-name intended to be read by a human, or
> some other data in human-readable form.
The
On Thu, Mar 30, 2017 at 11:14 AM, Steve D'Aprano
wrote:
> Just like the rest of the computation. Relatively few command-line
> computations are performed by machines, for machines, using
> machine-friendly human-hostile formats.
And even most computations performed by machines for machines are do
On Thu, 30 Mar 2017 06:47 am, Marko Rauhamaa wrote:
> Chris Angelico :
>> But normally, the standard streams are connected ultimately to a
>> human, so they're text.
>
> Huh? The standard input is the workload
Which is usually typed by a human, read from a file containing
human-readable text, a
On Wed, Mar 29, 2017 at 7:13 PM, Marko Rauhamaa wrote:
> eryk sun :
>> PowerShell is far more invasive. Instead of giving the child process a
>> handle for the file, it gives it a handle for a *pipe*. PowerShell
>> reads from the pipe, and like an annoying busybody that no asked for,
>> decodes th
Chris Angelico :
> But normally, the standard streams are connected ultimately to a
> human, so they're text.
Huh? The standard input is the workload and the standard output is the
result of the computation.
Arguably, the standard error stream is meant for humans.
Marko
--
https://mail.python.
On Thu, Mar 30, 2017 at 6:13 AM, Marko Rauhamaa wrote:
> eryk sun :
>> PowerShell is far more invasive. Instead of giving the child process a
>> handle for the file, it gives it a handle for a *pipe*. PowerShell
>> reads from the pipe, and like an annoying busybody that no asked for,
>> decodes th
eryk sun :
> PowerShell is far more invasive. Instead of giving the child process a
> handle for the file, it gives it a handle for a *pipe*. PowerShell
> reads from the pipe, and like an annoying busybody that no asked for,
> decodes the output as text,
You mean, a bit like Python3 does?
Marko
On Thu, Mar 30, 2017 at 5:29 AM, Rob Gaddi
wrote:
> Engineer 1: Man, that old DOS shell we keep emulating is just getting older
> and clunkier.
>
> Engineer 2: I know, we should rewrite it. You know, whole new thing, really
> modernize it.
>
> E1: So, like, bring in bash like everyone else?
>
> E
On Wednesday, March 29, 2017 at 11:20:45 AM UTC-7, eryk sun wrote:
> On Wed, Mar 29, 2017 at 5:42 PM, Jay Braun wrote:
> >
> > I'm not using ISE. I'm using a pre-edited script, and running it with the
> > python command.
> >
> > Consider the following simple script named hello.py (Python 2.7):
>
On 03/29/2017 11:23 AM, Chris Angelico wrote:
On Thu, Mar 30, 2017 at 5:19 AM, eryk sun wrote:
PowerShell is far more invasive. Instead of giving the child process a
handle for the file, it gives it a handle for a *pipe*. PowerShell
reads from the pipe, and like an annoying busybody that no ask
On Thu, Mar 30, 2017 at 5:19 AM, eryk sun wrote:
> PowerShell is far more invasive. Instead of giving the child process a
> handle for the file, it gives it a handle for a *pipe*. PowerShell
> reads from the pipe, and like an annoying busybody that no asked for,
> decodes the output as text, proce
On Wed, Mar 29, 2017 at 5:42 PM, Jay Braun wrote:
>
> I'm not using ISE. I'm using a pre-edited script, and running it with the
> python command.
>
> Consider the following simple script named hello.py (Python 2.7):
>
> print "Hello"
>
> If I enter:
> python hello.py > out.txt
>
> from cmd.exe I
On Thu, Mar 30, 2017 at 4:42 AM, Jay Braun wrote:
> Consider the following simple script named hello.py (Python 2.7):
>
> print "Hello"
>
> If I enter:
>
> python hello.py > out.txt
>
> from cmd.exe I get a 6-character file (characters plus new-line).
>
> from PowerShell I get an extract ^@ charac
On Wednesday, March 29, 2017 at 10:28:58 AM UTC-7, eryk sun wrote:
> On Wed, Mar 29, 2017 at 4:06 PM, wrote:
> > I wrote a Python script, which executed as intended on Linux and
> > from cmd.exe on Windows. Then, I ran it from the PowerShell
> >command line, all print statements added ^@ after e
On Wed, Mar 29, 2017 at 4:06 PM, wrote:
> I wrote a Python script, which executed as intended on Linux and
> from cmd.exe on Windows. Then, I ran it from the PowerShell
>command line, all print statements added ^@ after every character.
ISE is the only command-line environment that's specific t
lyngw...@gmail.com writes:
> I wrote a Python script, which executed as intended on Linux and from
> cmd.exe on Windows. Then, I ran it from the PowerShell command line,
> all print statements added ^@ after every character.
>
> Have you seen this? Do you know how to prevent this?
Script is pri
I wrote a Python script, which executed as intended on Linux and from cmd.exe
on Windows. Then, I ran it from the PowerShell command line, all print
statements added ^@ after every character.
Have you seen this? Do you know how to prevent this?
Thank you,
Jay
--
https://mail.python.org/mailm
23 matches
Mail list logo
