[Python-Dev] Call for participants: Windows Python security experts
Hi folks, The Python security team is a small group of core Python developers who triage and respond to vulnerability reports sent to [email protected]. We get all kinds of reports, for which we try to provide guidance and feedback, review patches, etc. Python being as secure as it is, traffic is fairly low. :) We have a dearth of Windows expertise on the team though, so I am putting out a call for participants. If you are an expert on Python for Windows operating systems and can make judgments about the validity of security reports for the platform, please contact us. Core developers are preferred, but motivation and available time is paramount. You're welcome to apply even if you're not a Windows expert, if you have the time and ability to help out in general. If you're interested, you can reach the team at [email protected]. Cheers, -Barry signature.asc Description: PGP signature ___ 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 393 Summer of Code Project
Hello all, I have implemented an initial version of PEP 393 -- "Flexible String Representation" as part of my Google Summer of Code project. My patch is hosted as a repository on bitbucket [1] and I created a related issue on the bug tracker [2]. I posted documentation for the current state of the development in the wiki [3]. Current tests show a potential reduction of memory by about 20% and CPU by 50% for a join micro benchmark. Starting a new interpreter still causes 3244 calls to create compatibility Py_UNICODE representations, 263 strings are created using the old API while 62719 are created using the new API. More measurements are on the wiki page [3]. If there is interest, I would like to continue working on the patch with the goal of getting it into Python 3.3. Any and all feedback is welcome. Regards, Torsten [1]: http://www.python.org/dev/peps/pep-0393 [2]: http://bugs.python.org/issue12819 [3]: http://wiki.python.org/moin/SummerOfCode/2011/PEP393 ___ 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 393 Summer of Code Project
On 8/22/2011 11:58 AM, Torsten Becker wrote: Hello all, I have implemented an initial version of PEP 393 -- "Flexible String Representation" as part of my Google Summer of Code project. My patch is hosted as a repository on bitbucket [1] and I created a related issue on the bug tracker [2]. I posted documentation for the current state of the development in the wiki [3]. Current tests show a potential reduction of memory by about 20% and CPU by 50% for a join micro benchmark. Starting a new interpreter still causes 3244 calls to create compatibility Py_UNICODE representations, 263 strings are created using the old API while 62719 are created using the new API. More measurements are on the wiki page [3]. If there is interest, I would like to continue working on the patch with the goal of getting it into Python 3.3. Any and all feedback is welcome. Sounds like great progress! ___ 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 393 Summer of Code Project
Hello, On Mon, 22 Aug 2011 14:58:51 -0400 Torsten Becker wrote: > > I have implemented an initial version of PEP 393 -- "Flexible String > Representation" as part of my Google Summer of Code project. My patch > is hosted as a repository on bitbucket [1] and I created a related > issue on the bug tracker [2]. I posted documentation for the current > state of the development in the wiki [3]. A couple of minor comments: - “The UTF-8 decoding fast path for ASCII only characters was removed and replaced with a memcpy if the entire string is ASCII.” The fast path would still be useful for mostly-ASCII strings, which are extremely common (unless UTF-8 has become a no-op?). - You could trim the debug results from the benchmark results, this may make them more readable. - You could try to run stringbench, which can be found at http://svn.python.org/projects/sandbox/trunk/stringbench (*) and there's iobench (the text mode benchmarks) in the Tools/iobench directory. (*) (yes, apparently we forgot to convert this one to Mercurial) 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 (3.2): #9200: The str.is* methods now work with strings that contain non-BMP
On Mon, 22 Aug 2011 19:31:32 +0200 ezio.melotti wrote: > http://hg.python.org/cpython/rev/06b30c5bcc3d > changeset: 72035:06b30c5bcc3d > branch: 3.2 > parent: 72026:c8e73a89150e > user:Ezio Melotti > date:Mon Aug 22 14:08:38 2011 +0300 > summary: > #9200: The str.is* methods now work with strings that contain non-BMP > characters even in narrow Unicode builds. That's a very cool improvement! cheers 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] Sphinx version for Python 2.x docs
Hi all, > Any chance the version of sphinx used to generate the docs on > docs.python.org could be updated? I'd like to discuss this aspect, in particular for the implication it has on http://bugs.python.org/issue12409 . Personally, I do think it has a value to have the same set of tools to build the Python documentation of the currently active branches. Currently, only 2.7 is different, since it still fetches (from svn.python.org... can we fix this too? suggestions welcome!) sphinx 0.6.7 while 3.2/3.3 uses 1.0.7. If you're worried about the time needed to convert the actual 2.7 doc to new sphinx format and all the related changes, I volunteer to do the job (and/or collaborate with whom is already on it), but what I want to understand if it's an acceptable change. I see sphinx more as of an internal, building tool, so freezing it it's like saying "don't upgrade gcc" or so. Now the delta is just the C functions definitions and some py-specific roles, but during the years it will increase. Keeping it small, simplifying the forward-port of doc patches (not needing to have 2 version between 2.7 and 3.x f.e.) and having a common set of tools for doc building is worth IMHO. What do you think about it? and yes Georg, I'd like to hear your opinion too :) Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ___ 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
