Re: Idiom for shelling out to $EDITOR/$PAGER?

[Peter Otten]

Tim Chase wrote:

> After a little searching, I've not been able to come up with what
> I'd consider canonical examples of consider calling an external
> editor/pager on a file and reading the results back in.  (most of
> my results are swamped by people asking about editors written in
> Python, or what the best editors for Python code are)
> 
> The pseudocode would be something like
> 
>def edit_text(data):
>  temp_fname = generate_temp_name()
>  try:
>f = file(temp_fname, 'w')
>f.write(data)
>f.close()
>before = info(temp_fname) # maybe stat+checksum?
>editor = find_sensible_editor()
>subprocess.call([editor, temp_fname])
>if before == info(temp_fname):
>  return None
>else:
>  return file(temp_fname).read()
>  finally:
>delete_if_exists(temp_fname)
> 
> However there are things to watch out for in this lousy code:
> 
> -race conditions, unique naming, and permissions on the temp file
> 
> -proper & efficient detection of file-change, to know whether the
> user actually did anything

Just read the whole thing back into memory and compare the string to the 
original data. The file has to be quite long for the checksum calculation to 
be worthwhile.

> -cross-platform determination of a sensible editor (that blocks
> rather than spawns), using platform conventions like
> os.environ['EDITOR']
> 
> -cleanup deletion of the temp-file
> 
> I presume the code for spawning $PAGER on some content would look
> pretty similar.
> 
> Any good example code (or blog posts, or other links) that has
> been battle-tested?

You could look into mercurial to see what it does to let you edit its commit 
messages. A quick look into mercurial/ui.py 
(http://selenic.com/hg/file/9cf1620e1e75/mercurial/ui.py, start with the 
ui.edit() method) suggests that it uses the same approach as your 
pseudocode.


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

Re: what does 'a=b=c=[]' do

[rusi]

On Dec 23, 7:10 am, alex23  wrote:
> On Dec 22, 6:51 pm, Rolf Camps  wrote:
>
> > I'm afraid it's dangerous to encourage the use of '[]' as assignment to
> > a parameter in a function definition. If you use the function several
> > times 'default' always points to the same list.
>
> I appreciate the concern, but adding a default argument guard would
> not only obscure the code. It's irrelevant, as you recognise, because
> no matter what, it's going to make copies of the default argument.
>
> You know what the say about foolish consistencies :)

Programming languages can have bugs as much as programs can.
A classic example is the precedence table of C which Kernighan or
Ritchie (dont remember which) admitted was wrong.

Likewise function arguments that default to mutable entities is a
known gotcha of python which is best treated as a bug in python. It
should be avoided with the suitable additional circumspection that a
language bug deserves over a program bug.

[Just my rephrasing of what Ian is saying]
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: IPC with multiprocessing.connection

[Andrew Berg]

On 12/23/2011 2:32 AM, Deepak Babu wrote:

See if http://www.rsdcbabu.com/2011/02/multiprocessing-with-python.htmlhelps
you.
It doesn't. There is not even a mention of the connection submodule 
(plus it's Python 2, and I'm familiar enough with Python 2 to do a good 
job of porting to py3k). I don't even want to spawn new processes with 
the multiprocessing module; I want processes which may not even be 
written in Python to communicate over a named pipe or Unix domain socket.


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

Re: what does 'a=b=c=[]' do

[Ethan Furman]

Ian Kelly wrote:

On Thu, Dec 22, 2011 at 7:10 PM, alex23  wrote:

On Dec 22, 6:51 pm, Rolf Camps  wrote:

I'm afraid it's dangerous to encourage the use of '[]' as assignment to
a parameter in a function definition. If you use the function several
times 'default' always points to the same list.

>>

I appreciate the concern, but adding a default argument guard would
not only obscure the code. It's irrelevant, as you recognise, because
no matter what, it's going to make copies of the default argument.


It's only irrelevant in the immediate context of the code you posted.
But when Joe Novice sees your code and likes it and duplicates it a
million times without receiving any warning about it, he's eventually
going to write a function that modifies its default list argument, and
he'll be in for a nasty surprise when he does.


And then he will learn about it and not make the mistake again (or if he 
does, it take much less time to figure it out).


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

Re: what does 'a=b=c=[]' do

