Re: [OT'ish] Is there a list as good as this for Javascript

[Ben Finney]

Mark Lawrence  writes:

> No.  While this idiot, BartC, is let loose on this forum, I'll say
> what I like.

That is the attitude of a petulant schoolyard bully. Stop, please. You
are to behave well in this community, and this is not conditional on the
behaviour of others.

You are better that that. Please continue to show it.

-- 
 \  “Some forms of reality are so horrible we refuse to face them, |
  `\ unless we are trapped into it by comedy. To label any subject |
_o__)unsuitable for comedy is to admit defeat.” —Peter Sellers |
Ben Finney

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

Re: [OT'ish] Is there a list as good as this for Javascript

[cl]

Larry Martell  wrote:
> On Thu, Mar 24, 2016 at 4:53 PM,   wrote:
> > I use Python wherever I can and find this list (as a usenet group via
> > gmane) an invaluable help at times.
> >
> > Occasionally I have to make forays into Javascript, can anyone
> > recommend a place similar to this list where Javascript questions can
> > be asked?  The trouble is that there are very many usenet Javascript
> > lists and it's difficult to guess which one[es] might be good.
> 
> I don't know of any JS specific mailing lists. When I have a JS
> question I usually use stackoverflow. But there is also the web design
> mailing list, which will accept JS questions. See
> http://www.webdesign-l.com/
> 
OK, thanks, I do know about both of those though I hadn't realised
there was a mailing list at Web Design.


> For jQuery questions I use the jquery forum - http://forum.jquery.com/

I find forums very difficult to use in general for a number of reasons:-

I have to visit them individually, it's not practical for the
number of subjects I'm interested in. I belong to 77 lists just
now, a similar number of forums would be totally unmanageable.

I can't use a decent editor (or my choice) to write and reply to
messages.

The threading is often rather poor (though some are better than
others).

-- 
Chris Green
·
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Web Scraping

[alister]

On Thu, 24 Mar 2016 18:17:43 -0700, 121sukha wrote:

> I am new to python and I want to use web scraping to download songs from
> website.
> how do I write code to check if the website has uploaded a new song and
> have that song automatically be downloaded onto my computer. I know how
> to use the requests.get() module but i am more interested in knowing how
> to download and save every new song that the website uploads on the
> site. I would extremely appreciate the help from anyone. Thanks!

I belive if you contact the RIAA they have full details available



-- 
You or I must yield up his life to Ahrimanes.  I would rather it were you.
I should have no hesitation in sacrificing my own life to spare yours, but
we take stock next week, and it would not be fair on the company.
-- J. Wellington Wells
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT'ish] Is there a list as good as this for Javascript

[alister]

On Thu, 24 Mar 2016 23:46:14 +, Mark Lawrence wrote:

> On 24/03/2016 23:33, Ian Kelly wrote:
>> On Thu, Mar 24, 2016 at 4:58 PM, Mark Lawrence
>>  wrote:
>>> No.  While this idiot, BartC, is let loose on this forum, I'll say
>>> what I like.
>>
>> Good to know. I've been on the fence about this for a long time, but
>> lately the frequency of your outbursts seems to have increased, and
>> you're being more of a nuisance to this list than the people whom
>> you're complaining about.
>>
>> *plonk*
>>
>>
> I just love it.  A complete moron like BartC insults the Python
> community day in, day out, yet I'm the problem?   When he can actually
> write a decent line of Python code and avoid discussing speed I'll think
> about him as a professional programmer.  I cannot see this happening
> when all he talks about is byte code.  He's clearly never read anything
> like Steve Maguire's "Writing Solid Code".

I am afraid I have to disagree with you
Responding in BartC's threads is one thing but you are now deliberately 
trolling him in others, this is a bad as a poster (who shall remain 
namless) continually telling people the cause of there issues is due to 
pythons Unicode handling. it does nothing for the OP of this thread & 
quickly renders it useless.



-- 
I'm into SOFTWARE!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[BartC]

On 25/03/2016 01:02, Dennis Lee Bieber wrote:

On Thu, 24 Mar 2016 19:54:54 +, BartC  declaimed the
following:




(I use a dedicated repeat-N-times loop that needs no explicit loop
variable,



Well, that sure wouldn't support a Python for-loop...


If I may, I'll reply to this point outside the group, at this link:

http://pastebin.com/hfAKN2jg


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

RE: Effects of caching frequently used objects, was Re: Explaining names vs variables in Python

[Albert-Jan Roskam]

> To: python-list@python.org
> From: __pete...@web.de
> Subject: Effects of caching frequently used objects, was Re: Explaining  
> names  vs variables  in Python
> Date: Wed, 2 Mar 2016 10:12:48 +0100
> 
> Salvatore DI DIO wrote:
> 
> > Hello,
> > 
> > I know Python does not have variables, but names.
> > Multiple names cant then be bound to the same objects.
> > 
> > So this behavior
> > 
>  b = 234
>  v = 234
>  b is v
> > True
> > 
> > according to the above that is ok
> > 
> > 
> > 
> > But where is the consistency ? if I try :
> > 
>  v = 890
>  w = 890
>  v is w
> > False
> > 
> > It is a little difficult to explain this behavior to a newcommer in Python
> > 
> > Can someone give me the right argument to expose ?
> 
> You should not bother with object identity for objects other than None.


A little late to the party, but: how about Ellipsis? Shouldn't "is" also be 
used for that one? (It's rare, I know :))
Albert-Jan

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

Re: Effects of caching frequently used objects, was Re: Explaining names vs variables in Python

[Chris Angelico]

On Sat, Mar 26, 2016 at 12:03 AM, Albert-Jan Roskam
 wrote:
>> You should not bother with object identity for objects other than None.
>
>
> A little late to the party, but: how about Ellipsis? Shouldn't "is" also be 
> used for that one? (It's rare, I know :))

Yes, and also True and False, if you're checking for the specific
values. (Though it's more common in Python to merely care about
truthiness/falsiness.) Other common identity checks include:

if str is bytes:
# Python 2 handling, where "native strings" are byte strings
else:
# Python 3 handling, where "native strings" are text strings

if iter(x) is x:
# x is an iterator, not some other iterable

_SENTINEL = object()
def func(arg=_SENTINEL):
if arg is _SENTINEL:
# arg was not passed

Anyone who says that identity checks are only for None is
significantly over-simplifying things. This isn't necessarily a bad
thing, but it should never be taken to be the whole story.

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

Re: Tkinter --> Why multiple windows

[kevind0718]

On Thursday, March 24, 2016 at 9:24:44 PM UTC-4, Wildman wrote:
> On Thu, 24 Mar 2016 13:24:16 -0700, kevind0718 wrote:
> 
> > Hello:
> > 
> > newbie Tkinter question
> > 
> > If I run the code below two windows appear.
> > One empty and one with the text box and button.
> > 
> > Why?  please
> > 
> > KD
> > 
> > 
> > 
> > from Tkinter import *
> > 
> > class MyDialog:
> > def __init__(self, parent):
> > 
> > top = self.top = Toplevel(parent)
> > 
> > Label(top, text="Value").pack()
> > 
> > self.e = Entry(top)
> > self.e.pack(padx=5)
> > 
> > b = Button(top, text="OK", command=self.ok)
> > b.pack(pady=5)
> > 
> > def ok(self):
> > 
> > print "value is", self.e.get()
> > 
> > self.top.destroy()
> > 
> > 
> > root = Tk()
> > 
> > d = MyDialog(root)
> > 
> > root.wait_window(d.top)
> 
> Try this:
> 
> from Tkinter import *
> 
> class MyDialog(Frame):
> 
> def __init__(self, parent):
> Frame.__init__(self, parent)
> self.parent = parent
> self.pack(fill=BOTH, expand=1)
> self.parent.title("MyDialog")
> Label(self, text="Value").pack()
> self.e = Entry(self)
> self.e.pack(padx=5)
> self.b = Button(self, text="OK", command=self.ok)
> self.b.pack(pady=5)
> 
> def ok(self):
> print "value is", self.e.get()
> 
> root = Tk()
> d = MyDialog(root)
> root.mainloop()
> 
> -- 
>  GNU/Linux user #557453
> May the Source be with you.


Looking at the lines below 
As related to the code I posted above.
I believe this code will allow me to instantiate the class
MyDialog, wait until the window is destroyed and then 
continue on my merry way.

root = Tk()
d = MyDialog(root)
root.wait_window(d.top) 


Now if I pass an instance of  Unamepword into the constructor of
MyDialog(unamepword) , I can modify uStr and pWord in MyDialog and 
the local copy will get updated.  
Correct?

class Unamepword:
## 
## class to hold user name and pWord for Database
uName = None
pWord = None
def __init__(self, uStr, pStr):
self.uName = uStr
self.pWord = pStr

Many thanks for your attention to this matter.

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

Re: Problem With Embedded Icon and Python 3.4

[Wildman via Python-list]

On Fri, 25 Mar 2016 01:30:17 -0400, Terry Reedy wrote:

> On 3/25/2016 1:10 AM, Wildman via Python-list wrote:
>> I have a program that I have been trying to rewrite so it will
>> run on Python 2.7 and 3.4.  It has been a pain to say the least.
>> Thank $DIETY for aliases.  Anyway, I got it all working except
>> for one thing.  The program has an embedded icon.  It is displayed
>> in the window's titlebar.  The icon is a 16x16 png that has been
>> base64 encoded using a Linux utility called memencoder.  The code
>> below works perfectly with Python 2.7.  The icon data is complete
>> for anyone that wants to try to run this code:
>>
>> encoded_icon = """\
> 
> To make this literal a bytes literal, prepend 'b'.
> 
> encoded_icon = b'''\

Whoopee, that worked!  Thank you.

-- 
 GNU/Linux user #557453
The cow died so I don't need your bull!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Problem With Embedded Icon and Python 3.4

[Wildman via Python-list]

On Fri, 25 Mar 2016 00:34:13 -0500, Zachary Ware wrote:

> On Fri, Mar 25, 2016 at 12:10 AM, Wildman via Python-list
>  wrote:
>> I have a program that I have been trying to rewrite so it will
>> run on Python 2.7 and 3.4.  It has been a pain to say the least.
>> Thank $DIETY for aliases.  Anyway, I got it all working except
>> for one thing.  The program has an embedded icon.  It is displayed
>> in the window's titlebar.  The icon is a 16x16 png that has been
>> base64 encoded using a Linux utility called memencoder.  The code
>> below works perfectly with Python 2.7.  The icon data is complete
>> for anyone that wants to try to run this code:
>>
>> encoded_icon = """\
> [...]
>> I tried converting the icon string to a byte variable like this:
>>
>> encoded_icon = bytes("""\
>> iVBORw0KGgoNSUhEUgAAABAQCAMoLQ9TBGdBTUEAALGPC/xhBQAAACBj
>> (...)
>> ZGlmeQAyMDE2LTAzLTIxVDE1OjE5OjI3LTA1OjAwe2m2vwBJRU5ErkJggg==""")
>>
>>
>> That give me a different error:
>>
>> Traceback (most recent call last):
>>   File "./myprogram.py", line 269, in 
>> ZGlmeQAyMDE2LTAzLTIxVDE1OjE5OjI3LTA1OjAwe2m2vwBJRU5ErkJggg==""")
>> TypeError: string argument without an encoding
>>
>> I'm not sure what that means.  I looks like it wants the string
>> to be encoded but it already is.
> 
> The bytes constructor in Python 3 requires you to provide an encoding
> (utf-8, ascii, latin-1, koi8, etc) when passing in a string, otherwise
> it doesn't know what bytes you want and refuses to guess.  You could
> fix this by adding `encoding='ascii'` to the bytes() call–but I'm not
> certain that that would work in 2.7, and there's a much easier method,
> noted later.
> 
>> And why the reference to only
>> the last line of the string?
> 
> Because the traceback would be huge if it included the entire function
> call, and there's no need to.  You can find the error from just that
> line.  It would be arguably more useful to show the first line, but
> that's more difficult to do.
> 
>> I am at a loss here.  Any help would be greatly appreciated.
> 
> What you need here is a bytes literal, which is accomplished by
> prepending a 'b' to the string literal.   Your `encoded_icon = """\`
> just needs to become `encoded_icon = b"""\`.  See here [1] for more
> information.

Thanks for the info and the link.  That fixed the problem.

-- 
 GNU/Linux user #557453
The cow died so I don't need your bull!
-- 
https://mail.python.org/mailman/listinfo/python-list

Undefined behaviour in C [was Re: The Cost of Dynamism]

[Steven D'Aprano]

On Fri, 25 Mar 2016 06:54 am, BartC wrote:

>> In the case of C, the line is limited to working with some specific type
>> (say, an int32). Even there, if the addition might overflow, the
>> behaviour is undefined and the compiler can do anything it wants
>> (including time travel,
> 
> I'm pretty sure it can't do time travel...
> 
>   or erasing your hard disk).


You are absolutely, and potentially catastrophically, mistaken on that.

Undefined behaviour does not mean "implementation specific behaviour". Nor
does it mean "something sensible will happen but we don't promise what it
will be". It means "the compiler can do anything", including ignoring the
code you actually wrote and substituting its own faster code, which may or
may not do what your original code did.

We can presume that no non-malicious C compiler will *intentionally* erase
your hard drive because you added 1 to an integer without checking for
overflow, but it is certainly true that undefined behaviour can lead to any
behaviour at all. Undefined behaviour in C is a major cause of bugs and
security vulnerabilities.

Raymond Chen, one of Microsoft's luminaries, describes how undefined
behaviour can travel backwards in time to affect code that executes
*before* the undefined behaviour occurs:

https://blogs.msdn.microsoft.com/oldnewthing/20140627-00/?p=633/

Many people assume that if your code has undefined behaviour, you might have
no idea what happens from that point on, but at least you can reason
correctly about the state of the program prior to that. THIS IS INCORRECT.
The C standard makes no such promise, and in fact explicitly states that
the effect of undefined behaviour can affect code that runs before the
undefined behaviour occurs.


Here is an excellent three part article about undefined behaviour:

http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_21.html

And three-parter:

http://blog.regehr.org/archives/213
http://blog.regehr.org/archives/226
http://blog.regehr.org/archives/232

Bruce Dawson:

https://randomascii.wordpress.com/2014/05/19/undefined-behavior-can-format-your-drive/

And I love the title of this talk from Robert C Seacord at CERT:

"Dangerous Optimizations and the Loss of Causality"

http://bsidespgh.com/2014/media/speakercontent/DangerousOptimizationsBSides.pdf



Undefined behaviour in C is a minefield waiting to blow your program's legs
off, because the designers of the language made the explicit choice that
they wanted the language to be as fast and efficient as possible, even at
the cost of safe, reproducible behaviour.



-- 
Steven

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

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[Steven D'Aprano]

On Fri, 25 Mar 2016 10:06 pm, BartC wrote:

> On 25/03/2016 01:02, Dennis Lee Bieber wrote:
>> On Thu, 24 Mar 2016 19:54:54 +, BartC  declaimed the
>> following:
>>
>>
>>>
>>> (I use a dedicated repeat-N-times loop that needs no explicit loop
>>> variable,
> 
>> Well, that sure wouldn't support a Python for-loop...
> 
> If I may, I'll reply to this point outside the group, at this link:
> 
> http://pastebin.com/hfAKN2jg

Why split the discussion to *Pastebin*, of all places?

Anyway, this is (in my opinion) the only relevant part of your comments
there:



[quote]
But it is an optimisation that /could/ be done by the byte-code compiler
when it sees a construct such as:
 
for i in range(100):
   .
and 'i' isn't used within the loop. (I don't know what Python says about the
value of i after the loop terminates.)
[end quote]


i is guaranteed to have the same value outside the loop as it last had
inside the loop, unless you explicitly unbind the name using "del" (or
something equivalent).

So after:

for i in range(100):
pass
print(i)


"99" will be printed. Likewise:

for i in range(100):
if i == 50: break
print(i)


"50" will be printed.


[quote] 
This change would require a new byte-code (one that goes at the end of a
loop, not the start), which probably wouldn't be popular either. And, by
itself, would have very little impact on the majority of programs. (Also,
if loops are that much of a problem, this is where PyPy excels.)
[end quote]


I am pretty sure that PyPy takes lots of efforts to optimize loops, but I
can't tell you precisely what.

I would also expect that Victor Stinner's FAT Python project will
(eventually) look at optimizing such for-loops too. If you see something
like:

for i in range(N):
do_stuff()


and three conditions hold:

(1) i is unused in the loop body;

(2) range is still bound to the expected built-in function, and no
other "range" in a nearer scope (say, a local variable called "range", or a
global) exists to shadow it; and

(3) and the body of the for-loop has no side-effects that might affect the
truth of (1)

then it should be safe to replace this loop with a fast, C loop that just
calls the body of the loop N times. And that in turn might be fully or
partly unrolled, e.g. 

for i in range(4):
spam()

could become:

spam()
spam()
spam()
spam()


(This is a pretty standard compiler optimization technique, and if I recall
correctly, PyPy already does this.)


#1 (is i used in the loop?) can be detected at compile-time. There might be
some tricky corner cases involving calls to nested functions, and of course
any call to eval or exec make the analysis intractable, but I think it is
otherwise easy to tell whether or not i is used in the for-loop.

#2 (is range the expected range) can be handled by assuming it is, and
keeping a guard for the case that it isn't. That's what FAT Python will do.
I think PyPy does something similar.

I don't have an intuition on how hard #3 (does the loop body have any
side-effects that might affect this optimization?) might be, except to say
that the presence of an eval or exec inside the body will probably make the
optimization unsafe.

It wouldn't surprise me if the unmaintained but still working Psycho project
handled this, as well as such newer projects as pyjion, pyston, numba and
theano.

Bart, possibly something you have missed in this discussion: many of the
optimizations you are surprised not to see are not, and may never be, in
the vanilla Python language. But they are being included in language
add-ons. There is a thriving, experimental but still usable, culture of JIT
compilers for Python. Here is one of the oldest:

http://www.ibm.com/developerworks/library/l-psyco/index.html


Pyscho is unmaintained and doesn't work on anything better than 2.6, but the
author has gone on to be one of the lead devs in PyPy, and it has inspired
newer projects like numba and theano. The attitude of the core developers,
especially Guido, is that the reference interpreter CPython should stick to
only the easiest, least controversial optimizations (if any!) and leave the
hard ones to third-party add-ons.


-- 
Steven

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

Re: Effects of caching frequently used objects, was Re: Explaining names vs variables in Python

[Ethan Furman]

On 03/25/2016 06:03 AM, Albert-Jan Roskam wrote:
> Somebody wrote:
>> Somebody else wrote:


I know Python does not have variables, but names.
Multiple names cant then be bound to the same objects.

So this behavior

--> b = 234
--> v = 234
--> b is v
True

according to the above that is ok



But where is the consistency ? if I try :

--> v = 890
--> w = 890
--> v is w
False

It is a little difficult to explain this behavior to a newcommer in Python

Can someone give me the right argument to expose ?


You should not bother with object identity for objects other than None.


No.  The correct answer is: if identity is important either ensure the 
object you are getting back is a singleton (such as None, True, an Enum 
member, etc.) or you assign one name from another name:


--> b = 234
--> v = b
--> b is v
True
--> v = 890
--> w = v
--> v is w
True

If identity is not important, don't use `is`.


A little late to the party, but: how about Ellipsis? Shouldn't "is" also be 
used for that one? (It's rare, I know :))


Ellipsis is a singleton, so `is` is fine.

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

Re: Undefined behaviour in C [was Re: The Cost of Dynamism]

[Marko Rauhamaa]

Steven D'Aprano :

> Undefined behaviour in C is a minefield waiting to blow your program's
> legs off, because the designers of the language made the explicit
> choice that they wanted the language to be as fast and efficient as
> possible, even at the cost of safe, reproducible behaviour.

Yes, although the same could be true for Python as well.

For example, you could have this program:

===begin poof.py
assert 1 < 0
===end poof.py==

When it is run, you might see this:


$ python3 poof.py
python3: the VM vanished in a puff of logic while executing 'poof.py'


Java's Hotspot produces very aggressive optimizations, essentially
identifying bugs in the code and deducing the coder knows the bugs will
never be realized at runtime and so the code paths that lead to the bug
can be removed.


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

Re: [OT'ish] Is there a list as good as this for Javascript

[Cousin Stanley]

> Occasionally I have to make forays into Javascript, 
> can anyone recommend a place similar to this list 
> where Javascript questions can be asked ?


  Several years back I found 
  the newsgroup comp.lang.javascript
  to be helpful 

  However, I haven't used that group
  for some time now so don't know
  the current nature of the group 


-- 
Stanley C. Kitching
Human Being
Phoenix, Arizona
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT'ish] Is there a list as good as this for Javascript

[Ben Bacarisse]

Cousin Stanley  writes:

> 
>> Occasionally I have to make forays into Javascript, 
>> can anyone recommend a place similar to this list 
>> where Javascript questions can be asked ?
> 
>
>   Several years back I found 
>   the newsgroup comp.lang.javascript
>   to be helpful 

Still going.  It can't hurt to try.

>   However, I haven't used that group
>   for some time now so don't know
>   the current nature of the group 

I suspect some people are put off answering because there's a poster
whose main pleasure seems to be to nit-pick other people's answers (and
the OP will be told there's no "Javascript" for starters!).  The usual
Usenet thick skin advised.

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

Adding run_in_executor task to already existing loop.

[Ray Cote]

Hello:

I’m trying to perform an synchronous task while using asyncio.
I understand the solution is to use run_in_executor.
I’m not clear on how to add this into an already running event loop.

I’ve found lots of examples showing how to set up a loop and run this, but
I’m blocked in regards to doing this when the loop is already established.


Example code:

def blocking_func(param1):
# call the blocking call here.
return results

async def process_request():
loop = asyncio.get_event_loop()
block = loop.run_in_executor(None, blocking_func, “hello”)
results = await loop.run_until_complete(asyncio.gather(*[block, ])

The above code says “loop already running.” because we’re already in an
async ask that has been awaited. What is the proper method of adding in
this new synchronous task?

Regards
—Ray
-- 
Raymond Cote, President
voice: +1.603.924.6079 email: rgac...@appropriatesolutions.com skype:
ray.cote
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Adding run_in_executor task to already existing loop.

[Zachary Ware]

On Fri, Mar 25, 2016 at 3:24 PM, Ray Cote
 wrote:
> Hello:
>
> I’m trying to perform an synchronous task while using asyncio.
> I understand the solution is to use run_in_executor.
> I’m not clear on how to add this into an already running event loop.
>
> I’ve found lots of examples showing how to set up a loop and run this, but
> I’m blocked in regards to doing this when the loop is already established.
>
>
> Example code:
>
> def blocking_func(param1):
> # call the blocking call here.
> return results
>
> async def process_request():
> loop = asyncio.get_event_loop()
> block = loop.run_in_executor(None, blocking_func, “hello”)
> results = await loop.run_until_complete(asyncio.gather(*[block, ])
>
> The above code says “loop already running.” because we’re already in an
> async ask that has been awaited. What is the proper method of adding in
> this new synchronous task?

I'm assuming you're doing `await process_request()` elsewhere, which
is what's producing your error: you're trying to start the loop within
a coroutine running on that loop.  loop.run_in_executor() returns a
Future just like any other coroutine, so process_request just needs
this:

   async def process_request():
   loop = asyncio.get_event_loop()
   results = await loop.run_in_executor(None, blocking_func, 'hello')

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

Re: Adding run_in_executor task to already existing loop.

[Marko Rauhamaa]

Ray Cote :

> I’m trying to perform an synchronous task while using asyncio.

You seem to want to do something you shouldn't be doing. Asyncio does
not tolerate synchronous/blocking calls. You will need to move those in
separate threads or processes if you can't turn them into asynchronous
tasks.


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

Re: Adding run_in_executor task to already existing loop.

[Zachary Ware]

On Fri, Mar 25, 2016 at 3:56 PM, Marko Rauhamaa  wrote:
> Ray Cote :
>
>> I’m trying to perform an synchronous task while using asyncio.
>
> You seem to want to do something you shouldn't be doing. Asyncio does
> not tolerate synchronous/blocking calls. You will need to move those in
> separate threads or processes if you can't turn them into asynchronous
> tasks.

That's exactly what run_in_executor does.

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

Re: Adding run_in_executor task to already existing loop.

[Ray Cote]

On Fri, Mar 25, 2016 at 5:00 PM, Zachary Ware  wrote:

> I'm assuming you're doing `await process_request()` elsewhere, which
> is what's producing your error: you're trying to start the loop within
> a coroutine running on that loop.  loop.run_in_executor() returns a
> Future just like any other coroutine, so process_request just needs
> this:
>
>async def process_request():
>loop = asyncio.get_event_loop()
>results = await loop.run_in_executor(None, blocking_func, 'hello')
>

Yes, that was precisely the directive I needed. This is now working
perfectly.
Thanks
—Ray



-- 
Raymond Cote, President
voice: +1.603.924.6079 email: rgac...@appropriatesolutions.com skype:
ray.cote
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[Mark Lawrence]

On 25/03/2016 02:49, Michael Torrie wrote:



I've been trying to follow things on this thread, and I understand a bit
about Pythonic ideomatic style and I know what Python is really good at
and some of what it's not so good at, but it seems like one of Bart's
original contentions was that given a certain problem, coded in a
non-pythonic way, got slower under Python 3 than it was under Python 2
(if I recall correctly).  In other words a performance regression.
Somehow this seems to have gotten lost in the squabble over how one
should use Python.



Python 3 is slower, period.  The devs are trying to grab some of that 
back.  I'd still say that the additions in Python 3, many of which were 
backported to 2.6/7, were worth this regression.


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

Re: [OT'ish] Is there a list as good as this for Javascript

[Thomas 'PointedEars' Lahn]

c...@isbd.net wrote:

> Occasionally I have to make forays into Javascript, can anyone
> recommend a place similar to this list where Javascript questions can
> be asked?  The trouble is that there are very many usenet Javascript
> lists and it's difficult to guess which one[es] might be good.

There is no Javascript. 

There are no Usenet lists.

This is not only a Python *mailing* list, it is also mirrored as an 
international Usenet _newsgroup_,  (which I am 
reading).

If you can accept all of that, then the international Usenet _newsgroup_ 
 (where I am posting primarily) is for you.
So are other national/language-specific newsgroups on the JavaScripts and 
other ECMAScript implementations.  In your newsreader, search for newsgroups 
whose name contains “javascript”.

Next time, read  and STFW first, and get a real name.

-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT'ish] Is there a list as good as this for Javascript

[Thomas 'PointedEars' Lahn]

Mark Lawrence wrote:

> […] It is so blatantly obvious that he knows precisely nothing about
> Python, but still the moderators on this list let him get away with it.

This is a mailing list?  It is moderated?  *Seriously*?

-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Undefined behaviour in C [was Re: The Cost of Dynamism]

[Chris Angelico]

On Sat, Mar 26, 2016 at 2:50 AM, Steven D'Aprano  wrote:
> On Fri, 25 Mar 2016 06:54 am, BartC wrote:
>
>>> In the case of C, the line is limited to working with some specific type
>>> (say, an int32). Even there, if the addition might overflow, the
>>> behaviour is undefined and the compiler can do anything it wants
>>> (including time travel,
>>
>> I'm pretty sure it can't do time travel...
>>
>>   or erasing your hard disk).
>
>
> You are absolutely, and potentially catastrophically, mistaken on that.
>
> Undefined behaviour does not mean "implementation specific behaviour". Nor
> does it mean "something sensible will happen but we don't promise what it
> will be". It means "the compiler can do anything", including ignoring the
> code you actually wrote and substituting its own faster code, which may or
> may not do what your original code did.

C's undefined behaviour is basically "you're not allowed to do this".
The compiler is free to assume that you will never do this, ergo it is
free to write out machine code that is correct only so long as you do
not do this. Let me draw a Python analogy:

1) A well-behaved iterator will return values until it raises
StopIteration, and then raise StopIteration thereafter.
2) An iterator which raises and then returns is thus badly written and
should not exist.
3) A consumer of an iterator is allowed to misbehave in the event that
the iterator returns after raising.
4) Therefore an optimizer is free to *cause* the consumer to misbehave
when given an ill-behaved iterator.

Consider this code:

def zip_forever(*iters, fillvalue=None):
"""Like zip_longest, but without the silly rule that
it should terminate once they all finish"""
while True:
yield tuple(next(it, fillvalue) for it in iters)

If all its iterators are well-behaved, this is identical (modulo
monkey-patching of names like "tuple" and "next") to:

def zip_forever(*iters, fillvalue=None):
yield from zip_longest(*iters, fillvalue=fillvalue)
tup = (None,) * len(iters)
while True: yield tup

Is PyPy/FAT Python/some other optimizer permitted to make this change?
The only difference between C's "undefined behaviour" and Python's way
of doing the spec is the answer to that one question. C says yes,
you're totally allowed to assume that; the end result in all cases
should be indistinguishable; any time you can detect that it optimized
this away, it's because of a bug somewhere else. Is your code allowed
to misbehave when other code has bugs? That, ultimately, is the
question.

Imagine a tightened up subset of the Python language that restricts
certain unusual behaviours. (This has the same purpose as PyPy's
RPython, and for all I know, RPython might do exactly this.) It's a
narrowly-used single purpose language, and its sole guarantee is that
well-written SubPython code will behave the same way in SubPython as
it does in CPython. It might then, for instance, not permit rebinding
of builtins, nor of function default argument replacements, without an
explicit "drop_caches()" call. Code could then be far more
aggressively optimized - but behaviour would become undefined in the
event that you break one of its rules. That's really all that C's
done, and you honestly don't have to get so panicky at the word
"undefined". It's simply "don't do this".

And let's face it... there's a *lot* of undefined behaviour in CPython
once you play with ctypes. Do we have any language guarantees as to
what will happen if you change the value of the integer 7 to now be 8?
Or will you just say "don't do that"?

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

Re: WP-A: A New URL Shortener

[Thomas 'PointedEars' Lahn]

Chris Angelico wrote:

> […] Thomas 'PointedEars' Lahn […] wrote:
>> Chris Angelico wrote:
>>> […] Thomas 'PointedEars' Lahn […] wrote:
 Daniel Wilcox wrote:
> Cool thanks, highly recommended to use an ORM to deter easy SQL
> injections.
 That is to crack a nut with a sledgehammer.  SQL injection can be
 easily and more efficiently prevented with prepared statements.  […]
>>> You don't even need prepared statements. All you need is parameterized
>>> queries.
>> A prepared statement in this context uses a parameterized query.
>>
>> 

> 
> I know what a prepared statement is. And I know that they are
> effective. However they are overkill - as I said, you merely need
> parameterization.

Then enlighten me, please: How is “parameterization” or a “parameterized 
query”, as *you* understand it, different from a prepared statement?

-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: WP-A: A New URL Shortener

[Chris Angelico]

On Sat, Mar 26, 2016 at 8:28 AM, Thomas 'PointedEars' Lahn
 wrote:
> Chris Angelico wrote:
>
>> […] Thomas 'PointedEars' Lahn […] wrote:
>>> Chris Angelico wrote:
 […] Thomas 'PointedEars' Lahn […] wrote:
> Daniel Wilcox wrote:
>> Cool thanks, highly recommended to use an ORM to deter easy SQL
>> injections.
> That is to crack a nut with a sledgehammer.  SQL injection can be
> easily and more efficiently prevented with prepared statements.  […]
 You don't even need prepared statements. All you need is parameterized
 queries.
>>> A prepared statement in this context uses a parameterized query.
>>>
>>>
> 
>>
>> I know what a prepared statement is. And I know that they are
>> effective. However they are overkill - as I said, you merely need
>> parameterization.
>
> Then enlighten me, please: How is “parameterization” or a “parameterized
> query”, as *you* understand it, different from a prepared statement?

This is a prepared statement:

http://www.postgresql.org/docs/current/static/sql-prepare.html

You use a special "PREPARE" query to create *and store* a half-run
query, and then you execute it afterwards. Back in the 1990s, I had
the option of actually *compiling* my SQL queries as part of my C
code, which would prepare all the queries for future execution. It is
completely different from the dynamic parameterized queries that most
people use.

Parameterization is a more general concept which prepared statements
invariably use, but which general code need not use. A Python database
connector could choose to PREPARE/EXECUTE for every query it's given,
or it could choose to escape all the parameters and embed them, or it
could (if it's using a decent database back-end like PostgreSQL)
simply send the query and its associated parameters as-is. Only one of
these options is a "prepared statement". All three are "parameterized
queries", at least from the POV of Python code.

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

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[BartC]

On 25/03/2016 16:22, Steven D'Aprano wrote:

On Fri, 25 Mar 2016 10:06 pm, BartC wrote:


(OK, I'll risk the wrath of Mark Lawrence et al by daring to post my 
opinions.)



But it is an optimisation that /could/ be done by the byte-code compiler



I would also expect that Victor Stinner's FAT Python project will
(eventually) look at optimizing such for-loops too. If you see something
like:

for i in range(N):
 do_stuff()


and three conditions hold:

(1) i is unused in the loop body;

(2) range is still bound to the expected built-in function, and no
other "range" in a nearer scope (say, a local variable called "range", or a
global) exists to shadow it; and


The volatility of 'range' I'd completely forgotten about. Python really 
doesn't make this stuff easy, does it?


Checking this at runtime, per loop (I don't think it's necessary per 
iteration) is a possibility, but now an extra overhead is introduced. It 
might worth it if the body of the loop is also optimised, but this is 
getting into the territory covered by tracing JITs.


My kind of approach would try to keep it simple, and that would be 
helped tremendously by special language constructs (something like 
Ruby's 100.times) where you can use a streamlined loop, and possible

unrolling, straight off.

(Personally, if I was creating a byte-code intepreter for Python as-is, 
I would have a -dynamic:on or -dynamic:off switch.)



Here is one of the oldest:

http://www.ibm.com/developerworks/library/l-psyco/index.html


Yes, I tried that long ago. It's very fast on certain benchmarks. (Both 
psyco and pypy can run my lexer at around 170Klps. And this is code 
using string compares and long if-elif chains, that would be crazy in 
any other language. From that point of view, it's very impressive (I can 
only get half that speed using the same methods).


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

Re: WP-A: A New URL Shortener

[Thomas 'PointedEars' Lahn]

Chris Angelico wrote:

> On Sat, Mar 26, 2016 at 8:28 AM, Thomas 'PointedEars' Lahn
>  wrote:
>> Chris Angelico wrote:
>>> […] Thomas 'PointedEars' Lahn […] wrote:
 Chris Angelico wrote:
> […] Thomas 'PointedEars' Lahn […] wrote:
>> Daniel Wilcox wrote:
>>> Cool thanks, highly recommended to use an ORM to deter easy SQL
>>> injections.
>> That is to crack a nut with a sledgehammer.  SQL injection can be
>> easily and more efficiently prevented with prepared statements.  […]
> You don't even need prepared statements. All you need is parameterized
> queries.
 A prepared statement in this context uses a parameterized query.


>> 

>>>
>>> I know what a prepared statement is. And I know that they are
>>> effective. However they are overkill - as I said, you merely need
>>> parameterization.
>>
>> Then enlighten me, please: How is “parameterization” or a “parameterized
>> query”, as *you* understand it, different from a prepared statement?
> 
> This is a prepared statement:
> 
> http://www.postgresql.org/docs/current/static/sql-prepare.html
> 
> You use a special "PREPARE" query to create *and store* a half-run
> query,

[Having written a database layer (in PHP) myself, I know what a prepared 
statement is, thank you very much.]

Your statement is incorrect both for MySQL (which I know) and PostgreSQL 
(AIUI your reference): The query is processed and stored of course, but it 
is definitely _not_ *run* before the EXECUTE command is issued for it.

> and then you execute it afterwards.

In both DMBSs, the query/statement is filled with parameter values and then 
executed not before, and then only if and when, one issues the EXECUTE 
statement for it.

> Back in the 1990s, I had the option of actually *compiling* my SQL queries
> as part of my C code, which would prepare all the queries for future
> execution. It is completely different from the dynamic parameterized
> queries that most people use.

Interesting, but irrelevant.
 
> Parameterization is a more general concept which prepared statements
> invariably use, but which general code need not use.

If it is to be safe from SQL injection, it better uses a parameterized query 
as it is *commonly* understood.

> A Python database connector could choose to PREPARE/EXECUTE for every
> query it's given,

That would not be wise, given that not every query contains variable 
parameters.

> or it could choose to escape all the parameters and embed them,

Recommended against, and not a parameterized query at all.

> or it could (if it's using a decent database back-end like PostgreSQL)
> simply send the query and its associated parameters as-is. Only one of
> these options is a "prepared statement".

Maybe.  I do not know enough about PostgreSQL and its “[sending] the query 
and its associated parameters as-is” yet to confirm or deny this.

> All three are "parameterized queries", at least from the POV of Python
> code.

You are mistaken, then: Of the three kinds of “parameterized queries” as 
*you* understand them (OWASP and I beg to differ), at least one of them
that is not used in a prepared statement is *insufficient to prevent SQL 
injection*.

The second kind also moves tasks to the programming language that are better 
done by the DBMS; the program code should database-agnostic (in the best 
case, for mockup testing, even oblivious of the database).

Which is why programming languages have come to support prepared statements, 
and why OWASP recommends to use either them or stored procedures.

-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.y
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: WP-A: A New URL Shortener

[Chris Angelico]

On Sat, Mar 26, 2016 at 9:25 AM, Thomas 'PointedEars' Lahn
 wrote:
> Chris Angelico wrote:
>
>> On Sat, Mar 26, 2016 at 8:28 AM, Thomas 'PointedEars' Lahn
>>  wrote:
>>> Chris Angelico wrote:
 […] Thomas 'PointedEars' Lahn […] wrote:
> Chris Angelico wrote:
>> […] Thomas 'PointedEars' Lahn […] wrote:
>>> Daniel Wilcox wrote:
 Cool thanks, highly recommended to use an ORM to deter easy SQL
 injections.
>>> That is to crack a nut with a sledgehammer.  SQL injection can be
>>> easily and more efficiently prevented with prepared statements.  […]
>> You don't even need prepared statements. All you need is parameterized
>> queries.
> A prepared statement in this context uses a parameterized query.
>
>
>>>
> 

 I know what a prepared statement is. And I know that they are
 effective. However they are overkill - as I said, you merely need
 parameterization.
>>>
>>> Then enlighten me, please: How is “parameterization” or a “parameterized
>>> query”, as *you* understand it, different from a prepared statement?
>>
>> This is a prepared statement:
>>
>> http://www.postgresql.org/docs/current/static/sql-prepare.html
>>
>> You use a special "PREPARE" query to create *and store* a half-run
>> query,
>
> [Having written a database layer (in PHP) myself, I know what a prepared
> statement is, thank you very much.]
>
> Your statement is incorrect both for MySQL (which I know) and PostgreSQL
> (AIUI your reference): The query is processed and stored of course, but it
> is definitely _not_ *run* before the EXECUTE command is issued for it.

It legal to partly perform the query. DB2 can retain a "query plan"
which consists of the exact paths it will follow. So I stand by my
statement.

>> Back in the 1990s, I had the option of actually *compiling* my SQL queries
>> as part of my C code, which would prepare all the queries for future
>> execution. It is completely different from the dynamic parameterized
>> queries that most people use.
>
> Interesting, but irrelevant.

Not really, no. It was a form of PREPARE/EXECUTE that hid the PREPARE
behind a convenient syntax, and then replaced it with EXECUTE for the
run-time.

>> Parameterization is a more general concept which prepared statements
>> invariably use, but which general code need not use.
>
> If it is to be safe from SQL injection, it better uses a parameterized query
> as it is *commonly* understood.

Why? All it needs to do is guarantee that no user data can affect the
query. There are myriad ways to do that, and prepared statements are
only one of them. Even parameterization is not strictly necessary, as
long as the escaping is perfect. (Though that does have its own
consequences, and is not recommended.)

>> A Python database connector could choose to PREPARE/EXECUTE for every
>> query it's given,
>
> That would not be wise, given that not every query contains variable
> parameters.

Irrelevant. It would still be legal. Do you understand the difference
between what is legal according to a specification and what is
actually worth doing? In an explanation of what a parameterized query
is, I would expect to be discussing what is semantically and
functionally valid, not which optimizations are worth doing.

>> or it could choose to escape all the parameters and embed them,
>
> Recommended against, and not a parameterized query at all.

Not once it reaches the underlying database, but it is parameterized
in the source code. It's not possible for an external attacker to get
past the escaping, if it is done correctly. It is still legal,
however, it is indeed not recommended.

>> or it could (if it's using a decent database back-end like PostgreSQL)
>> simply send the query and its associated parameters as-is. Only one of
>> these options is a "prepared statement".
>
> Maybe.  I do not know enough about PostgreSQL and its “[sending] the query
> and its associated parameters as-is” yet to confirm or deny this.

The wire protocol supports this.

>> All three are "parameterized queries", at least from the POV of Python
>> code.
>
> You are mistaken, then: Of the three kinds of “parameterized queries” as
> *you* understand them (OWASP and I beg to differ), at least one of them
> that is not used in a prepared statement is *insufficient to prevent SQL
> injection*.

Okay, then. Please explain how this code is vulnerable to SQL injection:

conn = some_db_module.connect("")
cur = conn.cursor()
data = input("Enter a value: ")
cur.execute("insert into some_table (some_column) values (%s)", (input,))
conn.commit()

Do you need to know the implementation of cur.execute to be able to
say whether this is safe, or can you be confident that, short of
really blatantly obvious bugs in the database connector, this is
genuinely a parameterized query? I posit that the latter is the case.

Re: [OT'ish] Is there a list as good as this for Javascript

[Ned Batchelder]

On Friday, March 25, 2016 at 5:17:21 PM UTC-4, Thomas 'PointedEars' Lahn wrote:
> c...@isbd.net wrote:
> 
> > Occasionally I have to make forays into Javascript, can anyone
> > recommend a place similar to this list where Javascript questions can
> > be asked?  The trouble is that there are very many usenet Javascript
> > lists and it's difficult to guess which one[es] might be good.
> 
> There is no Javascript. 
> 
> There are no Usenet lists.
> 
> This is not only a Python *mailing* list, it is also mirrored as an 
> international Usenet _newsgroup_,  (which I am 
> reading).
> 
> If you can accept all of that, then the international Usenet _newsgroup_ 
>  (where I am posting primarily) is for you.
> So are other national/language-specific newsgroups on the JavaScripts and 
> other ECMAScript implementations.  In your newsreader, search for newsgroups 
> whose name contains "javascript".
> 
> Next time, read  and STFW first, and get a real name.

Chris, I apologize for Thomas.  His main goal on this list seems to be
pointing out when people are wrong, over the smallest details.  His
secondary goal is enforcing some imaginary rule about real names, though
he couldn't be bothered to read your post thoroughly enough to discover yours.

Thomas is not typical of the Python community. We are mostly nice people. :)

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

Re: [OT'ish] Is there a list as good as this for Javascript

[Thomas 'PointedEars' Lahn]

Ned Batchelder wrote:

> Chris, I apologize for Thomas.

How dare you to speak for me, and *again* the rest of the subscribers?  
There is nothing to apologize for when I am *helping* someone by giving them 
useful information.  You can apologize for your own presumptous behavior 
instead.

> is main goal on this list seems to be pointing out when people are wrong, 
> over the smallest details.

Certainly I point out when people are wrong.   That is how we develop 
*knowledge*.  For that it does not matter of you in your blissful ignorance 
think that those are “smallest details”, which they are not.  The underlying 
process is called *learning*.  You should try it sometime.

> His secondary goal is enforcing some imaginary rule about real names,

It is not an imaginary rule, it is a social convention that follows from 
another social convention, simple politeness.  When you are seeking the help 
of people that you do not know, there is a principle of basic politeness 
saying that you should tell them who you are.  Especially if those people 
have already extended you the politeness to tell them who *they* are; like 
here, when you have read their names already.

Politeness is another thing you should try sometime, as I see that, your 
having no valid argument at all, you like to throw dirt instead.

> Thomas is not typical of the Python community. We are mostly nice people.
> :)

You do not even know me.  I *am* a nice person, if only for the fact that I 
do not let people suffer from their own ignorance, and I encourage them to 
educate and enlighten themselves in order not be dependent on people like 
you who tell them what they should think.

So *evidentially*, *you* are not a nice person.  According to your own 
"logic", *you* do not belong in the Python community.  Go away.

-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Problem With Embedded Icon and Python 3.4

[Mark Lawrence]

On 25/03/2016 05:10, Wildman via Python-list wrote:

I have a program that I have been trying to rewrite so it will
run on Python 2.7 and 3.4.


This http://pythonhosted.org/six/ might come in handy in future.

As I'm also climbing the tkinter cliff at the moment I've found anything 
on stackoverflow from Bryan Oakley to be very helpful. In particular, 
his answer here 
http://stackoverflow.com/questions/17466561/best-way-to-structure-a-tkinter-application 
really helped me get a grip on things.


A lot of the examples here http://pyinmyeye.blogspot.co.uk/ were also 
useful.


HTH.

--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

Re: [OT'ish] Is there a list as good as this for Javascript

[Steven D'Aprano]

On Sat, 26 Mar 2016 08:17 am, PointedEars wrote:
..^^^

> get a real name.

You sign your posts "PointedEars". Do you not realise how hypocritical these
repeated carping complaints about "real names" are? 

Not to mention pointless. Aside from the fact that "real name" is
subjective, you have no idea what is someone's real name and what isn't.


Nobody appointed you as Real Name Sheriff. Just give it up.



-- 
Steven

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

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[Steven D'Aprano]

On Sat, 26 Mar 2016 09:08 am, BartC wrote:

> On 25/03/2016 16:22, Steven D'Aprano wrote:
>> On Fri, 25 Mar 2016 10:06 pm, BartC wrote:
> 
> (OK, I'll risk the wrath of Mark Lawrence et al by daring to post my
> opinions.)

Please ignore Mark Lawrence when he is acting as an obnoxious troll, as he
is now. He occasionally has something useful or helpful to say, but most of
the time he thinks he is the self-appointed Guardian of Python's Honour, a
job he is singularly ill-equipped for even if Python's honour needed
defending, which it doesn't.


>>> But it is an optimisation that /could/ be done by the byte-code compiler
> 
>> I would also expect that Victor Stinner's FAT Python project will
>> (eventually) look at optimizing such for-loops too. If you see something
>> like:
>>
>> for i in range(N):
>>  do_stuff()
>>
>>
>> and three conditions hold:
>>
>> (1) i is unused in the loop body;
>>
>> (2) range is still bound to the expected built-in function, and no
>> other "range" in a nearer scope (say, a local variable called "range", or
>> a global) exists to shadow it; and
> 
> The volatility of 'range' I'd completely forgotten about. Python really
> doesn't make this stuff easy, does it?

True. But it makes *other things* much more easy. Things which are
impossible or very difficult in other, stricter languages are trivially
easy in Python.



> Checking this at runtime, per loop (I don't think it's necessary per
> iteration) is a possibility, but now an extra overhead is introduced. It
> might worth it if the body of the loop is also optimised, but this is
> getting into the territory covered by tracing JITs.

Detecting whether or not range has been shadowed or replaced doesn't need a
full tracing JIT. Victor's work isn't complete, but preliminary results
suggest strongly that the overhead of checking guards will be
insignificant.


> My kind of approach would try to keep it simple, and that would be
> helped tremendously by special language constructs (something like
> Ruby's 100.times) where you can use a streamlined loop, and possible
> unrolling, straight off.

Ruby is an interesting case, because Ruby is even more dynamic than Python.
Python doesn't allow you to replace or add methods to built-ins, but Ruby
does, so in principle, you have no idea what 100.times is going to do until
runtime. That's no different from Python and range.

Up until a few years ago, Ruby was considered even slower than Python, by a
factor of two or five or so. I'm lead to believe that the latest version of
Ruby reverses that, and I've seen claims that it is now faster than Python,
but I haven't seen it for myself so I'm not sure if I believe it entirely.


> (Personally, if I was creating a byte-code intepreter for Python as-is,
> I would have a -dynamic:on or -dynamic:off switch.)
> 
>> Here is one of the oldest:
>>
>> http://www.ibm.com/developerworks/library/l-psyco/index.html
> 
> Yes, I tried that long ago. It's very fast on certain benchmarks. (Both
> psyco and pypy can run my lexer at around 170Klps. And this is code
> using string compares and long if-elif chains, that would be crazy in
> any other language. From that point of view, it's very impressive (I can
> only get half that speed using the same methods).

The Python philosophy seems to prefer the use of specialist JIT compilers to
speed up bottlenecks rather than language features. I've seen Guido comment
that he doesn't believe static AOT optimization is worthwhile in Python and
that people should concentrate on JIT optimizations. I suspect he's right.



-- 
Steven

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

Re: Problem With Embedded Icon and Python 3.4

[Wildman via Python-list]

On Sat, 26 Mar 2016 01:42:37 +, Mark Lawrence wrote:

> On 25/03/2016 05:10, Wildman via Python-list wrote:
>> I have a program that I have been trying to rewrite so it will
>> run on Python 2.7 and 3.4.
> 
> This http://pythonhosted.org/six/ might come in handy in future.
> 
> As I'm also climbing the tkinter cliff at the moment I've found anything 
> on stackoverflow from Bryan Oakley to be very helpful. In particular, 
> his answer here 
> http://stackoverflow.com/questions/17466561/best-way-to-structure-a-tkinter-application
>  
> really helped me get a grip on things.
> 
> A lot of the examples here http://pyinmyeye.blogspot.co.uk/ were also 
> useful.
> 
> HTH.

Thanks for the links.  Good stuff.  Bookmarked.

-- 
 GNU/Linux user #557453
The cow died so I don't need your bull!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Undefined behaviour in C [was Re: The Cost of Dynamism]

[Steven D'Aprano]

On Sat, 26 Mar 2016 03:57 am, Marko Rauhamaa wrote:

> Steven D'Aprano :
> 
>> Undefined behaviour in C is a minefield waiting to blow your program's
>> legs off, because the designers of the language made the explicit
>> choice that they wanted the language to be as fast and efficient as
>> possible, even at the cost of safe, reproducible behaviour.
> 
> Yes, although the same could be true for Python as well.

Is this a philosophical question? Yes, it *could* be true, in some alternate
universe, but it isn't actually true.

Python does not have undefined behaviour in the C sense. Like any language
which doesn't have a formal IEEE standard behind it (and even some that
do), it has implementation-specific behaviour, or under- or unspecified
behaviour. But that is not the same as C Undefined Behaviour. Please read
the links I gave.

Culturally, C compiler writers have a preference for using undefined
behaviour to allow optimizations, even if it means changing the semantics
of your code. The C compiler is allowed to ignore your code, move it around
so that things happen in a different order, or add its own code, even if
that changes the semantics of the code.

Python has nothing even remotely like that. If you shoot yourself in the
foot with Python, you can say it is because you didn't understand what your
code would do, but you can't say it is because Python moved code around to
execute it in an unexpected order, or ignored it.



> For example, you could have this program:
> 
> ===begin poof.py
> assert 1 < 0
> ===end poof.py==

The semantics of "assert condition" are equivalent to:


if __debug__:
if not condition:
raise AssertionError


so assert is intentionally a no-op when Python runs with debug mode disabled
(the -O command-line switch).


 
> When it is run, you might see this:
> 
> 
> $ python3 poof.py
> python3: the VM vanished in a puff of logic while executing 'poof.py'
> 

I assume that the "vanished" quip is your editorial. Otherwise, the only way
to get that result would be if you linked the python3 executable to
something other than Python 3.

There are only two behaviours a conforming Python interpreter can do
with "poof.py":

- by default, it must raise AssertionError;

- if run with optimizations switched on (debugging mode turned off), 
  it must do nothing.


Anything else would be a bug in the interpreter or compiler.




-- 
Steven

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

Re: Undefined behaviour in C [was Re: The Cost of Dynamism]

[Random832]

On Fri, Mar 25, 2016, at 22:46, Steven D'Aprano wrote:
> Culturally, C compiler writers have a preference for using undefined
> behaviour to allow optimizations, even if it means changing the semantics
> of your code. The C compiler is allowed to ignore your code, move it
> around
> so that things happen in a different order, or add its own code, even if
> that changes the semantics of the code.

Er, the point of undefined behavior is that your code doesn't *have*
semantics.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Undefined behaviour in C [was Re: The Cost of Dynamism]

[Paul Rubin]

Steven D'Aprano  writes:
> Culturally, C compiler writers have a preference for using undefined
> behaviour to allow optimizations, even if it means changing the semantics
> of your code. 

If your code has UB then by definition it has no semantics to change.
Code with UB has no meaning.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT'ish] Is there a list as good as this for Javascript

[Chris Angelico]

On Sat, Mar 26, 2016 at 12:36 PM, Thomas 'PointedEars' Lahn
 wrote:
>> Thomas is not typical of the Python community. We are mostly nice people.
>> :)
>
> You do not even know me.  I *am* a nice person, if only for the fact that I
> do not let people suffer from their own ignorance, and I encourage them to
> educate and enlighten themselves in order not be dependent on people like
> you who tell them what they should think.
>
> So *evidentially*, *you* are not a nice person.  According to your own
> "logic", *you* do not belong in the Python community.  Go away.

King Gama is a nicer person than you are, and in very similar ways.

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

Re: WP-A: A New URL Shortener

[Thomas 'PointedEars' Lahn]

Chris Angelico wrote:

> On Sat, Mar 26, 2016 at 9:25 AM, Thomas 'PointedEars' Lahn
>  wrote:

Attribution line, not attribution novel.

>> Chris Angelico wrote:
>>> On Sat, Mar 26, 2016 at 8:28 AM, Thomas 'PointedEars' Lahn
>>>  wrote:
 Then enlighten me, please: How is “parameterization” or a
 “parameterized query”, as *you* understand it, different from a
 prepared statement?
>>>
>>> This is a prepared statement:
>>>
>>> http://www.postgresql.org/docs/current/static/sql-prepare.html
>>>
>>> You use a special "PREPARE" query to create *and store* a half-run
>>> query,
>>
>> [Having written a database layer (in PHP) myself, I know what a prepared
>> statement is, thank you very much.]
>>
>> Your statement is incorrect both for MySQL (which I know) and PostgreSQL
>> (AIUI your reference): The query is processed and stored of course, but
>> it is definitely _not_ *run* before the EXECUTE command is issued for it.
> 
> It legal to partly perform the query.

What are you getting at?  A query cannot be performed if the values of its 
parameters have no defined value yet.

> DB2 can retain a "query plan" which consists of the exact paths it will
> follow. So I stand by my statement.

A query plan is _not_ the *execution* (“run”) of a query, but the result of 
*processing* a query (AISB).  So you are still wrong.
 
>>> Back in the 1990s, I had the option of actually *compiling* my SQL
>>> queries as part of my C code, which would prepare all the queries for
>>> future execution. It is completely different from the dynamic
>>> parameterized queries that most people use.
>> Interesting, but irrelevant.
> 
> Not really, no. It was a form of PREPARE/EXECUTE that hid the PREPARE
> behind a convenient syntax, and then replaced it with EXECUTE for the
> run-time.

IOW, a prepared statement.  Thanks for the confirmation.
 
>>> Parameterization is a more general concept which prepared statements
>>> invariably use, but which general code need not use.
>>
>> If it is to be safe from SQL injection, it better uses a parameterized
>> query as it is *commonly* understood.
> 
> Why? […]

Far beyond the scope of this newsgroup/mailing list.  RTFM I referred to.

>>> A Python database connector could choose to PREPARE/EXECUTE for every
>>> query it's given,
>> That would not be wise, given that not every query contains variable
>> parameters.
> 
> Irrelevant. It would still be legal. Do you understand the difference
> between what is legal according to a specification and what is
> actually worth doing?

Red herring.  Legality (better: validity) was not the issue.  Whether 
legal/valid code or or not, it would still not be wise because application 
performance would be reduced at little advantage, if any.

>>> or it could choose to escape all the parameters and embed them,
>> Recommended against, and not a parameterized query at all.
> 
> Not once it reaches the underlying database,

And that is not how “parameterized query” is commonly defined.

>>> All three are "parameterized queries", at least from the POV of Python
>>> code.
>> You are mistaken, then: Of the three kinds of “parameterized queries” as
>> *you* understand them (OWASP and I beg to differ), at least one of them
>> that is not used in a prepared statement is *insufficient to prevent SQL
>> injection*.
> 
> Okay, then. Please explain how this code is vulnerable to SQL injection:
> 
> conn = some_db_module.connect("")
> cur = conn.cursor()
> data = input("Enter a value: ")
 ^
> cur.execute("insert into some_table (some_column) values (%s)", (input,))
   ^
> conn.commit()

This code is not vulnerable to SQL injection, unless “input” referred to an 
object that had both a suitable __call__() or __init__(), and __str__() 
method ;->

Probably you meant

#---
conn = some_db_module.connect("")
cur = conn.cursor()
data = input("Enter a value: ")
cur.execute("insert into some_table (some_column) values (%s)", (data,))
conn.commit()
#---

Since nothing indicates the used module and accessed DBMS (only that, if it 
is Python code, the module cannot be sqlite3 as that does not support “%s”), 
then this code can, if the module uses an escaping mechanism, still be 
vulnerable to SQL injection.  For example, I could input something to the 
effect of

#---
data = r'\"); DROP TABLE some_table; --'
#---

if, for example, the string escaping mechanism in the module would simply 
duplicate any double-quote it finds to escape it in the string literal that 
it created (as is possible in MySQL and PostgreSQL), and still inject my 
code because the resulting query would be

  insert into some_table (some_column) v

Re: [OT'ish] Is there a list as good as this for Javascript

[Thomas 'PointedEars' Lahn]

Chris Angelico wrote:

> On Sat, Mar 26, 2016 at 12:36 PM, Thomas 'PointedEars' Lahn
>  wrote:
>>> Thomas is not typical of the Python community. We are mostly nice
>>> people.
>>> :)
>>
>> You do not even know me.  I *am* a nice person, if only for the fact that
>> I do not let people suffer from their own ignorance, and I encourage them
>> to educate and enlighten themselves in order not be dependent on people
>> like you who tell them what they should think.
>>
>> So *evidentially*, *you* are not a nice person.  According to your own
>> "logic", *you* do not belong in the Python community.  Go away.
> 
> King Gama is a nicer person than you are, and in very similar ways.

I do not know a person called “King Gama”, I do not think I need to know 
them, I do not think that he is on-topic here either, and I think that you 
should keep in mind that this is not a niceness contest, but a technical 
newsgroup/mailing list.  I for one prefer a direct, if blunt, correct answer 
over a nice, evading or incorrect one any time.

See also: 


F'up2 poster

-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: WP-A: A New URL Shortener

[Chris Angelico]

On Sat, Mar 26, 2016 at 2:30 PM, Thomas 'PointedEars' Lahn
 wrote:
> Since nothing indicates the used module and accessed DBMS (only that, if it
> is Python code, the module cannot be sqlite3 as that does not support “%s”),
> then this code can, if the module uses an escaping mechanism, still be
> vulnerable to SQL injection.  For example, I could input something to the
> effect of
>
> #---
> data = r'\"); DROP TABLE some_table; --'
> #---
>
> if, for example, the string escaping mechanism in the module would simply
> duplicate any double-quote it finds to escape it in the string literal that
> it created (as is possible in MySQL and PostgreSQL), and still inject my
> code because the resulting query would be
>
>   insert into some_table (some_column) values ("\"");
>   DROP TABLE some_table;
>   --")
>
> which is at least syntactically valid MySQL code, but from the perspective
> of the so-attacked it is still not fine as the table would be gone
> afterwards.

In other words, you are assuming that the string escaping *in the
module* is buggy. Well, duh. This is exactly what I said about not
having stupid bugs. The developer of a MySQL binding library should
know the *entire* rules for escaping, and, duh, that's going to
include escaping the backslash. So the escaped query would be
something like:

  insert into some_table (some_column) values ("\\"");
  DROP TABLE some_table;
  --")

which would be interpreted correctly by MySQL.

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

Re: [OT'ish] Is there a list as good as this for Javascript

[Chris Angelico]

On Sat, Mar 26, 2016 at 2:37 PM, Thomas 'PointedEars' Lahn
 wrote:
> Chris Angelico wrote:
>
>> On Sat, Mar 26, 2016 at 12:36 PM, Thomas 'PointedEars' Lahn
>>  wrote:
 Thomas is not typical of the Python community. We are mostly nice
 people.
 :)
>>>
>>> You do not even know me.  I *am* a nice person, if only for the fact that
>>> I do not let people suffer from their own ignorance, and I encourage them
>>> to educate and enlighten themselves in order not be dependent on people
>>> like you who tell them what they should think.
>>>
>>> So *evidentially*, *you* are not a nice person.  According to your own
>>> "logic", *you* do not belong in the Python community.  Go away.
>>
>> King Gama is a nicer person than you are, and in very similar ways.
>
> I do not know a person called “King Gama”, I do not think I need to know
> them, I do not think that he is on-topic here either, and I think that you
> should keep in mind that this is not a niceness contest, but a technical
> newsgroup/mailing list.  I for one prefer a direct, if blunt, correct answer
> over a nice, evading or incorrect one any time.
>
> See also: 
>
>
> F'up2 poster

Fine. You want a blunt answer?

You, Thomas, are not a nice person. You think you are, but you are
not. Be nicer or go away. Please.

Also, go look up King Gama, as he's from a source that the Pythons follow.

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

Re: [OT'ish] Is there a list as good as this for Javascript

[Rustom Mody]

On Saturday, March 26, 2016 at 9:55:15 AM UTC+5:30, Chris Angelico wrote:
> On Sat, Mar 26, 2016 at 2:37 PM, Thomas 'PointedEars' Lahn wrote:
> > Chris Angelico wrote:
> >
> >> On Sat, Mar 26, 2016 at 12:36 PM, Thomas 'PointedEars' Lahn wrote:
>  Thomas is not typical of the Python community. We are mostly nice
>  people.
>  :)
> >>>
> >>> You do not even know me.  I *am* a nice person, if only for the fact that
> >>> I do not let people suffer from their own ignorance, and I encourage them
> >>> to educate and enlighten themselves in order not be dependent on people
> >>> like you who tell them what they should think.
> >>>
> >>> So *evidentially*, *you* are not a nice person.  According to your own
> >>> "logic", *you* do not belong in the Python community.  Go away.
> >>
> >> King Gama is a nicer person than you are, and in very similar ways.
> >
> > I do not know a person called "King Gama", I do not think I need to know
> > them, I do not think that he is on-topic here either, and I think that you
> > should keep in mind that this is not a niceness contest, but a technical
> > newsgroup/mailing list.  I for one prefer a direct, if blunt, correct answer
> > over a nice, evading or incorrect one any time.
> >
> > See also: 
> >
> >
> > F'up2 poster
> 
> Fine. You want a blunt answer?
> 
> You, Thomas, are not a nice person. You think you are, but you are
> not. Be nicer or go away. Please.

"You think??"
I think you just failed the Turing test Chris 
Do admit it though...

Thomas 'juvenile' Lahn does a better job than Dihedral
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Undefined behaviour in C [was Re: The Cost of Dynamism]

[Rustom Mody]

On Friday, March 25, 2016 at 9:20:23 PM UTC+5:30, Steven D'Aprano wrote:
> 
> Undefined behaviour in C is a minefield waiting to blow your program's legs
> off, because the designers of the language made the explicit choice that
> they wanted the language to be as fast and efficient as possible, even at
> the cost of safe, reproducible behaviour.

Thats a nice polemic Steven
Ive been guilty of similar... which Ive subsequently tried to correct:
http://blog.languager.org/2013/02/c-in-education-and-software-engineering.html

For one thing its good to remember that we wouldn't be here without python
Python wouldn't be what it is without CPython
And the C there is the C you are talking of.

More pertinently this polemic misses the real culprit -- intel hardware.
40 years ago Dijkstra pointed out that software costs are variable;
hardware costs are fixed.
this results in this that programmers will increasingly skip a test that is
very skew.  If that same super-skew test were taken care of by hardware we
(programmers) wouldn't mind. [1]

To see this consider overflow error for integers and for floats.
Intel hardware catches float errors in hardware but not int errors
So language designers have the hobson choice of catching errors at huge cost
Or ignoring and (inviting programmers to ) creating flaky systems.

[1] Economics/financial considerations drive more than we imagine
https://www.facebook.com/EvolvePolitics/videos/1666350230283584/
-- 
https://mail.python.org/mailman/listinfo/python-list