Hi,
I've just left the soc2009-mentors list on request, as I'm not a
mentor. So if you need my input on the mentor side regarding ideas
I've contributed to [1] (struct, socket, core helper tools or
Roundup), please CC me.
Best regards,
Daniel
[1]
Thanks Larry.
I didn't notice the patch, or indeed the defect, hence my question.
A clarification in the documentation that a string comparison is indeed used
might be useful.
As a user of CObject I appreciate this effort.
K
-Original Message-
From: Larry Hastings
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 by
the module.
I don't follow that. If you already have
Apologies if this has already been discussed.
I was expecting that by now, python 3.0, the following code:
# clean the target dir
import errno
try:
shutil.rmtree(trace_output_path)
except OSError, ex:
if ex.errno not
Greg Ewing wrote:
Attaching some kind of type info to a CObject and having
an easy way of checking it makes sense to me. If the
existing CObject API can't be changed, maybe a new
enhanced one could be added.
I thought the entire *point* of C object was that it's an opaque box
without any info
On Apr 1, 2009, at 11:51 PM, Guido van Rossum wrote:
...
Note also this cheap exported-vtable hack isn't the
only use of CObjects; for example _ctypes uses them to wrap plenty of
one-off objects which are never set as attributes of the _ctypes
module.
We'd like a solution that enforces some
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 by the
Hello there.
Yesterday I created a number of defects for regression test failures on Windows:
http://bugs.python.org/issue5646 : test_importlib fails for py3k on Windows
http://bugs.python.org/issue5645 : test_memoryio fails for py3k on windows
http://bugs.python.org/issue5643 : test__locale fails
I propose the following PEP for inclusion to Python 3.1.
Please comment.
Regards,
Martin
Abstract
Namespace packages are a mechanism for splitting a single Python
package across multiple directories on disk. In current Python
versions, an algorithm to compute the packages __path__ must
At 10:32 AM 4/2/2009 -0500, Martin v. Löwis wrote:
I propose the following PEP for inclusion to Python 3.1.
Please comment.
An excellent idea. One thing I am not 100% clear on, is how to get
additions to sys.path to work correctly with this. Currently, when
pkg_resources adds a new egg to
On Thu, Apr 2, 2009 at 6:22 AM, Jim Fulton j...@zope.com wrote:
The original use case for CObjects was to export an API from a module, in
which case, you'd be importing the API from the module.
I consider this the *only* use case. What other use cases are there?
The presence in the
module
Guido van Rossum guido at python.org writes:
On Thu, Apr 2, 2009 at 6:22 AM, Jim Fulton jim at zope.com wrote:
The original use case for CObjects was to export an API from a module, in
which case, you'd be importing the API from the module.
I consider this the *only* use case. What other
On Thu, Apr 2, 2009 at 10:24 AM, Antoine Pitrou solip...@pitrou.net wrote:
Guido van Rossum guido at python.org writes:
On Thu, Apr 2, 2009 at 6:22 AM, Jim Fulton jim at zope.com wrote:
The original use case for CObjects was to export an API from a module, in
which case, you'd be importing
On Thu, Apr 2, 2009 at 04:16, John Ehresman j...@wingware.com wrote:
Collin Winter wrote:
Have you measured the impact on performance?
I've tried to test using pystone, but am seeing more differences between
runs than there is between python w/ the patch and w/o when there is no hook
On Wed, Apr 1, 2009 at 12:50 PM, Ron DuPlain ron.dupl...@gmail.com wrote:
On Mon, Mar 30, 2009 at 9:29 PM, Benjamin Peterson benja...@python.org
wrote:
2009/3/30 Collin Winter coll...@gmail.com:
If anyone is interested in working on this during the PyCon sprints or
otherwise, here are some
The measurements are just a distractor. We all already know that the hook is
being added to a critical path. Everyone will pay a cost for a feature that
few people will use. This is a really bad idea. It is not part of a thorough,
thought-out framework of container hooks (something that
Guido van Rossum wrote:
On Thu, Apr 2, 2009 at 6:22 AM, Jim Fulton j...@zope.com wrote:
The original use case for CObjects was to export an API from a module, in
which case, you'd be importing the API from the module.
I consider this the *only* use case. What other use cases are there?
Guido van Rossum wrote:
OK, my proposal would be to agree on the value of this string too:
module.variable.
That's a fine idea for cases where the CObject is stored as an attribute
of a module; my next update of my patch will change the existing uses to
use that format.
Why would you
P.J. Eby wrote:
Apart from that, this mechanism sounds great! I only wish there was a
way to backport it all the way to 2.3 so I could drop the messy bits
from setuptools.
Maybe we could? :-)
Chris
--
Simplistix - Content Management, Zope Python Consulting
-
2009/4/2 Gustavo Carneiro gjcarne...@gmail.com:
Apologies if this has already been discussed.
I don't believe it has ever been discussed to be implemented.
Apparently no one has bothered yet to turn OSError + errno into a hierarchy
of OSError subclasses, as it should. What's the problem, no
On 2009-04-02 17:32, Martin v. Löwis wrote:
I propose the following PEP for inclusion to Python 3.1.
Thanks for picking this up.
I'd like to extend the proposal to Python 2.7 and later.
Please comment.
Regards,
Martin
Specification
=
Rather than using an imperative
On Thu, Apr 2, 2009 at 4:25 PM, Benjamin Peterson benja...@python.org wrote:
2009/4/2 Gustavo Carneiro gjcarne...@gmail.com:
Apologies if this has already been discussed.
I don't believe it has ever been discussed to be implemented.
Apparently no one has bothered yet to turn OSError + errno
R. David Murray wrote:
On Wed, 1 Apr 2009 at 13:12, Chris Withers wrote:
Guido van Rossum wrote:
Well hold on for a minute, I remember we used to have an exec
statement in a class body in the standard library, to define some file
methods in socket.py IIRC.
But why an exec?! Surely there
On Thu, Apr 2, 2009 at 2:16 PM, Chris Withers ch...@simplistix.co.uk wrote:
R. David Murray wrote:
On Wed, 1 Apr 2009 at 13:12, Chris Withers wrote:
Guido van Rossum wrote:
Well hold on for a minute, I remember we used to have an exec
statement in a class body in the standard library, to
Guido van Rossum wrote:
from functools import partial
from new import instancemethod
def meth(name,self,*args):
return getattr(self._sock,name)(*args)
for _m in _socketmethods:
p = partial(meth,_m)
p.__name__ = _m
p.__doc__ = getattr(_realsocket,_m).__doc__
m =
On Thu, Apr 2, 2009 at 2:21 PM, Chris Withers ch...@simplistix.co.uk wrote:
Guido van Rossum wrote:
from functools import partial
from new import instancemethod
def meth(name,self,*args):
return getattr(self._sock,name)(*args)
for _m in _socketmethods:
p = partial(meth,_m)
http://bugs.python.org/issue3609 requests to move the function
parse_header present in cgi module to email package.
The reasons for this request are:
1) The MIME type header parsing methods rightly belong to email
package. Confirming to RFC 2045.
2) parse_qs, parse_qsl were similarly moved from
Hey All,
I have to admit to not having the willpower to plough through the 200
unread messages in the packaging thread when I got back from PyCon but
just wanted to throw out a few thoughts on what my python packaging
utopia would look like:
- python would have a package format that
Hello all,
The unittest module is around 1500 lines of code now, and the tests are
3000 lines.
It would be much easier to maintain as a package rather than a module.
Shall I work on a suggested structure or are there objections in principle?
Obviously all the functionality would still be
Wow. Can you possibly be more negative?
I think it's worse to give the poor guy the run around
by making him run lots of random benchmarks. In
the end, someone will run a timeit or have a specific
case that shows the full effect. All of the respondents
so far seem to have a clear intuition
On Thu, 2009-04-02 at 16:58 -0500, Michael Foord wrote:
Hello all,
The unittest module is around 1500 lines of code now, and the tests are
3000 lines.
It would be much easier to maintain as a package rather than a module.
Shall I work on a suggested structure or are there objections in
Raymond Hettinger python at rcn.com writes:
It seems weird to me that Collin's group can be working
so hard just to get a percent or two improvement in
specific cases for pickling while python-dev is readily
entertaining a patch that slows down the entire language.
I think it's really
It seems weird to me that Collin's group can be working
so hard just to get a percent or two improvement in
specific cases for pickling while python-dev is readily
entertaining a patch that slows down the entire language.
[Antoine Pitrou]
I think it's really more than a percent or two:
On Thu, Apr 2, 2009 at 03:23, Christian Heimes li...@cheimes.de wrote:
John Ehresman wrote:
* To what extent should non-debugger code use the hook? At one end of
the spectrum, the hook could be made readily available for non-debug use
and at the other end, it could be documented as being
On Fri, Apr 3, 2009 at 00:07, Raymond Hettinger pyt...@rcn.com wrote:
It seems weird to me that Collin's group can be working
so hard just to get a percent or two improvement in specific cases for
pickling while python-dev is readily entertaining a patch that slows down
the entire language.
On Thu, Apr 2, 2009 at 3:07 PM, Raymond Hettinger pyt...@rcn.com wrote:
Wow. Can you possibly be more negative?
I think it's worse to give the poor guy the run around
Mind your words please.
by making him run lots of random benchmarks. In
the end, someone will run a timeit or have a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Apr 2, 2009, at 4:58 PM, Michael Foord wrote:
The unittest module is around 1500 lines of code now, and the tests
are 3000 lines.
It would be much easier to maintain as a package rather than a
module. Shall I work on a suggested structure
(cross-posting back to python-dev to finalize discussions)
2009/4/2 Guido van Rossum gu...@python.org
[...]
The problem you report:
try:
...
except OSWinError:
...
except OSLinError:
...
Would be solved if both OSWinError and OSLinError were always defined in
Iterators can implement a method called __length_hint__ that provides a hint
to certain internal routines (such as list.extend) so they can operate more
efficiently. As far as I can tell, __length_hint__ is currently
undocumented. Should it be?
If so, are there any constraints on what an
Iterators can implement a method called __length_hint__ that provides a hint
to certain internal routines (such as list.extend) so they can operate more
efficiently. As far as I can tell, __length_hint__ is currently
undocumented. Should it be?
This has been discussed, and no, it is a
Phillip J. Eby p...@telecommunity.com writes:
However, there's currently no standard, as far as I know, for what
encoding the PKG-INFO file should use.
Who would define such a standard? My vote goes for “default is UTF-8”.
Meanwhile, the 'register' command accepts Unicode, but is broken in
At 10:33 PM 4/2/2009 +0200, M.-A. Lemburg wrote:
That's going to slow down Python package detection a lot - you'd
replace an O(1) test with an O(n) scan.
I thought about this too, but it's pretty trivial considering that
the only time it takes effect is when you have a directory name that
Hrvoje Niksic wrote:
I thought the entire *point* of C object was that it's an opaque box
without any info whatsoever, except that which is known and shared by
its creator and its consumer.
But there's no way of telling who created a given
CObject, so *nobody* knows anything about it for
Jim Fulton wrote:
The original use case for CObjects was to export an API from a module,
in which case, you'd be importing the API from the module. The presence
in the module indicates the type.
Sure, but it can't hurt to have an additional sanity
check.
Also, there are wider uses for
Martin v. Löwis schrieb:
I propose the following PEP for inclusion to Python 3.1.
Please comment.
Regards,
Martin
Abstract
Namespace packages are a mechanism for splitting a single Python
package across multiple directories on disk. In current Python
versions, an algorithm
At 03:21 AM 4/3/2009 +0200, Matthias Klose wrote:
+1 speaking as a downstream packaging python for Debian/Ubuntu I
welcome this approach. The current practice of shipping the very
same file (__init__.py) in different packages leads to conflicts for
the installation of these packages (this is
Hello,
I just noticed that the new io-c modules were merged in the py3k
branch (I know, I am kind late on the news—blame school work). Anyway,
I am just wondering if it would be a good idea to put the io-c modules
in a sub-directory (like sqlite), instead of scattering them around in
the Modules/
Chris Withers writes:
Personally I feel all of the above are perfectly possible, and can't see
anyone being left unhappy by them. I'm sure I've missed something then,
otherwise why not make it happen?
Labor shortage.
We will need a PEP, the PEP will need a sample implementation, and
a
48 matches
Mail list logo
