Collin Winter wrote:
On Fri, Apr 3, 2009 at 10:28 AM, Michael Foord
wrote:
Collin Winter wrote:
As part of the common standard library and test suite that we agreed
on at the PyCon language summit last week, we're going to include a
common benchmark suite that all P
uldn't). If
something comes up I should know about you can always email or IM me
directly.
See you all on July 1. Here is to hoping I don't suffer any withdrawal.
We'll miss you. Hope you don't end up preferr
stdlib) - although we could view the benchmarks
and tests themselves as part of the standard library...
Either way we should get it underway. Collin and Jeffrey - happy to use
stdlib-sig?
Michael
Regards
Antoine.
___
Python-Dev mailing lis
Jeffrey Yasskin wrote:
On Sat, Apr 4, 2009 at 11:52 AM, Collin Winter wrote:
On Sat, Apr 4, 2009 at 7:33 AM, Michael Foord wrote:
Antoine Pitrou wrote:
Nick Coghlan gmail.com> writes:
C. Titus Brown wrote:
I vote for a separate mailing list --
a commit - and
then discover half an hour later that it conflicts with something that
was ahead of you in the queue.
Michael
Cheers,
Nick.
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
___
Python-Dev mailing l
t repr, or should
it just be considered an implementation detail of CPython?
I propose the latter, except that all implementations should
be required to satisfy eval(repr(x)) == x for finite floats x.
Short float repr should be an implementation detail, so long as
eval(repr(x)) == x still holds.
about
the possibility of being able to preserve (not change!) the function
signature.
That could be added to functools if enough people want it.
+1
Michael
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
___
more of that type of code than
implementations using bytes.
Of course, one could use message.header and message.bythdr and they'd
be the same length.
Shouldn't headers always be text?
Michael
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
__
not, is there actually a *need* to remove query parameters?
Michael
You could e.g. rename the function to update_query_params() and decide that
every parameter whose specified value is None must atcually be removed from
the URL.
Regards
Antoine.
___
Pyth
nd with "allow_dups" and just get rid of it.
Reluctant +1, it seems the best solution. You can always use {}.items()
if you still want to store the params in a mapping.
Michael
Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://
2.x code?
IIRC the proposal was to also create PYTHON3PATH and PYTHON3HOME.
Michael
Jared
___
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/
on-escape? Will a new name fully provided by a
user on his keyboard (ignoring copy and paste) almost always safely
encode?
--
Michael Urman
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe
opers what new exception might occur where? It would be a shame
to have a solid application developed under Windows start raising
encoding exceptions on linux. Would the encoding error get mapped to
an IOError for all file APIs that do this encoding?
--
Michael Urman
___
;
rather than "(4+10j)".
No objections here either. +0
Doing it sooner rather than later means that it is less likely to
disrupt anyone relying on the representation (i.e. doctests).
Michael
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
___
re* going to treat filenames as strings.
The proposed PEP allows that to work for them - whatever platform their
program runs on.
Michael
> Besides, the goal is also to makes things easier for the
> programmer. Otherwise, we'll have the same situation as in 2.x
> where many Englis
modified in order to run under
Python 2.6.
All the best,
Michael Foord
--
Best Regards
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/l
r encountered
brought up against a PEP which resolves some actual problems people encounter on
a regular basis.
For the record, I'm +1 on the PEP being accepted and implemented as soon as
possible (preferably before 3.1).
In case it's not clear, I am also +1 on the PEP as it stands.
ironmentally aware, but serialization probably will not. Should
this PEP make recommendations about how to save filenames in
configuration files?
--
Michael Urman
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python
Larry Hastings wrote:
I've written a patch for Python 3.1 that changes os.path so it handles
UNC paths on Windows:
http://bugs.python.org/issue5799
+1 for the feature. I have to deal with Windows networks from time to
time and this would be useful.
Michael
In a Windows path s
Unicode strings can occur on
the Windows filesystem, I don't find their use in PEP 383 to be a
flaw.
--
Michael Urman
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.
ry name, so I think I would stick with the previous
version.
The current unicode mode would skip the filenames you are interested
(those that fail to decode correctly) - so you would have been forced to
use the bytes mode. If you need access to the original bytes then you
should continue to d
PEP 0 generator? (It's in peps/pep0)
I'm still trying to think which letters to use!
P for Proposal (to replace Active Proposal)? Every active PEP is a
proposal...
Michael
___
Python-Dev mailing list
Python-Dev@python.org
h
s over sockets, and "utf8" will be prone to
exceptions on the very names we're trying to support right now. Is
there an advantage to not providing the the "utf8b" behavior as a
registered codec?
--
Michael Urman
___
Python
r than UTF-8, no big
deal. I could also see something like errors="roundtrip" which
explains the intention of the handler rather than the algorithm, but
is awkward on encode when it encounters unavailable Unicode
characters.
--
Michael Urman
On Thu, May 7, 2009 at 00:43, "Martin v. Löwis" wrote:
> Michael Urman wrote:
>> On Wed, May 6, 2009 at 15:42, "Martin v. Löwis" wrote:
>>> Despite there being also an error handler called "surrogates".
>>
>> Not that I have to
"surrogatereplace", errors="surrogateescape",
errors="binaryreplace", errors="binaryescape". This includes Antoine's
proposal (sans hyphen).
--
Michael Urman
___
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
ht be more convenient if *all*
attribute access did go through __getattr__ - but with that not the case
it is much better for it to be consistent rather than have to put in
specific workaround code.
All the best,
Michael
Cheers,
Nick.
--
http://www.i
mpression tools is less likely to work
cross-platform wouldn't it be both easier and better to deprecate (and
not replace) the compress support.
If there is a huge outcry adding LZW support to tarfile can be reconsidered.
Michael Foord
Regards
Antoine.
___
IronPython. I don't think this
PEP impacts the project, but it is not completely unfeasible for the
alternative implementations to do this.
In particular we have had to address the issue of the GIL and extensions
(IronPython has no GIL) and reference counting (which IronPython also
ible modules?
b) Would further restrictions in the PEP help that cause?
I've forwarded these questions to the lead developer of Ironclad
(William Reade) along with a link to the PEP. He isn't on Python-dev so
I may have to be a proxy for him in discussion. His initial response was
&
which
use .NET reflection and inspect could fallback to if sys.platform ==
'cli'. Would it be ok for me to add these to the inspect module?
Obviously the tests would only run on IronPython... The behaviour for
CPython would be unaffected.
All the best,
Michael Foord
--
http://www.ir
ython only.
Dino is developing Python - he's one of the core developers of
IronPython and I suspect he is asking whether this is intentional, and
IronPython should implement the same behaviour, or whether it is a bug.
Michael
Matthew
___
Python-D
The email contains the body of the comment so you
can follow discussions completely by email only going to the tracker to
add responses.
Michael
and keep a mental
note of where I've read up to so I know what's new. RSS would make
this simpler, certainly, but I'm not sure abou
ture
freeze on trunk for an indefinite period of time.
Michael
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Uns
"What's new in Python 2.7" list is already very impressive. :-)
Michael
Terry Jan Reedy
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python
27;t want isinstance(something, dict) to
fail because it is a dictionary from a different interpreter...
Michael
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/ma
Guido van Rossum wrote:
On Mon, Jun 15, 2009 at 9:10 AM, Michael Foord wrote:
Dino Viehland wrote:
Guido wrote:
I should add that this policy is also forced somewhat by the existence
of the "multiple interpreters in one address space" feature, which is
used e.g. by
Steven D'Aprano wrote:
On Tue, 16 Jun 2009 01:20:53 pm Cameron Simpson wrote:
I don't think all
pythons do immediate ref-counted GC.
Jython and IronPython don't. I don't know about PyPy, CLPython, Unladen
Swallow, etc.
PyPy doesn't, Unladen Swallow
ferable to discovering them after a
release. Thanks for this.
Michael Foordt
IMHO this is the best way to deal with incompatible changes,
especially in the case of superclasses, given Python's subtle and
complex inheritance semantics. It's not feasible to provide a policy
that somehow
you is
volunteering to write an official spec for Python and its libraries...
:-) (Something that would not be bad IMO - just a long and difficult
task, *especially* if you include the library along with language
semantics and APIs).
Michael
___
new keywords?
The policy (AFAICT) is that if new keywords are created they are enabled
with a future import (with a warning?) in the version they are
introduced and then enabled by default in the next version.
All the best,
Michael Foord
PEP: 387
Title: Backwards Compatibility Policy
Ve
ling lists (or their google groups
/ gmane gateways if you prefer a web interface) you will find people
willing and able to answer your questions.
All the best,
Michael Foord
I did a straight install on a XP system.
Any help would be appreciated.
Have a good
ld be:
$ python -m distutils uninstall some_package
Asymmetrical with the install of course.
Michael
It could just be:
$ python setup.py uninstall
Except then you'd need to have a complete distribution kicking around
with which to run the "python setup.py uninstall" command just to t
6.3 and
ported to trunk. Sorry for the late reply - I've been on holiday.
Michael
JP (primary author of nose)
___
Python-Dev mailing list
Python-Dev@python.org
ht
want to test the default
initialisation behavior.
Michael Foord
JP (primary author of nose)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listin
t
match both 'ConfigObj' and 'configobj'?
An abomination for which I am truly sorry - however to be precise I'm
pretty sure the setup.py specifies configobj and it is only registered
on PyPI with mixed case (which I don't believe I can change).
Michael
get_i
rt version, so if some of this is
covered in the longer explanation, I apologise now.
-1.
I agree. People with versioning issues *should* be using virtualenv.
Michael Foord
In my view, multiple version support is not at all related to PEP 302
- or to core Python in general. The import statem
ip]
Why not drop the ".re" part? You would, however, then need a new name
for the re split, eg "re_split".
Or you could make the string the pattern, eg r'whatever(.*)'.match(s).
+1 for re support built-in to strings.
Michael Foord
___
re it.
A big advantage of using ctypes is that it works cross-implementation -
on IronPython and PyPy already and on Jython soon. I'd like to see more
standard library modules use it. Distributions that choose not to
include it are crippling their Python distribution.
Michael Foord
if it is to stand a chance
of ever being included in the standard library - but with the right
expertise it is *possible* to create decent looking UIs with Tk.
Michael
(Just because
users say they want something, doesn't mean they'll actually use the
tool you provide -- perhaps th
t the changes so
far should be relatively uncontroversial, I hope.
Please post the patches to the Python bug tracker:
http://bugs.python.org
Thanks
Michael Foord
Cheers,
Jacob Rus
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pyth
;t all you need a script to *generate* the py2exe'd output
from an *installed* Python? This is the approach I take with Movable
Python which does something very similar.
n reason for bundling with py2exe is to
not be dependent (or require) an installed version of Python. For a
standalone teaching tool this seems reasonable.
Michael
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listi
--
http://www.ironpythoninaction.com
On 7 Aug 2009, at 12:06, ilya wrote:
I believe people now discuss this both on python-dev and python-ideas,
though since I'm new to both lists, I can't really tell where this
belongs.
It definitely belongs on the ideas list...
Michael
this patch includes tests
and documentation.
All the best,
Michael Foord
Previously to scroll this widget we had to write an external function
(recalling xview_moveto and xview_scroll).
With my method this operation is cleared and the same as all other widgets
(just have to
have an MSDN subscription. VS 2008
can't (reliably) be used to build extensions for 2005 I believe.
I'm sure someone will correct me if this information is incorrect.
Michael
cheers,
Chris
--
http://www.ironpythoninaction.com/
http://www.voidsp
Michael Foord wrote:
Chris Withers wrote:
Hi All,
Is the Express Edition of Visual C++ 2008 suitable for compiling
packages for Python 2.6 on Windows?
(And Python 2.6 itself for that matter...)
I would think so - all you really need is the compiler (which the
express version definitely
ern kool-aid.
(Google tells me that GoF seems to mean "Gang of Four", which is of course as
meaningful as a hip-hop band name can be :-))
Really? Discussing the GoF design patterns by name seems to be prevalent
amongst the programmers I know (yourself excluded of course...).
Michael
Antoine Pitrou wrote:
Michael Foord voidspace.org.uk> writes:
Really? Discussing the GoF design patterns by name seems to be prevalent
amongst the programmers I know (yourself excluded of course...).
Ah? I still haven't understood what "Gang of Four" is supposed to
Congratulations and thank you - this is *great* news.
Michael
Joe Amenta wrote:
Hello all,
I have released the first alpha version of 3to2 after finishing it for
my Google Summer of Code 2009(tm) project. You can get the tarball
for this release at
http://bitbucket.org/amentajo/lib3to2
d-only attributes are a great nuisance.
Michael
Cheers,
Nick.
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python
7;t realise this was invalid syntax - nor the neat trick with the
identity function to bypass the limitation.
Michael
2009/9/2 Carl Johnson
> Crossposting to Python-ideas,
>
> I asked for the same change to the grammar a couple months back on
> python-ideas.
>
> See
> http
Hello Chris,
Can you post your patch to the Python bug tracker please -
http://bugs.python.org
Patches posted to this list tend to get lost...
Thanks
Michael
Chris Frantz wrote:
Greetings,
I would like to be able to set the cipher list when creating an SSL
connection. It appears that
nt for floating point literals in
source code) and *also* for how the float type converts strings to
numbers (float('10.7') and not float('10,7')).
I assume there is a way of turning strings to floats honoring the
locale, but off the top of my head I don't know what it
pywin32 is not a standard
part of Python itself.
pywin32 has its own mailing list where you are more likely to get an
answer to your question:
http://mail.python.org/mailman/listinfo/python-win32
All the best,
Michael Foord
Thanks.
Jacky
, as it is advertised in the pdb docs
under the "alias" command), the output has the printed values interspersed
with "None"s.
Now, what is the lesser evil?
IMO not showing the extraneous Nones is preferable.
Michael
cheers,
Georg
--
htt
rs want to see an actively improving
standard library
* Bringing new best-of-breed modules into the standard library (and what
to when they fully or partly duplicate existing functionality)
All the best,
Michael
Feel free to raise discussions on other lists such as jython-dev,
catalog-sig, or wher
Antoine Pitrou wrote:
Michael Foord voidspace.org.uk> writes:
Given the long discussion on the stdlib-sig it seems like a discussion
of the standard library would be useful. Potential topics include (some
of which partially overlap each other):
[snip]
Let me suggest the follow
s (*coff* ConfigObj) only
recognises the latter (=).
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/
cided to ignore them. Please don't do this over such an important
matter.
Yes, for the syntax bikeshedding on how conditions should be expressed,
I have decided I'll be some kind of distutils dictator to end up the
endless discussions
on how they should be expressed so we can mov
--
http://www.ironpythoninaction.com
On 22 Sep 2009, at 19:15, Tarek Ziadé wrote:
On Tue, Sep 22, 2009 at 4:02 PM, Dirkjan Ochtman
wrote:
On Tue, Sep 22, 2009 at 15:55, Michael Foord > wrote:
ConfigParser recognises both, but other tools (*coff* ConfigObj)
only
recognises the lat
th this, I will draft a schedule.
+1
I'm keen to see a 2.7 release as there are good new features on trunk
(particularly in unittest :-)
Michael
Are we still planning to make 3.3 the main development focus and start
the 5 years of 2.x maintenance after this release?
Additionally, I
t Python tests. For many of them getting a
'defined' set of results and changing the tests to compare against that
rather than against CPython could be really useful - but probably a lot
of work to create.
Michael
___
Python-Dev mailing lis
*mostly* be reaching the same set of people, but at least it
spreads the net a bit wider.
Michael
Well, from the behavior of Philip and Chris, it seems that their
position is that there was insufficient time to put forward an
alternative design before the summary was posted to Python-D
not
support indexing" one.
+1 as well.
Also +1. I had a friend (an experienced programmer) who started using
Python recently. The cryptic nature of some of the error messages was a
sore point with him.
Michael
Note that the wording of error message has never been something
we gua
ast major release in the
2.x cycle?
Michael
to be
different in that several people would do the maintenance releases
(perhaps on a 6 month schedule or so) for the 5 year period, so that
would leave me with just 3.2.x (and maybe another 3.1.x release).
...
Additionally, I'm very appr
Brett Cannon wrote:
On Wed, Sep 23, 2009 at 14:19, Michael Foord wrote:
[SNIP]
Also +1. I had a friend (an experienced programmer) who started using Python
recently. The cryptic nature of some of the error messages was a sore point
with him.
Do you know which error messages? We can
at running all the existing Python code...
Michael
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/m
Raymond Hettinger wrote:
[Michael Foord]
Are we definitely decided that 2.7 will be the last major release in
the 2.x cycle?
ISTM, that would depend on the uptake for 3.2.
The users get a say in the matter.
That would be my feeling...
Michael
Raymond
--
http
Benjamin Peterson wrote:
2009/9/23 Michael Foord :
Isn't that the real compatibility test *anyway* - how successful a new
version of Python is at running all the existing Python code...
Yes, but we should have expect 3rd party code to be detecting bugs for
us that our test suite
Benjamin Peterson wrote:
2009/9/23 Michael Foord :
Benjamin Peterson wrote:
2009/9/23 Michael Foord :
Isn't that the real compatibility test *anyway* - how successful a new
version of Python is at running all the existing Python code...
Yes, but we should
/comp.lang.python/topics
All the best,
Michael Foord
here is my search method code:
search=re.compile("^#acl InternationalGroup.*\n", re.M).search(pagetext)
if search:
ret=search.group()
here i am searching for "#acl InternationalGroup" in the pageText and
when it
for Silverlight which does
IO operations using local browser storage. The use case is for an online
Python tutorial running in the browser [2]. Whilst implementing the
exception behaviour (writing to a file open in read mode, etc) I
considered improving the exception messages as they are very
ages are truly awful though as things stand,
especially for someone new to Python. Try to read from a file handle
opened in read mode for example: IOError: [Errno 9] Bad file descriptor
Michael
Cheers,
Nick.
--
http://www.ironpythoninaction.com/
http://www.v
ady
set to maintain the code. That covers the usual checklist we have for
even looking at a PEP to add a module to the standard library.
I've used argparse and really like it. I could also have done with the
subcommand support in recent changes to unittest.
+1 for inclusion.
Michael
Greg Ewing wrote:
Michael Foord wrote:
Some of the error messages are truly awful though as things stand,
especially for someone new to Python. Try to read from a file handle
opened in read mode for example: IOError: [Errno 9] Bad file descriptor
Subdividing the IOError exception won't
h the fact that argparse has a
different 'rationale' than optparse. What about an optparse
compatibility layer to make porting easier?
Although it can't cover the whole optparse API (as explained in the PEP)
it could perhaps cover most '
but discussion about the standard library in
situations like this is badly needed for 3.X.
Certainly a slow deprecation procedure, as suggested by Steven, is
warranted.
Michael
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
__
de the realm of this PEP however.
All the best,
Michael Foord
Chaining Configuration
--
Ugly code to cascade configuration
class Unset(object): pass
def cascade_value(opt=None, opt_name=None, env_name=None, cfg=None,
cfg_section=None, cfg_name=Non
Greg Ewing wrote:
Michael Foord wrote:
Well, the file type knows what mode it is opened in so catching these
errors is really not difficult at all.
Yes, in this particular case it could do some checking of
its own before making the system call. But this still has
nothing to do with the
hould hold enough information to be useful to
non-command-line users, and obviously contain error messages that are
output to stderr by default. This would allow non-command-line users to
call parse_args_with_exceptions() and handle the exceptions however they
like.
Michael
__
tement semantics for both loops and exception
handling are extremely useful and don't need cleaning up. If you have
further ideas then the Python-ideas list is the right place to discuss
potential language changes or additions.
All the best,
Michael Foord
On Tue, Sep 29, 2009 at 11:47 PM, G
verriding .exit() or
catching the exception.
Steve
Why not just catch SystemExit? If you want a custom exception the
overriding .exit() should be sufficient.
I'd be much more interested in Guido's suggestion of auto-generated
custom help messages for sub-commands.
Michael
--
htt
subcommands was already
implemented. :-)
Michael
import argparse
parser = argparse.ArgumentParser()
parser.add_argument('--foo')
subparsers = parser.add_subparsers()
parser1 = subparsers.add_parser('1')
parser1.add_argument('--bar')
parser2 = subparsers.add_parser('
Yuvgoog Greenle wrote:
On Sat, Oct 3, 2009 at 7:21 PM, Michael Foord wrote:
[snip...]
Why not just catch SystemExit? If you want a custom exception the overriding
.exit() should be sufficient.
I'd be much more interested in Guido's suggestion of auto-generated custom help
messag
a format string does not
(prima-facie) preclude string subclasses:
>>> class X(str): pass
...
>>> class Y(object):
... def __str__(self):
... return X('foo')
...
>>> a = Y()
>>> type(str(a))
Michael
I suspect other APIs will exist with simila
e fundamentally different concepts.
Michael
I should also mention this bug was not unknown. I discovered it after
Distribute 0.6 was released as I always run cutting edge interpreters.
Never bothered to report it until Distribute 0.6.1 was released which
Tarek fixed in less than a week.
or a while now though).
Michael
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/opti
:
http://groups.google.com/group/comp.lang.python/topics?lnk=li&hl=en&pli=1
All the best,
Michael Foord
Te code mentioned goes like this:
tar = tarfile.open("foo.tar.gz", "w:gz")
for filename in filenames:
tarinfo = tar.gettarinfo(filename)
if tarinfo.isreg
ess as a compatibility fix for Python 2.6 as well. :-)
Michael
___
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%4
201 - 300 of 1851 matches
Mail list logo
