Mailman 3 December 2001 - Python-Dev

RE: [Python-Dev] Those import related syntax errors again...
by Samuele Pedroni Feb. 23, 2005

Feb. 23, 2005

Hi. [Mark Hammond] > The point isn't about my suffering as such. The point is more that > python-dev owns a tiny amount of the code out there, and I don't believe we > should put Python's users through this. > > Sure - I would be happy to "upgrade" all the win32all code, no problem. I > am also happy to live in the bleeding edge and take some pain that will > cause. > > The issue is simply the user base, and giving Python a reputation of not > being able to … [View More]painlessly upgrade even dot revisions. I agree with all this. [As I imagined explicit syntax did not catch up and would require lot of discussions.] [GvR] > > Another way is to use special rules > > (similar to those for class defs), e.g. having > > > > <frag> > > y=3 > > def f(): > > exec "y=2" > > def g(): > > return y > > return g() > > > > print f() > > </frag> > > > > # print 3. > > > > Is that confusing for users? maybe they will more naturally expect 2 > > as outcome (given nested scopes). > > This seems the best compromise to me. It will lead to the least > broken code, because this is the behavior that we had before nested > scopes! It is also quite easy to implement given the current > implementation, I believe. > > Maybe we could introduce a warning rather than an error for this > situation though, because even if this behavior is clearly documented, > it will still be confusing to some, so it is better if we outlaw it in > some future version. > Yes this can be easy to implement but more confusing situations can arise: <frag> y=3 def f(): y=9 exec "y=2" def g(): return y return y,g() print f() </frag> What should this print? the situation leads not to a canonical solution as class def scopes. or <frag> def f(): from foo import * def g(): return y return g() print f() </frag> [Mark Hammond] > > This probably won't be a very popular suggestion, but how about pulling > > nested scopes (I assume they are at the root of the problem) > > until this can be solved cleanly? > > Agreed. While I think nested scopes are kinda cool, I have lived without > them, and really without missing them, for years. At the moment the cure > appears worse then the symptoms in at least a few cases. If nothing else, > it compromises the elegant simplicity of Python that drew me here in the > first place! > > Assuming that people really _do_ want this feature, IMO the bar should be > raised so there are _zero_ backward compatibility issues. I don't say anything about pulling nested scopes (I don't think my opinion can change things in this respect) but I should insist that without explicit syntax IMO raising the bar has a too high impl cost (both performance and complexity) or creates confusion. [Andrew Kuchling] > >Assuming that people really _do_ want this feature, IMO the bar should be > >raised so there are _zero_ backward compatibility issues. > > Even at the cost of additional implementation complexity? At the cost > of having to learn "scopes are nested, unless you do these two things > in which case they're not"? > > Let's not waffle. If nested scopes are worth doing, they're worth > breaking code. Either leave exec and from..import illegal, or back > out nested scopes, or think of some better solution, but let's not > introduce complicated backward compatibility hacks. IMO breaking code would be ok if we issue warnings today and implement nested scopes issuing errors tomorrow. But this is simply a statement about principles and raised impression. IMO import * in an inner scope should end up being an error, not sure about 'exec's. We will need a final BDFL statement. regards, Samuele Pedroni. [View Less]

18 78

Re: [XML-SIG] printing Unicode xml to StringIO
by Martin v. Loewis Jan. 6, 2002

Jan. 6, 2002

[Over to python-dev. Jaco noticed that writing Unicode objects to a StringIO object stopped working in 2.2, see http://mail.python.org/pipermail/xml-sig/2001-December/006891.html ] Marc-Andre writes > Actually, I think that this is a bug in the documentation, not the > code. StringIO and cStringIO were never meant to work on anything but > strings and memory buffers. IMO, "strings" should include both byte strings and Unicode strings. Mixing them may not be allowed, but that is a … [View More]

3 8

Offline for a while
by Jack Jansen Dec. 31, 2001

Dec. 31, 2001

Folks, I will probably be unreacable by mail for the next few days, the backup we put in for our move seems to be non-functional. So don't worry about bounceds to the oratrix.nl address, all should be well again on wednseday or thusrday (and backspace also doesn't work on this machine:-) Jack

1 0

[development doc updates]
by Fred L. Drake Dec. 27, 2001

Dec. 27, 2001

