On 06/06/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
On 6/5/07, Tim Delaney <[EMAIL PROTECTED]> wrote:
> I've added patch #1731330 to fix a missing Py_DECREF in
> pysqlite_cache_display. I've attached the diff to this email.
>
> I haven't actually bee
ot; provides the same value for pairs. Another way to create
the same list is "pairs = [(v, k) for (k, v) in a.iteritems()]".
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Uns
ot; provides the same value for pairs. Another way to create
the same list is "pairs = [(v, k) for (k, v) in a.iteritems()]".
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Uns
ch as
slowspitfire) would probably exercise things quite well.
http://speed.pypy.org/about/
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/o
ore
relaxed syntax, that can be added later (either in 3.3 or a later release).
Tim Delaney
___
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
>
> Brilliant suggestion! Vinay? :)
410 Gone would be more appropriate IMO. But 404 does have more mindshare.
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://m
bly a good salt. (If it is likely to change, a salt
override should be being used instead). Don't use any other IPv6 address.
In particular, never use a "temporary" IPv6" address like Windows assigns -
multiprocessing could end up with instances with different salts.
b. Take th
>
> +1 to option c (environment variable) as an override. And/or maybe an
> override on the command line.
>
That obviously should have said option b (environment variable) ...
Tim Delaney
___
Python-Dev mailing list
Python-Dev@pyt
On 30 December 2011 06:59, Tim Delaney wrote:
> +0 to exposing the salt as a constant (3.3+ only) - or alternatively
> expose a hash function that just takes an existing hash and returns the
> salted hash. That would make it very easy for anything that wanted a salted
> hash to get o
se braces.
I'd also point out that if you're expecting braces, not having them can
make the code less readable. A consistent format tends to make for more
readable code.
Cheers,
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
http:
On 3 January 2012 09:55, Raymond Hettinger wrote:
>
> On Jan 2, 2012, at 2:09 PM, Tim Delaney wrote:
>
> I'd also point out that if you're expecting braces, not having them can
> make the code less readable.
>
>
> If a programmer's mind explodes whe
he non-deterministic behaviour in pathological cases,
which we would presumably need new tests for.
Thoughts?
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.pyth
On 17 January 2012 10:14, Tim Delaney wrote:
> On 17 January 2012 09:23, Paul McMillan wrote:
>
>> This is why the "simply throw an error" solution isn't a complete fix.
>> Making portions of an interface unusable for regular users is clearly
>> a bad th
ssive conflicts would fail.
4. (Optional) in 3.3, provide a way to get a dictionary with random salt
(i.e. not wait for attack).
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
NoException__' confusing?
Seems perfectly expressive to me so long as it can't itself be raised.
Tim Delaney
___
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
ions of
> "fill this in from somewhere else", and since we really just want a
> known sentinel object that isn't None and isn't a meaningful type like
> the boolean singletons...
>
It's cute yet seems appropriate ... I quite like it.
Tim Delaney
> reset a variable explicitly to its default value.
In that case, would the best syntax be:
raise Exception() from Ellipsis
or:
raise Exception() from ...
? I kinda like the second - it feels more self-descriptive to me than "from
Ellipsis" - but there's the counter-argum
and __context__ alone, and if you're raising a *new*
> exception, then __cause__ will already be Ellipsis by default - you
> only need to use "raise X from Y" to set it to something *else*.
>
Absolutely - I can't think of a reason to want to reraise an existing
exce
a slight cost compared to previously (always importing the python
version) and you'll still be using cElementTree directly until it's
removed, but if/when it is removed you won't notice it.
Tim Delaney
___
Python-Dev mailing list
Python-Dev@p
27;s valid).
By choosing relative terms, it caters to people's desire to have the "best"
clock, but doesn't set the expectation that the behaviour is guaranteed.
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
http://ma
ng weakrefs before GC -
however, since the object would then be completely unreachable (except by C
code) I'm not sure it matters.
Tim Delaney
___
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 29 September 2012 06:51, Paul Moore wrote:
>
> Wow! I had no idea cdecimal was that close in speed to float. That's
> seriously impressive.
>
If those numbers are similar in other benchmarks, would it be accurate
and/or reasonable to include a statement along the lines of:
"comparable to flo
On 29 September 2012 07:50, Tim Delaney wrote:
> On 29 September 2012 06:51, Paul Moore wrote:
>
>>
>> Wow! I had no idea cdecimal was that close in speed to float. That's
>> seriously impressive.
>>
>
> If those numbers are similar in other benchmarks,
BTW, "What's New": http://www.python.org/download/releases/3.3.0/ still
says 80x for decimal performance.
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Uns
Also the example at
http://docs.python.org/py3k/whatsnew/3.3.html#pep-409-suppressing-exception-contextreads:
... raise AttributeError(attr) from None...
Looks like there's an elipsis there that shouldn't be.
Tim Delaney
___
slightly higher).
To be clear - I'm *not* suggesting Cython become part of the required build
toolchain. But *if* the Cython-compiled extensions prove to be
significantly faster I'm thinking maybe it could become a semi-supported
option (e.g. a HOWTO with the caveat &
e Cython on
speed.python.orgeventually (in two modes - one without hints as a
baseline and one with
hints). Of course the ideal situation would be to have every implementation
of Python 3.3 that is capable of running on the hardware contributing
numbers e.g. if/when Jython achieves 3.3 compatibility
leted from (probably most dict
literals) and it would be nice to have an iteration order for them that
matched the source code.
However if deletions occur all bets would be off. If you need to maintain
insertion order in the face of deletions, use an explicit ordereddict.
Tim Delaney
__
Apologies the top-posting (damned Gmail ...).
Tim Delaney
___
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
each collapsed changeset is for a single change I
haven't seen this be a major issue. However, I'm personally a "create a new
named branch for each task, keep all intermediate history" kind of guy (and
I get to set the rules for my team ;) so I don't see collapsed changesets
and tear it down at the end? you've then got full control of that server and
can make it do whatever you want.
Or replace the socket objects with mock objects?
Tim Delaney
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailma
Guido van Rossum wrote:
Python runs on Nokia cell phones (the high-end ones, anyway) and has
support from Nokia!
Pretty cool all around.
I couldn't find out which version of Python is supported - have they told
you?
Cheers.
Tim Delaney
___
P
it's possible to override get_foo in subclasses if done
right ...
Two approaches are here:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/408713
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailma
:
return obj.next(exception) # Will raise an appropriate exception
return obj.next()
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/opt
names, and I don't think this
should be one of them - it has obvious uses other than as an implementation
detail.
PS The first person to replace builtin __next__ in order to implement
a "next hook" of some sort, gets shot :-)
Damn! There goes the use case ;)
Tim Delaney
7;s concern about distinguishing between
exceptions and values passed to the generator. Anything except StopIteration
or ContinueIteration will be presumed to be an exception and will be raised.
Anything passed via ContinueIteration is a value.
Tim Delaney
__
Tim Delaney wrote:
Also, within a for-loop or block-statement, we could have ``raise
`` be equivalent to::
arg =
continue
For this to work, builtin next() would need to be a bit smarter ...
specifically, for an old-style iterator, any non-Iteration exception would
need to be re-raised
another value.
when discussing StopIteration?
Tim Delaney
___
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
tely,
I think it's at work - don't seem to have a copy here :(
Obviously, this isn't applicable to as many cases, but it might be
interesting to compare what kind of results this produces compared to
LOAD_SELF/SELF_ATTR.
Tim Delaney
___
Python-Dev
Tim Delaney wrote:
> that also binds all attribute accesses all the way down into a single
> constant call e.g.
>
>LOAD_FAST 0
>LOAD_ATTR 'a'
>LOAD_ATTR 'b'
>LOAD_ATTR 'c'
>LOAD_ATTR 'd'
>
> is bo
ards MinGW becoming the official Windows build platform.
There was a considerable amount of angst with the 2.4 release that can be
blamed solely on the CRT change (and hence different DLLs to link to). And
with them deprecating ISO standard functions ...
Tim Delaney
_
101 - 141 of 141 matches
Mail list logo