Michael Urman wrote:
> On 10/1/06, Ron Adam <[EMAIL PROTECTED]> wrote:
>> (I don't think this has been suggested yet.)
>>
>> while , :
>>
>
> [snip]
>
>> Putting both the entry and exit conditions at the top is easier to read.
>
> I agree in principle, but I thought the proposed sy
> This pattern:
>
> while entry_cond:
> ...
> and while not exit_cond:
> ...
>
> has been suggested before, and I believe that at least one of the times it
> was suggested, it had some support from Guido. Essentially, the "and
> while not exit" is equivalent to an "
At 12:58 PM 10/1/2006 -0400, Andrew Koenig wrote:
> > (I don't think this has been suggested yet.)
> >
> > while , :
> >
>
>This usage makes me uneasy, not the least because I don't understand why the
>comma isn't creating a tuple. That is, why whould
>
> while x, y:
>
> (I don't think this has been suggested yet.)
>
> while , :
>
This usage makes me uneasy, not the least because I don't understand why the
comma isn't creating a tuple. That is, why whould
while x, y:
be any different from
while (x, y):
On 10/1/06, Ron Adam <[EMAIL PROTECTED]> wrote:
> (I don't think this has been suggested yet.)
>
> while , :
>
[snip]
> Putting both the entry and exit conditions at the top is easier to read.
I agree in principle, but I thought the proposed syntax already has
meaning today (as it
Nick Coghlan wrote:
> Hans Polak wrote:
>> Hi,
>>
>>
>>
>> Just an opinion, but many uses of the ‘while true loop’ are instances of
>> a ‘do loop’. I appreciate the language layout question, so I’ll give you
>> an alternative:
>>
>>
>>
>> do:
>>
>>
>>
>>
>>
>>
Hans Polak wrote:
> Hi,
>
>
>
> Just an opinion, but many uses of the ‘while true loop’ are instances of
> a ‘do loop’. I appreciate the language layout question, so I’ll give you
> an alternative:
>
>
>
> do:
>
>
>
>
>
> while
>
I believe you m
Hi,
Just an opinion, but many uses of the ‘while true loop’
are instances of a ‘do loop’. I appreciate the language layout
question, so I’ll give you an alternative:
do:
while
Cheers,
Hans Polak.
This message contains informat
I've rejected PEP 351, with a reference to this thread as the rationale.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
h
Bengt Richter wrote:
> Anyhow, why shouldn't you be able to call freeze(an_ordinary_list) and get
> back freeze(xlist(an_ordinary_list))
> automatically, based e.g. on a freeze_registry_dict[type(an_ordinary_list)]
> => xlist lookup, if plain hash fails?
[Cue: sound of loud alarm bells going of
On Sat, 11 Feb 2006 12:55:10 -0800, Alex Martelli <[EMAIL PROTECTED]> wrote:
>
>On Feb 10, 2006, at 1:05 PM, Raymond Hettinger wrote:
>
>> [Guido van Rossum]
>>> PEP 351 - freeze protocol. I'm personally -1; I don't like the
>>> idea of
>>> freezing arbitrary mutable data structures. Are there c
[Noam]
> I just wanted to say this: you can reject PEP 351, please don't reject
> the idea of frozen objects completely. I'm working on an idea similar
> to that of the PEP,
. . .
> I think these concerns can only be judged given a real suggestion,
> along with an implementation. I have already im
Hello,
I just wanted to say this: you can reject PEP 351, please don't reject
the idea of frozen objects completely. I'm working on an idea similar
to that of the PEP, and I think that it can be done elegantly, without
the concrete problems that Raymond pointed. I didn't work on it in the
last few
- Original Message -
From: "Alex Martelli" <[EMAIL PROTECTED]>
To: "Raymond Hettinger" <[EMAIL PROTECTED]>
Cc:
Sent: Saturday, February 11, 2006 3:55 PM
Subject: PEP 351
>
> On Feb 10, 2006, at 1:05 PM, Raymond Hettinger wrote:
>
>> [Guido van Rossum]
>>> PEP 351 - freeze protocol. I'm
On Feb 11, 2006, at 3:55 PM, Alex Martelli wrote:
>
> On Feb 10, 2006, at 1:05 PM, Raymond Hettinger wrote:
>
>> [Guido van Rossum]
>>> PEP 351 - freeze protocol. I'm personally -1; I don't like the
>>> idea of
>>> freezing arbitrary mutable data structures. Are there champions who
>>> want to arg
On Feb 10, 2006, at 1:05 PM, Raymond Hettinger wrote:
> [Guido van Rossum]
>> PEP 351 - freeze protocol. I'm personally -1; I don't like the
>> idea of
>> freezing arbitrary mutable data structures. Are there champions who
>> want to argue this?
>
> It has at least one anti-champion. I think i
I thought about something -
>
> I think that the performance penalty may be rather small - remember
> that in programs which do not change strings, there would never be a
> need to copy the string data at all. And since I think that usually
> most of the dict lookups are for method or function name
On 10/31/05, Josiah Carlson <[EMAIL PROTECTED]> wrote:
...
> And I'm going to point out why you are wrong.
I still don't think so. I think that I need to reclarify what I mean.
> > About the users-changing-my-internal-data issue:
...
> You can have a printout before it dies:
> "I'm crashing your
Noam Raphael <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I have slept quite well, and talked about it with a few people, and I
> still think I'm right.
And I'm going to point out why you are wrong.
> About the users-changing-my-internal-data issue:
>
> > Again, user semantics. Tell your users not
Steve Holden <[EMAIL PROTECTED]> wrote:
>
> Josiah Carlson wrote:
> [...]
> >>Perhaps I didn't make it clear. The difference between wxPython's Grid
> >>and my table is that in the table, most values are *computed*. This
> >>means that there's no point in changing the values themselves. They
> >>
Hello,
I have slept quite well, and talked about it with a few people, and I
still think I'm right.
About the users-changing-my-internal-data issue:
> Again, user semantics. Tell your users not to modify entries, and/or
> you can make copies of objects you return. If your users are too daft
>
On 10/31/05, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
>
> > It allows everything in Python to be both mutable and hashable,
>
> I don't understand, since it's already the case. Any user-defined object
> is at the same time mutable and hashable.
By default, user-defined objects are equal iff they
Josiah Carlson wrote:
[...]
>>Perhaps I didn't make it clear. The difference between wxPython's Grid
>>and my table is that in the table, most values are *computed*. This
>>means that there's no point in changing the values themselves. They
>>are also used frequently as set members (I can describe
Noam Raphael <[EMAIL PROTECTED]> wrote:
>
> Hello,
>
> It seems that we both agree that freezing is cool (-; . We disagree on
> whether a copy-on-write behaviour is desired. Your arguments agains
> copy-on-write are:
> 1. It's not needed.
> 2. It's complicated to implement.
>
> But first of all
> It allows everything in Python to be both mutable and hashable,
I don't understand, since it's already the case. Any user-defined object
is at the same time mutable and hashable.
And if you want the hash value to follow the changes in attribute
values, just define an appropriate __hash__ method
Hello,
It seems that we both agree that freezing is cool (-; . We disagree on
whether a copy-on-write behaviour is desired. Your arguments agains
copy-on-write are:
1. It's not needed.
2. It's complicated to implement.
But first of all, you didn't like my use cases. I want to argue with that.
>
Noam Raphael <[EMAIL PROTECTED]> wrote:
>
> Hello,
>
> I have thought about freezing for some time, and I think that it is a
> fundamental need - the need to know, sometimes, that objects aren't
> going to change.
I agree with this point.
> This is mostly the need of containers. dicts need to
Hello,
I have thought about freezing for some time, and I think that it is a
fundamental need - the need to know, sometimes, that objects aren't
going to change.
This is mostly the need of containers. dicts need to know that the
objects that are used as keys aren't going to change, because if the
Paolino wrote:
> Is __hash__=id inside a class enough to use a set (sets.Set before 2.5)
> derived class instance as a key to a mapping?
It is __hash__=lambda self:id(self) that is terribly slow ,it needs a
faster way to state that to let them be useful as key to mapping as all
set operations w
Nick Coghlan <[EMAIL PROTECTED]> wrote:
>
> Josiah Carlson wrote:
> > Nick Coghlan <[EMAIL PROTECTED]> wrote:
> >> I think having dicts and sets automatically invoke freeze would be a
> >> mistake,
> >> because at least one of the following two cases would behave unexpectedly:
> >
> > I'm pret
Josiah Carlson wrote:
> Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> I think having dicts and sets automatically invoke freeze would be a
>> mistake,
>> because at least one of the following two cases would behave unexpectedly:
>
> I'm pretty sure that the PEP was only aslomg if one would freeze t
[Barry Warsaw]
> I've had this PEP laying around for quite a few months. It was
inspired
> by some code we'd written which wanted to be able to get immutable
> versions of arbitrary objects.
* FWIW, the _as_immutable() protocol was dropped from sets.py for a
reason. User reports indicated that
On Oct 23, 2005, at 6:43 PM, Barry Warsaw wrote:
> I've had this PEP laying around for quite a few months. It was
> inspired
> by some code we'd written which wanted to be able to get immutable
> versions of arbitrary objects. I've finally finished the PEP,
> uploaded
> a sample patch (albe
I'm not sure I understood completely the idea but deriving freeze
function from hash gives hash a wider importance.
Is __hash__=id inside a class enough to use a set (sets.Set before 2.5)
derived class instance as a key to a mapping?
Sure I missed the point.
Regards Paolino
___
Nick Coghlan <[EMAIL PROTECTED]> wrote:
> I think having dicts and sets automatically invoke freeze would be a mistake,
> because at least one of the following two cases would behave unexpectedly:
I'm pretty sure that the PEP was only aslomg if one would freeze the
contents of dicts IF the dict
Christopher Armstrong <[EMAIL PROTECTED]> wrote:
>
> On 10/24/05, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > "Should dicts and sets automatically freeze their mutable keys?"
> >
> > Dictionaries don't have mutable keys,
>
> Since when?
>
> Maybe you meant something else? I can't think of any
On 10/24/05, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> "Should dicts and sets automatically freeze their mutable keys?"
>
> Dictionaries don't have mutable keys,
Since when?
class Foo:
def __init__(self):
self.x = 1
f = Foo()
d = {f: 1}
f.x = 2
Maybe you meant something else? I ca
Barry Warsaw wrote:
> I've had this PEP laying around for quite a few months. It was inspired
> by some code we'd written which wanted to be able to get immutable
> versions of arbitrary objects. I've finally finished the PEP, uploaded
> a sample patch (albeit a bit incomplete), and I'm posting i
Barry Warsaw <[EMAIL PROTECTED]> wrote:
> I've had this PEP laying around for quite a few months. It was inspired
> by some code we'd written which wanted to be able to get immutable
> versions of arbitrary objects. I've finally finished the PEP, uploaded
> a sample patch (albeit a bit incomplet
On 10/23/05, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> I've had this PEP laying around for quite a few months. It was inspired
> by some code we'd written which wanted to be able to get immutable
> versions of arbitrary objects. I've finally finished the PEP, uploaded
> a sample patch (albeit a b
I've had this PEP laying around for quite a few months. It was inspired
by some code we'd written which wanted to be able to get immutable
versions of arbitrary objects. I've finally finished the PEP, uploaded
a sample patch (albeit a bit incomplete), and I'm posting it here to see
if there is an
41 matches
Mail list logo
