[Python-Dev] New python developer
Hello, I'm using Python for about 2 years, and I would like to go further in python developement. So that's why I've subscribed to python-dev. And since I'm not very good in C, I think I will try to help and to submit patchs in pure python. -- Fabien SCHWOB (and sorry for my english but it's not my mother tongue) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Fix for frame_setlineno() in frameobject.c function
Hello,
This concerns a known bug in the frame_setlineno() function for Python
2.5.x and 2.6.x (maybe in earlier version too). It is not possible to use
this function when the address or line offset are greater than 127. The
problem comes from the lnotab variable which is typed char*, therefore
implicitely signed char*. Any value above 127 becomes a negative number.
The fix is very simple (applied on the Python 2.6.1 version of the source
code):
--- frameobject.c Thu Oct 02 19:39:50 2008
+++ frameobject_fixed.c Fri Dec 05 11:27:42 2008
@@ -119,8 +119,8 @@
line = f->f_code->co_firstlineno;
new_lasti = -1;
for (offset = 0; offset < lnotab_len; offset += 2) {
- addr += lnotab[offset];
- line += lnotab[offset+1];
+ addr += ((unsigned char*)lnotab)[offset];
+ line += ((unsigned char*)lnotab)[offset+1];
if (line >= new_lineno) {
new_lasti = addr;
new_lineno = line;
It would be nice to fix it for Python 2.5 and above, in order to have a
proper MSI installer for Windows.
Best regards,
Fabien Bouleau
DISCLAIMER:
This e-mail contains proprietary information some or all of which may be
legally privileged. It is for the intended recipient only. If an addressing or
transmission error has misdirected this e-mail, please notify the author by
replying to this e-mail. If you are not the intended recipient you must not
use, disclose, distribute, copy, print, or rely on this e-mail.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] bug in urlparse
Hello, I'm using the module urlparse and I think I've found a bug in the urlparse module. When you merge an url and a link like"../../../page.html" with urljoin, the new url created keep some "../" in it. Here is an example : >>> import urlparse >>> begin = "http://www.example.com/folder/page.html"; >>> end = "../../../otherpage.html" >>> urlparse.urljoin(begin, end) 'http://www.example.com/../../otherpage.html' I would more expect the following url : http://www.example.com/otherpage.html It's what is done in most web browser. So I would like to know if it's a bug or not. If it is, I would try to code and to submit a patch. -- Fabien SCHWOB ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bug in urlparse
>> >>> import urlparse >> >>> begin = "http://www.example.com/folder/page.html"; >> >>> end = "../../../otherpage.html" >> >>> urlparse.urljoin(begin, end) >>'http://www.example.com/../../otherpage.html' > You seem to be typing this from memory; the example actually gives a > single set of "../", not two. No, it's a copy of an interactive session using Python 2.4.1. >>I would more expect the following url : >>http://www.example.com/otherpage.html >> >>It's what is done in most web browser. >> >>So I would like to know if it's a bug or not. If it is, I would try to >>code and to submit a patch. > You shouldn't be giving more "../" sequences than are possible. I find > the current behavior acceptable. Ok, so I would try do dev my own fonction. Mainly because on some web pages that I manipulate (for example [1]) there are more "../" than possible. [1] http://linuxfr.org/~pterjan/19252.html -- Fabien SCHWOB ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Divorcing str and unicode (no more implicitconversions).
> FWIW, being French, I don't remember hearing any programmer wish (s)he > could use non-ASCII identifiers, in any programming language. But > arguably translitteration is very straight-forward (although a bit > lossless at times ;-)). > > I think typeability and reproduceability should be weighted carefully. > It's nice to have the real letter delta instead of "delta", but how do I > type it again on my non-Greek keyboard if I want to keep consistent > naming in the program? > > ASCII is ethnocentric, but it probably can be typed easily with every > device in the world. > > Also, as a matter of fact, if I type an identifier with an accented > letter inside, I would like Python to warn me, because it would be a > typing error on my part. > > Maybe this should be an option at the beginning of any source file (like > encoding currently). Or is this overkill? I'm also French and I must say that I agree with you. In my case, the most important thing is to be able to manage the _data_ in the good encoding. I'm currently trying to implement a little search engine in python (to improve my skills mainly) and the biggest problem I have to face is how to manage encoding. Some web pages are in French, in German, in English, etc. and it take me a lot of time to handle this problem correctly. I think it's more useful to be able to manipulate simply the _data_ than to have accents in identifiers. -- Derrière chaque bogue, il y a un développeur, un homme qui s'est trompé. (Bon, OK, parfois ils s'y mettent à plusieurs). ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
> Example 1 (Python 2.x): > --- > > class Foo: > def __init__(self, x): # 1: Explicit 'self' argument > self.x = x # 2: 'self' must be used explicitly > def bar(self, a, b): # 3: There are three arguments... > print self.x + a + b > > Foo(10).bar(20, 30) # ...but only two explicit parameters > #is presented > > This document proposes to change this, as the next example shows: > > Example 2 (Python 3.0): > --- > > class Foo: > def __init__(x): # 1: Implicit self > .x = x # 2: Brief form of: self.x = x > def bar(a, b): # 3: Two arguments... > print .x + a + b > > Foo(10).bar(20, 30) # ...and exactly two parameters In my case, I think that the problem of _self_ is mainly in the method definition. It's a little "hard" to understand why you have to use myFunction(self, otherArgs) when you create a class method. But the use of self in the code of the method is a good thing because it allow you to clearly say that you are working on a class property. In my case, I would like to have the following syntax in Python 3.0 : class Foo: def __init__(x): self.x = x def bar(a, b): print self.x + a + b My 0.2€ ;) -- Fabien SCHWOB ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP and stdlib
Hello, I've often read new PEP that are published, and they are often about new additions to the core language. Why not using them with the standard library. Guido often say that he don't want to include new module that aren't widely used in the community. It's a good thing, but it lead to the creation of a lot of API incompatible modules. Why not using PEP in order to create standard API like the Java world do with JSRs (Java Specification Requests) ? What do you think about that ? -- Fabien ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
