Re: Python is cool!!

[Michael Foord]

On 9 May 2010 20:36, Godson Gera  wrote:

>
>
> On Sun, May 9, 2010 at 6:24 PM, Fuzzyman  wrote:
>
>> On Mar 23, 10:04 pm, geremy condra  wrote:
>> > On Tue, Mar 23, 2010 at 1:07 PM, Tim Golden 
>> wrote:
>> > > On 23/03/2010 16:55, Jose Manuel wrote:
>> >
>>
>> The closest is Skulpt which is very much an incomplete implementation
>> of Python that runs in the browser.
>>
>
> Since you have mentioned Skulpt, take a look at much better pyjamas
> http://pyjs.org/ demos are awesome.
>
>
I'm aware of Pyjamas. It is a Python to Javascript translator and *not* (as
far as I know) capable of running an interpreter in the browser.

Michael



> --
> Thanks & Regards,
> Godson Gera
> IVRS India 
>



-- 
http://www.ironpythoninaction.com/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: [Python-Dev] PEP 384: Defining a Stable ABI

[Michael Foord]

Martin v. Löwis wrote:

It also might make it easier for alternate implementations to support
the same API so some modules could work cross implementation - but I
suspect that's a non-goal of this PEP :).



Indeed :-) I'm also skeptical that this would actually allow
cross-implementation modules to happen. The list of functions that
an alternate implementation would have to provide is fairly long.

  
  

Just in case you're unaware of it; the company I work for has an open
source project called Ironclad.



I was unaware indeed; thanks for pointing this out.

IIUC, it's not just an API emulation, but also an ABI emulation.

  


Correct.


In particular we have had to address the issue of the GIL and extensions
(IronPython has no GIL) and reference counting (which IronPython also
doesn't) use.



I think this somewhat strengthens the point I was trying to make: An
alternate implementation that tries to be API compatible has to consider
so many things that it is questionable whether making Py_INCREF/DECREF
functions would be any simplification.
  


It would actually have been helpful for us, but I understand that it 
would be a big performance hit. The Ironclad garbage collection 
mechanism is described here:


http://www.voidspace.org.uk/python/weblog/arch_d7_2009_01_24.shtml#e1055

We artificially inflate the refcount of all objects that Ironclad 
creates to 2 and hold a reference to them on the .NET side to make them 
ineligible for garbage collection.


Because we can't always know when objects have been decreffed back down 
to 1, there are some circumstances when we have to scan all the objects 
we are holding onto. If their refcount is only 1 then we no longer need 
to hold a reference them. When nothing is using them on the IronPython 
side either normal .NET garbage collection kicks in and the IronPython 
proxy object has a destructor that calls back into Ironclad and uses the 
CPython dealloc method.



So I just ask:
a) Would it help IronClad if it could restrict itself to PEP 384
   compatible modules?
b) Would further restrictions in the PEP help that cause?
  


I've forwarded these questions to the lead developer of Ironclad 
(William Reade) along with a link to the PEP. He isn't on Python-dev so 
I may have to be a proxy for him in discussion. His initial response was 
"looks pretty sweet".


Michael


Regards,
Martin
  



--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog


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

Re: [Python-Dev] PEP 384: Defining a Stable ABI

[Michael Foord]

Martin v. Löwis wrote:

Dino Viehland wrote:
  

Dirkjan Ochtman wrote:


It would seem to me that optimizations are likely to require data
structure changes, for exactly the kind of core data structures that
you're talking about locking down. But that's just a high-level view,
I might be wrong.

  

In particular I would guess that ref counting is the biggest issue here.
I would think not directly exposing the field and having inc/dec ref
Functions (real methods, not macros) for it would give a lot more
ability to change the API in the future.



In the context of optimization, I'm skeptical that introducing functions
for the reference counting would be useful. Making the INCREF/DECREF
macros functions just in case the reference counting goes away is IMO
an unacceptable performance cost.

Instead, such a change should go through the regular deprecation
procedure and/or cause the release of Python 4.0.

  

