Re: Class decorators might also be super too

[Michele Simionato]

He is basically showing that using mixins for implementing logging is not such 
a good idea, i.e. you can get the same effect in a better way by making use of 
other Python features. I argued the same thing many times in the past. I even 
wrote a module once (strait) to reimplement 99% of multiple inheritance without 
multiple inheritance, just to show that in can be done in few lines of code in 
a language as powerful as Python.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: float("nan") in set or as key

[John Nagle]

On 5/28/2011 6:04 PM, Gregory Ewing wrote:

MRAB wrote:

float("nan") can occur multiple times in a set or as a key in a dict:

>>> {float("nan"), float("nan")}
{nan, nan}

except that sometimes it can't:

>>> nan = float("nan")
>>> {nan, nan}
{nan}


NaNs are weird. They're not equal to themselves:

Python 2.7 (r27:82500, Oct 15 2010, 21:14:33)
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> nan = float("nan")
 >>> nan == nan
False

This confuses the daylights out of Python's dict lookup machinery,
which assumes that two references to the same object can't possibly
compare unequal, so it doesn't bother calling __eq__ on them.


   Right.

   The correct answer to "nan == nan" is to raise an exception, because
you have asked a question for which the answer is nether True nor False.

   The correct semantics for IEEE floating point look something like
this:

1/0 INF
INF + 1 INF
INF - INF   NaN
INF == INF  unordered
NaN == NaN  unordered

INF and NaN both have comparison semantics which return
"unordered". The FPU sets a bit for this, which most language
implementations ignore.  But you can turn on floating point
exception traps, and on x86 machines, they're exact - the
exception will occur exactly at the instruction which
triggered the error.   In superscalar CPUs, a sizable part of
the CPU handles the unwinding necessary to do that.  x86 does
it, because it's carefully emulating non-superscalar machines.
Most RISC machines don't bother.

Python should raise an exception on unordered comparisons.
Given that the language handles integer overflow by going to
arbitrary-precision integers, checking the FPU status bits is
cheap.

The advantage of raising an exception is that the logical operations
still work.  For example,

not (a == b)
a != b

will always return the same results if exceptions are raised for
unordered comparison results.  Also, exactly one of

a = b
a < b
a > b

is always true - something sorts tend to assume.

If you get an unordered comparison exception, your program
almost certainly was getting wrong answers.

(I used to do dynamics simulation engines, where this mattered.)

John Nagle

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

Re: Beginner needs advice

[Dotan Cohen]

On Fri, May 27, 2011 at 23:40, harrismh777  wrote:
> You have erected a straw-man... once again.
>

I think that is a red herring, not a strawman.

> Most 2.x code *will not* run correctly in 3.x/  Most of the best
> improvements and enhancements of 3.x will not back-port to below 2.7, and
> almost none of them will back-port before 2.6 (class decorations, for
> instance).
>

Although it is true that 2.x code will not run in a 3.x environment,
the changes to the code are minimal. This would be akin to saying that
a 2008 Peugeot 407 will not drive on a Canadian road because the
license plate is a different shape. Just go an put a different plastic
license plate holder on the Peugeot and it will run fine on the
Canadian road. The changes to bring Python 2 code into Python 3 code
are minimal, and it would be a terrific learning experience for the OP
to go back and revise his old code to do just that.

Furthermore, the OP is not just learning Python for the fun of
learning Python. If that were the case, then I would agree that Python
3 is the way to go. The OP needs to use imaging libraries which may
not yet work in Python 3 (I have not checked, but it is very likely
that they do not). Therefore Python 3 is a non-starter in any case.

-- 
Dotan Cohen

http://gibberish.co.il
http://what-is-what.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Beginner needs advice

[harrismh777]

Steven D'Aprano wrote:

A straw man is not when somebody points out holes in your argument, or
unwanted implications that you didn't realise were there. It is when
somebody makes claims on your behalf that you did not make to discredit
you, not because you don't understand the implications of your own
argument.


The straw-man fallacy is when you erect a "straw man" to "represent" the 
actual man (or idea) which can be easily knocked down, and then you 
proceed to knock it down (the straw-man) as though the "straw man" was 
the actual man, or idea... proving your point as-it-were against your 
opponent when in fact you have only just knocked down the straw-man... 
leaving the real man standing.


This fallacy has a couple of nuances (sometimes combined with metaphor 
or analogy fallacy) and you are a master at presenting both... 
thankfully you usually don't try to present both at the same time!  :)


