Michael Urman wrote:
> The idea that slicing a match object should produce a match object
> sounds like a foolish consistency to me.
well, the idea that adding m[x] as a convenience alias for m.group(x)
automatically turns m into a list-style sequence that also has to
support full slicing sound
[Tim Peters]
>> Sorry, I couldn't follow the intent there. Not obvious to me how
>> moving this stuff from `threading` into `thread` would make it
>> easier(?) for the implementation to wait for non-daemon threads to
>> finish.
[Martin v. Löwis]
> Currently, if you create a thread through the thr
Tim Peters schrieb:
> Sorry, I couldn't follow the intent there. Not obvious to me how
> moving this stuff from `threading` into `thread` would make it
> easier(?) for the implementation to wait for non-daemon threads to
> finish.
Currently, if you create a thread through the thread module
(rathe
[Martin v. Löwis]
>>> Upon investigation, it turns out that the file descriptor
>>> is closed because the logging atexit handler is invoked.
>>> This is surprising, as the program is far from exiting at
>>> this point.
[Tim Peters]
>> But the main thread is done, right?
[Martin]
> Wrong. main.py
Patch / Bug Summary
___
Patches : 413 open ( +6) / 3489 closed ( +5) / 3902 total (+11)
Bugs: 943 open ( +7) / 6364 closed ( +1) / 7307 total ( +8)
RFE : 246 open ( +0) / 244 closed ( +0) / 490 total ( +0)
New / Reopened Patches
__
popen() s
"Michael Urman" <[EMAIL PROTECTED]> wrote:
> On 12/6/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > *We* may not be confused, but it's not about us (I'm personally happy to
> > use the .group() interface); it's about relative newbies who, generally
> > speaking, desire/need consistency (see [1]
Alastair Houghton <[EMAIL PROTECTED]> wrote:
> On 7 Dec 2006, at 01:01, Josiah Carlson wrote:
> > *We* may not be confused, but it's not about us (I'm personally
> > happy to
> > use the .group() interface); it's about relative newbies who,
> > generally
> > speaking, desire/need consistency (
On 12/6/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> *We* may not be confused, but it's not about us (I'm personally happy to
> use the .group() interface); it's about relative newbies who, generally
> speaking, desire/need consistency (see [1] for a paper showing that
> certain kinds of inconsi
On 7 Dec 2006, at 01:01, Josiah Carlson wrote:
> *We* may not be confused, but it's not about us (I'm personally
> happy to
> use the .group() interface); it's about relative newbies who,
> generally
> speaking, desire/need consistency (see [1] for a paper showing that
> certain kinds of incon
On 7 Dec 2006, at 00:39, Mike Klaas wrote:
> Keep in mind when implementing that m[3:4] should contain only the
> element at index 3, not both 3 and 4, as you've seemed to imply twice.
Yes, you're quite right. I was writing off the top of my head and
I'm still a relative newbie to Python codi
Alastair Houghton <[EMAIL PROTECTED]> wrote:
> On 6 Dec 2006, at 20:29, Josiah Carlson wrote:
>
> > The problem is that either we return a list (easy), or we return
> > something that is basically another match object (not quite so easy).
> > Either way, we would be confusing one set of users or
On 12/6/06, Alastair Houghton <[EMAIL PROTECTED]> wrote:
[from previous message]:
>> Anyway, clearly what people will expect here (talking about the match
>> object API) is that m[3:4] would give them a list (or some equivalent
>> sequence object) containing groups 3 and 4. Why do you think someo
On 6 Dec 2006, at 20:29, Josiah Carlson wrote:
> The problem is that either we return a list (easy), or we return
> something that is basically another match object (not quite so easy).
> Either way, we would be confusing one set of users or another. By not
> including slicing functionality by de
Alastair Houghton <[EMAIL PROTECTED]> wrote:
> On 5 Dec 2006, at 15:51, Fredrik Lundh wrote:
> > Alastair Houghton wrote:
> >> or
> >>
> >>m[3:4]
> >>
> >> fail to do what they expect.
> >
> > the problem with slicing is that people may 1) expect a slice to
> > return
> > a new object *of th
On 5 Dec 2006, at 15:51, Fredrik Lundh wrote:
> Alastair Houghton wrote:
>
>> What's more, I think it will be confusing for Python newbies because
>> they'll see someone doing
>>
>>m[3]
>>
>> and assume that m is a list-like object, then complain when things
>> like
>>
>>for match in m:
Greg Ewing schrieb:
> Could backwards compatibility concerns be addressed
> by including more than one version of Python in
> the LSB? Python already allows multiple versions
> to coexist, so applications targeting the LSB
> would just need to be explicit about which version
> of the interpreter to
Tim Peters schrieb:
>> Upon investigation, it turns out that the file descriptor
>> is closed because the logging atexit handler is invoked.
>> This is surprising, as the program is far from exiting at
>> this point.
>
> But the main thread is done, right?
Wrong. main.py (which is the __main__ sc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Dec 6, 2006, at 9:15 AM, Michael Urman wrote:
>> I don't have anything older than 2.4 laying around either, but IIRC
>> in 2.3 unicode() did not call __unicode__().
>
> It turns out __unicode__() is called on Python 2.3.5.
Ah cool, thanks. I must
> I don't have anything older than 2.4 laying around either, but IIRC
> in 2.3 unicode() did not call __unicode__().
It turns out __unicode__() is called on Python 2.3.5.
% python2.3
Python 2.3.5 (#2, Oct 18 2006, 23:04:45)
[GCC 4.1.2 20061015 (prerelease) (Debian 4.1.1-16.1)] on linux2
Type "hel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Dec 6, 2006, at 7:07 AM, Nick Coghlan wrote:
> M.-A. Lemburg wrote:
>> On 2006-12-06 10:26, Fredrik Lundh wrote:
>>> From what I can tell, __str__ may return a Unicode object, but
>>> only if can be converted to an 8-bit string using the default
Fredrik Lundh wrote:
> the problem with slicing is that people may 1) expect a slice to return
> a new object *of the same type* (which opens up a *gigantic* can of
> worms, both on the implementation level and on the wtf-is-this-thing-
> really level), and 2) expect things like [::-1] to work, w
M.-A. Lemburg wrote:
> On 2006-12-06 10:26, Fredrik Lundh wrote:
>> From what I can tell, __str__ may return a Unicode object, but
>> only if can be converted to an 8-bit string using the default encoding. Is
>> this
>> on purpose or by accident? Do we have a plan for improving the situation
>>
On 2006-12-06 10:56, Fredrik Lundh wrote:
> M.-A. Lemburg wrote:
>
>> This was added to make the transition to all Unicode in 3k easier:
>
> thanks for the clarification.
>
> do you recall when this was added? 2.5?
Not really, only that it was definitely before 2.5.
--
Marc-Andre Lemburg
eGe
M.-A. Lemburg wrote:
> This was added to make the transition to all Unicode in 3k easier:
thanks for the clarification.
do you recall when this was added? 2.5?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/list
On 2006-12-06 10:46, M.-A. Lemburg wrote:
> On 2006-12-06 10:26, Fredrik Lundh wrote:
>> over at my work copy of the python language reference, Adrian Holovaty
>> asked about the exact semantics of the __str__ hook:
>>
>> http://effbot.org/pyref/__str__
>>
>>"The return value must be a stri
On 2006-12-06 10:26, Fredrik Lundh wrote:
> over at my work copy of the python language reference, Adrian Holovaty
> asked about the exact semantics of the __str__ hook:
>
> http://effbot.org/pyref/__str__
>
>"The return value must be a string object." Does this mean it can be a
>*Uni
over at my work copy of the python language reference, Adrian Holovaty
asked about the exact semantics of the __str__ hook:
http://effbot.org/pyref/__str__
"The return value must be a string object." Does this mean it can be a
*Unicode* string object? This distinction is ambiguous to me
[Martin v. Löwis]
> In bug #1566280 somebody reported that he gets an
> exception where the logging module tries to write
> to closed file descriptor.
>
> Upon investigation, it turns out that the file descriptor
> is closed because the logging atexit handler is invoked.
> This is surprising, as th
28 matches
Mail list logo
