Re: User Interface Suggestions? (newbie)

[Brendan Abel]

You should look into using PyQt or PySide.  They are python bindings for
the very popular Qt GUI framework.



On Wed, Oct 5, 2016 at 2:33 PM, Beverly Howard  wrote:

> >> if it is a pi controlling the system I would tend towards controlling it
> from a web page via the network. to keep it updating would require AJAX
> style programming of the web page. <<
>
> Thanks.  I am interested in eventually doing that, but it seems that
> learning how to do it on a local console first would be to my advantage...
> especially during initial testing stages.
>
> fwiw, this project is to transfer (actually re-create) a basic program
> that I wrote for a Tandy Model 100 portable back in the early 80's to
> control ceramic kilns which get to over 2,000 degrees F.
>
> Worked perfectly until a few years ago when there were no longer any Tandy
> Model 100s available at any cost ;-)  (In case anyone is interested in
> fossilized projects, see http://bevhoward.com/kiln/KilnCtrl.htm)
>
> Thanks again for the response and pointers,
> Beverly Howard
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Passing Variable to Function

[Brendan Abel]

Define your colors as actual number variables instead of a string

color = (255,0,0)
color2 = (0,0,255)

Then use argument expansion to pass them in as separate arguments to the
function

colorFunction(*color)

Brendan

On Wed, Oct 5, 2016 at 12:17 PM, John McKenzie 
wrote:

>
>  Hello, all.
>
>  I have a function that takes three arguments, arguments to express an RGB
> colour. The function controls an LED light strip (a Blinkytape).
>
>  Sometimes I might need to be change what colour is sent to the function,
> so I set a variable with the idea that I can change just the variable
> later if I need to instead of changing a bunch of different lines.
>
> So I have variables along the lines of this:
>
> colour ="255, 0, 0"
> colour2 ="100, 0, 0"
>
>
> My function, written by the Blinkytape people:
>
>
> def changeColor(r, g, b):
>  serialPorts = glob.glob("/dev/ttyACM0*")
>  port = serialPorts[0]
>
>  if not port:
>  sys.exit("Could not locate a BlinkyTape.")
>
>  print "BlinkyTape found at: %s" % port
>
>  bt = BlinkyTape.BlinkyTape(port)
>  bt.displayColor(r, g, b)
>  time.sleep(.1)  # Give the serial driver some time to actually send
> the data
>  bt.close()
>
>
>  Later, I have conditional statements like:
>
>
> if latitude > maxNetural and latitude < NorthLine:
> changeColor(colour)
> elif latitude > NorthLine:
> changeColor(colour2)
>
>
>
> (There is a GPS device connected, there are variables defined based on
> latitude earlier in the script.)
>
>  I get an error stating that changeColor takes three arguments and I am
> just giving it one (either "colour1" or "colour2").
>
>
>  Is there a way to format the "colour" variable so that the changeColor
> function takes it as the three numbers it is meant to be defined as?
>
>
> Entire script:
> http://hastebin.com/qaqotusozo.py
>
>
>  Thanks.
>
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: unintuitive for-loop behavior

[Brendan Abel]

> a = 1
if condition:
print(a)  # UnboundLocalError: local 'a' referenced before assignment
a += 1


For-loops are no different. Making them their own namespace is a very
strange thing to do, it would mean you couldn't re-bind a value inside a
for-loop:

count = 0
for x in sequence:
count += 1
# raises UnboundLocalError: local 'count' referenced before assignment

--

That's generally not how nested scopes work, you could still reference
objects in the outer scope from the inner scope, but the outer scope
couldn't reference objects in the inner scope

a = 1
if condition:
b = a + 2

print b # UnboundLocalError: local 'b' referenced before assignment


for x in sequence:
print x

print x  # UnboundLocalError: local 'x' referenced before assignment.


--

I wouldn't call either behavior intuitive or unintuitive.  They're just
different behaviors of different languages.


On Fri, Sep 30, 2016 at 5:33 AM, Steve D'Aprano 
wrote:

> On Fri, 30 Sep 2016 05:29 am, namenobodywa...@gmail.com wrote:
>
> > hello pythonistas
> >
> > i've had a nodding acquaintance with python for some time, and all along
> i
> > assumed that for-loops got a namespace of their own;
>
> Giving for-loops their own namespace is a grossly unintuitive and a very
> weird thing to do. Modules, classes and functions are obviously namespaces.
> Why should arbitrary syntactic structures create their own namespace?
>
> It would be terribly inconvenient and surprising for if...else blocks to be
> separate namespaces:
>
> a = 1
> if condition:
> print(a)  # UnboundLocalError: local 'a' referenced before assignment
> a += 1
>
>
> For-loops are no different. Making them their own namespace is a very
> strange thing to do, it would mean you couldn't re-bind a value inside a
> for-loop:
>
> count = 0
> for x in sequence:
> count += 1
> # raises UnboundLocalError: local 'count' referenced before assignment
>
>
> unless you declared it nonlocal or global, depending on whether your for
> loop was inside a function or not.
>
> To me, "make for-loops be their own scope" sounds like a joke feature out
> of
> joke languages like INTERCAL. I'm not aware of any sensible language that
> does anything like this.
>
> No, wait a minute, I tell a lie, I recall Chris Angelico mentioning that
> one
> of his favourite languages, Pike or REXX, does it. I forget which.
>
>
>
>
> --
> Steve
> “Cheer up,” they said, “things could be worse.” So I cheered up, and sure
> enough, things got worse.
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: unintuitive for-loop behavior

[Brendan Abel]

Yes, loops don't have their own scope.  Indeed, very few flow elements in
python -- if, with, try/except -- create a new scope.  In that sense, it's
fairly consistent, but can be unexpected for people that have used
languages with many nested scopes.

The lambda behavior is a common gotcha - there are hundreds of questions on
StackOverflow that are caused by that misunderstanding

http://stackoverflow.com/questions/7368522/weird-behavior-lambda-inside-list-comprehension

The most common solution is to just provide the variable as a default
argument to the lambda function, which will bind it how you'd expect

[lambda base, exponent=exponent: (base ** exponent) for exponent in
range(9)]

On Thu, Sep 29, 2016 at 12:29 PM,  wrote:

> hello pythonistas
>
> i've had a nodding acquaintance with python for some time, and all along i
> assumed that for-loops got a namespace of their own; now i'm reading up on
> the language and i find out that's not the case: the loop variable gets put
> into the enclosing namespace, overwriting any former value that was already
> there; of course i realize there are situations where one is interested in
> the value that a loop variable has after the loop has been exited, but this
> behavior seems grossly unintuitive to me: has there ever been any
> discussion of giving for-loops the option of running in namespaces of their
> own?
>
> and it gets even worse; consider the following means of raising an
> exception:
>
> #)-- begin code
>
> def powerfunction(exponent):
> return lambda base: (base ** exponent)
>
> p1 = [powerfunction(exponent) for exponent in range(9)]
> p2 = [lambda base: (base ** exponent) for exponent in range(9)]
>
> assert p1[3](4) == p2[3](4)
>
> #) end code
>
> apparently the problem is that "exponent" gets evaluated when the relevant
> lambda function is run, not when it's defined, but no binding for
> "exponent" gets put into the enclosing namespace: it seems that python
> remembers this ghostly "exponent" for me on the theory that i don't WANT
> "p1" and "p2" to be the same; can anyone help to reconcile me to this
> semantics?
>
> thanks if you can help
> stm
>
>
>
>
>
>
>
>
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to import all things defined the files in a module directory in __init__.py?

[Brendan Abel]

> Splitting it up would make it slower to load.

It's usually the opposite.  When packages are split up, you only have to
load the specific portions you need.  Putting it all in a single module
forces you to always load everything.

On Fri, Sep 23, 2016 at 11:59 PM, Lawrence D’Oliveiro <
lawrenced...@gmail.com> wrote:

> On Saturday, September 24, 2016 at 2:11:09 PM UTC+12, Chris Angelico wrote:
> > It's a large and complex module, and about at the boundary of being
> > broken up a bit.
>
> Splitting it up would make it slower to load.
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What is the correct form for saying "licensed under the same terms as Python itself"?

[Brendan Abel]

Unless you're actually distributing python (as in, the interpreter or it's
source code), you don't need to include the python license or the copyright
notice.  You also don't need a Contributor agreement just to distribute a
python library.  That is more for people who are contributing to core
Python or if your package is being added to the standard library.

