Launching a process with stdout in the terminal and captured

[Olive]

I am here on Linux. I want to launch a process just like os.system, (output to 
a terminal in an unbuffered way so as to support interaction) and at the same 
time capturing the output of the process (analogous to the Unix tee command). I 
have found some tricks on the web, but is it a standard way to do that? Note 
that if it is possible I would prefer that the launched command see its 
standard output connected to a terminal (many command change their behaviour 
accordingly like 'ls', etc.). 

The main reason now is to run latex (with its interaction), I need the output 
to know where it has put its output {dvi,pdf} file (you can't guess it from the 
command line because you can launch latex without any argument and \input a 
file afterwards). 

Olivier

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: value of pi and 22/7

[Christian Gollwitzer]

Am 18.06.16 um 03:19 schrieb Steven D'Aprano:

If I tell you that some physical phenomenon [let's call it the speed of
light] is 299,999,999 m/s, how many significant digits would I be using?

What if I tell you that it's 300,000,001 m/s?

What if the figure to nine significant digits *actually is* three followed
by eight zeroes?


You can't read off the number of significant figures from a value 
itself, it must be given as a side information. It is a common way to 
indicate uncertainty estimes, however, by giving a number to as many 
decimal places as there are significant digits, i.e. to indicate the 
uncertainty as a power of ten. You need to use exponential notation to 
express that clearly, in that case:


3*10^8 -> (3 +/- 0.5) * 10^8
3.0 *10^8 -> (3.0 +/- 0.05)*10^8

For more accurate error estimates, the second notation is used. Another 
common way to express this is something like


3.42(3) which means 3.42 +/- 0.03

Note, however, that in current SI units the speed of light is known exactly:

c = 299,792,458 m/s

There is no error! This is possible because the unit metre is defined by 
this value from the unit second.


Christian
--
https://mail.python.org/mailman/listinfo/python-list

Re: Launching a process with stdout in the terminal and captured

[eryk sun]

On Sat, Jun 18, 2016 at 7:09 AM, Olive
 wrote:
> I am here on Linux.
> ...
> Note that if it is possible I would prefer that the launched command see its 
> standard
> output connected to a terminal

Try pexpect.

https://pypi.python.org/pypi/pexpect
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: (repost) Advisory: HTTP Header Injection in Python urllib

[Marko Rauhamaa]

Steven D'Aprano :

> "Even an unauthenticated service listening on localhost is risky these
> days."
>
> but fall short of *explicitly* recommending that they should be
> authenticated. Although they do *implicitly* do so, by saying that "it
> wouldn't be hard" for such services to include a password.

In the local case, one should consider using local domain sockets
(AF_LOCAL), which can reliably identify the peer's credentials
(SO_PASSCRED, SO_PEERCRED).


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: best text editor for programming Python on a Mac

[Terry Reedy]

On 6/18/2016 3:04 AM, Michael Vilain via Python-list wrote:

In article ,
 supp...@ecourierz.com wrote:


use notepad++


To me, for programming only in Python, IDLE beats Notepad++.  Some 
features noted below.



[pay no attention to the little windows troll behind the curtain]

"best" is subjective.  Anytime someone wants the "best", I ask "what
features are important to you that would make it the best" because I'm
pretty sure what I find important wouldn't be what they find important.

Things I've seen in a bunch of straight editors:

- syntax coloring
- parathesis/block matching
- auto indent
- expansion of keywords, variables, subroutines
- integrated documentation so you don't have to lookup the syntax and
arguments of a function
- integration with code management systems (svn, git, github)
- regular expression searching
- multi-file regular expression search/replace
- multi-pane/window diff/merge
- programmability (e.g. write/store macros to perform repeatable tasks)
- integrated compile, run & syntax checking (this is really a function
of an IDE)


When compile of text in editor fails, the cursor is moved to the spot 
where indicated by the compiler.


When compile succeeds but there is a runtime error, one can jump from 
traceback to any of the file and line specified in the traceback.  This 
is *extremely* useful.


When one runs the integrated grep over part of the directory tree, one 
can jump to any of the file/line hits.



- interactive debugger (program stepping, expression & variable
evaluation, breakpoints, watchpoints, macros) [this is why I like perl]
- extensibility to add features (lint or code formatting, special
framework, etc.)



What's the best? That's your homework.  Write 500 describing what is the
Best editor and why.


--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: best text editor for programming Python on a Mac

[Marko Rauhamaa]

Michael Vilain :

> "best" is subjective. Anytime someone wants the "best", I ask "what
> features are important to you that would make it the best" because I'm
> pretty sure what I find important wouldn't be what they find
> important.

That's a bit like asking what gender, nationality and religion you'd
prefer for yourself.

I mean, having used emacs since the mid-1980's, everything just seems to
be in the right place -- including typing this posting.

> - syntax coloring
> - parathesis/block matching
> - auto indent

Yes, in active use.

> - expansion of keywords, variables, subroutines

Never learned to need that.

> - integrated documentation so you don't have to lookup the syntax and 
> arguments of a function

I have seen that in action with eclipse and Java. It could never match
having a web browser window next to the editor window: https://docs.python.org/3/library/>.

It would be nice if python provided a full set of man pages as well as
info documentation like C. Those are integrated into emacs.

> - integration with code management systems (svn, git, github)
> - regular expression searching
> - multi-file regular expression search/replace
> - multi-pane/window diff/merge
> - programmability (e.g. write/store macros to perform repeatable tasks)

Yes, in active use.

> - integrated compile, run & syntax checking (this is really a function 
> of an IDE)
> - interactive debugger (program stepping, expression & variable 
> evaluation, breakpoints, watchpoints, macros) [this is why I like perl]

As far as Python goes, emacs does have some elementary support for pdb.
Haven't found it all that practical, though.

> - extensibility to add features (lint or code formatting, special 
> framework, etc.)

Although they do exist for emacs, I'm not a big fan of special plugins
of any sort.

> What's the best? That's your homework. Write 500 describing what is
> the Best editor and why.

Emacs doesn't take up the whole screen. It integrates seamlessly with
the Unix way of doing things (but has some trouble with non-Unix culture
items like Java). It can be run perfectly fine in a text terminal
session. It takes care of all of your typing needs: when you type, type
in emacs. Shell, email, news, documentation (with ASCII graphics!),
programming...


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: best text editor for programming Python on a Mac

[Lawrence D’Oliveiro]

On Saturday, June 18, 2016 at 9:40:23 PM UTC+12, Marko Rauhamaa wrote:

> Michael Vilain:
> 
>> - expansion of keywords, variables, subroutines

Reminds me of a story by a local CompSci lecturer who originally learned Java 
through an IDE with autocomplete. Then one day he sat down to write some Java 
code without the benefit of autocomplete, and realized he didn’t know the 
language at all.

>> - integrated documentation so you don't have to lookup the syntax and 
>> arguments of a function
> 
> I have seen that in action with eclipse and Java. It could never match
> having a web browser window next to the editor window:  https://docs.python.org/3/library/>.

I do exactly the same. Here’s my story: I’ve lost track of the number of times 
I have seen people write (in several different languages) sequences like

x = ... expression for x ...
y = ... expression for y ...
s = math.sqrt(x * x + y * y)

instead of the more direct

s = math.hypot(... expression for x ..., ... expression for y ...)

Would this “integrated documentation” to “lookup the syntax and arguments of a 
function” point out that math.hypot is a better function to use in this case 
than math.sqrt? No. For that, you have to actually be able to read and 
understand the reference documentation.

> Emacs doesn't take up the whole screen. It integrates seamlessly with
> the Unix way of doing things (but has some trouble with non-Unix culture
> items like Java).

Also an Emacs user here, even used it with Java (for Android).
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Method Chaining

[Pete Forman]

Rustom Mody  writes:

> On Friday, June 17, 2016 at 2:58:19 PM UTC+5:30, Steven D'Aprano wrote:
>> On Fri, 17 Jun 2016 06:13 pm, Ned Batchelder wrote:
>>
>> > To me, it's a toss-up. The chained version is nice in that it
>> > removes the repetition of "g". But the unchained version is more
>> > explicit, and avoids the awkward parenthesis.
>> >
>> > I think I would lean toward the unchained version. Clearly tastes
>> > can differ.
>>
>> Indeed. For what it's worth, I'm ever-so-slightly leaning towards
>> Lawrence's taste here.
>
> More than 'slightly' out here!
> One thing about python OOP that irritates me is the 'self.' clutter.
> With a Pascal/VB style with-statement its naturally taken care of
>
> Yeah I know there is this FAQ:
> https://docs.python.org/2/faq/design.html#why-doesn-t-python-have-a-with-statement-for-attribute-assignments
>
> I consider it bogus if we allow with to mean something like:
> https://msdn.microsoft.com/en-us/library/wc500chb.aspx

One subtle difference between your two citations is that VB uses a
leading dot. Might that lessening of ambiguity enable a future Python to
allow this?

class Foo:
def .set(a):  # equivalent to def set(self, a):
.a = a# equivalent to self.a = a

Unless it is in a with statement

with obj:
.a = 1# equivalent to obj.a = 1
.total = .total + 1   # obj.total = obj.total + 1

-- 
Pete Forman
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: value of pi and 22/7

[Pete Forman]

Lawrence D’Oliveiro  writes:

> On Saturday, March 19, 2011 at 3:16:41 AM UTC+13, Grant Edwards wrote:
>>
>> On 2011-03-18, peter wrote:
>>
>>> The Old Testament (1 Kings 7,23) says ... "And he made a molten sea,
>>> ten cubits from the one brim to the other: it was round all about, and
>>> his height was five cubits: and a line of thirty cubits did compass it
>>> round about. ".  So pi=3.  End Of.
>>
>> There's nothing wrong with that value.  The measurements were given
>> with one significant digit, so the ratio of the two measurements
>> should only have one significant digit.
>
> I’m not sure how you can write “30” with one digit...

>>> int('U', 36)
30

-- 
Pete Forman
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: best text editor for programming Python on a Mac

[alister]

On Sat, 18 Jun 2016 12:40:09 +0300, Marko Rauhamaa wrote:

> 
>> - integrated documentation so you don't have to lookup the syntax and
>> arguments of a function
> 
> I have seen that in action with eclipse and Java. It could never match
> having a web browser window next to the editor window:  https://docs.python.org/3/library/>.
> 
> It would be nice if python provided a full set of man pages as well as
> info documentation like C. Those are integrated into emacs.
> 
pydoc - I think Guido's time machine strikes again :-)

