Re: ongoing browser projects

[Thomas Jollans]

On 23/07/18 03:43, Akkana Peck wrote:
> There used to be a Python-WebKit-GTK2 library that was fairly easy
> to use and even had documentation, but it's been orphaned for years,
> and in any case a lot of the modern web no longer works with the old
> WebKit engine. You'd think there would be something newer (ideally
> based on Blink) that worked with GTK3/GIO, but I never found anything.

This gi-based example looks like Gtk3, right?

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

Re: ongoing browser projects

[Thomas Jollans]

On 23/07/18 09:00, Thomas Jollans wrote:
> On 23/07/18 03:43, Akkana Peck wrote:
>> There used to be a Python-WebKit-GTK2 library that was fairly easy
>> to use and even had documentation, but it's been orphaned for years,
>> and in any case a lot of the modern web no longer works with the old
>> WebKit engine. You'd think there would be something newer (ideally
>> based on Blink) that worked with GTK3/GIO, but I never found anything.
> 
> This gi-based example looks like Gtk3, right?
> 

https://gist.github.com/kklimonda/890640#file-pybrowser-py-L14

sorry forgot to hit ctrl+v
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: import in code

[Cameron Simpson]

On 22Jul2018 15:38, Mark Lawrence  wrote:

On 22/07/18 05:45, Cameron Simpson wrote:

Circular imports: 2 codependent modules. If you have:

 module A:
   import B
 module B:
   import B

That won't work: the second import (whichever it turns out to be) 
will fail. One workaround is to make one of the modules put off the 
import. A better approach is usually to redesign things so that they 
don't do a mutual import (move classses etc around, or merge them). 
This is always feasible, but often is.


I don't ever recall seeing a module try to import itself, but then 
perhaps you meant module B should be importing module A? :)


Yes, sorry. Poor proof reading. - Cameron
--
https://mail.python.org/mailman/listinfo/python-list

Re: For next loops

[Brian Oney via Python-list]

What if ply != com in the first (0th) iteration? 

It's better to have an 'else:'-statement in your case, I suppose.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: coding style - where to declare variables

[Gregory Ewing]

Steven D'Aprano wrote:

So let me see if I understand your argument...

- we should stop using the term "binding", because it means 
  nothing different from assignment;

- binding (a.k.a. "assignment") comes from lambda calculus;
- which has no assignment (a.k.a. "binding").


No, that's not what Marko is saying at all. He's pointing
out that the term "binding" means something completely
different in lambda calculus.

The terms "bound variable" and "free variable" in lambda
calculus mean what in Python we would call a "local
variable" vs. a "non-local variable". They have nothing
to do with assignment at all.

Marko is asking us to stop using the word "binding" to
refer to assignment because of the potential confusion
with this other meaning.

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

Re: coding style - where to declare variables

[Ben Finney]

Gregory Ewing  writes:

> Marko is asking us to stop using the word "binding" to refer to
> assignment because of the potential confusion with this other meaning.

That's about as reasonable as my request that we stop using the term
“variable” for what is, in Python, an un-typed reference to an object.

I expect both of these requests to meet with little satisfaction.

