On Jun 24, 2012, at 12:08 AM, Martin v. Löwis wrote:
>Please propose something. I think the hexversion *is* user-friendly,
>since it allows easy comparisons (Py_LIMITED_API+0 >= 0x0303).
>Users that run into missing symbols will, after inspection of the
>header file, easily know what to do.
+
On Sun, Jun 24, 2012 at 5:08 PM, Nick Coghlan wrote:
> On Sun, Jun 24, 2012 at 5:00 PM, "Martin v. Löwis" wrote:
>>> This strikes me as in opposition to the Python-level policy of duck
>>> typing. Would it be more appropriate to, instead of asking if it's
>>> Python 3.3.0, ask if it's a Python th
On Sun, Jun 24, 2012 at 5:00 PM, "Martin v. Löwis" wrote:
>> This strikes me as in opposition to the Python-level policy of duck
>> typing. Would it be more appropriate to, instead of asking if it's
>> Python 3.3.0, ask if it's a Python that supports PY_FEATURE_FOOBAR? Or
>> would that result in a
> This strikes me as in opposition to the Python-level policy of duck
> typing. Would it be more appropriate to, instead of asking if it's
> Python 3.3.0, ask if it's a Python that supports PY_FEATURE_FOOBAR? Or
> would that result in an unnecessary proliferation of flag macros?
It would, hence I'
On Sun, Jun 24, 2012 at 9:40 AM, Christian Heimes wrote:
> Am 24.06.2012 01:11, schrieb Larry Hastings:
>> On 06/23/2012 03:08 PM, "Martin v. Löwis" wrote:
>>> On 23.06.2012 23:41, Antoine Pitrou wrote:
Perhaps something more user-friendly than the hexversion?
>>> Please propose something. I
Am 24.06.2012 01:44, schrieb Chris Angelico:
> This strikes me as in opposition to the Python-level policy of duck
> typing. Would it be more appropriate to, instead of asking if it's
> Python 3.3.0, ask if it's a Python that supports PY_FEATURE_FOOBAR? Or
> would that result in an unnecessary prol
On 06/23/2012 04:44 PM, Chris Angelico wrote:
On Sun, Jun 24, 2012 at 9:40 AM, Christian Heimes wrote:
+1 for the general idea and for using Py_LIMITED_API. I still like my
idea of a simple macro based on Include/patchlevel.h, for example:
#define Py_API_VERSION(major, minor, micro) \
(((m
On Sun, Jun 24, 2012 at 9:40 AM, Christian Heimes wrote:
> +1 for the general idea and for using Py_LIMITED_API. I still like my
> idea of a simple macro based on Include/patchlevel.h, for example:
>
> #define Py_API_VERSION(major, minor, micro) \
> (((major) << 24) | ((minor) << 16) | ((micro)
Am 24.06.2012 01:11, schrieb Larry Hastings:
> On 06/23/2012 03:08 PM, "Martin v. Löwis" wrote:
>> On 23.06.2012 23:41, Antoine Pitrou wrote:
>>> Perhaps something more user-friendly than the hexversion?
>> Please propose something. I think the hexversion *is* user-friendly,
>
> +1 to the idea, an
On 06/23/2012 03:08 PM, "Martin v. Löwis" wrote:
On 23.06.2012 23:41, Antoine Pitrou wrote:
Perhaps something more user-friendly than the hexversion?
Please propose something. I think the hexversion *is* user-friendly,
+1 to the idea, and specifically to using hexversion here. (Though what
On 23.06.2012 23:41, Antoine Pitrou wrote:
> On Sat, 23 Jun 2012 23:31:07 +0200
> "Martin v. Löwis" wrote:
>> I've been thinking about extensions to the stable ABI. On the one hand,
>> introducing new API can cause extension modules not to run on older
>> Python versions. On the other hand, the ne
Am 23.06.2012 23:41, schrieb Antoine Pitrou:
> Perhaps something more user-friendly than the hexversion?
IMHO 0x0303 for 3.0.0 is user-friendly enough. A macro like
PY_VERSION(3, 0, 0) could be added, too.
Christian
___
Python-Dev mailing list
Pytho
On Sat, 23 Jun 2012 23:31:07 +0200
"Martin v. Löwis" wrote:
> I've been thinking about extensions to the stable ABI. On the one hand,
> introducing new API can cause extension modules not to run on older
> Python versions. On the other hand, the new API may well be stable in
> itself, i.e. remain
On Sat, Jun 23, 2012 at 2:31 PM, "Martin v. Löwis" wrote:
> I've been thinking about extensions to the stable ABI. On the one hand,
> introducing new API can cause extension modules not to run on older
> Python versions. On the other hand, the new API may well be stable in
> itself, i.e. remain av
On Sat, Jun 23, 2012 at 5:31 PM, "Martin v. Löwis" wrote:
> I've been thinking about extensions to the stable ABI. On the one hand,
> introducing new API can cause extension modules not to run on older
> Python versions. On the other hand, the new API may well be stable in
> itself, i.e. remain av
I've been thinking about extensions to the stable ABI. On the one hand,
introducing new API can cause extension modules not to run on older
Python versions. On the other hand, the new API may well be stable in
itself, i.e. remain available for all coming 3.x versions.
As a compromise, I propose th
16 matches
Mail list logo