pydoc - the Python documentation tool

pydoc  ...
Show text documentation on something.   may be the name of a
Python keyword, topic, function, module, or package, or a dotted
reference to a class or function within a module or module in a
package.  If  contains a '/', it is used as the path to a
Python source file to document. If name is 'keywords', 'topics',
or 'modules', a listing of these things is displayed.

pydoc -k 
Search for a keyword in the synopsis lines of all available modules.

pydoc -p 
Start an HTTP server on the given port on the local machine.  Port
number 0 can be used to get an arbitrary unused port.

pydoc -w  ...
Write out the HTML documentation for a module to a file in the current
directory.  If  contains a '/', it is treated as a filename; if
it names a directory, documentation is written for all the contents.

as it uses docstrings it should work well with any reasonably well 
written module - (even your own)




-- 
... The prejudices people feel about each other disappear when they get
to know each other.
-- Kirk, "Elaan of Troyius", stardate 4372.5
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Method Chaining

[Joonas Liik]

On 18 June 2016 at 15:04, Pete Forman  wrote:
> Rustom Mody  writes:
>
>> On Friday, June 17, 2016 at 2:58:19 PM UTC+5:30, Steven D'Aprano wrote:
>>> On Fri, 17 Jun 2016 06:13 pm, Ned Batchelder wrote:
>>>
>>> > To me, it's a toss-up. The chained version is nice in that it
>>> > removes the repetition of "g". But the unchained version is more
>>> > explicit, and avoids the awkward parenthesis.
>>> >
>>> > I think I would lean toward the unchained version. Clearly tastes
>>> > can differ.
>>>
>>> Indeed. For what it's worth, I'm ever-so-slightly leaning towards
>>> Lawrence's taste here.
>>
>> More than 'slightly' out here!
>> One thing about python OOP that irritates me is the 'self.' clutter.
>> With a Pascal/VB style with-statement its naturally taken care of
>>
>> Yeah I know there is this FAQ:
>> https://docs.python.org/2/faq/design.html#why-doesn-t-python-have-a-with-statement-for-attribute-assignments
>>
>> I consider it bogus if we allow with to mean something like:
>> https://msdn.microsoft.com/en-us/library/wc500chb.aspx
>
> One subtle difference between your two citations is that VB uses a
> leading dot. Might that lessening of ambiguity enable a future Python to
> allow this?
>
> class Foo:
> def .set(a):  # equivalent to def set(self, a):
> .a = a# equivalent to self.a = a
>
> Unless it is in a with statement
>
> with obj:
> .a = 1# equivalent to obj.a = 1
> .total = .total + 1   # obj.total = obj.total + 1
>
> --
> Pete Forman
> --
> https://mail.python.org/mailman/listinfo/python-list

the leading dot does not resolve the ambiguity that arises from:

with ob_a:
with ob_b:
.attr_c = 42 # which object are we modifying right now?

also refer to "javascript the bad parts" about all the edege cases
that python would surely face.
also with is allready used for context managers..
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: value of pi and 22/7

[boB Stepp]

On Sat, Jun 18, 2016 at 12:47 AM, Tim Harig
 wrote:

>
> The main problem I have with significant figures is that measurement
> accuracy is often not constrained to a decimal system.  A scale that can
> measure in 1/5 units is more accurate than a scale that can measure only
> in whole units but it is not as accurate as a scale that can measure
> all 1/10 units.  Therefore it effectively has a fractional number of
> significant figures.

Probably in this type of discussion a more careful distinction between
"precision" and "accuracy" should be made.  A measuring instrument may
allow for many significant digits in its reported result, giving it a
high level of precision, but could, in fact, be giving an inaccurate
measurement (How close it is to the "true" value.), especially if it
is an instrument that has not been properly calibrated (Made to agree
as well as possible with known standards.).

boB
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Method Chaining

[Rustom Mody]

On Saturday, June 18, 2016 at 5:34:30 PM UTC+5:30, Pete Forman wrote:
> Rustom Mody  writes:
> 
> > On Friday, June 17, 2016 at 2:58:19 PM UTC+5:30, Steven D'Aprano wrote:
> >> On Fri, 17 Jun 2016 06:13 pm, Ned Batchelder wrote:
> >>
> >> > To me, it's a toss-up. The chained version is nice in that it
> >> > removes the repetition of "g". But the unchained version is more
> >> > explicit, and avoids the awkward parenthesis.
> >> >
> >> > I think I would lean toward the unchained version. Clearly tastes
> >> > can differ.
> >>
> >> Indeed. For what it's worth, I'm ever-so-slightly leaning towards
> >> Lawrence's taste here.
> >
> > More than 'slightly' out here!
> > One thing about python OOP that irritates me is the 'self.' clutter.
> > With a Pascal/VB style with-statement its naturally taken care of
> >
> > Yeah I know there is this FAQ:
> > https://docs.python.org/2/faq/design.html#why-doesn-t-python-have-a-with-statement-for-attribute-assignments
> >
> > I consider it bogus if we allow with to mean something like:
> > https://msdn.microsoft.com/en-us/library/wc500chb.aspx
> 
> One subtle difference between your two citations is that VB uses a
> leading dot. Might that lessening of ambiguity enable a future Python to
> allow this?
> 
> class Foo:
> def .set(a):  # equivalent to def set(self, a):
> .a = a# equivalent to self.a = a
> 

