Re: [Python-Dev] Import and unicode: part two

Toshio Kuratomi writes: > On Linux there's no defined encoding that will work; file names are just > bytes to the Linux kernel so based on people's argument that the convention > is and should be that filenames are utf-8 and anything else is > a misconfigured system -- python should mandate th

Re: [Python-Dev] Import and unicode: part two

Toshio Kuratomi writes: > Sure ... but with these systems, neither read-modules-as-locale or > read-modules-as-utf-8 are a good solution to work, correct? Good solution, no, but I believe that read-modules-as-locale *should* work to a great extent. AFAIK Python 3 reads Python programs as str (

Re: [Python-Dev] MSI: Remove dependency from win32com.client module (issue4080047)

anatoly techtonik writes: > I'll abandon my efforts when you prove me that current "documented > process" is a top-notch way for all interested parties to do a quality > contributions to make Python better. I think the product of the process speaks very well for the process. > The most valua

Re: [Python-Dev] Finally fix installer to add Python to %PATH% on Windows

Paul Moore writes: > "Before any existing Python directories, otherwise at the end" is the > closest to what I suspect most users want (certainly it matches my > preferences, and anything else would have me manually editing PATH > anyway, so is of no use to me in practice). Unfortunately, wha

Re: [Python-Dev] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py

Antoine Pitrou writes: > Would that be a Mapping or a Sequence? Sure it would be nowhere near as predictable as a Mapping or Sequence, so Isuppose it would be a Container ... although the probability of OverflowException is near 1. ___ Python-Dev maili

[Python-Dev] Strange error importing a Pickle from 2.7 to 3.2

Jesus Cea writes: > PPS: If there is consensus that this is a real bug, I would create an > issue in the tracker and try to get a minimal testcase. All bugs are issues, but not all issues are bugs. Please don't wait for consensus or even a second opinion to file the issue. It's reasonable for

Re: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2

Jesus Cea writes: > Every time I read a message from [long, incomplete list] and > so many others python-devs (not an exhaustive list, if you are not > there, you probably should, sorry :), I feel I am faking my > knowledge of Python :-). I am a pretender :). Sure. I suspect even some of tho

Re: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2

M.-A. Lemburg writes: > "Latin-1" is short for "Latin Alphabet No. 1" [...]. > I assume that since the HTML standard used the more popular > name "Latin-1" for its definition of the default character set > and also made use of the term throughout the spec, it > became the de-facto standard n

Re: [Python-Dev] Mercurial conversion repositories

Barry Warsaw writes: > You mean, TortoiseHg supports incremental commits on a single file? That's > kind of neat, but scary. ;) Darcs people have been doing this for, well, for as long as Darcs has existed. It's not scary at all. In fact, in Darcs you can select hunks across files, too. __

Re: [Python-Dev] contributors survey?

Antoine Pitrou writes: > Following the example given in the original article, I was considering > a single freeform question: "why did you stop contributing after your > last patch to CPython?" (of course, that text should be decorated with > a greeting and an introduction and the wording can

[Python-Dev] hg diff

"Martin v. Löwis" writes: > It seems that the dev guide recommends to use the --git option in hg > diff. I'm working on the Rietveld integration, and found that this > option makes things worse: the regular diff includes the base revision > of the patch; hg diff --git doesn't. Does the regular

Re: [Python-Dev] hg diff

"Martin v. Löwis" writes: > Am 07.03.2011 02:24, schrieb Stephen J. Turnbull: > > "Martin v. Löwis" writes: > > > It seems that the dev guide recommends to use the --git option in hg > > > diff. I'm working on the Rietveld integratio

Re: [Python-Dev] hg diff

Barry Warsaw writes: > I hear this complaint [about branches being no help in reviewing] a > lot from hg and git users, so maybe it's just the nature of the > tools. In which case, I'm fine with whatever works better for > Python. First, let me remind you that PEP 374 was quite clear about o

Re: [Python-Dev] hg diff

"Martin v. Löwis" writes: > > However, as Michael points out, you can have your tools generate the > > patch. For example, it shouldn't be too hard to add a dynamic patch > > generator to Roundup (although I haven't thought about the UI or the > > CPU burden). > For Mercurial, that's more d

