date:20111227

On Wed, Dec 28, 2011 at 4:34 PM, Rick Johnson
 wrote:
> I am also thinking that ANY quote char is a bad choice for string
> literal delimiters. Why? Well because it is often necessary to embed
> single or double quotes into a string literal.

Postgres allows dollar-delimited strings, which get around this issue somewhat.

http://www.postgresql.org/docs/9.1/static/sql-syntax-lexical.html#SQL-SYNTAX-DOLLAR-QUOTING

But for most strings, it simply makes sense to use a quote character.
Most strings don't need both ' and " in them.

You cannot pick one character to be your ultimate delimiter, because
there will always be occasion to embed it. (If nothing else, what
happens when you emit code?) You want the delimiter to be easily typed
and recognized, and that guarantees that it'll be something that's
going to want to be emitted. It's necessary to have multiple options,
or escaping.

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

user login session for stand alone PyQt

2011-12-27 Thread Panupat Chongstitwattana

For my current project I'm making PyQt GUI to be used inside Maya. One
of my requirement is that users need to first login with username and
password.

After authenticating the account, I'm not sure how I can store the
session. I tried Cookie.Simplecookie but I guess it doesn't wok
because the GUI is not running through HTTP.

Any suggestion appreciate.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Regular expressions

2011-12-27 Thread rusi

On Dec 27, 10:01 am, Fredrik Tolf  wrote:
> On Mon, 26 Dec 2011, mauricel...@acm.org wrote:
> > I've tried
>
> > re.sub('@\S\s[1-9]:[A-N]:[0-9]', '@\S\s', '@HWI-ST115:568:B08LLABXX:
> > 1:1105:6465:151103 1:N:0:')
>
> > but it does not seems to work.
>
> Indeed, for several reasons. First of all, your backslash sequences are
> interpreted by Python as string escapes. You'll need to write either "\\S"
> or r"\S" (the r, for raw, turns off backslash escapes).
>
> Second, when you use only "\S", that matches a single non-space character,
> not several; you'll need to quantify them. "\S*" will match zero or more,
> "\S+" will match one or more, "\S?" will match zero or one, and there are
> a couple of other possibilities as well (see the manual for details). In
> this case, you probably want to use "+" for most of those.
>
> Third, you're not marking the groups that you want to use in the
> replacement. Since you want to retain the entire string before the space,
> and the numeric element, you'll want to enclose them in parentheses to
> mark them as groups.
>
> Fourth, your replacement string is entirely wacky. You don't use sequences
> such as "\S" and "\s" to refer back to groups in the original text, but
> numbered references, to refer back to parenthesized groups in the order
> they appear in the regex. In accordance what you seemed to want, you
> should probably use "@\1/\2" in your case ("\1" refers back to the first
> parentesized group, which you be the first "\S+" part, and "\2" to the
> second group, which should be the "[1-9]+" part; the at-mark and slash
> are inserted as they are into the result string).
>
> Fifth, you'll probably want to match the last colon as well, in order not
> to retain it into the result string.
>
> All in all, you will probably want to use something like this to correct
> that regex:
>
> re.sub(r'@(\S+)\s([1-9]+):[A-N]+:[0-9]+:', r'@\1/\2',
>         '@HWI-ST115:568:B08LLABXX:1:1105:6465:151103 1:N:0:')
>
> Also, you may be interested to know that you can use "\d" instead of
> "[0-9]".
>
> --
>
> Fredrik Tolf

For practical 'get-the-hands-dirty' experience look at

python-specific:  http://kodos.sourceforge.net/
Online: http://gskinner.com/RegExr/
emacs-specific: re-builder and regex-tool http://bc.tech.coop/blog/071103.html
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Pythonification of the asterisk-based collection packing/unpacking syntax

On Wed, Dec 28, 2011 at 5:25 PM, Steven D'Aprano
 wrote:
> On Wed, 28 Dec 2011 15:06:37 +1100, Chris Angelico wrote:
>
>> ... suppose you have a huge
>> set/frozenset using tuples as the keys, and one of your operations is to
>> shorten all keys by removing their first elements. Current Python
>> roughly doubles the cost of this operation, since you can't choose what
>> type the tail is made into.
>
> The First Rule of Program Optimization:
> - Don't do it.
>
> The Second Rule of Program Optimization (for experts only):
> - Don't do it yet.
>
>
> Building syntax to optimize imagined problems is rarely a good idea. The
> difference between 2 seconds processing your huge set and 4 seconds
> processing it is unlikely to be significant unless you have dozens of
> such huge sets and less than a minute to process them all.
>
> And your idea of "huge" is probably not that big... it makes me laugh
> when people ask how to optimize code "because my actual data has HUNDREDS
> of items!". Whoop-de-doo. Come back when you have a hundred million
> items, then I'll take your question seriously.
>
> (All references to "you" and "your" are generic, and not aimed at Chris
> personally. Stupid English language.)

And what you're seeing there is the _best possible_ situation I could
think of, the strongest possible justification for new syntax.
Granted, that may say more about me and my imagination than about the
problem, but the challenge is open: Come up with something that
actually needs this.

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

Re: Python education survey

On Tue, 27 Dec 2011 18:42:05 -0800, Rick Johnson wrote:

> On Dec 27, 8:21 pm, Tim Chase  wrote:
> 
>> I'm glad you're open to learning more about English as "used to" is
>> perfectly acceptable according to the World English Dictionary[1] [...]
>> May you be found better for learning and come to give others the
>> benefit of the doubt.
> 
> I don't care what ANY dictionary says. Much less a "world" dictionary. I
> don't validate or invalidate a word based on some phony baloney group of
> pseudo intellectuals who decided one to day that writing a dictionary
> "might be cool". I am against these words and phrases because we already
> have words that work just fine. Why rock the boat?

Why do you say "rock" when the word "shake" is just as good?

Why do you say "boat" when we already have "ship"?

Why do you say "pseudo intellectuals" when you could say "fake 
intellectuals"?

Why do I waste my time reading your pretentious self-important nonsense?


[...]
> This is group has the most dumbest smart people i have ever met!

Considering I keep expecting you to stop trolling, I admit this applies 
to me.


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

Re: Py-dea: Streamline string literals now!

On Tue, 27 Dec 2011 21:34:19 -0800, Rick Johnson wrote:

> Now. If anyone can look at that mess and not admit it is a disaster,
> well then...

It isn't a disaster. A disaster is when people die, lose their houses, 
get tossed out into the street to starve, radioactive contamination 
everywhere, floods, fire, the first born of every family being struck 
down suddenly, that sort of thing. Not having eight ways to write string 
literals. That's merely a convenience.

> I am also thinking that ANY quote char is a bad choice for string
> literal delimiters. Why? Well because it is often necessary to embed
> single or double quotes into a string literal. We need to use a
> delimiter that is not a current delimiter elsewhere in Python, and also,
> is a very rare char. I believe Mr Ewing found that perfect char in his
> "Multi-line uber raw string literals!" (Just scroll down a bit at this
> link)...
> 
> http://www.cosc.canterbury.ac.nz/greg.ewing/python/ideas.html

Not surprisingly, you haven't thought this through. I'm sure Greg Ewing 
has, which is why he hasn't proposed *replacing* string delimiters with 
his multi-line format. That's why he proposed it as a *statement* and not 
string-builder syntax.

Without an end-delimiter, how do you embed string literals in expressions?

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

Re: Pythonification of the asterisk-based collection packing/unpacking syntax

On Wed, 28 Dec 2011 15:06:37 +1100, Chris Angelico wrote:

> On Wed, Dec 28, 2011 at 10:10 AM, Steven D'Aprano
>  wrote:
>> Your original use-case, where you want to change the type of tail from
>> a list to something else, is simply solved by one extra line of code:
>>
>> head, *tail = sequence
>> tail = tuple(tail)
> 
> That achieves the goal of having tail as a different type, but it does
> have the additional cost of constructing and then discarding a temporary
> list. I know this is contrived, but suppose you have a huge
> set/frozenset using tuples as the keys, and one of your operations is to
> shorten all keys by removing their first elements. Current Python
> roughly doubles the cost of this operation, since you can't choose what
> type the tail is made into.

The First Rule of Program Optimization:
- Don't do it.

The Second Rule of Program Optimization (for experts only):
- Don't do it yet.

Building syntax to optimize imagined problems is rarely a good idea. The 
difference between 2 seconds processing your huge set and 4 seconds 
processing it is unlikely to be significant unless you have dozens of 
such huge sets and less than a minute to process them all.

And your idea of "huge" is probably not that big... it makes me laugh 
when people ask how to optimize code "because my actual data has HUNDREDS 
of items!". Whoop-de-doo. Come back when you have a hundred million 
items, then I'll take your question seriously.

(All references to "you" and "your" are generic, and not aimed at Chris 
personally. Stupid English language.)

> But if that's what you're trying to do, it's probably best to slice
> instead of unpacking.

Assuming the iterable is a sequence.

Fortunately, most iterable constructors accept iterators directly, so for 
the cost of an extra line (three instead of two), you can handle data 
structures as big as will fit into memory:

# I want to keep both the old and the new set
it = iter(huge_set_of_tuples)
head = next(it)  # actually an arbitrary item
tail = set(x[1:] for x in it)  # and everything else

If you don't need both the old and the new:

head = huge_set_of_tuples.pop()
tail = set()
while huge_set_of_tuples:
tail.add(huge_set_of_tuples.pop()[1:])
assert huge_set_of_tuples == set([])

If you rely on language features, who knows how efficient the compiler 
will be?

head, tail::tuple = ::sequence

may create a temporary list before building the tuple anyway. And why 
not? That's what this *must* do:

head, second, middle::tuple, second_from_last, last = ::iterator

because tuples are immutable and can't be grown or shrunk, so why assume 
the language designers special cased the first form above?

> Fortunately, the Zen of Python "one obvious way to
> do it" doesn't stop there being other ways that work too.

Exactly. It is astonishing how many people think that if there isn't a 
built-in language feature, with special syntax, to do something, there's 
a problem that needs to be solved.

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

google form filling

2011-12-27 Thread angle 9

google form filling
http://gsonlinejobs.yolasite.com/

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

google form filling

2011-12-27 Thread angle 9

google form filling
http://gsonlinejobs.yolasite.com/

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

Re: Python education survey

2011-12-27 Thread rusi

On Dec 27, 11:26 pm, Andrew Berg  wrote:
> On 12/27/2011 11:59 AM, K Richard Pixley wrote:> You'd do better to encourage 
> eclipse, but setting that up isn't
> > trivial either.
>
> IIRC, all I had to do to set up PyDev was copy a URL to Eclipse's
> "Install New Software" wizard, and have Eclipse download and install it.
> Extra steps are needed if a different implementation of Python (e.g.
> Jython) is needed, but other than that, the user only needs to specify a
> couple options (e.g. Python grammar version) at project creation time.
> This assumes that Python is already installed, but why wouldn't it be?

There was a recent announcement about eclipse for python (pydev)
http://www.mail-archive.com/python-list@python.org/msg320434.html

It did not work for me -- got a backtrace.  I responded with that.
There was no further response.
Just mentioning that at least in some cases it does not 'just work.'
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Py-dea: Streamline string literals now!

On Dec 27, 9:49 pm, Rick Johnson  wrote:

> The fact is...even with the multi-line issue solved, we still have two
> forms of literal delimiters that encompass two characters resulting in
> *four* possible legal combinations of the exact same string! I don't
> know about you guys, but i am not a big fan of Tim Towtdi.

actually i was a bit hasty with that statment and underestimated the
actual number of possiblities.

1) "this is a string"
2) 'this is a string'
3) r"this is a string"
4) r'this is a string'
5) '''this is a string'''
6) """this is a string"""
7) r'''this is a string'''
8) r"""this is a string"""

