Would Anonymous Functions Help in Learning Programming/Python?

[Cristian]

A friend of mine is an engineer and he's been needing to do more and
more programming as he goes on with is career. I convinced him to
learn Python instead of Perl and he's really started to like it. He
usually comes to me when he can't accomplish a task with his current
knowledge and I introduce him to a new feature in Python. FYIW, he
thought List Comprehensions were freakin' awesome. He's started
writing his own personal scripts for tasks like web scraping. So, from
personal experience, Python truly is a great first language to learn.

Although his learning experience has gone mostly smoothly, he's hit a
lot of speed bumps with functions. Specifically, he's having trouble
thinking of functions as first order data (don't worry, I haven't
confused him with such terminology yet). He had a little trouble
understanding that you can pass functions as arguments to other
functions (e.g., passing a key to the list.sort method). He also had a
little trouble grasping functions within other functions. Last but not
least, he had trouble grasping methods in class declarations,
especially the required self as the first argument (I'm sure he wasn't
the first).

Now, my friend's a smart guy so I know it isn't any lack of brain
cells on his part. I still remember many students in my CS classes
having trouble grasping the very same concept. And, after we finally
get a hold of first order functions, we appreciate its incorporation
into languages. It would be a shame if my friend just learns the
motions and never incorporates first order functions into his
programs. I began to wonder if there was anything Python could do to
help newcomers grasp the power of first order functions or, as
Pythonistas put it, everything is an object.

To me, the biggest setback for new programmers is the different syntax
Python has for creating functions. Instead of the common (and easy to
grasp) syntax of foo = bar Python has the def foo(): syntax. So, when
a new programmer is first introduced to functions they are immediately
confronted with the notion that functions are "different". After all,
they have their own special syntax. This seems to only further the
separation newbies make between "data" and "functions" or "stuff" and
"actions". Now, the vast majority of us learned this dichotomy when we
first began to program, so we are ingrained to assume and even expect
a different syntax for function declaration, but in a program like
Python there doesn't seem to be any other reason to have it.
Furthermore, I think it actually inhibits the learning of the
uninitiated. We can, of course, keep the current syntax as sugar.

To someone who's learning to program wouldn't a syntax like the
further give them all they need and also reinforces the idea that
functions are data just like everything else?

my_function = function(foo, bar): pass
an_instance_method = function(self, foo): pass
a_method_declaration = method(self, foo): pass

The last one is mostly my pet peeve of having Python "magically"
create methods out of (what is essentially) a function declaration.
When I first learned it, it felt wrong but you had to press through it
because there was really no other way of declaring methods.

What do you think? Have you hit this roadblock when helping others
learn Python? Does the current syntax make you feel that functions are
still treated as second class (get it?) citizens?

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

Re: Would Anonymous Functions Help in Learning Programming/Python?

[Cristian]

On Sep 21, 2:48 pm, [EMAIL PROTECTED] wrote:
> There are already anonymous functions in Python.
>
> lambda x, y, z: x + y + z
>
> is the same as:
>
> def _(x, y, z): return x + y + z
>
> As for the method stuff, check out staticmethod(). If you assign
> staticmethod() to an object, it will be treated as a
> normal function and not as a "method."
>
> I have my own personal opinions about how methods should be in Python,
> but, whatever. It's weird to deal with stuff like this:
>
> x.y = re.match # Assign a function to an attribute of a class, but it
> doesn't work because you can't assign anything but methods!
> x.y = staticmethod(re.match) # Ugly

True, there is lambda, but that is very limited. It might be useful
for key arguments, but not much else. It doesn't solve the teaching
problem of "See, functions are just like any other data type. You can
assign it to a variable." It would be a footnote if it's mentioned at
all. My hope is to subtly reinforce the notion that functions are data
and can be passed around. The current function declaration doesn't
help with this. Creating a function and assigning it to a name is
exactly what Python does, why not have it come out in the syntax? It's
not necessary, yes, but I think it would be helpful for teaching
purposes.

