Re: [Python-Dev] PEP 383 update: utf8b is now the error handler

2009-05-06 Thread Stephen J. Turnbull
Lino Mastrodomenico writes: > It's a know problem with Shift-JIS and was fixed in UTF-8. It was fixed in EUC before Shift-JIS was invented by Microsoft or Big5 was invented by the Taiwanese clone makers. Guido's not the only language designer with a time machine __

Re: [Python-Dev] PEP 383 update: utf8b is now the error handler

2009-05-06 Thread Stephen J. Turnbull
"Martin v. Löwis" writes: > > Yeah, yeah, this is the same old same old from PEP 3131. Anything > > that handles the various attacks based on ASCII-alike characters > > should at least rule out invalid Unicode, too! > > > > And where is this U+DC2F supposed to be coming from, anyway? The

Re: [Python-Dev] PEP 383 update: utf8b is now the error handler

2009-05-06 Thread Stephen J. Turnbull
"Martin v. Löwis" writes: > > Now, with Python's file system encoding == UTF-8 or any packed EUC, > > and more than a handful of Shift JIS or Big5 characters in file names, > > one is *almost certain* to encounter ASCII as the second byte of a > > multibyte sequence. PEP 383 can't handle this

Re: [Python-Dev] PEP 383 update: utf8b is now the error handler

