reset() function:
Clear traces of memory blocks allocated by Python.
Does this do anything besides clear? If not, why not just re-use the
'clear' name from dicts?
disable() function:
Stop tracing Python memory allocations and clear traces of
memory blocks alloc
On Wed, Oct 30, 2013 at 6:02 AM, Victor Stinner
wrote:
> 2013/10/30 Jim J. Jewett :
>> Well, unless I missed it... I don't see how to get anything beyond
>> the return value of get_traces, which is a (time-ordered?) list
>> of allocation size with then-current call stack. It doesn't mention
>> an
Why are these functions (get_traces and get_object_traceback) private?
(1) Is the whole module provisional? At one point, I had thought so, but
I don't see that in the PEP or implementation. (I'm not sure that it
should be provisional, but I want to be sure that the decision is
intentional.)
(
On Tue, Jan 14, 2014 at 3:06 PM, Guido van Rossum wrote:
> Personally I wouldn't add any words suggesting or referring to the
> option of creation another class for this purpose. You wouldn't
> recommend subclassing dict for constraining the types of keys or
> values, would you?
Yes, and it is so
http://midwinter.com/~larry/3.4.status/merge.status.html lists enough
changes that it sounds more like a bugfix release than "just a few
last tweaks after the rc".
It would probably help if the what's-new-in-rc2 explicitly mentioned
that asyncio is new and provisional with 3.4, and listed its chan
I personally regret that sorting isn't safe, but that ship has sailed.
There is practicality benefit in making None compare to everything,
just as C and Java do with null pointers -- but it is too late to do
by default.
Adding a keyword to sorted might be nice -- but then shouldn't it also
be add
Stefan Behnel wrote:
> I would have a hard time feeling happy
> if a real-world HTML parser was added to the stdlib that provides a totally
> different interface than the best (and fastest) XML library that the stdlib
> currently has.
I doubt there would be any objection to someone contributing w
Michael Foord wrote:
> Chris Withers wrote:
>> ... love to see ... but ... not optimistic
>> - python to grow a decent, cross platform, package management system
As stated, this may be impossible, because of the difference in what a
package should mean on Windows vs Unix.
If you just mean a way
It is starting to look as though flush (and close?) should take an
optional wait parameter, to indicate how much re-assurance you're
willing to wait for.
It also looks like we can't know enough to predict all sensible
symbolic constants -- so instead use a floating point numeric value.
f.flush(wa
On 3/12/09, "Martin v. Löwis" wrote:
>> It is starting to look as though flush (and close?) should take an
>> optional wait parameter, to indicate how much re-assurance you're
>> willing to wait for.
> Unfortunately, such a thing would be unimplementable on most of today's
> operating systems.
W
[new name instead of "wait" -- but certainty is too long, patience too
hard to spell, etc...]
>> class file(_file): ...
>> def flush(self, sure=0):
> super().flush(self)
> if sure < 0.25:
> return
> if sure < 0.5 and os.fdatasync:
> os.fdatasync(
On Thu, Mar 26, 2009 at 4:19 PM, P.J. Eby wrote:
>> What I don't like is the confusion of adding "return values" to generators,
>> at least using the 'return' statement.
At Fri Mar 27 04:39:48 CET 2009, Guido van Rossum replied:
> I'm +1 on "yield from" and +0 on return values in generators.
>
At 11:27 PM 3/26/2009 +, Paul Moore wrote:
>> What I'd really like is essentially some form of "virtual filesystem"
>> access to stuff addressed relative to a Python package name,
P.J. Eby responded:
> Note that relative to a *Python package name* isn't quite as useful,
> due to namespace pack
Jared Grubb wrote:
> Ok, so if I understand, the situation is:
> * python points to 2.x version
> * python3 points to 3.x version
> * need to be able to run certain 3k scripts from cmdline (since we're
>talking about shebangs) using Python3k even though "python"
>points to 2.x
> So, if I
(sent only to python-dev, as I am not a subscriber of tahoe-dev)
Zooko wrote:
> [Tahoe] currently uses utf-8 for its internal storage (note: nothing to
> do with reading or writing files from external sources -- only for
> storing filenames in the decentralized storage system which is
> accessed
Martin v. Löwis wrote:
> - PyGetSetDef (name, get, set, doc, closure)
Is it fully decided that the generally-unused closure parameter will
stay until python 4?
> The accessor macros to these fields (Py_REFCNT, Py_TYPE, Py_SIZE)
> are also available to applications.
There have been several expe
Michael Foord wrote:
>> I agree. People with versioning issues *should* be using virtualenv.
Tarek Ziadé replied (and several people later agreed)
> Let's remove site-packages from Python then.
What about those people *without* versioning issues?
I have no qualms suggesting that package manageme
[It may be worth creating a patch; I think most of these comments
would be better on the bug-tracker.]
(1) In a few cases, it looked like you were changing parameter names
between "files" and "filenames". This might break code that was
calling it with keyword arguments -- as I typically would fo
> Kristján Valur Jónsson wrote:
>> I've never understood the need to have a distinction betwen statements
>> and expressions, not when expressions can have side effects.
Alex Martelli responded:
> If you're interested in understanding it better, research
> Query-Command Separation (QCS), e.g. sta
> M.-A. Lemburg wrote:
>> ... and because of this, the feature is already available if
>> you use codecs.open() instead of the built-in open():
Neil Hodgson asked:
> So should I not add an issue for the basic open because codecs.open
> should be used for this case?
In python 3, why does codecs.o
I understand the need to ship without source -- but why does that
require supporting .pyc (or .pyo) -only?
Couldn't vendors just replace the real .py files with empty files?
Then no one would need the extra stat call, and no one would be bitten
by orphaned .pyc files after a rename.
[Yes, zips c
python.org/sf/1515343 fixes a regression against 2.4, which masks
exceptions, and should therefore go in before release. The tracker
has a patch to the test cases, and two alternative fixes. (One
minimal, the other less ugly.)
Since this only affects string exceptions with a value, it might be
a
Ka-Ping Yee writes:
> A. The interpreter will not crash no matter what Python code
> it is given to execute.
Why?
We don't want it to crash the embedding app (which might be another
python interpreter), but if the sandboxed interpreter itself crashes,
is that so bad? The embedding app
Mihai,
It does make sense to document this limit for people writing
subclasses, or using a Turkic codeset. I'm not sure that logging is
the right place to document it, and I don't think changing the base
classes is a good idea.
TimedRotatingFileHandler and HTTPHandler restrict their input to a
t
On 7/20/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> On Thu, Jul 20, 2006 at 11:39:27AM -0400, Jim Jewett wrote:
> > Even SysLogHandler.emit doesn't actually print the string; it is only
> > used as a lookup key for a dictionary whose keys are all lower-case
> &
Greg Ewing wrote:
> The time isn't the main issue. The main issue
> is that almost all the use cases for round()
> involve doing an int() on it afterwards. At
> least nobody has put forward an argument to
> the contrary yet.
Or, more accurately, they *should* involve an int
afterwards, but often
http://mail.python.org/pipermail/python-dev/2006-August/067934.html
M.-A. Lemburg mal at egenix.com
> Ralf Schmitt wrote:
>> Still trying to port our software. here's another thing I noticed:
>> d = {}
>> d[u'm\xe1s'] = 1
>> d['m\xe1s'] = 1
>> print d
(a 2-element dictionary, because they are no
The OpenSSL library implements some algorithms that are patented. The
source code should be fine to (re)distribute, but but there may be a
slight legal risk with distributing a binary.
Note that http://www.openssl.org/support/faq.html#LEGAL1 says that we
can avoid building the problem sections wi
On 8/8/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Jim Jewett schrieb:
> > The OpenSSL library implements some algorithms that are patented. The
> > source code should be fine to (re)distribute, but but there may be a
> > slight legal risk with dist
On 8/8/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> If distributing the source doesn't violate the patent,
> and distributing a binary doesn't violate the patent,
> then what *would* constitute a violation of a software
> patent?
> Writing new code using the algorithm? Compiling
> something which
> It wasn't my idea to stop ignoring exceptions in dict lookups; I would
> gladly have put this off until Py3k, where the main problem
> (str-unicode __eq__ raising UnicodeError) will go away.
> But since people are adamant that they want this in sooner,
Is this true for dictionaries specifically
Martin v. Löwis wrote:
> Now I looked at it, and think that the recipe is broken. It should
> add an __eq__ method which is
> def __eq__(self, other):
> return type(self) is type(other) \
> and self.EnumType is other.EnumType \
> and self.__value==other.__value)
Absol
I just uploaded a series of IDLE patches, but I'm not quite sure how
to classify them on the feature/bugfix scale now that the last beta is
out.
>From most to least buggish:
python.org/sf/1540892 -- honor the new quit() behavior. On the other
hand, it was documented that this didn't work in IDLE
> > python.org/sf/1540874 -- broken shortcut keys. On windows, only one
> > entry per menu can be reached with the same shortcut letter, so
> > advertising others is just an attractive nuisance. I'm not sure that
> > other systems wouldn't be able to use the hidden shortcuts.
On 8/15/06, Anthony
This makes things more consistent for today, but does it really ease
maintenance?
Why not just change it to:
from sys import version as IDLE_VERSION
so that it can be ignored from now on?
On 8/18/06, anthony.baxter <[EMAIL PROTECTED]> wrote:
> Author: anthony.baxter
> Date: Fri Aug 18 09:29:02
Collin Winter:
> [ improvements to unittest]
These would all have been (mostly) reasonable when the module was
first added to the standard library. But it has been there as an ugly
fragile unchanging beast for several years, and is ironically not well
endowed with unit tests. I therefore think
This 8 vs 4 is getting cruftier and cruftier. (And does it deal
properly with existing code that already has four spaces because it
was written recently?)
"Tim" regularly fixes whitespace already, with little damage.
Would it make sense to do a one-time cutover on the 2.6 trunk?
How about the bu
Reversing the order of the return tuple will break the alignment with
split/rsplit.
Why not just change which of the three strings holds the remainder in
the not-found case?
In rc1,
"d".rpartition(".") --> ('d', '', '')
If that changes to
"d".rpartition(".") --> ('', '', 'd')
then
(1)
> Jim Jewett wrote:
> >Why not just change which of the three strings holds the remainder in
> >the not-found case?
On 9/5/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> That was the only change submitted.
> Are you happy with what was checked-in?
This change
On 9/5/06, Fred L. Drake, Jr. <[EMAIL PROTECTED]> wrote:
> S.partition(sep) -> (head, sep, rest)
> S.rpartition(sep) -> (tail, sep, rest)
> Here, "rest" is always used for "what remains"; head/tail are somewhat more
> clear here I think.
Then shouldn't rpartition be S.rpartition(sep) ->
I think I finally figured out where Raymond is coming from.
For Raymond, "head" is where he started processing -- for rpartition,
this is the .endswith part.
For me, "head" is the start of the data structure -- always the
.startswith part.
We won't resolve that with anything suggesting a sequent
OpenSSL should probably be upgraded to 0.9.8.c (or possibly 0.9.7.k)
because of the security patch.
http://www.openssl.org/
http://www.openssl.org/news/secadv_20060905.txt
I'm not sure which version shipped with the 2.4 windows binaries, but
externals (for 2.5) still points to 0.9.8.a, wh
Travis E. Oliphant wrote:
> Two packages need to share a chunk of memory (the package authors do not
> know each other and only have and Python as a common reference). They
> both want to describe that the memory they are sharing has some
> underlying binary structure.
As a quick sanity check, p
I'm still not sure exactly what is missing from ctypes. To make this concrete:
You have an array of 500 elements meeting
struct {
int simple;
struct nested {
char name[30];
char addr[45];
int amount;
}
ctypes can describe this as
class n
On 10:06 am, g.brandl at gmx.net wrote:
>> What a successor to os.path needs is not security, it's a better
(more pythonic,
>> if you like) interface to the old functionality.
Glyph:
> Why?
> Rushing ... could exacerbate a very real problem, e.g.
> the security and data-integrity implications of
On 12/8/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> /ftp/python/2.5/python-2.5.msi is by far the top download -- 271,971
> hits, more than 5x the next one, /ftp/python/2.5/Python-2.5.tgz
> (47,898 hits). Are these numbers real?
Why wouldn't it be?
Most computers are running windows.
Most p
Raymond Hettinger wrote:
> Also, I'm wondering if the desire for 2.6 warnings is based on the notion that
> it will be possible to get large tools to work under both Py2.x and Py3.x.
I had certainly assumed it would be possible.
In fact, I had assumed that the 2->3 translator would have a mode
w
Other than dict.items (and .keys and .values) returning a non-list,
are there any other cases where the Py3K idiom can't already be used
in (or at least backported to) Py 2.x?
Is there a chance that this special case could be handled by an import
hook in py 2.6?
For example 2.6 could have an addi
On 1/17/07, Thomas Wouters <[EMAIL PROTECTED]> wrote:
> On 1/16/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > Other than dict.items (and .keys and .values) returning a non-list,
> > are there any other cases where the Py3K idiom can't already be used
> >
Nick Maclaren wrote:
>... I can work with and teach almost any model,
> and have done so with some pretty weird ones.
I think python's model is "Whatever your other tools use. Ask them."
And I think that is a reasonable choice.
For sensible input, the various models all work the same.
For dubio
Tim Peters wrote:
> complex_new() ends with:
> cr.real -= ci.imag;
> cr.imag += ci.real;
> and I have no idea what that thinks it's doing. Surely this isn't intended?!:
I think it is. python.org/sf/1642844 adds comments to make it less unclear.
> >>> complex(complex(1.0, 2.0),
Nick Maclaren wrote:
> Martin v. Löwis wrote:
>> It may be a bit problematic to implement, but I think a clean
>> specification is possible. If a and b are numbers, and a==b,
>> then hash(a)==hash(b).
You don't even need that much complication.
If a==b, then hash(a) == hash(b)
If you have
George Sakkis wrote:
> far too often I use the idiom dict(zip(keys,values)), or
> the same with izip. How does letting dict take two positional
> arguments sound ?
I think the dict constructor is already a bit too complicated, and
would prefer that it be a separate classmethod, such as
dict.
Nick Maclaren wrote:
>>> I really do mean that quite a lot of floating-point bells and whistles
>>> are non-transitive.
Martin v. Löwis wrote:
>> If so, they just shouldn't use the equal operator (==). == ought to
>> be transitive. It should be consistent with has().
Nick Maclaren wrote:
> Fine.
Greg Ewing schrieb:
> Might we want to add an in-place version of the 3-arg
> pow() function one day? If so, leaving the third argument
> there could be useful.
"Martin v. Löwis" martin at v.loewis.de replied:
> What could the syntax for that be?
> Instead of writing
> x = pow(x, n, 10)
Either
Raymond Hettinger explained:
> The constructor signature ... Point(*fetchall(s)),
> and it allows for direct construction with Point(2,3) without the
> slower and weirder form: Point((2,3)).
If you were starting from scratch, I would agree whole-heartedly;
this is one of my most frequent mistakes
On 2/22/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> [-python-checkins, +python-dev]
>
> On 2/22/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > > __setitem__
> > > __setslice__
> > > append
> > >
Guido van Rossum wrote:
> Since this can conceivably be going on in parallel in multiple
> threads, we really don't ever want to be sharing whatever object
> contains the head of the chain of tracebacks since it mutates at every
> frame bubble-up.
So (full) exceptions can't be unitary objects.
I
Proposal changed from "err, tb" to "err with tb" at Brett's good suggestion.
The rest of this message is a bit of a sidetrack; skimmers can stop now.
Nick Maclaren wrote:
>"Jim Jewett" wrote:
>> Guido van Rossum wrote:
>> > [multiple thre
The 5:1 patch review is a good idea -- but what is the procedure for
reviewing a patch?
I often comment on patches. Does this count as a review? Would
anyone know if it did?
If I were going through five at the same time, and I had a sixth to
push, I could post here. Normally, I just make a com
I guess I should have been less specific. :D
It has been quite a while since I worried about my own patches going
stale; I just want to know how my review time can be more useful.
Once a committer has already decided to look at a patch, comments may
make the next step easier.
But is there anywa
(Please note that most replies should trim at least one list from the Cc)
On 3/23/07, guido.van.rossum <[EMAIL PROTECTED]> wrote:
> Note: without the change to string.py, lots of spurious warnings happen.
> What's going on there?
I assume it was a defensive measure for subclasses of both Template
Greg Ewing wrote:
> Carl Banks wrote:
> > /* don't define releasebuffer or lockbuffer */
> > /* only objects that manage buffers themselves would define these */
> That's an advantage, but it's a pretty small one ...
> the releaser field makes the protocol asymmetrical
> and thus harder to reaso
Reading this message without the entire PEP in front of me showed some
confusing usage. (Details below) Most (but not all) I could resolve
from the PEP itself, but they could be clarified with different
constant names.
Counter Proposal at bottom, and specific questions in between.
Travis Olipha
(Please note that several groups were Cc'd. For now, please limit
followups to python-3000. This would *probably* be backported to 2.6,
but that wouldn't be decided until the implementation strategy was
settled.)
PEP: 30XX
Title: Access to Module/Class/Function Currently Being Defined (this)
Ver
Phillip J. Eby wrote:
> a __call__ method, it will still be
> called, even if you override __getattribute__ to return something else
>>> dc = DoubleCall()
>>> dc()
'called!'
>>> dc.__call__()
'attribute'
That is sufficiently fragile that I would be uncomfortable with a
feature that could
(Adding python-3000 to the Cc, since that is where much of the recent
discussion occurred)
Calvin's full proposal is archived at:
http://mail.python.org/pipermail/python-dev/2007-April/072835.html
> Abstract
>
> The PEP defines the proposal to enhance the super builtin to work implicit
On 4/29/07, Tim Delaney <[EMAIL PROTECTED]> wrote:
> I've been intending to write up a PEP for fixing super, but I haven't had
> time to get to it.
Calvin Spealman has the most recent draft. I hope he will incorporate
this into his draft.
> 1. 'super' becomes a keyword, that returns a super objec
PEP: 30xz
Title: Simplified Parsing
Version: $Revision$
Last-Modified: $Date$
Author: Jim J. Jewett <[EMAIL PROTECTED]>
Status: Draft
Type: Standards Track
Content-Type: text/plain
Created: 29-Apr-2007
Post-History: 29-Apr-2007
Abstract
Python initially inherited its parsing from C. While t
Major rewrite.
The inside-a-string continuation is separated from the general continuation.
The alternatives section is expaned to als list Andrew Koenig's
improved inside-expressions variant, since that is a real contender.
If anyone feels I haven't acknowledged their concerns, please tell me.
It might still be worth saying something like:
Note that this "python wrote:
> Author: georg.brandl
> Date: Tue Dec 28 10:18:24 2010
> New Revision: 87523
>
> Log:
> Remove confusing paragraph -- this is relevant only to advanced users anyway
> and does not belong into the tutorial.
>
> Modified
Why?
Are annotations being deprecated in general? Or are these particular
annotations no longer accurate?
-jJ
On Wed, Jan 12, 2011 at 9:31 PM, raymond.hettinger
wrote:
> Author: raymond.hettinger
> Date: Thu Jan 13 03:31:25 2011
> New Revision: 87980
>
> Log:
> Issue 10899: Remove function typ
On 4/4/11, brett.cannon wrote:
> Draft of PEP 399: Pure Python/C Accelerator Module Compatibiilty
> Requirements
> +Abstract
> +
> +
> +The Python standard library under CPython contains various instances
> +of modules implemented in both pure Python and C. This PEP requires
> +that in
This seems to be changing what is tested -- are you saying that
filenames with an included directory name are not intended to be
supported?
On 4/25/11, antoine.pitrou wrote:
> http://hg.python.org/cpython/rev/2f2c7eb27437
> changeset: 69556:2f2c7eb27437
> branch: 3.2
> parent: 69554:7
Would it be a problem to make them available a no-ops?
On 4/26/11, victor.stinner wrote:
> http://hg.python.org/cpython/rev/75503c26a17f
> changeset: 69584:75503c26a17f
> user:Victor Stinner
> date:Tue Apr 26 23:34:58 2011 +0200
> summary:
> PyGILState_Ensure(), PyGILState_Re
Do you also want to assert that u is not v, or would that sort of
"copy" be acceptable by some subclasses?
On 5/5/11, raymond.hettinger wrote:
> http://hg.python.org/cpython/rev/f20373fcdde5
> changeset: 69865:f20373fcdde5
> user:Raymond Hettinger
> date:Thu May 05 14:34:35 201
Can you clarify (preferably in the commit message as well) exactly
*why* these largefile tests are useless? For example, is there
another test that covers this already?
-jJ
On 5/7/11, nadeem.vawda wrote:
> http://hg.python.org/cpython/rev/201dcfc56e86
> changeset: 69886:201dcfc56e86
> branch:
Are you asserting that all foreign modules (or at least all handled by
this) are in C, as opposed to C++ or even Java or Fortran? (And the C
won't change?)
Is this ASCII restriction (as opposed to even UTF8) really needed?
Or are you just saying that we need to create an ASCII name for passing t
Does this really need to be a bare except?
On Sat, Jun 18, 2011 at 8:21 PM, r.david.murray
wrote:
> http://hg.python.org/cpython/rev/9c96c3adbcd1
> changeset: 70867:9c96c3adbcd1
> user: R David Murray
> date: Sat Jun 18 20:21:09 2011 -0400
> summary:
> #6771: Move wrapper functi
If you're going to get rid of the pun, you might as well change the
whole sentence...
On Sun, Jul 3, 2011 at 1:22 PM, georg.brandl wrote:
> http://hg.python.org/cpython/rev/76452b892838
> changeset: 71146:76452b892838
> parent: 71144:ce52310f61a0
> user: Georg Brandl
> date:
Martin v. Löwis schrieb:
> That docutils happens to be written in Python should make little
> difference - it's *not* part of the Python language project,
> and is just a tool for us, very much like latex and latex2html.
Not entirely. When I first started looking at python, I read a lot of
docum
Greg,
If you do update this PEP, please update the __not__ portion as well,
at least regarding possible return values.
It currently says that __not__ can return NotImplemented, which falls
back to the current semantics. (Why? to override an explicit
__not__? Then why not just put the current
Choosing a revision, such as
http://svn.python.org/view/python/trunk/Objects/?rev=55606&sortby=date&view=log
does not lead to the correct generated page; it either times out or
generates a much older changelog.
___
Python-Dev mailing list
Python-Dev@pyt
> a) import cgi and call cgi module's query_ps. [circular imports]
or
> b) Implement a stand alone query parsing facility in urlparse *AS IN*
> cgi module.
Assuming (b), please remove the (code for the) parsing from the cgi
module, and just import it back from urlparse (or urllib). Since cgi
a
Andy C wrote:
>... a .zip file with a __zipmain__.py module at its root?
Why not just an __init__.py, which you would normally execute if you
tried to import/run a directory?
> * Magically looking at the first argument to see if it's a zip file
> seems problematic to me. I'd rather be explicit w
On 7/14/07, Andy C <[EMAIL PROTECTED]> wrote:
> On 7/13/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > > while I think it would be a bad practice to
> > > import __main__,
> > I have seen it recommended as the right place to store global
> > (cross-mod
Brett Cannon wrote:
> A Signature object has the following structure attributes:
> * name : str
> Name of the function. This is not fully qualified because
> function objects for methods do not know the class they are
> contained within. This makes functions and methods
> indist
urllib goes to goes to some trouble to ensure that it raises IOError,
even when the underlying exception comes from another module.[*] I'm
wondering if it would make sense to just have those modules'
exceptions inherit from IOError.
In particular, should socket.error, ftp.Error and
httplib.HTTPEx
Bill Janssen wrote:
> One thing to watch out for: ssl.SSLError can't
> inherit from socket.error, as it does in 2.6+,
Why not?
-jJ
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http:/
Bill Janssen wrote:
> One thing to watch out for: ssl.SSLError can't
> inherit from socket.error, as it does in 2.6+,
Why not?
-jJ
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http:/
PJE wrote:
> Isn't the simplest way to cache attribute
> lookups to just have a cache dictionary in the type,
> and update that dictionary whenever a change is
> made to a superclass? That's essentially how
> __slotted__ attribute changes on base classes
> work now, isn't it?
Neil Toronto wrote
Neal Norwitz wrote:
>> For codeobject.c, line 327 should not be reachable.
...
Christian Heimes wrote:
> Please suppress the warning. I removed the last
> two lines and GCC complained ...
Either way, it would be worth adding a comment to the source code so
this doesn't come up again.
-jJ
___
On 1/12/08, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On Jan 12, 2008 5:09 PM, Jeffrey Yasskin <[EMAIL PROTECTED]> wrote:
> > During the discussion about the new Rational implementation
> > (http://bugs.python.org/issue1682), Guido and Raymond decided that
> > Decimal should not implement the n
> A simple way to do this would be to push objects whose
> refcounts had reached 0 onto a list instead of finalizing them
> immediately, and have PyEval_EvalFrameEx periodically swap
> in a new to-delete list and delete the objects on the old one.
Some of the memory management threads discussed so
I think (repeatedly) testing an app through IDLE is a reasonable use case.
Would it be reasonable for shutdown to remove logging from
sys.modules, so that a rerun has some chance of succeeding via its own
import?
-jJ
On 3/16/08, vinay.sajip <[EMAIL PROTECTED]> wrote:
> Author: vinay.sajip
> Dat
On 3/19/08, Vinay Sajip <[EMAIL PROTECTED]> wrote:
> > I think (repeatedly) testing an app through IDLE is a reasonable use case.
> [other threads may still have references to loggers or handlers]
> > Would it be reasonable for shutdown to remove logging from
> > sys.modules, so that a rerun ha
What is the precise specification of the builtin "print" function.
Does it call "str", or does it just behave as if the builtin str had
been called?
In 2.5, the print statement ignores any overrides of the str builtin,
but I'm not sure whether a _function_ should -- and I do think it
should be spe
Terry Reedy
> The standard (and to me, preferable) way of dealing
> with such things is to have an 'installation manager'
> that can reinstall as well as delete and that has a
> check box for various things to delete. This is what
> Python needs.
Paul Moore:
> I'd dispute strongly that this i
> Maybe it's not apparent to people that hasn't
> developed in that kind of environment, and
> I'm sorry I'm not able to make this clearer.
I think I understand the issue.
Some contributors will be running under 2.6, others will be running under 3.0.
Either the code forks, or one of them is work
> Are the Linux users happy with having a Python
> package manager that ignores RPM/apt? Why
> should Windows users be any happier?
Because, as you noted, the add/remove programs application is severely
limited.
> I've read one too many "Windows is so broken
> that people who use it obviously don
1 - 100 of 287 matches
Mail list logo
