Hello,
As you may have seen, I have recently been granted developer
privileges on python svn.
Let me introduce myself. I am French, 35 years old, and father of 5 children.
I work as a programmer in a fund manager company, and have been
working with python for eight years now.
What I mostly like in python are:
- fun to work with
- its robustness: not only against bugs, but the stability of its
concepts, and the readability of its code base;
- easy to interface with any other system.
To start with python development, I think I will try to help with
python3.0, or picking some bugs in the issue tracker.
I have some knowledge of the python internals, with hours of debugging
sessions of a C++ application mixed with the python interpreter. And I
think I have read almost every svn commit for two years.
I can also help on win32 specific development. As an example, I find
that the distutils module don't work very well with the new compilers.
I won't be of much help on Unix, though.
I also like good and accurate documentation. Even if my english may be
poor sometimes, I can help with writing some parts. Digging in the
code to extract specifications is one of my favourite jobs.
And of course I can help on other subjects if there is some interest.
I am very excited to take part in this great project. So please
forgive me if I do something wrong or too quickly. And your (kind)
remarks will always be welcome.
--
Amaury Forgeot d'Arc
Hello Pythonistas and fellow core developers!
After Amaury introduced himself I've decided that I *have* to take some
time to introduce myself, too.
Hello, my name is Christian Heimes and I'm a 28 years old German from
Aachen. Aachen is a beautiful city about 70km West to Cologne and near
the borders to The Netherlands and Belgium. Some of you may know me from
#python as Crys (|Crys| or Crys_) or my former nick Tiran. Others may
have seen me at some Python related conferences like EuroPython 2003 in
Charleroi/Belgium, 2004+2005 in Gothenburg/Sweden, DZUG 2004 at the
DESY/Hamburg or Plone Conference 2004/Vienna.
Before I'm going to bore you with the (Python) story of my life let me
tell you something about my persona. I'm of average build and average
height but people usually don't describe me as an average guy. Unless
you see the more Metal and Gothic like chap with glasses, chin-beard and
very long hair in black cloths, boots and a hat as ordinary. *g*
When I'm not sitting in front of my box I'm spending time with my
beautiful girl friend, listening to music, my friends or in a disco. I
enjoy cooking but I rarely spend time in front of the TV. I only watch
some well selected series like Myth Busters + LOST and information
channels like ARTE.
My more exotic hobby is Medieval Living History, also known as
Reenactment although we don't take it as serious as Reenacters. I
usually describe it as a counter weight to my science and computer
interests. We are tailoring cloths and living in tents or castles like
people about 1200 to 600 years ago. That is without electricity, mobile
phones and computers as much as it is possible these days. It's like a
vacation from the modern world for a view days or entire week for me.
Now here is the story how Python entered my life:
I had my first real contact with Python in 2002 when some friends and me
were evaluation web frameworks for the relaunch of our community site.
We were all frustrated from our past experiences with PHP and MySQL and
were looking for something innovative and more professional. Quickly we
were brim over with enthusiasm for Zope3 and Python. But Zope3 wasn't
ready in 2002 and the community project went dead after some internal
frictions and lack of time. But I kept learning Python and playing
around with Zope3 and Zope2.
After some Zope related jobs I came in contact with Plone and eventually
became a Plone core developer and elected board member of the newly
formed Plone Foundation. Unfortunately personal and health problems
forced me to drop everything. After things went better again I focused
on other areas like PyQt4, Twisted. C#/.NET and PythonDotNET in order to
broaden my knowledge and learn other techniques beside CMS and web
applications.
I came to Python C development as I worked on PythonDotNET for one of my
projects. Although it might sound strange how a .NET and C# project got
me into C and Python C API but it's easy to explain. In order to fix
PythonDotNET for Python 2.5, Mono and UCS-4 builds of Python I had to
familiarize myself with the C API of Python. The project is a bridge
between CPython and .NET and not related to IronPython. The C# is doing
a lot of calls into the C library using a technology that can be
compared to ctypes. The code jumps forth and back between C, C#/.NET and
Python code. It's a nightmare to debug problems but it's fun, too.
Once I had overcome my fear of Python's C API I saw its elegance and
started to contribute to Python's core. I wrote some patches for Python
3000 because I saw an opportunity to get involved and contribute. And
because I like to play with new stuff ;) After a heap of patches and bug
reports Guido finally granted me developer privileges.
I'm planing to focus my work on Python 3000. I'm a Linux user (10 years
server and 5 years work station experience) but I've a VMWare running to
test patches on Windows XP, too.
Questions? :)
Christian
>>>>> "Guido" == Guido van Rossum <guido(a)python.org> writes:
Guido> I feel left out. I have only one child and I don't qualify as
Guido> 'strange' by any stretch of the imagination... Sometimes I think I'm
Guido> the only regular guy working on Python. ;-)
Ah well, that explains a lot! :-)
Anyone else here think they're normal?
1. You're a programmer
2. You work on Python
3. You're on the dev mailing list (and you read it)
Each one of those must be worth at least one unit of standard deviation.
Terry
Many years ago I implemented a deque type in C (for use in C programs)
using a single dynamically sized array as the underling type, along
with an extra integer to designate where the "start" of the list is.
Somehow, I had always imagined that Python's implementation worked the
same way, but was just looking at the code and found that it uses
doubly-linked lists of 62-item blocks.
I just wanted to toss my approach out there to see if it might offer
better performance and/or simpler code (my pure-C implementation is
only 80 lines of code). If there's interest, I'd be happy to work it
up into a patch. I could also do some performance tests if others
have specific use cases they'd like to see tested. I see the
advantages as follows:
- __getitem__ would take O(1) time instead of O(n)
- Dirt simple implementation
Compared to the existing code, memory allocation/deallocation is less
frequent but more expensive when necessary, working out to O(1)
amortized time (same as the current implementation).
The basic idea is to use a single dynamically sized array (much like
Python's list type). An extra integer points to the start of the
deque within the array, and the data implicitly wraps around the end
of the list back to the beginning. Here's the basic data structure:
struct deque
{
PyObject **obs;
int max_len; /* Number of objects we can store in the deque
before having to reallocate */
int len; /* Number of objects currently in the deque */
int start; /* Where in obs the objects starts */
}
When len == max_len and the user adds an element, we reallocate obs.
Much like Python's list type, this can be done in such a way that
memory allocation takes O(1) amortized time (e.g., by doubling
max_len)..
The start of the list is always obs[start] and the last element of the
list is at obs[(start + len - 1) % max_len]. The nth element of the
list is obs[(start + n) % max_len].
I think an example would be helpful. For illustrative purposes,
suppose we start with max_len=4. Each line is followed by a picture
of the data structure's contents:
>>> x = deque()
{obs = {NULL, NULL, NULL, NULL}, max_len = 4, len = 0, start = 0}
>>> x.extend((1,2,3,4))
{obs = {1, 2, 3, 4}, max_len = 4, len = 4, start = 0}
>>> x.popleft()
{obs = {NULL, 2, 3, 4}, max_len = 4, len = 3, start = 1}
>>> x.append(5)
{obs = {5, 2, 3, 4}, max_len = 4, len = 4, start = 1}
>>> x.popleft()
{obs = {5, NULL, 3, 4}, max_len = 4, len = 3, start = 2}
>>> x.pop()
{obs = {NULL, NULL, 3, 4}, max_len = 4, len = 2, start = 2}
Comments? Thoughts? Would a patch be welcome?
--
Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises LLC
> In my opinion __replace__ should be able to replace multiple fields.
This suggestion is accepted and checked-in. See revision 58975.
Surprisingly, the required signature change results in improved
clarity. This was an all around win.
Raymond
Hi
I have some scripts where this module is used - asyncore, xmlrpc, sgmlop.
Some errors are arriving - memory errors reported by msvc2005 malloc/free.
Where I should report bugs ?
my env: py-2.5- partial cvs, sgmlop either from Frideric-s site or pyxml
- same effect.
tia,
mak
> crucial stuff like __fields__ ... fully
> read-write.
On further thought, I think this is a good idea. Nothing good can come from writing to this class variable.
Suggestion is checked-in in rev 58971. Curiously, it was already documented as read-only (I took the time machine out for a spin).
Raymond
> for efficiency I would prefer to avoid using * to break
> up the sequences generated directly by the database interface.
There are some use cases that would be better served by an alternate design and others that are better served by the current design. For example, it would really suck to have to type-out an an enclosing set of parenthesis to build a named tuple explicitly: opt = StockOption((daysleft/360., strike/100.0, bool(putcall))).
The alternate signature was discussed and rejected previously. See some of the details on previous python-dev posting and in the ASPN recipe discussion: at some length in the ASPN recipe: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/500261
FWIW, the current design does work efficiently with your use case if you use itertools to apply the named tuple cast to large record sets. See the example in the docs: http://docs.python.org/dev/library/collections.html#named-tuple-factory-fun…
Also, fwiw, I've had good success using this starmap() approach in some performance critcal applications.
Almost every class in Python could be subjected to the same discussion. Why doesn't every class and function accept a tuple of args instead of separate, serial arguments. The * operator and starmap() function were provided specifically to address the inter-conversion between the two approaches.
> It would be nice to be able to have default values
This came-up before, but I'll take another look at it this weekend. If it significantly complicates the API or impacts performance, then it is a non-starter; otherwise, I'll put together an implementation and float it on ASPN for comments.
> In my opinion __replace__ should be able to replace multiple fields.
This may be do-able. Will take a look at it. The current design is easily extended for this without impacting performance. The question is whether is makes sense in normal applications to do multiple replacements at once. FWIW, the str.replace function only has one target/replacement pair.
> To me, exec is a last resort
It was a last resort here also. Earlier versions of the recipe used type() but they were less flexible, slower, had crummy error reporting, and were much less clear. The exec version has the advantage of being able to print-out the template so you can see *exactly* what it is doing. I ended-up putting in a lot f field validation to prevent injection attacks (they are also they to provide more actionable error messages).
> crucial stuff like __fields__ and __signature__ fully
> read-write. It feels like those should be read-only properties.
> ... On the other hand, I'm a recovering Java programmer,
Welcome to the Python world of consenting adults. These fields could be made read-only but that is just a matter of taste. Looking through the standard library, you'll see making attributes read-only is not the typical practice. If users demand it, I don't see a problem with it, but until then, I don't see a reason to unnecessarily complicate and slow-down the code.
FWIW, you're welcome to email me directly. I've been getting tons of user feedback and have already incorporated the better suggestions. Also, the recipe itself is a combination of the best of prior attempts. Unfortunately, each of several commenters revisit everything from scratch and propose their own complete rewrites that ignore the requests and commments of all those who preceded them. Fortunately, we're homing in on a darned good tool.
Raymond