Re: [Python-Dev] hg diff

"Martin v. Löwis" writes: > > Doesn't "hg diff -r 'ancestor(branch,default)::branch'", where "branch" > > is the unmerged branch you would like to inspect, do the right thing? > > What would I specify as "branch" if all I have is > "http://bitbucket.com/turnbull/foo";, and know that it must

Re: [Python-Dev] hg diff

"Martin v. Loewis" writes: > > I’m of the opinion that hg diffs should always use the extended git > > format, given their usefulness. A tool working with hg diffs that does > > not support this format is broken IMO. > > IMO, it's "hg diff --git" that's broken, as it doesn't include the base

Re: [Python-Dev] GPL'd python code vs Python2.6 linked against OpenSSL

Joao S. O. Bueno writes: > Any libraries commonly avaliable with a CPython instalation can be > considered as "system libraries" for GPL purposes - and so > this would fall in the "system library exception" as described by the FAQ: Note that your interpretation would allow Python to distribute

Re: [Python-Dev] GPL'd python code vs Python2.6 linked against OpenSSL

Westley Martínez writes: > Is it legal to distribute GPL programs that use the Win32 API? Yes. Their use of the Win32 API falls under the "essential system library" clause. The criterion for "essential" is that normal, basic use of the system would fail without the library. Windows won't boot

Re: [Python-Dev] GPL'd python code vs Python2.6 linked against OpenSSL

