Re: The Modernization of Emacs: terminology buffer and keybinding

[David Kastrup]

Twisted <[EMAIL PROTECTED]> writes:

> On Jun 23, 2:04 am, Robert Uhl <[EMAIL PROTECTED]> wrote:
>
>> > Besides, ANY interface that involves fumbling around in the dark
>> > trying to find a light switch is clunky.
>>
>> That sounds like vi, not emacs.
>
> That sounds like any application where you need to read the help, but
> "f1" does not bring up a separate help window, switchable with the
> main one using alt-tab or the mouse, and navigable using arrows,
> pageup, pagedn, and the mouse.

Well, f1 brings up a prompt: f1 (type ? for further options)-
Typing ? brings up a separate window (and instructions how to scroll
it) with a variety of help options, among them the tutorial.  If you
want a separate window, File/New Frame will give you that.  Of course,
switchable with the main one using alt-tab or the mouse, and navigable
using arrows, pageup, pagedn and the mouse.

> The result of that is invariably that when the document has the
> focus, the help is open to "help on switching windows" rather than
> whatever you need it to be on once the document has the focus. You
> can read the help on doing what you want to do with the document,
> but to apply it you need to transfer focus back to the document. If
> doing that isn't second-nature, you have to navigate the help away
> from where you need it to get the focus back to the document.

Nonsense.

> Now the focus is on the document, but the help you need isn't
> displayed next to it anymore. Frustrating? You can't begin to
> imagine, I suspect. Apparently, some people are born somehow able to
> avoid this problem without having to memorize one or the other piece
> of help. You're clearly one of those. I am equally clearly NOT one
> of those. Of course, if emacs let you keep THREE windows open and
> visible at the same time, instead of being limited to one or a
> horizontally split two ...

Which it does...

> and a cramped 80x10 or so each, at that ...

Emacs frames can certainly be resized and repositioned at will using
the mouse...

You are really babbling a lot of nonsense that is, at best, somewhat
relevant for prehistoric versions of Emacs without GUI support.

Just shut up until you have installed and worked with a modern version
of Emacs.

> If I haven't, it must be the case that finding this tutorial (or
> even discovering that it exists) was nontrivial, or it wasn't built
> into emacs, one or the other. My memory is somewhat fuzzy after all
> these years so you'll forgive me if I don't make a definite
> statement about which.

"After all these years"...  You really should not rely on 10-year old
memories about an application.

> On the flip side, if I have, the tutorial can't have been all it's
> cracked up to be. Especially given I can program Java proficiently,

Apparently, at the time you last looked at Emacs, Java did not yet
exist.

> including some fairly sophisticated network-using tools, and clearly
> am not an idiot or untalented in technically demanding areas
> involving substantial amounts of arcana.

Up to now you have not delivered any discourse that would warrant the
"clearly" in this sentence.  Not that using Emacs involved
"substantial amounts of arcana".

> The technical term for managing limited resources, such as time and
> effort, first where needed and never where avoidable, is
> "efficiency", in case you were unaware.

Sure, but babbling about a system you have never seen in its present
state for 10 years, and consequently putting your foot in your mouth
in hundreds of postings requiring hours of times spread over several
months, when it would take all of 10 minutes to get your information
somewhat up to scratch, is called "stupidity", in case you were
unaware.

>> or you're just making things up.
>
> Also untrue, and you've just accused me of incompetence once and of
> lying twice, which in a formerly civil discussion constitutes
> behavior that I consider to be in poor taste.

Well, so what is it about you accusing people of lying that report
experiences about a system you have never looked at in its current
state?  You even accused me of lying when I posted _screenshots_ from
a publicly accessible site, suspecting me of forgery.

>> If I'm browsing the manual online, I can switch from said manual to
>> my document buffer without making the manual scroll to the
>> documentation for switch-to-buffer.
>
> Apparently because you find the switch second nature, despite its
> not being the obvious (which is ctrl-tab, to switch between
> documents in an MDI app).

And which works fine when using Emacs frames.  Look, you are making a
complete spectable of yourself.  Get a current version of Emacs and
actually try it.

> Cheat sheet? Memorized with painstaking months of hard effort?
> Thanks for proving my point, either way.

You are babbling.  Not that this is new.

>> In fact, I am not aware of any package which auto-changes the
>> *info* or *Help* buffers to reflect the last keyboard command.
>
> I didn't say it auto-changes. It

Re: The Modernization of Emacs: terminology buffer and keybinding

[Twisted]

On Jun 23, 11:56 am, Bjorn Borud <[EMAIL PROTECTED]> wrote:
> [Twisted <[EMAIL PROTECTED]>]
> |
> | That sort of negative-sum thinking is alien to me. Software being easy
> | for beginners to get started using does not in and of itself detract
> | from its value to expert users.
>
> the fact that you imply that this is my argument tells me that either
> you have not paid attention, or you have a raging inferiority complex.
> given the sum of your postings so far I'd say that you neither are,
> nor consider yourself, a cerebral sort of person, so this narrows it
> down somewhat (although not to the exclusion of you not having paid
> attention).

That ... makes no sense. Sorry. Previously, I said:

> Being beginner-friendly doesn't have to be at the expense of power or
> expert-user usability

and you said that depended on the definition of "expert". Apparently
you believe there is a type of "expert" for whom beginner-friendly
software is intrinsically less usable than beginner-hostile software.

Given that beginner-friendliness does not preclude any kind of expert
level functionality being available (consider something configurable
enough that an advanced user can start it up and open an advanced-uses
window and immediately do advanced stuff, and a real expert can make
it start up with that window already open and focused by default), it
follows that these experts' perceptions of decreased usability are a
psychological result of simply knowing beginners can easily become
proficient in using basic functions of the software in question,
rather than a material result of some compromise necessarily made in
the software's design, as there is no such compromise that can't in
practise be avoided.

An expert who feels software is less suitable for his use *purely*
because the unwashed masses can actually use it to accomplish
something is quite obviously some type of elitist jerk.

I rest my case.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The Modernization of Emacs: terminology buffer and keybinding

[Twisted]

On Jun 23, 8:35 pm, Robert Uhl <[EMAIL PROTECTED]> wrote:
> Twisted <[EMAIL PROTECTED]> writes:
>
> > For an example of the latter, consider opening a file. Can't remember
> > the exact spelling and capitalization of the file name? Sorry, bud,
> > you're SOL. Go find it in some other app and memorize the name, then
> > return to emacs.
>
> Once again I am forced to wonder if you have _ever_ actually used
> emacs.  find-file has tab completion: hit tab without anything typed, and
> it displays _everything_ in the directory; type a few characters to
> narrow it down; hit tab to complete the filename and be done with it.
>
> Or of course you could use directory mode, which enables you to navigate
> around a directory tree, performing actions on files (including editing
> them).
>
> Then of course there's ido.el, which is even better: type a few
> characters from anywhere in the name, and it displays files matching
> those characters.

Really? None of this happens if you just do the straightforward file-
open command, which should obviously at least provide a navigable
directory tree, but definitely does not. One sounds like it involves
managing a separate open window on each directory you're interested in
(versus having a file...open dialog that falls open to the last place
you'd left it and doesn't clutter up any space when you're not opening
a file); the other sounds like it involves actually installing a
plugin of some kind, which is obviously well beyond what a beginner
should need to do just to get a freaking directory listing. :) Tab
completion is a poor cousin to a real directory tree navigator, as I'm
sure most would agree. Even if it will show all matches to a partial
name instead of none, it's the textual equivalent of navigating a
directory tree made into menus instead of provided by a proper folder
view window. Windows users unfortunately have the experience
regularly: the notorious Start menu. You have to expand submenus to
find stuff, and you can't leave it idling to do something somewhere
else and come back to it because it's a menu. Moreover, clicking an
item may display a large number of items the next level down, which
runs into screen display space issues. Even a large video mode can't
hide the fact that menus weren't really designed to list hundreds of
sibling items or for scrolling or finding stuff in a large set of
files, unlike folder windows. I can only imagine the pain of trying to
navigate an equivalent way in an 80x25 box of text information. That
would be like navigating the Windows start menu from outside your
house by peeking through a keyhole and reaching through a window with
a repurposed straightened out coathanger. Clumsy AND the neighbors'll
see you and call the cops well before you find the item you're looking
for. :) (Navigating the Windows start menu in safe mode, at 640x480,
is about as close as most Windows users are ever likely to come to the
nightmare of opening a file in emacs when you don't already know its
exact path.)

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The Modernization of Emacs: terminology buffer and keybinding

[Twisted]

On Jun 23, 2:04 am, Robert Uhl <[EMAIL PROTECTED]> wrote:
> Of course, emacs doesn't take years of mastery.  It takes 30, 40
> minutes.

I gave it twice that, and it failed to grow on me in that amount of
time.

> > Besides, ANY interface that involves fumbling around in the dark
> > trying to find a light switch is clunky.
>
> That sounds like vi, not emacs.

That sounds like any application where you need to read the help, but
"f1" does not bring up a separate help window, switchable with the
main one using alt-tab or the mouse, and navigable using arrows,
pageup, pagedn, and the mouse. The result of that is invariably that
when the document has the focus, the help is open to "help on
switching windows" rather than whatever you need it to be on once the
document has the focus. You can read the help on doing what you want
to do with the document, but to apply it you need to transfer focus
back to the document. If doing that isn't second-nature, you have to
navigate the help away from where you need it to get the focus back to
the document. Now the focus is on the document, but the help you need
isn't displayed next to it anymore. Frustrating? You can't begin to
imagine, I suspect. Apparently, some people are born somehow able to
avoid this problem without having to memorize one or the other piece
of help. You're clearly one of those. I am equally clearly NOT one of
those. Of course, if emacs let you keep THREE windows open and visible
at the same time, instead of being limited to one or a horizontally
split two ... and a cramped 80x10 or so each, at that ...

> > Applications that not only eschew normal methods of navigation of the
> > interface, but force you to fumble your way between the help and the
> > task you're trying to do, are definitely clunky.
>
> a) emacs doesn't 'eschew normal methods of navigation'; it's been doing
>its own thing since before there _were_ Mac OS or Windows

I'll admit that it didn't USED TO 'eschew normal methods of
navigation', but at a certain point in time there began to be 'normal
methods of navigation' and emacs naturally began eschewing them
promptly and has done so ever since.

> b) I believe you've never used the emacs tutorial, which is quite
>definitely designed for you _not_ to have to fumble around between
>windows

If I haven't, it must be the case that finding this tutorial (or even
discovering that it exists) was nontrivial, or it wasn't built into
emacs, one or the other. My memory is somewhat fuzzy after all these
years so you'll forgive me if I don't make a definite statement about
which. On the flip side, if I have, the tutorial can't have been all
it's cracked up to be. Especially given I can program Java
proficiently, including some fairly sophisticated network-using tools,
and clearly am not an idiot or untalented in technically demanding
areas involving substantial amounts of arcana. Of course, I might have
put more effort into learning effective Java; effort like that in
learning some language is necessary to being a programmer. Thanks to
modern editors and IDEs, putting a comparable amount into learning the
mere mechanics of operating a text editor is not necessary, and I
chose to spend the time and effort elsewhere, where it was necessary,
such as on learning a programming language.

The technical term for managing limited resources, such as time and
effort, first where needed and never where avoidable, is "efficiency",
in case you were unaware.

> > The interface never improved over that time -- the biggest problem
> > consistently being that whenever focus was successfully transferred to
> > the document window, the help window was invariably open to the
> > instructions for switching windows, so you could never be doing
> > something with the document and have the help for that something
> > available at a glance.
>
> That doesn't even make sense.  Either your memory is faulty

Impossible

> you've never actually used emacs

Untrue

> or you're just making things up.

Also untrue, and you've just accused me of incompetence once and of
lying twice, which in a formerly civil discussion constitutes behavior
that I consider to be in poor taste.

> If I'm browsing the manual
> online, I can switch from said manual to my document buffer without
> making the manual scroll to the documentation for switch-to-buffer.

Apparently because you find the switch second nature, despite its not
being the obvious (which is ctrl-tab, to switch between documents in
an MDI app). Cheat sheet? Memorized with painstaking months of hard
effort? Thanks for proving my point, either way.

> In fact, I am not aware of any package which auto-changes the *info* or
> *Help* buffers to reflect the last keyboard command.

I didn't say it auto-changes. It manual-changes. The exact sequence of
events that causes this with a novice user being:
* Need to do X, and the usual command doesn't work (e.g. go to save
document and get search prompt)
* Now nothing much works (typ

Re: is this a valid import sequence ?

[Alex Martelli]

Steven D'Aprano <[EMAIL PROTECTED]> wrote:
   ...
> >> It's never _wrong_ to use the global statement, even if it is strictly
> >> unnecessary for the Python compiler.
> > 
> > So, repeat that global statement ninetyseven times -- that's not
> > "wrong", either, in exactly the same sense in which it's not "wrong" to
> > have it once -- the Python compiler will not complain.  And by repeating
> > it over and over you make it less likely that a reader could miss it, so
> > it's even more "self-documenting" and "easier to read", right?
> 
> No, repeating it ninety-seven times doesn't make it easier to read, it
> makes it *harder* to read, and I'm sure I don't need to explain why.

You do, if you claim you're consistent in your "never _wrong_"
assertion.  How many totally useless repetitions are "never wrong"? I
claim: ZERO; even ONE totally useless statement is one too many.  You
appear to want to put the bar elsewhere, but then it's not clear WHERE.


> > "Perfection is reached, not when there is no longer anything to
> > add, but when there is no longer anything to take away", as Antoine de
> > Saint-Exupery wrote.
> 
> That's debatable. Why does Python have decorators when there was already a
> perfectly usable syntax for setting a method to function(method)? And
> let's not even mention x += 1 etc.

A decorator "takes away" some redundancy and repetition from an
important idiom:

@deco
def somefunction ...
   ...

stands for
def somefunction ...
   ...
somefunction = deco(somefunction)

where 'somefunction' needed to be repeated THREE times.  Similarly,
though not quite as dramatically,

somevariable += whatever

can stand for

somevariable = somevariable + whatever

again taking away one (now needless) repetition.  (Actually, the
existence of inplace addition for some types makes += even more useful,
as it polymorphically resolves to "what it _should_" resolve to:-).

In sharp and enormous contrast, the construct you're defending ADDS
useless repetition -- a statement that carries NO relevant information
whatsoever, and in particular needlessly repeat a variable name.

How can you SERIOUSLY claim ANY equivalence between constructs that
REMOVE redundancy, and your defense of one that ADDS it?!


> > Since that global statement is utterly useless
> > (it's impossible to read and understand any substantial amount of Python
> > code without realizing that accessing a variable not locally assigned
> > means you're accessing a global, so the "self-documenting" character
> > claimed for that redundancy is quite fallacious),
> 
> Sure, in the *specific* example given, the body of the function was so
> short that it would be a pretty poor developer who didn't know it was a
> global.
> 
> But in a more substantial function, one using lots of variables, it might
> not be clear which were global and which weren't unless you studied the
> code, line-by-line.

If a function is so long and complicated, and in particular uses so many
variables, that you lose track of what variables are local and which
ones global, then adding a 'global' statement (or more) is tantamount to
putting a bandaid over a large, gaping wound that's bleeding copiously
and unarrestably.  Forget such pitiful attempts at half-hearted kludgey
"remedies", and refactor mercilessly -- that one, huge, hopelessly
confused and confusing function, MUST become a (hopefully small) set of
small, shiny, crystal-clear ones.  In this sense, the presence of a
totally useless "global" statement, which may have been used in the vain
hope of effecting such unworkable "remedy", is yet another red flag
waving -- it may indicate the programmer suspects he's overflowed the
boundaries of good taste and maximum sensible complication, while
lacking the guts to do the refactoring such a situation desperately
calls for.


> > it IS perfectly
> > suitable to take away, and so it's at least a serious imperfection.  It
> > violates Occam's Razor, by multiplying entities (specifically
> > statements) without necessity.  It's just about as bad as sticking a
> > semicolon at the end of every statement (to make it "self-documenting"
> > that the statement ends there), parentheses around the conditions in if
> > and while statements and the argument in return statements (to make it
> > "self-documenting" where those expressions start and end), and a few
> > other less common ways to waste pixels, screen space, readers' attention
> > spans, and everybody's time.
> 
> I'm not going to defend *any* of those practices. But I don't think
> explicitly stating that a name is global, even when strictly unnecessary,
> is in the same category. In practice, I wouldn't do so for a function that
> was as short as the one the Original Poster used.

