Re: need help with re module

[Gabriel Genellina]

En Sat, 23 Jun 2007 01:12:17 -0300, samwyse <[EMAIL PROTECTED]> escribió:

> Speak for yourself.  If I'm writing an HTML syntax checker, I think I'll
> skip BeautifulSoup and use something that gives me the results that I
> expect, not the results that you expect.

Sure! By the way, I'm looking for a different sound. I have an Ibanez but  
I think the Jackson is far better for thrash metal, the Jackson Kelly Pro  
series KE3 sounds good, and it's a classic. Maybe as a self-gift for my  
birthday next month.

-- 
Gabriel Genellina

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

urllib interpretation of URL with ".."

[John Nagle]

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?

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

Re: newbie question about unicode

[Gabriel Genellina]

En Sat, 23 Jun 2007 01:10:19 -0300, Genie T <[EMAIL PROTECTED]>  
escribió:

> can anybody tell me whether these two expressions have the same
> meanings?
>
> s = u''
> s1 = s.encode('utf-8')
>
> AND
>
> s1 = unicode(s,'utf-8')

No - but consider this (assuming your terminal uses utf-8):

py> u1 = u''
py> s1 = u1.encode('utf-8')
py>
py> s2 = ''
py> u2 = s2.decode('utf-8')
py>
py> type(u1), type(u2)
(, )
py> u1==u2
True
py> type(s1), type(s2)
(, )
py> s1==s2
True

-- 
Gabriel Genellina

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

Re: The Modernization of Emacs: terminology buffer and keybinding

[Robert Uhl]

Twisted <[EMAIL PROTECTED]> writes:
>
> How clunky versus usable an interface to a tool is is for those who
> invest some, but not extraordinary amounts of, time into its use to
> decide. If it requires years of mastery, it is clunky -- period. This
> may be unavoidable if it's something involved in nuclear power plants,
> delicate neurosurgery, or whatever. If it's a text editor, on the
> other hand, it's clearly going to have superior competition in the
> area of usability.

Of course, emacs doesn't take years of mastery.  It takes 30, 40
minutes.  And a functioning intellect, of course.

Incidentally, a violin requires years of mastery, and is hardly cranky.
Granted, there are few people with the talent to play a violin well.
Maybe an automobile is a better example...

> Besides, ANY interface that involves fumbling around in the dark
> trying to find a light switch is clunky.

That sounds like vi, not emacs.

> 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

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

> 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, you've
never actually used emacs (something I'm beginning to suspect more and
more) or you're just making things up.  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.  In
fact, I am not aware of any package which auto-changes the *info* or
*Help* buffers to reflect the last keyboard command.

> Even though it would be at the price of no full- text search
> capability -- not that I could ever get that to work in emacs
> anyway. There was no apparent way to do a simple substring search and
> click "next match" or "previous match" to navigate among the
> hits...more arcane keypresses would be required, and as soon as it
> showed you the first match inside the help, the keypress documentation
> of course vanished.

Dude, you hit C-s; you're prompted for a search string; you hit C-s to
search for the next match.  From line 899 of the tutorial:

>> Now type C-s to start a search.  SLOWLY, one letter at a time,
   type the word 'cursor', pausing after you type each
   character to notice what happens to the cursor.
   Now you have searched for "cursor", once.
>> Type C-s again, to search for the next occurrence of "cursor".

If you had actually, you know, actually _read_ it this would not be a
surprise.  I hate to be rude, but I just don't see how you could ever
have actually done what you claim to have done.

> Infrequently used commands you can stand to hunt for in menus. When
> you find you use one frequently, you can try to learn the keyboard
> shortcut -- and you can find it without even consulting the help,
> simply by finding the command's menu item.

This is no different from emacs.  There's a menu bar; it displays
commands and shortcuts next to them; one can learn to use them instead,
at one's own pace.

> Every time you want to use the command but can't remember the shortcut
> you just find it in the menu and activate it from there, and see the
> shortcut while you're at it, helping to eventually memorize it. And
> the commonest sorts of File and Edit menu items have near-universal
> shortcuts, the big variation tending to be whether Redo is
> shift-ctrl-Z, ctrl-Y, nonexistent, or menu-only.

You've actually hit on another advantage of emacs: consider emacs itself
as an operating system hosting multiple applications, in which the vast
majority of commands are the same.  I can use the same text-editing
commands for reading & writing emails, reading & writing Usenet posts,
reading & writing code, browsing the web, organising my schedule and so
forth.

The vast majority of what we do on a computer is reading & writing
text--wouldn't it be cool to have a full-fledged text editing
environment always available for that sort of thing?  Wouldn't it be
cool not to have one program implement search in one way, and another a
second way, and yet another a third?  Wouldn't it be cool to have access
to a proper text editor when editing text on a web page?

> But you can start using it right away with low productivity, and
> increase your productivity with proficiency and learning (optional)
> shortcuts, chief

Re: Collections of non-arbitrary objects ?

[Gabriel Genellina]

En Fri, 22 Jun 2007 21:45:02 -0300, walterbyrd <[EMAIL PROTECTED]>  
escribió:

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

Sure. You can implement it yourself, if you want; it's not so hard even  
for a beginner. It's just not needed enough, or required enough, to become  
a builtin type.
Look for some recent posts about a RestrictedList.

-- 
Gabriel Genellina

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

Re: Collections of non-arbitrary objects ?

[Ben Finney]

walterbyrd <[EMAIL PROTECTED]> writes:

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

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

-- 
 \ "Quidquid latine dictum sit, altum viditur."  ("Whatever is |
  `\   said in Latin, sounds profound.")  -- Anonymous |
_o__)  |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The Modernization of Emacs: terminology buffer and keybinding

[Robert Uhl]

Falcolas <[EMAIL PROTECTED]> writes:
>
>> It's Mac OS and Windows which are inconsistent.  Emacs has been
>> around since they were mere glimmers in the eye of Jobs & Gates...
>
> Inconsistent? I would have to disagree. They changed paradigms -
> terminal text based interfaces to GUIs. You wouldn't expect a piece of
> software built for a terminal to be backwards compatibility to punch
> card interfaces, would you? Why would a GUI based program limit itself
> to functionality as defined by a terminal application?

You're making the assumption that Mac OS in 1984 offered some textual
capability (textual, since we're discussing text editing) which emacs
did not.  It didn't.

-- 
Robert Uhl 
A: Top posting
Q: What's the most annoying thing about Usenet?
-- 
http://mail.python.org/mailman/listinfo/python-list

high performance/threaded applications in Python - your experiences?

[Jay Loden]

All, 

In studying Python, I have predictably run across quite a bit of talk about the 
GIL and threading in Python. As my day job, I work with a (mostly Java) 
application that is heavily threaded. As such our application takes good 
advantage of multiple processors and we can often scale through simply adding 
processing power to a server. 

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" ;)

Your thoughts and opinions are welcome, especially those with relevant 
experiences. Thanks!

-Jay

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

Re: The Modernization of Emacs: terminology buffer and keybinding

[Tim Roberts]

Cor Gest <[EMAIL PROTECTED]> wrote:

>Some entity, AKA [EMAIL PROTECTED],
>wrote this mindboggling stuff:
>
>> On Jun 22, 6:32 pm, Cor Gest <[EMAIL PROTECTED]> wrote:
>> 
>> So now we're expected to go on a filesystem fishing expedition instead
>> of just hit F1? One small step (backwards) for a man; one giant leap
>> (backwards) for mankind. :P
>
>that's  M-` Escape-Backtick in a CLI, for you, thank you very much ... 
>Function-Keys  do not work in in a vt100 terminal.
>
>You really are that shallow, aren't you ? and lazy too, huh ?

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.

Editors are like underwear.  We each have our own favorite brand, and
nothing you say will convince me to change mine.  Editor, that is.  I do
occasionally change my underwear.
-- 
Tim Roberts, [EMAIL PROTECTED]
Providenza & Boekelheide, Inc.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The Modernization of Emacs: terminology buffer and keybinding

[Tim Roberts]

Bjorn Borud <[EMAIL PROTECTED]> wrote:
>
>bah, UNIX is not user hostile;  it is just selective about its
>friends.

Right.  My favorite Unix quote is from the same source (Dennis Ritchie):

 Unix is the answer.  You just have to phrase the 
 question very carefully.
-- 
Tim Roberts, [EMAIL PROTECTED]
Providenza & Boekelheide, Inc.
-- 
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 Fri, 22 Jun 2007 19:51:28 -0400, Douglas Alan wrote:

> You seem oblivious to the fact that one of the huge benefits of Python
> is its elegant and readable syntax.  The problem with not having a
> "flexible syntax", is that a programming language can't provide
> off-the-shelf an elegant syntax for all functionality that will ever
> be needed.

It is hardly "off-the-shelf" if somebody has to create new syntax for it.



> Eventually programmers find themselves in need of new
> elegant functionality, but without a corresponding elegant syntax to
> go along with the new functionality, the result is code that does not
> look elegant and is therefore difficult to read and thus maintain.

That's true, as far as it goes, but I think you over-state your
case. The syntax included in Python is excellent for most things, and even
at its weakest, is still good. I can't think of any part of Python's
syntax that is out-and-out bad.

The reality is, one can go a long, long, long distance with Python's
syntax. Most requests for "new syntax" I've seen fall into a few
categories:

* optimization, e.g. case, repeat, multi-line lambda
* "language Foo looks like this, it is kewl"
* the usual braces/whitespace flamewars
* trying to get static type checking into the language


So let's be specific -- what do you think Python's syntax is missing? If
Python did have a macro facility, what would you change?

It is easy to point to functional features Python is missing, but are they
functions that can't be elegantly written without new syntax? Given
that not everybody is convinced that Python needs static type checking,
the only obvious hole I can see is the lack of syntax for
repeat-at-least-once.


[snip]

> Take the issue up with Paul Graham.  Since making a fortune developing
> software in Lisp (making heavy use of macros), he now has much more
> free time to write essays defending the truth than I do:
> 
>http://www.paulgraham.com/avg.html


I think the #1 advantage to using Lisp in a commercial enterprise is only
indirectly related to the language. Lisp coders are a self-selecting
above-average bunch -- no VB drones or C code monkeys need apply.

Graham talks about 25% of the Viaweb code base being macros. Imagine how
productive his coders would have been if the language was not quite
so minimalistic, so that they could do what they wanted without the
_lack_ of syntax getting in the way.



-- 
Steven.

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

Re: newbie question about unicode

[Carsten Haese]

On Sat, 23 Jun 2007 04:10:19 -, Genie T wrote
> Hi,
> 
> can anybody tell me whether these two expressions have the same
> meanings?
> 
> s = u''
> s1 = s.encode('utf-8')
> 
> AND
> 
> s1 = unicode(s,'utf-8')

Considering that one works and the other doesn't, no, they don't have the same
meaning.

The unicode() function decodes a given byte string into a unicode object, but
you're giving it a unicode object. What are you actually trying to achieve?

If you're just trying to get a handle on the topic, I recommend you read
http://www.amk.ca/python/howto/unicode

HTH,

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

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

Re: EMBEDDING > Run Python & Run C Function

[Gabriel Genellina]

En Fri, 22 Jun 2007 12:09:40 -0300, <[EMAIL PROTECTED]> escribió:

> At the moment i can run python-string-code from C (MinGW, WinXP)
>
> But how can i register a C-function in python-RUNTIME and call this C
> function from python - without wrapper dll's or libs???

You can use ctypes:
http://www.python.org/doc/lib/module-ctypes.html

-- 
Gabriel Genellina

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

Re: need help with re module

[samwyse]

Gabriel Genellina wrote:
> En Wed, 20 Jun 2007 17:56:30 -0300, David Wahler <[EMAIL PROTECTED]>  
> escribió:
> 
>> On 6/20/07, Gabriel Genellina <[EMAIL PROTECTED]> wrote:
>>
[snip]
>> I agree that BeautifulSoup is probably the best tool for the job, but
>> this doesn't sound right to me. Since the OP doesn't care about tags
>> being properly nested, I don't see why a regex (albeit a tricky one)
>> wouldn't work. For example:
>>
[snip]
>>
>> Granted, this misses out a few things (e.g. DOCTYPE declarations), but
>> those should be straightforward to handle.
> 
> It doesn't handle a lot of things. For this input (not very special, 
> just  a few simple mistakes):
> 
> 
> http://foo.com/baz.html>click here
> What if price<100? You lose.
> What if HitPoints<-10? You are dead.
> Assignment: target <-- any_expression
> Just a few last words.
> 
> 
> the BeautifulSoup version gives:
> 
> click here
> What if price<100? You lose.
> What if HitPoints<-10? You are dead.
> Assignment: target <-- any_expression
> Just a few last words.
> 
> and the regular expression version gives:
> 
> http://foo.com/baz.html>click here
> What if priceWhat if HitPointsAssignment: target
> 
> Clearly the BeautifulSoup version gives the "right" result, or the  
> "expected" one.
> It's hard to get that with only a regular expression, you need more 
> power;  and BeautifulSoup fills the gap.

Speak for yourself.  If I'm writing an HTML syntax checker, I think I'll 
skip BeautifulSoup and use something that gives me the results that I 
expect, not the results that you expect.
-- 
http://mail.python.org/mailman/listinfo/python-list

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

[Lenard Lindstrom]

Douglas Alan wrote:
> "Terry Reedy" <[EMAIL PROTECTED]> writes:
> 
>> "Douglas Alan" <[EMAIL PROTECTED]> wrote in message 
> 
>> | > But why is the ability to abstract syntax good?
> 
>> | It allows the community to develop language features in a modular way
>> | without having to sully the code base for the language itself.
> 
>> Anyone can write modules, experimental or otherwise, without touching the 
>> code base for any particular implementation.
> 
>> For those whose know one of the implementation languages, source code 
>> control systems allow one to do experiments on branches without 'sullying' 
>> the trunk or impeding the development thereof.
> 
> When I said "without having to sully the code base", I meant that one
> can implement a language feature for the target language as a loadable
> module written entirely within the language itself, and without having
> to understand anything particularly deep or specific about the language
> implementation details.
> 
> I.e., I could write a new object system for Lisp faster than I could
> even begin to fathom the internal of CPython.  Not only that, I have
> absolutely no desire to spend my valuable free time writing C code.
> I'd much rather be hacking in Python, thank you very much.
> 

