Re: [Python-Dev] Hg: inter-branch workflow
Neil Schemenauer writes: > Regarding collapsing multiple comments (and rewriting history in > general), I feel there are two main schools of thought. One school > considers the development history of a change important and that it > should be preserved: every step and misstep of development should end > up in the public repository. Yep, that's the school I'm in. Other people don't get to say what I would find useful, and the cost of having data there is very low compared to the inability to re-create it at the times when it's needed. > The other school, which I am a member of, considers a logical > development sequence more important than actual development history. That seems to be an artefact of VCS tools which force you to choose between those two. The reason I prefer Bazaar is that it gives me both without compromising either. > I like to see a feature or fix developed in smallish, logical steps > and I'm willing to spend a lot of time to rewrite patches to make it > happen. IMO, future maintainers will thank you for the effort. Right, and those logical steps are done as merges from the feature branch into the trunk (substitute those names as you like). I consider the merging from one branch to another as the time to decide how to present my VCS work for others to view. I haven't heard a useful case for rebase that I don't get with Bazaar's merging, default history presentation, and shelve capability. And all of that without ever having to re-write history – nor even choose what valuable information to lose. -- \ “The way to build large Python applications is to componentize | `\ and loosely-couple the hell out of everything.” —Aahz | _o__) | 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] [Python-checkins] cpython: Add optional *func* argument to itertools.accumulate().
On Mon, Mar 28, 2011 at 2:11 PM, Daniel Stutzbach wrote: > Is there a good use-case for the func argument? I can only think of bad > use-cases (where "func" does something that does not remotely resemble > addition). I fear that people will actually implement these bad use-cases, > and I will have to try to read and understand their code. > Adding the func argument seems analogous to adding a func argument to sum(), > which would give it all of the power of reduce(). The difference lies in the fact that, because accumulate is an iterator that yields a *running* result, the two corner cases that make reduce problematic in practice (i.e. correctly handling empty and 1-item input iterables) are handled naturally. The examples that Raymond gives in the docs (cumulative multiplication, running min/max, cash flow accumulation) look fairly solid to me. 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] [Python-checkins] cpython: Add optional *func* argument to itertools.accumulate().
On Sun, Mar 27, 2011 at 6:52 PM, raymond.hettinger < python-check...@python.org> wrote: > -.. function:: accumulate(iterable) +.. function:: accumulate(iterable[, func]) > > Make an iterator that returns accumulated sums. Elements may be any > addable > -type including :class:`Decimal` or :class:`Fraction`. Equivalent to:: > +type including :class:`Decimal` or :class:`Fraction`. If the optional > +*func* argument is supplied, it should be a function of two arguments > +and it will be used instead of addition. > Is there a good use-case for the func argument? I can only think of bad use-cases (where "func" does something that does not remotely resemble addition). I fear that people will actually implement these bad use-cases, and I will have to try to read and understand their code. Adding the func argument seems analogous to adding a func argument to sum(), which would give it all of the power of reduce(). -- Daniel Stutzbach ___ 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] Hg: inter-branch workflow
Barry Warsaw wrote: > I'm asking because I don't know hg and git well enough to answer the > question. In my own use of Bazaar over the last 4+ years, I've almost never > rebased or even been asked to. Maybe it depends on what kind of changes you commit. I consider future maintainers the most important "customer" of the repository history. As such, I try to make each commit a logical change that takes a working system and produces another working system. In that way, each change to be potentially reversed if later on if it found to cause problems. Also, ideally, each revision can be tested to narrow down the version where a bug was introduced. I see a VCS system as having two related but different purposes. The first is to help keep track of changes when they are developed. This is messy. I don't know about you but I make lots of mistakes: changes that don't do what I want, crazy ideas that turn into dead ends, etc. I use a VCS to keep track of this experimentation and my incremental progress. The second is to keep a record of the change history of a long lived piece of software. In that case, I like it that each change has a logical purpose. In the first case the "customer" is the developer. In the second it is the maintainer. > In this graph: > >> A --- B . >> / \ >>... --- X --- C --- D --- E --- M > > A and B do exist, but I shouldn't care or notice them unless I explicitly > drill down. In my case, I usually have something like: A --- B --- C / ... --- X --- F --- G --- H A, B, and C are messy and not logical. Maybe I write them so I have two logical patches (assuming they are only in my private repo): A' --- B' / ... --- X --- F --- G --- H Next, putting the merge in public repository generally serves no purpose so I rebase on H: ... --- X --- F --- G --- H --- A'' --- B'' This very much matches the result I would get if using CVS or Subversion. IMHO, the changes A, B, and C represent partially complete development and there is no purpose to put them in the public repo. If you are able to directly commit A' and B' and your tool does a good job of hiding the logically unimportant merge then I guess you wouldn't miss the ability to modify history. Neil ___ 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] Hg: inter-branch workflow
Guido van Rossum wrote: > What is "rebase"? Why does everyone want it and hate it at the same time? It's the same thing that happens when you do a "svn up" with local changes in your checkout. Logically, your patch gets modified so that it applies on a different (newer) version of the code. If you don't rebase then those modifications end up getting stored in the history as merge nodes. That's quite messy in my opinion and generally not a good idea. Rebase is an important tool (which can at times be abused). Regarding collapsing multiple comments (and rewriting history in general), I feel there are two main schools of thought. One school considers the development history of a change important and that it should be preserved: every step and misstep of development should end up in the public repository. The other school, which I am a member of, considers a logical development sequence more important than actual development history. I like to see a feature or fix developed in smallish, logical steps and I'm willing to spend a lot of time to rewrite patches to make it happen. IMO, future maintainers will thank you for the effort. Note though, when you are worked with a distributed system, you should not rebase commits that are in other people's repositories. In practice this is generally not a problem. If you have a long lived branch that you are sharing with other people, you can have a agreement that everyone will destory their old copy when it is rebased. Alternatively, you just take care to only publicly push logical changes. Regards, Neil ___ 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] Python 2.7 on Irix 6.5.22 fails ctypes callback test
Trying to compile and install Python 2.7 on irix 6.5.22 IP22 (N32 ABI model), Using gcc-4.5.1 and binutils 2.20.1. Everything goes well (I applied th patches listed at: http://bugs.python.org/file15915/python-2.7-irix.patch ) It compiles and the test mostly work except for the callback ctypes (libffi) test where it segfaults on a pyDECREFF. Digging in, the O_get call is returning a NULL pointer (and pyDECREF is understandably choking on that). Since I am very new to python, I am at a bit of a loss to tracing the C code back through this particulat section of code to see why the PyOBJECT isn't being assigned here. Any help would be welomed. -- David E. Cross ___ 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] utf-8 encoding in checkins?
On Sun, 27 Mar 2011 19:46:35 +0100, Jon Ribbens wrote: > On Sun, Mar 27, 2011 at 02:21:25PM -0400, R. David Murray wrote: > > > Mind you, I've never managed to get the <-- button working reliably > > > either, but to be fair that's insanely complicated too. > > > > No idea what that is. > > "Backspace" key. Ah, yes. The backspace key is indeed harder to get right across all applications than utf-8 is. Which makes one wonder, considering that the backspace key problem has been with us a lot longer. -- R. David Murray http://www.bitdance.com ___ 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] utf-8 encoding in checkins?
On 3/27/2011 2:13 PM, Eugene Toder wrote: I'm not disputing that, and I understand that my current choice of mail reader limits me. I was just asking if it would be possible (read: fairly easy) to only generate utf-8 when it was necessary. Isn't utf-8 itself same as ascii where no non-ascii symbols are used? Yes, except for the content encoding header. Any mail reader today should know that and at least replace any non-ascii bytes (very rare in checkin messages) with some symbol and continue, rather than crash. -- Terry Jan Reedy ___ 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] utf-8 encoding in checkins?
Martin> Am 27.03.2011 17:06, schrieb s...@pobox.com: >> It seems that all checkin mails are utf-8-encoded. This makes it >> challenging to view checkin mails if you have a text-based mail >> reader. (I use VM within XEmacs. XEmacs doesn't seem to support >> utf-8 out of the box. I believe you need to add MULE to it.) Is >> there some reason such messages can't be encoded in ASCII unless a >> non-ASCII message body is detected? Martin> Even if it was easy to change, I'd advise against doing Martin> so. IIUC, we use the standard email hook from the Mercurial Martin> sources, to change it would mean to fork it. Users with email Martin> readers that can't display UTF-8 at all (even if the characters Martin> are all ASCII) will need to find a way of coping with that. That's fine. I was just asking. I guess I have my work cut out for me. It appears my preferred mail reader, VM, is not supported out-of-the-box by GNU Emacs (they still use Rmail and Babyl for some reason), and I'm not sure the investment trying to get XEmacs built with MULE is worth the effort. 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] utf-8 encoding in checkins?
>> I'm not disputing that, and I understand that my current choice of >> mail reader limits me. I was just asking if it would be possible >> (read: fairly easy) to only generate utf-8 when it was necessary. Eugene> Isn't utf-8 itself same as ascii where no non-ascii symbols are Eugene> used? Sure, but the mime header tells VM that the body of the part is utf-8 encoded, and it's base64-encoded. If it wasn't base64-encoded I could simply hit D in my mail reader to expand the part. 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] utf-8 encoding in checkins?
On Sun, Mar 27, 2011 at 02:21:25PM -0400, R. David Murray wrote: > > Mind you, I've never managed to get the <-- button working reliably > > either, but to be fair that's insanely complicated too. > > No idea what that is. "Backspace" key. ___ 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] utf-8 encoding in checkins?
On Sun, Mar 27, 2011 at 02:13:29PM -0400, Eugene Toder wrote: > > I'm not disputing that, and I understand that my current choice of mail > > reader limits me. I was just asking if it would be possible (read: fairly > > easy) to only generate utf-8 when it was necessary. > > Isn't utf-8 itself same as ascii where no non-ascii symbols are used? Yes, however some software will label outgoing stuff as UTF-8 even if actually it contains no non-ASCII characters. Then, other software will assume that it cannot understand the message (either because it assumes the charset label is correct or because it doesn't know that it can understand "UTF-8" that contains no top-bit-set characters). ___ 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] utf-8 encoding in checkins?
Am 27.03.2011 17:06, schrieb s...@pobox.com: > It seems that all checkin mails are utf-8-encoded. This makes it > challenging to view checkin mails if you have a text-based mail reader. (I > use VM within XEmacs. XEmacs doesn't seem to support utf-8 out of the box. > I believe you need to add MULE to it.) Is there some reason such messages > can't be encoded in ASCII unless a non-ASCII message body is detected? Even if it was easy to change, I'd advise against doing so. IIUC, we use the standard email hook from the Mercurial sources, to change it would mean to fork it. Users with email readers that can't display UTF-8 at all (even if the characters are all ASCII) will need to find a way of coping with that. 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] utf-8 encoding in checkins?
On Sun, 27 Mar 2011 17:33:04 +0100, Jon Ribbens wrote: > In my experience it is very difficult to get a whole system > configured, such that UTF-8 works reliably. In my case that would > mean, I think, Linux, glibc, mutt, screen, elinks, and SecureCRT would > all have to simultaneously be configured precisely correctly in order > to get it to work. I have certainly never managed it, anyway. I remember a few small bumps when I switched to using utf8 by default in Linux, but nothing very difficult to figure out. There are still a few places where it isn't displayed properly, but they are isolated cases and don't bother me much (mostly a couple older tools that just don't have good non-ascii support). > Mind you, I've never managed to get the <-- button working reliably > either, but to be fair that's insanely complicated too. No idea what that is. -- R. David Murray http://www.bitdance.com ___ 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] utf-8 encoding in checkins?
On 27.03.2011 18:33, Jon Ribbens wrote: > On Sun, Mar 27, 2011 at 05:21:08PM +0200, Antoine Pitrou wrote: >> On Sun, 27 Mar 2011 10:06:49 -0500 >> s...@pobox.com wrote: >> > It seems that all checkin mails are utf-8-encoded. This makes it >> > challenging to view checkin mails if you have a text-based mail reader. (I >> > use VM within XEmacs. XEmacs doesn't seem to support utf-8 out of the box. >> > I believe you need to add MULE to it.) >> >> Hmm, are you sure? Software (especially mail-reading software) that >> doesn't support utf-8 in 2011 should be considered extremely broken. >> >> (I understand you may be a native English speaker, but do you never >> receive non-ASCII utf-8 e-mail at all? doesn't it get displayed >> properly?) > > In my experience it is very difficult to get a whole system > configured, such that UTF-8 works reliably. In my case that would > mean, I think, Linux, glibc, mutt, screen, elinks, and SecureCRT would > all have to simultaneously be configured precisely correctly in order > to get it to work. I have certainly never managed it, anyway. But surely there is a difference between input and output encoding? Even if a mail program cannot output UTF-8 correctly (due to whatever misconfiguration in the output chain), it should still be able to read base-64 encoded utf-8 blocks, and display most of them, even if the odd non-ASCII character is broken. > Mind you, I've never managed to get the <-- button working reliably > either, but to be fair that's insanely complicated too. Sorry, I'm not familiar with that button. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] utf-8 encoding in checkins?
> I'm not disputing that, and I understand that my current choice of mail > reader limits me. I was just asking if it would be possible (read: fairly > easy) to only generate utf-8 when it was necessary. Isn't utf-8 itself same as ascii where no non-ascii symbols are used? Eugene ___ 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] utf-8 encoding in checkins?
Antoine> Hmm, are you sure? Software (especially mail-reading software) Antoine> that doesn't support utf-8 in 2011 should be considered Antoine> extremely broken. I'm not disputing that, and I understand that my current choice of mail reader limits me. I was just asking if it would be possible (read: fairly easy) to only generate utf-8 when it was necessary. For the time being I'm using a procmail hack to blindly rewrite utf-8 to us-ascii in the checking messages. I'll see how that works before doing something more elaborate like switching out my mail reader. 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] utf-8 encoding in checkins?
On Sun, Mar 27, 2011 at 05:21:08PM +0200, Antoine Pitrou wrote: > On Sun, 27 Mar 2011 10:06:49 -0500 > s...@pobox.com wrote: > > It seems that all checkin mails are utf-8-encoded. This makes it > > challenging to view checkin mails if you have a text-based mail reader. (I > > use VM within XEmacs. XEmacs doesn't seem to support utf-8 out of the box. > > I believe you need to add MULE to it.) > > Hmm, are you sure? Software (especially mail-reading software) that > doesn't support utf-8 in 2011 should be considered extremely broken. > > (I understand you may be a native English speaker, but do you never > receive non-ASCII utf-8 e-mail at all? doesn't it get displayed > properly?) In my experience it is very difficult to get a whole system configured, such that UTF-8 works reliably. In my case that would mean, I think, Linux, glibc, mutt, screen, elinks, and SecureCRT would all have to simultaneously be configured precisely correctly in order to get it to work. I have certainly never managed it, anyway. Mind you, I've never managed to get the <-- button working reliably either, but to be fair that's insanely complicated too. ___ 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] utf-8 encoding in checkins?
On Sun, 27 Mar 2011 10:06:49 -0500 s...@pobox.com wrote: > It seems that all checkin mails are utf-8-encoded. This makes it > challenging to view checkin mails if you have a text-based mail reader. (I > use VM within XEmacs. XEmacs doesn't seem to support utf-8 out of the box. > I believe you need to add MULE to it.) Hmm, are you sure? Software (especially mail-reading software) that doesn't support utf-8 in 2011 should be considered extremely broken. (I understand you may be a native English speaker, but do you never receive non-ASCII utf-8 e-mail at all? doesn't it get displayed properly?) Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] utf-8 encoding in checkins?
It seems that all checkin mails are utf-8-encoded. This makes it challenging to view checkin mails if you have a text-based mail reader. (I use VM within XEmacs. XEmacs doesn't seem to support utf-8 out of the box. I believe you need to add MULE to it.) Is there some reason such messages can't be encoded in ASCII unless a non-ASCII message body is detected? 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
