[Python-Dev] Fighting the theoretical randomness of "is" on immutables

[Armin Rigo]

Hi all,

In the context PyPy, we've recently seen again the issue of "x is y"
not being well-defined on immutable constants.  I've tried to
summarize the issues and possible solutions in a mail to pypy-dev [1]
and got some answers already.  Having been convinced that the core is
a language design issue, I'm asking for help from people on this list.
 (Feel free to cross-post.)

[1] http://mail.python.org/pipermail/pypy-dev/2013-May/011299.html

To summarize: the issue is a combination of various optimizations that
work great otherwise.  For example we can store integers directly in
lists of integers, so when we read them back, we need to put them into
fresh W_IntObjects (equivalent of PyIntObject).  We solved temporarily
the issue of "I'm getting an object which isn't ``is``-identical to
the one I put in!" by making all equal integers ``is``-identical.
This required hacking at ``id(x)`` as well to keep the requirement ``x
is y <=> id(x)==id(y)``.  This is getting annoying for strings, though
-- how do you compute the id() of a long string?  Give a unique long
integer?  And if we do the same for tuples, what about their id()?

The long-term solution that seems the most stable to me would be to
relax the requirement ``x is y <=> id(x)==id(y)``.  If we can get away
with only ``x is y <= id(x)==id(y)`` then it would allow us to
implement ``is`` in a consistent way (e.g. two strings with equal
content would always be ``is``-identical) while keeping id()
reasonable (both in terms of complexity and of size of the resulting
long number).  Obviously ``x is y <=> id(x)==id(y)`` would still be
true if any of ``x`` or ``y`` is not an immutable "by-value" built-in
type.

This is clearly a language design issue though.  I can't really think
of a use case that would break if we relax the requirement, but I
might be wrong.  It seems to me that at most some modules like pickle
which use id()-keyed dictionaries will fail to find some
otherwise-identical objects, but would still work (even if tuples are
"relaxed" in this way, you can't have cycles with only tuples).


A bientôt,

Armin.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Fighting the theoretical randomness of "is" on immutables

[Terry Jan Reedy]

On 5/6/2013 4:46 AM, Armin Rigo wrote:

'is' *is* well-defined. In production code, the main use of 'is' is for 
builtin singletons, the bool doubleton, and object instances used as 
sentinals. The most common use, in particular, is 'if a is None:'. For 
such code, the result must be independent of implementation.


For other immutable classes, for which 'is' is mostly irrelevant and 
useless, the result of some code is intentionally implementation 
dependent to allow optional optimizations. 'Implementation dependent' is 
differnt from 'random'. For such classes (int, tuple, set, string), the 
main use of 'is' is to test if the intended optimization is being done. 
In other words, for these classes, the implementation dependence is a 
feature.


The general advice given to newbies by python-list regulars is to limit 
the use of 'is' with immutables to the first group of classes and never 
use it for the second.



In the context PyPy, we've recently seen again the issue of "x is y"
not being well-defined on immutable constants.


Since immutable objects have a constant value by definition of 
immutable, I am not sure if you are trying to say anything more by 
adding the extra word.



 I've tried to
summarize the issues and possible solutions in a mail to pypy-dev [1]
and got some answers already.  Having been convinced that the core is
a language design issue, I'm asking for help from people on this list.
  (Feel free to cross-post.)

[1] http://mail.python.org/pipermail/pypy-dev/2013-May/011299.html

To summarize: the issue is a combination of various optimizations that
work great otherwise.  For example we can store integers directly in
lists of integers, so when we read them back, we need to put them into
fresh W_IntObjects (equivalent of PyIntObject).


Interesting. I presume you only do this when the ints all fit in a 
machine int so that all require the same number of bytes so you can 
efficiently index and slice.


This is sort of what strings do with characters, except for there being 
no char class. The similarity is that if you concatenate a string to 
another string and then slice it back out, you generally get a different 
object, but may get the same object if some optimization has that 
effect. For instance, in current CPython, s is ''+s is s+''. The details 
depend on the CPython version.



We solved temporarily the issue  of "I'm getting an object which isn't

> ``is``-identical to the one I put in!"

Does the definition of list operations guarantee preservation of object 
identify? After 'somelist.append(a)', must 'somelist.pop() is a' be 
true? I am not sure. For immutables, it could be an issue if someone 
stores the id. But I don't know why someone would do that for an int.


As I already said, we routinely tell people on python-list (c.l.p) that 
they shouldn't care about ids of ints.. The identity of an int cannot 
(and should not) affect the result of numerical calculation.


> by making all equal integers ``is``-identical.

Which changes the definition of 'is', or rather, makes the definition 
implementation dependent.



This required hacking at ``id(x)`` as well to keep the requirement ``x
is y <=> id(x)==id(y)``.  This is getting annoying for strings, though
-- how do you compute the id() of a long string?  Give a unique long
integer?  And if we do the same for tuples, what about their id()?


The solution to the annoyance is to not do this ;-). More seriously, are 
you planning to unbox strings or tuples?



The long-term solution that seems the most stable to me would be to
relax the requirement ``x is y <=> id(x)==id(y)``.


I see this as a definition, not a requirement. Changing the definition 
would break any use that depends on the definition being what it is.


--
Terry Jan Reedy



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Fighting the theoretical randomness of "is" on immutables

[Nick Coghlan]

