Assertion for python scripts
Howdy ! I started using the assert() stmt and found it quite useful :-) I have only one problem: I don't know how to turn them off again. I know that "-O" turns off assertions in general. However, how do I pass thus parameter to python to an executable script ? I have tried the following: 1. !#/usr/bin/env python -O -> Fails with this msg: /usr/bin/env: python -O: No such file or directory Also, putting it in quotes won't do it. 2. Passing the "-O" to the runnable script won't work either. Here is my question: How do I maintain debug / release builds that allow me to switch debug stmts, like assert, on / off ? Thanx, Matthias -- http://mail.python.org/mailman/listinfo/python-list
Re: Assertion for python scripts
On Nov 2, 12:12 pm, "Matt McCredie" <[EMAIL PROTECTED]> wrote: > On 11/2/07, matthias <[EMAIL PROTECTED]> wrote: > > > > > Howdy ! > > > I started using the assert() stmt and found it quite useful :-) I > > have only one problem: I don't > > know how to turn them off again. > > > I know that "-O" turns off assertions in general. However, how do I > > pass thus parameter to > > python to an executable script ? > > > I have tried the following: > > > 1. > > !#/usr/bin/env python -O > > > -> Fails with this msg: /usr/bin/env: python -O: No such file or > > directory > > > Also, putting it in quotes won't do it. > > > 2. > > Passing the "-O" to the runnable script won't work either. > > > Here is my question: How do I maintain debug / release builds that > > allow me to switch > > debug stmts, like assert, on / off ? > > > Thanx, > > Matthias > > Use: > python -O -mcompileall path > > That command will compile all of the files in the given path and > produce .pyo files. If the .pyo file is present and up-to-date it will > be used instead of the .py file. > > Alternatively you could do this: > > python -O -mpy_compile somefile.py > > which can be used to compile one file at a time. > > Many Python programs and modules include a compile step as part of > their installation process. There is also a -OO option, which will > strip doc-strings as well. > > Matt Thanx for your reply , Matt ! However, I think I am missing something. Here is my example prog, assert.py, with the executable bit set: #!/usr/bin/env python assert 1 > 1, "ASSERTTION !" Running this: # python ./assert.py Traceback (most recent call last): File "assert.py", line 3, in ? assert 1 > 1, "ASSERTTION !" AssertionError: ASSERTTION ! leads to the expected result. Now I do this as you've recommended: # python -O -mpy_compile assert.py This indeed creates a file with the name assert.pyo. That must be the optimized one. Now I try this: # ./assert.py Traceback (most recent call last): File "./assert.py", line 3, in ? assert 1 > 1, "ASSERTTION !" AssertionError: ASSERTTION ! Ok, so it still uses the unoptimized version. Now I try this: # chmod 755 assert.pyo # ./assert.pyo bash: ./assert.pyo: cannot execute binary file Here is my problem: I want to have an optimized executable version of assert.py. I am assuming that I am thinking in an unconventional way wrt Python. If so, then how do you start your optimized python scripts ? Thanx, Matthias -- http://mail.python.org/mailman/listinfo/python-list
Re: Assertion for python scripts
On Nov 2, 1:29 pm, "Bart." <[EMAIL PROTECTED]> wrote: > Friday 02 of November 2007 20:53:12 matthias napisa (a): > > > > > On Nov 2, 12:12 pm, "Matt McCredie" <[EMAIL PROTECTED]> wrote: > > > On 11/2/07, matthias <[EMAIL PROTECTED]> wrote: > > > > Howdy ! > > > > > I started using the assert() stmt and found it quite useful :-) I > > > > have only one problem: I don't > > > > know how to turn them off again. > > > > > I know that "-O" turns off assertions in general. However, how do I > > > > pass thus parameter to > > > > python to an executable script ? > > > > > I have tried the following: > > > > > 1. > > > > !#/usr/bin/env python -O > > > > > -> Fails with this msg: /usr/bin/env: python -O: No such file or > > > > directory > > > > > Also, putting it in quotes won't do it. > > > > > 2. > > > > Passing the "-O" to the runnable script won't work either. > > > > > Here is my question: How do I maintain debug / release builds that > > > > allow me to switch > > > > debug stmts, like assert, on / off ? > > > > > Thanx, > > > > Matthias > > > > Use: > > > python -O -mcompileall path > > > > That command will compile all of the files in the given path and > > > produce .pyo files. If the .pyo file is present and up-to-date it will > > > be used instead of the .py file. > > > > Alternatively you could do this: > > > > python -O -mpy_compile somefile.py > > > > which can be used to compile one file at a time. > > > > Many Python programs and modules include a compile step as part of > > > their installation process. There is also a -OO option, which will > > > strip doc-strings as well. > > > > Matt > > > Thanx for your reply , Matt ! > > > However, I think I am missing something. > > > Here is my example prog, assert.py, with the executable bit set: > > > #!/usr/bin/env python > > > assert 1 > 1, "ASSERTTION !" > > > Running this: > > > # python ./assert.py > > Traceback (most recent call last): > > File "assert.py", line 3, in ? > > assert 1 > 1, "ASSERTTION !" > > AssertionError: ASSERTTION ! > > > leads to the expected result. > > > Now I do this as you've recommended: > > > # python -O -mpy_compile assert.py > > > This indeed creates a file with the name assert.pyo. That must be the > > optimized one. > > > Now I try this: > > > # ./assert.py > > Traceback (most recent call last): > > File "./assert.py", line 3, in ? > > assert 1 > 1, "ASSERTTION !" > > AssertionError: ASSERTTION ! > > > Ok, so it still uses the unoptimized version. > > > Now I try this: > > > # chmod 755 assert.pyo > > # ./assert.pyo > > bash: ./assert.pyo: cannot execute binary file > > > Here is my problem: I want to have an optimized executable version of > > assert.py. > > > I am assuming that I am thinking in an unconventional way wrt Python. > > If so, then > > how do you start your optimized python scripts ? > > > Thanx, > > Matthias > > check this: > > python ./assert.pyo Yes, I know that this works. Thanx. However, that's not what I was going for. Essentially, I am targeting a build system that allows me to build debug / release versions of my Python code. I know how to build the Python code, but how do I package it so that I can simply dump it on the test system with either build type and the same calling interface ? Thanx, Matthias -- http://mail.python.org/mailman/listinfo/python-list
Re: error ...1 value to unpack
On Nov 2, 2:32 pm, "Chris Mellon" <[EMAIL PROTECTED]> wrote:
> On Nov 2, 2007 3:04 PM, Beema shafreen <[EMAIL PROTECTED]> wrote:
>
>
>
> > hi everybody,
> > i have a file:
>
> > A_16_P21360207#304
> > A_14_P136880#783
> > A_16_P21360209#795
> > A_16_P21360210#173
> > A_16_P03641959#1177
> > A_16_P03641960#1944
> > A_16_P03641962#999
> > A_16_P41563648#-31
> > A_16_P03641963#3391
> > A_16_P41563649#3626
> > A_16_P03641964#180
> > A_16_P41563655#1216
> > A_16_P03641965#1170
> > A_16_P03641966#194
> > A_16_P21360229#290
> > A_16_P03641967#425
> > A_16_P21360231#1091
> > A_16_P03641968#1167
> > A_16_P03641969#421
> > A_16_P03641970#63
> > A_16_P21360234#290
> > A_16_P21360235#289
> > A_16_P03641971#398
> > A_16_P21360237#418
> > A_16_P03641972#122
> > A_16_P21360239#16
> > A_16_P03641973#2187
> > A_16_P41563669#2881
> > A_16_P03641974#1101fh = open('complete_span','r')
> > data = fh.readline().split('#')
> > old_probe = data[0].strip()
> > old_value = data[1].strip()
> > #print old_probe, old_value
> > count = 1
> > while fh:
> > current_probe, current_value = fh.readline().strip().split('#')[0:2]
> > probe =current_probe.strip()
> > value = current_value.strip()
> > if old_value > value:
> > res_value='%s\t%s'%(old_value, old_probe)
> > print res_value
> > if count == 244000:
> > break
> > old_probe,old_value =probe, value
> > fh.close()
> > and i face this error:Traceback (most recent call last):
> > File "count_values.py", line 8, in
> > current_probe, current_value = fh.readline().strip().split('#')[0:2]
> > ValueError: need more than 1 value to unpack
>
> > why do i get this what is the solution for this
> > regards
> > shafreen
>
> One of your lines doesn't have a # in it, so split is returning a one
> element list.
No, that's not the problem. The problem is that your algo is
incorrect. fh.readline() returns
a null string at EOF. Thus, the split() functions fails. Personally,
I would rewrite the loop
completely. However this will fix your code :
fh = open('complete_span','r')
data = fh.readline().split('#')
old_probe = data[0].strip()
old_value = data[1].strip()
print old_probe, old_value
count = 1
line = ""
while line:
line = fh.readline().strip()
if line :
current_probe, current_value = line.split('#')[0:2]
probe =current_probe.strip()
value = current_value.strip()
print "probe: [%s], value [%s]" % (probe, value)
if old_value > value:
res_value='%s\t%s'%(old_value, old_probe)
print res_value
if count == 244000:
break
old_probe,old_value =probe, value
fh.close()
--
http://mail.python.org/mailman/listinfo/python-list
PyRun_String
Hello,
I encountered a strange problem today. I try to do this:
Log("Marker 1");
Py_XDECREF( PyRun_String( "print 'Hi!'", Py_single_input, Dict, Dict) );
Log("Marker 2");
The output looks like
Marker 1
Hi!
Hi!
Marker 2
Obviously Hi! is printed twice. I've extracted the above example of a more
complex piece of code where you can clearly see that the statement is
actually executed twice (not only printed). You can also see this with
Log("Marker 1");
Py_XDECREF( PyRun_String( "def func():\n\ti = 0\n\twhile 1:\n\t\tyield
i\n\t\ti += 1\no=func()", Py_file_input, Dict, Dict) );
Py_XDECREF( PyRun_String( "print o.next()", Py_file_input, Dict, Dict) );
Log("Marker 2");
Here the output goes
Marker 1
0
1
Marker 2
What is the reason for this very strange behaviour? Did I do something
wrong?
-Matthias
--
http://mail.python.org/mailman/listinfo/python-list
Re: PyRun_String
Am Thu, 09 Mar 2006 20:06:54 +0100 hat Duncan Booth
<[EMAIL PROTECTED]> geschrieben:
> Matthias wrote:
>
>> Log("Marker 1");
>> Py_XDECREF( PyRun_String( "print 'Hi!'", Py_single_input, Dict, Dict) );
>> Log("Marker 2");
>>
>> The output looks like
>>
>> Marker 1
>> Hi!
>> Hi!
>> Marker 2
>>
>> Obviously Hi! is printed twice.
>
> Py_XDECREF is a C macro. If you check its definition you will see that it
> does indeed evaluate the argument twice. This is a not uncommon problem
> when using macros in C: if in doubt, do not call a macro with anything
> as a parameter which has side effects.
>
> #define Py_XDECREF(op) if ((op) == NULL) ; else Py_DECREF(op)
Arrrghh, I've seen the evil side today; C macros are surely devil-sent. I
spent hours tracking down this bug, I didn't even consider the Py_XDECREF
and concentrated on PyRun_String. It's a pity C doesn't support inline
functions. Thanks a lot for pointing this out before I lost my head,
Duncan!
Maybe Py_XDECREF(op) could be replaced with
#define Py_XDECREF(op) {PyObject* obj = (op); if (obj == NULL) ; else
Py_DECREF(obj)}
but I guess this eats one or two clock cycles too much for other people
who use Py_XDECREF.
Thanks again!
-Matthias
--
http://mail.python.org/mailman/listinfo/python-list
how to do random / SystemRandom switch
Dear list, In my top-level script I want to select if my program is to use random.xxx functions or the random.SystemRandom.xxx ones. All the other modules shouldn't know about that switch and simply use import random ... return random.randint(1, 6) ... for example. In C I would do a similar thing in the Makefile using Compiler-/Link-Options (DEBUG/FINAL Build) switching between two libraries. Any hints are welcome, especially a search term would be very helpful :) Thanks in advance, Matthias Kievernagel. -- http://mail.python.org/mailman/listinfo/python-list
Re: how to do random / SystemRandom switch
Peter Otten <[email protected]> wrote: > Matthias Kievernagel wrote: > >> In my top-level script I want to select if my program >> is to use random.xxx functions or the random.SystemRandom.xxx >> ones. All the other modules shouldn't know about that >> switch and simply use >> import random >> ... >> return random.randint(1, 6) >> ... >> for example. > > You can inject the SystemRandom instance into the sys.modules cache: > >>>> import random >>>> random > >>>> sr = random.SystemRandom() >>>> import sys >>>> sys.modules["random"] = sr > > Then use it in the other modules: > >>>> import random >>>> random > > > Another approach is to monkey-patch the random module: > > import random > sr = random.SystemRandom() > random.randrange = sr.randrange > random.randint = sr.randint > ... > Thanks a lot. That's what I was looking for. I'll give both a try. Regards, Matthias Kievernagel -- http://mail.python.org/mailman/listinfo/python-list
Method to know if object support being weakreferenced ?
Hi all, I was recently had to use weakreferences, using the weakref module, and came across the fact that some object cannot be weakreferenced. If you try to do so you get greated by a TypeError, which is a totally expected and documented behavior. As I tend to prefer the "Look before you leap" approach I search for a method capable of telling me whether an object can be weakreferenced. Which I failed to found. I could of course write a function that try/except and return False/True depending on the result, but that seem suboptimal as how can I know that the TypeError does come from not being able to take a weak reference ? And not from something else ? The common Idiom in CPython, at the C layer seem to be PyType_SUPPORTS_WEAKREFS(Py_TYPE(ob)). So I can (and did) write a C-extension that expose such a function, but it does seem silly that no one else did that before me, and that no one seemed to have encountered the problem before. So am I missing something ? Is such a function not useful ? Is there any reason not to have it in the stdlib ? Thanks. -- M -- https://mail.python.org/mailman/listinfo/python-list
spurious BadDrawable error when running test_tk
Dear list, I changed some detail in the tkinter library, so I'm running the tk test like this: ./python -m test -u gui -v test_tk Approximately every 2 or 3 runs I get a BadDrawable error from the X server, most of the time at the end after the last test finished successfully. As this also happens when I run the test on the unmodified CPython sources I suspect it is a shortcoming of my non-mainstream setup. I use ctwm with interactive window placement, so running the test involves a lot of clicks. Does anyone know if the errors are to be expected or should it work nonetheless? I haven't found anything on b.p.o. about this. Thanks for any insights, Matthias Kievernagel -- https://mail.python.org/mailman/listinfo/python-list
subscribe
-- https://mail.python.org/mailman/listinfo/python-list
The imp module and cyclic imports
Hi All,
I'm having a little bit of trouble using the "imp" module to
dynamically import modules. It seems that somehow cyclic references of
modules don't work.
I'm unable to get the following to work:
I've got the following files:
web/__init__.py
web/one.py
web/two.py
testimport.py
>From which web/one.py contains the line:
from web import two
and web/two.py contains the line:
from web import one
.
Now I try to import one of the two modules in testimport.py:
import imp
(mfile,pathname,description) = imp.find_module("one", ["web"])
m = imp.load_module("one",mfile,pathname,description)
When I start the file testimport.py, I get the following exception:
$ python testimport.py
Traceback (most recent call last):
File "testimport.py", line 3, in ?
m = imp.load_module("one",mfile,pathname,description)
File "web/one.py", line 1, in ?
from web import two
File "/scripts/python/importtest/web/two.py", line 2, in ?
from web import one
File "web/one.py", line 1, in ?
from web import two
ImportError: cannot import name two
It seems that when two.py (referenced by one.py) references one.py
again, something breaks.
I'm lost. Am I doing something wrong, or is this a bug?
Many thanks for any light anybody can shed on this.
Greetings
Matthias
--
http://mail.python.org/mailman/listinfo/python-list
Re: The imp module and cyclic imports
> the problem you're seeing appears also if you use "import web.one"
> or "from web import one" or "__import__('web.one')".
Thanks for the hint. You're right. This isn't actually imp related. The
standard import also fails.
> if you replace the "from web import" statements with plain imports,
> everything will work as expected. just change
>
>from web import one
>
> to
>
> import one
Unfortunately, this fails if one.py and two.py are in different
directories/packages.
With a setup like
web1/one.py
web2/two.py
there doesn't seem to be any way to make one.py and two.py reference
each other via (non-delayed) imports.
It's interesting, though, that cyclic imports work when using the plain
"import foo" import, but not with the "from package import foo" style.
Especially since the former also used to fail (google for "python
cyclic imports" on groups.google.com). I wonder whether the "from"
style imports were overlooked when the cyclic problem was fixed.
Greetings
Matthias
--
http://mail.python.org/mailman/listinfo/python-list
Re: video analysis with python
On Mon, 17 Jan 2005 08:08:46 +0100, "Alexander 'boesi' Bösecke" <[EMAIL PROTECTED]> wrote: >> 1. There is PyMedia (http://pymedia.org/) > >Is this library able to extract single images from a video? AFAICS it >can only convert videos from one format to another. But I didn't try it, >I've looked only in the docu. Yes, you can extract single images from a video. The package uses the avformat and avcodec libraries from ffmpeg and it provides rather low level access to video/audio files. You can access the individual streams in a file, obtain the stream data and decode the data therein. What you do with the data is up to your application. Converting the file into another format is just one such application. - Matthias - -- http://mail.python.org/mailman/listinfo/python-list
ANN: Python Computer Graphics Kit v2.0.0alpha2
The second alpha release of version 2 of the Python Computer Graphics Kit is available at http://cgkit.sourceforge.net What is it? --- The Python Computer Graphics Kit is a generic 3D package written in C++ and Python that can be used for a variety of domains such as scientific visualization, photorealistic rendering, Virtual Reality or even games. The package contains a number of generic modules that can be useful for any application that processes 3D data. This includes new types such as vectors, matrices and quaternions. Furthermore, the package can read and store 3D models in memory where they can be manipulated by Python programs. The kit comes with tools that can be used to display the scene either interactively or by rendering it offline via a RenderMan renderer. What's new? --- - New module "glove" that wraps the 5DT Data Glove SDK - New module "wintab" that wraps the Wintab API to receive data from tablets (Windows only) - New module "spacedevice" that wraps the 3Dconnexion 3DXWare SDK (currently Windows only) - New class: FreeCamera - STL importer added (ASCII and binary) - some bugfixes and minor enhancements (see changelog) Windows binary versions are available for Python 2.3 and Python 2.4. For more information, visit: http://cgkit.sourceforge.net - Matthias - -- http://mail.python.org/mailman/listinfo/python-list
msvcp71.dll and Python 2.4 C++ extensions
Hi, are there any guidelines about what to do if a Windows extension for Python 2.4 requires the C++ runtime (msvcp71.dll)? If I want to distribute a binary installer of an extension that contains C++ code, should I really include the msvcp71.dll in the package? It doesn't sound like a good idea to me if every package places another copy of this dll somewhere in the Python directory. Python 2.4 does install the C runtime (msvcr71.dll) in the Windows system32 directory, doesn't it? (btw, shouldn't this be installed in the Python directory instead?) So would it be possible that future Python releases would also install the C++ runtime? I think it's better if the dll would only be installed once by Python instead of several times by every extension that uses C++. Currently, I do not package the C++ runtime and leave it up to the user to install the dll if it isn't already somewhere on his system. But this really is not a satisfying solution... - Matthias - -- http://mail.python.org/mailman/listinfo/python-list
Re: msvcp71.dll and Python 2.4 C++ extensions
On Tue, 01 Feb 2005 00:14:30 +0100, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: >> are there any guidelines about what to do if a Windows extension for >> Python 2.4 requires the C++ runtime (msvcp71.dll)? > >No; it should "just work fine". [...] I fully agree with that. :) And that was actually the reason why I posted here, because in my case it did not just work fine... >> It doesn't >> sound like a good idea to me if every package places another copy of >> this dll somewhere in the Python directory. > >Why not? If your installer follows Windows logo compliance rules, it >should check whether the DLL is already present; if it is, it should >check whether the version installed is newer than the one it would >install, and if so, should skip installation. I'm creating the installer via the distutils by calling "setup.py bdist_wininst". How can I configure distutils to have it create an installer that does the above things? How should an installer check if a DLL is already present? Are DLLs registered with Windows so I can query a database? Or should the installer search for the DLL in the directories specified in the PATH variable and see if the DLL is there? And what's the preferred location for such a DLL? Should it be placed in a local directory that only belongs to the package or in a directory where other C++ extension packages might also be able to use it? But where would this be then? The Windows system directory seems to be discouraged by Microsoft: "An application should use and redistribute msvcr71.dll, and it should avoid placing a copy or using an existing copy of msvcr71.dll in the system directory. Instead, the application should keep a copy of msvcr71.dll in its application directory with the program executable." (see http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_crt_c_run.2d.time_libraries.asp) I suppose the same applies for msvcp71.dll. >> Python 2.4 does install the C runtime (msvcr71.dll) in the Windows >> system32 directory, doesn't it? > >It depends. If this is an allusers installation, it does so. For a >per-user installation, the user might not have sufficient privileges >to install into system32, so the installer won't install it there. Ah, ok. And yes, I did a "all users" installation. >> (btw, shouldn't this be installed in >> the Python directory instead?) > >No. If you install the DLL into the Python directory, Python >will not work anymore because python24.dll (installed into system32) >will not find this DLL. If you then also move python24.dll into >the Python directory, COM components that require python24.dll will >fail to run. ok, I see. >> So would it be possible that future >> Python releases would also install the C++ runtime? > >Why should it? Nothing in the Python distribution requires C++. Well, yes, I know. But I don't see Python as a standalone application. One of the great things about Python is that there are so many extension modules for every kinds of purposes. So, making available the C++ runtime would just pave the way for more of those extension modules by making it easier to distribute binary packages that are implemented in C++. >> I think it's >> better if the dll would only be installed once by Python instead of >> several times by every extension that uses C++. > >Why is that better? The DLL versioning rules, and the shared DLL >refcounting mechanisms will make sure that the installation works >just fine. I was referring to the possibility that the DLL might get installed several times at several different locations which would be a waste of disk space. If there's only one file, then I agree with the above (however, what happens if I uninstall one package and this package removes the DLL even when there are other packages installed that still require the DLL?). >> Currently, I do not package the C++ runtime and leave it up to the >> user to install the dll if it isn't already somewhere on his system. >> But this really is not a satisfying solution... > >Then you should probably include the DLL, or rewrite your extension >to not use C++. I'm afraid the latter will hardly ever be an option... ;) For one smaller package I was compiling I solved the problem by linking against the static versions of the C/C++ runtime. This will also satisfy the "It-Should-Just-Work" constraint... :) (however, there still could be situations where this is not possible (the sources might not be available, for example)). - Matthias - -- http://mail.python.org/mailman/listinfo/python-list
Re: smtplib and TLS
> From: "Paul Rubin" "http://phr.cx"@NOSPAM.invalid >> "Matthias Kluwe" <[EMAIL PROTECTED]> writes: >> After getting a @gmail.com address, I recognized I had to use TLS in my >> python scripts using smtplib in order to get mail to the smtp.gmail.com >> server. >> [...] >> The server accepts and delivers my messages, but the last command >> raises >> socket.sslerror: (8, 'EOF occurred in violation of protocol') > [...] > Have you verified that its your end that is broken, not gmail's, do other > servers give the same response ? No, I have not -- I should have, as I know now: Connecting, starttls, login and sending mail works fine without the above mentioned error using my previous mail provider. Does that mean Gmail is in error here? I don't know... Regards, Matthias -- http://mail.python.org/mailman/listinfo/python-list
ANN: Python Computer Graphics Kit v2.0.0alpha4
The fourth alpha release of version 2 of the Python Computer Graphics Kit is available at http://cgkit.sourceforge.net What is it? --- The Python Computer Graphics Kit is a generic 3D package written in C++ and Python that can be used for a variety of domains such as scientific visualization, photorealistic rendering, Virtual Reality or even games. The package contains a number of generic modules that can be useful for any application that processes 3D data. This includes new types such as vectors, matrices and quaternions. Furthermore, the package can read and store 3D models in memory where they can be manipulated by Python programs. The kit comes with tools that can be used to display the scene either interactively or by rendering it offline via a RenderMan renderer. What's new? --- - The render tool can now also be used to bake texture maps (using the technique from the Stupid RAT Tricks 2001 by J. Litt and D. Goldman, so no special renderer functionality required). A tutorial is available on the web site: http://cgkit.sourceforge.net/tutorials/baking/baking.html) - PLY import and export using Diego Nehab's RPly library - A Maya .ma file parser and partial support for importing the contents of a .ma file (polys without history, cameras, lights, skeletons, ...) - The near and far plane of the cameras can now be controlled explicitly - New RMLightSource object that wraps a RenderMan light source shader - A new MEL script to export ASF/AMC files + several other enhancements and bugfixes (see changelog) Windows binary versions are available for Python 2.3 and Python 2.4. For more information, visit: http://cgkit.sourceforge.net - Matthias - -- http://mail.python.org/mailman/listinfo/python-list
Re: turn text lines into a list
Xah Lee (27.06.2005 12:33): > i have a large number of lines i want to turn into a list. > In perl, i can do > > @corenames=qw( > rb_basic_islamic > sq1_pentagonTile > sq_arc501Tile > sq_arc503Tile > ); > > use Data::Dumper; > print Dumper([EMAIL PROTECTED]); > > -- > is there some shortcut to turn lines into list in Python? txt = """rb_basic_islamic sq1_pentagonTile sq_arc501Tile sq_arc503Tile""" print txt.splitlines() Matthias -- http://mail.python.org/mailman/listinfo/python-list
Re: f*cking re module
jwaixs (04.07.2005 10:04):
> arg... I've lost 1.5 hours of my precious time to try letting re work
> correcty. There's really not a single good re tutorial or documentation
> I could found!
Did you try this one?
http://www.amk.ca/python/howto/regex/regex.html
>>>>import re
>>>>str = "blablaRe modules sucks!blabla"
>>>>re.search("()(/python>)", str).group()
>
> Traceback (most recent call last):
> File "", line 1, in ?
> AttributeError: 'NoneType' object has no attribute 'group'
RE doesn't find "()(/python>)" because it isn't in your string.
That's why group fails.
>>> import re
>>> s = "blablaRe module is great!blabla"
>>> re.search("().*(/python>)", s).group()
'Re module is great!'
Matthias
--
http://mail.python.org/mailman/listinfo/python-list
Re: Scipy - Latex Annotations in plots
Unfortunately matplotlib is only a 2D-plotting library. Do you know another one with 3D-capabilities as well? That would be very nice, thank you, Matthias Robert Kern wrote: > fortuneteller wrote: >> Hello, >> >> I'm quite new to python and Scipy. >> Anyway I want to use it to plot graphs. >> Does anybody know if there is the possibility to use Latex in SciPy's >> plotting functions like gplt? > > I don't believe so. matplotlib, however, does have this functionality in > recent releases. > -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expresiveness in a Computer Language?
Steven D'Aprano <[EMAIL PROTECTED]> writes: >On Sun, 10 Jul 2005 07:20:34 -0700, raptor wrote: > >> I think u are wrong.. I think perl is much more exrpressive in >> semantics than Python.. > >Well, with such great command of natural language as you are displaying, >how could anyone argue with your conclusion? Folks, Xah Lee is a known troll.. don't get into any arguments among yourselves over anything that person writes. mkb. -- http://mail.python.org/mailman/listinfo/python-list
Re: Jargons of Info Tech industry
[EMAIL PROTECTED] writes: >In comp.lang.perl.misc Xah Lee <[EMAIL PROTECTED]> wrote: >> The other class of jargon stupidity is from computing practitioners, of >> which the Unix/Perl community is exemplary. For example, the name Unix >> & Perl themselves are good examples of buzzing jargons. Unix is >> supposed to be opposed of Multics and hints on the offensive and >> tasteless term eunuchs. > >Now that connexion is a product of a truely warped mind. and one devoid of any trace of humour. mkb. -- http://mail.python.org/mailman/listinfo/python-list
ANN: Python Computer Graphics Kit v2.0.0alpha5
The fifth alpha release of version 2 of the Python Computer Graphics Kit is available at http://cgkit.sourceforge.net What is it? --- The Python Computer Graphics Kit is a generic 3D package written in C++ and Python that can be used for a variety of domains such as scientific visualization, photorealistic rendering, Virtual Reality or even games. The package contains a number of generic modules that can be useful for any application that processes 3D data. This includes new types such as vectors, matrices and quaternions. Furthermore, the package can read and store 3D models in memory where they can be manipulated by Python programs. The kit comes with tools that can be used to display the scene either interactively or by rendering it offline via a RenderMan renderer. What's new? --- - Easier usage as external dependencies are delayed until they are really used. This makes it easier to use most parts of the package even when you do not have PIL or PyOpenGL installed. - To further ease installation you can opt to install a 'light' version which is implemented in pure Python. This light version only has limited functionality (basically it provides the functionality of cgkit1) but it has no dependencies at all (neither at runtime nor at installation time (no C/C++ compiler required!)) and runs virtually anywhere (this should also work on your mobile phone :). - New BezierCurve object that is modelled after the spline shape in MAX (MAX spline shapes can actually be exported with a special maxscript). - New MotionPath component to animate objects or sample curves at regular intervals. - The RMShader class does not need an external preprocessor anymore (which makes life easier for Windows user). - + quite a few more enhancements and bugfixes (see the changelog). Windows binary versions are available for Python 2.3 and Python 2.4. For more information, visit: http://cgkit.sourceforge.net - Matthias - -- http://mail.python.org/mailman/listinfo/python-list
Re: Python versus Perl
Hi! > [...] > 1 - How does the speed of execution of Perl compares to that of Python? This might not answer your question, but I found "The Computer Language Shootout Benchmarks" quite interesting (and fun). Python to Perl comparison can be found at http://shootout.alioth.debian.org/benchmark.php?test=all&lang=python&sort=fullcpu Regards, Matthias -- http://mail.python.org/mailman/listinfo/python-list
Re: Confused with methods
Hi Gerald,
When you define an instance method, the first parameter (in the
definition) represents the instance. By convention, you would name it
"self":
#
class B:
def foo(self, x):
print "we have two parameters: " + str(self) + " and " + x
#
then calling
##
b = B()
b.foo("x")
##
would be equivalent to
##
b = B()
B.foo(b, "x")
##
So, as you have noted, you need at least one parameter to attach the
method to an instance. This is because the instance _is_ the parameter.
Python does this for you internally.
For more documentation you should read the paragraph about classes in
the tutorial.
Regards,
Matthias
--
http://mail.python.org/mailman/listinfo/python-list
ANN: Python Computer Graphics Kit v2.0.0alpha1
The first alpha release of version 2 of the Python Computer Graphics Kit is available at http://cgkit.sourceforge.net There are still a lot of things missing, but on the other hand, there is also quite a lot that is already working and that might make the current version useful nevertheless. What is it? --- The Python Computer Graphics Kit is a generic 3D package written in C++ and Python that can be used for a variety of domains such as scientific visualization, photorealistic rendering, Virtual Reality or even games. The package contains a number of generic modules that can be useful for any application that processes 3D data. This includes new types such as vectors, matrices and quaternions. Furthermore, the package can read and store 3D models in memory where they can be manipulated by Python programs. The kit comes with tools that can be used to display the scene either interactively or by rendering it offline via a RenderMan renderer. What's new? --- The new version of the kit can store 3D data in memory where it can be manipulated via Python programs. The new main features are: - 3D data can be stored and manipulated in memory - Imports 3DS, VRML, X3D, OFF, IFS - Exports RIB (shaders are generated on-the-fly) - Create 3D scenes via Python scripting - Interactive OpenGL viewer tool - OpenGL stereo output (vertical split or quad buffer) - Offline render tool that feeds a RenderMan renderer - Use the latest graphics card features using the interactive OGRE viewer tool (not included in the Windows binary) - Connect arbitrary attributes of the same type to create animations - Rigid body dynamics via the Open Dynamics Engine - Extensible via regular modules or plugins For more information, visit: http://cgkit.sourceforge.net - Matthias - -- http://mail.python.org/mailman/listinfo/python-list
Re: Regexp problem, which pattern to use in split
Hans Almåsbakk (14.12.2004 16:02): Any pointer will be greatly appreciated. Maybe I'm attacking this problem the wrong way already from the start? (Not that I can see another way myself :) Hans, did you try the csv module in the Python library? Matthias -- http://mail.python.org/mailman/listinfo/python-list
MySQLdb & Python 2.4 on Windows
Hello Yesterday I installed Python 2.4. Since I often work with MySQL, I need the MySQLdb module, wich worked fine under 2.3. Now, it doesn't work under 2.4, it says it needs python 2.3 when I try to install the module. Now I have some (rather nooby) questions: 1. Has anyone tried installing MySQLdb 1.0 under Python 2.4 and has he succeeded? Please let me know how to do it or where I can find more information. 2. Is it possible to use Python 2.4 & 2.3 next to each other without conflicts? This is probably not a real descent solution... It wouldn't be a problem to downgrade to 2.3, but since 2.4 works fine too, I don't see why I shouldn't use it, if I don't mind the MySQL problems of course. Thanks in advance! Matthias -- http://mail.python.org/mailman/listinfo/python-list
Re: MySQLdb & Python 2.4 on Windows
Fredrik Lundh schreef: Matthias Verniers wrote: 2. Is it possible to use Python 2.4 & 2.3 next to each other without conflicts? yes, assuming "next to each other" means "on the same machine". but binary extensions are bound to the Python version they were built for; you cannot use a 2.3 extension with 2.4 on windows. Yes, that is what I mean. I think I will switch back to 2.3 for a while, untill MySQLdb can work with 2.4 or untill I find a way to use it with 2.4. Thanks for your help! Matthias -- http://mail.python.org/mailman/listinfo/python-list
Re: MySQLdb & Python 2.4 on Windows
Steve Holden schreef: Fredrik Lundh wrote: Matthias Verniers wrote: 2. Is it possible to use Python 2.4 & 2.3 next to each other without conflicts? yes, assuming "next to each other" means "on the same machine". but binary extensions are bound to the Python version they were built for; you cannot use a 2.3 extension with 2.4 on windows. Using the recently-publicized methods for the using the freely-available (i.e. costless) Microsoft tool chain I managed to create a Windows installer for MySQLdb-1.1.4. If anyone's interested in this I guess I could post it on a web site and/or let Andy Dustman have a copy. [pauses to check that the module actually imports and works ...] Yep, works fine for a small test ;-) so I'm mailing it to Andy next thing I do. regards Steve Good job! It would be nice if I could have a copy of your installer. I am one of the interested people ;-) Regards Matthias -- http://mail.python.org/mailman/listinfo/python-list
Re: MySQLdb & Python 2.4 on Windows
Steve Holden schreef: Matthias Verniers wrote: [...] Good job! It would be nice if I could have a copy of your installer. I am one of the interested people ;-) Regards As I reported, I've shipped a copy of the installer to Andy Dustman, so it will appear on SourceForge in due course. For those who can't wait, there's a copy at http://pydish.holdenweb.com/pwp/MySQL-python.exe-1.0.0.win32-py2.4.exe Enjoy! regards Steve Thanks a lot! I just installed it and it works fine! Good job! I think many people will be happy with this :-) Regards Matthias -- http://mail.python.org/mailman/listinfo/python-list
ANN: Python Computer Graphics Kit v2.0.0alpha3
The third alpha release of version 2 of the Python Computer Graphics Kit is available at http://cgkit.sourceforge.net What is it? --- The Python Computer Graphics Kit is a generic 3D package written in C++ and Python that can be used for a variety of domains such as scientific visualization, photorealistic rendering, Virtual Reality or even games. The package contains a number of generic modules that can be useful for any application that processes 3D data. This includes new types such as vectors, matrices and quaternions. Furthermore, the package can read and store 3D models in memory where they can be manipulated by Python programs. The kit comes with tools that can be used to display the scene either interactively or by rendering it offline via a RenderMan renderer. What's new? --- - New polyhedron geometry (made up of general concave polygons that may have holes) - New storage classes FACEVARYING and FACEVERTEX for primitive variables - OBJ import and export (including the material files) - OFF export and improved import - ASF/AMC import - BVH import - an additional maxscript that exports a Biped skeleton and motion into ASF/AMC + several smaller enhancements and bugfixes (see changelog) Windows binary versions are available for Python 2.3 and Python 2.4. For more information, visit: http://cgkit.sourceforge.net - Matthias - -- http://mail.python.org/mailman/listinfo/python-list
Re: Python application for rpm creation
On 11/27/2013 03:28 AM, Amit Saha wrote: > On Wed, Nov 27, 2013 at 1:39 AM, Unix SA wrote: >> >>> Sounds to me more like he is looking to package some other in house >>> software, as opposed to packaging python specific libraries, etc.. >> >> - Yes, This is exactly i am looking at >> >> >>> Doing an apt-cache search on my Ubuntu desktop results with a project, >>> Spectacle, coincidentally written in Python. (I haven't really looked > into >>> it): >>> http://meego.gitorious.org/meego-developer-tools/spectacle >> >> this looks useful, i shall looking to this... or may be try myself writing >> something. >> >> if you guys ( others ) got something else for Redhat Linux rpm creation do >> let me know. > > I played with creating a RPM SPEC file "generator" for Sphinx documentation: > https://github.com/amitsaha/sphinx_doc_packaging > > It's written in Python, so perhaps may help with you a starting point. > > Best, > Amit. > > In Fedora (and IMHO in EPEL, too) there is a package named pyp2rpm. This is quite handy. It fetches sources from pypi, writes a basic SPEC file, which might need minor tweaks, but in general, it really saves you time. Matthias -- https://mail.python.org/mailman/listinfo/python-list
Re: [Python-ideas] Wheels For ...
Hi Sven, Just adding a few comments inline: On Sun, Sep 6, 2015 at 7:33 PM, Sven R. Kunze wrote: > 3) more than one way to do (upload, wheel, source/binary etc.) it (sigh) And most are uploading/registering over http (sight) > nope: what a pity for wheels; example: > https://github.com/simplejson/simplejson/issues/122 But that's for non pure-python wheels, wheel can be universal, in which case they are easy to build. > Why do developers need to build their distribution themselves? Historical reason. On GitHub, at least it is pretty easy to make Travis-CI build your wheels, some scientific packages (which are not the easier to build) have done that, so automation is possible. And these case need really particular environements where all aspects of the builds are controlled. > > I had not real answer to him, but pondering a while over it, I found it > really insightful. Viewing this from a different angle, packaging your own > distribution is actually a waste of time. It is a tedious, error-prone task > involving no creativity whatsoever. Developers on the other hand are > actually people with very little time and a lot of creativity at hand which > should spend better. The logical conclusion would be that PyPI should build > wheels for the developers for every python/platform combination necessary. I think that some of that could be done by warehouse at some point: https://github.com/pypa/warehouse But you will never be able to cover all. I'm sure people will ask PyPI to build for windows 98 server version otherwise. Personally for pure python packages I know use https://pypi.python.org/pypi/flit which is one of the only packaging tools for which I can remember all the step to get a package on PyPI without reading the docs. -- M [Sven, sorry for duplicate :-) ] -- https://mail.python.org/mailman/listinfo/python-list
Re: Python ORM library for distributed mostly-read-only objects?
Hi, William Ray Wing: > Are you sure it won’t fit in memory? Default server memory configs these > days tend to start at 128 Gig, and scale to 256 or 384 Gig. > I am not going to buy a new server. I can justify writing a lot of custom code for that kind of money. Besides, the time to actually load all the data into memory beforehand would be prohibitive (so I'd still need a way to load referred data on demand), and the update problem remains. -- -- Matthias Urlichs -- https://mail.python.org/mailman/listinfo/python-list
Re: Easiest framework to develop simple interactive web site in python?
Am 12.09.2011 16:03, schrieb John Reid: I don't have much experience writing web sites or applications. Can anyone recommend a python framework that will allow me to easily write a few pages? You want a simple framework? Try Bottle: http://bottlepy.org/ Matthias -- http://mail.python.org/mailman/listinfo/python-list
Pygtk entry readline
Hi, does anybody know howto connect / use a gtk entry as "frontend" for readline in- / output? I couldn't find anything on the net for my problem. Basicly I've a working readline autocomplete, which I can use without problems via input function, but I want to use that in an gtk gui inside an entry or textbox, etc. Thanks, Matthias -- Wer A sagt, der muss nich B sagen, Er kann auch erkennen, dass A falsch war. GPG key: 1814DA35 -- http://mail.python.org/mailman/listinfo/python-list
Re: [TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages
On Apr 14, 2013, at 11:48 PM, Mark Janssen wrote: > After the 2001 "type/class unification" , it went towards Alan Kay's ideal Are you sure? Remember Kay's two motivations [*], which he so elegantly describes with "[the] large scale one was to find a better module scheme for complex systems involving hiding of details, and the small scale one was to find a more flexible version of assignment, and then to try to eliminate it altogether." At least for me, this quote sends a signal to language designers that is still looking for a receiver -- Matthias [*] http://gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html -- http://mail.python.org/mailman/listinfo/python-list
OO in Python? ^^
Hi, sorry for my ignorance, but after reading the Python tutorial on python.org, I'm sort of, well surprised about the lack of OOP capabilities in python. Honestly, I don't even see the point at all of how OO actually works in Python. For one, is there any good reason why I should ever inherit from a class? ^^ There is no functionality to check if a subclass correctly implements an inherited interface and polymorphism seems to be missing in Python as well. I kind of can't imagine in which circumstances inheritance in Python helps. For example: class Base: def foo(self): # I'd like to say that children must implement foo pass class Child(Base): pass # works Does inheritance in Python boil down to a mere code sharing? And how do I formulate polymorphism in Python? Example: class D1(Base): def foo(self): print "D1" class D2(Base): def foo(self): print "D2" obj = Base() # I want a base class reference which is polymorphic if (): obj = D1() else: obj = D2() I could as well leave the whole inheritance stuff out and the program would still work (?). Please give me hope that Python is still worth learning :-/ Regards, Matthias -- http://mail.python.org/mailman/listinfo/python-list
Re: OO in Python? ^^
Heiko Wundram wrote:
> Brian Beck wrote:
>
>>>class D1(Base):
>>> def foo(self):
>>> print "D1"
>>>
>>>class D2(Base):
>>> def foo(self):
>>> print "D2"
>>>obj = Base() # I want a base class reference which is polymorphic
>>>if ():
>>> obj = D1()
>>>else:
>>> obj = D2()
>>
>>I have no idea what you're trying to do here and how it relates to
>>polymorphism.
>>
>
>
> He's translating C++ code directly to Python. obj = Base() creates a
> variable of type Base(), to which you can assign different object types (D
> (), D2()) which implement the Base interface (are derived from Base).
> Err... At least I think it's what this code is supposed to mean...
>
> In C++ you'd do:
>
> Base *baseob;
>
> if( ) {
> baseob = (Base*)new D1();
> } else {
> baseob = (Base*)new D2();
> }
>
> baseob->foo();
>
> (should, if foo is declared virtual in Base, produce "d1" for D1, and "d2"
> for D2)
>
> At least IIRC, it's been quite some time since I programmed C++... ;-)
> *shudder*
Yes, that's what I tried to express (the cast to Base* is redundant here
by the way, since D1/D2 are also of type Base; you can always hold a
base class pointer to derived types without type conversion).
I have also read the other answers to my question, and I am really sorry
if I have sounded ignorant in my post, but it's harder than I thought to
move to a language where all these techniques one had learned in years
of hard work suddenly become redundant :)
I'm so used to statically typed languages that the shift is very
confusing. Looks as if it isn't as easy to learn Python afterall, for
the mere reason of unlearning rules which don't apply in the world of
Python anymore (which seem to be quite a lot!).
Regards,
Matthias
--
http://mail.python.org/mailman/listinfo/python-list
Re: OO in Python? ^^
Brian Beck wrote:
> def foo(self):
> raise NotImplementedError("Subclasses must implement foo")
That's actually a good idea, though not as nice as a check at
"compile-time" (jesus, I'm probably talking in C++ speech again, is
there such a thing as compile-time in Python at all?!)
Another thing which is really bugging me about this whole dynamically
typing thing is that it seems very error prone to me:
foo = "some string!"
# ...
if (something_fubar):
fo = "another string"
Oops, the last 'o' slipped, now we have a different object and the
interpreter will happily continue executing the flawed program.
I really see issues with this, can anyone comment on this who has been
working with Python more than just a day (like me)?
Regards,
Matthias
--
http://mail.python.org/mailman/listinfo/python-list
Re: OO in Python? ^^
That was quite insightful Martin, thanks. Regards, Matthias -- http://mail.python.org/mailman/listinfo/python-list
Re: OO in Python? ^^
gene tani wrote: > http://naeblis.cx/rtomayko/2004/12/15/the-static-method-thing > http://dirtsimple.org/2004/12/java-is-not-python-either.html > http://dirtsimple.org/2004/12/python-is-not-java.html > > http://idevnews.com/PrintVersion_CaseStudies.asp?Search3=web+services&Go2=Go&ID=118 > http://www.idevnews.com/PrintVersion_TipsTricks.asp?ID=107 > http://www.eros-os.org/pipermail/e-lang/2001-June/005337.html First of all, thanks everybody for posting all these answers and links, much appreciated. What Bruce Eckel wrote about dynamic typing was quite convincing and reasonable. I stumbled over this paragraph in "Python is not Java", can anyone elaborate on it: "In Java, you have to use getters and setters because using public fields gives you no opportunity to go back and change your mind later to using getters and setters. So in Java, you might as well get the chore out of the way up front. In Python, this is silly, because you can start with a normal attribute and change your mind at any time, without affecting any clients of the class. So, don't write getters and setters." Why would I want to use an attribute in Python, where I would use getters and setters in Java? I know that encapsulation is actually just a hack in Python (common, "hiding" an implementation detail by prefixing it with the classname so you can't access it by its name anymore? Gimme a break...), but is that a reason to only write white box classes? ^^ - Matthias -- http://mail.python.org/mailman/listinfo/python-list
Re: OO in Python? ^^
[EMAIL PROTECTED] wrote: > Just follow the links. I'll try ;-) -- http://mail.python.org/mailman/listinfo/python-list
PyXML: SAX vs. DOM
Hi, I have to say I am confused about the documentation on pyxml.sf.net. When I want to use DOM, I effectively am using a class called Sax2? ^^ I also have to catch SAXExceptions, which reside in xml.sax._exceptions. I thought DOM and SAX are two completely different things. Why is PyXML mixing them up like this? Thanks, Matthias -- http://mail.python.org/mailman/listinfo/python-list
Re: PyXML: SAX vs. DOM
Oh and: Where can I find an API reference for PyXML? Am I supposed to /guess/ which methods and attributes e.g. Sax2 supplies? :D Thanks again, Matthias -- http://mail.python.org/mailman/listinfo/python-list
Re: PyXML: SAX vs. DOM
Steven Bethard wrote: > I don't have an answer to your real question, but if you're not > committed to a particular XML package yet, you might consider ElementTree: > http://effbot.org/zone/element-index.htm > > The API is much simpler, and the package has a much more sane > organization. ;) Plus, it will be part of the Python standard library > in Python 2.5. That sounds great, thanks. Regards, Matthias -- http://mail.python.org/mailman/listinfo/python-list
Re: PyXML: SAX vs. DOM
Ivan Herman wrote: > I know this is not the ideal answer, but maybe it helps... It does, thanks Ivan. Regards, Matthias -- http://mail.python.org/mailman/listinfo/python-list
yEnc
How can i encode with yEnc? -- http://mail.python.org/mailman/listinfo/python-list
Simple question to split
Hi, I have a simple question. When I read in a string like: a='1,2,3,4,5 6 7,3,4', can I get the list l=[1,2,3,4,5,6,7,3,4] with a single split-call? Thx, Matthias -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Darren New <[EMAIL PROTECTED]> writes: > Joachim Durchholz wrote: >> Give a heterogenous list that would to too awkward to live in a >> statically-typed language. > > Printf()? Very good statically typed versions of printf exist. See, e.g., Danvy's unparsing combinators. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Darren New <[EMAIL PROTECTED]> writes: > Matthias Blume wrote: >> Very good statically typed versions of printf exist. See, e.g., >> Danvy's unparsing combinators. > > That seems to ignore the fact that the pattern is a string, which > means that printf's first argument in Danvy's mechanism has to be a > literal. In Danvy's solution, the format argument is not a string. > You can't read the printf format from a configuration file > (for example) to support separate languages. You don't need to do that if you want to support separate languages. Moreover, reading the format string from external input is a good way of opening your program to security attacks, since ill-formed data on external media are then able to crash you program. > It doesn't look like the > version of printf that can print its arguments in an order different > from the order provided in the argument list is supported either; > something like "%3$d" or some such. I am not familiar with the version of printf you are refering to, but I am sure one could adapt Danvy's solution to support such a thing. > Second, what's the type of the argument that printf, sprintf, fprintf, > kprintf, etc all pass to the subroutine that actually does the > formatting? (Called vprintf, I think?) Obviously, a Danvy-style solution (see, e.g., the one in SML/NJ's library) is not necessarily structured that way. I don't see the problem with typing, though. Matthias -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
George Neuner writes: > I am, however, going to ask what > information you think type inference can provide that substitutes for > algorithm or data structure exploration. Nobody wants to do such a substitution, of course. In /my/ experience, however, I find that doing algorithm and data structure exploration is greatly aided by a language with static types and type inference. YMMV. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
"Rob Thorpe" <[EMAIL PROTECTED]> writes:
> I don't think dynamic typing is that nebulous. I remember this being
> discussed elsewhere some time ago, I'll post the same reply I did then
> ..
>
>
> A language is statically typed if a variable has a property - called
> it's type - attached to it, and given it's type it can only represent
> values defined by a certain class.
By this definition, all languages are statically typed (by making that
"certain class" the set of all values). Moreover, this "definition",
when read the way you probably wanted it to be read, requires some
considerable stretch to accommodate existing static type systems such
as F_\omega.
Perhaps better: A language is statically typed if its definition
includes (or ever better: is based on) a static type system, i.e., a
static semantics with typing judgments derivable by typing rules.
Usually typing judgmets associate program phrases ("expressions") with
types given a typing environment.
> A language is latently typed if a value has a property - called it's
> type - attached to it, and given it's type it can only represent values
> defined by a certain class.
This "definition" makes little sense. Any given value can obviously
only represent one value: itself. "Dynamic types" are nothing more
than sets of values, often given by computable predicates.
> Untyped and type-free mean something else: they mean no type checking
> is done.
Look up "untyped lambda calculus".
--
http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Pascal Costanza <[EMAIL PROTECTED]> writes:
> Matthias Blume wrote:
>> "Rob Thorpe" <[EMAIL PROTECTED]> writes:
>>
>>> I don't think dynamic typing is that nebulous. I remember this being
>>> discussed elsewhere some time ago, I'll post the same reply I did then
>>> ..
>>>
>>>
>>> A language is statically typed if a variable has a property - called
>>> it's type - attached to it, and given it's type it can only represent
>>> values defined by a certain class.
>> By this definition, all languages are statically typed (by making
>> that
>> "certain class" the set of all values). Moreover, this "definition",
>> when read the way you probably wanted it to be read, requires some
>> considerable stretch to accommodate existing static type systems such
>> as F_\omega.
>> Perhaps better: A language is statically typed if its definition
>> includes (or ever better: is based on) a static type system, i.e., a
>> static semantics with typing judgments derivable by typing rules.
>> Usually typing judgmets associate program phrases ("expressions") with
>> types given a typing environment.
>
> How does your definition exclude the trivial type system in which the
> only typing judgment states that every expression is acceptable?
It does not.
--
http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Pascal Costanza <[EMAIL PROTECTED]> writes: > - In a dynamically typed language, you can run programs successfully > that are not acceptable by static type systems. This statement is false. For every program that can run successfully to completion there exists a static type system which accepts that program. Moreover, there is at least one static type system that accepts all such programs. What you mean is that for static type systems that are restrictive enough to be useful in practice there always exist programs which (after type erasure in an untyped setting, i.e., by switching to a different language) would run to completion, but which are rejected by the static type system. By the way, the parenthetical remark is important: If a language's definition is based on a static type system, then there are *no* programs in that language which are rejected by its type checker. That's trivially so because strings that do not type-check are simply not considered programs. > Here is an example in Common Lisp: > > ; A class "person" with no superclasses and with the only field "name": > (defclass person () >(name)) > > ; A test program: > (defun test () >(let ((p (make-instance 'person))) > (eval (read)) > (slot-value p 'address))) > > (slot-value p 'address) is an attempt to access the field 'address in > the object p. In many languages, the notation for this is p.address. > > Although the class definition for person doesn't mention the field > address, the call to (eval (read)) allows the user to change the > definition of the class person and update its existing > instances. Therefore at runtime, the call to (slot-value p 'adress) > has a chance to succeed. I am quite comfortable with the thought that this sort of evil would get rejected by a statically typed language. :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
David Squire <[EMAIL PROTECTED]> writes: > Andreas Rossberg wrote: >> Rob Thorpe wrote: > No, that isn't what I said. What I said was: > "A language is latently typed if a value has a property - called it's > type - attached to it, and given it's type it can only represent values > defined by a certain class." "it [= a value] [...] can [...] represent values"? >>> >>> ??? >> I just quoted, in condensed form, what you said above: namely, that >> a value represents values - which I find a strange and circular >> definition. >> > > But you left out the most significant part: "given it's type it can > only represent values *defined by a certain class*" (my emphasis). In > C-ish notation: > > unsigned int x; > > means that x can only represent elements that are integers elements of > the set (class) of values [0, MAX_INT]. Negative numbers and > non-integer numbers are excluded, as are all sorts of other things. This x is not a value. It is a name of a memory location. > You over-condensed. Andreas condensed correctly. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
"Rob Thorpe" <[EMAIL PROTECTED]> writes: > Andreas Rossberg wrote: >> Rob Thorpe wrote: >> >> >> >>>No, that isn't what I said. What I said was: >> >>>"A language is latently typed if a value has a property - called it's >> >>>type - attached to it, and given it's type it can only represent values >> >>>defined by a certain class." >> >> >> >>"it [= a value] [...] can [...] represent values"? >> > >> > ??? >> >> I just quoted, in condensed form, what you said above: namely, that a >> value represents values - which I find a strange and circular definition. > > Yes, but the point is, as the other poster mentioned: values defined by > a class. > For example, in lisp: > "xyz" is a string, #(1 2 3) is an array, '(1 2 3) is a list, 45 is a > fixed-point number. > Each item that can be stored has a type, no item can be stored without > one. The types can be tested. Most dynamic typed languages are like > that. Your "types" are just predicates. > Compare this to an untyped language where types cannot generally be > tested. You mean there are no predicates in untyped languages? >> They all have - the whole purpose of a type system is to ensure that any >> expression of type T always evaluates to a value of type T. > > But it only gaurantees this because the variables themselves have a > type, the values themselves do not. Of course they do. > Most of the time the fact that the > variable they are held in has a type infers that the value does too. > But the value itself has no type, in a C program for example I can take > the value from some variable and recast it in any way I feel and the > language cannot correct any errors I make because their is no > information in the variable to indicate what type it is. Casting in C takes values of one type to values of another type. >> So when you >> look at type systems formally then you certainly have to assign types to >> values, otherwise you couldn't prove any useful property about those >> systems (esp. soundness). > > Yes, but indirectly. No, this is usually done very directly and very explicitly. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
David Squire <[EMAIL PROTECTED]> writes: > Matthias Blume wrote: >> David Squire <[EMAIL PROTECTED]> writes: >> >>> Andreas Rossberg wrote: >>>> Rob Thorpe wrote: >>>>>>> No, that isn't what I said. What I said was: >>>>>>> "A language is latently typed if a value has a property - called it's >>>>>>> type - attached to it, and given it's type it can only represent values >>>>>>> defined by a certain class." >>>>>> "it [= a value] [...] can [...] represent values"? >>>>> ??? >>>> I just quoted, in condensed form, what you said above: namely, that >>>> a value represents values - which I find a strange and circular >>>> definition. >>>> >>> But you left out the most significant part: "given it's type it can >>> only represent values *defined by a certain class*" (my emphasis). In >>> C-ish notation: >>> >>> unsigned int x; >>> >>> means that x can only represent elements that are integers elements of >>> the set (class) of values [0, MAX_INT]. Negative numbers and >>> non-integer numbers are excluded, as are all sorts of other things. >> This x is not a value. It is a name of a memory location. >> >>> You over-condensed. >> Andreas condensed correctly. > > I should have stayed out of this. I had not realised that it had > degenerated to point-scoring off someone typing "value" when it is > clear from context that he meant "variable". If he really had meant "variable" then he would have been completely wrong. > Bye. Bye. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
"Rob Thorpe" <[EMAIL PROTECTED]> writes: > I think we're discussing this at cross-purposes. In a language like C > or another statically typed language there is no information passed > with values indicating their type. You seem to be confusing "does not have a type" with "no type information is passed at runtime". > Have a look in a C compiler if you don't believe me. Believe me, I have. > No it doesn't. Casting reinterprets a value of one type as a value of > another type. > There is a difference. If I cast an unsigned integer 20 to a > signed integer in C on the machine I'm using then the result I will get > will not make any sense. Which result are you getting? What does it mean to "make sense"? -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Joachim Durchholz <[EMAIL PROTECTED]> writes:
> Matthias Blume schrieb:
>> Perhaps better: A language is statically typed if its definition
>> includes (or ever better: is based on) a static type system, i.e., a
>> static semantics with typing judgments derivable by typing rules.
>> Usually typing judgmets associate program phrases ("expressions") with
>> types given a typing environment.
>
> This is defining a single term ("statically typed") using three
> undefined terms ("typing judgements", "typing rules", "typing
> environment").
This was not meant to be a rigorous definition. Also, I'm not going
to repeat the textbook definitions for those three standard terms
here. Next thing you are going to ask me to define the meaning of the
word "is"...
--
http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
"Rob Thorpe" <[EMAIL PROTECTED]> writes: > Matthias Blume wrote: >> "Rob Thorpe" <[EMAIL PROTECTED]> writes: >> >> > I think we're discussing this at cross-purposes. In a language like C >> > or another statically typed language there is no information passed >> > with values indicating their type. >> >> You seem to be confusing "does not have a type" with "no type >> information is passed at runtime". >> >> > Have a look in a C compiler if you don't believe me. >> >> Believe me, I have. > > In a C compiler the compiler has no idea what the values are in the > program. It is no different from any other compiler, really. If the compiler sees the literal 1 in a context that demands type int, then it knows perfectly well what value that is. > It knows only their type in that it knows the type of the variable they > are contained within. > Would you agree with that? > >> > No it doesn't. Casting reinterprets a value of one type as a value of >> > another type. >> > There is a difference. If I cast an unsigned integer 20 to a >> > signed integer in C on the machine I'm using then the result I will get >> > will not make any sense. >> >> Which result are you getting? What does it mean to "make sense"? > > Well the right one actually, bad example. > > But, if I cast an unsigned int 25 to signed I get -1794967296. So, why do you think this "does not make sense"? And, as this example illustrates, casting in C maps values to values. Depending on the types of the source and the target, a cast might change the underlying representation, or it might leave it the same. But it does produce a value, and the result value is usually not the same as the argument value, even if the representation is the same. Matthias -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Joachim Durchholz <[EMAIL PROTECTED]> writes:
> Matthias Blume schrieb:
>> Joachim Durchholz <[EMAIL PROTECTED]> writes:
>>
>>> Matthias Blume schrieb:
>>>> Perhaps better: A language is statically typed if its definition
>>>> includes (or ever better: is based on) a static type system, i.e., a
>>>> static semantics with typing judgments derivable by typing rules.
>>>> Usually typing judgmets associate program phrases ("expressions") with
>>>> types given a typing environment.
>>> This is defining a single term ("statically typed") using three
>>> undefined terms ("typing judgements", "typing rules", "typing
>>> environment").
>> This was not meant to be a rigorous definition.
>
> Rigorous or not, introducing additional undefined terms doesn't help
> with explaining a term.
I think you missed my point. My point was that a language is
statically typed IF IT IS DEFINED THAT WAY, i.e., if it has a static
type system that is PART OF THE LANGUAGE DEFINITION. The details are
up to each individual definition.
>> Also, I'm not going to repeat the textbook definitions for those
>> three standard terms here.
>
> These terms certainly aren't standard for Perl, Python, Java, or Lisp,
Indeed. That's because these languages are not statically typed.
--
http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
"Rob Thorpe" <[EMAIL PROTECTED]> writes: >> >> > No it doesn't. Casting reinterprets a value of one type as a value of >> >> > another type. >> >> > There is a difference. If I cast an unsigned integer 20 to a >> >> > signed integer in C on the machine I'm using then the result I will get >> >> > will not make any sense. >> >> >> >> Which result are you getting? What does it mean to "make sense"? >> > >> > Well the right one actually, bad example. >> > >> > But, if I cast an unsigned int 25 to signed I get -1794967296. >> >> So, why do you think this "does not make sense"? > > Well, it makes sense in terms of the C spec certainly. > It does not make sense in that it does not emit an error. Why not? -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
"Marshall" <[EMAIL PROTECTED]> writes: > Torben Ægidius Mogensen wrote: >> >> That's not true. ML has variables in the mathematical sense of >> variables -- symbols that can be associated with different values at >> different times. What it doesn't have is mutable variables (though it >> can get the effect of those by having variables be immutable >> references to mutable memory locations). > > While we're on the topic of terminology, here's a pet peeve of > mine: "immutable variable." > > immutable = can't change > vary-able = can change > > Clearly a contradiction in terms. No, it is not a contradiction. See the mathematical usage of the word "variable". Immutable variables can stand for different values at different times, even without mutation involved, usually because they are bound by some construct such as lambda. > If you have a named value that cannot be updated, it makes > no sense to call it "variable" since it isn't *able* to *vary.* Mutation is not the only way for an expression to evaluate to different values over time. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Darren New <[EMAIL PROTECTED]> writes: > [ ... ] As far as I know, LOTOS is the only > language that *actually* uses abstract data types - you have to use > the equivalent of #include to bring in the integers, for > example. Everything else uses informal rules to say how types work. There are *tons* of languages that "actually" facilitate abstract data types, and some of these languages are actually used by real people. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Pascal Bourguignon <[EMAIL PROTECTED]> writes: > Moreover, a good proportion of the program and a good number of > algorithms don't even need to know the type of the objects they > manipulate. > > For example, sort doesn't need to know what type the objects it sorts > are. It only needs to be given a function that is able to compare the > objects. Of course, some statically typed languages handle this sort of thing routinely. > Only a few "primitive" functions need specific types. Your sort function from above also has a specific type -- a type which represents the fact that the objects to be sorted must be acceptable input to the comparison function. > So basically, you've got a big black box of applicaition code in the > middle that doesn't care what type of value they get, and you've got a > few input values of a specific type, a few processing functions > needing a specific type and returning a specific type, and a few > output values that are expected to be of a specific type. At anytime, > you may change the type of the input values, and ensure that the > needed processing functions will be able to handle this new input > type, and the output gets mapped to the expected type. ...or you type-check your "black box" and make sure that no matter how you will ever change the type of the inputs (in accordance with the interface type of the box) you get a valid program. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is a type error?
Pascal Costanza <[EMAIL PROTECTED]> writes: > Chris Smith wrote: > >> While this effort to salvage the term "type error" in dynamic >> languages is interesting, I fear it will fail. Either we'll all >> have to admit that "type" in the dynamic sense is a psychological >> concept with no precise technical definition (as was at least hinted >> by Anton's post earlier, whether intentionally or not) or someone is >> going to have to propose a technical meaning that makes sense, >> independently of what is meant by "type" in a static system. > > What about this: You get a type error when the program attempts to > invoke an operation on values that are not appropriate for this > operation. > > Examples: adding numbers to strings; determining the string-length of > a number; applying a function on the wrong number of parameters; > applying a non-function; accessing an array with out-of-bound indexes; > etc. Yes, the phrase "runtime type error" is actually a misnomer. What one usually means by that is a situation where the operational semantics is "stuck", i.e., where the program, while not yet arrived at what's considered a "result", cannot make any progress because the current configuration does not match any of the rules of the dynamic semantics. The reason why we call this a "type error" is that such situations are precisely the ones we want to statically rule out using sound static type systems. So it is a "type error" in the sense that the static semantics was not strong enough to rule it out. > Sending a message to an object that does not understand that message > is a type error. The "message not understood" machinery can be seen > either as a way to escape from this type error in case it occurs and > allow the program to still do something useful, or to actually remove > (some) potential type errors. I disagree with this. If the program keeps running in a defined way, then it is not what I would call a type error. It definitely is not an error in the sense I described above. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Pascal Bourguignon <[EMAIL PROTECTED]> writes: > Matthias Blume <[EMAIL PROTECTED]> writes: > >> Pascal Bourguignon <[EMAIL PROTECTED]> writes: >> >>> Moreover, a good proportion of the program and a good number of >>> algorithms don't even need to know the type of the objects they >>> manipulate. >>> >>> For example, sort doesn't need to know what type the objects it sorts >>> are. It only needs to be given a function that is able to compare the >>> objects. >> >> Of course, some statically typed languages handle this sort of thing >> routinely. >> >>> Only a few "primitive" functions need specific types. >> >> Your sort function from above also has a specific type -- a type which >> represents the fact that the objects to be sorted must be acceptable >> input to the comparison function. > > Well, not exactly. What do you mean by "not exactly". > sort is a higher level function. The type of its > arguments is an implicit parameter of the sort function. What do you mean by "higher-level"? Maybe you meant "higher-order" or "polymorphic"? [ rest snipped ] You might want to look up "System F". >>> So basically, you've got a big black box of applicaition code in the >>> middle that doesn't care what type of value they get, and you've got a >>> few input values of a specific type, a few processing functions >>> needing a specific type and returning a specific type, and a few >>> output values that are expected to be of a specific type. At anytime, >>> you may change the type of the input values, and ensure that the >>> needed processing functions will be able to handle this new input >>> type, and the output gets mapped to the expected type. >> >> ...or you type-check your "black box" and make sure that no matter how >> you will ever change the type of the inputs (in accordance with the >> interface type of the box) you get a valid program. > > When? When what? -- http://mail.python.org/mailman/listinfo/python-list
Re: Saying "latently-typed language" is making a category mistake
Pascal Costanza <[EMAIL PROTECTED]> writes: > Patricia Shanahan wrote: >> Vesa Karvonen wrote: >> ... >>> An example of a form of informal reasoning that (practically) every >>> programmer does daily is termination analysis. There are type systems >>> that guarantee termination, but I think that is fair to say that it >>> is not >>> yet understood how to make a practical general purpose language, whose >>> type system would guarantee termination (or at least I'm not aware >>> of such >>> a language). It should also be clear that termination analysis need not >>> be done informally. Given a program, it may be possible to >>> formally prove >>> that it terminates. >> To make the halting problem decidable one would have to do one of >> two >> things: Depend on memory size limits, or have a language that really is >> less expressive, at a very deep level, than any of the languages >> mentioned in the newsgroups header for this message. > > Not quite. See http://en.wikipedia.org/wiki/ACL2 What do you mean "not quite"? Of course, Patricia is absolutely right. Termination-guaranteeing languages are fundamentally less expressive than Turing-complete languages. ACL2 was not mentioned in the newsgroup header. -- http://mail.python.org/mailman/listinfo/python-list
Re: Saying "latently-typed language" is making a category mistake
Pascal Costanza <[EMAIL PROTECTED]> writes: > Matthias Blume wrote: >> Pascal Costanza <[EMAIL PROTECTED]> writes: >> >>> Patricia Shanahan wrote: >>>> Vesa Karvonen wrote: >>>> ... >>>>> An example of a form of informal reasoning that (practically) every >>>>> programmer does daily is termination analysis. There are type systems >>>>> that guarantee termination, but I think that is fair to say that it >>>>> is not >>>>> yet understood how to make a practical general purpose language, whose >>>>> type system would guarantee termination (or at least I'm not aware >>>>> of such >>>>> a language). It should also be clear that termination analysis need not >>>>> be done informally. Given a program, it may be possible to >>>>> formally prove >>>>> that it terminates. >>>> To make the halting problem decidable one would have to do one of >>>> two >>>> things: Depend on memory size limits, or have a language that really is >>>> less expressive, at a very deep level, than any of the languages >>>> mentioned in the newsgroups header for this message. >>> Not quite. See http://en.wikipedia.org/wiki/ACL2 >> What do you mean "not quite"? Of course, Patricia is absolutely >> right. Termination-guaranteeing languages are fundamentally less >> expressive than Turing-complete languages. ACL2 was not mentioned in >> the newsgroup header. > > ACL2 is a subset of Common Lisp, and programs written in ACL2 are > executable in Common Lisp. comp.lang.lisp is not only about Common > Lisp, but even if it were, ACL2 would fit. So what? Patricia said "less expressive", you said "subset". Where is the contradiction? Perhaps you could also bring up the subset of Common Lisp where the only legal program has the form: nil Obviously, this is a subset of Common Lisp and, therefore, fits comp.lang.lisp. Right? Yes, if you restrict the language to make it less expressive, you can guarantee termination. Some restrictions that fit the bill already exist. IMHO, it is still wrong to say that "Lisp guaratees termination", just because there is a subset of Lisp that does. Matthias PS: I'm not sure if this language guarantees termination, though. :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: Saying "latently-typed language" is making a category mistake
David Hopwood <[EMAIL PROTECTED]> writes: > Patricia Shanahan wrote: >> Vesa Karvonen wrote: >> ... >> >>> An example of a form of informal reasoning that (practically) every >>> programmer does daily is termination analysis. There are type systems >>> that guarantee termination, but I think that is fair to say that it is >>> not yet understood how to make a practical general purpose language, whose >>> type system would guarantee termination (or at least I'm not aware of >>> such a language). It should also be clear that termination analysis need >>> not be done informally. Given a program, it may be possible to formally >>> prove that it terminates. >> >> To make the halting problem decidable one would have to do one of two >> things: Depend on memory size limits, or have a language that really is >> less expressive, at a very deep level, than any of the languages >> mentioned in the newsgroups header for this message. > > I don't think Vesa was talking about trying to solve the halting problem. > > A type system that required termination would indeed significantly restrict > language expressiveness -- mainly because many interactive processes are > *intended* not to terminate. Most interactive processes are written in such a way that they (effectively) consist of an infinitely repeated application of some function f that maps the current state and the input to the new state and the output. f : state * input -> state * output This function f itself has to terminate, i.e., if t has to be guaranteed that after any given input, there will eventually be an output. In most interactive systems the requirements are in fact much stricter: the output should come "soon" after the input has been received. I am pretty confident that the f for most (if not all) existing interactive systems could be coded in a language that enforces termination. Only the loop that repeatedly applies f would have to be coded in a less restrictive language. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] writes:
>
> | think that it is too relevant for the discussion at hand. Moreover,
> | Harper talks about a relative concept of "C-safety".
>
> Then, I believe you missed the entire point.
>
>First point: "safety" is a *per-language* property. Each language
>comes with its own notion of safety. ML is ML-safe; C is C-safe;
>etc. I'm not being facetious; I think this is the core of the
>confusion.
>
>Safety is an internal consistency check on the formal definition of
>a language. In a sense it is not interesting that a language is
>safe, precisely because if it weren't, we'd change the language to
>make sure it is! I regard safety as a tool for the language
>designer, rather than a criterion with which we can compare
>languages.
I agree with Bob Harper about safety being language-specific and all
that. But, with all due respect, I think his characterization of C is
not accurate. In particular, the semantics of C (as specified by the
standard) is *not* just a mapping from memories to memories. Instead,
there are lots of situations that are quite clearly marked in C's
definition as "undefined" (or whatever the technical term may be). In
other words, C's specified transition system (to the extend that we
can actually call it "specified") has lots of places where programs
can "get stuck", i.e., where there is no transition to take. Most
actual implementations of C (including "Unix") are actually quite
generous by filling in some of the transitions, so that programs that
are officially "legal C" will run anyway.
Example:
The following program (IIRC) is not legal C, even though I expect it
to run without problem on almost any machine/OS, printing 0 to stdout:
#include
int a[] = { 0, 1, 2 };
int main (void)
{
int *p, *q;
p = a;
q = p-1; /** illegal **/
printf("%d\n", q[1]);
return 0;
}
Nevertheless, the line marked with the comment is illegal because it
creates a pointer that is not pointing into a memory object. Still, a
C compiler is not required to reject this program. It is allowed,
though, to make the program behave in unexpected ways. In particular,
you can't really blame the compiler if the program does not print 0,
or if it even crashes.
AFAIC, C is C-unsafe by Bob's reasoning.
---
Of course, C can be made safe quite easily:
Define a state "undefined" that is considered "safe" and add a
transition to "undefined" wherever necessary.
Kind regards,
Matthias
--
http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language [off-topic]
David Hopwood <[EMAIL PROTECTED]> writes: > Matthias Blume wrote: >> I agree with Bob Harper about safety being language-specific and all >> that. But, with all due respect, I think his characterization of C is >> not accurate. > [...] >> AFAIC, C is C-unsafe by Bob's reasoning. > > Agreed. > >> Of course, C can be made safe quite easily: >> >> Define a state "undefined" that is considered "safe" and add a >> transition to "undefined" wherever necessary. > > I wouldn't say that was "quite easy" at all. > > C99 4 #2: > # If a "shall" or "shall not" requirement that appears outside of a constraint > # is violated, the behavior is undefined. Undefined behavior is otherwise > # indicated in this International Standard by the words "undefined behavior" > # *or by the omission of any explicit definition of behavior*. [...] > > In other words, to fix C to be a safe language (compatible with Standard C89 > or C99), you first have to resolve all the ambiguities in the standard where > the behaviour is *implicitly* undefined. There are a lot of them. Yes, if you want to make the transition system completely explict, it won't be easy. I was thinking of a catch-all rule that says: transition to "undefined" unless specified otherwise. (Note that I am not actually advocating this approach to making a language "safe". For practical purposes, C is unsafe. (And so is C++.)) -- http://mail.python.org/mailman/listinfo/python-list
Re: languages with full unicode support
Tin Gherdanarra <[EMAIL PROTECTED]> writes: > Oliver Bandel wrote: >> こんいちわ Xah-Lee san ;-) > > Uhm, I'd guess that Xah is Chinese. Be careful > with such things in real life; Koreans might > beat you up for this. Stay alive! And the Japanese might beat him up, too. For butchering their language. :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Pascal Costanza <[EMAIL PROTECTED]> writes: > Whether you consider something you cannot do with statically typed > languages a bad idea or not is irrelevant. You were asking for things > that you cannot do with statically typed languages. The whole point of static type systems is to make sure that there are things that one cannot do. So the fact that there are such things are not an argument per se against static types. [ ... ] > Beyond that, I am convinced that the ability to update a running > system without the need to shut it down can be an important asset. And I am convinced that updating a running system in the style of, e.g., Erlang, can be statically typed. >> Note that prohibiting directly self-modifying code does not prevent a >> program from specifying another program to *replace* it. > > ...and this creates problems with moving data from one version of a > program to the next. How does this "create" such a problem? The problem is there in either approach. In fact, I believe that the best chance we have of addressing the problem is by adopting the "replace the code" model along with a "translate the data where necessary at the time of replacement". Translating the data, i.e., re-establishing the invariants expected by the updated/replaced code, seems much harder (to me) in the case of self-modifying code. Erlang got this one right. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Pascal Costanza <[EMAIL PROTECTED]> writes: >> And I am convinced that updating a running system in the style of, >> e.g., Erlang, can be statically typed. > > Maybe. The interesting question then is whether you can express the > kinds of dynamic updates that are relevant in practice. Because a > static type system always restricts what kinds of runtime behavior you > can express in your language. I am still skeptical, because changing > the types at runtime is basically changing the assumptions that the > static type checker has used to check the program's types in the first > place. That's why I find the Erlang model to be more promising. I am extremely skeptical of code mutation at runtime which would "change types", because to me types are approximations of program invariants. So if you do a modification that changes the types, it is rather likely that you did something that also changed the invariants, and existing code relying on those invariants will now break. > For example, all the approaches that I have seen in statically typed > languages deal with adding to a running program (say, class fields and > methods, etc.), but not with changing to, or removing from it. Of course, there are good reasons for that: removing fields or changing their invariants requires that all /deployed/ code which relied on their existence or their invariants must be made aware of this change. This is a semantic problem which happens to reveal itself as a typing problem. By making types dynamic, the problem does not go away but is merely swept under the rug. Note that prohibiting directly self-modifying code does not prevent a program from specifying another program to *replace* it. >>> ...and this creates problems with moving data from one version of a >>> program to the next. >> How does this "create" such a problem? The problem is there in >> either >> approach. In fact, I believe that the best chance we have of >> addressing the problem is by adopting the "replace the code" model >> along with a "translate the data where necessary at the time of >> replacement". Translating the data, i.e., re-establishing the >> invariants expected by the updated/replaced code, seems much harder >> (to me) in the case of self-modifying code. Erlang got this one >> right. > > ...and the "translate the date where necessary" approach is > essentially triggered by a dynamic type test (if value x is of an old > version of type T, update it to reflect the new version of type T > [1]). QED. But this test would have to already exist in code that was deployed /before/ the change! How did this code know what to test for, and how did it know how to translate the data? Plus, how do you detect that some piece of data is "of an old version of type T"? If v has type T and T "changes" (whatever that might mean), how can you tell that v's type is "the old T" rather than "the new T"! Are there two different Ts around now? If so, how can you say that T has changed? The bottom line is that even the concept of "changing types at runtime" makes little sense. Until someone shows me a /careful/ formalization that actually works, I just can't take it very seriously. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
"Marshall" <[EMAIL PROTECTED]> writes: > Matthias Blume wrote: >> >> How does this "create" such a problem? The problem is there in either >> approach. In fact, I believe that the best chance we have of >> addressing the problem is by adopting the "replace the code" model >> along with a "translate the data where necessary at the time of >> replacement". Translating the data, i.e., re-establishing the >> invariants expected by the updated/replaced code, seems much harder >> (to me) in the case of self-modifying code. Erlang got this one >> right. > > Pardon my ignorance, but what is the Erlang solution to this problem? Erlang relies on a combination of purity, concurrency, and message passing, where messages can carry higher-order values. Data structures are immutable, and each computational agent is a thread. Most threads consist a loop that explicitly passes state around. It dispatches on some input event, applies a state transformer (which is a pure function), produces some output event (if necessary), and goes back to the beginning of the loop (by tail-calling itself) with the new state. When a code update is necessary, a special event is sent to the thread, passing along the new code to be executed. The old code, upon receiving such an event, ceases to go back to its own loop entry point (by simply not performing the self-tail-call). Instead it tail-calls the new code with the current state. If the new code can live with the same data structures that the old code had, then it can directly proceed to perform real work. If new invariants are to be established, it can first run a translation function on the current state before resuming operation. >From what I hear from the Erlang folks that I have talked to, this approach works extremely well in practice. -- http://mail.python.org/mailman/listinfo/python-list
Re: languages with full unicode support
Oliver Bandel <[EMAIL PROTECTED]> writes: >>>Oliver Bandel wrote: >>> >>>>こんいちわ Xah-Lee san ;-) >>> >>>Uhm, I'd guess that Xah is Chinese. Be careful >>>with such things in real life; Koreans might >>>beat you up for this. Stay alive! >> And the Japanese might beat him up, too. For butchering their >> language. :-) > > OK, back to ISO-8859-1 :) no one needs so much symbols, > this is enough: äöüÄÖÜß :) There are plenty of people who need such symbols (more people than those who need ß, btw). Matthias PS: It should have been こんにちは. -- http://mail.python.org/mailman/listinfo/python-list
Change coords of a canvas.line item
Hi all, I want to change the beginning/end-coordinates of a canvas.line item. Something like: self.myCanvas.itemconfigure(item_id, coords=(x1_new, y1_new, x2_new, y2_new)) I don't want to delete and repaint a new line item. Is this possible? Thanks Matthias -- http://mail.python.org/mailman/listinfo/python-list
Re: Change coords of a canvas.line item
Very nice :) Thank you, Matthias -- http://mail.python.org/mailman/listinfo/python-list
Cross-module imports?
Hi, I am getting strange errors when I am importing modules cross-wise, like this: # module A import B var1 = "x" B.var2 = "y" # module B import A var2 = "z" print A.var1 The error messages are not even sane, for example the interpreter complains about not finding 'var1' in module A. Is there a solution to this problem which doesn't involve introducing a new module holding the shared objects? Thanks, Matthias -- http://mail.python.org/mailman/listinfo/python-list
Re: Cross-module imports?
Ant wrote: > If you have to trick the compiler like this though, I'd take a good > look at *why* you want to couple the modules so tightly in the first > place! Yeah, you're right. I think loosening up the coupling by introducing a module which holds common shared data is probably a good idea anyway. Thanks for clearing up, Matthias -- http://mail.python.org/mailman/listinfo/python-list
Re: wxPython or wxWidgets
Marc 'BlackJack' Rintsch wrote: > wxPython are the Python bindings to wxWidgets which is a C++ library. Don't want to hijack the thread, but since it's answered already: Has wxWidgets finally arrived at migrating to GTK2? ^^ If so, I might consider using wxPython instead of pygtk for that small application I am currently writing. This would help portability a lot (since IIRC, wxWidgets has been designed to work on Windows, too). The last time I checked, wxWidgets was GTK1, although GTK2 has had been long around already. Because of this, and the nasty feeling that I was programming MFC when working with the wxWidgets somewhat drove me away from it with a big "Yuck!", but if it's based on GTK2 now I might risk another glimpse. Thanks, Matthias -- http://mail.python.org/mailman/listinfo/python-list
Re: Write a GUI for a python script?
Glurt Wuntal (02.03.2006 15:56): > I am a newbie with Python. It's a great language, but I would like to be > able to present a simple gui menu for some of my scripts; something better > than using 'raw_input' prompts. > If you only need some dialogs, input and/or message boxes, you could start with EasyGUI. http://www.ferg.org/easygui/ Matthias -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
Andreas Rottmann wrote: > You get terminology totally wrong here. As already said, Lisp is > stronger typed than C, but C is statically typed, whereas Lisp is > dynamically typed. In Lisp (or Scheme), all variables have types: > > (define foo #(1 2 3)) > (vector? foo) => #t > (boolean? foo) => #t Hmm.. weird Scheme you're using here. Normally you have to quote the vector (see R5RS, 6.2.6) because it is not self-evaluating, and boolean? should not return true on vectors (6.3.1). I get (on scheme48): (define foo '#(1 2 3)) (vector? foo) => #t (boolean? foo) => #f mkb. -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
Anno Siegel wrote: > I've been through Pascal, Modula2 and Oberon, and I agree. > In the short run they succeeded. For a number of years, languages of > that family were widely used, primarily in educational programming > but also in implementing large real-life systems. With a few relaxations and extensions, you can get a surprisingly useful language out of the rigid Pascal, as evidenced by Turbo Pascal, one of the most popular (and practical) programming languages in the late 80ies / start of the 90ies. mkb. -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
Andrea Griffini wrote: >>With a few relaxations and extensions, you can get a surprisingly useful >>language out of the rigid Pascal, as evidenced by Turbo Pascal, one of >>the most popular (and practical) programming languages in the late 80ies >>/ start of the 90ies. > > It was not a language. It was a product in the hand of a single > company. The difference is that a product can die at the snaps > of a marketroid, no matter how nice or how diffuse it is. Of course it is a language, just not a standardized one (if you include Borland's extensions that make it practical). But does that matter? With the exception of Scheme, none of the languages that are the object of discussion of the newsgroups this thread is being posted to, are standardized. Yet they are all quite popular. And btw., I haven't used Pascal in a dozen years but my latest info is that Turbo Pascal still lives in the form of "Delphi" for the Windows platform. Surely not "dead" as I understand it. mkb. -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
Xah Lee wrote: > to be continued tomorrow. Please don't... mkb. -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
Andrea Griffini wrote: >>Of course it is a language, just not a standardized one (if you include >>Borland's extensions that make it practical). > > The history of "runtime error 200" and its handling from > borland is a clear example of what I mean with a product. Hmm, I had to google this up... Quite embarrassing, but it's a runtime bug and got nothing to do with the language per se. And it certainly manifests itself after the hey-days of Turbo Pascal (when Borland seems to have lost interest in maintaining it.) mkb. -- http://mail.python.org/mailman/listinfo/python-list
smtplib and TLS
Hi!
After getting a @gmail.com address, I recognized I had to use TLS in my
python scripts using smtplib in order to get mail to the smtp.gmail.com
server.
Things work well so far, apart from an unexpected error. Here's my
sample code:
import smtplib
server = smtplib.SMTP('smtp.gmail.com', 587)
server.ehlo()
server.starttls()
server.ehlo()
server.login('[EMAIL PROTECTED]', password)
server.sendmail("[EMAIL PROTECTED]", toaddress, message)
server.quit()
The server accepts and delivers my messages, but the last command
raises
socket.sslerror: (8, 'EOF occurred in violation of protocol')
Did I miss something? Any hint is welcome.
Regards,
Matthias
--
http://mail.python.org/mailman/listinfo/python-list
Re: pysqlite - Checking the existance of a table
Simply use the internal table SQLite_Master: select name from SQLite_Master will return all existing tables. Regards, Matthias -- http://mail.python.org/mailman/listinfo/python-list
Re: smtplib and TLS
> "Matthias Kluwe" <[EMAIL PROTECTED]> writes:
>> The server accepts and delivers my messages, but the last command
>> raises
>> socket.sslerror: (8, 'EOF occurred in violation of protocol')
>> Did I miss something? Any hint is welcome.
> Looks like the module didn't send an TLS Close Notify message before
> closing the socket. I don't see anything in the docs about how to
> send one from smtplib or socket, though.
Hmm. I tried
server.sock.realsock.shutdown(2)
before server.quit() with the result of
SMTPServerDisconnected('Server not connected')
being raised. Quite an improvement ...
Matthias
--
http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs
David Kastrup wrote: > My favorite killing offence is /* vi:set ts=4: */. This is apparently the default setting in many of the so-called "IDE"s today.. I think it's another unwelcome poison gift from the ignorant M$FT world (I suspect some primitive Windoze IDE which couldn't differentiate between TAB and indent probably offered the programmer changing the tabwidth as the only method for changing indentation, and then this method got stuck...) F'up to comp.emacs. -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
Twisted wrote: > That's a joke, right? I tried it a time or two. Every time it was > rapidly apparent that doing anything non-trivial would require > consulting a cheat sheet. The printed-out kind, since navigating to > the help and back without already having the help displayed and open > to the command reference was also non-trivial. Ah, yes.. we live in a time where no-one seems to have the patience to read documentation anymore. Maybe that's why there is such a scarcity of good documentation with many "modern" software packages. Here's a nice one from Ken Thompson: ``I abhor a system designed for the "user", if that word is a coded pejorative meaning "stupid and unsophisticated".'' -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
Twisted wrote: > Emacs does have documentation. The problem is you have to already know > a load of emacs navigation oddities^Wkeyboard commands to get to and > use it. Yes, like hitting the F1 key. > Yeah, and I abhor the elitist systems that are designed with the > philosophy that anyone who hasn't mastered years of arcane > memorization and training in just that one idiosyncratic system is / > ipso facto/ "stupid and unsophisticated". Most of us 6 and a half > billion people have better uses for our time, such as buckling in and > being promptly productive, once we're out of high school or college, > and fully three and a quarter of us are at least as smart as average, > and so /ipso facto/ *not* "stupid and unsophisticated". Noone forces you to use either Unix or emacs (or vi, for that matter). I don't really understand what your problem is. -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
Kaldrenon wrote: > I don't think anyone can make the argument that any (past or current) > graphics-based editor is as efficient when being used to its fullest > as a text-based editor. Actually, I think the argument can be made: ``We’ve done a cool $50 million of R & D on the Apple Human Interface. We discovered, among other things, two pertinent facts: * Test subjects consistently report that keyboarding is faster than mousing. * The stopwatch consistently proves mousing is faster than keyboarding.'' (from http://plan9.bell-labs.com/wiki/plan9/Mouse_vs._keyboard/index.html ) However, at least for me, heavy mousing is stressful to the wrist, so I prefer to keep my hands on the keyboard (even though I use a trackball, which greatly reduces the strain for me). I also think that while intuitive cursor positioning and text selection operations may be faster with a mouse, complex operations (like on the shell or complex editor commands) are impractical through a pure point+click interface. -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs
Twisted wrote: > I find these anecdotes liberally sprinkled into this thread frankly > unbelievable. If you'd spent as much time learning the software as you're ranting about it, you could actually use it _and_ would get the additional benefit of having avoided making a fool of yourself on Usenet. Of course that would have been too easy, wouldn't it? -- http://mail.python.org/mailman/listinfo/python-list