Again, it's not necessary as much as it's more intuitive and obvious
what's going on. This helps a beginner sort out the process from the
syntax without taking it on faith. They can see the class declaration
and see "I'm defining just another attribute to this class only this
time it happens to be method".

There is nothing functionally lacking in Python. I'm just curious if
there's anything Python can do syntax-wise to help a person better
grasp programming ideas and Python's inner workings.

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

Re: Would Anonymous Functions Help in Learning Programming/Python?

[Cristian]

On Sep 21, 3:22 pm, [EMAIL PROTECTED] wrote:
> On Sep 21, 6:07 pm, Cristian <[EMAIL PROTECTED]> wrote:
>
>
>
> > On Sep 21, 2:48 pm, [EMAIL PROTECTED] wrote:
>
> > > There are already anonymous functions in Python.
>
> > > lambda x, y, z: x + y + z
>
> > > is the same as:
>
> > > def _(x, y, z): return x + y + z
>
> > > As for the method stuff, check out staticmethod(). If you assign
> > > staticmethod() to an object, it will be treated as a
> > > normal function and not as a "method."
>
> > > I have my own personal opinions about how methods should be in Python,
> > > but, whatever. It's weird to deal with stuff like this:
>
> > > x.y = re.match # Assign a function to an attribute of a class, but it
> > > doesn't work because you can't assign anything but methods!
> > > x.y = staticmethod(re.match) # Ugly
>
> > True, there is lambda, but that is very limited. It might be useful
> > for key arguments, but not much else. It doesn't solve the teaching
> > problem of "See, functions are just like any other data type. You can
> > assign it to a variable." It would be a footnote if it's mentioned at
> > all. My hope is to subtly reinforce the notion that functions are data
> > and can be passed around. The current function declaration doesn't
> > help with this. Creating a function and assigning it to a name is
> > exactly what Python does, why not have it come out in the syntax? It's
> > not necessary, yes, but I think it would be helpful for teaching
> > purposes.
>
> > Again, it's not necessary as much as it's more intuitive and obvious
> > what's going on. This helps a beginner sort out the process from the
> > syntax without taking it on faith. They can see the class declaration
> > and see "I'm defining just another attribute to this class only this
> > time it happens to be method".
>
> > There is nothing functionally lacking in Python. I'm just curious if
> > there's anything Python can do syntax-wise to help a person better
> > grasp programming ideas and Python's inner workings.
>
> Guido apparently doesn't like lambda; I'm not really sure why, it's
> extremely useful. There were rumors of it leaving in Python 3000, but
> thankfully there was the decision to keep them. (I have a feeling if
> they weren't kept in, a project fork would have happened or such.)
> Anyway, one of the biggest problems implementation wise is indentation
> in an expression - there is no expression currently that uses
> significant whitespace. Python draws a pretty clear line between
> expression and statement. I do agree with you however, it seems as if
> there is an arbitrary line between function definitions and normal
> variable assignment that shouldn't be there for the sake of
> consistency.
>
> A question: if you WERE to implement function definitions as normal
> expressions, how would you go about embedding it within an expression?
>
> x = map(def a:
> 
> 
> 
> , [1, 2, 3])
>
> It looks hideous in my opinion and lining up the , with the def is
> ugly. Not to mention currently, inside groupings, whitespace is
> ignored. How would you handle a whitespace signif. expression inside a
> grouping which by definition ignores whitespace?

Yeah, I agree, that does look pretty ugly. Correct me if I'm wrong,
but I thought the way Python determines a block is by the whitespace
of the first line. So, as long as the spacing (or !tabbing!) is
consistent from line to line the parser will know it's part of the
same block. From that I don't think the parser would have much trouble
extracting the function definition from the above example. I would
change the word "def". That's never been informative enough for me. I
would follow Javascript and call it "function." Also, I think
parentheses should be required.

If there's no implementation problem, I don't see why Python shouldn't
allow the above example, but I would certainly discourage it. Just
like Python doesn't prevent you from writing an insanely long and
convoluted function, Python shouldn't enforce any arbitrary length in
anonymous functions. I think the above example should be discouraged
as a style violation, not syntax.

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

Re: Would Anonymous Functions Help in Learning Programming/Python?

[Cristian]

On Sep 21, 3:44 pm, Ron Adam <[EMAIL PROTECTED]> wrote:

> I think key may be to discuss names and name binding with your friend.  How
> a name is not the object it self, like a variable is in other languages.
> For example show him how an object can have more than one name.  And discus
> how names can be bound to nearly anything, including classes and functions.

I could discuss name binding but it would be great if Python said this
itself. After all, you can even bind a module with the foo = bar
syntax by using __import__ function. If function definitions followed
the same pattern, I think a beginner would subconsciously (maybe even
consciously) realize that function names are just like everything
else. Actually, this would be helpful for many people. If you come
from a language like Java you're used to thinking of attributes and
methods as living in different namespaces. I think a new syntax will
encourage seasoned programmers think in a more Pythonic way.

Python has done a very good job in easing people into programming. My
friend doesn't come to me very often because the syntax is clear and
simple and the builtin datatypes allow you to do so much. My goal is
that I would never have to explain to him about name binding; that
he'd pick it up by learning the language on his own. He's learned
lists, dictionaries and even some OOP without me. I don't think name
binding would be a stretch.

> You could also discus factory functions with him.  Once he gets that a
> function can return another function, then it won't be so much of a leap
> for a function to take a function as an argument.

I think this isn't the most intuitive way of approaching first order
functions. It's true that if a function can return another function
then a function must be first order (i.e., it's just like any other
variable), but that seems almost backwards to me. I think it would
make more sense to have beginners _know_ that functions are like all
other variables and can therefore be passed by other functions or
returned by other functions. That I think would be better accomplished
if they define functions the same way you would define other variables
that you know can be passed and returned.


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

Re: Would Anonymous Functions Help in Learning Programming/Python?

[Cristian]

On Sep 21, 4:27 pm, "J. Cliff Dyer" <[EMAIL PROTECTED]> wrote:
> Cristian wrote:
> > On Sep 21, 3:44 pm, Ron Adam <[EMAIL PROTECTED]> wrote:
>
> >> I think key may be to discuss names and name binding with your friend.  How
> >> a name is not the object it self, like a variable is in other languages.
> >> For example show him how an object can have more than one name.  And discus
> >> how names can be bound to nearly anything, including classes and functions.
>
> > I could discuss name binding but it would be great if Python said this
> > itself. After all, you can even bind a module with the foo = bar
> > syntax by using __import__ function. If function definitions followed
> > the same pattern, I think a beginner would subconsciously (maybe even
> > consciously) realize that function names are just like everything
> > else. Actually, this would be helpful for many people. If you come
> > from a language like Java you're used to thinking of attributes and
> > methods as living in different namespaces. I think a new syntax will
> > encourage seasoned programmers think in a more Pythonic way.
>
> However, you still have to solve the problem of using a single-line
> construct (x = y) with a multi-line definition.  That is the essential
> difference that def is designed to solve.  The __import__ trick works
> because import is also a single line construct.
>
> The only proposal given in this thread is using consistent indentation
> within the parentheses, but parentheses are already explicitly designed
> to let you ignore the whitespace rules.  To suddenly create a situation
> in which you have significant whitespace on the right side of an
> assignment statement, and *within parentheses* will break too much code,
> and make the solution unnecessarily ugly.  Multi-line lambdas have been
> rejected because of this very problem, so unless you have a clean
> solution, I think your proposal falls into the category of "would be
> nice, but not in Python."
>
> Cheers,
> Cliff

http://www.artima.com/weblogs/viewpost.jsp?thread=147358

You, Guido, and I all agree that anonymous functions in expressions
are ugly. There's no argument there. I wouldn't expect any self
respecting programmer to do such a thing even if it was available to
them (in Python that is).

I suppose my question is, taking into account the potential of ugly
code that could be created, and the fact that it's technically
feasible, would it still be worth adding anonymous functions to
explicitly show the first order nature of functions and show that
functions are in the same namespace as all other variables?

I suppose a solution could be to allow the my_function = function(foo,
bar): ... syntax but throw a syntax error if the function isn't being
bound to a variable, but that would cause other problems. From that
syntax you would assume that it's possible to create an anonymous
function wherever a variable is expected. That's not very intuitive
either.

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

Re: Would Anonymous Functions Help in Learning Programming/Python?

[Cristian]

On Sep 21, 4:47 pm, "Sean Tierney" <[EMAIL PROTECTED]> wrote:
> Just tell him that "functions are like all  other variables and can
> therefore be passed by other functions or returned by other functions.
> "
>



I could """Just tell him that "functions are like all  other variables
and can
therefore be passed by other functions or returned by other functions.
" """ but wouldn't it be great if Python did this for me? It seems to
me that the ability for Python to explicitly state that functions-are-
like-other-variables is there so why not expose it?

> If your friend understands variables and functions and he can't make
> the "leap" (and assuming you're right, of course) then your friend
> doesn't understand variables and functions.

To say that you understand variables and functions is language
specific. You can't translate your knowledge of variables and
functions from Python to Java and vice-versa. They are treated
completely different. Perhaps you can translate your Python
understanding of functions and variables to Javascript but not to C.


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

Re: Would Anonymous Functions Help in Learning Programming/Python?

[Cristian]

On Sep 21, 5:21 pm, Bruno Desthuilliers
<[EMAIL PROTECTED]> wrote:

> Ok, then what about classes ? They also are objects-like-any-other,
> after all. So should we have this syntax too ?
>
> MyClass = class(ParentClass):
>__init__ = function (self, name):
>  self.name = name
>
> ?-)

For consistency I would suggest this, but Python already does this!

Foo = type('Foo', (object, ), {'bar': lambda self, bar: bar})

I've created a new class and then binded it to name afterwards. If you
can import modules without special syntax and you can create classes
without special syntax, why should functions be treated any
differently?

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

An "Object" class?

[Cristian Cocos]

I know that "Everything is an object in python" as per
https://mail.python.org/pipermail/python-list/2015-June/691689.html. Also,
I am more-or-less convinced that there is a generic "class" (aka "type")
(meta)class (which would be an object, of course). Is there, however, a
generic "object" (meta)class (which would obviously be an object as well as
a class)?

Christian

-- 
"People think that I must be a very strange person. This is not correct. I
have the heart of a small boy. It is in a glass jar on my desk." -- Stephen
King
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An "Object" class?

[Cristian Cocos]

Thank you! What would be the names of the *class *class, and of the *function
*class please?

On Tue, Aug 27, 2019 at 1:39 PM Calvin Spealman  wrote:

> Yes, it is called `object` and `object` is the base class of ALL other
> classes, including `type`. In fact, it is the only class which does not
> itself inherit from anything.
>
> On Tue, Aug 27, 2019 at 1:35 PM Cristian Cocos  wrote:
>
>> I know that "Everything is an object in python" as per
>> https://mail.python.org/pipermail/python-list/2015-June/691689.html.
>> Also,
>> I am more-or-less convinced that there is a generic "class" (aka "type")
>> (meta)class (which would be an object, of course). Is there, however, a
>> generic "object" (meta)class (which would obviously be an object as well
>> as
>> a class)?
>>
>> Christian
>>
>> --
>> "People think that I must be a very strange person. This is not correct. I
>> have the heart of a small boy. It is in a glass jar on my desk." --
>> Stephen
>> King
>> --
>> https://mail.python.org/mailman/listinfo/python-list
>>
>
>
> --
>
> CALVIN SPEALMAN
>
> SENIOR QUALITY ENGINEER
>
> cspea...@redhat.com  M: +1.336.210.5107
> [image: https://red.ht/sig] <https://red.ht/sig>
> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
>


-- 
"People think that I must be a very strange person. This is not correct. I
have the heart of a small boy. It is in a glass jar on my desk." -- Stephen
King
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An "Object" class?

[Cristian Cocos]

Thank you! I can see that the taxonomy of built-in classes (i.e. the
subclass/superclass relations) is not very developed. At the very least I
would have loved to see stuff such as int declared as a subClass/subType
of float and the like--that is, a class taxonomy in tune with standard
mathematical practice, but I am guessing that mathematical kosher-ness had
to take a back seat to implementational concerns.

Neither does the numbers package bring any order or clarity into this; take
for example the following sentence from the standard type hierarchy (
https://docs.python.org/3/reference/datamodel.html#the-standard-type-hierarchy):
"There are two types of integers [numbers.Integral]: Integers (int) ...
[and] Booleans (bool)" I, for one, cannot help but read this as a subtype
declaration, which appears to be the wrong construal. For one, I am not
sure that numbers.Integral is a type that is returned by the type()
function, regardless of the input argument. Furthermore, it looks to me
that no instance of the int type is an instance of the numbers.Integral
type (and that is based on the fact that type.mro() function applied to
some integer does not list numbers.Integral among the returned values
(although this may also be a consequence of the fact that type() never
returns numbers.Integral)).

Anyway, I am looking forward to your correcting any of the above assertions.

C

On Tue, Aug 27, 2019 at 5:00 PM Terry Reedy  wrote:

> On 8/27/2019 2:19 PM, Cristian Cocos wrote:
> > Thank you! What would be the names of the *class *class,
> > and of the *function *class please?
>
> Use type(ob) to get the internal name of the class of an object.
> Built-in classes that users may need to call in python code are bound to
> the same name in __builtins__, as if __builtins__ were build with class
> statements. but many are not.
>
>  >>> type(object)
> 
>  >>> type(type)
> 
>  >>> type(int)
> 
>  >>> type(abs)  # built-in function
> 
>
> Users can usefully call 'type' but not 'builtin_function_or_method'.
>
>  >>> def(f): pass
>
>  >>> type(f)  # User-defined function.
> 
>  >>> l = lambda: None  # Equivalent lambda expression.
>  >>> type(l)
> 
>
> Creating a function by calling 'function' instead of using 'def' or
> 'lambda' is a super expert endeaver, and the details are CPython
> specific and subject to change in any version.
>
>  >>> type(list.__add__)
> 
>  >>> type(list.append)
> 
>  >>> for k, v in vars(list).items(): print(k, type(v))
> # 36 lines.
>
> To see super classes of a class, use type.mro(cls).  The returned list
> always begins with cls and ends with 'object'
>
>  >>> mro = type.mro
>  >>> mro(object)
> []  # As Chris said, baseclass has no superclass.
>  >>> mro(type)
> [, ]
>  >>> mro(list)
> [, ]
> # Nearly all built-in classes return [cls, 'object'].
>  >>> mro(bool)
> [, , ]
> # The only exception I can think of.
>
> --
> Terry Jan Reedy
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>


-- 
"People think that I must be a very strange person. This is not correct. I
have the heart of a small boy. It is in a glass jar on my desk." -- Stephen
King
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An "Object" class?

[Cristian Cocos]

Thank you! For some reason I didn't think of using issubclass and
isinstance in my Python types investigation. As you may have already
noticed, I am a Python beginner. I also happen to have a Logic and
Foundations of Mathematics background, hence I am tempted to investigate
Python's type taxonomy from a basic mathematical angle, with an eye to
"recovering" basic mathematical notions such as set membership, set
inclusion etc. So far, I have been living under the impression that type()
is akin to set membership (in a meta-Python approach), hence it should
ideally match the results of isinstance(), but that does not happen:

>>> type(print)

>>> isinstance(print, builtin_function_or_method)
Traceback (most recent call last):
  File "", line 1, in 
NameError: name 'builtin_function_or_method' is not defined

Just curious why builtin_function_or_method doesn't work as an argument of
isinstance(). After all,  builtin_function_or_method is a type, right?

The bottom line is that I am trying to figure out where exactly the world
of Python types _diverges from_ what I would expect as a mathematician. It
makes it easier for me to learn Python this way.

Many thanks,

C

On Wed, Aug 28, 2019 at 11:56 PM Alan Bawden  wrote:

> Cristian Cocos  writes:
>
> > Thank you! I can see that the taxonomy of built-in classes (i.e. the
> > subclass/superclass relations) is not very developed. At the very least I
> > would have loved to see stuff such as int declared as a subClass/subType
> > of float and the like--that is, a class taxonomy in tune with standard
> > mathematical practice, but I am guessing that mathematical kosher-ness
> had
> > to take a back seat to implementational concerns.
>
> Except that numbers of type `int' are _not_ a subset of numbers of
> type `float'!  Some ints are much larger that the largest float.
>
> In fact, both `int' and `float' are subclasses of `numbers.Real'.  While it
> is true that `numbers.Real' does not appear in the list returned by
> `type.mro(int)', nevertheless `issubclass(int, numbers.Real)' and
> `isinstance(2, numbers.Real)' are true.  `type.mro' tells you something
> about the _implementation_ of `int' and `float' that you _usually_
> shouldn't
> concern yourself with.  Stick to `isinstance' and `issubclass' and
> everthing looks pretty kosher.
>
> --
> Alan Bawden
> --
> https://mail.python.org/mailman/listinfo/python-list
>


-- 
"People think that I must be a very strange person. This is not correct. I
have the heart of a small boy. It is in a glass jar on my desk." -- Stephen
King
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An "Object" class?

[Cristian Cocos]

Thank you! Will give the "types" module a whirl.

Otherwise, the whole idea behind building a rigorous taxonomical hierarchy
("taxonomy") is to provide a simpler management of the wealth of features
objects have. And that is because entities belonging to the same
taxonomical class ("clade") have common features, and also inherit the
features of the taxonomical parent. A kosher type hierarchy (or class
taxonomy) is thus meant to answer precisely your concern about
entity/object behavior. Now, it may be that this was not the intention of
Python developers when they came up with the breakdown of the class of
objects into types/classes, in which case the term "type" and derivatives
(subtype, supertype etc.) used in this context is nothing but a regrettable
misnomer. Then maybe I should re-direct my quest away from studying the
type hierarchy, toward asking for built-in-object inheritance: Is there a
diagram of built-in-object inheritance available anywhere?

Many thanks for the clarifications,

C

On Fri, Aug 30, 2019 at 3:47 AM Gregory Ewing 
wrote:

> Cristian Cocos wrote:
>
> >>>>type(print)
> >
> > 
> >
> >>>>isinstance(print, builtin_function_or_method)
> >
> > Traceback (most recent call last):
> >   File "", line 1, in 
> > NameError: name 'builtin_function_or_method' is not defined
> >
> > Just curious why builtin_function_or_method doesn't work as an argument
> of
> > isinstance().
>
> Because the type object in question is not bound to the name
> 'builtin_function_or_method' in the builtin namespace. There
> is a way to get at it, though:
>
>  >>> import types
>  >>> types.BuiltinFunctionType
> 
>  >>> isinstance(print, types.BuiltinFunctionType)
> True
>
> When it comes to objects that form part of the interpreter's
> internal machinery, the names shown when you print their types
> are often just suggestive and aren't meant to be taken literally.
> Most of them are available in the 'types' module, however,
> possibly under different names. The reasons for all this are
> buried in a lot of messy history.
>
> > The bottom line is that I am trying to figure out where exactly the world
> > of Python types _diverges from_ what I would expect as a mathematician.
> It
> > makes it easier for me to learn Python this way.
>
> I'm not sure that focusing on classes as mathematical sets is all
> that useful. In Python, what class an object belongs to isn't
> usually very important. Much more relevant is how the object
> *behaves*. We call this "duck typing" -- if it walks like a duck
> and quacks like a duck then it might as well be a duck, even if
> it doesn't belong to a class called "Duck".
>
> This is why Python doesn't have e.g. an elaborate tower of
> numeric types as is seen in some other languages. It just isn't
> necessary for getting things done, and Python, being a very
> pragmatic language, is all about getting things done.
>
> --
> Greg
> --
> https://mail.python.org/mailman/listinfo/python-list
>


-- 
"People think that I must be a very strange person. This is not correct. I
have the heart of a small boy. It is in a glass jar on my desk." -- Stephen
King
-- 
https://mail.python.org/mailman/listinfo/python-list

[Fwd: Re: Uso de variable Global]

[cristian abarzúa]

- Mensaje reenviado 
> De: Peter Otten <__pete...@web.de>
> Para: python-list@python.org
> Asunto: Re: Uso de variable Global
> Fecha: Thu, 02 Dec 2010 23:06:25 +0100
> Grupos de noticias: comp.lang.python
> 
> craf wrote:
> 
> > Hola.
> > 
> > 
> > Estoy probando Tkinter y escribí este pequeño código el cual crea un
> > formulario con un textbox y un botón. Al ingresar un dato en el textbox
> > y presionar el botón, se imprime en la consola el valor.
> > 
> > 
> > ---CODE
> > 
> > from Tkinter import *
> > 
> > def muestra():
> > print(valor.get())
> > 
> > class App:
> > def __init__(self,master):
> > global valor
> > valor = StringVar()
> > e = Entry(master,textvariable=valor).pack()
> > b = Button(master,text='Mostrar',command=muestra).pack()
> 
> pack() returns None so both e and b set to None here. In this case it 
> doesn't matter because you don't do anything with e and b.
> 
> > master = Tk()
> > app = App(master)
> > master.mainloop()
> > 
> > -
> > 
> > Funciona, pero tuve que hacer uso de una variable Global.
> > 
> > Pregunta: ¿Es valida esta forma?, ¿Se puede hacer de otra forma, sin
> > ocuparla?.
> 
> I'd prefer to make valor an attribute and muestra() a method:
> 
> from Tkinter import * 
> 
> class App:
> def __init__(self, master):
> self.valor = StringVar()
> Entry(master, textvariable=self.valor).pack()
> Button(master, text='Mostrar', command=self.muestra).pack()
> def muestra(self):
> print self.valor.get()
> 
> master = Tk()
> app = App(master)
> master.mainloop()

Thanks!, Sorry for the Spanish mail.

Regards

Cristian


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

"Download/windows" site page

[Cristian Consonni]

Dear all,

I'm not sure this is the right place to point this out, but on this page:

http://www.python.org/download/windows/

It is not mentioned "Windows 7".

Is there some problem with 7 or it is simply an omission?
A friend of mine is refusing to install python on his machine because
"it does not say it is compatible with Windows 7" (sic).

So, may somebody fix that?

Thanks in advance.

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

Re: "Download/windows" site page

[Cristian Consonni]

2010/12/13 Martin v. Loewis :
[...]
>> It is not mentioned "Windows 7".
>>
>> Is there some problem with 7 or it is simply an omission?
>
> It's simply an omission. You'll notice that Windows 2003 and Windows
> 2008, as well as Windows 2003 R2 and Windows 2008R2 are omitted as
> well. Likely, Python also works on Windows Media Center Edition, which
> is also omitted.
>
>> So, may somebody fix that?
>
> I'd rather not fix it by adding all product names that Microsoft has
> used for Windows. How about "Microsoft Windows (XP and later releases)"?

Sounds as a reasonable solution to me. Thank you.

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