On Jun 16, 2006, at 9:44 PM, Nick Coghlan wrote:
> Bob Ippolito wrote:
>> There's a similar issue in that if sys.prefix contains a colon,
>> Python is also busted:
>> http://python.org/sf/1507224
>> Of course, that's not a Windows issue, but it is everywhere else.
>> The offending code in tha
Giovanni Bajo wrote:
> It was discussed before, and the agreement was to use VS 2003 for another
> cycle
> (i.e. 2.5). But the fact that VS 2003 is no longer available for download is
> an
> important fact, and we might want to rediscuss the issue.
it's still available in the .net sdk packages
Bill Janssen <[EMAIL PROTECTED]> wrote:
>> I'm trying to build a Python extension, and Python 2.4 insists on
>> the MS
>> Visual C++ compiler version 7.1, which is included with the MS VC++
>> 2003
>> toolkit. This toolkit is no longer available for download from
>> Microsoft (superseded by the 2
On 6/16/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> Fredrik Lundh wrote:
> >
> > what's the beta 1 status ? fixing this should be trivial, but I don't have
> > any
> > cycles to spare today.
>
> Good question. PEP 356 says beta 1 was planned two days
> ago...
>
> http://www.python.org/dev/peps
Kristján V. Jónsson:
> Although python has had full unicode support for filenames for a long time
> on selected platforms (e.g. Windows), there is one glaring deficiency: It
> cannot import from paths containing unicode. I´ve tried creating folders
> with chinese characters and adding them to pa
Bob Ippolito wrote:
> There's a similar issue in that if sys.prefix contains a colon, Python
> is also busted:
> http://python.org/sf/1507224
>
> Of course, that's not a Windows issue, but it is everywhere else. The
> offending code in that case is Modules/getpath.c,
Since it has to do with the
Phillip J. Eby wrote:
> Actually, you would want to put it in sys.path_hooks, and then instances
> would be placed in path_importer_cache automatically. If you are adding
> it to the path_hooks after the fact, you should simply clear the
> path_importer_cache. Simply poking stuff into the path
I would like to share a couple of observations that I made as I
studied the latest setobject implementation.
1. Is there a reason not to have PySet_CheckExact, given that
PyFrozenSet_CheckExact exists? Similarly, why PyAnySet_Check, but no
PySet_Check or PyFrozenSet_Check?
2. Type of severa
For folks contemplating what opcodes might need to be added to implement a
"switch" statement, it turns out that there is a "clever way" (i.e. a
filthy hack) to implement computed jumps in Python bytecode, using
WHY_CONTINUE and END_FINALLY.
I discovered this rather by accident, while working o
Walter Dörwald wrote:
>> It can go into beta1 until the beta1 code freeze is announced.
>
> Great!
>
>> It does need a configure test, though.
>
> Unfortunately I have no idea how this whole configure business works!
Unfortunately, this either means you have to learn it, or find somebody
who do
Fredrik Lundh wrote:
> M.-A. Lemburg wrote:
>> Since replace() only works on string objects, it appears
>> as if a temporary string object would have to be created.
>> However, this would involve an unnecessary allocation
>> and copy process... it appears as if the refactoring
>> during the NFS spr
There is a related bit of functionality for subprocess that would allow
for asynchronous handling of IO to/from the called subprocess. It has
been implemented as a recipe [1], but requires the use of additional
pywin32 functionality on Windows. As was the case for the original
subprocess module,
On Tue, 13 Jun 2006, Martin Blais wrote:
Hi all. Now let's see if I remember something about my module...
> In the subprocess module, by default the files handles in the child
> are inherited from the parent. To ignore a child's output, I can use
> the stdout or stderr options to send the outpu
A colleague recently posted this message:
> I'm trying to build a Python extension, and Python 2.4 insists on the MS
> Visual C++ compiler version 7.1, which is included with the MS VC++ 2003
> toolkit. This toolkit is no longer available for download from
> Microsoft (superseded by the 2005 vers
On Jun 16, 2006, at 9:02 AM, Phillip J. Eby wrote:
> At 01:29 AM 6/17/2006 +1000, Nick Coghlan wrote:
>> Kristján V. Jónsson wrote:
>>> A cursory glance at import.c shows that the import mechanism is
>>> fairly
>>> complicated, and riddled with "char *path" thingies, and manual
>>> string
>>>
"Noam Raphael" <[EMAIL PROTECTED]> wrote:
>
> 2006/6/16, Gareth McCaughan <[EMAIL PROTECTED]>:
> > None of the above is intended to constitute argument for
> > or against Noam's proposed change to Python. Python isn't
> > primarily a language for mathematicians, and so much the
> > better for Pyt
At 01:29 AM 6/17/2006 +1000, Nick Coghlan wrote:
>Kristján V. Jónsson wrote:
> > A cursory glance at import.c shows that the import mechanism is fairly
> > complicated, and riddled with "char *path" thingies, and manual string
> > arithmetic. Do you have any suggestions on a clean way to unicodify
Kristján V. Jónsson wrote:
> A cursory glance at import.c shows that the import mechanism is fairly
> complicated, and riddled with "char *path" thingies, and manual string
> arithmetic. Do you have any suggestions on a clean way to unicodify the
> import mechanism?
Can you install a PEP 302 p
2006/6/16, Gareth McCaughan <[EMAIL PROTECTED]>:
> None of the above is intended to constitute argument for
> or against Noam's proposed change to Python. Python isn't
> primarily a language for mathematicians, and so much the
> better for Python.
>
Thanks for your explanation of mathematical zero
Hello,
It seems to me that people don't object to my proposal, but don't find
it useful to them either.
The question is, what to do next. I guess one possibility is to raise
this discussion again in a few months, when people will be less
occupied with 2.5 beta. This is ok, although I would prefer
Greetings!
Although python has
had full unicode support for filenames for a long time on selected platforms
(e.g. Windows), there is one glaring deficiency: It cannot import from
paths containing unicode. I´ve tried creating folders with chinese
characters and adding them to path, to no
M.-A. Lemburg wrote:
> Since replace() only works on string objects, it appears
> as if a temporary string object would have to be created.
> However, this would involve an unnecessary allocation
> and copy process... it appears as if the refactoring
> during the NFS sprint left out that case.
wha
Georg Brandl wrote:
> In string_replace, there is
>
> if (PyString_Check(from)) {
> /* Can this be made a '!check' after the Unicode check? */
> }
> #ifdef Py_USING_UNICODE
> if (PyUnicode_Check(from))
> return PyUnicode_Replace((PyObject *)self,
>
In string_replace, there is
if (PyString_Check(from)) {
/* Can this be made a '!check' after the Unicode check? */
}
#ifdef Py_USING_UNICODE
if (PyUnicode_Check(from))
return PyUnicode_Replace((PyObject *)self,
> But only if it makes sense. I still think there are some
> severe conceptual difficulties with 0D arrays. One is
> the question of how many items it contains. With 1 or
> more dimensions, you can talk about its size along any
> chosen dimension. But with 0 dimensions there's no size
> to measure.
Greg Ewing wrote:
> M.-A. Lemburg wrote:
>
>> My personal favorite is making the compiler
>> smarter to detect the mentioned if-elif-else scheme
>> and generate code which uses a lookup table for
>> implementing fast branching.
>
> But then the values need to be actual compile-time
> constants, p
Raymond Hettinger wrote:
>>> The optimisation of the if-elif case would then simply be to say that the
>>> compiler can recognise if-elif chains like the one above where the RHS
>>> of the comparisons are all hashable literals and collapse them to switch
>>> statements.
>>>
>>
>> Right (consta
Martin v. Löwis wrote:
> Walter Dörwald wrote:
>> I have a small patch http://bugs.python.org/1506645 that adds
>> resizeterm() and resize_term() to the curses module. Can this still go
>> in for beta1? I'm not sure, if it needs some additional configure magic.
>
> It can go into beta1 until the b
28 matches
Mail list logo