The development version of the documentation has been updated: http://python.sourceforge.net/devel-docs/ A variety of updates made since Python 2.2 was released.

1 0

[development doc updates]
by Fred L. Drake Dec. 27, 2001

Dec. 27, 2001

The development version of the documentation has been updated: http://python.sourceforge.net/maint-docs/ The "maintenance version" of the Python documentation on the Python development site at SourceForge has been updated to show the docs being developed for Python 2.2.1.

1 0

Documentation for Python 2.2.1
by Fred L. Drake, Jr. Dec. 27, 2001

Dec. 27, 2001

I've brought the docs in Python's release22-maint branch up to date with the corrections that have been made on the trunk. I'll be checking in relevant additions to this branch as well as the trunk when I make the trunk changes. When anyone else makes a change on the trunk which should also be made on the 2.2 maintenance branch, feel free to check it in in both places, or add a note to the checkin message noting that it should be made on the branch as well, and I'll try to make sure that … [View More]

1 0

Re: [Python-Dev] Python 2.2.1
by Jack Jansen Dec. 26, 2001

Dec. 26, 2001

Recently, "Fred L. Drake, Jr." <fdrake(a)acm.org> said: > > Has anything been done to get the release22-maint branch to see the > changes made for MacPython yet? We should do this before we lose > track of it. > Jack, any preference for how this is done, or did you already do it? They haven\t been checked in yet. There was a snag in the Mac distriubution that has just been solved, the checkins will follow shortly. -- Jack Jansen | ++++ stop the execution … [View More]

2 1

Re: [Python-Dev] Python 2.2.1
by Anthony Baxter Dec. 26, 2001

Dec. 26, 2001

>>> Jack Jansen wrote > - The final bits of the Mac tree havne't been checked in yet, should > we move the release22-maint branch when that's done? Can you move a > branch? How? D'oh! Hm, I'm not sure how easily that can be done. In theory you should be able to "cvs tag -d release22-maint" in the Mac-specific subdirectory, then do the checkins, then "cvs tag -b release22-maint" in the Mac directory again. So long as there's not been any checkins on the branch in the … [View More]

2 1

Re: [Python-Dev] Python 2.2.1
by Jack Jansen Dec. 25, 2001

Dec. 25, 2001

Two questions wrt 2.2.1: - Is there a timeline for it? I couldn't find one in PEP251 (which stops at 2.2 final). The reason I ask is that there's a serious flaw in MacPython (has been there since day one) that renders it useless on multiprocessor Mac OS X machines. I'm waiting for an external party to fix this (as the problem is in an external library), but I could put a bit of pressure on if 2.2.1 is due reasonably soon (as I hope). - The final bits of the Mac tree havne't been checked in … [View More]

4 4

Re: [Python-Dev] Python 2.2.1
by Anthony Baxter Dec. 23, 2001

Dec. 23, 2001

>>> Michael Hudson wrote > I've just spent half an hour fiddling with gnus to the point that it > should be easy for me to keep a log of checkins that should be put on > the release22-maint branch. > > This isn't me volunteering to be Patch Czar, by the way... I don't > know if I'll have time for that, but I hope that doing this will help > whoever it ends up being. I'm happy enough to continue doing this - now that it's starting from a caught-up position, it's … [View More]

1 0

Re: [Python-Dev] Python 2.2.1
by Michael Hudson Dec. 23, 2001

Dec. 23, 2001

"Fred L. Drake, Jr." <fdrake(a)acm.org> writes: > I've created the branch release22-maint as the Python 2.2 > maintenance branch. > We don't yet have a Patch Czar for 2.2.1, though. I've just spent half an hour fiddling with gnus to the point that it should be easy for me to keep a log of checkins that should be put on the release22-maint branch. This isn't me volunteering to be Patch Czar, by the way... I don't know if I'll have time for that, but I hope that doing this … [View More]

1 0

2.1.2rc is ready to go.
by Anthony Baxter Dec. 23, 2001

Dec. 23, 2001

the 2.1.2 is ready for release candidate - I've yet to go through the hoops to cut the rc1, but please please feel free to pull the CVS version and try it out. Anthony.

2 1

Re: [Python-Dev] RELEASED - Python 2.2 final
by Michael Hudson Dec. 21, 2001

Dec. 21, 2001