CPython's class system is independent of the interpreter proper. That is 
how two class systems, classic and new-style, can exist in the same 
language. Both class types implement hooks into attribute lookup. By 
providing __getattr__/__getattribute__, __setattr__, and __delattr__ 
methods one can effectively alter object behavior, such as method 
resolution. And metaclasses change the nature of class statements. Novel 
objects systems, such as prototypes, are possible. So the Python 
language provides more of a framework for handling objects rather than 
defining an actual object model. Python is the syntax; objects define 
the behavior.

Finally, with the advent of Python 2.2, built-in types like int and list 
became far more class like. Subclassing became possible. The object 
types were reworking at the interpreter level. No amount of macro 
wizardry could have done it.

>> One of the goals of the PyPy project was to allow people to experiment with 
>> syntax extensions in Python itself.  (But I don't know how easy that is 
>> yet.)
> 
> PyPy sounds like a very interesting project indeed!
> 

PyPy uses aspects without needing macros.

>> But I think that overall the problem of designing new syntax is more
>> in the design than the implementation.  Anything new has to be
>> usable, readable, not clash too much with existing style, not
>> introduce ambiguities, and not move the extended language outside
>> the LL(1) [I believe that is right] subset of CFLs.
> 
> People (myself included) haven't had much trouble implementing nice
> and useful macro packages for Lisp.  Admittedly, it's a harder problem
> for a language that doesn't have a Lisp-like syntax.  I believe that
> Dylan has macros without having a Lisp-like syntax, but Dylan is
> really a dialect of Lisp, only with a more traditional Algol-like
> syntax veneered onto it.  My guess is that a macro developer for Dylan
> would have to be familiar with an underlying hidden intermediate Lisp
> syntax.  (Though I'm just really just spouting that guess out of my
> butt.)
> 

Dylan macros do not use an "underlying hidden intermediate Lisp syntax". 
  They are language-based, doing pattern matching on Dylan language 
elements ( http://www.opendylan.org/books/dpg/db_329.html ).

> A few years back, I designed a somewhat Python-like language with a
> macro facility for a class on dynamic languages and their
> implementations.  I didn't implement it, however, and I doubt that
> I'll have time to get around to it in this lifetime.
> 

It's easy to say Python would benefit from macros. Macros have solved 
problems in Common Lisp and Scheme and so it is assumed they can do the 
same for Python. But no concrete suggestions are made in this thread. No 
specific macro mechanism is put forward for Python. No example is given 
on how to implement some Python feature with it. No point has been 
identified in the Python compiler chain for macro expansion.

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-bytecodehacks.macro.html
 
). 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

newbie question about unicode

[Genie T]

Hi,

can anybody tell me whether these two expressions have the same
meanings?

s = u''
s1 = s.encode('utf-8')

AND

s1 = unicode(s,'utf-8')

Thanks :)

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

MI5 Persecution: Stasi 21/4/96 (15702)

[MI5Victim]

Subject: Chief Constable Alderson Condemns "Stasi" MI5
Newsgroups:uk.misc,uk.politics,uk.media,uk.legal,soc.culture.british
Organization: Toronto Free-Net
Summary:
Keywords:
 
 
John Alderson, former Chief Constable of Devon and Cornwall, had the
following to say about the expansion of the Security Service's powers, in
a recent magazine article;
 
"It is fatal to let the secret service into the area of ordinary crime.
MI5 is not under the same restraints as the police. They infiltrate
organisations, people's jobs and lives. They operate almost like a cancer."
 
"At the moment the acorn of a Stasi [the former East German communists'
secret service] has been planted. It is there for future governments to
build on."
 
The message is clear. Criminal subversion and criminal harassment by an
unpoliced minority not subject to the law, "infiltration of people's jobs
and lives" is with us today.

15702

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

Re: subprocess.popen question

[Gabriel Genellina]

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 in spe it 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

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

Re: Tailing a log file?

[Paul Rubin]

"Evan Klitzke" <[EMAIL PROTECTED]> writes:
> I checked the source code for tail and they actually poll the file by
> using fstat and sleep to check for changes in the file size. This
> didn't seem right so I thought about it more and realized I ought to
> be using inotify. So I guess I answered my own question.

If it's just one file, inotify is probably overkill.  I looked into
this recently and ended up just sleeping and trying to read the file
(not bothering with stat; just see if you get 0 bytes back from read).
-- 
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 Fri, 22 Jun 2007 13:54:35 -0400, Douglas Alan wrote:

>> Python already allows me to shoot myself in the foot, if I wish. I'm 
>> comfortable with that level of freedom. I'm not necessarily comfortable 
>> with extensions to the language that would allow me the freedom to shoot 
>> myself in the head.
> 
> Lisp macros don't let you shoot yourself in the head -- only in the
> foot.  Being able to do
> 
>True = False
> 
> is being able to shoot yourself in the head.  And Python certainly
> lets you do that.

True, that is a current piece of badness. There are arguments for and
against making True and False reserved words, like None.

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

 
>> I would need to be convinced of the advantages, as would many other
>> people, including the BDFL.
> 
> 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.

I don't accept Graham's reasoning.

I think that it is true that people's *values* change, as they get more
familiar with a more powerful language. For instance, I used to write
Pascal code on a Mac, and I avoided object-oriented techniques because
they were too inefficient and slow. (E.g. when Apple released System
7, which used OO code extensively, even the most one-eyed Mac fan boys
had to admit that the Finder ran like a dog compared to System 6.) But the
advantages were obvious, even before I had experience with OO design.

Now, I use Python, which is all object-oriented -- but the hardware I run
it on is so much faster that I care more about the programmer productivity
(my time) than about the efficiency of the executed code (the computer's
time). But if I were still running on a 1988-vintage Mac, you better believe I
wouldn't be making the same trade-offs I am now.

So, quite frankly, the things which you and Graham value in Lisp *simply
don't interest me*. It isn't that I can't see the advantages. They just
don't matter to me, in fact in some ways they are disadvantages.

Could my opinion ever change? Of course it could. I might, for example,
suddenly have a burning passion about language design, or find some
problem that is really painful under Python, and then I might go searching
for "a more powerful language". One doesn't need to be familiar with more
powerful languages to be aware that they offer benefits that less powerful
languages don't.

Or some really smart people might come up with a macro system that reduces
the disadvantages while keeping the advantages, and then dealing with
some random module developer's syntax extensions no more frightening than
dealing with some random module developer's functions.

(Considering the poor design and shoddy code of some modules I've had to
deal with, I really worry about giving developers the ability to redefine
syntax too.)

[snip]


>> let alone whether the benefits would outweigh the costs,
> 
> They pay off in boatloads in the Lisp community.

But do they? Where is the standard library containing all these
magnificent macros? Forcing people to implement basic things from scratch
doesn't sound like a pay-off to me.

It seems that one of the major costs of having an extremely minimalist,
but easily extensible, syntax is that it encourages massive re-invention
of the wheel. Things get moved into the language slowly, because it is so
easy to work around the lack -- but the cost is a proliferation of
different macros all doing the same thing.

I think Python has the better philosophy. Python has one really good
syntax, minimalistic but not _overly_ minimalistic, not an easily
extensible syntax. The cost is that there are some things which could be
easier, if the syntax were different, but the benefit is that I don't have
to write syntax-extending macros, or debug them, or learn somebody else's.
Once every few years, Python introduces a new syntax, e.g. list
comprehensions, after much thought. That's better than every time I use a
different library or module.


-- 
Steven.

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

Re: Internationalised email subjects

[Gabriel Genellina]

En Fri, 22 Jun 2007 06:49:22 -0300, <[EMAIL PROTECTED]> escribió:

> I've tried removing the encode('GB2312') line, so the code looks like
> this:
>
> h = Header(subject, 'GB2312')
>
> However, this line still causes the following error message:
>
> Traceback (most recent call last):
> File "/home/web88/html/app/sendmail.py", line 314, in
> h = Header(subject, 'GB2312')
> File "/usr/lib/python2.2/email/Header.py", line 188, in __init__
> self.append(s, charset, errors)
> File "/usr/lib/python2.2/email/Header.py", line 272, in append
> ustr = unicode(s, incodec, errors)
> LookupError: unknown encoding: gb2312 )

It appears that you don't have the gb2312 codec - maybe it was not  
available with your rather old Python version (2.2). Upgrading to a newer  
version may help.

-- 
Gabriel Genellina

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

Re: Error while installing Python2.5.1

[zaperaj]

In the Red Hat installation cd, i saw that there are four rpms for
gcc. Now what do i need to do?

-- 
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 Fri, 22 Jun 2007 13:21:14 -0400, Douglas Alan wrote:

> I.e., I could write a new object system for Lisp faster than I could
> even begin to fathom the internal of CPython.  Not only that, I have
> absolutely no desire to spend my valuable free time writing C code.
> I'd much rather be hacking in Python, thank you very much.

Which is very valuable... IF you care about writing a new object system. I
don't, and I think most developers don't, which is why Lisp-like macros
haven't taken off. I simply don't want to think about object syntax, I
just want it to work. I'm happy that Guido and the other Python-dev
people have thought about it, and come up with a good syntax, and are
conservative with their syntax changes. When I use somebody else's
library, I don't want to have to learn their syntax, no matter how cunning
they think it is.

The cost is that if I do have a brilliant new idea for syntax to Python,
it is hard for me to implement it. Nobody sensible denies that Python's
model is cost-free. But I think the cost is worth it, in the same way that
building houses out of bricks and mortar instead of plastic Lego blocks
makes it really hard to redesign the layout of rooms in the house, but has
other advantages.

(Don't over-analyze the analogy. I'm not suggesting Lisp code is
necessarily as fragile and easy to break as a house made of Lego would be,
or that Python code is safe as houses.)


-- 
Steven.

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

Re: Adding method to a class on the fly

[Steven D'Aprano]

On Fri, 22 Jun 2007 14:44:54 -0700, John Henry wrote:

> The above doesn't exactly do I what need.  I was looking for a way to
> add method to a class at run time.
> 
> What does work, is to define an entire sub-class at run time.  Like:
> 
> class DummyParent:
> def __init__(self):
> return
> 
> def method_static(self, text):
> print text
> return
> 
> text = "class Dummy(DummyParent):"
> text += "\n\t" + "def __init(self):"
> text += "\n\t" + "\tDummyParent.__init__(self)"
> text += "\n\t" + "def method_dynamic(self):"
> text += "\n\t" + "\tself.method_static(\"it's me\")"
> 
> exec text

(By the way, you misspelled __init__.)

The correct way to add methods to an instance is with the
instancemethod() function.


class Parrot:
def __init__(self):
import new
# define a function
def method_dynamic(self, *args):
args.insert(0, "hello, it's me!")
return self.method_static(*args)
# convert it into an instance method
method = new.instancemethod(function, self, self.__class__)
# add it to self
self.method_dynamic = method
def method_static(self, text):
return text


And here is how I use it:

>>> p = Parrot()
>>> p.method_dynamic()  # call from an instance
"it's me"
>>> Parrot.method_dynamic  # does it exist in the class?
Traceback (most recent call last):
  File "", line 1, in ?
AttributeError: class Parrot has no attribute 'method_dynamic'


BUT, having said all that, are you sure this is what you want to do? This
is probably a better way to get the same results:

class Parrot:
def __init__(self):
self.text = "hello, it's me!"
def method_dynamic(self):
return self.method_static(self.text)
def method_static(self, text):
return text


Earlier in the thread, you said you wanted a CLASS method, which is very
different. You can use the classmethod built-in function (no need to
import new) to create class methods:

class Parrot:
def method_dynamic(cls):
return cls.method_static(cls(), "hello it's me")
# or alternatively cls().method_static("hello it's me")
method_dynamic = classmethod(method_dynamic)
def method_static(self, text):
return text

Note: if you are using recent versions of Python, instead of saying
"method = classmethod(method)" AFTER the block, you can use a decorator
before the block.

Making method_dynamic a class method and calling an instance method is not
a good way of doing things, since the class method has to create a new
instance before calling method_static, only to throw it away afterwards.
That is wasteful and could be very expensive.

A better way is to change your class so that method_static is a class
method too, especially since it doesn't use self:

class Parrot:
@classmethod
def method_dynamic(cls):
return cls.method_static("hello it's me")
@classmethod
def method_static(cls, text):
return text

(Actually, since method_static doesn't even use the class, you could use
staticmethod instead of classmethod. Remember to remove the "cls" argument.)

Hope this helps,


-- 
Steven.

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

Weekly Python Patch/Bug Summary

[Kurt B. Kaiser]

Patch / Bug Summary
___

Patches :  385 open (+21) /  3790 closed (+21) /  4175 total (+42)
Bugs: 1029 open (+43) /  6744 closed (+43) /  7773 total (+86)
RFE :  262 open ( +4) /   291 closed ( +4) /   553 total ( +8)

New / Reopened Patches
__

syslog syscall support for SysLogLogger  (2007-05-02)
   http://python.org/sf/1711603  reopened by  luke-jr

syslog syscall support for SysLogLogger  (2007-05-02)
   http://python.org/sf/1711603  reopened by  luke-jr

syslog syscall support for SysLogLogger  (2007-05-02)
   http://python.org/sf/1711603  reopened by  luke-jr

syslog syscall support for SysLogLogger  (2007-05-02)
   http://python.org/sf/1711603  reopened by  luke-jr

dict size changes during iter  (2007-05-24)
   http://python.org/sf/1724999  opened by  Ali Gholami Rudi

Line ending bug SimpleXMLRPCServer  (2007-05-24)
   http://python.org/sf/1725295  opened by  bgrubbs

IDLE - cursor color configuration bug  (2007-05-25)
   http://python.org/sf/1725576  opened by  Tal Einat

Distutils default exclude doesn't match top level .svn  (2007-05-25)
   http://python.org/sf/1725737  opened by  Petteri Räty

ftplib.py: IndexError in voidresp occasionally  (2007-05-26)
   http://python.org/sf/1726172  opened by  kxroberto

Patch to vs 2005 build  (2007-05-26)
   http://python.org/sf/1726195  opened by  Joseph Armbruster

Windows Build Warnings  (2007-05-26)
   http://python.org/sf/1726196  opened by  Joseph Armbruster

Line iteration readability  (2007-05-26)
   http://python.org/sf/1726198  opened by  Joseph Armbruster

SimpleHTTPServer extensions_map  (2007-05-26)
   http://python.org/sf/1726208  opened by  Joseph Armbruster

ftplib and ProFTPD NLST 226 without 1xx response  (2007-05-27)
   http://python.org/sf/1726451  opened by  Kenneth Loafman

First steps towards new super (PEP 367)  (2007-05-28)
CLOSED http://python.org/sf/1727209  opened by  Guido van Rossum

move intern to sys, make intern() optionally warn  (2007-05-31)
   http://python.org/sf/1728741  opened by  Anthony Baxter

IDLE - configDialog layout cleanup  (2007-06-03)
   http://python.org/sf/1730217  opened by  Tal Einat

telnetlib: A callback for monitoring the telnet session  (2007-06-04)
   http://python.org/sf/1730959  opened by  Samuel Abels

BufReader, TextReader for PEP 3116 "New I/O"  (2007-06-04)
   http://python.org/sf/1731036  opened by  Ilguiz Latypov

Pruning threading.py from asserts  (2007-06-05)
CLOSED http://python.org/sf/1731049  opened by  Björn Lindqvist

Expect skips by platform  (2007-06-04)
   http://python.org/sf/1731169  opened by  Matt Kraai

Missing Py_DECREF in pysqlite_cache_display  (2007-06-05)
CLOSED http://python.org/sf/1731330  opened by  Tim Delaney

Improve doc for time.strptime  (2007-06-05)
   http://python.org/sf/1731659  opened by  Björn Lindqvist

urllib.urlretrieve/URLopener.retrieve - 'buff' argument  (2007-06-05)
   http://python.org/sf/1731720  opened by  Dariusz Suchojad

Document the constants in the socket module  (2007-06-06)
   http://python.org/sf/1732367  opened by  Björn Lindqvist

Allow T_LONGLONG to accepts ints  (2007-06-09)
CLOSED http://python.org/sf/1733960  opened by  Roger Upole

_lsprof.c:ptrace_enter_call assumes PyErr_* is clean  (2007-06-09)
   http://python.org/sf/1733973  opened by  Eyal Lotem

PY_LLONG_MAX and so on  (2007-06-09)
CLOSED http://python.org/sf/1734014  opened by  Hirokazu Yamamoto

Fast path for unicodedata.normalize()  (2007-06-10)
   http://python.org/sf/1734234  opened by  Rauli Ruohonen

patch for bug 1170311 "zipfile UnicodeDecodeError"  (2007-06-10)
   http://python.org/sf/1734346  opened by  Alexey Borzenkov

platform.py patch to support turbolinux  (2007-06-11)
CLOSED http://python.org/sf/1734945  opened by  Yayati_Turbolinux

Fix selectmodule.c compilation on GNU/Hurd  (2007-06-11)
   http://python.org/sf/1735030  opened by  Michael Banck

Kill StandardError  (2007-06-12)
CLOSED http://python.org/sf/1735485  opened by  Collin Winter

asyncore should handle also ECONNABORTED in recv  (2007-06-12)
   http://python.org/sf/1736101  opened by  billiejoex

asyncore/asynchat patches  (2007-06-12)
   http://python.org/sf/1736190  opened by  Josiah Carlson

EasyDialogs patch to remove aepack dependency  (2007-06-15)
   http://python.org/sf/1737832  opened by  has

help() can't find right source file  (2007-06-15)
   http://python.org/sf/1738179  opened by  Greg Couch

Add a -z interpreter flag to execute a zip file  (2007-06-19)
   http://python.org/sf/1739468  opened by  andy-chu

zipfile.testzip() using progressive file reads  (2007-06-19)
   http://python.org/sf/1739648  opened by  Grzegorz Adam Hankiewicz

Patch inspect.py for IronPython / Jython Compatibility  (2007-06-19)
   http://python.org/sf/1739696  opened by  Mike Foord

Accelerate attr dict lookups  (2007-06-19)
   http:

MI5 Persecution: A new Kafka? 3/10/95 (5104)

[MI5Victim]

Newsgroups: uk.misc,soc.culture.british,uk.media,uk.politics
From: [EMAIL PROTECTED] (Dick Jackson)
Subject: Re: What it's like to be watched by the security services
Message-ID: <[EMAIL PROTECTED]>
Sender: [EMAIL PROTECTED] (Usenet Admin)
Nntp-Posting-Host: soldev
Organization: Citicorp-TTI at Santa Monica (CA) by the Sea
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Date: Fri, 13 Oct 1995 22:53:12 GMT
Lines: 34

In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] (Mike Corley) writes:
>
>Strangers in the street have recognized me on sight many times, and shown
>awareness of the current thread of abuse. To give you one example, in 1992
>I was seriously ill, and a manager at work somewhat humouroursly said that
>"it wasn't fair" that people were bullying me. A few days later, I
>attended for the first time a clinic in London as an outpatient, and on my
>way out was accosted by someone who asked if "they had paid my fare", with
>emphasis on the word "fare". He repeated the word several times in this
>different context;  that they should have paid my "fare", each time
>emphasising the word. 
>
>For two and a half years from the time their harassment started until
>November 1992 I refused to see a psychiatrist, because I reasoned that I
>was not ill of my own action or fault, but through the stress caused by
>harassment, and that a lessening of the illness would have to be
>consequent to a removal of its immediate cause, in other words a cessation
>of harassment. I also reasoned that since they were taunting me with jokes
>about mental illness, if I were to seek treatment then the abusers would
>think that they had "won" and been proved "right".



