Re: Documentation, assignment in expression.
Tim Chase wrote: > On 03/25/12 08:11, Chris Angelico wrote: >> On Mon, Mar 26, 2012 at 12:03 AM, Tim Chase >> wrote: >>> Granted, this can be turned into an iterator with a yield, making the >>> issue somewhat moot: >> >> No, just moving the issue to the iterator. Your iterator has exactly >> the same structure in it. > > Yeah, it has the same structure internally, but I'm somewhat > surprised that the DB connection object doesn't have an > __iter__() that does something like this automatically under the > covers. Most of my database programs wind up having the boilerplate (not tested): def rowsof (cursor): names = [x[0] for x in cursor.description] r = cursor.fetchone() while r: yield dict (zip (names, r)) r = cursor.fetchone() Mel. > >> Personally, I quite like assignment-in-conditional notation. Yes, it's >> a pretty common cause of problems; but what happened to the >> "consenting adults" policy? Python permits operator overloading and >> even the reassignment of builtins, both of which can cause similar >> confusion. > > In my past years of C programming, I've accidentally omitted the > second "=" in a comparison test numerous times, requiring me to > track down the missing character. When I finally catch it, it's > obvious what the problem is, but I've come to love having Python > yell at me contextually. > >> But, that's the choice Python's made. And being able to use the same >> symbol for assignment and comparison does have its advantages. > > The old curmudgeon in me likes the Pascal method of using "=" for > equality-testing, and ":=" for assignment which feels a little > closer to mathematical use of "=". > > -tkc -- http://mail.python.org/mailman/listinfo/python-list
Re: Documentation, assignment in expression.
Dennis Lee Bieber wrote: > On Sun, 25 Mar 2012 19:09:12 -0400, [email protected] declaimed the > following in gmane.comp.python.general: > > >> Most of my database programs wind up having the boilerplate (not tested): >> >> def rowsof (cursor): >> names = [x[0] for x in cursor.description] >> r = cursor.fetchone() >> while r: >> yield dict (zip (names, r)) >> r = cursor.fetchone() >> > > In my (limited) experience, the main loop above could be replaced > with: > > for r in cursor: > yield dict(zip(names, r)) I think your experience is more recent than mine. I'll change my boilerplate next time around. Mel. -- http://mail.python.org/mailman/listinfo/python-list
Re: string interpolation for python
Yingjie Lan wrote: > Seems you miss understood my notion of dynamic string. > Dynamic strings are expressions in disguise: the things > in between $...$ are plain old expressions (with optional > formatting specifications). They are evaluated > as if they were outside the dynamic string. In that case you should re-think the delimiters, so that you have something that can be nested. An example (example only, I'm not in love with it as a final form): "A string that gets %(count*spacer%) in the middle" "A string that gets %(count*%(spacer%)%) in the middle" Mel. -- http://mail.python.org/mailman/listinfo/python-list
Re: string interpolation for python
[email protected] wrote: > Yingjie Lan wrote: >> Seems you miss understood my notion of dynamic string. >> Dynamic strings are expressions in disguise: the things >> in between $...$ are plain old expressions (with optional >> formatting specifications). They are evaluated >> as if they were outside the dynamic string. > In that case you should re-think the delimiters, so that you have > something > that can be nested. An example (example only, I'm not in love with it as > a final form): > > "A string that gets %(count*spacer%) in the middle" > > "A string that gets %(count*%(spacer%)%) in the middle" A less than great example, I guess. Maybe > "A string that gets %(count*"-%(spacer%)-"%) in the middle" Mel. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Gotcha's?
rusi wrote: > Are there languages (other than python) in which single and double > quotes are equivalent? Kernighan and Plauger's RATFOR (a pre-processor that added some C-like syntax to FORTRAN) did that. Published in their book _Software Tools_. Mel. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Gotcha's?
Roy Smith wrote: > In article , [email protected] wrote: > >> rusi wrote: >> >> > Are there languages (other than python) in which single and double >> > quotes are equivalent? >> >> Kernighan and Plauger's RATFOR (a pre-processor that added some C-like >> syntax to FORTRAN) did that. Published in their book _Software Tools_. > > I used to write a lot of code in RATFOR. It was really a pretty good > tool. ISTR that RATFOR also concatenated adjacent quoted strings to build up long strings. That sort of puts the capstone on the two-quote-characters scheme. I can't lay my hands on the book to prove it. GE/Honeywell FORTRAN stole the single quote to delimit seek addresses in I/O statements, so my RATFOR implementations had to lose the two-quote feature and use a two-for-one scheme, like backslash-escaping and % inclusion in moduloed strings do in Python. Mel. -- http://mail.python.org/mailman/listinfo/python-list
Re: ordering with duck typing in 3.1
Thomas Rachel wrote: > Am 07.04.2012 14:23 schrieb andrew cooke: > >> class IntVar(object): >> >> def __init__(self, value=None): >> if value is not None: value = int(value) >> self.value = value >> >> def setter(self): >> def wrapper(stream_in, thunk): >> self.value = thunk() >> return self.value >> return wrapper >> >> def __int__(self): >> return self.value >> >> def __lt__(self, other): >> return self.value< other >> >> def __eq__(self, other): >> return self.value == other >> >> def __hash__(self): >> return hash(self.value) > >> so what am i missing? > > If I don't confuse things, I think you are missing a __gt__() in your > IntVar() class. > > This is because first, a '2 < three' is tried with 2.__lt__(three). As > this fails due to the used types, it is reversed: 'three > 2' is > equivalent. As your three doesn't have a __gt__(), three.__gt__(2) fails > as well. Practically, yes. Just that that's not what the documentation says. Looks like Python no longer tries to cobble together missing relations based on the "usual" properties of ordering. Mel. -- http://mail.python.org/mailman/listinfo/python-list
Re: Donald E. Knuth in Python, cont'd
Antti J Ylikoski wrote: > > I wrote about a straightforward way to program D. E. Knuth in Python, > and received an excellent communcation about programming Deterministic > Finite Automata (Finite State Machines) in Python. [ ... ] > #You can adjust that for your needs. Sometimes I have the states return > #a (next_state, output) tuple. You could use a distinguished done() > #state, or just use None for that. I wrote the example above as global > #functions, but more commonly these would be methods of some StateMachine > #class. > # > # > # > # The program calculates correctly after D. E. Knuth but it has the > # actual > # yearly calendar Easter dates wrong. See Knuth's text. > # [ ... ] > def Easter(Year): > global G, Y, C, X, Z, D, N, E > Y = Year > nextState = E1 > continueLoop = 1 > while continueLoop: > nextState = nextState() > if nextState is None: > break def Easter (year): global Y Y = year nextState = E1 while nextState is not None: nextState = nextState() would be a little cleaner. As you say, to be really clean, make a class. Mel. -- http://mail.python.org/mailman/listinfo/python-list
Re: why () is () and [] is [] work in other way?
Adam Skutt wrote: [ ... ] > In the real world, if we were doing the math with pen and paper, we'd > stop as soon as we hit such an error. Equality is simply not defined > for the operations that can produce NaN, because we don't know to > perform those computations. So no, it doesn't conceptually follow > that NaN = NaN, what conceptually follows is the operation is > undefined because NaN causes a halt. > > This is what programming languages ought to do if NaN is compared to > anything other than a (floating-point) number: disallow the operation > in the first place or toss an exception. Any code that tries such an > operation has a logic error and must be fixed. There was a time when subtracting 5 from 3 would have been a logic error. Your phrase "if we were doing the math ..." lies behind most of the history of math, esp. as it concerns arithmetic. Mathematicians kept extending the definitions so that they wouldn't have to stop. Feynman's _Lectures on Physics_, chapter 22, "Algebra" gives a stellar account of the whole process. Mel. -- http://mail.python.org/mailman/listinfo/python-list
Re: confusing doc: mutable and hashable
[email protected] wrote: > I'm just learning Python. The python doc about mutable and hashable is > confusing to me. > > In my understanding, there is no directly relation between mutable and > hashable in Python. Any class with __hash__ function is "hashable". > > According the wiki: http://en.wikipedia.org/wiki/Immutable_object > > In object-oriented and functional programming, an immutable object is an > object whose state cannot be modified after it is created.[1] This is in > contrast to a mutable object, which can be modified after it is created. > > We surely can define __hash__ function in user-define class and the > instance of that class can be changed thus mutable. > > But following statement seems correct in practice but not technically. Any > comments on this? Wikipedia has it right. Mutable objects are objects where significant attributes of the object can change value over the lifetime of the object. This is useful for data sharing. If, for example, one part of your program knows an object by the name `a`, and another part knows the same object as `b` (or if they can access the object in any other distinct ways), they can communicate by changing values of attributes of the shared object. In practice, hashable means that the hashable object can be used as a key in a dict. Looking up an item in a dict means that 1) the hash of the lookup key has to match the hash of the stored key, and 2) the lookup key has to be equal to the stored key according to the `==` operator. These requirements are easy to meet if the keys are immutable. Otherwise for classes you create, you can (if you're careful) create __hash__ and __eq__ methods to meet the requirements, even if significant attributes of your instances can change their values. Mel. -- http://mail.python.org/mailman/listinfo/python-list
Re: syntax for code blocks
Ben Finney wrote: > [ ... ] Even worse is the > penchant for ‘foo .bar()’, the space obscures the fact that this is > attribute access. I like the style sometimes when it helps to break the significantly different parts out of boilerplate: libbnem. BN_add .argtypes = [ctypes.POINTER (BignumType), ctypes.POINTER (BignumType), ctypes.POINTER (BignumType)] libbnem. BN_add .restype = ctypes.c_int libbnem. BN_add_word .argtypes = [ctypes.POINTER (BignumType), ctypes.c_ulong] libbnem. BN_add_word .restype = ctypes.c_int libbnem. BN_sub .argtypes = [ctypes.POINTER (BignumType), ctypes.POINTER (BignumType), ctypes.POINTER (BignumType)] libbnem. BN_sub .restype = ctypes.c_int libbnem. BN_sub_word .argtypes = [ctypes.POINTER (BignumType), ctypes.c_ulong] libbnem. BN_sub_word .restype = ctypes.c_int (there were a lot more in the original program where those came from.) Another take-away might be don't use boilerplate, but in the situation I didn't see a simple way to avoid it. Mel. -- http://mail.python.org/mailman/listinfo/python-list
ctypes details was: Re: syntax for code blocks
> On 4/30/2012 17:02, Kiuhnm wrote: >> BignumTypePtr = ctypes.POINTER(BignumType) >> >> for op, op_word in ((libbnem.BN_add, libbnem.BN_add_word), >> (libbnem.BN_sub, libbnem.BN_sub_word)): >> op.argtypes = [BignumTypePtr] * 3 >> op_word.argtypes = [BignumTypePtr, ctypes.c_ulong] >> op.restype = op_word.restype = ctypes.c_int > > On second thought, BignumPtrType is probably the right name. (Way off the original topic, aren't we?) I haven't looked inside ctypes, and don't know what kind of thing ctypes.POINTER actually constructs. I was worried about falling into a [[a]]*3 kind of error -- unwittingly sharing a mutable object. I guess I really should look. Mel. -- http://mail.python.org/mailman/listinfo/python-list
Re: ctypes details was: Re: syntax for code blocks
Kiuhnm wrote:
> Regarding ctypes, try this to convince yourself that there's no problem
> in reusing BignumPtrType:
> from ctypes import POINTER, c_int
> assert POINTER(c_int) is POINTER(c_int)
print ('POINTERs are shareable:', ctypes.POINTER (BignumType) is ctypes.POINTER
(BignumType))
[ ... ]
('POINTERs are shareable:', True)
Thanks.
Mel.
--
http://mail.python.org/mailman/listinfo/python-list
