Re: [Python-Dev] Last-minute curses patch
Walter Dörwald wrote: > Martin v. Löwis wrote: >> It does need a configure test, though. > > Unfortunately I have no idea how this whole configure business works! I got bored. I posted a comment to the bug, which will direct you to http://scottdial.com/python-dev/curses-resizeterm.diff -- Scott Dial [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.4 extensions require VC 7.1?
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. I don't recall the discussion vividly, but I think the reasoning was something like "because it still works." Maybe I remember wrong, but this is not a compelling argument en lieu of it being hard to get a hold of the toolkit. If there is some kind of legwork involved with getting python moved to VS2005, then I'll volunteer.. Despite the possibility illegality of the posting of the toolkit, I suggest curious people to google for '"Index Of" VCToolkitSetup.exe', if need be. -- Scott Dial [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.4 extensions require VC 7.1?
Fredrik Lundh 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 (see comp.lang.python), > and it's still available for MSDN subscribers. It's also easy to get a used copy on ebay. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.4 extensions require VC 7.1?
Scott Dial wrote: > I don't recall the discussion vividly, but I think the reasoning was > something like "because it still works." Maybe I remember wrong, but > this is not a compelling argument en lieu of it being hard to get a hold > of the toolkit. If there is some kind of legwork involved with getting > python moved to VS2005, then I'll volunteer.. There were several reasons: it's the same compiler that was used to compile Python 2.4, so authors of Python extension modules typically already have a copy. Switching to VS 2005 would require people to get that first, and it would require people to have three releases of VC installed just to build modules for Python 2.3, 2.4, and 2.5. Another reason is that I consider VS 2005 buggy, I hope that some of the breakage that Microsoft has done to the C library is reverted in a future release. VS2005 managed to break compatibility with C89 and C99 in a way that made Python fail to start up, also, it was possible to have the CRT abort just by calling the builtin open with the wrong arguments. There is now a work-around for that breakage, but still, I don't trust that VS 2005 is a good product. I'm hoping that Python can skip VS 2005 entirely, and go straight to VS 2007 (or whatever it will be called) for 2.6. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Improve error msgs?
Georg Brandl wrote:
> In abstract.c, there are many error messages like
>
> type_error("object does not support item assignment");
>
> It helps debugging if the object's type was prepended.
> Should I go through the code and try to enhance them
> where possible?
So that's definite "perhaps"?
Anyway, posted patch 1507676.
Georg
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unicode imports
Kristján V. Jónsson wrote: > The standard install path in chinese distributions can be with a > non-ANSI path, and installing an embedded python application there will > break it. I very much doubt this. On a Chinese system, the Program Files folder likely has a non-*ASCII* name, but it will have a fine *ANSI* name, as the ANSI code page on that system should be either 936 (simplified chinese) or 950 (traditional chinese) - unless the system is misconfigured. Can you please report what the path is, what the precise name of the operating system is, and what the system locale and the system code page are? > A completely parallel implementation on the sys.path[i] level? You should also take a look at what the 8.3 name of the path is. I really cannot believe that the path is unaccessible to DOS programs. > Are there other platforms beside Windows that would profit from this? No. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unicode imports
Neil Hodgson wrote: >It should be unusual for a Chinese installation to use an install > path that can not be represented in MBCS. Try encoding the install > directory into MBCS before adding it to sys.path. Indeed. Unfortunately, people apparently install an English version (because they can get that without paying any license fee), and then create directory names that can't be represented in the ANSI code page (which would then be 1252). Still, on such a system, the target folder for programs should be "Program Files". If people do that, they *should* change the system locale to some Chinese locale, but being non-admin people, they often don't. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Last-minute curses patch
Scott Dial sagte: > Walter Dörwald wrote: >> Martin v. Löwis wrote: >>> It does need a configure test, though. >> >> Unfortunately I have no idea how this whole configure business works! > > I got bored. I posted a comment to the bug, which will direct you to > http://scottdial.com/python-dev/curses-resizeterm.diff Thanks for the patch! I'm not sure if is_term_resized() can return ERR or not. Can't comment on the configure logic. Neal, can this still go in? Servus, Walter ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Beta 1 schedule ? (Bug in stringobject?)
Neal Norwitz wrote: > 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/pep-0356/ > > beta 1 won't be released until the tests pass consistently. That > hasn't happened much this week. I updated the PEP's schedule. > Hopefully we can release early next week. This means the code freeze > is likely to happen as early as Sunday (more likely Monday or > Tuesday). > > http://mail.python.org/pipermail/python-checkins/2006-June/054104.html > >> I'd also like to get the new winerror module in before >> beta1 is released - documentation will follow next week: >> >> https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1505257&group_id=5470 >> >> >> Is it OK to first check in a pure Python version and then >> replace this with a C implementation having the same interface >> later on in the beta cycle ? > > My answer is no. Is that no to adding the winerror Python module or no to replacing it with a C module later on in the beta cycle ? Note that winerror is a new module, so it can't really break anything. > We've had too much breakage. There are so many > things already in 2.5. We really don't need one more thing to break. > There will be a 2.6. winerror has limited impact. At this point, I'd > rather not see any checkins except to fix something that's broken. > tests, doc, and bugfixes. I seem to recall a bunch of checkins > recently that didn't have a test. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 17 2006) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2006-07-03: EuroPython 2006, CERN, Switzerland 15 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] An obscene computed goto bytecode hack for "switch" :)
Hi Phillip, On Fri, Jun 16, 2006 at 10:01:05PM -0400, Phillip J. Eby wrote: > One thing I'm curious about, if there are any PyPy folks listening: will > tricks like this drive PyPy or Psyco insane? :) Yes, both :-) The reason is that the details of the stack behavior of END_FINALLY are messy in CPython. The finally blocks are the only place where the depth of the stack is not known in advance: depending on how the finally block is entered, there will be between one and three objects pushed (a single None, or an int and another object, or an exception type, instance and traceback). Psyco cheats here and emulates a behavior where there is always exactly one object instead (which can be a tuple), so if a END_FINALLY sees values not put there in the "official" way it will just crash. PyPy works similarily but always expect three values. (Hum, Psyco could easily be fixed to support your use case... For PyPy it would be harder without performance hit) A bientot, Armin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Last-minute curses patch
Walter Dörwald wrote: > I'm not sure if is_term_resized() can return ERR or not. Oh whoops, you are of course correct. I have corrected the diff accordingly. -- Scott Dial [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.4 extensions require VC 7.1?
I remember you voicing this point at the Texas sprint. I can't say I agree. The behaviour of certain function (like signal and fopen) is undefined for certain arguments. Undefined is undefined, exiting the program with an admonition is one of the possible outcomes (as is formatting your hard drive.) In my opinion this is to be considered "a good thing" since it helps us adhere to the "defined" parts of the standards and not rely on something which is utterly unknown or unpredictable by the standards (but which happens to work on some platforms, no thanks to the standards.) Besides, we only found this an issue in three places: signal(), fopen() and strftime() functions. Not a huge thing to fix. Apart from these things, I must say that in my experience VC2005 is an surprisingly stable product. The whole program (link-step) optimization is a boon, and if combined with profile guided optimization (PGO), works wonders. VS2005 also can create binaries for the X64 windows platform, no small point, and the primary reason we started using it in the first place. I encourage people to look at the PCBuild8 directory in the current python trunk. Especially I would like suggestions and comments on how to better automate the PGO build process Cheers, Kristján -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of "Martin v. Löwis" Sent: 17. júní 2006 08:26 To: Scott Dial Cc: Python Dev Subject: Re: [Python-Dev] Python 2.4 extensions require VC 7.1? Another reason is that I consider VS 2005 buggy, I hope that some of the breakage that Microsoft has done to the C library is reverted in a future release. VS2005 managed to break compatibility with C89 and C99 in a way that made Python fail to start up, also, it was possible to have the CRT abort just by calling the builtin open with the wrong arguments. There is now a work-around for that breakage, but still, I don't trust that VS 2005 is a good product. I'm hoping that Python can skip VS 2005 entirely, and go straight to VS 2007 (or whatever it will be called) for 2.6. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.4 extensions require VC 7.1?
Kristján V. Jónsson wrote: > I remember you voicing this point at the Texas sprint. I can't say I > agree. The behaviour of certain function (like signal and fopen) is > undefined for certain arguments. Undefined is undefined, exiting the > program with an admonition is one of the possible outcomes (as is > formatting your hard drive.) For fopen(3), you are right. For signal(3), VS2005 is in clear violation with ISO C, which specifies in 7.14.1.1 [#8] If the request can be honored, the signal function returns the value of func for the most recent successful call to signal for the specified signal sig. Otherwise, a value of SIG_ERR is returned and a positive value is stored in errno. The set of acceptable signals is deliberately implementation-defined, and it is consequential that an attempt to set an unsupported signal gives an error (ISO C cannot specify that the error is EINVAL, since EINVAL is not part of ISO C). > In my opinion this is to be considered "a good thing" since it helps > us adhere to the "defined" parts of the standards and not rely on > something which is utterly unknown or unpredictable by the standards > (but which happens to work on some platforms, no thanks to the > standards.) Besides, we only found this an issue in three places: > signal(), fopen() and strftime() functions. Not a huge thing to fix. For fopen and strftime, they could have achieved the same effect with just setting errno to EINVAL. The C runtime library just should never ever terminate the program unless explicitly asked to, just as Python should never ever terminate execution without giving the application a chance to intervene (e.g. by catching an exception). > VS2005 also can create binaries for the X64 windows platform, no > small point, and the primary reason we started using it in the first > place. OTOH, you don't *need* VS2005 to create AMD64 binaries. I had been creating Itanium binaries for several years now with VS2003, and started producing AMD64 binaries for Python 2.5. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.4 extensions require VC 7.1?
Martin v. Löwis wrote:
> For fopen(3), you are right. For signal(3), VS2005 is in clear
> violation with ISO C
I'm nobody but I don't find your argument compelling. I suggest you go
read: http://msdn2.microsoft.com/en-us/library/ksazx244.aspx
In short, you can tell the CRT to do whatever you like when the
parameters are invalid, including returning EINVAL.
void VS2005_CRT_invalidParamHandler(const wchar_t* expression,
const wchar_t* function,
const wchar_t* file,
unsigned int line,
uintptr_t pReserved)
) { errno = EINVAL; }
int main() {
// Disable VS2005's parameter checking aborts
_set_invalid_parameter_handler(VS2005_CRT_invalidParamHandler);
// Disable message box assertions
_CrtSetReportMode(_CRT_ASSERT, 0);
...
}
I went back and read more of the older discussion. And I think your
position is that you just don't want to force another compiler on
people, but aren't developers used to this? And if the Express Edition
(free version) is the target, there is no monetary reason to avoid the
upgrade. And as others have said, a VS2005 version of python is faster.
For reference, http://msdn2.microsoft.com/en-us/library/ms235497.aspx
contains the list of CRT breakages according to MSFT.
--
Scott Dial
[EMAIL PROTECTED]
[EMAIL PROTECTED]
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.4 extensions require VC 7.1?
Scott Dial wrote: >> For fopen(3), you are right. For signal(3), VS2005 is in clear >> violation with ISO C > > I'm nobody but I don't find your argument compelling. I suggest you go > read: http://msdn2.microsoft.com/en-us/library/ksazx244.aspx > > In short, you can tell the CRT to do whatever you like when the > parameters are invalid, including returning EINVAL. Sure, I can *make* the library conform to C 99. I could also write my own C library entirely to achieve that effect. The fact remains that VS 2005 violates standard C where VS 2003 and earlier did not: A conforming program will abort, instead of completing successfully. > I went back and read more of the older discussion. And I think your > position is that you just don't want to force another compiler on > people, That also, yes. > but aren't developers used to this? They can manage, sure, nobody will get injured. However, since somebody will be unhappy no matter what I do, I do what makes most people happy, i.e. no change. Also, I'm really upset by Microsoft's attitude towards their C compiler. They shouldn't have broken the C library like that, and they shouldn't have taken the VS Express 2003 release off the net without any prior warning. > For reference, http://msdn2.microsoft.com/en-us/library/ms235497.aspx > contains the list of CRT breakages according to MSFT. Unfortunately, they don't list the specific breakage that the parameter validation causes. They don't even document the effect of parameter validation on their signal() documentation: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_CRT_signal.asp In any case, I see little chance for a change in the build procedure for Python 2.5. Notice that none of the Python committers have spoken in favour of changing the procedure (and some against). Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.4 extensions require VC 7.1?
One reason for not switching to VC 8, which hasn't yet been explicitly mentioned here, is that MinGW does not yet easily support linking to the msvcr80 runtime library. Some C extension modules, for instance those in SciPy, are primarily developed under Linux with GCC and hence are most easily built on Windows with MinGW. If the official Python distribution was linked to msvcr80.dll, many extension modules probably could not be built "out of the box" on Windows (with MinGW) anymore. The 64bit compiler in VS2005 is pretty handy, though. Regards, Stephan ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unicode imports
On 17-jun-2006, at 6:44, 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 that case is Modules/getpath.c,
>
> Since it has to do with the definition of Py_GetPath as returning a
> single
> string that is really a DELIM separated list of strings, where
> DELIM is
> defined by the current platform (';' on Windows, ':' everywhere
> else), this
> seems more like a platform problem than a Python problem, though -
> you can't
> have directories containing a colon as an entry in PATH or
> PYTHONPATH either.
> It's not really Python's fault that the platform defines a legal
> filename
> character as the delimiter for path entries.
On unix-y systems any character except the NUL byte can be used in a
legal fileystem path, that leaves awfully little characters to use as
delimiter without risking issues like the one in the bug Bob mentioned.
>
> The only real alternative I can see is to normalise Py_GetPath to
> always
> return a ';' delimited list of strings, regardless of platform, and
> update
> PySys_SetPath accordingly. That'd cause potential compatibility
> problems for
> embedded interpreters, though.
That wouldn't help, ';' is also a valid character in filenames on
Unix. Except for accepting the status quo (which is a perfectly fine
alternative) there seem to be two valid ways to solve this problem.
You can either define Py_GetPath2 that returns a python list or
tuple, or introduce some way of quoting the delimiter. Both would be
backward incompatible.
Ronald
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] An obscene computed goto bytecode hack for "switch" :)
At 01:18 PM 6/17/2006 +0200, Armin Rigo wrote: >Psyco cheats here and emulates a behavior where there is >always exactly one object instead (which can be a tuple), so if a >END_FINALLY sees values not put there in the "official" way it will just >crash. PyPy works similarily but always expect three values. > >(Hum, Psyco could easily be fixed to support your use case... For PyPy >it would be harder without performance hit) I suppose if the code knew it was running under PyPy or Psyco, the code could push three items or a tuple? It's the knowing whether that's the case that would be difficult. :) I'm a bit surprised, though, since I thought PyPy was supposed to be an interpreter of CPython bytecode. That is, that it runs unmodified Python bytecode. Or are you guys just changing POP_BLOCK's semantics so it puts two extra None's on the stack when popping a SETUP_FINALLY block? [Looks at the code] Ah, yes. But you're not emulating the control mechanism. I see why you're saying it would be harder without a performance hit. I could change the bytecode so it would work under PyPy as far as stack levels go, but I'd need to also be able to put wrapped unrollers on the stack (which seems impossible from within the interpreter), or else PyPy would have to check whether the unroller is an integer. I guess it would probably make better sense to have a JUMP_TOP operation to implement the switch statement, and to use that under PyPy, keeping the hack only for implementing jump tables in older Python versions. Anyway, if I do use this for older Python versions, would you accept a patch for Psyco to support it? That would let us have JIT-compiled predicate dispatch for older Pythons, which sounds rather exciting. :) The current version of RuleDispatch is an interpreter that follows a tree data structure, but I am working on a new package, PEAK-Rules, that is planned to be able to translate dispatch trees directly into bytecode, thus removing one level of interpretation. I do have some other questions, but I suppose this is getting off-topic for python-dev now, so I'll jump over to psyco-devel once I've gotten a bit further along. Right now, I've only just got BytecodeAssembler up to building simple expression trees, and the "computed goto" demo. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Allow Empty Subscript List Without Parentheses
Hello, 2006/6/16, Josiah Carlson <[EMAIL PROTECTED]>: > I'm not a mathematician, and I don't really work with arrays of any > dimensionality, so the need for 0-D subscripting via arr[] while being > cute, isn't compelling to my uses for Python. Thanks for appreciating its cuteness... > > Now, I appreciate the desire to reduce code length and complexity, but > from what I understand, the ultimate result of such a change to your > code would be to go from: > arr[()] > to: > arr[] > > I don't see how this can reduce lines of code in implementation or use. > At most it is a two characters per use, and a change in documentation > (specifying how you subscript 0-D arrays). If you can show an example > where actual code line count is reduced with this change, I can't > guarantee that I would get behind this proposal in a few months (if the > conversation starts up again), but it may make me feel less that your > proposal is essentially about aesthetics. I meant the extra code for writing a special class to handle scalars, if I decide that the "x[()]" syntax is too ugly or too hard to type, so I write a special class which will allow the syntax "x.value". The extra parentheses might not seem to matter for code using that library, but I intend for people to use it directly, in an interactive way, just like you type an expression in a spreadsheet. I expect that for such a usage, the extra parentheses will be slightly unfun. I know that it's not such a big difference, but I'm not talking about a big change to the language either - it affects less than 20 lines of code (probably could be done with even less), and doesn't cause any problems with anything. I can imagine Guido designing the grammar, thinking, "Should I allow an empty subscript list? No, why should anyone want such a thing? Besides, if someone wants them, we can always add them later." - at least, it may be how I would think if I designed a language. So now, a use was found. Indeed, it is farely rare. But why not to allow it now? Have a good week, Noam ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Allow Empty Subscript List Without Parentheses
Noam Raphael wrote: > I meant the extra code for writing a special class to handle scalars, > if I decide that the "x[()]" syntax is too ugly or too hard to type, > so I write a special class which will allow the syntax "x.value". What I cannot understand is why you use a zero-dimensional array to represent a scalar. Scalars are directly supported in Python: x = 5 Also, in an assignment, what are you putting on the right-hand side? A read access from another zero-dimensional array? I think this feature is so esoteric that it would actually hurt the language to have it. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.4 extensions require VC 7.1?
On Sat, Jun 17, 2006 at 03:27:36PM +0200, "Martin v. L?wis" wrote: > Scott Dial wrote: > >> For fopen(3), you are right. For signal(3), VS2005 is in clear > >> violation with ISO C > > > > I'm nobody but I don't find your argument compelling. I suggest you go > > read: http://msdn2.microsoft.com/en-us/library/ksazx244.aspx > > > > In short, you can tell the CRT to do whatever you like when the > > parameters are invalid, including returning EINVAL. > > Sure, I can *make* the library conform to C 99. I could also write > my own C library entirely to achieve that effect. The fact remains > that VS 2005 violates standard C where VS 2003 and earlier did not: > A conforming program will abort, instead of completing successfully. A note from the sidelines on this: Don't assume microsoft is ever going to "fix" their compilers. C and modern C standards are not an important to them. MS is large enough that they can choose not to conform or break from the standards and you'll just have to live with it. MS uses C++ and C# for everything internally so they have little internal incentive. > > I went back and read more of the older discussion. And I think your > > position is that you just don't want to force another compiler on > > people, > > That also, yes. > > > but aren't developers used to this? > > They can manage, sure, nobody will get injured. However, since somebody > will be unhappy no matter what I do, I do what makes most people happy, > i.e. no change. > > Also, I'm really upset by Microsoft's attitude towards their C compiler. > They shouldn't have broken the C library like that, and they shouldn't > have taken the VS Express 2003 release off the net without any prior > warning. Agreed. Regardless, I don't see this as something that the world being pissed off at them can control. There are other C compilers for Windows if you don't want to be at their mercy. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.4 extensions require VC 7.1?
Op za, 17-06-2006 te 10:25 +0200, schreef "Martin v. Löwis": > Another reason is that I consider VS 2005 buggy, I hope that some > of the breakage that Microsoft has done to the C library is reverted > in a future release. VS2005 managed to break compatibility with > C89 and C99 in a way that made Python fail to start up, also, it > was possible to have the CRT abort just by calling the builtin open > with the wrong arguments. There is now a work-around for that breakage, > but still, I don't trust that VS 2005 is a good product. Why should a C++ compiler be able to compile C89 and/or C99 code? -- Jan Claeys ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.4 extensions require VC 7.1?
Jan Claeys wrote: > Op za, 17-06-2006 te 10:25 +0200, schreef "Martin v. Löwis": >> Another reason is that I consider VS 2005 buggy, I hope that some >> of the breakage that Microsoft has done to the C library is reverted >> in a future release. VS2005 managed to break compatibility with >> C89 and C99 in a way that made Python fail to start up, also, it >> was possible to have the CRT abort just by calling the builtin open >> with the wrong arguments. There is now a work-around for that breakage, >> but still, I don't trust that VS 2005 is a good product. > > Why should a C++ compiler be able to compile C89 and/or C99 code? It shouldn't. It appears you think VC 7.1 is a C++ compiler only; that is not the case. It also offers support for (some sort of) C. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Allow Empty Subscript List Without Parentheses
2006/6/17, "Martin v. Löwis" <[EMAIL PROTECTED]>: > Noam Raphael wrote: > > I meant the extra code for writing a special class to handle scalars, > > if I decide that the "x[()]" syntax is too ugly or too hard to type, > > so I write a special class which will allow the syntax "x.value". > > What I cannot understand is why you use a zero-dimensional array to > represent a scalar. Scalars are directly supported in Python: > > x = 5 I need a zero-dimensional array as a single cell - an object that holds a value that can change over time. It works just like a cell in a spreadsheet: For example, say that if you change the value of cell A1 to 0.18, cell A2 changes to 5. When using the library I design, you would write "sheet1[0, 0] = 0.18", and, magically, "sheet1[0, 1]" will become 5. But in my library, everything is meaningful and doesn't have to be two-dimensional. So, if in the spreadsheet example, A1 meant the income tax rate, you would write "income_tax[] = 0.18", and, magically, "profit['Jerusalem', 2005]" will become 5. I hope I managed to explain myself - my use case and why the simplest way to treat scalars like income_tax is as zero-dimensional arrays. > Also, in an assignment, what are you putting on the right-hand side? > A read access from another zero-dimensional array? > I hope my example explained that, but you can put there any object - for example, you can write "income_tax[] = 0.18" (If I didn't yet manage to explain myself, please say so - it seems that it's not a very simple example and I'm not a very good explainer, at least in English.) Noam ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Allow Empty Subscript List Without Parentheses
Hi, sorry for my repeated posts. I just wanted to say that I improved my patch a little bit, so it does exactly the same thing, but with smaller code: you can see for yourself at http://python.pastebin.com/715221 - it changed exactly 10 lines of code, and adds additional 8 lines, all of them really short and obvious. I thought that it might convince someone that it's just a little generalization of syntax, nothing frightening... Noam 2006/6/17, Noam Raphael <[EMAIL PROTECTED]>: > I know that it's not such a big difference, but I'm not talking about > a big change to the language either - it affects less than 20 lines of > code (probably could be done with even less), and doesn't cause any > problems with anything. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Allow Empty Subscript List Without Parentheses
Martin v. Löwis wrote: > Noam Raphael wrote: > >>I meant the extra code for writing a special class to handle scalars, >>if I decide that the "x[()]" syntax is too ugly or too hard to type, >>so I write a special class which will allow the syntax "x.value". > > > What I cannot understand is why you use a zero-dimensional array to > represent a scalar. Scalars are directly supported in Python: > > x = 5 > > Also, in an assignment, what are you putting on the right-hand side? > A read access from another zero-dimensional array? Ok, so in order to clear up the confusion here, I am going to take a moment to try and explain Noam's proposal in clearer language. Note that I have no opinions about the merits of the proposal itself; However, the lack of understanding here bothers me :) The motivation, as I understand it, is one of mathematical consistency. Let's take a moment and think about arrays in terms of geometry. We all learned in school that 3 dimensions defines a volume, 2 dimensions defines a plane, 1 dimension defines a line, and 0 dimensions defines a point. Moreover, each N-dimensional entity can be converted to one of lower order by setting one of its dimensions to 0. So a volume with one dimension set to zero becomes a plane, and so on. Now think about this with respect to arrays. A 3-dimensional array can be converted into a 2-dimensional array by setting one of its dimensions to 1. So a 5 x 5 array is equivalent to a 5 x 5 x 1 array. Similarly, a 3-dimensional array can be converted into a 1-dimensional array by setting two of its dimensions to 1: So an array of length 5 is equivalent to a 5 x 1 x 1 array. We see, then, a general rule that a N-dimensional array can be reduced to M dimensions by setting (N-M) of its dimensions to 1. So by this rule, if we reduce a 3d array to zero dimensions, we would have an array that has one element: 1 x 1 x 1. Similarly, each time we reduce the dimension by 1, we also reduce the number of indices needed to access the elements of the array. So a 3-d array requires 3 coordinates, a 2-d array requires 2 coordinates, and so on. It should be noted that this zero-dimensional array is not exactly a normal scalar. It is a scalar in the sense that it has no dimensions, but it is still an array in the sense that it is contains a value which is distinct from the array itself. The zero-dimensional array is still a container of other values, however it can only hold one value. This is different from a normal scalar, which is simply a value, and not a container. Now, as to the specifics of Noam's problem: Apparently what he is trying to do is what many other people have done, which is to use Python as a base for some other high-level language, building on top of Python syntax and using the various operator overloads to define the semantics of the language. However, what he's discovering is that there are cases where his syntactical requirements and the syntactical rules of Python don't match. Now, typically when this occurs, the person who is creating the language knows that there is a rationale for why that particular syntax makes sense in their language. What they often do in this case is to try and convince the Python community that this rationale also applies to Python in addition to their own made-up language. This is especially the case when the proposed change gives meaning to what would formerly have been an error. (I sometime suspect that the guiding design principle of Perl is that all possible permutations of ASCII input characters should eventually be assigned some syntactically valid meaning.) Historically, I can say that such efforts are almost always rebuffed - while Python may be good at being a base for other languages, this is not one of the primary design goals of the language as I understand it. My advice to people in this situation is to consider that perhaps some level of translation between their syntax and Python syntax may be in order. It would not be hard for the interactive interpreter to convert instances of [] into [()], for example. -- Talin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Allow Empty Subscript List Without Parentheses
On Sun, Jun 18, 2006, Noam Raphael wrote: > > Hi, sorry for my repeated posts. I just wanted to say that I improved > my patch a little bit, so it does exactly the same thing, but with > smaller code: you can see for yourself at > http://python.pastebin.com/715221 - it changed exactly 10 lines of > code, and adds additional 8 lines, all of them really short and > obvious. > > I thought that it might convince someone that it's just a little > generalization of syntax, nothing frightening... Not really. After reading this thread, my opinion is that you have a relatively narrow corner case and should find another way to get what you want. -1 -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "I saw `cout' being shifted "Hello world" times to the left and stopped right there." --Steve Gonedes ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Beta 1 schedule ? (Bug in stringobject?)
On Saturday 17 June 2006 07:06, M.-A. Lemburg wrote: > 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 sprint left out that case. > > > > what's the beta 1 status ? fixing this should be trivial, but I > > don't have any cycles to spare today. I just confirmed that Martin and Fred are ready to do this on Tuesday. We slipped a couple of days because of pretty bad builbot breakage. > I'd also like to get the new winerror module in before > beta1 is released - documentation will follow next week: Hm. A new python module should be OK - but I was under the impression that then large piles of the standard library would be updated to use this new module. I'm less happy (much less) about this happening for 2.5. > Is it OK to first check in a pure Python version and then > replace this with a C implementation having the same interface > later on in the beta cycle ? How big is it likely to be? How much of a pain will it be to make it work with various versions of Windows? Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bug in stringobject?
On Friday 16 June 2006 23:13, 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 sprint left out that case. > > what's the beta 1 status ? fixing this should be trivial, but I > don't have any cycles to spare today. If you don't get time before the code freeze for beta 1, I don't have a problem with this bug fix going in for beta 2. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] uuid backward compatibility
Python 2.5 ships with uuid.py and now I want to ask you about its backward compatibility. uuid.py says in its docstring: This module works with Python 2.3 or higher. And my question is: Do we plan to make it 2.3 compatible in future releases? If so, uuid needs to be listed in PEP 291. Otherwise, the comment is misleading. Current uuid.py uses ctypes but it checks ctypes availability and I counldn't find no other newly added features, so backward compatibility is still retained. I just want to make sure. Thanks in advance. -- george ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Allow Empty Subscript List Without Parentheses
Talin wrote: > The motivation, as I understand it, is one of mathematical consistency. Noam told me in private email that this is *not* the motivation. Instead, he wants mutable values. This, in turn, he wants so he can catch modifications. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