I have so far not contributed to this tread, it has been unpleasant
in my opinion. However, I was struck by the resemblance of the above
passages to the writing of Franz Kafka.

Viz. while from an objective viewpoint it seems to refer to a abnormal
world, in a strange way it does resonate strongly at other levels.

Mr. Corley, have you tried to write for publication? I honestly think
it might lead somewhere positive.

Dick Jackson (serious for a change and expecting to get beaten up)

5104

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

Re: The Modernization of Emacs

[David Golden]

Twisted wrote:

> If I sit down at a windows text editor (or 
> even kwrite or similar) I can just focus on the job. Faced with emacs
> or most other text-mode editors (but not MS-DOS Edit, interestingly)
> the editor keeps intruding on my focus. Oops.
> 

"emacs or most other text-mode editors" sounds very much like you
believe emacs works in a pure text mode too?  It can, of course, and
that's a good thing, but that's certainly not how I usually use it -
it has a GUI, you know.


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

Re: Adding method to a class on the fly

[James Stroud]

John Henry wrote:
> Hi list,
> 
> I have a need to create class methods on the fly.  For example, if I
> do:
> 
> class Dummy:
> def __init__(self):
> exec '''def method_dynamic(self):\n\treturn
> self.method_static("it's me")'''
> return
> 
> def method_static(self, text):
> print text
> return

Where is the text for the exec statement coming from? A file? User 
input? What you are doing above makes absolutely no sense. You confuse 
everyone who attempts to understand what you want to do with the above 
because no one in his right mind would do anything like it.

> I like that to be the same as:
> 
> class Dummy:
> def __init__(self):
> return
> 
> def method_dynamic(self):
> return self.method_static("it's me")
> 
> def method_static(self, text):
> print text
> return

Are you looking to fill in text and create new methods for Dummy based 
on the text and method_static() such that these will become true 
instance methods for instances of Dummy?

def add_dynamic(cls_name, f, name, *args, **kwargs):
   cls = globals()[cls_name]
   def _f(self):
 return getattr(cls, f)(self, *args, **kwargs)
   setattr(cls, name, _f)

e.g.

py> class Dummy:
...  def method_static(self, text):
... print text
... return
...
py> def add_dynamic(cls_name, f, name, *args, **kwargs):
...   cls = globals()[cls_name]
...   def _f(self):
... return getattr(cls, f)(self, *args, **kwargs)
...   setattr(cls, name, _f)
...
py> add_dynamic('Dummy', 'method_static', 'method_dynamic', 'abc xyz')
py> Dummy.method_dynamic

py> d = Dummy()
py> d.method_dynamic()
abc xyz

Note that this is "completely dynamic" in that all arguments to 
add_dynamic() are strings. This may or may not be what you want--in such 
a case, you will want to study the code to see how it works and fix it 
yourself. Note also that methods added to classes after instances are 
made will be available to said instances:


py> add_dynamic('Dummy', 'method_static', 'method2_dynamic', 'asdf jkl')
py> d.method2_dynamic()
asdf jkl


> so that I can do:
> 
> dum=Dummy.method_dynamic()

Here you confuse everyone. This last line is not the same as you 
describe in the above example. Here you imply the dynamic creation of a 
"static method" (not a "method_static"--don't be confused by the names 
you invent as they may already have a meaning to everyone else). Static 
methods are different from unbound class methods that are later bound to 
instances of a class upon instantiation.

Here is an analagous solution for static methods:


def add_static(cls_name, f, name, *args, **kwargs):
   cls = globals()[cls_name]
   def _f():
 return getattr(cls, f)(*args, **kwargs)
   setattr(cls, name, staticmethod(_f))

class Dummy:
   @staticmethod
   def method_static(text):
 print text


e.g.:


py> def add_static(cls_name, f, name, *args, **kwargs):
...   cls = globals()[cls_name]
...   def _f():
... return getattr(cls, f)(*args, **kwargs)
...   setattr(cls, name, staticmethod(_f))
...
py> class Dummy:
...   @staticmethod
...   def method_static(text):
... print text
...
py> add_static('Dummy', 'method_static', 'real_static', 'aaa bbb')
py> Dummy.real_static

py> Dummy.real_static()
aaa bbb



Again, this will do what you want, but if it doesn't do *exactly* what 
you want, you need to study and modify the code. Also, creating static 
methods from unbound methods requires trickery. If this is what you 
want, you should be very clear about it.


> and see "it's me" printed.
> 
> Can that be done?


Yes. Anything is possible with python. That's why I use it.


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

Re: Adding method to a class on the fly

[James Stroud]

7stud wrote:
> On Jun 22, 3:23 pm, askel <[EMAIL PROTECTED]> wrote:
> 
>>sorry, of course last line should be:
>>Dummy().method2('Hello, world!')
> 
> 
> ..which doesn't meet the op's requirements.
> 

Which were contradictory.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: is this a valid import sequence ?

[Steven D'Aprano]

On Fri, 22 Jun 2007 21:43:40 +0200, Stef Mientki wrote:

> This might be a very weird construction,
> but it's the most easy way in translating another language into Python (for 
> simulation).
> 
> Although it works, I like to know if this a valid construction:

Since it works, how can it NOT be a valid construction?

However, using global variables is almost always a bad idea. Passing
parameters around is really cheap in Python, that's almost always a better
solution.


-- 
Steven.

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

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

[Steven D'Aprano]

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. 

Follow-ups set to comp.lang.python.



-- 
Steven.

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

Re: Collections of non-arbitrary objects ?

[walterbyrd]

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.

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

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

[Alan Isaac]

Not Python, but maybe relevant:
http://www.scriptaworks.com/cgi-bin/wiki.sh/NoSQL/HomePage

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

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

[felciano]

>
> i don't think that using flat text files as a database is common these
> days. if you need relational database features what stops you from
> using rdbms? if the only reason for that is some legacy system then
> i'd still use in-memory sqlite database for all relational operations.
> import, process, export back to text if you need to.
>
These are often one-off operations, so those import + export steps are
non-trivial overhead. For example, most log files are structured, but
it seems like we still use scripts or command line tools to find data
in those files. I'm essentially doing the same thing, only with
operations across multiple files (e.g. merge records these two files
based on a common key, or append a column based on a look up value). I
may end up having to go to DB, but that seems like a heavyweight jump
for what are otherwise simple operations.

Maybe this is the wrong forum for the question. I prefer programming
in Python, but the use cases I'm looking is closer to shell scripting.
I'd be perfectly happy with a more powerful version of GNU textutils
that allowed for greater flexibility in text manipulation.

HTH,

Ramon

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

Re: configparser shuffles all sections ?

[Fuzzyman]

On Jun 23, 1:14 am, Fuzzyman <[EMAIL PROTECTED]> wrote:
> On Jun 22, 8:28 pm, Stef Mientki <[EMAIL PROTECTED]>
> wrote:
>
>
>
> > Nick Craig-Wood wrote:
> > > stef <[EMAIL PROTECTED]> wrote:
> > >>  I just used configparser for the first time and discovered that it
> > >>  shuffled all my sections,
> > >>  and the contents of the sections too.
>
> > >>  This makes human manipulation of the file impossible.
>
> > >>  Is there a way to prevent this shuffling,
>
> > > You could try getting yourself an ordered dictionary implmentation,
> > > say
>
> > >  http://www.voidspace.org.uk/python/odict.html
>
> > > Then doing something like this (untested)
>
> > > class MyConfigParser(SafeConfigParser):
> > > def __init__(self, defaults=None):
> > > SafeConfigParser.__init__(defaults)
> > > self._sections = odict()
> > > self._defaults = odict()
>
> > This might be good alternative,
> > I'll check that.
>
> > thank you all for the answers,
> > it's always good to know that I've not missed the simple solution ;-)
>
> There's one simple solution - ConfigObj.
>
> It is a config file reader and preserves order:
>
> http://www.voidspace.org.uk/python/configobj.html
>
> Fuzzyman

Oh - and as a bonus, it preserves comments.


http://www.ironpython.info
>
>
>
> > cheers,
> > Stef Mientki


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

Re: configparser shuffles all sections ?

[Fuzzyman]

On Jun 22, 8:28 pm, Stef Mientki <[EMAIL PROTECTED]>
wrote:
> Nick Craig-Wood wrote:
> > stef <[EMAIL PROTECTED]> wrote:
> >>  I just used configparser for the first time and discovered that it
> >>  shuffled all my sections,
> >>  and the contents of the sections too.
>
> >>  This makes human manipulation of the file impossible.
>
> >>  Is there a way to prevent this shuffling,
>
> > You could try getting yourself an ordered dictionary implmentation,
> > say
>
> >  http://www.voidspace.org.uk/python/odict.html
>
> > Then doing something like this (untested)
>
> > class MyConfigParser(SafeConfigParser):
> > def __init__(self, defaults=None):
> > SafeConfigParser.__init__(defaults)
> > self._sections = odict()
> > self._defaults = odict()
>
> This might be good alternative,
> I'll check that.
>
> thank you all for the answers,
> it's always good to know that I've not missed the simple solution ;-)


There's one simple solution - ConfigObj.

It is a config file reader and preserves order:

http://www.voidspace.org.uk/python/configobj.html

Fuzzyman
http://www.ironpython.info

>
> cheers,
> Stef Mientki


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

Re: The Modernization of Emacs

[Matthias Buelow]

Twisted wrote:

> I find these anecdotes liberally sprinkled into this thread frankly
> unbelievable.

If you'd spent as much time learning the software as you're ranting
about it, you could actually use it _and_ would get the additional
benefit of having avoided making a fool of yourself on Usenet. Of course
that would have been too easy, wouldn't it?
-- 
http://mail.python.org/mailman/listinfo/python-list

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

[Paul Rubin]

