David Pokorny wrote:
> With all due respect, the policy you
> describe---a more efficient implementation in the common
> case---optimizes the code of people who don't think about this issue
> at all. In other words it facilitates premature optimization.
So automatically making the most common
> I'd say not clear, for two reasons. One is that I pretty much never
> use keys() in a for loop, I just use the dictionary.
Ok. Consider items() then. Again, I claim that the common use of
items() is to iterate over it.
,keys() should clearly behave the same as .items().
>> Applications that ta
On Tue, Apr 1, 2008 at 7:37 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> I think it's fairly obvious why the 2.x .keys() has to change. It's
> just too wasteful to actually build the list of all keys of a dictionary
> (or even of all values, as you have to create all the tuples as well),
>
> So unless I am misinterpreting this, it sounds like the burden of
> proof now falls on the option to keep the status quo. The thing is
> that it seems to me that if that an outside observer were to look at
> this situation, then they might ask why the names are being changed
> when the current be
On Tue, Apr 1, 2008 at 6:43 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Well, it *is* part of the public interface of io.py, and it *is* the
> implementation of the built-in open() function. So I don't think this
> should be changed. The module's name is so short that I hope people
> won't i
On Tue, Apr 1, 2008 at 4:40 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I'm not sure that it's really a safe vs. non-safe issue. The OP's
> concern is that the change affects behavior of keys() and friends that
> people have internalized for the past 18 years. I certainly don't see
> this
--- Antoine Pitrou <[EMAIL PROTECTED]> wrote:
> Steve Howell yahoo.com> writes:
> >
> >line 673234: lambda cannot be renamed in ANY
> > temporal dimension
> >
> [...]
> >
> >line 913975: parens not removed from print(),
> > please use 3to4 converter instead
>
> Mmmh... "3to2" was rel
On Mon, Mar 31, 2008 at 12:12 PM, Alexander Belopolsky
<[EMAIL PROTECTED]> wrote:
> Do I understand correctly that with PEP 3102 implemented, keyword
> arguments can follow vararg in function definitions, but doing the
> same when calling the function is still a syntax error?
>
> With the latest
Well, it *is* part of the public interface of io.py, and it *is* the
implementation of the built-in open() function. So I don't think this
should be changed. The module's name is so short that I hope people
won't import * from it.
On Tue, Apr 1, 2008 at 1:46 PM, Benjamin Peterson
<[EMAIL PROTECTED
I'm not sure that it's really a safe vs. non-safe issue. The OP's
concern is that the change affects behavior of keys() and friends that
people have internalized for the past 18 years. I certainly don't see
this is a reason to change it back (we knew this would be the case). I
do think it needs to
On Tue, Apr 1, 2008 at 5:25 PM, Paul Moore <[EMAIL PROTECTED]> wrote:
> On 01/04/2008, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > > What really bugs me about this state of affairs is that I consider the
> > > python 2 dict.items() to be safe and free of surprises, but I no
> > > longer fee
> I suspect that view semantics will become less surprising over time,
> but I think it's a fair point that it's something new to get used to.
I don't doubt that it is surprising. I object to calling it unsafe.
Regards,
Martin
___
Python-3000 mailing li
On 01/04/2008, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > What really bugs me about this state of affairs is that I consider the
> > python 2 dict.items() to be safe and free of surprises, but I no
> > longer feel the same way about it in 3; this is really about the fact
> > that when you
> What really bugs me about this state of affairs is that I consider the
> python 2 dict.items() to be safe and free of surprises, but I no
> longer feel the same way about it in 3; this is really about the fact
> that when you want to get the items, keys, or values of a dict, the
> simplest thing
Hi Py3k,
I just started using Python 3000 (for my own projects, nothing
production-y, and mostly for the class decorators and function
annotations) but ever since I noticed PEP 3106, the "spooky" behavior
of dict views has been bothering me...I wouldn't say it has been
keeping me up late at night,
Is there a reason io.open is in the __all__? It seems to me it would
redundant and confusing to import a builtin.
--
Cheers,
Benjamin Peterson
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubs
Steve Howell yahoo.com> writes:
>
>line 673234: lambda cannot be renamed in ANY
> temporal dimension
>
[...]
>
>line 913975: parens not removed from print(),
> please use 3to4 converter instead
Mmmh... "3to2" was released on April 1st right ? :)
_
Steve Howell wrote:
> I've written about 100,000 lines of Py3K code since it
> was released, mostly on evenings and weekends, so I
> was very excited to see Van release the new 3to2 tool
> today.
A point of clarification: I did not release anything. I was simply
pointing out someone else's work t
Vizcayno <[EMAIL PROTECTED]> wrote:
> I am doing some testing using Python r30a3:61161 under command prompt
> of WinXp SP2.
> Is this possible to find an explanation about next error? I tried to
> find the error message in the web but no info exists and, can not
> isolate or reproduce it.
> Ma
On Tue, Apr 1, 2008 at 7:38 AM, Steve Howell <[EMAIL PROTECTED]> wrote:
> I've written about 100,000 lines of Py3K code since it
> was released, mostly on evenings and weekends, so I
> was very excited to see Van release the new 3to2 tool
> today.
>
> I immediately ran it against my codebase, a
I am doing some testing using Python r30a3:61161 under command prompt
of WinXp SP2.
Is this possible to find an explanation about next error? I tried to
find the error message in the web but no info exists and, can not
isolate or reproduce it.
Many, many thanks for your attention.
Traceback (most
On Mon, 24 Mar 2008 09:06:29 +0100
> > It really does appear that, for such a project (and I think two of
> > mine - python-xlib & plwm - qualify) 2.5->2.6 and 2.6->3.0 aren't that
> > far apart. You can write code for the old version, and run it (with
> > suitable preprocessing) on the new ver
On Sun, 23 Mar 2008 23:12:55 +0100
"Lennart Regebro" <[EMAIL PROTECTED]> wrote:
> > You develop for 2.6, and then make sure it runs on 3.0 -
> > *exactly* the same as for 2.5/2.6.
> Uh... no. You develop for 2.5, and then you don't do anything else. It
> *will* run under 2.6. No need to check. Beca
On Sun, 23 Mar 2008 21:20:11 +0100
"Lennart Regebro" <[EMAIL PROTECTED]> wrote:
> On Thu, Mar 20, 2008 at 11:02 PM, Mike Meyer <[EMAIL PROTECTED]> wrote:
> > Fair enough. But doesn't 2.5->2.6 present the same problem? After all,
> > you can't start using 2.6 features until everyone is using it, r
I've written about 100,000 lines of Py3K code since it
was released, mostly on evenings and weekends, so I
was very excited to see Van release the new 3to2 tool
today.
I immediately ran it against my codebase, and it
mostly works, but I got some strange diagnostics:
line 673234: lambda cannot
I know there has been some discussion of a 3to2 tool for easing porting.
The PyPy team has created at least the start of such a tool:
"Under the hood, the 2to3 conversion tool operates as a graph
transformer: it takes the graph of your program (in the form of Python
2.x source file) and returns
On Tue, Apr 1, 2008 at 12:58 AM, Amaury Forgeot d'Arc
<[EMAIL PROTECTED]> wrote:
> On Tue, Apr 1, 2008 at 9:41 AM, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> > I fixed the itertools refleak.
> >
> > test_compile leaks due to code like this:
> >
> > class J:
> > def foo():
> > class Ba
On Tue, Apr 1, 2008 at 9:41 AM, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> I fixed the itertools refleak.
>
> test_compile leaks due to code like this:
>
> class J:
> def foo():
> class Bar: pass
>
> I thought Amaury fixed that problem already?
http://mail.python.org/pipermail/python-3000-
I fixed the itertools refleak.
test_compile leaks due to code like this:
class J:
def foo():
class Bar: pass
I thought Amaury fixed that problem already?
n
On Mon, Mar 31, 2008 at 9:25 PM, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> The current refleaks for 3k are:
>
> test_compile leaked
29 matches
Mail list logo
