://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 it
isn't in use in Twisted yet):
http://codebrowse.launchpad.net/~glyph/+junk/pyexport/files
Something that I notice about
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 requirements
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
choice is
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 let
, 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() system call is entered
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:
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 standard
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
IT'S NOT
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 existing
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; current
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 :).
___
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 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 this
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
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
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
than disrespect.
If you want, I can make a decision. But I will only do that if I hear
from both sides of the debate that they are willing to accept my
choice even if it favors the other party. Can I hear agreement to
that? In particular; Phillip and Glyph, if I decide that Martin's
change is OK
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
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
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
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,
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 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 going
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
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,
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
[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
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 antipattern
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
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 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
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
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 new
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.x to
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
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 initial
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 library
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 competing
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 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 reactor the
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.
Building on an
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 of
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. But that's
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 Twisted
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 project as a
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. This
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 from
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 Twisted
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.
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't
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 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 :).
___
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 for
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
external lint utility.
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
(47,898 hits).
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
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 effect
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 seems
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 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 just
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 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-agnosticpathname code, you don't put slashes in the argumentsat all. Instead you do os.path.join("hello", "slash", "world")Many of the other things you mention are also aresult of not treating
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
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,
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 as
On 08:14 pm, [EMAIL PROTECTED] wrote:Argh, it's difficult to respond to one topic that's now spiraling intotwo conversations on two lists.[EMAIL PROTECTED] wrote:(...) people have had to spend five years putting hard-to-reados.path functions in the code, or reinventing the wheel with their
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. "Wemade this class but we don't know how it works." Actually, it'sdownright alarming coming from someone who knows Twisted inside andout yet
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 very
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
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 really
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 may be
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 must
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.
It
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 be a static
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 be a
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 is
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,
because
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 contribute
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
suspect that my usage of the language isn't all
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 external
On Wed, 12 Jul 2006 10:30:17 +1000, Michael Ellerman [EMAIL PROTECTED] wrote:
Well here's one I stumbled across the other day. I don't know if it's
legit, but it's still bad PR:
http://www.gbch.net/gjb/blog/software/discuss/python-sucks.html
Having been exhorted (or maybe I mean excoriated) by
On Thu, 13 Jul 2006 19:19:08 +0100, Michael Hudson [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] writes:
For example, did anyone here know that the new-style exceptions stuff in 2.5
caused hundreds of unit-test failures in Twisted? I am glad the change was
made, and one of our users did catch
On Thu, 13 Jul 2006 11:29:16 -0700, Aahz [EMAIL PROTECTED] wrote:
There's been some recent discussion in the PSF wondering where it would
make sense to throw some money to remove grit in the wheels; do you think
this is a case where that would help?
Most likely yes. It's not a huge
On Mon, 2005-01-31 at 08:51 -0800, Michael Chermside wrote:
However, remember that changing away from reference counting is a change
to the semantics of CPython. Right now, people can (and often do) assume
that objects which don't participate in a reference loop are collected
as soon as they
On Mon, 2005-01-17 at 07:43 -0800, Guido van Rossum wrote:
Note that you can't pickle unbound methods anyway unless you write
specific suppport code to do that; it's not supported by pickle
itself.
It's supported by Twisted. Alternatively, replace pickle with python
object serializer of my
On Mon, 2005-01-17 at 23:58 +0100, M.-A. Lemburg wrote:
If you want to make methods look more like functions,
the method object should become a subclass of the function
object (function + added im_* attributes).
I think this suggestion would fix my serialization problem as well...
but does it
On Sun, 2005-01-16 at 13:00 -0500, Phillip J. Eby wrote:
One type is the extender, ...
By contrast, an independent adapter ...
I really like the way this part of the PEP is sounding, since it really
captures two almost, but not quite, completely different use-cases, the
confusion between
On Sun, 2005-01-16 at 22:12 -0800, Guido van Rossum wrote:
What do people think? (My main motivation for this, as stated before,
is that it adds complexity without much benefit.)
***
*** 331,339
def test_im_class():
class C:
def foo(self): pass
-
On Fri, 2005-01-14 at 10:07 -0500, Phillip J. Eby wrote:
Maybe I'm missing something, but for those interfaces, isn't it okay to
keep the state in the *adapted* object here? In other words, if PointPen
just added some private attributes to store the extra data?
I have been following this
On Fri, 2005-01-14 at 19:14 -0500, Bob Ippolito wrote:
I think the idea is that it's better to have an adapter from
IBusinessThunk - IGtkUIPlugFactory, which you can use to *create* a
stateful object that complies with the IGtkUIPlug interface.
This way, you are explicitly creating
301 - 394 of 394 matches
Mail list logo
