Re: __debug__ http://stackoverflow.com/questions/15305688/conditional-debug-statement-not-executed-though-debug-is-true

[dieter]

Veek M  writes:

> Trying to make sense of that article. My understanding of debug was 
> simple:
> 1. __debug__ is always True, unless -O or -OO
> 2. 'if' is optimized out when True and the expr is inlined.
>
> So what does he mean by:
>
> 1. 'If you rebind __debug__, it can cause symptoms'
> 2. 'During module compilation, the same code that handles literals also 
> handles the magic constants ..., None, True, False, and __debug__'
> 3. 'you'll see that if __debug__: statements are either removed 
> entirely, or use LOAD_CONST to load the compile-time debug constant, 
> while if bool(__debug__): statements use LOAD_GLOBAL to load the value 
> of __debug__.'
>
> 4. 'Of course these are guaranteed to be the same… unless you rebind 
> __debug__'
>
> Basically every line in that answer is new to me..

It essentially tells you:
 
  "__debug__" has an internal use; only read it; never write (rebind) it.

The rest are the details explaining what can go wrong when you
write (rebind) "__debug__" and why.

The "why" comes essentially from the fact that in some (but not all)
cases "__debug__" is handled at compile time, while a potential
writing it handled at runtime. Thus, after you have changed "__debug__",
things may not work as you expect.


If you keep in mind "do not change the value of __debug__ at runtime", you
can forget all the details.

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

urllib.request giving unexpected results

