On 6/3/2012 5:02 PM, Nick Coghlan wrote:
The one thing I actually *would* like to see change is for the cadence
of *alpha* releases to be increased to match that of maintenance
releases (that is, I'd like to see Python 3.4a1 released at the same
time as Python 3.3.1: around 6 months after the
On 04.06.2012 01:28, Nick Coghlan wrote:
I apologise, unmaintained is too strong a word. I mean lacking an
owner sufficiently confident in their authority and expertise and with
sufficient time and energy to add,or approve the addition of,
substantial new features which may require significant
So I wondering whether we should abandon the change all together or
attempt it for the next release. Personally, I slightly leaning on
the former option since the two modules are actually fairly different
underneath even though they are used similarly. And also, because it
is getting late to make
I am out of the office until 06/06/2012.
I will be out of the office Monday and Tuesday, June 4-5. I expect to have
some email access but may be delayed in responding.
Note: This is an automated response to your message Python-Dev Digest,
Vol 107, Issue 9 sent on 06/04/2012 0:19:23.
This
I recently opened issue14908. At work, I have to do a bunch of things
with dates, times and timezones, and sometimes Unix timestamps are
also involved (largely for easy compatibility with legacy APIs). I
find the relative obscurity when converting datetimes to timestamps
rather painful; IMO it
On Mon, Jun 4, 2012 at 9:19 PM, Dirkjan Ochtman dirk...@ochtman.nl wrote:
Anyway, I was pointed to issue 2736, which seems to have got a lot of
discouraged core contributors (Victor, Antoine, David and Ka-Ping, to
name just a few) up against Alexander (the datetime maintainer,
AFAIK). It seems
On Mon, Jun 4, 2012 at 2:11 PM, Nick Coghlan ncogh...@gmail.com wrote:
My perspective is that if I'm dealing with strictly absolute time, I
should only need one import: datetime
If I'm dealing strictly with relative time, I should also only need
one import: time
Can you define relative time
On Mon, Jun 4, 2012 at 10:18 PM, Dirkjan Ochtman dirk...@ochtman.nl wrote:
Can you define relative time here? The term makes me think of things
like timedelta.
Timeouts, performance measurement, that kind of thing. Mostly
timescales of less than an hour, and usually less than a minute.
Hello Christian,
On 06/03/2012 03:56 PM, Éric Araujo wrote:
Le 02/06/2012 12:59, Christian Tismer a écrit :
One urgent question: will this feature be backported to Python 2.7?
Features are never backported to the stable versions. virtualenv still
exists as a standalone project which is
[Let's try this again since my last reply was rejected for being too large]
On Mon, Jun 4, 2012 at 9:52 AM, barry.warsaw python-check...@python.org
wrote:
http://hg.python.org/cpython/rev/9c445f4695c1
changeset: 77339:9c445f4695c1
parent: 77328:0808cb8c60fd
user:Barry Warsaw
Thanks for the second set of eyes, Brett.
On Jun 04, 2012, at 10:16 AM, Brett Cannon wrote:
+.. data:: implementation
+
+ An object containing the information about the implementation of the
+ currently running Python interpreter. Its attributes are the those
the those - those
I
On 4 Jun 2012, at 16:10, Barry Warsaw wrote:
[snip...]
+ However, for a structured record type use
:func:`~collections.namedtuple`
What's with the ~?
I'm not sure, but it seems to result in a cross-reference, and I see tildes
used elsewhere, so I guess it's some reST/docutils
On Mon, Jun 4, 2012 at 11:10 AM, Barry Warsaw ba...@python.org wrote:
Thanks for the second set of eyes, Brett.
On Jun 04, 2012, at 10:16 AM, Brett Cannon wrote:
+.. data:: implementation
+
+ An object containing the information about the implementation of the
+ currently running
On Jun 04, 2012, at 01:19 PM, Dirkjan Ochtman wrote:
I recently opened issue14908. At work, I have to do a bunch of things
with dates, times and timezones, and sometimes Unix timestamps are
also involved (largely for easy compatibility with legacy APIs). I
find the relative obscurity when
On Jun 04, 2012, at 02:18 PM, Dirkjan Ochtman wrote:
Personally, I would really like not having to think about the time
module at all, except if I wanted to go low-level (e.g. get a Unix
timestamp from scratch).
+1
Oh and, practicality beats purity.
-Barry
On Jun 04, 2012, at 11:39 AM, Brett Cannon wrote:
OK, then I would add a test to make sure this happens, like
``self.assertEqual(sys.implementation.name, sys.implement.name.lower())``
if you don't want to bother documenting it to make sure other VMs conform.
Good idea. Done.
-Barry
On Mon, Jun 4, 2012 at 8:51 AM, Barry Warsaw ba...@python.org wrote:
On Jun 04, 2012, at 02:18 PM, Dirkjan Ochtman wrote:
Personally, I would really like not having to think about the time
module at all, except if I wanted to go low-level (e.g. get a Unix
timestamp from scratch).
+1
Oh and,
Le 03/06/2012 06:01, Benjamin Peterson a écrit :
2012/6/2solip...@pitrou.net:
results for d9b7399d9e45 on branch default
test_smtplib leaked [154, 154, 154] references, sum=462
Can other people reproduce this one? I can't.
$ ./python -m test -R
On 6/4/12 4:11 PM, Carl Meyer wrote:
Hello Christian,
On 06/03/2012 03:56 PM, Éric Araujo wrote:
Le 02/06/2012 12:59, Christian Tismer a écrit :
One urgent question: will this feature be backported to Python 2.7?
Features are never backported to the stable versions. virtualenv still
exists
On Mon, Jun 4, 2012 at 1:12 PM, Guido van Rossum gu...@python.org wrote:
A big +1 on making conversions between POSIX timestamps and datetime
(with or without timezone) easier.
I am all for achieving this goal, but I think the root of the problem
is not the lack of mxDT's ticks() method. Note
Agreed that having a robust tzinfo object representing local time,
whatever it is would be a good feature too. This shouldn't have to
depend on the Olson tz database; it should just consult the libc
localtime function.
--Guido
On Mon, Jun 4, 2012 at 11:30 AM, Alexander Belopolsky
On Mon, Jun 4, 2012 at 1:12 PM, Guido van Rossum gu...@python.org wrote:
... I heard
a colleague complain that he'd lost several hours trying to figure out
how to determine whether two datetimes were within 24h of each other,
getting confused by what was happening when the two were on
On Mon, Jun 4, 2012 at 11:46 AM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Mon, Jun 4, 2012 at 1:12 PM, Guido van Rossum gu...@python.org wrote:
... I heard
a colleague complain that he'd lost several hours trying to figure out
how to determine whether two datetimes were
Anyway, I was pointed to issue 2736, which seems to have got a lot of
discouraged core contributors (Victor, Antoine, David and Ka-Ping, to
name just a few) up against Alexander (the datetime maintainer,
AFAIK). It seems like a fairly straightforward case of practicality
over purity:
On Mon, 04 Jun 2012 19:36:52 +0200, Antoine Pitrou solip...@pitrou.net wrote:
Le 03/06/2012 06:01, Benjamin Peterson a écrit :
2012/6/2solip...@pitrou.net:
results for d9b7399d9e45 on branch default
test_smtplib leaked [154, 154, 154]
On Mon, Jun 4, 2012 at 3:05 PM, Guido van Rossum gu...@python.org wrote:
You seem to have misread -- I don't want to check if they are exactly
24 hours apart. I want to check if they are at most 24 hours apart.
The timezone can be assumed to be the same on dt1 and dt2.
A variant of (1) was
On Mon, Jun 4, 2012 at 1:57 PM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Mon, Jun 4, 2012 at 3:05 PM, Guido van Rossum gu...@python.org wrote:
You seem to have misread -- I don't want to check if they are exactly
24 hours apart. I want to check if they are at most 24 hours
It's actually the pre-decoration class, since the cell is initialised
before the class is passed to the first decorator. I agree it's a little
weird, but I did try to describe it accurately in the new docs.
--
Sent from my phone, thus the relative brevity :)
On Jun 5, 2012 7:52 AM, PJ Eby
On Sun, May 20, 2012 at 4:38 AM, Nick Coghlan ncogh...@gmail.com wrote:
When writing the docs for types.new_class(), I discovered that the
description of the class creation process in the language reference
was not only hard to follow, it was actually *incorrect* when it came
to describing
On Mon, Jun 4, 2012 at 6:15 PM, Nick Coghlan ncogh...@gmail.com wrote:
It's actually the pre-decoration class, since the cell is initialised
before the class is passed to the first decorator. I agree it's a little
weird, but I did try to describe it accurately in the new docs.
I see that now;
On Tue, Jun 5, 2012 at 8:58 AM, PJ Eby p...@telecommunity.com wrote:
On Mon, Jun 4, 2012 at 6:15 PM, Nick Coghlan ncogh...@gmail.com wrote:
It's actually the pre-decoration class, since the cell is initialised
before the class is passed to the first decorator. I agree it's a little
weird, but
Hi,
I have issues with the installation of rdflib and rdfextras packages on
windows for python 3.2.3. I cannot find anywhere in the document detailing
how to install this packages and succesfully import them in a python
program. not to talk less of accessing it on eclipse indigo.
Kindly help to
Nick Coghlan wrote:
On Tue, Jun 5, 2012 at 8:58 AM, PJ Eby wrote:
The reason for wanting this to be transparent is that 1) if you forget the
redundant class-decorator, mixin, or metaclass, stuff will silently not
work,
Why would it silently not work? What's preventing you from having
(I've been having trouble with my email recently, so I missed this
thread amongst others.)
I personally am no longer that bothered about whether the regex module
makes it into stdlib, but I am still be maintaining it on PyPI. If
someone else wants to integrate it I would, of course, be willing
Hi,
I would like to know if it is too late (or not) to change the
behaviour of open() for text files (TextIOWrapper). Currently, it
calls locale.getpreferredencoding() to get the locale encoding by
default. It is convinient and I like this behaviour... except that it
changes temporary the
On Mon, Jun 4, 2012 at 7:18 PM, Nick Coghlan ncogh...@gmail.com wrote:
On Tue, Jun 5, 2012 at 8:58 AM, PJ Eby p...@telecommunity.com wrote:
On Mon, Jun 4, 2012 at 6:15 PM, Nick Coghlan ncogh...@gmail.com wrote:
It's actually the pre-decoration class, since the cell is initialised
before
MRAB wrote:
I personally am no longer that bothered about whether the regex module
makes it into stdlib, but I am still be maintaining it on PyPI. If
someone else wants to integrate it I would, of course, be willing to
help out.
Are you withdrawing your offer to maintain regex in the stdlib?
On Mon, Jun 4, 2012 at 7:31 PM, Steven D'Aprano st...@pearwood.info wrote:
But changes to the stdlib (bug fixes or functional changes) are very likely
to run at a slower pace to what third-party packages can afford. If you
continue to develop regex outside of the stdlib, that could cause
On Mon, Jun 4, 2012 at 5:25 PM, Guido van Rossum gu...@python.org wrote:
..
But I don't know what ticks() is supposed to do.
.ticks(offset=0.0,dst=-1)
Returns a float representing the instances value in ticks (see above).
The conversion routine assumes that the stored date/time value is
given
On 05/06/2012 01:31, Steven D'Aprano wrote:
MRAB wrote:
I personally am no longer that bothered about whether the regex module
makes it into stdlib, but I am still be maintaining it on PyPI. If
someone else wants to integrate it I would, of course, be willing to
help out.
Are you
On 6/4/2012 7:27 PM, ayodele akingbulu wrote:
I have issues with the installation of rdflib and rdfextras packages on
windows for python 3.2.3. I cannot find anywhere in the document
detailing how to install this packages and succesfully import them in a
python program. not to talk less of
On Tue, Jun 5, 2012 at 10:10 AM, PJ Eby p...@telecommunity.com wrote:
On Mon, Jun 4, 2012 at 7:18 PM, Nick Coghlan ncogh...@gmail.com wrote:
On Tue, Jun 5, 2012 at 8:58 AM, PJ Eby p...@telecommunity.com wrote:
On Mon, Jun 4, 2012 at 6:15 PM, Nick Coghlan ncogh...@gmail.com wrote:
It's
On 6/4/2012 9:22 PM, MRAB wrote:
I'm not planning any further changes to regex. I think it already has
enough features...
Do you have any idea where regex + Python stands in regard to Unicode
TR18 support levels? http://unicode.org/reports/tr18/
While most of the Tailored Support Level 3
On Mon, Jun 4, 2012 at 6:10 PM, PJ Eby p...@telecommunity.com wrote:
I mean that class-level __metaclass__ is no longer supported as of PEP 3115,
so I can't use that as a way to non-invasively obtain the enclosing class at
class creation time.
Depends on what you mean by non-invasive:
*
On Sun, May 20, 2012 at 10:38 AM, Nick Coghlan ncogh...@gmail.com wrote:
When writing the docs for types.new_class(), I discovered that the
description of the class creation process in the language reference
was not only hard to follow, it was actually *incorrect* when it came
to describing
On Mon, Jun 4, 2012 at 10:25 PM, Nick Coghlan ncogh...@gmail.com wrote:
On Tue, Jun 5, 2012 at 10:10 AM, PJ Eby p...@telecommunity.com wrote:
On Mon, Jun 4, 2012 at 7:18 PM, Nick Coghlan ncogh...@gmail.com wrote:
On Tue, Jun 5, 2012 at 8:58 AM, PJ Eby p...@telecommunity.com wrote:
On
On Mon, Jun 4, 2012 at 10:43 PM, Eric Snow ericsnowcurren...@gmail.comwrote:
On Mon, Jun 4, 2012 at 6:10 PM, PJ Eby p...@telecommunity.com wrote:
I mean that class-level __metaclass__ is no longer supported as of PEP
3115,
so I can't use that as a way to non-invasively obtain the enclosing
Can I change this behaviour (before the first beta) in Python 3.3?
Fine with me. That code predates 43e32b2b4004. I don't recall
discussion to set the LC_CTYPE locale and not take it back, but
apparently, this is what Python currently does, which means that
another setlocale call is not
48 matches
Mail list logo