A) "this is difficult to \"eyeball parse\""
B) """this is "overkill
C) "that's just plain \"nuts\"!"

Now. If anyone can look at that mess and not admit it is a disaster,
well then...

I am also thinking that ANY quote char is a bad choice for string
literal delimiters. Why? Well because it is often necessary to embed
single or double quotes into a string literal. We need to use a
delimiter that is not a current delimiter elsewhere in Python, and
also, is a very rare char. I believe Mr Ewing found that perfect char
in his "Multi-line uber raw string literals!" (Just scroll down a bit
at this link)...

http://www.cosc.canterbury.ac.nz/greg.ewing/python/ideas.html

...however, requiring a programmer to start EVERY line with a marker
does not seem like fun to me. And just think what a nightmare it will
be to modify copy/pasted data with line markers! Although it does
solve the "indention" issue with doc-strings! I think just for foreign
language compatibility reasons we should stick with one of either " or
' (or maybe both), but allowing [r]""" and [r]''' is just WAY too
much! We need to trim this fat.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Py-dea: Streamline string literals now!

On Dec 27, 10:17 pm, Chris Angelico  wrote:
> On Wed, Dec 28, 2011 at 2:49 PM, Rick Johnson
>
>  wrote:
> > My proposal is to introduce a single delimiter for string literals. A
> > new string literal that is just as good at spanning single lines as it
> > is spanning multiple lines. A new literal that uses widely known
> > markup tag syntax instead of cryptic and noisy escape sequences. And
> > finally, a *literal* that is worthy of the 21st century.
>
> So all you're doing is introducing a different form of escaping.

Well that is but one of the proposals. The others include reducing
four combinations of string literals into one, and by default,
spanning multiple lines with one syntax.

> You
> can already achieve this with regular expressions in several engines -
> declare a different delimiter and/or escape character - in order to
> dodge the issue of multiple escapes.

I am specifically referring to the Python language and how the
interpreter "interprets" string literals. Wait, you do share the same
definition of "string literal" as i do, i hope?

http://en.wikipedia.org/wiki/String_literal

> Python already has raw strings
> for the same reason (although the rules governing raw strings are
> oddly complex in edge cases).

Raw strings would be history with my proposal. No more need for raw
strings. This is the string literal to rule all string literals!

> Your proposal sounds like a good idea for a specific-situation config
> file, but a very bad idea for Python.

Can you give specific reasons why?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: RSA and Cryptography in PYTHON

2011-12-27 Thread Paul Rubin

8 Dihedral  writes:
>> How about the nontrivial decoding part ?
> I am getting lousy in the news group in my writing?
> I mean the non-trivial decoding of the key decomposition. 

I still don't have the slightest idea what you are asking for.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Py-dea: Streamline string literals now!

On Tue, 27 Dec 2011 19:49:12 -0800, Rick Johnson wrote:

> I believe that with the ubiquitous-ness of syntax highlight, string
> literals only need one delimiter.  In the old days (before syntax
> highlight was invented) i could understand how a programmer "might" miss
> a single (or even a triple!) closing delimiter; but those days died with
> the king.

http://en.wikipedia.org/wiki/List_of_current_monarchs

Thank you Rick for another non-solution to a non-problem.

How is that fork of Python going? You promised us you would revitalise 
the community with a new fork of Python that throws out all the 
accumulated cruft of the language. I'm sure that the silent majority who 
agree with you are hanging out for your first release. I know I am.

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

Re: Py-dea: Streamline string literals now!

On Wed, Dec 28, 2011 at 2:49 PM, Rick Johnson
 wrote:
> My proposal is to introduce a single delimiter for string literals. A
> new string literal that is just as good at spanning single lines as it
> is spanning multiple lines. A new literal that uses widely known
> markup tag syntax instead of cryptic and noisy escape sequences. And
> finally, a *literal* that is worthy of the 21st century.

So all you're doing is introducing a different form of escaping. You
can already achieve this with regular expressions in several engines -
declare a different delimiter and/or escape character - in order to
dodge the issue of multiple escapes. Python already has raw strings
for the same reason (although the rules governing raw strings are
oddly complex in edge cases).

Your proposal sounds like a good idea for a specific-situation config
file, but a very bad idea for Python. If you want elaboration on that,
ask me for my arguments on CSV vs /etc/passwd. Or search the web for
the same topic, I'm sure many others have made the same points.

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

Re: Pythonification of the asterisk-based collection packing/unpacking syntax

On Wed, Dec 28, 2011 at 10:10 AM, Steven D'Aprano
 wrote:
> Your original use-case, where you want to change the type of tail from a
> list to something else, is simply solved by one extra line of code:
>
> head, *tail = sequence
> tail = tuple(tail)

That achieves the goal of having tail as a different type, but it does
have the additional cost of constructing and then discarding a
temporary list. I know this is contrived, but suppose you have a huge
set/frozenset using tuples as the keys, and one of your operations is
to shorten all keys by removing their first elements. Current Python
roughly doubles the cost of this operation, since you can't choose
what type the tail is made into.

But if that's what you're trying to do, it's probably best to slice
instead of unpacking. Fortunately, the Zen of Python "one obvious way
to do it" doesn't stop there being other ways that work too.

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

Re: Python education survey

On Wed, Dec 28, 2011 at 1:42 PM, Rick Johnson
 wrote:
> I don't care what ANY dictionary says. Much less a "world" dictionary.
> I don't validate or invalidate a word based on some phony baloney
> group of pseudo intellectuals who decided one to day that writing a
> dictionary "might be cool".

Finally we know who Ranting Rick is the alt of. He's Humpty Dumpty!

http://en.wikisource.org/wiki/Through_the_Looking-Glass,_and_What_Alice_Found_There/Chapter_VI

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

Py-dea: Streamline string literals now!

Hello folks,

In a recent thread i stumbled upon an epiphany of sorts concerning
Python string literals, with implications that trickle down to all
forms of string literals used in general programming, since, for the
most part, the syntax is virtually the same!

For all our lives we have been excepting a standard for string
literals that is, quite literally, overkill. It seems all along the
syntax has been flawed, however, we have been totally unaware... until
now!

*[A brief history lesson]*

Python offers two main styles of delimiting string literals:
 * single "leading and trailing" double, or single quote chars.
 * triple "leading and trailing" double, or single quote chars.

The single leading group is intended for one line literals whereas the
triple is intended for multi-line literals.

Now, in my initial days of Python-ing, i thought this was a great
system. Unlike most languages that require a programmer to concatenate
strings over and over again, python "seemed" to solve the multi-line
issue -- but there is a greater issue!

*[Current Issues]*

The fact is...even with the multi-line issue solved, we still have two
forms of literal delimiters that encompass two characters resulting in
*four* possible legal combinations of the exact same string! I don't
know about you guys, but i am not a big fan of Tim Towtdi.

But the problems just keep adding up. There is also the issue of
escape sequences; which i have always found to be atrociousness noisy.
Everyone who has had to deal with double escapes in regexps raise your
hand. The frowns are deafening.

The simple fact is: The current syntax for string literals is not only
deficient, it is bloated, noisy, and confusing!

*[Solution]*

I believe that with the ubiquitous-ness of syntax highlight, string
literals only need one delimiter.  In the old days (before syntax
highlight was invented) i could understand how a programmer "might"
miss a single (or even a triple!) closing delimiter; but those days
died with the king.

My proposal is to introduce a single delimiter for string literals. A
new string literal that is just as good at spanning single lines as it
is spanning multiple lines. A new literal that uses widely known
markup tag syntax instead of cryptic and noisy escape sequences. And
finally, a *literal* that is worthy of the 21st century.

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

Re: Which libraries for Python 2.5.2

2011-12-27 Thread Dave Angel


On 12/27/2011 10:31 PM, W. eWatson wrote:

On 12/27/2011 6:27 PM, Ian Kelly wrote:


http://www.dll-files.com/dllindex/dll-files.shtml?msvcp71 (or just
find it on another Windows XP PC) and copy it into
C:\Windows\System32.  Don't forget to run regsvr32 to register it.

HTH,
Ian
You are very likely right about the spelling. I wrote it down, and 
carried it to this PC. Sometimes I can't read my own writing.


I've never used regsvr32, but I would guess it's entered into the Run 
(simple dialog for MS tools like regedit) selection off the Start menu.


Of course not.  You run it from the same command window (aka DOS box, or 
cmd window) you've been doing all your other testing from.  And like all 
good commands, it has built-in help so you can see what the argument 
list looks like.


--

DaveA

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

Re: Which libraries for Python 2.5.2


On 12/27/2011 6:27 PM, Ian Kelly wrote:

On Tue, Dec 27, 2011 at 6:21 PM, W. eWatson  wrote:

Well, it found several problems. These DLLs
MSVCP1
EFSADU
MSJAVA.


I'm guessing MSVCP1 is a typo for MSVCP71?  If that is missing then
that is probably the culprit.  That DLL is the C runtime library.  It
is supposed to be shipped with applications that need it, but it is so
ubiquitous that it is often assumed to be present or forgotten.  You
can download it from
http://www.dll-files.com/dllindex/dll-files.shtml?msvcp71 (or just
find it on another Windows XP PC) and copy it into
C:\Windows\System32.  Don't forget to run regsvr32 to register it.

HTH,
Ian
You are very likely right about the spelling. I wrote it down, and 
carried it to this PC. Sometimes I can't read my own writing.


I've never used regsvr32, but I would guess it's entered into the Run 
(simple dialog for MS tools like regedit) selection off the Start menu.

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

Re: Python education survey

On Dec 27, 8:21 pm, Tim Chase  wrote:

> I'm glad you're open to learning more about English as "used to"
> is perfectly acceptable according to the World English Dictionary[1]
> [...]
> May you be found better for learning and come to give others the
> benefit of the doubt.

I don't care what ANY dictionary says. Much less a "world" dictionary.
I don't validate or invalidate a word based on some phony baloney
group of pseudo intellectuals who decided one to day that writing a
dictionary "might be cool". I am against these words and phrases
because we already have words that work just fine. Why rock the boat?

Why would you use a word like "hard" (which describes the physical
properties of a tangible object),  to describe how "difficult" a task
may be? If you insist on this lunacy, then why not use "soft" to
describe how easy a task may be? Seems ridiculous now, huh?

Garbage Verbiage Translator:
 Used to -> previously|before
 Supposed to -> required|expected
 Use to -> accustomed|acquainted
 Right (OOC) -> Correct
 Hard (OOC) -> Difficult
 Pretty (OOC) -> very

This is group has the most dumbest smart people i have ever met!
-- 
http://mail.python.org/mailman/listinfo/python-list

Online Data Entry Jobs Without Investment http://ponlinejobs.yolasite.com/

2011-12-27 Thread prabhakaran k

Online Data Entry Jobs Without Investment
http://ponlinejobs.yolasite.com/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Which libraries for Python 2.5.2

On Tue, Dec 27, 2011 at 6:21 PM, W. eWatson  wrote:
> Well, it found several problems. These DLLs
> MSVCP1
> EFSADU
> MSJAVA.

I'm guessing MSVCP1 is a typo for MSVCP71?  If that is missing then
that is probably the culprit.  That DLL is the C runtime library.  It
is supposed to be shipped with applications that need it, but it is so
ubiquitous that it is often assumed to be present or forgotten.  You
can download it from
http://www.dll-files.com/dllindex/dll-files.shtml?msvcp71 (or just
find it on another Windows XP PC) and copy it into
C:\Windows\System32.  Don't forget to run regsvr32 to register it.

HTH,
Ian
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python education survey

2011-12-27 Thread Tim Chase


On 12/27/11 19:56, Rick Johnson wrote:

On Dec 27, 3:44 pm, Eelco
wrote:


Despite the fact that you mis-attributed that quote to me,
im going to be a little bit offended in the name of its
actual author anyway. Thats a lot of words to waste on your
linguistic preferences. Personally, I reserve the right to
botch my non-native languages as much as I please.


I hope you're just joking a bit because i have little respect
for those who refuse to better themselves. If you are learning
English as a second language then you have a legitimacy
excuse, but at some point that excuse just becomes a lie.


I'm glad you're open to learning more about English as "used to" 
is perfectly acceptable according to the World English Dictionary[1]


"""
2.  	(takes an infinitive or implied infinitive) used as an 
auxiliary to express habitual or accustomed actions, states, etc, 
taking place in the past but not continuing into the present: I 
don't drink these days, but I used to; I used to fish here every day

"""

May you be found better for learning and come to give others the 
benefit of the doubt.


-tkc

[1]
http://dictionary.reference.com/browse/used%20to



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

Re: Python education survey

On Dec 27, 7:21 pm, 8 Dihedral 
wrote:
> There are Dr.Python, Pycrust and  Notepadplus to support writing python 
> programs.

I really like Pycrust. It's written in Python, it's code base is
structured in a professional manner (IDLE you should be jealous!), and
it works well. However, it is dependent on WxPython; so that's right
out.

> IDLE is OK, but if a program failed inside IDLE, then I  might have
> to kill the old IDLE and restart IDLE again.

Yes, i've had to kill many frozen instances of IDLE. It gets
aggravating.

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

Re: Python education survey

On Dec 27, 3:44 pm, Eelco  wrote:

> Despite the fact that you mis-attributed that quote to me, im going to
> be a little bit offended in the name of its actual author anyway.
> Thats a lot of words to waste on your linguistic preferences.
> Personally, I reserve the right to botch my non-native languages as
> much as I please.

I hope you're just joking a bit because i have little respect for
those who refuse to better themselves. If you are learning English as
a second language then you have a legitimacy excuse, but at some point
that excuse just becomes a lie. In any case, i apologize for mis-
quoting you.

> > I always though "run" was a perfect verb for "running" code... but who
> > knows :)
>
> Im assuming the audience is familiar with an ipod, but not an IDE, or
> programming in general. To their eyes, it looks like a 'play' button;

I would be very careful about introducing new words, or borrowing
words, to replace tried and true technical terms that have existed for
along time. As a matter of fact, the BDFL make the point better than i
ever could:

GvR speaking about ABC's design: """ The ABC group assumed that the
users had no prior computer experience (or were willing to forget it).
Thus, alternative terminology was introduced that was considered more
"newbie-friendly" than standard programming terms. For example:
procedures were called "how-tos" and variables "locations". """
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Pythonification of the asterisk-based collection packing/unpacking syntax

On Dec 27, 5:10 pm, Steven D'Aprano  wrote:
> On Sun, 25 Dec 2011 07:47:20 -0800, Eelco wrote:
> Your original use-case, where you want to change the type of tail from a
> list to something else, is simply solved by one extra line of code:
>
> head, *tail = sequence
> tail = tuple(tail)

i wonder if we could make this proposal a bit more "Pythonic"? Hmm...

head, tuple(tail) = sequence

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

Re: Which libraries for Python 2.5.2


On 12/27/2011 2:58 PM, Ian Kelly wrote:

On Tue, Dec 27, 2011 at 2:35 PM, W. eWatson  wrote:

I replaced numpy and matplotlib, and added scipy. I still get errors, but
perhaps because the install order is now wrong. It was
numpy
matplotlib

Does anyone know the right order?


The order (numpy, scipy, matplotlib) reflects the dependencies, but
since the installers are just fancied-up self-extracting zips, I don't
think it should matter.


OK, I installed it. Is there an easy way to go to track down this dll.
There's a Help, but I can't print it from the PC I have it on.


It should be reasonably self-explanatory, I think.  Just start
Dependency Walker, open up the _path.pyd file, and it will show you
the full dependency tree.  Below that is a list of all the modules,
and any missing dependencies should helpfully show up right at the top
of the list.

Note that missing delay-load dependencies (those with an hourglass
icon) are not necessarily problems.  Since the error occurs at
load-time, you're looking for a missing module that would be loaded
immediately.
I was too timid. When I saw File->Open, I thought I was going to have to 
open a file, thinking what file could it be?


Well, it found several problems. These DLLs
MSVCP1
EFSADU
MSJAVA.

There may be 100 file.

Issues found:
required dependency not found
delay-dependency not found
one nodule unresolved ... missing delay-dependency module

Perhaps the next step is to download a fresh version of matplotlib?
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python education survey

2011-12-27 Thread 88888 Dihedral

There are Dr.Python, Pycrust and  Notepadplus to support writing python 
programs. 

IDLE is OK, but if a program failed inside IDLE, then I  might have 
to kill the old IDLE and restart IDLE again.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Possible bug in string handling (with kludgy work-around)

On Dec 27, 3:38 pm, Terry Reedy  wrote:
> On 12/27/2011 1:04 PM, Rick Johnson wrote:
>
> > But this brings up a very important topic. Why do we even need triple
> > quote string literals to span multiple lines? Good question, and one i
> > have never really mused on until now.
>
> I have, and the reason I thought of is that people, including me, too
> ofter forget or accidentally fail to properly close a string literal,

Yes, agreed.

> Color coding editors make it easier to catch such errors, but they were
> less common in 1991.

I would say the need for triple quote strings has passed long ago.
Like you say, since color lexers are ubiquitous now we don't need
them.

> And there is still uncolored interactive mode.

I don't see interactive command line programming as a problem. I mean,
who drops into a cmd line and starts writing paragraphs of string
literals? Typically, one would just make a few one-liner calls here or
there. Also, un-terminated string literal errors can be very
aggravating. Not because they are difficult to fix, no, but because
they are difficult to find! -- and sending me an error message
like...

 "Exception: Un-terminated string literal meets EOF! line: 50,466,638"

... is about as helpful as a bullet in my head!

If the interpreter finds itself at EOF BEFORE a string closes, don't
you think it would be more helpful to include the currently "opened"
strings START POSITION also? Heck, it would be wonderful to only have
the start position since the likely-hood of a string ending at EOF is
astronomical!

As an intelligent lad must know, the odds that the distance from any
given string's start position to it's end position is more likely to
be shorter than the distance from the string's beginning to the
freaking EOF! Ruby and Python are both guilty of this atrocity.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: RSA and Cryptography in PYTHON

2011-12-27 Thread 88888 Dihedral

8 Dihedral於 2011年12月26日星期一UTC+8上午3時58分28秒寫道：
> Long integer is really excellent in Python. 
> 
> Encoding RSA 2048bits  in a simple and elegant way in Python
> is almost trivial. 
> 
> How about the nontrivial decoding part ?

I am getting lousy in the news group in my writing?

I mean the non-trivial decoding of the key decomposition. 
Of course RSA is symmetric in encoding and decoding of data.   
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Slices when extending python with C++

2011/12/27  :
> Hallo,
> I have kind of special question when extening python with C++
> implemented modules.
>
> I try to implement a class, behaving also like an array. And I need
> to implement slice-getters. I implemented PySequenceMethods.sq_slice
> to get "simple" slices like:
>
> myobj[x:y]
>
> It works perfectly, without problems. But now I have a problem when
> need to access the array with "special" slices, like:
>
> myobj[x:y:step]
> myobj[::-1]  # to revert the array
>
> I would like to ask which method must be implemented to get this
> "special" slice getters. The "simple" slice
> PySequenceMethods.sq_slice getter accepts only two indexes - from,
> to, but not a step (which would solve the issue).

I'm not entirely certain about the C API, but in Python the
__getslice__ and __setslice__ methods do not support extended slicing
and have been deprecated and removed in Python 3.  The practice
instead is to implement __getitem__ and __setitem__ and check the type
of the key object passed in.  For slicing, the object passed in will
be a slice object, which contains start, stop, and step attributes.
For example:

class MySequence(object):
def __getitem__(self, key):
if isinstance(key, slice):
# return a subsequence using key.start, key.stop, key.step
else:
# return a single item indexed by key

HTH,
Ian
-- 
http://mail.python.org/mailman/listinfo/python-list

[no subject]

2011-12-27 Thread rozelak

Hallo,
I have kind of special question when extening python with C++
implemented
modules.
I try to implement a class, behaving also like an array. And I need
to
implement slice-getters. I implemented PySequenceMethods.sq_slice to
get
"simple" slices like:
myobj[x:y]
It works perfectly, without problems. But now I have a problem when
need to
access the array with "special" slices, like:
myobj[x:y:step]
myobj[::-1]  # to revert the array
I would like to ask which method must be implemented to get this
"special"
slice getters. The "simple" slice PySequenceMethods.sq_slice getter
accepts
only two indexes - from, to, but not a step (which would solve the
issue).
Thank you very much for your ansver, best regards
Dan T.

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

Re: Pythonification of the asterisk-based collection packing/unpacking syntax

On Sun, 25 Dec 2011 07:47:20 -0800, Eelco wrote:

> Explicit and implicit are not well-defined terms, 

We can at least agree on that.

> but I would say that
> at the moment the signal is implicit, in the sense that one cannot see
> what is going on by considering the rhs in isolation. 

That is a ridiculous argument. If you ignore half the statement, of 
course you can't tell what is going on.

> Normally in
> python, an assignment just binds the rhs to the identifiers on the lhs,
> but in case of collection (un)packing, this rule that holds almost all
> of the time is broken, and the assignment statement implies a far more
> complicated construct, with a far more subtle meaning, and non-constant
> time complexity.

Python assignment in general is not constant time.

If the left hand side is a single identifier (a name, a dotted attribute, 
a subscription or slice, etc.) then the assignment is arguably constant 
time (hand-waving away complications like attribute access, hash table 
collisions, descriptors, etc.); but if the left hand side is a list of 
targets, e.g.:

a, b, c = sequence

then the assignment is O(N). Python has to walk the sequence (actually, 
any iterator) and assign each of N items to N identifiers, hence O(N) not 
O(1).

The trivial case of a single value on the left hand side:

x = 1

is just the degenerate case for N=1.

> Thats not a terrible thing, but a little extra explicitness there would
> not hurt, 

I think it will. It makes the assignment more verbose to no benefit.

> and like I argued many times before, it is a nice unification
> with the situation where the unpacking can not be implicit, like inside
> a function call rather than assignment.

That's one opinion; but there's no need for any "extra explicitness" 
since the definition of assignment in Python already explicitly includes 
iterable unpacking. How much explicitness do you need?

>>     n = len(::sequence)
> 
> Now you are just discrediting yourself in terms of having any idea what
> you are talking about.

::sequence is redundant and unnecessary whether it is inside a function 
call to len or on the right hand side of an assignment. In both cases, it 
adds nothing to the code except noise.

Your proposal is surreal. You started off this conversation arguing that 
the existing idiom for extended iterator unpacking, e.g.

head, *tail = sequence

is too hard to understand because it uses punctuation, and have ended up 
recommending that we replace it with:

head, tail:: = ::sequence 

instead (in the generic case where you don't want to use a different type 
for tail).

Your original use-case, where you want to change the type of tail from a 
list to something else, is simply solved by one extra line of code:

head, *tail = sequence
tail = tuple(tail)

You have written thousands of words to save one line in an idiom which 
you claim is very uncommon. Perhaps your understanding of "pythonic" is 
not as good as you imagine.

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

Re: Pythonification of the asterisk-based collection packing/unpacking syntax

On Mon, 26 Dec 2011 13:51:50 -0800, Eelco wrote:
[...]
>> If your point is that parens are used more often than
>> packing/unpacking, that's almost certainly true, since function calls
>> (including method invocations) are so prevalent in pretty much any
>> code. But what does that prove?
> 
> That proves the original point of contention: that the below* is
> suboptimal language design, 

Well duh.

I was mocking the idea that the meaning of * is context-dependent is a 
bad thing by pointing out that we accept context-dependent meaning for 
round brackets () without any difficulties. Of course it is "suboptimal 
language design" -- it couldn't fail to be. Context-dependency is not 
necessarily a bad thing.

> not because terseness always trumps
> verbosity, but because commonly-used constructs (such as parenthesis or
> round brackets or whatever you wish to call them) 

Parentheses are not a construct. They are symbols (punctuation marks) 
which are applied to at least three different constructs: grouping, 
function calls, class inheritance lists.

> are more deserving of
> the limited space in both the ascii table and your reflexive memory,
> than uncommonly used ones.

Right. And since sequence packing and unpacking is a common idiom, it 
deserves to be given punctuation. That's my opinion.

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

Slices when extending python with C++

2011-12-27 Thread rozelak

Hallo,
I have kind of special question when extening python with C++
implemented modules.

I try to implement a class, behaving also like an array. And I need
to implement slice-getters. I implemented PySequenceMethods.sq_slice
to get "simple" slices like:

myobj[x:y]

It works perfectly, without problems. But now I have a problem when
need to access the array with "special" slices, like:

myobj[x:y:step]
myobj[::-1] # to revert the array

I would like to ask which method must be implemented to get this
"special" slice getters. The "simple" slice
PySequenceMethods.sq_slice getter accepts only two indexes - from,
to, but not a step (which would solve the issue).

Thank you very much for your ansver, best regards
Dan T.

--
Tradiční i moderní adventní a novoroční zvyky, sváteční jídlo a
pití, výzdoba a dárky... - čtěte vánoční a silvestrovský speciál
portálu VOLNÝ.cz na http://web.volny.cz/data/click.php?id=1301
Hallo,I have kind of special question when extening python with C++ implemented modules.I try to implement a class, behaving also like an array. And I need to implement slice-getters. I implemented PySequenceMethods.sq_slice to get "simple" slices like: myobj[x:y]It works perfectly, without problems. But now I have a problem when need to access the array with "special" slices, like: myobj[x:y:step] myobj[::-1] # to revert the array I would like to ask which method must be implemented to get this "special" slice getters. The "simple" slice PySequenceMethods.sq_slice getter accepts only two indexes - from, to, but not a step (which would solve the issue). Thank you very much for your ansver, best regardsDan T. --
http://mail.python.org/mailman/listinfo/python-list

Slices when extending python with C++

2011-12-27 Thread rozelak

Hallo,
I have kind of special question when extening python with C++
implemented modules.

I try to implement a class, behaving also like an array. And I need
to implement slice-getters. I implemented PySequenceMethods.sq_slice
to get "simple" slices like:

myobj[x:y]

It works perfectly, without problems. But now I have a problem when
need to access the array with "special" slices, like:

myobj[x:y:step]
myobj[::-1]  # to revert the array

I would like to ask which method must be implemented to get this 
"special" slice getters. The "simple" slice
PySequenceMethods.sq_slice getter accepts only two indexes - from,
to, but not a step (which would solve the issue).

Thank you very much for your ansver, best regards
Dan T.



-- 
Tradiční i moderní adventní a novoroční zvyky, sváteční jídlo a
pití, výzdoba a dárky... - čtěte vánoční a silvestrovský speciál
portálu VOLNÝ.cz na http://web.volny.cz/data/click.php?id=1301

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

Re: Which libraries for Python 2.5.2

On Tue, Dec 27, 2011 at 2:35 PM, W. eWatson  wrote:
> I replaced numpy and matplotlib, and added scipy. I still get errors, but
> perhaps because the install order is now wrong. It was
> numpy
> matplotlib
>
> Does anyone know the right order?

The order (numpy, scipy, matplotlib) reflects the dependencies, but
since the installers are just fancied-up self-extracting zips, I don't
think it should matter.

> OK, I installed it. Is there an easy way to go to track down this dll.
> There's a Help, but I can't print it from the PC I have it on.

It should be reasonably self-explanatory, I think.  Just start
Dependency Walker, open up the _path.pyd file, and it will show you
the full dependency tree.  Below that is a list of all the modules,
and any missing dependencies should helpfully show up right at the top
of the list.

Note that missing delay-load dependencies (those with an hourglass
icon) are not necessarily problems.  Since the error occurs at
load-time, you're looking for a missing module that would be loaded
immediately.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Pythonification of the asterisk-based collection packing/unpacking syntax

On Mon, 26 Dec 2011 13:41:34 -0800, Eelco wrote:

> On Dec 25, 6:05 pm, Steven D'Aprano  +comp.lang.pyt...@pearwood.info> wrote:
>> On Sun, 25 Dec 2011 07:38:17 -0800, Eelco wrote:
[...]

>> > How is 'head, *tail = sequence' or semantically entirely
>> > equivalently, 'head, tail::list = sequence' any different then? Of
>> > course after interpretation/compilation, what it boils down to is
>> > that we are constructing a list and binding it to the identifier
>> > tail, but that is not how it is formulated in python as a language
>>
>> I'm afraid it is.
>>
>> Here's the definition of assignment in Python 3:
>> http://docs.python.org/py3k/reference/simple_stmts.html#assignment-
>> statements
> 
> Que?

You have claimed that "constructing a list and binding it to the 
identifier" is not how iterator unpacking is formulated in Python the 
language. But that is wrong. That *is* how iterator unpacking is 
formulated in Python the language. The reference manual goes into detail 
on how assignment is defined in Python. You should read it.

> 'head, *tail = sequence'
> 
> Is how one currently unpacks a head and tail in idiomatic python
> 
> This is semantically equivalent to
> 
> 'head = sequence[0]'
> 'tail = list(sequence[1:])'

There's a reason this feature is called *iterable* unpacking: it operates 
on any iterable object, not just indexable sequences. 

'head, *tail = sequence' is not just semantically equivalent to, but 
*actually is* implemented as something very close to:

temp = iter(sequence)
head = next(temp)
tail = list(temp)
del temp

Extended iterable unpacking, as in 'head, *middle, tail = sequence' is a 
little more complex, but otherwise the same: it operates using the 
iterator protocol, not indexing. I recommend you read the PEP, if you 
haven't already done so.

http://www.python.org/dev/peps/pep-3132/

> But these forms are linguistically different, in too many different ways
> to mention.

How about mentioning even one way? Because I have no idea what 
differences you are referring to, or why you think they are important.

>> > We dont have
>> > something of the form 'tail = list_tail(sequence)'.
>>
>> I'm afraid we do. See the definition of assignment again.
> 
> Que?

Again, you make a claim about Python which is contradicted by the 
documented behaviour of the language. You claim that we DON'T have 
something of the form 'tail = list_tail(sequence)', but that is *exactly* 
what we DO have: extracting the tail from an iterator.

Obviously there is no built-in function "list_tail" but we get the same 
effect by just using list() on an iterator after advancing past the first 
item.

> My claim is that the two semantically identical formulations above do
> not have isomorphic linguistic form. As far as I can make sense of your
> words, you seem to be disputing this claim, but its a claim as much
> worth debating as that the sun rises in the east.

"Isomorphic linguistic form"? Are you referring to the idea from 
linguistics that there are analogies between the structure of phonic and 
semantic units? E.g. that the structures (phoneme, syllable, word) and 
(sememe, onomateme, sentence) are analogous.

I don't see why this is relevant, or which units you are referring to -- 
the human-language description of what Python does, high-level Python 
language features, Python byte-code, or machine code. Not that it 
matters, but it is unlikely that any of those are isomorphic in the 
linguistic sense, and I am not making any general claim that they are.

If not, I have no idea what you are getting at, except possibly trying to 
hide behind obfuscation.

>> > Rather, we annotate
>> > the identifier 'tail' with an attribute that unquestionably
>> > destinates it to become a list*. It is no longer that 'tail' will
>> > just take anything that pops out of the expression on the right hand
>> > side;
>>
>> Of course it will. Python is a dynamically typed language. It doesn't
>> suddenly develop static types to ensure that 'tail' becomes a list;
>> 'tail' is bound to a list because that's what the assignment statement
>> provides.
> 
> How python accomplishes any of this under the hood is entirely
> immaterial. The form is that of a compile-time type constraint,
> regardless of whether the BDFL ever thought about it in these terms.

Compile-time type constraints only have meaning in statically-typed 
languages. Otherwise, you are applying an analogy that simply doesn't 
fit, like claiming that the motion of paper airplanes and birds are 
equivalent just because in English we use the word "fly" to describe them 
both.

The differences between what Python actually does and compile-time type-
constraints are greater than the similarities.

Similarities:

(1) In both cases, 'tail' ends up as a list.

Differences:

(1) Compiler enforces the constraint that the identifier 'tail' is always 
associated with a list and will prevent any attempt to associate 'tail' 
with some value that is not a list. Python does

Re: Python education survey

2011-12-27 Thread Andrew Berg


On 12/27/2011 4:04 PM, K Richard Pixley wrote:

You still need to match versions of PyDev to versions of Eclipse to
versions of operating system to versions of other eclipse plugins.  I
spent a few days trying to get it together once and came to the
conclusion that it was a much bigger effort than I was willing to commit to.
This is more of a package management issue than an Eclipse one. I had no 
problems getting the very latest stable versions of everything on 
Windows. I'm pretty sure most schools will be using Windows for 
workstations anyway. In any case, if Eclipse is impractical for whatever 
reason, obviously it would be wise to try something else.



 You could create your own distribution of eclipse, but
 then you have that "only useful for python" problem again.

 AFAIK, Eclipse should always be good for Java unless you do some serious
 hacking.


Depends on which versions of eclipse, java, os, other plugins, etc.

How so? AFAIK, Eclipse is almost (if not completely) unusable without Java.

--
CPython 3.2.2 | Windows NT 6.1.7601.17640
--
http://mail.python.org/mailman/listinfo/python-list

Re: confused about new

On Tue, Dec 27, 2011 at 3:19 PM, K Richard Pixley  wrote:
> Are you trying to demonstrate that I haven't prevented you from
> instantiating Foo?  If so, then I will cede that point.  I certainly don't
> know enough about python internals just now to even claim to be capable of
> protecting a class from a hostile user.  My guess is that short of a
> privileged/unprivileged split, or castrating the interpreter and locking you
> into it, such a protection would not be possible.

Yes, that was the point.  I certainly don't think that anybody should
ever be creating class instances by directly invoking object.__new__
unless they really, really know what they are doing.  I was just
pointing out that I don't think it's actually possible to prevent
classes from being instantiated.

> My point was that I can indeed intercept common and convenient usage to
> create a lovely singleton semantic.  I can't force you to use it. (Nor do I
> have any motivation to so do.)

Sure, I don't disagree with that.  And the object.__new__ workaround
is a general point that doesn't apply only to singletons.  Any class
that customizes its instantiation process can be messed up by doing
that.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Type object returned by the re.compile function

On Tue, Dec 27, 2011 at 2:56 PM, candide  wrote:
> The Python 2.7 official documentation here:
>
> http://docs.python.org/library/re.html#re.compile
>
> doesn't specify the type object returned by the re.compiled function.
> According to the documentation, re.compile returns a "regular expression
> object".
>
> A regular expression object seems to be an instance of the class
> RegexObject. The documentation mentions this class here :
>
> http://docs.python.org/library/re.html#regular-expression-objects
>
> but i don't see any existing class with this name :

Presumably if it's not in the module then it's not meant to be
directly invoked.  You should always use re.compile().  If you really
want to assign the type a name, though:

>>> import re
>>> RegexObject = type(re.compile(''))
>>> RegexObject


Cheers,
Ian
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Type object returned by the re.compile function

2011-12-27 Thread Jerry Hill

On Tue, Dec 27, 2011 at 4:56 PM, candide  wrote:
 import re
 reo = re.compile('')
 reo.__class__
> Traceback (most recent call last):
>  File "", line 1, in 
> AttributeError: __class__

I'm not going to comment on what type is returned from the various
functions in the re module, mostly because all I have installed
locally is 2.6, and I'm not sure if anything has changed in 2.7 or
3.2.

Instead, I will recommend a different tool for your  toolbox.  Take a
look at the type() builtin function (
http://docs.python.org/library/functions.html#type ).  Particularly,
instead of inspecting reo.__class__ in your example above, you can
print out type(reo).

At a guess, those objects are missing the __class__ attribute,
possibly because they are old style classes.

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

Re: Python education survey

On Dec 27, 9:04 pm, Rick Johnson  wrote:
> On Dec 27, 1:45 pm, Eelco  wrote:
>
> > On Dec 27, 6:53 pm, Lie Ryan  wrote:
> > > On 12/27/2011 10:41 PM, Eelco wrote:
> > > Before using VIM, I used to use gedit
>
> Eelco, please don't get offended, but can you (and everyone else) stop
> using silly verbage like "used to", "use to", "suppose to", "hard"
> when you "difficult", and "pretty" when you mean "very". I find this
> verbiage to be quite ridiculous. In this case you could have simply
> said...
>
> """Before using VIM, I USED gedit."""
>
> or if you want to stress that you don't use gedit anymore you could
> say...
>
> """ Previously i used gedit, but have since moved on to VIM."""
>
> Thanks

Despite the fact that you mis-attributed that quote to me, im going to
be a little bit offended in the name of its actual author anyway.
Thats a lot of words to waste on your linguistic preferences.
Personally, I reserve the right to botch my non-native languages as
much as I please.

> > You
> > dont have to explain to them how to open a file, and if you tell them
> > to hit the 'play' button to start running their code (not a hard
> > concept to grasp or remember either) they are good to start hacking.
>
> I always though "run" was a perfect verb for "running" code... but who
> knows :)

Im assuming the audience is familiar with an ipod, but not an IDE, or
programming in general. To their eyes, it looks like a 'play' button;
but yes, 'running' is what its called in my mind.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: confused about new

On 12/27/11 12:34 , Ian Kelly wrote:

On Tue, Dec 27, 2011 at 1:31 PM, K Richard Pixley  wrote:

On 12/27/11 10:28 , Ian Kelly wrote:

On Tue, Dec 27, 2011 at 10:41 AM, K Richard Pixleywrote:

The conceptual leap for me was in recognizing that a class is just an
object.  The best way, (imo, so far), to create a singleton in python is
to
use the class itself as the singleton rather than ever instantiating it.
  With a little work, you can even prevent it from ever being
instantiated.

I don't think that's actually possible:

Python 3.2 (r32:88445, Feb 20 2011, 21:29:02) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.

class Foo:

... def __new__(cls):
... raise TypeError
... def __init__(self):
... raise TypeError
...

type(object.__new__(Foo))

Try:

class Foo(object):
def __new__(cls):
return cls

Okay:

Python 3.2 (r32:88445, Feb 20 2011, 21:29:02) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.

class Foo:

... def __new__(cls):
... return cls
...

f1 = object.__new__(Foo)
f2 = object.__new__(Foo)
type(f1), type(f2)

(,)

f1 is f2

False

I'm not seeing why you're using "object.__new__".  With Foo(), it seems 
fine.

r...@fuji-land.noir.com> python
Python 2.7.2 (default, Dec 12 2011, 13:05:49)
[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)] on 
darwin

Type "help", "copyright", "credits" or "license" for more information.
>>> class Foo(object):
... def __new__(cls):
... return cls
...
>>> f1 = Foo()
>>> f2 = Foo()
>>> id(Foo)
4298515984
>>> id(f1)
4298515984
>>> id(f2)
4298515984

r...@fuji-land.noir.com> python3
Python 3.2.2 (default, Dec 26 2011, 15:03:08)
[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)] on 
darwin

Type "help", "copyright", "credits" or "license" for more information.
>>> class Foo(object):
... def __new__(cls):
... return cls
...
>>> f1 = Foo()
>>> f2 = Foo()
>>> id(f1)
4298841008
>>> id(f2)
4298841008
>>> f1.stuff = True
>>> f2.stuff
True
>>> id(Foo)
4298841008

Are you trying to demonstrate that I haven't prevented you from 
instantiating Foo?  If so, then I will cede that point.  I certainly 
don't know enough about python internals just now to even claim to be 
capable of protecting a class from a hostile user.  My guess is that 
short of a privileged/unprivileged split, or castrating the interpreter 
and locking you into it, such a protection would not be possible.

My point was that I can indeed intercept common and convenient usage to 
create a lovely singleton semantic.  I can't force you to use it. (Nor 
do I have any motivation to so do.)

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

Re: Python education survey


On 12/27/11 10:26 , Andrew Berg wrote:

On 12/27/2011 11:59 AM, K Richard Pixley wrote:

You'd do better to encourage eclipse, but setting that up isn't
trivial either.

IIRC, all I had to do to set up PyDev was copy a URL to Eclipse's
"Install New Software" wizard, and have Eclipse download and install it.
Extra steps are needed if a different implementation of Python (e.g.
Jython) is needed, but other than that, the user only needs to specify a
couple options (e.g. Python grammar version) at project creation time.
This assumes that Python is already installed, but why wouldn't it be?


You still need to match versions of PyDev to versions of Eclipse to 
versions of operating system to versions of other eclipse plugins.  I 
spent a few days trying to get it together once and came to the 
conclusion that it was a much bigger effort than I was willing to commit to.



You could create your own distribution of eclipse, but
then you have that "only useful for python" problem again.

AFAIK, Eclipse should always be good for Java unless you do some serious
hacking.


Depends on which versions of eclipse, java, os, other plugins, etc.


If students are going to go anywhere else after this class, they're
going to need to either be able to learn to switch editors or find an
editor they can use more generally.

There are a ton of editors that have syntax highlighting and other
little features for many languages.


Exactly.  My preference is emacs but I'll admit that the learning curve 
there is pretty high by today's standards.  (Whether it's worth the 
effort is a debatable point.)  There are certainly many others.


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

Type object returned by the re.compile function

2011-12-27 Thread candide


The Python 2.7 official documentation here:

http://docs.python.org/library/re.html#re.compile

doesn't specify the type object returned by the re.compiled function. 
According to the documentation, re.compile returns a "regular expression 
object".


A regular expression object seems to be an instance of the class 
RegexObject. The documentation mentions this class here :


http://docs.python.org/library/re.html#regular-expression-objects

but i don't see any existing class with this name :

>>> import re
>>> re.RegexObject
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'module' object has no attribute 'RegexObject'
>>>

Actually, a regular expression object doesn't seem to be a class object :

>>> import re
>>> reo = re.compile('')
>>> reo.__class__
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: __class__
>>>

but has attributes :

>>> dir(reo)
['__copy__', '__deepcopy__', 'findall', 'finditer', 'match', 'scanner', 
'search', 'split', 'sub', 'subn']

>>>


I have the same problem with the match object : the doc mentions a 
re.MatchObject class but this class doesn't exist :


>>> re.MatchObject
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'module' object has no attribute 'MatchObject'
>>>


Any clarification is welcome.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Daemon management

2011-12-27 Thread Fredrik Tolf


On Tue, 27 Dec 2011, Miki Tebeka wrote:

What was the term you used to search? Since 
http://pypi.python.org/pypi/ingress/0.1.1 seems to fit your description.


Not quite, though. It (AFAICT, at least) only provides the REPL part, with 
no way to construct a more program-friendly interface.


--

Fredrik Tolf

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

Re: Daemon management

2011-12-27 Thread Fredrik Tolf




On Wed, 28 Dec 2011, Lie Ryan wrote:

On 12/27/2011 12:43 PM, Fredrik Tolf wrote:

[...]
This is possible through the use of a debugger. I've never used it, but I 
heard good thing of winpdb which has remote debugging. (http://winpdb.org/)


Thanks, but not as long as the debugger freezes the program it attaches 
to.


Another tool that I've never used is rconsole, part of rfoo library, which 
appears to be similar to pdm; it is also intended for the same kind of 
problem, managing long-running-processes/daemons.


Interesting. That does sound very similar to what I wanted, so it's kind 
of a shame that I didn't find it. If anything, it seems that PDM is a bit 
more flexible in that it can handle limited references to remote 
objects, event notifications from the server to the client, and has better 
support for handling both TCP and Unix sockets (the rconsole script, for 
instance, seems to lack support for connecting to Unix sockets), so I 
guess my time wasn't wasted.


--

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

Re: Which libraries for Python 2.5.2

I realized that I had a working copy of the app on another XP PC, so I 
looked at what I had installed for Python.


It was not what I had posted the first time. There must have been some 
shift after the July 16, 2008 date. One lib that was missing was scipy.


I just collected the three libs I saw there.

numpy
matplotlib
scipy

Scipy uses as its installer.
scipy-0.6.0.win32-py2.5.exe

I replaced numpy and matplotlib, and added scipy. I still get errors, 
but perhaps because the install order is now wrong. It was

numpy
matplotlib

Does anyone know the right order?

The complaint msgs were very close to what I posted before, and 
matplotlib was again the last of the bunch. DLL for it not found.


Possibly I need the dependencywalker that Christian mentioned.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Which libraries for Python 2.5.2


On 12/27/2011 10:36 AM, Christian Heimes wrote:

Am 27.12.2011 17:03, schrieb W. eWatson:

  from matplotlib._path import affine_transform
ImportError: DLL load failed: The specified module could not be found.


You are missing one or more DLLs that is required to load the _path.pyd
module. You can use http://www.dependencywalker.com/ to track down
missing DLLs.

Christian

OK, I installed it. Is there an easy way to go to track down this dll. 
There's a Help, but I can't print it from the PC I have it on.

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

Re: Possible bug in string handling (with kludgy work-around)

2011-12-27 Thread Terry Reedy


On 12/27/2011 1:04 PM, Rick Johnson wrote:


But this brings up a very important topic. Why do we even need triple
quote string literals to span multiple lines? Good question, and one i
have never really mused on until now.


I have, and the reason I thought of is that people, including me, too 
ofter forget or accidentally fail to properly close a string literal, 
and type something like 'this is a fairly long single line string"
and wonder why they get a syntax error lines later, or, in interactive 
mode, why the interpreter does not respond to a newline.


Color coding editors make it easier to catch such errors, but they were 
less common in 1991. And there is still uncolored interactive mode.


There may also be a technical reason as to how the lexer works.

--
Terry Jan Reedy

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

Re: Python education survey

On Tue, Dec 27, 2011 at 2:13 PM, Lie Ryan  wrote:
> In any case, removing IDLE without a much better replacement is pretty much
> out of the question. If people installed Python in vanilla Windows install,
> they would only have Notepad to edit their code.

No no, Wordpad is much better for editing Python.  It even supports
(manual) syntax highlighting!

And of course for the console lovers there is MS-DOS Edit.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PDF 508 Compliance with Python?

2011-12-27 Thread Terry Reedy


On 12/27/2011 11:35 AM, Yanovsky, Boris, VHACIN wrote:

Hello,

I am new to Python and I hope my question makes sense. We are trying to
make PDFs 508 Compliant, meaning that the objects within them have to be
tagged. The problem is that we have hundreds, and potentially thousands
of PDFs, since they are automated reports that we create on a regular basis.

Is there a code or feature in Python that can read PDFs and tag the
objects within them for this kind of compliance?


There are 3rd party python packages that can read and write .pdfs.
Google 'Python pdf library' or just go to
http://pypi.python.org/pypi?%3Aaction=search&term=pdf&submit=search
Make sure you check out the one from ReportLab.
I suspect at least one will do what you want.

--
Terry Jan Reedy

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

Re: Possible bug in string handling (with kludgy work-around)


On 12/28/2011 05:04 AM, Rick Johnson wrote:

--
Note: superfluous indention removed for clarity!
--

On Dec 27, 8:53 am, Dennis Lee Bieber  wrote:

You can get by without the backslash in this situation too, by using
triple quoting:


I would not do that because:
1. Because Python already has TWO string literal delimiters (' and ")
2. Because triple quote string literals are SPECIFICALLY created to
solve the "multi-line issue"
3. Because you can confuse the hell out of someone who is reading
Python code and they may miss the true purpose of triple quotes in
Python

But this brings up a very important topic. Why do we even need triple
quote string literals to span multiple lines? Good question, and one i
have never really mused on until now. It's amazing how much BS we just
accept blindly! WE DON'T NEED TRIPLE QUOTE STRINGS! What we need is
single quote strings that span multiple lines and triple quotes then
become superfluous! For the problem of embedding quotes in string
literals, we should be using markup. A SIMPLISTIC MARKUP!

" This is a multi line
string with a single quote -->  
and a double quote -->  . Here is an
embedded newline -->  . And a backspace.

Now we can dispense with all the BS!
"


Ok, you're trolling.

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

Re: Python education survey


On 12/28/2011 05:11 AM, Rick Johnson wrote:

On Dec 27, 11:50 am, Lie Ryan  wrote:

In case you haven't realised it, it is pretty
much impossible for a large open source project to "die"; even if Guido
decided to remove IDLE from the standard library


I don't remember stating that Python would die if IDLE was removed
(not sure if you misunderstood me or you're just making a general
statement???). My belief is that the atrocious state of IDLE and
Tkinter's code bases are making us look bad as a community. And i can
go either way on the issue; remove them both, or enrich them both.
Either way we improve on the current situation.  My point is that we
CANNOT just ignore the issue.


The point is, I didn't think it's such a pressing issue. I haven't seen 
anyone in or outside Python communities making their conclusion about 
Python based on IDLE.


In any case, removing IDLE without a much better replacement is pretty 
much out of the question. If people installed Python in vanilla Windows 
install, they would only have Notepad to edit their code.


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

Re: Python education survey


On 12/27/11 10:21 , Rick Johnson wrote:

On Dec 27, 11:59 am, K Richard Pixley  wrote:


The problem is that IDLE is hard to set up.  (I've never managed it and
I'm a well seasoned veteran).


Can you qualify that statement? Do you mean "difficult to set up on
certain OS's"? Because for windows there is no difficulty.


The distributed binaries haven't worked when I tried on any version of 
linux or macosx that I used.  Attempting to build from source also 
failed.  (I'm pretty much an anti-microsoft bigot).



  Everyone ends up writing some html
eventually, for instance.


most folks write more than just HTML! Ruby, Lisp, Perl, C, Java, etc.


Dedicated computer folks and experimental tinkerers, yes, I concur.

But even casual computer users eventually want to write html, or compose 
for a wiki and get annoyed when their 3 hours of work in a web browser 
test field are lost because they changed pages.


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

Re: confused about new


On 12/27/11 10:28 , Ian Kelly wrote:

On Tue, Dec 27, 2011 at 10:41 AM, K Richard Pixley  wrote:

The conceptual leap for me was in recognizing that a class is just an
object.  The best way, (imo, so far), to create a singleton in python is to
use the class itself as the singleton rather than ever instantiating it.
  With a little work, you can even prevent it from ever being instantiated.

I don't think that's actually possible:

Python 3.2 (r32:88445, Feb 20 2011, 21:29:02) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.

class Foo:

... def __new__(cls):
... raise TypeError
... def __init__(self):
... raise TypeError
...

type(object.__new__(Foo))




Try:

class Foo(object):
def __new__(cls):
return cls

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

Re: confused about new

On Tue, Dec 27, 2011 at 1:31 PM, K Richard Pixley  wrote:
> On 12/27/11 10:28 , Ian Kelly wrote:
>>
>> On Tue, Dec 27, 2011 at 10:41 AM, K Richard Pixley  wrote:
>>>
>>> The conceptual leap for me was in recognizing that a class is just an
>>> object.  The best way, (imo, so far), to create a singleton in python is
>>> to
>>> use the class itself as the singleton rather than ever instantiating it.
>>>  With a little work, you can even prevent it from ever being
>>> instantiated.
>>
>> I don't think that's actually possible:
>>
>> Python 3.2 (r32:88445, Feb 20 2011, 21:29:02) [MSC v.1500 32 bit
>> (Intel)] on win32
>> Type "help", "copyright", "credits" or "license" for more information.
>
> class Foo:
>>
>> ...     def __new__(cls):
>> ...         raise TypeError
>> ...     def __init__(self):
>> ...         raise TypeError
>> ...
>
> type(object.__new__(Foo))
>>
>> 
>
>
> Try:
>
> class Foo(object):
>    def __new__(cls):
>        return cls


Okay:

Python 3.2 (r32:88445, Feb 20 2011, 21:29:02) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> class Foo:
... def __new__(cls):
... return cls
...
>>> f1 = object.__new__(Foo)
>>> f2 = object.__new__(Foo)
>>> type(f1), type(f2)
(, )
>>> f1 is f2
False
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Which libraries for Python 2.5.2


...


I'm suspicious of this line, and maybe even the app program. There may
have been a change to the code that required the later two versions of
numpy and matplotlib. In fact, I'm using the later version here, so I'll
see if I can back up to the first Python app they produced.

from pylab import plot, xlabel, ylabel, title, show, xticks, bar


I found what I thought might be the original, but that got changed in a 
later version on July 16, 2008, which became what I continued to use. 
The libs are as in my first post. I looked at the original Python app, 
and it used Python 2.4.2 but sure doesn't use the same lib versions as 
the 2008 version.


The puzzler for me is why I can find numpy and matplotlib on my PC 
slightly latter than shown in the first post. It's like another release 
of the app came later. Unfortunately, I'm stuck on that, since our 
sponsors seem to be out for the entire holiday season.



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

Re: Python education survey

On Dec 27, 1:45 pm, Eelco  wrote:
> On Dec 27, 6:53 pm, Lie Ryan  wrote:
> > On 12/27/2011 10:41 PM, Eelco wrote:

> > Before using VIM, I used to use gedit

Eelco, please don't get offended, but can you (and everyone else) stop
using silly verbage like "used to", "use to", "suppose to", "hard"
when you "difficult", and "pretty" when you mean "very". I find this
verbiage to be quite ridiculous. In this case you could have simply
said...

"""Before using VIM, I USED gedit."""

or if you want to stress that you don't use gedit anymore you could
say...

""" Previously i used gedit, but have since moved on to VIM."""

Thanks

> As for my personal use, I very much prefer an IDE. I hate having only
> crappy code completion

Syntax highlight is important ESPECIALLY if you're multi-lingual.
Sometimes when i switch between the many languages i know, the
highlight of the syntax is the only blindingly apparent clue. Take
Python and Ruby for example.

> A good IDE should get out of your way if you want it to. I like
> pycharm in this regard; click an x or two, and you are facing just
> your text editor and console/output window.

A "good IDE" is nothing more than an extension of a base text editor
with options to switch on as little or as much IDE machinery as you
like. Why would you have a text editor AND an IDE? When an IDE is just
an intelligent texteditor? That is one thing that i find missing in
IDLE; the ability to turn off certain things. With IDLE, it's all or
nothing.

> Generally, I think a non-cluttered IDE is ideal for a beginner.

Agreed, see last response ^^^

> You
> dont have to explain to them how to open a file, and if you tell them
> to hit the 'play' button to start running their code (not a hard
> concept to grasp or remember either) they are good to start hacking.

I always though "run" was a perfect verb for "running" code... but who
knows :)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python education survey

On Dec 27, 6:53 pm, Lie Ryan  wrote:
> On 12/27/2011 10:41 PM, Eelco wrote:
>
>
>
> > *Your suggestion of VIM is especially objectionable. Though I am sure
> > it is a great tool to you, the subject here is beginner education.
> > Just because it is a good tool for you, does not make it a good tool
> > for a beginner.
>
> Before using VIM, I used to use gedit (and still do, though not as often
> now); I don't think I've ever had any problem with not using a full
> blown IDE with Python. I generally don't miss not using an IDE since
> Python doesn't have the tradition of using overly verbose names like in
> Java.

As for my personal use, I very much prefer an IDE. I hate having only
crappy code completion, for starters, and I like a good integrated
debugger. But then again, im spoiled I suppose coming from C#. On the
other hand, ive worked for many years using a very minimal notepad
+command line compilation setup as well.

But I can very well imagine that people are perfectly happy with more
hackerish tools. That is, once they have gotten past the learning
curve.

> I'm personally of the opinion that beginners generally should start with
> a simple programmer text editors (gedit is a good example). Firstly, you
> don't want to confuse beginners with IDE vs language features; secondly,
> at the size of the problem beginners typically had, they don't **need**
> 95% of those features; and if you teach beginners powerful IDE features
> too early, by the time their problem gets big enough that the IDE
> features would actually help, they'd already forgotten about them.

A good IDE should get out of your way if you want it to. I like
pycharm in this regard; click an x or two, and you are facing just
your text editor and console/output window.

Generally, I think a non-cluttered IDE is ideal for a beginner. You
dont have to explain to them how to open a file, and if you tell them
to hit the 'play' button to start running their code (not a hard
concept to grasp or remember either) they are good to start hacking.
Also, I think code completion is a blessing to beginning programmers.
IPython is good in that regard; until you switch to editing files,
where your choice is between notepad, or configuring an other editor
you dont want your class to spend any time on, and youll end up with
something that still doesnt do much more than syntax highlighting.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Daemon management

2011-12-27 Thread Miki Tebeka

What was the term you used to search? Since 
http://pypi.python.org/pypi/ingress/0.1.1 seems to fit your description.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Which libraries for Python 2.5.2


On 12/27/2011 8:42 AM, Lie Ryan wrote:

On 12/28/2011 03:03 AM, W. eWatson wrote:

Here's the traceback.


The traceback seems to imply that matplotlib is not being installed
properly. Have you tried uninstalling then reinstalling matplotlib?



I just did, and the results are this:
=
Traceback (most recent call last):
  File "C:\Sentinel\Sent_user-20080716.py", line 16, in 
from pylab import plot, xlabel, ylabel, title, show, xticks, bar
  File "C:\Python25\lib\site-packages\pylab.py", line 1, in 
from matplotlib.pylab import *
  File "C:\Python25\lib\site-packages\matplotlib\pylab.py", line 204, 
in 

from matplotlib import mpl  # pulls in most modules
  File "C:\Python25\lib\site-packages\matplotlib\mpl.py", line 1, in 


from matplotlib import artist
  File "C:\Python25\lib\site-packages\matplotlib\artist.py", line 4, in 

from transforms import Bbox, IdentityTransform, TransformedBbox, 
TransformedPath
  File "C:\Python25\lib\site-packages\matplotlib\transforms.py", line 
34, in 

from matplotlib._path import affine_transform
ImportError: DLL load failed: The specified module could not be found.
=

I'm suspicious of this line, and maybe even the app program. There may 
have been a change to the code that required the later two versions of 
numpy and matplotlib. In fact, I'm using the later version here, so I'll 
see if I can back up to the first Python app they produced.


from pylab import plot, xlabel, ylabel, title, show, xticks, bar
--
http://mail.python.org/mailman/listinfo/python-list

Re: Which libraries for Python 2.5.2

2011-12-27 Thread Christian Heimes

Am 27.12.2011 17:03, schrieb W. eWatson:
>  from matplotlib._path import affine_transform
> ImportError: DLL load failed: The specified module could not be found.

You are missing one or more DLLs that is required to load the _path.pyd
module. You can use http://www.dependencywalker.com/ to track down
missing DLLs.

Christian

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

Re: Python education survey

On Dec 27, 11:59 am, K Richard Pixley  wrote:

> The problem is that IDLE is hard to set up.  (I've never managed it and
> I'm a well seasoned veteran).

Can you qualify that statement? Do you mean "difficult to set up on
certain OS's"? Because for windows there is no difficulty.

> And [IDLE is] pretty much only good for python,

Yes, i will agree on that! We could create snap-ins for other
languages, but, there are many good multi-language editors out there
already.

>  I'd
> expect.  You'd do better to encourage eclipse, but setting that up isn't
> trivial either.  You could create your own distribution of eclipse, but
> then you have that "only useful for python" problem again.

Same boat, different lake.

> If students are going to go anywhere else after this class, they're
> going to need to either be able to learn to switch editors or find an
> editor they can use more generally.

Agreed!

>  Everyone ends up writing some html
> eventually, for instance.

most folks write more than just HTML! Ruby, Lisp, Perl, C, Java, etc.

>  Either way requires climbing a learning curve
> that would be difficult to justify for a single class.

Yes, i must agree that IDLE does not scale. It's true that IDLE is
only good for Python. Could we make the IDLE usable for other
languages? Yes, but what good is that going to do? IDLE is already
slow due to Tkinter being slow, due to Python being slow... etc. I
must admit that IDLE is only useful for complete beginners, those who
code only in Python, or those who don't care about using a specific
Python IDE.

But that damn "batteries included" and CPFE keeps creeping up! What to
do, what to do?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: confused about new

On Tue, Dec 27, 2011 at 10:41 AM, K Richard Pixley  wrote:
> The conceptual leap for me was in recognizing that a class is just an
> object.  The best way, (imo, so far), to create a singleton in python is to
> use the class itself as the singleton rather than ever instantiating it.
>  With a little work, you can even prevent it from ever being instantiated.

I don't think that's actually possible:

Python 3.2 (r32:88445, Feb 20 2011, 21:29:02) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> class Foo:
... def __new__(cls):
... raise TypeError
... def __init__(self):
... raise TypeError
...
>>> type(object.__new__(Foo))

I prefer the Borg pattern for singletons myself.  When you need a Borg
instance, you just instantiate the class normally, do whatever you
need with it, and then discard it normally.  It doesn't matter how
many instances there are (there can even be zero) because they all
share identical state.  It's better encapsulation too, since client
code does not even need to know that the class is a singleton variant;
that becomes an implementation detail.

http://www.aleax.it/Python/5ep.html
http://code.activestate.com/recipes/66531/

> But __metaclass__ could use a few more examples, imo.  I'm still not
> entirely clear on __metaclass__.  As I understand it, (which may well be
> completely wrong), __metaclass_ is the means of perturbing the results of
> "isinstance".  You can create, (or delete), inheritance arbitrarily, and
> without even requiring real, existing classes to do it.

A metaclass is the class of another class (which is normally `type` if
no metaclass is specified).  It's used to customize the way that the
class is created, in the same way that the class can be used to
customize the way instances are created (e.g. by overriding __new__).
You could use it to mess with the class's base classes, although I
think that usage is rare.  It's more common to use it to automatically
add or modify entries in the class dict.  For example, Django models
use a metaclass to collect all the fields and options declared for the
model class and to setup a default manager for the model class.

Note that many things that can be done with a metaclass can also be
done with a class decorator.  The main difference as I see it is that
the metaclass is inherited by subclasses, whereas a decorator would
need to be applied individually to each subclass.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python education survey

2011-12-27 Thread Andrew Berg


On 12/27/2011 11:59 AM, K Richard Pixley wrote:

You'd do better to encourage eclipse, but setting that up isn't
trivial either.
IIRC, all I had to do to set up PyDev was copy a URL to Eclipse's 
"Install New Software" wizard, and have Eclipse download and install it. 
Extra steps are needed if a different implementation of Python (e.g. 
Jython) is needed, but other than that, the user only needs to specify a 
couple options (e.g. Python grammar version) at project creation time. 
This assumes that Python is already installed, but why wouldn't it be?



You could create your own distribution of eclipse, but
then you have that "only useful for python" problem again.
AFAIK, Eclipse should always be good for Java unless you do some serious 
hacking.



If students are going to go anywhere else after this class, they're
going to need to either be able to learn to switch editors or find an
editor they can use more generally.
There are a ton of editors that have syntax highlighting and other 
little features for many languages.


--
CPython 3.2.2 | Windows NT 6.1.7601.17640
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python education survey

On Dec 27, 11:50 am, Lie Ryan  wrote:
> In case you haven't realised it, it is pretty
> much impossible for a large open source project to "die"; even if Guido
> decided to remove IDLE from the standard library

I don't remember stating that Python would die if IDLE was removed
(not sure if you misunderstood me or you're just making a general
statement???). My belief is that the atrocious state of IDLE and
Tkinter's code bases are making us look bad as a community. And i can
go either way on the issue; remove them both, or enrich them both.
Either way we improve on the current situation.  My point is that we
CANNOT just ignore the issue.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Which libraries for Python 2.5.2


On 12/27/2011 8:53 AM, Ian Kelly wrote:

On Tue, Dec 27, 2011 at 9:03 AM, W. eWatson  wrote:

  File "C:\Python25\lib\site-packages\matplotlib\transforms.py", line 34, in

from matplotlib._path import affine_transform
ImportError: DLL load failed: The specified module could not be found.


Do you not have the file
C:\Python25\lib\site-packages\matplotlib\_path.pyd?  It's in the
installer archive, so you should be able to just open it up with a zip
program and extract it manually.  If that's missing, then there may be
other things wrong with your installation, though, so I would
recommend a full reinstall.

The path exits. _path.pyd exists.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Possible bug in string handling (with kludgy work-around)

--
Note: superfluous indention removed for clarity!
--

On Dec 27, 8:53 am, Dennis Lee Bieber  wrote:
> You can get by without the backslash in this situation too, by using
> triple quoting:

I would not do that because:
1. Because Python already has TWO string literal delimiters (' and ")
2. Because triple quote string literals are SPECIFICALLY created to
solve the "multi-line issue"
3. Because you can confuse the hell out of someone who is reading
Python code and they may miss the true purpose of triple quotes in
Python

But this brings up a very important topic. Why do we even need triple
quote string literals to span multiple lines? Good question, and one i
have never really mused on until now. It's amazing how much BS we just
accept blindly! WE DON'T NEED TRIPLE QUOTE STRINGS! What we need is
single quote strings that span multiple lines and triple quotes then
become superfluous! For the problem of embedding quotes in string
literals, we should be using markup. A SIMPLISTIC MARKUP!

" This is a multi line
string with a single quote --> 
and a double quote --> . Here is an
embedded newline --> . And a backspace .

Now we can dispense with all the BS!
"

>  I find """ clearer, ''' could be a " and '
> packed tightly in some fonts, "', whereas """ can only be one construct)