Chuckle! Heck Why not?!
But no I did not think of this

> Unless it is in a with statement
> 
> with obj:
> .a = 1# equivalent to obj.a = 1
> .total = .total + 1   # obj.total = obj.total + 1


I intended only this much viz that the syntactic marker '.' disambiguates
between ordinary variable and attribute

As for what happens when there are nested references as mentioned by Waffle:
Well these ambiguities have a venerable vintage in programming languages
Starting from the dangling else to which declaration a variable refers to
when there are nested scopes and much else ie "match-to-the-innermost" seems
to be obvious enough
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Method Chaining

[Pete Forman]

Joonas Liik  writes:

> On 18 June 2016 at 15:04, Pete Forman  wrote:
>> Rustom Mody  writes:
>>
>>> On Friday, June 17, 2016 at 2:58:19 PM UTC+5:30, Steven D'Aprano wrote:
 On Fri, 17 Jun 2016 06:13 pm, Ned Batchelder wrote:

 > To me, it's a toss-up. The chained version is nice in that it
 > removes the repetition of "g". But the unchained version is more
 > explicit, and avoids the awkward parenthesis.
 >
 > I think I would lean toward the unchained version. Clearly tastes
 > can differ.

 Indeed. For what it's worth, I'm ever-so-slightly leaning towards
 Lawrence's taste here.
>>>
>>> More than 'slightly' out here!
>>> One thing about python OOP that irritates me is the 'self.' clutter.
>>> With a Pascal/VB style with-statement its naturally taken care of
>>>
>>> Yeah I know there is this FAQ:
>>> https://docs.python.org/2/faq/design.html#why-doesn-t-python-have-a-with-statement-for-attribute-assignments
>>>
>>> I consider it bogus if we allow with to mean something like:
>>> https://msdn.microsoft.com/en-us/library/wc500chb.aspx
>>
>> One subtle difference between your two citations is that VB uses a
>> leading dot. Might that lessening of ambiguity enable a future Python to
>> allow this?
>>
>> class Foo:
>> def .set(a):  # equivalent to def set(self, a):
>> .a = a# equivalent to self.a = a
>>
>> Unless it is in a with statement
>>
>> with obj:
>> .a = 1# equivalent to obj.a = 1
>> .total = .total + 1   # obj.total = obj.total + 1
>>
>> --
>> Pete Forman
>> --
>> https://mail.python.org/mailman/listinfo/python-list
>
> the leading dot does not resolve the ambiguity that arises from:
>
> with ob_a:
> with ob_b:
> .attr_c = 42 # which object are we modifying right now?
>
> also refer to "javascript the bad parts" about all the edege cases
> that python would surely face.
> also with is allready used for context managers..

Yes, I ought not to have lumped in the with proposal with that for self.
Python's design FAQ clearly explains why the language does not need that
form of "with".

-- 
Pete Forman
-- 
https://mail.python.org/mailman/listinfo/python-list

best text editor for programming Python on a Mac

[MrJean1]

Try TextWrangler from BareBones 
.  I've been using that for 
years on MacOS X.

/Jean
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: best text editor for programming Python on a Mac

[Rustom Mody]

On Saturday, June 18, 2016 at 3:10:23 PM UTC+5:30, Marko Rauhamaa wrote:
> Michael Vilain :
> 
> > "best" is subjective. Anytime someone wants the "best", I ask "what
> > features are important to you that would make it the best" because I'm
> > pretty sure what I find important wouldn't be what they find
> > important.
> 
> That's a bit like asking what gender, nationality and religion you'd
> prefer for yourself.
> 
> I mean, having used emacs since the mid-1980's, everything just seems to
> be in the right place -- including typing this posting.
> 
> > - syntax coloring
> > - parathesis/block matching
> > - auto indent
> 
> Yes, in active use.
> 
> > - expansion of keywords, variables, subroutines
> 
> Never learned to need that.
> 
> > - integrated documentation so you don't have to lookup the syntax and 
> > arguments of a function
> 
> I have seen that in action with eclipse and Java. It could never match
> having a web browser window next to the editor window:  https://docs.python.org/3/library/>.
> 
> It would be nice if python provided a full set of man pages as well as
> info documentation like C. Those are integrated into emacs.
> 
> > - integration with code management systems (svn, git, github)
> > - regular expression searching
> > - multi-file regular expression search/replace
> > - multi-pane/window diff/merge
> > - programmability (e.g. write/store macros to perform repeatable tasks)
> 
> Yes, in active use.
> 
> > - integrated compile, run & syntax checking (this is really a function 
> > of an IDE)
> > - interactive debugger (program stepping, expression & variable 
> > evaluation, breakpoints, watchpoints, macros) [this is why I like perl]
> 
> As far as Python goes, emacs does have some elementary support for pdb.
> Haven't found it all that practical, though.
> 
> > - extensibility to add features (lint or code formatting, special 
> > framework, etc.)
> 
> Although they do exist for emacs, I'm not a big fan of special plugins
> of any sort.
> 
> > What's the best? That's your homework. Write 500 describing what is
> > the Best editor and why.
> 
> Emacs doesn't take up the whole screen. It integrates seamlessly with
> the Unix way of doing things (but has some trouble with non-Unix culture
> items like Java). It can be run perfectly fine in a text terminal
> session. It takes care of all of your typing needs: when you type, type
> in emacs. Shell, email, news, documentation (with ASCII graphics!),
> programming...
> 
> 
> Marko

