[Python-ideas] Temporary variables in comprehensions

[fhsxfhsx]

As far as I can see, a comprehension like
alist = [f(x) for x in range(10)]
is better than a for-loop
for x in range(10):
  alist.append(f(x))
because the previous one shows every element of the list explicitly so that we 
don't need to handle `append` mentally.

But when it comes to something like
[f(x) + g(f(x)) for x in range(10)]
you find you have to sacrifice some readableness if you don't want two f(x) 
which might slow down your code.

Someone may argue that one can write
[y + g(y) for y in [f(x) for x in range(10)]]
but it's not as clear as to show what `y` is in a subsequent clause, not to say 
there'll be another temporary list built in the process.
We can even replace every comprehension with map and filter, but that would 
face the same problems.

In a word, what I'm arguing is that we need a way to assign temporary variables 
in a comprehension.
In my opinion, code like
[y + g(y) for x in range(10) **some syntax for `y=f(x)` here**]
is more natural than any solution we now have.
And that's why I pro the new syntax, it's clear, explicit and readable, and is 
nothing beyond the functionality of the present comprehensions so it's not 
complicated.

And I hope the discussion could focus more on whether we should allow assigning 
temporary variables in comprehensions rather than how to solve the specific 
example I mentioned above.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Give ipaddresses an __index__ method

[Steven D'Aprano]

On Thu, Feb 15, 2018 at 01:39:13PM +1000, Nick Coghlan wrote:

> There are tests that ensure IP addresses don't implement __index__,
> and the pragmatic reason for that is the downside you mentioned: to
> ensure they can't be used as indices, slice endpoints, or range
> endpoints.

If it is an intentional decision to disallow treating IP addresses as 
integers implicitly, I guess that is definite then. No change. I can see 
that this is a reasonable decision for pragmatic reasons.

However, for the record (and under no illusion that I'll change your 
mind *wink*) ...


> While IP addresses can be converted to an integer, they are
> *not* integers in any mathematical sense, and it doesn't make sense to
> treat them that way.

I really don't think this is strictly correct. IP addresses already 
support adding to regular ints, and conceptually they are indexes into a 
32-bit or 128-bit space. They define "successor" and "predecessor" 
relations via addition and subtraction, which is pretty much all you 
need to build all other int operations from, mathematically speaking. 
(Actually, you don't even need predecessor.) I think there's a good case 
to make that they are ordinal numbers (each IP address uniquely 
specifies a logical position in a sequence from 0 to 2**32-1).

Python ints already do quadruple duty as:

- ordinal numbers, e.g. indexing, "string".find("r");

- cardinal numbers, e.g. counting, len("string");

- nominal numbers, e.g. id(obj);

- subset of the Reals in the numeric tower.

But anyway, at this point the discussion is getting rather esoteric. 
I accept the argument from pragmatism that the benefit of supporting 
__index__ is less than the disadvantage, so I think we're done here :-)



-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Boolean ABC similar to what's provided in the 'numbers' module

[Guido van Rossum]

On Wed, Feb 14, 2018 at 5:49 PM, Chris Barker - NOAA Federal <
chris.bar...@noaa.gov> wrote:

> >
> > So as long as you are not expecting to ever need mypy you should be fine
> -- however if you're sharing code at some point someone is probably going
> to want to point mypy at it.
>
> mypy isn’t an “official” tool, but PEP484 is — and mypy is more or
> less a reference implimentation, yes?
>

Except PEP 484 is silent on many, many details. So far from all of mypy's
behavior is normative.

However, in this case PEP 484 has an opinion on the numbers module (don't
use it, just use int).


> mypy support bool, as far as I can tell, will that not work for your case?
>
> Even though the python bools are integer subclasses, that doesn’t mean
> a type checker shouldn’t flag passing an integer in to a function that
> expects a bool.
>

That's not the issue.

The issue is that, from mypy's POV, np.bool is not a subtype of
builtins.bool, just like the various np.intXX types aren't subtypes of
builtins.int. But IMO the solution is to lie about this in the stubs and
make the np types subtypes of the builtin types, not to switch to
numbers.Integral. And the reason is that few people (outside hardcore np
fans) will want to write numbers.Integral instead of int.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Give ipaddresses an __index__ method

[Dan Sommers]

On Thu, 15 Feb 2018 15:14:03 +1100, Steven D'Aprano wrote:

> On Thu, Feb 15, 2018 at 11:45:46AM +1100, Chris Angelico wrote:
> 
>> Except that this computer's IPv4 is not 3232235539, and I never want
>> to enter it that way. I enter it as 192.168.0.19 - as four separate
>> integers.
> 
> That's partly convention (and a useful convention: it is less error- 
> prone than 3232235539) and partly that because you're a sys admin who 
> can read the individual subfields of an IP address. I'm not suggesting 
> you ought to change your habit.
> 
> But to civilians, 192.168.0.19 is as opaque as 3232235539 or 0xC0A80013 
> would be.

There was a lengthy discussion (or more than one) about supporting
decimal unicode code point literals.  Is U+03B1 (GREEK SMALL LETTER
ALPHA) somehow less clear than X+945?

192.168.0.19 speaks volumes, but 3232235539 is not only opaque, but also
obtuse.

> But doing *at least some* int operations on addresses isn't meaningless:
> 
> py> a = ipaddress.ip_address('192.168.0.19')
> py> a + 1
> IPv4Address('192.168.0.20')

py> a = ipaddress.ip_address('192.168.1.255')
> py> a + 1
> IPv4Address('192.168.1.256')

Uh, oh.

py> a = ipaddress.ip_address('255.255.255.255')
> py> a + 1

Mu?

Yes, if I were writing a DHCP server, the notion of "the next IP address
that meets certain constraints, or an exception if no such address
exists" has meaning.  But it's not as simple as "ip + 1."

Dan

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Give ipaddresses an __index__ method

[Chris Angelico]

On Thu, Feb 15, 2018 at 3:14 PM, Steven D'Aprano  wrote:
> On Thu, Feb 15, 2018 at 11:45:46AM +1100, Chris Angelico wrote:
>
>> Except that this computer's IPv4 is not 3232235539, and I never want
>> to enter it that way. I enter it as 192.168.0.19 - as four separate
>> integers.
>
> That's partly convention (and a useful convention: it is less error-
> prone than 3232235539) and partly that because you're a sys admin who
> can read the individual subfields of an IP address. I'm not suggesting
> you ought to change your habit.
>
> But to civilians, 192.168.0.19 is as opaque as 3232235539 or 0xC0A80013
> would be.

