Re: (side-)effects and ...
On 07/05/2015 04:29 PM, Stefan Ram wrote: But why do we not have a common and well-known term for the counterpart, that something does not modify the state of the world, but that the state of the world does influence the value (behaviour) of a call such as »datetime.datetime.now().time()«? And this is the intention of my post: Maybe there is such a term, and I just missed to learn it so far? So, do you know a term for the phenomenon that can be found in Python but not in mathematics and consists in the state of the world influencing the value of an expressions? Variables that are changed from an outside environment are Volatile. https://en.wikipedia.org/wiki/Volatile_%28computer_programming%29 It isn't used in python, though I think maybe it should be. Cheers, Ron -- https://mail.python.org/mailman/listinfo/python-list
Re: Lawful != Mutable (was Can Python function return multiple data?)
On 06/20/2015 10:50 PM, Rustom Mody wrote: Here is Eric Snow: | Keep in mind that by immutability I'm talking about*really* | immutable, perhaps going so far as treating the full memory space | associated with an object as frozen. For instance, we'd have to | ensure that immutable Python objects like strings, ints, and tuples | do not change (i.e. via the C API). The contents of involved | tuples/containers would have to be likewise immutable. Even changing | refcounts could be too much, hence the idea of moving refcounts out to | a separate table. | | This level of immutability would be something new to Python. We'll | see if it's necessary. If it isn't too much work it might be a good | idea regardless of the multi-core proposal. Does the second para look like CPython implementation or python-the-language? Also note the 'Even' in the first para. ie Eric is talking of low-level (ie thread-safety, refcounting etc) immutability after the even and higher level semantic immutability before It seems to me, this will take a lot more changes to python overall. Adding a way to raise an exception if an object is mutated would be a good initial step. Have it turned off by default. I think it will be needed to test how any of the above is working. It may also allow some multiprocessing just by avoiding raising any MutatedObject exceptions. Cheers, Ron -- https://mail.python.org/mailman/listinfo/python-list
Re: Set a flag on the function or a global?
On 06/16/2015 05:15 AM, Steven D'Aprano wrote: On Tuesday 16 June 2015 10:24, Ron Adam wrote: Another way is to make it an object with a __call__ method. The the attribute can be accessed from both outside and inside dependably. That's what functions are, objects with a __call__ method: py (lambda: None).__call__ method-wrapper '__call__' of function object at 0xb7301a04 Yes ;-) One slight disadvantage is that functions don't take a self parameter by default, which means they have to refer to themselves by name: def spam(): print spam.attr Here's a fun hack: py from types import MethodType py def physician(func): ... # As in, Physician, Know Thyself:-) ... return MethodType(func, func) ... py @physician ... def spam(this, n): ... return this.food * n ... py spam.__func__.food = spam-and-eggs py spam(3) 'spam-and-eggs spam-and-eggs spam-and-eggs' How about this?: (paste it into your console) #- import sys class EDir: long = False def __call__(self, obj=None): if obj == None: d = sys._getframe(1).f_locals else: d = dir(obj) return [x for x in d if self.long or not x.startswith(_)] edir = EDir() edir() edir(edir) edir.long = True edir(edir) edir.long = False edir(edir) #-- I didn't test how that works from other modules or in nested scopes. Also replacing None with a unique sentinel object may be better so dir(None) will work. Cheers, Ron -- https://mail.python.org/mailman/listinfo/python-list
Re: Set a flag on the function or a global?
On 06/15/2015 08:07 PM, Chris Angelico wrote: On Tue, Jun 16, 2015 at 9:57 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: I have two ideas for this, a module-level global, or a flag set on the function object itself. Remember that the usual way of using this will be from module import edir, there are two obvious ways to set the global: import module module.dunders = False # -or- edir.__globals__['dunders'] = False Alternatively, I can use a flag set on the function object itself: edir.dunders = False For most situations, the last one is extremely surprising - attributes on functions aren't normally meant to be changed by outside callers, Or inside callers either. You can't be sure of the name and there is no self. it always feels wrong (they belong to the function itself). But since this is interactive, I'd advise going for the absolute simplest, which this would be. Go for the function attribute IMO. Another way is to make it an object with a __call__ method. The the attribute can be accessed from both outside and inside dependably. Cheers, Ron -- https://mail.python.org/mailman/listinfo/python-list
Re: Rule of order for dot operators?
On 05/19/2015 02:25 AM, Chris Angelico wrote: On Tue, May 19, 2015 at 12:43 PM, Ron Adamron3...@gmail.com wrote: Having just implementing something similar for nested scopes, it turns out it can't be operators because if it was, then the names y and z would be resolved in the wrong scope. y = m z = n a = x . y . z Which of course wouldn't do what we want. a = x . m . n And most likely this would give an error. If you want to implement the dot as an operator, you could do it by having a special syntactic element called an atom, which is used for these kinds of identifier-like tokens. The dot operator could then take an object and an atom, and effectively return getattr(obj, stringify(atom)). I'm fairly sure this would result in the same syntax as Python uses. I think it's better not to. What practical things can be done if the dot was an operator and names after dots where parsed as atoms? What I did was parse a name to a subtype of tuple with elements of strings. [return name.with.dots] becomes this in memory after parsing. [keyword_object name_object] Using dots as operators would make that... [keyword_object name_object dot_object atom_object dot_object atom_object] This would require the interpreter to do in steps what a single function call can do all at once. Cheers, Ron -- https://mail.python.org/mailman/listinfo/python-list
Re: Rule of order for dot operators?
On 05/18/2015 09:32 PM, Rustom Mody wrote: In particular, each .foo() need not return a string - it might return anything, and the following .bah() will work on that anything. For an arbitrary binary operator ◼ x ◼ y ◼ z can group as (x◼y)◼z or x◼(y◼z) One could (conceivably) apply the same rule to x.y.z Except that x.(y.z) is a bit hard to give a meaning to!! Yes. Having just implementing something similar for nested scopes, it turns out it can't be operators because if it was, then the names y and z would be resolved in the wrong scope. y = m z = n a = x . y . z Which of course wouldn't do what we want. a = x . m . n And most likely this would give an error. The name-part after the dot is evaluated in the next inner scope. y is resolved in x's scope, and z is resolved in y's scope. Which is why you can implement objects with closures, but you need to delay name resolution to do that. Which is what the . does. Pythons attribute lookup is a bit more complex than this of course. https://docs.python.org/3.4/howto/descriptor.html Cheers, Ron -- https://mail.python.org/mailman/listinfo/python-list
An experiment with blocks of object code and other meta ideas.
I've been playing around with a experimental script language that executes
object code lists directly and am looking for others who might like to help.
The first version was written in python. The original idea came from
wondering if it is possible to replace python's byte code with nested
object code lists. As I worked on it, it became clear it would also make a
nice script language on it's own so I decided to test how it would work
independently of python first.
Currently it's implemented in scheme so it can be compiled to C and a stand
alone executable.
The design is simple enough that converting it to use python objects and
using the python C API should be fairly straight forward.
I can update the original written-in-python version if anyone is
interested. It's quite a bit behind the scheme version right now. It might
make an interesting module.
Here's a few command line examples...
== def [hello] [
... (print Hello World\n)
... ]
== (hello)
Hello World
== set a 23/41
== set b 3/2
== (+ a b)
169/82
== for x [1 2 3 4 5] [
...(print x \n)
... ]
1
2
3
4
5
== set conds [
... ( a 6)
... (== b 2)
... not-done
... ]
== let [a b not-done] [7 2 0]
== (or conds)
1
== (and conds)
0
And of course it does execute files too. :-)
{-- guess-my-number.mta
GUESS MY NUMBER GAME
The computer picks a number and you
try to guess it.
---}
def [guess] [
set n (random 10)
set msg Guess a number from 0 to 10:
loop [
(print msg)
catch error
[set g (int (read-line))]
if (not (empty? error))
[set msg What?, guess again: ]
elif ( g n)
[set msg Too high, guess again: ]
elif ( g n)
[set msg Too low, guess again: ]
else
[break]
]
(print Good guess!\n)
]
(guess)
I've been told it looks like a combination of scheme, tcl, and python.
This script-language tests a number of ideas I've been interested in.
Keywords are objects too! They can be bound to names and executed later in
another place or returned by expressions to be executed.
Blocks are nested lists of object code that can be passed around. Actually
programs are nested lists of object codes. It's just the outer most block.
These features make it an interesting meta language to experiment with.
If you think you may be interested in helping with this project, (It's open
source), you can find it here.
https://github.com/Ronald-Adam/magic-meta
https://github.com/Ronald-Adam/magic-meta/wiki/1.-Home
I'm hoping some of you may be interested in helping out as a group project
with the possibility of bringing some of the ideas back to python in some
form. Possibly as a script language that can be used in projects.
There is lots of opportunities to make improvements and additions as there
are zero users currently.
It's still very early in it's development, so don't expect too much at this
time.
Cheers,
Ron
--
https://mail.python.org/mailman/listinfo/python-list
Re: New to Python - block grouping (spaces)
On 04/19/2015 05:42 PM, BartC wrote: So I'm aware of some of the things that are involved. (BTW that project worked reasonably well, but I decided to go in a different direction: turning J from a mere syntax into an actual language of its own.) Something you might try with your new language is to have an editor that can parse the source text to a tokenised text data file. It should be a fairly direct text to text translation, so putting it into the editor should be doable. Once you get that far, you can add pluggable token parsers to the editor that can unparse the token files to a specific user format for editing, and reparse it back to the standardised token file for storage. Now the users can choose a customised dialect of your language. And the compiler will work on a single token file type. This will also remove the need for pretty printers and formatters as they will be built into the editors pluggable token parser. Just have the editor tokenise and then immediately untokenise and you just checked for syntax errors and reformatted the program. The highlighter could also work with the token parser as well. The only catch is how to handle compile and run time errors. The editor will need to read an error file and translate it back to the source. I think it's doable but it will be tricky to get it to work well. The reason to make the split at tokens is, it's at a stage that most of what is needed is already in a text editor. The token file format becomes the bridge that spans the gap between the user/editor and the compiler/interpreter. Then your compiler/interpreter is all implementation details that work on a single standardised token file format rather than unformatted text files. Ron -- https://mail.python.org/mailman/listinfo/python-list
Re: Great Math Mystery
On 04/17/2015 11:03 AM, Steven D'Aprano wrote: On Fri, 17 Apr 2015 07:47 pm, Fetchinson . wrote: In an altercation with the police, complying with their orders greatly increases your chances of survival. Ah, the definition of a police state: where ordinary people, whether breaking the law or not, are forced by fear of death to obey the police at all times, whether the police are acting legally or not. I think you are grossly mischaracterizing that sentence of the OP. He simply makes an observation: in an altercation with the police, complying with their orders greatly increases your chances of survival. Is this observation/statement true or false? Based on empirical data from the past 50 years (in the US and elsewhere) I'd say it's true by a huge margin. Which is*exactly my point*. Failure to obey arbitrary commands from random police officers, whether legally justified or not, may carry the penalty of summary execution at the discretion of the officer is a defining characteristic of police states. This is but one subset of the possibilities that could lead to the same valid advise. Keep in mind that many officers are citizens too, at least where I live, who have jobs that put them in extremely dangerous situations fairly often. Taking too long to rationally think about a situation could mean the police officer is shot instead of the criminal with a gun. There are some combinations of conditions that will result in a certain percentage of outcomes of a certain kind. I think the original statement (Quite possibly from a fortune cookie program.) recognises that concept (as well as yours.) Take a thousand officers, each who respond to a thousand calls a year, and there will be a few (very tragic) mistakes. (and hopefully many more fortunate interventions.) We can maybe shift the proportion of mistakes vs interventions, but I don't see how training officers to shoot after being shot is a good idea. We will likely need to pay a whole lot more to get people to take those jobs. Of course it does not excuse willing abuse of authority. Most cases of police power abuse here are more likely to be related to an individual officers state of mind and/or motives at the time rather than being due to instructions higher up. Possibly there is a way to use Python and statistics to calculate some of these values. With data of course... Number of officers. number of responses. Percent of responses where suspects have deadly weapons. Percent of incorrect judgements within some critical time frame by people in safe conditions. Percentage of incorrect judgements of people in dangerous conditions. Percentage of incorrect judgements of people in safe, but perceived dangerousness conditions.. etc... Would be possible to calculate a norm or average from that kind of info? It is also the type of number people don't want to know about or discuss. -Ron I made no comment on the OP's intention for making that statement. Perhaps he was making an ironic comment on the state of US law enforcement; perhaps he thinks he is being genuinely helpful; perhaps this is his way of mocking those killed. I don't know. Whether he is a fascist who thinks police states are wonderful, or a liberal who thinks they are terrible, he described a police state. Whether he knew it at the time or not. -- https://mail.python.org/mailman/listinfo/python-list
Re: New to Python - block grouping (spaces)
On 04/16/2015 01:41 PM, Steven D'Aprano wrote:
2. Having been an employer, it is difficult to force programmers to use
any particular editor or style. Different editors handle tabs and spaces
differently. This is all a bloody nightmare with Python.
Do you really expect us to believe for a microsecond that the choice
between 4 spaces or tab is worse than the C brace wars?
You know I've never thought braces where the problem in a language, and in
python, not having them isn't a problem either.
The reason I dislike C is due to the amount of boiler plate and the low
level of code, which requires managing memory, declaring prototypes and
including headers. All of which I think are much more troublesome and
harder to get right than any amount of braces.
Both sides have advantages, but Python's design is meant to represent code
in an easier to see and read way. Representing blocks by indention is
consistent with that. (And so is outlines in written language.)
I could equally like a language where blocks are literal code objects that
can be assigned to names. In that case the block delimiters would be
consistent with that language design and that would be perfectly fine to
me. The code would be representing what it does in an expected and useful way.
block = {statement_1; statement_2; ...}
The cases in between seem a bit unclean to me however. Where braces are
used to define blocks that aren't exposed. I think it's ok, but it also
seems a bit unclean to me. Adding more noise than necessary to the code.
But I understand at some time, when a language was designed it may have
been that it made parsing the language simpler. (it does.) Or it may have
just been the language designers preference at that time. shrug
But still, I think the whole braces are good/evil is over stated. There
are lots of more important things in languages to consider.
Cheers,
Ron
--
https://mail.python.org/mailman/listinfo/python-list
[issue18387] Add 'symbols' link to pydoc's html menu bar.
Ron Adam added the comment: Adding you Nick, I don't have commit rights. This probably doesn't need much.. maybe a one line comment in news is all. (And maybe not even that.) -- nosy: +ncoghlan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18387 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18740] str is number methods don't recognize '.'
New submission from Ron Adam: Shouldn't at least isdecimal return True? '123.0'.isdecimal() False '123.0'.isalnum() False '123.0'.isnumeric() False '123.0'.isdigit() False -- components: Interpreter Core messages: 195186 nosy: ron_adam priority: normal severity: normal status: open title: str is number methods don't recognize '.' type: behavior versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18740 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18740] str is number methods don't recognize '.'
Ron Adam added the comment: I get the same resluts if I make the string by str(123.0). I was thinking it should test True for the isdecimal case for that. It seems I missunderstood their purpose/use. This seems like it would be a very common misunderstanding. It appears, (Because it isn't stated in the doc strings), that they are for testing what specific sub-group of unicode data, the individual character(s) are in. I think the methods doc strings should say this and be worded so they are more character specific. Tests each character, and returns true if all of them are in the unicode ___ sub-group. As for testing weather or not a string as a whole represents a number value, it seems try/except is still the best way. :-/ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18740 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18387] Add 'symbols' link to pydoc's html menu bar.
Changes by Ron Adam ron3...@gmail.com: Removed file: http://bugs.python.org/file30922/pdoc_symbols.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18387 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18387] Add 'symbols' link to pydoc's html menu bar.
Ron Adam added the comment: Patch update: removed from pydoc symbols table. -- Added file: http://bugs.python.org/file30931/pdoc_symbols.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18387 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18387] Add 'symbols' link to pydoc's html menu bar.
Ron Adam added the comment: I agree the specific content for each symbol are separate issues. Those are probably best addressed individually or a few at a time when they are closely related. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18387 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18436] Add mapping of symbol to function to operator module
Ron Adam added the comment: Regarding opertor.get_op: Look at help(symbols) output for consistancy. There may be items in one that can be included in the other. The operator.get_op addition would be useful for improving help on the symbol information for help/pydoc. Currently it seems overly general for symbols. Also patch, http://bugs.python.org/issue18387, which adds help(symbols) output to pydocs web browser interface. It could use a review. -- nosy: +ron_adam ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18436 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18387] Add 'symbols' link to pydoc's html menu bar.
Ron Adam added the comment: Thanks for catching that. I had used unquote_plus instead of unquote. That is needed for multi-field form data, pydoc doens't need it. Removed the back tick from the pydoc symbols list. The topic link for that symbol was already removed. I also attempted to make the escape() usage a bit better by using the escape function from the html package in more places. It does just a bit better job of escaping. I wasn't aware help() would take a symbols argument when I added the keywords and topics pages to the html server. I've been meaning to get this in for a while. -- Added file: http://bugs.python.org/file30922/pdoc_symbols.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18387 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18387] Add 'symbols' link to pydoc's html menu bar.
Ron Adam added the comment: Updated the patch. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18387 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18387] Add 'symbols' link to pydoc's html menu bar.
Changes by Ron Adam ron3...@gmail.com: Removed file: http://bugs.python.org/file30843/pdoc_symbols.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18387 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18387] Add 'symbols' link to pydoc's html menu bar.
Changes by Ron Adam ron3...@gmail.com: Removed file: http://bugs.python.org/file30831/pdoc_symbols.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18387 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18387] Add 'symbols' link to pydoc's html menu bar.
Ron Adam added the comment: New slightly improved patch. Combined the topic index's, topics, keywords, and the new symbols case, into a single html_topicsindex(title) function. -- Added file: http://bugs.python.org/file30843/pdoc_symbols.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18387 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18387] Add 'symbols' link to html menu bar.
New submission from Ron Adam:
This patch adds a 'symbols' link after the 'topics' and 'keywords' links in the
html browser menu bar.
help('symbols') worked, but there was no way to get to it in the html browser.
This also adds unquote_plus() to the url handler to unquote the html input form
fields. This is needed to allow entering the symbols.
--
components: Library (Lib)
files: pdoc_symbols.diff
keywords: patch
messages: 192471
nosy: ron_adam
priority: normal
severity: normal
status: open
title: Add 'symbols' link to html menu bar.
versions: Python 3.4
Added file: http://bugs.python.org/file30831/pdoc_symbols.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18387
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18387] Add 'symbols' link to pydoc's html menu bar.
Changes by Ron Adam ron3...@gmail.com: -- title: Add 'symbols' link to html menu bar. - Add 'symbols' link to pydoc's html menu bar. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18387 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10716] Modernize pydoc to use better HTML and separate CSS
Ron Adam added the comment: I'm going to go over this issue again with fresh eyes after having been away for some time. Recent experience with another project has helped answer some of the questions I had earlier. Particulary, how not to over specifying class names and id's. This should lead to cleaner html pages that will be easier to style with css. It should also lead to a smaller patch. ;-) It seems that most of the input so far has more to do with spelling rather than function. Is there a prefered style guide for css that we should use? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10716 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13659] Add a help() viewer for IDLE's Shell.
Ron Adam ron3...@gmail.com added the comment: What about having idle open a web browser session with pydocs new browse option? python3 -m pydoc -b We've added input fields to the pages that take the same input as help() command does. It also links to the online help pages, and you can view the source code of the files directly in the browser. (Sometimes that's the best documentation you can get.) -- nosy: +ron_adam ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13659 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13607] Move generator specific sections out of ceval.
Changes by Ron Adam ron3...@gmail.com: Removed file: http://bugs.python.org/file24047/f_why1.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13607 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13607] Move generator specific sections out of ceval.
Ron Adam ron3...@gmail.com added the comment: Updated patch with suggested changes. It also has a cleaned up fast_block_end section. Concerning speed. What happens is (as Tim and Raymond have pointed out) that we can make some things a little faster, in exchange for other things being a little slower. You can play around with the order of the why cases in the fast_block_end section and see that effect. By using a switch instead of if-else's, that should result in more consistent balance between the block exit cases. The order I currently have gives a little more priority for exceptions and that seems to help a tiny bit with the ccbench scores. I think that is a better bench mark than the small micro tests like pybench does. The problem with pybench is, it doesn't test deeper nesting where these particular changes will have a greater effect. -- Added file: http://bugs.python.org/file24087/f_why2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13607 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13607] Move generator specific sections out of ceval.
Ron Adam ron3...@gmail.com added the comment:
I think the time benefits I saw are dependent on how the C code is compiled.
So it may be different on different compilers or the same compiler with only a
very minor change.
Some of the things I've noticed...
A switch is sometimes slower if it has a default: block.
Moving why = tstate-why_exit; to just before the if helps a tiny bit.
why = tstate-why_exit;
if (why != WHY_EXCEPTION) {
Returning directly out of the WHY_YIELD case.
case WHY_YIELD:
return result;
These will be mostly compiler dependent, but they won't slow things down any
either.
What I was trying to do is clean up things a bit in ceval.c. Having the why
available on the frame can help by allowing some things to be moved out of
ceval.c where it makes sense to do that.
I'll post a new diff tonight with the why_exit moved back to the frame object
and the why's back to enums. Yes, I think the frame object is a good place for
it.
One of the odd issues is the opcode and why values sometimes need to be pushed
on the value stack. Which means it needs to be converted to a pyobject first,
then converted back after it's pulled off the stack. I'm looking for a way to
avoid that.
I also was able to make fast_block_end section simpler and more understandable
without making it slower. I think it was trying to be too clever in order to
save some lines of code. That makes it very hard to figure out by someone else.
But first I need to finish my Christmas shopping, I'll post a new patch tonight
when I get a chance. :-)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13607
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13607] Move generator specific sections out of ceval.
Changes by Ron Adam ron3...@gmail.com: Removed file: http://bugs.python.org/file23969/f_why.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13607 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13607] Move generator specific sections out of ceval.
Ron Adam ron3...@gmail.com added the comment: New diff file. The main difference is I moved the saved why value to the tstate object instead of the frame object as why_exit. I'm not seeing the time savings now for some reason. Maybe the previous increase was a case of coincidental noise. (?) Still looking for other reasons though. ;-) Moving the generator code from the eval loop to the generator object may still be a good thing to do. -- Added file: http://bugs.python.org/file24047/f_why1.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13607 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13607] Move generator specific sections out of ceval.
New submission from Ron Adam ron3...@gmail.com: The following changes cleanup the eval loop and result in a pretty solid 2 to 3% improvement in pybench for me. And it is about 5% faster for long generators. * Change why enum type to int and #defines. And moved the why defines to opcode.h so that they can be seen by the genrator objects after a yield, return, or exception. * Added an int f_why to frames so the generator can see why it returned from a send. * Refactored generator obj so it can use the f-f_why to determine what to do without having to do several checks first. * Moved the generator specific execption save/swap/and clear out of the cevel main loop. No need to check for those on every function call. The only test that fails is the frame size is test_sys. I left that in for now so someone could check that, and tell me if it's ok to fix it, or if I need to do something else. I also considered putting the why on the tstate object. It might save some memory as there wouldn't be as many of those. -- components: Interpreter Core files: f_why.diff keywords: patch messages: 149583 nosy: ron_adam priority: normal severity: normal status: open title: Move generator specific sections out of ceval. type: performance versions: Python 3.3 Added file: http://bugs.python.org/file23969/f_why.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13607 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13607] Move generator specific sections out of ceval.
Ron Adam ron3...@gmail.com added the comment: A simple test to show the difference. BEFORE: $ python3 -mtimeit def y(n): for x in range(n): yield x sum(y(10)) 10 loops, best of 3: 3.87 usec per loop $ python3 -mtimeit def y(n): for x in range(n): yield x sum(y(100)) 10 loops, best of 3: 186 msec per loop AFTER: $ ./python -mtimeit def y(n): for x in range(n): yield x sum(y(10)) 10 loops, best of 3: 3.81 usec per loop $ ./python -mtimeit def y(n): for x in range(n): yield x sum(y(100)) 10 loops, best of 3: 168 msec per loop before after y(10) usec's 3.873.81 - 1.55% y(100)msec's 186 168 - 9.67% -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13607 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11682] PEP 380 reference implementation for 3.3
Ron Adam ron3...@gmail.com added the comment: Thanks for the updated links Nick. There is a comment in the docs that recommends putting parentheses around any yield expression that returns a value. So it is in agreement with that in the function argument case. The grammar I used does keep it as a variant. yield_expr 'yield' [testlist | yield_from] yield_from 'from' test The purpose of doing that is so I can do ... yield_expr 'yield' [testlist | yield_from | yield_raise] yield_from 'from' test yield_raise 'raise' [test ['from' test]] The yield_raise part is only an interesting exercise to help me understand cpythons internals better. I'm getting there and hope to be able to contribute to more bug fixes, and patches. :-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11682 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11682] PEP 380 reference implementation for 3.3
Ron Adam ron3...@gmail.com added the comment: There is a test for 'yield from' as a function argument without the extra parentheses. f(yield from x) You do need them in the case of a regular yield. f((yield)) or f((yield value)) Shouldn't the same rule apply in both cases? * I'm trying to do a version of the patch with 'yield_from' as a separate item from 'yield' in the grammar, but it insists on the parentheses due to it being a yield_expr component. -- nosy: +ron_adam ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11682 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11816] Refactor the dis module to provide better building blocks for bytecode analysis
Ron Adam ron3...@gmail.com added the comment: Instead of a get_instructions() function, How about using a DisCode class that defines the API for accessing Opinfo tuples of a disassembled object. So instead of... for instr in dis.bytecode_instructions(thing): process(instr) You could use... for instr in dis.DisCode(thing): process(instr) And I would like to be able to do... assertEqual(DisCode(thing1), DisCode(thing2)) It could also have a .dis() method that returns formatted output that matches what dis() currently prints. That would allow tests that use dis.dis() to get rid of capturing stdout with minimal changes. result = DisCode(func).dis() # return a dis compatible string. A DisCode object also offers a nice place to put documentation for the various pieces and an overall view of the new API without getting it confused with the current dis.dis() API. It's easier for me to remember an object with methods than several separate but related functions. (YMMV) This is very near a version of dis I did a while back where I removed the prints and returned a list of list object from dis.dis(). The returned object had __repr__ that formatted the data so it matched the current dis output. That made it work the same in a python shell. But I could still access and alter individual lines and fields by indexing or iterating it. While it worked nicely, it wouldn't be backwards compatible. -- nosy: +ron_adam ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11816 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13062] Introspection generator and function closure state
Changes by Ron Adam ron3...@gmail.com: -- nosy: +ron_adam ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13062 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2571] cmd.py always uses raw_input, even when another stdin is specified
Changes by Ron Adam ron_a...@users.sourceforge.net: -- nosy: +ron_adam ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2571 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11182] pydoc.Scanner class not used by anything
New submission from Ron Adam ron_a...@users.sourceforge.net: There doesn't seem to be any references to it in any other part of pydoc, or the Library for that matter. Searching for it on google code search (and also google web search) only turns up auto generated API references for python editing tools like VIM, and of course it's existence in pydoc itself. This doesn't appear to be related to the ModuleScanner class in any way other than possibly being a bit of left over example code. Can it be removed? -- components: Library (Lib) messages: 128365 nosy: ron_adam priority: normal severity: normal status: open title: pydoc.Scanner class not used by anything versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11182 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9364] some problems with the documentation of pydoc
Changes by Ron Adam ron_a...@users.sourceforge.net: -- nosy: +ron_adam ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9364 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1038909] pydoc method documentation lookup enhancement
Ron Adam ron_a...@users.sourceforge.net added the comment: I agree. It is close enough to be a duplicate. I suggest closing it. As Ka-Ping noted in the other issue: There's a link to the base class provided if you want to find out what the base class does. This is easy to do if your viewing pydoc output in a web browser. And you can also look at the source code to see any comments. At some point we can consider enhancing the command line help mode to make it easier to do the same. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1038909 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10716] Modernize pydoc to use CSS
Ron Adam ron_a...@users.sourceforge.net added the comment: A reminder: Check for instances where html.escape is not called on data inserted into the html pages. I'll update the patch as the non-css (error handling) parts made it into python 3.2. :-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10716 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10961] Pydoc touchups in new browser for 3.2
Ron Adam ron_a...@users.sourceforge.net added the comment: New and hopefully last patch... pydoc_misc_fix_e.diff I removed the .html in the ?key= links as Eric suggested. I checked the navbar float behavior on browsershots.org. Multiple versions of MSIE, firefox, opera, chrome, and safari were tested on Ubuntu and Windows XP. They all looked very close to each other. Better than I expected. :-) As for clearing floats, there is the html clear=all attribute, and a css style=clear:both;. The browsershots.org tests confirms style=clear:both; works as it should where I used it. Cheers, and hopefully this is ready to go. I believe it is. -- Added file: http://bugs.python.org/file20616/pydoc_misc_fix_e.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10961 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10961] Pydoc touchups in new browser for 3.2
Changes by Ron Adam ron_a...@users.sourceforge.net: Removed file: http://bugs.python.org/file20473/pydoc_misc_fix_c.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10961 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10961] Pydoc touchups in new browser for 3.2
Ron Adam ron_a...@users.sourceforge.net added the comment: George, My apologies to you for the late corrections. And thanks for doing this. Eric, I replied to your comments on Rietveld. Thanks for taking a look. I'll wait until you have a chance to reply and test it, then upload a new patch with any needed changes. Ron -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10961 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10961] Pydoc touchups in new browser for 3.2
New submission from Ron Adam ron_a...@users.sourceforge.net: A collection of small fix's that only effect the new browser mode. * Change title of html pages from Python ... to PyDoc * Fixed unterminated div float for items returned without a header. example: str, None, True, False * Added topic?key=... url command to explicitly get topics. This is to avoid the shadowing when an object has the same name as a topic. * Nicer parsing and error handling in the url handler. -- components: Library (Lib) files: pydoc_misc_fix.diff keywords: patch messages: 126633 nosy: georg.brandl, ron_adam priority: normal severity: normal status: open title: Pydoc touchups in new browser for 3.2 type: behavior versions: Python 3.2 Added file: http://bugs.python.org/file20467/pydoc_misc_fix.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10961 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10961] Pydoc touchups in new browser for 3.2
Ron Adam ron_a...@users.sourceforge.net added the comment: new patch... Adjusted a comment in the _gettopic method. Everything else the same. -- Added file: http://bugs.python.org/file20468/pydoc_misc_fix.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10961 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10961] Pydoc touchups in new browser for 3.2
Changes by Ron Adam ron_a...@users.sourceforge.net: Removed file: http://bugs.python.org/file20467/pydoc_misc_fix.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10961 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10961] Pydoc touchups in new browser for 3.2
Ron Adam ron_a...@users.sourceforge.net added the comment: A few last minute changes.. I think this will be all. Run topic contents through html.markup. That makes ref:, pep:, and html: links if they exist. (I meant to this earlier.) Fix case where topic reference links are to objects rather than another topic. (applies to keywords also.) Skips making an empty reference section if there are no references with a topic. These are all small changes, and nothing should be controversial in this as everything changed only effects the new html browser mode. -- Added file: http://bugs.python.org/file20473/pydoc_misc_fix_c.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10961 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10961] Pydoc touchups in new browser for 3.2
Changes by Ron Adam ron_a...@users.sourceforge.net: Removed file: http://bugs.python.org/file20468/pydoc_misc_fix.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10961 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10961] Pydoc touchups in new browser for 3.2
Changes by Ron Adam ron_a...@users.sourceforge.net: -- nosy: +eric.araujo, rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10961 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10918] **kwargs unnecessarily restricted in concurrent.futures 'submit' API
Ron Adam ron_a...@users.sourceforge.net added the comment: Yes, you are correct. Pulling the first value off of args would work. This is new for 3.2, can it still be changed? One more thing to consider... One of the things I look at for functions like these is, how easy is it to separate the data from the program interface? I prefer: submit_data = [fn, args, kwds] e.submit(*submit_data) or.. submit_args = [(a, k), (a, k), ... ] for args, kwds in submit_args: e.submit(fn, args, kwds) But its a trade off against easier direct calling. My feelings, is submit will be used more in an indirect way, like these examples, rather than being used directly by writing out each submit separately. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10918 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10918] **kwargs unnecessarily restricted in API
Ron Adam ron_a...@users.sourceforge.net added the comment: Why is this surprising? def foo(c, c=None): ... pass ... File stdin, line 1 SyntaxError: duplicate argument 'c' in function definition In the previous examples, it finds the duplicate at run time instead of compile time due to not being able to determine the contents of kwargs at compile time. It's just a bug in your code if you do it, and it should raise an exception as it does. -- nosy: +ron_adam ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10918 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10918] **kwargs unnecessarily restricted in API
Ron Adam ron_a...@users.sourceforge.net added the comment: Is this issue referring to something in Python's library, or a hypothetical function someone may write? If it's in the library, we can look at that case in more detail, otherwise, it's just a bad program design issue and there's nothing to do. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10918 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10918] **kwargs unnecessarily restricted in concurrent.futures 'submit' API
Ron Adam ron_a...@users.sourceforge.net added the comment:
Here is the whole method for reference...
def submit(self, fn, *args, **kwargs):
with self._shutdown_lock:
if self._shutdown_thread:
raise RuntimeError('cannot schedule new futures after shutdown')
f = _base.Future()
w = _WorkItem(f, fn, args, kwargs)
self._pending_work_items[self._queue_count] = w
self._work_ids.put(self._queue_count)
self._queue_count += 1
self._start_queue_management_thread()
self._adjust_process_count()
return f
submit.__doc__ = _base.Executor.submit.__doc__
If self and fn are in kwargs, they are probably a *different* self and fn, than
the self and fn passed to submit!
The current submit definition doesn't allow that, and pulling out self, and fn,
would not be correct either.
If it's still possible to change the method call signature, it should be
without asterisks...
def submit(self, fn, args, kwargs):
...
Then the correct way to call it would be...
submit(foo, [1, 2], dict(fn=bar))
There wouldn't be a conflict because the args, and keywords, (to be eventually
passed to fn), are never unpacked within submit.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10918
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10918] **kwargs unnecessarily restricted in concurrent.futures 'submit' API
Ron Adam ron_a...@users.sourceforge.net added the comment: Change... are never unpacked within submit. to... Are completely separate. It's the attempt to mix two function signatures together as one, that was/is the problem. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10918 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10818] pydoc: Remove old server and tk panel
Ron Adam ron_a...@users.sourceforge.net added the comment: Here is a patch for this. Not much to it as the hard parts were already done. Apparently there was no tests for this, test_pydoc still passes without it. Does there need to be any messages for the -g option? Pydoc help is displayed in the case -g is used. That already includes the new -b usage. -- keywords: +patch title: pydoc: refactorize duplicate DocHandler and DocServer classes - pydoc: Remove old server and tk panel Added file: http://bugs.python.org/file20272/no_tkserve.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10818 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10818] pydoc: refactorize duplicate DocHandler and DocServer classes
Ron Adam ron_a...@users.sourceforge.net added the comment: No refactoring is needed. The second copies are part of the new server. The old server was depreciated in 3.2 and is supposed to be removed along with the tk panel for 3.3. After that there will only be one of each again. This issue can be used for that purpose. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10818 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10716] Modernize pydoc to use CSS
Ron Adam ron_a...@users.sourceforge.net added the comment: If the colors are passed directly to the HTML they should be removed and left to the CSS(s) only. I don't know the code well enough to say if this is doable and/or if it requires a deprecation first; We may have to do dome depreciating when it comes to the old HTMLDoc class methods. Would it be possible to depreciate the whole class instead of the separate methods? If so, it would be good if we can squeeze that into 3.2. hint hint Or else we may not be able to finish this until Python 3.4. The empty css elements will be used later. Here is the css_v3.diff for review. I'd like to hear any thoughts about the general html structure and class/id names. Beside validating them, I test with firefox and chromium. I don't have easy access to ms-explorer or the current mac browser. -- Added file: http://bugs.python.org/file20236/css_v3.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10716 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10716] Modernize pydoc to use CSS
Ron Adam ron_a...@users.sourceforge.net added the comment: To go forward I can create a new private api instead of changing HTMLDoc, that would be preferable. Should the -w option also use the new html pages? Or do we need a new option for that? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10716 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10716] Modernize pydoc to use CSS
Ron Adam ron_a...@users.sourceforge.net added the comment: Here is a new diff which updates all the new pydoc pages to use the css file. The css file is simpler and cleaner. I also made a few adjustments to the url handler error handling, and changed the titles in the head sections so they say Pydoc instead of Python as they are PyDoc pages about Python. None of these changes effect any of the old pydoc code yet. This is about as far as we can go without removing the old tk panel and server. Time for some feed back. And how close do we really need it to be to the original? :-) -- Added file: http://bugs.python.org/file20216/css_v2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10716 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10716] Modernize pydoc to use CSS
Changes by Ron Adam ron_a...@users.sourceforge.net: Removed file: http://bugs.python.org/file20081/defaultstyle.css ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10716 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10716] Modernize pydoc to use CSS
Changes by Ron Adam ron_a...@users.sourceforge.net: Removed file: http://bugs.python.org/file20088/pydoc sample html files.zip ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10716 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10716] Modernize pydoc to use CSS
Changes by Ron Adam ron_a...@users.sourceforge.net: Removed file: http://bugs.python.org/file20183/css_v1.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10716 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10716] Modernize pydoc to use CSS
Ron Adam ron_a...@users.sourceforge.net added the comment: The HtmlDoc class has methods that take colors. Can this be changed or does it need to be depreciated first? def heading(self, title, fgcol, bgcol, extras=''): Format a page heading. return ''' table width=100%% cellspacing=0 cellpadding=2 border=0 summary=heading tr bgcolor=%s td valign=bottomnbsp;br font color=%s face=helvetica, arialnbsp;br%s/font/td td align=right valign=bottom font color=%s face=helvetica, arial%s/font/td/tr/table ''' % (bgcol, fgcol, title, fgcol, extras or 'nbsp;') For the interactive server, I can override these methods with no problem, but the generated docs won't benefit from this until the HtmlDoc class is replaced. Any suggestions? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10716 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10716] Modernize pydoc to use CSS
Ron Adam ron_a...@users.sourceforge.net added the comment: It may be useful to change those to 'id=' and 'class=' if possible. It isn't clear to me how much of pydoc is still part of the public api in python 3.x. pydoc.__all__ is set only to ['help']. Entering help(pydoc) just gives the basic help and command line arguments along with. DATA __all__ = ['help'] help = pydoc.Helper instance There is nothing in the official (online) docs on importing pydoc or any of it's classes or methods. But dir(pydoc) shows all the methods, and the HTMLDoc class is still importable even though they aren't listed in __all__. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10716 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10716] Modernize pydoc to use CSS
Ron Adam ron_a...@users.sourceforge.net added the comment: Here is a tentative start on this. (css_v1.diff) The css file is much better. It's shorter, simpler and validated. The header and navbar panel use it in the new server. Added a markup call to the topic page contents. (The same markup call is already used for the doc strings.) Extra items in the css are what I come up with from testing different ways of doing things. -- keywords: +patch Added file: http://bugs.python.org/file20183/css_v1.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10716 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10573] Consistency in unittest assert methods: order of actual, expected
Ron Adam ron_a...@users.sourceforge.net added the comment: The issue10573.diff file with the time stamp 20:03 has a lot of document changes that don't have corresponding code changes? -- nosy: +ron_adam ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10573 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10087] HTML calendar is broken
Changes by Ron Adam ron_a...@users.sourceforge.net: -- nosy: +ron_adam ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10087 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10087] HTML calendar is broken
Ron Adam ron_a...@users.sourceforge.net added the comment:
The problem is in the following line...
return ''.join(v).encode(encoding, xmlcharrefreplace)
The .encode(encoding, xmlcharrefreplace) is returning a bytes object.
Here is the simplest change to resolve the problem.
return str(''.join(v).encode(encoding, xmlcharrefreplace),
encoding=encoding)
But maybe a different way to implement xmlcharrefreplace is what is needed.
Would it be better if it were a function or method in the xml (or html) module?
Just because it can be implemented as an encoding doesn't mean it should be.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10087
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10087] HTML calendar is broken
Ron Adam ron_a...@users.sourceforge.net added the comment: Oops. You're right. I miss understood how the encode method works in this particular case. ;-/ I agree with your comments as well. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10087 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8916] Move PEP 362 (function signature objects) into inspect
Changes by Ron Adam ron_a...@users.sourceforge.net: -- nosy: +ron_adam ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8916 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10716] Modernize pydoc to use CSS
Ron Adam ron_a...@users.sourceforge.net added the comment: I uploaded the css file I used in an experimental version of pydoc. It may give some useful starting values. Before this is done, the old server code should be removed (also for 3.3). (another issue?) There are two files in the tools/scripts directory that may need attention as well. pydocgui.pyw and pydoc3. -- Added file: http://bugs.python.org/file20081/defaultstyle.css ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10716 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10716] Modernize pydoc to use CSS
Ron Adam ron_a...@users.sourceforge.net added the comment: Eric, most of what's in that file is what I figured out by trial and error in order to get it to work on the different browsers at that time. (about 3 years ago.) You are probably more experienced with css than I am, so you are more than welcome to update and change anything in there. :-) What do you think about starting with a set of static html pages to get the css and html to work nice, and then only after that is done, edit pydoc to generate those pages. That should get us mostly there, and simplify what needs to be done in pydoc. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10716 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10716] Modernize pydoc to use CSS
Ron Adam ron_a...@users.sourceforge.net added the comment: I think that's how I ended up with the style sheet I uploaded. It works, but it can be a slow process. Another factor is the pydoc server will reread an external style sheet on browser refreshes. So you can see the results of style sheet changes without restarting pydoc. If it's embedded, you need to edit the program and restart everything each time. I was thinking that I may still be able to make a set of static html files that go along with that style sheet. Then we can adjust the css class names and make other changes, then use that as a guide for replacing the html. Eric, what do you think? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10716 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10716] Modernize pydoc to use CSS
Ron Adam ron_a...@users.sourceforge.net added the comment: Ok, I just looked at them again, I didn't remember how different it was. They probably won't be much help other than maybe seeing how some things could be done. Here's a zip file of some saved pages, so you can take a look. -- Added file: http://bugs.python.org/file20088/pydoc sample html files.zip ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10716 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9319] imp.find_module('test/badsyntax_pep3120') causes segfault
Ron Adam ron_a...@users.sourceforge.net added the comment: Pydoc skips the badsysntax_pep3120 file for now. When this gets fixed that workaround should be removed. The work around is commented and refers to this issue #. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9319 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10588] imp.find_module raises unexpected SyntaxError
Changes by Ron Adam ron_a...@users.sourceforge.net: -- nosy: +ron_adam ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10588 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2001] Pydoc interactive browsing enhancement
Ron Adam ron_a...@users.sourceforge.net added the comment: Thanks for the review and style edits Éric. I think it's a much better patch with the changes and suggestions from you, Nick, and Alexander. I'll check my white space settings. Thanks for noticing it. As Nick points out, parts of the patch was written with the idea of having the text server as a separate module. So I made the example in it runnable as a doctest, as if it was going to be a public module. As Nick also suggests, the server example could be changed to a comment, and it could be condensed quite a bit by removing the command line doctest formatting/tutorial style and replacing it with a nice single example as it would be seen in a file. Originally I was hopping to get a complete rewrite into python 3.0. Then it was suggested I try for 2.6. While doing that, I went way overboard with making it have plug in html formatters and converters. (Some people suggested they wanted that). In the end, I found that these parts in this patch, (and some additional stuff), can be used without the complete rewrite. And these parts really help make pydoc much more usable. Not the document generating parts. Maybe we can move some of those parts to a pydoc_lib.py file at some point, and have an API for creating document generators rather than try to have pydoc do everything it self. As you noticed, I used an html style that is similar to what was in the other parts of pydoc. And yes, it's not pretty. As Nick points out, those things should be fixed, and I agree. But I feel it should be a separate patch. That will make it easier to review and keep the html code changes separate from any functional changes. Hopefully, we can update the html so it makes good use of the style sheet at that time as well. ie... a lot of the html code will probably be changed in the near future, so don't be too nit-picky about it right now. Other things that I hope to add later, are to have more references in the topics and keywords be links. That one is fairly easy. The function to do that is already in pydoc. Add line numbers and color output to the file view page. And eventually look into detecting and using reST to enhance both the html and text output in docstrings, topics, and keywords. As for the imports that arn't at the top of the module, I followed the usage that was in pydoc. It seemed to me that there was probably a conscious reason for why it done that way. I can't find anything I disagree with. Ron -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2001 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10509] PyTokenizer_FindEncoding can lead to a segfault if bad characters are found
Ron Adam ron_a...@users.sourceforge.net added the comment: Is this a duplicate of issue 9319? -- nosy: +ron_adam ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10509 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2001] Pydoc interactive browsing enhancement
Ron Adam ron_a...@users.sourceforge.net added the comment: Here is the latest patch with tests. In order to test the html pages I separated out the URL handler. So now we have three new functions. pydoc._start_server(urlhandler, port) pydoc._url_handler(url, content_type=text/html) pydoc.browse(port=0, *, open_browser=True) A css file: pydoc_data/_pydoc.css The tests in test_pydoc.py, test that the server can be started and shutdown without an error. And test that the _url_handler() will send back html pages with the correct title for all the different type of requests that it can handle. I think this is ready for a final review now. -- Added file: http://bugs.python.org/file19727/issue2001_f.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2001 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: [issue2001] Pydoc interactive browsing enhancement
On 11/19/2010 08:21 AM, Alexander Belopolsky wrote: Alexander Belopolskybelopol...@users.sourceforge.net added the comment: On Thu, Nov 18, 2010 at 2:37 AM, Ron Adamrep...@bugs.python.org wrote: .. I'll try reading and writing directly to the socket and working up some tests from that. I don't suppose there's something like that already in the test suite I can copy? I believe you can find relevant code in test/test_httpservers.py. Thanks I'll check it out. What I had in mind was simpler:test_pydoc already checks html output for a module, but this test did not fail after I applied your patch. When I put the old server and gui() function back the existing tests passed with changes. Which is good. Also the old tests didn't actually test the server and the tk interface. There should be something in the tests that checks that the new navigation bar is generated correctly. I'm going to work on this today. ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2001] Pydoc interactive browsing enhancement
Ron Adam ron_a...@users.sourceforge.net added the comment: I added an empty _pydoc.css file. The server does read it and you'll be able to play around with it, but don't expect it to be pretty if you do until the rest of the html is updated. Should I put that in the pydoc_data? It just needs tests now, which I'll be working on as time permits over the next few days. (And any other minor details we find.) -- Added file: http://bugs.python.org/file19644/issue2001_e.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2001 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2001] Pydoc interactive browsing enhancement
Ron Adam ron_a...@users.sourceforge.net added the comment: Here is the patch in the current state which includes the changes in issue2001_c.diff as well as most of the changes Éric suggested. Still to do: * Use the with statement in several places to ensure closing. * Add tests for the server. I did try to make the header a bit less cluttered, but I'm not completely happy with it yet, but I think it will be good enough for now. Fixing the HTML probably should be a separate issue where we can add a style sheet at the same time. Lets get this patch in first. This is also reitveld: http://codereview.appspot.com/3151042/ -- Added file: http://bugs.python.org/file19642/issue2001_d.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2001 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2001] Pydoc interactive browsing enhancement
Ron Adam ron_a...@users.sourceforge.net added the comment: I just noticed I used depreciated in place of deprecated in one of the doc strings. I can upload a new patch with that fixed. Before I do that, is there any thing else I can do? Do you agree that the browse function should be public? If not, what do we tell people to use instead of gui(), sense that will be deprecated? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2001 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10446] pydoc3 links to 2.x library reference
Ron Adam ron_a...@users.sourceforge.net added the comment: I noticed in your patch, the disclaimer only prints when pydoc can find a doc location (docloc is not None). So it may not get displayed at all depending on how python is installed. I also think having it on every page may be a bit overly cautious. (IMHO) I'm also not sure it is correct to have that when viewing third party modules as the doc location in those cases will be broken anyway. The obvious places to put it are: * top of the pydoc html module index. (first page displayed) * in the welcome message for interactive help() * help(help) * help(pydoc) It can still be defined in one location and then use + pydoc_disclaimer in the desired locations. -- nosy: +ron_adam ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10446 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2001] Pydoc interactive browsing enhancement
Ron Adam ron_a...@users.sourceforge.net added the comment: Thanks for the review Éric! The more eyes on this the better it will be. I'm not familiar with rietveld yet. But no time like the present to get started. Here's the link. http://codereview.appspot.com/3151042/ I didn't play around with the html too much. Mostly I just wanted to get it to work for now. I plan on adding support for style sheets, so a lot of the html code will be updated at that time. Alex, the version info is just what sys.version returns, that was just easy to do, we can probably trim that down a bit. The Index of Modules can be shortened to Index or Modules. I can have the get, and search box's always be two lines. Something like... Python 3.2a4/rev# Get[]Index Platform Search []Topics : Keywords -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2001 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2001] Pydoc interactive browsing enhancement
Ron Adam ron_a...@users.sourceforge.net added the comment: Sense these features reuse other parts of pydoc, they are are covered to some degree by the existing tests. An easy test would be to just start the server and then shut it down after a short timeout. Better than nothing. I'll try reading and writing directly to the socket and working up some tests from that. I don't suppose there's something like that already in the test suite I can copy? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2001 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10434] Document the rules for public names
Ron Adam ron_a...@users.sourceforge.net added the comment: You may also want to update help topics. help(PRIVATENAMES). Identifiers (Names) *** An identifier occurring as an atom is a name. See section *Identifiers and keywords* for lexical definition and section *Naming and binding* for documentation of naming and binding. When the name is bound to an object, evaluation of the atom yields that object. When a name is not bound, an attempt to evaluate it raises a ``NameError`` exception. **Private name mangling:** When an identifier that textually occurs in a class definition begins with two or more underscore characters and does not end in two or more underscores, it is considered a *private name* of that class. Private names are transformed to a longer form before code is generated for them. The transformation inserts the class name in front of the name, with leading underscores removed, and a single underscore inserted in front of the class name. For example, the identifier ``__spam`` occurring in a class named ``Ham`` will be transformed to ``_Ham__spam``. This transformation is independent of the syntactical context in which the identifier is used. If the transformed name is extremely long (longer than 255 characters), implementation defined truncation may happen. If the class name consists only of underscores, no transformation is done. Other topics that may be of interest. IDENTIFIERS NAMESPACES PACKAGES PRIVATENAMES SPECIALATTRIBUTES SPECIALIDENTIFIERS SPECIALMETHODS -- nosy: +ron_adam ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10434 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2001] Pydoc interactive browsing enhancement
Ron Adam ron_a...@users.sourceforge.net added the comment: This should be done or very close to done. The -g option, gui(), and serve() functions are deprecated. The new features are browse(port, *, open_browser=True), and a '-b' option. The '-p port' option does browse(port=port, open_browser=False), so _startserver() does not need to be part of the API. If anyone wants to access the server directly, then we can discuss making it it's own module, or a submodule in a package. Because we deprecated the gui() function, I figured we need to make browse() public. The only reason it would need to be private is if we want a different name or signature. (Any thoughts?) I left Lib/urllib/parse.py, Lib/test/test_pyclbr.py, and Lib/test/test_urlparse.py alone. I presumed you fixed bugs in them that needed to be fixed anyway. -- Added file: http://bugs.python.org/file19613/issue2001_b.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2001 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2001] Pydoc interactive browsing enhancement
Changes by Ron Adam ron_a...@users.sourceforge.net: Removed file: http://bugs.python.org/file19604/issue2001_a.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2001 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2001] Pydoc interactive browsing enhancement
Changes by Ron Adam ron_a...@users.sourceforge.net: Removed file: http://bugs.python.org/file19476/pydoc_r86133.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2001 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2001] Pydoc interactive browsing enhancement
Ron Adam ron_a...@users.sourceforge.net added the comment: Ok, here is the latest patch for review. issue2001_a.diff' I restored the pydoc.py file and then put most of the new code in these two functions, _startserver(urlhandler, port) _browse(port=0, *, open_browser=True) This creates a bettor organized file, and reduces the number of names with leading underscores. As far as I know you can't import things that are located inside a function. I still need to depreciate the '-g' option and the gui() function along with the old server parts. Is there a guide on how to depreciate things? -- Added file: http://bugs.python.org/file19604/issue2001_a.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2001 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2001] Pydoc interactive browsing enhancement
Ron Adam ron_a...@users.sourceforge.net added the comment: What about http://bugs.python.org/issue2001#msg114326 ? Thanks for the reminder. To Nick: However, the public (albeit undocumented) nature of the APIs implementing the old Tk GUI means I'm not comfortable committing the patch in a form that simply drops them without going through a deprecation period first. I think it would be ok sense this is a 'user' interface rather than a programming interface, but it won't hurt to ask specifically about this on python dev. I got the impression that pydoc is considered a 'user' tool like idle, that just happens to live in lib, so the rules aren't considered to be quite as strict as it would be if it was a module meant to be used by other modules or programs. 3. A serve() function to start the web server component should be added back in There is a _startserver() function. The leading underscore can be removed, or it can be renamed to serve. A serve() function could also just call _startserver(). 2. The gui() function should still open the Tkinter GUI, and the -g option should be retained with its old functionality. Invoking this function should trigger DeprecationWarning. 4. The new behaviour of opening the web client can be provided as a browse() function (that accepts the port number the server is listening on as an argument). After the patch the gui() function starts the server with a server text command window, and opens the browser to the correct page. If you close the browser, you can use 'b' at the server prompt to reopen the browser at the address it is serving. It sounds like you want serve() to just start the server. and browse() to just start the browser. The gui() function does both in one step. What would be the equivalent new way of doing both in one step, if gui() retains the old tk behavior? Cheers, Ron -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2001 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2001] Pydoc interactive browsing enhancement
Changes by Ron Adam ron_a...@users.sourceforge.net: Removed file: http://bugs.python.org/file16517/pydoc_gui.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2001 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2001] Pydoc interactive browsing enhancement
Changes by Ron Adam ron_a...@users.sourceforge.net: Removed file: http://bugs.python.org/file18165/pydoc_server3.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2001 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2001] Pydoc interactive browsing enhancement
Changes by Ron Adam ron_a...@users.sourceforge.net: Removed file: http://bugs.python.org/file18271/pydoc_server4.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2001 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2001] Pydoc interactive browsing enhancement
Ron Adam ron_a...@users.sourceforge.net added the comment: Here you go Nick. One file with Underscores for the new class's and functions. Where there was some overlap in names, like where some of the older server class's were reused, but don't have exactly the same behavior, I started those with underscores also. This should make it easier for you to review and/or make adjustments where it's needed. -- Added file: http://bugs.python.org/file19476/pydoc_r86133.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2001 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2001] Pydoc interactive browsing enhancement
Ron Adam ron_a...@users.sourceforge.net added the comment: Nick, I can update the patch and move the server back into pydoc.py if that will help you get this into 3.2 beta. I can also changed the docstrings of the new parts to # comments. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2001 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9319] segfault when searching modules with help()
Ron Adam ron_a...@users.sourceforge.net added the comment:
The test in the patch isn't quite right. The following still fails.
Python 3.2a3+ (py3k:85719, Oct 18 2010, 22:32:47)
[GCC 4.4.3] on linux2
Type help, copyright, credits or license for more information.
import imp
imp.find_module('test/badsyntax_pep3120')
Segmentation fault
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9319
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