Having expatiatated all that you could have added some tips to OP on handling 
unicode in emacs :-)

Some emacs tips
[Note If recommending emacs ⇒ recommender = sadist; blame is on first mention!]

Emacs has a modeline at bottom which tells all sorts of things -- one of them
the coding system (as it detects/decides) at the left corner.
For latin-1 it should show a '1' and then there should be no problem
If it shows 'U' then its utf-something (usually UTF-8) and you have a likely
problem

To force latin-1 type
C-x RET f (ie control-X followed by return followed by an 'f')
It will ask for what coding system to save file
Say latin-1-unix
[the unix is for LF line endings]
And the U should change to 1 and you are done

OTOH there may be a non-latin-1-able character it will complain and put the 
cursor on the offending char

[
For that matter if I had to guess whats happened I'd hazard that you cut-pasted
something from a pdf which converted ASCII quotes -- '  " -- into one
of ‘ “ And unfortunately thats not very visible
]

If this is the case emacs will helpfully tell you to do something about these

In order to check for sure put the cursor on the char and type
C-u C-x =

eg On the “ I get

 position: 13 of 13 (92%), column: 0
character: “ (displayed as “) (codepoint 8220, #o20034, #x201c)
preferred charset: unicode (Unicode (ISO10646))
code point in charset: 0x201C
   script: symbol
   syntax: .which means: punctuation
 category: .:Base, c:Chinese, h:Korean, j:Japanese
 to input: type "C-x 8 RET HEX-CODEPOINT" or "C-x 8 RET NAME"
  buffer code: #xE2 #x80 #x9C
file code: #xFF #xFE #x1C #x20 (encoded by coding system 
utf-16-le-unix)
  display: by this font (glyph code)
xft:-DAMA-Ubuntu Mono-normal-normal-normal-*-17-*-*-*-m-0-iso10646-1 (#x70)

Character code properties: customize what to show
  name: LEFT DOUBLE QUOTATION MARK
  old-name: DOUBLE TURNED COMMA QUOTATION MARK
  general-category: Pi (Punctuation, Initial quote)
  decomposition: (8220) ('“')


Yeah thats a mouthful but that the codepoint > 127 indicates you have a problem
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: (repost) Advisory: HTTP Header Injection in Python urllib

[Steven D'Aprano]

On Sat, 18 Jun 2016 01:52 pm, Random832 wrote:

> On Fri, Jun 17, 2016, at 21:00, Steven D'Aprano wrote:
>> The author doesn't go into details of what sort of attacks against
>> localhost they're talking about. An unauthenticated service running on
>> localhost implies, to me, a single-user setup, where presumably the
>> single-user has admin access to localhost. So I'm not really sure what
>> "risk" they have
> 
> The issue - especially clearly in this context, which demonstrates a
> working exploit for this vulnerability - is cross-site request forgery.
> Which doesn't technically require the victim service to be HTTP (I
> remember a proof of concept a while back which would trick a browser
> into connecting to an IRC server), so long as it can ignore HTTP
> headers.

Er, you may have missed that I'm talking about a single user setup. Are you
suggesting that I can't trust myself not to forge a request that goes to a
hostile site?

It's all well and good to say that the application is vulnerable to X-site
attacks, but how does that relate to a system where I'm the only user?



-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: value of pi and 22/7

[Johannes Bauer]

On 18.06.2016 01:12, Lawrence D’Oliveiro wrote:

> I’m not sure how you can write “30” with one digit...

3e1 has one significant digit.

Cheers,
Johannes

-- 
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
 - Karl Kaos über Rüdiger Thomas in dsa 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: (repost) Advisory: HTTP Header Injection in Python urllib

[alister]

On Sun, 19 Jun 2016 02:02:43 +1000, Steven D'Aprano wrote:

> On Sat, 18 Jun 2016 01:52 pm, Random832 wrote:
> 
>> On Fri, Jun 17, 2016, at 21:00, Steven D'Aprano wrote:
>>> The author doesn't go into details of what sort of attacks against
>>> localhost they're talking about. An unauthenticated service running on
>>> localhost implies, to me, a single-user setup, where presumably the
>>> single-user has admin access to localhost. So I'm not really sure what
>>> "risk" they have
>> 
>> The issue - especially clearly in this context, which demonstrates a
>> working exploit for this vulnerability - is cross-site request forgery.
>> Which doesn't technically require the victim service to be HTTP (I
>> remember a proof of concept a while back which would trick a browser
>> into connecting to an IRC server), so long as it can ignore HTTP
>> headers.
> 
> Er, you may have missed that I'm talking about a single user setup. Are
> you suggesting that I can't trust myself not to forge a request that
> goes to a hostile site?
> 
> It's all well and good to say that the application is vulnerable to
> X-site attacks, but how does that relate to a system where I'm the only
> user?

one possible reason I can think of is if for whatever reason your 
computer is infected by malware that malware could make use of the 
service.



-- 
"The only way for a reporter to look at a politician is down."
-- H.L. Mencken
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: (repost) Advisory: HTTP Header Injection in Python urllib

