Re: [Python-Dev] Mercurial?
On Mon, Apr 6, 2009 at 00:48, Mark Hammond skippy.hamm...@gmail.com wrote: Just to be clear, what input would you like on that map? Review of email addresses, pointers to names/email addresses for the usernames I don't have anything for yet. Also, there's a few commented question marks, it would be useful if someone checked those. I'm listed twice: mark.hammond = Mark Hammond skippy.hamm...@gmail.com mhammond = Mark Hammond skippy.hamm...@gmail.com but that email address isn't the address normally associated with any checkins I make, nor the address in the comments of the ssh keys I use (which is mhamm...@skippinet.com.au) Your being listed twice is normal; both mark.hammond and mhammond have been used in the commit history, and I just assumed they're both you. I'll probably change your email address to be the one associated with the checkins/public key, though. Is there a list of such email addresses? I just parsed python-dev archives to get to my list. Cheers, Dirkjan ___ 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] Mercurial?
On Mon, Apr 6, 2009 at 04:27, s...@pobox.com wrote: Maybe once for each currently active Subversion branch (2.6, 2.7, 3.0, 3.1)? Sure, if we're doing cloned branches. But then someone will also need to clone 2.5, and maybe 2.4. The point is, as long as it's a constant factor and not an order of magnitude more, it's still quite easy to cope with. This would also be one of the arguments *for* named branches, I suppose. Cheers, Dirkjan ___ 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] Mercurial?
On Mon, Apr 6, 2009 at 06:20, Alexandre Vassalotti alexan...@peadrop.com wrote: But that won't work if people who are not core developers submit us patch bundle to import. And maintaining a such white-list sounds to me more burdensome than necessary. Well, if you need contributors to sign a contributor's agreement anyway, there's already some list out there that we can leverage. The other option is to play the consenting adults card and ask all people with push access to ascertain the correct names of committer names on patches they push. Cheers, Dirkjan ___ 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] Mercurial?
Alexandre Vassalotti alexandre at peadrop.com writes: If I recall correctly, only ssh clients can request compression to the server—in other words, the server cannot forces the clients to use compression, but merely allow them use it. See the man page for sshd_config and ssh_config for the specific details. So we'll explain how to configure that in the .hgrc/Mercurial.ini file that people will have to create anyway. Alternatively, we do it the way Mozilla has done and let everyone clone/pull over http and push over ssh. Then everyone always gets compression for the big clones/pulls, pushes are a little slower (but they aren't usually that large), and people who don't have push access already have the right setup. Cheers, Dirkjan ___ 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] Mercurial?
Martin v. Löwis martin at v.loewis.de writes: Is it possible to branch from a subdirectory? For the different VMs stuff, it's rather desirable to have a branch of the test suite, and the perhaps the standard library, than extracting it from the source. You can only branch the whole repository. Of course you could drop the other stuff right after branching it, but that would kind of defy the point of branching (since you won't really be able to merge later on). This is why it might be interesting to just split out the stdlib entirely. Though maybe we should wait for Mercurial's subrepos support to arrive before we go there (so we can a CPython repo that has the stdlib repo included automatically). Something like that is already provided by the forest extension, but it's not being maintained. Subrepo support is slated for the 1.3 release, which is planned for early July. Cheers, Dirkjan ___ 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] Mercurial?
Alexandre Vassalotti alexandre at peadrop.com writes: With Mercurial, we will need to add support for server-side clone ourselves. There's few ways to provide this feature. We give Unix user accounts to all core developers and let developers manages their private branches directly on the server. You made clear that this is not wanted. So an alternative approach is to add a interface accessible via SSH. As I previously mentioned, this is the approach used by Mozilla. The easier solution here is to just allow normal local-to-remote clones. hg supports commands like hg clone . ssh://h...@hg.python.org/my-branch without the need for any extra scripts or setup. I think that would be a good start. This makes me remember that we will have to decide how we will reorganize our workflow. For this, we can either be conservative and keep the current CVS-style development workflow—i.e., a few main repositories where all developers can commit to. Or we could drink the kool-aid and go with a kernel-style development workflow—i.e., each developer maintains his own branch and pull changes from each others. The differences between these workflows aren't all that big, i.e. it's not like there's a big schisma between them. But I suspect that, in a setup where buildbots are important, a very much multi-repo setup probably isn't a good idea (this is also why Mozilla doesn't use that many repos; their continuous integration infra is /very/ important to them). Cheers, Dirkjan ___ 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] CObject take 2: Introducing the Capsule
(See my posting Let's update CObject API so it is safe and regular! from 2009/03/31 for take 1). I discussed this off-list with GvR. He was primarily concerned with fixing the passing-around-a-vtable C API usage of CObject, but he wanted to preserve as much backwards compatibility as possible. In the end, he suggested I create a new API and leave CObject unchanged. I've done that, incorporating many of GvR's suggestions, though the blame for the proposed new API is ultimately mine. The new object is called a Capsule. (I *had* wanted to call it Wrapper, but there's already a PyWrapper_New in descrobject.h.) Highlights of the new API: * PyCapsule_New() replaces PyCObject_FromVoidPtr. * It takes a void * pointer, a const char *name, and a destructor. * The pointer must not be NULL. * The name may be NULL; if it is not NULL, it must be a valid C string which outlives the capsule. * The destructor takes a PyObject *, not a void *. * PyCapsule_GetPointer() replaces PyCObject_AsVoidPtr. * It takes a PyObject * and a const char *name. * The name must compare to the name inside the object; either they're both NULL or they strcmp to be the same. * PyCapsule_Import() replaces PyCObject_Import. * It takes three arguments: const char *module_name, const char *attribute_name, int no_block. * It ensures that the name of the Capsule is modulename.attributename. * If no_block is true, it uses PyModule_ImportModuleNoBlock. If this fails it sets no exception. * The PyCapsule structure is private. There are accessors for all fields: pointer, name, destructor, and context. * The context is a second void * you can set / get. You can read the full API and its implementation in the patch I just posted to the tracker: http://bugs.python.org/issue5630 The patch was written against svn r71304. The patch isn't ready to be applied--there is no documentation for the new API beyond the header file. GvR and I disagree on one point: he thinks that we should leave CObject in forever, undeprecated. I think we should deprecate it now and remove it... whenever we'd do that. The new API does everything the old one does, and more, and it's cleaner and safer. Let me start an informal poll: assuming we accept the new API, should we deprecate CObject? /larry/ ___ 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] Mercurial?
Dirkjan Ochtman wrote: On 05/04/2009 20:29, Martin v. Löwis wrote: FYI: this is the list of hooks currently employed: - pre: check whitespace - post: mail python-checkins inform regular buildbot inform community buildbot trigger website rebuild if a PEP was modified (but then, whether or not the PEPs will be maintained in hg also needs to be decided) All this is easy to do with Mercurial's hook system. One question: if somebody pushes a changeset with 3 commits, will the pre and post hooks be applied on all of the commits, or only on the final commit ? If this is applied on every commit, then you have no way to fix a whitespace problem without rewriting your history ? cheers, Philippe ___ 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] Mercurial?
On Mon, Apr 6, 2009 at 10:21, Philippe Fremy p...@freehackers.org wrote: One question: if somebody pushes a changeset with 3 commits, will the pre and post hooks be applied on all of the commits, or only on the final commit ? If this is applied on every commit, then you have no way to fix a whitespace problem without rewriting your history ? Correct, so if the latter is something we want, we could run the whitespace hook just on every changegroup (group of changesets pushed). Cheers, Dirkjan ___ 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] Mercurial?
Daniel (ajax) Diniz wrote: Martin v. Löwis wrote: I think it would be a good idea to host a temporary svn mirrors for developers who accesses their VCS via an IDE. Although, I am sure anymore if supporting these developers (if there are any) would worth the trouble. So, think of this as optional. Any decision to have or not have such a feature should be stated in the PEP. I personally don't use IDEs, so I don't care (although I do notice that the apparent absence of IDE support for Mercurial indicates maturity of the technology) I can spend some time on Mercurial integration for the main IDEs in use by core devs, I'm sure the PIDA folks have most of this sorted already. It would be important to have these (and any other non-PEP worthy tasks/helpers) listed with some detail, e.g., in a wiki page. Well PIDA is the IDE-hater's IDE, but yes, it has excellent Mercurial integration (probably the best integration of any system). It is all through anyvc with a small amount of user interface added. I am sure this would be easily portable. Ali (thanks for cc) ___ 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] Mercurial?
On Mon, Apr 6, 2009 at 11:14, Philippe Fremy p...@freehackers.org wrote: This is a problem I have with my daily usage of mercurial. It's supposed to be great to work offline and to commit your intermediate versions before it's fully working but if you do that, all those intermediate non working versions find their way into the main repository. Well, it can also be nice to have smaller commits. They're easier to review, and will provide easier history to browse/read later on. BTW, having smaller commits doesn't necessarily equate having non-working changesets. I.e. in my work on Mercurial, I'll often push small changesets (we all do), but we try to keep the test suite passing in every single one of them. This means that something like all test pass 100% or close on every version of the repository is not really feasible unless every committer agrees not to have any version in his local repository that does not break any tests. Which defeats part of the purpose of being able to have a local repository, no ? This is why you'd want something like a pushlog, to provide a way to see what revisions were actually tested by buildbots. Another thing that I discussed with Georg last night would be a setup where changesets get pushed to a gateway repo that runs the tests and only pushes to an official repo if everything's still green. That should probably be a topic discussed separately, though. Cheers, Dirkjan ___ 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] Possible py3k io wierdness
Alex Martelli wrote: Queue.Queue in 2.* (and queue.Queue in 3.*) is like that too -- the single leading underscore meaning protected (I'm here for subclasses to override me, only in C++ parlance) and a great way to denote hook methods in a Template Method design pattern instance. Base class deals with all locking issues in e.g. 'get' (the method a client calls), subclass can override _get and not worry about threading (it will be called by parent class's get with proper locks held and locks will be properly released c afterwards). Ah, thank you - yes, that's the one I was thinking of. My brain was telling me threading, which makes some sense, since I put the Queue conceptually in the same bucket as the rest of the locking constructs in the threading module. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ 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] Getting values stored inside sets
Raymond Hettinger wrote: Hrvoje Niksic wrote: I've stumbled upon an oddity using sets. It's trivial to test if a value is in the set, but it appears to be impossible to retrieve a stored value, See: http://code.activestate.com/recipes/499299/ Thanks, this is *really* good, the kind of idea that seems perfectly obvious once pointed out by someone else. :-) I'd still prefer sets to get this functionality so they can be used to implement, say, interning, but this is good enough for me. In fact, I can derive from set and add a method similar to that in the recipe. It can be a bit simpler than yours because it only needs to support operations needed by sets (__eq__ and __hash__), not arbitrary attributes. class Set(set): def find(self, item, default=None): capt = _CaptureEq(item) if capt in self: return capt.match return default class _CaptureEq(object): __slots__ = 'obj', 'match' def __init__(self, obj): self.obj = obj def __eq__(self, other): eq = (self.obj == other) if eq: self.match = other return eq def __hash__(self): return hash(self.obj) s = Set([1, 2, 3]) s.find(2.0) 2 ___ 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] Mercurial?
Dirkjan Ochtman wrote: I have a stab at an author map at http://dirkjan.ochtman.nl/author-map. Could use some review, but it seems like a good start. Martin may be able to provide a better list of names based on the checkin name-SSH public key mapping in the SVN setup. (e.g. I believe my SVN checkin name is nick.coghlan rather than the shorter ncoghlan in my email address, and many others are in a similar boat since first.last was the chosen scheme for names in the SVN switchover) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ 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] Mercurial?
Dirkjan Ochtman wrote: Another thing that I discussed with Georg last night would be a setup where changesets get pushed to a gateway repo that runs the tests and only pushes to an official repo if everything's still green. That should probably be a topic discussed separately, though. That was one of the post-switch workflow enhancements that Barry was advocating - it's still a good idea, even if Barry's preferred flavour of DVCS wasn't chosen :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ 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] Mercurial?
Nick Coghlan wrote: Dirkjan Ochtman wrote: Another thing that I discussed with Georg last night would be a setup where changesets get pushed to a gateway repo that runs the tests and only pushes to an official repo if everything's still green. That should probably be a topic discussed separately, though. That was one of the post-switch workflow enhancements that Barry was advocating - it's still a good idea, even if Barry's preferred flavour of DVCS wasn't chosen :) Gated checkins can work fine but can also have many problems. For example if we have a spuriously failing test then if you are working on an unrelated issue it will be entirely up to chance as to whether you can checkin... Building the docs would be another thing we could check, although it can take a while. If we have a queue then it could be the case that you do a commit - and then discover half an hour later that it conflicts with something that was ahead of you in the queue. Michael Cheers, Nick. -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ 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] Possible py3k io wierdness
Brian Quinlan wrote: - you need the cooperation of your subclasses i.e. they must call super().flush() in .flush() to get correct close behavior (and this represents a backwards-incompatible semantic change) Are you sure about that? Going by the current _pyio semantics that Antoine posted, it looks to me that it is already the case that subclasses need to invoke the parent flush() call correctly to avoid breaking the base class semantics (which really isn't an uncommon problem when it comes to writing correct subclasses). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ 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] Mercurial?
Alexandre Vassalotti wrote: On Mon, Apr 6, 2009 at 12:20 AM, Aahz a...@pythoncraft.com wrote: How difficult would it be to change the decision later? That is, how about starting with a CVS-style system and maybe switch to kernel-style once people get comfortable with Hg? I believe it would be fairly easy. It would be a matter of declaring a volunteer to maintain the main repositories and ask core developers to avoid committing directly to them. I think that would be the way to go then (i.e. start with a fairly centralised workflow, and then look at adjusting to something more decentralised later)*. Cheers, Nick. *I actually had an interesting off-list discussion with Steve Turnbull regarding how well the 3 most popular DVCS tools supported centralised and decentralised workflows (or rather, how their advocates evangelise them in that respect). This is relevant when pitching a DVCS to people like me that really only have experience working with a centralised repository model like CVS or SVN. My guess was that Bazaar anchored the centralised end of the DVCS scale by letting users avoid caring about the underlying acyclic graph, while Git was solidly down the decentralised end with users expected to be fully aware of and comfortable with the graph. Mercurial appeared to be somewhere in the middle, as it allowed you to avoid caring about the graph most of the time, but still provided tools to manipulate it when you needed to. That makes Bazaar easy to pitch conceptually to someone like me (you can use it just like you use SVN, only with much better merging and offline support), and Git a tough sell (umm, yeah, you really think about version control all wrong... we're going to have to fix that before Git makes much sense to you). Mercurial appears to best allow the sales pitch to be tailored to the target audience (in this case, a group including a lot of people with a background predominantly involving centralised version control tools). That's just a subjective impression formed from reading what other people have written *about* the various tools, rather than anything based on my own experience using them, so you may want to investigate the location of the nearest salt mine before taking it too seriously :) -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ 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] Mercurial?
Dirkjan Ochtman wrote: On Mon, Apr 6, 2009 at 10:21, Philippe Fremy p...@freehackers.org wrote: One question: if somebody pushes a changeset with 3 commits, will the pre and post hooks be applied on all of the commits, or only on the final commit ? If this is applied on every commit, then you have no way to fix a whitespace problem without rewriting your history ? Correct, so if the latter is something we want, we could run the whitespace hook just on every changegroup (group of changesets pushed). Probably wise, and for many other checks as well. This is a problem I have with my daily usage of mercurial. It's supposed to be great to work offline and to commit your intermediate versions before it's fully working but if you do that, all those intermediate non working versions find their way into the main repository. This means that something like all test pass 100% or close on every version of the repository is not really feasible unless every committer agrees not to have any version in his local repository that does not break any tests. Which defeats part of the purpose of being able to have a local repository, no ? cheers, Philippe ___ 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] Mercurial?
On Mon, Apr 6, 2009 at 13:55, Michael Foord fuzzy...@voidspace.org.uk wrote: Gated checkins can work fine but can also have many problems. For example if we have a spuriously failing test then if you are working on an unrelated issue it will be entirely up to chance as to whether you can checkin... Sure, it's a problem, but it does get you a tree that's always green. They're all trade-offs. But let's keep this discussion for some time *after* migration to hg is completed. Cheers, Dirkjan ___ 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] Tools
On Sun, Apr 5, 2009 at 10:58 PM, Jack diederich jackd...@gmail.com wrote: On Sun, Apr 5, 2009 at 10:50 PM, s...@pobox.com wrote: Barry Someone asked me at Pycon about stripping out Demos and Tools. Matthias +1, but please for 2.7 and 3.1 only. Is there a list of other demos or tools which should be deleted? If possible the list should be publicized so that people can pick up external maintenance if desired. I liked Brett's (Georg's?) half joking idea at sprints. Just delete each subdirectory in a separate commit and then wait to see what people revert. -Jack Jack brought up a good point - this discussion came up during the sprints, I believe Martin and others had some good arguments to keep *some* of the demo/... stuff, however I think we all agreed that it belongs somewhere else; possibly the documentation. As it is, the demo/... directory only exists in subversion - it's not installed anywhere. I really do think that most of the contents can either be deleted, or moved to the docs where it might be of more use for people in general. Random thought - what if we made a docs/demos directory, which contained sub directories ala Demo/... - and added a sphinx extension which would detect nested directories and zip them up during the build? This way, you could add a tag in the .rst for the module that looked like: .. demos:: multiprocessing.zip The zip would not be checked in, but created at build time from Docs/demos/multiprocessing Just some thoughts. Back to my coffee. -jesse ___ 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] PEP 382: Namespace Packages
Martin v. Löwis wrote: Chris Withers wrote: Martin v. Löwis wrote: I propose the following PEP for inclusion to Python 3.1. Please comment. Would this support the following case: I have a package called mortar, which defines useful stuff: from mortar import content, ... I now want to distribute large optional chunks separately, but ideally so that the following will will work: from mortar.rbd import ... from mortar.zodb import ... from mortar.wsgi import ... Does the PEP support this? That's the primary purpose of the PEP. Are you sure? Does the pep really allow for: from mortar import content from mortar.rdb import something ...where 'content' is a function defined in mortar/__init__.py and 'something' is a function defined in mortar/rdb/__init__.py *and* the following are separate distributions on PyPI: - mortar - mortar.rdb ...where 'mortar' does not contain 'mortar.rdb'. You can do this today already (see the zope package, No, they have nothing but a (functionally) empty __init__.py in the zope package. cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ 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] issue5578 - explanation
Benjamin Peterson wrote: Assuming it breaks no tests, would there be objection to me committing the above change to the Python 3 trunk? That's up to Benjamin. Personally, I live by if it ain't broke, don't fix it. :-) Anything using an exec is broken by definition ;-) practicality beats purity Benjamin? +0 OK, well, I'll use it as my first test commit when I get a chance :-) Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ 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] FWD: Documentation site problems
The 3.0 docs seem to be correct: http://docs.python.org/3.0/tutorial/ - Forwarded message from Ernst Persson er...@stickybit.se - Subject: Documentation site problems From: Ernst Persson er...@stickybit.se To: webmas...@python.org Organization: StickyBit AB Date: Mon, 06 Apr 2009 10:32:42 +0200 Hi, there contents is missing from the python tutorial: http://docs.python.org/tutorial/ BR /Ernst Persson - End forwarded message - -- Aahz (a...@pythoncraft.com) * http://www.pythoncraft.com/ ...string iteration isn't about treating strings as sequences of strings, it's about treating strings as sequences of characters. The fact that characters are also strings is the reason we have problems, but characters are strings for other good reasons. --Aahz ___ 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] FWD: Library Reference is incomplete
Hrm, looks like the whole 2.6 build is broken. - Forwarded message from M?ller-Reineke, Matthias matthias.mueller-rein...@grundvers.de - Subject: Library Reference is incomplete Date: Mon, 6 Apr 2009 11:25:54 +0200 From: M?ller-Reineke, Matthias matthias.mueller-rein...@grundvers.de To: webmas...@python.org Dear Webmaster, Library Reference on http://www.python.org/doc/ takes me to http://docs.python.org/library/ . That side doesn't contain the index of contents. Matthias M?ller-Reineke -- Grundeigent?mer-Versicherung VVaG Gro?e B?ckerstra?e 7 20095 Hamburg Tel: 040 - 3 76 63 - 199 Fax: 040 - 3 76 63 - 98 199 http://www.grundvers.de mailto:matthias.mueller-rein...@grundvers.de Firmensitz: Hamburg HRB 13 103 Vorstand: Heinz Walter Berens (Vors.), R?diger Buyten Aufsichtsratsvorsitzender: Peter Landmann - End forwarded message - -- Aahz (a...@pythoncraft.com) * http://www.pythoncraft.com/ ...string iteration isn't about treating strings as sequences of strings, it's about treating strings as sequences of characters. The fact that characters are also strings is the reason we have problems, but characters are strings for other good reasons. --Aahz ___ 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] Mercurial?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Apr 6, 2009, at 7:55 AM, Michael Foord wrote: Gated checkins can work fine but can also have many problems. For example if we have a spuriously failing test then if you are working on an unrelated issue it will be entirely up to chance as to whether you can checkin... Building the docs would be another thing we could check, although it can take a while. If we have a queue then it could be the case that you do a commit - and then discover half an hour later that it conflicts with something that was ahead of you in the queue. All very true. Where I've worked with gated branches, there are procedures for dealing with each of these issues. For a test suite like Python's which runs in a few minutes, I don't think some of the more extreme approaches are necessary (as opposed to a system where a full test run takes *hours*). On the whole though, it's a net win because you know the main tree is always good. This is especially useful around release time! But I guess it's up to Benjamin now to push for that :). Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSdn+iXEjvBPtnXfVAQIEKAP/b3RcUIxcxOpTGfk8POAj+oQXvcvIpI+H 6sN2CWss7bt9qLVlJMFCJoEH78JKnydHuGy+JmZf2rMtnfwIr0w7EFSMoT8X7tPg YflsHn3ePrBddqD9EOwXo+hQfgodSKHEyPHDPgYSMUtiR4TTqkVXD/o4ViQk4K1b YFtRkehHKfc= =F39k -END PGP 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] Mercurial?
Nick Coghlan ncogh...@gmail.com writes: My guess was that Bazaar anchored the centralised end of the DVCS scale by letting users avoid caring about the underlying acyclic graph […] That makes Bazaar easy to pitch conceptually to someone like me (you can use it just like you use SVN, only with much better merging and offline support) […] Mercurial appears to best allow the sales pitch to be tailored to the target audience (in this case, a group including a lot of people with a background predominantly involving centralised version control tools). I don't follow. Wouldn't your preceding points above instead make *Bazaar* the one best suited for a group including a lot of people with a background predominantly involving centralised version control tools? -- \ “I disapprove of what you say, but I will defend to the death | `\ your right to say it.” —Evelyn Beatrice Hall, _The Friends of | _o__) Voltaire_, 1906 | Ben Finney ___ 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] PEP 382: Namespace Packages
On Thu, Apr 2, 2009 at 4:33 PM, M.-A. Lemburg m...@egenix.com wrote: On 2009-04-02 17:32, Martin v. Löwis wrote: I propose the following PEP for inclusion to Python 3.1. Thanks for picking this up. I'd like to extend the proposal to Python 2.7 and later. -1 to adding it to the 2.x series. There was much discussion around adding features to 2.x *and* 3.0, and the consensus seemed to *not* add new features to 2.x and use those new features as carrots to help lead people into 3.0. jesse ___ 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] PEP 382: Namespace Packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Apr 6, 2009, at 9:21 AM, Jesse Noller wrote: On Thu, Apr 2, 2009 at 4:33 PM, M.-A. Lemburg m...@egenix.com wrote: On 2009-04-02 17:32, Martin v. Löwis wrote: I propose the following PEP for inclusion to Python 3.1. Thanks for picking this up. I'd like to extend the proposal to Python 2.7 and later. -1 to adding it to the 2.x series. There was much discussion around adding features to 2.x *and* 3.0, and the consensus seemed to *not* add new features to 2.x and use those new features as carrots to help lead people into 3.0. Actually, isn't the policy just that nothing can go into 2.7 that isn't backported from 3.1? Whether the actual backport happens or not is up to the developer though. OTOH, we talked about a lot of things and my recollection is probably fuzzy. Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSdoDAXEjvBPtnXfVAQIrPgQAse7BXQfPYHJJ/g3HNEtc0UmZZ9MCNtGc sIoZ2EHRVz+pylZT9fmSmorJdIdFvAj7E43tKsV2bQpo/am9XlL10SMn3k0KLxnF vNCi39nB1B7Uktbnrlpnfo4u93suuEqYexEwrkDhJuTMeye0Cxg0os5aysryuPza mKr5jsqkV5c= =Y9iP -END PGP 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] Tools
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Apr 5, 2009, at 7:37 PM, Matthias Klose wrote: Barry Warsaw schrieb: Someone (I'm sorry, I forgot who) asked me at Pycon about stripping out Demos and Tools. I'm happy to remove the two I wrote - Tools/world and Tools/pynche - from the distribution and release them as separate projects (retaining the PSF license). Should I remove them from both the Python 2.x and 3.x trunks? +1, but please for 2.7 and 3.1 only. Yes, of course. Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSdoE0XEjvBPtnXfVAQIyFgP+MqBghtSqVigJF9w/u47npaheOusITPWT iUeeJfTFDDHBKyYKXOwpASW+SahtnTO3OTR3f40S0Ptf+HRGo0J2efWUWcbXkN5X ikrHePT8YIp0MC4qYcUAfNrSNtgYxJuVKd7ARCFotBSN3Nu+bxzPO+LGw5xhlvbT Q3H3f3TQM3A= =nCUB -END PGP 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] pyc files, constant folding and borderline portability issues
On Mar 29, 2009 at 05:36PM, Guido van Rossum gu...@python.org wrote:
- Issue #5593: code like 1e16+2. is optimized away and its result stored
as
a constant (again), but the result can vary slightly depending on the
internal
FPU precision.
I would just not bother constant folding involving FP, or only if the
values involved have an exact representation in IEEE binary FP format.
The Language Reference says nothing about the effects of code optimizations.
I think it's a very good thing, because we can do some work here with constant
folding.
If someone wants to preserve precision with floats, it can always use a
temporary
variable, like in many other languages.
These problems have probably been there for a long time and almost no one
seems
to complain, but I thought I'd report them here just in case.
I would expect that constant folding isn't nearly effective in Python
as in other (less dynamic) languages because it doesn't do anything
for NAMED constants. E.g.
MINUTE = 60
def half_hour():
return MINUTE*30
This should be folded to return 1800 but doesn't because the
compiler doesn't know that MINUTE is a constant.
I completely agree. We can't say nothing about MINUTE at the time half_hour
will be executed. The code here must never been changed.
Has anyone ever profiled the effectiveness of constant folding on
real-world code? The only kind of constant folding that I expect to be
making a diference is things like unary operators, since e.g. x = -2
is technically an expression involving a unary minus.
At this time with Python 2.6.1 we have these results:
def f(): return 1 + 2 * 3 + 4j
dis(f)
1 0 LOAD_CONST 1 (1)
3 LOAD_CONST 5 (6)
6 BINARY_ADD
7 LOAD_CONST 4 (4j)
10 BINARY_ADD
11 RETURN_VALUE
def f(): return ['a', ('b', 'c')] * (1 + 2 * 3)
dis(f)
1 0 LOAD_CONST 1 ('a')
3 LOAD_CONST 7 (('b', 'c'))
6 BUILD_LIST 2
9 LOAD_CONST 4 (1)
12 LOAD_CONST 8 (6)
15 BINARY_ADD
16 BINARY_MULTIPLY
17 RETURN_VALUE
With proper constant folding code, both functions can be reduced
to a single LOAD_CONST and a RETURN_VALUE (or, definitely, by
a single instruction at all with an advanced peephole optimizer).
I'll show you it at PyCon in Florence, next month.
ISTM that historically, almost every time we attempted some new form
of constant folding, we introduced a bug.
I found a very rich test battery with Python, which helped me a lot in my
work of changing the ast, compiler, peephole, and VM.
If they aren't enough, we can expand them to add more test cases.
But, again, the Language Reference says nothing about optimizations.
Cheers,
Cesare
___
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] PEP 382: Namespace Packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Apr 6, 2009, at 9:21 AM, Jesse Noller wrote: On Thu, Apr 2, 2009 at 4:33 PM, M.-A. Lemburg m...@egenix.com wrote: On 2009-04-02 17:32, Martin v. Löwis wrote: I propose the following PEP for inclusion to Python 3.1. Thanks for picking this up. I'd like to extend the proposal to Python 2.7 and later. -1 to adding it to the 2.x series. There was much discussion around adding features to 2.x *and* 3.0, and the consensus seemed to *not* add new features to 2.x and use those new features as carrots to help lead people into 3.0. Actually, isn't the policy just that nothing can go into 2.7 that isn't backported from 3.1? Whether the actual backport happens or not is up to the developer though. OTOH, we talked about a lot of things and my recollection is probably fuzzy. I believe Barry is correct. The official policy is no features in 2.7 that aren't also in 3.1. I personally think I'm not going to put anything else in 2.7, specifically the ',' formatter stuff from PEP 378. 3.1 has diverged too far from 2.7 in this regard to make the backport easy to do. But this decision is left up to the individual committer. ___ 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] pyc files, constant folding and borderline portability issues
Cesare Di Mauro cesare.dimauro at a-tono.com writes:
def f(): return ['a', ('b', 'c')] * (1 + 2 * 3)
[...]
With proper constant folding code, both functions can be reduced
to a single LOAD_CONST and a RETURN_VALUE (or, definitely, by
a single instruction at all with an advanced peephole optimizer).
Lists are mutable, you can't optimize the creation of list literals by storing
them as singleton constants.
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
Re: [Python-Dev] PEP 382: Namespace Packages
At 02:00 PM 4/6/2009 +0100, Chris Withers wrote: Martin v. Löwis wrote: Chris Withers wrote: Would this support the following case: I have a package called mortar, which defines useful stuff: from mortar import content, ... I now want to distribute large optional chunks separately, but ideally so that the following will will work: from mortar.rbd import ... from mortar.zodb import ... from mortar.wsgi import ... Does the PEP support this? That's the primary purpose of the PEP. Are you sure? Does the pep really allow for: from mortar import content from mortar.rdb import something ...where 'content' is a function defined in mortar/__init__.py and 'something' is a function defined in mortar/rdb/__init__.py *and* the following are separate distributions on PyPI: - mortar - mortar.rdb ...where 'mortar' does not contain 'mortar.rdb'. See the third paragraph of http://www.python.org/dev/peps/pep-0382/#discussion ___ 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] PEP 382: Namespace Packages
P.J. Eby wrote: See the third paragraph of http://www.python.org/dev/peps/pep-0382/#discussion Indeed, I guess the PEP could be made more explanatory then 'cos, as a packager, I don't see what I'd put in the various setup.py and __init__.py to make this work... That said, I'm delighted to hear it's going to be possible and wholeheartedly support the PEP and it's backporting to 2.7 as a result... cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ 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] PEP 382: Namespace Packages
On Mon, Apr 6, 2009 at 9:26 AM, Barry Warsaw ba...@python.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Apr 6, 2009, at 9:21 AM, Jesse Noller wrote: On Thu, Apr 2, 2009 at 4:33 PM, M.-A. Lemburg m...@egenix.com wrote: On 2009-04-02 17:32, Martin v. Löwis wrote: I propose the following PEP for inclusion to Python 3.1. Thanks for picking this up. I'd like to extend the proposal to Python 2.7 and later. -1 to adding it to the 2.x series. There was much discussion around adding features to 2.x *and* 3.0, and the consensus seemed to *not* add new features to 2.x and use those new features as carrots to help lead people into 3.0. Actually, isn't the policy just that nothing can go into 2.7 that isn't backported from 3.1? Whether the actual backport happens or not is up to the developer though. OTOH, we talked about a lot of things and my recollection is probably fuzzy. Barry That *is* the official policy, but there was discussions around no further backporting of features from 3.1 into 2.x, therefore providing more of an upgrade incentive ___ 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] deprecating BaseException.message
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brett Cannon wrote: During the PyCon sprint I tried to make BaseException accept only a single argument and bind it to BaseException.message . I was successful (see the p3yk_no_args_on_exc branch), but it was very painful to pull off as anyone who sat around me the last three days of the sprint will tell you as they had to listen to me curse incessantly. Because of the pain that I went through in the transition and thus the lessons learned, Guido and I discussed it and we think it would be best to give up on forcing BaseException to accept only a single argument. I think it is still doable, but requires a multi-release transition period and not the one that 2.6 - 3.0 is offering. And so Guido and I plan on deprecating BaseException.message as its entire point in existence was to help transition to what we are not going to have happen. =) Now that means BaseException.message might hold the record for shortest lived feature as it was only introduced in 2.5 and is now to be deprecated in 2.6 and removed in 2.7/3.0. =) Below is PEP 352, revised to reflect the removal of BaseException.messageand for letting the 'args' attribute stay (along with suggesting one should only pass a single argument to BaseException). Basically the interface for exceptions doesn't really change in 3.0 except for the removal of __getitem__. Hmm, I'm working on cleaning up deprecations for Zope and related packages under Python 2.6. The irony here is that I'm receiving deprecation warnings for custom exception classes which had a 'message' attribute long before the abortive attempt to add them to the BaseException type, which hardly seems reasonable. For instance, docutils.parsers.rst defines a DirectiveError which takes two arguments, 'level' and 'message', and therefore gets hit with the deprecation (even though it never used the new signature). Likewise, ZODB.POSException defines a ConflictError type which takes 'message' as one of several arguments, all optional, and has since at least 2002. I don't think either of these classes should be subject to a deprecation warning for a feature they never used or depended on. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ2iqv+gerLs4ltQ4RArg7AJ9cjTweXUuGdUZNxZ3dHzYb9u6AcQCePJW/ PrXQ48wFrwrsrXSslZ0LSB4= =VU1d -END PGP 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] PEP 382: Namespace Packages
On Mon, 6 Apr 2009 at 12:00, Jesse Noller wrote: On Mon, Apr 6, 2009 at 9:26 AM, Barry Warsaw ba...@python.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Apr 6, 2009, at 9:21 AM, Jesse Noller wrote: On Thu, Apr 2, 2009 at 4:33 PM, M.-A. Lemburg m...@egenix.com wrote: On 2009-04-02 17:32, Martin v. L?wis wrote: I propose the following PEP for inclusion to Python 3.1. Thanks for picking this up. I'd like to extend the proposal to Python 2.7 and later. -1 to adding it to the 2.x series. There was much discussion around adding features to 2.x *and* 3.0, and the consensus seemed to *not* add new features to 2.x and use those new features as carrots to help lead people into 3.0. Actually, isn't the policy just that nothing can go into 2.7 that isn't backported from 3.1? ?Whether the actual backport happens or not is up to the developer though. ?OTOH, we talked about a lot of things and my recollection is probably fuzzy. Barry That *is* the official policy, but there was discussions around no further backporting of features from 3.1 into 2.x, therefore providing more of an upgrade incentive My sense was that this wasn't proposed as a hard and fast rule, more as a strongly suggested guideline. And in this case, I think you could argue that the PEP is actually fixing a bug in the current namespace packaging system. Some projects, especially the large ones where this matters most, are going to have to maintain backward compatibility for 2.x for a long time even as 3.x adoption accelerates. It seems a shame to require packagers to continue to deal with the problems caused by the current system even after all the platforms have made it to 2.7+. --David___ 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] PEP 382: Namespace Packages
On Mon, Apr 6, 2009 at 12:28 PM, R. David Murray rdmur...@bitdance.com wrote: On Mon, 6 Apr 2009 at 12:00, Jesse Noller wrote: On Mon, Apr 6, 2009 at 9:26 AM, Barry Warsaw ba...@python.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Apr 6, 2009, at 9:21 AM, Jesse Noller wrote: On Thu, Apr 2, 2009 at 4:33 PM, M.-A. Lemburg m...@egenix.com wrote: On 2009-04-02 17:32, Martin v. Löwis wrote: I propose the following PEP for inclusion to Python 3.1. Thanks for picking this up. I'd like to extend the proposal to Python 2.7 and later. -1 to adding it to the 2.x series. There was much discussion around adding features to 2.x *and* 3.0, and the consensus seemed to *not* add new features to 2.x and use those new features as carrots to help lead people into 3.0. Actually, isn't the policy just that nothing can go into 2.7 that isn't backported from 3.1? Whether the actual backport happens or not is up to the developer though. OTOH, we talked about a lot of things and my recollection is probably fuzzy. Barry That *is* the official policy, but there was discussions around no further backporting of features from 3.1 into 2.x, therefore providing more of an upgrade incentive My sense was that this wasn't proposed as a hard and fast rule, more as a strongly suggested guideline. And in this case, I think you could argue that the PEP is actually fixing a bug in the current namespace packaging system. Some projects, especially the large ones where this matters most, are going to have to maintain backward compatibility for 2.x for a long time even as 3.x adoption accelerates. It seems a shame to require packagers to continue to deal with the problems caused by the current system even after all the platforms have made it to 2.7+. --David I know it wasn't a hard and fast rule; also, with 3to2 already being worked on, the barrier of maintenance and back porting is going to be lowered. ___ 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] pyc files, constant folding and borderline portability issues
Cesare At this time with Python 2.6.1 we have these results:
Cesare def f(): return 1 + 2 * 3 + 4j
...
Cesare def f(): return ['a', ('b', 'c')] * (1 + 2 * 3)
Guido can certainly correct me if I'm wrong, but I believe the main point of
his message was that you aren't going to encounter a lot of code in Python
which is amenable to traditional constant folding. For the most part, they
will be assigned to symbolic constants, which, unlike C preprocessor
macros aren't really constants at all. Consequently, the opportunity for
constant folding is minimal and probably introduces more opportunities for
bugs than performance improvements.
Skip
___
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] pyc files, constant folding and borderline portability issues
On Lun, Apr 6, 2009 16:43, Antoine Pitrou wrote:
Cesare Di Mauro cesare.dimauro at a-tono.com writes:
def f(): return ['a', ('b', 'c')] * (1 + 2 * 3)
[...]
With proper constant folding code, both functions can be reduced
to a single LOAD_CONST and a RETURN_VALUE (or, definitely, by
a single instruction at all with an advanced peephole optimizer).
Lists are mutable, you can't optimize the creation of list literals by
storing
them as singleton constants.
Regards
Antoine.
You are right, I've mistyped the example.
def f(): return ('a', ('b', 'c')) * (1 + 2 * 3)
generates a single instruction (depending on the threshold used to limit
folding of sequences), whereas
def f(): return ['a', ('b', 'c')] * (1 + 2 * 3)
needs three.
Sorry for the mistake.
Cheers,
Cesare
___
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] PEP 382: Namespace Packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jesse Noller wrote: On Mon, Apr 6, 2009 at 12:28 PM, R. David Murray rdmur...@bitdance.com wrote: On Mon, 6 Apr 2009 at 12:00, Jesse Noller wrote: On Mon, Apr 6, 2009 at 9:26 AM, Barry Warsaw ba...@python.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Apr 6, 2009, at 9:21 AM, Jesse Noller wrote: On Thu, Apr 2, 2009 at 4:33 PM, M.-A. Lemburg m...@egenix.com wrote: On 2009-04-02 17:32, Martin v. Löwis wrote: I propose the following PEP for inclusion to Python 3.1. Thanks for picking this up. I'd like to extend the proposal to Python 2.7 and later. -1 to adding it to the 2.x series. There was much discussion around adding features to 2.x *and* 3.0, and the consensus seemed to *not* add new features to 2.x and use those new features as carrots to help lead people into 3.0. Actually, isn't the policy just that nothing can go into 2.7 that isn't backported from 3.1? Whether the actual backport happens or not is up to the developer though. OTOH, we talked about a lot of things and my recollection is probably fuzzy. Barry That *is* the official policy, but there was discussions around no further backporting of features from 3.1 into 2.x, therefore providing more of an upgrade incentive My sense was that this wasn't proposed as a hard and fast rule, more as a strongly suggested guideline. And in this case, I think you could argue that the PEP is actually fixing a bug in the current namespace packaging system. Some projects, especially the large ones where this matters most, are going to have to maintain backward compatibility for 2.x for a long time even as 3.x adoption accelerates. It seems a shame to require packagers to continue to deal with the problems caused by the current system even after all the platforms have made it to 2.7+. --David I know it wasn't a hard and fast rule; also, with 3to2 already being worked on, the barrier of maintenance and back porting is going to be lowered. My understanding from the summit is that the only point in a 2.7 release at all is to lower the speed bumps which make porting from 2.x to 3.x hard for large codebases. In this case, having a consistent spelling for namespace packages between 2.7 and 3.1 would incent those applications / frameworks / libraries to move to 2.7, and therefore ease getting them to 3.1. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ2jaR+gerLs4ltQ4RAsi1AJ0cJyKsoP5SlOcBlnzLr6MB11ZoNwCg1Kil 4O2M0sZG+jH12s22p2AmXWk= =DLRM -END PGP 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] Possible py3k io wierdness
Nick Coghlan wrote: Brian Quinlan wrote: - you need the cooperation of your subclasses i.e. they must call super().flush() in .flush() to get correct close behavior (and this represents a backwards-incompatible semantic change) Are you sure about that? Going by the current _pyio semantics that Antoine posted, it looks to me that it is already the case that subclasses need to invoke the parent flush() call correctly to avoid breaking the base class semantics (which really isn't an uncommon problem when it comes to writing correct subclasses). As it is now, if you didn't call super().flush() in your flush override, then a buffer won't be flushed at the time that you expected. With the proposed change, if you don't call super().flush() in your flush override, then the buffer will never get flushed and you will lose data when you close the file. I'm not saying that it is a big deal, but it is a difference. Cheers, Brian ___ 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] pyc files, constant folding and borderline portability issues
On Mon, Apr 6, 2009 18:57, s...@pobox.com wrote:
Cesare At this time with Python 2.6.1 we have these results:
Cesare def f(): return 1 + 2 * 3 + 4j
...
Cesare def f(): return ['a', ('b', 'c')] * (1 + 2 * 3)
Guido can certainly correct me if I'm wrong, but I believe the main point
of
his message was that you aren't going to encounter a lot of code in Python
which is amenable to traditional constant folding. For the most part,
they
will be assigned to symbolic constants, which, unlike C preprocessor
macros aren't really constants at all. Consequently, the opportunity for
constant folding is minimal and probably introduces more opportunities for
bugs than performance improvements.
Skip
I can understand Guido's concern, but you worked as well on constant
folding, and you know that there's space for optimizations here.
peephole.c have some code for unary, binary, and tuple/list folding; they
worked fine. Why mantaining unuseful and dangerous code, otherwise?
I know that bugs can come out doing such optimizations, but Python have a
good tests battery that can help find them. Obviously tests can't give us
100% insurance that everything works as expected, but they are very good
starting point.
Bugs can happen at every change on the code base, but code base changes...
Cesare
___
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] pyc files, constant folding and borderline portability issues
[Antoine] - Issue #5593: code like 1e16+2. is optimized away and its result stored as a constant (again), but the result can vary slightly depending on the internal FPU precision. [Guido] I would just not bother constant folding involving FP, or only if the values involved have an exact representation in IEEE binary FP format. +1 for removing constant folding for floats (besides conversion of -literal). There are just too many things to worry about: FPU rounding mode and precision, floating-point signals and flags, effect of compiler flags, and the potential benefit seems small. Mark ___ 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] pyc files, constant folding and borderline portability issues
+1 for removing constant folding for floats (besides conversion of -literal). There are just too many things to worry about: FPU rounding mode and precision, floating-point signals and flags, effect of compiler flags, and the potential benefit seems small. If you're talking about the existing peepholer optimization that has been in-place for years, I think it would be better to leave it as-is. It's better to have the compiler do the work than to have a programmer thinking he/she needs to do it by hand (reducing readability by introducing magic numbers). The code for the lsum() recipe is more readable with a line like: exp = long(mant * 2.0 ** 53) than with exp = long(mant * 9007199254740992.0) It would be ashamed if code written like the former suddenly started doing the exponentation in the inner-loop or if the code got rewritten by hand as shown. The list of things to worry about seems like the normal list of issues associated with doing anything in floating point. Python is already FPU challenged in that it offers nearly zero control over the FPU or direct access to signals and flags. Every step of a floating point calculation in Python gets written-out to a PyFloat object and is squeezed back into a C double (potentially introducing double-rounding if extended precision had be used by the FPU). Disabling the peepholer doesn't change this situation. Raymond ___ 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] Evaluated cmake as an autoconf replacement
Hi, On Sun, Mar 29, 2009 at 10:21 AM, Jeffrey Yasskin jyass...@gmail.com wrote: I've heard some good things about cmake — LLVM, googletest, and Boost are all looking at switching to it — so I wanted to see if we could simplify our autoconf+makefile system by using it. The biggest wins I see from going to cmake are: 1. It can autogenerate the Visual Studio project files instead of needing them to be maintained separately 2. It lets you write functions and modules without understanding autoconf's mix of shell and M4. 3. Its generated Makefiles track header dependencies accurately so we might be able to add private headers efficiently. I am switching to cmake with all my python projects, as it is rock solid, supports building in parallel (if I have some C++ and Cython extensions), and the configure part works well. The only disadvantage that I can see is that one has to learn a new syntax, which is not Python. But on the other hand, at least it forces one to really just use cmake to write build scripts in a standard way, while scons and other Python solutions imho encourage to write full Python programs, which imho is a disadvantage for the build system, as then every build system is nonstandard. Ondrej ___ 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] pyc files, constant folding and borderline portability issues
On Mon, Apr 6, 2009 at 9:05 PM, Raymond Hettinger pyt...@rcn.com wrote: The code for the lsum() recipe is more readable with a line like: exp = long(mant * 2.0 ** 53) than with exp = long(mant * 9007199254740992.0) It would be ashamed if code written like the former suddenly started doing the exponentation in the inner-loop or if the code got rewritten by hand as shown. Well, I'd say that the obvious solution here is to compute the constant 2.0**53 just once, somewhere outside the inner loop. In any case, that value would probably be better written as 2.0**DBL_MANT_DIG (or something similar). As Antoine reported, the constant-folding caused quite a confusing bug report (issue #5593): the problem (when we eventually tracked it down) was that the folded constant was in a .pyc file, and so wasn't updated when the compiler flags changed. Mark ___ 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] Getting information out of the buildbots
I committed some new telnetlib tests yesterday to the trunk and I can see they are failing on Neal's setup but not what the failures are. Ideally I like to get the information out of the buildbots but they all seem to be hanging on stdio tests and quiting out. Ideas? TIA, -Jack ___ 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] Getting information out of the buildbots
Jack diederich jackdied at gmail.com writes: I committed some new telnetlib tests yesterday to the trunk and I can see they are failing on Neal's setup but not what the failures are. Ideally I like to get the information out of the buildbots but they all seem to be hanging on stdio tests and quiting out. You can commit some temporary debug output in the tests (just sprinkle those print()'s you need to get your tasty information). 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
Re: [Python-Dev] pyc files, constant folding and borderline portability issues
On Mon, Apr 6, 2009 at 7:28 AM, Cesare Di Mauro cesare.dima...@a-tono.com wrote: The Language Reference says nothing about the effects of code optimizations. I think it's a very good thing, because we can do some work here with constant folding. Unfortunately the language reference is not the only thing we have to worry about. Unlike languages like C++, where compiler writers have the moral right to modify the compiler as long as they stay within the weasel-words of the standard, in Python, users' expectations carry value. Since the language is inherently not that fast, users are not all that focused on performance (if they were, they wouldn't be using Python). Unsurprising behavior OTOH is valued tremendously. -- --Guido van Rossum (home page: http://www.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] pyc files, constant folding and borderline portability issues
On Mon, Apr 6, 2009 at 1:22 PM, Mark Dickinson dicki...@gmail.com wrote: On Mon, Apr 6, 2009 at 9:05 PM, Raymond Hettinger pyt...@rcn.com wrote: The code for the lsum() recipe is more readable with a line like: exp = long(mant * 2.0 ** 53) than with exp = long(mant * 9007199254740992.0) It would be ashamed if code written like the former suddenly started doing the exponentation in the inner-loop or if the code got rewritten by hand as shown. Do you have any evidence that people write lots of inner loops with constant expressions? In real-world code these just don't exist that much. The case of constant folding in Python is *much* weaker than in C because Python doesn't have real compile-time constants, so named constants are variables to the compiler. Well, I'd say that the obvious solution here is to compute the constant 2.0**53 just once, somewhere outside the inner loop. In any case, that value would probably be better written as 2.0**DBL_MANT_DIG (or something similar). So true. As Antoine reported, the constant-folding caused quite a confusing bug report (issue #5593): the problem (when we eventually tracked it down) was that the folded constant was in a .pyc file, and so wasn't updated when the compiler flags changed. Right. Over the years the peephole optimizer and constant folding have been a constant (though small) source of bugs. I'm not sure that there is much real-world value in it, and it is certainly not right to choose speed over correctness. -- --Guido van Rossum (home page: http://www.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] FWD: Library Reference is incomplete
Anyone able to look into this and fix it? Having all of the normal entrypoints for documentation broken is rather inconvenient for users :-) On Mon, Apr 6, 2009 at 15:06, Aahz a...@pythoncraft.com wrote: Hrm, looks like the whole 2.6 build is broken. - Forwarded message from M?ller-Reineke, Matthias matthias.mueller-rein...@grundvers.de - Subject: Library Reference is incomplete Date: Mon, 6 Apr 2009 11:25:54 +0200 From: M?ller-Reineke, Matthias matthias.mueller-rein...@grundvers.de To: webmas...@python.org Dear Webmaster, Library Reference on http://www.python.org/doc/ takes me to http://docs.python.org/library/ . That side doesn't contain the index of contents. Matthias M?ller-Reineke -- Grundeigent?mer-Versicherung VVaG Gro?e B?ckerstra?e 7 20095 Hamburg Tel: 040 - 3 76 63 - 199 Fax: 040 - 3 76 63 - 98 199 http://www.grundvers.de mailto:matthias.mueller-rein...@grundvers.de Firmensitz: Hamburg HRB 13 103 Vorstand: Heinz Walter Berens (Vors.), R?diger Buyten Aufsichtsratsvorsitzender: Peter Landmann - End forwarded message - -- Aahz (a...@pythoncraft.com) * http://www.pythoncraft.com/ ...string iteration isn't about treating strings as sequences of strings, it's about treating strings as sequences of characters. The fact that characters are also strings is the reason we have problems, but characters are strings for other good reasons. --Aahz ___ 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/thomas%40python.org -- Thomas Wouters tho...@python.org Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ 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] deprecating BaseException.message
Tres Seaver wrote: I don't think either of these classes should be subject to a deprecation warning for a feature they never used or depended on. Agreed. Could you raise a tracker issue for the spurious warnings? (I believe we should be able to make the warning condition a bit smarter to eliminate these). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ 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] Mercurial?
Ben Finney wrote: Nick Coghlan ncogh...@gmail.com writes: Mercurial appears to best allow the sales pitch to be tailored to the target audience (in this case, a group including a lot of people with a background predominantly involving centralised version control tools). I don't follow. Wouldn't your preceding points above instead make *Bazaar* the one best suited for a group including a lot of people with a background predominantly involving centralised version control tools? Yes, but the Bazaar advocates appear to have a hard time convincing the other existing DVCS users that it provides *enough* access to the underlying graph. So it then tends to get resisted by the folks that are already fans of git or Mercurial. Like I said though, this is a subjective impression formed by reading what other people have written rather than by actually experiencing any of the tools myself. I'm sure all of them are quite capable of getting the job done :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ 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] Mercurial?
Nick Coghlan wrote: Dirkjan Ochtman wrote: I have a stab at an author map at http://dirkjan.ochtman.nl/author-map. Could use some review, but it seems like a good start. Martin may be able to provide a better list of names based on the checkin name-SSH public key mapping in the SVN setup. I think the identification in the SSH keys is useless. It contains strings like loe...@mira or ncogh...@uberwald, or even multiple of them (ba...@wooz, ba...@resist, ...). It seems that the PEP needs to spell out a policy as to what committer information needs to look like; then we need to verify that the proposed name mapping matches that policy. (e.g. I believe my SVN checkin name is nick.coghlan rather than the shorter ncoghlan in my email address, and many others are in a similar boat since first.last was the chosen scheme for names in the SVN switchover) Correct. The objective was to not allow nick names, but have real names as committer names. It appears that this policy does not directly translate into Mercurial. 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] pyc files, constant folding and borderline portability issues
On Mon, Apr 6, 2009 at 2:22 PM, Mark Dickinson dicki...@gmail.com wrote: Well, I'd say that the obvious solution here is to compute the constant 2.0**53 just once, somewhere outside the inner loop. In any case, that value would probably be better written as 2.0**DBL_MANT_DIG (or something similar). As Antoine reported, the constant-folding caused quite a confusing bug report (issue #5593): the problem (when we eventually tracked it down) was that the folded constant was in a .pyc file, and so wasn't updated when the compiler flags changed. Another way of looking at this is that we have a ./configure option which affects .pyc output. Therefor, we should add a flag to the magic number, causing it to be regenerated as needed. Whether that's better or worse than removing constant folding I haven't decided. I have such low expectations of floating point that I'm not surprised by bugs like this. I'm more surprised that people expect consistent, deterministic results... -- Adam Olsen, aka Rhamphoryncus ___ 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] Getting information out of the buildbots
You can commit some temporary debug output in the tests (just sprinkle those print()'s you need to get your tasty information). Also, if you want to do a sequence of changes to test a specific machine, you might want to create a branch, make those changes, and then trigger a build of that branch just on that specific slave (use branches/name in the input field). When doing so, feel free to cancel any automated build that is currently running; make sure to use your real name in the UI so we know it's not spam. 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] FWD: Documentation site problems
there contents is missing from the python tutorial: The 3.0 docs seem to be correct: http://docs.python.org/3.0/tutorial/ It seems it is not the case anymore. The devel doc from Python 3 are missing a few tables of contents as well: http://docs.python.org/dev/py3k/tutorial/ When I build the html doc locally, it looks like Sphinx from svn (r68598) has an issue with the 'numbered' option in the toctree directive. Here is my output of `make html' from revision 71295 of the py3k branch: http://fourmanoit.googlepages.com/pydoc_output.txt It did work fine a few days back though -- yesterday, the online doc was still complete: I believe it was last built on March the 28th. Yours, -- Sylvain Fourmanoit Memory fault -- core...uh...um...core... Oh dammit, I forget! ___ 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] pyc files, constant folding and bor derline portability issues
On Tue, 7 Apr 2009 07:27:29 am Guido van Rossum wrote: Unfortunately the language reference is not the only thing we have to worry about. Unlike languages like C++, where compiler writers have the moral right to modify the compiler as long as they stay within the weasel-words of the standard, in Python, users' expectations carry value. Since the language is inherently not that fast, users are not all that focused on performance (if they were, they wouldn't be using Python). Unsurprising behavior OTOH is valued tremendously. Speaking as a user, Python's slowness is *not* a feature. Anything reasonable which can increase performance is a Good Thing. One of the better aspects of Python programming is that (in general) you can write code in the most natural way possible, with the least amount of scaffolding getting in the way. I'm with Raymond: I think it would be sad if exp = long(mant * 2.0 ** 53) did the exponentiation in the inner-loop. Pre-computing that value outside the loop counts as scaffolding, and gets in the way of readability and beauty. On the other hand, I'm with Guido when he wrote it is certainly not right to choose speed over correctness. This is especially a problem for floating point optimizations, and I urge Cesare to be conservative in any f.p. optimizations he introduces, including constant folding. So... +1 on the general principle of constant folding, -0.5 on any such optimizations which change the semantics of a f.p. operation. The only reason it's -0.5 rather than -1 is that (presumably) anyone who cares about floating point correctness already knows to never trust the compiler. -- Steven D'Aprano ___ 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] pyc files, constant folding and borderline portability issues
On Mon, Apr 6, 2009 at 5:10 PM, Steven D'Aprano st...@pearwood.info wrote: On Tue, 7 Apr 2009 07:27:29 am Guido van Rossum wrote: Unfortunately the language reference is not the only thing we have to worry about. Unlike languages like C++, where compiler writers have the moral right to modify the compiler as long as they stay within the weasel-words of the standard, in Python, users' expectations carry value. Since the language is inherently not that fast, users are not all that focused on performance (if they were, they wouldn't be using Python). Unsurprising behavior OTOH is valued tremendously. Speaking as a user, Python's slowness is *not* a feature. Anything reasonable which can increase performance is a Good Thing. One of the better aspects of Python programming is that (in general) you can write code in the most natural way possible, with the least amount of scaffolding getting in the way. I'm with Raymond: I think it would be sad if exp = long(mant * 2.0 ** 53) did the exponentiation in the inner-loop. Pre-computing that value outside the loop counts as scaffolding, and gets in the way of readability and beauty. On the other hand, I'm with Guido when he wrote it is certainly not right to choose speed over correctness. This is especially a problem for floating point optimizations, and I urge Cesare to be conservative in any f.p. optimizations he introduces, including constant folding. So... +1 on the general principle of constant folding, -0.5 on any such optimizations which change the semantics of a f.p. operation. The only reason it's -0.5 rather than -1 is that (presumably) anyone who cares about floating point correctness already knows to never trust the compiler. Unfortunately, historically well-meaning attempts at adding constant-folding have more than once introduced obscure bugs that were hard to reproduce and only discovered one or two releases later. This has little to do with caring about float correctness. It's more about the difficulty of debugging Heisenbugs. For all these reasons should be super risk averse in this area. -- --Guido van Rossum (home page: http://www.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] Evaluated cmake as an autoconf replacement
David Cournapeau wrote: On Mon, Mar 30, 2009 at 2:59 AM, Antoine Pitrou solip...@pitrou.net wrote: ... Waf is definitely faster than scons - something like one order of magnitude. I am yet very familiar with waf, but I like what I saw - the architecture is much nicer than scons (waf core amount of code is almost ten times smaller than scons core), but I would not call it a mature project yet. I haven't tried waf, but IIUC it _solves_ the bootstrap issue. ___ 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] Evaluated cmake as an autoconf replacement
Ondrej Certik wrote: Hi, On Sun, Mar 29, 2009 at 10:21 AM, Jeffrey Yasskin jyass...@gmail.com wrote: I've heard some good things about cmake — LLVM, googletest, and Boost are all looking at switching to it — so I wanted to see if we could simplify our autoconf+makefile system by using it. The biggest wins I see from going to cmake are: 1. It can autogenerate the Visual Studio project files instead of needing them to be maintained separately 2. It lets you write functions and modules without understanding autoconf's mix of shell and M4. 3. Its generated Makefiles track header dependencies accurately so we might be able to add private headers efficiently. I am switching to cmake with all my python projects, as it is rock solid, supports building in parallel (if I have some C++ and Cython extensions), and the configure part works well. The only disadvantage that I can see is that one has to learn a new syntax, which is not Python. But on the other hand, at least it forces one to really just use cmake to write build scripts in a standard way, while scons and other Python solutions imho encourage to write full Python programs, which imho is a disadvantage for the build system, as then every build system is nonstandard. [obirrelevance] Isn't it strange how nobody every complained about the significance of whitespace in makefiles: only the fact that leading tabs were required rather than just-any-old whitespace. I guess some people just home in on things to complain about. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ Want to know? Come to PyCon - soon! http://us.pycon.org/ ___ 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] Mercurial?
Dirkjan Ochtman wrote: On Mon, Apr 6, 2009 at 06:20, Alexandre Vassalotti alexan...@peadrop.com wrote: But that won't work if people who are not core developers submit us patch bundle to import. And maintaining a such white-list sounds to me more burdensome than necessary. Well, if you need contributors to sign a contributor's agreement anyway, there's already some list out there that we can leverage. The other option is to play the consenting adults card and ask all people with push access to ascertain the correct names of committer names on patches they push. I would remind you all that it's *very* necessary to make sure that whatever finds its way into released code is indeed covered by contributor agreements. The PSF (as the guardian of the IP) has to ensure this, and so we have to find a way of ensuring that all contributions to source are correctly logged against authors in a traceable way. regasds Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ Want to know? Come to PyCon - soon! http://us.pycon.org/ ___ 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] calling dictresize outside dictobject.c
Hi, I'm trying to write a C extension which is a subclass of dict. I want to do something like a setdefault() but with a single lookup. Looking through the dictobject code, the three workhorse routines lookdict, insertdict and dictresize are not available directly for functions outside dictobject.c, but I can get at lookdict through dict-ma_lookup(). So I use lookdict to get the PyDictEntry (call it ep) I'm looking for. The comments for lookdict say ep is ready to be set... so I do that. Then I check whether the dict needs to be resized--following the nice example of PyDict_SetItem. But I can't call dictresize to finish off the process. Should I be using PyDict_SetItem directly? No... it does its own lookup. I don't want a second lookup! I already know which entry will be filled. So then I look at the code for setdefault and it also does a double lookup for checking and setting an entry. What subtle issue am I missing? Why does setdefault do a double lookup? More globally, why isn't dictresize available through the C-API? If there isn't a reason to do a double lookup I have a patch for setdefault, but I thought I should ask here first. Thanks! Dan ___ 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] Evaluated cmake as an autoconf replacement
Steve Holden wrote: Isn't it strange how nobody every complained about the significance of whitespace in makefiles: only the fact that leading tabs were required rather than just-any-old whitespace. Make doesn't care how *much* whitespace there is, though, only whether it's there or not. If it accepted anything that looks like whitespace, there would be no cause for complaint. -- Greg ___ 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] decorator module in stdlib?
The decorator module [1] written by Michele Simionato is a very useful tool for maintaining function signatures while applying a decorator. Many different projects implement their own versions of the same functionality, for example turbogears has its own utility for this, I guess others do something similar too. Was the issue whether to include this module in the stdlib raised? If yes, what were the arguments against it? If not, what do you folks think, shouldn't it be included? I certainly think it should be. Originally I sent this message to c.l.p [2] and Michele suggested it be brought up on python-dev. He also pointed out that a PEP [3] is already written about this topic and it is in draft form. What do you guys think, wouldn't this be a useful addition to functools? Cheers, Daniel [1] http://pypi.python.org/pypi/decorator [2] http://groups.google.com/group/comp.lang.python/browse_thread/thread/d4056023f1150fe0 [3] http://www.python.org/dev/peps/pep-0362/ -- Psss, psss, put it down! - http://www.cafepress.com/putitdown ___ 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] Mercurial?
Alexandre Vassalotti writes: This makes me remember that we will have to decide how we will reorganize our workflow. For this, we can either be conservative and keep the current CVS-style development workflow--i.e., a few main repositories where all developers can commit to. That was the original idea of PEP 374, that was a presumption under which I wrote my part of it, I think we should stick with it. As people develop personal workflows, they can suggest them, and/or changes in the public workflow needed to support them. But there should be a working sample implementation before thinking about changes to the workflow. Simply allowing more people to work effectively offline is going to speed things up perceptibly. Improved branching will add to that impact. The current workflow is pretty clean. Let's not mess it up or all that will be achieved is to speed up the mess. Or we could drink the kool-aid and go with a kernel-style development workflow--i.e., each developer maintains his own branch and pull changes from each others. Can you give examples of projects using Mercurial that do that? All of the Mercurial projects I've seen up close have relatively centralized workflows, which Mercurial encourages because of the way it likes to automatically merge. I wouldn't want to try the kernel style with Mercurial because its named branch support doesn't work the way it should. In my experience, to deal with external branches, you have to maintain a separate workspace per external branch you want to follow. You'd also need to provide a users' guide to things like rebasing, which become very important in a kernel-style workflow, but which the Mercurial developers opposed on principle, at least at first. However if we go kernel-style, I will need to designate someone (i.e., an integrator) that will maintain the main branches, which will tested by buildbot and used for the public releases. These are issues I would like to address in the PEP. IMHO, that's new PEP. This is not part of the PEP 374 decision to go to a dVCS, nor part of the requirements for implementation, whether that is considered an extension of 374 or a new PEP in itself. ___ 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
