Hi,
> abc (2.6)
I’m not sure this module is very useful without built-in support in
isinstance and issubclass.
> collections.OrderedDict (2.7)
> unittest2 (2.7)
Why not depend on the backports available on PyPI instead of
re-backporting these in your project?
> My second doubt is about morality.
On 10/8/2011 12:57 PM, Giampaolo Rodolà wrote:
I have a couple of doubts about this though.
The first one is about licensing.
Other have answered -- follow the license in giving credit, etc.
My second doubt is about morality.
Although this might be useful to those people who are forced to us
2011/10/8 Dirkjan Ochtman :
> On Sat, Oct 8, 2011 at 21:47, Toshio Kuratomi wrote:
>> I have some similar code in kitchen:
>> http://packages.python.org/kitchen/api-overview.html
>
> It also sounds similar to six:
>
> http://pypi.python.org/pypi/six
Though six tries to be a bit minimalist and doe
On Sat, Oct 8, 2011 at 21:47, Toshio Kuratomi wrote:
> I have some similar code in kitchen:
> http://packages.python.org/kitchen/api-overview.html
It also sounds similar to six:
http://pypi.python.org/pypi/six
Avoid all the duplicate efforts would certainly make sense.
Cheers,
Dirkjan
___
I have some similar code in kitchen:
http://packages.python.org/kitchen/api-overview.html
It wasn't as ambitious as your initial goals sound (I was only working on
pulling out what was necessary for what people requested rather than an
all-inclusive set of changes). You're welcome to join me and
On Sat, Oct 8, 2011 at 8:35 PM, "Martin v. Löwis" wrote:
>> The first one is about licensing.
>> What I would be doing is basically copy& paste pieces of the python
>> stdlib modules (including tests) and, where needed, adjust them so
>> that they work with older python versions.
>> Would this re
The first one is about licensing.
What I would be doing is basically copy& paste pieces of the python
stdlib modules (including tests) and, where needed, adjust them so
that they work with older python versions.
Would this represent problem?
You have a "nonexclusive, royalty-free, world-wide li
Ciao Giampaolo,
> I have a couple of doubts about this though.
> The first one is about licensing.
> What I would be doing is basically copy & paste pieces of the python
> stdlib modules (including tests) and, where needed, adjust them so
> that they work with older python versions.
> Would this
Hello everybody,
at work we're using different versions of python, from 2.4 to 2.7.
Because of the differences between the various versions in terms of
features we have a "util.pycompat" module which basically is a copy &
paste of different features which were added to stdlib in every new
major ver
Am 08.10.2011 17:43, schrieb Antoine Pitrou:
> On Sat, 08 Oct 2011 16:54:06 +0200
> "Martin v. Löwis" wrote:
>>
>> I find the ad-hoc approach of declaring and initializing variables
>> inadequate, in particular since it is difficult to clean up all
>> those string objects at interpreter shutdown.
On Sat, 08 Oct 2011 16:54:06 +0200
"Martin v. Löwis" wrote:
>
> I find the ad-hoc approach of declaring and initializing variables
> inadequate, in particular since it is difficult to clean up all
> those string objects at interpreter shutdown.
>
> I propose to add an explicit API to deal with s
On Sat, 08 Oct 2011 17:14:55 +0200
Victor Stinner wrote:
> Le 08/10/2011 15:03, Antoine Pitrou a écrit :
> > On Fri, 07 Oct 2011 21:14:44 -0600
> > Jeffrey wrote:
> >> I would like to suggest adding an integer presentation type for base 36
> >> to PEP 3101. I can't imagine that it would be a wh
Le 08/10/2011 15:03, Antoine Pitrou a écrit :
On Fri, 07 Oct 2011 21:14:44 -0600
Jeffrey wrote:
I would like to suggest adding an integer presentation type for base 36
to PEP 3101. I can't imagine that it would be a whole lot more
difficult than the existing types. Python's built-in long inte
Pretending the snark to be slightly serious: you've missed the point.
The builtbots are building unreliable code, that being the point of the
test suite. Doing unpredictable stuff as root is bad juju.
Running the builtbots and their tests should not be run as root except
for a very few special te
In benchmarking PEP 393, I noticed that many UTF-8 decode
calls originate from C code with static strings, in particular
PyObject_CallMethod. Many of such calls already have been optimized
to cache a string object, however, PyObject_CallMethod remains
unoptimized since it requires a char*.
I find
Stephen J. Turnbull wrote:
> Andrew Bennetts writes:
>
> > No, that just means you shouldn't trust *root*. Which is where a
> > VM is a very useful tool. You can have the “as root” environment
> > for your tests without the need to have anything important trust it.
>
> Cameron acknowledges t
16 matches
Mail list logo
