Re: Python version of Ruby devkit - Advice On library compilation

[Chris Angelico]

On Mon, Nov 9, 2015 at 3:00 PM, Sayth Renshaw  wrote:
> This is an exert
>
> DevKit Overview
> The DevKit is a toolkit that makes it easy to build and use native C/C++ 
> extensions such as RDiscount and RedCloth for Ruby on Windows.
>
> Because on Windows with python libraries like lxml will fail with a vcvarsall 
> error based on different c++ compilers.

Ah okay.

The normal way to install Python extensions on Windows is to get a
precompiled binary. That way, you don't have to worry about compilers
at all. In the case of lxml, you can get them straight off PyPI:

https://pypi.python.org/pypi/lxml/3.4.4

I don't have a Windows system to test with, but 'pip' should be able
to go fetch them for you. There does seem to be a bit of a hole,
though: there's an installer that targets CPython 3.2, but nothing
newer. Fortunately, there's another good place to find Windows
binaries - this unofficial (but fairly trustworthy) site:

http://www.lfd.uci.edu/~gohlke/pythonlibs/#lxml

Binaries targeting CPython 2.7, 3.3, 3.4, and 3.5 are all there.
Download the appropriate one (due to compiler differences, you MUST
pick the one for your CPython version, or it won't work), and use
easy_install on the egg file.

Actually installing a build chain on Windows is such a pain that it's
usually easier to fiddle around with binaries than to build from
source. That's probably why there's no Python DevKit - even with that
kind of thing, getting all your deps right would be a pain.

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

Re: Python version of Ruby devkit - Advice On library compilation

[Sayth Renshaw]

This is an exert 

DevKit Overview
The DevKit is a toolkit that makes it easy to build and use native C/C++ 
extensions such as RDiscount and RedCloth for Ruby on Windows.

Because on Windows with python libraries like lxml will fail with a vcvarsall 
error based on different c++ compilers. 

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

Re: [Ubuntu] PyQt5

[Laura Creighton]

In a message of Sun, 08 Nov 2015 18:05:32 -0500, Terry Reedy writes:
>On 11/8/2015 11:03 AM, Andrew Diamond wrote:
>> On Saturday, November 7, 2015 at 10:13:25 PM UTC-5, Andrew Diamond
>> wrote:
>>> Hi!
>>>
>>> I'm fairly new to Python, and installed pyqt5 and began working
>>> through the examples at http://zetcode.com/gui/pyqt5/menustoolbars/
>>> However, whenever I click one of the buttons or menus in the
>>> example apps I run that is supposed to quit the application, it
>>> locks up.
>
>What is 'it'?  And what does 'lock up' mean?  Did the gui freeze and not 
>disappear?  Or did IDLE itself freeze, and even the menu quit working?
>
>>> This happens with all the examples I installed that
>>> handle code to quit the app.
>>>
>>> Running Ubuntu 15.10, and installed pyqt5 via:
>>>
>>> sudo apt-get install python3-pyqt5 sudo apt-get install qtcreator
>
>> I just read somewhere that the issue could be because I was trying to
>> run these examples from within Idle.
>
>I am an IDLE maintainer.  Am I to take it that everything ran fine 
>before you tried to quit?  If not, I would want to know why and try to fix.
>
>If you run tut.py from an IDLE editor, IDLE tries to run it the same as 
>if you ran it at a console in the tut.py directory with 'python3 -i 
>tut.py'.  I can imagine that there might be a problem with the 
>transition from gui mode to interactive shell mode, though it works for 
>tkinter apps.  You said 'python3 tut.py' works.  What happens if you add 
>the '-i' option?  I'd like to know if the transition problem is in 
>(Py)qt5 or in IDLE's simulation of '-i'.
>
>-- 
>Terry Jan Reedy

I suspect that Qt and Idle are disagreeing as to who gets to have the
main thread around here.

Laura

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

Re: Question about math.pi is mutable

[Steven D'Aprano]

On Mon, 9 Nov 2015 09:35 am, BartC wrote:

> Suppose this is the python program:
> 
> import m
> a=10
> b=20
> c=30
> m.f()
> 
> The set of global names the compiler knows will be ("m","a","b","c").

Wrong. Up to the line "c=30", the set of names the compiler can infer are m,
a, b and c. Once the line "m.f()" executes, *all bets are off*. The
compiler can no longer infer *anything* about those names. In principle,
m.f may have reached into the globals and deleted *any* of the names,
including itself.


> I don't believe code can remove these names (that would cause problems).

Of course names can be removed. There's even a built-in statement to do
so: "del".

Deleting names from namespaces is a moderately common thing to do.


> You say the set of global names can be added to - after this lot, but I
> can't see that the first four are going to change.

Of course they can change.


> Therefore these names could be referred to by index.

Perhaps. But that adds significant complexity to the compiler, and the
performance benefits *in practice* may not be as good as you imagine. After
all, there is usually far more to real programs than just getting and
setting names.

Nevertheless, such indexed name lookups do have the potential to save time,
and in fact that's what CPython already does with local variables. We can
get a *rough* indication of how big a difference this micro-optimization
makes by disabling it. Unfortunately, this only works in Python 2 -- in
Python 3, you can no longer defeat the local variable optimization.


def unopt():
from math import *  # Defeats the local variable optimization.
x = sin; x = cos; x = tan; x = exp; x = pi
x = e; x = trunc; x = log; x = hypot; x = sqrt
return

def opt():
from math import sin, cos, tan, exp, pi, e, trunc, log, hypot, sqrt
x = sin; x = cos; x = tan; x = exp; x = pi
x = e; x = trunc; x = log; x = hypot; x = sqrt
return

from timeit import Timer
t1 = Timer("unopt()", setup="from __main__ import unopt")
t2 = Timer("opt()", setup="from __main__ import opt")

# Best of five trials of 1,000,000 calls each.
print min(t1.repeat(repeat=5))
print min(t2.repeat(repeat=5))


When I run this code, I get

16.5607659817 seconds for unopt, and 3.58955097198 seconds for opt. That's a
significant difference. But remember that not all of that difference is due
to the name lookups (unopt also imports more stuff), and also remember that
this is a pretty unrealistic benchmark. Real functions do more than just
look up a variable name over and over.


> Attributes are harder because they are more of a free-for-all, but
> suppose you do have m.f().
> 
> "m" is easy, it's entry 0 in the global table for this module, so no
> lookup-by-name is needed. You examine it, and it's a module.
> 
> It's now necessary to find f within the global table for m. This is
> where it gets tricky if you want to avoid a lookup. And I expect you
> will say that any code can randomly add names within the global table of
> m.

Of course it can. It can even add names to builtins.

Oh, and you don't know that m is a module until you inspect it at runtime.
It could be any object.



> But bear with me. Suppose the interpreter were to maintain a table for
> each static (not runtime) attribute encountered in the source code. The
> compile can produce empty tables for the attributes it's seen. In this
> case the table for "f" would be empty: (). The compiler will also
> produce a list of such tables for all attributes.

I have no idea how well this implementation would work. My guess is that if
you look at, say, Nuitka, it may perform optimizations like this. (The aim
of Nuitka is to be a static optimizing compiler.) PyPy may do things like
this too, using a JIT optimizing compiler. PyPy is capable of far more than
such simple optimizations.

As I have argued all along, it is certainly not true that Python's
dynamicism prevents all such optimizations. It just makes them harder.


-- 
Steven

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

Re: Question about math.pi is mutable

[Ben Finney]

Chris Angelico  writes:

> Hmm, then I was misunderstanding what BartC was advocating. I didn't
> think it would *fail* in the presence of dynamic attributes, but
> merely *perform suboptimally* (and presumably worse than current
> CPython).

There isn't a way for the compiler to *know*, in all cases, whether
module attributes will be updated during the lifetime of the program
(short of, as pointed out elsewhere, running the entire program under
all possible conditions).

So the optimisation can't be applied by the compiler without risking
breaking perfectly valid code.

That is enough, IMO, to kill the proposal; if the compiler could break
*any* valid code, it's no longer a Python compiler.

-- 
 \   “If [a technology company] has confidence in their future |
  `\  ability to innovate, the importance they place on protecting |
_o__) their past innovations really should decline.” —Gary Barnett |
Ben Finney

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

Re: Question about math.pi is mutable

[Steven D'Aprano]

On Sun, 8 Nov 2015 11:39 pm, BartC wrote:


>> shutil.copyfileobj(Source(), Dest())
>> 
> 
> OK, so here, it is necessary to resolve "copyfileobj" by seeing if
> "shutil" is something that contains a name "copyfileobj" that happens to
> be a method.

Correct.

> Is this the lookup you're talking about, and is it done using the actual
> string "copyfileobj"? If so, does it need to be done every single time
> this line is executed? It would extraordinarily inefficient if that was
> the case.

That's not what Marko was referring to, but you are correct, it is done
using the string "copyfileobj". And it has to be done every single time,
since you cannot be sure that the lookup will always return the same
object, or even whether it will always succeed. For example, here is a
self-destructing method:


class X:
counter = 0
def method(self):
self.counter += 1
if self.counter == 3:
del X.method
msg = "This method will self-destruct in %d calls."
return msg % (3 - self.counter)


But you are wrong to describe this as "extraordinarily inefficient". It is
certainly efficient enough to be practical: inefficient or not, Python is
used for many thousands of practical applications. It is only about a
factor of 100 times slower than C or Java, and the PyPy optimizing compiler
averages ten times faster (and, occasionally, approaches or even exceeds
the speed of similar C or Java code). When performance is critical, you can
often locate the bottlenecks and turn that into C or Fortran code.

Ruby, which is even more flexible than Python in some ways, is even slower,
and yet even Ruby is still fast enough to be practical for many tasks.

And remember too that some of the speed of Java (and especially C) is gained
at the expense of:

- prohibiting the developer from doing certain things;
- restricting the range of values you can use;
- making significant assumptions about correctness;
- avoiding actually checking those assumptions;
- and in the case of C, by outright *ignoring the code you write* if you
inadvertently violate those assumptions.



-- 
Steven

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

Re: Question about math.pi is mutable

[Chris Angelico]

On Mon, Nov 9, 2015 at 11:50 AM, Ben Finney  wrote:
> You misunderstand me. I'm not saying the optimisations would be
> crippled. I am saying that, in order to achieve those optimisations, the
> *test code* would be crippled.
>
> I am pointing out that the assumption necessary for the optimisation
> BartC is advocating – the optimisation of module attributes to be
> immutable after compilation – depends on crippling the *functionality*
> needed for many uses, including test code uses.
>
> Since the compiler should not be in the position of deciding whether
> code is test code or not, it cannot use that criterion to decide whether
> to enable or disable the optimisation.
>
> So either the optimisation should never be enabled (my perference), or
> test code will unwittingly be crippled by the assumptions needed for
> that optimisation.

Hmm, then I was misunderstanding what BartC was advocating. I didn't
think it would *fail* in the presence of dynamic attributes, but
merely *perform suboptimally* (and presumably worse than current
CPython). If it does indeed require crippling the functionality, then
I agree, this is a bad idea.

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

Re: Question about math.pi is mutable

[Ben Finney]

Chris Angelico  writes:

> On Mon, Nov 9, 2015 at 11:26 AM, Ben Finney  
> wrote:
> > Chris Angelico  writes:
> >
> >> Testing/mocking is a completely separate consideration (eg you can
> >> inject a shadow for a built-in name)
> >
> > Not for the purpose of making compiler optimisations, as BartC is
> > advocating. […] since those optimisations would cripple perfectly
> > normal test code, that should be sufficient to quash the desire to
> > make them.
>
> But I distinguish between crippling *performance* and crippling
> *functionality*. If the compiler optimizations are defeated, so the
> test suite falls back on the slow path, that means your tests run
> slower. Unless you're testing the optimizer itself, this shouldn't be
> a problem.

You misunderstand me. I'm not saying the optimisations would be
crippled. I am saying that, in order to achieve those optimisations, the
*test code* would be crippled.

I am pointing out that the assumption necessary for the optimisation
BartC is advocating – the optimisation of module attributes to be
immutable after compilation – depends on crippling the *functionality*
needed for many uses, including test code uses.

Since the compiler should not be in the position of deciding whether
code is test code or not, it cannot use that criterion to decide whether
to enable or disable the optimisation.

So either the optimisation should never be enabled (my perference), or
test code will unwittingly be crippled by the assumptions needed for
that optimisation.

-- 
 \ “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: Question about math.pi is mutable

[Steven D'Aprano]

On Sun, 8 Nov 2015 11:28 pm, Chris Angelico wrote:

> On Sun, Nov 8, 2015 at 10:19 PM, BartC  wrote:
>> I've never understood why this seems to be necessary in Python. Why do
>> names have to be looked up? (I'm assuming this is searching by name in
>> some sort of table.)
> 
> Yes, if by "searching" you include hash-table lookup. A CPython
> dictionary is a *highly* optimized data structure, specifically
> because it's used virtually everywhere (I understand Lua's "table"
> type has similar optimizations for the same reason). In the common
> case, where your names come from literal text in the module, the
> strings used for the lookup will be interned constants, and their
> hashes will have been precalculated and stored, so the lookup is
> pretty easy. So it's a constant-time operation, and while that
> constant may be larger than a simple offset-and-fetch, it's still
> pretty fast in the overall scheme of things.

*Usually*.

There are pathological cases -- if you're unlucky enough, or malicious
enough, to have a whole lot of names with the same hash value, the look-up
degrades to a linear search.

More importantly, consider the case of a function referring to a variable
named "spam". In principle, at least, it may need to:

- search the local namespace;
- search the namespace of one or more enclosing functions;
- search the global namespace;
- search the built-in namespace;

before locating the variable's value. In practice, most Python
implementations will provide at least one optimization: local variables are
recognised and searched using an offset-and-fetch model.

Similarly for method calls: spam.eggs needs to:

- search the instance dict and slots;
- search the class dict;
- search the dict for each additional superclass;

where searching involves more than just a hash table lookup. It also
involves checking the classes for __getattribute__ and __getattr__ methods,
checking for descriptors, and more. The whole lookup process is quite
complicated, and little of it can be done at compile time.



-- 
Steven

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

Re: Python version of Ruby devkit - Advice On library compilation

[Chris Angelico]

On Mon, Nov 9, 2015 at 11:33 AM, Sayth Renshaw  wrote:
> I was wondering if there is a reason that we on windows with python do not 
> have a version of Ruby devkit for python.
>

Many of us here don't use Ruby. Can you elaborate on what "devkit" does, please?

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

Re: Question about math.pi is mutable

[Chris Angelico]

On Mon, Nov 9, 2015 at 11:26 AM, Ben Finney  wrote:
> Chris Angelico  writes:
>
>> Testing/mocking is a completely separate consideration (eg you can
>> inject a shadow for a built-in name)
>
> Not for the purpose of making compiler optimisations, as BartC is
> advocating.
>
> The compiler definitely should not treat “is this code part of a test
> suite?” as a relevant criterion for deciding what optimisation. We
> should certainly not have a compiler that makes needless difference to
> code behaviour under test conditions versus non-test conditions.
>
> So, since those optimisations would cripple perfectly normal test code,
> that should be sufficient to quash the desire to make them.

But I distinguish between crippling *performance* and crippling
*functionality*. If the compiler optimizations are defeated, so the
test suite falls back on the slow path, that means your tests run
slower. Unless you're testing the optimizer itself, this shouldn't be
a problem.

This is broadly the same kinds of optimizations that Fat Python is
playing with. Effectively, what it says is "I think that 'len' is this
object", and then it guards the fast path with a quick check for
validity. So if you go in and change something, the result is that the
slow path gets used instead.

The question then is whether it's worth the optimization effort. Will
the slow path be penalized more than the fast path gains? Will the
code complexity introduce more bugs? The same consideration comes up
in JavaScript/ECMAScript (where object attributes can also be created
dynamically), and I know some interpreters have been written to do a
slot-based lookup, so the concept does have at least some merit.

Personally, I'm dubious about the value of this in CPython; but I'm
willing to be persuaded.

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

Python version of Ruby devkit - Advice On library compilation

[Sayth Renshaw]

Hi

I was wondering if there is a reason that we on windows with python do not have 
a version of Ruby devkit for python. 

Is it just for historical reason of life before pip became the package manager 
and released with python? 
I can't find the actual post in SO it came off this discussion 
http://stackoverflow.com/a/13445719/461887 regarding vcvarsall and related 
python packaging queries. 

I know it wouldn't solve all pain points as I don't believe(could be wrong 
here) it would be unable to include Atlas compilation for some scientific 
libraries but it would be able to compile most targets and reduce the need for 
alternate implementations, like conda.

Not that there is anything wrong with conda at all except you need to rebuild 
most of the libraries in binstar to use them, but its virtualenv feature is 
nice and if you use R its good to.

Someone more windows and library build savvy is this something easily 
achievable for windows and would it help?

Cheers

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

Re: Question about math.pi is mutable

[Ben Finney]

Chris Angelico  writes:

> Testing/mocking is a completely separate consideration (eg you can
> inject a shadow for a built-in name)

Not for the purpose of making compiler optimisations, as BartC is
advocating.

The compiler definitely should not treat “is this code part of a test
suite?” as a relevant criterion for deciding what optimisation. We
should certainly not have a compiler that makes needless difference to
code behaviour under test conditions versus non-test conditions.

So, since those optimisations would cripple perfectly normal test code,
that should be sufficient to quash the desire to make them.

-- 
 \   “If you define cowardice as running away at the first sign of |
  `\   danger, screaming and tripping and begging for mercy, then yes, |
_o__)   Mr. Brave man, I guess I'm a coward.” —Jack Handey |
Ben Finney

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

Re: Is there an archive of the gohlke python binaries on windows

[Sayth Renshaw]

On Sunday, 8 November 2015 21:30:59 UTC+11, Laura Creighton  wrote:
> In a message of Sat, 07 Nov 2015 21:55:32 -0800, Sayth Renshaw writes:
> >Just wondering if there is an archive mirror for these binaries available. i 
> >was looking for lxml 3.4.1 and the current version is the latest on the page 
> >at 3.4.4 being on windows I cannot build it.
> >
> >http://www.lfd.uci.edu/~gohlke/pythonlibs/
> >
> >Thanks
> >
> >Sayth
> 
> https://pypi.python.org/pypi/lxml/3.4.1
> 
> Laura

Thanks Laura but that fails to install because I uninstalled visual studio and 
its compiler.

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

Re: Question about math.pi is mutable

[BartC]

On 09/11/2015 00:00, Ben Finney wrote:

BartC  writes:


Is this typical Python code? Creating global objects in other modules
(or writing all over essential data structures in a library module).


Not “creating global objects”, but changing the referent of a name in
some other module. Yes, that's quite a common technique. Does that
surprise you?


Changing the referent (I assume that just means assigning to it or 
updating the associated value) wouldn't be a problem. Provided the name 
was defined in that other module, because then it is a name the compiler 
would know about.


(And, more importantly, someone reading the code in that module would 
know about.)



If it surprises you, hopefully you can learn some more Python with this
new knowledge.


Yes, that it's more of a crazy language than it looks at first; I can 
write a simple module like this:


pass

which looks like an empty module, yet for all I know will end up contain 
hundreds of variables by the time it's run.


(I normally use my own language, that I call 'dynamic', but compared 
with Python it might as well be carved in stone!)


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

Re: Question about math.pi is mutable

[Chris Angelico]

On Mon, Nov 9, 2015 at 11:00 AM, Ben Finney  wrote:
> BartC  writes:
>
>> Is this typical Python code? Creating global objects in other modules
>> (or writing all over essential data structures in a library module).
>
> Not “creating global objects”, but changing the referent of a name in
> some other module. Yes, that's quite a common technique. Does that
> surprise you?

Changing the referent of an existing name, definitely. Creating new
names, not so much. You don't often reach into another module and
create a new attribute.

Testing/mocking is a completely separate consideration (eg you can
inject a shadow for a built-in name); if some Python implementation
has a fast path that gets defeated by "module.int = MagicInt", and it
causes the tests to run slower, so be it. Other than that, I can't
think of many cases (actually, can't think of any, off hand) where you
inject names into other modules.

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

Re: Question about math.pi is mutable

[Ben Finney]

BartC  writes:

> Is this typical Python code? Creating global objects in other modules
> (or writing all over essential data structures in a library module).

Not “creating global objects”, but changing the referent of a name in
some other module. Yes, that's quite a common technique. Does that
surprise you?

If it surprises you, hopefully you can learn some more Python with this
new knowledge.

-- 
 \ “We can't depend for the long run on distinguishing one |
  `\ bitstream from another in order to figure out which rules |
_o__)   apply.” —Eben Moglen, _Anarchism Triumphant_, 1999 |
Ben Finney

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

Re: Question about math.pi is mutable

[BartC]

On 08/11/2015 23:13, Dennis Lee Bieber wrote:

On Sun, 8 Nov 2015 18:58:36 +, BartC  declaimed the
following:


But then, you say that additional attributes, potentially millions of
different ones, can be invented at runtime. Although I don't see how it
can remove names that are part of the source code: if "A.B" is in the
file, then surely "A" and "B" always have to be present in some table or
other.


-=-=-=-=- module.py

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

-=-=-=-=- main.py

import module

module.remote = module.Something()
nonremote = module.remote
nonremote.x = "Looky here"
print module.remote.x
module.remote.x = 3.14
print nonremote.x
module.remote = None
print nonremote.x
print module.remote.x


Is this typical Python code? Creating global objects in other modules 
(or writing all over essential data structures in a library module).


If most code is going to be more sensible, then I mentioned an approach 
in my other post just over an hour ago. The idea there was to optimise 
attribute lookups when code is written with more restraint. (So defining 
functions, classes and attributes within classes in a boring manner.)



Where do you propose to "tableize" remote, nonremote, and x. "remote"
doesn't exist inside module.py until one executes main.py -- so it can't be


In your example, only attributes "remote" and "x" exist. But the tables 
for those will be empty as it is not practical to add in runtime-created 
attributes. Then, a conventional lookup would be needed.



optimized to when the compiler parses module.py (creating, in most cases a
bytecode module.pyc). You can't optimize it to main.py since (not shown in
my example) there may be another imported package that also imports module
and references module.remote -- and could even replace it with a new object
(in which case nonremote is still associated with the old object, not the
new one)


The tables would reflect the static layout of the attributes as defined 
in the source code. Since the source code is finite, the tables will be 
also (unlike runtime when a billion attributes could be created).


If your module.py code is tweaked like this:

 class Something(object):
x=0
def __init__(self):
pass

 remote=0

Then 'x' and 'remote' become static attributes that can now added to 
tables for fast lookup. Although this does require that these two are 
effectively 'declared'.


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

Re: [Ubuntu] PyQt5

[Terry Reedy]

On 11/8/2015 11:03 AM, Andrew Diamond wrote:

On Saturday, November 7, 2015 at 10:13:25 PM UTC-5, Andrew Diamond
wrote:

Hi!

I'm fairly new to Python, and installed pyqt5 and began working
through the examples at http://zetcode.com/gui/pyqt5/menustoolbars/
However, whenever I click one of the buttons or menus in the
example apps I run that is supposed to quit the application, it
locks up.


What is 'it'?  And what does 'lock up' mean?  Did the gui freeze and not 
disappear?  Or did IDLE itself freeze, and even the menu quit working?



This happens with all the examples I installed that
handle code to quit the app.

Running Ubuntu 15.10, and installed pyqt5 via:

sudo apt-get install python3-pyqt5 sudo apt-get install qtcreator



I just read somewhere that the issue could be because I was trying to
run these examples from within Idle.


I am an IDLE maintainer.  Am I to take it that everything ran fine 
before you tried to quit?  If not, I would want to know why and try to fix.


If you run tut.py from an IDLE editor, IDLE tries to run it the same as 
if you ran it at a console in the tut.py directory with 'python3 -i 
tut.py'.  I can imagine that there might be a problem with the 
transition from gui mode to interactive shell mode, though it works for 
tkinter apps.  You said 'python3 tut.py' works.  What happens if you add 
the '-i' option?  I'd like to know if the transition problem is in 
(Py)qt5 or in IDLE's simulation of '-i'.


--
Terry Jan Reedy

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

Re: Question about math.pi is mutable

[Ben Finney]

BartC  writes:

> On 08/11/2015 21:00, Ben Finney wrote:
> > The namespace can change dynamically, which is another way of what
> > people have been trying to tell you all through this thread.
> >
> > The compiler *cannot* know what the names will be at every single
> > point they'll be looked un in the namespace dictionary. This
> > dynamism of each namespace is a Python feature.
>
> Suppose this is the python program:
>
> import m
> a=10
> b=20
> c=30
> m.f()
>
> The set of global names the compiler knows will be ("m","a","b","c").
>
> I don't believe code can remove these names (that would cause
> problems).

It may indeed cause problems. Those names can nevertheless be changed.

Names at module level are simply attributes on the module object. The
module can gain attributes, lose attributes, and its attributes can
chage; its namespace is just as mutable as any other object's namespace.

> You say the set of global names can be added to - after this lot, but
> I can't see that the first four are going to change.

You have not yet learned enough about the Python data model:

A module object has a namespace implemented by a dictionary object
(this is the dictionary referenced by the __globals__ attribute of
functions defined in the module). Attribute references are
translated to lookups in this dictionary, e.g., m.x is equivalent
to m.__dict__["x"]. A module object does not contain the code
object used to initialize the module (since it isn’t needed once
the initialization is done).

https://docs.python.org/3/reference/datamodel.html>

Any name can be deleted, just like any other reference, with the ‘del’
statement.

Any reference (including names) can be added or changed in a module
namespace like any other object's namespace.

> Attributes are harder because they are more of a free-for-all

Please understand that a module *is* an object, and a name in a module's
namespace *is* an attribute on that module.

Also, please *learn about* the way Python works; you have certainly been
here long enough to know how to look up answers in the documentation
instead of making ignorant assertions here.

-- 
 \   “What I resent is that the range of your vision should be the |
  `\ limit of my action.” —Henry James |
_o__)  |
Ben Finney

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

Re: Question about math.pi is mutable

[BartC]

On 08/11/2015 21:00, Ben Finney wrote:

BartC  writes:


I've never understood why this seems to be necessary in Python. Why do
names have to be looked up? (I'm assuming this is searching by name in
some sort of table.)


No, it is literally looking the name up as a key in a namespace
dictionary — which is just like any other Python dictionary, but
nominated internally for use as the namespace dictionary.

The distinction is important, because like any other dictionary it can
change at run-time and the bindings between name and value can change,
can be added, and can be removed.


That part is not a problem.


When a module is compiled, while the compiler can't see the
definitions inside the imported modules, it /will/ know all the names
that appear in this module, so it can organise them into fixed tables.


Not true. The namespace can change dynamically, which is another way of
what people have been trying to tell you all through this thread.

The compiler *cannot* know what the names will be at every single point
they'll be looked un in the namespace dictionary. This dynamism of each
namespace is a Python feature.


Suppose this is the python program:

import m
a=10
b=20
c=30
m.f()

The set of global names the compiler knows will be ("m","a","b","c").

I don't believe code can remove these names (that would cause problems). 
You say the set of global names can be added to - after this lot, but I 
can't see that the first four are going to change.


Therefore these names could be referred to by index.

Attributes are harder because they are more of a free-for-all, but 
suppose you do have m.f().


"m" is easy, it's entry 0 in the global table for this module, so no 
lookup-by-name is needed. You examine it, and it's a module.


It's now necessary to find f within the global table for m. This is 
where it gets tricky if you want to avoid a lookup. And I expect you 
will say that any code can randomly add names within the global table of m.


But bear with me. Suppose the interpreter were to maintain a table for 
each static (not runtime) attribute encountered in the source code. The 
compile can produce empty tables for the attributes it's seen. In this 
case the table for "f" would be empty: (). The compiler will also 
produce a list of such tables for all attributes.


Here there is only one, and the "f" table will have index 0, which is 
what can be used within the byte-code.


The hard part would be in building and maintaining that table. When 
module m is loaded, let's say it defines function "f". Now that can be 
used to create the first entry in the attribute table for "f": ($m, 
$m.f). Here, $m is some internal reference to m, and $m.f is some 
internal reference to m.f().


Now back to resolving m.f(): we know the "m" part is module $m. For "f", 
it looks through its attribute table (remember it's index 0, so instant 
access), and there is only one entry. We're lucky as that entry's owner 
matches the "m." part of this access. So we know it refers to $m.f. No 
lookups by name needed in this case.


However not all random attributes will be neatly defined somewhere as 
functions or classes that will be listed in these little tables. So 
sometimes, an actual lookup will still be needed.


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

Re: python PEP suggestion

[Terry Reedy]

On 11/6/2015 1:21 PM, Dan Strohl wrote:

All,

I wanted to run the following thought past the list as a possible PEP enhancement suggestion to 
see if it feels like something that is worth proposing.   I know it is not in the PEP format at 
this point, I can, and will, clean it up if needed, I am just trying to throw it against the 
wall at this point to see if it resonates... (or if it falls flat and goes "splat" 
).

Thoughts?


At first glance, plausible, but I am not sure needed, and it seems a bit 
contrary to how Python currently works.



New special method name to allow for more flexible object type casting/access, 
and extend type() to cast objects using this special method name.

Overview:

Have a new special method name that would allow a given objects to request 
information from another object in a given type, or to cast an object into a 
different type, and extend the built in type() function to use this.

Rationale:
There is currently __str__, __int__, and __bool__ that allow me to tell an 
object how it should reply to a request for these types of basic data types.  
However if I want to access a copy of the objet in dict form, or as a list, or 
if I am trying to convert something using json, there is no standard way of 
doing that for a custom object (I know I can do __getitem__ and/or __iter__, 
but I many processes don't try these if the object is not a subclass of dict or 
list/tuple)


Conditional execution, indexing (__index__), numeric conversions 
(__float__ also), and displaying are special cases related to syntax 
operations.  Functions that unnecessarily restrict inputs to subclasses 
of list or dict will not be solved by this.  You have left out the use 
of abstract base classes.  An iterable that can be used as a mapping can 
register itself as a mapping.  Json could check whether something is a 
sequence or mapping and iterate to get values or pairs of values.  Of 
course, the tranformation would be unidirectional.



Proposal:
What I am proposing is something like:

object.__cast__(self, to_class):
   """
   to_class: the class type that you wish to return.
   """


The excessive indents of 31 and 15 spaces make the rest of this post 
unnecessarily hard to read.


--
Terry Jan Reedy

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

Re: python PEP suggestion

[André Roberge]

On Sunday, 8 November 2015 11:35:32 UTC-4, Dan Strohl  wrote:
> All,
> 
> I wanted to run the following thought past the list as a possible PEP 
> enhancement suggestion to see if it feels like something that is worth 
> proposing.   I know it is not in the PEP format at this point, I can, and 
> will, clean it up if needed, I am just trying to throw it against the wall at 
> this point to see if it resonates... (or if it falls flat and goes "splat" 
> ).
> 
> Thoughts?
> 
> Dan Strohl
>
Snip

You might want to post this to the python-ideas list.

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

Re: [ANN] MicroPython 1.5

[Chris Angelico]

On Mon, Nov 9, 2015 at 7:53 AM, Paul Sokolovsky  wrote:
> On Sun, 8 Nov 2015 12:08:20 -0700
> paul.hermeneu...@gmail.com wrote:
>
>> What is the possibility that MicroPython could be another build from
>> the base python.org sources? Python already gets built for a variety
>> of architectures. Could a MicroPython be another one? In that way, it
>> would always be up to date on language changes.
>
> There's zero possibility for this - MicroPython is from-scratch
> implementation carefully optimized for code size and memory usage,
> that's how it's up to 50 times smaller than CPython and can run with
> ~1000 times less RAM than CPython usually runs with.

Putting this another way: MicroPython is a *different implementation*
of Python, which just happens to be in the same language as CPython. A
number of Python implementations are listed here:

https://wiki.python.org/moin/PythonImplementations

Each one is a distinct implementation of (some version of) the same
language spec called "Python", which is different from a build target
of CPython. For example, there are several implementations designed to
run inside a web browser, and while it's theoretically possible to
port some other Python implementation to JavaScript (which is what
PyPyJS did with PyPy), it's usually easier to instead implement
something specifically in/for JS (eg Brython). There's no way to say
"CPython, go build yourself for the platform known as Mozilla
Firefox", because that would be hopelessly inefficient.

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

Re: Question about math.pi is mutable

[Ben Finney]

BartC  writes:

> I've never understood why this seems to be necessary in Python. Why do
> names have to be looked up? (I'm assuming this is searching by name in
> some sort of table.)

No, it is literally looking the name up as a key in a namespace
dictionary — which is just like any other Python dictionary, but
nominated internally for use as the namespace dictionary.

The distinction is important, because like any other dictionary it can
change at run-time and the bindings between name and value can change,
can be added, and can be removed.

> When a module is compiled, while the compiler can't see the
> definitions inside the imported modules, it /will/ know all the names
> that appear in this module, so it can organise them into fixed tables.

Not true. The namespace can change dynamically, which is another way of
what people have been trying to tell you all through this thread.

The compiler *cannot* know what the names will be at every single point
they'll be looked un in the namespace dictionary. This dynamism of each
namespace is a Python feature.

-- 
 \  “It is … incumbent upon us to recognize that it is |
  `\inappropriate for religion to play any role in issues of state |
_o__)[of] a modern democracy.” —Lawrence M. Krauss, 2012-05-28 |
Ben Finney

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

Re: [ANN] MicroPython 1.5

[Paul Sokolovsky]

Hello,

On Sun, 8 Nov 2015 12:08:20 -0700
paul.hermeneu...@gmail.com wrote:

> What is the possibility that MicroPython could be another build from
> the base python.org sources? Python already gets built for a variety
> of architectures. Could a MicroPython be another one? In that way, it
> would always be up to date on language changes.

There's zero possibility for this - MicroPython is from-scratch
implementation carefully optimized for code size and memory usage,
that's how it's up to 50 times smaller than CPython and can run with
~1000 times less RAM than CPython usually runs with.

Support for the latest features is not the aim of MicroPython, instead
it's being able to use the same great language on systems where CPython
simply could never run. That necessitates being on a diet and leaving
out not just the latest lesser-known features, but even quite a few of
old more widely known ones.

That said, the core of the language is there and any Python programmer
should feel straight at home. And it's Python*3*, so it's pretty fresh
anyway, knowing that half of our community still sits on Python2 and
never tried Python3. (Hacking on MicroPython is how I get to use
Python3 myself, on my dayjob we still use Python2).

[]

-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [ANN] MicroPython 1.5

[Paul Sokolovsky]

Hello,

On Sun, 08 Nov 2015 10:28:24 -0800
Paul Rubin  wrote:

> Paul Sokolovsky  writes:
> > Recent 1.5 release is an important milestone for the project, major
> > changes including:
> 
> Thanks for posting this.  We don't hear enough about MicroPython on
> this newsgroup so it's good to get these announcements.
> 
> Is the language still Python 3.4?  Will it implement 3.5 sometime
> soon?

Yes, we already implement the most important 3.5 feature - ability to
format bytes: b"foo%s" % b"bar" ;-).

> > 1. Advanced REPL support with smart auto-indent and auto-completion
> 
> Hmm does this make the code footprint significantly bigger?

No, as everything else in MicroPython, code implementing this feature
is well-optimized, it did cost few hundreds of bytes to implement.

> > 2. Support for client SSL connections.
> 
> Nice.  Does it check the server certificate?  

The driving force for adding SSL was being able to download package
from PyPI (for builtin upip package manager). Unfortunately, PyPI forces
SSL, so previously we had to fallback to wget for downloads, which
limited upip to unix-like systems. So, the way we use SSL is as bloated
plain HTTP, just to workaround PyPI's maintainers' decision to raise
the bar too high to access it. Consequently, nobody yet worked on
certificate checking and other stuff.

> Is it based on TLSLite by any chance?

I had an idea to port TLSLite and even submitted couple of patches to
it, I had an idea to write a module titled "insecureSSL" which would
just emulate SSL by doing as little as possible processing and using
static session keys, etc. - just to prove the point that there can't be
security without both parties consenting, and mis-applied "security" is
nothing but a denial-of-service. But I gave up in the end, deciding to
take that productively and add generic SSL client support using axTLS
library (which was also optimized to meet MicroPython code size
standards).

(You see, these questions touched ranty feelings - thanks for
asking ;-) ).

> > 5. There're now 2 well-supported microcontroller boards for
> > MicroPython, and dozen(s) community-supported ones.
> 
> The PyBoard is very nice, but what is the other one?  I don't see
> anything about it on the MicroPython web site.  (Hmm, maybe you mean
> the Micro Bit).

It's WiPy, http://wipy.io/ , WiFi-enabled board which had successful
kickstarter in the spring and last month shipped ready boards. Micro
Bit would take some time before general availability of course.

> Btw, I notice that the "store" page doesn't show any products under my
> normal adblock settings.  It's probably best to make it a normal page
> instead of an AJAX one.
> 
> > MicroPython supports growing subset of Python3 standard library
> > (including simplified asyncio package)
> 
> This would look much nicer with the new Python 3.5 syntax.

There was initial patch to add initial async/await support a week within
corresponding PEP was initially posted. But we decided not to haste with
it, or we can add feature which nobody really uses (while we have bunch
of features which almost everyone would use, but which aren't yet
there). So, we decided yo do our homework, and let asyncio/async-await
people do theirs on popularizing it (every 10th Python programmer
using it seems like good target, now it's probably every 10,000th if not
100,000th).


Thanks for the feedback!

-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Question about math.pi is mutable

[Ian Kelly]

On Nov 8, 2015 12:01 PM, "BartC"  wrote:
>
> But then, you say that additional attributes, potentially millions of
different ones, can be invented at runtime. Although I don't see how it can
remove names that are part of the source code: if "A.B" is in the file,
then surely "A" and "B" always have to be present in some table or other.

Gratuitous example:

def factory(name):
class inner:
# stuff
inner.__name__ = name
return inner

One = factory('One')
Two = factory('Two')

# factory is no longer needed, so remove it from globals.
del factory
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [ANN] MicroPython 1.5

[paul . hermeneutic]

What is the possibility that MicroPython could be another build from the
base python.org sources? Python already gets built for a variety of
architectures. Could a MicroPython be another one? In that way, it would
always be up to date on language changes.

On Sun, Nov 8, 2015 at 11:28 AM, Paul Rubin  wrote:

> Paul Sokolovsky  writes:
> > Recent 1.5 release is an important milestone for the project, major
> > changes including:
>
> Thanks for posting this.  We don't hear enough about MicroPython on
> this newsgroup so it's good to get these announcements.
>
> Is the language still Python 3.4?  Will it implement 3.5 sometime soon?
>
> > 1. Advanced REPL support with smart auto-indent and auto-completion
>
> Hmm does this make the code footprint significantly bigger?
>
> > 2. Support for client SSL connections.
>
> Nice.  Does it check the server certificate?  Is it based on TLSLite by
> any chance?
>
> > 5. There're now 2 well-supported microcontroller boards for
> > MicroPython, and dozen(s) community-supported ones.
>
> The PyBoard is very nice, but what is the other one?  I don't see
> anything about it on the MicroPython web site.  (Hmm, maybe you mean the
> Micro Bit).
>
> Btw, I notice that the "store" page doesn't show any products under my
> normal adblock settings.  It's probably best to make it a normal page
> instead of an AJAX one.
>
> > MicroPython supports growing subset of Python3 standard library
> > (including simplified asyncio package)
>
> This would look much nicer with the new Python 3.5 syntax.
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Question about math.pi is mutable

[BartC]

On 08/11/2015 18:01, Chris Angelico wrote:

On Mon, Nov 9, 2015 at 4:54 AM, BartC  wrote:

That would be true for locals as well. But as far as I can tell from the
CPython source code, byte-codes uses an index to represent a local, which
represents an entry into a linear table.

I can't quite see why that can't be done for global names and for attributes
too (ie. the names that follow a ".").


At compilation time, the set of local names is locked in permanently.
That's not true of any other namespace (except nonlocals, which are
still locals, just not yours). Attributes and global names (which are
attributes of the current module) can be added and removed
dynamically, so they can't be assigned to slots; attributes can even
be simulated via __getattr__ and __getattribute__.


Yes, that's yet another way that the language design makes things 
difficult (for those who want to streamline its implementation).


For most purposes, the set of attribute names that can follow a dot are 
limited and fixed, by the occurrences of such names in a source file. So 
they can be assigned a slot.


But then, you say that additional attributes, potentially millions of 
different ones, can be invented at runtime. Although I don't see how it 
can remove names that are part of the source code: if "A.B" is in the 
file, then surely "A" and "B" always have to be present in some table or 
other.


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

Re: [ANN] MicroPython 1.5

[Paul Rubin]

Paul Sokolovsky  writes:
> Recent 1.5 release is an important milestone for the project, major
> changes including:

Thanks for posting this.  We don't hear enough about MicroPython on
this newsgroup so it's good to get these announcements.

Is the language still Python 3.4?  Will it implement 3.5 sometime soon?

> 1. Advanced REPL support with smart auto-indent and auto-completion

Hmm does this make the code footprint significantly bigger?

> 2. Support for client SSL connections.

Nice.  Does it check the server certificate?  Is it based on TLSLite by
any chance?

> 5. There're now 2 well-supported microcontroller boards for
> MicroPython, and dozen(s) community-supported ones.

The PyBoard is very nice, but what is the other one?  I don't see
anything about it on the MicroPython web site.  (Hmm, maybe you mean the
Micro Bit).

Btw, I notice that the "store" page doesn't show any products under my
normal adblock settings.  It's probably best to make it a normal page
instead of an AJAX one.

> MicroPython supports growing subset of Python3 standard library
> (including simplified asyncio package)

This would look much nicer with the new Python 3.5 syntax.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Question about math.pi is mutable

[Chris Angelico]

On Mon, Nov 9, 2015 at 4:54 AM, BartC  wrote:
> That would be true for locals as well. But as far as I can tell from the
> CPython source code, byte-codes uses an index to represent a local, which
> represents an entry into a linear table.
>
> I can't quite see why that can't be done for global names and for attributes
> too (ie. the names that follow a ".").

At compilation time, the set of local names is locked in permanently.
That's not true of any other namespace (except nonlocals, which are
still locals, just not yours). Attributes and global names (which are
attributes of the current module) can be added and removed
dynamically, so they can't be assigned to slots; attributes can even
be simulated via __getattr__ and __getattribute__.

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

Re: Question about math.pi is mutable

[BartC]

On 08/11/2015 15:59, Michael Torrie wrote:

On 11/08/2015 04:19 AM, BartC wrote:


That elegant dynamism comes at a cost: method lookup is not a constant
memory offset. Rather, it is a dictionary lookup.


I've never understood why this seems to be necessary in Python. Why do
names have to be looked up? (I'm assuming this is searching by name in
some sort of table.)

When a module is compiled, while the compiler can't see the definitions
inside the imported modules, it /will/ know all the names that appear in
this module, so it can organise them into fixed tables. Then the names
can be referred to by index. (I think LOAD_FAST does this.)

Or is eval() the culprit here by making most optimisations impossible?


Perhaps I'm misunderstanding what you're saying, here, but the reason a
lookup has to be performed is because python variables are not like C
variables. They aren't boxes per se.  They are names bound to objects.
so doing something like

a += 1

Actually assigns the name "a" to an entirely new object than the one it
had before, which, from the interpreters point of view, is in an
entirely different memory location.


That would be true for locals as well. But as far as I can tell from the 
CPython source code, byte-codes uses an index to represent a local, 
which represents an entry into a linear table.


I can't quite see why that can't be done for global names and for 
attributes too (ie. the names that follow a ".").


Attributes are a more difficult because there can be multiple instances 
of each name, and Python won't know which one is meant, so it needs to 
be resolved at each use.


So in the case of A.B(), Python apparently looks up "B" in the names 
associated with object A (and also, someone said, with the class of 
which A is an instance if the first lookup fails).


I had in mind a different approach, where a table exists for each 
different attribute, which contains an entry for each owner class. 
Usually this table will be small, or will have just one entry, so is 
quick to search.


However, another feature of Python makes that impractical: the ability 
of any instance of a class to have arbitrary sets of attributes. There 
could be millions of such instances, all named "B".


Now, if methods could only be part of a class definition, then with 
A.B() rather than A.B, there will be a limited number of classes that 
could have a method "B", so the short table idea could work.


But then, A.B could be assigned the name of a function, which is then 
called using A.B(), the same as method-calling syntax!


So it looks like Python is stuck with its name lookups.

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

Re: Puzzled

[Michael Torrie]

On 11/06/2015 02:36 PM, Robinson, Wendy wrote:
> Ah, ok I get it now.
> Thanks both!

Glad you got it!  Thanks for letting us know, too.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: how to copy PyObject * memory data to another memory address?

[Laura Creighton]

In a message of Sat, 07 Nov 2015 21:23:51 +0800, yueyoum writes:
>I'm working on a C program that has Python embedded. The host program is multi 
>processes, which communicate via shared memory (mmap). I create a Python 
>object (e.g., PyDict_New) in one process. How can I copy this data to shared 
>memory so that the other process can obtain this data and convert to Python 
>Object? 发自网易邮箱大师
>-- 
>https://mail.python.org/mailman/listinfo/python-list

It is not clear that what you want to do can be done in the general
sense.  See Alex Martelli's explanation here:
tackoverflow.com/questions/1268252/python-possible-to-share-in-memory-data-between-2-separate-processes/1269055#1269055

Any chance that instead of trying to share a PyDict you could share an
array?  If so, multiprocessing will work for you.

Or the last reference there is to some lower level inter process communication
things you can use in Python.  I have never tried them, so have no idea
how well written the code is.

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

Re: [Ubuntu] PyQt5

[Andrew Diamond]

On Sunday, November 8, 2015 at 11:22:30 AM UTC-5, Chris Angelico wrote:
> On Mon, Nov 9, 2015 at 3:03 AM, Andrew Diamond  wrote:
> > On Saturday, November 7, 2015 at 10:13:25 PM UTC-5, Andrew Diamond wrote:
> >> Hi!
> >>
> >> I'm fairly new to Python, and installed pyqt5 and began working through 
> >> the examples at http://zetcode.com/gui/pyqt5/menustoolbars/  However, 
> >> whenever I click one of the buttons or menus in the example apps I run 
> >> that is supposed to quit the application, it locks up.  This happens with 
> >> all the examples I installed that handle code to quit the app.
> >>
> >> Running Ubuntu 15.10, and installed pyqt5 via:
> >>
> >> sudo apt-get install python3-pyqt5
> >> sudo apt-get install qtcreator
> >>
> >> Thank you in advance for any assistance!
> >
> > I just read somewhere that the issue could be because I was trying to run 
> > these examples from within Idle.  However, when I try to run them from the 
> > terminal, I run into another snag:
> >
> > andrew@andrew-Satellite-P755:~/Programming/Python$ python tut8.py
> > Traceback (most recent call last):
> >   File "tut8.py", line 16, in 
> > from PyQt5.QtWidgets import QMainWindow, QAction, qApp, QApplication
> > ImportError: No module named PyQt5.QtWidgets
> >
> > ...a path issue?
> 
> If you installed "python3-pyqt5", you probably want to run "python3
> tut8.py". There are potentially two completely separate Python
> interpreters installed - version 2.7, and the latest available version
> 3.x (probably 3.4 or 3.5). You've installed a package for Python 3,
> but haven't installed the corresponding Python 2 package, so it won't
> run under the Python 2 interpreter. Compare these:
> 
> $ python --version
> $ python3 --version
> 
> I suspect that "python3 tut8.py" should work. If it doesn't, post some
> more info about your Idle installation; it might give a hint as to
> what's going on.
> 
> ChrisA

You were absolutely correct!

$ python3 tut8.py 

...worked great, thanks!!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Ubuntu] PyQt5

[Chris Angelico]

On Mon, Nov 9, 2015 at 3:03 AM, Andrew Diamond  wrote:
> On Saturday, November 7, 2015 at 10:13:25 PM UTC-5, Andrew Diamond wrote:
>> Hi!
>>
>> I'm fairly new to Python, and installed pyqt5 and began working through the 
>> examples at http://zetcode.com/gui/pyqt5/menustoolbars/  However, whenever I 
>> click one of the buttons or menus in the example apps I run that is supposed 
>> to quit the application, it locks up.  This happens with all the examples I 
>> installed that handle code to quit the app.
>>
>> Running Ubuntu 15.10, and installed pyqt5 via:
>>
>> sudo apt-get install python3-pyqt5
>> sudo apt-get install qtcreator
>>
>> Thank you in advance for any assistance!
>
> I just read somewhere that the issue could be because I was trying to run 
> these examples from within Idle.  However, when I try to run them from the 
> terminal, I run into another snag:
>
> andrew@andrew-Satellite-P755:~/Programming/Python$ python tut8.py
> Traceback (most recent call last):
>   File "tut8.py", line 16, in 
> from PyQt5.QtWidgets import QMainWindow, QAction, qApp, QApplication
> ImportError: No module named PyQt5.QtWidgets
>
> ...a path issue?

If you installed "python3-pyqt5", you probably want to run "python3
tut8.py". There are potentially two completely separate Python
interpreters installed - version 2.7, and the latest available version
3.x (probably 3.4 or 3.5). You've installed a package for Python 3,
but haven't installed the corresponding Python 2 package, so it won't
run under the Python 2 interpreter. Compare these:

$ python --version
$ python3 --version

I suspect that "python3 tut8.py" should work. If it doesn't, post some
more info about your Idle installation; it might give a hint as to
what's going on.

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

Re: how to copy PyObject * memory data to another memory address?

[Chris Angelico]

On Sun, Nov 8, 2015 at 12:23 AM, yueyoum  wrote:
> I'm working on a C program that has Python embedded. The host program is 
> multi processes, which communicate via shared memory (mmap). I create a 
> Python object (e.g., PyDict_New) in one process. How can I copy this data to 
> shared memory so that the other process can obtain this data and convert to 
> Python Object? 发自网易邮箱大师
>

The best way to do this would be to serialize it in some format - JSON
is a good choice, if all your data can fit into that format;
otherwise, consider the Pickle format. Python objects consist of lots
of references to other objects, so it's difficult to transfer them
from one to another as they are. JSON will serve you well.

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

Re: Python 3.5.0: python.exe is not a valid Windows 32 application

[Laura Creighton]

In a message of Sun, 08 Nov 2015 13:34:22 +0100, Tomáš Beňák writes:
>Hi,
>
>I have downloaded the Python 3.5.0 installer for x86 (
>https://www.python.org/ftp/python/3.5.0/python-3.5.0.exe) and have
>installed it on my Windows XP SP3. The installer run to a successful end,
>but when I try to run python.exe, it ends with an error saying that
>python.exe is not a valid Windows 32 application.
>Is this a bug? Is my Windows XP a problem? Should I try another release of
>Python? Could you provide me with the link?
>Thank you.
>
>Best regards
>Tomáš Beňák

This is an XP problem.  XP is not supported for 3.5 and later.
The latest you can run is 3.4.3
https://www.python.org/downloads/release/python-343/

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

Re: Python 3.5.0: python.exe is not a valid Windows 32 application

[Chris Angelico]

On Sun, Nov 8, 2015 at 11:34 PM, Tomáš Beňák  wrote:
> I have downloaded the Python 3.5.0 installer for x86 (
> https://www.python.org/ftp/python/3.5.0/python-3.5.0.exe) and have
> installed it on my Windows XP SP3. The installer run to a successful end,
> but when I try to run python.exe, it ends with an error saying that
> python.exe is not a valid Windows 32 application.
> Is this a bug? Is my Windows XP a problem? Should I try another release of
> Python? Could you provide me with the link?

Your Windows XP is a problem. You have a couple of options: either
upgrade to Vista/7/8/10, or downgrade your Python to 3.4, which does
support XP.

There is also a bug, which is that the installer appears to run
successfully. When Python 3.5.1 is released (currently scheduled for
early December), the installer should detect XP early on and save you
the confusion.

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

Re: [Ubuntu] PyQt5

[Andrew Diamond]

On Saturday, November 7, 2015 at 10:13:25 PM UTC-5, Andrew Diamond wrote:
> Hi!
> 
> I'm fairly new to Python, and installed pyqt5 and began working through the 
> examples at http://zetcode.com/gui/pyqt5/menustoolbars/  However, whenever I 
> click one of the buttons or menus in the example apps I run that is supposed 
> to quit the application, it locks up.  This happens with all the examples I 
> installed that handle code to quit the app.
> 
> Running Ubuntu 15.10, and installed pyqt5 via:
> 
> sudo apt-get install python3-pyqt5
> sudo apt-get install qtcreator
> 
> Thank you in advance for any assistance!

I just read somewhere that the issue could be because I was trying to run these 
examples from within Idle.  However, when I try to run them from the terminal, 
I run into another snag:

andrew@andrew-Satellite-P755:~/Programming/Python$ python tut8.py 
Traceback (most recent call last):
  File "tut8.py", line 16, in 
from PyQt5.QtWidgets import QMainWindow, QAction, qApp, QApplication
ImportError: No module named PyQt5.QtWidgets

...a path issue?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Question about math.pi is mutable

[Michael Torrie]

On 11/08/2015 04:19 AM, BartC wrote:

>> That elegant dynamism comes at a cost: method lookup is not a constant
>> memory offset. Rather, it is a dictionary lookup.
> 
> I've never understood why this seems to be necessary in Python. Why do 
> names have to be looked up? (I'm assuming this is searching by name in 
> some sort of table.)
> 
> When a module is compiled, while the compiler can't see the definitions 
> inside the imported modules, it /will/ know all the names that appear in 
> this module, so it can organise them into fixed tables. Then the names 
> can be referred to by index. (I think LOAD_FAST does this.)
> 
> Or is eval() the culprit here by making most optimisations impossible?

Perhaps I'm misunderstanding what you're saying, here, but the reason a
lookup has to be performed is because python variables are not like C
variables. They aren't boxes per se.  They are names bound to objects.
so doing something like

a += 1

Actually assigns the name "a" to an entirely new object than the one it
had before, which, from the interpreters point of view, is in an
entirely different memory location.

Whereas in C, a variable is a box that's always at the same location, so
the name is simply not important, and at runtime variables have no
names.  Python is not like this.  names are important at runtime.  There
may be certain circumstances where the Python compiler could optimize
certain types of variable access (say if the variable was bound to
integers only) into C-style variables under the hood. But I don't think
the benefit would be that great.



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

[ANN] MicroPython 1.5

[Paul Sokolovsky]

Hello,

MicroPython is a lean and efficient Python implementation for
microcontrollers, embedded, and mobile systems (which also runs just as
fine on desktops of course).

https://github.com/micropython/micropython

Recent 1.5 release is an important milestone for the project, major
changes including:

1. Advanced REPL support with smart auto-indent and auto-completion for
comfortable interactive typing pf Python code, easily switchable to
paste mode to copy pre-made code snippets.

2. Support for client SSL connections.

3. upip, MicroPython builtin package manager, is now fully standalone
thanks to SSL support.

4. There's new, elaborated API to access hardware features ("machine"
module).

5. There're now 2 well-supported microcontroller boards for
MicroPython, and dozen(s) community-supported ones.

6. MicroPython was selected as one of the languages supported for BBC
micro:bit initiative:
http://ntoll.org/article/story-micropython-on-microbit

7. There's work on native efficient JNI bridge, inspired by Kivy's
PyJNIus module, included into growing Android port.


More detailed changelog for this version is at
https://github.com/micropython/micropython/releases/tag/v1.5

MicroPython supports growing subset of Python3 standard library
(including simplified asyncio package) - not included by default with
an executable, but easily installable per-module using builtin "upip"
package manager:
https://github.com/micropython/micropython-lib


-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
-- 
https://mail.python.org/mailman/listinfo/python-list

how to copy PyObject * memory data to another memory address?

[yueyoum]

I'm working on a C program that has Python embedded. The host program is multi 
processes, which communicate via shared memory (mmap). I create a Python object 
(e.g., PyDict_New) in one process. How can I copy this data to shared memory so 
that the other process can obtain this data and convert to Python Object? 
发自网易邮箱大师
-- 
https://mail.python.org/mailman/listinfo/python-list

RE: Puzzled

[Robinson, Wendy]

Ah, ok I get it now.
Thanks both!

Wendy Robinson
Audit Analyst


-Original Message-
From: Chris Gonnerman [mailto:ch...@gonnerman.org] 
Sent: Friday, November 06, 2015 5:40 AM
To: python-list@python.org
Cc: Robinson, Wendy
Subject: Re: Puzzled

Wendy said:
> I installed Python 3.5.0 64-bit for Windows yesterday and tried some basic 
> programs successfully.
> This morning I rebooted my computer and can't get a single one to work.  The 
> interpreter seems to be fine and the environment variables look correct.  But 
> every py file I try to run at the >>> prompt gives me a NameError.
But that's not how the Python interpreter works.  You say you are trying to run 
"py files" at the >>> prompt.  If what you are doing is this:

 >>> test.py

Well, no, that's not going to work.  If you want to run "test.py" as a script, 
from the CMD prompt you type:

 python test.py

If test.py is a module meant to be imported, then from the Python prompt you do 
this:

 import test

Hope this helps.

-- Chris.

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

Python 3.5.0: python.exe is not a valid Windows 32 application

[Tomáš Beňák]

Hi,

I have downloaded the Python 3.5.0 installer for x86 (
https://www.python.org/ftp/python/3.5.0/python-3.5.0.exe) and have
installed it on my Windows XP SP3. The installer run to a successful end,
but when I try to run python.exe, it ends with an error saying that
python.exe is not a valid Windows 32 application.
Is this a bug? Is my Windows XP a problem? Should I try another release of
Python? Could you provide me with the link?
Thank you.

Best regards
Tomáš Beňák
-- 
https://mail.python.org/mailman/listinfo/python-list

RE: Script to extract text from PDF files

[Dan Strohl]

Its possible (likely) that I came into this in the middle, so sorry if this was 
already thrown out... but have you looked at any of the following suggestions?

https://pypi.python.org/pypi?%3Aaction=search&term=pdf+convert&submit=search
http://stackoverflow.com/questions/6413441/python-pdf-library
https://www.binpress.com/tutorial/manipulating-pdfs-with-python/167



-Original Message-
From: Python-list [mailto:python-list-bounces+d.strohl=f5@python.org] On 
Behalf Of Scott Werner
Sent: Friday, November 06, 2015 2:30 PM
To: python-list@python.org
Subject: Re: Script to extract text from PDF files

On Tuesday, September 25, 2007 at 1:41:56 PM UTC-4, brad wrote:
> I have a very crude Python script that extracts text from some (and I 
> emphasize some) PDF documents. On many PDF docs, I cannot extract 
> text, but this is because I'm doing something wrong. The PDF spec is 
> large and complex and there are various ways in which to store and 
> encode text. I wanted to post here and ask if anyone is interested in 
> helping make the script better which means it should accurately 
> extract text from most any pdf file... not just some.
> 
> I know the topic of reading/extracting the text from a PDF document 
> natively in Python comes up every now and then on comp.lang.python...
> I've posted about it in the past myself. After searching for other 
> solutions, I've resorted to attempting this on my own in my spare time.
> Using apps external to Python (pdftotext, etc.) is not really an 
> option for me. If someone knows of a free native Python app that does 
> this now, let me know and I'll use that instead!
> 
> So, if other more experienced programmer are interested in helping 
> make the script better, please let me know. I can host a website and 
> the latest revision and do all of the grunt work.
> 
> Thanks,
> 
> Brad

As mentioned before, extracting plain text from a PDF document can be hit or 
miss. I have tried all the following applications (free/open source) on Arch 
Linux. Note, I would execute the commands with subprocess and capture stdout or 
read plain text file created by the application.

* textract (uses pdftotext)
- https://github.com/deanmalmgren/textract

* pdftotext
- http://poppler.freedesktop.org/
- cmd: pdftotext -layout "/path/to/document.pdf" -
- cmd: pdftotext "/path/to/document.pdf" -

* Calibre
- http://calibre-ebook.com/
- cmd: ebook-convert "/path/to/document.pdf" "/path/to/plain.txt" 
--no-chapters-in-toc

* AbiWord
- http://www.abiword.org/
- cmd: abiword --to-name=fd://1 --to-TXT "/path/to/document.pdf"

* Apache Tika
- https://tika.apache.org/
- cmd: "/usr/bin/java" -jar "/path/to/standalone/tika-app-1.10.jar" --text-main 
"/path/to/document.pdf"

For my application, I saw the best results using Apache Tika. However, I do 
still encounter strange encoding or extraction issues, e.g. S P A C E D  O U T  
H E A D E R S" and "\nBroken \nHeader\n". I ended up writing a lot of 
repairing/cleaning methods.

I welcome an improved solution that has some intelligence like comparing the 
extract plain text order to a snapshot of the pdf page using OCR.
--
https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

python PEP suggestion

[Dan Strohl]

All,

I wanted to run the following thought past the list as a possible PEP 
enhancement suggestion to see if it feels like something that is worth 
proposing.   I know it is not in the PEP format at this point, I can, and will, 
clean it up if needed, I am just trying to throw it against the wall at this 
point to see if it resonates... (or if it falls flat and goes "splat" ).

Thoughts?

Dan Strohl



New special method name to allow for more flexible object type casting/access, 
and extend type() to cast objects using this special method name.

Overview:

Have a new special method name that would allow a given objects to request 
information from another object in a given type, or to cast an object into a 
different type, and extend the built in type() function to use this.

Rationale:
There is currently __str__, __int__, and __bool__ that allow me to tell an 
object how it should reply to a request for these types of basic data types.  
However if I want to access a copy of the objet in dict form, or as a list, or 
if I am trying to convert something using json, there is no standard way of 
doing that for a custom object (I know I can do __getitem__ and/or __iter__, 
but I many processes don't try these if the object is not a subclass of dict or 
list/tuple)

Proposal:
What I am proposing is something like:

object.__cast__(self, to_class):
  """
  to_class: the class type that you wish to return.
  """

   -and-

   Class type(object, to_class):
  """
  With two arguments, will attempt to cast "object" 
into "to_class" if possible.   This would be done by something like the 
following:
  (with 1 and 3 arguments, will work as currently 
designed)
  """
  Type(object, to_class):
 If isinstance(to_class, (int, str, 
bool)):
Return 
to_class(object)
 Else:
Try:
   
Return object.__cast__(to_class):
Except 
AttributeError:
   # 
yes, I know this should be more readable!
   
Raise TypeError('object x could not be converted to type y")



This allows for more customization on how a developer would want to return this 
object in various forms, and if, for example, the custom object was passed to 
something like json.dumps, it could try converting the object to something it 
recognizes first, or even try doing something like type(custom_object, json) 
and see what returned.

So, in implementation I might do something like:

def __conv__(self, to_class):
   if isinstance(to_class, (json, dict)):
  return self._data_dict
   elif isinstance(to_class, ElementTree):
  return self._get_xml_dict()
   else:
 raise TypeError('could not convert 
object to class')


This allows for developers of classes that operate on data passed to be able to 
define a process that they would use to accept unknown objects,  without having 
to worry about handling all of the different potential object types, and pass 
the responsibility for how to structure the information to the developer of the 
custom object.



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

Re: Converting a string into a float that includes the negative

[Pete Dowdell]

On 08/11/15 09:11, phamton...@gmail.com wrote:

I am having issue with converting the string into a float because there is a negative, so 
only end up with "ValueError: invalid literal for float(): 81.4]"81.4]


The error is right there in the exception: you are trying to cast 
'81.4]' - that's a square bracket in the string.
You are also  removing the negative sign from your number before casting 
with your slice


this will fix it - change line:
long1 = long[1:]
to:
long1 = long[:-1]

test:
>>> TXT="[41.3, -81.4]\t6\t2011-08-28 19:02:28\tyay. little league 
world series!"

>>> float( TXT.split('\t')[0].split(', ')[1][:-1] )
-81.4

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

Re: Question about math.pi is mutable

[Chris Angelico]

On Mon, Nov 9, 2015 at 12:42 AM, BartC  wrote:
> Sorry, you'll have to assume I'm very stupid.
>
> What exactly is being looked up, and in what?
>
> From what I can understand in your example:
>
> * You are calling shutil.copyfileobj with two arguments, which happen to be
> instances of classes Source and Dest.
>
> * Let's say these are known as src and dst inside .copyfileobj.
>
> * .copyfileobj then calls methods src.read() dst.write().
>
> * Each of these method calls has the form A.B() which seems to me to be
> little different from shutil.copyfileobj().
>
> So to get back to what I was saying, does this lookup involving searching
> for method B in object A, and if so, does it actually do a search by name?
>
> (Someone mentioned a precalculated hash, of "A", or of "src" or "dst", use
> used, but still, it's looking something up in a table, and a hash table
> lookup I believe still requires an string compare to check if you've got the
> right entry.)

The lookups I'm talking about happen pretty much anywhere. Firstly,
this function:

def f():
shutil.copyfileobj(src, dst)

looks up the global name 'shutil' (that's one dict lookup - module
globals are a dictionary), then performs an attribute lookup on the
resulting object with the name 'copyfileobj', then looks up the two
global names 'src' and 'dst'.

In fact[1], those strings can be found in f.__code__.co_names, and the
byte-code identifies them by their indices in that tuple. These are
str objects (note that this means they can be any legal Unicode
string; "шутил.цопыфилеобй(срц, дст)" is just as valid), and their
hashes will normally be precomputed to save time. Now, things are a
bit different with function-locals; the compiler always knows which
names they are, and it can compile things differently. Compare:

def f(src):
shutil.copyfileobj(src, dst)

Instead of looking up a global name 'src', this now looks up a local
name. They're identified by slot positions, so the compiler simply
knows that "src" is in slot #0, and instead of looking anything up,
simply says "load the thing in slot #0". There can also be other
levels of indirection, such as __getattr__ and __getattribute__, which
affect how stuff gets looked up. But otherwise, name lookups generally
involve poking a dict with a string and taking what comes back
(possibly replacing KeyError with NameError or AttributeError as the
case may be).

ChrisA

[1] Assuming we're using CPython, or something which uses the same
byte-code; this is NOT a language requirement - none of this is.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Question about math.pi is mutable

[Marko Rauhamaa]

BartC :

>>> On 08/11/2015 11:50, Marko Rauhamaa wrote:
 
 import shutil

 class Source:
   def __init__(self):
   self.remaining = "hello world"

   def read(self, count):
   if count <= 0:
   return ""
   chunk, self.remaining = self.remaining[:count], 
 self.remaining[count:]
   return chunk

 class Dest:
   def write(self, stuff):
   print("<{}>".format(stuff))

 shutil.copyfileobj(Source(), Dest())
 
>
> What exactly is being looked up, and in what?
>
> [...]
>
> So to get back to what I was saying, does this lookup involving
> searching for method B in object A, and if so, does it actually do a
> search by name?

Yes, finding Source.read and Dest.write involves hash table lookups. In
fact, it's even a bit more involved: each method fetch consists of *two*
hash table lookups. First you have to check if the object has a match in
its individual lookup table and next if there is a match in the class's
lookup table.


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

Re: Question about math.pi is mutable

[BartC]

On 08/11/2015 12:43, Marko Rauhamaa wrote:

BartC :


On 08/11/2015 11:50, Marko Rauhamaa wrote:


import shutil

class Source:
  def __init__(self):
  self.remaining = "hello world"

  def read(self, count):
  if count <= 0:
  return ""
  chunk, self.remaining = self.remaining[:count], self.remaining[count:]
  return chunk

class Dest:
  def write(self, stuff):
  print("<{}>".format(stuff))

shutil.copyfileobj(Source(), Dest())



OK, so here, it is necessary to resolve "copyfileobj" by seeing if
"shutil" is something that contains a name "copyfileobj" that happens
to be a method.

Is this the lookup you're talking about, and is it done using the
actual string "copyfileobj"? If so, does it need to be done every
single time this line is executed? It would extraordinarily
inefficient if that was the case.


No, what I'm talking about is that copyfileobj calls src.read() and
dst.write() without having any idea what kinds of objects src and dst
are. Thus, it will be difficult for a performance optimizer to get rid
of the dictionary lookups.


Sorry, you'll have to assume I'm very stupid.

What exactly is being looked up, and in what?

From what I can understand in your example:

* You are calling shutil.copyfileobj with two arguments, which happen to 
be instances of classes Source and Dest.


* Let's say these are known as src and dst inside .copyfileobj.

* .copyfileobj then calls methods src.read() dst.write().

* Each of these method calls has the form A.B() which seems to me to be 
little different from shutil.copyfileobj().


So to get back to what I was saying, does this lookup involving 
searching for method B in object A, and if so, does it actually do a 
search by name?


(Someone mentioned a precalculated hash, of "A", or of "src" or "dst", 
use used, but still, it's looking something up in a table, and a hash 
table lookup I believe still requires an string compare to check if 
you've got the right entry.)


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

Re: Question about math.pi is mutable

[Marko Rauhamaa]

BartC :

> On 08/11/2015 11:50, Marko Rauhamaa wrote:
>> 
>> import shutil
>>
>> class Source:
>>  def __init__(self):
>>  self.remaining = "hello world"
>>
>>  def read(self, count):
>>  if count <= 0:
>>  return ""
>>  chunk, self.remaining = self.remaining[:count], 
>> self.remaining[count:]
>>  return chunk
>>
>> class Dest:
>>  def write(self, stuff):
>>  print("<{}>".format(stuff))
>>
>> shutil.copyfileobj(Source(), Dest())
>> 
>
> OK, so here, it is necessary to resolve "copyfileobj" by seeing if
> "shutil" is something that contains a name "copyfileobj" that happens
> to be a method.
>
> Is this the lookup you're talking about, and is it done using the
> actual string "copyfileobj"? If so, does it need to be done every
> single time this line is executed? It would extraordinarily
> inefficient if that was the case.

No, what I'm talking about is that copyfileobj calls src.read() and
dst.write() without having any idea what kinds of objects src and dst
are. Thus, it will be difficult for a performance optimizer to get rid
of the dictionary lookups.


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

Re: Question about math.pi is mutable

[BartC]

On 08/11/2015 11:50, Marko Rauhamaa wrote:

BartC :


On 08/11/2015 11:02, Marko Rauhamaa wrote:

That elegant dynamism comes at a cost: method lookup is not a constant
memory offset. Rather, it is a dictionary lookup.


I've never understood why this seems to be necessary in Python. Why do
names have to be looked up? (I'm assuming this is searching by name in
some sort of table.)

When a module is compiled, while the compiler can't see the
definitions inside the imported modules, it /will/ know all the names
that appear in this module, so it can organise them into fixed tables.
Then the names can be referred to by index. (I think LOAD_FAST does
this.)


Modules are not the issue. Barely any functions are invoked from the
modules. Rather, almost all invocations are object methods. (Of course,
modules are objects, too.) Methods belong to objects that can be
literally anything.

Consider, for example,

 shutil.copyfileobj(src, dst[, length])

The shutil module has absolutely no idea what kind of objects src and
dst are. An example program:


import shutil

class Source:
 def __init__(self):
 self.remaining = "hello world"

 def read(self, count):
 if count <= 0:
 return ""
 chunk, self.remaining = self.remaining[:count], self.remaining[count:]
 return chunk

class Dest:
 def write(self, stuff):
 print("<{}>".format(stuff))

shutil.copyfileobj(Source(), Dest())



OK, so here, it is necessary to resolve "copyfileobj" by seeing if 
"shutil" is something that contains a name "copyfileobj" that happens to 
be a method.


Is this the lookup you're talking about, and is it done using the actual 
string "copyfileobj"? If so, does it need to be done every single time 
this line is executed? It would extraordinarily inefficient if that was 
the case.


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

Re: Question about math.pi is mutable

[Chris Angelico]

On Sun, Nov 8, 2015 at 10:19 PM, BartC  wrote:
> I've never understood why this seems to be necessary in Python. Why do names
> have to be looked up? (I'm assuming this is searching by name in some sort
> of table.)

Yes, if by "searching" you include hash-table lookup. A CPython
dictionary is a *highly* optimized data structure, specifically
because it's used virtually everywhere (I understand Lua's "table"
type has similar optimizations for the same reason). In the common
case, where your names come from literal text in the module, the
strings used for the lookup will be interned constants, and their
hashes will have been precalculated and stored, so the lookup is
pretty easy. So it's a constant-time operation, and while that
constant may be larger than a simple offset-and-fetch, it's still
pretty fast in the overall scheme of things.

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

Re: Question about math.pi is mutable

[BartC]

On 08/11/2015 11:30, Steven D'Aprano wrote:

On Sun, 8 Nov 2015 09:40 pm, Bartc wrote:



This is what I mean about people not understanding it!


I'm pretty sure I understand what *I* mean by constant, and what Pascal
means by it, and why the Pascal meaning doesn't quite match what Python can
do. I'm not sure I understand what *you* mean, or why you think a "variable
that won't change" isn't good enough.


I showed you what I mean. A named constant is a just a value - with a 
label. That value doesn't need to be stored in a 'box' anywhere, in 
exactly the same manner as values that can be written to (and therefore 
at risk of being overwritten).


But let me turn it around: why is it so important to use variables for 
this purpose?



In NASM terms, a named constant is like:

  daysinweek   equ   7   ; definition

  mov rax, daysinweek; using it, as immediate value
  mov rbx, daysinweek*2  ; an a 'compile-term' expression
;   mov daysinweek,8   ; can't be done! Illegal syntax


In pseudo-Python, we have:

const daysinweek = 7  # let's just pretend it exists
x = daysinweek + 1  # this is fine
daysinweek = 8  # an error

Apart from the difference between compile-time and run-time, why would this
not be satisfactory?


If that's all that's possible, that it will have to do. And might solve 
the OP's problem.


But for a true named constant, there is no actual assignment. It really 
is not necessary. 'daysinweek' is just a synonym for '7'.





While a 'const' variable, C style, might be:

[...]

Why does your C code look like assembler?


I mean the 'const' is C style. The assembly code is to highlight the 
difference between what C calls a const, and what I call a named constant.



I am not interested in the limitations of low-level machine languages. They
have very little to say about what Python can or should do.


OK, let's take a higher level one:

 const a = 2
 var   b = 3

 c = a+b

which might generate a byte-code like this:

  push_ci   2
  push_m[b]
  add
  pop_m [c]

Now apply this to Python byte-code. Can you not see the advantage of not 
having to deal with variable names, reference counts, garbage collection 
and all that?


I don't know what you had in mind for implementing the pretend 'const' 
in your Python example above. But if it takes the form of an extra 
runtime attribute, then all variable accesses will be slowed then if it 
is has to be checked for every assignment, and 'const' names won't be 
any faster.



In the language however, you will not be able to use the named constant
as an lvalue, and you will usually be able to use it for compile-time
constant folding and for dimensioning fixed-bound arrays and such.)


We're talking about Python, and how the concept of "const" might apply to a
Python-like language. Compile-time constant folding is not part of it,
because the constant itself might not exist at compile-time:

const START = time.time()


You're thinking in C terms again. The C 'const' really means 'read-only' 
and applies to ordinary variables. It has nothing to do with my named 
constants which are always known at compile-time


(That's if the definitions are visible. If not, then they will be known 
at the time the module they're in is compiled. Linking these is one of 
the problems in a Python implementation.)



Fixed-bound arrays are irrelevant (neither lists nor arrays are
fixed-bounds; tuples are, but they are constructed at runtime, not compile
time).


Think of a possible 'switch' statement then, and the values for its case 
labels.



Python has such a "more elaborate way" of executing source code:


exec("""
if condition:
 import time
 const START = time.time()
 x = START + 1
""")


(1) That is not a const but a variable with a read-only attribute. The 
expression after the "=" should itself be a constant expression or a 
literal value. (No reason why Python shouldn't have such an attribute, 
but that's different from what I'm talking about.)


(2) I assume that the contents of the string passed to exec() are first 
compiled to byte-code. Then that's the same as a normal compile, with 
the same problems of visibility and imparting its constant definitions 
to code that is compiled separately. (If the use 'exec' is more subtle, 
then we might as well give up!)


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

Re: Question about math.pi is mutable

[Marko Rauhamaa]

BartC :

> On 08/11/2015 11:02, Marko Rauhamaa wrote:
>> That elegant dynamism comes at a cost: method lookup is not a constant
>> memory offset. Rather, it is a dictionary lookup.
>
> I've never understood why this seems to be necessary in Python. Why do
> names have to be looked up? (I'm assuming this is searching by name in
> some sort of table.)
>
> When a module is compiled, while the compiler can't see the
> definitions inside the imported modules, it /will/ know all the names
> that appear in this module, so it can organise them into fixed tables.
> Then the names can be referred to by index. (I think LOAD_FAST does
> this.)

Modules are not the issue. Barely any functions are invoked from the
modules. Rather, almost all invocations are object methods. (Of course,
modules are objects, too.) Methods belong to objects that can be
literally anything.

Consider, for example,

shutil.copyfileobj(src, dst[, length])

The shutil module has absolutely no idea what kind of objects src and
dst are. An example program:


import shutil

class Source:
def __init__(self):
self.remaining = "hello world"

def read(self, count):
if count <= 0:
return ""
chunk, self.remaining = self.remaining[:count], self.remaining[count:]
return chunk

class Dest:
def write(self, stuff):
print("<{}>".format(stuff))

shutil.copyfileobj(Source(), Dest())



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

Re: Question about math.pi is mutable

[Steven D'Aprano]

On Sun, 8 Nov 2015 09:40 pm, Bartc wrote:

> On 08/11/2015 02:59, Steven D'Aprano wrote:
>> On Sun, 8 Nov 2015 02:01 am, Bartc wrote:
>>
>>> Neither have the simplicity of concept of Pascal's 'const', which is
>>> just a named value. Not a variable that won't change once initialised,
>>> not a parameter that won't be changed nor any addressable location.)
>>
>> Unfortunately the concept of "named value" doesn't match well with
>> Python's design. That implies a separate compilation step which doesn't
>> fit well with Python's runtime semantics. Very little happens at
>> compile-time in Python that *must* happen at compile-time.
>>
>> I'm also not sure what difference you think there is between "named
>> value" and "variable that won't change once initialised".
> 
> This is what I mean about people not understanding it!

I'm pretty sure I understand what *I* mean by constant, and what Pascal
means by it, and why the Pascal meaning doesn't quite match what Python can
do. I'm not sure I understand what *you* mean, or why you think a "variable
that won't change" isn't good enough.


> In NASM terms, a named constant is like:
> 
>  daysinweek   equ   7   ; definition
> 
>  mov rax, daysinweek; using it, as immediate value
>  mov rbx, daysinweek*2  ; an a 'compile-term' expression
> ;   mov daysinweek,8   ; can't be done! Illegal syntax

In pseudo-Python, we have:

const daysinweek = 7  # let's just pretend it exists
x = daysinweek + 1  # this is fine
daysinweek = 8  # an error

Apart from the difference between compile-time and run-time, why would this
not be satisfactory?

Oh, and just to satisfy Ben, the determined monkey-patcher can write:

globals()['daysinweek'] = 8

if they really want to defeat the compiler. The idea is to avoid
*accidental* bindings.



> While a 'const' variable, C style, might be:
[...]

Why does your C code look like assembler?


> So in native code, a named value is not much different to a literal such
> as 7, or 3.14159. (But unlike C's #define, the name is a proper symbol
> with normal scope rules, and a type).
> 
> The distinction at the machine level can be blurred with some
> instructions sets where there might not be an immediate data option for
> some data widths or types. Also where named constants are applied to
> things such as strings, which necessarily use storage.

I am not interested in the limitations of low-level machine languages. They
have very little to say about what Python can or should do.


> In the language however, you will not be able to use the named constant
> as an lvalue, and you will usually be able to use it for compile-time
> constant folding and for dimensioning fixed-bound arrays and such.)

We're talking about Python, and how the concept of "const" might apply to a
Python-like language. Compile-time constant folding is not part of it,
because the constant itself might not exist at compile-time:

const START = time.time()

Fixed-bound arrays are irrelevant (neither lists nor arrays are
fixed-bounds; tuples are, but they are constructed at runtime, not compile
time). 


>> Python has a convention for "constants" -- all UPPERCASE names. The fact
>> that the convention exists is enough to prove that the concept
>> of "constant" is a useful one. The difference between Python's
>> pseudo-constants and (say) Pascal's actual constants is that in Python,
>> the burden of ensuring that neither you, nor any of the libraries you
>> call, modifies the "constant" falls on you, the user, whereas in Pascal
>> the compiler or interpreter performs that checking for you.
> 
> With a real named constant the check can always be done at compile-time.
> Unless you have a pure interpreter or some more elaborate way of
> executing source code.

Python has such a "more elaborate way" of executing source code:


exec("""
if condition:
import time
const START = time.time()
x = START + 1
""")




-- 
Steven

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

Re: Question about math.pi is mutable

[Marko Rauhamaa]

Steven D'Aprano :

> So... you have no need for Python to be fast, and even less need for
> Python code to be correct...

Correct. If I didn't think so, I'd still be using Java instead of
Python.

> Or perhaps you mean that you don't need help writing correct code,
> because your code is perfect...

Python's noise-free syntax does more for code quality than compile-time
type checking.


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

Re: Question about math.pi is mutable

[BartC]

On 08/11/2015 11:02, Marko Rauhamaa wrote:

Bartc :


(In the case of Python, the main obstacle is that a constant name from
inside an imported module is not visible when this module is compiled
to byte-code. So it has to assume it can be anything.)


Which it can.



That elegant dynamism comes at a cost: method lookup is not a constant
memory offset. Rather, it is a dictionary lookup.


I've never understood why this seems to be necessary in Python. Why do 
names have to be looked up? (I'm assuming this is searching by name in 
some sort of table.)


When a module is compiled, while the compiler can't see the definitions 
inside the imported modules, it /will/ know all the names that appear in 
this module, so it can organise them into fixed tables. Then the names 
can be referred to by index. (I think LOAD_FAST does this.)


Or is eval() the culprit here by making most optimisations impossible?

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

Re: Question about math.pi is mutable

[Steven D'Aprano]

On Sun, 8 Nov 2015 08:44 pm, Marko Rauhamaa wrote:

> Steven D'Aprano :
> 
>> On Sun, 8 Nov 2015 01:23 am, Marko Rauhamaa wrote:
>>> Correct. That's not Python's fault, however. Python should not try to
>>> placate the performance computing people. (Alas, it is now trying to
>>> do just that with the introduction of static typing annotation.)
>>
>> That is factually incorrect.
>>
>> The motive behind the introduction of typing annotations is not "speed",
>> but "correctness".
> 
> Oh, then I'm even more disappointed with type annotation.


/me does a double-take


Wait a minute, you've just spent a bunch of paragraphs explaining that
Python is plenty fast enough (for you), that you don't need it to be
faster. Okay. Now you're saying that you're *even more* disappointed that
type annotations will be used to make code *more correct* and *less buggy*.

So... you have no need for Python to be fast, and even less need for Python
code to be correct...

Or perhaps you mean that you don't need help writing correct code, because
your code is perfect...

It is moments like this I wonder if you are trolling.


-- 
Steven

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

Re: time module

[Marko Rauhamaa]

input/ldompel...@casema.nl:

> Yes, I would like seconds since start of program.
> Can I not doing something like time()=0 only this gives an error.

Here:

class MyReckoning:
def __init__(self):
self.the_beginning = time.time()

def time(self):
return time.time() - self.the_beginning

reckoning = MyReckoning()
print(reckoning.time())


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

Re: Question about math.pi is mutable

[BartC]

On 08/11/2015 03:50, Steven D'Aprano wrote:

On Sun, 8 Nov 2015 01:23 am, Marko Rauhamaa wrote:



Your point of view is really down-to-earth. It's slightly analogous to
protesting against Unicode because you only ever need ASCII.


I don't think so, but in any case, Bart is *way* oversimplifying the
potential optimizations available. Function inlining depends on the
function being small enough that inlining it does more good than harm, but
it doesn't require that f never changes.


I didn't really have function in-lining in mind (although once you are 
sure a specific function will always be called, that is a possibility 
for the compiler).


There are plenty of optimisations available if you know you are calling 
a function, and the compiler can 'see' the source code:


* You don't need to check that 'f' in 'f(a,b,c)' is a function; it will be.

* You will know whether the number of arguments provided is correct or 
not, and make adjustments at compile-time if not


* Where keyword parameters are used, this can also all be sorted out at 
compile-time, rather than at runtime


* (And does Python still need to do a lookup for the name 'f'? I don't 
know; the CPython sources are hard to follow. But in my interpreters, 
this is never necessary at runtime.)


However, most functions will not be visible to the compiler because they 
are in imported modules. A certain amount of work can be done when a 
module is loaded, but this now starts to get complicated.



Even such simple things as constant folding are slightly controversial! If
you go back to older versions of Python, code like this:

 x = 1 + 1

actually performed the addition at runtime, instead of being compiled to:

 x = 2

Believe it or not, even something as simple as that remains controversial,


Actually, it's not so simple! If floating point expressions are 
involved, the results can be different between compiler and runtime, if 
the compilation is done on a separate machine. But this is only a 
problem is byte-code is distributed rather than sources.


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

Re: Question about math.pi is mutable

[Marko Rauhamaa]

Bartc :

> (In the case of Python, the main obstacle is that a constant name from
> inside an imported module is not visible when this module is compiled
> to byte-code. So it has to assume it can be anything.)

Which it can.

Optimizing for naive floating-point constants could be done but has
barely any significance in most Python code. Numeric computations are
carried out in separate native plugins.

Most Python code deals with encapsulated objects whose innards are
hidden and whose only semantics are defined by the access methods. New
implementations or derived objects can be plugged in transparently.

A case in point are the so-called file-like objects. They are a simple,
elegant concept. I can come up with new file-like objects without any
common pedigree with some predefined classes and incorporate them with a
lot of utility classes.

That elegant dynamism comes at a cost: method lookup is not a constant
memory offset. Rather, it is a dictionary lookup.


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

Re: Question about math.pi is mutable

[Bartc]

On 08/11/2015 02:59, Steven D'Aprano wrote:

On Sun, 8 Nov 2015 02:01 am, Bartc wrote:


Neither have the simplicity of concept of Pascal's 'const', which is
just a named value. Not a variable that won't change once initialised,
not a parameter that won't be changed nor any addressable location.)


Unfortunately the concept of "named value" doesn't match well with Python's
design. That implies a separate compilation step which doesn't fit well
with Python's runtime semantics. Very little happens at compile-time in
Python that *must* happen at compile-time.

I'm also not sure what difference you think there is between "named value"
and "variable that won't change once initialised".


This is what I mean about people not understanding it!

In NASM terms, a named constant is like:

daysinweek   equ   7   ; definition

mov rax, daysinweek; using it, as immediate value
mov rbx, daysinweek*2  ; an a 'compile-term' expression
;   mov daysinweek,8   ; can't be done! Illegal syntax

While a 'const' variable, C style, might be:

segment .rodata
monthsinyear:  ; definition
dd 12

mov rax,[monthsinyear] ; using it, as memory access
;   mov rbx,[monthsinyear*10]  ; can't be done!
mov [monthsinyear],6   ; can be done, but might give memory
   ; access errors if actually stored in
   ; protected memory. Usually in C,
   ; it isn't

So in native code, a named value is not much different to a literal such 
as 7, or 3.14159. (But unlike C's #define, the name is a proper symbol 
with normal scope rules, and a type).


The distinction at the machine level can be blurred with some 
instructions sets where there might not be an immediate data option for 
some data widths or types. Also where named constants are applied to 
things such as strings, which necessarily use storage.


In the language however, you will not be able to use the named constant 
as an lvalue, and you will usually be able to use it for compile-time 
constant folding and for dimensioning fixed-bound arrays and such.)



Python has a convention for "constants" -- all UPPERCASE names. The fact
that the convention exists is enough to prove that the concept
of "constant" is a useful one. The difference between Python's
pseudo-constants and (say) Pascal's actual constants is that in Python, the
burden of ensuring that neither you, nor any of the libraries you call,
modifies the "constant" falls on you, the user, whereas in Pascal the
compiler or interpreter performs that checking for you.


With a real named constant the check can always be done at compile-time. 
Unless you have a pure interpreter or some more elaborate way of 
executing source code.


(In the case of Python, the main obstacle is that a constant name from 
inside an imported module is not visible when this module is compiled to 
byte-code. So it has to assume it can be anything.)


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

Re: Is there an archive of the gohlke python binaries on windows

[Laura Creighton]

In a message of Sat, 07 Nov 2015 21:55:32 -0800, Sayth Renshaw writes:
>Just wondering if there is an archive mirror for these binaries available. i 
>was looking for lxml 3.4.1 and the current version is the latest on the page 
>at 3.4.4 being on windows I cannot build it.
>
>http://www.lfd.uci.edu/~gohlke/pythonlibs/
>
>Thanks
>
>Sayth

https://pypi.python.org/pypi/lxml/3.4.1

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

Re: time module

[input/ldompeling]

>  Ambiguous requirement: any normal counter starts from zero... But what
> "zero" represents may differ... Seconds since Jan 1 1970? Seconds since
> midnight? Seconds since start of program?

Thanks for the reply

Yes, I would like seconds since start of program.
Can I not doing something like time()=0 only this gives an error.

Thanks

In reply to "Dennis Lee Bieber" who wrote the following:

> On Sat, 07 Nov 2015 21:27:06 GMT, input/ldompel...@casema.nl declaimed the
> following:
> 
> > hi,
> > 
> > I like to have a function that prints time in seconds.
> > I am looking for something for example that seconds count from zero.
> > I search the internet for time module in python but could not found anathing
> > usefull.
> > 
> 
>  Ambiguous requirement: any normal counter starts from zero... But what
> "zero" represents may differ... Seconds since Jan 1 1970? Seconds since
> midnight? Seconds since start of program?
> 
> > > > import time
> > > > t0 = time.time()
> > > > t0
> 1446941608.052
> > > > t0 / 60.0
> 24115693.46755
> > > > t0 / 60.0 / 60.0
> 401928.2244593
> > > > t0 / 60.0 / 60.0 / 24.0
> 16747.009352453704
> > > > t0 / 60.0 / 60.0 / 24.0 / 365.25
> 45.850812737724034
> > > > 
> 
>  Almost 46 years worth of seconds.
> 
> > > > tStart = time.time()
> > > > for x in range(10):
> ...  time.sleep(x)
> ...  print time.time() - tStart
> ...  
> 36.502935
> 37.5040001869
> 39.509629
> 42.509905
> 46.5170001984
> 51.519534
> 57.522193
> 64.5210001469
> 72.523019
> 81.523019
> > > > 
> 
> Okay, I'm not the fastest typist (35 seconds from tStart to finishing the
> loop code)
> --
>  Wulfraed Dennis Lee Bieber AF6VN
> wlfr...@ix.netcom.comHTTP://wlfraed.home.netcom.com/




-- 
- --- -- -
Posted with NewsLeecher v7.0 Beta 2
Web @ http://www.newsleecher.com/?usenet
--- -  -- -

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

Re: Is there an archive of the gohlke python binaries on windows

[Sayth Renshaw]

On Sunday, 8 November 2015 20:44:02 UTC+11, Chris Warrick  wrote:
> On 8 November 2015 at 06:55, Sayth Renshaw  wrote:
> > Just wondering if there is an archive mirror for these binaries available. 
> > i was looking for lxml 3.4.1 and the current version is the latest on the 
> > page at 3.4.4 being on windows I cannot build it.
> >
> > http://www.lfd.uci.edu/~gohlke/pythonlibs/
> >
> > Thanks
> >
> > Sayth
> > --
> > https://mail.python.org/mailman/listinfo/python-list
> 
> Why do you need an old version? There should be no reason to use an
> old version...  Why can't you use lxml 3.4.4?
> 
> If you are a fan of old software, you are probably on Python 2.x, too,
> and you can get a binary from here:
> https://pypi.python.org/pypi/lxml/3.4.1
> 
> Also, those binaries are built by someone USING Windows. You can
> certainly build C extensions, if you install Visual Studio in the
> correct version.
> 
> -- 
> Chris Warrick 
> PGP: 5EAAEA16

I want to use lxml 3.4.1 because it is the required version in portia current 
version

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

Re: [Ubuntu] PyQt5

[Laura Creighton]

In a message of Sun, 08 Nov 2015 06:36:26 +0100, Vincent Vande Vyvre writes:
>Le 08/11/2015 04:13, Andrew Diamond a écrit :
>> Hi!
>>
>> I'm fairly new to Python, and installed pyqt5 and began working through the 
>> examples at http://zetcode.com/gui/pyqt5/menustoolbars/  However, whenever I 
>> click one of the buttons or menus in the example apps I run that is supposed 
>> to quit the application, it locks up.  This happens with all the examples I 
>> installed that handle code to quit the app.
>>
>> Running Ubuntu 15.10, and installed pyqt5 via:
>>
>> sudo apt-get install python3-pyqt5
>> sudo apt-get install qtcreator
>>
>> Thank you in advance for any assistance!
>Works fine for me on 15.04.
>
>I've tested the first example with the menuBar.
>
>Have you a message into the terminal? Maybe an error?
>
>Vincent

A suggestion:

When I get the 'it locks up when I want to quit' behaviour
in PyQt4 it is because I have messed up something with my threading.
PyQt4 wants there to be one, main control thread (that handles, among
other things, shutting down) and lots of worker threads which do the
gui-stuff, i.e. all the work that the program really needs to do.

If you manage to structure things so that your control ends up in
a worker thread, then when it is told to quit, your app sits around
and waits for the main control thread to come back and deal with things,
but your main control thread is dead, and therefore isn't coming.

I assume you can get problems like this with Qt5 as well.

Did quitting work properly with the earlier exercises of this tutorial,
or did you try to start learning from the middle?

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

Re: Question about math.pi is mutable

[Marko Rauhamaa]

Paul Rubin :

> Marko Rauhamaa  writes:
>> Point is, the consequences of "proper" use of const are so annoying even
>> standard library functions would rather grossly abuse it than tolerate
>> compiler warnings everywhere.
>
> I'm not sure what the C standard says about that example, but C++ is
> much stricter about those conversions, [...]

C++ gets const even more wrong than C, and const is the least of C++'s
problems.


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

Re: Question about math.pi is mutable

[Marko Rauhamaa]

Steven D'Aprano :

> On Sun, 8 Nov 2015 01:23 am, Marko Rauhamaa wrote:
>> Correct. That's not Python's fault, however. Python should not try to
>> placate the performance computing people. (Alas, it is now trying to
>> do just that with the introduction of static typing annotation.)
>
> That is factually incorrect.
>
> The motive behind the introduction of typing annotations is not "speed",
> but "correctness".

Oh, then I'm even more disappointed with type annotation.


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

Re: Is there an archive of the gohlke python binaries on windows

[Chris Warrick]

On 8 November 2015 at 06:55, Sayth Renshaw  wrote:
> Just wondering if there is an archive mirror for these binaries available. i 
> was looking for lxml 3.4.1 and the current version is the latest on the page 
> at 3.4.4 being on windows I cannot build it.
>
> http://www.lfd.uci.edu/~gohlke/pythonlibs/
>
> Thanks
>
> Sayth
> --
> https://mail.python.org/mailman/listinfo/python-list

Why do you need an old version? There should be no reason to use an
old version…  Why can’t you use lxml 3.4.4?

If you are a fan of old software, you are probably on Python 2.x, too,
and you can get a binary from here:
https://pypi.python.org/pypi/lxml/3.4.1

Also, those binaries are built by someone USING Windows. You can
certainly build C extensions, if you install Visual Studio in the
correct version.

-- 
Chris Warrick 
PGP: 5EAAEA16
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Guide in Deskop Application Development in Python for newbies

[Chris Warrick]

On 7 November 2015 at 15:44,   wrote:
> How do you start building a desktop application in python? I mean where do I 
> start? Besides installing python on your windows what else do I need, and any 
> suggestion on how do I accomplish this project.
>
> Right now I really want to finish this beauty pageant judging system which 
> requires to have a client and a server, client would be for the judges and a 
> server that computes the scores from all the categories, (i do hope you get I 
> want mean by that project). I just finished reading Headfirst Python and I 
> really loving this language, so any help from all the great programmers here 
> would be so great.
> --
> https://mail.python.org/mailman/listinfo/python-list

This project requires two very different components, or one monolithic server.

The first one is the server. It basically needs to talk to clients
(via HTTP) and to a database. This is a trivial app to write in your
favorite web framework, eg. Django [0]. Come up with a good database
structure (read the excellent tutorial and documentation, should get
you there), write some models. But you can’t write your views just
yet. Because the views you write depend strictly on the client.

For the client, you basically have two choices:
(a) write a web application in Django;
(b) use a GUI framework and make a standalone desktop application.

If you choose option (a), you need to learn HTML/CSS and write the
views for your Django application (or use a ready-made front-end
framework, eg. Bootstrap [1]). This is the simplest choice, and it
takes a lot of work away from you. Your users will use their favorite
web browser to access the voting system, log in, and make their votes,
and there is no special setup for them (apart from giving them
credentials to access your app). Your Django views will use the
built-in Django templating, forms, and is relatively simple to do
(might even be doable in a weekend).

Route (b) is much more complicated. To follow this route, you need to
pick a GUI framework. There are also multiple options, I personally
recommend PySide, but you could also try wxWidgets, pygobject or kivy.
The web app side of things will require serializing data to JSON and
writing a RESTful API, but there are ready-made solutions for many web
frameworks [2].
But most of those come with a catch: they usually make you produce
ugly code, because they are wrappers around ugly C++ APIs. And then
you need to write code to talk to your HTTP server. You can’t use the
beautiful requests library, because it will block — so there’s more
work ahead, unless you want your app to be unresponsive every time you
talk to the server. For example, in Qt, you would need to use Qt
networking capabilities (which work asynchronously within the event
loop), or some other implementation that you can use asynchronously
(eg. Twisted, but then you lock yourself to Python 2, which is bad, or
threading, which has its limitations…)
And then you need to distribute your app to your users. Which is
already hard, because you need to coordinate Python, your GUI
framework, and your app. Are your users on Windows, Linux, or OS X? If
you have at least one person on a platform, you will need some sort of
testing environment…

And no matter which route you choose, you can’t do much without a
Linux server, so there’s more learning to do.

Sadly, developing big things is hard and requires a lot of knowledge —
especially if you’re a one-man-band.
Here’s a short list of skills you need, with a subjectively suggested
implementation and ease of implementation:

* understanding of the HTTP protocol (*)
* web application development (Django *)
* database schema writing (planning out the structure + Django ORM **)
* app server setup (uWSGI + nginx + Linux ***)
* database setup (PostgreSQL *** or something simpler[3])
* Route A:
  * HTML/CSS skills; a front-end framework (Bootstrap **)
* Route B:
  * RESTful APIs (Django REST Framework ***/* if you use OAuth)
  * GUI framework (PyQt )
  * talking to your server from within the framework (/*)

[0]: https://www.djangoproject.com/
[1]: http://getbootstrap.com/
[2]: http://www.django-rest-framework.org/
[3]: If this is going to be VERY small, you could go with a sqlite
database, which requires zero setup, but which is not suited for
anything more serious.

Other learning materials:

https://uwsgi-docs.readthedocs.org/en/latest/tutorials/Django_and_nginx.html
http://www.fullstackpython.com/
http://deploypython.com/

On 8 November 2015 at 02:50, Michael Torrie  wrote:
> On 11/07/2015 12:15 PM, paul.hermeneu...@gmail.com wrote:
>> Where would you say that web2py  fits into this mix
>> of tools?
>
> I am not familiar with it but I know it's supposed to be a lightweight
> framework for developing web-based sites and applications.  Could be an
> excellent tool for the OP to use to build his user interface.
>
> --
> https://mail.python.org/mailman/listinfo/python-list

w

Re: Problems connecting to PostgreSQL

[Chris Warrick]

On 8 November 2015 at 00:40, Cecil Westerhof  wrote:
> I followed http://zetcode.com/db/postgresqlpythontutorial/.
>
> I used:
> sudo -u postgres createuser stressTest
> this create the role, but also gave:
> could not change directory to "/root": Permission denied
> and I did not get the questions.

This is not an error, just a warning — and it comes from sudo,
postgres doesn’t care. To silence it, you need to work from a
different directory than /root.  The commands actually worked just
fine.

> Then I used:
> sudo -u postgres createdb stressTest -O stressTest
> This gave also:
> could not change directory to "/root": Permission denied
>
> The database is created, but when I execute:
> conn = psycopg2.connect(database = postgres_database, user = 'stressTest')
> I get:
> psycopg2.OperationalError: FATAL:  Peer authentication failed for user 
> "stressTest"
>
> What do I need to do to get things working?

You need to configure your PostgreSQL database to use md5
authentication, and set a password for your user.

# cd /
# sudo -u postgres psql
postgres=# ALTER ROLE stressTest WITH PASSWORD 'swordfish';
postgres=# \q
# vim /var/lib/postgres/data/pg_hba.conf

Change host settings to look like this:
# IPv4 local connections:
hostall all 127.0.0.1/32md5
# IPv6 local connections:
hostall all ::1/128 md5

Then you can connect using:

conn = psycopg2.connect(database='stressTest', user='stressTest',
password='swordfish', host='localhost')

Documentation:
http://www.postgresql.org/docs/current/static/auth-pg-hba-conf.html
http://www.postgresql.org/docs/current/static/auth-methods.html
http://www.postgresql.org/docs/current/static/sql-alterrole.html

(basically, the default peer authentication checks your Unix user name
to see if it matches 'stressTest', and fails)

-- 
Chris Warrick 
PGP: 5EAAEA16
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Question about math.pi is mutable

[Paul Rubin]

Marko Rauhamaa  writes:
> Point is, the consequences of "proper" use of const are so annoying even
> standard library functions would rather grossly abuse it than tolerate
> compiler warnings everywhere.

I'm not sure what the C standard says about that example, but C++ is
much stricter about those conversions, and g++ does flag an error if
you compile that code with it.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Question about math.pi is mutable

[Christian Gollwitzer]

Am 08.11.15 um 08:45 schrieb Marko Rauhamaa:

Grant Edwards :


On 2015-11-07, Marko Rauhamaa  wrote:

"const" is a very ineffective tool that clutters the code and forces
you to sprinkle type casts around your code.


But it allows the compiler to warn you if you pass a pointer to a
read-only data to a function that expects a pointer to writable data.


Unfortunately, it doesn't:


#include 
#include 

int main()
{
 const char name[] = "Tom";
 char *p = strstr(name, "Tom");
 strcpy(p, "Bob");
 printf("name = %s\n", name);
 return 0;
}


 $ cc -o prog prog.c
 $ ./prog
 Bob

No warning.



That is strange. In C, I can see thet problem here, because it is 
impossible to define a const correct strstr. But in C++ I have expected 
that according to the overload, the const version of strstr would be 
selected (http://www.cplusplus.com/reference/cstring/strstr/ ) . Still:


apfelkiste:Tests chris$ cat prog.cpp
#include 
#include 

int main()
{
const char name[] = "Tom";
char *p = strstr(name, "Tom"); // this line should be an error
strcpy(p, "Bob");
printf("name = %s\n", name);
return 0;
}

apfelkiste:Tests chris$ g++ -Wall prog.cpp
apfelkiste:Tests chris$ ./a.out
Bus error: 10

It segfaults because on OSX, const can be stored in write-only memory.

apfelkiste:Tests chris$ g++ --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr 
--with-gxx-include-dir=/usr/include/c++/4.2.1

Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin12.6.0
Thread model: posix


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