Another reason to ONLY use fixed width font when viewing code! Why
would you use ANY font that would obscure chars SO ubiquitous as " and
'?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: confused about new

2011-12-27 Thread Fredrik Tolf


On Tue, 27 Dec 2011, Ian Kelly wrote:

On Mon, Dec 26, 2011 at 10:48 PM, Fredrik Tolf  wrote:

I'm also a bit confused about __new__. I'd very much appreciate it if
someone could explain the following aspects of it:

 * The manual () says
  that __new__ is "a static method (special-cased so you need not declare
  it as such)". What does "special-cased" mean? Apparently, for
  instance, in OP's case,  Python did not automatically detect that it
  should not be bound as a method.


It apparently has to do with the class creation.  For the
special-casing to happen, the __new__ method has to be present when
the class is created.  If it is, then it automatically gets wrapped in
a staticmethod.  In the OP's case, he was adding the __new__ method
after class creation, so the wrapping did not happen automatically.


Hmm, thank you. After trying a couple of things, it appears that the 
reason OP's method worked in Python 3 is that __get__ on ordinary 
functions in Python 3 simply returns the function itself when called on 
type lookup, rather than Python 2's unbound method objects.



http://docs.python.org/reference/datamodel.html#the-standard-type-hierarchy
"""
Class Types
   Class types, or “new-style classes,” are callable. These objects
normally act as factories for new instances of themselves, but
variations are possible for class types that override __new__(). The
arguments of the call are passed to __new__() and, in the typical
case, to __init__() to initialize the new instance.
"""