Python has a custom license, though it is GPL-compatible.  The python
license has a lot of wording that is specific to python and the PSF, so it
probably doesn't make sense for you to use their license.  Also, according
to the python web site, they only accept contributions under the following
licenses:


   - Academic Free License v. 2.1
   
   - Apache License, Version 2.0
   

https://www.python.org/psf/contrib/

So, if you want your code to be available to the Python team (which is what
it sounds like), you should use one of those 2 licenses, or consider using
an even more permissive license (like the MIT license) that would not
prohibit your project from being relicensed under the Apache or Python
license.

On Wed, Sep 14, 2016 at 7:58 AM, Mark Summerfield 
wrote:

> Hi,
>
> I'm developing a small Python software library that I want to publish as
> free software under the same terms as Python itself.
>
> I notice that a few of Python's own files begin like this:
>
> # Copyright 2007 XXX. All Rights Reserved.
> # Licensed to PSF under a Contributor Agreement.
>
> Is this form sufficient?
> Do I need to include the PSF license with the package?
> (Also, I don't actually remember if I've signed a Contributor Agreement.)
>
> Thanks!
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python inner function parameter shadowed

[Brendan Abel]

Yeah, you could change the name, but it shouldn't matter, the "func" in the
inner function will always be the one passed into it, it won't be the
"func" from the outer function, which in this specific case, would always
be None (at least as far as the second inner function is concerned.)

