Thanks for asking a question that triggered an enlightening discussion!
On 10/25/2018 5:13 PM, Stephane Wirtel wrote:
> Hi all,
>
> After your feedback, I have my answer.
>
> I understand the your points of view and I don't want to change any part
> of code for os.system and subprocess, I don't w
ds/1645/steps/2/logs/stdio
https://buildbot.python.org/all/#/builders/161/builds/328/steps/2/logs/stdio
Help appreciated.
Michael
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mai
My short comment: +1
My longer comment: for someone who is not trying to be caught up in "internals"
I find it extremely difficult to work with the "default" approach described
below - trying to mentally understand, and remember what those macros mean/do
as I got "bug-hunting".
Ultimately, hav
test was, and I'll look at it on my server manually.
If it succeeds - I would also appreciate a heads-up!
Thanks,
Michael
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://
g a single file and add some extra flags (-qsource or -qlist)
which generates a .lst file and shows what the compiler did (macro expansion,
etc..)
If you would like me to attempt this - just let me know. Although it may take
24 hours from that request before I can fulfill it.
Regards,
Michael
On Fri, Nov 9, 2018 at 4:33 PM Victor Stinner wrote:
> It uses an opt-in option (Py_NEWCAPI define -- I'm not sure about the
> name) to get the new API. The current C API is unchanged.
>
While one can hope that this will be the only time the C API will be
revised, it may be better to number it i
On Thu, Nov 29, 2018 at 1:33 PM Nathaniel Smith wrote:
> > > https://anaconda.com/
> > > https://www.activestate.com/products/activepython/
> > > http://winpython.github.io/
> > > http://python-xy.github.io/
> > > https://www.enthought.com/product/canopy/
> > > https://software.intel.com/en-us/di
On Thu, Nov 29, 2018 at 5:48 PM Oscar Benjamin
wrote:
> There have been significant improvements in pip, pypi and the whole
> packaging ecosystem in recent years thanks to the efforts of many
> including Paul. I've been pushing students and others to Anaconda
> simply because I knew that at minim
Waiting on review
https://github.com/python/cpython/pull/8014
On Thu, Jan 31, 2019, 12:04 AM INADA Naoki I'm sorry, configparser is changed already.
> https://bugs.python.org/issue33504
>
> On Thu, Jan 31, 2019 at 4:52 PM INADA Naoki
> wrote:
> >
> > Hi,
> >
> > csv.DictReader uses OrderedDict b
wrong how the Python community "sees the world".
> On 2/21/2019 11:26 AM, Michael wrote:
> It seems so - however, Is there something such as PyUnsignedLong and is
> that large enough for a "long long"? and if it exists, would that make
> the value positive (for the
> The main question is if anyone ever used Py_TRACE_REFS? Does someone
> use sys.getobjects() or PYTHONDUMPREFS environment variable?
I used sys.getobjects() today to track down a memory leak in the
mypyc-compiled version of mypy.
We were leaking memory badly but no sign of the leak was showing u
I've submitted PEP 591 (Adding a final qualifier to typing) for discussion
to typing-sig [1].
Here's the abstract:
This PEP proposes a "final" qualifier to be added to the ``typing``
module---in the form of a ``final`` decorator and a ``Final`` type
annotation---to serve three related purposes:
*
On Mon, Apr 15, 2019 at 4:06 PM Nathaniel Smith wrote:
> On Mon, Apr 15, 2019, 15:27 Michael Sullivan wrote:
>
>> > The main question is if anyone ever used Py_TRACE_REFS? Does someone
>> > use sys.getobjects() or PYTHONDUMPREFS environment variable?
>>
>> I
On Mon, Apr 15, 2019 at 8:12 PM Nathaniel Smith wrote:
> On Mon, Apr 15, 2019 at 5:00 PM Michael Sullivan wrote:
> >
> > I've submitted PEP 591 (Adding a final qualifier to typing) for
> discussion to typing-sig [1].
>
> I'm not on typing-sig [1] so I'm r
On Tue, Apr 16, 2019 at 2:11 AM Victor Stinner wrote:
> Hi Michael,
>
> Do you know the tracemalloc module? Did you try it? It works on a
> regular Python (compiled in debug mode).
>
> I would be curious to know if tracemalloc also allows you to track the
> memory leak.
&g
ssword that can write to
> https://pypi.org/project/mock/ ...
I can add you as a maintainer. Ping me off-list.
Michael
>
>> If I understand correctly this is just the hg style branch backport
>> consequence, multiple copies of a change. Should be safe to skip thos
so not documented. I propose
> removing this sorted order in 3.9 and to preserve the original order. The
> change is straightforward and I can add a PR if this change is accepted.
+1 go ahead. The test that will fail was synthetic for the sorting and it won't
cause real tests to fail
!,
Michael
OpenPGP_0x722BFDB61F396FC2.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https
Dear all,
After several months of absence - my first manual build surprised me by
the addition of the -qalias=noansi.
Before I open an issue - maybe it is not that important - I am trying to
find what brought it in. It looks to be a change in behavior in
configure(.ac) - starting with Python
the
Python parser generator world. Being stable and widely used, with an "available
maintainer", makes it an ideal candidate for standard library inclusion.
Michael
> LALR(1) parsers have been around for a long time, are generally known to
> anyone who's used yacc/bison, and woul
I can add
them to the agenda.
All the best,
Michael Foord
--
http://www.voidspace.org.uk/
May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing
http://www.sqlite.org/diff
On 28 Feb 2013, at 07:36, Georg Brandl wrote:
> Am 27.02.2013 17:51, schrieb Michael Foord:
>> Hello all,
>>
>> PyCon, and the Python Language Summit, is nearly upon us. We have a good
>> number of people confirmed to attend. If you are intending to come to the
>
On 27 Feb 2013, at 18:50, Antoine Pitrou wrote:
> On Wed, 27 Feb 2013 16:51:16 +
> Michael Foord wrote:
>
>> Hello all,
>>
>> PyCon, and the Python Language Summit, is nearly upon us. We have a good
>> number of people confirmed to attend. If
On 27 Feb 2013, at 19:01, fwierzbi...@gmail.com wrote:
> On Wed, Feb 27, 2013 at 8:51 AM, Michael Foord
> wrote:
>> If you have other items you'd like to discuss please let me know and I can
>> add them to the agenda.
>
> I'd like to discuss merging Jython&#
On 28 Feb 2013, at 03:42, Barry Warsaw wrote:
> On Feb 27, 2013, at 04:51 PM, Michael Foord wrote:
>
>> If you have other items you'd like to discuss please let me know and I can
>> add them to the agenda.
>
> I'd like to have some discussions around
On 3 Mar 2013, at 01:29, Trent Nelson wrote:
> On Wed, Feb 27, 2013 at 08:51:16AM -0800, Michael Foord wrote:
>> If you have other items you'd like to discuss please let me know and I
>> can add them to the agenda.
>
>Hmm, seems like this might be a g
ole lot of subunit
context was required to understand the specific proposal you're making for the
TestResult. It also *seems* like you're redesigning the TestResult for a single
use case (distributed testing) with an api that looks quite "odd" for anything
that isn
#x27;t work) has "unit2" as a shortcut. So it has an
advantage over the standard library version here.
I'd like to see pyunit as a short-cut for "python -m unittest discover", with a
"pyunit-3.x" variant too.
Barry objects that Linux distributions won't want to
On 28 Feb 2013, at 13:49, Brett Cannon wrote:
>
>
>
> On Thu, Feb 28, 2013 at 6:34 AM, Michael Foord
> wrote:
>
> On 28 Feb 2013, at 07:36, Georg Brandl wrote:
>
> > Am 27.02.2013 17:51, schrieb Michael Foord:
> >> Hello all,
> >>
>
>>
>> --Berker
>
> setup.py's setup(test_suite="x")... not sure if this is a distutils or
> setuptools feature. PEP 426 has an extension mechanism that could do
> the job.
This is a setuptools extension. There was some discussion for
packaging/distuti
Windows system (more accurately, over the
> Windows API).
>
It has been used incorrectly in a few places in the Python standard library -
Windows support code that would work correctly on IronPython is skipped because
os.name is *not* 'nt' on IronPython. That was
On 5 Mar 2013, at 00:23, Robert Collins wrote:
> On 5 March 2013 13:21, Michael Foord wrote:
>>
>
>> We can certainly talk about it - although as Guido says, something specific
>> may be easier to have a useful discussion about.
>>
>> Reading through
pressed. As a selfish
> side-effect, I want to reduce the amount of guesswork I need to perform in
> order to know how to run a package's test when I `$vcs clone` their
> repository. ;)
>
Distutils2 had a way of specifying this in the me
case. That doesn't solve 'how to introspect a package test suite' but
> for distro packagers - and large scale CI integration - that doesn't
> matter.
>
> For instance testrepository offers a setuptools extension to let it be
> used trivially, I believe nose do
scover" is just too long.
>>>
>>
>> Command-line options for advanced capabilities can get long, yes.
>
> The whole point is that discovery is not "advanced capability", it's
> pretty basic by today's standards. So it should actually be th
he
standard library testing capabilities to better support this use case - but I
wouldn't like to design their apis around that as the sole use case. :-)
Michael
>
> -glyph
>
> ___
> Python-Dev mailing list
> Python-Dev@python.or
On 5 Mar 2013, at 05:39, Jeff Hardy wrote:
> On Mon, Mar 4, 2013 at 4:39 PM, Michael Foord
> wrote:
>>
>> On 1 Mar 2013, at 18:38, Antoine Pitrou wrote:
>>
>>> On Fri, 1 Mar 2013 09:32:23 -0500
>>> Barry Warsaw wrote:
>>>>
>&
On 19 Mar 2013, at 17:26, Antoine Pitrou wrote:
> On Wed, 20 Mar 2013 01:22:58 +0100 (CET)
> michael.foord wrote:
>> http://hg.python.org/cpython/rev/684b75600fa9
>> changeset: 82811:684b75600fa9
>> user:Michael Foord
>> date:Tue Mar 19
On 20 Mar 2013, at 00:09, Antoine Pitrou wrote:
> On Tue, 19 Mar 2013 21:44:15 -0700
> Michael Foord wrote:
>>
>> mock_open makes it easy to put a StringIO in place if that's what you want.
>> It's just a simple helper function for providing some known dat
On 20 Mar 2013, at 01:03, Antoine Pitrou wrote:
> On Wed, 20 Mar 2013 00:50:27 -0700
> Michael Foord wrote:
>>
>> If you want to add support for additional functionality feel free to propose
>> a patch.
>
> This isn't about additional functionality, thi
On 19 Mar 2013, at 23:09, "Gregory P. Smith" wrote:
>
> On Tue, Mar 19, 2013 at 9:44 PM, Michael Foord
> wrote:
>>
>> On 19 Mar 2013, at 17:26, Antoine Pitrou wrote:
>>
>> > On Wed, 20 Mar 2013 01:22:58 +0100 (CET)
>> > micha
e_effect that returns iterator.
>
> Patch by Michael Ford.
>
> files:
> Lib/unittest/mock.py | 2 ++
> Lib/unittest/test/testmock/testmock.py | 4
> 2 files changed, 6 insertions(+), 0 deletions(-)
>
>
> diff --git a/Lib/unittest/mock.py
iven Enum? While I like the idea of catching
mistaken collisions, I've seen far too many C/C++ scenarios where multiple
names map to the same value. This does raise questions, as it's unclear
whether each name should get its own representation, or whether it's better
to let Dup
On Fri, Apr 12, 2013 at 9:30 AM, Barry Warsaw wrote:
> On Apr 12, 2013, at 09:03 AM, Michael Urman wrote:
> >(For the latter behavior, would adding DupEnum.name2 = DupEnum.name1 after
> >the class declaration work today?)
>
> Yes, but the repr/str of the alias will sh
changes are clearly beyond the scope of PEP 435, otherwise a true
enum syntax might have been born. So that leaves us with requiring the
caller to provide it.
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/archive%40mail-archive.com
ches) are more painful to express in
doctests
and so on...
However doctests absolutely rock for testing documentation / docstring
examples. So I'm with Raymond on this one.
All the best,
Michael
> That serves two very good purposes in one. How can you beat that?
> The issues of tea
f course). Not being able to tell the difference between a module level
function and an unbound method caused some pain then. (I worked round it by
flowing the information about where the object came from through the code but
it did add ugliness).
Michael
> --Guido
>
> On Thu, Jul 4, 201
On 5 Jul 2013, at 12:07, "Martin v. Löwis" wrote:
> Am 05.07.13 11:23, schrieb Michael Foord:
>> I've also lamented the death of bound methods in Python 3 for mock
>> "autospeccing". Autospec introspects objects and provides mock
>> objects with
em?
>>
>
> My guess is that Michael's design lets mock objects be introspected as well,
> i.e. they don't appear as magical as they really are to the user code.
>
This is also true. Doing it up front has some conveniences - for example
dir(...) works correctly.
Mi
ough until July 2015.
http://support.microsoft.com/lifecycle/search/default.aspx?alpha=Windows+Server+2003+R2
Michael
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/ma
98
The agreed on approach just needs doing.
Michael
>
> What do you think of a change like this?
>
> $ hg diff
> diff -r 3bd55ec317a7 Lib/unittest/suite.py
> --- a/Lib/unittest/suite.py Thu Aug 01 23:57:21 2013 +0200
> +++ b/Lib/unittest/suite.py Fri Aug 02
Sent from my iPhone
On 2 Aug 2013, at 19:19, Antoine Pitrou wrote:
> Le Fri, 2 Aug 2013 18:13:13 +0300,
> Michael Foord a écrit :
>>
>> On 2 Aug 2013, at 14:51, Matt McClure
>> wrote:
>>
>>> It seems unittest.TestSuite holds references to unittes
Sent from my iPhone
On 3 Aug 2013, at 19:07, "R. David Murray" wrote:
> On Sat, 03 Aug 2013 10:27:30 -0400, Matt McClure
> wrote:
>> Michael Foord voidspace.org.uk> writes:
>>> On 2 Aug 2013, at 19:19, Antoine Pitrou pitrou.net> wrote:
>>>>
sing of the builtins but screws your function signature too. So
It should really only be done where benchmarking proves it makes a difference.
I've never managed to find such a case...
Michael
> However lru_cache *is* likely to end up being speed critical *and* it's
> binding
PythonCAD is now on PyQt, use Wing as a prominent PyGtk example.
>
>
Wing is only a good example of PyGtk until Wing 5 is out of beta. They too
have switched to PyQt...
Michael
> Found by Helge Stenström on docs@.
>
> files:
> Doc/library/othergui.rst | 2 +-
>
here will be a language summit. I'm pretty sure
it will be on Thursday as the last few years. I'm getting definite confirmation
of this.
Michael
>
> -eric
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://ma
I am using IBM xlc aka vac - version 11.
afaik it will deal with c99 features (by default I set it to behave that
way because a common 'issue' is C++ style comments, when they should not
be that style (fyi: not seen that in Python).
IMHO: GCC is not just a compiler - it brings with it a whole
On 13/09/2016 02:15, Ned Deily wrote:
the challenge is to put the finishing touches on the features and
documentation, squash bugs, and test test test. The next preview release will
be 3.6.0b2
Found one typo in Modules/_io/_iomodule.h on line 156 - #endif^L rather
than #endif (posted as an
On 26/09/2016 17:41, Guido van Rossum wrote:
The issue tracker is your friend!
I shall remember this for future reference
As you probably noticed - new "issue" https://bugs.python.org/issue28290
-- BETA report: Python-3.6 build messages to stderr: AIX and "not GCC"
rs.
FYI: calling the IBM C compiler as c99 magically makes it c99 compliant,
as xlc makes it c99 plus several extensions - and take note - as cc it
is "pre-c89". In other words, calling IBM compiler as "cc" is not a wise
thing to do - I recommend to anyone l
On 27/01/2017 22:24, MRAB wrote:
I'm not bothered about it. It's quite a bit bigger than the re module,
and, anyway, keeping it as a third-party module gives me more freedom
to make updates, which are available for a range of Python versions.
I tried packaging it (pip build) and ran into a mi
On Tue, Oct 19, 2021 at 9:39 AM Chris Angelico wrote:
> On Wed, Oct 20, 2021 at 3:25 AM Baptiste Carvello
> wrote:
> >
> > Le 18/10/2021 à 20:26, Guido van Rossum a écrit :
> > >
> > > y = None # Default
> > > if config is not None:
> > > handler = config.get("handler")
> > > if handler is
On Wed, Oct 20, 2021 at 1:16 AM Piotr Waszkiewicz
wrote:
> On Wed, Oct 20, 2021 at 2:33 AM Michael Selik wrote:
>
>> In case it saves anyone a couple clicks:
>> https://www.python.org/dev/peps/pep-0463/
>> I also prefer more syntactic help with exceptions, rather than mo
On Wed, Oct 20, 2021 at 9:18 AM Piotr Waszkiewicz
wrote:
> Do you think about something along those lines?
> ```
> phone = book.publisher.owner.phone except AttributeError: None
> ```
>
Yes, that seems reasonable.
> I don't mind this syntax but it would have to be supported by static type
> ch
Sent from my iPhone
> On 15 Sep 2019, at 23:25, Tim Peters wrote:
>
> [Tim]
>> While python-dev has several "official" moderators, best I can tell
>> I'm the only one who has reviewed these messages for years.
>
> I should clarify that! That's not meant to be a dig at the other
> moderators
pt-in to this behavior if they define
`__match_args__
= None`? Not sure if adding the extra "is None" check when doing the match
will introduce too much overhead though.
-- Michael
On Wed, Jul 8, 2020 at 8:06 AM Guido van Rossum wrote:
> Today I’m happy (and a little trepidatious) to a
d be great to get this into 2.6-maint.
All the best,
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
Unsubscr
Michael Foord wrote:
Hello all,
Issue 5287 is a patch for the logging module for compatibility with
IronPython. IronPython provides sys._getframe but it throws an exception
if you call it with a non-zero depth. This may be fixed in a future
version of IronPython.
http://bugs.python.org
the posting, so in their
judgment it wasn't spam.
I saw it in the queue and hit reject. I think he may have signed up and
reposted - either that or I *didn't* hit reject when I intended to.
Michael
It was in my judgment, but someone else approved it before I managed
to hit th
lly equivalent and single set of tests is run on
both then -- assuming good tests -- breakage would be noticed...
Michael
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.
__, etc.
What do you mean overwriting __name__ and __file__? Doing import * in a
pure Python file doesn't override these.
Michael
-Brett
___
Python-Dev mailing list
Python
've been using 1.5 clients with 1.4 and earlier servers for
quite a while now. My guess is that you deciphered the error message wrong!
A working copy created by a 1.5 client can only be manipulated by a 1.5
client (I sometimes have several clients on windows boxen) but work fine
with ear
d for switching
out objects in the scope of the lower level APIs - that seems like a
design smell to me.
Michael
--
http://www.ironpythoninaction.com/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
U
by saving the pickled primer itself in the database. The unpickler
would be primed by using it to load the primer before loading the record
of interest. But AFAIK there is no way to prime new picklers, because
there is no guarantee that pickling the same primer twice will result in
the same id-&
ult&prev=/search%3Fq%3Dcebit%2B2009%2B%2BLinux%2BNew%2BMedia%2BAwards%2Bpython%26hl%3Den%26client%3Dfirefox-a%26rls%3Dorg.mozilla:en-GB:official%26hs%3DP9E
All the best,
Michael Foord
--
http://www.ironpythoninaction.com/
___
Python-Dev mailing
Antoine Pitrou wrote:
> Michael Haggerty alum.mit.edu> writes:
>> It is easy to optimize the pickling of instances by giving them
>> __getstate__() and __setstate__() methods. But the pickler still
>> records the type of each object (essentially, the name of its class)
Antoine Pitrou wrote:
> Le vendredi 06 mars 2009 à 13:44 +0100, Michael Haggerty a écrit :
>> Antoine Pitrou wrote:
>>> Michael Haggerty alum.mit.edu> writes:
>>>> It is easy to optimize the pickling of instances by giving them
>>>> __getstate__()
Greg Ewing wrote:
> Michael Haggerty wrote:
>> A similar effect could *almost* be obtained without accessing the memos
>> by saving the pickled primer itself in the database. The unpickler
>> would be primed by using it to load the primer before loading the record
>> of
Guido van Rossum wrote:
> On Sat, Mar 7, 2009 at 8:04 AM, Michael Haggerty wrote:
>> Typically, the purpose of a database is to persist data across program
>> runs. So typically, your suggestion would only help if there were a way
>> to persist the primed Pickler across
community use (Python Imaging Library and the PyWin32
extensions for example) that aren't in the standard library.
I think other developers have similar mixed feelings, or at least there
are enough people on both sides of the fence that it is very hard to
make changes. Perhaps this is
only implement one (e.g. __lt__):
http://code.activestate.com/recipes/576529/
Michael Foord
Mart Sõmermaa wrote:
__cmp__ used to provide a convenient way to make all ordering
operators work by defining a single method. For better or worse, it's
gone in 3.0.
To provide total ordering wi
ng point and we won't have to
annoint one like __lt__ as the one true underlying method.
When it's ready, I'll bring it to python-dev for discussion.
Is there something you don't like about this one:
http://code.activestate.com/rec
e provided as a starting point and we won't have to
annoint one like __lt__ as the one true underlying method.
When it's ready, I'll bring it to python-dev for discussion.
[Michael Foord]
Is there something you don't like about this one:
http://code.activestate.com/recipes
Mart Sõmermaa wrote:
On Tue, Mar 10, 2009 at 3:57 PM, Michael Foord
mailto:fuzzy...@voidspace.org.uk>> wrote:
Is there something you don't like about this one:
http://code.activestate.com/recipes/576529/
Yes -- it is not in the standard library. As I said, eventual
they're ugly).
Isn't it better practise for exceptions to be used for exceptional
circumstances rather than for control flow?
Michael
On Sun, Mar 15, 2009 at 05:56, Nick Coghlan <mailto:ncogh...@gmail.com>> wrote:
PEP 377 is a proposal to allow context manager __enter__()
e alternative outcomes of a function call, rather than just a
single result. In principle, it would be possible to eliminate the
return statement altogether, but it is useful syntactic sugar.
Using exceptions for control flow is akin to goto. Sometimes useful but
a dubious practise. :-)
M
that exceptions are expensive, or setting up a try/except block is
expensive? The reason the SkipStatement idea is tenable at all (even in
CPython) is that try/except is fairly cheap when no exception is raised.
It is the raising of the exception that is expensive.
Michael
(In this specific cas
cases are exceedingly rare. We used to
say that exceptions should be used for exceptional cases, but folks
pushed back on that as tautological."
Michael
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
___
Python-Dev mail
Aahz wrote:
On Sun, Mar 15, 2009, Michael Foord wrote:
Note that using exceptions for control flow can be bad for other
implementations of Python. For example exceptions on the .NET framework
are very expensive. (Although there are workarounds such as not really
raising the exception
Aahz wrote:
On Sun, Mar 15, 2009, Michael Foord wrote:
Aahz wrote:
On Sun, Mar 15, 2009, Michael Foord wrote:
Note that using exceptions for control flow can be bad for other
implementations of Python. For example exceptions on the .NET
framework are very expensive
ntics well documented will be an
*excellent* side effect of importlib. Thank you for your astonishing
efforts on this project.
Personally I would rather see the import semantics themselves in the
language reference.
Michae
und it useful to short-circuit any doubt and just
refer to comments in code as 'lies'. :-)
Michael
all the best -- chris
p.s.: won't make it to PyCon this time, see you soon at the piggies
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
_
n. Are you sure you can't use
try:
raise Thing
except Thing, e:
# handle Thing exceptions
raise
finally:
# handle *all situations*, including Thing
Obviously, the finally: block is also invoked in the case that no
exceptions are triggered, but often this
> We're switching to Mercurial (Hg).
And two hours later, GNOME announces their migration to git is
underway. I'd suspect a series of April Fools jokes, if it weren't two
days early. :)
--
Michael Urman
___
Python-Dev maili
d but is usable on 10.3.9 as well, but I haven't
checked yet how much that would complicate the build.
Two installers sounds OK to me, particularly if it simplifies the build
process but allows us to still support 64bit.
Michae
rsonal settings (which files you have open, how many windows you are
using etc) and would be svn-ignored.
Michael Foord
--
http://www.ironpythoninaction.com/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/list
Michael Foord wrote:
Hello all,
How many are using the Wing IDE to work on core Python?
It would be nice to have a 'python.wpr' checked in to trunk, as I have
to recreate the project file every time I do a new checkout. Would
this be useful for anyone else? Where is a good place
available from the
top-level unittest namespace (for backwards compatibility).
Michael
--
http://www.ironpythoninaction.com/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http
the PSF may be willing to pay).
Michael
Chris
--
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://
t currently rely on deterministic finalisation (reference counting)
so it makes sense to test changes on both platforms and commit a single
solution.
Michael
Collin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listi
101 - 200 of 1851 matches
Mail list logo
