Re: OTish: using short-term TCP connections to send to multiple slaves

[Peter Otten]

jkn wrote:

> Hi all
> This is a little bit OT for this newsgroup, but I intend to use python
> for prototyping at least, and I know there are a lot of knowledgeable
> people using Python in a Network context here...
> 
> I have a use case of a single 'master' machine which will need to
> periodically 'push' data to a variety of 'slave' devices on a small local
> subnet, over Ethernet. We are talking perhaps a dozen devices in all with
> comms occurring perhaps once very few seconds, to much less often - once
> per half an hour, or less. There is probably an upper bound of 64KB or so
> of data that is likely to be sent on each occasion.
> 
> Previous similar systems have attempted to do this by maintaining multiple
> long-term TCP connections from the master to all the slave devices. The
> Master is the server and the slaves periodically check the master to see
> what has changed. Although this ... works ..., we have had trouble
> maintaining the connection, for reasons ... I am not yet fully aware of.
> 
> We are now considering an alternative approach where the master maintains
> a list of slave devices and acts as a client. Each device is a server from
> the point of view of data transfer. We would then use a short-lived TCP
> connection when data is available; the Master would connect to each slave
> which needed the data, send it, and close the connection.
> 
> I should also add that we desire our system to be 'robust' in the face of
> situations such as cable unplugging, device power cycles, etc.
> 
> Although this might get round some of our current problems, I can see that
> we might end up with new problems to deal with. I am wondering if this
> scenario rings bells with anyone, and seeking pointers to what has been
> done elsewhere. As I say, I am expecting to prototype it in Python so any
> specifics also welcome!
> 
> (suggestions as to a better forum to ask for previous experience also
> gratefully received)
> 
> Thanks al lot for any thoughts/suggestions

You said *any* suggestions, so:

I know nothing about them, but would a messaging infrastructure like 
RabbitMQ or ZeroMQ be useful?

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

Re: Interrupted system call

[Peter Bell]

Many thanks for your helpful response, Chris.

On 17/11/14 06:13, Chris Angelico wrote:

On Sun, Nov 16, 2014 at 7:11 PM, Peter Bell  wrote:

   File "/usr/lib/python3.4/site-packages/serial/serialposix.py", line 480,
in read
 if e[0] != errno.EAGAIN:
TypeError: 'InterruptedError' object is not subscriptable
=


I'm not sure how to address the 'InterruptedError'.  Can it/should it be
masked at the user code level with a 'try:' block?  Or is there another way
to deal with it?


At this stage, you're not getting it, because of the cascaded error,
so that's the thing to deal with.


Okay - I was just thinking that if the 'InterruptedError' didn't occur, 
then the 'TypeError' would never be exposed!



I presume that the subsequent error (TypeError) indicates some fault in the
system level library.  I'm not sure where/how to report this.


Not system-level. According to the traceback, that's coming from line
480 of something in site-packages, which probably means it was
installed with pip or equivalent. Do you know where you got hold of
this module from? That's who to report this to.


Ah, I understand. I believe, then, that this is from the pyserial 
module, fetched from sourceforge.



It's trying to retrieve the errno from the exception. I suspect the
code was written for Python 2, and you're using it with Python 3. It's
probably possible to shorten/simplify the code somewhat.


I see, now, that the sourceforge download does specify 
'pyserial-2.7.tar.gz' and, yes, I'm working in Python 3.  I see, from 
other comments around the web, that I'm not the only person to be 
attempting to use this module with 3.


Given that pyserial is for 2.7, it is probably unreasonable to report 
errant behaviour when run on Python 3.


I'm teaching myself (and the kids, as I go) Python and felt, rightly or 
wrongly, that it would be better to start with Python 3, rather than 
learning the older Python 2.x.


Is there a better way to interface to a serial port from Python 3?  I've 
found a reference in the PSF 3.3.6 FAQ which points to pyserial on 
sourceforge.


--
---
Peter BellMob: +63 (0) 9287 340 343
Tagum City, Philippines.  Tel: +63 (0) 84 216 9037
email/msn: pe...@bellfamily.org.ukTel: +63 (0) 84 308 0002
--
https://mail.python.org/mailman/listinfo/python-list

Re: Interrupted system call

[Chris Angelico]

On Mon, Nov 17, 2014 at 3:10 PM, Peter Bell  wrote:
> Many thanks for your helpful response, Chris.
>
> On 17/11/14 06:13, Chris Angelico wrote:
>>
>> On Sun, Nov 16, 2014 at 7:11 PM, Peter Bell 
>> wrote:
>>>
>>>File "/usr/lib/python3.4/site-packages/serial/serialposix.py", line
>>> 480,
>>> in read
>>>  if e[0] != errno.EAGAIN:
>>> TypeError: 'InterruptedError' object is not subscriptable
>>> =
>>>
>>>
>>> I'm not sure how to address the 'InterruptedError'.  Can it/should it be
>>> masked at the user code level with a 'try:' block?  Or is there another
>>> way
>>> to deal with it?
>>
>>
>> At this stage, you're not getting it, because of the cascaded error,
>> so that's the thing to deal with.
>
>
> Okay - I was just thinking that if the 'InterruptedError' didn't occur, then
> the 'TypeError' would never be exposed!

Correct. The handling of InterruptedError (a subclass of OSError) is
what's raising TypeError.

> Ah, I understand. I believe, then, that this is from the pyserial module,
> fetched from sourceforge.
>
> I see, now, that the sourceforge download does specify 'pyserial-2.7.tar.gz'
> and, yes, I'm working in Python 3.  I see, from other comments around the
> web, that I'm not the only person to be attempting to use this module with
> 3.
>
> Given that pyserial is for 2.7, it is probably unreasonable to report errant
> behaviour when run on Python 3.

Yes and no. It may be possible to alter the code to be 2/3 compatible;
for instance, if e.errno is used instead of e[0], it should work in
both 2.7 and 3.x. (I haven't confirmed this, though.) But keep
reading.

> I'm teaching myself (and the kids, as I go) Python and felt, rightly or
> wrongly, that it would be better to start with Python 3, rather than
> learning the older Python 2.x.

You felt rightly. All you need is...

> Is there a better way to interface to a serial port from Python 3?  I've
> found a reference in the PSF 3.3.6 FAQ which points to pyserial on
> sourceforge.

... a solution to this. I would suggest looking on PyPI, the Python
Package Index, to see what you can get for Python 3. In your case, you
may well be in luck:

https://pypi.python.org/pypi/pyserial

There's a version that claims to work with any Python version (though
there's some minor disagreement; the metadata says 2.3-2.7 and
3.0-3.3, but the Windows binaries say 2.4-2.7 and 3.0-3.4). I suspect
the "2.7" in the name is actually the version of PySerial, and it's
coincidental that that happens also to be a Python version.

