For correctness, if the extension is playing games with reference
>> counts Python isn't expecting.
>
> Yikes :)
>
>> 2. For speed, if the extension is creating dicts (or tuples) it knows
>> cannot participate in cycles.
>
> The optimization is now automated in
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 expor
Larry's example.
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
he
bug tracker:
http://bugs.python.org/issue5630
I look forward to your comments!
-1
I don't see that this gains anything.
1. All you're adding, afaict is a name for the API and the (address of
the) CObject itself already provides this.
2. Only code provided by the module pro
see some value in this, but I think working at the
project level 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
Uns
Are there plans for a 2.4 release that includes:
http://bugs.python.org/issue2620, and
http://svn.python.org/view?rev=65335&view=rev
?
These (and other fixes) address:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2315
Jim
--
Jim Fulton
Zope Corpora
It doesn't make sense to not call this function for classic instances.
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 m
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&#
st 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 mailto:[EMAIL PROTECTED] Python Powered!
CTO (54
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
>
. 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.zop
>
> Even the recently posted "get rid of default comparisons" use case is
> really 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 databa
ly descriptors, which make
properties, among other things, possible.
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
_
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.
>
>
>
Barry Warsaw wrote:
> On Sun, 2005-12-11 at 11:20 -0500, Jim Fulton wrote:
>
>
>>This seems outdated. My impression, in part from time spent
>>working with the Python Labs guys, is that it is fine to have public
>>data sttributes even for non-"record" type
ts" rule for data attributes, but attributes
> that cause an object to perform some action should always be explicit
> methods.
Exactly. That's why I suggested the PEP start with the trivial case,
which, BTW is extremely common. Let judgement guide when something
is
ovided the necessary methods.
A better approach is to document the API for your classes and expect
people to use that API. Prepending an underscore documents that a
variable or method is internal. (Of course, there's still the subclassing
API to deal
[EMAIL PROTECTED] wrote:
...
> This is subjective enough that I would think some rationale explaining this
> convention should be given.
This is subjective enough that I don't think it should be in the PEP.
Sometimes, less is more.
JIm
--
Jim Fulton mailto:[EMAI
oupings to me. (All of
my "internal" modules are in packages.) When scanning imports, I
don't want to have to think about whether a module is internal or
external. I've got enough to think about without that. :)
Frankly, I'd be as happy t see the PEP be silent on
Guido van Rossum wrote:
> On 12/12/05, Jim Fulton <[EMAIL PROTECTED]> wrote:
>
>>In practice, I don't agree that it works fine. Inevitably, someone
>>finds a need to access a "private" variable in a subclass. Or
>>even in the original cl
gn code changes an object's state. If you provide a property 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 attribu
the accessors are trivial.
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
___
Python-Dev mai
P 8 for the minimum practices necessary for
> one programmer to be able to read and maintain another programmer's
> code.
I'm for making 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
mulate the name mangling. Or perhaps someone wants
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 m
ty that accessor methods would give you.
>
> Don't properties only work with new-style clsses? If so, this should
> probably be noted.
Read properties work with old-style classes. Write properties require
old-stype classes. I'm always forgetting this for some reason. Ye
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
>>>v
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 latt
[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
>
e hidden by a property. If the initial decision, following the rule
of "do the simplest thing that works", is to use an instance dictionary item,
then I wouldn't bother with a property until you change your mind.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED]
ed.
FWIW, as a general rule, I like using a single trailing underscore,
especially for keywords. It allows the use of meaningful and easy
to remember names. When the name of a variable should be "class" or
"for" or whatever, it's easy, as a Python programmer, to remembe
out what's best for a particular situation.
> ET
> belongs in the standard distribution to create a level playing field for a
> module many people feel is superior to the current XML-related modules.
> Think of it as Pythonic affirmative action. ;-)
I would only think of it as Pytho
Steve Holden wrote:
> Jim Fulton wrote:
> [...]
>
>>I hope that packaging progress will someday make it matter much less
>>whether something is in the standard library.
>>
>
> For which we need a *mechanism* that all package providers can
> implement, r
t; That said, I agree that ElementTree would be a valuable addition
> to the Python library, and has certainly passed the "collect feedback
> in the real world" test.
I hope that packaging progress will someday make it matter much less
whether something is in the standard library
is sounds acceptable?
Since you can now (as of 2.4) subclass the weakref.ref class, you should be
able to
do this yourself in Python. See for example, weakref.KeyedRef.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714
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 wo
comparison.
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://ww
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) 36
date
objects or compare date objects to DateTime objects. After all,
if the datetime module doesn't allow compatison of date and datetime,
why should you try to compare date and DateTime?
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (54
Guido van Rossum wrote:
> On 10/9/05, Jim Fulton <[EMAIL PROTECTED]> wrote:
>
>>Based on the discussion, I think I'd go with defaultproperty.
>
>
> Great.
>
>
>>Questions:
>>
>>- Should this be in builtins, alongside property, or
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, J
an
a time-stamp) strategy for ZODB, although ZEO would make this
extra challenging.
In any case, the important thing to agree on here is that transactions
provide a useful approach to concurrency control in the case where
- separate control flows are independent, and
- we need to mediate access to sha
ng a sitecustomize.py module which then call the
> sys.setdefaultencoding("undefined").
This is a much more evil trick IMO, as it affects all Python code,
rather than a single program.
I would argue that it's evil to change the default encoding
in the first place, except in thi
is
> semantically textual, and to only use str for what is to be semantically
> treated as a string of bytes (network packets, identifiers...). This is
> also, AFAIU, the semantic model which is favoured for a hypothetical
> future version of Python.
This approach has worked pret
(possibly thousands) of programmers who have used this technique
in Zope, probably without even realizing that they were doing concurrent
programming.
J2EE systems use a similar approach.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 3
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 c
ate a read
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
Martin v. Löwis wrote:
> Jim Fulton wrote:
>
>>I did convert projects individually. I told cvs2svn to just create dump
>>files. I then used svnload to load the dump files myself so that
>>I could make each project a top-level directory with it's own
>>trunk, b
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 d
abized by "projects",
where separate projects reflect more or less independent
development efforts with their own teams and schedules.
(Maybe Python doesn't have many of these.)
> 2. state how the conversion should be performed
Once you decide what the project
I'd still like to hear from Jim, as I don't 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
--
Ji
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? IIR
thunk implementation. It
would be a lot simpler, doing just what is required
without any jiggery pokery with exceptions and
break/continue/return statements. It would be easy
to explain what it does and why it's useful.
"Simple is better than Complex."
Is there a thunk PEP?
Jim
--
Duncan Booth wrote:
Jim Fulton <[EMAIL PROTECTED]> wrote in news:[EMAIL PROTECTED]:
Guido van Rossum wrote:
I've written a PEP about this topic. It's PEP 340: Anonymous Block
Statements (http://python.org/peps/pep-0340.html).
Some observations:
1. It looks to me like a bare re
ariable manipulation. I'm guessing 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
email)
___
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/jim%40zope.com
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714
try:
True, False
except NameError:
True, False = 1, 0
from ever ever happening again.
- This, I hope, needs no further explanation
Anthony
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO
uire lots of inconvenient 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
Armin Rigo wrote:
Hi Jim,
On Tue, Jan 04, 2005 at 02:44:43PM -0500, Jim Fulton wrote:
Actually, unbound builtin methods are a different type than bound
builtin methods:
Of course, but conceptually they are similar. You would still
encounter the concept if you got an unbound builtin method.
There
than bound
builtin methods:
Of course, but conceptually they are similar. You would still
encounter the concept if you got an unbound builtin method.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope C
wouldn't break with the change. We'd still
have bound methods.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope
so the concept won't
go away. In fact, the change would mean that the behavior between
builtin methods and python methods would become more inconsistent.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.o
st argument if it is non-NULL.
It loosly models a Python assignment, assuming that it owns the
reference to the second argument.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http:
Tim Peters wrote:
[Jim Fulton]
Ugh. Part of the problem is that all of those calls are unchecked,
Dang us. If they were checked, then, who knows, we might have
gotten informative exceptions.
They certainly "should" be checked, but as a pragmatic matter
PyInt_FromLong(1) can't
be the reason that
such a "stupid" call return NULL in a reproducable way?
Ugh. Part of the problem is that all of those calls are unchecked,
Dang us. If they were checked, then, who knows, we might have
gotten informative exceptions.
I'd say the first step should be to add che
64 matches
Mail list logo