"Martin v. Löwis" writes: > Note that it is ultimately up to a court to interpret these words of the > GPL, not to the FSF lawyer. True, and in the case of a non-FSF product, any ambiguities would be resolved first by determining the intent of the copyright owner, second (perhaps even overridin

Re: [Python-Dev] Using feature branches for local development

On Sun, Mar 13, 2011 at 8:25 PM, Nick Coghlan wrote: > 1. While the feature branches are active, is it correct that I can't > use a bare "hg push" any more, since I don't want to push the feature > branches to hg.python.org? Instead, I need to name all the branches I > want to push explicitly. M

Re: [Python-Dev] Using feature branches for local development

On Sun, Mar 13, 2011 at 9:05 PM, Nick Coghlan wrote: > On Sun, Mar 13, 2011 at 7:56 AM, Stephen J. Turnbull > wrote: >> You may *want* to do that, but hg branch obsolete-branch; >> hg commit -m "I'm done" --close should also do the trick of getting >

Re: [Python-Dev] Using feature branches for local development

On Sun, Mar 13, 2011 at 9:32 PM, Eli Bendersky wrote: > The way to do this, IMHO, is just create a local clone and work on it. Then > you can keep checking partial changes in without ever worrying about > accidentally modifying the official repo. Especially if some of this work is > experimental

Re: [Python-Dev] Generating patch files

On Thu, Mar 17, 2011 at 5:00 AM, Ned Deily wrote: > In article <4d810f84.5060...@v.loewis.de>, >  "Martin v. Löwis" wrote: >> Before you upgrade: give me some time to come up with a script that >> uses Mercurial API instead to compute the revset and then invoke the >> diff command. >> >> We must

Re: [Python-Dev] Hg: inter-branch workflow

On Sat, Mar 19, 2011 at 12:22 PM, Jesus Cea wrote: > On 19/03/11 03:14, Nick Coghlan wrote: >> (i.e. start moving towards more of a style of development where code >> doesn't land in the main repository until it has been vetted by the >> buildbots *first*). Unfortunately, this is *not* good enou

Re: [Python-Dev] I am now lost - committed, pulled, merged, what is "collapse"?

Jesus Cea writes: > I think we are doing some antipatterns with our current approach, > battling the tools instead of "joining them". Yes. That is deliberate; see PEP 0374. I admit I personally didn't foresee the issues Nick describes with the flow of patches from one branch to another. Also

Re: [Python-Dev] Hg: inter-branch workflow

Thomas Wouters writes: > On Sun, Mar 20, 2011 at 17:59, Georg Brandl wrote: > > On 20.03.2011 16:50, Thomas Wouters wrote: > > > On Sun, Mar 20, 2011 at 17:39, Georg Brandl > > > wrote: > > > > > > The reason why rebasing is not universally applied is that the >

Re: [Python-Dev] I am now lost - committed, pulled, merged, what is "collapse"?

s...@pobox.com writes: > Stephen> interactions across modules. That is, it's not that Subversion > Stephen> provided a simpler way of doing the work. Rather, it hid the > Stephen> fact that certain work was not being done at all. hg exposes > Steph

Re: [Python-Dev] I am now lost - committed, pulled, merged, what is "collapse"?

R. David Murray writes: > On Mon, 21 Mar 2011 14:07:46 +0900, "Stephen J. Turnbull" > wrote: > > No, at best the DVCS workflow forces the developer on a branch to > > merge and test the revisions that will actually be added to the > > repository, and per

Re: [Python-Dev] I am now lost - committed, pulled, merged, what is "collapse"?

"Martin v. Löwis" writes: > > My understanding is that svn does not detect fast forwards, only lack > > of conflicts, and therefore in case of concurrent development it is > > possible that the repository contains a version that never existed in > > any developer's workspace. > > I can't und

Re: [Python-Dev] I am now lost - committed, pulled, merged, what is "collapse"?

s...@pobox.com writes: > I believe it runs counter to the professed intention of the switch > away from a centralized version control system, to make it easier > for more people to contribute to Python. It certainly seems harder > for this old dog. Well, you may be an old dog, but you're als

Re: [Python-Dev] I am now lost - committed, pulled, merged, what is "collapse"?

Barry Warsaw writes: > Actually, I meant something like 'bzr checkout': No. Of the DVCSes, only bzr has that. > This would allow individual developers to treat the repository in a > centralized way like they did for svn, but still allowing other > developers to work in a distributed way. I

Re: [Python-Dev] I am now lost - committed, pulled, merged, what is "collapse"?

R. David Murray writes: > The workflow in svn "can" "require" this same thing: before committing, > you do an svn up and run the test suite. No, it can't. That's not good enough, if you care about tree-wide consistency, because svn's approach has a race condition. You say you don't care, but

Re: [Python-Dev] Hg: inter-branch workflow

"Martin v. Löwis" writes: > Not if the changes you want to suppress are actually also on the same > branch as the one whose mainline you are trying to see (which they > typically are, with the branch typically being "default"). There is no "also on" with Mercurial named branches. Every commit

Re: [Python-Dev] Hg: inter-branch workflow

Ben Finney writes: > As a user of Bazaar primarily, that's addressing the problem in the > wrong place: why rewrite *my* history, which is useful to me as is, when > the other person is using Bazaar and so doesn't see revisions they don't > care about? Speaking for myself, I rewrite my git hi

Re: [Python-Dev] Hg: inter-branch workflow

"Martin v. Löwis" writes: > Am 22.03.2011 02:02, schrieb Eugene Toder: > >> Not if the changes you want to suppress are actually also on the same > >> branch as the one whose mainline you are trying to see (which they > >> typically are, with the branch typically being "default"). > > > > Rig

[Python-Dev] Workflow proposal

Executive summary: If we're really serious about serializing the public branches, mq seems to be the way to go. Jesus Cea writes: > 6. Use "hg strip" (dangerous!) to delete the local merges to 3.2 and > "default". Leave the original commit in "3.1" alone. I would suggest "hg strip --keep" whi

Re: [Python-Dev] I am now lost - committed, pulled, merged, what is "collapse"?

s...@pobox.com writes: > > Stephen> This won't be pleasant if people are sprinting and lots of > Stephen> commits are coming, because you're likely to repeatedly lose > Stephen> the push race. But in those conditions, nothing is guaranteed >

Re: [Python-Dev] Workflow proposal

Antoine Pitrou writes: > Now, "hg strip" should definitely be absent of any recommended or even > suggested workflow. It's a power user tool for the experimented > developer/admin. Not the average hg command. So what you're saying is that Mercurial by itself can't support the recommended workf

Re: [Python-Dev] sprints and pushes

Tres Seaver writes: > On 03/23/2011 01:24 PM, Antoine Pitrou wrote: > > On Wed, 23 Mar 2011 10:25:01 -0700 > > Ethan Furman wrote: > >> > >> I think the use-case has been lost. Think sprints and multiple push > >> races. I do, can't speak for others. So what? *sigh* ... read on. > > W

Re: [Python-Dev] Trimming the fat from "make quicktest" (was Re: I am now lost - committed, pulled, merged, what is "collapse"?)

Nick Coghlan writes: > (i.e. less than a minute) because you're going to be running it three > times in quick succession (perhaps 3 if it applies to 2.7 as well). Nobody says it's got to be *you* that runs the tests, just that they need to be run before pushing to public repo. Here's a simple

Re: [Python-Dev] sprints and pushes

Tres Seaver writes: > > > > Well, keep in ming hg is a *distributed* version control system. You > > > > don't have to push your changes right now. > > > That doesn't work so well at a sprint, where the point is to maximize > > > the value of precious face-time to get stuff done *now*. >

Re: [Python-Dev] sprints and pushes

Tres Seaver writes: > That was precisely my proposal: Sorry about that. I live in a disaster area, and was limited to GMail until two days ago, and lost a fair amount of context in the switch back. ___ Python-Dev mailing list Python-Dev@python.org ht

Re: [Python-Dev] Please revert autofolding of tracker edit form

Ethan Furman writes: > -1 on reverse time sequence of messages -- no top posting! ;) I'd really like this to be a browse-time option, and for bonus points, it should be "sticky". For issues I'm not familiar with, I want to read in more or less chronological order. For issues I *am* familiar w

Re: [Python-Dev] Releases for recent security vulnerability

Gustavo Narea writes: > Well, that's a long shot. I doubt the people/organizations affected are > all aware. That's really not Python's responsibility. That's theirs. Caveats: Python should have a single place where security patches are announced *first*, before developer blogs and the like.

Re: [Python-Dev] Releases for recent security vulnerability

Nick Coghlan writes: > I'd personally like to see a couple of adjustments to > http://www.python.org/news/security/: For another thing, it needs to be more discoverable. For yet another thing, it has two ancient entries on it. Surely there are more than that?

Re: [Python-Dev] PyObject_RichCompareBool identity shortcut

Glenn Linderman writes: > I would not, however expect the original case that was described: > >>> nan = float('nan') > >>> nan == nan > False > >>> [nan] == [nan] > True # also True in tuples, dicts, etc. Are you saying you would expect that >>> nan = float('nan') >>> a

Re: [Python-Dev] PyObject_RichCompareBool identity shortcut

Mark Dickinson writes: > Declaring that 'nan == nan' should be True seems attractive in > theory, No, it's intuitively attractive, but that's because humans like nice continuous behavior. In *theory*, it's true that some singularities are removable, and the NaN that occurs when evaluating at t

Re: [Python-Dev] PyObject_RichCompareBool identity shortcut

Glenn Linderman writes: > On 4/27/2011 6:11 PM, Ethan Furman wrote: > > Totally out of my depth, but what if the a NaN object was allowed to > > compare equal to itself, but different NaN objects still compared > > unequal? If NaN was a singleton then the current behavior makes more > > s

Re: [Python-Dev] the role of assert in the standard library ?

Tarek Ziadé writes: > On Thu, Apr 28, 2011 at 5:26 PM, Barry Warsaw wrote: > > BTW, I think it always helps to have a really good assert message, and/or a > > leading comment to explain *why* that condition can't possibly happen. > > why bother, it can't happen ;) Except before breakfast,