Since you seem to be on a POSIX system, you shouldn't need to worry
about the provided binary installers. Use pip3 to install it for your
Python 3, and you should be all set.

Now, since the package does claim to support Python 3, any
discrepancies between that claim and the actual results you're seeing
*are* reportable bugs. But it's entirely possible that using pip to
install it will sort all that out, as it'll go and grab the correct
version.

All the best!

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

Re: Interrupted system call

[Peter Otten]

Chris Angelico wrote:

> On Mon, Nov 17, 2014 at 3:10 PM, Peter Bell 
> wrote:
>> Many thanks for your helpful response, Chris.
>>
>> On 17/11/14 06:13, Chris Angelico wrote:
>>>
>>> On Sun, Nov 16, 2014 at 7:11 PM, Peter Bell 
>>> wrote:

File "/usr/lib/python3.4/site-packages/serial/serialposix.py", line
 480,
 in read
  if e[0] != errno.EAGAIN:
 TypeError: 'InterruptedError' object is not subscriptable
 =


 I'm not sure how to address the 'InterruptedError'.  Can it/should it
 be
 masked at the user code level with a 'try:' block?  Or is there another
 way
 to deal with it?
>>>
>>>
>>> At this stage, you're not getting it, because of the cascaded error,
>>> so that's the thing to deal with.
>>
>>
>> Okay - I was just thinking that if the 'InterruptedError' didn't occur,
>> then the 'TypeError' would never be exposed!
> 
> Correct. The handling of InterruptedError (a subclass of OSError) is
> what's raising TypeError.
> 
>> Ah, I understand. I believe, then, that this is from the pyserial module,
>> fetched from sourceforge.
>>
>> I see, now, that the sourceforge download does specify
>> 'pyserial-2.7.tar.gz'
>> and, yes, I'm working in Python 3.  I see, from other comments around the
>> web, that I'm not the only person to be attempting to use this module
>> with 3.
>>
>> Given that pyserial is for 2.7, it is probably unreasonable to report
>> errant behaviour when run on Python 3.
> 
> Yes and no. It may be possible to alter the code to be 2/3 compatible;
> for instance, if e.errno is used instead of e[0], it should work in
> both 2.7 and 3.x. (I haven't confirmed this, though.) But keep
> reading.
> 
>> I'm teaching myself (and the kids, as I go) Python and felt, rightly or
>> wrongly, that it would be better to start with Python 3, rather than
>> learning the older Python 2.x.
> 
> You felt rightly. All you need is...
> 
>> Is there a better way to interface to a serial port from Python 3?  I've
>> found a reference in the PSF 3.3.6 FAQ which points to pyserial on
>> sourceforge.
> 
> ... a solution to this. I would suggest looking on PyPI, the Python
> Package Index, to see what you can get for Python 3. In your case, you
> may well be in luck:
> 
> https://pypi.python.org/pypi/pyserial
> 
> There's a version that claims to work with any Python version (though
> there's some minor disagreement; the metadata says 2.3-2.7 and
> 3.0-3.3, but the Windows binaries say 2.4-2.7 and 3.0-3.4). I suspect
> the "2.7" in the name is actually the version of PySerial, and it's
> coincidental that that happens also to be a Python version.
> 
> Since you seem to be on a POSIX system, you shouldn't need to worry
> about the provided binary installers. Use pip3 to install it for your
> Python 3, and you should be all set.

I'd suggest a more conservative path: if available install the version that 
comes with your distribution. 

$ sudo apt-get python3-serial

might do the job.

> Now, since the package does claim to support Python 3, any
> discrepancies between that claim and the actual results you're seeing
> *are* reportable bugs. But it's entirely possible that using pip to
> install it will sort all that out, as it'll go and grab the correct
> version.
> 
> All the best!
> 
> ChrisA


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

Re: Interrupted system call

[Peter Bell]

On 17/11/14 16:31, Chris Angelico wrote:

On Mon, Nov 17, 2014 at 3:10 PM, Peter Bell  wrote:

Is there a better way to interface to a serial port from Python 3?  I've
found a reference in the PSF 3.3.6 FAQ which points to pyserial on
sourceforge.


... a solution to this. I would suggest looking on PyPI, the Python
Package Index, to see what you can get for Python 3. In your case, you
may well be in luck:

https://pypi.python.org/pypi/pyserial

There's a version that claims to work with any Python version (though
there's some minor disagreement; the metadata says 2.3-2.7 and
3.0-3.3, but the Windows binaries say 2.4-2.7 and 3.0-3.4). I suspect
the "2.7" in the name is actually the version of PySerial, and it's
coincidental that that happens also to be a Python version.


I think that you are correct.  pyserial-2.7 is supposed to be compatible 
with python3.



Since you seem to be on a POSIX system, you shouldn't need to worry
about the provided binary installers. Use pip3 to install it for your
Python 3, and you should be all set.


On further investigation, it turns out that I installed pyserial from my 
distro's package manager.  The default python is 3, with python2 being 
the alternative.  Now, to go with this, I'd installed python-pyserial, 
not python2-pyserial:


==
[root@automate ~]# pacman -Ss pyserial
community/python-pyserial 2.7-4 [installed]
Multiplatform Serial Port Module for Python
community/python2-pyserial 2.7-4
Multiplatform Serial Port Module for Python
==

So, yes, my understanding is that the pyserial-2.7 which I have 
installed should be compatible with Python3.


Now I have to work out how to make the report to Chris Liechti - I'll 
try his gmx.net email address.


Thanks for all your advice - I'm enjoying my project, and loving Python!

Regards,
Peter.

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

Re: Interrupted system call

[Chris Angelico]

On Mon, Nov 17, 2014 at 7:55 PM, Peter Otten <__pete...@web.de> wrote:
> I'd suggest a more conservative path: if available install the version that
> comes with your distribution.
>
> $ sudo apt-get python3-serial
>
> might do the job.

Only if the Python to install to was also the distro-installed one.
Turns out that's the case, but if it's not, pip is the way to go.

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

Re: import graphics library; causes error

