On 3/23/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> When I was just first learning Python I thought this would work:
>
>for item in select_results:
>...
>else:
>... stuff when there are no items ...
>
> But it doesn't work like that.
On 3/23/06, Brett Cannon <[EMAIL PROTEC
On 3/24/06, Tim Peters <[EMAIL PROTECTED]> wrote:
> [Nicola Larosa]
> > ... I sometimes may have had a need for the current semantics
> > of the else after loops, but I don't remember it; on the other hand, I have
> > had a use for the no-iteration case a number of times. Somehow I find it
> > hard
On 3/24/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> I'm well aware that Python 3000 doesn't aim to be backwards compatible,
> but I would prefer if we could refrain from subtly changing the behaviour
> of existing constructs in way that breaks all existing use, and makes it un-
> necessarily har
Guido van Rossum wrote:
> Python 3000 *will* be backwards incompatible, and sometimes it will be
> awkward to convert code. The question I lay in front of the community
> is, how much incompatibility can we handle? And what will the
> transition strategy be? Someone needs to own this discussion top
On 3/26/06, Adam DePrince <[EMAIL PROTECTED]> wrote:
> I have a draft PEP and an implementation of mutable iterators for lists
> and dicts that supports delete only.
>
> The PEP (Mutable Iterations) and sample code can be found at:
>
> http://www.deprince.net/ideas/peps.html
I think the PEP really
with Backwards-Incompatible Changes
Version: $Revision$
Last-Modified: $Date$
Author: Steven Bethard <[EMAIL PROTECTED]>
Status: Draft
Type: Informational
Content-Type: text/x-rst
Created: 03-Mar-2006
Post-History: 03-Mar-2006
Abstract
This PEP describes the procedure for changes to
On 3/27/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
> Requiring code that can identify things in 2.x that will change in 3.0
> that are coded externally from the interpreter is going to be *really*
> difficult in some situations, if not impossible to get right. Just
> look at dict.items(); how do
On 3/27/06, Aahz <[EMAIL PROTECTED]> wrote:
> On Mon, Mar 27, 2006, Steven Bethard wrote:
> >
> > Abstract
> >
> >
> > This PEP describes the procedure for changes to Python that introduce
> > backwards incompatible changes between the Py
On 3/27/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Some years ago there was a long discussion about extending
> the for-loop to express parallel iteration over a number
> of iterables, which ended with the conclusion that such
> an extension was syntactically impossible, and the creation
> of zip(
On 3/28/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I like your strawman: if incompatibilities or synergy
> don't require it to go into Py3k, let's propose it for 2.x.
Yeah, I think this makes a lot of sense - and we should probably
document it somewhere. Do you want this in the Backwards-I
On 4/8/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> To me an AST access feature would only be useful for changing the "VM" that
> Python code runs on. For example, there is an object-relational mapper out
> there (I think it's Robert Brewer's DejaVu system) that takes Python
> generator express
On 4/10/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Are there other proto-PEPs being worked on? I would appreciate if the
> authors would send me a note (or reply here) with the URL and the
> status.
This is the Backwards Incompatibility PEP discussed earlier. I've
submitted it for a PEP nu
On 4/11/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Steven Bethard wrote:
> > This is potentially a Python 2.6 PEP, but it has some optional
> > extensions for Python 3000 and may be relevant to the
> > adaptation/overloading/interfaces discussion. It proposes a m
On 4/11/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I wish the community efforts for Python 3000 were focused more on
> practical things like the effects of making all strings unicode,
> designing a bytes datatype, a new I/O stack, and the view objects to
> be returned by keys() etc. These th
s), let me know.
PEP: 3002
Title: Procedure for Backwards-Incompatible Changes
Version: $Revision: 45366 $
Last-Modified: $Date: 2006-04-13 07:36:24 -0600 (Thu, 13 Apr 2006) $
Author: Steven Bethard <[EMAIL PROTECTED]>
Status: Draft
Type: Process
Content-Type: text/x-rst
Created: 03-Mar-2006
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!
> >
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
[Talin]
> 1) I don't know if this is already on the table, but I sure would like
> to be able to have more options as far as mixing positional and
> keyword arguments.
I thought it might be useful to look at a few places where we
currently have to do some hackery to get the function signature we
w
On 4/18/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> PS: if this change to the class statement were to happen, the crowd
> discussing the 'make' PEP (which I don't like but don't have the power
> to stop being discussed) should take notice.
If you pronounce it dead, I can make sure the discus
On 4/19/06, Boris Borcic <[EMAIL PROTECTED]> wrote:
> BTW, what about replacing the geeky and arguably lengthy keyword
> "lambda" with either :
>
> given- much clearer and slightly more concise; or
> ? - slightly clearer and much more concise ?
Guido's already said that lambda will st
Guido van Rossum wrote:
> OTOH mathematicians (whether in high school or not) write things like
> {x | 2 < x < 10}, which is of course the origin of our list
> comprehensions and generator expressions. Therefor I think it makes
> sense that {F(x) for x in S if P(x)}, ough to be valid syntax if we
>
On 4/24/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> Greg Wilson wrote:
>
> >I'm sure we can work something out --- I agree, {} for empty set and {:}
> >for empty dict would be ideal, were it not for backward compatibility.
> >
[snip]
> Further, punctuation approaches face uncomfortable choic
On 4/26/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> ... the dict constructor signature is
> already too far overloaded, giving a different meaning to keyword
> args, and distinguishing between a mapping and a sequence is iffy: it
> requires a "keys" method which is kind of sub-optimal compare
On 4/27/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> [pep-3100 checkin]
> > {F(x) for x in S if P(x)} means set(F(x) for x in S if P(x)).
>
> I presume this means that there will never be dictionary
> comprehensions (as they would aspire to have an identical
> notation).
Why would that be n
On 4/27/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Phillip J. Eby wrote:
>
> > And thanks to the time machine, str.join('', seq) does this already:
> >
> > Python 2.2.2 (#1, Feb 24 2003, 19:13:11)
> > [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2
> > Type "help", "copyright", "credits"
On 4/28/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> {} however, can appear only standalone. It is not permitted for it to follow
> an expression. If we change that, we can use it to support an alternate
> invocation syntax for functions that currently expect an iterable as their
> first argument.
On 4/29/06, Rudy Rudolph <[EMAIL PROTECTED]> wrote:
> One thing that has always bothered me about Python is the lack of in-out
> parameters. Python is such a wonderful object-oriented language, but it lacks
> this feature that nearly every language has. Maybe we can fix this in 3.0.
-1 since I can
On 4/27/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I just read PEP 3002 and while I like most of what I see (thanks
> Steven Bethard!) there's one section that stands out as problematic.
[snip]
> Rather than a version of Python
> 3000, I suggest to add such warning
On 5/1/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 4/29/06, Steven Bethard <[EMAIL PROTECTED]> wrote:
> > Yes, I think it definitely makes more sense to make the modifications
> > on 2.x. I was hesitant to require integrating it into the main-line
> &
On 5/8/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> Perhaps then, if we get rid of callable()/PyCallable_Check() it would be
> useful to add a NotCallableError (as a subclass of TypeError?) that
> would get thrown should you try to call something that's not callable.
> The argument to the exceptio
On 5/8/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 5/8/06, Steven Bethard <[EMAIL PROTECTED]> wrote:
> > It'd certainly be nice to be able to tell the difference between
> > the following two TypeErrors:
> >
> > >>> def s():
> &g
On 5/11/06, Talin <[EMAIL PROTECTED]> wrote:
> sequence( indexable ):
> -- an indexable in which the indexes are successive integers
> -- Test: isinstance( index_type, int )
I think as of Python 2.5, this should be hasattr(index_type, '__index__'), no?
> mapping( indexable ):
> -- an
On 5/11/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> In other words, I mean that if most people saw something like this in
> "What's new in Python 3.0", I don't think they would freak out:
>
> """Removal of __magic__ attributes
>
> Special attribute names like '__iter__' have been replaced with
On 5/19/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> As a quick data point, I showed around your "dict[str, str|int]"
> example to some friends, all of whom have done a decent amount of
> coding in Python. I gave them some background, including that this was
> an example of type parameterization.
On 5/20/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I've already addressed Steve's other issues. The blogs have the use cases etc.
I'm sorry, I guess I'm just dense, but here's the blogs I've read:
http://www.artima.com/weblogs/viewpost.jsp?thread=85551
http://www.artima.com/weblogs/viewpos
On 5/20/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 5/20/06, Steven Bethard <[EMAIL PROTECTED]> wrote:
> > And the only use-cases I could extract are:
[snip]
> > * function overloading[1]. I think Philip J. Eby had some interesting
> > thought
On 5/20/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> On 5/20/06, Steven Bethard <[EMAIL PROTECTED]> wrote:
> > I wandered around
> > http://oakwinter.com/code/typecheck/
> > but couldn't find any discussion about the implications of, say,
> >
On 5/20/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 5/20/06, Steven Bethard <[EMAIL PROTECTED]> wrote:
> > I guess in the end, I'm still a little confused at why we're having a
> > syntax discussion now. If type annotations are just an extra
> &g
On 5/30/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
> So, first step in my mind is settling if we want to add one more depth to
> the stdlib, and if so, how we want to group (not specific groupings, just
> general guidelines).
I think that having a package level that exactly matches the divisions
[Steven Bethard]
> I think that having a package level that exactly matches the divisions
> in the Library Reference (http://docs.python.org/lib/lib.html) would
> be great.
[Jim Jewett]
> Are there any *dis*agreements with this?
[Terry Reedy]
> It is certainly a good starting poin
I'd like to suggest that we (at least briefly) re-consider the
decision that iterating over a mapping generates the keys, not the
(key, value) pairs. This was addressed somewhat in `PEP 234`_, with
the pros and cons basically being:
* From a purity standpoint, iterating over keys keeps the symmet
On 6/8/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> I think I've come across a use case for @decorators
> on assignment statements.
>
> I have a function which is used like this:
>
>my_property = overridable_property('my_property', "This is my property.")
>
> However, it sucks a bit to have to w
BJörn Lindqvist wrote:
> I have often wanted something similar to that for global
> variables, instead of the global declaration:
>
> cache = None
> def init():
> if not global.cache:
> global.cache = init_cache()
Redirected since this seemed like a Python 3000 kind of request. I
like
On 6/30/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 6/30/06, Steven Bethard <[EMAIL PROTECTED]> wrote:
> > BJörn Lindqvist wrote:
> > > I have often wanted something similar to that for global
> > > variables, instead of the global declaration:
On 6/30/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 6/30/06, Steven Bethard <[EMAIL PROTECTED]> wrote:
> > On 6/30/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > On 6/30/06, Steven Bethard <[EMAIL PROTECTED]> wrote:
> > > >
On 7/8/06, Calvin Spealman <[EMAIL PROTECTED]> wrote:
> Just throwing this out there, but I would love to see a complete
> dropping of container literals from Python. That is why I proposed the
> coercion syntax (ex: list from something) because it would allow
> things like list(1, 2, 3)
I don't s
On 7/10/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Currently, this is valid:
>
> a = {'a': 1, 'a': 2}
> print a # {'a': 2}
>
> I wonder if we shouldn't make this a run-time error instead.
If it's possible, definitely. That's gotta be a typo if it appears in
real code.
> If people
[Guido van Rossum]
> I propose to take the same approach as for callable: if it has
> __hash__ we consider it hashable even though the hash may fail
[Greg Ewing]
> Fair enough, although since object has __hash__
> we end up concluding that everything is
> hashable except when it isn't. :-)
[Guido
On 7/27/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 7/27/06, Steven Bethard <[EMAIL PROTECTED]> wrote:
> > If I understand the problem right, the reason for not wanting to
> > remove __hash__ from object is that it's often convenient to have a
> >
On 7/27/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> So how about we change callable() and add hashable(), iterable() and
> whatever else makes sense so that these all become like this:
>
> def callable(x):
> return getattr(x, "__call__", None) is not None
>
> This way classes can explic
On 7/27/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > So how about we change callable() and add hashable(), iterable() and
> > whatever else makes sense so that these all become like this:
> >
> > def callable(x):
> > return getattr(x, "__call__", None) is not None
>
On 7/27/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 7/27/06, Steven Bethard <[EMAIL PROTECTED]> wrote:
> > [1] It might get you something for __hash__() if object.__hash__() is
> > not removed, but that debate still seems to be in progress and I'm n
On 7/28/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Steven Bethard wrote:
>
> > I thought about this for a while, and I think maybe a good rule of
> > thumb (and something like what Python seems to follow) is: "If it's
> > there's an obvious defau
On 8/13/06, Talin <[EMAIL PROTECTED]> wrote:
> One of the items in PEP 3100 is getting rid of unbound methods. I want
> to explore a heretical notion, which is getting rid of bound methods as
> well.
I believe you're suggesting that the code that I just wrote moments
ago would stop working::
On 8/14/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I believe the PEP doesn't address the opposite use case: positional
> arguments that should *not* be specified as keyword arguments. For
> example, I might want to write
>
> def foo(a, b): ...
>
> but I don't want callers to be able to cal
On 8/14/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 8/14/06, Steven Bethard <[EMAIL PROTECTED]> wrote:
> > On 8/14/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > I believe the PEP doesn't address the opposite use case: positional
> >
[Steven Bethard]
> It would be really nice in the example above to mark ``self`` in
> ``__call__`` as a positional only argument.
[Nick Coghlan]
> However, I'm also wondering if we need an actual syntax, or if a simple
> convention would do the trick: start the names of position
On 8/23/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 8/23/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> > I agree with Tim -- if we have to get rid of one of them, let's get
> > rid of index/rindex and keep find/rfind. Catching the exception is
> > much less convenient than testing for -1.
On 8/23/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> Where it comes to the library, I think we ought to concentrate on
> reducing duplication. TOOWTDI. Get rid of the User* modules.
Generally a good idea, but we still need somewhere to put DictMixin.
It's too bad you can't just use the unbound
On 8/23/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> I agree with Tim -- if we have to get rid of one of them, let's get
> rid of index/rindex and keep find/rfind. Catching the exception is
> much less convenient than testing for -1.
Could you post a simple example or two? I keep imagining thin
Steven Bethard wrote:
> Could you post a simple example or two?
Josiah Carlson wrote:
> index = text.find(...)
> if index >= 0:
> ...
>
[snip]
> index = 0
> while 1:
> index = text.find(..., index)
> if in
On 8/23/06, Jack Diederich <[EMAIL PROTECTED]> wrote:
> On Wed, Aug 23, 2006 at 02:18:59PM -0700, Guido van Rossum wrote:
> > Here's the patch (by Hasan Diwan, BTW) for people's perusal. It just
> > gets rid of all *uses* of find/rfind from Lib; it doesn't actually
> > modify stringobject.c or unic
A couple Python-3000 threads [1] [2] have indicated that the most
natural use of zip() is with sequences of the same lengths. I feel
the same way, and run into this all the time. Because the error would
otherwise pass silently, I usually end up adding checks before each
use of zip() to raise an e
On 8/30/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> Until now, there have been zero requests for zip() to have exception
> raising behavior.
>
> For Python 3k, I recommend:
> * simply replacing zip() with itertools.izip()
> * keeping the zip_longest() in a separate module
> * punting on an e
On 8/30/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> Steven Bethard wrote:
>
> >A couple Python-3000 threads [1] [2] have indicated that the most
> >natural use of zip() is with sequences of the same lengths. I feel
> >the same way, and run into this all the
On 8/30/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> >If changing zip()'s behavior to match the most common use case is
> >totally out, the stdlib code at least argues for adding something like
> >itertools.izip_exact().
>
> I open to that.
>
> For this time being, let's do this. Add itertoo
On 9/12/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> Ron Adam wrote:
> >Maybe "input" can be depreciated in 2.x with a messages to use
> >eval(raw_input())
> >instead. That would limit some of the confusion.
>
> Let me take this opportunity to articulate a principle that I hope this
> group
On 10/13/06, Talin <[EMAIL PROTECTED]> wrote:
> The problem with 'nonlocal' is not that it's confusing, but that it's
> ugly. And my guess is that there will be enough others that share the
> same sentiment that adopting the word will be difficult.
Not at all. Community sentiment about syntax is
Guido wrote:
> My personal preference is still to abuse 'global' instead of adding a
> new, ugly keyword. That would make the syntax for global and nonlocal
> completely identical. :-) But I seem to be alone in this preference.
Brett wrote:
> Seeing Guido have a sad face is enough to force me to h
On 11/1/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
> I think a fairer survey example would be something like this:
>
> n = 1
> def f():
> n = 2
> def g():
> global n = 99
> return n
> g()
>
> f()
> print n
>
> Which 'n' do you expect g
On 11/14/06, George Sakkis <[EMAIL PROTECTED]> wrote:
> Given the overly negative reaction to a base iterator type, I withdraw
> the part of my proposal that suggests this type as the base of all
> iterators. Instead I propose a builtin Iter (or even better iter, if
> there is no objection to chang
On 11/15/06, tomer filiba <[EMAIL PROTECTED]> wrote:
> i understand there's a green light for class decorators in py3k,
> so i wanted to give the issue a slight push.
If you haven't already, you should look at PEP 359, which tried to
address many of the same use-cases and was withdrawn after feedb
On 11/15/06, tomer filiba <[EMAIL PROTECTED]> wrote:
> i understand there's a green light for class decorators in py3k,
> so i wanted to give the issue a slight push.
"Steven Bethard" <[EMAIL PROTECTED]> wrote:
> FWIW, most of the arguments against PEP 359 were
On 11/16/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> but here's some abuse that I couldn't help chuckling
> over. No need to even bother constructing a class, but don't forget that
> 'return locals()' at the end! (not that I'm advocating its [ab]use,
> just something that made me smile)
>
> -
On 11/22/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Examples that keep recurring are things like the
> smtplib.SMTP.sendmail() method, whose second argument
> is either a string or a list of strings.
[snip]
> Rewriting this as a generic method
[snip]
> sounds like a total waste of time and c
On 11/22/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 09:42 AM 11/22/2006 -0700, Steven Bethard wrote:
> >Yeah, it certainly seems like in both this case and the string case,
> >there needs to be some shorthand for saying "implements all the basic
> >String/N
On 11/22/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Steven Bethard wrote:
> > So I would have expected something like:
> >
> > str.lower[MyStringType] = MyStringType.lower
> > str.split[MyStringType] = MyStringType.split
>
> But that would only
On 11/29/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> But the >>> prompt is Python's trademark! I always get a warm fuzzy
> feeling when I see it, e.g. in a corner of a slide in a NASA
> presentation.
I was using ``py>`` for a while. That still gave me a warm fuzzy
feeling ;-) and seemed to
On 12/3/06, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> In looking at this and some other stuff, I thought about this code:
> x = 1,
> How about requiring parens around (1,)?
[snip]
> This would apply to x, = 1 as well (ie, both LHS and RHS).
FWLIW, I use the latter all the time and would greatly m
On 12/7/06, Tim Hochberg <[EMAIL PROTECTED]> wrote:
> Let me throw out an examples of how this could look.
>
>@implements(sequence.__getitem__, sequence.__len__)
>class MySequence:
>#
>
>@implements(mapping.__getitem__, mapping.keys, mapping.__len__)
>class MyMapping:
>
On 12/8/06, Talin <[EMAIL PROTECTED]> wrote:
> Another mini-brainstorm, which is how to represent PJE's 'defop' syntax
> without adding any keywords:
>
> Alternative 1. Omitting the function name in 'def' statements.
[snip]
>@overload(len):
>def (self):
> ... compute len( self ) ...
[
At 08:53 AM 12/8/2006 -0600, Guido van Rossum wrote:
> I've been thinking about this too, and I think it's reasonable to let
> the metaclass provide the dict to be used as locals.
[snip]
> class C(B1, B2, metaclass=Foo):
>...
On 12/8/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> I definitely
On 12/9/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> I'd prefer to see...
>
> class MyMapping:
> @implements(mapping)
> def __getitem__(self, key):
> ...
>
> @implements(mapping)
> def __len__(self):
> ...
>
[snip]
>
> P.S. Here's a 1
Phillip J. Eby wrote:
> There's mine, where you simply create mcls(name, bases, {}) and then map
> locals operations to get/set/delattr operations on the class. This
> would presumably be done using a simple mapping proxy, but it would be a
> built-in type rather than the user having to implement
On 12/17/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> Say I have a metaclass X. Say that I've been using metaclass X since
> Python 2.2 days. One day I hear that shortly after Py3k, __metaclass__
> is going away and I need to start using some other syntax (say the
> metaclass= syntax for argum
On 12/22/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Andre Roberge wrote:
>
> > The various possibilities mentioned in various forums include:
> >
> > ask()
> > ask_user()
> > get_string()
> > input() # rejected by BDFL
> > prompt()
> > read()
> > user_input()
> > get_response()
>
> why not ca
On Dec 7, 2007 8:46 AM, Eric Smith <[EMAIL PROTECTED]> wrote:
> Neal Becker wrote:
> > Right now we have 2 rather different stdlib modules for parsing options from
> > ini-style files and from command line. I believe it would be desirable to
> > have one module that can handle both. Is there inte
On Jan 8, 2008 3:55 PM, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On Jan 8, 2008 2:41 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > list.sort() and built-in sorted() are the least of our problems: even
> > though the API uses cmp, the implementation actually only ever uses
> > '<'; and the pr
On Jan 24, 2008 5:13 PM, <[EMAIL PROTECTED]> wrote:
>
> Guido> Looking over the code base, frozensets are used rarely. So I
> Guido> don't think this is warranted.
>
> I kind of like the idea. Raymond's arguments make sense to me. Most of the
> time if I bother to create a set literal it
On Jan 25, 2008 12:18 AM, Mark Summerfield <[EMAIL PROTECTED]> wrote:
> On 2008-01-25, Guido van Rossum wrote:
> > For the record, I'm thinking Raymond has won this argument fair and
> > square, and I'm withdrawing my opposition.
> >
> > I hope it isn't too confusing that {1: 1} creates a *mutable*
On Jan 25, 2008 1:31 PM, J. Cliff Dyer <[EMAIL PROTECTED]> wrote:
>
> I'm a -0.9 on this one. I really like that Python is powerful, but also a
> great pedagogical language.
>
> I don't like that whereas before you could teach someone {} creates a dict,
> but now you have to say {} creates a dic
On Feb 9, 2008 2:33 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> In the process of getting UserDict updated to subclass from MutableMapping,
> it ended-up in the collections module during the transistion. Probably, all
> three
> should end-up in the same place, either in the collections mod
On Feb 9, 2008 6:43 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> [Brett]
> > +1 on collections.
>
> [Steven Bethard]
> > +1 for putting them in the collections module.
>
> How about UserString?
> Is there a reason for it to continue to exist?
Like Bret
On Feb 10, 2008 9:22 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On Feb 9, 2008 8:58 PM, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > At 07:51 PM 2/8/2008 -0500, Raymond Hettinger wrote:
> > >I recommend dropping the dict.copy() method from Py3.0.
> > >
> > >* We can already write: newd = c
On Feb 11, 2008 9:10 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> Was the concensus on this to move UserList into the collections module and to
> remove UserString?
> Any objections?
No objections here either.
Steve
--
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
On Thu, Feb 14, 2008 at 5:52 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> Would it be worthwhile to leave reversed(s) and s[::-1] as the two obvious
> ways to do it (ways that work with any Sequence, not just lists)?
But .reverse() is in-place, while the other two create new sequences, no?
On Fri, Mar 7, 2008 at 8:47 PM, Anthony Tolle <[EMAIL PROTECTED]> wrote:
> Let me put it this way: if unbound methods are gone for good, then I
> think it would nice to develop some guidance on checking the signature
> of callable objects, to enable decorators to play nice with each
> other--es
On Sat, Mar 8, 2008 at 4:33 PM, Anthony Tolle <[EMAIL PROTECTED]> wrote:
> On Sat, Mar 8, 2008 at 3:28 PM, Steven Bethard <[EMAIL PROTECTED]> wrote:
> > Why is it so crucial that "self" is the first argument? If I use a
> > decorator that adds a new ele
On Tue, Mar 18, 2008 at 6:39 AM, Marcin 'Qrczak' Kowalczyk
<[EMAIL PROTECTED]> wrote:
> Dnia 17-03-2008, Pn o godzinie 11:56 -0600, Adam Olsen pisze:
>
> > I've replaced __del__ API (which resurrected objects) with a
> > __finalize__/__finalizeattrs__ API (which doesn't). Attributes listed
> >
On Tue, Apr 8, 2008 at 7:25 AM, Anand Balachandran Pillai
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> There seems to be inconsistency in the way the new range(...)
> type implements equality and inequality operators.
>
> In Python 2.x, range(...) of course returns lists and when you
> equate lhs of
1 - 100 of 197 matches
Mail list logo
