On Tue, Oct 11, 2011 at 12:14 PM, Toshio Kuratomi wrote:
> This may not be the preferred manner to write decorators but it's fairly
> straightforward and easy to remember compared to, say, porting away from
> the
> with statement.
>
You can emulate 'with' using decorators, actually, if you don't
On Tue, Oct 11, 2011 at 01:49:43PM +0100, Michael Foord wrote:
> On 10/10/2011 21:21, Giampaolo Rodolà wrote:
> >
> >Toshio Kuratomi wrote:
> >>I have a need to support a small amount of code as far back as python-2.3
> >>I don't suppose you're interested in that as well? ;-)
> >I'm still not sure
On 11/10/2011 16:39, Toshio Kuratomi wrote:
On Tue, Oct 11, 2011 at 12:22:12AM -0400, Terry Reedy wrote:
On 10/10/2011 4:21 PM, Giampaolo Rodolà wrote:
Thanks everybody for your feedback.
I created a gcode project here:
http://code.google.com/p/pycompat/
This project will be easier if the test
On Tue, Oct 11, 2011 at 12:22:12AM -0400, Terry Reedy wrote:
> On 10/10/2011 4:21 PM, Giampaolo Rodolà wrote:
> >Thanks everybody for your feedback.
> >I created a gcode project here:
> >http://code.google.com/p/pycompat/
>
> This project will be easier if the test suite for a particular
> functio
On 10/10/2011 21:21, Giampaolo Rodolà wrote:
Thanks everybody for your feedback.
I created a gcode project here:
http://code.google.com/p/pycompat/
2011/10/8 Antoine Pitrou:
There's also some stuff there that is coded in C, or that will rely on
some functionality of the core interpreter that is
On 10/10/2011 4:21 PM, Giampaolo Rodolà wrote:
Thanks everybody for your feedback.
I created a gcode project here:
http://code.google.com/p/pycompat/
This project will be easier if the test suite for a particular
function/class/module is up to par. If you find any gaping holes, you
might file
Thanks everybody for your feedback.
I created a gcode project here:
http://code.google.com/p/pycompat/
2011/10/8 Antoine Pitrou :
> There's also some stuff there that is coded in C, or that will rely on
> some functionality of the core interpreter that is not easily
> emulated on previous versions
Nick Coghlan gmail.com> writes:
> Should we create an informational PEP or other resource to point
> people towards some of these forwards compatibility options?
Or perhaps a page on www.python.org which is referenced by e.g. a footnote in
PEP 387 (Backwards Compatibility Policy)?
Regards,
Vin
On Mon, Oct 10, 2011 at 11:47 PM, Vinay Sajip wrote:
> Giampaolo Rodolà gmail.com> writes:
>
>> This let us use different stdlib features which appeared in latest
>> Python versions (including 3.2) throughout all our code base.
>> Now, what I have in mind is to release this as a public module so
Giampaolo Rodolà gmail.com> writes:
> This let us use different stdlib features which appeared in latest
> Python versions (including 3.2) throughout all our code base.
> Now, what I have in mind is to release this as a public module so that
> everyone who cannot upgrade to a recent python versio
On 08/10/2011 20:38, Maciej Fijalkowski wrote:
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
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
20 matches
Mail list logo
