Re: Python ++ Operator?
2011/7/15 Rafael Durán Castañeda : > What's the meaning of using i++? Even, does exist ++ operator in python? No it doesn't, which is a good thing. Python differentiates between expressions and variable assignments. "i++" in C both assigns the value i + 1 to i AND evaluates to i. Pre and post-increments are almost always confusing unless they are used as the counter-variable inside for-loops. -- mvh/best regards Björn Lindqvist http://www.footballexperts.net/ -- http://mail.python.org/mailman/listinfo/python-list
Getting rid of "self."
I think it would be cool if you could refer to instance variables without prefixing with "self." I know noone else thinks like me so Python will never be changed, but maybe you can already do it with Python today? .import sys . .def magic(): .s = "" .for var in sys._getframe(1).f_locals["self"].__dict__: .s += var + " = self." + var + "\n" .return s . .class A: .def __init__(self): .self.hi = "yo" . .def meth(self): .exec(magic()) .print hi . .a = A() .a.meth() It works! exec(magic()) does the needed hi = self.hi. Not so impressive in this case but much cooler when there is more instance variables around. But the solution is very ugly because you have to write exec(magic()) in every method. So I'm asking here if someone knows a better way, maybe using decorators or metaclasses or other black magic? -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: Getting rid of "self."
Thank you for your replies. But they don't deal with my original question. :) I have read the thousands of posts all saying "self is good" and they are right. But this time I want to be different m-kay? I figure that there might be some way to solve my problem by doing this: .def instancevar2locals(method): .# Do something magic here so that exec(magic()) is automagically run each time .# the function is invoked. .newmethod = method .return newmethod And then in the class definition something like this: .class A: .def __init__(self): .self.hi = "hi" .def meth(self): .print hi .meth = instancevar2locals(meth) But beyond that, I have no idea and I would be grateful if someone would like to help me with it. -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: Securing a future for anonymous functions in Python
The more features a language has, the harder it becomes to learn. An example of that is C++ which has almost everything. Classes, structs, templates, strange keywords that noone uses like auto, inline const, passing by reference/value, enum, union, lots of macros, multiple inheritance, namespaces etc. I'll bet that you could shave off 50% of C++'s features and it would still be 95% as usable[*]. Judging by the number of PEP proposals and syntax additions that appear on the mailing list every day Python could some day become as bloated. We don't want that, do we? So how do we avoid feature bloat?: 1. We stop adding features, either now or at some point in the future. 2. We remove some features. Either way we have to put a limit on the number of features we want Python to have. Let's call that number X where X is a number much smaller than infinity. With a set limit, the discussion becomes "which features should be selected for use in Python?" instead of "should this feature be added/removed?" Personally, I don't care either way if lambda is removed or retained, but I would much rather have the "with" keyword someone proposed, do-while loops or whatever. I think there are way too many good features out there just waiting to take lambdas place. * - Please don't ask me to make that bet. -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: Getting rid of "self."
Thank you for your replies. It is very nice to see that a thread you started is generating so much discussion, but please, I have read the previous debates so I know all about what people think about self. Spare the "you shouldn't do that" and "self is here to stay" replies to the threads in which people are actually suggesting changing the syntax. :) I know the solution I presented is not working ideally, because you have to use self to assign to instance attributes like "self.hi = 'baby'". > Sean Ross: > http://starship.python.net/crew/mwh/hacks/selfless.py That's excellent! There is one small problem with the code though: .class Hi(Selfless): .__attrs__ = ["x"] .def __init__(x): .self.x = x In this case, I think the Python interpreter should realise that the parameter x shadows the attribute x. But the selfless code has problems with that. I want it to work exactly like how the situation is handled in Java and C++. > Alex Martelli: >> Björn Lindqvist: >> I think it would be cool if you could refer to instance variables >> without prefixing with "self." I know noone else thinks like me so > Some do -- Kent Beck's excellent book on TDD-by-example has a specific > grouse against that in the chapter where he develops the unittest module I have to get myself that book. > Alex Martelli: > A decorator can entirely rewrite the bytecode (and more) of the method > it's munging, so it can do essentially anything that is doable on the > basis of information available at the time the decorator executes. Which I believe means that the instance variables have to be declared in the class? I am content with declaring them like the selfless approach does: __attrs__ = ["hi", "foo"] It's not optimal because it would lead to some "name duplication" when a class is __init__:ed. .__attrs__ = ["hi", "foo"] .def __init__(_hi, _foo): .hi = _hi .foo = _foo I guess you can solve that adequately by using one of the recipes from the Cookbook that automagically initialises an objects variable depending on which variables was passed in the parameter list. Another alternative would be not to declare the variables in an __attr__ list, and instead let them be "declared" by having them initialised in the __init__. I.e: .def __init__(hi, foo): .self.hi = hi .self.foo = foo When the metaclass then does it magic, it would go through the code of the __init__ method, see the assignments to "self.hi" and "self.foo", decide that "hi" and "foo" are attributes of the object and replace "hi" and "foo" in all other methods with "self.hi" and "self.foo". The downside is that it probably could never be foolproof against code like this: .def __init__(hi, foo): .if hi: .self.hi = hi .else: .self.foo = foo But AFAIK, that example is a corner case and you shouldn't write such code anyway. :) > Alex Martelli: > You do, however, need to nail down the specs. What your 'magic' does > is roughly the equivalent of a "from ... import *" (except it > ... > Then, you must decide whether this applies to all names the method > accesses (which aren't already local). For example, if the method > has a statement such as: > x = len(y) All names should be checked like this: 1. Is the name in the parameter list? If so, do not rebind it. 2. Is the name in the objects attribute list? If so, prepend "self." 3. Do stuff like normal. Example: .class Foo(Selfless): .def __init__(x): .print x .self.x = x*2 .def meth(): .x = x + 10 .print x .def meth2(x): .print x .print self.x .self.x = x . .o = Foo(50) .print o.x .o.meth() .o.meth2(12) .print o.x Outputs: 50 100 110 12 110 12 > Alex Martelli: > If you can give totally complete specifications, I can tell you > whether your specs are doable (by a decorator, or other means), how, > and at what cost. Without knowing your specs, I can't tell; I can > _guess_ that the answer is "probably doable" (as long as you're not > demanding the code in the decorator to be an oracle for the future, This is promising, I'm content with whatever slowdowns necessary as long as I can prove those who say "you can't do it" wrong. :) It seems to me that it should be doable by having the metaclass that modifies the class go through the class and bytecode-rewrite all its methods. So there has to be a big slowdown when the class is created, but after that, it should execute at pure Python speed? That doesn't seem to hard, and pretty robust too since bytecode doesn't change so often. And THEN I'll rewrite python-mode so that it syntax highlights member attributes! It will be cool. -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: Refactoring; arbitrary expression in lists
> # do other non-extension-related tests here > if basename.find( "Makefile" ) != -1: > return "text/x-makefile" I believe this can be nicelier written as: if "Makefile" in basename: -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: search engine
> hi all, i´m doing a search engine using python for the spider and php > to make a web for the search. The Database i have choosen is > postgreSQL. Do you think it is a good choosen? Any suggestion? "Databases are implementation details! Considering the database should be deferred as long as possible. Far too many applications are inextricably tied to their databases because they were designed with the database in mind from the beginning. Remember the definition of abstraction: the amplification of the essential and the elimination of the irrelevant. The database is irrelevant at this stage of the project; it is merely a technique used for storing and accessing data, nothing more." (Robert C. Martin, Agile Software Development, p. 194) -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: About standard library improvement
The process seem slow. I've submitted two patches and haven't gotten any response so far, but it has only been three weeks. Other patches seem to be idling for months. I'm not complaining, just want to know why the process is so slow and what you can do when you submit patches/bug reports to speed it up? -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: Alternative to standard C "for"
> I am quite new to Python, and have a straight & simple question. > In C, there is for (init; cond; advance). We all know that. > In Python there are two ways to loop over i=A..B (numerical.): > 1) i = A >while i ...do something... > i+=STEP This is indeed quite ugly. You rarely need such loops in Python and with some thinking you can often translate the C-equivalent to something more pythonic. As you guessed, your second problem is best solved with a generator function - xrange(). It is completely equal to range() except that it returns a generator instead of a list. -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: Favorite non-python language trick?
I like C++ templates so that you can ensure that a list only contain items of one type. I also like the JMP instruction in x86 assembler, you could do some nasty tricks with that. -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: namespaces module (a.k.a. bunch, struct, generic object, etc.) PEP
I like it alot! My only minor complaint is that the name is to long. Also I *really wish* the Namespace could do this: r, g, b = col = Namespace(r = 4, g = 3, b = 12) But alas, I guess that's not doable within the scope of the Namespace PEP. -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: Unit Testing in Python
> put it) PyUnit project. I'm sorry if this is a obvious question or one > that has already been answered, but unit-testing sounds interesting and > I'm not sure where to start. Hi Ryan. I belive this (http://www.xp123.com/xplor/xp0201/index.shtml) is a good way to learn about unit testing by practice if you already know the basics of it. It is written in Java but is easy to translate to Python. Unittesting really is great in Python, I try to use it for anything but simple and dirty hacks. -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: list of all type names
> Python has one feature that I really hate: There are certain special > names like 'file' and 'dict' with a predefined meaning. Yet, it is > allowed to redefine these special names as in > > dict = [1:'bla'] dir(__builtins__) Yes, rebinding builtin names accidentally is an annoying and I think everyone has made that mistake at least once. Maybe PyChecker can issue a warning? -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: Best way to make a list unique?
The Cookbook features another interesting way to do it: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/204297 -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: RELEASED Python 2.4 (final)
Christmas came early this year. Thank you all nice Python developers. -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: decorators ?
Some more decorator examples.
How to create abstract methods using an @absractmethod decorator:
http://www.brpreiss.com/books/opus7/html/page117.html
Generics, property getters and setters. I don't know what these
decorators are supposed to do:
http://www.cis.upenn.edu/~edloper/pydecorators.html -
And according to this,
http://www.prothon.org/pipermail/prothon-user/2004-August/003173.html,
one use of decorators is to put a functions docstring before the def
f(): line like this:
@doc("""blabla does something.""")
def blabla():
Here is one decorator for optimizing:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/277940
I think the essence of decorators is that it makes it possible to do
in Python what you in other languages do with method qualifiers. This
declaration in Java
public synchronized static void doStuff()
would you write in Python as
@public
@synchronized
@staticmethod
def doStuff():
I haven't seen an example of a @synchronized decorator, but I assume
it is possible. Hopefully, it is possible to create a @private
decorator which throws some kind of exception when a private method is
accessed from outside the class. If that is possible, then it would
also be nice to have a @public decorator which doesn't do anything. As
far as I know, only two decorators are included in the standard
library in Python 2.4, @staticmethod and @classmethod. That is a
little unfortunate, because many more "obvious ones" could have been
included. The devs are probably planning to correct that in the coming
versions.
That is all I know about decorators. Or rather THINK I know from
reading stuff on the internet. Please don't flame me if I'm wrong. :)
--
mvh Björn
--
http://mail.python.org/mailman/listinfo/python-list
Re: Best book on Python?
I haven't read any Python paper books myself but as Christmas is coming up, I've checked up on what Python books other people recommend. Everyone who has reviewed Python books seem to like these books: * Python Essential Reference * Python Cookbook * Python in a Nutshell The last two are both written by Alex Martelli and the cookbook is IMHO really awesome. -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: Pre-PEP: Dictionary accumulator methods
I like count() and appendlist() or whatever they will be named. But I have one question/idea: Why does the methods have to be put in dict? Can't their be a subtype of dict that includes those two methods? I.e.: .histogram = counting_dict() .for ch in text: .histogram.count(ch) Then maybe some more methods can be added tailor-mode for these two types of dicts?: .for ch in string.ascii_letters: .print "Frequency of %s = %d." % (ch, histogram.freq(ch)) Or something, you get the idea. -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: unittest vs py.test?
py.test is awesome, but there is one slight flaw in it. It produces to much output. All I want to see when all tests pass is "All X passes succeded!" (or something similar). py.test's output can be distracting. -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
A little request about spam
Please do not reply to spam. Replying to spam makes it much harder for spam filters to catch all the spam or will produce very many false positives. Atleast that's how gmail's filter works. And if you must reply, please change the subject line. On 13 Apr 2005 17:50:06 -0500, "."@bag.python.org <"."@bag.python.org> wrote: > Nuf said. > -- > http://mail.python.org/mailman/listinfo/python-list > -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: Guessing the encoding from a BOM
2014/1/16 Steven D'Aprano : > def guess_encoding_from_bom(filename, default): > with open(filename, 'rb') as f: > sig = f.read(4) > if sig.startswith((b'\xFE\xFF', b'\xFF\xFE')): > return 'utf_16' > elif sig.startswith((b'\x00\x00\xFE\xFF', b'\xFF\xFE\x00\x00')): > return 'utf_32' > else: > return default You might want to add the utf8 bom too: '\xEF\xBB\xBF'. > (4) Don't return anything, but raise an exception. (But > which exception?) I like this option the most because it is the most "fail fast". If you return 'undefined' the error might happen hours later or not at all in some cases. -- mvh/best regards Björn Lindqvist -- https://mail.python.org/mailman/listinfo/python-list
Re: What do you want in a new web framework?
On 8/20/06, Dave Richards <[EMAIL PROTECTED]> wrote: > Really, really good documentation. > > Dave ... Which is the one thing no Python web framework provides. :( A framework with really good documentation (preferably translated into multiple languages) would be, I'm sure, the PHP/Ruby on Rails killer everyone seem to hope for. > On 20 Aug 2006 11:58:50 -0700, [EMAIL PROTECTED] < > [EMAIL PROTECTED]> wrote: > > Hello Everyone, > > > > Now, I'm working on a new web framework. I tried many test on the other > > programming languages. Then i decided to use python on my web framework > > project. > > > > Now i want to listen all of you. What do you want in that web > > framework(Easy use of Database, Easy use of XML, GUI Designer, etc...)? > > > > I'm wating your answers. Thank you for all answers...! > > > > King Regards, > > > > Emrah Ayanoglu > > > > -- > > http://mail.python.org/mailman/listinfo/python-list > > > > > -- > http://mail.python.org/mailman/listinfo/python-list > > -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: PSF Infrastructure has chosen Roundup as the issue tracker for Python development
On 10/20/06, Brett Cannon <[EMAIL PROTECTED]> wrote: > At the beginning of the month the PSF Infrastructure committee announced > that we had reached the decision that JIRA was our recommendation for the > next issue tracker for Python development. Realizing, though, that it was a > tough call between JIRA and Roundup we said that we would be willing to > switch our recommendation to Roundup if enough volunteers stepped forward to > help administer the tracker, thus negating Atlassian's offer of free managed > hosting. > > Well, the community stepped up to the challenge and we got plenty of > volunteers! In fact, the call for volunteers has led to an offer for > professional hosting for Roundup from Upfront Systems. The committee is Good times! Mind telling us exactly how many volunteers have stepped forward? It may be an interesting statistic for how big interest there is in the "freeness" of software. -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Projecting MUD maps
Hello, I'm looking for an algorithm to project "MUD maps" such as the following map: http://www.aww-mud.org/maps/MUD_Maps/Caerin-colour.jpg MUD:s consists of rooms, each rooms has up to four orthogonal edges (north, east, west and south) that connects it to another room. So it is very easy to model a MUD as a directed graph. But projecting the graph on a surface is very complicated. For example, Room A:s North edge may connect it to Room B. But Room B:s South edge may connect it to Room C. Or another tricky example: Room A:s East edge connects it to Room B, whose East edge connect it to Room C, whose North edge connects it to Room D, whose West edge connects it to Room E, whose South edge connects it to Room A. In that example, there would be a "hole" between Room D and E. -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: Projecting MUD maps
On 11/5/06, Diez B. Roggisch <[EMAIL PROTECTED]> wrote:
> BJörn Lindqvist schrieb:
> > Hello, I'm looking for an algorithm to project "MUD maps" such as the
> > following map: http://www.aww-mud.org/maps/MUD_Maps/Caerin-colour.jpg
> >
> > MUD:s consists of rooms, each rooms has up to four orthogonal edges
> > (north, east, west and south) that connects it to another room. So it
> > is very easy to model a MUD as a directed graph. But projecting the
> > graph on a surface is very complicated. For example, Room A:s North
> > edge may connect it to Room B. But Room B:s South edge may connect it
> > to Room C. Or another tricky example: Room A:s East edge connects it
> > to Room B, whose East edge connect it to Room C, whose North edge
> > connects it to Room D, whose West edge connects it to Room E, whose
> > South edge connects it to Room A. In that example, there would be a
> > "hole" between Room D and E.
>
>
> try graphviz. You can also annotate some compass information ther, I
> guess it should make for a better placement.
Sorry, I think everyone misunderstood what my problem is. Which is not
very strange since I see now that I didn't explain it very well.
In the code below, I have created a simple Room class. It has up to
four edges; north, east, west and south. The Room class also has the
method get_projection() which recursively traverses through all
reachable rooms in the graphs and gives them x,y coordinates and
returns a dict containing x,y-coordinates and rooms. The function
project_dict() simply plots the dict on stdout.
The main() function demonstrates how a map consisting of nine rooms
should be plotted. All well so far. But if there had been an east-west
edge from G to I, then that edge would have overlapped C:s position.
That would have been wrong and I want the algorithm in
get_projection() to detect such overlaps and automatically fix them.
In this case, the fix would have been to add 2 to G and I:s
y-coordinate. Then the east-west edge from G to I wouldn't overlap any
room.
So I wonder if there is any algorithm that can do what I'm asking for?
--- mudgraph.py ---
# -*- coding: utf-8 -*-
import sys
class Dir:
dirs = ['n', 'e', 's', 'w']
@classmethod
def opposite(cls, dir):
"""
Return the opposite direction, i.e Dir.opposite('n') => 's'.
"""
opp_idx = (Dir.dirs.index(dir) + 2) % 4
return Dir.dirs[opp_idx]
class Room:
"""
A Room is a node in a mud map. Each room can have up to four
connections (edges) to other rooms in the cardinal directions;
north, east, south and west.
"""
def __init__(self, name = None):
self.name = name or "+"
self.n = None
self.s = None
self.e = None
self.w = None
def connect(self, dir, room):
"""
Create an edge dir from self to room. Also create an edge in
the opposite direction from room to self.
"""
setattr(self, dir, room)
setattr(room, Dir.opposite(dir), self)
def north(self, room):
self.connect('n', room)
def east(self, room):
self.connect('e', room)
def west(self, room):
self.connect('w', room)
def south(self, room):
self.connect('s', room)
def get_projection(self, x = 0, y = 0,
proj_dict = None,
visited = None):
"""
Return a dictionary containing all Rooms in the map as
values. Each key is the projected x and y position of the
room.
"""
if proj_dict is None:
proj_dict = {}
if visited is None:
visited = set()
visited.add(self)
proj_dict[x, y] = self
if self.n and not self.n in visited:
self.n.get_projection(x, y - 1, proj_dict, visited)
if self.e and not self.e in visited:
self.e.get_projection(x + 1, y, proj_dict, visited)
if self.w and not self.w in visited:
self.w.get_projection(x - 1, y, proj_dict, visited)
if self.s and not self.s in visited:
self.s.get_projection(x, y + 1, proj_dict, visited)
return proj_dict
def project_dict(dict):
coords = dict.keys()
max_x = 0
max_y = 0
min_x = 999
min_y = 999
for x, y in coords:
if x > max_x:
max_x = x
elif x < min_x:
min_x = x
if y > max_y:
max_y = y
elif y < min_y:
min_y = y
max_x += 1
max_y += 1
for y in range(
Re: iteration over non-sequence ,how can I resolve it?
On 28 May 2006 06:20:20 -0700, python <[EMAIL PROTECTED]> wrote: > at line "for j in linkReturned:" , raise an error: > File "C:\pythonProgram\test.py", line 308, in main > for j in linkReturned: > TypeError: iteration over non-sequence > how can I get a list from the return of thread.start() ? You can't. thread.start() always return None. > class PrintThread(threading.Thread): > def __init__(self, urlList): > threading.Thread.__init__(self) > urllist=[] > self.urllist=urlList >def run(self): > urllink=[] > .. > return urllink > > > for i in range(0,2): > thread=PrintThread(links) > threadList.append(thread) > linkReturned=[] > for i in threadList: > linkReturned=i.start() > for j in linkReturned: > links.append(j) >From the looks of this code it seems like you want a sub-routine not a thread. You can simulate returning a value from a thread by adding a "return value" attribute to the PrintThread class that the run() method writes to. Then you would have to add some form of synchronizing so that your main program does not try to read the "return value" of the thread before the thread actually has written the "return value." -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: code is data
> Personally, I would like to see macros in Python (actually Logix > succeeding is good enough). But I am no language designer and the > community has no interest in it. When I absolutely need macros, I will > go elsewhere. One must wonder, when is that? When do you absolutely need macros? -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: code is data
> > > community has no interest in it. When I absolutely need macros, I will > > > go elsewhere. > I *like* 1..5 (ada, ruby) instead of range(5). If I had macros, I would > have done it myself for *my* code. I think this example more is a symptom of a childish need to get things your way than of a deficiency in Python. BTW, range(5) = 0..4 in Ada and Ruby. You said "when I absolutely need macros" but none of your examples demonstrate any "absolute need." I can't see your point. -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: Can anyone please analyse this program for me (write a pseudocode for it).
> void
> usage(const char *proggie)
> {
> errx(EXIT_FAILURE, "Usage: %s ", proggie);
> }
>
> int
> main(int argc, char **argv)
> {
> struct in_addr addr;
>
> if (argc != 2 || !inet_aton(argv[1], &addr)) {
> usage(argv[0]);
> }
>
> (void)printf("%s\n", inet_ntoa(addr));
> return 0;
> }
1. Take an internet host address in dotted decimal form, if it is
valid convert it to an internal representation.
1b. If it isn't, or no address was supplied print usage information and exit.
2. Convert the internal representation back to dotted decimal form and print it.
--
mvh Björn
--
http://mail.python.org/mailman/listinfo/python-list
Re: Can anyone please analyse this program for me (write a pseudocode for it).
> > /* $Id: dotquad.c 3529 2005-10-01 10:15:22Z dyoung $ */ > > /* > > * Copyright (c) 2003, 2004 David Young. All rights reserved. > > * > > * This code was written by David Young. > > [snip code] > > Am I the only one who found it hilarious that this piece of code was made > up of 24 lines of actual code (including lines containing only a single > brace) but 29 lines of legalise? Good thing it was C then, had it been Python the hilariousness of the legalese/LOC ratio would have been lethal. -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
cookielib incorrectly escapes cookie
Hello,
I have some very serious trouble getting cookes to work. After a lot
of work (urllib2 is severly underdocumented, arcane and overengineerd
btw) I'm finally able to accept cookes from a server. But I'm still
unable to return them to a server. Specifically the script im trying
to do logs on to a server, get a session cookie and then tries to
access a secure page using the same session cookie. But the cookie
header cookielib produces is very different from the header it
received.
This example demonstrates it:
import cookielib
import urllib
import urllib2
# Install an opener that can handle cookies
policy = cookielib.DefaultCookiePolicy(rfc2965 = True)
cj = cookielib.CookieJar(policy)
opener = urllib2.build_opener(urllib2.HTTPCookieProcessor(cj))
urllib2.install_opener(opener)
# Login to the server
url = "http://server/dologin.htm";
params = urllib.urlencode({"user" : "foo", "pass" : "pwd"})
req = urllib2.Request(url, params)
handle = urllib2.urlopen(req)
# So far so good, the request should have added a cookie to the jar.
# The cookie header looks like this:
#
# Set-Cookie: SessionId="acf941a1fb4895ed"; Version=1; Path=/
#
assert len(cj) == 1
# Hack around the code in cookielib.CookieJar._cookie_attrs(),
# specifically the part that quotes, search for "quote_re" in the
# file cookielib.py.
cj._cookies_for_request(req)[0].version = 0
# Now request a secure page from the server
req = urllib2.Request("http://server/secure.htm";)
cj.add_cookie_header(req)
handle = urllib2.urlopen(req)
# Here is where it doesn't work unless the hack is applied. The cookie
# header that is sent without the hack looks like this:
#
# Cookie: $Version=1; SessionId=\"66b908e5025d93ed\"; $Path="/"
#
# It is not accepted by the server, probably because the SessionID
# string is wrong.
--
mvh Björn
--
http://mail.python.org/mailman/listinfo/python-list
Re: converting file formats to txt
On 4 Jul 2006 08:38:47 -0700, Gaurav Agarwal
<[EMAIL PROTECTED]> wrote:
> Thanks Steven, Actually i wanted a do text processing for my office
> where I can view all files in the system and use the first three to
> give a summary of the document. Instead of having somebody actually
> entering the summary. Seems there is no one code that can act as
> convertor across formats, i'll have to check out convertors for
> individual formats.
I have some old code that does just that. It uses pdftotext, catdoc
and links to convert .doc, .pdf and .html to text.
##
import mimetypes
from subprocess import call, Popen, PIPE
import sys
class ConversionError(Exception):
pass
class UnknownMimeType(ConversionError):
pass
class NotAMimeType(ConversionError):
pass
class ParseError(ConversionError):
pass
def has_program(progname):
return call(["which", progname], stdout = PIPE) == 0
def check_requirements():
missing = []
for prog in "catdoc", "pdftotext", "links":
if not has_program(prog):
missing.append(prog)
if missing:
print "You need to have the programs:", " ".join(missing)
return False
return True
if not check_requirements():
print "Needed external programs not found, quitting"
sys.exit(1)
def get_catdoc_args(infile):
return ["catdoc", "-s", "8859-1", infile]
def get_pdftotext_args(infile):
return ["pdftotext", infile, "-"]
def get_links_args(infile):
return ["links", infile, "-dump"]
def totext(document):
filetype_to_args_map = {"application/msword" : get_catdoc_args,
"application/pdf" : get_pdftotext_args,
"text/html" : get_links_args}
ftype, ign = mimetypes.guess_type(document)
if not ftype:
raise NotAMimeType, "Couldn't detect mimetype for %s" % document
try:
argfunc = filetype_to_args_map[ftype]
except KeyError:
s = "Don't know how to handle %s documents" % ftype
raise UnknownMimeType, s
p = Popen(argfunc(document), stdout = PIPE, stderr = PIPE)
text = p.stdout.read()
if p.wait():
# Force a better exception to be thrown if the file doesn't exist.
open(document)
raise ParseError, "Failed to parse %s" % document
return text
if __name__ == "__main__":
print totext("testpdf.pdf")
--
mvh Björn
--
http://mail.python.org/mailman/listinfo/python-list
Re: How to download a web page just like a web browser do ?
Mechanize (http://wwwsearch.sourceforge.net/mechanize/) is another option, it can even fill out forms! -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: What do you want in a new web framework?
> > > I have already suggested to the BDFL that he can remedy this situation > > > in Py3k: all he has to do, of course, is to add a LOT more keywords. > > > > Here is another remedy: he adds one of the frameworks to the standard > > library :) > > That didn't help Tk maintain a monopoly on Python GUI toolkits. In fact, it almost seems like it is the opposite. There exist better third party modules and packages of most functionality in the standard library. The only examples I can think of that seem to have a "monopoly" is subprocess, decimal, thread and pickle. Are there any more? Maybe when ElementTree joins the stdlib it will also have a monopoly on DOM parsers. -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: Allowing ref counting to close file items bad style?
On 8/30/06, Dan <[EMAIL PROTECTED]> wrote:
> Is this discouraged?:
>
> for line in open(filename):
>
In theory, it is. In practice, that is the way Python code is written
because it more natural and to the point. Not just for hacked together
scripts, lots of third party modules includes code like "data =
open(filename).read()" and similar idioms.
> Is my data safer if I explicitly close, like this?:
> fileptr = open("the.file", "w")
> foo_obj.write(fileptr)
> fileptr.close()
Have you ever experienced a problem caused by not explicitly closing
your file handles?
--
mvh Björn
--
http://mail.python.org/mailman/listinfo/python-list
Re: Pros/Cons of Turbogears/Rails?
On 8/31/06, Jorge Vargas <[EMAIL PROTECTED]> wrote: > On 31 Aug 2006 08:24:29 -0700, Adam Jones <[EMAIL PROTECTED]> wrote: > > I believe that is the most important part of TG, taking the best of > the best, and letting the framework adapt and morphe. > > for example noone plan to move to SA, 0.1 came out a couple of people > took and look and like it, then 0.2 was "mature enough" so people > started thinking about the migration. after that some code was made > and now we have TG with SA, eventually it will be the default. > Same with templates, kid is really weak at generating non-xml, it has > a plain text serializer but the input must be xml so that's overkill. > So a new template frontend (chettah was born). > > Someone ones said on the mailing list TG is the Ubuntu of web > frameworks, and I think I'll add and you can strip down the kernel and > it wont break :) But that is not really true. If you use Cheetah instead of Kid, you lose out: No widgets, no auto-generated code and the (incomplete) documentation won't apply anymore (it assumes Kid templates ofcourse). If you use SQLAlchemy instead of SQLObject, no identity framework, no administrative tools (tg-admin sql, CatWalk etc) and no documentation. If you use prototype instead of MochiKit... I have no idea what happens and using another webserver than CherryPy isn't possible right now, I guess? In fact, if you decide to replace so many modules that TurboGears depend on, what do you gain in using TurboGears at all? It seems like the TurboGears developers have a lot of work to do, (and a lot of documentation to write) if they want to make their framework as easy to use as others (ie: Django) that takes a more holistic approach. TurboGears more seem to be like emacs than Ubuntu - infinitely customizable... In the future both Rails and TurboGears will probably be great. But since someone mentioned Rails moving to YARV, and TurboGears moving to SQLAlchemy and Markup, it seems to me that they are both in a state of flux and not quite ready yet. -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: Pros/Cons of Turbogears/Rails?
> > > Someone ones said on the mailing list TG is the Ubuntu of web > > > frameworks, and I think I'll add and you can strip down the kernel and > > > it wont break :) > > > > But that is not really true. If you use Cheetah instead of Kid, you > > lose out: No widgets, > > Untrue. Even though I don't use widgets much myself, I wanted to make > sure they *could* be used with TurboStan, so I did a quick test with > Kevin's autocomplete widget. Worked fine. I can't see why Cheetah > would be any different. Maybe I stand corrected then. But the definition of the AutoCompleteField widget is here: http://trac.turbogears.org/turbogears/browser/trunk/turbogears/widgets/big_widgets.py#L88 I really don't understand how a completely different non-xml based templating engine, with a completely different syntax, would be able to grok that. > > If you use SQLAlchemy instead of SQLObject, no identity framework, > Completely false. Yes, I'm sorry. Last time I used it, it didn't work. But now it seem to have 100% compatibility. > > no administrative tools (tg-admin sql, > > True. > > > CatWalk etc > > True. > > > ) and no documentation. > > Partially true. The documentation exists but some of it is out-of-date > and it was never very complete to begin with. Of course, like many OSS > projects, the mailing list is your best resource and SQLAlchemy itself > has quite good documentation. SQLAlchemy does, yes. > > If you use prototype instead of MochiKit... I have no idea what > > happens > > You get Prototype instead of MochiKit. ... And the docs showing you how to integrate TurboGears with AJAXy stuff ofcourse no longer applies. > Personally I've chosen to go a different route on a couple things and > leave the rest intact. I expect most people are the same. With most > frameworks, there's typically one or two things most people don't like > and it's nice to be able to replace those things without a lot of fuss. > I don't see how that's a liability. I disagree, most frameworks do not let you replace its components. They are a "take it or leave it" kind of deal. I like that. The more adaptable you try to make a piece of code, the more complex it becomes. Obviously, it is easier to make code that supports one templating engine than to make it that supports everyone. You then most solve that additional complexity. Both in the code AND in the documentation and you must ensure that the additional complexity doesn't "leak" and make users life miserable. I think Jorge claimed that TurboGears was very pluggable and I claimed that it wasn't so. My point is that making the code pluggable is not enough. All the stuff around it also need to support the pluggability, not the least the docs. > That's odd, because I've actually used both and found TurboGears far > easier to get started with (no mucking about with Apache and mod_python > for one thing, no need to setup explicit url regexes just to get "hello, > world" on a page). > > Judging from your above comments it sounds to me like you're mostly > speculating about TurboGears. Not so. During 3 months a few months ago I've built a pretty big web application using TurboGears. The easy of use of a framework isn't writing "hello, world" applications, it is finding out how to do things, doing them and how fast you can do it. > > In the future both Rails and TurboGears will probably be great. But > > since someone mentioned Rails moving to YARV, and TurboGears moving to > > SQLAlchemy and Markup, it seems to me that they are both in a state of > > flux and not quite ready yet. > > TurboGears is certainly in a state of flux although from an outside > (i.e. API) standpoint it's not nearly as bad as you might think from the > changes that have gone on under the hood. There's been only a few > breaking changes up til now (I converted a site I'd built on 0.8 to the > latest SVN last night and most of the issues I encountered were with my > own changes to TurboStan). You must have been luckier than me then or maybe you didn't use much advanced functionality? I converted a site from SVN head somewhere at 0.9 to 1.1 and there were lots of breakages. Anyway, I think we have different definitions for "not quite ready." Lets say you have to build and maintain a site or web application together with two other developers who (like most web developers) doesn't know Python. Would you then choose TurboGears? -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: SQLObject or SQLAlchemy?
I think this post by the author of SQLAlchemy perfectly summarizes the differences between the two ORMs: http://article.gmane.org/gmane.comp.python.sqlalchemy.user/1072/ -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: testing for valid reference: obj vs. None!=obs vs. obj is not None
> I have a reference to certain objects. What is the most pythonic way to
> test for valid reference:
>
> if obj:
>
> if None!=obs:
>
> if obj is not None:
The third way is the most precise way. It is often used in combination
with default arguments.
def __init__(self, amount = None):
if amount is not None:
self.amount = amount
else:
self.amount = self.calc_amount()
However, the first way is shorter and more concise. It really depends
on what obj is supposed to be and where you get obj from. If it is a
database and obj is an instance:
obj = db.get("sometable", id = 33)
(assuming db.get returns None if the object isn't found) Then "if
obj:" clearly is the right test. In general, I think "If obj:" is the
right answer, except when dealing with default arguments. And you must
be aware that some objects, like 0, [] or {} evaluate to False -- it
is possible that that could create some subtle bugs.
--
mvh Björn
--
http://mail.python.org/mailman/listinfo/python-list
Re: for: else: - any practical uses for the else clause?
On 9/29/06, Johan Steyn <[EMAIL PROTECTED]> wrote: > I agree that it is meaningless without a break statement, but I still find > it useful when I want to determine whether I looped over the whole list or > not. For example, if I want to see whether or not a list contains an odd > number: > > for i in list: > if i % 2 == 1: > print "Found an odd number." > break > else: > print "No odd number found." > > Without the else clause I would need to use an extra variable as a "flag" > and check its value outside the loop: You can use generator comprehension: if (i for i in list if i % 2 == 1): print "Found an odd number." else: print "No odd number found." I *think* any() should also work: if any(i % 2 == 1 in list): And so on. For every use of the for/else clause there exists a better alternative. Which sums up my opinion about the construct -- if you are using it, there's something wrong with your code. -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: for: else: - any practical uses for the else clause?
> How do you transform this?
>
> height = 0
> for block in stack:
>if block.is_marked():
>print "Lowest marked block is at height", height
>break
>height += block.height
> else:
>raise SomeError("No marked block")
def get_height_of_first_marked_bock(stack):
height = 0
for block in stack:
if block.is_marked():
return height
height += block.height
raise SomeError("No marked block")
height = get_height_of_first_marked_block(stack)
print "Lowest marked block is at height", height
Yes, this transformation is one line longer, but the control flow is
much easier to understand. In general, using the for/else clause mixes
the retrieval and the usage of the element. Consider this:
for item in list:
if somecond(item):
A) do something with item
break
else:
B) exceptional code when somecond() doesnt match anything in list
The code that you write in the positions A and B really are misplaced.
They arent part of the iteration of list. The two tasks, find item and
do something with item should be separated.
def find_item(list):
for item in list:
if somecond(item):
return item
return None # OR raise an exception
item = find_item(list)
if item:
A) do something with item
else:
B) exceptional code
This is, IMHO, much better style.
--
mvh Björn
--
http://mail.python.org/mailman/listinfo/python-list
Re: Why not just show the out-of-range index?
On 12/4/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Russ schrieb:
> > I love Python, but every time I get an out-of-range error message, I
> > wonder why it didn't just tell me what the out-of-range index was and
> > what the allowable range was. Certainly that information must be
> > available to the exception handler, or how would it know that it is out
> > of range?
>
> Yes, that is true. The information is readily available.
>
> It's not true that it is "trivial" to fix, though: for every fix, there
> ought to be a new test case also, and you have to run the test suite.
> Depending on how fast a developer is, it may take between 30min and
> 1hour to get a fix implemented (for the list case alone, not counting
> all the other sequences).
Maybe it is not as trivial as the OP thought, but it can't be that
hard. It could be implemented as a utility function that does the
index checking:
bool
PyObject_IsIndexOutOfBounds(PyObject *o, const char *ob_name, int i)
{
if (i < 0 || i >= o->ob_size)
{
char buf[256];
const char fmt[] = "%s index %d not in range(%d)"
snprintf(buf, fmt, ob_name, i, o->ob_size);
PyErr_SetString(PyExc_IndexError, buf);
return true;
}
return false;
}
Then replace all code like:
if (i < 0 || i >= a->ob_size) {
PyErr_SetString(PyExc_IndexError, "string index out of range");
return NULL;
}
with:
if (PyObject_IsOutOfBounds((PyObject *)a, "string", i)
return NULL;
Or maybe add "index" and "length" attributes to the PyExc_IndexError?
"index" and "length" would of course be the invalid index and "length"
the length of the container. That would be harder and probably involve
some API change or something.
Sorry I haven't thought this through 100%, but I don't see how
actually _implementing it_ (getting it through the layers of
bureaucracy may be harder) could be so difficult.
> Even though I could fix it, I don't feel tempted to do so: I never had
> this problem; in most cases of IndexError, it was very clear what the
> problem was so I didn't need the additional information.
For you yes, for a newbie the extra information would certainly be helpful.
--
mvh Björn
--
http://mail.python.org/mailman/listinfo/python-list
Re: Why not just show the out-of-range index?
On 12/4/06, OKB (not okblacke) <[EMAIL PROTECTED]> wrote: > I think the same could be said of virtually all exceptions. What I > think would be ideal is that whenever an exception is raised, the > traceback tells you: > > 1) What the exception is > 2) The names of the variables involved in the offending expression > (or their character position in the line) > 3) The values of those variables There was a patch to that effect and a thread about it on python-dev two years ago [1]. Most python-devvers seemed skeptical. But the issue haven't come to closure yet. [1] - http://mail.python.org/pipermail/python-dev/2005-February/051470.html -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: Why not just show the out-of-range index?
On 12/4/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
BJörn Lindqvist wrote:
> Sorry I haven't thought this through 100%
obviously not.
And you're not helping. Anyway, here's the patch:
Index: Objects/listobject.c
===
--- Objects/listobject.c(revision 52915)
+++ Objects/listobject.c(arbetskopia)
@@ -131,7 +131,18 @@
return ((PyListObject *)op) -> ob_size;
}
-static PyObject *indexerr = NULL;
+static int
+list_check_index(PyListObject *o, const char *ob_name, int i)
+{
+if (i < 0 || i >= o->ob_size) {
+const char fmt[] = "%s index %d not in range(%d)";
+char buf[256];
+snprintf(buf, 256, fmt, ob_name, i, o->ob_size);
+PyErr_SetString(PyExc_IndexError, buf);
+return -1;
+}
+return 0;
+}
PyObject *
PyList_GetItem(PyObject *op, Py_ssize_t i)
@@ -140,13 +151,9 @@
PyErr_BadInternalCall();
return NULL;
}
- if (i < 0 || i >= ((PyListObject *)op) -> ob_size) {
- if (indexerr == NULL)
- indexerr = PyString_FromString(
- "list index out of range");
- PyErr_SetObject(PyExc_IndexError, indexerr);
- return NULL;
- }
+
+if (list_check_index((PyListObject *)op, "list", i) == -1)
+return NULL;
return ((PyListObject *)op) -> ob_item[i];
}
@@ -161,12 +168,10 @@
PyErr_BadInternalCall();
return -1;
}
- if (i < 0 || i >= ((PyListObject *)op) -> ob_size) {
- Py_XDECREF(newitem);
- PyErr_SetString(PyExc_IndexError,
- "list assignment index out of range");
- return -1;
- }
+if (list_check_index((PyListObject *)op, "list", i) == -1) {
+Py_XDECREF(newitem);
+return -1;
+}
p = ((PyListObject *)op) -> ob_item + i;
olditem = *p;
*p = newitem;
@@ -387,15 +392,10 @@
static PyObject *
list_item(PyListObject *a, Py_ssize_t i)
{
- if (i < 0 || i >= a->ob_size) {
- if (indexerr == NULL)
- indexerr = PyString_FromString(
- "list index out of range");
- PyErr_SetObject(PyExc_IndexError, indexerr);
- return NULL;
- }
- Py_INCREF(a->ob_item[i]);
- return a->ob_item[i];
+if (list_check_index(a, "list", i) == -1)
+return NULL;
+Py_INCREF(a->ob_item[i]);
+return a->ob_item[i];
}
static PyObject *
@@ -692,11 +692,9 @@
list_ass_item(PyListObject *a, Py_ssize_t i, PyObject *v)
{
PyObject *old_value;
- if (i < 0 || i >= a->ob_size) {
- PyErr_SetString(PyExc_IndexError,
- "list assignment index out of range");
- return -1;
- }
+if (list_check_index(a, "list", i) == -1)
+return -1;
+
if (v == NULL)
return list_ass_slice(a, i, i+1, v);
Py_INCREF(v);
And the result:
L = range(10)
L[44]
Traceback (most recent call last):
File "", line 1, in
IndexError: list index 44 not in range(10)
L[11] = 77
Traceback (most recent call last):
File "", line 1, in
IndexError: list index 11 not in range(10)
... And it was damn easy.
--
mvh Björn
Index: Objects/listobject.c
===
--- Objects/listobject.c (revision 52915)
+++ Objects/listobject.c (arbetskopia)
@@ -131,7 +131,18 @@
return ((PyListObject *)op) -> ob_size;
}
-static PyObject *indexerr = NULL;
+static int
+list_check_index(PyListObject *o, const char *ob_name, int i)
+{
+if (i < 0 || i >= o->ob_size) {
+const char fmt[] = "%s index %d not in range(%d)";
+char buf[256];
+snprintf(buf, 256, fmt, ob_name, i, o->ob_size);
+PyErr_SetString(PyExc_IndexError, buf);
+return -1;
+}
+return 0;
+}
PyObject *
PyList_GetItem(PyObject *op, Py_ssize_t i)
@@ -140,13 +151,9 @@
PyErr_BadInternalCall();
return NULL;
}
- if (i < 0 || i >= ((PyListObject *)op) -> ob_size) {
- if (indexerr == NULL)
- indexerr = PyString_FromString(
-"list index out of range");
- PyErr_SetObject(PyExc_IndexError, indexerr);
- return NULL;
- }
+
+if (list_check_index((PyListObject *)op, "list", i) == -1)
+return NULL;
return ((PyListObject *)op) -> ob_item[i];
}
@@ -161,12 +168,10 @@
PyErr_BadInternalCall();
Re: Why not just show the out-of-range index?
On 12/4/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > BJörn Lindqvist wrote: > > >> > Sorry I haven't thought this through 100% > >> > >> obviously not. > > > > And you're not helping. > > I've already explained why something like PyObject_IsIndexOutOfBounds > cannot work earlier in this thread. Maybe so, but that doesn't mean that it is not possible to make the IndexError messages Pythons sequence objects throws better. You don't need to change the semantics of x[i]. -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: Why not just show the out-of-range index?
On 12/4/06, Terry Reedy <[EMAIL PROTECTED]> wrote: > While Fredrik's reply is a bit short, as is sometimes his habit, > here are some things that appear to me to not have been thought through > enough: > 1. some negative indexes are legal. That could be fixed. Just substract len(L) from i if i < 0. > 2. replacing short inline code with a function call on *every* index lookup > will slow down the interpreter a bit. I can't notice any difference. On my machine, Python is compiled with -O3 which probably inlines the function. > 3. will the same check code work for even all built-in sequences? Atleast for tuple, string and list, they can be downcasted to PyVarObjects. So yes. > 4. how does index checking fit in with slice checking? When does slicing throw IndexErrors? > with both the knowledge and motivation to do so. But insulting such people > is not helpful. Agreed. I don't think insulting people is helpful at all, but I don't think "Russ" is the only one in this thread that should learn that. -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
> I think that people who know more languages and more about programming will > be much more inclined to use Lisp than Python. Look at the contents of the > newsgroups for example, c.l.l has a thread on memoization whereas c.l.p has > a thread about wrestling oiled pigs. Practicality beats purity. :) -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
> > Maybe so. But I've only ever appreciated its functional aspects. I > > wouldn't choose Lisp or its derivatives for OO related tasks even if > > I'm high. > > But CLOS is the best OO there is. The OMG said so. It can do anything > any other OO can do. Why /specifically/ would you not use it? This type Specifically it does not have name spaces. Therefore it is fundamentally flawed and cannot be used as a serious object-oriented tool for developing complex applications. However, I'll give you that it is pretty nice for pet-projects and educational purposes (counting parenthesises). But for some, that is more than enough. -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: trouble getting google through urllib
> > > Google doesnt like Python scripts. You will need to pretend to be a > > > browser by setting the user-agent string in the HTTP header. > > > > > and possibly also run the risk of having your system blocked by Google if > > they figure out you are lying to them? > > It is possible. I wrote a 'googlewhack' (remember them?) script a while > ago, which pretty much downloaded as many google pages as my adsl could > handle. And they didn't punish me for it. Although apparently they do > issue short term bans on IP's that abuse their service. For Google, that load must be piss in the ocean. I bet for Google to even notice the abuse, it must be something really, really severe. -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: python-hosting.com projects: dead?
On 12/20/06, greg <[EMAIL PROTECTED]> wrote: > Richard Jones wrote: > > > Actually, to clarify the DEFAULT configuration for Trac is to leave it open > > to spam. > > That sounds like a really bad choice of default. > > A bit like the way Windows comes with all the > "let anyone in the world send me a virus" > options turned on... Not really, Trac's default to be open is great for intranet installations. It is Webfactions own fault that they haven't been able to shield themself from spam by changing Trac's default to something more restrictive. -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Generating all permutations from a regexp
With regexps you can search for strings matching it. For example,
given the regexp: "foobar\d\d\d". "foobar123" would match. I want to
do the reverse, from a regexp generate all strings that could match
it.
The regexp: "[A-Z]{3}\d{3}" should generate the strings "AAA000",
"AAA001", "AAA002" ... "AAB000", "AAB001" ... "ZZZ999".
Is this possible to do? Obviously, for some regexps the set of matches
is unbounded (a list of everything that matches "*" would be very
unpractical), but how would you do it for simple regexps like the one
above?
--
mvh Björn
--
http://mail.python.org/mailman/listinfo/python-list
Re: are there Tomboy and F-Spot equivalents?
On 12/21/06, Tshepang Lekhonkhobe <[EMAIL PROTECTED]> wrote: > Hi, > I dislike installing the entire Mono stack simply to take notes and > manage photos, and am totally biased towards Python. At least for > search I got Tracker, instead of Beagle. > Are there equvalents applications for Tomboy and F-Spot which are > written in Python. No -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: Getting the name of an assignment
On 23 Dec 2006 14:38:19 -0800, Adam Atlas <[EMAIL PROTECTED]> wrote:
> Is it possible for an object, in its __init__ method, to find out if it
> is being assigned to a variable, and if so, what that variable's name
> is? I can think of some potentially ugly ways of finding out using
> sys._getframe, but if possible I'd prefer something less exotic.
> (Basically I have a class whose instances, upon being created, need a
> 'name' property, and if it's being assigned to a variable immediately,
> that variable's name would be the best value of 'name'; to make the
> code cleaner and less redundant, it would be best if it knew its own
> name upon creation, just like functions and classes do, without the
> code having to pass it its own name as a string.)
I guess you mean something like this:
>>> olle = Person()
>>> olle.name
"olle"
Instead of:
>>> olle = Person("olle")
>>> olle.name
"olle"
It is not possible without ugly hacks. What you could use instead is
some kind of registry approach:
reg = {}
class Person:
def __init__(self, name):
self.name = name
reg[name] = self
>>> Person("olle")
>>> reg["olle"].name
"olle"
I think there are thousand different ways you could solve it.
--
mvh Björn
--
http://mail.python.org/mailman/listinfo/python-list
Re: some OT: how to solve this kind of problem in our program?
On 12/24/06, oyster <[EMAIL PROTECTED]> wrote: > 1. first of all, what is the English jargon (Optimize? But I think > this is not a very good keyword :( )for this problem? So I can use it > to search on the internet The first problem is a magic square. The general term for all your problems are constraint satisfaction problems. > 2. is there any free/open lib for this? Yes, this for example: http://labix.org/python-constraint > 3. I know for some questions(case 1, case 2, and sudoku), we can use > bundles of "FOR...NEXT" loop to program. however I think it is clumsy > and inconvenient, especially when there is many vars Yes. I think it is also very much unoptimal. For solving problems such as magic squares and sudoku puzzles you want a recursive backtracking constraint solver. > case: > 1. choose x0~x9 from 1~9, and must use all of 1~9, let > x0/(10*x1+x2)+x3/(10*x4+x5)+x6/(10*x7+x8)=1/2 Using the linked to constraint solver, you could write something like this: p = Problem() # Ten variables named 0..9 all with values in the domain 0..9 p.addVariables(range(10), range(10)) p.addConstraint(AllDifferentConstraint(), range(10)) def eqConstraint(*x): t = x[0]/(10*x[1] + x[2]) + x[3]/(10 * x[4] + x[5]) + x[5](10 * x[7] + x[8]) # Convert to int to get rid of rounding errors t = int(t * 2) return t == 1 p.addConstraint(eqConstraint, range(10)) p.getSolutions() > 2. choose x0~x15 from 1~16, and must use all of 1~16, let > +-+-+-+-+ > | x0 | x1 | x2 | x3 | > +-+-+-+-+ > | x4 | x5 | x6 | x7 | > +-+-+-+-+ > | x8 | x9 | x10 | x11 | > +-+-+-+-+ > | x12 | x13 | x14 | x15 | > +-+-+-+-+ > > sum of every column =sum of of every row > = x0+x5+x10+x11 =x3+x6+x9+x12 Similar to above, just enter all the constraints and let the library do the hard work: def lineConstraint(*l): s1 = sum(l[:4]) s2 = sum(l[4:]) return s1 == s2 # For magic squares, recursive backtracking solves are the best p = Problem(RecursiveBacktrackingSolver()) p.addConstraint(AllDifferentConstraint()) p.addConstraint(lineConstraint, [0, 5, 10, 11, 3, 6, 9, 12]) ... add more constraints... p.getSolution() HTH -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: Generating all permutations from a regexp
On 12/22/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> BJörn Lindqvist wrote:
> > With regexps you can search for strings matching it. For example,
> > given the regexp: "foobar\d\d\d". "foobar123" would match. I want to
> > do the reverse, from a regexp generate all strings that could match
> > it.
> >
> > The regexp: "[A-Z]{3}\d{3}" should generate the strings "AAA000",
> > "AAA001", "AAA002" ... "AAB000", "AAB001" ... "ZZZ999".
> >
> > Is this possible to do? Obviously, for some regexps the set of matches
> > is unbounded (a list of everything that matches "*" would be very
> > unpractical), but how would you do it for simple regexps like the one
> > above?
>
> here's a start:
>
> http://mail.python.org/pipermail/python-list/2001-August/102739.html
Thankyou! Who would have known that there is a sre_parse module...
makes things quite a bit easier.
--
mvh Björn
--
http://mail.python.org/mailman/listinfo/python-list
Re: Generating all permutations from a regexp
With some help from the sre_parse module (and the Python Cookbook),
here is the completed module:
# -*- coding: utf-8 -*-
import itertools
from sre_constants import *
import sre_parse
import string
category_chars = {
CATEGORY_DIGIT : string.digits,
CATEGORY_SPACE : string.whitespace,
CATEGORY_WORD : string.digits + string.letters + '_'
}
def unique_extend(res_list, list):
for item in list:
if item not in res_list:
res_list.append(item)
def handle_any(val):
"""
This is different from normal regexp matching. It only matches
printable ASCII characters.
"""
return string.printable
def handle_branch((tok, val)):
all_opts = []
for toks in val:
opts = permute_toks(toks)
unique_extend(all_opts, opts)
return all_opts
def handle_category(val):
return list(category_chars[val])
def handle_in(val):
out = []
for tok, val in val:
out += handle_tok(tok, val)
return out
def handle_literal(val):
return [chr(val)]
def handle_max_repeat((min, max, val)):
"""
Handle a repeat token such as {x,y} or ?.
"""
subtok, subval = val[0]
if max > 5000:
# max is the number of cartesian join operations needed to be
# carried out. More than 5000 consumes way to much memory.
raise ValueError("To many repetitions requested (%d)" % max)
optlist = handle_tok(subtok, subval)
iterlist = []
for x in range(min, max + 1):
joined = join([optlist] * x)
iterlist.append(joined)
return (''.join(it) for it in itertools.chain(*iterlist))
def handle_range(val):
lo, hi = val
return (chr(x) for x in range(lo, hi + 1))
def handle_subpattern(val):
return list(permute_toks(val[1]))
def handle_tok(tok, val):
"""
Returns a list of strings of possible permutations for this regexp
token.
"""
handlers = {
ANY: handle_any,
BRANCH : handle_branch,
CATEGORY : handle_category,
LITERAL: handle_literal,
IN : handle_in,
MAX_REPEAT : handle_max_repeat,
RANGE : handle_range,
SUBPATTERN : handle_subpattern}
try:
return handlers[tok](val)
except KeyError, e:
fmt = "Unsupported regular expression construct: %s"
raise ValueError(fmt % tok)
def permute_toks(toks):
"""
Returns a generator of strings of possible permutations for this
regexp token list.
"""
lists = [handle_tok(tok, val) for tok, val in toks]
return (''.join(it) for it in join(lists))
def join(iterlist):
"""
Cartesian join as an iterator of the supplied sequences. Borrowed
from:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/302478
"""
def rloop(seqin, comb):
if seqin:
for item in seqin[0]:
newcomb = comb + [item]
for item in rloop(seqin[1:], newcomb):
yield item
else:
yield comb
return rloop(iterlist, [])
## PUBLIC API
def ipermute(p):
toks = [tok_n_val for tok_n_val in sre_parse.parse(p)]
return permute_toks(toks)
def permute(p):
return list(ipermute(p))
Used like this:
from permute import ipermute
for s in ipermute('[A-Z]\d'):
print s
Almost all regular expression constructs are supported except for '*'
(which in the Python sre_parse implementation matches 0 to 65535
times), '+' and '^'. Non-ASCII characters doesn't work, but I think
that is a limitation in the sre_parse module. It works by first
parsing the regexp to string sequences so that [A-Z] becomes ['A',
'B', ... 'Z'], \d becomes ['1', ... , '9']. Then a Cartesian join is
applied on all string sequences to get all possible permutations of
them all.
Suggestions for improvements very much appreciated.
--
mvh Björn
--
http://mail.python.org/mailman/listinfo/python-list
Re: Generating all permutations from a regexp
On 23 Dec 2006 04:23:09 -0800, Chris Johnson <[EMAIL PROTECTED]> wrote:
>
> BJörn Lindqvist wrote:
> > With regexps you can search for strings matching it. For example,
> > given the regexp: "foobar\d\d\d". "foobar123" would match. I want to
> > do the reverse, from a regexp generate all strings that could match
> > it.
> >
> > The regexp: "[A-Z]{3}\d{3}" should generate the strings "AAA000",
> > "AAA001", "AAA002" ... "AAB000", "AAB001" ... "ZZZ999".
> >
> > Is this possible to do? Obviously, for some regexps the set of matches
> > is unbounded (a list of everything that matches "*" would be very
> > unpractical), but how would you do it for simple regexps like the one
> > above?
>
> For a very small number of characters, it would be feasible. For any
> finite number of characters, it would be possible (though it wouldn't
> take much to take longer than the age of the universe). For reference,
> in your simple example, you have 17,576,000 matching strings.
>
> I'm curious as to why you would wish to do this. I certainly understand
> considering hard problems for their own sake, but when I formulate
> them, there's always some impetus that makes me say "Huh. Now I
> wonder..."
I have a thousand use cases in mind. For example:
1. Generate sentences for a bot:
ipermute("(I|You|He|She|It|They) do( not)? (dis)?like (you|him|her|me|they)"):
Generates many grammatically incorrect sentences but you get the point.
2. Generate URL:s to web resources:
The following should generate URL:s to all c.l.p digests from the mail archive:
def download_clp():
year_re = "(199\d|200[0-6])"
months = ["January",
"February",
"March",
"April",
"May",
"June",
"July",
"August",
"September",
"October",
"November",
"December"]
month_re = '(' + '|'.join(months) + ')'
fmt = "http://mail\.python\.org/pipermail/python-list/%s-%s\.txt";
url_re = fmt % (year_re, month_re)
for x in ipermute(url_re):
print "Downloading", x
code to download here
The same approach could be used to download all threads in a forum for
example, or all articles on Slashdot.
3. "Visualising" regular expressions. I think it would be easier to
write regular expressions if you could see what kind of data they
would match.
4. Port scanning:
ip_tuple = "(\d|[1-9]\d|1\d\d|2[0-4]\d|25[0-5])"
for x in ipermute("192\.168\." + "\.".join([ip_tuple] * 2)):
scan_ip(x)
--
mvh Björn
--
http://mail.python.org/mailman/listinfo/python-list
Re: keypressed() function
> I know that this probably does not exist in the Python library already > as a platform-independant abstraction (even though it probably could), > but then I would at least like solutions that works on Windows and on > Linux. http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/134892 But it is blocking. -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 3107 Function Annotations for review and comment
On 12/29/06, Tony Lownds <[EMAIL PROTECTED]> wrote: > Rationale > = > > Because Python's 2.x series lacks a standard way of annotating a > function's parameters and return values (e.g., with information about > what type a function's return value should be), a variety of tools > and libraries have appeared to fill this gap [#tailexamp]_. Some > utilise the decorators introduced in "PEP 318", while others parse a > function's docstring, looking for annotations there. > > This PEP aims to provide a single, standard way of specifying this > information, reducing the confusion caused by the wide variation in > mechanism and syntax that has existed until this point. I think this rationale is very lacking and to weak for such a big change to Python. I definitely like to see it expanded. The reference links to two small libraries implementing type checking using decorators and doc strings. None of which to seem to be very popular in the Python community. Surely, those two libraries *alone* can't be enough of a motivation for this? To me, it is far from self-evident what purpose function annotations would serve. I also wonder why a very obtrusive syntax addition is needed when it clearly is possible to annotate functions in today's Python. Why is syntax better than just adding a function annotation decorator to the standard library? @annotate(a = int, b = dict, c = int) def foo(a, b, c = 5): ... Are decorators to ugly? -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: Why less emphasis on private data?
On 6 Jan 2007 16:07:05 -0800, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Coming from a C++ / C# background, the lack of emphasis on private data > seems weird to me. I've often found wrapping private data useful to > prevent bugs and enforce error checking.. > > It appears to me (perhaps wrongly) that Python prefers to leave class > data public. What is the logic behind that choice? Google for "python for consenting adults" Or ask yourself the opposite question. Why does C++ and C# prefer more private data? It is given that emphasizing private data (encapsulation) leads to more internal complexity and more lines of code because you have to write getters and setters and stuff. With that in mind, why do you think that data encapsulation makes code less error prone? Can you prove it? Or do you have anecdotal evidence of where data encapsulation saved your ass? IMHO, that data hiding is good, is one of those ideas that have been repeated so much that virtually everyone thinks it is true. But Python proves that it isn't necessarily so. -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: itertools.groupby
On 27 May 2007 10:49:06 -0700, 7stud <[EMAIL PROTECTED]> wrote: > On May 27, 11:28 am, Steve Howell <[EMAIL PROTECTED]> wrote: > > The groupby method has its uses, but it's behavior is > > going to be very surprising to anybody that has used > > the "group by" syntax of SQL, because Python's groupby > > method will repeat groups if your data is not sorted, > > whereas SQL has the luxury of (knowing that it's) > > working with a finite data set, so it can provide the > > more convenient semantics. > > The groupby method has its uses > > I'd settle for a simple explanation of what it does in python. Here is another example: import itertools import random dierolls = sorted(random.randint(1, 6) for x in range(200)) for number, numbers in itertools.groupby(dierolls): number_count = len(list(numbers)) print number, "came up", number_count, "times." -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: Select one of 2 functions with the same name ?
On 6/10/07, Stef Mientki <[EMAIL PROTECTED]> wrote:
> I can realize it with a simple switch within each function,
> but that makes the code much less readable:
>
> def Some_Function():
>if simulation_level == 1:
> ... do things in a way
>elif simulation_level == 2:
> ... do things in another way
>elif simulation_level == 3:
> ... do things in yet another way
If you only have three levels, then that definitely is the best way to
solve the problem. If you have more, and if they may change, then use
a dispatch-dict:
def simulator_1():
print 'mooo'
...
simulators = {1 : simulartor_1, 2 : simulator_2, 3 : simulator_3}
def Some_Function():
simulators[simulation_level]()
--
mvh Björn
--
http://mail.python.org/mailman/listinfo/python-list
Re: a_list.count(a_callable) ?
On 6/15/07, Ping <[EMAIL PROTECTED]> wrote:
> >
> > sum(1 for i in a_list if a_callable(i))
> >
> > --
> > Carsten Haesehttp://informixdb.sourceforge.net
>
> This works nicely but not very intuitive or readable to me.
>
> First of all, the generator expression makes sense only to
> trained eyes. Secondly, using sum(1 ...) to mean count()
> isn't very intuitive either.
>
> I would still prefer an expression like a_list.count(a_callable),
> which is short, clean, and easy to understand. :) However,
> it does produce ambiguities if a_list is a list of callables.
> Should the count() method match values or check return values
> of a_callable? There are several possible designs but I'm not
> sure which is better.
Maybe you could extend count() analogous to how sort() works:
# L is a list of Person objects, each Person has a name attribute
L.sort(key = attrgetter("name"))
# How many olle are there?
print L.count("olle", key = attrgetter("name"))
# And index could be extended in the same way!
# Whom has id 1234?
print L.index(1234, key = attrgetter("id")).name
All of these could be solved by giving Person an __eq__() method, but
it fails when you need to search, sort or count on a different key.
--
mvh Björn
--
http://mail.python.org/mailman/listinfo/python-list
Re: A patch to support L.count(value, cmp=None, key=None)
> I patched Objects/listobject.c to support
> L.count(value, cmp=None, key=None).
> I tested it with the same script above by replacing slist
> with built-in list. It worked correctly with this small
> test. The patch is below (126 lines, I hope that's not
Great! If you want this change included in Python, you should post it
on SourceForge's patch tracker at
http://sourceforge.net/tracker/?group_id=5470&atid=305470. Optionally,
you can also ask if people like the patch on python-dev. But IMHO, the
odds of this patch being accepted are slim (borrowing from the example
in the last thread):
persons.count("olle", key = attergetter("name"))
is longer and just barely more readable than
sum(1 for x in persons if x.name == "olle"))
--
mvh Björn
--
http://mail.python.org/mailman/listinfo/python-list
Re: Q: listsort and dictsort - official equivalents?
> In python I must kick off a sort on the line before I start the
> iteration. (This does make sense because at the end of the day the sort
> has complete BEFORE the for loop can proceed - that is... until the day
> when python lists have a secondary index ;-).
>
> group_list=group_dict.keys()
> group_list.sort()
> for group in group_list: # do
> print group,group_dict[group]
> # done
>
> I am sure python has a more concise way of doing this, any hints?
for group in sorted(open("/etc/group")):
print group,
It's not true that the sort must complete (or that the whole file must
be read for that matter), Python has cool generators which makes the
above possible. You can even sort by the gid:
for group in sorted(open("/etc/group"), key = lambda x: int(x.split(':')[2])):
print group,
--
mvh Björn
--
http://mail.python.org/mailman/listinfo/python-list
Re: Q: listsort and dictsort - official equivalents?
On 6/20/07, Gabriel Genellina <[EMAIL PROTECTED]> wrote: > > It's not true that the sort must complete (or that the whole file must > > be read for that matter), Python has cool generators which makes the > > above possible. > > That's not possible, the input must be read completely before sorted() can > output anything. Suppose the minimum element is at the end - until you > read it, you can't output the very first sorted element. Doh! Yes of course. I always thought that sorted() returned a generator. Since Python's sort is based on merge sort, using a generator approach it should at least be theoretically possible to begin emitting the items before the sort operation completes. -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 3107 and stronger typing (note: probably a newbie question)
On 6/22/07, Eduardo EdCrypt O. Padoan <[EMAIL PROTECTED]> wrote: > Remember that pure CPython has no different "compile time" and > runtiime. But Psyco and ShedSkin could use the annotations the way > they want. . > def compile(source: "something compilable", >filename: "where the compilable thing comes from", >mode: "is this a single statement or a suite?"): I think the above would make an annotation-enhanced Psyco or ShedSkin very confused. -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: What is the preferred doc extraction tool?
On 7/9/07, Emin.shopper Martinian.shopper <[EMAIL PROTECTED]> wrote: > Dear Experts, > > What is the preferred doc extraction tool for python? It seems that there > are many very nice options (e.g., pydoc, epydoc, HappyDoc, and lots of > others), but what is the "standard" tool or at least what is the tool used > to generate the documentation for the python standard library? The tool is Latex plus a lot of utilities that help make the HTML output good looking. It doesn't even extract documentation from the source. The best tool is definitely epydoc. It produces very good looking javadoc-like html output by default, no annoying css setup needed. You can also produce pdfs with it which is very nice. -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: Can a low-level programmer learn OOP?
On 7/13/07, John Nagle <[EMAIL PROTECTED]> wrote: > You can sometimes get better performance in C++ than in C, because C++ > has "inline". Inline expansion happens before optimization, so you > can have abstractions that cost nothing. C99 has that too. > Python is a relatively easy language, easier than C++, Java, > or even Perl. It's quite forgiving. The main implementation, > CPython, is about 60x slower than C, though, so if you're trying > to implement, say, a rapidly changing digital oscilloscope display, > the result may be sluggish. But if the data for that oscilloscope comes from an external device connected via a serial port, execution speed won't matter. -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: While we're talking about annoyances
On 4/29/07, Steven D'Aprano <[EMAIL PROTECTED]> wrote: > To do that, I needed to generate an index table first. In the book > "Numerical Recipes in Pascal" by William Press et al there is a procedure > to generate an index table (46 lines of code) and one for a rank table > (five lines). 51 lines total. > In Python, my index function is four lines of code and my rank function is > five lines. I then wrote three more functions for verifying that my index > and rank tables were calculated correctly (17 more lines) and four more > lines to call doctest, giving a total of 30 lines of code. So 9 lines for Python, excluding tests. > I also have 93 lines of documentation, including doctests, or three > lines of documentation per line of code. Then, without documentation, Python is roughly 560% (51/9) as efficient as Pascal. But with documentation (assuming you need the same amount of documentation for the Python code as the Pascal code), (51 + 93)/(9 + 93) = 1.41 so only 141% as efficient as Pascal. I wonder what that means? Maybe Python the language is approaching the upper bound for how efficient an imperative programming language can be? On the other hand, there seem to be some progress that could be made to reduce the amount of work in writing documentation. Documentation in Esperanto instead of English maybe? -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: Is it possible to merge xrange and slice?
On 30 Apr 2007 11:02:19 -0700, Bas <[EMAIL PROTECTED]> wrote: > stupid question, but would it be possible to somehow merge xrange > (which is supposed to replace range in py3k) and slice? Both have very > similar start, stop and step arguments and both are lightweight > objects to indicate a range. But you can't do a[xrange(10,20)] and > 'for i in slice(10,20)'. The only difference is see is some behavior > with infinities (e.g. object[3:] gives a slice(3,maxint) inside > _getitem_ , but I think this should not be a large problem > (xrange(0,infinity) could just yield a generator that never stops). > > Which problems am I overlooking that prevent this? Novel idea but how would slice(3,-1) work? -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: Quote aware split
How is the code different from shlex.split? -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: Is PEP-8 a Code or More of a Guideline?
On 5/29/07, Eric S. Johansson <[EMAIL PROTECTED]> wrote: > A huge reason why this is important because the vast majority of software > developers who are injured fall off the economic ladder. They leave the > profession and had very few options for work that doesn't involve significant > handy is. The last time I looked at the numbers, in the US somewhere north of > 60,000 developers per year are injured. Some recover (kind of). Others, like > I I'm curious, where did you get that statistic? Assuming the US hosts no more than 6M developers, then 60,000 is >=1% which is an alarming amount. -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: Creating a distro of python... What would you include in it?
On 30 May 2007 08:25:48 -0700, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > I am creating a distro of Python to be licensed as GPL am > wondering, what would anyone suggest as to 3rd party modules being put > into it (non-commercial of course!)? I know I'd put MySQLdb into it at > the very least. Any suggestions? If your distro is to be GPL-licensed, does that mean that you want your components to be GPL too? If so, the number of components you can select is reduced drastically. I'd like a distro with a good IDE, GUI toolkit (PyGTK for example), Django and PyGame. Something you could point a newbie to and they would be able to create "real" applications with, without needing to download hundreds of dependencies. -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: decorators - more than just syntactic sugar
On 8/11/07, Helmut Jarausch <[EMAIL PROTECTED]> wrote: > How can I find out the predefined decorators? There are two in the standard library, @classmethod for declaring class methods and @staticmethod for declaring static methods. They are listed at the built ins page http://docs.python.org/dev/lib/built-in-funcs.html, unpedagogically not separated from ordinary functions. -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: decorators - more than just syntactic sugar
On 8/13/07, Bjoern Schliessmann <[EMAIL PROTECTED]> wrote: > BJörn Lindqvist wrote: > > > unpedagogically not separated from ordinary functions. > > Decorators _are_ ordinary functions. Remember the "syntactic sugar" > in this thread? Remember also "that syntactic sugar is important." Case in point, the OP did not think of looking at the built-in functions page. -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: advice about `correct' use of decorator
On 8/16/07, Gerardo Herzig <[EMAIL PROTECTED]> wrote: > @is_logued_in > def change_pass(): > bla > bla > > And so on for all the other functions who needs that the user is still > loged in. > > where obviosly the is_logued_in() function will determine if the dude is > still loged in, and THEN execute change_pass(). If the dude is not loged > in, change_pass() is NOT executed at all. Instead, it will be redirected > to the `login' screen. I think this is redundant use of a decorator. You can achieve the exact same effect by writing: def is_logued_in(): if not user.is_logged_in(): raise NotLoggedInError It costs you one more line, but reduces complexity. And if you are worried about that extra line you can put it in a function. -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: advice about `correct' use of decorator
On 8/17/07, Gerardo Herzig <[EMAIL PROTECTED]> wrote: > BJörn Lindqvist wrote: > >def is_logued_in(): > >if not user.is_logged_in(): > >raise NotLoggedInError > > > >It costs you one more line, but reduces complexity. And if you are > >worried about that extra line you can put it in a function. > > > As far as i know (by the way, AFAK is the shortcut?, and BTW means `by > the way'? ), decorators are not indispensable. I mean, all that you can > do with python, you can doit without decorators. And from my point of > view, this hides the complexity for the other developers of my group, hiding is not the same thing as reducing. By hiding the code behind a decorator, you are increasing the complexity by adding another layer that the programmer has to look through to see your control flow. > since all they have to do is add the @is_logged_in line at the top of > the cgi script, and not to worrie about exceptions, not even how the > decorator is implemented (i may log the error in some file). All they > have to know is that any abnormal situation will redirect to the `login' > screen. As I said, you can accomplish the exact same thing by calling a function from within the function that requires the user to be logged in. def change_pass(): check_user_logged_in() ... more stuff here... is less complex (and therefore preferable) than: @check_user_logged_in def change_pass(): ... more stuff here... An important principle in engineering is that you should always strive to make your design as simple as possible. If you have two equal designs, you should always choose the one that is simpler because simple things are easier to understand than complex things. -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: advice about `correct' use of decorator
On 8/22/07, Gabriel Genellina <[EMAIL PROTECTED]> wrote: > On 22 ago, 10:00, "BJörn Lindqvist" <[EMAIL PROTECTED]> wrote: > > As I said, you can accomplish the exact same thing by calling a > > function from within the function that requires the user to be logged > > in. > > > > def change_pass(): > > check_user_logged_in() > > ... more stuff here... > > > > is less complex (and therefore preferable) than: > > > > @check_user_logged_in > > def change_pass(): > > ... more stuff here... > > > > An important principle in engineering is that you should always strive > > to make your design as simple as possible. If you have two equal > > designs, you should always choose the one that is simpler because > > simple things are easier to understand than complex things. > > I don't see the complexity in this case - both are a single line of > code. Any internal complexity is hidden by the language. In fact, I "Hiding" doesn't reduce complexity, quite the opposite. > consider the decorated function simpler than the other: its body > represents exactly what the function does, without any distracting > precondition calls. Think about how the decorator is implemented. It is a high order function, taking a function and returning a new function. Something like this: def check_user_logged_in(func): def f(*args, **kwargs): if global_state.the_user.is_logged_in: return func(*args, **kwargs) return show_login_page() return f @check_user_logged_in def change_pass(): ... more stuff here... or: def check_user_logged_in(): return global_state.the_user.is_logged_in def change_pass(): if not check_user_logged_in(): return show_login_page() ... more stuff here ... or even: def change_pass(): if not global_state.the_user.is_logged_in: return show_login_page() ... more stuff here ... > The decorator has some advantages: can have syntax support on your > editor, can perform some registering/logging, it's even easier to > quickly check visually if it's here. The decorator has just as many disadvantages. For example, what if you want to redirect back to the change_pass page once the user has pressed the Login button on the login_page? Or if you want to show different login pages depending on user properties? How much control flow do you really want to "hide" in your decorator? -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: advice about `correct' use of decorator
On 8/24/07, Gabriel Genellina <[EMAIL PROTECTED]> wrote: > En Thu, 23 Aug 2007 09:20:21 -0300, BJörn Lindqvist <[EMAIL PROTECTED]> > escribi�: > > > def check_user_logged_in(func): > > def f(*args, **kwargs): > > if global_state.the_user.is_logged_in: > > return func(*args, **kwargs) > > return show_login_page() > > return f > > I think there is a semantic problem, perhaps we are not talking > about the same thing. I'm considering the software complexity AS > PERCEIVED BY THE PROGRAMMER, looking at the interactions between a > program and a programmer who is working on some task; some people > would say "cognitive complexity" to make it clear. There is no semantic problem. You are just mistaken in your belief that the complexity that the user of the decorator has to deal with is different from the complexity in implementing the decorator. > Which API is more complex: one in which you can play a movie with > just a single call like PlayMovie(Title), or one on which you must > call a zillion functions to firtly initialize the stream format, > configure the display, disable undesired user interfase elements, > locate the movie file, load it in chunks, etc.? The first one is > certainly much simpler to use (simpler = less complex), and maybe > internally it calls the same functions as the second one, but nobody > cares. "nobody cares" is your guess. I'd bet that the caller of the PlayMovie function cares a lot: Is the movie played full screened? Which encodings are supported? Can you set the title of the movie window? Is streaming supported? Does it even work on windows? Which URI schemes does it support? And so on and so on. That is why no video decoding API:s have a PlayMovie(Title) function and why I haven't seen a single 3d engine with a MakeReallyCoolDoomCloneFPSGame() function. "hiding details" only works if the client programmer really doesn't care about the details. > Back to your example, the fact that a decorator builds a higher order > function, does NOT make it more complex - because the programmer does not > see that. In fact, hiding the details makes it simpler. Yes, the programmer does see that. The example decorator I posted requires about a zillion preconditions to work correctly and will fail in weird ways when those preconditions are not satisfied. The programmer is interested in the crazy failures he or she will experience. I dare you to try and implementing the code both as a decorator and as a function, then write the unit tests and documentation. The complexity of those three items together (implementation + tests + documentation) will be much higher for the decorator choice because the complexity of the decorator implementation is a bit higher than using a plain old function. Note also that it is extremely rare to see well-documented or well-tested code, which means that the programmer WILL have to analyze the implementation which means that implementation complexity matters a lot. -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: list index()
On 8/30/07, Carsten Haese <[EMAIL PROTECTED]> wrote: > Is the Pythonic way > > try: > i = somelist.index(thing) > # Do something with i > except IndexError: > # Do something if thing not found That is not the Pythonic way. "# Do something with i" might also raise an IndexError and they you are screwed. The Pythonic way is something like: try: i = somelist.index(thing) except IndexError: print "Oh noes!" else: # Do the thing with i And for many cases this actually is worse/less readable than the alternative would have been if list.index() returned -1. -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
[ANN] GtkImageView 1.5.0 and PyGtkImageView 1.0.0 -- Image viewer widget for GTK
I'm pleased to finally announce GtkImageView 1.5.0. I'm even more
pleased to ALSO announce PyGtkImageView 1.0.0:
Description
---
GtkImageView is a simple image viewer widget for GTK+. Similar to the
image viewer panes in gThumb or Eye of Gnome. It makes writing image
viewing and editing applications easy. Among its features are:
* Mouse and keyboard zooming.
* Scrolling and dragging.
* Adjustable interpolation.
* Fullscreen mode.
* GIF animation support.
* Ability to make selections.
* Extensible using a tool system.
PyGtkImageView is the Python bindings for the same thing.
GtkImageView Download
-
Subversion: svn co http://publicsvn.bjourne.webfactional.com/gtkimageview
Tarball:
http://trac.bjourne.webfactional.com/attachment/wiki/WikiStart/gtkimageview-1.5.0.tar.gz
API doc:
http://trac.bjourne.webfactional.com/chrome/common/gtkimageview-docs/
PyGtkImageView Download
---
Subversion: svn co http://publicsvn.bjourne.webfactional.com/pygtkimageview
Tarball:
http://trac.bjourne.webfactional.com/attachment/wiki/WikiStart/pygtkimageview-1.0.0.tar.gz
API doc:
http://trac.bjourne.webfactional.com/chrome/common/pygtkimageview-docs/
PDF:
http://trac.bjourne.webfactional.com/attachment/wiki/WikiStart/pygtkimageview-1.0.0-api.pdf
Project website: http://trac.bjourne.webfactional.com
Examples
Here is the canonical example for using the widget::
#include
#include
...
GtkWidget *view = gtk_image_view_new ();
GtkWidget *scroll = gtk_image_scroll_win_new (GTK_IMAGE_VIEW (view));
/* Where "box" is a GtkBox already part of your layout. */
gtk_box_pack_start (GTK_BOX (box), scroll, TRUE, TRUE, 0);
GdkPixbuf *pixbuf = gdk_pixbuf_new_from_file ("someimage.png", NULL);
gtk_image_view_set_pixbuf (GTK_IMAGE_VIEW (view), pixbuf, TRUE);
Same thing using PyGtkImageView::
import gtk
import gtk.gdk
import gtkimageview
view = gtkimageview.ImageView()
scroll = gtkimageview.ImageScrollWin(view)
# Where "box" is a gtk.Box already part of your layout.
box.pack_start(scroll)
pixbuf = gtk.gdk.pixbuf_new_from_file("someimage.png")
view.set_pixbuf(pixbuf)
Future
--
* Perl bindings.
* Gtk# bindings.
* Haskell bindings.
--
mvh Björn
--
http://mail.python.org/mailman/listinfo/python-list
Re: newbie: self.member syntax seems /really/ annoying
On 9/12/07, Dave Hansen <[EMAIL PROTECTED]> wrote: > The name "self" is just a convention. You can give it any name you > wish. Using "s" is common. Not it's not common. And the name "self" is a convention codified in PEP8 which you shouldn't violate. And I agree with the OP that the convention is really annoying. self.rect.width = self.foo(self.rect.x + self.rect.y) * self.boo() is much less concise than s.rect.width = s.foo(s.rect.x + s.rect.y) * s.boo() -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: Interface Implementation in Python
On 5 Mar 2007 16:25:03 -0800, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Hi, > > I would like to know the interface concept in Python.How the > Interface is defined and implemented in Python?. > > How to access the interface fromn Client? You have a class with methods and data. You write many unit tests for that class which defines the behaviour of your interface. Make sure your class passes all those tests. When you are done, not only does your unit tests specify an interface, you also have a concrete class that implements that interface. Now replace the original class with another class. If that class also passes all your tests, then you can conclude that it also implements the same interface. -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: 2 new comment-like characters in Python to aid development?
On 9 Mar 2007 02:31:14 -0800, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Thanks for the thoughts. > > > This could be implemented without new syntax: just make your editor > > recognize some special comments, and apply the highlighting to the > > following block. By example, > > > > # XXX Remove this when FuruFaifa is fixed to always provide > > # XXX the names in the same order > > names.sort() > > names.reverse() > > Yes I recognise that we can use existing comments for this purpose, > and if I was suitably gifted I guess I could try to make the IDE > recognise these 'special comments', and maybe even work out what block > they're meant to apply to. Of course I'll still argue that the WIP > character would be a more elegant, speedy and versatile alternative. But you are overloading the ? character for a purpose which it totally was not meant for. What the character means really depends on what person you are asking. To me, it means that what precedes it is something someone or something does not know and wants to know the answer to. To me, it really does not mean that what follows it is work in progress. Even if I could intuitively tell that a question mark represents a work in progress, that information is not very useful. Similarly to the "under construction" animated gifs that were popular on the web in the mid 90-ties, the symbol does not convey any useful information. WHY is it a work in progress? Is there something wrong with it? ?def foobar(): do stuff The question mark does not leave me any the wiser. Now if you replace that question mark with a comment: # foobar() is buggy because it throws weird exceptions when x = 42. def foobar(): do stuff That gives me some useful information. -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: Grep Equivalent for Python
> I come from a shell/perl background and have just to learn python. To
> start with, I'm trying to obtain system information from a Linux
> server using the /proc FS. For example, in order to obtain the amount
> of physical memory on the server, I would do the following in shell:
>
> grep ^MemTotal /proc/meminfo | awk '{print $2}'
>
> That would get me the exact number that I need. Now, I'm trying to do
> this in python. Here is where I have gotten so far:
>
> memFile = open('/proc/meminfo')
> for line in memFile.readlines():
> print re.search('MemTotal', line)
> memFile.close()
import sys
sys.stdout.write(L.split()[1] + '\n' for L in open('/proc/meminfo') if
L.startswith('MemTotal'))
--
mvh Björn
--
http://mail.python.org/mailman/listinfo/python-list
Re: When is List Comprehension inappropriate?
On 19 Mar 2007 07:41:59 -0700, Ben <[EMAIL PROTECTED]> wrote: > I have recently learned how list comprehension works and am finding it > extremely cool. I am worried, however, that I may be stuffing it into > places that it does not belong. > > What's the most "pythony" way to do this: > > even = [] > for x in range(0,width,2): > for y in range(0,height,2): > color = im.getpixel((x,y)) > even.append(((x,y), color)) > > versus list comprehension: > > even2 = [((x,y), im.getpixel((x,y))) for x in range(0,width,2) for y > in range(0,height,2)] I would definitely not use list comprehension in this case. While they may be faster, Psyco is great here. Also, if you have lots of 2d-loops like "for x in something: for y in something:", then it could be more beautiful to separate the iteration from the task: def iterimage(im, width, height, step = 1): for y in range(0, height, step): for x in range(0, width, step): yield (x, y), im.getpixel((x, y)) Then the list comprehension becomes a little more manageable: even2 = [(pos, col) for pos, col in iterimage(im, width, height, 2)] Although this must definitely be the slowest of all the different approaches. -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: An error of matrix inversion using NumPy
On 4 Apr 2007 06:15:18 -0700, lancered <[EMAIL PROTECTED]> wrote: > During the calculation, I noticed an apparent error of > inverion of a 19x19 matrix. Denote this matrix as KK, U=KK^ -1, I > found the product of U and KK is not equivalent to unit matrix! This > apparently violate the definition of inversion. The inversion is > through the function linalg.inv(). Could it have something to do with floating point accuracy? >>> r = matrix([[random.random() * for x in range(19)] for y in range(19)]) >>> allclose(linalg.inv(r) * r, identity(19)) True >So, can you tell me what goes wrong? Is this a bug in > Numpy.linalg? How to deal with this situation? If you need, I can > post the matrix I used below, but it is so long,so not at the moment. Please post it. -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: Easy question: More items in a For loop?
> Here is some sample tuna:
> ['[7:55pm] My teachings goes back to the last iceage.\r\n',
> '[7:55pm] <%Zack> ahh now it does\r\n', '[7:55pm] <%Zack> ok\r\n',
> '[7:55pm] Or it is down just for you.\r\n', '[7:55pm] <@FC3>
> which one? that -12000 ice age or the one before\r\n', '[7:55pm]
> the earliest..\r\n', '[7:56pm] so.. 12000 quite long..\r
> \n', '[7:56pm] <@FC3> the one created by the meteor then\r\n',
> '[7:57pm] did not know that.. this is just a new teory I am
> folding.\r\n', '[7:57pm] * P0ke test test test\r\n']
You use the split method:
for j in tuna:
time, text = j.split(' ', 1)
if text.startswith('<%'):
print 'Will be yellow'
elif text.startswith('<@'):
print 'Will be pink'
elif text.startswith('*'):
print 'Will be dark pink'
First each line in tuna is looped through. Then you split the line
into two pieces so that it becomes easier to manage. Then you just
check if the line begins with the searched after pattern. If it does,
you color it appropriately.
--
mvh Björn
--
http://mail.python.org/mailman/listinfo/python-list
Re: tuples, index method, Python's design
On 4/10/07, Carsten Haese <[EMAIL PROTECTED]> wrote: > i = p.index(current_player) > opponents = p[:i-1] + p[i+1:] > > An alternative is this: > > opponents = tuple(x for x in p if x is not current_player) > > You may disagree, but in my opinion, the alternative is better because > it is a more natural translation of the concept that the opponents of > the current player are all players that are not the current player. Your alternative is wrong because it wont raise ValueError if current_player is not present in the tuple. Please revise your "solution." -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: tuples, index method, Python's design
On 4/10/07, Steve Holden <[EMAIL PROTECTED]> wrote: > Paul Boddie wrote: > > On 10 Apr, 11:48, Antoon Pardon <[EMAIL PROTECTED]> wrote: > >> On 2007-04-10, Duncan Booth <[EMAIL PROTECTED]> wrote: > >> > >>> There is a cost to every new language feature: it has to be implemented, > >>> documented, maintained, and above all learned by the users. Good design > >>> involves, in part, not adding to these burdens except where there is a > >>> benefit at least equal to the cost. > >> So what is the easiest to learn: "All sequences have an index method" or > >> "Such and so sequences have an index method and others don't" > > > > I think this observation leads to insights both at the end-user level > > and at the implementer level. Tuples and lists are sequences; the > > index method can be defined generically for all sequences; adding such > > a method to the tuple type can be done with barely any changes to the > > implementation taken from the list type. This leads to the observation > > that a generic index method (defined as a function in the > > implementation) could be made to work with both lists and tuples, and > > that various other methods might also be defined similarly, although > > things like append, extend and other mutating methods wouldn't be > > appropriate for a tuple. > > > A generic definition of index would be tricky, though, if you wanted to > include strings as sequences. In that case you aren't testing for the > presence of a single element but a sub-sequence - I think this change > was introduced in 2.4 to allow checks like > >"men" in "three good men" > > to succeed where formerly only single characters could be checked for. > One might perversely allow extension to lists and tuples to allow > >[3, 4] in [1, 2, 3, 4, 5, 6] > > to succeed, but that's forcing the use case beyond normal limits. The > point I am trying to make is that circumstances alter cases, and that we > can't always rely on our intuition to determine how specific methods > work, let alone whether they are available. I'd love to have that! There are at least one million use cases for finding a sequence in a sequence and implementing it yourself is non-trivial. Plus then both list and tuple's index methods would work *exactly* like string's. It would be easier to document and more useful. A big win. > Indeed the syntax is deliberately "crippled" - Guido's reasoning being, > I believe, that if it were too easy and natural to use then people would > use it inappropriately and too frequently. There are no appropriate use cases for that feature. Maybe not for tuple.index either, but increasing consistency and being able to say "ALL sequences have an index method that works like THIS" would be a big win. Unfortunately, it really is the string type that screws up the symmetry. -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: tuples, index method, Python's design
On 4/10/07, Carsten Haese <[EMAIL PROTECTED]> wrote: > > > opponents = tuple(x for x in p if x is not current_player) > > > > > Your alternative is wrong because it wont raise ValueError if > > current_player is not present in the tuple. Please revise your > > "solution." > > You have a point. Here is my revised solution: > > assert current_player in p > opponents = tuple(x for x in p if x is not current_player) > > The added advantage is that AssertionError is better than IndexError for > conveying that a severe program bug has occurred. Assertions are not checked when you run scripts with -O. Furthermore, changing the exception type and the message it produces, is quite a big deviation from list.index. -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: tuples, index method, Python's design
> > while not game_has_ended: > > for current_player in p: > > player_does_something(current_player) > > > > I'm curious why someone would even consider using a tuple in this case > regardless. I think that much of the desire for tuple.index is because > people use a tuple where they could have a list, but either a) some > vestige of B&D language programming comes out and they want to make Maybe someone had to much alcohol when they were coding? Maybe they don't know better? Maybe they thought that an index method on a sequence made sense? Who are you to spoil their fun? Could it be that YOU are the B&D person? -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Feature Request: Add the "using" keyword which works like "with" in Visual Basic
Your idea isn't new and has already been discussed lots of time before. It was once planned to be implemented in py3k, but no longer is. One of the problems is that with a "using" statement, you always have to decide whether your code repeats some prefix enough times to use a "using" statement. Should you write: self.quit.action = self.bar self.quit.name = "End it" or should it be: using self.quit: .action = self.bar .name = "End it" ? Not having to bother with petty things like that is an advantage. Javascript has with-statements that are equivalent to your using-statements but from what I've seen most programmers avoid them. They don't increase readability one bit. You already can emulate the using statement like this: def using(obj, **kw): for key, val in kw.items(): setattr(obj, key, val) using(self.quit, action = self.bar, name = "End it") But I have never seen anyone do that, which I think, is a sign that nobody wants the feature. -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Feature Request: Add the "using" keyword which works like "with" in Visual Basic
On 14 Apr 2007 07:24:32 -0700, jamadagni <[EMAIL PROTECTED]> wrote: > > You already can emulate the using statement like this: > > You can emulate only assignments like this. How would you emulate > function calls, like the ones in my example? You can't, of course. But using the with statement: using self.q: .doit() becomes: with self.quit as q: q.doit() :) -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Feature Request: Add the "using" keyword which works like "with" in Visual Basic
On 4/14/07, BJörn Lindqvist <[EMAIL PROTECTED]> wrote: > On 14 Apr 2007 07:24:32 -0700, jamadagni <[EMAIL PROTECTED]> wrote: > > > You already can emulate the using statement like this: > > > > You can emulate only assignments like this. How would you emulate > > function calls, like the ones in my example? > > You can't, of course. But using the with statement: > > using self.q: > .doit() > > becomes: > > with self.quit as q: > q.doit() Er.. I guess there are some details you need to work out for that. But in principle, it works fine. -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: function with list argument defaulting to [] - what's going on here???
> This comes up so often that I wonder whether Python should issue a warning
> when it sees [] or {} as a default argument.
>
>
> What do people think? A misuse or good use of warnings?
I think Python should reevaluate the default values.
--
mvh Björn
--
http://mail.python.org/mailman/listinfo/python-list
Re: is laziness a programer's virtue?
On 4/17/07, Mirco Wahab <[EMAIL PROTECTED]> wrote: > The reason why I answered your posting at all (besides > seeing your x-post going into 5 ng's) is your mentioning > of 'God'. According to christian tradition (which is > somehow on topic in a Perl group) it is exactly the > case of Jesus (imho), who was (in his context) the > "/Do you really want to look like a dolt in public/" > man par excellance. Socrates also comes into the mind ;-) Fits George W. Bush too. -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: Needless copying in iterations?
On 9/16/07, Steven D'Aprano <[EMAIL PROTECTED]> wrote: > Maybe I'm being unfair, but it seems to me that the attitude is similar: > 'there's no point optimizing the common case of printing (say) ints > stored in a list, Just In Case the programmer wants the incredibly rare > case of setting sys.stdout to some wacky object that modifies the list > he's iterating over. It could happen.' Indeed, there is no point in optimizing printing of lists as IO is orders of magnitudes slower than Python. But psyco probably would make a best effort attempt. -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: Try this
On 9/16/07, GeorgeRXZ <[EMAIL PROTECTED]> wrote: > Well you are speed That's an awesome party trick! But before I mail this to everyone at the office, must have a better sentence. Well you are speed is to gibberish. Something microsoft+evil... hm.. -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