Guido van Rossum <guido(a)python.org> writes: > On December 21, just in time to be placed under the Christmas tree, > we're issuing the final release of Python 2.2. Hurrah! > http://sf.net/project/shownotes.php?release_id=?????? Oops. Cheers, M. -- ARTHUR: Why should a rock hum? FORD: Maybe it feels good about being a rock. -- The Hitch-Hikers Guide to the Galaxy, Episode 8

2 1

Python 2.2.1
by Fred L. Drake, Jr. Dec. 21, 2001

Dec. 21, 2001

I've created the branch release22-maint as the Python 2.2 maintenance branch. We don't yet have a Patch Czar for 2.2.1, though. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation

1 0

RELEASED - Python 2.2 final
by Guido van Rossum Dec. 21, 2001

Dec. 21, 2001

On December 21, just in time to be placed under the Christmas tree, we're issuing the final release of Python 2.2. We're proud of this release, and expect that you'll like it. Please check it out here: http://www.python.org/2.2/ Our thanks to everyone who helped test Python 2.2 during the alpha, beta and release candidate phases, and to everyone who contributed patches, feedback, and suggestions! Please continue to report any bugs you find to the bug tracker: http://sourceforge.… [View More]net/bugs/?group_id=5470 Highlights of what's new for this release are outlined below. For a more complete list, please see: http://sf.net/project/shownotes.php?release_id=?????? What's new since 2.1 -------------------- In brief (for PEPs, see http://www.python.org/peps/): - type/class unification (PEP 252 and 253) - iterators (PEP 234) and generators (PEP 255) - nested scopes standard (PEP 227) - int overflows return longs (PEP 237) - new operator // to future-proof int division (PEP 238) Andrew Kuchling has written a gentle introduction to the most important changes, titled "What's New in Python 2.2": http://www.amk.ca/python/2.2/ A thorough introduction to the type/class unification is at: http://www.python.org/2.2/descrintro.html Status of the type/class unification ------------------------------------ With a set of changes as large as this, it's unavoidable that after the release we'll find that there are certain things that would work better if we did them a little differently. Also, it is clear that some of the new features (e.g. class and static methods, properties, super, and slots, to mention a few) could use additional syntactic sugar to make their use easier and more intuitive. This will almost certainly require us to make changes in future releases. However, with the release of these features as part of the Python 2.2 release, we are committed to the same standard of release-to-release compatibility that we have used in the past, as explained in PEP 5. When we feel the need to change things, we'll use the PEP system to propose changes, and we'll provide warnings and backwards compatiblity for at least a year -- or more in cases where a year is deemed too short by the user community. In the meantime, we'll work on completing the documentation for these features (both in Python and in the C API) as they are found in Python 2.2. This documentation will clarify the status of individual features. What's new since 2.2c1 ---------------------- (Adapted from the Misc/NEWS file.) Type/class unification and new-style classes - pickle.py, cPickle: allow pickling instances of new-style classes with a custom metaclass. Core and builtins - weakref proxy object: when comparing, unwrap both arguments if both are proxies. Extension modules - binascii.b2a_base64(): fix a potential buffer overrun when encoding very short strings. - cPickle: the obscure "fast" mode caused stack overflows on the Mac. We fixed this by setting the recursion limit much smaller. If the limit is too low (it only affects performance), you can change it by defining PY_CPICKLE_FAST_LIMIT when compiling cPickle.c (or in pyconfig.h). Library - dumbdbm.py: fixed a dumb old bug (the file didn't get synched at close or delete time). - rfc822.py: fixed a bug where the address '<>' was converted to None instead of an empty string (also fixes the email.Utils module). - xmlrpclib.py: version 1.0.0; uses precision for doubles. - test suite: the pickle and cPickle tests were not executing any code when run from the standard regresssion test. Windows - distutils package: fixed broken Windows installers (bdist_wininst). - tempfile.py: prevent mysterious warnings when TemporaryFileWrapper instances are deleted at process exit time. - socket.py: prevent mysterious warnings when socket instances are deleted at process exit time. - posixmodule.c: fix a Windows crash with stat() of a filename ending in backslash. Mac - The Carbon toolbox modules have been upgraded to Universal Headers 3.4, and experimental CoreGraphics and CarbonEvents modules have been added. All only for framework-enabled MacOSX. --Guido van Rossum (home page: http://www.python.org/~guido/) [View Less]

2 1

ActiveState & Python
by David Ascher Dec. 21, 2001

