Re: Python turtle: How to change icons
On 11/25/2016 10:33 PM, qrious wrote: Hello All, I would like to change two graphical icons related to turtle graphics using Python: a) One that shows up at the top left corner of the canvas window as in below. I believe this is coming from tk itself. https://s22.postimg.org/tkjaxmh41/image.png That can be changed for app after creating root window and IDLE does so. See idlelib/pyshell.py (in 3.6, PyShell.py previously), after "# set application icon". Code is different for Windows and *nix/Mac. b) The icon on the desktop as in below (in Windows): https://s13.postimg.org/n7ol0mdpz/icon.png This is set during installation. I *presume* (but know no details) that icon file is loaded somewhat and appropriate registry setting connects app to icon file. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: The Case Against Python 3
On Fri, Nov 25, 2016 at 1:29 AM, Mark Summerfield wrote: > The article has a section called: > > "Too Many Formatting Options" > > He's right! The % formatting was kept to help port old code, the new > .format() which is far more versatile is a bit verbose, so finally they've > settled on f-strings. So, you do need to know that all three exist (e.g., for > maintaining code), but you can easily choose the style that you prefer and > just use that. Largely tangential, but don't you mean "all four"? PEP-292 template strings are also still around, though I don't recall that I've ever seen them used in the wild. When I read that Python 3.6 would include f-strings, I turned to the coworker sitting next to me and said, "Oh my god, Python is adding yet another new syntax for string formatting." It's getting to be a joke. -- https://mail.python.org/mailman/listinfo/python-list
Re: The Case Against Python 3
On 2016-11-26 01:01, Ian Kelly wrote: > When I read that Python 3.6 would include f-strings, I turned to the > coworker sitting next to me and said, "Oh my god, Python is adding > yet another new syntax for string formatting." It's getting to be a > joke. Pretty soon Python will have one string-formatting syntax for every Python web framework. ;-) -tkc -- https://mail.python.org/mailman/listinfo/python-list
how do i fix this invalid arguement error
import csv
with open('\\192.168.0.1\fe18cb0618cabd41\ninjatrader$EURUSDTestRun
2016-11-25-11-11.csv','r') as f:
reader=csv.reader(f)
for row in reader:
print(row)
File "C:/Users/Suresh/PycharmProjects/untitled/test.py", line 2, in
with open('\\192.168.0.1\fe18cb0618cabd41\ninjatrader$EURUSDTestRun
2016-11-25-11-11.csv','r') as f:
OSError: [Errno 22] Invalid argument:
'\\192.168.0.1\x0ce18cb0618cabd41\ninjatrader$EURUSDTestRun
2016-11-25-11-11.csv'
--
https://mail.python.org/mailman/listinfo/python-list
Re: how do i fix this invalid arguement error
On 11/26/2016 12:55 PM, Dennis Lee Bieber wrote: On Sat, 26 Nov 2016 08:12:46 -0800 (PST), [email protected] declaimed the following: import csv with open('\\192.168.0.1\fe18cb0618cabd41\ninjatrader$EURUSDTestRun 2016-11-25-11-11.csv','r') as f: reader=csv.reader(f) for row in reader: print(row) File "C:/Users/Suresh/PycharmProjects/untitled/test.py", line 2, in with open('\\192.168.0.1\fe18cb0618cabd41\ninjatrader$EURUSDTestRun 2016-11-25-11-11.csv','r') as f: OSError: [Errno 22] Invalid argument: '\\192.168.0.1\x0ce18cb0618cabd41\ninjatrader$EURUSDTestRun 2016-11-25-11-11.csv' First suggestion... Make it a RAW string. What you have has an embedded new-line character making it: \\192.168.0.1\fe18cb0618cabd41 injatrader$EURUSDTestRun 2016-11-25-11-11.csv Or use forward slashes: with open('/192.168.0.1/fe18cb0618cabd41/ninjatrader$EURUSDTestRun 2016-11-25-11-11.csv','r') as f: Second... does Python open() accept web addresses? What is at 192.168.0.1 that you don't have some more sensible path to it? 192.168.0.1 is a private local network address. You are on a Windows machine so if the file is available on a local network node you can probably mount that node (Computer/Map Network Drive) and access the file as something like Z:/ninjatrader... -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: how do i fix this invalid arguement error
On Sun, 27 Nov 2016 03:12 am, [email protected] wrote: > import csv > with open('\\192.168.0.1\fe18cb0618cabd41\ninjatrader$EURUSDTestRun > 2016-11-25-11-11.csv','r') as f: \f inserts a FORMFEED character, ASCII code 12. \n inserts a LINEFEED character, or newline, ASCII code 10. I believe that on Windows, both are illegal in file names. And \\ inserts a single backslash. You have three solutions: (1) Use forward slashes, which Windows accepts as well: '//192.168.0.1/fe18cb0618cabd41/ninjatrader$EURUSDTestRun 2016-11-25-11-11.csv' (2) Use a "raw string" to disable most (but not all) backslash escapes: r'\\192.168.0.1\fe18cb0618cabd41\ninjatrader$EURUSDTestRun 2016-11-25-11-11.csv' The problem with raw strings is that you cannot end a string with a backslash, so you cannot write: # this gives a syntax error r'C:\My Documents\directory\' (3) Or escape all your backslashes with more backslashes: '192.168.0.1\\fe18cb0618cabd41\\ninjatrader$EURUSDTestRun 2016-11-25-11-11.csv' -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: The Case Against Python 3
On Sat, 26 Nov 2016 07:01 pm, Ian Kelly wrote: > When I read that Python 3.6 would include f-strings, I turned to the > coworker sitting next to me and said, "Oh my god, Python is adding yet > another new syntax for string formatting." It's getting to be a joke. f-strings are not merely string formatting. They are a new syntax for evaluating arbitrary Python expressions, which then gets inserted into a string. In some ways, they're like the old Python 2 backtick syntax: py> `1 + len(str(5**4))` '4' except that you can automagically concatenate strings to the evaluated expressions. So-called f-strings haven't even hit the already been implicated in a code-injection vulnerability: http://bugs.python.org/issue28563 I feel kind of vindicated here, because when so-called f-strings were first proposed I asked about the security implication of another way of evaluating arbitrary expressions, and I was told that there were no security implications. Technically that might be true in the sense that f-strings don't do anything that wasn't already possible, but as the above bug shows, they can make exploiting code injection trivially easy in cases where they were previously diabolically hard. Yay for progress. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: The Case Against Python 3
On Sun, Nov 27, 2016 at 11:13 AM, Steve D'Aprano wrote: > So-called f-strings haven't even hit the already been implicated in a > code-injection vulnerability: > > http://bugs.python.org/issue28563 > > I feel kind of vindicated here, because when so-called f-strings were first > proposed I asked about the security implication of another way of > evaluating arbitrary expressions, and I was told that there were no > security implications. Technically that might be true in the sense that > f-strings don't do anything that wasn't already possible, but as the above > bug shows, they can make exploiting code injection trivially easy in cases > where they were previously diabolically hard. Given that the exploit exists in 2.7, I would say f-strings didn't create this, eval did. The problem is that you absolutely CANNOT "sanitize" something before giving it to eval. An f-string slips past the sanitizer, but so do other things. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: The Case Against Python 3
On Sun, 27 Nov 2016 11:25 am, Chris Angelico wrote:
> On Sun, Nov 27, 2016 at 11:13 AM, Steve D'Aprano
> wrote:
>> So-called f-strings haven't even hit the already been implicated in a
>> code-injection vulnerability:
>>
>> http://bugs.python.org/issue28563
>>
>> I feel kind of vindicated here, because when so-called f-strings were
>> first proposed I asked about the security implication of another way of
>> evaluating arbitrary expressions, and I was told that there were no
>> security implications. Technically that might be true in the sense that
>> f-strings don't do anything that wasn't already possible, but as the
>> above bug shows, they can make exploiting code injection trivially easy
>> in cases where they were previously diabolically hard.
>
> Given that the exploit exists in 2.7, I would say f-strings didn't
> create this, eval did.
I never said that f-strings caused the vulnerability. I choose my words
carefully. As I said when I mentioned this issue three weeks ago, the
underlying cause of the vulnerability is the use of eval on an untrusted
string. But the existence of a theoretical vulnerability is not the same as
an exploit, let alone an easy exploit.
> The problem is that you absolutely CANNOT
> "sanitize" something before giving it to eval.
Be careful about making absolute claims. I challenge you to break this use
of eval:
def calculate(phrase):
try:
phrase = sanitize(phrase)
except ValueError:
return
return eval(phrase, {'x': 20})
def sanitize(phrase):
phrase = phrase.replace(' ', '')
if phrase in ('x+1', '2*x'):
return phrase
raise ValueError('unsafe phrase')
For a more practical example, namedtuple uses exec to dynamically build the
class. Can you find a code injection attack in namedtuple? I doubt it. Not
all uses of exec or eval lead to a code injection vulnerability.
> An f-string slips past the sanitizer, but so do other things.
I daresay you are right that a sufficiently clever adversary may have found
an exploit. But there's no sign that anyone actually did find an exploit,
until f-strings made exploiting this trivial.
--
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.
--
https://mail.python.org/mailman/listinfo/python-list
Re: The Case Against Python 3
Sure, what if the input used a double quote instead of single, cursory
glance looks like it might vulnerable.
(Not trying to be argumentative here)
On Nov 26, 2016 7:21 PM, "Steve D'Aprano"
wrote:
> On Sun, 27 Nov 2016 11:25 am, Chris Angelico wrote:
>
> > On Sun, Nov 27, 2016 at 11:13 AM, Steve D'Aprano
> > wrote:
> >> So-called f-strings haven't even hit the already been implicated in a
> >> code-injection vulnerability:
> >>
> >> http://bugs.python.org/issue28563
> >>
> >> I feel kind of vindicated here, because when so-called f-strings were
> >> first proposed I asked about the security implication of another way of
> >> evaluating arbitrary expressions, and I was told that there were no
> >> security implications. Technically that might be true in the sense that
> >> f-strings don't do anything that wasn't already possible, but as the
> >> above bug shows, they can make exploiting code injection trivially easy
> >> in cases where they were previously diabolically hard.
> >
> > Given that the exploit exists in 2.7, I would say f-strings didn't
> > create this, eval did.
>
> I never said that f-strings caused the vulnerability. I choose my words
> carefully. As I said when I mentioned this issue three weeks ago, the
> underlying cause of the vulnerability is the use of eval on an untrusted
> string. But the existence of a theoretical vulnerability is not the same as
> an exploit, let alone an easy exploit.
>
>
> > The problem is that you absolutely CANNOT
> > "sanitize" something before giving it to eval.
>
> Be careful about making absolute claims. I challenge you to break this use
> of eval:
>
> def calculate(phrase):
> try:
> phrase = sanitize(phrase)
> except ValueError:
> return
> return eval(phrase, {'x': 20})
>
>
> def sanitize(phrase):
> phrase = phrase.replace(' ', '')
> if phrase in ('x+1', '2*x'):
> return phrase
> raise ValueError('unsafe phrase')
>
>
> For a more practical example, namedtuple uses exec to dynamically build the
> class. Can you find a code injection attack in namedtuple? I doubt it. Not
> all uses of exec or eval lead to a code injection vulnerability.
>
>
> > An f-string slips past the sanitizer, but so do other things.
>
> I daresay you are right that a sufficiently clever adversary may have found
> an exploit. But there's no sign that anyone actually did find an exploit,
> until f-strings made exploiting this trivial.
>
>
>
>
>
> --
> Steve
> “Cheer up,” they said, “things could be worse.” So I cheered up, and sure
> enough, things got worse.
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: The Case Against Python 3
On 11/26/2016 06:26 PM, Nathan Ernst wrote: > Sure, what if the input used a double quote instead of single, cursory > glance looks like it might vulnerable. Either a single quote or a double quote would not pass the sanitizer. Or am I misunderstanding you? -- https://mail.python.org/mailman/listinfo/python-list
Re: how do i fix this invalid arguement error
On 26Nov2016 12:55, Dennis Lee Bieber wrote: On Sat, 26 Nov 2016 08:12:46 -0800 (PST), [email protected] declaimed the following: with open('\\192.168.0.1\fe18cb0618cabd41\ninjatrader$EURUSDTestRun 2016-11-25-11-11.csv','r') as f: [...] Second... does Python open() accept web addresses? What is at 192.168.0.1 that you don't have some more sensible path to it? 192.168.0.1 is a private local network address. You are on a Windows machine so if the file is available on a local network node you can probably mount that node (Computer/Map Network Drive) and access the file as something like Z:/ninjatrader... I thought //192.168.0.1/foo/... was a network share, getting "foo" from host 192.168.0.1. Disclaimer: not a Windows guy. But I've certainly using UNIXy systems implementing this syntax, and thought I'd seen an equivalent in Windows land. So not HTTP, SMB. Confirmation or refutation from anyone? Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
Re: how do i fix this invalid arguement error
On Sun, Nov 27, 2016 at 1:24 PM, Cameron Simpson wrote: > I thought //192.168.0.1/foo/... was a network share, getting "foo" from host > 192.168.0.1. Disclaimer: not a Windows guy. But I've certainly using UNIXy > systems implementing this syntax, and thought I'd seen an equivalent in > Windows land. So not HTTP, SMB. Confirmation or refutation from anyone? Confirmed, that's the NETBIOS-over-TCP syntax, which Microsoft has maintained into the newer Windows drive-sharing protocols. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: The Case Against Python 3
You're right. Didn't look closely enough at it in my phone. Still don't think i'd recommend this in a general solution, though. You effectively have to white-list code snippets. Not very useful. On Nov 26, 2016 7:51 PM, "Michael Torrie" wrote: > On 11/26/2016 06:26 PM, Nathan Ernst wrote: > > Sure, what if the input used a double quote instead of single, cursory > > glance looks like it might vulnerable. > > Either a single quote or a double quote would not pass the sanitizer. Or > am I misunderstanding you? > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