AFAIK, that's pretty much it.  When a type is called, __new__ is
called to create the new instance, and then __init__ is called to
initialize it (if __new__ returned an instance of the type).


Since that description doesn't include when __dict__ is created, it isn't 
complete, however. I guess it's safe to assume that __dict__ is created 
inside object.__new__, but that also leaves some things unclear; see 
below.



how methods, properties and the like are bound;


When they're accessed, using the descriptor protocol, not as part of
the instantiation process.  See:
http://docs.python.org/reference/datamodel.html#invoking-descriptors


Ah, sorry. I had read that, but I had mistakenly thought that the same 
instance method object was always returned, which would have implied that 
it had to be stored for the instance somewhere, at some point. I see now 
that that is not actually the case, however. That clears up a whole lot 
for me. Thanks!



when and whether __dict__
  is created and a couple of other things.


Under the hood as part of the object creation process, unless the
class uses __slots__.


And also unless the object created is of type `object' or any other 
built-in type, which leaves me wondering exactly under what circumstances 
__dict__ actually is created. Is it some kind of special case in 
object.__new__ for types created with the `class' statement? There also 
appear to be other special cases in object.__new__:



object.__new__(dict)

Traceback (most recent call last):
  File "", line 1, in 
TypeError: object.__new__(dict) is not safe, use dict.__new__()

