Re: method that can be called from a class and also from an instance

[Peter Otten]

Steven D'Aprano wrote:

> On Thu, 22 Nov 2012 16:51:27 +0100, Peter Otten wrote:
> 
>> Marc Aymerich wrote:
>> 
>>> Hi,
>>> 
>>> I want to create a method within a class that is able to accept either
>>> a class or an instance.
> [...]
>> Why would you overload a method that way?
> 
> 
> The use-case I have is that I have a number of classes with default
> state. Most instances don't override any of the state, so the instances
> don't add anything except an extra conceptual layer:
> 
> instance = MyClass()  # notice that there are no arguments passed
> instance.method(args)
> 
> Since the instances don't have any state except for that already held by
> the class, they are redundant and pointless. Just knowing the class is
> enough to specify the behaviour. If I used class methods, I could do this:
> 
> MyClass.method(args)
> 
> 
> But here's the thing -- sometimes I *do* have instances that override the
> default state:
> 
> instance = MyClass(x, y, z)
> instance.method(args)
> 
> Now if method is a class method, my per-instance state is ignored. So I
> want a method that can be called from the class, and see the default
> state, or from the instance, and see the per-instance state. Neither
> classmethod, staticmethod nor ordinary instance methods do the job, but
> my custom dualmethod does.
> 
> http://code.activestate.com/recipes/577030/

Am I reading that right that you don't invoke method() as MyClass.method()? 
Then I'd probably use class attributes to store the default state and shade 
them by instance attributes as needed.

class A:
state = "default"
def __init__(self, state=None):
if state is not None:
self.state = state
def method(self): return self.state

assert A().method() == "default"
assert A("special").method() == "special"

The same idea might work for the OP, too (but I'm not sure it's a good 
idea):

class B:
def inst_f(self):
return "instance"
@classmethod
def f(class_):
return "class"
def __init__(self):
self.f = self.inst_f

assert B.f() == "class"
assert B().f() == "instance"


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

Re: Migrate from Access 2010 / VBA

[Peter Otten]

kgard wrote:

> Greetings:
> 
> I am the lone developer of db apps at a company of 350+ employees.
> Everything is done in MS Access 2010 and VBA. I'm frustrated with the
> limitations of this platform and have been considering switching to
> Python. I've been experimenting with the language for a year or so, and
> feel comfortable with the basics.
> 
> I am concerned that I'll have a hard time replacing the access form and
> report designers. I've worked a little with TKinter, but it's a far cry
> from the GUI designer in Access. Finding a professional grade report
> designer looks like an even bigger challenge.
> 
> I don't need to port any applications, but I will need to use the data
> (mdb/accede format), design a variety of reports with multi-level
> groupings, and deliver them to many individual recipients via email.
> 
> Has anyone here made this transition successfully? If so, could you pass
> along your suggestions about how to do this as quickly and painlessly as
> possible?

These guys are coming from Foxpro, but I'd expect a huge overlap of the 
problem spaces:

http://dabodev.com/

(Disclaimer: I have not tried Dabo myself)

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

Re: Print value from array

[Hans Mulder]

On 22/11/12 19:44:02, Mike wrote:
> Hello,
> I am noob en python programing,  i wrote a perl script for read from csv but 
> now i wish print value but the value must be within double quote and I can 
> not do this. 
> 
> For example now the output is:
> 
> ma user@domain displayName Name SecondName givenName Name sn SecondName cn 
> Name
> 
> and i wish
> 
> ma "user@domain" displayName "Name Lastname" givenName "Name" sn "SecondName" 
> cn "Name"
> 
> My script is
> 
> #!/usr/bin/python
> import csv
> 
> with open ('file.csv', 'rb') as f:
>   reader = csv.reader (f, delimiter=';' )
>   for row in reader:
>   mail = row [0]
>   name = row [1]
>   lastname = row [2]
>   name2  = row [1] + ' ' + row [2]
>   
>   print  'ma ' + mail + ' displayName ' +  name2.title() + ' 
> givenName ' + name.title() + ' sn ' + lastname.title() + ' cn ' + 
> name.title()  
> 
>   #   print '\n'
> 
> f.close() 

How about:

#!/usr/bin/python
import csv

with open('file.csv', 'rb') as f:
reader = csv.reader(f, delimiter=';' )
for mail, firstname, lastname in reader:
fullname  = firstname + ' ' + lastname