-- 
 \ “We are all agreed that your theory is crazy. The question that |
  `\  divides us is whether it is crazy enough to have a chance of |
_o__)being correct.” —Niels Bohr (to Wolfgang Pauli), 1958 |
Ben Finney

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

Re: coding style - where to declare variables

[Marko Rauhamaa]

Ben Finney :
> Gregory Ewing  writes:
>
>> Marko is asking us to stop using the word "binding" to refer to
>> assignment because of the potential confusion with this other meaning.
>
> That's about as reasonable as my request that we stop using the term
> “variable” for what is, in Python, an un-typed reference to an object.
>
> I expect both of these requests to meet with little satisfaction.

I'm actually not asking, only wishing.

People new to Python are unnecessarily confused by talking about names
and binding when it's really just ordinary variables and assignment. It
seems to be mostly some sort of marketing lingo that seeks to create an
air of mystique around Python.


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

Re: coding style - where to declare variables

[Frank Millman]

"Marko Rauhamaa"  wrote in message news:87zhyitjz2@elektro.pacujo.net...


People new to Python are unnecessarily confused by talking about names
and binding when it's really just ordinary variables and assignment. It
seems to be mostly some sort of marketing lingo that seeks to create an
air of mystique around Python.



I don't think that is a fair comment.

I am not qualified to enter the debate itself, but as an 'outsider' I can 
offer two thoughts -


1. It seems that, whatever terminology we come up with, some other language 
will use similar terminology, but with a subtly different meaning. Newcomers 
to Python coming from that other language often get confused because they 
make certain assumptions, based on their other experience, which turn out to 
be unfounded in Python.


2. My 'aha' moment came early on when I read somewhere that Python objects 
have 3 attributes - a type, a value, and a unique id. One thing that they do 
*not* have is a name. Once I understood that, a lot of things became 
clearer.


Frank Millman


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

Re: coding style - where to declare variables

[Steven D'Aprano]

On Mon, 23 Jul 2018 20:24:30 +1200, Gregory Ewing wrote:

> Steven D'Aprano wrote:
>> So let me see if I understand your argument...
>> 
>> - we should stop using the term "binding", because it means
>>   nothing different from assignment;
>> - binding (a.k.a. "assignment") comes from lambda calculus;
>> - which has no assignment (a.k.a. "binding").
> 
> No, that's not what Marko is saying at all. He's pointing out that the
> term "binding" means something completely different in lambda calculus.

Well done in reading Marko's intent. Unfortunately, I'm not as good as 
inferring meaning as you seem to be, consequently I had to judge by what 
he wrote, not what he meant.

When a writer fails to communicate their intent, that's usually the 
failure of the writer, not the reader. We aren't mind-readers and writers 
should not blame the reader when they fail to communicate their intended 
meaning.


> The terms "bound variable" and "free variable" in lambda calculus mean
> what in Python we would call a "local variable" vs. a "non-local
> variable".

Actually, no, they are called "bound variable" and "free variable" in 
Python too.

https://docs.python.org/3/reference/executionmodel.html

See also: http://effbot.org/zone/closure.htm

Alas, I don't think Fredrik Lundh got it *quite* right. I think that 
globals (and builtins) in Python are "open free variables", as opposed to 
nonlocals which are closed. And sadly, the Python glossary currently 
doesn't define free variables nor bound variables, or even name binding.


> They have nothing to do with assignment at all.

That's not quite correct either.

Lambda calculus has the concept of a binding operator, which is 
effectively an assignment operator: it takes a variable and a value and 
binds the value to the variable, changing a free variable to a bound 
variable. In other words, it assigns the value to the variable, just like 
assignment does.

In Python terms, = is a binary binding operator: it takes a left hand 
operand, the variable (a name, for the sake of simplicity) and a right 
hand operand (a value) and binds the value to the name.

 
> Marko is asking us to stop using the word "binding" to refer to
> assignment because of the potential confusion with this other meaning.

Marko has some idiosyncratic beliefs about Python (and apparently other 
languages as well) that are difficult to justify.

Especially in this case. Anyone who understands lambda calculus is 
unlikely to be confused by Python using the same terms to mean something 
*almost identical* to what they mean in lambda calculus. (The only 
difference I can see is that lambda calculus treats variables as abstract 
mathematical entities, while Python and other programming languages 
vivify them and give them a concrete implementation.)

If one in ten thousand programmers are even aware of the existence of 
lambda calculus, I would be surprised. To give up using perfectly good, 
accurate terminology in favour of worse, less accurate terminology in 
order to avoid unlikely and transient confusion among a minuscule subset 
of programmers seems a poor tradeoff to me.



-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

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

Re: coding style - where to declare variables

[Ben Bacarisse]

Mark Lawrence  writes:

> On 22/07/18 14:51, Abdur-Rahmaan Janhangeer wrote:
>> except local vars
>>
>> Abdur-Rahmaan Janhangeer
>> https://github.com/Abdur-rahmaanJ
>> Mauritius
>>
>
> Python doesn't have variables, it has names.

I think we should cut beginners (and probably everyone) some slack about
this.  I don't know if work is underway to purge the term from the
Python documentation, but until that is done people can be forgiven for
thinking that the term is acceptable.

For example, https://docs.python.org/3/tutorial/classes.html says

  "The global statement can be used to indicate that particular
  variables live in the global scope and should be rebound there; the
  nonlocal statement indicates that particular variables live in an
  enclosing scope and should be rebound there."

and https://www.python.org/dev/peps/pep-0526/ is titled "Syntax for
Variable Annotations".  It describes:

  "This PEP aims at adding syntax to Python for annotating the types of
  variables (including class variables and instance variables), instead
  of expressing them through comments"

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

Re: coding style - where to declare variables

[Steven D'Aprano]

On Mon, 23 Jul 2018 11:49:37 +0300, Marko Rauhamaa wrote:

> People new to Python are unnecessarily confused by talking about names
> and binding when it's really just ordinary variables and assignment.

It really isn't, not to those people who expect ordinary variables and 
assignment to be the same as that of C, C++, C#, Objective C, Swift, 
Pascal, Java, Go etc.

There are at least two common models for the association between symbolic 
names and values in programming: 

1. variables are named boxes at a statically-allocated, fixed 
   location in memory, usually on the stack ("value types");

2. variables are names that refer to dynamically-allocated
   objects in the heap, often movable ("reference types").

It is absolutely true that both are "variables" of a kind, and that "name 
binding" is abstract enough to refer to both models. But in *practice*, 
the influence of Algol, C and BASIC especially is so great that many 
people think of variables and assignment exclusively in the first sense. 
Since Python uses the second sense, having a distinct name to contrast 
the two is desirable, and "name binding" seems to fit that need.

I no longer believe that we should actively avoid the word "variable" 
when referring to Python. I think that's an extreme position which isn't 
justified. But "name binding" is an accurate technical term and not that 
hard to understand (on a scale of 0 to "monad", it's about 1) and I think 
it is elitist to claim that "people new to Python"[1] will necessarily be 
confused and we therefore ought to avoid the term.

There are lots of confusing terms and concepts in Python. People learn 
them. Name binding is no different.






[1] What, all of them? Even those with a comp sci PhD and 40 years 
programming experience in two dozen different languages?


-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

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

Re: coding style - where to declare variables

[Marko Rauhamaa]

Steven D'Aprano :

> Lambda calculus has the concept of a binding operator, which is
> effectively an assignment operator: it takes a variable and a value
> and binds the value to the variable, changing a free variable to a
> bound variable. In other words, it assigns the value to the variable,
> just like assignment does.

In traditional Lambda Calculus semantics, there are no values at all.
There are only well-formatted formulas and syntactic transformation
rules. You could view it as a macro preprocessing system where you keep
transforming the formula until no transformation rule applies.

Yes, λ can be viewed as a binding operator although classically, it is
simply a dead symbol just like '(', '.' and 'z'.

> Especially in this case. Anyone who understands lambda calculus is
> unlikely to be confused by Python using the same terms to mean
> something *almost identical* to what they mean in lambda calculus.
> (The only difference I can see is that lambda calculus treats
> variables as abstract mathematical entities, while Python and other
> programming languages vivify them and give them a concrete
> implementation.)
>
> If one in ten thousand programmers are even aware of the existence of
> lambda calculus, I would be surprised. To give up using perfectly
> good, accurate terminology in favour of worse, less accurate
> terminology in order to avoid unlikely and transient confusion among a
> minuscule subset of programmers seems a poor tradeoff to me.

The lambda calculus comment is just an aside. The main point is that
you shouldn't lead people to believe that Python has variables that are
any different than, say, Pascal's variables (even if you, for whatever
reason, want to call them "names"). They are memory slots that hold
values until you assign new values to them.

It *is* true that Python has a more limited data model than Pascal (all
of Python's values are objects in the heap and only accessible through
pointers). Also, unlike Pascal, variables can hold (pointers to) values
of any type. IOW, Python has the data model of Lisp.

Lisp talks about binding and rebinding variables as well:

   https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node79.html>

which might be Lambda Calculus legacy, but at least they are not shy to
talk about variables and assignment.


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

Re: coding style - where to declare variables

[Steven D'Aprano]

On Mon, 23 Jul 2018 09:22:55 +0300, Marko Rauhamaa wrote:

> Dennis Lee Bieber :
[...]
>>  In my world, Java and Python are the ones that are not "common".
> 
> Yes, "boxed" is a Java term. However, the programming pattern of using
> dynamic memory and pointers is ubiquitous and ancient:

Not that ancient -- the first version(s) of Fortran didn't have dynamic 
memory allocation or pointers. (Admittedly, Lisp did follow not long 
afterwards.) But it is certainly not ubiquitous: many languages don't 
have pointers at all.


> FILE *f = fopen("xyz", "r");
> 
> where f holds a pointer, fopen() returns a pointer, and "xyz" and "r"
> evaluate to pointer values.
> 
> In Python, every expression evaluates to a pointer and every variable
> holds a pointer.

Within the semantics of the Python language, there are no pointer values, 
no way to get a pointer to a memory location or a pointer to an object. 
No expression in Python evaluates to a pointer, no variables hold 
pointers in Python. The Python language is defined in terms of objects: 
expressions evaluate to objects, and variables are names bound to objects.

If you don't believe me, believe the interpreter:

# Marko expects a pointer, but unfortunately he gets an int
py> type(1 + 2) 


Marko is making a similar category error as those who insist that Python 
uses "call by reference" or "call by value" for parameter passing. He 
mistakes an irrelevant implementation detail used by *some* but not all 
Python interpreters[1] for entities which exist in the Python computation 
model. As Fredrick puts it:

"Joe, I think our son might be lost in the woods"
"Don't worry, I have his social security number"

http://effbot.org/zone/call-by-object.htm

(The *pointer to an object* used in the implementation is not the same as 
the object itself.)

Evaluating 1 + 2 gives the value (an object) 3, not a pointer to the 
value 3. Pointers are not merely "not first-class citizens" of Python, 
they aren't citizens at all: there is nothing we can do in pure Python to 
get hold of pointers, manipulate pointers, or dereference pointers.

https://en.wikipedia.org/wiki/First-class_citizen

Pointers are merely one convenient, useful mechanism to implement 
Python's model of computation in an efficient manner on a digital 
computer. They are not part of the computation model, and pointers are 
not values available to the Python programmer[2].







[1] The CPython interpreter uses pointers; the Jython interpreter uses 
whatever kind of memory indirection the JVM provides; when I emulate a 
Python interpreter using pencil and paper, there's not a pointer in sight 
but a lot of copying of values and crossing them out. ("Copy on access" 
perhaps?) A Python interpreter emulated by a Turing machine would use 
dots on a long paper tape, and an analog computer emulating Python would 
use I-have-no-idea. Clockwork? Hydraulics?

https://en.wikipedia.org/wiki/MONIAC
https://makezine.com/2012/01/24/early-russian-hydraulic-computer/


[2] Except by dropping into ctypes or some other interface to the 
implementation, and even then the pointers have to be converted to and 
from int objects as they cross the boundary between the Python realm and 
the implementation realm.




-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

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

Re: coding style - where to declare variables

[Chris Angelico]

On Mon, Jul 23, 2018 at 9:39 PM, Steven D'Aprano
 wrote:
> [1] The CPython interpreter uses pointers; the Jython interpreter uses
> whatever kind of memory indirection the JVM provides; when I emulate a
> Python interpreter using pencil and paper, there's not a pointer in sight
> but a lot of copying of values and crossing them out. ("Copy on access"
> perhaps?) A Python interpreter emulated by a Turing machine would use
> dots on a long paper tape, and an analog computer emulating Python would
> use I-have-no-idea. Clockwork? Hydraulics?

I've been known to implement a linked list using a deck of cards, with
tetrapod "one teaspoon of sugar" packets for the Next markers, and
pens for externally-accessible references (the head of the list, the
current node, etc). This therefore proves that a pointer IS a teaspoon
of sugar, and vice versa.

Would you like your tea with one pointer or two?

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

Re: For next loops

[Neil Cerutti]

On 2018-07-23, no@none.invalid  wrote:
> never mind.
> x = range (5)
> y = range (5)
> for ply in x:
>
> for com in y:
> if ply==com:
> result="Tie"
>
> print(ply,com,result)
> result = ""

Something like this is possible. "x", "y" and "result" can be
unecessary.

for ply in range(5):
for com in range(5):
print(ply, com, end='')
if ply == com:
print(" Tie")
else:
print()

-- 
Neil Cerutti

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

Re: coding style - where to declare variables

[Steven D'Aprano]

On Mon, 23 Jul 2018 14:39:56 +0300, Marko Rauhamaa wrote:

> Steven D'Aprano :
> 
>> Lambda calculus has the concept of a binding operator, which is
>> effectively an assignment operator: it takes a variable and a value and
>> binds the value to the variable, changing a free variable to a bound
>> variable. In other words, it assigns the value to the variable, just
>> like assignment does.
> 
> In traditional Lambda Calculus semantics, there are no values at all.

It is more common to say "pure lambda calculus" rather than 
"traditional", and it is not correct to say there are no values at all. 
Rather, all values are functions (and all functions are values).

http://scienceblogs.com/goodmath/2006/08/29/a-lambda-calculus-rerun-1/

and:

"As this suggests, functions are just ordinary values, and can
be the results of functions or passed as arguments to functions
(even to themselves!).  Thus, in the lambda calculus, functions are
first-class values.  Lambda terms serve both as functions and data."

http://www.cs.cornell.edu/courses/cs6110/2013sp/lectures/lec02-sp13.pdf

And from the same notes:

"So, what is a value?  In the pure lambda calculus, any abstraction
is a value.  Remember, an abstraction λx:e is a function; in the
pure lambda calculus, the only values are functions. In an applied
lambda calculus with integers and arithmetic operations, values
also include integers.  Intuitively, a value is an expression
that can not be reduced/executed/simplified any further."



[...]
> The lambda calculus comment is just an aside. The main point is that you
> shouldn't lead people to believe that Python has variables that are any
> different than, say, Pascal's variables (even if you, for whatever
> reason, want to call them "names"). They are memory slots that hold
> values until you assign new values to them.

Nevertheless, they are still different.

My computer has an ethernet slot and a USB slot, and while they are both 
slots that hold a cable and transmit information in and out of the 
computer, they are nevertheless different. The differences are just as 
important as the similarities.


> It *is* true that Python has a more limited data model than Pascal (all
> of Python's values are objects in the heap and only accessible through
> pointers).

Calling it "more limited" is an inaccurate and pejorative way of putting 
it. Rather, I would say it is a more minimalist, *elegant* data model:

* a single kind of variable (objects in the heap where the interpreter
  manages the lifetime of objects for you)

as opposed to Pascal's more complex and more difficult model:

* two kinds of variables:

  - first-class variables that the compiler manages for you 
(allocating and deallocating them on the stack)

  - second-class variables that the programmer has to manage
manually (declaring pointers, allocating memory by hand,
tracking the lifetime of the memory block yourself,
deallocating it when you are done, and carefully avoiding
accessing the pointed-to memory block after deallocation).


At least more modern languages with both value-types and reference-types 
(such as Java, C#, Objective C, Swift) manage to elevate their reference-
type variables to first-class citizenship.


> Also, unlike Pascal, variables can hold (pointers to) values
> of any type. IOW, Python has the data model of Lisp.
> 
> Lisp talks about binding and rebinding variables as well:
> 
>https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node79.html>
> 
> which might be Lambda Calculus legacy, but at least they are not shy to
> talk about variables and assignment.




-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

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

Re: Non-GUI, single processort inter process massaging - how?

[Anders Wegge Keller]

På Sat, 21 Jul 2018 09:07:23 +0100
Chris Green  skrev:

> So - what's the best approach to this?  I've done some searching and
> most/many of the solutions seem rather heavyweight for my needs. Am I
> overlooking something obvious or should I try rethinking the original
> requirement and look for another approach?

 What do you consider heavyweight? Number of dependencies, memory footprint,
amount of code or a fourth thing? Also, which platform will the code
eventually run on?

 If your update frequency is low enough that it wont kill the filesystem and
the amount of data is reasonably small, atomic writes to a file is easy to
work with:

  def atomic_write(filename, data):
handle, name = tempfile.mkstemp()
os.write(handle, data)
os.fsync(handle)
os.close(handle)
os.replace(tmpname, filename)

 The imports are trivial to deduce, so I removed the clutter. If you have
multiple filesystems, you may have to read into the details of calling
mkstemp.


 If you have an update frequency that will kill the filesystem (for instance
a RPi on a SD card), or have a larger data set where you only want to do
partial updates, the mmap module could be an option. It require some more
boilerplate. You will probably also have to consider a semaphore to
guarantee that the clients read a consistent result set.

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

Python shuts down when I try to run a module

[Lyra]

Hello,
I’ve just started to learn Python coding, and downloaded version 3.7.0 from the 
website.  I’ve written 5 or 6 small programs and saved them, but whenever I try 
to run them, Python doesn’t work right.  The user answers the first question 
and presses ENTER, but then the Python window just closes, disappears, and 
shuts down.  My programs are all written correctly, and work just like they’re 
supposed to, when I run them in the Shell window instead.  There are no error 
messages.
I went into the original installation file of Python and clicked on “Repair”.  
There was a progress bar, and it said “Repair completed”, but the problem still 
occurs.
I don’t want to uninstall the whole thing and download a different version 
until after I hear from someone here who knows more about it than I do.

Please respond soon.

Thanks.


Sent from Mail for Windows 10

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

Re: Python shuts down when I try to run a module

[Calvin Spealman]

This is an unfortunate property of running command line programs on
Windows. If you run the script directly (like by double clicking on it?)
the console window will close when the program is done, so you can't see
the final output.

To get around this you could run them in the IDLE editor, which comes with
Python 3.7 for Windows, or you could open a windows command prompt and run
your Python scripts from there.

On Mon, Jul 23, 2018 at 3:00 AM, Lyra  wrote:

> Hello,
> I’ve just started to learn Python coding, and downloaded version 3.7.0
> from the website.  I’ve written 5 or 6 small programs and saved them, but
> whenever I try to run them, Python doesn’t work right.  The user answers
> the first question and presses ENTER, but then the Python window just
> closes, disappears, and shuts down.  My programs are all written correctly,
> and work just like they’re supposed to, when I run them in the Shell window
> instead.  There are no error messages.
> I went into the original installation file of Python and clicked on
> “Repair”.  There was a progress bar, and it said “Repair completed”, but
> the problem still occurs.
> I don’t want to uninstall the whole thing and download a different version
> until after I hear from someone here who knows more about it than I do.
>
> Please respond soon.
>
> Thanks.
>
>
> Sent from Mail for Windows 10
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: list of lists

[Sharan Basappa]

On Sunday, 22 July 2018 21:07:17 UTC+5:30, Thomas Jollans  wrote:
> On 22/07/18 14:53, Sharan Basappa wrote:
> > Thanks. I initially thought about this but did not know if this is legal 
> > syntax.
> 
> In this kind of situation – you think you know how to do something but
> you're not quite sure if it'll work as intended – just try it! Start up
> an interactive interpreter, or write a test script (as you appear to
> have done). If it doesn't work, that's fine. No harm done.
> 
> Also, please use Python 3.

Agree. That is one advantage of interpreted language. For quick trial and 
error, not much overhead and we can print lot of variables once script is run.
-- 
https://mail.python.org/mailman/listinfo/python-list

Python in the news

[Rich Shepard]

  The lead article in science section and technology section of this week's
'The Economist' is about Python:


Enjoy,

Rich

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

Re: Python shuts down when I try to run a module

[Neil Cerutti]

On 2018-07-23, Calvin Spealman  wrote:
> This is an unfortunate property of running command line
> programs on Windows. If you run the script directly (like by
> double clicking on it?) the console window will close when the
> program is done, so you can't see the final output.
>
> To get around this you could run them in the IDLE editor, which
> comes with Python 3.7 for Windows, or you could open a windows
> command prompt and run your Python scripts from there.

You can also put

input("Press [Enter] to exit.")

at the end of your program, though unfortunately it doesn't help
when an error occurs, requiring you to put it in a finally block
to ensure it happens.

-- 
Neil Cerutti

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

Tracking a memory leak in C extension - interpreting the output of PYTHONMALLOCSTATS

[Bartosz Golaszewski]

Hi!

A user recently reported a memory leak in python bindings (C extension
module) to a C library[1] I wrote. I've been trying to fix it since
but so far without success. Since I'm probably dealing with a space
leak rather than actual memory leak, valgrind didn't help much even
when using malloc as allocator. I'm now trying to use
PYTHONMALLOCSTATS but need some help on how to interpret the output
emitted it's enabled.

I'm setting PYTHONMALLOCSTATS=1 & PYTHONMALLOC=pymalloc_debug and then
running the script that triggers the leak. The last debug message is
as follows:

class   size   num pools   blocks in use  avail blocks
-      -   -  
3 32   1   2   124
4 40   2   9   193
5 48   1   381
6 56   1   468
7 64  11 295   398
8 72   9 260   244
9 80  36 831   969
   10 88  791542  2092
   11 96 1313262  2240
   12104  701903   757
   13112  19 289   395
   14120  11 139   224
   15128   7  88   129
   16136   6  70   104
   17144   5  4496
   18152   4  4757
   19160  24 342   258
   20168   4  1779
   21176  24 360   192
   22184   2   836
   23192   2  1131
   24200  22 227   213
   25208   3  1344
   26216   3   747
   27224   2  1323
   28232   2   628
   29240   3   840
   30248   2  1022
   31256   3  1035
   32264   2   921
   33272   3  1131
   34280   2  1018
   35288   1   311
   36296   2   917
   37304   2   917
   38312   2   519
   39320   2   519
   40328  14 10563
   41336   2   321
   42344   1   3 8
   43352   1   3 8
   44360   2   319
   45368   1   3 8
   46376   1   1 9
   47384   2   416
   48392   2   614
   49400   2   317
   50408   1   1 8
   51416   1   3 6
   52424   2   414
   53432   50967  45868023
   54440   3   918
   55448   4  1521
   56456   4  1220
   57464   3   816
   58472   2   511
   59480   1   4 4
   60488   1   3 5
   61496   4  1121
   62504   4  1319
   63512   2   7 7

# times object malloc called   =2,811,245
# arenas allocated total   =  810
# arenas reclaimed =0
# arenas highwater mark=  810
# arenas allocated current =  810
810 arenas * 262144 bytes/arena=  212,336,640

# bytes in allocated blocks=  199,277,432
# bytes in available blocks=1,138,472
308 unused pools * 4096 bytes  =1,261,568
# bytes lost to pool headers   =2,473,536
# bytes lost to quantization   =8,185,632
# bytes lost to arena alignment=0
Total  =  212,336,640

The number of pools in arena 53 continuously grows. Its size column
says: 432. I couldn't find any documentation on what it means but I
assume it's an allocation of 432 bytes. I launched gdb and set 

Re: PyCharm

[Michael Vilain]

I used the pycharm edu version from here:

https://www.jetbrains.com/pycharm-edu/download/download-thanks.html?platform=mac

input works fine on it. YMMV.


> On 20-Jul-2018, at 9:15 PM 🌙, no@none.invalid wrote:
> 
> On Fri, 20 Jul 2018 20:56:41 -0700, Michael Vilain
>  wrote:
> 
>> I'm running PyCharm Edu (to go through their great tutorial). It's version 
>> is 2018.1.3, which I got from the web site.  Unless you mistyped the 
>> version, this is the current release and yours is very old.
> 
> The date was just from a message posted back in Jan.
> 
> My version  says:
> PyCharm 2018.1.4 (Community Edition)
> Build #PC-181.5087.37, built on May 24, 2018
> JRE: 1.8.0_152-release-1136-b39 amd64
> JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
> Windows 7 6.1
> 
> When I try to use an input statment, the program freezes.  I have to
> terminate it.
> 
> What happens when you try to run code with an input statment?
> 
> -- 
> https://mail.python.org/mailman/listinfo/python-list

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

Want to be a rockstar programmer?

[Larry Martell]

https://github.com/dylanbeattie/rockstar
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Want to be a rockstar programmer?

[Brian Oney via Python-list]

meh, I'm more into 90s and 00s metal rock and punk rock. Oh well, I knew it 
wasn't meant to be. ;)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Tracking a memory leak in C extension - interpreting the output of PYTHONMALLOCSTATS

[Thomas Jollans]

On 23/07/18 20:02, Bartosz Golaszewski wrote:
> Hi!

Hey!

> A user recently reported a memory leak in python bindings (C extension
> module) to a C library[1] I wrote. I've been trying to fix it since
> but so far without success. Since I'm probably dealing with a space
> leak rather than actual memory leak, valgrind didn't help much even
> when using malloc as allocator. I'm now trying to use
> PYTHONMALLOCSTATS but need some help on how to interpret the output
> emitted it's enabled.

Oh dear.

> 
> [snip]
> 
> The number of pools in arena 53 continuously grows. Its size column
> says: 432. I couldn't find any documentation on what it means but I
> assume it's an allocation of 432 bytes. [...]

I had a quick look at the code (because what else does one do for fun);
I don't understand much, but what I can tell you is that
 (a) yes, that is an allocation size in bytes, and
 (b) as you can see, it uses intervals of 8. This means that pool 53
 is used for allocations of 424 < nbytes <= 432 bytes. Maybe your
 breakpoint needs tweaking.
 (c) Try breaking on _PyObject_Malloc or pymalloc_alloc. I think they're
 called by both PyMem_Malloc and PyObject_Malloc.

int _PyObject_DebugMallocStats(FILE *out)

https://github.com/python/cpython/blob/b18f8bc1a77193c372d79afa79b284028a2842d7/Objects/obmalloc.c#L2435

static int pymalloc_alloc(void *ctx, void **ptr_p, size_t nbytes)

https://github.com/python/cpython/blob/b18f8bc1a77193c372d79afa79b284028a2842d7/Objects/obmalloc.c#L1327


Have fun debugging!

-- Thomas


> 
> How do I use the info produced by PYTHONMALLOCSTATS do get to the
> culprit of the leak? Is there anything wrong in my reasoning here?
> 
> Best regards,
> Bartosz Golaszewski
> 
> [1] https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/
> 

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

Re: Non-GUI, single processort inter process massaging - how?

[Chris Green]

Anders Wegge Keller  wrote:
> På Sat, 21 Jul 2018 09:07:23 +0100
> Chris Green  skrev:
> 
> > So - what's the best approach to this?  I've done some searching and
> > most/many of the solutions seem rather heavyweight for my needs. Am I
> > overlooking something obvious or should I try rethinking the original
> > requirement and look for another approach?
> 
>  What do you consider heavyweight? Number of dependencies, memory footprint,
> amount of code or a fourth thing? Also, which platform will the code
> eventually run on?
> 
>  If your update frequency is low enough that it wont kill the filesystem and
> the amount of data is reasonably small, atomic writes to a file is easy to
> work with:
> 
Yes, I think you're right, using a file would seem to be the best
answer.  Sample rate is only one a second or slower and there's not a
huge amount of data involved.

Thanks.

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

Re: ongoing browser projects

[Akkana Peck]

> > On 23/07/18 03:43, Akkana Peck wrote:
> >> You'd think there would be something newer (ideally
> >> based on Blink) that worked with GTK3/GIO, but I never found anything.

Thomas Jollans writes:
> > This gi-based example looks like Gtk3, right?
> 
> https://gist.github.com/kklimonda/890640#file-pybrowser-py-L14

Sure enough, that works, at least with the webkit in Debian's
gir1.2-webkit-3.0 package. It didn't work with gir1.2-webkit2-4.0:
  File "", line 888, in _find_spec"
  AttributeError: 'DynamicImporter' object has no attribute 'find_spec'
and then various further errors resulting from those; but at
least it's possible to make a Python 3, GTK3, webkit 3.0 browser.
And it even handles fullscreen events (like from youtube), something
I've never managed in QtWebEngine.

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

curses, ncurses or something else

[John Pote]

I recently wrote a command line app to take a stream of numbers, do some 
signal processing on them and display the results on the console. There 
may be several output columns of data so a title line is printed first. 
But the stream of numbers may be several hundred long and the title line 
disappears of the top on the console.


So I thought it might be quick and easy to do something with curses to 
keep the title line visable while the numbers roll up the screen. But 
alas I'm a Windows user and the 'curses' module is not in the Windows 
standard library for Python.


It occured to me that I could create a simple tkinter class but I 
haven't tinkered for some time and would have to refresh my knowledge of 
the API. Just wondered if there was any other simple way I could keep 
the title line on the console, preferably without having to install 
another library.


Ideas invited.


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

Python 2.7.14 and Python 3.6.0 netcdf4

[jorge . conrado]

 Hi,

 Please someone can help me with this error message;


 for Python 2.7.14 I did:

 from netCDF4 import Dataset

 and I didn't have no message



 But, for Python 3.6.0

 from netCDF4 import Dataset

 I had:

 Traceback (most recent call last):
 File "", line 1, in 
 ModuleNotFoundError: No module named 'netCDF4'


 What can I do to solve this error for Python 3.6.0


 Thanks,


 Conrado

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

Re: Python shuts down when I try to run a module

[Michael Torrie]

On 07/23/2018 01:00 AM, Lyra wrote:
> Hello,
> I’ve just started to learn Python coding, and downloaded version 3.7.0 from 
> the website.  I’ve written 5 or 6 small programs and saved them, but whenever 
> I try to run them, Python doesn’t work right.  The user answers the first 
> question and presses ENTER, but then the Python window just closes, 
> disappears, and shuts down.  My programs are all written correctly, and work 
> just like they’re supposed to, when I run them in the Shell window instead.  
> There are no error messages.
> I went into the original installation file of Python and clicked on “Repair”. 
>  There was a progress bar, and it said “Repair completed”, but the problem 
> still occurs.
> I don’t want to uninstall the whole thing and download a different version 
> until after I hear from someone here who knows more about it than I do.

This is expected behavior on Windows.  Unless your program has a
graphical user interface that you've created, the proper way to run an
*interactive* python program is from the command prompt.  Alternatively
you can run it from within IDLE or some other Python IDE like PyCharm.
So you're not doing anything wrong. Just don't run them by double
clicking; run them from a command prompt instead.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: curses, ncurses or something else

[Rich Shepard]

On Mon, 23 Jul 2018, John Pote wrote:


So I thought it might be quick and easy to do something with curses to
keep the title line visable while the numbers roll up the screen. But alas
I'm a Windows user and the 'curses' module is not in the Windows standard
library for Python.


John,

  I don't recall if urwid  supports windows, but it has
more display and UI capabilities than either curses or ncurses. Urwid is a
console widget library for python.

HTH,

Rich

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

Re: curses, ncurses or something else

[Dale Marvin via Python-list]

On 7/23/18 3:24 PM, John Pote wrote:
I recently wrote a command line app to take a stream of numbers, do some 
signal processing on them and display the results on the console. There 
may be several output columns of data so a title line is printed first. 
But the stream of numbers may be several hundred long and the title line 
disappears of the top on the console.


So I thought it might be quick and easy to do something with curses to 
keep the title line visable while the numbers roll up the screen. But 
alas I'm a Windows user and the 'curses' module is not in the Windows 
standard library for Python.


It occured to me that I could create a simple tkinter class but I 
haven't tinkered for some time and would have to refresh my knowledge of 
the API. Just wondered if there was any other simple way I could keep 
the title line on the console, preferably without having to install 
another library.


Ideas invited.




You didn't tell us much about your application but for analysis and 
display I like Jupiter Notebook. Plus it's easy to add graphs etc.


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

Re: curses, ncurses or something else

[Thomas Jollans]

On 24/07/18 00:24, John Pote wrote:
> Ideas invited.

This doesn't answer your question at all, but when I want a small script
to produce largish streams of numbers, I write them to a (csv) file and
plot them using matplotlib then and there.

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

Re: Python 2.7.14 and Python 3.6.0 netcdf4

[Thomas Jollans]

On 24/07/18 00:39, jorge.conr...@cptec.inpe.br wrote:
>  from netCDF4 import Dataset
> 
>  I had:
> 
>  Traceback (most recent call last):
>  File "", line 1, in 
>  ModuleNotFoundError: No module named 'netCDF4'
> 
> 
>  What can I do to solve this error for Python 3.6.0

Install netCDF4 in your Python 3.6 environment.

Depending on what OS and Python distribution you're using, the thing to
do might be

py -3 -m pip install netCDF4

or

pip3 install netCDF4

(or something involving conda if you use anaconda)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python 2.7.14 and Python 3.6.0 netcdf4

[Steven D'Aprano]

On Mon, 23 Jul 2018 19:39:18 -0300, jorge.conrado wrote:

>   Traceback (most recent call last):
>   File "", line 1, in 
>   ModuleNotFoundError: No module named 'netCDF4'
> 
> 
>   What can I do to solve this error for Python 3.6.0

Just because you have the Python 2.7 version of the netCDF4 module 
installed in the Python 2.7 environment, doesn't mean it will magically 
work for Python 3.6. You have to install the module for 3.6 as well.

How did you install it for Python 2.7?


-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

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

Re: Python 2.7.14 and Python 3.6.0 netcdf4

[MRAB]

On 2018-07-23 23:39, jorge.conr...@cptec.inpe.br wrote:



   Hi,

   Please someone can help me with this error message;


   for Python 2.7.14 I did:

   from netCDF4 import Dataset

   and I didn't have no message


That's because you've installed netCDF4 for Python 2.7.



   But, for Python 3.6.0

   from netCDF4 import Dataset

   I had:

   Traceback (most recent call last):
   File "", line 1, in 
   ModuleNotFoundError: No module named 'netCDF4'


That's because you haven't installed netCDF4 for Python 3.6.



   What can I do to solve this error for Python 3.6.0


Install that module.

Assuming that you're using Windows, try this in a console window:

py -3.6 -m pip install netCDF4
--
https://mail.python.org/mailman/listinfo/python-list

Format list of list sub elements keeping structure.

[Sayth Renshaw]

I have data which is a list of lists of all the full paths in a json document.

How can I change the format to be usable when selecting elements?

data = [['glossary'],
 ['glossary', 'title'],
 ['glossary', 'GlossDiv'],
 ['glossary', 'GlossDiv', 'title'],
 ['glossary', 'GlossDiv', 'GlossList'],
 ['glossary', 'GlossDiv', 'GlossList', 'GlossEntry'],
 ['glossary', 'GlossDiv', 'GlossList', 'GlossEntry', 'ID'],
 ['glossary', 'GlossDiv', 'GlossList', 'GlossEntry', 'SortAs'],
 ['glossary', 'GlossDiv', 'GlossList', 'GlossEntry', 'GlossTerm'],
 ['glossary', 'GlossDiv', 'GlossList', 'GlossEntry', 'Acronym'],
 ['glossary', 'GlossDiv', 'GlossList', 'GlossEntry', 'Abbrev'],
 ['glossary', 'GlossDiv', 'GlossList', 'GlossEntry', 'GlossDef'],
 ['glossary', 'GlossDiv', 'GlossList', 'GlossEntry', 'GlossDef', 'para'],
 ['glossary', 'GlossDiv', 'GlossList', 'GlossEntry', 'GlossDef', 
'GlossSeeAlso'],
 ['glossary', 'GlossDiv', 'GlossList', 'GlossEntry', 'GlossDef', 
'GlossSeeAlso', 0],
 ['glossary', 'GlossDiv', 'GlossList', 'GlossEntry', 'GlossDef', 
'GlossSeeAlso', 1],
 ['glossary', 'GlossDiv', 'GlossList', 'GlossEntry', 'GlossSee']]

I am trying to change it to be.

[['glossary'],
 ['glossary']['title'],
 ['glossary']['GlossDiv'],
]

Currently when I am formatting I am flattening the structure(accidentally).

for item in data:
for elem in item:
out = ("[{0}]").format(elem)
print(out)

Which gives

[glossary]
[title]
[GlossDiv]
[title]
[GlossList]
[GlossEntry]
[ID]
[SortAs]
[GlossTerm]
[Acronym]
[Abbrev]
[GlossDef]
[para]
[GlossSeeAlso]
[0]
[1]
[GlossSee]


Cheers

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

Re: curses, ncurses or something else

[eryk sun]

On Mon, Jul 23, 2018 at 10:24 PM, John Pote  wrote:
>
> So I thought it might be quick and easy to do something with curses to keep
> the title line visable while the numbers roll up the screen. But alas I'm a
> Windows user and the 'curses' module is not in the Windows standard library
> for Python.

Try this versions, based on PDCurses:

https://www.lfd.uci.edu/~gohlke/pythonlibs/#curses
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Format list of list sub elements keeping structure.

[Sayth Renshaw]

> > 
> > for item in data:
> > for elem in item:
> > out = ("[{0}]").format(elem)
> > print(out)
> 
> Hint: print implicitly adds a newline to the output string. So collect all 
> the values of each sublist and print a line-at-time to output, or use the 
> end= argument of Py3's print, or find another solution. Also remember that 
> indention is significant in Python.

Thanks

Getting closer.

answer = []
for item in data:
for elem in item:
out = ("[{0}]").format(elem)
answer.append(out)

print(answer)

Think I need to bring it in a list not an element of a list and process it.

Cheers

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

Re: Format list of list sub elements keeping structure.

[Sayth Renshaw]

I am very close to the end result. I now have it as

Output
[   ['[glossary]'],
['[glossary]', '[title]'],
['[glossary]', '[GlossDiv]'],
['[glossary]', '[GlossDiv]', '[title]'],
['[glossary]', '[GlossDiv]', '[GlossList]'],
['[glossary]', '[GlossDiv]', '[GlossList]', '[GlossEntry]'],
.]

I used.

elements = [['[{0}]'.format(element) for element in elements]for elements in 
data]

Is there a good way to strip the ', ' and make the list a list of 1 element 
lists? Thoughts on achieving this?

So

[   ['[glossary]'],
['[glossary][title]'],
]

Cheers

Sayth

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

Re: Format list of list sub elements keeping structure.

[Sayth Renshaw]

On Tuesday, 24 July 2018 14:25:48 UTC+10, Rick Johnson  wrote:
> Sayth Renshaw wrote:
> 
> > elements = [['[{0}]'.format(element) for element in elements]for elements 
> > in data]
> 
> I would suggest you avoid list comprehensions until you master long-form 
> loops.

My general issue is that I want to pick up all the elements in each sublist and 
operate on them to concatenate them together.

However, using for loops I get each list then each element of each list.
When in my head I want each list then all elements of each list.

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

Re: Format list of list sub elements keeping structure.

[Sayth Renshaw]

On Tuesday, 24 July 2018 14:25:48 UTC+10, Rick Johnson  wrote:
> Sayth Renshaw wrote:
> 
> > elements = [['[{0}]'.format(element) for element in elements]for elements 
> > in data]
> 
> I would suggest you avoid list comprehensions until you master long-form 
> loops.

I actually have the answer except for a glitch where on list element is an int.

My code

for item in data:
out = '[{0}]'.format("][".join(item))
print(out)

which prints out

[glossary]
[glossary][title]
[glossary][GlossDiv]
[glossary][GlossDiv][title]
[glossary][GlossDiv][GlossList]


However, in my source I have two lines like this

 ['glossary', 'GlossDiv', 'GlossList', 'GlossEntry', 'GlossDef', 
'GlossSeeAlso', 0],
 ['glossary', 'GlossDiv', 'GlossList', 'GlossEntry', 'GlossDef', 
'GlossSeeAlso', 1],

when it hits these lines I get 

TypeError: sequence item 6: expected str instance, int found

Do I need to do an explicit check for these 2 cases or is there a simpler way?

Cheers

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