Re: ANN: Dao Language v.0.9.6-beta is release!
D H wrote: > > How is that a problem that some editors use 8 columns for tabs and > others use less? So what? > A bigger problem I see is people using only 2 or 3 spaces for indenting. > That makes large amounts of code much less readable. And of course it > is a problem if you mix tabs and spaces at the beginning of the same line. > Tabs are easier to type (one keystroke each) and lead to visually better > results (greater indentation unless you like hitting 8 spaces for each > indent level). Where does that misconception that 2-3 spaces for indenting makes things less readable come from? There was an article in Comm. of the ACM on research into readability back in 1984 or so, that indicated 2-4 spaces has very similar readability and 8 spaces significantly less than that. IIRC they took care of personal preferences/what one was used to in the research. So disallowing tabs which could be set to 8 spaces (positions?) does make sense to me. I switched from using 2 to using 4 spaces for Python recently, and the big pain was to deal with lines that no longer fitted in 80 columns :-( -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 2.5 Core Dump on Solaris 8
Hi Melissa, I run into similar problems after compiling python-ldap 2.2.0 for Python 2.5 on SuSE Linux 9.3 and running a small commandline application *** glibc detected *** double free or corruption (out): 0x40180788 *** I realy suspect the _ldap.so file. I have not found a solution yet, but will let you know if I do. Did you compile python-ldap yourself for Python 2.5? Which version of python-ldap? Which compiler? Regards Anthon Melissa Evans wrote: > Hi. I'm new to Python. :) > > I've modified grappy.py, > http://www.stacken.kth.se/~mattiasa/projects/grappy/, a postfix policy > daemon for greylisting. to use LDAP as a backend instead of SQL (with > python-ldap.) The daemon runs fine when testing but when I put it under > load it core dumps quickly. What little analysis I know how to do shows > similar information every time. Any advice on where to go from here? > > Thanks! > Melissa > -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 2.5 Core Dump on Solaris 8
You can set an environment variable MALLOC_CHECK_ to influence the behaviour of glibc 0 -> no error message program continues 1 -> error message, program continues 2 -> no error message, kills program 3 -> error message, kills program Since the message only occured with my two programs at exit time, I set the environment var to 0 HTH Anthon -- http://mail.python.org/mailman/listinfo/python-list
incompatible exit values between python 2.4 and 2.5
I have a small C program that restarts a python based server
application if the exit value of the
system("python -m pythonscript arg1 arg2 ...")
is greater than 127 (using WEXITSTATUS on the result of system(..))
If the server really needs to stop I exit with
sys.exit(0)
but if I just want it to restart (to reread all modules) I can do
sys.exit(128)
With python 2.4, if pythonscript.py could not be found, the exit value
would be 2 and if there was some syntax error, or other exception
raised, the exit value would be 1.
While trying this out with Python 2.5 I found that the exit value on
error is always 255, so I have to change my script (not a big deal).
However two questions came up while finding out what was
the difference:
1) is this change of behaviour documented somewhere and did I miss
that, or has this not been documented (yet)
2) Is there a build-in way to set the exit value for Python in case an
exception is raised that is uncaught and causes python to terminate? (I
have now implemented something using
try:
...
except ImportError, comment:
sys.exit(2)
except:
sys.exit(1)
but I still have to figure out how to print the stacktrace before
exiting with specific values.)
Regards
Anthon
--
http://mail.python.org/mailman/listinfo/python-list
Python SVN down?
I am trying to get at the python source code, but it seems svn.python.org is down, at least on port 80 (http) and 3690 (svn). This happened earlier this week and then it came back (at least yesterday). Are all the real ( ;-) ) developers using ssh+svn and not noticing this? Anthon -- http://mail.python.org/mailman/listinfo/python-list
keyword parameter order
I am looking for a way to determine the order of keyword parameters passed on to a class method. In the source code the keyword parameters are ordered, an ordering that is lost by putting them into a dictionary and then accessing them by using **kw. If I had this order (either of the keyword+value pairs or just of the keywords) I could meaningfully initialise my ordereddict implemenation (which uses Key Insertion Order or KeyValue Insertion Order). I looked at traceback (which shows this info if all the keywords are on one source line), and tracing that I found that it displays the sourcecode line based on the code-object found in the frame stack. I could persue that but I find the idea of reparsing the sourcecode kind of ugly (although doable, as the keyword are never variables, and I would not have to reevaluate the variables). I am not sure if this kind of info is available internally to the interpreter (ordereddict is in C, so I would even prefer that). Has anyone done this or anything like it? I could probably compile the python interpreter to use ordereddict instead of dict and then the parser would insert the keyword parameters in specification order in the **kw ordereddict, after which iteration over parameters would be ordered. I am pretty sure though if the 10% speed overhead of the ordereddict implementation compared to dict is going to prevent people from using such an interpreter version. As an aside: I think that allowing dict to be initialised from keyword parameters (introduced in Python 2.2 IIRC) was a mistake. This kind of use of keyword parameters prevents any real keyword parameters. E.g. with 'maxsize' that restricts the dictionary size or 'unique' that would throw an Exception if an existing key gets reassigned. Anthon -- http://mail.python.org/mailman/listinfo/python-list
Re: keyword parameter order
Martin, Thanks for pointing this out. I might have found that code eventualy but it would have taken me quite sometime. There was a request from a user to make ordereddict more of drop-in replacement for dict. That can be already be done by specifying the relax keyword parameter (or defining a subclass that does so), but it made me revisit the idea of investigating the keyword parameter order.. I will just drop this idea Thanks Anthon On Nov 18, 12:08 pm, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > I am not sure if this kind of info is available internally to the > > interpreter (ordereddict is in C, so I would even prefer that). Has > > anyone done this or anything like it? > > It's not available. See ceval.c:do_call; this fills the dictionary. > From then on, information about the order of keyword arguments is > lost. > > > I could probably compile the python interpreter to use ordereddict > > instead of dict and then the parser would insert the keyword > > parameters in specification order in the **kw ordereddict, after which > > iteration over parameters would be ordered. > > If you'ld do that literally, you'll find that the keyword arguments are > in reverse order. > > > As an aside: I think that allowing dict to be initialised from keyword > > parameters (introduced in Python 2.2 IIRC) was a mistake. This kind of > > use of keyword parameters prevents any real keyword parameters. E.g. > > with 'maxsize' that restricts the dictionary size or 'unique' that > > would throw an Exception if an existing key gets reassigned. > > For your own dictionary implementation, you are not required to follow > this interface - in particular if you believe it was a mistake. > > Regards, > Martin -- http://mail.python.org/mailman/listinfo/python-list
Re: keyword parameter order
Hi Tim,
Thanks for the comments, I obviously hadn't thought beyond the simple
case.
I am happy I wrote (and that you Martin answered) instead of trying to
program myself into a halffunctional implementation %-)
Regards
Anthon
On Nov 18, 1:40 pm, Tim Chase <[EMAIL PROTECTED]> wrote:
> > I am looking for a way to determine the order of keyword parameters
> > passed on to a class method.
>
> I'm fairly certain it's not possible, as how would code like this
> behave:
>
> def my_func(**kwd):
> kwd = OrderedDict(kwd) #magic happens here?
> return do_something(kwd)
>
> my_dict = {'hello':42, 'world':3.14159}
> print my_func(**my_dict)
>
> This is regularly used in lots of code. The ordering of the
> contents of my_dict is already lost before the my_func() ever
> gets a chance to see it. And in case one suggests trying to
> sniff the source-code for the ordering, it's easy to break with
> things like
>
> my_dict = read_dict_from_file(get_filename_from_user())
>
> where the dict and its source are completely outside the scope of
> the code.
>
> The only way around it I see is to force the user to pass in an
> ordered dict explicitly:
>
> def my_func(ordered_dict_of_kwdargs):
> return do_something(ordered_dict_of_kwdargs)
> my_dict = OrderedDict()
> my_dict['hello'] = 42
> my_dict['world'] = 3.14159
> print my_func(my_dict)
>
> -tkc
--
http://mail.python.org/mailman/listinfo/python-list
Re: tiffany 0.6.1 released
Christian, I should have several larger Tiff files, but I would have to search a bi. I used tilded tiffs ack in the early 90-s as a solution to mapping large images onto raytraced surfaces on machines with only 20Mb of memory. I will have to search though and I am now travelling. If I fail to come back to you after I return home (in a week time), drop me an email. Are you going to be at Europython again (we once shared a taxi in Birmingham). I will drive down there tomoorw. Regards Anthon On 2012-06-30 12:41, Christian Tismer wrote: Tiffany - Read/Write Multipage-Tiff with PIL without PIL Tiffany stands for any tiff. The tiny module solves a large set of problems, has no dependencies and just works wherever Python works. Tiffany was developed in the course of the *DiDoCa* project and will always appear on PyPi. Version 0.6.1 - This version uses the new int.from_bytes/to_bytes methods from python3.2 and emulates them on python2.6/2.7 . This migration was tested using pytest. Tiffany is quite unlikely to change anymore until user requests come, or I get better test data: Testing with larger tiff files -- The implementation right now copies data in one big chunk. I would like to make that better/not limited by memory. For that, I need a tiff file that is a few megabytes big. Can somebody please send me one? Extending Tiffany? -- I'm also thinking of - an interface to Qt (without adding a dependency) - a command line interface, to make tiffany into a new tiff tool, - support for other toolkits that need to handle tiff files. Ideas about this are most welcome. Please let me know if this stuff works for you, and send requests to or use the links in the bitbucket website: https://bitbucket.org/didoca/tiffany cheers -- Chris -- http://mail.python.org/mailman/listinfo/python-list
string_formatter 1.0.1 released
string_formatter is a backport of the 3.4.1+ string.Formatter class, to
2.7, 3.3 and 3.4.0. This allows the use of empty keys {} in its format
strings.
At the same time it solves an existing (at least until 3.5.0.rc3) bug in
string.Formatter, breaking with the use of nested empty keys.
Python 3.4.3:
>>> import string
>>> string.Formatter().format("|{:<{}} {}|", 'a', 3, 5)
'|a 3|'
In addition (that is how it all started) it provides TrailingFormatter
which allows a type specification "t" with a single character parameter.
That character will be added to the (stringified) value before applying
(left-aligned) formatting:
import string_formatter as string
fmt = string.TrailingFormatter()
d = dict(a=1, bc=2, xyz=18)
for key in sorted(d):
print(fmt.format("{:t{}<{}} {:>3}", key, ':', 15, d[key]))
giving:
a:1
bc: 2
xyz: 18
--
https://mail.python.org/mailman/listinfo/python-list