It also might make it easier for alternate implementations to support
the same API so some modules could work cross implementation - but I
suspect that's a non-goal of this PEP :).



Indeed :-) I'm also skeptical that this would actually allow
cross-implementation modules to happen. The list of functions that
an alternate implementation would have to provide is fairly long.

  


Just in case you're unaware of it; the company I work for has an open 
source project called Ironclad. This *is* a reimplementation of the 
Python C API and gives us binary compatibility with [some subset of] 
Python C extensions for use from IronPython.


http://www.resolversystems.com/documentation/index.php/Ironclad.html

It's an ambitious project but it is now at the stage where 1000s of the 
Numpy and Scipy tests pass when run from IronPython. I don't think this 
PEP impacts the project, but it is not completely unfeasible for the 
alternative implementations to do this.


In particular we have had to address the issue of the GIL and extensions 
(IronPython has no GIL) and reference counting (which IronPython also 
doesn't) use.


Michael Foord



--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog


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

Re: [Python-Dev] Global Python Sprint Weekends: May 10th-11th and June 21st-22nd.

[Michael Foord]

Trent Nelson wrote:
> Following on from the success of previous sprint/bugfix weekends and
> sprinting efforts at PyCon 2008, I'd like to propose the next two
> Global Python Sprint Weekends take place on the following dates:
>
> * May 10th-11th (four days after 2.6a3 and 3.0a5 are released)
> * June 21st-22nd (~week before 2.6b2 and 3.0b2 are released)
>
> It seems there are a few of the Python User Groups keen on meeting
> up in person and sprinting collaboratively, akin to PyCon, which I
> highly recommend.  I'd like to nominate Saturday across the board
> as the day for PUGs to meet up in person, with Sunday geared more
> towards an online collaboration day via IRC, where we can take care
> of all the little things that got in our way of coding on Saturday
> (like finalising/preparing/reviewing patches, updating tracker and
> documentation, writing tests ;-).
>
> For User Groups that are planning on meeting up to collaborate,
> please reply to this thread on [EMAIL PROTECTED] and let every-
> one know your intentions!
>
>   

I should be able to help organise and attend the London contribution. 
Personally I'd like to work on the documentation changes / clean-up for 
the unittest module discussed recently.

Michael Foord

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

[Ann] Voidspace Pythonutils Website Change and Updates

[Michael Foord]

The Voidspace Pythonutil Pages have had a long overdue overhaul. The url 
of the Voidspace Pythonutils homepage has changed. It is now :
http://www.voidspace.org.uk/python/index.html

There are now separate pages for programs, modules, recipes, and CGIs. 
Several of the bigger modules and programs have their own pages.

The following modules have also been updated :
StandOut
Version 2.1.0 6th Jan 2005
http://www.voidspace.org.uk/python/modules.shtml#standout
This simple 'Flexible Output Object' has now been updated to work with 
sys.stderr as well as sys.stdout. It can log them separately or to the 
same file.

StandOut is a simple way of adding 'variable verbosity levels' to your 
program *and* logging, just using normal print commands.

guestbook.py
http://www.voidspace.org.uk/python/cgi.shtml#guestbook
Version 1.2.0 3rd December 2004
The Voidspace Python Guestbook has been updated.
You can now use sendmail instead of smtplib as an option (my current 
host will only allow sendmail).
License change (again!) - now the BSD license.
Changed to use the UTF-8 encoding throughout. We ought to be able to 
accept 'foreign' (non-ascii) entries now.

ConfigObj  
Version 3.2.3 2nd December 2004
Fixes a critical bug and a couple of minor improvements.

ConfigObj is for simple but powerful config file parsing/creation.
Fixed bug in creating non-flatfiles from scratch. (__comments__ 
KeyError). (critical bugfix)
Tuple entries are written out as lists rather than being converted to 
strings.
When an exception is raised, it's no longer printed first.
Added the istrue method.
Changed the license to BSD-License.

As far as I know these are the only substantial changes to modules. A 
few others have had *minor* bugfix updates as well.

Regards,
Fuzzy
http://www.voidspace.org.uk/python/index.shtml
--
http://mail.python.org/mailman/listinfo/python-list

ANN: Python Test Environment

[Michael Foord]

Well sort of... Highly experimental - I'm interested in ways of
improving this.
http://www.voidspace.org.uk/atlantibots/pythonutils.html#testenv
I've created a script that will build a 'test environment'. Windoze(tm)
only as it uses py2exe.
It scans your Python\Lib folder (configurable) and builds a script that
*fakes* an import of every module (along with some boilerplate). This,
more or less, amounts to everything in the standard lib. There is then a
normal setup.py to turn this into a python executable.
The result, is an executable that will run any python script. It gives
sensible values for sys.path, sys.argv and __file__.
This is useful for various purposes :
1) Easily have test environments for multiple versions of python - to
test your scripts.
2) Run any python script on a machine without python installed.
3) Deploying several scripts using py2exe - one build fits all.
Usage :
testenv  arg1 arg2...
Which should be the equivalent of :
python  arg1 arg2...
Sample output :
(Built with Python 2.4 - then 2.3 - prints sys.version first)

