hi
i face with problem when i run one sample on cygwin:
please help me
Exception happened during processing of request from ('127.0.0.1', 49154)
Traceback (most recent call last):
File "/usr/local/lib/python2.5/SocketServer.py", line 222, in handle_request
self.process_request(request, cli
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Martin,
For the most part, the information at
http://www.python.org/download/releases/2.4/msi/ assisted me with
automating a 2.7 installation on Windows XP. The following initial
attempt, however, failed to provide a working python installation.
(Messages are either "The system cannot execute the
On 4/08/2010 11:08 AM, Steve Holden wrote:
It's a little disappointing to discover that despite the relatively
large number of developers who have received MSDN licenses from
Microsoft, none if us have the time to make sure that the buildbots are
green for the 2.6.6 release.
I wonder if anyone c
On Tue, Aug 3, 2010 at 20:08, Steve Holden wrote:
> It's a little disappointing to discover that despite the relatively
> large number of developers who have received MSDN licenses from
> Microsoft, none if us have the time to make sure that the buildbots are
> green for the 2.6.6 release.
>
> I
It's a little disappointing to discover that despite the relatively
large number of developers who have received MSDN licenses from
Microsoft, none if us have the time to make sure that the buildbots are
green for the 2.6.6 release.
I wonder if anyone can think of a way we can get some Windows ski
Hello,
While Lib/_threading_local.py is meant as a fallback Python
implementation of thread-local objects, it looks like it will never be
invoked in practice. The reason is that the thread-local code in
Modules/_threadmodule.c in unconditionally compiled. Furthermore,
_threading_local.py imports
Guido van Rossum wrote:
What are the use cases for co_firstlineno? Even if it is for
displaying the source code, I can find virtue for both sides of this
argument.
Seems to me that if the code is being displayed to a
human, the decorators are an important thing to know
about, so including them
2010/8/3 "Martin v. Löwis" :
..
> I think there are many other instances where values that compare equal
> pickle differently in Python.
Indeed. For example:
>>> 1.0 == 1
True
>>> dumps(1.0) == dumps(1)
False
or for objects of the same type
>>> 0.0 == -0.0
True
>>> dumps(0.0) == dumps(-0.0)
Fa
2010/8/3 Kristján Valur Jónsson :
..
>
> These strings are different, presumably because of the (ob_refcnt == 1)
> optimization used during object pickling.
>
I have recently closed a similar issue because it is not a bug and the
problem is not present in 3.x: http://bugs.python.org/issue8738
..
>
> I just wanted to point this out. We‘ll attempt some local workarounds
> here, but it should otherwise be simple to modify pickling to optionally
> turn off this optimization and always generate the same output
> irrespective of the internal reference counts of the objects.
I think there are man
On Tue, 03 Aug 2010 20:36:36 +0200, Georg Brandl wrote:
> Am 03.08.2010 19:05, schrieb Brian Curtin:
> > On Tue, Aug 3, 2010 at 11:58, R. David Murray
> > Fixed. Apparently a line was dropped when applying a patch to
> > the tracker, but the mistake didn't surface until roundup
> >
On Tue, 03 Aug 2010 12:22:30 -0500, Benjamin Peterson
wrote:
> 2010/8/3 R. David Murray :
> > So I thought I'd break the exception chain before raising the error the
> > test harness really wants to raise. However, I can't figure out any way
> > to do that. Am I missing something, or this a mis
Hi there.
I was made aware of this oddity here:
import cPickle
reffed = "xKITTENSx"[1:-1]
print repr(cPickle.dumps(reffed))
print repr(cPickle.dumps("xKITTENSx"[1:-1]))
These strings are different, presumably because of the (ob_refcnt == 1)
optimization used during object pickling.
This might c
We're going to go ahead and cut the 2.6.6rc1 release tonight, bugs.python.org
willing. We've got a fairly clean test run on local hardware across OS X,
Linux (Debian, Ubuntu), and Brian is looking at Windows now (the buildbots are
a sad and sorry story). Ezio has done a great amount of work on ge
Am 03.08.2010 19:05, schrieb Brian Curtin:
> On Tue, Aug 3, 2010 at 11:58, R. David Murray Fixed. Apparently a line was dropped when applying a patch to
> the tracker, but the mistake didn't surface until roundup
> was restarted after the reboot.
>
> --
> R. David Murray
On 8/3/2010 8:48 AM, Antoine Pitrou wrote:
On Tue, 3 Aug 2010 22:25:01 +1000
Nick Coghlan wrote:
On Tue, Aug 3, 2010 at 1:40 PM, Eli Bendersky wrote:
The first print out correctly specifies the line "def foo" is in. However,
the second one points to the line with "@dummydecorator" instead of
2010/8/3 R. David Murray :
> Working with Catherine on an argparse bug, we ran into a test that was
> apparently failing by raising a SystemExit, when the test harness was
> supposed to be catching that error. It took us a bit to realize that
> there wasn't really a SystemExit error, but that what
Working with Catherine on an argparse bug, we ran into a test that was
apparently failing by raising a SystemExit, when the test harness was
supposed to be catching that error. It took us a bit to realize that
there wasn't really a SystemExit error, but that what we were seeing was
the SystemExit
On 8/3/2010 12:33 PM, Glyph Lefkowitz wrote:
>
> On Aug 3, 2010, at 4:28 AM, M.-A. Lemburg wrote:
>
>> I don't think that's a problem: the SQLite database would be a cache
>> like e.g. a font cache or TCSH command cache, not a replacement of
>> the meta files stored in directories.
>>
>> Such a d
On Tue, Aug 3, 2010 at 11:58, R. David Murray wrote:
> On Tue, 03 Aug 2010 16:35:01 +0200, Antoine Pitrou
> wrote:
> > Apparently you are not the only one experiencing it.
> > On #python-dev we get such notifications:
> >
> > alanwilter roundup * #9485/signal.signal/signal.alarm not
> > working
On Tue, 03 Aug 2010 16:35:01 +0200, Antoine Pitrou wrote:
> Apparently you are not the only one experiencing it.
> On #python-dev we get such notifications:
>
> alanwilter roundup * #9485/signal.signal/signal.alarm not
> working as expected: [new] I have this example code to illustrate a
> probl
On Aug 3, 2010, at 4:28 AM, M.-A. Lemburg wrote:
> I don't think that's a problem: the SQLite database would be a cache
> like e.g. a font cache or TCSH command cache, not a replacement of
> the meta files stored in directories.
>
> Such a database would solve many things at once: faster access
On Tue, Aug 3, 2010 at 9:05 AM, Nick Coghlan wrote:
> .. While I'd agree with you for a
> clean slate definition, that's not what we're dealing with here:
> "co_firstlineno" has an existing meaning, and it *isn't* "the line
> containing the def keyword", it's "the first line of the function,
> inc
On 03/08/2010 16:24, David Cournapeau wrote:
On Tue, Aug 3, 2010 at 11:35 PM, Michael Foord
wrote:
On 03/08/2010 15:19, David Cournapeau wrote:
On Tue, Aug 3, 2010 at 8:48 PM, Antoine Pitrou
wrote:
On Tue, 03 Aug 2010 10:28:07 +0200
"M.-A. Lemburg"wrote:
On Tue, Aug 3, 2010 at 11:35 PM, Michael Foord
wrote:
> On 03/08/2010 15:19, David Cournapeau wrote:
>>
>> On Tue, Aug 3, 2010 at 8:48 PM, Antoine Pitrou
>> wrote:
>>
>>>
>>> On Tue, 03 Aug 2010 10:28:07 +0200
>>> "M.-A. Lemburg" wrote:
>>>
>
> Don't forget system packaging tools like .d
Le mardi 03 août 2010 à 11:05 -0400, Raghuram Devarakonda a écrit :
> On Tue, Aug 3, 2010 at 10:14 AM, Guido van Rossum wrote:
>
> > What are the use cases for co_firstlineno? Even if it is for
> > displaying the source code, I can find virtue for both sides of this
> > argument.
>
> nose uses c
On Tue, Aug 3, 2010 at 10:14 AM, Guido van Rossum wrote:
> What are the use cases for co_firstlineno? Even if it is for
> displaying the source code, I can find virtue for both sides of this
> argument.
nose uses co_firstlineno to determine order of the test functions and
decorating a test funct
At 01:40 PM 8/3/2010 +0200, M.-A. Lemburg wrote:
If you look at the proposal, it is really just about adding a
new data store to manage a certain package type called "plugins".
Next time around, someone will want to see support for "skins" or
"themes". Then perhaps identify "script" packages, or
On 03/08/2010 15:19, David Cournapeau wrote:
On Tue, Aug 3, 2010 at 8:48 PM, Antoine Pitrou wrote:
On Tue, 03 Aug 2010 10:28:07 +0200
"M.-A. Lemburg" wrote:
Don't forget system packaging tools like .deb, .rpm, etc., which do not
generally take kindly to updating such things. For be
Apparently you are not the only one experiencing it.
On #python-dev we get such notifications:
alanwilter roundup * #9485/signal.signal/signal.alarm not
working as expected: [new] I have this example code to illustrate a
problem I am ...
alanwilter roundup * #9486/signal.signal/signal.alarm not
At 10:28 AM 8/3/2010 +0200, M.-A. Lemburg wrote:
Since you are into comparing numbers, you might want to count
the number of Zope plugins that are available on PyPI and its plugin
system has been around much longer than setuptools has been.
I don't think that proves anything, though.
Actually,
> There is a tension between the two approaches: either you want
> "auto-discovery", or you want a system with explicit registration and
> only the registered plugins would be visible to the system.
I think both are necessary. A discovery API should be available, but the
library or application sh
On Tue, Aug 3, 2010 at 8:48 PM, Antoine Pitrou wrote:
> On Tue, 03 Aug 2010 10:28:07 +0200
> "M.-A. Lemburg" wrote:
>> >
>> > Don't forget system packaging tools like .deb, .rpm, etc., which do not
>> > generally take kindly to updating such things. For better or worse, the
>> > filesystem *is*
On Tue, Aug 3, 2010 at 6:05 AM, Nick Coghlan wrote:
> On Tue, Aug 3, 2010 at 10:48 PM, Antoine Pitrou wrote:
>> Furthermore, co_firstlineno is an attribute of the code object, not the
>> function object, so it shouldn't ideally depend on whether a decorator
>> was applied or not.
>
> You cut the
Steve, thanks for your care-full reply.
Steve Holden writes:
> Particularly when the issue tracker works ...
Well, sometimes it's down.But Roundup is more flexible as
a database engine than a lot of people realize. Better docs would
help, I'm sure, but we can also create new standard queri
There's no new issue posted this morning.
I tried to post an issue, and an error occurred on submit.
So...
--
Florent
2010/8/3 Fred Drake
> On Tue, Aug 3, 2010 at 1:01 AM, Ray Allen wrote:
> > Is the tracker OK now?
>
> It's working for me.
>
>
> -Fred
>
> --
> Fred L. Drake, Jr.
> "A
On Tue, Aug 3, 2010 at 1:01 AM, Ray Allen wrote:
> Is the tracker OK now?
It's working for me.
-Fred
--
Fred L. Drake, Jr.
"A storm broke loose in my mind." --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python
On Tue, Aug 3, 2010 at 07:01, Ray Allen wrote:
> Is the tracker OK now?
Works for me.
Cheers,
Dirkjan
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/opt
Is the tracker OK now?
--
Ray Allen
Best wishes!
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On Tue, Aug 3, 2010 at 10:48 PM, Antoine Pitrou wrote:
> Furthermore, co_firstlineno is an attribute of the code object, not the
> function object, so it shouldn't ideally depend on whether a decorator
> was applied or not.
You cut the part about the inspect module (and no doubt other code)
relyi
On Tue, 3 Aug 2010 22:25:01 +1000
Nick Coghlan wrote:
> On Tue, Aug 3, 2010 at 1:40 PM, Eli Bendersky wrote:
> > The first print out correctly specifies the line "def foo" is in. However,
> > the second one points to the line with "@dummydecorator" instead of "def
> > bar". [Python 2.6]
> >
> > T
On 2 Aug, 2010, at 2:03, Tarek Ziadé wrote:
> On Mon, Aug 2, 2010 at 1:56 AM, Michael Foord
> wrote:
>> On 02/08/2010 00:46, Tarek Ziadé wrote:
>>>
>>> [snip...]
I don't think that unittest would use a distutils2 (or pkgutil) supplied
API
for activation.
>>>
>>> But
On Tue, Aug 3, 2010 at 6:56 PM, Stephen J. Turnbull wrote:
> As Steven d'Aprano pointed out (admittedly with a bit of hyperbole) a
> very high percentage of issues (about 97%) do get some response, and
> nearly 87% of all issues ever submitted to Python have already been
> closed (based on the end
On Tue, Aug 3, 2010 at 1:40 PM, Eli Bendersky wrote:
> The first print out correctly specifies the line "def foo" is in. However,
> the second one points to the line with "@dummydecorator" instead of "def
> bar". [Python 2.6]
>
> The side-effects of this behavior can be easily seen in the output o
On Tue, 03 Aug 2010 10:28:07 +0200
"M.-A. Lemburg" wrote:
> >
> > Don't forget system packaging tools like .deb, .rpm, etc., which do not
> > generally take kindly to updating such things. For better or worse, the
> > filesystem *is* our "central database" these days.
>
> I don't think that's a
On 8/3/2010 4:56 AM, Stephen J. Turnbull wrote:
> Steve Holden writes:
>
> > No, you don't, and the current discussion about how to ensure that bug
> > reporters get at least the courtesy of a relatively quick reply is one
> > of the most promising developments in building a welcoming community
Michael Foord wrote:
> On 03/08/2010 09:28, M.-A. Lemburg wrote:
>> P.J. Eby wrote:
>>
>>> At 10:37 PM 8/2/2010 +0200, M.-A. Lemburg wrote:
>>>
If that's the case, then it would be better to come up with an
idea of how to make access to that meta-data available in a less
I/O
On 03/08/2010 09:28, M.-A. Lemburg wrote:
P.J. Eby wrote:
At 10:37 PM 8/2/2010 +0200, M.-A. Lemburg wrote:
If that's the case, then it would be better to come up with an
idea of how to make access to that meta-data available in a less
I/O intense way, e.g. by having pip or other packa
FWIW, I think the best way to avoid UnicodeError is: Don't use chars
out of ASCII in Python2.
I prefer '%r' to '%s' because it escapes chars not printable or out of
ASCII with backslash.
On Mon, Jul 5, 2010 at 9:34 PM, Chris Withers wrote:
> Hi All,
>
> The documentation for the logging package d
Steve Holden writes:
> No, you don't, and the current discussion about how to ensure that bug
> reporters get at least the courtesy of a relatively quick reply is one
> of the most promising developments in building a welcoming community
> that I can remember.
C'mon Steve, it's not hard to se
P.J. Eby wrote:
> At 10:37 PM 8/2/2010 +0200, M.-A. Lemburg wrote:
>> If that's the case, then it would be better to come up with an
>> idea of how to make access to that meta-data available in a less
>> I/O intense way, e.g. by having pip or other package managers update
>> a central SQLite databa
Éric Araujo wrote:
>> What you might want to do is add new type fields to PEP 345,
>> making it easier to identify and list packages that work as
>> plugins for applications, e.g.
>>
>> Type: Plugin for MyCoolApp
>>
>> The MyCoolApp could then use the Type-field to identify all
>> installed plugins
53 matches
Mail list logo
