"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> Michael Hudson wrote:
>> I've been looking at this area partly to try and understand this bug:
>>
>> [ 1163563 ] Sub threads execute in restricted mode
>>
>> but I'm not sure the who
"Raymond Hettinger" <[EMAIL PROTECTED]> writes:
> I recommend that the proposed syntax be altered to be more parallel
> with the existing for-loop syntax to make it more parsable for both
> humans and for the compiler.
Although all your suggestions are improvments, I'm still -1 on the PEP.
Cheer
Keith Dart <[EMAIL PROTECTED]> writes:
> I am very concernced about something. The following code breaks with 2.4.1:
>
> fcntl.ioctl(self.rtc_fd, RTC_RD_TIME, ...)
>
> Where RTC_RD_TIME = 2149871625L
>
> In Python 2.3 it is -2145095671.
Well, you could always use "-2145095671"...
> Actually, thi
ferent to the google link feature, which only shows links to a
specific URL I believe.)
http://www.alltheweb.com/search?cat=web&cs=utf8&q=link%3Adocs.python.org&rys=0&itag=crv&_sb_lang=pref
It's where I link to as well. Be a shame to lose it. ;-)
Michael Foord
> On
es/decodes that happen in Python. Life is confusing enough
already.
Michael Foord
___
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
Guido van Rossum wrote:
> On 2/13/06, Michael Foord <[EMAIL PROTECTED]> wrote:
>
>> Phillip J. Eby wrote:
>> [snip..]
>>
>>> In fact, the 'encoding' argument seems useless in the case of str objects,
>>> and it seems i
Greg Ewing <[EMAIL PROTECTED]> writes:
> Guido van Rossum wrote:
>
>> There's also the consideration for APIs that, informally, accept
>> either a string or a sequence of objects.
>
> My preference these days is not to design APIs that
> way. It's never necessary and it avoids a lot of
> problems.
It doesn't seem to me that math.nice has an obvious meaning.
Regards,
Michael
On 2/14/06, Crutcher Dunnavant <[EMAIL PROTECTED]> wrote:
> On 2/12/06, Alan Gauld <[EMAIL PROTECTED]> wrote:
> > >> However I do dislike the name nice() - there is already a nice(
also the following cookbook recipe that uses an heuristic to
guess encoding :
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/163743
XML, HTML, or other text streams may also contain additional information
about their encoding - which be unreliable. :-)
All the best,
Micha
that might reasonably be called an 'opentext'.
textfile() seems better.
Cheers,
mwh
--
Q: What are 1000 lawyers at the bottom of the ocean?
A: A good start.
(A lawyer told me this joke.)
-- Michael Ströder, comp.lang.python
"Fredrik Lundh" <[EMAIL PROTECTED]> writes:
> Michael Hudson wrote:
>
>> > OTOH, even if we didn't rename str/unicode to text, opentext would
>> > still be a good name for the function that opens a text file.
>>
>> Hnnrgh, not really.
ion it is that is still undecided). If a
_trivial_ decision is already made, there's no need for a
PEP, but if a difficult decision has been made, then
documenting it in a PEP saves years of having to justify
it to newbies.
-- Michael Chermside
___
Python
ove either in dict or a subclass compare to five line
or smaller custom subclasses using something like the following?
def append(self, k, val):
self.setdefault(k, []).append(val)
or
def accumulate(self, k, val):
try: self[k] += val
except KeyError: self[k] = val
Michael
"Guido van Rossum" <[EMAIL PROTECTED]> writes:
> It's only me that's allowed to top-post. :-)
At least you include attributions these days!
Cheers,
mwh
--
SPIDER: 'Scuse me. [scuttles off]
ZAPHOD: One huge spider.
FORD: Polite though.
-- The Hitch-Hikers Guide to
"Guido van Rossum" <[EMAIL PROTECTED]> writes:
> I'm torn. While trying to implement this I came across some ugliness
> in PyDict_GetItem() -- it would make sense if this also called
> on_missing(), but it must return a value without incrementing its
> refcount, and isn't supposed to raise excepti
This posting is entirely tangential. Be warned.
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> It's worse than that. The return *type* depends on the *value* of
> the argument. I think there is little precedence for that:
There's one extremely significant example where the *value* of
something
"Neal Norwitz" <[EMAIL PROTECTED]> writes:
> http://www.python.org/dev/buildbot/
Wow, that's very cool!
Cheers,
mwh
--
this "I hate c++" is so old
it's as old as C++, yes
-- from Twisted.Quotes
__
"M.-A. Lemburg" <[EMAIL PROTECTED]> writes:
> Martin v. Löwis wrote:
>> M.-A. Lemburg wrote:
> True. However, note that the .encode()/.decode() methods on
> strings and Unicode narrow down the possible return types.
> The corresponding .bytes methods should only allow bytes and
> U
to be bind all checked names, but only if __contains__
returns True.
Even though it would make a poor base implementation, and these
effects aren't a good candidate for it, the code style that could
best leverage such a __contains__ exists.
Michael
--
Michael Urman http://www.tortall.net/m
>>> 1/2
0
>>> (-1) ** (1./2)
Traceback (most recent call last):
File "", line 1, in ?
ValueError: negative number cannot be raised to a fractional power
Regards,
Michael
On 2/20/06, Jonathan Barbero <[EMAIL PROTECTED]> wrote:
> Hello!
> My name is Jon
r so when I
> feel like it and have them submitted to buildbot?
>
>
Has a machine been volunteered ?
I have a spare machine and an always on connection. Would the 'right'
development tools be needed ? (In the case of Microsoft they are a touch
expensive I believe.)
All the
Martin v. Löwis wrote:
> Michael Foord wrote:
>
>> Has a machine been volunteered ?
>>
>
> Not yet.
>
>
>> I have a spare machine and an always on connection. Would the 'right'
>> development tools be needed ? (In the case o
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> Tim Peters wrote:
>> Speaking of which, a number of test failures over the past few weeks
>> were provoked here only under -r (run tests in random order) or under
>> a debug build, and didn't look like those were specific to Windows.
>> Adding -r to
ery rare
and *would* be interested in seeing real code that does break.
Especially if that code cannot be trivially rewritten to use the first
example.
All the best,
Michael Foord
>
> Analysis Script
>
> from collections import deque
> from UserList import UserList
>
A minor related point about on_missing():
Haven't we learned from regrets over the .next() method of iterators
that all "magically" invoked methods should be named using the __xxx__
pattern? Shouldn't it be named __on_missing__() instead?
howed that it would have been
better the other way.
-- Michael Chermside
___
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
return self(
> binascii.unhexlify(data))".
Am I the only one who finds the use of "self" on a classmethod to be
incredibly confusing? Can we please follow PEP 8 and use "cls"
instead?
--
Michael Hoffman <[EMAIL PROTECTED]>
European Bioinformatics Institute
___
ws 98. But I guess if noone is
volunteering to maintain the code...
Michael Foord
> Georg
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubs
h code using encode() and decode() for my opinion
to count in that matter.) But I will say that if there were no
legacy I'd prefer the tounicode() and tostring() (but shouldn't it
be 'tobytes()' i
3.0 where text == unicode?
Um... yes. Sorry, I'm not completely used to 3.0 yet. I'll need to borrow
the time machine for a little longer before my fingers really pick up on
the 3.0 names and idioms.
-- Michael Chermside
___
Python-Dev mailing li
inst the idea of the C++ rewrite as I also
fail to see the advantages outweighing the disadvantages, especially
in light of the amount of rewriting necessary to see the "advantages"
cited so far.)
Michael
--
Michael Urman http://www.tortall.net/mu/blog
__
k together, but 2b and 3c work with
either complementary option. What other options do we have?
Michael
--
Michael Urman http://www.tortall.net/mu/blog
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
U
n
of builtins (adding one more for next() won't hurt, but if we make a
practice of it we'll eventually have too many).
All told, I prefer using the underscores. I think that the first
invariant is important. But it's a judgement call, and a close one, so
I'll be
hose as identifiers in your code. Avoid only that portion of
the builtin namespace that you feel is worth keeping.
-- Michael Chermside
___
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
;absolute_import" in self.futures)
The only USE I have ever seen for code obscurity was in writing
certain vote-counting software where the true behavior needed
to remain obscure even in the face of source code publication.[1]
-- Michael Chermside
[1] http://graphics.stanford.edu/~danielrh/v
s that would break this into multiple statements.
[inspired by a recent python-list question]
--
Michael Hoffman <[EMAIL PROTECTED]>
European Bioinformatics Institute
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/lis
"Travis E. Oliphant" <[EMAIL PROTECTED]> writes:
> I'm seeing strange behavior in the Python 2.5a0 trunk that is causing
> the tests for numpy to fail. Apparently obj[...] = 1 is not calling
> PyObject_SetItem
>
> Here is a minimal example to show the error. Does anyone else see this?
>
> clas
jects in
hopes of selling it for money to comercial projects is a WONDERFUL
business model. Good luck!
-- Michael Chermside
(PS: too bad I can't buy stock in Coverity. How come all the GOOD
companies are private? I had to wait around 6 years before I could
buy stock in Google.)
bt we're going to convince Sun or Microsoft to change
their approach to threading, I think it is unwise to build such a
feature into the Python language. Supporting it in CPython only
requires (I think) no more than a very simple C extension. I think
it should stay as an exte
ents, and should do the right
thing. Nobody would expect the second import to rename both items to
q, and the first except clause would be a SyntaxError.
from foo import bar as b, quux as q
except TypeError as te, IndexError as ie
from foo import bar, quux as q
except TypeEr
[EMAIL PROTECTED] writes:
> Greg> except as :
>
> Baptiste> except with :
>
> Can I catch multiple exceptions with a single value in this case? Today, I
> write:
>
> try:
> foo()
> except (TypeError, KeyError), msg:
> print msg
>
> Either of the above seem like t
skillful Java programmers
out there. Yet it is rare to see them write "catch Throwable" when they
should use "catch Exception". That mistake is far more common among
beginning Python users. Surely we can do at least as well as Java!
-- Michael Chermside
PS: I've intentionall
"M.-A. Lemburg" <[EMAIL PROTECTED]> writes:
> The ssize_t patch is the single most disruptive patch in
> Python 2.5, so it deserves special attention.
>From your POV, maybe: from mine, it's definitely the new compiler.
Cheers,
mwh
--
I reject that approach. It has a suspicious lack
"Fredrik Lundh" <[EMAIL PROTECTED]> writes:
> Michael Hudson wrote:
>
>> > The ssize_t patch is the single most disruptive patch in
>> > Python 2.5, so it deserves special attention.
>>
>> From your POV, maybe: from mine, it's definitel
"Fredrik Lundh" <[EMAIL PROTECTED]> writes:
> neal.norwitz wrote:
>
>> +Outstanding Issues
>> +==
>> +
>> +* Require C99, so we can use // comments, named initializers, declare
>> variables
>> + without introducing a new scope, among other benefits.
>
> gcc only, in other words ?
abase.duras
database.oracle
there's no need to group the SQL databases.
-- Michael Chermside
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/op
pointing out what should have been
obvious to me from the start. The ability to use callable objects as
functions is a powerful tool in Python, and ought not be broken by decorator
inconsistencies.
-- Michael Chermside
___
Python-Dev mailing l
Armin Rigo <[EMAIL PROTECTED]> writes:
> Hi Neal,
>
> On Sun, Mar 26, 2006 at 11:39:50PM -0800, Neal Norwitz wrote:
>> test_pkg leaked [10, 10, 10] references
>
> This one at least appears to be caused by dummy (deleted) entries in the
> dictionary of interned strings. So it is not really a leak.
"Chris AtLee" <[EMAIL PROTECTED]> writes:
> On 3/28/06, Neal Norwitz <[EMAIL PROTECTED]> wrote:
>> We've made a lot of improvement with testing over the years.
>> Recently, we've gotten even more serious with the buildbot, Coverity,
>> and coverage (http://coverage.livinglogic.de). However, in or
"Thomas Wouters" <[EMAIL PROTECTED]> writes:
> While we're at it, I would like for the new __del__ (which would
> probably have to be a new method) to disallow reviving self, just
> because it makes it unnecessarily complicated and it's rarely
> needed.
I'm not sure the problem is so much that an
Greg Ewing <[EMAIL PROTECTED]> writes:
> Michael Hudson wrote:
>
>> And if we want to have a version of __del__ that can't reference
>> 'self', we have it already: weakrefs with callbacks.
>
> Does that actually work at the moment? Last I hear
"Tim Peters" <[EMAIL PROTECTED]> writes:
> [Michael Hudson]
>> ...
>> What happened to the 'get rid of __del__ in py3k' idea?
>
> Apart from its initial mention, every now & again someone asks what
> happened to it :-).
Good enough
"Neal Norwitz" <[EMAIL PROTECTED]> writes:
> On 4/3/06, Michael Hudson <[EMAIL PROTECTED]> wrote:
>> Greg Ewing <[EMAIL PROTECTED]> writes:
>>
>> > Michael Hudson wrote:
>> >
>> >> And if we want to have a version of __d
"Tim Peters" <[EMAIL PROTECTED]> writes:
> _Perhaps_ it's the case that doubles are aligned to an 8-byte boundary
> when socketmodule.c is compiled, but (for some unknown reason) only to
> a 4-byte boundary when _ssl.c is compiled. Although that seems to
> match the details in the bug report, I h
- y, x**y would not be the same as x * * y.
Michael
--
Michael Urman http://www.tortall.net/mu/blog
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailma
m.
So rather than extract the zip at install time (something purely
within setuptool's domain), you found modifying pydoc's behavior to be
a more compelling story. Are you aware that zipimport fails on 64-bit
systems in Python 2.3, or do you plan to patch over that as well?
Michael
--
"A.M. Kuchling" <[EMAIL PROTECTED]> writes:
> On Thu, Apr 20, 2006 at 07:53:55AM +0200, "Martin v. Löwis" quoted:
>> > It is flatly not possible to "fix" distutils and preserve backwards
>> > compatibility.
>
> Would it be possible to figure what parts are problematic, and
> introduce PendingDepr
Hello all,
I'm working on a parser for part of the Python language (expressions but
not statements basically). I'm using PLY to generate the parser and it's
mostly done.
I've hit on what looks like a fundamental ambiguity in the Python
grammar which is difficult to get round with PLY; and I'm won
Hello all,
I'm working on a parser for part of the Python language (expressions but
not statements basically). I'm using PLY to generate the parser and it's
mostly done.
I've hit on what looks like a fundamental ambiguity in the Python
grammar which is difficult to get round with PLY; and I'm
expression_list there)
reflects the current state of the parser.
First of all the grammar in SVN also has expression_list there *and* the
following does successfully parse to an ast (but fails when you compile
the ast) :
[x for x + 1 in y]
All the best,
Michael Foord
> On 4/24/
[EMAIL PROTECTED] wrote:
> Michael> I've hit on what looks like a fundamental ambiguity in the
> Michael> Python grammar which is difficult to get round with PLY; and
> Michael> I'm wondering *why* the grammar is defined in this way.
>
> Michae
tion); but the current
> approach allows more code sharing in the code generator.
>
> I suggest you go ahead and write the second form for your own parser.
> Coming up with the correct rules for varlist is not hard.
>
>
We've already done that, I was just checking there was
"Neil Hodgson" <[EMAIL PROTECTED]> writes:
> Martin v. Löwis:
>
>> Apparently, the status of this changed right now: it seems that
>> the 2003 compiler is not available anymore; the page now says
>> that it was replaced with the 2005 compiler.
>>
>> Should we reconsider?
>
>I expect Microsoft
Gerhard Häring <[EMAIL PROTECTED]> writes:
> Currently I'm not subscribed to python-checkins and didn't see a need
> to. Is there a need to for Python core developers?
I would say it's "encouraged".
> I think there's no better way except subscribing and defining a
> filter for SQLite-related c
"Thomas Wouters" <[EMAIL PROTECTED]> writes:
> Neal and I wrote a few tests that exercise the Py_ssize_t code on 64bit
> hardware:
>
> http://python.org/sf/1471578
>
> Now that it's configurable and integrated with test_support and all, we
> think it's time to include it in the normal testsuite. I
Hi - I'm looking at implementing Python as a scripting language for an existing C++ code base. However, there are many interdependencies between the C++ modules that I already have, and I'm not sure how to deal with this in a Python context. I thought this would be the appropriate place to pose m
a good rule of thumb (especially for a tutorial) was :
Either define ``__cmp__`` *or*
define the rich comparison operators.
Doing both is a recipe for confusion.
Michael Foord
> A bientot,
>
> Armin.
> ___
> Python-Dev mailing list
>
I will probably need to refer
to the following pages :
http://docs.python.org/ref/sequence-types.html
http://docs.python.org/lib/typesmapping.html
http://docs.python.org/ref/customization.html
Michael Foord
> (Or are the two goals --
ack and
``repr(expression)`` is clearer. If backticks were documented as a
hackish shortcut for repr then great. :-)
Michael Foord
> http://docs.python.org/ref/string-conversions.html
>
> any suggestions for a better term ? should backticks be deprecated,
>
ception. In
your example this would result in an infinite loop. Alternately the
behavior of return should be changed, and the below code would no
longer work as it does today.
>>> def foo():
... try: raise Exception
... finally: return 'Done'
...
>>> foo()
&
) on many of the C functions in the python stdlib.
So what allowing named keyword-only arguments does for us is allows us
to document this case. That is an absolute win.
Michael
--
Michael Urman http://www.tortall.net/mu/blog
___
Python-Dev mailing lis
s easy
to tweak. However the part I didn't bring up as a reason to prefer
explicit syntax for required-as-keyword is performance. I suspect
syntactic support will be faster than **kw.pop; I'm almost certain
it's faster than decorator gimmicks. I'm not certain at all that it's
a
eyword argument:
>
> "{0:{1}.{2}d}".format(a, b, c)
This violates the specification given above... it has non-escaped '}'
characters. Make up one rule and be consistant.
-- Michael Chermside
___
Python-Dev mailing list
he basic format() method
and I would have tried to take one small step at a time.
But please don't read this as saying I object to the above ideas...
I wouldn't have said anything if you hadn't asked what my approach
would be.
-- Michael Chermside
_
"Neal Norwitz" <[EMAIL PROTECTED]> writes:
> Here's what's left for 2.5 after the most recent go around.
>
> There's no owner for these items. If no one takes them, they won't
> get done and I will move them to deferred within a week:
>
> * Add @decorator decorator to functional, rename to func
Sean Reifschneider <[EMAIL PROTECTED]> writes:
> We're working at the sprint on tracking this down. I want to provide some
> history first and then what we're looking for feedback on.
>
> Steve Holden found this on Sunday, the pybench try/except test shows a ~60%
> slowdown from 2.4.3 to 2.5a2.
"Thomas Wouters" <[EMAIL PROTECTED]> writes:
> Does 'a tuple containing two Nones, a string and an int' ring a bell to
> anyone? :)
I found this one on the train (look at SyntaxError_init, it's
obvious). I also found a number of other bugs in the new exceptions.c
code, from leaks:
>>> def f():
Georg Brandl <[EMAIL PROTECTED]> writes:
> Michael Hudson wrote:
>
>> So I think I'll be reading through exceptions.c pretty carefully. I
>> don't think Sean and Richard have acquired as much paranoid
>> anal-mindedness and I have when hacking on Python
Georg Brandl <[EMAIL PROTECTED]> writes:
> Michael Hudson wrote:
>> Georg Brandl <[EMAIL PROTECTED]> writes:
>>
>>> Michael Hudson wrote:
>>>
>>>> So I think I'll be reading through exceptions.c pretty carefully. I
>>>
Michael Hudson <[EMAIL PROTECTED]> writes:
> I think I've fixed the refleaks too, but running regrtest -R :: takes
> rther a while.
I hadn't: test_codecs and test_codeccallbacks both leak, the latter
quite spectacularly (9000+ refleaks a run). The test_codecs le
hange, the error messages that report the wrong line can be
very confusing.
Michael Foord
>
> Please post your patches to SourceForge, then post links back to the
> list.
>
___
Python-Dev mailing list
Python-Dev@python.org
http://m
(x)
I presume that Michele's proposal is that inspect.isgenerator() (or
perhaps "inspect.isgenfunc()") would return True for "foo" and "bar"
but false for "foo_or_bar". Can you give a single use case for
guing me round in
> circles.
No need for thanks, ma'am; that's what we're here for.
-- LNR & Michael M Mason, cam.misc
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/
o think carefully about such things, and the documentation
on the option should give a good explanation of the tradeoffs
or at least a link to such an explanation.
-- Michael Chermside
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pyth
Greg Ewing <[EMAIL PROTECTED]> writes:
> Tim Peters wrote:
>
>> I liked benchmarking on Crays in the good old days. ...
> > Test times were reproducible to the
>> nanosecond with no effort. Running on a modern box for a few
>> microseconds at a time is a way to approximate that, provided you
"Thomas Wouters" <[EMAIL PROTECTED]> writes:
> On 6/4/06, Michael Hudson <[EMAIL PROTECTED]> wrote:
> [ For non-checkins readers: Martin Blais checked in un-unittestification
> of test_struct, which spawned questions form Neal and me about whether
> that'
"Neal Norwitz" <[EMAIL PROTECTED]> writes:
> It's June 9 in most parts of the world. The schedule calls for beta 1
> on June 14. That means there's less than 4 days until the expected
> code freeze. Please don't rush to get everything in at the last
> minute. The buildbots should remain green
ls are not easily available.
>
> Does anybody find this idea interesting?
> Does anybody think it could go into stdlib before the feature freeze for 2.5?
>
>
+1
Michael Foord
> The module consists of only one file. It imports only sys, zlib,
> struct (maybe re for testing).
>
Maybe "switch" became a keyword with the patch..
Regards,
Michael
On 6/12/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> Thomas Lee wrote:
> > Hi all,
> >
> > As the subject of this e-mail says, the attached patch adds a "switch"
> > stateme
Fredrik Lundh <[EMAIL PROTECTED]> writes:
> I just ran the PIL test suite using the current Python trunk, and the
> tests for a user-contributed plugin raised an interesting exception:
>
> ValueError: can't unpack IEEE 754 special value on non-IEEE platform
>
> fixing this is easy, but the error
Nick Maclaren <[EMAIL PROTECTED]> writes:
> As I have posted to comp.lang.python, I am not happy with Python's
> numerical robustness - because it basically propagates the 'features'
> of IEEE 754 and (worse) C99.
That's not really now I would describe the situation today.
> Yes, it's better, b
Anthony Baxter <[EMAIL PROTECTED]> writes:
> A question has been asked about branching release25-maint at the time
> of beta1. I was actually thinking about doing this for 2.5rc1 - once
> we're in release candidate stage we want to really be careful about
> checkins. I'm not sure it's worth bra
This mail never appeared on python-dev as far as I can tell, so I'm
not snipping anything.
On 19 Jun 2006, at 16:29, Nick Maclaren wrote:
> Michael Hudson <[EMAIL PROTECTED]> wrote:
>>
>>> As I have posted to comp.lang.python, I am not happy with Python's
>
Nick Maclaren <[EMAIL PROTECTED]> writes:
> Michael Hudson <[EMAIL PROTECTED]> wrote:
>>
>> This mail never appeared on python-dev as far as I can tell, so I'm
>> not snipping anything.
>
> And it still hasn't :-( I am on the list of recip
Nick Maclaren <[EMAIL PROTECTED]> writes:
>> > My intentions are to provide some numerically robust semantics,
>> > preferably of the form where straightforward numeric code (i.e. code
>> > that doesn't play any bit-twiddling tricks) will never invoke
>> > mathematically undefined behaviour withou
t
from numerous people. Please feel free to give feedback and
raise questions.
contact points: http://codespeak.net/pypy/dist/pypy/doc/contact.html
have fun,
the pypy team, (Armin Rigo, Samuele Pedroni,
Holger Krekel, Christian Tismer,
Carl Friedrich Bolz, Michael Hudson,
James Y Knight <[EMAIL PROTECTED]> writes:
> On Jun 24, 2006, at 1:29 PM, Ralf W. Grosse-Kunstleve wrote:
>
>> --- Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
>>> I think it is safe to say that Twisted is more widely used than
>>> anything
>>> Google has yet released. Twisted also has a reas
o see a way to use 'is' instead of (or inaddition
to) '==' for the comparison, but I don't have any use cases behind
this.
Michael
--
Michael Urman http://www.tortall.net/mu/blog
___
Python-Dev mailing list
Python-Dev@pyt
Benji York <[EMAIL PROTECTED]> writes:
> Nick Coghlan wrote:
>> Perhaps ImportWarning should default to being ignored, the same way
>> PendingDeprecationWarning does?
>>
>> Then -Wd would become 'the one obvious way' to debug import problems
>
> +1
I'm not sure what this would achieve -- people
add a
__reduce__ method to class UUID like
def __reduce__(self):
return (uuid, (self.int,))
together with a helper function (at module level) like
def uuid(i):
return UUID(int=i)
Please feel free to use the supplied code.
Cheers
Michael
# helper functions for determining host id
1501 - 1600 of 1850 matches
Mail list logo
