On 1 juil. 2013, at 23:44, VernonCole wrote:
> Dropping support of 3.2 would potentially aid projects which have not yet
> converted to Python 3, since Python 3.3 supports u"Unicode Literals" but 3.2
> does not.
Third-party projects are free to set their own version requirements. For
instance
Hi Wim,
I've heard about 5 for 1. You're right, I should give some more of my time
before asking that of others. I'll give that a good go at the PyCon AU
sprints in a few days.
Cheers,
- Roger
On 2 July 2013 07:13, Wim Feijen wrote:
> Hi Roger,
>
> Probably the best way to get some love is to
Debian Wheezy and Ubuntu 12.04 LTS are both on Python 3.2.
On Mon, Jul 1, 2013 at 5:44 PM, VernonCole wrote:
>
> Dropping support of 3.2 would potentially aid projects which have not yet
> converted to Python 3, since Python 3.3 supports u"Unicode Literals" but
> 3.2 does not. Skipping over the
On Mon, Jul 1, 2013 at 10:47 PM, Warren Smith wrote:
> On Fri, Jun 28, 2013 at 5:49 PM, Russell Keith-Magee <
> russ...@keith-magee.com> wrote:
>
>>
>> A third approach would be a new setting, for AWARE_TIME_FORMAT that would
only get used if you pass a datetime object to |time; this *would*
Dropping support of 3.2 would potentially aid projects which have not yet
converted to Python 3, since Python 3.3 supports u"Unicode Literals" but
3.2 does not. Skipping over the early 3.x versions vastly eases transition
from 2.6 to 3.3.
Besides, what are the chances that someone running Pyt
Hi Roger,
Probably the best way to get some love is to do a 5 for 1. Did you hear of
that before?
It means that if you look into five tickets and/or patches from other
people, that you state here: I did a five for one. In my experience, core
contributors are very willing to give a hand then. (
On 1 juil. 2013, at 17:17, Peter Herndon wrote:
> So, there's a supported version of Python 2.7 and 3.3 for RHEL 6, which
> should make Python deprecation choices easier. I would suggest that the above
> link get some mention in the documentation, as this will make things much
> easier to sell
Hi Juan,
Thanks for your detailed examination and report. The best way to proceed is
definitely to create a ticket in trac:
https://code.djangoproject.com/newticket .
Then, if you are willing and like to become a contributor, you can either
add a patch or create a pull request on github.
Tha
On 07/01/2013 10:34 AM, Clayton Keller wrote:
On 07/01/2013 10:17 AM, Peter Herndon wrote:
Hi all,
For those on RHEL6 or a derivative, please note that RHEL Software
Collections will provide an installation source for Python 2.7 and
3.3, as well as Postgres 9.2 and both MySQL 5.5 and MariaDB 5.
On 07/01/2013 10:17 AM, Peter Herndon wrote:
Hi all,
For those on RHEL6 or a derivative, please note that RHEL Software Collections
will provide an installation source for Python 2.7 and 3.3, as well as Postgres
9.2 and both MySQL 5.5 and MariaDB 5.5, and works for RHELs 6.2-6.4.
Furthermore,
Hi all,
For those on RHEL6 or a derivative, please note that RHEL Software Collections
will provide an installation source for Python 2.7 and 3.3, as well as Postgres
9.2 and both MySQL 5.5 and MariaDB 5.5, and works for RHELs 6.2-6.4.
Furthermore, "With the notable exception of Node.js, all Re
On Fri, Jun 28, 2013 at 5:49 PM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:
>
> A third approach would be a new setting, for AWARE_TIME_FORMAT that would
>>> only get used if you pass a datetime object to |time; this *would* be able
>>> to use T as an option. However, this means introdu
Hi,
I'm currently working on an application to « soft-delete » objects (mark them
as deleted in the database, and mask them from the queries made using the
default manager).
https://github.com/makinacorpus/django-safedelete
But it can't work well with GeoDjango the way managers are handled now (
13 matches
Mail list logo
