Re: Help writelines
Hi,
You have to iterate.
Either with
for u in users:
fob.write( u + '\n' )
or with a lambda function.
always a good call: http://python.org/
greets,
M.
On 02/03/2012 09:27 PM, Anatoli Hristov wrote:
Hi everyone,
I`m totaly new in python and trying to figure out - how to write a
list to a file with a newline at the end of each object.
I tried alot of combinations :) like:
users = ['toli','didi']
fob=open('c:/Python27/Toli/username','w')
fob.writelines(users) + '%s\N'
fob.close()
or fob.writelines('\N' % users)
or fob.writelines('%s\N' % users)
but nothing of dose works...
Could you help me find out the right syntaxes?
Thanks
--
http://mail.python.org/mailman/listinfo/python-list
Bug? ( () == [] ) != ( ().__eq__([]) )
Hello, The following behaviour seen in 3.2 seems very strange to me: As expected: >>> () == [] False However: >>> ().__eq__([]) NotImplemented >>> [].__eq__(()) NotImplemented And: >>> bool(NotImplemented) True Hence: >>> bool(().__eq__([])) True >>> ( () == [] ) != ( ().__eq__([]) ) True How/why can this be intended? Thanks, everybody. Markus R. -- http://mail.python.org/mailman/listinfo/python-list
Re: Bug? ( () == [] ) != ( ().__eq__([]) )
Thanks for the good explanation. My intention was to pass a custom method/function as a comparator to an object. My misconception was, that __eq__ is equivalent to the '==' operator, and could be passed as a first class function. Apparently, that is not possible without wrapping the comparison into another function/method. Best regards, Markus R. On 05.08.2013 01:06, Chris Angelico wrote: On Sun, Aug 4, 2013 at 11:35 PM, Markus Rother wrote: Hello, The following behaviour seen in 3.2 seems very strange to me: As expected: () == [] False However: ().__eq__([]) NotImplemented [].__eq__(()) NotImplemented You don't normally want to be calling dunder methods directly. The reasoning behind this behaviour goes back to a few things, including a way to handle "1 == Foo()" where Foo is a custom type that implements __eq__; obviously the integer 1 won't know whether it's equal to a Foo instance or not, so it has to defer to the second operand to get a result. This deferral is done by returning NotImplemented, which is an object, and so is true by default. I don't see any particular reason for it to be false, as you shouldn't normally be using it; it's more like a "null" state, it means "I don't know if we're equal or not". If neither side knows whether they're equal, then they're presumed to be unequal, but you can't determine that from a single call to __eq__. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Language design
Hello all,
Thanks for this thread. Here are my two cents...
On 10.09.2013 08:09, Steven D'Aprano wrote:
> What design mistakes, traps or gotchas do you think Python has? Gotchas
> are not necessarily a bad thing, there may be good reasons for it, but
> they're surprising.
"""
1. Occasionally, one encounters a strange idiom. Syntactically
legal and consistent, though:
>>> +4++4
8
>>> -4+-4
-8
>>> -4-+4
-8
2. Reduce removed from standard library. That is a big fail, in
my opinion.
3. The default return value of methods is None instead of self.
If it was self, it would be possible to chain method calls (which
is called a cascade in smalltalk).
>>> lst = []
>>> lst.append(1).append(2).append(3) ## FAIL
Traceback (most recent call last):
...
AttributeError: 'NoneType' object has no attribute 'append'
Instead, this works:
>>> class Coll(list):
...
... def add(self, e):
... self.append(e)
... return self
...
>>> lst = Coll()
>>> lst.add(1).add(2).add(3) ## OK
[1, 2, 3]
A very practical use case is, that the return value of None makes
all of these methods unusable for reduce.
>>> from functools import reduce
...
>>> many = [{1: 'a'}, {2: 'b'}, {3: 'c'}]
...
>>> reduce(lambda d, other : d.update(other), many, {}) ## FAIL
Traceback (most recent call last):
...
AttributeError: 'NoneType' object has no attribute 'update'
Again, one would have to define an update function with an
explicit return value.
>>> many = [{1: 'a'}, {2: 'b'}, {3: 'c'}]
...
>>> def fn(d, other):
... d.update(other)
... return d
...
>>> reduce(fn, many, {}) ## OK
{1: 'a', 2: 'b', 3: 'c'}
4. As has been mentioned already, some built-in functions do magic
stuff behind the scenes:
>>> () == []
False
But:
>>> bool(().__eq__([]))
True
Because:
>>> ().__eq__([])
NotImplemented
which yields True when cast to boolean.
"""
Greets,
Markus
--
https://mail.python.org/mailman/listinfo/python-list
Re: Language design
On 10.09.2013 08:09, Steven D'Aprano wrote: > What design mistakes, traps or gotchas do you think Python has? Gotchas > are not necessarily a bad thing, there may be good reasons for it, but > they're surprising. I have one more: Dictionaries should iterate over their items instead of their keys. Looking forward to contrary opinions. Greets, Markus -- https://mail.python.org/mailman/listinfo/python-list
Re: Language design
On 11.09.2013 23:15, Ethan Furman wrote: > On 09/11/2013 01:41 PM, Markus Rother wrote: >> >>> () == [] >> False >> >> But: >> >> >>> bool(().__eq__([])) >> True > > This is not a trap, this is simply the wrong way to do it. The magic > methods (aka dunder methods) are there for Python to call, not you > (except under special circumstances, such as when writing your own > dunder methods). While trying to do it, I learned that its not the right way to do it. However, I was not satisfied with the fact, that there is no built in pure function for operations on primitives. Such that >>> def get_do_stuff (fn): ... def do_stuff(x,y): ... return fn(x,y) ... return do_stuff I understand that python is not a functional language, but it frustrates me at times. Markus -- https://mail.python.org/mailman/listinfo/python-list
Re: Language design
On 12.09.2013 01:27, Chris Angelico wrote:
> On Thu, Sep 12, 2013 at 6:41 AM, Markus Rother wrote:
>> 3. The default return value of methods is None instead of self.
>> If it was self, it would be possible to chain method calls (which
>> is called a cascade in smalltalk).
>>
>>
>> >>> lst = []
>> >>> lst.append(1).append(2).append(3) ## FAIL
>> Traceback (most recent call last):
>> ...
>> AttributeError: 'NoneType' object has no attribute 'append'
>
> That's a policy decision: a method (or function) will *EITHER* return
> a value, *OR* mutate its primary argument (in the case of a method,
> that's self).
You are stating: "All getters must be free of side effects".
That is not the case. Furthermore, the demand for getters with hidden
side effects is the reasoning behind properties.
The policy could as well be: a method (not a function) will either
return a value, or return self, whether or not the object was mutated.
> Why should that be split into two statements? Or alternatively, why
> should an extra copy of the list be created (if you use Python's
> sorted() here)? But for the new programmer, this is a convenient
> safety-net, and if list.sort() worked the other way, it'd be just as
> much a gotcha ("I ask for a sorted list, and it also changed the
> original?!??").
I understand the point you are making in the end, in the interest of
having an easy to start with language.
Markus
--
https://mail.python.org/mailman/listinfo/python-list