On Tue, Sep 13, 2016 at 11:31 AM, Chris Angelico <ros...@gmail.com> wrote:

> On Wed, Sep 14, 2016 at 4:28 AM, Brendan Abel <007bren...@gmail.com>
> wrote:
> > This looks like a decorator function that optionally accepts arguments to
> > change the behavior.
>
> Oh, I get it. So, yeah, it is one function doing two jobs -
> legitimately. In that case, I'd just rename one of the 'func'
> arguments - probably the inner one, since that's never going to be
> passed as a keyword.
>
> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python inner function parameter shadowed

[Brendan Abel]

This looks like a decorator function that optionally accepts arguments to
change the behavior.

You can safely ignore the warning form PyCharm.  the variable won't be
shadowed it's included in the function signature of the inner function.

A lot of times, the outside decorator will just use the *args or **kwargs
parameters and check whether the first arg is callable or not and if any
keywords have been passed in to decide which version of the wrapped
function to return

Here is an example:
http://stackoverflow.com/questions/653368/how-to-create-a-python-decorator-that-can-be-used-either-with-or-without-paramet

On Tue, Sep 13, 2016 at 9:40 AM, Chris Angelico  wrote:

> On Wed, Sep 14, 2016 at 2:34 AM, Daiyue Weng  wrote:
> > Hi, I am using inner function like this,
> >
> > def timeit(func=None, loops=1, verbose=False):
> > if func is not None:
> > def inner(*args, **kwargs):
> >
> > # some code
> >
> > return inner
> > else:
> > def partial_inner(func):
> > return timeit(func, loops, verbose)
> >
> > return partial_inner
> >
> >
> > PyCharm warns about "Shadows name 'func' from outer scope" on
> >
> > def partial_inner(func):
> >
> > How to fix it?
> >
> > cheers
>
> Hmm. I think the real solution here is to separate this into two functions:
>
> def timeit(func, loops=1, verbose=False):
> def inner(*args, **kwargs):
>
> # some code
>
> return inner
>
> def timeit_nofunc(loops=1, verbose=False):
> def partial_inner(func):
> return timeit(func, loops, verbose)
> return partial_inner
>
> But without knowing more about what you're accomplishing, I can't
> really say. If you just want a quick fix to shut the linter up (note
> that this is NOT a Python error, it's just a message from a linter),
> you could use a different name for one of the variables.
>
> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Unittest

[Brendan Abel]

Generally, all your unittests will be inside a "tests" directory that lives
outside your package directory.  That directory will be excluded when you
build or install your project using your setup.py script.  Take a look at
some popular 3rd party python packages to see how they structure their
projects and setup their setup.py.

On Mon, Jul 25, 2016 at 9:45 AM, Joaquin Alzola 
wrote:

> Hi Guys
>
> I have a question related to unittest.
>
> I suppose a SW that is going to live will not have any trace of unittest
> module along their code.
>
> So is it the way to do it to put all unittest in a preproduction
> environment and then remove all lines relate to unittest once the SW is
> release into production?
>
> What is the best way of working with unittest?
>
> BR
>
> Joaquin
>
> This email is confidential and may be subject to privilege. If you are not
> the intended recipient, please do not copy or disclose its content but
> contact the sender immediately upon receipt.
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: reversed(enumerate(x))

[Brendan Abel]

You could create your own generator that wraps enumerate

def reverse_enumerate(iterable):
for i, val in enumerate(reversed(iterable)):
yield len(iterable) - 1 - i, val

for i, val in reverse_enumerate(x):
...

On Wed, Jul 20, 2016 at 10:42 AM, Ian Kelly  wrote:

> I had occasion to write something like this:
>
> for i, n in reversed(enumerate(x)): pass
>
> Of course this fails with "TypeError: argument to reversed() must be a
> sequence". I ended up using this instead:
>
> for i, n in zip(reversed(range(len(x))), reversed(x)): pass
>
> This works but is extraordinarily ugly and not terribly clear. I think
> it's less confusing however than:
>
> for i, n in zip(range(len(x)-1, -1, -1), reversed(n)): pass
>
> How would you write this?
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Were is a great place to Share your finished projects?

[Brendan Abel]

A lot of these arguments and points have already been made and hashed out
on the python-dev list.  There's a very good article that one of the python
core developers wrote about the decision to move to github

http://www.snarky.ca/the-history-behind-the-decision-to-move-python-to-github

Basically, maintaining an open source git server, bug tracker, etc. would
have cost time and money, and historically very few people were willing to
contribute those, especially the people who were the most opinionated on
the desire to remain "pure to open source".  Github gives all these things
away for free.  And pretty much every python developer has already used
github for other projects.  In the article he makes a good point that if
you're that worried about always using open-source, then you shouldn't be
using gmail, or twitter, or even automobiles, since they all use software
that is closed-source.  At some point, paying for software just makes sense.



On Thu, Jul 14, 2016 at 12:34 PM, Terry Reedy  wrote:

> On 7/14/2016 3:04 PM, hasan.di...@gmail.com wrote:
>
> Python's primary repository is Mercurial (hg.python.org), not Git.
>>
>
> CPython's current repository 
> Ditto for the PSF Python docs.
>
> Were python to switch,
>>
>
> Like it or not, CPython and the Docs are moving to git and github.
> PEPs and the devguide have already been moved.
>
> --
> Terry Jan Reedy
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Are imports supposed to be like this?

[Brendan Abel]

Consider the following example python package where `a.py` and `b.py`
depend on each other:

/package
__init__.py
a.py
b.py


There are several ways I could import the "a.py" module in "b.py"

import package.a   # Absolute import
import package.a as a_mod  # Absolute import bound to different name
from package import a  # Alternate absolute import
import a   # Implicit relative import (deprecated, py2
only)
from . import a# Explicit relative import

