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
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/
Senthil Kumaran writes:
> 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.
In
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 n
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
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 CObje
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
cert
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
mat
"Phillip J. Eby" 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
> handling it. […]
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 implemen
2009/4/2 Daniel Stutzbach :
> 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 d
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 iterato
(cross-posting back to python-dev to finalize discussions)
2009/4/2 Guido van Rossum
[...]
> > The problem you report:
> >>
> >> try:
> >>...
> >> except OSWinError:
> >>...
> >> except OSLinError:
> >>...
> >>
> >
> > Would be solved if both OSWinError and OSLinError were always
-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 or
On Thu, Apr 2, 2009 at 3:07 PM, Raymond Hettinger 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 specific
> case
On Fri, Apr 3, 2009 at 00:07, Raymond Hettinger 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.
Collin's
On Thu, Apr 2, 2009 at 03:23, Christian Heimes 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 debug only,
>>
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:
ht
Raymond Hettinger 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 more
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 objectio
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 th
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 av
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 included
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
On Thu, Apr 2, 2009 at 2:21 PM, Chris Withers 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)
>>>
Hello,
On Thu, Apr 2, 2009 at 22:35, Jack diederich wrote:
> On Thu, Apr 2, 2009 at 4:25 PM, Benjamin Peterson wrote:
>> 2009/4/2 Gustavo Carneiro :
>>> Apologies if this has already been discussed.
>>
>> I don't believe it has ever been discussed to be implemented.
>>
>>> Apparently no one has
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 = instancemethod(p,N
Wow. Can you possibly be more negative?
2009/4/2 Raymond Hettinger :
> 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
On Thu, Apr 2, 2009 at 2:16 PM, Chris Withers 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
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 m
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Apr 2, 2009, at 3:35 PM, Jack diederich wrote:
On Thu, Apr 2, 2009 at 4:25 PM, Benjamin Peterson
wrote:
2009/4/2 Gustavo Carneiro :
Apologies if this has already been discussed.
I don't believe it has ever been discussed to be implemented.
On Thu, Apr 2, 2009 at 4:25 PM, Benjamin Peterson wrote:
> 2009/4/2 Gustavo Carneiro :
>> 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 s
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 impera
2009/4/2 Gustavo Carneiro :
> 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 will to do it,
> o
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
- http://www.simplist
Martin v. Löwis wrote:
I propose the following PEP for inclusion to Python 3.1.
Please comment.
Would this support the following case:
I have a package called mortar, which defines useful stuff:
from mortar import content, ...
I now want to distribute large optional chunks separately, but id
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
Hrvoje Niksic wrote:
If we're adding type information, then please make it a Python object
rather than a C string. That way the creator and the consumer can use
a richer API to query the "type", such as by calling its methods or by
inspecting it in some other way.
I'm not writing my patch t
Guido van Rossum wrote:
On Thu, Apr 2, 2009 at 6:22 AM, 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.
I consider this the *only* use case. What other use cases are there?
Exporting a
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 woul
On Wed, Apr 1, 2009 at 12:50 PM, Ron DuPlain wrote:
> On Mon, Mar 30, 2009 at 9:29 PM, Benjamin Peterson
> wrote:
>> 2009/3/30 Collin Winter :
>>> If anyone is interested in working on this during the PyCon sprints or
>>> otherwise, here are some easy, concrete starter projects that would
>>> re
On Thu, Apr 2, 2009 at 04:16, John Ehresman 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
> installed.
On Thu, Apr 2, 2009 at 10:24 AM, Antoine Pitrou wrote:
> Guido van Rossum python.org> writes:
>>
>> On Thu, Apr 2, 2009 at 6:22 AM, Jim Fulton 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 modu
Guido van Rossum python.org> writes:
>
> On Thu, Apr 2, 2009 at 6:22 AM, Jim Fulton 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
On Thu, Apr 2, 2009 at 6:22 AM, 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.
I consider this the *only* use case. What other use cases are there?
> The presence in the
> module indicates th
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 s
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
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
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 mo
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 s
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
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
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 the
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 [mailto:la...@hastings.o
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] http://wiki.python.org/moin/SummerOfCode/2009/Inco
55 matches
Mail list logo
