On Tue, Nov 14, 2017 at 7:58 AM, Thomas Caswell wrote:
> I am in very supportive of this plan.
>
> For Matplotlib the intention is to do a mpl2.2LTS early 2018 and a mpl3.0
> (no major API breaks other than dropping py2 support) summer 2018 with the
> same meaning of LTS.
>
> I also had thought a
On Thu, Oct 26, 2017 at 12:40 PM, Nathaniel Smith wrote:
> On Wed, Oct 18, 2017 at 10:24 PM, Nathaniel Smith wrote:
>> I'll also be giving a lunch talk at BIDS tomorrow to let folks locally
>> know about what's going on, which I think will be recorded – I'll send
>> around a link after in case ot
> Just to check that I am not misunderstanding: the version of pip should
> not be more than a year old; "decades old" is just French hyperbola? Do I
> understand right?
Yes, sorry if you can't hear my french accent in writing, I can hear yours :-)
There is also a "softer" requirement on setuptoo
On Nov 13, 2017 12:03, "Gael Varoquaux"
wrote:
On Mon, Nov 13, 2017 at 10:26:31AM -0800, Matthias Bussonnier wrote:
> This behavior is "new" (Nov/Dec 2016). [snip]
> It _does_ require to have a version of pip which is not decades old
Just to check that I am not misunderstanding: the version of p
On Mon, Nov 13, 2017 at 10:26:31AM -0800, Matthias Bussonnier wrote:
> This behavior is "new" (Nov/Dec 2016). [snip]
> It _does_ require to have a version of pip which is not decades old
Just to check that I am not misunderstanding: the version of pip should
not be more than a year old; "decades o
I am in very supportive of this plan.
For Matplotlib the intention is to do a mpl2.2LTS early 2018 and a mpl3.0
(no major API breaks other than dropping py2 support) summer 2018 with the
same meaning of LTS.
I also had thought about bumping the minimum numpy version of Matplotlib to
the first py3
Hello All,
I need to make use of the limited numpy API access Pybind11 gives, in order
to add a feature to it. It seems to give access to functions from
numpy_api.py [1]. I need to use PyArray_GETITEM and PyArray_SETITEM in
order to get and set array elements [2], these functions / macros are n
On Mon, Nov 13, 2017 at 10:31 AM, Stefan van der Walt
wrote:
>
> Is this documented anywhere? I couldn't find it via Google, and suspect
> it may be widely useful in the next few months.
Everything you need to know is on the Python3Statement practicality page:
http://www.python3statement.org/pr
On Mon, Nov 13, 2017, at 10:26, Matthias Bussonnier wrote:
> Unless the sdist is tagged with require_python and users have
> recent-enough pip.
Is this documented anywhere? I couldn't find it via Google, and suspect
it may be widely useful in the next few months.
Stéfan
_
> If a wheel is not available for the client platform, pip will try to install
> the latest version of the source distribution (.tar.gz or .zip) which I think
> is the cause of the problem here.
Unless the sdist is tagged with require_python and users have
recent-enough pip. Which is what was re
If a wheel is not available for the client platform, pip will try to
install the latest version of the source distribution (.tar.gz or .zip)
which I think is the cause of the problem here.
--
Olivier
___
NumPy-Discussion mailing list
NumPy-Discussion@
> The trouble is PyPi doesn't allow multiple branches. So if you upload NumPy
> 2.0 wheels, then you cannot turn around and upload 1.18.X bug-fix patches.
> At least, this is my understanding of PyPi.
That's perfectly feasible. We've been maintaining a 6.x (Python 3
only) and 5.x (Python2+3)
On Mon, Nov 13, 2017 at 7:47 AM, Matthias Bussonnier <
bussonniermatth...@gmail.com> wrote:
> > For this to be efficient, it should be done soon enough to allow
> downstream projects to adapt their requirements.txt.
> > Release managers: how much more effort would it be to upload current
> numpy t
On Fri, Nov 10, 2017 at 2:03 PM, Robert McLeod wrote:
> Pip repo names and actual module names don't have to be the same. One
> potential work-around would be to make a 'numpylts' repo on PyPi which is
> the 1.17 version with support for Python 2.7 and bug-fix releases as
> required. This will
> For this to be efficient, it should be done soon enough to allow downstream
> projects to adapt their requirements.txt.
> Release managers: how much more effort would it be to upload current numpy to
> both numpy and numpylts?
I'm not quite sure I see the point. you would ask downstream to cha
On 10 November 2017 at 23:03, Robert McLeod wrote:
> E.g. in `requirements.txt`:
>
> numpy;python_version>"3.0"
> numpylts; python_version<"3.0"
>
> In both cases you still call `import numpy` in the code.
>
For this to be efficient, it should be done soon enough to allow downstream
projects
16 matches
Mail list logo
