Re: in-place exponentiation incongruities

[Giacomo Alzetta]

Il giorno domenica 12 agosto 2012 06:28:10 UTC+2, Steven D'Aprano ha scritto:
> On Sat, 11 Aug 2012 09:54:56 -0700, Giacomo Alzetta wrote:
> 
> 
> 
> > I've noticed some incongruities regarding in-place exponentiation.
> 
> > 
> 
> > On the C side nb_inplace_power is a ternary function, like nb_power (see
> 
> > here:
> 
> > http://docs.python.org/c-api/typeobj.html?
> 
> highlight=numbermethods#PyNumberMethods).
> 
> > 
> 
> > Obviously you can't pass the third argument using the usual in-place
> 
> > syntax "**=". Nevertheless I'd expect to be able to provide the third
> 
> > argument using operator.ipow. But the operator module accept only the
> 
> > two parameter variant.
> 
> 
> 
> Why? The operator module implements the ** operator, not the pow() 
> 
> function. If you want the pow() function, you can just use it directly, 
> 
> no need to use operator.pow or operator.ipow.
> 
> 
> 
> Since ** is a binary operator, it can only accept two arguments.
> 
> 
> 
> 
> 
> > The Number Protocol specify that the ipow operation ""is the equivalent
> 
> > of the Python statement o1 **= o2 when o3 is Py_None, or an in-place
> 
> > variant of pow(o1, o2, o3) otherwise.""
> 
> 
> 
> Where is that from?
> 
> 
> 
> 
> 
> -- 
> 
> Steven

>From The Number Protocol(http://docs.python.org/c-api/number.html).
The full text is:

PyObject* PyNumber_InPlacePower(PyObject *o1, PyObject *o2, PyObject *o3)
Return value: New reference.

**See the built-in function pow().** Returns NULL on failure. The operation 
is done in-place when o1 supports it. This is the equivalent of the Python 
statement o1 **= o2 when o3 is Py_None, or an in-place variant of pow(o1, o2, 
o3) otherwise. If o3 is to be ignored, pass Py_None in its place (passing NULL 
for o3 would cause an illegal memory access).

The first thing that this text does is referring to the **function** pow, which 
takes three arguments. And since the documentation of the operator module 
states that "The operator module exports a set of efficient functions 
corresponding to the intrinsic operators of Python.", I'd expect the ipow to 
have three arguments, the third being optional.


With normal exponentiation you have ** referring to the 2-argument variant, and 
"pow" providing the ability to use the third argument.
At the moment in-place exponentiation you have "**=" referring to the 
2-argument variant(and this is consistent), while operator.ipow also referring 
to it. So providing an ipow with the third argument would just increase 
consistency in the language, and provide a feature that at the moment is not 
present. (well if the designers of python care really much about consistency 
they'd probably add an "ipow" built-in function, so that you don't have to 
import it from "operator").

I understand that it's not a feature often used, but I can't see why not 
allowing it.
At the moment you can do that from the C side, because you can call 
PyNumber_InPlacePower directly, but from the python side you have no way to do 
that, except for writing a C-extension that wraps the PyNumber_InPlacePower 
function.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: in-place exponentiation incongruities

[Steven D'Aprano]

On Sun, 12 Aug 2012 00:14:27 -0700, Giacomo Alzetta wrote:

> From The Number Protocol(http://docs.python.org/c-api/number.html). The
> full text is:
> 
> PyObject* PyNumber_InPlacePower(PyObject *o1, PyObject *o2, PyObject
> *o3)
> Return value: New reference.
> 
> **See the built-in function pow().** Returns NULL on failure. The
> operation is done in-place when o1 supports it. This is the
> equivalent of the Python statement o1 **= o2 when o3 is Py_None, or
> an in-place variant of pow(o1, o2, o3) otherwise. If o3 is to be
> ignored, pass Py_None in its place (passing NULL for o3 would cause
> an illegal memory access).
> 
> The first thing that this text does is referring to the **function**
> pow, which takes three arguments. And since the documentation of the
> operator module states that "The operator module exports a set of
> efficient functions corresponding to the intrinsic operators of
> Python.", I'd expect the ipow to have three arguments, the third being
> optional.

Why? There is no three-argument operator. There is a three-argument 
function, pow, but you don't need the operator module for that, it is 
built-in. There is no in-place three-argument operator, and no in-place 
three-argument function in the operator module.

Arguing from "consistency" is not going to get you very far, since it is 
already consistent:

In-place binary operator: **=
In-place binary function: operator.ipow

In-place three-argument operator: none
In-place three-argument function: none

If you decide to make a feature-request, you need to argue from 
usefulness, not consistency.

http://bugs.python.org

Remember that the Python 2.x branch is now in feature-freeze, so new 
features only apply to Python 3.x.


> With normal exponentiation you have ** referring to the 2-argument
> variant, and "pow" providing the ability to use the third argument. 

Correct.


> At the moment in-place exponentiation you have "**=" referring to the
> 2-argument variant(and this is consistent), while operator.ipow also
> referring to it. 

Correct. Both **= and ipow match the ** operator, which only takes two 
arguments.


> So providing an ipow with the third argument would just
> increase consistency in the language, 

Consistency with something other than **=  would be inconsistency.



> and provide a feature that at the
> moment is not present. (well if the designers of python care really much
> about consistency they'd probably add an "ipow" built-in function, so
> that you don't have to import it from "operator").

Not everything needs to be a built-in function.



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

Re: Arithmetic with Boolean values

[Steven D'Aprano]

On Sat, 11 Aug 2012 17:54:40 -0700, Paul Rubin wrote:

> John Ladasky  writes:
[...]
>> If the length of the list L is odd, I want to process it once.  If
>> len(L) is even, I want to process it twice
>>   for x in range(1 + not(len(L) % 2)):
> 
> If you really have to do something like that, I'd say
> 
>for x in range(1 + (len(L) & 1)):
[snip]

I'd simplify it even more:

for x in (0,) if len(L)%2 else (0, 1):
...

which is even more explicit and simpler to read even though it is longer.



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

Re: Arithmetic with Boolean values

[Roy Smith]

In article <502791ea$0$29978$c3e8da3$54964...@news.astraweb.com>,
 Steven D'Aprano  wrote:

> for x in (0,) if len(L)%2 else (0, 1):
> ...
> 
> which is even more explicit and simpler to read even though it is longer.

Ugh.

do_stuff()
if len(L) % 2 == 0:
   do_stuff()  # reprocess even-length list

Sure, it's 3 lines instead of one, but dead-obvious what the intention 
is.  I might even go for:

if len(L) % 2:
   do_stuff()
else:
   do_stuff()
   do_stuff()

There's two problems with all the looping suggestions people have given.  
One is that the computation of whether you need to do it once or twice 
is messy.  But, but bigger issue is you're trying to warp what's 
fundamentally a boolean value into a looping construct.  That's a 
cognitive mismatch.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: in-place exponentiation incongruities

[Giacomo Alzetta]

Il giorno domenica 12 agosto 2012 13:03:08 UTC+2, Steven D'Aprano ha scritto:
> On Sun, 12 Aug 2012 00:14:27 -0700, Giacomo Alzetta wrote:
> 
> 
> 
> > From The Number Protocol(http://docs.python.org/c-api/number.html). The
> 
> > full text is:
> 
> > 
> 
> > PyObject* PyNumber_InPlacePower(PyObject *o1, PyObject *o2, PyObject
> 
> > *o3)
> 
> > Return value: New reference.
> 
> > 
> 
> > **See the built-in function pow().** Returns NULL on failure. The
> 
> > operation is done in-place when o1 supports it. This is the
> 
> > equivalent of the Python statement o1 **= o2 when o3 is Py_None, or
> 
> > an in-place variant of pow(o1, o2, o3) otherwise. If o3 is to be
> 
> > ignored, pass Py_None in its place (passing NULL for o3 would cause
> 
> > an illegal memory access).
> 
> > 
> 
> > The first thing that this text does is referring to the **function**
> 
> > pow, which takes three arguments. And since the documentation of the
> 
> > operator module states that "The operator module exports a set of
> 
> > efficient functions corresponding to the intrinsic operators of
> 
> > Python.", I'd expect the ipow to have three arguments, the third being
> 
> > optional.
> 
> 
> 
> Why? There is no three-argument operator. There is a three-argument 
> 
> function, pow, but you don't need the operator module for that, it is 
> 
> built-in. There is no in-place three-argument operator, and no in-place 
> 
> three-argument function in the operator module.
> 
> 
> 
> Arguing from "consistency" is not going to get you very far, since it is 
> 
> already consistent:
> 
> 
> 
> In-place binary operator: **=
> 
> In-place binary function: operator.ipow
> 
> 
> 
> In-place three-argument operator: none
> 
> In-place three-argument function: none
> 
> 
> 
> If you decide to make a feature-request, you need to argue from 
> 
> usefulness, not consistency.
> 
> 
> 
> http://bugs.python.org
> 
> 
> 
> Remember that the Python 2.x branch is now in feature-freeze, so new 
> 
> features only apply to Python 3.x.
> 
> 
> 
> 
> 
> > With normal exponentiation you have ** referring to the 2-argument
> 
> > variant, and "pow" providing the ability to use the third argument. 
> 
> 
> 
> Correct.
> 
> 
> 
> 
> 
> > At the moment in-place exponentiation you have "**=" referring to the
> 
> > 2-argument variant(and this is consistent), while operator.ipow also
> 
> > referring to it. 
> 
> 
> 
> Correct. Both **= and ipow match the ** operator, which only takes two 
> 
> arguments.
> 
> 
> 
> 
> 
> > So providing an ipow with the third argument would just
> 
> > increase consistency in the language, 
> 
> 
> 
> Consistency with something other than **=  would be inconsistency.
> 
> 
> 
> 
> 
> 
> 
> > and provide a feature that at the
> 
> > moment is not present. (well if the designers of python care really much
> 
> > about consistency they'd probably add an "ipow" built-in function, so
> 
> > that you don't have to import it from "operator").
> 
> 
> 
> Not everything needs to be a built-in function.
> 
> 
> 
> 
> 
> 
> 
> -- 
> 
> Steven

Probably I've mixed things up.

What I mean is: when you implement a new type as a C extension you have to 
provide special methods through the NumberMethods struct. In this struct both 
the power and in-place power operations have three arguments.
Now, suppose I implement the three argument variant of the in-place power in a 
class. No user would be able to call my C function with a non-None third 
argument, while he would be able to call the normal version with the third 
argument.

This is what I find inconsistent. either provide a way to call also the 
in-place exponentiation with three arguments, or define it as a binary function.
Having it as a ternary function, but only from the C-side is quite strange.

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

Re: save dictionary to a file without brackets.

[88888 Dihedral]

Steven D'Aprano於 2012年8月11日星期六UTC+8下午7時26分37秒寫道：
> On Fri, 10 Aug 2012 08:53:43 +1000, Chris Angelico wrote:
> 
> 
> 
> > On Fri, Aug 10, 2012 at 8:26 AM, Dave Angel  wrote:
> 
> >> On 08/09/2012 06:03 PM, Andrew Cooper wrote:
> 
> >>> O(n) for all other entries in the dict which suffer a hash collision
> 
> >>> with the searched entry.
> 
> >>>
> 
> >>> True, a sensible choice of hash function will reduce n to 1 in common
> 
> >>> cases, but it becomes an important consideration for larger datasets.
> 
> >>
> 
> >> I'm glad you're wrong for CPython's dictionaries.  The only time the
> 
> >> lookup would degenerate to O[n] would be if the hash table had only one
> 
> >> slot.  CPython sensibly increases the hash table size when it becomes
> 
> >> too small for efficiency.
> 
> >>
> 
> >> Where have you seen dictionaries so poorly implemented?
> 
> > 
> 
> > In vanilla CPython up to version (I think) 3.3, where it's possible to
> 
> > DoS the hash generator. Hash collisions are always possible, just
> 
> > ridiculously unlikely unless deliberately exploited.
> 
> 
> 
> Not so unlikely actually.
> 
> 
> 
> py> hash(3)
> 
> 3
> 
> py> hash(2**64 + 2)
> 
> 3
> 
> 
> 
> py> hash(-1)
> 
> -2
> 
> py> hash(-2)
> 
> -2
> 
> 
> 
> 
> 
> By its very nature, a hash function cannot fail to have collisions. The 
> 
> problem is that in general you have an essentially unlimited number of 
> 
> objects being mapped to a large but still finite number of hash values.
> 
> 
> 
> 
> 
> 
> 
> -- 
> 
> Steven



Steven D'Aprano於 2012年8月11日星期六UTC+8下午7時26分37秒寫道：
> On Fri, 10 Aug 2012 08:53:43 +1000, Chris Angelico wrote:
> 
> 
> 
> > On Fri, Aug 10, 2012 at 8:26 AM, Dave Angel  wrote:
> 
> >> On 08/09/2012 06:03 PM, Andrew Cooper wrote:
> 
> >>> O(n) for all other entries in the dict which suffer a hash collision
> 
> >>> with the searched entry.
> 
> >>>
> 
> >>> True, a sensible choice of hash function will reduce n to 1 in common
> 
> >>> cases, but it becomes an important consideration for larger datasets.
> 
> >>
> 
> >> I'm glad you're wrong for CPython's dictionaries.  The only time the
> 
> >> lookup would degenerate to O[n] would be if the hash table had only one
> 
> >> slot.  CPython sensibly increases the hash table size when it becomes
> 
> >> too small for efficiency.
> 
> >>
> 
> >> Where have you seen dictionaries so poorly implemented?
> 
> > 
> 
> > In vanilla CPython up to version (I think) 3.3, where it's possible to
> 
> > DoS the hash generator. Hash collisions are always possible, just
> 
> > ridiculously unlikely unless deliberately exploited.
> 
> 
> 
> Not so unlikely actually.
> 
> 
> 
> py> hash(3)
> 
> 3
> 
> py> hash(2**64 + 2)
> 
> 3
> 
> 
> 
> py> hash(-1)
> 
> -2
> 
> py> hash(-2)
> 
> -2
> 
> 
> 
> 
> 
> By its very nature, a hash function cannot fail to have collisions. The 
> 
> problem is that in general you have an essentially unlimited number of 
> 
> objects being mapped to a large but still finite number of hash values.
> 
> 
> 
> 
> 
> 
> 
> -- 
> 
> Steven

Lets check the basic operations of a hash table or so-called a dictionary first.

If the dictionary is implemented toward faster in searching items, 
then it is slightly different in the insertion and the deletion operations of
(key, value) pairs.


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

[RELEASED] Python 3.3.0 beta 2

[Georg Brandl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On behalf of the Python development team, I'm happy to announce the
second beta release of Python 3.3.0 -- a little later than originally
scheduled, but much better for it.

This is a preview release, and its use is not recommended in
production settings.

Python 3.3 includes a range of improvements of the 3.x series, as well
as easier porting between 2.x and 3.x.  Major new features and changes
in the 3.3 release series are:

* PEP 380, syntax for delegating to a subgenerator ("yield from")
* PEP 393, flexible string representation (doing away with the
   distinction between "wide" and "narrow" Unicode builds)
* A C implementation of the "decimal" module, with up to 80x speedup
   for decimal-heavy applications
* The import system (__import__) now based on importlib by default
* The new "lzma" module with LZMA/XZ support
* PEP 397, a Python launcher for Windows
* PEP 405, virtual environment support in core
* PEP 420, namespace package support
* PEP 3151, reworking the OS and IO exception hierarchy
* PEP 3155, qualified name for classes and functions
* PEP 409, suppressing exception context
* PEP 414, explicit Unicode literals to help with porting
* PEP 418, extended platform-independent clocks in the "time" module
* PEP 412, a new key-sharing dictionary implementation that
   significantly saves memory for object-oriented code
* PEP 362, the function-signature object
* The new "faulthandler" module that helps diagnosing crashes
* The new "unittest.mock" module
* The new "ipaddress" module
* The "sys.implementation" attribute
* A policy framework for the email package, with a provisional (see
   PEP 411) policy that adds much improved unicode support for email
   header parsing
* A "collections.ChainMap" class for linking mappings to a single unit
* Wrappers for many more POSIX functions in the "os" and "signal"
   modules, as well as other useful functions such as "sendfile()"
* Hash randomization, introduced in earlier bugfix releases, is now
   switched on by default

In total, almost 500 API items are new or improved in Python 3.3.
For a more extensive list of changes in 3.3.0, see

 http://docs.python.org/3.3/whatsnew/3.3.html (*)

To download Python 3.3.0 visit:

 http://www.python.org/download/releases/3.3.0/

Please consider trying Python 3.3.0 with your code and reporting any bugs
you may notice to:

 http://bugs.python.org/


Enjoy!

(*) Please note that this document is usually finalized late in the release
cycle and therefore may have stubs and missing entries at this point.

- --
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.3's contributors)

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAlAnxVAACgkQN9GcIYhpnLAECACcDeE+N2AfYVnuwMkq682znfDU
ODAAn0J87+MVA9WHEV5iYZd3ub9ZhbpC
=LvY0
-END PGP SIGNATURE-
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Arithmetic with Boolean values

[Paul Rubin]

> which can be simplified to:
> for x in range(len(L)//2 + len(L)%2):

for x in range(sum(divmod(len(L), 2))): ...
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Arithmetic with Boolean values

[Bernd Nawothnig]

On 2012-08-12, Paul Rubin wrote:
>> which can be simplified to:
>> for x in range(len(L)//2 + len(L)%2):
>
> for x in range(sum(divmod(len(L), 2))): ...

nice solution.



Bernd

-- 
"Die Antisemiten vergeben es den Juden nicht, dass die Juden Geist
haben - und Geld." [Friedrich Nietzsche]
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Arithmetic with Boolean values

[Mark Lawrence]

On 12/08/2012 17:59, Paul Rubin wrote:

which can be simplified to:
for x in range(len(L)//2 + len(L)%2):


for x in range(sum(divmod(len(L), 2))): ...



So who's going to be first in with "and thou shalt not count to 4..."?

--
Cheers.

Mark Lawrence.

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

Re: Arithmetic with Boolean values

[Roy Smith]

In article ,
 Mark Lawrence  wrote:

> On 12/08/2012 17:59, Paul Rubin wrote:
> >> which can be simplified to:
> >> for x in range(len(L)//2 + len(L)%2):
> >
> > for x in range(sum(divmod(len(L), 2))): ...
> >
> 
> So who's going to be first in with "and thou shalt not count to 4..."?

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

Re: suggesting a launcher wrapper script for portable python

[Thomas Jollans]

On 08/12/2012 02:49 AM, Gelonida N wrote:
> 
> One minor drawback of my suggested script would be, that a console
> window pops up for a few seconds when starting a .pyw file.

(I'm no expert but) This should be avoidable if you use the Windows
Script Host instead of DOS command scripts to write the launchers.
I.e. use JScript or VBScript to do exactly the same thing. I don't know
much about Windows shortcut (*.lnk) files; if they can contain relative
paths, you could just create shortcuts that launch portable python with
the script.

Thomas


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

Re: lpod-python

[Agon Hajdari]

On Fri, 10 Aug 2012 19:37:16 +0200, Francesco wrote:

> I'm trying to use the lpod-python module to programmatically read data
> from Open Document files. My problem is: i can't download the module
> from its authors' site,
> http://download.lpod-project.org/lpod-python/lpod-python-0.9.3.tar.gz.
> It seems the download site is unavailable, while the main site is
> working.
> I also tried to install the module with pip (I read on the site that
> it's now available), but again, no luck.
> Do somebody know what's happening to download.lpod-project.org ? It
> doesn't even ping...
> 
> Please let me know, thank you very much.
> Francesco

It seems that they are hosting their project at gitorious.org via git. 
Try this: 
git clone git://gitorious.org/lpod-project/lpod-python.git (u need the 
git client of course)

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

Re: suggesting a launcher wrapper script for portable python

[Mark Lawrence]

On 12/08/2012 01:49, Gelonida N wrote:

I just started looking at portable Python and was rather surprised, that
I didn't find any recommended method in the documentation of how to
launch scripts with portable python.
Creating py2exe scripts on ones own USB drive seems to be kind of overkill.

So here my own thoughts / suggestsions.
I'm interestted in feedback of how others use portable pythons
and how they run their scripts from a USB stick.


Let's assume I install portable python on my USB drive and then I'd like
to store self written python scripts on this drive.

It would of course be greate if I could just click on the script and
they'd be started.


However under windows this would not be the case.
The python script would either not be started at all or if the PC had
his own python installed, then the script would be started with the PC's
version of python.

Thus a tiny wrapper script would be needed.


Suggestion:
--
The current directory structore for portable python (2.7) is (assuming
that %PP% is the base directory)

%PP%/Python-Portable.exe   # launches the python interactive shell
%PP%/PyScripter-Portable.exe   # launches some IDE
%PP%/App

Let's assume I add two more directories:
%PP%/myscripts# location of all callable scripts
%PP%/launchers# location with icons one can click on
   # to start the scripts in myscripts




if I wrote a script named %PP%/myscripts/test1.py,
and I created an aproprriate  named %PP%/launchers/test1.bat

then I could just click on test1.bat and the Python script test1.py
would be started. If the wrapper script is written properly, then it can
look at its own base name and call the related python script.

If I dragged and dropped some filenames on the bat file, then they would
be passed to sys.argv of the script.

Running the script from command line would also work and the present
working directory would be preserved (which might be useful in some cases)

If the script name would not be .py, but .pyw then it woudl be started
with pythonw.
T

Below suggested script:



@echo off
REM
=
REM script to start a python file with portable python
REM
=

REM basepath of this .bat file
set basepath=%~dp0

REM create the name of the python file related to this bat file
REM Unfortunately I do not know how to normalyze %pyfile%,
REM so we got stuck with the '..'
set pyfile=%basepath%..\myscripts\%~n0.py

If EXIST "%pyfile%" (
 REM a normal console python file with .py suffix
 "%basepath%\..\App\python.exe" "%pyfile%"  %*
) ELSE (
If EXIST "%pyfile%w" (
 REM a non  console python file with .pyw suffix
 start "" "%basepath%\..\App\pythonw.exe" "%pyfile%w"  %*
) ELSE (
 REM found neither a .py nor a .pyw file
 echo found no python file %pyfile%
)
)
REM
=
REM end of script
REM
=


One minor drawback of my suggested script would be, that a console
window pops up for a few seconds when starting a .pyw file.

This could be avoided by using either a small compiled C-file (which
sounds like overkill though)
or by writing a windows scripting host .wsf file.
However I don't know this well enough to replicate my batch file.
AN article on SO mentions how to write such a script.
However it does not parse command line arguments nor does it
automatically determine the scripts file name.
So any help for creating a .wsf file starting a .pyw file with command
line arguments would be appreciated.



An alternativce approach could be to provide a scipt named
mk_wrapper.bat
If one drags and drops a python script on it, then an apropriate wrapper
file would be created in the launcher directory.

If well done, then this could be implemented such, that the script may
be located in an arbitrary location on the same USB drive.



I think it would be great if the official portable python release
contained some upport for launching scripts.
Perhaps it exists alrady and I just didn't find it?

If not,then I wouldn't mind if my script or a similiar sand a related
README.txt cript were added to the official release



This might be a complete waste of time but can you use the new windows 
launcher described here http://www.python.org/dev/peps/pep-0397/ ???



--
Cheers.

Mark Lawrence.

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

Re: Arithmetic with Boolean values

[Alister]

On Sun, 12 Aug 2012 19:20:26 +0100, Mark Lawrence wrote:

> On 12/08/2012 17:59, Paul Rubin wrote:
>>> which can be simplified to:
>>> for x in range(len(L)//2 + len(L)%2):
>>
>> for x in range(sum(divmod(len(L), 2))): ...
>>
>>
> So who's going to be first in with "and thou shalt not count to 4..."?

Five is right out



-- 
Insanity is the final defense ... It's hard to get a refund when the
salesman is sniffing your crotch and baying at the moon.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Running Python web apps on shared ASO servers?

[Gilles]

On Sun, 12 Aug 2012 07:56:26 +0200, Dieter Maurer
 wrote:
>You should probably read the mentioned forum resources to learn
>details about the Python support provided by your web site hoster.

Yup, but so far, no answer, so I figured someone here might now.

Those articles seem to indicate that CGI isn't a good solution when
mod_python isn't available, so it looks like I'll have to investigate
FastCGI, WSGI, etc.

http://docs.python.org/howto/webservers.html
http://stackoverflow.com/questions/219110/how-python-web-frameworks-wsgi-and-cgi-fit-together

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

Re: Running Python web apps on shared ASO servers?

[Tim Golden]

On 12/08/2012 21:52, Gilles wrote:

On Sun, 12 Aug 2012 07:56:26 +0200, Dieter Maurer
 wrote:

You should probably read the mentioned forum resources to learn
details about the Python support provided by your web site hoster.


Yup, but so far, no answer, so I figured someone here might now.

Those articles seem to indicate that CGI isn't a good solution when
mod_python isn't available


Just to make a point: one person's "isn't a good solution" is another 
person's "works perfectly well for me". Modern servers are really quite 
quick: the cost of starting up a Python process and generating an HTML 
page can be really quite low. I've certainly had low-traffic production 
websites running for years on CGI without anyone complaining.


If speed was an issue or if I thought that I'd be getting more requests 
than I am then I'd consider a more sophisticated solution.


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

Re: in-place exponentiation incongruities

[Terry Reedy]

On 8/12/2012 7:55 AM, Giacomo Alzetta wrote:


What I mean is: when you implement a new type as a C extension you
have to provide special methods through the NumberMethods struct. In
this struct both the power and in-place power operations have three
arguments.


I am not really sure why the latter is true. Probably 'consistency' at 
the special method level, with __pow__. As Steven points out, it is not 
needed to implement normal Python code.


This is one area of Python where the design is a bit messy. I believe 
the very existence of __ipow__ is a matter of consistency than of known 
use cases. Guido was not sure which __ixxx__ would ever be needed (for 
mutable objects), so he just put them all in.


At the Python level, both __pow__ and __ipow__ are also documented in 
the manual as having an optional, third, modulo parameter. __rpow__ is 
defined as binary, but that is a mistake


>>> int.__rpow__(3, 5, 4)
1



Now, suppose I implement the three argument variant of the
in-place power in a class.


Are you actually planning to do this, or is this purely theoretical?


No user would be able to call my C
function with a non-None third argument,


Not true. Whether the function is coded in Python or C
cls.__ipow__(base, exp, mod) # or
base.__ipow__(exp, mod)


while he would be able to
call the normal version with the third argument.


That can also be done directly
>>> int.__pow__(5, 3,  4)
1

--
Terry Jan Reedy

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

Re: suggesting a launcher wrapper script for portable python

[Gelonida N]

Hi Thomas,

On 08/12/2012 09:05 PM, Thomas Jollans wrote:

On 08/12/2012 02:49 AM, Gelonida N wrote:


One minor drawback of my suggested script would be, that a console
window pops up for a few seconds when starting a .pyw file.


(I'm no expert but) This should be avoidable if you use the Windows
Script Host instead of DOS command scripts to write the launchers.
I.e. use JScript or VBScript to do exactly the same thing. I don't know
much about Windows shortcut (*.lnk) files; if they can contain relative
paths, you could just create shortcuts that launch portable python with
the script.



You're absolutely right and I was rather sure, that I posted a link to 
an SO article with a wsf script avoiding this problem.


Only drawback of this script was, that it did not detect the name of 
it's own script and that it did not pass command line arguments down to 
the python script.


Well here is the link: http://preview.tinyurl.com/bu9rda5

The suggested script was:



set WshShell = WScript.CreateObject("WScript.Shell")
CMDFile = "App\\pythonw.exe App\\gui.py"
WshShell.Run CMDFile, 1



The question is how to extend it such, that it detects it's own name 
(nice to have) and that it passes command line args down to python 
(essential)


I know absolutely nothing about windows scripting.













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

Re: suggesting a launcher wrapper script for portable python

[Gelonida N]

On 08/12/2012 09:52 PM, Mark Lawrence wrote:

On 12/08/2012 01:49, Gelonida N wrote:




I think it would be great if the official portable python release
contained some upport for launching scripts.
Perhaps it exists alrady and I just didn't find it?

If not,then I wouldn't mind if my script or a similiar sand a related
README.txt cript were added to the official release



This might be a complete waste of time but can you use the new windows
launcher described here http://www.python.org/dev/peps/pep-0397/ ???



This might be interesting and I have to read a little more.

However on a very first glance I'd assume it had to be stalled on the 
PC, so it would not really be a portable solution (meaning self 
contained on a USB key),that can be executed on any WIndows host.


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

Official reason for omitting inspect.currentcallable() ?

[kj]

Is there an *explicitly stated* reason (e.g. in a PEP, or in some
python dev list message) for why the inspect module (at least for
Python 2.7) does not include anything like a "currentcallable()"
function that would *stably*[1] return the currently executing
callable object?

(It seems unlikely that the absence in the inspect module of anything
even remotely like such a currentcallable is merely an oversight,
considering how many introspection facilities the inspect module
provides.  It seems far more likely that this absence is either
due to some fundamental limitation of Python that makes it impossible
to fully specify such a function, or it is the result of a deliberate
policy against including such a function in inspect.)

Thanks!

[1] By "stably" above I mean, e.g., that the value returned by the
top-level function (object) defined by

def spam():
return inspect.currentcallable()

is *invariant*, in contrast to the value returned by the top-level
function (object) defined by

def ham():
return ham

which is whatever the current value of the 'ham' global happens to
be.

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

Re: ANN: visage (interfaces)

[jwp]

On Sunday, July 29, 2012 10:18:23 PM UTC-7, jwp wrote:
> What's c.l.py's perspective on managing interfaces and implementations?

I pushed another version with support for IID references, so you can refer to 
implementations in annotations. The ultimate point of this is to give registry 
queries the ability to check for implementations with particular features:

@visage.lib.implementation('foo')
class Imp(object):
 def meth(self) -> visage.lib.reference('bar'):
  ...

Imp.meth making a statement that a 'bar' implementation will be returned.

That is, consider code that is not aware of the modules that "Imp" is stored in 
but wants a 'foo' implementation whose "meth" method returns a 'bar' instance. 
Registry queries pave the way for supporting IID based implementation 
resolution. There is also the potential that registry information could be 
extracted on package installation for the purpose of an implementation index. 
Implementations could be imported on demand by modules that have no knowledge 
of the implementation.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: save dictionary to a file without brackets.

[alex23]

On Aug 10, 7:37 pm, Mark Lawrence  wrote:
> Well whatever you do *DON'T* mention Cython. I mentioned it just now but
> I think I've got away with it.

While I'm not against threads straying off topic, you're beginning to
come across as a bit of an asshole now.

Just let it go.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Arithmetic with Boolean values

[Gene Heskett]

On Sunday 12 August 2012 20:27:13 Alister did opine:

> On Sun, 12 Aug 2012 19:20:26 +0100, Mark Lawrence wrote:
> > On 12/08/2012 17:59, Paul Rubin wrote:
> >>> which can be simplified to:
> >> 
> >>> for x in range(len(L)//2 + len(L)%2):
> >> for x in range(sum(divmod(len(L), 2))): ...
> > 
> > So who's going to be first in with "and thou shalt not count to 4..."?
> 
> Five is right out

Can some smart ass (like me) suggest 69!

If it doesn't get summarily tossed, it could take a week or so to run. :-)

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page:  is up!
e-credibility: the non-guaranteeable likelihood that the electronic data
you're seeing is genuine rather than somebody's made-up crap.
-- Karl Lehenbauer
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Does anyone have an activate script for portable python?

[alex23]

On Aug 12, 9:09 am, Gelonida N  wrote:
> In Pythons installed with virtualenv there is on windows an activate.bat
> script, that can be used to setup the cmd-shell such, that the search
> path for python and pythor elated tools (pip / easy_install) is setup
> properly.
> Do such a scripts also exist for Portable python?


Portable Python is just Python with some helper scripts for not
requiring a system installation.

So "command-line-command-to-run-portable-python virtualenv " should be all you need.
-- 
http://mail.python.org/mailman/listinfo/python-list

Python Game Programming Challenge (PyWeek) #15 is coming!

[Richard Jones]

The 15th Python Game Programming Challenge (PyWeek) is coming. It'll
run from the 9th to the 16th of September:

  http://pyweek.org/

The PyWeek challenge:

1. Invites entrants to write a game in one week from scratch either as
an individual or in a team,
2. Is intended to be challenging and fun,
3. Will increase the public body of game tools, code and expertise,
4. Will let a lot of people actually finish a game, and
5. May inspire new projects (with ready made teams!)


Check out the help page for how to compete and the growing resources
message board post:

   http://pyweek.org/s/help/
   http://pyweek.org/d/4008/


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

Re: Official reason for omitting inspect.currentcallable() ?

[Terry Reedy]

On 8/12/2012 7:06 PM, kj wrote:



Is there an *explicitly stated* reason (e.g. in a PEP, or in some
python dev list message) for why the inspect module (at least for
Python 2.7)


2.7 is over two years old. Things have been added to the inspect module 
since. So when asking about 'why feature x is not present', you should 
be asking about 3.3. Enhancement requests should be directed to 3.4.



does not include anything like a "currentcallable()"


3.x include currentframe() (see below), though it is not guaranteed for 
anything other than CPython. 2.x and 3.x have more general functions to 
get the entire call stack. Details are certainly implementation specific.



function that would *stably*[1] return the currently executing
callable object?


The concepts 'callable' and 'executable' are not the same. Callables 
have a .__call__ method that initiates the execution of an executable. 
Python-coded functions have a __call__ method that knows how to initiate 
the execution of the attached (byte)code object that was compiled from 
the Python code. C-coded function wrappers have a __call__ method that 
knows how to initiate the execution of object code compiled from C 
functions. Other implementations have other __call__ methods. Once the 
executable is executing, there is no need for the function and its call 
method.


So getting the current callable has to be indirect frame to code object 
to name to function object looked up in the parent calling frame. A 
direct link would create an unnecessary circular reference.



[1] By "stably" above I mean, e.g., that the value returned by the
top-level function (object) defined by

def spam():
 return inspect.currentcallable()

is *invariant*, in contrast to the value returned by the top-level
function (object) defined by


There have been various proposals and a rejected PEP for accessing 'this 
function' from within a function. I do not know if that particular 
spelling has been proposed or not.




def ham():
 return ham

which is whatever the current value of the 'ham' global happens to
be.

if the def statement is in global scope.

There is no difference unless someone rebind the name, which is normally 
done intentionally, for a purpose. Names do not just randomly mutate.


The advantage of access by name is that if someone, whether the original 
author or not, wraps the function (say to log calls), then the function 
continues to work with the wrapped version.


--
Terry Jan Reedy

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

combine modelformset and inlineformset in django views

[Asif Jamadar]

I have two models

   class A(models.Model):
name = models.CharField(50)
type = models.CharField(50)

   class B(models.Model):
field1 = ForeignKeyField(A)
value = IntegerField()

I need to generate both formsets and inline formsets using the above models.

For class A I will generate model formset, but i'm not getting how to bind 
inline formset for model B to modelformsets

How can I combine both modelformsets from model A and inline formsets  from 
model A and model B on save method in django views?
-- 
http://mail.python.org/mailman/listinfo/python-list