[Steven D'Aprano]

On Fri, 23 Dec 2011 00:38:07 -0800, rusi wrote:

> Likewise function arguments that default to mutable entities is a known
> gotcha of python which is best treated as a bug in python.

Nonsense. It is a feature, not a bug.

Some people might argue that it is a mistake, a minor feature which 
allegedly causes more difficulties than benefits. I do not hold with that 
idea. But either way, it is not a bug to be fixed, but a deliberate 
consequence of intended semantics.



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

Re: Idiom for shelling out to $EDITOR/$PAGER?

[Steven D'Aprano]

On Fri, 23 Dec 2011 09:28:52 +0100, Peter Otten wrote:

>> -proper & efficient detection of file-change, to know whether the user
>> actually did anything
> 
> Just read the whole thing back into memory and compare the string to the
> original data. The file has to be quite long for the checksum
> calculation to be worthwhile.

I don't think so. No matter how long the file is, the checksum is always 
going to do far more work than a simple string comparison. A string 
comparison can short-circuit on the first difference; the checksum must 
always process both files in their entirety.


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

Re: Idiom for shelling out to $EDITOR/$PAGER?

[Steven D'Aprano]

On Fri, 23 Dec 2011 09:44:31 +, Steven D'Aprano wrote:

> On Fri, 23 Dec 2011 09:28:52 +0100, Peter Otten wrote:
> 
>>> -proper & efficient detection of file-change, to know whether the user
>>> actually did anything
>> 
>> Just read the whole thing back into memory and compare the string to
>> the original data. The file has to be quite long for the checksum
>> calculation to be worthwhile.
> 
> I don't think so. No matter how long the file is, the checksum is always
> going to do far more work than a simple string comparison. A string
> comparison can short-circuit on the first difference; the checksum must
> always process both files in their entirety.

Wait... the above only holds assuming you keep both the before-editing 
and after-editing versions. If you don't, then Peter is right, there 
comes a point where keeping a checksum saves enough memory for the 
additional effort to be worth while.

Sorry for the noise.


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

Re: what does 'a=b=c=[]' do

[Ethan Furman]

rusi wrote:

On Dec 23, 7:10 am, alex23  wrote:

On Dec 22, 6:51 pm, Rolf Camps  wrote:


I'm afraid it's dangerous to encourage the use of '[]' as assignment to
a parameter in a function definition. If you use the function several
times 'default' always points to the same list.

>>

I appreciate the concern, but adding a default argument guard would
not only obscure the code. It's irrelevant, as you recognise, because
no matter what, it's going to make copies of the default argument.

You know what the say about foolish consistencies :)


Programming languages can have bugs as much as programs can.
A classic example is the precedence table of C which Kernighan or
Ritchie (dont remember which) admitted was wrong.

Likewise function arguments that default to mutable entities is a
known gotcha of python which is best treated as a bug in python. It
should be avoided with the suitable additional circumspection that a
language bug deserves over a program bug.


That is the most ridiculous thing I have heard in a while.  Mutable 
default arguments are *not* a bug in Python.


Reminds me of a bug report a couple years back claiming multiple 
inheritence was a bug and asking it to be removed.


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

Re: what does 'a=b=c=[]' do

[Chris Angelico]

On Fri, Dec 23, 2011 at 7:49 PM, Ethan Furman  wrote:
> That is the most ridiculous thing I have heard in a while.  Mutable default
> arguments are *not* a bug in Python.
>
> Reminds me of a bug report a couple years back claiming multiple inheritence
> was a bug and asking it to be removed.

Both of these could arguably be called misfeaures, but not bugs.

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

Re: Idiom for shelling out to $EDITOR/$PAGER?

[Steven D'Aprano]

On Thu, 22 Dec 2011 22:16:30 -0600, Tim Chase wrote:

> I presume the code for spawning $PAGER on some content would look pretty
> similar.

Have a look at pydoc in the standard library, which implements pager-like 
functionality.


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

Re: what does 'a=b=c=[]' do

[rusi]

On Dec 23, 2:59 pm, Chris Angelico  wrote:
> On Fri, Dec 23, 2011 at 7:49 PM, Ethan Furman  wrote:
> > That is the most ridiculous thing I have heard in a while.  Mutable default
> > arguments are *not* a bug in Python.
>
> > Reminds me of a bug report a couple years back claiming multiple inheritence
> > was a bug and asking it to be removed.
>
> Both of these could arguably be called misfeatures, but not bugs.
>
> ChrisA

In Fortran, if the comma in the loop
DO 10 I = 1,10
is misspelt as '.' it becomes the assignment
DO10I = 1.0

Do you consider it a bug or a feature?
Does Fortran consider it a bug or feature?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: IPC with multiprocessing.connection

[bobicanprogram]

On Dec 22, 3:27 pm, Andrew Berg  wrote:
> I'm trying to set up a system where my main program launches external
> programs and then establishes connections to them via named pipes or
> Unix domain sockets (depending on platform) with
> multiprocessing.connection.Listener. The issue I'm having is with the
> accept() method. If there is nothing on the other side of the
> pipe/socket, it just hangs. Connection objects have a poll() method that
> can timeout, but I see no way to continue the program if there's no
> initial connection. What I'd like to do is let it time out if there's
> nothing on the other side.
> I'm pretty new to the multiprocessing module (and IPC in general), so I
> could've easily missed something.
>
> --
> CPython 3.2.2 | Windows NT 6.1.7601.17640

You might want to check out the code samples at:
http://www.icanprogram.com/06py/lesson1/lesson1.html

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

ANN: PyQt v4.9 Released (Python bindings for Qt)

[Phil Thompson]

PyQt v4.9 has been released and is available from
http://www.riverbankcomputing.com/software/pyqt/.

PyQt is a comprehensive set of bindings for the Qt application and UI
framework from Nokia.  It supports the same platforms as Qt (Windows,
Linux and MacOS/X).

PyQt supports Python v3 and Python v2.3 and later.

The highlight of this release is full support for Qt v4.8.0 and the
inclusion
of the QtDBus module (so providing support for DBus with Python v3).

Windows installers are provided for the GPL version of PyQt which contains
everything needed for PyQt development (including Qt, Qt Designer,
QScintilla, and MySQL, PostgreSQL, SQLite and ODBC drivers) except Python
itself.  Installers are provided for the 32 and 64 bit versions of Python
v2.5, v2.6, v2.7, v3.1 and v3.2.

PyQt v4 is implemented as a set of 19 extension modules containing over
400 classes and over 6,000 functions and methods.

QtCore
The non-GUI infrastructure including event loops, threads, i18n,
Unicode, signals and slots, user and application settings, mapped
files and shared memory.

QtDeclarative
A set of classes that implement a framework for building highly
dynamic user interfaces using the QML declarative language that can be
integrated with Python.

QtDBus
A set of classes for accessing remote applications using the DBus
protocol.

QtDesigner
A set of classes that allow the Qt Designer GUI design tool to be
extended with PyQt.

QtGui
A rich collection of GUI widgets.

QtHelp
A set of classes for creating and viewing searchable documentation and
being able to integrate online help with PyQt applications.  It
includes the C++ port of the Lucene text search engine.

QtNetwork
A set of classes to support TCP and UDP socket programming and higher
level protocols (eg. HTTP, SSL).

QtOpenGL
A set of classes that allows PyOpenGL to render onto Qt widgets.

QtScript
A set of classes that implements a JavaScript interpreter.  Python
objects may be exposed in the interpreter as JavaScript objects.

QtScriptTools
A debugger for the JavaScript interpreter.

QtSql
A set of classes that implement SQL data models and interfaces to
industry standard databases.  The Windows installers include support
for SQLite, MySQL, PostgreSQL and ODBC.

QtSvg
A set of classes to render SVG files onto Qt widgets.

QtTest
A set of classes to automate unit testing of PyQt applications and
GUIs.

QtWebKit
This implements a web browser engine based on the WebKit engine used
by Apple's Safari browser.  It allows the methods and properties of
Python objects to be published and appear as JavaScript objects to
scripts embedded in HTML pages.

QtXML
A set of classes that implement DOM and SAX parsers.

QtXMLPatterns
A set of classes that implement XQuery and XPath support for XML and
custom data models.

QAxContainer
A set of classes for Windows that allows the integration of ActiveX
controls and COM objects.

phonon
A cross-platform multimedia framework that enables the use of audio
and video content in PyQt applications.  DirectX is used as the
Windows backend, QuickTime as the MacOS/X backend, and GStreamer as
the Linux backend.

QtMultimedia
A set of classes that provide low-level multimedia functions.
Application developers would normally use the phonon module.

PyQt includes the pyuic4 utility which generates Python code to implement
user interfaces created with Qt Designer in the same way that the uic
utility generates C++ code.  It is also able to load Designer XML files
dynamically.

PyQt is available under the GPL and a commercial license.  Unlike Qt, PyQt
is not available under the LGPL.  The commercial PyQt license allows GPL
applications to be relicensed at any time.

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

Re: Idiom for shelling out to $EDITOR/$PAGER?

[Ben Finney]

Cameron Simpson  writes:

> On 23Dec2011 17:12, Ben Finney  wrote:
> | That doesn't address the concern Tim raised: did the user actually do
> | anything, did the file change?
>
> I'm not sure it matters.

I know of numerous applications where it matters, spcifically ones which
decide what to do with the edited text. Including “submit a bug report”
and “submit a wiki page edit” and “send an email message”.

> Sure. But still, if you're able to act on a changed file, why not also
> act on an unchanged file? The user asked to change things; take what
> you got back and proceed!

If the buffer was not edited, the user has most likely changed their
mind about editing at all, and there are many applications where the
correct default action differes depending on whether the user actually
changed anything in the text.

-- 
 \  “By instructing students how to learn, unlearn, and relearn, a |
  `\ powerful new dimension can be added to education.” —Alvin |
_o__)Toffler, _Future Shock_, 1970 |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: what does 'a=b=c=[]' do

[rusi]

On Dec 23, 2:39 pm, Steven D'Aprano  wrote:
> On Fri, 23 Dec 2011 00:38:07 -0800, rusi wrote:
> > Likewise function arguments that default to mutable entities is a known
> > gotcha of python which is best treated as a bug in python.
>
> Nonsense. It is a feature, not a bug.

Tsk Tsk How can python have a bug? And that too on the python mailing
list?

Others however feel differently. See Chris Rebert's
http://mail.python.org/pipermail/python-ideas/2007-January/73.html
and the links cited there.

>
> Some people might argue that it is a mistake, a minor feature which
> allegedly causes more difficulties than benefits. I do not hold with that
> idea. But either way, it is not a bug to be fixed, but a deliberate
> consequence of intended semantics.

I did not ask or imply that it should be 'fixed', just that language
misfeatures should be treated with extra care.
Windows uses CRLF where Unix uses LF.  Nobody could argue that this
discrepancy is of any use and nobody is about to fix it.

Of course if "bug" means "must-fix-else-unusable" then sure you are
right but then we would not be able to use most of the hardware or
software that we do.

To restate what (I think) Ian is saying:

Exploit language misfeatures cleverly in your code if you want. But
please red-flag them in mailing list posts.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: IPC with multiprocessing.connection

[Andrew Berg]

On 12/23/2011 5:50 AM, bobicanprogram wrote:

You might want to check out the code samples at:
http://www.icanprogram.com/06py/lesson1/lesson1.html
Let's see, I asked about a method in the multiprocessing module, and you 
recommend code snippets that run on Python versions that don't even have 
the module and that assume Linux when I state in my email signature the 
version of /Windows/ that I run. On top of all that, it's not even 
designed to teach Python; it's designed to explain how to use that 
library! I honestly don't mind someone pushing their website if it 
actually might help, but you clearly didn't read my post.


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

Re: Idiom for shelling out to $EDITOR/$PAGER?

[Tim Chase]

On 12/23/11 06:06, Ben Finney wrote:

Cameron Simpson  writes:

On 23Dec2011 17:12, Ben Finney
wrote: | That doesn't address the concern Tim raised: did
the user actually do | anything, did the file change?

I'm not sure it matters.


I know of numerous applications where it matters, spcifically
ones which decide what to do with the edited text. Including
“submit a bug report” and “submit a wiki page edit” and “send
an email message”.

If the buffer was not edited, the user has most likely changed
their mind about editing at all, and there are many
applications where the correct default action differes
depending on whether the user actually changed anything in the
text.


Yes, Ben's understanding is correct here, that for some of my 
use-cases, it's helpful to know if the user did anything.  The 
application can then decide whether it should use the original 
data it passed to the function, or whether it should go some 
"abort what you're doing" route.


-tkc


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

Timeout when calling COM objects on Windows

[Wong Wah Meng-R32813]

Hello there,

I am converting my VB ActiveX application written sometime back in year 2000 
with python 1.5.2 to run in python 2.7.1. 

My application is using RMI architecture and I am using a pythonOleRmi.py 
parser to exchange data/objects between the python and the VB exe. 

I have no issue when my VB EXE is not running as a COM server while making 
python API calls where my application server is written purely in python and 
runs on UNIX. However, when my VB EXE is running as a COM server, this code 
seems hangs when I make the python API same call to the application server. Is 
there something that I need to change or configure in order to run this 
successfully? Or to make some security setting on my Windows? (My VB EXE is run 
on Windows 7 now, will try out if the same issue is encountered on XP next 
week). 

Is the issue resided in the calling to the local daemon process 
(10.228.70.137:26000), or it is some security setting depicted in the policy.py 
file?



Collecting Python Trace Output...
Proxy called with: MatlMgr, getCompatibleFTCSVersions(), (), {}
Dec 23 18:41:21 OleRmiClient Timeout of 300 seconds occurred on the invocati
on of ('getAppAddress', (u'MatlMgr',), {}) to ('10.228.70.137', 26000)
pythoncom error: Python error invoking COM method.

Traceback (most recent call last):
  File "C:\genesis\Enablers\Python\lib\site-packages\win32com\server\policy.py",
 line 277, in _Invoke_
return self._invoke_(dispid, lcid, wFlags, args)
  File "C:\genesis\Enablers\Python\lib\site-packages\win32com\server\policy.py",
 line 282, in _invoke_
return S_OK, -1, self._invokeex_(dispid, lcid, wFlags, args, None, None)
  File "C:\genesis\Enablers\Python\lib\site-packages\win32com\server\policy.py",
 line 585, in _invokeex_
return func(*args)
  File "C:\genesis\Product\Lib\PythonOleRmi.py", line 240, in Proxy
proxy = self._getProxyObj(pyserverString)
  File "C:\genesis\Product\Lib\PythonOleRmi.py", line 223, in _getProxyObj
None, self._logWriter, rem_admin_addr = remAddr )
  File "C:\genesis\Product\Lib\EComponent.py", line 710, in __init__
addr = self._getAppProxyAddress()
  File "C:\genesis\Product\Lib\EComponent.py", line 742, in _getAppProxyAddress
addr = remAdmin.getAppAddress(self.server_name)
  File "C:\genesis\Product\Lib\EComponent.py", line 611, in __call__
self._method, args, kw )
  File "C:\genesis\Product\Lib\RMI.py", line 1779, in _genericInvocation
reply = self._requestReply( replyBit, (method_name, args, kw) )
  File "C:\genesis\Product\Lib\RMI.py", line 1585, in _requestReply
reply = self._receive()
  File "C:\genesis\Product\Lib\RMI.py", line 1677, in _receive
raise ServerReplyTimeout( self.reply_timeout)
ServerReplyTimeout: 300


Regards,
Wah Meng 

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

Re: what does 'a=b=c=[]' do

[Robert Kern]

On 12/23/11 10:22 AM, rusi wrote:

On Dec 23, 2:39 pm, Steven D'Aprano  wrote:

On Fri, 23 Dec 2011 00:38:07 -0800, rusi wrote:

Likewise function arguments that default to mutable entities is a known
gotcha of python which is best treated as a bug in python.


Nonsense. It is a feature, not a bug.


Tsk Tsk How can python have a bug? And that too on the python mailing
list?

Others however feel differently. See Chris Rebert's
http://mail.python.org/pipermail/python-ideas/2007-January/73.html
and the links cited there.



Some people might argue that it is a mistake, a minor feature which
allegedly causes more difficulties than benefits. I do not hold with that
idea. But either way, it is not a bug to be fixed, but a deliberate
consequence of intended semantics.


I did not ask or imply that it should be 'fixed', just that language
misfeatures should be treated with extra care.


"Bug" means, roughly, "something that should be fixed" not just any "thing that 
has some unwanted consequences". So yes, by calling it a bug you are asking and 
implying just that. If you don't mean that, don't use the word "bug".


--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco

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

Re: what does 'a=b=c=[]' do

[Neil Cerutti]

On 2011-12-23, Neil Cerutti  wrote:
> Is the misfeature that Python doesn't evaluate the default
> argument expression every time you call the function? What
> would be the harm if it did?

...you know, assuming it wouldn't break existing code. ;)

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

Re: what does 'a=b=c=[]' do

[Neil Cerutti]

On 2011-12-23, Chris Angelico  wrote:
> On Fri, Dec 23, 2011 at 7:49 PM, Ethan Furman  wrote:
>> That is the most ridiculous thing I have heard in a while.
>> ?Mutable default arguments are *not* a bug in Python.
>>
>> Reminds me of a bug report a couple years back claiming
>> multiple inheritence was a bug and asking it to be removed.
>
> Both of these could arguably be called misfeaures, but not
> bugs.

Is the misfeature that Python doesn't evaluate the default
argument expression every time you call the function? What would
be the harm if it did?

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

Re: what does 'a=b=c=[]' do

[rusi]

On Dec 23, 6:10 pm, Robert Kern  wrote:
> On 12/23/11 10:22 AM, rusi wrote:
>
>
>
>
>
>
>
>
>
> > On Dec 23, 2:39 pm, Steven D'Aprano > +comp.lang.pyt...@pearwood.info>  wrote:
> >> On Fri, 23 Dec 2011 00:38:07 -0800, rusi wrote:
> >>> Likewise function arguments that default to mutable entities is a known
> >>> gotcha of python which is best treated as a bug in python.
>
> >> Nonsense. It is a feature, not a bug.
>
> > Tsk Tsk How can python have a bug? And that too on the python mailing
> > list?
>
> > Others however feel differently. See Chris Rebert's
> >http://mail.python.org/pipermail/python-ideas/2007-January/73.html
> > and the links cited there.
>
> >> Some people might argue that it is a mistake, a minor feature which
> >> allegedly causes more difficulties than benefits. I do not hold with that
> >> idea. But either way, it is not a bug to be fixed, but a deliberate
> >> consequence of intended semantics.
>
> > I did not ask or imply that it should be 'fixed', just that language
> > misfeatures should be treated with extra care.
>
> "Bug" means, roughly, "something that should be fixed" not just any "thing 
> that
> has some unwanted consequences". So yes, by calling it a bug you are asking 
> and
> implying just that. If you don't mean that, don't use the word "bug".

Of course it should be fixed.  The repeated recurrence of it as a
standard gotcha as well as the python ideas list testifies to that.

Its not going to be fixed -- does not mean thats ideal, just that the
best proposed solutions cost/benefit equations are not good enough at
this point.

Case in point: I think it was around python 2.2 that there were
discussions for having a conditional operator.  GvR did not put it in
for a couple of releases not because it was a bad idea but because no
syntax was good enough.

When he finally did it, he chose a syntax which is arguably not ideal
but is the best all-things-considered (eg no unnecessary new keywords,
compatibility with existing code etc)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: what does 'a=b=c=[]' do

[Robert Kern]

On 12/23/11 1:23 PM, rusi wrote:

On Dec 23, 6:10 pm, Robert Kern  wrote:

On 12/23/11 10:22 AM, rusi wrote:

On Dec 23, 2:39 pm, Steven D'Apranowrote:



Some people might argue that it is a mistake, a minor feature which
allegedly causes more difficulties than benefits. I do not hold with that
idea. But either way, it is not a bug to be fixed, but a deliberate
consequence of intended semantics.



I did not ask or imply that it should be 'fixed', just that language
misfeatures should be treated with extra care.


"Bug" means, roughly, "something that should be fixed" not just any "thing that
has some unwanted consequences". So yes, by calling it a bug you are asking and
implying just that. If you don't mean that, don't use the word "bug".


Of course it should be fixed.  The repeated recurrence of it as a
standard gotcha as well as the python ideas list testifies to that.


So you were lying when you said that you did not ask or imply that it should be 
'fixed'? Please make up your mind. It's quite rude to "defend" your position by 
constantly shifting it whenever you get challenged on it.


--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco

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

Re: socket.gethostbyaddr( os.environ['REMOTE_ADDR'] error

[becky_lewis]

Is there any possibility that you can tell us what the script actually
is or provide a code listing (use pastebin if it's big)?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: what does 'a=b=c=[]' do

[rusi]

On Dec 23, 6:53 pm, Robert Kern  wrote:
> On 12/23/11 1:23 PM, rusi wrote:
>
>
>
>
>
>
>
>
>
> > On Dec 23, 6:10 pm, Robert Kern  wrote:
> >> On 12/23/11 10:22 AM, rusi wrote:
> >>> On Dec 23, 2:39 pm, Steven D'Aprano >>> +comp.lang.pyt...@pearwood.info>    wrote:
>  Some people might argue that it is a mistake, a minor feature which
>  allegedly causes more difficulties than benefits. I do not hold with that
>  idea. But either way, it is not a bug to be fixed, but a deliberate
>  consequence of intended semantics.
>
> >>> I did not ask or imply that it should be 'fixed', just that language
> >>> misfeatures should be treated with extra care.
>
> >> "Bug" means, roughly, "something that should be fixed" not just any "thing 
> >> that
> >> has some unwanted consequences". So yes, by calling it a bug you are 
> >> asking and
> >> implying just that. If you don't mean that, don't use the word "bug".
>
> > Of course it should be fixed.  The repeated recurrence of it as a
> > standard gotcha as well as the python ideas list testifies to that.
>
> So you were lying when you said that you did not ask or imply that it should 
> be
> 'fixed'? Please make up your mind. It's quite rude to "defend" your position 
> by
> constantly shifting it whenever you get challenged on it.

Meanings of "should" http://www.englishpage.com/modals/should.html
My first should was the 3rd one
My second was the 1st one.

[And we really should stop this argument (2nd one)]
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Grammar for classes

[Joshua Landau]

On 22 December 2011 23:39, Terry Reedy  wrote:

> On 12/20/2011 12:05 PM, Joshua Landau wrote:
>
>> Should I file a documentation bug report?
>>
>
> Please do. It the addition means something, it needs to be explained in
> the text. If it is wrong, it should go.


I have filed one at issue13658 .
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: what does 'a=b=c=[]' do

[Steven D'Aprano]

On Fri, 23 Dec 2011 06:57:02 -0800, rusi wrote:

> On Dec 23, 6:53 pm, Robert Kern  wrote:
>> On 12/23/11 1:23 PM, rusi wrote:
[...]
>> > Of course it should be fixed.  The repeated recurrence of it as a
>> > standard gotcha as well as the python ideas list testifies to that.
>>
>> So you were lying when you said that you did not ask or imply that it
>> should be 'fixed'? Please make up your mind. It's quite rude to
>> "defend" your position by constantly shifting it whenever you get
>> challenged on it.
> 
> Meanings of "should" http://www.englishpage.com/modals/should.html My
> first should was the 3rd one
> My second was the 1st one.

Rusi, are you a native English speaker? Because that excuse/defense does 
not excuse your comments at all, multiple meanings of "should" or not. 
Why not just admit to a mistake? After denying you were asking for Python 
to fix a so-called bug, you then called for Python to fix it. If this 
were a real argument rather than a friendly debate, people would be 
crying "Gotcha!" for sure.


> [And we really should stop this argument (2nd one)]

When the facts are against you, argue semantics; when semantics are 
against you, argue the facts; when both are against you, claim to be 
above arguing.


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

Early and late binding [was Re: what does 'a=b=c=[]' do]

[Steven D'Aprano]

On Fri, 23 Dec 2011 13:13:38 +, Neil Cerutti wrote:

> On 2011-12-23, Neil Cerutti  wrote:
>> Is the misfeature that Python doesn't evaluate the default argument
>> expression every time you call the function? What would be the harm if
>> it did?
> 
> ...you know, assuming it wouldn't break existing code. ;)

It will. Python's default argument strategy has been in use for 20 years. 
Some code will rely on it. I know mine does.

There are two strategies for dealing with default arguments that I know 
of: early binding and late binding. Python has early binding: the default 
argument is evaluated once, when the function is created. Late binding 
means the default argument is always re-evaluated each time it is needed.

Both strategies are reasonable choices. Both have advantages and 
disadvantages. Both have use-cases, and both lead to confusion when the 
user expects one but gets the other. If you think changing from early to 
late binding will completely eliminate the default argument "gotcha", you 
haven't thought things through -- at best you might reduce the number of 
complaints, but only at the cost of shifting them from one set of use-
cases to another.

Early binding is simple to implement and simple to explain: when you 
define a function, the default value is evaluated once, and the result 
stored to be used whenever it is needed. The disadvantage is that it can 
lead to unexpected results for mutable arguments.

Late binding is also simple to explain, but a little harder to implement. 
The function needs to store the default value as a piece of code (an 
expression) which can be re-evaluated as often as needed, not an object.

The disadvantage of late binding is that since the expression is live, it 
needs to be calculated each time, even if it turns out to be the same 
result. But there's no guarantee that it will return the same result each 
time: consider a default value like x=time.time(), which will return a 
different value each time it is called; or one like x=a+b, which will 
vary if either a or b are changed. Or will fail altogether if either a or 
b are deleted. This will surprise some people some of the time and lead 
to demands that Python "fix" the "obviously buggy" default argument 
gotcha.

If a language only offers one, I maintain it should offer early binding 
(the status quo). Why? Because it is more elegant to fake late binding in 
an early binding language than vice versa.

To fake late binding in a language with early binding, use a sentinel 
value and put the default value inside the body of the function:

def func(x, y=None):
if y is None:
y = []
...

All the important parts of the function are in one place, namely inside 
the function.

To fake early binding when the language provides late binding, you still 
use a sentinel value, but the initialization code creating the default 
value is outside the body of the function, usually in a global variable:

_DEFAULT_Y = []  # Private constant, don't touch.

def func(x, y=None):
if y is None:
y = _DEFAULT_Y
...

This separates parts of the code that should be together, and relies on a 
global, with all the disadvantages that implies.



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

Re: Early and late binding [was Re: what does 'a=b=c=[]' do]

[Chris Angelico]

On Sat, Dec 24, 2011 at 2:49 AM, Steven D'Aprano
 wrote:
> To fake early binding when the language provides late binding, you still
> use a sentinel value, but the initialization code creating the default
> value is outside the body of the function, usually in a global variable:
>
>    _DEFAULT_Y = []  # Private constant, don't touch.
>
>    def func(x, y=None):
>        if y is None:
>            y = _DEFAULT_Y
>        ...
>
> This separates parts of the code that should be together, and relies on a
> global, with all the disadvantages that implies.

A static variable (in the C sense) would make this just as clean as
the alternative. In Python, that could be implemented as an attribute
of the function object. Oh looky here... that's how default arguments
are implemented. :)

Tim Toady.

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

Re: Need advice on the design of my application

[Eelco]

My first suggestion would be to keep the rendering in Python, if at
all feasible, and do only the actual simulation/computation in C.
Rasterizing a heightfield and rigid body plus some plash effects is
nothing that couldnt be done in PyOpenGL, or even something higher-
level like visvis or mayavi. (visvis would be my first suggestion)

I would run the simulation in a python subprocess that calls into the
C dll; that should give you at least one core fully focussed on your
computations, without competition/blocking from any other modules.

Marshalling the simulation data between subprocesses should be a small
performance hurdle relative to getting it on your GPU; either way, the
python subprocessing module makes it entirely painless.

And I would start with an implementation in numpy; probably, you will
be doing some fft's and/or boundary element stuff. This can all be
done fairly efficiently in numpy; at minimum it will give you a
reference implementation, and its not unlikely it will work well
enough that you dont even want to bother with the C implementation
anymore.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: what does 'a=b=c=[]' do

[rusi]

On Dec 23, 8:33 pm, Steven D'Aprano  wrote:
> On Fri, 23 Dec 2011 06:57:02 -0800, rusi wrote:
> > On Dec 23, 6:53 pm, Robert Kern  wrote:
> >> On 12/23/11 1:23 PM, rusi wrote:
> [...]
> >> > Of course it should be fixed.  The repeated recurrence of it as a
> >> > standard gotcha as well as the python ideas list testifies to that.
>
> >> So you were lying when you said that you did not ask or imply that it
> >> should be 'fixed'? Please make up your mind. It's quite rude to
> >> "defend" your position by constantly shifting it whenever you get
> >> challenged on it.
>
> > Meanings of "should"http://www.englishpage.com/modals/should.htmlMy
> > first should was the 3rd one
> > My second was the 1st one.
>
> Rusi, are you a native English speaker? Because that excuse/defense does
> not excuse your comments at all, multiple meanings of "should" or not.
> Why not just admit to a mistake? After denying you were asking for Python
> to fix a so-called bug, you then called for Python to fix it. If this
> were a real argument rather than a friendly debate, people would be
> crying "Gotcha!" for sure.

Ok You got me!

Does that help the OP's?

> It's a slick language but I still have trouble wrapping my brain around some 
> of the concepts.

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

Get named module's file location

[Gnarlodious]

Given a module's name, how do I get the file path without importing it? 
Searched all over, can't find any such info.

Is it possible to ask if a named module exists before attempting an import?

Or are we forced to import first and catch any failure?

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

Re: Get named module's file location

[Yaşar Arabacı]

>>> import imp
>>> imp.find_module("os")
(,
'/usr/lib/python2.7/os.py', ('.py', 'U', 1))
>>>

2011/12/23 Gnarlodious 

> Given a module's name, how do I get the file path without importing it?
> Searched all over, can't find any such info.
>
> Is it possible to ask if a named module exists before attempting an import?
>
> Or are we forced to import first and catch any failure?
>
> -- Gnarlie
> --
> http://mail.python.org/mailman/listinfo/python-list
>



-- 
http://yasar.serveblog.net/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Early and late binding [was Re: what does 'a=b=c=[]' do]

[Roy Smith]

In article <4ef4a30d$0$29973$c3e8da3$54964...@news.astraweb.com>,
 Steven D'Aprano  wrote:

> The disadvantage of late binding is that since the expression is live, it 
> needs to be calculated each time, even if it turns out to be the same 
> result. But there's no guarantee that it will return the same result each 
> time: consider a default value like x=time.time(), which will return a 
> different value each time it is called

I know this is not quite the same thing, but it's interesting to look at 
what django (and mongoengine) do in their model definitions, prompted by 
your time.time() example.  You can do declare a model field something 
like:

class Foo(models.Model):
   timestamp = DateTimeField(default=datetime.utcnow)

Now, when you create a Foo, if you don't supply a timestamp, it 
generates one by calling utcnow() for you.  Very handy.

I'm not arguing that Python should do that, just pointing out an example 
of where late binding is nice.  Technically, that's probably not really 
late binding.  You always get the same function bound, it's just called 
each time it's used because django notices that you passed a callable.  
Maybe sort of "early binding, late calling" would be a more apt 
description, but given that python has descriptors, the line between 
data and function sometimes gets a little blurry anyway.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Get named module's file location

[Roy Smith]

In article 
<32472953.855.1324656114851.JavaMail.geo-discussion-forums@prix23>,
 Gnarlodious  wrote:

> Given a module's name, how do I get the file path without importing it? 
> Searched all over, can't find any such info.
> 
> Is it possible to ask if a named module exists before attempting an import?
> 
> Or are we forced to import first and catch any failure?
> 
> -- Gnarlie

import imp
imp.find_module()

Why do you want to do this?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Early and late binding [was Re: what does 'a=b=c=[]' do]

[Mel Wilson]

Steven D'Aprano wrote:
> On Fri, 23 Dec 2011 13:13:38 +, Neil Cerutti wrote:
>> On 2011-12-23, Neil Cerutti  wrote:
>> ...you know, assuming it wouldn't break existing code. ;)
> 
> It will. Python's default argument strategy has been in use for 20 years.
> Some code will rely on it. I know mine does.

In a tool that's meant for other people to use to accomplish work of their 
own, breaking workflow is a cardinal sin.

In a research language that's meant always to be up-to-date with the concept 
of the week, not so much.

Mel.

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

Re: Get named module's file location

[Gnarlodious]

Roy Smith wrote:

> import imp
> imp.find_module()

Oh yeah that works. I am getting a list of modtimes using List Comprehension, 
from a list of modules, which will be compared to an older list to see if 
mod_wsgi needs to be restarted.

Maybe thee is an easy way to get the modtimes, I'd be grateful.

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

Re: Get named module's file location

[Roy Smith]

In article 
<4946660.379.1324659073535.JavaMail.geo-discussion-forums@prez5>,
 Gnarlodious  wrote:

> Roy Smith wrote:
> 
> > import imp
> > imp.find_module()
> 
> Oh yeah that works. I am getting a list of modtimes using List Comprehension, 
> from a list of modules, which will be compared to an older list to see if 
> mod_wsgi needs to be restarted.

Ah, I see.  Django's runserver does this.  You might want to look to see 
how they implement it (https://www.djangoproject.com/download/).
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Early and late binding [was Re: what does 'a=b=c=[]' do]

[Neil Cerutti]

On 2011-12-23, Steven D'Aprano  wrote:
> On Fri, 23 Dec 2011 13:13:38 +, Neil Cerutti wrote:
>> On 2011-12-23, Neil Cerutti  wrote:
>>> Is the misfeature that Python doesn't evaluate the default
>>> argument expression every time you call the function? What
>>> would be the harm if it did?
>> 
>> ...you know, assuming it wouldn't break existing code. ;)
>
> It will. Python's default argument strategy has been in use for
> 20 years. Some code will rely on it. I know mine does.

I'm aware of that. I should have put the question differently,
but you did guess what I meant to ask. Thanks for the dicussion.

> Early binding is simple to implement and simple to explain:
> when you define a function, the default value is evaluated
> once, and the result stored to be used whenever it is needed.
> The disadvantage is that it can lead to unexpected results for
> mutable arguments.
>
> Late binding is also simple to explain, but a little harder to
> implement. The function needs to store the default value as a
> piece of code (an expression) which can be re-evaluated as
> often as needed, not an object.
>
> The disadvantage of late binding is that since the expression
> is live, it needs to be calculated each time, even if it turns
> out to be the same result. But there's no guarantee that it
> will return the same result each time: 

That's its main *advantage*.

> consider a default value like x=time.time(), which will return
> a different value each time it is called; or one like x=a+b,
> which will vary if either a or b are changed. Or will fail
> altogether if either a or b are deleted. This will surprise
> some people some of the time and lead to demands that Python
> "fix" the "obviously buggy" default argument gotcha.

It's hard to see anyone being confused by the resultant
exception. It's much harder to figure out what's going wrong with
an early-bound mutable.

> If a language only offers one, I maintain it should offer early
> binding (the status quo). Why? Because it is more elegant to
> fake late binding in an early binding language than vice versa.
>
> To fake late binding in a language with early binding, use a
> sentinel value and put the default value inside the body of the
> function:
>
> def func(x, y=None):
> if y is None:
> y = []
> ...
>
> All the important parts of the function are in one place,
> namely inside the function.
>
> To fake early binding when the language provides late binding,
> you still use a sentinel value, but the initialization code
> creating the default value is outside the body of the function,
> usually in a global variable:
>
> _DEFAULT_Y = []  # Private constant, don't touch.
>
> def func(x, y=None):
> if y is None:
> y = _DEFAULT_Y
> ...
>
> This separates parts of the code that should be together, and
> relies on a global, with all the disadvantages that implies.

I'd use a function attribute.

def func(x, y=None):
  if y is None:
y = func.default_y
  ...
func.default_y = []

That's awkward only if you believe function attributes are
awkward. Even if common practice were instead to use a global
variable, as you did, it wouldn't be considered bad if it were a
common idiom. In case, a global that's not meant to be rebound or
mutated is the best possible variety.

However, I also wouldn't base the decision of late versus early
binding on how confusing it would be if you assume wrongly which
one you are getting. Most default function arguments are
literals, so in Python the question just doesn't come up until
you get mutabled.

The greater efficiency was probably what decided this question
for Python, right? Since late-binding is so easy to fake, is
hardly ever what you want, and would make all code slower, why do
it?

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

Re: socket.gethostbyaddr( os.environ['REMOTE_ADDR'] error

[Νικόλαος Κούρας]

On 23 Δεκ, 12:41, becky_lewis  wrote:
> Is there any possibility that you can tell us what the script actually
> is or provide a code listing (use pastebin if it's big)?

The script is about retrieving and storing the visitros hostnames to
mysql database creating a log file.

I dont know why this line host =
socket.gethostbyaddr( os.environ['REMOTE_ADDR'] )[0] fails sometimes
and some other times works ok retrieving the hostnames correctly.

What do you understand from the traceback?!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: what does 'a=b=c=[]' do

[Michael Torrie]

On 12/23/2011 03:31 AM, rusi wrote:
> In Fortran, if the comma in the loop
> DO 10 I = 1,10
> is misspelt as '.' it becomes the assignment
> DO10I = 1.0
> 
> Do you consider it a bug or a feature?
> Does Fortran consider it a bug or feature?

Non sequitor.  Nothing at all to do with the issue at hand.
Furthermore, you are talking about a parser "feature" not a runtime
behavior.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Get named module's file location

[Gnarlodious]

I am rolling my own, and learning Python at the same time.

One more question. Say I want to assemble a list of tuples like this:

modules = ['wsgiref', 'http']
import imp
[(imp.find_module(module)[1], os.path.getmtime(imp.find_module(module)[1])) for 
module in modules]

Can I in some way assign imp.find_module(module)[1] to a variable and reuse it? 
Is this a job for lambda?

Thanks anyone.

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

Re: Idiom for shelling out to $EDITOR/$PAGER?

[Cameron Simpson]

On 23Dec2011 02:21, Devin Jeanpierre  wrote:
| > Anyway, look it up; it has an autodelete mode etc.
| 
| The autodelete isn't useful in this context. The file needs to be
| closed and then reopened again; with the autodelete option, the
| closing would delete the file, preventing it from being opened by the
| text editor or reopened to check contents.
| 
| (As far as I know, the race condition inherent in this is unavoidable.
| At least on windows, but I couldn't figure out any other way on Linux
| either.)

You can fire off the editor from inside the with statement.
Write contents, flush, edit, open T.name for read, read, close, exit
with statement.

Windows may hate you for this with its locking behaviour for open files,
but it will work for UNIX.

Cheers,
-- 
Cameron Simpson  DoD#743
http://www.cskk.ezoshosting.com/cs/

The elliptical cam has gradually slid up the beam shaft and caught on the
flange rebate dislodging the gripley, with disastrous results.
- Death, 'Reaper Man' (Pratchett)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Get named module's file location

[Chris Angelico]

On Sat, Dec 24, 2011 at 6:40 AM, Gnarlodious  wrote:
> [(imp.find_module(module)[1], os.path.getmtime(imp.find_module(module)[1])) 
> for module in modules]
>
> Can I in some way assign imp.find_module(module)[1] to a variable and reuse 
> it? Is this a job for lambda?

Well, you can use an additional comprehension to provide a temporary
variable, if you really want to do it all as a single expression.

[(m, os.path.getmtime(m)) for m in (imp.find_module(module)[1] for
module in modules)]

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

Re: Cannot Remove Python Libs from XP

[W. eWatson]

On 12/22/2011 1:21 PM, Dennis Lee Bieber wrote:

On Thu, 22 Dec 2011 09:53:04 -0800, "W. eWatson"
  wrote:


I have three py libs and the python program itself, 2.52, installed on
an 6 year old HP Laptop. I decided to remove them, and took removed
Python with the Control Panel ?Add/Remove icon. Worked fine. When I try
to remove any of the remaining libs, press the add/remove button does
nothing but blink. How  do I get around this  problem?


It would probably have been better to remove the libraries first
(especially if their installers /used/ Python to do the install; the
uninstaller would then likely also have used that version of Python). In
short, uninstalling a set of related packages should be done in the
reverse order of how they were installed.

If you don't have anything private stored in the remains of the
Python2.5.2 install directory... Just delete the entire directory tree
(which should get rid of any left-over files from the other libraries).

Removing them from the Add/Remove control might be achieved by using
a registry cleaner; if not, manually scanning the registry for those
package names and deleting the registry keys may suffice (back up the
registry first -- export everything from the top down). Then run a
registry cleaner, as there may be stray GUID keys that eventually mapped
to the deleted keys.

Lets see {booting even older WinXP laptop -- I'm using a Win7
laptop with data-card for current online activity}

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\...

Look for the particular packages (and anything else you may also
have removed just in case something got left behind) and delete the
keys. (Interesting -- I have an entry for wxPython, but no entry for
Python or ActiveState... They may be stuffed elsewhere -- I also seem to
have a corrupted search path; maybe happened last time I tried using the
laptop to debug one of your queries; Pythonwin isn't finding win32ui)


I think this turns out to be something of a laugher. I did re-install 
Python 2.5.2; however, the action was similar when I tried to remove the 
libs. I happened to move the screen slightly, and noticed a small hidden 
dialog behind the Add/Remove screen with a message in it. "Are you sure 
you want to remove this program?".  Argh. How foolish it was to hide 
that simple dialog. So hitting the add/remove button repeatedly really 
was useless.

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

Re: Get named module's file location

[Roy Smith]

In article 
<4652751.858.1324669248908.JavaMail.geo-discussion-forums@prj1>,
 Gnarlodious  wrote:

> I am rolling my own, and learning Python at the same time.

Hmmm.  The imp module is kind of deep magic for a first introduction to 
the language.  But, whatever.

> One more question. Say I want to assemble a list of tuples like this:
> 
> modules = ['wsgiref', 'http']
> import imp
> [(imp.find_module(module)[1], os.path.getmtime(imp.find_module(module)[1])) 
> for module in modules]
> 
> Can I in some way assign imp.find_module(module)[1] to a variable and reuse 
> it? Is this a job for lambda?

I think what you want to do is rewrite the list comprehension as a 
regular loop.

my_list = []
for module in modules:
   m = imp.find_module(module)[1]
   my_list.append(m, os.path.getmtime(m))
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Idiom for shelling out to $EDITOR/$PAGER?

[Devin Jeanpierre]

> Windows may hate you for this with its locking behaviour for open files,
> but it will work for UNIX.

Windows won't let you open the file while NamedTemporaryFile has a
hold on it, yeah. Your point is legitimate anyway.

Even so, there's still the race conditions for "what if the tempfile
is moved before the editor can get to it" and "what if the tempfile is
moved after the editor can get to it but before I can open it again".

-- Devin

On Fri, Dec 23, 2011 at 2:47 PM, Cameron Simpson  wrote:
> On 23Dec2011 02:21, Devin Jeanpierre  wrote:
> | > Anyway, look it up; it has an autodelete mode etc.
> |
> | The autodelete isn't useful in this context. The file needs to be
> | closed and then reopened again; with the autodelete option, the
> | closing would delete the file, preventing it from being opened by the
> | text editor or reopened to check contents.
> |
> | (As far as I know, the race condition inherent in this is unavoidable.
> | At least on windows, but I couldn't figure out any other way on Linux
> | either.)
>
> You can fire off the editor from inside the with statement.
> Write contents, flush, edit, open T.name for read, read, close, exit
> with statement.
>
> Windows may hate you for this with its locking behaviour for open files,
> but it will work for UNIX.
>
> Cheers,
> --
> Cameron Simpson  DoD#743
> http://www.cskk.ezoshosting.com/cs/
>
> The elliptical cam has gradually slid up the beam shaft and caught on the
> flange rebate dislodging the gripley, with disastrous results.
>        - Death, 'Reaper Man' (Pratchett)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Get named module's file location

[Chris Angelico]

I'm guessing you meant for this to be on-list, and am hoping you don't
mind that I'm replying on-list.

On Sat, Dec 24, 2011 at 8:16 AM, Gnarlodious  wrote:
> Chris Angelico wrote:
>> [(m, os.path.getmtime(m)) for m in (imp.find_module(module)[1] for
>> module in modules)]
>>
>> Yeah, a little hard to read. Tell me, does this formulation execute
>> imp.find_module(module) once or twice for each modname?

What this does is save a temporary list, more or less. (It's actually
a generator expression, not a list comprehension, but that's
immaterial.)

temporary = [imp.find_module(module)[1] for module in modules]
[(m, os.path.getmtime(m)) for m in temporary]

It iterates over modules, calling find_module for each, and saving the
results to a new list. Then separately iterates over the new list,
pairing each with the getmtime.

Since I used parentheses instead of square brackets in the original
expression, Python won't actually build the full list. Other than
that, it's equivalent to the two-statement version, and you can try
those two in IDLE to see what they do.

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

Re: Early and late binding [was Re: what does 'a=b=c=[]' do]

[Steven D'Aprano]

On Sat, 24 Dec 2011 02:55:41 +1100, Chris Angelico wrote:

> On Sat, Dec 24, 2011 at 2:49 AM, Steven D'Aprano
>  wrote:
>> To fake early binding when the language provides late binding, you
>> still use a sentinel value, but the initialization code creating the
>> default value is outside the body of the function, usually in a global
>> variable:
>>
>>    _DEFAULT_Y = []  # Private constant, don't touch.
>>
>>    def func(x, y=None):
>>        if y is None:
>>            y = _DEFAULT_Y
>>        ...
>>
>> This separates parts of the code that should be together, and relies on
>> a global, with all the disadvantages that implies.
> 
> A static variable (in the C sense) would make this just as clean as the
> alternative. In Python, that could be implemented as an attribute of the
> function object. Oh looky here... that's how default arguments are
> implemented. :)

Yes. But having to manage it *by hand* is still unclean:

* you still have to assign the default value to the function assignment 
outside the function, which is inelegant; 

* if you rename the function, the internal lookup func.default_value will 
fail.

I'm not saying it can't be done. I'm just saying that the status quo is 
cleaner and more elegant, and if you want late binding, there is a 
simple, obvious, elegant idiom to get it.



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

Re: Get named module's file location

[Steven D'Aprano]

On Fri, 23 Dec 2011 15:00:17 -0500, Roy Smith wrote:

>> Can I in some way assign imp.find_module(module)[1] to a variable and
>> reuse it? Is this a job for lambda?
> 
> I think what you want to do is rewrite the list comprehension as a
> regular loop.
> 
> my_list = []
> for module in modules:
>m = imp.find_module(module)[1]
>my_list.append(m, os.path.getmtime(m))

+1


List comprehensions are so cool that sometimes people forget that not 
every loop has to be a list comp. There is no shortage of newlines in the 
world, and not everything needs to be on a single line.


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

Re: Early and late binding [was Re: what does 'a=b=c=[]' do]

[Chris Angelico]

On Sat, Dec 24, 2011 at 9:32 AM, Steven D'Aprano
 wrote:
> Yes. But having to manage it *by hand* is still unclean:

Well, my point was that Python's current behaviour _is_ that.

> * you still have to assign the default value to the function assignment
> outside the function, which is inelegant;

C's static variables are initialized inside the function. But since
Python doesn't have that, it doesn't really work that way. (You might
be able to use a decorator to do some cool tricks though.)

> * if you rename the function, the internal lookup func.default_value will
> fail.

Python would benefit some from a "current-function" reference, if
tricks like this were to be encouraged. It'd help with recursion too.
h...

>>> def Y(func):
return lambda *args,**kwargs: func(func,*args,**kwargs)

>>> @Y
def foo(me,x):
if x>5: return x
return me(me,x+1),7,x

>>> foo(3)
(((6, 7, 5), 7, 4), 7, 3)

Useful? Not very. Maybe as a language feature, but not as a parameter.
But of curiosity value.

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

Re: Early and late binding [was Re: what does 'a=b=c=[]' do]

[Devin Jeanpierre]

> To fake early binding when the language provides late binding, you still
> use a sentinel value, but the initialization code creating the default
> value is outside the body of the function, usually in a global variable:
>
>_DEFAULT_Y = []  # Private constant, don't touch.
>
>def func(x, y=None):
>if y is None:
>y = _DEFAULT_Y
>...
>
> This separates parts of the code that should be together, and relies on a
> global, with all the disadvantages that implies.

No, you can just do def func(x, y=_DEFAULT_Y): ...

-- Devin

On Fri, Dec 23, 2011 at 10:49 AM, Steven D'Aprano
 wrote:
> On Fri, 23 Dec 2011 13:13:38 +, Neil Cerutti wrote:
>
>> On 2011-12-23, Neil Cerutti  wrote:
>>> Is the misfeature that Python doesn't evaluate the default argument
>>> expression every time you call the function? What would be the harm if
>>> it did?
>>
>> ...you know, assuming it wouldn't break existing code. ;)
>
> It will. Python's default argument strategy has been in use for 20 years.
> Some code will rely on it. I know mine does.
>
> There are two strategies for dealing with default arguments that I know
> of: early binding and late binding. Python has early binding: the default
> argument is evaluated once, when the function is created. Late binding
> means the default argument is always re-evaluated each time it is needed.
>
> Both strategies are reasonable choices. Both have advantages and
> disadvantages. Both have use-cases, and both lead to confusion when the
> user expects one but gets the other. If you think changing from early to
> late binding will completely eliminate the default argument "gotcha", you
> haven't thought things through -- at best you might reduce the number of
> complaints, but only at the cost of shifting them from one set of use-
> cases to another.
>
> Early binding is simple to implement and simple to explain: when you
> define a function, the default value is evaluated once, and the result
> stored to be used whenever it is needed. The disadvantage is that it can
> lead to unexpected results for mutable arguments.
>
> Late binding is also simple to explain, but a little harder to implement.
> The function needs to store the default value as a piece of code (an
> expression) which can be re-evaluated as often as needed, not an object.
>
> The disadvantage of late binding is that since the expression is live, it
> needs to be calculated each time, even if it turns out to be the same
> result. But there's no guarantee that it will return the same result each
> time: consider a default value like x=time.time(), which will return a
> different value each time it is called; or one like x=a+b, which will
> vary if either a or b are changed. Or will fail altogether if either a or
> b are deleted. This will surprise some people some of the time and lead
> to demands that Python "fix" the "obviously buggy" default argument
> gotcha.
>
> If a language only offers one, I maintain it should offer early binding
> (the status quo). Why? Because it is more elegant to fake late binding in
> an early binding language than vice versa.
>
> To fake late binding in a language with early binding, use a sentinel
> value and put the default value inside the body of the function:
>
>    def func(x, y=None):
>        if y is None:
>            y = []
>        ...
>
> All the important parts of the function are in one place, namely inside
> the function.
>
> To fake early binding when the language provides late binding, you still
> use a sentinel value, but the initialization code creating the default
> value is outside the body of the function, usually in a global variable:
>
>    _DEFAULT_Y = []  # Private constant, don't touch.
>
>    def func(x, y=None):
>        if y is None:
>            y = _DEFAULT_Y
>        ...
>
> This separates parts of the code that should be together, and relies on a
> global, with all the disadvantages that implies.
>
>
>
> --
> Steven
> --
> http://mail.python.org/mailman/listinfo/python-list
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Idiom for shelling out to $EDITOR/$PAGER?

[Owen Jacobson]

On 2011-12-23 06:02:18 +, Cameron Simpson said:


MacOSX has "open", though it won't be running a blocking editor, alas.


But it can be. From the man page:

-t  Causes the file to be opened with the default text editor, as deter-
mined via LaunchServices

and

-W  Causes open to wait until the applications it opens (or that were
already open) have exited.  Use with the -n flag to allow open to
function as an appropriate app for the $EDITOR environment variable.

and finally

-n  Open a new instance of the application(s) even if one is already run-
ning.

can be combined to make 'open' (the shell interface to OS X's 
LaunchServices system) into a workable $EDITOR.


-o


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

Re: merging argparse parsers

[Jason Friedman]

> I would like to have something like
>
> merged_parser = LoggingParser() + OtherParser()
>
> Which should create an argument parser with all the options composed.
>

I have used parent parsers.

http://docs.python.org/py3k/library/argparse.html#parents

I think in your case merged_parser would become more of a child, like this:

>>> mom_parser = argparse.ArgumentParser(add_help=False)
>>> mom_parser.add_argument('--arg1', type=int)
>>> dad_parser = argparse.ArgumentParser(add_help=False)
>>> dad_parser.add_argument('--arg2', type=int)
>>> child_parser = argparse.ArgumentParser(parents=[mom_parser, dad_parser])
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: modifying a time.struct_time

[Jason Friedman]

On Fri, Dec 16, 2011 at 10:44 AM, Chris Angelico  wrote:
> On Fri, Dec 16, 2011 at 8:45 PM, Ulrich Eckhardt
>  wrote:
>> I'm trying to create a struct_time that is e.g. one year ahead or a month
>> back in order to test some parsing/formatting code with different dates.
>
> Do you need it to be one exact calendar year, or would it make sense
> to add/subtract integers from a Unix time?
>
> t = time.time() + 365*86400   # Not actually a year ahead, it's 365 days ahead
> t = time.localtime(t)  # if you want a struct_time
>
> ChrisA
> --

Not particularly elegant, but I believe accurate and relying only on
the stated struct_time contract:

#!/usr/bin/env python
# 2.7.2
import time, itertools
def is_local_time_different_by_one_year(time1, time2):
if abs(time1.tm_year - time2.tm_year) != 1:
return False
if abs(time1.tm_mon  - time2.tm_mon ) != 0:
return False
if abs(time1.tm_mday - time2.tm_mday) != 0:
return False
if abs(time1.tm_hour - time2.tm_hour) != 0:
return False
if abs(time1.tm_min  - time2.tm_min ) != 0:
return False
if abs(time1.tm_sec  - time2.tm_sec ) != 0:
return False
return True

t = time.time()
time1 = time.localtime(t)
print("Local time is {}.".format(time1))
for i in itertools.count(0):
t += 1 # Add one second until we have reached next year
time2 = time.localtime(t)
if is_local_time_different_by_one_year(time1, time2):
print("One year later is {}".format(time2))
break


Not exactly a speed demon, either:
$ time python timediff.py
Local time is time.struct_time(tm_year=2011, tm_mon=12, tm_mday=24,
tm_hour=5, tm_min=57, tm_sec=44, tm_wday=5, tm_yday=358, tm_isdst=0).
One year later is time.struct_time(tm_year=2012, tm_mon=12,
tm_mday=24, tm_hour=5, tm_min=57, tm_sec=44, tm_wday=0, tm_yday=359,
tm_isdst=0)

real3m8.922s
user2m2.470s
sys 1m1.760s
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: modifying a time.struct_time

[Chris Angelico]

On Sat, Dec 24, 2011 at 5:04 PM, Jason Friedman  wrote:
> Not particularly elegant, but I believe accurate and relying only on
> the stated struct_time contract:

Funny! But a binary search would be better, I think.


t = time.time()
time1 = time.localtime(t)
print("Local time is {}.".format(time1))
est1 = t + 365*86400
est2 = est1 + 86400 # Assume that the year is between 365 and 366 days
long (widen this if assumption not valid)
while True:
   est = (est1 + est2) / 2
   time2 = time.localtime(t)
   cmp = is_local_time_different_by_one_year(time1, time2):
   if cmp<0: est1 = est
   elif cmp>0: est2 = est
   else:
   print("One year later is {}".format(time2))
   break

Could do with a few more improvements. Also, it requires that the
comparison function return -1, 0, or 1, in the same way that strcmp()
does (not a difficult enhancement, but I'm off to Christmas dinner
with the family so I'll leave it as an exercise for the reader).

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