.
Yikes :)
2. For speed, if the extension is creating dicts (or tuples) it knows
cannot participate in cycles.
The optimization is now automated in the simple cases (as you've found
out!).
This came up when Jim Fulton asked me for advice about assertion
failures coming out of cyclic gc
.
Jim
--
Jim Fulton
Zope Corporation
___
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 Apr 2, 2009, at 7:28 AM, Greg Ewing wrote:
Jim Fulton wrote:
The only type-safety mechanism for a CObject is it's identity. If
you want to make sure you're using the foomodule api, make sure
the address of the CObject is the same as the address of the api
object exported
for the API and the (address of
the) CObject itself already provides this.
2. Only code provided by the module provider should be accessing the
CObject exported by the module.
Jim
--
Jim Fulton
Zope Corporation
___
Python-Dev mailing list
Python-Dev
is a lot simpler and more practically useful.
Jim
--
Jim Fulton
Zope Corporation
___
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
Are there plans for a 2.4 release that includes:
http://bugs.python.org/issue2620, and
http://svn.python.org/view?rev=65335view=rev
?
These (and other fixes) address:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2315
Jim
--
Jim Fulton
Zope Corporation
.
This optimization is fairly useful. I propose to update the logic to
call this function for classic instances too. I'm also open to
renaming it if that would make people happier. :)
Thoughts?
Jim
--
Jim Fulton
Zope Corporation
___
Python-Dev mailing
Recently, I reviewed the documentation source for pickle and came
across the following comment:
BAW: Both pickle and cPickle support something called
inst_persistent_id()
which appears to give unknown types a second shot at producing a
persistent
id. Since Jim Fulton can't
and justifiable.
In general though, for adults, truthfulness and non-anonymity *do*
matter. At least they matter to me, a *lot*. I don't think members
of the PSF should be allowed to hide their identity and certainly,
it should not be acceptable to contribute to Python under a false name.
Jim
--
Jim Fulton
at it. I'm happy to work on this *if* I can find time. This would make
a nice easy sprint project at PyCon too.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com
Steve Holden wrote:
Jim Fulton wrote:
Yesterday, I needed to make a web request in a program (actually a test)
that could block indefinately, so I needed to set a socket timeout.
Unfortunately, AFAICT none of urllib, urllib2, httplib provide options to set
the timeout on the sockets they use
just an argument to make the canonical ordering work better.
The problem Jim Fulton describes is that the (current default)
canonical order will change if objects are saved to a database and
then imported to a different session. Removing default comparisons
wouldn't really help much
Michael Hoffman wrote:
[Ian Bickling]
stdlib, external modules, internal modules seems like enough
ordering to me.
[Jim Fulton]
Personally, I don't find the stdlib/external distinction to be useful.
It's useful because it allows one to quickly see all the prerequisites
need
to examine the value of one of these variables in the debugger.
In my experience, almost every time someone uses the __private
trick, they or someone else comes to regret it.
OTOH, explicit name mangling provides the benefits of implicit
name mangling without it's drawbacks.
Jim
--
Jim Fulton
the style guide smaller. I do think it offers too
much advice in places. Although I'm not sure we could all agree
om what those places are. :)
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope
is more likely to store
the result in a temp variable for use in the same context, instead of
calling it multiple times. Similar reasoning applites for setter vs
property =.
That's why, in my suggested writeup, I suggested that attributes should
be used if the accessors are trivial.
Jim
--
Jim
or a pair
if accessors that just sets and gets an attribute with a slightly different
name,
that affords no more protection than if people were setting the attribute
directly.
If you don't want external code to change an attribute, don't expose it through
a public API.
Jim
--
Jim Fulton
names, it's easier to remember them when
reading code. (Note that ease of use hinges on editors that automate
typeing of repeated names.)
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation
[EMAIL PROTECTED] wrote:
Jim == Jim Fulton [EMAIL PROTECTED] writes:
Jim The decision about wither to implement foo as a key in the instance
Jim dictionary *is* an implementation detail that can be hidden by a
Jim property.
If it's not in the instance dictionary, where
Ian Bicking wrote:
Jim Fulton wrote:
...
Also decide whether your attributes should be private or not.
The difference between private and non-public is that the former
will never be useful for a derived class, while the latter might
be. Yes, you should design
Ian Bicking wrote:
Jim Fulton wrote:
Designing for inheritance
Always decide whether a class's methods and instance variables
should be public or non-public. In general, never make data
variables public unless you're implementing essentially a
record
.
Explicit is better than implicit. :)
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
Guido van Rossum wrote:
On 11/6/05, Jim Fulton [EMAIL PROTECTED] wrote:
...
Except that I really don't think that there's anything wrong with a
default __eq__ that uses object identity. As Martin pointed out, it's
just too weird that an object wouldn't be considered equal to itself.
It's
Jeremy Hylton wrote:
Can anyone point an old CVS/Perforce-Luddite at instructions for how
to use the new SVN repository?
And can you remind us where to send our public keys? :)
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714
and datetime,
why should you try to compare date and DateTime?
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
Based on the discussion, I think I'd go with defaultproperty.
Questions:
- Should this be in builtins, alongside property, or in
a library module? (Oleg suggested propertytools.)
- Do we need a short PEP?
Jim
Jim Fulton wrote:
Guido van Rossum wrote:
On 9/28/05, Jim Fulton [EMAIL
.
Someone else pointed out essentially the same thing at the beginning
of this thread.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
model which is favoured for a hypothetical
future version of Python.
This approach has worked pretty well for us. Still, when there is a problem,
it's a real pain to debug because the error occurs too late, as you point
out.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python
in the first place, except in this case to disable implicit
encoding or decoding.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
Guido van Rossum wrote:
On 9/28/05, Jim Fulton [EMAIL PROTECTED] wrote:
...
I think we need to be real careful with chosing a name -- in Jim's
example, *anyone* could assign to Spam().eggs to override the value.
The name readproperty is too close to readonlyproperty,
In fact, property
descriptor.) I'd be happy to add this for 2.5.
Thoughts?
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
Tim Peters wrote:
...
I'm sending this to Jim Fulton because he did the conversion of Zope
Corp's code base to SVN. Unfortunately, Jim will soon be out of touch
for several weeks. Jim, do you have time to summarize the high bits
of the problems you hit? IIRC, you didn't find any conversion
believe all serious
problems were identified by eyeball at once.
I'm not aware of any errors in the conversion.
...
Ah, before I forget, single repository has worked very well for Zope
Yup.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361
what the projects are, I suggest
converting each project separately. I'd be happy to
share my scrips and experenice, although, as Tim noted
I'll be off-line for two or three weeks starting in the
next few days.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO
Martin v. Löwis wrote:
Jim Fulton wrote:
I don't expect that this would be an issue for Python.
Right.
2. I initially tried to conver our entire repository, including all
branches. This would have taken days. I finally decided to just
convert our trunk, which took several
that
either implementing interfaces (or implementing a class statement
in which the class was created before execution of a suite)
is not a use case for this PEP.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http
hooks. There are exceptions of course.
Our ZODB storage tests use a generic storage-interface test, but this
is possible because the ZODB storage interfaces are extremely
concrete.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714
37 matches
Mail list logo