[Steven D'Aprano]

ryguy7272 wrote:


> Python is by far the most backwards type 
> of technology that I can think of.  Using it is completely
> counter-productive.  I can't take it serious. I have plenty of tools in 
> my toolbox.  I'll keep learning Python, and keep reading books, and keep
> using it...but strictly for fun.  I would never use this as a foundation
> for a mission critical business application.

Thank you for setting us right.

Would you mind dropping a note to Google, DropBox, NASA, CERN, Microsoft,
Industrial Light & Magic, Rackspace, Honeywell and Red Hat, and tell them
that based on your extensive experience (all ten minutes of it) they're
obviously doing it wrong and Python is a toy language not suitable for
critical business apps?

I'm sure that they will be grateful to be set right.




-- 
Steven

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

Re: OTish: using short-term TCP connections to send to multiple slaves

[alister]

On Mon, 17 Nov 2014 08:56:43 +1100, Chris Angelico wrote:

> On Mon, Nov 17, 2014 at 4:21 AM, Roy Smith  wrote:
>> In article ,
>>  Chris Angelico  wrote:
>>
>>> UDP for anything more than your network's MTU is inefficient
>>
>> Why do you say it's inefficient?  Sure, the UDP datagram will get
>> fragmented and re-assembled at the other end, but it's not like TCP
>> would do any better.  One way or another, your data is going to be
>> transmitted in packet that fit into the MTU.
> 
> Sorry, is less efficient. I was responding to the point about 64KB being
> way too big for UDP, when really it's perfectly possible. It's common to
> keep UDP packet sizes as low as possible to take advantage of
> non-fragmentation efficiency (hence the DNS TCP switchover at 512
> bytes), but I've sent some huge UDP packets around.
> 
>>> plus you'd need to roll your own acknowledgement system so you know
>>> when the client got the data, at which point you're basically
>>> recreating TCP.
>>
>> That I certainly agree with.  UDP should be used for fire-and-forget,
>> where its not critical that every bit of data gets through.  A classic
>> example is high-volume logging.  Once you start thinking about any kind
>> of acknowledgements, you should just switch to TCP.  The alternative is
>> that you will slowly end up reinventing TCP (and doing a bad job of
>> it).
> 
> Another good use of UDP is where it's not 100% critical that *every*
> update get to *every* client instantly, but a client can "catch up" when
> it gets the next notification. (Since clients can be down, you'd need
> some kind of catch-up mechanic anyway.) If the data involved can fit
> inside a single UDP packet, this is trivially easy: just overwrite with
> the new state. Otherwise, some kind of update counter works too ("hmm, I
> got update 5, this one's update 7, I guess I'd better catch up"). If
> most clients collect most UDP updates, but occasionally they establish a
> TCP connection to do the full catch-up, you can get some handy
> conveniences.
> 
>>> NAT is the most common cause of breakage, but any router does have the
>>> power to monitor and drop connections on any basis it likes. (I can't
>>> imagine any reason a non-NAT router would want to prevent connections
>>> from going idle, but it could be done.)
>>
>> It's common in corporate networks for routers to forcibly close idle
>> connections (i.e. inject RST packets).  Often, the IT security guys
>> think idle connections represent some kind of threat (and good luck
>> trying to argue with them).
> 
> Yeah... but I can't imagine any reason for those connections to be a
> threat. I've heard of it happening but I cannot fathom the reasoning
> behind it. (You're also suggesting a much nicer approach than the
> worst-case I was talking about: with RST injection, at least one end
> will be immediately aware of the closure. If the router just starts
> dropping packets, much harder.)
> 
> ChrisA

I have recently been caught by this issues with call logging software for 
a PBX I maintain.

TCP sessions can get closed for a multitude of reasons. they are commonly 
closed by the TCP/IP stack because they have been idle too long & the 
resources are needed elsewhere. ideally a close message should be sent 
but this does not always happen (& is perfectly within specification)

if a sending devise finds that its connection is no longer open it should 
re-initiate the connection with a three way handshake.

Certain versions of the PBX firmware did not re initiate the connection 
but just kept retrying indefinitely meaning that the call logger did not 
get the data until the PBX output was stopped & restarted.

(a small python script to emulate things helped me prove what was 
happening :-) )
 



-- 
A horse!  A horse!  My kingdom for a horse!
-- Wm. Shakespeare, "Henry VI"
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: import graphics library; causes error

[Mark Lawrence]

On 17/11/2014 03:03, ryguy7272 wrote:

On Sunday, November 16, 2014 3:39:45 PM UTC-5, ryguy7272 wrote:

These libraries drive me totally nuts.  Sorry, just had to get it out there.
Anyway, I open the cmd window, and typed this: 'easy_install python graphics'.  
So, it starts up and runs/downloads the appropriate library from the web.  I 
get confirmation (in the cmd window) that it finishes, then I try to run this 
script.


# futval_graph2.py
from graphics import *
def main():
   # Introduction
   print "This program plots the growth of a 10-year investment."
   # Get principal and interest rate
   principal = input("Enter the initial principal: ")
   apr = input("Enter the annualized interest rate: ")
   # Create a graphics window with labels on left edge
   win = GraphWin("Investment Growth Chart", 640, 480)
   win.setBackground("white")
   win.setCoords(-1.75,-200, 11.5, 10400)
   Text(Point(-1, 0), '0.0K').draw(win)
   Text(Point(-1, 2500), '2.5K').draw(win)
   Text(Point(-1, 5000), '5.0K').draw(win)
   Text(Point(-1, 7500), '7.5k').draw(win)
   Text(Point(-1, 1), '10.0K').draw(win)
   # Draw bar for initial principal
   bar = Rectangle(Point(0, 0), Point(1, principal))
   bar.setFill("green")
   bar.setWidth(2)
   bar.draw(win)
   # Draw a bar for each subsequent year
   for year in range(1, 11):
 principal = principal * (1 + apr)
 bar = Rectangle(Point(year, 0), Point(year+1, principal))
 bar.setFill("green")
 bar.setWidth(2)
 bar.draw(win)
   raw_input("Press  to quit.")


After I hit F5, I get this:
Traceback (most recent call last):
   File "C:\Users\Ryan\Desktop\Graphics_Test.py", line 2, in 
 from graphics import *
ImportError: No module named graphics




In what directory?
Well, that's a damn good question.  I thought, by defailt, everything was 
downloaded to this folder:
'C:\Python27\Lib\site-packages'

In there, I have all kinds of things like:
'setuptools-6.1.dist-info', 'pip-1.5.6.dist-info', etc.
All kinds of other things too.

It seems there is always a copy, so I cut/paste the folders named 'setuptools' 
& 'pip' (always taking off the versions and identifiers and the like...).  Then 
I cut/paste everything into this folder:
'C:\Python27\Lib'

Is that how it's done or not?  Honestly, for the life of me, I don't know why a 
human being would have do do any of this, including using the cmd window, to 
install anything in 2014.  I can code in 10 different languages, not including 
Python.  Python is by far the most backwards type of technology that I can 
think of.  Using it is completely counter-productive.  I can't take it serious. 
 I have plenty of tools in my toolbox.  I'll keep learning Python, and keep 
reading books, and keep using it...but strictly for fun.  I would never use 
this as a foundation for a mission critical business application.

Thanks everyone!



A bad workman always blames his tools.

--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

Re: import graphics library; causes error

[YBM]

Le 17/11/2014 04:03, ryguy7272 a écrit :

On Sunday, November 16, 2014 3:39:45 PM UTC-5, ryguy7272 wrote:

These libraries drive me totally nuts.  Sorry, just had to get it out there.
Anyway, I open the cmd window, and typed this: 'easy_install python graphics'.  
So, it starts up and runs/downloads the appropriate library from the web.  I 
get confirmation (in the cmd window) that it finishes, then I try to run this 
script.


# futval_graph2.py
from graphics import *
[...]

In what directory?
Well, that's a damn good question.  I thought, by defailt, everything was 
downloaded to this folder:
'C:\Python27\Lib\site-packages'


Except when the module does not exist in pypi... In such case either
easy_install and pip finish by printing out that the module cannot be
found...

graphics.py is NOT distributed through pypi, you have to download and
copy it by yourself in an appropriate place from the author's Web site:

http://mcsp.wartburg.edu/zelle/python/graphics.py


It seems there is always a copy, so I cut/paste the folders named 'setuptools' 
& 'pip' (always taking off the versions and identifiers and the like...).  Then 
I cut/paste everything into this folder:
'C:\Python27\Lib'

Is that how it's done or not?  Honestly, for the life of me, I don't know why a 
human
being would have do do any of this, including using the cmd window, to install 
anything
in 2014.  I can code in 10 different languages, not including Python.  Python 
is by far
the most backwards type of technology that I can think of.
 Using it is completely counter-productive.  I can't take it serious.  I have 
plenty of
tools in my toolbox.  I'll keep learning Python, and keep reading books, and 
keep using
it...but strictly for fun.  I would never use this as a foundation for a 
mission critical
business application.


MS Windows is by far the most backwards type of technology that I can
think of. Using it is completely counter-productive.  I can't take it
serious. I have plenty of tools in my Linux boxes. I would never use MS
Windows as a foundation for a mission critical business application.

Hopefully I'm not the only one to think so...



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

I dont understand root['bg'] = 'red' where root is a tkinter.Tk object

[ast]

Hello,

import tkinter
root = tkinter.Tk()

Let's see all attributes of root:


root.__dict__
{'master': None, 'children': {}, '_tclCommands': ['tkerror', 'exit', '13825848destroy'], 'tk': 
, '_tkloaded': 1}


Now we change the background color using following command:

root['bg'] = 'red'


I am wondering what 'bg' is for object root. Is it an attribute ?


root.__dict__
{'master': None, 'children': {}, '_tclCommands': ['tkerror', 'exit', '13825848destroy'], 'tk': 
, '_tkloaded': 1}


No, 'bg' is not in root attribute's list. So what is it ?

Thx


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

Re: I dont understand root['bg'] = 'red' where root is a tkinter.Tk object

[Peter Otten]

ast wrote:

> Hello,
> 
> import tkinter
> root = tkinter.Tk()
> 
> Let's see all attributes of root:
> 
 root.__dict__
> {'master': None, 'children': {}, '_tclCommands': ['tkerror', 'exit',
> {'13825848destroy'], 'tk':
> , '_tkloaded': 1}
> 
> Now we change the background color using following command:
 root['bg'] = 'red'
> 
> I am wondering what 'bg' is for object root. Is it an attribute ?
> 
 root.__dict__
> {'master': None, 'children': {}, '_tclCommands': ['tkerror', 'exit',
> {'13825848destroy'], 'tk':
> , '_tkloaded': 1}
> 
> No, 'bg' is not in root attribute's list. So what is it ?

Let's drill down a bit:


>>> import tkinter, inspect
>>> print(inspect.getsource(tkinter.Tk.__setitem__))
def __setitem__(self, key, value):
self.configure({key: value})

>>> print(inspect.getsource(tkinter.Tk.configure))   
def configure(self, cnf=None, **kw):
"""Configure resources of a widget.

The values for resources are specified as keyword
arguments. To get an overview about
the allowed keyword arguments call the method keys.
"""
return self._configure('configure', cnf, kw)

>>> print(inspect.getsource(tkinter.Tk._configure))
def _configure(self, cmd, cnf, kw):
"""Internal function."""
if kw:
cnf = _cnfmerge((cnf, kw))
elif cnf:
cnf = _cnfmerge(cnf)
if cnf is None:
return self._getconfigure(_flatten((self._w, cmd)))
if isinstance(cnf, str):
return self._getconfigure1(_flatten((self._w, cmd, '-'+cnf)))
self.tk.call(_flatten((self._w, cmd)) + self._options(cnf))

>>> print(inspect.getsource(root.tk.call))
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3.4/inspect.py", line 830, in getsource
lines, lnum = getsourcelines(object)
  File "/usr/lib/python3.4/inspect.py", line 819, in getsourcelines
lines, lnum = findsource(object)
  File "/usr/lib/python3.4/inspect.py", line 655, in findsource
file = getfile(object)
  File "/usr/lib/python3.4/inspect.py", line 536, in getfile
'function, traceback, frame, or code object'.format(object))
TypeError:  is not a 
module, class, method, function, traceback, frame, or code object

OK, we've reached C code, from here more traditional methods of code 
inspection are required.

tkinter is a wrapper for a GUI written in tcl/tk. For every GUI element in 
tkinter there is a corresponding tcl object that holds the actual bg data. 
It's just that at some point in the development of tkinter someone thought 
that

widget["bg"] = "red"

is more convenient than

widget.configure(bg="red")

While it would have been possible to choose

widget.bg = "red"

that would have mixed the tcl and python namespaces. When the tcl object 
acquires new attributes hilarity ensues...

(I probably would have chosen widget.gui.bg = "red")

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

Re: Karlsruhe (Germany) Python User Group, November 21st 2014, 7pm

[M.-A. Lemburg]

Added to the Python User Group calendar. Thanks.

On 14.11.2014 06:43, Jürgen A. Erhard wrote:
> The Karlsruhe Python User Group (KaPy) meets again.
> 
> Friday, 2014-11-21 (November 21st) at 19:00 (7pm) in the rooms of Entropia eV
> (the local affiliate of the CCC).  See http://entropia.de/wiki/Anfahrt
> on how to get there.
> 
> For your calendars: meetings are held monthly, on the 3rd Friday.
> 
> There's also a mailing list at
> https://lists.bl0rg.net/cgi-bin/mailman/listinfo/kapy.
> 

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Nov 17 2014)
>>> Python Projects, Consulting and Support ...   http://www.egenix.com/
>>> mxODBC.Zope/Plone.Database.Adapter ...   http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/

2014-11-11: Released eGenix pyOpenSSL 0.13.6 ...  http://egenix.com/go64

: Try our mxODBC.Connect Python Database Interface for free ! ::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: I dont understand root['bg'] = 'red' where root is a tkinter.Tk object

[ast]

"Peter Otten" <__pete...@web.de> a écrit dans le message de 
news:mailman.15958.1416233676.18130.python-l...@python.org...


ty 


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

Re: OTish: using short-term TCP connections to send to multiple slaves

[Grant Edwards]

On 2014-11-16, jkn  wrote:

> An analogy might be with a master and multiple slave devices sharing
> a serial RS-485 bus.

If that's the model you _want_, then UDP multicast matches it almost
exactly.  ;)

