[Python-Dev] (no subject)
How closely is tokenize.detect_encoding() supposed to match PyTokenizer_FindEncoding()? From what I can tell, there is a subtle difference in their behavior that has bearing on PEP 263 handling during import. [1] Should any difference be considered a bug, or should I work around it? Thanks. -eric [1] http://www.python.org/dev/peps/pep-0263/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] support for encoding detection and PEP 263
Forgot the subject (going to bed now). On Thu, Apr 19, 2012 at 2:00 AM, Eric Snow wrote: > How closely is tokenize.detect_encoding() supposed to match > PyTokenizer_FindEncoding()? From what I can tell, there is a subtle > difference in their behavior that has bearing on PEP 263 handling > during import. [1] Should any difference be considered a bug, or > should I work around it? Thanks. > > -eric > > > [1] http://www.python.org/dev/peps/pep-0263/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Cython for cPickle?
Hi, I noticed that there is a PEP (3154) and a GSoC proposal about improving Pickle. Given the recent discussion on this list about using Cython for the import module, I wonder if it wouldn't make even more sense to switch from a C (accelerator) implementation to Cython for _pickle. The rationale is that C code that deals a lot with object operations tends to be rather verbose, and _pickle specifically looks very verbose in many places. Some of this is optimised I/O, ok, but most of it seems to take its complexity from code specialisations for builtin types and a lot of error handling code. A Cython reimplementation would take a lot of weight out of this. Note that the approach won't be as simple as compiling pickle.py. _pickle uses a lot of optimisations that only work at the C level, at least efficiently. So the idea would be to rewrite _pickle in Cython instead. It's currently about 6500 lines of C. Even if we divide that only by a rather conservative factor of 3, we'd end up with some 2000 lines of Cython code, all extracted straight from the existing C code. That sounds like less than two weeks of work, maybe even if we add the marshal module to it. In less than a month of GSoC time, this could easily reach a point where it's "close to the speed of what we have" and "fast enough", but a lot more accessible and maintainable, thus also making it easier to add the extensions described in the PEP. What do you think? Stefan ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] (no subject)
Am 19.04.2012 10:00, schrieb Eric Snow: > How closely is tokenize.detect_encoding() supposed to match > PyTokenizer_FindEncoding()? From what I can tell, there is a subtle > difference in their behavior that has bearing on PEP 263 handling > during import. [1] Should any difference be considered a bug, or > should I work around it? Thanks. If there is such a difference, it's a bug. The authority should be the PEP. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cython for cPickle?
> What do you think? I think I know what Jim Fulton thinks (as we talked about something like this a PyCon): don't. He is already sad that cPickle grew so much pickle features when it was designed as a real fast implementation. pickle speed is really important to some users, and any loss of performance needs serious justification. Easier maintenance is not a sufficient reason. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cython for cPickle?
On Thu, Apr 19, 2012 at 6:55 PM, Stefan Behnel wrote: > What do you think? I think the possible use of Cython for standard library extension modules is potentially worth looking into for the 3.4 timeframe (c.f. the recent multiple checkins sorting out the refcounts for the new ImportError helper function). There are obviously a lot of factors to consider before actually proceeding with such an approach (even for the extension modules), but a side-by-side comparison of pickle.py, the existing C accelerated pickle module and a Cython accelerated pickle module (including benchmark numbers) would be a valuable data point in any such discussion. However, it would definitely have to be pitched to any interested students as a proof-of-concept exercise, with a real possibility that the outcome will end up supporting MvL's reply. Regards, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Highlighting reference-stealing APIs [was Re: cpython: Fix email post-commit review comments.]
On 19 April 2012 02:20, Nick Coghlan wrote:
> On Thu, Apr 19, 2012 at 12:21 AM, Antoine Pitrou wrote:
>> (and here we see why reference-stealing APIs are a nuisance: because
>> you never know in advance whether a function will steal a reference or
>> not, and you have to read the docs for each and every C API call you
>> make)
>
> Yeah, it would have been nice if there was an explicit hint in the API
> names when reference stealing was involved, but I guess it's far too
> late now :(
It's too late to change the fn names sure, but you could change the
argument names in question for reference stealing apis with some kind
of markup.
That would make it fairly easy to write a script that did the checking for you :
int PyTuple_SetItem(PyObject *p, Py_ssize_t pos, PyObject *stolen_o)
Or better yet would be to mark the types :
int PyTuple_SetItem(PyObject *p, Py_ssize_t pos, PyStolenObject* o)
PyBorrowedObject* PyTuple_GetItem(PyObject *p, Py_ssize_t pos)
PyStolenObject and PyBorrowedObject would just be typedefs to PyObject
normally. But a consenting user could define PyENABLE_CHECKED_REFS
before including Python.h which would given
#if defined(PyENABLE_CHECKED_STOLEN_REFS)
struct PyStolenObject;
struct PyBorrowedObject;
#define PyYesIKnowItsStolen(o) ((PyStolenObject*)o)
#define PyYesIKnowItsBorrowed(o) ((PyObject*)o)
#else
typedef PyStolenObject PyObject;
typedef PyBorrowedObject PyObject;
#endif
Forcing the user to use
PyTuple_SetItem(p, pos, PyYesIKnowItsStolen(o))
PyObject * ref = PyYesIKnowItsBorrowed(PyTuple_GetItem(p, pos));
Or else it would fail to compile. The user could even add her own :
PyStolenObject* IncRefBecauseIKnowItsStolen(PyObject* o) {
PyIncRef(o); return (PyStolenObject*)o; }
PyObject* IncRefBecauseIKnowItsBorrowed(PyBorrowedObject* o) {
PyIncRef(o); return (PyObject*)o; }
This would not require a special gcc build and would be available to
anyone who wanted it. I use a similar, C++ based trick in my python
extension code to avoid the whole issue of ref leaking, but I have to
be careful at the point of calling the python api, having it automatic
would be great.
On a similar note, I have just implemented a wrapper around Python.h
which runtime checks that the GIL is held around every call to the
Python API or else fails very noisily. This was done because it turns
out that wxPython had a ton of non-GIL calls to the API causing random
sporadic set faults in our app. We now use it on several of our
extensions. It doesn't require any changes to Python.h, you just
need to add an include path before the python include path. Would
there be any interest in this?
Sam
On 19 April 2012 02:25, Nick Coghlan wrote:
> On Thu, Apr 19, 2012 at 11:04 AM, Gregory P. Smith wrote:
>> +1 Adding these annotations and setting up a buildbot that builds using
>> cpychecker would be a great.
>
> Even without the extra annotations, running cpychecker on at least one
> of the buildbots might be helpful.
>
> I'm in the process of setting up a buildbot for RHEL 6, once I get it
> up and running normally, I'll look into what it would take to install
> and enable cpychecker for the builds. (Or, alternatively, I may make
> it a separate cron job, similar to the daily refcount leak detection
> run).
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan | [email protected] | Brisbane, Australia
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/sam.partington%40gmail.com
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Highlighting reference-stealing APIs [was Re: cpython: Fix email post-commit review comments.]
Am 19.04.2012 12:42, schrieb Sam Partington: > On 19 April 2012 02:20, Nick Coghlan wrote: >> On Thu, Apr 19, 2012 at 12:21 AM, Antoine Pitrou wrote: >>> (and here we see why reference-stealing APIs are a nuisance: because >>> you never know in advance whether a function will steal a reference or >>> not, and you have to read the docs for each and every C API call you >>> make) >> >> Yeah, it would have been nice if there was an explicit hint in the API >> names when reference stealing was involved, but I guess it's far too >> late now :( > > It's too late to change the fn names sure, but you could change the > argument names in question for reference stealing apis with some kind > of markup. While it may too late to change the names, it's not to late to remove these functions entirely. It will take some time, but it would be possible to add parallel APIs that neither borrow nor steal references, and have them preferred over the existing APIs. Then, with Python 4, the old APIs could go away. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Issue #11750: The Windows API functions scattered in the _subprocess and
>>> Issue #11750: The Windows API functions scattered in the _subprocess and >>> _multiprocessing.win32 modules now live in a single module "_winapi". >>> Patch by sbt. >> >> Can we use Real Names, please? > > Do we have a policy about that? sbt seems happy using a pseudonym (and > I personally don't have a problem with it). We would have to ask a lawyer. Apparently, he signed a form, and presumably, that can be traced to a real person. However, we need to be extremely careful not to accept anonymous contributions, as then barrier to contribute stolen code is much lower. It took Linux a ten year copyright lawsuit to go through this; I don't want this to happen for Python. In any case, the real policy is that we should not accept significant changes without a contributor form. I, myself, feel extremely uncomfortable dealing with pseudonyms in the net, more so since I committed code from (and, IIRC, gave commit rights to) Reinhold Birkenfeld. Of course, the issue is different when you *know* it's pseudonym (and no, I have no bad feelings towards Georg about this at all). Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cython for cPickle?
On Thu, 19 Apr 2012 10:55:24 +0200 Stefan Behnel wrote: > > I noticed that there is a PEP (3154) and a GSoC proposal about improving > Pickle. Given the recent discussion on this list about using Cython for the > import module, I wonder if it wouldn't make even more sense to switch from > a C (accelerator) implementation to Cython for _pickle. I think that's quite orthogonal to PEP 3154 (which shouldn't add a lot of new code IMHO). > Note that the approach won't be as simple as compiling pickle.py. _pickle > uses a lot of optimisations that only work at the C level, at least > efficiently. So the idea would be to rewrite _pickle in Cython instead. > It's currently about 6500 lines of C. Even if we divide that only by a > rather conservative factor of 3, we'd end up with some 2000 lines of Cython > code, all extracted straight from the existing C code. That sounds like > less than two weeks of work, maybe even if we add the marshal module to it. I think this all needs someone to demonstrate the benefits, in terms of both readability/maintainability, and performance. Also, while C is a low-level language, Cython is a different language than Python when you start using its optimization features. This means core developers have to learn that language. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cython for cPickle?
On Thu, Apr 19, 2012 at 05:38, Nick Coghlan wrote: > On Thu, Apr 19, 2012 at 6:55 PM, Stefan Behnel wrote: >> What do you think? > > I think the possible use of Cython for standard library extension > modules is potentially worth looking into for the 3.4 timeframe (c.f. > the recent multiple checkins sorting out the refcounts for the new > ImportError helper function). I'd rather just "rtfm" as was suggested and get it right than switch everything around to Cython. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cython for cPickle?
On Thu, 19 Apr 2012 14:44:06 +0200, Antoine Pitrou wrote: > Also, while C is a low-level language, Cython is a different language > than Python when you start using its optimization features. This means > core developers have to learn that language. Hmm. On the other hand, perhaps some core developers (present or future) would prefer to learn Cython over learning C [*]. --David [*] For this you may actually want to read "learning to modify the Python C codebase", since in fact I know how to program in C, I just prefer to do as little of it as possible, and so haven't really learned the Python C codebase. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cython for cPickle?
Personally I find the unholy product of C and Python that is Cython to be more complex than the sum of the complexities of its parts. Is it really wise to be learning Cython without already knowing C, Python, and the CPython object model? While code generation alleviates the burden of tedious languages, it's also infinitely more complex, makes debugging very difficult and adds to prerequisite knowledge, among other drawbacks. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Suggested addition to PEP 8 for context managers
On Apr 18, 2012, at 09:26 PM, Guido van Rossum wrote: >On Wed, Apr 18, 2012 at 8:14 PM, Chris Angelico wrote: >> On Thu, Apr 19, 2012 at 1:06 PM, Eli Bendersky wrote: >>> (quoting GvR) Let's change this to something more reasonable, e.g. """ If operators with different priorities are used, consider adding whitespace around the operators with the lowest priority(ies). This is very much to taste, however, never use more than one space, and always have the same amount of whitespace on both sides of a binary operator. """ >>> >>> +1, a very welcome change to a piece of PEP8 I've always felt >>> uncomfortable with. Tiny nitpick: I'd just replace the comma following >>> "however" with a period or semicolon. >> >> Following or preceding? Either works, but there's a slight shift of >> meaning depending on which punctuation gets the upgrade. What was the >> original intent of the paragraph? > >I meant the semicolon to be before 'however'. I'll make this change to the PEP. I'm not entirely sure the Yes/No examples are great illustrations of this change in wording though. Here's the diff so far (uncommitted): diff -r 34076bfed420 pep-0008.txt --- a/pep-0008.txt Thu Apr 19 10:32:50 2012 +0200 +++ b/pep-0008.txt Thu Apr 19 10:53:15 2012 -0400 @@ -305,7 +305,11 @@ ``>=``, ``in``, ``not in``, ``is``, ``is not``), Booleans (``and``, ``or``, ``not``). -- Use spaces around arithmetic operators: +- If operators with different priorities are used, consider adding + whitespace around the operators with the lowest priority(ies). This + is very much to taste; however, never use more than one space, and + always have the same amount of whitespace on both sides of a binary + operator. Yes:: Cheers, -Barry ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Suggested addition to PEP 8 for context managers
Hi, +- If operators with different priorities are used, consider adding + whitespace around the operators with the lowest priority(ies). This + is very much to taste; however, never use more than one space, and + always have the same amount of whitespace on both sides of a binary + operator. Does “this is very much to taste” means that it’s a style judgment where each team or individual may make different choices? I’m not a native speaker and I’m not sure about the intended meaning. Cheers ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Suggested addition to PEP 8 for context managers
On Fri, Apr 20, 2012 at 1:00 AM, Éric Araujo wrote: > Hi, > >> +- If operators with different priorities are used, consider adding >> + whitespace around the operators with the lowest priority(ies). This >> + is very much to taste; however, never use more than one space, and >> + always have the same amount of whitespace on both sides of a binary >> + operator. > > Does “this is very much to taste” means that it’s a style judgment where > each team or individual may make different choices? I’m not a native > speaker and I’m not sure about the intended meaning. Yes. It's like writing instructions for how to make a cup of tea. You might want to put in one spoon of sugar, someone else might prefer two. On the instructions, you simply write "Add sugar to taste", and that's what this is drawing analogy with. The PEP, as then written, would happily accept all of these: x = y*2+z*3 x = y*2 + z*3 x = y * 2 + z * 3 but would advise against: x =y*2 + z* 3 ChrisA ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Suggested addition to PEP 8 for context managers
On Apr 19, 2012, at 11:00 AM, Éric Araujo wrote: >Hi, > >> +- If operators with different priorities are used, consider adding >> + whitespace around the operators with the lowest priority(ies). This >> + is very much to taste; however, never use more than one space, and >> + always have the same amount of whitespace on both sides of a binary >> + operator. > >Does “this is very much to taste” means that it’s a style judgment where each >team or individual may make different choices? I’m not a native speaker and >I’m not sure about the intended meaning. If I change that phrase to "Use your own judgement" does that help? -Barry ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Suggested addition to PEP 8 for context managers
On Thu, Apr 19, 2012 at 11:15:38AM -0400, Barry Warsaw wrote: > On Apr 19, 2012, at 11:00 AM, ??ric Araujo wrote: > >> +- If operators with different priorities are used, consider adding > >> + whitespace around the operators with the lowest priority(ies). This > >> + is very much to taste; however, never use more than one space, and > >> + always have the same amount of whitespace on both sides of a binary > >> + operator. > > > >Does ???this is very much to taste??? means that it???s a style judgment > >where each > >team or individual may make different choices? I???m not a native speaker > >and > >I???m not sure about the intended meaning. > > If I change that phrase to "Use your own judgement" does that help? Yes, in my opinion. Oleg. -- Oleg Broytmanhttp://phdru.name/[email protected] Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Suggested addition to PEP 8 for context managers
If I change that phrase to "Use your own judgement" does that help? It does. It may also help fight the mindset that PEP 8 is a Law. Regards ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Suggested addition to PEP 8 for context managers
was sent to Barry-only by mistake On Thu, Apr 19, 2012 at 17:20, Tshepang Lekhonkhobe wrote: > On Thu, Apr 19, 2012 at 17:15, Barry Warsaw wrote: >> If I change that phrase to "Use your own judgement" does that help? > > I would prefer "This is a matter of taste...". Much closer to original > meaning, and I think it's a more common phrase. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Issue #11750: The Windows API functions scattered in the _subprocess and
On Thu, Apr 19, 2012 at 4:19 AM, "Martin v. Löwis" wrote: Issue #11750: The Windows API functions scattered in the _subprocess and _multiprocessing.win32 modules now live in a single module "_winapi". Patch by sbt. >>> >>> Can we use Real Names, please? >> >> Do we have a policy about that? sbt seems happy using a pseudonym (and >> I personally don't have a problem with it). > > We would have to ask a lawyer. Apparently, he signed a form, and > presumably, that can be traced to a real person. However, we need to > be extremely careful not to accept anonymous contributions, as then > barrier to contribute stolen code is much lower. It took Linux a ten > year copyright lawsuit to go through this; I don't want this to happen > for Python. > > In any case, the real policy is that we should not accept significant > changes without a contributor form. > > I, myself, feel extremely uncomfortable dealing with pseudonyms in the > net, more so since I committed code from (and, IIRC, gave commit rights > to) Reinhold Birkenfeld. Of course, the issue is different when you > *know* it's pseudonym (and no, I have no bad feelings towards Georg > about this at all). I'd like to copy for posterity what I wrote off-list about this incident: I'm against accepting anonymous patches, period, unless the core developer who accepts them vets them *very* carefully and can vouch for them as if the core developer wrote the patch personally. Giving an anonymous person commit rights does not meet my standard for good stewardship of the code base. (But... see below.) Of course, knowing the name is not *sufficient* to give a person commit rights -- we know what's needed there, which includes a trust relationship with the contributor over a long time and with multiple core committers. This *process* of vetting committers in turn is necessary so that others, way outside our community, will trust us. When open source was new, I got regular requests from lawyers working for large companies wanting to see the list of contributors. Eventually this stopped, because the lawyers started understanding open source, but part of that understanding included the idea that a typical open source project actually has a high moral code of conduct (written or not). That said, I can think of plenty of reasons why a contributor does not want their real name published. Some of those are bad -- e.g. if you worry that you'll be embarrassed by your contributions in the future I'm not sure I'd want to see your code in the repository; if you don't want your employer to find out that you're contributing you might be violating your employment contract and the PSF could get into trouble for e.g. incorporating patented code; and I'm not sure we'd like to accept code from convicted fellons (though I'd consider that a gray area). But some might be acceptable. E.g. someone who is regularly in the news might not want to attract gawkers or reveal their personal email address; someone who is hiding from the law in an oppressive country (even the US, depending on which law we're talking about) might need to be protected; someone might have fears for their personal safety. In all those cases I think there should be some core contributors who know the real identity of the contributor. These must also know the reason for the anonymity and agree that it's important to maintain it. It must also be known to the community at large that the contributor is using a pseudonym. If the contributor is not comfortable revealing their identity to any core contributors, I don't think there is enough of a trust relationship to build on for a successful career as a contributor to Python. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Issue #11750: The Windows API functions scattered in the _subprocess and
On Thu, Apr 19, 2012 at 17:51, Guido van Rossum wrote: > and I'm not sure we'd like to > accept code from convicted fellons (though I'd consider that a gray > area). This makes me curious... why would that be a problem at all (assuming the felony is not related to the computing field)? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Issue #11750: The Windows API functions scattered in the _subprocess and
On Apr 19, 2012, at 11:51 AM, Guido van Rossum wrote: > In all those cases I think there should be some core contributors who > know the real identity of the contributor. These must also know the > reason for the anonymity and agree that it's important to maintain it. > It must also be known to the community at large that the contributor > is using a pseudonym. If the contributor is not comfortable revealing > their identity to any core contributors, I don't think there is enough > of a trust relationship to build on for a successful career as a > contributor to Python. I do think that python-dev should be clear that by "real" identity you mean "legal" identity. There are plenty of cases where the name a person is known by in more "real" situations is not in fact their legal name. There are also cases where legal names are different in different jurisdictions; especially people with CJK names may have different orthographies of the "same" name in different jurisdictions or even completely different names in different places, if they have immigrated to a different country. So there should be a legal name on file somewhere for copyright provenance purposes, but this should not need to be the same name that is present in commit logs, as long as there's a mapping recorded that can be made available to any interested lawyer. (Hopefully this is not a practical issue, but this is one of my pet peeves - for obvious reasons.) -glyph ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Issue #11750: The Windows API functions scattered in the _subprocess and
On Thu, Apr 19, 2012 at 9:02 AM, Tshepang Lekhonkhobe wrote: > On Thu, Apr 19, 2012 at 17:51, Guido van Rossum wrote: >> and I'm not sure we'd like to >> accept code from convicted fellons (though I'd consider that a gray >> area). > > This makes me curious... why would that be a problem at all (assuming > the felony is not related to the computing field)? Because the person might not be trustworthy, period. Or it might reflect badly upon Python's reputation. But yes, I could also see cases where we'd chose to trust the person anyway. This is why I said it's a gray area -- it can only be determined on a case-by-case basis. The most likely case might actually be someone like Aaron Swartz. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Issue #11750: The Windows API functions scattered in the _subprocess and
On Thu, Apr 19, 2012 at 9:06 AM, Glyph wrote: > On Apr 19, 2012, at 11:51 AM, Guido van Rossum wrote: > > In all those cases I think there should be some core contributors who > know the real identity of the contributor. These must also know the > reason for the anonymity and agree that it's important to maintain it. > It must also be known to the community at large that the contributor > is using a pseudonym. If the contributor is not comfortable revealing > their identity to any core contributors, I don't think there is enough > of a trust relationship to build on for a successful career as a > contributor to Python. > > > I do think that python-dev should be clear that by "real" identity you mean > "legal" identity. > > There are plenty of cases where the name a person is known by in more "real" > situations is not in fact their legal name. There are also cases where > legal names are different in different jurisdictions; especially people with > CJK names may have different orthographies of the "same" name in different > jurisdictions or even completely different names in different places, if > they have immigrated to a different country. > > So there should be a legal name on file somewhere for copyright provenance > purposes, but this should not need to be the same name that is present in > commit logs, as long as there's a mapping recorded that can be made > available to any interested lawyer. > > (Hopefully this is not a practical issue, but this is one of my pet peeves - > for obvious reasons.) Heh. I was hoping to avoid too much legal wrangling. Note that we don't require legal proof of identity; that would be an undue burden and more than I would personally put up with as a contributor. The primary concept here is trust, and identity can be seen as an approximation of that at best. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Issue #11750: The Windows API functions scattered in the _subprocess and
On Thu, Apr 19, 2012 at 18:55, Guido van Rossum wrote: > On Thu, Apr 19, 2012 at 9:02 AM, Tshepang Lekhonkhobe > wrote: >> On Thu, Apr 19, 2012 at 17:51, Guido van Rossum wrote: >>> and I'm not sure we'd like to >>> accept code from convicted fellons (though I'd consider that a gray >>> area). >> >> This makes me curious... why would that be a problem at all (assuming >> the felony is not related to the computing field)? > > Because the person might not be trustworthy, period. Or it might > reflect badly upon Python's reputation. But yes, I could also see > cases where we'd chose to trust the person anyway. This is why I said > it's a gray area -- it can only be determined on a case-by-case basis. > The most likely case might actually be someone like Aaron Swartz. Even if Aaron submits typo fixes for documentation :) I would think that being core developer would be the only thing that would require trust. As for a random a contributor, their patches are always reviewed by core developers before going in, so I don't see any need for trust there. Identity is another matter of course, but no one even checks if I'm the real Tshepang Lekhonkhobe. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Issue #11750: The Windows API functions scattered in the _subprocess and
On Thu, Apr 19, 2012 at 10:13 AM, Tshepang Lekhonkhobe wrote: > On Thu, Apr 19, 2012 at 18:55, Guido van Rossum wrote: >> On Thu, Apr 19, 2012 at 9:02 AM, Tshepang Lekhonkhobe >> wrote: >>> On Thu, Apr 19, 2012 at 17:51, Guido van Rossum wrote: and I'm not sure we'd like to accept code from convicted fellons (though I'd consider that a gray area). >>> >>> This makes me curious... why would that be a problem at all (assuming >>> the felony is not related to the computing field)? >> >> Because the person might not be trustworthy, period. Or it might >> reflect badly upon Python's reputation. But yes, I could also see >> cases where we'd chose to trust the person anyway. This is why I said >> it's a gray area -- it can only be determined on a case-by-case basis. >> The most likely case might actually be someone like Aaron Swartz. > > Even if Aaron submits typo fixes for documentation :) > > I would think that being core developer would be the only thing that > would require trust. As for a random a contributor, their patches are > always reviewed by core developers before going in, so I don't see any > need for trust there. Identity is another matter of course, but no one > even checks if I'm the real Tshepang Lekhonkhobe. I don't think you're a core contributor, right? Even if a core developer reviews the code, it requires a certain level of trust, especially for complex patches. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Issue #11750: The Windows API functions scattered in the _subprocess and
On Thu, 19 Apr 2012 10:21:00 -0700 Guido van Rossum wrote: > On Thu, Apr 19, 2012 at 10:13 AM, Tshepang Lekhonkhobe > wrote: > > On Thu, Apr 19, 2012 at 18:55, Guido van Rossum wrote: > >> On Thu, Apr 19, 2012 at 9:02 AM, Tshepang Lekhonkhobe > >> wrote: > >>> On Thu, Apr 19, 2012 at 17:51, Guido van Rossum wrote: > and I'm not sure we'd like to > accept code from convicted fellons (though I'd consider that a gray > area). > >>> > >>> This makes me curious... why would that be a problem at all (assuming > >>> the felony is not related to the computing field)? > >> > >> Because the person might not be trustworthy, period. Or it might > >> reflect badly upon Python's reputation. But yes, I could also see > >> cases where we'd chose to trust the person anyway. This is why I said > >> it's a gray area -- it can only be determined on a case-by-case basis. > >> The most likely case might actually be someone like Aaron Swartz. > > > > Even if Aaron submits typo fixes for documentation :) > > > > I would think that being core developer would be the only thing that > > would require trust. As for a random a contributor, their patches are > > always reviewed by core developers before going in, so I don't see any > > need for trust there. Identity is another matter of course, but no one > > even checks if I'm the real Tshepang Lekhonkhobe. > > I don't think you're a core contributor, right? Even if a core > developer reviews the code, it requires a certain level of trust, > especially for complex patches. I would say trust is gained through previous patches, not through personal knowledge of the contributor, though. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Issue #11750: The Windows API functions scattered in the _subprocess and
Le jeudi 19 avril 2012 à 10:40 -0700, Guido van Rossum a écrit : > >> > >> I don't think you're a core contributor, right? Even if a core > >> developer reviews the code, it requires a certain level of trust, > >> especially for complex patches. > > > > I would say trust is gained through previous patches, not through > > personal knowledge of the contributor, though. > > You don't have to have face-to-face meetings (I never may most Python > contributors face-to-face until many years later, and some I've never > met) but you do gain insight into their personality through the > interaction *around* patches. To me, that counts just as much as the > objective quality of their patches. Agreed. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Issue #11750: The Windows API functions scattered in the _subprocess and
On Thu, Apr 19, 2012 at 10:30 AM, Antoine Pitrou wrote: > On Thu, 19 Apr 2012 10:21:00 -0700 > Guido van Rossum wrote: >> On Thu, Apr 19, 2012 at 10:13 AM, Tshepang Lekhonkhobe >> wrote: >> > On Thu, Apr 19, 2012 at 18:55, Guido van Rossum wrote: >> >> On Thu, Apr 19, 2012 at 9:02 AM, Tshepang Lekhonkhobe >> >> wrote: >> >>> On Thu, Apr 19, 2012 at 17:51, Guido van Rossum wrote: >> and I'm not sure we'd like to >> accept code from convicted fellons (though I'd consider that a gray >> area). >> >>> >> >>> This makes me curious... why would that be a problem at all (assuming >> >>> the felony is not related to the computing field)? >> >> >> >> Because the person might not be trustworthy, period. Or it might >> >> reflect badly upon Python's reputation. But yes, I could also see >> >> cases where we'd chose to trust the person anyway. This is why I said >> >> it's a gray area -- it can only be determined on a case-by-case basis. >> >> The most likely case might actually be someone like Aaron Swartz. >> > >> > Even if Aaron submits typo fixes for documentation :) >> > >> > I would think that being core developer would be the only thing that >> > would require trust. As for a random a contributor, their patches are >> > always reviewed by core developers before going in, so I don't see any >> > need for trust there. Identity is another matter of course, but no one >> > even checks if I'm the real Tshepang Lekhonkhobe. >> >> I don't think you're a core contributor, right? Even if a core >> developer reviews the code, it requires a certain level of trust, >> especially for complex patches. > > I would say trust is gained through previous patches, not through > personal knowledge of the contributor, though. You don't have to have face-to-face meetings (I never may most Python contributors face-to-face until many years later, and some I've never met) but you do gain insight into their personality through the interaction *around* patches. To me, that counts just as much as the objective quality of their patches. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cython for cPickle?
Matt Joiner, 19.04.2012 16:13: > Personally I find the unholy product of C and Python that is Cython to be > more complex than the sum of the complexities of its parts. Is it really > wise to be learning Cython without already knowing C, Python, and the > CPython object model? The main obstacle that I regularly see for users of the C-API is actually reference counting and an understanding of what borrowed references and owned references imply in a given code context. In fact, I can't remember seeing any C extension code getting posted on Python mailing lists (core developers excluded) that has no ref-counting bugs or at least a severe lack of error handling. Usually, such code is also accompanied by a comment that the author is not sure if everything is correct and asks for advice, and that's rather independent of the functional complexity of the code snippet. OTOH, I've also seen a couple of really dangerous code snippets already that posters apparently meant to show off with, so not everyone is aware of these obstacles. Also, the C code by inexperienced programmers tends to be fairly inefficient because they simply do not know what impact some convenience functions have. So they tend to optimise prematurely in places where they feel more comfortable, but that can never make up for the overhead that simple and very conveniently looking C-API functions introduce in other places. Value packing comes to mind. So, from my experience, there is a serious learning curve beyond knowing C, right from the start when trying to work on C extensions, including CPython's own code, because the C-API is far from trivial. And that's the kind of learning curve that Cython tries to lower. It makes it substantially easier to write correct code, simply by letting you write Python code instead of C plus C-API code. And once it works, you can start making it explicitly faster by applying "I know what I'm doing" schemes to proven hot spots or by partially rewriting it. And if you do not know yet what you're doing, then *that's* where the learning curve begins. But by then, your code is basically written, works more or less and can be benchmarked. > While code generation alleviates the burden of tedious languages, it's also > infinitely more complex, makes debugging very difficult and adds to > prerequisite knowledge, among other drawbacks. You can use gdb for source level debugging of Cython code and cProfile to profile it. Try that with C-API code. Stefan ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP-419: Protecting cleanup statements from interruptions
> PEP: 419 > Title: Protecting cleanup statements from interruptions > Version: $Revision$ > Last-Modified: $Date$ > Author: Paul Colomiets > Status: Draft > Type: Standards Track > Content-Type: text/x-rst > Created: 06-Apr-2012 > Python-Version: 3.3 Hi, I think your PEP should at least mention that the signal.pthread_sigmask() exists, function added to Python 3.3. signal.pthread_sigmask() is maybe less practical than your proposition (each finally block has to be patched), but it is the best way to ignore temporary signals. Using signal.pthread_sigmask(), you guarantee that EINTR will not occurs... if you use it on all threads! http://mail.python.org/pipermail/python-ideas/2012-April/014749.html Victor ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cython for cPickle?
On Thu, Apr 19, 2012 at 16:08, Stefan Behnel >> While code generation alleviates the burden of tedious languages, it's also >> infinitely more complex, makes debugging very difficult and adds to >> prerequisite knowledge, among other drawbacks. > > You can use gdb for source level debugging of Cython code and cProfile to > profile it. Try that with C-API code. I know I'm in the minority of committers being on Windows, but we do receive a good amount of reports and contributions from Windows users who dive into the C code. The outside contributors actually gave the strongest indication that we needed to move to VS2010. Visual Studio by itself makes debugging unbelievably easy, and with the Python Tools for VS plugin it even allows Visual Studio's built-in profiler to work. I know Windows is not on most people's maps, but if we have to scrap the debugger, that's another learning curve attachment to evaluate. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 418: Add monotonic time, performance counter and process time functions
On 19Apr2012 10:47, Stephen J. Turnbull wrote: | On Thu, Apr 19, 2012 at 8:15 AM, Victor Stinner | wrote: | > Well, I asked on IRC what I should do for these definitions because | > I'm too tired to decide what to do. [[...]] I replaced these definitions with yours. | | That was nice of you. In return, I'll go over the PEP to check that | usage is appropriate (eg, in some places "resolution" was used in the | sense of computer science's "precision" == reported digits). Hmm. Let me know when you're done too; my counterproposal example implementation uses .resolution as the name for the metadata specifying the fineness of the OS call API (not the accuracy of the clock). So I would like to adjust my metadata to match and send Vicotr updated code for the snapshot he has in the PEP. Cheers, -- Cameron Simpson DoD#743 http://www.cskk.ezoshosting.com/cs/ The Few. The Proud. The Politically Incorrect. - Steve Masticola ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cython for cPickle?
Brian Curtin, 19.04.2012 23:19: > On Thu, Apr 19, 2012 at 16:08, Stefan Behnel >>> While code generation alleviates the burden of tedious languages, it's also >>> infinitely more complex, makes debugging very difficult and adds to >>> prerequisite knowledge, among other drawbacks. >> >> You can use gdb for source level debugging of Cython code and cProfile to >> profile it. Try that with C-API code. > > I know I'm in the minority of committers being on Windows, but we do > receive a good amount of reports and contributions from Windows users > who dive into the C code. Doesn't match my experience at all - different software target audiences, I guess. > Visual Studio by itself makes debugging unbelievably easy, and with > the Python Tools for VS plugin it even allows Visual Studio's built-in > profiler to work. I know Windows is not on most people's maps, but if > we have to scrap the debugger, that's another learning curve > attachment to evaluate. What I meant was that there's pdb for debugging Python code (which doesn't know about the C code it executes) and gdb (or VS) for debugging C code, from which you can barely infer the Python code it executes. For Cython code, you can use gdb for both Cython and C, and within limits also for Python code. Here's a quick intro to see what I mean: http://docs.cython.org/src/userguide/debugging.html For profiling, you can use cProfile for Python code (which doesn't tell you about the C code it executes) and oprofile, callgrind, etc. (incl. VS) for C code, from which it's non-trivial to infer the relation to the Python code. With Cython, you can use cProfile for both Cython and Python code as long as you stay at the source code level, and only need to descend to a low-level profiler when you care about the exact details, usually assembly jumps and branches. Anyway, I guess this is getting off-topic for this list. Stefan ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cython for cPickle?
On Thu, Apr 19, 2012 at 17:21, Stefan Behnel wrote: > Brian Curtin, 19.04.2012 23:19: >> On Thu, Apr 19, 2012 at 16:08, Stefan Behnel While code generation alleviates the burden of tedious languages, it's also infinitely more complex, makes debugging very difficult and adds to prerequisite knowledge, among other drawbacks. >>> >>> You can use gdb for source level debugging of Cython code and cProfile to >>> profile it. Try that with C-API code. >> >> I know I'm in the minority of committers being on Windows, but we do >> receive a good amount of reports and contributions from Windows users >> who dive into the C code. > > Doesn't match my experience at all - different software target audiences, I > guess. I'm don't know what this means. I work on CPython, which is the target audience at hand, and I come across reports and contributions from Windows users for C extensions. >> Visual Studio by itself makes debugging unbelievably easy, and with >> the Python Tools for VS plugin it even allows Visual Studio's built-in >> profiler to work. I know Windows is not on most people's maps, but if >> we have to scrap the debugger, that's another learning curve >> attachment to evaluate. > > What I meant was that there's pdb for debugging Python code (which doesn't > know about the C code it executes) and gdb (or VS) for debugging C code, > from which you can barely infer the Python code it executes. For Cython > code, you can use gdb for both Cython and C, and within limits also for > Python code. Here's a quick intro to see what I mean: > > http://docs.cython.org/src/userguide/debugging.html I know what you meant. What I meant is "easy debugging on Windows goes away, now I have to setup and learn GDB on Windows". *I* can do that. Does the rest of the community want to have to do that as well? We should also take into consideration how something like this affects the third-party IDEs and their debugger support. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 420: Implicit Namespace Packages
If you have any comments, please join the discussion over in import-sig. Eric. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] peps: Note that ImportError will no longer be raised due to a missing __init__.py
It's actually an ImportWarning, not Error (or at least that's what I meant on import-sig). If the module is eventually found then there is no error. On Thu, Apr 19, 2012 at 18:56, eric.smith wrote: > http://hg.python.org/peps/rev/af61fe9a56fb > changeset: 4281:af61fe9a56fb > user:Eric V. Smith > date:Thu Apr 19 18:56:22 2012 -0400 > summary: > Note that ImportError will no longer be raised due to a missing > __init__.py file. > > files: > pep-0420.txt | 5 + > 1 files changed, 5 insertions(+), 0 deletions(-) > > > diff --git a/pep-0420.txt b/pep-0420.txt > --- a/pep-0420.txt > +++ b/pep-0420.txt > @@ -148,6 +148,11 @@ > path. With namespace packages, all entries in the path must be > scanned. > > +Note that an ImportError will no longer be raised for a directory > +lacking an ``__init__.py`` file. Such a directory will now be imported > +as a namespace package, whereas in prior Python versions an > +ImportError would be raised. > + > At PyCon 2012, we had a discussion about namespace packages at which > PEP 382 and PEP 402 were rejected, to be replaced by this PEP [1]_. > > > -- > Repository URL: http://hg.python.org/peps > > ___ > Python-checkins mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-checkins > > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