D:\New Folder\testenv>testenv test.py arg1 arg2 arg3
2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)]
sys.path = ['D:\\New Folder\\testenv\\library.zip', 'D:\\New
Folder\\testenv', '
D:\\New Folder\\testenv']
sys.argv = ['D:\\New Folder\\testenv\\test.py', 'arg1', 'arg2', 'arg3']
import Tkinter # succeeded
import dummylibrary # succeeded
D:\New Folder\testenv>
##
D:\Python Projects\modules in progress\py2exe-testenv\dist>testenv
test.py arg1
arg2
2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200 32 bit (Intel)]
sys.path = ['D:\\Python Projects\\modules in
progress\\py2exe-testenv\\dist\\lib
\\shared.zip', 'D:\\Python Projects\\modules in
progress\\py2exe-testenv\\dist',
'D:\\Python Projects\\modules in progress\\py2exe-testenv\\dist']
sys.argv = ['D:\\Python Projects\\modules in
progress\\py2exe-testenv\\dist\\tes
t.py', 'arg1', 'arg2']
import Tkinter # succeeded
import dummylibrary # succeeded
D:\Python Projects\modules in progress\py2exe-testenv\dist>
~~~
I'm sure this can be improved in lots of ways - but already useful to
me. Comments and suggestions for improvements welcomed. Thanks go to
Bruno Thoorens for his suggestions so far.
Currently has issues collecting 'sub-packages', but I *think* only the
same issues that py2exe has. Extra modules can just be included
somewhere on sys.path.
Regards,
Fuzzy
http://www.voidspace.org.uk/atlantibots/pythonutils.html
--
http://mail.python.org/mailman/listinfo/python-list

Upgrading Python Article

[Michael Foord]

http://www.voidspace.org.uk/python/articles/upgrading_python.html

I've been looking at whether to upgrade immediately from Python 2.3 to
Python 2.4 or postpone it. This is my first `major version change`, so
I've come up against the usual windoze (tm) problem - upgrading python
breaks all my extension modules.

I've been looking into the issues, what modules do I use, can I
compile them myself ? etc... and the result is a brief article on the
issues round upgrading.

I thought I would share (awww aint that nice).

Flames welcomed.

Regards,


Fuzzy

http://www.voidspace.org.uk/atlantibots/pythonutils.html
-- 
http://mail.python.org/mailman/listinfo/python-list

Bookmark CGI in Python

[Michael Foord]

Anyone written an online bookmarks manager in Python ?

I can knock a simple one together... but wondered if anyone else had
already done it ? I can't find one with google - but htere are *loads*
in perl and PHP, so I suspect thayt someoen must have written one
witrh python. One that uses XBEL would be nice - but it's not that
important.

Regards,

Fuzzy
http://www.voidspace.org.uk/atlantibots/pythonutils.html
-- 
http://mail.python.org/mailman/listinfo/python-list