Mailman 3 August 2006 - Python-Dev

Re: [Python-Dev] Error while building 2.5rc1 pythoncore_pgo on VC8
by Kristján V. Jónsson Aug. 31, 2006

Aug. 31, 2006

Hello all. I am working on updating the PCBuild8 directory in the trunk. This should fix this issue, unify platform builds for win32, x64 and I64, and provide better support for PGO builds. Hopefully when this is checked in, I can backport it to 2.5, since PCBuild8 is not an "official" platform for 2.5 Cheers, Kristjan > -----Original Message----- > From: python-dev-bounces+kristjan=ccpgames.com(a)python.org > [mailto:python-dev-bounces+kristjan=ccpgames.com@python.org] > On Behalf Of Fredrik Lundh > Sent: 31. ágúst 2006 10:55 > To: python-dev(a)python.org > Subject: Re: [Python-Dev] Error while building 2.5rc1 > pythoncore_pgo on VC8 > > Muguntharaj Subramanian wrote: > > Hi All, > > I tried building python 2.5c1 using VC8. > > > > Getting the following errors while building pythoncore_pgo: > > > > Creating library pythoncore_pgo/python25.lib and object > > pythoncore_pgo/python25.exp config.obj : error LNK2001: unresolved > > external symbol _init_types .\pythoncore_pgo/python25.dll : fatal > > error LNK1120: 1 unresolved externals > > > > I checked pythoncore_pgo.vcproj file, it alreadu contains: > > > > RelativePath="..\Modules\_typesmodule.c" > > > > Can anyone give me some clue to solve this issue. > > googling for error messages is always a good idea: > > http://thread.gmane.org/gmane.comp.python.devel/83341 > > (see the last post in that thread for what I believe is a workaround) > > </F> > > _______________________________________________ > Python-Dev mailing list > Python-Dev(a)python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/kristjan%40c cpgames.com >

1 0

Re: [Python-Dev] gcc 4.2 exposes signed integer overflows
by Nick Maclaren Aug. 30, 2006

Aug. 30, 2006

"Tim Peters" <tim.peters(a)gmail.com> wrote: > > This is a wrong time in the release process to take on chance on > discovering a flaky LONG_MIN on some box, so I want to keep the code > as much as possible like what's already there (which worked fine for > > 10 years on all known boxes) for now. No, it didn't. I reported a bug a couple of years back. A blanket rule not to use symbols is clearly wrong, but there are good reasons not to want to rely on LONG_MIN (or INT_MIN for that matter). Because of some incredibly complex issues (which I only know some of), it hasn't been consistently -(1+LONG_MAX) on twos' complement machines. There are good reasons for making it -LONG_MAX, but they aren't the ones that actually cause it to be so. There are, however, very good reasons for using BOTH tests. I.e. if I have a C system which defines LONG_MIN to be -LONG_MAX because it uses -(1+LONG_MAX) for an integer NaN indicator in some contexts, you really DON'T want to create such a value. I don't know if there are any such C systems, but there have been other languages that did. I hope that Guido wasn't saying that Python should EVER rely on signed integer overflow wrapping in twos' complement. Despite the common usage, Java and all that, it is perhaps the worst systematic architectural change to have happened in 30 years, and accounts for a good 30% of all hard bugs in many classes of program. Simple buffer overflow is fairly easy to avoid by good programming style; integer overflow causing trashing of unpredictable data isn't. Any decent programming language (like Python!) regards integer overflow as an error, and the moves to make C copy Java semantics are yet another step away from software engineering in the direction of who-gives-a-damn hacking. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: nmm1(a)cam.ac.uk Tel.: +44 1223 334761 Fax: +44 1223 334679

1 0

32-bit and 64-bit python on Solaris
by Laszlo (Laca) Peter Aug. 30, 2006

Aug. 30, 2006