> I have control over the format of the data to be send, so there can
> and should be some indication of the beginning and end of a data
> 'block'. In actual fact the data is very likely to be in JSON.

Using TCP with human-readable ASCII data sure makes testing,
prototyping, and troubleshooting a lot easier: you'd be surprised what
you can do with some dummy data files, a shell script, and nc.

> UDP has been mentioned but I am expecting the comms to be TCP-based,
> I think. The 65KB block size is indicative but I am reluctant to say
> that this is a hard limit.
>
> Chris asks why the slave devices can't periodically connect to the
> master and request data. The reason is that it is unknown when data
> destined for a given slave will be available. The devices would need
> to connect perhaps once a second to get sufficient time resolution,
> and this seems over- complicated to me at the moment.

When the TCP connections are failing, does the master know they have
failed?

> (FWIW there will also have to be some (UDP?) transmission from the
> slaves to the master, for purposes of device discovery)

UDP broadcast works pretty well for discoverying nodes (I'm assuming
IPV4 at this point).  One hint for Linux platforms: you have to
disable reverse path filtering 

in order to receive a UDP packet whose source address doesn't match
the subnets of the interface on which it was received.  This can come
into play when you need to discover and configure a newly installed
device which hasn't yet been configured to match the subnet.

UDP discovery and configuration is actually much simpler to implement
under IPv6.  If you're doing IPv6, then UDP link-local all-nodes
multicast is trivial, since all nodes _have_ a valid link-local
address, you don't have to worrry about reverse-path filtering.