To some people, any form of address is as opaque as any other, true.
(That's part of why we have DNS.) Also true, however, is that the
conventional notation has value and meaning. That's partly historical
(before CIDR, all networks were sized as either class A (10.x.y.z for
any x, y, z), class B (172.16.x.y), or class C (192.168.0.x)), partly
self-perpetuating (we use a lot of /24 addresses in local networks,
not because we HAVE to, but because a /24 lets you lock three parts of
the address and have the last part vary), but also definitely
practical.

> We allow creating IP address objects from a single int, we don't require
> four separate int arguments (one for each subfield), and unless I've
> missed something, IP addresses are not treated as a collection of four
> separate integers (or more for v6). I can't even find a method to split
> an address into four ints. (Nor am I sure that there is good reason to
> want to do so.) So calling a single address "four separate integers" is
> not really accurate.

The most common way to create an IPv4Address object is to construct it
from a string, which has the four separate integers in it. The dots
delimit those integers. It's not an arbitrary string; it is most
definitely a tuple of four integers, represented in its standard
string notation. Simply because it's not actually the Python type
Tuple[Int] doesn't mean it isn't functionally and logically a sequence
of numbers.

And if ever you actually do have the four integers, you can use a
one-liner anyway:

>>> address = (192, 168, 0, 19)
>>> ipaddress.IPv4Address("%d.%d.%d.%d" % address)
IPv4Address('192.168.0.19')

> It is meaningless to perform string operations on IP addresses. What
> would it mean to call addr.replace('.', 'Z') or addr.split('2')?
>
> But doing *at least some* int operations on addresses isn't meaningless:
>
> py> a = ipaddress.ip_address('192.168.0.19')
> py> a + 1
> IPv4Address('192.168.0.20')

How meaningful is that, when you don't have the netmask?

>>> a = ipaddress.ip_address('192.168.0.254')
>>> a + 1
IPv4Address('192.168.0.255')
>>> a + 2
IPv4Address('192.168.1.0')
>>> a + 3
IPv4Address('192.168.1.1')

If that's a /24, one of those is a broadcast address, one is an
unrelated network address, and one is an unrelated host address.
"Adding 1" to an IP address is meaningless. And it definitely does NOT
mean that IP addresses should have __index__, because that implies
that they truly are integers, which would mean you could do something
like this:

>>> ipaddress.IPv4Address('192.168.0.19') + ipaddress.IPv4Address("10.1.1.1")
Traceback (most recent call last):
  File "", line 1, in 
TypeError: unsupported operand type(s) for +: 'IPv4Address' and 'IPv4Address'

The __int__ method *converts* something to an integer. Nobody is
disagreeing that you can convert an IP address into an integer. But
they are NOT integers. It doesn't make sense to treat one as an
integer implicitly.

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Give ipaddresses an __index__ method

[Steven D'Aprano]

On Thu, Feb 15, 2018 at 11:45:46AM +1100, Chris Angelico wrote:

> Except that this computer's IPv4 is not 3232235539, and I never want
> to enter it that way. I enter it as 192.168.0.19 - as four separate
> integers.

That's partly convention (and a useful convention: it is less error- 
prone than 3232235539) and partly that because you're a sys admin who 
can read the individual subfields of an IP address. I'm not suggesting 
you ought to change your habit.

But to civilians, 192.168.0.19 is as opaque as 3232235539 or 0xC0A80013 
would be.

We allow creating IP address objects from a single int, we don't require 
four separate int arguments (one for each subfield), and unless I've 
missed something, IP addresses are not treated as a collection of four 
separate integers (or more for v6). I can't even find a method to split 
an address into four ints. (Nor am I sure that there is good reason to 
want to do so.) So calling a single address "four separate integers" is 
not really accurate.


[...]
> IP addresses can be losslessly converted to and from strings, too, and
> that's a lot more useful. But they still don't have string methods,
> because they're not strings.

I agree they're not strings, I never suggested they were. Python only 
allows IP addresses to be entered as strings because we don't have a 
"dotted-quad" syntax for 32-bit integers. (Nor am I suggesting we 
should.)

It is meaningless to perform string operations on IP addresses. What 
would it mean to call addr.replace('.', 'Z') or addr.split('2')?

But doing *at least some* int operations on addresses isn't meaningless:

py> a = ipaddress.ip_address('192.168.0.19')
py> a + 1
IPv4Address('192.168.0.20')



-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Extending __format__ method in ipaddress

[Nick Coghlan]

On 15 February 2018 at 08:29, Eric Osborne  wrote:
>   Nick Coghlan suggested I instead extend __format__, which is what the
> diffs in the current pull request do.  This allows a great deal more
> flexibility: the current code takes 'b', 'n', or 'x' types, as well as the
> '#' option and support for the '_' separator.

+1 from me (unsurprisingly).

We added __format__ specifically to give types more control over how
they're printed, and this approach is amenable to the simple
explanation that the custom IP address formatting works via:

- conversion to int
- printing in a fixed width field (based on the address size)
- in binary or hex based on either the given format character, or the
address size ("n", where IPv4=b and IPv6=x)
- with a suitable prefix if "#" is given
- with four-digit separators if "_" is given

>  I realize now I didn't add
> 'o' but I certainly can for completeness.

I'd suggest leaving it out, as octal characters are 3 bits each, so
they don't have a natural association with IP address representations
any more than decimal representation does (neither 32 nor 128 are
divisible by 3).

>  I debated adding rfc1924 encoding
> for IPv6 addresses but decided it was entirely too silly.

Yeah, if we decided to support that, we likely *would* add a separate
method for it.

__format__ works well for "print an IP address as an integer with
zero-padding and an automatically calculated field width" though,
since we can borrow the notation from regular integer formatting to
select the digit base and tweak the display details.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Give ipaddresses an __index__ method

[Nick Coghlan]

On 15 February 2018 at 10:18, Steven D'Aprano  wrote:
> This idea is inspired by Eric Osborne's post "Extending __format__
> method in ipaddress", but I wanted to avoid derailing that thread.
>
> I notice what seems to be an inconsistency in the ipaddress objects:
>
> py> v4 = ipaddress.IPv4Address('1.2.3.4')
> py> bin(v4)
> Traceback (most recent call last):
>   File "", line 1, in 
> TypeError: 'IPv4Address' object cannot be interpreted as an integer

That error message should probably either have an "implicitly" in it,
or else use the word "handled" rather than "interpreted".

There are tests that ensure IP addresses don't implement __index__,
and the pragmatic reason for that is the downside you mentioned: to
ensure they can't be used as indices, slice endpoints, or range
endpoints. While IP addresses can be converted to an integer, they are
*not* integers in any mathematical sense, and it doesn't make sense to
treat them that way.

A useful heuristic for answering the question "Should this type
implement __index__?" is "Does this type conform to the
numbers.Integral ABC?" (IP addresses definitely don't, as there's no
concept of addition, subtraction, multiplication, division, etc -
they're discrete entities with a numeric representation, not numbers)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Extending __format__ method in ipaddress

[Ethan Furman]

On 02/14/2018 02:29 PM, Eric Osborne wrote:


Nick Coghlan suggested I instead extend __format__, which is what the diffs in 
the current pull request do.  This
allows a great deal more flexibility: the current code takes 'b', 'n', or 'x' 
types, as well as the '#' option and
support for the '_' separator.  I realize now I didn't add 'o' but I certainly 
can for completeness.  I debated adding
rfc1924 encoding for IPv6 addresses but decided it was entirely too silly.

This is just a convenience function, but IMO fills a need.  Is this worth 
pursuing?


Seems like a good idea to me!

--
~Ethan~

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Boolean ABC similar to what's provided in the 'numbers' module

[Chris Barker - NOAA Federal]

>
> So as long as you are not expecting to ever need mypy you should be fine -- 
> however if you're sharing code at some point someone is probably going to 
> want to point mypy at it.

mypy isn’t an “official” tool, but PEP484 is — and mypy is more or
less a reference implimentation, yes?

mypy support bool, as far as I can tell, will that not work for your case?

Even though the python bools are integer subclasses, that doesn’t mean
a type checker shouldn’t flag passing an integer in to a function that
expects a bool.

-CHB
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Give ipaddresses an __index__ method

[Chris Angelico]

On Thu, Feb 15, 2018 at 11:18 AM, Steven D'Aprano  wrote:
> This idea is inspired by Eric Osborne's post "Extending __format__
> method in ipaddress", but I wanted to avoid derailing that thread.
>
> I notice what seems to be an inconsistency in the ipaddress objects:
>
> py> v4 = ipaddress.IPv4Address('1.2.3.4')
> py> bin(v4)
> Traceback (most recent call last):
>   File "", line 1, in 
> TypeError: 'IPv4Address' object cannot be interpreted as an integer
>
> But that's surely not right: we just need to explicitly do so:
>
> py> bin(int(v4))
> '0b1001000110100'
>
> IP addresses are, in a strong sense, integers: either 32 or 128 bits.
> And they can be explicitly converted losslessly to and from integers:
>

Except that this computer's IPv4 is not 3232235539, and I never want
to enter it that way. I enter it as 192.168.0.19 - as four separate
integers. The __index__ method means "this thing really is an integer,
and can be used as an index". With IPv6, similar: you think about them
as eight separate blocks of digits.

IP addresses can be losslessly converted to and from strings, too, and
that's a lot more useful. But they still don't have string methods,
because they're not strings.

> I acknowledge one potentially undesirable side-effect: this would
> allow using IP addresses as indexes into sequences:
>
> py> 'abcdef'[X('0.0.0.2')]
> 'c'
>
> but while it's weird to do this, I don't think it's logically wrong.

That's not a side effect. That is the *primary* effect of __index__.
If you call int() on something, you are *converting* it to an integer
(eg int(2.3) ==> 2), and IMO that is the appropriate way to turn
192.168.0.19 into 3232235539 if ever you want that.

Unless you have a use-case for using IP addresses as integers,
distinct from Eric's ideas?

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Give ipaddresses an __index__ method

[Steven D'Aprano]

This idea is inspired by Eric Osborne's post "Extending __format__ 
method in ipaddress", but I wanted to avoid derailing that thread.

I notice what seems to be an inconsistency in the ipaddress objects:

py> v4 = ipaddress.IPv4Address('1.2.3.4')
py> bin(v4)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: 'IPv4Address' object cannot be interpreted as an integer

But that's surely not right: we just need to explicitly do so:

py> bin(int(v4))
'0b1001000110100'

IP addresses are, in a strong sense, integers: either 32 or 128 bits. 
And they can be explicitly converted losslessly to and from integers:

py> v4 == ipaddress.IPv4Address(int(v4))
True

Is there a good reason not to give them an __index__ method so that 
bin(), oct() and hex() will work directly?

py> class X(ipaddress.IPv4Address):
... def __index__(self):
... return int(self)
...
py> a = X('1.2.3.4')
py> bin(a)
'0b1001000110100'

I acknowledge one potentially undesirable side-effect: this would 
allow using IP addresses as indexes into sequences:

py> 'abcdef'[X('0.0.0.2')]
'c'

but while it's weird to do this, I don't think it's logically wrong.


-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Boolean ABC similar to what's provided in the 'numbers' module

[Guido van Rossum]

No, PyCharm has its own annotation checker, which is much more lenient than
mypy (and less compliant with PEP 484). And indeed the runtime checkers are
also unrelated (though a runtime checker will have to work with the type
objects created by typing.py).

So as long as you are not expecting to ever need mypy you should be fine --
however if you're sharing code at some point someone is probably going to
want to point mypy at it.

On Wed, Feb 14, 2018 at 2:36 PM, Sylvain MARIE <
sylvain.ma...@schneider-electric.com> wrote:

> I see :)
>
>
>
> This does not seem to happen with PyCharm IDE + Anaconda distribution. Is
> PyCharm relying on MyPy under the hood ?
>
> I actually have no knowledge at all about MyPy and how it relates to
> PyCharm static code analysis warnings. I’m pretty sure though that the
> runtime checkers (enforce, pytypes) are not dependent on MyPy.
>
>
>
> Sylvain
>
>
>
> *De :* gvanros...@gmail.com [mailto:gvanros...@gmail.com] *De la part de*
> Guido van Rossum
> *Envoyé :* mercredi 14 février 2018 19:47
> *À :* Sylvain MARIE 
>
> *Cc :* python-ideas 
> *Objet :* Re: [Python-ideas] Boolean ABC similar to what's provided in
> the 'numbers' module
>
>
>
> I am mystified how you can be using the numbers package with mypy. Example:
>
> import numbers
> def f(a: numbers.Integral, b: numbers.Integral) -> numbers.Integral:
>   return a + b
> f(12, 12)
>
> This gives an two errors on the last line when checked by mypy:
>
> _.py:10: error: Argument 1 to "f" has incompatible type "int"; expected
> "Integral"
> _.py:10: error: Argument 2 to "f" has incompatible type "int"; expected
> "Integral"
>
>
>
> On Tue, Feb 13, 2018 at 1:21 AM, Sylvain MARIE  electric.com> wrote:
>
> The main use case I had in mind was PEP484-based type hinting/checking
> actually:
>
>
>
> def my_function(foo: Boolean):
>
> pass
>
>
>
> explicitly states that my_function accepts any Boolean value, whether it
> is a python bool or a np.bool that would come from a numpy array or pandas
> dataframe.
>
> Note that type hinting is also the use case for which I make extensive use
> of the types from the ‘numbers’ package, for the same reasons.
>
>
>
> Sylvain
>
>
>
> *De :* Python-ideas [mailto:python-ideas-bounces+sylvain.marie=schneider-
> electric@python.org] *De la part de* David Mertz
> *Envoyé :* mardi 13 février 2018 07:08
> *À :* Nick Coghlan 
> *Cc :* python-ideas 
> *Objet :* Re: [Python-ideas] Boolean ABC similar to what's provided in
> the 'numbers' module
>
>
>
> I'm not sure I'm convinced by Sylvain that Boolean needs to be an ABC in
> the standard library; Guido expresses skepticism.  Of course it is possible
> to define it in some other library that actually needs to use
> `isinstance(x, Boolean)` as Sylvain demonstraits in his post.  I'm not sure
> I'm unconvinced either, I can see a certain value to saying a given value
> is "fully round-trippable to bool" (as is np.bool_).
>
>
>
> But just for anyone who doesn't know NumPy, here's a quick illustration of
> what I alluded to:
>
>
>
> In [1]: import numpy as np
>
> In [2]: arr = np.array([7,8,12,33])
>
> In [3]: ndx1 = np.array([0,1,1,0], dtype=int)
>
> In [4]: ndx2 = np.array([0,1,1,0], dtype=bool)
>
> In [5]: arr[ndx1]
>
> Out[5]: array([7, 8, 8, 7])
>
> In [6]: arr[ndx2]
>
> Out[6]: array([ 8, 12])
>
>
>
> ndx1 and ndx2 are both nice things (and are both often programmatically
> constructed by operations in NumPy).  But indexing using ndx1 gives us an
> array of the things in the listed *positions* in arr.  In this case, we
> happen to choose two each of the things an index 0 and index 1 in the
> result.
>
>
>
> Indexing by ndx2 gives us a filter of only those positions in arr
> corresponding to 'True's.  These are both nice things to be able to do, but
> if NumPy's True was a special kind of 1, it wouldn't work out
> unambiguously.  However, recent versions of NumPy *have* gotten a bit
> smarter about recognizing the special type of Python bools, so it's less of
> a trap than it used to be.  Still, contrast these (using actual Python
> lists for the indexes:
>
>
>
> In [10]: arr[[False, True, True, False]]
>
> Out[10]: array([ 8, 12])
>
> In [11]: arr[[False, True, 1, 0]]
>
> Out[11]: array([7, 8, 8, 7])
>
>
>
>
>
>
>
> On Mon, Feb 12, 2018 at 7:50 PM, Nick Coghlan  wrote:
>
> On 13 February 2018 at 02:14, David Mertz  wrote:
> > NumPy np.bool_ is specifically not a subclass of any np.int_.  If it
> we're,
> > there would be an ambiguity between indexing with a Boolean array and an
> > array of ints. Both are meaningful, but they mean different things (mask
> vs
> > collection of indices).
> >
> > Do we have other examples a Python ABC that exists to accommodate
> something
> > outside the standard library or builtins? Even if not, NumPy is
> special...
> > the actual syntax for '@' exists primarily for that library!
>
> collections.abc.Sequence and collections.abc.Mapping come to mind -
> the standard library doesn't tend to distinguish between differen

Re: [Python-ideas] Boolean ABC similar to what's provided in the 'numbers' module

[Sylvain MARIE]

I see :)

This does not seem to happen with PyCharm IDE + Anaconda distribution. Is 
PyCharm relying on MyPy under the hood ?
I actually have no knowledge at all about MyPy and how it relates to PyCharm 
static code analysis warnings. I’m pretty sure though that the runtime checkers 
(enforce, pytypes) are not dependent on MyPy.

Sylvain

De : gvanros...@gmail.com [mailto:gvanros...@gmail.com] De la part de Guido van 
Rossum
Envoyé : mercredi 14 février 2018 19:47
À : Sylvain MARIE 
Cc : python-ideas 
Objet : Re: [Python-ideas] Boolean ABC similar to what's provided in the 
'numbers' module

I am mystified how you can be using the numbers package with mypy. Example:

import numbers
def f(a: numbers.Integral, b: numbers.Integral) -> numbers.Integral:
  return a + b
f(12, 12)
This gives an two errors on the last line when checked by mypy:

_.py:10: error: Argument 1 to "f" has incompatible type "int"; expected 
"Integral"
_.py:10: error: Argument 2 to "f" has incompatible type "int"; expected 
"Integral"

On Tue, Feb 13, 2018 at 1:21 AM, Sylvain MARIE 
mailto:sylvain.ma...@schneider-electric.com>>
 wrote:
The main use case I had in mind was PEP484-based type hinting/checking actually:

def my_function(foo: Boolean):
pass

explicitly states that my_function accepts any Boolean value, whether it is a 
python bool or a np.bool that would come from a numpy array or pandas dataframe.
Note that type hinting is also the use case for which I make extensive use of 
the types from the ‘numbers’ package, for the same reasons.

Sylvain

De : Python-ideas 
[mailto:python-ideas-bounces+sylvain.marie=schneider-electric@python.org]
 De la part de David Mertz
Envoyé : mardi 13 février 2018 07:08
À : Nick Coghlan mailto:ncogh...@gmail.com>>
Cc : python-ideas mailto:python-ideas@python.org>>
Objet : Re: [Python-ideas] Boolean ABC similar to what's provided in the 
'numbers' module

I'm not sure I'm convinced by Sylvain that Boolean needs to be an ABC in the 
standard library; Guido expresses skepticism.  Of course it is possible to 
define it in some other library that actually needs to use `isinstance(x, 
Boolean)` as Sylvain demonstraits in his post.  I'm not sure I'm unconvinced 
either, I can see a certain value to saying a given value is "fully 
round-trippable to bool" (as is np.bool_).

But just for anyone who doesn't know NumPy, here's a quick illustration of what 
I alluded to:

In [1]: import numpy as np
In [2]: arr = np.array([7,8,12,33])
In [3]: ndx1 = np.array([0,1,1,0], dtype=int)
In [4]: ndx2 = np.array([0,1,1,0], dtype=bool)
In [5]: arr[ndx1]
Out[5]: array([7, 8, 8, 7])
In [6]: arr[ndx2]
Out[6]: array([ 8, 12])

ndx1 and ndx2 are both nice things (and are both often programmatically 
constructed by operations in NumPy).  But indexing using ndx1 gives us an array 
of the things in the listed positions in arr.  In this case, we happen to 
choose two each of the things an index 0 and index 1 in the result.

Indexing by ndx2 gives us a filter of only those positions in arr corresponding 
to 'True's.  These are both nice things to be able to do, but if NumPy's True 
was a special kind of 1, it wouldn't work out unambiguously.  However, recent 
versions of NumPy have gotten a bit smarter about recognizing the special type 
of Python bools, so it's less of a trap than it used to be.  Still, contrast 
these (using actual Python lists for the indexes:

In [10]: arr[[False, True, True, False]]
Out[10]: array([ 8, 12])
In [11]: arr[[False, True, 1, 0]]
Out[11]: array([7, 8, 8, 7])



On Mon, Feb 12, 2018 at 7:50 PM, Nick Coghlan 
mailto:ncogh...@gmail.com>> wrote:
On 13 February 2018 at 02:14, David Mertz 
mailto:me...@gnosis.cx>> wrote:
> NumPy np.bool_ is specifically not a subclass of any np.int_.  If it we're,
> there would be an ambiguity between indexing with a Boolean array and an
> array of ints. Both are meaningful, but they mean different things (mask vs
> collection of indices).
>
> Do we have other examples a Python ABC that exists to accommodate something
> outside the standard library or builtins? Even if not, NumPy is special...
> the actual syntax for '@' exists primarily for that library!

collections.abc.Sequence and collections.abc.Mapping come to mind -
the standard library doesn't tend to distinguish between different
kinds of subscriptable objects, but it's a distinction some third
party libraries and tools want to be able to make reliably.

The other comparison that comes to mind would be the distinction
between "__int__" ("can be coerced to an integer, but may lose
information in the process") and "__index__" ("can be losslessly
converted to and from a builtin integer").

Right now, we only define boolean coercion via "__bool__" - there's no
mechanism to say "this *is* a boolean value that can be losslessly
converted to and from the builtin boolean constants". That isn't a
distinction the standard library

[Python-ideas] Extending __format__ method in ipaddress

[Eric Osborne]

Folks-

  The ipaddress library returns an IP address object which can represent
itself in a number of ways:


In [1]: import ipaddress

In [2]: v4 = ipaddress.IPv4Address('1.2.3.4')

In [3]: print(v4)
1.2.3.4

In [4]: v4
Out[4]: IPv4Address('1.2.3.4')

In [6]: v4.packed
Out[6]: b'\x01\x02\x03\x04'

In [9]: str(v4)
Out[9]: '1.2.3.4'

In [10]: int(v4)
Out[10]: 16909060

In [13]: bin(int(v4))
Out[13]: '0b1001000110100'

In [14]: hex(int(v4))
Out[14]: '0x1020304'

In [15]: oct(int(v4))
Out[15]: '0o100401404'

There are IPv6 objects as well:

In [6]: v6 =
ipaddress.IPv6Address('2001:0db8:85a3:::8a2e:0370:7334')

In [7]: int(v6)
Out[7]: 42540766452641154071740215577757643572

and what I'm proposing will work for both address families.
In either case, bin/hex/oct don't work on them directly, but on the integer
representation.  This is a little annoying but not such a big deal.  What
is a big deal (at least to me) is that the binary representation isn't
zero-padded.  This makes it harder to compare two IP addresses by eye to
see what the differences are, i.e.:

In [16]: a = ipaddress.IPv4Address('0.2.3.4')
In [30]: bin(int(a))
Out[30]: '0b1000110100'

In [31]: bin(int(v4))
Out[31]: '0b1001000110100'

  It would be nice if there was a way to have an IP address always present
itself in fully zero-padded binary (32 bits for IPv4, 128 bits for IPv6).
I find this particularly convenient when putting together  training
material, as it's easier to show subnetting and aggregation if you point at
the binary than if you give people dotted-quad addresses and ask them to do
the binary conversion in their head.  Hex is also handy when you're
comparing a dotted-quad IP address to a hex sniffer trace.  It's possible
to do this in a one-liner (thanks to Eric Smith): f'{int(v4):#0{34}b}'.  But
this is a little cryptic.

  I opened bpo-32820 (https://github.com/python/cpython/pull/5627) to
contribute a way to do this.  I started with an __index__ method but Issue
15559 (
https://github.com/python/cpython/commit/e0c3f5edc0f20cc28363258df501758c1bdb1ca7)
rules this out.  I instead added a bits() class method so that v4.bits
would return the fully padded string.  This was not terribly pretty, but it
mirrored packed(), at least.

  Nick Coghlan suggested I instead extend __format__, which is what the
diffs in the current pull request do.  This allows a great deal more
flexibility: the current code takes 'b', 'n', or 'x' types, as well as the
'#' option and support for the '_' separator.  I realize now I didn't add
'o' but I certainly can for completeness.  I debated adding rfc1924
encoding for IPv6 addresses but decided it was entirely too silly.

  This is just a convenience function, but IMO fills a need.  Is this worth
pursuing?





eric
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Boolean ABC similar to what's provided in the 'numbers' module

[Guido van Rossum]

I am mystified how you can be using the numbers package with mypy. Example:

import numbers
def f(a: numbers.Integral, b: numbers.Integral) -> numbers.Integral:
  return a + b
f(12, 12)

This gives an two errors on the last line when checked by mypy:

_.py:10: error: Argument 1 to "f" has incompatible type "int"; expected
"Integral"
_.py:10: error: Argument 2 to "f" has incompatible type "int"; expected
"Integral"


On Tue, Feb 13, 2018 at 1:21 AM, Sylvain MARIE <
sylvain.ma...@schneider-electric.com> wrote:

> The main use case I had in mind was PEP484-based type hinting/checking
> actually:
>
>
>
> def my_function(foo: Boolean):
>
> pass
>
>
>
> explicitly states that my_function accepts any Boolean value, whether it
> is a python bool or a np.bool that would come from a numpy array or pandas
> dataframe.
>
> Note that type hinting is also the use case for which I make extensive use
> of the types from the ‘numbers’ package, for the same reasons.
>
>
>
> Sylvain
>
>
>
> *De :* Python-ideas [mailto:python-ideas-bounces+sylvain.marie=schneider-
> electric@python.org] *De la part de* David Mertz
> *Envoyé :* mardi 13 février 2018 07:08
> *À :* Nick Coghlan 
> *Cc :* python-ideas 
> *Objet :* Re: [Python-ideas] Boolean ABC similar to what's provided in
> the 'numbers' module
>
>
>
> I'm not sure I'm convinced by Sylvain that Boolean needs to be an ABC in
> the standard library; Guido expresses skepticism.  Of course it is possible
> to define it in some other library that actually needs to use
> `isinstance(x, Boolean)` as Sylvain demonstraits in his post.  I'm not sure
> I'm unconvinced either, I can see a certain value to saying a given value
> is "fully round-trippable to bool" (as is np.bool_).
>
>
>
> But just for anyone who doesn't know NumPy, here's a quick illustration of
> what I alluded to:
>
>
>
> In [1]: import numpy as np
>
> In [2]: arr = np.array([7,8,12,33])
>
> In [3]: ndx1 = np.array([0,1,1,0], dtype=int)
>
> In [4]: ndx2 = np.array([0,1,1,0], dtype=bool)
>
> In [5]: arr[ndx1]
>
> Out[5]: array([7, 8, 8, 7])
>
> In [6]: arr[ndx2]
>
> Out[6]: array([ 8, 12])
>
>
>
> ndx1 and ndx2 are both nice things (and are both often programmatically
> constructed by operations in NumPy).  But indexing using ndx1 gives us an
> array of the things in the listed *positions* in arr.  In this case, we
> happen to choose two each of the things an index 0 and index 1 in the
> result.
>
>
>
> Indexing by ndx2 gives us a filter of only those positions in arr
> corresponding to 'True's.  These are both nice things to be able to do, but
> if NumPy's True was a special kind of 1, it wouldn't work out
> unambiguously.  However, recent versions of NumPy *have* gotten a bit
> smarter about recognizing the special type of Python bools, so it's less of
> a trap than it used to be.  Still, contrast these (using actual Python
> lists for the indexes:
>
>
>
> In [10]: arr[[False, True, True, False]]
>
> Out[10]: array([ 8, 12])
>
> In [11]: arr[[False, True, 1, 0]]
>
> Out[11]: array([7, 8, 8, 7])
>
>
>
>
>
>
>
> On Mon, Feb 12, 2018 at 7:50 PM, Nick Coghlan  wrote:
>
> On 13 February 2018 at 02:14, David Mertz  wrote:
> > NumPy np.bool_ is specifically not a subclass of any np.int_.  If it
> we're,
> > there would be an ambiguity between indexing with a Boolean array and an
> > array of ints. Both are meaningful, but they mean different things (mask
> vs
> > collection of indices).
> >
> > Do we have other examples a Python ABC that exists to accommodate
> something
> > outside the standard library or builtins? Even if not, NumPy is
> special...
> > the actual syntax for '@' exists primarily for that library!
>
> collections.abc.Sequence and collections.abc.Mapping come to mind -
> the standard library doesn't tend to distinguish between different
> kinds of subscriptable objects, but it's a distinction some third
> party libraries and tools want to be able to make reliably.
>
> The other comparison that comes to mind would be the distinction
> between "__int__" ("can be coerced to an integer, but may lose
> information in the process") and "__index__" ("can be losslessly
> converted to and from a builtin integer").
>
> Right now, we only define boolean coercion via "__bool__" - there's no
> mechanism to say "this *is* a boolean value that can be losslessly
> converted to and from the builtin boolean constants". That isn't a
> distinction the standard library makes, but it sounds like it's one
> that NumPy cares about (and NumPy was also the main driver for
> introducing __index__).
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
>
>
>
>
>
> --
>
> Keeping medicines from the bloodstreams of the sick; food
> from the bellies of the hungry; books from the hands of the
> uneducated; technology from the underdeveloped; and putting
> advocates of freedom in prisons.  Intellectual property is
> to the 21st century what the slave trade was to the 16th.
>
>
> ___

Re: [Python-ideas] Boolean ABC similar to what's provided in the 'numbers' module

[Sylvain MARIE]

The main use case I had in mind was PEP484-based type hinting/checking actually:

def my_function(foo: Boolean):
pass

explicitly states that my_function accepts any Boolean value, whether it is a 
python bool or a np.bool that would come from a numpy array or pandas dataframe.
Note that type hinting is also the use case for which I make extensive use of 
the types from the ‘numbers’ package, for the same reasons.

Sylvain

De : Python-ideas 
[mailto:python-ideas-bounces+sylvain.marie=schneider-electric@python.org] 
De la part de David Mertz
Envoyé : mardi 13 février 2018 07:08
À : Nick Coghlan 
Cc : python-ideas 
Objet : Re: [Python-ideas] Boolean ABC similar to what's provided in the 
'numbers' module

I'm not sure I'm convinced by Sylvain that Boolean needs to be an ABC in the 
standard library; Guido expresses skepticism.  Of course it is possible to 
define it in some other library that actually needs to use `isinstance(x, 
Boolean)` as Sylvain demonstraits in his post.  I'm not sure I'm unconvinced 
either, I can see a certain value to saying a given value is "fully 
round-trippable to bool" (as is np.bool_).

But just for anyone who doesn't know NumPy, here's a quick illustration of what 
I alluded to:

In [1]: import numpy as np
In [2]: arr = np.array([7,8,12,33])
In [3]: ndx1 = np.array([0,1,1,0], dtype=int)
In [4]: ndx2 = np.array([0,1,1,0], dtype=bool)
In [5]: arr[ndx1]
Out[5]: array([7, 8, 8, 7])
In [6]: arr[ndx2]
Out[6]: array([ 8, 12])

ndx1 and ndx2 are both nice things (and are both often programmatically 
constructed by operations in NumPy).  But indexing using ndx1 gives us an array 
of the things in the listed positions in arr.  In this case, we happen to 
choose two each of the things an index 0 and index 1 in the result.

Indexing by ndx2 gives us a filter of only those positions in arr corresponding 
to 'True's.  These are both nice things to be able to do, but if NumPy's True 
was a special kind of 1, it wouldn't work out unambiguously.  However, recent 
versions of NumPy have gotten a bit smarter about recognizing the special type 
of Python bools, so it's less of a trap than it used to be.  Still, contrast 
these (using actual Python lists for the indexes:

In [10]: arr[[False, True, True, False]]
Out[10]: array([ 8, 12])
In [11]: arr[[False, True, 1, 0]]
Out[11]: array([7, 8, 8, 7])



On Mon, Feb 12, 2018 at 7:50 PM, Nick Coghlan 
mailto:ncogh...@gmail.com>> wrote:
On 13 February 2018 at 02:14, David Mertz 
mailto:me...@gnosis.cx>> wrote:
> NumPy np.bool_ is specifically not a subclass of any np.int_.  If it we're,
> there would be an ambiguity between indexing with a Boolean array and an
> array of ints. Both are meaningful, but they mean different things (mask vs
> collection of indices).
>
> Do we have other examples a Python ABC that exists to accommodate something
> outside the standard library or builtins? Even if not, NumPy is special...
> the actual syntax for '@' exists primarily for that library!

collections.abc.Sequence and collections.abc.Mapping come to mind -
the standard library doesn't tend to distinguish between different
kinds of subscriptable objects, but it's a distinction some third
party libraries and tools want to be able to make reliably.

The other comparison that comes to mind would be the distinction
between "__int__" ("can be coerced to an integer, but may lose
information in the process") and "__index__" ("can be losslessly
converted to and from a builtin integer").

Right now, we only define boolean coercion via "__bool__" - there's no
mechanism to say "this *is* a boolean value that can be losslessly
converted to and from the builtin boolean constants". That isn't a
distinction the standard library makes, but it sounds like it's one
that NumPy cares about (and NumPy was also the main driver for
introducing __index__).

Cheers,
Nick.

--
Nick Coghlan   |   ncogh...@gmail.com   |   
Brisbane, Australia



--
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.

__
This email has been scanned by the Symantec Email Security.cloud service.
__
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Boolean ABC similar to what's provided in the 'numbers' module

[Guido van Rossum]

Can you show some sample code that you have written that shows where this
would be useful?

Note that using the numbers package actually makes static type checking
through e.g. mypy difficult. So I presume you are talking about dynamic
checking?

--Guido


On Feb 14, 2018 12:42 AM, "Sylvain MARIE" <
sylvain.ma...@schneider-electric.com> wrote:

My point is just that today, I use the ‘numbers’ package classes (Integral,
Real, …) for PEP484 type-hinting, and I find it quite useful in term of
input type validation (in combination with PEP484-compliant type checkers,
whether static or dynamic). Adding a Boolean ABC with a similar behavior
would certainly add consistency to that ‘numbers’ package – only for users
who already find it useful, of course.



Note that my use case is not about converting an object to a Boolean, I’m
just speaking about type validation of a ‘true’ boolean object, for example
to be received as a function argument for a flag option. This is for
example for users who want to define strongly-typed APIs for interaction
with the ‘outside world’, and keep using duck-typing for internals.



Sylvain



*De :* Python-ideas [mailto:python-ideas-bounces+sylvain.marie=schneider-
electric@python.org] *De la part de* Chris Barker
*Envoyé :* mardi 13 février 2018 21:12
*À :* David Mertz 
*Cc :* python-ideas 
*Objet :* Re: [Python-ideas] Boolean ABC similar to what's provided in the
'numbers' module







On Mon, Feb 12, 2018 at 10:07 PM, David Mertz  wrote:

I'm not sure I'm convinced by Sylvain that Boolean needs to be an ABC in
the standard library; Guido expresses skepticism.  Of course it is possible
to define it in some other library that actually needs to use
`isinstance(x, Boolean)` as Sylvain demonstraits in his post.  I'm not sure
I'm unconvinced either, I can see a certain value to saying a given value
is "fully round-trippable to bool" (as is np.bool_).



But is an ABC the way to do it? Personally, I'm skeptical that ABCs are a
solution to, well, anything (as apposed to duck typing and EAFTP). Take
Nick's example:



"""

The other comparison that comes to mind would be the distinction
between "__int__" ("can be coerced to an integer, but may lose
information in the process") and "__index__" ("can be losslessly
converted to and from a builtin integer").

"""



I suppose we could have had an Index ABC -- but that seems painful to me.



so maybe we could use a __true_bool__ special method?



(and an operator.true_bool() function ???)



(this all makes me wish that python bools were more pure -- but way to late
for that!)



I guess it comes down to whether you want to:



 - Ask the question: "is this object a boolean?"



or



 - Make this object a boolean



__index__ (and operator.index())  is essentially the later -- you want to
make an index out of whatever object you have, if you can do so.



-CHB







-- 


Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov


__
This email has been scanned by the Symantec Email Security.cloud service.
__

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Boolean ABC similar to what's provided in the 'numbers' module

[Sylvain MARIE]

My point is just that today, I use the ‘numbers’ package classes (Integral, 
Real, …) for PEP484 type-hinting, and I find it quite useful in term of input 
type validation (in combination with PEP484-compliant type checkers, whether 
static or dynamic). Adding a Boolean ABC with a similar behavior would 
certainly add consistency to that ‘numbers’ package – only for users who 
already find it useful, of course.

Note that my use case is not about converting an object to a Boolean, I’m just 
speaking about type validation of a ‘true’ boolean object, for example to be 
received as a function argument for a flag option. This is for example for 
users who want to define strongly-typed APIs for interaction with the ‘outside 
world’, and keep using duck-typing for internals.

Sylvain

De : Python-ideas 
[mailto:python-ideas-bounces+sylvain.marie=schneider-electric@python.org] 
De la part de Chris Barker
Envoyé : mardi 13 février 2018 21:12
À : David Mertz 
Cc : python-ideas 
Objet : Re: [Python-ideas] Boolean ABC similar to what's provided in the 
'numbers' module



On Mon, Feb 12, 2018 at 10:07 PM, David Mertz 
mailto:me...@gnosis.cx>> wrote:
I'm not sure I'm convinced by Sylvain that Boolean needs to be an ABC in the 
standard library; Guido expresses skepticism.  Of course it is possible to 
define it in some other library that actually needs to use `isinstance(x, 
Boolean)` as Sylvain demonstraits in his post.  I'm not sure I'm unconvinced 
either, I can see a certain value to saying a given value is "fully 
round-trippable to bool" (as is np.bool_).

But is an ABC the way to do it? Personally, I'm skeptical that ABCs are a 
solution to, well, anything (as apposed to duck typing and EAFTP). Take Nick's 
example:

"""
The other comparison that comes to mind would be the distinction
between "__int__" ("can be coerced to an integer, but may lose
information in the process") and "__index__" ("can be losslessly
converted to and from a builtin integer").
"""

I suppose we could have had an Index ABC -- but that seems painful to me.

so maybe we could use a __true_bool__ special method?

(and an operator.true_bool() function ???)

(this all makes me wish that python bools were more pure -- but way to late for 
that!)

I guess it comes down to whether you want to:

 - Ask the question: "is this object a boolean?"

or

 - Make this object a boolean

__index__ (and operator.index())  is essentially the later -- you want to make 
an index out of whatever object you have, if you can do so.

-CHB



--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov

__
This email has been scanned by the Symantec Email Security.cloud service.
__
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/