I guess my question reduces into the following: What does object.__new__ 
actually do, and what other special cases does it implement?


--

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

Re: Python education survey


On 12/19/11 19:51 , Raymond Hettinger wrote:

Do you use IDLE when teaching Python?
If not, what is the tool of choice?



If your goal is to quickly get new users up and running in Python,
what IDE or editor do you recommend?


I would:

a) let the students pick their own editor.
b) encourage emacs and use emacs as a reference editor.

The problem is that IDLE is hard to set up.  (I've never managed it and 
I'm a well seasoned veteran).  And pretty much only good for python, I'd 
expect.  You'd do better to encourage eclipse, but setting that up isn't 
trivial either.  You could create your own distribution of eclipse, but 
then you have that "only useful for python" problem again.


If students are going to go anywhere else after this class, they're 
going to need to either be able to learn to switch editors or find an 
editor they can use more generally.  Everyone ends up writing some html 
eventually, for instance.  Either way requires climbing a learning curve 
that would be difficult to justify for a single class.


OTOH, there are binary emacs distributions for all systems you've 
mentioned.  And they work.


I'm an antimicrosoft bigot, but I think my answer is probably the same 
regardless of whether we know the OS the students will be using or not.


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

Re: Python education survey


On 12/27/2011 10:41 PM, Eelco wrote:


*Your suggestion of VIM is especially objectionable. Though I am sure
it is a great tool to you, the subject here is beginner education.
Just because it is a good tool for you, does not make it a good tool
for a beginner.


Before using VIM, I used to use gedit (and still do, though not as often 
now); I don't think I've ever had any problem with not using a full 
blown IDE with Python. I generally don't miss not using an IDE since 
Python doesn't have the tradition of using overly verbose names like in 
Java.


I'm personally of the opinion that beginners generally should start with 
a simple programmer text editors (gedit is a good example). Firstly, you 
don't want to confuse beginners with IDE vs language features; secondly, 
at the size of the problem beginners typically had, they don't **need** 
95% of those features; and if you teach beginners powerful IDE features 
too early, by the time their problem gets big enough that the IDE 
features would actually help, they'd already forgotten about them.



IPython bundled with a lightweight but function-rich and non-hacker-
but-WYSIWYG editor would be a great choice. But until that comes
around, pycharm it is for me.


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

Re: Python education survey


On 12/28/2011 03:37 AM, Rick Johnson wrote:

My logic is this:
  """ Including an IDE in the stdlib may have been a bad idea (although
i understand and support Guido's original vision for IDLE). But since
we do have it, we need to either MAINTAIN the package or REMOVE it. We
cannot just stick our heads in the sand and ignore the elephant in the
chicken coop. It's bad enough to bloat ANY stdlib with seldom used
modules, but i dare say, it's far worse to bloat a library with seldom
used modules that are poorly maintained! Every module in Python's
stdlib is a testament to the skill and professionalism of this
community as a whole. When a module looks or works badly, we ALL look
and work badly."""


AFAICS, Python has a pretty good reputation even outside Python 
community. I haven't seen anyone looks at Python badly because of IDLE.



It's no big secret to anyone in this community that both Tkinter and
IDLE are the red headed step children of Pythons stdlib. Very few
people speak kindly of either package. I believe GvR still believes in
the merits of both packages (psst: batteries included!) but he finds
himself at odds with the elite at pydev. Hmm, Maybe he DOES want to
remove them but fears loosing face...FYI: Guido IS is the original
author of both Tkinter and IDLE... it was HIS idea after all. However,
it is high time to re-ignite the original vision and form these
packages into something we can be proud of -- OR -- cut our losses and
remove them forever.


I hope you're not attempting to put words into his mouth, what you think 
of Guido's ideas is not necessarily Guido's ideas.


In any case, IDLE is open source -- I don't know exactly what license 
it's under but I'd assume it's the same as Python -- and anyone in this 
list and outside this list -- including you -- can freely fork it and 
work on it to improve it. In case you haven't realised it, it is pretty 
much impossible for a large open source project to "die"; even if Guido 
decided to remove IDLE from the standard library, it's not unlikely that 
someone will fork it and maintain it as a third party application.


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

Re: Python education survey

2011-12-27 Thread 88888 Dihedral


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

Re: Which libraries for Python 2.5.2


On 12/27/2011 8:42 AM, Lie Ryan wrote:

On 12/28/2011 03:03 AM, W. eWatson wrote:

Here's the traceback.


The traceback seems to imply that matplotlib is not being installed
properly. Have you tried uninstalling then reinstalling matplotlib?


I believe I have, but I'll give it another go.
--
http://mail.python.org/mailman/listinfo/python-list

Re: confused about new


On 12/26/11 21:48 , Fredrik Tolf wrote:

On Mon, 26 Dec 2011, K. Richard Pixley wrote:

I don't understand. Can anyone explain?


I'm also a bit confused about __new__. I'd very much appreciate it if
someone could explain the following aspects of it:

* The manual () says
that __new__ is "a static method (special-cased so you need not declare
it as such)". What does "special-cased" mean? Apparently, for
instance, in OP's case, Python did not automatically detect that it
should not be bound as a method.

