[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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
