Urgent - Would like to see output of each block of python

[Archana Sonavane]

Hi Team,

I don't have any idea about python scripts, i have ganglia tool python scripts.

I would like see the output of each code block, could you please guide.

The code as follows:

#!/usr/bin/env python

#
# ganglia-api.py - Ganglia Metric API
#


from settings import LOGFILE, PIDFILE, API_SERVER, HEARTBEAT

import os
import sys
import glob
import re
import logging
import socket
import select
import datetime
import time
import SocketServer
from xml.etree import ElementTree
from xml.parsers.expat import ExpatError
from urllib import quote
from threading import Thread

import tornado.httpserver
import tornado.ioloop
import tornado.options
import tornado.web
from tornado.options import define, options


__version__ = '1.0.16'

define("port", default=8080, help="run on the given port", type=int)

logging.basicConfig(level=logging.INFO, format="%(asctime)s 
%(name)s[%(process)d] %(levelname)s - %(message)s",
filename=LOGFILE)
global logger
logger = logging.getLogger("ganglia-api")


class Elem:
def __init__(self, elem):
self.elem = elem

def __getattr__(self, name):
return self.elem.get(name.upper())


class NullElem:
def __getattr__(self, name):
return None


class ApiMetric:
tag_re = re.compile("\s+")

def id(self):
group = self.group if self.group is not None else ""
id_elements = [self.environment, self.grid.name, self.cluster.name, 
self.host.name, group, self.name]
return str.lower(".".join(filter(lambda (e): e is not None, 
id_elements)))

def api_dict(self):
type, units = ApiMetric.metric_type(self.type, self.units, self.slope)
metric = {'environment': self.environment,
  'service': self.grid.name,
  'cluster': self.cluster.name,
  'host': self.host.name,
  'id': self.id(),
  'metric': self.name,
  'instance': self.instance,
  'group': self.group,
  'title': self.title,
  'tags': ApiMetric.parse_tags(self.host.tags),
  'description': self.desc,
  'sum': self.sum,
  'num': self.num,
  'value': ApiMetric.is_num(self.val),
  'units': units,
  'type': type,
  'sampleTime': datetime.datetime.fromtimestamp(
  int(self.host.reported) + int(self.host.tn) - 
int(self.tn)).isoformat() + ".000Z",
  'graphUrl': self.graph_url,
  'dataUrl': self.data_url}
return dict(filter(lambda (k, v): v is not None, metric.items()))

@staticmethod
def parse_tags(tag_string):
if tag_string is None:
return None
else:
tags = ApiMetric.tag_re.split(tag_string)
if "unspecified" in tags:
return list()
else:
return tags

@staticmethod
def metric_type(type, units, slope):
if units == 'timestamp':
return 'timestamp', 's'
if 'int' in type or type == 'float' or type == 'double':
return 'gauge', units
if type == 'string':
return 'text', units
return 'undefined', units

@staticmethod
def is_num(val):
try:
return int(val)
except ValueError:
pass
try:
return float(val)
except ValueError:
return val

def __str__(self):
return "%s %s %s %s %s %s" % (
self.environment, self.grid.name, self.cluster.name, self.host.name, 
self.group, self.name)


class Metric(Elem, ApiMetric):
def __init__(self, elem, host, cluster, grid, environment):
self.host = host
self.cluster = cluster
self.grid = grid
self.environment = environment
Elem.__init__(self, elem)
self.metadata = dict()
for extra_data in elem.findall("EXTRA_DATA"):
for extra_elem in extra_data.findall("EXTRA_ELEMENT"):
name = extra_elem.get("NAME")
if name:
self.metadata[name] = extra_elem.get('VAL')

original_metric_name = self.name

try:
self.metadata['NAME'], self.metadata['INSTANCE'] = 
self.name.split('-', 1)
except ValueError:
self.metadata['INSTANCE'] = ''

if self.name in ['fs_util', 'inode_util']:
if self.instance == 'rootfs':
self.metadata['INSTANCE'] = '/'
else:
self.metadata['INSTANCE'] = '/' + 
'/'.join(self.instance.split('-'))

params = {"environment": self.environment,
  "service": self.grid.name,
  "cluster": self.cluster.name,
  "host": self.host.name,
  "metric": original_metric_name}
url

Re: Urgent - Would like to see output of each block of python

[Chris Rebert]

On Sun, Jun 5, 2016 at 11:57 PM, Archana Sonavane
 wrote:
> Hi Team,
>
> I don't have any idea about python scripts, i have ganglia tool python 
> scripts.
>
> I would like see the output of each code block, could you please guide.
>
> The code as follows:


With regard to your Subject line, please don't attempt to mark posts
as "urgent".
See http://www.catb.org/esr/faqs/smart-questions.html#urgent

Regards,
Chris
-- 
https://mail.python.org/mailman/listinfo/python-list

Would like to see python script output

[Archana Sonavane]

Hello,

I have ganglia python script, i would like to see output of each code block.

Could you please guide. I don't have any idea about python.

My scripts as follows:

#!/usr/bin/env python

#
# ganglia-api.py - Ganglia Metric API
#


from settings import LOGFILE, PIDFILE, API_SERVER, HEARTBEAT

import os
import sys
import glob
import re
import logging
import socket
import select
import datetime
import time
import SocketServer
from xml.etree import ElementTree
from xml.parsers.expat import ExpatError
from urllib import quote
from threading import Thread

import tornado.httpserver
import tornado.ioloop
import tornado.options
import tornado.web
from tornado.options import define, options


__version__ = '1.0.16'

define("port", default=8080, help="run on the given port", type=int)

logging.basicConfig(level=logging.INFO, format="%(asctime)s 
%(name)s[%(process)d] %(levelname)s - %(message)s",
filename=LOGFILE)
global logger
logger = logging.getLogger("ganglia-api")


class Elem:
def __init__(self, elem):
self.elem = elem

def __getattr__(self, name):
return self.elem.get(name.upper())


class NullElem:
def __getattr__(self, name):
return None


class ApiMetric:
tag_re = re.compile("\s+")

def id(self):
group = self.group if self.group is not None else ""
id_elements = [self.environment, self.grid.name, self.cluster.name, 
self.host.name, group, self.name]
return str.lower(".".join(filter(lambda (e): e is not None, 
id_elements)))

def api_dict(self):
type, units = ApiMetric.metric_type(self.type, self.units, self.slope)
metric = {'environment': self.environment,
  'service': self.grid.name,
  'cluster': self.cluster.name,
  'host': self.host.name,
  'id': self.id(),
  'metric': self.name,
  'instance': self.instance,
  'group': self.group,
  'title': self.title,
  'tags': ApiMetric.parse_tags(self.host.tags),
  'description': self.desc,
  'sum': self.sum,
  'num': self.num,
  'value': ApiMetric.is_num(self.val),
  'units': units,
  'type': type,
  'sampleTime': datetime.datetime.fromtimestamp(
  int(self.host.reported) + int(self.host.tn) - 
int(self.tn)).isoformat() + ".000Z",
  'graphUrl': self.graph_url,
  'dataUrl': self.data_url}
return dict(filter(lambda (k, v): v is not None, metric.items()))

@staticmethod
def parse_tags(tag_string):
if tag_string is None:
return None
else:
tags = ApiMetric.tag_re.split(tag_string)
if "unspecified" in tags:
return list()
else:
return tags

@staticmethod
def metric_type(type, units, slope):
if units == 'timestamp':
return 'timestamp', 's'
if 'int' in type or type == 'float' or type == 'double':
return 'gauge', units
if type == 'string':
return 'text', units
return 'undefined', units

@staticmethod
def is_num(val):
try:
return int(val)
except ValueError:
pass
try:
return float(val)
except ValueError:
return val

def __str__(self):
return "%s %s %s %s %s %s" % (
self.environment, self.grid.name, self.cluster.name, self.host.name, 
self.group, self.name)


class Metric(Elem, ApiMetric):
def __init__(self, elem, host, cluster, grid, environment):
self.host = host
self.cluster = cluster
self.grid = grid
self.environment = environment
Elem.__init__(self, elem)
self.metadata = dict()
for extra_data in elem.findall("EXTRA_DATA"):
for extra_elem in extra_data.findall("EXTRA_ELEMENT"):
name = extra_elem.get("NAME")
if name:
self.metadata[name] = extra_elem.get('VAL')

original_metric_name = self.name

try:
self.metadata['NAME'], self.metadata['INSTANCE'] = 
self.name.split('-', 1)
except ValueError:
self.metadata['INSTANCE'] = ''

if self.name in ['fs_util', 'inode_util']:
if self.instance == 'rootfs':
self.metadata['INSTANCE'] = '/'
else:
self.metadata['INSTANCE'] = '/' + 
'/'.join(self.instance.split('-'))

params = {"environment": self.environment,
  "service": self.grid.name,
  "cluster": self.cluster.name,
  "host": self.host.name,
  "metric": original_metric_name}
url = '%s/ganglia/

Re: Spread a class over multiple files

[dieter]

Mark Summerfield  writes:

> Sometimes I want to spread a class over multiple files.

When I run into such a use case, I use (multiple) inheritance --
with "mixin class"es.

Each "mixin class" handles some important aspect and is only loosely
coupled with maybe a common base class and the other aspects.
The main application class integrates the mixin classes via inheritance --
when it needs to handle the respective aspect.

Each mixin class can be implemented in its own file.

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

Re: Urgent - Would like to see output of each block of python

[Archana Sonavane]

On Monday, June 6, 2016 at 12:35:55 PM UTC+5:30, Chris Rebert wrote:
> On Sun, Jun 5, 2016 at 11:57 PM, Archana Sonavane
>  wrote:
> > Hi Team,
> >
> > I don't have any idea about python scripts, i have ganglia tool python 
> > scripts.
> >
> > I would like see the output of each code block, could you please guide.
> >
> > The code as follows:
> 
> 
> With regard to your Subject line, please don't attempt to mark posts
> as "urgent".
> See http://www.catb.org/esr/faqs/smart-questions.html#urgent
> 
> Regards,
> Chris

Ok.. Sorry, next time will take care.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: I'm wrong or Will we fix the ducks limp?

[Marko Rauhamaa]

Random832 :

