Re: popen2
Grant Edwards a écrit :
> On 2005-10-29, Piet van Oostrum <[EMAIL PROTECTED]> wrote:
>
>>>"g.franzkowiak" <[EMAIL PROTECTED]> (gf) wrote:
>>
>>>gf> If starts a process with popen2.popen3('myprogram') and myprogram.exe is
>>>gf> running before, I've a connection to the second process, not to the
>>>first.
>>>gf> I can find the process by name before I start a process with popen2...,
>>>gf> but how bcan I connect t this process with a pipe ?
>>
>>You have to use a named pipe.
>
>
> That would require that the application know about the named
> pipe and open it. I don't think there is any way to swap a
> pipe in for stdin/stdout once a process is running.
>
in C: freopen
--
http://mail.python.org/mailman/listinfo/python-list
Re: For American numbers
Peter Hansen wrote: Scott David Daniels wrote: Kind of fun exercise (no good for British English). def units(value, units='bytes'): magnitude = abs(value) if magnitude >= 1000: for prefix in ['kilo mega giga tera peta ' 'exa zetta yotta').split(): magnitude /= 1000. if magnitude < 1000.: break Only for hard drive manufacturers, perhaps. For the rest of the computer world, unless I've missed a changing of the guard or something, "kilo" is 1024 and "mega" is 1024*1024 and so forth... -Peter even for cpu frequency? -- http://mail.python.org/mailman/listinfo/python-list
Re: PIL cutting off letters
Matt Haggard a écrit : > I'm using PIL (Python Imaging Library) to generate button images. > They consist of a left end image, a middle, repeating image and a > right side image anyway, that's not important > > I'm using a TTF font for the text of the button (Verdana.TTF) and it > keeps cutting the bottom part of the the g's q's and y's off. hello may be the problem is in your code, but it is also possibly in PIL which clips caracters at the top and bottom line; that's not the typographic names, but these are *font* values, not characters ones. There are fonts with caracters far higher than these conventionnal lines (try Liorah.ttf or any swashed font for exemple)! I don't remember for sure but may be there is the same problem horizontally. -- Pierre -- http://mail.python.org/mailman/listinfo/python-list
PEP 3131: Ascii-English is like coca-cola!
This pep is not technical, or at least not only. It has larger implications about society model we want. Let me explain with an analogy: let's compare 'ascii english' to coca-cola. It's available nearly everywhere. It does not taste good at first try, and is especially repulsive to young children. It's cheap and you don't expect much of it. You know you can drink some in case of real need. It's imperialist connotation is widely accepted(?) But it's not good as your favorite beverage, beer, wine, ... The world is full of other possibilities. Think, in case of necessity you could even have to drink tea with yack butter in himalaya! in normal circonstances, you should never see any, but in extreme situation you may have to! Were is freedom in such a world you could only drink coca? I DON'T WANT TO HAVE TO DRINK COCA AT HOME ALL THE TIME. and this pep is a glorious occasion to get free from it. [disclaimer: coca is used here as the generic name it became, and no real offense is intended] -- Pierre -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 3131: Supporting Non-ASCII Identifiers
René Fleschenberg a écrit : > IMO, the burden of proof is on you. If this PEP has the potential to > introduce another hindrance for code-sharing, the supporters of this PEP > should be required to provide a "damn good reason" for doing so. So far, > you have failed to do that, in my opinion. All you have presented are > vague notions of rare and isolated use-cases. you want to limit my liberty of using appealing names in my language. this alone should be enough to accept the pep! -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 3131: Supporting Non-ASCII Identifiers
René Fleschenberg a écrit : > Your example does not prove much. The fact that some people use > non-ASCII identifiers when they can does not at all prove that it would > be a serious problem for them if they could not. > i have to make orthograph mistakes in my code to please you? -- Pierre -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 3131: Supporting Non-ASCII Identifiers
hello i work for a large phone maker, and for a long time we thought, very arrogantly, our phones would be ok for the whole world. After all, using a phone uses so little words, and some of them where even replaced with pictograms! every body should be able to understand appel, bis, renvoi, mévo, ... nowdays we make chinese, corean, japanese talking phones. because we can do it, because graphics are cheaper than they were, because it augments our market. (also because some markets require it) see the analogy? of course, +1 for the pep -- Pierre -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 3131: Supporting Non-ASCII Identifiers
[EMAIL PROTECTED] a écrit : > On May 15, 3:28 pm, René Fleschenberg <[EMAIL PROTECTED]> wrote: >> We all know what the PEP is about (we can read). The point is: If we do >> not *need* non-English/ASCII identifiers, we do not need the PEP. If the >> PEP does not solve an actual *problem* and still introduces some >> potential for *new* problems, it should be rejected. So far, the >> "problem" seems to just not exist. The burden of proof is on those who >> support the PEP. it *does* solve a huge problem: i have to use degenerate french, with orthographic mistakes, or select in a small subset of words to use only ascii. I'm limited in my expression, and I ressent this everyday! This is true, even if commercial french programmers don't object the pep because they have to use english in their own work. This is something i really cannot understand. it's a problem of everyday, for million people! and yes sometimes i publish code (rarely), even if it uses french identifiers, because someone looking after a real solution *does* prefer an existing solution than nothing. -- Pierre -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
Carl Banks a écrit : > > This is starting to sound silly, people. Critical is a relative term, > and one project's critical may be anothers mundane. Sure a flaw in your > flagship product is a critical problem *for your company*, but are you > really trying to say that the criticalness of a bad web search is even > comparable to the most important systems on airplanes, nuclear reactors, > dams, and so on? Come on. 20 years ago, there was *no* computer at all in nuclear reactors. -- http://mail.python.org/mailman/listinfo/python-list
Re: Which SOAP module?
Ralf Schoenian a écrit : > Roy Smith wrote: >> I'm starting to play with SOAP. The zeroth question that needs >> answering is, "Which SOAP module should I use?" There seem to be a >> number of different ones to pick from. Any suggestions? >> >> > It depends on whether you want to write a client or a server > application. If you only want to write a client I found suds ( > https://fedorahosted.org/suds/ ) very helpful. It is actively developed > and the documentation is comprehensive. +1 for suds -- http://mail.python.org/mailman/listinfo/python-list
simplejson: alternate encoder not called enought
hello I'm trying to use simplejson to encode some python objects using simplejson dumps method. The dumps method accept a cls parameter to specify an alternate encoder. But it seems that this alternate encoder is called only as a last resort, if object type is not int, string, and all other basic types. My problem is that i wanted to specify an encoding for a dbus.Boolean object which inherits from int. As int is handled by the standard encoder, the alternate encoder is never called and a dbus.Boolean is converted to 0 or 1 instead of true or false. Could someone knowledgeabled enought confirm my diagnostic? thanks in advance -- Pierre -- http://mail.python.org/mailman/listinfo/python-list