Douglas Alan <[EMAIL PROTECTED]> writes:
> People (myself included) haven't had much trouble implementing nice
> and useful macro packages for Lisp.  Admittedly, it's a harder problem
> for a language that doesn't have a Lisp-like syntax.

One very simple hack would be to define a syntax extension like

   f.(arg1,arg2,arg3)

to compile f's args into unevaluated thunks passed into f, instead of
evaluating them as expressions before calling f.  That could replace
macros and syntax extensions in some circumstances.  For example the
famous ternary operator would just be

def ternary(cond, a, b): 
   if cond(): return a()
   else: return b()

Then you'd write, e.g.

selection = ternary.(x > y, exp1, exp2)

without worrying about side effects of exp1 and exp2 both getting
evaluated.

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

contextlib.closing annoyance

[Paul Rubin]

it looks like contextlib.closing fails to be idempotent,
i.e. wrapping closing() around another closing() doesn't work.

This is annoying because the idea of closing() is to let you
use legacy file-like objects as targets of the "with" statement,
e.g.

with closing(gzip.open(filename)) as zf: ...

but what happens if the gzip library gets updated the dumb way to
support the enter and exit methods so you don't need the explicit
closing call any more?  The dumb way of course is to just call
closing() inside the library.  It seems to me that 
closing(closing(f)) ought to do the same thing as closing(f).

Let me know if I'm overlooking something.  I'm thinking of submitting
an RFE.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The Modernization of Emacs: terminology buffer and keybinding

[Cor Gest]

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

> On Jun 22, 6:32 pm, Cor Gest <[EMAIL PROTECTED]> wrote:
> > > 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?!
> >
> > What's your problem ?
> >
> > Ofcourse a mere program-consumer would not look what was being
> > installed on his/her system in the first place ...
> > So after some trivial perusing what was installed and where :
> >  WOW Look, MA !  it's all there!
> >
> > lpr /usr/local/share/emacs/21.3/etc/refcard.ps
> > or your install-dir^^
> > or your version.^
> 
> So now we're expected to go on a filesystem fishing expedition instead
> of just hit F1? One small step (backwards) for a man; one giant leap
> (backwards) for mankind. :P

that's  M-` Escape-Backtick in a CLI, for you, thank you very much ... 
Function-Keys  do not work in in a vt100 terminal.

You really are that shallow, aren't you ? and lazy too, huh ?

> copyright and not copyleft, so much for the "free as in speech" too,
> and nevermind the "free as in beer".
Download & print the junk then.
Ofcourse you pay your ISP for the priviledge & give some treehuggers a
nervous brakedown in the process.
 
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: Portable general timestamp format, not 2038-limited

[Paul Rubin]

James Harris <[EMAIL PROTECTED]> writes:
> I have a requirement to store timestamps in a database. Simple enough
> you might think but finding a suitably general format is not easy. The
> specifics are
> 
> 1) subsecond resolution - milliseconds or, preferably, more detailed
> ...

There are subtle issues that have been messed up many times.  See:

  http://cr.yp.to/time.html

particularly the TAI stuff for some info.
-- 
http://mail.python.org/mailman/listinfo/python-list

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

[Douglas Alan]

"Terry Reedy" <[EMAIL PROTECTED]> writes:

> "Douglas Alan" <[EMAIL PROTECTED]> wrote in message 

> | "Terry Reedy" <[EMAIL PROTECTED]> writes:

> | > I think this points to where Sussman went wrong in his footnote
> | > and Alan in his defense thereof.  Flexibility of function --
> | > being able to do many different things -- is quite different
> | > from flexibility of syntax

> | I think you are setting up a false dichotomy.

> I think this denial of reality is your way of avoiding admitting, perhaps 
> to yourself, that your god Sussman made a mistake.

Sussman isn't my god -- Kate Bush is.

Just because I'm right and you're wrong, doesn't mean that I'm in
denial.  It is you who are in denial if you believe that syntax is
unimportant, as long as one is provided the required functionality.
In fact, that's stereotypical Computer Science denial.  Computer
Science academics will typically state as a truism that semantics are
what is important and syntax is just a boring trifle in comparison.
But time and time again, you'll see programming languages succeed or
fail more on their syntax than on their semantics.  And issues of
syntax is often where you see the most inflamed debates.  Just look at
all the flames one used to hear about Python using whitespace
significantly.  Or all the flames that one will still hear about Lisp
using a lot of parentheses.

You seem oblivious to the fact that one of the huge benefits of Python
is its elegant and readable syntax.  The problem with not having a
"flexible syntax", is that a programming language can't provide
off-the-shelf an elegant syntax for all functionality that will ever
be needed.  Eventually programmers find themselves in need of new
elegant functionality, but without a corresponding elegant syntax to
go along with the new functionality, the result is code that does not
look elegant and is therefore difficult to read and thus maintain.

Consequently, "flexibility of function" is often moot without
"flexibility of syntax".  I don't know how I can make it any clearer
than this.  I'm sorry if you don't understand what I am saying, but
just because you don't understand, or if you do, that you don't agree,
doesn't mean that I don't have a reasoned and reasonable point of
view.

> | One that is related to the false unification that annoying people
> | used to always make when they would perpetually argue that it
> | wasn't important which programming language you programmed in, as
> | they are all Turing equivalent anyway.  Well, I sure as hell don't
> | want to write all my programs for a Turning machine, and a Turing
> | machine is certainly Turing equivalent!

> Diversionary crap unrelated to the previous discussion.

Take the issue up with Paul Graham.  Since making a fortune developing
software in Lisp (making heavy use of macros), he now has much more
free time to write essays defending the truth than I do:

   http://www.paulgraham.com/avg.html

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

Re: Packing a simple dictionary into a string - extending struct?

[Jonathan Fine]

John Machin wrote:

> def unpack(bytes, unpack_entry=unpack_entry):
> '''Return dictionary gotten by unpacking supplied bytes.
> Both keys and values in the returned dictionary are byte-strings.
> '''
> bytedict = {}
> ptr = 0
> while 1:
> key, val, ptr = unpack_entry(bytes, ptr)
> bytedict[key] = val
> if ptr == len(bytes):
> break
> # That's beautiful code -- as pretty as a cane-toad.

Well, it's nearly right.  It has a transposition error.

> # Well-behaved too, a very elegant response to unpack(pack({}))

Yes, you're right.  An attempt to read bytes that aren't there.

> # Try this:
> blen = len(bytes)
> while ptr < blen:
> key, val, ptr = unpack_entry(bytes, ptr)
> bytedict[key] = val
> 
> return bytedict

I've committed such a change.  Thank you.

-- 
Jonathan



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

Re: newb: Scope Question

[attn . steven . kuo]

On Jun 22, 3:53 pm, johnny <[EMAIL PROTECTED]> wrote:
> Scope of ids:
> When I print "ids", it's always empty string '', as I have intialized
> before.  That's not what I want. I want the ids to have
> str(r['id']).join(',')
>
> if res:
> ids = ''
> for r in res['key']:
> ids = str(r['id']).join(',')
>
> print("ids: %s" %(ids))




"""
1.  You haven't posted enough code to allow someone else to reproduce
the problem.

2.  Are you sure that res['key'] isn't an empty sequence?

3.  The 'join' operation looks funny.  The syntax is
.join().  Since ',' is a sequence of length
one, you'll get, if anything, a comma (',') as the value of ids.
"""

res = { 'key': [dict(id=value) for value in range(10)] }

if res:
ids = ''
for r in res['key']:
ids = str(r['id']).join(',')
print ("ids : %s" % (ids))


# Wild guess -- perhaps you really wanted:


if res:
ids = ','.join(str(r['id']) for r in res['key'])
print "ids : %s" % ids


--
Hope this helps,
Steven

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

SIMD powered Python

[Bytter]

Hi!

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

Best regards,

Hugo Ferreira

--

[1] http://en.wikipedia.org/wiki/SIMD
[2] http://en.wikipedia.org/wiki/Streaming_SIMD_Extensions

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

Re: The Modernization of Emacs

[Lew]

Twisted wrote:
> 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, or someone somewhere is simply lying. 

So if someone provides evidence with which you disagree, you accuse them of 
lying.

There's no opportunity for reasoned discourse in the face of such tactics.  Or 
room for new information to combat one's prejudices.

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

Re: The Modernization of Emacs: terminology buffer and keybinding

[nebulous99]

On Jun 22, 6:32 pm, Cor Gest <[EMAIL PROTECTED]> wrote:
> > 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?!
>
> What's your problem ?
>
> Ofcourse a mere program-consumer would not look what was being
> installed on his/her system in the first place ...
> So after some trivial perusing what was installed and where :
>  WOW Look, MA !  it's all there!
>
> lpr /usr/local/share/emacs/21.3/etc/refcard.ps
> or your install-dir^^
> or your version.^

So now we're expected to go on a filesystem fishing expedition instead
of just hit F1? One small step (backwards) for a man; one giant leap
(backwards) for mankind. :P

> But then again buying the GNU-book from 'O Reilly would have solved it
> in the utmost nicest possible of ways anyway.

So much for the "free" in "free software". If you can't actually use
it without paying money, whether for the software or for some book, it
isn't really free, is it? The book assumes the role of a copy
protection dongle*. Of course, if the book is under the usual sort of
copyright and not copyleft, so much for the "free as in speech" too,
and nevermind the "free as in beer".

* In fact, I not-too-fondly remember the days when a common copy
protection scheme was for software to periodically (or at least on
startup) insist that the user enter the first word on page N of the
manual, for various changing choices of N. Making the interface simply
unnavigable without the manual strikes me as nearly as effective. If
someone did decide to intentionally cripple the interface of some
"free" software and make a killing off a book de-facto required to use
it, it would be quite the racket. I hope the open source movement
would chew them to pieces and curse them in public though.

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

Re: newb: Scope Question

[James Stroud]

johnny wrote:
> Scope of ids:
> When I print "ids", it's always empty string '', as I have intialized
> before.  That's not what I want. I want the ids to have
> str(r['id']).join(',')
> 
> if res:
> ids = ''
> for r in res['key']:
> ids = str(r['id']).join(',')
> 
> print("ids: %s" %(ids))
> 

1. You do not need to "initialize" ids.
2. It looks as if res['key'] is empty.
3. Are you sure you don't mean "res[key]"?
4. "ids" and "(ids)" are equivalent.
5. Are you sure you don't want to indent the print statement?

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

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

[Terry Reedy]

"Douglas Alan" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
| "Terry Reedy" <[EMAIL PROTECTED]> writes:
| > I think this points to where Sussman went wrong in his footnote and
| > Alan in his defense thereof.  Flexibility of function -- being able
| > to do many different things -- is quite different from flexibility
| > of syntax
|
| I think you are setting up a false dichotomy.

I think this denial of reality is your way of avoiding admitting, perhaps 
to yourself, that your god Sussman made a mistake.

| One that is related to
| the false unification that annoying people used to always make when
| they would perpetually argue that it wasn't important which
| programming language you programmed in, as they are all Turing
| equivalent anyway.  Well, I sure as hell don't want to write all my
| programs for a Turning machine, and a Turing machine is certainly
| Turing equivalent!

Diversionary crap unrelated to the previous discussion.

Bye.



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

ANN: Urwid 0.9.8.1 - Console UI Library

[Ian Ward]

Announcing Urwid 0.9.8.1
--

Urwid home page:
   http://excess.org/urwid/

Tarball:
   http://excess.org/urwid/urwid-0.9.8.1.tar.gz

RSS:
   http://excess.org/feeds/tag/urwid/


About this release:
===

This is a maintenance release that fixes a number of bugs that have been 
found in 0.9.8.


New in this release:


  * Fixed a Filler render() bug

  * Fixed a raw_display start()/stop() bug

  * Fixed a number of problems triggered by very small terminal window
sizes.


About Urwid
===

Urwid is a console UI library for Python. It features fluid interface
resizing, UTF-8 support, multiple text layouts, simple attribute markup,
powerful scrolling list boxes and flexible interface design.

Urwid is released under the GNU LGPL.




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

newb: Scope Question

[johnny]

Scope of ids:
When I print "ids", it's always empty string '', as I have intialized
before.  That's not what I want. I want the ids to have
str(r['id']).join(',')

if res:
ids = ''
for r in res['key']:
ids = str(r['id']).join(',')

print("ids: %s" %(ids))

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

Re: Adding method to a class on the fly

[attn . steven . kuo]

On Jun 22, 2:44 pm, John Henry <[EMAIL PROTECTED]> wrote:
> On Jun 22, 2:28 pm, askel <[EMAIL PROTECTED]> wrote:
>

(snipped)

>
> The above doesn't exactly do I what need.  I was looking for a way to
> add method to a class at run time.


I'm not sure what you mean by this.  Bind an attribute -- a method --
to class Dummy if and only if an instance of this class is created?



> What does work, is to define an entire sub-class at run time.  Like:
>
> class DummyParent:
> def __init__(self):
> return
>
> def method_static(self, text):
> print text
> return
>
> text = "class Dummy(DummyParent):"
> text += "\n\t" + "def __init(self):"
> text += "\n\t" + "\tDummyParent.__init__(self)"
> text += "\n\t" + "def method_dynamic(self):"
> text += "\n\t" + "\tself.method_static(\"it's me\")"
>
> exec text
>
> dum=Dummy().method_dynamic()
>
> Thanks again.


I tend to avoid exec if possible.  Also, you
seem to be a bit inexact with regard to the
term "static".


class Dummy(object):
def __init__(self):
new_method_name = 'method_dynamic'
try:
getattr(Dummy, new_method_name)
except AttributeError:
print "Creating an instance method..."
def newf(self):
"""Something Descriptive Here"""
return self.method_static("it's me")
newf.__name__ = new_method_name
setattr(Dummy, new_method_name, newf)
def method_static(self, text):
"""I hate this name.  Do not confuse this with a staticmethod;
what you probably meant was that this is an attribute (a
method)
bound within the class body as opposed to elsewhere"""
print text
return # is this necessary?

d1 = Dummy()
d1.method_dynamic()
d2 = Dummy()
d2.method_dynamic()
print d1.method_dynamic.im_func.__name__
print d1.method_dynamic.im_func.__dict__
print d1.method_dynamic.im_func.__doc__
print d1.method_dynamic.im_func.__module__
print d1.method_dynamic.im_self

--
Hope this helps,
Steven

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

Re: Portable general timestamp format, not 2038-limited

[Roger Miller]