Re: [Python-Dev] PyObject_RichCompareBool identity shortcut

Steven D'Aprano writes: > (I grant that Alexander is an exception -- I understand that he does do > a lot of numeric work, and does come across NANs, and still doesn't like > them one bit.) I don't think I'd want anybody who *likes* NaNs to have a commit bit at python.org. __

Re: [Python-Dev] Not-a-Number (was PyObject_RichCompareBool identity shortcut)

Terry Reedy writes: > > Python treats it as if it were a number: > > As I said, so did the committee, and that was its mistake that we are > more or less stuck with. The committee didn't really have a choice. You could ask that they call NaNs something else, but some bit pattern is going t

Re: [Python-Dev] Linus on garbage collection

Mark Shannon writes: > > > Neal Becker wrote: > > http://gcc.gnu.org/ml/gcc/2002-08/msg00552.html > > > Being famous does not necessarily make you right. No, but being a genius sure helps you beat the odds. > OS kernels are pretty atypical software, > even if Linus is right about Linux

Re: [Python-Dev] Commit changelog: issue number and merges

R. David Murray writes: > On Mon, 09 May 2011 18:23:45 -0500, Benjamin Peterson > wrote: > > *cough* http://mercurial.selenic.com/wiki/GraphlogExtension > > I'm sorry, but I've looked at the output of that and the mental overhead > has so far proven too high for it to be of any use to me.

