Nick Coghlan schrieb:
> So this is taking something that *already works properly on POSIX
> systems* and making it work on Windows as well.
I doubt it does without side effects. For example, an application that
would go through sys.path, and encode everything with
sys.getfilesystemencoding() curre
On 9/7/06, Neal Norwitz <[EMAIL PROTECTED]> wrote:
On 9/5/06, Brett Cannon <[EMAIL PROTECTED]> wrote:>> > [MAL]> > The proper fix would be to introduce a tp_unicode slot and let> > this decide what to do, ie. call .__unicode__() methods on instances
> > and use the .__name__ on classes.>> That was
I was hoping to have stopped, but here are a few comments.
I agree with Jan Kanis. That is the way to tackle this one.
"Adam Olsen" <[EMAIL PROTECTED]> wrote:
>
> I don't think we should let this die, at least not yet. Nick seems to
> be arguing that ANY signal handler is prone to rand
On 9/9/06, Jan Kanis <[EMAIL PROTECTED]> wrote:
> At the risk of waking up a thread that was already declared dead, but
> perhaps this is usefull.
>
> So, what happens is pythons signal handler sets a flag and registrers a
> callback. Then the main thread should check the flag and make the callback
On 9/9/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> On 9/8/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > Ensuring modifications to that array are atomic would be tricky, but I
> > think it would be doable if we use a read-copy-update approach (with
> > two alternating signal handler functions). Not
On 9/9/06, Nick Maclaren <[EMAIL PROTECTED]> wrote:
> I was hoping to have stopped, but here are a few comments.
>
> I agree with Jan Kanis. That is the way to tackle this one.
Alas, it doesn't work in practice, as I already replied.
[...]
> Despite the implication, the code of Py_AddPendingCa
Martin v. Löwis wrote:
> Nick Coghlan schrieb:
>
>>So this is taking something that *already works properly on POSIX
>>systems* and making it work on Windows as well.
>
>
> I doubt it does without side effects. For example, an application that
> would go through sys.path, and encode everything w
On Sat, 09 Sep 2006 12:59:23 +0200, Gustavo Carneiro
<[EMAIL PROTECTED]> wrote:
> On 9/9/06, Jan Kanis <[EMAIL PROTECTED]> wrote:
>> However, PyGTKs problem does get
>> solved, as long as there is _a_ thread that returns to the interpreter
>> within some timeframe. It seems plausible that this w
Martin v. Löwis wrote:
> Nick Coghlan schrieb:
>
>>So this is taking something that *already works properly on POSIX
>>systems* and making it work on Windows as well.
>
> I doubt it does without side effects. For example, an application that
> would go through sys.path, and encode everything with
David Hopwood schrieb:
>> I doubt it does without side effects. For example, an application that
>> would go through sys.path, and encode everything with
>> sys.getfilesystemencoding() currently works, but will break if the patch
>> is applied and non-mbcs strings are put on sys.path.
>
> Huh? It
David Hopwood wrote:
> Martin v. Löwis wrote:
>> Nick Coghlan schrieb:
>>
>>> So this is taking something that *already works properly on POSIX
>>> systems* and making it work on Windows as well.
>> I doubt it does without side effects. For example, an application that
>> would go through sys.path,
Nick Coghlan schrieb:
> I think MvL is looking at it from the point of view of consumers of the list
> of strings in sys.path, such as PEP 302 importer and loader objects, and
> tools
> like module_finder. Currently, the list of values in sys.path is limited to:
That, and all kinds of inspectio
Barry Warsaw schrieb:
> Thoughts? I don't want to waste my time if nobody thinks a 2.3.6 would
> be useful, but I'm happy to do it if there's community support. I'll
> also need the usual help with Windows installers and documentation updates.
I personally would consider it a waste of time. Sinc
Nick Coghlan wrote:
> David Hopwood wrote:
>> Martin v. Löwis wrote:
>>> Nick Coghlan schrieb:
>>>
So this is taking something that *already works properly on POSIX
systems* and making it work on Windows as well.
>>>
>>> I doubt it does without side effects. For example, an application th
David Hopwood schrieb:
> On Windows, file system pathnames can contain arbitrary Unicode characters
> (well, almost). Despite the existence of "ANSI" filesystem APIs, and
> regardless of what 'sys.getfilesystemencoding()' returns, the underlying
> file system encoding for NTFS and FAT filesystems i
On Sep 9, 2006, at 2:10 PM, Martin v. Löwis wrote:
> Barry Warsaw schrieb:
>> Thoughts? I don't want to waste my time if nobody thinks a 2.3.6
>> would
>> be useful, but I'm happy to do it if there's community support. I'll
>> also need the usual help with Windows installers and documentation
Martin v. Löwis wrote:
> David Hopwood schrieb:
>
>>On Windows, file system pathnames can contain arbitrary Unicode characters
>>(well, almost). Despite the existence of "ANSI" filesystem APIs, and
>>regardless of what 'sys.getfilesystemencoding()' returns, the underlying
>>file system encoding fo
David Hopwood schrieb:
> Elements of sys.path can be Unicode strings in Python 2.5, and should be
> pathnames supported by the underlying OS. Where is it documented that there
> is any further restriction on them? And why should there be any further
> restriction on them?
It's not documented in th
Barry Warsaw <[EMAIL PROTECTED]> wrote:
> Well, there certainly hasn't been an overwhelming chorus of support
> for the idea, so I think I'll waste my time elsewhere ;). Consider
> the offer withdrawn.
I hope someone tries to fix one of the two bugs I listed that were
problems for 2.3 and 2.
David Hopwood wrote:
> Martin v. Löwis wrote:
>> Programs that rely on sys.getfilesystemencoding() being able to
>> represent arbitrary file names on Windows might have a bug;
>> programs that rely on sys.getfilesystemencoding() being able
>> to encode all elements of sys.path do not (at least not
20 matches
Mail list logo