[Random832]

On Sat, Jun 18, 2016, at 12:02, Steven D'Aprano wrote:
> Er, you may have missed that I'm talking about a single user setup.
> Are you suggesting that I can't trust myself not to forge a request
> that goes to a hostile site?
>
> It's all well and good to say that the application is vulnerable to
> X-site attacks, but how does that relate to a system where I'm the
> only user?

I don't think you understand what cross-site request forgery is, unless
your definition of "single user setup" includes not connecting to the
internet at all. The point is that one site causes the client to send a
request (not desired by the user) to another site. That the client is a
single-user system makes no difference.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: (repost) Advisory: HTTP Header Injection in Python urllib

[Paul Rubin]

Steven D'Aprano  writes:
>> The issue ... is cross-site request forgery.
> Er, you may have missed that I'm talking about a single user setup. Are you
> suggesting that I can't trust myself not to forge a request that goes to a
> hostile site?

I think the idea is you visit some website with malicious script that
accesses your localhost resources from your browser.  So it's not a
matter of trusting yourself.  Rather, it's one of trusting every website
you visit, including the ad servers they transclude, etc.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Method Chaining

[Ethan Furman]

On 06/18/2016 07:05 AM, Joonas Liik wrote:

On 18 June 2016 at 15:04, Pete Forman wrote:



with obj:
 .a = 1# equivalent to obj.a = 1
 .total = .total + 1   # obj.total = obj.total + 1


the leading dot does not resolve the ambiguity that arises from:

with ob_a:
 with ob_b:
 .attr_c = 42 # which object are we modifying right now?


The innermost one.  Why would it be anything else?

--
~Ethan~

--
https://mail.python.org/mailman/listinfo/python-list

Re: PyCon Keynote

[Chris Angelico]

On Sun, Jun 19, 2016 at 7:14 AM, Quivis  wrote:
> On Thu, 09 Jun 2016 12:53:37 -0700, Ethan Furman wrote:
>
>>https://www.youtube.com/watch?v=bSfe5M_zG2s
>
> Good example of how not to do a presentation. Embarrassing.
> I turned it off after one minute.

Strange. Must be in the eye of the beholder... I watched it, shared it
with members of my family, then added it to our list of "watch these
if you haven't".

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PyCon Keynote

[alex wright]

I enjoyed it.  Skipped most of the intro video but I enjoyed the content of
his talk.  Shared with a co-worker as well.
On Jun 18, 2016 5:23 PM, "Chris Angelico"  wrote:

> On Sun, Jun 19, 2016 at 7:14 AM, Quivis  wrote:
> > On Thu, 09 Jun 2016 12:53:37 -0700, Ethan Furman wrote:
> >
> >>https://www.youtube.com/watch?v=bSfe5M_zG2s
> >
> > Good example of how not to do a presentation. Embarrassing.
> > I turned it off after one minute.
>
> Strange. Must be in the eye of the beholder... I watched it, shared it
> with members of my family, then added it to our list of "watch these
> if you haven't".
>
> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PyCon Keynote

[Michael Torrie]

On 06/18/2016 03:20 PM, Chris Angelico wrote:
> On Sun, Jun 19, 2016 at 7:14 AM, Quivis  wrote:
>> On Thu, 09 Jun 2016 12:53:37 -0700, Ethan Furman wrote:
>>
>>>https://www.youtube.com/watch?v=bSfe5M_zG2s
>>
>> Good example of how not to do a presentation. Embarrassing.
>> I turned it off after one minute.
> 
> Strange. Must be in the eye of the beholder... I watched it, shared it
> with members of my family, then added it to our list of "watch these
> if you haven't".

Indeed that was very good. Thanks for posting this, Ethan.  It's neat to
see the links between computer programming, logic, nature, life, and
philosophy.  He's a very good teacher and speaker.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PyCon Keynote

[Michael Torrie]

On 06/18/2016 04:33 PM, Michael Torrie wrote:
> On 06/18/2016 03:20 PM, Chris Angelico wrote:
>> On Sun, Jun 19, 2016 at 7:14 AM, Quivis  wrote:
>>> On Thu, 09 Jun 2016 12:53:37 -0700, Ethan Furman wrote:
>>>
https://www.youtube.com/watch?v=bSfe5M_zG2s
>>>
>>> Good example of how not to do a presentation. Embarrassing.
>>> I turned it off after one minute.
>>
>> Strange. Must be in the eye of the beholder... I watched it, shared it
>> with members of my family, then added it to our list of "watch these
>> if you haven't".
> 
> Indeed that was very good. Thanks for posting this, Ethan.  It's neat to
> see the links between computer programming, logic, nature, life, and
> philosophy.  He's a very good teacher and speaker.

Does anyone know what kind of electric instrument he was playing and how
it works?

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: best text editor for programming Python on a Mac

[Michael Torrie]

On 06/17/2016 05:52 PM, Chris via Python-list wrote:
> Any suggestions for a good open source text editor for the Mac out
> there?  For now, I am going to stick with vim.

Good choice.


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: best text editor for programming Python on a Mac

[Lawrence D’Oliveiro]

