[issue13276] distutils bdist_wininst created installer does not run the postinstallation script on uninstalling
New submission from francisco : The bug can be reproduced by running the following command to create a Windows installer for the attached module: python setup.py bdist_wininst --install-script pis.py I include also the installer that I have created in the dist folder. The installer installs everything correctly and it runs the pis.py script, which simply creates a file in the USERPROFILE directory with the "Installing" string. However, when uninstalling the program from the Windows Control Panel the script is not called, what can be verified by checking that the "Uninstalling" string is not appended to the file. I am experiencing this problem in Windows 7 64 bits, but it may be present in other platforms. -- assignee: tarek components: Distutils files: foo.zip messages: 146492 nosy: eric.araujo, francisco, tarek priority: normal severity: normal status: open title: distutils bdist_wininst created installer does not run the postinstallation script on uninstalling versions: Python 2.7 Added file: http://bugs.python.org/file23536/foo.zip ___ Python tracker <http://bugs.python.org/issue13276> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13276] bdist_wininst-created installer does not run the postinstallation script when uninstalling
francisco added the comment: I believe that this bug—which I reported in 2011—is not correctly tagged, what may explain why it has not been fixed yet. Despite the fact that the original issue report contains a script to reproduce the bug and that msg148674 contains a patch to fix the issue the State of this issue is "test needed". Shouldn't State be "patch review" instead? -- type: -> behavior versions: +Python 3.6 ___ Python tracker <http://bugs.python.org/issue13276> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12412] non defined representation for pwd.struct_passwd
New submission from Francisco Garcia :
pwd.struct_passwd has different representations in cpython 2.7.2 and pypy 1.5
A unit test from cpython might enforce the same representation across
interpreters:
>>> print pwd.getpwuid(os.getuid())
Current cpython output:
pwd.struct_passwd(pw_name='demo_user', pw_passwd='', pw_uid=1001,
pw_gid=100, pw_gecos='demo_user', pw_dir='/Users/demo_user',
pw_shell='/bin/bash')
Current pypy output
('demo_user', '', 1001, 100, 'demo_user', '/Users/demo_user',
'/bin/bash')
--
messages: 139090
nosy: fgarciar
priority: normal
severity: normal
status: open
title: non defined representation for pwd.struct_passwd
type: behavior
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue12412>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44212] asyncio overrides signal handlers
New submission from Francisco Demartino : Hello, It looks like when asyncio sets up a signal handler, it forgets about the previous one (if any). Here's a patch (was about to create a PR but the default text brought me to bugs.python.org) https://github.com/franciscod/cpython/commit/bdac885b86fbb01d0d775f40c47870e48af5fa5b Tracked this down to the initial asyncio checkout, in commit 27b7c7ebf1039e96cac41b6330cf16b5632d9e49, a few commits before v3.4.0a4. Not sure if this is a bug but it surprised me. I would have expected that it registered an "additional" signal handler, or at least that my previously installed signal handler would be called afterwards. Also I'm not sure that it's a good idea to suddenly start running handlers that some current code might rely on not running, or have worked around this behaviour otherwise. Thanks, Francisco -- components: asyncio messages: 394174 nosy: Francisco Demartino, asvetlov, yselivanov priority: normal severity: normal status: open title: asyncio overrides signal handlers type: behavior versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue44212> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44212] asyncio overrides signal handlers
Francisco Demartino added the comment: Looks like Roger Dahl also noted this on https://bugs.python.org/issue39765: > Second, set_signal_handler()[sic] silently and implicitly removes > corresponding handlers set with signal.signal(). [...] I think this should > be documented as well. (then has a linked PR that apparently doesn't address this second part) -- ___ Python tracker <https://bugs.python.org/issue44212> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44212] asyncio overrides signal handlers
Change by Francisco Demartino : -- keywords: +patch pull_requests: +24904 stage: -> patch review pull_request: https://github.com/python/cpython/pull/26306 ___ Python tracker <https://bugs.python.org/issue44212> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46010] Cookie cutter templates to allow variable fields and data transfer proposal before system merge
New submission from Francisco Orozco : Not featuring templates to allow variable fields and data record creation when converting projects to new platform projects for purpose to confirm, verify record creation, might be helpful, in addition of only viewing/editing project development and structure. For purpose of data analysis, future data merging, data financial reservations or data eligibility or feasibility or recalls. -- components: Build messages: 407980 nosy: Francisco priority: normal severity: normal status: open title: Cookie cutter templates to allow variable fields and data transfer proposal before system merge type: enhancement versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46010> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21879] str.format() gives poor diagnostic on placeholder mismatch
Francisco Couzo added the comment: I'm preparing the PR myself -- ___ Python tracker <https://bugs.python.org/issue21879> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21879] str.format() gives poor diagnostic on placeholder mismatch
Change by Francisco Couzo : -- pull_requests: +12602 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issue21879> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21879] str.format() gives poor diagnostic on placeholder mismatch
Francisco Couzo added the comment: I just made the pull request, I totally forgot I mentioned I was going to work on this, sorry! -- ___ Python tracker <https://bugs.python.org/issue21879> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22102] Zipfile generates Zipfile error in zip with 0 total number of disk in Zip64 end of central directory locator
Change by Francisco Facioni : -- keywords: +patch pull_requests: +5752 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue22102> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14019] Unify tests for str.format and string.Formatter
Francisco Freire added the comment: I increased the coverage of formatter module to 40%. I added a new file "test_formatter.py" including some unit tests. -- keywords: +patch nosy: +francisco.freire Added file: http://bugs.python.org/file31202/mywork.patch ___ Python tracker <http://bugs.python.org/issue14019> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14019] Unify tests for str.format and string.Formatter
Francisco Freire added the comment: Thanks for the review. I corrected some issues in my code. Here is the new patch. -- Added file: http://bugs.python.org/file31453/mywork2.patch ___ Python tracker <http://bugs.python.org/issue14019> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14924] re.finditer() oddity
New submission from Francisco Gracia : I find baffling the following behaviour of *re.finditer()*: Python 3.2 (r32:88445, Feb 20 2011, 21:29:02) [MSC v.1500 32 bit (Intel)] on win32 Type "copyright", "credits" or "license()" for more information. >>> import re >>> m = re.finditer( '123', 'abc' ) >>> m >>> if m : 'I am Napoleon' 'I am Napoleon' No other way of formulating the condition that I have tried has worked either. Apparently *m* is always true, although all efforts to test its value indicate the contrary: >>> m == True False >>> This does not happen with any other of the related methods (*findall*, *match*, *search*), which no doubt is the correct and logical behaviour: >>> n = re.findall( '123', 'abc' ) >>> n [] >>> if n : 'I am Napoleon' >>> I have not seen any warning or explanation for this fact in the official or third party documentation that I have consulted. Perhaps it is not a bug, but, as the preceding lines show, it makes impossible to test the result of the operation and direct the subsequent program flow. If this were an unavoidable feature of *re.finditer*, it should be at least clearly exposed and, if possible, with indications of how to circumvent its undesirable consequences. Thanks for your attention and efforts. -- components: Regular Expressions messages: 161705 nosy: ezio.melotti, fgracia, mrabarnett priority: normal severity: normal status: open title: re.finditer() oddity type: behavior versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue14924> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14924] re.finditer() oddity
Francisco Gracia added the comment: Thank you both for your quick and clear explanations. However I regret that I keep considering the situation rather unsatisfactory. I can well understand that all objects are true and even that the convention that applies to some of them, like containers, that when they are empty they be considered false, does not apply to iterators; no doubt there will be good reasons for it being so. What seems illogical to me is that a method like *re.finditer()* returns as the result of its execution something that can only be interpreted as implying that what happened is exactly the contrary of what it really was. Why does it have to return anything different from the standard *None* when the match fails, like any other operation that fails? What use is in an *iterator* that leads nowhere? I would find clarifying if at least the documentation formulated unambigously that it is unwise to submit iterators (and specifically the ones returned by methods like *finditer()* whose same names imply the opposite) to logical testing and that the only valid use they have is as arguments in *for* loops. I think that the same vagorosity in this respect transpires in other places of the documentation. For instance in paragraph 7.2.5 of *re.html* it is said: Match objects always have a boolean value of *True*, so that you can test whether e. g. *match()* resulted in a match with a simple *if* statement. As it is formulated, this clause is clearly contradictory: if something points always in the same direction, it cannot be used as the basis for any decission about which of two roads to take. Match objects can very well be always true (in fact, as all objects are in this sense, as paragraph 5.1 of *stdtypes.html* comes close to formulating it); what happens is that *re.match()* or *re.search()* do not return them when they fail, but the familiar and well behaved *None* value. -- ___ Python tracker <http://bugs.python.org/issue14924> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14929] IDLE crashes on *Edit / Find in files ...* command (Python 3.2, Windows XP)
New submission from Francisco Gracia : There is little more that I can add to the title statement. 1. Start IDLE 2. Go to *Edit* menu option 3. Select *Find in files...* option 4. Put some word in the *Find* input box 5. Press *Search files* button When the command is issued the disappearance of IDLE's window is so quick that almost nothing can be seen. There is however a hint that a new window pops up with some message, that I have been unable to read. With some input strings or if the search is happening in a directory with many *.py files a quickly moving list of messages shows in this window, but the final result is the same: IDLE disappears immediately. -- components: IDLE messages: 161727 nosy: fgracia priority: normal severity: normal status: open title: IDLE crashes on *Edit / Find in files ...* command (Python 3.2, Windows XP) versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue14929> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14937] IDLE's deficiency in the completion of file names (Python 32, Windows XP)
New submission from Francisco Gracia : I find specially nice the completion feature for filenames of IDLE when they include long paths, something that is more mand more frequent with big disks and infinite amounts of files. But there is a small problem with it. If the name of any of the directories that intervene in the path to the file has any special character in it (meaning by that I suppose any non ASCII character), the completion mechanism ceases to work. For instance, if the path were: d:/Biblioteca/Técnica/informática/Python ... the cesation of the help would occur after the incorporation of *Técnica*, because its *e* is accented. There is plenty of cheap software which shows this minor deficiency, but I consider that IDLE for Python 3 should not be in that group. -- components: IDLE messages: 161795 nosy: fgracia priority: normal severity: normal status: open title: IDLE's deficiency in the completion of file names (Python 32, Windows XP) type: behavior versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue14937> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14937] IDLE's deficiency in the completion of file names (Python 32, Windows XP)
Francisco Gracia added the comment: I would be delighted, but unfortunately I am a very poor programmer and do not have the slightest idea of how all this works. -- ___ Python tracker <http://bugs.python.org/issue14937> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14937] IDLE's deficiency in the completion of file names (Python 32, Windows XP)
Francisco Gracia added the comment: Is there any necessity at all for the IDLE to test the validity of the filenames? I mean: the file specification is provided by the underlying operating system, so by definition it has to be taken as valid. Testing for its validity is superfluous and, in my opinion, a fault in the general conception of the procedure. IDLE's only role should be to present the data it receives in the best possible form and silently integrate the election made by the user. Excuse me if I speak nonsense, but I got this idea from studying *Autocomplete.py* and its dependencies. It seems to me that the difficulty resides in submitting natural language strings to the judgement of *PyParse* and *Hyperparser*, which are not competent for it because its purpose is to check the validity of Python code and Python *identifiers*. This confussion is what in my opinion causes this bug (and probably others related to the treatment of natural language text files by the IDLE, as it could also happen with issue 14929). -- ___ Python tracker <http://bugs.python.org/issue14937> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14929] IDLE crashes on *Edit / Find in files ...* command
Francisco Gracia added the comment: While your are at it, here is another suggestion: what the *Find in files ...* dialog needs most urgently in my opinion is a field for specifying clearly the directory from which the user wants to launch the search. Also in my modest opinion, having an input field for encondings would be good, although detecting the encodings of the handled files is something that any self respecting software should reliably do by itself. -- ___ Python tracker <http://bugs.python.org/issue14929> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14937] IDLE's deficiency in the completion of file names (Python 32, Windows XP)
Francisco Gracia added the comment: In my machine with Windows XP and Python 3.3.0 both variants work, the only difference being that 'c:/ brings up the selection box authomatically and 'c:\ requieres that it be summoned with the tab key, as indicated. 2012/10/12 Terry J. Reedy > > Terry J. Reedy added the comment: > > This patch (I suspect it is this one) disabled the use of '/' in filenames > on windows when using filename completion. > > 'c:\in 3.2.3 and 3.3.0> > (If there is no 'r' prefix, it really should require '\\' to be safe.) > > "c:/ ditto for 3.2.3. > In 3.3.0, (and, I presume, 3.2.4 if not changed) tab inserts spaces to > next tab stop, while ^space is ignored. > > Since using '/' is recommended over unsafe '\', this is an undesireable > regression. > > -- > resolution: fixed -> > stage: patch review -> needs patch > status: closed -> open > versions: +Python 3.3, Python 3.4 > > ___ > Python tracker > <http://bugs.python.org/issue14937> > ___ > -- ___ Python tracker <http://bugs.python.org/issue14937> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16226] IDLE crashes on *File / Path browser*
New submission from Francisco Gracia: The menu option *File / Path browser* (as well in the *Shell* window as in the *Editor* one) shows a new window with a tree structure rooted at *sys.path*. The available leaf nodes show the *plus* sign that usually implies that they can be expanded by clicking on the desired one. On the performance of this action IDLE disappears immediately. If one clicks just on the legend of the node, IDLE remains undisturbed but nothing more happens. Idle's help says: *File Menu: ... Path Browser -- Show sys.path directories, modules, classes and methods* so that apparently the expansion should also work. I suppose that this command would be mostly used at the initial phases of learning Python (at least I would have done it if I had noticed then its existence and function), but its present status does not favor such didactic purpose. Regards -- components: IDLE messages: 172863 nosy: fgracia priority: normal severity: normal status: open title: IDLE crashes on *File / Path browser* type: crash versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue16226> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16229] Module *redemo.py* lacking in recent Python distributions
New submission from Francisco Gracia: Since Python 3.2 the module *redemo.py* is lacking in the official Python distributions. The excellent and extremely useful *Regular expressions HOWTO* of 3.2.x and 3.3 keep however referring to it (although referring to the wrong path *Tools/demo/* instead of *Tools/Scripts/*) and the same does the *README* file. I just copied the version of the module distributed with 3.1 and it keeps working as well with 3.2.x as with 3.3.0 without having experienced any problems. Is there any justification for this situation or is it just a slip? Regards -- components: Demos and Tools messages: 172868 nosy: fgracia priority: normal severity: normal status: open title: Module *redemo.py* lacking in recent Python distributions versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue16229> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16233] IDLE: conceptual problems with *Class browser*
New submission from Francisco Gracia: The *File* option in the menu bar of both the Python shell and the program editor have an entry called *Class Browser*. If one selects it from the shell window, one gets always an error message with the title: "No filename" which says: "This buffer has no associated filename". This happens whatever the previous history of the current interactive session. If one selects it from the editor window with a Python module loaded, then another window shows correctly the expected information about the classes defined in such a module, if any. The same previous error appears if the current contents of the editor are not recognised as a Python module (for instance by not having been yet saved), which is reasonable. IDLE's help says: "Class Browser-- Show classes and methods in current file". This does not clarify things much (what does *current file* mean from the shell window?) and does not permit one to get a coherent idea of the purpose originally intended for the option (a module imported in the current interactive session could not be rightly understood as a *current file*?). I find this situation quite confuse and would suggest that some action could be taken in order to at least clarify it, if not improve it, as for instance (in order of desirability and --very likely-- difficulty): - Just make the error message less puzzling and more informative when coming from the shell window (what does *buffer* mean in this context?) and let the help file explain that this operation has only sense in connection with Python scripts being edited (if that is the case, as it seems). - Disable the option in the shell window. - Suppress the option in the shell window and keep it only in the editor window when the document it is handling is recognised as a Python module. - Keep the option also in the shell window and make it display information about the classes defined in the namespace of the current interactive session, if any. I think that this is what would be a real and useful *class browser*. Thank you in advance for your attention. -- components: IDLE messages: 172891 nosy: fgracia priority: normal severity: normal status: open title: IDLE: conceptual problems with *Class browser* type: enhancement versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue16233> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16229] Module *redemo.py* lacking in recent Python distributions
Francisco Gracia added the comment: You are right. I am referring to the Windows installer. I forgot to mention that I am using Windows XP. Thank you. 2012/10/14 Ned Deily > > Ned Deily added the comment: > > The demo scripts in the Tools directory were cleaned up earlier in Python > 3 and moved. redemo.py is still included in the 3.2 and later source > distributions in the Tools/demo directory. The builders of binary > installers and third-party distributors of Python 3.x may make their own > decisions about whether to include the Tools directory in their distros. > For which platform and from what source are you installing Python 3.2? > > -- > nosy: +ned.deily > > ___ > Python tracker > <http://bugs.python.org/issue16229> > ___ > -- title: File *redemo.py* lacking in recent Python distributions -> Module *redemo.py* lacking in recent Python distributions ___ Python tracker <http://bugs.python.org/issue16229> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21450] [Issue 13630] IDLE: Find(ed) text is not highlighted while dialog box is open
New submission from Francisco Gracia: I was delighted with the behaviour of IDLE in version 3.4 until I noticed the problem of the matches with the non highlighted background in the modified (and in this sense improved) iterative text search operations. I was wondering how could this be possible at all in the present luxuriant stage of Python's evolution when now I see that this is a very old and probably cronic problem! What a pity! I have tried to test your *SearchBar* extension, Tal, but, after following the installation instructions of the *README* file, no bar appears at all in the editor window as well in version 3.3 as in 3.4 (WIndows7). As the process is not that difficult, I think that I am performing it correctly. Any idea of what can be wrong in spite of it? Thanks. -- messages: 218057 nosy: fgracia priority: normal severity: normal status: open title: [Issue 13630] IDLE: Find(ed) text is not highlighted while dialog box is open ___ Python tracker <http://bugs.python.org/issue21450> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13630] IDLE: Find(ed) text is not highlighted while dialog box is open
Francisco Gracia added the comment: I had problems for installing your *SearchBar*, Tal, in Python 33 and 34 until it downed onto me that in its present form it is only Python 2 compliant. This is then its first weakness, that of course can be easily remedied by applying *2to3.py* to it, as I did. I am using Windows 7. Another fault is that when IDLE's editor window is expanded to full screen the bar's widget fills half of it. I imagine that this should not be difficult to mend either. If you would be interested in suggestions for your revision, mine would be that the option controls of the *Find* searchbar be disposed in two rows. This would avoid a certain clutter and allow the addition of a new one that, if possible, I would find convenient. It would perform the toggling of the simultaneous highlighting of all the matches of the search, something that is handy in some situations but can be confusing in others. These are the only quirks that I have observed until now. I think that *SearchBar* is a must for anyone that uses IDLE's editor in 3.4 or in any previous version of Python (as I have discovered here that the problem is an old one) and am surprised that it does not belong to the standard distribution since it was available. Thanks and congratulations for your excellent job. -- ___ Python tracker <http://bugs.python.org/issue13630> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13630] IDLE: Find(ed) text is not highlighted while dialog box is open
Francisco Gracia added the comment: The neat program *redemo.py* toggles between *Highlight first match* and *Highlight all matches*. -- ___ Python tracker <http://bugs.python.org/issue13630> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14019] Unify tests for str.format and string.Formatter
Francisco Freire added the comment: Hi, I signed the contributor agreement. Thank you for your review comments. I did these tests about one year ago and right now I don't have much time to look at it again. I hope to do so in the next months. -- status: pending -> open ___ Python tracker <http://bugs.python.org/issue14019> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29630] REPL tab-completion triggers code execution
New submission from Francisco Demartino: On the REPL, when autocompleting with the TAB key, getattr is called, potentially triggering code execution. This took me by surprise. Until you press RETURN, it should be pretty safe to go around autocompleting with certainty that you won't run any code. But that might be just my opinion. What do you think? -- components: Interpreter Core files: wat.py messages: 288420 nosy: Francisco Demartino priority: normal severity: normal status: open title: REPL tab-completion triggers code execution versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file46662/wat.py ___ Python tracker <http://bugs.python.org/issue29630> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29630] REPL tab-completion triggers code execution
Francisco Demartino added the comment: This branch (working on the PR) fixes it: https://github.com/franciscod/cpython/tree/bpo-29630 -- ___ Python tracker <http://bugs.python.org/issue29630> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29630] REPL tab-completion triggers code execution
Changes by Francisco Demartino : -- pull_requests: +213 status: pending -> open ___ Python tracker <http://bugs.python.org/issue29630> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29630] REPL tab-completion triggers code execution
Francisco Demartino added the comment: I've updated that branch and made a pull request (https://github.com/python/cpython/pull/248) I think this is a good compromise: inspect.getattr_static can tell if it's a property, and in that case we don't call getattr on it to prevent code execution on the completion. If it isn't a property, the current codepath is preserved. -- ___ Python tracker <http://bugs.python.org/issue29630> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29630] REPL tab-completion triggers code execution
Francisco Demartino added the comment: > There is no way to safely inspect any Python object without triggering some > dunder functions like __getattr__, __getattribute__ or __dir__. But somehow inspect.getattr_static can do it? > Your change is not backwards compatible and makes auto-completion less useful. Why is it less useful? The only change is not executing property getters when showing completion options. It's removing a surprising code execution before the newline is received. Should CPython keep backwards compatibility of this execution-on-completion at the REPL? -- ___ Python tracker <http://bugs.python.org/issue29630> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29630] REPL tab-completion triggers code execution
Francisco Demartino added the comment: Serhiy, Chris, thank you for your additional comments. They surely helped me understand why my solution to this "problem?" isn't that good (also I slept on it a bit and maybe that helped). I still ponder for a way to get autocompletion while guarranteeing no code will run, but a) any getter code is meant to run in that way, and b) it would somehow need to know the result of running that code without running it (Tricky, huh?). Thanks again for your patience. I feel enlightened :) -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue29630> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27427] Math tests
New submission from Francisco Couzo: I added some tests for the math module. -- components: Tests files: test_math.patch keywords: patch messages: 269632 nosy: franciscouzo priority: normal severity: normal status: open title: Math tests versions: Python 3.6 Added file: http://bugs.python.org/file43593/test_math.patch ___ Python tracker <http://bugs.python.org/issue27427> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26830] Refactor Tools/scripts/google.py
Changes by Francisco Couzo : -- files: scripts_google.patch keywords: patch nosy: franciscouzo priority: normal severity: normal status: open title: Refactor Tools/scripts/google.py type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file42572/scripts_google.patch ___ Python tracker <http://bugs.python.org/issue26830> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26830] Refactor Tools/scripts/google.py
Francisco Couzo added the comment: I was also going to refactor the other demo scripts, but first I wanted to make sure there was at least some kind of interest in it. -- ___ Python tracker <http://bugs.python.org/issue26830> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26830] Refactor Tools/scripts/google.py
Francisco Couzo added the comment: Here's the patch with the modifications from the review. -- Added file: http://bugs.python.org/file42657/scripts_google_v2.patch ___ Python tracker <http://bugs.python.org/issue26830> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21879] str.format() gives poor diagnostic on placeholder mismatch
Changes by Francisco Couzo : -- keywords: +patch Added file: http://bugs.python.org/file44490/format.patch ___ Python tracker <http://bugs.python.org/issue21879> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21879] str.format() gives poor diagnostic on placeholder mismatch
Changes by Francisco Couzo : -- nosy: +franciscouzo ___ Python tracker <http://bugs.python.org/issue21879> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28139] Misleading Indentation
New submission from Francisco Couzo: Fixed the warnings that appear when compiling 2.7 with -Wmisleading-indentation (Included in -Wall since GCC 6). Kinda related, though I don't think there would be too much interest in fixing it (all the tabs in Python's C source): $ find . -name '*.c' -print0 | xargs -0 grep -R $'\t' | wc -l 10407 -- files: misleading_indentation.patch keywords: patch messages: 276367 nosy: franciscouzo priority: normal severity: normal status: open title: Misleading Indentation versions: Python 2.7 Added file: http://bugs.python.org/file44645/misleading_indentation.patch ___ Python tracker <http://bugs.python.org/issue28139> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26830] Refactor Tools/scripts/google.py
Changes by Francisco Couzo : Added file: http://bugs.python.org/file44652/scripts_google_v4.patch ___ Python tracker <http://bugs.python.org/issue26830> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28145] Fix whitespace in C source code
New submission from Francisco Couzo: I changed most of the tabs in the source code to spaces, and removed trailing whitespace. I also made some scripts that generate code use spaces and not generate trailing whitespace. (makesetup and makeunicodedata.py) I fixed a typo in Modules/makesetup (I don't know if I should open another issue, if so please tell me) I think by changing line Tools/unicode/makeunicodedata.py:1260 to file.write(s.strip() + "\n") the trailing whitespace in unicodename_db.h and unicodedata_db.h would be fixed, but I didn't put that change in the patch because I couldn't test it. I couldn't find where Parser/asdl_c.py is generating the trailing spaces for Python-ast.h -- files: fix_whitespace.patch keywords: patch messages: 276414 nosy: franciscouzo priority: normal severity: normal status: open title: Fix whitespace in C source code versions: Python 3.7 Added file: http://bugs.python.org/file44657/fix_whitespace.patch ___ Python tracker <http://bugs.python.org/issue28145> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27482] heap-buffer-overflow on address 0x6250000078ff
Francisco Couzo added the comment: I can confirm this bug is also present in 3.7 -- nosy: +franciscouzo versions: +Python 3.7 ___ Python tracker <http://bugs.python.org/issue27482> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28169] shift exponent overflow
New submission from Francisco Couzo: Steps to reproduce: make distclean LDFLAGS="-lasan -lubsan" CFLAGS="-fsanitize=address -fsanitize=undefined" ./configure ASAN_OPTIONS="detect_leaks=0" make UBSAN_OPTIONS=print_stacktrace=1 ASAN_OPTIONS="allocator_may_return_null=1:detect_leaks=0" ./python -m test.test_ctypes /home/fran/code/cpython/Modules/_ctypes/cfield.c:580:5: runtime error: shift exponent 18446744073709551614 is too large for 32-bit type 'int' #0 0x7fb4b3d3f6f6 in h_get /home/fran/code/cpython/Modules/_ctypes/cfield.c:580 #1 0x6fc95b in _PyObject_GenericGetAttrWithDict Objects/object.c:1060 #2 0x6fc95b in PyObject_GenericGetAttr Objects/object.c:1121 #3 0x9330a0 in builtin_getattr Python/bltinmodule.c:985 #4 0x6e7d20 in _PyCFunction_FastCallDict Objects/methodobject.c:234 #5 0x6e7d20 in _PyCFunction_FastCallKeywords Objects/methodobject.c:295 #6 0x944cfc in call_function Python/ceval.c:4763 #7 0x95a0f4 in _PyEval_EvalFrameDefault Python/ceval.c:3250 #8 0x9407f0 in PyEval_EvalFrameEx Python/ceval.c:718 #9 0x9407f0 in _PyFunction_FastCall Python/ceval.c:4845 #10 0x945235 in fast_function Python/ceval.c:4880 #11 0x945235 in call_function Python/ceval.c:4784 #12 0x95a0f4 in _PyEval_EvalFrameDefault Python/ceval.c:3250 #13 0x94292f in PyEval_EvalFrameEx Python/ceval.c:718 #14 0x94292f in _PyEval_EvalCodeWithName Python/ceval.c:4094 #15 0x9780b8 in _PyFunction_FastCallDict Python/ceval.c:4996 #16 0x5132d7 in _PyObject_FastCallDict Objects/abstract.c:2297 #17 0x513904 in _PyObject_Call_Prepend Objects/abstract.c:2360 #18 0x5125ba in PyObject_Call Objects/abstract.c:2248 #19 0x957bb0 in do_call_core Python/ceval.c:5032 #20 0x957bb0 in _PyEval_EvalFrameDefault Python/ceval.c:3332 #21 0x94292f in PyEval_EvalFrameEx Python/ceval.c:718 #22 0x94292f in _PyEval_EvalCodeWithName Python/ceval.c:4094 #23 0x9780b8 in _PyFunction_FastCallDict Python/ceval.c:4996 #24 0x5132d7 in _PyObject_FastCallDict Objects/abstract.c:2297 #25 0x513904 in _PyObject_Call_Prepend Objects/abstract.c:2360 #26 0x5125ba in PyObject_Call Objects/abstract.c:2248 #27 0x766761 in slot_tp_call Objects/typeobject.c:6146 #28 0x5130b6 in _PyObject_FastCallDict Objects/abstract.c:2318 #29 0x944103 in call_function Python/ceval.c:4787 #30 0x95a0f4 in _PyEval_EvalFrameDefault Python/ceval.c:3250 #31 0x94292f in PyEval_EvalFrameEx Python/ceval.c:718 #32 0x94292f in _PyEval_EvalCodeWithName Python/ceval.c:4094 #33 0x9780b8 in _PyFunction_FastCallDict Python/ceval.c:4996 #34 0x5132d7 in _PyObject_FastCallDict Objects/abstract.c:2297 #35 0x513904 in _PyObject_Call_Prepend Objects/abstract.c:2360 #36 0x5125ba in PyObject_Call Objects/abstract.c:2248 #37 0x957bb0 in do_call_core Python/ceval.c:5032 #38 0x957bb0 in _PyEval_EvalFrameDefault Python/ceval.c:3332 #39 0x94292f in PyEval_EvalFrameEx Python/ceval.c:718 #40 0x94292f in _PyEval_EvalCodeWithName Python/ceval.c:4094 #41 0x9780b8 in _PyFunction_FastCallDict Python/ceval.c:4996 #42 0x5132d7 in _PyObject_FastCallDict Objects/abstract.c:2297 #43 0x513904 in _PyObject_Call_Prepend Objects/abstract.c:2360 #44 0x5125ba in PyObject_Call Objects/abstract.c:2248 #45 0x766761 in slot_tp_call Objects/typeobject.c:6146 #46 0x5130b6 in _PyObject_FastCallDict Objects/abstract.c:2318 #47 0x944103 in call_function Python/ceval.c:4787 #48 0x95a0f4 in _PyEval_EvalFrameDefault Python/ceval.c:3250 #49 0x94292f in PyEval_EvalFrameEx Python/ceval.c:718 #50 0x94292f in _PyEval_EvalCodeWithName Python/ceval.c:4094 #51 0x9780b8 in _PyFunction_FastCallDict Python/ceval.c:4996 #52 0x5132d7 in _PyObject_FastCallDict Objects/abstract.c:2297 #53 0x513904 in _PyObject_Call_Prepend Objects/abstract.c:2360 #54 0x5125ba in PyObject_Call Objects/abstract.c:2248 #55 0x957bb0 in do_call_core Python/ceval.c:5032 #56 0x957bb0 in _PyEval_EvalFrameDefault Python/ceval.c:3332 #57 0x94292f in PyEval_EvalFrameEx Python/ceval.c:718 #58 0x94292f in _PyEval_EvalCodeWithName Python/ceval.c:4094 #59 0x9780b8 in _PyFunction_FastCallDict Python/ceval.c:4996 #60 0x5132d7 in _PyObject_FastCallDict Objects/abstract.c:2297 #61 0x513904 in _PyObject_Call_Prepend Objects/abstract.c:2360 #62 0x5125ba in PyObject_Call Objects/abstract.c:2248 #63 0x766761 in slot_tp_call Objects/typeobject.c:6146 #64 0x5130b6 in _PyObject_FastCallDict Objects/abstract.c:2318 #65 0x944103 in call_function Python/ceval.c:4787 #66 0x95a0f4 in _PyEval_EvalFrameDefault Python/ceval.c:3250 #67 0x94292f in PyEval_EvalFrameEx Python/ceval.c:718 #68 0x94292f in _PyEval_EvalCodeWithName Python/ceval.c:4094 #69 0x9780b8 in _PyFunction_FastCallDict Python/ceval.c:4996 #70 0x5132d7 in _PyObject_FastCallDict Objects/abstract.c:2297 #71 0x513904
[issue28184] Trailing whitespace in C source code
New submission from Francisco Couzo: As per Terry's recommendations (#28145), I'm going to open a new issue for each case. -- files: trailing_whitespace.patch keywords: patch messages: 276761 nosy: franciscouzo, josh.r, mark.dickinson, martin.panter, r.david.murray, terry.reedy priority: normal severity: normal status: open title: Trailing whitespace in C source code versions: Python 3.7 Added file: http://bugs.python.org/file44701/trailing_whitespace.patch ___ Python tracker <http://bugs.python.org/issue28184> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28185] Tabs in C source code
New submission from Francisco Couzo: Files I didn't change: Python/dup2.c, Python/strdup.c (Since they are external dependencies) -- files: tabs_c.patch keywords: patch messages: 276762 nosy: franciscouzo, josh.r, mark.dickinson, martin.panter, r.david.murray, terry.reedy priority: normal severity: normal status: open title: Tabs in C source code Added file: http://bugs.python.org/file44702/tabs_c.patch ___ Python tracker <http://bugs.python.org/issue28185> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28185] Tabs in C source code
Changes by Francisco Couzo : -- versions: +Python 3.7 Added file: http://bugs.python.org/file44703/tabs_h.patch ___ Python tracker <http://bugs.python.org/issue28185> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28185] Tabs in C source code
Changes by Francisco Couzo : Removed file: http://bugs.python.org/file44703/tabs_h.patch ___ Python tracker <http://bugs.python.org/issue28185> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28185] Tabs in C source code
Changes by Francisco Couzo : Added file: http://bugs.python.org/file44704/tabs_h.patch ___ Python tracker <http://bugs.python.org/issue28185> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28184] Trailing whitespace in C source code
Changes by Francisco Couzo : Added file: http://bugs.python.org/file44706/trailing_whitespace2.patch ___ Python tracker <http://bugs.python.org/issue28184> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28186] Autogenerated tabs / trailing whitespace
New submission from Francisco Couzo: Fix some auto generated whitespace issues (tabs and trailing whitespace) -- files: autogenerated_whitespace.patch keywords: patch messages: 276774 nosy: franciscouzo priority: normal severity: normal status: open title: Autogenerated tabs / trailing whitespace versions: Python 3.7 Added file: http://bugs.python.org/file44707/autogenerated_whitespace.patch ___ Python tracker <http://bugs.python.org/issue28186> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28186] Autogenerated tabs / trailing whitespace
Changes by Francisco Couzo : Added file: http://bugs.python.org/file44709/autogenerated_whitespace2.patch ___ Python tracker <http://bugs.python.org/issue28186> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28145] Fix whitespace in C source code
Francisco Couzo added the comment: I'm closing this issue since I've created new issues for each case, please refer to #28184, #28185, and #28186. -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue28145> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28186] Autogenerated tabs / trailing whitespace
Changes by Francisco Couzo : Removed file: http://bugs.python.org/file44707/autogenerated_whitespace.patch ___ Python tracker <http://bugs.python.org/issue28186> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28475] Misleading error on random.sample when k < 0
New submission from Francisco Couzo: Improved a bit the error message when k < 0, and also added a comment about it on the documentation and an additional test case. -- assignee: docs@python components: Documentation, Library (Lib), Tests files: random_sample.patch keywords: patch messages: 278964 nosy: docs@python, franciscouzo priority: normal severity: normal status: open title: Misleading error on random.sample when k < 0 Added file: http://bugs.python.org/file45141/random_sample.patch ___ Python tracker <http://bugs.python.org/issue28475> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28476] Remove redundant definition of factorial on test_random
Changes by Francisco Couzo : -- components: Tests files: test_random.patch keywords: patch nosy: franciscouzo priority: normal severity: normal status: open title: Remove redundant definition of factorial on test_random Added file: http://bugs.python.org/file45142/test_random.patch ___ Python tracker <http://bugs.python.org/issue28476> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28475] Misleading error on random.sample when k < 0
Changes by Francisco Couzo : Added file: http://bugs.python.org/file45144/random_sample2.patch ___ Python tracker <http://bugs.python.org/issue28475> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28540] math.degrees(sys.float_info.max) should throw an OverflowError exception
New submission from Francisco Couzo: Most functions in the math library raise an OverflowError when the arguments are finite but the result is not. >>> math.exp(sys.float_info.max) Traceback (most recent call last): File "", line 1, in OverflowError: math range error >>> math.degrees(sys.float_info.max) inf -- messages: 279513 nosy: franciscouzo priority: normal severity: normal status: open title: math.degrees(sys.float_info.max) should throw an OverflowError exception ___ Python tracker <http://bugs.python.org/issue28540> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28593] Inconsistent itertools' predicate behaviour
New submission from Francisco Couzo: As per Terry's recommendation https://mail.python.org/pipermail/python-dev/2016-November/146791.html Currently some functions in itertools (dropwhile and takewhile), don't accept None as a predicate, but filterfalse and groupby do. I'd like your input, and I'm interested in writing a patch. -- messages: 279960 nosy: franciscouzo, rhettinger priority: normal severity: normal status: open title: Inconsistent itertools' predicate behaviour type: enhancement ___ Python tracker <http://bugs.python.org/issue28593> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28593] Inconsistent itertools' predicate behaviour
Francisco Couzo added the comment: I think removing None as a valid predicate to filterfalse would make the API simpler, but I don't know if it's worth the API change, please do close the issue if you think it's not worth it. -- ___ Python tracker <http://bugs.python.org/issue28593> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13117] Broken links in the “compiler” page, section “references” from the devguide.
New submission from Francisco Martín Brugué : Hi, In the page http://docs.python.org/devguide/compiler.html the links in the references [1] (http://www.foretec.com/python/workshops/1998-11/proceedings/papers/montanaro/montanaro.html) and in [Wang97] (http://www.cs.princeton.edu/%7Edanwang/Papers/dsl97/dsl97.html) are broken. Cheers, francis -- components: Devguide messages: 145030 nosy: francismb priority: normal severity: normal status: open title: Broken links in the “compiler” page, section “references” from the devguide. ___ Python tracker <http://bugs.python.org/issue13117> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13117] Broken links in the “compiler” page, section “references” from the devguide.
Francisco Martín Brugué added the comment: The reference for [1] could be changed to: http://www.python.org/workshops/1998-11/proceedings/papers/montanaro/montanaro.html -- ___ Python tracker <http://bugs.python.org/issue13117> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13117] Broken links in the “compiler” page, section “references” from the devguide.
Francisco Martín Brugué added the comment: The reference to [Wang97] could be changed to: http://www.cs.princeton.edu/research/techreps/TR-554-97 -- ___ Python tracker <http://bugs.python.org/issue13117> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13117] Broken links in the “compiler” page, section “references” from the devguide.
Francisco Martín Brugué added the comment: A patch with the links mentioned above. -- keywords: +patch Added file: http://bugs.python.org/file23329/issue13117.patch ___ Python tracker <http://bugs.python.org/issue13117> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12659] Add tests for packaging.tests.support
Francisco Martín Brugué added the comment: The patch is updated. Let me know if I've understood your review. Thanks ! -- Added file: http://bugs.python.org/file23370/issue12659_v3.patch ___ Python tracker <http://bugs.python.org/issue12659> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12659] Add tests for packaging.tests.support
Francisco Martín Brugué added the comment: Hi Éric, Nice! and thanks for the info: I was just waiting to the check-in to compare and try further with the tests. Now I can just commit another patch by synching against the actual tip. Cheers, francis -- ___ Python tracker <http://bugs.python.org/issue12659> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13193] test_packaging and test_distutils failures
Francisco Martín Brugué added the comment: Hi Eli, I cannot find the file/Distro: find / -name *'dist-info' 2> /dev/null /home/ci/cpython/Lib/packaging/tests/fake_dists/grammar-1.0a4.dist-info /home/ci/cpython/Lib/packaging/tests/fake_dists/towel_stuff-0.1.dist-info /home/ci/cpython/Lib/packaging/tests/fake_dists/babar-0.1.dist-info /home/ci/cpython/Lib/packaging/tests/fake_dists/choxie-2.0.0.9.dist-info /home/ci/cpython/.hg/store/data/_lib/packaging/tests/fake__dists/grammar-1.0a4.dist-info /home/ci/cpython/.hg/store/data/_lib/packaging/tests/fake__dists/babar-0.1.dist-info /home/ci/cpython/.hg/store/data/_lib/packaging/tests/fake__dists/towel__stuff-0.1.dist-info /home/ci/cpython/.hg/store/data/_lib/packaging/tests/fake__dists/choxie-2.0.0.9.dist-info Where should be the distro? Cheers, francis -- nosy: +francismb ___ Python tracker <http://bugs.python.org/issue13193> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13193] test_packaging and test_distutils failures
Francisco Martín Brugué added the comment: The changeset was: $ hg tip changeset: 73075:d4839fea4a5a [...] -- ___ Python tracker <http://bugs.python.org/issue13193> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13193] test_packaging and test_distutils failures
Francisco Martín Brugué added the comment: > >> Where should be the distro? > > You won't find it in the hg repository - it gets created by the test, and > then deleted afterwards. Thanks for the info > >> The changeset was: >> $ hg tip >> changeset: 73075:d4839fea4a5a >> [...] > > That's not possible - these failures have been around for over a week now, > and that changeset was only committed yesterday. > Thanks again, next time I'll search the exact start point of failure in the repo. I've just put the ref to MY actual tip ;) -- ___ Python tracker <http://bugs.python.org/issue13193> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12659] Add tests for packaging.tests.support
Francisco Martín Brugué added the comment: Hi Éric, I've mutated test_support.py a bit and now passes in https://bitbucket.org/tarek/distutils2 changeset:6c3d67ed3adb. I've added runTest to Tester, used os.unlink also removed the test fake_dec test as in support.py from distutils2 version is not present. Best regards, Francis -- Added file: http://bugs.python.org/file23687/test_support_v1.py ___ Python tracker <http://bugs.python.org/issue12659> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12185] Decimal documentation lists "first" and "second" arguments, should be "self" and "other"
Francisco Martín Brugué added the comment: Hi all, that is my first contribution. Please let me know if all it's OK. Thanks in advance ! -- keywords: +patch nosy: +francismb Added file: http://bugs.python.org/file8/issue_12185.patch ___ Python tracker <http://bugs.python.org/issue12185> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12185] Decimal documentation lists "first" and "second" arguments, should be "self" and "other"
Francisco Martín Brugué added the comment: Hi Adam, I couldn’t see that from the threat context, I'm new to this and just wanted to learn the work flow and tools so I've just picked up an easy issue to start with. Anyway your patch seems more complete. -- ___ Python tracker <http://bugs.python.org/issue12185> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10206] python program starting with unmatched quote spews spaces to stdout
Francisco Martín Brugué added the comment:
I've attached an alternative test case.
I'm not sure if there is a more robust way to test:
self.assert_('SyntaxError' in err.decode('ascii', 'ignore'))
Due the use of 'SyntaxtError' directly as string. I would prefer something like
str(SyntaxtError) (or just the name of the exception
without extra text)
Review is welcome
--
nosy: +francismb
Added file: http://bugs.python.org/file22441/issue10206.patch
___
Python tracker
<http://bugs.python.org/issue10206>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10206] python program starting with unmatched quote spews spaces to stdout
Francisco Martín Brugué added the comment: Just attaching the review patch -- Added file: http://bugs.python.org/file22443/issue10206v2.patch ___ Python tracker <http://bugs.python.org/issue10206> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10206] python program starting with unmatched quote spews spaces to stdout
Francisco Martín Brugué added the comment:
On 06/24/2011 06:07 PM, R. David Murray wrote:
> self.assertRegex(err.decode('ascii', 'ignore'), 'SyntaxError')
I understand that's the standard way to check if a given failure
happened in the command line or there is also a helper for that case
(maybe something: assert_python_raises('-c', "'", SyntaxError))
Thanks !
Francisco
--
___
Python tracker
<http://bugs.python.org/issue10206>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2259] Poor support other than 44.1khz, 16bit audio files?
Francisco Martín Brugué added the comment: Adding a test that opens the 24b48k.aif file, gets some information and does navigation on it. I'm aware that it doesn't triggers any extra failure against the actual tip (5a1bb8d4afd7) but it does if r72100 is undone (with some small rework :)). I'm not sure if that is the kind of test needed (if not just ignore it). -- nosy: +francismb Added file: http://bugs.python.org/file22688/test_issue2259.patch ___ Python tracker <http://bugs.python.org/issue2259> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12659] Add tests for packaging.tests.support
Francisco Martín Brugué added the comment: I've started with test for “fake_dec” and “TempdirManager”. Please let me know if that in the line you want. Thanks in advance Francis -- keywords: +patch nosy: +francismb Added file: http://bugs.python.org/file22895/issue12659_v1.patch ___ Python tracker <http://bugs.python.org/issue12659> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12659] Add tests for packaging.tests.support
Francisco Martín Brugué added the comment: Hi Éric, sorry but I've not received that email. Could you simply paste/send me the link (I've not used Rietveld already and I can not to find that review). Thanks ! -- ___ Python tracker <http://bugs.python.org/issue12659> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12659] Add tests for packaging.tests.support
Francisco Martín Brugué added the comment: I've updated the patch. From your review: the class 'Mixin' is still there as the idea was to imitate the use of 'TempdirManager' as is used in the rest of the tests and test what it's documentation says. Just let me know your preferences here. Thank in advance ! -- Added file: http://bugs.python.org/file23116/issue12659_v2.patch ___ Python tracker <http://bugs.python.org/issue12659> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12659] Add tests for packaging.tests.support
Francisco Martín Brugué added the comment: I've just updated “test_support.py” and tested against 'default' and 'distutils2' (after changing the imports). Just let me know what has to be changed ... BTW: in distutils2 I get (not because of this change): == FAIL: test_bad_urls (distutils2.tests.test_pypi_simple.SimpleCrawlerTestCase) -- Traceback (most recent call last): File "/home/ci/prog/cpython/distutils2/distutils2/tests/pypi_server.py", line 68, in wrapped func(server=server, *args, **kwargs) File "/home/ci/prog/cpython/distutils2/distutils2/tests/test_pypi_simple.py", line 93, in test_bad_urls self.assertIn(wanted, str(v)) AssertionError: 'nonnumeric port' not found in 'Download error for http://http://svn.pythonpaste.org/Paste/wphp/trunk: [Errno -2] Name or service not known' -- Cheers, francis -- Added file: http://bugs.python.org/file24440/test_support_v2.py ___ Python tracker <http://bugs.python.org/issue12659> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13953] test_packaging: unused test?
Changes by Francisco Martín Brugué : -- nosy: +francismb ___ Python tracker <http://bugs.python.org/issue13953> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12659] Add tests for packaging.tests.support
Francisco Martín Brugué added the comment: > If so, could you provide a patch this time? Done. The patch is against default. what about against distutils2? Do you need also a patch for it? -- Added file: http://bugs.python.org/file24458/issue12659_58bd6a58365d.patch ___ Python tracker <http://bugs.python.org/issue12659> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13953] Get rid of doctests in packaging.tests.test_version
Francisco Martín Brugué added the comment: Hi here's a patch preview: it has to be re factored further but I stopped here as some tests failed: the out commented ones ... I've checked twice but I cannot see any diff, could you check that? Or, has maybe the behavior (due that bug) changed and nobody noticed? Thanks in advance ! Francis -- keywords: +patch Added file: http://bugs.python.org/file24459/issue13953_58bd6a58365d.patch ___ Python tracker <http://bugs.python.org/issue13953> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13953] Get rid of doctests in packaging.tests.test_version
Francisco Martín Brugué added the comment: I've done some cleanups -- Added file: http://bugs.python.org/file24471/issue13953_bf6f306ad5cf.patch ___ Python tracker <http://bugs.python.org/issue13953> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13990] Benchmarks: 2to3 failures on the py3 side
New submission from Francisco Martín Brugué : Steps to reproduce: after following the usage instructions from make_perf3.sh go to the the py3 benchmarks directory and run the lib/2to3 tests (python3.2 test.py). The result are 3 failures and 17 errors. The equivalent procedure in the py2 benchmarks directory succeeds (python2.7 test.py). A summary is attached (the whole paste at http://pastebin.com/PAAhGsdR) Cheers, francis -- assignee: collinwinter components: 2to3 (2.x to 3.x conversion tool), Benchmarks files: FailuresErrors.txt messages: 153069 nosy: collinwinter, francismb priority: normal severity: normal status: open title: Benchmarks: 2to3 failures on the py3 side versions: Python 3.2 Added file: http://bugs.python.org/file24477/FailuresErrors.txt ___ Python tracker <http://bugs.python.org/issue13990> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13953] Get rid of doctests in packaging.tests.test_version
Francisco Martín Brugué added the comment: Thank you for the review. Just some questions: Isn't that what the previous code (doctest code) did? I thought that the code should be ported as far backwards as possible and that's why I used the plain assertEqual (I don't know exactly in with version the other assert methods were introduced. Unittest2?) Can one use all the new unittest2 methods to test packaging (distutils2) code? > -- > Added file: http://bugs.python.org/file24482/cleanup-test_version.diff > > ___ > Python tracker > <http://bugs.python.org/issue13953> > ___ > -- ___ Python tracker <http://bugs.python.org/issue13953> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12659] Add tests for packaging.tests.support
Francisco Martín Brugué added the comment: On 02/11/2012 05:59 AM, Éric Araujo wrote: >> BTW: in distutils2 I get (not because of this change): > Actually I did fix that, but depending on your Python version the conditional > in the test may be wrong. What’s the Python version you used? I did: python2.7 runtests.py The exact version is: python2.7 -V --> Python 2.7.2+ and the machine is a Debian: uname -a --> Linux random 3.1.0-1-amd64 #1 SMP Tue Jan 10 05:01:58 UTC 2012 x86_64 GNU/Linux Thanks for your time as mentor! -- ___ Python tracker <http://bugs.python.org/issue12659> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13953] Get rid of doctests in packaging.tests.test_version
Francisco Martín Brugué added the comment: Does a "doc test" test the output literally? (I've just always used unittest) Ok, thanks -- ___ Python tracker <http://bugs.python.org/issue13953> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13579] string.Formatter doesn't understand the !a conversion specifier
Francisco Martín Brugué added the comment: Hi, here's a patch with the changes proposed by Terry Cheers, francis -- keywords: +patch nosy: +francismb Added file: http://bugs.python.org/file24512/issue13579_80a50b7ad88f.patch ___ Python tracker <http://bugs.python.org/issue13579> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14019] Unify tests for str.format and string.Formatter
Changes by Francisco Martín Brugué : -- nosy: +francismb ___ Python tracker <http://bugs.python.org/issue14019> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13579] string.Formatter doesn't understand the !a conversion specifier
Francisco Martín Brugué added the comment: I have updated the patch with the documentation changes proposed and also added a news entry (does a new entry has to be added in some order?). Thank for the review in advance. -- Added file: http://bugs.python.org/file24526/issue13579_a99632426af5.patch ___ Python tracker <http://bugs.python.org/issue13579> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13579] string.Formatter doesn't understand the !a conversion specifier
Francisco Martín Brugué added the comment: Updated. The NEWS line is now at the top of the section. >As near as I can tell, the two change block beginning with >+In less formal terms, >[...] >are strictly re-wrapping and no text changes. Correct? Yes. Just a pydev question here: I now this re-wrapping adds noise to the patch, but can/should be done? Please correct me if I'm wrong: one should try to limit the line width to 80. If one word starts before and ends behind is not bad but new words should start in a new line. Now in the devguide states “To perform a quick sanity check on your path, you can run make patchcheck” I did that (I'm using the mq approach here) but I get no useful information (AFAIN): --- Modules/Setup.dist is newer than Modules/Setup; check to make sure you have all the updates you need in your Modules/Setup file. Usually, copying Modules/Setup.dist to Modules/Setup will work. --- ./python ./Tools/scripts/patchcheck.py Getting the list of files that have been added/changed ... 0 files Fixing whitespace ... 0 files Fixing C file whitespace ... 0 files Fixing docs whitespace ... 0 files Docs modified ... NO Misc/ACKS updated ... NO Misc/NEWS updated ... NO Thanks in advance ! -- Added file: http://bugs.python.org/file24555/issue13579_4720cc9e.patch ___ Python tracker <http://bugs.python.org/issue13579> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13579] string.Formatter doesn't understand the !a conversion specifier
Francisco Martín Brugué added the comment: > I suspect mq will confuse make patchcheck (since it looks for > differences between the working copy and the hg branch tip, and there > are no such differences for an applied mq patch). Does it makes sense to open a feature request for that? -- ___ Python tracker <http://bugs.python.org/issue13579> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14053] Make Tools/scripts/patchcheck.py compatible with mercurial mqueues.
New submission from Francisco Martín Brugué :
The devguide (http://docs.python.org/devguide/patch.html) recommends the use of
the mercurial “mq” feature to work with patches and that works IMHO very well.
It also states that before sending the patch a sanity check should be done
('devguide: Preparation and Generation'). At this stage, if one has the patch
as tip (hg qapplied), the advice to run “pathcheck” doesn't help as no changes
are noticed.
The message is:
---
Modules/Setup.dist is newer than Modules/Setup;
check to make sure you have all the updates you
need in your Modules/Setup file.
Usually, copying Modules/Setup.dist to Modules/Setup will work.
---
./python ./Tools/scripts/patchcheck.py
Getting the list of files that have been added/changed ... 0 files
Fixing whitespace ... 0 files
Fixing C file whitespace ... 0 files
Fixing docs whitespace ... 0 files
Docs modified ... NO
Misc/ACKS updated ... NO
Misc/NEWS updated ... NO
The tool should check if some mq patches are applied (from “normal” tip to
“mqtip” and make it's checks there.
Thanks in advance !
Francis
--
components: Demos and Tools, Devguide
messages: 153703
nosy: ezio.melotti, francismb
priority: normal
severity: normal
status: open
title: Make Tools/scripts/patchcheck.py compatible with mercurial mqueues.
___
Python tracker
<http://bugs.python.org/issue14053>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13579] string.Formatter doesn't understand the !a conversion specifier
Francisco Martín Brugué added the comment: Well, it's done: http://bugs.python.org/issue14053 -- ___ Python tracker <http://bugs.python.org/issue13579> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14053] Make Tools/scripts/patchcheck.py compatible with mercurial mqueues.
Francisco Martín Brugué added the comment: Here is a patch that works for me. Please check and review it. Thanks in advance! Francis -- keywords: +patch Added file: http://bugs.python.org/file24566/issue14053_336a614f35a3.patch ___ Python tracker <http://bugs.python.org/issue14053> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14053] Make Tools/scripts/patchcheck.py compatible with mercurial mqueues.
Francisco Martín Brugué added the comment: Nice feedback ! One question : > >An alternative approach that solves all three of these problems is to >check whether we have any patches applied (using "hg qapplied"), and if >this is the case, then add "--rev qbase" to the "hg status" command >line. This will list all files added/modified by patches as well as by >uncommitted changes. > Shouldn't be --rev qparent ? with --rev qbase the first MQ patch applied changes are not listed ... (one wants the changes between qparent and qtip) -- title: Make patchcheck compatible with MQ -> Make Tools/scripts/patchcheck.py compatible with mercurial mqueues. ___ Python tracker <http://bugs.python.org/issue14053> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14053] Make Tools/scripts/patchcheck.py compatible with mercurial mqueues.
Francisco Martín Brugué added the comment: The patch is updated. Notice about: [...]Ideally, it should distinguish between this and other errors by checking the subprocess's stderr, so that if a different error occurs, we can still print out the error message. […] that should be improved as now stderr is ignored in 'mq_changed_files' (user case: 'no mq extension enabled'). Suggestions are welcome! > [..] but this is a bit orthogonal. IMHO the MQ feature works very well for pydev newbies (as I'm) and it's a good recommendation (it's a taste thing ...) > The easiest thing to do is to make some changes and use > "hg diff> patch.diff" and the devguide should advertise this IMHO. This > also works fine with `make patchcheck`. There is some small differences between diff, qdiff and status but if one uses MQ then diff isn't enough. One really wants to know the changes from qparent to qtip and using 'status' as proposed I thing that it's the best solution. Cheers, francis -- Added file: http://bugs.python.org/file24582/issue14053_1f9461ef6312.patch ___ Python tracker <http://bugs.python.org/issue14053> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
