http://groups.google.com/group/comp.lang.python?hl=en
comp.lang.python@googlegroups.com
Today's topics:
* The best library to create charting application - 3 messages, 3 authors
http://groups.google.com/group/comp.lang.python/t/7c14e5090a272c23?hl=en
* exec within function - 3 messages, 3 authors
http://groups.google.com/group/comp.lang.python/t/7a046e4ede9c310a?hl=en
* Dreaming of new generation IDE - 10 messages, 6 authors
http://groups.google.com/group/comp.lang.python/t/e019614ea149e7bd?hl=en
* simple and fast platform independent IPC - 1 messages, 1 author
http://groups.google.com/group/comp.lang.python/t/0fb9d731abbc5ab3?hl=en
* expy 0.5.2 released - 1 messages, 1 author
http://groups.google.com/group/comp.lang.python/t/ea3018487d9365ec?hl=en
* Wrap a function - 2 messages, 1 author
http://groups.google.com/group/comp.lang.python/t/fce27f8c4a22d12b?hl=en
* newbie qns : how do i use xmldiff? - 1 messages, 1 author
http://groups.google.com/group/comp.lang.python/t/3a02ad06382e366b?hl=en
* ANN: GMPY 1.11 released - 1 messages, 1 author
http://groups.google.com/group/comp.lang.python/t/6b7dae7a8c90517e?hl=en
* Logging oddity: handlers mandatory in every single logger? - 1 messages, 1
author
http://groups.google.com/group/comp.lang.python/t/c4da89f2c43b0bc8?hl=en
* How to guard against bugs like this one? - 1 messages, 1 author
http://groups.google.com/group/comp.lang.python/t/fe6430e7980e2a96?hl=en
* PEP 3147 - new .pyc format - 1 messages, 1 author
http://groups.google.com/group/comp.lang.python/t/7a0d8230a5907885?hl=en
* Python and Ruby - 1 messages, 1 author
http://groups.google.com/group/comp.lang.python/t/dfe4f6c60032755e?hl=en
==============================================================================
TOPIC: The best library to create charting application
http://groups.google.com/group/comp.lang.python/t/7c14e5090a272c23?hl=en
==============================================================================
== 1 of 3 ==
Date: Wed, Feb 3 2010 11:50 am
From: mk
Phlip wrote:
> mk wrote:
>>
>> The application will display (elaborate) financial charts.
>>
>> Pygame? Smth else?
>
> Back in the day it was Python BLT.
>
> Are you on the Web or the Desktop?
>
Desktop, really (there should be some nominal web interface but the main
application will be desktop)
Regards,
mk
== 2 of 3 ==
Date: Wed, Feb 3 2010 12:07 pm
From: Daniel Molina Wegener
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On Mié 03 Feb 2010 16:30,
mk wrote:
>
> The application will display (elaborate) financial charts.
>
> Pygame? Smth else?
I don't know if is the /best/ one, but I've used matplotlib
as multipurpose chart displaying library ;)
>
> <duck>dotnet?
>
>
> Regards,
> mk
Best regards,
- --
Daniel Molina Wegener <dmw [at] coder [dot] cl>
Software Architect, System Programmer & Web Developer
Phone: +1 (510) 629-4267 | Blog: http://coder.cl/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iQIcBAEBCgAGBQJLadeAAAoJEHxqfq6Y4O5Nr5cP/0eCN/Kbg1ujdRwmUTnFlzGL
NLu7RW/IlJyDDOPcHfWwlXjjJELCuC6H541dTE6l3S+3ZBIrEPhCjJ9+5bijP43Z
V4KFjgCchZZcA4K6xEJWugj08dE9uCxP64vyhB8H+Hcsln/TyHAMkSeW2eA1jx+c
UCqc9xAiNzNgbrIuJHtfFNBXQXMnMb4YHy2fas3SEKE0nP8/Cm6IowK+wUwZRVxA
LGGfB/V5Go4qkfJU1LomnM88y1OFzY2igo8GyJnvGQsMwyQ2SNgMc9pVpSRdZC8K
xKrZQE+W5d+ZPMWcJupRlMz7+qFXWEyDGRdXMO9aNvlZycwA/s+fZzGoIBj9CUgM
nPcfxOv0M9P/zN56ZRKMs0H0eyALQ+Uupq2FgMQgD9fPWy+sRTfesetmby7h+YB1
rDxUKgNIIve8lrdv6qN4uBLyhgCNpbeKLEcaTYyqEDLd59yvvFGmP0fS/gjHICtA
M+I9DU1XRw6xZJUVOf2NcoA9EXj1OET/g/Wt6qdQjgfS3eNVY3LXmZQySSAsbPDY
1+FHZaFSV3NJqC3Iuj3LfrMlCn8eiaSQjhpBsg4XNHYh3qMLK4nEdVh+R5jntJUi
hz5kXjs9Q/5/hukGaPOcl5unP3b4pGoc/a8tDV1ZHtnWRwFZSnNudmejB1g/K/ud
xLty6/xN7OgFm/4kAl3X
=61lU
-----END PGP SIGNATURE-----
== 3 of 3 ==
Date: Wed, Feb 3 2010 12:10 pm
From: John Bokma
mk <mrkafk@gmail.com> writes:
> The application will display (elaborate) financial charts.
>
> Pygame? Smth else?
You might want to check out the book "Beginning Python
Visualisation".
--
John Bokma j3b
Hacking & Hiking in Mexico - http://johnbokma.com/
http://castleamber.com/ - Perl & Python Development
==============================================================================
TOPIC: exec within function
http://groups.google.com/group/comp.lang.python/t/7a046e4ede9c310a?hl=en
==============================================================================
== 1 of 3 ==
Date: Wed, Feb 3 2010 11:59 am
From: Terry Reedy
On 2/3/2010 3:30 AM, Simon zack wrote:
> hi,
> I'm not sure how I can use exec within a function correctly
> here is the code i'm using:
>
> def a():
> exec('b=1')
> print(b)
>
> a()
>
> this will raise an error, but I would like to see it outputting 1
Always **copy and paste** **complete error tracebacks** when asking a
question like this. (The only exception would be if it is v e r y long,
as with hitting the recursion depth limit of 1000.)
== 2 of 3 ==
Date: Wed, Feb 3 2010 12:29 pm
From: Gerald Britton
I get no error:
>>> def a():
... exec('b=1')
... print(b)
...
>>> a()
1
>>>
On Wed, Feb 3, 2010 at 2:59 PM, Terry Reedy <tjreedy@udel.edu> wrote:
> On 2/3/2010 3:30 AM, Simon zack wrote:
>>
>> hi,
>> I'm not sure how I can use exec within a function correctly
>> here is the code i'm using:
>>
>> def a():
>> exec('b=1')
>> print(b)
>>
>> a()
>>
>> this will raise an error, but I would like to see it outputting 1
>
> Always **copy and paste** **complete error tracebacks** when asking a
> question like this. (The only exception would be if it is v e r y long, as
> with hitting the recursion depth limit of 1000.)
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
--
Gerald Britton
== 3 of 3 ==
Date: Wed, Feb 3 2010 12:50 pm
From: Peter Otten <__peter__@web.de>
Gerald Britton wrote:
> On Wed, Feb 3, 2010 at 2:59 PM, Terry Reedy <tjreedy@udel.edu> wrote:
>> On 2/3/2010 3:30 AM, Simon zack wrote:
>>>
>>> hi,
>>> I'm not sure how I can use exec within a function correctly
>>> here is the code i'm using:
>>>
>>> def a():
>>> exec('b=1')
>>> print(b)
>>>
>>> a()
>>>
>>> this will raise an error, but I would like to see it outputting 1
>>
>> Always **copy and paste** **complete error tracebacks** when asking a
>> question like this. (The only exception would be if it is v e r y long,
>> as with hitting the recursion depth limit of 1000.)
> I get no error:
>
>>>> def a():
> ... exec('b=1')
> ... print(b)
> ...
>>>> a()
> 1
My crystal ball says you're using Python 2.x. Try it again, this time in
3.x:
Python 3.1.1+ (r311:74480, Nov 2 2009, 15:45:00)
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> def f():
... exec('a = 42')
... print(a)
...
>>> f()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 3, in f
NameError: global name 'a' is not defined
OP: Python 2.x generates different bytecode for functions containing an exec
statement. In 3.x this statement is gone and exec() has become a normal
function. I suppose you now have to pass a namespace explicitly:
>>> def f():
... ns = {}
... exec("a=1", ns)
... print(ns["a"])
...
>>> f()
1
Peter
==============================================================================
TOPIC: Dreaming of new generation IDE
http://groups.google.com/group/comp.lang.python/t/e019614ea149e7bd?hl=en
==============================================================================
== 1 of 10 ==
Date: Wed, Feb 3 2010 12:08 pm
From: John Bokma
Phlip <phlip2005@gmail.com> writes:
> On Feb 3, 10:57 am, Adam Tauno Williams <awill...@opengroupware.us>
> wrote:
>
>> > Current editors suck because they can't see into the code and browse
>> > it - unless it's so statically typed it's painful.
>>
>> ? I edit Python in MonoDevelop 2.2; and I can browse my file,
>> classes, etc... So I don't know what you mean by "can't see into the
>> code". It works pretty well.
>>
>> Of course it can't tell that I've set x = {an integer}, as that only
>> happens at runtime.
>>
>> > That's why I wrote this:
>> > http://www.oreillynet.com/onlamp/blog/2008/05/dynamic_languages_vs_editors.html
>
> You just said that your code browsing "works pretty well, except when
> it doesn't".
>
> Hence my blog entry. If your editor analyzed your code at runtime,
> instead of just static analysis, then it could see that x = an
> integer, or an object, no matter how dynamic your language.
In Perl:
my $x = ( 5, "hello", sub {}, [], {} )[ int rand 5 ];
what's $x? The answer is: it depends.
Moreover, even if your editor analyzes your code at runtime (which is
certainly not always desirable) it might not be able to find out what
the type is of x, simply because it would take too much time to find it
out. (It sounds like you want an editor that solves the halting problem
;-) )
I agree with you that to /some extent/ and editor can do analyses, if it
does compilation as well (and even runs the code, but the latter is not
always desirable). I mentioned the Synthesizer Generator before, which
can do compilation on the fly, if you implement it (or if it has been
implemented for the language you edit with it). I've written a very
simple assembler in it, ages ago, which did assembling on the fly.
--
John Bokma j3b
Hacking & Hiking in Mexico - http://johnbokma.com/
http://castleamber.com/ - Perl & Python Development
== 2 of 10 ==
Date: Wed, Feb 3 2010 12:40 pm
From: Robert
Vladimir Ignatov wrote:
> dynamic-type languages. Instead of current text-oriented IDEs, it
> should be a database-centric and resemble current CAD systems instead
> of being just "fancy text editor". Source text should be an output
> product of that CAD and not a "source material" itself.
can you sketch an example/use case more concretely?
Robert
== 3 of 10 ==
Date: Wed, Feb 3 2010 12:44 pm
From: Phlip
John Bokma wrote:
> my $x = ( 5, "hello", sub {}, [], {} )[ int rand 5 ];
>
> what's $x? The answer is: it depends.
That's why my blog post advocated (as usual for me) developer tests.
Then you either mock the rand, like all developers should, or you get
what you pay for, and Principle of Least Surprise still applies...
Over the past decade, teams discovered that developer tests more than
made up for the lack of rigor in dynamic languages. A dynamic language
with tests can be more productive than a static language, even with
its runtime type checks AND with its tests.
However, our editors must catch up to us. When I test, I am statically
declaring a set of types, even if the language would prefer to
dynamically fling them hither and yon. We should leverage that.
--
Phlip
== 4 of 10 ==
Date: Wed, Feb 3 2010 1:02 pm
From: John Bokma
Phlip <phlip2005@gmail.com> writes:
> John Bokma wrote:
>
>> my $x = ( 5, "hello", sub {}, [], {} )[ int rand 5 ];
>>
>> what's $x? The answer is: it depends.
>
> That's why my blog post advocated (as usual for me) developer tests.
> Then you either mock the rand, like all developers should, or you get
> what you pay for, and Principle of Least Surprise still applies...
Yup, I agree with you that (to some extent) an IDE should be able to
determine types, especially if programmers don't reuse variables, like
(again Perl):
my $result = .... # int
:
:
if ( ... ) {
$result = .... # string
}
# $result can be still an int, or either a string, depending on the
# test.
> Over the past decade, teams discovered that developer tests more than
> made up for the lack of rigor in dynamic languages. A dynamic language
> with tests can be more productive than a static language, even with
> its runtime type checks AND with its tests.
Yup, this matches up with my experience. I can't recall that I ever
bumped into an issue in Perl (the dynamic language I've been using
the most for the past years). Not saying that it hasn't happened, but I
just can't recall. Probably also the reason why a "new" language I am
learning is also dynamic: Python ;-)
> However, our editors must catch up to us. When I test, I am statically
> declaring a set of types, even if the language would prefer to
> dynamically fling them hither and yon. We should leverage that.
I am all for testing, but it should IMO not get into the way. I am quite
happy with Emacs as an editor (I "recently" switched), it satisfies most
(if not all) of the items on the check list.
--
John Bokma j3b
Hacking & Hiking in Mexico - http://johnbokma.com/
http://castleamber.com/ - Perl & Python Development
== 5 of 10 ==
Date: Wed, Feb 3 2010 1:10 pm
From: John Bokma
Robert <no-spam@non-existing.invalid> writes:
> Vladimir Ignatov wrote:
>> dynamic-type languages. Instead of current text-oriented IDEs, it
>> should be a database-centric and resemble current CAD systems instead
>> of being just "fancy text editor". Source text should be an output
>> product of that CAD and not a "source material" itself.
>
> can you sketch an example/use case more concretely?
I guess Vladimir means what's called a structure editor. The (by me)
aforementioned Synthesizer Generator is an example of such an editor
(environment).
http://en.wikipedia.org/wiki/Structure_editor
http://portal.acm.org/citation.cfm?doid=358746.358755
--
John Bokma j3b
Hacking & Hiking in Mexico - http://johnbokma.com/
http://castleamber.com/ - Perl & Python Development
== 6 of 10 ==
Date: Wed, Feb 3 2010 1:24 pm
From: Vladimir Ignatov
> can you sketch an example/use case more concretely?
Sorry, I don't have anything written down. I just have some rough idea
of implementation and some concrete features I would like to see in
such system. For example:
1) Instant refactoring. No more needs for manual
search/inspect/rename. Since system knows exactly that is going on,
the refactoring will be fully automatic.
2) Show "xref table" for each function. How often this function used?
Where is it used? (code snippets of calls) What functionality is
supported by this function?
3) Extended statistics. How many objects this object/function
interacts with? Popular functions, dead/unused functions.
4) Code smell detector - too long functions, too much interaction with
other objects, global objects, etc.
...
Vladimir Ignatov
== 7 of 10 ==
Date: Wed, Feb 3 2010 1:27 pm
From: Robert Kern
On 2010-02-03 14:40 PM, Robert wrote:
> Vladimir Ignatov wrote:
>> dynamic-type languages. Instead of current text-oriented IDEs, it
>> should be a database-centric and resemble current CAD systems instead
>> of being just "fancy text editor". Source text should be an output
>> product of that CAD and not a "source material" itself.
>
> can you sketch an example/use case more concretely?
I believe that Smalltalk came pretty close to what Vladimir is asking for. You
wrote the methods as linear plain text, but you used the GUI three pane class
browser to define and navigate classes. You could export class definitions to a
text file and read them back in, but in Vladimir's terms, the text files were
not the "source material" themselves.
http://www.cosc.canterbury.ac.nz/wolfgang.kreutzer/cosc205/smalltalk1.html
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco
== 8 of 10 ==
Date: Wed, Feb 3 2010 1:36 pm
From: Vladimir Ignatov
> I guess Vladimir means what's called a structure editor. The (by me)
> aforementioned Synthesizer Generator is an example of such an editor
> (environment).
Maybe. Yes, it kind of "generator". It has (entered somehow) internal
representation of target program. Then it generates code out of this
internal data. Yes, it is imaginable system, I don't have any working
prototype yet. But about to start making it. For prototype I choose
python 2.x as implementation language, sqlite as internal database and
Django as UI.
Vladimir Ignatov
== 9 of 10 ==
Date: Wed, Feb 3 2010 1:37 pm
From: Steven D'Aprano
On Wed, 03 Feb 2010 08:18:40 -0500, Adam Tauno Williams wrote:
> On Wed, 2010-02-03 at 14:10 +0300, Vladimir Ignatov wrote:
>> Hello,
>> I am sitting here for quite some time, but usually keep silent ;-) I
>> use Python since 2003 both "professionally" and for my hobby projects
>> and love it a much.
>> I notice however, that "maintaining" existing/older python code is may
>> be not so enjoyable task. It may be even harder than supporting old
>> code written in some type of "static" languages (like Java or C++).
>> Surely "dynamic" nature of python comes with price.
>
> Yes, it certainly does. Not that you'll get many Pythonistas to confess
> to that fact. Somehow those who brag about the readability and
> expressiveness of source code just cannot admit that:
>
> class.method(sting name, int count)
>
> - is *obviously* more expressive than -
>
> class.method(name, count)
Obviously? I don't know about that. Being told that "count" is an int
doesn't really help me -- it's obvious just from the name. In a well-
written API, what else could it be?
And surely count should be positive or zero but not negative? Saying it's
an int is misleading. Or perhaps count can be negative, in which case
maybe negative counts have some special meaning that isn't obvious from
the function signature. Can I pass None to get the default behaviour?
Either way, I need to read the docs, so the supposed added expressiveness
doesn't actually add much.
And why is count limited to an actual int type, rather than anything
which is integer-like? Why can't I pass 3.0 or Decimal(3)? If you have a
good reason for that limitation, great, but if it's just there to satisfy
the compiler, then boo hiss to you.
I cheerfully admit that *sometimes* there are type restrictions which
make sense, and of course we know that there are sometimes useful
performance gains to be made with static typing. Any compiler which
requires types to be declared is far too 1970s though -- a good modern
static language should use type inference to reduce the number of
declarations needed.
As for Pythonistas refusing to accept this, how do you explain function
annotations then?
Quoting Guido:
"Optional static typing has long been requested as a Python feature."
http://www.artima.com/weblogs/viewpost.jsp?thread=85551
More on function annotations and type inference for Python:
http://lambda-the-ultimate.org/node/1519
http://www.python.org/dev/peps/pep-3107/
http://www.python.org/workshops/2000-01/proceedings/papers/aycock/aycock.html
> This is obvious even in the Python documentation itself where one
> frequently asks oneself "Uhh... so what is parameter X supposed to be...
> a string... a list... ?"
The answer is usually "both, and anything else that obeys some subset of
the sequence or iterable protocols".
--
Steven
== 10 of 10 ==
Date: Wed, Feb 3 2010 1:40 pm
From: Steven D'Aprano
On Wed, 03 Feb 2010 06:42:52 -0800, Paul Rubin wrote:
> One nice trick with static types is if you change
> what the method does (even if its type signature doesn't change), you
> can rename the method:
>
> class.method2(string name, int count): # change 'method' to
> 'method2'
>
> and recompile your codebase. Every place in the code that called
> 'method' now gets a compile time "undefined method" error that you can
> examine to see if you need to update it. This is something you can't
> catch with unit tests because the call sites can be in distant modules.
I don't understand why that won't work with unit tests. If you change the
name of a method, surely your unit tests will now start failing with
AttributeError?
--
Steven
==============================================================================
TOPIC: simple and fast platform independent IPC
http://groups.google.com/group/comp.lang.python/t/0fb9d731abbc5ab3?hl=en
==============================================================================
== 1 of 1 ==
Date: Wed, Feb 3 2010 12:09 pm
From: Terry Reedy
On 2/3/2010 6:31 AM, Joan Miller wrote:
>>> I've read that Pyro is not safe.
>>
>> That's a fairly broad thing to say. I've read lots
>> of things. What does "is not safe" mean, in any case?
>> I assume you've got a valid concern in mind which is
>> worth passing on to a would-be user, but what exactly
>> is it? FWIW I've used Pyro on and off over the years
>> without any problems. Certainly my computer's never
>> blown up as a result of using it.
>> From its own page:
> "Pyro has never been truly designed to provide a secure communication
> mechanism, nor has it had a security review or -test by a security
> expert."
> http://pyro.sourceforge.net/features.html
For communication between processes on one machine, that hardly seems to
be a worry. If it were, I would expect that sending encrypted strings
would substantially improve things.
That aside, I would wonder whether you could use a master process with a
gui to haphazardly launch subprocess, so as to avail oneself of
multiprocessing.Queue.
Terry Jan Reedy
==============================================================================
TOPIC: expy 0.5.2 released
http://groups.google.com/group/comp.lang.python/t/ea3018487d9365ec?hl=en
==============================================================================
== 1 of 1 ==
Date: Wed, Feb 3 2010 12:18 pm
From: Terry Reedy
On 2/3/2010 1:43 AM, Yingjie Lan wrote:
> Hi,
>
> expy is an expressway to extend python.
>
> in release 0.5.2, expy now supports custom exceptions, besides all built-in ones, and exception handling is made easy.
>
> for more info, see
>
> http://expy.sourceforge.net/
What Python versions does it work with?
There is no indication either above or on the sf page.
tjr
==============================================================================
TOPIC: Wrap a function
http://groups.google.com/group/comp.lang.python/t/fce27f8c4a22d12b?hl=en
==============================================================================
== 1 of 2 ==
Date: Wed, Feb 3 2010 12:33 pm
From: Dan Stromberg
Joan Miller wrote:
> On 28 ene, 21:40, Jonathan Gardner <jgard...@jonathangardner.net>
> wrote:
>
>> On Jan 28, 10:20 am, Joan Miller <pelok...@gmail.com> wrote:
>>
>>
>>
>>
>>> I've to call to many functions with the format:
>>>
>>>>>> run("cmd")
>>>>>>
>>> were "cmd" is a command with its arguments to pass them to the shell
>>> and run it, i.e.
>>>
>>>>>> run("pwd")
>>>>>>
>>> or
>>>
>>>>>> run("ls /home")
>>>>>>
>>> Does anybody knows any library to help me to avoid the use of the main
>>> quotes, and brackets?
>>>
>>> I would to use anything as:
>>>
>>> $ ls /home => run("ls /home")
>>>
>>> or, at least
>>>
>>> run pwd => run("pwd")
>>>
>> How about this?
>>
>> def pwd(): return run("pwd")
>>
>> pwd()
>>
>> def ls(l=False, files=()):
>> args = []
>> if l: args.insert(0, '-l')
>> args.append(files)
>> return run("ls", args)
>>
>> ls(l=True, "/foo")
>>
>
> There would be to make a function for each system command to use so it
> would be too inefficient, and follow the problem with the quotes.
>
> The best is make a parser into a compiled language
>
'disagree.
Best is to have a text file outside your program, in which you define
commands and symbolic names for those commands.
Then you have a python module which reads these commands and names, and
creates functions that invoke them via the specified name.
This way you get concise syntax, don't have to type as much boilerplate,
and don't add line noise.
Mixing two languages as though they were the same language greatly
increases the complexity of the original language with little gain.
Consider PowerShell - it's almost like two different languages smushed
together, and you have to know how a command was implemented to know how
to read it.
Also, what if someday The Powers That Be (the python language core
designers) decide they need to use $ for something? I hope they won't,
but if they do, your preprocessor might make quite a mess of it.
== 2 of 2 ==
Date: Wed, Feb 3 2010 12:41 pm
From: Dan Stromberg
Ben Finney wrote:
> Dennis Lee Bieber <wlfraed@ix.netcom.com> writes:
>
>
>> On Thu, 28 Jan 2010 11:24:28 -0800 (PST), Joan Miller:
>>
>>> On 28 ene, 19:16, Josh Holland <j...@joshh.co.uk> wrote:
>>>
>>>> Check the docs on os.system().
>>>>
>>> No. I've a function that uses subprocess to run commands on the same
>>> shell and so substitute to bash scrips. But a script full of run
>>> ("shell_command --with --arguments") is too verbose.
>>>
>> I shall blaspheme, and suggest that maybe the language you want
>> to use is REXX (ooREXX or Regina).
>>
>
> Heh. That isn't blasphemy, because no true Pythonista [0] would claim
> Python to be the god of that domain.
>
> It's no sin to say that Python isn't a good choice for specific things;
> and "I want to write programs by indistinguishably mixing statements
> with external system calls" is one of them, IMO
>From
http://stromberg.dnsalias.org/~dstromberg/debugging-with-syscall-tracers.html#terminology
A quick note on terminology: open() is typically a system call.
fopen is probably never a system call - instead, it is a function in
the C library that wraps open(), making open() easier to use. Then
there's the system() function - like fopen(), it isn't really a
system call, despite its name. Rather, it is a C library function
that typically will wrap the fork() and exec*() system calls.
==============================================================================
TOPIC: newbie qns : how do i use xmldiff?
http://groups.google.com/group/comp.lang.python/t/3a02ad06382e366b?hl=en
==============================================================================
== 1 of 1 ==
Date: Wed, Feb 3 2010 12:34 pm
From: Terry Reedy
On 2/3/2010 1:38 AM, sWrath swrath wrote:
> Hi ,
>
> I am pretty new to python , and reading up on it.
>
> Basically I am trying to compare xml files . I know difflib have it
> but it does not work out as expected. I was looking at xmldiff ,
> unfortunately I am not able to find documentation how to call it from
> python. Anyone knows a link or doc to it as I have been looking high
> and low for few days?
When asking such a question, it is good to explain what sort of thing,
in this case, 'xmldiff' is and where it is is from. Let us assume you
meant xmldiff from
It says it is a python tool that can "be used be used as a library or as
a command line tool." It includes a README file. Have you read that?
That says "USAGE ... Read the HELP.txt file.". Have you read *that*?
HELP.txt seems to focus on command line usage. I would start with that.
To use it as a library (via import ...), you might have to look at the
source code as I did not see importing covered in my quick look at that
file.
Terry Jan Reedy
==============================================================================
TOPIC: ANN: GMPY 1.11 released
http://groups.google.com/group/comp.lang.python/t/6b7dae7a8c90517e?hl=en
==============================================================================
== 1 of 1 ==
Date: Wed, Feb 3 2010 12:38 pm
From: Mensanator
On Feb 3, 12:36 pm, casevh <cas...@gmail.com> wrote:
> On Feb 3, 10:22 am, Mensanator <mensana...@aol.com> wrote:
>
>
> Historically, gmpy really didn't have alpha/beta/rc versions and
> gmpy.version() just had the version "number" and didn't indicate the
> status. If I change it, I'd rather go to "1.1.1rc1" or "1.2.0a0" but
> that might break some applications.
Ok. And historically, we never had Python 2.5, 2.6, 2.7 & 3.1
to support simultaneously with Windows Xp, Vista and 7 along
with Mac OSX 10.4, 10.5,& 10.6 as well as whatever flavors
Linnux comes it.
Not to mention that there's now two flavors of GMP.
How many different permutations do you suppose that is?
Thinking about it makes my head hurt. I certainly fell
sympathy towards you developers.
==============================================================================
TOPIC: Logging oddity: handlers mandatory in every single logger?
http://groups.google.com/group/comp.lang.python/t/c4da89f2c43b0bc8?hl=en
==============================================================================
== 1 of 1 ==
Date: Wed, Feb 3 2010 12:44 pm
From: Vinay Sajip
On Feb 3, 11:36 am, Masklinn <maskl...@masklinn.net> wrote:
Well, Xavier,
I would be the first to agree that the existing logging configuration
API is not ideal. There are a number of reasons for the current
ConfigParser schema used (e.g. an old GUI for configuring logging,
which was there before the logging package was added to Python, but
which was not brought across). However, there is no point in
nitpicking over the particular shortcomings you've focused on, unless
of course you've run out of bikesheds to paint ;-)
Particularly as I've just received the good news from Guido van Rossum
that PEP 391 (Dictionary-Based Configuration For Logging) has been
accepted, and my aim is to get it into Python 2.7 and Python 3.2.
Now, PEP 391 was announced on python-list and python-dev in October
2009, so plenty of people have had an opportunity to comment on it.
Going forwards, and over time, I would hope that this configuration
scheme will supplant the ConfigParser-based approach, and so I don't
think there's much need to tinker with that API.
Onwards, upwards, ever forwards :-)
Regards,
Vinay Sajip
==============================================================================
TOPIC: How to guard against bugs like this one?
http://groups.google.com/group/comp.lang.python/t/fe6430e7980e2a96?hl=en
==============================================================================
== 1 of 1 ==
Date: Wed, Feb 3 2010 1:09 pm
From: Dan Stromberg
kj wrote:
> I just spent about 1-1/2 hours tracking down a bug.
>
> An innocuous little script, let's call it buggy.py, only 10 lines
> long, and whose output should have been, at most two lines, was
> quickly dumping tens of megabytes of non-printable characters to
> my screen (aka gobbledygook), and in the process was messing up my
> terminal *royally*. Here's buggy.py:
>
>
>
> import sys
> import psycopg2
> connection_params = "dbname='%s' user='%s' password='%s'" % tuple(sys.argv[1:])
> conn = psycopg2.connect(connection_params)
> cur = conn.cursor()
> cur.execute('SELECT * FROM version;')
> print '\n'.join(x[-1] for x in cur.fetchall())
>
>
> (Of course, buggy.py is pretty useless; I reduced the original,
> more useful, script to this to help me debug it.)
>
> Through a *lot* of trial an error I finally discovered that the
> root cause of the problem was the fact that, in the same directory
> as buggy.py, there is *another* innocuous little script, totally
> unrelated, whose name happens to be numbers.py. (This second script
> is one I wrote as part of a little Python tutorial I put together
> months ago, and is not much more of a script than hello_world.py;
> it's baby-steps for the absolute beginner. But apparently, it has
> a killer name! I had completely forgotten about it.)
>
> Both scripts live in a directory filled with *hundreds* little
> one-off scripts like the two of them. I'll call this directory
> myscripts in what follows.
>
> It turns out that buggy.py imports psycopg2, as you can see, and
> apparently psycopg2 (or something imported by psycopg2) tries to
> import some standard Python module called numbers; instead it ends
> up importing the innocent myscript/numbers.py, resulting in *absolute
> mayhem*.
>
> (This is no mere Python "wart"; this is a suppurating chancre, and
> the fact that it remains unfixed is a neverending source of puzzlement
> for me.)
>
> How can the average Python programmer guard against this sort of
> time-devouring bug in the future (while remaining a Python programmer)?
> The only solution I can think of is to avoid like the plague the
> basenames of all the 200 or so /usr/lib/pythonX.XX/xyz.py{,c} files,
> and *pray* that whatever name one chooses for one's script does
> not suddenly pop up in the appropriate /usr/lib/pythonX.XX directory
> of a future release.
>
> What else can one do? Let's see, one should put every script in its
> own directory, thereby containing the damage.
>
> Anything else?
>
> Any suggestion would be appreciated.
>
> TIA!
>
> ~k
>
Here's a pretty simple fix that should work in about any version of
python available:
Put modules in ~/lib. Put scripts in ~/bin. Your modules end with
.py. Your scripts don't. Your scripts add ~/lib to sys.path as
needed. Things that go in ~/lib are named carefully. Things in ~/bin
also need to be named carefully, but for an entirely different reason -
if you name something "ls", you may get into trouble.
Then things in ~/lib plainly could cause issues. Things in ~/bin don't.
Ending everything with .py seems to come from the perl tradition of
ending everything with .pl. This perl tradition appears to have come
from perl advocates wanting everyone to know (by looking at a URL) that
they are using a perl CGI. IMO, it's language vanity, and best
dispensed with - aside from this issue, it also keeps you from rewriting
your program in another language with an identical interface.
This does, however, appear to be a scary issue from a security
standpoint. I certainly hope that scripts running as root don't search
"." for modules.
==============================================================================
TOPIC: PEP 3147 - new .pyc format
http://groups.google.com/group/comp.lang.python/t/7a0d8230a5907885?hl=en
==============================================================================
== 1 of 1 ==
Date: Wed, Feb 3 2010 1:17 pm
From: Steven D'Aprano
On Wed, 03 Feb 2010 11:55:57 +0100, Daniel Fetchinson wrote:
[...]
>> Python does most of that for you: it automatically recompiles the
>> source whenever the source code's last modified date stamp is newer
>> than that of the byte code. So to a first approximation you can forget
>> all about the .pyc files and just care about the source.
>
> True, but the .pyc file is lying around and I always have to do 'ls -al
> | grep -v pyc' in my python source directory.
So alias a one-word name to that :)
[...]
> Here is an example: shared object files. If your code needs them, you
> can use them easily, you can access them easily if you want to, but they
> are not in the directory where you keep your C files. They are somewhere
> in /usr/lib for example, where they are conveniently collected, you can
> inspect them, look at them, distribute them, do basically whatever you
> want, but they are out of the way, and 99% of the time while you develop
> your code, you don't need them. In the 1% of the case you can easily get
> at them in the centralized location, /usr/lib in our example.
>
> Of course the relationship between C source files and shared objects is
> not parallel to the relationship to python source files and the created
> pyc files, please don't nitpick on this point. The analogy is in the
> sense that your project inevitable needs for whatever reason some binary
> files which are rarely needed at hand, only the
> linker/compiler/interpreter/etc needs to know where they are. These
> files can be stored separately, but at a location where one can inspect
> them if needed (which rarely happens).
I'll try not to nit-pick :)
When an object file is in /usr/lib, you're dealing with it as a user.
You, or likely someone else, have almost certainly compiled it in a
different directory and then used make to drop it in place. It's now a
library, you're a user of that library, and you don't care where the
object file is so long as your app can find it (until you have a
conflict, and then you do).
While you are actively developing the library, on the other hand, the
compiler typically puts the object file in the same directory as the
source file. (There may be an option to gcc to do otherwise, but surely
most people don't use it often.) While the library is still being
actively developed, the last thing you want is for the object file to be
placed somewhere other than in your working directory. A potentially
unstable or broken library could end up in /usr/lib and stomp all over a
working version. Even if it doesn't, it means you have to be flipping
backwards and forwards between two locations to get anything done.
Python development is much the same, the only(?) differences are that we
have a lower threshold between "in production" and "in development", and
that we typically install both the source and the binary instead of just
the binary.
When you are *using* a library/script/module, you don't care whether
import uses the .py file or the .pyc, and you don't care where they are,
so long as they are in your PYTHONPATH (and there are no conflicts). But
I would argue that while you are *developing* the module, it would more
nuisance than help to have the .pyc file anywhere other than immediately
next to the .py file (either in the same directory, or in a clearly named
sub-directory).
--
Steven
==============================================================================
TOPIC: Python and Ruby
http://groups.google.com/group/comp.lang.python/t/dfe4f6c60032755e?hl=en
==============================================================================
== 1 of 1 ==
Date: Wed, Feb 3 2010 1:32 pm
From: Jonathan Gardner
On Feb 2, 9:11 pm, John Bokma <j...@castleamber.com> wrote:
> Jonathan Gardner <jgard...@jonathangardner.net> writes:
> > I can explain, in an hour, every single feature of the Python language
> > to an experienced programmer, all the way up to metaclasses,
>
> Either you're a hell of a talker, or I am far, far away from being an
> experienced programmer. It's advocacy like this, IMO, that keeps people
> away from a language, because you can't feel nothing but a failure after
> a statement like this.
>
I can explain all of Python in an hour; I doubt anyone will understand
all of Python in an hour.
Coming from perl to python, the big "aha!" moment was when I realized
there wasn't anything more than what I saw before me. I kept expecting
something big around the corner, kind of like when I first discovered
refs in perl, or when I realized how hard it truly was to write OO
code in perl that actually does what you think it should do.
Perl has trained me to be fearful of the language, constantly on the
lookout for jabberwockies. If you fall into one of those traps in
perl, it's because you weren't smart enough and aren't worthy of the
language, or so they say. It's never perl's fault. I mean, doesn't
everyone know what the Schwartzian Transform is?
Python is the complete opposite. Go through http://docs.python.org/reference/
. Once you've familiarized yourself with all the operators,
statements, and the special methods, you're done with syntax and the
core language. There is no more.
The next step is to learn the basic objects and functions in builtins.
That's in the first seven chapters of http://docs.python.org/library/index.html.
You can always fall back to the "help" function to remind yourself if
you forget. I do it all the time.
After that, it's merely figuring out which standard libraries do what
and how. The documentation there is complete and awesome, and there
are more than enough people willing to point you in the right
direction here.
There are no dragons in this forest. Heck, this isn't even a forest---
it's a single-room apartment with everything you need right there
where you can see it. The thermostat is set to room temperature, and
no matter what happens outside, you're safe and protected from it all.
==============================================================================
You received this message because you are subscribed to the Google Groups "comp.lang.python"
group.
To post to this group, visit http://groups.google.com/group/comp.lang.python?hl=en
To unsubscribe from this group, send email to comp.lang.python+unsubscribe@googlegroups.com
To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.python/subscribe?hl=en
To report abuse, send email explaining the problem to abuse@googlegroups.com
==============================================================================
Google Groups: http://groups.google.com/?hl=en
No comments:
Post a Comment