Can you add a testcase for this?
On Mon, Jun 4, 2012 at 9:01 PM, richard.oudkerk
wrote:
> http://hg.python.org/cpython/rev/3baeb5e13dd2
> changeset: 77348:3baeb5e13dd2
> user: Richard Oudkerk
> date: Mon Jun 04 18:59:07 2012 +0100
> summary:
> Fix potential NameError in multipro
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 necessar
On Mon, Jun 4, 2012 at 10:43 PM, Eric Snow wrote:
> On Mon, Jun 4, 2012 at 6:10 PM, PJ Eby 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.
>
> Depe
On Mon, Jun 4, 2012 at 10:25 PM, Nick Coghlan wrote:
> On Tue, Jun 5, 2012 at 10:10 AM, PJ Eby wrote:
> > On Mon, Jun 4, 2012 at 7:18 PM, Nick Coghlan wrote:
> >>
> >> On Tue, Jun 5, 2012 at 8:58 AM, PJ Eby wrote:
> >> > On Mon, Jun 4, 2012 at 6:15 PM, Nick Coghlan
> wrote:
> >> >>
> >> >> It
On Sun, May 20, 2012 at 10:38 AM, Nick Coghlan 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 the algorithm for
On Mon, Jun 4, 2012 at 6:10 PM, PJ Eby 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:
* http://code.activestate.c
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 stri
On Tue, Jun 5, 2012 at 10:10 AM, PJ Eby wrote:
> On Mon, Jun 4, 2012 at 7:18 PM, Nick Coghlan wrote:
>>
>> On Tue, Jun 5, 2012 at 8:58 AM, PJ Eby wrote:
>> > On Mon, Jun 4, 2012 at 6:15 PM, Nick Coghlan wrote:
>> >>
>> >> It's actually the pre-decoration class, since the cell is initialised
>>
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 acces
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 withdraw
On Mon, Jun 4, 2012 at 5:25 PM, Guido van Rossum 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 in local tim
On Mon, Jun 4, 2012 at 7:31 PM, Steven D'Aprano 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
> complications.
Devel
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:18 PM, Nick Coghlan wrote:
> On Tue, Jun 5, 2012 at 8:58 AM, PJ Eby wrote:
> > On Mon, Jun 4, 2012 at 6:15 PM, Nick Coghlan wrote:
> >>
> >> It's actually the pre-decoration class, since the cell is initialised
> >> before the class is passed to the first decorator. I a
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 LC_CTYPE
(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 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
decorator
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 l
On Tue, Jun 5, 2012 at 8:58 AM, PJ Eby wrote:
> On Mon, Jun 4, 2012 at 6:15 PM, Nick Coghlan 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 accura
On Mon, Jun 4, 2012 at 6:15 PM, Nick Coghlan 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; it might be he
On Sun, May 20, 2012 at 4:38 AM, Nick Coghlan 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 the algorithm for
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" wrote
On Mon, Jun 4, 2012 at 1:57 PM, Alexander Belopolsky
wrote:
> On Mon, Jun 4, 2012 at 3:05 PM, Guido van Rossum 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 b
On Mon, Jun 4, 2012 at 3:05 PM, Guido van Rossum 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 what was neede
On Mon, 04 Jun 2012 19:36:52 +0200, Antoine Pitrou wrote:
> Le 03/06/2012 06:01, Benjamin Peterson a écrit :
> > 2012/6/2:
> >> results for d9b7399d9e45 on branch "default"
> >>
> >>
> >> test_smtplib leaked [154, 154, 154] references, sum=462
> >
> >
> 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: Alex
On Mon, Jun 4, 2012 at 11:46 AM, Alexander Belopolsky
wrote:
> On Mon, Jun 4, 2012 at 1:12 PM, Guido van Rossum 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 conf
On Mon, Jun 4, 2012 at 1:12 PM, Guido van Rossum 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 different
> sides of
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
wrote:
> On M
On Mon, Jun 4, 2012 at 1:12 PM, Guido van Rossum 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 that someone wh
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 a
Le 03/06/2012 06:01, Benjamin Peterson a écrit :
2012/6/2:
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 3:3 -uall test_smt
On Mon, Jun 4, 2012 at 8:51 AM, Barry Warsaw 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, pract
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
signatu
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 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 conv
On Mon, Jun 4, 2012 at 11:10 AM, Barry Warsaw 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 P
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 reS
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" ->
[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
wrote:
> http://hg.python.org/cpython/rev/9c445f4695c1
> changeset: 77339:9c445f4695c1
> parent: 77328:0808cb8c60fd
> user:Barry Warsaw
> date:Sun Jun
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 i
On Mon, Jun 4, 2012 at 10:18 PM, Dirkjan Ochtman 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.
> Personally, I would
On Mon, Jun 4, 2012 at 2:11 PM, Nick Coghlan 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" here? The te
On Mon, Jun 4, 2012 at 9:19 PM, Dirkjan Ochtman 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 like a fairly
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 shou
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
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
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
48 matches
Mail list logo
