list(), tuple() should not place at "Built-in functions" in documentation
As telling in the subject,because "list" and "tuple" aren't functions,they are types.Is that right? -- http://mail.python.org/mailman/listinfo/python-list
Re: list(), tuple() should not place at "Built-in functions" in documentation
Hey guy,thx for you feedback first. But I can't follow your opinion.Why?because of the list & tuple are placed at built-in function,so before I type 'list' unintentionally on the pyshell and it show me "", I never know that the name 'list' is a type,I used to consider it's a function to produce 'list' type. so,after I figure out this matter,I have to change all my code "assert isinstance(someobj, (type([]), type((0, " to "assert isinstance(someobj, (list, tuple))",that's not a funny job. I hope that I can stay in the Python abstract layer to solve problem(although go to the C API is OK but I don't want to),I'm going to trust what the doc telling me,so I hope the doc is exact enough.And the doc in the distribution maybe the most popular one. @Steven D'Aprano,yes they can be used as function,but they aren't function and shouldn't confuse newcomers by this. -- http://mail.python.org/mailman/listinfo/python-list
Re: list(), tuple() should not place at "Built-in functions" in documentation
Why I use assertion,please check this code: """ class User(object):pass class Student(User):pass class Professional(User):pass def add(user): assert(user, User) def add(users): assert(users, (tuple, list)) #If necessary I'll also check every obj in the sequence to see whether it's a User. """ I just follow some coding rules of me: 1. Controlling "input" strictly. 2. In a function keep doubting on its parameters until they're checked. 3. Let potential errors raise as early as possible. -- http://mail.python.org/mailman/listinfo/python-list
Re: list(), tuple() should not place at "Built-in functions" in documentation
> Perhaps you meant this? > > assert isinstance(user, User) Yes I meant this,sorry,my mistake. Thx for your and Ben's feedbacks first,it's appreciated. your points is taken by me,but I want to make my opinion more clearly. The assertion is JUST show to my function callers during development,warning that "I want a list/tuple,not some other objects"(BTW, your practice of wrapping arguments to iter is good,I'll take this to improve my code,thx again.).And assertion's off when running Python with the -O (optimize) switch is what I expect,it isn't necessary in production code.Argument validation is done by constuctor of object which I used in assertion. I also have a few words about duck-typing.Duck-typing is good,but how about if I offer a convenient way to my function user by producing or changing what he want to pass me to a *real* duck?Is that more explicit to my user? Anyway,I'll look at my principles which may need some changes or improvements. -- http://mail.python.org/mailman/listinfo/python-list
Re: list(), tuple() should not place at "Built-in functions" in documentation
Supplement: The assertion will not be handled anyway. I want AssertionError raise as early as possible.(mentinoed before) -- http://mail.python.org/mailman/listinfo/python-list
How to pass class instance to a method?
How to "statically type" an instance of class that I pass to a method of other instance? I suppose there shall be some kind of method decorator to treat an argument as an instance of class? Generally it is needed so IDE (PyCharm) can auto-complete instance's methods and properties. Pseudo-python-code example: i = MyClass() xxx(i, 1, 2); ... def xxx(self, MyClass myclass, number, foobar): myclass.classsmethod() #myclass - is an instance of known class -- http://mail.python.org/mailman/listinfo/python-list
Re: 10 sec poll - please reply!
press_keys()
On Tuesday, November 20, 2012 2:18:38 PM UTC+2, 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
