I'm rather sad to have been sacked, but such is life. I won't be doing
any more work on the bug tracker for obvious reasons, but hope that you
who have managed to keep your voluntary jobs manage to keep Python going.
Kindest regards.
Mar
siness in back rooms many times over.
If you're referring to me I'm extremely offended. Yes or no?
Kindest regards.
Mark Lawrence.
___
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
t buildbot 0.8.2 has done away with the
XMLRPC interface that bbreport uses.
But that's really a bbreport issue rather than a buildbot one...
Mark
[1] http://code.google.com/p/bbreport/
___
Python-Dev mailing list
Python-Dev@python.org
http://ma
#x27;d been thinking harder, I would
have remembered that float accepted the non-European digits and added
a note to that effect. This (unintentional) omission does underline
the point that it's difficult right now to document and understand
exactly what the float constructor does or doesn't accept.
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Guido writes:
> As Phillip understood, I meant the environment to include the
> filesystem (and on Windows, the registry -- in fact, Python on Windows
> *has* exactly such a mechanism in the registry, although I believe
> it's rarely used these days -- it was done by Mark Hammond
the common usage of strings
in usual programming, I fail to see why an implementation like this would not
be desirable?
If there's a widely recognized argument against this, a link will likely sate
my curiosity.
Thanks,
Mark
> ---Original Message---
> From: Josiah Carl
a bit embarrassing if they fail for some inputs.
One more thing: since this is my first post to python-dev I should
probably introduce myself. I'm a mathematician, working mostly in
number theory. I learnt programming and numerical analysis the hard
way, coding service-life prediction algorit
runk has
Python in XUL working, and is being used by at least a few people. The
ongoing work is fairly sporadic, but is currently aimed at closer
integration of Javascript and Python with the DOM - notably enabling
"native" attributes on DOM objects to be accessed by other languages.
Mark
Please add my -1 to the chorus here, for the same reasons already expressed.
Cheers,
Mark
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> ]On Behalf
> Of Jim Jewett
> Sent: Monday, 30 April 2007 1:29 PM
> To: Python 3000; Python Dev
&
months ago. But maybe that was just an issue with timestamps on
files. I'll see if I can reproduce.
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org
On Sat, Dec 4, 2010 at 1:23 PM, Mark Dickinson wrote:
> On Sat, Dec 4, 2010 at 11:41 AM, Antoine Pitrou wrote:
>> Er, normally you don't need *any* Python installed to build Python (be
>> it 3.x or 2.x).
>
> Are you sure about this? I remember needing an existing Pytho
On Sat, Dec 4, 2010 at 1:40 PM, Benjamin Peterson wrote:
> You have to touch Include/Python-ast.h and Python/Python-ast.c. We do
> this for release tarballs.
Ah, that makes sense. Thanks.
Mark
___
Python-Dev mailing list
Python-Dev@python.or
On Mon, Dec 13, 2010 at 3:51 PM, R. David Murray wrote:
> It seems like the status quo is fine. I wouldn't object to it being
> made more consistent. I would object to removing the existing cases.
Same here, on all three counts. In one of the projects I'm currently
working on, we've settled on
g to say "operator.index(self)" would be the
> clearest solution here.
Agreed. Certainly "someobject[self]" isn't right.
(There's also a question about whether __index__ should really be
defaulting to int, but that's another issue...)
Mark
On Mon, Dec 27, 2010 at 9:43 AM, Raymond Hettinger
wrote:
> FWIW, I'm entirely opposed to doing an assignment in a nonlocal definition.
> [...]
-1 for assignment in nonlocal and global statements from me, too.
Mark
___
Python-Dev mailing
Bah. I meant to send this to the list. (I suspect that Nick also
meant to send his reply to the list.)
On Mon, Dec 27, 2010 at 12:43 PM, Mark Dickinson wrote:
> On Mon, Dec 27, 2010 at 12:23 PM, Nick Coghlan wrote:
>> The symmetry only breaks for a class that breaks the invariant:
.. and here's my original reply to Nick, which was also intended to go
to the list. Sorry, folks.
Mark
-- Forwarded message --
From: Mark Dickinson
Date: Mon, Dec 27, 2010 at 10:27 AM
Subject: Re: [Python-Dev] Range __contains__ and objects with __index__ methods
To:
two such fields: smalltable and obj.
The need for obj is a little ugly: as far as I can tell, it's
meaningless for a 3rd-party object that wants to export buffers---it's
only really used by the memoryview object and by internal Python
types.
Mark
___
On Wed, Jan 5, 2011 at 2:03 PM, Mark Dickinson wrote:
> Maybe I'm misunderstanding. What's the responsibility of a buffer
> export w.r.t. the obj field---i.e., what should 3rd party code be
Grr. *buffer exporter*, not *buffe
On Wed, Jan 5, 2011 at 1:13 PM, Antoine Pitrou wrote:
> On Wed, 5 Jan 2011 12:55:55 +
> Mark Dickinson wrote:
>> The need for obj is a little ugly: as far as I can tell, it's
>> meaningless for a 3rd-party object that wants to export buffers---it's
>>
2011, 08:32:59)
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from Graphics.Vector import *
Traceback (most recent call last):
File "", line 1, in
File "Graphics/Vector/Sv
On Mon, 17 Jan 2011 09:23:39 -0500
"R. David Murray" wrote:
> On Mon, 17 Jan 2011 08:33:42 +, Mark Summerfield
> wrote:
> > from ..Graphics import Xpm
> > SVG = 1
> >
> > I can do the relative import with Python 3.0 and 3.1 but not with
> > 3.2
t really, pipermail should just output a suitable style itself, e.g.: style=hite-space: pre-wrap"> or a pre { white-space: pre-wrap;
> } in the header.
This is mailman bug 266467
<https://bugs.launchpad.net/mailman/+bug/266467>. It was fixed in
Mailman 2.1.13.
--
Mark Sapiro
should be made
between working on CPython and the standard library?)
Overall I think this document is *extremely welcome* and I am very glad
you have done it. I'm sure that once it starts to get known it will help
add to the pool of people contributing to Python as well as helping to
keep the pr
version plus any *necessary*
changes in time for the 3.2 release?
Remember the C API is a promise to support these functions for years to
come and a burden on other implementations, including future CPythons.
So could the CPython internal APIs be kept out of the public API?
Please.
Cheers,
Mark
Georg Brandl wrote:
Am 09.02.2011 10:09, schrieb Mark Shannon:
At sometime between versions 3.1 and the current version, 3.1.3,
the API grew considerably.
See
http://docs.python.org/release/3.1/c-api/exceptions.html#exception-handling
and
http://docs.python.org/py3k/c-api/exceptions.html
M.-A. Lemburg wrote:
Mark Shannon wrote:
The Unicode Exception Objects section is new and seemingly redundant:
http://docs.python.org/py3k/c-api/exceptions.html#unicode-exception-objects
Should this be in the public API?
Those function have been in the public API since we introduced
Unicode
added
between 3.1.3 and 3.2b2.
Of course 743 functions is about 700 too many,
but that's a discussion for Python-ideas and PEP 384.
Mark.
HTH,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/lis
Nick Coghlan wrote:
On Thu, Feb 10, 2011 at 8:16 PM, Mark Shannon wrote:
Doing a search for the regex: "PyAPI_FUNC\([^)]*\) *Py" in .h files,
which should match API functions (functions starting _Py are excluded) gives
the following result:
Version matches
3.0 717
3.1.3
M.-A. Lemburg wrote:
Mark Shannon wrote:
Nick Coghlan wrote:
On Thu, Feb 10, 2011 at 8:16 PM, Mark Shannon
wrote:
Doing a search for the regex: "PyAPI_FUNC\([^)]*\) *Py" in .h files,
which should match API functions (functions starting _Py are
excluded) gives
the following result
e it only costs a
few line of code."
This seems a little cavalier to me.
That little PyAPI_FUNC() macro carries a lot of obligation in terms of
documentation, future support, and the cost to other implementations.
Cheers,
Mark.
___
Python-Dev
Victor Stinner wrote:
Le jeudi 10 février 2011 à 16:19 +0100, M.-A. Lemburg a écrit :
And the following were added to 3.2,
of which only 2 are documented:
PyArg_ValidateKeywordArguments
PyAST_CompileEx
Py_CompileString
Py_CompileStringExFlags
PyErr_NewExceptionWithDoc(documented)
PyErr_Synt
because people were using
PyCode_Addr2Line to get the current line number.
The API will contain then both
PyFrame_GetLineNumber *and* PyCode_Addr2Line.
The API then has even more redundancy.
PyObject_GetAttrString(frame, "f_lineno") should do the job.
Mark.
Antoine.
___
Nick Coghlan wrote:
On Fri, Feb 11, 2011 at 3:25 AM, Mark Shannon wrote:
Antoine Pitrou wrote:
Please, don't just document all these.
Don't add them to the API, unless they are really needed.
We only add functions when they are actually needed (by us, usually).
If only you (I p
les" in What's New in alphabetical order?
--
Mark Summerfield, Qtrac Ltd, www.qtrac.eu
C++, Python, Qt, PyQt - training and consultancy
Programming in Python 3" - ISBN 0321680561
http://www.qtrac.eu/py3book.html
___
use
they'll never be accepted. I'll dedicate my time to something else instead.
Mercurial /will/ make it easier to contribute code, but if it doesn't get
accepted into a release branch, then that makes no real difference to me.
Seriously guys - fix the issue lifecycle; I'll come back
stalled wins" issue
Martin mentions - only all of them taken together will "fix" this issue
- not that I personally consider it particularly broken - more like
"sub-optimal" :)
Cheers,
Mark
___
Python-Dev mailing list
Pyth
On 6/03/2011 12:37 AM, Michael Foord wrote:
On 05/03/2011 07:02, Nick Coghlan wrote:
On Sat, Mar 5, 2011 at 10:47 AM, Mark
Hammond wrote:
I think this discussion should be divorced from this PEP and taken up
with
the discussion about the PATH and the "last installed wins" issue Marti
atus-quo (or better) for files which don't...
But this sounds like a different PEP ;)
Cheers,
Mark.
___
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 7/03/2011 1:55 AM, Paul Moore wrote:
On 6 March 2011 02:33, Mark Hammond wrote:
IIUC, the PEP language is referring to links which point to a specific
version of Python and that there is no suggestion a 'python3' will live in
the Python 3 binary tree. If that is correct and a
On 7/03/2011 10:04 AM, Michael Foord wrote:
Paul Moore was +1 on Windows being included. Mark did accept that some
of the changes were "desirable", but was also concerned they didn't
address all the issues on Windows. I *would* like to see all the issues
addressed but I think that
th .py
files.
There would probably also need to be the same for ".pyw", but it would
be almost identical to the .py handling.
Cheers,
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Uns
On 7/03/2011 4:34 PM, Nick Coghlan wrote:
On Mon, Mar 7, 2011 at 3:19 PM, Mark Hammond wrote:
Without putting too much thought into it, I think a simple scheme could work
where the path must either be "/usr/bin/python[23]?" or a fully-qualified
path to a Python executable. IIUC, t
ad the spare time (I don't :-() I'd work on this myself.
+1 from me.
Cool - I may have a go at this over the next few weekends... :)
Cheers,
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo
exact same mechanism be used to
denote the major version of Python needed.
* as I work with multiple platforms it would be really nice if the same
invocations worked across all of them - whilst I say again that I really
like the idea of the launcher it doesn't conflict with the other
suggestion
On 8/03/2011 10:15 AM, Greg Ewing wrote:
Mark Hammond wrote:
Yup - although I think a pythonw.exe launcher would be needed too
Couldn't the launcher look at the extension of the file being
launched to decide about this?
Nope - the launcher itself must be marked as "console&qu
n the #! line is the only clue Windows needs to make it work
automagically?
Cheers,
Mark
___
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
est", and anarchy and variant workarounds have abounded.
I'm glad solving world hunger is out of scope for this :) I understand
your position but my personal opinion is that simple support for #! is
more desirable. I'd be happy to go with the consensus though...
Cheers,
Mark
earch.
Cheers,
Mark.
___
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
These issues are best put in the tracker so they don't get lost -
especially at the moment with lots of regulars at pycon.
It would also be good to know if there is an actual behaviour bug caused
by this (ie, what problems can be observed which are caused by the
current code?)
Cheers,
rue check disabled then there probably
isn't a problem.
Mark
___
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
entirely. But
reverting Antoine's patch seems like a step backwards.
Mark
___
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
ght balance between
simplicity and usefulness?
* Does the strategy have general support from Martin, who as the person
making Python distributions would need to be involved in at least some
aspects of it (specifically, having the installer MSI install the
launcher and update the file associat
On Sat, Mar 19, 2011 at 12:59 PM, Raymond Hettinger
wrote:
> On Mar 19, 2011, at 11:21 AM, Antoine Pitrou wrote:
>> On Sat, 19 Mar 2011 09:25:07 -0500
>> s...@pobox.com wrote:
>>
>>> The dev guide says something about collapsing changesets. Is that
>>> collapsing commits within a changeset or col
Thanks for the feedback!
On 19/03/2011 7:44 PM, Glenn Linderman wrote:
Not all of the ideas below are complementary to each other, some are
either or, to allow different thoughts to be inspired or different
directions to be taken.
Thanks for starting a PEP.
On 3/18/2011 11:02 PM, Mark Hammond
3 environment variables
- while they have different names, 2 of them work as you describe above.
The third is used to nominate how a simple 'python' with no version
qualifiers should be treated - I wanted the ability for the simple
'python' to execute a python 3.x version if desi
he launcher should
be associated with .py files and the "windows" version associated with
.pyw files.'
What extra level of detail do you feel is necessary?
I'm fine with the strategy, but I feel that the devil's in the detail.
Indeed! But general approval
On 20/03/2011 6:22 PM, Glenn Linderman wrote:
On 3/19/2011 7:38 PM, Mark Hammond wrote:
...
A Windows user who has only learned Python 2.x programming would not
necessarily have ever heard of execve, would not realize execve(2) means
it is from the 2nd chapter of the Unix man pages, meaning an
On 20/03/2011 8:36 PM, Terry Reedy wrote:
On 3/20/2011 3:22 AM, Glenn Linderman wrote:
On 3/19/2011 7:38 PM, Mark Hammond wrote:
[snip]
As both a writer and reader, I would like to just add, for instance,
#! python3
(or 3.3 or whatever) and have the launcher do the 'right thing'.
al, I'd be happy for py.exe to avoid CreateProcess for
CPython if that could be reasonably done and was the consensus...
Thanks,
Mark
___
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
Following up myself here...
On 20/03/2011 9:25 PM, Mark Hammond wrote:
On 20/03/2011 8:37 PM, "Martin v. Löwis" wrote:
...
Some of these uses probably shouldn't use the launcher directly - eg,
ISAPI apps and COM objects which have a separate registration step could
register a spec
On 20/03/2011 11:56 PM, Dj Gilcrease wrote:
...
Before Mark wrote up this pep I had started experimenting with how to
make the launcher and I was able to get it to launch python while
exiting py.exe and as far as I could tell it behaved just as if I had
launched the app directly by double
e.exe (which is part of pywin32 and is located simply by
assuming it is next to win32service.pyd)
Regardless, I don't think they are very likely to break - my concern is
more for "normal" scripts which construct a child process cmdline/argv
On 21/03/2011 11:10 AM, "Martin v. Löwis" wrote:
Am 21.03.2011 00:52, schrieb Mark Hammond:
On 21/03/2011 10:32 AM, "Martin v. Löwis" wrote:
The above raises an interesting question - if the launcher executed
Python in-process, what would sys.executable be? I can i
On 21/03/2011 11:15 AM, "Martin v. Löwis" wrote:
Am 21.03.2011 00:43, schrieb Greg Ewing:
Mark Hammond wrote:
The above raises an interesting question - if the launcher executed
Python in-process, what would sys.executable be?
I think it should be the actual Python executing at t
the hypothetical
program mentioned above, of which no instance can be found and no
breakage actually demonstrated.
I personally would conclude that the last option is the least worst
scenario by a wide margin.
Cheers,
Mark
___
Python-Dev mailing li
7;m not confident enough we can make it
work correctly to base the entire success or failure of the PEP on that
detail.
Any other ideas/thoughts about this?
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/py
iscussions in this thread.
Should I also check the reference implementation in? Maybe next to the
PEP text as "pep--reference.py"?
Thanks,
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/p
sdn.microsoft.com/en-us/library/ms684161%28v=vs.85%29.aspx for
an overview.
Cheers,
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/pytho
On 22/03/2011 8:09 AM, Barry Warsaw wrote:
I started an Informational PEP on this at Pycon, and will try to finish a
draft of it this week. (I'm claiming 396 for it.)
We nearly had a race for that number! FYI, I just checked in pep-0397
leaving 396 for you :)
Cheers,
think and what objections/comments/etc remain.
Thanks,
Mark
PEP: 397
Title: Python launcher for Windows
Version: $Revision$
Last-Modified: $Date$
Author: Mark Hammond
Status: Draft
Type: Standards Track or Informational ?
Content-Type: text/x-rst
Created: 15-Mar-2011
Abstract
This PEP describ
On 23/03/2011 6:12 AM, Michael Foord wrote:
On 22/03/2011 07:21, Mark Hammond wrote:
Hi all,
I've made some changes to the draft PEP and checked it into the PEP
repository as PEP397. The reference implementation is currently being
tracked at http://bugs.python.org/issue11629.
Hey Mark,
indows function could be
used to extract the data (eg, only '=' can be used to separate the
name/value pair, case-insensitive and no support for string
interpolation) as I have no interest in writing my own config file
parser in C :)
Cheers,
Mark
_
On 24/03/2011 1:20 PM, Michael Foord wrote:
On 24/03/2011 00:44, Dj Gilcrease wrote:
On Wed, Mar 23, 2011 at 8:14 PM, Mark
Hammond wrote:
If you guys (or anyone) would like to agree on some precise rules for
both
the location of the config file and its contents and express this as
a patch
to
y - the files are likely to be in the middle of a
very long list which my brain will be trained to habitually skip over.
The number of new files which legitimately need to be added to those
directories seem so small that this risk seems worthwhile.
Any thoughts?
Mark
On 30/03/2011 12:09 PM, R. David Murray wrote:
On Wed, 30 Mar 2011 11:11:45 +1100, Mark Hammond
wrote:
I'm wondering if it is a reasonable idea to have .hgignore exclude all
files from 'Lib/site-packages' and 'Scripts'? As I install packages
into my source builds,
On 30/03/2011 1:37 PM, R. David Murray wrote:
On Wed, 30 Mar 2011 12:17:05 +1100, Mark Hammond
wrote:
On 30/03/2011 12:09 PM, R. David Murray wrote:
The solution is to add such
directories and/or files to your personal ignore list See the 'ignore'
entry under 'ui' in th
versions I
can use before I can even start the process...
Thanks,
Mark
___
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 Tue, Apr 12, 2011 at 6:01 PM, Djoume Salvetti wrote:
> Thank you and sorry about the pastebin.
> I can reproduce it on python 2.5.2 and python 2.6.6 but not on python 3.1.2
> (all in ubuntu). I'll open a bug.
Is http://bugs.python.org/issue5215 the sam
cannot precede any of its sub-classes in an MRO,
see http://en.wikipedia.org/wiki/C3_linearization
If A is a "parent" (super-class) of B, then B must precede A in any MRO
that contains them both.
"Siblings", in the context of a single MRO are thus classes between
which
On Thu, Apr 14, 2011 at 7:09 AM, Ricardo Kirkner
wrote:
> I recently stumbled upon an issue with a class in the mro chain not
> calling super, therefore breaking the chain (ie, further base classes
> along the chain didn't get called).
> I understand it is currently a requirement that all classes
Argh! Sorry list. I meant to discard the post that was just sent.
Please accept my humblest apologies...
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org
#x27; should be True seems attractive in theory,
but I agree that it doesn't really seem like a realistic option in
terms of backwards compatibility and compatibility with other
mainstream languages.
Mark
___
Python-Dev mailing list
Python-Dev@
On Wed, Apr 27, 2011 at 7:41 PM, Glenn Linderman wrote:
> One issue that I don't fully understand: I know there is only one instance
> of None in Python, but I'm not sure where to discover whether there is only
> a single, or whether there can be multiple, instances of NaN or Inf. The
> IEEE 754
and lists
do not raise unwanted exceptions.
NaN is Not a Number (therefore should be neither a float nor a Decimal).
Making it a new class would solve some of the problems discussed,
but would create new problems instead.
Correct behaviour of collections is
Steven D'Aprano wrote:
Mark Shannon wrote:
Related to the discussion on "Not a Number" can I point out a few things
that have not be explicitly addressed so far.
The IEEE standard is about hardware and bit patterns, rather than types
and values so may not be entirely appro
Maciej Fijalkowski wrote:
On Thu, Apr 28, 2011 at 11:10 PM, Stefan Behnel wrote:
M.-A. Lemburg, 28.04.2011 22:23:
Stefan Behnel wrote:
DasIch, 28.04.2011 20:55:
the CPython
benchmarks have an extensive set of microbenchmarks in the pybench
package
Try not to care too much about pybench. The
python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/marks%40dcs.gla.ac.uk
Could you please post this to python-ideas, rather than python-dev
Python-dev is about aspects of the implementation,
not significant language changes.
Mark.
p' arithmetic, under which infinities and
nans were produced as per IEEE 754:
with math.non_stop_arithmetic():
...
But this is python-ideas territory.
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/
previously
worked and no reports of the regression exist, we should just fix it
without regard to people relying on the "new" functionality...
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/
Hi,
The online documentation specifies which API function borrow and/or
steal references (as opposed to the default behaviour).
Yet, I cannot find this information anywhere in the source.
Any clues as to where I should look?
Cheers,
Mark
___
Python
this information separate
from the code and maintain it manually, it's going to get out-of-date.
What about #defining PY_STOLEN in some header?
Then any stolen parameter can be prefixed with PY_STOLEN in signature.
For return values, similarly #define PY_BO
eference, I expect it to take it from me.
"Stealing" takes the ownership. Borrowing does not.
This explains it better:
http://docs.python.org/py3k/c-api/intro.html#reference-count-details
Cheers,
Mark.
___
Python-Dev mailing list
Python-Dev@python.
nor collections, 0 major collections
Max heap size 2.4 Mbytes.
Total time spent in GC: 3.5 milliseconds. ( <1% of execution time)
My GC is quick, but its not the fastest.
Evidence trumps opinion IMHO ;)
Cheers,
Mark.
___
Python-Dev mailing list
Pyt
s...@pobox.com wrote:
Antoine> Since we're sharing links, here's Matt Mackall's take:
Antoine>
http://www.selenic.com/pipermail/mercurial-devel/2011-May/031055.html
From that note:
1: You can't have meaningful destructors, because when destruction
happens is undefined. And go
Michael Foord wrote:
On 06/05/2011 18:26, Mark Shannon wrote:
Michael Foord wrote:
On 06/05/2011 17:51, Stefan Behnel wrote:
Mark Shannon, 06.05.2011 18:33:
s...@pobox.com wrote:
Antoine> Since we're sharing links, here's Matt Mackall's take:
Antoine>
http://www.
Stefan Behnel wrote:
Michael Foord, 06.05.2011 19:06:
On 06/05/2011 17:51, Stefan Behnel wrote:
Mark Shannon, 06.05.2011 18:33:
s...@pobox.com wrote:
Antoine> Since we're sharing links, here's Matt Mackall's take:
Antoine>
http://www.selenic.com/pipermail/mercurial-devel
Hi Michael,
Sorry for the late reply; it's been kinda busy around here.
If there are places left, I'll definitely be there at the summit.
Congratulations on your impending doom! (And sorry to hear that you
might not be there in Florence.)
Mark
On Sat, Apr 16, 2011 at 3:50 PM, Mic
attached and I welcome all comments, including
bike-shedding on the environment variable names and INI section/value names.
Note that the reference implementation has not changed - I'll update
that once there is general agreement on the functionality described in
the PEP.
Thanks,
Mark
PEP
On Mon, Jun 20, 2011 at 1:31 PM, Antoine Pitrou wrote:
> Maciej Fijalkowski a écrit :
>>
>> Unfortunately I'm missing Europython (and language summit) this year.
>> Did anyone do a writeup on what was discussed?
>
> Mark Dickinson has been taking notes,
801 - 900 of 1370 matches
Mail list logo