On Mon, May 6, 2013 at 6:46 PM, Armin Rigo  wrote:
> This is clearly a language design issue though.  I can't really think
> of a use case that would break if we relax the requirement, but I
> might be wrong.  It seems to me that at most some modules like pickle
> which use id()-keyed dictionaries will fail to find some
> otherwise-identical objects, but would still work (even if tuples are
> "relaxed" in this way, you can't have cycles with only tuples).

IIRC, Jython just delays calculating the object id() until it is
called, and lives with it potentially being incredibly expensive to
calculate. Is there some way PyPy can run with a model where "is" is
defined in terms of values for immutable objects, with a lazily
populated mapping from values to numeric ids if you're forced to
define them through an explicit call to id()?

We're not going to change the language design because people don't
understand the difference between "is" and "==" and then wrongly blame
PyPy for breaking their code. If you're tired of explaining to people
that it's their code which is buggy rather than PyPy, then your
Solution 2 (mimic'ing CPython's caching) is likely your best bet.

Alternatively, we've offered to add CompatibilityWarning to CPython in
the past (there may even be a preliminary patch for it on the
tracker). That offer is still open, and would be applicable to this
case.

Regards,
Nick.

--
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Fighting the theoretical randomness of "is" on immutables

[Antoine Pitrou]

Le Mon, 6 May 2013 23:18:54 +1000,
Nick Coghlan  a écrit :
> 
> IIRC, Jython just delays calculating the object id() until it is
> called, and lives with it potentially being incredibly expensive to
> calculate. Is there some way PyPy can run with a model where "is" is
> defined in terms of values for immutable objects, with a lazily
> populated mapping from values to numeric ids if you're forced to
> define them through an explicit call to id()?

This sounds reasonable. Actually, for small ints, id() could simply be
a tagged pointer (e.g. "1 + 2 * myint.value").

> We're not going to change the language design because people don't
> understand the difference between "is" and "==" and then wrongly blame
> PyPy for breaking their code.

Well, if I'm doing:

  mylist = [x]

and ``mylist[0] is x`` returns False, then I pretty much consider the
Python implementation to be broken, not my code :-)

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Fighting the theoretical randomness of "is" on immutables

[Nick Coghlan]

On Mon, May 6, 2013 at 11:26 PM, Antoine Pitrou  wrote:
> Le Mon, 6 May 2013 23:18:54 +1000,
> Nick Coghlan  a écrit :
>> We're not going to change the language design because people don't
>> understand the difference between "is" and "==" and then wrongly blame
>> PyPy for breaking their code.
>
> Well, if I'm doing:
>
>   mylist = [x]
>
> and ``mylist[0] is x`` returns False, then I pretty much consider the
> Python implementation to be broken, not my code :-)

Yeah, that's a rather good point - I briefly forgot that the trigger
here was PyPy's specialised single type containers.

Cheers,
Nick.

--
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 435 - ref impl disc 2

[Barry Warsaw]

On May 06, 2013, at 02:51 PM, Nick Coghlan wrote:

>Enums are the same - they carve out a subtree in the type hierarchy
>that *doesn't* behave the same as the standard tree anchored directly
>on type. This *is* going to cause conflicts with meta-tools that only
>handle ordinary types - the trick is that the cause of the problem (a
>custom metaclass) is also the solution (a custom metaclass derived
>from enum.enum_type).

Agreed.  When the time is right, I think we should consider implementation
details that allow for useful flexibility.  An example would be the
prohibition on extension through subclassing.  I'm perfectly willing to accept
that as the standard behavior on stdlib Enums, but I'd like to be able to
override this with my own custom metaclass subclass.  I think it could be done
quite easily with the right refactoring of the implementation, although there
would be some discussion around what is blessed private API and what is
YOYO[1] API.

-Barry

[1] You're own your own.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 435 - requesting pronouncement

[Barry Warsaw]

On May 05, 2013, at 06:44 AM, Ethan Furman wrote:

> to easily create enums when prototyping or at the interactive prompt (I'll
> use it all the time -- it's convenient! ;)

+1billion

(That's literally the number of times I've used the functional API when
discussion various aspects of enum behavior :).

-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 435: initial values must be specified? Yes

[Georg Brandl]

Am 05.05.2013 22:09, schrieb Ethan Furman:

> About the closest you going to be able to get is something like:
> 
> def e(_next=[1]):
>  e, _next[0] = _next[0], _next[0] + 1
>  return e
> 
> class Color(Enum):
>  red = e()
>  green = e()
>  blue = e()

Uh, that's surely more nicely spelled as "e = itertools.count()"?

Georg

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 435: initial values must be specified? Yes

[Ethan Furman]

On 05/06/2013 10:48 AM, Georg Brandl wrote:

Am 05.05.2013 22:09, schrieb Ethan Furman:


About the closest you going to be able to get is something like:

def e(_next=[1]):
  e, _next[0] = _next[0], _next[0] + 1
  return e

class Color(Enum):
  red = e()
  green = e()
  blue = e()


Uh, that's surely more nicely spelled as "e = itertools.count()"?


Why, yes, I believe it is.  :)

--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: Issue #11816: multiple improvements to the dis module

[Antoine Pitrou]

On Mon,  6 May 2013 15:59:49 +0200 (CEST)
nick.coghlan  wrote:
> http://hg.python.org/cpython/rev/f65b867ce817
> changeset:   83644:f65b867ce817
> user:Nick Coghlan 
> date:Mon May 06 23:59:20 2013 +1000
> summary:
>   Issue #11816: multiple improvements to the dis module
> 
> * get_instructions generator
> * ability to redirect output to a file
> * Bytecode and Instruction abstractions
> 
> Patch by Nick Coghlan, Ryan Kelly and Thomas Kluyver.
> 
> files:
>   Doc/library/dis.rst  |  269 +++-
>   Doc/whatsnew/3.4.rst |   15 +
>   Lib/dis.py   |  341 +-
>   Lib/test/test_dis.py |  339 +++---
>   Misc/NEWS|4 +
>   5 files changed, 775 insertions(+), 193 deletions(-)