print 'ma "%s"' % mail,
print 'displayname "%s"' % fullname.title(),
print 'givenName "%s"' % firstname.title(),
print 'sn "%s"' % lastname.title(),
print 'cn "%s"' % firstname.title()

f.close()


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

Pass parameters/globals to eval

[esandin]

I am trying to set the parameter 'a' below so that it can be used when I call 
eval:

>>> def gp_function():
... return 1+a
... 
>>> print eval("gp_function()", {'a':123, 'gp_function':gp_function})

Traceback (most recent call last):
  File "", line 1, in 
  File "", line 1, in 
  File "", line 2, in a_method
NameError: global name 'a' is not defined

Why isn't 'a' defined?
Shouldn't you be able to define the global variables with a dict passed to eval?
Is there an other way to do this, beside the two obvious: defining 'a' before 
calling gp_function and using a as an argument in gp_function?

In case you are wondering why I want this:
This is a simplification of a problem I ran into when experimenting with 
pyevolve. After running pyevolve: GTreeGP.getCompiledCode() I get some compiled 
code, and need to pass some arguments to it. Perhaps there is an easier way to 
do it...

Kind Regards
Emil
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Pass parameters/globals to eval

[Chris Angelico]

On Fri, Nov 23, 2012 at 11:14 PM,   wrote:
> Why isn't 'a' defined?
> Shouldn't you be able to define the global variables with a dict passed to 
> eval?
> Is there an other way to do this, beside the two obvious: defining 'a' before 
> calling gp_function and using a as an argument in gp_function?

It is defined, but not in the context of the called function.

You defined that function in a particular scope, which then becomes
its global scope. (I'm handwaving a lot of details here. Bear with
me.) When you eval a bit of code, you define the global scope for
_that code_, but not what it calls. Calling gp_function from inside
there switches to the new global scope and off it goes.

Normally, I'd recommend your second option, passing a as an argument.
It's flexible, clear, doesn't rely on fancy names and hidden state.
But to answer your actual question: Yes, there is another way to do
it. In all probability, gp_function is actually defined at module
scope (I'm guessing here but it seems likely based on your
description). Simply assign to the module's namespace before calling
it - it'll "see" that as a global.

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

Re: method that can be called from a class and also from an instance

[Steven D'Aprano]

On Fri, 23 Nov 2012 09:52:25 +0100, Peter Otten wrote:

> Steven D'Aprano wrote:
>> http://code.activestate.com/recipes/577030/
> 
> Am I reading that right that you don't invoke method() as
> MyClass.method()? 

No. I give an example and explicitly state:

You can use this class without instantiating:

Example.method('else')  # returns 'something else'


> Then I'd probably use class attributes to store the
> default state and shade them by instance attributes as needed.
> 
> class A:
> state = "default"
> def __init__(self, state=None):
> if state is not None:
> self.state = state
> def method(self): return self.state

That doesn't allow me to call A.method().

On the other hand, if method were a class method, then I could say 
A.method() or A(state).method, but in both cases I would get the default. 
So that isn't suitable.


[...]
> The same idea might work for the OP, too (but I'm not sure it's a good
> idea):
> 
> class B:

This needs to be a new-style class unless you're using Python 3.

> def inst_f(self):
> return "instance"
> @classmethod
> def f(class_):
> return "class"
> def __init__(self):
> self.f = self.inst_f
> 
> assert B.f() == "class"
> assert B().f() == "instance"

Without studying that in detail, it looks like that would be an 
alternative solution to the same problem. The downsides are:

- you have two distinct but almost identical implementations of 
  method "f", one called "f" and one called "inst_f";

- it works by shadowing method "f" in the instance, which may
  strike many people as too tricky for production software.


Me personally, I think the first objection is critical. Having to write 
the same method twice, with subtle differences, is inviting bugs.



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

python3.3 - tk_setPalette bug?

[Helmut Jarausch]

Hi,

AFAIK, this should work:

import tkinter as Tk
root= Tk.Tk()
root.tk_setPalette(background = 'AntiqueWhite1', foreground = 'blue')

but python-3.3:0e4574595674+ gives

Traceback (most recent call last):
  File "Matr_Select.py", line 174, in 
root.tk_setPalette(background = 'AntiqueWhite1', foreground = 'blue')
  File "/usr/lib64/python3.3/tkinter/__init__.py", line 390, in 
tk_setPalette
+ _flatten(args) + _flatten(kw.items()))
TypeError: argument must be sequence


What am I missing?

Thanks,
Helmut.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: 10 sec poll - please reply!