In this present case the straw-man was not "me," rather the straw-man 
was the python language itself. You chose a code-snippet (one small puny 
dangle that doesn't prove a thing) and used it to speak for the entire 
language!  As though one code-block is enough to demonstrate 
compatibility for the entire language in all of its nuances and details. 
 To prove something positive with a test case requires that you provide 
*all* test cases, or that you provide an algorithm that accounts for 
*all* test cases... you cannot prove compatibility with a code-snippet.


On the other hand, all you have to do to prove incompatibility is to 
show "one" (1) test case where compatibility fails... and of course for 
the present case there are many that can be shown, in fact, hundreds of 
them.


The thing that nobody has presented here yet is that *all* the books 
declare that 3.x is incompatible with 2.x/   ... some of them go out of 
their way to tell the reader that they are only going to deal with 3.x 
and not 2.x in any way... and others go out of their way to point out 
the hundreds of nuances in details between the two languages. (and a 
good thing too, for those of us who must work with both! )  So this fact 
is not alluding the press... the point being not to bust anybody in the 
chops, but to point out that it is not helpful to move the community 
forward with a new language and get mass adoption (not just early 
adopters) to lie about the differences between the two sets... yes, for 
trivial code blocks that use prime constructs, integer math, and the 
print statement, not much has changed.  But in real world applications 
of the language there are many hundreds of details that have changed or 
been added (deleted) which will make life difficult for the uninitiated. 
Don't mislead people by saying that very little has changed.  Tell them 
that the philosophy is the same (what Chris called python 'think' ) but 
be honest about the details of syntax, environment, layout, and 
morphology.





kind regards,
m harris






kind regards,
m harris




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

Re: float("nan") in set or as key

[Grant Edwards]

On 2011-05-29, Albert Hopkins  wrote:
> On Sun, 2011-05-29 at 00:41 +0100, MRAB wrote:
>> Here's a curiosity. float("nan") can occur multiple times in a set or as 
>> a key in a dict:
>> 
>>  >>> {float("nan"), float("nan")}
>> {nan, nan}
>> 
> These two nans are not equal (they are two different nans)
>
>> except that sometimes it can't:
>> 
>>  >>> nan = float("nan")
>>  >>> {nan, nan}
>> {nan}
>
> This is the same nan, so it is equal to itself.

No, it's not.

>>> x = float("nan")
>>> y = x
>>> x is y
True
>>> x == y
False

> I can't cite this in a spec, but it makes sense (to me) that two things
> which are nan are not necessarily the same nan.

Even if they _are_ the same nan, it's still not equal to itself.

-- 
Grant


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

Re: Beginner needs advice

[Chris Angelico]

On Sun, May 29, 2011 at 12:02 PM, harrismh777  wrote:
> Chris Angelico wrote:
>> Both versions of Python are
>> the same language, because they "think" the same way;
>     I see your point. But, knowing that 3.x "thinks" like 2.x is not helpful
> when we all know that languages don't think, people do.

I was being (deliberately) sloppy with the English language there, but
I was referring to the fundamental philosophies of Python, which are
common across both versions (and, presumably, most/all of them can be
seen in Python 1 too; I've never used Python 1).

>> Little syntactic
>> differences like whether 'print' is a function or a statement, and
>> whether the simple slash operator between two ints returns a float,
>> and the fact that Unicode is the default string type, are
>> comparatively minor; on 'most every philosophical point, the two
>> dialects agree.
>
>   Minor, yes,  until you need to make something work--- only to be
> frustrated to find that a detail that was not expected has risen to bite a
> sensitive place...   :)

I get far worse than those when I switch between languages and forget
operator precedence, or forget that function X has its parameters the
other way around, or whatever. They are minor, and if you're not 100%
familiar with the language you're writing in, you should probably have
its docs handy anyway.

The print function will bite you instantly, you'll know what's wrong
as soon as you try to run it. Unicode strings, too, will usually throw
a nice tidy exception. The only one that's going to really sting you
is division, and it's so easy to deal with that one as you code
(always use // for flooring).

> instance, how do we reload a module in 2.x...  with, um, reload.   This has
> always been the way... every book says so, and every one of us has
> re-invoked a .py file by using relaod.  Reload doesn't even work on 3.x
> without an import.

>From what I gather, Python simply isn't designed with that sort of
"live reload" in mind. Just terminate it and start over, it's easier.
If you want a system where you reload parts of it without bringing
things down, either build it manually (loading another piece of code,
and maybe reassigning some state variables that have your functions),
or pick a different language - Pike does this excellently. That's not
an indictment of Python; it's simply that Python is not everything.

> Some of the posts here are referring to the two languages as partially
> incompatible   reminds me of that line from Princess Bride... "... he's
> not dead, hes only mostly dead!... and mostly dead is partly alive!"  To say
> that 3.x is partly compatible with 2.x is silly, but to say that 3.x
> 'thinks' the same way as 2.x is almost pythonesque...  I almost like that...

Mostly compatible is still partly incompatible? Sure. But "mostly
compatible" is Python 2.6.6 and Python 2.7.1, too. It's easy to write
one codebase that runs under multiple Python versions; certainly it's
a lot easier than writing one source file that's both Python and C,
for instance. And the same lines of code will be doing the same work
(unlike most polyglottisms, where one language's code is another
language's comments). There is a subset of Python 2 that is also a
subset of Python 3, and this intersection is quite large.

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

Re: Beginner needs advice

[harrismh777]

Chris Angelico wrote:

Both versions of Python are
the same language, because they "think" the same way;


 I appreciate your thought. And there is an obvious continuity in 
philosophy between 2.x and 3.x; in fact even a cursory study of the 
history of python demonstrates a concerted effort to build on the best 
points of 2.x while eliminating the worst.   3.x builds upon and adds to 
2.x,  as (loosely)  C++ builds on and adds to C.  Perhaps python3 should 
have been named Python+  !   ( I think I've already told yous guys that 
I invoke python3 on my desk machine with---  Anaconda


 I see your point. But, knowing that 3.x "thinks" like 2.x is not 
helpful when we all know that languages don't think, people do. People 
need to be able to understand the 'details' of the language in order to 
be able to think with it...



Little syntactic
differences like whether 'print' is a function or a statement, and
whether the simple slash operator between two ints returns a float,
and the fact that Unicode is the default string type, are
comparatively minor; on 'most every philosophical point, the two
dialects agree.


   Minor, yes,  until you need to make something work--- only to be 
frustrated to find that a detail that was not expected has risen to bite 
a sensitive place...   :)


   I am amazed at how many folks are not using 3.x/  Why?  (beats me), 
but how do I know they're not using it...?   Because, if they were 
trying to use it with 2.x knowledge they would be complaining bloody 
murder..   for instance, how do we reload a module in 2.x...  with, um, 
reload.   This has always been the way... every book says so, and every 
one of us has re-invoked a .py file by using relaod.  Reload doesn't 
even work on 3.x without an import. If you don't know that, well, you're 
sol until you figure it out, read it, or somebody tells you. This ought 
not to be.  Even the environments of these two languages are 
incompatible (partially)   :)



PS   Something nobody has pointed out yet is that "completely 
incompatible" is redundant.   ... its like saying totally destroyed.

I was trying to be funny, but nobody unpinned it... I'm disappointed.

Some of the posts here are referring to the two languages as partially 
incompatible   reminds me of that line from Princess Bride... "... 
he's not dead, hes only mostly dead!... and mostly dead is partly 
alive!"  To say that 3.x is partly compatible with 2.x is silly, but to 
say that 3.x 'thinks' the same way as 2.x is almost pythonesque...  I 
almost like that...   :)









kind regards,
m harris



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

Re: The worth of comments

[Irmen de Jong]

On 29-5-2011 2:47, Gregory Ewing wrote:
> Irmen de Jong wrote:
> 
>> I don't see how that is opposed to what Grant was saying. It's that these 
>> 'contracts'
>> tend to change and that people forget or are too lazy to update the comments 
>> to reflect
>> those changes.
> 
> However, I can't see that deleting the comment documenting the
> contract can be the right response to the situation.
> 
> If the contract comment doesn't match what code does, then
> there are two possibilities -- the comment is wrong, or the
> code is wrong. The appropriate response is to find out which
> one is wrong and fix it.

Fair enough.

Certainly I won't be deleting every source code comment encountered from now 
on, but I
do think we should keep in mind the risks already mentioned. In some situations 
I can
very well imagine it is best to simply delete any comments and go with just the 
code.


> If you simply delete the comment, then you're left with no
> redundancy to catch the fact that something is wrong.

You are right, if you don't have a Unit test for it.
Then again, faulty unit tests are a problem in their own right...

Irmen de Jong
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The worth of comments

[Ben Finney]

Gregory Ewing  writes:

> If the contract comment doesn't match what code does, then there are
> two possibilities -- the comment is wrong, or the code is wrong. The
> appropriate response is to find out which one is wrong and fix it.

You omit the common third possibility: *both* the comment and the code
are wrong.

That's the one that I bet on whenever I notice code and comment don't
match.

-- 
 \ “Anyone can do any amount of work provided it isn't the work he |
  `\  is supposed to be doing at the moment.” —Robert Benchley |
_o__)  |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: float("nan") in set or as key

[Gregory Ewing]

MRAB wrote:
float("nan") can occur multiple times in a set or as 
a key in a dict:


 >>> {float("nan"), float("nan")}
{nan, nan}

except that sometimes it can't:

 >>> nan = float("nan")
 >>> {nan, nan}
{nan}


NaNs are weird. They're not equal to themselves:

Python 2.7 (r27:82500, Oct 15 2010, 21:14:33)
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> nan = float("nan")
>>> nan == nan
False

This confuses the daylights out of Python's dict lookup machinery,
which assumes that two references to the same object can't possibly
compare unequal, so it doesn't bother calling __eq__ on them.

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

Re: English Idiom in Unix: Directory Recursively

[Steven D'Aprano]

On Sun, 29 May 2011 05:58:01 +1000, Chris Angelico wrote:

> Geeks tend to have larger vocabularies than non-geeks, on average;
> probably akin to our love of word games and precision (two distinct
> notions that bridge surprisingly often).

And also because more educated people in general tend to have larger 
vocabularies than less educated people: both for the number of words they 
actually use, and those they can interpret in context.

Geeks sometimes tend to forget that they're not the only smart, educated 
people who use "hard" (big, technical, complicated) words.


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

Re: The worth of comments

[Gregory Ewing]

Irmen de Jong wrote:


I don't see how that is opposed to what Grant was saying. It's that these 
'contracts'
tend to change and that people forget or are too lazy to update the comments to 
reflect
those changes.


However, I can't see that deleting the comment documenting the
contract can be the right response to the situation.

If the contract comment doesn't match what code does, then
there are two possibilities -- the comment is wrong, or the
code is wrong. The appropriate response is to find out which
one is wrong and fix it.

If you simply delete the comment, then you're left with no
redundancy to catch the fact that something is wrong.

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

Re: float("nan") in set or as key

[Erik Max Francis]

Albert Hopkins wrote:

On Sun, 2011-05-29 at 00:41 +0100, MRAB wrote:

1.0 == 1.0

True

float("nan") == float("nan")

False

I can't cite this in a spec, but it makes sense (to me) that two things
which are nan are not necessarily the same nan.


It's part of the IEEE standard.

--
Erik Max Francis && m...@alcyone.com && http://www.alcyone.com/max/
 San Jose, CA, USA && 37 18 N 121 57 W && AIM/Y!M/Skype erikmaxfrancis
  There was never a good war or a bad peace.
   -- Benjamin Franklin, 1706-1790
--
http://mail.python.org/mailman/listinfo/python-list

Re: How to catch a line with Popen

[Dan Stromberg]

On Sat, May 28, 2011 at 4:32 PM, Tim Roberts  wrote:

> TheSaint  wrote:
> >
> >I'm looking into subprocess.Popen docs.
> >I've launch the program with its arguments and that's smooth. I'm
> expecting
> >to read the output by *comunicate()* at every line that prgram may blow
> >during the process, but the output is given only when the child process is
> >ended.
> >I'd like to process the lines to display an information in percentage
> during
> >the running time of the child.
>
> Are you specifying a buffer size in the Popen command?  If not, then the
> Python side of things is unbuffered.  It's possible that the application
> you are launching is buffering its output, so that it doesn't SEND until
> the application ends.
>

I believe there are 4 normal ways, and 1 special way of getting output from
a buffered application:

1) As you mentioned, the program could terminate
2) Also, the program could just have written enough to fill its buffer, so
it outputs the content of the buffer before starting to fill it again
3) Also, the program could call flush
4) Also, the program could use an unbuffered file, like stderr - not all
file in an application are astonishingly likely to be buffered the same way

And the special one:
1) Sometimes you can take a buffered program and get it to be unbuffered (or
at least line buffered) by running it on a pty.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: float("nan") in set or as key

[Chris Angelico]

On Sun, May 29, 2011 at 10:28 AM, Albert Hopkins  wrote:
> This is the same nan, so it is equal to itself.
>

Actually, they're not. But it's possible the dictionary uses an 'is'
check to save computation, and if one thing 'is' another, it is
assumed to equal it. That's true of most well-behaved objects, but nan
is not well-behaved :)

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

Re: float("nan") in set or as key

[Steven D'Aprano]

On Sun, 29 May 2011 00:41:16 +0100, MRAB wrote:

> Here's a curiosity. float("nan") can occur multiple times in a set or as
> a key in a dict:
> 
>  >>> {float("nan"), float("nan")}
> {nan, nan}

That's an implementation detail. Python is free to reuse the same object 
when you create an immutable object twice on the same line, but in this 
case doesn't. (I don't actually know if it ever does, but it could.)

And since NAN != NAN always, you can get two NANs in the one set, since 
they're unequal.


> when you write float('nan')
> 
> except that sometimes it can't:
> 
>  >>> nan = float("nan")
>  >>> {nan, nan}
> {nan}

But in this case, you try to put the same NAN in the set twice. Since 
sets optimize element testing by checking for identity before equality, 
the NAN only goes in once.


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

Re: float("nan") in set or as key

[Tim Delaney]

On 29 May 2011 10:16, Erik Max Francis  wrote:

> MRAB wrote:
>
>> Here's a curiosity. float("nan") can occur multiple times in a set or as a
>> key in a dict:
>>
>>  >>> {float("nan"), float("nan")}
>> {nan, nan}
>>
>> except that sometimes it can't:
>>
>>  >>> nan = float("nan")
>>  >>> {nan, nan}
>> {nan}
>>
>
> It's fundamentally because NaN is not equal to itself, by design.
> Dictionaries and sets rely on equality to test for uniqueness of keys or
> elements.
>
>
> >>> nan = float("nan")
> >>> nan == nan
> False
>
> In short, don't do that.


There's a second part the mystery - sets and dictionaries (and I think
lists) assume that identify implies equality (hence the second result). This
was recently discussed on python-dev, and the decision was to leave things
as-is.

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

Re: float("nan") in set or as key

[Albert Hopkins]

On Sun, 2011-05-29 at 00:41 +0100, MRAB wrote:
> Here's a curiosity. float("nan") can occur multiple times in a set or as 
> a key in a dict:
> 
>  >>> {float("nan"), float("nan")}
> {nan, nan}
> 
These two nans are not equal (they are two different nans)

> except that sometimes it can't:
> 
>  >>> nan = float("nan")
>  >>> {nan, nan}
> {nan}

This is the same nan, so it is equal to itself.

Two "nan"s are not equal in the manner that 1.0 and 1.0 are equal:

>>> 1.0 == 1.0
True
>>> float("nan") == float("nan")
False


I can't cite this in a spec, but it makes sense (to me) that two things
which are nan are not necessarily the same nan.

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

Re: float("nan") in set or as key

[Erik Max Francis]

MRAB wrote:
Here's a curiosity. float("nan") can occur multiple times in a set or as 
a key in a dict:


 >>> {float("nan"), float("nan")}
{nan, nan}

except that sometimes it can't:

 >>> nan = float("nan")
 >>> {nan, nan}
{nan}


It's fundamentally because NaN is not equal to itself, by design. 
Dictionaries and sets rely on equality to test for uniqueness of keys or 
elements.


>>> nan = float("nan")
>>> nan == nan
False

In short, don't do that.

--
Erik Max Francis && m...@alcyone.com && http://www.alcyone.com/max/
 San Jose, CA, USA && 37 18 N 121 57 W && AIM/Y!M/Skype erikmaxfrancis
  There was never a good war or a bad peace.
   -- Benjamin Franklin, 1706-1790
--
http://mail.python.org/mailman/listinfo/python-list

float("nan") in set or as key

[MRAB]

Here's a curiosity. float("nan") can occur multiple times in a set or as 
a key in a dict:


>>> {float("nan"), float("nan")}
{nan, nan}

except that sometimes it can't:

>>> nan = float("nan")
>>> {nan, nan}
{nan}
--
http://mail.python.org/mailman/listinfo/python-list

Re: How to catch a line with Popen

[Tim Roberts]

TheSaint  wrote:
>
>I'm looking into subprocess.Popen docs.
>I've launch the program with its arguments and that's smooth. I'm expecting 
>to read the output by *comunicate()* at every line that prgram may blow 
>during the process, but the output is given only when the child process is 
>ended.
>I'd like to process the lines to display an information in percentage during 
>the running time of the child.

Are you specifying a buffer size in the Popen command?  If not, then the
Python side of things is unbuffered.  It's possible that the application
you are launching is buffering its output, so that it doesn't SEND until
the application ends.
-- 
Tim Roberts, t...@probo.com
Providenza & Boekelheide, Inc.
-- 
http://mail.python.org/mailman/listinfo/python-list

portable way of sending notifying a process

[News123]

Hi,


I'm looking for a portable way (windows XP / Windows Vista and Linux )
to send a signal from any python script to another one
(one signa would be enough)

I have several python scripts started from different parent processes

occasionally some of the scripts want to tell another to reread it's
config file ( kill -HUP)

It seems, that neither the signals HUP / USR1 are implemented under windows.

What would be a light weight portable way, that one process can tell
another to do something?

The main requirement would be to have no CPU impact while waiting (thus
no polling)

Thanks for any suggestion of small portable libraries or code snippets.


The options, that I found so far seem to be a little too big or not
portable:
- sending the HUP signal doesn't work under win
- inotify doesn't work under win
- pyro seems to be a little too big for such a 'trivial' task
- watchdog might be a solution, but requires
three other non standard libraries to be installed.
So I'm not sure it's really lightweight


If nothing exists I might just write a wrapper around
pyinotify and (Tim Goldens code snippet allowing to watch a directory
for file changes)
http://timgolden.me.uk/python/win32_how_do_i/watch_directory_for_changes.html

and use a marker file in a marker directory
but I wanted to be sure of not reinventing the wheel.




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

Re: Parse config file and command-line arguments, to get a single collection of options

[rzed]

Ben Finney  wrote in
news:87k4deaxfc@benfinney.id.au: 

> Howdy all,
> 
> Python's standard library has modules for configuration file
> parsing (configparser) and command-line argument parsing
> (optparse, argparse). I want to write a program that does both,
> but also: 
> 
> * Has a cascade of options: default option values, overridden by
> config 
>   file options, overridden by command-line options.
> 
> * Reads a different, or even additional, configuration file if
> specified 
>   on the command-line (e.g. --config-file foo.conf) and yet still
>   obeys the above cascade.
> 
> * Allows a single definition of an option (e.g. logging level) to
> define 
>   the same option for parsing from configuration files and the
>   command line.
> 
> * Unifies the parsed options into a single collection for the
> rest of 
>   the program to access without caring where they came from.
> 
> How can I achieve this with minimum deviation from the Python
> standard library?
> 
> 
> (For anyone interested in gaining StackOverflow points, I'm also
> asking this as a question there so feel free to post answers on
> that site 
> http://stackoverflow.com/questions/6133517/parse-config-file-
> and-command-line-arguments-to-get-a-single-collection-of-optio>.) 
> 

This seems vaguely similar to a module I wrote and use all the time. 
It allows default value specification, categorization of command-line 
options, in-line parsing of further spec file[s] and overrides of 
values in the the sequence you define, pretty much. It doesn't deal 
with the "logging level" item. I'm not sure what that would mean. The  
idea of the module is to create a namespace object (though it could 
as easily be a dict) that contains whatever values are specified.

in the program it would be invoked like this:
ctx = Cmdline( outfname='test.out', size=(250,400), ... ) (or 
whatever).

The command line can contain switches, prefixed by hyphens, spec file 
names, prefixed by @, untagged names, or key=value pairs. The values 
will be parsed as (tuples), [lists], or {dicts}, ints, floats, or 
strings. I did not, I am ashamed to say, resist the temptation to 
guess. 'Ctx' will contain the result of all this. Switches, if any 
are in a list named ctx._switches, unadorned arguments are in a list 
named ctx._vars, and the other stuff is pretty much as you would 
expect. It expects configuration files to be in a sort of ini-file 
format. 

Here's an example:

---
test.spec:
log=test.log
count=10
size=(400,200)
group1={key=value,a=alpha}
group2={b=beta,name=doogie howser}
#
temp=[1,2,5,11,22]
sub=(al,becky,carl,diane,edwin,fran)

---
test.py:
from Cmdline import Cmdline
c = Cmdline( count=5, log='pink.tank')
c.show()

---
>python test.py log=friend.txt @test.spec count=32 name=waldo

... yields:
 count  = 32
 sub  = ('al', 'becky', 'carl', 'diane', 'edwin', 
'fran')
 log  = 'test.log'
 temp  = [1, 2, 5, 11, 22]
 group1  = {'a': 'alpha', 'key': 'value'}
 group2  = {'b': 'beta', 'name': 'doogie howser'}
 size  = (400, 200)
 name  = 'waldo'

... while

>python @test.spec count=32 name=waldo temp=Vitalis sub='' dream -k
 count  = 32
 _vars  = ['dream']
 log  = 'test.log'
 temp  = 'Vitalis'
 _switches  = ['k']
 name  = 'waldo'
 group1  = {'a': 'alpha', 'key': 'value'}
 group2  = {'b': 'beta', 'name': 'doogie howser'}
 size  = (400, 200)
 sub  = ''

What the program does with the results is up to it, of course.

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

Re: How to catch a line with Popen

[Nobody]

On Sun, 29 May 2011 00:01:56 +0800, TheSaint wrote:

> I'm looking into subprocess.Popen docs. I've launch the program with its
> arguments and that's smooth. I'm expecting to read the output by
> *comunicate()* at every line that prgram may blow during the process, but
> the output is given only when the child process is ended.

.communicate() reads until EOF, .wait()s for the process to terminate,
then returns the output as a pair of strings.

If you want to read data while the process is running, use the process'
.stdout and/or .stderr members, e.g.:

p = subprocess.Popen(...)
for line in p.stdout:
...
p.wait()

Don't forget to .wait() on the process when you're done, regardless of
whether you actually need the exit code.

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

Re: Beginner needs advice

[Terry Reedy]

On 5/28/2011 2:57 PM, Uncle Ben wrote:


Just this past Tuesday, I blindly downloaded 3.1 and found that at the
level I am workloing, all it took to get my 2.7 code to run was to put
parens around the print arguments and double the slashes in integer
division. I didn't even use the 2to3 automation.


1//2 works in 2.7 and earlier.
from __future__ import division
gives 1/2 == 0.5 and in 3.x

print('abc') is the same as print 'abc'
The parens only make a difference with 2 or more items.

--
Terry Jan Reedy

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

Re: changing current dir and executing a shell script

[Albert Hopkins]

On Sat, 2011-05-28 at 09:41 +0200, Peter Otten wrote:
> > You don't want to do this because "cd" is a built-in shell command,
> and
> > subprocess does not execute within a shell (by default).
> 
> The problem is not that cd is built-in, but that there is no shell at
> all. 
> You can change that with shell=True: 

This is exactly what I said, but using different words.

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

Re: English Idiom in Unix: Directory Recursively

[Chris Angelico]

On Sun, May 29, 2011 at 7:25 AM, GSO  wrote:
> The beginning of wisdom is to call things by their right names. - Chinese
> Proverb (So I'm told at least, I'd check with the Chinese first though ;)

See, I thought it was "The fear of the Lord is the beginning of
wisdom", but the Chinese don't worship Yahweh, so I guess they
wouldn't say that. Proverbs chapter 9 verse 10, in any case. :)

Chris Angelico
yes, bit of a Bible geek as well as a programming geek
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: English Idiom in Unix: Directory Recursively

[GSO]

The beginning of wisdom is to call things by their right names. - Chinese
Proverb (So I'm told at least, I'd check with the Chinese first though ;)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: bdist_wininst: install_script not run on uninstall

[Wilbert Berendsen]

Op zaterdag 28 mei 2011 schreef Mark:

> This is a bug in distutils/bdist_wininst - I just created 
> http://bugs.python.org/issue12200 with the details and your samples, and 
> sadly I can't think of a work around you can use until this is fixed 
> (which I might get to soon, but not this weekend...)

Great that you found the cause of the bug!
I looked for hours in the install.c but I didn't find it :-)

Looking forward to a fix, which will make bdist_wininst much more usable!

thanks!
Wilbert Berendsen

-- 
http://www.wilbertberendsen.nl/
"You must be the change you wish to see in the world."
-- Mahatma Gandhi
-- 
http://mail.python.org/mailman/listinfo/python-list

Class decorators might also be super too

[Raymond Hettinger]

David Beazley wrote a class decorator blog post that is worth reading:
  http://dabeaz.blogspot.com/2011/05/class-decorators-might-also-be-super.html

Raymond

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

Re: English Idiom in Unix: Directory Recursively

[Chris Angelico]

On Sun, May 29, 2011 at 5:36 AM, Rikishi42  wrote:
> Is it [the term 'incinerate'] that widespread? I figured most people
> woul speak of burning. OK, my bad if it is.

I think it's geographic. This list covers a lot of geography; I'm in
Australia, there are quite a few Brits, and probably the bulk of posts
come from either the US or Europe. (And yes, I did deliberately fold
all of Europe down to one entity, and I did also deliberately leave
Great Britain out of that entity.)

> True, but I meant that they just use it as a name. I don't think many people
> would actually try to find out what a microwave is.

Most things work out that way. A thing gets a name based either on its
implementation or on the brand name of the first/most popular one. If
the only microwave oven ever produced had been made by Foobar Corp,
and that company were not known for anything else, then quite possibly
everyone would call them "foobar ovens".

>> Pedantic... that's another one of those academic words that need to be
>> explained to lay people, isn't it? As is academic itself, and in fact
>> "lay people". Who uses "lay people" in conversation?
>
> That (lay people) was atually a quote, from someone who actually used it in
> this thread.

"Lay person"/"lay people" is a fairly common expression, although
"laity" (which ought to mean the same thing) seems only to have
meaning in a church context (as in, the non-clergy).

Geeks tend to have larger vocabularies than non-geeks, on average;
probably akin to our love of word games and precision (two distinct
notions that bridge surprisingly often).

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

Re: Beginner needs advice

[Chris Angelico]

On Sun, May 29, 2011 at 5:21 AM, harrismh777  wrote:
> The problem is that they "look" similar.     :)

C looks like every other bracey language in the world. Is that a
problem? According to Wikipedia, there's quite a lot of them:

http://en.wikipedia.org/wiki/List_of_programming_languages_by_category#Curly-bracket_languages

I would say that the difference between the difference between Python
2 and Python 3 and the difference between C and Javascript (there,
parse THAT one without parentheses!) is that the latter have a
fundamentally different data philosophy. Both versions of Python are
the same language, because they "think" the same way; high level
objects that can be multiply-referenced, and are disposed of when no
longer needed. (That sounds like an implementation detail -
refcounting - but I don't really care how it does it under the hood,
as long as I can have multiple variables pointing to the same object,
and have objects not need explicit deallocation.) Little syntactic
differences like whether 'print' is a function or a statement, and
whether the simple slash operator between two ints returns a float,
and the fact that Unicode is the default string type, are
comparatively minor; on 'most every philosophical point, the two
dialects agree.

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

Re: English Idiom in Unix: Directory Recursively

[Rikishi42]

On 2011-05-25, Steven D'Aprano  wrote:
> I know many people who have no idea what a directory is, let alone a 
> subdirectory, unless it's the phone directory. They're non-computer 
> users. Once they start using computers, they quickly work out what the 
> word means in context, or they ask and get told, and then they've learned 
> a new word and never need ask again. This is a good thing.
>
> The idiom of "recursively delete" is no different. Of course some people 
> will have to learn a new term in order to make sense of it. So what?

OK, but the addition of recursive, is not really usefull, is it? Deleting
the directory says it, doesn't it?


>> Do you know many people who incinerate leaves and branches in their
>> garden? I burn them.
>
> I know many people who incinerate leaves in an incinerator. Or at least 
> they used to, until the government here banned it. It might only have 
> been a 44 gallon drum with holes punched in the side, but they still 
> called it an incinerator.
>
> I learned that word from my father, who left school at 14 to work in a 
> shoe shop. He isn't especially educated, doesn't read much beyond the 
> daily tabloid, and thinks Benny Hill is the height of wit. But he's not 
> an idiot and even at 72 is capable of learning new words.

Is it that widespread? I figured most people woul speak of burning.
OK, my bad if it is.


>>> Do they need to know the words "microwave oven" when they could be
>>> saying "invisible rays cooking thing"?
>> 
>> The word oven has existed for ages, microwave is just a name for the
>> type of oven. Not even a description, just a name.
>
> Why do you think they're called "microwave ovens" instead of "fizzbaz 
> ovens"? Could it possibly have something to do with the fact that they 
> cook with microwaves?
>
> So not actually "just a name" at all. It's a jargon description of the 
> implementation of the oven.

True, but I meant that they just use it as a name. I don't think many people
would actually try to find out what a microwave is.


>>> I wonder whether physicists insist that cars should have a "go faster
>>> pedal" because ordinary people don't need to understand Newton's Laws
>>> of Motion in order to drive cars?
>> 
>> Gas pedal. Pedal was allraedy known when the car was invented. The
>> simple addition of gas solved that need. 
>
> What's a gas pedal? Is that some strange American term for what most of 
> the English-speaking world knows as the accelerator? *wink*


Oh, come one. I'm sure I've heard that often enough NOT to have imagined it.


>> Oh, and it's break pedal, not descellarator. (sp?)
> That would be brake, and decelerator.

Sorry. But I actually have a excuse for those. (see below)  ;-)


>> I'm one of the 'people'. You say exposed to, I say bothered/bored with.
>
> You can't force people to learn new words, although you would be 
> surprised how even the most disinterested, lazy speaker manages to pick 
> up vocabulary without even being aware of it.

I know, I'm one.


> But nor do you have to pander to the slackers. They can learn the word, 
> or not, I don't care. If I'm writing for an audience of children, or 
> English as a second language, or the otherwise linguistically challenged, 

Third, actually. But I do try.  ;-)


> I'll simplify my vocabulary appropriately. For everyone else, I'll use an 
> ordinary adult vocabulary, and that includes the word "recursion" or 
> "recursive". It's hardly technical jargon -- I've found a discussion of 
> gangsta rap that uses it. Even children understand the concept of 
> recursion (self-reference). People put it in comedies like Blazing 
> Saddles and Space Balls! How difficult is it to put a name to the concept?
>
>
>> I have nothing against the use of a proper, precise term. And that word
>> can be a complex one with many, many sylables (seems to add value,
>> somehow).
>> 
>> But I'm not an academic, so I don't admire the pedantic use of terms
>> that need to be explained to 'lay' people.
>
> Pedantic... that's another one of those academic words that need to be 
> explained to lay people, isn't it? As is academic itself, and in fact 
> "lay people". Who uses "lay people" in conversation?

That (lay people) was atually a quote, from someone who actually used it in
this thread.


>> widespread, usually shorter and much simpler one for it. A pointless
>> effort if pointless, even when comming from a physicist.  :-)
>
> I think you *grossly* underestimate how many words people know, 
> particularly if you include so-called "passive vocabulary" (words people 
> can understand in context, but not define precisely). See, for example:
>
> http://www.worldwidewords.org/articles/howmany.htm

Got a point, there.



-- 
When in doubt, use brute force.
-- Ken Thompson
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Beginner needs advice

[harrismh777]

Ethan Furman wrote:

Um -- how can you have on the one hand "completely not compatible" and
on the other "code that can cross-execute on either version"?


Great question ! .. .it has to do with education.

... if you learn 2.x (only) and attempt to program on the 3.x platform, 
(without helps, education, migration tools, etc) you will fail... and 
you will be frustrated. Why? 3.x is not compatible with 2.x knowledge.


   If you learn 3.2 (only) and attempt to program on 2.x you will fail, 
and you will be frustrated. Why?   Because the two languages are 
different and incompatible.


Now then, can you learn both?...  sure.Can you migrate one to the 
other with enough knowledge and effort?... yup.   Is it possible (with 
enough cleverness) to write code that will run on "both" without 
modification... yes...   Are the two languages compatible?No!



Where this really counts of course is real-world apps. It is relatively 
easy to write trivial code blocks that demonstrate that nothing has 
changed in 3.x/   ... and they are *all* misleading.  The truth is that 
hundreds of details have changed making the two 'versions' actually 
different languages.



If I use the '89 version (1) K&R to write a C program,  and compile it 
on the current gcc without mods it will run.  If I use the 2.5 python 
manual to write a python program and try to run it on 3.2 it will fail 
(for many, many reasons).  This is my definition of completely 
incompatible. The two languages are different; period.


The problem is that they "look" similar. :)



kind regards,
m harris




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

Re: Beginner needs advice

[Uncle Ben]

On May 27, 5:33 pm, Ethan Furman  wrote:
> Lew Schwartz wrote:
> > So, if I read between the lines correctly, you recommend Python 3? Does
> > the windows version install with a development environment?
>
> Dabo, last I checked, uses wxPython, which uses wxWidgets (sp?), which
> is not yet ported to Python 3.  So if you got that route you'll need to
> stay with 2.7.
>
> ~Ethan~

Just this past Tuesday, I blindly downloaded 3.1 and found that at the
level I am workloing, all it took to get my 2.7 code to run was to put
parens around the print arguments and double the slashes in integer
division. I didn't even use the 2to3 automation.

But I am a noob to Python, which is my tenth computer language.  Maybe
when I get more ambitious I will find more serious differences.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GIL in alternative implementations

[Steven D'Aprano]

On Sat, 28 May 2011 09:39:08 -0700, John Nagle wrote:

> Python allows patching code while the code is executing.

Can you give an example of what you mean by this?

If I have a function:


def f(a, b):
c = a + b
d = c*3
return "hello world"*d


how would I patch this function while it is executing?


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

Re: GIL in alternative implementations

[John Nagle]

On 5/27/2011 7:06 PM, Daniel Kluev wrote:

So I'd like to know: how do these other implementations handle concurrency
matters for their primitive types, and prevent them from getting corrupted
in multithreaded programs (if they do) ? I'm not only thinking about python
types, but also primitive containers and types used in .Net and Java VMs,
which aren't atomic elements either at an assembly-level point of view.


  "+=" is not guaranteed to be atomic in most languages.  Some
C and C++ implementations have "atomic_inc", etc., which is guaranteed
to execute as an atomic operation.

  How do most safe languages handle concurrency? For the unboxed 
primitive types, like numbers, the hardware handles it. For

memory allocation, there's a lock.  Most don't allow patching code
on the fly.  Concurrent garbage collection prevents deleting
something if there's a pointer to it anywhere.  This was all worked
out for LISP and SELF decades ago.

  Python allows patching code while the code is executing.  This
implies a sizable performance penalty, and causes incredible
complexity in PyPy.

John Nagle


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

How to catch a line with Popen

[TheSaint]

Hello.
I'm looking into subprocess.Popen docs.
I've launch the program with its arguments and that's smooth. I'm expecting 
to read the output by *comunicate()* at every line that prgram may blow 
during the process, but the output is given only when the child process is 
ended.
I'd like to process the lines to display an information in percentage during 
the running time of the child. Sorry but I'm poor of know-how, so I'm stuck 
over to find a clue.

-- 
goto /dev/null
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The worth of comments

[Irmen de Jong]

On 28-5-2011 15:36, Roy Smith wrote:
> In article ,
>  Grant Edwards  wrote:
> 
>> When trying to find a bug in code written by sombody else, I often
>> first go through and delete all of the comments so as not to be
>> mislead.
> 
> I've heard people say that before.  While I get the concept, I don't 
> like doing things that way myself.
> 
>>> The comments reflect what the author _thought_ the code did
>> _at_some_point_in_the_past_.  What matters is what the code actually
>> does at the present.
> 
> I don't look at it that way.  Most of the comments I write are to 
> document interfaces, i.e. what the code is supposed to do.  That's the 
> contract between you and the code.  If you call me with arguments that 
> meet these conditions, this is what I promise I'll return to you (and 
> what side effects I'll perform).

I don't see how that is opposed to what Grant was saying. It's that these 
'contracts'
tend to change and that people forget or are too lazy to update the comments to 
reflect
those changes.

The comments you are writing, saying what the code is supposed to do, are only 
saying
what the code is supposed to do at the moment in time that you were writing the 
comment
and/or the code, are they not?

> One reasonable definition of a bug is something the code actually does 
> which differs from the documented interface.  Unless you know what the 
> code is supposed to do, how can you possibly look at it and say whether 
> it has a bug or not?  For example, take this function:
> 
> def foo():
>l = [1, 2, 3]
>return l[3]
> 
> Is this code correct?

Unit tests should tell you.


>  I'll bet most people would look at this and say, 
> "I'm not sure what he had in mind, but whatever it was, this has to be a 
> bug because he's indexing past the end of the list".

I do agree that reading just that piece of code without other information, 
makes me
think that it is fishy. But:


>  Well, what if I 
> showed you the interface contract:
> 
> def foo():
>"Raise IndexError.  This is useful as a testing fixture."
>l = [1, 2, 3]
>return l[3]
> 
> Now it's obvious that the function does exactly what it's supposed to do 
> (even if it's not the best way to do it).

A month later the requirement changes: it should raise a ZeroDevisionError 
instead.
Someone modifies the code but leaves the comment (for whatever reason).

def foo():
"Raise IndexError.  This is useful as a testing fixture."
return 1//0

Unless there is a way to force people to update the code comment as well (which 
I'm not
aware of.. Doctests? dunno...),  you now have a comment that lies about the the 
intended
working.   In my opinion that is worse than what we had before (the function 
without
comment).


That being said, I do write code comments myself. Some of them are like notes, 
directed
to future-me or other future readers (remember that we do this because blabla, 
don't
change this to such-and-such because it will probably break xyz) and some of 
them are
stating the contract of the code (like you wrote above, about documenting 
interfaces).
I always try to avoid writing comments that duplicate the working of the code 
itself in
pseudo code or text phrases.  But humans make mistakes and forget things so 
after enough
modifications my code probably contains lies as well... :(


Irmen de Jong

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

Re: and becomes or and or becomes and

[Chris Angelico]

On Sat, May 28, 2011 at 11:31 PM, Nobody  wrote:
> Not Python, but:
>
>        #define SIX  1 + 5
>        #define NINE 8 + 1
>        ...
>        printf("six times nine is: %d\n", SIX * NINE);

*AWESOME*!! That is brilliant!

DNA FTW.

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

Re: The worth of comments

[Chris Angelico]

On Sat, May 28, 2011 at 11:36 PM, Roy Smith  wrote:
> def foo():
>   "Raise IndexError.  This is useful as a testing fixture."
>   l = [1, 2, 3]
>   return l[3]

A quite useful thing, on occasion. I have a couple of variants of
this, actually. In one of my C++ programs:

extern char *death1; extern int death2; //Globals for killing things with

// further down, inside a function:
case "death1": *death1=42; break; //Die by dereferencing NULL
case "death2": return 42/death2; //Die by dividing by zero

They were designed to verify the parent-process code that was meant to
catch process termination and identify the cause, so I wanted two
quite different ways of blowing up the program. (The variables were
extern and defined in another file to ensure that the compiler
couldn't outsmart me with a compilation error.)

In the Python code, that would be unnecessary with the *list* type,
but it might be of value with your own class (eg subclass of list).
Although, I'd put that sort of thing into a dedicated unit testing
section, where everyone _knows_ that you're trying to break stuff.

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

PyCon Australia 2011: Early Bird Closing Soon

[Ryan Kelly]

Hi Everyone,


A reminder that Early Bird Registrations for PyCon Australia 2011 will
be closing soon.  There are only a few days left to get your tickets at
the discounted rate.

PyCon Australia is Australia's only conference dedicated exclusively to
the Python programming language, and will be held at the Sydney Masonic
Center over the weekend of August 20 and 21. See below for more
information and updates on:
 
 1. Early-Bird Registration Closing Soon
 2. Presentations Selected
 3. More Sponsors Announced
 
Please pass this message on to those you feel may be interested.

 

Early-Bird Registration Closing Soon


Early-bird registration closes at the end of May, so you've only got
a few days left to get your tickets at the special discounted rate.

We offer three levels of registration for PyCon Australia 2011.
Registration provides access to two full days of technical content
presented by Python enthusiasts from around the country, as well as the
new classroom track and a seat at the conference dinner.
  
  Full (Early Bird) - $165
This is the registration rate for regular attendees. We are offering
a limited Early Bird rate for the first 50 registrations until the
end of May.

Once the early-bird period ends, Full Registration will be $198.

  Corporate - $440
If your company is paying for you to attend PyCon, please register
at the corporate rate. You'll be helping to keep the conference
affordable for all.

  Student - $44
For students able to present a valid student card we're offering
this reduced rate, which does not include the conference dinner.

All prices include GST.  For more information or to register, please
visit the conference website.

Register here: http://pycon-au.org/reg



Presentations Selected
==

We have had a fantastic response to our Call For Proposals this year.
While the detailed talk schedule is still being finalised, we are
pleased to announce that the following presentations have been selected
for the conference:

  Standard Talks:

A Python on the Couch  (Mark Rees)
Behaviour Driven Development  (Malcolm Tredinnick)
Benchmarking stuff made ridiculously easy  (Tennessee Leeuwenburg)
Bytecode: What, Why, and How to Hack it  (Ryan Kelly)
Developing Scientific Software in Python  (Duncan Gray)
Fun with App Engine 1.5.0  (Greg Darke)
Hosting Python Web Applications  (Graham Dumpleton)
How Python Evolves (and How You Can Help Make It Happen)  (Nick Coghlan)
Infinite 8-bit Platformer  (Chris McCormick)
Networking Libraries in Python.  (Senthil Kumaran)
Pants - Network Programming Made Easy  (Evan Davis)
Say What You Mean: Meta-Programming a Declarative API  (Ryan Kelly)
State of CPython and Python Ecosystem  (Senthil Kumaran)
Sysadmins vs Developers, a take from the other side of the fence  (Benjamin 
Smith)
Teaching Python to the young and impressionable  (Katie Bell)
The NCSS Challenge: teaching programming via automated testing  (Tim 
Dawborn)
Weather field warping using Python.  (Nathan Faggian)
Zookeepr: Home-grown conference management software  (Brianna Laugher)

  In-Depth Talks:

Ah! I see you have the machine that goes "BING"!  (Graeme Cross)
Easy site migration using Diazo and Funnelweb  (Adam Terrey)
How to maintain big app stacks without losing your mind  (Dylan Jay)
Introduction to the Geospatial Web with GeoDjango  (Javier Candeira)
Panel: Python 3  (Richard Jones)
Panel: Python in the webs  (Richard Jones)
Pyramid: Lighter, faster, better web apps  (Dylan Jay)
Web micro-framework battle  (Richard Jones)

  Classroom Track:

Meta-matters: using decorators for better Python programming  (Graeme Cross)
Python 101+  (Peter Lovett)
Python's dark corners - the bad bits in Python and how to avoid them  
(Peter Lovett)
Python for Science and Engineering, Part 1  (Edward Schofield)
Python for Science and Engineering, Part 2  (Edward Schofield)
The Zen of Python  (Richard Jones)


Thanks again to everyone who submitted a proposal.


 
More Sponsors Announced
===

We are delighted to announce that WingWare and Superior Recruitment have
joined as Silver Sponsors.  Thank you to the following companies for
their continuing support of Python and for helping to make PyCon
Australia 2011 a reality:

Gold:  Google  
Gold:  ComOps  
 
Silver:  Anchor
Silver:  Enthought 
Silver:  Python Software Foundation
Silver:  WingWare  
Silver:  Superior Recruitment  
 

Thanks also to Linux Australia

join this group

[YUVI RAJ]

 http://123maza.com/65/Cape201/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The worth of comments

[Roy Smith]

In article ,
 Grant Edwards  wrote:

> When trying to find a bug in code written by sombody else, I often
> first go through and delete all of the comments so as not to be
> mislead.

I've heard people say that before.  While I get the concept, I don't 
like doing things that way myself.

>> The comments reflect what the author _thought_ the code did
> _at_some_point_in_the_past_.  What matters is what the code actually
> does at the present.

I don't look at it that way.  Most of the comments I write are to 
document interfaces, i.e. what the code is supposed to do.  That's the 
contract between you and the code.  If you call me with arguments that 
meet these conditions, this is what I promise I'll return to you (and 
what side effects I'll perform).

One reasonable definition of a bug is something the code actually does 
which differs from the documented interface.  Unless you know what the 
code is supposed to do, how can you possibly look at it and say whether 
it has a bug or not?  For example, take this function:

def foo():
   l = [1, 2, 3]
   return l[3]

Is this code correct?  I'll bet most people would look at this and say, 
"I'm not sure what he had in mind, but whatever it was, this has to be a 
bug because he's indexing past the end of the list".  Well, what if I 
showed you the interface contract:

def foo():
   "Raise IndexError.  This is useful as a testing fixture."
   l = [1, 2, 3]
   return l[3]

Now it's obvious that the function does exactly what it's supposed to do 
(even if it's not the best way to do it).
-- 
http://mail.python.org/mailman/listinfo/python-list

join this group

[YUVI RAJ]

 http://123maza.com/65/Cape201/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: and becomes or and or becomes and

[Nobody]

On Sun, 22 May 2011 15:39:33 -0700, Tim Roberts wrote:

> That IS funny.  Interesting how a careful choice of arugments will fool us.
> One of my favorite math jokes is like that.  A teacher asked a student to
> reduce the following fraction: 
>   16
>  
>   64
> 
> He says "all I have to do is cancel out the sixes, so the answer is 1/4".

Not Python, but:

#define SIX  1 + 5
#define NINE 8 + 1
...
printf("six times nine is: %d\n", SIX * NINE);

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

Re: The worth of comments

[python]

Irmen,

> I'm going to share this thread, and the funny slideshow about Uncomment your 
> code, with my team at work :-) We're not a Python shop so I'm probably the 
> only one reading this

Same here!

> but as usual there is a lot of wisdom going on in this new[s]group that is 
> not only applicable to Python.

+1 QOTW

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

Re: The worth of comments

[Irmen de Jong]

On 27-5-2011 19:53, Grant Edwards wrote:
> On 2011-05-27, Irmen de Jong  wrote:
>> On 27-05-11 15:54, Grant Edwards wrote:
>>> On 2011-05-27, Ben Finney  wrote:
 Richard Parker  writes:

> On May 26, 2011, at 4:28 AM, python-list-requ...@python.org wrote:
>
>> My experience is that comments in Python are of relatively low
>> usefulness. (For avoidance of doubt: not *zero* usefulness, merely
>> low.)
>>>
>>> I've seen plenty of comments who's usefulness was not zero.  It was
>>> less than zero.
>>
>> Someone once taught me, "There is one thing worse than having no 
>> comments in the source code: having incorrect (or 'lying') comments
>> in the code."
>>
>> Grant, I guess you hint at such comments?
> 
> Yes.  :)
> 
> When trying to find a bug in code written by sombody else, I often
> first go through and delete all of the comments so as not to be
> mislead.
> 
> The comments reflect what the author _thought_ the code did
> _at_some_point_in_the_past_.  What matters is what the code actually
> does at the present.
> 

I'm going to share this thread, and the funny slideshow about Uncomment your 
code, with
my team at work :-)
We're not a Python shop so I'm probably the only one reading this, but as usual 
there is
a lot of wisdom going on in this newgroup that is not only applicable to Python.

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

Re: and becomes or and or becomes and

[Chris Angelico]

On Sat, May 28, 2011 at 10:27 PM, bch  wrote:
> And of course, a programmer cannot tell the difference between
> Halloween and Christmas day.

Well known, of course. But a lot of modern programmers don't speak
octal, they only use another power-of-two base; it's as though
someone's cast a hex on them.

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

Re: Why did Quora choose Python for its development?

[Roy Smith]

In article 
,
 Carl Banks  wrote:

> On Friday, May 27, 2011 6:47:21 AM UTC-7, Roy Smith wrote:

> > One of the truly awesome things about the Python re library is that it 
> > lets you write complex regexes like this:
> > 
> > pattern = r"""\b # beginning of line
> >   (?P\w+)  # a word
> >   \s+# some whitespace
> >   (?P=word)(?!\w)# the same word again
> >"""
> 
> Perl has the X flag as well, in fact I'm pretty sure Perl originated it.  
> Just saying.

Heh.  Didn't know that.  I wish people would use it more.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Beginner needs advice

[D'Arcy J.M. Cain]

On Sat, 28 May 2011 07:06:53 +0200
Thomas Rachel

wrote:
> > "Completely incompatible"? A "lie"?
> 
> Hard word, but it is true. Many things can and will fall on your feet 
> when moving.
> 
> There are very many subtle differences.

The space between "Completely incompatible" and "many subtle
differences" is about the size of the Grand Canyon.

-- 
D'Arcy J.M. Cain  |  Democracy is three wolves
http://www.druid.net/darcy/|  and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP)   |  what's for dinner.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: and becomes or and or becomes and

[bch]

On May 23, 11:30 pm, rusi  wrote:
> On May 23, 5:30 am, Steven D'Aprano 
>
>
> +comp.lang.pyt...@pearwood.info> wrote:
> > On Sun, 22 May 2011 15:39:33 -0700, Tim Roberts wrote:
> > > Stef Mientki  wrote:
>
> > >>must of us will not use single bits these days, but at first sight, this
> > >>looks funny :
>
> > > a=2
> > > b=6
> > > a and b
> > >>6
> > > a & b
> > >>2
> > > a or b
> > >>2
> > > a | b
> > >>6
>
> > > That IS funny.  Interesting how a careful choice of arugments will fool
> > > us. One of my favorite math jokes is like that.  A teacher asked a
> > > student to reduce the following fraction:
> > >   16
> > >  
> > >   64
>
> > > He says "all I have to do is cancel out the sixes, so the answer is
> > > 1/4".
>
> > One of my favourite variations on this is by Abbott and Costello, where
> > Costello proves that 13*7 = 28 in three different ways.
>
> >http://www.youtube.com/watch?v=rLprXHbn19I
>
> Ha Ha! [You're hired Steven]

And of course, a programmer cannot tell the difference between
Halloween and Christmas day.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Question about isodate

[Colin J. Williams]

On 26-May-11 07:48 AM, truongxuan quang wrote:

Hello list,

I am installing and testing istSOS wrote base on Python with its
extension like gdal, isodate, easy istall, setuptool, psycopg. I have
already installed all these stuff when I was using method POST the error
appear is "_No module named mx.DateTime.ISO_" , could you please give me
your command and advice.

Many thanks

Quang

Does this help? 
http://www.google.com/url?sa=t&source=web&cd=1&ved=0CB0QFjAA&url=http%3A%2F%2Fwww.egenix.com%2Fproducts%2Fpython%2FmxBase%2FmxDateTime%2F&rct=j&q=mxdatetime&ei=eengTYf5MM6EtgfdzeSoBw&usg=AFQjCNEsnznUS1kZ_zAzbSxGlP2IF6BsTg&sig2=3GgXQ9caWtvHTwzZoJOBuQ&cad=rja


Colin W.

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

Re: GIL in alternative implementations

[Wolfgang Rohdewald]

On Samstag 28 Mai 2011, Marc Christiansen wrote:
> And I wouldn't rely on 3.2
> not to break.

it breaks too like it should, but only rarely
like one out of 10 times

i5:/pub/src/gitgames/kajongg/src$ python3.2 test.py 
100
i5:/pub/src/gitgames/kajongg/src$ python3.2 test.py 
100
i5:/pub/src/gitgames/kajongg/src$ python3.2 test.py 
98
i5:/pub/src/gitgames/kajongg/src$ python3.2 test.py 
100


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

Re: GIL in alternative implementations

[Peter Otten]

Daniel Kluev wrote:

>> So I'd like to know: how do these other implementations handle
>> concurrency matters for their primitive types, and prevent them from
>> getting corrupted in multithreaded programs (if they do) ? I'm not only
>> thinking about python types, but also primitive containers and types used
>> in .Net and Java VMs, which aren't atomic elements either at an
>> assembly-level point of view.
> 
> Well, they definitely have some shortcomings:
> 
> test.py:
> 
> from threading import Thread
> class X(object):
> pass
> obj = X()
> obj.x = 0
> 
> def f(*args):
>for i in range(1):
>obj.x += 1
> 
> threads = []
> for i in range(100):
> t = Thread(target=f)
> threads.append(t)
> t.start()
> 
> for t in threads:
> while t.isAlive():
> t.join(1)
> 
> print(obj.x)
> 
>> python test.py
> 100
>> pypy test.py
> 100
>> jython-2.5 test.py
> 19217
>> ipy test.py
> 59040
> 
> Not that this thing is reasonable to do in real code, but cpython and
> other implementations with GIL at least give you some safety margin.

The problem with your code is that it gives the wrong result when a thread 
reads obj.x, then suspends, then another thread reads obj.x and finally both 
threads store the same value+1 back. That problem has nothing to do with the 
GIL which just prohibits that two threads can run at the same time, on 
different cores. 

It occurs because obj.x += 1 is not an atomic operation. That lack of 
atomicity should be obvious if you take a look at the byte-code:

>>> def f():
... obj.x += 1
...
>>> dis.dis(f)
  2   0 LOAD_GLOBAL  0 (obj)
  3 DUP_TOP
  4 LOAD_ATTR1 (x)
  7 LOAD_CONST   1 (1)
 10 INPLACE_ADD
 11 ROT_TWO
 12 STORE_ATTR   1 (x)
 15 LOAD_CONST   0 (None)
 18 RETURN_VALUE

[Marc Christiansen]
> So even CPython (at least < 3.2) isn't safe. And I wouldn't rely on 3.2
> not to break.

I don't know why it /seems/ to work in 3.2 more often than in 2.x, but in 
general bugs that occur only sporadically are typical for multithreaded 
code...

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

Re: GIL in alternative implementations

[Marc Christiansen]

Daniel Kluev  wrote:
> test.py:
> 
> from threading import Thread
> class X(object):
>pass
> obj = X()
> obj.x = 0
> 
> def f(*args):
>   for i in range(1):
>   obj.x += 1
> 
> threads = []
> for i in range(100):
>t = Thread(target=f)
>threads.append(t)
>t.start()
> 
> for t in threads:
>while t.isAlive():
>t.join(1)
> 
> print(obj.x)
> 
>> python test.py
> 100
>> pypy test.py
> 100
>> jython-2.5 test.py
> 19217
>> ipy test.py
> 59040
> 
> Not that this thing is reasonable to do in real code, but cpython and
> other implementations with GIL at least give you some safety margin.
> 
Sure? ;)
 > for p in python2.4 python2.5 python2.6 python2.7 python3.1 python3.2; do 
 > echo $p; $p /tmp/test.py; $p /tmp/test.py; done
 python2.4
 525369
 736202
 python2.5
 449496
 551023
 python2.6
 903405
 937335
 python2.7
 885834
 910144
 python3.1
 866557
 766842
 python3.2
 100
 100

So even CPython (at least < 3.2) isn't safe. And I wouldn't rely on 3.2
not to break.

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

Re: The worth of comments

[Gregory Ewing]

Grant Edwards wrote:


After hearing/reading somebody for years, I don't seem to have a
detailed image of them in my head, but when I finally do see a picture
of them, my initial reaction is almost always "no, that's not at all
what I thought he/she looked like".


It works the other way, too. I've known what Terry Pratchett looks
like for many years from the pictures on his books. When I heard
him on the radio for the first time recently, I thought, "Wait
a minute, that's not what his voice is supposed to sound like!"

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

Re: Beginner needs advice

[Steven D'Aprano]

On Sat, 28 May 2011 08:38:54 +0200, Thorsten Kampe wrote:

> * Thomas Rachel (Sat, 28 May 2011 07:06:53 +0200)
>> Am 27.05.2011 17:52 schrieb Steven D'Aprano:
>> > On Fri, 27 May 2011 09:40:53 -0500, harrismh777 wrote:
>> >> 3.x is completely incompatible with 2.x (some call it a dialect, but
>> >> that is a lie).
>> >
>> > "Completely incompatible"? A "lie"?
>> 
>> Hard word, but it is true. Many things can and will fall on your feet
>> when moving.
> 
> I think we should stop talking about (in)compatability because everyone
> seems to associate something different with that term (incompatible =
> "no Python2 to code will run with Python3", "not all Python2 code will
> run with Python3").

There is a difference between "completely incompatible" and merely 
"incompatible to some degree". It just takes *one* tiny incompatibility 
to stop a program running, so "will it run unmodified?" is hardly a good 
measure of the degree of incompatibility.

Python 2.5 and 2.6 are incompatible to some degree. I recently had to 
port a client's program from 2.3 to 2.6. I did it in two steps: about two 
hours to get it working in 2.5, then the same to get it working in 2.6, 
and then about a day of effort to iron out all the display issues in 
Tkinter (such as text being shown in giant letters).

Judging by the binary Yes/No "does it run unmodified?" test, I'd have to 
say that Python 2.3, 2.5 and 2.6 are "completely different" -- which 
would be foolish. Nobody sensible applies such a simple-minded, overly 
strict test to minor releases, or even between major releases like 1.5 
versus 2.0. What would be the point? It is not the least bit helpful to 
learn that your 2.3 code doesn't run unmodified in 2.6. (Learning that it 
does, on the other hand, is useful. But such code is in a minority.)

And yet some people are willing to throw commonsense away and apply such 
an obviously unsuitable test to Python 3. These people vehemently insist 
that the differences between Python 2.7 and 3.2 are of the same 
qualitative kind as between Ruby and PHP (they're *different languages* 
you see, not merely different dialects of the same language, and anyone 
who tells you different is not just mistaken but *lying*).



> The question is: if you want (or have) to run your code under Python3,
> how likely is that it will run unmodified? 

That's not a useful question. The useful question is to ask how much 
effort is it to make the code run in the new version. The effort might be 
zero (but probably isn't), or it might be a minute, or an hour, or a day, 
or six months... that depends partly on the complexity of your code and 
partly on the differences between Python 2.x and 3.x.

A trivial app might take three minutes to port from Python 2.5 to 3.2. A 
complicated app might take three months to port from 2.5 to 2.6. What 
generalization do we make from this?


> My experience is: unless the
> code is especially written with Python3 compatability or just a short
> snippet, it's actually quite unlikely that it will run.

You describe taking a full day to upgrade a 150 line PyQt application. 
Only it wasn't a 150 line application, was it? By your own admission, 
much of the problems were in the library, PyQt, so it was more like 
150,000 lines. (Or whatever the size of PyQt is...)

Rather than "it took a full day to upgrade 150 lines to use Python 3, 
that's terrible!", it is more like "it only took a day to upgrade my 150 
line app *and* work around a whole lot of problems with a huge library, 
that's really great!"



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

Re: changing current dir and executing a shell script

[Peter Otten]

Albert Hopkins wrote:

> On Fri, 2011-05-27 at 14:25 -0700, suresh wrote:

>> I want to execute the following command line stuff from inside python.
>> $cd directory
>> $./executable
>> 
>> I tried the following but I get errors
>> import subprocess
>> subprocess.check_call('cd dir_name;./executable')
>> 
>> Due to filename path issues, I cannot try this version.
>> subprocess.check_call('./dir_name/executable')

> You don't want to do this because "cd" is a built-in shell command, and
> subprocess does not execute within a shell (by default).

The problem is not that cd is built-in, but that there is no shell at all. 
You can change that with shell=True:

>>> subprocess.check_call("cd /usr/share; pwd; cd /usr/lib; pwd", 
shell=True)
/usr/share
/usr/lib
 
But I agree with you that 

> The proper way to do this is to use the "cwd" keyword argument to
> subprocess calls, i.e.:
> 
 subprocess.check_call(('/path/to/exec',), cwd="/path/to/dir")

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