Looks like you forgot to add bytecode_helper.py.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 4XX: pyzaa "Improving Python ZIP Application Support"

[Steve Dower]

> From: Nick Coghlan [mailto:ncogh...@gmail.com]
> Sent: Friday, May 3, 2013 2348
>
> We don't need examples of arbitrary data file extentions, we need examples
> of 4 letter extensions that are known to work correctly when placed on
> PATHEXT, including when called from PowerShell. In the absence of
> confirmation that 4-letter extensions work reliably in such cases, it seems
> wise to abbreviate the Windows GUI application extension as .pzw.
> 
> I've also cc'ed Steve Dower, since investigation of this kind of Windows
> behavioural question is one of the things he offered distuils-sig help with
> after PyCon US :)

Thanks, Nick. I've been following along with this but haven't really been able 
to add anything.

I can certainly say that I've never had any issue with more than 3 letters in 
an extension, and I deal with those every day (.pyproj, .csproj, 
.vxcproj.filters, etc).

The PowerShell bug (which I hadn't heard of before) may be a complete 
non-issue, depending on how the associations are set up.

To summarise the bug, when PowerShell invokes a command based on an extension 
in PATHEXT, only the first three characters of the extension are used to 
determine the associated program. I tested this by creating a file "test.txta" 
and adding ".TXTA" to my PATHEXT variable. Typing ".\test" in PowerShell opened 
the file in my text editor. This only affects PowerShell (cmd.exe handles it 
correctly) and only in the case where you don't specify the extension 
(".\test.txta"  works fine, and with tab completion, this is probably more 
likely). It also ignores the associated command line and only uses the 
executable.

(I'll pass this on to the PowerShell team, though I have no idea how they'll 
prioritise it, and of course there's probably no fix for existing versions.)

Because we'd be claiming both .pyz and .pyzw, it's possible to work around this 
issue if we accept that .pyzw files may run with the .pyz program instead of 
the .pyzw program. Maybe it goes to something other than py.exe that could 
choose based on the extension. (Since other command-line arguments get 
stripped, adding an option to py.exe can't be done, and unless the current 
behaviour is for it to open .pyw files in pythonw.exe, I wouldn't want it to be 
different for .pyzw files.)

However, anywhere in Windows that uses ShellExecute rather than FindExecutable 
will handle long extensions without any issue. AFAIK, this is everywhere except 
PowerShell, so I don't really see a strong case for breaking the w-suffix 
convention here. 

Cheers,
Steve


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 4XX: pyzaa "Improving Python ZIP Application Support"

[Paul Moore]

On 6 May 2013 20:46, Steve Dower  wrote:

> To summarise the bug, when PowerShell invokes a command based on an
> extension in PATHEXT, only the first three characters of the extension are
> used to determine the associated program. I tested this by creating a file
> "test.txta" and adding ".TXTA" to my PATHEXT variable. Typing ".\test" in
> PowerShell opened the file in my text editor. This only affects PowerShell
> (cmd.exe handles it correctly) and only in the case where you don't specify
> the extension (".\test.txta"  works fine, and with tab completion, this is
> probably more likely). It also ignores the associated command line and only
> uses the executable.
>

The form in which I hit the bug is that I tried to create a "script"
extension so that "foo.script" would be a generic script with a #!
extension specifying the interpreter. I was adding the extension to PATHEXT
so that scripts would be run "inline" (displaying the output at the console
prompt, rather than in a new transient console window) - again this is a
Powershell-specific issue which does not affect CMD.

But when I added .script to PATHEXT, the script ran, but in a separate
console window, which flashed up too fast for me to see the output. (It may
be that it's the clash with .scr screensaver files that caused the file to
be treated as a windows executable rather than a console executable, but
it's hard to tell when you can't see the error message :-()


> (I'll pass this on to the PowerShell team, though I have no idea how
> they'll prioritise it, and of course there's probably no fix for existing
> versions.)
>

Thanks. In my view, it's a vaguely irritating rough edge rather than a
dealbreaker. But it does cause problems as here. And the number of rough
edges in powershell when dealing with "traditional" console commands (e.g.,
see the point above about needing PATHEXT to get inline output, rather than
just to be able to omit the extension) are sufficient to make the
accumulation greater than the sum of its individual parts.


> Because we'd be claiming both .pyz and .pyzw, it's possible to work around
> this issue if we accept that .pyzw files may run with the .pyz program
> instead of the .pyzw program. Maybe it goes to something other than py.exe
> that could choose based on the extension. (Since other command-line
> arguments get stripped, adding an option to py.exe can't be done, and
> unless the current behaviour is for it to open .pyw files in pythonw.exe, I
> wouldn't want it to be different for .pyzw files.)
>

I'm not sure the behaviour is clearly defined enough to be certain of this
(although I'll defer to someone who's looked at the Powershell source code
:-)). In my experiments, it was frustratingly difficult to pin down the
exact behaviour with any certainty. And given that the choice is over
running a console executable or a Windows one, it can be particularly bad
if the wrong one is run (console program pops up in a transient second
window and the output gets lost, for example). Add the fact that the
powershell behaviour is essentially undocumented, and it's hard to
guarantee anything.

On the plus side, I suspect (but haven't proved) that if the GUI extension
(pyzw) gets misread as the console one (pyz) the behaviour is less serious,
because PATHEXT is not as relevant for GUI programs.


> However, anywhere in Windows that uses ShellExecute rather than
> FindExecutable will handle long extensions without any issue. AFAIK, this
> is everywhere except PowerShell, so I don't really see a strong case for
> breaking the w-suffix convention here.
>

To be blunt, I see no point in using a pair of extensions that are known to
be broken, even if only in Powershell, over a pair that will work
everywhere (but are no more than mildly less consistent with other cases -
note that while there's a py/pyw pair, there is no pycw corresponding to
pyc, or pyow corresponding to pyo).

Paul
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 4XX: pyzaa "Improving Python ZIP Application Support"

[Richard Oudkerk]

So the bug would just cause .pyzw files to be opened with py instead of 
pyw?  Won't this be harmless?


I think the worst that would happen would be that you get a redundant 
console window if you are not already running powershell inside a console.


--
Richard

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 4XX: pyzaa "Improving Python ZIP Application Support"

[Daniel Holth]

As the PEP author I declare we can have 3-letter extensions. It is not
a big deal.

Daniel Holth

On Mon, May 6, 2013 at 4:30 PM, Richard Oudkerk  wrote:
> So the bug would just cause .pyzw files to be opened with py instead of pyw?
> Won't this be harmless?
>
> I think the worst that would happen would be that you get a redundant
> console window if you are not already running powershell inside a console.
>
> --
> Richard
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/dholth%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Fighting the theoretical randomness of "is" on immutables

[PJ Eby]

On Mon, May 6, 2013 at 4:46 AM, Armin Rigo  wrote:
> This is clearly a language design issue though.  I can't really think
> of a use case that would break if we relax the requirement, but I
> might be wrong.  It seems to me that at most some modules like pickle
> which use id()-keyed dictionaries will fail to find some
> otherwise-identical objects, but would still work (even if tuples are
> "relaxed" in this way, you can't have cycles with only tuples).

I don't know if I've precisely understood the change you're proposing,
but I do know that in PEAK-Rules I use id() as an approximation for
"is" in order to build indexes of various "parameter is some_object"
conditions, for various "some_objects" and a given parameter.  The
rule engine takes id(parameter) at call time and then looks it up to
obtain a subset of applicable rules.  IIUC, this would require that
either "x is y" equates to "id(x)==id(y)", or else that there be some
way to determine in advance all the possible id(y)s that are now or
would ever be "is x", so they can be placed in the index.  Otherwise,
any use of an "is" condition would require a linear search of the
possibilities, as you could not rule out the possibility that a given
x was "is" to *some* y already in the index.

Of course, rules using "is" tend to be few and far between, outside of
some special cases, and their use with simple integers and strings
would be downright silly.  And on top of that, I'm not even sure
whether the "a <= b" notation you used was meant to signify "a implies
b" or "b implies a".  ;-)

But since you mentioned id()-keyed dictionaries and this is another
use of them that I know of, I figured I should at least throw it out
there for information's sake, regardless of which side of the issue it
lands on.  ;-)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Fighting the theoretical randomness of "is" on immutables

[Terry Jan Reedy]

On 5/6/2013 10:20 AM, Nick Coghlan wrote:

On Mon, May 6, 2013 at 11:26 PM, Antoine Pitrou  wrote:

Le Mon, 6 May 2013 23:18:54 +1000,
Nick Coghlan  a écrit :

We're not going to change the language design because people don't
understand the difference between "is" and "=="


For sure. The definition "The operators is and is not test for object 
identity: x is y is true if and only if x and y are the same object. x 
is not y yields the inverse truth value. [4]" is clear enough as far as 
it goes. But perhaps it should be said that whether or not x and y *are* 
the same object, in a particular situation, may depend on the 
implementation. The footnote [4] "Due to automatic garbage-collection, 
free lists, and the dynamic nature of descriptors, you may notice 
seemingly unusual behaviour in certain uses of the is operator, like 
those involving comparisons between instance methods, or constants." 
tells only part of the story, and the less common part at that.



and then wrongly blame PyPy for breaking their code.


The language definition intentionally leaves 'isness' implementation 
defined for number and string operations in order to allow but not 
require optimizations. Preserving isness when mixing numbers and strings 
with mutable collections is a different issue.



Well, if I'm doing:

   mylist = [x]

and ``mylist[0] is x`` returns False, then I pretty much consider the
Python implementation to be broken, not my code :-)


If x were constrained to be an int, the comparison would not make much 
sense, but part of the essential nature of lists is that x could be 
literally any object. So unless False were a documented possibility, I 
might be inclined to agree with you, based on CPython precedent.


The situation *is* different with type-limited arrays.
>>> from array import array
>>> x = 1001
>>> myray = array('i', [x])
>>> myray[0] is x
False

I think the possibility of False is implicit in "an object type which 
can compactly represent an array of basic values". The later phrase "the 
type of objects stored in them is constrained" is incorrectly worded 
because arrays store constrained *values*, not *objects* or even object 
references as lists do.



Yeah, that's a rather good point - I briefly forgot that the trigger
here was PyPy's specialised single type containers.


Does implicitly replacing or implementing a list with something that is 
internally more like Cpython arrays than Cpython lists (as I understand 
what pypy is doing) violates the language spec? I re-read the doc and I 
am not sure.


Sequences are sequences of 'items'. For example: "s[i]   ith item of s, 
origin 0"  'Items' are not defined, but pragmatically, they can be 
defined either by value or identity Containment is defined in terms of 
equality, which itself can be defined in terms of either value or 
identity. For strings and ranges, the 'items' are values, not objects. 
They also are for bytes even though identity is recovered when objects 
for all possible byte values are pre-cached, as in CPython.


'Item' is necessarily left vague for mutable sequences as bytearrays 
also store values. The fact that Antoine's example 'works' for 
bytearrays is an artifact of the caching, not a language-mandated necessity.


>>> b = bytearray()
>>> b.append(98)
>>> b[0] is 98
True

The definition for lists does not narrow 'item' either. "Lists are 
mutable sequences, typically used to store collections of homogeneous 
items (where the precise degree of similarity will vary by 
application)." Antoine's opinion would be more supportable if 'item' 
were replaced by 'object'.


Guido's notion of 'homogenous' could be interpreted as supporting 
specialized 'lists'. On the other hand, I think explicit import, as with 
the array module and numarray package, is a better idea. This is 
especially true if an implementation intends to be a drop-in replacement 
for CPython. It seems to me that Armin's pain comes from trying to be 
both different and compatible at the same time.


--
Terry Jan Reedy


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Fighting the theoretical randomness of "is" on immutables

[Antoine Pitrou]

On Mon, 06 May 2013 18:23:02 -0400
Terry Jan Reedy  wrote:
> 
> 'Item' is necessarily left vague for mutable sequences as bytearrays 
> also store values. The fact that Antoine's example 'works' for 
> bytearrays is an artifact of the caching, not a language-mandated
> necessity.

No, it isn't. You are mixing up values and references. A bytearray or a
array.array may indeed store values, but a list stores references to
objects.

I'm pretty sure that not respecting identity of objects stored in
general-purpose containers would break a *lot* of code out there.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 435 - ref impl disc 2

[Ethan Furman]

On 05/05/2013 01:01 AM, Glenn Linderman wrote:


The bigger problem is that the arithmetic on enumeration items, which seems 
like it should be inherited from NamedInt
(and seems to be, because the third value from each print is a NamedInt), doesn't pick up 
"x" or "y", nor does it pick
up "the-x" or "the-y", but rather, it somehow picks up the str of the value.


Indeed, the bigger problem is that we ended up have an (NamedInt, Enum) wrapping a NamedInt, so we had both 
NEI.x._intname /and/ NEI.x.value._intname, and it was just one big mess.


But I think it is solved.  Try the new code.  Here's what your example should 
look like:

class NamedInt( int ):
def __new__( cls, *args, **kwds ):
_args = args
name, *args = args
if len( args ) == 0:
raise TypeError("name and value must be specified")
self = int.__new__( cls, *args, **kwds )
self._intname = name
return self
@property
def __name__( self ):
return self._intname
def __repr__( self ):
# repr() is updated to include the name and type info
return "{}({!r}, {})".format(type(self).__name__,
 self.__name__,
 int.__repr__(self))
def __str__( self ):
# str() is unchanged, even if it relies on the repr() fallback
base = int
base_str = base.__str__
if base_str.__objclass__ is object:
return base.__repr__(self)
return base_str(self)
# for testing, we only define one operator that propagates expressions
def __add__(self, other):
temp = int( self ) + int( other )
if isinstance( self, NamedInt ) and isinstance( other, NamedInt ):
return NamedInt(
'({0} + {1})'.format(self.__name__, other.__name__),
temp )
else:
return temp

class NEI( NamedInt, Enum ):
x = ('the-x', 1 )
y = ('the-y', 2 )

NEI.x + NEI.y

--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Fighting the theoretical randomness of "is" on immutables

[Terry Jan Reedy]

On 5/6/2013 6:34 PM, Antoine Pitrou wrote:

On Mon, 06 May 2013 18:23:02 -0400
Terry Jan Reedy  wrote:


'Item' is necessarily left vague for mutable sequences as bytearrays
also store values. The fact that Antoine's example 'works' for
bytearrays is an artifact of the caching, not a language-mandated
necessity.


No, it isn't.


Yes it is. Look again at the array example.
>>> from array import array
>>> x = 1001
>>> myray = array('i', [x])
>>> myray[0] is x
False

Change 1001 to a cached int value such as 98 and the result is True 
instead of False. For the equivalent bytearray example


>>> b = bytearray()
>>> b.append(98)
>>> b[0] is 98
True

the result is always True *because*, and only because, all byte value 
are (now) cached. I believe the test for that is marked as CPython-specific.


> You are mixing up values and references.

No I am not. My whole post was about being careful to not to confuse the 
two. I noted, however, that the Python *docs* use 'item' to mean either 
or both. If you do not like the *doc* being unclear, clarify it.



A bytearray or a array.array may indeed store values, but a list stores 
references to
objects.


I said exactly that in reference to CPython. As far as I know, the same 
is true of lists in every other implementation up until Pypy decided to 
optimize that away. What I also said is that I cannot read the *current* 
doc as guaranteeing that characterization. The reason is that the 
members of sequences, mutable sequences, and lists are all described as 
'items'. In the first two cases, 'item' means 'value or object 
reference'. I see nothing in the doc to force a reader to change or 
particularized the meaning of 'item' in the third case. If I missed 
something *in the specification*, please point it out to me.



I'm pretty sure that not respecting identity of objects stored in
general-purpose containers would break a *lot* of code out there.


Me too. Hence I suggested that if lists, etc, are intended to respect 
identity, with 'is' as currently defined, in any implementation, then 
the docs should say so and end the discussion. I would be happy to 
commit an approved patch, but I am not in a position to decide the 
substantive content. Hence, I tried to provide a neutral analysis that 
avoided confusing the CPython implementation with the Python specification.


In my final paragraph, however, I did suggest that Pypy respect 
precedent, to avoid breaking existing code and expectations, and call 
their mutable sequences something other than 'list'.


--
Terry Jan Reedy


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 435: initial values must be specified? Yes

[Ethan Furman]

On 05/05/2013 02:55 PM, Tim Delaney wrote:


So long as I can get one of the requirements documented to implement an 
auto-number syntax I'll be happy enough with
stdlib enums I think.

class Color(AutoIntEnum):
 red = ...
 green = ...
 blue = ...



Will this do?

class AutoNumber(Enum):
def __new__(cls):
value = len(cls.__enum_info__) + 1
obj = object.__new__(cls)
obj._value = value
return obj
def __int__(self):
return self._value
class Color(AutoNumber):
red = ()
green = ()
blue = ()

--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 435: initial values must be specified? Yes

[Tim Delaney]

On 7 May 2013 12:29, Ethan Furman  wrote:

> On 05/05/2013 02:55 PM, Tim Delaney wrote:
>
>>
>> So long as I can get one of the requirements documented to implement an
>> auto-number syntax I'll be happy enough with
>> stdlib enums I think.
>>
>> class Color(AutoIntEnum):
>>  red = ...
>>  green = ...
>>  blue = ...
>>
>>
> Will this do?
>
> class AutoNumber(Enum):
> def __new__(cls):
> value = len(cls.__enum_info__) + 1
> obj = object.__new__(cls)
> obj._value = value
> return obj
> def __int__(self):
> return self._value
> class Color(AutoNumber):
> red = ()
> green = ()
> blue = ()


Considering that doesn't actually work with the reference implementation
(AutoNumber.__new__ is never called) ... no.

print(Color.red._value)
print(int(Color.red))

-- Run Python3 --
()
Traceback (most recent call last):
  File "D:\home\repos\mercurial\ref435\ref435.py", line 292, in 
print(int(Color.red))
TypeError: __int__ returned non-int (type tuple)

Plus I would not want to use the empty tuple for the purpose - at least ...
implies something ongoing.

Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 435 - ref impl disc 2

[Glenn Linderman]

On 5/6/2013 6:26 PM, Ethan Furman wrote:

On 05/05/2013 01:01 AM, Glenn Linderman wrote:


The bigger problem is that the arithmetic on enumeration items, which 
seems like it should be inherited from NamedInt
(and seems to be, because the third value from each print is a 
NamedInt), doesn't pick up "x" or "y", nor does it pick
up "the-x" or "the-y", but rather, it somehow picks up the str of the 
value.


Indeed, the bigger problem is that we ended up have an (NamedInt, 
Enum) wrapping a NamedInt, so we had both NEI.x._intname /and/ 
NEI.x.value._intname, and it was just one big mess.


But I think it is solved.  Try the new code.  Here's what your example 
should look like:


OK. I notice you changed some super()s to specific int calls; I think I 
understand why, having recently reread about the specific problem that 
super() solves regarding diamond inheritance, and with that 
understanding, it is clear that super() is not always the right thing to 
use, particularly when unrelated classes may still have particular 
methods with name clashes (dunder methods would commonly have the same 
names in unrelated classes).  So my use of super likely contributed to 
the multiple wrappings that you allude to above, although I haven't 
(yet) tried to figure out the exact details of how that happened.




class NamedInt( int ):
def __new__( cls, *args, **kwds ):
_args = args
name, *args = args
if len( args ) == 0:
raise TypeError("name and value must be specified")
self = int.__new__( cls, *args, **kwds )
self._intname = name
return self
@property
def __name__( self ):
return self._intname
def __repr__( self ):
# repr() is updated to include the name and type info
return "{}({!r}, {})".format(type(self).__name__,
 self.__name__,
 int.__repr__(self))
def __str__( self ):
# str() is unchanged, even if it relies on the repr() 
fallback

base = int
base_str = base.__str__
if base_str.__objclass__ is object:
return base.__repr__(self)
return base_str(self)
# for testing, we only define one operator that propagates 
expressions

def __add__(self, other):
temp = int( self ) + int( other )
if isinstance( self, NamedInt ) and isinstance( other, 
NamedInt ):

return NamedInt(
'({0} + {1})'.format(self.__name__, other.__name__),
temp )
else:
return temp

class NEI( NamedInt, Enum ):
x = ('the-x', 1 )
y = ('the-y', 2 )


I had tried this sort of constructor, thinking it should work, but 
couldn't tell that it helped or hindered, but it probably took 
eliminating the super() problem earlier, and likely your preservation of 
__new__ in your ref435 changes, to enable this syntax to do what I 
expected it might.  This certainly does allow the name definitions to be 
better grouped, even though still somewhat redundant.


It may take a subclass of the enum_type, as Nick was suggesting, to make 
the NamedInt and the enumeration member actually share a single name... 
but this (after fleshing out NamedInt with more operators) would be a 
functional method of producing enumerations for the various flag 
parameters in the Python API (that are mostly inherited from wrapped C 
APIs, I suppose... at least, I haven't found a need or benefit of 
creating flag parameters in new Python APIs that I have created).



NEI.x + NEI.y


And this works as expected, now. Can't say I still fully understand the 
changes, but the test case works, and the constructors for the NamedInt 
inside the NEI class works, so this is pretty much what I was hoping to 
be able when I started down this path... but since it found some issues 
that you were able to fix in ref435, I guess I wasn't totally wasting 
your time presenting the issue. Thanks for investigating, and fixing, 
rather than blowing it off, even given my amateurish presentation.


And I should have called this NIE, not NEI, because it was intended to 
stand for NamedIntEnum... but it is just a name, so doesn't affect the 
functionality.



N.B.  In your latest ref435.py code, line 105, should be "An Enum class 
_is_ final..." rather than "in".
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Fighting the theoretical randomness of "is" on immutables

[Gregory P. Smith]

On Mon, May 6, 2013 at 7:50 PM, Terry Jan Reedy  wrote:

> On 5/6/2013 6:34 PM, Antoine Pitrou wrote:
>
>> On Mon, 06 May 2013 18:23:02 -0400
>> Terry Jan Reedy  wrote:
>>
>>>
>>> 'Item' is necessarily left vague for mutable sequences as bytearrays
>>> also store values. The fact that Antoine's example 'works' for
>>> bytearrays is an artifact of the caching, not a language-mandated
>>> necessity.
>>>
>>
>> No, it isn't.
>>
>
> Yes it is. Look again at the array example.
>
> >>> from array import array
> >>> x = 1001
> >>> myray = array('i', [x])
> >>> myray[0] is x
> False
>
> Change 1001 to a cached int value such as 98 and the result is True
> instead of False. For the equivalent bytearray example
>
>
> >>> b = bytearray()
> >>> b.append(98)
> >>> b[0] is 98
> True
>
> the result is always True *because*, and only because, all byte value are
> (now) cached. I believe the test for that is marked as CPython-specific.
>
>
> > You are mixing up values and references.
>
> No I am not. My whole post was about being careful to not to confuse the
> two. I noted, however, that the Python *docs* use 'item' to mean either or
> both. If you do not like the *doc* being unclear, clarify it.
>
>
>  A bytearray or a array.array may indeed store values, but a list stores
>> references to
>> objects.
>>
>
> I said exactly that in reference to CPython. As far as I know, the same is
> true of lists in every other implementation up until Pypy decided to
> optimize that away. What I also said is that I cannot read the *current*
> doc as guaranteeing that characterization. The reason is that the members
> of sequences, mutable sequences, and lists are all described as 'items'. In
> the first two cases, 'item' means 'value or object reference'. I see
> nothing in the doc to force a reader to change or particularized the
> meaning of 'item' in the third case. If I missed something *in the
> specification*, please point it out to me.
>
>
>  I'm pretty sure that not respecting identity of objects stored in
>> general-purpose containers would break a *lot* of code out there.
>>
>
> Me too. Hence I suggested that if lists, etc, are intended to respect
> identity, with 'is' as currently defined, in any implementation, then the
> docs should say so and end the discussion. I would be happy to commit an
> approved patch, but I am not in a position to decide the substantive
> content. Hence, I tried to provide a neutral analysis that avoided
> confusing the CPython implementation with the Python specification.
>
> In my final paragraph, however, I did suggest that Pypy respect precedent,
> to avoid breaking existing code and expectations, and call their mutable
> sequences something other than 'list'.
>

Wouldn't the entire point of such things existing in pypy be that the
implementation is irrelevant to the user and used behind the scenes
automatically in the common case when a container is determined to fit the
special constraint?

I personally do not think we should guarantee that "mylist[0] = x; assert x
is mylist[0]" succeeds when x is an immutable type other than None.  If
something is immutable and not intended to be a singleton and does not
define equality (like None or sentinel values commonly tested using is such
as arbitrary object() instances) it needs to be up to the language VM to
determine when to copy or not in most situations.

You already gave the example of the interned small integers in CPython.
 String constants and names used in code are also interned in today's
CPython implementation.  This doesn't tend to trip any real code up.

-gps
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 435: initial values must be specified? Yes

[Ethan Furman]

On 05/06/2013 07:58 PM, Tim Delaney wrote:


Considering that doesn't actually work with the reference implementation 
(AutoNumber.__new__ is never called) ... no.


Two points:

  1) Did you grab the latest code?  That exact implementation passes in the 
tests.

  2) You can write your __new__ however you want -- use ... !  ;)