* Is there any part of the manual that explains, holistically, the
greater context of object instantiation into which __new__ fits? I can
only find small parts of it spread around the documentation for __new__
and __init__, but no complete explanation of it. There are several
things I'm wondering about, like what it means to call a type object at
all; how methods, properties and the like are bound; how pickle can
instantiate a class without calling __init__; when and whether __dict__
is created and a couple of other things. Is there a complete
documentation of the process anywhere that I haven't managed to find?


Everything I know about this stuff I got by reading the manual.  Search 
for __init__ and you'll find a pretty complete description of how 
objects are created, how to perturb that process, how attributes are 
looked up, and how to perturb that process.  At least, you do in both 
python 2 and python 3 current manuals, I think.


The conceptual leap for me was in recognizing that a class is just an 
object.  The best way, (imo, so far), to create a singleton in python is 
to use the class itself as the singleton rather than ever instantiating 
it.  With a little work, you can even prevent it from ever being 
instantiated.


The concept of a "factory" gets a little weird then, as a factory might 
return an instantiation of some class but it might instead return a 
class proper - perhaps even an automatically constructed class - which 
is a somewhat different sort of factory.


Calling a type is a little bit different.  Calling a class is how you 
initiate an instantiation of that class.  Calling an instantiation leads 
to __call__, (which may or may not have much semantic meaning, depending 
on your class).  It's the difference between C() and C()().  (And the 
analogy holds for other builtin types, I think).


