Re: [Python-Dev] Summary of Python tracker Issues
Most recent 15 issues waiting for review (15) = Just curious: How is a issue considered "waiting for review"? Thanks! francis ___ 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] Summary of Python tracker Issues
Zitat von francis : Most recent 15 issues waiting for review (15) = Just curious: How is a issue considered "waiting for review"? Issues that have the "patch" or "needs review" keyword or are in the "patch review" stage. 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] Summary of Python tracker Issues
Most recent 15 issues waiting for review (15) = Just curious: How is a issue considered "waiting for review"? Issues that have the "patch" or "needs review" keyword or are in the "patch review" stage. Thank you! Is there a easy way to automate this?: - Get a list the "waiting for review" issues - Get the last patch - Try to apply that patch to the version(s) to check if that patch already applies? Regards, francis ___ 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] Summary of Python tracker Issues
Zitat von francis :
Is there a easy way to automate this?:
- Get a list the "waiting for review" issues
Not exactly this precise list; instead, a list of issues with a patch:
s=xmlrpclib.ServerProxy("http://bugs.python.org",allow_none=True)
s.filter('issue',dict(keywords=2,status=1})
The other conditions need to be queried separately (although you
could search for both keywords in a single query).
- Get the last patch
s.display('issue12201','files')
The latest patch will be the one with the highest ID.
To then download the patch, just download
http://bugs.python.org/file/arbitrary-name.diff
Alternatively, do
s.display('file22163', 'content')
- Try to apply that patch to the version(s) to check if that patch
already applies?
This should be possible by just running patch(1) through the subprocess
module (and hg revert afterwards). You may have to do some patch parsing
to find out whether to pass -p0 or -p1.
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] Summary of Python tracker Issues
Hi,
On Sat, Aug 25, 2012 at 2:07 PM, wrote:
>
> Zitat von francis :
>
>
>> Is there a easy way to automate this?:
>>
>> - Get a list the "waiting for review" issues
>
>
> Not exactly this precise list; instead, a list of issues with a patch:
>
> s=xmlrpclib.ServerProxy("http://bugs.python.org",allow_none=True)
> s.filter('issue',dict(keywords=2,status=1})
>
> The other conditions need to be queried separately (although you
> could search for both keywords in a single query).
>
> [...]
In addition, you might want to check the Roundup XML-RPC docs:
http://roundup.sourceforge.net/docs/xmlrpc.html
and the source of the script that generates the summary:
http://hg.python.org/tracker/python-dev/file/default/scripts/roundup-summary
Best Regards,
Ezio Melotti
___
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 2.7: only Visual Studio 2008?
> Compatibility issues may lead to other strange bugs, too. IIRC each > msvcrt has its own thread local storage and therefore its own errno > handling. An extension compiled with VS 2010 won't be able to use the > PyErr_SetFromErrno*() function correctly. That's much harder to debug > than a FILE pointer mismatch because it usually doesn't cause a segfault. Interesting point. This somewhat breaks the stable ABI, which does include three SetFromErrno functions. So I guess we need to warn users of the stable ABI against using these functions. A solution would then be to add an additional set of functions which expect errno as a parameter, although this is quite some complication. Another solution is to introduce a Py_errno macro (and _Py_errno function) which exposes Python's view of errno, so code that might be confronted with this issue would write Py_errno = errno; before calling any of these functions. Except for the FILE* issue, I never considered any of the other issues really relevant for Python extensions, namely: - each CRT has its own heap, allocating on one heap and releasing to the other can leak. Not an issue for Python, since no Python API involves malloc/free pairs across DLL boundaries. - each CRT has its own timezone. This isn't really an issue, as they still get initialized consistently when the process starts (I guess except when the process starts before the DST change, but imports the extension after the DST change). - each CRT has its own locale. This may be an issue if an extension module relies on the CRT locale for data formatting; I just think this is unlikely to occur in practice (and when it does, it's easily notable). Anything else that you are aware of? 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] Python 2.7: only Visual Studio 2008?
"Martin v. L?wis" wrote: > - each CRT has its own locale. This may be an issue if an extension > module relies on the CRT locale for data formatting; I just think > this is unlikely to occur in practice (and when it does, it's easily > notable). _decimal's 'n' format specifier actually relies on the CRT locale. The functions in question are in libmpdec, so on Windows it is not possible to compile a static libmpdec and build the module from that. Well, it's possible, but setting the locale from Python then has no effect on the module, IIRC. Stefan Krah ___ 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 2.7: only Visual Studio 2008?
On 25.08.2012 19:36, Stefan Krah wrote: > "Martin v. L?wis" wrote: >> - each CRT has its own locale. This may be an issue if an extension >> module relies on the CRT locale for data formatting; I just think >> this is unlikely to occur in practice (and when it does, it's easily >> notable). > > _decimal's 'n' format specifier actually relies on the CRT locale. The > functions in question are in libmpdec, so on Windows it is not possible > to compile a static libmpdec and build the module from that. Building a static libmpdec should work fine, as long as it links with the CRT DLL. Most likely, the problem was that the project file in question would also link with the static CRT, which then causes the problem. But I see the point that extension modules may rely on the locale set by the Python script. 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
[Python-Dev] [RELEASED] Python 3.3.0 release candidate 1
On behalf of the Python development team, I'm delighted to announce the
first release candidate of Python 3.3.0.
This is a preview release, and its use is not recommended in
production settings.
Python 3.3 includes a range of improvements of the 3.x series, as well
as easier porting between 2.x and 3.x. Major new features and changes
in the 3.3 release series are:
* PEP 380, syntax for delegating to a subgenerator ("yield from")
* PEP 393, flexible string representation (doing away with the
distinction between "wide" and "narrow" Unicode builds)
* A C implementation of the "decimal" module, with up to 80x speedup
for decimal-heavy applications
* The import system (__import__) now based on importlib by default
* The new "lzma" module with LZMA/XZ support
* PEP 397, a Python launcher for Windows
* PEP 405, virtual environment support in core
* PEP 420, namespace package support
* PEP 3151, reworking the OS and IO exception hierarchy
* PEP 3155, qualified name for classes and functions
* PEP 409, suppressing exception context
* PEP 414, explicit Unicode literals to help with porting
* PEP 418, extended platform-independent clocks in the "time" module
* PEP 412, a new key-sharing dictionary implementation that
significantly saves memory for object-oriented code
* PEP 362, the function-signature object
* The new "faulthandler" module that helps diagnosing crashes
* The new "unittest.mock" module
* The new "ipaddress" module
* The "sys.implementation" attribute
* A policy framework for the email package, with a provisional (see
PEP 411) policy that adds much improved unicode support for email
header parsing
* A "collections.ChainMap" class for linking mappings to a single unit
* Wrappers for many more POSIX functions in the "os" and "signal"
modules, as well as other useful functions such as "sendfile()"
* Hash randomization, introduced in earlier bugfix releases, is now
switched on by default
In total, almost 500 API items are new or improved in Python 3.3.
For a more extensive list of changes in 3.3.0, see
http://docs.python.org/3.3/whatsnew/3.3.html
To download Python 3.3.0 visit:
http://www.python.org/download/releases/3.3.0/
Please consider trying Python 3.3.0 with your code and reporting any bugs
you may notice to:
http://bugs.python.org/
Enjoy!
--
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.3's contributors)
___
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