--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 435: initial values must be specified? Yes

[Glenn Linderman]

On 5/6/2013 7:58 PM, Tim Delaney wrote:
On 7 May 2013 12:29, Ethan Furman > wrote:


On 05/05/2013 02:55 PM, Tim Delaney wrote:


So long as I can get one of the requirements documented to
implement an auto-number syntax I'll be happy enough with
stdlib enums I think.

class Color(AutoIntEnum):
 red = ...
 green = ...
 blue = ...


Will this do?

class AutoNumber(Enum):
def __new__(cls):
value = len(cls.__enum_info__) + 1
obj = object.__new__(cls)
obj._value = value
return obj
def __int__(self):
return self._value
class Color(AutoNumber):
red = ()
green = ()
blue = ()


Considering that doesn't actually work with the reference 
implementation (AutoNumber.__new__ is never called) ... no.


Maybe you should have tried with the latest version of the reference 
implementation, where Ethan kindly fixed the reference implementation to 
work better with NamedInt (per my thread "ref impl disc 2") and 
apparently also with the above class's __new__...




print(Color.red._value)
print(int(Color.red))

-- Run Python3 --
()
Traceback (most recent call last):
  File "D:\home\repos\mercurial\ref435\ref435.py", line 292, in 
print(int(Color.red))
TypeError: __int__ returned non-int (type tuple)

