On 09/02/2010 22:22, Olemis Lang wrote:
On Tue, Feb 9, 2010 at 4:50 PM, Ben Finney wrote:
Michael Foord writes:
It seems to me that the same effect (always reporting test name) can
be achieved in _TextTestResult.getDescription(). I propose to revert
the change to
On 09/02/2010 21:50, Ben Finney wrote:
Michael Foord writes:
It seems to me that the same effect (always reporting test name) can
be achieved in _TextTestResult.getDescription(). I propose to revert
the change to TestCase.shortDescription() (which has both a horrible
name and a horrible
On 09/02/2010 21:57, Ben Finney wrote:
Michael Foord writes:
The next 'big' change to unittest will (may?) be the introduction of
class and module level setUp and tearDown. This was discussed on
Python-ideas and Guido supported them. They can be useful but are also
very easy to
On 10/02/2010 01:07, Ben Finney wrote:
Michael Foord writes:
On 09/02/2010 21:50, Ben Finney wrote:
I understood the point of ‘TestCase.shortDescription’, and indeed
the point of that particular name, was to be clear that some *other*
text could be the short description for the
On 11/02/2010 12:30, Nick Coghlan wrote:
Michael Foord wrote:
I'm not sure what response I expect from this email, and neither option
will be implemented without further discussion - possibly at the PyCon
sprints - but I thought I would make it clear what the possible
direction
On 11/02/2010 12:13, Nick Coghlan wrote:
Michael Foord wrote:
Given that the change broke something, and the desired effect can be
gained with a different change, I don't really see a downside to the
change I'm proposing (reverting shortDescription and moving the code
that add
On 11/02/2010 15:56, R. David Murray wrote:
On Thu, 11 Feb 2010 12:41:37 +, Michael Foord
wrote:
On 11/02/2010 12:30, Nick Coghlan wrote:
The test framework might promise to do the following for each test:
with get_module_cm(test_instance): # However identified
with
On 11/02/2010 22:03, Ben Finney wrote:
Michael Foord writes:
It is done. The slight disadvantage is that overriding
shortDescription on your own TestCase no longer removes the test name
from being added to the short description.
That's a significant disadvantage; it can e
On 11/02/2010 18:11, Guido van Rossum wrote:
On Tue, Feb 9, 2010 at 8:42 AM, Michael Foord wrote:
The next 'big' change to unittest will (may?) be the introduction of class
and module level setUp and tearDown. This was discussed on Python-ideas and
Guido supported them. They can
'workdir' ends up being an instance attribute,
why not make it a dict instead of a list of tuples? Or even better, a
could each resource become a class variable?
I guess we could introspect the class for every attribute that is a
resource, but I prefer some way of explicitly declaring wh
sounds like Guido isn't a fan of Test Resources *instead* of
setUpClass / module because it doesn't offer a simple solution for the
setUpModule use case and the API still needs to mature.
All the best,
Michael
By the way, how does a given test access the allocated resource
it is probably nicer
for them to appear in the API.
I guess my preferred approach is to have a default implementation, but
not to create pseudo-tests for them if they aren't used.
All the best,
Michael
testresources very neatly sidesteps this problem by just providing an API to say
&qu
On 15/02/2010 17:05, Michael Foord wrote:
[snip]
This is also an interesting point. The 'naive' implementation, which I
think I prefer, only runs the setUpModule of modules actually
containing tests. Similarly setUpClass is only called on classes with
actual tests, although they m
y impossible, by breaking the integration
mechanisms between tests and framework, and between multiple testing
frameworks.
And I am pretty sure this is not just my over-reaction; Michael still
appears to be wrestling with the problems I'm describing.
And I appreciate your input.
In a
ould then still be available and released regularly without being
tied to the Python release schedule. That assumes that the author of pytz
*wants* it to come into the standard library of course.
Michael Foord
> --
> Lennart Regebro: Python, Zope, Plone, Grok
> http://regebro.wor
alled Python
although application distribution is typically done with py2exe. The
Windows msi installer is downloaded an insane amount from Python.org.
Michael
What about using virtualenv with ironpython and jython? does it make
any sense in that context? how do we make it not impossible for the
another response, but for a different reason.
Shortcuts don't work from the shell (well, cmd.exe, at least), do
they? Can't test from here.
They do if you add .lnk to your PATHEXT environment variable.
Michael
___
Python-Dev ma
n unittest - deprecation via documentation.
Michael
--
http://www.ironpythoninaction.com/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-d
Hello Connor,
I think you have the wrong email address - this is Python-dev, an email
list for the development *of* Python.
All the best,
Michael Foord
On 23/02/2010 15:41, Connor, Craig A. wrote:
Hello, Dave;
My name is Craig Connor and I am a senior s/w developer at Northrop
s in the
place of the source file it *could* be imported from - making pyc only
distributions possible. As the pyc files are in the __pycache__ (or
whatever) directory by default they *won't* be importable without the
source files. A pyc only distribution can easily be created though with
th
ld be possible to change the API to better support
this - perhaps a default __module__ or providing an optional argument to
specify it at creation time?
Michael
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
READ CAREFULLY. By accepting and reading this email you agre
te.
Anyway, if the consensus is that it would be good to link to them then I
will update the page (which could already do with some updating by the
looks of it).
All the best,
Michael
Skip
___
Python-Dev mailing list
Python-Dev@python.org
On 26/02/2010 22:09, Brett Cannon wrote:
On Thu, Feb 25, 2010 at 16:13, Greg Ewing <mailto:greg.ew...@canterbury.ac.nz>> wrote:
Michael Foord wrote:
I thought we agreed at the language summit that if a .pyc was
in the place of the source file it *could* be impo
s the Python version
and magic number match, then it is slightly kooky but meets the use case.
All the best,
Michael
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
READ CAREFULLY. By accepting and reading this email you agree, on behalf of
your employer, to release me
it yourself - doesn't make a very convincing argument.
Michael Foord
regards
Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/pyt
The problem is doing this little dance for every path on sys.path.
Michael
A solution might be to look for the presence of the
cache directory, and only look for a .pyc in the source
directory if there is no cache directory. Testing for
the cache directory would only have to be done once
p
As far as I can tell there is no Python 2.6.5 documentation online and
the link to 3.1 docs is actually for 3.1.1 whilst the link for 3.1.1
docs is dead.
The actual documentation doesn't seem to be in the pydotorg svn
repository so I guess this a release manager issue?
Michael
e robust
against these differences, but the fact that the "obvious-thing" often
fails in subtle ways on other platforms are *one* of the reasons I don't
consider doctest to be a suitable tool for unit testing [1]. :-)
Michael
[1] It isn't the main reason and I realise that i
x27;s the *last* thing we need!
I've been thinking for a while that it would be a big help
if there were one, standardised module in the stdlib for
handling async events, and all the other gui toolkits
etc. were made to use it.
Wouldn't it have to be the Tcl event loop then?
M
ng to override functionality. This
will take a fair bit of discussion and experimentation, so I will
probably trial this in unittest2 first. It would be nice to have
something in place for the release of 3.2, but that may be ambitious.
All the best,
Michael Foord
--
http://www.ironpythoninacti
error and exit with the code 1.
That sounds like a good solution to me. +1
Michael
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
READ CAREFULLY. By accepting and reading this email you agree, on behalf of
your employer, to release me from all obligations and waivers
On 08/03/2010 01:11, Antoine Pitrou wrote:
Le Mon, 08 Mar 2010 00:51:02 +,
Michael Foord a écrit :
In other news, class and module fixtures (setUpClass /
tearDownClass / setUpModule / tearDownModule) are now implemented in
unittest (in trunk
- not yet merged to py3k). These features
>
sure to set the "Category" field to "Documentation".
There doesn't appear to be a field named "Category". Perhaps there used
to be? The correct field name now appears to be "Components".
Yep, 'Components' is correct. I&
easier for distros that share code between Python versions."
Has something changed since then?
Michael
[1] http://mail.python.org/pipermail/python-dev/2010-March/098098.html
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mai
On 12/03/2010 22:48, Michael Foord wrote:
On 12/03/2010 19:53, Barry Warsaw wrote:
On Mar 04, 2010, at 11:34 PM, Nick Coghlan wrote:
The remaining open question to my mind is whether or not there should be
a -X option to control the bytecode generation. E.g.:
-Xcache_bytecode=no (don&#
t to allow it. (The argument 'because some programmers might do
it without realising' doesn't hold much water with me.)
Michael
Regards
Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listin
the whole point of the __radd__ method. ints don't know how to
add themselves to C objects, so int.__add__ will return NotImplemented
and then Python will try C.__radd__.
All the best,
Michael
--uncut--
My first expectation would be to get a TypeError here, as ints indeed
have an __ad
__getattribute__', name)
... raise AttributeError
... def __getattr__(s, name):
... print ('__getattr__', name)
...
>>> a = x()
>>> a.b
__getattribute__ b
__getattr__ b
This list is not really an appropriate place to ask questions like this
though, comp.lang.py
f you like. But taken to the limit, the Zen
you quoted would prevent the try except clause from being used.
No, that is what "unless explicitly silenced" means - you are proposing
to silence them *without* an explicit try except clause.
Michael
_
On 20/03/2010 00:19, Glenn Linderman wrote:
On 3/19/2010 5:18 PM, Michael Foord wrote:
will probably get you buggy results, somehow or another. That's what
> design, code reviews, and testing are for.
We'll have to "agree to disagree" then. If you want error silencing
On 20/03/2010 12:00, Pascal Chambon wrote:
Michael Foord a écrit :
On 19/03/2010 18:58, Pascal Chambon wrote:
Hello
I've already crossed a bunch of articles detailing python's
attribute lookup semantic (__dict__, descriptors, order of base
class traversing...), but I have neve
ror).
Anyway, unless there are strenuous objections I intend to do this.
All the best,
Michael
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
READ CAREFULLY. By accepting and reading this email you agree, on behalf of
your employer, to release me from all obligations
have
google and gmane web interfaces as well I believe.
You can find more information at:
http://www.python.org/community/lists/
All the best,
Michael Foord
I have two files (class.py and object.py). Now, within object.py I
create two objects from the class.py file. The class.py file
Hello all,
Python 3 includes a WeakSet implementation. Any objections to me
backporting this to 2.7?
http://docs.python.org/py3k/library/weakref.html#weakref.WeakSet
I needed this in unittest and used a WeakKeyDictionary instead.
Michael
--
http://www.ironpythoninaction.com/
http
On 29/03/2010 18:16, Michael Foord wrote:
Hello all,
Python 3 includes a WeakSet implementation. Any objections to me
backporting this to 2.7?
http://docs.python.org/py3k/library/weakref.html#weakref.WeakSet
I needed this in unittest and used a WeakKeyDictionary instead.
Hmmm... I was
On 29/03/2010 19:14, Daniel Stutzbach wrote:
On Mon, Mar 29, 2010 at 12:16 PM, Michael Foord
mailto:mich...@voidspace.org.uk>> wrote:
Python 3 includes a WeakSet implementation. Any objections to me
backporting this to 2.7?
http://docs.python.org/py3k/library/weakre
On 29/03/2010 20:20, Michael Foord wrote:
On 29/03/2010 18:16, Michael Foord wrote:
Hello all,
Python 3 includes a WeakSet implementation. Any objections to me
backporting this to 2.7?
http://docs.python.org/py3k/library/weakref.html#weakref.WeakSet
I needed this in unittest and used a
On 29/03/2010 20:46, Daniel Stutzbach wrote:
On Mon, Mar 29, 2010 at 2:21 PM, Michael Foord
mailto:mich...@voidspace.org.uk>> wrote:
It should be possible to fix it with a WeakKeyDictionary instead
of WeakSet.
True. I should have said "Backporting WeakSet would make it *
really like to contribute, i can learn and improve a
lot. This is the first time that i participate in a serious, large and
complex project.
Have you any advice for me? :)
The #python-dev IRC channel on freenode is a useful place to hangout if
you have realtime quest
ilures
[42795 refs]
All the best,
Michael Foord
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
READ CAREFULLY. By accepting and reading this email you agree, on behalf of
your employer, to release me from all obligations and waivers arising from any
and all NON-NEGOTIATED agree
od to me to mix test support
library with tests themselves"? Do you mean to have it in the same
directory - where would you put it? It isn't *meant* to be a public
library, it exists only to support the test framework. In Python 3 it
has been renamed support.py, but lives in the sam
These are not really Python though, just Python like languages
that happen to be valid subsets of Python.
All the best,
Michael
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscr
nteresting to study and improve. They also need a Windows maintainer...
Michael
tjr
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-de
by the language moratorium. :-)
Michael
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
READ CAREFULLY. By accepting and reading this email you agree, on behalf of
your employer, to release me from all obligations and waivers arising from any
and all NON-NEGOTIATED ag
algorithm for Python, such as
the one used by ShedSkin, could be interesting.
All the best,
Michael
[1] Smaller devices than those targetted by
http://code.google.com/p/python-on-a-chip/
___
Python-Dev mailing list
Python-Dev@python.org
http
it right
is one thing, getting it fast enough to be useful is another (i.e. it is
a difficult problem) - but yes, could be both interesting and useful.
Michael
In addition, to-python compilers may also be interesting in various HTML
templating languages, e.g. Django templating, Zope page templa
On 06/04/2010 23:34, Michael Foord wrote:
On 06/04/2010 23:31, "Martin v. Löwis" wrote:
will...@ufpa.br wrote:
First, thank you for all opnion. Each one was considered.
I think the better question would be:
I have to develop a project that involves compilers, and being a fan of
beta 2. Not so sure
about the difflib one.
Michael
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
READ CAREFULLY. By accepting and reading this email you agree, on behalf of
your employer, to release me from all obligations and waivers arising from any
and all NON
to Antoine for the interview.
All the best,
Michael Foord
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
READ CAREFULLY. By accepting and reading this email you agree, on behalf of
your employer, to release me from all obligations and waivers arising from any
a
ld be able to
answer the question. python-dev is indeed the right place to ask.
Which is why I sent the email onto python-dev. However, no-one responded
until Steve.
All the best,
Michael
Regards,
Martin
___
Python-Dev mailing list
Python
is a
*big* need however.
All the best,
Michael
--
http://www.ironpythoninaction.com/
___
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
incompatible change.
All the best,
Michael Foord
Thanks,
--Chris
___
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/fuzzyma
elease - is not a trivial task.
All the best,
Michael Foord
Clearly it's not a priority given that nobody has seen fit to (or had
time to) reply to this mail in three weeks.
That is not surprising: none of the webmaster people would be able to
answer the question. python-dev
On 14/04/2010 12:54, Chris Jerdonek wrote:
On Wed, Apr 14, 2010 at 2:07 AM, Michael Foord
wrote:
I'm still not convinced that this isn't a backwards incompatible change - up
until now, however horrible it may be, TestLoader.loadTestsFromName only
raised an AttributeError when it
On 14/04/2010 13:46, Barry Warsaw wrote:
On Apr 14, 2010, at 10:56 AM, Michael Foord wrote:
The problem is the process that creates a new release with a 404 link to
the Mac installer with no explanation. The 2.6.5 release (as always)
caused several requests to webmaster from Mac users
On 14/04/2010 13:58, Barry Warsaw wrote:
On Apr 14, 2010, at 02:45 PM, Michael Foord wrote:
Can we amend that to having some placeholder text saying that the Mac
installer is not yet available and a link to the previous available
version please. That can then be replaced with the normal
On 14/04/2010 17:36, Bill Janssen wrote:
Michael Foord wrote:
Building the Mac installer requires volunteer time which I'm not sure
that more hardware will fix - compiling a full build of Python for Mac
OS X (with all the Python modules like Tkinter etc) requires expertise
which o
On 14/04/2010 17:41, Michael Foord wrote:
[snip...]
A Mac OS X machine (and location to keep it) for the buildbots is a
*big* need however.
At least two. You want Leopard and Snow Leopard, too.
Well - an XServe that we can run virtualisation on would be the
*ideal* solution. I think the X
On 14/04/2010 18:01, s...@pobox.com wrote:
Michael> Mac users definitely *do* expect installers. Building Python
Michael> requires, I believe, the XCode development tools to be
Michael> installed.
XCode is free, and I suspect many people have it (I do).
S
On 14/04/2010 16:53, Nick Coghlan wrote:
Michael Foord wrote:
Changing the error message to provide more useful information, possibly
including the original traceback, would certainly avoid the potential
for incompatibility. I'd be interested in seeing what other folks here
on pytho
On 14/04/2010 18:49, Steve Holden wrote:
Bill Janssen wrote:
Michael Foord wrote:
Isn't that just a matter of having the recipe written down somewhere?
Yes, that would be nice. :-) Preferably a recipe that doesn't involve
Macports or Fink which some of us ar
On 14/04/2010 19:25, Steve Holden wrote:
Michael Foord wrote:
On 14/04/2010 06:13, Ned Deily wrote:
In article,
Steve Holden wrote:
Why is it unavoidable that the Mac build will languish behind others?
Are we supporting MacOs or aren't we? If we are, why isn&
too busy.
All the best,
Michael
Regards,
Martin
--
http://www.ironpythoninaction.com/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/
l
version of Tcl/Tk 8.4 is installed in /Library/Frameworks. The system
should also not have fink or darwinports and a clean /usr/local tree
to avoid contaminating the build.
I can't verify that this is correct, I can verify it that the
build-installer script doesn't appear
On 14/04/2010 23:32, Greg Ewing wrote:
Michael Foord wrote:
Building Python requires, I believe, the XCode development tools to
be installed. Even then, building a full version of Python - with
*all* the C extensions that are part of a Python release - is not a
trivial task.
What'
happy with the Python binary installers for the Mac -
once they arrive. :-)
All the best,
Michael
On 15/04/2010 14:18, Ned Deily wrote:
In article<4bc63599.5020...@voidspace.org.uk>,
Michael Foord wrote:
A build on my machine produces output similar to:
Python build finished, b
27.4927
Type "help", "copyright", "credits" or "license" for more information.
>>> dict(**{1: 'hi'})
Traceback (most recent call last):
File "", line 1, in
TypeError: expected string for dict
#x27;dummy', 'the_other': 'Steve', 'that': 'Raymond'}
Or would we?
Nobody is proposing barring that.
If it's OK to mutate kwargs inside the function to contain
a non-string key, why isn't it OK to pass a non-string key in?
all strings) is fast.
Michael
--
http://www.ironpythoninaction.com/
___
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
ot;--version" looks wrong, though. "-v"
is almost always used for verbosity these days.
Adding -V *could* be incompatible with existing users using it for
something else. A default '--version' seems like a sensible solution to me.
Michael
Note
that even thoug
ompiling Python (amongst other things).
Michael
Regards
Antoine.
___
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/fuzzyman%40v
n, not the one with the most
backing. :-)
All the best,
Michael
--
http://www.ironpythoninaction.com/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailm
could
put on the tracker (preferably with patch and tests of course), but is
on-topic for this mailing list.
I rarely use help(...) myself (I probably should), but it sounds like a
useful enhancement.
Michael
Best wishes
Rob Cliffe
___
Pytho
On 18/04/2010 15:13, Ronald Oussoren wrote:
On 14 Apr, 2010, at 23:37, Michael Foord wrote:
On 14/04/2010 23:32, Greg Ewing wrote:
Michael Foord wrote:
Building Python requires, I believe, the XCode development tools to be
installed. Even then, building a full version of
On 24/04/2010 21:34, David Bolen wrote:
Michael Foord writes:
10.6.3 and yes I have Tcl and Tk in /Library/Frameworks. How do I
determine which versions they are?
You can use "info patchlevel" in tclsh - assuming you're running a
tclsh linked to your /Library versio
On 24/04/2010 21:50, David Bolen wrote:
Michael Foord writes:
Hmmm... looks like a 32 / 64 bit issue, which I believe may be the
expected result when trying to build on Snow Leopard (?).
I think so - I haven't tried a 64-bit build myself, but there's a
comment i
On 24/04/2010 22:16, Michael Foord wrote:
On 24/04/2010 21:50, David Bolen wrote:
Michael Foord writes:
Hmmm... looks like a 32 / 64 bit issue, which I believe may be the
expected result when trying to build on Snow Leopard (?).
I think so - I haven't tried a 64-bit build myself, but th
ished committer could become a *standard*
acceptable way to gain tracker privileges. It makes a lot of sense for
the barriers to entry for bug triaging to be substantially lower than
for commit privileges.
I agree that we should try and establish straightforward and consistent
procedures, but also
awful lot (more) we
could achieve.
All the best,
Michael Foord
Just that it's
not obvious that it's *wrong*, and therefore the decision should be
left up to the people who will do the mentoring, the supervision, and
-- if necessary -- the cleanup. If the existing tracker crew is ha
and how
they'd like it scratched.. but I wasn't ignored or rejected despite the
lack of a maintainer. Thanks to RDM for giving my issue attention.
Right, but finding counterexamples is not at all hard...
Michael
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
.
All the best,
Michael
Regards
Antoine.
___
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/fuzzyman%40voidspace.org.uk
--
http
other platforms. Even if you never intend to
repackage your project yourself following these "best practises" seems
like a good idea. (Unless you *really* don't want them packaged for
debian - in which case you now have a handy guide telling you how you
can ensure this.)
Al
2_localnet test_warnings
I believe that Victor has ensured that the buildbot failures have open
issues against, I'm just going to check that the failures I see are the
same.
Michael
IMHO it would be better to do a framework build for at least some of the OSX
buildbots because tha
e unit of measure from the old British imperial
system now defunct throughout the civilized world.
Michael
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
READ CAREFULLY. By accepting and reading this email you agree, on behalf of
your employer, to release me from all obligat
glish speaking non-metric system users? (2x4
is probably something imperial)
You we would probably strike with 100x50mm boards instead.
Michael
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-de
Hello all,
It looks like the changes to the python-dev mailman archives broke some
of the links in PEPs.
All the best,
Michael Foord
Original Message
Subject:broken mailing list links in PEP(s?)
Date: Tue, 4 May 2010 20:22:57 -0700
From: Bayle Shanks
To
*every* decision. We only need
this for PEPs where there isn't a community consensus.
Michael
Regards,
Nick.
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
READ CAREFULLY. By accepting and reading this email you agree, on behalf of
your employer, to rele
nice repr. Would this group be
interested in a patch, or is this not interesting?
Sounds good to me. Could you post the patch to http://bugs.python.org
please.
Michael Foord
Thanks,
Van
___
Python-Dev mailing list
Python-Dev@python.org
http
mparing bytecode though (plus
signature etc) and is not likely to be portable to other implementations.
Partials that wrap the *same* function (based on identity) comparing
equal seems useful enough to me.
Michael
--
http://www.ironpythoninaction.com/
__
#x27;s still work to be done before
that option can be used without having to worry about false alarms.
FWIW I *usually* run the test suite with parallelization (it is just so
much quicker) and these days *rarely* see spurious failures as a result.
This is on Mac OS X, YMMV.
Michael Fo
401 - 500 of 1851 matches
Mail list logo
