Re: the meaning of rユ.......ï¾

2012-07-23 Thread Henrik Faber
On 23.07.2012 16:43, Mark Lawrence wrote: >> Apparently, not all characters are fine with Python. Why can I not have >> domino tiles are identifier characters? >> > 🀻 = 9 >>File "", line 1 >> 🀻 = 9 >> ^ >> SyntaxError: invalid character in identifier >> >> I think there ne

Re: the meaning of rユ.......ï¾

2012-07-23 Thread Henrik Faber
On 23.07.2012 16:10, Devin Jeanpierre wrote: > On Mon, Jul 23, 2012 at 9:52 AM, Henrik Faber wrote: >> If you allow for UTF-8 identifiers you'll have to be horribly careful >> what to include and what to exclude. Is the non-breaking space a valid >> character for a iden

Re: the meaning of rユ.......ï¾

2012-07-23 Thread Henrik Faber
On 23.07.2012 16:19, Chris Angelico wrote: > On Mon, Jul 23, 2012 at 11:52 PM, Henrik Faber wrote: >> What about × vs x? Or Ì vs Í vs Î vs Ï vs Ĩ vs Ī vs ī vs Ĭ vs ĭ vs Į vs >> į vs I vs İ? Do you think if you need to maintain such code you'll >> immediately know the

Re: the meaning of rユ.......ï¾

2012-07-23 Thread Henrik Faber
On 23.07.2012 15:55, Henrik Faber wrote: > Dear Lord. > > Python 3.2 (r32:88445, Dec 8 2011, 15:26:58) > [GCC 4.5.2] on linux2 > Type "help", "copyright", "credits" or "license" for more information. >>>> fööbär = 3 >>

Re: the meaning of rユ.......ï¾

2012-07-23 Thread Henrik Faber
On 23.07.2012 15:52, Henrik Faber wrote: > but I would hate for > Python to include them into identifiers. Then again, I'm pretty sure > this is not planned anytime soon. Dear Lord. Python 3.2 (r32:88445, Dec 8 2011, 15:26:58) [GCC 4.5.2] on linux2 Type "help", &

Re: the meaning of rユ.......ï¾

2012-07-23 Thread Henrik Faber
On 23.07.2012 15:35, Chris Angelico wrote: > That said, though, there's good argument in allowing full Unicode in > *identifiers*. If I'm allowed to name something "foo", then a German > should be allowed to name something "foö". And since identifiers are > case sensitive (at least, they are in a

Re: the meaning of rユ.......ï¾

2012-07-23 Thread Henrik Faber
On 23.07.2012 14:55, Roy Smith wrote: > Some day, we're going to have programming languages that take advantage > of the full unicode character set. Plus, if I may add this: It's *your* newsreader that broke the correctly declared ISO-8859-7 encoded subject of the OP. What a bitter irony that de

Re: the meaning of rユ.......ï¾

2012-07-23 Thread Henrik Faber
On 23.07.2012 14:55, Roy Smith wrote: > In article <500d0632$0$1504$c3e8da3$76491...@news.astraweb.com>, > Steven D'Aprano wrote: > >> Technically, no, it's a SyntaxError, because the Original Poster has used >> some sort of "Smart Quotes" characters r’‘ instead of good old fashion

Re: dict: keys() and values() order guaranteed to be same?

2012-07-23 Thread Henrik Faber
On 23.07.2012 13:40, Philipp Hagemeister wrote: > On 07/23/2012 01:23 PM, Henrik Faber wrote: >> With an arbitrary dictionaty d, are d.keys() and d.values() >> guaraneed to be in the same order? > > Yes. From the documentation[1]: > > If items(), keys(), values(), i

dict: keys() and values() order guaranteed to be same?

2012-07-23 Thread Henrik Faber
Hi group, I have a question of which I'm unsure if the specification guarantees it. With an arbitrary dictionaty d, are d.keys() and d.values() guaraneed to be in the same order? I.e. what I mean is: # For all dictionaries d: assert({ list(d.keys())[i]: list(d.values())[i] for i in range(len(d))

Re: Python vs. C++11

2012-02-15 Thread Henrik Faber
On 15.02.2012 08:18, Tim Roberts wrote: > sturlamolden wrote: >> >> There are bigsimilarities between Python and the new C++ standard. Now >> we can actually use our experience as Python programmers to write >> fantastic C++ :-) > > This is more true than you might think. For quite a few years n

Signature-preserving decorators

2011-12-13 Thread Henrik Faber
Hi group, when decorating a method in Python3, by use of the functools.update_wrapper function, it can be achieved that the docstring and name of the original function is preseverved. However, the prototype is lost: When looking into the Python help, I have lots of entries that look like: getfoo

Re: Confusion about decorators

2011-12-12 Thread Henrik Faber
On 12.12.2011 15:01, Arnaud Delobelle wrote: >> I am very amazed -- I've been programming Python for about 5 years now >> and have never even come close to something as a "descriptor protocol". >> Python never ceases to amaze me. Do you have any beginners guide how >> this works? The Pydoc ("Data

Re: Confusion about decorators

2011-12-12 Thread Henrik Faber
On 12.12.2011 14:45, Arnaud Delobelle wrote: >> Can someone please enlighten me? > > You can (need to?) use the descriptor protocol to deal with methods. > > from functools import partial [...] >def __get__(self, obj, objtype): >return partial(self, obj) Whoa. This is abs

Re: Confusion about decorators

2011-12-12 Thread Henrik Faber
On 12.12.2011 14:37, Andrea Crotti wrote: > On 12/12/2011 01:27 PM, Henrik Faber wrote: >> Hi group, >> >> I'm a bit confused regarding decorators. Recently started playing with >> them with Python3 and wanted (as an excercise) to implement a simple >> type c

Confusion about decorators

2011-12-12 Thread Henrik Faber
Hi group, I'm a bit confused regarding decorators. Recently started playing with them with Python3 and wanted (as an excercise) to implement a simple type checker first: I know there are lots of them out there, this is actually one of the reasons I chose that particular function (to compare my sol

Re: Multiple threads

2011-11-16 Thread Henrik Faber
On 16.11.2011 14:48, Eduardo Oliva wrote: > I need my script to run 2 separated threads, and then when the first has > finished, starts the next onebut no more than 2 threads. > I know that Semaphores would help with that. > But the problem here is to know when the thread has finished i

Re: all() is slow?

2011-11-08 Thread Henrik Faber
On 07.11.2011 23:06, Chris Angelico wrote: > On Tue, Nov 8, 2011 at 8:46 AM, david vierra wrote: >> But, you didn't write an all() function. You wrote a more specialized >> allBoolean() function. I think this comparison is more fair to the >> builtin all(): > > So really, it's not "all() is slow

Re: Operator commutativity

2011-09-19 Thread Henrik Faber
On 19.09.2011 13:23, Paul Rudin wrote: > Henrik Faber writes: > >> How can I make this commutative? > > Incidentally - this isn't really about commutativity at all - the > question is how can you define both left and right versions of add, > irrespective of wheth

Operator commutativity

2011-09-19 Thread Henrik Faber
Hi there, when I have a python class X which overloads an operator, I can use that operator to do any operation for example with an integer y = X() + 123 however, say I want the "+" operator to be commutative. Then y = 123 + X() should have the same result. However, since it does not call __ad