Plus I would not want to use the empty tuple for the purpose - at 
least ... implies something ongoing.


Why not? For classes derived from Enum, having __new__, the value/tuple 
assigned to the enumeration member becomes the set of parameters to 
__new__... so why would you want to provide a parameter?  Well, you 
could, with a minor tweak.  If you don't like Ethan's AutoNumber class, 
you can now write your own, like the following one that I derived from 
his, but to use your preferred ...


class AutoNumber(Enum):
def __new__(cls, parm):
obj = object.__new__(cls)
if parm is ...:
   value = len(cls.__enum_info__) + 1
obj._value = value
else:
obj._value = parm
return obj
def __int__(self):
return self._value
class Color(AutoNumber):
red = ...
green = ...
blue = 7
purple = ...

print ( Color.red, repr( Color.red ))
print ( Color.green, repr( Color.green ))
print ( Color.blue, repr( Color.blue ))
print ( Color.purple, repr( Color.purple ))

Since you want to provide a parameter, I decided in my example 
AutoNumber class that I would use ... as a flag to use his count, and 
anything else would be an actual value for the enumeration member.  You 
could do whatever else you like, of course, should you write your own, 
including using someone's suggested itertools.count()
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 435: initial values must be specified? Yes

[Tim Delaney]

On 7 May 2013 15:14, Tim Delaney  wrote:

> D'oh! I had my default path being my forked repo ... so didn't see the
> changes. BTW I can't see how that exact implementation passes ... not
> enough parameters declared in AutoNumber.__new__ ...
>

Sorry - my fault again - I'd already changed () to ...

Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 435 - ref impl disc 2

[Ethan Furman]

On 05/06/2013 08:35 PM, Glenn Linderman wrote:


N.B.  In your latest ref435.py code, line 105, should be "An Enum class _is_ final..." 
rather than "in".


Thanks, fixed.

--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 435: initial values must be specified? Yes

[Tim Delaney]

On 7 May 2013 15:14, Tim Delaney  wrote:

> Unfortunately, if you subclass AutoNumber from IntEnum it breaks.
>
> -- Run Python3 --
> Traceback (most recent call last):
>   File "D:\home\repos\mercurial\ref435\ref435.py", line 346, in 
> class Color(AutoNumber):
>   File "D:\home\repos\mercurial\ref435\ref435.py", line 184, in __new__
> enum_item = __new__(enum_class, *args)
> TypeError: int() argument must be a string or a number, not 'ellipsis'
>

Or using your exact implementation, but subclassing AutoNumber from IntEnum:

class AutoNumber(IntEnum):
def __new__(cls):
value = len(cls.__enum_info__) + 1
obj = object.__new__(cls)
obj._value = value
return obj
def __int__(self):
return self._value
class Color(AutoNumber):
red = ()
green = ()
blue = ()