On Jun 22, 10:33 am, James Harris <[EMAIL PROTECTED]>
wrote:
> I have a requirement to store timestamps in a database. Simple enough
> you might think but finding a suitably general format is not easy.
> ...
> Any thoughts on a better way to do this? (Please reply-all. Thanks).
>
> --
> James


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.

- Roger

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

Re: The Modernization of Emacs

[nebulous99]

On Jun 21, 10:48 am, Lew <[EMAIL PROTECTED]> wrote:
> Bjorn Borud <[EMAIL PROTECTED]> writes:
> >> so if the context was system administration, I'd vote for vi as
> >> well. if the context was programming I'd vote Emacs.
> David Kastrup wrote:
> > You know you can use something like
> > C-x C-f /su::/etc/fstab RET
> > (or /sudo::/etc/fstab) in order to edit files as root in a normal
> > Emacs session?
>
> I've been using emacs for something like twenty years and never knew that 
> before.
>
> I like the built-in therapist in emacs.

I think both of Lew's sentences here speak volumes.

One about the difficulty even supposed expert users can have with
tasks and finding things out from the help system. (I take it unix has
also still not caught up to the windows world in the concept of a "tip
of the day"?)

And both of them, though especially the latter, regarding what a
feeping creature emacs is. I don't suppose there's also a kitchen sink
in there somewhere? Or is that just nethack?

PS you'll have to stop posting such a high volume here. I'm getting BS
from Google Groups about posting limits being exceeded again.
Apparently they've lowered it still further, from 25 in a 24 hour
period to 12 or so in a 24 hour period. Fuckers.

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

Re: regular expression concatenation with strings

[oscartheduck]

Oh dear. I just want to make it clear I wasn't trying to take credit
for the change of extension to ext. I genuinely worked it out
independently and then rushed back and posted about it, but you
definitely worked it out and wrote it up first!

Sorry! And thanks for the help!!



James

On Jun 22, 4:07 pm, oscartheduck <[EMAIL PROTECTED]> wrote:
> Got it:
>
> #!/usr/bin/env python
> from PIL import Image
> import glob, os, re
>
> size = 128, 128
>
> def thumbnailer(dir, filenameRx):
>  for picture in [ p for p in os.listdir(dir) if
> os.path.isfile(os.path.join(
> dir,p)) and filenameRx.match(p) ]:
>  file, ext = os.path.splitext(picture)
>  im = Image.open (picture)
>  im.thumbnail(size, Image.ANTIALIAS)
>  im.save(file + ".thumbnail" + ext)
>
> jpg = re.compile(".*\.(jpg|jpeg)", re.IGNORECASE)
> thumbnailer(".", jpg)
>
> The answer was sitting in front of my eyes. What is your code doing?
> It looks like:
>
> for $foo in [current working directory]
> if $foo is a file
> and foo's name matches the regex


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

Re: The Modernization of Emacs: terminology buffer and keybinding

[Falcolas]

On Jun 22, 4:12 pm, Pascal Bourguignon <[EMAIL PROTECTED]> wrote:
> Anything that the user have to do repeatitively with the GUI, like
> copy-and-paste, or reformating of a lot of paragraphs or table
> entries, and which is done automatically by writting a one-liner
> program in emacs or shell.

So the tool they were using did not support macros? You're right, that
would suck. I'm guessing this is before you could expose the Unix
underpinnings on the mac.

I will agree that I do miss much of the standard shell utility when
working in windows. Fortunately, I am able to replace a lot of that
with well written python or perl scripts.

> And they tried to put graphical user interfaces on scripting, it
> doesn't work either.  Programming is working with text, with verbs.

Recording macros could be considered a form of programming, which can
have nothing to do with any text. Granted, they're pretty dumb if you
don't manually modify them, but really, nothing is stopping you from
modifying them either. I can't count the number of times I've created
a macro to do repeated modification of a text file.

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

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

Re: The Modernization of Emacs

[Twisted]

On Jun 22, 11:52 am, Bjorn Borud <[EMAIL PROTECTED]> wrote:
> [Martin Gregorie <[EMAIL PROTECTED]>]
> |
> | Yep, and the same people think a command line is to be avoided at all
> | costs. "I mean, its so /last century/ and you can't do anything useful
> | with it anyway".

I think a command line can be useful as a way to directly talk to
something's brain. More GUI apps should have a command processor you
can access to do something arcane once in a while. The other thing a
command processor is good for is providing automation support.

Windows is definitely weak on allowing things like editors to be
embedded and used as components by other applications. OLE makes it
theoretically possible to e.g. use Winword in an IDE but who'd want
to? It also doesn't provide a system-wide way to select particular
components to do particular jobs -- the closest thing would be
splitting comctl32.dll into separate dlls for each common task or
dialog and allowing third-party drop-in replacements to be found in a
user-specific directory that override the defaults. That sort of
modularity and choice is alien to MS thought patterns however.
Combining the flexibility of componentry in Unix with the graphical
power of Windows might lead to something awesome ... which makes KDE
and Gnome things to keep eyes on in the future.

> 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. If their attention keeps being dragged forcible from
THE JOB to THE TOOL and how to make this cantankerous thing do *this*?
then there is a problem. If I sit down at a windows text editor (or
even kwrite or similar) I can just focus on the job. Faced with emacs
or most other text-mode editors (but not MS-DOS Edit, interestingly)
the editor keeps intruding on my focus. Oops.

Elsewhere, you mentioned 3 second attention spans -- I think you'll
find people are much more willing to spend 3 hours of attention on
their task than 3 seconds on your favorite tool. When the tool
intrudes into the user's attention (either by misbehaving, e.g.
crashing, or by confounding the user as to how to do what they want to
do next), then a problem is evident.

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

Re: The Modernization of Emacs: terminology buffer and keybinding

[Cor Gest]

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

> On Jun 21, 12:03 pm, Robert Uhl <[EMAIL PROTECTED]> wrote:
> > Twisted <[EMAIL PROTECTED]> writes:
> >
> > >> Emacs is amazingly beginner-friendly for the power and flexibility it
> > >> provides. [snip]
> >
> > > That's a joke, right? I tried it a time or two. Every time it was
> > > rapidly apparent that doing anything non-trivial would require
> > > consulting a cheat sheet. The printed-out kind, since navigating to
> > > the help and back without already having the help displayed and open
> > > to the command reference was also non-trivial.
> >
> > C-h i, C-x b RET is non-trivial?!?
> 
> Let's change that so that you see it the way most human beings see it:
> 
> > > navigating to
> > > the help and back without already having the help displayed and open
> > > to the command reference was also non-trivial.
> 
> > Erh h, dhsd f hHE is non-trivial?
> 
> I'm sorry. I don't speak Chinese.
> 
> I trust I've made my point. Not only does it insist you learn a whole
> other language (though I'm guessing it's not actually Chinese --
> Greek, maybe), even when you know that's a bunch of keystrokes and
> even what they are...
> 
> 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?!

What's your problem ? 

Ofcourse a mere program-consumer would not look what was being
installed on his/her system in the first place ...
So after some trivial perusing what was installed and where :
 WOW Look, MA !  it's all there!
 
lpr /usr/local/share/emacs/21.3/etc/refcard.ps
or your install-dir^^
or your version.^

But then again buying the GNU-book from 'O Reilly would have solved it
in the utmost nicest possible of ways anyway.

Buying or printing the GNU-Emacs Reference Manual should do 
quit a memorable job also.

But then again there allways will be people that cannot find their way to
the outhouse even when it stinks a mile a minute. 

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: The Modernization of Emacs: terminology buffer and keybinding

[David Golden]

Twisted wrote:

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

WTF? Of course you can. http://oldr.net/emacs_two_frames.png

> I don't know why people keep harping about what version. 

Perhaps because essentially none of the crap you're spouting corresponds
to remotely recent versions of emacs they're are aware of.  I'd be
increasingly dubious much applies to any previous versions either.

If everyone had such bizarre problems you describe yourself as having
with emacs, well, nobody would be using it.  That is clearly not the
case.  Of course, no one's pointing a gun at you and making you use it,
either - if you like notepad or joe or whatever, just use them instead.











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

Re: The Modernization of Emacs: terminology buffer and keybinding

[Pascal Bourguignon]

Twisted <[EMAIL PROTECTED]> writes:
> The Windows world may have a fair bit to learn from the Unix world
> about software reliability and QA, and also about better supporting
> task automation. But not about user interface design for when tasks
> are done manually.

That's the point.  Manual tasks have nothing to do in computers.
Computers are there to automatize tasks, not to give you more manual work.


-- 
__Pascal Bourguignon__ http://www.informatimago.com/

NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The Modernization of Emacs: terminology buffer and keybinding

[Pascal Bourguignon]

Falcolas <[EMAIL PROTECTED]> writes:

> On Jun 22, 3:06 pm, Pascal Bourguignon <[EMAIL PROTECTED]> wrote:
>> How do you call a Mac user interface that let a user work during 3
>> hours to do a simple modification to a MS-Word file that takes 15
>> seconds to do with emacs or a simple unix script?
>
> Would you mind elaborating on *what* took 3 hours to do, as opposed to
> just throwing around unquantified numbers? Would you also mind
> explaining the user's familiarity with the tools they were using on
> the mac?

Anything that the user have to do repeatitively with the GUI, like
copy-and-paste, or reformating of a lot of paragraphs or table
entries, and which is done automatically by writting a one-liner
program in emacs or shell.

And they tried to put graphical user interfaces on scripting, it
doesn't work either.  Programming is working with text, with verbs.


> It's just as easy for me to say that it took me 30 minutes to simply
> exit emacs, and use that to justify that emacs, and by extension
> Linux, is a terrible tool.


-- 
__Pascal Bourguignon__ http://www.informatimago.com/

NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The Modernization of Emacs

[Twisted]

On Jun 21, 11:11 am, Lew <[EMAIL PROTECTED]> wrote:
> Joel J. Adamson wrote:
> > My point is that I'm the sort of person that has a mind set up for
> > Emacs.  I had none of the difficulties that someone else might have,
> > who's used to other kinds of software.
>
> > However, I'll also point out that my wife has used Emacs a couple
> > times, and she's never done more than point and click with a computer,
> > and she's had no frustration whatsoever.
>
> A new user of two hours' experience.  A father of a six-year old whose child
> hums along happily with emacs.  A computer widow who "had no frustration
> whatsoever" with it.
>
> To the claim that "emacs is too hard for the beginner" we have a mounting pile
> of steaming evidence that refutes.

It's a steaming pile of something, of that I am sure, but I don't
think "evidence" is the word I'd use to describe it. The word I'm
thinking of IS eight letters long, but it starts with "b" instead of
"e"...

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

> To the claim that the help is too hard to use comes the evidence that three
> simple keystroke patterns are all one needs to know, and anecdotal evidence of
> the help system's utility.

Utility is nothing without usability. In particular, no matter how
much useful content the help might have, the fact that when the
document window has the focus the help is always open to the section
on switching windows rather puts a crimp in the actual usability of
that information. The only times you can use it and the only times you
can read it are non-overlapping sets.

> Some will refuse to face the truth.  To the open-minded, let the facts speak
> for themselves.

A few anecdotes prove nothing. A first year statistics 101 dropout
knows that much.

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

Re: The Modernization of Emacs: terminology buffer and keybinding

[David Golden]

Twisted wrote:
 
> Of course not. It's too hard to get started using it, so I gave up on
> it years ago.

So wtf makes you think you're remotely qualified to comment about
emacs as it stands today? Idiot.




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

Re: regular expression concatenation with strings

[oscartheduck]

Got it:

#!/usr/bin/env python
from PIL import Image
import glob, os, re

size = 128, 128

def thumbnailer(dir, filenameRx):
 for picture in [ p for p in os.listdir(dir) if
os.path.isfile(os.path.join(
dir,p)) and filenameRx.match(p) ]:
 file, ext = os.path.splitext(picture)
 im = Image.open (picture)
 im.thumbnail(size, Image.ANTIALIAS)
 im.save(file + ".thumbnail" + ext)

jpg = re.compile(".*\.(jpg|jpeg)", re.IGNORECASE)
thumbnailer(".", jpg)



The answer was sitting in front of my eyes. What is your code doing?
It looks like:

for $foo in [current working directory]
if $foo is a file
and foo's name matches the regex



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

Re: The Modernization of Emacs: terminology buffer and keybinding

[Twisted]

On Jun 21, 10:52 am, Bjorn Borud <[EMAIL PROTECTED]> wrote:
> [Twisted <[EMAIL PROTECTED]>]
> |
> | Being beginner-friendly doesn't have to be at the expense of power or
> | expert-user usability.
>
> depends on your definition of "expert". :-)

Well, admittedly, if your definition of "expert" is "elitist pig who
considers beginner-hostileness itself to be a required feature in
order for him to regard the software as usable", then you may be
right.

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. Only if they "value" such perverse
things as "being one of the exclusive club that can actually manage to
use this thing" does any of this make sense. That's a form of
artificial scarcity, and as I think I've mentioned before, artificial
scarcity is one of the more major roots of evil.

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

Re: newbie question: parsing street name from address

[John Machin]

On Jun 23, 1:43 am, Eric <[EMAIL PROTECTED]> wrote:
> On Jun 21, 6:03 pm, John Machin <[EMAIL PROTECTED]> wrote:
>
>
>
> > On Jun 22, 4:43 am, Eric <[EMAIL PROTECTED]> wrote:
>
> > > On Jun 21, 9:47 am, cjl <[EMAIL PROTECTED]> wrote:
>
> > > > P:
>
> > > > I am working on a project that requires geocoding, and have written a
> > > > very simple geocoder that uses the Google service.
>
> > > > I would like to be able to extract the name of the street from the
> > > > addresses in my data, however they vary significantly. Here a some
> > > > examples:
>
> > > > 25 Main St
> > > > 2500 14th St
> > > > 12 Bennet Pkwy
> > > > Pearl St
> > > > Bennet Rd and Main st
> > > > 19th St
>
> > > > As you can see, sometimes I have the house number, and sometimes I do
> > > > not. Sometimes the street name is a number. Sometimes I simply have
> > > > the names of intersecting streets.
>
> > > > I would like to be able to parse the above into the following:
>
> > > > Main St
> > > > 14th St
> > > > Bennet Pkwy
> > > > Pearl St
> > > > Bennet Rd
> > > > Main St
> > > > 19th St
>
> > > > How might I approach this complex parsing problem?
>
> > > > -CJL
>
> > > You might be able to use consistencies in your data to make this
> > > simpler.  If the examples you have there are representative, it looks
> > > like what you should do is look for a word like 'St' or 'Rd' and then
> > > return that word and the previous word.
>
> > The OP's data already contains
> > [corner|cnr [of]] Foo Rd and|& Bar St
> > and real world data will contain things like
> > 1234 John F Kennedy Memorial Drive
> > 456 Broadway
>
> > As Paul wrote, "Parsing street addresses is a very complex parsing
> > problem", even when you restrict yourself to one mostly-English-
> > speaking country. Software written under such restrictions rapidly
> > breaks down elsewhere (Rue de la Paix, Wilhelmstrasse, Avenida 9 de
> > Julio, etc) and blows up altogether when street names aren't used in
> > postal addresses (e.g. Japan).
>
> No doubt that address parsing is, in general, a very difficult
> problem.  However, it may not be necessary for him to solve the
> general problem.  If his dataset is more limited in formats then his
> problem is much simpler.