On Sunday, June 19, 2016 at 11:07:23 AM UTC+12, Michael Torrie wrote:
>
> On 06/17/2016 05:52 PM, Chris via Python-list wrote:
>>
>> Any suggestions for a good open source text editor for the Mac out
>> there?  For now, I am going to stick with vim.
> 
> Good choice.

The trouble with vim/vi/whatever, is that it doesn’t work like any other editor 
on Earth.

Pull up any old GUI-based editor you like, for example Windows (shudder) 
Notepad. If there are N characters in your file, then the insertion point can 
be placed at N + 1 positions: in-between two adjacent characters, or before the 
first character, or after the last character. And this makes sense: anything 
you type is inserted at the insertion point. All rational text editors (and 
word processors) work this way.

But not vi/vim. It only lets you place your cursor *on* a character, not 
*in-between* characters. That’s why you need two separate insertion commands, 
insert-before and insert-after. And one of those has the interesting side 
effect where, if you exit insertion mode without inserting anything, it doesn’t 
put you back in the same position as before. Why?

As to why you need insertion commands at all, that’s another thing...
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: best text editor for programming Python on a Mac

[Joel Goldstick]

On Sat, Jun 18, 2016 at 8:12 PM, Lawrence D’Oliveiro
 wrote:
> On Sunday, June 19, 2016 at 11:07:23 AM UTC+12, Michael Torrie wrote:
>>
>> On 06/17/2016 05:52 PM, Chris via Python-list wrote:
>>>
>>> Any suggestions for a good open source text editor for the Mac out
>>> there?  For now, I am going to stick with vim.
>>
>> Good choice.
>
> The trouble with vim/vi/whatever, is that it doesn’t work like any other 
> editor on Earth.
>
> Pull up any old GUI-based editor you like, for example Windows (shudder) 
> Notepad. If there are N characters in your file, then the insertion point can 
> be placed at N + 1 positions: in-between two adjacent characters, or before 
> the first character, or after the last character. And this makes sense: 
> anything you type is inserted at the insertion point. All rational text 
> editors (and word processors) work this way.
>
> But not vi/vim. It only lets you place your cursor *on* a character, not 
> *in-between* characters. That’s why you need two separate insertion commands, 
> insert-before and insert-after. And one of those has the interesting side 
> effect where, if you exit insertion mode without inserting anything, it 
> doesn’t put you back in the same position as before. Why?
>
> As to why you need insertion commands at all, that’s another thing...
> --
> https://mail.python.org/mailman/listinfo/python-list

I personally love vim.  But its clearly an acquired taste.  When you
get good at it its pretty amazing -- and no mouse.  The other thing
about vim is that it is on every linux system, so you don't have to
load your editor if you are ssh-ing to some machine

-- 
Joel Goldstick
http://joelgoldstick.com/blog
http://cc-baseballstats.info/stats/birthdays
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: best text editor for programming Python on a Mac

[Michael Torrie]

On 06/18/2016 06:12 PM, Lawrence D’Oliveiro wrote:
> On Sunday, June 19, 2016 at 11:07:23 AM UTC+12, Michael Torrie
> wrote:
>> 
>> On 06/17/2016 05:52 PM, Chris via Python-list wrote:
>>> 
>>> Any suggestions for a good open source text editor for the Mac
>>> out there?  For now, I am going to stick with vim.
>> 
>> Good choice.
> 
> The trouble with vim/vi/whatever, is that it doesn’t work like any
> other editor on Earth.

The fact that the OP is using vim would suggest this doesn't really
matter to him all that much.

> Pull up any old GUI-based editor you like, for example Windows
> (shudder) Notepad. If there are N characters in your file, then the
> insertion point can be placed at N + 1 positions: in-between two
> adjacent characters, or before the first character, or after the last
> character. And this makes sense: anything you type is inserted at the
> insertion point. All rational text editors (and word processors) work
> this way.

Indeed, so does vi/vim.  Why do you think otherwise?

> But not vi/vim. It only lets you place your cursor *on* a character,
> not *in-between* characters. That’s why you need two separate
> insertion commands, insert-before and insert-after. And one of those
> has the interesting side effect where, if you exit insertion mode
> without inserting anything, it doesn’t put you back in the same
> position as before. Why?
> 
> As to why you need insertion commands at all, that’s another
> thing...

Having used vim for years and also normal editors including word
processors, I have no idea what you're talking about by how insert
works.  It works the exactly the same.  I put my cursor under a letter,
hit insert, and I am inserting text before that letter, just like any
other text editor.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: best text editor for programming Python on a Mac

[Michael Torrie]

On 06/18/2016 06:50 PM, Michael Torrie wrote:
> On 06/18/2016 06:12 PM, Lawrence D’Oliveiro wrote:
>> But not vi/vim. It only lets you place your cursor *on* a character,
>> not *in-between* characters. That’s why you need two separate
>> insertion commands, insert-before and insert-after. And one of those
>> has the interesting side effect where, if you exit insertion mode
>> without inserting anything, it doesn’t put you back in the same
>> position as before. Why?

Nevermind I see what you are talking about.  Doesn't bother me though.

>> As to why you need insertion commands at all, that’s another
>> thing...

In it's day, the scriptability of ed depended on this feature.


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: best text editor for programming Python on a Mac

[Michael Torrie]

