Re: [Python-Dev] How long the wrong type of argument should we limit (or not) in the error message (C-api)?
Being that python is, to me, a prototyping language, then every possible outcome should be presented to the end user. A full variety of explanations should be presented to the programmer. On Fri, Dec 13, 2013 at 11:56 PM, Vajrasky Kok wrote: > Greetings, > > When fixing/adding error message for wrong type of argument in C code, > I am always confused, how long the wrong type is the ideal? > > The type of error message that I am talking about: > > "Blabla() argument 1 must be integer not wrong_type". > > We have inconsistency in CPython code, for example: > > Python/sysmodule.c > === > PyErr_Format(PyExc_TypeError, > "can't intern %.400s", s->ob_type->tp_name); > > Modules/_json.c > > PyErr_Format(PyExc_TypeError, > "first argument must be a string, not %.80s", > Py_TYPE(pystr)->tp_name); > > > Objects/typeobject.c > === > PyErr_Format(PyExc_TypeError, > "can only assign string to %s.__name__, not '%s'", > type->tp_name, Py_TYPE(value)->tp_name); > > So is it %.400s or %.80s or %s? I vote for %s. > > Other thing is which one is more preferable? Py_TYPE(value)->tp_name > or value->ob_type->tp_name? I vote for Py_TYPE(value)->tp_name. > > Or this is just a matter of taste? > > Thank you. > > Vajrasky Kok > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/dwightdhutto%40gmail.com > -- Best Regards, David Hutto *CEO:* *http://www.hitwebdevelopment.com <http://www.hitwebdevelopment.com>* ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How long the wrong type of argument should we limit (or not) in the error message (C-api)?
Susskinds...Me too, but the refinement of the error messages is the point. We should be looking at the full assessment of the error, which the prototyping of python should present. I've seen others reply that python wouldn't be around, or that theree are other forms I've seen before that will take the forefront. The point should be to align the prototyping of python with the updates in technology taking place. It should be like it usually is, line for lineerror assessments, even followed by further info to inform the prototyper that is looking to translate to a lower level language. On Sat, Dec 14, 2013 at 4:07 PM, Greg Ewing wrote: > David Hutto wrote: > >> Being that python is, to me, a prototyping language, then every possible >> outcome should be presented to the end user. >> > > So we should produce a quantum superposition of > error messages? :-) > > (Sorry, I've been watching Susskind's lectures on > QM and I've got quantum on the brain at the moment.) > > -- > Greg > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ > dwightdhutto%40gmail.com > -- Best Regards, David Hutto *CEO:* *http://www.hitwebdevelopment.com <http://www.hitwebdevelopment.com>* ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How long the wrong type of argument should we limit (or not) in the error message (C-api)?
We all strive to be python programmers, and some of the responses are that it might not be around in the future. Now we all probably speak conversational in other langs, but I'm thinking of keeping around a great prototyping language. So the topic becomes how too integrate it with the not just the expected, but the unexpected technologiesDespite the topic is error messages, it should apply to all possibilities that could be derived from a prototyping language like python. On Sat, Dec 14, 2013 at 11:09 PM, David Hutto wrote: > Susskinds...Me too, but the refinement of the error messages is the point. > We should be looking at the full assessment of the error, which the > prototyping of python should present. > > I've seen others reply that python wouldn't be around, or that theree are > other forms I've seen before that will take the forefront. > > The point should be to align the prototyping of python with the updates in > technology taking place. > > It should be like it usually is, line for lineerror assessments, even > followed by further info to inform the prototyper that is looking to > translate to a lower level language. > > > On Sat, Dec 14, 2013 at 4:07 PM, Greg Ewing > wrote: > >> David Hutto wrote: >> >>> Being that python is, to me, a prototyping language, then every possible >>> outcome should be presented to the end user. >>> >> >> So we should produce a quantum superposition of >> error messages? :-) >> >> (Sorry, I've been watching Susskind's lectures on >> QM and I've got quantum on the brain at the moment.) >> >> -- >> Greg >> >> ___ >> Python-Dev mailing list >> Python-Dev@python.org >> https://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: https://mail.python.org/mailman/options/python-dev/ >> dwightdhutto%40gmail.com >> > > > > -- > Best Regards, > David Hutto > *CEO:* *http://www.hitwebdevelopment.com > <http://www.hitwebdevelopment.com>* > -- Best Regards, David Hutto *CEO:* *http://www.hitwebdevelopment.com <http://www.hitwebdevelopment.com>* ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Building a Faster Python
Just a suggestion from working with an assembly language stepper from a while back with Intel x86...lost to an HD crash, but couldn't you disassemble the binary, run through the assembly, and look for specific instructions that you could refine into a simpler, smaller cycling time to improve upon with a stepper that counts cycles? I've seen other assembly steppers after I started mine for electrical engineering of PCB's, but I don't know if they're counting cycles, and suggesting other actions in an editor typ/optimization mode that the compiler might miss. On Mon, Jul 22, 2013 at 12:09 PM, Ronald Oussoren wrote: > > On 22 Jul, 2013, at 17:08, David Malcolm wrote: > > > On Mon, 2013-07-22 at 09:32 +0200, Maciej Fijalkowski wrote: > >> On Mon, Jul 22, 2013 at 9:32 AM, Maciej Fijalkowski > wrote: > >>> On Mon, Jul 22, 2013 at 8:15 AM, Antoine Pitrou > wrote: > >>>> On Sun, 21 Jul 2013 16:36:35 -0700 > >>>> Raymond Hettinger wrote: > >>>>> Our current Mac OS X builds use GCC-4.2. > >>>>> > >>>>> On Python2.7, I ran a comparison of gcc-4.2.1 builds > >>>>> versus gcc-4.8.1 and found that the latter makes a much > >>>>> faster Python. PyBench2.0 shows the total running time > >>>>> dropping from 5653ms to 4571ms. The code is uniformly > >>>>> better in just about every category. > >>>> > >>>> You could try running the benchmarks suite to see what that gives: > >>>> http://hg.python.org/benchmarks/ > >>>> > >>>> Regards > >>>> > >>>> Antoine. > >>> > >>> or pypy benchmark suite which is more comprehensive for python 2.7 > >>> (http://bitbucket.org/pypy/benchmarks) > >> > >> Besides, is there any reason not to use clang by default on OS X? > > > > How did this thread go from: > > "for OS X, GCC 4.8.1 gives you significantly faster machine code > > than the system GCC 4.2.1" > > to > > "let's just use clang" > > ? > > Because we use the system compiler for building the official binary > packages. > > I'm not looking forward to bootstrapping GCC multiple times[*] just to be > able > to build a slightly faster python. And more so because you have to be very > careful when using a alternative compiler when building the installer, it > is > very easy to end up with a build that others cannot use to build extension > because they don't have /Users/ronald/Tools/Compiler/gcc-4.8/bin/gcc. > > > > > (I should declare that I've been hacking on GCC for the last few months, > > so I have an interest in this) > > It would still be interesting to know which compiler would generate the > fastest code for CPython. Apple tends to claim that clang generates better > code than GCC, buit AFAIK they compare the latest clang with the latest > version of GCC that they used to ship, which is ancient by now. > > Ronald > > [*] multiple times due to fat binaries. > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/dwightdhutto%40gmail.com > -- Best Regards, David Hutto *CEO:* *http://www.hitwebdevelopment.com* ___ Python-Dev mailing list Python-Dev@python.org 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 3 as a Default in Linux Distros
Haven't been over to yum land in a while, but usually they stabilize the distro in synergy to the python version. Ubuntu came with 2.7, and I just use sudo-apt get install, for 3.2(or a gui package manager), and then can use 3.2 with using the command python3.2 in command line, or you can compile from source with a newer python not available with your distro's package manager/repository. It's really up to your distro's base linux, and python version decided on top of a specific distro they define as compatible with the distros system. On Wed, Jul 24, 2013 at 9:54 AM, Lennart Regebro wrote: > On Wed, Jul 24, 2013 at 11:12 AM, Bohuslav Kabrda > wrote: > > - Should we point /usr/bin/python to Python 3 when we make the move? > > No. > > > - What should user get after using "yum install python"? > > Will a base install include Python 3? If it does, I think yum install > python should mean python3, and hence already be installed. > > //Lennart > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/dwightdhutto%40gmail.com > -- Best Regards, David Hutto *CEO:* *http://www.hitwebdevelopment.com* ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
