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
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
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
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
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
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,
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
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
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
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
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
>> >
>> > 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
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
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
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
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(
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:/
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
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
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
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
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
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
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
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
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
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
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
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
'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
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
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
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
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
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),
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'
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
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
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
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
[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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
On 08:19 am, [EMAIL PROTECTED] wrote:
>Georg Brandl schrieb:
>>> If Python 3.0 was simply a release which removed deprecated features,
>>> there would clearly be no issue. I would update my code in advance of
>>> the 3.0 release to not use any of those features being removed, and
>>> I'm all set. B
On 02:42 am, [EMAIL PROTECTED] wrote:
>Wrapper around open() that does proper checking of its arguments. I
>will be discussing my security stuff at PyCon if you are attending and
>are interested.
I am both, so I guess I'll see you there :).
___
Pyth
On 12:37 am, [EMAIL PROTECTED] wrote:
>For security reasons I might be asking for file's constructor to be
>removed from the type for Python source code at some point (it can be
>relocated to an extension module if desired). By forcing people to go
>through open() to create a file object you can
On 09:04 pm, [EMAIL PROTECTED] wrote:
>I'm wondering if we might be going the wrong way about warning about
>compatibility between 2.x and 3.x. Perhaps it might be better if the 3.0
>alpha had a 2.x compatibility mode command-line flag, which is removed late
>in the beta cycle.
Please, no.
I don
On 06:49 pm, [EMAIL PROTECTED] wrote:
>I think we should draw a line in the sand and resolve not to garbage-up Py2.6.
>The whole Py3.0 project is about eliminating cruft and being free of the
>bonds of backwards compatibility. Adding non-essential cruft to Py2.6
>goes against that philosophy.
Em
On 11:22 am, [EMAIL PROTECTED] wrote:
>> FWIW, I also agree with James that Python 3 shouldn't even be
>> released until the 2.x series has reached parity with its feature
>> set. However, if there's continuity in the version numbers
>> instead of the release dates, I can at least explain to Twis
On 10:12 am, [EMAIL PROTECTED] wrote:
>For practical reasons (we have enough work to be getting on with) PyPy
>is more-or-less ignoring Python 2.5 at the moment. After funding and
>so on, when there's less pressure, maybe it will seem worth it. Not
>soon though.
I think I know what you mean fro
On 07:56 am, [EMAIL PROTECTED] wrote:
>Additionally, without a 2.x<->3.x upgrade path 3.x is essentially a
>new language, having to build a new userbase from scratch. Worse
>yet, 2.x will suffer as people have the perception "Python 2?
>That's a dead/abandoned language"
It's worse than that. Thi
On 01:12 am, [EMAIL PROTECTED] wrote:
>On Friday 12 January 2007 06:09, James Y Knight wrote:
>> On Jan 10, 2007, at 6:46 PM, Benji York wrote:
>> > Paul Moore wrote:
>> >> How many other projects/packages anticipate *not* migrating to
>> >> Py3K, I wonder?
>> >
>> > I certainly can't speak for the
On 11 Jan, 08:22 pm, [EMAIL PROTECTED] wrote:
>On 1/11/07, James Y Knight <[EMAIL PROTECTED]> wrote:
>> If the goal is really to have Py 3.0 be released later this year,
>There will certainly be demand for an asynchronous server in 3.0,
To flip the question around: there might be a demand for Twi
On 10 Jan, 11:10 pm, [EMAIL PROTECTED] wrote:
>On 10/01/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>>I've been assuming for some time that the only hope for Py3k compatibility
>>within Twisted would be using PyPy as a translation layer.
>Does this ring as many warning bells for me as it does
On 07:42 pm, [EMAIL PROTECTED] wrote:
>On 1/10/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>>
>><"Anthony Baxter">
>> > Comments? What else should get warnings?
>>
>>It is my strong preference that we not go down this path.
>>Instead, the 2.6 vs 3.0 difference analysis should go in an
>>extern
On 11:17 pm, [EMAIL PROTECTED] wrote:
>On 12/11/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
>> On 12/8/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> > /ftp/python/2.5/python-2.5.msi is by far the top download -- 271,971
>> > hits, more than 5x the next one, /ftp/python/2.5/Python-2.5.tgz
>> > (4
On 05:37 pm, [EMAIL PROTECTED] wrote:
>Perhaps "pyinstall"?
Keep in mind that Python packages will still generally be *system*-installed
with other tools, like dpkg (or apt) and rpm, on systems which have them. The
name of the packaging system we're talking about is called either "eggs" or
"se
On 04:36 am, [EMAIL PROTECTED] wrote:
>easy_install uses the standard distutils configuration system, which means
>that you can do e.g.
Hmm. I thought I knew quite a lot about distutils, but this particular nugget
had evaded me. Thanks! I see that it's mentioned in the documentation, but I
On 04:11 am, [EMAIL PROTECTED] wrote:
>On Wednesday 29 November 2006 22:20, [EMAIL PROTECTED] wrote:
> > GNOME et. al. aren't promoting the concept too hard. It's just the first
> > convention I came across. (Pardon the lack of references here, but it's
> > very hard to google for "~/.local" - I
On 12:34 am, [EMAIL PROTECTED] wrote:
>The whole concept of "hidden" files seems ill-
>considered to me, anyway. It's too easy to forget
>that they're there. Putting infrequently-referenced
>stuff in a non-hidden location such as ~/local
>seems just as good and less magical to me.
Something like
On 29 Nov, 11:49 pm, [EMAIL PROTECTED] wrote:
>On Nov 29, 2006, at 5:18 AM, [EMAIL PROTECTED] wrote:
>> I'd suggest using "~/.local/lib/pythonX.X/site-packages" for the
>> "official" UNIX installation location, ...
>+1 from me also for the concept. I'm not sure I like ~/.local though
>- -- it s
On 09:34 am, [EMAIL PROTECTED] wrote:
>There's another standard place that is searched on MacOS: a per-user
>package directory ~/Library/Python/2.5/site-packages (the name "site-
>packages" is a misnomer, really). Standardising something here is
>less important than for vendor-packages (as the eff
On 11:45 pm, [EMAIL PROTECTED] wrote:
>I keep thinking I'd like to treat the OS as just another application,
>so that there's nothing special about it and the same infrastructure
>could be used for other applications with lots of entry level scripts.
I agree. The motivation here is that the "OS"
On 01:04 am, [EMAIL PROTECTED] wrote:>[EMAIL PROTECTED] wrote:>If you're serious about writing platform-agnostic>pathname code, you don't put slashes in the arguments>at all. Instead you do>> os.path.join("hello", "slash", "world")>>Many of the other things you mention are also a>result of not tr
On 01:46 am, [EMAIL PROTECTED] wrote:>On 11/1/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:>This is ironic coming from one of Python's celebrity geniuses. "We>made this class but we don't know how it works." Actually, it's>downright alarming coming from someone who knows Twisted inside and>out
On 08:14 pm, [EMAIL PROTECTED] wrote:>Argh, it's difficult to respond to one topic that's now spiraling into>two conversations on two lists.>[EMAIL PROTECTED] wrote:>(...) people have had to spend five years putting hard-to-read>os.path functions in the code, or reinventing the wheel with their own
On 06:14 pm, [EMAIL PROTECTED] wrote:>[EMAIL PROTECTED] wrote:>>> I assert that it needs a better[1] interface because the current>> interface can lead to a variety of bugs through idiomatic, apparently>> correct usage. All the more because many of those bugs are related to>> critical errors such
On 10:06 am, [EMAIL PROTECTED] wrote:>What a successor to os.path needs is not security, it's a better (more pythonic,>if you like) interface to the old functionality.Why?I assert that it needs a better[1] interface because the current interface can lead to a variety of bugs through idiomatic, appa
On 03:14 am, [EMAIL PROTECTED] wrote:>One thing is sure -- we urgently need something better than os.path.>It functions well but it makes hard-to-read and unpythonic code.I'm not so sure. The need is not any more "urgent" today than it was 5 years ago, when os.path was equally "unpythonic" and unr
On Sun, 01 Oct 2006 13:56:53 +1000, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>Things the PEP 355 path object lumps together:
> - string manipulation operations
> - abstract path manipulation operations (work for non-existent filesystems)
> - read-only traversal of a concrete filesystem (dir
On Fri, 29 Sep 2006 12:38:22 -0700, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>I would recommend not using it. IMO it's an amalgam of unrelated
>functionality (much like the Java equivalent BTW) and the existing os
>and os.path modules work just fine. Those who disagree with me haven't
>done a v
On Fri, 22 Sep 2006 20:55:18 +0100, Michael Foord <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] wrote:
>>On Fri, 22 Sep 2006 18:43:42 +0100, Michael Foord
>><[EMAIL PROTECTED]> wrote:
>>This wouldn't be a problem except that everyone has a different idea of
>>those requirements:).
You didn't r
On Fri, 22 Sep 2006 18:43:42 +0100, Michael Foord <[EMAIL PROTECTED]> wrote:
>I have a suggestion for a new Python built in function: 'flatten'.
This seems superficially like a good idea, but I think adding it to Python
anywhere would do a lot more harm than good. I can see that consensus is
a
On Thu, 17 Aug 2006 23:58:27 +0200, "\"Martin v. Löwis\"" <[EMAIL PROTECTED]>
wrote:
>You misunderstand indeed: the chunk reads (...)
>it currently calls uuid1, and will call uuid4 when patched.
>test_uuid4 should have never failed, except that it uses uuid1
>as the uniqueness test.
Whooops. I
On Thu, 17 Aug 2006 22:06:24 +0200, "\"Martin v. Löwis\"" <[EMAIL PROTECTED]>
wrote:
>Georg Brandl schrieb:
>>> Can somebody please fix that? If not, should we remove the uuid module
>>> as being immature?
>>
>> Patch #1541863 supposedly solves this.
>
>Ah, good. I think it should go in.
Uh, I ma
On Thu, 20 Jul 2006 14:57:07 -0400, "Phillip J. Eby" <[EMAIL PROTECTED]> wrote:
>While investigating the need to apply http://python.org/sf/1525766 I found
>that there was a modification to pkgutil during the need-for-speed sprint
>that affects the PEP 302 protocol in a backwards incompatible way.
On Tue, 18 Jul 2006 09:24:57 -0400, Jean-Paul Calderone <[EMAIL PROTECTED]>
wrote:
>On Tue, 18 Jul 2006 09:10:11 -0400, Scott Dial <[EMAIL PROTECTED]> wrote:
>>Greg Ewing wrote:
>>> Guido van Rossum wrote:
In the world where cooperative multiple inheritance
originated (C++), this would
On Mon, 17 Jul 2006 10:29:22 -0300, Johan Dahlin <[EMAIL PROTECTED]> wrote:
>I consider __getattribute__ a hack, being able to override __dict__ is less
>hackish, IMHO.
Why do you feel one is more "hackish" than the other? In my experience the
opposite is true: certain C APIs expect __dict__ to
On Sat, 15 Jul 2006 10:43:22 +0200, "\"Martin v. Löwis\"" <[EMAIL PROTECTED]>
wrote:
>People can use [-U] to improve the Unicode support in the Python standard
>library. When they find that something doesn't work, they can study the
>problem, and ponder possible solutions. Then, they can contribu
On Sat, 15 Jul 2006 14:35:08 +1000, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] wrote:
>>A __future__ import would allow these behaviors to be upgraded module-by-
>>module.
>
>No it wouldn't.
Yes it would! :)
>__future__ works solely on the semantics of different pieces of syntax,
On Sat, 15 Jul 2006 00:13:35 -0400, Terry Reedy <[EMAIL PROTECTED]> wrote:
>Is the following something like what you are suggesting?
Something like it, but...
>A Python Application Testing (PAT) machine is set up with buildbot and any
>needed custom scripts. Sometime after that and after 2.5
On Fri, 14 Jul 2006 23:38:52 +0200, "\"Martin v. Löwis\"" <[EMAIL PROTECTED]>
wrote:
>Christopher Armstrong wrote:
>> python -U is a failure for obvious reasons and a
>> __future__ import is clearly better.
>
>I disagree.
I am surprised that you do, since I thought that Chris's conclusion was
pr
On Thu, 13 Jul 2006 23:39:06 -0700, Neal Norwitz <[EMAIL PROTECTED]> wrote:
>On 7/13/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
>> a longer beta period gives *external* developers more time to catch up,
>> and results in less work for the end users.
>This is the part I don't get. For the exter
perly test to see if there *are*
problems. Keep in mind though: just because the problems are small or easy
to fix doesn't mean they're not severe. One tiny bug can prevent a program
from even starting up.
>Admittedly, I'm not as sophisticated a user as Fredrik or Glyph, but I
>su
On Thu, 13 Jul 2006 23:27:56 -0500, [EMAIL PROTECTED] wrote:
>The buildbot idea sounds excellent.
Thanks. If someone can set this up, it pretty much addresses my concerns.
>If you're concerned about noticing when a new release train is pulling out
>of the station I think it would be sufficient
301 - 400 of 417 matches
Mail list logo