Super() is also fairly well documented.

But __metaclass__ could use a few more examples, imo.  I'm still not 
entirely clear on __metaclass__.  As I understand it, (which may well be 
completely wrong), __metaclass_ is the means of perturbing the results 
of "isinstance".  You can create, (or delete), inheritance arbitrarily, 
and without even requiring real, existing classes to do it.  I'm not 
clear on why you'd want to do this, nor why __metaclass__ is a better 
mechanism than, say, any of the implementations of "interface" which 
have been done in various tool kits or "mixins", which all seem to be 
somewhat overlapping in functionality.


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

Re: Daemon management


On 12/27/2011 12:43 PM, Fredrik Tolf wrote:

Dear list,

Lately, I've had a personal itch to scratch, in that I run a couple of
Python programs as daemons, and sometimes want to inspect or alter them
in ad-hoc ways, or other times need to do things to them that are less
ad-hoc in nature, but nevertheless lack a natural user interface.

In order to solve that problem, I wrote a small library to allow the
daemon to simply listen to some socket and accept arbitrary, but easily
definable, commands. It also provides a "remote REPL" to allow me to run
arbitrary Python code interactively in the context of the daemon.

I was actually a bit surprised that I couldn't find any obvious existing
solution to the problem, so I'm writing this message in order to share
mine, just in case anyone else would happen to have the same problem as
I had and doesn't want to reinvent the wheel yet again:


This is possible through the use of a debugger. I've never used it, but 
I heard good thing of winpdb which has remote debugging. 
(http://winpdb.org/)


Another tool that I've never used is rconsole, part of rfoo library, 
which appears to be similar to pdm; it is also intended for the same 
kind of problem, managing long-running-processes/daemons.


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

Re: Errors installing mod_python with apache

2011-12-27 Thread Mark Seger

I did try yum and got this:

[root@rhel53 tmp]# yum install mod_python
Loaded plugins: rhnplugin, security
This system is not registered with RHN.
RHN support will be disabled.
Setting up Install Process
Parsing package install arguments
No package mod_python available.
Nothing to do

after further digging around I did find rh's mod_python rpm so I installed
than and now seem to be ok.  nevertheless it still bothers me the
'standard' tarball install didn't work.  but I guess I'll leave that to
others to worry about.

thanks
-mark

On Tue, Dec 27, 2011 at 12:02 PM, Rami Chowdhury
wrote:

> On Tue, Dec 27, 2011 at 13:32, Mark Seger  wrote:
> > I've tried this on both RHEL5.5 and RHEL 6.0, using the default apache
> that
> > comes with the environment and itself isn't configured with mod_python.
> >
> > The first thing I noticed when mod_python wouldn't install was that apsx
> > wasn't installed either.  After a lot of pain, I discovered httpd-devel
> > provided apsx and so installed that.
> >
> > Back to mod_python.  After running
> ./configure --with-apxs=/usr/sbin/apxs,
> > according to the README I need to run "make dso", but that promptly
> blows up
> > because it's looking for header files in /usr/include/httpd and itlooks
> like
> > the apxs files are in /usr/include/apr1, so I copied all its contents to
> > /usr/include/httpd.
> >
> > Now when I try to make dso, it successfully gets past finding its header
> > files but now fails with:
> >
> > [root@rhel6 mod_python-2.7.10]#  make dso
> > make[1]: Entering directory `/tmp/mod_python-2.7.10/src'
> > gcc  -I/tmp/mod_python-2.7.10/src/include -I/usr/include/httpd
> > -I/usr/include/python2.6-c -o mod_python.o mod_python.c
> > In file included from /usr/include/python2.6/pyconfig.h:6,
> >  from /usr/include/python2.6/Python.h:8,
> >  from /tmp/mod_python-2.7.10/src/include/mod_python.h:77,
> >  from mod_python.c:54:
> > /usr/include/python2.6/pyconfig-64.h:1031:1: warning: "_POSIX_C_SOURCE"
> > redefined
> > In file included from /usr/include/sys/types.h:26,
> >  from /usr/include/httpd/apr-x86_64.h:127,
> >  from /usr/include/httpd/apr.h:19,
> >  from /usr/include/httpd/ap_config.h:25,
> >  from /usr/include/httpd/httpd.h:43,
> >  from /tmp/mod_python-2.7.10/src/include/mod_python.h:63,
> >  from mod_python.c:54:
> > /usr/include/features.h:213:1: warning: this is the location of the
> previous
> > definition
> > In file included from mod_python.c:54:
> > /tmp/mod_python-2.7.10/src/include/mod_python.h:93: error: expected â=â,
> > â,â, â;â, âasmâ or â__attribute__â before â*â token
> > /tmp/mod_python-2.7.10/src/include/mod_python.h:96: error: expected â=â,
> > â,â, â;â, âasmâ or â__attribute__â before âpython_moduleâ
> > In file included from /tmp/mod_python-2.7.10/src/include/mod_python.h:99,
> >  from mod_python.c:54:
> > /tmp/mod_python-2.7.10/src/include/util.h:57: error: expected â;â, â,â or
> > â)â before â*â token
> > In file included from
> /tmp/mod_python-2.7.10/src/include/mod_python.h:100,
> >  from mod_python.c:54:
> >
> > and a lot more.  Can anyone help?
>
> Is there a reason you're not using the system package manager? Does
> "yum install mod_python" not find anything? How about "yum provides
> */mod_python.so"?
>
>
> --
> Rami Chowdhury
> "A mind all logic is like a knife all blade - it makes the hand bleed
> that uses it." -- Rabindranath Tagore
> +44-7581-430-517 / +1-408-597-7068 / +88-0189-245544
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Errors installing mod_python with apache

2011-12-27 Thread Rami Chowdhury

On Tue, Dec 27, 2011 at 13:32, Mark Seger  wrote:
> I've tried this on both RHEL5.5 and RHEL 6.0, using the default apache that
> comes with the environment and itself isn't configured with mod_python.
>
> The first thing I noticed when mod_python wouldn't install was that apsx
> wasn't installed either.  After a lot of pain, I discovered httpd-devel
> provided apsx and so installed that.
>
> Back to mod_python.  After running ./configure --with-apxs=/usr/sbin/apxs,
> according to the README I need to run "make dso", but that promptly blows up
> because it's looking for header files in /usr/include/httpd and itlooks like
> the apxs files are in /usr/include/apr1, so I copied all its contents to
> /usr/include/httpd.
>
> Now when I try to make dso, it successfully gets past finding its header
> files but now fails with:
>
> [root@rhel6 mod_python-2.7.10]#  make dso
> make[1]: Entering directory `/tmp/mod_python-2.7.10/src'
> gcc  -I/tmp/mod_python-2.7.10/src/include -I/usr/include/httpd
> -I/usr/include/python2.6    -c -o mod_python.o mod_python.c
> In file included from /usr/include/python2.6/pyconfig.h:6,
>                  from /usr/include/python2.6/Python.h:8,
>                  from /tmp/mod_python-2.7.10/src/include/mod_python.h:77,
>                  from mod_python.c:54:
> /usr/include/python2.6/pyconfig-64.h:1031:1: warning: "_POSIX_C_SOURCE"
> redefined
> In file included from /usr/include/sys/types.h:26,
>                  from /usr/include/httpd/apr-x86_64.h:127,
>                  from /usr/include/httpd/apr.h:19,
>                  from /usr/include/httpd/ap_config.h:25,
>                  from /usr/include/httpd/httpd.h:43,
>                  from /tmp/mod_python-2.7.10/src/include/mod_python.h:63,
>                  from mod_python.c:54:
> /usr/include/features.h:213:1: warning: this is the location of the previous
> definition
> In file included from mod_python.c:54:
> /tmp/mod_python-2.7.10/src/include/mod_python.h:93: error: expected â=â,
> â,â, â;â, âasmâ or â__attribute__â before â*â token
> /tmp/mod_python-2.7.10/src/include/mod_python.h:96: error: expected â=â,
> â,â, â;â, âasmâ or â__attribute__â before âpython_moduleâ
> In file included from /tmp/mod_python-2.7.10/src/include/mod_python.h:99,
>                  from mod_python.c:54:
> /tmp/mod_python-2.7.10/src/include/util.h:57: error: expected â;â, â,â or
> â)â before â*â token
> In file included from /tmp/mod_python-2.7.10/src/include/mod_python.h:100,
>                  from mod_python.c:54:
>
> and a lot more.  Can anyone help?

Is there a reason you're not using the system package manager? Does
"yum install mod_python" not find anything? How about "yum provides
*/mod_python.so"?


-- 
Rami Chowdhury
"A mind all logic is like a knife all blade - it makes the hand bleed
that uses it." -- Rabindranath Tagore
+44-7581-430-517 / +1-408-597-7068 / +88-0189-245544
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Which libraries for Python 2.5.2

On Tue, Dec 27, 2011 at 9:03 AM, W. eWatson  wrote:
>  File "C:\Python25\lib\site-packages\matplotlib\transforms.py", line 34, in
> 
>    from matplotlib._path import affine_transform
> ImportError: DLL load failed: The specified module could not be found.

Do you not have the file
C:\Python25\lib\site-packages\matplotlib\_path.pyd?  It's in the
installer archive, so you should be able to just open it up with a zip
program and extract it manually.  If that's missing, then there may be
other things wrong with your installation, though, so I would
recommend a full reinstall.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Which libraries for Python 2.5.2


On 12/28/2011 03:03 AM, W. eWatson wrote:

Here's the traceback.