Ignore the last sentence of my post. Restrict the application to
[sub]urban addresses in the USA. If the OP's dataset is real-world
data, it will contain cases of street addresses that don't fit "look
for a word like 'St' or 'Rd' and then return that word and the
previous word."  To expect an OP in a newsgroup to provide
representative examples is charmingly naive :-) and in any case the OP
had already provided a corner case [pun intended] that busted your
rule.

Cheers,
John

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

Re: The Modernization of Emacs: terminology buffer and keybinding

[Twisted]

On Jun 21, 12:03 pm, Robert Uhl <[EMAIL PROTECTED]> wrote:
> Twisted <[EMAIL PROTECTED]> writes:
>
> >> Emacs is amazingly beginner-friendly for the power and flexibility it
> >> provides. [snip]
>
> > That's a joke, right? I tried it a time or two. Every time it was
> > rapidly apparent that doing anything non-trivial would require
> > consulting a cheat sheet. The printed-out kind, since navigating to
> > the help and back without already having the help displayed and open
> > to the command reference was also non-trivial.
>
> C-h i, C-x b RET is non-trivial?!?

Let's change that so that you see it the way most human beings see it:

> > navigating to
> > the help and back without already having the help displayed and open
> > to the command reference was also non-trivial.

> Erh h, dhsd f hHE is non-trivial?

I'm sorry. I don't speak Chinese.

I trust I've made my point. Not only does it insist you learn a whole
other language (though I'm guessing it's not actually Chinese --
Greek, maybe), even when you know that's a bunch of keystrokes and
even what they are...

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

I suppose it just pops in there by divine inspiration? Or it's
supposed to be self-evident to anyone who has TRUE wisdom? Or maybe
it's just expected that you be mentored by an expert, who would know
that arcane incantation and could pass it on to a new student. Well
I've got news for you buddy -- there's no such thing as divine
inspiration, it's not self-evident, and most people can't afford (if
they could find) a tutor just to learn how to use A TEXT EDITOR.

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.

This is the lowly Notepad, which I'll freely admit is the rusty
bicycle of text editors, and it's much easier to use (including the
help) than the supposed Mercedes-Benz of editors.

[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...but it
does occur to me that a context-sensitive auto-popup cheat sheet tool
would be useful on the typical unix system!]

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

Re: Adding method to a class on the fly

[John Henry]

On Jun 22, 2:28 pm, askel <[EMAIL PROTECTED]> wrote:
> On Jun 22, 5:17 pm, 7stud <[EMAIL PROTECTED]> wrote:
>
>
>
> > On Jun 22, 2:24 pm, askel <[EMAIL PROTECTED]> wrote:
>
> > > class Dummy:
> > >   def method(self, arg):
> > > print arg
>
> > > def method2(self, arg):
> > >   self.method(arg)
>
> > > Dummy.method2 = method2
> > > Dummy.method2('Hello, world!')
>
> > Traceback (most recent call last):
> >   File "test1.py", line 8, in ?
> > Dummy.method2('Hello, world!')
> > TypeError: unbound method method2() must be called with Dummy instance
> > as first argument (got str instance
> > instead)
>
> > >I like that to be the same as:
>
> > >class Dummy:
> > >def __init__(self):
> > >return
>
> > >def method_dynamic(self):
> > >return self.method_static("it's me")
>
> > >def method_static(self, text):
> > >print text
> > >   return
>
> > >so that I can do:
>
> > >dum=Dummy.method_dynamic()
>
> > >and see "it's me" printed.
>
> > When are you able to see that?
>
> there is no way to call instance method from static one. but in your
> case you can make something like:
>
> class Dummy:
>   @staticmethod
>   def method(arg):
> print arg
>
> def method2(arg):
>   Dummy.method(arg)
>
> Dummy.method2 = staticmethod(method2)
> Dummy.method2('Hello, world!')
>
> - OR -
>
> def method2(cls, arg):
>   cls.method(arg)
>
> Dummy.method2 = classmethod(method2)
> Dummy.method2('Hello, world!')



Thanks for the response.

The above doesn't exactly do I what need.  I was looking for a way to
add method to a class at run time.

What does work, is to define an entire sub-class at run time.  Like:

class DummyParent:
def __init__(self):
return

def method_static(self, text):
print text
return

text = "class Dummy(DummyParent):"
text += "\n\t" + "def __init(self):"
text += "\n\t" + "\tDummyParent.__init__(self)"
text += "\n\t" + "def method_dynamic(self):"
text += "\n\t" + "\tself.method_static(\"it's me\")"

exec text

dum=Dummy().method_dynamic()


Thanks again.

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

Re: The Modernization of Emacs: terminology buffer and keybinding

[Twisted]

On Jun 21, 11:06 am, [EMAIL PROTECTED] (Joel J. Adamson) wrote:
> And it's baloney!  No one in my office that uses one of these supposedly
> user-friendly machines thinks that it's actually easy to use.  They
> slam their keyboards and throw their hands up *every* day.

Because of bugs or the network going down or stuff like that, I'll
bet, not because they can't find out or remember how to do some basic
task.

That's entirely orthogonal to the issue of interface learning curve OR
interface ease-of-use. Emacs has deficiencies in both areas, if
principally the former. (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. Now THAT is what I call
disruptive context switching. Meanwhile even the lowly Notepad
responds to "open" by displaying a list of text files and tools to
navigate the folder hierarchy without having to do it blind, while
still letting you blind-type a path if you remember it. And you can
also paste the path in from the clipboard. Unix systems don't even
*have* a proper system-wide clipboard and copy/paste capability. Under
X there's a weak, text-only imitation, which doesn't help you much
when you want to copy a selection from an image in a paint program and
paste it into a CAD or web-design or specialized image-manipulation
tool or whatever...you have to save it to a file and load it, which is
a pain in the butt and slowly clutters your hard drive with
"temporary" files you occasionally forget to delete.

> The only solution that really works is for people to _learn_ how to
> use computers, and to accept that it will be a challenge.

How much learning it takes can be varied by the programmer, however.
They can choose to make the learning curve steeply vertical at
takeoff, or they can make it start out shallow and climb steeply only
when the user desires expert functionality. (They can also, stupidly,
choose to leave out fancier functionality entirely, of course.)

As for bugs and other frustrations, better robustness in the key areas
of memory management and concurrency control is needed. Most serious
(especially crash-causing, data-losing, or data-corrupting) bugs
involve memory mismanagement and a lot more, as well as other serious
bugs, result from race conditions. These sorts of bugs are also
responsible for a lot of security holes -- buffer overrun exploits are
only possible against targets with memory management and input
validation bugs. Java apps, due to Java's memory management model, are
immune to these.

The Windows world may have a fair bit to learn from the Unix world
about software reliability and QA, and also about better supporting
task automation. But not about user interface design for when tasks
are done manually.

> And as for the arcane commands needed to get to the help page, their
> on the splash screen.  Have you used Emacs recently?

Of course not. It's too hard to get started using it, so I gave up on
it years ago.

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

Re: Portable general timestamp format, not 2038-limited

[Lew]

James Harris wrote:
> a) store, as a 32-bit number, days since a virtual year zero (there is
> no year zero in common era time 
).

But according to the same article:
> (It [year zero] is, however, used in the astronomical system and ISO 8601.)

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

Re: regular expression concatenation with strings

[Jacek Trzmiel]

Hi,

oscartheduck wrote:
> I noticed a small error in the code (you referenced extension, which
> you had renamed to filenameRx), and when I corrected it I received the
> original error again.

I haven't had PIL installed, so I just commented out im.* calls for 
test. Just change:
   im.save(file + ".thumbnail." + extension)
to:
   im.save(file + ".thumbnail" + ext)


> What was it you were trying to do to solve the
> problem, though?

You can't use glob with regexps.  Instead use os.listdir() to get 
filenames and then rx.match() to find ones that does match the pattern.

Best regards,
Jacek.

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

Re: Adding method to a class on the fly

[askel]

On Jun 22, 5:17 pm, 7stud <[EMAIL PROTECTED]> wrote:
> On Jun 22, 2:24 pm, askel <[EMAIL PROTECTED]> wrote:
>
> > class Dummy:
> >   def method(self, arg):
> > print arg
>
> > def method2(self, arg):
> >   self.method(arg)
>
> > Dummy.method2 = method2
> > Dummy.method2('Hello, world!')
>
> Traceback (most recent call last):
>   File "test1.py", line 8, in ?
> Dummy.method2('Hello, world!')
> TypeError: unbound method method2() must be called with Dummy instance
> as first argument (got str instance
> instead)
>
>
>
> >I like that to be the same as:
>
> >class Dummy:
> >def __init__(self):
> >return
>
> >def method_dynamic(self):
> >return self.method_static("it's me")
>
> >def method_static(self, text):
> >print text
> >   return
>
> >so that I can do:
>
> >dum=Dummy.method_dynamic()
>
> >and see "it's me" printed.
>
> When are you able to see that?

there is no way to call instance method from static one. but in your
case you can make something like:

class Dummy:
  @staticmethod
  def method(arg):
print arg

def method2(arg):
  Dummy.method(arg)

Dummy.method2 = staticmethod(method2)
Dummy.method2('Hello, world!')

- OR -

def method2(cls, arg):
  cls.method(arg)

Dummy.method2 = classmethod(method2)
Dummy.method2('Hello, world!')

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

Re: Adding method to a class on the fly

[7stud]

On Jun 22, 3:23 pm, askel <[EMAIL PROTECTED]> wrote:
> sorry, of course last line should be:
> Dummy().method2('Hello, world!')

..which doesn't meet the op's requirements.

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

Re: regular expression concatenation with strings

[oscartheduck]

Shoot, I think I realised what I'm doing wrong.

Let me write some code to address this, but I'm almost certain that
the error is that I'm attempting to save an image with a regular
expression, which is by nature fluid, tacked on to its ass after
the .thumbnail. Which, now I look at your code, you address implicitly
by suggesting that the extension be a different variable.


Thanks!





On Jun 22, 3:10 pm, oscartheduck <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I noticed a small error in the code (you referenced extension, which
> you had renamed to filenameRx), and when I corrected it I received the
> original error again. What was it you were trying to do to solve the
> problem, though?
>
> Thanks!
>
> On Jun 22, 2:41 pm, Jacek Trzmiel <[EMAIL PROTECTED]> wrote:
>
> > Hi,
>
> > oscartheduck wrote:
> > > I have a little script that sits in a directory of images and, when
> > > ran, creates thumbnails of the images. It works fine if I call the
> > > function inside the program with something like "thumbnailer("jpg),
> > > but I want to use a regular expression instead of a plain string so
> > > that I can match jpeg, jpg, JPEG etc.
>
> > Something like this will work:
>
> > #!/usr/bin/env python
> > #from PIL import Image
> > import glob, os, re
>
> > size = 128, 128
>
> > def thumbnailer(dir, filenameRx):
> >  for picture in [ p for p in os.listdir(dir) if
> > os.path.isfile(os.path.join(dir,p)) and filenameRx.match(p) ]:
> >  file, ext = os.path.splitext(picture)
> >  im = Image.open (picture)
> >  im.thumbnail(size, Image.ANTIALIAS)
> >  im.save(file + ".thumbnail." + extension)
>
> > jpg = re.compile(".*\.(jpg|jpeg)", re.IGNORECASE)
> > thumbnailer(".", jpg)
>
> > Best regards,
> > Jacek.


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

Re: Adding method to a class on the fly

[askel]

On Jun 22, 5:17 pm, 7stud <[EMAIL PROTECTED]> wrote:
> On Jun 22, 2:24 pm, askel <[EMAIL PROTECTED]> wrote:
>
> > class Dummy:
> >   def method(self, arg):
> > print arg
>
> > def method2(self, arg):
> >   self.method(arg)
>
> > Dummy.method2 = method2
> > Dummy.method2('Hello, world!')
>
> Traceback (most recent call last):
>   File "test1.py", line 8, in ?
> Dummy.method2('Hello, world!')
> TypeError: unbound method method2() must be called with Dummy instance
> as first argument (got str instance
> instead)
>
>
>
> >I like that to be the same as:
>
> >class Dummy:
> >def __init__(self):
> >return
>
> >def method_dynamic(self):
> >return self.method_static("it's me")
>
> >def method_static(self, text):
> >print text
> >   return
>
> >so that I can do:
>
> >dum=Dummy.method_dynamic()
>
> >and see "it's me" printed.
>
> When are you able to see that?

sorry, of course last line should be:
Dummy().method2('Hello, world!')

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

Re: The Modernization of Emacs: terminology buffer and keybinding

[BartlebyScrivener]

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

rd


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

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

[askel]

On Jun 22, 1: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.
>
> Conceptually this is a simple database operation with a join on a
> common field (zip code in the above example). Other case use other
> relational operators (projection, cross-product, etc) so I'm really
> looking for something SQL-like in functionality. However, the data is
> in flat-files, the file structure changes frequently, the files are
> dynamically generated from a range of sources, are short-lived in
> nature, and otherwise not warrant the hassle of a database setup. So
> I've been looking around for a nice, Pythonic, zero-config (no
> parsers, no setup/teardown, etc) solution for simple queries that
> handles a database of csv-files-with-headers automatically. There are
> number of solutions that are close, but in the end come up short:
>
> - KirbyBase 1.9 (latest Python version) is the closest that I could
> find, as it lets you keep your data in flatfiles and perform
> operations using the field names from those text-based tables, but it
> doesn't support joins (the more recent Ruby version seems to).
> - Buzhug and Sqlite have their data structures w no automatic .tab
> or .csv parsing (unless sqlite includes a way to map flatfiles to
> sqlite virtual tables that I don't know about).
> -http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/159974is
> heading in the right direction, as it shows how to perform relational
> operations on lists and are index based rather than field-name based.
> -http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/498130andhttp://furius.ca/pubcode/pub/conf/common/bin/csv-db-import.html
> provide ways of automatically populating DBs but not the reverse
> (persist changes back out to the data files)
>
> The closest alternatives I've found are the GNU textutils that support
> join, cut, merge, etc but I need to add additional logic they don't
> support, nor do they allow field-level write operations from Python
> (UPDATE ... WHERE ...). Normally I'd jump right in and start coding
> but this seems like something so common that I would have expected
> someone else to have solved, so in the interest of not re-inventing
> the wheel I thought I'd see if anyone had any other suggestions. Any
> thoughts?
>
> Thanks!
>
> Ramon

ramon,

i don't think that using flat text files as a database is common these
days. if you need relational database features what stops you from
using rdbms? if the only reason for that is some legacy system then
i'd still use in-memory sqlite database for all relational operations.
import, process, export back to text if you need to.

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

Re: Adding method to a class on the fly

[7stud]

On Jun 22, 2:24 pm, askel <[EMAIL PROTECTED]> wrote:
> class Dummy:
>   def method(self, arg):
> print arg
>
> def method2(self, arg):
>   self.method(arg)
>
> Dummy.method2 = method2
> Dummy.method2('Hello, world!')

Traceback (most recent call last):
  File "test1.py", line 8, in ?
Dummy.method2('Hello, world!')
TypeError: unbound method method2() must be called with Dummy instance
as first argument (got str instance
instead)



>I like that to be the same as:
>
>class Dummy:
>def __init__(self):
>return
>
>def method_dynamic(self):
>return self.method_static("it's me")
>
>def method_static(self, text):
>print text
>   return
>
>
>so that I can do:
>
>dum=Dummy.method_dynamic()
>
>and see "it's me" printed.

When are you able to see that?

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

Re: The Modernization of Emacs: terminology buffer and keybinding

[Falcolas]

On Jun 22, 3:06 pm, Pascal Bourguignon <[EMAIL PROTECTED]> wrote:
> How do you call a Mac user interface that let a user work during 3
> hours to do a simple modification to a MS-Word file that takes 15
> seconds to do with emacs or a simple unix script?

Would you mind elaborating on *what* took 3 hours to do, as opposed to
just throwing around unquantified numbers? Would you also mind
explaining the user's familiarity with the tools they were using on
the mac?

It's just as easy for me to say that it took me 30 minutes to simply
exit emacs, and use that to justify that emacs, and by extension
Linux, is a terrible tool.

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

Re: regular expression concatenation with strings

[oscartheduck]

Hi,

I noticed a small error in the code (you referenced extension, which
you had renamed to filenameRx), and when I corrected it I received the
original error again. What was it you were trying to do to solve the
problem, though?

Thanks!



On Jun 22, 2:41 pm, Jacek Trzmiel <[EMAIL PROTECTED]> wrote:
> Hi,
>
> oscartheduck wrote:
> > I have a little script that sits in a directory of images and, when
> > ran, creates thumbnails of the images. It works fine if I call the
> > function inside the program with something like "thumbnailer("jpg),
> > but I want to use a regular expression instead of a plain string so
> > that I can match jpeg, jpg, JPEG etc.
>
> Something like this will work:
>
> #!/usr/bin/env python
> #from PIL import Image
> import glob, os, re
>
> size = 128, 128
>
> def thumbnailer(dir, filenameRx):
>  for picture in [ p for p in os.listdir(dir) if
> os.path.isfile(os.path.join(dir,p)) and filenameRx.match(p) ]:
>  file, ext = os.path.splitext(picture)
>  im = Image.open (picture)
>  im.thumbnail(size, Image.ANTIALIAS)
>  im.save(file + ".thumbnail." + extension)
>
> jpg = re.compile(".*\.(jpg|jpeg)", re.IGNORECASE)
> thumbnailer(".", jpg)
>
> Best regards,
> Jacek.




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

Re: The Modernization of Emacs: terminology buffer and keybinding

[Pascal Bourguignon]

Twisted <[EMAIL PROTECTED]> writes:

> On Jun 21, 12:09 pm, Robert Uhl <[EMAIL PROTECTED]> wrote:
>> Twisted <[EMAIL PROTECTED]> writes:
>>
>> >> > I have that exact URL now --
>> >> >http://www.asktog.com/columns/027InterfacesThatKill.html
>>
>> >> Utterly unrelated to Emacs.
>>
>> > I think it is quite relevant. Clunky computer interfaces may not be so
>> > dramatically dangerous, but they certainly can hamper productivity.
>>
>> You're quite right.  Windows/Mac user interfaces are so clunky that they
>> massively hamper productivity.
>
> This is a joke, right?

How do you call a Mac user interface that let a user work during 3
hours to do a simple modification to a MS-Word file that takes 15
seconds to do with emacs or a simple unix script?


-- 
__Pascal Bourguignon__ http://www.informatimago.com/

NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
-- 
http://mail.python.org/mailman/listinfo/python-list

SIMD powered Python

[Hugo Ferreira]

Hi!

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

Best regards,

Hugo Ferreira

--

[1] http://en.wikipedia.org/wiki/SIMD
[2] http://en.wikipedia.org/wiki/Streaming_SIMD_Extensions
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The Modernization of Emacs: terminology buffer and keybinding

[Twisted]

On Jun 21, 12:09 pm, Robert Uhl <[EMAIL PROTECTED]> wrote:
> Twisted <[EMAIL PROTECTED]> writes:
>
> >> > I have that exact URL now --
> >> >http://www.asktog.com/columns/027InterfacesThatKill.html
>
> >> Utterly unrelated to Emacs.
>
> > I think it is quite relevant. Clunky computer interfaces may not be so
> > dramatically dangerous, but they certainly can hamper productivity.
>
> You're quite right.  Windows/Mac user interfaces are so clunky that they
> massively hamper productivity.

This is a joke, right?

> Emacs, OTOH, enables it.  For example,
> C-s is search forward; C-r is search backward ('reverse'); C-M-s is
> search forward for a regular expression; C-M-r is search backward for a
> regular expression.

Aside from the collision with the standard in the case of C-s (should
be save focused document if it has unsaved changes), these present no
problem. The inability to find and use them without memorizing all
those keystrokes does present a problem.

> A Windows or Mac editor would have C-s for save,
> and that's it.  It might have C-f for find, but it'd pop up a dialogue
> instead of offering an interactive search, causing a mental context
> switch.

Eh? In other words, it works the way it's supposed to. That dialogue
will ordinarily be modeless but floating, so you can get it out of the
way or use it to navigate the document, then edit the document without
having to close the dialogue, and avoid the dialogue disappearing
behind other things. New search can be typed in at the drop of a hat.
Some editors have regular expression searches. All have a
straightforward substring search. Generally if there's anything in the
least arcane (e.g. regular expression searches) there's a ? button to
pop up help, which goes directly to the search help. You can read this
and tab back to the search dialogue with ease, and get them side by
side without any mess or fuss. Of course the dialog offers search
forward and usually search backward. And it normally also offers
search-AND-REPLACE, to boot.

Is this somehow not "interactive" enough for you? Versus having to
memorize a bunch of keys. It also means no esc-meta-alt-ctrl-shift BS,
as the document window needs to have only a few bindings, such as C-f
and C-s, and only the one (C-f) for search; all the search bindings in
the one window in emacs get replaced by just one binding in the
document window and a bunch applicable to the find dialogue. And the
find dialogue can be operated without knowing the bindings by mouse,
and the bindings can be seen directly in the find dialogue by
underlined letters on button labels (see that underlined N in "find
Next"? It means you can hit alt-N while the dialogue has focus,
followed by alt-tab to jump to the document with the next occurrence
selected, or alt-N repeatedly to jump to later occurrences until you
see the one you want, just in case you have rodent allergies).

It has useful key bindings. It is also wise enough to make learning
them optional, so you can learn the ones that speed up your most
common tasks and spare the effort otherwise, where it would consume
more time than it would eventually save you (less common tasks). With
an emacs type interface, you only get to ignore the key bindings for
commands you will NEVER use, rather than ones you use but
infrequently. Forgetting the latter means a trip to the help every
time, also.

> Searching would interrupt one's flow of thought rather than being part of it.

Where does this come from?

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

C wrappers and the proxy dilemma

[Ken Seehart]

Anyone who has wrapped C or C++ libraries has encountered the proxy 
dilemma. 

A long time ago, I naively thought that I could start by deriving my 
high level python class from the c-python type, but this leads to many 
difficult problems because several of the underlying methods return the 
low level objects.  After reading up on the subject, I learned that the 
"correct" solution is to use composition rather than inheritance.  It 
makes sense, but it is nevertheless rather annoying.


An excellent example of this is the wxPython library, which uses 
composition (proxies) and even solves the OOR (original object return) 
problem that is associated with this kind of proxy oriented solution.


Conclusion: There is no really good solution to this kind of thing that 
doesn't get messy.  Wrapping C or C++ in python becomes difficult 
whenever you have methods that return (or take as arguments) instances 
of the objects that you are trying to wrap in high level python.  Any 
solution seems to add more overhead than is desirable (in terms of both 
programmer time and run time).


This problem comes up over and over again, so perhaps it is even worth a 
PEP if a change to the python language would facilitate a more 
convenient solution to this nagging problem.


First, mentally set aside the idea of using composition.  I understand 
the set of problems that it solves, but it also creates a new set of 
problems (such as function call overhead on every method call).  I also 
understand why composition is better than inheritance.  But in order to 
contemplate this proposal, it is necessary to temporarily set aside the 
composition idea.  This proposal involves taking another look at 
something slightly more akin to the inheritance approach that we all 
gave up on before.


Okay, so here is a somewhat radical proposal:

Add a writable  __overload__ attribute to low level python type.  This 
would be assigned a python 'type' instance (or None to have no effect).  
The effect is to place __overload__ at the /beginning /of the __mro__ of 
the low level type, making it possible to directly alter the behavior of 
the base python type without using inheritance.  This means that 
instances of the base type acquire the attributes of our high level 
python class.  It is important that the __overload__ type is checked 
/before /the actual type.


Yeah, it sounds a bit scary at first.  A bit too loose maybe.  So the 
type definition should have to explicitly enable this feature to prevent 
people from doing bad things.  But dwelling too much on the scariness 
seems somewhat non-pythonic.  It is more important that we can do really 
good things than that we prevent ourselves from going out of our way to 
do bad things (as long as it is not too /easy /to do bad things).


So here are some of the benefits:

1. Eliminates the duality between proxy objects and low level objects.

2. Increased speed on methods whose syntaxes are not being altered 
(because no wrapper is needed).


3. Much less work than writing wrappers for every method (even if such a 
task is partially automated).


Usage example:

from foolib import c_foo

class Foo(c_foo):
   """Overload of c_foo"""

   def __new__(typ, *args, **kwargs):
   return c_foo(*args, **kwargs)

   def __init__(self, parrot_state):
   c_foo.__init__(self)
   self.parrot_state = parrot_state

   def myfunc(self):
   return 5 * self.juju(self.parrot_state) # juju method is defined 
in foolib


# This makes all c_foo instances into Foo instances:  Poof!
c_foo.c_footype.__overload__ = Foo



x = Foo('not dead yet') # actually creates a c_foo instance that looks 
like a Foo instance


# c_foo.Add is defined in foolib and takes c_foo instances
x.Add(Foo('strange'))
x.Add(Foo('missing'))

# c_foo.GetChildren is defined in foolib and returns c_foo instances
for y in x.GetChildren():
   print y.myfunc() # Wow, I am magically accessing Foo.myfunc


Yeah I know, that's an infinitely recursive inheritance; but that's 
okay, we just implement the __overload__ feature such that the MRO 
thingy will do the right thing for us.  The semantics will be that Foo 
is derived from c_foo, and all instances of c_foo behave as if the are 
instances of Foo.


I used the term "radical" earlier, to describe this idea.  What I meant 
was that it seems to violate some basic Object Oriented principles.  
However, when evaluating solutions I try not to apply any principles too 
dogmatically.  Theory is only relevant when it has /practical 
/consequences.  So I recommend not quoting theory without also defending 
the relevance of the theory to the case in point.  IMO, anything that 
eliminates thousands of lines of boilerplate code is worth bending 
theory a little.


Is it possible to get the same syntactic/semantic results without 
changing python?


- Ken

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

Re: Portable general timestamp format, not 2038-limited

[Carsten Haese]

On Fri, 2007-06-22 at 13:33 -0700, James Harris wrote:
> I have a requirement to store timestamps in a database. Simple enough
> you might think but finding a suitably general format is not easy. The
> specifics are
> 
> 1) subsecond resolution - milliseconds or, preferably, more detailed
> 2) not bounded by Unix timestamp 2038 limit
> 3) readable in Java
> 4) writable portably in Perl which seems to mean that 64-bit values
> are out
> 5) readable and writable in Python
> 6) storable in a free database - Postgresql/MySQL

PostgreSQL timestamps do not appear to be limited by Y2K38:

pgtest=> create table dt(a timestamp);
CREATE TABLE
pgtest=> insert into dt(a) values('2099-01-01 01:23:45.678901');
INSERT 0 1
pgtest=> select * from dt;
 a  

 2099-01-01 01:23:45.678901
(1 row)


HTH,

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


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

Re: The Modernization of Emacs: terminology buffer and keybinding

[Twisted]

On Jun 21, 12:11 pm, Robert Uhl <[EMAIL PROTECTED]> wrote:
> Twisted <[EMAIL PROTECTED]> writes:
>
> >> But Emacs does not have a "clunky" interface.
>
> > That's for the everyday novice-to-intermediate user to decide.
>
> Why should the ignorant decide?  Do you leave the decision of what great
> art is to 3 year olds and their doting parents?

Did I say it was for the "beginner" to decide? No, I said "novice-to-
intermediate".

How clunky versus usable an interface to a tool is is for those who
invest some, but not extraordinary amounts of, time into its use to
decide. If it requires years of mastery, it is clunky -- period. This
may be unavoidable if it's something involved in nuclear power plants,
delicate neurosurgery, or whatever. If it's a text editor, on the
other hand, it's clearly going to have superior competition in the
area of usability.

