Re: [Python-Dev] Unipath package

On 28 Jan, 06:30 pm, [EMAIL PROTECTED] wrote: >The discussion has been hampered by the lack of released code. Only >Orendorff's class has been widely used in production systems. The >others have either never been used or only by their authors; they >haven't made it to the Cheeseshop. Unipath is

Re: [Python-Dev] New syntax for 'dynamic' attribute access

On 12 Feb, 11:19 pm, [EMAIL PROTECTED] wrote: >Ben North wrote: > >> Generally gently positive, with the exception of Anthony Baxter's >> "-1", which I understand to be motivated by concerns about newcomers to >> the syntax > >The more I think about it, the more I'm leaning >towards -1 as well. Add

Re: [Python-Dev] Trial balloon: microthreads library in stdlib

On 12 Feb, 05:11 pm, [EMAIL PROTECTED] wrote: >On 2/12/07, Tristan Seligmann <[EMAIL PROTECTED]> wrote: >> * Richard Tew <[EMAIL PROTECTED]> [2007-02-12 13:46:43 +]: >> > Perhaps there is a better way. And I of course have no concept of >> > how this might be done on other platforms. >> >> Bui

[Python-Dev] Twisted Isn't Specific (was Re: Trial balloon: microthreads library in stdlib)

On 02:20 am, [EMAIL PROTECTED] wrote: >If Twisted is designed so that it absolutely *has* to >use its own special event mechanism, and everything else >needs to be modified to suit its requirements, then it's >part of the problem, not part of the solution. I've often heard this complaint, usually

Re: [Python-Dev] Summary: rejection of 'dynamic attribute' syntax

On 01:04 pm, [EMAIL PROTECTED] wrote: >[EMAIL PROTECTED]: >> I really, really wish that every feature proposal for Python had to meet >> some burden of proof [...]. I suspect this would kill 90% of "hey >> wouldn't this syntax be neat" proposals on day zero [...] > >This is what I understood the

Re: [Python-Dev] Twisted Isn't Specific (was Re: Trial balloon: microthreads library in stdlib)

On 03:32 pm, [EMAIL PROTECTED] wrote: >[EMAIL PROTECTED] wrote: >>When you boil it down, Twisted's event loop ... >But that is exactly the problem I have with Twisted. For HTTP ... >From that word on out, you have completely lost the pl

Re: [Python-Dev] Twisted Isn't Specific (was Re: Trial balloon: microthreads library in stdlib)

On 02:22 pm, [EMAIL PROTECTED] wrote: >On Wed, Feb 14, 2007, [EMAIL PROTECTED] wrote: >> >> As I said, I don't have time to write the PEPs myself, but I might fix >> some specific bugs if there were a clear set of issues preventing this >> from moving forward. Better integration with the standard

Re: [Python-Dev] Trial balloon: microthreads library in stdlib

On 04:49 pm, [EMAIL PROTECTED] wrote: >On 2/13/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >>Tristan is correct: this should be a patch against Twisted, or perhaps as a >>separate library that could implement a reactor. > >I think there is some confusion here. Quite. >I am not writing a comp

Re: [Python-Dev] Twisted Isn't Specific (was Re: Trial balloon: microthreads library in stdlib)

On 08:52 pm, [EMAIL PROTECTED] wrote: >When I last looked at twisted (that is several years ago), there were >several reactors - win32reactor, wxreactor, maybe even more. Yes. That's intentional. Each of those systems offers its own event loop, and each reactor implements the basic operations

Re: [Python-Dev] Twisted Isn't Specific (was Re: Trial balloon: microthreads library in stdlib)

On 12:31 am, [EMAIL PROTECTED] wrote: >[EMAIL PROTECTED] wrote: >> On 08:52 pm, [EMAIL PROTECTED] wrote: >> >> >When I last looked at twisted (that is several years ago), there were >> >several reactors - win32reactor, wxreactor, maybe even more. >> >> Only the very top-most level decides which

Re: [Python-Dev] Twisted Isn't Specific (was Re: Trial balloon: microthreads library in stdlib)

On 16 Feb, 06:30 pm, [EMAIL PROTECTED] wrote: >I suggest it is possible to implement a PerfectReactor. I don't think this constitutes a sufficient existence proof. Perhaps you could write a prototype? There are a bunch of existing reactors you could either import or copy/paste from to bootst

Re: [Python-Dev] with_traceback

