Thank you guys! Will try it that way.
Best,
Alex
On Tue, Feb 19, 2019 at 10:57 PM Steve Dower wrote:
>
> And for what it's worth, most of the really active contributors from
> distutils-sig seem to prefer the "Packaging" category at
> https://discuss.python.org/
>
> If you'd prefer to use Discou
And for what it's worth, most of the really active contributors from
distutils-sig seem to prefer the "Packaging" category at
https://discuss.python.org/
If you'd prefer to use Discourse, I'd suggest posting there first and
also email distutils-sig with a link to the discussion. Otherwise, go
Unfortunately you're still posted to the wrong list, Alexander. You want to
mail distutils-...@python.org where packaging discussions occur.
On Tue, Feb 19, 2019 at 8:19 AM Alexander Revin wrote:
> Hi all,
>
> I have an idea regarding Python binary wheels on non-glibc platforms,
> and it seems t
Steve Dower schrieb am 19.02.19 um 21:40:
> On 19Feb2019 1212, Stefan Behnel wrote:
>> Then it's up to the users to decide
>> how much work they want to invest into keeping up with C-API changes vs.
>> potentially sub-optimal but stable C-API usage.
> [...]
> And it's not up to the users - it's up
On 19Feb2019 1141, Barry Warsaw wrote:
Steve Dower wrote on 2/16/19 14:34:>
This is mostly about being able to assign blame when things break, so
I'm totally okay with extension modules that want to play with internals
declaring Py_BUILD_CORE to get access to them (though I suspect that
won't wo
On 19Feb2019 1212, Stefan Behnel wrote:
So, yeah, I'm happy with the status quo, and a bit worried about all the
moving around of declarations and that scent of a sword of Damocles hanging
over their potential confinement. IMHO, things should just be public and
potentially marked as "unstable" to
Nick Coghlan schrieb am 19.02.19 um 15:00:
> On Tue, 19 Feb 2019 at 20:41, Antoine Pitrou wrote:
>> On Mon, 18 Feb 2019 19:04:31 -0800 Steve Dower wrote:
>>> If you always rebuild your extension for every micro version (3.x.y) of
>>> CPython, then sure, go ahead and use this.
>>
>> Usually we would
[Any reason for dropping python-dev?]
Sorry. just clicked the wrong button.
And the answer is a resounding "yes, it returns the target platform"? It seems
you're saying this, but the wording of your email sounds just enough of a question that
I'm not sure whether you are definitively answeri
Steve Dower wrote on 2/16/19 14:34:>
This is mostly about being able to assign blame when things break, so
I'm totally okay with extension modules that want to play with internals
declaring Py_BUILD_CORE to get access to them (though I suspect that
won't work out of the box - maybe we should have
https://gitlab.com/xdegaye/abifa
The table of content of the first url in my initial post gives also a
link to that repository.under the name 'Repository'.
Xavier
On Tue, Feb 19, 2019 at 4:54 PM Stephane Wirtel wrote:
>
> Hi Xavier,
>
> I get this exception
>
> Timeout (360 seconds) reached; fa
On 19Feb2019 0555, Nick Coghlan wrote:
I really don't want us to ever get into a situation where we're
actively encouraging third party projects to define Py_BUILD_CORE.
If we decide we do want to go down a path like that, I'd instead
prefer to see us define something more like "Py_FRAGILE_API"
On 19Feb2019 0229, Jeroen Demeyer wrote:
On 2019-02-19 04:04, Steve Dower wrote:
On 18Feb.2019 1324, Jeroen Demeyer wrote:
For a very concrete example, was it really necessary to put
_PyTuple_ITEMS in (4)? That's used in _functoolsmodule.c. Especially
given that the very similar PySequence_Fast
Hi all,
I have an idea regarding Python binary wheels on non-glibc platforms,
and it seems that initially I've posted it to the wrong list ([1])
Long story short, the proposal is to use platform tuples (like
compiler ones) for wheel names, which will allow much broader platform
support, for examp
Hi Xavier,
I get this exception
Timeout (360 seconds) reached; failed to start emulator
---> Device ready.
---> Install Python on the emulator.
/home/pydev/build/python-native/python -B
/home/pydev/abifa/Android/tools/install.py
error: device 'emulator-5556' not found
unzip -q /home/pydev/dist/
On Tue, 19 Feb 2019 at 20:41, Antoine Pitrou wrote:
> On Mon, 18 Feb 2019 19:04:31 -0800
> Steve Dower wrote:
> > If you always rebuild your extension for every micro version (3.x.y) of
> > CPython, then sure, go ahead and use this.
>
> Usually we would guarantee that API details don't change in
Another point in favor of the change I just noticed is that int()
accept objects defining __index__ as its `base` argument:
Python 3.7.2 (default, Jan 13 2019, 12:50:01)
[Clang 10.0.0 (clang-1000.11.45.5)] on darwin
Type "help", "copyright", "credits" or "license" for more information
On Tue, 19 Feb 2019 at 05:33, Eric Snow wrote:
>
> On Sat, Feb 16, 2019 at 3:47 PM Antoine Pitrou wrote:
> > On Sat, 16 Feb 2019 14:34:46 -0800
> > Steve Dower wrote:
> > > Which seems to suggest that the answer to "which members are important
> > > to expose?" is "probably none".
> >
> > That s
On Tue, 19 Feb 2019 at 03:31, Rémi Lapeyre wrote:
> Nick Coghlan proposes to make __int__ defaults to __index__ when only the
> second
> is defined and asked to open a discussion on python-dev before making any
> change
> "as the closest equivalent we have to this right now is the "negative"
>
On 2/16/19, Richard Levasseur wrote:
>
> First: The tempfile module is a poor fit for testing (don't get me wrong,
> it works, but its not *nice for use in tests*)*.* This is because:
> 1. Using it as a context manager is distracting. The indentation signifies
> a conceptual scope the reader needs
Nice, we could start to fix the Android issues with this docker image,
maybe modified with the local repository but really useful.
Thank you so much for your job.
--
Stéphane Wirtel - https://wirtel.be - @matrixise
___
Python-Dev mailing list
Python-De
This is cool! Sadly, I don't have the bandwidth right now to play with
it. I may have a look later.
Victor
Le ven. 15 févr. 2019 à 18:27, Xavier de Gaye a écrit :
>
> The following command runs the buildbottest on an Android emulator with
> docker (it will use a little bit more than 11 GB):
>
>
Le mar. 19 févr. 2019 à 11:57, INADA Naoki a écrit :
> On the other hand, it makes sense to move _PyTuple_ITEMS to (3) or even (2).
> PyTuple_ITEMS(t) seems better than &PyTuple_GET_ITEM(t, 0).
Please don't use &PyTuple_GET_ITEM() or _PyTuple_ITEMS(). It prevents
to use a more efficient storage f
Le lun. 18 févr. 2019 à 22:34, Jeroen Demeyer a écrit :
> First of all, if everybody can actually #define Py_BUILD_CORE and get
> access to the complete API, I don't mind so much. But then it's
> important that this actually keeps working (i.e. that those headers will
> always be installed).
>
> S
On Tue, Feb 19, 2019 at 7:32 PM Jeroen Demeyer wrote:
>
> On 2019-02-19 04:04, Steve Dower wrote:
> > On 18Feb.2019 1324, Jeroen Demeyer wrote:
> >> For a very concrete example, was it really necessary to put
> >> _PyTuple_ITEMS in (4)? That's used in _functoolsmodule.c. Especially
> >> given that
On Mon, 18 Feb 2019 19:04:31 -0800
Steve Dower wrote:
>
> > I'm afraid of hiding actually useful private macros under Py_BUILD_CORE.
> > For example, Modules/_functoolsmodule.c and Modules/_json.c use API
> > functions from (4). But if an API function is useful for implementing
> > functools or j
On 2019-02-19 04:04, Steve Dower wrote:
On 18Feb.2019 1324, Jeroen Demeyer wrote:
For a very concrete example, was it really necessary to put
_PyTuple_ITEMS in (4)? That's used in _functoolsmodule.c. Especially
given that the very similar PySequence_Fast_ITEMS is in (2), that seems
like a strang
On 2019-02-19 04:04, Steve Dower wrote:
Otherwise, the
internal memory layout becomes part of the public ABI
Of course, the ABI (not API) depends on the internal memory layout. Why
is this considered a problem? If you want a fixed ABI, use API level (1)
from my last post. If you want a fixed
27 matches
Mail list logo