The traceback seems to imply that matplotlib is not being installed 
properly. Have you tried uninstalling then reinstalling matplotlib?


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

Re: Python education survey

On Dec 27, 12:14 am, Carl Smith  wrote:
> Do people seriously use IDLE? I thought it was just there for
> scratchers, like turtle.

I know for a fact that many folks use IDLE, even some rather "well
known" folks around here. The fact is, more people use IDLE than admit
to using IDLE. Of course, out of respect, i will not mention their
names myself. Hopefully they will chime in..?

There is a stigma in this community towards IDLE. I am not sure
exactly how it started, or on what logic (or lack thereof) it is
based, but the stigma exists no doubt. I believe it may be just an
extension of the TCL/TK stigma (since IDLE is coded using Tkinter).

My logic is this:
 """ Including an IDE in the stdlib may have been a bad idea (although
i understand and support Guido's original vision for IDLE). But since
we do have it, we need to either MAINTAIN the package or REMOVE it. We
cannot just stick our heads in the sand and ignore the elephant in the
chicken coop. It's bad enough to bloat ANY stdlib with seldom used
modules, but i dare say, it's far worse to bloat a library with seldom
used modules that are poorly maintained! Every module in Python's
stdlib is a testament to the skill and professionalism of this
community as a whole. When a module looks or works badly, we ALL look
and work badly."""

It's no big secret to anyone in this community that both Tkinter and
IDLE are the red headed step children of Pythons stdlib. Very few
people speak kindly of either package. I believe GvR still believes in
the merits of both packages (psst: batteries included!) but he finds
himself at odds with the elite at pydev. Hmm, Maybe he DOES want to
remove them but fears loosing face...FYI: Guido IS is the original
author of both Tkinter and IDLE... it was HIS idea after all. However,
it is high time to re-ignite the original vision and form these
packages into something we can be proud of -- OR -- cut our losses and
remove them forever.

This indecisiveness, collective bickering, and lack of true leadership
is shameful.
-- 
http://mail.python.org/mailman/listinfo/python-list

PDF 508 Compliance with Python?

2011-12-27 Thread Yanovsky, Boris, VHACIN

Hello,

 

I am new to Python and I hope my question makes sense. We are trying to
make PDFs 508 Compliant, meaning that the objects within them have to be
tagged. The problem is that we have hundreds, and potentially thousands
of PDFs, since they are automated reports that we create on a regular
basis.

 

Is there a code or feature in Python that can read PDFs and tag the
objects within them for this kind of compliance?

 

Thanks in advance.

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

Which libraries for Python 2.5.2

I'm trying to restore Python 2.5.2 on an old XP PC for a particular 
application from 4-5 years ago that uses it .


According to the latest manual on it, the following should be installed.

python-2.5.2.msi
PIL-1.1.6.win32-py2.5.exe
numpy-1.1.0-win32-superpack-python2.5.exe
matplotlib-0.98.1.win32-py2.5.exe

When I install them, and try to run the app program, Sentinel.py, some 
part of matplotlib complains (error msgs) and the program quits.


The program begins with:
from Tkinter import *
from numpy import *
import Image
import ImageChops
import ImageTk
import time
import binascii
import tkMessageBox
import tkSimpleDialog
from pylab import plot, xlabel, ylabel, title, show, xticks, bar

I tried numpy-1.2.0 and matplotlib-0.98.3 and had the same difficulty. 
What are wiser choices?


Here's the traceback.

Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit 
(Intel)] on win32

Type "copyright", "credits" or "license()" for more information.


Personal firewall software may warn about the connection IDLE
makes to its subprocess using this computer's internal loopback
interface.  This connection is not visible on any external
interface and no data is sent to or received from the Internet.


IDLE 1.2.2   No Subprocess 
>>>
Traceback (most recent call last):
  File "C:\Sentinel\Sent_user-20080716.py", line 16, in 

(SEE THIS from the above list of imports, and the from)<*---<
from pylab import plot, xlabel, ylabel, title, show, xticks, bar
  File "C:\Python25\lib\site-packages\pylab.py", line 1, in 
from matplotlib.pylab import *
  File "C:\Python25\lib\site-packages\matplotlib\pylab.py", line 206, 
in 

from matplotlib import mpl  # pulls in most modules
  File "C:\Python25\lib\site-packages\matplotlib\mpl.py", line 1, in 


from matplotlib import artist
  File "C:\Python25\lib\site-packages\matplotlib\artist.py", line 4, in 

from transforms import Bbox, IdentityTransform, TransformedBbox, 
TransformedPath
  File "C:\Python25\lib\site-packages\matplotlib\transforms.py", line 
34, in 

from matplotlib._path import affine_transform
ImportError: DLL load failed: The specified module could not be found.
>>>
--
http://mail.python.org/mailman/listinfo/python-list

Re: Possible bug in string handling (with kludgy work-around)

2011-12-27 Thread Charles Hixson


That was it!  Thanks.

On 12/26/2011 02:44 PM, Chris Angelico wrote:

On Tue, Dec 27, 2011 at 9:23 AM, Charles Hixson
  wrote:
   

This doesn't cause a crash, but rather incorrect results.
 

You may need to be a bit clearer. What line of code (or what
expression)? What did you expect to see, and what did you see?

> From examining your code, I've come up with one most-likely scenario.
In Python, indexing is zero-based and, in effect, indexes the
boundaries between items rather than the items themselves. Referencing
string[-1] actually means asking for the boundary between the
second-last and last characters; using that as your end marker
actually trims off the last character. What you may want is simply:

self.wordList[i][1:]

which means "from character position 1 to the end of the string".

Hope that helps!

Chris Angelico
   

Sorry I didn't specify things more clearly.

--
Charles Hixson

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

Errors installing mod_python with apache

2011-12-27 Thread Mark Seger

I've tried this on both RHEL5.5 and RHEL 6.0, using the default apache that
comes with the environment and itself isn't configured with mod_python.

The first thing I noticed when mod_python wouldn't install was that apsx
wasn't installed either.  After a lot of pain, I discovered httpd-devel
provided apsx and so installed that.

Back to mod_python.  After running ./configure --with-apxs=/usr/sbin/apxs,
according to the README I need to run "make dso", but that promptly blows
up because it's looking for header files in /usr/include/httpd and itlooks
like the apxs files are in /usr/include/apr1, so I copied all its contents
to /usr/include/httpd.

Now when I try to make dso, it successfully gets past finding its header
files but now fails with:

[root@rhel6 mod_python-2.7.10]#  make dso
make[1]: Entering directory `/tmp/mod_python-2.7.10/src'
gcc  -I/tmp/mod_python-2.7.10/src/include -I/usr/include/httpd
-I/usr/include/python2.6-c -o mod_python.o mod_python.c
In file included from /usr/include/python2.6/pyconfig.h:6,
 from /usr/include/python2.6/Python.h:8,
 from /tmp/mod_python-2.7.10/src/include/mod_python.h:77,
 from mod_python.c:54:
/usr/include/python2.6/pyconfig-64.h:1031:1: warning: "_POSIX_C_SOURCE"
redefined
In file included from /usr/include/sys/types.h:26,
 from /usr/include/httpd/apr-x86_64.h:127,
 from /usr/include/httpd/apr.h:19,
 from /usr/include/httpd/ap_config.h:25,
 from /usr/include/httpd/httpd.h:43,
 from /tmp/mod_python-2.7.10/src/include/mod_python.h:63,
 from mod_python.c:54:
/usr/include/features.h:213:1: warning: this is the location of the
previous definition
In file included from mod_python.c:54:
/tmp/mod_python-2.7.10/src/include/mod_python.h:93: error: expected â=â,
â,â, â;â, âasmâ or â__attribute__â before â*â token
/tmp/mod_python-2.7.10/src/include/mod_python.h:96: error: expected â=â,
â,â, â;â, âasmâ or â__attribute__â before âpython_moduleâ
In file included from /tmp/mod_python-2.7.10/src/include/mod_python.h:99,
 from mod_python.c:54:
/tmp/mod_python-2.7.10/src/include/util.h:57: error: expected â;â, â,â or
â)â before â*â token
In file included from /tmp/mod_python-2.7.10/src/include/mod_python.h:100,
 from mod_python.c:54:

and a lot more.  Can anyone help?

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

Re: Python education survey

On Dec 27, 6:59 am, Carl Smith  wrote:
> On Dec 20, 10:58 am, Andrea Crotti  wrote:
>
>
>
>
>
>
>
>
>
> > On 12/20/2011 03:51 AM, Raymond Hettinger wrote:
>
> > > Do you use IDLE when teaching Python?
> > > If not, what is the tool of choice?
>
> > > Students may not be experienced with the command-line and may be
> > > running Windows, Linux, or Macs.  Ideally, the tool or IDE will be
> > > easy to install and configure (startup directory, path, associated
> > > with a particular version of Python etc).
>
> > > Though an Emacs user myself, I've been teaching with IDLE because it's
> > > free; it runs on multiple OSes, it has tooltips and code colorization
> > > and easy indent/dedent/comment/uncomment commands, it has tab
> > > completion; it allows easy editing at the interactive prompt; it has
> > > an easy run-script command (F5); it has direct access to source code
> > > (File OpenModule) and a class browser (Cntl+B).
>
> > > On the downside, some python distros aren't built with the requisite
> > > Tcl/Tk support; some distros like the Mac OS ship with a broken Tcl/Tk
> > > so users have to install a fix to that as well; and IDLE sometimes
> > > just freezes for no reason.  It also doesn't have an easy way to
> > > specify the startup directory.
>
> > > If your goal is to quickly get new users up and running in Python,
> > > what IDE or editor do you recommend?
>
> > > Raymond
>
> > I think ipython and a good editor gives a much nicer experience
> > than IDLE, which I actually almost never used, and
> > for everything else there is python and python-mode.
>
> > New users however can be pointed to something like PyCharm
> > or Eclipse+PyDev if they are more familiar to IDEs..
>
> I agree; IPython is a excellent choice. You have a much more powerful
> interactive Python experience, with all the features you need from an
> IDE. You can use any editor (VIM) and you can also readily hack
> IPython to death.
>
> I think the fact that anyone with basic programming skills can
> substantially enhance their console is a big winner in CS education.
> It gives students something they personally value to work on, it's a
> place to store all their little bits of code and actually benefit from
> them in real life.
>
> I've never met a programmer that got familiar with IPython and then
> went on to stop using it. It should be included in the standard
> library and used as the default Python interactive environment.
>
> The last line of my .bashrc file:
>
> ipython3

Youve got one here. I like IPython a lot, but it quite rarely enters
into my workflow.

While I agree that a good interactive python console is a good way to
get your feet wet with programming, I also strongly feel that a more
comprehensive programming environment should be introduced to
students. That includes opening and editing files, syntax
highlighting, and code completion. And painless installation. There
are no lightweight editors that provide all this functionality in
conjuction with Ipython*. So I prefer to work the other way around;
use something like pycharm, and open an IPython interactive session
within it.

*Your suggestion of VIM is especially objectionable. Though I am sure
it is a great tool to you, the subject here is beginner education.
Just because it is a good tool for you, does not make it a good tool
for a beginner.

IPython bundled with a lightweight but function-rich and non-hacker-
but-WYSIWYG editor would be a great choice. But until that comes
around, pycharm it is for me.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Plot seems weird


On 12/27/2011 06:14 AM, Yigit Turgut wrote:

On Dec 26, 8:58 pm, Lie Ryan  wrote:

On 12/27/2011 04:08 AM, Yigit Turgut wrote:

not your fault, I made a mistake when copy-pasteing the code, here's the
fixed code:

from itertools import izip_longest
def to_square(data):
   sq_data = [[], []]
   for x,y, xn in izip_longest(data[0], data[1], data[0][1:]):
   sq_data[0].append(x)
   sq_data[1].append(y)
   sq_data[0].append(xn)
   sq_data[1].append(y)
   return numpy.array(sq_data, dtype=float)

use it like this:

t,y1 = to_square(numpy.genfromtxt(filename, unpack=True))
pyplot.plot(t,y1)
pyplot.show()


Significant improvement on the plot, pretty interesting. It runs ok
but I need to know how?! (:


it's pretty simple, actually; just observe the numbers before and after 
it's fixed by the function and it should be fairly obvious.


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

Re: python logging module:a quick question


On 12/27/2011 05:26 PM, Littlefield, Tyler wrote:

Hello all:
I have a basic server I am working on, and wanted some input with an
error I'm getting.
I am initializing the logger like so:
if __name__ == "__main__":
observer = log.PythonLoggingObserver()
observer.start()
logging.basicConfig(filename='logs/server.log', level=logging.DEBUG,
format='%(asctime)s [%(levelname)s] %(module)s:%(funcname)s:%(lineno)d
%(message)s')
logger = logging.getLogger()
logger.addHandler(logging.handlers.TimedRotatingFileHandler)


You should pass an **instance** of the handler, not the class; so it 
should look like this:


logger.addHandler(logging.handlers.TimedRotatingFileHandler(...))

if you want to configure the handler, e.g. configure how often the log 
file is rotated, you can do it by passing parameters to the handler's 
constructure, e.g.:


logger.addHandler(logging.handlers.TimedRotatingFileHandler(filename='/foo/mylog.log', 
when='d', interval=3, backupCount=5))


will create a handler that will log to the file /foo/mylog.log and 
rotate the log every 3 days and keeps the last 5 logs for backup.


the logging handlers are documented over here: 
http://docs.python.org/library/logging.handlers.html#logging.handlers.TimedRotatingFileHandler


Note that if you're using a recent enough version of python, it's also 
possible to configure the logging module using a dictionary-based 
configuration. Dictionary-based configuration is generally simpler than 
code-based configuration.


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

Re: Pythonification of the asterisk-based collection packing/unpacking syntax