Re: A Moronicity of Guido van Rossum
Delaney, Timothy (Tim) wrote: > You have to admit though, he's remarkably good at getting past > Spambayes. Despite classifying *every* Xah Lee post as spam, he still > manages to get most of his posts classified as 0% or 1% spam. Hmm, perhaps he's using steganography. Maybe the emails actually contain an encoded message for an anonymous recipient, and he writes stuff designed to get past filters. If I were a spy, I might do the same thing... but I'd use language less likely to get me booted from the list. ;-) Shane -- http://mail.python.org/mailman/listinfo/python-list
How to get listed on planet.python.org
I've been writing Python-related articles on my weblog, and I thought planet.python.org might be interested in including them. Does anyone know how to submit a feed to the aggregator? http://hathawaymix.org/Weblog/rss20.xml?categories:list=Python Shane -- http://mail.python.org/mailman/listinfo/python-list
Re: PythonMagick on Windows
Adam Endicott wrote: > Claudio Grondi wrote: > >>Why is PIL *(Python Image Library) not suitable to do the graphics? >> >>http://www.pythonware.com/products/pil/ >> >>Claudio > > > I am using PIL for some other things, but what I need ImageMagick for > is to convert a PDF into a series of jpegs (one per page). Its the only > tool I've found to do this at a good enough resolution. FWIW: I tried PythonMagick for a while, but soon found that large or complex images caused it to consume excessive memory and sometimes crash, taking my application with it. I switched to the command line interface to isolate my application from problems in Graphics/ImageMagick. Everything ended up much more robust that way, and the time cost is small--it's on the order of milliseconds. Shane -- http://mail.python.org/mailman/listinfo/python-list
Proposal: Inline Import
Here's a heretical idea.
I'd like a way to import modules at the point where I need the
functionality, rather than remember to import ahead of time. This might
eliminate a step in my coding process. Currently, my process is I
change code and later scan my changes to make matching changes to the
import statements. The scan step is error prone and time consuming.
By importing inline, I'd be able to change code without the extra scan step.
Furthermore, I propose that the syntax for importing inline should be an
expression containing a dot followed by an optionally dotted name. For
example:
name_expr = .re.compile('[a-zA-Z]+')
The expression on the right causes "re.compile" to be imported before
calling the compile function. It is similar to:
from re import compile as __hidden_re_compile
name_expr = __hidden_re_compile('[a-zA-Z]+')
The example expression can be present in any module, regardless of
whether the module imports the "re" module or assigns a different
meaning to the names "re" or "compile".
I also propose that inline import expressions should have no effect on
local or global namespaces, nor should inline import be affected by
local or global namespaces. If users want to affect a namespace, they
must do so with additional syntax that explicitly assigns a name, such as:
compile = .re.compile
In the interest of catching errors early, it would be useful for the
Python parser to produce byte code that performs the actual import upon
loading modules containing inline import expressions. This would catch
misspelled module names early. If the module also caches the imported
names in a dictionary, there would be no speed penalty for importing
inline rather than importing at the top of the module.
I believe this could help many aspects of the language:
- The coding workflow will improve, as I mentioned.
- Code will become more self-contained. Self-contained code is easier
to move around or post as a recipe.
- There will be less desire for new builtins, since modules will be just
as accessible as builtins.
Thoughts?
Shane
--
http://mail.python.org/mailman/listinfo/python-list
Re: Proposal: Inline Import
Benji York wrote: > Why not: 1) jump to the top of the file when you need to do an import > (1G in Vim), 2) add the import, 3) jump back to where you were (Ctrl-o > in Vim) and keep coding. This isn't Vim specific, I suspect all decent > editors have similar capabilities (I know Emacs does). Thus eliminating > the unpleasant scan step. That's something the computer should do for me. It's busywork. Eclipse practically eliminates this busywork when I'm writing Java code: if I autocomplete a name, it also quietly adds the corresponding import statement. It also generates import statements when I copy/paste code. The structure of the Java language makes this relatively easy. In Python, it's harder to do autocompletion with the level of accuracy required for import statement generation. However, inline imports could eliminate the need to generate import statements. > Oh, and py.std does something similar to what you want: > http://codespeak.net/py/current/doc/misc.html#the-py-std-hook. Either form of inline import (py.std or my proposal) is a major idiomatic change. I can't be too much of a cowboy and start using idioms that are completely different from standard Python usage; my code would become unmaintainable. Thus a prerequisite for using inline import is broad approval. Shane -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal: Inline Import
Benji York wrote: > OK, good. You won't have to worry about that. :) You didn't give a reason for disliking it. Shane -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal: Inline Import
Xavier Morel wrote:
> Shane Hathaway wrote:
>
>>Thoughts?
>
>
> >>> import re; name_expr = re.compile('[a-zA-Z]+')
> >>> name_expr
> <_sre.SRE_Pattern object at 0x00F9D338>
> >>>
>
> the import statement can be called anywhere in the code, why would you
> add strange syntactic sugar that doesn't actually bring anything?
That syntax is verbose and avoided by most coders because of the speed
penalty. It doesn't replace the idiom of importing everything at the
top of the module.
What's really got me down is the level of effort required to move code
between modules. After I cut 100 lines from a 500 line module and paste
them to a different 500 line module, I have to examine every import in
both modules as well as examine the code I moved for missing imports.
And I still miss a lot of cases. My test suite catches a lot of the
mistakes, but it can't catch everything.
If I could just avoid import statements altogether, moving code would be
easier, regardless of extra typing. But I can't avoid import statements
unless there's a different way to import that lots of people like.
Shane
--
http://mail.python.org/mailman/listinfo/python-list
Re: Proposal: Inline Import
Mike Meyer wrote: > Shane Hathaway <[EMAIL PROTECTED]> writes: >>I'd like a way to import modules at the point where I need the >>functionality, rather than remember to import ahead of time. This >>might eliminate a step in my coding process. Currently, my process is >>I change code and later scan my changes to make matching changes to >>the import statements. The scan step is error prone and time >>consuming. By importing inline, I'd be able to change code without the >>extra scan step. > > > As others have pointed out, you can fix your process. That your > process doesn't work well with Python isn't a good reason for changing > Python. Do you have any ideas on how to improve the process of maintaining imports? Benji's suggestion of jumping around doesn't work for moving code and it interrupts my train of thought. Sprinkling the code with import statements causes a speed penalty and a lot of clutter. I'm actually quite surprised that others aren't bothered by the process of maintaining imports. Perhaps the group hasn't spent time in Eclipse to see what a relief it is to have imports managed for you. The difference isn't enough to make anyone jump ship to Java, but it's a real improvement. Shane -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal: Inline Import
Mike Meyer wrote: > Shane Hathaway <[EMAIL PROTECTED]> writes: >>That syntax is verbose and avoided by most coders because of the speed >>penalty. > > > What speed penalty? "import re" is a cheap operation, every time but > the first one in a program. I'm talking about using imports *everywhere*. The penalty would be appreciable. >>What's really got me down is the level of effort required to move code >>between modules. After I cut 100 lines from a 500 line module and >>paste them to a different 500 line module, I have to examine every >>import in both modules as well as examine the code I moved for missing >>imports. > > > Has it ever occured to you that if you're cutting and pasting 500 line > blocks, you're doing something fundamentally wrong? One of the points > of modules and OO is that you don't *have* to do things like > that. Cut-n-paste means you wind up with two copies of the code to > maintain, so that bug fixes in one will have to be propogated to the > other "by hand". Rather than spend time fixing what you broke by > yanking the code out of it's context, you'd be better off refactoring > the code so you could use it in context. That'll cut down on the > maintenance in the future, and may well mean that the next time > someone needs the code, it'll already be properly refactored so they > can use it directly, without having to cut-n-paste-n-fix it again. I said cut and paste, not copy and paste. I'm moving code, not copying it. Your advice is correct but doesn't apply to this problem. Shane -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal: Inline Import
Kent Johnson wrote: > Shane Hathaway wrote: >>I'm talking about using imports *everywhere*. The penalty would be >>appreciable. > > > Have you tried it? > > D:\Projects\CB>python -m timeit -s "import re" "import re" > 100 loops, best of 3: 1.36 usec per loop > > You need a lot of imports before 1 usec becomes "appreciable". Let me fully elaborate the heresy I'm suggesting: I am talking about inline imports on every other line of code. The obvious implementation would drop performance by a double digit percentage. > And your > proposal is doing the import anyway, just under the hood. How will you > avoid the same penalty? The more complex implementation, which I suggested in the first message, is to maintain a per-module dictionary of imported objects (distinct from the global namespace.) This would make inline imports have almost exactly the same runtime cost as a global namespace lookup. But never mind, this proposal is a distraction from the real issue. See the next thread I'm starting. Shane -- http://mail.python.org/mailman/listinfo/python-list
Managing import statements
Let's talk about the problem I really want help with. I brought up a proposal earlier, but it was only half serious. I realize Python is too sacred to accept such a heretical change. ;-) Here's the real problem: maintaining import statements when moving sizable blocks of code between modules is hairy and error prone. I move major code sections almost every day. I'm constantly restructuring the code to make it clearer and simpler, to minimize duplication, and to meet new requirements. To give you an idea of the size I'm talking about, just today I moved around 600 lines between about 8 modules, resulting in a 1400 line diff. It wasn't just cut-n-paste, either: nearly every line I moved needed adjustment to work in its new context. While moving and adjusting the code, I also adjusted the import statements. When I finished, I ran the test suite, and sure enough, I had missed some imports. While the test suite helps a lot, it's prohibitively difficult to cover all code in the test suite, and I had lingering doubts about the correctness of all those import statements. So I examined them some more and found a couple more mistakes. Altogether I estimate I spent 20% of my time just examining and fixing import statements, and who knows what other imports I missed. I'm surprised this problem isn't more familiar to the group. Perhaps some thought I was asking a newbie question. I'm definitely a newbie in the sum of human knowledge, but at least I've learned some tiny fraction of it that includes Python, DRY, test-first methodology, OOP, design patterns, XP, and other things that are commonly understood by this group. Let's move beyond that. I'm looking for ways to gain just a little more productivity, and improving the process of managing imports could be low-hanging fruit. So, how about PyDev? Does it generate import statements for you? I've never succeeded in configuring PyDev to perform autocompletion, but if someone can say it's worth the effort, I'd be willing to spend time debugging my PyDev configuration. How about PyLint / PyChecker? Can I configure one of them to tell me only about missing / extra imports? Last time I used one of those tools, it spewed excessively pedantic warnings. Should I reconsider? Is there a tool that simply scans each module and updates the import statements, subject to my approval? Maybe someone has worked on this, but I haven't found the right Google incantation to discover it. Shane -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal: Inline Import
Steve Holden wrote: > Shane Hathaway wrote: >> The structure of the Java language makes this relatively easy. >> > > And there's so much more busywork in Java that it's probably worth > automating. See > >http://www.artima.com/weblogs/viewpost.jsp?thread=42242 Agreed. Here's my take on Java vs. Python: http://hathawaymix.org/Weblog/2004-06-16 Shane -- http://mail.python.org/mailman/listinfo/python-list
Re: Managing import statements
Jean-Paul Calderone wrote: > On Sat, 10 Dec 2005 02:21:39 -0700, Shane Hathaway <[EMAIL PROTECTED]> wrote: >>How about PyLint / PyChecker? Can I configure one of them to tell me >>only about missing / extra imports? Last time I used one of those >>tools, it spewed excessively pedantic warnings. Should I reconsider? > > > I use pyflakes for this: <http://divmod.org/trac/wiki/DivmodPyflakes>. The > *only* things it tells me about are modules that are imported but never used > and names that are used but not defined. It's false positive rate is > something like 1 in 10,000. That's definitely a good lead. Thanks. > This is something I've long wanted to add to pyflakes (or as another feature > of pyflakes/emacs integration). Is there a community around pyflakes? If I wanted to contribute to it, could I? Shane -- http://mail.python.org/mailman/listinfo/python-list
Re: Managing import statements
Chris Mellon wrote: > On 12/10/05, Shane Hathaway <[EMAIL PROTECTED]> wrote: >>I'm surprised this problem isn't more familiar to the group. Perhaps >>some thought I was asking a newbie question. I'm definitely a newbie in >>the sum of human knowledge, but at least I've learned some tiny fraction >>of it that includes Python, DRY, test-first methodology, OOP, design >>patterns, XP, and other things that are commonly understood by this >>group. Let's move beyond that. I'm looking for ways to gain just a >>little more productivity, and improving the process of managing imports >>could be low-hanging fruit. > > It is probably because most people don't regularly switch that much > code around, or use that many modules. I think the fact that you move > that much code between modules is probably a code smell in and of > itself - you're clearly moving and changing responsibilities. > Refactoring in smaller chunks, less extreme refactoring, correcting > the imports as you go, and avoiding inline imports without a really > good reason will probably help you a lot more than a new syntax. That's an insightful suggestion, but I'm pretty sure I'm doing it right. :-) I fill my mind with the way the code should look and behave when it's done, then I go through the code and change everything that doesn't match the picture. As the code moves closer to production and bugs become more expensive, I add a step to the process where I perform more formal refactoring, but that process takes much longer. The problems caused by the informal process are less expensive than the formal process. > Yes. Spend an afternoon looking at PyLints options, get rid of the > stuff you don't like, and use it regularly. PyDev has PyLint > integration, which is nice. Ok, thanks. > I don't think I've ever imported more than a dozen modules into any > given file. I rarely find it neccesary to move huge chunks of code > between my modules - the biggest such I did was when I moved from a > single-file proof of concept to a real modular structure, and that > only took me an hour or so. If I'd done it modularly to start with it > would have been fine. Well, code moves a lot in the immature phases of large applications like Zope and distributed systems. Shane -- http://mail.python.org/mailman/listinfo/python-list
Re: Loop until condition is true
Remi Villatel wrote: > Hi there, > > There is always a "nice" way to do things in Python but this time I can't > find one. > > What I'm trying to achieve is a conditionnal loop of which the condition > test would be done at the end so the loop is executed at least once. It's > some way the opposite of "while". > > So far, all I got is: > > while True: > some(code) > if final_condition is True: > break > # > # > > What I don't find so "nice" is to have to build an infinite loop only to > break it. FWIW, my own experience is that the "while True" idiom is actually safer and better than alternatives like do/while. I used to write do/while loops all the time, but I wound up with more than my fair share of unintentionally infinite loops. I put too much trust in the syntax: I expected that since I was using the cleaner construct, I didn't have to worry about infinite loops. Now, I think of "while True" not as an infinite loop, but rather as a sign reminding me to be wary of looping infinitely in a particular spot. I feel like this has resulted in a lot fewer infinite loops in my own code. Now I believe that any loop that can't be represented well with "for" or a conditional "while" has enough inherent complexity to justify a warning sign, and "while True" has bright yellow flashing lights all over it. Thus I'm quite in favor of the status quo. Shane -- http://mail.python.org/mailman/listinfo/python-list
Re: timeoutsocket.py mirror?
[EMAIL PROTECTED] wrote: > Can anybody provide a mirror for this module? The original URL seems to > be down. I have been looking for over an hour, and every single > resource that uses it links to the timo-tasi.org site to download it. FWIW, Python 2.3+ has the timeout functionality built in, so timeoutsocket.py is no longer needed. See the documentation on socket.Socket.settimeout(). Shane -- http://mail.python.org/mailman/listinfo/python-list
Re: time.clock() or time.time()
[EMAIL PROTECTED] wrote: > What's the difference between time.clock() and time.time() > (and please don't say clock() is the CPU clock and time() is the actual > time because that doesn't help me at all :) > > I'm trying to benchmark some function calls for Zope project and when I > use t0=time.clock(); foo(); print time.clock()-t0 > I get much smaller values than when I use time.clock() (most of them > 0.0 but some 0.01) > When I use time.time() I get values like 0.0133562088013, > 0.00669002532959 etc. > To me it looks like time.time() gives a better measure (at least from a > statistical practical point of view). time.time() is very likely what you want. time.time() measures real time, while time.clock() measures the time the CPU dedicates to your program. For example, if your function spends 2 seconds doing pure I/O and 3 seconds doing pure computation, you should expect time.time() to show 5 that seconds elapsed, and time.clock() to show that the CPU was consumed by your program for 3 seconds. Shane -- http://mail.python.org/mailman/listinfo/python-list
Re: time.clock() or time.time()
Magnus Lycka wrote: > Shane Hathaway wrote: > >>time.time() measures real time, while time.clock() measures the time the >>CPU dedicates to your program. > > > I suppose that varies with the platform... "help(time.clock)" says: > > Help on built-in function clock: > > clock(...) > clock() -> floating point number > > Return the CPU time or real time since the start of the process or > since > the first call to clock(). This has as much precision as the > system records. > > Another thing to notice is that depending on OS, either time.time() or > time.clock() might have much higher precision than the other. I didn't notice that. Thanks. However, isn't this thoroughly un-Pythonic? No wonder people have to ask. Wouldn't it be better to have: time.time() -> real time, with as much precision as the platform provides. Does not wrap around. time.cputime() -> CPU time, or real time on platforms that don't measure CPU time separately from real time. May wrap around in long-running processes. Shane -- http://mail.python.org/mailman/listinfo/python-list
urllib versus IIS
I started experimenting with SOAPpy yesterday and immediately hit a snag. Both web services I tried simply hung and never replied. After a lot of digging, I found out what was going wrong: urllib.urlopen() is issuing an HTTP/1.0 request, but Microsoft IIS 5 ignores the client HTTP version and replies with an HTTP/1.1 response. This is a problem because while HTTP/1.0 servers are expected to close the connection once the response is finished, HTTP/1.1 servers are allowed keep the connection open. urllib assumes that the connection always closes. Therefore, when urllib receives an HTTP/1.1 response, it hangs until the server feels inclined to close the connection. Obviously the server is wrong, since HTTP/1.0 requests should only receive HTTP/1.0 responses, but I can't do anything about that. Now, there is actually code in httplib that would allow urllib to correctly understand HTTP/1.1 responses, if only urllib used it. After the headers have been parsed, urllib calls getfile(), but I think it should call getresponse() instead. The result of getresponse() is almost like a file; it just needs readline(s) and iteration. In fact, perhaps httplib's getfile() should be deprecated, since HTTP/1.1 has several options for encoding the response body (chunking and compression) and users of httplib shouldn't have to know about those encodings. Users should use getresponse() instead. So, is it worth my time to fix urllib and httplib, making urllib use getresponse() instead of getfile()? Would the changes be accepted? Is anyone else working on something similar? BTW, this is on Python 2.3.5, but I haven't spotted any changes between Python 2.3.5 and current CVS that would have fixed the problem. I'll start trying Python CVS in a moment. Shane -- http://mail.python.org/mailman/listinfo/python-list
Re: pre-PEP: Suite-Based Keywords
Kent Johnson wrote: > Brian Sabbey wrote: >> Using suite-based keyword arguments, the code >> >> f(x = 1) >> >> is equivalent to >> >> f(): >>x = 1 > > > ISTM the syntax is ambiguous. How do you interpret > if f(): > x = 1 > ? > > Is a suite alllowed only when a block could not be introduced in the > current syntax? I like this PEP a lot, but your concern is valid. Maybe Brian could modify the PEP slightly to disambiguate. How about using an ellipsis in the argument list to signify suite-based keywords? Examples: f(...): x = 1 class C(object): x = property(...): doc = "I'm the 'x' property." def fget(self): return self.__x def fset(self, value): self.__x = value def fdel(self): del self.__x d = dict(...): a = 1 b = 2 Using an ellipsis in a statement that would begin a different kind of block is illegal and generates a syntax error. Note that this usage seems to fit well with the definition of "ellipsis". http://dictionary.reference.com/search?q=ellipsis Shane -- http://mail.python.org/mailman/listinfo/python-list
Re: pre-PEP: Suite-Based Keywords
Brian Sabbey wrote:
> Maybe using '**' would be better than '...' since it already is used to
> indicate keyword arguments. Example:
>
> class C(object):
> x = property(**):
>doc = "I'm the 'x' property."
>def fget(self):
> return self.__x
>def fset(self, value):
> self.__x = value
>def fdel(self):
> del self.__x
Looks good to me. You should update the pre-PEP and submit it again to
the list.
This syntax might also be a good replacement for event handling when
lambda goes away (as Guido announced in his PyCon 2005 keynote.)
button = Button(self, "Push me")
button.addHandlers(**):
def onmouseover(event):
self.textBox.setText("Are you going to push me?")
def onmouseout(event):
self.textBox.setText("Too shy. Goodbye.")
def onclick(event):
self.textBox.setText("Ouch!")
oncontextmenu = self.oncontextmenu
Shane
--
http://mail.python.org/mailman/listinfo/python-list
Re: PyGTK vs. wxPython
Szabolcs Nagy wrote: > it's not quite true since the latest stable release (2.6.0.0) > > see the new wx doc (it's generated with epydoc so it's not for C++): > http://www.wxpython.org/docs/api/ > > i used wxPython with XRCed a few times and i liked the way it works > (worked under linux and win as well for me) +1. I've had a lot of success with XRCed, but no success with wxGlade. The UI in XRCed needs polish but it's easy enough to use. Also, wxGlade wants to spew generated Python code, while XRCed generates a nice resource file that wx can load easily. Shane -- http://mail.python.org/mailman/listinfo/python-list
Re: Trigraph Idiom - Original?
Jeff Winkler wrote: > I've come up with a trigraph idiom, am curious if it's been done before > (probably). I like to use trigraphs occasionally. > > Scenario: I'm doing an RSS->Javascript conversion for our intranet. I'd > like to use different CSS class if a post is new. Code: > > hoursOld=abs(time.time()-time.mktime(i.modified_parsed))/3600 > cssClass=['rssLink','rssLinkNew'][hoursOld<12] > entry='%s' % > (cssClass,i['link'],i['title']) > > So, ['rssLink','rssLinkNew'] is index by boolean value- False:0, or > True:1. > > I realize many will find this hideous, but 3 lines of code to do > something simple seems equally bad. Thoughts? Is there a better way? The need for ternary expressions seems to center around presentation to humans. I find myself using such expressions frequently in presentation templates or in code that prepares information for templates. You're using it the same way. I always write it this way: condition and truecase or falsecase This works as long as truecase evaluates as a true value. (If it doesn't, the result of the expression is falsecase.) So I would write the cssClass assignment like this: cssClass = (hoursOld < 12) and 'rssLinkNew' or 'rssLink' The C equivalent is more readable, but this is close enough. It's the same trick people use in shell scripts. Shane -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Challenge ahead [NEW] for riddle lovers
pythonchallenge wrote: > For the riddles' lovers among you, you are most invited to take part > in the Python Challenge, the first python programming riddle on the net. > > You are invited to take part in it at: > http://www.pythonchallenge.com That was pretty fun. Good for a Friday. Too bad it comes to an abrupt "temporary end". Shane P.S. I hope I didn't hammer your server on step 3. I was missing the mark. :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Challenge ahead [NEW] for riddle lovers
darren kirby wrote: > quoth the Shane Hathaway: > >>pythonchallenge wrote: >> >>>For the riddles' lovers among you, you are most invited to take part >>>in the Python Challenge, the first python programming riddle on the net. >>> >>>You are invited to take part in it at: >>>http://www.pythonchallenge.com >> >>That was pretty fun. Good for a Friday. Too bad it comes to an abrupt >>"temporary end". >> >>Shane >> >>P.S. I hope I didn't hammer your server on step 3. I was missing the >>mark. :-) > > > You're not the only one. This is where I am currently stuck. It's starting to > hurt my head. > > There are 478 results in the form *BBBsBBB* but the thing said 'exactly' > right, well there are 10 results in the form *sBBBsBBBs* > None of them seem to work... I did the same thing. Now just combine those ten results. Shane -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal: Inline Import
Benji York wrote: > Shane Hathaway wrote: > >> Benji York wrote: >> >>> OK, good. You won't have to worry about that. :) >> >> >> You didn't give a reason for disliking it. > > > Oh, I don't particularly dislike it. I hadn't come up with a reason to > like or dislike it, other than a predilection for the status quo. I definitely sympathize. I don't want to see random changes in Python, either. The inline import idea was a bit intriguing when it surfaced, though. :-) Shane -- http://mail.python.org/mailman/listinfo/python-list
Re: python coding contest
Paul McGuire wrote:
> "Paul McGuire" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>
>
>>Well *I'm* certainly looking forward to learning some new tricks! My
>>(non-cheat) version is a comparatively-portly 245, and no alternatives are
>>popping into my head at the moment!
>>
>>-- Paul
>>
>>
>
> down to 2 lines, 229 characters
I'm down to 133 characters (counted according to 'wc -c') on a single
line. It contains about 11 whitespace characters (depending on what you
consider whitespace.) It's way too tricky for my taste, but it's fun to
play anyway. Has anyone done better so far? Here's a hint on my
strategy: the code contains three large integers. :-)
Also, here's another cheat version. (No, 7seg.com does not exist.)
import urllib2
def seven_seg(x):return urllib2.urlopen('http://7seg.com/'+x).read()
Shane
--
http://mail.python.org/mailman/listinfo/python-list
Re: python coding contest
Tim Hochberg wrote: > Paul McGuire wrote: > >>"Shane Hathaway" <[EMAIL PROTECTED]> wrote in message >>news:[EMAIL PROTECTED] >> >> >>>I'm down to 133 characters (counted according to 'wc -c') on a single >>>line. It contains about 11 whitespace characters (depending on what you >>>consider whitespace.) It's way too tricky for my taste, but it's fun to >>>play anyway. Has anyone done better so far? Here's a hint on my >>>strategy: the code contains three large integers. :-) >>> >> >>With 1 large integer, I am down to 200 characters on 1 multiline line. I >>can guess why you have 3 integers vs. 1, but I don't see how that saves you >>any characters of code. > > > This is interesting. I have a six line solution that is 133 characters > long. 133 characters according to 'wc -c'? If so, that will surely win style points over my one-line monster. But I bet someone's going to do better (without cheating.) Shane -- http://mail.python.org/mailman/listinfo/python-list
Re: python coding contest
I just found a 125 character solution. It's actually faster and more readable than the 133 character solution (though it's still obscure.) It depends on Python 2.4. If Python 2.3 compatibility is required for the contest, I have to add 4 characters. Shane [EMAIL PROTECTED] pycontest_01]$ wc -c seven_seg.py 125 seven_seg.py [EMAIL PROTECTED] pycontest_01]$ python test.py . -- Ran 1 test in 0.084s OK -- http://mail.python.org/mailman/listinfo/python-list
Re: python coding contest
Andrew Durdin wrote: > On 12/28/05, Shane Hathaway <[EMAIL PROTECTED]> wrote: > >>I just found a 125 character solution. It's actually faster and more >>readable than the 133 character solution (though it's still obscure.) > > > Having spent a good deal of time and effort, and not getting below 144 > characters, I am now very eager to see how these shorter versions > work, particularly the 6 120-character solutions. I also expect that > someone (I'll certainly give it a try) will produce a yet shorter > version after the contest closes, based on the knowledge from the > winning solutions. Roberto Alsina fully documented his 120 byte solution here: http://www.pycs.net/lateral/weblog/2005/12/29.html#P333 My 120 byte solution is equivalent. Many others probably did the same thing. Python's philosophy of one way to do it seems to be leading us all down the same road. However, it still feels like there's room for improvement. I have a 123 byte solution based on a fairly repetitive 21 character string; if I could compress the representation of the string, it could win. Shane -- http://mail.python.org/mailman/listinfo/python-list
Re: python coding contest
Tim Hochberg wrote:
> g=''.join;seven_seg=lambda i:g(
> g(' _|x|'[ord("~$]m'k{d\x7fo"[int(n)])>>s&j]
> for n in i for j in(2,1,4))+'\n'for s in(6,0,3))
>
> I've replaced the unprintable characters and added some preemptive
> linebreaks so that hopefully this won't get too munged. It's all clear
> now, right? Two hints: 6,0,3->row, 2,1,4->column and the 6 and 1 have to
> be where they are to exploit the property that the top row only ever has
> a center character in it. That way things can be encoded in 7-bits and
> fit in a character string that Python likes. The order of the other loop
> indices is mostly accidental but not all permutations may work.
I worked on a similar solution, but didn't have the idea of iterating
over a series of masks as you did with the 'j' variable. Good work.
> I'm off to try to figure out how to do it the other way now, before the
> code gets revealed.
We should have more contests like this. While the skills I applied for
the contest don't have much practical value, the mental exercise was great.
Shane
--
http://mail.python.org/mailman/listinfo/python-list
Re: python coding contest
Szabolcs Nagy wrote:
> my two solutions (well I wasn't so clever to encode everything in
> strings instead of numbers, but at least it won't give warnings about
> non ascii characters):
> 128:
> j,seven_seg=''.join,lambda s:j(j(' |_ |'[i>>3*int(c)&b]for c in s for b
> in(4,2,1))+'\n'for i in(306775170,1060861645,524130191))
>
> 122:
> seven_seg=lambda s,j=''.join:j(j(' _ _|_| |_
> |'[i>>3*int(c)&14:][:3]for c in s)+'\n'for i
> in(8208,934111592,664455910))
FWIW, here's my 121 character solution that's fully printable. (Line
breaks added.)
seven_seg=lambda s,j=''.join:j(j(
' _ _| |_ |_|'[ord('^-TR5bfmvr'[int(c)])/b%8*2:][:3]for c in s)+'\n'
for b in(64,8,1))
This solution uses the 7 lower bits of every encoded byte, rather than
the 7 upper bits that the 8 bit solutions use. 8 bits make it possible
to avoid multiplying by 2, but I wanted this version to use pure ASCII,
so I had to multiply by 2. The choice to divide rather than shift is
important because it allowed me to eliminate parentheses.
It's interesting that there seems to be no room for special cases. For
example, the top row has only two states and those states are not used
by the other rows. Therefore, the top row could be computed in a much
simpler way than the other two rows, and the other two rows could be
simplified by having only 5 possible states rather than 7. However, all
my attempts to exploit this property produced larger code.
Shane
--
http://mail.python.org/mailman/listinfo/python-list
Re: python coding contest
André wrote: > For the few that might be interested, I will be posting the details of > a 117 character long solution to the challenge on my blog > http://aroberge.blogspot.com/. > > Enjoy! You took advantage of prime numbers, enabling you to extract encoded information using a single modulus operation rather than shift and mask. Brilliant strategy. Congratulations. Shane -- http://mail.python.org/mailman/listinfo/python-list
Re: python coding contest
Claudio Grondi wrote: > so I tried all which made sense in the context of '0' conversion and > found out, that it should be the > >' _ |_|_ _| |' > > not the at http://aroberge.blogspot.com/ > >' _ |_|_ _| |' The HTML source has the three spaces. If the code had been surrounded by a "pre" tag, it would have rendered correctly. Shane -- http://mail.python.org/mailman/listinfo/python-list
Re: Spiritual Programming (OT, but Python-inspired)
[EMAIL PROTECTED] wrote: > Perhaps this is one reason why programmers are so passionate, and even > religious, about their programming tools; because they intuitively > sense that we are dealing with ideas that, however crudely, mirror > eternal realities of immense significance. While I don't associate any spiritual significance with programming, I do think that the choices we've made in the field of programming reflect deeply upon human cognition. A modern computer is a thoroughly abstract mathematical machine, so programmers can choose almost any abstraction to solve a problem. But it turns out that some abstractions fit our minds better than others, so programmers usually apply a small set of abstractions many times. So if we could categorize and chart the space of all programming abstractions that we have found most useful, we might learn a little about how our minds work. The research could be valuable for AI. Shane -- http://mail.python.org/mailman/listinfo/python-list
Re: libpython2.4.so
Levi Campbell wrote: > what is /usr/lib/libpython2.4.so used for? > On many systems, it is the core of Python, and /usr/bin/python2.4 is a small wrapper around it. Here's what I see on my box: [EMAIL PROTECTED] usr]$ ls -l bin/python2.4 lib/libpython2.4.so.1.0 -rwxr-xr-x 1 root root4072 Oct 3 12:35 bin/python2.4 -r-xr-xr-x 1 root root 1009832 Oct 3 12:35 lib/libpython2.4.so.1.0 Shane -- http://mail.python.org/mailman/listinfo/python-list
Re: Finding the name of a class
John Salerno wrote: > >>> class Foo(object): > pass > > >>> dir(Foo) > ['__class__', '__delattr__', '__dict__', '__doc__', '__getattribute__', > '__hash__', '__init__', '__module__', '__new__', '__reduce__', > '__reduce_ex__', '__repr__', '__setattr__', '__str__', '__weakref__'] > > Hmmm. Don't forget to file a bug. Shane -- http://mail.python.org/mailman/listinfo/python-list
Re: Finding the name of a class
John Salerno wrote: > Shane Hathaway wrote: > >> Don't forget to file a bug. > > I'm reluctant to call it a bug just yet. Here's more stuff below. > There's obviously a difference between old- and new-style classes. It > seems that as far as new-style is concerned, __name__ is an attribute of > __class__ (along with a bunch of other stuff), but not of Foo itself. I'm not sure what you're saying. The class of a class is the 'type' builtin, unless metaclasses are involved. So your expression "dir(Foo.__class__)" is equivalent to "dir(type)", and the 'type' builtin happens to have a __name__ attribute that dir() notices. Take a look: >>> class Foo(object): ... pass ... >>> Foo.__class__ is type True >>> Foo.__name__ 'Foo' >>> Foo.__class__.__name__ 'type' The bug is that the expression "dir(someclass)", where the class is a user-defined class of either new or old style, never reveals to the user that the class object has a __name__ attribute. I tested this with Python versions 2.3 through 2.5b1. This is an education issue; since that important attribute is not in the list, newcomers are not likely to discover it, and may instead use strange incantations to get the name of a class. Do you want me to file the bug? Shane -- http://mail.python.org/mailman/listinfo/python-list
Re: OT: What's up with the starship?
Fredrik Lundh wrote: > [EMAIL PROTECTED] wrote: > >> Then perhaps you or he could explain it to us less intelligent >> people in very simple terms? > > the security advisory explains that the cause of the problem is a bug > in the source code used to implement repr() for 32-bit Unicode strings, > on all Python versions from 2.2 and onwards. > > Python 2.2 was released in 2001. So, are we to infer that Starship was running Python 2.1 or earlier at the time the server was compromised? Otherwise I missed your point, sorry. The vulnerability described by PSF-2006-001 could easily lead to server compromises. AFAIK, most Linux distributions enable UCS-4 by default, and they have done so for years. To compromise a server using the PSF-2006-001 vulnerability, an intruder just needs to find a Python CGI script running on that server that converts some bad input to unicode, then cause that script to raise an error while processing the request containing the bad input. There's a good chance the script will log an error with the repr() of the bad input, allowing the intruder to mess with the stack. If the server is running a distribution-supplied build of Python, the intruder may be able to inject arbitrary code. I don't know if this concern applies to Starship specifically, but it seems to apply to thousands of web sites running Python CGIs and Python web servers. Shane -- http://mail.python.org/mailman/listinfo/python-list
Re: OT: What's up with the starship?
Fredrik Lundh wrote: > Shane Hathaway wrote: > > > I don't know if this concern applies to Starship specifically, but it > > seems to apply to thousands of web sites running Python CGIs and > > Python web servers. > > so are we seeing thousands of web sites running Python CGIs and web > servers being attacked right now? No, but it often takes a long time for servers to get patched, so the window for intruders is going to be open for a while. I'm trying to understand: a) how urgent and/or exploitable this is, b) how I can check whether a given Python installation (running on a server) has been patched, and c) whether the security advisory downplays the risk more than it should, since it appears that many Zope/Plone web servers are vulnerable. Shane -- http://mail.python.org/mailman/listinfo/python-list
Re: Exploiting Dual Core's with Py_NewInterpreter's separated GIL ?
robert wrote: > I'd like to use multiple CPU cores for selected time consuming Python > computations (incl. numpy/scipy) in a frictionless manner. > > Interprocess communication is tedious and out of question, so I > thought about simply using a more Python interpreter instances > (Py_NewInterpreter) with extra GIL in the same process. I expect to > be able to directly push around Python Object-Trees between the 2 (or > more) interpreters by doing some careful locking. > > Any hope to come through? If possible, what are the main dangers? Is > there an example / guideline around for that task? - using ctypes or > so. > > Or is there even a ready made Python module which makes it easy to > setup and deal with extra Interpreter instances? If not, would it be > an idea to create such thing in the Python std libs to make Python > multi-processor-ready. I guess Python will always have a GIL - > otherwise it would loose lots of comfort in threaded programming I'd like to mention mod_python, which creates multiple interpreters inside Apache. It does this transparently and works well. There is no apparent lock contention between the interpreters, because no Python objects are shared. Also, I'd like to make the observation that it is not always necessary to share the entire interpreter (ala threads) in order to take advantage of multiple cores. I think Python only needs a nice way to share a relatively small set of objects using shared memory. POSH goes in that direction, but I don't think it's simple enough yet. http://modpython.org/ http://poshmodule.sourceforge.net/ Shane -- http://mail.python.org/mailman/listinfo/python-list
Re: Web Browser Pygame Plug-in?
Gregory Piñero wrote: > Are there security issues too? Would you remove potentially harmful > Python libraries for the plugin, not allow system calls, etc? Would > you only allow file system access in one area? Ah, so you also want to distribute untrusted Python code. That's fairly hard. There's a discussion about it on Python-Dev right now. > I guess you'd just copy however Java applets work? But run faster ;-) More or less. Shane -- http://mail.python.org/mailman/listinfo/python-list
Re: Out of the box database support
Alex Biddle wrote: > Ah, so separate downloads then. At least now I know. > > Ergh... I checked the version of Python my current host is running and its > 2.2. > > ...ergh This is why you really want a VPS (virtual private server). The cost is similar to a web host but you get to choose your own technologies and versions. Several companies come to mind: http://westhost.com/ http://jvds.com/ http://linode.com/ I'm using Westhost, which provides Python 2.2 if you ask for it, but I compiled Python 2.4 instead. I didn't even have to ask whether I was allowed to do that. :-) Shane -- http://mail.python.org/mailman/listinfo/python-list
Re: Web Browser Pygame Plug-in?
Gregory Piñero wrote: > I was just idley curious on what it would take to make a web plug-in > for Pygame. I'm picturing it working the way my browser currently > shows flash games. Is such an idea even possible? Has anyone > attempted this? I once played with a similar idea. Yes, it's possible, although platform differences make the idea non-trivial. Specifically, I ran into difficulty when I discovered that it's not easy on Linux to load a dynamic library (such as libpython.so) which in turn loads other dynamic libraries (such as native Python modules), since the library search path is not modifiable at runtime. A possible workaround is to launch a separate process which projects into the browser window. I don't know what surprises may pop up on other platforms. Shane -- http://mail.python.org/mailman/listinfo/python-list
Re: Out of the box database support
Alex Biddle wrote: > Ah, so separate downloads then. At least now I know. > > Ergh... I checked the version of Python my current host is running and its > 2.2. > > ...ergh This is why you really want a VPS (virtual private server). The cost is similar to a web host but you get to choose your own technologies and versions. Several companies come to mind: http://westhost.com/ http://jvds.com/ http://linode.com/ I'm using Westhost, which provides Python 2.2 if you ask for it, but I compiled Python 2.4 instead. I didn't even have to ask whether I was allowed to do that. :-) Shane -- http://mail.python.org/mailman/listinfo/python-list
Re: Out of the box database support
Alex Biddle wrote: > Ah, so separate downloads then. At least now I know. > > Ergh... I checked the version of Python my current host is running and its > 2.2. > > ...ergh This is why you really want a VPS (virtual private server). The cost is similar to a web host but you get to choose your own technologies and versions. Several companies come to mind: http://westhost.com/ http://jvds.com/ http://linode.com/ I'm using Westhost, which provides Python 2.2 if you ask for it, but I compiled Python 2.4 instead. I didn't even have to ask whether I was allowed to do that. :-) Shane -- http://mail.python.org/mailman/listinfo/python-list
Re: Web Browser Pygame Plug-in?
Gregory Piñero wrote: > Shane Wrote: >> Ah, so you also want to distribute untrusted Python code. That's fairly >> hard. There's a discussion about it on Python-Dev right now. > > Well, I want to write a game in Pygame, and people can just go to my > website and play it within their browser. I guess that would be > untrusted code? If they download your code with the plugin, your code is trusted. If they download it separately in a browser session, it's untrusted. So one way to get started quickly is to just mix your code with the plugin, and not attempt to enable execution of untrusted code. Shane -- http://mail.python.org/mailman/listinfo/python-list
Re: The Python Papers Edition One
[EMAIL PROTECTED] wrote: > Ben Finney wrote: >> "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes: >> >>> Yes, it's true that you can't resell copies of The Python Papers for >>> personal profits, but you may derive from it, reproduce and >>> propagate it. You're quite right to point it out. >> Then please revise the false statement that the publication is "free >> as in beer and freedom", or make it true by releasing the documents >> under a license that does grant conventional free-software freedoms. >> >> -- >> \ "They can not take away our self respect if we do not give it | >> `\ to them." -- Mahatma Gandhi | >> _o__) | >> Ben Finney > > I thought I just had. In what way does the statement "Yes, it's true > that you can't resell copies of The Python Papers for personal profits, > but you may derive from it, reproduce and propagate it" not provide > such a revision and clarification? Seriously, let me know what exact > statement you feel needs to be made, and I will endorse it accordingly > if it is accurate. The phrase "free as in freedom" is commonly understood differently from the way you are using it. Free as in freedom usually grants the right to distribute for a fee. Many Linux distributors depend on that right; otherwise they wouldn't have the right to sell CDs. IMHO your licensing terms are fine; you don't need to switch from the CC license. Just avoid the term "free as in freedom", since the Free Software Foundation has assigned that phrase a very specific meaning. Shane -- http://mail.python.org/mailman/listinfo/python-list
Re: Subprocess with a Python Session?
Calvin Spealman wrote:
> No matter what I do I cant get the following code to do what I expect.
> I hadn't used subprocess t o read and write to pipes of a
> still-running app, and I just can't seem to get it right. What gives?
>
> import subprocess
>
> p = subprocess.Popen("python", stdout=subprocess.PIPE, stdin=subprocess.PIPE)
> p.stdin.write('print 10\n')
> assert p.stdout.readline() == '10\n'
Make sure the pipes are unbuffered. Launch the process with "python -u"
and flush() the streams after writing. (That's the issue I've
encountered when doing this before.)
Shane
--
http://mail.python.org/mailman/listinfo/python-list
Re: first release of PyPy
Torsten Bronger wrote: > Hallöchen! > > "Kay Schluehr" <[EMAIL PROTECTED]> writes: > > >>[...] >> >>[...] Once You get enough speed out of the PyPy-runtime and the >>community shifts to it the PEP-process degenerates in the view of >>a PyPythonista to discussions about aspects of the std-objectspace >>and language design patterns. There will be some CPython >>compliance - that's all. > > > Please could somebody explain to us non-CS people why PyPy could > have speed features CPython can't have? The idea is to shift more of the responsibility to optimize code from the human to the computer. Since C code is at a low level, the computer can only infer low level intent and thus perform low level optimizations. Humans optimize C by making thousands of speed-oriented decisions directly in the code. Python code is at a much higher level, which should enable the computer to discover more of the programmer's intent and perform deep optimizations. In the end, the computer's automated optimization could turn out better than a human's manual optimization. Thus, by expressing the Python interpreter in a high level manner, PyPy is a first step toward deep optimizations that aren't possible to automate in C. Even if things don't turn out that way, note that each generation of programming languages builds on its predecessors, and PyPy could help bootstrap the next generation. Assemblers first had to be written in machine code; when it was possible to write assemblers in assembly, people started writing complex grammars and came up with C. C compilers first had to be written in assembly; when it was possible to write C compilers in C, people started inventing high level languages. Now people are experimenting with high level compilers written in high level languages. Where will this pattern lead? Who knows. :-) Shane -- http://mail.python.org/mailman/listinfo/python-list
Re: first release of PyPy
Mike Meyer wrote: > Basically, there's a *lot* of history in programming languages. I'd > hate to see someone think that we went straight from assembler to C, > or that people didn't understand the value of dynamic languages very > early. Yes, although I wasn't following historical events; I was following the trends of what programmers in general have used. Theory has always been far ahead of practice... and generalizations are never correct. ;-) Shane -- http://mail.python.org/mailman/listinfo/python-list
Re: Python analog of Ruby on Rails?
George Sakkis wrote:
> "Christopher J. Bottaro" wrote:
>
>
>>Cool signature, can anyone do a Python one that I can leech? =)
>>
>>-- C
>>
>
>
> Here's the transliteration in python for your address:
>
> python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')])
> for p in '[EMAIL PROTECTED]'.split('@')])"
BTW, here's the proper response to that religious thread that keeps
invading this list:
python -c 'print sum([ord(c) for c in "HOLYBIBLE"])'
I'm Christian and I think it's funny. ;-) Some background:
http://scriptures.lds.org/rev/13/16-18#16
http://www.greaterthings.com/Word-Number/666HolyBible.htm
Shane
--
http://mail.python.org/mailman/listinfo/python-list
Re: Running a python program during idle time only
Mike Meyer wrote: > On a completely different topic, this looks like the wrong way to solve > the problem. You want to update a search engine based on changes to the > underlying file system. The right way to do this isn't to just keep > rescanning the file system, it's to arrange things so that your scanner > gets notified of any changes made to the file system. I did something like > this for my web site search engine, but that's hooked into the SCM that's > used for propogating changes to the web site. I know someone is working > on patches to the FreeBSD kernel to make this kind of thing work. It would > seem that some of the "backup" facilities that worked by keeping a mirror > of the disk on separate media would have to have used such hooks, but maybe > not. I think you're right that filesystem change notification is what Carlos needs. If you're interested in using Linux, Carlos, "inotify" is a new kernel module that can notify your program of filesystem changes. It's not folded into the mainline kernel yet, but it's a clean patch. http://www.edoceo.com/creo/inotify/ I don't know if Windows has anything like it. I'd be interested to hear if it does. Shane -- http://mail.python.org/mailman/listinfo/python-list
Re: working with pointers
Michael wrote:
> sorry, I'm used to working in c++ :-p
>
> if i do
> a=2
> b=a
> b=0
> then a is still 2!?
>
> so when do = mean a reference to the same object and when does it mean make
> a copy of the object??
To understand this in C++ terms, you have to treat everything, including
simple integers, as a class instance, and every variable is a reference
(or "smart pointer".) The literals '0' and '2' produce integer class
instances rather than primitive integers. Here's a reasonable C++
translation of that code, omitting destruction issues:
class Integer
{
private:
int value;
public:
Integer(int v) { value = v; }
int asInt() { return value; }
}
void test()
{
Integer *a, *b;
a = new Integer(2);
b = a;
b = new Integer(0);
}
In that light, do you see why a is still 2?
Shane
--
http://mail.python.org/mailman/listinfo/python-list
Re: anygui,anydb, any opinions?
rzed wrote: > That's all I'm talking about here. To be able to write a Python > application that can ultimately be displayed using wxWidgets or Qt > or Tkinter or Curses. Then, without having to do more than to > change which interface package is imported, to expect to see the > result displayed. To have it just happen, and to have expectations > when using Python that it *will* just happen that way. > > So what do you think? What's wrong with the picture? Why isn't > there a greater priority to work in this direction? See "The Law of Leaky Abstractions" by Joel Spolsky. http://www.joelonsoftware.com/articles/LeakyAbstractions.html As he says, "All non-trivial abstractions, to some degree, are leaky." GUI abstractions tend to leak badly. As I write this email in Thunderbird, my initial impression is that most of the controls on the screen are pretty standard and could be done with virtually any toolkit... or are they? Looking again, the "from" field has both a place for me to type and some grayed out text that reminds me I'm posting from a different account; the "to", "cc", and "newsgroup" fields are not quite combo boxes; the toolbar has pulldown buttons. So it turns out that Thunderbird is actually tied to a particular toolkit, and for good reason: GUI development has not stagnated; toolkit developers continue to invent new, interesting widgets and variations, leading to better UIs. Application developers want to take advantage of those innovations. Even anydbm is a pretty leaky abstraction. I recently tested the behavior of 5 Python dbm implementations when they run out of disk space. Most left the database in an inconsistent state, some swallowed the exception, some segfaulted, and one deadlocked. If I'm going to rely on a dbm module, I really need to know what it's going to do when it hits an exceptional condition. Thus anydbm seemed like a bad choice. Shane -- http://mail.python.org/mailman/listinfo/python-list
Re: wtf
Sergiy wrote: > print 1 / 2 > print -1 / 2 > > 0 > -1 > > correct? Yes. It works like the floor() function. >>> import math >>> math.floor(1.0 / 2) 0.0 >>> math.floor(-1.0 / 2) -1.0 Shane -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 2.5 licensing: stop this change
Steve Holden wrote: > As the only director of the Python Software Foundation to vote against a > recent Board motion to implement the change in licensing terms described in > >http://pyfound.blogspot.com/2006/04/python-25-licensing-change.html I must saay that i am fully in favor of this change. The ppython developerrs need to eat too. Iis no one ellse aware off the perils oof ooutright open source llicenssing? Shane -- http://mail.python.org/mailman/listinfo/python-list
