Re: when "normal" parallel computations in CPython will be implemented at last?
Thomas Jollans wrote:
>There is, of course, Stackless Python.
>http://stackless.com/
Stackless Python doesn't really address the original poster's problem
as the GIL still effectively limits Python code running in one thread
at a time.
Ross Ridge
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] rri...@csclub.uwaterloo.ca
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //
--
http://mail.python.org/mailman/listinfo/python-list
Re: How to safely maintain a status file
Laszlo Nagy:
> This is not a contradiction. Although the rename operation is atomic,
> the whole "change status" process is not. It is because there are two
> operations: #1 delete old status file and #2. rename the new status
> file. And because there are two operations, there is still a race
> condition. I see no contradiction here.
Christian Heimes wrote:
>Sorry, but you are wrong. It's just one operation that boils down to
>"point name to a different inode".
For some reason you're assuming POSIX semantics, an assumption that
Laszlo Nagy did not make.
Ross Ridge
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] rri...@csclub.uwaterloo.ca
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //
--
http://mail.python.org/mailman/listinfo/python-list
Re: the meaning of rï¾.......��
Roy Smith wrote:
>When I first started writing C code, it was on ASR-33s which did not
>support curly baces. We wrote ÃÂ¥( for { and ÃÂ¥) for } (although I think the
>translation was
>handled entirely in the TTY driver and the compiler was never in on the
>joke). 20 or 30 years from now, people are going to look back on us
>neanderthals and laugh about how we had to write r''.
No, it's not going to change in 20 or 30 years. The ASR-33 Teletype
was pretty much obsolete by the time C escaped Bell Labs. You were
programming in a 70's language using early 60's technology and suffered
accordingly. Today, the technology to support "Unicode" operators in
programming langauges is both widespread and has existed for a long
time now. I'm sure you've heard of APL, which both predates Unicode and
C and is almost old as the ASR-33. If any one actually wanted another
programming language like this it would've come into existance 20 or 30
years ago not 20 or 30 years from now.
Python actually choose to go the other direction and choose to use
keywords as operators instead of symbols in a number of instances.
Ross Ridge
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] rri...@csclub.uwaterloo.ca
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //
--
http://mail.python.org/mailman/listinfo/python-list
Re: the meaning of rï¾â¢.......ï¾
Steven D'Aprano wrote:
>Hey, if the Japanese and Chinese can manage it, English speakers can
>surely find a way to enter àor â without a keyboard the size of a
>battleship.
Japanese and Chinese programmers don't use (and don't seem to want to)
use non-ASCII characters outside of strings and comments even when the
language (supposedly) allows it.
Ross Ridge
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] rri...@csclub.uwaterloo.ca
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //
--
http://mail.python.org/mailman/listinfo/python-list
Re: from future import pass_function
Ulrich Eckhardt wrote:
> I just had an idea, it occurred to me that the pass statement is pretty
> similar to the print statement,
[...]
> try:
> do_something()
> except:
> pass()
Steven D'Aprano wrote:
>What's the point of this?
Remember everything you've said about why its a good thing the that
print statement is now a function? That.
Ross Ridge
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] rri...@csclub.uwaterloo.ca
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //
--
http://mail.python.org/mailman/listinfo/python-list
Re: from future import pass_function
Steven D'Aprano wrote: >What's the point of this? Ross Ridge wrote: > Remember everything you've said about why its a good thing the that > print statement is now a function? That. Steven D'Aprano wrote: >I can't believe I actually have to point this out explicitly, but pass is >not print. Apart from them both starting with the letter "P", they are >nothing alike. There are good reasons for making print a function, and >they don't apply to pass because pass doesn't do what print does. No, they're very much alike. That's why all your arguments for print as function also apply just as well to pass a function. Your arguments had very little to do what what print actually did. Ross Ridge -- l/ // Ross Ridge -- The Great HTMU [oo][oo] rri...@csclub.uwaterloo.ca -()-/()/ http://www.csclub.uwaterloo.ca/~rridge/ db // -- http://mail.python.org/mailman/listinfo/python-list
Re: from future import pass_function
Ross Ridge wrote:
> No, they're very much alike. That's why all your arguments for print
> as function also apply just as well to pass a function. Your arguments
> had very little to do what what print actually did.
Chris Angelico wrote:
>Except that print / print() is executable. Execution proceeds through
>your code, comes to a "print", and goes off to handle that, then comes
>back to your code. But "pass" doesn't have code attached to it. Why
>should it be a function?
For consistancy with print. What it does doesn't matter any more than
what print did mattered.
Ross Ridge
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] rri...@csclub.uwaterloo.ca
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //
--
http://mail.python.org/mailman/listinfo/python-list
Re: String manipulation in python..NEED HELP!!!!
John Gordon wrote:
> def encode(plain):
> '''Return a substituted version of the plain text.'''
> encoded = ''
> for ch in plain:
>encoded += key[alpha.index(ch)]
> return encoded
Terry Reedy wrote:
>The turns an O(n) problem into a slow O(n*n) solution. Much better to
>build a list of chars and then join them.
There have been much better suggestions in this thread, but John Gordon's
code above is faster than the equivilent list and join implementation
with Python 2.6 and Python 3.1 (the newest versions I have handy).
CPython optimized this case of string concatenation into O(n) back in
Python 2.4.
Ross Ridge
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] rri...@csclub.uwaterloo.ca
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //
--
http://mail.python.org/mailman/listinfo/python-list
Re: XSLT to Python script conversion?
Matej Cepl wrote:
>No, the strangness is not that bad (well, it is bad ... almost anything
>feels bad comparing to Python, to be honest, but not the reason I would
>give up; after all I spent couple of years with Javascript).
The XSLT language is one of the worst misuses of XML, which puts it way
beyond bad.
>The terrible debugging is one thing, and even worse, I just still cannot
>get over rules around spaces: whitespace just jumps at me randomly in
>random places and is erased in others.
I use explicit nodes exclusively to avoid this problem.
Ross Ridge
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] rri...@csclub.uwaterloo.ca
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //
--
http://mail.python.org/mailman/listinfo/python-list
Re: XSLT to Python script conversion?
Ross Ridge writes:
> The XSLT language is one of the worst misuses of XML, which puts it way
> beyond bad.
Stefan Behnel wrote:
>Clearly a matter of opinion.
No. There's no excuse for using XML as the syntax of a language like
XLST.
Ross Ridge
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] rri...@csclub.uwaterloo.ca
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //
--
http://mail.python.org/mailman/listinfo/python-list
Re: "convert" string to bytes without changing data (encoding)
Chris Angelico wrote:
>What is a string? It's not a series of bytes.
Of course it is. Conceptually you're not supposed to think of it that
way, but a string is stored in memory as a series of bytes.
What he's asking for many not be very useful or practical, but if that's
your problem here than then that's what you should be addressing, not
pretending that it's fundamentally impossible.
Ross Ridge
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] rri...@csclub.uwaterloo.ca
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //
--
http://mail.python.org/mailman/listinfo/python-list
Re: "convert" string to bytes without changing data (encoding)
Ross Ridge wr= > Of course it is. =A0Conceptually you're not supposed to think of it that > way, but a string is stored in memory as a series of bytes. Chris Angelico wrote: >Note that distinction. I said that a string "is not" a series of >bytes; you say that it "is stored" as bytes. The distinction is meaningless. I'm not going argue with you about what you or I ment by the word "is". >But a Python Unicode string might be stored in several >ways; for all you know, it might actually be stored as a sequence of >apples in a refrigerator, just as long as they can be referenced >correctly. But it is in fact only stored in one particular way, as a series of bytes. >There's no logical Python way to turn that into a series of bytes. Nonsense. Play all the semantic games you want, it already is a series of bytes. Ross Ridge -- l/ // Ross Ridge -- The Great HTMU [oo][oo] rri...@csclub.uwaterloo.ca -()-/()/ http://www.csclub.uwaterloo.ca/~rridge/ db // -- http://mail.python.org/mailman/listinfo/python-list
Re: "convert" string to bytes without changing data (encoding)
Steven D'Aprano wrote:
>The right way to convert bytes to strings, and vice versa, is via
>encoding and decoding operations.
If you want to dictate to the original poster the correct way to do
things then you don't need to do anything more that. You don't need to
pretend like Chris Angelico that there's isn't a direct mapping from
the his Python 3 implementation's internal respresentation of strings
to bytes in order to label what he's asking for as being "silly".
Ross Ridge
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] rri...@csclub.uwaterloo.ca
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //
--
http://mail.python.org/mailman/listinfo/python-list
Re: "convert" string to bytes without changing data (encoding)
Tim Chase wrote:
>Internally, they're a series of bytes, but they are MEANINGLESS
>bytes unless you know how they are encoded internally. Those
>bytes could be UTF-8, UTF-16, UTF-32, or any of a number of other
>possible encodings[1]. If you get the internal byte stream,
>there's no way to meaningfully operate on it unless you also know
>how it's encoded (or you're willing to sacrifice the ability to
>reliably get the string back).
In practice the number of ways that CPython (the only Python 3
implementation) represents strings is much more limited. Pretending
otherwise really isn't helpful.
Still, if Chris Angelico had used your much less misleading explaination,
then this could've been resolved much quicker. The original poster
didn't buy Chris's bullshit for a minute, instead he had to find out on
his own that that the internal representation of strings wasn't what he
expected to be.
Ross Ridge
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] rri...@csclub.uwaterloo.ca
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //
--
http://mail.python.org/mailman/listinfo/python-list
Re: Re: "convert" string to bytes without changing data (encoding)
Evan Driscoll wrote:
>So yes, you can say that pretending there's not a mapping of strings to
>internal representation is silly, because there is. However, there's
>nothing you can say about that mapping.
I'm not the one labeling anything as being silly. I'm the one labeling
the things as bullshit, and that's what you're doing here. I can in
fact say what the internal byte string representation of strings is any
given build of Python 3. Just because I can't say what it would be in
an imaginary hypothetical implementation doesn't mean I can never say
anything about it.
Ross Ridge
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] rri...@csclub.uwaterloo.ca
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //
--
http://mail.python.org/mailman/listinfo/python-list
Re: Re: Re: "convert" string to bytes without changing data (encoding)
Evan Driscoll wrote:
>People like you -- who write to assumptions which are not even remotely
>guaranteed by the spec -- are part of the reason software sucks.
...
>This email is a bit harsher than it deserves -- but I feel not by much.
I don't see how you could feel the least bit justified. Well meaning,
if unhelpful, lies about the nature Python strings in order to try to
convince someone to follow what you think are good programming practices
is one thing. Maliciously lying about someone else's code that you've
never seen is another thing entirely.
Ross Ridge
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] rri...@csclub.uwaterloo.ca
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //
--
http://mail.python.org/mailman/listinfo/python-list
Re: Re: Re: "convert" string to bytes without changing data (encoding)
Chris Angelico wrote:
>Actually, he is justified. It's one thing to work in C or assembly and
>write code that depends on certain bit-pattern representations of data
>(although even that causes trouble - assuming that
>sizeof(int)=3D=3Dsizeof(int*) isn't good for portability), but in a high
>level language, you cannot assume any correlation between objects and
>bytes. Any code that depends on implementation details is risky.
How does that in anyway justify Evan Driscoll maliciously lying about
code he's never seen?
Ross Ridge
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] rri...@csclub.uwaterloo.ca
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //
--
http://mail.python.org/mailman/listinfo/python-list
Re: "convert" string to bytes without changing data (encoding)
Steven D'Aprano wrote: >Your reaction is to make an equally unjustified estimate of Evan's >mindset, namely that he is not just wrong about you, but *deliberately >and maliciously* lying about you in the full knowledge that he is wrong. No, Evan in his own words admitted that his post was ment to be harsh, "a bit harsher than it deserves", showing his malicious intent. He made accusations that where neither supported by anything I've said in this thread nor by the code I actually write. His accusation about me were completely made up, he was not telling the truth and had no reasonable basis to beleive he was telling the truth. He was malicously lying and I'm completely justified in saying so. Just to make it clear to all you zealots. I've not once advocated writing any sort "risky code" in this thread. I have not once advocated writing any style of code in thread. Just because I refuse to drink the "it's impossible to represent strings as a series of bytes" kool-aid does't mean that I'm a heretic that must oppose against everything you believe in. Ross Ridge -- l/ // Ross Ridge -- The Great HTMU [oo][oo] rri...@csclub.uwaterloo.ca -()-/()/ http://www.csclub.uwaterloo.ca/~rridge/ db // -- http://mail.python.org/mailman/listinfo/python-list
Re: "convert" string to bytes without changing data (encoding)
Ross Ridge wrote:
> Just because I refuse to drink the
> "it's impossible to represent strings as a series of bytes" kool-aid
Terry Reedy wrote:
>I do not believe *anyone* has made that claim. Is this meant to be a
>wild exaggeration? As wild as Evan's?
Sorry, it would've been more accurate to label the flavour of kool-aid
Chris Angelico was trying to push as "it's impossible ... without
encoding":
What is a string? It's not a series of bytes. You can't convert
it without encoding those characters into bytes in some way.
>In my first post on this thread, I made three truthful claims.
I'm not objecting to every post made in this thread. If your post had
been made before the original poster had figured it out on his own,
I would've hoped he would have found it much more convincing than what
I quoted above.
Ross Ridge
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] rri...@csclub.uwaterloo.ca
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //
--
http://mail.python.org/mailman/listinfo/python-list
Re: Newbie questions on import & cmd line run
Steven D'Aprano wrote:
>#! ("hash-bang") lines currently do nothing on Windows machines, they are
>just comments. However, on Unix and Linux machines (and Macintosh?) they
>are interpreted by the shell (equivalent to cmd.exe or command.com), in
>order to tell the shell what interpreter to use to execute the program if
>you run it directly.
They're actually interpreted by the kernel so that they'll work when
run from any program.
Ross Ridge
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] rri...@csclub.uwaterloo.ca
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //
--
http://mail.python.org/mailman/listinfo/python-list
Re: Smallest/cheapest possible Python platform?
Roy Smith wrote:
>What's the smallest/cheapest/lowest-power hardware platform I can run
>Python on today?
Not counting the Rasberry Pi, then probably a wireless router or one of
those cheap media streaming boxes running custom firmware.
>Performance requirements are minimal. I need to monitor a few switches,
>control a couple of LEDs and relays, and keep time over about a 30
>minute period to 1/10th second accuracy. Nice-to-have (but not
>essential) would be a speech synthesizer with a vocabulary of maybe 50
>words.
Unfortunately I don't think any of these devices would have the GPIO
pins you'd want for such a project.
>The Rasberry Pi certainly looks attractive, but isn't quite available
>today. Can you run Python on an Arduino? Things like
>http://www.embeddedarm.com/products/board-detail.php?product=TS-7250 are
>more than I need, and the $129 price probably busts my budget.
The Arduino uses an 8-bit micro-controller, so probably not. (The ARM
emulator based port of Linux probably doesn't meet your performance
requirements.)
I think you may need to either wait for the Rasberry Pi to become
generally available or increase your budget. You should also consider
whether any of these devices have Python bindings to interface with
their GPIO pins. If not you'll probably have to end up writing some C
code anyways.
Ross Ridge
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] rri...@csclub.uwaterloo.ca
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //
--
http://mail.python.org/mailman/listinfo/python-list
Re: can I distribute Microsoft.VC90.CRT files?
"J.O. Aho" wrote:
> Read the EULA that comes with Microsoft Visual C++ Redistributable Package.
Chaz wrote:
> PLEASE RESPOND WITH AN ANSWER NEXT TIME
READ THE EULA THAT COMES WITH THE MICROSOFT VISUAL C++ REDISTRIBUTABLE PACKAGE.
I hope that helps.
Ross Ridge
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] rri...@csclub.uwaterloo.ca
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //
--
http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Free software versus software idea patents (was: Python benefits over Cobra)
Steven D'Aprano wrote:
>Perhaps what you mean is, none of the licences granted are *irrevocable*.
>But the same applies to the GPL -- break the GPL's (generous) terms, and
>you too could find that your licence is revoked.
Actually, you could argue since the GPL doesn't meet the legal definition
of a contract, it can be revoked unilateraly (but not retroactively)
by the copyright holder at any time for any reason.
Ross Ridge
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] rri...@csclub.uwaterloo.ca
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //
--
http://mail.python.org/mailman/listinfo/python-list
Re: Speeding up Python's exit
Antoine Pitrou wrote:
>Now please read my message again. The OS buffers are *not* flushed according
>to POSIX.
POSIX says open *streams* might not be flushed. POSIX streams are C
FILE * streams and generally aren't regarded as being part of the OS.
When you call os._exit() in a Python program any unwritten data still
in Python's own file buffers will be lost. Any unwritten data still
in the C library's FILE * buffers will be lost. Any data successfuly
written through a POSIX file descriptor (eg. using the write() function)
will not be lost becasue os._exit() was used.
Note that this doesn't mean that OS buffers will flushed when os._exit()
is called. Data that hasn't yet been physically written to disk, hasn't
be successfully transmitted over the network, or otherwise hasn't been
fully comitted could still be lost. However, exiting Python normally
doesn't change this. Only the Python process's own internal buffers are
flushed, the OS doesn't change its handling of its buffers. If you want
written data to be fully committed before exiting you need to use other
OS services that guarantee this.
Ross Ridge
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] rri...@csclub.uwaterloo.ca
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //
--
http://mail.python.org/mailman/listinfo/python-list
Re: How to prevent tests from running against production?
Roy Smith wrote:
>Our deploy/configuration system includes credentials for connecting to a
>database. We have one production database, and a variety of clones of
>that in our test and development environments.
Having your tests use credentials that don't work in the production
environment would seem to be the obvious solution.
Ross Ridge
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] rri...@csclub.uwaterloo.ca
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //
--
http://mail.python.org/mailman/listinfo/python-list
Re: random shuffles
David G. Wonnacott wrote:
> Couldn't we easily get an n*log(n) shuffle...
Why are you trying to get an O(n*log(n)) shuffle when an O(n) shuffle
algorithim is well known and implemented in Python as random.shuffle()?
Ross Ridge
--
http://mail.python.org/mailman/listinfo/python-list
Re: Trouble compiling win32all on Windows
robert wrote:
> I've trouble compiling win32all. VC98 and latest SDK installed
> (otherwise with original SDK it won't even compile).
> It tells that uuid.lib(cguid_i.obj) : fatal error LNK1103: debug info
> is destroyed.
The library isn't compatable with the compiler you're using. You'll
need to use an older version of the Platform SDK that supports your
compiler.
Ross Ridge
--
http://mail.python.org/mailman/listinfo/python-list
Re: Exploiting Dual Core's with Py_NewInterpreter's separated GIL ?
Paul Rubin wrote: > I dunno about x86 hardware signals but these instructions do > read-modify-write operaitons. That means there has to be enough > interlocking to prevent two cpu's from updating the same memory > location simultaneously, which means the CPU's have to communicate. > See <http://en.wikipedia.org/wiki/MESI_protocol> (I think this is > how the current x86's do it): The MESI protocol is used to ensure all read and write operations are cache coherent, not just locked read-modify-write operations. Whether the LOCK prefix is used or not in an instruction normally isn't externally visable. From IA-32 Intel® Architecture Software Developer's Manual Volume 3A: System Programming Guide, Part 1: For the Pentium 4, Intel Xeon, and P6 family processors, if the area of memory being locked during a LOCK operation is cached in the processor that is performing the LOCK operation as write-back memory and is completely contained in a cache line, the processor may not assert the LOCK# signal on the bus. Instead, it will modify the memory location internally and allow it's cache coherency mechanism to insure that the operation is carried out atomically. This operation is called "cache locking." The cache coherency mechanism automatically prevents two or more processors that have cached the same area of memory from simultaneously modifying data in that area. The cost of mantaining cache coherency for a locked increment instruction should be no different than that of an unlocked increment instruction. Ross Ridge -- http://mail.python.org/mailman/listinfo/python-list
Re: Exploiting Dual Core's with Py_NewInterpreter's separated GIL ?
"Martin v. Löwis" <[EMAIL PROTECTED]> writes: > Ah, but in the case where the lock# signal is used, it's known that > the data is not in the cache of the CPU performing the lock operation; > I believe it is also known that the data is not in the cache of any > other CPU. So the CPU performing the LOCK INC sequence just has > to perform two memory cycles. No cache coherency protocol runs > in that case. Paul Rubin wrote: > How can any CPU know in advance that the data is not in the cache of > some other CPU? In the case where the LOCK# signal is asserted the area of memory accessed is marked as being uncachable. In a SMP system all CPUs must have the same mapping of cached and uncached memory or things like this break. In the case where the LOCK# signal isn't used, the MESI protocol informs the CPU of which of it's cache lines might also be in the cache of another CPU. > OK, this is logical, but it already implies a cache miss, which costs > many dozen (100?) cycles. But this case may be uncommon, since one > hops that cache misses are relatively rare. The cost of the cache miss is the same whether the increment instruction is locked or not. Ross Ridge -- http://mail.python.org/mailman/listinfo/python-list
Re: Exploiting Dual Core's with Py_NewInterpreter's separated GIL ?
Joe Seigh wrote:
> Basically there's a race condition where an object containing the
> refcount can be deleted between the time you load a pointer to
> the object and the time you increment what used to be a refcount
> and is possibly something else but definitely undefined.
That doesn't really make sense. The object can't be deleted because
the thread should already have a reference (directly or indirectly) to
the object, otherwise any access to it can cause the race condition you
describe.
Ross Ridge
--
http://mail.python.org/mailman/listinfo/python-list
Re: Exploiting Dual Core's with Py_NewInterpreter's separated GIL ?
Ross Ridge wrote:
> That doesn't really make sense. The object can't be deleted because
> the thread should already have a reference (directly or indirectly) to
> the object, otherwise any access to it can cause the race condition you
> describe.
Joe Seigh wrote:
> True but if the thread didn't already have a reference, how would you get
> that initial reference to a shared object without a lock?
The thread that shares it increments the reference count before passing
its address to directly another thread or indirectly through a shared
container.
Ross Ridge
--
http://mail.python.org/mailman/listinfo/python-list
Re: Exploiting Dual Core's with Py_NewInterpreter's separated GIL ?
Martin v. Löwis wrote:
> How would you propose to fix file_repr to prevent such
> a race condition?
The race condition you describe is different from the one Joe Seigh
described. It's caused because without GIL access to the file object
is no longer thread safe, not because reference counting isn't thread
safe.
Ross Ridge
--
http://mail.python.org/mailman/listinfo/python-list
Re: Exploiting Dual Core's with Py_NewInterpreter's separated GIL ?
Martin v. Löwis wrote: > How would you propose to fix file_repr to prevent such > a race condition? Ross Ridge schrieb: > The race condition you describe is different from the one Joe Seigh > described. It's caused because without GIL access to the file object > is no longer thread safe, not because reference counting isn't thread > safe. Martin v. Löwis wrote: > Joe's claim (quoting him) was: "Atomic increment and decrement > instructions are not by themselves sufficient to make reference > counting safe." So give an example where reference counting is unsafe. Remember that I only said that Joe Seigh's statement didn't make sense, not that I had some magic solution that would somehow make Python thread safe without locking. Ross Ridge -- http://mail.python.org/mailman/listinfo/python-list
Re: Exploiting Dual Core's with Py_NewInterpreter's separated GIL ?
Ross Ridge schrieb: > So give an example where reference counting is unsafe. Martin v. Löwis wrote: > Nobody claimed that, in that thread. Instead, the claim was > "Atomic increment and decrement instructions are not by themselves > sufficient to make reference counting safe." So give an example of where atomic increment and decrement instructions are not by themselves sufficent to make reference counting safe. > I did give an example, in <[EMAIL PROTECTED]>. > Even though f_name is reference-counted, it might happen that you get a > dangling pointer. Your example is of how access to the "f_name" member is unsafe, not of how reference counting being unsafe. The same sort of race condition can without reference counting being involved at all. Consider the "f_fp" member: if one thread tries to use "printf()" on it while another thread calls "fclose()", then you can have same problem. The race condition here doesn't happen because reference counting hasn't been made safe, nor does it happen because stdio isn't thread-safe. It happens because accessing "f_fp" (without the GIL) is unsafe. The problem your describing isn't that reference counting hasn't been made safe. What you and Joe seem to be trying to say is that atomic increment and decrement instructions alone don't make accessing shared structure members safe. Ross Ridge -- http://mail.python.org/mailman/listinfo/python-list
Re: XBox 360 free SDK (XNA) and IronPython
[EMAIL PROTECTED] wrote:
> Just for information I just read this BBC article about the free (as in
> beer) SDK for XBOX 360 called XNA :
It's actually called the XNA Framework, and the beta only supports
Windows. The XBox 360 won't be supported until it's released.
> and saw here an example of someone using IronPython:
IronPython won't work on the XBox 360.
Ross Ridge
--
http://mail.python.org/mailman/listinfo/python-list
Re: XSLT speed comparisons
Damian wrote:
> two websites, one in ASP.NET v2 and one in Python 2.5 (using 4suite for
> XML/XSLT)
> both on the same box (Windows Server 2003)
> both using the same XML, XSLT, CSS
>
> The problem is, the Python version is (at a guess) about three times
> slower than the ASP one.
It could just be that 4suite is slower than MSXML. If so, you can use
MSXML in Python if you want. You'll need to install the Python for
Windows extensions. Something like this:
from os import environ
import win32com.client
def buildPage():
xsluri = 'xsl/plainpage.xsl'
xmluri = 'website.xml'
xsl =
win32com.client.Dispatch("Msxml2.FreeThreadedDOMDocument.4.0")
xml = win32com.client.Dispatch("Msxml2.DOMDocument.4.0")
xsl.load(xsluri)
xml.load(xmluri)
xslt = win32com.client.Dispatch("Msxml2.XSLTemplate.4.0")
xslt.stylesheet = xsl
proc = xslt.createProcessor()
proc.input = xml
params = {"url":environ['QUERY_STRING'].split("=")[1]}
for i, v in enumerate(environ['QUERY_STRING'].split("/")[1:]):
params["selected_section%s" % (i + 1)] = "/" + v
for param, value in params.items():
proc.addParameter(param, value)
proc.transform()
return proc.output
print "Content-Type: text/html\n\n"
print buildPage()
Ross Ridge
--
http://mail.python.org/mailman/listinfo/python-list
Re: XSLT speed comparisons
Damian wrote:
> The errors can be seen at http://python.pointy.co.nz/test (I'm leaving
> the existing, slower version running at the moment for the rest of the
> site).
Hmm... it seems that you don't have MSXML 4.0 installed on your
machine. I missed the fact that you're using ASP.NET, so your ASP code
probably is probably using the .NET XML implementation instead of
MSXML. In that case, another alternative might be to use IronPython
and just translate your ASP script into Python.
Ross Ridge
--
http://mail.python.org/mailman/listinfo/python-list
Re: len() and PEP 3000
Colin J. Williams wrote:
> __len__ is not very special and the
> property len eliminates the redundant parentheses.
tac-tics wrote:
> One might say the current syntax eliminates the redundant dot.
Make "len" an operator, like C's "sizeof", and eliminate the
(hypothetical) dot, parenthesises and a name lookup.
Ross Ridge
--
http://mail.python.org/mailman/listinfo/python-list
Re: Why does Python never add itself to the Windows path?
Ben Sizer wrote: > I've installed several different versions of Python across several > different versions of MS Windows, and not a single time was the Python > directory or the Scripts subdirectory added to the PATH environment > variable. Personally, I hate Windows applications that add themselves to the PATH. So much crap gets put in there that I don't even use the default system PATH and just set my own explicitly. > Every time, I've had to go through and add this by hand, to > have something resembling a usable Python installation. If you're installing multiple versions of Python on one machine you're going to have to do this anyways to ensure the version of Python you want first in the path actually is first. > No such problems on Linux, whether it be Mandrake/Mandriva, Fedora Core, or > Kubuntu. Linux distributions normally install themselves somewhere that's normally in the path already. I suppose you can do the same thing on Windows if you want, just choose to install Python into directory that's already in your path. Though installing to something like C:\WINDOWS\SYSTEM32 is probably not a good idea. Ross Ridge -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 2.4.2 using msvcrt71.dll on Win and compatibility issues
Martin v. Löwis wrote: > In general, the only Microsoft-supported strategy is that you > must use only a single msvcrt in the entire application. So > either recompile PostGres, or recompile Python. If you want a compiled version of Python that already uses MSVCRT then you try using pyMingGW: http://jove.prohosting.com/iwave/ipython/pyMinGW.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Replacing curses
Thomas Dickey wrote:
> ...and send UTF-8 text, keeping track of where you really are on the screen.
You make that sound so easy.
Ross Ridge
--
http://mail.python.org/mailman/listinfo/python-list
Re: Replacing curses
Ian Ward wrote: > I'll have to deal with that anyway, since I'm doing all my own wrapping, > justification and clipping of text. In general it's impossible to know how many display positions some random Unicode character might use. For example, Chinese characters normally take two display positions, but the terminal your using might not support them and display a single width replacement character. Hopefully, you're limitted in the character set you actually need to support and the terminals that your applicaiton will be using. -- http://mail.python.org/mailman/listinfo/python-list
Re: Legality of using Fonts
Steven D'Aprano wrote:
> It is highly unlikely that any judge will be fooled by a mere change in
> format ("but Your Honour, I converted the TTF file into a bitmap").
If that were true, almost the entire X11 bitmap font collection would
be illegal. Fonts aren't subject copyright, just the hints in most
outline fonts, which are considered computer programs.
Ross Ridge
--
http://mail.python.org/mailman/listinfo/python-list
Re: Legality of using Fonts
Steven D'Aprano wrote: > In any case, even in the USA, hinted fonts are copyrightable, and merely > removing the hints (say, by converting to a bitmap) is no more legal than > whiting out the author's name from a book and claiming it as your own. That's an absurd comparison. By making a bitmap font from an hinted outline font you're only copying the typeface, you're not copying the hints, the computer program, that's the only part of the font that's subject copyright. If a book consisted of two parts, the first a play by Shakespeare, and the second a commentary of that play, and someone copied only the first part, they'd be doing nothing illegal. Ross Ridge -- http://mail.python.org/mailman/listinfo/python-list
Re: Is there a way to build python without 'posixmodule' ?
mrstephengross wrote:
> I'm working on building python 2.4.2 with the mingw compiler (on
> cygwin).
Try following the instructions on the pyMinGW site:
http://jove.prohosting.com/iwave/ipython/pyMinGW.html
Ross Ridge
--
http://mail.python.org/mailman/listinfo/python-list
Re: Pure python implementation of string-like class
Steve Holden wrote: > "Wider than UTF-16" doesn't make sense. It makes perfect sense. Ross Ridge -- http://mail.python.org/mailman/listinfo/python-list
Re: Pure python implementation of string-like class
Steve Holden wrote: >"Wider than UTF-16" doesn't make sense. Ross Ridge wrote" > It makes perfect sense. Alan Kennedy wrote: > UTF-16 is a "Unicode Transcription Format", meaning that it is a > mechanism for representing all unicode code points, even the ones with > ordinals greater than 0x, using series of 16-bit values. It's an encoding format that only supports encoding 1,112,064 different characters making it a little more than 20-bits wide. While this enough to encode all code points currently assigned by Unicode, it's not sufficient to encode the private use area of ISO 10646-1 that Akihiro Kayama wants to use. Ross Ridge -- http://mail.python.org/mailman/listinfo/python-list
Re: Pure python implementation of string-like class
Xavier Morel wrote:
> Not if you're still within Unicode / Universal Character Set code space.
Akihiro Kayama in his original post made it clear that he wanted to use
a character set larger than entire Unicode code space.
Ross Ridge
--
http://mail.python.org/mailman/listinfo/python-list
Re: Pure python implementation of string-like class
Ross Ridge wrote: > Akihiro Kayama in his original post made it clear that he wanted to use > a character set larger than entire Unicode code space. Xavier Morel wrote: > He implies that ... He explictly said that character set he wanted to use wouldn't fit in UTF-16. >... but in later messages he > 1. Implies that he wants to use the Unicode private spaces, which are in > the Unicode code space He explictly said that he wanted to use the "U+6000...U+7FFF" range which is outside of the Unicode code space, despite him mistakenly calling them Unicode characters. > 2. Says explicitly that his needs concern Kanji encoding... I have no clue whether he really needs such a large character set, but if he does then it makes sense for him to want to use an encoding that's wider than UTF-16. As for the problem he actually posed, I'd suggest using tuples rather than lists, since tuples are immutable like strings. That would make it easier for the class to be used as key in a dictionary. Hmm... thiking about it, it might actually make sense to use strings as the internal representation as a lot operations can be implemented by using the standard string operation but multipling the offsets and lengths by 4. Ross Ridge -- http://mail.python.org/mailman/listinfo/python-list
Re: Python, Dutch, English, Chinese, Japanese, etc.
Steve Howell <[EMAIL PROTECTED]> wrote:
>about Japan:
>major linguistic influences: Chinese, English,
>Dutch
English and Dutch are minor linguistic influences.
>kanji = Chinese characters
>hiragana and katakana -- syllabic scripts
>Latin alphabet often used in modern Japanese (see
>wikipedia)
The Latin alphabet is generally only used for western or westernized
names, like Sony.
>Asia:
>
> Python should be *completely* internationalized for
>Mandarin, Japanese, and possibly Hindi and Korean.
>Not just identifiers. I'm talking the entire
>language, keywords and all.
This would be more convincing if it came from someone who spoke Mandarin,
Japanese, Hindi or Korean.
btw. Mandarin is a spoken dialect Chinese, what you're actually asking
for is a Simplified-Chinese version of Python.
Ross Ridge
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] [EMAIL PROTECTED]
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python, Dutch, English, Chinese, Japanese, etc.
Steve Howell <[EMAIL PROTECTED]> wrote:
>I'm wondering if all the English keywords in Python
>would present too high a barrier for most Chinese
>people--def, if, while, for, sys, os, etc. So you
>might need to go even further than simply allowing
>identifiers to be written in Simplified-Chinese.
Translating keywords and standard identifiers into Chinese could make
learning Python even more difficult. It would probably make things
easier for new programmers, but I don't know if serious programmers would
actually prefer programming using Chinese keywords. It would make their
Python implementations incompatible with the standard implementation, they
wouldn't be able to use third-party modules and their own code wouldn't
be portable. If novice Chinese programmers would have to unlearn much
of they've learned in order to become serious Python programmers are
you really doing them a favour by teaching them Chinese Python?
It would really only work if Chinese Python became it own successful
dialect of Python, independent of the standard Python implementation.
Chinese Python programmers would be isolated from other Python
programmers, each with their own set of third-party modules and little
code sharing between the two groups. I don't think this would be good
for Python as whole.
Ross Ridge
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] [EMAIL PROTECTED]
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python, Dutch, English, Chinese, Japanese, etc.
Ross Ridge wrote: > Translating keywords and standard identifiers into Chinese could make > learning Python even more difficult. It would probably make things > easier for new programmers, but I don't know if serious programmers would > actually prefer programming using Chinese keywords. It would make their > Python implementations incompatible with the standard implementation, they > wouldn't be able to use third-party modules and their own code wouldn't > be portable. If novice Chinese programmers would have to unlearn much > of they've learned in order to become serious Python programmers are > you really doing them a favour by teaching them Chinese Python? > > It would really only work if Chinese Python became it own successful > dialect of Python, independent of the standard Python implementation. > Chinese Python programmers would be isolated from other Python > programmers, each with their own set of third-party modules and little > code sharing between the two groups. I don't think this would be good > for Python as whole. Wildemar Wildenburger <[EMAIL PROTECTED]> wrote: >I don't see the problem here. The bytecode wouldn't change (right?). Python code generally isn't shared as bytecode and it's not just keywords we're talking about here, all standard Python identifiers (eg. "os" and "sys") would be translated too. >So what? One would have to make sure that the interprter understands both >(or to generalize: all) language versions of python and wham! That might work, you'd need both the standard and Chinese versions the Python standard libraries. I doubt anyone outside of China would want a distribution that included both, so there would still be barriers to code sharing between the two communities. Interestingly, someone has already created a Chinese version of Python much like Steve Howell suggested: http://www.chinesepython.org/cgi_bin/cgb.cgi/home.html http://www.chinesepython.org/cgi_bin/cgb.cgi/english/english.html Apparently it hasn't been updated in almost four years, so I don't know much use it gets. Ross Ridge -- l/ // Ross Ridge -- The Great HTMU [oo][oo] [EMAIL PROTECTED] -()-/()/ http://www.csclub.uwaterloo.ca/~rridge/ db // -- http://mail.python.org/mailman/listinfo/python-list
Re: Python COM iterator
Larry Bates wrote:
> I tested in VB and by golly it works! What is odd is that this looks
> NOTHING like what we got from the docs earlier. No GetEnumerator
> method, no MoveNext method. I'm glad it works, but I'm a little
> puzzled as to why it works.
The documention Carsten Haese referenced earlier was for the .NET version
of VisualBasic, and shows how to use .NET's IEnumerate and IEnumerable
interfaces.
Steve Holden <[EMAIL PROTECTED]> wrote:
>Presumably the magic of mark Hammond's wrapper classes providing
>adaptation between Python iteration and COM enumerable collection
>objects. win32all is *very* Pythonic.
Maybe Mark Hammond's win32all provides such a magic wrapper, but Cartsen
Haese's example didn't use it. Instead it provided it own implementation
of the COM IEnumVARIANT interface, the OLE Automation (ie. VisualBasic
6 compatable) way implementing iteratable objects.
Ross Ridge
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] [EMAIL PROTECTED]
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python's handling of unicode surrogates
Rhamphoryncus <[EMAIL PROTECTED]> wrote:
>The only code that will be changed is that which doesn't handle
>surrogates properly. Some will start working properly. Some (ie
>random.choice(u'\U0010\u')) will fail explicitly (rather than
>silently).
You're falsely assuming that any code that doesn't support surrogates
is broken. Supporting surrogates is no more required than supporting
combining characters, right-to-left languages or lower case letters.
Ross Ridge
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] [EMAIL PROTECTED]
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python's handling of unicode surrogates
Rhamphoryncus <[EMAIL PROTECTED]> wrote:
>I wish to write software that supports Unicode. Like it or not,
>Unicode goes beyond the BMP, so I'd be lying if I said I supported
>Unicode if I only handled the BMP.
The Unicode standard doesn't require that you support surrogates, or
any other kind of character, so no you wouldn't be lying.
Also since few Python programs claim to support Unicode, why do you
think it's acceptable to break them if they don't support surrogates?
Ross Ridge
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] [EMAIL PROTECTED]
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python's handling of unicode surrogates
Ross Ridge writes: > The Unicode standard doesn't require that you support surrogates, or > any other kind of character, so no you wouldn't be lying. <[EMAIL PROTECTED]> wrote: > There is the notion of Unicode implementation levels, and each of them > does include a set of characters to support. There are different levels of implemtentation for ISO 10646, but not of Unicode. > It is probably an interpretation issue what "supported" means. The strongest claim to support Unicode that you can meaningfully make is that of conformance to the Unicode standard. The Unicode standard's conformance requirements make it explicit that you don't need to support any particular character: C8 A process shall not assume that it is required to interpret any particular coded character representation. . Processes that interpret only a subset of Unicode characters are allowed; there is no blanket requirement to interpret all Unicode characters. [...] > Python clearly supports Unicode level 1 (if we leave alone the issue > that it can't render all these characters out of the box, as it doesn't > ship any fonts); It's not at all clear to to me that Python does support ISO 10646's implementation level 1, if only because I don't, and I assume you don't, have a copy of ISO 10646 available to verify what the requirements actually are. Ross Ridge -- l/ // Ross Ridge -- The Great HTMU [oo][oo] [EMAIL PROTECTED] -()-/()/ http://www.csclub.uwaterloo.ca/~rridge/ db // -- http://mail.python.org/mailman/listinfo/python-list
Re: My Python annoyances
Thorsten Kampe <[EMAIL PROTECTED]> wrote:
>He was using /Windows/ Python in Cygwin *chuckle*... Windows Python
>says Ctrl-Z because it doesn't know that it's been run from bash where
>Ctrl-Z is for job control.
No, if you run Windows Python from Cygwin bash CTRL-Z works as the
EOF character:
~$ /cygdrive/e/util/python24/python
Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> quit
'Use Ctrl-Z plus Return to exit.'
>>> ^Z
~$ jobs
~$ python
Python 2.5 (r25:51908, Mar 13 2007, 08:13:14)
[GCC 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)] on cygwin
Type "help", "copyright", "credits" or "license" for more information.
>>> quit
Use quit() or Ctrl-D (i.e. EOF) to exit
>>>
[1]+ Stopped python
~$
Apparently though the Cygwin version of Python now prints the correct
message for quit.
Ross Ridge
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] [EMAIL PROTECTED]
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //
--
http://mail.python.org/mailman/listinfo/python-list
Re: My Python annoyances
Ben Collver <[EMAIL PROTECTED]> wrote:
>It is problem report #1678102. I understand the problem: that a 32 bit
>number looks different in a 32 bit signed int than in a 64 bit signed
>int. However, the workaround of dropping a bit seems to defeat the
>purpose of using a CRC.
The workaround doesn't drop any bits, it converts the value to a Python
long and extracts the lower 32 bits.
There's really no good reason for Python to give two different results
here. It should either return a signed 32-bit CRC value in a Python int,
or return a unsigned 32-bit CRC value in either Python long or a Python
int, if it's big enough. What it's doing now, returning unsigned value in
a Python int, even when it's not big enough to hold the result, is wrong.
Ross Ridge
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] [EMAIL PROTECTED]
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //
--
http://mail.python.org/mailman/listinfo/python-list
Re: Single precision floating point calcs?
Grant Edwards <[EMAIL PROTECTED]> wrote:
>In the C implementations, the algorithms will be done
>implemented in single precision, so doing my Python prototyping
>in as close to single precision as possible would be "a good
>thing".
Something like numpy might give you reproducable IEEE 32-bit floating
point arithmetic, but you may find it difficult to get that out of a
IA-32 C compiler. IA-32 compilers either set the x87 FPU's precision to
either 64-bits or 80-bits and only round results down to 32-bits when
storing values in memory. If you can target CPUs that support SSE,
then compiler can use SSE math to do most single precision operations
in single precision, although the compiler may not set the required SSE
flags for full IEEE complaince.
In other words, since you're probably going to have to allow for some
small differences in results anyways, it may not be worth the trouble
of trying to get Python to use 32-bit floats.
(You might also want to consider whether you want to using single
precision in your C code to begin with, on IA-32 CPUs it seldom makes
a difference in performance.)
Ross Ridge
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] [EMAIL PROTECTED]
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //
--
http://mail.python.org/mailman/listinfo/python-list
Re: PEP 3131: Supporting Non-ASCII Identifiers
<[EMAIL PROTECTED]> wrote:
>So, please provide feedback, e.g. perhaps by answering these
>questions:
>- should non-ASCII identifiers be supported? why?
I think the biggest argument against this PEP is how little similar
features are used in other languages and how poorly they are supported
by third party utilities. Your PEP gives very little thought to how
the change would affect the standard Python library. Are non-ASCII
identifiers going to be poorly supported in Python's own library and
utilities?
Ross Ridge
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] [EMAIL PROTECTED]
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //
--
http://mail.python.org/mailman/listinfo/python-list
Re: PEP 3131: Supporting Non-ASCII Identifiers
<[EMAIL PROTECTED]> wrote: >So, please provide feedback, e.g. perhaps by answering these >questions: >- should non-ASCII identifiers be supported? why? Ross Ridge wrote: > I think the biggest argument against this PEP is how little similar > features are used in other languages Carsten Haese <[EMAIL PROTECTED]> wrote: >That observation is biased by your limited sample. No. I've actually looked hard to find examples of source code that use non-ASCII identifiers. While it's easy to find code where comments use non-ASCII characters, I was never able to find a non-made up example that used them in identifiers. > You only see open source code that chooses to restrict itself to ASCII >and mostly English identifiers to allow for easier code sharing. There >could be millions of kids in China learning C# in native Mandarin and >you'd never know about it. No, there's tons of code written by kids learning programming languages from all over the world scattered all over the Internet. Regardless of what my observations are, I think that you need a better argument than a bunch of children in China that may very well not exist. This PEP, like similar features in other langauges is being made and advocated by people who don't actually want to use it. It's made on the presumption that somehow developers in China and other places its proponents aren't familar with desperately want this feature but are somehow incapable of advocating for it themselves let alone implementing it. The burden of proof should be on this PEP's proponents to show that it will be actually be used. Is this PEP even justified by anyone going to the trouble of asking for it to be implemented in the first place? >How would a choice of identifiers interact in any way with Python's >standard or third-party libraries? The only things that get passed >between an application and the libraries are objects that neither know >nor care what identifiers, if any, are attached to them. A number of libraries and utilities, including those included with the standard Python distribution work with Python identifiers. The PEP gives one example, but it doesn't really give much though as to how much of the standard library might be affected. If the proponents of this PEP think it will actually be used, then the implementation section of this PEP should be updated to include making all aspects of the standard Python distribution, the interpreter, libraries and utilities fully support non-ASCII identifiers. These hypothetical Chinese students are going to happy if IDLE doesn't highlight identifiers correctly, or the carret in a syntax error doesn't point to the right place. Hmm... normalizing identifiers could cause problems with module names. If Python searches the filesystem for the module using the normalized version of the name different from the one that appears in the source code it could end up surprising users. Ross Ridge -- l/ // Ross Ridge -- The Great HTMU [oo][oo] [EMAIL PROTECTED] -()-/()/ http://www.csclub.uwaterloo.ca/~rridge/ db // -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 3131: Supporting Non-ASCII Identifiers
Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> wrote:
>I think you have to search examples of ASCII sources with transliterated
>identifiers too, because the authors may have skipped the transliteration
>if they could have written the non-ASCII characters in the first place.
The point of my search was to look for code that actually used non-ASCII
characters in languages that actually supported it (mainly Java at the
time). The point wasn't to create more speculation about what programmers
might or might not do, but to find out what they were actually doing.
>And then I dare to guess that much of that code is not open source.
Lots of non-open source code makes it on to the Internet in the form of
code snippets. You don't have to guess what closed-source are actually
doing either.
Ross Ridge
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] [EMAIL PROTECTED]
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //
--
http://mail.python.org/mailman/listinfo/python-list
Re: PEP 3131: Supporting Non-ASCII Identifiers
Ross Ridge schrieb:
> non-ASCII identifiers. While it's easy to find code where comments use
> non-ASCII characters, I was never able to find a non-made up example
> that used them in identifiers.
Gregor Horvath <[EMAIL PROTECTED]> wrote:
>If comments are allowed to be none English, then why are identifier not?
In the code I was looking at identifiers were allowed to use non-ASCII
characters. For whatever reason, the programmers choose not use non-ASCII
indentifiers even though they had no problem using non-ASCII characters
in commonets.
Ross Ridge
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] [EMAIL PROTECTED]
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //
--
http://mail.python.org/mailman/listinfo/python-list
Re: PEP 3131: Supporting Non-ASCII Identifiers
=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?= <[EMAIL PROTECTED]> wrote:
>One possible reason is that the tools processing the program would not
>know correctly what encoding the source file is in, and would fail
>when they guessed the encoding incorrectly. For comments, that is not
>a problem, as an incorrect encoding guess has no impact on the meaning
>of the program (if the compiler is able to read over the comment
>in the first place).
Possibly. One Java program I remember had Japanese comments encoded
in Shift-JIS. Will Python be better here? Will it support the source
code encodings that programmers around the world expect?
>Another possible reason is that the programmers were unsure whether
>non-ASCII identifiers are allowed.
If that's the case, I'm not sure how you can improve on that in Python.
There are lots of possible reasons why all these programmers around
the world who want to use non-ASCII identifiers end-up not using them.
One is simply that very people ever really want to do so. However,
if you're to assume that they do, then you should look the existing
practice in other languages to find out what they did right and what
they did wrong. You don't have to speculate.
Ross Ridge
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] [EMAIL PROTECTED]
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //
--
http://mail.python.org/mailman/listinfo/python-list
Re: Passing a FILE* from Python into a MinGW/SWIG module
John Pye <[EMAIL PROTECTED]> wrote:
>Is there an official workaround for this? Presumably I need to
>implement a mingw-compatible version of all the 'file' class in
>Python, eg
I'm not familiar with SWIG, but why not pass Python's own file class?
Method calls on Python's file class will be dispatched to C code in
the Python interpreter and so will use the C runtime that Python was
linked with.
Ross Ridge
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] [EMAIL PROTECTED]
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //
--
http://mail.python.org/mailman/listinfo/python-list
Re: Exceptions when closing a file
Steven D'Aprano <[EMAIL PROTECTED]> wrote:
>Closing a file can (I believe) raise an exception. Is that documented
>anywhere?
In a catch-all statement for file objects: "When a file operation fails
for an I/O-related reason, the exception IOError is raised." The fact
that close() is a file operation that might fail is revealed by "file
objects are implemented using C's stdio package" and the fact the C's
fclose() function can fail.
> Is IOError the only exception it can raise?
I assume it can raise the exceptions MemoryError and KeyboardInterupt,
which just about any Python operation can raise.
>Out of curiosity, is there a simple way to demonstrate close() raising an
>exception that doesn't involve messing about with disk quotas?
Something like the following should work:
f = file("/dev/null", "r")
os.close(f.fileno)
f.close()
Normally however, you can expect file method close() to fail for all
the same reasons you would expect write() to fail.
Ross Ridge
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] [EMAIL PROTECTED]
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //
--
http://mail.python.org/mailman/listinfo/python-list
Re: How to receive a FILE* from Python under MinGW?
Gabriel Genellina <[EMAIL PROTECTED]> wrote:
>You can get the file descriptor from the Python file object using its
>fileno() method. The file descriptor lives at the OS level, so it's safe
>to pass around.
Not under Windows. Windows doesn't have Unix-like descriptors, so the
C runtime emulates them.
Ross Ridge
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] [EMAIL PROTECTED]
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //
--
http://mail.python.org/mailman/listinfo/python-list
Re: Getting started with python
James Stroud <[EMAIL PROTECTED]> wrote:
>py> t = timeit.Timer(stmt=s)
>py> print "%.2f usec/pass" % (100 * t.timeit(number=10)/10)
>40.88 usec/pass
7stud <[EMAIL PROTECTED]> wrote:
>What does this accomplish:
>
>100 * t.timeit(number=10)/10
>
>that the following doesn't accomplish:
>
>10 * t.timeit(number=10)
The first example converts from seconds per 10 passes to microseconds
per pass in two steps, while the second example does it one. The first
example is more easily understood and maintainable than the second
example.
Ross Ridge
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] [EMAIL PROTECTED]
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //
--
http://mail.python.org/mailman/listinfo/python-list
Re: Determining when a file is an Open Office Document
tubby wrote: > Silly question, but here goes... what's a good way to determine when a > file is an Open Office document? I could look at the file extension, but > it seems there would be a better way. VI shows this info in the files: > > mimetypeapplication/vnd.oasis.opendocument.textPK It's a ZIP archive. The info you've found are the file name "mimetype", the uncompressed contents of that file "application/vnd.oasis.opendocument.text", and part of the ZIP magic number "PK". You should be able to use the "zipfile" module to check to see if the file a ZIP file, if it has a member named "mimetype" and if the contents of the file match one of the OpenOffice MIME types. Ross Ridge -- http://mail.python.org/mailman/listinfo/python-list
Re: Determining when a file is an Open Office Document
tubby wrote: > Silly question, but here goes... what's a good way to determine when a > file is an Open Office document? I could look at the file extension, but > it seems there would be a better way. VI shows this info in the files: > > mimetypeapplication/vnd.oasis.opendocument.textPK It's a ZIP archive. The info you've found are the file name "mimetype", the uncompressed contents of that file "application/vnd.oasis.opendocument.text", and part of the ZIP magic number "PK". You should be able to use the "zipfile" module to check to see if the file a ZIP file, if it has a member named "mimetype" and if the contents of the file match one of the OpenOffice MIME types. Ross Ridge -- http://mail.python.org/mailman/listinfo/python-list
Re: Determining when a file is an Open Office Document
tubby wrote:
> Now, If only I could something like that on PDF files :)
PDF files should begin with "%PDF-" followed by a version number, eg.
"%PDF-1.4". The PDF Reference notes that Adobe Acrobat Reader is a bit
more flexiable about what it will accept:
13. Acrobat viewers require only that the header appear
somewhere within the first 1024 bytes of the file.
14. Acrobat viewers also accept a header of the form
%!PS-Adobe-N.n PDF-M.m
So identifying PDF files is pretty easy. If you want to examine the
contents of a PDF file you're better off using Postscript, Ghostscript
specifically, since PDF is essentially Postscript with a special
dictionary of commands.
Ross Ridge
--
http://mail.python.org/mailman/listinfo/python-list
Re: Determining when a file is an Open Office Document
Ross Ridge wrote: > So identifying PDF files is pretty easy. Steven D'Aprano wrote: > Sure. MIS-identifying PDF files is pretty easy. Identifying them is not. > Consider this example: Your contrived example doesn't show how a PDF file would be misidentified, it only shows how a file deliberately made to look like PDF file would be "misidentified". Since that was the intent of crafting such a file, I don't see the problem. > Is there a security vulnerability buried in the detection of file types by > magic bytes? I don't know, but I wouldn't be surprised if there were. There's only a security vulnerability if you choose to trust a file based on it's assumed file type. Since PDF files generally aren't trusted, it's not likely to be an issue for whatever application tubby has in mind. >Any file system that doesn't have file type metadata is reduced to >guessing the type of the file, and guesses can be wrong. File type metadata can also be wrong. You can give any file a .PDF extension and Windows will believe it's a PDF file. On Mac OS if file has a signature "CARO"/"PDF ", it will believe it's a PDF file regardless of it's contents. Metadata doesn't make programs any less vulnerable to deliberate attempts to fool them. Ross Ridge -- http://mail.python.org/mailman/listinfo/python-list
Re: mmap caching
George Sakkis wrote: > It's around 400MB. On Windows you may not be able to map a file of this size into memory because of virtual address space fragmentation. A Win32 process has only 2G of virtual address space, and DLLs tend to get scattered through out that address space. > As I said, I cannot reproduce the MemoryError > locally since I have 1GB physical space but IIRC the user who reported > it had less. Virtual address space fragmentation isn't affected by the amount of physical memory in your system. A system with 64MB of RAM might be able to map a 400MB file while system with 3G of RAM might not be able to map it because of how DLLs got loaded in to the process. > Actually I am less concerned about whether a MemoryError > is raised or not in this case and more about the fact that even if > there's no exception, the program may suffer from severe thrashing due > to constant swapping. Well, that's what you're asking for when you use mmap. The same mechanism that creates virtual memory using a swap file is used to create a virtual memory mapping of your file. When you read from the mmap file pages from the file a swapped into memory and stay in memory until they need to be swapped out to make room for something else. If you don't want this behaviour, don't use mmap. Ross Ridge -- http://mail.python.org/mailman/listinfo/python-list
Re: Help with Optimization of Python software: real-time audio controller
Paul Rubin wrote: > I think you can't really do that, not just because of Python but also > as a result of using a multitasking OS that's not especially designed > for real time. You have to rely on some buffering in the audio > hardware, so you don't have to be sample-accurate with the timings. For his application you don't need "sample-accurate" timings. Between MIDI and synthesizer latency a few milliseconds of delay are inherent in what he's trying to do, regardless of operatings system, and a latency of 20 milliseconds or more is probably acceptable. Assuming he's not trying to write his own synthesizer, he might just be able to write his application in Python under Mac OS X. Ross Ridge -- http://mail.python.org/mailman/listinfo/python-list
Re: Running Python scripts from BASH
Ishpeck <[EMAIL PROTECTED]> wrote: >': [Errno 22] Invalid argumentopen file 'foo.py The problem is that Python is using the standard Windows CRLF line endings, while Cygwin bash expects Unix LF-only line endings. Your script ends up trying run the script "foo.y\r" instead of "foo.y", and since CR is isn't allowed in Windows filename you get the "Invalid argument" error when Python tries to open the file. >Maybe this is a better question for a BASH-related group. The Cygwin list probably would've been the best. >How do I get around this? Don't mix Cygwin tools and native Windows tools. Either use the Cygwin version of Python or don't use Cygwin bash. Ross Ridge -- http://mail.python.org/mailman/listinfo/python-list
Re: mailbox.Maildir question/problem
<[EMAIL PROTECTED]> wrote: >Is there *any* way I can get python to access maildirs >which are not named using this (IMHO stupid) convention? Well, the mailbox module doesn't support deleting mailboxes, so I'm not sure why you want to use it. Since you also seem to have a better idea of what your maildirs look like, why not just use the lower level file functions directly? Something like: def remove_empty_maildir(dirname): expected = set(["cur", "new", "tmp"]) ents = set(os.listdir(dirname)) if ents != expected: if expected.issubset(ents): raise error, "unexpected subdirs in maildir" raise error, "not a maildir" subdirs = [os.path.join(dirname, d) for d in expected] for d in subdirs: if len(os.listdir(d)) != 0: return False for d in subdirs: os.rmdir(d) os.rmdir(dirname) return True Your case is presumably different somehow, so you'll have to update and fix this completely untested code if you want to use it. Ross Ridge -- l/ // Ross Ridge -- The Great HTMU [oo][oo] [EMAIL PROTECTED] -()-/()/ http://www.csclub.uwaterloo.ca/~rridge/ db // -- http://mail.python.org/mailman/listinfo/python-list
Re: Windows XP unicode and escape sequences
<[EMAIL PROTECTED]> wrote:
>This brings up another question. If I run some Python code that starts
>off with 'os.system('cp869')' so it will change to the correct code page,
>then when it starts printing the Greek characters it breaks. But run
>the same Python code again and it works fine.
That's probably because the encoding of stdin, stdout, and stderr is set
according to the code page of the console they're connected to (if any)
when Python starts.
>Is there another way to do this so I can change over to the 869 code
>page and continue on with the Greek letters printing correctly?
Unfortunately, you can't easily change the encoding of file object after
it's been created. It's probably simpler convert Unicode strings to cp869
before printing them instead of having Python do it automatically for you.
Ross Ridge
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] [EMAIL PROTECTED]
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //
--
http://mail.python.org/mailman/listinfo/python-list
Re: IronPython faster than CPython?
Jack <[EMAIL PROTECTED]> wrote:
>I learned a lot from the other thread 'Is a "real" C-Python possible?' about
>Python performance and optimization. I'm almost convinced that Python's
>performance is pretty good for this dynamic language although there are
>areas to improve, until I read some articles that say IronPython is a few
>times faster.
In my limitted experience, IronPython is slower than CPython. I can't
actually get much to run with IronPython, but what I have been able
to get working runs slower. In particular initialization time takes
much longer. A command line utility of mine that takes 1.5 seconds to
run with CPython, ends up taking 20 seconds with IronPython. That 3
seconds for IronPython's own startup and initilization, 12 seconds for
importing modules, and 5 seconds for the rest.
Ross Ridge
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] [EMAIL PROTECTED]
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //
--
http://mail.python.org/mailman/listinfo/python-list
Re: Allowing Arbitrary Indentation in Python
Sam <[EMAIL PROTECTED]> wrote:
>cmds.window(t='gwfUI Builder')
>cmds.paneLayout(configuration='vertical3', ps=((1, 25, 100), (3, 20,
>100)))
>cmds.paneLayout(configuration='horizontal2')
>cmds.frameLayout(l='Layouts')
>cmds.scrollLayout(cr=True)
>cmds.columnLayout(adj=True, cat=('both', 2))
>for i in layouts:
> cmds.button(l=i)
>cmds.setParent('..')
>cmds.setParent('..')
>cmds.setParent('..')
>cmds.setParent('..')
>cmds.setParent('..')
>cmds.showWindow()
An alternative would be to do something like the following:
cmds.window(t='gwfUI Builder')
cmds.paneLayout(configuration='vertical3', ps=((1, 25, 100),
(3, 20, 100)))
cmds.paneLayout(configuration='horizontal2')
cmds.frameLayout(l='Layouts')
cmds.scrollLayout(cr=True)
cmds.columnLayout(adj=True, cat=('both', 2))
for i in layouts:
cmds.button(l=i)
cmds.setParent('..')
cmds.setParent('..')
cmds.setParent('..')
cmds. setParent('..')
cmds.setParent('..')
cmds.showWindow()
Stylistically it's not much better, but you don't need to change Python
interpreter for it work.
Ross Ridge
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] [EMAIL PROTECTED]
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //
--
http://mail.python.org/mailman/listinfo/python-list
Re: Understanding memory leak reports
Giampaolo Rodola' <[EMAIL PROTECTED]> wrote: >I'm in a big trouble since I don't know how to find some memory leaks ... >The message printed on screen is the following: > >gc: collectable >gc: collectable >gc: collectable >gc: collectable >gc: collectable >gc: collectable >gc: collectable > >Since the main module is very big (more than 2800 lines of code) I do >not understand which objects are not garbage collected. They are being garbage collected. That's what the "collectable" part of the message means. It's just a warning that those objects needed to be garbage collected because they were refering to each other in some sort of cycle. While the memory used was being wasted before the garbage collector ran, it probably doesn't have any negative effect on your program. Ross Ridge -- l/ // Ross Ridge -- The Great HTMU [oo][oo] [EMAIL PROTECTED] -()-/()/ http://www.csclub.uwaterloo.ca/~rridge/ db // -- http://mail.python.org/mailman/listinfo/python-list
Re: Python DLL in Windows Folder
Markus Gritsch <[EMAIL PROTECTED]> wrote:
>... We are embedding Python into our application which
>gets compiled using MSVC 8.0. We like to link dynamically, so the
>Python interpreter is not statically linked into the program. The
>Python DLL from the Python installer in the Windows system32 folder is
>compiled using MSVC 7.1.
If you're targetting Windows XP or newer you can use manifests to force
Windows to link your application with a particular version of the DLL.
On Windows 98SE or newer you can use .local files to force Windows to
link with whatever DLLs are in the same directory as your executable.
>Our current solution to the problem is modifying the Python build
>process to produce our Python DLL with a filename containing also the
>patchlevel of the version number i.e. python251.dll instead of
>python25.dll. This way we can be sure that *our* Python DLL gets
>loaded. This works fine.
I'd give it a more unique name, like "companyname_python25_1_msvc80.dll".
That gives you more certainty that it is actually your DLL. You also
won't have to worry if your users copied python251.dll to the system
directory when you upgrade to Visual Studio 2008.
Ross Ridge
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] [EMAIL PROTECTED]
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python DLL in Windows Folder
Chris Mellon <[EMAIL PROTECTED]> wrote:
>What the python installer is doing is the Right Thing for making the
>standard python dll available to third party applications.
>Applications that want a specific version of a specific DLL should use
>the mechanisms available for doing so, instead of relying on there
>being a specific version of the python dll in the windows folder. This
>is just general best practice on Windows.
No, it's not best practice for an application install any of its files
in the Windows system directory. The system directory is ment only
for drivers and system files. Installing application DLLs in the
system directory is something that should only be done for backwards
compatiblity.
Ross Ridge
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] [EMAIL PROTECTED]
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python DLL in Windows Folder
Chris Mellon <[EMAIL PROTECTED]> wrote: >What the python installer is doing is the Right Thing for making the >standard python dll available to third party applications. >Applications that want a specific version of a specific DLL should use >the mechanisms available for doing so, instead of relying on there >being a specific version of the python dll in the windows folder. This >is just general best practice on Windows. Ross Ridge <[EMAIL PROTECTED]> wrote: >No, it's not best practice for an application install any of its files >in the Windows system directory. Tim Roberts <[EMAIL PROTECTED]> wrote: >Python is more than an application. It's a development tool, and its DLLs >are needed by any of the Python applications I create. I disagree with >your assertion. A development tool is an application, and is covered by the same best practice guidelines as any other Windows application. >>The system directory is ment only for drivers and system files. > >In your view, what disqualifies python24.dll as a "system file"? The fact >that it wasn't produced by Microsoft? By definition, all system files on Windows are supplied by Microsoft. They're sometimes produced by other companies, and they can be installed by third-party applications, but only Microsoft gets to say what is a supported part of the Windows operating system and thus a system file. >>Installing application DLLs in the system directory is something that >>should only be done for backwards compatiblity. > >Deployment of Python applications is much easier when python24.dll is >located there. That has to weigh in the equation. *shrug* I'm sure it wasn't done malicously. I'm not arguing that Python should change it behaviour, I know how utterly pointless that would be. However, like it or not it doesn't follow the best practices for Windows applications. I'm just hoping that no one reading this thread will think that Python is doing the "Right Thing" and copy its behaviour. Ross Ridge -- l/ // Ross Ridge -- The Great HTMU [oo][oo] [EMAIL PROTECTED] -()-/()/ http://www.csclub.uwaterloo.ca/~rridge/ db // -- http://mail.python.org/mailman/listinfo/python-list
Re: Python DLL in Windows Folder
Chris Mellon <[EMAIL PROTECTED]> wrote:
>Python (when installed with "for everyone") is not (just) an
>application, it's a runtime.
Whatever you want to call it, the Python DLL is not part of the operating
system, it's not a driver and doesn't belong in the system directory.
Ross Ridge
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] [EMAIL PROTECTED]
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //
--
http://mail.python.org/mailman/listinfo/python-list
Re: MinGW and Python
sturlamolden wrote: > MinGW and Cygwin GCC is actually the same compiler. Not exactly. They're both GCC, but the MinGW compiler that you can download from MinGW WWW site is a native Win32 appliction, while the "MinGW" compiler included with Cygwin and invoked by "-mno-cygwin" is a Cygwin application. Ross Ridge -- http://mail.python.org/mailman/listinfo/python-list
Re: MinGW and Python
sturlamolden wrote: > MinGW can compile MFC. Download Windows Platform SDK and you get the > MFC source. Do not do this. The Platform SDK's EULA does not permit you to redistribute anything you build from the MFC sources included in the SDK. The only way to get a copy of MFC that you can legitimately use in anything you distribute you need to buy a Microsoft C++ compiler. Ross Ridge -- http://mail.python.org/mailman/listinfo/python-list
Re: MinGW and Python
Martin v. Löwis wrote: > Well, there is no native C library on Microsoft Windows: the system > simply doesn't include an official C library (I know there is crtdll.dll > and msvcrt.dll, but these aren't "endorsed" system C libraries). MSVCRT.DLL has been a standard system compent of Windows since at least Windows 98. Many other system components depend on it. Essentially, MSVCRT.DLL is an "undocumented" part of the Windows API. It's not exactly "endorsed", Microsoft would rather you use it's current compiler and runtime, but it is the standard "official" Windows system C library. Ross Ridge -- http://mail.python.org/mailman/listinfo/python-list
Re: MS VC++ Toolkit 2003, where?
Martin v. Löwis wrote: > Right. MingW (GNU ld) was (apparently) changed to support that shortly > after I started including libpython24.a files with the Windows > distributions. A bug in binutils support for short import library records was fixed about year ago. You need to use MinGW binutils 2.16.91 or newer if you want to link with any of the ".lib" files included with Python 2.4. Ross Ridge -- http://mail.python.org/mailman/listinfo/python-list
Re: MinGW and Python
Ross Ridge wrote: > MSVCRT.DLL has been a standard system compent of Windows since at least > Windows 98. Many other system components depend on it. Essentially, > MSVCRT.DLL is an "undocumented" part of the Windows API. It's not > exactly "endorsed", Microsoft would rather you use it's current > compiler and runtime, but it is the standard "official" Windows system > C library. Martin v. Löwis wrote: > http://msdn2.microsoft.com/en-us/library/abx4dbyh(VS.80).aspx > > 'The msvcrt.dll is now a "known DLL," meaning that it is a system > component owned and built by Windows. It is intended for future use only > by system-level components.' Exactly, it's the standard Windows system C library. > The SDK stopped including an import library for it (I believe earlier > versions of the SDK still had an import library). An import library for it is easy enough to obtain. You can make your own, or just grab the one from MinGW. If you insist on a Microsoft source for it then you can find it in the Windows DDK. > Regardless, there is no version of the MS C++ library that links against > msvcrt.dll. The version of the MS C++ library in Visual Studio C++ 6 links against MSVCRT.DLL. > So if Python is linked against msvcrt.dll, you can't really build C++ > extensions anymore (with MSVC), unless you are certain that > mixing CRTs causes no harm for your application. Python 2.4 is linked against MSVCR71.DLL, so you can't really build C or C++ extensions anymore with Microsoft's current compiler either. Ross Ridge -- http://mail.python.org/mailman/listinfo/python-list
Re: MinGW and Python
Ross Ridge wrote: > Not exactly. They're both GCC, but the MinGW compiler that you can > download from MinGW WWW site is a native Win32 appliction, while the > "MinGW" compiler included with Cygwin and invoked by "-mno-cygwin" is a > Cygwin application. Martin v. Löwis wrote: > Any Cygwin application is a native Win32 application, which just happens > to link with cygwin1.dll (which also is a native Win32 DLL) Nonetheless, Cygwin applications are not generally considered native Win32 applications because of the dependency on CYGWIN1.DLL and the related environment. While what you're saying a strictly true, the term "native Win32" is used to make a distinction between a port of a program that doesn't use or require the Cygwin environment from one that does. For example, the official version of Python for Windows is considered a native Win32 application because it's implemented using the Windows APIs directly, as opposed to the Cygwin's version of Python which implemented using Cygwin's POSIX emulation API, and only uses the Windows API indirectly. Ross Ridge -- http://mail.python.org/mailman/listinfo/python-list
Re: MinGW and Python
Ross Ridge wrote: > Nonetheless, Cygwin applications are not generally considered native > Win32 applications because of the dependency on CYGWIN1.DLL and the > related environment. While what you're saying a strictly true, the > term "native Win32" is used to make a distinction between a port of a > program that doesn't use or require the Cygwin environment from one > that does. Martin v. Löwis wrote: > I know it is common to take that view, but I believe it is wrong, no > matter how you look at it Regardless, that's what "native Win32 application" means in this context, and makes a useful and well understood distinction between ports. Ross Ridge -- http://mail.python.org/mailman/listinfo/python-list
Re: MinGW and Python
sturlamolden wrote:
> Cygwin executables are native windows ".exe files" just like MinGW
> executables. They are built by the same compiler, a port of GCC to 32
> bit Windows originally written by Mumit Khan.
No, Cygwin executables are built using a different port of GCC, the
Cygwin port of GCC. The two ports are very similar, but the Cygwin
port is a Cygwin application. That means, for example, it uses Cygwin
pathnames instead of the standard Win32 pathnames that MinGW uses.
Ross Ridge
--
http://mail.python.org/mailman/listinfo/python-list
Re: MinGW and Python
sturlamolden wrote:
> That is correct. And it is the reson why the MinGW team is working on
> removing the dependency on this CRT.
No one is working on removing MinGW's depency on MSVCRT.DLL.
Ross Ridge
--
http://mail.python.org/mailman/listinfo/python-list
Re: MinGW and Python
sturlamolden wrote: > I seem to vaguely remember that MinGW was going to get its own CRT. And > unless it does, MinGW is a defect compiler for legal resons. It cannot > be legally used. That is simply not true. > Microsoft has designated the CRT that MinGW links a system file, > against which no application should link. While they may not recommend it anymore, Microsoft no more prohibits applications linking against MSVCRT.DLL than KERNEL32.DLL. > Insted they have asked that a CRT is distributed together > with any program that depends on it. If you program needs > msvcrt.dll, you should redistribute msvcrt.dll and place > a copy in your program's install directory. No, this is not how Microsoft recommends installing MSVCRT.DLL. Because it is a system DLL it should be, after doing appropriate version checking, installed in the system directory. See: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvc60/html/redistribvc6.asp > When you compile with MinGW, you are not allowed to to that. That's why MinGW applications don't include MSVCRT.DLL in their distributions. There's no reason to do so, since it's installed already on virtually all Windows systems. Even on systems like Windows 95 where MSVCRT.DLL wasn't originally a system DLL, it's usually already been installed as a consequence of installing some other application. > http://support.microsoft.com/default.aspx?scid=kb;en-us;326922 This article describes how MSVCR70.DLL, MSVCR71.DLL and MSVCR80.DLL should be installed. Since these DLLs, as the article points out, aren't system files they should differently than MSVCRT.DLL. Ross Ridge -- http://mail.python.org/mailman/listinfo/python-list
Re: MinGW and Python
Ross Ridge write: > No one is working on removing MinGW's depency on MSVCRT.DLL. Ames Andreas wrote: > There is certainly work underway to ease the use of msvcrXX in > mingw built binaries. Danny makes it pretty clear in the message you refered that he's not working on that. > 2) legal issues: redistribution of msvcrXX ... > No. 2 could be a show-stopper. You'd have to point people who don't already have it to Microsoft's download site. This wouldn't be ideal, but then Python already points Windows users to Microsoft's download site if they don't have MSI already installed. > There remains one technical issue that isn't a killer but would > be inconvenient, IMHO: Can pywin32 be made working with a > mingw-python (I'm quite sure it can't be made building on it)? I don't why it couldn't. It works with old versions of Python that use MSVCRT.DLL. I think that having current versions of Python also linked MSVCRT.DLL, whether compiled with MinGW or MSVC 6, 7 or 8, could be over all be a better solution than using a CRT DLL specific to one version of Microsoft's compiler. It would make it possible to build extentions with any version of MSVC, instead of just the one that Python was built with. Ross Ridge -- http://mail.python.org/mailman/listinfo/python-list
Re: MinGW and Python
Ross Ridge wrote: > You'd have to point people who don't already have it to Microsoft's > download site. sturlamolden wrote: > Is there a download site? I have not been able to localise one. Links where you can download them were posted in the thread you started on the MinGW C/C++ forum. > 2. you need an import library for msvcrt.dll, if your VS don't ship > with one you are lost. I already listed in this thread other alternatives for legitimately obtaining an MSVCRT.DLL import library. Ross Ridge -- http://mail.python.org/mailman/listinfo/python-list
Re: MinGW and Python
Martin v. Löwis wrote:
> How would you build for MSVCRT.DLL using MSVC 7 or 8? You don't have
> the header files for that library...
You should be able to use the header files that come with these
compilers. Things like "sizes, field offsets, or member function
names" don't change between versions of the runtime. See the MSDN
library page you refered to earlier:
http://msdn2.microsoft.com/en-us/library/abx4dbyh(VS.80).aspx
>... and you don't have the import library.
I already mentioned where you can get it.
Ross Ridge
--
http://mail.python.org/mailman/listinfo/python-list
Re: documentation for win32com?
John Salerno wrote:
> So does this mean that the code can be different each time, or is there
> still a pre-determined way to refer to things, such as opening Excel,
> reading a spreadsheet and working with it, etc.?
For a given version of Excel, there's a "pre-determinied way" of doing
those things. Different versions of Excel may do things the same way or
differently depending on what exactly you're trying to do.
> If so, where can I find a list of those objects and methods?
In the documentation for the version of Excel you're using.
Ross Ridge
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python DLL in Windows Folder
Ross Ridge writes:
> Whatever you want to call it, the Python DLL is not part of the operating
> system, it's not a driver and doesn't belong in the system directory.
<[EMAIL PROTECTED]> wrote:
>Is that just your personal opinion, or a guideline from the operating
>system vendor?
It's one of Microsoft guidelines. The "'Designed for Microsoft Windows
XP' Application Specification" only allows DLLs to be installed in the
system directory if it's required for backwards compatiblity.
Ross Ridge
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] [EMAIL PROTECTED]
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python DLL in Windows Folder
<[EMAIL PROTECTED]> wrote:
> I think Python perfectly meets the specification (i.e. is designed
>for Windows XP) in this respect (*):
>- python25.dll is a shared component
>- it is not private to a single software vendor
>- it is not a control panel item
>- it is not a service or device driver
>- it does not support side-by-side installation
>- hence, it can be placed in the System directory.
No, that doesn't follow from the requirements given. The only exception
for something that isn't a service or device driver is for backwards
compatibility. Also, pretty much any DLL supports side-by-side
installation.
>The backwards compatibility with "those applications" is necessary, in
>particular with PythonWin (but also with any other software that embeds
>Python).
The backwards compatibility exception doesn't apply when the name of
the DLL changes. If the name of the DLL changes, the shared location
its installed to can also change.
Ross Ridge
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] [EMAIL PROTECTED]
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //
--
http://mail.python.org/mailman/listinfo/python-list
