On 4/12/06, Thomas Wouters <[EMAIL PROTECTED]> wrote:
>
> On 4/12/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > Tim Peters quoted Guido:
>
> > - when reload() is used on an extension
>
> > This is trickier: I guess reload should invoke the finalize function,
> > discard the memory for the st
On 4/13/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Occasionally I wonder whether it would be useful
> to have some form of const declaration in the
> language, not to prevent accidental change, but
> so that access to them can be optimised. E.g. in
>
> const GET = 'GET'
>
> def f(address):
>ht
Guido writes:
> the conventional way of treating __add__
> etc. has a different need for resolving conflicts than Phillip Eby's
> idea of requiring strict dominance of the selected solution over all
> other candidates. So now that you mention it I wonder if the whole
> strict dominance requirement
> Guido writes:
>> the conventional way of treating __add__
>> etc. has a different need for resolving conflicts than Phillip Eby's
>> idea of requiring strict dominance of the selected solution over all
>> other candidates. So now that you mention it I wonder if the whole
>> strict dominance requi
Martin v. Löwis replies to my story:
> Or, to make a long story short: there might not be a single next
> best candidate, but multiple, which are mutually equally-good:
> both mpz+object and object+array would match, and neither is
> better than the other.
>
> This is because they only form a parti
On 4/13/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Michael Chermside wrote:
> > my_x = my_mpz + my_array
> >
> > THIS then raises an exception because there is no one dominant
> > definition.
>
> Or, to make a long story short: there might not be a single next
> best candidate, but mul
Michael Chermside wrote:
> But in a more realistic situation, the NumPy folks realize that
> many of their users are doing scientific work and a noticable
> number make use of mpz. (The mpz folks are just wrapping an
> external library so they don't think of these things, but that's
> OK since only
This should be pretty similar to the last time I posted it, but now
it's got an official PEP number. Let me know what you think!
At the moment, I'm only posting this to the Python 3000 list. If you
think I should be posting it to python-dev or python-list (as I would
with other PEPs), let me kno
On 4/12/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 4/12/06, Tim Hochberg <[EMAIL PROTECTED]> wrote:
> > What would happen if 'a+b' was just syntactic sugar for
> > 'operator.add(a,b)', where operator.add was a generic
> > function, instead of the current magic dance involvi
Guido van Rossum wrote:
> Around the same time I also had this scary thought:
>
> What if, instead of adding registries mapping types to functions left
> and right (in pickle, copy, pprint, who knows where else), we had a
> convention of adding __foo_bar__ methods directly to the class dict?
> Thi
OK, so first Guido says he wants people to speculate less, then he says
he wants them to speculate more. Who knows. So, now I speculate more.
I propose that the self argument be removed from method definitions. It
would not be removed from other places, e.g., you'd still use
"self.foo()", bu
[Guido]
>> ...
>> Definitely wild. Reader beware. Now is the time to generate lots of
>> wild ideas and let them sink in. If it still seems a good idea 3
>> months from now we may select it for a code experiment (as opposed to
>> a thought experiment). BTW I want to encourage lots of code
>> experi
Let me update my original thought experiment in a way that (I think)
preserves the current behaviour while also requiring strict dominance.
Let's imagine for a second that we have two new types at the top of the
hierarchy. I'll call them Ultimate and Penultimate. So the inheritance
tree goes l
On Thu, Apr 13, 2006 at 10:07:27AM -0600, Steven Bethard wrote:
> This should be pretty similar to the last time I posted it, but now
> it's got an official PEP number. Let me know what you think!
>
> Identifying Problematic Code
>
>
> This PEP proposes to house this
At 10:34 AM 4/13/2006 -0500, Ian Bicking <[EMAIL PROTECTED]> wrote:
>And even if that wasn't a problem, it means mpz would be eagerly loaded
>along with NumPy even if it wasn't needed. Or if you had to manually
>import this operator.add-glue, then if you forget it is likely to be
>difficult to deb
(...)
> The traditional way of calling superclass methods and getting an unbound
> method should still work. It just won't be symmetric with the way the
> functions are defined. Since this is not the typical way methods are
> called, it seems reasonable.
Using "obj.some_method(blah)" when som
On 4/13/06, Jack Diederich <[EMAIL PROTECTED]> wrote:
> On Thu, Apr 13, 2006 at 10:07:27AM -0600, Steven Bethard wrote:
> > This should be pretty similar to the last time I posted it, but now
> > it's got an official PEP number. Let me know what you think!
> >
> > Identifying Problematic Code
> >
Gustavo Niemeyer wrote:
>>The traditional way of calling superclass methods and getting an unbound
>>method should still work. It just won't be symmetric with the way the
>>functions are defined. Since this is not the typical way methods are
>>called, it seems reasonable.
>
>
> Using "obj.so
I propose that strings (unicode/text) shouldn't be iterable. Seeing this:
i
t
e
m
1
a few too many times... it's annoying. Instead, I propose that strings
get a list-like view on their characters. Oh synergy!
Thus you would do:
for c in a_string.chars():
print
On 4/13/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> I propose that strings (unicode/text) shouldn't be iterable. Seeing this:
>
>
>i
>t
>e
>m
>
>1
>
>
> a few too many times... it's annoying. Instead, I propose that strings
> get a list-like view on their characters.
+1
Ian Bicking <[EMAIL PROTECTED]> wrote:
>
> OK, so first Guido says he wants people to speculate less, then he says
> he wants them to speculate more. Who knows. So, now I speculate more.
>
> I propose that the self argument be removed from method definitions. It
> would not be removed from
On 4/13/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> I propose that strings (unicode/text) shouldn't be iterable.
I understand that there are use cases, but I can't remember seeing one
in real life. I have seen many uses for the container version
x in string
and of course many good uses of
In another thread ("Module Initialization and finalization") reload()
has come up, and some suggestions to improve the reloadability of modules.
I would like to ask: is reloading feasible at all? Right now reload()
works poorly. The builtin reload() can be improved some, but there are
problem
Josiah Carlson wrote:
> Ian Bicking <[EMAIL PROTECTED]> wrote:
>
>>OK, so first Guido says he wants people to speculate less, then he says
>>he wants them to speculate more. Who knows. So, now I speculate more.
>>
>>I propose that the self argument be removed from method definitions. It
>>wou
Ian Bicking <[EMAIL PROTECTED]> wrote:
> I would like to ask: is reloading feasible at all? Right now reload()
> works poorly. The builtin reload() can be improved some, but there are
> problems that cannot ever be resolved in general.
Sure, but there are many simple cases where reload() does i
Ian Bicking <[EMAIL PROTECTED]> wrote:
> I propose that strings (unicode/text) shouldn't be iterable. Seeing this:
>
>
>i
>t
>e
>m
>
>1
>
>
> a few too many times... it's annoying. Instead, I propose that strings
> get a list-like view on their characters. Oh synergy!
>
-1 on removing self from method defs. I always make the opposite
mistake from Ian when moving from Python to C++ or Java. :)
On Thu, 2006-04-13 at 12:59 -0500, Ian Bicking wrote:
> My own interpretation of self-related criticism is that people get
> bothered with all the "self"s from their expe
Giovanni Bajo wrote:
>>Thus you would do:
>>
>> for c in a_string.chars():
>> print c
>
>
> Would this remove __getitem__? I believe I wouldn't want to give up s[0] as
> "the first character in s". That would make a string a thing where you can
> use [3] to access the third character, but
On 13 apr 2006, at 20.01, Ian Bicking wrote:
> I propose that strings (unicode/text) shouldn't be iterable.
> Seeing this:
>
>
>i
>t
>e
>m
>
>1
>
>
> a few too many times... it's annoying. Instead, I propose that
> strings
> get a list-like view on their characters.
Ian Bicking wrote:
> I propose: 'self' and 'cls' implicit arguments. Their presence as the
> first argument to a function or method will be ignored, for backward
> compatibility.
It occurs to me that some of the problems with doing this involve the
fact that you can't know how if a function is
(Cc to python dev, as my question is really about 2.x)
On 4/13/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> ... the self in the signature (and the miscount of arguments
> in TypeError exceptions) ...
Even in the 2.x line, the TypeError messages should be improved.
>>> # No syntax errors w
On Thu, 2006-04-13 at 13:01 -0500, Ian Bicking wrote:
> I propose that strings (unicode/text) shouldn't be iterable.
+1. I think I've mentioned before that we have a particular choke point
that may get scalars or sequences, but that everything coming out of
that choke point is guaranteed to be a
Ian Bicking writes:
> I propose that the self argument be removed from method definitions.
This is not a new proposal. The fundamental problem is a perceived
mismatch between the argument list used for calling and the argument
list used in defining the method. Of the many times that it has been
pr
On Thu, Apr 13, 2006 at 01:39:43PM -0500, Ian Bicking wrote:
> In another thread ("Module Initialization and finalization") reload()
> has come up, and some suggestions to improve the reloadability of modules.
>
> I would like to ask: is reloading feasible at all? Right now reload()
> works poo
On 4/13/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
I propose that the self argument be removed from method definitions. Itwould not be removed from other places, e.g., you'd still use"self.foo()", but the definition for that method would be "def foo():".
Guido already shot this idea down. (It's on
At 12:58 PM 4/13/2006 -0700, Michael Chermside <[EMAIL PROTECTED]> wrote:
>To be abundantly specific, the proposal is that if the next two tokens
>after a "def" were "self" and "." then the result of compiling such
>code would be exactly the same as if they were not present but "self"
>and "," were
Phillip J. Eby wrote:
> At 12:58 PM 4/13/2006 -0700, Michael Chermside <[EMAIL PROTECTED]> wrote:
>
>>To be abundantly specific, the proposal is that if the next two tokens
>>after a "def" were "self" and "." then the result of compiling such
>>code would be exactly the same as if they were not pr
"Steven Bethard" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Thus, for any backwards-incompatible change, two things are required:
>
> * An official Python Enhancement Proposal (PEP)
> * Code that can identify pieces of Python 2.X code that may be
> problematic in Python 3000
"Ian Bicking" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>> Definitely wild. Reader beware. Now is the time to generate lots of
>> wild ideas and let them sink in. If it still seems a good idea 3
>> months from now we may select it for a code experiment (as opposed to
>> a though
On 4/13/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> I propose that strings (unicode/text) shouldn't be iterable. Seeing this:
>
>
>i
>t
>e
>m
>
>1
>
>
> a few too many times... it's annoying. Instead, I propose that strings
> get a list-like view on their characters. Oh
On Mon, 2006-04-10 at 15:19 -0700, Guido van Rossum wrote:
> I've been intermittently following and skipping the Python-3000 list;
> my personal bandwidth just wasn't up to following everything. I know a
> few PEPs have been checked in (thanks Georg!).
>
> I know Adam DePrince has four different p
Another potential generic function use case that occurred to me is the open()
builtin.
If that was extensible, the discussion about providing a nice filesystem path
abstraction in the standard lib wouldn't need to waste any time on the
question of whether or not to inherit from unicode - it wou
Ian Bicking wrote:
> I propose that strings (unicode/text) shouldn't be iterable. Seeing this:
>
>
>i
>t
>e
>m
>
>1
>
>
> a few too many times... it's annoying. Instead, I propose that strings
> get a list-like view on their characters. Oh synergy!
Another +1 here.
On Wed, 2006-04-12 at 05:15 -0700, Michael Chermside wrote:
> Kendall Clark writes:
> > The other choice, of course, is for the library or API to define some
> > variables bound to strings and then use them like constants, except
> > that they can get redefined:
> >
> > @pylons.rest.restrict(GE
Michael Chermside wrote:
> Ian Bicking writes:
>> I propose that the self argument be removed from method definitions.
>
> This is not a new proposal. The fundamental problem is a perceived
> mismatch between the argument list used for calling and the argument
> list used in defining the method. O
Adam DePrince wrote:
> On Wed, 2006-04-12 at 05:15 -0700, Michael Chermside wrote:
>
>> When I see a variable name in all-caps, I don't assign to it. I don't
>> even need a tool like PyChecker to remind me that this is a constant
>> because I've been familiar with the "all-caps == constant" conv
Kendall Clark wrote:
> I don't know if the Ruby syntax for symbols, :foo, will work in
> Python (though I think visually it's a good thing), but it would be
> really nice to have symbols with *some* syntax in Python 3000.
>
> Again, this design request is based on aesthetics and fun: having
47 matches
Mail list logo
