Re: [Python-Dev] Language Summit notes
Hi,
On 11 April 2014 19:55, Maciej Fijalkowski wrote:
>> Thanks, that clarification helps a lot. Does this mean that "API-mode"
>> CFFI is competing with things like swig (which is not used much these
>> days, as far as I know) and Cython (which is used a lot in the numeric
>> community)? ("ABI-mode" CFFI is obviously directly competing with
>> ctypes).
>
> Yes.
Funny how a high-level shift --- not really changing anything under
the hood --- changes how we look at a project :-)
A bientôt,
Armin.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Final, Take 3
On Mar 29, 2014, at 2:53 PM, Gregory P. Smith wrote: > > On Thu, Mar 27, 2014 at 3:05 PM, Antoine Pitrou wrote: > On Thu, 27 Mar 2014 18:47:59 + > Brett Cannon wrote: > > On Thu Mar 27 2014 at 2:42:40 PM, Guido van Rossum wrote: > > > > > Much better, but I'm still not happy with including %s at all. Otherwise > > > it's accept-worthy. (How's that for pressure. :-) > > > > > > > But if we only add %b and leave out %s then how is this going to lead to > > Python 2/3 compatible code since %b is not in Python 2? Or am I > > misunderstanding you? > > I think we have reached a point where adding porting-related facilities > in 3.5 may actually slow down the pace of porting, rather than > accelerate it (because people will then wait for 3.5 to start porting > stuff). > > I understand that sentiment but that is an unjustified fear. It is not a good > reason not to do it. Projects are already trying to port stuff today and > running into roadblocks when it comes to ascii-compatible bytes formatting > for real world data formats in code needing to be 2.x compatible. I'm pulling > out my practicality beats purity card here. > > Mercurial is one of the large Python 2.4-2.7 code bases that needs this > feature in order to support Python 3 in a sane manner. (+Augie Fackler to > look at the latest http://legacy.python.org/dev/peps/pep-0461/ to confirm > usefulness) That looks sufficient to me - the biggest thing is being able to do "abort: %s is broken" % some_filename_that_is_bytes and have that work sanely, as well as the numerics. This looks like exactly what we need, but I'd love to test it soon (I'm happy to build a 3.5 from tip for testing) so that if it's not Right[0] changes can be made before it's permanent. Feel encouraged to CC me on patches or something for testing (or mail me directly when it lands). Thanks! AF > > -gps signature.asc Description: Message signed with OpenPGP using GPGMail ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Fwd: Jython Report
Below is the Jython "status update" report on Jython I received from Jim Baker and summarised in the Language Summit. It comes with one addendum from Frank: Jim's list is fantastic - the one bit I'd like to add to the list: Jython now supports a buffer protocol that parallels CPython's C API buffer protocol. This provided the basis for support of buffer() and memoryview(). The work was done with Jython3 in mind and will be a huge boost to that eventual effort. Begin forwarded message: > From: Jim Baker > Subject: Re: Jython Report > Date: 7 April 2014 06:42:51 BST > To: Michael Foord > Cc: Frank Wierzbicki > > Recent changes to trunk (last 6 months) > > * Recently tagged a soft beta 2! > * Java 7 JVM is now the minimum version, which gives a larger base of > functionality to work with (such as using Java 7's AutoCloseable to imply > corresponding context manager support in using Python code) > * Enable mixing Python and Java types in the bases of a class when using a > metaclass > * Added support for buffer, memoryview, although not complete yet with > respect to Java integration > * Console and encoding support, such as unicodedata/idna updates > * Many, many small fixes > > About to be in trunk, to support beta 3 > > * socket-reboot reimplements socket/select/ssl on top of Netty 4, a popular > event loop networking framework for the JVM (used by a large number of > performant projects in Java space and originally part of JBoss). There was no > ssl support before, but now socket and especially select semantics are much > closer to CPython as well (basically close to the Windows socket model). > * socket-reboot in turn enables requests and thereby pip. A branch of pip > currently works, actually modifying an upstream vendor lib (html5lib) so that > it doesn't use isolated UTF-16 surrogates in literals, since this is not > actually legal unicode, nor does it work in Jython's UTF-16 based > representation. Ironically this usage is to detect such illegal use in input > streams. > * Relative star imports, which seems to impact a number of interesting > projects. > * Performance tuning of sre. Jython has a port of CPython's sre, however our > use of UTF-16 requires expansion into an array of codepoints. Currently this > is done on demand, which can potentially add another O(n) factor in > evaluating regexes. A pull request we will apply memoizes. In the future, we > will rewrite the logic in sre so that it does next/prev, much like JRuby > currently does for similar encoding issues. > > Related work > > * Other PyPA tooling including virtualenv and wheel needs more diagnosis to > see why they currently fail on Jython, but our hope is that this is minor. > * New project jythontools by a number of Jython developers (including Frank > and Jim). This includes a number of projects that will help evolve Jython, > but outside the usual release schedule and the usual problem of being in core > (such as eventual deprecation): > - Clamp - precise integration with Java, enabling such capabilities as > Java directly importing Python modules without explicitly initializing the > Jython runtime or using object factories. Future work will enable Java > annotation integration, as decorators. Integrates with setuptools; future > integration as well with Maven via Aether. > - Jiffy - provide a CFFI backend for Jython. Right now it is pure > vaporware, but cursory examination of cffi.backend_ctypes suggests that it > should be straightforward and of modest effort to provide a similar backend > by using JFFI, which Jython and JRuby both use to access native runtime > services (such as Posix API) as part of the Java native runtime project. > * The Patois project has been started to collect examples for > cross-implementation support, as seen in surrogate support, but it will be a > good question to get that really going, vs just talking about it. > * JyNI - simply adding this jar to the classpath enables C extension API > support. Note that this project has been licensed by its developer (not a > Jython committer) under an LGPL license. > > Release schedule > > * Complete beta 2 > * Beta 3 is forthcoming, likely in 2 weeks > * For beta 4, need to perform a comprehensive bug triage - what will be in, > not in for 2.7.0 > * EuroPython sprint to finalize a release candidate for 2.7.0? > > Future > > * Mostly around performance, Java integration, and of course the usual bug > fixes > * Python bytecode compiler remains important, including for support targeting > Android and removing restriction on getting too large a method for the JVM > * More hooks for Java integration, including managing generated bytecode > * Integrating Zippy could provide for PyPy-like performance, but requires > Graal JVM > * Supporting invokedynamic is a more realistic solution, but without the use > of annotations (eg turn off Python frames) is going to be limited (maybe 2x?) > based o
Re: [Python-Dev] Language Summit notes
Guido van Rossum, 10.04.2014 03:08:
> - Jukka Lehtosalo gave a talk and answered questions about mypy, his design
> and implementation of pragmatic type annotations (no new syntax required,
> uses Python 3 function annotations).
FWIW, signature type annotations aren't enough for a static compiler like
Cython, which also benefits from local and global variable declarations,
static functions, etc. However, we initially discussed this feature in the
project some five years ago or so and never actually implemented it, so I
finally decided to add support for it to Cython. There already was a way to
provide static Cython/C type declarations in pure Python code, also for
function arguments, but it's nice to have a way that is also naturally
runtime inspectable in the signature.
It essentially looks like this now:
def func(plain_python_type: dict,
named_python_type: 'list',
explicit_python_type: {'type': dict},
explicit_named_python_type: {'type': 'tuple'},
explicit_c_type: {'ctype': 'int'}):
...
Pretty straight forward, I think.
Stefan
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Final, Take 3
On 4/12/2014 11:08 AM, Augie Fackler wrote: On Mar 29, 2014, at 2:53 PM, Gregory P. Smith mailto:[email protected]>> wrote: On Thu, Mar 27, 2014 at 3:05 PM, Antoine Pitrou mailto:[email protected]>> wrote: On Thu, 27 Mar 2014 18:47:59 + Brett Cannon mailto:[email protected]>> wrote: > On Thu Mar 27 2014 at 2:42:40 PM, Guido van Rossum mailto:[email protected]>> wrote: > > > Much better, but I'm still not happy with including %s at all. Otherwise > > it's accept-worthy. (How's that for pressure. :-) > > > > But if we only add %b and leave out %s then how is this going to lead to > Python 2/3 compatible code since %b is not in Python 2? Or am I > misunderstanding you? I think we have reached a point where adding porting-related facilities in 3.5 may actually slow down the pace of porting, rather than accelerate it (because people will then wait for 3.5 to start porting stuff). I understand that sentiment but that is an unjustified fear. It is not a good reason not to do it. Projects are already trying to port stuff today and running into roadblocks when it comes to ascii-compatible bytes formatting for real world data formats in code needing to be 2.x compatible. I'm pulling out my practicality beats purity card here. Mercurial is one of the large Python 2.4-2.7 code bases that needs this feature in order to support Python 3 in a sane manner. (+Augie Fackler to look at the latest http://legacy.python.org/dev/peps/pep-0461/ to confirm usefulness) That looks sufficient to me - the biggest thing is being able to do "abort: %s is broken" % some_filename_that_is_bytes and have that work sanely, as well as the numerics. This looks like exactly what we need, but I'd love to test it soon (I'm happy to build a 3.5 from tip for testing) so that if it's not Right[0] changes can be made before it's permanent. Feel encouraged to CC me on patches or something for testing (or mail me directly when it lands). Add yourself as nosy to http://bugs.python.org/issue20284 "patch to implement PEP 461 (%-interpolation for bytes)" Indeed, you could help test it the latest version, and others as posted. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Appeal for reviews
Hello, I've accumulated a number of patches in the issue tracker that are waiting for someone to review/commit/reject them. I'm eager to make corrections as necessary, I just need someone to look the work that I've done so far: * http://bugs.python.org/issue20951 (SSLSocket.send() returns 0 for non-blocking socket) * http://bugs.python.org/issue1738 (filecmp.dircmp does exact match only) * http://bugs.python.org/issue7776 (http.client.HTTPConnection tunneling is broken) * http://bugs.python.org/issue20177 (Derby #8: Convert 28 sites to Argument Clinic across 2 files) * http://bugs.python.org/issue19414 (iter(ordered_dict) yields keys not in dict in some circumstances) * http://bugs.python.org/issue20578 (BufferedIOBase.readinto1 is missing) * http://bugs.python.org/issue21057 (TextIOWrapper does not support reading bytearrays or memoryviews) I realize that core developer time is scarce, so I have started to only work on patches after I've confirmed that someone is available and interested to review them. However, it would be great if some people could find time to look at the issues above as well. Having your contributions just languish in the bugtracker is really dispiriting... I *want* to contribute, and I can't believe that Python is the one open-source project that is not in need of more manpower. But for some reason it seems really hard to actually find something to do.. Best, Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Appeal for reviews
On 4/12/2014 2:58 PM, Nikolaus Rath wrote: I've accumulated a number of patches in the issue tracker that are waiting for someone to review/commit/reject them. I'm eager to make corrections as necessary, I just need someone to look the work that I've done so far: If I did not have several Idle patches to review from other new people like you, I would. Many core developers are at the PyCon conference, so it may be a few days before they can respond. * http://bugs.python.org/issue20951 (SSLSocket.send() returns 0 for non-blocking socket) * http://bugs.python.org/issue1738 (filecmp.dircmp does exact match only) * http://bugs.python.org/issue7776 (http.client.HTTPConnection tunneling is broken) * http://bugs.python.org/issue20177 (Derby #8: Convert 28 sites to Argument Clinic across 2 files) * http://bugs.python.org/issue19414 (iter(ordered_dict) yields keys not in dict in some circumstances) * http://bugs.python.org/issue20578 (BufferedIOBase.readinto1 is missing) * http://bugs.python.org/issue21057 (TextIOWrapper does not support reading bytearrays or memoryviews) Do you consider any of these 'ready-to-commit'? * before-fail, after-pass test? * required doc changes? * tested patch for all versions that should be patched? * any new Misc/ACKS entry needed (for new person other than you)? * checked for stray end-of-line whitespace? I intentionally omitted news entry. There is a list of commit checks in in devguide, and a script to do some. I realize that core developer time is scarce, so I have started to only work on patches after I've confirmed that someone is available and interested to review them. However, it would be great if some people could find time to look at the issues above as well. Having your contributions just languish in the bugtracker is really dispiriting... I *want* to contribute, and I can't believe that Python is the one open-source project that is not in need of more manpower. We need either more core developer personpower or more efficient use of the effort we do have -- or both. We seem to lose people as fast as we promote them. More efficient use of time might also reduce attrition. Right now we seem to be in an awkward phase of the core mentorship program. We have gotten some new people, like you, submitting multiple patches, but have not yet gotten enough new people to review and commit. > But for some reason it seems really hard to actually find something to do. Review and test other people's patches, if you are not already. If a 3.4 bugfix patch works and is ready to commit, and plausibly should be applied to 2.7 (maybe ask), but does not apply cleanly (common), see if the core developer on the issue would like you to tweak, test, and upload a 2.7 version. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Appeal for reviews
On 12 Apr 2014 18:08, "Terry Reedy" wrote: > On 4/12/2014 2:58 PM, Nikolaus Rath wrote: > >> I realize that core developer time is scarce, so I have started to only >> work on patches after I've confirmed that someone is available and >> interested to review them. However, it would be great if some people >> could find time to look at the issues above as well. Having your >> contributions just languish in the bugtracker is really dispiriting... I >> *want* to contribute, and I can't believe that Python is the one >> open-source project that is not in need of more manpower. > > > We need either more core developer personpower or more efficient use of the effort we do have -- or both. We seem to lose people as fast as we promote them. More efficient use of time might also reduce attrition. > > Right now we seem to be in an awkward phase of the core mentorship program. We have gotten some new people, like you, submitting multiple patches, but have not yet gotten enough new people to review and commit. PEP 462 covers the workflow problems that currently make it difficult not only to get patches merged, but also makes the existing core developers reluctant to add new core developers too hastily. We'll eventually get those resolved, but it's going to take time, since infrastructure support is incredibly short of contributors (even more so than core development in general), and there's already a non-trivial backlog of unresolved issues. Regards, Nick. > > > > But for some >> >> reason it seems really hard to actually find something to do. > > > Review and test other people's patches, if you are not already. If a 3.4 bugfix patch works and is ready to commit, and plausibly should be applied to 2.7 (maybe ask), but does not apply cleanly (common), see if the core developer on the issue would like you to tweak, test, and upload a 2.7 version. > > -- > Terry Jan Reedy > > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Appeal for reviews
I apologize for the tone. I need to go *right* now, and can't fix that. Really, I'm sympathetic and my goal is not just to defend python-dev, but to help you get the reviews your work deserves. Please read with that in mind. Steve Nikolaus Rath writes: > I've accumulated a number of patches in the issue tracker that are > waiting for someone to review/commit/reject them. This is the wrong place to post a personal request like this, now that the core-mentorship channel is available. The problem itself is well- known, but you don't offer a solution that makes it easier to review, so it's not really appropriate for Python-Dev. > I'm eager to make corrections as necessary, I just need someone to > look the work that I've done so far: > > * http://bugs.python.org/issue20951 (SSLSocket.send() returns 0 for > non-blocking socket) > > * http://bugs.python.org/issue1738 (filecmp.dircmp does exact match > only) > > * http://bugs.python.org/issue7776 (http.client.HTTPConnection > tunneling is broken) > > * http://bugs.python.org/issue20177 (Derby #8: Convert 28 sites to > Argument Clinic across 2 files) > > * http://bugs.python.org/issue19414 (iter(ordered_dict) yields keys > not in dict in some circumstances) > > * http://bugs.python.org/issue20578 (BufferedIOBase.readinto1 is > missing) > > * http://bugs.python.org/issue21057 (TextIOWrapper does not support > reading bytearrays or memoryviews) That's an impressive list, but it doesn't tell us what work you've done. There's a checklist in the devguide which should be more accurate (sorry about lack of URL), but I imagine it includes the following: * Has the issue been classified as bug or feature? * If bug, is it confirmed? * If complex, does it need a PEP? (probably irrelevant to your patches) * Is there agreement about requirements in the issue comments? * Is there a patch? * Does the design need review? * Has relevant documentation been added/updated (including docstrings, manuals, Whats New at least)? * Are there tests that the requirements are satisfied? * Are there tests for any regressions that arose in the process of developing the patch? * Have you signed a CA? (irrelevant to you IIRC) * Is the issue status updated to reflect the work done so far? It would help in getting reviewer attention to your work if in addition to a list of patches you provided an indication of (1) how complete the patch is and (2) what review is requested. That in itself is a strong indicator of quality. > I realize that core developer time is scarce, so I have started to only > work on patches after I've confirmed that someone is available and > interested to review them. However, it would be great if some people > could find time to look at the issues above as well. Having your > contributions just languish in the bugtracker is really > dispiriting... > I *want* to contribute, Not really. You *want* attention. You have *already* contributed, it's a matter of time before the contribution is integrated. There's nothing wrong with wanting to see your contribution integrated, but as you write yourself, core developer time is very scarce. Please be patient and keep pinging core-mentorship at intervals. > and I can't believe that Python is the one open-source project that > is not in need of more manpower. It's not. What is unusual (though hardly unique) about Python is the high quality demanded of both contributions and reviews. It is well- known that demand for quality screens out contributors who can't provide the quality, and it is equally well-known that it frustrates high-quality contributors who have not achieved "trust" yet. Motivating reviewers is not an easy problem to solve. > But for some reason it seems really hard to actually find something > to do.. Your list above makes it clear that you had little trouble finding things to do. I'm sure you can find more. Eventually people will start getting embarrassed by the length of your list of patches awaiting review. If you want to *do* something about this, maybe you could add a feature to the tracker to note that patches are awaiting review (nb -- it needs to identify who requested review or the feature will undoubtedly be abused). Ping the tracker-discuss list. You also might want to pay attention what's happening in the Python world in various seasons. Right now it's PyCon US (actually NA, emphasized by its venue in Montreal). Your post was poorly timed in that sense. Several of the obvious candidates for reviewer for your patches have been busy preparing for the language summit, and many more preparing talks or tutorials, as well as arranging for travel. There must be stuff of interest to you happening on twitter, etc., during PyCon. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/m
Re: [Python-Dev] Appeal for reviews
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/12/2014 08:30 PM, Stephen J. Turnbull wrote: > it's a matter of time before the contribution is integrated. Our current backlog is bad enough that many contributions are effectively wasted: they rot on the vine before they can be merged. Tres. - -- === Tres Seaver +1 540-429-0999 [email protected] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNJ4pUACgkQ+gerLs4ltQ4WIACfeoWID19lDf1wpFF2vtl1ZHRk q6gAnRrwLETLirZ6ulS0NivLmYcOOkzF =VHtW -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Appeal for reviews
On Sat, Apr 12, 2014, at 17:30, Stephen J. Turnbull wrote: > I apologize for the tone. I need to go *right* now, and can't fix > that. Really, I'm sympathetic and my goal is not just to defend > python-dev, but to help you get the reviews your work deserves. > Please read with that in mind. I don't think Nikolaus is wrong to post here. I often tell people that sometimes the only way to get your patches in is to constantly poke us about it. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] static typing of input arguments in signatures (was: Language Summit notes)
Stefan Behnel, 12.04.2014 19:11:
> Guido van Rossum, 10.04.2014 03:08:
>> - Jukka Lehtosalo gave a talk and answered questions about mypy, his design
>> and implementation of pragmatic type annotations (no new syntax required,
>> uses Python 3 function annotations).
>
> FWIW, signature type annotations aren't enough for a static compiler like
> Cython, which also benefits from local and global variable declarations,
> static functions, etc. However, we initially discussed this feature in the
> project some five years ago or so and never actually implemented it, so I
> finally decided to add support for it to Cython. There already was a way to
> provide static Cython/C type declarations in pure Python code, also for
> function arguments, but it's nice to have a way that is also naturally
> runtime inspectable in the signature.
>
> It essentially looks like this now:
>
> def func(plain_python_type: dict,
> named_python_type: 'list',
> explicit_python_type: {'type': dict},
> explicit_named_python_type: {'type': 'tuple'},
> explicit_c_type: {'ctype': 'int'}):
> ...
It may not be obvious to everyone, so I guess I should add a comment on why
this wasn't considered important enough during the last five years to
implement it before (and that didn't change much now). One thing I learned
in the Cython project is that it's often a bad idea to statically type
input arguments at all. The reason is that it violates the principle of
being liberal with input (but strict with output).
There are cases where this is ok, e.g. using the C type "double" is
perfectly ok most of the time, because it's not (really) range restricting
and all numeric-ish Python types can happily coerce to it. Using integer
types is ok only if their restricted range really is enough, but can lead
to the Py2.5 problem of having too small integer types if things grow
larger. Similarly, using self-defined (extension) types to type input
arguments is ok because at the native level, the code will almost certainly
depend on their internal implementation details, so accepting anything else
here would be useless and wrong (CPython does the same for "self" type
checking, for example).
However, what I've often seen people do is to write something like the
above example, i.e. they use explicit Python types for input arguments.
This leads to an overly narrow API that rejects lots of otherwise
acceptable input types. What people usually want as input type is something
like "iterable", or "mapping". What many users end up writing instead is
"list" or "dict". The reason is that in Python code, input really *is* a
list or a dict most of the time, and at the C level (to which Cython
translates), list and dict have (limited) performance advantages, whereas
"iterable" and "mapping" do not. So using something like the ABC types
Iterable or Mapping for static typing is almost completely useless, except
for documentation purposes (and maybe a bit earlier type checking, in some
cases).
The point where this is extremely visible is string/bytes input. I've seen
many people actually use "str" or "bytes" to type their input. In Python 2,
"str" is a very bad idea, because it excludes "unicode". In Py3, that's
less of a problem, because all reasonable string input really is "str" (or,
more rarely, a subtype). In both Py2 and Py3, however, statically typing
input as "bytes" is a *very* bad idea, because it excludes everything
bytes-ish: bytearray, memoryview, buffers. Many users don't see this need
at first. While using buffers instead is easy enough in Cython, getting it
right for a specific use case and properly using it to interface with
external native libraries is less straight forward and requires more
thought than just writing "I want bytes".
So, what I've learned from seven years of Cython is that static typing in
signatures is actually less interesting than you might think at first
sight. It might be ok for documentation purposes, although its verboseness
makes that also a bit questionable. But for actual input checking, there's
substantially more than just the (generic) type, even at the C level, so
users who properly understand the problem don't use static argument typing
in many cases and instead write their own input validation, conversion,
normalisation code. Or just let the code raise an exception if the input
doesn't work the way it's being used. Errors don't always have to be raised
at signature evaluation time.
Stefan
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Appeal for reviews
Benjamin Peterson writes: > I don't think Nikolaus is wrong to post here. I often tell people that > sometimes the only way to get your patches in is to constantly poke us > about it. I admit the tone was biased toward nagging or "blaming the victim", and again I apologize for causing misunderstanding. Nikolaus isn't "wrong" for posting here. My claim is that in current circumstances, core-mentorship would be a more *effective* channel because - core-mentorship is *explicitly* for poking Those Who Can Help (among other requests for help); - a surprisingly large (to me, anyway :-) fraction of core committers and people who may not be "core" but do a lot of mentoring for central projects like IDLE do hang out there; and - when reading core-mentorship their "mentor modes" will be engaged, whereas on python-dev they will often be mostly interested in a particular thread. I also suggested that some tweaks to the weekly issue report might help to catch the attention of those who can commit patches, but my ideas about that are still basically vaporware. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
