Our collaboration with the students and faculty from the Master’s program
in Survey Methodology at the University of Michigan and the University of
Maryland is underway. We are looking for a volunteer to translate the
survey questionnaire into Russian. If you are available, or you know
someone who would be interested to help, please leave a comment here:
Every good wish,
*Inessa Pawson *
it has come up in the last community call that many of our committee
membership lists have not been updated in a while.
This is not a big issue as such. But, while these committees are not
very active on a day-to-day basis, they are an important part of the
community and it is better to update them regularly and thus also
ensure they remain representative of the community.
We would like to start by updating the members of the Code of Conduct
(CoC) committee. The CoC committee is in charge of responding and
following up to any reports of CoC breaches, as stated in:
If you are interested in or happy to serve on our CoC committee please
let me or e.g. Ralf Gommers know, join the next community meeting
(April 29th, 11:00PDT/18:00UTC), or reply on the list.
I hope we will be able to discuss and reach a consensus between those
interested and involved quickly (possibly already on the next community
call). In either case, before any changes they will be run by the
mailing list to ensure community consensus.
Over in numpy-stubs we've been working on typing "array like":
It would be nice if the type were public so that downstream projects
could use it (e.g. it would be very helpful in SciPy). Originally the
plan was to only make it publicly available at typing time and not
runtime, which would mean that no changes to NumPy are necessary; see
for more information on how that works.
But, Stephan pointed out that it might be confusing to users for
objects to only exist at typing time, so we came around to the
question of whether people are open to the idea of including the type
aliases in NumPy itself. Ralf's concrete proposal was to make a module
numpy.types (or maybe numpy.typing) to hold the aliases so that they
don't pollute the top-level namespace. The module would initially
contain the types
- (maybe) ShapeLike
Note that we would not need to make changes to NumPy right away;
instead it would probably be done when numpy-stubs is merged into
What do people think?
I look forward to participating in this year's Season of Docs. Though it's
early, I'm eager to start a conversation; I've posted the webpage
https://bennathanson.com/numpy2020 to share my thoughts on contributing.
in https://github.com/numpy/numpy/pull/15925 I propose to deprecate
promotion of strings and numbers. I have to double check whether this
has a large effect on pandas, but it currently seems to me that it will
This means that `np.promote_types("S", "int8")`, etc. will lead to an
error instead of returning `"S4"`. For the user, I believe the two
main visible changes are that:
will stop creating a string array and return either an `object` array
or give an error (object array would be the default currently).
Another larger visible change will be code such as:
will result in an error instead of returning a string array. (Users
will have to cast manually here.)
The alternative is to return an object array also for the concatenate
example. I somewhat dislike that because `object` is not homogeneously
typed and we thus lose type information. This also affects functions
that wish to cast inputs to a common type (ufuncs also do this
A further example of this and discussion is at the end of the mail .
So the first question is whether we can form an agreement that an error
is the better choice for `concatenate` and `np.promote_types()`.
I.e. there is no one dtype that can faithfully represent both strings
and integers. (This is currently the case e.g. for datetime64 and
The second question is what to do for:
which currently always returns strings. Arguably, it must also either
return an `object` array, or raise an error (requiring the user to pick
string or object using `dtype=object`).
The default would be to create a FutureWarning that an `object` array
will be returned for `np.asarray(["string", 0])` in the future.
But if we know already that we prefer an error, it would be better to
give a DeprecationWarning right away. (It just does not seem nice to
change the same thing twice even if the workaround is identical.)
A second more in-depth point is that code such as:
common_dtype = np.result_type(arr1, arr2) # or promote_types
arr1 = arr1.astype(common_dtype, copy=False)
arr2 = arr2.astype(common_dtype, copy=False)
will currently use `string` in this case while it would error in the
future. This already fails with other type combinations such as
`datetime64` and `float64` at the moment.
The main alternative to this proposal is to return `object` for the
common dtype, since an object array is not homogeneously typed, it
arguably can represent both inputs. I do not quite like this choice
personally because in the above example, it may be that the next line
is something like:
return arr1 * arr2
in which case, the preferred return may be `str` and not `object`.
We currently never promote to `object` unless one of the arrays is
already an `object` array, and that seems like the right choice to me.
There will be a NumPy Community meeting Wednesday April 29th at 1pm
Pacific Time (20:00 UTC). Everyone is invited and encouraged to join in
and edit the work-in-progress meeting topics and notes: