Re: why del is not a function or method?

[Ben Finney via Python-list]

Steve D'Aprano  writes:

> On Tue, 17 Oct 2017 03:16 am, Oren Ben-Kiki wrote:
>
> > That doesn't explain why `del` isn't a method though.
>
> `del` cannot be a method or a function, because the argument to `del`
> is the name of the variable, not the contents of the variable.

Since a Python “variable” does not have contents, this is IMO another
instance where using the term “variable” is not helpful.

>>> x = 123
>>> y = [0, x, 2, x, 4]

Neither of the names ‘x’ nor ‘y’ have content; they are references to
objects. The list itself also has references, which the Python code can
use to get at the items.

>>> y
[0, 123, 2, 123, 4]
>>> y[1]
123

So when we give an argument to ‘del’, that argument is not always a
“variable”; it is always a reference.

We can delete one item from a list, because that item is accessed via a
reference; we give the same reference as argument to ‘del’::

>>> del y[1]

Both ‘x’ and ‘y’ remain bound. The reference that was at index 1 of the
above list is deleted.

>>> x
123
>>> y
[0, 2, 123, 4]

> then `del` needs to delete the *name* "x", not the value of x, namely
> 123. If del were a function or method, it would only see the value,
> 123, and have no idea what the name is.

Hopefully when one thinks in terms of references – and the use of a
non-name reference, above, may make that distinction clear – the
operation of ‘del’ is easier to understand.

-- 
 \  “The shortest distance between two points is under |
  `\  construction.” —Noelie Alito |
_o__)  |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Native object exposing buffer protocol

[Ben Finney via Python-list]

Rob Gaddi  writes:

> I'd like to create a native Python object that exposes the buffer
> protocol.  Basically, something with a ._data member which is a
> bytearray that I can still readinto, make directly into a numpy array,
> etc.

The “etc.” seems pretty important, there. You want the behaviour of
‘bytearray’ without actually inheriting that behaviour from the
‘bytearray’ type.

So, it seems your options are:

* Enumerate all the things, specifically, that you do want your new type
  to do. Don't hide anything in “etc.”, so that you know exactly what
  behaviours need to be implemented. Implement all those behaviours,
  without benefit of inheriting from ‘bytearray’.

* Inherit from ‘bytearray’, but ameliorate the problems you want to
  avoid. This will require enumerating all those problems, so that you
  can know whether you have avoided them. Don't hide any of them in an
  “etc.”.

> Not the end of the world (the file's less than 2KB), but it seems like
> something that should be doable easily without having to throw around
> a lot of extraneous copies.

I look forward to your report from having tried it :-)

-- 
 \  “A lie can be told in a few words. Debunking that lie can take |
  `\   pages. That is why my book… is five hundred pages long.” —Chris |
_o__)Rodda, 2011-05-05 |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why does __ne__ exist?

[Ben Finney via Python-list]

Chris Angelico  writes:

> On Mon, Jan 8, 2018 at 10:55 AM, Ben Finney  
> wrote:
> > We've established that it is useful to allow data types to define
> > their own meaning of “equal” and “not equal”, like many other
> > operations. Is that not good enough reason to allow it still?
>
> The fact that container types can define "contains" but can't define
> "doesn't contain", and that (as of Py3) there's proper default
> handling, suggests that it's not as big a priority now.

That is an inconsistency, I agree.

> Let's put it this way. Suppose that __eq__ existed and __ne__ didn't,
> just like with __contains__. Go ahead: sell the notion of __ne__.
> Pitch it, show why we absolutely need to allow this.

I think “reject unless absolutely needed” is an unreasonably high bar,
which would disqualify most Python language features. So I don't know
why you expect this to be so especially strongly argued.

> Make sure you mention the potential confusion when subclassing.

For example, that would alsop be a problem for multiple inheritance. Not
“absolutely needed”, and high risk of confusion when subclassing. Do you
think that multiple inheritance would thereby also not be allowed today?

If you consider that a different case, why?

-- 
 \ “First they came for the verbs, and I said nothing, for verbing |
  `\weirds language. Then, they arrival for the nouns and I speech |
_o__)   nothing, for I no verbs.” —Peter Ellis |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: $srcdir and $datadir

[Ben Finney via Python-list]

Victor Porton  writes:

> I want my program to work both when it is installed (using $datadir)
> and when it is not yet installed (using $srcdir).

Given your descriptions of both those, I don't see how it can reliably
work; the program will expect directories that may not exist. Why
hard-code them at all, then?

So, I am going to have to ignore the “$srcdir and $datadir” specifics,
and address the stated intent.

The current convention in Python build systems is the Setuptools
library. You will be familiar with the ‘setup.py’ top-level script for
co-ordinating Setuptools actions on a code base.

The installation tool ‘pip’ works with Setuptools data. Use it to
install your distribution from PyPI for production use; use it to
install your code base from local directories for testing; use it with
special options to “install” your code in a development mode while you
work on it.

https://pip.pypa.io/en/stable/reference/pip_install/#usage>
https://pip.pypa.io/en/stable/reference/pip_install/#editable-installs>

-- 
 \“Always code as if the guy who ends up maintaining your code |
  `\ will be a violent psychopath who knows where you live.” —John |
_o__) F. Woods |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Valid encodings for a Python source file

[Ben Finney via Python-list]

Daniel Glus  writes:

> I'm trying to figure out the entire list of possible encodings for a Python
> source file - that is, encodings that can go in a PEP 263
>  encoding specification, like #
> -*- encoding: foo -*-.

What if the answer is not an emunerated set of encodings? That is, I am
pretty sure the set isn't specified, to allow the encoding to be
negotiated. Whatever the interpreter recognises as an encoding can be
the encoding of the source.

So, I guess that leads to the question: Why do you need it to be an
exhaustive set (rather than deliberately unspecified)? What are you
hoping to do with that information?

-- 
 \   “Good design adds value faster than it adds cost.” —Thomas C. |
  `\  Gale |
_o__)  |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PEP 526 - var annotations and the spirit of python

[Ben Finney via Python-list]

Jim Lee  writes:

> If you were to say John had 2 apples, Jane had 4 apples, and Joe had
> an indefinite number of apples, how many numbers are we talking about?

Three numbers. And “indefinite” is not one of those numbers. So, no,
that doesn't support “"indefinite" is a number”.

-- 
 \“That's the essence of science: Ask an impertinent question, |
  `\and you're on the way to the pertinent answer.” —Jacob |
_o__) Bronowski, _The Ascent of Man_, 1973 |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list