he user
ever expects to visit. The home directory, or a subdirectory thereof,
for user editable app specific data is more usual and more friendly.
All the best,
Michael Foord
--
R. David Murray www.bitdance.com
___
Pytho
fo.
Yes, great.
- activate/disable a plugin, by writing its state
- load a plugin and return it by importing the 'code link'
Also great.
and in distutils2:
- let the user configure if plugins are automatically activated when
the project is installed
- provide a end-u
g plugins across apps is a use case too: Nose could use
unittest2 plugins and vice-versa.
Hehe, well - that's a different story...
Michael
Tarek
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
READ CAREFULLY. By accepting and reading this email you agree, on
On 02/08/2010 01: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 the discovery AP
location for config
files on the Mac, including some Apple software (XCode) and Python
applications.
My preference would be to follow this established and well used convention.
Michael
It's fine to have a mac-pathname-convention-following place for such data, but
please _also_ respec
On 02/08/2010 11:48, Ronald Oussoren wrote:
On 02 Aug, 2010,at 11:48 AM, Michael Foord
wrote:
On 02/08/2010 07:18, Ronald Oussoren wrote:
On 2 Aug, 2010, at 7:18, Glyph Lefkowitz wrote:
On Aug 1, 2010, at 3:52 PM, Ronald Oussoren wrote:
On 1 Aug, 2010, at 17:22, Éric Araujo
On 02/08/2010 11:48, Ronald Oussoren wrote:
On 02 Aug, 2010,at 11:48 AM, Michael Foord
wrote:
On 02/08/2010 07:18, Ronald Oussoren wrote:
On 2 Aug, 2010, at 7:18, Glyph Lefkowitz wrote:
On Aug 1, 2010, at 3:52 PM, Ronald Oussoren wrote:
On 1 Aug, 2010, at 17:22, Éric Araujo
st.
The downside to this is that installing and activating plugins are two
separate steps. Given that each project can have a different set of
plugins enabled I don't see a way round it.
Michael
Jean-Paul
___
Python-Dev mailing list
Python-Dev@
On 02/08/2010 14:34, Ronald Oussoren wrote:
On 02 Aug, 2010,at 01:00 PM, Michael Foord
wrote:
> The only apple one that is actually used is the .CFUserTextEncoding
> file, I have an .Xcode in my home as well but that is empty and last
> updated in 2007. AFAIK current versions
On 02/08/2010 14:34, Ronald Oussoren wrote:
On 02 Aug, 2010,at 01:00 PM, Michael Foord
wrote:
> The only apple one that is actually used is the .CFUserTextEncoding
> file, I have an .Xcode in my home as well but that is empty and last
> updated in 2007. AFAIK current versions
if we have tools that create the file which location does it create it
in and so on.
Michael seems to be arguing for not using the standard OSX locations
because the Finder can't edit them anyway. Is that true?
I am saying that Ronald's suggestion is *not* a natural locatio
ess (just as for others
posting to Python-dev will be their first contact - even if they really
should be posting to comp.lang.python instead).
All the best,
Michael
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
i can
point users to e.g.
pip install pytest-figleaf
py.test --figleaf
How do you achieve this currently?
Michael
instead of also having to explain a configuration file, its location
and exact content or some magic attribute variables on some
classes.
TBH, i'd like to have pip
On 02/08/2010 19:45, Holger Krekel wrote:
On Mon, Aug 2, 2010 at 8:12 PM, Michael Foord wrote:
On 02/08/2010 19:05, Holger Krekel wrote:
On Mon, Aug 2, 2010 at 6:57 PM, Ian Bickingwrote:
Just to add a general opinion in here:
Having worked with Setuptools'
On 02/08/2010 20:36, M.-A. Lemburg wrote:
Michael Foord wrote:
On 02/08/2010 13:31, exar...@twistedmatrix.com wrote:
On 12:21 pm, m...@egenix.com wrote:
Tarek Ziad� wrote:
On Mon, Aug 2, 2010 at 3:06 AM, P.J. Eby wrote:
..
So without specific
ure you don't have to use it. For applications that
want it (like the unittest plugin system) it will be *enormously* useful
and *reduce* complexity for the user (by allowing simpler plugin
management tools).
All the best,
Michael
--
http://www.ironpythoninaction.com/
http://www.vo
standard tools, whether
that be disutils2 or package managers, to install the plugins instead of
requiring ad-hoc approaches like "drop this file in this location".
All the best,
Michael Foord
System-wise, I much prefer the later, and auto-discovery should be
left at the application
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"
re commits) until everything is green again. Buildbots
themselves can be unstable, so this may or may not be workable, and
changing
any of this will take valuable volunteer time. It's also unsexy work.
How hard is it to look at a web page?
The hard part is remembering.
Micha
st
sequence using a binary chop to find test interactions... It could take
a while to run, but was usually faster than manually trying to find them
(assuming educated guessing had already failed).
Michael
Of course, educated guessing can accelerate the proce
.
IDLE has a config directory too - currently .idlerc in ~ (on Mac OS X at
any rate).
Michael
It would be nice to define one standard location for config files used
by stdlib modules, and maybe also by third-party programs related
closely to Python development (testing tools, static code checkers
ature of the store).
Yay - let's recreate the Windows registry! A binary blob only editable
with special tools, we know how much users love that.
Michael
Then at least there would only be one file no
matter how many versions of Python were installed. Seriously. We are
already spending enough
On 12/08/2010 11:54, Tim Golden wrote:
On 12/08/2010 11:40, Michael Foord wrote:
User editable configuration files are very different from libraries. The
per user site-packages folder *should* be hidden somewhere out of the
way where you can get at them if you want them but won't stumble a
youts.
Yes - this sounds good. +1 It also provides a single place for users who
are unhappy with the defaults that we choose.
Michael
It will avoid distributions to hack Python to change those paths.
For instance, Ubuntu currently patches distutils to change the
installation paths.
So
it tests per se.
I often see patches without a test, and have assumed this is what this
stage is for - where a patch is provided without a corresponding test.
On the other hand checkboxes for fix / test / docs sounds fine.
Michael
Regards
Antoine.
_
ople don't want to change
their ideas, it would be good to have a mingw-based alternative.
Otherwise everyone is forced to convert to the Windows religion.
You mean people using Windows are forced to use Windows?
Michael
--
http://www.ironpythoninaction.com/
http://www.voidspace.or
On 13/08/2010 06:39, Stephen J. Turnbull wrote:
Michael Foord writes:
> How is ~/python not memorable or consistent? (And cross-platform
> memorability and consistency is valuable too.)
But what does "~" mean on Windows?
There is a "user directory" in Windows di
lieve that setuptools / distribute already has a mechanism for
supporting this. It basically does it with sys.path hackery.
As far as I know there are no plans to include this in distutils2 - but
Tarek can correct me if I am wrong.
All the best,
Michael
Could (and should) the online Python 3.1 docs be updated to show Python
2.7 as stable?
All the best,
Michael
Original Message
Subject:Old link text in documentation
Date: Sun, 15 Aug 2010 15:49:34 -0700
From: Aaron DeVore
To: webmas...@python.org
The link
On 18/08/2010 21:59, "Martin v. Löwis" wrote:
Am 18.08.2010 17:11, schrieb Michael Foord:
Could (and should) the online Python 3.1 docs be updated to show Python
2.7 as stable?
I think the answer is "no, it could not".
How many old documentation sets would yo
n but do not run code.
It would be backwards incompatible with usage of hasattr for dynamically
created 'members' using __getattr__ though. For what it's worth I
*agree* with you [1], but for better or worse hasattr / getattr trigger
code execution and hasattr can return Tr
nfortunate -
especially because a full workaround is pretty arcane.
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.o
On 23/08/2010 23:13, Benjamin Peterson wrote:
2010/8/23 Michael Foord:
To me hasattr *looks* like a passive introspection function, and the fact
that it can trigger arbitrary code execution is unfortunate - especially
because a full workaround is pretty arcane.
That's the danger of a dy
On 23/08/2010 23:55, Benjamin Peterson wrote:
2010/8/23 Raymond Hettinger:
On Aug 23, 2010, at 1:13 PM, Benjamin Peterson wrote:
2010/8/23 Michael Foord:
To me hasattr *looks* like a passive introspection function, and the fact
that it can trigger arbitrary code execution is unfortunate
On 24/08/2010 00:05, Benjamin Peterson wrote:
2010/8/23 Michael Foord:
On 23/08/2010 23:55, Benjamin Peterson wrote:
2010/8/23 Raymond Hettinger:
On Aug 23, 2010, at 1:13 PM, Benjamin Peterson wrote:
2010/8/23 Michael Foord:
To me hasattr *looks* like a passive introspection function
ot; or not. We
just disagree on this.
However, it is irrelevant so not really worth continuing the discussion.
Changing hasattr in this way would be backwards incompatible and so
cannot be done. Doesn't mean I have to like it though. :-)
Michael
That means
it can't figure out whether or
type object or obj
uses __slots__.
If I have time (currently on vacation with only intermittent internet
access) I'll provide an update.
Michael
Cheers,
Nick.
--
http://www.ironpythoninaction.com/
___
Python-Dev mailing list
Python-Dev@python.o
you are worried about overhead). This would
also work with the suggested "passive introspection" function.
All the best,
Michael Foord
-- at which point, you can always use the trace facility and throw an
error when any Python code runs that's not part of your debugging
tool
ciate it.
A downside (from experience with .NET which takes this approach - logic
and class names are all English but error messages are localized) is
that you then get bug reports with localized error messages. It makes
frequent visits to google translate unavoidable...
All the best,
Mi
assertEqual will never get executed since the previous line raises.
If it is dedented once then it will work (in Python 2.7 / 3.2).
Michael
+with self.assertRaises(IOError) as err:
+ssl.wrap_socket(socket.socket(), certfile=WRONGCERT,
keyfile=WRONGCERT)
+self.assertEqual
ompile Python -
defeating the purpose of the PEP. Right?
If this is the case then I agree that it should be explicit in the PEP.
All the best,
Michael
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo
PyObject_Print() of the whole C API,
not only the limited subset which is defined by PEP 384.
Definitely. On Windows it is relatively common to configure distutils to
compile extensions with Mingw, which is likely to have problems with
FILE* from the Microsoft C runtime [1].
Michael
[1] I
On 24/08/2010 08:40, Michael Foord wrote:
On 24/08/2010 01:25, Nick Coghlan wrote:
On Tue, Aug 24, 2010 at 8:15 AM, Nick Coghlan wrote:
Now, it may be worth considering an addition to the inspect module
that was basically:
def getattr_static(obj, attr):
"""Retrieve att
I've written proxy
objects several times (for various different purposes) and this would have
saved me the effort. :-)
All the best,
Michael Foord
--
http://www.voidspace.org.uk
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pytho
need fixing or auditing as to how they handle
bytes / strings.
Michael
Jean-Paul
___
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
me we didn't get to it for 3.0,
but thank you for picking this up.
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/opti
nse=&as_case=
Of course *every* standard library module will have *some* users. The
question is whether or not a handful of users justifies something being
in the standard library. If it was proposed as a new package then we
probably wouldn't want it, but as we already have it then making
and it doesn't tell us how active these
projects are, but it does indicate the real world use is greater than
zero.
Interestingly one of the uses is mailman, which uses it for its nntp
gateway maintenance.
Michael
Cheers,
Nick.
--
http://www.ironpythoninaction.com/
http://www.
On 14/09/2010 12:47, Steve Holden wrote:
On 9/14/2010 7:10 AM, Michael Foord wrote:
On 14/09/2010 12:04, Senthil Kumaran wrote:
On Tue, Sep 14, 2010 at 12:44:30PM +0200, Baptiste Carvello wrote:
Antoine> Like the email package, nntplib in py3k is broken
(because of
Anto
e changes required in nntplib.
All the best,
Michael
jesse
___
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
t the time).
http://bugs.python.org/issue5337
Michael Foord
Georg
Am 16.09.2010 14:02, schrieb raymond.hettinger:
Author: raymond.hettinger
Date: Thu Sep 16 14:02:17 2010
New Revision: 84847
Log:
Add tokenizer example to regex docs.
Modified:
python/branches/py3k/Doc/library/re.rst
Mod
ly creates the bytes representation.
I think something like this would be great for WSGI. Rather than focus
on whether bytes *or* text should be used, use a higher level object
that provides a bytes view, and (where possible/appropriate) a unicode
view too.
Michael
(of course all processing ca
d actively hinder
adoption of the better replacement.
All the best,
Michael Foord
Ideally, in future - I should be able to query static metadata (with
environment markers[2] and such) for *any* package from PyPI. And
this static metadata is simply a DIST-INFO file (instead of being a
directo
ools that they could implement today.
Why a few years?
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/python-dev/archive%40mail-archive.com
On 18/09/2010 11:48, David Cournapeau wrote:
On Sat, Sep 18, 2010 at 7:39 PM, Michael Foord
wrote:
On 18/09/2010 11:03, "Martin v. Löwis" wrote:
That's really sad. So people will have to wait a few years to efficiently
implement tools that they could implement today.
e that long until a significant number of
packages will use distutils 2. People still use very old versions
of packaging tools (e.g. the ones that come with Debian); it will
just take time to get the new tools and API adopted.
Promoting another format in preference to
ils2a1 is already out and distutils2a2
will be out soon).
All the best,
Michael Foord
On 18/09/2010 14:21, "Martin v. Löwis" wrote:
No. See above comment. If exposing this information has no value then
don't do it. If it does have value, then we are blessing it - and
therefor
On 18/09/2010 18:27, Nick Coghlan wrote:
On Sat, Sep 18, 2010 at 10:24 PM, Michael Foord
wrote:
On 18/09/2010 12:25, "Martin v. Löwis" wrote:
I think you are misunderstanding. The infrastructure will *not* depend
on the old formats. Instead, packaging that have that inform
attention getter that isn't as shouty as an actual ReST note.
I agree. Don't feel strongly about it though. (I'm sure Strunk and White
would disapprove.)
Michael
Cheers,
Nick.
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
READ CAREFULLY. By accepting a
sh Mark the best for the future and hope that he is still able to find
some way to contribute to Python.
All the best,
Michael Foord
On Wed, Sep 22, 2010 at 4:07 AM, Nick Coghlan wrote:
On Wed, Sep 22, 2010 at 8:47 PM, Antoine Pitrou
wrote:
Simply, situations like the above (Mark closing a
so there is certainly no consensus that this work
is pointless.
All the best,
Michael Foord
Regards
Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python
ster a separate (pydotorg) workflow sounds quite strong to
me.
+1
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/pyth
the bug tracker.
All the best,
Michael
ensure other fields in the tracker are filled in correctly
Likewise.
Regards,
Martin
--
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
the change is about making it easier for the dev community
(who are using/creating the development infrastructure) to update the
relevant documentation.
+1 Keeping the dev docs in the development tree sounds good to me
(however they are deployed to the web - but preferably automagically).
#x27;t actually know entirely; at a minimum, Skip Montanaro.
Wiki maintenance is discussed, along with other python.org maintenance
topics, on the pydotorg-www mailing list:
http://mail.python.org/mailman/listinfo/pydotorg-www
More wiki and website maintainers needed!
All the best,
Michael
On 25/09/2010 20:12, Paul Boddie wrote:
[snip...]
Guido van Rossum wrote:
On Fri, Sep 24, 2010 at 3:31 AM, Michael Foord
wrote:
Wiki maintenance is discussed, along with other python.org maintenance
topics, on the pydotorg-www mailing list:
http://mail.python.org/mailman/listinfo/pydotorg
x27;t get twenty other emails saying the same thing...
If you don't like Thunderbird warning you about attaching files then
switch that off!
Preferences -> Composition -> Check for missing attachments
All the best,
Michael Foord
Suggestion pending something better from rst/PEP e
es is that source data can only be
correctly decoded to text once the encoding is known. The encoding is
determined by reading the encoding cookie.
I certainly wouldn't be opposed to an API that accepts a string as well
though.
All the best,
Michael
_
On 28 September 2010 12:29, Michael Foord wrote:
> On 28/09/2010 12:19, Antoine Pitrou wrote:
>
>> On Mon, 27 Sep 2010 23:45:45 -0400
>> Steve Holden wrote:
>>
>>> On 9/27/2010 11:27 PM, Benjamin Peterson wrote:
>>>
>>>> 2010/9/27 Meador In
rtunately, Python 3 byte literals ban non-ASCII literal characters,
> so assuming an ASCII-compatible encoding for the original source is
> fairly safe.
>
The new API couldn't be ported to Python 2 •anyway•. As Nick pointed out, the
underlying tokenization happens on decode
project file names and rename 'python-wing.wpr'
to 'python-wing3.wpr'
(Option 3 could be done immediately of course.)
All the best,
Michael Foord
[1] http://wingware.com/
--
http://www.voidspace.org.uk/blog
READ CAREFULLY. By accepting and reading this email you agree,
on behalf
On 05/10/2010 12:51, Senthil Kumaran wrote:
On Tue, Oct 05, 2010 at 12:39:00PM +0100, Michael Foord wrote:
Wing 4 is now in beta and I have switched to using it. Wing 4 uses
an updated, backwards incompatible, project file format. I would
like to add a Wing 4 project file to Misc, called
jects that nonetheless don't warrant separate
distribution.
All the best,
Michael
Schiavo
Simon
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options
On 05/10/2010 13:00, Antoine Pitrou wrote:
On Tue, 05 Oct 2010 12:39:00 +0100
Michael Foord wrote:
1. rename the old file 'python-wing3.wpr' and rename 'python-wing4.wpr'
to 'python-wing.wpr'
2. delete the wing 3 project file altogether and rename
'pytho
esting, since I develop on MacOS, Linux and Windows and only
experienced the problem caused by setuptools normcase'ing distribution
names on Windows. The MacOS case also isn't in the docs.
Unless you're using Mac OS 9 you will be using posixpath and not macpath
t
't be able to do in
setup.cfg? Is the goal really to make that impossible/unnecessary?
The goal is to make it unnecessary. My understanding is that it will
still be possible to use a setup.py, just unnecessary for the vast
majority of cases.
All the best,
Michael
In
Mercurial, for example,
Market
Western Federation of Miners
Window Fitters Mate
Workforce Management
Although wfm is possibly being used here as "works for me" given the
context... ;-)
Michael
-Barry
___
Python-Dev mailing list
Python-Dev@pytho
ch version to run. Currently you have to setup
aliases yourself to do this.
So as well as pysetup.py/.exe I would like pysetup-3.2.py / .exe on
Windows please. (I'd really like a python-3.2.exe as well.)
All the best,
Michael Foord
--- Giampaolo
http://code.google.com/p/pyftpdlib/
foo" is less annoying to type than
"python -m distutils2.install foo" or "python -m setup install foo".
All the best,
Michael
Paul.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailm
h is
already accepted).
At least that was how I read what Brett wrote.
All the best,
Michael
(Benevolent Dictator for One PEP)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://ma
solution is probably not right)
that says either this bug has been verified as genuine and needs fixing
or for a feature request that it has been agreed that the feature can be
added but not yet got as far as a completed patch.
All the best,
Michael
Georg
--
http://www.voidspace.org.uk/
RE
On 18/10/2010 20:24, Georg Brandl wrote:
Am 18.10.2010 21:04, schrieb Michael Foord:
On 18/10/2010 19:18, Georg Brandl wrote:
Am 18.10.2010 20:11, schrieb Barry Warsaw:
On Oct 18, 2010, at 04:04 PM, Éric Araujo wrote:
Raymond Hettinger noticed on the tracker that there are different
for this
list. catalog-sig is possibly the right place for that. Creating a new
PyPI package for the port and forking the project is probably the best
approach.
Michael Foord
Hope this is helpful
Dave
On Tue, 2010-10-19 at 20:07 -0500, Benjamin Peterson wrote:
fpconst developers?
2010/10/
t's very clear
which python environment you're installing (or whatever other valid
action) the package into. For a stand-alone script this might not
always be as clear.
Versioned scripts would also allow that without requiring the extra
typing...
Michael
Regards
Floris
--
http
diagnosis and suggested fix seem good.
Please raise an issue on the Python bug tracker - preferably with patch
and test.
http://bugs.python.org/
All the best,
Michael Foord
Kind regards,
Adam Bielanski.
___
Python-Dev mailing list
Python-Dev@pyt
ith:
python -m unittest args
As unittest2 is a package and supports Python 2.6 (and earlier), python
-m unittest2 doesn't work so I provide a "unit2" script for accessing
its functionality. I *much* prefer using "unit2 ..." to "python -m
unittest ...".
Michael
t think it is a
price worth paying in this particular case.
All the best,
Michael Foord
--
R. David Murray www.bitdance.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/
h Python
3 (I don't have numbers though).
All the best,
Michael Foord
you can hardly call the user base imaginary.
Further, Python development (and development in general!) is *always*
focused on a "future user base" in the sense you are using it, not the
"current user base
y useful.
-1 for deprecating.
All the best,
Michael Foord
IMO, users are far better-off sticking with assertEqual() so they
can be specific about the nature of the test:
# hashable elements; ignore dups
assertEqual(set(a), set(b))
# orderable elements; dups matter, order doesn't
On 29/10/2010 23:29, Michael Foord wrote:
[snip...]
Besides de-documenting those four redundant methods,
I propose that assertItemsEqual() be deprecated just like
its brother assertSameElements(). I haven't found anyone
who accurately guesses what those methods entail based
on their m
On 29/10/2010 23:56, Michael Foord wrote:
On 29/10/2010 23:29, Michael Foord wrote:
[snip...]
Besides de-documenting those four redundant methods,
I propose that assertItemsEqual() be deprecated just like
its brother assertSameElements(). I haven't found anyone
who accurately guesses
to that time machine...
http://docs.python.org/dev/library/unittest.html#unittest.TestCase.assertAlmostEqual
All the best,
Michael Foord
(2) This leads people to write the wrong test, because
assertAlmostEqual exists and is easy to use, while the right test is
tricky and requires better under
On 30/10/2010 06:56, Raymond Hettinger wrote:
On Oct 29, 2010, at 9:11 PM, Michael Foord wrote:
Just to clarify. The following fails in Python 3:
sorted([3, 1, 2, None])
If you want to compare that two iterables containing heterogeneous
types have the same members then it is tricky to
use is annoying.
Michael
Kristján
___
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://www.voidspac
On 01/11/2010 11:33, Antoine Pitrou wrote:
On Mon, 01 Nov 2010 02:55:35 +
Michael Foord wrote:
Having a more efficient 'slow-path' and moving to that by default would
fix it. The bug is only a duplicate of the bug in sorted - caused by the
fact that sets / frozensets can't b
that "from argparse import *" will also
export all the modules you import (copy, os, re, sys, textwrap).
All the best,
Michael
Steve
--
http://www.voidspace.org.uk/
READ CAREFULLY. By accepting and reading this email you agree,
on behalf of your employer, to release me from
avoid this.
Bah Sorry about that.
Michael
--
http://www.voidspace.org.uk/
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 agreements,
licenses, terms-of-service,
On 01/11/2010 15:10, R. David Murray wrote:
On Mon, 01 Nov 2010 14:26:19 -, Michael Foord
wrote:
On 01/11/2010 11:33, Antoine Pitrou wrote:
On Mon, 01 Nov 2010 02:55:35 +
Michael Foord wrote:
Having a more efficient 'slow-path' and moving to that by default would
fix i
If that is sufficient then it would be a nice way of keeping the fast path.
(I'm not arguing that Antoine and R. David aren't correct in what
they're saying about set ordering - I'm just saying that I was surprised
and bet I'm not the only one. Bit of a dead end disc
ill works for
other mutable collections. Worth being aware that custom implementations
of standard operators will break expectations of users who aren't
intimately aware of the problem domains that the specific type may be
created for.
All the best,
Michael Foord
What I did say in the post
601 - 700 of 1851 matches
Mail list logo