On Tue, 27 Feb 2007 13:37:21 +1300, Greg Ewing <[EMAIL PROTECTED]> wrote: >I don't like that answer. I can think of legitimate >reasons for wanting to pre-create exceptions, e.g. if >I'm intending to raise and catch a particular exception >frequently and I don't want the overhead of creating >a ne

Re: [Python-Dev] Python-3000 upgrade path

On Sun, 25 Feb 2007 13:12:51 -0800, Thomas Wouters <[EMAIL PROTECTED]> wrote: >I'm sending this to python-dev instead of python-3000 for two reasons: It's >not about features to be added to Python 3.0, and it's not really >about 3.0at all -- it's about >2.6 and later. It's about how we get Python 2

Re: [Python-Dev] with_traceback

On Wed, 28 Feb 2007 18:10:21 -0800, Guido van Rossum <[EMAIL PROTECTED]> wrote: >I am beginning to think that there are serious problems with attaching >the traceback to the exception; I really don't like the answer that >pre-creating an exception is unpythonic in Py3k. In Twisted, to deal with a

Re: [Python-Dev] Encouraging developers

A few meta-points: On 07:30 pm, [EMAIL PROTECTED] wrote: 2. Publically identify the core developers and their areas of expertise and responsibility (ie. which parts of the source tree they "own"). I'd like to stress that this is an important point; although we all know that Guido's the event

Re: [Python-Dev] splitext('.cshrc')

On 10:18 pm, [EMAIL PROTECTED] wrote: Phillip J. Eby schrieb: At 10:01 PM 3/6/2007 +0100, Martin v. L�wis wrote: It's unfortunate, of course, that people apparently relied on this behavior I was going to say it's the *documented* behavior, but I see that the documentation is actually such tha

Re: [Python-Dev] Python-3000 upgrade path

On 10:22 pm, [EMAIL PROTECTED] wrote: On 2/27/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: 2to3 should take great care _tell_ you when it fails. One concern I have is that the source translation may subtly alter the *semantics* of unit test code, so that the tests are no longer effective a

[Python-Dev] Policy Decisions, Judgment Calls, and Backwards Compatibility (was Re: splitext('.cshrc'))

[EMAIL PROTECTED] wrote: That assumes there is a need for the old functionality. I really don't see it (pje claimed he needed it once, but I remain unconvinced, not having seen an actual fragment where the old behavior is helpful). This passage is symptomatic of the thing that really bothers me

Re: [Python-Dev] splitext('.cshrc')

On 8 Mar, 06:02 pm, [EMAIL PROTECTED] wrote: On Thu, Mar 08, 2007 at 06:54:30PM +0100, "Martin v. L?wis" wrote: back_name = splitext(name[0]) + '.bak' back_name = splitext(name)[0] + '.bak' This is really totally secondary to the point I actually care about, but seeing this antipatter

Re: [Python-Dev] Backports of standard library modules

