Tim Peters [EMAIL PROTECTED] writes:
Turns out it's _not_ input speed that's the problem here, and not even
mainly the speed of integer mod: the bulk of the time is spent in
int(string) (and, yes, that's also far more important to the problem
Neal was looking at than list.append time). If
Guido van Rossum wrote:
On 10/21/05, Tony Meyer [EMAIL PROTECTED] wrote:
This is over a month late, sorry, but here it is (Steve did his
threads ages ago; I've fallen really behind).
Better late than never! These summaries are awesome.
I certainly find them to be a very useful reminder of
With significant input from Fred I made some changes to xmlrpclib a couple
months ago to better integrate datetime objects into xmlrpclib. That raised
some problems because I neglected to add support for comparing datetime
objects with xmlrpclib.DateTime objects. (The problem showed up in
On 10/22/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
With significant input from Fred I made some changes to xmlrpclib a couple
months ago to better integrate datetime objects into xmlrpclib. That raised
some problems because I neglected to add support for comparing datetime
objects with
I'm still looking for more feedback on the issues raised in the last update of
PEP 343. There hasn't been much direct feedback so far, but I've rephrased and
suggested resolutions for the outstanding issues based on what feedback I have
received, and my own thoughts over the last week of so.
[EMAIL PROTECTED] wrote:
With significant input from Fred I made some changes to xmlrpclib a couple
months ago to better integrate datetime objects into xmlrpclib. That raised
some problems because I neglected to add support for comparing datetime
objects with xmlrpclib.DateTime objects.
Tim Peters [EMAIL PROTECTED] writes:
Turns out it's _not_ input speed that's the problem here, and not even
mainly the speed of integer mod: the bulk of the time is spent in
int(string) (and, yes, that's also far more important to the problem
Neal was looking at than list.append time).
On 10/22/05, Nick Coghlan [EMAIL PROTECTED] wrote:
I'm still looking for more feedback on the issues raised in the last update of
PEP 343. There hasn't been much direct feedback so far, but I've rephrased and
suggested resolutions for the outstanding issues based on what feedback I have
On Saturday 22 October 2005 07:48, [EMAIL PROTECTED] wrote:
..., I'm inclined to dump support
for marshalling and comparison of time objects altogether. Do others
agree that was a bad idea?
Very much. As Jim notes, supporting date objects is more than a little
questionable as well.
[Tim]
I assume it's the overflow-checking that's the major time sink,
[Adam Olsen]
Are you sure?
No -- that's what assume means 0.7 wink. For example, there's a
long chain of function calls involved in int(string) too.
On 10/22/05, Tim Peters [EMAIL PROTECTED] wrote:
[Tim]
I assume it's the overflow-checking that's the major time sink,
[Adam Olsen]
Are you sure?
No -- that's what assume means 0.7 wink. For example, there's a
long chain of function calls involved in int(string) too.
Michele Simionato wrote:
As other explained, the syntax would not work for functions (and it is
not intended to).
A possible use case I had in mind is to define inlined modules to be
used as bunches
of attributes. For instance, I could define a module as
module m():
a = 1
b = 2
Here's another argument against automatically decorating __context__.
What if I want to have a class with a __context__ method that returns
a custom context manager that *doesn't* involve applying
@contextmanager to a generator?
While technically this is possible with your proposal (since such a
Based on feedback from Jim and Fred, I took out date and time object
marshalling and comparison. (Actually, you can still compare an
xmlrpclib.DateTime object with a datetime.date object, because DateTime
objects can be compared with anything that has a timetuple method.) There's
a patch at
Please bear with me for a few paragraphs ;-)
One aspect of str-type strings is the efficiency afforded when all the encoding
really
is ascii. If the internal encoding were e.g. fixed utf-16le for strings, maybe
with today's
computers it would still be efficient enough for most actual string
At 01:30 AM 10/23/2005 -0400, Raymond Hettinger wrote:
FWIW, a few months ago, I reported that File New or File Open in IDLE
would crash Python as a result of the check-in implementing PEP 342.
Now, with AST checked-in, IDLE has started working again. Given the
reconfirmation, I recommend that
16 matches
Mail list logo