> Thanks for the mention of SCTP; I was aware that there were other
> protocols to consider but haven't yet looked hard at them. One likely
> issue here is that our simpler devices won't be able to support such
> protocols straightforwardly.

If simple helps, then UDP again fits the bill nicely.

-- 
Grant Edwards   grant.b.edwardsYow! I love ROCK 'N ROLL!
  at   I memorized the all WORDS
  gmail.comto "WIPE-OUT" in 1965!!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: I dont understand root['bg'] = 'red' where root is a tkinter.Tk object

[Terry Reedy]

On 11/17/2014 8:32 AM, ast wrote:

Hello,

import tkinter
root = tkinter.Tk()

Let's see all attributes of root:


root.__dict__

{'master': None, 'children': {}, '_tclCommands': ['tkerror', 'exit',
'13825848destroy'], 'tk': , '_tkloaded': 1}

Now we change the background color using following command:


As Peter Otten nicely explained, tkinter widgets are proxies for tk 
widgets, with a few extra attributes added (as shown above).  Tk widget 
methods are proxied as tkinter widget methods, with Python syntax and 
objects.


Tk widgets each *have* an internal options dictionary, created with the 
widget and later accessed trough the .configure method.  As tcl 
dictionaries, keys and values are strings. The configure method with no 
args returns the entire options dictionary and the Python wrapper return 
it as a Python dict.  Each value is a 2- or 5-tuple.


>>> root.configure()
{'takefocus': ('takefocus', 'takeFocus', 'TakeFocus', '0', '0'), 'pady': 
('pady', 'padY', 'Pad', , ), 
'relief': ('relief', 'relief', 'Relief', , 
'flat'), 'bg': ('bg', '-background'), 'class': ('class', 'class', 
'Class', 'Toplevel', 'Tk'), 'visual': ('visual', 'visual', 'Visual', '', 
''), 'highlightthickness': ('highlightthickness', 'highlightThickness', 
'HighlightThickness', , 0), 'borderwidth': 
('borderwidth', 'borderWidth', 'BorderWidth', , 0), 
'highlightbackground': ('highlightbackground', 'highlightBackground', 
'HighlightBackground', , 
'SystemButtonFace'), 'width': ('width', 'width', 'Width', '0'>, 0), 'container': ('container', 'container', 'Container', 0, 0), 
'bd': ('bd', '-borderwidth'), 'background': ('background', 'background', 
'Background', , 'SystemButtonFace'), 
'cursor': ('cursor', 'cursor', 'Cursor', '', ''), 'highlightcolor': 
('highlightcolor', 'highlightColor', 'HighlightColor', 'SystemWindowFrame'>, 'SystemWindowFrame'), 'use': ('use', 'use', 'Use', 
'', ''), 'colormap': ('colormap', 'colormap', 'Colormap', '', ''), 
'height': ('height', 'height', 'Height', , 0), 
'padx': ('padx', 'padX', 'Pad', , '0'>), 'menu': ('menu', 'menu', 'Menu', '', ''), 'screen': ('screen', 
'screen', 'Screen', '', '')}


Once created, this Python snapshot is independent of the tk options 
dictionary.  Changes in either do not affect the other.


Since sometime in 2.x, each tkinter widget *also* acts as a partial 
proxy for the tk widget's option dict.  Getting and setting a value by 
key works.


>>> root['bg']
'SystemButtonFace'


root['bg'] = 'red'


(Interior of root window turn bright red.)
>>> root['bg']
'red'