> On Sun, Jun 5, 2016, at 15:20, Marko Rauhamaa wrote:
>> I say None is a wooden post, you say None is a puppy.
>> 
>> What piece of Python code could put our dispute to rest?
>
> isinstance(None, object)

Well, the wooden post is an object as are all puppies.

It's bad enough to objectify sentient beings; I just don't have the
heart to put a cute, fluffy puppy in the role of None. The fact that
CPython does that could be considered animal cruelty.


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

ANN: eGenix PyRun - One file Python Runtime 2.2.1

[eGenix Team: M.-A. Lemburg]

ANNOUNCING

eGenix PyRun - One file Python Runtime

Version 2.2.1


   An easy-to-use single file relocatable Python run-time -
  available for Linux, Mac OS X and Unix platforms,
  with support for Python 2.6, 2.7, 3.4 and
 * now also for Python 3.5 *


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



INTRODUCTION

eGenix PyRun is our open source, one file, no installation version of
Python, making the distribution of a Python interpreter to run based
scripts and applications to Unix based systems as simple as copying a
single file.

eGenix PyRun's executable only needs 11MB for Python 2 and 13MB for
Python 3, but still supports most Python application and scripts - and
it can be compressed to just 3-4MB using upx, if needed.

Compared to a regular Python installation of typically 100MB on disk,
eGenix PyRun is ideal for applications and scripts that need to be
distributed to several target machines, client installations or
customers.

It makes "installing" Python on a Unix based system as simple as
copying a single file.

eGenix has been using eGenix PyRun internally in the mxODBC Connect
Server product since 2008 with great success and decided to make it
available as a stand-alone open-source product.

We provide both the source archive to build your own eGenix PyRun, as
well as pre-compiled binaries for Linux, FreeBSD and Mac OS X, as 32-
and 64-bit versions. The binaries can be downloaded manually, or you
can let our automatic install script install-pyrun take care of the
installation: ./install-pyrun dir and you're done.

Please see the product page for more details:

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



NEWS

This minor level release of eGenix PyRun comes with the following
enhancements:

Enhancements / Changes
--

 * Fixed support for -u command line option with Python 3. Since this
   is used by pip since version 8.0, it also removes issues with pip.

 * Removed ensurepip package from PyRun since this only works with
   access to the bundled whl files. This is incompatible with the
   frozen nature of packages in PyRun.

 * Added support for setting the OpenSSL path to the Makefile and have
   it look in /usr/local/ssl before reverting to system dirs to make
   it easier to link against more recent builds of OpenSSL.

 * Linking against OpenSSL 1.0.2 now on Mac OS X for the precompiled
   pyrun binaries. You may have to set your shared linker path to
   point to the right OpenSSL version.


install-pyrun Quick Install Enhancements
-