2009-05-07 Thread Stephen J. Turnbull
Walter Dörwald writes: > "surrogatepass" (for the "don't complain about lone half surrogates" > handler) and "surrogatereplace" sound OK to me. However the other > "...replace" handlers are destructive (i.e. when such a "...replace" > handler is used for encoding, decoding will not produce the

Re: [Python-Dev] PEP 383 update: utf8b is now the error handler

2009-05-07 Thread Stephen J. Turnbull
M.-A. Lemburg writes: > I'd use "allowlonesurrogates" as name for the "surrogates" error > handler and "lonesurrogatereplace" for the "utf8b" one. +1 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev

[Python-Dev] Shorter release schedule?

2009-05-12 Thread Stephen J. Turnbull
Antoine Pitrou writes: > Just food for thought here, but seeing how 3.1 is going to be a > real featureful schedule despite being released shortly after 3.0, > wouldn't it make sense to tighten future release planning a little? With all due respect, it's easy and natural to have a short, featu

Re: [Python-Dev] Shorter release schedule?

2009-05-12 Thread Stephen J. Turnbull
Tennessee Leeuwenburg writes: > Can I ask if there's any sense in pursuing a release schedule which > is slow for whatever might be deemed the "most core modules" but > faster for "less core modules"? I think you need to be more specific about how many levels of "fast" there should be, and why

Re: [Python-Dev] [unladen-swallow] PEP 384: Defining a Stable ABI

2009-05-20 Thread Stephen J. Turnbull
Benjamin Peterson writes: > 2009/5/20 : > > > I suspect it's not really germane to this discussion but if the > > incref/decref functions were defined as inline would that effectively be > > like using the macro versions vis a vis ABI compatibility? > > The code would be inlined into appl

Re: [Python-Dev] Issues with Py3.1's new ipaddr

2009-06-02 Thread Stephen J. Turnbull
Aahz writes: > On Tue, Jun 02, 2009, Guido van Rossum wrote: > > > > I hope we can learn from this. > > I'm not thrilled with adding more process just because we had a problem > here, and the only obvious solution I see is to require a PEP every time > a module is added. Based on what I'v

Re: [Python-Dev] Issues with process and discussions (Re: Issues with Py3.1's new ipaddr)

2009-06-03 Thread Stephen J. Turnbull
Antoine Pitrou writes: > Terry Reedy udel.edu> writes: > > > > I watched and was greatly impressed by the video demo of Google's new > > Wave collaborative communication system. I believe it would/will help > > with some of the chronic problems we (and others) have. > > I really don't

Re: [Python-Dev] Status of 2.7 and 3.2

2009-06-07 Thread Stephen J. Turnbull
"Martin v. Löwis" writes: > I'm not sure that the concept of a "trunk" branch still exists in > Mercurial. PEP 385 apparently doesn't have resolved the branch strategy > for Mercurial yet. With cloned branches, I think the concept of a > "trunk" becomes irrelevant. "Trunk" exists as a technic

Re: [Python-Dev] Status of 2.7 and 3.2

2009-06-13 Thread Stephen J. Turnbull
Lennart Regebro writes: > 2009/6/7 Stephen J. Turnbull : > > Python's 2.x/py3k division is a tour de force; I still can't believe > > my eyes that you've pulled it off. > > Well, It's not pulled off until Python 3 has surpassed Python 2 in > usa

[Python-Dev] Anyone against having a loop option for regrtest?

2009-06-29 Thread Stephen J. Turnbull
Jesse Noller writes: > Any thoughts? Does anyone hate this idea with the power of a thousand suns? If somebody has the power of 1000 Suns at their disposal, maybe they can contribute a few buildbots? Wishful-thinking-is-the-order-of-the-day-ly y'rs,

Re: [Python-Dev] PEP 376

2009-07-01 Thread Stephen J. Turnbull
Tarek Ziadé writes: > On Wed, Jul 1, 2009 at 1:44 PM, Paul Moore wrote: > > General rule - don't document (and commit yourself to) any > > internal details that the user can't access from the public > > API. It just makes backward compatibility harder to maintain. > > The purpose is to prov

[Python-Dev] Mercurial migration: progress report (PEP 385)

2009-07-03 Thread Stephen J. Turnbull
Dirkjan Ochtman writes: > Mercurial has two basic ways of using branches: cloned branches, where > each branch is kept in a separate repository, and named branches, > where each revision keeps metadata to note on which branch it belongs. > The former makes it easier to distinguish branches, at

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

2009-07-03 Thread Stephen J. Turnbull
Dirkjan Ochtman writes: > On Fri, Jul 3, 2009 at 15:29, Stephen J. Turnbull wrote: > > I'll have to try them again now that 1.3 is out, but I found Mercurial > > named branches fundamentally unsuited to release management. > > Can you explain why, please? It

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

2009-07-03 Thread Stephen J. Turnbull
Nick Coghlan writes: > I'm not clear on the rationale for the explicit CRLF line ending on the > email test message, but I would guess it is to ensure that the email > module can handle CRLF line endings correctly regardless of platform. IIRC, that's just the standard for text email. Lines mu

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

2009-07-03 Thread Stephen J. Turnbull
P.J. Eby writes: > Wouldn't the simple thing to do in Mercurial, just be to use > different repositories for long-lived branches? I mean, if you're > not merging them that much anyway, what's the point? I basically agree with that, and so does Dirkjan, I think. I'm not sure why he brought

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

2009-07-05 Thread Stephen J. Turnbull
Georg Brandl writes: > What I really want to see is the common-subset approach for > maintenance branches. IMO, this unfortunately unlikely to work as you seem to expect, for a two technical reasons and for a social reason. The first technical reason is that a maintenance branch really is a br

Re: [Python-Dev] PEP 376 - Open questions

2009-07-07 Thread Stephen J. Turnbull
Tarek Ziadé writes: > On Tue, Jul 7, 2009 at 10:31 PM, P.J. Eby wrote: > > No one expects the package inquisition.  ;-) > Sorry, i've looked in the english dictionary but I don't get this one. I think that far more important than PEP 385 conversion of Roundup and other utilities to recognize

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

2009-07-07 Thread Stephen J. Turnbull
R. David Murray writes: > On Tue, 7 Jul 2009 at 15:26, M.-A. Lemburg wrote: > > I've seen a few discussions about this, but no final statement > > of what strategy to follow and whether hg makes this easier (AFAIR, > > that was the main argument for switching to hg). Yes, yes, yes, and no. I

Re: [Python-Dev] PEP 376 - Open questions

2009-07-08 Thread Stephen J. Turnbull
Eric Smith writes: > But I think we've veered into metadata that describes what has been > installed. I don't think that's so useful. As I've said, this is private > to the installers. If 2 installers want to communicate with each other > about what they've installed, then they can agree on

Re: [Python-Dev] Remove site-packages?!? [was: [Distutils] PEP 376 - from pythonpkgmgr's point of view]

2009-07-23 Thread Stephen J. Turnbull
Floris Bruynooghe writes: > [dist-packages] is a pretty neat solution to the problem. To what problem? I admit I am no expert on Python packaging, but my experience with XEmacs suggests that this is the distro trying to help with a *set* of problems that the user/sysadmins really should be hand

Re: [Python-Dev] Update to Python Documentation Website Request

2009-07-24 Thread Stephen J. Turnbull
David Lyon writes: > On Fri, 24 Jul 2009 17:08:32 +0100, Paul Moore wrote: > > I read this as meaning that David was proposing to ship a built > > application (on Windows, bundled up with something like py2exe, I > > guess) and any supporting DLLs such as the wxWindows ones would be > > bundl

Re: [Python-Dev] Update to Python Documentation Website Request

2009-07-26 Thread Stephen J. Turnbull
"Martin v. Löwis" writes: > > pythonpkgmgr is not so different to that. And the idea behind it is > > to bring consistancy in package management across the different > > platforms. > > At the cost of being inconsistent within a platform. Indeed, and that seems to be one of the really big s

Re: [Python-Dev] Update to Python Documentation Website Request

2009-07-27 Thread Stephen J. Turnbull
David Lyon writes: > On Mon, 27 Jul 2009 11:18:25 +0900, "Stephen J. Turnbull" > wrote: > > [1] on > > my part") and sysadmin goals ("something that works and plays nicely > > with the rest of the system"). > > > > pytho

Re: [Python-Dev] Update to Python Documentation Website Request

2009-07-27 Thread Stephen J. Turnbull
David Lyon writes: > It manages local developer modules for python 2.6+. > pythonpkgmgr is aimed at featherweight users. You were talking about "developers", but now they're "featherweight users"? I'm sorry, but the more you post, the less I like the idea of including it with Python. Please

Re: [Python-Dev] PEP 385: the eol-type issue

2009-08-05 Thread Stephen J. Turnbull
Mark Hammond writes: > I'm not sure what point you are trying to make, but I believe it *is* > possible for a solution to be found here which will keep Windows users > happy. I'm guessing you haven't had much practical experience with this > problem, so probably don't see this is clearly a

Re: [Python-Dev] PEP 385: Mercurial issues

2009-08-05 Thread Stephen J. Turnbull
Oleg Broytmann writes: >Dirkjan, how does Mercurial handles charsets? If I have three files in > my repository - one in utf-8, another in koi8-r, and the third in cp1251 > encoding - I certainly don't want to convert them back and force, but I > want hg web interface to provide charset in

Re: [Python-Dev] PEP 385: Mercurial issues

2009-08-05 Thread Stephen J. Turnbull
"Martin v. Löwis" writes: > > I don't see any good reason for having any encodings but UTF-8 in > > Python's. > > Just in case my previous message gets overlooked: PEP 8 mandates Latin-1 > for Python 2.x source code (except for files that test PEP 263). You're right, sorry for the misinform

Re: [Python-Dev] PEP 385: the eol-type issue

2009-08-05 Thread Stephen J. Turnbull
Mark Hammond writes: > On 6/08/2009 12:28 AM, Stephen J. Turnbull wrote: > > I think the implication is obvious. There will be no good solution > > until Windows users develop it. I don't see a good reason to wait for > > that. > My conclusion is different. I

Re: [Python-Dev] PEP 385: the eol-type issue

2009-08-06 Thread Stephen J. Turnbull
"Martin v. Löwis" writes: > > This is simply false AFAICS. There was little participation on this > > particular issue during PEP 374 that I can recall. Now that it is > > clearly an issue after all, it's still early in the PEP 385 process. > > Martin has already picked up the ball on EOL sup

Re: [Python-Dev] (try-except) conditional expression similar to (if-else) conditional (PEP 308)

2009-08-08 Thread Stephen J. Turnbull
Steven D'Aprano writes: > It's not immediately obvious to me why the last expression should be > given that privileged rule. Why not the first expression? Or the second, for that matter. So find a large body of Lisp code and run "grep -r prog1 | wc", "grep -r prog2 | wc", and "grep -r progn |

Re: [Python-Dev] Mercurial migration: help needed

2009-08-21 Thread Stephen J. Turnbull
Mark Hammond writes: > * Add support for versioned 'filter rules' - eg, /.hgfilters or similar. > > * This might be pushing my luck, but: add 'defensive' support to core hg > for this feature - if /.hgfilters exists, hg should refuse to operate on > the working tree unless the win32text ex

Re: [Python-Dev] Mercurial migration: help needed

2009-08-21 Thread Stephen J. Turnbull
Nick Coghlan writes: > Stephen J. Turnbull wrote: > > Note that Bazaar is currently discussing some similar policies. I > > think the name they have settled on is ".bzrrules". Maybe .hgrules is > > a better name. > > So it would be .hgrules/? Wi

Re: [Python-Dev] Mercurial migration: help needed

2009-08-21 Thread Stephen J. Turnbull
Mark Hammond writes: > Something like ~/.hgrules having: Surely you mean $PROJECTROOT/.hgrules? > [config] # or maybe [rules] ? > required_extensions = win32text, some_pydev_specific_extension [extensions] required_for_commit = win32text,some_other_ext That might require a change to hg's i

Re: [Python-Dev] Mercurial migration: help needed

2009-08-22 Thread Stephen J. Turnbull
Mark Hammond writes: > On 22/08/2009 2:46 PM, Stephen J. Turnbull wrote: > Possibly - although I would expect the existing section names be reused > when applied to a versioned file, I'd be more than happy for the hg guys > to declare new names are appropriate for this. I

Re: [Python-Dev] Mercurial migration: help needed

2009-08-22 Thread Stephen J. Turnbull
Dirkjan Ochtman writes: > [Clients] cannot be trusted (e.g. I might put a win32text stub in > there somewhere that does nothing). Heck, just edit the .hgrules file, and do a Houdini on any and all handcuffs. Don't trust software, trust people -- but help them avoid thoughtless mistakes. __

Re: [Python-Dev] Support for Encrypted Zip as python scripts

2009-08-24 Thread Stephen J. Turnbull
Bugbee, Larry writes: > My original post was intended to increase the awareness in those > thinking encrypted ZIP files will 1) be easy, 2) afford the > protection they desire, and 3) not lead others into a sense of > false security. All good points, but note that (even without the DMCA) at l

