Re: #define (from C) in Python

On Fri, 13 Nov 2009 08:43:14 -, Ulrich Eckhardt wrote: Santiago Romero wrote: Well, In the above concrete example, that would work, but I was talking for multiple code lines, like: #define LD_r_n(reg) (reg) = Z80ReadMem(r_PC++) #define LD_rr_nn(reg) r_opl = Z80ReadMem(r_PC); r_PC++;

Re: tkFileDialog question

On Nov 13, 2:47 pm, "Matt Mitchell" wrote: > --- > The information contained in this electronic message and any attached > document(s) is intended only for the personal and confidential use of the > designated recipients named above. This message may be confidenti

Re: python simply not scaleable enough for google?

On 2009-11-13, at 17:42, Robert Brown wrote, quoting me: > ... Python *the language* is specified in a way that > makes executing Python programs quickly very very difficult. That is untrue. I have mentioned before that optional declarations integrate well with dynamic languages. Apart from C

Re: tkFileDialog question

Opps, i see you answered your own question ;-) To save you more hours of Googling take a look at these two sites! #great reference http://infohost.nmt.edu/tcc/help/pubs/tkinter/ #more in-depth http://effbot.org/tkinterbook/ you'll want to keep them both under your pillow. -- http://mail.python

Re: python simply not scaleable enough for google?

On Fri, Nov 13, 2009 at 3:32 PM, Paul Rubin wrote: > ...  This is Usenet so > please stick with Usenet practices.  If you want a web forum there are > plenty of them out there. Actually this is python-list@python.org I don't use usenet and I have no intention to stic

Re: python simply not scaleable enough for google?

On 2009-11-13, at 18:02, Robert Brown wrote: > Common Lisp and Scheme were designed by people who wanted to write complicated > systems on machines with a tiny fraction of the horsepower of current > workstations. They were carefully designed to be compiled efficiently, which > is not the case wi

Re: python simply not scaleable enough for google?

Vincent Manis writes: > 3. I'm on the python-list mailing list, reading this with Apple's > Mail application, which actually doesn't have convenient ways of > enforcing `Usenet practices' regarding message format. Oh, I see. Damn gateway. > Stephen asked me to wrap my posts. I'm happy to do it.

Re: Python & Go

Duncan Booth writes: > > Haskell handles lookups through its type system; dealing with > > lookup errors (say by chaining the Maybe type) is clean and elegant. > I said exceptions or any other method of error handling. I think the use of an option type (like Maybe) is pretty standard and works fi

Re: Writing an emulator in python - implementation questions (for performance)

Santiago Romero wrote: Can the above be easily done with another already-existing application? (example: can m4 do this job)? The problem you're going to have with something like m4 is indentation. When you inline a function call, somehow the inserted code has to be shifted to the same indent

Re: python simply not scaleable enough for google?

"Robert P. J. Day" writes: > http://groups.google.com/group/unladen-swallow/browse_thread/thread/4edbc406f544643e?pli=1 > thoughts? I'd bet it's not just about multicore scaling and general efficiency, but also the suitability of the language itself for large, complex projects. It's just not p

Re: Python & Go

On Nov 14, 4:38 am, Paul Rubin wrote: > It seems a little weird to me that they (Google) are concerned with > the speed of the compiler, indicating that they plan to write enormous > programs in the language.  I've heard they use a 1000-node cluster to > compile their

Re: Choosing GUI Module for Python

In article , Antony wrote: > > I just wanted to know which module is best for developing designing >interface in python . Haven't tried it, but a new release was just announced for this: http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/ -- Aahz (a...@pythoncraft.com) <*>

the unicode saga continues...

So I've added unicode support to my dbf package, but I also have some rather large programs that aren't ready to make the switch over yet. So as a workaround I added a (rather lame) option to convert the unicode-ified data that was decoded from the dbf table back into an encoded format. Here

Re: 2.6.4 Mac x86_64 ?

On Nov 13, 2009, at 3:58 PM, chris grebeldinger wrote: > Hi All, > I've been having some trouble getting a x86_64/i386 universal > readline.so to build against libedit, on MacOS 10.5.6 as Apple does. > Does anyone have any pointers about what changes I need to make to > setup.py or readline.c to a

Re: python simply not scaleable enough for google?

On 2009-11-13, at 19:53, Paul Rubin wrote: > "Robert P. J. Day" writes: >> http://groups.google.com/group/unladen-swallow/browse_thread/thread/4edbc406f544643e?pli=1 >> thoughts? > > I'd bet it's not just about multicore scaling and general efficiency, > but also the suitability of the language

Re: the unicode saga continues...

"Ethan Furman" wrote in message news:4afe4141.4020...@stoneleaf.us... So I've added unicode support to my dbf package, but I also have some rather large programs that aren't ready to make the switch over yet. So as a workaround I added a (rather lame) option to convert the unicode-ified dat

Re: python simply not scaleable enough for google?

* Rami Chowdhury: On Thu, 12 Nov 2009 12:02:11 -0800, Alf P. Steinbach wrote: I think that was in the part you *snipped* here. Just fill in the mentioned qualifications and weasel words. OK, sure. I don't think they're weasel words, because I find them useful, but I think I see where you're

Re: python simply not scaleable enough for google?

Vincent Manis writes: > On 2009-11-13, at 17:42, Robert Brown wrote, quoting me: >> ... Python *the language* is specified in a way that >> makes executing Python programs quickly very very difficult. > That is untrue. I have mentioned before that optional declarations integrate > well with

Re: python simply not scaleable enough for google?

On 2009-11-13, at 22:51, Alf P. Steinbach wrote: > It's sort of hilarious. It really is, see below. > So no, it's not a language that is slow, it's of course only concrete > implementations that may have slowness flavoring. And no, not really, they > don't, because it's just particular aspects

Re: the unicode saga continues...

Ethan Furman wrote: > Python 2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit > (Intel)] on win32 > Type "help", "copyright", "credits" or "license" for more information. > >>> print u'\xed' > í > >>> print u'\xed'.encode('cp437') > í > >>> print u'\xed'.encode('cp850') > í > >>> pr

python-daemonize and upstart

I'm experimenting with the daemon module and upstart . There's something I don't understand, which may be more of an upstart issue than a python issue, but I thought I'd start by posting here. Here's a test script: #!/usr/bi

Re: python simply not scaleable enough for google?

Vincent Manis writes: > On 2009-11-13, at 18:02, Robert Brown wrote: > >> Common Lisp and Scheme were designed by people who wanted to write >> complicated systems on machines with a tiny fraction of the horsepower of >> current workstations. They were carefully designed to be compiled >> effic

Re: python simply not scaleable enough for google?

On 14 Nov, 08:39, Robert Brown wrote: > > Using Python 3 annotations, one can imagine a Python compiler that does the > > appropriate thing (shown in the comments) with the following code. > > I can imagine a lot too, but we're talking about Python as it's specified > *today*.  The Python languag

<    1   2