On 11 Mar, 10:32 pm, [EMAIL PROTECTED] wrote: If this seems useful to others, I could try to start a PEP on how the process would work (but since I'm fairly new, it would be great if someone could help out a bit by validating my verbiage against some of the process requirements). Isn't this PE

Re: [Python-Dev] Proposal to revert r54204 (splitext change)

On 14 Mar, 05:08 pm, [EMAIL PROTECTED] wrote: In addition to the prior behavior being explicitly documented in the function docstrings, r54204 shows that it was also *tested* as behaving that way by test_macpath, test_ntpath, and test_posixpath. When combined with the explicit docstrings, this

Re: [Python-Dev] Status of thread cancellation

On 04:24 pm, [EMAIL PROTECTED] wrote: Jean-Paul Calderone schrieb: I inferred from Martin's proposal that he expected the thread to be able to catch the exception. Perhaps he can elaborate on what cleanup actions the dying thread will be allowed to perform. Perhaps he can. Hopefully, he ca

Re: [Python-Dev] Proposal to revert r54204 (splitext change)

On 05:51 pm, [EMAIL PROTECTED] wrote: At 07:45 AM 3/15/2007 +0100, Martin v. L�wis wrote: I apparently took the same position that you now take back then, whereas I'm now leaning towards (or going beyond) the position Tim had back then, who wrote "BTW, if it *weren't* for the code breakage, I'

Re: [Python-Dev] Proposal to revert r54204 (splitext change)

On 08:21 pm, [EMAIL PROTECTED] wrote: Mike Krell schrieb: FWIW, I agree completely with PJE's and glyph's remarks with respect to expectations of stability, especially in a minor release. Not sure what you mean by "minor release". The change isn't proposed for the next bug fix release (2.5.1),

Re: [Python-Dev] Proposal to revert r54204 (splitext change)

On 08:43 pm, [EMAIL PROTECTED] wrote: On 3/15/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: On 05:51 pm, [EMAIL PROTECTED] wrote: >At 07:45 AM 3/15/2007 +0100, Martin v. L�wis wrote: >>I apparently took the same position that you now take back then, >>whereas I'm now leaning towards (or goin

Re: [Python-Dev] Proposal to revert r54204 (splitext change)

On 09:17 pm, [EMAIL PROTECTED] wrote: But the key point I want to get across is people should not being getting mad at Martin. The people who are getting all bent out of shape over this should be upset at python-dev as a whole for not having a clear policy on this sort of thing. Martin just hap

Re: [Python-Dev] Proposal to revert r54204 (splitext change)

On 15 Mar, 11:34 pm, [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] schrieb: However, the decision was a bad one regardless of the existing policy, and sets a bad precedent while we are discussing this policy. I could be wrong, but I think it would be reasonable to assume that if Martin strongly

Re: [Python-Dev] Status of thread cancellation

On 12:06 am, [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Can you suggest any use-cases for thread termination which will *not* result in a completely broken and unpredictable heap after the thread has died? Suppose you have a GUI and you want to launch a long-running computation without

Re: [Python-Dev] Proposal to revert r54204 (splitext change)

't said anything that implied (or stated, of course) that I did not *respect* the other participants of the discussion. If I have, I retract it. Strong disagreement is different than disrespect. If you want, I can make a decision. But I will only do that if I hear from both sides of the deba

Re: [Python-Dev] Proposal to revert r54204 (splitext change)

On 19 Mar, 02:46 pm, [EMAIL PROTECTED] wrote: As you see I'm trying to discourage you from working on such a document; but I won't stop you and if there's general demand for it and agreement I'll gladly review it when it's ready. (It's a bit annoying to have to read long posts alluding to a docum

Re: [Python-Dev] deprecate commands.getstatus()

On 22 Mar, 08:38 pm, [EMAIL PROTECTED] wrote: And do we even need os.fork(), os.exec*(), os.spawn*()? Maybe not os.spawn*, but Twisted's spawnProcess is implemented (on UNIX) in terms of fork/exec and I believe it should stay that way. The subprocess module isn't really usable for asynchrono

Re: [Python-Dev] deprecate commands.getstatus()

On 22 Mar, 09:37 pm, [EMAIL PROTECTED] wrote: Sure. os.fork() and the os.exec*() family can stay. But os.spawn*(), that abomination invented by Microsoft? Right, I personally would not miss it. It's also not a system call, but a library function on both Windows and Unix (the equivalent of expo

Re: [Python-Dev] Tweaking the stdlib test infrastructure

On 12:39 am, [EMAIL PROTECTED] wrote: Fast and simple: I want all stdlib test cases to stop subclassing unittest.TestCase and start subclassing test_support.TestCase. So: any objections to making this change? Not an objection so much as a question - if these feature additions are generally

Re: [Python-Dev] Tweaking the stdlib test infrastructure

On 04:36 pm, [EMAIL PROTECTED] wrote: On 4/24/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: On 12:39 am, [EMAIL PROTECTED] wrote: >Fast and simple: I want all stdlib test cases to stop subclassing >unittest.TestCase and start subclassing test_support.TestCase. >So: any objections to making t

Re: [Python-Dev] whitespace normalization

On 08:15 pm, [EMAIL PROTECTED] wrote: ;; untabify and clean up lines with just whitespace (defun baw-whitespace-normalization () Looks a lot like (whitespace-cleanup), if you've got the right configuration. A function I've used many times :). ___ Py

Re: [Python-Dev] Add a -z interpreter flag to execute a zip file

On 08:41 am, [EMAIL PROTECTED] wrote: >On 7/12/07, Thomas Wouters <[EMAIL PROTECTED]> wrote: >>I disagree with both statements. The bagage is much less than >>zipimport >>itself, which has proven to be quite useful. Nevertheless, zipimport >>built >>into the interpreter was by no means necessary

Re: [Python-Dev] frozenset C API?

On 05:03 pm, [EMAIL PROTECTED] wrote: >>I really don't understand why you would not expose all data in the >>certificate. > >You mean, providing the entire certificate as a blob? That is planned >(although perhaps not implemented). > >Or do you mean "expose all data in a structured manner". BECAUSE

Re: [Python-Dev] frozenset C API?

On 05:15 pm, [EMAIL PROTECTED] wrote: >>RFC 2818 >> >>"""If a subjectAltName extension of type dNSName is present, that MUST >>be used as the identity. Otherwise, the (most specific) Common Name >>field in the Subject field of the certificate MUST be used. Although >>the use of the Common Name is e

[Python-Dev] Design and direction of the SSL module (was Re: frozenset C API?)

Sorry for the late response. As always, I have a lot of other stuff going on at the moment, but I'm very interested in this subject. On 6 Sep, 06:15 pm, [EMAIL PROTECTED] wrote: >>PyOpenSSL, in particular, is both a popular de-facto >>standard *and* almost completely unmaintained; python's stand

Re: [Python-Dev] Declaring setters with getters

As long as we're all tossing out ideas here, my 2¢. I vastly prefer this: On 02:43 am, [EMAIL PROTECTED] wrote: On 10/31/07, Fred Drake <[EMAIL PROTECTED]> wrote: @property.set def attribute(self, value): self._ignored = value to this: @property.set(attribut

Re: [Python-Dev] Declaring setters with getters

On 02:01 pm, [EMAIL PROTECTED] wrote: On 10/31/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: As long as we're all tossing out ideas here, my 2�. I vastly prefer this: >>@property.set to this: > @property.set(attribute) I don't approve of it. It has always been and will always

Re: [Python-Dev] Signals+Threads (PyGTK waking up 10x/sec).

On 02:48 pm, [EMAIL PROTECTED] wrote: >Not only that, but current python signal handling is not theorethically >async safe; there are race conditions in the Py_AddPendingCalls API, >and it >just happens to work most of the time. Twisted has encountered one such issue, described here: http:/

Re: [Python-Dev] Signals+Threads (PyGTK waking up 10x/sec).

to the write end, and add the read >end to your list of file descriptors passed to select() or poll(). The >handler must be written in C in order to avoid the race condition >referred to by Glyph (signals arriving after the signal check in the >VM main loop but before the select()/poll(

Re: [Python-Dev] Signals+Threads (PyGTK waking up 10x/sec).

On 12:21 am, [EMAIL PROTECTED] wrote: >Anyway, I would still like to discuss this on #python-dev Monday. >Adam, in what time zone are you? (I'm PST.) Who else is interested? I'm also interested. I'm EST, but my schedule is very flexible (I'm on IRC pretty much all day for work anyway). Just le

Re: [Python-Dev] Return type of round, floor, and ceil in 2.6

On 4 Jan, 10:45 pm, [EMAIL PROTECTED] wrote: >[GvR to Tim] >>Do you have an opinion as to whether we should >>adopt round-to-even at all (as a default)? > >For the sake of other implementations (Jython, etc) and for ease of >reproducing the results with other tools (Excel, etc), the simplest >cho

Re: [Python-Dev] Return type of round, floor, and ceil in 2.6

On 04:54 pm, [EMAIL PROTECTED] wrote: >On Jan 4, 2008 10:16 PM, <[EMAIL PROTECTED]> wrote: >>Having other rounding methods *available*, though, would be neat. The >>only application I've ever worked on where I cared about the >>difference, >>the user had to select it (since accounting requirem

Re: [Python-Dev] PEP: Lazy module imports and post import hook

>> > >> > Christian >> >>Note also that mercurial has demandimport >>http://www.selenic.com/mercurial/wiki/ > >And that bzr has lazy_import (inspired by mercurial's demandimport): and very recently, I implemented similar functionality myself (though i

Re: [Python-Dev] PEP: per user site-packages directory

On 12:08 pm, [EMAIL PROTECTED] wrote: >So if I'm using the --user option, where would scripts be installed? >Would this be: > >Windows: %APPDATA%/Python/Python26/bin >Mac: ~/Library/Python/2.6/bin >Unix: ~/.local/lib/python2.6/bin > >I'd like to be able to switch between several versions of my user

Re: [Python-Dev] PEP: per user site-packages directory

On 06:37 pm, [EMAIL PROTECTED] wrote: >[EMAIL PROTECTED] wrote: >>I think the relevant link to change here would be ~/.local. >> >>I have personally been using the ~/.local convention for a while, and >>I >>believe ~/.local/bin is where scripts should go. Python is not the >>only >>thing that ca

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

On 03:37 pm, [EMAIL PROTECTED] wrote: >I think it's useful to share these recipes, if only to to establish >whether they have been discovered before, or to decide whether they >are worthy of a place in the standard library. I didn't find any >relevant hits on the ASPN Python cookbook. >from impor

Re: [Python-Dev] PEP 370, open questions

On 07:55 am, [EMAIL PROTECTED] wrote: >A CC of the mail goes to the authors of setuptools, virtual python, >working env and virtual env. What's your opinion on the PEP? Do you >have >some input and advice for me? I wrote a similar tool called Combinator (http://divmod.org/trac/wiki/DivmodCombin

Re: [Python-Dev] PEP 370, open questions

On 12:02 pm, [EMAIL PROTECTED] wrote: On 17 Jan, 2008, at 9:40, [EMAIL PROTECTED] wrote: On 07:55 am, [EMAIL PROTECTED] wrote: The framework build of Python definitly targets the upper layer of the OSX stack, not just the Unix core. This sometimes causes confusion, but mostly from developers

Re: [Python-Dev] PEP 370, open questions

On 12:19 pm, [EMAIL PROTECTED] wrote: >[EMAIL PROTECTED] wrote: >MacOS isn't the only platform that has this problem. I use cygwin >under >Windows, and I wish Python (whether or not a cygwin build) would also >use ~/.local. I would like to agree. MacOS has an advantage here though. Windows,

Re: [Python-Dev] PEP 370, open questions

On 12:26 pm, [EMAIL PROTECTED] wrote: >On Thu, 17 Jan 2008 13:09:34 +0100, Christian Heimes <[EMAIL PROTECTED]> >wrote: >>The uid and gid tests aren't really required. They just provide an >>extra >>safety net if a user forgets to add the -s flag to a suid app. >It's not much of a safety net if

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

On 04:43 am, [EMAIL PROTECTED] wrote: >Just being able to (voluntarily! on a >per-module basis!) use a different type name and literal style for >data could help forward-looking programmers get started on making the >distinction clear, thus getting ready for 3.0 without making the jump >just yet (o

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

On 19 Jan, 07:32 pm, [EMAIL PROTECTED] wrote: >There is no way to know whether that return value means text or data >(plenty of apps legitimately read text straight off a socket in 2.x), IMHO, this is a stretch of the word "legitimately" ;-). If you're reading from a socket, what you're getting

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

On 04:26 am, [EMAIL PROTECTED] wrote: On Jan 19, 2008 5:54 PM, <[EMAIL PROTECTED]> wrote: On 19 Jan, 07:32 pm, [EMAIL PROTECTED] wrote: Starting with the most relevant bit before getting off into digressions that may not interest most people: Why can't we get that warning in -3 mode just th

Re: [Python-Dev] Any Emacs tips for core developers?

To say I "use" emacs would be an understatement. I *live* in emacs. On 04:32 pm, [EMAIL PROTECTED] wrote: >I recently upgraded to the emacs 22.1/python.el which I tried *really* >hard to use, but eventually ended up installing python-mode again. >There are a number of problems in the emacs lisp t

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

On 02:21 pm, [EMAIL PROTECTED] wrote: >>OTOH, I'd rather there be OOWTDI so whatever the consensus is is fine >>with me. > >This strikes me as a gratuitous API change of the kind Guido was >warning about in his recent post: "Don't change your APIs incompatibly >when porting to Py3k" I agree empha

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

On 08:34 pm, [EMAIL PROTECTED] wrote: Martin v. L�wis wrote: You seem to be implying that some projects may release separate source distributions. I cannot imagine why somebody would want to do that. That's odd. I can't imagine why anybody would *not* want to do that. Python 2 is going to

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

On 09:33 am, [EMAIL PROTECTED] wrote: >I'll chime in here, too. I really want to like >setuptools/easy_install, but I don't. I'll try to be specific in my >reasons, in the hope that they can be addressed. I know some of these >are "known about", but one of my meta-dislikes of setuptools is that >k

Re: [Python-Dev] shal we redefine "module" and "package"?

On 10:53 pm, [EMAIL PROTECTED] wrote: zooko wrote: Unfortunately these answers aren't quite right. A "package" is actually a directory containing an __init__.py file, and a distribution is actually what you think of when you say "package" -- a reusable package of Python code that you can,

Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008

On 11:45 pm, [EMAIL PROTECTED] wrote: I like this, except one issue: I really don't like the .local directory. I don't see any compelling reason why this needs to be ~/.local/lib/ -- IMO it should just be ~/lib/. There's no need to hide it from view, especially since the user is expected to manag

Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008

On 01:55 am, [EMAIL PROTECTED] wrote: On Thu, May 1, 2008 at 5:03 PM, <[EMAIL PROTECTED]> wrote: Hi everybody. I apologize for writing yet another lengthy screed about a simple directory naming issue. I feel strongly about it but I encourate anyone who doesn't to simply skip it. First, s

Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008

On 03:49 am, [EMAIL PROTECTED] wrote: I stand corrected on a few points. You've convinced me that ~/lib/ is wrong. But I still don't like ~/.local/; not in the last place because it's not any more local than any other dot files or directories. The "symmetry" with /usr/local/ is pretty weak, and

Re: [Python-Dev] Reminder: last alphas next Wednesday 07-May-2008

On 11:01 am, [EMAIL PROTECTED] wrote: On Friday 02 May 2008, Nick Coghlan wrote: This sums up my opinion pretty well. Hidden by default, but easy to expose (e.g. via a local -> .local symlink) for the more experienced users that want it more easily accessible. But you can't be serious about

Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008

On 05:53 pm, [EMAIL PROTECTED] wrote: On May 1, 2008, at 7:54 PM, Barry Warsaw wrote: Interesting. I'm of the opposite opinion. I really don't want Python dictating to me what my home directory should look like (a dot file doesn't count because so many tools conspire to hide it from me).

Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008

On 3 May, 11:34 pm, [EMAIL PROTECTED] wrote: On May 3, 2008, at 7:51 AM, [EMAIL PROTECTED] wrote: Fred asked for a --prefix flag (which is what I was voting on). I don't really care what you do by default as long as you give me a way to do it differently. What's most interesting (to me) i

Re: [Python-Dev] Module renaming and pickle mechanisms

On 10:22 pm, [EMAIL PROTECTED] wrote: When I brought this up earlier, various people assured me that it wasn't a problem in practice. I think we're seeing one situation here where it *is* a problem. Just my two cents here - experience has taught me that it's definitely a problem in practice.

Re: [Python-Dev] Py3k DeprecationWarning in stdlib

On 10:05 pm, [EMAIL PROTECTED] wrote: We need to be especially careful with the unit test suite itself - changing the test code to avoid the warning will normally be the right answer, but when the code is actually setting out to test the deprecated feature we need to suppress the warning in the

[Python-Dev] Community buildbots and Python release quality metrics

Today on planetpython.org, Doug Hellman announced the June issue of Python magazine. The cover story this month is about Pybots, "the fantastic automation system that has been put in place to make sure new releases of Python software are as robust and stable as possible". Last week, there was

Re: [Python-Dev] Community buildbots and Python release quality metrics

On 03:33 pm, [EMAIL PROTECTED] wrote: Too verbose, Glyph. :-) Mea culpa. "Glyph" might be a less appropriate moniker than "Altogether too many glyphs". It needs to be decided case-by-case. If certain tests are to be ignored on a case-by-case basis, why not rec

Re: [Python-Dev] Community buildbots and Python release quality metrics

On 03:42 pm, [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: beta 1 has some trouble running *our* test suite - I'd be fairly surprised if the community buildbots were in significantly better shape. That's another problem, yes :) The community buildbots have been in a broken state for mo

Re: [Python-Dev] Community buildbots and Python release quality metrics

On 04:42 pm, [EMAIL PROTECTED] wrote: On Thu, Jun 26, 2008 at 5:33 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: an explanation about *why* Django cannot even be imported than a blanket complaint that this is a disgrace. So why is it? and already discussed: http://mail.python.org/pipermail/

Re: [Python-Dev] Community buildbots and Python release quality metrics

I do tend to ramble on, so here's an executive summary of my response: I want python developers to pay attention to the community buildbots and to treat breakages of existing projects as a serious issue. However, I don't think that maintaining those projects is the core team's job, so all I'

Re: [Python-Dev] Community buildbots and Python release quality metrics

On 05:14 pm, [EMAIL PROTECTED] wrote: I don't know. JP is already addressing the issues affecting Twisted in another thread (incompatible changes in the private-but-necessary-to- get-any-testing-done API of the warnings module). But I really think that whoever made the change which broke it s

Re: [Python-Dev] Community buildbots and Python release quality metrics

On 07:44 pm, [EMAIL PROTECTED] wrote: At no time will a policy "the community buildbots must be green" be useful: the tests that run on these buildbots are not under our control, so if the tests test things we deem non-public we can't do anything about it. (And we may have a hard time convincin

Re: [Python-Dev] Community buildbots and Python release quality metrics

On 09:17 pm, [EMAIL PROTECTED] wrote: On Thu, Jun 26, 2008 at 12:35 PM, <[EMAIL PROTECTED]> wrote: Because the relevant community buildbot turned red with that revision of trunk. Keep in mind I'm not talking about every piece of Python code in the universe; just the ones selected for the c

Re: [Python-Dev] Community buildbots and Python release quality metrics

On 26 Jun, 09:24 pm, [EMAIL PROTECTED] wrote: On Thu, Jun 26, 2008 at 1:06 PM, <[EMAIL PROTECTED]> wrote: On 07:44 pm, [EMAIL PROTECTED] wrote: Well, sorry, that's life. We're not going to deal with breakage in 3rd party code on a "drop all other work" basis. For the record, "automatic rev

Re: [Python-Dev] Community buildbots and Python release quality metrics

On 01:02 am, [EMAIL PROTECTED] wrote: To bring my $0.02 to this discussion: the Pybots 'community buildbots' turned out largely to be a failure. Let's not say it's a failure. Let's instead say that it hasn't yet become a success :-). I still haven't given up, and I hope this thread will spur

Re: [Python-Dev] Community buildbots and Python release quality metrics

y easily. How shall we arrange it, then? :) Whoever is interested, I've got a recent SSH key on https://launchpad.net/~glyph/+sshkeys ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-de

Re: [Python-Dev] Community buildbots and Python release quality metrics

On 6 Jul, 09:09 pm, [EMAIL PROTECTED] wrote: On Sun, Jul 6, 2008 at 8:46 AM, <[EMAIL PROTECTED]> wrote: It's one thing to tell people that they need to be helping out (and I'm sure you're right) but it's much more useful to get the message out that "we really need people to do X, Y, and Z".

Re: [Python-Dev] Things to Know About Super

On 06:33 pm, [EMAIL PROTECTED] wrote: On Aug 29, 2008, at 11:46 AM, Michele Simionato wrote: On Fri, Aug 29, 2008 at 6:15 PM, Nick Coghlan <[EMAIL PROTECTED]> wrote: I am very well aware of the collection module and the ABC mechanism. However, you are missing that mixins can be implemented in

[Python-Dev] 'warnings' module changes still breaking Twisted, still looking for a fix

With the 2.6 final release impending, the Twisted community buildbot is still red, , but there only seems to be one real issue: the warn_explicit change. This seems like it could be a pretty minor bit of maintenance to clear up on our end, if Python provided the appropri

Re: [Python-Dev] 'warnings' module changes still breaking Twisted, still looking for a fix

On 10:18 pm, [EMAIL PROTECTED] wrote: That's why catch_warning keeps track of the warnings filter too, so you can call warnings.simplefilter("always") within the context manager and the filter state will be restored. Thanks for the pointer - this is interesting. I misunderstood the way the wa

Re: [Python-Dev] 'warnings' module changes still breaking Twisted, still looking for a fix

On 10:35 pm, [EMAIL PROTECTED] wrote: It is not hard to force an import of warnings to use the pure Python version and totally ignore the C implementation. See test_warnings on how to pull that off. Then you can do your hack of overriding warn_explicit(). Benjamin Peterson's recommendation sou

Re: [Python-Dev] Filename as byte string in python 2.6 or 3.0?

On 10:50 am, [EMAIL PROTECTED] wrote: On Sunday 28 September 2008, Gregory P. Smith wrote: "broken" systems will always exist. Code to deal with them must be possible to write in python 3.0. since any given path (not just fs) can have its own encoding it makes the most sense to me to let the

Re: [Python-Dev] Filename as byte string in python 2.6 or 3.0?

On 11:59 am, [EMAIL PROTECTED] wrote: Sorry, I wasn't clear enough. I'll try to explain further... Let's assume we have a filename like this: 0xc2 0xa9 0x2f 0x7f The first two bytes are the copyright sign encoded in UTF-8, followed by a slash (0x2f, path separator) and a character encoded i

Re: [Python-Dev] Patch for an initial support of bytes filename in Python3

On 12:47 am, [EMAIL PROTECTED] wrote: This is the most sane contribution I've seen so far :). See attached patch: python3_bytes_filename.patch Using the patch, you will get: - open() support bytes - listdir(unicode) -> only unicode, *skip* invalid filenames (as asked by Guido) Forgive me fo

Re: [Python-Dev] Patch for an initial support of bytes filename in Python3

On 02:32 pm, [EMAIL PROTECTED] wrote: On Tue, Sep 30, 2008 at 6:21 AM, <[EMAIL PROTECTED]> wrote: On 12:47 am, [EMAIL PROTECTED] wrote: It sounds like maybe there should be some 2to3 fixers in here somewhere, too? Not necessarily as part of this patch, but somewhere related? I don't know

Re: [Python-Dev] Filename as byte string in python 2.6 or 3.0?

On 02:39 pm, [EMAIL PROTECTED] wrote: For example, implementing os.listdir to return the file names as Unicode subclasses with ability to access the underlying bytes (automatically recognized by open and friends) sounds like a good compromise that allows the word processor to both have the cake

Re: [Python-Dev] Filename as byte string in python 2.6 or 3.0?

On 06:16 pm, [EMAIL PROTECTED] wrote: On Tue, Sep 30, 2008 at 11:12 AM, <[EMAIL PROTECTED]> wrote: The one thing it doesn't do is expose the decoding rules for the higher- level applications to deal with. I am pretty sure I don't understand how the interaction between filesystem encoding and

Re: [Python-Dev] Patch for an initial support of bytes filename in Python3

On 05:56 pm, [EMAIL PROTECTED] wrote: On Tue, Sep 30, 2008 at 10:59 AM, <[EMAIL PROTECTED]> wrote: On 02:32 pm, [EMAIL PROTECTED] wrote: In the absence of a 2.6 getcwdb, perhaps the fixer could just drop the "benefit of the doubt" case? It could always be added to 2.7, and the parity relea

Re: [Python-Dev] Filename as byte string in python 2.6 or 3.0?

On 30 Sep, 09:37 pm, [EMAIL PROTECTED] wrote: On Tue, Sep 30, 2008 at 11:42 AM, <[EMAIL PROTECTED]> wrote: There are other ways to glean this knowledge; for example, looking at the 'iocharset' or 'nls' mount options supplied to mount various filesystems. I know we could do a better job, but

Re: [Python-Dev] [Python-3000] New proposition for Python3 bytes filename issue

On 30 Sep, 09:22 pm, [EMAIL PROTECTED] wrote: On Tue, Sep 30, 2008 at 1:04 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: Guido van Rossum wrote: On Mon, Sep 29, 2008 at 11:00 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: Martin, I don't understand why you are in favor of storing raw by

Re: [Python-Dev] [Python-3000] New proposition for Python3 bytes filename issue

On 03:32 am, [EMAIL PROTECTED] wrote: On Sep 30, 2008, at 10:06 PM, [EMAIL PROTECTED] wrote: Can you clarify what proposal you are supporting for Python: Sure. Neither of your descriptions is terribly accurate, but I'll try to explain. 1) Two sets of APIs, one returning unicode strings, an

Re: [Python-Dev] [Python-3000] New proposition for Python3 bytes filename issue

On 03:54 pm, [EMAIL PROTECTED] wrote: I'm actually sort of liking this idea. A Pathname class, for convenience a subtype of String, but containing the underlying binary representation used by the OS. Even non-unicode pathnames could be represented. On the one hand, I agree with you - excep

Re: [Python-Dev] [Python-checkins] r66863 - python/trunk/Modules/posixmodule.c

On 11:12 pm, [EMAIL PROTECTED] wrote: - The backport to release26-maint http://svn.python.org/view?rev=66865&view=rev also merged other changes (new unrelated unit tests). IMO unrelated changes should be committed separately: different commit messages help to understand the motivation of each

Re: [Python-Dev] Documentation idea

On 9 Oct, 11:12 pm, [EMAIL PROTECTED] wrote: Background -- In the itertools module docs, I included pure python equivalents for each of the C functions. Necessarily, some of those equivalents are only approximate but they seem to have greatly enhanced the docs. Why not go the other

Re: [Python-Dev] [ANN] VPython 0.1

On 23 Oct, 10:42 pm, [EMAIL PROTECTED] wrote: Guido van Rossum wrote: there already is something else called VPython Perhaps it could be called Fython (Python with a Forth-like VM) or Thython (threaded-code Python). I feel like I've missed something important, but, why not just call it "Pyt

<    1   2   3   4   5   >