[Michael Herrmann]

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`? Their use cases are:
press(CTRL + 'a') 
press(ENTER) 
press(ALT + 'f', 's') 
enter("Hello World!") 
enter("test.txt", into="File name") 

Thanks, 
Michael

On Thursday, November 22, 2012 7:00:55 PM UTC+1, Michael Herrmann wrote:
> Dear all,
> 
> 
> 
> thank you for your replies. After experimenting with your suggestions, we 
> have arrived at a solution that we believe fits well with our existing API. 
> However, before we implement this solution, we would like to ask you one last 
> time to sign off on our proposal or raise any serious problems you see with 
> it.
> 
> 
> 
> We took the fact that naming our one function 'type' was so difficult to name 
> as an indicator that it may be trying to do too many things: On the one hand, 
> it allows you to enter plain text as in `type("Hello World!")`; on the other 
> hand, it lets you press single keys, possibly in combination with control 
> keys as for instance in `type(CTRL + 'a')`. We believe it won't normally be 
> necessary to combine the two. For instance, while you could see what
> 
>   type(CTRL + 'a' + "Hello World!")
> 
> does, we think you would be more likely to use the two separate calls
> 
>   type(CTRL + 'a')
> 
>   type("Hello World!")
> 
> 
> 
> One of the main goals of our automation product is that using it should feel 
> like giving instructions to a human being looking over their shoulder at a 
> screen. For this reason, it's very useful for us if the function names in our 
> API are short, if possible without underscores, and close to the vocabulary 
> you would use in an everyday conversation. We hope that by offering an API 
> with this property, we can not only make it easier to use for experienced 
> programmers such as yourself, but also be approachable for people from a less 
> technical background.
> 
> 
> 
> In our gut feeling, the words apart from `type` that would most normally be 
> used in an everyday conversation to express the three examples I have given 
> in my first mail are:
> 
>   press(CTRL + 'a')
> 
>   enter("Hello World")
> 
>   press(ENTER)
> 
> 
> 
> We really quite like the word `type`, and a few people here seem to favour it 
> too. In particular, Steven: We're glad you accidentally clicked on our mail. 
> Thank you for your inputs and the great quote by Phil Karlton. We think you 
> were right in everything you said. However, some people seem to be *really* 
> put off when you override a built-in function. Even though of course you can 
> avoid the overriding by saying
> 
>   from automa.api import type *as* ...,
> 
> (as Tim pointed out) we'd like to avoid irritating those people. For this 
> reason, we would rather not use `type`.
> 
> 
> 
> Many people here voted for send_keys(...). We agree with Dave and Neil that 
> `type` may have too many uses already. As Chris and MRAB pointed out, 
> 'send_keys' is used in many other automation tools. This makes it intuitive 
> for people with knowledge of such tools. However, as I said above (and should 
> have probably said earlier), we are also trying to reach users from a less 
> technical background. Since these people would not normally use 'send_keys' 
> in an everyday conversion, we are afraid that it would not be an intuitive 
> name for them. A similar argument applies to some extent to our 'type_keys', 
> to our 'generate_keystrokes', Ramit's 'simulate_keypress', 
> 'simulate_key(s)_down', 'send_kb_press', 'fake_typing' and 'send_char(s)' and 
> Tim's 'feedkeys'. We thank you for your suggestions. Hopefully you can also 
> agree with our choice!
> 
> 
> 
> Some suggestions were very nice, short and pretty unambiguous, such as 
> Dennis' `emit` and particularly Alan's `strike`. However, they're 
> unfortunately also rather rarely used and we'd be afraid that it'd be hard to 
> remember them. Thank you though!
> 
> 
> 
> A final point that Evan made and that also we find very important is to have 
> verbs in our function names. 
> 
> 
> 
> Our proposed solution is to split what we previously called `type` into two 
> functions, 'press' and 'enter' (proposed by xDog Walker). 'press' could be 
> used to press single keys or combinations of them, at once:
> 
>   press(CTRL + 'a')
> 
>   press(ENTER)
> 
> To open a menu via the keyboard, you could also supply several key 
> combinations to be pressed, in sequence:
> 
>   press(ALT + 'f', 's')
> 
> 'enter' on the other hand would be used to enter longer strings of plain text:
> 
>   enter("Hello World!")
> 
> With a functionality we already have, you could supply an optional 'into' 
> parameter that selects a text field into which the text is entered:
> 
>   enter("test.txt", into="File name")
> 
> 'enter' currently does involve generating same system events that are fired 
> when

Re: python3.3 - tk_setPalette bug?

[Peter Otten]

Helmut Jarausch wrote:

> Hi,
> 
> AFAIK, this should work:
> 
> import tkinter as Tk
> root= Tk.Tk()
> root.tk_setPalette(background = 'AntiqueWhite1', foreground = 'blue')
> 
> but python-3.3:0e4574595674+ gives
> 
> Traceback (most recent call last):
>   File "Matr_Select.py", line 174, in 
> root.tk_setPalette(background = 'AntiqueWhite1', foreground = 'blue')
>   File "/usr/lib64/python3.3/tkinter/__init__.py", line 390, in
> tk_setPalette
> + _flatten(args) + _flatten(kw.items()))
> TypeError: argument must be sequence
> 
> 
> What am I missing?

Nothing, as far as I can tell. Please file a bug report on 
.

For now you can work around the bug with

root.tk_setPalette("background", 'AntiqueWhite1', "foreground", 'blue')


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

who is that...?!!

[BV BV]

who is that...?!!


http://www.youtube.com/watch?v=SIADfS030qg&feature=BFa&list=PLB95C1C59E12FBA96



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

Re: 10 sec poll - please reply!

[Michael Herrmann]

Hi again,

Steven's points and the "feeling" for `type` are very good and maybe the 
problems I mentioned can be ramified. I therefore opened a new thread to find 
out what the general public thinks about overwriting built-in functions such as 
`type` here: 
https://groups.google.com/forum/?fromgroups=#!topic/comp.lang.python/GjZ2hAS1Wyk

Thanks,
Michael

On Friday, November 23, 2012 10:08:06 AM UTC+1, Michael Herrmann wrote:
> Hi Steven,
> 
> 
> 
> On Friday, November 23, 2012 6:41:35 AM UTC+1, Steven D'Aprano wrote:
> 
> > On Thu, 22 Nov 2012 10:00:54 -0800, Michael Herrmann wrote:
> 
> > 
> 
> > 
> 
> > 
> 
> > > We took the fact that naming our one function 'type' was so difficult to
> 
> > 
> 
> > > name as an indicator that it may be trying to do too many things:
> 
> > 
> 
> > 
> 
> > 
> 
> > I don't think it is difficult to name at all.
> 
> > 
> 
> > 
> 
> > 
> 
> > > On the one hand, it allows you to enter plain text as in `type("Hello
> 
> > 
> 
> > > World!")`; 
> 
> > 
> 
> > 
> 
> > 
> 
> > That would be called "typing".
> 
> 
> 
> I agree that "typing" might be more common in this context. However, you also 
> understand me when I say "enter".
> 
> 
> 
> > 
> 
> > 
> 
> > 
> 
> > > on the other hand, it lets you press single keys, 
> 
> > 
> 
> > 
> 
> > 
> 
> > That would be called "typing".
> 
> 
> 
> Here, I disagree. You "press" enter and you "press" ALT+TAB. You might be 
> able to say "type ENTER" but that is much less common. Google agrees: 
> http://bit.ly/10o8yAQ vs. http://bit.ly/WmVwyU.
> 
> 
> 
> > 
> 
> > 
> 
> > 
> 
> > > possibly in combination with control keys as for instance in 
> 
> > 
> 
> > > `type(CTRL + 'a')`. 
> 
> > 
> 
> > 
> 
> > 
> 
> > That would be called "prestidigitation".
> 
> > 
> 
> > 
> 
> > 
> 
> > Nah, just kidding. That would also be called "typing".
> 
> 
> 
> Here too Google favours "press ctrl+a" over "type ctrl+a".
> 
> 
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > > We believe it won't normally be necessary to combine the two.
> 
> > 
> 
> > 
> 
> > 
> 
> > I can't imagine why you say that. You even go ahead and give a perfectly 
> 
> > 
> 
> > fine example of combining a control character with plain text.
> 
> > 
> 
> > 
> 
> > 
> 
> > I don't know what operating system you are using, but under Linux, people 
> 
> > 
> 
> > often use strings of regular characters mixed in with control- or alt-
> 
> > 
> 
> > characters. E.g. I in the shell, I might type Alt-B Shift-' END Shift-' 
> 
> > 
> 
> > to jump backwards one word (Alt-B), insert a double quote mark (Shift-'), 
> 
> > 
> 
> > jump to the end of the line I am editing (END), and insert another double 
> 
> > 
> 
> > quote mark.
> 
> 
> 
> Unfortunately, I didn't explain what I mean by "plain text". Your example 
> could be implemented with the "press" from our proposal, as follows:
> 
>   press(ALT + 'B', '"', END, '"')
> 
> What I meant when I said that "press" could not be used to enter plain text 
> was that it would not be possible to enter a sequence of multiple normal 
> letters enclosed in single quotes, as in
> 
>   press("Hello World")
> 
> If in your example you had wanted to add more than just a single character to 
> the beginning or end of the line, this means you would have to write
> 
>   press(ALT + 'B')
> 
>   enter("beginning of line")
> 
>   press(END)
> 
>   enter("end of line")
> 
> I agree that the following would read better here:
> 
>   press(ALT + 'B')
> 
>   type("beginning of line")
> 
>   press(END)
> 
>   type("end of line")
> 
> However like Google above, I would disagree with
> 
>   type(ALT + 'B')
> 
>   type("beginning of line")
> 
>   type(END)
> 
>   type("end of line")
> 
> or even
> 
>   type(ALT + 'B' + "beginning of line" + END + "end of line")
> 
> 
> 
> 
> 
> > 
> 
> > 
> 
> > 
> 
> > It is a needless restriction to assume that every control character must 
> 
> > 
> 
> > only be part of a single key press event. I even remember a Mac 
> 
> > 
> 
> > application back in the early 1990s or late 1980s that used combinations 
> 
> > 
> 
> > like Ctrl-A Y to perform commands. (Actually, such older Macs didn't have 
> 
> > 
> 
> > a Control key, they used Command instead, but the principle is the same.)
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > > One of the main goals of our automation product is that using it should
> 
> > 
> 
> > > feel like giving instructions to a human being looking over their
> 
> > 
> 
> > > shoulder at a screen.
> 
> > 
> 
> > 
> 
> > 
> 
> > In a word processor, I might say
> 
> > 
> 
> > 
> 
> > 
> 
> > "Type Ctrl-A Ctrl-X to cut all the text from the document."
> 
> > 
> 
> > 
> 
> > 
> 
> > rather than
> 
> > 
> 
> > 
> 
> > 
> 
> > "Press Ctrl-A. Now press Ctrl-X."
> 
> > 
> 
> 
> 
> With the current proposal, it'd be
> 
>   press(CTRL + 'A', CTRL + 'X')
> 
> Forgetting about `type` vs `press` for a moment, chaining the key 
> combinations li

ANN : occmodel v0.1.0

[Runar Tenfjord]

I am pleased to announce the first official
release of occmodel (v0.1.0) and the releated
libraries geotools/gltools.

Description
--

occmodel is a small library which gives a high level access
to the OpenCASCADE modelling kernel.

For most users a direct use of the OpenCASCADE modelling
kernel can be quite a hurdle as it is a huge library.

The geometry can be visualized with the included viewer.
This viewer is utilizing modern OpenGL methods like GLSL
shaders and vertex buffers to ensure visual quality and
maximum speed. To use the viewer OpenGL version 2.1 is
needed.

Home page : http://github.com/tenko/occmodel
Documentation : http://tenko.github.com/occmodel/index.html

In addition the following related libraries are released:

geotools (required) : http://github.com/tenko/geotools
Documentation : http://tenko.github.com/geotools/index.html

gltools (optional) : http://github.com/tenko/gltools
Documentation : http://tenko.github.com/gltools/index.html

As this is the first official release some hurdles are expected
Binary installers are available for the Windows platform.

Best regards
Runar Tenfjord

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

RE: Getting a seeded value from a list

[Prasad, Ramit]

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. 


~Ramit


This email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of
securities, accuracy and completeness of information, viruses,
confidentiality, legal privilege, and legal entity disclaimers,
available at http://www.jpmorgan.com/pages/disclosures/email.  
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: 10 sec poll - please reply!

[Kwpolska]

On Fri, Nov 23, 2012 at 2:42 PM, 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`? Their use cases 
> are:
> press(CTRL + 'a')
> press(ENTER)
> press(ALT + 'f', 's')
> enter("Hello World!")
> enter("test.txt", into="File name")
>
> Thanks,
> Michael

First of, please don’t top-post.  Second of, the type—enter split a
bad idea.  It would require me to think whether I should use one or
the other.  type() is perfectly fine, because Automa is never going to
be used as from automa import *.  And if it is, it’s in your shell for
non-Pythonistas.

And also, my general thoughts: type() is just fine.  Unless you want
to call it 
simulate_pressing_keys_on_the_keyboard_without_getting_a_mechanical_arm_out_of_the_screen_and_pressing_the_keys_with_it(),
but then you will need to create
simulate_using_the_mouse_without_getting_a_mechanical_arm_out_of_the_screen_and_moving_the_mouse_or_pressing_its_buttons_with_it(),
too.

--
Kwpolska 
stop html mail  | always bottom-post
www.asciiribbon.org | www.netmeister.org/news/learn2quote.html
GPG KEY: 5EAAEA16
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Is it bad style to override the built-in function `type`?

[Roy Smith]

In article ,
 Michael Herrmann  wrote:

> do you think it's bad style to override the built-in function `type`? I'm 
> co-developing a GUI automation library called Automa 
> (http://www.getautoma.com) and 'type' would be a very fitting name for a 
> function that generates artificial key strokes. 

For local variable names with small scopes, I don't fret much about 
overriding built-in names.  For a library, I would try harder to find 
non-conflicting names.  How about one of these:

type_text()
enter_text()
keyboard()

PS, A suggestion about your website.  In these days of tech exit 
strategies and M/A crazyness, putting "Purchase" and "Company" as 
adjacent items in the main menu might be misconstrued.  At first glance, 
I read it as "Purchase company".  Twitter Bootstrap, no?
-- 
http://mail.python.org/mailman/listinfo/python-list

Why queue.empty() returns False even after put() is called?

[Peng Yu]

Hi,

The empty() returns True even after put() has been called. Why it is
empty when there some items in it? Could anybody help me understand
it? Thanks!

~/linux/test/python/man/library/multiprocessing/Queue/empty$ cat
main.py
#!/usr/bin/env python

import multiprocessing

queue = multiprocessing.Queue()
print queue.empty()
queue.put(['a', 'b'])
queue.put(['c', 'd'])
print queue.empty()


Regards,
Peng
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: 10 sec poll - please reply!

[Michael Herrmann]

Hi,

I see your concern with having two functions that have to be separately 
remembered... I personally would also be fine with type(), however some people 
are violently against it. I opened a new thread 
(https://groups.google.com/forum/?fromgroups=#!topic/comp.lang.python/GjZ2hAS1Wyk)
 to ask just how many people would have a problem with this. I know I'm really 
spamming this list and apologize. I promise it'll be over soon.

Michael

On Friday, November 23, 2012 5:43:08 PM UTC+1, Kwpolska wrote:
> On Fri, Nov 23, 2012 at 2:42 PM, 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`? Their use 
> > cases are:
> 
> > press(CTRL + 'a')
> 
> > press(ENTER)
> 
> > press(ALT + 'f', 's')
> 
> > enter("Hello World!")
> 
> > enter("test.txt", into="File name")
> 
> >
> 
> > Thanks,
> 
> > Michael
> 
> 
> 
> First of, please don’t top-post.  Second of, the type—enter split a
> 
> bad idea.  It would require me to think whether I should use one or
> 
> the other.  type() is perfectly fine, because Automa is never going to
> 
> be used as from automa import *.  And if it is, it’s in your shell for
> 
> non-Pythonistas.
> 
> 
> 
> And also, my general thoughts: type() is just fine.  Unless you want
> 
> to call it 
> simulate_pressing_keys_on_the_keyboard_without_getting_a_mechanical_arm_out_of_the_screen_and_pressing_the_keys_with_it(),
> 
> but then you will need to create
> 
> simulate_using_the_mouse_without_getting_a_mechanical_arm_out_of_the_screen_and_moving_the_mouse_or_pressing_its_buttons_with_it(),
> 
> too.
> 
> 
> 
> --
> 
> Kwpolska 
> 
> stop html mail  | always bottom-post
> 
> www.asciiribbon.org | www.netmeister.org/news/learn2quote.html
> 
> GPG KEY: 5EAAEA16
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Is it bad style to override the built-in function `type`?

[Terry Reedy]

On 11/23/2012 11:22 AM, Joel Goldstick wrote:




On Fri, Nov 23, 2012 at 11:12 AM, Michael Herrmann
mailto:michael.herrm...@getautoma.com>>
wrote:

Hi,

do you think it's bad style to override the built-in function
`type`? I'm co-developing a GUI automation library called Automa
(http://www.getautoma.com) and 'type' would be a very fitting name
for a function that generates artificial key strokes.

Personally, I think this is a horrible idea.  On this list and the tutor
list, people often use variable names that are already defined in the
language.  It leads to non obvious errors -- especially when revisting
old code.  Why not call the thing 'key_stroke'?


I agree.

--
Terry Jan Reedy

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

argparse -- mutually exclusive sets of arguments?

[Roy Smith]

My command either takes two positional arguments (in which case, both 
are required):

$ command foo bar

or the name of a config file (in which case, the positional arguments 
are forbidden):

$ command --config file

How can I represent this with argparse; add_mutually_exclusive_group() 
isn't quite the right thing.  It could specify that foo and --config are 
mutually exclusive, but not (as far as I can see) the more complicated 
logic described above.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Why queue.empty() returns False even after put() is called?

[MRAB]

On 2012-11-23 16:57, Peng Yu wrote:

Hi,

The empty() returns True even after put() has been called. Why it is
empty when there some items in it? Could anybody help me understand
it? Thanks!

~/linux/test/python/man/library/multiprocessing/Queue/empty$ cat
main.py
#!/usr/bin/env python

import multiprocessing

queue = multiprocessing.Queue()
print queue.empty()
queue.put(['a', 'b'])
queue.put(['c', 'd'])
print queue.empty()


It works correctly for me.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Why queue.empty() returns False even after put() is called?

[Ian Kelly]

On Fri, Nov 23, 2012 at 9:57 AM, Peng Yu  wrote:
> Hi,
>
> The empty() returns True even after put() has been called. Why it is
> empty when there some items in it? Could anybody help me understand
> it? Thanks!
>
> ~/linux/test/python/man/library/multiprocessing/Queue/empty$ cat
> main.py
> #!/usr/bin/env python
>
> import multiprocessing
>
> queue = multiprocessing.Queue()
> print queue.empty()
> queue.put(['a', 'b'])
> queue.put(['c', 'd'])
> print queue.empty()

According to the docs, the Queue uses a background thread to load data into it:

When a process first puts an item on the queue a feeder thread is
started which transfers objects from a buffer into the pipe.

Most likely it still appears to be empty because this thread has not
had a chance to run yet.  If you try inserting a time.sleep() call,
you should see the queue become non-empty once the background thread
has run.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: argparse -- mutually exclusive sets of arguments?

[Terry Reedy]

On 11/23/2012 1:46 PM, Roy Smith wrote:

My command either takes two positional arguments (in which case, both
are required):

$ command foo bar

or the name of a config file (in which case, the positional arguments
are forbidden):

$ command --config file

How can I represent this with argparse; add_mutually_exclusive_group()
isn't quite the right thing.  It could specify that foo and --config are
mutually exclusive, but not (as far as I can see) the more complicated
logic described above.


Make the two positional arguments be one duple?
Or tell argparse that all three are optional and handle the 'more 
complicated logic' in your own code after argparse returns.



--
Terry Jan Reedy

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

Re: Why queue.empty() returns False even after put() is called?

[Cameron Simpson]

On 23Nov2012 11:53, Ian Kelly  wrote:
| On Fri, Nov 23, 2012 at 9:57 AM, Peng Yu  wrote:
| > The empty() returns True even after put() has been called. Why it is
| > empty when there some items in it? Could anybody help me understand
| > it? Thanks!
| >
| > ~/linux/test/python/man/library/multiprocessing/Queue/empty$ cat
| > main.py
| > #!/usr/bin/env python
| >
| > import multiprocessing
| >
| > queue = multiprocessing.Queue()
| > print queue.empty()
| > queue.put(['a', 'b'])
| > queue.put(['c', 'd'])
| > print queue.empty()
| 
| According to the docs, the Queue uses a background thread to load data into 
it:
| 
| When a process first puts an item on the queue a feeder thread is
| started which transfers objects from a buffer into the pipe.
| 
| Most likely it still appears to be empty because this thread has not
| had a chance to run yet.  If you try inserting a time.sleep() call,
| you should see the queue become non-empty once the background thread
| has run.

Conversely, might it not appear empty because the objects have been
thrown at the pipe already, appearing to have been consumed? Or is there
end-to-end handshaking controlling what .empty() tests? (Though again,
the far end may have grabbed them already too.)
-- 
Cameron Simpson 

The ZZR-1100 is not the bike for me, but the day they invent "nerf" roads
and ban radars I'll be the first in line..AMCN
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Is it bad style to override the built-in function `type`?

[Cameron Simpson]

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: Getting a seeded value from a list

[Chris Angelico]

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

Re: 10 sec poll - please reply!

[Steven D'Aprano]

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: Problem with subprocess.call and windows schtasks

[Prasad, Ramit]

Dave Angel wrote:
> 
> On 11/20/2012 06:41 PM, Tom Borkin wrote:
> 
> (Please don't top-post.  Now we lose all the context)
> > Using shlex, I now have this:
> > #!\Python27\python
> > import os, subprocess
> > path = os.path.join("C:\\", "Program Files", "Apache Group", "Apache2",
> > "htdocs", "ccc", "run_alert.py")
> > #subprocess.call(['SchTasks', '/Create', '/SC', 'ONCE', '/TN', '"test"',
> > '/TR', path, '/ST', '23:50'])
> > subprocess.call(['SchTasks', '/Create', '/SC', 'ONCE', '/TN', '"test"',
> > '/TR', 'run_alert.py', '/ST', '23:50'])
> > Both of the above commands throw the same error:
> > ERROR: The filename, directory name or volume label syntax is incorrect.
> 
> I don't use Windows, but doesn't a Windows program usually have an .exe
> extension?  So why would you expect it to find SchTasks ?  Adding
> extensions is a shell feature, and you're not using the shell.
> 
> Also, you should take a look at the value "path".  On Linux, it shows up as:
> 
> C:\\/Program Files/Apache Group/Apache2/htdocs/ccc/run_alert.py
> 
> It'll be different under Windows, but probably still wrong.

Windows 7 + Python 2.6
>>> os.path.join("C:\\", "Program Files", "Apache Group", "Apache2",
...  "htdocs", "ccc", "run_alert.py")
'C:\\Program Files\\Apache Group\\Apache2\\htdocs\\ccc\\run_alert.py'


~Ramit


This email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of
securities, accuracy and completeness of information, viruses,
confidentiality, legal privilege, and legal entity disclaimers,
available at http://www.jpmorgan.com/pages/disclosures/email.  
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: argparse -- mutually exclusive sets of arguments?

[Joshua Landau]

On 23 November 2012 18:46, Roy Smith  wrote:

> My command either takes two positional arguments (in which case, both
> are required):
>
> $ command foo bar
>
> or the name of a config file (in which case, the positional arguments
> are forbidden):
>
> $ command --config file
>
> How can I represent this with argparse; add_mutually_exclusive_group()
> isn't quite the right thing.  It could specify that foo and --config are
> mutually exclusive, but not (as far as I can see) the more complicated
> logic described above.


Do you need to use argparse?

If not, I've been recommending docopt due to its power and simplicity:

-START -
"""
Command.

Usage:
command  
command --config=

Options:
foo  The egg that spams
bar  The spam that eggs
--config=  The config that configures
"""

from docopt import docopt

if __name__ == '__main__':
arguments = docopt(__doc__)
print(arguments)
- END 

- USAGE -
%~> python simple_docopt.py foobar barfoo
{'--config': None,
 '': 'barfoo',
 '': 'foobar'}
%~> python simple_docopt.py foobar
Usage:
simple_docopt.py  
simple_docopt.py --config=
%~> python simple_docopt.py --config=turtle.conf
{'--config': 'turtle.conf',
 '': None,
 '': None}
%~> python simple_docopt.py --config=turtle.conf not allowed
Usage:
simple_docopt.py  
simple_docopt.py --config=
--- END USAGE ---
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: argparse -- mutually exclusive sets of arguments?

[Ian Kelly]

On Fri, Nov 23, 2012 at 11:46 AM, Roy Smith  wrote:
> My command either takes two positional arguments (in which case, both
> are required):
>
> $ command foo bar
>
> or the name of a config file (in which case, the positional arguments
> are forbidden):
>
> $ command --config file
>
> How can I represent this with argparse; add_mutually_exclusive_group()
> isn't quite the right thing.  It could specify that foo and --config are
> mutually exclusive, but not (as far as I can see) the more complicated
> logic described above.

I don't think you could even do the former.  An argument must be
optional in order to be mutually exclusive with anything.  This works,
however:

parser = argparse.ArgumentParser()
group = parser.add_mutually_exclusive_group(required=True)
group.add_argument('--config', type=file)
group.add_argument('--foobar', nargs=2, metavar=('FOO', 'BAR'))
print parser.parse_args()

Downsides are that the resulting interface is a little more formal and
a little less friendly, and unless you customize the action you'll
wind up with a 2-element 'foobar' arg instead of separate 'foo' and
'bar' args.
-- 
http://mail.python.org/mailman/listinfo/python-list