Re: [Python-Dev] Python 3.x and bytes

Robert Collins writes: > Its probably too late to change, but please don't try to argue that > its correct: the continued confusion of folk running into this is > evidence that confusion *is happening*. Treat that as evidence and > think about how to fix it going forward. Sorry, Rob, but you'

Re: [Python-Dev] Python 3.x and bytes

Robert Collins writes: > Thats separate to the implementation issues I have mentioned in this > thread and previous. Oops, sorry. Nevertheless, I personally think that b'a'[0] == 97 is a good idea, and consistent with everything else in Python. It's Unicode (str) that is weird, it's str is su

Re: [Python-Dev] Stable buildbots update

Tarek Ziadé writes: > I have now completed the cleanup and we're back on green-land for the > stable bots. Are you saying you expect Mac OS X 10.4 "Tiger" to go green once the bots update? If so, I'm impressed, and "thank you!" to all involved. Apple and MacPorts have long since washed their h

Re: [Python-Dev] The socket HOWTO

exar...@twistedmatrix.com writes: > However, does that really have anything to do with improving the socket > howto? Thank you! > The Python documentation can include a clear explanation of what > functionality the socket module provides - without forcing you to read > Stevens _or_ use T

Re: [Python-Dev] The socket HOWTO

Antoine Pitrou writes: > Did you run a user survey? Martin undoubtedly has a lot of experience with users, and it's quite reasonable for him to express his opinions based on that informal sample, yes. The issue here is the difference between existential and universal quantifiers. Martin's argu

Re: [Python-Dev] The socket HOWTO

Antoine Pitrou writes: > So did you read the discussion before posting? Yes. It's rude to assume that those who disagree with you are irresponsible and uninformed. Would you please stop it? > The sockets HOWTO *doesn't* serve both groups. > Actually, I would argue that it serves neither of

Re: [Python-Dev] is anyone using Misc/RPM?

Benjamin Peterson writes: > I should qualify: We shouldn't distribute distribution-specific files > for which we don't provide binaries. Probably it belongs in a "contrib" area of the tree, but one of the things I find really annoying about distros is the way they refuse to use my perfectly goo

Re: [Python-Dev] Python 3.x and bytes

Ethan Furman writes: > Using this method, my code now looks like: > > # constants [...] > This is not beautiful code. Put mascara on a pig, and you have a pig with mascara on, not Bette Davis. I don't necessarily think you're doing anybody a service by making the hack of using ASCII bytes

Re: [Python-Dev] Issue10403 - using 'attributes' instead of members in documentation

Nick Coghlan writes: > And no, the fact that methods can be treated as attributes is not a > minor detail. It is *fundamental* to Python's object model that > *methods are not a special case of attribute access*. That's ambiguous. I assume you mean "just a case of attribute access, and not sp

Re: [Python-Dev] [Python-checkins] cpython: Remove mention of medical condition from the test suite.

Jim Jewett writes: > If you're going to get rid of the pun, you might as well change the > whole sentence... In fact, he should, since this is such a well-known pun that many people will consciously make the reverse substitution, and wonder WTF python-dev was thinking when they put the amended

