Re: [Python-Dev] Python as a Metro-style App
Am 07.01.2012 18:57, schrieb Martin v. Löwis: I just tried porting Python as a Metro (Windows 8) App, and failed. Metro Apps use a variant of the Windows API called WinRT that still allows to write native applications in C++, but restricts various APIs to a subset of the full Win32 functionality. For example, everything related to subprocess creation would not work; none of the byte-oriented file API seems to be present, and a number of file operation functions are absent as well (such as MoveFile). Just wondering, do Metro apps define UNDER_CE or _WIN32_WCE? The point is that the old ANSI functions (CreateFileA etc) have been removed from the embedded MS Windows CE long ago, too, and MS Windows Mobile used to be a custom CE variant or at least strongly related. In any case, it could help using the existing (incomplete) CE port as base for Metro. Uli ** Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932 ** Visit our website at http://www.dominolaser.com ** Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden. E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht verantwortlich. ** ___ Python-Dev mailing list Python-Dev@python.org 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-Dev Digest, Vol 102, Issue 35
jbk python-dev-requ...@python.org编写： Send Python-Dev mailing list submissions to python-dev@python.org To subscribe or unsubscribe via the World Wide Web, visit http://mail.python.org/mailman/listinfo/python-dev or, via email, send a message with subject or body 'help' to python-dev-requ...@python.org You can reach the person managing the list at python-dev-ow...@python.org When replying, please edit your Subject line so it is more specific than Re: Contents of Python-Dev digest... Today's Topics: 1. Re: Status of the fix for the hash collision vulnerability (Gregory P. Smith) 2. Re: Status of the fix for the hash collision vulnerability (Barry Warsaw) 3. Re: Sphinx version for Python 2.x docs (?ric Araujo) 4. Re: Status of the fix for the hash collision vulnerability (mar...@v.loewis.de) 5. Re: Status of the fix for the hash collision vulnerability (Guido van Rossum) 6. Re: [Python-checkins] cpython: add test, which was missing from d64ac9ab4cd0 (Nick Coghlan) 7. Re: Status of the fix for the hash collision vulnerability (Terry Reedy) 8. Re: Status of the fix for the hash collision vulnerability (Jack Diederich) 9. Re: cpython: Implement PEP 380 - 'yield from' (closes#11682) (Nick Coghlan) 10. Re: Status of the fix for the hash collision vulnerability (Nick Coghlan) -- Message: 1 Date: Fri, 13 Jan 2012 19:06:00 -0800 From: Gregory P. Smith g...@krypto.org Cc: python-dev@python.org Subject: Re: [Python-Dev] Status of the fix for the hash collision vulnerability Message-ID: cage7pnkkhw-_wqiuqc9bhqxnou77f+eprs_q3nqmycstm3j...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 On Fri, Jan 13, 2012 at 5:58 PM, Gregory P. Smith g...@krypto.org wrote: On Fri, Jan 13, 2012 at 5:38 PM, Guido van Rossum gu...@python.orgwrote: On Fri, Jan 13, 2012 at 5:17 PM, Antoine Pitrou solip...@pitrou.netwrote: On Thu, 12 Jan 2012 18:57:42 -0800 Guido van Rossum gu...@python.org wrote: Hm... I started out as a big fan of the randomized hash, but thinking more about it, I actually believe that the chances of some legitimate app having 1000 collisions are way smaller than the chances that somebody's code will break due to the variable hashing. Breaking due to variable hashing is deterministic: you notice it as soon as you upgrade (and then you use PYTHONHASHSEED to disable variable hashing). That seems better than unpredictable breaking when some legitimate collision chain happens. Fair enough. But I'm now uncomfortable with turning this on for bugfix releases. I'm fine with making this the default in 3.3, just not in 3.2, 3.1 or 2.x -- it will break too much code and organizations will have to roll back the release or do extensive testing before installing a bugfix release -- exactly what we *don't* want for those. FWIW, I don't believe in the SafeDict solution -- you never know which dicts you have to change. Agreed. Of the three options Victor listed only one is good. I don't like *SafeDict*. *-1*. It puts the onerous on the coder to always get everything right with regards to data that came from outside the process never ending up hashed in a non-safe dict or set *anywhere*. Safe needs to be the default option for all hash tables. I don't like the *too many hash collisions* exception. *-1*. It provides non-deterministic application behavior for data driven applications with no way for them to predict when it'll happen or where and prepare for it. It may work in practice for many applications but is simply odd behavior. I do like *randomly seeding the hash*. *+1*. This is easy. It can easily be back ported to any Python version. It is perfectly okay to break existing users who had anything depending on ordering of internal hash tables. Their code was already broken. We *will*provide a flag and/or environment variable that can be set to turn the feature off at their own peril which they can use in their test harnesses that are stupid enough to use doctests with order dependencies. What an implementation looks like: http://pastebin.com/9ydETTag some stuff to be filled in, but this is all that is really required. add logic to allow a particular seed to be specified or forced to 0 from the command line or environment. add the logic to grab random bytes. add the autoconf glue to disable it. done. -gps This approach worked fine for Perl 9 years ago. https://rt.perl.org/rt3//Public/Bug/Display.html?id=22371 -gps -- next part -- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/python-dev/attachments/20120113/3fb82673/attachment-0001.html -- Message: 2 Date: Sat, 14 Jan 2012 04:19:38 +0100 From: Barry Warsaw ba...@python.org To:
Re: [Python-Dev] Python-Dev Digest, Vol 102, Issue 35
python wrote: jbk [snip 560+ lines of quoted text] Please delete irrelevant text when replying to digests, and replace the subject line with a meaningful subject. -- Steven ___ Python-Dev mailing list Python-Dev@python.org 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, Le 14/01/2012 15:31, Sandro Tosi a écrit : On Sat, Jan 14, 2012 at 04:24, Éric Araujo mer...@netwok.org wrote: Doc/glossary.rst:520: WARNING: unknown keyword: nonlocal That’s a mistake I did in cefe4f38fa0e. This sentence should be removed. Do you mean revert this whole hunk: [...] or just The :keyword:`nonlocal` allows writing to outer scopes.? My proposal was to remove just that one last sentence, but the only other change in the diff hunk is the addition of “by default”, which is connected to the existence of nonlocal. Both changes, i.e. the whole hunk, should be reverted (I think I’ll have time to do that today). Doc/library/stdtypes.rst:2372: WARNING: more than one target found for cross-reference u'next': Need to use :meth:`.next` to let Sphinx find the right target (more info on request :) it seems what it needed to was :meth:`next` (without the dot). The current page links all 'next' in file.next() to functions.html#next, and using :meth:`next` does that. I should have given more info, as I wanted the opposite result :) file.next should not link to the next function but to the file.next method. Because Sphinx does not differentiate between meth/func/class/mod roles, :meth:`next` is not resolved to the nearest next method as one could expect but to the next function, so we have to use :meth:`~SomeClass.next` or :meth:`.next` (local ref markup) to get our links to methods. Doc/reference/datamodel.rst:1942: WARNING: unknown keyword: not in Doc/reference/expressions.rst:1184: WARNING: unknown keyword: is not Georg fixed them. Cheers ___ Python-Dev mailing list Python-Dev@python.org 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: Bring the Python 3.3 feature list up to date.
Is the change to the pyc format big enough news to go into the release PEP? Or should that just be a What's New topic? On Fri, Jan 13, 2012 at 15:18, georg.brandl python-check...@python.orgwrote: http://hg.python.org/peps/rev/ea3ffa3611e5 changeset: 4012:ea3ffa3611e5 user:Georg Brandl ge...@python.org date:Fri Jan 13 21:18:11 2012 +0100 summary: Bring the Python 3.3 feature list up to date. files: pep-0398.txt | 17 - 1 files changed, 12 insertions(+), 5 deletions(-) diff --git a/pep-0398.txt b/pep-0398.txt --- a/pep-0398.txt +++ b/pep-0398.txt @@ -57,27 +57,34 @@ Features for 3.3 +Implemented PEPs: + +* PEP 380: Syntax for Delegating to a Subgenerator +* PEP 393: Flexible String Representation +* PEP 3151: Reworking the OS and IO exception hierarchy +* PEP 3155: Qualified name for classes and functions + +Other final large-scale changes: + +* Addition of the packaging module, deprecating distutils +* Addition of the faulthandler module + Candidate PEPs: * PEP 362: Function Signature Object -* PEP 380: Syntax for Delegating to a Subgenerator * PEP 382: Namespace Packages -* PEP 393: Flexible String Representation * PEP 395: Module Aliasing * PEP 397: Python launcher for Windows * PEP 3143: Standard daemon process library -* PEP 3151: Reworking the OS and IO exception hierarchy (Note that these are not accepted yet and even if they are, they might not be finished in time for Python 3.3.) Other planned large-scale changes: -* Addition of the packaging module, replacing distutils * Implementing ``__import__`` using importlib * Email version 6 * A standard event-loop interface (PEP by Jim Fulton pending) -* Adding the faulthandler module. * Breaking out standard library and docs in separate repos? * A PEP on supplementing C modules with equivalent Python modules? -- Repository URL: http://hg.python.org/peps ___ Python-checkins mailing list python-check...@python.org http://mail.python.org/mailman/listinfo/python-checkins ___ Python-Dev mailing list Python-Dev@python.org 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: Bring the Python 3.3 feature list up to date.
On Mon, 16 Jan 2012 11:17:42 -0500 Brett Cannon br...@python.org wrote: Is the change to the pyc format big enough news to go into the release PEP? Or should that just be a What's New topic? What's New sounds enough to me. The change doesn't enable any new feature, it just makes an issue much less likely to pop out. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Script(s) for building Python on Windows
The current scripts for building Python lack some things to be desired. The first thing I notice when I try to build Python on Windows is the scripts expect to be run inside of a Visual Studio environment, the environment of which is only defined inside of a cmd.exe context. This means the scripts can't be executed from within Powershell (my preferred shell on Windows). One must first shell out to cmd.exe, which disables any Powershell-specific features the developer might have installed (aliases, functions, etc). The second thing I notice is the scripts assume Visual Studio 2008. And while I recognize that Python is specifically built against Visual Studio 2008 for the official releases and that Visual Studio 2008 may be the only officially-supported build environment, later releases, such as Visual Studio 2010 are also adequate for testing purposes. I've been developing Python against Visual Studio 2010 for quite a while and it seems to be more than adequate. And while it's not the responsibility of the scripts to accommodate such environments, if the scripts could allow for such environments, that would be nice. Furthermore, having scripts that codify the process to upgrade will facilitate the migration should someone make the decision to officially upgrade to Visual Studio 2010. The third thing that I notice is that the command-line argument handling by the batch scripts is clumsy (compared to argparse, for example). This clumsiness is not a criticism of the authors, who have done well with the tools they had. However, batch programming is probably one of the least powerful ways to automate builds these days. So to ease my experience, I've developed my own library of functions and commands to facilitate building Python that aren't subject to the above limitations. Of course, I built these in Python, so they do require Python to build Python (not a huge burden, but worth mentioning). All of these modules are open-source and part of the jaraco.develop package http://pypi.python.org/pypi/jaraco.develop . The first of these modules is jaraco.develop.vstudio https://bitbucket.org/jaraco/jaraco.develop/src/b7263c9d9c93/jaraco/develop /vstudio.py . It exposes a class for locating Visual Studio in the usual locations, loading the environment for that instance of Visual Studio, and upgrading a project or solution file to that version. This class in particular enables running Visual Studio commands (including msbuild) from within a Visual Studio environment without actually requiring a cmd.exe context with that environment. Another module is jaraco.develop.python https://bitbucket.org/jaraco/jaraco.develop/src/b7263c9d9c93/jaraco/develop /python.py , which includes build_python, a function (and command) to build Python using whatever version of Visual Studio can be found (9 or 10 required). It has no environmental requirements except that Visual Studio be installed. Simply run build-python (part of jaraco.develop's console scripts) and it will build PCbuild.sln from the current directory to whatever targets are specified (or all of them if none are specified). The builder currently makes some assumptions (such as always building the 64-bit Release targets), but those could easily be customized using argparse parameters. This package and these modules have been tested and run on Python 2.7+. These tools solve the three shortcomings I mentioned above and make the development process so much smoother, IMO. If these modules were built into the repository, building Python could be as simple as hg clone; cd cpython/pcbuild; ./build.py (assuming only Visual Studio and Python available). I'd like to propose migrating this functionality (mainly these two modules) into the CPython heads for Python 2.7, 3.1, 3.2, and default as PCbuild/build.py (or similar). This functionality doesn't necessarily need to supersede the existing scripts (env, build_env, build), though it certainly could (and would as far as my usage is concerned). If there are no objections, I'll work to extract the aforementioned functionality from the jaraco.develop modules and into a portable script and put together a proof-of-concept in the default branch. The build script should not interfere with any build bots or other existing build processes, but should enable another more powerful technique for producing builds. I look forward to your comments and feedback. Regards, Jason smime.p7s Description: S/MIME cryptographic signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of the fix for the hash collision vulnerability
On Sun, Jan 15, 2012 at 9:44 AM, Guido van Rossum gu...@python.org wrote: On Sun, Jan 15, 2012 at 8:46 AM, Stefan Behnel stefan...@behnel.dewrote: Guido van Rossum, 15.01.2012 17:10: On Sun, Jan 15, 2012 at 6:30 AM, Stefan Behnel wrote: Terry Reedy, 14.01.2012 06:43: On 1/13/2012 8:58 PM, Gregory P. Smith wrote: It is perfectly okay to break existing users who had anything depending on ordering of internal hash tables. Their code was already broken. Given that the doc says Return the hash value of the object, I do not think we should be so hard-nosed. The above clearly implies that there is such a thing as *the* Python hash value for an object. And indeed, that has been true across many versions. If we had written Return a hash value for the object, which can vary from run to run, the case would be different. Just a side note, but I don't think hash() is the right place to document this. You mean we shouldn't document that the hash() of a string will vary per run? No, I mean that the hash() builtin function is not the right place to document the behaviour of a string hash. That should go into the string object documentation. Although, arguably, it may be worth mentioning in the docs of hash() that, in general, hash values of builtin types are bound to the lifetime of the interpreter instance (or entire runtime?) and may change after restarts. I think that's a reasonable restriction to document that prominently, even if it will only apply to str for the time being. Actually it will apply to a lot more than str, because the hash of (immutable) compound objects is often derived from the hash of the constituents, e.g. hash of a tuple. Hashing is a protocol in Python, just like indexing or iteration. Nothing keeps an object from changing its hash value due to modification, Eh? There's a huge body of cultural awareness that only immutable objects should define a hash, implying that the hash remains constant during the object's lifetime. and that would even be valid in the face of the usual dict lookup invariants if changes are only applied while the object is not referenced by any dict. And how would you know it isn't? Well, if it's an object with a mutable hash then it's up to the application defining that object to make sure it's used in a sensible way. Immutability just makes your life easier. I can imagine that an object gets removed from a dict (say, a cache), modified and then reinserted, and I think it's valid to allow the modification to have an impact on the hash in this case, in order to accommodate for any changes to equality comparisons due to the modification. That could be considered valid only in a very abstract, theoretical, non-constructive way, since there is no protocol to detect removal from a dict (and you cannot assume an object is used in only one dict at a time). That being said, it seems that the Python docs actually consider constant hashes a requirement rather than a virtue. http://docs.python.org/glossary.html#term-hashable An object is hashable if it has a hash value which never changes during its lifetime (it needs a __hash__() method), and can be compared to other objects (it needs an __eq__() or __cmp__() method). Hashable objects which compare equal must have the same hash value. It also seems to me that the wording has a hash value which never changes during its lifetime makes it pretty clear that the lifetime of the hash value is not guaranteed to supersede the lifetime of the object (although that's a rather muddy definition - memory lifetime? or pickle-unpickle as well?). Across pickle-unpickle it's not considered the same object. Pickling at best preserves values. Updating the docs to explicitly clarify this sounds like a good idea. How does this wording to be added to the glossary.rst hashing section sound? Hash values may not be stable across Python processes and must not be used for storage or otherwise communicated outside of a single Python session. -gps ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Script(s) for building Python on Windows
On Mon, Jan 16, 2012 at 14:00, Jason R. Coombs jar...@jaraco.com wrote: The second thing I notice is the scripts assume Visual Studio 2008. And while I recognize that Python is specifically built against Visual Studio 2008 for the official releases and that Visual Studio 2008 may be the only officially-supported build environment, later releases, such as Visual Studio 2010 are also adequate for testing purposes. I’ve been developing Python against Visual Studio 2010 for quite a while and it seems to be more than adequate. And while it’s not the responsibility of the scripts to accommodate such environments, if the scripts could allow for such environments, that would be nice. 2010 is adequate for limited use but the test suite doesn't pass, so I would be hesitant to add support and/or documentation for building with it until we actually support it the same as or in place of 2008. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Script(s) for building Python on Windows
From: Brian Curtin [mailto:br...@python.org] Sent: Monday, 16 January, 2012 15:20 2010 is adequate for limited use but the test suite doesn't pass, so I would be hesitant to add support and/or documentation for building with it until we actually support it the same as or in place of 2008. Good point. The current tools don't automatically support 2010; an extra command is require to perform the conversion. I'll be cautious and not expose that functionality without some indication to the user of the limitations. smime.p7s Description: S/MIME cryptographic signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Script(s) for building Python on Windows
If there are no objections, I’ll work to extract the aforementioned functionality from the jaraco.develop modules and into a portable script and put together a proof-of-concept in the default branch. The build script should not interfere with any build bots or other existing build processes, but should enable another more powerful technique for producing builds. I'd be hesitant to put too many specialized tools into the tree that will become unmaintained. Please take a look at the vs9to8 tool in PCbuild; if you could adjust that to support VS 10, it would be better IMO. As for completely automating the build: please take notice of Tools/buildbot/build.bat. It also fully automates the build, also doesn't require that the VS environment is already activated, and has the additional advantage of not requiring Python to be installed. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of the fix for the hash collision vulnerability
As I understand it, the way the attack works is that a *single* malicious request from the attacker can DoS the server by eating CPU resources while evaluating a massive collision chain induced in a dict by attacker supplied data. Explicitly truncating the collision chain boots them out almost immediately (likely with a 500 response for an internal server error), so they no longer affect other events, threads and processes on the same machine. This is only true in the specific attack presented at 28c3. If an attacker can insert data without triggering the attack, it's possible to produce (in the example of a web application) urls that (regardless of the request) always produce pathological behavior. For example, a collection of pathological usernames might make it impossible to list users (and so choose which ones to delete) without resorting to removing the problem data at an SQL level. This is why the simply throw an error solution isn't a complete fix. Making portions of an interface unusable for regular users is clearly a bad thing, and is clearly applicable to other types of poisoned data as well. We need to detect collisions and work around them transparently. However, such an app would have been crippled by the original DoS anyway, since its performance would have been gutted - the collision chain limiting just means it will trigger exceptions for the cases that would been insanely slow. We can do better than saying it would have been broken before, it's broken differently now. The universal hash function idea has merit, and for practical purposes hash randomization would fix this too (since colliding data is only likely to collide within a single process, persistent poisoning is far less feasible). -Paul ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of the fix for the hash collision vulnerability
On 17 January 2012 09:23, Paul McMillan p...@mcmillan.ws wrote: This is why the simply throw an error solution isn't a complete fix. Making portions of an interface unusable for regular users is clearly a bad thing, and is clearly applicable to other types of poisoned data as well. We need to detect collisions and work around them transparently. What if in a pathological collision (e.g. 1000 collisions), we increased the size of a dict by a small but random amount? Should be transparent, have neglible speed penalty, maximal reuse of existing code, and should be very difficult to attack since the dictionary would change size in a (near) non-deterministic manner when being attacked (i.e. first attack causes non-deterministic remap, next attack should fail). It should also have near-zero effect on existing tests and frameworks since we would only get the non-deterministic behaviour in pathological cases, which we would presumably need new tests for. Thoughts? Tim Delaney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of the fix for the hash collision vulnerability
On 17 January 2012 10:14, Tim Delaney timothy.c.dela...@gmail.com wrote: On 17 January 2012 09:23, Paul McMillan p...@mcmillan.ws wrote: This is why the simply throw an error solution isn't a complete fix. Making portions of an interface unusable for regular users is clearly a bad thing, and is clearly applicable to other types of poisoned data as well. We need to detect collisions and work around them transparently. What if in a pathological collision (e.g. 1000 collisions), we increased the size of a dict by a small but random amount? Should be transparent, have neglible speed penalty, maximal reuse of existing code, and should be very difficult to attack since the dictionary would change size in a (near) non-deterministic manner when being attacked (i.e. first attack causes non-deterministic remap, next attack should fail). It should also have near-zero effect on existing tests and frameworks since we would only get the non-deterministic behaviour in pathological cases, which we would presumably need new tests for. Thoughts? And one thought I had immediately after hitting send is that there could be an attack of the form build a huge dict, then hit it with something that causes it to rehash due to 1000 collisions. But that's not really going to be any worse than just building a huge dict and hitting a resize anyway. Tim Delaney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Script(s) for building Python on Windows
From: Martin v. Löwis [mailto:mar...@v.loewis.de] Sent: Monday, 16 January, 2012 16:25 I'd be hesitant to put too many specialized tools into the tree that will become unmaintained. Please take a look at the vs9to8 tool in PCbuild; if you could adjust that to support VS 10, it would be better IMO. Are you suggesting creating vs10to9, which would be congruent to vs9to8, or vs9to10? I'm unsure if the conversion from 9 to 10 or 10 to 9 can be as simple as the vs9to8 suggests. When I run the upgrade using the Visual Studio tools, it does upgrade the .sln file [as so]( http://a.libpa.st/kB19G). But as you can see, it also converts all of the .vcproj to .vcxproj, which appears to be a very different schema. According to [this article]( http://social.msdn.microsoft.com/Forums/en/vsprereleaseannouncements/thread/ 4345a151-d288-48d6-b7c7-a7c598d0f85e) it should be trivial to downgrade by only updating the .sln file (perhaps Visual Studio 2008 is forward compatible with the .vcxproj format). I'll look into this more when I have a better idea what you had in mind. My goal in adding the upgrade code was to provide a one-step upgrade for developers with only VS 10 installed. That's what vs-upgrade in jaraco.develop does. As for completely automating the build: please take notice of Tools/buildbot/build.bat. It also fully automates the build, also doesn't require that the VS environment is already activated, and has the additional advantage of not requiring Python to be installed. That's interesting, but it still suffers from several shortcomings: 1) It still assumes Visual Studio 2008 and fails with an obscure error otherwise. 2) You can't use it to build different targets (only the whole solution). 3) It automatically downloads the external dependencies (it'd be nice to build without them on occasion). 4) It's still a batch file, so still gives the abominable Terminate batch job (Y/N)? when cancelling any operation via Ctrl+C. 5) This functionality isn't in PCBuild/*. Why not? 6) There's no good way to select which type to build (64-bit versus 32-bit, release versus debug). Adding these command-line options is clumsy in batch files. 7) Since it's written in batch script, Python programmers might be hesitant to work with it (improve it). For a buildbot, the batch file is perfectly adequate. It should do the same thing every time reliably. For anyone but a robot or seasoned CPython Windows developer, however, the build tools are not intuitive, and I find that I'm constantly tweaking the batch scripts and asking myself, why couldn't this be in Python, which is a much more powerful language? This is why I developed the scripts, and my thought is they could be useful to others as well. My hope is they might even supersede the existing scripts and become canonical, in which case there would be no possibility of them becoming unmaintained. If it turns out that they do become unused and unmaintained, they can be removed, but my feeling is since they're concise, documented, Python scripts, they'd be more likely to be maintained than their '.bat' counterparts. smime.p7s Description: S/MIME cryptographic signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Script(s) for building Python on Windows
On Mon, Jan 16, 2012 at 18:01, Jason R. Coombs My goal in adding the upgrade code was to provide a one-step upgrade for developers with only VS 10 installed. That's what vs-upgrade in jaraco.develop does. Upgrading to 2010 requires some code changes in addition to the conversion, so the process might not be as ripe for automation as the previous versions. For one, a lot of constants in errno had to be updated, then a few places that set certain errnos had to be updated. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of the fix for the hash collision vulnerability
2012/1/17 Tim Delaney timothy.c.dela...@gmail.com: What if in a pathological collision (e.g. 1000 collisions), we increased the size of a dict by a small but random amount? It doesn't change anything, you will still get collisions. Victor ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of the fix for the hash collision vulnerability
On Mon, Jan 16, 2012 at 4:16 PM, Victor Stinner victor.stin...@haypocalc.com wrote: 2012/1/17 Tim Delaney timothy.c.dela...@gmail.com: What if in a pathological collision (e.g. 1000 collisions), we increased the size of a dict by a small but random amount? It doesn't change anything, you will still get collisions. That depends right? If the collision is because they all have the same hash(), yes. It might be different if it is because the secondary hashing (or whatever it's called :-) causes collisions. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Script(s) for building Python on Windows
From: python-dev-bounces+jaraco=jaraco@python.org [mailto:python- dev-bounces+jaraco=jaraco@python.org] On Behalf Of Jason R. Coombs Sent: Monday, 16 January, 2012 19:01 I'm unsure if the conversion from 9 to 10 or 10 to 9 can be as simple as the vs9to8 suggests. When I run the upgrade using the Visual Studio tools, it does upgrade the .sln file [as so]( http://a.libpa.st/kB19G). But as you can see, it also converts all of the .vcproj to .vcxproj, which appears to be a very different schema. According to [this article]( http://social.msdn.microsoft.com/Forums/en/vsprereleaseannouncements/thre ad/ 4345a151-d288-48d6-b7c7-a7c598d0f85e) it should be trivial to downgrade by only updating the .sln file (perhaps Visual Studio 2008 is forward compatible with the .vcxproj format). I upgraded the solution file using Visual Studio, then followed those instructions suggested by the article, but the solution no longer builds under Visual Studio 2008, so apparently that answer is incorrect. Perhaps it's possible to upgrade the .sln in a less aggressive way than the Visual Studio tools do by default, but my initial experience suggests it won't be as easy to upgrade/downgrade the solution file as it was between VS8/VS9. smime.p7s Description: S/MIME cryptographic signature ___ Python-Dev mailing list Python-Dev@python.org 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: Bring the Python 3.3 feature list up to date.
Am 16.01.2012 17:28, schrieb Antoine Pitrou: On Mon, 16 Jan 2012 11:17:42 -0500 Brett Cannon br...@python.org wrote: Is the change to the pyc format big enough news to go into the release PEP? Or should that just be a What's New topic? What's New sounds enough to me. The change doesn't enable any new feature, it just makes an issue much less likely to pop out. Agreed. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