I think it's an even more horrible practice than all others I list
(except for my later note on comments that lie).  Not only would I never
use it, but I would never tolerate it in any way, shape, or form: I
would not pass a code review for any code us

Re: pydoc with METH_VARGS

[7stud]

On Jun 23, 2:13 pm, Stuart <[EMAIL PROTECTED]> wrote:
> With my Python extension module all the function definitions are with
> METH_VARGS. The result being that pydoc, just puts "(...)" for the
> argument list. Can I hand edit this to put the specific variable names
> I want? With optional arguments in brackets or something?
>
> Thanks.

Are you asking whether you can change a text file that pydoc produces?

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The Modernization of Emacs: terminology buffer and keybinding

[Twisted]

On Jun 23, 10:36 am, Martin Gregorie <[EMAIL PROTECTED]>
wrote:
> However, there's a case he missed, probably through never using a CAD
> system. All the good ones can be driven either by mouse, or by
> non-chorded key sequences or any combo the user likes. The essence of
> CAD is very accurate pointing but all too many mice move slightly when
> clicked. Fortunately a decent CAD system offers the possibility of
> purely pointing with the mouse and doing everything else with the other
> hand on the keyboard. The result is both fast and extremely accurate.

Actually, what I prefer in (2D and 3D) visual design apps is the
ability to snap to some kind of grid/existing vertices, and to zoom in
close. Then small imprecisions in mouse movement can be rendered
unimportant.

> An interface design point that nobody has yet mentioned here is that
> there are four different types of user that map onto a grid:
>
> casual  dedicated
> untrained   1   2
> expert  3   4
>
> I first ran across grid this in "Design of Man-Computer Dialogs" by
> James Martin and its been very useful in systems interface design.
>
> The problem with almost all current GUIs is that they are aimed at types
> 1 and 3 users - this certainly applies to Windows, OS X and Gnome
> desktops with the emphasis on type 1. vi and microEmacs, OTOH, are aimed
> at type 3 and 4 users.

The problem of course being the complete exclusion of type 1 users.
Everyone starts out as type 1, and I don't think type 2 occurs in
practise. You'd have to be some kind of religious nut to be
"dedicated" while still "untrained", rather than only as a result of
experience. Apps that provide no traction for a type 1 user will not
see much adoption except in an environment of immersion, mentoring, or
desperation. I wonder which of the three explains the majority of
emacs users, and of vi users, and whether those prove to be the same
one. :) (Actually, there'll be a single or a small number of class-2
users: the original developers, who presumably became dedicated before
having much experience *using* the tool. Their experiences are
atypical however, and their knowledge of the internals probably means
they're type 4 by the time they actually use it to do more than debug
it. Unsurprisingly, never experiencing it as a type 1 themselves they
tend to be inconsiderate of future type 1 users...this is normal, and
requires effort to avoid, in much the way blinkered views of stuff and
seeing what you want to see can be normal, and efforts like using
double-blind studies may be needed to avoid bias in evaluating, say, a
new drug. That such efforts are needed should not be seen as
disparaging the programmer or the drug-studier, but as merely
reflecting human nature, and as a simple pragmatic requirement if one
is to maximize utility.)

> Its very difficult indeed to design an interface that suits both
> untrained and expert users.

One with a bog-standard UI but also a "console" or command prompt,
scripting language, and customizable bindings?

Funnily enough I can count the software I've seen with that range of
capabilities (so able to satisfy type 1, 3, AND 4 users) on one hand.
Here's the list, in fact:

ROM BASICs and QBasic (on any really ancient microcomputer, and old
pre-Windows PCs, respectively; the former came with printed manuals
and you could just run prepackaged software from disks very easily;
QBasic had mouse and menu support, but an immediate mode command line.
You might not count ROM BASICS as as friendly, due to the lack of
menus and such, but then at that time in history NOTHING had menus and
such! And comprehensive introductory use manuals came with those, and
with pre-Windows PCs (DOS also had a decent and easy to navigate help
system). Most other BASICs and programming environments more generally
lack an integrated environment with an immediate mode prompt. Eclipse
actually sort of does, but the evaluate line can't be used really
arbitrarily and I've found it touchy, and rarely use it.

Hypercard (found commonly on old Macs; had a command prompt you could
access to directly communicate to an interpreter).

Fractint (fractal graphics making software for old pre-Windows PCs;
had a similar prompt, accessed by typing 'g', but also had extensive
help and menus readily controlled by stock keyboard commands such as
the arrow keys, and later a Windows port with menus and mouse
support).

Quake and descendants (yes, the games. Easy to just use the menus and
play the game. Advanced users could hit ~ to drop down a console and
do a few things. Really advanced ones made config files to rebind
weapons and make chat macros to fire off a taunting sentence with a
single keystroke -- no more embarrassment getting fragged while typing
it in longhand in mid-game. Super-advanced ones got at the QuakeC and
made bots, flag-capture mode mods, and other enhancements and
utilities. And sometimes cheats.)

There's probably some more out there, but I've yet 

Multimedia message

[6015292630]

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: is this a valid import sequence ?

[Steven D'Aprano]

On Sat, 23 Jun 2007 17:51:17 -0700, Alex Martelli wrote:

> Steven D'Aprano <[EMAIL PROTECTED]> wrote:
> 
>> On Sat, 23 Jun 2007 11:03:03 -0700, Scott David Daniels wrote:
>> 
>> > The global statement in Write_LCD_Data is completely unnecessary.  The
>> > only time you need "global" is if you want to reassociate the global
>> > name to another object (such as LCD = LCD + 1 or whatever).
>> 
>> That's technically true, but declaring it with global makes the code
>> self-documenting and therefore easier to read.
>> 
>> It's never _wrong_ to use the global statement, even if it is strictly
>> unnecessary for the Python compiler.
> 
> So, repeat that global statement ninetyseven times -- that's not
> "wrong", either, in exactly the same sense in which it's not "wrong" to
> have it once -- the Python compiler will not complain.  And by repeating
> it over and over you make it less likely that a reader could miss it, so
> it's even more "self-documenting" and "easier to read", right?

No, repeating it ninety-seven times doesn't make it easier to read, it
makes it *harder* to read, and I'm sure I don't need to explain why.


> "Perfection is reached, not when there is no longer anything to
> add, but when there is no longer anything to take away", as Antoine de
> Saint-Exupery wrote.

That's debatable. Why does Python have decorators when there was already a
perfectly usable syntax for setting a method to function(method)? And
let's not even mention x += 1 etc.


> Since that global statement is utterly useless
> (it's impossible to read and understand any substantial amount of Python
> code without realizing that accessing a variable not locally assigned
> means you're accessing a global, so the "self-documenting" character
> claimed for that redundancy is quite fallacious),

Sure, in the *specific* example given, the body of the function was so
short that it would be a pretty poor developer who didn't know it was a
global.

But in a more substantial function, one using lots of variables, it might
not be clear which were global and which weren't unless you studied the
code, line-by-line.


> it IS perfectly
> suitable to take away, and so it's at least a serious imperfection.  It
> violates Occam's Razor, by multiplying entities (specifically
> statements) without necessity.  It's just about as bad as sticking a
> semicolon at the end of every statement (to make it "self-documenting"
> that the statement ends there), parentheses around the conditions in if
> and while statements and the argument in return statements (to make it
> "self-documenting" where those expressions start and end), and a few
> other less common ways to waste pixels, screen space, readers' attention
> spans, and everybody's time.

I'm not going to defend *any* of those practices. But I don't think
explicitly stating that a name is global, even when strictly unnecessary,
is in the same category. In practice, I wouldn't do so for a function that
was as short as the one the Original Poster used.

But consider also something like this:

def func(): 
x, y = 1, 2
z = x + y
# lots more code doing many things here
# some of which involve w
return z + w

Let's pretend that there is sufficient code in there that it isn't obvious
at a glance that w is a global, okay?

There's a off-by-one error in the code, which we fix:

def func():
x, y = 1, 2
z = x + y
# lots more code doing many things here
# some of which involve w
w = w + 1
return z + w

"UnboundLocalError". Oops.


Now, I cheerfully admit that this scenario is contrived. Some people might
even argue that it is good for newbies to run into this error sooner
rather than later, but for those who don't think so, defensively inserting
a global statement might help prevent the issue from coming up.

I'm a big believer in letting newbies walk before running. I'd rather see
beginner programmers over-use global than under-use it. You're welcome to
disagree, but since UnboundLocalError seems to be one of the more
perplexing errors newbies suffer from, I think it is better for them to
avoid it until they've got a little more experience.


-- 
Steven.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python changing keywords name

[Gabriel Genellina]

[EMAIL PROTECTED] wrote:

> I  on working on windows and Python 2.4. Where can I find and CHANGE
> python
> grammar.  ( I just want to change the keywords )

Instead of changing Python grammar, you could convert your
"translated" source into "original" Python using the code below, and
compile and run as usual; you can also reverse the process. Also, this
lets you use the standard Python library and all other Python code
around the world.
Unlike a simple "search and replace", it understands the lexical
structure of a Python program, and won't replace a keyword inside a
quoted string, by example.
The core function is simple:

def translate_tokens(sourcefile, tdict):
for tok_num, tok_val, _, _, _ in
tokenize.generate_tokens(sourcefile.readline):
if tok_num==token.NAME: tok_val = tdict.get(tok_val, tok_val)
yield tok_num, tok_val

translated_code = tokenize.untokenize(
  translate_tokens(StringIO(original_code), translation_dictionary))

Note that you may encounter problems if the original code uses some
names matching the translated keywords.

(I hope nobody will abuse this technique... Y perdón a los
hispanoparlantes por lo horrible de la traducción).

--- begin code ---
from cStringIO import StringIO
import token
import tokenize

# "spanished" Python source from the SimplePrograms wiki page
code_es = r"""
BOARD_SIZE = 8

clase BailOut(Exception):
pasar

def validate(queens):
left = right = col = queens[-1]
para r en reversed(queens[:-1]):
left, right = left-1, right+1
si r en (left, col, right):
lanzar BailOut

def add_queen(queens):
para i en range(BOARD_SIZE):
test_queens = queens + [i]
intentar:
validate(test_queens)
si len(test_queens) == BOARD_SIZE:
retornar test_queens
else:
retornar add_queen(test_queens)
excepto BailOut:
pasar
lanzar BailOut

queens = add_queen([])
imprimir queens
imprimir "\n".join(". "*q + "Q " + ". "*(BOARD_SIZE-q-1) para q en
queens)
"""

# english keyword -> spanish
trans_en2es = {
'and': 'y',
'as': 'como',
'assert': 'afirmar',
'break': 'afuera',
'class': 'clase',
'continue': 'siguiente',
'def': 'def',
'del': 'elim',
'elif': 'sinosi',
'else': 'sino',
'except': 'excepto',
'exec': 'ejecutar',
'finally': 'finalmente',
'for': 'para',
'from': 'desde',
'global': 'global',
'if': 'si',
'import': 'importar',
'in': 'en',
'is': 'es',
'lambda': 'lambda',
'not': 'no',
'or': 'o',
'pass': 'pasar',
'print': 'imprimir',
'raise': 'lanzar',
'return': 'retornar',
'try': 'intentar',
'while': 'mientras',
'with': 'con',
'yield': 'producir',
}
# reverse dict
trans_es2en = dict((v,k) for (k,v) in trans_en2es.items())

def translate_tokens(source, tdict):
for tok_num, tok_val, _, _, _ in
tokenize.generate_tokens(source.readline):
if tok_num==token.NAME: tok_val = tdict.get(tok_val, tok_val)
yield tok_num, tok_val

code_en = tokenize.untokenize(translate_tokens(StringIO(code_es),
trans_es2en))
print code_en
code_es2= tokenize.untokenize(translate_tokens(StringIO(code_en),
trans_en2es))
print code_es2
--- end code ---

--
Gabriel Genellina

PS: Asking just once is enough.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The Modernization of Emacs

[Robert Uhl]

[EMAIL PROTECTED] writes:
>
> And both of them, though especially the latter, regarding what a
> feeping creature emacs is.

I like it.  Every new version has great new abilities.

> I don't suppose there's also a kitchen sink in there somewhere? Or is
> that just nethack?

Check out nethack.el .  You can run
nethack within emacs.  This, of course, means that there _is_ a kitchen
sink within emacs (when it's running nethack within itself)...

-- 
Robert Uhl 
I don't think the Java folks are nuts for what they've done.  I just
don't like how hard they make certain simple and important things.
 --Kent M. Pitman
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: trouble installing numpy 1.0.2 and scipy.0.5.2

[Robert Kern]

[EMAIL PROTECTED] wrote:
> I have tried to install numpy and scipy on python 5.2. Using gcc
> 2.95.3, lapack 3.1.1 and ATLAS 3.6.0.
> When installin numpy it seems to work but when I try to run test get
> error no test for numpy.
> 
> When I try to Install scipy only get error.
> 
> Any ideas on how to install would be appreciated.

Please join us on the scipy-user mailing list.

  http://www.scipy.org/Mailing_Lists

We will need a fair bit more information in order to help you. What OS are you
using? Exactly what did you do to try to test numpy? Please copy-and-paste the
exact error output. Similarly, for the scipy installation, please tell us
exactly what steps you took and copy and paste the output.

Thanks.

-- 
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

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do eval() and exec not accept a function definition? (like 'def foo: pass) ?

[Jean-Paul Calderone]

On Sun, 24 Jun 2007 11:17:40 +1000, Steven D'Aprano <[EMAIL PROTECTED]> wrote:
>On Sat, 23 Jun 2007 19:58:32 +, vasudevram wrote:
>
>>
>> Hi group,
>>
>> Question: Do eval() and exec not accept a function definition? (like
>> 'def foo: pass) ?
>
>eval() is a function, and it only evaluates EXPRESSIONS, not code blocks.

Actually, that's not exactly true:

>>> x = compile('def foo():\n\tprint "hi"\n', '', 'exec')
>>> l = {}
>>> eval(x, l)
>>> l['foo']()
hi
>>>

Jean-Paul
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The Modernization of Emacs

[[EMAIL PROTECTED]]

In article <[EMAIL PROTECTED]>, David Kastrup  <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] writes:

[ snip ]

> It appears that you still have not bothered educating yourself, years
> after you were pretty much universally derided in comp.text.tex for
> making a spectacle of your self-chosen ignorance.

Ah, I *thought* this discussion was starting to sound familiar.
"This is where I came in"?  

(Reverting to the original set of newsgroups on the purely selfish
grounds of not wanting to follow an additional newsgroup, comp.emacs,
in order to read any replies.)

-- 
B. L. Massingill
ObDisclaimer:  I don't speak for my employers; they return the favor.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Adding method to a class on the fly

[Steven D'Aprano]

On Sat, 23 Jun 2007 12:31:39 -0700, John Henry wrote:

> it works fine but PythonCard isn't calling this function when I
> clicked on the button.


I think you need to take this question onto a PythonCard list. I have no
idea how PythonCard decides which method to call.


-- 
Steven.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do eval() and exec not accept a function definition? (like 'def foo: pass) ?

[Steven D'Aprano]

On Sat, 23 Jun 2007 19:58:32 +, vasudevram wrote:

> 
> Hi group,
> 
> Question: Do eval() and exec not accept a function definition? (like
> 'def foo: pass) ?

eval() is a function, and it only evaluates EXPRESSIONS, not code blocks. 

eval("2+3") # works
eval("x - 4") # works, if x exists
eval("print x") # doesn't work

exec is a statement, and it executes entire code blocks, including
function definitions, but don't use it. Seriously.

ESPECIALLY don't use it if you are exec'ing data collected from untrusted
users, e.g. from a web form.


> I wrote a function to generate other functions using something like
> eval("def foo: ")
> but it gave a syntax error ("Invalid syntax") with caret pointing to
> the 'd' of the def keyword.

You don't need eval or exec to write a function that generates other
functions. What you need is the factory-function design pattern:


def factory(arg):
def func(x):
return x + arg
return func

And here it is in action:

>>> plus_one = factory(1)
>>> plus_two = factory(2)
>>> plus_one(5)
6
>>> plus_two(5)
7



-- 
Steven.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The Modernization of Emacs

[[EMAIL PROTECTED]]

In article <[EMAIL PROTECTED]>,
Twisted  <[EMAIL PROTECTED]> wrote:

[ snip ]

> I find these anecdotes liberally sprinkled into this thread frankly
> unbelievable. Either they are not using the same software I understand
> "emacs" to refer to, 

I think this may be the explanation.  The other people's anecdotes
seem pretty plausible to me in the context of emacs as it currently
exists.  You, however, appear to be talking about -- well, I'm not
quite sure, but perhaps emacs as it existed at some earlier point
in its history?  The first emacs I used (in 1980-something) didn't
have a GUI either.  But the ones currently available to me do.  

> or someone somewhere is simply lying. Or maybe
> there's a bunch of prodigies around and they all picked now to pipe
> up? We can't design software or any other tool to cater exclusively to
> a handful of Mozarts, though, unless there's no reason to believe
> anyone outside that small and exclusive club will ever have a use for
> it.

[ snip ]

-- 
B. L. Massingill
ObDisclaimer:  I don't speak for my employers; they return the favor.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The Modernization of Emacs: terminology buffer and keybinding

[Robert Uhl]

Bjorn Borud <[EMAIL PROTECTED]> writes:
>
> for Emacs it would be far more helpful if the Lisp-implementation was
> replaced with one that is more efficient and Common Lisp-like.
> (indeed several friends of mine would like to see Emacs done in Common
> Lisp, and I seem to have some memory of such a project existing
> somewhere).

Agreed.  Stallman got sidetracked by Scheme, which IMHO was a dead-end.
A Common Lisp emacs would be pretty sweet.  There's a Climacs project,
but they're just focused on providing an editor, not on providing a
full-fledged emacs.

-- 
Robert Uhl 
Cinder blocks: $100
Mortar: $30
A cask of amontillado: $300
The faint screams of a desperate PHB: priceless.  --O. Schwarz
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: is this a valid import sequence ?

[Alex Martelli]

Steven D'Aprano <[EMAIL PROTECTED]> wrote:

> On Sat, 23 Jun 2007 11:03:03 -0700, Scott David Daniels wrote:
> 
> > The global statement in Write_LCD_Data is completely unnecessary.  The
> > only time you need "global" is if you want to reassociate the global
> > name to another object (such as LCD = LCD + 1 or whatever).
> 
> That's technically true, but declaring it with global makes the code
> self-documenting and therefore easier to read.
> 
> It's never _wrong_ to use the global statement, even if it is strictly
> unnecessary for the Python compiler.

So, repeat that global statement ninetyseven times -- that's not
"wrong", either, in exactly the same sense in which it's not "wrong" to
have it once -- the Python compiler will not complain.  And by repeating
it over and over you make it less likely that a reader could miss it, so
it's even more "self-documenting" and "easier to read", right?

"Perfection is reached, not when there is no longer anything to
add, but when there is no longer anything to take away", as Antoine de
Saint-Exupery wrote.  Since that global statement is utterly useless
(it's impossible to read and understand any substantial amount of Python
code without realizing that accessing a variable not locally assigned
means you're accessing a global, so the "self-documenting" character
claimed for that redundancy is quite fallacious), it IS perfectly
suitable to take away, and so it's at least a serious imperfection.  It
violates Occam's Razor, by multiplying entities (specifically
statements) without necessity.  It's just about as bad as sticking a
semicolon at the end of every statement (to make it "self-documenting"
that the statement ends there), parentheses around the conditions in if
and while statements and the argument in return statements (to make it
"self-documenting" where those expressions start and end), and a few
other less common ways to waste pixels, screen space, readers' attention
spans, and everybody's time.  In other words, it's almost as bad as it
can get in Python without outright breakage of syntax or semantics
("almost" only because long comments that lie outright are worse:-).


Alex
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python's "only one way to do it" philosophy isn't good?

[Steven D'Aprano]

On Sat, 23 Jun 2007 14:56:35 -0400, Douglas Alan wrote:

>> How long did it take you to write the macros, and use them, compared
>> to running Pylint or Pychecker or equivalent?
> 
> An hour?  Who cares?  You write it once and then you have it for the
> rest of your life.  You put it in a widely available library, and then
> *every* programmer also has it for the rest of their lives.  The
> amortized cost: $0.00.  The value: priceless.

Really? Where do I download this macro? How do I find out about it? How
many Lisp programmers are using it now?

How does your glib response jib with your earlier claims that the
weakness of Lisp/Scheme is the lack of good libraries?

Googling for ' "Douglas Allen" download lisp OR scheme ' wasn't very
promising. If you have made your macros available to others, they don't
seem to be very well-known.

In fairness, the various Python lints/checkers aren't part of the standard
library either, but they are well-know "standards".



>> But if you really want declarations, you can have them.
> 
> import variables
> variables.declare(x=1, y=2.5, z=[1, 2, 4])
> variables.x = None
> variables.w = 0
>> Traceback (most recent call last):
>>   File "", line 1, in 
>>   File "variables.py", line 15, in __setattr__
>> raise self.DeclarationError("Variable '%s' not declared" % name)
>> variables.DeclarationError: Variable 'w' not declared
> 
> Thanks, but that's just too syntactically ugly and verbose for me to
> use.


"Syntactically ugly"? "Verbose"?

Compare yours with mine:

let x = 0
let y = 1
let z = 2
set x = 99 

(Looks like BASIC, circa 1979.)

variables.declare(x=0, y=1, z=2)
variables.x = 99

(Standard Python syntax.)

I don't think having two easily confused names, let and set, is an
advantage, but if you don't like the word "declare" you could change it to
"let", or change the name of the module to "set" (although that runs the
risk of confusing it with sets).

Because this uses perfectly stock-standard Python syntax, you could even
do this, so you type fewer characters:

v = variables
v.x = 99

and it would Just Work. 


> Not only that, but my fellow Python programmers would be sure to
> come and shoot me if I were to code that way.

*shrug* They'd shoot you if you used "let x = 0" too.


> One of the reasons that I want to use Python is because I like reading
> and writing code that is easy to read and looks good.  I don't want to
> bend it to my will at the expense of ugly looking code.

But the "ugly looking code" is stock-standard Python syntax.

module.function(keyword=value)
module.attribute = value

is precisely the standard Python syntax you describe as "easy to read and
looks good" one moment. I don't believe you that you find it "ugly looking
code" -- if you did, you wouldn't be using Python.


-- 
Steven.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The Modernization of Emacs: terminology buffer and keybinding

[[EMAIL PROTECTED]]

In article <[EMAIL PROTECTED]>,
Bjorn Borud  <[EMAIL PROTECTED]> wrote:
> [Giorgos Keramidas <[EMAIL PROTECTED]>]
> | 
> | Educating the user to avoid confusion in this and other cases of made
> | up, 'user-friendly' descriptions is not a good enough answer.
> 
> there are two types of "user friendly".  there's "user friendly" and
> then there is "beginner friendly" which is often mislabeled.  the
> latter is more important for applications which are to be used
> casually.  like utilities you only use once or twice per year -- those
> need to be "beginner friendly".

Maybe this is an okay point at which to mention one of my favorite
bits of commentary on this subject.  It's an interview with Leslie
Lamport (originator of LaTeX, among other things) in which he
talks about the needs of beginners versus the needs of experts,
and how the latter are often neglected:

http://research.microsoft.com/users/lamport/pubs/lamport-latex-interview.pdf

(Yes, he works (worked?  but this seems current) for Microsoft.
Astonishing.)

Asked whether whether LaTeX is hard to use, he replies "It's easy
to use -- if you're one of the 2% of the population who thinks
logically and can read an instruction manual.  [otherwise not]"

> for applications you are likely to use for prolonged periods of time
> (like programming, video editing, music production etc), it does not
> make sense to optimize for "beginner friendly".  at least not at the
> cost of making the application less "user friendly".
> 
> applications you spend a lot of time using are worth an investment in
> learning how to use them.  what creates friction in an application you
> know reasonably well is when common tasks are fiddly.  for instance,
> while menus are often good for casual use and lower the initial
> threshold for absolute beginners, depending heavily on menu navigation
> becomes too fiddly if you are performing a certain task 2-3 times per
> minute.  it is not _user_ friendly.

Sing it, brother.

(I'm a vim fan myself, but my thinking is that these days emacs
and vi(m) people should be banding together against a common enemy
rather than carrying on the fine old tradition of arguing with
each other.  We have in common a preference, maybe, for learning
one editor really well and using it for everything.)

-- 
B. L. Massingill
ObDisclaimer:  I don't speak for my employers; they return the favor.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The Modernization of Emacs: terminology buffer and keybinding

[Robert Uhl]

[EMAIL PROTECTED] writes:
>
> So now we're expected to go on a filesystem fishing expedition instead
> of just hit F1?

Interestingly enough, f1 _is_ bound to the help system in emacs.  So's
C-h.  So's the 'help' key.

-- 
Robert Uhl 
That's why I love VoIP.  You don't get people phoning up to complain that the
network is down.  --Peter Corlett
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The Modernization of Emacs: terminology buffer and keybinding

[Robert Uhl]

Twisted <[EMAIL PROTECTED]> writes:
>
> HOW IN THE BLOODY HELL IS IT SUPPOSED TO OCCUR TO SOMEONE TO ENTER
> THEM, GIVEN THAT THEY HAVE TO DO SO TO REACH THE HELP THAT WOULD TELL
> THEM THOSE ARE THE KEYS TO REACH THE HELP?!

Because WHEN YOU START EMACS IT DISPLAYS A MESSAGE TELLING YOU HOW TO
GET TO THE TUTORIAL.  ONCE YOU'VE FOLLOWED THE TUTORIAL YOU KNOW
EVERYTHING YOU NEED TO KNOW.

If you had ever actually run emacs you'd know this.

> Of course, Notepad is so easy to use it doesn't even need help,
> despite which it's readily available. In case you forgot the bog-
> standard (and therefore it IS self-evident) "F1" there's even a "Help"
> menu in plain view as soon as you open a Notepad.

Any modern emacs comes with F1 configured to start the help system too.
Wow!

> [remainder snipped, apparently describing some piece of software that
> presents you automatically with an emacs tutorial if you start emacs
> while it's running. I've seen emacs a few times in my day but never
> whatever unnamed piece of software is being referred to here...

The message about the tutorial is displayed by a piece of software
called 'emacs.'  It's the piece of software we've talking about this
entire time.  It does this every time you start it.  Every single time.
Without fail.  Of course, if you somehow missed it, you could also go to
the menu titled, helpfully, 'Help'; the first item therein is 'Emacs
tutorial'; the second is 'Emacs tutorial (choose language).'

If you had ever actually run emacs you'd know this.

Do you think that Mercedes are awful cars because their engines don't
start when you turn the key in the ignition?  Do you think homemade
burgers are disgusting because cheese doesn't melt on them?

-- 
Robert Uhl 
Using SWITCHAR in MS-DOS 2.0 was a kludge on top of a kludge, back in
the days before Microsoft kludge-stacking turned the OS into a game of
Jenga played with sweating dynamite sticks.--Steve VanDevender
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The Modernization of Emacs: terminology buffer and keybinding

[Robert Uhl]

Twisted <[EMAIL PROTECTED]> writes:
>
> For an example of the latter, consider opening a file. Can't remember
> the exact spelling and capitalization of the file name? Sorry, bud,
> you're SOL. Go find it in some other app and memorize the name, then
> return to emacs.

Once again I am forced to wonder if you have _ever_ actually used
emacs.  find-file has tab completion: hit tab without anything typed, and
it displays _everything_ in the directory; type a few characters to
narrow it down; hit tab to complete the filename and be done with it.

Or of course you could use directory mode, which enables you to navigate
around a directory tree, performing actions on files (including editing
them).

Then of course there's ido.el, which is even better: type a few
characters from anywhere in the name, and it displays files matching
those characters.

You've never actually run emacs, have you?

-- 
Robert Uhl 
The power of Satan is as nothing before the might of the Lord, so don't
go getting any ideas. --I Abyssinians 20:20
-- 
http://mail.python.org/mailman/listinfo/python-list

how to query/test the state of a qt widget?

[raacampbell]

Hi,

I'm writing a simple Python/Qt3 application and I am trying to write
some code in which the user presses a button and the program performs
action A or B depending upon the state of a pair of radio buttons. I
would therefore like Python to read the state of the buttons. I was
expecting this to be straightforward but I've not been able to work
out how to do it and searching on Google hasn't helped. Surely there's
a one-liner that will do what I want? It seems like an every-day sort
of problem. I'm after something like:

if self.polPlotRadioButton.enabled==1: print "BLAH"

I've found squish from www.froglogic.com but that seems over the top.
Possibly pythonqt.sourceforge.net has something that will solve my
problem but that wants Qt4 and at the moment I'm making heavy use of
matplotlib widgets and I've not worked out how to get them to
incorporate into a Qt4 app so I'm stuck with Qt3.

Anyone know the answer?

Thanks in advance!

-- 
http://mail.python.org/mailman/listinfo/python-list

Leo 4.4.3 beta 3 released

[Edward K Ream]

Leo 4.4.3 beta 3 is available at:
http://sourceforge.net/project/showfiles.php?group_id=3458&package_id=29106

This release fixes all known bugs and adds several new features.

Leo is a text editor, data organizer, project manager and much more. See:
http://webpages.charter.net/edreamleo/intro.html

The highlights of Leo 4.4.3:

- Added support for chapters in Leo's core.
- Added support for zipped .leo files.
- Added a leoBridge module that allows full access to all of Leo's
capabilities
  from programs running outside of Leo.
- Removed all gui-dependent code from Leo's core.
- Better support for the winpdb debugger.
- Added support for @enabled-plugins nodes in settings files.
- Added support for @open-with nodes in settings files.
- Added support for @bool write_strips_blank_lines setting.
- The__wx_gui plugin is now functional.
- Leo can use aspell on Linux when using Python 2.5 or later.
- @test nodes can now be run from any .leo file.
- Many minor improvements, new settings, commands and bug fixes.

Links:
--
Leo:  http://webpages.charter.net/edreamleo/front.html
Home: http://sourceforge.net/projects/leo/
Download: http://sourceforge.net/project/showfiles.php?group_id=3458
CVS:  http://leo.tigris.org/source/browse/leo/
Quotes:   http://webpages.charter.net/edreamleo/testimonials.html

Edward K. Ream   email:  [EMAIL PROTECTED]
Leo: http://webpages.charter.net/edreamleo/front.html




-- 
http://mail.python.org/mailman/listinfo/python-list

Re: urllib interpretation of URL with ".."

[John Nagle]

Martin v. Löwis wrote:
> John Nagle schrieb:
> 
>>Here's a URL, found in a link, which gives us trouble
>>when we try to follow the link:
>>
>>http://sportsbra.co.uk/../acatalog/shop.html
>>
>>Browsers immediately turn this into
>>
>>http://sportsbra.co.uk/acatalog/shop.html
>>
>>and go from there, but urllib tries to open it explicitly, which
>>results in an HTTP error 400.
>>
>>Is "urllib" wrong?
> 
> 
> I can't see how. HTTP 1.1 says that the parameter to the GET
> request should be an abs_path; RFC 2396 says that
> /../acatalog/shop.html is indeed an abs_path, as .. is a valid
> segment. That RFC also has a section on relative identifiers
> and normalization; it defines what .. means *in a relative path*.
> 
> Section 4 is explicit about .. in absolute URIs:
> # The syntax for relative URI is a shortened form of that for absolute
> # URI, where some prefix of the URI is missing and certain path
> # components ("." and "..") have a special meaning when, and only when,
> # interpreting a relative path.
> 
> Notice the "and only when": the browsers who modify above
> URL before sending it seem to be in clear violation of
> RFC 2396.
> 
> Regards,
> Martin

I think you're right.  The problem is that there is apparently a de-facto
standard in browsers that any number of "../" sequences at the beginning of
the path part of a URL have no effect.  Even Google seems to use that
interpretation; not only does it follow that link, it lists it in Google
without the "..".

John Nagle
-- 
http://mail.python.org/mailman/listinfo/python-list

trouble installing numpy 1.0.2 and scipy.0.5.2

[1960_j]

I have tried to install numpy and scipy on python 5.2. Using gcc
2.95.3, lapack 3.1.1 and ATLAS 3.6.0.
When installin numpy it seems to work but when I try to run test get
error no test for numpy.

When I try to Install scipy only get error.

Any ideas on how to install would be appreciated.

Thanks

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do eval() and exec not accept a function definition? (like 'def foo: pass) ?

[Scott David Daniels]

vasudevram wrote:
> Hi group,
> 
> Question: Do eval() and exec not accept a function definition? (like
> 'def foo: pass) ?

def is the first keyword in a _statement_, not an expression.

exec executes statements, eval evaluates expressions.

try this:

 exec "def foolish(x):\ny= x * 2\nprint x, y"
 foolish(2.4)


-- 
--Scott David Daniels
[EMAIL PROTECTED]
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: database design help

[Jacek Trzmiel]

Hi,

Brian Blais wrote:
> I am trying to design a system for people to submit a series of documents to a
> project.  I want users to have the ability to submit updates to any 
> documents, so
> that there should be a history (or sequence) for each document.
[...]
> project1:
>document 1, document 1a, document 1b
>document 2
>document 3, document 3a
> 
> project 2:
>document 4, document 4a
> 
> etc...
> 
> I want to be able to query the history of any single document, so I can get a 
> list of
> document 1, 1a, and 1b.  or document 3  and 3a, etc...
> 
> So I have something like this (omitting a few lines, for clarity) to set up 
> the
> record structure:
> 
>  users.create(('name',str),
>  ('email',str))
> 
>  project.create( ('description',str),
>  ('label',str),
>  ('creation_date',date),
>  ('submitter',users))
> 
>  documents.create(('filename',str),
>  ('submit',date),
>  ('submitter',users),
>  ('type',str),
>  ('project',project))

Split document into separate document and revision concept, i.e. 
something like this:

  documents.create(('type',str),
  ('project',project))

  revisions.create(('filename',str),
  ('submit',date),
  ('submitter',users),
  ('document',documents))

(I'm not sure how you will use 'type', so maybe it should belong to 
revision.)

Best regards,
Jacek.

-- 
http://mail.python.org/mailman/listinfo/python-list

database design help

[Brian Blais]

Hello,

I am trying to design a system for people to submit a series of documents to a
project.  I want users to have the ability to submit updates to any documents, 
so
that there should be a history (or sequence) for each document.  I think in 
terms of
python data structures, so the relational database organization is not all that 
clear
to me (so I am trying to learn it!).  I am using buzhug, but the concept should 
be
the same in any rdb.

So my conceptual structure would look something like:

project1:
   document 1, document 1a, document 1b
   document 2
   document 3, document 3a

project 2:
   document 4, document 4a

etc...

I want to be able to query the history of any single document, so I can get a 
list of
document 1, 1a, and 1b.  or document 3  and 3a, etc...

So I have something like this (omitting a few lines, for clarity) to set up the
record structure:

 users.create(('name',str),
 ('email',str))

 project.create( ('description',str),
 ('label',str),
 ('creation_date',date),
 ('submitter',users))

 documents.create(('filename',str),
 ('submit',date),
 ('submitter',users),
 ('type',str),
 ('project',project))

with this structure, I can get a project with a series of documents, but each
document doesn't have a history.   My first thought (with Python data 
structures) is
to use a list, but that's not an rdb concept.  Do I make something like:

document_sequences.create(('name',str),('project',project))

and then change documents so that it contains not only a project field, but a
document_sequence field?   Am I thinking about this correctly?

Is there a resource I can read that goes through any of this?


thanks,


Brian Blais




-- 
-

  [EMAIL PROTECTED]
  http://web.bryant.edu/~bblais

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Portable general timestamp format, not 2038-limited

[rossum]

On Sat, 23 Jun 2007 13:37:14 -0700, James Harris
<[EMAIL PROTECTED]> wrote:

>On 22 Jun, 23:49, Roger Miller <[EMAIL PROTECTED]> wrote:
>...
>> My rule of thumb in situations like this is "When in doubt store it as
>> text".  The one format I am pretty sure we will still be able to deal
>> with in 2039.
>
>Interesting. I hadn't thought about using text. It would add to the
>storage a bit as each record is otherwise quite short. But this sounds
>like a good option and may help - at least while debugging - to see
>the raw date and time as digits. I will consider using this, perhaps
>as mmddhhmmssttt.
You might prefer to use one of the ISO 8601 formats:
mmddThhmmssttt or -mm-ddThh:mm:ss.ttt

http://www.cl.cam.ac.uk/~mgk25/iso-time.html

rossum

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python changing keywords name

[James Stroud]

[EMAIL PROTECTED] wrote:
> Hello AGAIN,
> 
> I  on working on windows and Python 2.4. Where can I find and CHANGE
> python
> grammar.  ( I just want to change the keywords )
> 
>   PLEASE HELP ME
> SOMEBODY!!
>  
> THANKS!
> 

1. Download the source to python
2. Unpack the source
3. Change to the "Grammar" directory
5. Edit the "Grammar" file appropriately
6. Compile python
7. Your interpreter now has new keywords
8. Use at your own risk.

For example, I changed a print statent in this file from

print_stmt: 'print' ( [ test (',' test)* [','] ] |
   '>>' test [ (',' test)+ [','] ] )

to

print_stmt: 'splodnik' ( [ test (',' test)* [','] ] |
   '>>' test [ (',' test)+ [','] ] )

And here are the results:

   Python 2.5 (r25:51908, Jun 23 2007, 14:42:05)
   [GCC 4.1.1] on linux2
   Type "help", "copyright", "credits" or "license" for more information.
   >>> splodnik 'This is a splodnik statement.'
   This is a splodnik statement.

You will also want to change every instance of the word "print" in every 
.py file to "splodnik" in the pythonsource before building, so that you 
won't break your standard lib. Also, no one else on the planet will be 
using this version of python, so you will not be able to use any one 
else's python code unless you replace keywords in their python source.

Now that you know how to do this, please don't ask again.

James
-- 
http://mail.python.org/mailman/listinfo/python-list

Strange Thread Issue

[Robert Rawlins - Think Blue]

Hello Guys,

 

I'm having an issue with a thread which I've not come across before and it
has be baffled. The thread doesn't really do a lot, it simple contains a
popen command to run something from cmd, now then i trigger the thread form
my main application using the .start() method nothing happens, the command
prompt program isn't triggered, yet as soon as a ctrl+c to close my
application the thread then seems to kick into life and work.

 

Any ideas what is causing this?

 

Thanks guys,

 

Rob

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do eval() and exec not accept a function definition? (like 'def foo: pass) ?

[vasudevram]

On Jun 24, 1:20 am, Eduardo Dobay <[EMAIL PROTECTED]> wrote:
> Hey,
>
> I think you could use lambda functions for that matter (Ever heard of
> them?). You could write something like:
>
> def generate_html_tag_function(tag_name, start_or_end):
>start_or_end.lower()
>assert(start_or_end in ('start', 'end'))
>if start_or_end == 'start':
>function = lambda: '<' + tag_name + '>'
>else:
>function = lambda: ''
>return function
>
> Then you would create the functions using the same code you had
> written before:
>
> start_html = generate_html_tag_function('html', 'start')
> start_body = generate_html_tag_function('body', 'start')
> end_html = generate_html_tag_function('html', 'end')
> end_body = generate_html_tag_function('body', 'end')
>
> That seems to do what you want.
>
> Eduardo

Thanks to all the repliers.

@Eduardo: Yep, I had heard of lambdas, but didn't think to use them
here.
Will try this out - thanks!

- Vasudev


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Collections of non-arbitrary objects ?

[Paddy]

On Jun 23, 6:45 pm, walterbyrd <[EMAIL PROTECTED]> wrote:
> On Jun 22, 11:43 pm, Ben Finney <[EMAIL PROTECTED]>
> wrote:
>
> > Can you help us understand, by showing a use case that would in your
> > estimation be improved by the feature you're describing?
>
> Suppose you are sequentially processing a list with a routine that
> expects every item to be of a certain type. Something in the list that
> doesn't conform to the type could give you unexpected results, maybe
> crash your application.
>
> In python, as far as I know, there is nothing built into the language
> to keep any type of item from being included in a list - or any such
> structure. To me, that seems like a potentially vulnerability.
> Especially since variables in python do not have to be explicitly
> assigned - another variable that points to the same thing, could
> change the data that a variable points to.

Reminds me a bit of that (awful) sketch:
  Patient: Doctor doctor it hurts if I do that.
  Doctor:  Well don't do that then.

The data for the list should have been checked when it entered
your program. It is up to you to then only stuff the list with
data expected by the routine. If you don't then Python will most
likely throw a runtime exception, but it is up to you to trust
your co-workers on the project.

- Paddy

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python changing keywords name

[Michael Hoffman]

[EMAIL PROTECTED] wrote:
> Hello AGAIN,
> 
> I  on working on windows and Python 2.4. Where can I find and CHANGE
> python
> grammar.  ( I just want to change the keywords )
> 
>   PLEASE HELP ME
> SOMEBODY!!
>  
> THANKS!

This is the third time you have posted this today. Please stop.

Also, you might want to moderate the tone of your messages. Some people 
might find a string of all caps and exclamation marks obnoxious. I think 
it is less likely to get you help.

You may find this guide helpful 
.
-- 
Michael Hoffman
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Portable general timestamp format, not 2038-limited

[James Harris]

On 22 Jun, 23:49, Roger Miller <[EMAIL PROTECTED]> wrote:
...
> My rule of thumb in situations like this is "When in doubt store it as
> text".  The one format I am pretty sure we will still be able to deal
> with in 2039.

Interesting. I hadn't thought about using text. It would add to the
storage a bit as each record is otherwise quite short. But this sounds
like a good option and may help - at least while debugging - to see
the raw date and time as digits. I will consider using this, perhaps
as mmddhhmmssttt.

-- 
http://mail.python.org/mailman/listinfo/python-list

Python changing keywords name

[vedrandekovic]

Hello AGAIN,

I  on working on windows and Python 2.4. Where can I find and CHANGE
python
grammar.  ( I just want to change the keywords )

  PLEASE HELP ME
SOMEBODY!!
 
THANKS!

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do eval() and exec not accept a function definition? (like 'def foo: pass) ?

[Eduardo Dobay]

Hey,

I think you could use lambda functions for that matter (Ever heard of
them?). You could write something like:

def generate_html_tag_function(tag_name, start_or_end):
   start_or_end.lower()
   assert(start_or_end in ('start', 'end'))
   if start_or_end == 'start':
   function = lambda: '<' + tag_name + '>'
   else:
   function = lambda: ''
   return function

Then you would create the functions using the same code you had
written before:

start_html = generate_html_tag_function('html', 'start')
start_body = generate_html_tag_function('body', 'start')
end_html = generate_html_tag_function('html', 'end')
end_body = generate_html_tag_function('body', 'end')


That seems to do what you want.

Eduardo

-- 
http://mail.python.org/mailman/listinfo/python-list

pydoc with METH_VARGS

[Stuart]

With my Python extension module all the function definitions are with
METH_VARGS. The result being that pydoc, just puts "(...)" for the
argument list. Can I hand edit this to put the specific variable names
I want? With optional arguments in brackets or something?

Thanks.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do eval() and exec not accept a function definition? (like 'def foo: pass) ?

[MC]

Hi!

Try with change all '\r\n'  by  '\n'

-- 
@-salutations

Michel Claveau


-- 
http://mail.python.org/mailman/listinfo/python-list

Do eval() and exec not accept a function definition? (like 'def foo: pass) ?

[vasudevram]

Hi group,

Question: Do eval() and exec not accept a function definition? (like
'def foo: pass) ?

I wrote a function to generate other functions using something like
eval("def foo: ")
but it gave a syntax error ("Invalid syntax") with caret pointing to
the 'd' of the def keyword.

Details (sorry for the slight long post but thought it better to give
more details in this case - wording is pretty clear, though, I think,
so shouldn't take long to read):

While working on a personal project for creating a server for a
certain protocol (which I may make into an open source project later
if it turns out to be any good), I wrote some simple functions to
generate HTML start and end tags like , , , , etc. - just to simplify/shorten my code a little. (I'm aware
that there are HTML generation libraries out there, but don't think I
need the overhead, since my needs are very simple, and anyway wanted
to roll my own just for fun. For a bigger/more serious project I would
probably use the existing libraries after doing a proper evaluation).
So, this question is not about HTML generation but about Python's
eval() function and exec statement.

Started by writing functions like this:

def start_html():
return '\r\n'

def end_html():
return '\r\n'

... and similarly for the 'body', 'p', etc. HTML tags.
(I used '\r\n' at the end because the server will send this output to
the browser over HTTP, so that my code conforms to Internet protocols,
and also so that while debugging, my output would have only one tag
per line, for readability. Not showing the '\r\n in the rest of the
code below)

Then I realized that all these functions are very similar - only
differ in the return value of the tag.
So (being interested in metaprogramming of late), thought of writing a
function that would generate these functions, when passed the
appropriate tag name argument.

[ Digression: I could of course have used another simple approach such
as this:

def start_tag(tag_name):
return '<' + tag_name + '>'

# called like this:
# print start_tag('html')
# print start_tag('body')

# and

def end_tag(tag_name):
return ''

# called like this:
# print end_tag('body')
# print end_tag('html')

# and called similarly for the other HTML tags.

While the above would work, it still would involve a bit more typing
than I'd like to do, since I'[d have to pass in the tag name as an
argument each time. I'd prefer having functions that I could call like
this:

print start_html()
# which would print ""
print start_body()
# which would print ""

# and so on ... just to make the code a little shorter and more
readable.

End of Digression]

So, I wrote this code generation function:

# 
import string
def generate_html_tag_function(tag_name, start_or_end):
start_or_end.lower()
assert(start_or_end in ('start', 'end'))
if start_or_end == 'start':
func_def = "def start_" + tag_name + ":()\n" + \
"return '<' + tag_name + '>'
else:
func_def = "def end_" + tag_name + ":()\n" + \
"return ''
function = eval(func_def)
return function

# meant to be called like this:

start_html = generate_html_tag_function('html', 'start')
start_body = generate_html_tag_function('body', 'start')
end_html = generate_html_tag_function('html', 'end')
end_body = generate_html_tag_function('body', 'end')

# and the generated functions would be called like this:

print start_html()
print start_body()
print end_body()
print end_html()
# 

# giving the output:





But when I ran the above code (between the lines marked # and
#), I got an error "Invalid syntax" with the caret pointing at the
"d" of the def statement.
I had used eval a few times earlier for somewhat similar uses, so
thought this would work.
I then looked up the Python Language Reference help, and saw that eval
is used to evaluate Python expressions, not statements, and def is a
statement. So looked up the exec statement of Python and saw that its
syntax seemed to allow what I wanted.
So replaced the line containing eval in the above with:
exec(func_def)
But that too gave the same error (I think so - I tried this yesterday
and forgot to save the error messages, sorry about that, so can't be
sure, but do think this was the case - if not, I'll save the exact
code and output/errors later and repost here - not at my PC right
now.)

Thanks for any suggestions,

Vasudev Ram
Bize site: http://www.dancingbison.com
PDF creation / conversion toolkit: http://sourceforge.net/projects/xtopdf
Blog on software innovation: http://jugad.livejournal.com

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Adding method to a class on the fly

[John Henry]

On Jun 23, 10:56 am, Steven D'Aprano
<[EMAIL PROTECTED]> wrote:
> On Sat, 23 Jun 2007 09:06:36 -0700, John Henry wrote:
>
> >> > But then how do I create the on_Button1_mouseClick function?
>
> >> That depends on what it is supposed to do, but in general you want a
> >> factory function -- a function that returns functions. Here's a simple
> >> example:
>
> > 
>
> > Steven,
>
> > May be I didn't explain it clearly: the PythonCard package expects to
> > see a function by the name of on_Button1_mouseClick.  I don't do
> > anything to register the callback function.  The package assumes that
> > there is a function by that name whenever I create a button named
> > Button1.  So, if I don't use exec, how can I create a function by that
> > exact name?
>
> def mouseclick_factory(name):
> def function(self, event):
> print "You clicked '%s'." % name
> function.name = "on_%s_mouseClick" % name
> return function
>
> class Parrot:
> def __init__(self, name):
> function = mouseclick_factory(name) # as before
> method = new.instancemethod(function, self, self.__class__)
> setattr(self, function.name, method)
>
> And here it is in action:
>
> >>> p = Parrot("Button1")
> >>> p.on_Button1_mouseClick("event")
>
> You clicked 'Button1'.
>
> --
> Steven.


Wouldn't it be nice if it works right away?  :=)

I tried the above method and this is what I have:

#!/usr/bin/python

"""
__version__ = "$Revision: 1.6 $"
__date__ = "$Date: 2004/08/17 19:46:06 $"
"""

import new

from PythonCard import model

rsrc = {'application':{'type':'Application',
  'name':'Minimal',
'backgrounds': [
{'type':'Background',
  'name':'bgMin',
  'title':'Minimal PythonCard Application',
  'size':(200, 300),
 'components': [

] # end components
} # end background
] # end backgrounds
} }

def mouseclick_factory(parent, name):
id_num=int(name[-1:])
parent.components[name] = {'type':'Button',
 'name':name,
 'label':name,
 'position':(5, 5+id_num*30),
 'text':name}
def function(self, event):
print "You clicked '%s'." % name
function.name = "on_%s_mouseClick" % name
return function

class Minimal(model.Background):
def on_initialize(self, event):
self.components['field1'] =
{'type':'TextField','name':'field1','position':(5, 5),'size':(150,
-1),'text':'Hello PythonCard'}
name = "Button1"
function = mouseclick_factory(self, name) # as before
method = new.instancemethod(function, self, self.__class__)
setattr(self, function.name, method)

if __name__ == '__main__':
app = model.Application(Minimal, None, rsrc)
app.MainLoop()

When I click on the button, nothing happens.  However, if I call the
function directly (like right after the setattr line:

self.on_Button1_mouseClick(event)

it works fine but PythonCard isn't calling this function when I
clicked on the button.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python's "only one way to do it" philosophy isn't good?

[Douglas Alan]

Steven D'Aprano <[EMAIL PROTECTED]> writes:

> But if you really want declarations, you can have them.
>
 import variables
 variables.declare(x=1, y=2.5, z=[1, 2, 4])
 variables.x = None
 variables.w = 0
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "variables.py", line 15, in __setattr__
> raise self.DeclarationError("Variable '%s' not declared" % name)
> variables.DeclarationError: Variable 'w' not declared

Oh, I forgot to mention that I work a lot on preexisting code, which I
am surely not going to go to all the effort to retype and then retest.
With the "let" and "set" macros I can use "set" without a matching
"let".  "set" just checks to make sure that a variable already exists
before assigning to it, and "let" just prevents against
double-declarations.  They can be used independently or together.
With your "variables" class, they have to be used together.

|>oug
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Collections of non-arbitrary objects ?

[Marc 'BlackJack' Rintsch]

In <[EMAIL PROTECTED]>, walterbyrd
wrote:

> On Jun 22, 11:43 pm, Ben Finney <[EMAIL PROTECTED]>
> wrote:
> 
>> Can you help us understand, by showing a use case that would in your
>> estimation be improved by the feature you're describing?
>>
> 
> Suppose you are sequentially processing a list with a routine that
> expects every item to be of a certain type. Something in the list that
> doesn't conform to the type could give you unexpected results, maybe
> crash your application.

It raises an exception.  What want you an "typed list" to do when a wrong
object is put into it?  Raising an exception?  So all you change is the
point in time when the exception is raised.

> In python, as far as I know, there is nothing built into the language
> to keep any type of item from being included in a list - or any such
> structure. To me, that seems like a potentially vulnerability.
> Especially since variables in python do not have to be explicitly
> assigned - another variable that points to the same thing, could
> change the data that a variable points to.

But this doesn't really change with a "typed list".  It's easy to take
an object and completely replace all its attributes so it behaves very
different.

Ciao,
Marc 'BlackJack' Rintsch
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: is this a valid import sequence ?

[Stef Mientki]

Steven D'Aprano wrote:
> On Sat, 23 Jun 2007 11:03:03 -0700, Scott David Daniels wrote:
> 
>> The global statement in Write_LCD_Data is completely unnecessary.  The
>> only time you need "global" is if you want to reassociate the global
>> name to another object (such as LCD = LCD + 1 or whatever).
> 
> That's technically true, but declaring it with global makes the code
> self-documenting and therefore easier to read.
> 
> It's never _wrong_ to use the global statement, even if it is strictly
> unnecessary for the Python compiler.
> 
> 
Although I'm not an expert,
I guess you're both right.

thanks and cheers,
Stef Mientki
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Collections of non-arbitrary objects ?

[7stud]

On Jun 23, 11:45 am, walterbyrd <[EMAIL PROTECTED]> wrote:
> On Jun 22, 11:43 pm, Ben Finney <[EMAIL PROTECTED]>
> wrote:
>
> > Can you help us understand, by showing a use case that would in your
> > estimation be improved by the feature you're describing?
>
> Suppose you are sequentially processing a list with a routine that
> expects every item to be of a certain type. Something in the list that
> doesn't conform to the type could give you unexpected results, maybe
> crash your application.
>

if hasattr(elmt, some_func):
   elmt.some_func()



-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Adding method to a class on the fly

[John Henry]

On Jun 23, 10:56 am, Steven D'Aprano
<[EMAIL PROTECTED]> wrote:
> On Sat, 23 Jun 2007 09:06:36 -0700, John Henry wrote:
>
> >> > But then how do I create the on_Button1_mouseClick function?
>
> >> That depends on what it is supposed to do, but in general you want a
> >> factory function -- a function that returns functions. Here's a simple
> >> example:
>
> > 
>
> > Steven,
>
> > May be I didn't explain it clearly: the PythonCard package expects to
> > see a function by the name of on_Button1_mouseClick.  I don't do
> > anything to register the callback function.  The package assumes that
> > there is a function by that name whenever I create a button named
> > Button1.  So, if I don't use exec, how can I create a function by that
> > exact name?
>
> def mouseclick_factory(name):
> def function(self, event):
> print "You clicked '%s'." % name
> function.name = "on_%s_mouseClick" % name
> return function
>
> class Parrot:
> def __init__(self, name):
> function = mouseclick_factory(name) # as before
> method = new.instancemethod(function, self, self.__class__)
> setattr(self, function.name, method)
>
> And here it is in action:
>
> >>> p = Parrot("Button1")
> >>> p.on_Button1_mouseClick("event")
>
> You clicked 'Button1'.
>
> --
> Steven.


Thank you.  I think that should work perfectly.  By using
mouseclick_factory, you've avoided using exec and result in a much
more readable code.  The part I really didn't know how is the use of
the new.instancemethod followed by setattr.  I'll go try it now.

Thanks again.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python's "only one way to do it" philosophy isn't good?

[Douglas Alan]

Steven D'Aprano <[EMAIL PROTECTED]> writes:

>> So one use for macros would be so that I can define "let" and "set"
>> statements so that I might code like this:
>> 
>>  let longVariableName = 0
>>  set longVarableName = foo(longVariableName)
>> 
>> Then if longVarableName didn't already exist, an error would be
>> raised, rather than a new variable being automatically created for me.

> So "let" is the initial declaration, and "set" modifies the existing
> variable? 

Yes.

> What happens is you declare a variable twice?

The same thing that would happen in Perl or any other language that
supports this type of variable declaration and setting: it would raise
an error.

The big debate you get next, is then whether you should be allowed to
shadow variables in nested scopes with new variables of the same
name.  Given that Python already allows this, my guess is that the
answer should be yes.

> How long did it take you to write the macros, and use them, compared
> to running Pylint or Pychecker or equivalent?

An hour?  Who cares?  You write it once and then you have it for the
rest of your life.  You put it in a widely available library, and then
*every* programmer also has it for the rest of their lives.  The
amortized cost: $0.00.  The value: priceless.

> But if you really want declarations, you can have them.

 import variables
 variables.declare(x=1, y=2.5, z=[1, 2, 4])
 variables.x = None
 variables.w = 0
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "variables.py", line 15, in __setattr__
> raise self.DeclarationError("Variable '%s' not declared" % name)
> variables.DeclarationError: Variable 'w' not declared

Thanks, but that's just too syntactically ugly and verbose for me to
use.  Not only that, but my fellow Python programmers would be sure to
come and shoot me if I were to code that way.

One of the reasons that I want to use Python is because I like reading
and writing code that is easy to read and looks good.  I don't want to
bend it to my will at the expense of ugly looking code.

|>oug
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: C API: passing by reference

[[EMAIL PROTECTED]]

Thanks for that clarification Martin. When I googled it before, the
first page I read said "Python passes all arguments using 'pass by
reference'." However, after seeing your reply and further searching I
see that this is not true.

I have a python function insertEdge which takes to 2-tuples of
(faceid,vertexid) and returns the edgeid. But upon execution of the
function the two vertexid's end up sharing the same faceid. So right
now my solution is just to also return the two new (faceid,vertexid).
These will both have the same vertexid as before, but have a different
faceid then before (sharing the same faceid).

Here for example is a script to create a triangle:

  v1 = createVertex((0,0,0))
  v2 = createVertex((1,0,0))
  e1,v1,v2 = insertEdge(v1,v2)
  v3 = createVertex((0,1,0))
  e2,v2,v3 = insertEdge(v2,v3)
  e3,v3,v1 = insertEdge(v3,v1)

Here is the C++ code:

static PyObject *
dlfl_insert_edge(PyObject *self, PyObject *args)
{
  uint faceId1;
  int vertId1;
  uint faceId2;
  int vertId2;
  int edgeId = -1;

  if( !PyArg_ParseTuple(args, "(ii)(ii)", &faceId1, &vertId1,
&faceId2, &vertId2) )
return NULL;

  if( currObj ) {
edgeId = DLFL::insertEdge( currObj, faceId1, vertId1, faceId2,
vertId2 );
currObj->clearSelected( );
  }

  return Py_BuildValue("i,(ii)(ii)", edgeId, faceId1, vertId1,
faceId2, vertId2 );
}

This works, but...
Any suggestions if there is a cleaner way?

Thanks!

On Jun 23, 1:31 pm, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] schrieb:
>
> > I'm writing my own python extension module with the C API. In python
> > all functions pass arguments by reference
>
> Can you please show an example what you mean by that? There is no
> "pass-by-reference" in Python: a function can not normally modify
> the variable in the caller.
>
> When you show what precisely you want to achieve, it should be easy
> to say how to do that in C.
>
> Regards,
> Martin

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: C API: passing by reference

[Carsten Haese]

On Sat, 2007-06-23 at 18:25 +, [EMAIL PROTECTED] wrote:
> I'm writing my own python extension module with the C API. In python
> all functions pass arguments by reference,

"Pass by reference", while correct from a certain standpoint, is to be
taken with a large grain of salt. It is correct in so far as the value
is not copied. It is incorrect in so far as, in general, you may not be
able to modify the object that's passed.

The reference you receive can only be used to call methods of the
referenced object, if it has any, or manipulate attributes of the
object, if it has any. It can not be used to replace the object with
another object.

>  but how can I make use of
> this in C? Right now, I am using:

You can't.

> PyArg_ParseTuple(args, "(ii)(ii)", &faceId1, &vertId1, &faceId2,
> &vertId2)
> 
> I want the to change the faceId's in my function. From what I've seen
> you can't do this safely with PyArg_ParseTuple.

Not with PyArg_ParseTuple, not with anything. Your function receives a
reference to an int object. Since int objects are immutable, you can't
replace the number that's in the int object.

> Do I have another option?

Return the value instead of trying to produce side-effects in the
caller's name space.

HTH,

-- 
Carsten Haese
http://informixdb.sourceforge.net


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: C API: passing by reference

[Martin v. Löwis]

[EMAIL PROTECTED] schrieb:
> I'm writing my own python extension module with the C API. In python
> all functions pass arguments by reference

Can you please show an example what you mean by that? There is no
"pass-by-reference" in Python: a function can not normally modify
the variable in the caller.

When you show what precisely you want to achieve, it should be easy
to say how to do that in C.

Regards,
Martin
-- 
http://mail.python.org/mailman/listinfo/python-list

C API: passing by reference

[[EMAIL PROTECTED]]

I'm writing my own python extension module with the C API. In python
all functions pass arguments by reference, but how can I make use of
this in C? Right now, I am using:

PyArg_ParseTuple(args, "(ii)(ii)", &faceId1, &vertId1, &faceId2,
&vertId2)

I want the to change the faceId's in my function. From what I've seen
you can't do this safely with PyArg_ParseTuple.

Do I have another option?

Otherwise, I just have to return an extra variable. But it would be
much much nicer to just have the faceId's change if the arguments
passed were variables.

Thanks!

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: is this a valid import sequence ?

[Steven D'Aprano]

On Sat, 23 Jun 2007 11:03:03 -0700, Scott David Daniels wrote:

> The global statement in Write_LCD_Data is completely unnecessary.  The
> only time you need "global" is if you want to reassociate the global
> name to another object (such as LCD = LCD + 1 or whatever).

That's technically true, but declaring it with global makes the code
self-documenting and therefore easier to read.

It's never _wrong_ to use the global statement, even if it is strictly
unnecessary for the Python compiler.


-- 
Steven.

-- 
http://mail.python.org/mailman/listinfo/python-list

bicycle repair man help

[Rustom Mody]

Does someone know that when using bicycle repair man to refactor python code
what exactly extract local variable means?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python's "only one way to do it" philosophy isn't good?

[Steven D'Aprano]

On Sat, 23 Jun 2007 12:39:51 -0400, Douglas Alan wrote:

> One of the things that annoys me when coding in Python (and this is a
> flaw that even lowly Perl has a good solution for), is that if you do
> something like
> 
>  longVarableName = foo(longVariableName)
> 
> You end up with a bug that can be very hard to track down.  So one use
> for macros would be so that I can define "let" and "set" statements so
> that I might code like this:
> 
>  let longVariableName = 0
>  set longVarableName = foo(longVariableName)
> 
> Then if longVarableName didn't already exist, an error would be
> raised, rather than a new variable being automatically created for me.

So "let" is the initial declaration, and "set" modifies the existing
variable? 

What happens is you declare a variable twice?

let longVariableName = 0
let longVariableName = foo(longVariableName) # oops I meant set

How long did it take you to write the macros, and use them, compared to
running Pylint or Pychecker or equivalent? 


But if you really want declarations, you can have them.

>>> import variables
>>> variables.declare(x=1, y=2.5, z=[1, 2, 4])
>>> variables.x = None
>>> variables.w = 0
Traceback (most recent call last):
  File "", line 1, in 
  File "variables.py", line 15, in __setattr__
raise self.DeclarationError("Variable '%s' not declared" % name)
variables.DeclarationError: Variable 'w' not declared



The variables module isn't part of the standard library. Here's the code
for it:

import sys

class _variable:
class DeclarationError(TypeError): pass
def __setattr__(self, name, value):
if self.__dict__.has_key(name):
self.__dict__[name] = value
else:
raise self.DeclarationError("Variable '%s' not declared" % name)
self.__dict__[name]=value
def declare(self, **args):
for name, value in args.items():
self.__dict__[name] = value

sys.modules[__name__]=_variable()


It took me less than five minutes starting from Alex Martelli's code here
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/65207

No special syntax or macros or magic powers were needed. I could extend
the variables functionality to (say) make sure the same variable isn't
declared twice, or be case-insensitive, or have multiple namespaces, none
of which need special syntax.


-- 
Steven.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: is this a valid import sequence ?

[Scott David Daniels]

Stef Mientki wrote:
> ... I've defined a class, like this, ...
> 
> class T6963_device (tDevice):
> def __init__ (self):
> global LCD
> LCD = self
> ... In the same module I've a function,
> that runs a method of the above class instance, ...
> 
> def Write_LCD_Data ( data ):
> global LCD
> LCD.Write_Data ( data )

The global statement in Write_LCD_Data is completely unnecessary.  The
only time you need "global" is if you want to reassociate the global
name to another object (such as LCD = LCD + 1 or whatever).  You only
read the global name-to-object mapping (though you may be using methods
on the named object to alter the referenced object).  You only need
"global" when you need to "write" (re-bind) the global name-to-object
mapping.

--Scott David Daniels
[EMAIL PROTECTED]
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Collections of non-arbitrary objects ?

[walterbyrd]

On Jun 22, 11:43 pm, Ben Finney <[EMAIL PROTECTED]>
wrote:

> Can you help us understand, by showing a use case that would in your
> estimation be improved by the feature you're describing?
>

Suppose you are sequentially processing a list with a routine that
expects every item to be of a certain type. Something in the list that
doesn't conform to the type could give you unexpected results, maybe
crash your application.

In python, as far as I know, there is nothing built into the language
to keep any type of item from being included in a list - or any such
structure. To me, that seems like a potentially vulnerability.
Especially since variables in python do not have to be explicitly
assigned - another variable that points to the same thing, could
change the data that a variable points to.



-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Adding method to a class on the fly

[Steven D'Aprano]

On Sat, 23 Jun 2007 09:06:36 -0700, John Henry wrote:

>>
>> > But then how do I create the on_Button1_mouseClick function?
>>
>> That depends on what it is supposed to do, but in general you want a
>> factory function -- a function that returns functions. Here's a simple
>> example:
>>
> 
> 
> Steven,
> 
> May be I didn't explain it clearly: the PythonCard package expects to
> see a function by the name of on_Button1_mouseClick.  I don't do
> anything to register the callback function.  The package assumes that
> there is a function by that name whenever I create a button named
> Button1.  So, if I don't use exec, how can I create a function by that
> exact name?


def mouseclick_factory(name):
def function(self, event):
print "You clicked '%s'." % name
function.name = "on_%s_mouseClick" % name
return function



class Parrot:
def __init__(self, name):
function = mouseclick_factory(name) # as before
method = new.instancemethod(function, self, self.__class__)
setattr(self, function.name, method)


And here it is in action:

>>> p = Parrot("Button1")
>>> p.on_Button1_mouseClick("event")
You clicked 'Button1'.



-- 
Steven.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python's "only one way to do it" philosophy isn't good?

[Douglas Alan]

Michele Simionato <[EMAIL PROTECTED]> writes:

> Been there, done that. So what? Your example will not convince any
> Pythonista.

I'm a Pythonista, and it convinces me.

> The Pythonista expects Guido to do the language job and the
> application developer to do the application job.

I'm happy to hear that there is a brain washing device built into
Python that provides all Python programmers with exactly the same
mindset, as that will certainly aid in having a consistent look and
feel to all Python code.

> Consider for instance generators.

Yes, consider them!  If Python had first class continuations (like
Ruby does) and macros in 1991, it could have had generators in 1992,
rather than in 2002.  (I implemented generators using macros and stack
groups for Lisp Machines in 1983, and it took me all of a few hours.)

> In Python they are already implemented in the core language and the
> application developer does not care at all about implementing them.

And if they were implemented as macros in a library, then the
application developer doesn't have to care about implementing them
either.

> In Scheme I am supposed to implement them myself with continuations,
> but why should I do that, except as a learning exercise?

Well, when I get around to giving my sage advice to the Scheme
community, I'll let them know that generators need to be in the
standard library, not a roll-your-own exercise.

> It is much better if competent people are in charge of the very low
> level stuff and give me just the high level tools.

Even many competent people don't want to hack in the implementation
language and have to understand the language implementation internals
to design and implement language features.  By your argument,
Pythonistas might as well insist that the entire standard library be
coded in C.

> BTW, there are already Python-like languages with macros
> (i.e. logix) and still nobody use them, including people with a
> Scheme/Lisp background. That /should be telling you something.

It only tells me what I've known for at least a couple decades now --
that languages live and die on issues that often have little to do
with the language's intrinsic merits.

|>oug
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The Modernization of Emacs: terminology buffer and keybinding

[David Kastrup]

Matthias Buelow <[EMAIL PROTECTED]> writes:

> Tim Roberts wrote:
>
>> Editors are like underwear.  We each have our own favorite brand, and
>> nothing you say will convince me to change mine.
>
> You really should have stopped here :)

Well if "It stinks!" is not incentive enough for him to change his
underwear, what will?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python's "only one way to do it" philosophy isn't good?

[Douglas Alan]

Steven D'Aprano <[EMAIL PROTECTED]> writes:

> Nevertheless, in Python 1+2 always equals 3. You can't say the same thing
> about Lisp.

Well, I can't say much of *anything* about "1 + 2" in Lisp, since
that's not the syntax for adding numbers in Lisp.  In Lisp, numbers
are typically added using the "+" function, which might be invoked
like so:

   (+ 1 2 3)

This would return 6.

It's true that some dialects of Lisp will let you redefine the "+"
function, which would typically be a bad idea.  Other dialects would
give you an error or a warning if you tried to redefine "+".  I would
fall more into the latter camp.  (Though sometimes you might want a
way to escape such restrictions with some sort of "yes, I really want
to shoot myself in the head" declaration, as you may want to
experiment, not with changing the meaning of "(+ 1 2"), but rather
with adding some additional useful capability to the "+" function that
it doesn't already have.

Back on the Python front, although "1 + 2" might always equal 3 in
Python, this is really rather cold comfort, since no useful code would
ever do that.  Useful code might include "a + 1", but since you can
overload operators in Python, you can say little about what "a + 1"
might do or mean on the basis of the syntax alone.

Furthermore, in Python you can redefine the "int" data type so that
int.__add__ does a subtraction instead.  Then you end up with such
weirdness as

   >>> int(1.0) + int(2.0)
   -1

Also, you can redefine the sum() function in Python.

So, we see that Python offers you a multitude of ways to shoot
yourself in the head.

One of the things that annoys me when coding in Python (and this is a
flaw that even lowly Perl has a good solution for), is that if you do
something like

 longVarableName = foo(longVariableName)

You end up with a bug that can be very hard to track down.  So one use
for macros would be so that I can define "let" and "set" statements so
that I might code like this:

 let longVariableName = 0
 set longVarableName = foo(longVariableName)

Then if longVarableName didn't already exist, an error would be
raised, rather than a new variable being automatically created for me.

The last time I mentioned this, Alex Martelli basically accused me of
being an idiot for having such trivial concerns.  But, ya know -- it
isn't really a trivial concern, despite Martelli's obviously high
intellect.  A woman I work with who is bringing up a CMS using Drupal
was complaining to me bitterly that this very same issue in PHP was
causing her bugs that were hard to track down.  Unfortunately, I could
not gloat over her with my Python superiority, because if Drupal were
written in Python, rather than PHP, she'd have the very same problem
-- at least in this regard.

|>oug
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The Modernization of Emacs: terminology buffer and keybinding

[Matthias Buelow]

Tim Roberts wrote:

> Editors are like underwear.  We each have our own favorite brand, and
> nothing you say will convince me to change mine.

You really should have stopped here :)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Adding method to a class on the fly

[John Henry]

>
> > But then how do I create the on_Button1_mouseClick function?
>
> That depends on what it is supposed to do, but in general you want a
> factory function -- a function that returns functions. Here's a simple
> example:
>


Steven,

May be I didn't explain it clearly: the PythonCard package expects to
see a function by the name of on_Button1_mouseClick.  I don't do
anything to register the callback function.  The package assumes that
there is a function by that name whenever I create a button named
Button1.  So, if I don't use exec, how can I create a function by that
exact name?

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The Modernization of Emacs: terminology buffer and keybinding

[David Golden]

Bjorn Borud wrote:

> [Falcolas <[EMAIL PROTECTED]>]
> | 
> | I guess ultimately I'm trying to argue the point that just because a
> | tool was written with a GUI or on Windows does not automatically
> | make it any less a productive tool than a text based terminal tool.
> | Even in windows, you can use the keyboard to do all of your work, if
> | you learn how (thanks to the magic of the alt key).
> 
> as I see it, the debate isn't whether GUI tools are inferior per se,
> but whether Emacs is inferior since it has its own interaction
> concepts that do not map 1:1 to GUI conventions of Windows and OSX.

I think it worthwile to point out again here that emacs does in fact
have a bitmapped, windowy GUI, has done for years - e.g.
http://oldr.net/emacshelp4.gif  ...
Some people in this silly thread (not Bjørn specifically) seem to be
labouring under the impression that it is solely a text-only
interface - "Mouse longcuts" exist for the most basic keyboard commands
when you're using emacs on a WIMP system like X11 or Microsoft Windows
(though you can turn them off to stop wasting screen real estate on
pretty-pretty once you know the keyboard commands)

> (indeed several friends of mine would like to see Emacs done in Common
> Lisp, and I seem to have some memory of such a project existing
> somewhere).
>

Climacs @
http://common-lisp.net/project/climacs/


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python plain-text database or library that supports joins?

[Michele Simionato]

On Jun 22, 7:18 pm, felciano <[EMAIL PROTECTED]> wrote:
> Hello --
>
> Is there a convention, library or Pythonic idiom for performing
> lightweight relational operations on flatfiles? I frequently find
> myself writing code to do simple SQL-like operations between flat
> files, such as appending columns from one file to another, linked
> through a common id. For example, take a list of addresses and append
> a 'district' field by looking up a congressional district from a
> second file that maps zip codes to districts.

Have you looked at itools?

http://www.ikaaro.org/itools#itools.csv

HTH,

   Michele Simionato

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The Modernization of Emacs: terminology buffer and keybinding

[Bjorn Borud]

[Twisted <[EMAIL PROTECTED]>]
|
| That sort of negative-sum thinking is alien to me. Software being easy
| for beginners to get started using does not in and of itself detract
| from its value to expert users.

the fact that you imply that this is my argument tells me that either
you have not paid attention, or you have a raging inferiority complex.
given the sum of your postings so far I'd say that you neither are,
nor consider yourself, a cerebral sort of person, so this narrows it
down somewhat (although not to the exclusion of you not having paid
attention).

-Bjørn
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "assert" annoyance

[Michele Simionato]

On Jun 22, 5:05 pm, Paul Rubin  wrote:
> Unit tests are not a magic wand that discover every problem that a
> program could possibly have.


+1 QOTW

   Michele Simionato

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: SIMD powered Python

[Paul Rubin]

Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> writes:
> > True... But maybe in NumPy arrays that would be more feasible...?
> 
> Yes but that's in external libraries and not in the Python interpreter.
> So it won't speed up Python code like list comprehensions but "just" calls
> to external functions written in C, Fortran or assembler if those make use
> of SIMD instructions.

Right, Python has such poor control over side effects that it has not
much chance of parallelizing stuff like list comprehensions in
general.  Maybe there's some chance of doing it for some special cases
with RPython.

See http://www.google.com/search?q="nested+data+parallelism";
for what's happening with some other languages.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python's "only one way to do it" philosophy isn't good?

[Paul Rubin]

Michele Simionato <[EMAIL PROTECTED]> writes:
> Really powerful languages (say Haskell, just not to be too
> Python-centric) do not need macros.

http://www.haskell.org/th/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python's "only one way to do it" philosophy isn't good?

[Paul Rubin]

Michele Simionato <[EMAIL PROTECTED]> writes:
> BTW, there are already Python-like languages with macros
> (i.e. logix) and still nobody use them, including people with a
> Scheme/Lisp background. That should be telling you something.

What about Dylan?
-- 
http://mail.python.org/mailman/listinfo/python-list

Using PSE under Win32

[Eduardo Dobay]

Hello, I've been playing around with mod_python these days (using
Publisher and PSP), and it has been working smoothly under Windows XP
(using Apache 2.2). But when I installed PSE and went to use it with
mod_python, it didn't work. The error I get whenever I try to load a
PSE page is:

Traceback (most recent call last):

  File "C:\Python25\lib\site-packages\mod_python\importer.py", line
1537, in HandlerDispatch
default=default_handler, arg=req, silent=hlist.silent)

  File "C:\Python25\lib\site-packages\mod_python\importer.py", line
1229, in _process_target
result = _execute_target(config, req, object, arg)

  File "C:\Python25\lib\site-packages\mod_python\importer.py", line
1128, in _execute_target
result = object(arg)

TypeError: 'module' object is not callable


I thought it could be some incompatibility issue between PSE and
mod_python, but I tried both installing the PSE binary and building
the sources, and it didn't make a difference. Has anyone out there had
success using PSE under Windows?

(Just for the record, I did install matching versions, at least for
Apache (2.2.3), Python (2.5) and mod_python (3.3.1). PSE doesn't seem
to have a strict version requirement.)

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The Modernization of Emacs: terminology buffer and keybinding

[Bjorn Borud]

[Falcolas <[EMAIL PROTECTED]>]
| 
| I guess ultimately I'm trying to argue the point that just because a
| tool was written with a GUI or on Windows does not automatically make
| it any less a productive tool than a text based terminal tool. Even in
| windows, you can use the keyboard to do all of your work, if you learn
| how (thanks to the magic of the alt key).

as I see it, the debate isn't whether GUI tools are inferior per se,
but whether Emacs is inferior since it has its own interaction
concepts that do not map 1:1 to GUI conventions of Windows and OSX.

the point I am trying to get across is that Emacs (and vi) is its own
niche, and that if you want to improve them, there are more important
things than fiddling around with superficial details (like keybindings
-- which you can customize to your own liking anyway).

for Emacs it would be far more helpful if the Lisp-implementation was
replaced with one that is more efficient and Common Lisp-like.
(indeed several friends of mine would like to see Emacs done in Common
Lisp, and I seem to have some memory of such a project existing
somewhere).

-Bjørn
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: SIMD powered Python

[Marc 'BlackJack' Rintsch]

In <[EMAIL PROTECTED]>, Bytter wrote:

> Marc 'BlackJack' Rintsch escreveu:
>> In <[EMAIL PROTECTED]>, Bytter wrote:
>>
>> > Is there any I&D ongoing about using SIMD [1] instructions, like SSE
>> > [2], to speed up Python, especially regarding functional features,
>> > like list comprehension, map and reduce, etc.. ?
>>
>> SIMD instruction sets know about "low level" data types, Python is about
>> objects.  `map()`, `reduce()`, list comprehension work on arbitrary
>> iterables so how do you expect SIMD instructions handle this?  Even simple
>> lists contain objects and those don't have to be of the same type.
>
> True... But maybe in NumPy arrays that would be more feasible...?

Yes but that's in external libraries and not in the Python interpreter.
So it won't speed up Python code like list comprehensions but "just" calls
to external functions written in C, Fortran or assembler if those make use
of SIMD instructions.

Ciao,
Marc 'BlackJack' Rintsch
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The Modernization of Emacs: terminology buffer and keybinding

[Martin Gregorie]

BartlebyScrivener wrote:
> On Jun 22, 3:47 pm, Twisted <[EMAIL PROTECTED]> wrote:
> 
>> If it requires years of mastery, it is clunky
> 
> Well, now you keep harping on this, but it's just not true.
> 
> I use vim myself, but for purposes of this argument it doesn't matter.
> If you take the Vim tutorial and use the help (which appears in a
> split window anytime you want it), you can use Vim like any other text
> editor within a day or so, especially if you use Cream, which is set
> up to hold your Windows hands and act like any other Windows text
> editor on the surface. But if you use Vim for YEARS you get better and
> faster and more efficient precisely BECAUSE of its arcane
> capabilities. If you are going to keep your hands on the keyboard
> where they belong, if you REALLY want to go fast, then there's no
> alternative to having complex key commands, which become second nature
> over time, and take the place of repetitive, totally inefficient
> mousing around.
> 
> You might enjoy this. Especially the link to an old essay called
> "Interface Zen"
> 
> http://tinyurl.com/2da3om
>
A good reference. Thanks.

I like Interface Zen - much sense there.

However, there's a case he missed, probably through never using a CAD 
system. All the good ones can be driven either by mouse, or by 
non-chorded key sequences or any combo the user likes. The essence of 
CAD is very accurate pointing but all too many mice move slightly when 
clicked. Fortunately a decent CAD system offers the possibility of 
purely pointing with the mouse and doing everything else with the other 
hand on the keyboard. The result is both fast and extremely accurate.

An interface design point that nobody has yet mentioned here is that 
there are four different types of user that map onto a grid:

casual  dedicated
untrained   1   2
expert  3   4

I first ran across grid this in "Design of Man-Computer Dialogs" by 
James Martin and its been very useful in systems interface design.

The problem with almost all current GUIs is that they are aimed at types 
1 and 3 users - this certainly applies to Windows, OS X and Gnome 
desktops with the emphasis on type 1. vi and microEmacs, OTOH, are aimed 
at type 3 and 4 users.

Where does emacs fit on this grid? My guess would be 3 and 4.

Its very difficult indeed to design an interface that suits both 
untrained and expert users. About the closest I've seen have been 
keyboard driven menu structures which have been designed so the user can 
build their own "command sequences" that traverse menu levels without 
showing the menus, as long as items are selected correctly from each 
level. Many CAD systems approximate to this but I've yet to see a 
graphical desktop, IDE, or editor menu structure that came close.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org   |
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The Modernization of Emacs

[Martin Gregorie]

Joel J. Adamson wrote:
> Xerox PARC (not Apple nor MIcrosoft) excelled in helping computers fit
> in to how people already lived, not the other way around.
>
I've never got my hands on a genuine Xerox. About the nearest to that I 
managed was an ICL PERQ back in 1980, with a portrait-mode black and 
white screen and a three button mouse. That was the first GUI I saw 
(next was an Apple Lisa in 1984). The PERQ was dead easy to use after 
about 5 minutes instruction.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org   |
-- 
http://mail.python.org/mailman/listinfo/python-list

relative import question: packaging scripts

[Alan Isaac]

What is the recommended packaging of
demo scripts or test scripts for a package
that has modules that use relative imports?

Example:
Suppose I have the package structure:

package/
__init__.py
subpackage1/
__init__.py
moduleY.py
subpackage2/
__init__.py
moduleZ.py

Important detail:
moduleZ uses a relative import to access moduleY.

The problem:
I have a script test.py that I want to
distribute with the package.  It will import
moduleZ to illustrate or test the module's use.

Is it the case that this script cannot reasonably be
bundled with `package`?  (I.e., within its directory
structure.)

I cannot put it in the `subpackage2` directory and
just import moduleZ, because then I will get
ValueError: Attempted relative import in non-package

I cannot put it in the `package` directory and
import subpackage2.moduleZ, because then I will get
ValueError: Attempted relative import beyond toplevel package

The script could use path manipulation to
find `package`, as suggested by Alex Martelli
http://mail.python.org/pipermail/python-list/2007-May/438250.html
and others.  However it has also been claimed that this approach is an
insane for any shared code.  Is it?

I do not want to assume the package will be installed:
a user should be able to play with it without installing it.
In this case, does the only "sane" thing to become to
require any user to take the step of inserting the
package location into sys.path and have
test.py rely on the user having done this?

Thank you,
Alan Isaac
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The Modernization of Emacs: terminology buffer and keybinding

[Bjorn Borud]

[Twisted <[EMAIL PROTECTED]>]
| You end up having to memorize the help, because *you can't
| have arbitrary parts of the help and your document open side by side
| and be working on the document*. All because you can't simply tab or
| click to the document.

yes you can.  you even have a lot of choice as to how you want to do
it and it even works on the simplest of text terminals (which is
useful when you are on the road and only have a computer with a
browser availabe and you've had the foresight to set up the Mindterm
SSH applet on a machine so you can log in and edit code from anywhere
in the world).

I use multiple frames on-screen most of the time.  either to edit and
view multiple files at once or to edit different locations of the same
file.  if you're a programmer it is often useful to be able to do
this.  you can look at more than one file at the same time, have
documentation up on screen etc.

| At minimum, you have to *memorize* some arcane key controls for
| switching panes ... er, "windows", that are totally unintuitive and
| unlike what is normally used.

following the built-in tutorial in Emacs I understood how to
manipulate buffers and split windows in various ways.  there are
basically three commands you need to know.  one of them is used to
switch between active buffers in a given window, so it is not specific
to splitting.

it took me minutes to learn and within days I didn't even think about
what I was doing -- I was just using the features.

I think you fail to understand the approach.  if you know an editor
like VI or Emacs properly you have a much bigger bag of tricks, that
are applicable to a wide range of scenarios, than what is encouraged
by GUI intensive editors.  and you don't think of them as "tricks".
it is just the way you edit text.

| Oops. The interface design is a nightmare. The most basic requirement,
| that it be easy to have the help open side by side with your document
| and switch back and forth and navigate inside the help easily, is
| broken. If you have to consult the help just to navigate the help or
| to switch focus between document and help, then you're trapped, and
| that is what happens with emacs.

why don't you learn Emacs before you say what it can and can't do?
it is so frustrating to debate editors with people who haven't even
bothered to make a minimal effort to at least spend a day or two
learning it.

let's look at Word and word processing.  how long does it take you to
learn Word properly?  to understand how to efficiently edit large
documents, automate common tasks, use the built-in features for
helping you organize documents?


-Bjørn
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python's "only one way to do it" philosophy isn't good?

[Michele Simionato]

On Jun 23, 6:11 am, Lenard Lindstrom <[EMAIL PROTECTED]> wrote:
> When this thread turned to the topic of macros I did an Internet search
> for information on macros relevant to Python. Dylan's macros look
> promising. The Python-inspired language Converge has macros 
> (http://convergepl.org/). Michael Hudson's Bytecodehacks package
> supports limited Python macros 
> (http://bytecodehacks.sourceforge.net/bch-docs/bch/module-bytecodehack...
> ). There is also the __macro__ package, which I still have on my
> computer, but I cannot find its home page.
>
> The __macro__ package simply allows text substitution of source code at
> module import time. The bytecodehack.macro module lets one define what
> amounts to inlined functions. IMO neither package represents a
> productive macro system. And I could find no other attempts to take
> Python macros beyond wishful thinking. So until some solid proposal for
> Python macros is put on the table any discussion of their merits is
> unproductive. I can suggest though that procedural macros are a natural
> starting point given the runtime nature of class and function creation.
>
> --
> Lenard Lindstrom
> <[EMAIL PROTECTED]>

I would add to your list http://livelogix.net/logix/
and
http://www.fiber-space.de/EasyExtend/doc/main/EasyExtend.html

  Michele Simionato

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: high performance/threaded applications in Python - your experiences?

[Ivan Voras]

Jay Loden wrote:

> I was hoping for some experiences that some of you on the list may have had 
> in dealing with Python in a high performance and/or threaded environment. In 
> essence, I'm wondering how big of a deal the GIL can be in a  real-world 
> scenario where you need to take advantage of multiple processor machines, 
> thread pools, etc. How much does it get in the way (or not), and how 
> difficult have you found it to architect applications for high performance? I 
> have read a number of articles and opinions on whether or not the GIL is a 
> good thing, and how it affects threaded performance on multiple processor 
> machines, but what I haven't seen is experiences of people who have actually 
> done it and reported back "it was a nightmare" or "it's no big deal" ;)

The theory: If your threads mostly do IO, you can get decent CPU usage
even with Python. If the threads are CPU-bound (e.g. you do a lot of
computational work), you'll effectively only make use of one processor.

In practice, I've noticed that Python applications don't scale very much
across CPUs even if they're doing mostly IO. I blame cache trashing or
similar effect caused by too many global synchronization events. I
didn't measure but the speedup may even be negative with large-ish
number of CPUs (>=4).

OTOH, if you can get by with using forking instead of threads (given
enough effort) you can achieve very good scaling.

-- 
(\__/)
(O.o)
(> < )

This is Bunny.
Copy Bunny into your signature to help him on his way to world domination!



signature.asc
Description: OpenPGP digital signature
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python's "only one way to do it" philosophy isn't good?

[Michele Simionato]

On Jun 22, 7:54 pm, Douglas Alan <[EMAIL PROTECTED]> wrote:
> The proof is in the pudding for anyone who has seen the advantages it
> brings to Lisp.  As Paul Graham points out, it's hard to look up and
> see the advantages of what is up there in a more powerful language.
> It's only easy to look down and see the disadvantages of what is
> missing from a less powerful language.  To understand the advantages,
> one has to be willing to climb the hill and take in the view.

Right. However you fail to recognize that there are people here with a
good
understanding of Lisp and its macrology that still prefer Python over
Lisp.
I will go even further and say that the utility of macros is inversely
proportional
to the power of a language: the more the language is powerful, the
less macros
are useful. Really powerful languages (say Haskell, just not to be too
Python-centric)
do not need macros.

Provocative-but-with-a-grain-of-salt-in-it-yours,

  Michele Simionato

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Adding method to a class on the fly

[Steven D'Aprano]

On Sat, 23 Jun 2007 00:02:09 -0700, John Henry wrote:

[snip]
> Notice that the event handler for mouseClick to Button1 is done via
> the function on_Button1_mouseClick.  This is very simple and works
> great - until you try to create the button on the fly.
> 
> Creating the button itself is no problem.  You simply do a:
> 
> self.components['Button1'] = {'type':'Button',
>  'name':'Button1',
>  'position':(5, 35),
>  'label':'Button1'}
> 
> But then how do I create the on_Button1_mouseClick function?

That depends on what it is supposed to do, but in general you want a
factory function -- a function that returns functions. Here's a simple
example:

def mouseclick_factory(arg):
def on_mouseClick(self, event):
print "You clicked '%s'." % arg
return on_mouseClick

func1 = mouseclick_factory("Button 1")
func2 = mouseclick_factory("this button")
func3 = mouseclick_factory("something")


Now let's try them out, faking the "self" and "event" parameters:


>>> func1(None, None)
You clicked 'Button 1'.
>>> func2(None, None)
You clicked 'this button'.
>>> func3(None, None)
You clicked 'something'.


Obviously in a real application, self and event are important and can't be
faked with None.

Now, there are two ways of using that factory function in a class. Here
is an example of both.

class Parrot:
def __init__(self, arg):
self.bar = mouseclick_factory(arg)
foo = mouseclick_factory("Foo")

p = Parrot("bar")

If you do it like this, there is a slight Gotcha to watch out for: as
provided, foo is an instance method (and so has the self argument
supplied automatically) but bar is not (and so needs the self argument to
be supplied manually.

>>> p.foo(None) # fake event argument
You clicked 'Foo'.
>>> p.bar(p, None) # self and fake event arguments
You clicked 'bar'.

If this is a problem -- and believe me, it will be -- you can use
new.instancemethod to convert bar.


[snip]

> Now, knowing the new.instancemethod way, may be I can simplify the
> above somewhat and improve the efficiencies but I still don't see how
> one can do it without using the exec function.

Rule 1:
Never use exec.

Exception for experts:
If you know enough to never need exec, you can use it.

Rule 1 is actually not quite true, but as an approximation to the truth,
it is quite good.



-- 
Steven.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The Modernization of Emacs

[Bjorn Borud]

[Twisted <[EMAIL PROTECTED]>]
| 
| > I have observed similar opinions in other non-computer-freaks.  people
| > who see the computer only as a tool and are only interested in getting
| > the job done.  they have a surprising preference for Linux.
| 
| But not emacs, I'll bet. I think emacs appeals to people who like
| dealing with the mechanics of emacs or fiddling with and extending the
| darn thing. But most people just want to get the job done, and the
| editor or other tools they use have to get out of the way and simply
| let them work.

no, Emacs is not among the applications they use.  nor are any IDEs or
compilers.  I don't think Emacs is that relevant to these users since
what they do is mostly word-processing, spreadsheets, mail and web
browsing.  Emacs is not really targeted at Word processing as
such. (although that doesn't stop some people from thinking that it
would be a good idea to turn Emacs into a wordprocessing application
with support for graphics, mixed fonts etc.)

I use Emacs for creating documents, but this is very different since I
use LaTeX and I'm a programmer, so it is very conventient for me to
use a system that allows me to treat documents like code (with respect
to revision control systems etc).  outside academia or the technical
community, not that many use LaTeX, but I have seen it in the past.

-Bjørn
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python's "only one way to do it" philosophy isn't good?

[Michele Simionato]

On Jun 22, 8:09 pm, Douglas Alan <[EMAIL PROTECTED]> wrote:
> Functionality is no good if it's too cumbersome to use.  For instance,
> Scheme gives you first class continuations, which Python doesn't.
> Continuations let you do *all sorts* of interesting things that you
> just cannot do in Python.  Like backtracking, for instance.  (Well
> maybe you could do backtracking in Python with lots of putting code
> into strings and liberal use of eval, for all I know, but the results
> would almost certainly be too much of a bear to actually use.)
>
> Now, continuations, by themselves, in Scheme actually don't buy you
> very much, because although they let you do some crazy powerful
> things, making use of them to do so, is too confusing and verbose.  In
> order to actually use this very cool functionality, you need macros so
> that you can wrap a pretty and easy-to-use face on top of all the
> delicious continuation goodness.
>
> You'll, just have to trust me on this one.  I've written code with
> continuations, and I just couldn't make heads or tails out of the code
> a few hours later.  But when prettied-up with a nice macro layer, they
> can be a joy to behold.


Been there, done that. So what? Your example will not convince any
Pythonista.
The Pythonista expects Guido to do the language job and the
application developer
to do the application job. Consider for instance generators. In Python
they are
already implemented in the core language and the application developer
does not
care at all about implementing them. In Scheme I am supposed to
implement them myself with
continuations, but why should I do that, except as a learning
exercise? It is
much better if competent people are in charge of the very low level
stuff and
give me just the high level tools. I essentially view macros are low-
level performance
hacks, useful for language developers more than for application
developers.
BTW, there are already Python-like languages with macros (i.e. logix)
and still
nobody use them, including people with a Scheme/Lisp background. That
should be
telling you something.


   Michele Simionato

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: SIMD powered Python

[Bytter]

Hi...

True... But maybe in NumPy arrays that would be more feasible...?

Cheers.

Hugo Ferreira

Marc 'BlackJack' Rintsch escreveu:
> In <[EMAIL PROTECTED]>, Bytter wrote:
>
> > Is there any I&D ongoing about using SIMD [1] instructions, like SSE
> > [2], to speed up Python, especially regarding functional features,
> > like list comprehension, map and reduce, etc.. ?
>
> SIMD instruction sets know about "low level" data types, Python is about
> objects.  `map()`, `reduce()`, list comprehension work on arbitrary
> iterables so how do you expect SIMD instructions handle this?  Even simple
> lists contain objects and those don't have to be of the same type.
>
> Ciao,
>   Marc 'BlackJack' Rintsch

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3107 and stronger typing (note: probably a newbie question)

[Kay Schluehr]

On 22 Jun., 08:46, John Nagle <[EMAIL PROTECTED]> wrote:

> PEP 3107 seems to add negative value to the language.  The
> ability to add arbitrary attributes to parameters which can then
> be interpreted by some external library yet to be defined is
> a "l33t feature", one that's more cute than useful.  Type-based
> dispatching is cute, but not really essential to Python.

I guess you refer to the generic functions PEP. Otherwise type based
dispatching is what Psyco does implicitely by caching variants of
natively compiled code blocks that can be considered as anonymous
functions. But then Psyco has to perform continous measurements and
either select a precompiled block if an appropriate signature has been
found or return code to the bytecode interpreter for further
evaluation. This scheme is an example for type directed evaluation
that does not interfere with Pythons default semantics.

Personally I appreciate having more control over expressions by means
of annotations. I also do think it's valuable for component adaptions.
So far I fail to see why it shall harm Python or having any impact on
its flexibility. Being "unusal" is not an argument neither are vague
apprehensions that Python will be locked into a poor type system with
rigid default semantics.

Kay

-- 
http://mail.python.org/mailman/listinfo/python-list

RE: Changing the names of python keywords

[vedrandekovic]

Hello,

I  on working on windows and Python 2.4. Where can I find and CHANGE
python
grammar.  ( I just want to change the keywords )

  PLEASE HELP ME
SOMEBODY!!
 
THANKS!

-- 
http://mail.python.org/mailman/listinfo/python-list

Changing sound volume

[simon kagwe]

Hi,

I am playing sounds using the winsound module. Is there a way I can change the 
volume?

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: People who reply to spammers [was: Re: I need some cleanings tips and advice.]

[Lew]

Steven D'Aprano wrote:
> On Fri, 22 Jun 2007 16:11:58 +, Colin B. replied to a spammer with:
> 
>> Let's see if I get this right.
>>
>> You create a website for a subject that you know nothing about. Then you
>> try to solicit content in a bunch of programming language newsgroups.
>>
>> Wow, that's pretty pathetic, even for a google-groups poster!
>>
>> Begone with you.
> 
> You know, my ISP did a pretty good job of recognizing the original post as
> spam, and dropped it, so I never even saw it until your post came along.
> So I wonder, who is more pathetic -- the spammer, who at least is hoping
> to make money from his rudeness, or idiots who try to reason with spammers
> AND include the spam in their reply?
> 
> Thanks a lot Colin, I really appreciate you finding a way to bypass the
> spam filtering. Not.
> 
> (You know, if I were a spammer, I would disguise my spam as an indignant
> response to spam, thus guaranteeing a vastly greater audience.)
> 
> Colin, if that doesn't convince you to STOP ENGAGING SPAMMERS IN
> DISCUSSION, no matter how witty you think your reply is, let me
> point out that by rudely including the text of the spam in your
> post, you are associating your name and email address with spam. That
> might not be such a good thing to do as more and more people use Bayesian
> filtering. 

Oh, hush.  What fun is life when you can't unleash your venom on a spammer who 
probably will never read it?

Take a chill pill and enjoy the fun.

-- 
Lew
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python live environment on web-site?

[Thomas Lenarz]

On Wed, 20 Jun 2007 15:18:26 GMT, [EMAIL PROTECTED] (Thomas
Lenarz) wrote:

>Hi all,
>
>I was wondering if there was a python-live-environment available on a
>public web-site similar to the ruby-live-tutorial on
Thanks a lot for all your replies. 

I looked at the "TryPython-Sites" and will have a look at crunchy,
although I in fact was looking for something already hosted somewhere
and ready to use.

Nonetheless, crunchy looks very interesting in general.

Thanks again,

Thomas
-- 
http://mail.python.org/mailman/listinfo/python-list

RE: Changing the names of python keywords

[...:::JA:::...]

Hello,

I  on working on windows and Python 2.4. Where can I find and CHANGE python
grammar.  ( I just want to change the keywords )

  PLEASE HELP ME 
SOMEBODY!!
  THANKS!
__ Vedran 
veki ICQ#: 264412055 Current ICQ status: + More ways to contact me Get ICQ! 
__ 


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The Modernization of Emacs: terminology buffer and keybinding

[Cor Gest]

Some entity, AKA Tim Roberts <[EMAIL PROTECTED]>,
wrote this mindboggling stuff:
(selectively-snipped-or-not-p)


> Boys, do you really not understand that this is a religious issue?  You
> can't use arguments and logic to convince someone to convert their
> religion, and you can't use arguments and logic to convince someone to
> change editors.

Nah, nothing beats a nice flame-war on a slow fridaynight & a Pint
of Bitter, while it spares the fingers to keep on manipulating all those nice
keyboard-modifiers to nag the ignorati for an other day ... ;-)

Cor
-- 
 (defvar MyComputer '((OS . "GNU/Emacs") (IPL . "GNU/Linux"))) 
The biggest problem LISP has, is that it does not appeal to dumb people
 If that fails to satisfy read the HyperSpec, woman frig or Tuxoharata
 mailpolicy @ http://www.clsnet.nl/mail.php
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3107 and stronger typing (note: probably a newbie question)

[Michael Hoffman]

Eduardo "EdCrypt" O. Padoan wrote:
> On 6/22/07, John Nagle <[EMAIL PROTECTED]> wrote:
>> Paul Boddie wrote:
>> > P.S. I agree with the sentiment that the annotations feature of Python
>> > 3000 seems like a lot of baggage. Aside from some benefits around
>> > writing C/C++/Java wrappers, it's the lowest common denominator type
>> > annotation dialect that dare not be known as such, resulting from a
>> > lack of consensus about what such a dialect should really do, haunted
>> > by a justified fear of restrictive side-effects imposed by a more
>> > ambitious dialect (eg. stuff you get in functional languages) on
>> > dynamically-typed code. I don't think the language should be modified
>> > in ways that only provide partial, speculative answers to certain
>> > problems when there's plenty of related activity going on elsewhere
>> > that's likely to provide more complete, proven answers to those
>> > problems.
>>
>>  I agree.  It's a wierd addition to the language.  It looks like
>> a compromise between the "no declarations" position and the "make
>> the language strongly typed" position.  But it's so ill-defined that
>> it's not helpful, and worse than either extreme.  The whole
>> approach is antithetical to the "only one way to do it" concept.
>> This could lead to misery when different libraries use
>> incompatible type annotation systems, which is not going to be fun.
>>
>>  Python made it this far without declarations, and programmers
>> seem to like that.  We need to get Python performance up, and
>> the ShedSkin/Psyco restrictions seem to be enough to allow that.
>> Type annotations don't seem to solve any problem that really needs
>> to be solved.
>>
>>  The main advantage of strongly typed systems is that more errors
>> are detected at compile time.  You pay for this in additional language
>> baggage.  PEP 3107 adds the excess baggage without providing the benefit
>> of compile time checks.
> 
> Remember that pure CPython has no different "compile time" and
> runtiime.

Yes, it does.
-- 
Michael Hoffman
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: subprocess.popen question

[SPE - Stani's Python Editor]

On Jun 23, 5:35 am, "Gabriel Genellina" <[EMAIL PROTECTED]>
wrote:
> En Fri, 22 Jun 2007 10:08:49 -0300, [EMAIL PROTECTED]
> <[EMAIL PROTECTED]> escribió:
>
> > I seemed to have it working sorta when I run it and save the results I
> > am noticing that inspeit spaces correctly but when I save it to a
> > file I can open it in wordpad there is only one line.  when I open in
> > up in WinXound (A csound editor) it is double spaced.  if I do it in a
> > batch file the output file is spaced correctly..  when I do splitlines
> > it is giving me one charecter down the page as output..  Do I need to
> > do something or can I do something to put an end of line charecter in
> > the output??
>
> Try
>
> print repr(your_data)
>
> to see exactly what you got.
>
> --
> Gabriel Genellina

Did you take in account that line endings on Windows are '\r\n' and
not '\n'?

Stani
--
http://pythonide.stani.be

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Error in following code

[Bjoern Schliessmann]

Jay Loden wrote:

> That should do the trick.

Additionally, it does the trick to save the first entered number as
default argument forever.

Regards,


Björn

-- 
BOFH excuse #117:

the printer thinks its a router.

-- 
http://mail.python.org/mailman/listinfo/python-list

the truth

[the truth seeker]

 Explore the greatest life of the most recognized man in
 the history of humanity.


http://mohammad.islamway.com

-- 
http://mail.python.org/mailman/listinfo/python-list

looking for scott from Glassboro State

[Fran Duffy]

I am looking for a friend of mine that I havent seen in a long time. If you
are Scott that went to Glassboro as a music major, please  send me an Email:
Fran Duffy at:
[EMAIL PROTECTED] If you are not that Scott, disregard, and sorry to
take up your time.
Thanks
Fran Duffy

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Collections of non-arbitrary objects ?

[Paddy]

On Jun 23, 1:45 am, walterbyrd <[EMAIL PROTECTED]> wrote:
> On Jun 21, 5:38 pm, Ben Finney <[EMAIL PROTECTED]>
> wrote:
>
> > That's a flippant response, but I don't understand the question.
>
> Everybody here seems to have about the same response: "why would you
> ever want to do that?"
>
> Maybe it's something that doesn't "need" to be done, but it seems to
> me that would give you a certain level of built-in integrity - you
> could be sure about what's in the structure. I would not expect that
> all of python would be that rigid, but I thought it might be
> worthwhile if there were one such structure.
>
> Think of this: why use tuples when lists are available? You can use a
> tuple to index a dictionary, but  not a list - why? I the answer may
> be that sometimes you want some degree on inherent enforced structure.
> I'm sure the language could have designed to allow lists to index
> dictionary, but you would have to awfully careful with those lists.
> The burden would be on the programmer to make certain that those lists
> didn't change. But, it could be done, therefore tuples are not
> "needed" right?
>
> Languages like C are often criticized as being too rigid - you have to
> pre-define your variables, and pre-allocate your array sizes. But,
> languages like Perl and BASIC, are often criticized as being  to
> sloppy - too few restrictions tend to lead to sloppy code. So I guess
> there is a sort of trade-off.
>
> I suppose I could use a database, that might give me some degree of
> assured integrity - depending on what database I used.

Hi Walterbyrd,
What happens when you are given good advice that may be contrary to
intuition?

Unfortunately its how we usually do things in Python and do NOT
suffer because of it. Try writing your application without it. Test
without it. Write other applications without it. Others do,
successfully.

- Paddy.


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "assert" annoyance

[Dave Baum]

In article <[EMAIL PROTECTED]>,
 Paul Rubin  wrote:

> 
> What I really want is for any assertion failure, anywhere in the
> program, to trap to the debugger WITHOUT blowing out of the scope
> where the failure happened, so I can examine the local frame.  That
> just seems natural, but I don't see an obvious way to do it.  Am I
> missing something?  I guess I could replace all the assertions with
> function calls that launch pdb, but why bother having an assert
> statement?

I tend to run my programs with a -i option:

python -i foo.py

Then if an exception occurs, I can do:

import pdb
pdm.pm()

and have a debug session at the point where the exception was raised.  
The "-i" shouldn't interfere with sys.argv since it is before the python 
file.

Another option would be for your program to do something like:

try:
# put your code here
except:
import sys
import pdb
pdb.post_mortem(sys.exc_info()[2])


If an exception is raised, the debugger will be started using the 
appropriate traceback.  (You don't need to import sys and pdb in the 
except block if they have already been imported.)


Dave
-- 
http://mail.python.org/mailman/listinfo/python-list