Re: [Python-Dev] [Python-checkins] cpython: Remove mention of medical condition from the test suite.

Antoine Pitrou writes: > I sincerely hope we don't start using the word "professional" to denote > "careful" or "good quality". No, by "professional" I mean "of a profession," which is a service that is provided by experts to laymen, and therefore demands adherence to certain standards since th

Re: [Python-Dev] [Python-checkins] cpython: Remove mention of medical condition from the test suite.

Antoine Pitrou writes: > On Wed, 06 Jul 2011 01:23:55 +0900 > "Stephen J. Turnbull" wrote: > > Antoine Pitrou writes: > > > > > I sincerely hope we don't start using the word "professional" to denote > > > "careful

Re: [Python-Dev] [Python-checkins] cpython: #665194: support roundtripping RFC2822 date stamps in the email.utils module

R. David Murray writes: > Hexlify, wormaround...our Barry is just full of interesting words :) Not "full" at all---there's no there there to put them in. He's a generator! The FLUFL-always-uses-efficient-idioms-ly y'rs, ___ Python-Dev mailing list Py

Re: [Python-Dev] New update to PEP397 - Python launcher for Windows

Glenn Linderman writes: > I note in passing that '/usr/bin/env python' is hard-coded in the > launcher, which conforms to the above documentation. A single character (space or tab) is also hard-coded in Emacs's python-mode. > But there is no hard requirement in Unix, if I correctly understan

Re: [Python-Dev] Comments of the PEP 3151

Antoine Pitrou writes: > > Did someone test Blender, Django or another major applications on the > > implementation of the PEP 3151? > > Does Django have a working Python 3 port yet? Define "working". Martin ported Django to Python 3 years ago as proof of concept, but never claimed it was r

Re: [Python-Dev] Comments of the PEP 3151

Glenn Linderman writes: > Sorry, no. "InterruptError" sounds too much like a CPU interrupt > signal, which the error is not. "InterruptedError" is OK by me, I don't > see the confusion you do. But maybe "InterruptedOperationError" would > be the most clear. Way too long, of course, so m

Re: [Python-Dev] The docs, reloaded

Neal Becker writes: > Perhaps my comment was misunderstood. I have no objection to a new system, > and it does not have to be based on latex. I just hope there will be some > escape mechanism that allows math. Docutils already provides the "raw" directive. I don't know if the latex backend

Re: [Python-Dev] The docs, reloaded

Armin Ronacher writes: > rst is simpler than latex: > > LaTeX: > > \item[\code{*?}, \code{+?}, \code{??}] The \character{*}, > \character{+}, and \character{?} qualifiers are all \dfn{greedy}; they > match as much text as possible. Sometimes this behaviour isn't > desired; if the RE \re

Re: [Python-Dev] Subversion branch merging

Dave Harrison writes: > While I can't claim to have spent alot of time with DARCS, my > experience was that it took a fair whack of unintuitive pain to work > out how to extract a patch that I could send upstream to be submitted > to a project. This doesn't seem to be a common issue with Darc

Re: [Python-Dev] Typo in itertools.dropwhile()

Raymond Hettinger writes: > [Matthieu on itertools.dropwhile() docs] > > Note, the iterator does not produce any output until the > > predicate is true > it did return EVERY element from the first false Shouldn't the "until" in the doc be "while"? Alternatively, "true" could be changed to

Re: [Python-Dev] Subversion branch merging

Dave Harrison writes: > > Unfortunately, rebasing doesn't seem to be stable yet. > > Not to diverge py-dev too far into the depths of DRCS usage, but are > you doing anything particularly complex ? As of git 1.5.0.something, "git rebase --onto NEWBASE UPSTREAM" just ignored the --onto flag A

Re: [Python-Dev] Two spaces or one?

[EMAIL PROTECTED] writes: > I started with IBM punch cards Definitely a character cell format. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/pyt

[Python-Dev] [Python-3000] Universal newlines support in Python 3.0

