[issue11594] 2to3 does not preserve line endings
Slawomir Nowaczyk added the comment: I've just tried 2to3 in 3.7.0, and it still breaks line endings for me... Seems like one also needs to fix line 517 in refactor.py fp = io.open(filename, "w", encoding=encoding, newline='') -- nosy: +Slawomir Nowaczyk ___ Python tracker <https://bugs.python.org/issue11594> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: execfile locks file forever if there are any syntax errors - is it python bug?
On Wed, 14 Mar 2007 07:59:57 -0500 [EMAIL PROTECTED] wrote: # # Slawomir When I execfile a file which contains a syntax error, the file # Slawomir becomes locked and stays this way all the way until I exit the # Slawomir interpreter (I am unable to delete it, for example). I have # Slawomir tried but failed to find any way to unlock the file... Is this # Slawomir a bug in Python? # # Kinda seems like it might be. Please file a bug report on SourceForge. I did, and it is a bug, but it seems to be already fixed in SVN. https://sourceforge.net/tracker/?func=detailatid=105470aid=1681020group_id=5470 -- Best wishes, Slawomir Nowaczyk ( [EMAIL PROTECTED] ) Does a clean house indicate that there is a broken computer in it? -- http://mail.python.org/mailman/listinfo/python-list
execfile locks file forever if there are any syntax errors - is it python bug?
Hello, When I execfile a file which contains a syntax error, the file becomes locked and stays this way all the way until I exit the interpreter (I am unable to delete it, for example). I have tried but failed to find any way to unlock the file... Is this a bug in Python? Is there *any* way to unlock the file? It is annoying for me because I often execfile various temporary files and it is a nuisance not to be able to delete them. I have tested with Python 2.5 on Windows... do other versions of Python behave this way as well? -- Best wishes, Slawomir Nowaczyk ( [EMAIL PROTECTED] ) I didn't fight my way to the top of the food chain to be a vegetarian. -- http://mail.python.org/mailman/listinfo/python-list
Re: automatically grading small programming assignments
On Thu, 14 Dec 2006 21:36:31 -0500 Brian Blais [EMAIL PROTECTED] wrote: # Paddy wrote: # It might turn out to be a poor substitute for the personal touch, # especially If they are just starting to program. # # Oh, I didn't mean it to completely replace me grading things, but I # think it would be useful if there were a lot of little assignments # that could be done automatically, and then some larger ones that I # would grade by hand. The little ones could be set up so that they can # submit as many times as they want, until they get it right. Well, that sounds like a valid plan, but why would you want to grade the little ones at all, then? What I would most likely do is to publish those small assignments together with a set of tests for each one, and say that they should write programs and make sure their programs pass the tests. If you wish, you could publish two sets of tests, the easy and tricky ones, and have them use easy ones when writing program, and only run it through the tricky tests when they believe the program is bug-free. This can be a very valuable experience! (if you can devise the right tests, of course ;) If you either require the skills they develop doing small assignments in the big assignments, or if you check 2-3 small assignments by hand, you should be able to reduce cheating sufficiently... It's just a matter of making sure they really *do* write programs and that those programs *do* pass the tests. Or just require students to hand in the small assignments, together with the testing output, but do not check them at all (not too many will have the guts to fake the outputs). Then there is a whole range of ideas about peer review in the education community, where you could get students to verify one another's programs... But this can sometimes be tricky. -- Best wishes, Slawomir Nowaczyk ( [EMAIL PROTECTED] ) Someone Else's Code - a commonly used synonym for Bad Code -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
On Sat, 16 Dec 2006 14:05:06 -0500 Kirk Sluder [EMAIL PROTECTED] wrote: # And there is something that is missing here in arguing about computer # language notations in relationship to human language readability, or # correspondence to spoken language. I'm not writing code for another # human, I'm writing code for a machine. Often, the optimum expression # of an mathematical concept for a machine is relatively baroque # compared to the optimum expression for a human being. Well, the memorable quote from Structure and Interpretation of Computer Programs states that Programs should be written for people to read, and only incidentally for machines to execute. -- Best wishes, Slawomir Nowaczyk ( [EMAIL PROTECTED] ) If at first you do succeed, try not to look astonished. -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
On Sat, 16 Dec 2006 14:09:11 +0100 André Thieme [EMAIL PROTECTED] wrote: # Sounds like Blub to me: # http://www.paulgraham.com/avg.html Well, too bad for you... # I will quote some parts of it: # snip # By induction, the only programmers in a position to see all the # differences in power between the various languages are those who # understand the most powerful one. This statement is, clearly, right.What I can not comprehend is how Lispers tend to mis-read comprehend above as think is the best. Some of us *do* comprehend Lisp, understand that there are uses for macros, just do not see the overwhelming need for them in everyday work (given sufficiently rich language core). I other words, people (in this sub-thread, at least) do not argue that Python is *as powerful* as Lisp -- we understand there are things macros can do easier/faster/more conveniently than functions or other features Python has. Lisp *is* more powerful than Lisp. You win. What we try to understand is why would you think Lisp is a better programming language than Python :) Sure, there are times I wish Python had macros. I would be able to save a couple of keystrokes here and there. But at other times, I am glad it does not have them, because when I read Bad Code (commonly used synonym for somebody else's code) I do not need to wonder what aif and 1000 others, similar things really do. In my experience, *if* somebody really needs aif, it can be done without macros. But without macros people will only introduce such thing if it does save significantly more than 3 or 4 lines of code in the whole project -- which is a good thing in my book. YMMV. I by far prefer to have it = timeConsumingCalculations() if it: use(it) five (or even ten) times in a medium sized project than to have to figure out what aif means. If the idiom is used 100 times, then something is wrong: either system should be redesigned or introducing aif is a good idea (but then Python idiom works just as good as Lisp one). YMMV. -- Best wishes, Slawomir Nowaczyk ( [EMAIL PROTECTED] ) There are 2 kinds of people in the world - those that divide the people into 2 groups, and those who don't. -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
On Fri, 15 Dec 2006 17:21:12 +0100 André Thieme [EMAIL PROTECTED] wrote: # And we might go further (again with an easy Graham example). # See this typical pattern: # # result = timeConsumingCalculation() # if result: #use(result) # # We need this ugly temporary variable result to refer to it. # If we could use the anaphor[1] it that could make situations like # these more clean. # # Imagine Python would have an anaphoric if, aif. Then: # # aif timeConsumingCalculation(): #use(it) I would spell the above like this: def timeConsumingCalculation(): pass def useit(it): pass def aif(first,second): res = first() if res: second(res) aif(timeConsumingCalculation,useit) Sure, it requires me to define function useit instead of embedding the code in aif call, but that has never been a problem for me: in reality, the code I would want to execute would be complex enough to warrant it's own function anyway. Of course, YMMV. -- Best wishes, Slawomir Nowaczyk ( [EMAIL PROTECTED] ) Real programmers can write assembly code in any language. -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
On Wed, 13 Dec 2006 02:41:29 -0500 Raffael Cavallaro [EMAIL PROTECTED]'espam-s'il-vous-plait-mac.com wrote: # On 2006-12-12 19:18:10 -0500, George Sakkis [EMAIL PROTECTED] said: # # If you mistakenly select an extra parenthesis or omit one, it's # the same thing. # # Because you can't mistakenly select an extra paren or omit one in a # lisp-aware editor. Sure I can! I think you misunderstood what George said. (unless (eq 1 2) (if (eql 2 3) (x)) (y)) How is the editor supposed to know whether I want to cut/paste the s-expression starting with if or the one with eql? # Whether its a commercial lisp IDE or emacs, you don't manually select # s-expressions. You put your cursor/point at one paren and you tell # the editor - with a keystroke or a mouse click - to find the matching # paren and select everything contained between the two. Oh, you mean you have never seen a Python environment which could mark the current block of code? -- Best wishes, Slawomir Nowaczyk ( [EMAIL PROTECTED] ) Truth is stranger than fiction, because fiction has to make sense. -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
On Sun, 10 Dec 2006 10:11:37 -0500 Ken Tilton [EMAIL PROTECTED] wrote: # Lisp has all the cool qualities you like in your pets, plus native # compilation in most implementations, plus maturity and a standard, plus # a better OO, plus macros, plus a dozen more small wins. Including # automatic indentation. :) Automatic indentation? Wow, that's cool... we in Python need to press RET and sometimes even use this ugly : or TAB key to get proper indentation. Oh, wait, you mean you need to type ( and ) in Lisp? What's automatic about *that*??? -- Best wishes, Slawomir Nowaczyk ( [EMAIL PROTECTED] ) Grossman's Law: Complex problems have simple, easy-to-understand, wrong answers. -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
On Sun, 10 Dec 2006 17:11:20 +0200 Dmitry V. Gorbatovsky [EMAIL PROTECTED] wrote: # Steven D'Aprano wrote: # # So which is it? If Lisp is so self-evidently better than every other # language, and if nobody has any fears or concerns with Lisp, why is Lisp a # fringe language? # Because shifting to lisp somewhere in the middle of # your project or carear is VERY EXPENSIVE STEP. Doesn't that say something about Lisp? Switching to most other useful languages is a nice experience. Luckily, that claim is obviously false. -- Best wishes, Slawomir Nowaczyk ( [EMAIL PROTECTED] ) Integrated Software: A single product that deftly performs hundreds of functions that the user never needs and awkwardly performs the half-dozen he uses constantly. -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
On Tue, 12 Dec 2006 20:38:14 -0800
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
# Because it's the language for which indentation is automatically
# determinable. That is, one can copy/paste a chunk of code, hit a
# key and suddenly everything is nicely indented.
#
# Cool, so in other languages I need to set block marks like () and
# {} and also indent the code for readability, and in Python I indent
# only. From my POV that's less work.
#
# Try reading again. In Lisp, you use () and *your editor*
# automatically indents according to the universal standard,
How does that differ from In Python, you use TAB and your editor
automatically indents according to the universal standard?
# or you leave it sloppy until other folks reading your code convince
# you to get a proper programming editor.
Well, in Python you never need to leave it sloppy.
# Indentation does not get out of sync with semantics because the
# editor virtually never misses parentheses that the Lisp compiler
# sees.
What makes you think Python indentation ever gets out of sync with
semantics?
# In Python, you group in your mind, and press indentation keys to make
# it happen in your editor.
In Lisp, you group in your mind, and press parentheses keys to make it
happen in your editor.
# The editor cannot help that much, because it cannot read your mind.
The editor cannot help that much, because it cannot read your mind.
--
Best wishes,
Slawomir Nowaczyk
( [EMAIL PROTECTED] )
You can't wake a person who is pretending to be asleep.
--
http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
On Sat, 09 Dec 2006 21:59:58 -0500 Ken Tilton [EMAIL PROTECTED] wrote: # Could it be because of people like J Shrager who writes things like this? # # Can't you just expand the language via macros to create whatever facility # of this sort [major new features with new syntax] you need... # # The context was CLOS. Something that big needs new syntax. Really? What if we *do not want* anything that big in Python? # (This thread, dated 8 Dec 2006 23:38:02 -0800) # # To someone outside of Lisp, that looks like I can make Lisp look like any # language I like in just a few lines. # # On the contrary, And you are the right person to say how things look like for *someone outside Lisp* exactly why? # Your hands must be getting sore from banging that drum so hard and so # long -- has it ever occurred to you that good programmers concerned # with power do not obfuscate code? Has it ever occurred to you that some of us need to read code written by not-so-good programmers? # We love the chance to preach to the unsaved, so we are indebted to # you for the many chances to clarify, but something tells me I should # check the c.l.p archives to make sure I am not chatting away happily # with the village idiot. :) Would you do me a favour and check the same thing on c.l.l while you are at it? # And that implies that to read a Lisp program, one might need to be # able to read code that looks like Lisp, or Smalltalk, or Prolog, or # Fortran, or all of those, or whatever bizarre syntax the developer # wanted it to look like. # # I don't want to think, I just want to bang on de drum all day. I # don't want to learn, just want to bang on de drum all day. Too bad for you. Steven has a valid point here, BTW. # Sure. But in the real world of programming, most developers aren't # good developers, they are merely average # # Two questions: do you really voluntarily use libraries from crappy # developers? Voluntarily as in in my work place? I mean, I *am* voluntarily staying employed, if you wish look at it this way... # Second, you think a language can stop people from writing bad code? No. But writing bad code can be made more or less difficult. -- Best wishes, Slawomir Nowaczyk ( [EMAIL PROTECTED] ) Consequences, shmonsequences! So long as I'm rich! -- Daffy Duck -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
On Sat, 09 Dec 2006 10:08:01 + Jon Harrop [EMAIL PROTECTED] wrote: # Steven D'Aprano wrote: # Anything any language can do is possible in any other language # # Not true. Concurrency, for example. As in, say, not being able to implement concurrency in assembler? -- Best wishes, Slawomir Nowaczyk ( [EMAIL PROTECTED] ) Be strict when sending and tolerant when receiving. RFC 1958 - Architectural Principles of the Internet - section 3.9 -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
On Tue, 12 Dec 2006 00:21:48 -0800 I V [EMAIL PROTECTED] wrote: # On Mon, 11 Dec 2006 23:24:07 -0500, Ken Tilton wrote: # Also, Python does not support a functional style of programming so # the line is the only meaningful textual entity. In this sense the # primitiveness of Python makes editing easier. # # Why do you say that? Wouldn't a block in python be a meaningful # textual entity in the same way a lisp form would be? No, it wouldn't, because that would make the argument false ;) -- Best wishes, Slawomir Nowaczyk ( [EMAIL PROTECTED] ) Monday is an awful way to spend 1/7th of your life. -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
On Tue, 12 Dec 2006 03:33:32 -0800 Paul Rubin http://phr.cx@NOSPAM.invalid wrote: # I V [EMAIL PROTECTED] writes: # Also, Python does not support a functional style of programming so the # line is the only meaningful textual entity. In this sense the # primitiveness of Python makes editing easier. # # Why do you say that? Wouldn't a block in python be a meaningful textual # entity in the same way a lisp form would be? # # You normally wouldn't refactor Python code by moving an indented block # to the inside of an expression. That is done all the time in Lisp. You mean, you actually take something like else-form from an if and put it inside, say, a multiplication? Sure, that is something you don't do in Python often. What you do in Python is take a block from one branch of if statement and put it somewhere else (in a for loop, for example). Sure, this requires you indent the block properly, although I am 100% sure that I could teach emacs to adjust indentation automatically has I needed to. I just never felt the need. -- Best wishes, Slawomir Nowaczyk ( [EMAIL PROTECTED] ) Programming: The art of debugging a blank sheet of paper (or, in these days of on-line editing, the art of debugging an empty file). -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
On Sat, 09 Dec 2006 14:57:08 -0500
Bill Atkins [EMAIL PROTECTED] wrote:
# In Python, I would need to do something like:
#
# control_code = connection.read_next_control_code()
# if control_code == +break+:
# connection.kill()
# throw blah
# else if control_code == +status+:
# connection.send_status_summary()
# else if control_code == +noop+ || control_code == +keep_alive+:
# else:
# error CONTROL_CODE fell through conditional cascade; was not one of
+BREAK+, +STATUS+, +NOOP+, +KEEP_ALIVE+
Hardly.
I mean, well, possibly, *you* might need to, but others might just do
things like this:
def main():
connection = +break+
def kill():
print kill,connection
raise broken-by-client
def status():
print status
def do_nothing():
pass
dispatch =
{+break+:kill,+status+:status,+noop+:do_nothing,+keep-alive+:do_nothing}
dispatch[connection]()
When you compare the above with your lisp version
# (let ((control-code (read-next-control-code connection)))
# (ecase control-code
# (+break+
# (kill-connection connection)
# (throw :broken-by-client))
# (+status+
# (send-status-summary connection))
# ((+noop+ +keep-alive+
# ;; +X+ indicates a constant
you may be able to see that they are pretty similar. Sure, Python does
not have fully functional lambda (which I, personally, consider to be a
drawback, but I understand that it is -- objectively -- a valid design
decision) so one needs to define functions for handling each case, but
there are some benefits to this approach as well.
# To change what control codes you want to check for, you need to add
# conditionals
Just as you need to add ecase branches...
# for them and keep the error text relevant. The reality is that a
# computer could be doing this for you, leaving your code simpler and
# more easily changed.
Not really. If you care about the error message, you can use a subclass
of a dictionary instead and provide the correct behaviour when key is
not found.
# Now someone will complain that the ECASE code means nothing until I
# understand ECASE. Yep. But once you understand ECASE, you can look
# at that code and, *at a glance*, see how control flows through it. In
# the equivalent Python code, I need to walk through each conditional
# and make sure they're all following the same pattern. If you're not
# convinced, extend the example to 12 different control codes.
What you say is right, but only for bad Python code. Want to bet I can
write bad Lisp which will be just as unmaintainable?
PS. Good sigmonster, have a cookie!
--
Best wishes,
Slawomir Nowaczyk
( [EMAIL PROTECTED] )
Get the facts first - you can distort them later!
--
http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
On Tue, 12 Dec 2006 10:30:40 -0700 Robert Uhl [EMAIL PROTECTED] wrote: # Imagine if one could write this in Python: # # defsyntax unless(condition, commands): # if not condition: # commands # # And use it like this: # # unless day == 'Sunday': # work() # # That'd be pretty cool, right? Left... What is cool in this? Sure, I love unless in Lisp, where it save me a whole one pair of parentheses, but in Python both of those are equally readable if not day == 'Sunday' unless day == 'Sunday' and the first one is standard, while the second is not. # As mentioned above, macros can make one's life significantly nicer. Sure. I sometimes (when writing code) wish we had macros in Python. I do know they can be useful. But then, when reading code, I am actually glad we do not have them. Their benefits in a language like Python would hardly pay off. # Wouldn't it be nice to have a macro with-open-file? # # filefor line in path: # foo(line) # bar(line) # baz(line) Not really. *If* this code bothers you, just do def with-open-file(path,fun): file = open(path,r) for line in file: fun(line) file.close() def handle-line(line): foo(line) bar(line) baz(line) with-open-file(path,handle-line) Sure, it takes some time to get used to this, and at the beginning you really miss full-blown lambda, but it does have its own benefits. # o Speed # # Lisp interpreters are several orders of magnitude faster than Python, # and Lisp compilers are faster yet. Speed's not the most important # thing, but it is _an_ important thing; all other things being equal, # the faster solution is better. Sure. But in 20-30 years, Python might get there. # o Symbols # # In Lisp, a symbol is essentially a hashed string; two symbols are alike # if their names are alike, but comparison of symbols is a constant-time # operation. Thus where in Python I have lots of string comparisons for # constants, and in C I have #defined integers, in Lisp I have symbols. # It's not just a performance hack--symbols are part of why macros and # packages work--but when I miss them, I miss them for the performance # side of things Well, you could fake symbols for most of the typical uses pretty easily... It won't look as good as it does in Lisp, but it will solve most problems. OTOH, if dictionary of strings is too slow, than maybe you are not using the right tool. # o CLOS # # The Common Lisp Object System is a really remarkable piece of work. # Among other things, it has generic functions instead of methods. E.g. # in Python or most other OO languages object.method(arg1, arg2) is # really just a fancy piece of syntactic sugar for method(object, arg1, # arg2); method does different things depending on the type of object, # its first argument. # # Wouldn't it be nice to be able to specialise a method on _any_ subset # of its arguments, not just its first one? Well, CLOS offers that. # (method object1 object2) could be specialised on the first argument, # the second or both. This can be very powerful. There are modules for Python offering exactly that. However, the Pythonic solution is not to rely on types too much anyway, in the first place. # Wouldn't it be nice to specify that some action be taken before or # after a superclass's method, rather than over-riding that method # entirely? Sure, one can over-ride the method and then call it within # one's own code, but that obscures the meaning of what one's doing. You can easily create a decorator which will do just that. I suppose you could also create a metaclass which would do that, but it's too late for me to be sure ;) -- Best wishes, Slawomir Nowaczyk ( [EMAIL PROTECTED] ) The nice thing about standards is that there are so many of them to choose from. -- http://mail.python.org/mailman/listinfo/python-list
Re: question about True values
On Fri, 27 Oct 2006 11:25:09 -0700 Carl Banks [EMAIL PROTECTED] wrote: # P.S. binary trees do have length: it's the number of nodes, just as # the number of keys is the length of a dict. I can't think of any # objects that use indexing but don't have a length, Well, infinite lists (either circular or dynamically-growing) would be one (unless you consider infinity to be a valid value of length, of course). Dictionaries with default value would be another (of course, Python 2.5 defaultdict *does* have length, but I would claim it is a wart). But I agree those are pathological cases. -- Best wishes, Slawomir Nowaczyk ( [EMAIL PROTECTED] ) Programmer - A red-eyed, mumbling mammal capable of conversing with inanimate objects. -- http://mail.python.org/mailman/listinfo/python-list
Re: IDE that uses an external editor?
On Fri, 13 Oct 2006 12:04:56 -0500 [EMAIL PROTECTED] wrote: # One thing that's kept me from even looking at IDEs is that to the # best of my knowledge none of them will integrate properly with # external editors like Emacs or vi. To the best of *my* knowledge, Emacs integrates pretty well with Emacs, and I suppose vi integrates pretty well with vi... Or do you mean something else by IDE? PS. Good sigmonster, have a cookie ;) -- Best wishes, Slawomir Nowaczyk ( [EMAIL PROTECTED] ) Vi is to emacs as masturbation is to making love: effective and always available but probably not your first choice. -- http://mail.python.org/mailman/listinfo/python-list
Re: IDE that uses an external editor?
On Sat, 14 Oct 2006 13:01:17 -0500 [EMAIL PROTECTED] wrote: # # Slawomir # One thing that's kept me from even looking at IDEs is that # Slawomir # to the best of my knowledge none of them will integrate # Slawomir # properly with external editors like Emacs or vi. # # Slawomir To the best of *my* knowledge, Emacs integrates pretty well # Slawomir with Emacs, and I suppose vi integrates pretty well with # Slawomir vi... Or do you mean something else by IDE? # # By IDE I mean Integrated Development Environment. Well, I haven't yet seen a definition of Integrated Development Environment which would exclude Emacs... # I realize I can do a lot within Emacs/XEmacs, but I suspect with a # tool like Eclipse I could do more. However, I don't want to give up # the text editing power of Emacs to get it. I don't know... I have never, personally, used Eclipse, so I cannot comment on that. It is highly dependent on what you are working on, I presume. -- Best wishes, Slawomir Nowaczyk ( [EMAIL PROTECTED] ) Sometimes I lie awake at night, and I ask, 'Where have I gone wrong?' Then a voice says to me, 'This is going to take more than one night. -- http://mail.python.org/mailman/listinfo/python-list
Re: hide python code !
On Wed, 16 Aug 2006 18:35:37 -0700 enigmadude [EMAIL PROTECTED] wrote: # Slawomir Nowaczyk wrote: # On Thu, 10 Aug 2006 17:35:27 -0700 # enigmadude [EMAIL PROTECTED] wrote: # # # 2. I've never done this, but you might be able to encrypt or otherwise # # turn you modules into binary form, and then use a clever import # # hook. # # Please observe that whatever the clever import hook is, it actually # needs to know the way to *decrypt* the module (secret key or # whatever). It means that if somebody decompiles the importing code, he # can just as well decompile the hidden one. Please do not top-post... # I'm pretty sure that just because someone is familiar with the PGP # sources, for example, doesn't mean that they have the necessary keys to # access other people's data across the internet. Also, I'm pretty sure I # know how a prison door lock works, but if I'm behind bars and don't # have the key, I'm still screwed. # # I believe the same things applies here. Just because you can see the # import code, depending upon what it does, if it requires (for example) # a key in order to decrypt the binary data before the modules can be # loaded, then no matter how much you understand the import code, the # data itself (that is the binary encrypted modules) is still useless to # you. Not really. The thing is, whatever data is actually required to perform the decryption, *must* be available in the importing code... as this code needs to -- by definition -- be able to decrypt the binaries into a form understandable by the CPU. After all, the code is supposed to actually work. As far as your analogy goes, you *do* have a key to the prison door, because you are *expected* to be able to let yourself out. -- Best wishes, Slawomir Nowaczyk ( [EMAIL PROTECTED] ) War doesn't determine who's right, war determines who's left. -- http://mail.python.org/mailman/listinfo/python-list
Re: easy string formating question
On Thu, 10 Aug 2006 17:28:59 -0700 Simon Forman [EMAIL PROTECTED] wrote: # There is a better way to check for exhausted StringIO (Note that # input is a python built-in and should not be used for a variable # name): Right, thanks for pointing it out. # import StringIO # s = '1234567890abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ' # size = 10 # 100 # S = StringIO.StringIO(s) # # data = S.read(size) # while data: # print data + ?\n, # data = S.read(size) It may be only my personal opinion, but duplicating data = S.read(size) line doesn't strike me as particularly better. # However, it's considered more pythonic to do it like so (also uses a # StringIO as an output file to show how print can print to a file-like # object): # # import StringIO # # s = '1234567890abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ' # size = 10 # 100 # # S = StringIO.StringIO(s) # out = StringIO.StringIO()# stand-in for a real file. # # while True: # data = S.read(size) # if not data: # break # print out, data + ?\n, # # print out.getvalue() This looks slightly nicer, but still, I wish there was some kind of StringIO.isEOF() to put in while condition. Don't take me wrong, I love while True stuff, but sometimes having an actual test there can be nice :) -- Best wishes, Slawomir Nowaczyk ( [EMAIL PROTECTED] ) Beware of bugs in the above code; I have only proved it correct, not tried it. -- http://mail.python.org/mailman/listinfo/python-list
Re: hide python code !
On Thu, 10 Aug 2006 17:35:27 -0700 enigmadude [EMAIL PROTECTED] wrote: # 2. I've never done this, but you might be able to encrypt or otherwise # turn you modules into binary form, and then use a clever import # hook. Please observe that whatever the clever import hook is, it actually needs to know the way to *decrypt* the module (secret key or whatever). It means that if somebody decompiles the importing code, he can just as well decompile the hidden one. -- Best wishes, Slawomir Nowaczyk ( [EMAIL PROTECTED] ) Children are natural mimics, who act like their parents despite every effort to teach them good manners. -- http://mail.python.org/mailman/listinfo/python-list
Re: converting a nested try/except statement into try/except/else
On Thu, 10 Aug 2006 16:42:47 -0700 Simon Forman [EMAIL PROTECTED] wrote: # 6.) There's a single return statement. # # I forget now where I picked this up, but it's served me well for # many years: Procedures, functions, methods, etc... should have one # exit point. Something about having fewer code paths to test or # something. Number of return statements has absolutely *nothing* to do with number of code paths to test. -- Best wishes, Slawomir Nowaczyk ( [EMAIL PROTECTED] ) Only drug dealers and software companies call their customers 'users.' -- http://mail.python.org/mailman/listinfo/python-list
Re: Nested function scope problem
On Wed, 09 Aug 2006 15:11:16 -0300 Gerhard Fiedler [EMAIL PROTECTED] wrote: # On 2006-08-09 07:54:21, Slawomir Nowaczyk wrote: # # Nope. Equivalence table can look like this: # # Python C # variable:a variable: a # textual representation: a address operator: a # id of object: id(a) dereference operator: *a # # Also, notice, that id(a) does not really identify a variable. It # only identifies *object* which is bound to this variable. Both in # Python and in C. # # Rests one question: what is the value of the variable? In Python, it would # be the result of a. In C, it would be the result of ...? Hmmm, well, it should be value of a, but it clearly doesn't make much sense. It seems like I got confused and was saying something else than I was thinking. So, indeed, you were right: this analogy is broken. But let me try again, please (just one more time, if this doesn't work either I am willing to admit I do not see a simple analogy between Python and C variables :-) Python C variable: avariable: a value of variable: eval(a)dereference operator: *a textual representation: a address operator: a id of object: id(a)value of variable: a Thus, equivalent operations would be: Python C a = 1003 a = three // (1) id(a)a b = 1004 b = four a == b # False *a == *b// false id(a) == id(b) # False a == b // false b = ab = a a == b # True *a == *b// true id(a) == id(b) # True a == b // true a = 1001+1002a = MallocNewIntFromValue( one+two ) a == b # True *a == *b// true id(a) == id(b) # False / True (2) a == b // false / true a = 1003+1004a = MallocNewIntFromValue( three+four ) a == b # False *a == *b// false id(a) == id(b) # False a == b // false (1) one, two, three and four are constants, something like const int one = 1. That is because there is no literal int object in C - the thing you would write as 1 is likely not to actually exist at runtime. And you cannot take an address of it. (2) is actually True in CPython implementation for small integers, but that's a minor detail. MallocNewIntFromValue might cache objects as well. -- Best wishes, Slawomir Nowaczyk ( [EMAIL PROTECTED] ) Housework can't kill you... but why take a chance? -- http://mail.python.org/mailman/listinfo/python-list
Re: do people really complain about significant whitespace?
On Wed, 09 Aug 2006 07:33:41 -0700 Rob Wolfe [EMAIL PROTECTED] wrote: # Slawomir Nowaczyk wrote: # # Really, typing brace after function/if/etc should add newlines and # indent code as required -- automatically. Actually, for me, it is even # *less* typing in C and similar languages... I probably should teach my # Emacs to automatically add newline after colon in Python, just as it # does after a brace in C... As soon as I figure out how to deal with # dictionary literals. Hmmm. # # Are you sure? My Emacs already know how to do it with the help # of python-mode and magic function py-newline-and-indent. # # emacs-version 21.3.1 # py-version $Revision: 4.63 $ OK, my python-mode.el was older, so I upgraded to 4.75, but it still doesn't work. Did you mean that after you write if x==1: the newline is inserted automatically when you type :? That's a functionality I would like to see, but it doesn't seem to work this way. Anyway, I am using python.el most of the time and it doesn't have that functionality yet. -- Best wishes, Slawomir Nowaczyk ( [EMAIL PROTECTED] ) Live in the past and future only. -- http://mail.python.org/mailman/listinfo/python-list
How to execute a file outside module's namespace?
Hello, Let's say I have a module emacs, defining function eexecfile(file): def eexecfile(file): # do other stuff execfile(file,globals()) # do other stuff Now, assume I have file test.py containing an assignment x=1 If I run python and do: import emacs emacs.eexecfile(test.py) print emacs.x # works, x was put in module namespace print x # doesn't work, x is not defined in main script namespace What is the best way to make print x work? Using the following: import __main__ def eexecfile(file): # do other stuff execfile(file, __main__.__dict__) # do other stuff seems to work, but it gives me a slightly uneasy feeling. Is this the right way? -- Best wishes, Slawomir Nowaczyk ( [EMAIL PROTECTED] ) Today advance is so rapid that even the astronauts who set foot on the moon in 1969 had never seen a digital watch -- http://mail.python.org/mailman/listinfo/python-list
Re: do people really complain about significant whitespace?
On Thu, 10 Aug 2006 04:01:51 -0700 Rob Wolfe [EMAIL PROTECTED] wrote: # if x==1: # # the newline is inserted automatically when you type :? That's a # # Exactly. Really? The newline? I know it *indents* automatically. But it definitely doesn't insert newline when I try it. I even downloaded revision 4.63 and I really do not see any code for doing that. py-electric-colon only seems to dedent code. # functionality I would like to see, but it doesn't seem to work # this way. # # Here is fragment of my python-mode.el: Please note that this comment doesn't say anything about automatically inserting newlines, only about indenting (actually, dedenting) as needed. Anyway, this is probably becoming off-topic here. -- Best wishes, Slawomir Nowaczyk ( [EMAIL PROTECTED] ) Cursor: What you become when your computer crashes. -- http://mail.python.org/mailman/listinfo/python-list
Re: converting a nested try/except statement into try/except/else
On Wed, 09 Aug 2006 18:51:04 + (GMT) John Salerno [EMAIL PROTECTED] wrote: # try: # int(text) # except ValueError: # self.error_message() # return False # else: # return True # # I think it's much cleaner, but obviously I lost the test in the # original if statement. # # So my question is, can I still retain this second structure and # still test for 0, but not have any extra nesting? How about try: if int(text) 0: return True except ValueError: pass self.error_message() return False -- Best wishes, Slawomir Nowaczyk ( [EMAIL PROTECTED] ) In 10 minutes, a hurricane releases more energy than all of the world's nuclear weapons combined. -- http://mail.python.org/mailman/listinfo/python-list
Re: knowing when file is flushed to disk
On Wed, 09 Aug 2006 16:13:19 + (GMT) John Pote [EMAIL PROTECTED] wrote: # Is there some way from my Python script to know when the data is actually on # the disk. BTW server OS is Linux. Presumably calling flush() and close() on # the output file will initiate the disk write, but do they wait for the # actual disk write or immediately return leaving the OS to do the write when # it sees fit? You may want to look into sqlite -- it is a single-file based SQL database which is known to be extremely robust in face of problems you describe. One of its design goals was to provide a replacement for file storage. There is python binding http://pysqlite.org which is, IIRC, supposed to be in stdlib for Python 2.5 That said, if your disk and/or OS is lying about the fact whether it has actually wrote the data or not, there is not much you can do. -- Best wishes, Slawomir Nowaczyk ( [EMAIL PROTECTED] ) If vegetarians love animals so much, why do they eat all their food??? -- http://mail.python.org/mailman/listinfo/python-list
Re: easy string formating question
On Thu, 10 Aug 2006 11:39:41 -0700 f pemberton [EMAIL PROTECTED] wrote: # I have kind of an interesting string, it looks like a couple hundred # letters bunched together with no spaces. Anyway, i'm trying to put a # ? and a (\n) newline after every 100th character of the string and # then write that string to a file. How would I go about doing that? Any # help would be much appreciated. In addition to all the other ideas, you can try using StringIO import StringIO s = '1234567890abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ' size = 10 # 100 input = StringIO.StringIO(s) while input.tell()input.len: # is there really no better way to check for exhausted StringIO ? print input.read(size)+?\n, # instead of print just write to a file or accumulate the result -- Best wishes, Slawomir Nowaczyk ( [EMAIL PROTECTED] ) Reality is that which, when you stop believing in it, doesn't go away. -- Philip K. Dick -- http://mail.python.org/mailman/listinfo/python-list
Re: How to execute a file outside module's namespace?
On Fri, 11 Aug 2006 01:23:14 +0800 Angelo Zhou [EMAIL PROTECTED] wrote: # Slawomir Nowaczyk wrote: # Hello, # # Let's say I have a module emacs, defining function eexecfile(file): # # def eexecfile(file): # # do other stuff # execfile(file,globals()) # # do other stuff # # Now, assume I have file test.py containing an assignment x=1 # # If I run python and do: # # import emacs # emacs.eexecfile(test.py) # print emacs.x # works, x was put in module namespace # print x # doesn't work, x is not defined in main script namespace # # What is the best way to make print x work? Using the following: # # import __main__ # def eexecfile(file): # # do other stuff # execfile(file, __main__.__dict__) # # do other stuff # # seems to work, but it gives me a slightly uneasy feeling. Is this the # right way? # # # from emacs import x will expose x to the current namespace True... but I do not know in advance what is the contents of test.py file -- it could be a=1 :) Sure, I could go over emacs.__dict__ and expose everything except eexecfile, but that's even less satisfying than the solution above. Anyway, thanks for the suggestion. -- Best wishes, Slawomir Nowaczyk ( [EMAIL PROTECTED] ) Zawinski's Law: Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can. -- http://mail.python.org/mailman/listinfo/python-list
Re: converting a nested try/except statement into try/except/else
On Thu, 10 Aug 2006 14:32:49 + (GMT) John Salerno [EMAIL PROTECTED] wrote: # Bruno Desthuilliers wrote: # # try: # if int(text) = 0: raise ValueError # # Hmm, I'm actually not so sure about this line now. It doesn't seem right # to raise a ValueError when the result of the expression is negative, # because even though it's a problem for my program, it isn't really a # ValueError, right? Well, you could always do something like try: int(-+text) Now, this *will* be a real ValueError for negative integers ;-) ;-) ;-) But no, I am not suggesting that... especially since -0 is valid. -- Best wishes, Slawomir Nowaczyk ( [EMAIL PROTECTED] ) COMMAND: A suggestion made to a computer. -- http://mail.python.org/mailman/listinfo/python-list
Re: do people really complain about significant whitespace?
On Mon, 07 Aug 2006 16:47:57 -0700 Jason [EMAIL PROTECTED] wrote: # It is annoying that certain communication channels do not respect # white-space. I dislike using braces because I have to indicate my # intentions twice: once for the compiler and once for humans. I must admit I do not get this indicate intentions twice argument, even though I heard it a number of times now... It's not that braces require more work or more typing or something, after all -- at least not if one is using a decent editor. Really, typing brace after function/if/etc should add newlines and indent code as required -- automatically. Actually, for me, it is even *less* typing in C and similar languages... I probably should teach my Emacs to automatically add newline after colon in Python, just as it does after a brace in C... As soon as I figure out how to deal with dictionary literals. Hmmm. -- Best wishes, Slawomir Nowaczyk ( [EMAIL PROTECTED] ) Be strict when sending and tolerant when receiving. RFC 1958 - Architectural Principles of the Internet - section 3.9 -- http://mail.python.org/mailman/listinfo/python-list
Re: Nested function scope problem
are not
equivalent to Python variables. The id() may correspond to some other
C concept -- I give you one example that works for me. You need to
show that there exists none.
# There is no textual representation of variables in C -- at least not at
# runtime. Why should there be? There is, after all, no equivalent to
# eval('a=1') so why would anybody care what was variable named?
#
# I wasn't aware that you were talking only about runtime.
#
# Yes, I am talking about C pointers, but I call *them*, not what they
# point at, variables.
#
# Not really. Try to make your analogy more explicit. Your analogy only works
# (kind of) if you treat (in C) *a as the equivalent of a Python variable,
# not a.
No. In fact, it *doesn't* work in that case.
I treat *a as Python _object_. I.e. this funny thing which can be
destroyed by a GC/reference counting when no longer needed.
It is definitely *not* a variable.
# # So the only variables in your example (a and b) don't really behave
# # according to your analogy.
#
# Sorry, I do not follow.
#
# You said that the address operator [of a C variable] in C is what textual
# representation is in Python. We agree that the pointer variable 'a' is a C
# variable.
Yes.
# So is 'a' in C the equivalent to 'id(a)' in Python?
No, *a is equivalent to id(a), a is equivalent to a.
# Your code seemed to indicate that you meant 'a' to be the
# equivalent to 'id(a)' -- which is not consistent with your own
# definition of the equivalence. Check out your example code; you
# didn't even include 'a'.
#
# I never said *a is a variable.
#
# But you treated it as such in your example code.
No I did not. At least not intentionally.
# I just noticed that part of our disagreement comes from the fact that
# I am talking about C variables as they look at runtime, while you seem
# to also consider the source code to be relevant. Am I correct?
#
# You're correct in that I considered the source. But that's not really
# important. I could leave the C source and go to the C runtime.
I think it would be easier to talk this way... After all, int a=1
and int b=1 are *exactly* equivalent in C, while a=1 and b=1 are
not quite as equivalent in Python (consider if next line of program
contains stuff like input() )
# However, then we don't really have anymore a C variable 'a', we
# only have a memory location.
I tend to disagree -- I would say that the term variable has meaning
also at runtime.
# That's probably one more inconsistency in the analogy.
Not really, that's exactly what makes the analogy work.
--
Best wishes,
Slawomir Nowaczyk
( [EMAIL PROTECTED] )
Don't personify computers. They hate that.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Nested function scope problem
On Sun, 06 Aug 2006 11:37:46 -0300 Gerhard Fiedler [EMAIL PROTECTED] wrote: # On 2006-08-06 06:41:27, Slawomir Nowaczyk wrote: # # Since Python doesn't (supposedly) have variables, it couldn't have come # from Python. # # The idea (of this part of the thread) was to find the analogy between C # variables and Python variables, at least that's what you said a few # messages ago. Yes. *I* believe Python has variables. I was under an impression that you do not. But I do not believe there is any identity of a variable which corresponds to id(). Still, you used such term -- repeatedly. I do not know what do you mean by it. # You claimed that there exists such an analogy between C variables # and Python variables. Yes. # (We never disputed the existence of Python variables; not sure why # you come up with that now. That was so far back in this thread.) Well, I *only* came out with C/Python analogy in order to show that it actually *does* make sense to talk about variables in Python -- since some people claimed Python variables are a completely different kind of beast than C variables, thus we should not be using the same name. It was never my goal to show that Python and C variables behave the same way or anything. So it seems like we misunderstood each others intents. -- Best wishes, Slawomir Nowaczyk ( [EMAIL PROTECTED] ) I don't care if I AM a lemming. I'm NOT going! -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about using python as a scripting language
On Tue, 08 Aug 2006 14:32:32 +0200
Wildemar Wildenburger [EMAIL PROTECTED] wrote:
# Steve Lianoglou wrote:
# Delaney, Timothy (Tim) wrote:
# This is just asking for trouble.
#
# my_list = eval('import shutil; shutil.rmtree('/')')
#
# Hah .. wow.
#
# And in related news: you still shouldn't be taking candy from
# strangers.
#
# Point well taken. Thanks for flagging that one.
#
# Heck, whenever *is* it OK to use eval() then?
eval is like optimisation. There are two rules:
Rule 1: Do not use it.
Rule 2 (for experts only): Do not use it (yet).
:)
--
Best wishes,
Slawomir Nowaczyk
( [EMAIL PROTECTED] )
The good people sleep much better at night than the bad people. Of course,
the bad people enjoy the waking hours much more.
--
http://mail.python.org/mailman/listinfo/python-list
Re: do people really complain about significant whitespace?
On Wed, 09 Aug 2006 05:00:20 -0700 [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: # Slawomir Nowaczyk wrote: # # I must admit I do not get this indicate intentions twice argument, # even though I heard it a number of times now... It's not that braces # require more work or more typing or something, after all -- at least # not if one is using a decent editor. # # Its not the typing, its the fact that when you say the same thing # twice, there is the potential for them to get out of sync. Which, in my book, is the *right* thing... if I see a wrongly indented piece of code, that's a good sign that it needs to be checked. It's the same principle as in if documentation and code disagree, both are probably wrong. YMMV, of course. # If the method the compiler uses (braces) and the method the human # uses (indentation) to determine what the code does don't agree, # then a reader will be likely to misunderstand what it will actually # do. Well, not in my experience. In my experience, such discrepancies usually only show up in places where something bad happens anyway. # One of the driving principles behind Python is that, because code # will be read more often than written, readability is more # important. That's exactly my point :) -- Best wishes, Slawomir Nowaczyk ( [EMAIL PROTECTED] ) Today advance is so rapid that even the astronauts who set foot on the moon in 1969 had never seen a digital watch -- http://mail.python.org/mailman/listinfo/python-list
Re: do people really complain about significant whitespace?
On Wed, 09 Aug 2006 09:13:21 -0500 [EMAIL PROTECTED] wrote: # # of the driving principles behind Python is that, because code will be # read more often than written, readability is more important. # # Stephen In which case, for long functions with multiple levels of # Stephen indentation Python fails compared to languages that use braces # Stephen or END or end; etc. # # No. In that case Python makes it more readily apparent that your code is # too complex. With C, Java, C++, Perl or FORTRAN you just smush everything # over to the left and pretend it's not. ;-) Well, one space is sufficient indentations for Python, right? So even on 80 column screen, you can easily fit about 40 levels of nesting before it becomes a real problem :D In other words, it is possible to write bad code in any language. We should focus on making it easier to write good code, not to make writing bad code difficult. -- Best wishes, Slawomir Nowaczyk ( [EMAIL PROTECTED] ) The nice thing about standards is that there are so many of them to choose from. -- http://mail.python.org/mailman/listinfo/python-list
Re: Nested function scope problem
On Sat, 05 Aug 2006 02:55:03 -0700 Bill Pursell [EMAIL PROTECTED] wrote: # Gerhard Fiedler wrote: # There's no Python equivalent to int*p=345; *p++;. # # Sure there is: # # os.kill(os.getpid(), signal.SIGSEGV) LOL... that's a good one :) -- Best wishes, Slawomir Nowaczyk ( [EMAIL PROTECTED] ) 90% of the time I'm right, so why worry about the other 3%? -- http://mail.python.org/mailman/listinfo/python-list
Re: regex question
On Fri, 04 Aug 2006 14:55:34 -0700
John Machin [EMAIL PROTECTED] wrote:
# def test(data):
# format, index = 'abcd', 0
# for c in data:
# i = format.index(c)
# if i index+1:
# return False
# index = i
# return index==format.index('d')
#
# Could be made faster if format was made a dictionary or if one wanted
# to compare characters directly. Writing (and profiling) left as an
# exercise for a reader.
#
# Premature optimisation
#
# # test('bcd')
# True
# #
Oooops... You are right. Should be
format, index = 'abcd', -1
of course. Thanks.
--
Best wishes,
Slawomir Nowaczyk
( [EMAIL PROTECTED] )
I believe that math illiteracy affects 7 out of every 5 people.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Nested function scope problem
On Fri, 04 Aug 2006 13:42:59 -0300 Gerhard Fiedler [EMAIL PROTECTED] wrote: # On 2006-08-04 12:12:44, Antoon Pardon wrote: # # You can hardly claim that what gets printed is the id of the variable c. # (Well, you can claim, but few C programmers would follow you.) # # That's possible. I wouldn't expect too many C programmers to have any # notion of id of a variable. I, for example, never thought about such # thing before this thread. # # But even in Python we don't speak of id of a variable. It is not the # variable that has an id. It is the object that is currently attached to # the variable that has an id. Yes we can use id of a variable as a # shortcut for the correct formulation as long as you keep in mind that it # is not the variable itself that has an id. # # This sounds a bit like saying yes we can use the term 'variable' as a # shortcut for the correct formulation (object associated to a name) as long # as we keep in mind that it is not actually a variable :) No it doesn't. Anyway, where did the idea that id(a) is an id of a variable a come from, anyway? Since Python doesn't (supposedly) have variables, it couldn't have come from Python. Since C doesn't have id(), it couldn't have come from C... So? Obviously, if we use pythonic terminology of binding, a statement would be that id(a) is an id of a binding, which doesn't make much sense. Antoon is right, id(a) is an identifier _of an object bound to a_. Which translates into C++ as an object pointed to by a, IMHO. -- Best wishes, Slawomir Nowaczyk ( [EMAIL PROTECTED] ) If at first you do succeed, try not to look astonished. -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal: [... for ... while cond(x)]
On Sun, 06 Aug 2006 18:59:39 + (GMT) Duncan Booth [EMAIL PROTECTED] wrote: # I suggest a new extension of the list comprehension syntax: # # [x for x in xs while cond(x)] # # which would be equivalent to # # list(itertools.takewhile(cond, xs)) # # What would this syntax offer that: # # [x for x in takewhile(cond, xs)] # # doesn't currently offer? # # The same thing that [f(x) for x in xs] offers that map(f, xs) doesn't, # and the same thing that [x for x in xs if f(x)] offers that filter(f, # xs) doesn't. It's more pythonic. You can use an expression for cond # instead of a lambda. # # No, the list comprehension lets you write an expression directly # avoiding a function call, and it also allows you to add in a # condition which can be used to filer the sequence. I am not sure if I understand you correctly, but... Does it? a = [0,1,2,3,7,8,9] [x for x in takewhile(lambda x: x in a, range(10))] [0, 1, 2, 3] [x for x in takewhile(x in a, range(10))] Traceback (most recent call last): File stdin, line 1, in ? TypeError: 'bool' object is not callable Did I miss something? Notice that using if gives different result: [x for x in range(10) if x in a] [0, 1, 2, 3, 7, 8, 9] # Your proposal adds nothing. Well, I am not sure how useful the proposal really is, but it seems to add *something* if it would allow for things like: [x for x in range(10) while x in a] -- Best wishes, Slawomir Nowaczyk ( [EMAIL PROTECTED] ) Women who seek to be equal to men lack ambition. -- http://mail.python.org/mailman/listinfo/python-list
Re: Nested function scope problem
On Thu, 03 Aug 2006 17:27:26 -0300 Gerhard Fiedler [EMAIL PROTECTED] wrote: # But seriously, for my comment this seems off-topic. Well, you wrote but it's not really understandable with a C++ concept of variable. It is perfectly understandable to me. That's all I said (or, at least, all I wanted to say). # I did not say that you can't create Python behavior with C (of # course you can, you can do /everything/ in C :). You can build # constructs made up of C variables that simulate everything that any # Python construct does. That's not the point. The point is how the # simple, built-in language variable behaves. I agree. For me, Python variable behaves just like a C++ variable (a pointer, sure, but that's minor point to me... YMMV). # # You also don't expect the identity of a and b to be the same # # after assigning one to the other. # # Don't I? # # I don't know. Try replacing your printf statements with something # like printf(%x %i %i\n,a,a,*a); and watch the first column. # The address operator is probably for a C programmer the closest to # what the id() function is to a Python programmer. I disagree. At least in my understanding, which, up to now, was perfectly enough to explain everything about how Python variables behave: The address operator in C is what textual representation (i.e. what you type, like a) is in Python. Equivalent of id() is a dereference operator. Of course, there are probably other ways to look at this. But I still do not see why people claim that there is a significant difference between what variables are in Python and in C++. -- Best wishes, Slawomir Nowaczyk ( [EMAIL PROTECTED] ) If at first you don't succeed, redefine success. -- http://mail.python.org/mailman/listinfo/python-list
Re: regex question
On Thu, 03 Aug 2006 22:10:55 +0100
Gabriel Murray [EMAIL PROTECTED] wrote:
# Hello, I'm looking for a regular expression
Some people, when confronted with a problem, think I know, I'll
use regular expressions. Now they have two problems.
-- Jamie Zawinski
Therefore:
def test(data):
format, index = 'abcd', 0
for c in data:
i = format.index(c)
if i index+1:
return False
index = i
return index==format.index('d')
Could be made faster if format was made a dictionary or if one wanted
to compare characters directly. Writing (and profiling) left as an
exercise for a reader.
--
Best wishes,
Slawomir Nowaczyk
( [EMAIL PROTECTED] )
A mind is like a parachute. It doesn't work unless it's open.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Nested function scope problem
On Fri, 04 Aug 2006 10:10:45 -0300
Gerhard Fiedler [EMAIL PROTECTED] wrote:
# On 2006-08-04 07:36:25, Slawomir Nowaczyk wrote:
#
# # The address operator is probably for a C programmer the closest to
# # what the id() function is to a Python programmer.
#
# I disagree. At least in my understanding, which, up to now, was
# perfectly enough to explain everything about how Python variables
# behave:
#
# The address operator in C is what textual representation (i.e. what
# you type, like a) is in Python. Equivalent of id() is a dereference
# operator.
#
# But then you are not talking about C variables.
I am. The fact that Python variables behave like C pointers isn't
overly relevant. A pointer is perfectly good C variable to me.
# Using a normal C variable, this doesn't work:
#
# int c = 5;
# printf( id(c)=%x, *c );
Depends on what do you expect. The above is kind of equivalent to,
say:
locals()[5]
in Python. Of course, there is no object at memory address 5 (in C)
and no object in locals() named 5 (in Python). I agree there is a
difference between getting a segfault and getting an exception, but it
doesn't have much to do, IMHO, with what a variable is.
# You can hardly claim that what gets printed is the id of the variable c.
# (Well, you can claim, but few C programmers would follow you.)
That's possible. I wouldn't expect too many C programmers to have any
notion of id of a variable. I, for example, never thought about such
thing before this thread.
# What would be analogous in Python to the textual representation of
# the variable in C? The address operator in C in analog to the
# textual representation in Python. The textual representation in C
# is analog to ??? in Python?
There is no textual representation of variables in C -- at least not
at runtime. Why should there be? There is, after all, no equivalent to
eval('a=1') so why would anybody care what was variable named?
# You may be talking about C pointers and call the locations they point to
# variables.
Yes, I am talking about C pointers, but I call *them*, not what they
point at, variables.
# That's a big difference; those are /not/ C variables.
I agree, the locations are not variables.
# And they still are not the same.
OK, sure, there is a number of things that you can do to/with C variable
that you cannot to/with Python variable, so they are not the same. I
just feel the differences are not large enough to warrant
# What is analog in Python (using your analogy) to the address of the pointer
# variable in C (a in your example)?
Well, how about x='a'? It allows you to do locals()[x],
# Note that in standard C/C++ language, a and b in your example are variables
# (in fact the only variables), not *a and *b.
Agreed.
# (three and four should have been declared as constants, to be
# analogous to Python.)
True, but I didn't think it matters.
# So the only variables in your example (a and b) don't really behave
# according to your analogy.
Sorry, I do not follow.
# What behaves somewhat like your analogy are *a and *b -- neither of
# which are C/C++ variables. (Well, they are in your example, but
# only because of sloppily applying your analogy.
I never said *a is a variable.
# And they are not in the general case: pointers don't care whether
# they point to actual C/C++ variables, or to any other memory
# location.)
I think I lost you, but Python names do? Does a in your *.py file
care whether they are bound to any object?
I just noticed that part of our disagreement comes from the fact that
I am talking about C variables as they look at runtime, while you seem
to also consider the source code to be relevant. Am I correct?
--
Best wishes,
Slawomir Nowaczyk
( [EMAIL PROTECTED] )
Science is a differential equation. Religion is a
boundary condition. -- Alan Turing
--
http://mail.python.org/mailman/listinfo/python-list
Re: Nested function scope problem
On Sun, 30 Jul 2006 11:18:10 -0300
Gerhard Fiedler [EMAIL PROTECTED] wrote:
# In any case, the following doesn't seem to be implementation detail
# (and rather a part of the language), but it's not really
# understandable with a C++ concept of variable:
#
# a=3
# id(a)
# 3368152
# b=a
# id(b)
# 3368152
# b=4
# id(b)
# 3368140
How about that?
int main()
{
int three = 3;
int four = 4;
int *a, *b;
a = three;
printf(%i %i\n,a,*a);
b = a;
printf(%i %i\n,b,*b);
b = four;
printf(%i %i\n,b,*b);
return 0;
}
Just in case you don't have C compiler at hand, it prints:
1244896 3
1244896 3
1244888 4
# You don't expect the identity of the variable b to change with a simple
# assignment from a C/C++ point of view.
That depends on your definition of identity, of course.
# You also don't expect the identity of a and b to be the same
# after assigning one to the other.
Don't I?
--
Best wishes,
Slawomir Nowaczyk
( [EMAIL PROTECTED] )
You can tell a bigot, but you can't tell him much.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Static Variables in Python?
On Tue, 01 Aug 2006 07:37:20 -0400 Michael Yanowitz [EMAIL PROTECTED] wrote: #I like the class idea, however I realize that the class object itself # has to be global. But no more global than your original set_bit was... -- Best wishes, Slawomir Nowaczyk ( [EMAIL PROTECTED] ) To err is human, but to really fuck things up takes a computer. -- http://mail.python.org/mailman/listinfo/python-list
Re: How do you use this list ?
On Tue, 27 Jun 2006 14:22:19 + Grant Edwards [EMAIL PROTECTED] wrote: # Actually having mailing lists send you mail is insane. Just curious: what's insane about it? -- Best wishes, Slawomir Nowaczyk ( [EMAIL PROTECTED] ) Never attribute to malice that which can be adequately explained by stupidity. -- http://mail.python.org/mailman/listinfo/python-list
Re: BeautifulSoup error
On Fri, 16 Jun 2006 15:20:48 +1000 Ben Finney [EMAIL PROTECTED] wrote: # soup = BeautifulSoup() # soup.feed(port) # Traceback (most recent call last): #File stdin, line 1, in ? #File /usr/lib/python2.3/sgmllib.py, line 94, in feed # self.rawdata = self.rawdata + data # UnicodeDecodeError: 'ascii' codec can't decode byte 0xb8 in position 565: ordinal not in range(128) # # # Uses the default Python text encoding, 'ascii', when it needs to # decode the data in 'port' to Unicode. Some of the data in that # object makes no sense in the 'ascii' encoding, so it barfs. In other words, this works for me: soup.feed( unicode(port,iso-8859-1) ) -- Best wishes, Slawomir Nowaczyk ( [EMAIL PROTECTED] ) ^[:wq! Crap! Thought I was in vi. -- http://mail.python.org/mailman/listinfo/python-list
Re: a good programming text editor (not IDE)
On Thu, 15 Jun 2006 13:18:53 -0700 BartlebyScrivener [EMAIL PROTECTED] wrote: # Emacs must be dying if this thread could get all the way to 20 with # nobody arguing with the vi folks. We have learned the important lesson: those who are looking for true enlightenment will find Emacs anyway. We no longer feel the need to argue with people who praise various versions of notepad ;-) ;-) ;-) -- Best wishes, Slawomir Nowaczyk ( [EMAIL PROTECTED] ) Conscience is what hurts when everything else feels so good. -- http://mail.python.org/mailman/listinfo/python-list
Re: a good programming text editor (not IDE)
On Thu, 15 Jun 2006 15:52:49 -0700 BartlebyScrivener [EMAIL PROTECTED] wrote: # Most IDEs are rather weak as text editors compared to emacsen. # # That's true, but even emacs and xemacs don't offer simple automatic # word wrap (i.e. wrap a line without splitting words or putting an eol # or hard carriage return at the end of every line). Of course it does... there is longlines.el and longlines-mode in my copy of GNU Emacs: ,-- | Toggle Long Lines mode. | In Long Lines mode, long lines are wrapped if they extend beyond | `fill-column'. The soft newlines used for line wrapping will not | show up when the text is yanked or saved to disk. `- I do not use it, personally, but it does exist. -- Best wishes, Slawomir Nowaczyk ( [EMAIL PROTECTED] ) COMMAND: A suggestion made to a computer. -- http://mail.python.org/mailman/listinfo/python-list
Re: better Python IDE? Mimics Maya's script editor?
On Thu, 08 Jun 2006 16:40:48 -0700 warpcat [EMAIL PROTECTED] wrote: # I'm using PythonWin right now and trying to find something better, # mainly with this functionality: *Assuming* I understood your description correctly, python-mode in Emacs does what you want. Emacs is hardly a substitute for PythonWin, though: the learning curve is quite steep. -- Best wishes, Slawomir Nowaczyk ( [EMAIL PROTECTED] ) If you're constantly looking behind you, you may miss the frontal attack. -- http://mail.python.org/mailman/listinfo/python-list
Re: CONSTRUCT - Python's way of Ruby's alias_method
On Thu, 08 Jun 2006 06:05:35 -0700 Tim N. van der Leeuw [EMAIL PROTECTED] wrote: # Since your question is so much about Django, you might want to ask # on Django groups. Now *that*, and the rest of your post, was uncalled for. This thread is perfectly on topic for this list and the question asked concerns *Python*, with django being only a use case. -- Best wishes, Slawomir Nowaczyk ( [EMAIL PROTECTED] ) Some drink at the fountain of knowledge. Others just gargle. -- http://mail.python.org/mailman/listinfo/python-list
Re: CONSTRUCT - Python's way of Ruby's alias_method
On Thu, 08 Jun 2006 15:28:39 +0300 Ilias Lazaridis [EMAIL PROTECTED] wrote: # *IMPORT* # # I would like to know, if this construct is valid, or if it can # result in problems (that I do not see as a newcomer): The intricacies of import are far beyond me, but FWIW I do not see anything wrong in this code. # Is there any way (beside a patch) to alter the behaviour to an # existing function. You can just assign new function to the old name. There are a few loops to hop through if you want to alter the behaviour of an existing *method*... There is an example -- I do not know if a good one -- here: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/52192 -- Best wishes, Slawomir Nowaczyk ( [EMAIL PROTECTED] ) Strange how people who don't even know their neighbors are extremely curious to know if there's extra-terrestrial life. -- http://mail.python.org/mailman/listinfo/python-list
Re: An oddity in list comparison and element assignment
On Sat, 03 Jun 2006 17:03:00 -0700 [EMAIL PROTECTED] (Alex Martelli) wrote: # Terry Reedy [EMAIL PROTECTED] wrote: # # Depends what one means by 'copy'. See below for your alternate wording. # # Please give me a reasonable definition of the unadorned word copy # which would make this statement false. (And, just to forestall one # possible attempt: no, I cannot agree that a ``deepcopy'' is a reasonable # definition of the _unadorned_ word copy). Actually, when *I* think about the word copy, I have in mind what happens with files... and I to me semantics of []*3 is more like symbolic linking, not copying. While I, personally, understand the sentence in question The result of S*n or n*S is the concatenation of n copies of S correctly, I *do* see how it might be misunderstood by others. Not that I know how to express it better :-( -- Best wishes, Slawomir Nowaczyk ( [EMAIL PROTECTED] ) Don't wake me for the end of the world unless it has very good special effects -- Roger Zelazny -- http://mail.python.org/mailman/listinfo/python-list
Re: An oddity in list comparison and element assignment
On Thu, 01 Jun 2006 19:16:16 -0700 [EMAIL PROTECTED] (Alex Martelli) wrote: # What does parallel mutations mean? In particular, what should be the # results of each of the following three comparisons: # # x, y, z = [1],[1],[1] # a, b = [x,y], [y,z] # c, d = [[1],[1]], [[1],[1]] # a == b # c == d # a[0].remove(1) # b[0].remove(1) # a == b # # So, do I understand correctly that you would like first comparison # (a==b) to return False and second comparison (c==d) to return # True? # # I sure hope not, So do I, but that's how I understood Michaels' words... # In fact, I'm starting to wonder if by Michaels' requirement ANY # non-*IDENTICAL* containers (with non-identical mutable items) could # EVER be deemed equal. If he's arguing that == should mean # exactly the same as is, that's even crazier than I had gauged so # far. I think he explicitly said that is doesn't fulfill his requirements either... but then, I am not sure as I do not understand what his requirements actually are (they seem to make some sense for immutable objects, but how should they generalise to mutable stuff I have no idea). PS. Thanks for explanation about Bank of America: I had no clue how it works in realty, it just had a good name ;) -- Best wishes, Slawomir Nowaczyk ( [EMAIL PROTECTED] ) Java is clearly an example of a MOP (money-oriented programming) -- Alexander Stepanov -- http://mail.python.org/mailman/listinfo/python-list
Re: An oddity in list comparison and element assignment
On Thu, 01 Jun 2006 13:40:34 -0700 [EMAIL PROTECTED] wrote: # Scott David Daniels wrote: # Would you say that envelope containing five $100 bills is equal to # an envelope containing five $100 bills with different serial numbers? # Yes (unless I was testing the assertion that the second envelope did # not contain counterfeits of the first) So, what if Bank of America later decided that bills with serial numbers containing 7 are no longer valid? In other word, *if* you assume equality must be preserved by future modifications, than no two different (modifiable) objects can ever be really equal. -- Best wishes, Slawomir Nowaczyk ( [EMAIL PROTECTED] ) I believe that math illiteracy affects 7 out of every 5 people. -- http://mail.python.org/mailman/listinfo/python-list
Re: An oddity in list comparison and element assignment
On Thu, 01 Jun 2006 15:12:23 -0700 [EMAIL PROTECTED] wrote: # I believe that 'is' tests equality of reference, such that # # a = range(1,3) # b = range(1,3) # a is b # False # # The 'is' operator tells you whether a and b refer to the same object. # What I've been discussing is whether == should test for structural # equality so that a and b remain equivalent under parallel mutations # (and also under single mutations to common references) What does parallel mutations mean? In particular, what should be the results of each of the following three comparisons: x, y, z = [1],[1],[1] a, b = [x,y], [y,z] c, d = [[1],[1]], [[1],[1]] a == b c == d a[0].remove(1) b[0].remove(1) a == b So, do I understand correctly that you would like first comparison (a==b) to return False and second comparison (c==d) to return True? -- Best wishes, Slawomir Nowaczyk ( [EMAIL PROTECTED] ) Living on Earth may be expensive, but it includes an annual free trip around the Sun. -- http://mail.python.org/mailman/listinfo/python-list
