Re: [Python-Dev] Inconsistent script/console behaviour
On Sat, Sep 24, 2011 at 11:27 AM, Georg Brandl wrote: > Am 24.09.2011 01:32, schrieb Guido van Rossum: > > On Fri, Sep 23, 2011 at 4:25 PM, anatoly techtonik > wrote: > >> Currently if you work in console and define a function and then > >> immediately call it - it will fail with SyntaxError. > >> For example, copy paste this completely valid Python script into > console: > >> > >> def some(): > >> print "XXX" > >> some() > >> > >> There is an issue for that that was just closed by Eric. However, I'd > >> like to know if there are people here that agree that if you paste a > >> valid Python script into console - it should work without changes. > > > > You can't fix this without completely changing the way the interactive > > console treats blank lines. None that it's not just that a blank line > > is required after a function definition -- you also *can't* have a > > blank line *inside* a function definition. > > While the former could be changed (I think), the latter certainly cannot. > So it's probably not worth changing established behavior. I've just hit this UX bug once more, but now I more prepared. Despite Guido's proposal to move into python-ideas, I continue discussion here, because: 1. It is not a proposal, but a defect (well, you may argue, but please, don't) 2. This thread has a history of analysis of what's going wrong in console 3. This thread also has developer's decision that answers the question "why it's so wrong?" and "why it can't/won't be fixed" 4. Yesterday I've heard from a Java person that Python is hard to pick up and remembered how I struggled with indentation myself trying to 'learn by example' in console Right now I am trying to cope with point (3.). To summarize, let's speak code that is copy/pasted into console. Two things that will make me happy if they behave consistently in console from .py file: ---ex1--- def some(): print "XXX" some() ---/ex1--- --ex1.output-- [ex1.py] XXX [console] File "", line 3 some() ^ SyntaxError: invalid syntax --/ex1.output-- --ex2-- def some(): pass --/ex2-- --ex2.output-- [ex2.py] File "./ex2.py", line 2 pass ^ IndentationError: expected an indented block [console] File "", line 2 pass ^ IndentationError: expected an indented block --/ex2.output-- The second example already works as expected. Why it is not possible to fix ex1? Guido said: > You can't fix this without completely changing the way the interactive > console treats blank lines. But the fix doesn't require changing the way interactive console treats blank lines at all. It only requires to finish current block when a dedented line is encountered and not throwing obviously confusing SyntaxError. At the very least it should not say it is SyntaxError, because the code is pretty valid Python code. If it appears to be invalid "Python Console code" - the error message should say that explicitly. That would be a correct user-friendly fix for this UX issue, but I'd still like the behavior to be fixed - i.e. "allow dedented lines end current block in console without SyntaxError". Right now I don't see the reasons why it is not possible. Please speak code when replying about use cases/examples that will be broken - I didn't quite get the problem with "global scope if" statements. -- anatoly t. ___ 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] Inconsistent script/console behaviour
Il 15 dicembre 2011 09:58, anatoly techtonik ha scritto: > 1. It is not a proposal, but a defect (well, you may argue, but please, > don't)> You can't copy/paste multiline scripts into system shell either, unless you append "\". It's likely that similar problems exists in a lot of other interactive shells (ruby?). And that makes sense to me, because they are supposed to be used interactively. It might be good to change this? Maybe. Is the current behavior objectively wrong? No, in my opinion. --- Giampaolo http://code.google.com/p/pyftpdlib/ http://code.google.com/p/psutil/ ___ 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] Compiling the source without stat
On 12/14/2011 05:04 PM, Hossein wrote: If there is anything I should do You can determine what the code that calls stat() is trying to do, and implement that with other primitives that your platform provides. For example, you can determine whether a file exists by trying to open it in read-only mode and checking the error. You can find whether a filesystem path names a directory by trying to chdir into it and checking the error. You can find the size of a regular file by opening it and seeking to the end. These substitutions would not be acceptable for a desktop system, but may be perfectly adequate for an embedded one that doesn't provide stat() in the first place. Either way, I expect that you will need to modify the sources. Finally, are you 100% sure that your platform doesn't provide another API similar to stat()? ___ 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
[Python-Dev] Proposed changes to provide compression support for rotated log files
In response to http://bugs.python.org/issue13516 I'm thinking of implementing some changes in the rotating file handlers, as outlined here: http://plumberjack.blogspot.com/2011/12/improved-flexibility-for-log-file.html The changes (including tests) are almost ready to check in, but I thought I'd give any one here who's interested a chance to comment, in case they can spot any shortcomings of the approach I suggest. Regards, Vinay Sajip ___ 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] Compiling the source without stat
I wanted to say something in the bug page petri showed ( http://bugs.python.org/issue12082 ) however I though about first discussing it here. If faking a stat struct and a function to fill it solves the problem, and checking for existing files and folders is the only thing that python needs to be compiled (i'm talking about 2.7) then it's possible to fail-check it by just trying to open the file. If you don't want to change the stat mechanism, you can create a new #define which can let user point it to his own faked stat function and struct. I'm currently trying to fake stat to see what happens next, but I guess I will have more problems with file handling later. By the way, some people with the same problem there said they "used" python by setting the Py_DontWriteBytecodeFlag flag, but here my problem is that i can't compile it. Dunno what they really did. ___ 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] Compiling the source without stat
It does have its own file handling functions: Opening, getting the size, enumerating directories, etc. It has its own limitations too. No dates supported, folders only one level deep, maximum 99 files inside each folder, etc. There is not a function called stat. But I am considering faking it, will explain in another reply. ___ 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] Proposed changes to provide compression support for rotated log files
On Thu, 15 Dec 2011 10:31:08 + (UTC) Vinay Sajip wrote: > In response to http://bugs.python.org/issue13516 I'm thinking of implementing > some changes in the rotating file handlers, as outlined here: > > http://plumberjack.blogspot.com/2011/12/improved-flexibility-for-log-file.html > > The changes (including tests) are almost ready to check in, but I thought I'd > give any one here who's interested a chance to comment, in case they can spot > any shortcomings of the approach I suggest. "def filename(self, name)" sounds like a poor method name. Regards Antoine. ___ 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] Compiling the source without stat
Le jeudi 15 décembre 2011 15:29:23 vous avez écrit : > If faking a stat struct and a function to fill it > solves the problem, and checking for existing files and folders is the > only thing that python needs to be compiled (i'm talking about 2.7) then > it's possible to fail-check it by just trying to open the file. It's better to only work on Python 3.3. I consider "support platform without stat" as a new feature, and new features are only accepted in Python 3.3. Victor ___ 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] Proposed changes to provide compression support for rotated log files
On 12/15/2011 5:31 AM, Vinay Sajip wrote: In response to http://bugs.python.org/issue13516 I'm thinking of implementing some changes in the rotating file handlers, as outlined here: http://plumberjack.blogspot.com/2011/12/improved-flexibility-for-log-file.html The changes (including tests) are almost ready to check in, but I thought I'd give any one here who's interested a chance to comment, in case they can spot any shortcomings of the approach I suggest. It appears you are adding two methods to do the same thing. One is to subclass and override one or two functions. The other is to define one or two custom functions and attach as attributes. Both seem equally easy. (Actually, subclassing takes one line less.) Are both really needed? -- Terry Jan Reedy ___ 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] Proposed changes to provide compression support for rotated log files
Antoine Pitrou pitrou.net> writes: > > "def filename(self, name)" sounds like a poor method name. > You're right - perhaps "def rotation_filename(self, default_name)" is better. Regards, Vinay Sajip ___ 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] Proposed changes to provide compression support for rotated log files
Terry Reedy udel.edu> writes: > > It appears you are adding two methods to do the same thing. One is to > subclass and override one or two functions. The other is to define one > or two custom functions and attach as attributes. Both seem equally > easy. (Actually, subclassing takes one line less.) Are both really needed? > That's why I asked for comments. Subclassing can be avoided if the callable attributes are used, which is a win, for example, if you have both timed and non-timed rotating handlers: you can use the same callables in each case, whereas with subclassing you would have to subclass both the timed and non-timed handler classes. Also, in scenarios where one might want to use alternative compression formats based on an application's configuration, there would be less work because one wouldn't need to create multiple subclasses. So for most cases the strategy would be to use the callable attributes, and if they were inappropriate for some reason, they could subclass and override the methods. I've factored out the two methods from the existing implementation because at the moment, it's hard to subclass without copying the whole doRollover method (as in the ActiveState example). Regards, Vinay Sajip ___ 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] Inconsistent script/console behaviour
On 12/15/2011 3:58 AM, anatoly techtonik wrote: 1. It is not a proposal, but a defect (well, you may argue, but please, don't) You state a controversial opinion as a fact and then request that others not discuss it. To me, this is a somewhat obnoxious hit-and-run tactic. If you do not want the point discussed, don't bring it up. Anyway, I will follow your request and not argue. Since that opinion is a central point, not discussing it does not leave much to say. -- Terry Jan Reedy ___ 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
[Python-Dev] French sprint this week-end
Hi, I organize an online sprint on CPython this week-end with french developers. At least six developers will participe, some of them don't know C, most know Python. Do you know simple task to start contributing to Python? Something useful and not boring if possible :-) There is the "easy" tag on the bug tracker, but many issues have a long history, already have a patch, etc. Do know other generic task like improving code coverage or support of some rare platforms? Eric Araujo, Antoine Pitrou and Charles François Natali should help me, so I'm not alone to organize the sprint. Don't watch the buildbot until Monday. You can expect more activity on our bug tracker (and maybe on the #python-dev channel) ;-) -- If you speak french, join #python-dev-fr IRC channel (on Freenode) and see the wiki page http://wiki.python.org/moin/SprintFranceDec2011 Victor ___ 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-checkins] cpython: input() in this sense is gone
On Thu, Dec 15, 2011 at 10:44 PM, benjamin.peterson wrote: > +# eval_input is the input for the eval() functions. Shouldn't this be "function" rather than "functions"? ___ 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
[Python-Dev] A new dict for Xmas?
Hi all, The current dict implementation is getting pretty old, isn't it time we had a new one (for xmas)? I have a new dict implementation which allows sharing of keys between objects of the same class. You can check it out here: http://bitbucket.org/markshannon/hotpy_new_dict Performance: For numerical applications, with few instances of user-defined classes, performance is pretty much unchanged, degrading about 1% for pystones. For applications that create lots of instances of user-defined classes, performance is improved and memory savings are large. For the gcbench benchmark (from unladen swallow), cpython with the new dict is about 9% faster and, more importantly, reduces memory use from 99 Mbytes to 61Mbytes (a 38% reduction). All tests were done on my ancient 32 bit intel linux machine, please try it out on your machines and let me know what sort of results you get. By the way it passes all the tests, but there are strange interactions with weakrefs and the GC. (Try running the tests, you'll see what I mean) Cheers, Mark ___ 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] A new dict for Xmas?
On Thu, 15 Dec 2011 22:18:18 + Mark Shannon wrote: > > For the gcbench benchmark (from unladen swallow), > cpython with the new dict is about 9% faster and, more importantly, > reduces memory use from 99 Mbytes to 61Mbytes (a 38% reduction). > > All tests were done on my ancient 32 bit intel linux machine, > please try it out on your machines and let me know what sort of results > you get. Benchmark results under a Core i5, 64-bit Linux: Report on Linux localhost.localdomain 2.6.38.8-desktop-8.mga #1 SMP Fri Nov 4 00:05:53 UTC 2011 x86_64 x86_64 Total CPU cores: 4 ### call_method ### Min: 0.292352 -> 0.274041: 1.07x faster Avg: 0.292978 -> 0.277124: 1.06x faster Significant (t=17.31) Stddev: 0.00053 -> 0.00351: 6.5719x larger ### call_method_slots ### Min: 0.284101 -> 0.273508: 1.04x faster Avg: 0.285029 -> 0.274534: 1.04x faster Significant (t=26.86) Stddev: 0.00068 -> 0.00135: 1.9969x larger ### call_simple ### Min: 0.225191 -> 0.222104: 1.01x faster Avg: 0.227443 -> 0.222776: 1.02x faster Significant (t=9.53) Stddev: 0.00181 -> 0.00056: 3.2266x smaller ### fastpickle ### Min: 0.482402 -> 0.493695: 1.02x slower Avg: 0.486077 -> 0.496568: 1.02x slower Significant (t=-5.35) Stddev: 0.00340 -> 0.00276: 1.2335x smaller ### fastunpickle ### Min: 0.394846 -> 0.433733: 1.10x slower Avg: 0.397362 -> 0.436318: 1.10x slower Significant (t=-23.73) Stddev: 0.00234 -> 0.00283: 1.2129x larger ### float ### Min: 0.052567 -> 0.051377: 1.02x faster Avg: 0.053812 -> 0.052669: 1.02x faster Significant (t=3.72) Stddev: 0.00110 -> 0.00107: 1.0203x smaller ### json_dump ### Min: 0.381395 -> 0.391053: 1.03x slower Avg: 0.381937 -> 0.393219: 1.03x slower Significant (t=-7.15) Stddev: 0.00043 -> 0.00350: 8.1447x larger ### json_load ### Min: 0.347112 -> 0.369763: 1.07x slower Avg: 0.347490 -> 0.370317: 1.07x slower Significant (t=-69.64) Stddev: 0.00045 -> 0.00058: 1.2717x larger ### nbody ### Min: 0.238068 -> 0.219208: 1.09x faster Avg: 0.238951 -> 0.22: 1.09x faster Significant (t=36.09) Stddev: 0.00076 -> 0.00090: 1.1863x larger ### nqueens ### Min: 0.262282 -> 0.252576: 1.04x faster Avg: 0.263835 -> 0.254497: 1.04x faster Significant (t=7.12) Stddev: 0.00117 -> 0.00269: 2.2914x larger ### regex_effbot ### Min: 0.060298 -> 0.057791: 1.04x faster Avg: 0.060435 -> 0.058128: 1.04x faster Significant (t=17.82) Stddev: 0.00012 -> 0.00026: 2.1761x larger ### richards ### Min: 0.148266 -> 0.143755: 1.03x faster Avg: 0.150677 -> 0.145003: 1.04x faster Significant (t=5.74) Stddev: 0.00200 -> 0.00094: 2.1329x smaller ### silent_logging ### Min: 0.057191 -> 0.059082: 1.03x slower Avg: 0.057335 -> 0.059194: 1.03x slower Significant (t=-17.40) Stddev: 0.00020 -> 0.00013: 1.4948x smaller ### unpack_sequence ### Min: 0.46 -> 0.42: 1.10x faster Avg: 0.48 -> 0.44: 1.09x faster Significant (t=128.98) Stddev: 0.0 -> 0.0: 1.8933x smaller gcbench first showed no memory consumption difference (using "ps -u"). I then removed the "stretch tree" (which apparently reserves memory upfront) and I saw a ~30% memory saving as well as a 20% performance improvement on large sizes. Regards Antoine. ___ 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] Compiling the source without stat
Am 15.12.2011 12:59, schrieb Hossein: > I wanted to say something in the bug page petri showed ( > http://bugs.python.org/issue12082 ) however I though about first > discussing it here. If faking a stat struct and a function to fill it > solves the problem, and checking for existing files and folders is the > only thing that python needs to be compiled (i'm talking about 2.7) then > it's possible to fail-check it by just trying to open the file. That's not true. It also looks at the file modification time. Regards, Martin ___ 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-checkins] cpython: improve abstract property support (closes #11610)
On Fri, Dec 16, 2011 at 6:34 AM, benjamin.peterson wrote: > +abc > +--- > + > +Improved support for abstract base classes containing descriptors composed > with > +abstract methods. The recommended approach to declaring abstract descriptors > is > +now to provide :attr:`__isabstractmethod__` as a dynamically updated > +property. The built-in descriptors have been updated accordingly. > + > + * :class:`abc.abstractproperty` has been deprecated, use :class:`property` > + with :func:`abc.abstractmethod` instead. > + * :class:`abc.abstractclassmethod` has been deprecated, use > + :class:`classmethod` with :func:`abc.abstractmethod` instead. > + * :class:`abc.abstractstaticmethod` has been deprecated, use > + :class:`property` with :func:`abc.abstractmethod` instead. > + > +(Contributed by Darren Dale in :issue:`11610`) s/property/staticmethod/ in the final bullet point here. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] A new dict for Xmas?
Antoine Pitrou wrote: On Thu, 15 Dec 2011 22:18:18 + Mark Shannon wrote: For the gcbench benchmark (from unladen swallow), cpython with the new dict is about 9% faster and, more importantly, reduces memory use from 99 Mbytes to 61Mbytes (a 38% reduction). All tests were done on my ancient 32 bit intel linux machine, please try it out on your machines and let me know what sort of results you get. Benchmark results under a Core i5, 64-bit Linux: Report on Linux localhost.localdomain 2.6.38.8-desktop-8.mga #1 SMP Fri Nov 4 00:05:53 UTC 2011 x86_64 x86_64 Total CPU cores: 4 ### call_method ### Min: 0.292352 -> 0.274041: 1.07x faster Avg: 0.292978 -> 0.277124: 1.06x faster Significant (t=17.31) Stddev: 0.00053 -> 0.00351: 6.5719x larger ### call_method_slots ### Min: 0.284101 -> 0.273508: 1.04x faster Avg: 0.285029 -> 0.274534: 1.04x faster Significant (t=26.86) Stddev: 0.00068 -> 0.00135: 1.9969x larger ### call_simple ### Min: 0.225191 -> 0.222104: 1.01x faster Avg: 0.227443 -> 0.222776: 1.02x faster Significant (t=9.53) Stddev: 0.00181 -> 0.00056: 3.2266x smaller ### fastpickle ### Min: 0.482402 -> 0.493695: 1.02x slower Avg: 0.486077 -> 0.496568: 1.02x slower Significant (t=-5.35) Stddev: 0.00340 -> 0.00276: 1.2335x smaller ### fastunpickle ### Min: 0.394846 -> 0.433733: 1.10x slower Avg: 0.397362 -> 0.436318: 1.10x slower Significant (t=-23.73) Stddev: 0.00234 -> 0.00283: 1.2129x larger ### float ### Min: 0.052567 -> 0.051377: 1.02x faster Avg: 0.053812 -> 0.052669: 1.02x faster Significant (t=3.72) Stddev: 0.00110 -> 0.00107: 1.0203x smaller ### json_dump ### Min: 0.381395 -> 0.391053: 1.03x slower Avg: 0.381937 -> 0.393219: 1.03x slower Significant (t=-7.15) Stddev: 0.00043 -> 0.00350: 8.1447x larger ### json_load ### Min: 0.347112 -> 0.369763: 1.07x slower Avg: 0.347490 -> 0.370317: 1.07x slower Significant (t=-69.64) Stddev: 0.00045 -> 0.00058: 1.2717x larger ### nbody ### Min: 0.238068 -> 0.219208: 1.09x faster Avg: 0.238951 -> 0.22: 1.09x faster Significant (t=36.09) Stddev: 0.00076 -> 0.00090: 1.1863x larger ### nqueens ### Min: 0.262282 -> 0.252576: 1.04x faster Avg: 0.263835 -> 0.254497: 1.04x faster Significant (t=7.12) Stddev: 0.00117 -> 0.00269: 2.2914x larger ### regex_effbot ### Min: 0.060298 -> 0.057791: 1.04x faster Avg: 0.060435 -> 0.058128: 1.04x faster Significant (t=17.82) Stddev: 0.00012 -> 0.00026: 2.1761x larger ### richards ### Min: 0.148266 -> 0.143755: 1.03x faster Avg: 0.150677 -> 0.145003: 1.04x faster Significant (t=5.74) Stddev: 0.00200 -> 0.00094: 2.1329x smaller ### silent_logging ### Min: 0.057191 -> 0.059082: 1.03x slower Avg: 0.057335 -> 0.059194: 1.03x slower Significant (t=-17.40) Stddev: 0.00020 -> 0.00013: 1.4948x smaller ### unpack_sequence ### Min: 0.46 -> 0.42: 1.10x faster Avg: 0.48 -> 0.44: 1.09x faster Significant (t=128.98) Stddev: 0.0 -> 0.0: 1.8933x smaller Thanks for running the benchmarks. It's probably best not to attach to much significance to a few percent her and there, but its good to see that performance is OK. gcbench first showed no memory consumption difference (using "ps -u"). I then removed the "stretch tree" (which apparently reserves memory upfront) and I saw a ~30% memory saving as well as a 20% performance improvement on large sizes. I should say how I did my memory tests. I did a search using ulimit to limit the maximum amount of memory the process was allowed. The given numbers were the minimum required to complete, I did not remove the "stretch tree". Cheers, Mark. ___ 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
[Python-Dev] generators and ceval
Hi, I Just added issue 13607 with a patch that removes the generator specific checks and code out of the ceval PyEval_EvalFrameEx() function. Those parts where moved up into the generator gen_send_ex() function. Doing that removed the generator flag checks from the eval loop and made it a bit cleaner. In order to do that, I needed to give generators a why to look at the 'why' value. Doing that also cleaned up the code in gen_sendex() as it can use the 'why' in a select instead of several indirect if tests. http://bugs.python.org/issue13607 Altogether it made yields about 10% faster, and everything else about 2%-3% faster (on average). But it does need to be checked. Cheers, Ron ___ 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] A new dict for Xmas?
Mark Shannon wrote: I have a new dict implementation which allows sharing of keys between objects of the same class. We already have the __slots__ mechanism for memory savings. Have you done any comparisons with that? Seems to me that __slots__ ought to save even more memory, since it eliminates the per-instance dict altogether rather than just the keys half of it. -- Greg ___ 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] Fixing the XML batteries
Stefan Behnel, 09.12.2011 09:02: I think Py3.3 would be a good milestone for cleaning up the stdlib support for XML. [...] I still think it is, so let me sum up the current discussion here. What should change? a) The stdlib documentation should help users to choose the right tool right from the start. It looks like there's agreement on this part. Instead of using the totally misleading wording that it uses now, it should be honest about the performance characteristics of MiniDOM and should actively suggest that those who don't know what to choose (or even *that* they can choose) should not use MiniDOM in the first place. There was some disagreement on whether MiniDOM should publicly disclose its performance characteristics in the documentation, and whether its use should be discouraged, even just for new users. However, it seemed that there was enough consensus to settle on Nick Coghlan's proposal for a compromise to move ElementTree up to the top of the list, and to add a visible note to the top of each of the XML modules like this: "Note: The module is a . If all you are trying to do is read and write XML files, consider using the xml.etree.ElementTree module instead" That template could (with a bit of peaking into the getopt documentation) be expanded into the following. """ [[Note: The xml.dom.minidom module provides an implementation of the W3C-DOM whose API is similar to that in other programming languages. Users who are unfamiliar with the W3C-DOM interface or who would like to write less code for processing XML files should consider using the xml.etree.ElementTree module instead.]] """ I think this should go on the xml.dom.minidom page as well as the xml.dom package page. Hand-wavingly, users who are new to the DOM are more likely to hit the package page first, whereas those who know it already will likely find the MiniDOM page directly. Note that I'd still encourage the removal of the misleading word "lightweight" until it makes sense to put it back in a meaningful way. I therefore propose the following minimalistic changes to the first paragraph on the minidom page: """ xml.dom.minidom is a [-XXX: light-weight] implementation of the Document Object Model interface. It is intended to be simpler than the full DOM and also [+XXX: provide a] significantly smaller [+XXX: API]. """ @Martin: note how the original paragraph does not refer to "4DOM" or "PyXML". It only generically mentions "the DOM interface". It is certainly not true that MiniDOM is more "light-weight" and "significantly smaller" than (most) other DOM interface implementations outside of the Python world, for example. So the current wording actually makes no sense at all. Additionally, the documentation on the xml.sax page would benefit from the following paragraph: """ [[Note: The xml.sax package provides an implementation of the SAX interface whose API is similar to that in other programming languages. Users who are unfamiliar with the SAX interface or who would like to write less code for efficient stream processing of XML files should consider using the iterparse() function in the xml.etree.ElementTree module instead.]] """ If these changes are considered acceptable, I'll copy the above over to the documentation bug I opened at http://bugs.python.org/issue11379 Can these doc changes go into both 2.7 and 3.3? Given that there is no important difference between the implementations, I don't see why the documentation should differ in Py2. b) cElementTree should finally loose it's "special" status as a separate library and disappear as an accelerator module behind ElementTree. There was no opposition and a general agreement on this in the thread, except for the warning that Fredrik Lundh should have a word in this. I wrote him an e-mail and didn't get a response so far. We can wait a little longer, I guess, there's still time before 3.3beta. Stefan ___ 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
