Introduction and request for commit access to the sandbox.
Hello, As some of you may already know, I will be working on Python for this year Google Summer of Code. My project is to merge the modules with a dual C and Python implementation, i.e. cPickle/pickle, cStringIO/StringIO and cProfile/profile [1]. This project is part of the standard library reorganization for Python 3000 [2]. And my mentor for this project is Brett Cannon. So first, let me introduce myself. I am currently a student from Quebec, Canada. I plan to make a career as a (hopefully good) programmer. Therefore, I dedicate a lot of my free time contributing to open source projects, like Ubuntu. I, recently, became interested by how compilers and interpreters work. So, I started reading Python's source code, which is one of the most well organized and comprehensive code base I have seen. This motivated me to start contributing to Python. However since school kept me fairly busy, I haven't had the chance to do anything other than providing support to Python's users in the #python FreeNode IRC channel. This year Summer of Code will give me the chance to do a significant contribution to Python, and to get started with Python code development as well. With that said, I would to request svn access to the sandbox for my work. I will use this access only for modifying stuff in the directory I will be assigned to. I would like to use the username "avassalotti" and the attached SSH2 public key for this access. One last thing, if you know semantic differences (other than the obvious ones) between the C and Python versions of the modules I need to merge, please let know. This will greatly simplify the merge and reduce the chances of later breaking. Cheers, -- Alexandre .. [1] Abstract of my application, Merge the C and Python implementations of the same interface (http://code.google.com/soc/psf/appinfo.html?csaid=C6768E09BEF7CCE2) .. [2] PEP 3108, Standard Library Reorganization, Cannon (http://www.python.org/dev/peps/pep-3108)
I have added your key. As we have a strict first.last account policy, I named it alexandre.vassalotti; please correct me if I misspelled it.
Somebody noticed on c.l.p that, for cPickle, a) cPickle will start memo keys at 1; pickle at 0 b) cPickle will not put things into the memo if their refcount is 1, whereas pickle puts everything into the memo. Not sure what you'd consider obvious, but I'll mention that cStringIO "obviously" is constrained in what data types you can write (namely, byte strings only), whereas StringIO allows Unicode strings as well. Less obviously, StringIO also allows py> s = StringIO(0) py> s.write(10) py> s.write(20) py> s.getvalue() '1020' Regards, Martin
On 5/21/07, "Martin v. Löwis" <martin@v.loewis.de> wrote:
Thanks!
Noted. I think I found the thread on c.l.p about it: http://groups.google.com/group/comp.lang.python/browse_thread/thread/68c72a5...
Yes. I was already aware of this. I just hope this problem will go away with the string unification in Python 3000. However, I will need to deal with this, sooner or later, if I want to port the merge to 2.x.
That is probably due to the design of cStringIO, which is separated into two subparts StringI and StringO. So when the constructor of cStringIO is given a string, it builds an output object, otherwise it builds an input object: static PyObject * IO_StringIO(PyObject *self, PyObject *args) { PyObject *s=0; if (!PyArg_UnpackTuple(args, "StringIO", 0, 1, &s)) return NULL; if (s) return newIobject(s); return newOobject(128); } As you see, cStringIO's code also needs a good cleanup to make it, at least, conforms to PEP-7. -- Alexandre
On 5/22/07, Alexandre Vassalotti <alexandre@peadrop.com> wrote:
As you see, cStringIO's code also needs a good cleanup to make it, at least, conforms to PEP-7.
Alexandre, It would be great if you could break up unrelated changes into separate patches. Some of these can go in sooner rather than later. I don't know all the things that need to be done, but I could imagine a separate patch for each of: * whitespace normalization * function name modification * other formatting changes * bug fixes * changes to make consistent with StringIO I don't know if all those items in the list need to change, but that's the general idea. Separate patches will make it much easier to review and get benefits from your work earlier. I look forward to seeing your work! n
I have added your key. As we have a strict first.last account policy, I named it alexandre.vassalotti; please correct me if I misspelled it.
Somebody noticed on c.l.p that, for cPickle, a) cPickle will start memo keys at 1; pickle at 0 b) cPickle will not put things into the memo if their refcount is 1, whereas pickle puts everything into the memo. Not sure what you'd consider obvious, but I'll mention that cStringIO "obviously" is constrained in what data types you can write (namely, byte strings only), whereas StringIO allows Unicode strings as well. Less obviously, StringIO also allows py> s = StringIO(0) py> s.write(10) py> s.write(20) py> s.getvalue() '1020' Regards, Martin
On 5/21/07, "Martin v. Löwis" <martin@v.loewis.de> wrote:
Thanks!
Noted. I think I found the thread on c.l.p about it: http://groups.google.com/group/comp.lang.python/browse_thread/thread/68c72a5...
Yes. I was already aware of this. I just hope this problem will go away with the string unification in Python 3000. However, I will need to deal with this, sooner or later, if I want to port the merge to 2.x.
That is probably due to the design of cStringIO, which is separated into two subparts StringI and StringO. So when the constructor of cStringIO is given a string, it builds an output object, otherwise it builds an input object: static PyObject * IO_StringIO(PyObject *self, PyObject *args) { PyObject *s=0; if (!PyArg_UnpackTuple(args, "StringIO", 0, 1, &s)) return NULL; if (s) return newIobject(s); return newOobject(128); } As you see, cStringIO's code also needs a good cleanup to make it, at least, conforms to PEP-7. -- Alexandre
On 5/22/07, Alexandre Vassalotti <alexandre@peadrop.com> wrote:
As you see, cStringIO's code also needs a good cleanup to make it, at least, conforms to PEP-7.
Alexandre, It would be great if you could break up unrelated changes into separate patches. Some of these can go in sooner rather than later. I don't know all the things that need to be done, but I could imagine a separate patch for each of: * whitespace normalization * function name modification * other formatting changes * bug fixes * changes to make consistent with StringIO I don't know if all those items in the list need to change, but that's the general idea. Separate patches will make it much easier to review and get benefits from your work earlier. I look forward to seeing your work! n
participants (3)
-
"Martin v. Löwis" -
Alexandre Vassalotti -
Neal Norwitz