Re: [Python-Dev] PEP 3144: IP Address Manipulation Library for the Python Standard Library

2009-08-27 Thread Stephen J. Turnbull
Ben Finney writes: > A pity, since the entire point of Design Patterns is to give us a > vocabulary of terms to use that enable these concepts to be communicated > *without* continually re-defining them. To that extent, then, they fail > their purpose. Of course not! There will always be chi

Re: [Python-Dev] deleting setdefaultencoding iin site.py is evil

2009-08-27 Thread Stephen J. Turnbull
Chris Withers writes: > > How can you be certain that any string is UTF-8 when doing any > > reasonable IO? > > Careful checking, and a knowledge for people working on the app's > development that anything else will result in severe pain, both physical > and mental ;-) If you're *that* c

Re: [Python-Dev] Mercurial migration: help needed

2009-09-05 Thread Stephen J. Turnbull
Antoine Pitrou writes: > > In addition, a DVCS brings in another problem dimension: when people > > push their changes, they have *already* committed them - and perhaps not > > even they, but a contributor from which they had been pulling changes. > > The bogus change may have been weeks ago,

Re: [Python-Dev] hgeol extension (Was: Mercurial migration: help needed)

2009-09-06 Thread Stephen J. Turnbull
"Martin v. Löwis" writes: > This is what I refer to as YAGNI. Subversion has LF as the internal > storage, and, IIRC, so does CVS. I don't think there is any precedence > for wanting something else - and frankly, I can't see how repository > storage would matter. Well, internally you could us