Unfortunately, only the 1st and 4th syntax actually work when you have
circular dependencies (the rest all raise `ImportError` or
`AttributeError`), and the 4th syntax only works in python 2 and is
generally discouraged because of the possibility of name conflicts.

I'd much rather use relative imports, or the "from x import y" syntax, or
at least be able to use the "as" import syntax.  If I have a deeply nested
package, the imports become unruly rather quickly, and I have to use that
long, ugly name throughout the entire module!

import package.subpackage.submodule.module  # fugly!

Are imports designed to work this way, or is this a bug in the import
machinery?  What reasoning is there for the first syntax to work, but all
the others should fail?  Admittedly, I haven't used Python3 yet, does it
fix this?  It seems odd to me that the documentation seems to encourage
relative imports or at least the "from x.y.z import a" forms of imports,
yet they don't work the same as "import x.y.z.a".


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

Imports and cyclical dependencies

[Brendan Abel]

I have a relatively large python package that has several cyclical 
dependencies.  The cyclical dependencies typically aren't a problem so long as 
I'm just importing modules, and not named attributes (ie. function, class, 
globals), which may not be defined at a given point in the import routine 
because of the cyclical dependency.

The problem I'm encountering is that relative imports and any import that uses 
the  from package import module or import package.module as module syntax 
results in an ImportError (or AttributeError for the as syntax).  I would 
much rather use this import syntax for several reasons:

1. Relative imports seem to be the recommended syntax going forward for 
intra-package imports.
2. One of the two import syntaxes that work does not work in Python3, or if 
absolute imports are used in Python2.
3. Imports with nested subpackages are wordy (eg. package.packa.packb.module) 
and make the code longer and harder to read.

I posted the question to stackoverflow with an example and got some useful 
information, but not the answer I was looking for.

http://stackoverflow.com/questions/19822281/why-do-these-python-import-statements-behave-differently

At this point, I'm wondering if I should report this as a bug/feature request, 
since it seems that these imports should be able to resolve to the correct 
module.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The real problem with Python 3 - no business case for conversion (was I strongly dislike Python 3)

[Brendan Abel]

   One thing that would be very useful is how to maintain something that
   works on 2.x and 3.x, but not limiting yourself to 2.6. Giving up
   versions below 2.6 is out of the question for most projects with a
   significant userbase IMHO. As such, the idea of running the python 3
   warnings is not so useful IMHO - unless it could be made to work
   better for python 2.x  2.6, but I am not sure the idea even makes
   sense.