[Steven D'Aprano]

I'm trying to download a file using urllib.request and pipe it straight to an 
external process. On Linux systems, the following is a test file that 
demonstrates the problem:


--- cut ---

#!/usr/bin/python3.5

import urllib.request
import subprocess

TEST_URL = 'https://www.irs.gov/pub/irs-prior/f1040--1864.pdf'

with urllib.request.urlopen(TEST_URL) as f:
data = subprocess.check_output(['file', '-'], stdin=f)
print(data)

with urllib.request.urlopen(TEST_URL) as f:
with open('/tmp/x.pdf', 'wb') as g:
n = g.write(f.read())
with open('/tmp/x.pdf') as g:
data = subprocess.check_output(['file', '-'], stdin=g)
print(data)

--- cut ---

Output is:

b'/dev/stdin: data\n'
b'/dev/stdin: PDF document, version 1.6\n'


Expected output is:

b'/dev/stdin: PDF document, version 1.6\n'
b'/dev/stdin: PDF document, version 1.6\n'


If I just read from urllib.request, I get what appears to the naked eye to be 
the expected data:


py> with urllib.request.urlopen(TEST_URL) as f:
... file = f.read()
... 
py> print(file[:100])
b'%PDF-1.6\r%\xe2\xe3\xcf\xd3\r\n55 0 obj\r<>\rendobj\r'




Certainly looks like a PDF file. So what's going on?




-- 
Steven
299792.458 km/s — not just a good idea, it’s the law!

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

Re: Access to the caller's globals, not your own

[Steven D'Aprano]

On Monday 14 November 2016 16:55, eryk sun wrote:

> On Mon, Nov 14, 2016 at 5:20 AM, Steven D'Aprano
>  wrote:
>> but what magic do I need? globals() is no good, because it returns the
>> library's global namespace, not the caller's.
>>
>> Any solution ought to work for CPython, IronPython and Jython, at a minimum.
> 
> You can access the globals of the caller's frame, but you'll have to
> research to what extent IronPython and Jython support CPython frame
> objects.
> 
> FWIW:
> 
> import inspect
> 
> SPAMIFY = True
> 
> def make_spam(n):
> caller_globals = inspect.currentframe().f_back.f_globals
> if caller_globals.get('SPAMIFY', SPAMIFY):
> return "spam" * n
> else:
> return "ham" * n

Nice! That appears to work on Jython, but not IronPython.

Thanks for the suggestion.





-- 
Steven
299792.458 km/s — not just a good idea, it’s the law!

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

Re: A question about sprite rendering in game development

[shadecelebi]

thanx a lot you guys. I'm slightly familiar with pygame from before so I'll 
make sure to utilize it. and no I don't have any of the characters yet as I've 
yet to start. I just wanted to know if I should keep learning python or if it 
would be trivial to try making my game a reality with this language. I'll need 
to learn a couple more things before I try to make a prototype. I believe the 
easiest route will be to simply rectangels of different colors for the early 
gameplay and to try and perfect the game mechanics before I move over to adding 
sprites and such. thank you both. I'll post updates in a different thread when 
I'm starting to see some kind of results
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Access to the caller's globals, not your own

[Steven D'Aprano]

On Tuesday 15 November 2016 07:04, ojacob...@heroku.com wrote:

> On Monday, November 14, 2016 at 12:21:00 AM UTC-5, Steven D'Aprano wrote:
> 
>> Don't tell me to make SPAMIFY a parameter of the function. I know that.
>> That's what I would normally do, but *occasionally* it is still useful to
>> have a global configuration setting, and those are the cases I'm talking
>> about.
> 
> This is the motivation behind Racket's parameters system
> . A _parameter_ has
> the following properties:
[snip]
> Parameterizing a call means that changes to the "global variables"
> implemented as parameters have predictable scope and can be reliably restored
> to their prior values, meaning they're a fairly safe way to implement
> "config" globals.

Sounds more like Python's "with" syntax and context managers, but I'll have a 
read over it the docs and see.


-- 
Steven
299792.458 km/s — not just a good idea, it’s the law!

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

Re: urllib.request giving unexpected results

[Chris Angelico]

On Wed, Nov 16, 2016 at 7:09 PM, Steven D'Aprano
 wrote:
> I'm trying to download a file using urllib.request and pipe it straight to an
> external process. On Linux systems, the following is a test file that
> demonstrates the problem:
>
>
> --- cut ---
>
> #!/usr/bin/python3.5
>
> import urllib.request
> import subprocess
>
> TEST_URL = 'https://www.irs.gov/pub/irs-prior/f1040--1864.pdf'
>
> with urllib.request.urlopen(TEST_URL) as f:
> data = subprocess.check_output(['file', '-'], stdin=f)
> print(data)

Interesting.

rosuav@sikorsky:~$ python3
Python 3.7.0a0 (default:72e64fc8746b+, Oct 28 2016, 12:35:28)
[GCC 6.2.0 20161010] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import urllib.request
>>> import subprocess
>>> TEST_URL = 'https://www.irs.gov/pub/irs-prior/f1040--1864.pdf'
>>> with urllib.request.urlopen(TEST_URL) as f:
...data = subprocess.check_output(['tee', 'tmp/asdfasdf'], stdin=f)
...

rosuav@sikorsky:~/tmp$ hd asdfasdf |head
  17 03 03 40 18 e9 b0 79  7c 03 c8 5d 21 40 2f 11  |...@...y|..]!@/.|
0010  4a a3 f1 4d e0 19 04 fc  42 84 d9 cf 59 0b f8 56  |J..MB...Y..V|
0020  7d 35 08 88 17 50 24 8c  26 fe d8 13 2b fd 14 55  |}5...P$.&...+..U|
0030  16 81 c3 1e 13 ae 00 1d  d4 8e 9f 0f a4 19 bb 44  |...D|
0040  46 d5 bf 25 28 d0 b0 23  44 6f 1c ef 84 d9 82 9b  |F..%(..#Do..|
0050  17 15 3a 11 e1 ec de 59  65 d7 ea 41 dc 53 07 70  |..:Ye..A.S.p|
0060  99 d5 11 75 b7 90 7e cd  46 b5 67 ee 9a 62 18 63  |...u..~.F.g..b.c|
0070  36 7f 7b df a1 fb 6d b8  66 8b 2f 82 e6 05 7e aa  |6.{...m.f./...~.|
0080  d7 9f 9e 05 cf 06 68 6b  c8 4c df 5e 24 9d 92 f6  |..hk.L.^$...|
0090  3d 53 76 11 c1 70 05 14  94 e5 5b ec b0 cf 64 70  |=Sv..p[...dp|


So that's what file(1) is seeing. My guess is that a urlopen object
isn't "file-like" enough for subprocess. Maybe it's showing a more
"raw" version?

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

Re: __debug__ http://stackoverflow.com/questions/15305688/conditional-debug-statement-not-executed-though-debug-is-true

[Steven D'Aprano]

On Wednesday 16 November 2016 16:21, Veek M wrote:

> Trying to make sense of that article. My understanding of debug was
> simple:
> 1. __debug__ is always True, unless -O or -OO
> 2. 'if' is optimized out when True and the expr is inlined.
> 
> So what does he mean by:
> 
> 1. 'If you rebind __debug__, it can cause symptoms'

What he means is, "I didn't test this code before running it, and I am wrong."

You cannot rebind __debug__.

>>> __debug__ = False
  File "", line 1
SyntaxError: can not assign to __debug__


(That's Python 2.5 or better, and maybe even older than that.)


-- 
Steven
299792.458 km/s — not just a good idea, it’s the law!

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

Re: Access to the caller's globals, not your own

[Steven D'Aprano]

On Tuesday 15 November 2016 15:55, Dan Sommers wrote:

> On Mon, 14 Nov 2016 16:20:49 +1100, Steven D'Aprano wrote:
> 
>> import library
>> SPAMIFY = False  # only affects this module, no other modules
>> result = library.make_spam(99)
> 
> I must be missing something, because it seems too obvious:
[snip]

I wouldn't say "obvious" so much as "complex".

A factory function or a class that holds state for a local make_spam() callable 
would be a possible solution, but it significantly increases the complexity, 
especially for the simple case:

import library
result = library.make_spam(arg)


versus:

import library
make_spam = library.make_library()
result = make_spam(arg)

What a drag.



[...]
> How do you want the following code to work:
> 
> import library
> SPAMIFY=False
> 
> def make_false_spam():
> return library.make_spam(99)
> 
> def make_true_spam():
> global SPAMIFY
> SPAMIFY=True
> return library.make_spam(99)
> 
> I don't have to tell you how many things can go wrong with code like
> that.  ;-)

Indeed.

> Yes, it's a straw man.  No, I don't think we have all the details of
> your use case.  Yes, I'm willing to have missed something subtle (or not
> so subtle).

The use-case shouldn't matter, because I think I've been hanging around here 
for long enough that you should trust me that I'm not one to abuse global 
variables :-)

But, for what its worth... 

I have a function, let's call it quartile(data, n). Unfortunately there's about 
a dozen different ways to calculate quartiles, and they all give ever-so-
slightly different results. So I end up with:

def quartile(data, n, scheme="Method 7"):
...


which lets the caller choose the specific calculation method they want to use, 
or just use the default. *My* default, chosen by me, which may or may not be 
convenient.

And then there's a bunch of other functions which depend on quartile(). I don't 
have to list them, but there's at least two and may be more. They too will have 
an optional parameter to choose a calculation method. And *that* almost rules 
out your factory function idea: having to call a factory to create multiple 
functions is too confusing for a library API.

quartile, iqr, blah blah blah = library.make_functions()


So while I'd consider that under some circumstances, I don't like it here.

I'd like the caller to be able to set their own default, if they don't like 
mine, in the easiest way possible. That means a global.

DEFAULT_SCHEME = "Method 7"

# Late binding of the default, instead of early binding.
def quartile(data, n, scheme=None):
if scheme is None:
scheme = DEFAULT_SCHEME
...


Say they want to match the same calculation method that Excel uses, they can 
just modify the library.DEFAULT_SCHEME and forget all about it.

But that's globally global, and I actually want it to only be global to their 
own module. Hence my question.

As an alternative, I'm thinking of allowing the caller to set an environment 
variable... only that's globally global too.


-- 
Steven
299792.458 km/s — not just a good idea, it’s the law!

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

Re: Access to the caller's globals, not your own

[Ethan Furman]

On 11/16/2016 12:36 AM, Steven D'Aprano wrote:


But, for what its worth...

I have a function, let's call it quartile(data, n). Unfortunately there's about
a dozen different ways to calculate quartiles, and they all give ever-so-
slightly different results. So I end up with:

def quartile(data, n, scheme="Method 7"):
 ...


which lets the caller choose the specific calculation method they want to use,
or just use the default. *My* default, chosen by me, which may or may not be
convenient.

And then there's a bunch of other functions which depend on quartile(). I don't
have to list them, but there's at least two and may be more. They too will have
an optional parameter to choose a calculation method. And *that* almost rules
out your factory function idea: having to call a factory to create multiple
functions is too confusing for a library API.

 quartile, iqr, blah blah blah = library.make_functions()


So while I'd consider that under some circumstances, I don't like it here.

I'd like the caller to be able to set their own default, if they don't like
mine, in the easiest way possible. That means a global.

DEFAULT_SCHEME = "Method 7"

# Late binding of the default, instead of early binding.
def quartile(data, n, scheme=None):
 if scheme is None:
 scheme = DEFAULT_SCHEME
 ...


Say they want to match the same calculation method that Excel uses, they can
just modify the library.DEFAULT_SCHEME and forget all about it.

But that's globally global, and I actually want it to only be global to their
own module. Hence my question.


I think you stuck with the same solution Decimal uses: a context that you can 
either set globally global, or one that can be used as a context manager.

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

Farewell to Rob Collins

[M.-A. Lemburg]

We would like to share with you the sad news, that Rob Collins has
passed away earlier this month, on November 2nd, after a short but
intense illness.

Many of you may know Rob from the sponsored massage sessions he
regularly ran at EuroPython in recent years and which he continued to
develop, taking them from a single man setup (single threaded process)
to a group of people setup by giving workshops (multiprocessing) and
later on by passing on his skills to more leaders (removing the GIL)
to spread wellness and kindness throughout our conference series:

https://ep2015.europython.eu/conference/talks/sponsored-massage-training-in-aid-of-the-python-software-foundation

His massages regularly raised more than a thousand dollars which were
donated to the Python Software Foundation (PSF) to do even more good.

Rob also gave a lot of thoughtful talks at the EuroPython conferences,
always very cheerful, full of humor and many good insights. Here’s a
selection:

 * EuroPython 2015: DumbDev – eight rules for dumb development
   https://www.youtube.com/watch?v=HEOI8y0qHMk

 * EuroPython 2015: Lightning Talk announcing the Python Massage
   Foundation
   https://youtu.be/WmvTfUYJ2Bw?t=1539

 * EuroPython 2013: TDM Test Driven Madness
   https://www.youtube.com/watch?v=Nj4nwh_VrPM

 * EuroPython 2012: An introduction to his neck and and shoulder
   massages
   https://www.youtube.com/watch?v=itn8W9zI0Wk

 * EuroPython 2011: Pricing products using Python graphs and sets
   https://www.youtube.com/watch?v=TN9nIBxDXU8

Rob was a true Pythonista from the heart. He will always be remembered
for his humor, great spirit and kindness.

You were such a cheerful person. We will miss you, Rob.

Thank you for all the inspiration,
-–
Your friends from the EuroPython community
http://www.europython-society.org/

Full blog post:
http://www.europython-society.org/post/153253946400/farewell-to-rob-collins
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Farewell to Rob Collins

[Karim]

On 16/11/2016 11:21, M.-A. Lemburg wrote:

s a true Pythonista from the heart. He will always be remember


RIP Rob.

Karim

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

Re: PyQt pass data from class

[Michael Torrie]

On 11/16/2016 12:47 AM, luca72 via Python-list wrote:
> Thanks for your reply
> 
> Is the latter, can you explain how i can do it.

Just add an argument to __init__() of the one class where you will pass
the instance of the other class to it. Then you can store it inside the
instance, and use it whenever needed.

class foo(object):
def __init__(self):
pass

def some_method(self):
print ("Hello from foo.some_method")

class bar(object):
def __init__(self, foo_instance):
self.foo_instance = foo_instance

def some_method(self):
foo.some_method()

a=foo()
b=bar(a)

Of course since you're dealing with PyQt your classes will involve some
other parameters to __init__ but you can still tack your parameter on there.

You may want to re-examine how you're building your classes, though.
There's likely a way you can structure things to eliminate this kind of
coupling, especially in the context of a GUI. Often times making your
own signal that can be externally connected to a method of the other
class is the way to go as this reduces the coupling between the classes.

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

Re: Access to the caller's globals, not your own

[Antoon Pardon]

Op 16-11-16 om 09:36 schreef Steven D'Aprano:
> On Tuesday 15 November 2016 15:55, Dan Sommers wrote:
>
>> On Mon, 14 Nov 2016 16:20:49 +1100, Steven D'Aprano wrote:
>>
>>> import library
>>> SPAMIFY = False  # only affects this module, no other modules
>>> result = library.make_spam(99)
>> I must be missing something, because it seems too obvious:
> [snip]
>
> I wouldn't say "obvious" so much as "complex".
>
> A factory function or a class that holds state for a local make_spam() 
> callable 
> would be a possible solution, but it significantly increases the complexity, 
> especially for the simple case:
>
> import library
> result = library.make_spam(arg)
>
>
> versus:
>
> import library
> make_spam = library.make_library()
> result = make_spam(arg)
>
> What a drag.

What about how the random module solves this?

The random module provides a factory class: Random.

It also provides functions which are methods of a
hidden instantiation.

-- 
Antoon Pardon.

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

Re: __debug__ http://stackoverflow.com/questions/15305688

[eryk sun]

On Wed, Nov 16, 2016 at 8:39 AM, Steven D'Aprano
 wrote:
> On Wednesday 16 November 2016 16:21, Veek M wrote:
>
>> Trying to make sense of that article. My understanding of debug was
>> simple:
>> 1. __debug__ is always True, unless -O or -OO
>> 2. 'if' is optimized out when True and the expr is inlined.
>>
>> So what does he mean by:
>>
>> 1. 'If you rebind __debug__, it can cause symptoms'
>
> What he means is, "I didn't test this code before running it, and I am wrong."
>
> You cannot rebind __debug__.
>
 __debug__ = False
>   File "", line 1
> SyntaxError: can not assign to __debug__
>
>
> (That's Python 2.5 or better, and maybe even older than that.)

Andrew didn't assign directly to __debug__. He assigned to
sys.modules[__name__].__debug__, which is allowed prior to 2.7. Even
in later versions, as he pointed out, you can dynamically assign to
'__debug__' in a namespace dict.

For an expression containing __debug__, i.e. not simply an `if
__debug__` test, the compiler emits a LOAD_NAME operation (or
LOAD_GLOBAL in a function) to load the value on the stack and evaluate
the expression. Thus the builtins value may be shadowed by a local or
global value, or you can just modify builtins directly.

This inconsistency could be addressed by making __debug__ a static
symbol, which in CPython would always be determined by the value of
the C global variable Py_OptimizeFlag. In this case a code block would
reference a '__debug__' constant in its co_consts, defined at compile
time.

For example, this is the current inconsistent compile-time vs run-time
behavior, tested in 3.5:

>>> import sys
>>> sys.flags.optimize
0
>>> vars(sys.modules['builtins'])['__debug__'] = False

Compiling a simple `if __debug__` block depends on the value of Py_OptimizeFlag:

>>> if __debug__: print('__debug__')
...
__debug__

But evaluating an expression requires loading the dynamic value of __debug__:

>>> if not __debug__: print('not __debug__')
...
not __debug__

>>> vars(sys.modules['builtins'])['__debug__'] = True
>>> if not not __debug__: print('__debug__')
...
__debug__

For `if __debug__` blocks, the compiler looks at the value of the C
global variable Py_OptimizeFlag:

>>> import ctypes
>>> Py_OptimizeFlag = ctypes.c_int.in_dll(
... ctypes.pythonapi, 'Py_OptimizeFlag')

>>> if __debug__: print('__debug__')
... else: print('not __debug__')
...
__debug__

>>> Py_OptimizeFlag.value = 1
>>> if __debug__: print('__debug__')
... else: print('not __debug__')
...
not __debug__

Off topic:
The text after the question ID in a Stack Overflow URL is optional, so
I removed it from the message title.
-- 
https://mail.python.org/mailman/listinfo/python-list

ANN: eGenix mxODBC 3.3.6 - Python ODBC Database Interface

[eGenix Team: M.-A. Lemburg]

ANNOUNCING

 eGenix.com mxODBC

   Python ODBC Database Interface

   Version 3.3.6


mxODBC is our commercially supported Python extension providing
 ODBC database connectivity to Python applications
on Windows, Mac OS X, Unix and BSD platforms
   with many advanced Python DB-API extensions and
 full support of stored procedures


This announcement is also available on our web-site for online reading:
http://www.egenix.com/company/news/eGenix-mxODBC-3.3.6-GA.html



INTRODUCTION

mxODBC provides an easy-to-use, high-performance, reliable and robust
Python interface to ODBC compatible databases such as MS SQL Server,
Oracle Database, IBM DB2, Informix and Netezza, SAP Sybase ASE and
Sybase Anywhere, Teradata, MySQL, MariaDB, PostgreSQL, SAP MaxDB and
many more:

http://www.egenix.com/products/python/mxODBC/

The "eGenix mxODBC - Python ODBC Database Interface" product is a
commercial extension to our open-source eGenix mx Base Distribution:

http://www.egenix.com/products/python/mxBase/



NEWS

The 3.3.6 release of our mxODBC is a patch level release of our
popular Python ODBC Interface for Windows, Linux, Mac OS X and
FreeBSD. It includes these enhancements and fixes:

Features


 * The mxODBC default *RowFactory helpers will no longer try to add
   column names which are not valid Python identifiers to the Row
   class code. Such columns are still available via index
   (e.g. row[0]) or named access (e.g. row['123']).

Bug Fixes
-

 * IMPORTANT: Fixed a bug in context managers not properly detecting
   exceptions. This resulted exceptions getting silenced, transactions
   not getting committed and could lead to data corruption. Thanks to
   Jan Murre for the report.

For the full set of changes please check the mxODBC change log:

http://www.egenix.com/products/python/mxODBC/changelog.html



FEATURES

mxODBC 3.3 was released on 2014-04-08. Please see the full
announcement for highlights of the 3.3 release:

http://www.egenix.com/company/news/eGenix-mxODBC-3.3.0-GA.html

For the full set of features mxODBC has to offer, please see:

http://www.egenix.com/products/python/mxODBC/#Features



EDITIONS

mxODBC is available in these two editions:

 * The Professional Edition, which gives full access to all mxODBC features.

 * The Product Development Edition, which allows including mxODBC in
   applications you develop.

For a complete overview of the available editions, please see the
product page:

http://www.egenix.com/products/python/mxODBC/#mxODBCEditions



DOWNLOADS

The download archives and instructions for installing the package can
be found at:

http://www.egenix.com/products/python/mxODBC/

In order to use the eGenix mxODBC package you will first need to
install the eGenix mx Base package:

http://www.egenix.com/products/python/mxBase/

You can also simply use:

pip install egenix-mxodbc

and then get evaluation licenses from our website to try mxODBC:

http://www.egenix.com/products/python/mxODBC/#Evaluation



UPGRADING

Users are encouraged to upgrade to this latest mxODBC release to
benefit from the new features and updated ODBC driver support.

We have taken special care not to introduce backwards incompatible
changes, making the upgrade experience as smooth as possible.

Customers who have purchased mxODBC 3.3 licenses can continue to use
their licenses with this patch level release.

For upgrade purchases, we will give out 20% discount coupons going
from mxODBC 2.x to 3.3 and 50% coupons for upgrades from mxODBC 3.x to
3.3. Please contact the eGenix.com Sales Team with your existing
license serials for details for an upgrade discount coupon.

If you want to try the new release before purchase, you can request
30-day evaluation licenses by visiting our web-site

http://www.egenix.com/products/python/mxODBC/#Evaluation

or writing to sa...@egenix.com, stating your name (or the name of the
company) and the number of eval licenses that you need.

___

SUPPORT

Commercial support for this product is available from eGenix.com.
Please see

http://www.egenix.com/services/support/

for details about our support offerings.

___

INFORMATION

About eGenix (http://www.egenix.com/):

eGenix is a 

Re: Farewell to Rob Collins

[Ben Finney]

"M.-A. Lemburg"  writes:

> Rob was a true Pythonista from the heart. He will always be remembered
> for his humor, great spirit and kindness.

Robert and I had many conversations about the Bazaar version control
system, and I owe to him my passion for distributed version control.

When I needed to convince my workplace to try this strange new idea,
Robert kindly donated his time to visit our offices and give a
presentation on why distributed version control was better and why
Bazaar was a good choice for us.

He also inspired me to get serious about unit testing as a way to
increase confidence in a code base.

You touched many lives, and you are missed. Vale, Rob.

-- 
 \ “What you have become is the price you paid to get what you |
  `\ used to want.” —Mignon McLaughlin |
_o__)  |
Ben Finney

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

Re: Access to the caller's globals, not your own

[Rob Gaddi]

Steven D'Aprano wrote:

> On Tuesday 15 November 2016 15:55, Dan Sommers wrote:
>
>> On Mon, 14 Nov 2016 16:20:49 +1100, Steven D'Aprano wrote:
>> 
>>> import library
>>> SPAMIFY = False  # only affects this module, no other modules
>>> result = library.make_spam(99)
>> 
>> I must be missing something, because it seems too obvious:
> [snip]
>
> I wouldn't say "obvious" so much as "complex".
>
> A factory function or a class that holds state for a local make_spam() 
> callable 
> would be a possible solution, but it significantly increases the complexity, 
> especially for the simple case:
>
> import library
> result = library.make_spam(arg)
>
>
> versus:
>
> import library
> make_spam = library.make_library()
> result = make_spam(arg)
>
> What a drag.
>
>

And there you have it; an entire extra line at import time.

It's the answer that's explicit.  It's versatile (you can create
multiple library instances with different defaults if that sort of thing
is really your jam), and it uses no tricky mechanisms that unskilled
programmers won't understand.

You can even create a default object in the main library with some
sensible defaults and bind out the methods as functions just to provide
a quick and easy answer for people who don't care.

  class Library:
...

  _defaultlib = Library()
  _defaultlib.rounding = NEAREST_EVEN
  make_spam = _defaultlib.make_spam

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Farewell to Rob Collins

[Sean Son]

Rest in Peace Rob

On Wed, Nov 16, 2016 at 12:48 PM, Ben Finney 
wrote:

> "M.-A. Lemburg"  writes:
>
> > Rob was a true Pythonista from the heart. He will always be remembered
> > for his humor, great spirit and kindness.
>
> Robert and I had many conversations about the Bazaar version control
> system, and I owe to him my passion for distributed version control.
>
> When I needed to convince my workplace to try this strange new idea,
> Robert kindly donated his time to visit our offices and give a
> presentation on why distributed version control was better and why
> Bazaar was a good choice for us.
>
> He also inspired me to get serious about unit testing as a way to
> increase confidence in a code base.
>
> You touched many lives, and you are missed. Vale, Rob.
>
> --
>  \ “What you have become is the price you paid to get what you |
>   `\ used to want.” —Mignon McLaughlin |
> _o__)  |
> Ben Finney
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Printing a generator returns "", need to print its values

[vmahajan]

I am running Python2.7, wherein I am running the following price of code:

y = m.predict(input_fn=lambda:input_fn(df_predict), as_iterable=True)
print ('Predictions: {}'.format(str(y)))

The output of the following is """

However, the desired output must be in the format [1 0 0 1 1 0 0 1].

Can someone help me print the output in this format
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Printing a generator returns "", need to print its values

[MRAB]

On 2016-11-16 20:01, vmaha...@centerpointmedia.com wrote:

I am running Python2.7, wherein I am running the following price of code:

y = m.predict(input_fn=lambda:input_fn(df_predict), as_iterable=True)
print ('Predictions: {}'.format(str(y)))

The output of the following is """

However, the desired output must be in the format [1 0 0 1 1 0 0 1].

Can someone help me print the output in this format


Pass the generator object to 'list':

y = list(m.predict(input_fn=lambda:input_fn(df_predict), as_iterable=True))
print('Predictions: {}'.format(y))

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

Re: Printing a generator returns "", need to print its values

[Peter Otten]

vmaha...@centerpointmedia.com wrote:

> I am running Python2.7, wherein I am running the following price of code:
> 
> y = m.predict(input_fn=lambda:input_fn(df_predict), as_iterable=True)
> print ('Predictions: {}'.format(str(y)))
> 
> The output of the following is "" 0x7f0476373e10>"
> 
> However, the desired output must be in the format [1 0 0 1 1 0 0 1].
> 
> Can someone help me print the output in this format

You give no context, but my suggestion would be to try and omit the 

as_iterable=True

part...


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

Re: how to print variable few time?

[andy]

Sun, 13 Nov 2016 17:27:23 +0200 wrote Jussi Piitulainen:


>>> word=raw_input()
>>> print word*3
>>> 
>>> 
>>> with this code im getting - wordwordword.
>>> what changes i need to make to get - word word word - instead?
>>> 
>>> thanks
>>
>> using python3.x:
>>
>> word=input()
>> print((word+' ')*2, end='')
>> print(word)
> 
> print(*[word]*3)

thanks for this starred expression - it took me one afternoon to 
understand ;-)

one should search the library and https://www.python.org/dev/peps/
pep-0448/ and try to

>>> import this

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

Re: Farewell to Rob Collins

[Ben Finney]

Ben Finney  writes:

> Robert and I had many conversations […].

My apologies for the confusion! This is not the same person.

I did not know the Rob Collins described in the obituary
http://www.europython-society.org/post/153253946400/farewell-to-rob-collins>
so my comments were misguided.


Thank you, Rob Collins (of the UK, and of EuroPython fame), for your
contributions to free software.

-- 
 \   “… one of the main causes of the fall of the Roman Empire was |
  `\that, lacking zero, they had no way to indicate successful |
_o__)  termination of their C programs.” —Robert Firth |
Ben Finney

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

Re: help on "from deen import *" vs. "import deen"

[jfong]

Steve D'Aprano at 2016/11/16 8:33:23AM wrote:
> `import foo` imports the module foo, that is all. (To be pedantic: it is
> *nominally* a module. By design, it could be any object at all.)
> 
> `from foo import *` imports all the visible public attributes of foo.
> 
> They do completely different things, equivalent to something similar to:
> 
> five = int('5')
> 
> 
> versus:
> 
> 
> _tmp = int('5')
> for name in dir(_tmp):
> if not name.startswith('_'):
> locals()[name] = getattr(_tmp, name)
> del _tmp

This is far beyond my comprehension:-(

--Jach

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

Re: help on "from deen import *" vs. "import deen"

[jfong]

Michael Torrie at 2016/11/16 11:15:11AM wrote:
> ... The globals object is a dictionary and is itself
> mutable.  But when we assign a new object to a particular dictionary
> key, it tosses out the old reference and makes the key now refer to the
> new object.  It does not do anything to the old object itself.

The last question: Is it possible, in the current Python version, to re-bind a 
global name in module "deen" after it was imported "from deen import *"?

> > That's one problem I was concerned. Human beings are very deeply
> > binding on words (names?). We think in words, talk in words,
> > communicate in words. Actually we are living in words. I really don't
> > like that when I said "John is a boy" and was told "No, John is a dog
> > now":-)
> 
> Not quite sure where you're going with that. I would think the idea of
> labels on objects would be fairly natural. I could stick a label that
> says "chair" on a chair, and then later move that label to the couch.
> Same label, different object.  Whether the label makes sense is up to you.

I mean it might be better to have two labels to label chair and couch 
separately, instead of one:-)

--Jach

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

Re: help on "from deen import *" vs. "import deen"

[Chris Angelico]

On Thu, Nov 17, 2016 at 1:01 PM,   wrote:
> Michael Torrie at 2016/11/16 11:15:11AM wrote:
>> ... The globals object is a dictionary and is itself
>> mutable.  But when we assign a new object to a particular dictionary
>> key, it tosses out the old reference and makes the key now refer to the
>> new object.  It does not do anything to the old object itself.
>
> The last question: Is it possible, in the current Python version, to re-bind 
> a global name in module "deen" after it was imported "from deen import *"?

Yes.

from deen import *

...

import deen
deen.some_name = new_value

Voila :)

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

Re: A question about sprite rendering in game development

[Larry Hudson via Python-list]

On 11/16/2016 12:16 AM, shadecelebi wrote:

thanx a lot you guys. I'm slightly familiar with pygame from before so I'll 
make sure to utilize it. and no I don't have any of the characters yet as I've 
yet to start. I just wanted to know if I should keep learning python or if it 
would be trivial to try making my game a reality with this language. I'll need 
to learn a couple more things before I try to make a prototype. I believe the 
easiest route will be to simply rectangels of different colors for the early 
gameplay and to try and perfect the game mechanics before I move over to adding 
sprites and such. thank you both. I'll post updates in a different thread when 
I'm starting to see some kind of results



There's a book, "Making Games with Python & Pygame", available at 
http://inventwithpython.com/pygame/ you might find worth checking out.


On this site, there are two prominent links to "Buy It" and "Read it on-line".  But below these 
are three 'alternate' links to downloadable PDF and e-Reader versions as well as the source code 
(including the graphics used in the book).  The "Buy It" is for a hard-copy version.


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

Re: help on "from deen import *" vs. "import deen"

[Steven D'Aprano]

On Thursday 17 November 2016 12:54, jf...@ms4.hinet.net wrote:

> Steve D'Aprano at 2016/11/16 8:33:23AM wrote:
>> `import foo` imports the module foo, that is all. (To be pedantic: it is
>> *nominally* a module. By design, it could be any object at all.)
>> 
>> `from foo import *` imports all the visible public attributes of foo.
>> 
>> They do completely different things, equivalent to something similar to:
>> 
>> five = int('5')
>> 
>> 
>> versus:
>> 
>> 
>> _tmp = int('5')
>> for name in dir(_tmp):
>> if not name.startswith('_'):
>> locals()[name] = getattr(_tmp, name)
>> del _tmp
> 
> This is far beyond my comprehension:-(

That's okay, I was talking mostly to Eric.

You understand how this works?

five = int('5')


creates a new variable "five", and gives it the value 5.

py> five
Traceback (most recent call last):
  File "", line 1, in 
NameError: name 'five' is not defined
py> five = int("5")  # creates the new variable
py> five
5

That is similar to how import works: "import os" reads the "os.py" file, 
compiles it to a module object, creates the variable "os", and sets collections 
to that module object:

py> os
Traceback (most recent call last):
  File "", line 1, in 
NameError: name 'os' is not defined
py> import os
py> os




But that's not what "from os import *" does. It is more complicated. It looks 
inside the "os" module, extracts all the public functions, classes and global 
variables, and creates new variables in your own module for them.

The os module has close to 200 or more public functions and globals, so I'll 
pick a simpler example. Create this two line file:


# library.py
apple = 1
pear = 2



Now let's check that "import" works the way we expect. Inside the Python 
interactive interpreter, run this code:


py> library
Traceback (most recent call last):
  File "", line 1, in 
NameError: name 'library' is not defined
py> import library
py> library



Do you get the same output?

Look inside the module:

py> print(library.apple)
1



Check that there's no "apple" variable, then import it:

py> apple
Traceback (most recent call last):
  File "", line 1, in 
NameError: name 'apple' is not defined
py> from library import apple
py> apple
1


Finally try this:

py> apple = 999
py> from library import *
py> apple
1
py> pear
2




Remember that the "apple" variable is a different variable from the 
"library.apple" variable. Think of:

# in the USA
president = "Barack Obama"

# in Russia
president = "Vladimir Putin"


Two variables, with the same name, but their values are independent:

usa.president = "Donald Trump"  # will happen soon
print(russia.president)  # still prints "Vladimir Putin"


The same happens when you are working inside the current active module:

president = "Xi Jinping"

This doesn't affect either usa.president or russia.president -- not even if we 
first take the value from the other module:


from russia import president
assert president == 'Vladimir Putin'  # this is true, for now
president = 'Francois Hollande'  # new president, here


Changing the president in the current module doesn't change the 
russia.president.



Now:

from russia import president

is almost the same as:


import russia as _tmp
president = _tmp.president
del _tmp



But this is more complicated:

from russia import *


The star import has to work out all the visible public names, and create new 
variables for all of them. You don't need to understand how it does that, the 
details are not important. What is important is that the variables it creates 
are different from the variables living inside the russia module.




-- 
Steven
299792.458 km/s — not just a good idea, it’s the law!

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

Re: Access to the caller's globals, not your own

[Steven D'Aprano]

On Thursday 17 November 2016 04:52, Rob Gaddi wrote:

>> import library
>> result = library.make_spam(arg)
>>
>>
>> versus:
>>
>> import library
>> make_spam = library.make_library()
>> result = make_spam(arg)
>>
>> What a drag.
>>
>>
> 
> And there you have it; an entire extra line at import time.

Multiplied by every function that has a configurable default. Multiplied by 
every module that imports any of those functions, *whether or not* they change 
the default. If there are four functions, the user has to do this:

import library
make_spam = library.make_spam_factory()
make_eggs = library.make_eggs_factory()
make_cheese = library.make_cheese_factory()
make_toast = library.make_toast_factory()


before they can even begin to do what they actually want to do, which is make 
spam, eggs, cheese etc. And yes, there's likely to be four or more of these 
functions.

You can slightly work around this by offering pre-built functions that avoid 
needing to call the factory, but this is adding more complexity to what really 
isn't that complicated: a function with a user-configurable default setting.


> It's the answer that's explicit.

An explicit solution would be to offer no default setting at all and require 
the user to always provide the setting as an explicit argument to the function.

But despite the Zen of Python (which has always been intended as a humorous and 
intentionally self-contradictory way to think about the design of the language, 
not as a way to shut down discussion), explicit is not ALWAYS better than 
implicit. That's why we have default values, and why we don't require imports 
to be written like this:

# explicitly giving the name to bind to is better
import math as math


It's very unusual to require the caller of a library function to create the 
function first: factory functions and builders are a powerful technique, but 
they're more useful for the library, less so for the user of the library.

Conceptually, my library offers a simple function. The API of functions is 
well-known:

import library
result = library.function(arg)

The API for providing user-configurable default values is well-known and easily 
understood: you set a global variable (or even an environment variable):

DEFAULT = foo
result = library.function()

There's about half a century of programming practice and probably ten billion 
person-hours of collective experience behind this idea.

Whereas fancy tricks involving factory functions, builders and class-based 
solutions are *much* less well-known or understood. Outside of functional 
programming circles, the idea of calling a function to return a function is 
often considered mind-blowing voodoo.


> It's versatile (you can create
> multiple library instances with different defaults if that sort of thing
> is really your jam), 

Indeed: factory functions are great. But I'm saying that as the writer of the 
library, not the user of the library. Can you imagine expecting users to do 
this?

from math import trig
sin = trig.build('sine')
result = sin(0.1)

It might only be one extra line of code, but conceptually it is an order of 
magnitude more complex. The user has to comprehend factory functions and first-
class functions as values before they can even begin to understand this.


> and it uses no tricky mechanisms that unskilled
> programmers won't understand.

The internal details of how the implementation works is not important to the 
user. They only need to understand that the "scheme" parameter takes its value 
from the first found of:

- an explicit argument
- a global variable called "WHATEVER"
- the library default

which is pretty simple to understand and use.



-- 
Steven
299792.458 km/s — not just a good idea, it’s the law!

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

What exactly is a python variable?

[Veek M]

In C:
int x = 10; 
results in storage being allocated and type and location are fixed for 
the life of the program. 

In Python,
x = 10

causes an object '10' to be created but how exactly is 'x' handled? 
Symbol Table lookup at compile time? Is every 'x' being substituted out 
of existence? Because type(x) gives 'int' so..
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Access to the caller's globals, not your own

[Dan Sommers]

On Thu, 17 Nov 2016 16:17:51 +1100, Steven D'Aprano wrote:

> ... factory functions are great. But I'm saying that as the writer of
> the library, not the user of the library. Can you imagine expecting
> users to do this?

> from math import trig
> sin = trig.build('sine')
> result = sin(0.1)

No, but I could expect users to do this:

import math # trig functions take radians by default
math = math.degree_math # but I like degrees

Or to choose from one of these:

import math # trig functions take radians by default
import math.degree_math as math # but I like degrees

Or to choose from one of these:

import math.radian_math as math # use the radians version
import math.degree_math as math # use the degrees version

The complexity is taken on once, by the library author, who (presumably)
understands the complexity better than the users do.

> It might only be one extra line of code, but conceptually it is an
> order of magnitude more complex. The user has to comprehend factory
> functions and first-class functions as values before they can even
> begin to understand this.

It is only one line of code, but only the library author has to deal
with the rest of that.

> The internal details of how the implementation works is not important
> to the user ...

On that we all agree.  :-)

> ... They only need to understand that the "scheme" parameter takes its
> value from the first found of:
> 
> - an explicit argument
> - a global variable called "WHATEVER"
> - the library default
> 
> which is pretty simple to understand and use.

Hey, wait a minute:  you've slipped another option into the mix because
you originally wanted a separate "global" setting for each module that
imports your library.  With a global global rather than a module global,
you might get something like this:

import library # default is HAMMIFY
library.default = library.SPAMMIFY # but I like SPAMMIFY instead

(At which point, I see your point about wanting the library to reach
"out" to some sort of global space rather than the user reaching "in" to
the library space after the fact.)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What exactly is a python variable?

[Chris Angelico]

On Thu, Nov 17, 2016 at 4:40 PM, Veek M  wrote:
> In C:
> int x = 10;
> results in storage being allocated and type and location are fixed for
> the life of the program.
>
> In Python,
> x = 10
>
> causes an object '10' to be created but how exactly is 'x' handled?
> Symbol Table lookup at compile time? Is every 'x' being substituted out
> of existence? Because type(x) gives 'int' so..

Here:

http://nedbatchelder.com/text/names1.html

Enjoy!

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

Re: help on "from deen import *" vs. "import deen"

[jfong]

Steven D'Aprano at 2016/11/17 12:06:19PM wrote:
> You understand how this works?

Yes, thank you for your detail explanation.

> import russia as _tmp
> president = _tmp.president
> del _tmp

This one I can understand. But the previous one

>>_tmp = int('5')
>>for name in dir(_tmp):
>>if not name.startswith('_'):
>>locals()[name] = getattr(_tmp, name)
>>del _tmp

which I am still on scratching my head.

Now the question moves from "how" to "why":

Why "del _tmp" at the last step? The only reason I can thought of is 
"information hiding", but from whom? A global variable has its reason to be as 
a global. It may need to be modified later to influence others behavior. Using 
delete to hide the name seems unnecessary and redundant. If someone really 
want, he can follow the solution Chris had provided in his reply.

>>from deen import *
>>...
>>import deen
>>deen.some_name = new_value

A little strange, but effective:-)

--Jach

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

Re: __debug__ http://stackoverflow.com/questions/15305688

[Steven D'Aprano]

On Thursday 17 November 2016 02:22, eryk sun wrote:

> On Wed, Nov 16, 2016 at 8:39 AM, Steven D'Aprano
>  wrote:
>> On Wednesday 16 November 2016 16:21, Veek M wrote:
>>
>>> Trying to make sense of that article. My understanding of debug was
>>> simple:
>>> 1. __debug__ is always True, unless -O or -OO
>>> 2. 'if' is optimized out when True and the expr is inlined.
>>>
>>> So what does he mean by:
>>>
>>> 1. 'If you rebind __debug__, it can cause symptoms'
>>
>> What he means is, "I didn't test this code before running it, and I am
>> wrong."
>>
>> You cannot rebind __debug__.
>>
> __debug__ = False
>>   File "", line 1
>> SyntaxError: can not assign to __debug__
>>
>>
>> (That's Python 2.5 or better, and maybe even older than that.)
> 
> Andrew didn't assign directly to __debug__. He assigned to
> sys.modules[__name__].__debug__, which is allowed prior to 2.7. Even
> in later versions, as he pointed out, you can dynamically assign to
> '__debug__' in a namespace dict.


That's a fascinating loophole.

In any case, that's not something people are likely to stumble onto by 
accident, and if you're intentionally writing to a reserved name in a non-
standard way, whatever side-effects you trip over are your own fault.


> >>> if not __debug__: print('not __debug__')
> ...
> not __debug__

That should be a candidate for keyhole optimization, same as `if __debug__`.



-- 
Steven
299792.458 km/s — not just a good idea, it’s the law!

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