Brett Cannon wrote:
> This PEP is to change the ``if __name__ == "__main__": ...`` idiom to
> ``if __name__ == sys.main: ...`` so that you at least have a chance
> to execute module in a package that use relative imports.
>
> Ran this PEP past python-ideas. Stopped the discussion there when too
On 4/23/07, Michele Cella <[EMAIL PROTECTED]> wrote:
Calling a method:
self.method(arg)
Calling a super method:
super self.method(arg)
That's consistent with:
* the way you call any other method
* the way you use any other keyword
But how would it *work*? I
Brett Cannon wrote:
>> Someone on python-idea brought up the idea to add the sys module to
>> builtins. The feature would remove the requirement for an extra line and
>> the costs should be minimal or even zero since sys is a special builtin
>> module.
>>
>
> That's a separate PEP.
Do you remembe
> Proposal: Add a __module__ keyword which refers to the module
> currently being defined (executed). (But see open issues.)
>
> if __module__ is sys.main: ... # assuming PEP 3020, Cannon
>
-1 on __module__
I understand PEP 3020 correctly then sys.main will contain the dotted
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Apr 23, 2007, at 9:21 AM, Christian Heimes wrote:
> -1 on __module__
>
> I understand PEP 3020 correctly then sys.main will contain the dotted
> name of the module as *string*.
>
> Also __module__ is already used in objects like classes.
I'm not s
On 4/23/07, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Apr 23, 2007, at 9:21 AM, Christian Heimes wrote:
>
> > -1 on __module__
> >
> > I understand PEP 3020 correctly then sys.main will contain the dotted
> > name of the module as *string*.
> >
On 4/23/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> On 4/23/07, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > On Apr 23, 2007, at 9:21 AM, Christian Heimes wrote:
> >
> > > -1 on __module__
> > >
> > > I understand PEP 3020 correctly then
Steven Bethard wrote:
> Of course, to make it work with packages, you have to write something like::
>
> mod = __import__(__name__)
> for sub_mod_name in __name__.split('.')[1:]:
> mod = getattr(mod, sub_mod_name)
>
> I guess that's not so simple after all.
>
> STeVe
Do you want
On Mon, 23 Apr 2007 08:19:12 -0600, Steven Bethard <[EMAIL PROTECTED]> wrote:
>On 4/23/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
>> On 4/23/07, Barry Warsaw <[EMAIL PROTECTED]> wrote:
>> > -BEGIN PGP SIGNED MESSAGE-
>> > Hash: SHA1
>> >
>> > On Apr 23, 2007, at 9:21 AM, Christian Heimes
That's okay. We won't be able to consider GFs for 3.0a1, but the whole
library reorg thing will be done later, so I expect adding GFs later
(to the library) will also be okay. I do hope that you'll stay with us
while I barrel forward with the ABC PEP. I see no serious
incompatibilities between GFs
At 07:57 AM 4/23/2007 -0700, Guido van Rossum wrote:
>That's okay. We won't be able to consider GFs for 3.0a1, but the whole
>library reorg thing will be done later, so I expect adding GFs later
>(to the library) will also be okay. I do hope that you'll stay with us
>while I barrel forward with the
On 23/04/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> (It occurs to me that I should mention that, just like the relationship
> between 'type' and 'object' rarely matters unless you delve into
> metaclasses or other wizardry, so too am I referring here only to the
> wizard-level aspects of a gen
On 4/22/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> On 4/22/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > PEP: 30XX
> > Title: Access to Module/Class/Function Currently Being Defined (this)
> One thing that isn't clear... You're saying "keywords". So that means
> "__module__" would not be a n
I have two proposals for Python 3000 that I'll write PEP(s) for if
there's interest. The first proposal is, I think, a modest one. The
second proposal is related, but more radical. I fully expect the
second proposal to be rejected for that alone, especially since I am a
relatively an outsider to
At 04:35 PM 4/23/2007 +0100, Paul Moore wrote:
>If the basic stuff really is that simple, I'd love to see just that
>for now. It would put the advanced stuff into context when it finally
>arrived.
Here you go:
from overloading import overload, abstract
def foo(bar, baz):
"""Default
At 11:51 AM 4/23/2007 -0400, Jim Jewett wrote:
>On 4/22/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> > On 4/22/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > > PEP: 30XX
> > > Title: Access to Module/Class/Function Currently Being Defined (this)
>
> > One thing that isn't clear... You're saying
> Replace list() with the BList.
Generally, I like the idea. But how about extension modules
which make use of the current implementation details?
Bill
___
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3
Some years ago, I was allured to convert from Perl to Python.
The main argument was that Python is much more secure.
That turned out to be true with one big exception.
The following lines would run just fine (as equivalent
Perl code)
from cStringIO import StringIO
Inp= StringIO('Guido 10')
for lin
On 4/23/07, Christian Heimes <[EMAIL PROTECTED]> wrote:
> > Proposal: Add a __module__ keyword which refers to the module
> > currently being defined (executed). (But see open issues.)
> -1 on __module__
> Also __module__ is already used in objects like classes.
Yes, I worried that it
On 23/04/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> Here you go:
[...]
> Any questions? :)
No :-)
I really do think that putting this in a PEP as it is, would be a good start.
> That's pretty much it, for the generic function part. The interface part
> looks like the "recombinable interfa
On 4/23/07, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Steven Bethard wrote:
> > Of course, to make it work with packages, you have to write something like::
> > mod = __import__(__name__)
> > for sub_mod_name in __name__.split('.')[1:]:
> > mod = getattr(mod, sub_mod_name)
> >
I like the implementation of the BList, however I'm not so sure whether
replacing a list with BList is a good idea since there are many instances
where python scripts will iterate through endless lists of items. In such
case time complexity (to iterate a whole list) as you have mentioned is O
(nlo
On 4/23/07, Bill Janssen <[EMAIL PROTECTED]> wrote:
> > Replace list() with the BList.
>
> Generally, I like the idea. But how about extension modules
> which make use of the current implementation details?
PyListObject could be moved to the collections module so that C
extension modules can cont
On 4/23/07, Helmut Jarausch <[EMAIL PROTECTED]> wrote:
> Some years ago, I was allured to convert from Perl to Python.
> The main argument was that Python is much more secure.
> That turned out to be true with one big exception.
> The following lines would run just fine (as equivalent
> Perl code)
"Daniel Stutzbach" <[EMAIL PROTECTED]> wrote:
> On 4/23/07, Bill Janssen <[EMAIL PROTECTED]> wrote:
> > > Replace list() with the BList.
> >
> > Generally, I like the idea. But how about extension modules
> > which make use of the current implementation details?
>
> PyListObject could be moved t
"Neville Grech Neville Grech" <[EMAIL PROTECTED]> wrote:
> I like the implementation of the BList, however I'm not so sure whether
> replacing a list with BList is a good idea since there are many instances
> where python scripts will iterate through endless lists of items. In such
> case time com
"Daniel Stutzbach" <[EMAIL PROTECTED]> wrote:
> I have two proposals for Python 3000 that I'll write PEP(s) for if
> there's interest. The first proposal is, I think, a modest one. The
> second proposal is related, but more radical. I fully expect the
> second proposal to be rejected for that a
At 01:37 PM 4/23/2007 -0300, Leonardo Santagada wrote:
>i've thought that the overloading in GF was more for rules like (bar >
>100) and not for diferent types. will both be suported or only the example
>that you gave?
The idea is that it should be possible for third-party implementations to
ad
On 4/23/07, Neville Grech Neville Grech <[EMAIL PROTECTED]> wrote:
> I like the implementation of the BList, however I'm not so sure whether
> replacing a list with BList is a good idea since there are many instances
> where python scripts will iterate through endless lists of items. In such
> case
On 4/23/07, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> "Daniel Stutzbach" <[EMAIL PROTECTED]> wrote:
> > On 4/23/07, Bill Janssen <[EMAIL PROTECTED]> wrote:
> > > > Replace list() with the BList.
> > >
> > > Generally, I like the idea. But how about extension modules
> > > which make use of the c
On 4/23/07, Daniel Stutzbach <[EMAIL PROTECTED]> wrote:
> I have two proposals for Python 3000 that I'll write PEP(s) for if
> there's interest. The first proposal is, I think, a modest one. The
> second proposal is related, but more radical. I fully expect the
> second proposal to be rejected f
On 4/23/07, Daniel Stutzbach <[EMAIL PROTECTED]> wrote:
> So you can see the performance of the BList in more detail, I've made
> several performance graphs available at the following link:
>http://stutzbachenterprises.com/blist/
Very cool. These detailed timings are very useful.
Might it b
On 4/23/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>from overloading import overload, abstract
>
>def foo(bar, baz):
>"""Default implementation here"""
>
>
>@overload
>def foo(bar:int, baz:str):
>"""Overloaded implementation for int/str here"""
>
>
>@abstract
You're right (I was seeing the statistics). Seems that it will outperform
the built in list in most cases then. I would be +1 for both proposals if
there are no underlying integration issues. Great work.
On 4/23/07, Daniel Stutzbach <[EMAIL PROTECTED]> wrote:
On 4/23/07, Neville Grech Neville G
On 4/22/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> On 4/22/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
> > Implementation
> > ==
> >
> > When the ``-m`` option is used, ``sys.main`` will be set to the
> > argument passed in. ``sys.argv`` will be adjusted as it is currently.
> > Th
> Base types should be as simple as possible.
Is that really a good idea? Wouldn't we wind up with BLISS (unsigned
integers)? I think it's always desirable to provide more useful base
types, but that it has to be balanced against conversion and
maintenance costs.
Bill
__
At 11:43 AM 4/23/2007 -0700, Guido van Rossum wrote:
>On 4/23/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> >from overloading import overload, abstract
> >
> >def foo(bar, baz):
> >"""Default implementation here"""
> >
> >
> >@overload
> >def foo(bar:int, baz:str):
> >
On 4/23/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On 4/22/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> > On 4/22/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
> > > Implementation
> > > ==
> > >
> > > When the ``-m`` option is used, ``sys.main`` will be set to the
> > > argument pa
On 4/23/07, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Brett Cannon wrote:
> > This PEP is to change the ``if __name__ == "__main__": ...`` idiom to
> > ``if __name__ == sys.main: ...`` so that you at least have a chance
> > to execute module in a package that use relative imports.
> >
> > Ran this
On 4/23/07, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Brett Cannon wrote:
> >> Someone on python-idea brought up the idea to add the sys module to
> >> builtins. The feature would remove the requirement for an extra line and
> >> the costs should be minimal or even zero since sys is a special b
Bill Janssen <[EMAIL PROTECTED]> wrote:
> > Base types should be as simple as possible.
> Is that really a good idea? Wouldn't we wind up with BLISS (unsigned
> integers)?
With everything, there is a balance. I do not advocate *removing*
functionality to make an object simpler; that would be ab
"Brett Cannon" <[EMAIL PROTECTED]> wrote:
[snip]
> So the questions for people to weigh in on are:
[snip]
> * For ../bacon.py
[snip]
> + Should we walk up the directories until __init__.py is not
> found and check for that directory on sys.path?
> Costly startup, but allows for rel
On 4/23/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On 4/22/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> In other words they are possible if we want to pay the startup cost of
> trying to infer the module's name.
This doesn't need to be a startup cost for python; it can be delayed
until an a
On 4/23/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 11:43 AM 4/23/2007 -0700, Guido van Rossum wrote:
> >On 4/23/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > >@abstract
> > >def spam(fizz):
> > >"""This function has no default implementation, and raises
> > >
Thomas Wouters wrote:
>
> But how would it *work*? I assume you want 'super' to take a single
> expression, and be an expression itself. How does it know which instance
> you want to 'super'? Does it specialcase the variable named 'self'?
> Threat 'everything up to the first dot' as 'the instan
Brett Cannon wrote:
> On 4/23/07, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> Then the import machinery was modified such that if it came across an
>> explicit relative import being made from a module called "__main__", it
>> would check to see if "__module_name__" was set, and if so, use that
>> in
At 04:52 PM 4/23/2007 -0400, Jim Jewett wrote:
>On 4/23/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>>At 11:43 AM 4/23/2007 -0700, Guido van Rossum wrote:
>> >On 4/23/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>
>> > >@abstract
>> > >def spam(fizz):
>> > >"""This function has n
At 11:08 PM 4/23/2007 +0200, Michele Cella wrote:
>My solution is nice (IMHO) for the simplest use case (and, probably, the
>most frequent) but it's behavior is really unclear for these complex use
>cases. Thanks for pointing that out.
>
>As far as I'm concerned, I can only confirm that having a su
On 4/23/07, Mike Klaas <[EMAIL PROTECTED]> wrote:
> On 4/23/07, Daniel Stutzbach <[EMAIL PROTECTED]> wrote:
> > So you can see the performance of the BList in more detail, I've made
> > several performance graphs available at the following link:
> >http://stutzbachenterprises.com/blist/
>
> Ver
On 4/22/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
> This PEP is to change the ``if __name__ == "__main__": ...`` idiom to
> ``if __name__ == sys.main: ...`` so that you at least have a chance
> to execute module in a package that use relative imports.
>
> Ran this PEP past python-ideas. Stopped
On 4/23/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 4/22/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
> > This PEP is to change the ``if __name__ == "__main__": ...`` idiom to
> > ``if __name__ == sys.main: ...`` so that you at least have a chance
> > to execute module in a package that us
On 4/23/07, Daniel Stutzbach <[EMAIL PROTECTED]> wrote:
> On 4/23/07, Mike Klaas <[EMAIL PROTECTED]> wrote:
> > Might it be possible to include variance bars?
>
> I'm not really sure what variance bars would reveal. Performing
> exactly the same operations follows exactly the same code path, so
>
[Guido]
> >(b) I'm proposing an @abstractmethod, which sets its argument's
> >__isabstractmethod__ attribute and then returns it, otherwise
> >unchanged. Would this be good enough for you, or do you need @abstract
> >to do more? My point is, I could rename mine to @abstract so that it
> >would serv
On 4/23/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> But I can't say I particularly like this idea, compared to "super.foo" or
> even "super(self).foo". In fact, the latter invocation doesn't even
> require a keyword -- it just means the compiler needs to include a cell
> variable for the curre
Josiah Carlson wrote:
> I believe that no performance improvement warrants such large scale
> breakage of 3rd party extensions.
If there's an implementation that's deemed superior to what's there now,
then 3.0 is exactly the right time to break 3rd party extensions. Of
course 3.0 isn't a blank che
On 4/23/07, Adam Olsen <[EMAIL PROTECTED]> wrote:
> On 4/23/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > But I can't say I particularly like this idea, compared to "super.foo" or
> > even "super(self).foo". In fact, the latter invocation doesn't even
> > require a keyword -- it just means the
On 4/23/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I'm -1 on this and on any other proposed twiddlings of the __main__
> machinery. The only use case seems to be running scripts that happen
> to be living inside a module's directory, which I've always seen as an
> antipattern. To make me cha
On 4/23/07, Mike Klaas <[EMAIL PROTECTED]> wrote:
> The init-from iterable is especially interesting: a 20% speed increase
> for list comps is not to be scoffed at.
That one is because list()'s tp_new method is PyType_GenericNew
instead of a wrapper around the more efficient PyList_New. Probably
On 4/23/07, Adam Olsen <[EMAIL PROTECTED]> wrote:
> On 4/23/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > I'm -1 on this and on any other proposed twiddlings of the __main__
> > machinery. The only use case seems to be running scripts that happen
> > to be living inside a module's directory,
At 03:16 PM 4/23/2007 -0700, Guido van Rossum wrote:
>On 4/23/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>>Assuming that:
>>
>>1. If you call such a function, it will raise some error, like
>>NotImplementedError
>
>That would be up to the author of the function; they would have to
>explicitly
On 4/23/07, Daniel Stutzbach <[EMAIL PROTECTED]> wrote:
> If a user creates a BList from whole-cloth (e.g., BList(iterable)),
> they will get a best-case BList. This would probably be the common
> case for user's who don't plan to modify their list much.
>
> If a user is doing lots of inserts and
On 4/23/07, Michele Cella <[EMAIL PROTECTED]> wrote:
> ... having a super keyword with methods attached ... doesn't feel right
Agreed. The goal is to *fix* super, not to make it a keyword. Making
it a keyword might -- or might not -- be the way to do that. A
keyword with attributes is probably
On 4/23/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 03:16 PM 4/23/2007 -0700, Guido van Rossum wrote:
> >On 4/23/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> >>Assuming that:
> >>
> >>1. If you call such a function, it will raise some error, like
> >>NotImplementedError
> >
> >That would
On 4/23/07, Adam Olsen <[EMAIL PROTECTED]> wrote:
> On 4/23/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > But I can't say I particularly like this idea, compared to "super.foo" or
> > even "super(self).foo". In fact, the latter invocation doesn't even
> > require a keyword -- it just means the
On 4/23/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 4/23/07, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > I note there's 26 files
> > marked executable and 50 with #!/usr/bin/env python, so there's quite
> > a bit of prior art in the "old way".
>
> Where are these files? If they are directly
On 4/23/07, Adam Olsen <[EMAIL PROTECTED]> wrote:
> The usage patterns can make a big difference there though. A list's
> worst-case is only reached if you have a spike, then drop to just
> above half-full. A BList's worst-case is reached through random
> slicing.
>
> Daniel, does repeated getite
On 4/23/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 4/23/07, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > On 4/23/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > > But I can't say I particularly like this idea, compared to "super.foo" or
> > > even "super(self).foo". In fact, the latter invocati
On 4/23/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
[snip]
> If we're willing to put up with the magic, then it would work to make
> super syntactic sugar for
>
> super(__this_class__, self)
>
> At the moment, I can't see anything wrong with this, but I have a
> feeling I'm missing something abou
At 04:49 PM 4/23/2007 -0700, Guido van Rossum wrote:
>>I suppose there is some value in requiring people to override @abstract
>>methods to make a subclass instantiable, versus merely using the lack of an
>>@abstract class decorator to indicate that a subclass is concrete. But I
>>wonder if being
Ivan Krstic <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
> > I believe that no performance improvement warrants such large scale
> > breakage of 3rd party extensions.
>
> If there's an implementation that's deemed superior to what's there now,
> then 3.0 is exactly the right time to break 3
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
>
> On 4/22/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
> > This PEP is to change the ``if __name__ == "__main__": ...`` idiom to
> > ``if __name__ == sys.main: ...`` so that you at least have a chance
> > to execute module in a package that use rela
On 4/23/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 4/23/07, Michele Cella <[EMAIL PROTECTED]> wrote:
>
> > ... having a super keyword with methods attached ... doesn't feel right
>
> Agreed. The goal is to *fix* super, not to make it a keyword. Making
> it a keyword might -- or might not -- b
On 4/23/07, Calvin Spealman <[EMAIL PROTECTED]> wrote:
> I will +1 on the self.__super__ suggestion. Hey, its very doable and I
> even whipped it up with a simple metaclass, so it would be a tiny
> change to 'type' in order to actually implement it as a standard
> feature. The demonstration is as f
On 4/23/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 04:49 PM 4/23/2007 -0700, Guido van Rossum wrote:
> >>I suppose there is some value in requiring people to override @abstract
> >>methods to make a subclass instantiable, versus merely using the lack of an
> >>@abstract class decorator to i
On 4/23/07, Daniel Stutzbach <[EMAIL PROTECTED]> wrote:
>
> The Radical Proposal
> ---
>
> Replace list() with the BList.
I looked over this patch and have various questions/comments. In
rough priority order:
I'm concerned about the moderately heavy use of macros wrt
Oops, here's the (broken) patch.
Index: Objects/typeobject.c
===
--- Objects/typeobject.c (revision 54928)
+++ Objects/typeobject.c (working copy)
@@ -5625,16 +5625,33 @@
super_init(PyObject *self, PyObject *args, PyObject *kwds)
Collin Winter wrote:
> However, having the AST compiler expand
>
> class A:
> def m(self):
> blah()
> super(self).m()
> blah()
>
> to
>
> class A:
> def m(self):
> super = super_factory(A)
> blah()
> super(self).m()
> blah()
>
I'm sold on the super(self) syntax a
Guido van Rossum wrote:
> On 4/23/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>> At 04:49 PM 4/23/2007 -0700, Guido van Rossum wrote:
I suppose there is some value in requiring people to override @abstract
methods to make a subclass instantiable, versus merely using the lack of an
78 matches
Mail list logo