The entire fact that 3.x was *designed* to be incompatible should tell
you that supporting 2.x and 3.x with a single code base is a bad idea,
except for the very smallest of projects.  This is the point where a
project should fork and provide two different versions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The real problem with Python 3 - no business case for conversion (was I strongly dislike Python 3)

[Brendan Abel]

On Jul 7, 3:00 pm, MRAB pyt...@mrabarnett.plus.com wrote:
 Brendan Abel wrote:
  One thing that would be very useful is how to maintain something that
  works on 2.x and 3.x, but not limiting yourself to 2.6. Giving up
  versions below 2.6 is out of the question for most projects with a
  significant userbase IMHO. As such, the idea of running the python 3
  warnings is not so useful IMHO - unless it could be made to work
  better for python 2.x  2.6, but I am not sure the idea even makes
  sense.

  The entire fact that 3.x was *designed* to be incompatible should tell
  you that supporting 2.x and 3.x with a single code base is a bad idea,
  except for the very smallest of projects.  This is the point where a
  project should fork and provide two different versions.

 I wouldn't say that 3.x was designed to be incompatible. It was designed
 to tidy the language, and the incompatibilities are an unfortunate
 result.

You're missing the point, and arguing semantics.  It's a good thing I
didn't misspell anything.

Python 3.x will continue to change.  The incompatibilities between 3.x
and 2.x will only become more numerous.  If your goal is to support
2.x, and 3.x, you'd be best supporting them separately.


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

Re: Picking a license

[Brendan Abel]

While I think most of the disagreement in this long thread results
from different beliefs in what freedom means, I wanted to add, that
most of the responses that argue that the MIT license permits the user
more freedom than the GPL, suffer from the broken window fallacy.
This fallacy results from the short-sided-ness of the user base, as it
is only considering the first generation of derivative works.

I agree, that under an MIT license, the first generation of derivative
works have more freedom.  But any extra freedom gained here comes at
the direct expense of all future generations of derivative software.

Under a GPL license, it is true that the first generation will have
less freedom to distribute their software as they would like.  But it
also ensures that all subsequent generations of derivative works have
the freedom to access all previous derivative works.

I also want to add that I think the GPL v3 has exceeded this
fundamental concept.  GPL v2 really embodies this meaning of freedom.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python dot-equals (syntax proposal)

[Brendan Abel]

On Apr 30, 9:04 am, Jabapyth jabap...@gmail.com wrote:
 At least a few times a day I wish python had the following shortcut
 syntax:

 vbl.=func(args)

 this would be equivalent to

 vbl = vbl.func(args)

 example:

 foo = Hello world
 foo.=split( )
 print foo
 # ['Hello', 'world']

 and I guess you could generalize this to

 vbl.=[some text]
 #
 vbl = vbl.[some text]

 e.g.

 temp.=children[0]
 # temp = temp.children[0]

 thoughts?

I tend to use this design pattern occasionally in my code as well:

val = val.func()  PROPOSED:  val .= func()

OR

val = func(val)  PROPOSED: val .= func(?) (not really sure how this
should look)


However, these are the only two use cases I can think of for this
language syntax modification proposal.  The first use case could lead
to namespace issues (if func() exists as a function as well as a
method), and even if the interpreter can choose correctly, reading it
may lead to confusion.  There will be at least some ambiguity in the
second use case (what if func() takes more than one argument, what if
it requires keyword arguments?).  The current implementation is much
more readable (THE guiding principle with python), and doesn't require
any lengthier code than the proposed changes, especially when you
factor in any other syntax changes that would be necessary to handle
the aforementioned ambiguities.

Just my 2 cents. :)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: function name

[Brendan Abel]

On Apr 28, 11:44 am, Richard Lamboj richard.lam...@bilcom.at wrote:
 Hello,

 is there any way to get the name from the actual called function, so that the
 function knows its own name?

 Kind Regards,

 Richi

If you want to get the function name from within the function itself,
check out the inspect module.
http://docs.python.org/library/inspect.html#inspect.currentframe
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: assigning multi-line strings to variables

[Brendan Abel]

On Apr 27, 7:20 pm, goldtech goldt...@worldpost.com wrote:
 Hi,

 This is undoubtedly a newbie question. How doI assign variables
 multiline strings? If I try this i get what's cited below. Thanks.

  d=d
 d
  d

 Traceback (most recent call last):
   File interactive input, line 1, in module
 NameError: name 'd' is not defined



d = d\
d

or

d = dd\
dd

You don't need the trailing slash in the first example if you are
writing this in a script, python assumes it.
-- 
http://mail.python.org/mailman/listinfo/python-list