print(repr(Color.red))

-- Run Python3 --


Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 435: initial values must be specified? Yes

[Tim Delaney]

On 7 May 2013 14:54, Ethan Furman  wrote:

> On 05/06/2013 07:58 PM, Tim Delaney wrote:
>
>>
>> Considering that doesn't actually work with the reference implementation
>> (AutoNumber.__new__ is never called) ... no.
>>
>
> Two points:
>
>   1) Did you grab the latest code?  That exact implementation passes in
> the tests.
>

D'oh! I had my default path being my forked repo ... so didn't see the
changes. BTW I can't see how that exact implementation passes ... not
enough parameters declared in AutoNumber.__new__ ...


>   2) You can write your __new__ however you want -- use ... !  ;)


class AutoNumber(Enum):
def __new__(cls, value):
if value is Ellipsis:
try:
value = cls._auto_number
except AttributeError:
value = cls._auto_number = 0
else:
cls._auto_number = int(value)

obj = object.__new__(cls)
obj._value = value
cls._auto_number += 1
return obj

def __int__(self):
return self._value

class Color(AutoNumber):
red = ...
green = 3
blue = ...

print(repr(Color.red))
print(repr(Color.green))
print(repr(Color.blue))

-- Run Python3 --




Unfortunately, if you subclass AutoNumber from IntEnum it breaks.