On 06/18/2016 06:12 PM, Lawrence D’Oliveiro wrote:
> Pull up any old GUI-based editor you like, for example Windows
> (shudder) Notepad. If there are N characters in your file, then the
> insertion point can be placed at N + 1 positions: in-between two
> adjacent characters, or before the first character, or after the last
> character. And this makes sense: anything you type is inserted at the
> insertion point. All rational text editors (and word processors) work
> this way.
> 
> But not vi/vim. It only lets you place your cursor *on* a character,
> not *in-between* characters. That’s why you need two separate
> insertion commands, insert-before and insert-after. And one of those
> has the interesting side effect where, if you exit insertion mode
> without inserting anything, it doesn’t put you back in the same
> position as before. Why?

In thinking about this, I think the answer is that in olden days no one
had though of using the imaginary spaces between characters as a
position.  So we had:

0 1 2 3 4 5 6 7 8 9
H E L L O W O R L D

10 character cells, 10 cursor positions.  Hence you had 10 places you
could insert before (which works well for everything but appending to
the string) or 10 places to insert after.  So that distinction between
insert and append was logical, and still is today, depending on your
background and experience.

It was later on that they figured out the N+1 thing you mentioned by
ignoring the character cells:

0 1 2 3 4 5 6 7 8 9 10
 H E L L O W O R L D

That works well for interactive editing, but it doesn't lend itself as
well to scripting and working with the contents of the text cells.
Indeed the text cells aren't actually addressable directly in this
scheme though conventionally the number immediately before the cell is
used to index the cell.  This can lead to confusion.  For example, if
the cursor is in position 10, that's not really part of the text, but it
kind of appears like it is.

I like that with vim I can see immediately whether there is trailing
space on a line just by jumping to the end of the line ($) which will
drop the cursor on the last actual character.

So I guess it's just a matter of history.  Perhaps it's a bit like big
endian vs little endian. Neither system is inherently better; it's just
what you get used to.  And arguments can be made either way.
-- 
https://mail.python.org/mailman/listinfo/python-list

best text editor for programming Python on a Mac

[drednot57]

My go to python editor is Dr. Python.  Coded in Python with the wxPython GUI 
library, but I use Linux.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: best text editor for programming Python on a Mac

[Lawrence D’Oliveiro]

On Sunday, June 19, 2016 at 2:09:31 PM UTC+12, Michael Torrie wrote:
> It was later on that they figured out the N+1 thing you mentioned by
> ignoring the character cells:
> 
> 0 1 2 3 4 5 6 7 8 9 10
>  H E L L O W O R L D
> 
> That works well for interactive editing, but it doesn't lend itself as
> well to scripting and working with the contents of the text cells.

Emacs scripting works perfectly well with this convention.

> I like that with vim I can see immediately whether there is trailing
> space on a line just by jumping to the end of the line ($) which will
> drop the cursor on the last actual character.

Emacs has an option (which I have enabled) which shows trailing white space 
throughout your entire file in bright red. And I have also defined a single 
keystroke that will get rid of it all.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: best text editor for programming Python on a Mac

[Michael Torrie]

On 06/18/2016 08:51 PM, Lawrence D’Oliveiro wrote:
> On Sunday, June 19, 2016 at 2:09:31 PM UTC+12, Michael Torrie wrote:
>> It was later on that they figured out the N+1 thing you mentioned by
>> ignoring the character cells:
>>
>> 0 1 2 3 4 5 6 7 8 9 10
>>  H E L L O W O R L D
>>
>> That works well for interactive editing, but it doesn't lend itself as
>> well to scripting and working with the contents of the text cells.
> 
> Emacs scripting works perfectly well with this convention.

Yes that's true.

Just saying though, it wasn't always obvious which is why ed chose to do
it the way they did.  vi, being somewhat compatible with ed's command
structure, follows the same pattern.  Two different ways of doing
things. Let's not make the mistake of thinking one way is necessarily
better.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: best text editor for programming Python on a Mac

[Michael Torrie]

On 06/18/2016 08:51 PM, Lawrence D’Oliveiro wrote:
> On Sunday, June 19, 2016 at 2:09:31 PM UTC+12, Michael Torrie wrote:
>> It was later on that they figured out the N+1 thing you mentioned
>> by ignoring the character cells:
>> 
>> 0 1 2 3 4 5 6 7 8 9 10 H E L L O W O R L D
>> 
>> That works well for interactive editing, but it doesn't lend itself
>> as well to scripting and working with the contents of the text
>> cells.
> 
> Emacs scripting works perfectly well with this convention.
> 
>> I like that with vim I can see immediately whether there is
>> trailing space on a line just by jumping to the end of the line ($)
>> which will drop the cursor on the last actual character.
> 
> Emacs has an option (which I have enabled) which shows trailing white
> space throughout your entire file in bright red. And I have also
> defined a single keystroke that will get rid of it all.

And I got it wrong anyway. Both ed and vim either put the cursor between
characters (insert mode), or on the character (command mode).  Probably
made sense at the time.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: best text editor for programming Python on a Mac

[Lawrence D’Oliveiro]

On Sunday, June 19, 2016 at 4:54:36 PM UTC+12, Michael Torrie wrote:

> Two different ways of doing things. Let's not make the mistake of thinking one
> way is necessarily better.

When one leads to more complications, the answer is pretty clear...
-- 
https://mail.python.org/mailman/listinfo/python-list