eGenix PyRun includes a shell script called install-pyrun, which
greatly simplifies installation of PyRun. It works much like the
virtualenv shell script used for creating new virtual environments
(except that there's nothing virtual about PyRun environments).

https://downloads.egenix.com/python/install-pyrun

With the script, an eGenix PyRun installation is as simple as running:

./install-pyrun targetdir

This will automatically detect the platform, download and install the
right pyrun version into targetdir.

We have updated this script since the last release:

 * Fixed install-pyrun to work with new PyPI package URL scheme (see

https://bitbucket.org/pypa/pypi/issues/438/backwards-compatible-un-hashed-package).
The
   options --pip-version=latest et al. should now work again.

 * Updated install-pyrun to default to eGenix PyRun 2.2.1 and its
   feature set.

For a complete list of changes, please see the eGenix PyRun Changelog:

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



LICENSE

eGenix PyRun is distributed under the eGenix.com Public License 1.1.0
which is an Open Source license similar to the Python license. You can
use eGenix PyRun in both commercial and non-commercial settings
without fee or charge.

Please see our license page for more details:

http://www.egenix.com/products/python/PyRun/license.html

The package comes with full source code.



DOWNLOADS

The download archives and instructions for installing eGenix PyRun can
be found at:

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

As always, we are providing pre-built binaries for all common
platforms: Windows 32/64-bit, Linux 32/64-bit, FreeBSD 32/64-bit, Mac
OS X 32/64-bit. Source code archives are available for installation on
other platforms, such as Solaris, AIX, HP-UX, etc.

___

SUPPORT

Re: I'm wrong or Will we fix the ducks limp?

[Antoon Pardon]

Op 06-06-16 om 05:52 schreef Steven D'Aprano:
> On Mon, 6 Jun 2016 03:42 am, Random832 wrote:
>
>> On Sun, Jun 5, 2016, at 02:37, Steven D'Aprano wrote:
>>> No they don't. You are confusing the implementation with the programming
>>> model.
>>>
>>> Following the assignment:
>>>
>>> x = 99
>>>
>>> if you print(x), do you see something like "reference 0x12345"? No.
>>>
>>> Do you have to dereference that reference to get the value of x? No.
>>>
>>> At the Python level, the value of x is 99, not some invisible,
>>> untouchable reference to 99.
>> Sure, but that is the value of the object referenced by x, it is not a
>> property of x itself.
> You need to be clear about what you are referring to.
>
> x itself is the object 99. When we say "x + 1", we expect to get 100. x is
> not some reference to 99, it is 99, just like Barrack Obama is not a
> reference to the President of the United States, he is the POTUS.

x is not the object 99. x is a variable that refers to an object that
has the value 99. That python starts looking for that object and
uses its value when your do arithmatics doesn't contradict that variables
refer to objects.

A reference is not pointer. When you use a reference parameter in Pascal,
it behave like an ordinary parameter within the procedure block, you don't
have to treat it like a pointer.

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

Trying to pass sys.argv as (int argc, char **argv) using ctypes

[Mark Summerfield]

Hi,

I have a setup roughly like this:

import ctypes
import sys

Lib = ctypes.cdll.LoadLibrary("libthing")

c_char_pp = ctypes.POINTER(ctypes.c_char_p)

LibOpen = Lib.Open
LibOpen.argtypes = (ctypes.c_int,   # argc
c_char_pp)  # argv
LibOpen.restype = ctypes.c_int


argc = ctypes.c_int(len(sys.argv))
Args = ctypes.c_char_p * len(sys.argv)
args = Args(*[ctypes.c_char_p(arg.encode("utf-8"))
  for arg in sys.argv])
argv = ctypes.pointer(args)
LibOpen(argc, ctypes.byref(argv))

But when run it produces an error:

ctypes.ArgumentError: argument 2: : expected LP_c_char_p 
instance instead of pointer to LP_c_char_p_Array_1

or this if I use LibOpen(argc, argv):

ctypes.ArgumentError: argument 2: : expected LP_c_char_p 
instance instead of LP_c_char_p_Array_1


I understand what it is telling me; but I don't know or understand ctypes well 
enough to fix it. I guess I need to convert the array pointer to a char ** 
pointer? Can anyone tell me, or point me to info that would help?

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

Re: I'm wrong or Will we fix the ducks limp?

[Marko Rauhamaa]

Antoon Pardon :

> A reference is not pointer. When you use a reference parameter in
> Pascal, it behave like an ordinary parameter within the procedure
> block, you don't have to treat it like a pointer.

The word "reference" as used in the Python standards documentation is
not the same as "reference parameter in Pascal." Even more confusing, we
have "The Python Language Reference," which uses the word in yet a third
meaning!

Python's reference *is* indeed a pointer, even though there's usually no
need to bring the word "pointer" in the discussion. A "reference",
"pointer", "arrow", "leash", "morphism" etc are abstract thingies that
connect a starting point to an endpoint. (No wonder Java, whose
terminology involves references as well, sports a NullPointerException.)


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

Re: I'm wrong or Will we fix the ducks limp?

[Chris Angelico]

On Mon, Jun 6, 2016 at 2:08 PM, Random832  wrote:
> My statement was that if two variables can be bound to the same object,
> then variables *cannot* contain objects. The object has to exist
> somewhere, and this requirement means that the variables cannot be where
> the objects live.

Then the problem is with your notion of containment. Have a think
about TARDISes, and the place the Narnians got to after the Last
Battle, and Bags of Holding, and various other related concepts. It's
perfectly possible for something to be 'inside' more than one thing at
once.

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

Re: Operator precedence problem

[Gary Herron]

On 06/04/2016 11:53 PM, ICT Ezy wrote:

2 ** 3 ** 2

Answer is 512
Why not 64?
Order is right-left or left-right?


Evidently right to left, but you already figured that out.

Python 3.5.1+ (default, Mar 30 2016, 22:46:26)
[GCC 5.3.1 20160330] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 2 ** 3 ** 2
512
>>> 2 ** (3 ** 2)
512
>>> (2 ** 3) ** 2
64
>>>


Here's the relevant documentation page:
https://docs.python.org/3/reference/expressions.html
Look for "... except for exponentiation, which groups from right to left"

Gary Herron

--
Dr. Gary Herron
Professor of Computer Science
DigiPen Institute of Technology
(425) 895-4418

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

Re: I'm wrong or Will we fix the ducks limp?

[BartC]

On 05/06/2016 07:37, Steven D'Aprano wrote:

On Sun, 5 Jun 2016 01:17 pm, Lawrence D’Oliveiro wrote:


On Saturday, June 4, 2016 at 3:55:12 AM UTC+12, Matt Wheeler wrote:

It's best to think of them as names, rather than variables, as names in
python don't behave quite how you'll expect variables to if you're coming
from some other languages.


I have made heavy use of Python as well as many other languages, and I
don’t know what you mean. What “other languages” are you thinking of?

Are variables like little boxes? Yes they are.


That's *exactly* what variables in Python are not like.


People can imagine a box around a variable name if they like.

The confusion might arise when they think the value attached to the name 
is in the same box. But often, for variables holding or referring to 
simple scalar values, it doesn't matter.





But they are all the same
size, while objects may be large (even very large) or small. That is why
variables hold, not objects, but references to objects.


No they don't. You are confusing the implementation with the programming
model.

Following the assignment:

x = 99

if you print(x), do you see something like "reference 0x12345"? No.


Nearly every high level language will perform an automatic dereference 
in such cases, between the written name of the variable (that sometimes 
corresponds to its /address/), and its value (for example, the contents 
of that address).


In Python there might well be a double dereference, from name to 
location, which contains an object reference, and from the object 
reference to the value that is printed.


While Python can give you access to the object reference rather than the 
object value, AFAIK you can't get the location where that object 
reference is stored for that variable. All you have is the name.


So for Python it makes more sense to have two boxes, one for the name, 
and another for the object value. With an arrow between the two. (Among 
other things, this allows same object to be shared between several 
variables: multiple boxed variable names all pointing to the same object 
box.)


But again, in the case of simple, immutable types, and where the 
variable always keeps the same type as is usually the case, there is no 
real problem in showing "x" and "99" in the same box, or "99" in the box 
and "x" immediately outside:


 x:[99]

instead of:

 x:[0x12345] -> 0x12345:[99]

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

Re: Would like to see python script output

[Michael Selik]

On Mon, Jun 6, 2016 at 3:12 AM Archana Sonavane 
wrote:

> I have ganglia python script, i would like to see output of each code
> block.
>
> Could you please guide. I don't have any idea about python.
>

Do you know how to run a Python script?

Have you read through the Python tutorial?
https://docs.python.org/3/tutorial/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Don't put your software in the public domain

[Paul Rudin]

Nobody  writes:

> On Sat, 04 Jun 2016 12:28:33 +1000, Steven D'Aprano wrote:
>
>>> OTOH, a Free software licence is unilateral; the author grants the user
>>> certain rights, with the user providing nothing in return.
>> 
>> That's not the case with the GPL.
>> 
>> The GPL requires the user (not the end-user, who merely avails themselves
>> of their common law right to run the software, but the developer user, who
>> copies, distributes and modifies the code) to do certain things in return
>> for the right to copy, distribute and modify the code:
>
> The GPL places limitations on the granted licence. That isn't the same
> thing as requiring the distributor to do something "in return".
>

The distributor grants the licence.

> This is why the (relatively few) cases where GPL infringements have
> resulted in litigation, the legal basis of the litigation is copyright
> infringement, not breach of contract.

Right, but the defence is that the licence grants permission to use; so
that's where the law if contract comes into it. You have to figure out
whether the use in question falls within the licence terms.

So if someone brings an action for copyright infringement you can argue
at least some of:

1. Copyright doesn't subsist in the copied material.
2. You didn't copy it.
3. One of the legal defences (fair use etc.) applies.
4. You had the permission of the copyright owner (i.e. a licence to copy
in these circumstances).


In the last case we're essentially into contract law.


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

Re: Anyone know a donation app codebase?

[Michael Selik]

On Sun, Jun 5, 2016 at 3:26 PM Ben Finney 
wrote:

> Albert  writes:
>
> > Thank you for your answer Ben,
>
> You're welcome. Please note that top-posting is poor etiquette for
> discussions; instead, interleave your response like a written dialogue.
> See https://en.wikipedia.org/wiki/Posting_style#Interleaved_style>.
>
> > That is not exactly what I am looking for. I am interested in knowing
> > if there are any python (django, flask, etc) opensource projects for
> > managing donations
>
> Again, PyPI is the place to search
>  https://pypi.python.org/pypi?:action=search&term=django%20donation&submit=search
> >.
>

I tried the Google search engine. Looking up the phrase "python managing
donations catarse" the 2nd search result was this a website which appears
to list several packages in different programming languages.
http://seedingfactory.com/index.html%3Fp=634.html
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Taking two and more data frames and extracting data on unique keys in python

[Michael Selik]

On Sun, Jun 5, 2016 at 7:05 AM Danish Hussain  wrote:

> Please me know if clarification is needed.
>

Could you clarify what your question is? Did you encounter an error while
coding the solution?
-- 
https://mail.python.org/mailman/listinfo/python-list

errorhandler 2.0.0 Released!

[Chris Withers]

Hi All,

errorhandler is a tiny but useful logging handler for the python logging 
framework. It lets you tell when logging above a certain level has 
occurred, even if it's not in code you can control.


I'm pleased to announce the release of errorhandler 2.0.0 featuring the 
following:


- Support for Python 3

- Documentation on Read The Docs

- Continuous testing using Travis CI

- Code coverage reporting through Coveralls

The package is on PyPI and a full list of all the links to docs, issue 
trackers and the like can be found here:


https://github.com/Simplistix/errorhandler

Any questions, please do ask on the Testing in Python list or on the 
Simplistix open source mailing list...


cheers,

Chris

--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
--
https://mail.python.org/mailman/listinfo/python-list

Re: errorhandler 2.0.0 Released!

[Pavel S]

Hi,
can you explain, why is the attribute 'fired' class-level and not 
instance-level? There must be good reason for modifying class attribute from 
instance.


Dne pondělí 6. června 2016 15:26:08 UTC+2 Chris Withers napsal(a):
> Hi All,
> 
> errorhandler is a tiny but useful logging handler for the python logging 
> framework. It lets you tell when logging above a certain level has 
> occurred, even if it's not in code you can control.
> 
> I'm pleased to announce the release of errorhandler 2.0.0 featuring the 
> following:
> 
> - Support for Python 3
> 
> - Documentation on Read The Docs
> 
> - Continuous testing using Travis CI
> 
> - Code coverage reporting through Coveralls
> 
> The package is on PyPI and a full list of all the links to docs, issue 
> trackers and the like can be found here:
> 
> https://github.com/Simplistix/errorhandler
> 
> Any questions, please do ask on the Testing in Python list or on the 
> Simplistix open source mailing list...
> 
> cheers,
> 
> Chris
> 
> -- 
> Simplistix - Content Management, Batch Processing & Python Consulting
>  - http://www.simplistix.co.uk

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

Re: Trying to pass sys.argv as (int argc, char **argv) using ctypes

[eryk sun]

On Mon, Jun 6, 2016 at 9:50 AM, Mark Summerfield  wrote:
>
> Lib = ctypes.cdll.LoadLibrary("libthing")

Use ctypes.CDLL('libthing'). It's simpler, plus it's the only way to
pass the handle, mode, and use_errno parameters if you need them.

> LibOpen.restype = ctypes.c_int

This line isn't required because c_int is the default result type.

> argc = ctypes.c_int(len(sys.argv))

ctypes automatically converts integer arguments that are passed by
value. You only need to create a c_int when you're passing by
reference.

> Args = ctypes.c_char_p * len(sys.argv)

The argv array in ANSI C should have length `argc + 1`. There's a
final null terminator, even though it's redundant given the argc
count.

> args = Args(*[ctypes.c_char_p(arg.encode("utf-8"))
>   for arg in sys.argv])

There's no need to create a list just to unpack it. You can use a for
loop to populate the array directly. Also, you don't have to manually
instantiate c_char_p instances when storing the elements of a c_char_p
array; the base type's getfunc will convert Python byte strings.

Also, since the function signature isn't `const char **`, you should
use ctypes.create_string_buffer just in case the function expects to
be able to modify the argv strings. This requires switching from using
c_char_p to a more generic POINTER(c_char).

> argv = ctypes.pointer(args)
> LibOpen(argc, ctypes.byref(argv))

C array arguments are passed as a pointer to the first element. You
don't have to manually create a pointer. And if you do, certainly you
shouldn't pass it by reference. That mistakenly passes a pointer to
the pointer to the first element of the argv array (which is a pointer
to the first character in the first string argument). Naturally you
get the following error:

> expected LP_c_char_p instance instead of pointer to LP_c_char_p_Array_1

Due to limitations in ctypes you also get the following error when you
pass the pointer by value:

> expected LP_c_char_p instance instead of LP_c_char_p_Array_1

Only passing the array directly is special cased for this to work.

Try the following code:

import sys
import ctypes

lib = ctypes.CDLL('libthing')

LP_c_char = ctypes.POINTER(ctypes.c_char)
LP_LP_c_char = ctypes.POINTER(LP_c_char)

lib.LibOpen.argtypes = (ctypes.c_int, # argc
LP_LP_c_char) # argv

argc = len(sys.argv)
argv = (LP_c_char * (argc + 1))()
for i, arg in enumerate(sys.argv):
enc_arg = arg.encode('utf-8')
argv[i] = ctypes.create_string_buffer(enc_arg)

lib.LibOpen(argc, argv)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Operator precedence problem

[Random832]

On Mon, Jun 6, 2016, at 01:46, Lawrence D’Oliveiro wrote:
> On Monday, June 6, 2016 at 4:06:20 AM UTC+12, Uri Even-Chen wrote:
> > Never write expressions, such as  2 ** 3 ** 2 or even 2 * 4
> > + 5, without parentheses.
> 
> That leads to the code equivalent of
> .

Okay, can we settle on, as a principle, "the basic arithmetic operators
(not to include **)  are the only ones whose precedence can be presumed
to be obvious to all readers, and other expressions may/should have
parentheses to make it more clear, even when not strictly necessary to
the meaning of the expression"?

Sure, it's obvious to _me_ that << and >> have higher precedence than &
and |, and that "and" has a higher precedence than "or", but can I
assume the other people know this? And I don't know offhand the relative
precedence of non-conceptually-related groups of operators, except that
I'm pretty sure "and" and "or" have very low precedence.

[To keep this on-topic, let's assume that this discussion has a goal of
getting something along the lines of "always/sometimes/never use
"unnecessary" parentheses" into PEP7/PEP8. Speaking of, did you know
that C has lower precedence for the bitwise operators &^| than for
comparisons? That was something that tripped me up for a very long time
and undermined my confidence as to other aspects of the bitwise
operators]
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Trying to pass sys.argv as (int argc, char **argv) using ctypes

[Mark Summerfield]

Thanks, that works! And also thanks for the excellent explanations of each part.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Operator precedence problem

[Marko Rauhamaa]

Random832 :

> Sure, it's obvious to _me_ that << and >> have higher precedence than &
> and |, and that "and" has a higher precedence than "or", but can I
> assume the other people know this?

No need to assume. Just read the spec:

   lambda Lambda expression
   if – else  Conditional expression
   or Boolean OR
   andBoolean AND
   not x  Boolean NOT
   in, not in, is, is not, <, <=, >, >=, !=, ==
  Comparisons, including membership tests and identity
  tests
   |  Bitwise OR
   ^  Bitwise XOR
   &  Bitwise AND
   <<, >> Shifts
   +, -   Addition and subtraction
   *, @, /, //, % Multiplication, matrix multiplication division,
  remainder [5]
   +x, -x, ~x Positive, negative, bitwise NOT
   ** Exponentiation [6]
   await xAwait expression
   x[index], x[index:index], x(arguments...), x.attribute
  Subscription, slicing, call, attribute reference
   (expressions...), [expressions...], {key: value...}, {expressions...}
  Binding or tuple display, list display, dictionary
  display, set display

   https://docs.python.org/3/reference/expressions.html#operat
   or-precedence>

> [To keep this on-topic, let's assume that this discussion has a goal of
> getting something along the lines of "always/sometimes/never use
> "unnecessary" parentheses" into PEP7/PEP8. Speaking of, did you know
> that C has lower precedence for the bitwise operators &^| than for
> comparisons? That was something that tripped me up for a very long time
> and undermined my confidence as to other aspects of the bitwise
> operators]

Yes, I happened to know that. Python's the same way.

However, no need to memorize. It's all there in the spec. Same as with
stdlib functions. Keep checking the spec.

You *can* assume other people have read the spec. Even more importantly,
you can assume the Python interpreter complies with the spec.


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

Re: I'm wrong or Will we fix the ducks limp?

[jfine2358]

On Friday, June 3, 2016 at 3:20:42 PM UTC+1, Sayth Renshaw wrote:

> pyqFiles = []
> for filename in sorted(file_list):
> pyqFiles = pyqFiles.append(pq(filename=my_dir + filename))

This won't end well. The return value from [].append(...) is None.

>>> [].append(0) is None
True

The first time through the loop pqFiles is set to the return value of 
pqFile.append(...), which is None. 

The second time through, you'll get:
AttributeError: 'NoneType' object has no attribute 'append'


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

Re: Operator precedence problem

[Random832]

On Mon, Jun 6, 2016, at 10:22, Marko Rauhamaa wrote:
> You *can* assume other people have read the spec. Even more importantly,
> you can assume the Python interpreter complies with the spec.

I can assume the python interpreter will accept tabs as indents too,
that doesn't make it good style.

Requiring people to constantly flip between my code and the language
reference to understand it is also not good style.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: OT: limit number of connections from browser to my server?

[Grant Edwards]

On 2016-05-16, Grant Edwards  wrote:

[...]
> Is there any way to limit the number of connections a browser uses to
> download a web page?  Browser writers seems to assume that all https
> servers are massively parallel server farms with hardware crypto
> support.

In case anybody is still wondering about this...

Various experiments have shown that if you try limit the number of
connections, browsers will fall over and not load the page completely.
You have to allow as many parallel connecitons as some addle-headed
browser devleoper wants to open -- no matter how counter-productive it
is.

I added chunked transfer encoding support to my web server so that all
connections can be kept open and re-used.  I also added a sepearte
thread to handle SSL handshaking at a lower priority so that opening a
new SSL connection doesn't block servicing requests on already open
connections.

Warm page loads are now around 1.8 seconds for all three browsers (IE,
Chrome, Firefox -- I don't have access to Safari).

On IE and Chrome, the above changes reduced cold page load times from
10-20 seconds to around 4.5 seconds.  Apparently, IE and Chrome are
sane enough to send reuqests on any idle idle connection.  So, the
entire page loads via the first connection once its SSL handshake
completes (which takes 3.5 seconds).  They still insist on opening 4-6
connections (a process which continues for 10-15 seconds after the
page has finished loading), but only the first one actually gets used
for the initial page load.

Cold load time for Firefox is still 20 seconds. Firefox seems to be
unable to pull its head out of it's arse and will sit there for 15
seconds waiting for that 6th connection to open while ignoring the
five idle connections it already has open.

The only thing I can think of to help cold page loads with Firefox is
to reduce the number of requests it has to send:

  1) Pre-process CSS and HTML files to embed images as base64 data
 instead of having the browser fetch them separately.

  2) Use preprocessing or server-side includes so that Javascript is
 embedded in the main page HTML instead of being fetched
 separately.

There are still 1-2 files that for logistical reasons I want to keep
separate, so perhaps adding Cache-Control headers to tell the browser
it can cache those files will help in cases where there are no open
connections but it's not the absolute first time the browser has seen
the device.  If I could get one particular file (jQuery-min) to be
cached, that would reduce warm page loads by 60% also.

-- 
Grant Edwards   grant.b.edwardsYow! I have seen these EGG
  at   EXTENDERS in my Supermarket
  gmail.com... I have read the
   INSTRUCTIONS ...

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

Re: Operator precedence problem

[Jon Ribbens]

On 2016-06-06, Marko Rauhamaa  wrote:
> Random832 :
>> Sure, it's obvious to _me_ that << and >> have higher precedence than &
>> and |, and that "and" has a higher precedence than "or", but can I
>> assume the other people know this?
>
> No need to assume. Just read the spec:

The spec tells you the overlap between the set of all people who will
ever read your code and the set of people who have memorised the
entire list of operator precedences in the spec?

That's one impressive spec.

> You *can* assume other people have read the spec. Even more importantly,
> you can assume the Python interpreter complies with the spec.

Obviously the latter is true (or at least, it's true except when it's
false). The former however is not true. You should put brackets around
expressions when it's at all unclear what the meaning is. You could
think of them a bit like "active comments" I suppose.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Operator precedence problem

[Marko Rauhamaa]

Random832 :

> On Mon, Jun 6, 2016, at 10:22, Marko Rauhamaa wrote:
>> You *can* assume other people have read the spec. Even more
>> importantly, you can assume the Python interpreter complies with the
>> spec.
>
> I can assume the python interpreter will accept tabs as indents too,
> that doesn't make it good style.
>
> Requiring people to constantly flip between my code and the language
> reference to understand it is also not good style.

I cannot guess at people's familiarity with the spec. In fact, there's
nobody in the world who masters the whole standard library, for example.
That's not a reason to start avoiding parts of the stdlib functions.

BTW, whenever I'm programming Python, I have the stdlib refererence open
next to the editor. Believe me, I keep consulting the spec all the time.

Operator precedence is a small table, of course, and it is not bad style
to assume familiarity with it.


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

Re: Operator precedence problem

[Jon Ribbens]

On 2016-06-06, Marko Rauhamaa  wrote:
> Jon Ribbens :
>> On 2016-06-06, Marko Rauhamaa  wrote:
>>> You *can* assume other people have read the spec. Even more
>>> importantly, you can assume the Python interpreter complies with the
>>> spec.
>>
>> Obviously the latter is true (or at least, it's true except when it's
>> false). The former however is not true.
>
> Well, of course nobody knows the whole spec. However, you should write
> your code assuming they do.

That sounds like bad advice to me I'm afraid. Assume they're
moderately competent, sure. Assume they know 100% of the entire spec
in all its detail? That's an assumption that will be false pretty much
100% of the time.

>> You should put brackets around expressions when it's at all unclear
>> what the meaning is. You could think of them a bit like "active
>> comments" I suppose.
>
> Your code should keep noise to the minimum.

Sensible and beneficial comments aren't "noise".
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Operator precedence problem

[Marko Rauhamaa]

Jon Ribbens :

> On 2016-06-06, Marko Rauhamaa  wrote:
>> You *can* assume other people have read the spec. Even more
>> importantly, you can assume the Python interpreter complies with the
>> spec.
>
> Obviously the latter is true (or at least, it's true except when it's
> false). The former however is not true.

Well, of course nobody knows the whole spec. However, you should write
your code assuming they do. Different people have different gaps in
their knowledge:

 * Somebody might not be aware of chained comparisons: a < b < c

 * Somebody might not know of the "else" branch of a "for" statement.

 * Somebody might not know of the if-else expression: a if b else c

However, there's no need to avoid those facilities that are there for
people to use them. What people are unclear about they can check in the
spec, which is readily available.

> You should put brackets around expressions when it's at all unclear
> what the meaning is. You could think of them a bit like "active
> comments" I suppose.

Your code should keep noise to the minimum.


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

Re: I'm wrong or Will we fix the ducks limp?

[Steven D'Aprano]

On Mon, 6 Jun 2016 02:08 pm, Random832 wrote:

> On Sun, Jun 5, 2016, at 23:52, Steven D'Aprano wrote:
>> Certainly not. x = y = 999 is required to bind the same object to x and
>> y.
> 
> My statement was that if two variables can be bound to the same object,
> then variables *cannot* contain objects. The object has to exist
> somewhere,

I could dispute that assertion, e.g. consider what happens when you simulate
a Python interpreter in your brain. What is the location of the objects
then? As best as we can tell from neuroscience, memories are distributed
across fairly large swaths of neurons.

But that's not the point. Even if you were right that objects must exist at
a single well-defined location, that is strictly irrelevant. That's
implementation, not interface. There is nothing in the specification of the
Python virtual machine and the execution model that requires objects have a
single location. That's just the way they happen to be easy to write on
current generation computers.


> and this requirement means that the variables cannot be where 
> the objects live.

I don't care. That's just implementation. There is nothing in the Python
programming language that says "x = 999" makes x an indirect reference to
999. The very thought is absurd.

I have tried to see things from your perspective. I completely agree that,
at the implementation level, Python variables are implemented as references
(in CPython, pointers) to objects. We all agree on that. Yay! We have
partial agreement!

But it really, truly is absurd to insist that AT THE PYTHON LEVEL variables
are references. That's as foolish as insisting that the President of the
United States is two words with eleven letters, not a man.

Surely you can acknowledge that the language we use to explain things will
depend on the level of physical phenomena we are looking at? If we can't
agree on that, then there's no point in continuing this conversation.

At the Python virtual machine level, x is the object 999. This is the most
important level, because we're actually talking about Python code. The
whole point of this is to understand what the Python VM does, so we can
reason about code. Every thing else is, in general, obfuscation, to a
lesser or greater degree.

At the C implementation level, x is an entry in a hash table, a pointer
pointing at an object in the heap. Occasionally it is useful to bring the
discussion down to this level, but not often.

At the assembly language level, x is probably a 32-bit or 64-bit word,
depending on whether you have a 32-bit or 64-bit build. Assigning to a
variable is a matter of copying memory from one location to another.

At a lower level still (machine code? microcode?), we don't copy memory, we
flip bits. x will be a series of bits. There's not much interesting to say
at this level: whether x is 999 or a HTTPServer object or None, it's still
just a series of bits.

At the hardware level, considered as a DRAM unit (other types of memory use
different implementations), x is a set of microscopic capacitors holding
tiny electric charges representing either a "high" or "low" charge, i.e.
bits.

At the hardware level below that, we have to start talking about the
properties of impure silicon, electrons in atomic shells, so-called
electron holes, etc. Given x = 999, x will be any of a large number of sets
of electron distributions, involving millions(?) of electrons. A few
thousand more or less in any one specific chunk of silicon will make no
difference: there are many, many physical states that x could be.

And below that, we start talking about quantum probability functions, and
surely we can agree that it is absurd to say that Python variables are
really quantum probability functions!

Can you at least met me there? Can we agree that, while it is absolutely
true and correct that Python variables are really implemented as quantum
waves, this fact is of absolutely no use to anyone trying to understand
what a snippet of Python code does?



>> If your variable x were a reference, then we would expect type(x) to
>> return
>> something like "Reference", but it doesn't, it returns int.
> 
> No we would not. You are once again inferring meaning that people's
> statements don't actually carry.

In the plain English meaning of the words, if is an int, then it behaves as
an int, and if you use introspection on it, it will look like an int. If x
is a string, then it similarly behaves as, and looks like, a string. So if
x is a reference, what should it behave as? A wheelbarrow?

I cannot help that you want to describe x as being a reference while denying
that it behaves as a reference or can be introspected as looking like a
reference. You could equally say it is really, actually a set of bits, or
charges in an integrated circuit, or electrons in atomic shells.


-- 
Steven

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

Re: Operator precedence problem

[Chris Angelico]

On Tue, Jun 7, 2016 at 1:27 AM, Jon Ribbens
 wrote:
>>> You should put brackets around expressions when it's at all unclear
>>> what the meaning is. You could think of them a bit like "active
>>> comments" I suppose.
>>
>> Your code should keep noise to the minimum.
>
> Sensible and beneficial comments aren't "noise".

In that case, please never insult the intelligence of your future
readers by including any of these parentheses:

x = 1 + (2 * 3)
value = 77 if (x % 2) else (70*7)

And if your readers have to figure out what 3**3**3 is interpreted as,
there should be an interactive interpreter around. Or here - try
something cute:

>>> 2**2**-1

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

Re: Don't put your software in the public domain

[Steven D'Aprano]

On Mon, 6 Jun 2016 03:54 pm, Nobody wrote:

> On Sat, 04 Jun 2016 12:28:33 +1000, Steven D'Aprano wrote:
> 
>>> OTOH, a Free software licence is unilateral; the author grants the user
>>> certain rights, with the user providing nothing in return.
>> 
>> That's not the case with the GPL.
>> 
>> The GPL requires the user (not the end-user, who merely avails themselves
>> of their common law right to run the software, but the developer user,
>> who copies, distributes and modifies the code) to do certain things in
>> return for the right to copy, distribute and modify the code:
> 
> The GPL places limitations on the granted licence. That isn't the same
> thing as requiring the distributor to do something "in return".

Read the GPL. I already linked to it. The GPL explicitly and implicitly
requires that the distributor do certain things, and avoid doing others. It
implicitly requires that the distribute give up their right to keep the
code a trade secret. (It cannot be a trade secret if it is released under a
FOSS licence.) It explicitly requires the distributor to make the source
code available under the GPL. All these things are sufficient to make the
GPL a contract.

All this is covered in my previous post that links to a paper on the
enforceability of the GPL, written by an actual lawyer. If you haven't read
that, please don't argue until you do. Its all covered in the paper.


> This is why the (relatively few) cases where GPL infringements have
> resulted in litigation, the legal basis of the litigation is copyright
> infringement, not breach of contract.

That's factually incorrect. The only case (that I know of) where the GPL was
actually fought out in front of a judge was in Germany, and it was treated
as a breach of contract. The GPL is legally a contract, and if the
distributor fails to live up to their end of the contract (namely, the
requirement to publish their program under the GPL), then they have no
right to distribute, copy or modify the GPLed code. If they do, then they
are infringing copyright.

Again, this is all covered in the paper.


-- 
Steven

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

Re: Operator precedence problem

[Jon Ribbens]

On 2016-06-06, Chris Angelico  wrote:
> On Tue, Jun 7, 2016 at 1:27 AM, Jon Ribbens
> wrote:
 You should put brackets around expressions when it's at all unclear
 what the meaning is. You could think of them a bit like "active
 comments" I suppose.
>>>
>>> Your code should keep noise to the minimum.
>>
>> Sensible and beneficial comments aren't "noise".
>
> In that case, please never insult the intelligence of your future
> readers by including any of these parentheses:
>
> x = 1 + (2 * 3)

I'm not sure what your point is. Yes, obviously you can take anything
to ridiculous extremes - that's why I said "sensible".

> value = 77 if (x % 2) else (70*7)

I'm not convinced that one isn't actually a good idea. It does seem
to aid the readability (especially if you space '70 * 7' properly).
If the expressions were any more complex then it would be even more
likely to be a good idea.

> And if your readers have to figure out what 3**3**3 is interpreted as,
> there should be an interactive interpreter around. Or here - try
> something cute:
>
 2**2**-1

I can't tell now if you're agreeing with me or disagreeing, because
you started out sounding like you were disagreeing but then provided
an example that helps prove my point.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: I'm wrong or Will we fix the ducks limp?

[Steven D'Aprano]

On Mon, 6 Jun 2016 04:37 pm, Gregory Ewing wrote:

> Steven D'Aprano wrote:
>> The *name* "x" is an entity which is bound to (i.e. a reference to) the
>> object 99, in some specific namespace, at some specific time. The name
>> itself is an English word consisting of a single letter, "x".
> 
> This is one reason why the term "name" is not good subsitute
> for the term "variable". The string "x" is not the same thing
> as the variable x, a fact that's obscured if you call the
> variable a "name".

I never said that the string "x" is the same thing as the variable x. I made
it clear, well I thought it was clear, that the *implementation* of names
in CPython uses string keys in dictionaries, but that's not what a name is.
A name is just a abstract, human-readable label. We prefer meaningful names
like "x" or "number_of_pages", but an interpreter could use 64-bit
cryptographic hashes or UUIDs or whatever it likes.

(A Python interpreter would have to find some way to map those UUIDs back to
human readable strings, so that we can call vars() or globals() or
equivalent and see the names we expect. But another language need not do
that.)


> A better analogy along the presidential line would be the
> name "President of the United States". That name can refer
> to different people at different times, so there must be
> some piece of state in the world that records the association
> between the character string "President of the United States"
> and the person who currently holds that office.

How ironic, after telling me off for saying that variables were strings
(which I didn't do), you're now talking about the POTUS being a "character
string".

You are right that there must be some piece of state that associates the
label "POTUS" or "Barack Obama" with the man. That's the essential feature
of a name binding. In human languages, we generally use words for labels.
(Sometimes we use numbers, as in "Prisoner 23848".) But we also need to
distinguish between talking about the POTUS and talking about the
*label* "POTUS", and the usual way of doing that in English is as I just
did, but putting it in quotation marks, or referring to it as "the word
POTUS", or some other equivalent phrase.


> It's that piece of state that the OP is calling a "box".
> I don't know what form it actually takes, probably an
> official piece of paper somewhere, which may well be
> kept in a box. But the box doesn't contain Barack Obama
> himself, it only contains something that refers to him.

Yes. And? 

Two points:

(1) When we refer to Barack Obama, we're not referring to his birth
certificate, and when we refer to the POTUS, we're not referring to this
hypothetical box where the official piece of paper resides. We're referring
to the man. Just as when we refer to the x in "x = 999", we mean 999, not
some analogue to a birth certificate or certificate of being president.

(2) The "variables are like boxes" metaphor applies to static languages like
C and Pascal, where the compiler has knowledge of what variables will
exist. Such languages allocate space for the variables at compile time,
usually using fixed memory locations on the stack, or in registers, but
rarely dynamically in the heap. That's exactly what Python doesn't do.



-- 
Steven

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

Re: Operator precedence problem

[Chris Angelico]

On Tue, Jun 7, 2016 at 2:05 AM, Jon Ribbens
 wrote:
> On 2016-06-06, Chris Angelico  wrote:
>> On Tue, Jun 7, 2016 at 1:27 AM, Jon Ribbens
>> wrote:
> You should put brackets around expressions when it's at all unclear
> what the meaning is. You could think of them a bit like "active
> comments" I suppose.

 Your code should keep noise to the minimum.
>>>
>>> Sensible and beneficial comments aren't "noise".
>>
>> In that case, please never insult the intelligence of your future
>> readers by including any of these parentheses:
>>
>> x = 1 + (2 * 3)
>
> I'm not sure what your point is. Yes, obviously you can take anything
> to ridiculous extremes - that's why I said "sensible".

Earlier in this thread, it was suggested that parens always be used,
even for this kind of example.

>> value = 77 if (x % 2) else (70*7)
>
> I'm not convinced that one isn't actually a good idea. It does seem
> to aid the readability (especially if you space '70 * 7' properly).
> If the expressions were any more complex then it would be even more
> likely to be a good idea.

Hmm, I still think not. But if you want the parens, at least
acknowledge that they're not to enforce/remind of operator precedence.

>> And if your readers have to figure out what 3**3**3 is interpreted as,
>> there should be an interactive interpreter around. Or here - try
>> something cute:
>>
> 2**2**-1
>
> I can't tell now if you're agreeing with me or disagreeing, because
> you started out sounding like you were disagreeing but then provided
> an example that helps prove my point.

My point is that if you're not sure, you grab interactive Python and
give it a quick whirl. Usually easier AND quicker than the
alternatives.

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

Re: Operator precedence problem

[Peter Otten]

Marko Rauhamaa wrote:

> Random832 :
> 
>> Sure, it's obvious to _me_ that << and >> have higher precedence than &
>> and |, and that "and" has a higher precedence than "or", but can I
>> assume the other people know this?
> 
> No need to assume. Just read the spec:
> 
>lambda Lambda expression
>if – else  Conditional expression
>or Boolean OR
>andBoolean AND
>not x  Boolean NOT
>in, not in, is, is not, <, <=, >, >=, !=, ==
>   Comparisons, including membership tests and identity
>   tests
>|  Bitwise OR
>^  Bitwise XOR
>&  Bitwise AND
><<, >> Shifts
>+, -   Addition and subtraction
>*, @, /, //, % Multiplication, matrix multiplication division,
>   remainder [5]
>+x, -x, ~x Positive, negative, bitwise NOT
>** Exponentiation [6]
>await xAwait expression
>x[index], x[index:index], x(arguments...), x.attribute
>   Subscription, slicing, call, attribute reference
>(expressions...), [expressions...], {key: value...}, {expressions...}
>   Binding or tuple display, list display, dictionary
>   display, set display
> 
>https://docs.python.org/3/reference/expressions.html#operat
>or-precedence>
> 
>> [To keep this on-topic, let's assume that this discussion has a goal of
>> getting something along the lines of "always/sometimes/never use
>> "unnecessary" parentheses" into PEP7/PEP8. Speaking of, did you know
>> that C has lower precedence for the bitwise operators &^| than for
>> comparisons? That was something that tripped me up for a very long time
>> and undermined my confidence as to other aspects of the bitwise
>> operators]
> 
> Yes, I happened to know that. Python's the same way.

It's not. From the page you linked to:

"""
Unlike C, all comparison operations in Python have the same priority, which 
is lower than that of any arithmetic, shifting or bitwise operation.
"""

> However, no need to memorize. It's all there in the spec. Same as with
> stdlib functions. Keep checking the spec.

Nah, I usually try it in the interactive interpreter:

$ python3 -c 'print(1 < 3 & 2)'
True

$ echo 'main() { printf("%d\n", 1 < 3 & 2); }' | tcc -run -
0

(tcc invocation courtesy of google/stackoverflow)

> You *can* assume other people have read the spec. Even more importantly,
> you can assume the Python interpreter complies with the spec.


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

Re: Operator precedence problem

[Grant Edwards]

On 2016-06-06, Chris Angelico  wrote:
> On Tue, Jun 7, 2016 at 1:27 AM, Jon Ribbens
> wrote:

 You should put brackets around expressions when it's at all
 unclear what the meaning is. You could think of them a bit like
 "active comments" I suppose.
>>>
>>> Your code should keep noise to the minimum.
>>
>> Sensible and beneficial comments aren't "noise".
>
> In that case, please never insult the intelligence of your future
> readers by including any of these parentheses:
>
> x = 1 + (2 * 3)
> value = 77 if (x % 2) else (70*7)

Just for the record, I don't have any problem at all with any of those
parens.  I don't think they're at all insulting, they don't slow down
comprehension, and they make clear the intent of the writer.  I'm not
sure I would include all of them if _I_ were writing the code, but in
this specific example, I think they're fine.

That said, I have seen lots of cases where fully parenthising an
expression would harm readability...

-- 
Grant Edwards   grant.b.edwardsYow! My nose feels like a
  at   bad Ronald Reagan movie ...
  gmail.com

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

Re: I'm wrong or Will we fix the ducks limp?

[Random832]

On Mon, Jun 6, 2016, at 12:19, Steven D'Aprano wrote:
> (2) The "variables are like boxes" metaphor applies to static languages
> like
> C and Pascal, where the compiler has knowledge of what variables will
> exist. Such languages allocate space for the variables at compile time,
> usually using fixed memory locations on the stack, or in registers, but
> rarely dynamically in the heap.

As you're so fond of pointing out, those are implementation details. And
CPython does it too (using frame objects rather than the stack, but the
relevant point here is that it *does* have knowledge of what variables
will exist), for local variables.

> That's exactly what Python doesn't do.

And anyway, the fact that the "boxes" are dynamically allocated rather
than "fixed memory locations on the stack"* doesn't stop them from being
boxes (if you prefer Marko's analogy, "Some puppies hold leashes in
their mouths"). Attributes and list items and dictionary keys and values
are also boxes.

*isn't the whole point of it being a stack that they're not fixed? I
assume you meant fixed offsets from the stack frame.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Operator precedence problem

[Peter Pearson]

On Mon, 6 Jun 2016 02:24:37 +1000, Chris Angelico  wrote:
> On Sun, Jun 5, 2016 at 4:53 PM, ICT Ezy  wrote:
> 2 ** 3 ** 2
>> Answer is 512
>> Why not 64?
>> Order is right-left or left-right?
>
> This example follows the mathematical standard; you start from the
> "top" (the right hand side), and work your way down.
[snip]

This is almost certainly why top-down was the desirable choice.  And
as for why mathematicians chose top-down (probably long before any
programming-language designer faced the decision), note that this
convention allows you to write both (a**b)**c and a**(b**c) without
parentheses, making expressions cleaner than otherwise:

   bc
  (a**b)**c = a

c
   b
  a**(b**c) = a

-- 
To email me, substitute nowhere->runbox, invalid->com.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Operator precedence problem

[Jon Ribbens]

On 2016-06-06, Chris Angelico  wrote:
> On Tue, Jun 7, 2016 at 2:05 AM, Jon Ribbens
> wrote:
>> On 2016-06-06, Chris Angelico  wrote:
>>> In that case, please never insult the intelligence of your future
>>> readers by including any of these parentheses:
>>>
>>> x = 1 + (2 * 3)
>>
>> I'm not sure what your point is. Yes, obviously you can take anything
>> to ridiculous extremes - that's why I said "sensible".
>
> Earlier in this thread, it was suggested that parens always be used,
> even for this kind of example.

Ok, but it wasn't me that said that, and I don't agree with it.

>>> value = 77 if (x % 2) else (70*7)
>>
>> I'm not convinced that one isn't actually a good idea. It does seem
>> to aid the readability (especially if you space '70 * 7' properly).
>> If the expressions were any more complex then it would be even more
>> likely to be a good idea.
>
> Hmm, I still think not. But if you want the parens, at least
> acknowledge that they're not to enforce/remind of operator precedence.

That depends on your point of view. I suppose the above without
parentheses could theoretically be taken to mean:
 
  value = (77 if (x % 2) else 70) * 7

although I would agree that people would be unlikely to assume that
was the meaning so they are not required under that heading.

>> I can't tell now if you're agreeing with me or disagreeing, because
>> you started out sounding like you were disagreeing but then provided
>> an example that helps prove my point.
>
> My point is that if you're not sure, you grab interactive Python and
> give it a quick whirl. Usually easier AND quicker than the
> alternatives.

It's never easier and quicker than the meaning of the code simply
being obvious by looking at it, which is the point.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Operator precedence problem

[Steven D'Aprano]

On Mon, 6 Jun 2016 11:57 pm, Random832 wrote:

> Okay, can we settle on, as a principle, "the basic arithmetic operators
> (not to include **)  are the only ones whose precedence can be presumed
> to be obvious to all readers, 

Agreed.

> and other expressions may/should have 
> parentheses to make it more clear, even when not strictly necessary to
> the meaning of the expression"?

Sure, why not? So long as it is a "should" and not a "must".


> Sure, it's obvious to _me_ that << and >> have higher precedence than &
> and |, and that "and" has a higher precedence than "or", 

Do they?

https://docs.python.org/2/reference/expressions.html#operator-precedence

Blimey, you're right. I always thought `and` and `or` had the same
precedence. And now that I know better, I have no doubt that I will forget
it again.



-- 
Steven

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

Re: Operator precedence problem

[Rustom Mody]

On Monday, June 6, 2016 at 7:27:18 PM UTC+5:30, Random832 wrote:
> On Mon, Jun 6, 2016, at 01:46, Lawrence D’Oliveiro wrote:
> > On Monday, June 6, 2016 at 4:06:20 AM UTC+12, Uri Even-Chen wrote:
> > > Never write expressions, such as  2 ** 3 ** 2 or even 2 * 4
> > > + 5, without parentheses.
> > 
> > That leads to the code equivalent of
> > .
> 
> Okay, can we settle on, as a principle, "the basic arithmetic operators
> (not to include **)  are the only ones whose precedence can be presumed
> to be obvious to all readers, and other expressions may/should have
> parentheses to make it more clear, even when not strictly necessary to
> the meaning of the expression"?
> 
> Sure, it's obvious to _me_ that << and >> have higher precedence than &
> and |, and that "and" has a higher precedence than "or", but can I
> assume the other people know this? And I don't know offhand the relative
> precedence of non-conceptually-related groups of operators, except that
> I'm pretty sure "and" and "or" have very low precedence.
> 
> [To keep this on-topic, let's assume that this discussion has a goal of
> getting something along the lines of "always/sometimes/never use
> "unnecessary" parentheses" into PEP7/PEP8. Speaking of, did you know
> that C has lower precedence for the bitwise operators &^| than for
> comparisons? That was something that tripped me up for a very long time
> and undermined my confidence as to other aspects of the bitwise
> operators]

Kernghan/Thomson/Ritchie (dont remember which) actually admitted to the
fact that these precedences are wrong

I believe there are necessary (maybe not sufficient) conditions for a
precedence table
▲ : A × A → B
■ : B × B → C
then ■ should be lower than ▲
because otherwise
(x ■ y) ▲ z comes out type-wrong

Of course these rules are usually more informal than rigorous -- both in
programming and in math
eg in C there is really not much of any type but int
Still if we informally treat 
< : A × A → Bool (A is some kind of numeric)
+,* : A × A → A
&&, || : Bool × Bool → Bool

then it follows that
+,*
< <= etc
&& || 
is the natural precedence table

The mistake that C creators made was to treat bitwise operators as
*logical* rather than as *arithmetic*
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Operator precedence problem

[Random832]

On Mon, Jun 6, 2016, at 13:07, Steven D'Aprano wrote:
> Blimey, you're right. I always thought `and` and `or` had the same
> precedence. And now that I know better, I have no doubt that I will
> forget
> it again.

A good way to remember it is that "and" is analogous to multiplication,
and "or" is analogous to addition. Which is, I assume, _why_ they have
the same precedence. (why ^ is between | and &, though, is a mystery to
me.)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Operator precedence problem

[Marko Rauhamaa]

Random832 :
> A good way to remember it is that "and" is analogous to
> multiplication, and "or" is analogous to addition. Which is, I assume,
> _why_ they have the same precedence. (why ^ is between | and &,
> though, is a mystery to me.)

APL had a good way of remembering operator precedence: every operator
was equal and the evaluation order was from right to left.


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

Re: I'm wrong or Will we fix the ducks limp?

[Steven D'Aprano]

On Tue, 7 Jun 2016 02:57 am, Random832 wrote:

> On Mon, Jun 6, 2016, at 12:19, Steven D'Aprano wrote:
>> (2) The "variables are like boxes" metaphor applies to static languages
>> like
>> C and Pascal, where the compiler has knowledge of what variables will
>> exist. Such languages allocate space for the variables at compile time,
>> usually using fixed memory locations on the stack, or in registers, but
>> rarely dynamically in the heap.
> 
> As you're so fond of pointing out, those are implementation details. 

I believe that both C and Pascal specify that they are statically declared
languages with a variable model broadly as I have described it above,
the "box" model.

There may be implementation-dependent details I've glossed over (I don't
know the entire Pascal and C specifications by heart), but I think I'm on
fairly solid ground to say that a language that is just like C except that
it allocates variables in a hash table at runtime, using runtime lookups
for variable access, would not satisfy the C89 or C99 standards.

In any case, the point is that there are behavioural differences between a
static "box" model and a dynamic "name binding" mode for variables. Python
uses the later, not the former. You couldn't implement Python with a
strictly static box model, since you have to support `exec`.


> And 
> CPython does it too (using frame objects rather than the stack, but the
> relevant point here is that it *does* have knowledge of what variables
> will exist), for local variables.

A very good point, however that *is* an implementation detail: Jython and
IronPython don't have that limitation, as CPython does, and so their
locals() is a proper namespace. But even in CPython 2, you can create local
variables dynamically:


py> def test():
... exec("x = 1")
... print(x)
...
py> test()
1


Though that doesn't work in Python 3.


>> That's exactly what Python doesn't do.
> 
> And anyway, the fact that the "boxes" are dynamically allocated rather
> than "fixed memory locations on the stack"* doesn't stop them from being
> boxes 

"Variables as boxes" is a long-standing, well-known metaphor for the C and
Pascal variable model, one where the value is copied into the box
(metaphorically), or to be more precise, where variables have fixed
locations and on assignment values are copied to that location. Python is
not like that, and using the same metaphor for two completely different
models is a sure way to get obfuscation and confusion rather than
understanding.

Weren't you the one who just a few days ago complained about Python folks
unilaterally redefining established terms in contradiction of how those
terms are used by the rest of the programming community?

The broader programming community understands "variables as boxes" to mean
fixed size boxes in fixed locations with assignment-as-copying, as used by
C and Pascal. I don't think it is helpful for you to invent your own
metaphor of Python-style variables being boxes.


> (if you prefer Marko's analogy, "Some puppies hold leashes in 
> their mouths").

I don't know what Marko's analogy is. Puppies with leashes? What?


> Attributes and list items and dictionary keys and values 
> are also boxes.

They're not boxes in the sense of the "variables are boxes" model. I don't
know what other sense you intend the metaphor to be understood.


> *isn't the whole point of it being a stack that they're not fixed? I
> assume you meant fixed offsets from the stack frame.

Yes, thank you for the correction. (That's not sarcasm.)




-- 
Steven

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

Re: Recommendation for GUI lib?

[Dietmar Schwertberger]

On 05.06.2016 01:08, John Pote wrote:
Qt and Qt Creator often come up in searches for Python GUI libraries. 
I need to decide weather to upgrade to wxPython.Phoenix and Python 3.5 
(as soon as I upgrade to win 7!) or switch to Qt which I don't know at 
all. It would be interesting to hear your experiences of trying Qt and 
why you've stuck with wxPython in the end.

Python 2.7 and wx are working well under Win 7.
But there are other problems like e.g. some bugs that I faced with the 
Win 32 extensions. For many libraries you can no longer expect first 
class support with 2.7.


I have been using wxPython on the desktop since around 2000.
Porting my main desktop application with several MB GUI related code to 
another toolkit is certainly not an option.
The lack of a Python 3 compatible wxPython did hold me back from moving 
to Python 3 for some years, but when I tried last year, I was positively 
surprised as it took only one evening to port my application. OK, then 
it took me some evenings to implement e.g. Metafile support for Phoenix. 
Nowadays almost all features from the classic wxPython should be 
available in Phoenix as well.
Even though Phoenix is not yet released, I did not face any 
instabilities (except maybe that the virtual grid is a bit more picky 
than it used to be when it comes to dynamic grid cell attributes).


I'm using Qt sometimes for small apps on my mobiles (Sailfish OS and, 
before that, Maemo).
I don't see a reason to change from wx to Qt on the desktop. I'm not 
convinced about whether Qt Widgets have too much of a future at all. The 
'traditional' development has moved out of the focus of the Qt team a 
long time ago (when Trolltech was aquired by Nokia). The suggestion is 
to use QML now, but there's no pythonic way to develop QML / Qt Quick 
based GUIs as there's no C++ API which could be used as base for this.


OK, Qt has one advantage: using Quamash you can integrate the asyncio 
and the qt main loops. Without Python 3 support there has not yet been a 
need to have this for wx...


Qt Designer is certainly a good GUI builder, but not more than that. 
When you actually want to use the designed GUI in Python, you will find 
that this needs almost as much know how and work as if you did the GUI 
in code.


Regards,

Dietmar

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

Re: Operator precedence problem

[MRAB]

On 2016-06-06 19:44, Random832 wrote:

On Mon, Jun 6, 2016, at 13:07, Steven D'Aprano wrote:

Blimey, you're right. I always thought `and` and `or` had the same
precedence. And now that I know better, I have no doubt that I will
forget
it again.


A good way to remember it is that "and" is analogous to multiplication,
and "or" is analogous to addition. Which is, I assume, _why_ they have
the same precedence. (why ^ is between | and &, though, is a mystery to
me.)

In Pascal, "and" has the same precedence as "*" and "or" has the same 
precedence as "+".


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

Re: Operator precedence problem

[Ben Bacarisse]

Rustom Mody  writes:

> Kernghan/Thomson/Ritchie (dont remember which) actually admitted to the
> fact that these precedences are wrong

> The mistake that C creators made was to treat bitwise operators as
> *logical* rather than as *arithmetic*

It was more that they did not take the opportunity to change them.  C
grew out of B, and B had only the one form of & and |.  These were
bitwise operators but, since they they were more often used for logical
combinations of tests, it made sense to give them low precedence.

When && and || were added to C, & and | should probably have been
"bumped up", but when you have a bunch of people who already know B (and
a bunch of B code you might be converting to C) it's easy to see why you
might not make that change.  After all, it's not like the language is
going to used for much more than this experimental Unix thingy!

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

Re: I'm wrong or Will we fix the ducks limp?

[Random832]

On Mon, Jun 6, 2016, at 14:59, Steven D'Aprano wrote:
> "Variables as boxes" is a long-standing, well-known metaphor for the C
> and
> Pascal variable model, one where the value is copied into the box
> (metaphorically), or to be more precise, where variables have fixed
> locations and on assignment values are copied to that location.

I don't think that's "to be more precise" at all. I think that is an
entirely different model.

The box metaphor as I understand it involves a lot of boxes, which may
contain arrows (call them pointers, references, or whatever) emerging
from them pointing to other boxes, which are all free-floating with no
implication that any of them are fixed locations or are not dynamically
allocated.

The most classic use of it, after all, is for Lisp, in which two boxes
glued together represent a cons cell, something absolutely nobody would
accuse of having a fixed location. Google "lisp box diagram"  for any
number of examples.

What does a diagram of *your* "variables as boxes" model look like?

> The broader programming community

Between this and the argument about "constructor" terminology, clearly
you and I see "the broader programming community" very differently.

> understands "variables as boxes" to mean fixed size boxes in fixed
> locations with assignment-as-copying, as used by C and Pascal. I don't
> think it is helpful for you to invent your own metaphor of Python-
> style variables being boxes.

> > (if you prefer Marko's analogy, "Some puppies hold leashes in 
> > their mouths").
> 
> I don't know what Marko's analogy is. Puppies with leashes? What?

It was a couple days ago in this thread, in a reply to a post by you.

On Sun, Jun 5, 2016, at 04:01, Marko Rauhamaa wrote:
M> You could also think of variables as pegs, references as leashes, and
M> objects as cute puppies. One puppy could be held with multiple
leashes
M> hung on separate pegs. Some puppies hold leashes in their mouths.
Every
M> leash is tied to a puppy or a special wooden post called None.

(I disagreed with him on "None" needing to be a special wooden post for
the analogy to work)

R> > Attributes and list items and dictionary keys and values 
R> > are also boxes.
S> 
S> They're not boxes in the sense of the "variables are boxes" model.

I would say 'yes they are', but clearly *your* "broader programming
community's" version of the ""variables are boxes" model" is different
from everyone else's. I don't think continuing this discussion is likely
to be productive.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: I'm wrong or Will we fix the ducks limp?

[Marko Rauhamaa]

Random832 :

> The box metaphor as I understand it involves a lot of boxes, which may
> contain arrows (call them pointers, references, or whatever) emerging
> from them pointing to other boxes, which are all free-floating with no
> implication that any of them are fixed locations or are not
> dynamically allocated.

When I first studied Java, I quickly made a realization that

   Java's.  (dot)

is

   C's   -> (arrow)

That's all there was to it. You could replace Java with Python.

Where a C programmer would write:

   x->y->z

a Python programmer would express the same as:

   x.y.z

> The most classic use of it, after all, is for Lisp, in which two boxes
> glued together represent a cons cell, something absolutely nobody
> would accuse of having a fixed location. Google "lisp box diagram" for
> any number of examples.

There doesn't seem to be any way to introduce Lisp/Java/Python's data
model except through lower-level programming concepts.

> On Sun, Jun 5, 2016, at 04:01, Marko Rauhamaa wrote:
> M> You could also think of variables as pegs, references as leashes,
> M> and objects as cute puppies. One puppy could be held with multiple
> M> leashes hung on separate pegs. Some puppies hold leashes in their
> M> mouths. Every leash is tied to a puppy or a special wooden post
> M> called None.
>
> (I disagreed with him on "None" needing to be a special wooden post for
> the analogy to work)

That's not an analogy -- that's an abstract data model!

Note: no boxes! However, there are strings attached. Now you can truly
*bind* objects to variables.

Seriously, though, it is notable that the high-level programming
languages pretty unanimously refuse to make variables first-class
objects. I wonder why.

Python (et al) can closely emulate pointers to variables with arrays:

   >>> def double_it(it):
   ... it[0] *= 2
   ... 
   >>> it = [7]
   >>> double_it(it)
   >>> it[0]
   14
   >>> double_it(it)
   >>> it[0]
   28

although that would be bad style in Python, which can return tuples.


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

Re: I'm wrong or Will we fix the ducks limp?

[BartC]

On 06/06/2016 17:19, Steven D'Aprano wrote:


(2) The "variables are like boxes" metaphor applies to static languages like
C and Pascal, where the compiler has knowledge of what variables will
exist. Such languages allocate space for the variables at compile time,
usually using fixed memory locations on the stack, or in registers, but
rarely dynamically in the heap. That's exactly what Python doesn't do.


With sane programs of the kind I would write, variables appear in the 
source code:


 a = b

Thus they are known to the compiler and can be given special treatment 
compared to any that there might be in an exec() string.


That the language allows the internal entries required for such names to 
be 'deleted', or not to create them at all in code such as:


   if cond:
  b = 10

(when cond is false) is another matter. A disassembly will clearly show 
the name "b". And it would be ludicrous to suggest that here:


 pass# 1
 a = 0   # 2
 pass# 3

"a" doesn't exist at all at line 1 or at the start of line 2, and only 
comes fully into existence by line 3. "a" exists by name in the 
byte-code as well as the source code from the start.


a is a variable.

--
Bartc

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

Re: [Q] ImportError by __import__() on Python >= 3.4

[Michael Selik]

On Thu, Jun 2, 2016 at 10:06 AM Makoto Kuwata  wrote:

> I have a trouble around __import__().
>

The docs for __import__ strongly recommend that you use importlib instead
https://docs.python.org/3.5/library/importlib.html#importlib.import_module

The docs for ``importlib.import_module`` suggest that you use
``invalidate_caches`` if you are importing dynamically generated files.
https://docs.python.org/3.5/library/importlib.html#importlib.invalidate_caches

I think you'll find this fixes your bug.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Operator precedence problem

[Gregory Ewing]

Peter Pearson wrote:


c
   b
  a**(b**c) = a


Also, in mathematical texts it's usually written with
the c smaller than the b, and the b smaller than the
a, which helps to make the precedence clear. We
can't do that in Python, unforunately. Unless we allow
writing the source in html...

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

Re: Operator precedence problem

[Gregory Ewing]

MRAB wrote:

In Pascal, "and" has the same precedence as "*" and "or" has the same 
precedence as "+".


Which was annoying, because it gave them higher precedence
than the comparison operators, so instead of

   a = b and c > d

you had to write

   (a = b) and (c > d)

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

Re: for / while else doesn't make sense

[Lawrence D’Oliveiro]

On Sunday, June 5, 2016 at 11:43:20 PM UTC+12, Marko Rauhamaa wrote:
> I often experiment with different loop constructs to find the one most
> pleasing to the eye. Working directly off iterators is quite rare but a
> while-vs-for consideration is frequent. Also, should the stepping part
> be in the beginning, middle or end of the loop body?

It is nice to have a common, versatile looping form which can be arranged in 
different ways to suit the problem at hand. That’s why I like the C-style 
for-statement.

Here’s another example 
, for the 
consideration of those who don’t seem too familiar with looping:

while True :
while True :
line = next(input_line, None)
if line != None :
if len(include_stack) == 0 :
linenr += 1
#end if
break
#end if
if len(include_stack) == 0 :
break
input_line = include_stack.pop()
#end while
if line == None or ... line contains something special ... :
...
if line == None :
break
... process special line ...
... replace with None to indicate it’s been processed ...
#end if
if line != None :
... process regular line ...
#end if
#end while
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: for / while else doesn't make sense

[Lawrence D’Oliveiro]

On Sunday, June 5, 2016 at 11:43:20 PM UTC+12, Marko Rauhamaa wrote:

> Then, you might overdo constructs like lambdas and maps.

Who says you can have too many lambdas?


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

Re: Everything good about Python except GUI IDE?

[Lawrence D’Oliveiro]

On Sunday, February 28, 2016 at 12:19:21 AM UTC+13, wrong.a...@gmail.com wrote:
> I have some VB forms with more than a hundred objects. If I cannot drag and
> drop text boxes, list boxes, labels, etc., it will be too much work to create
> that with several lines of code for each object. 

You mean you had to drag and drop every single one of those objects? You 
couldn’t script their creation automatically? And you are asking for a Python 
equivalent that will make you work just as hard?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: for / while else doesn't make sense

[Dan Sommers]

On Mon, 06 Jun 2016 17:51:24 -0700, Lawrence D’Oliveiro wrote:

> It is nice to have a common, versatile looping form which can be
> arranged in different ways to suit the problem at hand. That’s why I
> like the C-style for-statement.

[example snipped]

I used to write a lot of assembly code, for a lot of different CPUs, and
they all had a common, versatile looping form which could be arranged in
different ways to suit the problem at hand.  On most chips, it was (and
still is) called JMP.  The trouble began with multiple conditional
branching, call stack maintenance, and those other higher level
abstractions that made my assembly code so hard to follow.  Why on Earth
would I use something so complicated as a DJNZ instruction when a
common, versatile sequence of decrement, test, and branch-on-not-zero
instructions was available?  And who needed a C-level for statment, let
alone local variables and a language-runtime-maintained function call
stack when I had a handful of common, versatile CPU registers?

http://www.catb.org/jargon/html/story-of-mel.html
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: for / while else doesn't make sense

[Ian Kelly]

On Mon, Jun 6, 2016 at 6:51 PM, Lawrence D’Oliveiro
 wrote:
> On Sunday, June 5, 2016 at 11:43:20 PM UTC+12, Marko Rauhamaa wrote:
>> I often experiment with different loop constructs to find the one most
>> pleasing to the eye. Working directly off iterators is quite rare but a
>> while-vs-for consideration is frequent. Also, should the stepping part
>> be in the beginning, middle or end of the loop body?
>
> It is nice to have a common, versatile looping form which can be arranged in 
> different ways to suit the problem at hand. That’s why I like the C-style 
> for-statement.
>
> Here’s another example 
> , for the 
> consideration of those who don’t seem too familiar with looping:

A 500-line function? Yikes, what an eyesore. When you have to include
#end comments in order to visually match things up, that should be a
smell that your code is excessively complex. It took me a lot of
scrolling up and down just to figure out what the scopes of the
variables were.

> while True :
> while True :
> line = next(input_line, None)
> if line != None :
> if len(include_stack) == 0 :
> linenr += 1
> #end if
> break
> #end if
> if len(include_stack) == 0 :
> break
> input_line = include_stack.pop()
> #end while
> if line == None or ... line contains something special ... :
> ...
> if line == None :
> break
> ... process special line ...
> ... replace with None to indicate it’s been processed ...
> #end if
> if line != None :
> ... process regular line ...
> #end if
> #end while

def generate_lines():
nonlocal input_line
while True:
try:
# Note input_line appears to be an iterator, not a string
# as suggested by the name.
yield next(input_line)
except StopIteration:
if include_stack:
input_line = include_stack.pop()
else:
return

for line in generate_lines():
if not include_stack:
linenr += 1
if ... line contains something special ...:
... process special line ...
else:
... process regular line ...

Much simpler than the nested while loop hell above, and not a single
break needed (if you don't count the return, that is; in any case each
loop has a single exit point). I'd be tempted to refactor input_line
and include_stack into some sort of input context class and make
generate_lines a method of the class in order to avoid having those
variables be (effectively) global, but my goal was to keep this as
close to the original in design as possible.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: I'm wrong or Will we fix the ducks limp?

[Gregory Ewing]

Steven D'Aprano wrote:

Even if you were right that objects must exist at
a single well-defined location, that is strictly irrelevant. That's
implementation, not interface.


We're talking about mental models. Sure, you could come up
with some kind of Tardis-like mental model where objects
exist in more than one location at once. But why would
you bother going to such mental contortions? There is a much
more straightforward model that's vastly easier to reason
about, because it aligns with our intuitions, which are
based on the way things behave in the actual universe we
live in.

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

Re: I'm wrong or Will we fix the ducks limp?

[Gregory Ewing]

Steven D'Aprano wrote:


I never said that the string "x" is the same thing as the variable x.


Maybe you didn't, but some people insist we shouldn't use
the term "variable" when talking about python, but use
"name" instead. I was pointing out that those two words
don't have the same connotations.

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

Re: I'm wrong or Will we fix the ducks limp?

[Gregory Ewing]

Steven D'Aprano wrote:

I think I'm on
fairly solid ground to say that a language that is just like C except that
it allocates variables in a hash table at runtime, using runtime lookups
for variable access, would not satisfy the C89 or C99 standards.


I wouldn't be so sure about that. Modern C standards are
pretty careful to avoid making any promises about how
things are laid out in memory, etc.

It wouldn't surprise me much if you could come up with
such an implementation that adheres to the strict letter
of the standard. It also wouldn't surprise me if that
implementation failed to run a large proportion of
real C code out there, though...

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

Re: I'm wrong or Will we fix the ducks limp?

[Chris Angelico]

On Tue, Jun 7, 2016 at 4:33 PM, Gregory Ewing
 wrote:
> Steven D'Aprano wrote:
>>
>> I think I'm on
>> fairly solid ground to say that a language that is just like C except that
>> it allocates variables in a hash table at runtime, using runtime lookups
>> for variable access, would not satisfy the C89 or C99 standards.
>
>
> I wouldn't be so sure about that. Modern C standards are
> pretty careful to avoid making any promises about how
> things are laid out in memory, etc.
>
> It wouldn't surprise me much if you could come up with
> such an implementation that adheres to the strict letter
> of the standard. It also wouldn't surprise me if that
> implementation failed to run a large proportion of
> real C code out there, though...

Without having read any of the specs, my guess is you could be C89/C99
compliant putting all your "simple variables" into the hash table -
int, char, float, double, etc - but keep all your arrays and structs
in "real memory". There's no reason a CPU couldn't be built with fifty
million registers available, and the compiler could just put all those
scalars into registers (assuming you never take their addresses, in
which case they then need to have them).

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