Guido van Rossum writes: > However, the old universal newlines feature also set an attibute named > 'newlines' on the file object to a tuple of up to three elements > giving the actual line endings that were observed on the file so far > (\r, \n, or \r\n). This feature is not in PEP 3116, and

Re: [Python-Dev] urllib exception compatibility

Greg Ewing writes: > Gregory P. Smith wrote: > > Is IOError is the right name to use? OSError is raised for things that > > are not IO such as subprocess, dlopen, system. > > The trouble with either of these is that the class > of errors we're talking about don't necessarily come > direct

Re: [Python-Dev] XML codec?

"Martin v. Löwis" writes: > > It's clear to me that detecting an encoding is actually the simplest > > part of all this (so long as there's an API to do it!) Putting it > > inside a codec seems like the wrong subdivision of responsibility. > > In case it isn't clear - this is exactly my vie

[Python-Dev] Monkeypatching idioms -- elegant or ugly?

Guido van Rossum writes: > I think it's useful to share these recipes, But only to people who have demonstrated that they already know when, why and how to monkeypatch on their own. Lisp's `defadvice' plays a starring role in a number of my nightmares. Most recently, 15 minutes ago. Come to t

Re: [Python-Dev] Python-Dev Digest, Vol 54, Issue 57

Oleg Broytmann writes: >~/.python To me, this strongly suggests user configuration files, not a place where an app can store user-specific packages. True, there are apps that store their stuff in such places, like most GNOME apps. But they have no user-servicable parts (including config fi

Re: [Python-Dev] Python-Dev Digest, Vol 54, Issue 57

Oleg Broytmann writes: > On Wed, Jan 16, 2008 at 06:31:42AM +0900, Stephen J. Turnbull wrote: > > I think both for UI reasons (given above) and for API reasons (given > > by others) there should be a separate ~/SOMETHING/{bin,etc,lib,share} > > hierarchy for user-speci

Re: [Python-Dev] Python-Dev Digest, Vol 54, Issue 57

Bill Janssen writes: > > >> ~/Library/ is a Mac OS X thing. > > > > Bill> Sure, but it's clearly where this should be on an OS X system, by > > Bill> default. > > [etc.] > [tocatta and fugue ad lib] Doesn't Apple publish standards for this? They do for everything else, it se

Re: [Python-Dev] What to do for bytes in 2.6?

Raymond Hettinger writes: > One other thought. I'm guessing that apps that would > care about the distinction are already using unicode > and are already treating text as distinct from arrays > of bytes. Indeed. Mailman, for instance. Yet Mailman still has problems with (broken) wire proto

Re: [Python-Dev] Priorities in the tracker

Brett Cannon writes: > In my dream schema, severity becomes Then how does the user indicate how important it is to him? My severities (in an experimental roundup tracker I'm implementing) are 'inelegant', 'inconvenient', 'some work obstructed', 'much work obstructed', 'security', 'data loss',

Re: [Python-Dev] 2.5.2 release coming up

Brett Cannon writes: > On Jan 22, 2008 8:47 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > A reminder: 2.5.2 should only get bugfixes, new features. > > If Guido felt like dragging the time machine out he would catch his > mistake and have that say "NO new features". What, nothing abou

Re: [Python-Dev] Nosy lists on issue tracker.

"Martin v. Löwis" writes: > > What is the policy regarding nosy lists? Is it appropriate it add people > > to it besides oneself? As I cannot assign items, I'm sometimes tempted > > to add someone relevant to the list. (ie Should I add Georg to > > documentation related issues?) > > I wo

Re: [Python-Dev] Small RFEs and the Bug Tracker

"Martin v. Löwis" writes: > That's why the entire field is called "Resolution". "duplicate", > "invalid", "out of date", "wont fix" and "works for me" are also > firm decisions. > > ("later", "postponed", and "remind" might not be firm decisions - > they were just inherited from SF). These

Re: [Python-Dev] Small RFEs and the Bug Tracker

Facundo Batista writes: > 2008/2/23, Virgil Dupras <[EMAIL PROTECTED]>: > > The flow seems healthy to me. +1 > What I don't see healthy is that we have, per week, around 30 issues > more open (30 is the difference between those closed, and the new > ones). > > So, the curve is always go

Re: [Python-Dev] Code freeze?

Barry Warsaw writes: > I plan on cutting the alphas for 2.6 and 3.0 at about 6pm Eastern > (UTC-5) time or 2300 UTC. Let's freeze the tree one hour prior to > that: 2200 UTC Friday 29-Feb-2008. Is that enough time for the buildbots to do their thing and for you to look at the page? Alter

Re: [Python-Dev] Code freeze?

Not speaking for Barry or anyone else but myself. This is an explanation of how I understand the process and why I welcome it. Scott Dial writes: > I don't understand who these alpha releases are supposed to be for, and > who they will serve. An alpha test is internal. It is comprised of th

Re: [Python-Dev] [Python-3000] The release process

Christian Heimes writes: > It may sound like a dumb question by why do we need a release tool > at all? I was involved in the release process of 3.0a2. Almost > every step of the build process required human interaction. Interaction, yes, but often it can be reduced to "Abort, retry, fail?"

[Python-Dev] Documentation reorganization [was: ... for ability to execute zipfiles & directories]

Georg Brandl writes: > You speak my mind. For ages I've wanted to put the builtins together with > the language reference into a new document called "Python Core Language". > I've just never had the time to draft a serious proposal. I think that combination is reasonable, but I would like to se

Re: [Python-Dev] Documentation reorganization

Adam Olsen writes: > On Tue, Mar 4, 2008 at 3:13 PM, Stephen J. Turnbull <[EMAIL PROTECTED]> > wrote: > > I would like to see the clear division between the language (ie, > > the syntax) and the built-in functionality maintained. I'm not > > sure I like

Re: [Python-Dev] Compiler used to build Python for Windows

Greg Ewing writes: > Christian Heimes wrote: > > The latest alphas of Python 2.6 and 3.0 are build with VS 2088. > > Wow, that must be a very, very pre-alpha release... Nah, it's a version optimized for 8/16-bit segmented archi

Re: [Python-Dev] Complexity documentation request

"Martin v. Löwis" writes: > Premature optimization is the root of all evil. Actually, Knuth's bon mot was "Premature optimization is the root of all error." Which is probably worse; it leaves the perpetrator the excuse "but I was only trying to help!" While we all know what to do to evildoers,

Re: [Python-Dev] [Python-3000] 2.6 and 3.0 project management

Benjamin Peterson writes: > It's just depends on how you see the tracker. It's not just to "bug" tracker > anymore, is it? On other projects I've worked with, we had separate areas > for bugs, features, and tasks. (yes, it's SourceForge.) I found it easier to > keep organized. However, if this

Re: [Python-Dev] PEP 365 (Adding the pkg_resources module)

Guido van Rossum writes: > I am hoping that someone will create a simpler bootstrap module FWIW (I've never tried to implement one of these things) I agree with Phillip. This is not possible in the sense you are advocating. Anything "simpler" is simply an invitation to an unending stream of iss

Re: [Python-Dev] unittest's redundant assertions: asserts vs. failIf/Unlesses

Michael Urman writes: > Yes it removes redundancy, but it really doesn't change the cognitive > load (at least for native speakers). Actually, OONTDI is important to me, cognitively. Multiple names implies the possibility of multiple semantics, often unintentionally. Here that can't be the cas

Re: [Python-Dev] The Breaking of distutils and PyPI for Python 3000?

"Martin v. Löwis" writes: > I don't think any of the core committers is qualified to write such > a document. Instead, it would have to be written by people who > *actually* ported a project from 2 to 3 in some form. Note that this is precisely the kind of experience Skip Montanaro is talking

Re: [Python-Dev] How we can get rid of eggs for 2.6 and beyond

[EMAIL PROTECTED] writes: > > Joachim> I think, the uninstall should _not_ 'rm -rf' but only 'rm' the > Joachim> files (and 'rmdir' directories, but not recursively) that it > Joachim> created, and that have not been modified in the meantime (after > Joachim> the installation)

<    7   8   9   10   11   12   13   14   15   16   >