The keys method works. (I did not notice until reading the source in 
Peter's reply.)


>>> root.keys()
['bd', 'borderwidth', 'class', 'menu', 'relief', 'screen', 'use', 
'background', 'bg', 'colormap', 'container', 'cursor', 'height', 
'highlightbackground', 'highlightcolor', 'highlightthickness', 'padx', 
'pady', 'takefocus', 'visual', 'width']


Other dict methods, such as .items(), do not, instead raising 
AttributeError.  But items can be simulated.


>>> for k in sorted(root.keys()):
print(k, root[k])

background red
bd 0
bg red
borderwidth 0
class Tk
colormap
container 0
cursor
height 0
highlightbackground SystemButtonFace
highlightcolor SystemWindowFrame
highlightthickness 0
menu
padx 0
pady 0
relief flat
screen
takefocus 0
use
visual
width 0


I am wondering what 'bg' is for object root. Is it an attribute ?


No.  It is a key of one of the key,value pairs in the dict that root 
acts like.  This is the same as for any dict.  The attribute namespace 
of the dict (implemented by .__dict__) is separate from the namespace 
that the dict itself implements.  Given d = {1:'one'}, 1 is not an 
attribute of d.


--
Terry Jan Reedy

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

Re: caught in the import web again

[Charles T. Smith]

On Mon, 17 Nov 2014 08:08:40 +0100, dieter wrote:

> "Charles T. Smith"  writes:
>> ...
>> Are others equally frustrated by this or is there a trick or principle
>> that I'm missing.  At this point, I guess the way I'll have to proceed
>> is to put every class in its own file, no matter how small.  Hopefully
>> that takes care of the problem.
> 
> Recursive imports are inherently difficult. It is best if a careful
> design avoids it (note that a cycle free dependency structure is much
> easier to handle than a cyclic one -- not only for Python).
> 
> If you think such a cycle free module structure is impossible in your
> case, then try to delay module related operations:
> 
>*  consider local imports (imports inside a function).
>   They delay the import until the function is called rather than
>   execute it at module import time.
> 
>*  prefer "import " over "from  import ..."
>   This may delay the module access; perhaps (but not necessarily)
>   sufficiently such that the accessed object is already defined.
> 
> Neither of these approaches is complete - you may still get cyclic
> import dependencies and related problems. Usually, you need a careful
> module dependency design to avoid cyclic dependencies altogether.
>   
>   
>> I compared perl's object-oriented philosophy with python's and didn't
>> like how perl *requires* you to put everything into its own file.  Now
>> it looks like python does, too, implicitly.
> 
> If you put everything in a single file, then you do not get recursive
> imports (but you may still have other problems related to cyclic
> dependencies). Thus, Python's difficulties with recursive imports do not
> force you to "put everything in its own file".
> 
> If you think about it, you will recognize that cyclic dependencies are
> inherently difficult (e.g. "chicken - egg" type problems) and that the
> way Python handles cyclic import dependencies is rather natural (and
> understandable).


Well, I guess that's the definitive answer... the tips for delaying 
import are good, I'll try to leverage them.

I was hoping there would be a way to have python postpone evaluation 
similar to C's forward references.
-- 
https://mail.python.org/mailman/listinfo/python-list

Trouble getting full response content from PATCH request

[John Gordon]

I'm working with a third-party API and I'm seeing some behavior that I
can't explain.

The API uses the HTTP PATCH operation to set user passwords, and in
case of unacceptable passwords, the response is supposed to be an HTML
document containing a diagnostic message in the  tag.

When I submit my test data via a functional testing tool (SoapUI), it
behaves as expected.

However, when I submit test data from Python code, the response content
consists only of the diagnostic message, with no enclosing  or 
tags.

Does anyone have an idea why this might be happening?

Here's a sample of the code I'm using:

import requests

# API credentials -- username and password
auth = ('foo', 'bar')

# xml for setting password
with open('set_password.xml') as f:
raw_xml = f.read()

# fill in the requested password
body = raw_xml.format(password='hello')

headers = {'Content-type': 'text/xml'}

url = 'https://some.server.com/api/call/'

response = requests.patch(url, data=body, auth=auth, verify=False,
headers=headers)

print 'HTTP status code: %s' % response.status_code
print 'response content:'
print response.content

-- 
John Gordon Imagine what it must be like for a real medical doctor to
gor...@panix.comwatch 'House', or a real serial killer to watch 'Dexter'.

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

Re: Array of Functions

[Anton]

On Friday, November 14, 2014 2:17:38 PM UTC-8, Richard Riehle wrote:
> In C, C++, Ada, and functional languages, I can create an array of functions, 
> albeit with the nastiness of pointers in the C family.   For example, an 
> array of functions where each function is an active button, or an array of 
> functions that behave like formulae in a spreadsheet.  I am finding this a 
> bit challenging in Python.   
> 
> Example:
> 
> r1c1   r1c2  r1c3
> r2c1   r2c2  r2c3
> r3c1   r3c2  r3c3
> 
> where r1 is row 1 and c1 is column 1.  Suppose I want an array where the 
> colum three is a set of functions that operates on the other two columns, 
> depending on the values I set for those rows and columns?As noted, I can 
> do this pretty easily in most languages (well, except for Java which does not 
> support any kind of functional programming capability), even if I have to use 
> pointers.
> 
> I think my difficulty is related to the REPL nature of Python.  However, I am 
> sure some clever Pythonista has found a way to do this.   
> 
> Thanks in advance for any suggestions,
> 
> Richard Riehle, PhD, International Technological University, San Jose, CA

Could you share a code snippet in C/C++ that would do what you need?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: caught in the import web again

[Dave Angel]

"Charles T. Smith"  Wrote in message:

> Well, I guess that's the definitive answer... the tips for delaying
> import are good, I'll try to leverage them.
> 
> I was hoping there would be a way to have python postpone evaluation
> similar to C's forward references.
> 

In a module that might get tangled in a cycle, avoid global code
 that depends on other modules.  Instead of putting such
 initialization at top level, put inside a function that gets
 called after all suspect imports are completed. (That function
 has global keywords ). 

Similarly avoid class attribute initialization at class level, if
 such initialization references higher level modules.

-- 
DaveA

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

Re: caught in the import web again

[Steven D'Aprano]

Charles T. Smith wrote:

> Yes, we're talking about recursive imports here.  It's a complex, object-
> oriented system with big classes and little classes that are strongly
> interrelated.

Well, there's your problem right there. You're working with a complex,
highly coupled code-base. Alarms bells should be ringing in your head. That
sort of highly-interdependent code base is a nightmare to maintain at the
best of times. Recursive imports are just the start of the problem.

Circular dependencies are not just a problem in Python, they are a problem
throughout most of software design.

https://en.wikipedia.org/wiki/Acyclic_dependencies_principle

http://stackoverflow.com/questions/1897537/why-are-circular-references-considered-harmful


> I can get the imports configured properly so everything 
> works but if I make a little change to the code, then suddenly all my
> imports are broken and I must painstakingly go through the whole
> structure, reorganizing them.

The problems you are having with recursive imports are the symptom of a
deeper design problem. If you can, you should try to refactor your code so
as to have fewer mutual dependencies and less coupling.

 
> Are others equally frustrated by this or is there a trick or principle
> that I'm missing.  

Probably, and yes. Personally, I try very hard to avoid recursive imports as
a matter of principle, even when I can manage them safely, so personally
I'm never frustrated by them. But there are a few tricks you can use to
reduce the pain a little. Think of these as pain-killers. All they are
doing is masking the symptoms of an underlying problem, namely excessive
coupling.

You can often delay imports to when a function or method is called. Although
this is not "best practice", it does have its uses. Instead of this
recursive import:

# spam relies on this module, but this module relies on spam
import spam
class K:
def __init__(self):
self.eggs = spam.stuff()


you can write this:

class K:
def __init__(self):
import spam
self.eggs = spam.stuff()


That delays importing spam until after this module is already fully
initialised. If you're worried about efficiency, don't be, only the very
first import of spam will be expensive, the others will be very fast.

Another way to avoid recursive imports is to merge the code from both
modules into a single module. Note that this is the complete opposite of
the conclusion you draw below.

Google for "avoiding circular imports python" (and similar) and you will
find lots of discussions about this. Leave out the "python" and you will
find the same thing for other languages.


> At this point, I guess the way I'll have to proceed is 
> to put every class in its own file, no matter how small.  Hopefully that
> takes care of the problem.

I don't think that's going to help. If anything, it will make it worse.
Suppose you have two classes, A and B, which require each other:

class A:
def __init__(self):
self.thing = B()

class B(A): pass


There's a circular dependency right there, but no import is needed so it is
comparatively easy to manage. Now move them into separate modules, and
you've turned a manageable circular dependency within a single module into
a painful recursive import.

Python is not Java, nor Perl, and if you're putting every class into its own
file, you are doing it wrong.


> I compared perl's object-oriented philosophy with python's and didn't
> like how perl *requires* you to put everything into its own file.  Now it
> looks like python does, too, implicitly.

You are mistaken about that.



-- 
Steven

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

Re: caught in the import web again

[Ian Kelly]

On Mon, Nov 17, 2014 at 3:17 PM, Dave Angel  wrote:
> "Charles T. Smith"  Wrote in message:
>
>> Well, I guess that's the definitive answer... the tips for delaying
>> import are good, I'll try to leverage them.
>>
>> I was hoping there would be a way to have python postpone evaluation
>> similar to C's forward references.
>>
>
> In a module that might get tangled in a cycle, avoid global code
>  that depends on other modules.  Instead of putting such
>  initialization at top level, put inside a function that gets
>  called after all suspect imports are completed. (That function
>  has global keywords ).

If the problem is that one of those modules would import the current
module, then "after all suspect imports are completed" basically means
after the current module has finished importing. So what would be
responsible for calling such a function?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Different behaviour in list comps and generator expressions

[Steven D'Aprano]

Steven D'Aprano wrote:

> The following list comprehension and generator expression are almost, but
> not quite, the same:
> 
> [expr for x in iterable]
> 
> list(expr for x in iterable)
> 
> 
> The difference is in the handling of StopIteration raised inside the expr.
[...]


Thanks to Roy and Wolfgang for their comments.

If anyone is interested, Guido will soon be ruling on a PEP which will
change the behaviour of generators and generator expressions, and he has
asked for feedback. In particular, examples of code which will be broken by
this change.

Read the PEP here:

https://www.python.org/dev/peps/pep-0479


If you post comments here, I will see that they get forwarded on.


-- 
Steven

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

Re: Different behaviour in list comps and generator expressions

[Dan Stromberg]

On Mon, Nov 17, 2014 at 3:30 PM, Steven D'Aprano
 wrote:
>> The following list comprehension and generator expression are almost, but
>> not quite, the same:
>>
>> [expr for x in iterable]
>>
>> list(expr for x in iterable)
>>
>>
>> The difference is in the handling of StopIteration raised inside the expr.
> [...]
>
>
> Thanks to Roy and Wolfgang for their comments.
>
> If anyone is interested, Guido will soon be ruling on a PEP which will
> change the behaviour of generators and generator expressions, and he has
> asked for feedback. In particular, examples of code which will be broken by
> this change.
>
> Read the PEP here:
>
> https://www.python.org/dev/peps/pep-0479
>
>
> If you post comments here, I will see that they get forwarded on.

I'm inclined to say that list comprehensions and generator expressions
should be different.  I don't really think they should be identical,
one being eager and one being lazy.  Why let the implementation detail
of one impact the other?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: caught in the import web again

[Dave Angel]

Ian Kelly  Wrote in message:
> On Mon, Nov 17, 2014 at 3:17 PM, Dave Angel  wrote:

>> In a module that might get tangled in a cycle, avoid global code
>>  that depends on other modules.  Instead of putting such
>>  initialization at top level, put inside a function that gets
>>  called after all suspect imports are completed. (That function
>>  has global keywords ).
> 
> If the problem is that one of those modules would import the current
> module, then "after all suspect imports are completed" basically means
> after the current module has finished importing. So what would be
> responsible for calling such a function?
> 

If one builds a set of modules that cannot avoid recursive
 imports, then one can ask the code that imports it to make a call
 after importing. Or all that is needed to avoid exposing the mess
 is that the top level not be part of the loops.

-- 
DaveA

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

Re: caught in the import web again

[Rick Johnson]

On Monday, November 17, 2014 4:46:05 PM UTC-6, Steven D'Aprano wrote:
> [...]
> Python is not Java, nor Perl, and if you're putting every
> class into its own file, you are doing it wrong.

Stop making these gross generalizations. Just because Java
*REQUIRES* that you only have one class per file does not
mean that having one class per file is *BAD*, or *WRONG* --
quite the contrary! You might as well join the endless hordes
that parrot off such ridiculous bile as:

* All republicans are racists!

or:

* All democrats are whiners!

or:

* All politicians are filthy nasty liars!

...that last one might be true though!

There are times when i have only one class in a file, but
there are other times when i have multiple classes per file

BUT NOT MANY TIMES!

AND NOT MANY CLASSES!

The number of classes per file is a very subjective matter
indeed, but in my opinion, the number should be kept as low
as possible, because, as the number of lines in a file
increases, your mental grasp of the contents decreases. I
don't care who you *THINK* you are, but your mental focus is
*NOT* infinite!

One of the problems inherent in "large file editing" is the
fact that since you are dealing with multiple namespaces,
there is great possibilities of different namespaces re-using
the same symbols. So for instance, if your searching in
"class A" for "symbolX", and "symbolX" also exists in "class
M", you're going to find yourself 1000 lines away from the
scope you intended to search, and now you have to trog back
up to your original spot!

BOY I LOVE TROGGING!

YES, YES, i know some of you have fancy editing tools with
"scoped search" abilities, but even *IF* you use such a
tool, you still must define the scope in some way --by
selecting a block of text or choosing from a predefined set
of scopes-- but in any event, you're just doing "new work"
(scoped search rules) to avoid doing "old work" (flipping
between windows), and although there is arguably no net gain
or loss between the two techniques *DIRECTLY*, the person
trying to wrangle a large file is more likely to loose
focus.

IT'S NOT A ZERO SUM GAME, SO *YOU* LOOSE!

The "one class per file rule" handles the "scoped search"
*IMPLICITLY* for me. When i'm in a file that contains only
one class, i know that i could never acidentally edit the
wrong symbol in *ANOTHER* class, and I don't need to define a
search area, no, all i need to do to "search", is to, well, 
*SEARCH*. 

WHAT A NOVEL IDEA!

Combining multiple classes into a single file is like
combining multiple drinking glasses into a single unit.
Imagine a wine glass, a beer mug, and a soda can joined with
a tight fitting rubber-band -- sure, you can carry the "unit"
comfortably with one hand, and you might impress your drunk
friends at the local pub with your new "beverage dispenser",
however, try drinking from the beer mug without getting
drenched with wine or sticky soda.

And even if you *DID* manage to drink the beer without
spilling the other two in the process, you would have to
expend so much *EXTRA* mental focus during the process that
you've undermined the usefulness of the combination.
Most times, the simplest solution is the best.

JUST DRINK FROM ONE GLASS AT A TIME YOU IDIOT!

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

Re: Different behaviour in list comps and generator expressions

[Ethan Furman]

On 11/17/2014 03:38 PM, Dan Stromberg wrote:
> 
> I'm inclined to say that list comprehensions and generator expressions
> should be different.  I don't really think they should be identical,
> one being eager and one being lazy.  Why let the implementation detail
> of one impact the other?

It's not the eagerness vs. laziness that's being changed, but rather what 
happens in a generator when something inside
the generator raises StopIteration (as opposed to the generator itself simply 
return'ing and thereby causing a
StopIteration to be generated).

--
~Ethan~



signature.asc
Description: OpenPGP digital signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: caught in the import web again

[Chris Angelico]

On Tue, Nov 18, 2014 at 1:17 PM, Rick Johnson
 wrote:
> BOY I LOVE TROGGING!

For consistency, you should say GOVE there.

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

New Python Course

[Steve Holden]

Hi everybody,

I am pleased to announce the availability of a Python Programming Skills Lab in 
London on December 9, 2014 in The Church House, Westminster. The blurb follows.

Led by Steve Holden, a well-known educator and member of the Python community, 
this one-day lab presents Python programmers with the opportunity to increase 
their Python skill level in a relatively short time. As an optional extra those 
registering can purchase two hours remote consulting, which can (for example) 
be used to address confidential issues unsuitable for discussion in class.

A little more detail about this development can be found at

http://holdenweb.blogspot.com/2014/11/a-new-python-class.html

and you can register at

http://pythonskills14121.eventbrite.com

I hope to see you there.

regards
-- 
Steve Holden st...@holdenweb.com +1 571 484 6266 @holdenweb



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

learn from the masters of python and other languages, free

[ed]

Hey all,

Wanted to let you know about a special opportunity for subscribers to this 
list..

I'm hosting a virtual conference called hack.summit() happening December 1-4, 
where you can learn from some of the best programmers in the world.  An 
unprecedented line-up of programmers are speaking, including creators of Ruby 
on Rails, CSS, Google Glass, the Java language spec, Agile, Extreme 
Programming, Test Driven Development, Heroku, Spark, Bittorrent, UML, the Wiki, 
and many more.

ALL proceeds go to support coding non-profits, such as ones that help drive 
inclusivity and diversity in the coding space.

I'm happy to offer you guys free passes to bypass the registration process and 
join for free.  Just visit hacksummit.org and register using the code 
REGISTERFREE.

Over 12,000 developers registered in the first few days -- if this continues, 
then this will be one of the largest developer events ever held.  You're not 
going to want to miss it.

Hope to see you at the summit, and thanks for your time :)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: caught in the import web again

[Michael Torrie]

On 11/17/2014 03:45 PM, Steven D'Aprano wrote:

> Circular dependencies are not just a problem in Python, they are a problem
> throughout most of software design.

Personally I find that duck typing eliminates a lot of the circular
dependency problems.  Class A doesn't necessarily have to know about
Class B to work with instances of Class B.  All that has to be known is
what methods are going to be available on those instances.  The
interface pattern can help here if you wanted a bit more safety (like
what Zope provides).  Either way it breaks up the dependency cycle nicely.

If Class A needs to instantiate instances of Class B (which depends on
Class A), then it could call a factory method to do so, perhaps set up
by a third party after both modules have been imported.

There are lots of methods of avoiding the issue entirely.

In the C or C++ world, I find that signalling frameworks can also be
used to break a dependency cycle.  For example, if Class A needs to call
a method on an instance of Class B (which in turn depends on Class A),
that could be done instead as a signal, which is later connected to
Class B's method after everything is successfully instantiated.  Also
makes testing a bit easier, because you can simply hook up the signals
to a test harness.

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

Re: caught in the import web again

[Steven D'Aprano]

On Mon, 17 Nov 2014 18:17:13 -0800, Rick Johnson wrote:

> BOY I LOVE TROGGING!

Yes, we've noticed.

http://www.urbandictionary.com/define.php?term=trogging




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

Re: How to fix those errors?

[Gregory Ewing]

Roy Smith wrote:

Wouldn't it make more sense to use four periods?

def spam(arg)
for x in seq
pass


Conversely, to save space you should be able to
stack one of the dots of an ellipsis on top and
write it as either .: or :.

Taking this even further, we could allow all
characters to be encoded in 90-degree-rotated
Braille. This would be a tremendous advantage
for blind or poorly-sighted Python users.

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

Re: How to fix those errors?

[Chris Angelico]

On Tue, Nov 18, 2014 at 6:25 PM, Gregory Ewing
 wrote:
> Taking this even further, we could allow all
> characters to be encoded in 90-degree-rotated
> Braille. This would be a tremendous advantage
> for blind or poorly-sighted Python users.

Indeed. However, which way should they be rotated? Clockwise or
counterclockwise? We would need a special encoding cookie, consisting
of the Braille encoding of "zero-width space", with a guarantee that
its inverted form will never be used to mean anything. Alternatively,
you could have programs attempt to autodetect the rotation used, which
will be perfect unless Bush hid the facts.

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