UI error for pycharm
when I run py script in pycharm for UI
Code:
import from PySide.QtCore import * from PySide.QtGui import * import urllib2
class Form(QDialog): def __init__(self, parent=None): super(Form,
self).__init__(parent) date = self.getdata() rates = sorted(self.rates.keys())
dateLabel = QLabel(date) self.fromComboBox = QComboBox()
self.fromComboBox.addItems(rates) self.fromSpinBox = QDoubleSpinBox()
self.fromSpinBox.setRange(0.01, 1000.00) self.fromSpinBox.setValue(1.00)
self.toComboBox = QComboBox() self.toComboBox.addItems(rates) self.toLabel =
QLabel("1.00") grid = QGridLayout() grid.addWidget(dateLabel, 0, 0)
grid.addWidget(self.fromComboBox, 1, 0) grid.addWidget(self.fromSpinBox, 1, 1)
grid.addWidget(self.toComboBox, 2, 0) grid.addWidget(self.toLabel, 2, 1)
self.setLayout(grid) self.connect(self.fromComboBox,
SIGNAL("currentIndexChanged(int)"), self.updateUi)
self.connect(self.toComboBox, SIGNAL("currentIndexChanged(int)"),
self.updateUi) self.connect(self.fromSpinBox, SIGNAL("valueChanged(double)"),
self.updateUi) def updateUi
(self): to = self.toComboBox.currentText() from_ =
self.fromComboBox.currentText() amount = (self.rates[from_] / self.rates[to]) *
self.fromSpinBox.value() self.toLabel.setText("%0.2f" % amount) def
getdata(self): self.rates = {} try: date = "Unknown" fh =
urllib2.urlopen("http://www.bankofcanada.ca/en/markets/csv/exchange_eng.csv";)
for line in fh: line = line.rstrip() if not line or line.startswith(("#",
"Closing")): continue fields = line.split(",") if line.startswith("Date "):
date = fields[-1] else: try: value = float(fields[-1]) self.rates[fields[0]] =
value except ValueError: pass return "Exchange rates date: " + date except
Exception, e: return "Failued to download:\n%s" % e app =
QApplication(sys.argv) form = Form() form.show() app.exec_()
I had this error , how to fix them ?
Code:
C:\Python27\python.exe "C:/Users/denial/PycharmProjects/currency
project/alarm.py"
Traceback (most recent call last):
File "C:/Users/denial/PycharmProjects/currency project/alarm.py", line 2, in
from PySide.QtCore import *
ImportError: No module named PySide.QtCore
Process finished with exit code 1
--
http://mail.python.org/mailman/listinfo/python-list
Re: UI error for pycharm
Le 24/11/12 11:20, bakie a écrit :
> when I run py script in pycharm for UI
>
>
> Code:
> import from PySide.QtCore import * from PySide.QtGui import * import urllib2
> class Form(QDialog): def __init__(self, parent=None): super(Form,
> self).__init__(parent) date = self.getdata() rates =
> sorted(self.rates.keys()) dateLabel = QLabel(date) self.fromComboBox =
> QComboBox() self.fromComboBox.addItems(rates) self.fromSpinBox =
> QDoubleSpinBox() self.fromSpinBox.setRange(0.01, 1000.00)
> self.fromSpinBox.setValue(1.00) self.toComboBox = QComboBox()
> self.toComboBox.addItems(rates) self.toLabel = QLabel("1.00") grid =
> QGridLayout() grid.addWidget(dateLabel, 0, 0)
> grid.addWidget(self.fromComboBox, 1, 0) grid.addWidget(self.fromSpinBox, 1,
> 1) grid.addWidget(self.toComboBox, 2, 0) grid.addWidget(self.toLabel, 2, 1)
> self.setLayout(grid) self.connect(self.fromComboBox,
> SIGNAL("currentIndexChanged(int)"), self.updateUi)
> self.connect(self.toComboBox, SIGNAL("currentIndexChanged(int)"),
> self.updateUi) self.connect(self.fromSpinBox, SIGNAL("valueChanged(double)"),
> self.updateUi) def
> updateUi
> (self): to = self.toComboBox.currentText() from_ =
> self.fromComboBox.currentText() amount = (self.rates[from_] / self.rates[to])
> * self.fromSpinBox.value() self.toLabel.setText("%0.2f" % amount) def
> getdata(self): self.rates = {} try: date = "Unknown" fh =
> urllib2.urlopen("http://www.bankofcanada.ca/en/markets/csv/exchange_eng.csv";)
> for line in fh: line = line.rstrip() if not line or line.startswith(("#",
> "Closing")): continue fields = line.split(",") if line.startswith("Date "):
> date = fields[-1] else: try: value = float(fields[-1]) self.rates[fields[0]]
> = value except ValueError: pass return "Exchange rates date: " + date except
> Exception, e: return "Failued to download:\n%s" % e app =
> QApplication(sys.argv) form = Form() form.show() app.exec_()
>
>
> I had this error , how to fix them ?
>
> Code:
> C:\Python27\python.exe "C:/Users/denial/PycharmProjects/currency
> project/alarm.py"
> Traceback (most recent call last):
> File "C:/Users/denial/PycharmProjects/currency project/alarm.py", line 2,
> in
> from PySide.QtCore import *
> ImportError: No module named PySide.QtCore
>
> Process finished with exit code 1
Install PySide.
--
Vincent V.V.
Oqapy . Qarte
. PaQager
--
http://mail.python.org/mailman/listinfo/python-list
Re: UI error for pycharm
which version can i install / http://qt-project.org/downloads -- http://mail.python.org/mailman/listinfo/python-list
Re: UI error for pycharm
i used window 7 , 64 bits -- http://mail.python.org/mailman/listinfo/python-list
Resize RGB image?
I can resize a 2d image "im" with a command something like: r,c = shape(im) im2 = resize(im,(r//2,c//2)) However, resize doesn't seem to work with an RGB image: r,c,n = shape(im) # returns, say 500 600 3 I then need to take each band separately, resize it, and put them all back together with dstack: imr = im[:,:,0] img = im[:,:,1] imb = im[:,:,2] imr2 = resize(imr,(r//2,c//2)) img2 = resize(img,(r//2,c//2)) imb2 = resize(imb,(r//2,c//2)) im2 = dstack((imr2,img2,imb2)) This works fine, but seems a little clumsy. Of course this could be done in one command: im2 = dstack([resize(im[:,:,i],(r//2,c//2)) for i in range(3)]) What I want to know is: is there a version of resize which can be applied directly to multi-band images, without having to apply to each band separately? Thanks, Alasdair -- http://mail.python.org/mailman/listinfo/python-list
Re: UI error for pycharm
I got it , Ur anser is right . use that links http://www.lfd.uci.edu/~gohlke/pythonlibs/ ( unofficial libriares ) -- http://mail.python.org/mailman/listinfo/python-list
Re: Resize RGB image?
On 11/24/2012 06:14 AM, Alasdair McAndrew wrote: > I can resize a 2d image "im" with a command something like: > > r,c = shape(im) > im2 = resize(im,(r//2,c//2)) You're missing at least one import there. So how about you start by telling us what non-standard libraries you're using, what version of python you're using, and what OS ? Then supply us a working set of code, in the sense that people can see the problem you're complaining about. > However, resize doesn't seem to work with an RGB image: > > r,c,n = shape(im) # returns, say 500 600 3 Doesn't work is pretty vague. It could mean anything from "it makes the image too small by 1%" to "it crashes my system after reformatting my hard disk." If you get an error, include the entire traceback here. If it doesn't work in some other sense, > I then need to take each band separately, resize it, and put them all back > together with dstack: > > imr = im[:,:,0] > img = im[:,:,1] > imb = im[:,:,2] > imr2 = resize(imr,(r//2,c//2)) > img2 = resize(img,(r//2,c//2)) > imb2 = resize(imb,(r//2,c//2)) > im2 = dstack((imr2,img2,imb2)) > > This works fine, but seems a little clumsy. Of course this could be done in > one command: > > im2 = dstack([resize(im[:,:,i],(r//2,c//2)) for i in range(3)]) > > What I want to know is: is there a version of resize which can be applied > directly to multi-band images, without having to apply to each band > separately? > > Thanks, > Alasdair -- DaveA -- http://mail.python.org/mailman/listinfo/python-list
only .exe
in the last question I try how to run py script with pycharm . thank dear bro ... and then I wanna have that program with .exe ( standalone installer ) . How can i do that ? I tried with two ways 1) py2exe 2) cx_freeze but I don't like that It has many file when i complie my script . which way for .exe ( standalone installer ) from pycharm . Thanks U brothers -- http://mail.python.org/mailman/listinfo/python-list
Re: Resize RGB image?
On 11/24/2012 06:37 AM, Dave Angel wrote: Oops, I sent before I was done editing. Corrections below. > On 11/24/2012 06:14 AM, Alasdair McAndrew wrote: >> I can resize a 2d image "im" with a command something like: >> >> r,c = shape(im) >> im2 = resize(im,(r//2,c//2)) > You're missing at least one import there. > > So how about you start by telling us what non-standard libraries you're > using, what version of python you're using, and what OS ? Then supply > us a working set of code, in the sense that people can see the problem > you're complaining about. > >> However, resize doesn't seem to work with an RGB image: >> >> r,c,n = shape(im) # returns, say 500 600 3 > Doesn't work is pretty vague. It could mean anything from "it makes the > image too small by 1%" to "it crashes my system after reformatting my > hard disk." If you get an error, include the entire traceback here. If > it doesn't work in some other sense, then tell us what you expected, and what it did wrong. In this case, you might have to supply us with a link to sample data that demonstrates the problem. > >> I then need to take each band separately, resize it, and put them all back >> together with dstack: >> >> imr = im[:,:,0] >> img = im[:,:,1] >> imb = im[:,:,2] >> imr2 = resize(imr,(r//2,c//2)) >> img2 = resize(img,(r//2,c//2)) >> imb2 = resize(imb,(r//2,c//2)) >> im2 = dstack((imr2,img2,imb2)) >> >> This works fine, but seems a little clumsy. Of course this could be done in >> one command: >> >> im2 = dstack([resize(im[:,:,i],(r//2,c//2)) for i in range(3)]) >> >> What I want to know is: is there a version of resize which can be applied >> directly to multi-band images, without having to apply to each band >> separately? >> >> Thanks, >> Alasdair > -- DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: only .exe
Am 24.11.12 12:36, schrieb bakie: in the last question I try how to run py script with pycharm . thank dear bro ... and then I wanna have that program with .exe ( standalone installer ) . How can i do that ? I tried with two ways 1) py2exe 2) cx_freeze but I don't like that It has many file when i complie my script . which way for .exe ( standalone installer ) from pycharm . Thanks U brothers U cn trI to ask Ur ?n in readble English pyinstaller has a switch to make a single file executable, if that's what you are after. Christian -- http://mail.python.org/mailman/listinfo/python-list
Re: Resize RGB image?
On Sat, Nov 24, 2012 at 4:14 AM, Alasdair McAndrew wrote: > I can resize a 2d image "im" with a command something like: > > r,c = shape(im) > im2 = resize(im,(r//2,c//2)) > > However, resize doesn't seem to work with an RGB image: > > r,c,n = shape(im) # returns, say 500 600 3 > > I then need to take each band separately, resize it, and put them all back > together with dstack: > > imr = im[:,:,0] > img = im[:,:,1] > imb = im[:,:,2] > imr2 = resize(imr,(r//2,c//2)) > img2 = resize(img,(r//2,c//2)) > imb2 = resize(imb,(r//2,c//2)) > im2 = dstack((imr2,img2,imb2)) > > This works fine, but seems a little clumsy. Of course this could be done in > one command: > > im2 = dstack([resize(im[:,:,i],(r//2,c//2)) for i in range(3)]) > > What I want to know is: is there a version of resize which can be applied > directly to multi-band images, without having to apply to each band > separately? You appear to be using numpy for this, which is a numerical library, not specifically an image-processing library. I would suggest using a library more suited for the task, such as PIL. I don't think that resize calls above are doing what you want in any case. They're not going to do scaling with interpolation, as is usually intended when resizing an image. They're just taking as much of the data as will fit (i.e., the first (r//2 * c//2) bytes) and packing it into the new array in the requested shape. -- http://mail.python.org/mailman/listinfo/python-list
Re: Resize RGB image?
Thank you for your speedy response! And yes, I was too hasty in firing off a
request without the necessary details.
And in fact the resize from the PIL Image module does work:
f = Image.open('bird-of-paradise-flower-1.jpg')
r,c = f.size
f2 = f.resize((r//2,c//2))
f2.show()
shape(f) # returns(768, 1024, 3)
shape(f2) # returns (384, 512, 3)
I think I was confused about all the different "resize" methods floating about.
Clearly I had been using the wrong one! But if f is defined - as I've just
done - as an Image image, then it will use the correct resize method.
I'll crawl back under my rock now.
-Alasdair
--
http://mail.python.org/mailman/listinfo/python-list
Re: Suitable software stacks for simple python web service
On Thursday, November 22, 2012 1:42:42 AM UTC-5, Kev Dwyer wrote: > Steve Petrie wrote: > > > > > On Wednesday, November 21, 2012 2:32:40 AM UTC-5, Kev Dwyer wrote: > > >> Hello List, > > >> > > >> > > >> > > >> I have to build a simple web service which will: > > >> > > >> > > >> > > >> - receive queries from our other servers > > >> > > >> - forward the requests to a third party SOAP service > > >> > > >> - process the response from the third party > > >> > > >> - send the result back to the original requester > > >> > > >> > > >> > > >> >From the point of view of the requester, this will happen within the > > >> >scope > > >> > > >> of a single request. > > >> > > >> > > >> > > >> The data exchanged with the original requester will likely be encoded as > > >> > > >> JSON; the SOAP service will be handled by SUDS. > > >> > > >> > > >> > > >> The load is likely to be quite light, say a few requests per hour, though > > >> > > >> this may increase in the future. > > >> > > >> > > >> > > >> Given these requirements, what do you think might be a suitable software > > >> > > >> stack, i.e. webserver and web framework (if a web framework is even > > >> > > >> necessary)? > > >> > > >> > > >> > > >> Candidates should be compatible with Python2.7, though I'd be happy to > > >> > > >> consider Python 3 if anyone knows of a Python3 SOAP library that has good > > >> > > >> WSDL support. > > >> > > >> > > >> > > >> Cheers, > > >> > > >> > > >> > > >> Kev > > > > > > I'm using the Bottle web framework (http://bottlepy.org) to integrate > > > requests and replies originating in a Drupal site, a Beanstream (payment > > > processor) account, and a Salesforce instance. > > > > > > Communication with Salesforce is done through the Salesforce Python > > > Toolkit (http://code.google.com/p/salesforce-python-toolkit/), which uses > > > Suds. > > > > > > Communication with the Drupal site uses Python's (and PHP's on the Drupal > > > side) native JSON support. > > > > > > This is under Python 2.6.8 and Apache 2.2.23 running on an AWS EC2 > > > instance. > > > > > > No (major) problems so far, though still in the early stages of this > > > project. > > > > > > Steve > > > > > > > > > > > > I chose Bottle after trying a few other frameworks because, well, I can't > > > remember exactly why, though thinking back it's probably because of the > > > clarity of Bottle's approach and the simplicity of the documentation. > > > > > > Hello Steve, > > > > Thanks for your comment. > > > > I'm curious, did you consider any web servers other than Apache? > > > > Kev You're telling me that there are other web servers? ;) I didn't try any others seriously, no. My experience is with Apache and IIS, and I try to stay away from Windows. I should mention, given Dieter Maurer's comment, that Bottle is a (fairly thin) layer built over WSGI. I've built applications directly over WSGI as well; that's another way to go, it's quite straightforward. mod_python is no longer supported: http://blog.dscpl.com.au/2010/05/modpython-project-soon-to-be-officially.html. -- http://mail.python.org/mailman/listinfo/python-list
Re: Suitable software stacks for simple python web service
Steve Petrie wrote: > On Thursday, November 22, 2012 1:42:42 AM UTC-5, Kev Dwyer wrote: >> Steve Petrie wrote: >> >> >> >> > On Wednesday, November 21, 2012 2:32:40 AM UTC-5, Kev Dwyer wrote: >> >> >> Hello List, >> >> >> >> >> >> >> >> >> >> >> >> I have to build a simple web service which will: >> >> >> >> >> >> >> >> >> >> >> >> - receive queries from our other servers >> >> >> >> >> >> - forward the requests to a third party SOAP service >> >> >> >> >> >> - process the response from the third party >> >> >> >> >> >> - send the result back to the original requester >> >> >> >> >> >> >> >> >> >> >> >> >From the point of view of the requester, this will happen within the >> >> >> >scope >> >> >> >> >> >> of a single request. >> >> >> >> >> >> >> >> >> >> >> >> The data exchanged with the original requester will likely be encoded >> >> as >> >> >> >> >> >> JSON; the SOAP service will be handled by SUDS. >> >> >> >> >> >> >> >> >> >> >> >> The load is likely to be quite light, say a few requests per hour, >> >> though >> >> >> >> >> >> this may increase in the future. >> >> >> >> >> >> >> >> >> >> >> >> Given these requirements, what do you think might be a suitable >> >> software >> >> >> >> >> >> stack, i.e. webserver and web framework (if a web framework is even >> >> >> >> >> >> necessary)? >> >> >> >> >> >> >> >> >> >> >> >> Candidates should be compatible with Python2.7, though I'd be happy to >> >> >> >> >> >> consider Python 3 if anyone knows of a Python3 SOAP library that has >> >> good >> >> >> >> >> >> WSDL support. >> >> >> >> >> >> >> >> >> >> >> >> Cheers, >> >> >> >> >> >> >> >> >> >> >> >> Kev >> >> > >> >> > I'm using the Bottle web framework (http://bottlepy.org) to integrate >> >> > requests and replies originating in a Drupal site, a Beanstream >> > (payment >> >> > processor) account, and a Salesforce instance. >> >> > >> >> > Communication with Salesforce is done through the Salesforce Python >> >> > Toolkit (http://code.google.com/p/salesforce-python-toolkit/), which >> > uses >> >> > Suds. >> >> > >> >> > Communication with the Drupal site uses Python's (and PHP's on the >> > Drupal >> >> > side) native JSON support. >> >> > >> >> > This is under Python 2.6.8 and Apache 2.2.23 running on an AWS EC2 >> >> > instance. >> >> > >> >> > No (major) problems so far, though still in the early stages of this >> >> > project. >> >> > >> >> > Steve >> >> > >> >> > >> >> > >> >> > I chose Bottle after trying a few other frameworks because, well, I >> > can't >> >> > remember exactly why, though thinking back it's probably because of the >> >> > clarity of Bottle's approach and the simplicity of the documentation. >> >> >> >> >> >> Hello Steve, >> >> >> >> Thanks for your comment. >> >> >> >> I'm curious, did you consider any web servers other than Apache? >> >> >> >> Kev > > You're telling me that there are other web servers? ;) > > I didn't try any others seriously, no. My experience is with Apache and > IIS, and I try to stay away from Windows. > > I should mention, given Dieter Maurer's comment, that Bottle is a (fairly > thin) layer built over WSGI. I've built applications directly over WSGI > as well; that's another way to go, it's quite straightforward. mod_python > is no longer supported: > http://blog.dscpl.com.au/2010/05/modpython-project-soon-to-be- officially.html. Based on Dieter's comment I'm using Bottle as a framework, with gunicorn (behind nginx) as the webserver. Even Bottle is probably overkill for my use case, but my time is rather limited, so I'm happy to use an off the shelf solution. And I must say, configuring gunicorn and nginx contrasted pleasantly with my memories of struggling with httpd.conf :) -- http://mail.python.org/mailman/listinfo/python-list
RE: Getting a seeded value from a list
Just a quick update: after enlisting some help from a friend, we managed to get things working :) Thanks for all the help. In the area of items and monsters, they're both chosen from lists, based on some simple selection criteria (number per room, total per level, chance of appearance). Now, the major task is to reconfigure the distribution system to let items and monsters stay in place between levels. > Date: Sat, 24 Nov 2012 09:32:46 +1100 > Subject: Re: Getting a seeded value from a list > From: [email protected] > To: [email protected] > > On Sat, Nov 24, 2012 at 3:27 AM, Prasad, Ramit > wrote: > > Steven D'Aprano wrote: > >> > >> On Wed, 21 Nov 2012 14:41:24 +1100, Chris Angelico wrote: > >> > >> > However, this still means that the player will see the exact same level > >> > regenerated every time, absolutely fresh. As previously stated in this > >> > thread, that's not usually a good thing for encounters, treasure, etc. > >> > Once some nasty critter has been killed, he should STAY killed! :) > >> > >> Why? That isn't true in real life, why should it be true for games? > >> > > > > It is not true in all games. I have seen games where treasures > > regenerate in the same location except for key items. Same goes > > for enemies (where only "bosses" do not regenerate). It really > > just depends on the type of game you are playing--designing > > in this case. > > Perhaps they regenerate, but do they regenerate from the exact same > random seed? For instance, in Murkon's Refuge, the maps are > handcrafted and thus constant every time you enter a particular level > - but go downstairs and upstairs, and the monsters and treasure > regenerate, different from last time. > > Of course, if the idea is that you're rewinding time, then it makes > good sense for you to see the exact same pattern of enemies. > > ChrisA > -- > http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: 10 sec poll - please reply!
Hi Steven,
press('s') is allowed. So is press('S') - it presses shift for you and is thus
equivalent to press(SHIFT + 's'). You can write press('f', 's'). You cannot
write press('fs') because that's what enter(...) is for. If you try - or, as I
would deem more likely, happen do to it by mistake - you get the following
warning:
>>> press('fs')
ValueError: 'press' generates single keystrokes and is not intended to
be used for typing in long plain-text strings. Did you maybe mean one of the
following?
* enter("fs")
* click("fs")
* press('f', 's')
I'm not aware of CTRL + i having a connection with TAB. You cannot use it to
get a tab. We haven't decided on what to do when you press('\t'). If you want
three tabs, you can write
press(TAB, TAB, TAB)
If you want a tab, a letter and a newline, you can do
enter("""\tA
\tB
\tC
""")
The reasoning is that you are entering plain text, that is a string that you
would like to appear in the window you are typing into in the same way as you
are supplying it to `enter`.
If you want to type "Hello World!" without entering it, you call
enter("Hello World!")
Yes, I did write "call *enter* to do X *without entering*". You are hinting at
a valid ambiguity with `enter` that Chris already pointed out. I don't think
it's worse than the ambiguity of
>>> type("Hello World!")
We would need a new function for holding down keys to release them later. You
are again pointing out an imho valid ambiguity. However, you were just happily
using `press` with the understanding that it presses and releases keys, so I
hope this one isn't too bad.
As I said, I opened a new thread solely for overriding `type` in the context of
a GUI automation library:
https://groups.google.com/forum/?fromgroups=#!topic/comp.lang.python/GjZ2hAS1Wyk.
So far, 4/4 people there advised against it. If only Python hadn't defined
`type`...
Michael
On Friday, November 23, 2012 11:30:04 PM UTC+1, Steven D'Aprano wrote:
> On Fri, 23 Nov 2012 05:42:22 -0800, Michael Herrmann wrote:
>
>
>
> > Dear all,
>
> >
>
> > the emails are getting kind of long so to ask you briefly: What do you
>
> > think of splitting `type` into two functions `press` and `enter`?
>
>
>
> This invites confusion as to the rules of when you can call `press` and
>
> when you can call `enter`. Especially since you haven't explained the
>
> rules, just given a bunch of non-exhaustive examples and invited people
>
> to extrapolate what the rules are.
>
>
>
> (By the way, they aren't use-cases, they're examples.)
>
>
>
>
>
> > Their use cases are:
>
> > press(CTRL + 'a')
>
> > press(ENTER)
>
> > press(ALT + 'f', 's')
>
> > enter("Hello World!")
>
> > enter("test.txt", into="File name")
>
>
>
>
>
> Is `press('s')` allowed?
>
>
>
> What about `press('S')`, or do I have to write `press(SHIFT + 's')`?
>
>
>
> If I can write `press(ALT + 'f', 's')`, can I write `press('f', 's')`? If
>
> not, why not?
>
>
>
> Can I write `press('fs')` as a simpler version of `press('f', 's')`? If
>
> not, why not?
>
>
>
> Can I write `press(CTRL + 'i')` to get a tab? How about `press('\t')`?
>
>
>
> If I want three tabs, can I write `press('\t\t\t')`, or do I have to write
>
>
>
> press(CTRL + 'i')
>
> press(CTRL + 'i')
>
> press(CTRL + 'i')
>
>
>
> If I want a tab, a letter, and a newline, repeated three times, can I do
>
> this?
>
>
>
> press("""\tA
>
> \tB
>
> \tC
>
> """)
>
>
>
> Or do I have to do this?
>
>
>
> press(CTRL + 'i')
>
> enter('A')
>
> press(CTRL + 'i')
>
> enter('B')
>
> press(CTRL + 'i')
>
> enter('C')
>
>
>
> Speaking of enter, how do I type "Hello World!" without entering it? If I
>
> want to type "Hello World!" without ENTER, do I have to do this?
>
>
>
> press('H')
>
> press('e')
>
> press('l')
>
> press('l')
>
> ... you get the picture
>
>
>
>
>
> With a function named "press", I would expect to be able to say:
>
>
>
> press('a')
>
> time.sleep(5)
>
> release('a')
>
>
>
> How do I do something like that?
>
>
>
>
>
>
>
> --
>
> Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: 10 sec poll - please reply!
Thanks for your reply Dennis,
the commands sounding like they should be commands to a user is the whole point
of the exercise: In doing so, we hope to make the API accessible also to users
from a less technical background. You are perfectly right that system events
are being generated and passed around, however that is not what these users
care about. Frankly, also I coming from a very technical background don't care
which events are generated and how, as long as it works.
I agree that "key_down"/"key_up" has a nice symmetry to it. Maybe a solution
could also be to use a context manager:
with key_down(SHIFT):
# some action...
Cheers
On Friday, November 23, 2012 11:11:34 PM UTC+1, Dennis Lee Bieber wrote:
> On Thu, 22 Nov 2012 10:00:54 -0800 (PST), Michael Herrmann
>
> declaimed the following in
>
> gmane.comp.python.general:
>
>
>
> > These names aren't perfect. As Emile rightly pointed out, several tools
> > distinguish between 'press' and 'release' and a user might wonder how to
> > release a key that was pressed using 'press'. That's an ambiguity that is
> > certainly there, however we hope that once the user has at least seen
>
> > press(ENTER)
>
> > it is clear what is meant. Distinguishing between pressing and releasing
> > could we think easily be done with, say
>
> > hold_down(SHIFT)
>
> > ...
>
> > release(SHIFT)
>
> > Another ambiguity of 'press' that I pointed out in my original mail is that
> > it could also be understood as "pressing a button". The current idea is to
> > raise a ValueError if the user supplies a string that is longer than one
> > character:
>
> > >>> press("OK")
>
> > ValueError: 'press' generates keystrokes and can only press single
> > letters at a time. Did you maybe mean click("OK") or press('O', 'K')?
>
> >
>
>
>
> "press", "hold_down", "release" just sound so much like they should
>
> be commands to a /user/ not to a means of programmatically controlling
>
> an interface. A "user" presses a button -- but a program is just
>
> injecting the "event" of a button press into the input processing stream
>
> (it's been decades, but I still think in Amiga terms -- where all input
>
> events routed through one input handler and chained to the programs
>
> wanting to work with raw events... This meant that, but injecting the
>
> event codes before the input handler, a program could make another
>
> program [including the OS] think one had ejected/inserted floppies,
>
> mouse movements, keystrokes)
>
>
>
> "hold_down" and "release" would seem more memorable, and symmetric,
>
> if named "key_down" and "key_up"; and if "press" is limited to single
>
> codes -- "key" [or "keystroke"]
>
>
>
> The closest M$ .Net method is called SendKeys() and works with
>
> strings.
>
> http://msdn.microsoft.com/en-us/library/microsoft.visualstudio.testtools.uitesting.keyboard.sendkeys%28v=vs.100%29.aspx
>
>
>
>
>
>
>
>
>
>
>
> > What do you think of this solution? I hope anybody read this far. I
> > probably shouldn't have written that much but wanted to do justice to your
> > inputs.
>
> >
>
> > Thanks!
>
> >
>
> > Michael
>
> >
>
> > On Tuesday, November 20, 2012 1:18:38 PM UTC+1, Michael Herrmann wrote:
>
> > > Hi,
>
> > >
>
> > >
>
> > >
>
> > > I'm developing a GUI Automation library (http://www.getautoma.com) and am
> > > having difficulty picking a name for the function that simulates key
> > > strokes. I currently have it as 'type' but that clashes with the built-in
> > > function. Example uses of 'type':
>
> > >
>
> > >
>
> > >
>
> > > type(ENTER)
>
> > >
>
> > >
>
> > >
>
> > > type("Hello World!")
>
> > >
>
> > >
>
> > >
>
> > > type(CTRL + 'a')
>
> > >
>
> > >
>
> > >
>
> > > What, in your view, would be the most intuitive alternative name?
>
> > >
>
> > >
>
> > >
>
> > > Here are my thoughts so far: I could call it 'press' but then our GUI
> > > automation tool also allows you to click things and then "press" might be
> > > mistaken for "pressing a button". A less ambiguous alternative is
> > > "type_keys" but that is rather long and doesn't read as well, for
> > > instance in type_keys(ENTER).
>
> > >
>
> > >
>
> > >
>
> > > Thank you very much!
>
> --
>
> Wulfraed Dennis Lee Bieber AF6VN
>
> HTTP://wlfraed.home.netcom.com/
--
http://mail.python.org/mailman/listinfo/python-list
Setup.py not respecting package_dir during develop
This is my current project setup:
.
├── README.md
├── build
│ ├── bdist.macosx-10.8-intel
│ └── lib
├── dist
│ └── giordano-0.1-py2.7.egg
├── giordano.egg-info
│ ├── PKG-INFO
│ ├── SOURCES.txt
│ ├── dependency_links.txt
│ ├── not-zip-safe
│ └── top_level.txt
├── requirements.txt
├── setup.py
├── src
│ ├── giordano
│ └── spider
├── test.txt
└── venv
├── bin
├── include
├── lib
└── share
And this is my setup file:
from setuptools import setup
setup(name='giordano',
version='0.1',
packages=['giordano'],
package_dir={'giordano': 'src/giordano'},
zip_safe=False)
When I do python setup.py install, I am able to `import giordano` in my code
without problems.
However, when I am doing python setup.py develop, this is the console output:
[venv] fixSetup$ python setup.py develop
running develop
running egg_info
writing giordano.egg-info/PKG-INFO
writing top-level names to giordano.egg-info/top_level.txt
writing dependency_links to giordano.egg-info/dependency_links.txt
reading manifest file 'giordano.egg-info/SOURCES.txt'
writing manifest file 'giordano.egg-info/SOURCES.txt'
running build_ext
Creating
/Users/blah/Dropbox/projects/Giordano/venv/lib/python2.7/site-packages/giordano.egg-link
(link to .)
Removing giordano 0.1 from easy-install.pth file
Adding giordano 0.1 to easy-install.pth file
Installed /Users/blah/Dropbox/projects/Giordano
Processing dependencies for giordano==0.1
Finished processing dependencies for giordano==0.1
This is what the .egg.link looks like:
/Users/blah/Dropbox/projects/Giordano
.
I can no longer `import giordano` in my code now.
**If I `touch src/__init__.py`, I am able to `from src import giordano`
anywhere outside of this directory. So I am 100% certain that the egg is
pointing to here rather than what package_dir specified.**
Any ideas why develop is not respecting package_dir?
--
http://mail.python.org/mailman/listinfo/python-list
Re: 10 sec poll - please reply!
Hey,
how about 'write' instead of 'enter'?
write("Hello World!")
write("Brick Lane", into="Street")
This avoids the ambiguity of whether 'enter' ends by pressing ENTER or not.
Thanks,
Michael
On Tuesday, November 20, 2012 1:18:38 PM UTC+1, Michael Herrmann wrote:
> Hi,
>
>
>
> I'm developing a GUI Automation library (http://www.getautoma.com) and am
> having difficulty picking a name for the function that simulates key strokes.
> I currently have it as 'type' but that clashes with the built-in function.
> Example uses of 'type':
>
>
>
> type(ENTER)
>
>
>
> type("Hello World!")
>
>
>
> type(CTRL + 'a')
>
>
>
> What, in your view, would be the most intuitive alternative name?
>
>
>
> Here are my thoughts so far: I could call it 'press' but then our GUI
> automation tool also allows you to click things and then "press" might be
> mistaken for "pressing a button". A less ambiguous alternative is "type_keys"
> but that is rather long and doesn't read as well, for instance in
> type_keys(ENTER).
>
>
>
> Thank you very much!
--
http://mail.python.org/mailman/listinfo/python-list
Re: Is it bad style to override the built-in function `type`?
Hi,
how about "write" instead of "type"? Just came to me in a flash of inspiration.
I know it's also pretty general but at least it's not a built-in!
Thanks!
Michael
On Friday, November 23, 2012 11:30:18 PM UTC+1, Cameron Simpson wrote:
> On 23Nov2012 10:41, Michael Herrmann <> wrote:
>
> [...]
>
> | I know it's a common beginner's mistake to incautiously override
>
> | built-in functions. However, we put in a lot of research and have come to
>
> | the conclusion that, if Python had not already defined it, `type` would
>
> | be the best name. We are now trying to evaluate how bad the disadvantages
>
> | you mention are in comparison to the advantage to having a name that is
>
> | more intuitive to use in the problem domain.
>
> |
>
> | Can you somehow relate to my explanations, or are your experiences
>
> | with overwriting built-in variables so bad that you would advise to
>
> | never ever do it?
>
>
>
> My own experience says that it is a thing best avoiding without a truly
>
> amazing reason not to.
>
>
>
> I urge you not to: type(foo) is a very basic Python idiom and you're
>
> breaking it. One day it _will_ bite you or your users. You will
>
> understand, but I would give goods odds that some of your users will not
>
> the day they go to examine the type of an object for perfectly normal
>
> pythonic reasons.
>
>
>
> Example: I have a module that stores "objects" and they have as a
>
> primary key a "name" and a "type" - not Python types, just strings.
>
> Accordingly I have a similar situation to yours: the desire to use the
>
> word "type". Fortunately for me, as an attribute in (usually small) code
>
> chunks I can usually go:
>
>
>
> t = foo.type
>
> ... work with t here ...
>
>
>
> Where I must pass one as a parameter I use the common convention of
>
> naming the parameter "type_" at the receiving end.
>
>
>
> For the calling end, as in your case, you want to use:
>
>
>
> type(blah)
>
>
>
> Is it at all possible to make all uses of your "type" function method
>
> calls? Eg:
>
>
>
> something.type("text to type")
>
>
>
> It avoids the overloading while keeping your desired name.
>
> --
>
> Cameron Simpson
>
>
>
> Wouldn't it be great if all emergency stopping situations occurred on your
>
> favourite bit of road..you'd probably know about it before it happened
>
> and would be able to take other evasive action.
>
> - Neville Brabet
--
http://mail.python.org/mailman/listinfo/python-list
Re: Is it bad style to override the built-in function `type`?
On 24Nov2012 14:32, Michael Herrmann wrote: | how about "write" instead of "type"? Just came to me in a flash of inspiration. I know it's also pretty general but at least it's not a built-in! +1 -- Cameron Simpson Cars making a sudden U-turn are the most dangerous. They may cut you off entirely, blocking the whole roadway and leaving you no place to go. - MSF Motorcycle Operator Manual, sixth rev. 1991, page 21 -- http://mail.python.org/mailman/listinfo/python-list
RE: Is it bad style to override the built-in function `type`?
(This comes from my experience writing interactive fiction with the TADS
workbench; YMMV) As a rule, it's generally unwise to modify built-in variables
without thoroughly documenting your changes. Your modifications might not hold
up if the built-in definitions are revised (which would break your program) and
you could introduce later version/compatibility issues with other things that
use/need the 'standard' definitions. That said, if done cautiously, modifying
the built-ins can have a net benefit; just be careful to indicate what you've
changed so you can debug it properly, and -- if possible -- distribute yoru
modified code along with a copy of the original, so that if issues arise, your
users can restore the stable code without digging around in the guts of the
software.
> >
> > [...]
> >
> > | I know it's a common beginner's mistake to incautiously override
> >
> > | built-in functions. However, we put in a lot of research and have come to
> >
> > | the conclusion that, if Python had not already defined it, `type` would
> >
> > | be the best name. We are now trying to evaluate how bad the disadvantages
> >
> > | you mention are in comparison to the advantage to having a name that is
> >
> > | more intuitive to use in the problem domain.
> >
> > |
> >
> > | Can you somehow relate to my explanations, or are your experiences
> >
> > | with overwriting built-in variables so bad that you would advise to
> >
> > | never ever do it?
> >
> >
> >
> > My own experience says that it is a thing best avoiding without a truly
> >
> > amazing reason not to.
> >
> >
> >
> > I urge you not to: type(foo) is a very basic Python idiom and you're
> >
> > breaking it. One day it _will_ bite you or your users. You will
> >
> > understand, but I would give goods odds that some of your users will not
> >
> > the day they go to examine the type of an object for perfectly normal
> >
> > pythonic reasons.
> >
> >
> >
> > Example: I have a module that stores "objects" and they have as a
> >
> > primary key a "name" and a "type" - not Python types, just strings.
> >
> > Accordingly I have a similar situation to yours: the desire to use the
> >
> > word "type". Fortunately for me, as an attribute in (usually small) code
> >
> > chunks I can usually go:
> >
> >
> >
> > t = foo.type
> >
> > ... work with t here ...
> >
> >
> >
> > Where I must pass one as a parameter I use the common convention of
> >
> > naming the parameter "type_" at the receiving end.
> >
> >
> >
> > For the calling end, as in your case, you want to use:
> >
> >
> >
> > type(blah)
> >
> >
> >
> > Is it at all possible to make all uses of your "type" function method
> >
> > calls? Eg:
> >
> >
> >
> > something.type("text to type")
> >
> >
> >
> > It avoids the overloading while keeping your desired name.
> >
> > --
> >
> > Cameron Simpson
> >
> >
> >
> > Wouldn't it be great if all emergency stopping situations occurred on your
> >
> > favourite bit of road..you'd probably know about it before it happened
> >
> > and would be able to take other evasive action.
> >
> > - Neville Brabet
>
> --
> http://mail.python.org/mailman/listinfo/python-list
--
http://mail.python.org/mailman/listinfo/python-list
Re: Is it bad style to override the built-in function `type`?
On Sat, 24 Nov 2012 14:32:19 -0800, Michael Herrmann wrote:
> Hi,
>
> how about "write" instead of "type"? Just came to me in a flash of
> inspiration. I know it's also pretty general but at least it's not a
> built-in!
"write" is an extremely common operation with a signature very similar to
that of your function you want. The typical use of your function:
automata.write("Hello world") # or whatever your module is called
looks exactly like writing to the file referred to by the name "automata".
Writing to files is *far* more common than using type. Using the standard
library for a rough-and-ready test:
[steve@ando python3.3]$ grep "[.( ]write(" *.py | wc -l
475
[steve@ando python3.3]$ grep "[.( ]type(" *.py | wc -l
161
If it isn't obvious what I am doing, I am using the Linux "grep" utility
to search the Python 3.3 standard library for calls to functions or
methods called "write" vs "type". There are nearly three times as many
calls to "write".
If I inspect the way that the functions are used, the difference is
clear: write is nearly always used as a procedure, while type is used as
a function. Here are a couple of typical examples:
copy.py:return type(x)(x.__func__, deepcopy(x.__self__, memo))
datetime.py:if type(other) != timezone:
Your "simulate typing" function does not look like this. It doesn't
return anything. It usually gets used as a procedure, not a function,
just like the write method:
base64.py:output.write(line)
formatter.py:write(word)
There is far more opportunity for confusion with the name "write" than
"type":
* writing to files is much more common than calling type, even in
expert-level code;
* beginners are even less likely to be using builtin type;
* a call to your proposed function "type(string)" does not look
like a typical call to the builtin type function;
* but a call to your proposed function "write(string)" does look
very similar, if not identical, to a typical call to write.
This is why I maintain that fear of shadowing builtins often becomes
superstition, not reasonable, reasoned advice. For fear of one (unlikely)
source of confusion, you are prepared to accept a (more likely) source of
greater confusion.
Writing to files is a very common thing to do. Calling type() is not. Way
back in the early days of Python, it was common to use code like:
if type(obj) is type([]): ...
but that is usually wrong (it rejects subclasses) and inelegant. Normally
people will use:
if isinstance(obj, list): ...
or better still, avoid type-testing altogether. One thing that *doesn't*
get done is call builtin type on a literal string, then ignore the result:
type("Hello world!")
What would be the point? That would be better written:
str
or even better still, not written at all, since it does nothing sensible.
But calling file method "write" with a string, or a string literal, is
extremely common, and sensible. Your proposed "write" will look just like
writing to a file, when it does something completely different. A couple
of days ago I said:
[quote]
If it were possible to be confused by the two types, e.g. if they took the
same arguments but did radically different things, then I would accept
that it was too dangerous/confusing to re-use the name. Reasonable fears
about shadowing and confusion are, well, reasonable.
[end quote]
Your proposal to use "write" is exactly the sort of reasonable confusion
that I was talking about.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: Is it bad style to override the built-in function `type`?
On 25Nov2012 04:06, Steven D'Aprano
wrote:
| On Sat, 24 Nov 2012 14:32:19 -0800, Michael Herrmann wrote:
| > how about "write" instead of "type"? Just came to me in a flash of
| > inspiration. I know it's also pretty general but at least it's not a
| > built-in!
|
| "write" is an extremely common operation with a signature very similar to
| that of your function you want. The typical use of your function:
|
| automata.write("Hello world") # or whatever your module is called
|
| looks exactly like writing to the file referred to by the name "automata".
Which is actually an argument _for_ his suggestion.
[...]
| If I inspect the way that the functions are used, the difference is
| clear: write is nearly always used as a procedure, while type is used as
| a function. [...]
| Your "simulate typing" function does not look like this. It doesn't
| return anything. It usually gets used as a procedure, not a function,
| just like the write method:
Again, an argument _for_ his suggestion.
|
| There is far more opportunity for confusion with the name "write" than
| "type":
[...]
| * but a call to your proposed function "write(string)" does look
| very similar, if not identical, to a typical call to write.
Again, an argument _for_ his suggestion.
Why do I find these reasons to be plusses while you find them minuses?
Because you're conveniently glossing over the fact that almost all
uses of "write" in the library and common code have an object for
context.
And I find his suggestion good because for us old UNIX heads, the way you
present typed text to a terminal is usually to write it to the master
side of a pseudotty, thus:
pty.write("typed text here!")
The usage is _exactly_ analogous to the conventional uses of write(),
because "everything is a file" (one of the UNIX mantras). Writing typed
text is the natural way to express this stuff.
Your argument seems to be that because his write looks and acts like
other write()s it is cause for confusion. My argument is that using the
name "write" is a good thing, _because_ his usage looks and acts like
the other common uses of write.
So I maintain it should cause less confusion.
Cheers,
--
Cameron Simpson
It is a tale told by an idiot, full of sound and fury, signifying nothing.
- William Shakespeare
--
http://mail.python.org/mailman/listinfo/python-list
Re: only .exe
On Saturday, 24 November 2012 17:06:57 UTC+5:30, bakie wrote: > in the last question I try how to run py script with pycharm . > > thank dear bro ... > > > > and then I wanna have that program with .exe ( standalone installer ) . How > can i do that ? > > > > I tried with two ways > > 1) py2exe > > 2) cx_freeze > > > > but I don't like that It has many file when i complie my script . > > which way for .exe ( standalone installer ) from pycharm . > > > > Thanks U brothers Please, there are women here also. Also, it doesn't compile your script. It only bundles Python and your script in an .exe. -- http://mail.python.org/mailman/listinfo/python-list
