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.
Ro
antics, 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
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 in
II 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:/
er 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 //
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 ou
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
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
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
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
x27;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
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
d 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
--
at 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
esn'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
s 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
bility), 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?
e 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 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
ell 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] r
erally 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/ // Ro
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
sn'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:/
ython 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.
on
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
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/
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
.
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
s is the same whether the increment
instruction is locked or not.
Ross Ridge
--
http://mail.python.org/mailman/listinfo/python-list
at 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.
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
ce counting isn't thread
safe.
Ross Ridge
--
http://mail.python.org/mailman/listinfo/python-list
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 lon
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.&quo
d 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
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
e 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
pothetical) dot, parenthesises and a name lookup.
Ross Ridge
--
http://mail.python.org/mailman/listinfo/python-list
y 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.
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:
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
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 positio
copyright, just the hints in most
outline fonts, which are considered computer programs.
Ross Ridge
--
http://mail.python.org/mailman/listinfo/python-list
econd 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
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
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
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 th
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
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
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.
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://ww
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 Chin
ion (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
#x27;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 -
ogates, 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 -- T
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
t;, "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 q
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
yways, 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
re 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
--
<[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 lan
>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 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
ight 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
alls 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.uw
;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
riptors, 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
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
odule 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
odule 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
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
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
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
obably 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
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
r 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
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.
ation 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.
columnLayout(adj=True, cat=('both', 2))
for i in layouts:
cmds.button(l=i)
cmds.setParent('..')
cmds.setParent('..')
cmds.setParent('..')
cmds. setParent('
'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.
o 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
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://ww
ing 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 Windo
#x27;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
mno-cygwin" is a
Cygwin application.
Ross Ridge
--
http://mail.python.org/mailman/listinfo/python-list
hat 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
but it is the standard "official" Windows system
C library.
Ross Ridge
--
http://mail.python.org/mailman/listinfo/python-list
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
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", Micros
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.
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 di
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
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
n-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
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.
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
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
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 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
>
he 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
1 - 100 of 195 matches
Mail list logo