Hi, I work in the team that delivers python on Solaris. Recently we've been getting requests for delivering python in 64-bit as well as in 32-bit. As you probably know, Solaris can run 64-bit and 32-bit binaries on the same system, but of course you can't mix and match shared objects with different ISAs. This seems to apply to python bytecode as well: the pyc files generated by a 64-bit build of python are incompatible with those generated by the 32-bit python. Note the caveat at http://aspn.activestate.com/ASPN/docs/ActivePython/2.3/python/lib/module-ma… I guess my first question is if there are any plans to make the bytecodes for different ISAs compatible. That would make most of our problems magically go away (; If not, then the issue we have is how to separate the 32-bit and 64-bit pyc's on the same system so that: - loading the right pyc is transparent to the user - you can't accidentally load a pyc with the wrong ISA (by setting PYTHONPATH, for example) So duplicating the libdir is not an option. The usual technique used for Solaris shared objects is placing the 64-bit objects in a 64/ subdirectory, while the 32-bit objects stay where they are. We considered various solutions. Our current proposal is this: .../some/dir/foo.py <- python source .../some/dir/foo.pyc <- 32-bit bytecode .../some/dir/foo.pyc64 <- 64-bit bytecode .../some/dir/foo.pyo <- optimised 32-bit bytecode .../some/dir/foo.pyo64 <- optimised 64-bit bytecode The 64-bit python would always look for pyc64/pyo64, so this would take care of accidentally loading the wrong ISA. PYTHONPATH could be the same for the 32-bit and the 64-bit python. Shared objects: .../some/dir/foo.so <- 32-bit shared object .../some/dir/64/foo.so <- 64-bit shared object This is kinda inconsistent, but simple enough. The 64-bit python would automatically look for shared objects in the 64/ subdir. ld.so.1 makes sure that the wrong share object is never loaded. So I'm looking for advice and wondering if it would be possible to support multiple ISAs out of the box. Would you be willing to accept patches that implement the above (or whatever solution we agree to) on Solaris? Thanks, Laca

2 2

draft for bug guidelines
by Brett Cannon Aug. 29, 2006

Aug. 29, 2006

Below is the current draft of a set of bug guidelines for people to follow when they want to file a bug. The hope is that when we get an email asking "how do I file a bug?" we can point them towards these sets of guidelines for most issues. Let me know about any errors and such. This will (hopefully) end up going up on python.org/dev/ eventually. ------------------------- About /////////////////////////////////////////////////////////// These sets of guidelines are to help you file a bug report for the Python programming language on SourceForge_. If your bug is not for the language but for a third-party application, please report the bug to that third-party. *Please make sure to follow every step as it will make the lives of the Python developers much easier!!!* .. contents:: Steps to File a Bug Report /////////////////////////////////////////////////////////// Get a SourceForge account ======================================= In order to file a bug report, you must have an account_ on SourceForge_. We realize some people would like to have anonymous bug reporting for various reasons (anonymity, ease or reporting, etc.). But the Python developers made the decision to turn off anonymous posting so as to make sure you are notified by email when any action is taken on your report. This can be very important if a Python developer needs more information from you about the bug. Start a new bug ======================================= You must be logged into SourceForge to file a bug! See `Get a SourceForge account`_ if you do not have one. Go to the `SourceForge bug page`_ to start a new bug report. There you will find a link called `Submit New`_. Click on it and it will allow you to fill out a new bug report. Once you click on the link, you are presented with a page that has several fields for you to fill in. Here is what to do for each field: * Private Leave this unchecked. * Category Set this to the area that the bug is related to (e.g., documentation, build, etc.). * Group Usually this is set to the major.minor version of Python that you found the bug in. * Summary A one-liner describing the problem so as to make it easy for developers to spot whether they have the expertise needed to work on the bug; it also ends up being displayed as the title on index and search pages. * Detailed Description Following sections of this document discuss what should go in here. * Upload and Attach a File If you are going to upload a file, either type in the path to the file or click the ``Browse...`` button to find the file. * File Description A one-liner describing the file (e.g., how it is different from previously uploaded files); no date info is needed since the upload is timestamped. Specify the Python version ======================================= It is important that we have the most accurate version number of the interpreter you are using in order to best diagnose the issue. There are two ways to get us the version information. If you can run your Python interpreter, execute the following lines at at a shell prompt and paste the result into the ``Detailed Description`` field of the bug report:: python -c "import sys; print sys.version" If you are running a version of Python older than 2.5 and are working from a source checkout of Python, the please also report the Subversion revision number for the root of your checkout:: svnversion . If your bug is preventing you from running the interpreter, execute Python with the ``-V`` command-line flag and paste the output:: python -V Special settings for your Python interpreter ============================================ Sometimes your environment influences a bug and thus needs to be reported to help find the problem. This means we need to have reported: * Operating System * Environment Variables + ``PYTHONSTARTUP`` If this is set and might be causing the issue, please either upload the file or state what it does. + ``PYTHONCASEOK`` If your bug is on Windows and involves importing, please report if this environment variable is set or not. * ``site-packages`` If you have any third-party packages installed that may be contributing to the bug, please report those. * Custom Patches Any differences between your code and the code the Python developers work off of needs to be reported. Sample code to reproduce bug ======================================== If you can, please upload a file the demonstrates the bug. The more succinct the better! Submit! ======================================== At this point you should have a detailed bug report for developers to work off of. Click the ``Submit`` button and read on to see what you should do after the bug is reported. Respond to requests from developers ======================================== No matter how detailed the bug report, there is always the chance that a developer will need more information to fix a bug. Please be prompt in replying to requests for information by submitting a reply on the bug report. You may be asked to test out a patch. It is very important that you help with this, especially if the bug is not reproducible by the developer working on it. Write a patch! ======================================== If you are so inclined, patches for your own bug reports are always helpful! Please make sure to reference the tracker item number in the patch details. Also add a follow-up to the bug referencing the patch. .. _SourceForge: http://www.sourceforge.net/ .. _SourceForge bug page: http://sourceforge.net/tracker/?group_id=5470&atid=105470 .. _account: http://sourceforge.net/account/newuser_emailverify.php .. _Submit New: http://sourceforge.net/tracker/?func=add&group_id=5470&atid=105470

3 4

Adding an rslice() builtin?
by Nick Coghlan Aug. 29, 2006

Aug. 29, 2006

A discussion on the py3k list reminded me that translating a forward slice into a reversed slice is significantly less than obvious to many people. Not only do you have to negate the step value and swap the start and stop values, but you also need to subtract one from each of the step values, and ensure the new start value was actually in the original slice: reversed(seq[start:stop:step]) becomes seq[(stop-1)%abs(step):start-1:-step] An rslice builtin would make the latter version significantly easier to read: seq[rslice(start, stop, step)] Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org

7 6

Doc suggestion for Elementtree (for 2.5? a bit late, I know...)
by Paul Moore Aug. 29, 2006

Aug. 29, 2006

One little addition to the elementtree docs. In the overview section, adding a paragraph explaining best practice for importing the module might be useful. Some suggested text, for the "overview" section: """ The ElementTree module comes in two forms - a pure-python version (xml.etree.ElementTree) and a C-coded implementation (xml.etree.cElementTree) which is faster. To import the faster code if possible, but fall back to the Python implementation, you can use try: from xml.etree import cElementTree as ET except ImportError: from xml.etree import ElementTree as ET ElementTree is also available as an external module for older Python versions. For portability to these versions, this pattern can be extended to try: from xml.etree import cElementTree as ET except ImportError: try: from xml.etree import ElementTree as ET except ImportError: try: import cElementTree as ET except ImportError: import ElementTree as ET """ I'd put a patch on SF, but guess what? It's down again :-( Paul. PS This actually begs the question - are there platforms where xml.etree.cElementTree is not available? If not, is there a need for both versions? If there are, the wording above should probably be modified to reflect this.

5 7

distutils patch
by Russell E. Owen Aug. 29, 2006

Aug. 29, 2006

A colleague stumbled across distutils bug/misfeature that he found had been reported with an associated patch: <http://sourceforge.net/tracker/index.php?func=detail&aid=1183712&group_i d=5470&atid=305470> and I'm wondering if there's any plans to accept the patch or implement some other fix (such as raising an exception if one tries to use a blank package name). The current behavior is clearly unexpected and confusing. If there's something I can do to help get a fix of some kind into python 2.5, I'm happy to do it. Regards, -- Russell

2 1

draft of patch guidelines
by Brett Cannon Aug. 28, 2006

Aug. 28, 2006

Below is a draft for a set of patch guidelines. This is meant for that times where people ask "how do a create a patch for a change I made" or where to point people if they created a patch but it comes up short (no tests, etc.). Hopefully this will go up on python.org/dev/ . Let me know of any errors and such. -------------------------- About ///// This set of guidelines is meant for people who have written code that they wish to have committed to the Python programming language. This means that this set of guidelines assumes you have already written code and thus just want to know the steps required to generate the patch necessary to submit your change for addition in Python. The assumption you are using a UNIX-style shell is also made. If you need help with any of these steps, please ask for it! Usually you can create a new patch missing a few steps and the Python developers will try to help you complete it so that your patch can eventuallly be accepted. Guidelines for committing code to Python will be contained in a separate document. .. contents:: Steps to Creating a Patch ///////////////////////// Read the Developer Intro to understand the scope of your proposed change ======================================================================== Changes to Python come in various levels of scope. You could be fixing a simple bug in the standard library. You might be trying to add a new feature to a module. You might even be suggesting a new feature to the language. All three have a different amount of scope and thus require varying amounts of work to get approval. Please read the `Developer Intro`_ doc to make sure you realize the proper scope of what you are doing. It also tells you the rough steps needed for varying types of changes to be accepted. Add the appropriate unit tests ============================== Python prides itself on being a very stable piece of software. We maintain this by having a regression test suite that contains a huge amount of unit tests that exercise both the language and the standard library. Any change you make to Python requires a unit test. If your patch is to fix a bug, then a test exercising that bug and your fix is needed. If it is a new feature then an entirely new regression test might be needed. The important thing is that your new code is exercised within Python's test suite. Add the proper document changes =============================== If your patch will change or add new semantics, you must update the documentation. If your code clarifies some ambiguous behaviour, you must update the docs. The only time you do not need to touch the documentation is if your patch fixes a bug or adds new unit tests. Make your code follow the style guidelines ========================================== `PEP 7`_ and `PEP 8`_ are the style guidelines for C and Python code, respectively. Your code must conform to the style guidelines before it is accepted. Generate a patch ================ In general, people get their copy of the Python source from two locations: a svn checkout or from downloaded source. Both have slightly different steps in terms of generating patches. Working from a svn checkout is the best way to create a patch. It makes it easier on the Python developers since there is less chance of any merge problems. It also raises the chances that a developer will be willing to put the time and effort into working with you and your patch. If you need help with working with svn and Python's repository, see the `Developer FAQ`_. Working from downloaded source is so inferior to working with a svn checkout that it will not be discussed here (although patches *will* be accepted against downloaded code). First step is to update your svn checkout with ``svn update``. Once you have done that and resolved the merge conflicts, generate a patch containing the files you have changed. You can see what files you have touched with ``svn status``. If it lists only modified files you want to include in your patch, you can then generate your patch:: svn diff > PATCH_FILE Make sure to name ``PATCH_FILE`` to a reasonable name and be prepared to upload it in a later step. Also, please note what revision number you are working against. This can be found by executing:: python -c "import sys; print sys.version" Create a tracker item on SourceForge ==================================== First make sure you have a `SourceForge account`_. Once you have one and havve logged in, go to the `SF patch tracker`_ for Python and create a new tracker item. In the new tracker item, set the item's fields as so: * Private Leave unchecked. * Category Set to what area of Python your patch affects. * Group Set to the version of Python that the patch was generated against. * Assigned To Leave as-is. * Priority: Leave as-is. * Summary Briefly describe what the patch does. * Detailed Description Describe in more detail what the patch does. Make sure to mention the revision number the patch is against here. Also mention any bugs that the patch fixes. * Upload and Attach a File Point to the patch you generated. * File Description Mention it is the initial version of the patch. If you end up uploading newer versions of your patch you then specify how it is different from the previous one. Reference the patch in proper bug reports ========================================= If your patch fixes a bug, add a follow-up to that bug report referencing the patch. If there is not bug report but your patch does fix a bug, then quickly create a bug report. Wait for a developer to contact you =================================== At this point you need to wait for a Python developer to come along and look at your patch. This might be a while as all Python developers are volunteers and thus have a limited amount of time. Do not be surprised if it takes weeks or more before your patch is examined. There is a standing offer that if you review five other patches (by commenting on its correctness, helping it meet these guidelines, etc.), then a developer will definitely have a look at any patch you specify. Just email python-dev with what five patches you reviewed (and what you did for the review) and the patch you want examined. .. _Developer Intro: http://www.python.org/dev/intro/ .. _PEP 7: http://www.python.org/dev/peps/pep-0007/ .. _PEP 8: http://www.python.org/dev/peps/pep-0008/ .. _Developer FAQ: http://www.python.org/dev/faq .. _SourceForge account: http://sourceforge.net/account/newuser_emailverify.php .. _SF patch tracker: http://sourceforge.net/tracker/?group_id=5470&atid=305470

3 7

Re: [Python-Dev] gcc 4.2 exposes signed integer overflows
by howarth＠bromo.msbb.uc.edu Aug. 28, 2006

Aug. 28, 2006

I believe some of the others here might be interested in some other postings on the gcc mailing list regarding this issue (which weren't cross-posted here)... http://gcc.gnu.org/ml/gcc/2006-08/msg00516.html http://gcc.gnu.org/ml/gcc/2006-08/msg00517.html It makes clear that the impact of this change in gcc was considered and the reasoning on their decision to follow the standard so closely. http://gcc.gnu.org/ml/gcc/2005-06/msg01238.html Just so other beside Guido see those. Jack

2 1

Re: [Python-Dev] draft of patch guidelines
by Chad Whitacre Aug. 27, 2006

Aug. 27, 2006

Brett, >> I liked the "patch angel" term in Chad's version. Stating "a Python >> developer will take a look at your patch" smacks of a guarantee, >> while Chad's use of "patch angel" and "get the ball rolling" better >> conveyed the fact that this 5-for-1 rule is simply a practice of some >> of the volunteers. > > Eh, I still don't like the term. Too hokey. But I did toss in a > "try" to not make it sound like a guarantee. Yeah, kind of hokey. I included it because it's succinct and accurate, and because I assumed there's history to the term. Putting it in quotes helped w/ the goofiness, I thought. I believe Skip used the term: any comment, Skip? chad

1 0