...and just for fun this D code is about 3.2 times faster than the
Psyco version for the same dataset (30% lines with a space):
import std.stdio, std.conv, std.string, std.stream;
int[int] get_hist(string file_name) {
int[int] hist;
foreach(string line; new BufferedFile(file_name)) {
Alan Isaac>What is the fastest way? (Ignore the import time.)<
Maybe someday someone will realize such stuff belongs to the python
STD lib...
If you need a lazy generator without padding, that splits starting
from the start, then this is the faster to me if n is close to 2:
def xpartition(seq, n
Hans:
> I have run into a bit of a subtle problem. How do I go about
> duplicating a variable (particularly a list of lists) in python. I
> was surprised when simple assignment didn't work.
Python is quite high-level language, but now and then it too accepts
some compromises to increase its spee
I find the first and third solutions simpler to read, and the first
solution requires less memory, it probably works quite well with
Psyco, and it's easy to translate to other languages (that is
important for programs you want to use for a lot of time or in
different situations), so I'd use the fir
> Henry Baxter wrote:
> > def maxi(l):
> > m = max(l)
> > for i, v in enumerate(l):
> > if m == v:
> > return i
>
> What's about l.index(max(l)) ?
The version I use:
def posmax(seq, key=None):
"""Return the position of the first maximum item of a sequence.
It a
I think they can be called "soft interfaces" or "heuristic
interfaces", it's an example of machine learning. I think it's not
easy to apply such idea to a statically typed language, but probably
it can be done on Java. I presume in the future GUI will learn more
about the usage patterns of their us
Paul Rubin:
> def posmax(seq, key=lambda x:x):
>return max(enumerate(seq), key=lambda k: key(k[1]))[0]
Is the Python max able to tell that's the identity function? I don't
think so, so your version may be slower and more memory hungry in the
common situation where you don't have a key function
The LEL mini language (there used for JRuby) seems nice, it may be
added to Tkinter:
http://ihate.rubyforge.org/profligacy/lel.html
http://ihate.rubyforge.org/profligacy/sample.html
Bye,
bearophile
--
http://mail.python.org/mailman/listinfo/python-list
Steven D'Aprano:
> Much to my surprise, the fastest solution I've tried appears to be a pure
> Python version not even using max() at all.
That version is easy to translate to other languages and you can
probably find that Psyco makes it much faster still.
Bye,
bearophile
--
http://mail.python.o
bearophile:
> That version is easy to translate to other languages and you can
> probably find that Psyco makes it much faster still.
That operation is quite common, so it deserves a bit more work:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/543271
(I can show you the D/C code if you
Marc 'BlackJack' Rintsch:
> Try calling the iterative one twice and measure the time of the second
> call. IIRC psyco needs at least one call to analyze the function, so the
> first call is not speed up.
That's how Java HotSpot works, but Psyco is very different from
HotSpot, and I think you are
If you don't want to reinvent the wheel all the time you can use this
one:
def inplacefilter(pred, alist):
"""inplacefilter(pred, alist): filters the given list like
filter(),
but works inplace, minimizing the used memory. It returns None.
>>> pr = lambda x: x > 2
>>> l = []
>
Zbigniew Braniecki:
> Is there a way to speed it up? Any easier way? Faster method?
This problem is a bit messy. Maybe it's better to sidestep the
problem, and not use a list, and create an object that wraps the list,
so it always keeps an updated record of what changes are done... but
you have to
Paul McGuire:
> Why not just
> D = dict(zip(keys,values))
> ??
Because this may require less memory:
from itertools import izip
D = dict(izip(keys, values))
:-)
Bear hugs,
bearophile
--
http://mail.python.org/mailman/listinfo/python-list
Paul Sijben:
> Is there a fixc for this issue?
At the moment I think it's better to drop Pyrex and to use Cython.
Maybe you can try that, or ask to their developers.
Bye,
bearophile
--
http://mail.python.org/mailman/listinfo/python-list
There are news:
http://article.gmane.org/gmane.comp.lang.lua.general/44781
I think Psyco may deserve some updates, because it can be useful on
Python 3.0 too, on 64bit, and on iterators (with itertools) too.
Bye,
bearophile
--
http://mail.python.org/mailman/listinfo/python-list
Steven Bethard:
> It also doesn't build the unnecessary intermediate tuples:
I see, but can't the interpreter improved to remove similar
intermediate tuples anyway? Is this a difficult thing to do?
Bye,
bearophile
--
http://mail.python.org/mailman/listinfo/python-list
miller:
> Is there any simple/easy/elegant way to retain a reference to the
> *unoptimized* version of f so I can call them both and compare
> performance?
A simple solution is to defer the optimization. That is test the
original code, call Psyco, then test it again:
def somefunc():
...
from
It seems C# 4.0 may become a bit closer to dynamic languages,
especially closer to the Boo language (that is mostly static):
http://blogs.msdn.com/charlie/archive/2008/01/25/future-focus.aspx
As it develops, and its VM gains the method inlining capabilities of
HotSpot, it will be faster. Static la
Mike C. Fletcher:
> Not sure if Mono also provides a speedup.
There is a set of good benchmarks here, the answer is negative:
http://shootout.alioth.debian.org/sandbox/benchmark.php?test=all&lang=iron
Bye,
bearophile
--
http://mail.python.org/mailman/listinfo/python-list
Stefan Behnel:
> This doesn't look like Mono to me:
> IronPython 1.1 (1.1) on .NET 2.0.50727.42
You are right! I think this shows that IronPython isn't faster than
CPython at all :-) (And it uses more memory).
Bye,
bearophile
--
http://mail.python.org/mailman/listinfo/python-list
This is smells of homework. Here are few alternative solutions of mine
that I don't like. I presume a good teacher will refuse them all,
because no one of them uses the right tool :-) And every one of them
has some small problem (even if they work here).
data = """\
TABLE
black
blue
red
CHAIR
yell
Paul Rubin:
> I like the suggestion, except it should be
> port = int(sys.argv.get(1, '8000'))
> one could imagine your example going wrong in a protocol where 0 is
> a valid port number.
I think a high-level language like Python must have boolean operators
(or and not) that behave in a much
Steven D'Aprano:
> With the greatest respect, I think that if you think the second example
> "is more clear", you're completely bonkers. *grins*
No one is completely normal, I presume :-)
I'd like to know what others think about it, about this anti-feature.
What I can say is that other computer la
Carl Banks:
> I think booleans should be completely disjoint from all other types,
> as they are in Java. "and", "or", and "not" should accept only boolean
> operands and return only boolean results.
I'd like "or" and "and" (and "not") to return booleans only, to avoid
bugs and make their meanin
Michael Spencer:
> # perhaps faster
> $ python -mtimeit -s"t='D'" "if t in 'DE': pass"
> 100 loops, best of 3: 0.204 usec per loop
That may be faster indeed, but it gives true if t is "DE" too, and
that may be bad.
The new string search done by Effbot is really good :-)
Bye,
bearophile
--
ht
Gabriel Genellina:
> On most platforms -with a notable exception- there is a C compiler
> available as a standard tool, which is used to compile Python itself.
For that platform the Python site may offer a version of binary Python
bundled with the MingGW (and Cython too, maybe), like ShedSkin does
Steven D'Aprano:
> What you're trying to do is the equivalent of substring searching. There
> are simple algorithms that do this, and there are fast algorithms, but
> the simple ones aren't fast and the fast ones aren't simple.
> However, for your use case, the simple algorithm is probably fast eno
Steven D'Aprano:
> I believe that it is considered an abuse of doctest to write a function
> with 28 lines of code and 19 tests
I agree with you. Most of my functions/methods have more compact
doctests (putting things on many lines has the advantage of letting
you locate the failing tests in a sim
For me Python is useful to write code that gives *correct* results,
allowing me to write it in a short & simple way, with quick debugging
cycles (and for other purposes, like to write dynamic code, to use it
as glue language to use libraries, to create quick GUIs, as scripting
for data munging, etc
Mark Dickinson:
> This is probably the only sane way to deal with differences in
> platform behaviour when doing float divisions.
What Python run on a CPU that doesn't handle the nan correctly?
Bye,
bearophile
--
http://mail.python.org/mailman/listinfo/python-list
Paul McGuire:
> Sounds like you've been reading about Cobra...
I have heard about that language (for dotnet?) but my idea doesn't
come from Cobra...
Bye,
bearophile
--
http://mail.python.org/mailman/listinfo/python-list
Diez B. Roggisch:
> Then build up the mapping. Not elegant, but works.
For the OP: note that a list suffices, no dict needed.
Bye,
bearophile
--
http://mail.python.org/mailman/listinfo/python-list
Steven D'Aprano:
bearophile:
> > The new string search done by Effbot is really good :-)
> Care to explain what "new string search" you're referring to? Inquiring
> minds want to know.
I meant this good work you can find in Python 2.5:
http://effbot.org/zone/stringlib.htm
Bye,
bearophile
--
http
[repost]
Duncan Booth:
> >>> from operator import itemgetter
> >>> lst = [(1,2,4),(3,2,1),(2,2,2),(2,1,4),(2,4,1)]
> >>> lst.sort(key=itemgetter(1))
> >>> lst.sort(key=itemgetter(2))
> >>> lst
> [(3, 2, 1), (2, 4, 1), (2, 2, 2), (2, 1, 4), (1, 2, 4)]
A little known thing from Python 2.5:
>>> fro
Paul McGuire:
> - Added '==' short-cut to see if a given string matches a
> pyparsing expression. For instance, you can now write:
>
> integer = Word(nums)
> if "123" == integer:
># do something
>
> print [ x for x in "123 234 asld".split() if x==integer ]
> # prints ['12
Michael Robertson:
> I'm guessing sage has this, but shouldn't something like this be part of
> the standard library (perhaps in C)?
My answer is positive. As a reference point you can look at the
combinatorics module of Mathematica.
Bye,
bearophile
--
http://mail.python.org/mailman/listinfo/pyt
Paul Rubin:
> In 3.0 you may be able to say {,} but there is a contingent that would
> just as soon get rid of all that special syntax, so you'd say list()
> instead of [], dict() instead of {}, etc.
For Python 3.0 I'd like {} for the empty set and {:} for the empty
dict, but that idea was refused
Ben Finney:
> I often use these myself. They're slightly more explicit, which can
> help when I want the reader not to have to think too much, and they're
> not particularly verbose because the names are well-chosen and short.
I'd like "list" be called "array" ;-)
> Note that '()' is syntactical
Ben Finney:
> Generator literals do not require the
> parens at all. However, the syntax of where the generator literal
> *appears* can make it necessary to explicitly group the expression
> using parens.
Have you taken a look at Boo?
In Python this isn't possible:
s = char for char in string.digi
Fuzzyman:
> Another interesting little benchmark of CPython and IronPython. Can't
> see the code, but it looks like an implementation of the 11 queens
> problem and IronPython comes out a clear winner on this one. (Looks
> like no benchmark for psyco.)
If you want a more reliable set of benchmarks
Cameron Laird:
> It does occur to me, though, that even more widely applicable
> than the combinatorics module of Mathematica (if only because of
> its licensing) might be such resources as
What I was trying to say is that that Mathematica combinatorics module
contains lots and lots and lots of th
mathieu, stop writing complex REs like obfuscated toys, use the
re.VERBOSE flag and split that RE into several commented and
*indented* lines (indented just like Python code), the indentation
level has to be used to denote nesting. With that you may be able to
solve the problem by yourself. If not,
Paul Rubin:
> Even with that though, at least for me, Python starts feeling really
> scary when the iterators get this complicated. I start wishing for
> a static type system, re-usable iterators, etc.
This is an interesting topic. I agree with you, I too was scared in a
similar situation. The la
cokofree:
> Sadly that is pretty slow though...
It's quadratic, and it's not even short, you can do (quadratic still):
print [x for x in range(2, 100) if all(x%i for i in range(2, x))]
In D you can write similar code.
Bye,
bearophile
--
http://mail.python.org/mailman/listinfo/python-list
Gary Herron:
> Try image.getpixel((x,y)) to retrieve the pixel at (x,y).
If the OP needs to access many pixels, then he can use the load()
method on the image object, and then read/write pixels (tuples of 3
ints) using getitem []
import Image
im = Image
img = im.load()
img[x,y] = ...
... = im
subeen:
> I think you should go for 'dictionary' that is a built-in data
> structure of Python.
The OP asks this too:
> maintain the order (for iter and print)
So I think an "ordered dict" is fitter, the op can search for an odict
implementation, in the cookbook too (I too have written one, but i
This is the first time I write something that looks like a little
rant :-) Surely I'll be wrong in many points, but I presume this isn't
going to damage people, so...
Here there are some functional Python solutions to some Euler
problems:
http://pyeuler.wikidot.com/
Some pieces of that code:
def
Paul Rubin:
> def ggenfib():
> a,b = 1,2
> while True:
> yield a
> a,b = b, a=b
Your version is the nice basic generator version (the last line
contains a +, I presume), but I like this other version too:
def xfibonacci():
a = b = 1
yield a
yield b
Arnaud Delobelle:
> In this case why not:
>
> def xfib(a=1, b=1):
> while True:
> yield a
> a += b
> yield b
> b += a
That's a bit less easy to understand than my version, for me.
In my version is easy to see the values of the variables. And using a
longer funct
Arnaud Delobelle:
> I disagree; the generator function has no right to keep a and b to
> itself. a and b cry out to be function parameters.
I see. Then that's a generator for a generalized Fibonacci
sequence :-)
Your version too is useful.
Bye,
bearophile
--
http://mail.python.org/mailman/listi
This is the best praise of semantic indentation I have read so far, by
Chris Okasaki:
http://okasaki.blogspot.com/2008/02/in-praise-of-mandatory-indentation-for.html
A quotation:
>Imagine my surprise when I started teaching this language and found the
>students picking it up faster than any langu
When I use dictionaries I find the dict.get() method very handy, and
I'd like to use it often, but I think it's quite slow. This is a small
benchmark:
from random import randrange
from timeit import default_timer as clock
def main(N, M):
keys = list(set(randrange(2*N) for n in xrange(N)))
Marc 'BlackJack' Rintsch:
> I guess it's the method lookup that's the slow part. Factor it out of the
> loop and measure again::
I did know of that optimization, but sometimes I "forget" about it...
The new timings:
Output timings, best of 3, unloaded CPU:
2.32 s with adict.get
1.56 s with "in"
[EMAIL PROTECTED]:
> Why not b = copyonwrite( a )?
> Subclass the interpreter-- make your own session.
Your idea may work, but I am talking about a new language (with some
small differences, not a revolution). Making such language efficient
enough may require to add some complex tricks, copy-on-wr
There is this site too, I have written many small programs for it:
http://www.codecodex.com/wiki/index.php?title=Main_Page
Bye,
bearophile
--
http://mail.python.org/mailman/listinfo/python-list
[EMAIL PROTECTED]:
> As for the original prooblem, why not use
> defaultdict? I think it's the most idiomatic way to achieve what we
> want. And also the fastest one, according to my quick-and-dirty tests:
It adds the new keys, I can't accept that:
>>> from collections import defaultdict as dd
>>
[EMAIL PROTECTED]:
> It's Unpythonic to compile a machine instruction out of a script. But
> maybe in the right situations, with the right constraints on a
> function, certain chunks could be native, almost like a mini-
> compilation. How much machine instruction do you want to support?
This lan
Steven D'Aprano:
> Usability for beginners is a good thing, but not at the expense of
> teaching them the right way to do things. Insisting on explicit requests
> before copying data is a *good* thing. If it's a gotcha for newbies,
> that's just a sign that newbies don't know the Right Way from the
Steven D'Aprano:
>the readability of your posts will increase a LOT if you break it up into
>paragraphs,<
You are right, I'll try to do it (when I go in flux state I write
quickly, but I tend to produce long paragraphs).
>The thing is, make-another-copy and make-another-reference are semantica
So far in Python I've almost hated the 'else' of the 'for' loops:
- I have problems to remember its meaning;
- It gives me little problems when I later want to translate Python
code to other languages (and you always have to translate long-lived
code).
- I have used it only once, so far.
So so far
Raymond HettInger:
> FWIW, I'm very happy with for-else. Most of the time, you don't need
> it, but when you do, it beats the heck out of doing silly tricks with
> flags.
I'd like it to be renamed to something more natural :-)
Bye,
bearophile
--
http://mail.python.org/mailman/listinfo/python-li
apatheticagnostic:
> I swear, this is one of the most polite-oriented groups I've ever
> seen.
> Not that that's a bad thing or anything, it's nice to be nice.
Yep, and with lot more work it may even become a bit fit for women/
females too.
Bye,
bearophile
--
http://mail.python.org/mailman/listi
On Mar 5, 10:44 pm, "Troels Thomsen" wrote:
> > The primary use case is searching a container:
>
> > prep_tasks()
> > for item in container:
> > if predicate(item):
> > found_tasks()
> > break
> > else:
> > not_found_tasks()
> > follow_up_tasks
>
> I've foun
Troels Thomsen:
> The discussion of words is silly. My surprise about "else following a for
> loop what the heck " lasted excactly as long as it takes to read
> this sentence.
Maybe I don't follow what you are saying, but well chosen words are a
very important part of a well designed API.
I find itertools.islice() useful, so for Python 3.x I may like to see
it removed from the itertools module, and the normal slicing syntax
[::] extended to work with generators/iterators too.
from itertools import islice
primes = (x for x in xrange(1,999) if all(x % y for y in xrange(2,
x)))
print
George Sakkis:
> I had posted some time ago an OO wrapper of itertools; slice notation
> for islice was one
> motivation:http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/498272
I think I did see that, but later I forgot of it. It looks nice.
Thank you,
bearophile
--
http://mail.python.org
Their efficiency is mostly regarding the space. I think they aren't
much speed-efficient because they require many conversions from-to
Python types.
You can gain speed efficiency too (sometimes a LOT), in some
situations, using array with Psyco.
Another advantage of arrays (better called "vector"s,
It seems the development of Cython is going very well, quite
differently from the dead-looking Pyrex. Hopefully Cython will become
more user-friendly too (Pyrex is far from being user-friendly for
Windows users, it doesn't even contain a compiler, I think. The
ShedSkin Windows installer contains an
Tim Golden:
> I'm not entirely sure why you think Pyrex should "contain a compiler".
I think lot of Win users (computational biologists?), even people that
know how to write good Python code, don't even know how to install a C
compiler.
>I'm fairly sure it's fine with MingW<
(In the past?) I th
A PDF file, Embedding_Python_into_Counter-Strike:
http://us.pycon.org/common/2008/talkdata/PyCon2008/020/Case_Study_-_Embedding_Python_into_Counter-Strike_Source.pdf
It talks about some problems too.
Bye,
bearophile
--
http://mail.python.org/mailman/listinfo/python-list
Paul Rubin:
> Python needs more stuff in its stdlib, not less.
> If Tkinter doesn't satisfy, then add Gtk (or whatever) to the standard
> distro. If that happens (i.e. some new toolkit is brought in and
> declared to be the standard) then it might be ok to drop Tkinter but
> it certainly shouldn't
[EMAIL PROTECTED]:
> >>> a=filter ( lambda b: b != None, a)
With None it's better to use is/not is instead of ==/!=
Bye,
bearophile
--
http://mail.python.org/mailman/listinfo/python-list
Ricky Zhou:
> Look at the this line:
> if 'one' and 'two' in f:
Very cute, it's the first time I see a bug like this. I think it's not
a common enough pattern to justify a language change, but a bit
smarter computer language may be able to do that too ;-) (it's not
easy to tell the two meaning
bearophile:
> A more computer-friendly (and Pythonic) syntax may be ('are' is a keyword):
Sorry for causing confusion, I was just thinking aloud. English isn't
my first language, and sometimes I slip a bit. Replace that with:
> A more computer-friendly (and Pythonic) syntax may be ('are' is meant
Yatsek:
> Is there simple way to copy a into b (like a[:]) with all copies of
> all objects going as deep as possible?
If you only want to copy up to level-2, then you can do something
like:
cloned = [subl[:] for subl in somelist]
Or sometimes safer:
cloned = [list(subl) for subl in somelist]
If
ernesto:
best = list(test)
may be faster than:
best = [x for x in test]
Bye,
bearophile
--
http://mail.python.org/mailman/listinfo/python-list
Paul Rubin>It's at least pretty good. It's not ideal, but nothing
ever is.<
I agree. At the moment Python is among the best languages for that,
but it's not perfect for that purpose. I think newbies may need a bit
more structured language, where you have to put things in a certain
order to have a
Kelly Greer:
> What is the best way to filter a Python list to its unique members?
If Python is "batteries included", then an industrial-strength
unique() seems one of the most requested 'batteries' that's not
included :-) I feel that it's coming in Python 2.6/3.x. In the
meantime:
http://aspn.act
dmitrey:
> As I have mentioned, I don't know final length of the list, but
> usually I know a good approximation, for example 400.
There is no reserve()-like method, but this is a fast enough operation
you can do at the beginning:
l = [None] * 400
It may speed up your code, but the final resizin
Sean Davis>Java has a BitSet class that keeps this kind of thing
pretty clean and high-level, but I haven't seen anything like it for
python.<
If you look around you can usually find Python code able to do most of
the things you want, like (you can modify this code to add the boolean
operations):
dmitrey:
> As I have mentioned, I don't know final length of the list, but
> usually I know a good approximation, for example 400.
You may want to use collections.deque too, it doesn't produce a Python
list, but it's quite fast in appending (it's a linked list of small
arrays).
Bye,
bearophile
--
Michał Bentkowski:
> Why does python create a reference here, not just copy the variable?
I think to increase performance, in memory used and running time (and
to have a very uniform way of managing objects).
Bye,
bearophile
--
http://mail.python.org/mailman/listinfo/python-list
On Mar 27, 3:54 pm, [EMAIL PROTECTED] wrote:
> Writing Tkinter menu code used to be rather tedious, uninspiring work.
> I figured that I could delegate the job to a program:
I did develop a proggy that takes the following as input, it's part of
my "agui" project, you can use it as an idea to impro
Diez B. Roggisch:
> the author says that the approach is flawed, so at *some*
> point it will be discontinued.
Can't Psyco be improved, so it can compile things like:
nums = (i for i in xrange(20) if i % 2)
print sum(nums)
I think the current Psyco runs slower than Python with generators/
it
[EMAIL PROTECTED]:
> Mine does less. But you tell it less to do it.
Some of those fields are optional :-)
Bye,
bearophile
--
http://mail.python.org/mailman/listinfo/python-list
Duncan Booth:
> Both this and raj's suggestion create a single sorted list. Your suggestion
> creates two lists: the unsorted one and a separate sorted one. In most
> cases the difference is probably insignificant, but if you have a *lot* of
> values it might make a difference.
The good thing of P
Scott David Daniels:
> if checking:
> my_var = 'string'
> else:
> my_var = 'other string'
>
> remember, vertical space only kills trees if printed.
I value clarity a lot. But this is more DRY, sometimes it's almost
equally clear, and you reduce vertical space, packi
Raymond Hettinger:
> Thought you guys might enjoy this:
> http://code.activestate.com/recipes/576615/
Nice and short, but it's also very slow on my PC (Psyco may help).
This solves them in moments:
http://labix.org/python-constraint
Bye,
bearophile
--
http://mail.python.org/mailman/listinfo/p
mario ruggier, that's a hack that you can forget. Your code can't be
read. Don't use list comps for that purpose. Write code that can be
read.
Bye,
bearophile
--
http://mail.python.org/mailman/listinfo/python-list
Raymond Hettinger:
> for simple programs that take minutes to write and get the job done.
For fun here's a specific example:
from csp import Problem, timing
print "SEND+MORE=MONEY problem:"
p = Problem("recursivebacktracking")
p.addvars("sendmory", range(10))
p.addrule(lambda d,e,y: (d+e)%10 == y
Matimus, your suggestions are all good.
Try-except is slower than:
if x in adict: ... else: ...
A defaultdict is generally faster (there are some conditions when it's
not faster, but they aren't much common. I think it's when the ratio
of duplicates is really low), creating just a tuple instead of
Terry Reedy:
>It illustrates well the point you intended.
I don't know what my point was.
A suggestion: with that solver, to find solution in a faster way you
have to write many equations.
Bye,
bearophile
--
http://mail.python.org/mailman/listinfo/python-list
r:
>Of course it would not run in C or Python but the point here is readability.<
With languages like Genie you can go close:
http://live.gnome.org/Genie
Or better Delight (based on the D language), plus some my "Python
compatibility" libs (plus Pyd, if you want) you can run that code:
http://del
alex23:
> Paul, have you looked into Cython at all?
I can also suggest ShedSkin and the D language.
I have often used D for data munging, producing quick & short
programs, when Python isn't fast enough for a certain purpose.
Bye,
bearophile
--
http://mail.python.org/mailman/listinfo/python-list
Michele Simionato:
> I don't like that. Scala was designed with the idea of putting
> together the two worlds, by I think the result was to get the
> complications of both worlds.
But some other people may like it, and it's a design experiment worth
doing. Every programming paradigm has advantage
AlienBaby:
> PIL looked promising, but I couldn't see how to put text into the
> image once loaded.
A 15-second long Google search gives me:
http://nedbatchelder.com/blog/200801/truly_transparent_text_with_pil.html
Bye,
bearophile
--
http://mail.python.org/mailman/listinfo/python-list
FogleBird:
> a.count(3.14)
If the values to count are approximated FP values, then you may need
something more complex, like:
leniter(ifilter(somefunction, a))
Where somefunction uses an approximated comparison, and leniter is
just a function that counts the items of a generic iterator.
Bye,
be
I use the Python shell daily, plus of course normal editors to edit
python scripts. They both are very useful for different purposes. But
the default interactive shell isn't much handy if you want to modify
the past code to run it again, or you want to embed a bit of text in
the code, or if you wan
Ben Finney:
> Adding an editor to Python solves this problem only for Python.
I'm sure that once such "editor" (I use the word editor for lack of a
better term) is created, it can also be quickly adapted with other
dynamic languages, like Ruby, TCL, Lua, Io, Perl, Awk, ecc. Probably
it can't be a
601 - 700 of 1196 matches
Mail list logo
