On 26 July 2018 at 02:13, Erik Bray wrote:
> I think a new approach that might be more practical for actually
> getting this platform re-supported, is to go ahead and add a CI build,
> and just skip all known failing test modules. This is what I've done
> in a new PR to add a Cygwin build on
On 30/07/2018 16:41, Nick Coghlan wrote:
On 29 July 2018 at 03:20, Tim Golden wrote:
I think that was my starting point: rather than develop increasingly
involved and still somewhat brittle mechanisms, why not do what you'd
naturally do with a new test and use tempfile? I was expecting someone
On 18 July 2018 at 17:49, Steve Holden wrote:
> On Tue, Jul 17, 2018 at 11:44 PM, Paul G wrote:
>>
>> In many languages numeric types can't hold arbitrarily large values, and I
>> for one hadn't really previously recognized that if you read in a numeric
>> value with an exponent that it would be
On 2018-07-30 15:35, INADA Naoki wrote:
As repeatedly said, PEP 580 is very complicated protocol
when just implementing callable object.
Can you be more concrete what you find complicated? Maybe I can improve
the PEP to explain it more. Also, I'm open to suggestions to make it
less
On 30 July 2018 at 22:12, Jeroen Demeyer wrote:
> I think it has been argued before that it's a feature that self is counted.
> So I consider the error message for list().append a bug. This is one of the
> many oddities I noticed while working on improving built-in functions.
>
> Would you agree
On 30 July 2018 at 21:23, Victor Stinner wrote:
> Or maybe test__capi.py so you can more easily discover
> test_unicode_cami while working on Unicode. You can use -m "test_*_capi" to
> run all C API tests.
Missing word there: -m test "test*_capi"
I think between this approach and expanding
On 29 July 2018 at 03:20, Tim Golden wrote:
> I think that was my starting point: rather than develop increasingly
> involved and still somewhat brittle mechanisms, why not do what you'd
> naturally do with a new test and use tempfile? I was expecting someone to
> come forward to highlight some
Hello,
I noticed an inconsistency in the error messages for the number of
arguments to a method call. For Python methods, the "self" argument is
counted. For built-in methods, the "self" argument is *not* counted:
>>> class mylist(list):
... def append(self, val): super().append(val)
Like previous SageMath bench, this is caused by Cython's
specialization; __Pyx_PyObject_CallOneArg.
It specializing calling PyFunction and PyCFunction, but it doesn't
specialized for calling CyFunction.
Cython can optimize both benchmark with binding, but without PEP 576 nor 580,
by adding
Or maybe test__capi.py so you can more easily discover
test_unicode_cami while working on Unicode. You can use -m "test_*_capi" to
run all C API tests.
Victor
Le lundi 30 juillet 2018, Victor Stinner a écrit :
> Buildbots have a timeout of 15 min per test. I suggest to use multiple
As repeatedly said, PEP 580 is very complicated protocol
when just implementing callable object.
It is optimized for implementing custom method object, although
almost only Cython want the custom method type.
I'm not sure adding such complicated protocol almost only for Cython.
If CyFunction can
> On 30 Jul 2018, at 10:20, Victor Stinner wrote:
>
> The API leaking all implementation details will remain available as an opt-in
> option for Cython, cffi and debug tools. But this API will only be usable on
> the "slow" Python runtime, the one which keeps maximum backward
>
Buildbots have a timeout of 15 min per test. I suggest to use multiple
test_capi_.py files rather than a directory which behaves as a single
test. Or regrtest should be modified to implement timeout differently.
Victor
Le dimanche 29 juillet 2018, Serhiy Storchaka a
écrit :
> Currently C API is
On 2018-07-30 13:11, INADA Naoki wrote:
Like previous SageMath bench, this is caused by Cython's
specialization; __Pyx_PyObject_CallOneArg.
It specializing calling PyFunction and PyCFunction, but it doesn't
specialized for calling CyFunction.
Yes, I saw that too. But this is exactly what
On 2018-07-30 20:22, Chris Barker wrote:
is it possible for the interpreter to know when this error is
generated that this is a bound method expecting a "self", rather than an
arbitrary function with n parameters?
That would be quite hard. The error message is generated by the
underlying
On Mon, Jul 30, 2018 at 11:39 AM, Jeroen Demeyer wrote:
> On 2018-07-30 20:22, Chris Barker wrote:
>
>> is it possible for the interpreter to know when this error is
>> generated that this is a bound method expecting a "self", rather than an
>> arbitrary function with n parameters?
>>
>
> That
On Mon, Jul 30, 2018 at 8:46 AM, Tim Golden wrote:
> On 30/07/2018 16:41, Nick Coghlan wrote:
>>
>> On 29 July 2018 at 03:20, Tim Golden wrote:
>>>
>>> I think that was my starting point: rather than develop increasingly
>>> involved and still somewhat brittle mechanisms, why not do what you'd
On Mon, Jul 30, 2018 at 5:12 AM, Jeroen Demeyer wrote:
> I think it has been argued before that it's a feature that self is
> counted.
I suppose it is, as it's technically correct, but it's also a HUGE source
of confusion, particularly for newbies. IF this is being touched anyway, is
it
hi all,
I've been trying to figure out how to access the archives programmatically.
I'm sure this is easy once you know, but googling various things hasn't
worked. What I want to do is graph the number of messages about PEP 572 by
time. (or has someone already done that?)
I installed GNU
Jeroen Demeyer schrieb am 30.07.2018 um 16:40:
> On 2018-07-30 15:35, INADA Naoki wrote:
>> As repeatedly said, PEP 580 is very complicated protocol
>> when just implementing callable object.
>
> Can you be more concrete what you find complicated? Maybe I can improve the
> PEP to explain it more.
Actually, I mean -m test --match 'test_*_capi' where --match can also be
written -m.
It may catch false positive since the filter is also applied to test case
names and test method names.
Maybe 'test_*_capi.*' is better, I didn't try.
You may using use "ls Lib/test/test_*_capi.py > tests;
>> Last year, I gave a talk at the Language Summit (during Pycon) to
>> explain that CPython should become 2x faster to remain competitive.
>> IMHO all attempts to optimize Python (CPython forks) have failed
>> because they have been blocked by the C API which implies strict
>> constraints.
>
>
Hi Bob,
I wrote a basic script to compute the number of emails per PEP. It requires
to download gzipped mbox files from the web page of archives per month,
then ungzip them:
https://github.com/vstinner/misc/blob/master/python/parse_mailman_mbox_peps.py
Results:
On Sat, Jul 28, 2018 at 7:51 AM Ronald Oussoren via Python-Dev <
python-dev@python.org> wrote:
> Hi,
>
> I’m looking at PyOS_CheckStack because this feature might be useful on
> macOS (and when I created bpo-33955 for this someone ran with it and
> created a patch).
>
> Does anyone remember why
> On Jul 29, 2018, at 4:53 AM, Serhiy Storchaka wrote:
>
> The benefit is that it will be easier to run all C API tests at once, and
> only them, and it will be clearer what C API is covered by tests. The
> disadvantage is that you will need to run several files for testing marshal
> for
Hi Victor,
On Sun, 29 Jul 2018 21:47:51 +0200
Victor Stinner wrote:
>
> I just sent an email to the capi-sig mailing list. Since this mailing
> list was idle for months, I copy my email here to get a wider
> audience. But if possible, I would prefer that you join me on capi-sig
> to reply ;-)
On 7/30/2018 4:26 AM, Barath Aron wrote:
On 07/30/2018 10:23 AM, Victor Stinner wrote:
Python 3.8 will support os.posix_spawn(). I would like to see it used
whenever possible instead of fork+exec, since it's faster and it can
be safer on some platforms. Pablo Salgado is your guy for that.
Python 3.8 will support os.posix_spawn(). I would like to see it used
whenever possible instead of fork+exec, since it's faster and it can be
safer on some platforms. Pablo Salgado is your guy for that.
Victor
___
Python-Dev mailing list
30.07.18 09:46, Raymond Hettinger пише:
I prefer the current organization that keeps the various tests together with
the category being tested. I almost never need to run the C API tests all at
once, but I do need to see all the tests for an object in one place. When
maintaining something
The API leaking all implementation details will remain available as an
opt-in option for Cython, cffi and debug tools. But this API will only be
usable on the "slow" Python runtime, the one which keeps maximum backward
compatibility. To get new optimizations, you have to use Py_INCREF() and
avoid
> On Jul 30, 2018, at 12:06 AM, Serhiy Storchaka wrote:
>
> 30.07.18 09:46, Raymond Hettinger пише:
>> I prefer the current organization that keeps the various tests together with
>> the category being tested. I almost never need to run the C API tests all
>> at once, but I do need to see
On 07/30/2018 10:23 AM, Victor Stinner wrote:
Python 3.8 will support os.posix_spawn(). I would like to see it used
whenever possible instead of fork+exec, since it's faster and it can
be safer on some platforms. Pablo Salgado is your guy for that.
Victor
Awesome! Will this backported to
Supporting a new platform requires a lot work. It would be more reasonable
for you to first try to get a good support of the master branch before
start thinking how to support Python versions.
Python 2.7 in 2018? Really? Tick tock:
https://pythonclock.org/
http://python3statement.org/
Usually,
33 matches
Mail list logo