Re: [Python-Dev] Mercurial migration: help needed

2009-09-06 Thread Stephen J. Turnbull
Dirkjan Ochtman writes: > On 05/09/2009 16:59, Stephen J. Turnbull wrote: > > git has a nice filter-branch command, which would allow you to > > automatically repair the problem (it works basically by checking out > > each changeset and rerecording it with the appr

Re: [Python-Dev] Mercurial migration: help needed

2009-09-06 Thread Stephen J. Turnbull
Paul Moore writes: > The result is that user workspaces *may* (quite probably, will) > contain files with a mixture of line endings if care is not taken. Yes. Under your "fixed-EOL-files-are-binary" scheme, this is guaranteed for Unix systems. > As regards (1), I assume that for "text" files

Re: [Python-Dev] PEP 3144 review.

2009-09-15 Thread Stephen J. Turnbull
Antoine Pitrou writes: > Speaking as a non-network specialist, it actually looks logical to > me to be given an address if I iterate over a network (the same way > that, if I iterate on a list, I get individual elements, not > 1-element sublists). But if you iterate over a string you get one

Re: [Python-Dev] PEP 3144 review.

2009-09-15 Thread Stephen J. Turnbull
Scott Dial writes: > ipaddr.IPv4Network('1.1.1.0/24')[0] == ipaddr.IPv4Network('1.1.1.0/24') So foo returns True? def foo(): a = ipaddr.IPv4Network('1.1.1.0/24') return a[0] == a That seems ... weird. Maybe you committed a typo? ___ Python

Re: [Python-Dev] PEP 3144 review.

2009-09-15 Thread Stephen J. Turnbull
I haven't looked closedly at the reference implementation, and my experience is small. So take this as "POLA to the naive new user of the API" discussion. Scott Dial writes: > This example here solidifies my support of RDM's suggestion of there > being 3 types: > > IPv4Address > IP

Re: [Python-Dev] PEP 3144 review.

2009-09-15 Thread Stephen J. Turnbull
Antoine Pitrou writes: > > An IPv4Address with 'network' and 'mask' attributes that could be > > None would also not complicate the API, IMO, and would handle both > > of these use cases. > > But it would be confusing and conceptually bizarre, because an address (in > usually accepted termi

Re: [Python-Dev] PEP 3144 review.

2009-09-16 Thread Stephen J. Turnbull
Andrew McNamara writes: > As the module stands, we have a pair of address-without-mask classes > called *Address, and a pair of address-with-mask classes called > *Network. So, sometimes when you want to record an *address* you use > a class called Network, and that class comes with a behaviou

Re: [Python-Dev] PEP 3144 review.

2009-09-17 Thread Stephen J. Turnbull
Andrew McNamara writes: > Conceptually, you sometimes need a bare address, and other times, > you need an address with an associated network (host interface > configs, router configs, etc). By AddressWithMask, I really mean > AddressWithEnoughInformationToDeriveNetworkWhenNeeded. Conveniently,

Re: [Python-Dev] POSIX [Fuzziness in io module specs]

2009-09-18 Thread Stephen J. Turnbull
Antoine Pitrou writes: > James Y Knight fuhm.net> writes: > > > > Why are you just making things up? There is a *vast* amount of > > precedent for how file operations should work. Python should follow > > that precedent and do like POSIX unless there's a compelling reason > > not to.

Re: [Python-Dev] POSIX [Fuzziness in io module specs]

2009-09-19 Thread Stephen J. Turnbull
Antoine Pitrou writes: > I don't believe that POSIX compliance is a sufficient argument to ask > someone to shut up in the discussion of a cross-platform API. Which is > more or less what James' answer was trying to do. No, as I read it, James said, "when there's precedent, even a standard,

Re: [Python-Dev] Distutils ML wrap-up: setup.cfg new format

2009-09-22 Thread Stephen J. Turnbull
Brett Cannon writes: > OK, stop before it gets any nastier as your email already sounds > rude Rude, yes, but not entirely lacking in truth. Tarek's post to Python- Dev *is* a mess from the point of view of English and organization -- it's *way* below Tarek's normal command of the language. G

Re: [Python-Dev] Distutils ML wrap-up: setup.cfg new format

2009-09-23 Thread Stephen J. Turnbull
Tarek Ziadé writes: > On Wed, Sep 23, 2009 at 9:03 AM, Stephen J. Turnbull > wrote: > > At the very least, that would have kept this discussion on Distutils- > > SIG, and Chris couldn't be accused of trying to make an end run around > > that process.  I suggest

Re: [Python-Dev] PEP 3144 review.

2009-09-27 Thread Stephen J. Turnbull
Antoine Pitrou writes: > There was a proposal to have a separate parse_address_and_mask > method which would return a (Address, Network) tuple, I still don't > know why you don't seem to consider it seriously, rather than > trying to make the Network class a kind of all-in-one type > conflati

Re: [Python-Dev] PEP 3144 review.

2009-09-29 Thread Stephen J. Turnbull
Guido van Rossum writes: > I don't doubt that Peter has a use case for denormalized IPNetwork > objects. If you know what it is, would you please describe it, or say "that's proprietary"? Peter hasn't done either, despite repeated requests. > I do note that if Peter's use case is at all comm

Re: [Python-Dev] PEP 3144 review.

2009-09-29 Thread Stephen J. Turnbull
Let me first say that the module is overall quite nice; the implementation seems concise and very efficient, and the API is well-balanced. I'm sorry there's been such controversy (and for my part in it, as I managed to completely misunderstand what you absolutely require), when AFAICT the only "li

Re: [Python-Dev] PEP 3144 review.

2009-09-29 Thread Stephen J. Turnbull
Greg Ewing writes: > Peter Moody wrote: > > > I've mentioned at least once (and others have mentioned as well) that > > it's very common, when describing the ip address/prefix of a NIC to > > write, "192.168.1.100/24" > > Yes, but if you want to *retain* all of that information, > the obj

Re: [Python-Dev] PEP 3144 review.

2009-09-29 Thread Stephen J. Turnbull
Peter Moody writes: > >  > this is interesting. I would be open to doing this and making __lt__, > >  > __gt__, __eq__ and friends do the non-ip comparing by default. would > >  > this be sufficient or does the fact that the network has the .ip > >  > attribute break something pythonic? > >

Re: [Python-Dev] PEP 3144 review.

2009-09-30 Thread Stephen J. Turnbull
Mark Dickinson writes: > >> Please could someone who understands the uses of IPNetwork > >> better than I do explain why the following wouldn't be a > >> significant problem, if __eq__ and __hash__ were modified to > >> disregard the .ip attribute as suggested: > > linus = IPv4Network('1

Re: [Python-Dev] PEP 3144 review.

2009-09-30 Thread Stephen J. Turnbull
Daniel Stutzbach writes: > People have voiced support for the IPNetwork class The obvious use cases are 1. parsing and validating strings that purport to describe networks, 2. providing a received for the result of a function that deduces the network from an arbitrary address and a mask

Re: [Python-Dev] PEP 3144 review.

2009-10-02 Thread Stephen J. Turnbull
Nick Coghlan writes: > However, while I'd still be a little happier if the .ip attribute > went away all together and another means was found to conveniently > associate an IPAddress and an IPNetwork, keeping it doesn't bother > me anywhere near as much as having network equivalence defined in

Re: [Python-Dev] Package install failures in 2.6.3

2009-10-05 Thread Stephen J. Turnbull
Tarek Ziadé writes: > Maybe I should blog a summary of the situation and post it to > python annoucement as well. Please don't. It's unlikely to do anything except incite a lot of flames. ___ Python-Dev mailing list Python-Dev@python.org http://mail

[Python-Dev] comments vs spam in PyPI [was: eggs now mandatory for pypi?]

2009-10-05 Thread Stephen J. Turnbull
Antoine Pitrou writes: > Guido van Rossum python.org> writes: > > > > There are plenty of things we > > can learn about fighting spam and other forms of vandalism from other > > areas of the social web, including our very own wiki, and other wikis > > (WikiPedia survives despite spam). >

[Python-Dev] Top-posting on this list

2009-10-10 Thread Stephen J. Turnbull
Brett Cannon writes: > On Fri, Oct 9, 2009 at 11:32, Michael Foord wrote: > > Sorry for top-posting, mobile device. Michael, I for one *very much* appreciate your courtesy. > Aahz was the most adamant hater of top-posting and he isn't subscribed to > python-dev anymore, so whatever. Please

Re: [Python-Dev] Top-posting on this list

2009-10-10 Thread Stephen J. Turnbull
Greg Ewing writes: > That's no reason to squander it, though. Quoting the entire > message every time makes the size of the thread grow as > O(n**2), Agreed, but let's not exaggerate. Threads are finite, so big O is not really relevant. Spam OTOH is boundless, and that's where the bandwidth

Re: [Python-Dev] Top-posting on this list

2009-10-11 Thread Stephen J. Turnbull
Ben Finney writes: > "Stephen J. Turnbull" writes: > > > Trimming can be a PITA if you're using a crummy MUA > > How so? It merely requires the ability to navigate up and down by lines, > and to select and delete text. I've used some very crumm

Re: [Python-Dev] Python Package Management Roadmap in Python Releases

2009-10-21 Thread Stephen J. Turnbull
David Lyon writes: > On Wed, 21 Oct 2009 18:38:26 -0700, Brett Cannon wrote: > > David, you are making a huge leap here thinking that we even want > > a package manager in the stdlib. > > Well - who is 'we'? If it's python-dev people I can accept and > respect that. Yes. The stdlib is a

Re: [Python-Dev] language summit topic: issue tracker

2009-10-23 Thread Stephen J. Turnbull
Antoine Pitrou writes: > Besides, the more keywords there are, the messier it is. That's what I've found in the XEmacs tracker. Keywords are a reasonable way (in the context of the Roundup implementation) to test new classifications before going to the effort of messing with the page templates.

Re: [Python-Dev] First shot at some_set.get()

2009-10-23 Thread Stephen J. Turnbull
Steven D'Aprano writes: > I'm not being tongue-in-cheek or sarcastic. My question was serious -- > if there is a moratorium, is there any reason to bother submitting > patches for functional changes to built-ins? Yes. Python is open source. Private and public forks are possible and (at lea

Re: [Python-Dev] Retrieve an arbitrary element from a set without removing it

2009-10-23 Thread Stephen J. Turnbull
Ben Finney writes: > Steven D'Aprano writes: > > "get" is such a generic term that I don't believe that is a problem. > > The problem above is made less problematic by the fact that the function > signature (e.g. 'foo_dict.get(key)') clarifies the answer to the > question "get what?". Wher

Re: [Python-Dev] Retrieve an arbitrary element from a set without removing it

2009-10-26 Thread Stephen J. Turnbull
"Martin v. Löwis" writes: > > res.get() would be a fairly obvious way to do it. Enough that I would > > probably never have gone searching for any of the other answers. Though > > personally, I think I would call it "set.peek()", but the specific name > > doesn't really matter to me. > > So

Re: [Python-Dev] Retrieve an arbitrary element from a set without removing it

2009-10-28 Thread Stephen J. Turnbull
geremy condra writes: > On Wed, Oct 28, 2009 at 12:34 PM, average wrote: > > [I wrote:] > >> If Python3 were to have this feature it would make it worth > >> migrating to > > > > Sorry that may have sounded more harsh than I expected.  If I had more > > resources, > This is effectively th

Re: [Python-Dev] Retrieve an arbitrary element from a setwithoutremoving it

2009-10-30 Thread Stephen J. Turnbull
Steven D'Aprano writes: > The usual technique people tend to come up with is: > > x = s.pop() > s.add(x) > > Which strikes many people (including myself) as inelegant. Surely "get > an element" is a more fundamental operation than "get an element and > remove it"? Not in a literal urn

Re: [Python-Dev] PEP 3003 - Python Language Moratorium

2009-11-03 Thread Stephen J. Turnbull
Guido van Rossum writes: > On Tue, Nov 3, 2009 at 11:23 AM, M.-A. Lemburg wrote: > > One question: > > > > There are currently number of patch waiting on the tracker for > > additional Unicode feature support and it's also likely that we'll > > want to upgrade to a more recent Unicode versi

Re: [Python-Dev] PEP 3003 - Python Language Moratorium

2009-11-07 Thread Stephen J. Turnbull
~b <4222a8490911051521r1b9c8165id6e0f12d62da0...@mail.gmail.com> <48c184130911051555r9a5b78cs3a13cb1345d3c...@mail.gmail.com> <20091106001430.3229.796306500.divmod.xquotient@localhost.localdomain> <4af3cf69.6090...@gmx.net> <20091

Re: [Python-Dev] Replacing IDLE

2009-11-10 Thread Stephen J. Turnbull
anatoly techtonik writes: > Does that mean even if authors of some imaginary editor agree to > incorporate their code into Python, the framework that it is built > upon will have to be incorporated into Python also (and eventually > abandoned at original location)? I would assume so. How els

Re: [Python-Dev] Too many Python accounts

2009-11-14 Thread Stephen J. Turnbull
Ben Finney writes: > I would make a bug report for that, but the Python bug tracker also > requires yet-another-identity. It's lunacy. No, it's legacy. The software predates the availability of OpenID. If you'd like to integrate Open ID authentication into Roundup, I will personally be happy

Re: [Python-Dev] First draft of "sysconfig"

2009-12-16 Thread Stephen J. Turnbull
David Lyon writes: > I'm not star-gazing, because all these things are already > needed and already being done to some degree in some > organisations. There's already the libraries on pypi for > most of this anyway. Sure. But in a volunteer project, it's beg, buy, or build. Begging has not

Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2

2009-12-23 Thread Stephen J. Turnbull
David Lyon writes: > > I am just describing the needs and the end user PoV with the reference > > implementation that happens to be used by *all* tools out there. > > That's good. That's what we need right now. Martin's point is that the PEP process doesn't *have* "reference" implementations

Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2

2009-12-27 Thread Stephen J. Turnbull
Ben Finney writes: > Instead, the default should be `=='. That is, `Requires-Python: 3' > should be equivalent to `Requires-Python: ==3'; and only "3" or "3.0" or > "3.0.0" etc. will match. I maintain that is what most people will expect > on seeing that syntax. I really don't think your asse

Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2

2009-12-27 Thread Stephen J. Turnbull
david.l...@preisshare.net writes: > >> Before we had : Requires-Python: 2.5, 2.6 > >> > >> That made much more sense. It was simple and unambiguous, and is > >> relevant to typical packaging scenarios. > > > > Unfortunately, it is fairly ambiguous, and makes no sense. It means > > "requires

Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2

2009-12-27 Thread Stephen J. Turnbull
david.l...@preisshare.net writes: > With respect, it's not a very common use case for a developer to > say that package needs a python interpretor 'older' than 2.5. Of course it is. I don't claim it is the majority of cases out there, but stable versions of many of the packages I use will spec

Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2

2009-12-28 Thread Stephen J. Turnbull
Antoine Pitrou writes: > > > And in fact this case is often more the important one. Packages that > > depend on having a *recent* version of python will often crash > > quickly, before doing permanent damage, when an undefined syntax, > > function, or method is invoked, while packages that d

Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2

2009-12-28 Thread Stephen J. Turnbull
Antoine Pitrou writes: > > > > How can they know that they depend on "a quirk in behaviour of an older > > > version" if a newer version hasn't been released? This sounds bogus. > > > > Of course a newer version has been released. Who said it hasn't been? > > Eg, the discussion of <=2.5.

Re: [Python-Dev] Improve open() to support reading file starting with an unicode BOM

2010-01-07 Thread Stephen J. Turnbull
Guido van Rossum writes: > I'm a little hesitant about this. First of all, UTF-8 + BOM is crazy > talk. That doesn't stop many applications from doing it. Python should perhaps not produce UTF-8 + BOM without a disclaimer of indemnification against all resulting damage, signed in blood, from t

Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2

2010-01-11 Thread Stephen J. Turnbull
Neil Schemenauer writes: > On Sun, Jan 10, 2010 at 09:06:15PM -0800, Brett Cannon wrote: > > If people start taking the carrots we have added to 3.x and > > backporting them to keep the 2.x series alive you are essentially > > making the 3.x DOA by negating its benefits which I personally > >

Re: [Python-Dev] Bazaar branches available (again) on Launchpad

2010-01-20 Thread Stephen J. Turnbull
Barry Warsaw writes: > (Besides, git in the stdlib doesn't make much sense :). "Dulwich." ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-d

Re: [Python-Dev] Proposed downstream change to site.py in Fedora (sys.defaultencoding)

2010-01-24 Thread Stephen J. Turnbull
Michael Foord writes: > This is why I'm keen that by *default* Python should honour the UTF8 > signature when reading files; Unfortunately, your caveat about "a lot of the time it will *seem* to work" applies to this as well. The only way that "honoring signatures" really works is if Python

Re: [Python-Dev] Proposed downstream change to site.py in Fedora (sys.defaultencoding)

2010-01-24 Thread Stephen J. Turnbull
Michael Foord writes: > When reading text files the presence of the UTF-8 signature *almost > invariably* means a UTF-8 encoding. Honouring this will almost always be > better than using the wrong encoding. Of course there are caveats, but > it will be a substantial improvement. Sure, that

Re: [Python-Dev] Proposed downstream change to site.py in Fedora (sys.defaultencoding)

2010-01-24 Thread Stephen J. Turnbull
Antoine Pitrou writes: > Perhaps you are speaking with your emacs hat, where the purpose is > to output to the same file that serves as input. No, I'm not wearing my Emacs hat. If I was, there would be no problem. You just use binary for most such purposes. Historically that was how even Ema

Re: [Python-Dev] Proposed downstream change to site.py in Fedora (sys.defaultencoding)

2010-01-24 Thread Stephen J. Turnbull
Antoine Pitrou writes: > Stephen J. Turnbull xemacs.org> writes: > > > > But it *does* determine the charset of ErrorDocuments displayed by > > Apache. Users are likely to get somewhat confused if the > > ErrorDocuments are in a different charset from your

Re: [Python-Dev] Proposed downstream change to site.py in Fedora (sys.defaultencoding)

2010-01-24 Thread Stephen J. Turnbull
"Martin v. Löwis" writes: > My bet is that the majority of Python applications written today do > "web" stuff. In the web, input encoding and output encoding are > fairly decorrelated - in particular for databases and files read > from disk. Sure. Which means that programmers have to do a lo

Re: [Python-Dev] patch to make list.pop(0) work in O(1) time

2010-01-29 Thread Stephen J. Turnbull
Josiah Carlson writes: > Lisp lists are really stacks No, they're really (ie, concretely) singly-linked lists. Now, stacks are an abstract data type, and singly-linked lists provide an efficient implementation of stacks. But that's not what linked lists "really are". For example, singly-lin

Re: [Python-Dev] patch to make list.pop(0) work in O(1) time

2010-01-29 Thread Stephen J. Turnbull
Josiah Carlson writes: > On Thu, Jan 28, 2010 at 8:57 PM, Steve Howell wrote: > > What do you think of LISP, and "car" in particular (apart from > > the stupidly cryptic name)? > Apples and oranges. True, but speaking of Lisp lists, here's some possibly relevant experience. About 10 years

Re: [Python-Dev] patch to make list.pop(0) work in O(1) time

2010-01-30 Thread Stephen J. Turnbull
Josiah Carlson writes: > On Fri, Jan 29, 2010 at 11:31 PM, Stephen J. Turnbull > wrote: > > Some people complained, but we considered this well worthwhile (moving > > one "type bit" from the car to the header allowed Lisp integers to > > cover the

Re: [Python-Dev] patch to make list.pop(0) work in O(1) time

2010-01-30 Thread Stephen J. Turnbull
Minor erratum: Stephen J. Turnbull writes: > Emacs hasn't made that choice, XEmacs did. I believe Emacs is still > "restricted" to 128MB, or maybe 256MB, buffers. They recently had an > opportunity to increase integer size, and thus maximum buffer size, > but

Re: [Python-Dev] Reworking the GIL

2010-02-02 Thread Stephen J. Turnbull
Antoine Pitrou writes: > Yes, I hindsight I think Guido was right. Guido does too. One of the benefits of having a time machine is getting to turn your hindsight into foresight. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org

Re: [Python-Dev] Python 2.6.5

2010-02-10 Thread Stephen J. Turnbull
Antoine Pitrou writes: > Besides, as Barry said, classifying a bug as blocker is also a good way > to attract some attention on it. Other classifications, even "critical", > don't have the same effect. If done for the sole purpose of attracting attention, it's no different from spam. Opinions

<    3   4   5   6   7   8   9   10   11   12   >