Raspberry model b --> program
Hi ! I have one small program that should be completed till tomorrow so if someone can help am ready to pay this ( btw. budget for this is $40 ). Project: - usb scanner is connected to the PI. - when the user gets his e.g. coffe bill with barcode, he put this bill in from of scanner and scanner reads value. If the value is the same as the value in database - GPIO is triggered and signal is send to relay board - relay board opens the parking ramp. The cash register PC and RPI are connected over lan cable and they are on the same network. When the compare is over we are deleting the file that is on the PC side but when the new bill will be created, the new csv file will be created too. So nothing special. One csv file with barcode is on the PC side and db is on the RPI side. What we have done so far: - part for reading the data from scanner - mysql db with defined tables - connection to DB - successful test for GPIO What i need: - to hook up all this together and to test it. RPI is connected to my PC over SSH so there is no problem to make some "remote programming" and testing. If there is someone who can help, i am willing to pay for this. G. -- https://mail.python.org/mailman/listinfo/python-list
Leo 5.0 alpha 2 released
Leo 5.0a2 is now available at: http://sourceforge.net/projects/leo/files/Leo/ Leo is a PIM, an IDE and an outliner. Video tutorials: http://leoeditor.com/screencasts.html Text tutorials: http://leoeditor.com/tutorial.html The highlights of Leo 5.0 -- * Better compatibility with vim, Emacs, pylint and PyQt: - Optional native emulation of vim commands. - Full support for Emacs org-mode outlines. - Better support for pylint. - Support for both PyQt4 and PyQt5. * Better handling of nodes containing large text: - Idle time syntax coloring eliminates delay. - Optional delayed loading of large text. * Power features: - Leo available via github repository. - File name completion. - Cloned nodes expand and contract independently. - @data nodes can be composed from descendant nodes. - No need to change Leo's main style sheet: it can be customized with @color and @font settings. - @persistence nodes save data in @auto trees. - A pluggable architecture for @auto nodes. - The style-reload command changes Leo's appearance instantly. * Important new plugins for tagging, display and node evaluation. * For beginners: - Leo's default workbook files contains Leo's quickstart guide. * Hundreds of new/improved features and bug fixes. Links: -- Leo: http://leoeditor.com Docs: http://leoeditor.com/leo_toc.html Tutorials: http://leoeditor.com/tutorial.html Videos:http://leoeditor.com/screencasts.html Forum: http://groups.google.com/group/leo-editor Download: http://sourceforge.net/projects/leo/files/ Github:https://github.com/leo-editor/leo-editor Quotes:http://leoeditor.com/testimonials.html -- https://mail.python.org/mailman/listinfo/python-list
Re: How do i reduce this to a single function - the code is largely similar, just a direction of search toggle.
On 11/7/14 9:52 AM, Veek M wrote:
Veek M wrote:
new_col = self.b[row].index('def')
self.w.cursor = row, new_col
new_col = self.b[row].rindex('def')
self.w.cursor = row, new_col
There's also the different methods index vs rindex. Does this sort of thing
justify two functions and associated infrastructure (it's for vim so 2 x 3
mode lines in my .vimrc)
Stepping back a bit from the lines of code, why do you need to use
.index in one case and .rindex in the other? You are trying to find the
"def" line in the editor buffer, either above the current point, or
below it. But the "def" will always be the first non-whitespace text on
the line. In fact, when searching upward, you could find this line:
def get_default(self):
and you want to end up on the "def" token, not the "def" in
"get_default". .rindex isn't what you want in any case. Use .index in
both cases.
--
Ned Batchelder, http://nedbatchelder.com
--
https://mail.python.org/mailman/listinfo/python-list
Re: Moving a window on the screen
"ast" writes:
> Ok, thx, it works now with:
>
> import tkinter
> fen = tkinter.Tk()
>
> x=0
>
> def moveW():
>global x
>fen.geometry("200x200+%d+10" % x)
>x = x + 10
>if (x < 1200):
>fen.after(50, moveW)
>
> moveW()
In general, to avoid the start time "drift" [1], you could lock the
execution with a timer e.g., to move the window from left to right
*delta_x* pixels at a time every *period* ms [2]:
#!/usr/bin/env python3
from time import monotonic
from tkinter import Tk
def timer():
return int(monotonic() * 1000) # milliseconds
def call_repeatedly(period, function, *args):
root.after(period - timer() % period, call_repeatedly, period,
function, *args) # schedule the next call
function(*args)
def move(delta_x, max_x, width=200, x=[0]):
root.geometry("%dx50+%d+100" % (width, x[0]))
x[0] += delta_x # poor man's object
if x[0] > (max_x - width):
root.destroy() # exit
root = Tk()
period = 20 # call every *period* milliseconds
delta_x = 2 # how many pixels to move at a time
root.after(period - period % timer(), call_repeatedly, period,
move, delta_x, root.winfo_screenwidth())
root.mainloop()
[1]:
http://stackoverflow.com/questions/8600161/executing-periodic-actions-in-python#comment26637231_8600301
[2]:
http://stackoverflow.com/questions/24174924/how-to-run-a-function-periodically-in-python
Akira
--
https://mail.python.org/mailman/listinfo/python-list
Re: Moving a window on the screen
On 11/8/2014 11:35 AM, Akira Li wrote:
"ast" writes:
Ok, thx, it works now with:
import tkinter
fen = tkinter.Tk()
x=0
def moveW():
global x
fen.geometry("200x200+%d+10" % x)
x = x + 10
if (x < 1200):
fen.after(50, moveW)
moveW()
In general, to avoid the start time "drift" [1],
which is hardly noticeable
you could lock the
execution with a timer e.g., to move the window from left to right
*delta_x* pixels at a time every *period* ms [2]:
On my Win7 machine, your complicated code is much worse as it causes the
window to jump about every half second
#!/usr/bin/env python3
from time import monotonic
from tkinter import Tk
def timer():
return int(monotonic() * 1000) # milliseconds
def call_repeatedly(period, function, *args):
root.after(period - timer() % period, call_repeatedly, period,
The '- timer() % period' 'correction' is wrong when not 0 as it causes
jumps.
function, *args) # schedule the next call
function(*args)
def move(delta_x, max_x, width=200, x=[0]):
root.geometry("%dx50+%d+100" % (width, x[0]))
x[0] += delta_x # poor man's object
if x[0] > (max_x - width):
root.destroy() # exit
root = Tk()
period = 20 # call every *period* milliseconds
delta_x = 2 # how many pixels to move at a time
root.after(period - period % timer(), call_repeatedly, period,
'period % timer()' is nonsensical as timer() is arbitrary. It will
typically be 0 anyway. 'after(0, ...)' works fine.
move, delta_x, root.winfo_screenwidth())
root.mainloop()
[1]:
http://stackoverflow.com/questions/8600161/executing-periodic-actions-in-python#comment26637231_8600301
[2]:
http://stackoverflow.com/questions/24174924/how-to-run-a-function-periodically-in-python
Akira
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
Re: FYI: Micro Python running on kickstarter pyBoard project, now shipping
On Thursday, 23 October 2014 22:12:10 UTC+1, sohca...@gmail.com wrote: > On Thursday, October 23, 2014 10:07:26 AM UTC-7, jkn wrote: > > Hi all > > I haven't heard in mentioned here, but since I saw one of the boards > > today thought I'd pass on the news: > > > > The Kickstarter 'MicroPython' project, which has a tiny 'pyboard' (only a > > couple of sq.inches in size) with a processor running 'a complete re-write > > of the Python (version 3.4) programming language so that it fits and runs > > on a microcontroller' is now shipping. > > > > https://micropython.org/ > > > > Looks nice; I have no connection but will be getting one myself to play > > with... > > > > Cheers > > J^n > > > Is there any particular reason to get one of these when I can get a Raspberry > Pi which is faster, has more memory, and a bundle of other features? > > I mean, the idea seems cool and all, but I'm trying to understand why I would > want to spend the ~$45 on something like that when a ~$35 Raspberry Pi will > do everything and more, and do it faster. They are quite different devices: * The Raspberry Pi is a low-power general purpose computer designed specifically for education purposes. It just so happens that it's ideal for geek experimentation as well... * MicroPython is an optimised version of Python 3 running on a micro-controller board, designed specifically for controlling 'things' (eg robots). Doing what it is designed for, it will run far faster and use far less power than a Pi, but cannot do any of the general computing things a Pi can do, for example it has no means of editing programs for MicroPython, you have to do this on, say, your PC and download them to the MicroPython board. It won't do *any* of the other things you can do with a Pi - watch videos, browse the net, etc etc, but what it can do it will do faster and better. If you want a low-power, cheap, computer to play with and learn from, get a Pi. If you want a nifty micro-controller you can program in Python, buy a MicroPython board. John -- -- https://mail.python.org/mailman/listinfo/python-list
Re: [Python-Dev] Dinamically set __call__ method
On 11/07/2014 10:50 PM, dieter wrote: Ethan Furman writes: On 11/06/2014 10:59 PM, dieter wrote: John Ladasky writes: On Tuesday, November 4, 2014 11:12:31 AM UTC-8, Ethan Furman wrote: If you really absolutely positively have to have the signature be correct for each instance, you may to either look at a function creating factory, a class creating factory, or a meta-class. +1. Overriding __call__() within the class definition, over and over again, with different function, looks awkward to me. A possibility to get the original approach implemented looks like: make "__call__" a descriptor on the class which looks up the real method on the instance. This still wouldn't get the signatrue correct, though. Why not? Once the descriptor is resolved, you get the final instance method - with the correct signature. Hmmm... well, it wouldn't be correct on a class lookup, but, yeah, it would be correct for an instance lookup -- and maybe that's good enough for the OP. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: Moving a window on the screen
Terry Reedy writes:
> On 11/8/2014 11:35 AM, Akira Li wrote:
>> "ast" writes:
>>
>>> Ok, thx, it works now with:
>>>
>>> import tkinter
>>> fen = tkinter.Tk()
>>>
>>> x=0
>>>
>>> def moveW():
>>> global x
>>> fen.geometry("200x200+%d+10" % x)
>>> x = x + 10
>>> if (x < 1200):
>>> fen.after(50, moveW)
>>>
>>> moveW()
>>
>> In general, to avoid the start time "drift" [1],
>
> which is hardly noticeable
Do you mean hardly noticeable for these particular *period*, delta_x and
(small) fixed number of repeatitions?
That is why I said, "in general".
The link [1] that I've provided contains an example where it *is*
noticable.
>> you could lock the
>> execution with a timer e.g., to move the window from left to right
>> *delta_x* pixels at a time every *period* ms [2]:
>
> On my Win7 machine, your complicated code is much worse as it causes
> the window to jump about every half second
Could you add print(timer()) inside move(), to see the values? What
happens if you increase the period to 100 ms?
>>#!/usr/bin/env python3
>>from time import monotonic
>>from tkinter import Tk
>>
>>def timer():
>>return int(monotonic() * 1000) # milliseconds
>>
>>def call_repeatedly(period, function, *args):
>>root.after(period - timer() % period, call_repeatedly, period,
>
> The '- timer() % period' 'correction' is wrong when not 0 as it causes
> jumps.
The formula is correct. It is obvious if you make the period one second
(1000ms) and print the timer() values (in milliseconds):
52002
53000
54000
55000
56001
57000
58000
59001
60001
61000
62000
...
As you can see the start time is locked with the timer: the function is
called at whole seconds. Individual calls may happens slightly sooner or
later but the timing doesn't drift, the difference
between the expected start time and the actual start time is 1ms:
>>> M[0], M[-1], M[0] + 1000*(len(M)-1)
(52002, 224001, 224002)
Here's the same thing if I remove the locking `-timer() % period` and
use just `root.after(period, call..)`:
34235
35236
36236
37236
38236
39237
40237
41237
42237
43238
44238
45238
46238
47239
48239
...
The start time drifts:
>>> L[0], L[-1], L[0] + 1000*(len(L)-1)
(34235, 206279, 206235)
the difference between the expected start time and the actual start time
is 44ms (4400% worse than the previous method).
I agree, for the purpose of moving a window on the screen, the
difference doesn't matter though if it is a GUI clock then you should
not ignore it otherwise it will be wrong by a minute in a couple of
days.
>> function, *args) # schedule the next call
>>function(*args)
>>
>>def move(delta_x, max_x, width=200, x=[0]):
>>root.geometry("%dx50+%d+100" % (width, x[0]))
>>x[0] += delta_x # poor man's object
>>if x[0] > (max_x - width):
>>root.destroy() # exit
>>
>>root = Tk()
>>period = 20 # call every *period* milliseconds
>>delta_x = 2 # how many pixels to move at a time
>>root.after(period - period % timer(), call_repeatedly, period,
>
> 'period % timer()' is nonsensical as timer() is arbitrary. It will
> typically be 0 anyway. 'after(0, ...)' works fine.
>
It is a bug (the terms are swapped by mistake). Thank you for
noticing. It should be `timer() % period` instead. The same expression
as used in the call_repeatedly() and in the link [2] that I've provided.
`period - timer() % period` is used here to make the first start time at
the exact boundary so there is the same interval between function(*args) calls.
[1]:
http://stackoverflow.com/questions/8600161/executing-periodic-actions-in-python#comment26637231_8600301
[2]:
http://stackoverflow.com/questions/24174924/how-to-run-a-function-periodically-in-python
Akira
--
https://mail.python.org/mailman/listinfo/python-list
Engaging, powerful - video inspriration/learning - Your best selections
Morning Have you seen any python videos that were part of a series or that were from a conference that you found engaging and made a point click or solidify a concept or drive you to action to create something you wanted. That took an advanced topic or concept and made it clear as day to you. I have watched some Scipy conf videos which I really appreciated though some of the subject matter was over my technical level. Jessica McKellar did a great talk on the future of python. http://pyvideo.org/video/2375/the-future-of-python-a-choose-your-own-adventur Looking forward to see what videos engaged and drove your passion and increased your skills. Live engaged sayth -- https://mail.python.org/mailman/listinfo/python-list
Re: Leo 5.0 alpha 2 released
On Saturday, 8 November 2014 23:26:20 UTC+11, edre...@gmail.com wrote: > Leo 5.0a2 is now available at: > http://sourceforge.net/projects/leo/files/Leo/ > > Leo is a PIM, an IDE and an outliner. > Video tutorials: http://leoeditor.com/screencasts.html > Text tutorials: http://leoeditor.com/tutorial.html > > The highlights of Leo 5.0 > -- > > * Better compatibility with vim, Emacs, pylint and PyQt: > - Optional native emulation of vim commands. > - Full support for Emacs org-mode outlines. > - Better support for pylint. > - Support for both PyQt4 and PyQt5. > * Better handling of nodes containing large text: > - Idle time syntax coloring eliminates delay. > - Optional delayed loading of large text. > * Power features: > - Leo available via github repository. > - File name completion. > - Cloned nodes expand and contract independently. > - @data nodes can be composed from descendant nodes. > - No need to change Leo's main style sheet: > it can be customized with @color and @font settings. > - @persistence nodes save data in @auto trees. > - A pluggable architecture for @auto nodes. > - The style-reload command changes Leo's appearance instantly. > * Important new plugins for tagging, display and node evaluation. > * For beginners: > - Leo's default workbook files contains Leo's quickstart guide. > * Hundreds of new/improved features and bug fixes. > > Links: > -- > Leo: http://leoeditor.com > Docs: http://leoeditor.com/leo_toc.html > Tutorials: http://leoeditor.com/tutorial.html > Videos:http://leoeditor.com/screencasts.html > Forum: http://groups.google.com/group/leo-editor > Download: http://sourceforge.net/projects/leo/files/ > Github:https://github.com/leo-editor/leo-editor > Quotes:http://leoeditor.com/testimonials.html I tried to learn that is understand how Leo benefited me. There must be a click and aha moment with this editor, I never made it there. Having said that i got proficient with vim but not quite with that either. I use brackets currently. Have a great day Sayth -- https://mail.python.org/mailman/listinfo/python-list
Re: Different behaviour in list comps and generator expressions
On 08.11.2014 02:50, 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. Generator expressions consume them and halt, while comprehensions allow them to leak out. This is not the right description of what's happening. It is not the generator expression that consumes it, but the list constructor and, of course, list can't tell at which level in the inside code StopIteration got raised. So, yes this had me confused some times, too, but it is really not surprising. A simple example: iterable = [iter([])] list(next(x) for x in iterable) => returns [] But: [next(x) for x in iterable] => raises StopIteration Yes, but the equivalent to list(next(x) for x in iterable) is: l = [] for item in (next(x) for x in iterable): l.append(item) => returns [] because the for consumes the StopIteration this, on the other hand raises StopIteration l = [] for item in [next(x) for x in iterable]: l.append(item) because the error gets raised already when for causes iter() to be called on the list comprehension. Has anyone come across this difference in the wild? Was it a problem? Do you rely on that difference, or is it a nuisance? Has it caused difficulty in debugging code? If you had to keep one behaviour, which would you keep? The point is: there is no difference in the behavior of comprehensions and generator expressions, it is just how you access them: for anything that follows the iterator protocol, a comprehension (since it is evaluated immediately) raises during the iter() phase, while a generator expression (which gets evaluated lazily) raises during the next() phase where it gets swallowed. So in your example you would have to use the silly list([next(x) for x in iterable]) if you want the error to get raised. I agree this is all rather non-intuitive, but how would you change it ? -- https://mail.python.org/mailman/listinfo/python-list
Re: [Python-Dev] Dinamically set __call__ method
Ethan Furman wrote:
On 11/06/2014 10:59 PM, dieter wrote:
A possibility to get the original approach implemented looks like:
make "__call__" a descriptor on the class which looks up the real
method on the instance.
This still wouldn't get the signatrue correct, though.
Why not? Once the descriptor is resolved, you get the final
instance method - with the correct signature.
Hmmm... well, it wouldn't be correct on a class lookup, but, yeah, it
would be correct for an instance lookup -- and maybe that's good enough
for the OP.
Seems to depend on how you get hold of the object you're
inspecting the signature of. I did an experiment:
class C(object):
@property
def __call__(self):
return self.call
def f(x, y):
print("Called f with %s, %s" % (x, y))
c = C()
c.call = f
c(17, 42)
prints:
Called f with 17, 42
This works too:
import inspect
print(inspect.getargspec(c.__call__))
prints:
ArgSpec(args=['x', 'y'], varargs=None, keywords=None, defaults=None)
But
print(inspect.getargspec(c))
doesn't work:
TypeError: <__main__.C object at 0x479250> is not a Python function
(BTW, I'm actually surprised that this technique makes c callable.
There must be more going on that just "look up __call__ in the class
object", because evaluating C.__call__ just returns the descriptor
and doesn't invoking the descriptor mechanism.)
--
Greg
--
https://mail.python.org/mailman/listinfo/python-list
Re: Different behaviour in list comps and generator expressions
On 08.11.2014 22:31, Wolfgang Maier wrote: On 08.11.2014 02:50, 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. Generator expressions consume them and halt, while comprehensions allow them to leak out. This is not the right description of what's happening. It is not the generator expression that consumes it, but the list constructor and, of course, list can't tell at which level in the inside code StopIteration got raised. So, yes this had me confused some times, too, but it is really not surprising. A simple example: iterable = [iter([])] list(next(x) for x in iterable) => returns [] But: [next(x) for x in iterable] => raises StopIteration Yes, but the equivalent to list(next(x) for x in iterable) is: l = [] for item in (next(x) for x in iterable): l.append(item) => returns [] because the for consumes the StopIteration this, on the other hand raises StopIteration l = [] for item in [next(x) for x in iterable]: l.append(item) because the error gets raised already when for causes iter() to be called on the list comprehension. Has anyone come across this difference in the wild? Was it a problem? Do you rely on that difference, or is it a nuisance? Has it caused difficulty in debugging code? If you had to keep one behaviour, which would you keep? The point is: there is no difference in the behavior of comprehensions and generator expressions, it is just how you access them: for anything that follows the iterator protocol, a comprehension (since it is evaluated immediately) raises during the iter() phase, while a generator expression (which gets evaluated lazily) raises during the next() phase where it gets swallowed. So in your example you would have to use the silly list([next(x) for x in iterable]) if you want the error to get raised. I agree this is all rather non-intuitive, but how would you change it ? Ah, I came across the related thread on python-ideas only now and from this I can see that, as I expected, you know everything I've written above already. In light of the discussion on the other list: I did find it annoying occasionally that raising StopIteration inside a generator expression conveys a different behavior than elsewhere. It did take me quite a while to understand why that is so, but after that it did not cause me much of a headache anymore. I would say that Guido's suggestion of transforming StopIteration raised inside a generator into some other error to eliminate ambiguity would really help in some situations, but then I'm not sure whether that's worth breaking existing code. Best, Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Syncing audio and video for casual recording
I decided I'd like to publish some youtube videos of me playing an instrument. The audio being the important bit, I'd like to use my existing mics, which I've been sending through a USB audio interface to my computer. I don't have any camera yet, other than a prosumer digital camera that does take decent video. The problem that I'm anticipating is the syncing of audio and video. Now, I do have a Tascam recorder with timecode, so maybe that's one way to approach this. I'm just guessing that any camera that has this would be expensive, but I didn't find out much in a very quick search. Aside from that, could I feed a decent audio signal into the camera and get the audio in that way? I've never done any video, so I'm quite in the dark about the camera part. Thanks, Tobiah --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- https://mail.python.org/mailman/listinfo/python-list
Re: [Python-Dev] Dinamically set __call__ method
On 11/08/2014 02:31 PM, Gregory Ewing wrote:
Seems to depend on how you get hold of the object you're
inspecting the signature of. I did an experiment:
class C(object):
@property
def __call__(self):
return self.call
def f(x, y):
print("Called f with %s, %s" % (x, y))
c = C()
c.call = f
c(17, 42)
prints:
Called f with 17, 42
This works too:
import inspect
print(inspect.getargspec(c.__call__))
prints:
ArgSpec(args=['x', 'y'], varargs=None, keywords=None, defaults=None)
But
print(inspect.getargspec(c))
doesn't work:
TypeError: <__main__.C object at 0x479250> is not a Python function
(BTW, I'm actually surprised that this technique makes c callable.
There must be more going on that just "look up __call__ in the class
object", because evaluating C.__call__ just returns the descriptor
and doesn't invoking the descriptor mechanism.)
Looks like you found a bug in inspect.getargspec.
And the thing going on is the normal python behavior (in __getattribute__, I believe) of examining the returned
attribute to see if it is a descriptor, and if so invoking it.
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
Re: FYI: Micro Python running on kickstarter pyBoard project, now shipping
On 11/8/2014 2:41 PM, John Pinner wrote: They are quite different devices: * The Raspberry Pi is a low-power general purpose computer designed specifically for education purposes. It just so happens that it's ideal for geek experimentation as well... * MicroPython is an optimised version of Python 3 running on a micro-controller board, designed specifically for controlling 'things' (eg robots). Doing what it is designed for, it will run far faster and use far less power than a Pi, but cannot do any of the general computing things a Pi can do, for example it has no means of editing programs for MicroPython, you have to do this on, say, your PC and download them to the MicroPython board. It won't do *any* of the other things you can do with a Pi - watch videos, browse the net, etc etc, but what it can do it will do faster and better. If you want a low-power, cheap, computer to play with and learn from, get a Pi. If you want a nifty micro-controller you can program in Python, buy a MicroPython board. Nicely explained. Thank you. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