Dec. 21, 2001

As Mark mentioned in his email to python-dev, he is no longer employed by ActiveState. While I'm dealing with my grief about that unfortunate event in private, I think it's worth clarifying a few things in public: 1) Over the last two years, Mark has become my personal god of programming. ActiveState as a whole has benefited tremendously from having Mark on staff, I have learned a tremendous amount from him, and the entire ActiveState team hope to be able to bring him back on board as soon … [View More]

1 0

Can we checkin on the main trunk?
by Skip Montanaro Dec. 21, 2001

Dec. 21, 2001

I have a trivial change for asynchat to shut up pychecker: /usr/local/lib/python2.2/asynchat.py:83: Local variable (why) not used /usr/local/lib/python2.2/asynchat.py:217: Local variable (why) not used (delete the "why" variable in both cases). Can I check in on the main trunk and have it go into 2.3 without disturbing the 2.2 release? I'm never sure during these alpha/beta/release candidate situations what is and isn't allowed (other than that Barry's new branch is clearly off-… [View More]

4 3

2.1.2 status.
by Anthony Baxter Dec. 20, 2001

Dec. 20, 2001

I'm churning through the list of "things that I want to get fixed" for 2.1.2. I've had to abandon my initial plan of examining pretty much all patches for suitability - the backlog since 2.1.1 is just too huge. If there's something you know of that you think really should be in there, and you're not sure if it is actually there yet, please let me know ASAP! Anthony.

1 0

2.2 "What's New" article finished
by akuchlin＠mems-exchange.org Dec. 20, 2001

Dec. 20, 2001

I've made a few last updates and called it complete for 2.2final. (Bug reports and suggestions are still welcome, though.) Note for the PythonLabs gang: if you want to make a copy on python.org or zope.com (for press release purposes, consistent page design, or whatever), feel free to do so; the LaTeX source is in the pyhowto CVS tree at sourceforge.net. Oh, yeah, the URL: still http://www.amk.ca/python/2.2/ . --amk (www.amk.ca) The Sony … [View More]

1 0

For Jack Jansen
by Tim Peters Dec. 20, 2001

Dec. 20, 2001

Mail to you from me bounces, Jack: Reporting-MTA: dns; femail4.home.com Arrival-Date: Thu, 20 Dec 2001 18:43:54 -0800 Received-From-MTA: dns; CJ569191B (65.1.136.53) Final-Recipient: RFC822; <jack(a)cwi.nl> Action: failed Status: 5.1.1 Remote-MTA: dns; hera.cwi.nl (192.16.191.8) Diagnostic-Code: smtp; 550 <tim.one(a)home.com>... Blocked relay femail4.sdc1.sfba.home.com I'm not sure CWI wants to cut off the 4 million remaining @Home customers via one dumb spam trick -- although … [View More]

1 0

test_cpickle failing in MacPython - ideas needed
by Jack Jansen Dec. 20, 2001

Dec. 20, 2001

Folks, test_cpickle suddenly started failing (often with a hang) in MacPython (CVS tree, main branch). As I'm going to be offline all day tomorrow and I'd like to get MacPython out the door simultaneously with unix and windows-Python: does anyone know what could have changed over the last couple of days to cause this? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack … [View More]

2 1

Python 2.2 final - release branch created
by barry＠zope.com Dec. 20, 2001

Dec. 20, 2001

I've created the Python 2.2 final release branch. The CVS tag is different than with the alpha and beta release branches. Here, it is called `release22-branch'. There's also a tag `release22-fork' -- that's the point on the trunk where the branch forks off. So far the only change in the branch is the version number. As usual, no one except Guido and myself (or our authorized bots) should make checkins to the branch. Checkins to the trunk and branch are discouraged unless they fix … [View More]

1 0

No longer at ActiveState.
by Mark Hammond Dec. 20, 2001

Dec. 20, 2001

FYI, I am no longer emplyed by ActiveState (Merry Christmas! :) ActiveState have pretty much stopped all Komodo and Python work for the forseeable future. This left me without an immediate project and therefore without an immediate job. It was very dissapointing to hear this just after slaving to get the 1.2 release of Komodo out the door and just a few days before Christmas. So, please don't use my ActiveState.com email address. Further, I will probably be moving back to being self-… [View More]

5 6

test coverage
by Neal Norwitz Dec. 19, 2001

Dec. 19, 2001

I've been doing a bunch of testing using the regression tests and have tried to improve the test coverage. I've made some progress. Overall, the regression tests do a pretty good job. Below are all the functions that are not currently covered by the regression tests in Objects/ Parser/ and Python/ (Modules/ has too many at this point). This list may not be perfect, but should be pretty close (some tests failed: test_new, test_funcattrs, and test_symtable). I don't know how many of these … [View More]can be reached from within the python (interpreter), some may only be callable from C code which embeds python. After improving test coverage, I'll go back and run purify to see if there are any new memory leaks. Sorry, the list is kinda long. Let me know if there's a better way to distribute this info. Neal -- Objects/abstract.c PyObject_CallMethodObjArgs PyObject_CallFunctionObjArgs PyObject_Type PyObject_Length PyObject_AsWriteBuffer PyNumber_InPlaceTrueDivide PySequence_Length PySequence_In PySequence_InPlaceConcat PySequence_InPlaceRepeat PyMapping_Length PyMapping_HasKeyString PyMapping_HasKey PyMapping_GetItemString PyMapping_SetItemString null_error sliceobj_from_intint objargs_mktuple Objects/bufferobject.c PyBuffer_FromReadWriteObject PyBuffer_FromReadWriteMemory PyBuffer_New buffer_compare buffer_getwritebuf Objects/cellobject.c cell_compare cell_repr Objects/classobject.c instance_ass_item PyMethod_Function PyMethod_Self PyMethod_Class set_slot set_attr_slots set_dict set_bases set_name instancemethod_hash Objects/cobject.c PyCObject_FromVoidPtrAndDesc PyCObject_GetDesc PyCObject_Import Objects/complexobject.c PyComplex_FromDoubles complex_print complex_div Objects/descrobject.c member_repr getset_repr wrapper_repr method_get_doc wrapper_get_doc proxy_len proxy_has_key proxy_get proxy_values proxy_items proxy_copy proxy_getiter proxy_str proxy_traverse wrapper_name Objects/dictobject.c PyDict_Values PyDict_Items dictiter_next Objects/fileobject.c PyFile_FromString PyFile_Name Objects/floatobject.c PyFloat_AsString PyFloat_AsStringEx float_print Objects/funcobject.c PyFunction_GetCode PyFunction_GetGlobals PyFunction_GetDefaults PyFunction_GetClosure PyClassMethod_New func_set_code func_set_defaults Objects/iterobject.c iter_traverse iter_next calliter_traverse calliter_next Objects/listobject.c list_print immutable_list_op immutable_list_ass Objects/longobject.c PyLong_AsVoidPtr Objects/methodobject.c listmethodchain PyCFunction_GetFunction PyCFunction_GetSelf PyCFunction_GetFlags meth_traverse meth_get__self__ meth_compare Objects/object.c _PyObject_Dump PyObject_Not PyObject_Malloc PyObject_Realloc PyObject_Free none_dealloc NotImplemented_repr Objects/rangeobject.c range_compare range_slice range_tolist range_getattr Objects/sliceobject.c PySlice_GetIndices slice_compare Objects/stringobject.c _Py_ReleaseInternedStrings PyString_Decode PyString_Encode PyString_AsEncodedString PyString_AsDecodedString string_getbuffer string_buffer_getwritebuf Objects/structseq.c structseq_repr structseq_concat structseq_repeat structseq_contains structseq_hash Objects/tupleobject.c tupleprint Objects/typeobject.c slot_nb_coerce type_set_module type_subclasses wrap_binaryfunc_r wrap_coercefunc wrap_ternaryfunc_r wrap_sq_delitem wrap_delslice wrap_delitem wrap_hashfunc slot_sq_length slot_sq_ass_item slot_tp_iter slot_tp_iternext super_repr Objects/unicodeobject.c PyUnicodeUCS2_Replace PyUnicodeUCS2_AsUnicode PyUnicodeUCS2_GetSize PyUnicodeUCS2_FromWideChar PyUnicodeUCS2_AsWideChar PyUnicodeUCS2_SetDefaultEncoding PyUnicodeUCS2_Encode PyUnicodeUCS2_AsUTF16String PyUnicodeUCS2_AsUnicodeEscapeString PyUnicodeUCS2_AsRawUnicodeEscapeString PyUnicodeUCS2_AsCharmapString PyUnicodeUCS2_Translate PyUnicodeUCS2_Tailmatch PyUnicodeUCS2_Find utf8_decoding_error utf16_decoding_error latin1_encoding_error charmap_encoding_error unicode_index unicode_rindex unicode_buffer_getreadbuf unicode_buffer_getwritebuf Objects/weakrefobject.c PyWeakref_GetObject gc_clear weakref_repr proxy_print proxy_repr proxy_compare proxy_nonzero proxy_slice proxy_ass_slice proxy_contains proxy_length proxy_setitem Parser/bitset.c _Py_delbitset Parser/grammar1.c PyGrammar_LabelRepr Parser/listnode.c list1node PyNode_ListTree listnode Parser/myreadline.c PyOS_StdioReadline PyOS_Readline my_fgets Parser/parsetok.c PyParser_ParseString Parser/pgen.c dumpstate dumpnfa printssdfa Parser/pgenmain.c PySys_WriteStderr Py_FatalError PyOS_Readline Parser/tokenizer.c indenterror Python/ceval.c call_exc_trace PyEval_CallObject Py_SetRecursionLimit Py_GetRecursionLimit PyEval_AcquireLock PyEval_ReleaseThread loop_subscript gen_traverse gen_next Python/codecs.c PyCodec_StreamReader PyCodec_StreamWriter build_stream_codec Python/compile.c PyCode_Addr2Line PyNode_CompileSymtable code_repr do_pad dump Python/errors.c PyErr_WriteUnraisable PyErr_BadArgument PyErr_NoMemory PyErr_BadInternalCall _PyErr_BadInternalCall Python/frozenmain.c Py_FrozenMain Python/getargs.c PyArg_VaParse Python/import.c PyImport_ExtendInittab PyImport_ExecCodeModule PyImport_AppendInittab get_frozen_object imp_init_builtin imp_init_frozen imp_get_frozen_object imp_is_builtin imp_is_frozen imp_load_compiled imp_load_dynamic imp_load_module imp_load_package Python/marshal.c PyMarshal_ReadShortFromFile PyMarshal_ReadObjectFromFile w_more marshal_dump marshal_load Python/modsupport.c PyEval_CallFunction _ustrlen Python/pyfpe.c PyFPE_dummy Python/pystate.c PyInterpreterState_Head PyInterpreterState_Next PyInterpreterState_ThreadHead PyThreadState_Next Python/pythonrun.c Py_NewInterpreter PyRun_InteractiveLoopFlags PyRun_InteractiveOneFlags parse_syntax_error print_error_text PyErr_Display Py_FatalError Py_SetPythonHome Py_EndInterpreter PyRun_AnyFile PyRun_AnyFileEx PyRun_AnyFileFlags PyRun_SimpleString PyRun_SimpleStringFlags PyRun_SimpleFile PyRun_SimpleFileEx PyRun_InteractiveOne PyRun_InteractiveLoop PyRun_File PyRun_FileFlags Py_CompileString Py_SymtableString PyErr_Print Py_AtExit run_pyc_file add_flag Python/structmember.c PyMember_Set listmembers Python/symtable.c ste_repr Python/sysmodule.c mywrite PySys_WriteStdout PySys_WriteStderr PySys_GetFile PySys_AddWarnOption sys_excepthook sys_getdefaultencoding sys_setdefaultencoding sys_setcheckinterval sys_setrecursionlimit sys_getrecursionlimit sys_setdlopenflags sys_getdlopenflags Python/thread.c PyThread_allocate_sema PyThread_free_sema PyThread_down_sema PyThread_up_sema PyThread__exit_thread Python/traceback.c tb_displayline PyTraceBack_Print tb_clear tb_printinternal [View Less]

2 1

RE: [Numpy-discussion] Python 2.2
by Paul F. Dubois Dec. 19, 2001

Dec. 19, 2001

I downloaded and installed 2.2c1 and built the Numeric installers. However, when I run them they all fail when the installation begins (after one clicks the final click to install) with an access violation. I removed any previous Numeric and it still happened. Building and installing with setup.py install works ok. -----Original Message----- From: numpy-discussion-admin(a)lists.sourceforge.net [mailto:numpy-discussion-admin@lists.sourceforge.net] On Behalf Of Ray Drew Sent: Monday, December … [View More]

6 9