-- Run Python3 --
Traceback (most recent call last):
  File "D:\home\repos\mercurial\ref435\ref435.py", line 346, in 
class Color(AutoNumber):
  File "D:\home\repos\mercurial\ref435\ref435.py", line 184, in __new__
enum_item = __new__(enum_class, *args)
TypeError: int() argument must be a string or a number, not 'ellipsis'

I would probably also suggest 2 changes:

1. Set enum_item._name before calling enum_item.__init__.

2. Don't pass any arguments to enum_item.__init__ - the value should be set
in enum_item.__new__.

Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Fighting the theoretical randomness of "is" on immutables

[Antoine Pitrou]

On Mon, 06 May 2013 22:50:55 -0400
Terry Jan Reedy  wrote:
> 
> > A bytearray or a array.array may indeed store values, but a list stores 
> > references to
> > objects.
> 
> I said exactly that in reference to CPython. As far as I know, the same 
> is true of lists in every other implementation up until Pypy decided to 
> optimize that away. What I also said is that I cannot read the *current* 
> doc as guaranteeing that characterization.

In the absence of more precise specification, the reference is IMO the
reference interpreter, a.k.a. CPython, and its behaviour is more than
well-known and stable over time here.

> > I'm pretty sure that not respecting identity of objects stored in
> > general-purpose containers would break a *lot* of code out there.
> 
> Me too. Hence I suggested that if lists, etc, are intended to respect 
> identity, with 'is' as currently defined, in any implementation, then 
> the docs should say so and end the discussion. I would be happy to 
> commit an approved patch, but I am not in a position to decide the 
> substantive content.

For me, a patch that mandated general-purpose containers (list, dict,
etc.) respect object identity would be ok.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com