I tried to reimplement weakref.WeakValueDictionary as a subclass of
dict. The test passes except for one problem: To compare results
test_weakref.py converts a weakdict to a real dict via dict(weakdict).
This no longer works because PyDict_Merge() does a PyDict_Check() on the
argument and then ignores all overwritten methods. (The old version
worked because UserDict.UserDict was used).
The simplest solution is to replace the PyDict_Check() call with
PyDict_CheckExact(), but this might slow things down too much, because
the fallback code basically does:
for key in iter(arg.keys()):
self[key] = arg.__getitem__(key)
Why can't we use:
for key in iter(arg):
self[key] = arg.__getitem__(key)
instead?
Servus,
Walter
Hi guys,
I've just been putting together a podcasting doodad and have included resuming
support in it. Is this something that's already in the pipeline or should I
abstract it out to urllib and submit a patch?
Dan
>>>>> "Guido" == Guido van Rossum <guido(a)python.org> writes:
Guido> And I just found out (after everyone else probably :-) that YouTube
Guido> is almost entirely written in Python. (And now I can rub shoulders
Guido> with the developers since they're all Googlers now... :-)
Are any other details available? I'm mainly curious to know if they were
using Twisted.
Terry
I looked through the python.org web stats (as I usually do when
preparing for a keynote) and discovered that
/ftp/python/2.5/python-2.5.msi is by far the top download -- 271,971
hits, more than 5x the next one, /ftp/python/2.5/Python-2.5.tgz
(47,898 hits). Are these numbers real? (The byte counts suggest they
are.) What could cause this dramatic popularity of Python on Windows?
Does some vendor have an auto-install hook that installs Python
whenever someone opens up their new computer? Or have we just hit the
jackpot?
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
On 11:17 pm, guido(a)python.org wrote:
>On 12/11/06, Jim Jewett <jimjjewett(a)gmail.com> wrote:
>> On 12/8/06, Guido van Rossum <guido(a)python.org> wrote:
>> > /ftp/python/2.5/python-2.5.msi is by far the top download -- 271,971
>> > hits, more than 5x the next one, /ftp/python/2.5/Python-2.5.tgz
>> > (47,898 hits). Are these numbers real?
>>
>> Why wouldn't it be?
>
>Just because in the past the ratio of downloads for a particular
>version was always about 70% Windows vs. 30% source. Now it seems
>closer to 90/10.
Personally speaking, since switching to Ubuntu, I've been so happy with the speed of releases and the quality of packaged Python that I haven't downloaded a source release from python.org in over a year. If I need packages, they're already installed. If I need source from a release, I 'apt-get source' to conveniently install it from a (very fast) ubuntu mirror. When I need something outside the Ubuntu release structure, it's typically an SVN trunk checkout, not a release tarball.
I don't know what Ubuntu's impact in the general user community has been, but it seems that the vast majority of python developers I interact with on a regular basis have switched. I wouldn't be surprised if this were a major part of the impact.
It's been my pleasure to write the Python-Dev Summaries for the last
year and a half -- 40 summaries all told, 8 of those with Tim Lesher
and 23 with Tony Meyer. It's really been an incredible learning
experience, both in how the Python development process works, and in
how Python as a community interacts.
As I'm now coming up on the last semester of so of my Ph.D., I need to
make some more time to get research done, and so I'm looking to retire
from the summaries. Hence, I'm soliciting for a good replacement (or a
few) who would be willing to pick up the job.
The job takes a few hours about once every two weeks. I have scripts
to automate most of the grunt work (e.g. collecting the threads from
mail.python.org and laying out the summary as necessary for the
website), so the job is pretty much just writing a ReST-formatted
paragraph or two on each topic.
If you've been reading Python-Dev for a while, and you'd like to get
involved, this is a great place to start - I can guarantee you'll
learn a lot from it. Please drop me an email if you're interested!
Thanks,
Steve
--
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
--- Bucky Katt, Get Fuzzy
Hi all,
I have a patch for the fileinput.FileInput class, adding a parameter
to the __init__ method called write_mode in order to specify the write
mode when using the class with the inplace parameter set to True.
Before I submit the patch, I've added a test to the test module, and
noticed that the module is pretty messy, with half of the tests being
run in the module body, and the rest in a large function body.
I propose to refactor the module, moving the tests into a
unittest.TestCase subclass (essentially unchanged, bar changing verify
calls to self.assert_ calls, raise TestFailed(...) to self.fail(...)
etc). I think this will add clarity and modularity to the tests, and
bring them into line with the unittest based test suite used by the
test_file module amongst others (which I'm guessing are substantially
more up to date than test_fileinput).
Any thought?
Cheers,
--
Ant...
Hello all
(A quick google of the python-dev archive didn't turn up any discussions on
this topic. If this has already been discussed, please accept my humble
apologies.)
As part of the Windows Vista release, Microsoft have created the "Windows
SDK" that looks like Platform SDK on steroids. It includes 32-bit and 64-bit
libraries and compilers, debugging tools, etc. and supports Windows XP,
Windows Server 2003 and Windows Vista.
Check the Microsoft Windows SDK Blog for more info:
http://blogs.msdn.com/windowssdk/
Go here for links to ISO and web install:
http://blogs.msdn.com/windowssdk/archive/2006/11/08/windows-sdk-for-windo...
I'm only guessing here, but I think the Windows SDK is probably going to
become the de facto standard for building software on Windows in the absence
of Visual Studio. Has anybody else looked at the Windows SDK yet? Any
thoughts on what needs to be done with distutils so that the Windows SDK can
be supported in Python 2.6?
Cheers,
Albert Strasheim
On Fri Dec 8 08:07:16 CET 2006, Josiah Carlson wrote:
> a Fred <fghaibach at comcast.net> wrote:
> >
> > I'm looking for advice on stripping down Python for an SBC to run Numpy
> > and Scipy. I have the following notes on the system
> >
> > We have code that requires recent versions of Numpy and Scipy.
> > The processor is a 32 bit Sharp ARM Sharp LH7A404 32 bit ARM922TDMI with
> > 32MB of SDRAM.
> > 512 MB flash disk - but 400 MB is reserved for data
> > The OS is Linux
> > only a tty interface is used.
> >
> > Does anyone have a feel as to whether Python for Arm is the correct
> > starting point?
>
> Sounds like plenty of muscle to handle Python certain domain number
> crunching problems.
It appears that this ARM variant doesn't have a floating point coprocessor.
http://www.sharpsma.com/Page.aspx/americas/en/part/LH7A404/
I hope we're dealing with those problem domains here. ;-)
> > What modules can I safely add/strip out?
>
> Most every C module you don't need. You can also compile without
> unicode. I believe you can more or less toss everything except for the
> base python binary and the pythonxy.so (or pythonxy.dll) for your
> platform, but I am most likely wrong.
I found that Python tries to import various modules when it starts up, so
you might want to be a bit conservative with the ones you discard.
However, if the target platform doesn't have libraries that various extension
modules require then there's clearly no point in deploying those extensions.
There are lots of irrelevant modules (for your application, at least) in the
standard library. Anything that's platform-specific can go, apart from any
Linux-specific modules, obviously, and even those might be unnecessary. I'm
not sure if it's possible to automatically strip out Tkinter (lib-tk) and
IDLE (idlelib), but it's probably worth doing so in your case.
I should return to my own experiments and do all that again in a systematic
way, just to see what can be removed.
> My (awful) suggestion: start with
> a Python installation in some user path, like ~/python . Toss
> everything and start adding things that it complains about until it
> starts working again.
Or there's that approach. A module dependency graph would be useful to have,
or even just a list of modules that are required to get to the interactive
prompt.
It might also be worthwhile compiling all the pure Python modules to bytecode
and discarding the sources, but only if the compiled code is smaller, of
course.
> > Will Python take more than 5-6 seconds to load?
>
> I have previously gotten dos versions of Python (I think 1.5 or 1.4) to
> load on a 486 sx 33 with 8 megs of ram in a couple seconds. You
> shouldn't have issues with startup on an ARM.
Less than a second, I would imagine. Extension modules will also increase
the loading time, especially if they need to be perform some tasks when they
start.
> > Will old Python releases, like 1.5.x, work with newer Numpy and Scipy?
>
> I don't know. But you should be able to remove unused portions of
> Python for your platform. There are somewhat recent posts in this
> mailing lists about embedded systems and Python. Others may be able to
> help you more.
It should be possible to compile a version of Python for the ARM922TDMI
that uses Thumb instructions. These are 16 bit instructions that are expanded
on the fly so that they can be processed by the CPU as normal 32 bit wide
instructions. This doesn't mean that the resulting executable and libraries
will be half the size that they would have been when compiled normally, but
you may be able to save some storage space that way. I have no idea whether
this trick will help you save RAM as well.
David