Besides, ANY interface that involves fumbling around in the dark
trying to find a light switch is clunky. You should be able to see
what the hell you're doing and navigate easily. 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. An analogy to a genuine emacs experience:
you enter a workshop with some raw materials and tools. Unfortunately
there's no big ceiling lights so you can just flip the switch by the
door and then always be able to see where everything is. Instead
there's little lights here and there by various specific tools and
storage areas, and in one area a map of the place with switches to
control the lights. So first you have to fumble around until you
happen upon the map/light controls. Then you need to (in the dark!)
hit the switch for the map/light control area itself. (Now you've
found the help and gotten it to be the active pane, er "window".) Now
you need to find the tool you want on the map -- OK, that was easy.
Now you turn on its light. Oh, hell -- the light on the map/light
controls has now gone out though! That also included the instructions
on using the specific tool. You can go to and use the one tool, if you
memorized those instructions, but then it's back to the darkness...
(You find the help on doing a particular thing, then can't get back to
the document to do it because of clunky navigation. So you go back to
the help on switching windows, and now you can flip back to the
document. Only you realize you can have the document and help open at
the same time, but the only time the document has focus is when the
help is open to "help on switching windows", which makes this rather
useless! 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. 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.

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.

I don't know why people keep harping about what version. It was
probably something in the low 20s, after an earlier try with one in
the upper teens. 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. Defeating the whole purpose of
having a help system. A separate printed manual would have been
better, if I could have spared the paper and toner, as I could hold
that off to one side of the monitor and flip through it and open it to
anywhere I wanted to, then go back to my document without even having
to think about it. Even though it would be at the price of no full-
text search capability -- not that I could ever get that to work in
emacs anyway. There was no apparent way to do a simple substring
search and click "next match" or "previous match" to navigate among
the hits...more arcane keypresses would be required, and as soon as it
showed you the first match inside the help, the keypress documentation
of course vanished.

As far as I can tell, it just is not and never was possible to get
started with emacs without a separate, outside-of-emacs cheat sheet,
or to be very productive at all without actually memorizing the damn
thing. Modern user interfaces require a minimum of memorization, most
of which is basic, standard stuff that is the same from one app to the
next, so 

Re: regular expression concatenation with strings

[Jacek Trzmiel]

Hi,

oscartheduck wrote:
> I have a little script that sits in a directory of images and, when
> ran, creates thumbnails of the images. It works fine if I call the
> function inside the program with something like "thumbnailer("jpg),
> but I want to use a regular expression instead of a plain string so
> that I can match jpeg, jpg, JPEG etc.

Something like this will work:

#!/usr/bin/env python
#from PIL import Image
import glob, os, re

size = 128, 128


def thumbnailer(dir, filenameRx):
 for picture in [ p for p in os.listdir(dir) if 
os.path.isfile(os.path.join(dir,p)) and filenameRx.match(p) ]:
 file, ext = os.path.splitext(picture)
 im = Image.open (picture)
 im.thumbnail(size, Image.ANTIALIAS)
 im.save(file + ".thumbnail." + extension)


jpg = re.compile(".*\.(jpg|jpeg)", re.IGNORECASE)
thumbnailer(".", jpg)


Best regards,
Jacek.

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

Re: possible to preserve subprocess.Popen objects for later?

[Ratko]

> Sounds like you might want to consider running the backround task as
> either a service or daemon  and communicate via a TCP/IP connection or
> a named pipe rather than using STDIN/OUT.  Actually you could use
> either idea without actually setting up a daemon.

Unfortunately I don't have control over the processes that I am
running (they are components of a much larger system that I am trying
to bring under one roof).

However, it seems that a named pipe might work. Is it possible to set
up a named pipe for a process that I start and tell that process to
direct all its output to it?

Thanks,
Ratko

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

Portable general timestamp format, not 2038-limited

[James Harris]

I have a requirement to store timestamps in a database. Simple enough
you might think but finding a suitably general format is not easy. The
specifics are

1) subsecond resolution - milliseconds or, preferably, more detailed
2) not bounded by Unix timestamp 2038 limit
3) readable in Java
4) writable portably in Perl which seems to mean that 64-bit values
are out
5) readable and writable in Python
6) storable in a free database - Postgresql/MySQL

The formats provided by the two database systems are such as 8-byte or
12-byte values which, even if I could get Perl to work with I guess it
would be messy. Keeping to 32-bit values should give me portability
and be easy enough to work with without obscuring the program logic.
Since 32 bits of microseconds is less than 50 days I have to store two
32-bit values. How to split them? The option I favour at the moment is
to split days and parts of days like this:

a) store, as a 32-bit number, days since a virtual year zero (there is
no year zero in common era time ). This allows over five million years plus and minus.
Still not completely general, I know.
b) store parts of days as another 32-bit value. Its range would have
to go to 86401 seconds - the number of seconds in a leap day. This
means each 'tick' would be around 21 microseconds. For regularity I
could make the ticks 25 microseconds so there would be 40,000 in a
second and 3,456,000,000 in a day; and, finally, the counter could
tick about 5 hours into the next day if not caught.

Any thoughts on a better way to do this? (Please reply-all. Thanks).

--
James

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

Re: Tailing a log file?

[[EMAIL PROTECTED]]

On Jun 22, 2:50 pm, "Kenji Noguchi" <[EMAIL PROTECTED]> wrote:
> something like this? unix tail command does more fancy stuff
> like it waits for timeout, and check if the file is truncated
> or depending on incoming data it sleeps seconds , etc etc.
>
> #!/usr/bin/env python
> import sys, select
>
> while True:
> ins, outs, errs = select.select([sys.stdin],[],[])
> for i in ins:
> print i.readline()

select doesn't work on regular files (only pipes/sockets/etc).
inotify is platform-specific; the portable way to do this is to poll,
like tail does.  If you know you're on a platform that has inotify or
something like it, it's probably the more efficient (and lower
latency) route to go.

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

Ten years on....

[Clarence]

I've been waiting for a month to post this (yesterday), and then I
missed it. Oh, well, it's funny and deserves to be republished on its
ten-year-and-one-day anniversary.

BTW, a member of the ANSI C committee once told me that the only thing
rand is used for in C code is to decide whether to pick up the axe or
throw the dwarf, and if that's true I guess "the typical libc rand" is
adequate for all but the most fanatic of gamers .

-- Tim Peters, 21 June 1997.

"Belated-but-still-sincerely-admiring-of-Tim-Peters"-ly yrs,
Clarence

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

Re: Adding method to a class on the fly

[askel]

On Jun 22, 3:02 pm, John Henry <[EMAIL PROTECTED]> wrote:
> Hi list,
>
> I have a need to create class methods on the fly.  For example, if I
> do:
>
> class Dummy:
> def __init__(self):
> exec '''def method_dynamic(self):\n\treturn
> self.method_static("it's me")'''
> return
>
> def method_static(self, text):
> print text
> return
>
> I like that to be the same as:
>
> class Dummy:
> def __init__(self):
> return
>
> def method_dynamic(self):
> return self.method_static("it's me")
>
> def method_static(self, text):
> print text
> return
>
> so that I can do:
>
> dum=Dummy.method_dynamic()
>
> and see "it's me" printed.
>
> Can that be done?
>
> Thanks,

class Dummy:
  def method(self, arg):
print arg

def method2(self, arg):
  self.method(arg)

Dummy.method2 = method2
Dummy.method2('Hello, world!')

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

regular expression concatenation with strings

[oscartheduck]

Hi folks,

I have a little script that sits in a directory of images and, when
ran, creates thumbnails of the images. It works fine if I call the
function inside the program with something like "thumbnailer("jpg),
but I want to use a regular expression instead of a plain string so
that I can match jpeg, jpg, JPEG etc.



Here's the script:

---

 #!/usr/bin/env python
from PIL import Image
import glob, os, re

size = 128, 128

# takes an extension (e.g. jpg, png, gif, tiff) as argument
def thumbnailer(extension):
#glob the directory the script is in for files of the type
foo.extension
  for picture in glob.glob("*." + extension):
file, ext = os.path.splitext(picture)
im = Image.open (picture)
im.thumbnail(size, Image.ANTIALIAS)
im.save(file + ".thumbnail." + extension)


jpg = re.compile("jpg|jpeg", re.IGNORECASE)
thumbnailer(jpg)



---

And here's the error:

---

Traceback (most recent call last):
  File "./thumbnail.py", line 19, in ?
thumbnailer(jpg)
  File "./thumbnail.py", line 11, in thumbnailer
for picture in glob.glob("*." + extension):
TypeError: cannot concatenate 'str' and '_sre.SRE_Pattern' objects

---


It looks to me like the conversion to a regex object instead of a
plain string is screwing up the file glob + extension concatenation.
Is there a simple way to accomplish what I'm trying to do here and get
rid of that error?

Thanks!

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

Re: Setuptools, build and install dependencies

[Robert Kern]

Harry George wrote:

> We need to know the dependencies, install them in dependency order,
> and expect the next package to find them.  "configure" does this for
> hundreds of packages.  cmake, scons, and others also tackle this
> problem.  Python's old setup.py seems to be able to do it.  

No, generic setup.py scripts don't do anything of that kind.

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

regular expression

[James]

Hi folks,

I have a little script that sits in a directory of images and, when ran,
creates thumbnails of the images. It works fine if I call the function
inside the program with something like "thumbnailer("jpg), but I want to use
a regular expression instead of a plain string so that I can match jpeg,
jpg, JPEG etc.



Here's the script:

---

#!/usr/bin/env python
from PIL import Image
import glob, os, re

size = 128, 128

# takes an extension (e.g. jpg, png, gif, tiff) as argument
def thumbnailer(extension):
#glob the directory the script is in for files of the type foo.extension
 for picture in glob.glob("*." + extension):
   file, ext = os.path.splitext(picture)
   im = Image.open(picture)
   im.thumbnail(size, Image.ANTIALIAS)
   im.save(file + ".thumbnail." + extension)


jpg = re.compile("jpg|jpeg", re.IGNORECASE)
thumbnailer(jpg)



---

And here's the error:

---

Traceback (most recent call last):
 File "./thumbnail.py", line 19, in ?
   thumbnailer(jpg)
 File "./thumbnail.py", line 11, in thumbnailer
   for picture in glob.glob("*." + extension):
TypeError: cannot concatenate 'str' and '_sre.SRE_Pattern' objects

---


It looks to me like the conversion to a regex object instead of a plain
string is screwing up the file glob + extension concatenation. Is there a
simple way to accomplish what I'm trying to do here and get rid of that
error?

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

Re: How to Encode Parameters into an HTML Parsing Script

[SMERSH009X]

On Jun 21, 9:45 pm, "Gabriel Genellina" <[EMAIL PROTECTED]>
wrote:
> En Thu, 21 Jun 2007 23:37:07 -0300, <[EMAIL PROTECTED]> escribió:
>
> > So for example if I wanted to navigate to an encoded url
> >http://online.investools.com/landing.iedu?signedin=truerather than
> > justhttp://online.investools.com/landing.iedu  How would I do this?
> > How can I modify thescriptto urlencode these parameters:
> > {signedin:true} and to associate them with a specific url from the
> > urlList
>
> If you want to use GET, append '?' plus the encoded parameters to the
> desired url:
>
> py> data = {'signedin':'true', 'another':42}
> py> print urlencode(data)
> signedin=true&another=42
>
> Do not use the data argument to urlopen.
>
> --
> Gabriel Genellina

Sweet! I love this python group

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

is this a valid import sequence ?

[Stef Mientki]

This might be a very weird construction,
but it's the most easy way in translating another language into Python (for 
simulation).

Although it works, I like to know if this a valid construction:

I've defined a class, like this,
attaching a not yet defined global to itself

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,
and uses the global defined in the init of the class

def Write_LCD_Data ( data ):
 global LCD
 LCD.Write_Data ( data )

In another module a create one and only one instance of the class,
in the normal way:

   Graphical_LCD = T6963_device('', Pos=[196,240], Color=wx.CYAN, Timer_On=True)


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

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

[Eduardo \"EdCrypt\" O. Padoan]

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. But Psyco and ShedSkin could use the annotations the way
they want.

Function annotations, as PEP 3107 says, just adds "arbitrary metadata
annotations to Python functions" - If you follow the py-dev discutions
about it, it was only accepted because it have more possible uses then
just type checking. Also, there are many approches and different needs
for type checking/restrictions ("safety", IDEs autocompletion hints,
performance... )
So the annotations will be more a "signature documentation", so
different libraries can do whatever it want of it - I problably will
use only as documentation, like in:

def compile(source: "something compilable",
   filename: "where the compilable thing comes from",
   mode: "is this a single statement or a suite?"):


-- 
EduardoOPadoan (eopadoan->altavix::com)
Bookmarks: http://del.icio.us/edcrypt
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: comparing two lists and returning "position"

[hiro]

On Jun 22, 2:00 pm, hiro <[EMAIL PROTECTED]> wrote:
> On Jun 22, 1:58 pm, hiro <[EMAIL PROTECTED]> wrote:
>
>
>
> > On Jun 22, 1:56 pm, Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> wrote:
>
> > > In <[EMAIL PROTECTED]>, hiro wrote:
> > > > Hi once again, Charles.. I have tried your approach in my data set l2
> > > > and it keeps crashing on me,
> > > > bare in mind that I have a little over 10 million objects in my list
> > > > (l2) and l1 contains around 4 thousand
> > > > objects.. (i have enough ram in my computer so memory is not a
> > > > problem)
>
> > > > python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit
> > > > (Intel)] on win32
>
> > > > error is : ValueError: list.index(x): x not in list
>
> > > So you are saying you get this error with the value of `x` actually in the
> > > list!?  Somehow hard to believe.
>
> > > Ciao,
> > > Marc 'BlackJack' Rintsch
>
> > yes I do
>
> I doubled, trippled check my data already (even doing a search by hand
> using vim) and the data is fine.  Still looking into it though


hahaha, K found out what was wrong.. in the function computing
the data for l1 there was extra space was being put in.

ie:

l1 = [ 'abc ' 'ghi ' 'mno ' ]

and I didn't strip it properly after splitting it.. silly me,

well.. live and learn.. thanks guys

Cheers, -h

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

Re: configparser shuffles all sections ?

[Stef Mientki]

Nick Craig-Wood wrote:
> stef <[EMAIL PROTECTED]> wrote:
>>  I just used configparser for the first time and discovered that it 
>>  shuffled all my sections,
>>  and the contents of the sections too.
>>
>>  This makes human manipulation of the file impossible.
>>
>>  Is there a way to prevent this shuffling,
> 
> You could try getting yourself an ordered dictionary implmentation,
> say
> 
>   http://www.voidspace.org.uk/python/odict.html
> 
> Then doing something like this (untested)
> 
> class MyConfigParser(SafeConfigParser):
> def __init__(self, defaults=None):
> SafeConfigParser.__init__(defaults)
> self._sections = odict()
> self._defaults = odict()
> 

This might be good alternative,
I'll check that.

thank you all for the answers,
it's always good to know that I've not missed the simple solution ;-)

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